Delen via

Betrouwbaarheid in Azure Table Storage

Azure Table Storage is een service waarin gestructureerde NoSQL-gegevens in de cloud worden opgeslagen. Het biedt een schemaloze opslag waar elke entiteit wordt geopend via een sleutel en een set kenmerken bevat. Eén tabel kan entiteiten bevatten met verschillende sets eigenschappen en eigenschappen kunnen bestaan uit verschillende gegevenstypen.

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 Table Storage bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen. Ook wordt beschreven hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen en belangrijke informatie over de Service Level Agreement (SLA) van Table Storage uitlicht.

Opmerking

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

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Voer voor productieomgevingen de volgende acties uit:

  • Schakel zone-redundante opslag (ZRS) in voor de opslagaccounts die Table Storage-resources bevatten. ZRS biedt een hogere beschikbaarheid door uw gegevens synchroon te repliceren over meerdere beschikbaarheidszones in de primaire regio. Deze replicatie beschermt tegen fouten in de beschikbaarheidszone.

  • Als u tolerantie nodig hebt voor regiostoringen en de primaire regio van uw opslagaccount is gekoppeld, kunt u overwegen om geografisch redundante opslag (GRS) in te schakelen om gegevens asynchroon te repliceren naar de gekoppelde regio. In ondersteunde regio's kunt u georedundantie combineren met zoneredundantie met behulp van geografisch zone-redundante opslag (GZRS).

  • Voor grootschalige productieworkloads of als u hoge tolerantievereisten hebt, kunt u Overwegen Om Azure Cosmos DB voor Tabel te gebruiken. Azure Cosmos DB for Table is compatibel met toepassingen die zijn geschreven voor Table Storage. Het biedt ondersteuning voor lees- en schrijfbewerkingen met lage latentie op grote schaal en biedt een sterke wereldwijde distributie in meerdere regio's met flexibele consistentiemodellen. Het biedt ook ingebouwde back-ups en andere mogelijkheden die de tolerantie en prestaties van uw toepassing verbeteren.

Overzicht van betrouwbaarheidsarchitectuur

Table Storage werkt als een gedistribueerde NoSQL-database binnen de Azure Storage-platforminfrastructuur. De service biedt redundantie via meerdere kopieën van uw tabelgegevens en het specifieke redundantiemodel is afhankelijk van de configuratie van uw opslagaccount.

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.

Table Storage-clientbibliotheken en SDK's bevatten ingebouwde beleidsregels voor opnieuw proberen die automatisch veelvoorkomende tijdelijke fouten verwerken, zoals netwerktime-outs, tijdelijke serviceonbeschikbaarheid (HTTP 503), beperkingsreacties (HTTP 429) en overbelasting van partitieservers. Wanneer uw toepassing deze tijdelijke omstandigheden ondervindt, proberen de clientbibliotheken automatisch bewerkingen opnieuw met behulp van exponentieel uitstelstrategieën.

Als u tijdelijke fouten effectief wilt beheren wanneer u Table Storage gebruikt, voert u de volgende acties uit:

  • Configureer de juiste time-outs in uw Table Storage-client om de reactiesnelheid te verdelen met tolerantie voor tijdelijke vertragingen. De standaardtime-outs in Azure Storage-clientbibliotheken zijn doorgaans geschikt voor de meeste scenario's.

  • Implementeer exponentieel uitstel voor beleid voor opnieuw proberen, met name wanneer uw toepassing te maken krijgt met time-outfouten voor HTTP 503-servers of http 500-bewerkingstime-outfouten. Table Storage kan aanvragen beperken wanneer afzonderlijke partities dynamisch worden of wanneer de limieten van het opslagaccount worden benaderd.

  • Ontwerp partitiebewuste logica voor opnieuw proberen in grootschalige toepassingen. Partitiebewuste logica voor opnieuw proberen is een geavanceerdere benadering die gepartitioneerde architectuur in Table Storage beschouwt en bewerkingen over meerdere partities distribueert om de kans op beperking op afzonderlijke partitieservers te verminderen.

Zie de controlelijst prestaties en schaalbaarheid voor Table Storage voor meer informatie over de Table Storage-architectuur en het ontwerpen van robuuste en grootschalige toepassingen.

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.

