Delen via


Hoe door de klant beheerde (niet-geplande) failover werkt

Door de klant beheerde (niet-geplande) failover kunt u een failover uitvoeren voor uw hele geografisch redundante opslagaccount naar de secundaire regio als de opslagservice-eindpunten voor de primaire regio niet meer beschikbaar zijn. Tijdens een failover wordt de oorspronkelijke secundaire regio de nieuwe primaire regio. Alle opslagservice-eindpunten worden vervolgens omgeleid naar de nieuwe primaire regio. Nadat de storing van het opslagservice-eindpunt is opgelost, kunt u een andere failoverbewerking uitvoeren om een failback uit te voeren naar de oorspronkelijke primaire regio.

In dit artikel wordt beschreven wat er gebeurt tijdens een door de klant beheerde (niet-geplande) failover en failback in elke fase van het proces.

Belangrijk

Door de klant beheerde (niet-geplande) failover voor accounts met een hiërarchische naamruimte (Azure Data Lake Storage Gen2) of SSH File Transfer Protocol (SFTP) is momenteel in PREVIEW en wordt alleen ondersteund in de volgende regio's:

  • (Azië en Stille Oceaan) India - centraal
  • (Azië en Stille Oceaan) Azië - zuidoost
  • (Europa) Europa - noord
  • (Europa) Zwitserland - noord
  • (Europa) Zwitserland - west
  • (Europa) Europa - west
  • (Noord-Amerika) Canada - centraal
  • (Noord-Amerika) VS - oost 2
  • (Noord-Amerika) VS - zuid-centraal

Als u zich wilt aanmelden voor de preview, raadpleegt u Preview-functies instellen in het Azure-abonnement en geeft u AllowHNSAccountFailover deze 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.

In het geval van een aanzienlijke ramp die van invloed is op de primaire regio, beheert Microsoft de failover voor accounts met een hiërarchische naamruimte. Zie Microsoft beheerde failover voor meer informatie.

Redundantiebeheer tijdens niet-geplande failover en failback

Wanneer een opslagaccount is geconfigureerd voor geografisch redundante opslag (GRS) of geografisch redundante opslag met leestoegang (RA-GRS), worden gegevens drie keer gerepliceerd binnen zowel de primaire LRS- als secundaire regio's. Wanneer een opslagaccount is geconfigureerd voor geografisch zone-redundante opslag (GZRS) of leestoegang geografisch zone-redundante opslag (RA-GZRS) replicatie, zijn gegevens zone-redundant binnen de primaire ZRS-regio en drie keer gerepliceerd binnen de secundaire LRS-regio. Als het account is geconfigureerd voor leestoegang (RA), kunt u gegevens uit de secundaire regio lezen zolang de opslagservice-eindpunten voor die regio beschikbaar zijn.

Tijdens het door de klant beheerde (niet-geplande) failoverproces worden de DNS-vermeldingen (Domain Name System) voor de opslagservice-eindpunten overgeschakeld. De secundaire eindpunten van uw opslagaccount worden de nieuwe primaire eindpunten en de oorspronkelijke primaire eindpunten worden de nieuwe secundaire. Na een failover wordt de kopie van uw opslagaccount in de oorspronkelijke primaire regio verwijderd en blijft uw opslagaccount drie keer lokaal in de nieuwe primaire regio gerepliceerd. Op dat moment wordt uw opslagaccount lokaal redundant en maakt gebruik van LRS.

De oorspronkelijke en huidige redundantieconfiguraties worden opgeslagen in de eigenschappen van het opslagaccount. Met deze functionaliteit kunt u terugkeren naar de oorspronkelijke configuratie wanneer u een failback uitvoert.

Als u na een failover opnieuw wilt beschikken over georedundantie, moet u uw account opnieuw configureren als GRS. Houd er rekening mee dat GZRS geen optie na failover is omdat uw opslagaccount LRS gebruikt nadat de failover is voltooid. Nadat het account opnieuw is geconfigureerd voor georedundantie, begint Azure onmiddellijk met het kopiëren van gegevens van de nieuwe primaire regio naar de nieuwe secundaire regio. Als u uw opslagaccount configureert voor leestoegang tot de secundaire regio, is die toegang beschikbaar. Het kan echter enige tijd duren voordat de replicatie van de primaire naar de secundaire regio is voltooid.

Waarschuwing

Nadat uw account opnieuw is geconfigureerd voor georedundantie, kan het veel tijd duren voordat bestaande gegevens in de nieuwe primaire regio volledig naar de nieuwe secundaire regio worden gekopieerd.

Als u een groot gegevensverlies wilt voorkomen, controleert u de waarde van de eigenschap Laatste synchronisatietijd voordat u een failback uitvoert. Als u potentiële gegevensverlies wilt evalueren, vergelijkt u de laatste synchronisatietijd met de laatste keer waarop gegevens naar de nieuwe primaire gegevens zijn geschreven.

Het failbackproces is in wezen hetzelfde als het failoverproces, met uitzondering van Azure, herstelt de replicatieconfiguratie naar de oorspronkelijke staat voordat er een failover is uitgevoerd (de replicatieconfiguratie, niet de gegevens). Dus als uw opslagaccount oorspronkelijk is geconfigureerd als GZRS, wordt de primaire regio na failback ZRS.

Na failback kunt u uw opslagaccount opnieuw configureren om opnieuw te profiteren van geo-redundantie. Als de oorspronkelijke primaire regio is geconfigureerd voor LRS, kunt u deze configureren als GRS of RA-GRS. Als de oorspronkelijke primaire versie is geconfigureerd als ZRS, kunt u deze configureren als GZRS of RA-GZRS. Zie Wijzigen hoe een opslagaccount wordt gerepliceerd voor meer opties.

Een niet-geplande failover initiëren

Zie Een accountfailover initiëren voor meer informatie over het initiëren van een niet-geplande failover.

Let op

Niet-geplande failover omvat meestal gegevensverlies en mogelijk inconsistenties van bestanden en gegevens. Het is belangrijk om inzicht te krijgen in de impact die een accountfailover zou hebben op uw gegevens voordat u dit type failover start.

Zie Gegevensverlies en inconsistenties voorspellen voor meer informatie over mogelijk gegevensverlies en inconsistenties.

Het niet-geplande failover- en failbackproces

In deze sectie vindt u een overzicht van het failoverproces voor een door de klant beheerde (niet-geplande) failover.

Samenvatting van niet-geplande failoverovergang

Na een door de klant beheerde (niet-geplande) failover:

  • De secundaire regio wordt de nieuwe primaire regio
  • De kopie van de gegevens in de oorspronkelijke primaire regio wordt verwijderd
  • Het opslagaccount wordt geconverteerd naar LRS
  • Georedundantie gaat verloren

Deze tabel bevat een overzicht van de resulterende redundantieconfiguratie in elke fase van een door de klant beheerde (niet-geplande) failover en failback:

Origineel
configuratie
Na
failover
Na het opnieuw inschakelen
georedundantie
Na
failback
Na het opnieuw inschakelen
georedundantie
GRS LRS GRS 1 LRS GRS 1
GZRS LRS GRS 1 ZRS GZRS 1

1 Georedundantie gaat verloren tijdens een door de klant beheerde (niet-geplande) failover en moet handmatig opnieuw worden geconfigureerd.

Details van niet-geplande failoverovergang

In de volgende diagrammen ziet u wat er gebeurt tijdens door de klant beheerde (niet-geplande) failover en failback van een opslagaccount dat is geconfigureerd voor geo-redundantie. De overgangsgegevens voor GZRS en RA-GZRS verschillen enigszins van GRS en RA-GRS.

Normale werking (GRS/RA-GRS)

In normale omstandigheden schrijft een client gegevens naar een opslagaccount in de primaire regio via opslagservice-eindpunten (1). De gegevens worden vervolgens asynchroon gekopieerd van de primaire regio naar de secundaire regio (2). In de volgende afbeelding ziet u de normale status van een opslagaccount dat is geconfigureerd als GRS wanneer de primaire eindpunten beschikbaar zijn:

Diagram dat laat zien hoe clients gegevens schrijven naar het opslagaccount in de primaire regio.

De opslagservice-eindpunten zijn niet beschikbaar in de primaire regio (GRS/RA-GRS)

Als de primaire opslagservice-eindpunten om welke reden dan ook niet beschikbaar zijn (1), kan de client niet meer naar het opslagaccount schrijven. Afhankelijk van de onderliggende oorzaak van de storing, werkt de replicatie naar de secundaire regio mogelijk niet meer (2), zodat er gegevensverlies moet worden verwacht. In de volgende afbeelding ziet u het scenario waarin de primaire eindpunten niet beschikbaar zijn, maar voordat herstel plaatsvindt:

Diagram dat laat zien hoe de primaire niet beschikbaar is, zodat clients geen gegevens kunnen schrijven.

Het niet-geplande failoverproces (GRS/RA-GRS)

Als u schrijftoegang tot uw gegevens wilt herstellen, kunt u een failover initiëren. De URI's voor opslagservice-eindpunten voor blobs, tabellen, wachtrijen en bestanden blijven ongewijzigd, maar de DNS-vermeldingen worden gewijzigd zodat deze verwijzen naar de secundaire regio, zoals wordt weergegeven:

Diagram dat laat zien hoe de klant een failover van het account naar een secundair eindpunt initieert.

Door de klant beheerde (niet-geplande) failover duurt doorgaans ongeveer een uur.

Nadat de failover is voltooid, wordt de oorspronkelijke secundaire de nieuwe primaire (1) en wordt de kopie van het opslagaccount in de oorspronkelijke primaire versie verwijderd (2). Het opslagaccount is geconfigureerd als LRS in de nieuwe primaire regio en is niet langer geografisch redundant. Gebruikers kunnen het schrijven van gegevens naar het opslagaccount (3) hervatten, zoals wordt weergegeven in deze afbeelding:

Diagram met de status van het opslagaccount na een failover naar een secundaire regio.

Als u de replicatie naar een nieuwe secundaire regio wilt hervatten, configureert u het account opnieuw voor georedundantie.

Belangrijk

Houd er rekening mee dat bij het converteren van een lokaal redundant opslagaccount om georedundantie te gebruiken zowel kosten als tijd in rekening worden gebracht. Zie De tijd en kosten van failover voor meer informatie.

Nadat het account opnieuw is geconfigureerd voor het gebruik van GRS, begint Azure met het asynchroon kopiëren van uw gegevens naar de nieuwe secundaire regio (1), zoals wordt weergegeven in deze afbeelding:

Diagram met de status van het opslagaccount na een failover naar een secundaire regio als GRS.

Leestoegang tot de nieuwe secundaire regio is pas weer beschikbaar als het probleem dat de oorspronkelijke storing veroorzaakt, is opgelost.

Het niet-geplande failbackproces (GRS/RA-GRS)

Waarschuwing

Nadat uw account opnieuw is geconfigureerd voor georedundantie, kan het enige tijd duren voordat de gegevens in de nieuwe primaire regio volledig naar de nieuwe secundaire regio worden gekopieerd.

Als u een groot gegevensverlies wilt voorkomen, controleert u de waarde van de eigenschap Laatste synchronisatietijd voordat u een failback uitvoert. Vergelijk de laatste synchronisatietijd met de laatste keer dat gegevens naar de nieuwe primaire zijn geschreven om potentiële gegevensverlies te evalueren.

Nadat het probleem waardoor de oorspronkelijke storing is opgelost, kunt u failback initiëren naar de oorspronkelijke primaire regio. Dit proces wordt beschreven in de volgende afbeelding:

  1. De huidige primaire regio wordt alleen-lezen.
  2. Met door de klant geïnitieerde failover en failback kunnen uw gegevens niet worden gerepliceerd naar de secundaire regio tijdens het failbackproces. Daarom is het belangrijk om de waarde van de eigenschap Laatste synchronisatietijd te controleren voordat u een failback uitvoert.
  3. De DNS-vermeldingen voor de opslagservice-eindpunten worden overgeschakeld. De eindpunten in de secundaire regio worden de nieuwe primaire eindpunten voor uw opslagaccount.

Diagram waarin wordt getoond hoe de klant failback van het account initieert naar de oorspronkelijke primaire regio.

Nadat de failback is voltooid, wordt de oorspronkelijke primaire regio opnieuw de huidige regio (1) en wordt de kopie van het opslagaccount in de oorspronkelijke secundaire regio verwijderd (2). Het opslagaccount is geconfigureerd als lokaal redundant in de primaire regio en is niet langer geografisch redundant. Gebruikers kunnen het schrijven van gegevens naar het opslagaccount (3) hervatten, zoals wordt weergegeven in deze afbeelding:

Diagram met de status van de post-failback.

Als u de replicatie naar de oorspronkelijke secundaire regio wilt hervatten, configureert u het account voor georedundantie opnieuw.

Belangrijk

Houd er rekening mee dat bij het converteren van een lokaal redundant opslagaccount om georedundantie te gebruiken zowel kosten als tijd in rekening worden gebracht. Zie De tijd en kosten van failover voor meer informatie.

Nadat het account opnieuw is geconfigureerd als GRS, wordt de replicatie naar de oorspronkelijke secundaire regio hervat, zoals wordt weergegeven in deze afbeelding:

Diagram dat laat zien hoe de redundantieconfiguratie terugkeert naar de oorspronkelijke staat.

Zie ook