Megosztás a következőn keresztül:

Az Azure Storage vészhelyreállításának tervezése és feladatátvétele

  • Cikk

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 fordulnak elő. A jó vészhelyreállítási terv fő összetevői a következőkre vonatkozó stratégiák:

Ez a cikk ismerteti a globálisan redundáns tárfiókokhoz elérhető lehetőségeket, és javaslatokat nyújt a magas rendelkezésre állású alkalmazások fejlesztéséhez és a vészhelyreállítási terv teszteléséhez.

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

Az Azure Storage a tárfiók több példányát is fenntartja annak érdekében, hogy a rendelkezésre állási és tartóssági célok teljesüljenek, még a hibák esetén is. Az adatok replikálásának módja eltérő védelmi szinteket biztosít. Minden lehetőség saját előnyöket kínál, ezért a választott lehetőség attól függ, hogy az alkalmazások milyen fokú rugalmasságot igényelnek.

A helyileg redundáns tárolás (LRS), a legalacsonyabb költségű redundancia lehetőség automatikusan tárolja és replikálja a tárfiók három példányát egyetlen adatközpontban. Bár az LRS védi az adatokat a kiszolgálóállványokkal és a meghajtóhibákkal szemben, nem veszi figyelembe az olyan katasztrófákat, mint a tűz vagy az adatközponton belüli áradás. Ilyen katasztrófák esetén előfordulhat, hogy egy LRS használatára konfigurált tárfiók összes replikája elveszik vagy helyreállíthatatlan lesz.

Ehhez képest a zónaredundáns tárolás (ZRS) megőrzi egy tárfiók másolatát, és replikálja azt az ugyanazon régión belüli három különálló rendelkezésre állási zónában. A rendelkezésre állási zónákkal kapcsolatos további információkért lásd: Azure rendelkezésre állási zónák.

A tárfiók egyetlen példányának helyreállítása automatikusan megtörténik az LRS és a ZRS használatával is.

Georedundáns tárolás és feladatátvétel

A georedundáns tárolás (GRS), a georedundáns tárolás (GZRS) és az olvasási hozzáférésű georedundáns georedundáns tárolás (RA-GZRS) példák a globálisan redundáns tárolási lehetőségekre. Ha globálisan redundáns tárolás (GRS, GZRS és RA-GZRS) használatára van konfigurálva, az Azure aszinkron módon másolja az adatokat egy másodlagos földrajzi régióba. Ezek a régiók több száz, vagy akár több ezer mérföldnyire találhatók. Ez a redundanciaszint lehetővé teszi az adatok helyreállítását, ha a teljes elsődleges régióban kimaradás van.

Az LRS-sel és a ZRS-sel ellentétben a globálisan redundáns tárolás a másodlagos régióba történő nem tervezett feladatátvételt is támogatja, ha az elsődleges régióban kimaradás történik. A feladatátvételi folyamat során a tárfiók-szolgáltatásvégpontok DNS-bejegyzései automatikusan frissülnek, így a másodlagos régió végpontjai lesznek az új elsődleges végpontok. A nem tervezett feladatátvétel befejezése után az ügyfelek megkezdhetik az írást az új elsődleges végpontokra.

Az olvasási hozzáférésű georedundáns tárolás (RA-GRS) és az olvasási hozzáférésű georedundáns tárolás (RA-GZRS) georedundáns tárolást is biztosít, de a másodlagos végponthoz való olvasási hozzáférés további előnye. Ezek a lehetőségek ideálisak a magas rendelkezésre állású, üzletileg kritikus fontosságú alkalmazásokhoz tervezett alkalmazásokhoz. Ha az elsődleges végpont leállást tapasztal, a másodlagos régióhoz való olvasási hozzáférésre konfigurált alkalmazások továbbra is működhetnek. A Microsoft az RA-GZRS használatát javasolja a tárfiókok maximális rendelkezésre állása és tartóssága érdekében.

Az Azure Storage redundanciáról további információt az Azure Storage redundanciájában talál.

Feladatátvétel tervezése

Az Azure Storage-fiókok háromféle feladatátvételt támogatnak:

1 A Microsoft által felügyelt feladatátvétel nem kezdeményezhető egyéni tárfiókok, előfizetések vagy bérlők esetében. További információ: Microsoft által felügyelt feladatátvétel.
2 Az ügyfél által felügyelt feladatátvételi lehetőségek használata vészhelyreállítási tervek fejlesztéséhez, teszteléséhez és implementálásához. Ne támaszkodhat a Microsoft által felügyelt feladatátvételre, amelyet csak szélsőséges körülmények között használna.

Minden feladatátvételi típus egyedi használati esetekkel, az adatvesztéssel kapcsolatos elvárásokkal és a hierarchikus névtérrel rendelkező fiókok támogatásával (Azure Data Lake Storage Gen2) rendelkezik. Ez a táblázat a feladatátvétel egyes típusainak ezeket a szempontjait foglalja össze:

Típus Feladatátvételi hatókör Használati eset Várható adatvesztés A hierarchikus névtér (HNS) támogatott
Ügyfél által felügyelt tervezett feladatátvétel (előzetes verzió) Tárfiók Az elsődleges és másodlagos régiók tárolási szolgáltatásvégpontjai elérhetők, és vészhelyreállítási tesztelést szeretne végezni.

Az elsődleges régió tárolási szolgáltatásvégpontjai elérhetők, de egy másik Microsoft- vagy harmadik féltől származó szolgáltatás megakadályozza a számítási feladatok megfelelő működését.

Proaktívan felkészülni a nagy méretű katasztrófákra, például egy hurrikánra, amely hatással lehet egy régióra.		 Nem Igen
(Előzetes verzióban)
Ügyfél által felügyelt (nem tervezett) feladatátvétel Tárfiók Az elsődleges régió tárolási szolgáltatásvégpontjai elérhetetlenné válnak, de a másodlagos régió elérhető.

Kapott egy Azure Advisory-t, amelyben a Microsoft azt javasolja, hogy végezzen feladatátvételi műveletet azoknak a tárfiókoknak, amelyeket esetleg kimaradás érinthet.		 Igen Igen
(Előzetes verzióban)
Microsoft által felügyelt Teljes régió Az elsődleges régió egy jelentős katasztrófa miatt elérhetetlenné válik, de a másodlagos régió elérhető. Igen Igen

Az alábbi táblázat összehasonlítja a tárfiók redundanciaállapotát minden feladatátvételi típus után:

Feladatátvétel eredménye... Ügyfél által felügyelt tervezett feladatátvétel (előzetes verzió) Ügyfél által felügyelt (nem tervezett) feladatátvétel
... a másodlagos régió A másodlagos régió lesz az új elsődleges régió A másodlagos régió lesz az új elsődleges régió
... az eredeti elsődleges régió Az eredeti elsődleges régió lesz az új másodlagos régió Az eredeti elsődleges régió adatainak másolata törlődik
... a fiók redundanciakonfigurációja A tárfiók GRS-vé alakul A tárfiók LRS-sé alakul
... a georedundancia-konfiguráció A georedundancia megmarad A georedundancia elvész

Az alábbi táblázat a feladatátvételi és feladat-visszavételi folyamat minden szakaszában összefoglalja az eredményként kapott redundanciakonfigurációt az egyes feladatátvételi típusokhoz:

Eredeti
konfiguráció		 Után
feladatátvétel		 Újraengedélyezés után
georedundancia		 Után
feladat-visszavétel		 Újraengedélyezés után
georedundancia
Ügyfél által felügyelt tervezett feladatátvétel
GRS GRS n/a 2 GRS n/a 2
GZRS GRS n/a 2 GZRS n/a 2
Ügyfél által felügyelt (nem tervezett) feladatátvétel
GRS LRS GRS 1 LRS GRS 1
GZRS LRS GRS 1 ZRS GZRS 1

1 A georedundancia elveszik a nem tervezett feladatátvétel során, és manuálisan kell újrakonfigurálni.
2 A georedundancia nem tervezett feladatátvétel során megmarad, és nem kell manuálisan újrakonfigurálni.

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

