Betrouwbaarheid in Azure Cosmos DB

Azure Cosmos DB voor NoSQL is een wereldwijd gedistribueerde databaseservice met meerdere modellen die ondersteuning biedt voor documentgegevensmodellen met flexibele schema's. Azure Cosmos DB biedt uitgebreide betrouwbaarheidsfuncties, waaronder meerdere consistentieniveaus waarmee u prestaties en beschikbaarheid kunt verdelen, zone-redundante implementaties die bescherming bieden tegen storingen in de beschikbaarheidszone, replicatie in meerdere regio's met door de service beheerde of door de klant beheerde failover en continue en periodieke back-upopties voor gegevensbeveiliging.

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 Cosmos DB bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone, regiostoringen en serviceonderhoud. Het beschrijft ook hoe u back-ups gebruikt om te herstellen van andere soorten problemen en belicht belangrijke informatie over de Azure Cosmos DB Service Level Agreement (SLA).

Aanbevelingen voor productie-implementatie

Het Azure Well-Architected Framework biedt aanbevelingen voor betrouwbaarheid, beveiliging, kosten, bewerkingen en prestaties. Zie Architecture best practices for Azure Cosmos DB voor meer informatie over hoe deze gebieden van invloed zijn op elkaar en bijdragen aan een betrouwbare Azure Cosmos DB oplossing.

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

De primaire resource die u implementeert, is een Azure Cosmos DB account. Elk account kan meerdere databases met meerdere containers hebben. Containers fungeren als logische eenheden van distributie en schaalbaarheid. U kunt containers zoals verzamelingen, tabellen en grafieken maken, afhankelijk van de API die u gebruikt om te communiceren met Azure Cosmos DB. Zie Databases, containers en items in Azure Cosmos DB voor meer informatie over het resourcemodel. Elke container maakt gebruik van partitionering, die ondersteuning biedt voor hoge schaal en hoge prestaties.

U configureert doorvoer, die de hoeveelheid systeembronnen vertegenwoordigt die u kunt gebruiken voor het uitvoeren van query's en het werken met uw gegevens. U kunt doorvoer handmatig inrichten, automatisch schalen gebruiken om de capaciteit dynamisch aan te passen op basis van de vereisten van uw workload of het serverloze accounttype gebruiken om in rekening te worden gebracht voor uw werkelijke gebruik.

Eén account kan meerdere Azure regio's spanen, waardoor uw tolerantie voor regiostoringen toeneemt. U kunt meerdere regio's configureren voor lezen en als u de laag Bedrijfskritiek gebruikt, kunt u meerdere regio's gebruiken om te schrijven. Azure Cosmos DB uw gegevens automatisch geo-repliceert. Gedrag van geo-replicatie wordt beïnvloed door de configuratie die u gebruikt, zoals het consistentieniveau, waarmee wordt aangegeven hoe u compromissen wilt maken tussen gegevensconsistentie, beschikbaarheid, latentie en doorvoer. Verschillende consistentieniveaus optimaliseren voor verschillende problemen, ondersteunen verschillende garanties en bieden verschillende typen replicatie tussen regio's.

Fysieke architectuur

Azure Cosmos DB slaat meerdere replicas van uw gegevens op voor redundantie. De service vermindert automatisch replicastoringen door quorum tussen replica's in elke regio te onderhouden. Deze aanpak garandeert hoge beschikbaarheid en beschermt tegen gegevensverlies tijdens storingen in afzonderlijke knooppunten, zonder dat er toepassingswijzigingen of configuratie nodig zijn.

Intern beheert Azure Cosmos DB uw gegevens via verschillende constructies, waaronder physical partities, partition sets en replica sets. Zie Globale gegevensdistributie met Azure Cosmos DB - onder de schermen voor meer gedetailleerde informatie over hoe Azure Cosmos DB werkt.

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 cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

U wordt aangeraden de Azure Cosmos DB SDK's te gebruiken. De SDK's implementeren automatisch ondersteuning voor een reeks tolerantieoverwegingen, waaronder tijdelijke foutafhandeling via automatische nieuwe pogingen en het respecteren van reacties op frequentielimieten die door de service worden verzonden. Zie Ontwerp tolerante toepassingen met Azure Cosmos DB SDK's voor meer informatie.

Wanneer u met een account voor meerdere regio's werkt, ondersteunt de SDK ook een beschikbaarheidsstrategie op basis van drempelwaarden, ook wel hedging genoemd, waarbij parallelle leesaanvragen naar meerdere regio's worden verzonden en het snelste antwoord wordt geaccepteerd. Deze aanpak kan de prestaties van toepassingen verbeteren wanneer een regio tijdelijk een hogere latentie ondervindt dan normaal.

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 Cosmos DB ondersteunt zoneredundantie. Wanneer u zoneredundantie inschakelt, distribueert Azure de replica's van uw gegevens over meerdere beschikbaarheidszones, wat tolerantie biedt voor problemen met datacenters en storingen. Microsoft de te gebruiken beschikbaarheidszones selecteert.

Een Azure Cosmos DB-account kan meerdere regio's (locaties) gebruiken voor wereldwijde distributie, schaal en failover. U configureert zoneredundantie afzonderlijk voor elke regio in uw account.

Het gebruik van zoneredundantie in Azure Cosmos DB heeft geen merkbare invloed op prestaties of latentie. Er zijn geen aanpassingen aan de geselecteerde consistentiemodus vereist en hoeft geen wijzigingen aan de toepassingscode te worden aangebracht.

