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.
Fontos
Az Azure File Sync csak akkor támogatja a tárfiók feladatátvételét, ha a Társzinkronizálási szolgáltatás is feladatátvételt fut. Ennek az az oka, hogy az Azure File Sync megköveteli, hogy a tárfiók és a Társzinkronizálási szolgáltatás ugyanabban az Azure-régióban legyen. Ha csak a tárfiók feladatátvétele történik meg, a szinkronizálási és a felhőbeli rétegzési műveletek mindaddig sikertelenek lesznek, amíg a Társzinkronizálási szolgáltatás át nem kerül a másodlagos régióba. Ha az Azure File Syncben felhővégpontokként használt Azure-fájlmegosztásokat tartalmazó tárfiókot szeretne feladatátvételre használni, tekintse meg az Azure File Sync vészhelyreállítási ajánlott eljárásait és az Azure File Sync-kiszolgáló helyreállítá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.
Fontos
A GRS/GZRS nem támogatott a prémium Szintű Azure-fájlmegosztások esetében. A földrajzi redundancia eléréséhez azonban szinkronizálhat két Azure-fájlmegosztás között.
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.
Fontos
A feladatátvétel befejezése után a tárfiók helyileg redundánsnak van konfigurálva az új elsődleges végponton/régióban. A replikáció új másodlagosra való folytatásához konfigurálja újra a georedundáns fiókot.
Ne feledje, hogy a helyileg redundáns tárfiók georedundánssá alakítása költségekkel és idővel jár. További információ: A fiók feladatátvételének fontos következményei.
Adatvesztés előrejelzése
Figyelemfelhívás
A fiókok feladatátvétele általában némi adatvesztéssel jár. Fontos tisztában lenni a fiók feladatátvételének kezdeményezésével járó következményekkel.
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.