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 Azure Storage mindig több másolatot tárol az adatokról, hogy megvédje őket a tervezett és nem tervezett eseményektől. Ilyen események például az átmeneti hardverhibák, a hálózati vagy áramkimaradások, valamint a súlyos természeti katasztrófák. 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 legjobb a forgatókönyvhöz, vegye figyelembe az alacsonyabb költségek és a magasabb rendelkezésre állás közötti kompromisszumot. Azokat a tényezőket, amelyek segítenek meghatározni, hogy melyik redundancia lehetőséget válasszuk:
- Hogyan történik az adatok replikálása az elsődleges régión belül.
- Azt jelzi, hogy az adatok replikálva lesznek-e egy elsődleges régióból egy második, földrajzilag távoli régióba a regionális katasztrófák (georeplikálás) elleni védelem érdekében.
- Az alkalmazás igényel-e olvasási hozzáférést a másodlagos régióban lévő replikált adatokhoz az elsődleges régió meghibásodása esetén (olvasási hozzáféréssel rendelkező georeplikáció esetén)?
Feljegyzés
A cikkben ismertetett funkciók é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-ból álló szolgáltatásokat egy közös Azure-erőforrás, egy tárfiók felügyeli. A tárfiók egy megosztott tárolókészletet jelöl, amely olyan tárolási erőforrások üzembe helyezésére használható, mint a blobtárolók (Blob Storage), a fájlmegosztások (Azure Files), a táblák (Table Storage) vagy az üzenetsorok (Queue Storage). Az Azure Storage-fiókokról további információt a Tárfiókok áttekintése című témakörben talál.
A tárfiók redundanciabeállítása meg van osztva az adott fiók által közzétett összes tárolási szolgáltatás esetében. Az ugyanabban a tárfiókban üzembe helyezett összes tárolási erőforrás ugyanazzal a redundanciával rendelkezik. Fontolja meg a különböző típusú erőforrások elkülönítését külön tárfiókokban, 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 replikálja az adatokat egyetlen fizikai helyen (adatközpontban) az elsődleges régióban. Nem replikálódik a rendelkezésre állási zónák között.
- Zónaredundáns tárolás (ZRS( – A ZRS az adatokat szinkron módon másolja három rendelkezésre állási Azure-zónában az elsődleges régióban. A magas rendelkezésre állást igénylő alkalmazások esetében a Microsoft azt javasolja, hogy az elsődleges régióban használja a ZRS-t, és replikáljon egy másodlagos régióba is.
Feljegyzés
A Microsoft azt javasolja, hogy az elsődleges régióban használja a ZRS-t az Azure Data Lake Storage számítási feladataihoz.
Helyileg redundáns tárolás
A helyileg redundáns tárolás (LRS) a tárfiókokban lévő adatokat egy vagy több, a választott elsődleges régióban található Azure rendelkezésre állási zónába replikálja. Bár nincs lehetőség az előnyben részesített rendelkezésre állási zóna kiválasztására, az Azure áthelyezheti vagy kibővítheti az LRS-fiókokat a zónák között a terheléselosztás javítása érdekében. Az LRS legalább 99,9999999999999%-os (11 kilences) tartósságot biztosít az objektumoknak egy adott évben. A rendelkezésre állási zónák megbízhatóságával kapcsolatos további információkért tekintse meg az Azure rendelkezésre állási zónákról szóló cikket.
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 biztosítja. Az LRS védi az adatokat a kiszolgáló állvány- és meghajtóhibáitól. Ha azonban katasztrófa, például tűz vagy áradás történik az adatközpontban, előfordulhat, hogy egy LRS-t használó tárfiók összes replikája elveszik vagy helyreállíthatatlan lesz. A kockázat csökkentése érdekében a Microsoft javasolja 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.
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 az adatok mindhárom replikára való írása után tér vissza sikeresen.
Az alábbi diagram 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, fontolja meg az LRS kiválasztását.
- Ha az alkalmazás az adatszabályozási követelmények miatt csak egy régión belüli adatok replikálására van korlátozva, fontolja meg az LRS kiválasztását. Bizonyos esetekben a párosított régiók, amelyeken az adatok georeplikáltak, egy másik régión belül 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, fontolja meg az LRS használatát. Bár létrehozhat tárfiókot az Azure nem felügyelt lemezeihez, amely GRS-t használ, az aszinkron georeplikálás 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) a tárfiókokban lévő adatokat három vagy több, az Ön által választott elsődleges régióban található Azure rendelkezésre állási zónába replikálja. 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 egy adott évben legalább 99,99999999999999%-os (12 9s) tárolási erőforrások tartósságát biztosítja. A rendelkezésre állási zónák megbízhatóságával kapcsolatos további információkért tekintse meg az Azure rendelkezésre állási zónákról szóló cikket.
A ZRS használatakor az adatok akkor is elérhetők maradnak 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 olyan hálózati frissítéseket hajt végre, mint a tartománynévrendszer (DNS) újrapontozása. Ezek a frissítések hatással lehetnek az alkalmazásra, ha a frissítések befejeződése előtt hozzáfér 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 visszakapcsolással történő implementálását is.
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 lesz sikeres, ha az adatok a három rendelkezésre állási zónában lévő összes replikához meg lesznek írva. Ha egy rendelkezésre állási zóna átmenetileg nem érhető el, a művelet sikeresen visszaáll, miután az adatok az összes elérhető zónába meg vannak írva.
A Microsoft azt javasolja, hogy az elsődleges régióban használja a ZRS-t a magas rendelkezésre állást igénylő forgatókönyvekhez. Javasolt a ZRS használata az adatreplikálás egy adott régióra való korlátozására, hogy megfeleljen az adatszabályozási követelményeknek.
A Microsoft a ZRS használatát javasolja az Azure Files számítási feladataihoz. Ha egy zóna elérhetetlenné válik, nincs szükség az Azure-fájlmegosztások újracsatlakoztatására a már csatlakozott ügyfelek esetében.
Az alábbi ábra bemutatja, hogyan replikálja az adatokat az elsődleges régió rendelkezésre állási zónái között a 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 az ideiglenesen elérhetetlenné válik. Előfordulhat azonban, hogy a ZRS önmagában nem védi teljesen az adatokat egy olyan regionális katasztrófa ellen, amely több zónát érint véglegesen. A geozónaredundáns tárolás (GZRS) az elsődleges régióban ZRS-t használ, és georeplikálással egy másodlagos régióba replikálja az adatokat. A GZRS számos régióban elérhető, és ajánlott a regionális katasztrófák elleni védelemhez.
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, tekintse meg a rendelkezésre állási zónákkal rendelkező Azure-régiókat.
Redundancia egy másodlagos régióban
A redundancia beállításai nagy tartósságot biztosíthatnak az alkalmazások számára. Számos régióban átmásolhatja a tárfiókban lévő adatokat egy másodlagos régióba, amely több száz kilométerre található az elsődleges régiótól. A tárfiók másodlagos régióba másolása biztosítja, hogy az adatok tartósak maradnak egy teljes regionális kimaradás vagy olyan katasztrófa során, amelyben az elsődleges régió nem állítható helyre.
Tárfiók létrehozásakor kiválaszthatja 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 tekintse meg az Azure-régiók listáját.
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 elsődleges régióban, az LRS használatával, szinkron módon háromszor másolja az adatokat egy vagy több Azure rendelkezésre állási zónában. 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 szinkronizálása háromszor történik az LRS használatával.
- A geozónaredundáns tárolás (GZRS) szinkronizálva másolja az adatokat az elsődleges régió három Azure 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 szinkronizálása háromszor történik az LRS használatával.
Feljegyzé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ó LRS-jei védik az adatokat a hardverhibáktól.
GRS vagy GZRS használata esetén a másodlagos régió adatai nem érhetők el olvasási vagy írási hozzáféréshez, kivéve ha a feladatátvétel a másodlagos régióba történik. 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, választhatja a másodlagos régióba történő átkapcsolást. A feladatátvételi művelet befejezése után a másodlagos régió lesz az elsődleges régió, és ön képes adatokat olvasni és írni. A vészhelyreállításról és a másodlagos régióba történő feladatátvételről további információt a Vészhelyreállítás és tárfiók feladatátvétele című témakörben talál.
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ási pont 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 arra vonatkozóan, 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) háromszor szinkronizálja az adatokat egy vagy több rendelkezésre állási zónába az elsődleges régióban LRS használatával. 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 a tárolási erőforrások tartósságát legalább 99,99999999999999%-ra (16 darab 9-es) biztosítja egy adott év során.
Az írási művelet először az elsődleges helyre kerül, és az LRS használatával replikálódik. Ezt követően a rendszer aszinkron módon replikálja a frissítést a másodlagos régióba. Amikor az adatok a másodlagos helyre kerülnek, az LRS használatával ezen a helyen is replikálódik.
Az alábbi ábra bemutatja, hogyan replikálja az adatokat GRS vagy RA-GRS használatával:
Zóna- és georedundáns tárolás
A geozónaredundáns tárolás (GZRS) egyesíti a rendelkezésre állási zónák közötti redundancia által biztosított magas rendelkezésre állást a georeplikálás által biztosított regionális kimaradások elleni védelemmel. A GZRS-fiók adatai az elsődleges régió három Azure-rendelkezésre állási zónájában lesznek átmásolva. Emellett egy másodlagos földrajzi régióba is replikálja a regionális katasztrófák elleni védelem érdekében. A Microsoft a GZRS használatát javasolja olyan alkalmazásokhoz, amelyek maximális konzisztenciát, tartósságot és rendelkezésre állást, kiváló teljesítményt és rugalmasságot igényelnek a vészhelyreállításhoz.
GZRS-fió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 maradnak egy teljes regionális kimaradás vagy katasztrófa során, amelyben az elsődleges régió nem állítható helyre. A GZRS-t úgy tervezték, hogy legalább 99,99999999999999999%-os (16 9s) tartósságot biztosítson az objektumoknak egy adott évben.
Az alábbi diagram bemutatja, hogyan replikálja az adatokat a GZRS vagy az RA-GZRS használatával:
Annak megállapításához, hogy egy régió támogatja-e a GZRS-t, tekintse meg az Azure-régiók listáját. A GZRS támogatásához a régiónak támogatnia kell a rendelkezésre állási zónákat, és párosított régióval kell rendelkeznie.
Olvasási hozzáférés az adatokhoz a másodlagos régióban
A georedundáns tárolás (GRS vagy GZRS használatával) replikálja az adatokat egy másik fizikai helyre a másodlagos régióban a regionális kimaradások elleni védelem érdekében. A GRS-hez vagy GZRS-hez konfigurált fiókkal 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, ha az elsődleges régióban kimaradás történik, 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, így a másodlagos régióban lévő tárolási szolgáltatásvégpontok lesznek a tárfiók új elsődleges végpontjai. A feladatátvételi folyamat során az adatok nem érhetők el. A feladatátvétel befejezése után olvashat és írhat adatokat az új primer régióba. További információkért tekintse meg, hogyan működik az ügyfél által kezelt tárolófiók feladatátvétele a leállásból való helyreállítás során.
Ha az alkalmazások magas rendelkezésre állást igényelnek, akkor konfigurálhatja a tárfiókot a másodlagos régióhoz való olvasási hozzáféréshez. Ha engedélyezi az olvasási hozzáférést a másodlagos régióhoz, akkor az adatok mindig elérhetők a másodlagos régióból való olvasáshoz, beleértve azokat az állapotokat is, amikor az elsődleges régió elérhetetlenné válik. Az olvasási hozzáférésű georedundáns tárolás (RA-GRS) vagy az olvasási hozzáférésű geo-zónaredundáns tárolás (RA-GZRS) konfigurációi olvasási hozzáférést biztosítanak a másodlagos régióhoz.
Feljegyzés
Az Azure Files nem támogatja az olvasási hozzáférésű georedundáns tárolást (RA-GRS) vagy az olvasási hozzáférésű geo-zóna-redundáns tárolást (RA-GZRS).
Tervezze meg alkalmazásait, hogy olvasási hozzáférést biztosítsanak a másodlagos erőforrásokhoz.
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 az adatok olvasására a másodlagos régióból, 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. Ez a rendelkezésre állás lehetővé teszi az alkalmazás előzetes tesztelését annak biztosítása érdekében, hogy megfelelően olvassa be az alkalmazást a másodlagos régióból egy üzemkimaradás során. A georedundancia előnyeinek kihasználásához az alkalmazások tervezésével kapcsolatos további információkért lásd : Magas rendelkezésre állású alkalmazások tervezése georedundanciával.
Ha engedélyezve van a másodlagoshoz való olvasási hozzáférés, az alkalmazás a másodlagos és az elsődleges végpontról is olvasható. A másodlagos végpont hozzáfűzi a -secondary utótagot a fiók nevéhez. Ha például a Blob Storage elsődleges végpontja az myaccount.blob.core.windows.net, akkor a másodlagos végpont az myaccount-secondary.blob.core.windows.net. A tárfiók fiókhozzáférés-kulcsai megegyeznek az elsődleges és a másodlagos végpontok esetében is.
Adatvesztés megtervezése
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ót sújtja, valószínű, hogy egyes adatok elvesznek, és a címtárban vagy tárolóban lévő fájlok nem lesznek konzisztensek. A lehetséges adatvesztés megtervezéséről további információt az adatvesztés és az inkonzisztenciák című témakörben talál.
A redundancia beállításainak összegzése
Az alábbi szakaszokban található táblázatok az Azure Storage-hoz elérhető redundancialehetőségeket összegzik.
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 (tanulási rendszer) | 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 9s) | legalább 99,9999999999999% (12 9s) | legalább 99,99999999999999999% (16 9s) | legalább 99,99999999999999999% (16 9s) |
| Olvasási kérelmek rendelkezésre állása | Legalább 99,9% (cool/hideg/archív hozzáférési szintek esetén 99%) | Legalább 99,9% (hűvös/hideg hozzáférési szint esetén 99%) | GRS esetén legalább 99,9% (hűvös/hideg/archív hozzáférési szintek esetén 99%) RA-GRS esetén legalább 99,99% (ritka/hideg/archív hozzáférési szintek esetén 99,9%) |
GZRS esetén legalább 99.9% (hűvös/hideg hozzáférés-típus esetén 99%) RA-GZRS esetén legalább 99,99% (hideg/hideg hozzáférési réteg esetén 99,9%) |
| Írási kérelmek rendelkezésre állása | Legalább 99,9% (cool/hideg/archív hozzáférési szintek esetén 99%) | Legalább 99,9% (hűvös/hideg hozzáférési szint esetén 99%) | Legalább 99,9% (cool/hideg/archív hozzáférési szintek esetén 99%) | Legalább 99,9% (hűvös/hideg hozzáférési szint esetén 99%) |
További információért tekintse meg a tárfiókok szolgáltatási szintű megállapodását.
Tartósság és rendelkezésre állás kimaradás esetén
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:
| Üzemkimaradási forgatókönyv | LRS (tanulási rendszer) | ZRS | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|---|---|
| Egy adatközponton belüli csomópont elérhetetlenné válik | Igen | Igen | Igen | Igen |
| Egy teljes adatközpont (zóna vagy nem zóna) elérhetetlenné válik | Nem | Igen | Igen1 | Igen |
| Régiószintű kimaradá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-szel) | Igen (RA-GZRS használatával) |
1 Fiókátállás 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ókért lásd 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 az egyes Azure Storage-szolgáltatások által támogatott redundanciabeállításokat mutatja be.
| Szolgáltatás | LRS (tanulási rendszer) | ZRS | GRS | RA-GRS | GZRS | RA-GZRS |
|---|---|---|---|---|---|---|
| Blob tárhely (beleértve a Data Lake Storage-t) |
✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Soros tárolás | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Táblatárolás | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Azure Files | ✅ 1 | ✅ 1 | ✅ | ✅ | ||
| Azure felügyelt lemezek | ✅ | ✅ 2 | ||||
| Azure Elastic SAN | ✅ | ✅ |
Az LRS és a ZRS 1 SSD-fájlmegosztást támogat.
A 2 ZRS által felügyelt lemezekre bizonyos korlátozások vonatkoznak. A részletekért tekintse meg a felügyelt lemezek redundanciabeállításainak 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ók-típusokhoz. A tárfióktípusokról további információt a Tárfiókok áttekintése című témakörben talál.
| Tárfióktípusok | LRS (tanulási rendszer) | ZRS | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|---|---|
| Ajánlott | Szabványos általános célú v2 (StorageV2)1Prémium szintű blokkblobok ( BlockBlobStorage)1SSD-fájlmegosztások ( FileStorage) Prémium szintű lapblobok ( StorageV2) |
Szabványos általános célú v2 (StorageV2)1Prémium szintű blokkblobok ( BlockBlobStorage)1SSD-fájlmegosztások ( FileStorage) |
Szabványos általános célú v2 (StorageV2)1 |
Szabványos általános célú v2 (StorageV2)1 |
| Örökség | Standard általános célú v1 (Storage)Régi blob ( BlobStorage) |
n/a | Standard általános célú v1 (Storage)Régi blob ( BlobStorage) |
n/a |
1 A hierarchikus névtérrel rendelkező ilyen típusú fiókok a megadott redundanciabeállítást is támogatják.
Az összes tárfiók összes adata az elsődlegesről a másodlagosra lesz másolva a tárfiók redundanciabeállításának megfelelően. Objektumok, például blokkblobok, hozzáfűző blobok, oldalblobok, üzenetsorok, táblák és fájlok kerülnek másolásra.
A georeplikálás során az összes réteg adatai, beleértve az archív szintet is, mindig át lesznek másolva az elsődlegesről a másodlagosra. 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. A blobszintekről további információt a blobadatok hozzáférési szintjei című témakörben talál.
A nem felügyelt lemezek nem támogatják a ZRS-t vagy a GZRS-t.
Az egyes redundancialehetőségekre vonatkozó díjszabási információkért tekintse meg az Azure Storage díjszabását.
Feljegyzés
A blokkblobtárfiókok bizonyos régiókban támogatják a helyileg redundáns tárolást (LRS) és a zónaredundáns tárolást (ZRS).
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. Az észlelt adatsérülések redundáns adatokkal javíthatók. Az Azure Storage emellett 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
- Tárfiók redundanciabeállításának módosítása
- Geo replikáció (GRS/GZRS/RA-GRS/RA-GZRS)
- Árképzés