We raden u aan zoneredundantie te gebruiken in regio's waar deze worden ondersteund, met name voor accounts met één regio. Omdat beschikbaarheidszones fysiek gescheiden zijn en afzonderlijke energiebron, netwerk en koeling bieden, zijn de beschikbaarheids-SLA's voor Azure Cosmos DB hoger voor zone-redundante accounts dan accounts die geen beschikbaarheidszones gebruiken.

Als u zoneredundantie niet inschakelt, is het account niet-zonegebonden in die regio. Niet-zonegebonden accounts kunnen replica's vinden in één beschikbaarheidszone, wat leidt tot potentiële downtime als die specifieke zone een probleem ondervindt.

Requirements

• Region support: U kunt zoneredundantie inschakelen in Azure regio's die ondersteuning bieden voor beschikbaarheidszones. Zie de lijst met ondersteunde regio's om te zien of uw regio beschikbaarheidszones ondersteunt.

  Zoneredundantie is geen instelling voor het hele account. Azure Cosmos DB accounts kunnen meerdere regio's omvatten en elke regio kan onafhankelijk worden geconfigureerd voor het gebruik van beschikbaarheidszones. Regio's die geen ondersteuning bieden voor beschikbaarheidszones, verhinderen niet dat u zoneredundantie inschakelt in andere regio's binnen hetzelfde account.

• Serverloze accounts: U kunt alleen zoneredundante serverloze accounts configureren wanneer u ze maakt. U kunt bestaande serverloze accounts zonder beschikbaarheidszones niet converteren naar een configuratie van een beschikbaarheidszone. Voor bedrijfskritieke workloads raden we u aan om ingerichte doorvoer te gebruiken.

Considerations

• Meerdere gelijktijdige zonestoringen: Een account met één regio met zoneredundantie kan de beschikbaarheid van lezen/schrijven behouden wanneer een storing van invloed is op één beschikbaarheidszone. Als de storing echter van invloed is op meerdere beschikbaarheidszones of de hele regio, verliezen accounts met één regio lees- en schrijftoegang totdat de service is hersteld. Overweeg om een account voor meerdere regio's te implementeren als u bestand moet zijn tegen meerdere zones die tegelijkertijd mislukken.

• Accounts voor meerdere regio's: Als u een account voor meerdere regio's hebt, kunt u eventueel zoneredundantie inschakelen voor een of alle accountregio's die ondersteuning bieden voor beschikbaarheidszones. We raden u ten zeerste aan zoneredundantie in te schakelen wanneer uw account is geconfigureerd voor gebruik van één regio of als het is geconfigureerd voor het gebruik van één schrijfregio met meerdere leesregio's.

Cost

Regio's waarvoor zoneredundantie is ingeschakeld, worden tegen een hogere prijs in rekening gebracht. De premiumkosten voor beschikbaarheidszones worden echter kwijtgescholden voor accounts die zijn geconfigureerd met schrijfbewerkingen in meerdere regio's en voor verzamelingen die zijn geconfigureerd voor het gebruik van de autoschaaldoorvoermodus. Zie Azure Cosmos DB prijzen voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

Voor de meeste accounts schakelt u zoneredundantie alleen in wanneer u een nieuwe regio aan een Azure Cosmos DB-account toevoegt. Als u ondersteuning voor beschikbaarheidszones voor een bestaand account wilt inschakelen, voegt u een regio toe en schakelt u zoneredundantie in. U kunt een proces volgen om een tijdelijke regio toe te voegen, zodat u zoneredundantie in uw oorspronkelijke regio kunt configureren. Zie voor gedetailleerde stappen Inschakelen van zone-redundantie voor een Azure Cosmos DB-account.

Voor serverloze accounts moet u zoneredundantie inschakelen wanneer u het account maakt.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Azure Cosmos DB-account configureert voor zoneredundantie en alle zones operationeel zijn.

• Cross-zone bewerking: Azure Cosmos DB routeert verzoeken automatisch naar replica's in verschillende beschikbaarheidszones, zodat elke replica een verzoek kan afhandelen.

• Replicatie van gegevens in meerdere zones: Wanneer een client een wijziging aanbrengt in gegevens, wordt die wijziging toegepast op meerdere replica's in verschillende zones om quorum te bereiken. Deze benadering wordt synchrone replicatie genoemd. Synchrone replicatie zorgt voor een hoog gegevensconsistentieniveau, wat de kans op gegevensverlies tijdens een zonefout vermindert. Beschikbaarheidszones bevinden zich relatief dicht bij elkaar, wat betekent dat er minimaal effect is op latentie of doorvoer.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Azure Cosmos DB-account configureert voor zoneredundantie en er een storing is in een van de zones.

• Detection and response: Het Azure Cosmos DB-platform is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone. U hoeft niets te doen om een zonefailover te starten.

• Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt echter Azure Resource Health gebruiken om de status van een afzonderlijke resource te controleren 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: Wanneer een beschikbaarheidszone niet beschikbaar is, beëindigt Azure Cosmos DB alle actieve aanvragen die zijn verbonden met replica's in de betrokken zone en moet de toepassing deze aanvragen opnieuw proberen. Zorg ervoor dat uw toepassing is voorbereid door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.

• Verwachte gegevensverlies: Er zijn geen verwachte gegevensverlies van een zonefout.

• Verwachte downtime: Tijdens zonestoringen kunnen verbindingen korte onderbrekingen ondervinden die doorgaans enkele seconden duren wanneer het verkeer opnieuw wordt gedistribueerd. Zorg ervoor dat uw toepassingen zijn voorbereid door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.

• Redistribution: Azure Cosmos DB stuurt binnenkomende aanvragen automatisch om naar goede replica's in andere beschikbaarheidszones. Wanneer een beschikbaarheidszone een storing heeft, wordt de ingerichte doorvoer automatisch opnieuw toegewezen aan andere replica's.

Zoneherstel

Wanneer de beschikbaarheidszone wordt hersteld, herstelt Azure Cosmos DB automatisch de replica's in de beschikbaarheidszone en leidt het verkeer zoals gebruikelijk tussen de replica's om.

Testen op zonefouten

Failover en herstel van beschikbaarheidszones voor Azure Cosmos DB worden volledig beheerd door Microsoft. U hoeft geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren.

Tolerantie voor storingen in de hele regio

Wanneer u een Azure Cosmos DB-account in één regio implementeert, veroorzaakt een regiobrede storing die van invloed is op alle Azure Cosmos DB knooppunten doorgaans geen gegevensverlies, maar voorkomt u wel dat uw toepassing toegang krijgt tot gegevens. Azure Cosmos DB gegevenstoegang herstelt nadat de service is hersteld in de betreffende regio. Gegevensverlies treedt alleen op als de regio een onherstelbare ramp ondervindt.

Als u zich wilt voorbereiden op de zeldzame gevallen van regiostoringen, kunt u Azure Cosmos DB configureren ter ondersteuning van verschillende niveaus van duurzaamheid en beschikbaarheid met behulp van een van deze methoden:

• Meerdere leesregio's met één schrijfregio. U kunt optioneel door de service beheerde failover of automatische failover per partitie (PPAF) inschakelen.
• Meerdere schrijfregio's.

De volgende tabel bevat een overzicht van de herstelopties die beschikbaar zijn op basis van de accountconfiguratie en het type storing. In latere secties van dit artikel vindt u uitgebreide informatie over deze opties en het bijbehorende gedrag.

SDKs en veerkracht

De Azure Cosmos DB SDK's zijn een belangrijk onderdeel van de tolerantiestrategie van uw toepassing. Wanneer u een account voor meerdere regio's hebt, is de SDK-configuratie van invloed op de manier waarop aanvragen worden gerouteerd tussen regio's, inclusief de voorkeursregio's waarmee verbinding moet worden gemaakt en regio's die moeten worden uitgesloten. SDK's controleren de beschikbaarheid van regio's en partities en kunnen zichzelf dynamisch opnieuw configureren om gezonde regio's en partities te gebruiken, zoals via de circuitonderbreker op partitieniveau.

Zie de documentatie voor hoge beschikbaarheid voor de SDK die u gebruikt voor meer informatie over hoe de SDK hoge beschikbaarheid ondersteunt:

• Azure Cosmos DB .NET SDK v3
• Azure Cosmos DB Java SDK v4
• Azure Cosmos DB Python SDK

Potentieel gegevensverlies tijdens regiostoringen

Wanneer u een Azure Cosmos DB-account in meerdere regio's implementeert, is duurzaamheid van gegevens afhankelijk van het consistentieniveau dat u voor het account configureert. De volgende tabel details, voor alle consistentieniveaus, het herstelpuntdoel (RPO) van een Azure Cosmos DB-account dat geïmplementeerd is in ten minste twee regio's. De RPO vertegenwoordigt het potentiële gegevensverlies tijdens een regiostoring.

K = Het aantal versies (dat wil gezegd, updates) van een item.

T = Het tijdsinterval sinds de laatste update.

Voor accounts met meerdere regio's is de minimale waarde van K en T 100.000 schrijfbewerkingen of 300 seconden. Deze waarde definieert de minimale RPO voor gegevens wanneer u gebonden veroudering gebruikt.

Zie Consistentieniveaus in Azure Cosmos DB voor meer informatie over de verschillen tussen consistentieniveaus.

Meerdere leesregio's met één schrijfregio

Als uw oplossing continue uptime vereist tijdens regiostoringen, kunt u Azure Cosmos DB configureren om uw gegevens te repliceren in meerdere regio's, met schrijfbewerkingen die worden verwerkt door uw primaire regio. U kunt uw toepassingen desgewenst configureren om verbinding te maken met specifieke leesregio's, wat kan helpen om hun prestaties te verbeteren. Als een regio een storing heeft, kan het account blijven werken vanuit gezonde regio's.

Failover tussen regio's

U kunt de Azure Cosmos DB SDK configureren met een lijst met leesregio's met prioriteit. De SDK verbindt uw toepassing met de eerste beschikbare regio in de lijst. Tijdens een storing in de leesregio detecteert de SDK de storing via back-endantwoordcodes, markeert de regio als niet beschikbaar en leidt toekomstige bewerkingen om naar de volgende beschikbare regio in de voorkeurslijst. Zorg ervoor dat de lijst met voorkeursregio's correct is ingesteld en is afgestemd op de vereisten voor uw bedrijf en latentie. Zie Problemen met de beschikbaarheid van de Azure Cosmos DB SDK oplossen voor gedetailleerde richtlijnen.

Failover is het proces waarbij een van de regio's van uw account volledig of gedeeltelijk niet beschikbaar is. Het effect van een failover is afhankelijk van of de regio een schrijfregio of een leesregio is:

• Als een schrijfregio niet meer beschikbaar is, wordt een andere regio de schrijfregio.
• Als een leesregio niet beschikbaar is, kan die regio geen leesaanvragen verwerken en worden andere regio's gebruikt voor leesbewerkingen.

Azure Cosmos DB biedt meerdere soorten failover:

• Per-partitie automatische failover (PPAF): In Azure Cosmos DB worden de gegevens verspreid over meerdere fysieke partities. Als er een probleem optreedt met de infrastructuur die een partitie ondersteunt, worden andere partities mogelijk niet beïnvloed. MET PPAF kunnen regioaccounts met één schrijfbewerking automatisch een failover uitvoeren voor afzonderlijke partities naar een secundaire regio, terwijl de partities in de primaire regio in orde blijven. PPAF kan helpen om downtime te minimaliseren en sneller herstel mogelijk te maken tijdens een gedeeltelijke storing in de regio. Zie Hoe u Per-Partition Automatic Failover (PPAF) voor Azure Cosmos DB kunt onboarden en adopteren voor meer informatie.

  Note

  Automatische failover per partitie bevindt zich in openbare preview. Deze functie wordt geleverd zonder service level agreement. Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews voor meer informatie.

• Geforceerde failover: U kunt een van de regio's van uw account offline nemen. Dit wordt ook wel een door de klant beheerde failover of een offlineregiobewerking genoemd. Dit is de aanbevolen methode voor het snel herstellen van beschikbaarheid tijdens een storing. U bent verantwoordelijk voor het detecteren van de storing en het activeren van de failover. U kunt ook geforceerde failovers gebruiken om scenario's met uitval van een regio te simuleren voor testdoeleinden, zoals tijdens een noodhersteloefening.

  Als u de schrijfregio offline zet, wordt de leesregio met de volgende hoogste prioriteit de nieuwe schrijfregio. Als u een leesregio offline neemt, kunnen uw toepassingen verbinding maken met een andere leesregio in het account.

  Een geforceerde failover van uw schrijfregio biedt de mogelijkheid van gegevensverlies voor niet-gerepliceerde schrijfbewerkingen.

  Na een geforceerde failover moet Microsoft de regio weer online brengen. Voor gezonde regio's is dit proces geautomatiseerd, maar het kan enkele dagen duren. Als de regio niet binnen een of twee dagen online komt, opent u een ondersteuningsaanvraag om hulp aan te vragen.

• Schrijfregio wijzigen: Wanneer de regio's in orde zijn, kunt u de schrijfregio van uw account wijzigen. Deze wijziging is in feite een geplande failover van de schrijfregio voor uw account.

  Als u de schrijfregio wijzigt, leidt dit tot geen gegevensverlies, omdat de gegevensreplicatie optreedt voordat de nieuwe schrijfregio wordt gepromoveerd. Er kan een korte onderbreking optreden, maar klanten die gebruikmaken van herhalingslogica en andere technieken voor tijdelijke foutafhandeling hebben doorgaans geen aanzienlijke gevolgen.

  Voor deze bewerking moeten de regio's in orde zijn, zodat deze niet kunnen worden gebruikt tijdens een storing in de regio.

• Service-beheerde failover: Wanneer uw account gebruikmaakt van door de service beheerde failover, is Microsoft verantwoordelijk voor het bepalen wanneer een failover tussen regio's moet worden uitgevoerd. Als u door de service beheerde failover wilt inschakelen, geeft u prioriteiten op voor elke regio. Het proces voor het declareren van een storing en het activeren van door de service beheerde failover kan echter veel tijd in beslag nemen, mogelijk een uur of langer. Voor sneller herstel moet u een geforceerde failover uitvoeren in plaats van te wachten tot een door de service beheerde failover wordt geactiveerd.

  Als Microsoft servicebeheerde failover activeert voor de schrijfregio van het account, kunnen niet-gerepliceerde schrijfbewerkingen verloren gaan.

  Na een door de service beheerde failover moet Microsoft een regio weer online brengen. Microsoft brengt de regio automatisch online, maar dit proces kan enkele dagen duren.

Requirements

Regio-ondersteuning: U kunt elke Azure regio configureren als een leesregio voor uw Azure Cosmos DB-account.

Cost

Als u een extra leesregio toevoegt aan een Azure Cosmos DB-account, worden uw bestaande kosten voor elke regio verhoogd. Zie Azure Cosmos DB prijzen voor meer informatie.

Meerdere leesregio's configureren

• Leesregio's toevoegen aan een account: U kunt meerdere regio's in uw account configureren wanneer u het account maakt of op elk gewenst moment nadat het account is gemaakt. Zie Regio's toevoegen/verwijderen uit uw databaseaccount voor meer informatie.

• Failover inschakelen: Sommige typen failovers moeten vooraf worden geconfigureerd:

  • Per-partitie automatische failover: Voor meer informatie, zie Hoe u Per-partitie Automatische Failover (PPAF) voor Azure Cosmos DB kunt onboarden en adopteren.

  • Door de service beheerde failover: Schakel eerst door de service beheerde failover in. Stel vervolgens failoverprioriteiten in voor elke regio in uw account.

Capaciteitsplanning en -beheer

Als uw toepassing aanvragen verspreidt over regio's en één regio offline gaat, hebben de resterende regio's een hoger aanvraagvolume. Gebruik automatische capaciteitsvergroting om de capaciteit dynamisch aan te passen op basis van de vraag. Als u toegewezen doorvoer gebruikt, plan dan voldoende capaciteit om het verlies van een regio op te vangen zonder dat de dienstkwaliteit daaronder lijdt, en overweeg overprovisioning. Zie Capaciteit beheren met overinrichting voor meer informatie.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Azure Cosmos DB-account met meerdere leesregio's configureert en alle regio's operationeel zijn.

• Bewerking tussen regio's: Uw toepassing configureert de regio die leesbewerkingen moet ontvangen. U kunt uw toepassing configureren met een lijst met regio's met prioriteit of om bepaalde regio's uit te sluiten. Zie Diagnose en het oplossen van problemen met de beschikbaarheid van Azure Cosmos DB SDK's in multiregionale omgevingen voor meer informatie over hoe regioselectie werkt.

  Alle schrijfbewerkingen worden omgeleid naar de schrijfregio van uw account.

