Delen via

Betrouwbaarheid in Azure Files

In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure Files beschreven. Azure Files biedt volledig beheerde bestandsshares in de cloud die toegankelijk zijn via SMB-protocollen (Server Message Block) en Network File System (NFS).

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure Files tolerant maakt voor verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen. Er wordt ook beschreven hoe je back-ups kunt gebruiken om te herstellen van andere soorten problemen en enkele kerninformatie over de Service Level Agreement (SLA) van Azure Files belicht.

Opmerking

Azure Files maakt deel uit van het Azure Storage-platform. Sommige van de mogelijkheden van Azure Files zijn gebruikelijk in veel Azure Storage-services. In dit artikel gebruiken we Azure Storage om te verwijzen naar deze algemene mogelijkheden.

Aanbevelingen voor productie-implementatie

Zie Architectuur-best practices voor Azure Files in het Azure Well-Architected Framework voor informatie over hoe u Azure Files kunt implementeren ter ondersteuning van de betrouwbaarheidsvereisten van uw oplossing en hoe de betrouwbaarheid van invloed is op andere aspecten van uw architectuur.

Overzicht van betrouwbaarheidsarchitectuur

Lokaal redundante opslag (LRS) repliceert de gegevens in uw opslagaccounts naar een of meer Azure-beschikbaarheidszones die zich in de primaire regio van uw keuze bevinden. Hoewel er geen optie is om de gewenste beschikbaarheidszone te kiezen, kan Azure LRS-accounts verplaatsen of uitbreiden tussen zones om de taakverdeling te verbeteren. Er is geen garantie dat uw gegevens worden verspreid over zones. Zie Wat zijn beschikbaarheidszones? voor meer informatie over beschikbaarheidszones.

Diagram dat laat zien hoe gegevens worden gerepliceerd in beschikbaarheidszones met behulp van LRS.

Zone-redundante opslag (ZRS), geografisch redundante opslag (GRS) en geografisch zone-redundante opslag (GZRS) bieden extra beveiliging. In dit artikel worden deze opties uitgebreid beschreven.

Azure Files is beschikbaar in twee medialagen:

  • De Premium-laag maakt gebruik van SSD's (Solid State Drives) voor hoge prestaties. Deze laag wordt aanbevolen voor workloads waarvoor lage latentie is vereist.

  • De Standard-laag ondersteunt harde schijven (HDD). HDD-bestandsshares bieden een rendabele opslagoptie voor bestandsshares voor algemeen gebruik.

Zie voor meer informatie Plan to deploy Azure Files - Storage tiers.

Azure Files implementeert redundantie op opslagaccountniveau en bestandsshares nemen die redundantieconfiguratie automatisch over. De service ondersteunt meerdere redundantiemodellen die verschillen in hun benadering van gegevensbeveiliging.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Als u tijdelijke fouten effectief wilt beheren wanneer u Azure Files gebruikt, configureert u de juiste time-outwaarden voor uw bestandsbewerkingen op basis van de bestandsgrootte en netwerkvoorwaarden. Voor grotere bestanden zijn langere time-outs vereist, terwijl kleinere bewerkingen kortere waarden kunnen gebruiken om fouten snel te detecteren.

Om ervoor te zorgen dat alleen beveiligde verbindingen tot stand worden gebracht met uw NFS-share, raden we u aan een privé-eindpunt voor uw opslagaccount te configureren. Een privé-eindpunt maakt gebruik van Azure Private Link om een statisch IP-adres toe te wijzen aan uw opslagaccount vanuit de privéadresruimte van uw virtuele netwerk. Een privé-eindpunt helpt te voorkomen dat connectiviteitsonderbrekingen worden onderbroken door dynamische IP-adreswijzigingen. Zie NFS-bestandsshares - Beveiliging en netwerken voor meer informatie over beveiliging voor uw NFS-shares.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure Files biedt robuuste ondersteuning voor beschikbaarheidszones via ZRS-configuraties waarmee uw gegevens automatisch worden gedistribueerd over meerdere beschikbaarheidszones binnen een regio. In tegenstelling tot LRS garandeert ZRS dat azure uw bestandsgegevens synchroon repliceert in meerdere beschikbaarheidszones. ZRS zorgt ervoor dat uw gegevens toegankelijk blijven, zelfs als één zone een storing ondervindt.

