Planning en failover voor herstel na noodgevallen in Azure Storage

Microsoft streeft ernaar om ervoor te zorgen dat Azure-services altijd beschikbaar zijn. Er kunnen echter niet-geplande servicestoringen optreden. Belangrijke onderdelen van een goed plan voor herstel na noodgevallen omvatten strategieën voor:

• Gegevensbeveiliging
• Back-up en herstel
• Gegevensredundantie
• Failover
• Toepassingen ontwerpen voor hoge beschikbaarheid

Dit artikel is gericht op failover voor wereldwijd redundante opslagaccounts (GRS, GZRS en RA-GZRS) en het ontwerpen van uw toepassingen voor maximale beschikbaarheid als er een storing en daaropvolgende failover is.

De juiste redundantieoptie kiezen

Azure Storage onderhoudt meerdere kopieën van uw opslagaccount om duurzaamheid en hoge beschikbaarheid te garanderen. Welke redundantieoptie u voor uw account kiest, is afhankelijk van de mate van tolerantie die u nodig hebt voor uw toepassingen.

Met lokaal redundante opslag (LRS) worden drie kopieën van uw opslagaccount automatisch opgeslagen en gerepliceerd binnen één datacenter. Met zone-redundante opslag (ZRS) wordt een kopie opgeslagen en gerepliceerd in elk van de drie afzonderlijke beschikbaarheidszones binnen dezelfde regio. Zie Azure-beschikbaarheidszones voor meer informatie over beschikbaarheidszones.

Herstel van één kopie van een opslagaccount vindt automatisch plaats met LRS en ZRS.

Wereldwijd redundante opslag en failover

Met wereldwijd redundante opslag (GRS, GZRS en RA-GZRS) kopieert Azure uw gegevens asynchroon naar een secundaire geografische regio ten minste honderden kilometers verderop. Hierdoor kunt u uw gegevens herstellen als er een storing optreedt in de primaire regio. Een functie die wereldwijd redundante opslag onderscheidt van LRS en ZRS is de mogelijkheid om een failover uit te schakelen naar de secundaire regio als er een storing is in de primaire regio. Tijdens het uitvoeren van een failover worden de DNS-vermeldingen voor uw opslagaccountservice-eindpunten bijgewerkt, zodat de eindpunten voor de secundaire regio de nieuwe primaire eindpunten voor uw opslagaccount worden. Zodra de failover is voltooid, kunnen clients beginnen met schrijven naar de nieuwe primaire eindpunten.

RA-GRS- en RA-GZRS-redundantieconfiguraties bieden geografisch redundante opslag met het extra voordeel van leestoegang tot het secundaire eindpunt als er een storing is in de primaire regio. Als er een storing optreedt in het primaire eindpunt, kunnen toepassingen die zijn geconfigureerd voor leestoegang tot de secundaire regio en die zijn ontworpen voor hoge beschikbaarheid, blijven lezen vanaf het secundaire eindpunt. Microsoft raadt RA-GZRS aan voor maximale beschikbaarheid en duurzaamheid van uw opslagaccounts.

Zie Azure Storage-redundantie voor meer informatie over redundantie in Azure Storage.

Failover van opslagaccount plannen

Azure Storage-accounts ondersteunen twee soorten failover:

• Door de klant beheerde failover : klanten kunnen failover van opslagaccounts beheren als er een onverwachte servicestoring is.
• Door Microsoft beheerde failover : mogelijk geïnitieerd door Microsoft in het geval van een ernstige ramp in de primaire regio. ^1,2

¹Door Microsoft beheerde failover kan niet worden gestart voor afzonderlijke opslagaccounts, abonnementen of tenants. Zie Voor meer informatie, door Microsoft beheerde failover.
² Uw plan voor herstel na noodgevallen moet zijn gebaseerd op door de klant beheerde failover. Vertrouw niet op door Microsoft beheerde failover, die alleen in extreme omstandigheden wordt gebruikt.

Elk type failover heeft een unieke set gebruiksvoorbeelden, bijbehorende verwachtingen voor gegevensverlies en ondersteuning voor accounts waarvoor een hiërarchische naamruimte is ingeschakeld (Azure Data Lake Storage Gen2). Deze tabel bevat een overzicht van de aspecten van elk type failover:

Door de klant beheerde failover

Als de gegevenseindpunten voor de opslagservices in uw opslagaccount niet meer beschikbaar zijn in de primaire regio, kunt u een failover naar de secundaire regio uitvoeren. Nadat de failover is voltooid, wordt de secundaire regio de nieuwe primaire regio en kunnen gebruikers toegang krijgen tot gegevens in de nieuwe primaire regio.

Om volledig inzicht te krijgen in de impact die door de klant beheerde accountfailover zou hebben op uw gebruikers en toepassingen, is het handig om te weten wat er gebeurt tijdens elke stap van het failover- en failbackproces. Zie Hoe failover van door de klant beheerde opslagaccounts werkt voor meer informatie over hoe het proces werkt.

Door Microsoft beheerde failover

In extreme omstandigheden waarin de oorspronkelijke primaire regio binnen een redelijke tijd onherstelbaar wordt geacht vanwege een grote ramp, kan Microsoft een regionale failover initiëren. In dit geval is er geen actie voor uw onderdeel vereist. Totdat de door Microsoft beheerde failover is voltooid, hebt u geen schrijftoegang tot uw opslagaccount. Uw toepassingen kunnen lezen uit de secundaire regio als uw opslagaccount is geconfigureerd voor RA-GRS of RA-GZRS.

Anticiperen op gegevensverlies en inconsistenties

Omdat gegevens asynchroon van de primaire regio naar de secundaire regio worden geschreven, is er altijd een vertraging voordat een schrijfbewerking naar de primaire regio naar de secundaire regio wordt gekopieerd. Als de primaire regio niet meer beschikbaar is, zijn de meest recente schrijfbewerkingen mogelijk nog niet gekopieerd naar de secundaire regio.

Wanneer er een failover optreedt, gaan alle gegevens in de primaire regio verloren wanneer de secundaire regio de nieuwe primaire regio wordt. Alle gegevens die al naar de secundaire worden gekopieerd, blijven behouden wanneer de failover plaatsvindt. Alle gegevens die naar de primaire gegevens zijn geschreven die niet ook naar de secundaire regio zijn gekopieerd, gaan echter permanent verloren.

De nieuwe primaire regio is geconfigureerd voor lokaal redundant (LRS) na de failover.

Mogelijk ondervindt u ook inconsistenties in bestanden of gegevens als voor uw opslagaccounts een of meer van de volgende opties zijn ingeschakeld:

• Hiërarchische naamruimte (Azure Data Lake Storage Gen2)
• Wijzigingenfeed
• Herstel naar een bepaald tijdstip voor blok-blobs

Laatste synchronisatietijd

De eigenschap Last Sync Time geeft de meest recente tijd aan dat gegevens uit de primaire regio gegarandeerd naar de secundaire regio zijn geschreven. Voor accounts met een hiërarchische naamruimte is dezelfde eigenschap Last Sync Time ook van toepassing op de metagegevens die worden beheerd door de hiërarchische naamruimte, inclusief ACL's. Alle gegevens en metagegevens die vóór de laatste synchronisatietijd zijn geschreven, zijn beschikbaar op de secundaire, terwijl gegevens en metagegevens die na de laatste synchronisatietijd zijn geschreven, mogelijk niet naar de secundaire zijn geschreven en verloren gaan. Gebruik deze eigenschap als er een storing is om een schatting te maken van de hoeveelheid gegevensverlies die u kunt ondervinden door een accountfailover te starten.

