Herstel na noodgevallen en failover voor Azure Files
Microsoft streeft ernaar om ervoor te zorgen dat Azure-services altijd beschikbaar zijn. Er kunnen echter niet-geplande servicestoringen optreden en u moet een noodherstelplan (DR) hebben voor het afhandelen van een storing in de regionale service. Een belangrijk onderdeel van een noodherstelplan is het voorbereiden van een failover naar het secundaire eindpunt in het geval dat het primaire eindpunt niet meer beschikbaar is. In dit artikel worden de concepten en processen beschreven die betrekking hebben op noodherstel (DR) en failover van opslagaccounts.
Belangrijk
Azure File Sync biedt alleen ondersteuning voor failover van opslagaccounts als de opslagsynchronisatieservice ook een failover-overschakeling heeft uitgevoerd. Dit komt doordat Azure File Sync vereist dat het opslagaccount en de opslagsynchronisatieservice zich in dezelfde Azure-regio bevinden. Als alleen een failover van het opslagaccount is uitgevoerd, mislukken synchronisatie- en cloudlaagbewerkingen totdat de opslagsynchronisatieservice is overgeschakeld naar de secundaire regio. Als u een failover wilt uitvoeren voor een opslagaccount met Azure-bestandsshares die worden gebruikt als cloudeindpunten in Azure File Sync, raadpleegt u best practices voor herstel na noodgevallen van Azure File Sync en herstel van De Azure File Sync-server.
Metrische gegevens en kosten voor herstel
Om een effectieve DR-strategie te formuleren, moet een organisatie het volgende begrijpen:
- Hoeveel gegevens het zich kan veroorloven om te verliezen in geval van een onderbreking (herstelpuntdoelstelling of RPO)
- Hoe snel het moet kunnen herstellen van bedrijfsfuncties en -gegevens (hersteltijddoelstelling of RTO)
De kosten van dr nemen doorgaans toe met lagere of nul RPO/RTO. Bedrijven die na een noodgeval in een paar seconden actief moeten zijn en geen gegevensverlies kunnen ondersteunen, betalen meer voor herstel na noodgeval, terwijl mensen met hogere RPO/RTO-nummers minder betalen. Azure biedt oplossingen die kunnen werken met verschillende RPO- en RTO-vereisten.
De juiste redundantieoptie kiezen
Azure Files biedt verschillende redundantieopties om uw gegevens te beschermen tegen geplande en ongeplande gebeurtenissen, variërend van tijdelijke hardwarestoringen, netwerk- en stroomstoringen tot natuurrampen. Alle Azure-bestandsshares kunnen lokaal redundant (LRS) of zone-redundante opslag (ZRS) gebruiken. Zie Azure Files-redundantie voor meer informatie.
Azure Files biedt ondersteuning voor accountfailover voor standaardopslagaccounts die zijn geconfigureerd met geografisch redundante opslag (GRS) en geografisch zone-redundante opslag (GZRS) voor bescherming tegen regionale storingen. 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 zodat dit het primaire eindpunt voor uw opslagaccount wordt. Zodra de failover is voltooid, kunnen clients schrijven naar het nieuwe primaire eindpunt.
GRS en GZRS lopen nog steeds een risico op gegevensverlies omdat gegevens asynchroon naar de secundaire regio worden gekopieerd, wat betekent dat er een vertraging is voordat een schrijfbewerking naar de primaire regio naar de secundaire regio wordt gekopieerd. In het geval van een storing gaan schrijfbewerkingen naar het primaire eindpunt dat nog niet naar het secundaire eindpunt is gekopieerd, verloren. Dit betekent dat een fout die van invloed is op de primaire regio kan leiden tot gegevensverlies als de primaire regio niet kan worden hersteld. Het interval tussen de meest recente schrijfbewerkingen naar de primaire regio en de laatste schrijfbewerking naar de secundaire regio is de RPO. Azure Files heeft doorgaans een RPO van 15 minuten of minder, hoewel er momenteel geen SLA is over hoe lang het duurt om gegevens te repliceren naar de secundaire regio.
Belangrijk
GRS/GZRS worden niet ondersteund voor premium Azure-bestandsshares. U kunt echter synchroniseren tussen twee Azure-bestandsshares om geografische redundantie te bereiken.
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 voor SMB-bestandsshares.
We raden u ook aan uw toepassing te ontwerpen om u voor te bereiden op schrijffouten. Uw toepassing moet schrijffouten zichtbaar maken op een manier die u waarschuwt voor de mogelijkheid van een storing in de primaire regio.
Ontwerp uw toepassing als best practice om de eigenschap Last Sync Time te controleren 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.
Storingen bijhouden
U kunt zich abonneren op het Azure Service Health-dashboard om de status en status van Azure Files en andere Azure-services bij te houden.
Inzicht in het failoverproces van het account
Door de klant beheerde accountfailover stelt u in staat om uw hele opslagaccount uit te schakelen naar de secundaire regio als de primaire om welke reden dan ook niet beschikbaar is. Wanneer u een failover naar de secundaire regio afdingt, kunnen clients beginnen met het schrijven van gegevens naar het secundaire eindpunt nadat de failover is voltooid. De failover duurt doorgaans ongeveer een uur. Het is raadzaam om uw werkbelasting zoveel mogelijk te onderbreken voordat u een accountfailover start.
Zie Een accountfailover initiëren voor meer informatie over het initiëren van een accountfailover.
Hoe een accountfailover werkt
In normale omstandigheden schrijft een client gegevens naar een opslagaccount 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 welke reden dan ook niet meer beschikbaar is, kan de client niet meer naar het opslagaccount schrijven. In de volgende afbeelding ziet u het scenario waarin de primaire server niet meer beschikbaar is, maar er nog geen herstel is gebeurd:
De klant initieert de accountfailover naar het secundaire eindpunt. Het failoverproces werkt de DNS-vermelding van Azure Storage bij, zodat het secundaire eindpunt het nieuwe primaire eindpunt wordt voor uw opslagaccount, 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 blijven hetzelfde na de failover. Bestandsingangen en leases worden niet bewaard bij failover, dus clients moeten de bestandsshares ontkoppelen en opnieuw koppelen.
Belangrijk
Nadat de failover is voltooid, is het opslagaccount zo geconfigureerd dat het lokaal redundant is in het nieuwe primaire eindpunt/de nieuwe primaire regio. Als u de replicatie naar de nieuwe secundaire site wilt hervatten, configureert u het account opnieuw voor georedundantie.
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 Belangrijke gevolgen van accountfailover voor meer informatie.
Anticiperen op gegevensverlies
Let op
Een accountfailover gaat meestal gepaard met gegevensverlies. Het is belangrijk om inzicht te krijgen in de gevolgen van het initiëren van een accountfailover.
Omdat gegevens asynchroon van de primaire regio naar de secundaire regio worden geschreven, zijn de meest recente schrijfbewerkingen mogelijk nog niet gekopieerd naar de secundaire regio als de primaire regio niet meer beschikbaar is.
Wanneer u een failover afdingt, gaan alle gegevens in de primaire regio verloren wanneer de secundaire regio de nieuwe primaire regio wordt. De nieuwe primaire regio is zo geconfigureerd dat deze lokaal redundant is na de failover.
Alle gegevens die al naar de secundaire worden gekopieerd, blijven behouden wanneer de failover plaatsvindt. Gegevens die naar de primaire gegevens worden geschreven die niet ook naar de secundaire server zijn gekopieerd, gaan echter permanent verloren.
De eigenschap Laatst gesynchroniseerd controleren
De eigenschap Last Sync Time (LST) geeft de meest recente tijd aan dat gegevens uit de primaire regio gegarandeerd naar de secundaire regio zijn geschreven. Alle gegevens die vóór de laatste synchronisatietijd zijn geschreven, zijn beschikbaar op de secundaire, terwijl gegevens die na de laatste synchronisatietijd zijn geschreven, mogelijk niet naar de secundaire zijn geschreven en verloren gaan. Gebruik deze eigenschap in het geval van een storing om een schatting te maken van de hoeveelheid gegevensverlies die u kunt ondervinden door een accountfailover te starten.
Om ervoor te zorgen dat bestandsshares een consistente status hebben wanneer er een failover plaatsvindt, wordt er elke 15 minuten een systeemmomentopname gemaakt in de primaire regio en gerepliceerd naar de secundaire regio. Wanneer er een failover plaatsvindt naar de secundaire regio, wordt de status van de share gebaseerd op de meest recente momentopname van het systeem in de secundaire regio. Als er een fout optreedt in de primaire regio, bevindt de secundaire regio zich waarschijnlijk achter de primaire regio, omdat alle schrijfbewerkingen naar de primaire regio nog niet naar de secundaire regio zijn gerepliceerd. Vanwege geografische vertraging of andere problemen kan de meest recente systeemmomentopname in de secundaire regio ouder zijn dan 15 minuten.
Alle schrijfbewerkingen die naar de primaire regio zijn geschreven voordat de LST is gerepliceerd naar de secundaire regio, wat betekent dat ze beschikbaar zijn om te worden gelezen uit de secundaire regio. Schrijfbewerkingen die na de laatste synchronisatietijd naar de primaire regio zijn geschreven, zijn mogelijk of niet gerepliceerd naar de secundaire regio, wat betekent dat ze mogelijk niet beschikbaar zijn voor leesbewerkingen.
U kunt een query uitvoeren op de waarde van de eigenschap Last Sync Time met behulp van Azure PowerShell, Azure CLI of de clientbibliotheek. De eigenschap Laatste synchronisatietijd is een GMT-datum/tijd-waarde. Zie De eigenschap Laatste synchronisatietijd controleren voor een opslagaccount voor meer informatie.
Wees voorzichtig wanneer u een failback naar de oorspronkelijke primaire versie uitvoert
Zoals eerder vermeld, is uw opslagaccount, nadat u een failover van de primaire naar de secundaire regio hebt uitgevoerd, geconfigureerd om lokaal redundant te zijn in de nieuwe primaire regio. Vervolgens kunt u het account configureren in de nieuwe primaire regio voor georedundantie. Wanneer het account is geconfigureerd voor georedundantie 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 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 naar de nieuwe secundaire te starten. In dit geval wordt de oorspronkelijke primaire regio voordat de failover de primaire regio opnieuw wordt en is geconfigureerd om lokaal redundant of zone-redundant te zijn, afhankelijk van of de oorspronkelijke primaire configuratie GRS of GZRS is. Alle gegevens in de primaire regio na failover (de oorspronkelijke secundaire) gaan verloren tijdens de failback. Als de meeste gegevens in het opslagaccount niet naar de nieuwe secundaire zijn gekopieerd voordat u een failback uitvoert, kan er sprake zijn van een groot gegevensverlies.
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 het verwachte gegevensverlies te evalueren.
Na een failbackbewerking kunt u de nieuwe primaire regio zo configureren dat deze opnieuw geografisch redundant is. Als de oorspronkelijke primaire versie is geconfigureerd voor LRS, kunt u deze configureren als GRS. Als de oorspronkelijke primaire server is geconfigureerd voor ZRS, kunt u deze configureren als GZRS. Zie Wijzigen hoe een opslagaccount wordt gerepliceerd voor aanvullende opties.
Een failover van account initiëren
U kunt een accountfailover starten vanuit Azure Portal, PowerShell, Azure CLI of de API van de Azure Storage-resourceprovider. Zie Een accountfailover initiëren voor meer informatie over het initiëren van een failover.
Door Microsoft beheerde failover
In extreme omstandigheden waarin een regio verloren gaat vanwege een aanzienlijke ramp, kan Microsoft een regionale failover initiëren. In dit geval hoeft u geen actie te ondernemen. Totdat de door Microsoft beheerde failover is voltooid, hebt u geen schrijftoegang tot uw opslagaccount.