Diagram dat laat zien hoe gegevens worden gerepliceerd in de primaire regio met zone-redundante opslag (ZRS).

Requirements

ZRS wordt ondersteund in:

Kosten

Wanneer u zone-redundante opslag (ZRS) inschakelt, worden er kosten in rekening gebracht tegen een ander tarief dan lokaal redundante opslag (LRS) vanwege de extra replicatie- en opslagoverhead.

Zie De prijzen van Azure Files voor gedetailleerde informatie over prijzen.

Ondersteuning voor beschikbaarheidszones configureren

  • Maak een bestandsshare met zoneredundantie. Als u een nieuwe bestandsshare wilt maken met ZRS, raadpleegt u Een Azure-bestandsshare maken en selecteert u ZRS of GZRS als redundantieoptie tijdens het maken van het account.

  • Replicatietype wijzigen. Als u een bestaand opslagaccount wilt converteren naar ZRS en meer wilt weten over migratieopties en vereisten, raadpleegt u De redundantieconfiguratie voor Azure Files wijzigen.

  • Zoneredundantie uitschakelen. Converteer ZRS-accounts terug naar een niet-zonegebonden configuratie, zoals LRS, via hetzelfde wijzigingsproces voor de redundantieconfiguratie.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een bestandsopslagaccount is geconfigureerd voor zoneredundantie en alle beschikbaarheidszones operationeel zijn.

  • Verkeersroutering tussen zones: Azure Storage met zone-redundante opslag (ZRS) distribueert aanvragen automatisch over opslagclusters in meerdere beschikbaarheidszones. De distributie van verkeer is transparant voor toepassingen en vereist geen configuratie aan de clientzijde.

  • Gegevensreplicatie tussen zones: Alle schrijfbewerkingen naar ZRS worden synchroon gerepliceerd in alle beschikbaarheidszones binnen de regio. Wanneer u gegevens uploadt of wijzigt, wordt de bewerking pas als voltooid beschouwd als de gegevens zijn gerepliceerd in alle beschikbaarheidszones. Deze synchrone replicatie zorgt voor sterke consistentie en nul gegevensverlies tijdens zonefouten.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een bestandsopslagaccount is geconfigureerd voor zoneredundantie en er een storing in de beschikbaarheidszone is.

  • Detectie en reactie: Microsoft detecteert automatisch zonefouten en initieert herstelprocessen. Er is geen actie van de klant vereist voor ZRS-accounts (zone-redundante opslag).

    Als een zone niet meer beschikbaar is, voert Azure netwerkupdates uit, zoals het opnieuw verwijzen van het Domain Name System (DNS).

  • Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Resource Health echter gebruiken om te controleren op de status van een afzonderlijke resource en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • Actieve aanvragen: Aanvragen tijdens het herstelproces kunnen tijdens het herstelproces worden verwijderd en moeten opnieuw worden geprobeerd. Toepassingen moeten logica voor opnieuw proberen implementeren om deze tijdelijke onderbrekingen af te handelen.

  • Verwachte gegevensverlies: Er treden geen gegevensverlies op tijdens zonefouten omdat gegevens synchroon worden gerepliceerd in meerdere zones voordat schrijfbewerkingen zijn voltooid.

  • Verwachte downtime: Een kleine hoeveelheid downtime, meestal een paar seconden, kan optreden tijdens het automatisch herstel, omdat verkeer wordt omgeleid naar gezonde zones. Wanneer u toepassingen voor ZRS ontwerpt, volgt u procedures voor tijdelijke foutafhandeling, waaronder het implementeren van beleid voor opnieuw proberen met exponentieel uitstel.

  • Verkeer omleiden: Azure routeert automatisch verkeer naar de resterende gezonde beschikbaarheidszones. De service onderhoudt volledige functionaliteit door gebruik te maken van de overlevende zones zonder tussenkomst van de klant. Er is geen hermounting van Azure-bestandsshares van de verbonden clients vereist.

Zoneherstel

Wanneer de mislukte beschikbaarheidszone wordt hersteld, herstelt Azure Storage automatisch normale bewerkingen in alle beschikbaarheidszones. De service zorgt automatisch voor gegevensconsistentie door alle bewerkingen te synchroniseren die zijn opgetreden tijdens de onderbrekingsperiode.

Testen op zonefouten

