Tillgänglighet (tillförlitlighet) och haveriberedskap (DR) i Azure Cosmos DB för MongoDB vCore: Bakom kulisserna

Den här artikeln går in på interna funktioner för hög tillgänglighet (HA) och haveriberedskap mellan regioner (DR) för Azure Cosmos DB för MongoDB vCore och beskriver designen och kapabiliteterna hos dessa funktioner. Det ger insikter för effektiv strategiplanering mellan regioner och regioner för att säkerställa tillförlitlighet och affärskontinuitet.

Azure Cosmos DB för MongoDB vCore klusteranatomi

Ett Azure Cosmos DB for MongoDB vCore-kluster består av en eller flera fysiska shards (noder). Varje fysisk shard innehåller en dedikerad beräkningsnod och premium SSD-fjärrlagring. Beräknings - och lagringsresurserna för en fysisk shard är exklusiva för en enskild databas och delas inte mellan kluster eller databaser.

I kluster med flera shards har varje shard en identisk beräknings- och lagringskonfiguration. Oavsett antalet shards finns alla klusterresurser i samma Azure-region.

Azure Cosmos DB for MongoDB vCore använder lokalt redundant lagring (LRS), vilket säkerställer att alla data replikeras synkront tre gånger på klustrets fysiska plats. Azure Storage hanterar dessa repliker transparent, verifierar dataintegriteten med hjälp av cykliska redundanskontroller (CRC) och reparerar eventuella identifierade skador med hjälp av redundanta data. Dessutom tillämpas kontrollsummor på nätverkstrafik för att förhindra att data skadas under lagring och hämtning.

Bild 1. Azure Cosmos DB for MongoDB vCore-klusterkomponenter.

Oavsett om ditt program ansluter till ett enda shard- eller multishardkluster använder det en enda anslutningssträng och en slutpunkt. Den här abstraktionen förenklar distribuerade databasåtgärder, vilket gör det lika enkelt att ansluta till en installation med flera fragment som till en fristående MongoDB-databas.

Hög tillgänglighet i regionen (HA)

För produktionsarbetsbelastningar rekommenderar vi starkt att du aktiverar hög tillgänglighet i regionen (HA) för att uppfylla moderna tillförlitlighetsstandarder. Ha kan inaktiveras för utveckling eller experimentella kluster för att minska kostnaderna, men det är viktigt för att upprätthålla databastillgängligheten i produktion.

HA kan aktiveras eller inaktiveras vid klusterinställning eller när som helst efter att klustret har skapats. Den är tillgänglig i alla Azure-regioner som stöder Azure Cosmos DB för MongoDB vCore, oavsett specifika regionala funktioner.

När HA är aktiverat paras varje primär fysisk shard i klustret ihop med en standby-shard. Standby-fragmentet speglar beräknings- och lagringskonfigurationen för den primära motsvarigheten. Detta resulterar i sex datarepliker per fragment – tre på det primära fragmentet och tre på standby. I regioner med tillgänglighetszoner (AZs) distribueras primära och reservdelar i separata zoner.

Data replikeras synkront mellan varje primär- och väntelägesshard. Skrivningar bekräftas först efter att de har checkats in till båda shards, vilket säkerställer stark konsekvens i HA-klustret. Med andra ord är en fysisk shard i vänteläge en alltid uppdaterad fullständig replik av sin primära fysiska shard som ger stark konsistens i klustret med hög tillgänglighet.

Bild 2. Azure Cosmos DB for MongoDB vCore-kluster med och utan hög tillgänglighet i regionen (HA) aktiverat.

I händelse av ett primärt shardfel utför tjänsten automatiskt en redundansväxling till dess standby-shard. Vid failover omdirigeras alla läs- och skrivbegäranden till standby-shard, som blir den nya primärnoden. Skrivåtgärder som pågår under redundansväxlingen omförs i tjänsten för att garantera fortsatt drift. En ersättningsshard skapas sedan för att återupprätta synkron replikering och blir det nya vänteläget.

Replikering mellan regioner: Regional katastrofåterställning (DR)

Även om det är ovanligt kan regionala avbrott störa åtkomsten till databasen. Replikering mellan regioner ger en robust strategi för haveriberedskap (DR) som säkerställer åtkomst till dina data även vid storskaliga störningar.

Med replikering mellan regioner kan du skapa ett replikkluster i en annan Azure-region. Varje shard i replikklustret replikerar asynkront data från sin motsvarighet i det primära klustret. Den här replikeringsmodellen säkerställer slutlig konsekvens samtidigt som prestandapåverkan på det primära klustret minimeras.

Asynkron replikering undviker behovet av att varje skrivåtgärd omedelbart levereras till och bekräftas av repliker innan en "skriv fullständig" bekräftelse skickas tillbaka till programmet. Det innebär dock att vissa skrivningar som slutförts i det primära klustret kanske ännu inte replikeras till replikklustret, vilket resulterar i replikeringsfördröjning. Replikeringsfördröjningens omfattning beror på intensiteten i skrivåtgärderna på det primära klustret och den totala belastningen på både de primära klustren och replikkluster.

I den här konfigurationen:

• Det primära klustret i region A hanterar alla läsningar och skrivningar.
• Replikklustret i region B stöder enbart läsåtkomst, vilket möjliggör högpresterande läsåtgärder närmare program eller användare i den regionen.

Applikationer kan köra OLTP-frågor på det primära klustret i region A och intensiva läsoperationer som OLAP/rapporteringsfrågor kan riktas mot replikklustret i region B.

Program kan använda en dynamisk global anslutningssträng, som alltid pekar på klustret som är öppet för skrivningar. Vid ett regionalt avbrott kan replikaklustret i region B uppgraderas för att acceptera skrivoperationer. Den globala anslutningssträngen uppdateras automatiskt för att peka på det promoverade klustret, vilket säkerställer att skrivåtgärder är oavbrutna.

Bild 3. Regional katastrofåterställning (DR) med ett Azure Cosmos DB för MongoDB vCore-kluster med aktiverad replikering mellan regioner. Klustret i region B befordras till det nya läs-skriv-klustret. Klustret i region A blir ett replikkluster.

Sammanfattning av tillgänglighet i regionen och dr-funktioner mellan regioner

I följande tabell sammanfattas de viktigaste övervägandena för att aktivera och hantera en strategi för hög tillgänglighet och haveriberedskap mellan regioner i regionen.

† När du använder den globala anslutningssträngen.

Relaterat innehåll

• Läs mer om hög tillgänglighet i regionen i Azure Cosmos DB for MongoDB vCore
• Lär dig mer om replikering mellan regioner och haveriberedskap mellan regioner
• Lär dig mer om tillförlitlighet i Azure Cosmos DB for MongoDB vCore