Azure Storage-redundantie
Azure Storage slaat altijd meerdere kopieën van uw gegevens op, zodat deze worden beschermd tegen geplande en ongeplande gebeurtenissen, waaronder tijdelijke hardwarestoringen, netwerk- of stroomstoringen en grootschalige natuurrampen. Redundantie zorgt ervoor dat uw opslagaccount voldoet aan de beschikbaarheids- en duurzaamheidsdoelen, zelfs bij fouten.
Wanneer u besluit welke redundantieoptie het beste is voor uw scenario, moet u rekening houden met de afwegingen tussen lagere kosten en hogere beschikbaarheid. De factoren die helpen bepalen welke redundantieoptie u moet kiezen, zijn onder andere:
- Hoe uw gegevens worden gerepliceerd in de primaire regio.
- Of uw gegevens worden gerepliceerd naar een tweede regio die geografisch ver van de primaire regio ligt, ter bescherming tegen regionale rampen (geo-replicatie).
- Of uw toepassing leestoegang tot de gerepliceerde gegevens in de secundaire regio vereist als de primaire regio om welke reden dan ook niet meer beschikbaar is (geo-replicatie met leestoegang).
Notitie
De functies en regionale beschikbaarheid die in dit artikel worden beschreven, zijn ook beschikbaar voor accounts met een hiërarchische naamruimte (Azure Blob Storage).
De services waaruit Azure Storage bestaat, worden beheerd via een algemene Azure-resource die een opslagaccount wordt genoemd. Het opslagaccount vertegenwoordigt een gedeelde opslaggroep die kan worden gebruikt voor het implementeren van opslagresources zoals blobcontainers (Blob Storage), bestandsshares (Azure Files), tabellen (Table Storage) of wachtrijen (Queue Storage). Zie Overzicht van opslagaccounts voor meer informatie over Azure Storage-accounts.
De redundantie-instelling voor een opslagaccount wordt gedeeld voor alle opslagservices die beschikbaar zijn voor dat account. Alle opslagresources die in hetzelfde opslagaccount zijn geïmplementeerd, hebben dezelfde redundantie-instelling. U kunt verschillende typen resources in afzonderlijke opslagaccounts isoleren als ze verschillende redundantievereisten hebben.
Redundantie in de primaire regio
Gegevens in een Azure Storage-account worden altijd drie keer gerepliceerd in de primaire regio. Azure Storage biedt twee opties voor het repliceren van uw gegevens in de primaire regio:
- Lokaal redundante opslag (LRS) kopieert uw gegevens drie keer synchroon binnen één fysieke locatie in de primaire regio. LRS is de goedkoopste replicatieoptie, maar wordt niet aanbevolen voor toepassingen die hoge beschikbaarheid of duurzaamheid vereisen.
- Zone-redundante opslag (ZRS) kopieert uw gegevens synchroon tussen drie Azure-beschikbaarheidszones in de primaire regio. Voor toepassingen waarvoor hoge beschikbaarheid is vereist, raadt Microsoft aan ZRS te gebruiken in de primaire regio en ook te repliceren naar een secundaire regio.
Notitie
Microsoft raadt aan ZRS te gebruiken in de primaire regio voor Azure Data Lake Storage Gen2 workloads.
Lokaal redundante opslag
Lokaal redundante opslag (LRS) repliceert uw opslagaccount drie keer binnen één datacenter in de primaire regio. LRS biedt ten minste 99,9999999999% (11 negens) duurzaamheid van objecten gedurende een bepaald jaar.
LRS is de goedkoopste redundantieoptie en biedt de minste duurzaamheid in vergelijking met andere opties. LRS beschermt uw gegevens tegen serverrack- en stationsfouten. Als er echter een noodgeval zoals brand of overstromingen in het datacenter optreedt, kunnen alle replica's van een opslagaccount met LRS verloren gaan of onherstelbaar zijn. Om dit risico te beperken, raadt Microsoft aan zone-redundante opslag (ZRS), geografisch redundante opslag (GRS) of geografisch zone-redundante opslag (GZRS) te gebruiken.
Een schrijfaanvraag naar een opslagaccount dat LRS gebruikt, wordt synchroon uitgevoerd. De schrijfbewerking wordt pas geretourneerd nadat de gegevens naar alle drie de replica's zijn geschreven.
In het volgende diagram ziet u hoe uw gegevens worden gerepliceerd binnen één datacenter met LRS:
LRS is een goede keuze voor de volgende scenario's:
- Als uw toepassing gegevens opslaat die eenvoudig kunnen worden gereconstrueerd als gegevensverlies optreedt, kunt u kiezen voor LRS.
- Als uw toepassing is beperkt tot het repliceren van gegevens binnen een land of regio vanwege vereisten voor gegevensbeheer, kunt u kiezen voor LRS. In sommige gevallen bevinden de gekoppelde regio's waarbinnen de gegevens geo-repliceren zich in een ander land of een andere regio. Zie Azure-regio's voor meer informatie over gekoppelde regio's.
- Als uw scenario gebruikmaakt van niet-beheerde Azure-schijven, kunt u kiezen voor LRS. Hoewel het mogelijk is om een opslagaccount te maken voor niet-beheerde Azure-schijven die gebruikmaken van GRS, wordt dit niet aanbevolen vanwege mogelijke problemen met consistentie via asynchrone geo-replicatie.
Zone-redundante opslag
Zone-redundante opslag (ZRS) repliceert uw opslagaccount synchroon in drie Azure-beschikbaarheidszones in de primaire regio. Elke beschikbaarheidszone is een afzonderlijke fysieke locatie met onafhankelijke voeding, koeling en netwerken. ZRS biedt duurzaamheid voor opslagresources van ten minste 99,99999999999% (12 9's) gedurende een bepaald jaar.
Met ZRS zijn uw gegevens nog steeds toegankelijk voor zowel lees- als schrijfbewerkingen, zelfs als een zone niet meer beschikbaar is. Als een zone niet meer beschikbaar is, voert Azure netwerkupdates uit, zoals het opnieuw aanwijzen van DNS. Deze updates kunnen van invloed zijn op uw toepassing als u toegang hebt tot gegevens voordat de updates zijn voltooid. Bij het ontwerpen van toepassingen voor ZRS volgt u de procedures voor het afhandelen van tijdelijke fouten, waaronder het implementeren van beleid voor opnieuw proberen met exponentieel back-off.
Een schrijfaanvraag naar een opslagaccount dat gebruikmaakt van ZRS vindt synchroon plaats. De schrijfbewerking wordt pas geretourneerd nadat de gegevens naar alle replica's in de drie beschikbaarheidszones zijn geschreven. Als een beschikbaarheidszone tijdelijk niet beschikbaar is, wordt de bewerking geretourneerd nadat de gegevens naar alle beschikbare zones zijn geschreven.
Microsoft raadt het gebruik van ZRS aan in de primaire regio voor scenario's waarvoor hoge beschikbaarheid is vereist. ZRS wordt ook aanbevolen voor het beperken van de replicatie van gegevens naar een bepaald land of een bepaalde regio om te voldoen aan vereisten voor gegevensbeheer.
Microsoft raadt het gebruik van ZRS aan voor Azure Files workloads. Als een zone niet meer beschikbaar is, is het niet nodig om Azure-bestandsshares van de verbonden clients opnieuw te koppelen.
In het volgende diagram ziet u hoe uw gegevens worden gerepliceerd tussen beschikbaarheidszones in de primaire regio met ZRS:
ZRS biedt uitstekende prestaties, lage latentie en tolerantie voor uw gegevens als deze tijdelijk niet beschikbaar zijn. ZRS zelf kan uw gegevens echter niet beschermen tegen een regionaal noodgeval waarbij meerdere zones permanent worden getroffen. Voor bescherming tegen regionale rampen raadt Microsoft het gebruik van geografisch zone-redundante opslag (GZRS) aan, die gebruikmaakt van ZRS in de primaire regio en uw gegevens ook geo-repliceert naar een secundaire regio.
De archieflaag voor Blob Storage wordt momenteel niet ondersteund voor ZRS-, GZRS- of RA-GZRS-accounts. Niet-beheerde schijven bieden geen ondersteuning voor ZRS of GZRS.
Zie Azure-regio's met beschikbaarheidszones voor meer informatie over welke regio's ondersteuning bieden voor ZRS.
Standard-opslagaccounts
ZRS wordt ondersteund voor alle Azure Storage-services via standaard v2-opslagaccounts voor algemeen gebruik, waaronder:
- Azure Blob Storage (dynamische en statische blok-blobs en toevoeg-blobs, niet-schijfpagina-blobs)
- Azure Files (alle standaardlagen: geoptimaliseerd voor transacties, dynamisch en statisch)
- Azure Table Storage
- Azure Queue Storage
Premium blok-blob-accounts
ZRS wordt ondersteund voor premium blok-blobs-accounts. Zie Premium blok-blobopslagaccounts voor meer informatie over Premium-blok-blobs.
Premium-bestandsshareaccounts
ZRS wordt ondersteund voor Premium-bestandsshares (Azure Files) via het FileStorage
type opslagaccount.
Zie voor een lijst met regio's die ondersteuning bieden voor zone-redundante opslag (ZRS) voor Premium-bestandsshareaccounts Azure Files zone-redundante opslag voor Premium-bestandsshares.
Managed Disks
ZRS wordt ondersteund voor beheerde schijven met de volgende beperkingen.
Zie Regionale beschikbaarheid voor een lijst met regio's die ondersteuning bieden voor zone-redundante opslag (ZRS) voor beheerde schijven.
Redundantie in een secundaire regio
Voor toepassingen die een hoge duurzaamheid vereisen, kunt u ervoor kiezen om de gegevens in uw opslagaccount ook te kopiëren naar een secundaire regio die honderden kilometers verwijderd is van de primaire regio. Als uw opslagaccount wordt gekopieerd naar een secundaire regio, zijn uw gegevens duurzaam, zelfs in het geval van een volledige regionale storing of een noodgeval waarbij de primaire regio niet kan worden hersteld.
Wanneer u een opslagaccount maakt, selecteert u de primaire regio voor het account. De gekoppelde secundaire regio wordt bepaald op basis van de primaire regio en kan niet worden gewijzigd. Zie Azure-regio's voor meer informatie over regio's die worden ondersteund door Azure.
Azure Storage biedt twee opties voor het kopiëren van uw gegevens naar een secundaire regio:
- Geografisch redundante opslag (GRS): uw gegevens worden drie keer synchroon gekopieerd binnen één fysieke locatie in de primaire regio met LRS. Vervolgens worden uw gegevens asynchroon gekopieerd naar één fysieke locatie in de secundaire regio. Binnen de secundaire regio worden uw gegevens drie keer synchroon gekopieerd met behulp van LRS.
- Geografisch zone-redundante opslag (GZRS) kopieert uw gegevens synchroon tussen drie Azure-beschikbaarheidszones in de primaire regio met behulp van ZRS. Vervolgens worden uw gegevens asynchroon gekopieerd naar één fysieke locatie in de secundaire regio. Binnen de secundaire regio worden uw gegevens drie keer synchroon gekopieerd met behulp van LRS.
Notitie
Het belangrijkste verschil tussen GRS en GZRS is hoe gegevens in de primaire regio worden gerepliceerd. Binnen de secundaire regio worden gegevens altijd drie keer synchroon gerepliceerd met behulp van LRS. LRS in de secundaire regio beschermt uw gegevens tegen hardwarefouten.
Met GRS of GZRS zijn de gegevens in de secundaire regio niet beschikbaar voor lees- of schrijftoegang, tenzij er een failover naar de primaire regio is. Voor leestoegang tot de secundaire regio configureert u uw opslagaccount voor gebruik van geografisch redundante opslag met leestoegang (RA-GRS) of geografisch zone-redundante opslag met leestoegang (RA-GZRS). Zie Leestoegang tot gegevens in de secundaire regio voor meer informatie.
Als de primaire regio niet meer beschikbaar is, kunt u een failover uitvoeren naar de secundaire regio. Nadat de failover is voltooid, wordt de secundaire regio de primaire regio en kunt u opnieuw gegevens lezen en schrijven. Zie Herstel na noodgeval en failover van opslagaccounts voor meer informatie over herstel na noodgevallen en voor meer informatie over het uitvoeren van een failover naar de secundaire regio.
Belangrijk
Omdat gegevens asynchroon naar de secundaire regio worden gerepliceerd, kan een fout die van invloed is op de primaire regio leiden tot gegevensverlies als de primaire regio niet kan worden hersteld. Het interval tussen de meest recente schrijfbewerkingen naar de primaire regio en de laatste schrijfbewerking naar de secundaire regio wordt RPO (Recovery Point Objective) genoemd. De RPO geeft het tijdstip aan waarnaar gegevens kunnen worden hersteld. Het Azure Storage-platform heeft doorgaans een RPO van minder dan 15 minuten, hoewel er momenteel geen SLA is voor hoe lang het duurt om gegevens te repliceren naar de secundaire regio.
Geografisch redundante opslag
Geografisch redundante opslag (GRS): uw gegevens worden drie keer synchroon gekopieerd binnen één fysieke locatie in de primaire regio met LRS. Vervolgens worden uw gegevens asynchroon gekopieerd naar één fysieke locatie in een secundaire regio die honderden kilometers verwijderd is van de primaire regio. GRS biedt duurzaamheid voor opslagresources van ten minste 99,999999999999999% (16 9's) gedurende een bepaald jaar.
Een schrijfbewerking wordt eerst doorgevoerd op de primaire locatie en gerepliceerd met behulp van LRS. De update wordt vervolgens asynchroon gerepliceerd naar de secundaire regio. Wanneer gegevens naar de secundaire locatie worden geschreven, worden deze ook binnen die locatie gerepliceerd met behulp van LRS.
In het volgende diagram ziet u hoe uw gegevens worden gerepliceerd met GRS of RA-GRS:
Geografisch zone-redundante opslag
Geografisch zone-redundante opslag (GZRS) combineert de hoge beschikbaarheid die wordt geboden door redundantie in beschikbaarheidszones met bescherming tegen regionale storingen die worden geboden door geo-replicatie. Gegevens in een GZRS-opslagaccount worden gekopieerd naar drie Azure-beschikbaarheidszones in de primaire regio en worden ook gerepliceerd naar een secundaire geografische regio ter bescherming tegen regionale rampen. Microsoft raadt het gebruik van GZRS aan voor toepassingen die maximale consistentie, duurzaamheid en beschikbaarheid, uitstekende prestaties en tolerantie voor herstel na noodgevallen vereisen.
Met een GZRS-opslagaccount kunt u gegevens blijven lezen en schrijven als een beschikbaarheidszone niet meer beschikbaar is of niet meer kan worden hersteld. Bovendien zijn uw gegevens ook duurzaam in het geval van een volledige regionale storing of een noodgeval waarbij de primaire regio niet kan worden hersteld. GZRS is ontworpen om ten minste 99,999999999999999% (16 9's) duurzaamheid van objecten gedurende een bepaald jaar te bieden.
In het volgende diagram ziet u hoe uw gegevens worden gerepliceerd met GZRS of RA-GZRS:
Alleen standaard v2-opslagaccounts voor algemeen gebruik ondersteunen GZRS. GZRS wordt ondersteund door alle Azure Storage-services, waaronder:
- Azure Blob Storage (dynamische en statische blok-blobs, niet-schijfpagina-blobs)
- Azure Files (alle standard-lagen: geoptimaliseerd voor transacties, dynamisch en statisch)
- Azure Table Storage
- Azure Queue Storage
Leestoegang tot gegevens in de secundaire regio
Geografisch redundante opslag (met GRS of GZRS) repliceert uw gegevens naar een andere fysieke locatie in de secundaire regio ter bescherming tegen regionale storingen. Met een account dat is geconfigureerd voor GRS of GZRS, zijn gegevens in de secundaire regio niet rechtstreeks toegankelijk voor gebruikers of toepassingen, tenzij er een failover optreedt. Tijdens het failoverproces wordt de DNS-vermelding van Azure Storage bijgewerkt, zodat het secundaire eindpunt het nieuwe primaire eindpunt voor uw opslagaccount wordt. Tijdens het failoverproces zijn uw gegevens niet toegankelijk. Nadat de failover is voltooid, kunt u gegevens lezen en schrijven naar de nieuwe primaire regio. Zie Hoe een accountfailover werkt voor meer informatie over failover en herstel na noodgevallen.
Als voor uw toepassingen hoge beschikbaarheid is vereist, kunt u uw opslagaccount configureren voor leestoegang tot de secundaire regio. Wanneer u leestoegang tot de secundaire regio inschakelt, zijn uw gegevens altijd beschikbaar om te worden gelezen vanaf de secundaire regio, ook in een situatie waarin de primaire regio niet meer beschikbaar is. Configuraties voor geografisch redundante opslag met leestoegang (RA-GRS) of geografisch zone-redundante opslag met leestoegang (RA-GZRS) maken leestoegang tot de secundaire regio mogelijk.
Notitie
Azure Files biedt geen ondersteuning voor geografisch redundante opslag met leestoegang (RA-GRS) of geografisch zone-redundante opslag met leestoegang (RA-GZRS).
Uw toepassingen ontwerpen voor leestoegang tot de secundaire
Als uw opslagaccount is geconfigureerd voor leestoegang tot de secundaire regio, kunt u uw toepassingen ontwerpen om naadloos over te schakelen naar het lezen van gegevens uit de secundaire regio als de primaire regio om welke reden dan ook niet meer beschikbaar is.
De secundaire regio is beschikbaar voor leestoegang nadat u RA-GRS of RA-GZRS hebt ingeschakeld, zodat u uw toepassing van tevoren kunt testen om er zeker van te zijn dat deze correct wordt gelezen vanuit de secundaire regio in het geval van een storing. Zie Georedundantie gebruiken om maximaal beschikbare toepassingen te ontwerpen voor meer informatie over het ontwerpen van uw toepassingen om te profiteren van geo-redundantie.
Wanneer leestoegang tot de secundaire is ingeschakeld, kan uw toepassing worden gelezen vanuit het secundaire eindpunt en vanaf het primaire eindpunt. Het secundaire eindpunt voegt het achtervoegsel –secundair toe aan de accountnaam. Als uw primaire eindpunt voor Blob Storage bijvoorbeeld is, is myaccount.blob.core.windows.net
myaccount-secondary.blob.core.windows.net
het secundaire eindpunt . De accounttoegangssleutels voor uw opslagaccount zijn hetzelfde voor zowel het primaire als het secundaire eindpunt.
Plan voor gegevensverlies
Omdat gegevens asynchroon worden gerepliceerd van de primaire naar de secundaire regio, bevindt de secundaire regio zich doorgaans achter de primaire regio in termen van schrijfbewerkingen. Als een ramp de primaire regio treft, zijn er waarschijnlijk gegevens verloren gegaan. Zie Gegevensverlies anticiperen voor meer informatie over het plannen van mogelijk gegevensverlies.
Overzicht van redundantieopties
De tabellen in de volgende secties bevatten een overzicht van de redundantieopties die beschikbaar zijn voor Azure Storage.
Parameters voor duurzaamheid en beschikbaarheid
In de volgende tabel worden de belangrijkste parameters voor elke redundantieoptie beschreven:
Parameter | LRS | ZRS | GRS/RA-GRS | GZRS/RA-GZRS |
---|---|---|---|---|
Duurzaamheidspercentage van objecten in een bepaald jaar | ten minste 99,999999999999% (11 9's) | ten minste 99,9999999999999% (12 9's) | ten minste 99,999999999999999% (16 9's) | ten minste 99,999999999999999% (16 9's) |
Beschikbaarheid voor leesaanvragen | Ten minste 99,9% (99% voor statische of archieftoegangslagen) | Ten minste 99,9% (99% voor statische toegangslaag) | Ten minste 99,9% (99% voor statische of archieftoegangslagen) voor GRS Ten minste 99,99% (99,9% voor statische of archieftoegangslagen) voor RA-GRS |
Ten minste 99,9% (99% voor statische toegangslaag) voor GZRS Ten minste 99,99% (99,9% voor Cool-toegangslaag) voor RA-GZRS |
Beschikbaarheid voor schrijfaanvragen | Ten minste 99,9% (99% voor statische of archieftoegangslagen) | Ten minste 99,9% (99% voor statische toegangslaag) | Ten minste 99,9% (99% voor statische of archieftoegangslagen) | Ten minste 99,9% (99% voor statische toegangslaag) |
Aantal kopieën van gegevens dat op afzonderlijke knooppunten wordt onderhouden | Drie kopieën binnen één regio | Drie kopieën in afzonderlijke beschikbaarheidszones binnen één regio | In totaal zes exemplaren, waarvan drie in de primaire regio en drie in de secundaire regio | Zes exemplaren in totaal, waarvan drie in afzonderlijke beschikbaarheidszones in de primaire regio en drie lokaal redundante kopieën in de secundaire regio |
Zie de SLA voor opslagaccounts voor meer informatie.
Duurzaamheid en beschikbaarheid per storingsscenario
In de volgende tabel wordt aangegeven of uw gegevens duurzaam en beschikbaar zijn in een bepaald scenario, afhankelijk van welk type redundantie van kracht is voor uw opslagaccount:
Storingsscenario | LRS | ZRS | GRS/RA-GRS | GZRS/RA-GZRS |
---|---|---|---|---|
Een knooppunt in een datacentrum is niet meer beschikbaar | Ja | Ja | Ja | Ja |
Een volledig datacenter (zonegebonden of niet-zonegebonden) is niet meer beschikbaar | Nee | Ja | Ja1 | Yes |
Een storing in de hele regio treedt op in de primaire regio | No | Nee | Ja1 | Ja1 |
Leestoegang tot de secundaire regio is beschikbaar als de primaire regio niet meer beschikbaar is | No | Nee | Ja (met RA-GRS) | Ja (met RA-GZRS) |
1 Failover van account is vereist om de schrijfbeschikbaarheid te herstellen als de primaire regio niet meer beschikbaar is. Zie Herstel na noodgevallen en failover van opslagaccounts voor meer informatie.
Ondersteunde Azure Storage-services
In de volgende tabel ziet u welke redundantieopties worden ondersteund door elke Azure Storage-service.
Service | LRS | ZRS | GRS | RA-GRS | GZRS | RA-GZRS |
---|---|---|---|---|---|---|
Blob Storage (inclusief Data Lake Storage) |
✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Queue Storage | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Table Storage | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Azure Files | ✅1,2 | ✅1,2 | ✅1 | ✅1 | ||
Beheerde Azure-schijven | ✅ | ✅3 | ||||
Azure Elastic SAN | ✅ | ✅ |
1 Standaardbestandsshares worden ondersteund op LRS en ZRS. Standaardbestandsshares worden ondersteund op GRS en GZRS zolang ze kleiner zijn dan of gelijk zijn aan 5 TiB.
2 Premium-bestandsshares worden ondersteund op LRS en ZRS.
3 beheerde ZRS-schijven hebben bepaalde beperkingen. Zie de sectie Beperkingen van het artikel Redundantieopties voor beheerde schijven voor meer informatie.
Ondersteunde typen opslagaccounts
In de volgende tabel ziet u welke redundantieopties worden ondersteund voor elk type opslagaccount. Zie Overzicht van opslagaccounts voor informatie over opslagaccounttypen.
Typen opslagaccount | LRS | ZRS | GRS/RA-GRS | GZRS/RA-GZRS |
---|---|---|---|---|
Aanbevolen | Standaard v2 voor algemeen gebruik (StorageV2 )1Premium-blok-blobs ( BlockBlobStorage )1Premium-bestandsshares ( FileStorage )Premium-pagina-blobs ( StorageV2 ) |
Standaard v2 voor algemeen gebruik (StorageV2 )1Premium-blok-blobs ( BlockBlobStorage )1Premium-bestandsshares ( FileStorage ) |
Standaard v2 voor algemeen gebruik (StorageV2 )1 |
Standaard v2 voor algemeen gebruik (StorageV2 )1 |
Verouderd | Standaard v1 voor algemeen gebruik (Storage )Verouderde blob ( BlobStorage ) |
N.v.t. | Standaard v1 voor algemeen gebruik (Storage )Verouderde blob ( BlobStorage ) |
N.v.t. |
1 Accounts van dit type waarvoor een hiërarchische naamruimte is ingeschakeld, ondersteunen ook de opgegeven redundantieoptie.
Alle gegevens voor alle opslagaccounts worden gekopieerd van de primaire naar de secundaire op basis van de redundantieoptie voor het opslagaccount. Objecten zoals blok-blobs, toevoeg-blobs, pagina-blobs, wachtrijen, tabellen en bestanden worden gekopieerd.
Gegevens in alle lagen, met inbegrip van de archieflaag, worden altijd gekopieerd van de primaire naar de secundaire tijdens geo-replicatie. De archieflaag voor Blob Storage wordt momenteel ondersteund voor LRS-, GRS- en RA-GRS-accounts, maar niet voor ZRS-, GZRS- of RA-GZRS-accounts. Zie Dynamische, statische en archieftoegangslagen voor blobgegevens voor meer informatie over blob-lagen.
Niet-beheerde schijven bieden geen ondersteuning voor ZRS of GZRS.
Zie Prijzen voor Azure Storage voor prijsinformatie voor elke redundantieoptie.
Notitie
Blok-blobopslagaccounts ondersteunen lokaal redundante opslag (LRS) en zone-redundante opslag (ZRS) in bepaalde regio's.
Ondersteuning voor door de klant beheerde accountfailover
Alle geografisch redundante aanbiedingen ondersteunen door Microsoft beheerde failover in het geval van een noodgeval in de primaire regio. Daarnaast bieden sommige accounttypen ondersteuning voor door de klant beheerde accountfailover, zoals wordt weergegeven in de volgende tabel:
Type failover | GRS/RA-GRS | GZRS/RA-GZRS |
---|---|---|
Door de klant beheerde failover | Algemeen v2-accounts Algemeen v1-accounts Verouderde Blob Storage-accounts | V2-accounts voor algemeen gebruik |
Door Microsoft beheerde failover | Alle accounttypen | V2-accounts voor algemeen gebruik |
Belangrijk
Klassieke opslagaccounts
Failover van door de klant beheerd account wordt alleen ondersteund voor opslagaccounts die zijn geïmplementeerd met behulp van het ARM-implementatiemodel (Azure Resource Manager). Het Implementatiemodel van Azure Service Manager (ASM), ook wel klassiek genoemd, wordt niet ondersteund. Als u klassieke opslagaccounts in aanmerking wilt laten komen voor door de klant beheerde accountfailover, moeten ze eerst worden gemigreerd naar het ARM-model. Uw opslagaccount moet toegankelijk zijn om de upgrade uit te voeren, zodat de primaire regio momenteel niet de status Mislukt kan hebben.
In het geval van een noodgeval dat van invloed is op de primaire regio, beheert Microsoft de failover voor klassieke opslagaccounts. Zie Microsoft beheerde failover voor meer informatie.
Azure Data Lake Storage Gen2
Door de klant beheerde accountfailover voor accounts met een hiërarchische naamruimte (Azure Data Lake Storage Gen2) is momenteel in PREVIEW en wordt alleen ondersteund in de volgende regio's:
- (Azië en Stille Oceaan) India - centraal
- (Europa) Zwitserland - noord
- (Europa) Zwitserland - west
- (Noord-Amerika) Canada - centraal
Als u zich wilt aanmelden voor de preview, raadpleegt u Preview-functies instellen in een Azure-abonnement en geeft u AllowHNSAccountFailover
op als de functienaam.
Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.
Zie Herstel na noodgevallen en failover van opslagaccounts voor meer informatie over herstel na noodgevallen en door de klant beheerde failover.
Gegevensintegriteit
Azure Storage controleert regelmatig de integriteit van gegevens die zijn opgeslagen met behulp van cyclische redundantiecontroles (CPC's). Als gegevensbeschadiging wordt gedetecteerd, wordt deze hersteld met behulp van redundante gegevens. Azure Storage berekent ook controlesommen voor al het netwerkverkeer om beschadiging van gegevenspakketten te detecteren bij het opslaan of ophalen van gegevens.