Wanneer u zone-redundante opslag (ZRS) gebruikt, beheert Azure Storage automatisch replicatie, verkeersroutering en zone-down antwoorden. Omdat deze functie volledig wordt beheerd, hoeft u geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren.

Tolerantie voor storingen in de hele regio

Azure Storage, waaronder Azure Blob Storage, Azure Files, Azure Table Storage en Azure Queue Storage, biedt een scala aan georedundantie- en failovermogelijkheden die aan verschillende vereisten voldoen.

Belangrijk

Geografisch redundante opslag (GRS) werkt alleen binnen gekoppelde Azure-regio's. Als de regio van uw opslagaccount niet is gekoppeld, kunt u overwegen om de aangepaste oplossingen voor meerdere regio's te gebruiken voor tolerantie.

Geografisch redundante opslag voor gekoppelde regio's

Azure Storage biedt verschillende typen GRS in gekoppelde regio's. Welk type GRS u ook gebruikt, gegevens in de secundaire regio worden altijd gerepliceerd met behulp van lokaal redundante opslag (LRS). Deze aanpak biedt bescherming tegen hardwarefouten binnen de secundaire regio.

Belangrijk

Azure Files biedt alleen ondersteuning voor georedundantie (GRS of GZRS) voor standaardbestandsshares (HDD).

Azure Files biedt geen ondersteuning voor geografisch redundante opslag met leestoegang (RA-GRS) of geografisch zone-redundante opslag met leestoegang (RA-GZRS). Als een opslagaccount is geconfigureerd voor het gebruik van RA-GRS of RA-GZRS, worden de standaardbestandsshares (HDD) geconfigureerd en gefactureerd als GRS of GZRS.

Failovertypen

Azure Storage ondersteunt drie soorten failover voor verschillende scenario's.

  • Door de klant beheerde niet-geplande failover: U bent verantwoordelijk voor het initiëren van herstel als er sprake is van een opslagfout in de hele regio in uw primaire regio.

  • Door de klant beheerde geplande failover: U bent verantwoordelijk voor het initiëren van herstel als een ander deel van uw oplossing een storing heeft in uw primaire regio en u moet uw hele oplossing overschakelen naar een secundaire regio. Gebruik een geplande failover wanneer de opslag operationeel blijft in de primaire regio, maar u moet een failover uitvoeren voor uw hele oplossing naar een secundaire regio, zoals voor rampenhersteloefeningen die zijn ontworpen om te voldoen aan nalevings- en auditvereisten.

  • Door Microsoft beheerde failover: In uitzonderlijke omstandigheden kan Microsoft failover initiëren voor alle GEOGRAFISCH redundante opslagaccounts (GRS) in een regio. Door Microsoft beheerde failover is echter een laatste redmiddel en wordt naar verwachting alleen uitgevoerd na een langere periode van storing. U moet niet afhankelijk zijn van door Microsoft beheerde failover.

GRS-accounts kunnen elk van deze failovertypen gebruiken. U hoeft een opslagaccount niet vooraf te configureren voor het gebruik van een van de failovertypen van tevoren.

Requirements

  • Alleen standaardbestandsshares: Azure Files biedt alleen ondersteuning voor georedundantie (GRS of GZRS) voor standaardbestandsshares (HDD). Premium-bestandsshares met SSD moeten gebruik maken van LRS of ZRS. Als u premium-bestandsdeling hebt en u de gegevens wilt repliceren tussen regio's voor hogere veerkracht, raadpleegt u Aangepaste oplossingen voor meerdere regio's voor veerkracht.

  • Alleen GRS en GZRS: Azure Files biedt geen ondersteuning voor geografisch redundante opslag met leestoegang (RA-GRS) of geografisch zone-redundante opslag met leestoegang (RA-GZRS). Als een opslagaccount is geconfigureerd voor het gebruik van RA-GRS of RA-GZRS, worden de standaardbestandsshares (HDD) geconfigureerd en gefactureerd als GRS of GZRS.

Overwegingen

