Herstel na noodgeval en failover van opslagaccount

Microsoft streeft ernaar om ervoor te zorgen dat Azure-services altijd beschikbaar zijn. Niet-geplande service-uitval kan echter optreden. Als uw toepassing tolerantie vereist, raadt Microsoft u aan geografisch redundante opslag te gebruiken, zodat uw gegevens naar een tweede regio worden gekopieerd. Daarnaast moeten klanten een noodherstelplan hebben voor het afhandelen van een regionale servicestoring. Een belangrijk onderdeel van een noodherstelplan is het voorbereiden van een fail over naar het secundaire eindpunt in het geval dat het primaire eindpunt niet meer beschikbaar is.

Azure Storage biedt ondersteuning voor account-failover voor geografisch redundante opslagaccounts. Met een failover van het account kunt u het failoverproces voor uw opslagaccount initiëren als het primaire eindpunt niet meer beschikbaar is. De failover werkt het secundaire eindpunt bij om het primaire eindpunt voor uw opslagaccount te worden. Zodra de failover is voltooid, kunnen clients beginnen met het schrijven naar het nieuwe primaire eindpunt.

Accountfailover is beschikbaar voor de typen algemeen v1, algemeen v2, en Blob-opslagaccount met Azure Resource Manager-implementaties. Account-failover wordt niet ondersteund voor opslagaccounts met een hiërarchische naamruimte ingeschakeld.

In dit artikel worden de concepten en het proces beschreven die betrokken zijn bij een failover van een account en wordt beschreven hoe u uw opslagaccount voorbereidt op herstel met de minste impact op de klant. Zie Een account-failoverinitiëren voor meer informatie over het initiëren van een account-failover in de Azure Portal of PowerShell.

De juiste redundantieoptie kiezen

Azure Storage meerdere exemplaren van uw opslagaccount onderhouden 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 bescherming tegen regionale uitval configureert u uw account voor geografisch redundante opslag, met of zonder de optie leestoegang vanuit de secundaire regio:

Geografisch redundante opslag (GRS) of geografisch zone-redundante opslag (GZRS) kopieert uw gegevens asynchroon in twee geografische regio's die ten minste honderden kilometers uit elkaar liggen. Als de primaire regio te maken heeft met een storing, fungeert de secundaire regio als een redundante bron voor uw gegevens. U kunt een failover initiëren om het secundaire eindpunt te transformeren naar het primaire eindpunt.

Geografisch redundante opslag met leestoegang (RA-GRS) of geografisch zone-redundante opslag met leestoegang (RA-GZRS) biedt geografisch redundante opslag met het extra voordeel van leestoegang tot het secundaire eindpunt. Als er een storing optreedt in het primaire eindpunt, kunnen toepassingen die zijn geconfigureerd voor leestoegang tot de secundaire en ontworpen voor hoge beschikbaarheid, blijven lezen vanaf het secundaire eindpunt. Microsoft raadt RA-GZRS aan voor maximale beschikbaarheid en duurzaamheid voor uw toepassingen.

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

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 noodherstel:

• Flexibele toepassingen ontwerpen voor Azure:een overzicht van de belangrijkste concepten voor het ontwerpen van toepassingen met hoge beschikbaarheid in Azure.
• Controlelijst voor tolerantie:een controlelijst voor het controleren of uw toepassing de beste ontwerpprocedures voor hoge beschikbaarheid implementeert.
• Geo-redundantie gebruiken om toepassingen met hoge beschikbaregegevens te ontwerpen: ontwerp richtlijnen voor het bouwen van toepassingen om te profiteren van geografisch redundante opslag.
• Zelfstudie: Eentoepassing met hoge beschikbare blobopslag bouwen: een zelfstudie die laat zien hoe u een toepassing met hoge beschikbare gegevens bouwt die automatisch tussen eindpunten schakelt wanneer fouten en herstelfouten worden gesimuleerd.

