Delen via

Planning en failover voor herstel na noodgevallen in Azure Storage

  • Artikel

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:

In dit artikel worden de opties beschreven die beschikbaar zijn voor geografisch 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 geografisch redundante opslagopties. Wanneer deze is geconfigureerd voor het gebruik van geografisch 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 geografisch 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:

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). 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 van invloed kunnen zijn op een regio.		 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-opgeslagen 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.

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:

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

Replicatie voor opslagaccounts waarvoor een hiërarchische naamruimte is ingeschakeld (Azure Data Lake Storage) 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.

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.

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

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 georedundantie waarvoor NFSv3 is ingeschakeld.

De volgende tabel kan worden gebruikt om te verwijzen naar functieondersteuning.

Geplande failover Niet-geplande failover
Azure Data Lake Storage 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 Ondersteund1 Ondersteund1
Herstel naar een bepaald tijdstip (PITR) Niet ondersteund Ondersteund

1 Als u een door de klant beheerde geplande of niet-geplande failover initieert, kunnen opslagtaken pas worden uitgevoerd op het account als er een failback naar de oorspronkelijke primaire regio wordt uitgevoerd. Meer informatie.

Failover is niet voor accountmigratie

Failovers van opslagaccounts zijn een tijdelijke oplossing die wordt gebruikt voor het ontwikkelen en testen van noodherstelplannen of voor het herstellen van 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 in het opslagaccount.

Omdat de Azure Storage-resourceprovider geen failover uitvoert, retourneert de eigenschap Locatie 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:

  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 (virtuele harde schijf) voor de niet-beheerde schijven. Let op het tijdstip waarop u de VIRTUELE machine hebt verwijderd.
  4. 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.
  5. Start de accountfailover.
  6. Wacht totdat de accountfailover is voltooid en de secundaire regio de nieuwe primaire regio wordt.
  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 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:

Raadpleeg deze aanbevolen procedures om hoge beschikbaarheid voor uw Azure Storage-gegevens te behouden:

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