Houd rekening met de volgende belangrijke factoren wanneer u Azure Files met meerdere regio's implementeert:

  • Asynchrone replicatielatentie: Gegevensreplicatie naar de secundaire regio is asynchroon, wat betekent dat er een vertraging is tussen wanneer gegevens naar de primaire regio worden geschreven en wanneer deze beschikbaar zijn in de secundaire regio. Deze vertraging kan leiden tot mogelijk gegevensverlies als er een storing in de primaire regio optreedt voordat recente gegevens worden gerepliceerd. Het gegevensverlies wordt gemeten door het beoogde herstelpunt (RPO). U kunt verwachten dat de replicatievertraging minder dan 15 minuten is, maar deze keer is een schatting en niet gegarandeerd.

    U kunt de eigenschap Laatste synchronisatietijd controleren om te begrijpen hoeveel gegevens verloren kunnen gaan als uw opslagaccount een niet-geplande failover heeft.

  • Laatste synchronisatietijd: Voor Azure Files is de laatste synchronisatietijd gebaseerd op de meest recente systeemmomentopname in de secundaire regio.

    De berekening van de laatste synchronisatietijd kan een time-out hebben als er meer dan 100 bestandsshares in een opslagaccount zijn. U wordt aangeraden 100 of minder bestandsshares voor elk opslagaccount te implementeren om time-outs te voorkomen.

  • Toegang tot secundaire regio: De secundaire regio is pas toegankelijk voor leesbewerkingen als er een failover plaatsvindt.

  • Functiebeperkingen: Sommige Azure Files-functies worden niet ondersteund of hebben beperkingen wanneer u GRS of door de klant beheerde failover gebruikt. Deze beperkingen omvatten specifieke bestandsdelingstypen, toegangsniveaus en beheerhulpmiddelen en -bewerkingen. Raadpleeg de documentatie over functiecompatibiliteit voordat u geo-redundantie implementeert.

Kosten

Voor configuraties van Azure Storage-accounts met meerdere regio's worden extra kosten in rekening gebracht voor replicatie in meerdere regio's en opslag in de secundaire regio. Gegevensoverdracht tussen Azure-regio's wordt in rekening gebracht op basis van standaard bandbreedtetarieven tussen regio's.

Zie De prijzen van Azure Files voor gedetailleerde informatie over prijzen.