Ontwerp uw toepassing als best practice, zodat u de laatste synchronisatietijd kunt gebruiken om het verwachte gegevensverlies te evalueren. Als u bijvoorbeeld alle schrijfbewerkingen vasthoudt, kunt u de tijd van uw laatste schrijfbewerkingen vergelijken met de laatste synchronisatietijd om te bepalen welke schrijfbewerkingen niet zijn gesynchroniseerd met de secundaire.

Zie de eigenschap Laatste synchronisatietijd controleren voor een opslagaccount voor meer informatie over het controleren van de eigenschap Laatste synchronisatietijd.

Bestandsconsistentie voor Azure Data Lake Storage Gen2

Replicatie voor opslagaccounts waarvoor een hiërarchische naamruimte is ingeschakeld (Azure Data Lake Storage Gen2) vindt plaats op bestandsniveau. Dit betekent dat als er een storing in de primaire regio optreedt, slechts enkele bestanden in een container of map mogelijk zijn gerepliceerd naar de secundaire regio. Consistentie voor alle bestanden in een container of map nadat een failover van een opslagaccount niet is gegarandeerd.

Inconsistenties van wijzigingenfeed- en blobgegevens

Failover van opslagaccounts van geografisch redundante opslagaccounts waarvoor wijzigingenfeed is ingeschakeld, kan leiden tot inconsistenties tussen de wijzigingenfeedlogboeken en de blobgegevens en/of metagegevens. Dergelijke inconsistenties kunnen het gevolg zijn van de asynchrone aard van zowel updates in de wijzigingslogboeken als de replicatie van blobgegevens van de primaire naar de secundaire regio. De enige situatie waarin inconsistenties niet worden verwacht, is wanneer alle huidige logboekrecords zijn leeggemaakt naar de logboekbestanden en alle opslaggegevens zijn gerepliceerd van de primaire naar de secundaire regio.

Zie Hoe de wijzigingenfeed werkt voor informatie over hoe de wijzigingenfeed werkt.

Houd er rekening mee dat voor andere opslagaccountfuncties de wijzigingenfeed moet worden ingeschakeld, zoals operationele back-ups van Azure Blob Storage, objectreplicatie en herstel naar een bepaald tijdstip voor blok-blobs.

Inconsistenties voor herstel naar een bepaald tijdstip

Door de klant beheerde failover wordt ondersteund voor opslagaccounts in de standard-laag v2 voor algemeen gebruik die blok-blobs bevatten. Als u echter een door de klant beheerde failover uitvoert op een opslagaccount, wordt het vroegst mogelijke herstelpunt voor het account opnieuw ingesteld. Gegevens voor herstel naar een bepaald tijdstip voor blok-blobs zijn alleen consistent tot de voltooiingstijd van de failover. Als gevolg hiervan kunt u blok-blobs alleen herstellen naar een tijdstip dat niet eerder is dan de voltooiingstijd van de failover. U kunt de voltooiingstijd van de failover controleren op het tabblad Redundantie van uw opslagaccount in Azure Portal.

Stel dat u de bewaarperiode hebt ingesteld op 30 dagen. Als er meer dan 30 dagen zijn verstreken sinds de failover, kunt u herstellen naar een willekeurig punt binnen die 30 dagen. Als er echter minder dan 30 dagen zijn verstreken sinds de failover, kunt u niet herstellen naar een punt vóór de failover, ongeacht de bewaarperiode. Als het bijvoorbeeld 10 dagen geleden is sinds de failover, is het vroegst mogelijke herstelpunt 10 dagen in het verleden, niet 30 dagen in het verleden.

De tijd en kosten van failover

De tijd die nodig is om de failover te voltooien nadat deze is gestart, kan variëren, hoewel het doorgaans minder dan één uur duurt.

Een door de klant beheerde failover verliest de georedundantie na een failover (en failback). Uw opslagaccount wordt automatisch tijdens een failover geconverteerd naar lokaal redundante opslag (LRS) in de nieuwe primaire regio en het opslagaccount in de oorspronkelijke primaire regio wordt verwijderd.

U kunt geografisch redundante opslag (GRS) of geografisch redundante opslag met leestoegang (RA-GRS) voor het account opnieuw inschakelen, maar houd er rekening mee dat voor het converteren van LRS naar GRS of RA-GRS extra kosten in rekening worden gebracht. De kosten worden veroorzaakt door de kosten voor uitgaand netwerk om de gegevens opnieuw te repliceren naar de nieuwe secundaire regio. Bovendien moeten alle gearchiveerde blobs worden gerehydrateerd naar een onlinelaag voordat het account kan worden geconfigureerd voor geo-redundantie, wat kosten met zich meebrengt. Zie voor meer informatie over prijzen:

• Prijsinformatie voor bandbreedte
• Prijzen voor Azure Storage

Nadat u GRS opnieuw hebt ingeschakeld voor uw opslagaccount, begint Microsoft met het repliceren van de gegevens in uw account naar de nieuwe secundaire regio. Replicatietijd is afhankelijk van veel factoren, waaronder:

• Het aantal en de grootte van de objecten in het opslagaccount. Het repliceren van veel kleine objecten kan langer duren dan het repliceren van minder en grotere objecten.
• De beschikbare resources voor achtergrondreplicatie, zoals CPU, geheugen, schijf en WAN-capaciteit. Liveverkeer heeft prioriteit boven geo-replicatie.
• Als uw opslagaccount blobs bevat, is het aantal momentopnamen per blob.
• Als uw opslagaccount tabellen bevat, wordt de strategie voor gegevenspartitionering gebruikt. Het replicatieproces kan niet groter zijn dan het aantal partitiesleutels dat u gebruikt.

Ondersteunde typen opslagaccounts

Alle geografisch redundante aanbiedingen ondersteunen door Microsoft beheerde failover. Bovendien ondersteunen sommige accounttypen failover van door de klant beheerde accounts, zoals wordt weergegeven in de volgende tabel:

Klassieke opslagaccounts

Azure Data Lake Storage Gen2

Niet-ondersteunde functies en services

De volgende functies en services worden niet ondersteund voor accountfailover:

• Azure File Sync biedt geen ondersteuning voor door de klant geïnitieerde failover van het opslagaccount. Opslagaccounts met Azure-bestandsshares die worden gebruikt als cloudeindpunten in Azure File Sync, mogen geen failover-overschakeling uitvoeren. Als u dat wel doet, werkt de synchronisatie niet meer en kan dit leiden tot onverwacht gegevensverlies van bestanden in cloudlagen. Zie Best practices voor herstel na noodgevallen met Azure File Sync voor meer informatie.
• Een opslagaccount met premium blok-blobs kan geen failover uitvoeren. Opslagaccounts die ondersteuning bieden voor premium blok-blobs bieden momenteel geen ondersteuning voor georedundantie.
• Door de klant beheerde failover wordt niet ondersteund voor de bron- of het doelaccount in een objectreplicatiebeleid.
• Als u een failover wilt uitvoeren van een account waarvoor SFTP (SSH File Transfer Protocol) is ingeschakeld, moet u eerst SFTP uitschakelen voor het account. Als u het gebruik van SFTP wilt hervatten nadat de failover is voltooid, schakelt u deze opnieuw in.
• Network File System (NFS) 3.0 (NFSv3) wordt niet ondersteund voor failover van het opslagaccount. U kunt geen opslagaccount maken dat is geconfigureerd voor globale redundantie waarvoor NFSv3 is ingeschakeld.

Failover is niet voor accountmigratie

Failover van opslagaccounts mag niet worden gebruikt als onderdeel van uw strategie voor gegevensmigratie. Failover is een tijdelijke oplossing voor een servicestoring. Zie het overzicht van Azure Storage-migratie voor informatie over het migreren van uw opslagaccounts.

Opslagaccounts met gearchiveerde blobs

