Delen via

Betrouwbaarheid in Azure Blob Storage

Azure Blob Storage is een oplossing voor objectopslag voor de cloud van Microsoft. Het is ontworpen voor het opslaan van enorme hoeveelheden ongestructureerde gegevens, zoals tekst, binaire gegevens, documenten, mediabestanden en toepassingsback-ups. Als basisservice voor Azure Storage biedt Blob Storage meerdere betrouwbaarheidsfuncties om ervoor te zorgen dat uw gegevens beschikbaar en duurzaam blijven tijdens geplande en ongeplande gebeurtenissen.

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 beschikbaarheidsdoelstellingen.

In dit artikel wordt beschreven hoe u Blob Storage tolerant maakt voor een verscheidenheid aan mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen. De tekst beschrijft ook hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen en belicht enkele belangrijke informatiepunten over de service level agreement (SLA) van Blob Storage.

Opmerking

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

Aanbevelingen voor productie-implementatie

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

Overzicht van betrouwbaarheidsarchitectuur

Azure Storage biedt verschillende redundantieopties om uw gegevens te beschermen tegen verschillende typen fouten. Elke optie biedt een specifiek gegevensredundantieniveau, zodat u het niveau kunt kiezen dat het beste overeenkomt met de vereisten van uw toepassing.

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.

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.

Implementeer de volgende aanbevelingen om tijdelijke fouten effectief te beheren wanneer u Blob Storage gebruikt:

  • Gebruik de Azure Storage-clientbibliotheken, waaronder ingebouwd beleid voor opnieuw proberen met exponentieel uitstel en jitter. De SDK's voor .NET, Java, Python en JavaScript verwerken automatisch nieuwe pogingen voor tijdelijke fouten. Zie Een beleid voor opnieuw proberen implementeren met .NET voor meer informatie over configuratieopties voor opnieuw proberen.

  • Configureer de juiste time-outwaarden voor uw blobbewerkingen op basis van de blobgrootte en netwerkvoorwaarden. Voor grotere blobs zijn langere time-outs vereist, maar kleinere bewerkingen kunnen kortere waarden gebruiken om fouten snel te detecteren.

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.

Blob Storage biedt robuuste ondersteuning voor beschikbaarheidszones via ZRS-configuraties waarmee uw gegevens automatisch worden gedistribueerd over meerdere beschikbaarheidszones binnen een regio. In tegenstelling tot lokaal redundante opslag (LRS) garandeert ZRS dat uw blobgegevens synchroon worden gerepliceerd in meerdere beschikbaarheidszones. ZRS zorgt ervoor dat uw gegevens toegankelijk blijven, zelfs als één zone een storing ondervindt.

Zoneredundantie is ingeschakeld op het niveau van het opslagaccount en is van toepassing op alle blobcontainers binnen dat account. U kunt geen verschillende redundantieniveaus instellen voor afzonderlijke containers. De redundantieconfiguratie wordt toegepast op het hele opslagaccount. Wanneer een beschikbaarheidszone een storing ondervindt, stuurt Azure Storage aanvragen automatisch naar gezonde zones zonder tussenkomst van u of uw toepassing.

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

Behoeften

  • Typen opslagaccounts: Zoneredundantie is beschikbaar voor de typen Standard algemeen gebruik v2- en Premium Blok-blobopslagaccounts. Blok-blobs, toevoeg-blobs en pagina-blobs ondersteunen allemaal zone-redundante configuraties, maar het type opslagaccount dat u gebruikt, bepaalt welke mogelijkheden beschikbaar zijn. Zie Ondersteunde typen opslagaccounts voor meer informatie.

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 Blob Storage voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

  • Maak een blob-opslagaccount met zoneredundantie. Als u een nieuw opslagaccount wilt maken met ZRS, raadpleegt u Een opslagaccount maken en ZRS, geografisch zone-redundante opslag (GZRS) of geografisch redundante opslag met leestoegang (RA-GZRS) selecteren als redundantieoptie tijdens het maken van het account.

  • Replicatietype wijzigen. Zie Wijzigen hoe een opslagaccount wordt gerepliceerd voor meer informatie over het wijzigen van een bestaand opslagaccount in zone-redundante opslag (ZRS) en over configuratieopties en -vereisten.

  • Zoneredundantie uitschakelen. Converteer ZRS-accounts terug naar een niet-zonegebonden configuratie, zoals lokaal redundante opslag (LRS), met behulp van hetzelfde wijzigingsproces voor redundantieconfiguratie.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een Blob Storage-account 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 Blob Storage-account is geconfigureerd voor ZRS 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: Als een beschikbaarheidszone offline gaat, initieert Azure netwerkwijzigingen, zoals DNS-herstel (Domain Name System). Deze updates zorgen ervoor dat verkeer wordt omgeleid naar de resterende gezonde beschikbaarheidszones. De service onderhoudt volledige functionaliteit met behulp van de overlevende zones en vereist geen tussenkomst van de klant.

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.

