Dela via

Vanliga frågor och svar om programåterhämtning för Azure NetApp Files

  • Artikel

Den här artikeln besvarar vanliga frågor och svar om programresiliens i Azure NetApp Files.

Vad rekommenderar du för att hantera potentiella programstörningar på grund av underhållshändelser för lagringstjänsten?

Azure NetApp Files kan genomgå tillfälligt planerat underhåll (till exempel plattformsuppdateringar, tjänst- eller programvaruuppgraderingar). Från ett NFS-/SMB-perspektiv (file protocol) är underhållsåtgärderna icke-avbrottsfria, så länge programmet kan hantera de I/O-pauser som kort kan inträffa under dessa händelser. I/O-pauserna är vanligtvis korta, från några sekunder upp till 30 sekunder. NFS-protokollet är särskilt robust och filåtgärderna för klient-server fortsätter normalt. Vissa program kan kräva justering för att hantera I/O-pauser så länge som 30–45 sekunder. Se därför till att du är medveten om programmets återhämtningsinställningar för att hantera underhållshändelserna för lagringstjänsten. För interaktiva program som använder SMB-protokollet räcker standardprotokollinställningarna vanligtvis.

Viktigt!

För att säkerställa en elastisk arkitektur är det viktigt att känna igen att molnet fungerar enligt en modell med delat ansvar . Den här modellen omfattar Azure-molnplattformen, dess infrastrukturtjänster, OS-nivå och programleverantörer. Var och en av dessa komponenter spelar en viktig roll för att hantera potentiella programstörningar som kan uppstå under underhållshändelser för lagringstjänsten.

Behöver jag vidta särskilda försiktighetsåtgärder för SMB-baserade program?

Ja, vissa SMB-baserade program kräver transparent SMB-redundans. SMB Transparent redundans möjliggör underhållsåtgärder på Azure NetApp Files-tjänsten utan att avbryta anslutningen till serverprogram som lagrar och kommer åt data på SMB-volymer. För att stödja transparent SMB-redundans för specifika program har Azure NetApp Files nu stöd för alternativet SMB-resurser för kontinuerlig tillgänglighet. Användning av kontinuerlig SMB-tillgänglighet stöds endast för arbetsbelastningar på:

Varning

Anpassade program stöds inte med kontinuerlig SMB-tillgänglighet och kan inte användas med volymer med SMB-kontinuerlig tillgänglighet aktiverat.

Jag kör IBM MQ på Azure NetApp Files. Vilka försiktighetsåtgärder kan jag vidta för att undvika störningar på grund av underhållshändelser för lagringstjänsten trots att jag använder NFS-protokollet?

Om du kör IBM MQ-programmet i en konfiguration av delade filer, där IBM MQ-data och loggar lagras på en Azure NetApp Files-volym, rekommenderas följande överväganden för att förbättra motståndskraften under underhållshändelser för lagringstjänsten:

Kommentar

Antalet meddelanden som varje MQ-par med flera instanser ska bearbeta är mycket beroende av din specifika miljö. Du måste bestämma hur många MQ-par med flera instanser som skulle behövas, eller vilka uppskalnings- eller nedskalningsregler som skulle vara.

Utskalningsarkitekturen skulle bestå av flera IBM MQ-par med flera instanser som distribuerats bakom en Azure Load Balancer. Program som konfigurerats för att kommunicera med IBM MQ skulle sedan konfigureras för att kommunicera med IBM MQ-instanserna via Azure Load Balancer. För support som rör IBM MQ på delade NFS-volymer bör du få leverantörssupport på IBM.

Jag kör Apache ActiveMQ med LevelDB eller KahaDB på Azure NetApp Files. Vilka försiktighetsåtgärder kan jag vidta för att undvika störningar på grund av underhållshändelser för lagringstjänsten trots att jag använder NFS-protokollet ?

Om du kör Apache ActiveMQ rekommenderar vi att du distribuerar Hög tillgänglighet för ActiveMQ med låsbara lagringsskåp som kan anslutas.

ActiveMQ-modeller med hög tillgänglighet (HA) säkerställer att en koordinatorinstans alltid är online och kan bearbeta meddelandetrafik. De två vanligaste ActiveMQ HA-modellerna omfattar delning av ett filsystem över ett nätverk. Syftet är att tillhandahålla antingen LevelDB eller KahaDB till aktiva och passiva broker-instanser. Dessa HA-modeller kräver att ett lås på OS-nivå hämtas och underhålls på en fil i LevelDB- eller KahaDB-katalogerna, som kallas "lås". Det finns vissa problem med den här ActiveMQ HA-modellen. De kan leda till en "no-master"-situation där repliken inte vet att den kan låsa filen. De kan också leda till en "master-master"-konfiguration som resulterar i index- eller journalfel och slutligen meddelandeförlust. De flesta av dessa problem beror på faktorer utanför ActiveMQ:s kontroll. Till exempel kan en dåligt optimerad NFS-klient orsaka att låsdata blir inaktuella under belastning, vilket leder till "no-master" stilleståndstid under redundansväxling.

Eftersom de flesta problem med den här HA-lösningen beror på felaktig fillåsning på OS-nivå introducerade ActiveMQ-communityn konceptet med ett låsbart lagringsskåp i version 5.7 av asynkron meddelandekö. Med den här metoden kan en användare dra nytta av ett annat sätt för det delade låset, med hjälp av ett JDBC-databaslås på radnivå i stället för ett filsystemlås på OPERATIVSYSTEMnivå. Om du vill ha support eller rådgivning om ActiveMQ HA-arkitekturer och distributioner bör du kontakta OpenLogic by Perforce.

Jag kör Apache ActiveMQ med LevelDB eller KahaDB på Azure NetApp Files. Vilka försiktighetsåtgärder kan jag vidta för att undvika störningar på grund av underhållshändelser för lagringstjänsten trots att jag använder SMB-protokollet ?

Den allmänna branschrekommendationsen är att inte köra din delade KahaDB-lagring på CIFS [Common Internet File System]/SMB. Om du har problem med att upprätthålla korrekt låstillstånd kan du titta på JDBC Pluggable Storage Locker, som kan ge en mer tillförlitlig låsmekanism. Om du vill ha support eller rådgivning om ActiveMQ HA-arkitekturer och distributioner bör du kontakta OpenLogic by Perforce.

Jag kör Boomi på Azure NetApp Files. Vilka försiktighetsåtgärder kan jag vidta för att undvika störningar på grund av underhållshändelser för lagringstjänsten?

Om du kör Boomi rekommenderar vi att du följer boomi-metodtipsen för hög tillgänglighet och haveriberedskap för körningstid.

Boomi rekommenderar att Boomi Molecule används för att implementera hög tillgänglighet för Boomi Atom. Kraven för Boomi-molekylsystemet anger att antingen NFS med NFS-låsning aktiverat (NLM-stöd) eller SMB-filresurser kan användas. När det gäller Azure NetApp Files har NFSv4.1-volymer NLM-stöd.

Boomi rekommenderar att SMB-filresursen används med virtuella Windows-datorer. för NFS rekommenderar Boomi virtuella Linux-datorer.

Kommentar

Resurser för kontinuerlig tillgänglighet i Azure NetApp Files stöds inte med Boomi.

Nästa steg