Dela via

Tillförlitlighet i Azure Cosmos DB för MongoDB vCore

  • Artikel

GÄLLER FÖR: MongoDB vCore

Den här artikeln innehåller detaljerad information om regional återhämtning med tillgänglighetszoner och haveriberedskap mellan regioner och affärskontinuitet för Azure Cosmos DB for MongoDB vCore.

En arkitekturöversikt över tillförlitlighet i Azure finns i Azures tillförlitlighet.

Stöd för tillgänglighetszon

Azure-tillgänglighetszoner är minst tre fysiskt separata grupper av datacenter i varje Azure-region. Datacenter i varje zon är utrustade med oberoende infrastruktur för ström, kylning och nätverk. Om det uppstår ett fel i den lokala zonen är tillgänglighetszoner utformade så att regionala tjänster, kapacitet och hög tillgänglighet stöds av de återstående två zonerna om den ena zonen påverkas.

Fel kan vara allt från programvaru- och maskinvarufel till händelser som jordbävningar, översvämningar och bränder. Tolerans mot fel uppnås med redundans och logisk isolering av Azure-tjänster. Mer detaljerad information om tillgänglighetszoner i Azure finns i Regioner och tillgänglighetszoner.

Azure-tillgänglighetszoner-aktiverade tjänster är utformade för att ge rätt nivå av tillförlitlighet och flexibilitet. De kan konfigureras på två sätt. De kan vara antingen zonredundanta, med automatisk replikering mellan zoner eller zoninstanser, med instanser fästa på en specifik zon. Du kan också kombinera dessa metoder. Mer information om zon- och zonredundant arkitektur finns i Rekommendationer för användning av tillgänglighetszoner och regioner.

För att få stöd för tillgänglighetszoner måste du aktivera hög tillgänglighet (HA).

HA undviker databasavbrott genom att underhålla väntelägesrepliker av varje shard i ett kluster. Om en shard slutar fungera växlar Azure Cosmos DB for MongoDB vCore inkommande anslutningar från den misslyckade shard till dess väntelägesreplik.

När HA är aktiverat i en region som stöder tillgänglighetszoner etableras HA-replikskärvor i en annan tillgänglighetszon än sina primära shards. HA-repliker tar inte emot begäranden från klienter om inte deras primära fragment misslyckas.

Om HA är inaktiverat har varje shard sin egen lokalt redundanta lagring (LRS) med tre synkrona repliker som underhålls av Azure Storage-tjänsten. Om det uppstår ett enskilt replikfel identifierar Azure Storage-tjänsten felet och återskapar transparent relevanta data. Information om hållbarhet för LRS-lagring finns i Sammanfattning av redundansalternativ. I händelse av ett regionfel riskerar du dock att drabbas av omfattande driftstopp och eventuell dataförlust.

Skapa en resurs med tillgänglighetszoner aktiverade

Om du vill aktivera tillgänglighetszoner måste du aktivera Hög tillgänglighet (HA) när du skapar ett kluster eller i avsnittet Skala i ett befintligt kluster i Azure-portalen.

Haveriberedskap och affärskontinuitet mellan regioner

Haveriberedskap handlar om att återställa från händelser med hög påverkan, till exempel naturkatastrofer eller misslyckade distributioner som resulterar i driftstopp och dataförlust. Oavsett orsak är den bästa lösningen för en katastrof en väldefinierad och testad DR-plan och en programdesign som aktivt stöder DR. Innan du börjar fundera på att skapa en haveriberedskapsplan kan du läsa Rekommendationer för att utforma en strategi för haveriberedskap.

När det gäller dr använder Microsoft modellen för delat ansvar. I en modell med delat ansvar ser Microsoft till att baslinjeinfrastrukturen och plattformstjänsterna är tillgängliga. Samtidigt replikerar många Azure-tjänster inte automatiskt data eller återgår från en misslyckad region för att korsreparera till en annan aktiverad region. För dessa tjänster ansvarar du för att konfigurera en haveriberedskapsplan som fungerar för din arbetsbelastning. De flesta tjänster som körs på PaaS-erbjudanden (Plattform som en tjänst) i Azure ger funktioner och vägledning för att stödja DR och du kan använda tjänstspecifika funktioner för att stödja snabb återställning för att utveckla din DR-plan.

Azure Cosmos DB for MongoDB vCore tillhandahåller inte inbyggd automatisk redundans eller haveriberedskap. Att planera för hög tillgänglighet är ett viktigt steg när din lösning skalar.

Haveriberedskap i geografi för en region

För att maximera drifttiden planerar du framåt för att upprätthålla affärskontinuitet och förbereda för haveriberedskap med Azure Cosmos DB för MongoDB vCore.

Även om Azure-tjänster är utformade för att maximera drifttiden kan oplanerade tjänstavbrott inträffa. En haveriberedskapsplan säkerställer att du har en strategi för hantering av regionala tjänststopp.

Azure Cosmos DB for MongoDB vCore tar automatiskt säkerhetskopior av dina data med jämna mellanrum. Automatiska säkerhetskopieringar görs utan att det påverkar databasernas prestanda eller tillgänglighet. Alla säkerhetskopior utförs automatiskt i bakgrunden och lagras separat från källdata i en lagringstjänst. Dessa automatiska säkerhetskopior är användbara i scenarier när du oavsiktligt tar bort eller ändrar resurser och senare kräver de ursprungliga versionerna.

Automatiska säkerhetskopior behålls i olika intervall baserat på om klustret för närvarande är aktivt eller nyligen borttaget.

Kvarhållningsperiod
Aktiva kluster 35 dagar
Borttagna kluster 7 dagar

Utforma för hög tillgänglighet

Hög tillgänglighet (HA) bör aktiveras för kritiska Azure Cosmos DB för MongoDB vCore-kluster som kör produktionsarbetsbelastningar. I ett HA-aktiverat kluster fungerar varje shard som en primär tillsammans med en shard med frekvent vänteläge som etablerats i en annan tillgänglighetszon. Replikeringen mellan den primära och den sekundära fragmentet är synkron som standard. Alla ändringar av databasen sparas på både den primära och den sekundära (frekvent vänteläge) shards innan ett svar från databasen tas emot.

Tjänsten underhåller hälsokontroller och pulsslag till varje primär och sekundär shard i klustret. Om en primär shard blir otillgänglig på grund av ett zon- eller regionalt avbrott, befordras den sekundära shard automatiskt till att bli den nya primära och en efterföljande sekundär shard skapas för den nya primära. Om en sekundär shard dessutom blir otillgänglig skapar tjänsten automatiskt en ny sekundär shard med en fullständig kopia av data från den primära.

Om tjänsten utlöser en redundansväxling från den primära till den sekundära fragmentet dirigeras anslutningar sömlöst under täcket till den nya primära fragmentet.

Synkron replikering mellan de primära och sekundära shards garanterar ingen dataförlust om det sker en redundansväxling.

Nästa steg