Georedundante opslag

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 uw gehele oplossing moet overzetten naar een secundaire regio, bijvoorbeeld voor rampenhersteloefeningen die zijn ontworpen om te voldoen aan nalevings- en controlevereisten.

  • 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.

Behoeften

  • Typen opslagaccounts: Geografisch redundante opslag (GRS) en door de klant geïnitieerde failover en failback zijn beschikbaar in alle gekoppelde Azure-regio's die ondersteuning bieden voor v2 Azure Storage-accounts voor algemeen gebruik.

Overwegingen

Houd rekening met de volgende belangrijke factoren wanneer u Blob Storage 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.

  • Toegang tot secundaire regio: Met configuraties van geografisch redundante opslag (GRS) en geografisch zone-redundante opslag (GZRS) is de secundaire regio pas toegankelijk voor leesbewerkingen als er een failover plaatsvindt.

    geografisch redundante opslag met leestoegang (RA-GRS) en geografisch zone-redundante opslagconfiguraties met leestoegang (RA-GZRS) bieden leestoegang tot de secundaire regio tijdens normale bewerkingen, maar vanwege de asynchrone replicatielatentie kunnen ze enigszins verouderde gegevens retourneren.

  • Functiebeperkingen: Sommige Azure Storage-functies worden niet ondersteund of hebben beperkingen wanneer u geografisch redundante opslag (GRS) of door de klant beheerde failover gebruikt. Controleer de functiecompatibiliteit voordat u georedundantie 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 Blob Storage voor meer informatie.

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 opslagaccount. Als u een bestaand opslagaccount wilt converteren naar geografisch redundante opslag (GRS), raadpleegt u Wijzigen hoe een opslagaccount wordt gerepliceerd.

    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 dat gegevens naar de nieuwe primaire regio zijn geschreven.

  • Schakel georedundantie uit. Converteer GRS-accounts terug naar configuraties met één regio, zoals lokaal redundante opslag (LRS) of zone-redundante opslag (ZRS) met behulp van 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 Storage maakt gebruik van een actief-passieve benadering waarbij alle schrijfbewerkingen en de meeste leesbewerkingen worden omgeleid naar de primaire regio.

    Voor geografisch redundante opslag met leestoegang (RA-GRS) en geografisch zone-redundante opslagconfiguraties met leestoegang (RA-GZRS) kunnen toepassingen optioneel vanuit de secundaire regio lezen door toegang te krijgen tot het secundaire eindpunt. Deze aanpak vereist expliciete toepassingsconfiguratie en is niet automatisch. Vanwege de asynchrone replicatievertraging kunnen gegevens in de secundaire regio mogelijk enigszins verouderd zijn.

  • Gegevensreplicatie tussen regio's: Schrijfbewerkingen worden eerst doorgevoerd in de primaire regio met behulp van de volgende geconfigureerde redundantietypen:

    • Lokaal redundante opslag (LRS) voor geografisch redundante opslag (GRS) en RA-GRS
    • Zone-redundante opslag (ZRS) voor geografisch zone-redundante opslag (GZRS) en RA-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.

Regio herstel

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

U kunt regionale fouten simuleren om uw procedures voor herstel na noodgevallen te testen.

  • Geplande failovertests: Voor GRS-accounts (geografisch redundante opslag) kunt u geplande failoverbewerkingen uitvoeren tijdens onderhoudsvensters om het volledige failover- en failbackproces te testen. Geplande failover vereist geen gegevensverlies, maar er is wel sprake van downtime tijdens zowel failover als failback.

  • Secundair eindpunt testen: Voor geografisch redundante opslag met leestoegang (RA-GRS) en geografisch zone-redundante opslagconfiguraties (RA-GZRS) met leestoegang, test u regelmatig leesbewerkingen op het secundaire eindpunt om ervoor te zorgen dat uw toepassing gegevens uit de secundaire regio kan lezen.

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.

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.

