Hoe failover van door de klant beheerde opslagaccounts werkt
Door de klant beheerde failover van Azure Storage-accounts stelt u in staat om een failover uit te voeren voor uw hele geografisch redundante opslagaccount naar de secundaire regio als de opslagservice-eindpunten voor de primaire regio niet meer beschikbaar zijn. Tijdens de failover wordt de oorspronkelijke secundaire regio de nieuwe primaire regio en worden alle opslagservice-eindpunten voor blobs, tabellen, wachtrijen en bestanden 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 failover van een door de klant beheerd opslagaccount en failback in elke fase van het proces.
Belangrijk
Failover van door de klant beheerde accounts 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
- (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 failover en failback
Tip
Voor meer informatie over de verschillende redundantiestatussen tijdens de failover van het opslagaccount en het failbackproces raadpleegt u Azure Storage-redundantie voor definities van elke status.
Wanneer een opslagaccount is geconfigureerd voor GRS- of RA-GRS-redundantie, worden gegevens drie keer lokaal gerepliceerd binnen zowel de primaire als secundaire regio's (LRS). Wanneer een opslagaccount is geconfigureerd voor replicatie van GZRS of RA-GZRS, zijn gegevens zone-redundant binnen de primaire regio (ZRS) en drie keer lokaal gerepliceerd binnen de secundaire regio (LRS). 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 failoverproces worden de DNS-vermeldingen voor de opslagservice-eindpunten zodanig gewijzigd dat deze voor de secundaire regio de nieuwe primaire eindpunten voor uw opslagaccount worden. Na een failover wordt de kopie van uw opslagaccount in de oorspronkelijke primaire regio verwijderd en wordt uw opslagaccount drie keer lokaal gerepliceerd binnen de oorspronkelijke secundaire regio (de nieuwe primaire regio). Op dat moment wordt uw opslagaccount lokaal redundant (LRS).
De oorspronkelijke en huidige redundantieconfiguraties worden opgeslagen in de eigenschappen van het opslagaccount, zodat u uiteindelijk terugkeert 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. (GZRS is geen optie na failover, omdat de nieuwe primaire lrs na de failover is). 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 (RA) naar de secundaire regio, is die toegang beschikbaar, maar het kan enige tijd duren voordat de replicatie van de primaire regio de secundaire stroom heeft.
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. Vergelijk de laatste synchronisatietijd met de laatste keer dat gegevens naar de nieuwe primaire zijn geschreven om potentiële gegevensverlies te evalueren.
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 faillback ZRS.
Na failback kunt u uw opslagaccount zo configureren dat dit opnieuw geografisch redundant is. 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 aanvullende opties.
Een failover initiëren
Let op
Failover van opslagaccounts 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 er een initieert.
Zie Gegevensverlies en inconsistenties voorspellen voor meer informatie over mogelijk gegevensverlies en inconsistenties.
Het failover- en failbackproces
In deze sectie wordt het failoverproces voor een door de klant beheerde failover samengevat.
Samenvatting van failoverovergang
Na een door de klant beheerde 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 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 failover en moet handmatig opnieuw worden geconfigureerd.
Details van failoverovergang
In de volgende diagrammen ziet u wat er gebeurt tijdens door de klant beheerde 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:
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), dus er moet een aantal gegevensverlies worden verwacht. In de volgende afbeelding ziet u het scenario waarin de primaire eindpunten niet meer beschikbaar zijn, maar er nog geen herstel is opgetreden:
Het failoverproces (GRS/RA-GRS)
Als u schrijftoegang tot uw gegevens wilt herstellen, kunt u een failover initiëren. De URI's van het opslagservice-eindpunt voor blobs, tabellen, wachtrijen en bestanden blijven hetzelfde, maar de DNS-vermeldingen worden gewijzigd zodat deze verwijzen naar de secundaire regio (1), zoals weergegeven in deze afbeelding:
Failover die door de klant wordt beheerd, 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:
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 als GRS, begint Azure met het asynchroon kopiëren van uw gegevens naar de nieuwe secundaire regio (1), zoals wordt weergegeven in deze afbeelding:
Leestoegang tot de nieuwe secundaire regio wordt pas weer beschikbaar als het probleem waardoor de oorspronkelijke storing is opgelost.
Het 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.
Zodra het probleem waardoor de oorspronkelijke storing is opgelost, kunt u een andere failover initiëren om een failback uit te voeren naar de oorspronkelijke primaire regio, wat resulteert in het volgende:
- De huidige primaire regio wordt alleen-lezen.
- Met door de klant geïnitieerde failover en failback kunnen uw gegevens tijdens het failbackproces niet worden gerepliceerd naar de secundaire regio. Daarom is het belangrijk om de waarde van de eigenschap Laatste synchronisatietijd te controleren voordat u een failback uitvoert.
- De DNS-vermeldingen voor de opslagservice-eindpunten worden gewijzigd, zodat deze voor de secundaire regio de nieuwe primaire eindpunten voor uw opslagaccount worden.
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:
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:
