Tillförlitlighet i Azure DocumentDB

Azure DocumentDB är en fullständigt hanterad NoSQL databastjänst för modern programutveckling med MongoDB-kompatibilitet. Azure DocumentDB stöder en konfiguration med hög tillgänglighet (HA) med synkront replikerade repliker i vänteläge och zonredundans. Den erbjuder också en valfri läsreplika i en annan Azure-region och automatiska säkerhetskopior med återställning till en viss tidpunkt för att skydda mot oavsiktliga dataförluster.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver hur du gör Azure DocumentDB motståndskraftig mot olika potentiella avbrott och problem, inklusive tillfälliga fel, avbrott i tillgänglighetszonen, regionstopp och serviceunderhåll. Den beskriver också hur säkerhetskopiering fungerar och ger viktig information om HA och replikering mellan regioner.

Rekommendationer för produktionsdistribution för tillförlitlighet

En lista över rekommendationer för att förbättra klustrets tillförlitlighet finns i Metodtips för hög tillgänglighet (HA) och replikering mellan regioner i Azure DocumentDB.

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

Den primära resursen som du distribuerar är ett Azure DocumentDB-kluster. För varje kluster väljer du en beräkningsnivå och konfigurerar lagring. Den valda nivån avgör vilka funktioner som är tillgängliga för tillförlitlighetsfunktioner som hög tillgänglighet (HA), och det påverkar även hur du planerar kapacitet för motståndskraftsscenarier.

Program ansluter till ett kluster med hjälp av anslutningssträngar och slutpunkter. Azure DocumentDB tillhandahåller anslutningsändpunkter för läs- och skrivoperationer och, när det har konfigurerats, ändpunkter för kluster med läsrepliker. Med de här slutpunkterna kan ditt program fortsätta att använda stabila anslutningsmönster medan tjänsten hanterar redundansbeteende i bakgrunden.

I varje kluster ordnas dina data som databaser, samlingar och dokument. Den här MongoDB-kompatibla datamodellen är grunden för designbeslut på arbetsbelastningsnivå, till exempel strategi för horisontell partitionering, läs- och skrivmönster samt omfång för säkerhetskopiering och återställning.

Fysisk arkitektur

Azure DocumentDB kör klustret på shards, som representerar noder (virtuella datorer) som kör tjänsten. Du kan distribuera en shard eller skala ut till flera shards. Att distribuera flera shardar förbättrar skalningskapaciteten, men ger i sig inte hög tillgänglighet.

När du aktiverar HA etablerar Azure DocumentDB en matchande uppsättning väntelägesshards. Varje primär shard har en reservshard. Tjänsten replikerar data synkront mellan varje primär-/sekundärpar och befordrar sekundärfragmentet om primärfragmentet fallerar. Mer information om HA finns i Hög tillgänglighet i Azure DocumentDB.

Azure DocumentDB använder Azure Storage för shardars hållbarhet. Om HA är inaktiverat använder varje shard lokalt redundant lagring (LRS). LRS lagrar tre kopior av data, men skyddar inte mot bortfall av en tillgänglighetszon. Information om LRS-hållbarhet finns i Sammanfattning av redundansalternativ.

Mer information finns i Tillgänglighet och haveriberedskap (DR) i Azure DocumentDB: Behind the scenes.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av övergående fel.

Azure DocumentDB är kompatibelt med MongoDB-protokollet, så program ansluter vanligtvis med mongoDB-drivrutiner. Du ansvarar för att konfigurera programmets inställningar för omförsök av drivrutin för att hantera tillfälliga fel, särskilt anslutningsavbrott och korta skrivavbrott under redundansväxlingar. Följ dessa riktlinjer:

  • Använd MongoDB-drivrutiner som stöder automatisk återförsökshantering vid tillfälliga anslutningsfel.

  • Konfigurera återförsök med exponentiell backoff och begränsa antalet återförsök.

  • Utforma om möjligt skrivåtgärder så att de är idempotenta, så att det är säkert att försöka utföra dem igen. Allmän implementeringsvägledning om idempotens finns i Idempotent Consumer-mönstret.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Om du vill använda stöd för tillgänglighetszoner i Azure DocumentDB aktiverar du hög tillgänglighet (HA). När du aktiverar HA i en region som stöder tillgänglighetszoner blir klustret zonredundant eftersom Azure DocumentDB placerar standby-shards i en annan tillgänglighetszon än deras primära shards. Sekundära skärvor tar inte emot klientbegäranden såvida inte deras primära skärva slutar fungera.

Om du inaktiverar HA placerar Azure DocumentDB inte väntelägesshards i en annan tillgänglighetszon, så ett fel i tillgänglighetszonen kan göra klustret otillgängligt.

Diagram över ett zonredundant Azure DocumentDB-kluster med primära och väntelägesshards i separata tillgänglighetszoner.

Krav

Considerations

Vissa Azure DocumentDB-API:er innehåller referenser till distributionslägen i samma zon, men Azure DocumentDB stöder inte ha-distributioner i samma zon. Tjänsten stöder zonredundanta HA-distributioner.

Instansdistribution mellan zoner

Microsoft väljer två tillgänglighetszoner för klustret. I zonredundanta HA-distributioner placerar Azure DocumentDB alla primära shards i en zon och alla standby-shards i den andra zonen.

Cost

När HA är aktiverat etablerar Azure DocumentDB en standby-shard för varje primär shard, vilket ökar beräknings- och lagringskostnaden för klustret. I regioner som stöder tillgänglighetszoner gör HA även klustret zonredundant. I vissa distributionslägen aktiverar Azure DocumentDB HA som standard. Behåll HA aktiverat för produktionsarbetsbelastningar. För utvecklings- och testarbetsbelastningar kan du inaktivera HA för att minska kostnaderna. Prisinformation finns i Azure DocumentDB-priser.

Konfigurera stöd för tillgänglighetszoner

  • Skapa ett nytt zonredundant Azure DocumentDB-kluster: När du skapar ett kluster i en region som stöder tillgänglighetszoner aktiverar du HA för att göra klustret zonredundant. Detaljerade steg finns i Snabbstart: Skapa ett Azure DocumentDB-kluster med hjälp av Azure-portalen.

  • Aktivera zonredundans på ett befintligt Azure DocumentDB-kluster: Du kan aktivera HA på ett befintligt kluster. Det finns ingen databasavbrottstid när hög tillgänglighet är aktiverad eller inaktiverad i ett Azure DocumentDB-kluster. Detaljerade steg finns i Skala ett Azure DocumentDB-kluster.

Beteende när alla zoner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure DocumentDB-kluster för HA i en region som stöder tillgänglighetszoner och alla zoner är i drift.

  • Åtgärd mellan zoner: De primära fragmenten hanterar alla klientbegäranden. Standby-shards i en annan tillgänglighetszon tar inte emot klientbegäranden om inte det primära misslyckas.

  • Datareplikering mellan zoner: Replikeringen mellan primära och standby-skärvor är synkron. Skrivningar sparas på både primära och standby-shards innan tjänsten returnerar ett svar.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure DocumentDB-kluster för HA i en region som stöder tillgänglighetszoner, och det finns ett avbrott i någon av zonerna.

  • Identifiering och svar: Microsoft övervakar shardhälsa och hanterar identifierings- och redundansåtgärder åt dig. Om ett primärt fragment blir otillgängligt på grund av ett zonfel, befordrar Azure DocumentDB automatiskt standby-fragmentet till primärt fragment och återställer sedan redundansen genom att skapa ett nytt standby-fragment.

  • Anmälan: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

  • Aktiva begäranden: Begäranden under flygning som inte bekräftades innan redundansväxlingen kan misslyckas och som måste utföras på nytt av klienten. Om programmet hanterar tillfälliga fel slutförs dessa återförsök vanligtvis automatiskt.

  • Förväntad dataförlust: Azure DocumentDB replikerar data synkront mellan primär- och väntelägesshards, så ingen dataförlust förväntas.

  • Förväntad stilleståndstid: Ingen stilleståndstid förväntas för läsåtgärder. För skrivåtgärder kan ett kort avbrott inträffa medan redundansväxlingen slutförs. Om ditt program försöker igen korrekt vid transienta fel märks detta vanligtvis som en kort fördröjning.

  • Omdistribution: Connection string ändras inte, så klienterna fortsätter att använda samma slutpunkt. Tjänsten omdirigerar automatiskt trafik till befordrade standby-shards och bygger upp nya standby-shards.

Zonåterställning

När tillgänglighetszonen återställs återställer Azure DocumentDB automatiskt normala åtgärder i alla zoner som används av klustret.

Test för zonfel

Azure DocumentDB-plattformen hanterar trafikroutning, redundans och zonåterställning för zonredundanta kluster. Du behöver inte initiera eller bekräfta processer för tillgänglighetszonsfel.

Motståndskraft mot regionomfattande fel

Du distribuerar varje Azure DocumentDB-kluster i en enda Azure region. För att stödja motståndskraft mot regionfel konfigurerar du replikering mellan regioner genom att lägga till ett replikkluster i en annan region.

Replikering mellan regioner

Azure DocumentDB stöder replikering mellan regioner via ett replikkluster. Replikklustret visas som ett separat kluster i resursgruppen. Du kan använda det här replikklustret för katastrofåterställning och skalning av läsning. Azure DocumentDB automatiskt och replikerar asynkront dataändringar från det primära klustret till replikklustret.

Diagram över asynkron replikering från ett primärt Azure DocumentDB-kluster till ett skrivskyddat replikkluster i en annan region.

Om din primära region slutar fungera kan replikklustret befordras till att bli ett läs- och skrivkluster. Den globala anslutningssträngen för läsning och skrivning uppdateras automatiskt så att den pekar på det kluster som har befordrats.

Diagram över en upphöjd Azure DocumentDB-replik som betjänar trafik när den primära regionen misslyckas.

Det här avsnittet sammanfattar tillförlitlighetsöverväganden för replikering mellan regioner. Mer information finns i Hantera replikering mellan regioner och samma region på ditt Azure DocumentDB-kluster och metodtips för replikering mellan regioner och samma region i Azure DocumentDB.

Automatisk övergång mellan regioner

Azure DocumentDB stöder tre uppflyttningslägen:

  • Tvingad befordran: Befordrar omedelbart replikklustret så att det kan acceptera skrivoperationer och omdirigerar inkommande skrivtrafik via den globala anslutningssträngen för läsning och skrivning. Det här läget minimerar driftstopp men kan leda till dataförlust eftersom alla skrivningar som inte har replikerats går förlorade.

  • Tjänsthanterad redundans: Du kan konfigurera klustret så att det använder tjänsthanterad redundansväxling. Microsoft övervakar ditt primära kluster och utlöser automatiskt en framtvingad uppgradering om klustret inte fungerar korrekt.

  • Graciös befordran: Förhindrar dataförlust men kräver viss stilleståndstid medan otillförlitliga skrivningar replikeras. En bra befordran kräver att båda klustren är felfria, så du kan inte utföra det under ett regionavbrott.

Mer information finns i Redundanslägen mellan regioner i Azure DocumentDB.

Krav

  • Regionstöd: Du kan använda replikering mellan regioner i alla Azure regioner som stöder Azure DocumentDB.

  • Beräkningsnivå: Replikering mellan regioner kräver M30-beräkningsnivån eller högre.

Considerations

Cost

Replikering mellan regioner lägger till kostnader för replikklustrets beräknings- och lagringsresurser. Avgifter för dataöverföring mellan regioner tillkommer också. Prisinformation finns i Azure Priser för DocumentDB och bandbreddspriser.

Konfigurera stöd för flera regioner

  • Skapa ett replikkluster: Om du vill aktivera replikering mellan regioner skapar du ett replikkluster från ditt primära kluster. Du kan skapa ett replikkluster när du skapar det primära klustret eller efteråt. Anvisningar finns i Hantera replikering mellan regioner och samma region i ditt Azure DocumentDB-kluster.

  • Konfigurera automatisk redundans: Om du vill att Azure automatiskt ska höja upp repliken vid avbrott i den primära regionen aktiverar du tjänsthanterad redundans. Mer information finns i Aktivera tjänsthanterad redundans.

    Anmärkning

    Microsoft utlöser vanligtvis endast tjänsthanterad redundans vid extrema händelser, till exempel ett avbrott i hela regionen eller ett stort antal berörda kunder. Det kan uppstå en fördröjning innan redundans utlöses. Om du behöver återställa tillgängligheten snabbt rekommenderar vi att du hanterar redundansväxlingen med hjälp av kundinitierad framtvingad befordran.

Beteende när alla regioner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure DocumentDB-kluster för replikering mellan regioner och alla regioner är i drift.

  • Åtgärd mellan regioner: Det primära klustret hanterar all läs- och skrivtrafik. Replikklustret hanterar skrivskyddad trafik, som du kan använda för att skala ut läsarbetsbelastningar eller för att hålla lästrafik lokal till en viss region. Den globala anslutningssträngen för läsning och skrivning pekar alltid på det aktuella skrivbara klustret, så klienterna behöver inte hålla reda på vilken region som är primär.

  • Datareplikering mellan regioner: Replikeringen mellan det primära klustret och replikklustret är asynkron. Skrivningar utförs i det primära klustret och bekräftas till klienten innan de replikeras till replikklustret. Den här metoden förhindrar att nätverksfördröjning mellan regioner påverkar skrivprestanda. Eftersom replikeringen är asynkron är en viss replikeringsfördröjning att vänta mellan primärklustret och replikklustren, och eventuella skrivningar som ännu inte har replikerats kan gå förlorade under en påtvingad redundansväxling.

Beteende under ett regionfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar ett Azure DocumentDB-kluster för replikering mellan regioner och det uppstår ett avbrott i det primära klustrets region.

  • Identifiering och svar: Ansvaret för att identifiera avbrott och svara beror på vilken typ av redundans ditt kluster använder.

    • Om tjänsthanterad redundans är aktiverad identifierar Azure DocumentDB avbrottet och utför automatiskt en framtvingad befordran av replikklustret.
    • Om tjänsthanterad redundans inte är aktiverad ansvarar du för att identifiera avbrott och utlösa en tvingad befordran.

    Mer information finns i Redundanslägen mellan regioner i Azure DocumentDB.

  • Anmälan: Microsoft meddelar dig inte automatiskt när en region är nere. Du kan dock använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella regionfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

  • Aktiva begäranden: Alla aktiva begäranden till den misslyckade primära regionen kan misslyckas. När redundansväxlingen är klar bör program återansluta och försöka igen mot det upphöjda klustret.

  • Förväntad dataförlust: Redundansväxlingar vid regionfel är oplanerade, så skrivningar som inte har replikerats kan gå förlorade eftersom replikeringen är asynkron.

  • Förväntad stilleståndstid: Den totala stilleståndstiden beror på identifieringstid, redundansläge och klientåteranslutningsbeteende.

    För kundinitierad framtvingad befordran inkluderar den totala stilleståndstiden den tid det tar att identifiera avbrott och initiera dina svarsprocesser samt tiden för att slutföra kampanjen.

    När en kampanj har initierats slutförs den vanligtvis inom några minuter.

  • Omfördelning: Den globala anslutningssträngen för läsning och skrivning pekar automatiskt på det uppgraderade klustret efter uppgraderingen. Program som använder klusterspecifika anslutningssträngar kan kräva konfigurationsuppdateringar så att de dirigerar trafik till det felfria klustret.

Regionåterställning

Azure DocumentDB växlar inte automatiskt tillbaka till den ursprungliga regionen när tjänsten har återhämtat sig. Om du vill flytta tillbaka skrivåtgärderna till den ursprungliga regionen genomför du ytterligare en befordran när du har återupprättat din önskade topologi. Använd en kontrollerad uppgradering för att undvika dataförlust vid återgång efter fel. En graciös befordran kräver en liten mängd stilleståndstid, och du kan utföra det vid en tidpunkt som du väljer, till exempel under ett underhållsperiod. Mer information finns i Initiera en kontrollerad befordran.

Test för regionfel

Testa haveriberedskapsprocessen regelbundet genom att främja replikklustret i en kontrollerad miljö.

  • Använd tvingad befordran för att simulera avbrottsbeteende. Det här testet kan resultera i dataförlust, så överväg att köra det här testet i en icke-produktionsmiljö. Mer information finns i Utlösa en tvingad befordran.

  • Använd en graciös befordran för planerade växlingstest när du vill undvika dataförlust. Mer information finns i Initiera en kontrollerad befordran.

Säkerhetskopiering och återställning

För de flesta lösningar bör du inte enbart förlita dig på säkerhetskopior. Använd i stället de andra funktionerna som beskrivs i den här guiden för att stödja dina återhämtningskrav. Säkerhetskopior skyddar dock mot vissa risker som andra metoder inte gör. Mer information finns i Vad är redundans, replikering och säkerhetskopiering?.

Azure DocumentDB skapar automatiskt kontinuerliga säkerhetskopior som möjliggör återställning till en viss tidpunkt (PITR). De här automatiska säkerhetskopiorna hjälper dig att återställa ursprungliga versioner när du har tagit bort eller modifierat data av misstag. Azure DocumentDB tar säkerhetskopior utan att påverka prestanda eller tillgänglighet för databasåtgärder.

Azure DocumentDB lagrar säkerhetskopior separat från källdata. I regioner som stöder tillgänglighetszoner lagrar tjänsten ögonblicksbilder av säkerhetskopior i tre tillgänglighetszoner. Azure DocumentDB hanterar dessa säkerhetskopior och du kan inte exportera dem. Tjänsten behåller säkerhetskopior i 35 dagar för aktiva kluster, 7 dagar för aktiva M10-, M20- och M25-kluster och 7 dagar för borttagna kluster.

Du kan återställa en säkerhetskopia till ett nytt kluster. När du gör det måste du utföra en uppsättning uppgifter efter återställningen.

Mer information finns i Återställa ett kluster i Azure DocumentDB.

Motståndskraft mot serviceunderhåll

Microsoft tillämpar regelbundet tjänstuppdateringar och utför annat underhåll. Den Azure plattformen hanterar dessa aktiviteter automatiskt, vilket säkerställer att underhållet är sömlöst och transparent för dig. Ingen driftstopp förväntas under underhållshändelser om du inte har blivit informerad via Azure Service Health planerat underhåll.

Planerade underhållstillfällen kan fortfarande orsaka korta, övergående fel vid klientåtgärder. Ditt program bör hantera dessa händelser med hjälp av återförsöksvägledningen i Resilience till tillfälliga fel.

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

För Azure DocumentDB gäller tillgänglighets-SERVICEavtal endast när klustret har hög tillgänglighet (HA) aktiverat. Serviceavtal för olika tillgänglighet gäller för följande konfigurationer:

  • HA-aktiverade kluster som sträcker sig över flera Azure regioner med hjälp av replikering mellan regioner.

  • HA-aktiverade kluster i en enda region.

Relaterat innehåll

  • Last updated on