Az ügyfél által felügyelt tárfiók feladatátvételének működése
Az Azure Storage-fiókok ügyfél által felügyelt feladatátvétele lehetővé teszi a teljes georedundáns tárfiók feladatátvételét a másodlagos régióba, ha az elsődleges régió tárolási szolgáltatásvégpontjai elérhetetlenné válnak. A feladatátvétel során az eredeti másodlagos régió lesz az új elsődleges, és a blobok, táblák, üzenetsorok és fájlok összes tárolási szolgáltatásvégpontja az új elsődleges régióba lesz átirányítva. A tárolási szolgáltatás végpontkimaradásának feloldása után egy másik feladatátvételi műveletet hajthat végre az eredeti elsődleges régióba való visszavételhez.
Ez a cikk azt ismerteti, hogy mi történik az ügyfél által felügyelt tárfiók feladatátvétele és feladat-visszavétele során a folyamat minden szakaszában.
Fontos
A hierarchikus névtérrel (Azure Data Lake Storage Gen2) rendelkező fiókok ügyfél által felügyelt 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.
Redundanciakezelés feladatátvétel és feladat-visszavétel során
Tipp.
A tárfiók feladatátvételi és feladat-visszavételi folyamata során előforduló különböző redundanciaállapotok részletes megismeréséhez tekintse meg az Azure Storage-redundancia definícióit.
Ha egy tárfiók GRS-hez vagy RA-GRS-redundanciához van konfigurálva, a rendszer háromszor replikálja az adatokat helyileg az elsődleges és a másodlagos régióban (LRS). Ha egy tárfiók GZRS-hez vagy RA-GZRS-replikációhoz van konfigurálva, az adatok zónaredundánsak az elsődleges régión (ZRS) belül, és háromszor replikálódnak helyileg a másodlagos régióban (LRS). Ha a fiók olvasási hozzáférésre (RA) van konfigurálva, akkor képes lesz adatokat olvasni a másodlagos régióból mindaddig, amíg a tárolási szolgáltatás végpontjai elérhetők az adott régióhoz.
Az ügyfél által felügyelt feladatátvételi folyamat során a tárolási szolgáltatásvégpontok DNS-bejegyzései úgy módosulnak, hogy a másodlagos régióhoz tartozók lesznek a tárfiók új elsődleges végpontjai. A feladatátvételt követően a rendszer törli a tárfiók másolatát az eredeti elsődleges régióban, és a tárfiókot továbbra is háromszor replikálja helyileg az eredeti másodlagos régióban (az új elsődleges régióban). Ekkor a tárfiók helyileg redundánssá (LRS) válik.
Az eredeti és az aktuális redundanciakonfigurációk a tárfiók tulajdonságaiban vannak tárolva, hogy a feladat-visszavételkor végül visszatérjen az eredeti konfigurációhoz.
A georedundancia feladatátvétel utáni helyreállításához újra kell konfigurálnia a fiókját GRS-ként. (A GZRS nem lehetőség a feladatátvétel után, mivel az új elsődleges az LRS lesz a feladatátvétel után). Miután a fiók újrakonfigurálva van a georedundancia számára, az Azure azonnal megkezdi az adatok másolását az új elsődleges régióból az új másodlagos régióba. Ha a tárfiókot olvasási hozzáférésre (RA) konfigurálja a másodlagos régióhoz, akkor ez a hozzáférés elérhető lesz, de eltarthat egy ideig, amíg az elsődlegesről replikálja a másodlagos áramot.
Figyelmeztetés
Miután a fiók georedundanciára van konfigurálva, jelentős ideig tarthat, amíg az új elsődleges régióban lévő meglévő adatok teljes mértékben át lesznek másolva az új másodlagos régióba.
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őpontkal a lehetséges adatvesztés kiértékelése érdekében.
A feladat-visszavételi folyamat lényegében ugyanaz, mint a feladatátvételi folyamat, kivéve, hogy az Azure visszaállítja a replikációs konfigurációt az eredeti állapotára a feladatátvétel előtt (a replikáció konfigurációja, nem az adatok). Ha tehát a tárfiók eredetileg GZRS-ként lett konfigurálva, a feladat-visszavétel utáni elsődleges régió ZRS lesz.
A feladat-visszavétel után konfigurálhatja, hogy a tárfiók ismét georedundáns legyen. Ha az eredeti elsődleges régió az LRS-hez lett konfigurálva, akkor grS vagy RA-GRS lehet. Ha az eredeti elsődleges ZRS-ként lett konfigurálva, akkor GZRS-nek vagy RA-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.
Feladatátvétel kezdeményezése
A feladatátvétel indításáról további információt a tárfiók feladatátvételének kezdeményezése című témakörben talál.
Figyelem
A tárfiók feladatátvétele általában némi adatvesztést, esetleg fájl- és adatkonzisztenciát von maga után. Fontos tisztában lenni azzal, hogy a fiók feladatátvétele milyen hatással lenne az adataira, mielőtt elindítaná azt.
A lehetséges adatvesztéssel és inkonzisztenciákkal kapcsolatos részletekért lásd : Várható adatvesztés és inkonzisztenciák.
A feladatátvételi és feladat-visszavételi folyamat
Ez a szakasz az ügyfél által felügyelt feladatátvétel feladatátvételi folyamatát foglalja össze.
Feladatátvételi áttűnések összegzése
Ügyfél által felügyelt feladatátvétel után:
- A másodlagos régió lesz az új elsődleges régió
- Az eredeti elsődleges régió adatainak másolata törlődik
- A tárfiók LRS-sé alakul
- A georedundancia elvész
Ez a táblázat az ügyfél által felügyelt feladatátvétel és feladat-visszavétel minden szakaszában összefoglalja az eredményként kapott redundanciakonfigurációt:
| 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 |
|---|---|---|---|---|
| GRS | LRS | GRS 1 | LRS | GRS 1 |
| GZRS | LRS | GRS 1 | ZRS | GZRS 1 |
1 A georedundancia elveszik egy ügyfél által felügyelt feladatátvétel során, és manuálisan kell újrakonfigurálni.
Feladatátvételi áttűnés részletei
Az alábbi ábrák azt mutatják be, hogy mi történik az ügyfél által felügyelt feladatátvétel és a georedundanciára konfigurált tárfiók feladat-visszavétele során. A GZRS és az RA-GZRS áttűnési részletei kissé eltérnek a GRS-től és az RA-GRS-től.
Normál művelet (GRS/RA-GRS)
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 a tárolási szolgáltatás végpontjaival (1). Az adatok ezután aszinkron módon lesznek átmásolva az elsődleges régióból a másodlagos régióba (2). Az alábbi képen egy GRS-ként konfigurált tárfiók normál állapota látható, amikor az elsődleges végpontok elérhetők:
A tárolási szolgáltatás végpontjai elérhetetlenné válnak az elsődleges régióban (GRS/RA-GRS)
Ha az elsődleges tárolási szolgáltatás végpontjai bármilyen okból elérhetetlenné válnak (1), az ügyfél már nem tud írni a tárfiókba. A kimaradás kiváltó okától függően előfordulhat, hogy a másodlagos régióba történő replikáció már nem működik (2), ezért némi adatvesztésre kell számítani. Az alábbi képen az a forgatókönyv látható, amelyben az elsődleges végpontok elérhetetlenné váltak, de még nem történt helyreállítás:
A feladatátvételi folyamat (GRS/RA-GRS)
Az adatok írási hozzáférésének visszaállításához feladatátvételt kezdeményezhet. A blobokhoz, táblákhoz, üzenetsorokhoz és fájlokhoz tartozó tárolási szolgáltatásvégpont URI-k változatlanok maradnak, de a DNS-bejegyzéseik a képen látható másodlagos régióra (1) mutatnak:
Az ügyfél által felügyelt feladatátvétel általában körülbelül egy órát vesz igénybe.
A feladatátvétel befejezése után az eredeti másodlagos lesz az új elsődleges (1), és az eredeti elsődleges tárfiók másolata törlődik (2). A tárfiók LRS-ként van konfigurálva az új elsődleges régióban, és már nem georedundáns. A felhasználók folytathatják az adatok írását a tárfiókba (3) a képen látható módon:
Ha egy új másodlagos régióba szeretné folytatni a replikációt, konfigurálja újra a fiókot a georedundancia érdekében.
Fontos
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 feladatátvétel időpontja és költsége.
A fiók GRS-ként való újrakonfigurálása után az Azure megkezdi az adatok aszinkron másolását az új másodlagos régióba (1) a képen látható módon:
Az olvasási hozzáférés az új másodlagos régióhoz csak akkor válik elérhetővé, ha az eredeti kimaradást okozó probléma megoldódott.
A feladat-visszavételi folyamat (GRS/RA-GRS)
Figyelmeztetés
Miután a fiók újrakonfigurálva van a georedundanciához, jelentős ideig tarthat, amíg az új elsődleges régió adatai teljes mértékben át lesznek másolva az új másodlagos régióba.
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őpontkal a lehetséges adatvesztés kiértékelése érdekében.
Az eredeti kimaradást okozó probléma megoldása után kezdeményezhet egy másik feladatátvételt az eredeti elsődleges régióba való visszavételhez, ami a következőket eredményezi:
- Az aktuális elsődleges régió csak olvashatóvá válik.
- Az ügyfél által kezdeményezett feladatátvétel és feladat-visszavétel esetén az adatok nem fejezhetnek be replikálást a másodlagos régióba a feladat-visszavételi folyamat során. Ezért fontos ellenőrizni a Legutóbbi szinkronizálási idő tulajdonság értékét, mielőtt visszabukik.
- A tárolási szolgáltatásvégpontok DNS-bejegyzései úgy módosulnak, hogy a másodlagos régióhoz tartozók lesznek a tárfiók új elsődleges végpontjai.
A feladat-visszavétel befejezése után az eredeti elsődleges régió lesz ismét az aktuális (1), és az eredeti másodlagos tárfiók másolata törlődik (2). A tárfiók helyileg redundánsként van konfigurálva az elsődleges régióban, és már nem georedundáns. A felhasználók folytathatják az adatok írását a tárfiókba (3) a képen látható módon:
Ha folytatni szeretné a replikációt az eredeti másodlagos régióba, konfigurálja újra a georedundáns fiókot.
Fontos
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 feladatátvétel időpontja és költsége.
A fiók GRS-ként való újrakonfigurálása után az eredeti másodlagos régióba történő replikáció folytatódik, ahogyan az a képen látható:
