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

Az Azure Storage katasztrófa-helyreállítási tervezése és átállása

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 georedundáns tárfiókok számára 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.

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

A georedundáns tárolás (GRS), a geozónás-redundáns tárolás (GZRS) és az olvasási hozzáférésű geozónás-redundáns tárolás (RA-GZRS) példák a földrajzilag redundáns tárolási lehetőségekre. Georedundáns tárolás (GRS, GZRS és RA-GZRS) használatára 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-vel ellentétben a georedundá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égpontokhoz.

Az olvasási hozzáférésű georedundáns tárolás (RA-GRS) és az olvasási hozzáférésű geo-zónaredundáns tárolás (RA-GZRS) szintén georedundáns tárolást biztosítanak, de további előnyként kínálják a másodlagos végponthoz való olvasási hozzáférést. 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.

Átállási terv kidolgozása

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ámaszkodj a Microsoft által felügyelt feladatátvételre, amelyet csak szélsőséges körülmények között lenne használva.

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 (Azure Data Lake Storage) támogatásával rendelkezik. Ez a táblázat a feladatátvétel egyes típusainak ezeket a szempontjait foglalja össze:

Típus Átjárási hatókör Használati eset Várható adatvesztés Támogatott a hierarchikus névtér (HNS)
Ügyfél által felügyelt tervezett feladatátvétel (előzetes verzió) Tárolófió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 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) rendszerváltás Tárolófió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
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:

Átállás eredménye... Ügyfél által felügyelt tervezett feladatátvétel (előzetes verzió) Ügyfél által felügyelt (nem tervezett) rendszerváltás
... 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
visszaállítás		 Újraengedélyezés után
georedundancia
Ügyfél által felügyelt tervezett átállás
GRS GRS n/a 1 GRS n/a 1
GZRS GRS n/a 1 GZRS n/a 1
Ügyfél által felügyelt (nem tervezett) feladatátvétel
GRS LRS GRS LRS GRS
GZRS LRS GRS ZRS GZRS

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

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

A tervezett átállás több forgatókönyvben is használható, beleértve a tervezett katasztrófa-helyreá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ással kapcsolatos kimaradá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ó elveszíti elsődlegességét, és ú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.

Fontos

A felhasználói visszajelzések beépülnek az ügyfél által felügyelt tervezett feladatátvételbe (előzetes verzió), és a funkció ideiglenesen nem érhető el minden régióban. A befejezés után a frissített dokumentáció azokat a régiókat tükrözi, amelyekben a szolgáltatás elérhető.

Ügyfél által felügyelt (nem tervezett) rendszerváltás

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 katasztrofális katasztrófa esetén, amely egy teljes georégiót érint. 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ámaszkodjon a Microsoft által felügyelt feladatátvételre, mivel az csak szélsőséges körülmények között használható. A Microsoft által felügyelt feladatátvétel egy teljes fizikai egység, például egy régió vagy egy adatközpont esetében indulna el. 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ókváltás milyen hatással lenne az adatokra, mielőtt megkezdené azt.

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 adatinkonzisztenciát is tapasztalhat, ha a tárfiókoknál az alábbi lehetőségek közül egy vagy több engedélyezve van:

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 fájlkonzisztenciája

A hierarchikus névtérrel (Azure Data Lake Storage) rendelkező tárfiókok 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 konténerben vagy a 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) átsévelése inkonzisztenciát okozhat a változáscsatornanaplók, valamint a blob adatai és/vagy metaadatai 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 kezelt 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á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.

Az átkapcsolás 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óhoz rendelkezésre álló 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 szolgáltatás támogatja a Microsoft által kezelt feladatátvételt. Emellett egyes fióktípusok támogatják az ügyfél által felügyelt fiókok átvételét, ahogy az alábbi táblázat mutatja.

Átállás típusa GRS/RA-GRS GZRS/RA-GZRS
Ü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
Ü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
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 jogosultakká váljanak az ügyfél által kezelt fiókok átvételére, először át kell őket migrálni az ARM-modellre. 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 átváltásá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 kezelt fiók feladatátvételét. Az Azure File Sync felhőalapú végpontjaként használt tárfiókokat nem szabad átvitelre állítani. Átállás megszakítja a fájlszinkronizálást, és váratlan adatvesztést okozhat az újonnan rétegzett fájlok esetében. 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 állítható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 átállásához. Nem hozható létre georedundáns tároláshoz konfigurált tárfiók, ha engedélyezve van az NFSv3.

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

Tervezett átállás Nem tervezett átállás
Azure Data Lake Storage Támogatott (előzetes verzió) Támogatott
Hírcsatorna módosítása Nem támogatott Támogatott
Objektumreplikálás Nem támogatott Nem támogatott
SFTP Támogatott (előzetes verzió) Támogatott
NFSv3 A GRS nem támogatott A GRS nem támogatott
Tárolási műveletek Támogatott1 Támogatott1
Időponthoz kötött visszaállítás (PITR) Nem támogatott Támogatott

1 Ha ügyfél által felügyelt tervezett vagy nem tervezett feladatátvételt kezdeményez, a tárolási feladatok addig nem működnek a fiókon, amíg vissza nem lép az eredeti elsődleges régióba. További információ.

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

A tárfiók feladatátvétele ideiglenes megoldás a vészhelyreállítási (DR) tervek fejlesztésére és tesztelésére, illetve szolgáltatáskimaradásból való helyreállításra. Az átállás ne legyen használva 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 beolvashatják és megírhatják az Azure Storage-adatokat az új elsődleges régióban. Az Azure Storage-erőforrás-szolgáltató azonban nem hajtja végre 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 tudja végrehajtani a felügyeleti műveleteket 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 vesznek részt a tárfiók feladatátvitelében. 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 áthelyezésre kerültek 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.

Felügyelet nélküli Azure-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 átállása nem folytatható, ha bérleti szerződés 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 újra csatlakoztatá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 átváltásá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, mint feladatátvételi megoldás

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:

  • Lemezek: Az Azure Backup használatával készítsen biztonsági másolatot az Azure-beli virtuális gépek által használt virtuálisgép-lemezekről. Fontolja meg az Azure Site Recovery használatát is, hogy megvédje a virtuális gépeket egy regionális katasztrófa ellen.
  • Blokkblobok: Kapcsolja be a helyreállítható törlést az objektumszintű törlés és felülírás elleni védelemhez, vagy másolja a blokkblobokat egy másik régióban lévő tárfiókba az AzCopy, az Azure PowerShell vagy az Azure Data Movement könyvtár használatával.
  • Fájlokat: Az Azure Backup használatával biztonsági másolatot készít a fájlmegosztásokról. Engedélyezze a helyreállítható törlést is, hogy védelmet nyújthasson a véletlen fájlmegosztás-törlésekkel szemben. Georedundancia esetén, ha a GRS nem érhető el, az AzCopy vagy az Azure PowerShell használatával másolhatja a fájlokat egy másik régióban lévő tárfiókba.
  • Táblázatok: Az AzCopy használatával táblázatadatokat exportálhat egy másik régióban lévő másik tárfiókba.

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