Ondersteuning voor meerdere regio's configureren

  • Maak een nieuw GRS-account (geografisch redundante opslag). Als u een GRS-account wilt maken, raadpleegt u Een opslagaccount maken en selecteert u GRS, geografisch redundante opslag met leestoegang (RA-GRS), geografisch zone-redundante opslag (GZRS) of geografisch zone-redundante opslag met leestoegang (RA-GZRS) tijdens het maken van het account.

  • Schakel georedundantie in voor een bestaand bestandsopslagaccount. Als u een bestaand bestandsopslagaccount wilt converteren naar GRS, raadpleegt u De redundantieconfiguratie voor Azure Files wijzigen.

    Waarschuwing

    Nadat uw account opnieuw is geconfigureerd voor georedundantie, kan het enige 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 niet-geplande failover start. Als u potentiële gegevensverlies wilt evalueren, vergelijkt u de laatste synchronisatietijd met de laatste keer waarop gegevens naar de nieuwe primaire regio zijn geschreven.

  • Schakel georedundantie uit. Converteer GRS-accounts terug naar configuraties met één regio (LRS of ZRS) via hetzelfde wijzigingsproces voor redundantieconfiguratie.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een opslagaccount is geconfigureerd voor georedundantie en alle regio's operationeel zijn.

  • Verkeersroutering tussen regio's: Azure Files maakt gebruik van een actief-passieve benadering waarbij alle lees- en schrijfbewerkingen worden omgeleid naar de primaire regio.

  • Gegevensreplicatie tussen regio's: Schrijfbewerkingen worden eerst doorgevoerd in de primaire regio met behulp van het geconfigureerde redundantietype (LRS voor GRS of ZRS voor GZRS). Na een geslaagde voltooiing in de primaire regio worden gegevens asynchroon gerepliceerd naar de secundaire regio, waar ze worden opgeslagen met LRS.

    De asynchrone aard van replicatie tussen regio's betekent dat er meestal een vertragingstijd is tussen het moment waarop gegevens naar de primaire regio worden geschreven en wanneer deze beschikbaar zijn in de secundaire regio. U kunt de replicatietijd bewaken met behulp van de eigenschap Laatste synchronisatietijd.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een opslagaccount is geconfigureerd voor georedundantie en er een storing is in de primaire regio.

  • Door de klant beheerde failover (niet-gepland): Gebruik een niet-geplande failover wanneer opslag in de primaire regio niet beschikbaar is.

    • Detectie en reactie: In het onwaarschijnlijke geval dat uw opslagaccount niet beschikbaar is in uw primaire regio, kunt u overwegen om een niet-geplande failover door de klant te starten. Houd rekening met de volgende factoren om deze beslissing te nemen:

      • Of Azure Resource Health problemen toont bij het openen van het opslagaccount in uw primaire regio

      • Of Microsoft u adviseert failover naar een andere regio uit te voeren

      Waarschuwing

      Een niet-geplande failover kan leiden tot gegevensverlies. Voordat u een door de klant beheerde failover start, moet u beslissen of het herstel van de service het risico op gegevensverlies rechtvaardigt.

    • Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. Echter:

    • Actieve aanvragen: Tijdens het failoverproces zijn zowel de primaire als de secundaire eindpunten van het opslagaccount tijdelijk niet beschikbaar voor zowel lees- als schrijfbewerkingen. Actieve aanvragen kunnen worden verwijderd en clienttoepassingen moeten het opnieuw proberen nadat de failover is voltooid.

    • Verwachte gegevensverlies: Gegevensverlies is gebruikelijk tijdens een niet-geplande failover vanwege de asynchrone replicatievertraging, wat betekent dat recente schrijfbewerkingen mogelijk niet worden gerepliceerd. U kunt de eigenschap Laatste synchronisatietijd controleren om te begrijpen hoeveel gegevens verloren kunnen gaan tijdens een niet-geplande failover. Verwacht gegevensverlies wordt vaak het beoogde herstelpunt (RPO) genoemd. U kunt normaal gesproken verwachten dat de RPO minder dan 15 minuten is, maar die tijd is niet gegarandeerd.

    • Verwachte downtime: De hoeveelheid verwachte downtime wordt vaak aangeduid als de beoogde hersteltijd (RTO). Door de klant beheerde failover wordt doorgaans binnen 60 minuten voltooid, afhankelijk van de accountgrootte en complexiteit.

    • Verkeer omleiden: Wanneer de failover is voltooid, worden de eindpunten van het opslagaccount automatisch bijgewerkt, zodat toepassingen niet opnieuw hoeven te worden geconfigureerd. Als uw toepassing DNS-vermeldingen (Domain Name System) in de cache bewaart, kan het nodig zijn om de cache te wissen om ervoor te zorgen dat de toepassing verkeer naar de nieuwe primaire regio verzendt.

    • Configuratie na failover: Nadat een niet-geplande failover is voltooid, gebruikt uw opslagaccount in de doelregio de lokaal redundante opslaglaag (LRS). Als u deze opnieuw wilt repliceren, moet u geografisch redundante opslag (GRS) opnieuw inschakelen en wachten totdat de gegevens worden gerepliceerd naar de nieuwe secundaire regio.

    Zie Hoe door de klant beheerde (niet-geplande) failover werkt en een failover van een opslagaccount initiëren voor meer informatie over het initiëren van door de klant beheerde failover.

  • Door de klant beheerde failover (gepland): Gebruik een geplande failover wanneer de opslag operationeel blijft in de primaire regio, maar u moet om een andere reden een failover van uw hele oplossing uitvoeren naar een secundaire regio. Een andere Azure-service kan bijvoorbeeld een probleem ondervinden en u moet overschakelen naar het gebruik van een secundaire regio voor uw hele oplossing. Of u kunt een geplande failover gebruiken om een disaster recovery (DR)-oefening uit te voeren voor nalevings- en controledoeleinden.

    • Detectie en reactie: U bent verantwoordelijk voor het kiezen van een failover. Normaal gesproken neemt u deze beslissing als u een failover tussen regio's wilt uitvoeren, ook al is uw opslagaccount in orde. U kunt bijvoorbeeld een failover activeren wanneer er een grote storing optreedt in een ander toepassingsonderdeel waarvan u niet kunt herstellen in de primaire regio.

      • Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. Echter:

    • Actieve aanvragen: Tijdens het failoverproces zijn zowel de primaire als de secundaire eindpunten van het opslagaccount tijdelijk niet beschikbaar voor zowel lees- als schrijfbewerkingen. Actieve aanvragen kunnen worden verwijderd en clienttoepassingen moeten het opnieuw proberen nadat de failover is voltooid.

    • Verwachte gegevensverlies: Er wordt geen gegevensverlies verwacht omdat het failoverproces pas wordt voltooid nadat alle gegevens zijn gesynchroniseerd, wat resulteert in een RPO van nul.

    • Verwachte downtime: Failover wordt doorgaans binnen 60 minuten voltooid, wat betekent dat de verwachte RTO 60 minuten is, afhankelijk van de grootte en complexiteit van het account. Tijdens het failoverproces zijn zowel de primaire als de secundaire eindpunten van het opslagaccount tijdelijk niet beschikbaar voor zowel lees- als schrijfbewerkingen.

    • Verkeer omleiden: Wanneer de failover is voltooid, worden de eindpunten van het opslagaccount automatisch bijgewerkt, zodat toepassingen niet opnieuw hoeven te worden geconfigureerd. Als uw toepassing DNS-vermeldingen in de cache bewaart, kan het nodig zijn om de cache te wissen om ervoor te zorgen dat de toepassing verkeer naar de nieuwe primaire regio verzendt.

    • Configuratie na failover: Nadat een geplande failover is voltooid, blijft uw opslagaccount in de doelregio geo-repliceren en blijft deze op de GRS-laag staan.

    Zie Hoe door de klant beheerde (geplande) failover werkt en een failover van een opslagaccount initiëren voor meer informatie over het initiëren van door de klant beheerde failover.

  • Door Microsoft beheerde failover: In het zeldzame geval van een grote ramp waarbij Microsoft bepaalt dat de primaire regio permanent onherstelbaar is, kan een automatische failover naar de secundaire regio worden gestart. Microsoft verwerkt het hele proces en er is geen actie van de klant vereist. De hoeveelheid tijd die is verstreken voordat een failover plaatsvindt, is afhankelijk van de ernst van de ramp en de tijd die nodig is om de situatie te beoordelen.

    • Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. Echter:

    Belangrijk

    Gebruik door de klant beheerde failoveropties voor het ontwikkelen, testen en implementeren van uw DR-plannen. Vertrouw niet op door Microsoft beheerde failover, die alleen in extreme omstandigheden kan worden gebruikt. Een door Microsoft beheerde failover wordt waarschijnlijk geïnitieerd voor een hele regio. Het kan niet worden gestart voor afzonderlijke opslagaccounts, abonnementen of klanten. Failover kan zich op verschillende momenten voordoen voor verschillende Azure-services. We raden u aan om door de klant beheerde failover te gebruiken.

