Planning en failover voor herstel na noodgevallen in Azure Storage
Microsoft streeft ernaar om ervoor te zorgen dat Azure-services altijd beschikbaar zijn. Niet-geplande servicestoringen kunnen echter af en toe 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
In dit artikel worden de opties beschreven die beschikbaar zijn voor wereldwijd redundante opslagaccounts en aanbevelingen voor het ontwikkelen van maximaal beschikbare toepassingen en het testen van uw plan voor herstel na noodgevallen.
De juiste redundantieoptie kiezen
Azure Storage onderhoudt meerdere kopieën van uw opslagaccount om ervoor te zorgen dat aan beschikbaarheids- en duurzaamheidsdoelen wordt voldaan, zelfs als er fouten optreden. De manier waarop gegevens worden gerepliceerd, biedt verschillende beveiligingsniveaus. Elke optie biedt zijn eigen voordelen, dus de optie die u kiest, is afhankelijk van de mate van tolerantie die uw toepassingen nodig hebben.
Lokaal redundante opslag (LRS), de optie voor redundantie van de laagste kosten, slaat en repliceert automatisch drie kopieën van uw opslagaccount binnen één datacenter. Hoewel LRS uw gegevens beschermt tegen serverrek- en stationsfouten, is er geen rekening met rampen zoals brand of overstromingen binnen een datacenter. In het gevolg van dergelijke rampen kunnen alle replica's van een opslagaccount dat is geconfigureerd voor het gebruik van LRS verloren gaan of onherstelbaar zijn.
Ter vergelijking: zone-redundante opslag (ZRS) behoudt een kopie van een opslagaccount en repliceert deze in elk van de drie afzonderlijke beschikbaarheidszones binnen dezelfde regio. Zie Azure-beschikbaarheidszones voor meer informatie over beschikbaarheidszones.
Geografisch redundante opslag en failover
Geografisch redundante opslag (GRS), geografisch zone-redundante opslag (GZRS) en geografisch zone-redundante opslag met leestoegang (RA-GZRS) zijn voorbeelden van globaal redundante opslagopties. Wanneer deze is geconfigureerd voor het gebruik van wereldwijd redundante opslag (GRS, GZRS en RA-GZRS), kopieert Azure uw gegevens asynchroon naar een secundaire geografische regio. Deze regio's bevinden zich honderden of zelfs duizenden kilometers verderop. Met dit redundantieniveau kunt u uw gegevens herstellen als er een storing is in de hele primaire regio.
In tegenstelling tot LRS en ZRS biedt wereldwijd redundante opslag ook ondersteuning voor een niet-geplande failover naar een secundaire regio als er een storing is in de primaire regio. Tijdens het failoverproces worden DNS-vermeldingen (Domain Name System) voor de service-eindpunten van uw opslagaccount automatisch bijgewerkt, zodat de eindpunten van de secundaire regio de nieuwe primaire eindpunten worden. Zodra de niet-geplande failover is voltooid, kunnen clients beginnen met het schrijven naar de nieuwe primaire eindpunten.
Geografisch redundante opslag met leestoegang (RA-GRS) en geografisch zone-redundante opslag met leestoegang (RA-GZRS) bieden ook geografisch redundante opslag, maar bieden het extra voordeel van leestoegang tot het secundaire eindpunt. Deze opties zijn ideaal voor toepassingen die zijn ontworpen voor bedrijfskritieke toepassingen met hoge beschikbaarheid. Als het primaire eindpunt een storing ondervindt, kunnen toepassingen die zijn geconfigureerd voor leestoegang tot de secundaire regio, blijven werken. Microsoft raadt RA-GZRS aan voor maximale beschikbaarheid en duurzaamheid van uw opslagaccounts.
Zie Azure Storage-redundantie voor meer informatie over redundantie voor Azure Storage.
Plannen voor failover
Azure Storage-accounts ondersteunen drie typen failover:
- Door de klant beheerde geplande failover (preview): klanten kunnen failover van het opslagaccount beheren om hun plan voor herstel na noodgevallen te testen.
- Door de klant beheerde (niet-geplande) failover : klanten kunnen failover van opslagaccounts beheren als er een onverwachte servicestoring is.
- Door Microsoft beheerde failover : mogelijk geïnitieerd door Microsoft vanwege een ernstige ramp in de primaire regio. 1,2
1 Door Microsoft beheerde failover kan niet worden gestart voor afzonderlijke opslagaccounts, abonnementen of tenants. Zie Microsoft beheerde failover voor meer informatie.
2 Gebruik door de klant beheerde failoveropties om uw noodherstelplannen te ontwikkelen, te testen en te implementeren. 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:
| Type | Failoverbereik | Gebruiksscenario | Verwacht gegevensverlies | HNS (Hierarchical Namespace) ondersteund |
|---|---|---|---|---|
| Door de klant beheerde geplande failover (preview) | Opslagaccount | De opslagservice-eindpunten voor de primaire en secundaire regio's zijn beschikbaar en u wilt noodhersteltests uitvoeren. De opslagservice-eindpunten voor de primaire regio zijn beschikbaar, maar een andere service voorkomt dat uw workloads goed werken. Om proactief voor te bereiden op grootschalige rampen, zoals een orkaan, die een regio kan beïnvloeden. |
Nee | Ja (In preview) |
| Door de klant beheerde (niet-geplande) failover | Opslagaccount | De opslagservice-eindpunten voor de primaire regio zijn niet beschikbaar, maar de secundaire regio is beschikbaar. U hebt een Azure-advies ontvangen waarin Microsoft u adviseert om een failoverbewerking uit te voeren van opslagaccounts die mogelijk worden beïnvloed door een storing. |
Ja | Ja (In preview) |
| Door Microsoft beheerd | Hele regio | De primaire regio is niet meer beschikbaar vanwege een aanzienlijke ramp, maar de secundaire regio is beschikbaar. | Ja | Ja |
De volgende tabel vergelijkt de redundantiestatus van een opslagaccount na elk type failover:
| Resultaat van failover op... | Door de klant beheerde geplande failover (preview) | Door de klant beheerde (niet-geplande) failover |
|---|---|---|
| ... de secundaire regio | De secundaire regio wordt de nieuwe primaire regio | De secundaire regio wordt de nieuwe primaire regio |
| ... de oorspronkelijke primaire regio | De oorspronkelijke primaire regio wordt de nieuwe secundaire | De kopie van de gegevens in de oorspronkelijke primaire regio wordt verwijderd |
| ... de configuratie van accountredundantie | Het opslagaccount wordt geconverteerd naar GRS | Het opslagaccount wordt geconverteerd naar LRS |
| ... de configuratie van georedundantie | Geo-redundantie blijft behouden | Georedundantie gaat verloren |
De volgende tabel bevat een overzicht van de resulterende redundantieconfiguratie in elke fase van het failover- en failbackproces voor elk type failover:
| Origineel configuratie |
Na failover |
Na het opnieuw inschakelen georedundantie |
Na failback |
Na het opnieuw inschakelen georedundantie |
|---|---|---|---|---|
| Door de klant beheerde geplande failover | ||||
| GRS | GRS | n/a 1 | GRS | n/a 1 |
| GZRS | GRS | n/a 1 | GZRS | n/a 1 |
| Door de klant beheerde (niet-geplande) failover | ||||
| GRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
1 Georedundantie wordt bewaard tijdens een geplande failover en hoeft niet handmatig opnieuw te worden geconfigureerd.
Door de klant beheerde geplande failover (preview)
Geplande failover kan worden gebruikt in meerdere scenario's, waaronder geplande noodhersteltests, een proactieve benadering van grootschalige rampen of om te herstellen van niet-opslaggerelateerde storingen.
Tijdens het geplande failoverproces worden de primaire en secundaire regio's gewisseld. De oorspronkelijke primaire regio wordt gedegradeerd en wordt de nieuwe secundaire regio. Tegelijkertijd wordt de oorspronkelijke secundaire regio gepromoveerd en wordt het nieuwe primaire gebied. Nadat de failover is voltooid, kunnen gebruikers toegang krijgen tot gegevens in de nieuwe primaire regio en kunnen beheerders hun noodherstelplan valideren. Het opslagaccount moet beschikbaar zijn in zowel de primaire als de secundaire regio's voordat een geplande failover kan worden gestart.
Gegevensverlies wordt niet verwacht tijdens het geplande failover- en failbackproces, zolang de primaire en secundaire regio's gedurende het hele proces beschikbaar zijn. Zie de sectie Gegevensverlies en inconsistenties anticiperen voor meer informatie.
Om inzicht te krijgen in het effect van dit type failover voor uw gebruikers en toepassingen, is het handig om te weten wat er gebeurt tijdens elke stap van de geplande failover- en failbackprocessen. Zie Hoe door de klant beheerde (geplande) failover werkt voor meer informatie over hoe dit proces werkt.
Belangrijk
Door de klant beheerde geplande failover is momenteel in PREVIEW en beperkt tot de volgende regio's:
- Frankrijk - centraal
- Frankrijk - zuid
- India - centraal
- India - west
- Azië - oost
- Azië - zuidoost
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.
Als u zich wilt aanmelden voor de preview, raadpleegt u Preview-functies instellen in het Azure-abonnement en geeft u AllowSoftFailover deze op als de functienaam. De providernaam voor deze preview-functie is Microsoft.Storage.
Belangrijk
Na een geplande failover kan de LST-waarde (Last Sync Time) van een opslagaccount verlopen zijn of als NULL worden gerapporteerd wanneer Azure Files-gegevens aanwezig zijn.
Systeemmomentopnamen worden periodiek gemaakt in de secundaire regio van een opslagaccount om consistente herstelpunten te onderhouden die worden gebruikt tijdens een failover en failback. Het initiëren van door de klant beheerde geplande failover zorgt ervoor dat de oorspronkelijke primaire regio de nieuwe secundaire regio wordt. In sommige gevallen zijn er geen systeemmomentopnamen beschikbaar op de nieuwe secundaire nadat de geplande failover is voltooid, waardoor de totale LST-waarde van het account verouderd wordt weergegeven of als wordt weergegeven Null.
Omdat gebruikersactiviteiten zoals het maken, wijzigen of verwijderen van objecten het maken van momentopnamen kunnen activeren, heeft elk account waarop deze activiteiten plaatsvinden na geplande failover geen extra aandacht nodig. Accounts zonder momentopnamen of gebruikersactiviteit kunnen echter een Null LST-waarde blijven weergeven totdat het maken van een systeemmomentopname wordt geactiveerd.
Voer zo nodig een van de volgende activiteiten uit voor elke share in een opslagaccount om het maken van momentopnamen te activeren. Na voltooiing moet uw account binnen 30 minuten een geldige LST-waarde weergeven.
- Koppel de share en open vervolgens een bestand om te lezen.
- Upload een test- of voorbeeldbestand naar de share.
Door de klant beheerde (niet-geplande) failover
Als de gegevenseindpunten voor de opslagservices in uw opslagaccount niet meer beschikbaar zijn in de primaire regio, kunt u een niet-geplande failover naar de secundaire regio initiëren. Nadat de failover is voltooid, wordt de secundaire regio de nieuwe primaire regio en kunnen gebruikers daar toegang krijgen tot gegevens.
Om inzicht te hebben in het effect van dit type failover voor uw gebruikers en toepassingen, is het handig om te weten wat er gebeurt tijdens elke stap van het niet-geplande failover- en failbackproces. Zie Hoe door de klant beheerde (niet-geplande) failover werkt voor meer informatie over hoe het proces werkt.
Door Microsoft beheerde failover
Microsoft kan in extreme omstandigheden een regionale failover initiëren, zoals een catastrofale ramp die van invloed is op een hele geografische regio. Tijdens deze gebeurtenissen is er geen actie voor uw onderdeel vereist. Als uw opslagaccount is geconfigureerd voor RA-GRS of RA-GZRS, kunnen uw toepassingen lezen uit de secundaire regio tijdens een door Microsoft beheerde failover. U hebt echter geen schrijftoegang tot uw opslagaccount totdat het failoverproces is voltooid.
Belangrijk
Gebruik door de klant beheerde failoveropties om uw noodherstelplannen te ontwikkelen, te testen en te implementeren. Vertrouw niet op door Microsoft beheerde failover, die alleen in extreme omstandigheden kan worden gebruikt. Een door Microsoft beheerde failover wordt geïnitieerd voor een volledige fysieke eenheid, zoals een regio of een datacenter. Het kan niet worden gestart voor afzonderlijke opslagaccounts, abonnementen of tenants. Als u de mogelijkheid nodig hebt om selectief een failover uit te voeren voor uw afzonderlijke opslagaccounts, gebruikt u door de klant beheerde geplande failover.
Anticiperen op gegevensverlies en inconsistenties
Let op
Niet-geplande failover die door de klant wordt beheerd, omvat meestal enige hoeveelheid gegevensverlies en kan mogelijk ook inconsistenties van bestanden en gegevens veroorzaken. In uw plan voor herstel na noodgevallen is het belangrijk om rekening te houden met de impact die een accountfailover op uw gegevens zou hebben voordat u er een initieert.
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 beschikbaar is, is het mogelijk dat de meest recente schrijfbewerkingen nog niet naar de secundaire worden gekopieerd.
Wanneer er een niet-geplande 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 regio zijn gekopieerd, blijven behouden wanneer de failover plaatsvindt. Gegevens die zijn geschreven naar de primaire gegevens die nog niet bestaan in de secundaire regio, 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 Laatste synchronisatietijd geeft het meest recente tijdstip aan waarop gegevens uit de primaire regio ook naar de secundaire regio zijn geschreven. Voor accounts met een hiërarchische naamruimte geldt dezelfde eigenschap Last Sync Time ook voor de metagegevens die worden beheerd door de hiërarchische naamruimte, inclusief toegangsbeheerlijsten (ACL's). Alle gegevens en metagegevens die vóór de laatste synchronisatietijd zijn geschreven, zijn beschikbaar op de secundaire. Gegevens en metagegevens die na de laatste synchronisatietijd zijn geschreven, kunnen daarentegen nog niet naar de secundaire worden gekopieerd en kunnen mogelijk verloren gaan. Gebruik deze eigenschap tijdens een storing om de hoeveelheid gegevensverlies te schatten die u mogelijk ondervindt bij het initiëren van een accountfailover.
Ontwerp uw toepassing als best practice, zodat u de laatste synchronisatietijd kunt gebruiken om het verwachte gegevensverlies te evalueren. Door bijvoorbeeld alle schrijfbewerkingen te registreren, kunt u de tijden van uw laatste schrijfbewerking vergelijken met de laatste synchronisatietijd. Met deze methode kunt u bepalen welke schrijfbewerkingen nog niet zijn gesynchroniseerd met de secundaire en in gevaar zijn om verloren te gaan.
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. Omdat replicatie op dit niveau plaatsvindt, kan een storing in de primaire regio voorkomen dat sommige bestanden in een container of map met succes worden 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
Door de klant beheerde (niet-geplande) failover van 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 wijzigingenlogboekupdates en gegevensreplicatie tussen de primaire en secundaire regio's. U kunt inconsistenties voorkomen door de volgende voorzorgsmaatregelen te nemen:
- Zorg ervoor dat alle logboekrecords worden leeggemaakt in de logboekbestanden.
- Zorg ervoor dat alle opslaggegevens worden gerepliceerd van de primaire naar de secundaire regio.
Zie Hoe de wijzigingenfeed werkt voor meer informatie over de wijzigingenfeed.
Houd er rekening mee dat voor andere functies van het opslagaccount ook de wijzigingenfeed moet worden ingeschakeld. Deze functies omvatten 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.
De tijd en kosten van failover
De tijd die nodig is om een door de klant beheerde failover te voltooien nadat deze is gestart, kan variëren, hoewel het doorgaans minder dan één uur duurt.
Een geplande door de klant beheerde failover verliest de georedundantie niet na een failover en daaropvolgende failback, maar een niet-geplande door de klant beheerde failover wel.
Als u een door de klant beheerde niet-geplande failover initieert, wordt uw opslagaccount automatisch geconverteerd naar lokaal redundante opslag (LRS) in een nieuwe primaire regio en wordt het opslagaccount in de oorspronkelijke primaire regio verwijderd.
U kunt geografisch redundante opslag (GRS) of geografisch redundante opslag met leestoegang (RA-GRS) voor het account opnieuw inschakelen, maar voor het repliceren van gegevens naar de nieuwe secundaire regio worden kosten in rekening gebracht. Daarnaast moeten gearchiveerde blobs worden gerehydrateerd naar een onlinelaag voordat het account opnieuw kan worden geconfigureerd voor geo-redundantie. Bij deze rehydratatie worden ook extra kosten in rekening gebracht. Zie voor meer informatie over prijzen:
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. De hoeveelheid tijd die nodig is om de replicatie te voltooien, is afhankelijk van verschillende factoren. Deze factoren zijn onder andere:
- 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.
- Het aantal momentopnamen per blob, indien van toepassing.
- De strategie voor gegevenspartitionering als uw opslagaccount tabellen bevat. 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:
| Type failover | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|
| Door de klant beheerde geplande failover (preview) | V2-accounts voor algemeen gebruik v1-accounts voor algemeen gebruik v1-accounts verouderde Blob Storage-accounts |
V2-accounts voor algemeen gebruik |
| Door de klant beheerde (niet-geplande) failover | V2-accounts voor algemeen gebruik v1-accounts voor algemeen gebruik v1-accounts verouderde Blob Storage-accounts |
V2-accounts voor algemeen gebruik |
| Door Microsoft beheerde failover | Alle accounttypen | V2-accounts voor algemeen gebruik |
Klassieke opslagaccounts
Belangrijk
Door de klant beheerde failover 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 bekend als het klassieke model, wordt niet ondersteund. Als u wilt dat klassieke opslagaccounts in aanmerking komen voor failover van door de klant beheerde accounts, 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.
Tijdens een noodgeval dat van invloed is op de primaire regio, beheert Microsoft de failover voor klassieke opslagaccounts. Zie Microsoft beheerde failover voor meer informatie.
Hiërarchische naamruimte (HNS)
Belangrijk
Door de klant beheerde (niet-geplande) failover voor accounts waarvoor Azure Data Lake Storage Gen2 is ingeschakeld, is momenteel in PREVIEW en wordt ondersteund in alle openbare GRS/GZRS-regio's.
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.
Belangrijk
Door de klant beheerde (niet-geplande) failover voor accounts waarvoor SSH File Transfer Protocol (SFTP) is ingeschakeld, 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.
Niet-ondersteunde functies en services
De volgende functies en services worden niet ondersteund voor door de klant beheerde failover:
- Azure File Sync biedt geen ondersteuning voor failover van door de klant beheerde accounts. Opslagaccounts die worden gebruikt als cloudeindpunten voor Azure File Sync, mogen geen failover-overschakeling uitvoeren. Failover verstoort bestandssynchronisatie en kan leiden tot onverwacht gegevensverlies van nieuw gelaagde bestanden. 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.
- 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.
De volgende tabel kan worden gebruikt om te verwijzen naar functieondersteuning.
| Geplande failover | Niet-geplande failover | |
|---|---|---|
| ADLS Gen2 | Ondersteund (preview) | Ondersteund (preview) |
| Wijzigingenfeed | Niet ondersteund | Ondersteund |
| Objectreplicatie | Niet ondersteund | Niet ondersteund |
| SFTP | Ondersteund (preview) | Ondersteund (preview) |
| NFSv3 | GRS wordt niet ondersteund | GRS wordt niet ondersteund |
| Opslagacties | Niet ondersteund | Niet ondersteund |
| Herstel naar een bepaald tijdstip (PITR) | Niet ondersteund | Ondersteund |
Failover is niet voor accountmigratie
Failovers van opslagaccounts zijn een tijdelijke oplossing die kan worden gebruikt om uw DR-plannen te plannen en te testen of om te herstellen na een servicestoring. Failover mag niet worden gebruikt als onderdeel van uw strategie voor gegevensmigratie. 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 failover van een opslagaccount. Vm's waarvoor een failover is uitgevoerd naar een secundaire regio als reactie op een storing, moeten opnieuw worden gemaakt nadat de failover is voltooid. Accountfailover kan leiden tot verlies van gegevens die zijn opgeslagen op een tijdelijke schijf wanneer de virtuele machine (VM) wordt afgesloten. Microsoft raadt aan de richtlijnen voor hoge beschikbaarheid en herstel na noodgevallen te volgen die specifiek zijn voor virtuele machines in Azure.
Niet-beheerde Azure-schijven
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. Voordat een failover kan worden gestart op een account met niet-beheerde schijven die zijn gekoppeld aan Virtuele Azure-machines, moeten de schijven worden afgesloten. Daarom zijn de aanbevolen best practices van Microsoft onder andere het converteren van onbeheerde schijven naar beheerde schijven.
Voer de volgende stappen uit om een failover uit te voeren op een account met niet-beheerde schijven:
- 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.
- Sluit de virtuele machine af.
- Verwijder de virtuele machine, maar behoud de VHD-bestanden (virtuele harde schijf) voor de niet-beheerde schijven. Let op het tijdstip waarop u de VIRTUELE machine hebt verwijderd.
- Wacht totdat de laatste synchronisatietijd is bijgewerkt en zorg ervoor dat deze later is dan het tijdstip waarop u de virtuele machine hebt verwijderd. Deze stap zorgt ervoor dat het secundaire eindpunt volledig wordt bijgewerkt met de VHD-bestanden wanneer de failover plaatsvindt en dat de VM correct werkt in de nieuwe primaire regio.
- Start de accountfailover.
- Wacht totdat de accountfailover is voltooid en de secundaire regio de nieuwe primaire regio wordt.
- Maak een VIRTUELE machine in de nieuwe primaire regio en plaats de VHD's opnieuw bij elkaar.
- 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 failover-alternatief
Zoals eerder besproken, kunt u hoge beschikbaarheid behouden door toepassingen te configureren voor het gebruik van een opslagaccount dat is geconfigureerd voor leestoegang tot een secundaire regio. Als u echter liever geen failover wilt uitvoeren tijdens een storing binnen de primaire regio, kunt u uw gegevens handmatig kopiëren als alternatief. Met hulpprogramma's zoals AzCopy en Azure PowerShell kunt u gegevens uit uw opslagaccount in de betrokken regio kopiëren naar een ander opslagaccount in een niet-beïnvloede regio. Nadat de kopieerbewerking is voltooid, kunt u uw toepassingen opnieuw configureren om het opslagaccount in de niet-betrokken regio te gebruiken voor zowel lees- als schrijf beschikbaarheid.
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.
Raadpleeg deze aanbevolen procedures om hoge beschikbaarheid voor uw Azure Storage-gegevens te behouden:
- 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 beschermen tegen een regionaal noodgeval.
- 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.