U kunt Azure Storage implementeren in meerdere regio's 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.

Objectreplicatie biedt een extra optie voor replicatie van gegevens in meerdere regio's die asynchroon kopiëren van blok-blobs tussen opslagaccounts biedt. In tegenstelling tot de ingebouwde geografisch redundante opslagopties die gebruikmaken van vaste gekoppelde regio's, kunt u met objectreplicatie gegevens tussen opslagaccounts in elke Azure-regio repliceren, inclusief niet-gekoppelde regio's. Deze benadering biedt u volledige controle over bron- en doelregio's, replicatiebeleid en de specifieke containers en blobvoorvoegsels die moeten worden gerepliceerd.

U kunt objectreplicatie configureren om alle blobs in een container of specifieke subsets te repliceren op basis van blobvoorvoegsels en tags. De replicatie is asynchroon en vindt plaats op de achtergrond. U kunt meerdere replicatiebeleidsregels configureren en zelfs replicatie in meerdere opslagaccounts koppelen om geavanceerde topologieën voor meerdere regio's te maken.

Objectreplicatie is niet compatibel met alle opslagaccounts. Het werkt bijvoorbeeld niet met opslagaccounts die gebruikmaken van hiërarchische naamruimten (ook wel Azure Data Lake Storage Gen2-accounts genoemd).

Zie Objectreplicatie voor blok-blobs en objectreplicatie configureren voor meer informatie.

Back-up en herstel

Blob Storage biedt meerdere mechanismen voor gegevensbeveiliging die een aanvulling vormen op redundantie voor uitgebreide back-upstrategieën. De ingebouwde redundantie van de service beschermt tegen infrastructuurfouten en extra back-upmogelijkheden beschermen tegen onbedoelde verwijdering, beschadiging en schadelijke activiteiten.

Met herstel naar een bepaald tijdstip (PITR) kunt u blok-blobgegevens herstellen naar een eerdere status binnen een geconfigureerde bewaarperiode van maximaal 365 dagen. Microsoft beheert deze functie volledig. Het biedt ook gedetailleerde herstelmogelijkheden op container- of blobniveau. PITR-gegevens worden opgeslagen in dezelfde regio als het bronaccount en zijn ook toegankelijk tijdens regionale storingen als u geografisch redundante configuraties gebruikt.

Blob-versiebeheer onderhoudt automatisch eerdere versies van blobs wanneer ze worden gewijzigd of verwijderd. Elke versie wordt opgeslagen als een afzonderlijk object en kan onafhankelijk worden geopend. Versies worden opgeslagen in dezelfde regio als de huidige blob en volgen dezelfde redundantieconfiguratie als het opslagaccount.

Voorlopig verwijderen biedt een veiligheidsnet voor per ongeluk verwijderde blobs en containers door verwijderde gegevens gedurende een configureerbare periode te bewaren. Voorlopig verwijderde gegevens blijven in hetzelfde opslagaccount en dezelfde regio, waardoor deze direct beschikbaar zijn voor herstel. Voor geografisch redundante accounts worden voorlopig verwijderde gegevens ook gerepliceerd naar de secundaire regio.

Blob-momentopnamen maken alleen-lezen, point-in-time kopieën van blobs die u kunt gebruiken voor back-up- en herstelscenario's. Momentopnamen worden opgeslagen in hetzelfde opslagaccount en volgen dezelfde redundantie- en geo-replicatie-instellingen als de basisblob.

Voor back-upvereisten tussen regio's kunt u Overwegen Om Azure Backup te gebruiken voor blobs, dat gecentraliseerd back-upbeheer biedt en back-upgegevens kan opslaan in andere regio's dan de brongegevens. Deze service biedt operationele en gekluisde back-upopties met configureerbare bewaarbeleidsregels en herstelmogelijkheden. Zie het overzicht van Back-up voor blobs voor meer informatie.

Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Wat zijn redundantie, replicatie en back-up? voor meer informatie.

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