Opslagaccounts met gearchiveerde blobs ondersteunen failover van accounts. Nadat een door de klant beheerde failover is voltooid, moeten alle gearchiveerde blobs echter opnieuw worden gerehydrateerd naar een onlinelaag voordat het account kan worden geconfigureerd voor geo-redundantie.

Opslagresourceprovider

Microsoft biedt twee REST API's voor het werken met Azure Storage-resources. Deze API's vormen de basis van alle acties die u kunt uitvoeren op Azure Storage. Met de REST API van Azure Storage kunt u werken met gegevens in uw opslagaccount, waaronder blob-, wachtrij-, bestands- en tabelgegevens. Met de REST API van de Azure Storage-resourceprovider kunt u het opslagaccount en de gerelateerde resources beheren.

Nadat een failover is voltooid, kunnen clients Azure Storage-gegevens opnieuw lezen en schrijven in de nieuwe primaire regio. De Azure Storage-resourceprovider voert echter geen failover uit, dus resourcebeheerbewerkingen moeten nog steeds plaatsvinden in de primaire regio. Als de primaire regio niet beschikbaar is, kunt u geen beheerbewerkingen uitvoeren op het opslagaccount.

Omdat de Azure Storage-resourceprovider geen failover uitvoert, retourneert de eigenschap Location de oorspronkelijke primaire locatie nadat de failover is voltooid.

Azure-VM's

Virtuele Azure-machines (VM's) voeren geen failover uit als onderdeel van een accountfailover. Als de primaire regio niet meer beschikbaar is en u een failover naar de secundaire regio uitvoert, moet u de VM's na de failover opnieuw maken. Er is ook een mogelijk gegevensverlies dat is gekoppeld aan de accountfailover. Microsoft raadt aan de richtlijnen voor hoge beschikbaarheid en herstel na noodgevallen te volgen die specifiek zijn voor virtuele machines in Azure.

Houd er rekening mee dat alle gegevens die zijn opgeslagen op een tijdelijke schijf verloren gaan wanneer de VIRTUELE machine wordt afgesloten.

Niet-beheerde Azure-schijven

Als best practice raadt Microsoft aan om niet-beheerde schijven te converteren naar beheerde schijven. Als u echter een failover moet uitvoeren voor een account dat niet-beheerde schijven bevat die zijn gekoppeld aan Virtuele Azure-machines, moet u de VIRTUELE machine afsluiten voordat u de failover start.

Niet-beheerde schijven worden opgeslagen als pagina-blobs in Azure Storage. Wanneer een VIRTUELE machine wordt uitgevoerd in Azure, worden niet-beheerde schijven die aan de VIRTUELE machine zijn gekoppeld, geleased. Een accountfailover kan niet worden voortgezet wanneer er een lease op een blob is. Voer de volgende stappen uit om de failover uit te voeren:

1. Voordat u begint, noteert u de namen van onbeheerde schijven, hun logische eenheidsnummers (LUN) en de VM waaraan ze zijn gekoppeld. Als u dit doet, is het eenvoudiger om de schijven na de failover opnieuw te koppelen.
2. Sluit de virtuele machine af.
3. Verwijder de VIRTUELE machine, maar behoud de VHD-bestanden voor de niet-beheerde schijven. Let op het tijdstip waarop u de VIRTUELE machine hebt verwijderd.
4. Wacht tot de laatste synchronisatietijd is bijgewerkt en is later dan het tijdstip waarop u de virtuele machine hebt verwijderd. Deze stap is belangrijk, omdat als het secundaire eindpunt niet volledig is bijgewerkt met de VHD-bestanden wanneer de failover plaatsvindt, de VM mogelijk niet goed werkt in de nieuwe primaire regio.
5. Start de accountfailover.
6. Wacht totdat de accountfailover is voltooid en de secundaire regio de nieuwe primaire regio is geworden.
7. Maak een VIRTUELE machine in de nieuwe primaire regio en plaats de VHD's opnieuw bij elkaar.
8. Start de nieuwe VIRTUELE machine.

Houd er rekening mee dat alle gegevens die zijn opgeslagen op een tijdelijke schijf verloren gaan wanneer de VIRTUELE machine wordt afgesloten.

Gegevens kopiëren als alternatief voor failover

Als uw opslagaccount is geconfigureerd voor leestoegang tot de secundaire regio, kunt u uw toepassing ontwerpen om te lezen vanuit het secundaire eindpunt. Als u liever geen failover wilt uitvoeren als er een storing is in de primaire regio, kunt u hulpprogramma's zoals AzCopy of Azure PowerShell gebruiken om gegevens van uw opslagaccount in de secundaire regio naar een ander opslagaccount in een niet-beïnvloede regio te kopiëren. Vervolgens kunt u uw toepassingen naar dat opslagaccount laten verwijzen voor zowel lees- als schrijfbaarheid.

Ontwerpen voor hoge beschikbaarheid

Het is belangrijk om uw toepassing vanaf het begin te ontwerpen voor hoge beschikbaarheid. Raadpleeg deze Azure-resources voor hulp bij het ontwerpen van uw toepassing en het plannen van herstel na noodgevallen:

• Flexibele toepassingen ontwerpen voor Azure: een overzicht van de belangrijkste concepten voor het ontwerpen van maximaal beschikbare toepassingen in Azure.
• Controlelijst voor tolerantie: een controlelijst voor het controleren of uw toepassing de aanbevolen ontwerpprocedures voor hoge beschikbaarheid implementeert.
• Gebruik georedundantie om maximaal beschikbare toepassingen te ontwerpen: ontwerprichtlijnen voor het bouwen van toepassingen om te profiteren van geografisch redundante opslag.
• Zelfstudie: Een maximaal beschikbare toepassing bouwen met Blob Storage: een zelfstudie die laat zien hoe u een maximaal beschikbare toepassing bouwt die automatisch schakelt tussen eindpunten als fouten en herstelbewerkingen worden gesimuleerd.

Houd rekening met deze aanbevolen procedures voor het onderhouden van hoge beschikbaarheid voor uw Azure Storage-gegevens:

• Schijven: Gebruik Azure Backup om een back-up te maken van de VM-schijven die worden gebruikt door uw virtuele Azure-machines. Overweeg ook om Azure Site Recovery te gebruiken om uw VM's te beveiligen als er een regionaal noodgeval is.
• Blok-blobs: schakel voorlopig verwijderen in om te beveiligen tegen verwijderingen op objectniveau en overschrijven, of kopieer blok-blobs naar een ander opslagaccount in een andere regio met behulp van AzCopy, Azure PowerShell of de Azure Data Movement-bibliotheek.
• Bestanden: Gebruik Azure Backup om een back-up te maken van uw bestandsshares. Schakel voorlopig verwijderen ook in om te beveiligen tegen onbedoelde verwijderingen van bestandsshares. Voor georedundantie wanneer GRS niet beschikbaar is, gebruikt u AzCopy of Azure PowerShell om uw bestanden naar een ander opslagaccount in een andere regio te kopiëren.
• Tabellen: gebruik AzCopy om tabelgegevens te exporteren naar een ander opslagaccount in een andere regio.

Storingen bijhouden

Klanten kunnen zich abonneren op het Azure Service Health-dashboard om de status en status van Azure Storage en andere Azure-services bij te houden.

Microsoft raadt u ook aan uw toepassing zo te ontwerpen dat deze is voorbereid op de mogelijkheid van schrijffouten. Uw toepassing moet schrijffouten zichtbaar maken op een manier die u waarschuwt voor de mogelijkheid van een storing in de primaire regio.

Zie ook

• Georedundantie gebruiken om maximaal beschikbare toepassingen te ontwerpen
• Zelfstudie: Een maximaal beschikbare toepassing bouwen met Blob Storage
• Azure Storage-redundantie
• Hoe failover van door de klant beheerde opslagaccounts werkt