Az Azure Files vészhelyreállítása és feladatátvétele

A Microsoft arra törekszik, hogy az Azure-szolgáltatások mindig elérhetők legyenek. Előfordulhat azonban, hogy nem tervezett szolgáltatáskimaradások lépnek fel, és rendelkeznie kell egy vészhelyreállítási (DR) tervvel a regionális szolgáltatáskimaradás kezelésére. A vészhelyreállítási terv fontos része a másodlagos végpontra való feladatátvétel előkészítése abban az esetben, ha az elsődleges végpont elérhetetlenné válik. Ez a cikk a vészhelyreállítással (DR) és a tárfiók feladatátvételével kapcsolatos fogalmakat és folyamatokat ismerteti.

Ügyfél által felügyelt tervezett feladatátvétel (előzetes verzió)

Az ügyfél által felügyelt tervezett feladatátvétel több forgatókönyvben is használható, beleértve a tervezett vészhelyreállítási tesztelést, a nagy léptékű katasztrófák proaktív megközelítését vagy a nem tárolóval kapcsolatos leállások utáni helyreállítást.

A tervezett feladatátvételi folyamat során az elsődleges és a másodlagos régió felcserélődik. Az eredeti elsődleges régió lefokozódik, és az új másodlagos régióvá válik. Ezzel egyidejűleg a rendszer előlépteti az eredeti másodlagos régiót, és az új elsődleges régióvá válik. A feladatátvétel befejezése után a felhasználók hozzáférhetnek az új elsődleges régió adataihoz, és a rendszergazdák érvényesíthetik vészhelyreállítási tervüket. A tárfióknak az elsődleges és a másodlagos régióban is elérhetőnek kell lennie a tervezett feladatátvétel kezdeményezése előtt.

A tervezett feladatátvételi és feladat-visszavételi folyamat során nem várható adatvesztés, amíg az elsődleges és a másodlagos régiók a teljes folyamat során elérhetők. További részletekért tekintse meg az Előrejelzés adatvesztés és inkonzisztenciák szakaszt.

Az ilyen típusú feladatátvétel felhasználókra és alkalmazásokra gyakorolt hatásának megértéséhez hasznos tudni, hogy mi történik a tervezett feladatátvételi és feladat-visszavételi folyamatok minden lépése során. A folyamat működésével kapcsolatos részletekért tekintse meg az ügyfél által felügyelt (tervezett) feladatátvétel működését.

Helyreállítási metrikák és költségek

Egy hatékony dr. stratégia kialakításához a szervezetnek tisztában kell lennie a következőekkel:

• Mennyi adatot veszíthet el egy üzemzavar esetén (helyreállítási pont célkitűzése vagy RPO)
• Milyen gyorsan kell tudnia visszaállítani az üzleti függvényeket és adatokat (helyreállítási időkorlát vagy RTO)

A DR költsége általában alacsonyabb vagy nulla RPO/RTO értékkel nő. Azok a vállalatok, amelyeknek egy katasztrófa után néhány másodpercen belül működésbe kell lépnie, és nem tudnak semmilyen adatvesztést fenntartani, többet fognak fizetni a DR-ért, míg a magasabb RPO/RTO-számmal rendelkezők kevesebbet fognak fizetni. Az Azure olyan megoldásokat kínál, amelyek különböző RPO- és RTO-követelményekkel működnek együtt.

Válassza ki a megfelelő redundanciabeállítást

Az Azure Files különböző redundancialehetőségeket kínál az adatok védelmére a tervezett és nem tervezett eseményektől kezdve az átmeneti hardverhibáktól, a hálózati és áramkimaradásoktól a természeti katasztrófákig. Minden Azure-fájlmegosztás használhat helyileg redundáns (LRS) vagy zónaredundáns tárolást (ZRS). További információ: Azure Files-redundancia.

Az Azure Files támogatja a georedundáns tárolással (GRS) és geozónára redundáns tárolással (GZRS) konfigurált standard tárfiókok feladatátvételét a regionális kimaradások elleni védelem érdekében. A fiók feladatátvételével kezdeményezheti a tárfiókjához a feladatátvételi folyamatot, ha az elsődleges végpont elérhetetlenné válik. A feladatátvétel frissíti a másodlagos végpontot, hogy az váljon a tárfiók elsődleges végpontjává. A feladatátvétel befejezése után az ügyfelek elkezdhetnek az új elsődleges végpontra írni.

A GRS és a GZRS továbbra is fennáll az adatvesztés kockázatával, mivel az adatok aszinkron módon vannak átmásolva a másodlagos régióba, ami azt jelenti, hogy késéssel történik az elsődleges régióba történő írás másolása a másodlagos régióba. Leállás esetén az írási műveletek elvesznek az elsődleges végpontra, amely még nem lett átmásolva a másodlagos végpontra. Ez azt jelenti, hogy az elsődleges régiót érintő hiba adatvesztést okozhat, ha az elsődleges régió nem állítható helyre. Az elsődleges régióba történő legutóbbi írások és a másodlagos régióba történő utolsó írás közötti időköz az RPO. Az Azure Files általában 15 perces vagy annál rövidebb RPO-val rendelkezik, bár jelenleg nincs SLA arra vonatkozóan, hogy mennyi ideig tart az adatok replikálása a másodlagos régióba.

Tervezés magas rendelkezésre álláshoz

Fontos, hogy az alkalmazást a kezdetektől magas rendelkezésre állásra tervezzen. Az alkalmazás tervezésével és a vészhelyreállítás tervezésével kapcsolatos útmutatásért tekintse meg ezeket az Azure-erőforrásokat:

• Rugalmas alkalmazások tervezése az Azure-hoz: A magas rendelkezésre állású alkalmazások Azure-beli tervezésének legfontosabb fogalmainak áttekintése.
• Rugalmassági ellenőrzőlista: Ellenőrzőlista annak ellenőrzéséhez, hogy az alkalmazás implementálja-e a magas rendelkezésre álláshoz ajánlott tervezési eljárásokat.
• Georedundancia használata magas rendelkezésre állású alkalmazások tervezéséhez: Tervezési útmutató alkalmazások létrehozásához az SMB-fájlmegosztások georedundáns tárolásának előnyeinek kihasználásához.

Azt is javasoljuk, hogy úgy tervezze meg az alkalmazást, hogy felkészüljön az írási hibák lehetőségére. Az alkalmazásnak úgy kell felfednie az írási hibákat, hogy figyelmeztethessen az elsődleges régióban bekövetkező kimaradás lehetőségére.

Ajánlott eljárásként úgy tervezheti meg az alkalmazást, hogy ellenőrizze az Utolsó szinkronizálási idő tulajdonságot a várt adatvesztés kiértékelése érdekében. Ha például minden írási műveletet naplóz, akkor összehasonlíthatja az utolsó írási műveletek időpontját az utolsó szinkronizálási idővel annak megállapításához, hogy mely írások nincsenek szinkronizálva a másodlagos írással.

Leállások nyomon követése

Az Azure Service Health irányítópultjára feliratkozva nyomon követheti az Azure Files és más Azure-szolgáltatások állapotát és állapotát.

A fiók feladatátvételének ismertetése

Az ügyfél által felügyelt fiók feladatátvétele lehetővé teszi a teljes tárfiók feladatátvételét a másodlagos régióba, ha az elsődleges valamilyen okból elérhetetlenné válik. Amikor feladatátvételt kényszerít a másodlagos régióra, az ügyfelek a feladatátvétel befejezése után megkezdhetik az adatok írását a másodlagos végpontra. A feladatátvétel általában körülbelül egy órát vesz igénybe. Javasoljuk, hogy a fiók feladatátvétele előtt a lehető legnagyobb mértékben függessze fel a számítási feladatot.

A fiók feladatátvételének kezdeményezéséről további információt a fiók feladatátvételének kezdeményezése című témakörben talál.

Hogyan működik a fiók feladatátvétele

Normál körülmények között az ügyfél adatokat ír az elsődleges régióban lévő tárfiókba, és az adatokat aszinkron módon másolja a másodlagos régióba. Az alábbi képen az az eset látható, amikor az elsődleges régió elérhető:

Ha az elsődleges végpont bármilyen okból elérhetetlenné válik, az ügyfél már nem tud írni a tárfiókba. Az alábbi képen az a forgatókönyv látható, amelyben az elsődleges nem érhető el, de még nem történt helyreállítás:

Az ügyfél kezdeményezi a fiók feladatátvételét a másodlagos végpontra. A feladatátvételi folyamat frissíti az Azure Storage által biztosított DNS-bejegyzést, hogy a másodlagos végpont legyen a tárfiók új elsődleges végpontja, ahogyan az alábbi képen látható:

A georedundáns fiókok írási hozzáférése a DNS-bejegyzés frissítése és a kérések az új elsődleges végpontra való irányítása után lesz visszaállítva. A meglévő tárolási szolgáltatásvégpontok a feladatátvétel után is változatlanok maradnak. A fájlleírók és a bérletek nem maradnak meg feladatátvételkor, ezért az ügyfeleknek le kell választaniuk és újra kell választaniuk a fájlmegosztásokat.

Adatvesztés előrejelzése

Mivel az adatok aszinkron módon vannak megírva az elsődleges régióból a másodlagos régióba, ha az elsődleges régió elérhetetlenné válik, előfordulhat, hogy a legutóbbi írások még nem lettek átmásolva a másodlagos régióba.

Feladatátvétel kényszerítésekor az elsődleges régió összes adata elveszik, mivel a másodlagos régió lesz az új elsődleges régió. Az új elsődleges régió helyileg redundánsnak van konfigurálva a feladatátvétel után.

A feladatátvétel során minden, a másodlagosra másolt adat megmarad. Az elsődlegesre írt, a másodlagosra szintén nem másolt adatok azonban végleg elvesznek.

Az Utolsó szinkronizálás időpontja tulajdonság ellenőrzése

Az Utolsó szinkronizálási idő (LST) tulajdonság azt jelzi, hogy az elsődleges régióból származó adatok biztosan a másodlagos régióba lettek írva. Az utolsó szinkronizálási idő előtt írt összes adat elérhető a másodlagos kiszolgálón, míg az utolsó szinkronizálási idő után írt adatok esetleg nem lettek megírva a másodlagosra, és elveszhetnek. Ezt a tulajdonságot használva kimaradás esetén megbecsülheti a fiók feladatátvételének kezdeményezésével esetlegesen felmerülő adatvesztések mennyiségét.

Annak érdekében, hogy a fájlmegosztások konzisztens állapotban legyenek feladatátvétel esetén, a rendszer 15 percenként létrehoz egy rendszer-pillanatképet az elsődleges régióban, és replikálja a másodlagos régióba. Amikor feladatátvétel történik a másodlagos régióban, a megosztási állapot a másodlagos régió legújabb rendszerpillanatképén alapul. Ha hiba történik az elsődleges régióban, a másodlagos régió valószínűleg az elsődleges régió mögött van, mivel az elsődlegesre írt összes írás még nem lesz replikálva a másodlagosra. Georedundáns késés vagy egyéb problémák miatt előfordulhat, hogy a másodlagos régió legújabb rendszerpillanatképe 15 percnél régebbi lehet.

Az LST előtt az elsődleges régióba írt összes írási művelet sikeresen replikálva lett a másodlagos régióba, ami azt jelenti, hogy a másodlagos régióból olvashatók. Az utolsó szinkronizálási idő után az elsődleges régióba írt írási műveletek replikálhatók vagy nem replikálhatók a másodlagos régióba, ami azt jelenti, hogy nem érhetők el olvasási műveletekhez.

Az Utolsó szinkronizálási idő tulajdonság értékét az Azure PowerShell, az Azure CLI vagy az ügyfélkódtár használatával kérdezheti le. Az Utolsó szinkronizálási idő tulajdonság egy GMT dátum/idő érték. További információ: Tárfiók utolsó szinkronizálási ideje tulajdonságának ellenőrzése.

Körültekintően járjon el az eredeti elsődlegesre való visszalépéskor

Ahogy korábban említettük, miután feladatátvételt végzett az elsődleges régióból a másodlagos régióba, a tárfiók helyileg redundánsnak van konfigurálva az új elsődleges régióban. Ezután konfigurálhatja a fiókot az új elsődleges régióban a georedundancia érdekében. Ha a fiók georedundanciára van konfigurálva a feladatátvétel után, az új elsődleges régió azonnal megkezdi az adatok másolását az új másodlagos régióba, amely az eredeti feladatátvétel előtti elsődleges régió volt. Azonban eltarthat egy ideig, amíg az új elsődlegesen meglévő adatok teljes mértékben át lesznek másolva az új másodlagosra.

Miután a tárfiókot újrakonfigurálta a georedundancia érdekében, kezdeményezhet feladat-visszavételt az új elsődlegesről az új másodlagosra. Ebben az esetben a feladatátvételt megelőző eredeti elsődleges régió lesz ismét az elsődleges régió, és helyileg redundáns vagy zónaredundánsként van konfigurálva attól függően, hogy az eredeti elsődleges konfiguráció GRS vagy GZRS volt-e. A feladatátvétel utáni elsődleges régióban (az eredeti másodlagos régióban) lévő összes adat elveszik a feladat-visszavétel során. Ha a tárfiókban lévő adatok többsége nem lett átmásolva az új másodlagos helyre a feladat-visszavétel előtt, jelentős adatvesztést szenvedhet el.

A nagyobb adatvesztés elkerülése érdekében ellenőrizze a Legutóbbi szinkronizálási idő tulajdonság értékét, mielőtt visszabukik. Hasonlítsa össze az utolsó szinkronizálási időt az új elsődlegesbe írt utolsó időponthoz a várt adatvesztés kiértékeléséhez.

A feladat-visszavételi művelet után konfigurálhatja, hogy az új elsődleges régió ismét georedundáns legyen. Ha az eredeti elsődleges az LRS-hez lett konfigurálva, akkor grS-nek is konfigurálhatja. Ha az eredeti elsődleges a ZRS-hez lett konfigurálva, akkor GZRS-nek is konfigurálhatja. További beállításokért lásd : Tárfiók replikálás módjának módosítása.

Fiók feladatátvételének indítása

A fiók feladatátvételét az Azure Portalról, a PowerShellből, az Azure CLI-ből vagy az Azure Storage erőforrás-szolgáltató API-jából kezdeményezheti. A feladatátvétel indításáról további információt a fiók feladatátvételének kezdeményezése című témakörben talál.

Microsoft által felügyelt feladatátvétel

Szélsőséges körülmények között, amikor egy régió jelentős katasztrófa miatt elveszik, a Microsoft regionális feladatátvételt kezdeményezhet. Ebben az esetben nincs szükség műveletre az Ön részéről. A Microsoft által felügyelt feladatátvétel befejezéséig nem lesz írási hozzáférése a tárfiókhoz.

Lásd még

• Azure Files-redundancia
• Az Azure Files adatvédelmi áttekintése
• Tárfiók feladatátvételének kezdeményezése