Fontos

Az ügyfél által felügyelt tervezett feladatátvétel jelenleg előzetes verzióban érhető el, és a következő régiókra korlátozódik:

  • Kelet-Ausztrália
  • Az USA középső régiója
  • Kelet-Ázsia
  • USA 2. keleti régiója
  • Közép-Franciaország
  • Közép-India
  • Nyugat-India
  • Délkelet-Ázsia
  • Észak-Svájc
  • Nyugat-Svájc
  • Az Egyesült Királyság déli régiója
  • Nyugat-Európa

A bétaverziójú, előzetes verziójú vagy másként még általánosan nem elérhető Azure-szolgáltatások jogi feltételeit lásd: Kiegészítő használati feltételek a Microsoft Azure előzetes verziójú termékeihez.

Az előzetes verzióra való bejelentkezéshez tekintse meg az Előzetes verziójú szolgáltatások beállítása az Azure-előfizetésben című témakört, és adja meg AllowSoftFailover a funkció nevét. Az előzetes verziójú szolgáltatás szolgáltatóneve a Microsoft.Storage.

Fontos

A tervezett feladatátvétel után előfordulhat, hogy egy tárfiók utolsó szinkronizálási ideje (LST) értéke elavultnak tűnik, vagy NULL értékként jelenik meg az Azure Files-adatok megjelenésekor.

A rendszer pillanatképei rendszeres időközönként létrejönnek a tárfiók másodlagos régiójában a feladatátvétel és a feladat-visszavétel során használt konzisztens helyreállítási pontok fenntartása érdekében. Az ügyfél által felügyelt tervezett feladatátvétel kezdeményezése miatt az eredeti elsődleges régió lesz az új másodlagos. Bizonyos esetekben a tervezett feladatátvétel befejezése után nem érhetők el rendszer-pillanatképek az új másodlagos rendszeren, így a fiók teljes LST-értéke elavultnak vagy elavultnak Nulltűnik.

Mivel az olyan felhasználói tevékenységek, mint például az objektumok létrehozása, módosítása vagy törlése, pillanatkép-létrehozást válthatnak ki, a tervezett feladatátvétel után ezek a tevékenységek nem igényelnek további figyelmet. A pillanatképekkel vagy felhasználói tevékenységekkel nem rendelkező fiókok azonban továbbra is megjeleníthetnek LST-értéket Null , amíg a rendszer pillanatképének létrehozása nem aktiválódik.

Ha szükséges, hajtsa végre az alábbi tevékenységek egyikét a pillanatkép-létrehozás aktiválásához. A befejezés után a fióknak 30 percen belül meg kell jelennie egy érvényes LST-értéknek.

  • Csatlakoztassa a megosztást, majd nyissa meg az olvasáshoz szükséges fájlokat.
  • Töltsön fel egy tesztfájlt vagy egy mintafájlt a megosztásba.
  • Hozzon létre egy megosztási pillanatképet a megosztáshoz az Azure Portalon.

Számos forgatókönyv esetében ideális a tervezett feladatátvétel. Ezek a forgatókönyvek a következőket biztosítják:

  • Vészhelyreállítás (DR) tervezése és tesztelése.
  • Helyreállítás olyan üzemkimaradás során, amely nem befolyásolja az elsődleges régió tárolási szolgáltatásvégpontjait, de megakadályozza, hogy egy másik Microsoft- vagy harmadik féltől származó szolgáltatás hozzáférést biztosítson a számítási feladatokhoz.
  • Proaktívan felkészülni a nagy méretű katasztrófákra, például egy hurrikánra, amely hatással lehet egy régióra.

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.

Ügyfél által felügyelt (nem tervezett) feladatátvétel

Ha a tárfiókban lévő tárolási szolgáltatások adatvégpontjai elérhetetlenné válnak az elsődleges régióban, nem tervezett feladatátvételt kezdeményezhet a másodlagos régióba. A feladatátvétel befejezése után a másodlagos régió lesz az új elsődleges, és a felhasználók ott folytathatják az adatok elérését.

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 nem tervezett feladatátvételi és feladat-visszavételi folyamat 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 (nem tervezett) feladatátvétel működését.