• Replicatie van gegevens in meerdere regio's: Alle schrijfbewerkingen vinden plaats in de primaire regio van uw account. Schrijfbewerkingen worden gerepliceerd naar de andere leesregio's op basis van het geconfigureerde consistentieniveau van het account. Zie Potentiële gegevensverlies tijdens regiostoringen voor meer informatie over de maximale replicatievertraging.

Gedrag tijdens een storing in het leesgebied

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Azure Cosmos DB-account met meerdere leesregio's configureert en er een storing optreedt in een van de leesregio's van het account.

• Detectie en reactie: De verantwoordelijkheid voor het detecteren van de storing en het reageren is afhankelijk van het type failover dat uw account gebruikt.

  • PPAF: PPAF is doorgaans niet van toepassing op storingen in leesregio's. Voor accounts met sterke consistentie en slechts twee regio's vermindert het verlies van de leesregio echter het account tot één regio, waardoor het dynamische quorum niet kan worden gehandhaafd. In dit scenario kan PPAF activeren om de beschikbaarheid te behouden door de betrokken partities naar de gezonde regio te verplaatsen.

  • Geforceerde failover: U bent verantwoordelijk voor het uitvoeren van een geforceerde failover. Zie voor gedetailleerde stappen Geforceerde failover uitvoeren voor uw Azure Cosmos DB-account.

    Als u geen failover uitvoert, is het gedrag van uw account afhankelijk van het consistentieniveau:

    • Sterke consistentie: voor sterke consistentie zijn twee of meer regio's vereist om dynamisch quorum te behouden. Als er minder dan twee regio's beschikbaar zijn en u geen failover uitvoert, verliest het account de beschikbaarheid om te schrijven totdat de service is hersteld.

    • Gebonden verouderingsconsistentie: Gebonden verouderingsconsistentie is afhankelijk van het handhaven van een specifieke verouderingsdrempel tussen regio's. Als de lengte van de regiostoring de drempelwaarde overschrijdt, kan het systeem de consistentie tussen schrijfbewerkingen niet behouden. Als u geen failover uitvoert, verliest het account schrijf beschikbaarheid totdat de service is hersteld.

  • Service-beheerde failover: Als door de service beheerde failover is ingeschakeld, detecteert Microsoft uiteindelijk de storing en start u een failover van uw account. Dit proces kan echter veel tijd in beslag nemen, mogelijk een uur of meer. Voor sneller herstel moet u een geforceerde failover uitvoeren in plaats van te wachten tot een door de service beheerde failover wordt geactiveerd.

• Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. Aan de andere kant:

  • U kunt Azure Resource Health 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 gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Actieve aanvragen kunnen worden beëindigd en moeten opnieuw worden geprobeerd door de client nadat de failover is voltooid. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

• Verwachte gegevensverlies: Een storing in een leesregio veroorzaakt geen gegevensverlies. Azure Cosmos DB blijft de garanties voor leesconsistentie respecteren.

• Verwachte downtime: De hoeveelheid downtime die uw account ondervindt, is afhankelijk van het type failover dat uw account gebruikt.

  • PPAF: Wanneer PPAF is ingeschakeld, detecteert en herstelt het systeem automatisch na de fout, meestal binnen 3 minuten, zonder handmatige tussenkomst.

  • Geforceerde failover: Downtime is afhankelijk van:

    • Hoe lang het duurt om de storing te detecteren en een failover te starten.

    • Hoe lang de failover duurt, meestal een paar seconden.

      Warning

      Voer tijdens storingsscenario's geen configuratiebewerkingen (besturingsvlak) uit op de betreffende regio, omdat dit leidt tot inconsistentie van het account en het vertragen van herstel. Enkele voorbeelden van besturingsvlakbewerkingen die moeten worden vermeden:

      • Schrijfregio wijzigen of failoverprioriteit wijzigen
      • Het account bijwerken naar configuratie voor meerdere schrijfbewerkingen
      • Consistentieniveaus of andere accountinstellingen bijwerken
      • Configuraties of netwerkinstellingen voor privé-eindpunten bijwerken
      • Accountdoorvoer bijwerken of schalingsoperaties uitvoeren
      • Elke andere bewerking waarmee de accountconfiguratie of regio-instellingen worden gewijzigd

  • Service-beheerde failover: Microsoft is verantwoordelijk voor het initiëren van door de service beheerde failover en de downtime van uw account is gebaseerd op de tijd die Microsoft nodig heeft om de storing te declareren en failover te starten. In sommige situaties kan het een uur of langer duren. Als uw account onderbreking van schrijfbewerkingen ondervindt en u de beschikbaarheid van schrijfbewerkingen snel wilt herstellen, voert u een geforceerde failover uit.

• Herverdeling: Voor geforceerde failover of door de service beheerde failover wordt de verbinding met de betrokken regio verbroken en als offline gemarkeerd.

  Er zijn geen wijzigingen vereist in uw toepassingscode om storingen in leesregio's af te handelen. De Azure Cosmos DB SDK's leesbewerkingen omleiden naar de volgende beschikbare regio in de lijst met voorkeursregio's. Als geen van de regio's in de lijst met voorkeursregio's beschikbaar is, vallen leesbewerkingen automatisch terug naar de huidige schrijfregio van het account, zoals geconfigureerd in de service.

  Note

  Als u privé-eindpunten gebruikt met een Azure Cosmos DB-account, moet u ervoor zorgen dat de privé-DNS correct wordt gerouteerd na de offlineregiobewerking. Zie voor gedetailleerde richtlijnen Failover-overwegingen voor privé-eindpunten.