Table Storage is zone-redundant wanneer u deze implementeert met ZRS-configuratie. In tegenstelling tot lokaal redundante opslag (LRS) garandeert ZRS dat azure uw tabelgegevens synchroon repliceert in meerdere beschikbaarheidszones. Deze configuratie zorgt ervoor dat uw tabellen toegankelijk blijven, zelfs als een volledige beschikbaarheidszone niet beschikbaar is. Alle schrijfbewerkingen moeten worden bevestigd in meerdere zones voordat de service de schrijfbewerking voltooit, wat sterke consistentiegaranties biedt.

Zoneredundantie is ingeschakeld op het niveau van het opslagaccount en is van toepassing op alle Table Storage-resources binnen dat account. Omdat de instelling van toepassing is op het hele opslagaccount, kunt u afzonderlijke entiteiten niet configureren voor verschillende redundantieniveaus. 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).

Requirements

  • Typen opslagaccounts: U moet een Standaard v2-opslagaccount voor algemeen gebruik gebruiken om ZRS in te schakelen voor Table Storage. Premium-opslagaccounts bieden geen ondersteuning voor Table Storage.

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 Table Storage-prijzen voor gedetailleerde informatie over prijzen.

Ondersteuning voor beschikbaarheidszones configureren

  • Maak een zone-redundant opslagaccount en -tabel:

    1. Maak een opslagaccount. Zorg ervoor dat u ZRS, GZRS of geografisch redundante opslag met leestoegang (RA-GZRS) als redundantieoptie selecteert.

    2. Maak een tabel.

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

Wanneer een beschikbaarheidszone niet beschikbaar is, verwerkt Table Storage het failoverproces automatisch door te reageren met het volgende gedrag:

  • 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 zone niet meer beschikbaar is, voert Azure netwerkupdates zoals DNS (Domain Name System) opnieuw aan, zodat aanvragen worden omgeleid naar de resterende beschikbaarheidszones die in orde zijn. De service onderhoudt volledige functionaliteit met behulp van de gezonde 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 hele oplossing moet overhevelen naar een secundaire regio, bijvoorbeeld voor noodherstel oefeningen die zijn ontworpen om te voldoen aan vereisten voor naleving en auditering.

  • 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

  • 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 Table 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 Table Storage-prijzen 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 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.

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

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.

Opmerking

Voor toepassingen die zijn gebouwd voor het gebruik van Table Storage, kunt u Overwegen Om Azure Cosmos DB voor Table te gebruiken. Azure Cosmos DB for Table biedt ondersteuning voor geavanceerde vereisten voor meerdere regio's, waaronder ondersteuning voor niet-gekoppelde regio's. Het is ook ontworpen voor compatibiliteit met toepassingen die zijn gebouwd voor Table Storage.

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.

Voor Table Storage moet u voor een benadering met meerdere accounts gegevensdistributie beheren, synchronisatie tussen tabellen in verschillende regio's afhandelen, waaronder conflictoplossing en aangepaste failoverlogica implementeren.

Backups en herstel

Table Storage biedt geen traditionele back-upmogelijkheden, zoals herstel naar een bepaald tijdstip (PITR). U kunt echter aangepaste back-upstrategieën implementeren voor tabelgegevens.

Als u ingebouwde back-upmogelijkheden nodig hebt, kunt u overwegen om over te stappen naar Azure Cosmos DB voor Table, dat ondersteuning biedt voor zowel periodieke als continue back-ups. Zie Online back-up en on-demand gegevens herstellen in Azure Cosmos DB voor meer informatie.

Houd rekening met de volgende methoden voor scenario's waarvoor gegevensback-up vanuit Table Storage is vereist:

  • Exporteren met behulp van Azure Data Factory. Gebruik de Azure Data Factory-connector voor Table Storage om uw entiteiten te exporteren naar een andere locatie. U kunt bijvoorbeeld een back-up maken van elke entiteit naar een JSON-bestand dat is opgeslagen in Azure Blob Storage.

  • Back-up op toepassingsniveau uitvoeren. Implementeer aangepaste back-uplogica in uw toepassingen om kritieke tabelentiteiten te exporteren naar andere opslagservices, zoals Azure SQL Database of Azure Cosmos DB, voor robuustere back-up- en herstelmogelijkheden.

Wanneer u back-upstrategieën voor Table Storage ontwerpt, moet u rekening houden met de gepartitioneerde aard van de gegevens en ervoor zorgen dat uw back-upprocessen efficiënt grote tabellen kunnen verwerken door meerdere partities parallel te verwerken.

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