Microsoft által felügyelt feladatátvétel

A Microsoft szélsőséges körülmények között regionális feladatátvételt kezdeményezhet, például egy teljes georégiót érintő katasztrofális katasztrófa esetén. Ezekben az eseményekben nincs szükség műveletre az Ön részéről. Ha a tárfiók RA-GRS-hez vagy RA-GZRS-hez van konfigurálva, az alkalmazások a Microsoft által felügyelt feladatátvétel során olvashatnak a másodlagos régióból. A feladatátvételi folyamat befejezéséig azonban nem rendelkezik írási hozzáféréssel a tárfiókhoz.

Fontos

Használja az ügyfél által felügyelt feladatátvételi lehetőségeket vészhelyreállítási tervek fejlesztéséhez, teszteléséhez és implementálásához. Ne támaszkodhat a Microsoft által felügyelt feladatátvételre, amely csak szélsőséges körülmények között használható. A Microsoft által felügyelt feladatátvételt egy teljes fizikai egységre, például régióra, adatközpontra kell elindítani. Nem kezdeményezhető egyéni tárfiókok, előfizetések vagy bérlők esetében. Ha az egyéni tárfiókok szelektív feladatátvételére van szüksége, használja az ügyfél által felügyelt tervezett feladatátvételt.

Adatvesztés és inkonzisztenciák előrejelzése

Figyelemfelhívás

Az ügyfél által felügyelt (nem tervezett) feladatátvétel általában némi adatvesztéssel jár, és fájl- és adatkonzisztenciákat is okozhat. A vészhelyreállítási tervben fontos figyelembe venni, hogy a fiók feladatátvétele milyen hatással lenne az adatokra, mielőtt elindítaná az egyiket.

Mivel az adatok aszinkron módon vannak megírva az elsődleges régióból a másodlagos régióba, a rendszer mindig késlelteti az elsődleges régióba történő írást a másodlagos régióba. Ha az elsődleges régió elérhetetlenné válik, lehetséges, hogy a legutóbbi írások még nem lesznek átmásolva a másodlagosra.

Nem tervezett feladatátvétel esetén az elsődleges régió összes adata elveszik, mivel a másodlagos régió lesz az új elsődleges. A feladatátvétel során minden, a másodlagos régióba másolt adat megmarad. A másodlagos régióban még nem létező elsődlegesre írt adatok azonban végleg elvesznek.

Az új elsődleges régió helyileg redundánsnak (LRS) van konfigurálva a feladatátvétel után.

Fájl- vagy adatkonkonzisztenciát is tapasztalhat, ha a tárfiókok engedélyezve vannak az alábbi lehetőségek közül:

Utolsó szinkronizálás ideje

Az Utolsó szinkronizálási idő tulajdonság azt a legutóbbi időpontot jelzi, amikor az elsődleges régióból származó adatokat is a másodlagos régióba írták. Hierarchikus névtérrel rendelkező fiókok esetében ugyanez a Last Sync Time tulajdonság a hierarchikus névtér által kezelt metaadatokra is vonatkozik, beleértve a hozzáférés-vezérlési listákat (ACL-eket). Az utolsó szinkronizálási idő előtt írt összes adat és metaadat elérhető a másodlagos kiszolgálón. Ezzel szemben előfordulhat, hogy az utolsó szinkronizálási idő után írt adatok és metaadatok még nem lesznek átmásolva a másodlagosra, és elveszhetnek. A szolgáltatáskimaradás során ezzel a tulajdonságkal megbecsülheti a fiók feladatátvételének kezdeményezése során felmerülő adatvesztések mennyiségét.

Ajánlott eljárásként úgy tervezheti meg az alkalmazást, hogy a Legutóbbi szinkronizálási idő használatával kiértékelhesse a várt adatvesztést. Az összes írási művelet naplózásával például összehasonlíthatja az utolsó írási művelet időpontját az utolsó szinkronizálási idővel. Ezzel a módszerrel megállapíthatja, hogy mely írások nincsenek még szinkronizálva a másodlagos írással, és fennáll a veszélye annak, hogy elvesznek.

Az Utolsó szinkronizálási idő tulajdonság ellenőrzéséről további információt a tárfiók Utolsó szinkronizálási idő tulajdonságának ellenőrzése című témakörben talál.

Az Azure Data Lake Storage Gen2 fájlkonzisztenciája

A hierarchikus névtérrel rendelkező tárfiókok (Azure Data Lake Storage Gen2) replikációja a fájl szintjén történik. Mivel a replikáció ezen a szinten történik, az elsődleges régió leállása megakadályozhatja, hogy a tárolón vagy könyvtáron belüli fájlok egy része sikeresen replikáljon a másodlagos régióba. A tárolóban vagy könyvtárban lévő összes fájl konzisztenciája a tárfiók feladatátvétele után nem garantált.

Adatcsatorna- és blobadatok inkonzisztenciák módosítása

A változáscsatornával rendelkező tárfiókok ügyfél által felügyelt (nem tervezett) feladatátvétele inkonzisztenciát okozhat a változáscsatornanaplók és a blobadatok és/vagy metaadatok között. Ezek az inkonzisztenciák a változásnapló-frissítések aszinkron jellegéből és az elsődleges és másodlagos régiók közötti adatreplikációból eredhetnek. Az inkonzisztenciákat az alábbi óvintézkedések betartásával kerülheti el:

  • Győződjön meg arról, hogy az összes naplórekord ki van ürítve a naplófájlba.
  • Győződjön meg arról, hogy az összes tárolási adat replikálva van az elsődlegesről a másodlagos régióba.

A változáscsatornáról további információt a változáscsatorna működése című témakörben talál.

Ne feledje, hogy a tárfiók egyéb funkciói is megkövetelik a változáscsatorna engedélyezését. Ezek a funkciók magukban foglalják az Azure Blob Storage operatív biztonsági mentését, az objektumreplikálást és a blokkblobok időponthoz kötött visszaállítását.

Időponthoz kötött visszaállítási inkonzisztenciák

Az ügyfél által felügyelt feladatátvételt az általános célú, 2. szintű standard szintű tárfiókok támogatják, amelyek blokkblobokat tartalmaznak. Az ügyfél által felügyelt feladatátvétel egy tárfiókon történő végrehajtása azonban alaphelyzetbe állítja a fiók lehető legkorábbi visszaállítási pontjának visszaállítását. A blokkblobok időponthoz kötött visszaállításának adatai csak a feladatátvétel befejezésének időpontjáig konzisztensek. Ennek eredményeképpen a blokkblobok csak a feladatátvétel befejezési időpontjánál nem korábbi időpontra állíthatók vissza. A feladatátvételi befejezési időt a tárfiók redundancia lapján ellenőrizheti az Azure Portalon.

A feladatátvétel ideje és költsége

Az ügyfél által felügyelt feladatátvétel elindítása után eltelt idő eltérő lehet, bár általában kevesebb mint egy órát vesz igénybe.

A tervezett ügyfél által felügyelt feladatátvétel nem veszíti el a georedundanciát a feladatátvétel és az azt követő feladat-visszavétel után, de a nem tervezett, ügyfél által felügyelt feladatátvétel igen.

Az ügyfél által felügyelt nem tervezett feladatátvétel kezdeményezése automatikusan helyileg redundáns tárolóvá (LRS) alakítja át a tárfiókot egy új elsődleges régión belül, és törli a tárfiókot az eredeti elsődleges régióban.

Újra engedélyezheti a georedundáns tárolást (GRS) vagy az olvasási hozzáférésű georedundáns tárolást (RA-GRS) a fiók számára, de az adatok újrareplikálása az új másodlagos régióba díjköteles. Emellett az archivált blobokat online szintre kell rehidratálni ahhoz, hogy a fiók újrakonfigurálható legyen a georedundancia érdekében. Ez a rehidratálás többletköltséget is von maga után. A díjszabással kapcsolatos további információkért lásd:

Miután újra engedélyezte a GRS-t a tárfiókhoz, a Microsoft megkezdi a fiókban lévő adatok replikálását az új másodlagos régióba. A replikáció befejezéséhez szükséges idő több tényezőtől függ. Ezek a tényezők a következők:

  • A tárfiókban lévő objektumok száma és mérete. Sok kis objektum replikálása hosszabb időt vehet igénybe, mint kevesebb és nagyobb objektum replikálása.
  • A háttérreplikációs erőforrások, például a CPU, a memória, a lemez és a WAN kapacitás. Az élő forgalom elsőbbséget élvez a georeplikálással szemben.
  • Adott esetben a pillanatképek száma blobonként.
  • Az adatparticionálási stratégia, ha a tárfiók táblákat tartalmaz. A replikációs folyamat nem méretezhető túl a használt partíciókulcsok számán.

Támogatott tárfióktípusok

Minden georedundáns ajánlat támogatja a Microsoft által felügyelt feladatátvételt. Emellett egyes fióktípusok támogatják az ügyfél által felügyelt fiókok feladatátvételét, ahogy az az alábbi táblázatban is látható:

Feladatátvétel típusa GRS/RA-GRS GZRS/RA-GZRS
Ügyfél által felügyelt (nem tervezett) feladatátvétel Általános célú v2-fiókok
Általános célú v1-fiókok
Örökölt Blob Storage-fiókok		 Általános célú v2-fiókok
Ügyfél által felügyelt tervezett feladatátvétel (előzetes verzió) Általános célú v2-fiókok
Általános célú v1-fiókok
Örökölt Blob Storage-fiókok		 Általános célú v2-fiókok
Microsoft által felügyelt feladatátvétel Minden fióktípus Általános célú v2-fiókok

Klasszikus tárfiókok

Fontos

Az ügyfél által felügyelt feladatátvétel csak az Azure Resource Manager (ARM) üzemi modellel üzembe helyezett tárfiókok esetében támogatott. Az Azure Service Manager (ASM) üzembehelyezési modellje, más néven a klasszikus modell nem támogatott. Ahhoz, hogy a klasszikus tárfiókok jogosultak legyenek az ügyfél által felügyelt fiókok feladatátvételére, először át kell őket telepíteni az ARM-modellbe. A tárfióknak elérhetőnek kell lennie a frissítés végrehajtásához, így az elsődleges régió jelenleg nem lehet hibás állapotban.

Az elsődleges régiót érintő katasztrófa során a Microsoft kezeli a klasszikus tárfiókok feladatátvételét. További információ: Microsoft által felügyelt feladatátvétel.

Hierarchikus névtér (HNS)

Fontos

A hierarchikus névtérrel (Azure Data Lake Storage Gen2) vagy SSH File Transfer Protocolnal (SFTP) rendelkező fiókok ügyfél által felügyelt (nem tervezett) feladatátvétele jelenleg előzetes verzióban érhető el, és csak a következő régiókban támogatott:

  • (Ázsia és a Csendes-óceáni térség) Közép-India
  • (Ázsiai-csendes-óceáni térség) Délkelet-Ázsia
  • (Európa) Észak-Európa
  • (Európa) Észak-Svájc
  • (Európa) Nyugat-Svájc
  • (Európa) Nyugat-Európa
  • (Észak-Amerika) Közép-Kanada
  • (Észak-Amerika) USA 2. keleti régiója
  • (Észak-Amerika) USA déli középső régiója

Az előzetes verzióra való bejelentkezéshez tekintse meg az Előzetes verziójú szolgáltatások beállítása az Azure-előfizetésben című témakört, és adja meg AllowHNSAccountFailover a funkció nevét.

A bétaverziójú, előzetes verziójú vagy másként még általánosan nem elérhető Azure-szolgáltatások jogi feltételeit lásd: Kiegészítő használati feltételek a Microsoft Azure előzetes verziójú termékeihez.

Az elsődleges régiót érintő jelentős katasztrófa esetén a Microsoft felügyeli a hierarchikus névtérrel rendelkező fiókok feladatátvételét. További információ: Microsoft által felügyelt feladatátvétel.

Nem támogatott funkciók és szolgáltatások

Az ügyfél által felügyelt feladatátvételhez az alábbi funkciók és szolgáltatások nem támogatottak:

  • Az Azure File Sync nem támogatja az ügyfél által felügyelt fiók feladatátvételét. Az Azure File Sync felhőalapú végpontjaként használt tárfiókokat nem szabad feladatátvételre használni. A feladatátvétel megszakítja a fájlszinkronizálást, és az újonnan rétegzett fájlok váratlan adatvesztését okozhatja. További információkért lásd az Azure File Sync vészhelyreállításának ajánlott eljárásait.
  • A prémium szintű blokkblobokat tartalmazó tárfiókok nem adhatók át. A prémium szintű blokkblobokat támogató tárfiókok jelenleg nem támogatják a georedundanciát.
  • Az ügyfél által felügyelt feladatátvétel nem támogatott sem a forrás, sem a célfiók esetében egy objektumreplikációs szabályzatban.
  • A hálózati fájlrendszer (NFS) 3.0 (NFSv3) nem támogatott a tárfiók feladatátvételéhez. Az NFSv3 engedélyezésével nem hozhat létre globális redundanciához konfigurált tárfiókot.

Az alábbi táblázat a szolgáltatástámogatásra hivatkozik.

Tervezett feladatátvétel Nem tervezett feladatátvétel
ADLS Gen2 Támogatott (előzetes verzió) Támogatott (előzetes verzió)
Hírcsatorna módosítása Támogatott Támogatott
Objektumreplikálás Nem támogatott Nem támogatott
SFTP Támogatott (előzetes verzió) Támogatott (előzetes verzió)
NFSv3 A GRS nem támogatott A GRS nem támogatott
Tárolási műveletek Nem támogatott Nem támogatott
Időponthoz kötött visszaállítás (PITR) Támogatott Támogatott

A feladatátvétel nem fiókmigráláshoz szükséges

A tárfiók feladatátvétele egy ideiglenes megoldás, amely a DR-csomagok megtervezéséhez és teszteléséhez, vagy egy szolgáltatáskimaradásból való helyreállításhoz használható. A feladatátvétel nem használható az adatmigrálási stratégia részeként. A tárfiókok migrálásáról további információt az Azure Storage migrálási áttekintésében talál.

Archivált blobokat tartalmazó tárfiókok

Az archivált blobokat tartalmazó tárfiókok támogatják a feladatátvételt. Az ügyfél által felügyelt feladatátvétel befejezése után azonban az összes archivált blobot online szintre kell rehidratálni ahhoz, hogy a fiók konfigurálható legyen georedundanciára.

Tárolásierőforrás-szolgáltató

A Microsoft két REST API-t biztosít az Azure Storage-erőforrások használatához. Ezek az API-k képezik az Azure Storage-on elvégezhető összes művelet alapját. Az Azure Storage REST API lehetővé teszi, hogy a tárfiókban lévő adatokkal dolgozzon, beleértve a blob-, üzenetsor-, fájl- és táblaadatokat. Az Azure Storage-erőforrás-szolgáltató REST API-val kezelheti a tárfiókot és a kapcsolódó erőforrásokat.

A feladatátvétel befejezése után az ügyfelek ismét olvashatják és írhatnak Azure Storage-adatokat az új elsődleges régióban. Az Azure Storage-erőforrás-szolgáltató azonban nem végzi el a feladatátvételt, ezért az erőforrás-kezelési műveleteknek továbbra is az elsődleges régióban kell lenniük. Ha az elsődleges régió nem érhető el, nem fog tudni felügyeleti műveleteket végrehajtani a tárfiókon.

Mivel az Azure Storage-erőforrás-szolgáltató nem végzi el a feladatátvételt, a Hely tulajdonság az eredeti elsődleges helyet adja vissza a feladatátvétel befejezése után.

Azure-beli virtuális gépek

Az Azure-beli virtuális gépek (VM-ek) nem feladatátvételt a tárfiók feladatátvétele részeként. A feladatátvétel befejezése után újra létre kell hozni azokat a virtuális gépeket, amelyek egy másodlagos régióba bukott át a kimaradás miatt. A fiók feladatátvétele egy ideiglenes lemezen tárolt adatok elvesztését eredményezheti a virtuális gép (VM) leállásakor. A Microsoft azt javasolja, hogy kövesse az Azure-beli virtuális gépekre vonatkozó magas rendelkezésre állási és vészhelyreállítási útmutatást.

Azure nem felügyelt lemezek

A nem felügyelt lemezek lapblobokként vannak tárolva az Azure Storage-ban. Ha egy virtuális gép fut az Azure-ban, a rendszer a virtuális géphez csatlakoztatott nem felügyelt lemezeket bérli. A fiók feladatátvétele nem folytatható, ha bérlet van egy blobon. Mielőtt feladatátvételt kezdeményezhet az Azure-beli virtuális gépekhez csatlakoztatott nem felügyelt lemezeket tartalmazó fiókon, a lemezeket le kell állítani. Ezért a Microsoft ajánlott eljárásai közé tartozik a nem felügyelt lemezek felügyelt lemezekké alakítása.

Ha nem felügyelt lemezeket tartalmazó fiókon szeretne feladatátvételt végezni, kövesse az alábbi lépéseket:

  1. Mielőtt hozzákezdene, jegyezze fel a nem felügyelt lemezek nevét, azok logikai egységszámait (LUN) és azt a virtuális gépet, amelyhez csatlakoztatva vannak. Ez megkönnyíti a lemezek újraaktiválását a feladatátvétel után.
  2. Állítsa le a virtuális gépet.
  3. Törölje a virtuális gépet, de őrizze meg a nem felügyelt lemezek virtuális merevlemez-fájljait. Figyelje meg, hogy mikor törölte a virtuális gépet.
  4. Várjon, amíg az utolsó szinkronizálási idő frissül, és győződjön meg arról, hogy az későbbi, mint a virtuális gép törlésének időpontja. Ez a lépés biztosítja, hogy a másodlagos végpont teljes mértékben frissül a VHD-fájlokkal a feladatátvétel során, és hogy a virtuális gép megfelelően működve legyen az új elsődleges régióban.
  5. Indítsa el a fiók feladatátvételét.
  6. Várjon, amíg a fiók feladatátvétele befejeződött, és a másodlagos régió lesz az új elsődleges régió.
  7. Hozzon létre egy virtuális gépet az új elsődleges régióban, és helyezze újra a virtuális merevlemezeket.
  8. Indítsa el az új virtuális gépet.

Ne feledje, hogy az ideiglenes lemezen tárolt adatok elvesznek a virtuális gép leállásakor.

Adatok másolása feladatátvételi alternatívaként

Ahogy korábban említettem, a magas rendelkezésre állás fenntartásához konfigurálhatja az alkalmazásokat egy másodlagos régió olvasási hozzáférésére konfigurált tárfiók használatára. Ha azonban nem szeretne feladatátvételt végezni az elsődleges régión belüli leállások során, manuálisan is másolhatja az adatokat alternatívaként. Az olyan eszközök, mint az AzCopy és az Azure PowerShell , lehetővé teszik az adatok másolását az érintett régióban lévő tárfiókból egy másik, nem érintett régióbeli tárfiókba. A másolási művelet befejezése után újrakonfigurálhatja az alkalmazásokat úgy, hogy a tárfiókot a nem felügyelt régióban használja az olvasási és írási rendelkezésre állás érdekében.

Tervezés magas rendelkezésre álláshoz

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

Az Azure Storage-adatok magas rendelkezésre állásának fenntartásához tekintse meg az alábbi ajánlott eljárásokat:

Leállások nyomon követése

Az ügyfelek feliratkozhatnak az Azure Service Health irányítópultjára az Azure Storage és más Azure-szolgáltatások állapotának és állapotának nyomon követéséhez.

A Microsoft azt is javasolja, hogy úgy tervezze meg az alkalmazást, hogy fel legyen készülve az esetleges írási hibákra. 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.

Lásd még