Houd ook rekening met deze best practices voor het onderhouden van hoge beschikbaarheid voor uw Azure Storage gegevens:

• Schijven: Gebruik Azure Backup back-up te maken van de VM-schijven die worden gebruikt door uw virtuele Azure-machines. U kunt ook Azure Site Recovery om uw VM's te beveiligen in het geval van een regionaal noodval.
• Blok-blobs: Schakel soft delete in om u te beschermen tegen verwijderingen en overschrijven op objectniveau, of kopieer blok-blobs naar een ander opslagaccount in een andere regio met behulp van AzCopy, Azure PowerShell ofde Azure Data Movement-bibliotheek.
• Bestanden: Gebruik Azure Backup om een back-up te maken van uw bestands shares. Schakel ook soft delete in om te beveiligen tegen onbedoelde verwijderingen van bestands delen. Voor geo-redundantie wanneer GRS niet beschikbaar is, gebruikt u AzCopy of Azure PowerShell om uw bestanden te kopiëren naar een ander opslagaccount in een andere regio.
• Tabellen: gebruik AzCopy om tabelgegevens te exporteren naar een ander opslagaccount in een andere regio.

Uitval bijhouden

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

Microsoft raadt u ook aan uw toepassing te ontwerpen om u voor te bereiden op de mogelijkheid van schrijffouten. Uw toepassing moet schrijffouten blootstellen op een manier die u waarschuwt voor de mogelijkheid van een storing in de primaire regio.

Inzicht in het failoverproces van het account

Met failover van door de klant beheerd account kunt u een failover van uw hele opslagaccount naar de secundaire regio maken als de primaire om een of andere reden niet meer beschikbaar is. Wanneer u een failover naar de secundaire regio forceren, kunnen clients beginnen met het schrijven van gegevens naar het secundaire eindpunt nadat de failover is voltooid. De failover duurt doorgaans ongeveer een uur.

Hoe een accountfailover werkt

Onder normale omstandigheden schrijft een client gegevens naar een Azure Storage-account in de primaire regio en worden die gegevens asynchroon gekopieerd naar de secundaire regio. In de volgende afbeelding ziet u het scenario waarin de primaire regio beschikbaar is:

Als het primaire eindpunt om een of andere reden niet meer beschikbaar is, kan de client niet meer schrijven naar het opslagaccount. In de volgende afbeelding ziet u het scenario waarin de primaire niet meer beschikbaar is, maar er nog geen herstel is uitgevoerd:

De klant initieert de failover van het account naar het secundaire eindpunt. Het failoverproces werkt de DNS-vermelding bij die door Azure Storage wordt geleverd, zodat het secundaire eindpunt het nieuwe primaire eindpunt voor uw opslagaccount wordt, zoals wordt weergegeven in de volgende afbeelding:

Schrijftoegang wordt hersteld voor geografisch redundante accounts zodra de DNS-vermelding is bijgewerkt en aanvragen worden omgeleid naar het nieuwe primaire eindpunt. Bestaande opslagservice-eindpunten voor blobs, tabellen, wachtrijen en bestanden blijven na de failover hetzelfde.

Gegevensverlies anticiperen

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

Wanneer u een failover forceer, gaan alle gegevens in de primaire regio verloren omdat de secundaire regio de nieuwe primaire regio wordt. De nieuwe primaire regio is geconfigureerd om na de failover lokaal redundant te zijn.

Alle gegevens die al naar de secundaire worden gekopieerd, blijven behouden wanneer de failover wordt voortgezet. Alle gegevens die naar de primaire worden geschreven en die niet ook naar de secundaire zijn gekopieerd, gaan echter permanent verloren.

De eigenschap Laatste synchronisatietijd geeft de meest recente tijd aan dat gegevens uit de primaire regio gegarandeerd naar de secundaire regio zijn geschreven. Alle gegevens die zijn geschreven vóór de laatste synchronisatietijd zijn beschikbaar op de secundaire, terwijl gegevens die zijn geschreven na de laatste synchronisatietijd mogelijk niet naar de secundaire zijn geschreven en verloren kunnen gaan. Gebruik deze eigenschap in het geval van een storing om de hoeveelheid gegevensverlies te schatten die u kunt oplopen door een account-failover te initiëren.

Ontwerp als best practice toepassing zo dat 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.

Wees voorzichtig wanneer u een fout maakt bij het terug naar de oorspronkelijke primaire

Nadat u een fail overgezet hebt van de primaire naar de secundaire regio, is uw opslagaccount geconfigureerd om lokaal redundant te zijn in de nieuwe primaire regio. Vervolgens kunt u het account configureren in de nieuwe primaire regio voor geo-redundantie. Wanneer het account is geconfigureerd voor geo-redundantie na een failover, begint de nieuwe primaire regio onmiddellijk met het kopiëren van gegevens naar de nieuwe secundaire regio, de primaire regio vóór de oorspronkelijke failover. Het kan echter enige tijd duren voordat bestaande gegevens in de nieuwe primaire versie volledig naar de nieuwe secundaire worden gekopieerd.

Nadat het opslagaccount opnieuw is geconfigureerd voor geo-redundantie, is het mogelijk om een failback van de nieuwe primaire back naar de nieuwe secundaire te initiëren. In dit geval wordt de oorspronkelijke primaire regio vóór de failover opnieuw de primaire regio en geconfigureerd om lokaal redundant of zone-redundant te zijn, afhankelijk van of de oorspronkelijke primaire configuratie GRS/RA-GRS of GZRS/RA-GZRS was. Alle gegevens in de primaire regio na de failover (de oorspronkelijke secundaire regio) gaan verloren tijdens de failback. Als de meeste gegevens in het opslagaccount niet zijn gekopieerd naar de nieuwe secundaire vóór u een failback hebt, kan er een groot gegevensverlies zijn.

Als u groot gegevensverlies wilt voorkomen, controleert u de waarde van de eigenschap Laatste synchronisatietijd voordat u een fout in de fout opsink. Vergelijk de laatste synchronisatietijd met de laatste keer dat gegevens zijn geschreven naar de nieuwe primaire om verwacht gegevensverlies te evalueren.

Na een failbackbewerking kunt u de nieuwe primaire regio opnieuw configureren als geografisch redundant. Als de oorspronkelijke primaire is geconfigureerd voor LRS, kunt u deze configureren als GRS of RA-GRS. Als de oorspronkelijke primaire server is geconfigureerd voor ZRS, kunt u deze configureren als GZRS of RA-GZRS. Zie Wijzigen hoe een opslagaccount wordt gerepliceerd voor aanvullende opties.

Een failover van account initiëren

U kunt een account-failover initiëren vanuit Azure Portal, PowerShell, Azure CLI of de API Azure Storage resourceprovider. Zie Een account-failoverinitiëren voor meer informatie over het initiëren van een failover.

Aanvullende overwegingen

Bekijk de aanvullende overwegingen die in deze sectie worden beschreven om te begrijpen hoe uw toepassingen en services kunnen worden beïnvloed wanneer u een failover forceer.

Opslagaccount met gearchiveerde blobs

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

Opslagresourceprovider

Nadat een failover is voltooid, kunnen clients de gegevens Azure Storage in de nieuwe primaire regio opnieuw lezen en schrijven. De resourceprovider Azure Storage echter geen fail over, 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 heeft, retournt de eigenschap Location de oorspronkelijke primaire locatie nadat de failover is voltooid.

Azure-VM's

Voor virtuele Azure-machines (VM's) wordt geen failover uitgevoerd als onderdeel van een account-failover. Als de primaire regio niet meer beschikbaar is en u een failover naar de secundaire regio hebt, moet u na de failover alle VM's opnieuw maken. Er is ook een mogelijk gegevensverlies dat is gekoppeld aan de failover van het account. Microsoft raadt de volgende richtlijnen voor hoge beschikbaarheid en herstel na noodherstel aan die specifiek zijn voor virtuele machines in Azure.

Niet-mande azure-schijven

Als best practice raadt Microsoft u aan om niet-beheerde schijven te converteren naar beheerde schijven. Als u echter een failover moet uitvoeren voor een account dat niet-managede schijven bevat die zijn gekoppeld aan azure-VM's, moet u de VM afsluiten voordat u de failover start.

Niet-mande schijven worden opgeslagen als pagina-blobs in Azure Storage. Wanneer een VM wordt uitgevoerd in Azure, worden alle niet-mande schijven die aan de VM zijn gekoppeld, geleased. Een failover van een account kan niet worden doorgemaakt 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 niet-mande schijven, de logische eenheidsnummers (LUN) en de VM waaraan ze zijn gekoppeld. Als u dit doet, is het eenvoudiger om de schijven opnieuw teattachen na de failover.
2. Sluit de virtuele machine af.
3. Verwijder de VM, maar behoud de VHD-bestanden voor de niet-beherende schijven. Noteer het tijdstip waarop u de VM hebt verwijderd.
4. Wacht totdat de laatste synchronisatietijd is bijgewerkt en is later dan het tijdstip waarop u de VM 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 failover van het account.
6. Wacht totdat de failover van het account is voltooid en de secundaire regio de nieuwe primaire regio is geworden.
7. Maak een VM in de nieuwe primaire regio en wijs de VHD's opnieuw aan.
8. Start de nieuwe VM.

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

Niet-ondersteunde functies en services

De volgende functies en services worden niet ondersteund voor failover van het account:

• Azure File Sync biedt geen ondersteuning voor failover van opslagaccounts. Er mag geen failover-overschakeling worden uitgevoerd voor opslagaccounts met Azure-bestandsshares die worden gebruikt als cloudeindpunten in Azure File Sync. Als u dat wel doet, werkt de synchronisatie niet meer en kan dit leiden tot onverwacht gegevensverlies van bestanden in cloudlagen.
• Storage accounts met hiërarchische naamruimte ingeschakeld (zoals voor Data Lake Storage Gen2) worden op dit moment niet ondersteund.
• Een opslagaccount met premium blok-blobs kan niet worden overgeslagen. Storage-accounts die ondersteuning bieden voor premium blok-blobs bieden momenteel geen ondersteuning voor geo-redundantie.
• Er kan geen failed over worden genomen voor een opslagaccount met containers met een WORM-beleid voor onveranderbaarheid. Vergrendelde/vergrendelde beleidsregels voor retentie op basis van tijd of juridische bewaring voorkomen failover om naleving te behouden.

Gegevens kopiëren als alternatief voor failover

Als uw opslagaccount is geconfigureerd voor leestoegang tot de secundaire server, kunt u uw toepassing zo ontwerpen dat deze vanaf het secundaire eindpunt kan worden gelezen. Als u liever geen fail over wilt uitvoeren in het geval van een storing in de primaire regio, kunt u hulpprogramma's zoals AzCopy, Azure PowerShell ofde Azure Data Movement-bibliotheek gebruiken om gegevens van uw opslagaccount in de secundaire regio te kopiëren naar een ander opslagaccount in een niet-beïnvloede regio. U kunt uw toepassingen vervolgens naar dat opslagaccount laten wijzen voor zowel lees- als schrijfbeschikbaarheid.

Door Microsoft beheerde failover

In uitzonderlijke gevallen waarin een regio verloren gaat als gevolg van een aanzienlijke ramp, kan Microsoft een regionale failover initiëren. In dit geval is er geen actie van uw kant 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.

Zie ook

• Geo-redundantie gebruiken om toepassingen met hoge beschikbare gegevens te ontwerpen
• Een failover van account initiëren
• Controleer de eigenschap Laatste synchronisatietijd voor een opslagaccount
• Zelfstudie: Een maximaal beschikbare toepassing bouwen met Blob-opslag