Gedrag tijdens een fout in een schrijfregio

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Azure Cosmos DB-account met meerdere leesregio's configureert en er een storing optreedt in de schrijfregio van het account.

• Detectie en reactie: De verantwoordelijkheid voor het detecteren van de storing en het reageren is afhankelijk van het type failover dat uw account gebruikt.

  • PPAF: Microsoft detecteert automatisch de storing en initieert een failover van sommige partities, indien van toepassing. Uw toepassing hoeft geen actie te ondernemen.

  • Geforceerde failover: U bent verantwoordelijk voor het uitvoeren van een geforceerde failover. Zie Een geforceerde failover uitvoeren voor uw Azure Cosmos DB-account voor gedetailleerde stappen.

    Als u geen failover uitvoert, verliest het account schrijf beschikbaarheid totdat de service is hersteld.

    Als er een storing optreedt in de schrijfregio van uw account, vermijd dan het uitvoeren van een schrijfregio wijzigen bewerking. Wijzigingen in schrijfregio slagen niet als er een uitval optreedt in de bron- of doelregio. De reden hiervoor is dat de procedure voor regiowijziging een consistentiecontrole bevat waarvoor connectiviteit tussen de regio's is vereist.

  • Service-beheerde failover: Microsoft detecteert automatisch de storing en initieert een failover van uw account. Uw toepassing hoeft geen actie te ondernemen.

• Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. Aan de andere kant:

  • U kunt Azure Resource Health 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 gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Actieve aanvragen kunnen worden beëindigd en moeten opnieuw worden geprobeerd door de client nadat de failover is voltooid. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

• Verwachte gegevensverlies: Als u uw account configureert met sterke consistentie, treedt er geen gegevensverlies op. Anders kunnen niet-gerepliceerde schrijfbewerkingen verloren gaan nadat de failover is voltooid. Zie Potentiële gegevensverlies tijdens regiostoringen voor informatie over het maximale gegevensverlies dat tijdens een regiostoring wordt verwacht.

• Verwachte downtime: De hoeveelheid downtime die uw account ondervindt, is afhankelijk van het type failover dat uw account gebruikt.

  • PPAF: Wanneer PPAF is ingeschakeld, verwacht u een korte onderbreking, meestal ongeveer 3 minuten.

  • Geforceerde failover: Downtime is afhankelijk van:

    • Hoe lang het duurt om de storing te detecteren en een failover te starten.
    • Hoe lang de failover duurt, meestal een paar seconden.

  Warning

  Voer geen beheerbewerkingen uit op de getroffen regio tijdens storingen, omdat dit leidt tot inconsistentie van accounts en vertraging van herstel. Enkele voorbeelden van besturingsvlakbewerkingen die moeten worden vermeden:

  • Schrijfregio wijzigen of failoverprioriteit wijzigen
  • Het account bijwerken naar configuratie voor meerdere schrijfbewerkingen
  • Consistentieniveaus of andere accountinstellingen bijwerken
  • Configuraties of netwerkinstellingen voor privé-eindpunten bijwerken
  • Accountdoorvoer bijwerken of schalingsoperaties uitvoeren
  • Elke andere bewerking waarmee de accountconfiguratie of regio-instellingen worden gewijzigd
  • Service-beheerde failover: Microsoft is verantwoordelijk voor het initiëren van door de service beheerde failover en de downtime van uw account is gebaseerd op de tijd die Microsoft nodig heeft om de storing te declareren en failover te starten. In sommige situaties kan het een uur of langer duren. Als u de beschikbaarheid van schrijfbewerkingen snel wilt herstellen, voert u een geforceerde failover uit.

• Herverdeling: Herdistributie van schrijfverkeer is afhankelijk van het type failover dat door uw account wordt gebruikt.

  • PPAF: Azure Cosmos DB voert automatisch een failover uit van de beschadigde partitie naar een gezonde regio.

  • Geforceerde failover: Wanneer u een geforceerde failover uitvoert, wordt de schrijfregio van uw account gewijzigd in de regio die u opgeeft.

  Note

  Als u privé-eindpunten gebruikt met een Azure Cosmos DB-account, moet u ervoor zorgen dat de privé-DNS correct wordt gerouteerd na de offlineregiobewerking. Zie voor gedetailleerde richtlijnen Failover-overwegingen voor privé-eindpunten.

  • Service-beheerde failover: Azure Cosmos DB bevordert automatisch een van de secundaire regio's van het account als de nieuwe primaire schrijfregio. De failover treedt op in een andere regio in de volgorde van de regioprioriteit die u opgeeft.

Herstel van de regio

Microsoft moet een regio weer online brengen. Wanneer een regio na een storing herstelt, wordt de regio automatisch door Microsoft online gebracht. Dit proces kan echter enkele dagen duren.

Nadat de regio online is, verschillen de acties die u uitvoert, afhankelijk van of de storing zich in een leesregio of een schrijfregio bevindt.

• Na storingen in de leesregio: Wanneer de betrokken regio weer online is, wordt deze gesynchroniseerd met de huidige schrijfregio en is deze weer beschikbaar om leesaanvragen te verwerken nadat deze volledig is opgepikt. Latere leesbewerkingen worden omgeleid naar de herstelde regio zonder dat er wijzigingen in uw toepassingscode nodig zijn. Tijdens zowel failover als opnieuw verbinden met een eerder uitgevallen regio, blijft Azure Cosmos DB rekening houden met de garanties van leesconsistentie.

• Na schrijf regiostoringen: Wanneer de betrokken regio weer online is, wordt de regio weergegeven als 'online' in de Azure-portal en wordt deze beschikbaar als een leesregio. Op dit moment is het veilig om de schrijfregio weer te wijzigen in de herstelde regio.

  Important

  De herstelde regio wordt niet automatisch teruggepromoveerd naar de schrijfregio zodra deze is hersteld. Het is uw verantwoordelijkheid om terug te keren naar de herstelde regio als de schrijfregio, zodra dit veilig is.

  Er zijn geen gegevens of beschikbaarheidsverlies voor, terwijl of nadat u de schrijfregio hebt gewijzigd. Uw toepassing blijft maximaal beschikbaar.

  Als bepaalde schrijfbewerkingen niet zijn gerepliceerd voordat de regio offline ging, kunt u de niet-gerepliceerde schrijfbewerkingen lezen uit de conflictfeed. Uw toepassing kan de conflictfeed lezen, eventuele conflicten oplossen op basis van toepassingsspecifieke logica en de bijgewerkte gegevens zo nodig terugschrijven naar de container.

Test voor regiofouten

Uw toepassing verwerkt mogelijk niet correct regiofailovers, zelfs als uw Azure Cosmos DB account maximaal beschikbaar is. Als u de end-to-end hoge beschikbaarheid van uw applicatie wilt testen als onderdeel van uw applicatietests of noodhersteltests, schakelt u servicebeheerde failover tijdelijk uit voor het account. Roep forceerde failover aan met behulp van PowerShell, de Azure CLI of de Azure-portal en bewaak vervolgens uw toepassing. Nadat u de test hebt voltooid, kunt u zodra de primaire regio automatisch weer online komt, terugkeren naar deze regio en vervolgens de service-beheerde failover voor het account herstellen. Als de regio niet binnen een of twee dagen online komt, opent u een ondersteuningsaanvraag om hulp aan te vragen.

Als uw account PPAF gebruikt, kunt u een partitiefailover simuleren. Zie De PPAF-installatie testen (fout simuleren) voor meer informatie.

Meerdere schrijfregio's

U kunt Azure Cosmos DB zo configureren dat schrijfbewerkingen in meerdere regio's worden geaccepteerd. Deze configuratie kan zeer hoge tolerantie bieden voor regiostoringen. Het is ook handig voor het verminderen van de schrijflatentie in geografisch gedistribueerde toepassingen.

Wanneer u een Azure Cosmos DB-account configureert voor meerdere schrijfregio's, wordt sterke consistentie niet ondersteund en kunnen er schrijfconflicten optreden. De hub-regio fungeert als een arbiter in schrijfconflicten. Zie Conflicttypen en oplossingsbeleid bij het gebruik van meerdere schrijfregio's voor meer informatie over het oplossen van deze conflicten.

Het is belangrijk om rekening te houden met het ontwerp van uw toepassing en hoe deze werkt met meerdere schrijfregio's. Bekijk de aanbevolen procedures voor schrijfbewerkingen in meerdere regio's.

Requirements

Regio-ondersteuning: U kunt elke Azure regio configureren als een lees- of schrijfregio voor uw Azure Cosmos DB-account.

Cost

Als u een extra schrijfregio toevoegt aan een Azure Cosmos DB-account, worden uw bestaande kosten voor elke regio verhoogd. Zie Azure Cosmos DB prijzen voor meer informatie.

Meerdere schrijfregio's configureren

U kunt meerdere schrijfregio's voor uw account configureren wanneer u het account maakt of op elk gewenst moment nadat het account is gemaakt. Zie Meerdere schrijfregio's configureren voor meer informatie.

Als u effectief meerdere schrijfregio's wilt gebruiken, moet uw app ook op de juiste wijze worden geconfigureerd. Zie Multi-regio schrijfbewerkingen configureren in toepassingen die Azure Cosmos DB gebruiken.

Capaciteitsplanning en -beheer

Als uw toepassing aanvragen verspreidt over regio's en één regio offline gaat, hebben de resterende regio's een hoger aanvraagvolume. Gebruik automatische capaciteitsvergroting om de capaciteit dynamisch aan te passen op basis van de vraag. Als u toegewezen doorvoer gebruikt, plan dan voldoende capaciteit om het verlies van een regio op te vangen zonder dat de dienstkwaliteit daaronder lijdt, en overweeg overprovisioning. Zie Capaciteit beheren met overinrichting voor meer informatie.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Azure Cosmos DB-account met meerdere schrijfregio's configureert en alle regio's operationeel zijn.

• Bewerking tussen regio's: Wanneer een account is geconfigureerd met meerdere schrijfregio's, configureert uw toepassing de regio die moet worden gebruikt voor lees- en schrijfbewerkingen. U kunt uw toepassing configureren met een lijst met regio's met prioriteit of om bepaalde regio's uit te sluiten. Zie Diagnose en het oplossen van problemen met de beschikbaarheid van Azure Cosmos DB SDK's in multiregionale omgevingen voor meer informatie over hoe regioselectie werkt. Voor meer informatie over het configureren van uw toepassing, zie Configure multi-region writes in toepassingen die gebruikmaken van Azure Cosmos DB.

• Replicatie van gegevens in meerdere regio's: Gegevens worden asynchroon tussen regio's gerepliceerd. De replicatievertraging is afhankelijk van het consistentieniveau van het account. U kunt geen sterke consistentie gebruiken voor schrijfbewerkingen over meerdere regio's. Zie Potentiële gegevensverlies tijdens regiostoringen voor meer informatie.

  Wanneer een account is geconfigureerd voor meerdere schrijfregio's, kunnen toepassingen in verschillende regio's wijzigingen aanbrengen die met elkaar conflicteren. Azure Cosmos DB biedt mogelijkheden voor conflictoplossing. Zie Conflicttypen en oplossingsbeleid voor meer informatie wanneer u meerdere schrijfregio's gebruikt. Zie Beleid voor conflictoplossing beheren in Azure Cosmos DB voor meer informatie over het configureren van uw eigen beleid voor conflictoplossing.

  Note

  Het regelmatig bijwerken van dezelfde document-id of het opnieuw maken van dezelfde document-id nadat de TTL is verlopen of verwijderd, heeft een negatieve invloed op de replicatieprestaties vanwege een verhoogd aantal conflicten dat in het systeem is gegenereerd.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een Azure Cosmos DB-account met meerdere schrijfregio's configureert en er een storing is in een van de lees- of schrijfregio's van het account.

• Detectie en reactie: Uw toepassing detecteert het verlies van de regio. Azure Cosmos DB SDK's bieden mogelijkheden voor automatische regioselectie waarmee lees- en schrijfbewerkingen worden doorgestuurd naar gezonde regio's.

• Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. Aan de andere kant:

  • U kunt Azure Resource Health 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 gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Actieve aanvragen kunnen worden beëindigd en moeten opnieuw worden geprobeerd door de client nadat de failover is voltooid. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

• Verwachte gegevensverlies: Onlangs bijgewerkte gegevens zijn mogelijk niet beschikbaar in andere regio's. Zie Potentiële gegevensverlies tijdens regiostoringen voor informatie over het maximale gegevensverlies dat tijdens een regiostoring wordt verwacht. In het onwaarschijnlijke geval dat de getroffen regio permanent gegevensverlies ondervindt, gaan mogelijk niet-gerepliceerde gegevens verloren.

• Verwachte downtime: Er is geen verwachte downtime in configuraties voor meerdere schrijfbewerkingen, mits SDK's correct zijn geconfigureerd met ApplicationRegions of PreferredRegions.

  Tip

  Voor de beste resultaten moeten wereldwijd gedistribueerde toepassingen worden voorbereid door een wereldwijde taakverdelingsservice, zoals Azure Front Door of Azure Traffic Manager. Deze services kunnen regionale afname detecteren en verkeer automatisch doorsturen naar toepassingsexemplaren in een gezonde regio.

• Redistribution: De Azure Cosmos DB SDK's detecteren automatisch dat de regio niet in orde is en lees- en schrijfbewerkingen omleiden naar de volgende beschikbare regio in de lijst met voorkeursregio's. Er zijn geen wijzigingen vereist in uw toepassingscode.

  Tip

  Als uw toepassing wordt geleid door Azure Front Door of Traffic Manager, detecteren deze services ook regionale degradatie en routeer het verkeer naar een gezonde regio.

Herstel van de regio

Wanneer de getroffen regio weer online is, wordt de regio weergegeven als 'online' in de Azure-portal en wordt deze weer beschikbaar.

Schrijfgegevens die niet zijn gerepliceerd wanneer de regio uitviel, worden beschikbaar gesteld via de conflictfeed. Toepassingen kunnen de conflictfeed lezen, de conflicten oplossen op basis van de toepassingsspecifieke logica en de bijgewerkte gegevens zo nodig terugschrijven naar de Azure Cosmos DB-container.

Test voor regiofouten

Als u schrijffailoverscenario's voor meerdere regio's wilt testen, kunt u een schrijfregio offline halen met behulp van een geforceerde failover. Met dit proces wordt een regio-storing gesimuleerd en kunt u zien hoe uw toepassing reageert.

Back-up maken en terugzetten

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.

Gegevensverlies kan optreden vanwege onbedoelde verwijderingen of andere problemen in uw toepassing die leiden tot beschadiging van gegevens. Wanneer u een account met één regio gebruikt, kan gegevensverlies ook optreden vanwege een onherstelbare ramp in de Azure Cosmos DB regio. Om u te beschermen tegen gegevensverlies, biedt Azure Cosmos DB een set mogelijkheden voor back-up en herstel. U kunt back-ups en retentie configureren op basis van uw vereisten voor herstelbaarheid en kosten. Zie Online back-up en on-demand gegevens herstellen in Azure Cosmos DB voor meer informatie.

Tolerantie voor serviceonderhoud

Azure Cosmos DB alle details van afzonderlijke rekenknooppunten transparant beheert en automatisch patches en andere typen gepland onderhoud uitvoert. De Azure Cosmos DB SLA's voor beschikbaarheid en latentie zijn van toepassing via alle automatische onderhoudsbewerkingen die door het systeem worden uitgevoerd.

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Azure Cosmos DB biedt SLA's voor een reeks configuraties en servicekenmerken, waaronder beschikbaarheid, latentie, doorvoer en consistentie.

De beschikbaarheids-SLA's verschillen, afhankelijk van of u een van de volgende productmogelijkheden gebruikt:

• Ingestelde doorvoer
• Account met één regio met ondersteuning voor beschikbaarheidszones (zoneredundantie)
• Accounts die gebruikmaken van meerdere leesregio's
• Accounts die gebruikmaken van meerdere schrijfregio's (bedrijfskritieke laag)

Verwante inhoud

• Azure-betrouwbaarheid
• overzicht van Azure Cosmos DB
• Consistentieniveaus in Azure Cosmos DB
• Globale gegevensdistributie met Azure Cosmos DB
• Diagnose en los problemen op met de beschikbaarheid van Azure Cosmos DB SDK's in multiregionale omgevingen