Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Az ügyfél által felügyelt nem tervezett feladatátvétel 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 régió. Ezután a rendszer az összes tárolási szolgáltatásvégpontot átirányítja az új elsődleges régióba. A tárolási szolgáltatás végpontkimaradásának elhárítása után ismét végrehajthat egy feladatátviteli műveletet az eredeti elsődleges régióba való visszaálláshoz.
Ez a cikk azt ismerteti, hogy mi történik az ügyfél által felügyelt, nem tervezett feladatátvétel és feladat-visszavétel során a folyamat minden szakaszában.
Redundanciakezelés a nem tervezett feladatátvétel és feladat-visszavétel során
Tipp.
A nem tervezett feladatátvételi és feladat-visszavételi folyamat során a különböző redundanciaállapotok részletes megismeréséhez tekintse meg az Azure Storage redundanciával kapcsolatos definícióit.
Az adatok régiónként háromszor replikálódnak a georedundáns tárolásra (GRS) vagy az olvasási hozzáférés georedundáns tárolásra (RA-GRS) konfigurált tárfiókok esetében. Ez a megközelítés azt jelenti, hogy a replikáció az elsődleges és a másodlagos régión belül is megtörténik. Minden régió alapvetően helyileg redundáns (LRS), és az adatok három példányát tartalmazza.
Ha egy tárfiók geo-zónaredundáns tárolásra (GZRS) vagy olvasási hozzáférésű geo-zónaredundáns tárolásra (RA-GZRS) van konfigurálva, az adatok zónaredundánsak a zónaredundáns tárolás (ZRS) elsődleges régióján belül, és háromszor replikálódnak az LRS másodlagos régión belül. Ha a fiók olvasási hozzáférésre (RA) van konfigurálva, a másodlagos régióból is beolvashatja az adatokat, 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, nem tervezett feladatátvételi folyamat során a társzolgáltatás-végpontok tartománynévrendszer-bejegyzései (DNS) váltanak. A tárfiók másodlagos végpontjai lesznek az új elsődleges végpontok, és az eredeti elsődleges végpontok lesznek az új másodlagos végpontok. A feladatátvétel után 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 új elsődleges régióban. Ekkor a tárfiók helyileg redundánssá válik, és LRS-t használ.
Az eredeti és az aktuális redundanciakonfigurációk a tárfiók tulajdonságaiban vannak tárolva. Ez a funkció lehetővé teszi, hogy visszaálláskor visszatérjen az eredeti konfigurációhoz. Az eredményként kapott redundanciakonfigurációk teljes listájáért olvassa el a helyreállítási tervezést és a feladatátvételt.
A georedundancia feladatátvétel utáni helyreállításához a fiókját GRS-re kell átkonfigurálnia. 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 a másodlagos régióhoz való olvasási hozzáféréshez konfigurálja, akkor ez a hozzáférés elérhető. Az elsődleges régióból a másodlagos régióba történő replikáció azonban eltarthat egy ideig.
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.
Egy jelentős adatvesztés elkerülése érdekében ellenőrizze a Legutóbbi szinkronizálási idő tulajdonság értékét, mielőtt visszaállítást végezne. A lehetséges adatvesztés kiértékeléséhez hasonlítsa össze az utolsó szinkronizálási időt az új elsődlegesbe való írás utolsó időpontjával.
A visszaállási folyamat lényegében megegyezik a feladatátvételi folyamattal, azzal a különbséggel, hogy a replikációs konfiguráció visszaáll az eredeti, a feladatátvétel előtti állapotába.
Visszaállás után újrakonfigurálhatja a tárfiókját, hogy kihasználhassa a georedundancia előnyeit. Ha az eredeti elsődleges ZRS-ként van konfigurálva, akkor később átkonfigurálható GZRS-re vagy RA-GZRS-re. További lehetőségekért lásd : Tárfiók replikálás módjának módosítása.
Nem tervezett feladatátvétel kezdeményezése
Ha szeretné megtudni, hogyan kezdeményezhet nem tervezett feladatátvételt, olvassa el a fiók feladatátvételének kezdeményezése című témakört.
Figyelemfelhívás
A nem tervezett feladatátvétel általában némi adatvesztést, valamint fájl- és adatinkonzisztenciákat vonhat maga után. Fontos tisztában lenni azzal, hogy egy fiók átállása milyen hatással lenne az adataira, mielőtt elkezdené az ilyen típusú átállást.
A lehetséges adatvesztéssel és inkonzisztenciákkal kapcsolatos részletekért lásd : Várható adatvesztés és inkonzisztenciák.
A nem tervezett feladatátvételi és feladat-visszavételi folyamat
Ez a szakasz az ügyfél által felügyelt nem tervezett feladatátvételi folyamatot foglalja össze.
Nem tervezett átkapcsolási folyamat összefoglalása
Ügyfél által felügyelt, nem tervezett 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 nem tervezett feladatátvétel és feladat-visszavétel minden szakaszában összefoglalja az eredményül 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, nem tervezett feladatátvétel során, és manuálisan kell újrakonfigurálni.
Nem tervezett átkapcsolás részletei
Az alábbi ábrák a georedundanciára konfigurált tárfiók ügyfél által felügyelt nem tervezett feladatátvételi és feladat-visszavételi folyamatát mutatják be. A GZRS és az RA-GZRS átmeneti részletei kissé különböznek a GRS és az RA-GRS részleteitő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ó, amikor az elsődleges végpontok elérhetetlenné válnak, de a helyreállítás előtt:
A nem tervezett 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 blobok, táblák, üzenetsorok és fájlok tárolási szolgáltatásvégpontjai változatlanok maradnak, de a DNS-bejegyzéseik a másodlagos régióra mutatnak az ábrán látható módon:
Az ügyfél által felügyelt nem tervezett 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.
Miután újrakonfigurálta a fiókot a GRS használatára, az Azure megkezdi az adatok aszinkron másolását az új másodlagos régióba (1), ahogyan az a képen látható:
Az új másodlagos régió olvasási hozzáférése nem érhető el újra, amíg az eredeti kimaradást okozó probléma meg nem oldódik.
A nem tervezett visszaállítási folyamat (GRS/RA-GRS)
Figyelmeztetés
Miután a fiók georedundánsként újrakonfigurálva van, 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.
Egy jelentős adatvesztés elkerülése érdekében ellenőrizze a Legutóbbi szinkronizálási idő tulajdonság értékét, mielőtt visszaállítást végezne. 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ényezheti a helyreállítást az eredeti elsődleges régióba. A visszaállási folyamat megegyezik az eredeti átváltási folyamat korábban ismertetett módszerével.
Fontos tudnivalók:
- 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 visszaáll.
- A tárolási szolgáltatásvégpontok DNS-bejegyzései át lesznek kapcsolva. A másodlagos régión belüli végpontok lesznek a tárfiók új elsődleges végpontjai.
A visszaállás befejezése után az eredeti elsődleges régió lesz ismét az aktuális (1), és az eredeti másodlagos régió tárfiókjának 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:
Az eredeti másodlagos régióba történő replikáció folytatásához 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 a replikáció folytatódik az eredeti másodlagos régióba a képen látható módon:
