Redundancia az Azure Storage szolgáltatásban

Az Azure Storage mindig több példányban tárolja az adatokat, hogy azok védve legyen a tervezett és nem tervezett eseményektől, beleértve az átmeneti hardverhibákat, a hálózati vagy áramkimaradásokat és a súlyos természeti katasztrófákat. A redundancia biztosítja, hogy a tárfiók a hibák esetén is megfeleljen a rendelkezésre állási és tartóssági céloknak.

Amikor eldönti, hogy melyik redundancialehetőség a legmegfelelőbb az Ön forgatókönyvéhez, vegye figyelembe az alacsonyabb költségek és a magasabb rendelkezésre állás közötti kompromisszumot. Az alábbi tényezők segítenek meghatározni, hogy melyik redundanciabeállítást válassza:

  • Az adatok replikálása az elsődleges régióban.
  • Azt, hogy az adatok replikálva legyenek-e egy második régióba, amely földrajzilag távol van az elsődleges régiótól, a regionális katasztrófák (georeplikáció) elleni védelem érdekében.
  • Azt határozza meg, hogy az alkalmazás olvasási hozzáférést igényel-e a másodlagos régióban lévő replikált adatokhoz, ha az elsődleges régió valamilyen okból elérhetetlenné válik (georeplikáció olvasási hozzáféréssel).

Megjegyzés

A cikkben ismertetett szolgáltatások és regionális rendelkezésre állás a hierarchikus névtérrel (Azure Blob Storage) rendelkező fiókok számára is elérhetők.

Az Azure Storage-t alkotó szolgáltatásokat egy közös Azure-erőforrás, az úgynevezett tárfiók kezeli. A tárfiók egy megosztott tárolókészlet, amely tárolóerőforrások, például blobtárolók (Blob Storage), fájlmegosztások (Azure Files), táblák (Table Storage) vagy üzenetsorok (Queue Storage) üzembe helyezésére használható. További információ az Azure Storage-fiókokról: Tárfiókok áttekintése.

A tárfiók redundanciabeállítása az adott fiók által közzétett összes tárolási szolgáltatás esetében meg van osztva. Az ugyanabban a tárfiókban üzembe helyezett összes tárolási erőforrás ugyanazzal a redundanciával rendelkezik. Különböző típusú erőforrásokat külön tárfiókokban érdemes elkülöníteni, ha eltérő redundanciára vonatkozó követelményekkel rendelkeznek.

Redundancia az elsődleges régióban

Az Azure Storage-fiók adatainak replikálása mindig háromszor történik az elsődleges régióban. Az Azure Storage két lehetőséget ajánl fel az adatok replikálási módjaként az elsődleges régióban.

  • A helyileg redundáns tárolás (LRS) háromszor szinkronizálja az adatokat egyetlen fizikai helyen az elsődleges régióban. Az LRS a legkevésbé költséges replikációs lehetőség, de magas rendelkezésre állást vagy tartósságot igénylő alkalmazásokhoz nem ajánlott.
  • A zónaredundáns tárolás (ZRS) szinkron módon másolja az adatokat három Azure rendelkezésre állási zónába az elsődleges régióban. A magas rendelkezésre állást igénylő alkalmazások esetében a Microsoft a ZRS használatát javasolja az elsődleges régióban, valamint egy másodlagos régióba való replikálást.

Megjegyzés

A Microsoft a ZRS használatát javasolja az elsődleges régióban Azure Data Lake Storage Gen2 számítási feladatokhoz.

Helyileg redundáns tárolás

A helyileg redundáns tárolás (LRS) háromszor replikálja a tárfiókot egyetlen adatközpontban az elsődleges régióban. Az LRS legalább 99,999999999999%-os (11 kilences) tartósságot biztosít az objektumoknak egy adott évben.

Az LRS a legalacsonyabb költségű redundancia lehetőség, és a többi lehetőséghez képest a legkevésbé tartósságot nyújtja. Az LRS megvédi az adatokat a kiszolgálóállvány- és meghajtóhibáktól. Ha azonban katasztrófa, például tűz vagy árvíz történik az adatközpontban, előfordulhat, hogy egy tárfiók LRS-t használó replikái elvesznek vagy helyreállíthatatlanok lesznek. A kockázat csökkentése érdekében a Microsoft a zónaredundáns tárolás (ZRS), a georedundáns tárolás (GRS) vagy a georedundáns tárolás (GZRS) használatát javasolja.

Az LRS-t használó tárfiókra irányuló írási kérések szinkron módon történnek. Az írási művelet csak akkor ad vissza sikeresen, ha mind a három replikára meg van írva az adat.

Az alábbi diagram bemutatja, hogyan replikálja az adatokat egyetlen adatközpontban az LRS használatával:

Diagram, amely bemutatja, hogyan replikálja az adatokat egyetlen adatközpontban az LRS használatával

Az LRS a következő forgatókönyvekhez jó választás:

  • Ha az alkalmazás olyan adatokat tárol, amelyek könnyen rekonstruálhatók adatvesztés esetén, választhatja az LRS-t.
  • Ha az alkalmazás az adatszabályozási követelmények miatt csak egy országon vagy régión belül replikálja az adatokat, választhatja az LRS-t. Bizonyos esetekben az adatok földrajzilag replikált párosított régiói egy másik országban vagy régióban lehetnek. További információ a párosított régiókról: Azure-régiók.
  • Ha a forgatókönyv nem felügyelt Azure-lemezeket használ, választhatja az LRS-t. Bár létrehozhat egy tárfiókot az Azure nem felügyelt, GRS-t használó lemezeihez, az aszinkron georeplikáció konzisztenciájával kapcsolatos lehetséges problémák miatt nem ajánlott.

Zónaredundáns tárolás

A zónaredundáns tárolás (ZRS) szinkron módon replikálja a tárfiókot három Azure rendelkezésre állási zónában az elsődleges régióban. Minden rendelkezésreállási zóna egy fizikailag elkülönített, független áramforrással, hűtéssel és hálózatkezelési megoldással rendelkező hely. A ZRS tartósságot biztosít legalább 99,99999999999%-os (12 9-es) tárolási erőforrásokhoz egy adott évben.

A ZRS-ben az adatok akkor is elérhetők az olvasási és írási műveletekhez, ha egy zóna elérhetetlenné válik. Ha egy zóna elérhetetlenné válik, az Azure hálózatkezelési frissítéseket hajt végre, például DNS-újrapontozást. Ezek a frissítések hatással lehetnek az alkalmazásra, ha a frissítések befejeződése előtt fér hozzá az adatokhoz. A ZRS-alkalmazások tervezésekor kövesse az átmeneti hibakezelés gyakorlatát, beleértve az újrapróbálkozási szabályzatok exponenciális visszalépéssel történő implementálását.

A ZRS-t használó tárfiókra irányuló írási kérések szinkron módon történnek. Az írási művelet csak akkor ad vissza sikeresen, ha az adatok a három rendelkezésre állási zónában lévő összes replikára íródtak.

A Microsoft a ZRS használatát javasolja az elsődleges régióban a magas rendelkezésre állást igénylő forgatókönyvekhez. A ZRS azt is javasoljuk, hogy az adatreplikálást egy adott országba vagy régióba korlátozza az adatszabályozási követelményeknek való megfelelés érdekében.

A Microsoft a ZRS használatát javasolja Azure Files számítási feladatokhoz. Ha egy zóna elérhetetlenné válik, nincs szükség az Azure-fájlmegosztások újracsatlakoztatására a csatlakoztatott ügyfelekről.

Az alábbi diagram bemutatja, hogyan replikálja az adatokat a rendszer az elsődleges régió rendelkezésre állási zónái között a ZRS használatával:

Ábra az adatok az elsődleges régióban való replikálásáról ZRS használatával

A ZRS kiváló teljesítményt, alacsony késést és rugalmasságot biztosít az adatok számára, ha azok átmenetileg elérhetetlenné válnak. Előfordulhat azonban, hogy a ZRS önmagában nem védi meg az adatokat egy olyan regionális katasztrófa ellen, amely több zónát érint véglegesen. A regionális katasztrófák elleni védelem érdekében a Microsoft a földrajzi zónaredundáns tárolás (GZRS) használatát javasolja, amely ZRS-t használ az elsődleges régióban, és georeplikálja az adatokat egy másodlagos régióba.

A Blob Storage archív szintje jelenleg nem támogatott ZRS-, GZRS- vagy RA-GZRS-fiókok esetében. A nem felügyelt lemezek nem támogatják a ZRS-t vagy a GZRS-t.

További információ arról, hogy mely régiók támogatják a ZRS-t, lásd: Rendelkezésre állási zónákkal rendelkező Azure-régiók.

Standard szintű tárfiókok

A ZRS minden Azure Storage-szolgáltatás esetében támogatott standard általános célú v2-tárfiókokon keresztül, beleértve a következőket:

  • Azure Blob Storage (gyakori és ritka elérésű blokkblobok és hozzáfűző blobok, nem lemezes lapblobok)
  • Azure Files (minden standard szint: tranzakcióoptimalizált, gyakori és ritka elérésű)
  • Azure Table Storage
  • Azure Queue Storage

A standard általános célú v2-tárfiókokhoz készült ZRS az Azure-régiók egy részhalmazához érhető el:

  • (Afrika) Dél-Afrika északi régiója
  • (Ázsia és a Csendes-óceáni térség) Kelet-Ausztrália
  • (Ázsia és a Csendes-óceáni térség) Közép-India
  • (Ázsia és a Csendes-óceáni térség) Kelet-Ázsia
  • (Ázsia és a Csendes-óceáni térség) Kelet-Japán
  • (Ázsia és a Csendes-óceáni térség) Korea középső régiója
  • (Ázsia és a Csendes-óceáni térség) Délkelet-Ázsia
  • (Európa) Közép-Franciaország
  • (Európa) Németország nyugati középső régiója
  • (Európa) Észak-Európa
  • (Európa) Kelet-Norvégia
  • (Európa) Közép-Svédország
  • (Európa) Észak-Svájc
  • (Európa) Egyesült Királyság déli régiója
  • (Európa) Nyugat-Európa
  • (Közel-Kelet) Katar középső régiója
  • (Közel-Kelet) Egyesült Arab Emírségek északi régiója
  • (Észak-Amerika) Közép-Kanada
  • (Észak-Amerika) USA középső régiója
  • (Észak-Amerika) USA keleti régiója
  • (Észak-Amerika) USA 2. keleti régiója
  • (Észak-Amerika) USA déli középső régiója
  • (Észak-Amerika) US Gov Virginia
  • (Észak-Amerika) USA 2. nyugati régiója
  • (Észak-Amerika) USA 3. nyugati régiója
  • (Dél-Amerika) Dél-Brazília

Prémium szintű blokkblobfiókok

A ZRS a prémium szintű blokkblobfiókok esetében támogatott. A prémium szintű blokkblobokkal kapcsolatos további információkért lásd: Prémium szintű blokkblobtároló-fiókok.

A prémium szintű blokkblobok az Azure-régiók egy részhalmazában érhetők el:

  • (Ázsia és a Csendes-óceáni térség) Kelet-Ausztrália
  • (Ázsia és a Csendes-óceáni térség) Kelet-Ázsia
  • (Ázsia és a Csendes-óceáni térség) Kelet-Japán
  • (Ázsia és a Csendes-óceáni térség) Délkelet-Ázsia
  • (Európa) Közép-Franciaország
  • (Európa) Észak-Európa
  • (Európa) Nyugat-Európa
  • (Európa) Egyesült Királyság déli régiója
  • (Észak-Amerika) USA keleti régiója
  • (Észak-Amerika) USA 2. keleti régiója
  • (Észak-Amerika) USA 2. nyugati régiója
  • (Észak-Amerika) USA déli középső régiója
  • (Dél-Amerika) Dél-Brazília

Prémium szintű fájlmegosztási fiókok

A ZRS a tárfiók típusán keresztül FileStorage támogatja a prémium szintű fájlmegosztásokat (Azure Files).

A prémium szintű fájlmegosztásokhoz készült ZRS az Azure-régiók egy részhalmazához érhető el:

  • (Ázsia és a Csendes-óceáni térség) Kelet-Ausztrália
  • (Ázsia és a Csendes-óceáni térség) Kelet-Japán
  • (Ázsia és a Csendes-óceáni térség) Délkelet-Ázsia
  • (Ázsia és a Csendes-óceáni térség) Korea középső régiója
  • (Európa) Közép-Franciaország
  • (Európa) Észak-Európa
  • (Európa) Nyugat-Európa
  • (Európa) Egyesült Királyság déli régiója
  • (Közel-Kelet) Katar középső régiója
  • (Észak-Amerika) USA keleti régiója
  • (Észak-Amerika) USA 2. keleti régiója
  • (Észak-Amerika) USA 2. nyugati régiója
  • (Észak-Amerika) USA déli középső régiója
  • (Dél-Amerika) Dél-Brazília

Redundancia egy másodlagos régióban

A magas tartósságot igénylő alkalmazások esetében dönthet úgy, hogy a tárfiókban lévő adatokat egy másodlagos régióba másolja, amely több száz kilométerre van az elsődleges régiótól. Ha a tárfiókot egy másodlagos régióba másolja, akkor az adatok akkor is tartósak lesznek, ha teljes regionális kimaradás vagy katasztrófa esetén az elsődleges régió nem állítható helyre.

Tárfiók létrehozásakor ki kell választania a fiók elsődleges régióját. A párosított másodlagos régió az elsődleges régió alapján van meghatározva, és nem módosítható. Az Azure által támogatott régiókkal kapcsolatos további információkért lásd: Azure-régiók.

Az Azure Storage két lehetőséget kínál az adatok másodlagos régióba való másolására:

  • A Georedundáns tárolás (GRS) az adatokat szinkron módon, az LRS használatával háromszor másolja le az elsődleges régió egy fizikai helyére. Ezután aszinkron módon másolja át az adatokat a másodlagos régió egy fizikai helyére. A másodlagos régión belül az adatok másolása szinkron módon háromszor történik az LRS használatával.
  • A geo-zónaredundáns tárolás (GZRS) szinkron módon másolja az adatokat az elsődleges régió három rendelkezésre állási zónájában a ZRS használatával. Ezután aszinkron módon másolja át az adatokat a másodlagos régió egy fizikai helyére. A másodlagos régión belül az adatok másolása szinkron módon háromszor történik az LRS használatával.

Megjegyzés

A GRS és a GZRS közötti elsődleges különbség az adatok replikálása az elsődleges régióban. A másodlagos régión belül az adatok szinkronizálása mindig háromszor történik az LRS használatával. A másodlagos régióban az LRS megvédi az adatokat a hardverhibáktól.

GRS vagy GZRS esetén a másodlagos régióban lévő adatok csak akkor érhetők el olvasási vagy írási hozzáféréshez, ha feladatátvétel történt az elsődleges régióba. A másodlagos régióhoz való olvasási hozzáféréshez konfigurálja a tárfiókot írásvédett georedundáns tárolás (RA-GRS) vagy írásvédett geo-zónaredundáns tárolás (RA-GZRS) használatára. További információ: Olvasási hozzáférés az adatokhoz a másodlagos régióban.

Ha az elsődleges régió elérhetetlenné válik, dönthet úgy, hogy átadja a feladatátvételt a másodlagos régiónak. A feladatátvétel befejezése után a másodlagos régió lesz az elsődleges régió, és ismét olvashat és írhat adatokat. A vészhelyreállítással és a másodlagos régióba történő feladatátvétellel kapcsolatos további információkért lásd: Vészhelyreállítás és tárfiók feladatátvétele.

Fontos

Mivel az adatok aszinkron módon replikálódnak a másodlagos régióba, 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özt helyreállításipont-célkitűzésnek (RPO) nevezzük. Az RPO azt az időpontot jelzi, ahová az adatok helyreállíthatók. Az Azure Storage platform általában 15 percnél rövidebb RPO-val rendelkezik, bár jelenleg nincs SLA arról, hogy mennyi ideig tart az adatok replikálása a másodlagos régióba.

Georedundáns tárolás

A Georedundáns tárolás (GRS) az adatokat szinkron módon, az LRS használatával háromszor másolja le az elsődleges régió egy fizikai helyére. Ezután aszinkron módon másolja az adatokat egyetlen fizikai helyre egy másodlagos régióban, amely több száz kilométerre van az elsődleges régiótól. A GRS legalább 99,999999999999%-os (16 9-es) tárolási erőforrások tartósságát kínálja egy adott évben.

Az írási művelet először az elsődleges helyre lesz véglegesítve, és az LRS használatával replikálódik. A frissítés ezután aszinkron módon lesz replikálva a másodlagos régióba. Amikor az adatok a másodlagos helyre kerülnek, azokat az LRS használatával is replikálja a rendszer ezen a helyen.

Az alábbi ábrán az adatok GRS vagy RA-GRS használatával történő replikálása látható:

Ábra az adatok GRS vagy RA-GRS használatával történő replikálásáról

Zóna- és georedundáns tárolás

A geo-zónaredundáns tárolás (GZRS) egyesíti a rendelkezésre állási zónák redundanciái által biztosított magas rendelkezésre állást a georeplikáció által biztosított regionális kimaradások elleni védelemmel. A GZRS-tárfiókban lévő adatok az elsődleges régióban található három Azure rendelkezésre állási zónában lesznek átmásolva, és egy másodlagos földrajzi régióba is replikálódnak a regionális katasztrófák elleni védelem érdekében. A Microsoft a GZRS használatát javasolja a maximális konzisztenciát, tartósságot és rendelkezésre állást, kiváló teljesítményt és rugalmasságot igénylő alkalmazásokhoz a vészhelyreállításhoz.

GZRS-tárfiókkal továbbra is olvashat és írhat adatokat, ha egy rendelkezésre állási zóna elérhetetlenné válik vagy helyreállíthatatlanná válik. Emellett az adatok tartósak is egy teljes regionális kimaradás vagy katasztrófa esetén, amelyben az elsődleges régió nem állítható helyre. A GZRS-t úgy tervezték, hogy legalább 99,999999999999%-os (16 9-es) tartósságot biztosítson az objektumoknak egy adott évben.

Az alábbi ábrán az adatok GZRS vagy RA-GZRS használatával történő replikálása látható:

Diagram az adatok GZRS vagy RA-GZRS használatával történő replikálásáról

Csak a standard általános célú v2-tárfiókok támogatják a GZRS-t. A GZRS-t az összes Azure Storage-szolgáltatás támogatja, beleértve a következőket:

  • Azure Blob Storage (gyakori és ritka elérésű blokkblobok, nem lemezes lapblobok)
  • Azure Files (minden standard szint: tranzakcióoptimalizált, gyakori és ritka elérésű)
  • Azure Table Storage
  • Azure Queue Storage

A GZRS az Azure-régiók egy részhalmazához érhető el:

  • (Afrika) Dél-Afrika északi régiója
  • (Ázsia és a Csendes-óceáni térség) Kelet-Ausztrália
  • (Ázsia és a Csendes-óceáni térség) Kelet-Ázsia
  • (Ázsia és a Csendes-óceáni térség) Kelet-Japán
  • (Ázsia és a Csendes-óceáni térség) Korea középső régiója
  • (Ázsia és a Csendes-óceáni térség) Délkelet-Ázsia
  • (Ázsia és a Csendes-óceáni térség) Közép-India
  • (Európa) Közép-Franciaország
  • (Európa) Németország nyugati középső régiója
  • (Európa) Észak-Európa
  • (Európa) Kelet-Norvégia
  • (Európa) Közép-Svédország
  • (Európa) Észak-Svájc
  • (Európa) Egyesült Királyság déli régiója
  • (Európa) Nyugat-Európa
  • (Észak-Amerika) Közép-Kanada
  • (Észak-Amerika) USA középső régiója
  • (Észak-Amerika) USA keleti régiója
  • (Észak-Amerika) USA 2. keleti régiója
  • (Észak-Amerika) USA déli középső régiója
  • (Észak-Amerika) USA 2. nyugati régiója
  • (Észak-Amerika) USA 3. nyugati régiója
  • (Észak-Amerika) US Gov Virginia
  • (Dél-Amerika) Dél-Brazília

Olvasási hozzáférés a másodlagos régióban lévő adatokhoz

A georedundáns tárolás (GRS vagy GZRS használatával) a másodlagos régió egy másik fizikai helyére replikálja az adatokat a regionális kimaradások elleni védelem érdekében. A GRS-hez vagy GZRS-hez konfigurált fiók esetén a másodlagos régióban lévő adatok nem érhetők el közvetlenül a felhasználók vagy alkalmazások számára, kivéve, ha feladatátvétel történik. 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. A feladatátvételi folyamat során az adatok nem érhetők el. A feladatátvétel befejezése után adatokat olvashat és írhat az új elsődleges régióba. A feladatátvételről és a vészhelyreállításról további információt a Fiók feladatátvételének működése című témakörben talál.

Ha az alkalmazások magas rendelkezésre állást igényelnek, konfigurálhatja a tárfiókot olvasási hozzáférésre a másodlagos régióhoz. Ha engedélyezi az olvasási hozzáférést a másodlagos régióhoz, akkor az adatok mindig elérhetők lesznek a másodlagos régióból való olvasáshoz, beleértve azt az esetet is, amikor az elsődleges régió elérhetetlenné válik. Az írásvédett georedundáns tárolás (RA-GRS) vagy az írásvédett georedundáns tárolás (RA-GZRS) konfigurációi olvasási hozzáférést biztosítanak a másodlagos régióhoz.

Figyelemfelhívás

Mivel az adatok aszinkron módon replikálódnak az elsődleges régióból a másodlagos régióba, a másodlagos régió általában az elsődleges régió mögött van az írási műveletek szempontjából. Ha egy katasztrófa az elsődleges régióra csapna le, akkor valószínű, hogy egyes adatok elvesznének. A lehetséges adatvesztés megtervezéséről további információt az Adatvesztés előrejelzése című témakörben talál.

Megjegyzés

Azure Files nem támogatja az írásvédett georedundáns tárolást (RA-GRS) vagy az írásvédett geo-zónaredundáns tárolást (RA-GZRS).

Alkalmazások tervezése a másodlagoshoz való olvasási hozzáféréshez

Ha a tárfiókja olvasási hozzáférésre van konfigurálva a másodlagos régióhoz, akkor úgy tervezheti meg az alkalmazásokat, hogy zökkenőmentesen áttérjenek a másodlagos régióból származó adatok beolvasására, ha az elsődleges régió bármilyen okból elérhetetlenné válik.

A másodlagos régió az RA-GRS vagy az RA-GZRS engedélyezése után érhető el olvasási hozzáféréshez, így előre tesztelheti az alkalmazást, és meggyőződhet arról, hogy kimaradás esetén megfelelően lesz olvasható a másodlagos régióból. További információ arról, hogyan tervezheti meg az alkalmazásokat a georedundancia előnyeinek kihasználásához: Magas rendelkezésre állású alkalmazások tervezése georedundancia használatával.

Ha a másodlagoshoz való olvasási hozzáférés engedélyezve van, az alkalmazás beolvasható a másodlagos végpontról és az elsődleges végpontról is. A másodlagos végpont hozzáfűzi a másodlagos utótagot a fiók nevéhez. Ha például a Blob Storage elsődleges végpontja a myaccount.blob.core.windows.net, akkor a másodlagos végpont a myaccount-secondary.blob.core.windows.net. A tárfiók fiókelérési kulcsai megegyeznek az elsődleges és a másodlagos végpontok esetében is.

Az Utolsó szinkronizálás időpontja tulajdonság ellenőrzése

Mivel az adatok aszinkron módon replikálódnak a másodlagos régióba, a másodlagos régió gyakran az elsődleges régió mögött található. Ha hiba történik az elsődleges régióban, akkor valószínű, hogy az elsődleges régióba történő összes írás még nem lesz replikálva a másodlagosra.

Annak megállapításához, hogy mely írási műveletek lettek replikálva a másodlagos régióba, az alkalmazás ellenőrizheti a tárfiók utolsó szinkronizálási ideje tulajdonságát. Az utolsó szinkronizálási időpont 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ás időpontja tulajdonság értékét az Azure PowerShell, az Azure CLI vagy az Azure Storage ügyfélkódtárak egyikével kérdezheti le. Az Utolsó szinkronizálás időpontja tulajdonság egy GMT dátum/idő érték. További információ: Tárfiók legutóbbi szinkronizálási ideje tulajdonság ellenőrzése.

A redundancia beállításainak összefoglalása

Az alábbi szakaszok táblázatai összefoglalják az Azure Storage-hoz elérhető redundancialehetőségeket.

Tartóssági és rendelkezésre állási paraméterek

Az alábbi táblázat az egyes redundancialehetőségek fő paramétereit ismerteti:

Paraméter LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Objektumok tartósságának százalékos aránya egy adott évben legalább 99,99999999999% (11 9-ből) legalább 99,99999999999% (12 9-ből) legalább 99,99999999999999% (1699-ből) legalább 99,99999999999999% (1699-ből)
Olvasási kérések rendelkezésre állása Legalább 99,9% (ritka elérésű vagy archív hozzáférési szintek esetén 99%) Legalább 99,9% (ritka elérésű vagy archív hozzáférési szintek esetén 99%) Legalább 99,9% (ritka elérésű vagy archív hozzáférési szintek esetén 99%) GRS esetén

Legalább 99,99% (99,9% ritka elérésű vagy archív hozzáférési szintek esetén) az RA-GRS-hez
Legalább 99,9% (ritka elérésű vagy archív hozzáférési szintek esetén 99%) a GZRS-hez

RA-GZRS esetén legalább 99,99% (ritka elérésű vagy archív hozzáférési szintek esetén 99,9%)
Az írási kérelmek rendelkezésre állása Legalább 99,9% (ritka elérésű vagy archív hozzáférési szintek esetén 99%) Legalább 99,9% (ritka elérésű vagy archív hozzáférési szintek esetén 99%) Legalább 99,9% (ritka elérésű vagy archív hozzáférési szintek esetén 99%) Legalább 99,9% (ritka elérésű vagy archív hozzáférési szintek esetén 99%)
A különálló csomópontokon tárolt adatok másolatainak száma Három példány egyetlen régión belül Három példány egyetlen régión belül, különálló rendelkezésreállási zónákban Összesen hat példány, köztük három az elsődleges régióban és három a másodlagos régióban Összesen hat példány, köztük három különböző rendelkezésre állási zónában az elsődleges régióban és három helyileg redundáns másolat a másodlagos régióban

További információ: Tárfiókok SLA-ja.

Tartósság és rendelkezésre állás szolgáltatáskimaradási forgatókönyv szerint

Az alábbi táblázat azt jelzi, hogy az adatok tartósak-e és elérhetők-e egy adott forgatókönyvben attól függően, hogy milyen típusú redundancia van érvényben a tárfiókban:

Szolgáltatáskimaradási forgatókönyv LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Egy adatközponton belüli csomópont elérhetetlenné válik Igen Igen Igen Yes
Egy teljes adatközpont (zónaszintű vagy nem zónaszintű) elérhetetlenné válik Nem Igen Igen1 Yes
Régiószintű szolgáltatáskimaradás történik az elsődleges régióban Nem Nem Igen1 Igen1
A másodlagos régió olvasási hozzáférése akkor érhető el, ha az elsődleges régió elérhetetlenné válik Nem Nem Igen (RA-GRS-sel) Igen (RA-GZRS használatával)

1 Fiók feladatátvétele szükséges az írási rendelkezésre állás visszaállításához, ha az elsődleges régió elérhetetlenné válik. További információ: Vészhelyreállítás és tárfiók feladatátvétele.

Támogatott Azure Storage-szolgáltatások

Az alábbi táblázat azt mutatja be, hogy az egyes Azure Storage-szolgáltatások mely redundanciabeállításokat támogatják.

LRS ZRS GRS RA-GRS GZRS RA-GZRS
Blob Storage (beleértve a Data Lake Storage)
Queue Storage
Table Storage
Azure Files 1,2
Felügyelt Azure-lemezek
Lapblobok
Blob Storage (beleértve a Data Lake Storage)
Queue Storage
Table Storage
Azure Files 1,2
Azure-beli felügyelt lemezek3
Blob Storage (beleértve a Data Lake Storage)
Queue Storage
Table Storage
Azure Files 1
Blob Storage (beleértve a Data Lake Storage)
Queue Storage
Table Storage
Blob Storage (beleértve a Data Lake Storage)
Queue Storage
Table Storage
Azure Files 1
Blob Storage (beleértve a Data Lake Storage)
Queue Storage
Table Storage

1 A standard fájlmegosztások támogatottak az LRS-en és a ZRS-en. A standard fájlmegosztások grS-en és GZRS-en is támogatottak, feltéve, hogy 5 TiB-nál kisebbek vagy egyenlőek.
2 Prémium szintű fájlmegosztások támogatottak az LRS-en és a ZRS-en.
3 A ZRS által felügyelt lemezekre bizonyos korlátozások vonatkoznak. A részletekért lásd a felügyelt lemezekre vonatkozó redundanciabeállítások korlátozásokkal foglalkozó szakaszát.

Támogatott tárfióktípusok

Az alábbi táblázat azt mutatja be, hogy mely redundanciabeállítások támogatottak az egyes tárfióktípusokhoz. A tárfióktípusokról további információt a Tárfiók áttekintése című témakörben talál.

Tárfióktípusok LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Ajánlott Standard általános célú v2 (StorageV2)1

Prémium szintű blokkblobok (BlockBlobStorage)1

Prémium szintű fájlmegosztások (FileStorage)

Prémium lapblobok (StorageV2)
Standard általános célú v2 (StorageV2)1

Prémium szintű blokkblobok (BlockBlobStorage)1

Prémium szintű fájlmegosztások (FileStorage)
Standard általános célú v2 (StorageV2)1 Standard általános célú v2 (StorageV2)1
Örökölt Standard általános célú v1 (Storage)

Örökölt blob (BlobStorage)
N/A Standard általános célú v1 (Storage)

Örökölt blob (BlobStorage)
N/A

1 Az ilyen típusú fiókok, amelyeken engedélyezve van a hierarchikus névtér, szintén támogatják a megadott redundanciabeállítást.

A rendszer az összes tárfiók összes adatát az elsődlegesről a másodlagosra másolja a tárfiók redundanciabeállításának megfelelően. A blokkblobokat, hozzáfűző blobokat, lapblobokat, üzenetsorokat, táblákat és fájlokat tartalmazó objektumok másolása folyamatban van.

A georeplikáció során az összes rétegben lévő adatok, beleértve az archív szintet is, mindig az elsődlegesről a másodlagosra lesznek másolva. A Blob Storage archív szintje jelenleg LRS-, GRS- és RA-GRS-fiókok esetében támogatott, ZRS-, GZRS- vagy RA-GZRS-fiókok esetében azonban nem. További információ a blobszintekről: Gyakori elérésű, ritka elérésű és archív hozzáférési szintek a blobadatokhoz.

A nem felügyelt lemezek nem támogatják a ZRS-t vagy a GZRS-t.

Az egyes redundancialehetőségek díjszabására vonatkozó információkért lásd: Azure Storage díjszabása.

Megjegyzés

Az Azure Premium Disk Storage jelenleg csak a helyileg redundáns tárolást (LRS) támogatja. A blokkblobtároló-fiókok bizonyos régiókban támogatják a helyileg redundáns tárolást (LRS) és zónaredundáns tárolást (ZRS).

Ügyfél által felügyelt fiók feladatátvételének támogatása

Minden georedundáns ajánlat támogatja a Microsoft által felügyelt feladatátvételt az elsődleges régióban bekövetkezett katasztrófa esetén. Emellett egyes fióktípusok támogatják az ügyfél által felügyelt fiókok feladatátvételét, amint az az alábbi táblázatban látható. A támogatott fióktípusoknak Azure Resource Manager üzemelő példányokat kell használniuk. További információ a vészhelyreállításról és az ügyfél által felügyelt feladatátvételről: Vészhelyreállítás és tárfiók feladatátvétele.

Feladatátvétel típusa GRS/RA-GRS GZRS/RA-GZRS
Ügyfél által felügyelt 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

Megjegyzés

Az ügyfél által felügyelt fiók feladatátvétele jelenleg nem támogatott hierarchikus névtérrel rendelkező fiókok esetén (Azure Data Lake Storage Gen2). További információk: Az Azure Data Lake Storage Gen2-ben elérhető Blob Ostorvége-funkciók.

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

Adatintegritás

Az Azure Storage rendszeresen ellenőrzi a ciklikus redundancia-ellenőrzések (CRC-k) használatával tárolt adatok integritását. Ha a rendszer adatsérülést észlel, az redundáns adatokkal lesz javítva. Az Azure Storage az összes hálózati forgalom ellenőrzőösszegeit is kiszámítja, hogy észlelje az adatcsomagok sérülését az adatok tárolásakor vagy lekérésekor.

Lásd még