Herstel van de regio

Het failbackproces verschilt aanzienlijk tussen door Microsoft beheerde en door de klant beheerde failoverscenario's.

  • Door de klant beheerde failover (niet-gepland): Na een niet-geplande failover wordt het opslagaccount geconfigureerd met lokaal redundante opslag (LRS). Als u een failback wilt uitvoeren, moet u de GRS-relatie (geografisch redundante opslag) opnieuw tot stand brengen en wachten totdat de gegevens zijn gerepliceerd.

  • Door de klant beheerde failover (gepland): Na een geplande failover blijft het opslagaccount geo-gerepliceerd. U kunt een andere door de klant beheerde failover initiëren om een failback uit te voeren naar de oorspronkelijke primaire regio. Dezelfde overwegingen voor failover zijn van toepassing.

  • Door Microsoft beheerde failover: Als Microsoft een failover initieert, is het waarschijnlijk dat er een aanzienlijke ramp is opgetreden in de primaire regio en dat de primaire regio mogelijk niet kan worden hersteld. Tijdlijnen of herstelplannen zijn afhankelijk van de omvang van de regionale nood- en herstelinspanningen. U moet Azure Service Health-communicatie controleren voor details.

Test voor regiofouten

Voor GRS-accounts kunt u geplande failoverbewerkingen uitvoeren tijdens onderhoudsvensters om het volledige failover- en failbackproces te testen. Geplande failover vereist geen gegevensverlies, maar vereist wel downtime tijdens zowel failover als failback.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

De failovermogelijkheden tussen regio's van Azure Storage zijn mogelijk niet geschikt vanwege de volgende redenen:

  • Uw opslagaccount bevindt zich in een niet-gekoppelde regio.

  • Uw doelstellingen voor bedrijfstijd worden niet gerealiseerd door de hersteltijd of het gegevensverlies dat de ingebouwde failoveropties bieden.

  • U moet een failover uitvoeren naar een regio die niet gekoppeld is aan uw primaire regio.

  • U hebt een actieve/actieve configuratie in verschillende regio's nodig.

  • U gebruikt bestandstypen die geen ondersteuning bieden voor geo-redundantie.

In deze sectie vindt u een algemeen overzicht van enkele benaderingen die u kunt overwegen. Een uitgebreid overzicht van implementatietopologieën voor meerdere regio's voor Azure Storage valt buiten het bereik van dit artikel.

Houd rekening met de volgende algemene benaderingen van hoog niveau:

  • Meerdere opslagaccounts: Azure Files kan in meerdere regio's worden geïmplementeerd met behulp van afzonderlijke opslagaccounts in elke regio. Deze benadering biedt flexibiliteit in regioselectie, de mogelijkheid om niet-geaireerde regio's te gebruiken en meer gedetailleerde controle over de timing van replicatie en gegevensconsistentie. Wanneer u meerdere opslagaccounts in verschillende regio's implementeert, moet u replicatie van gegevens in meerdere regio's configureren, taakverdeling en failoverbeleid implementeren en gegevensconsistentie tussen regio's garanderen.

  • Replicatie op toepassingsniveau: Implementeer aangepaste replicatielogica met behulp van Azure Data Factory of AzCopy om gegevens tussen bestandsshares in verschillende regio's te synchroniseren. Deze aanpak vereist aangepaste mechanismen voor ontwikkeling en conflictoplossing.

  • Gebruik Azure File Sync om bestanden te repliceren naar een bestandsshare in een andere Azure-regio. U kunt Azure File Sync gebruiken om te synchroniseren tussen een SMB Azure-bestandsshare (cloudeindpunt), een on-premises Windows-bestandsserver en een gekoppelde bestandsshare die wordt uitgevoerd op een virtuele machine (VM) in een andere Azure-regio (een DR-servereindpunt).

    Voor deze aanpak moet u meerdere bestandsshares en een virtuele machine implementeren om het synchronisatieproces te coördineren.

    Als u deze methode gebruikt voor replicatie van meerdere regio's:

    • Schakel cloud-tiering uit om ervoor te zorgen dat alle gegevens lokaal aanwezig zijn op de bestandsserver.

    • Richt voldoende opslag in op de Virtuele Azure-machine om de volledige gegevensset op te slaan.

    • Open en wijzig bestanden op het servereindpunt en niet in Azure om ervoor te zorgen dat wijzigingen snel worden gerepliceerd naar de secundaire regio.

Backups en herstel

Azure Files Backup is een systeemeigen integratie tussen Azure Files en Azure Backup die is ontworpen om gegevens te beschermen tegen onbedoelde verwijdering, beschadiging en ransomware-aanvallen.

Met Azure Files Backup worden momentopnamen op shareniveau gemaakt die zijn opgeslagen in hetzelfde opslagaccount. Met deze mogelijkheid kunt u zowel afzonderlijke bestanden als volledige bestandsshares snel herstellen. U kunt ook backupbeleid gebruiken om lange bewaarperioden te bieden met een aanpasbare backupfrequentie.

U kunt uw momentopnamen maken en op twee verschillende manieren opslaan:

  • Opslag op shareniveau: Voor operationele en kortetermijnherstelscenario's kunt u momentopnamen op shareniveau maken en opslaan in hetzelfde opslagaccount. Momentopnamen op shareniveau maken snelle herstel van afzonderlijke bestanden of volledige bestandsshares mogelijk naar de oorspronkelijke of een alternatieve locatie.

  • Gekluisde back-upopslag: Met behulp van een gekluisde back-up kunt u uw dagelijkse momentopnamen kopiëren naar een Azure Recovery Services-kluis. Om de beveiliging te verbeteren, is deze kluis geïsoleerd en fysiek gescheiden van het primaire opslagaccount.

    Wanneer u een gekoppelde Azure-regio gebruikt en de kluis configureert voor GRS, worden de gegevens gerepliceerd naar de gekoppelde regio. Deze replicatie ondersteunt herstel in meerdere regio's en DR-werkstromen.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure Storage beschrijft de verwachte beschikbaarheid van de service en de voorwaarden waaraan moet worden voldaan om die beschikbaarheidsverwachting te bereiken. De SLA voor beschikbaarheid waarvoor u in aanmerking komt, is afhankelijk van de opslaglaag en het replicatietype dat u gebruikt. Zie SLA's voor onlineservices voor meer informatie.

Verwante inhoud

  • Last updated on