Delen via

Betrouwbaarheid in Azure Cosmos DB voor MongoDB vCore

  • Artikel

VAN TOEPASSING OP: MongoDB vCore

Dit artikel bevat gedetailleerde informatie over regionale tolerantie met beschikbaarheidszones en herstel na noodgevallen tussen regio's en bedrijfscontinuïteit voor Azure Cosmos DB voor MongoDB vCore.

Zie Azure-betrouwbaarheid voor een architectuuroverzicht van betrouwbaarheid in Azure.

Ondersteuning voor beschikbaarheidszone

Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.

Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.

Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor het gebruik van beschikbaarheidszones en regio's voor meer informatie over zone-redundante architectuur en zone-redundante architectuur.

Als u ondersteuning voor beschikbaarheidszones wilt krijgen, moet u Hoge beschikbaarheid (HA) inschakelen.

Hoge beschikbaarheid voorkomt downtime van databases door stand-byreplica's van elke shard in een cluster te onderhouden. Als een shard uitvalt, schakelt Azure Cosmos DB voor MongoDB vCore binnenkomende verbindingen van de mislukte shard naar de stand-byreplica over.

Wanneer hoge beschikbaarheid is ingeschakeld in een regio die beschikbaarheidszones ondersteunt, worden ha-replica-shards ingericht in een andere beschikbaarheidszone dan hun primaire shards. HA-replica's ontvangen geen aanvragen van clients, tenzij hun primaire shard mislukt.

Als hoge beschikbaarheid is uitgeschakeld, heeft elke shard een eigen lokaal redundante opslag (LRS) met drie synchrone replica's die worden onderhouden door de Azure Storage-service. Als er één replicafout optreedt, detecteert de Azure Storage-service de fout en maakt de relevante gegevens transparant opnieuw. Zie Overzicht van redundantieopties voor LRS-opslag. In het geval van een regiofout loopt u echter het risico op uitgebreide downtime en mogelijk gegevensverlies.

Een resource maken waarvoor beschikbaarheidszones zijn ingeschakeld

Als u beschikbaarheidszones wilt inschakelen, moet u hoge beschikbaarheid (HA) inschakelen bij het maken van een cluster of in de sectie Schaal van een bestaand cluster in Azure Portal.

Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's

Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallen voordat u begint na te denken over het maken van uw plan voor herstel na noodgevallen.

Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.

Azure Cosmos DB voor MongoDB vCore biedt geen ingebouwde automatische failover of herstel na noodgevallen. Het plannen van hoge beschikbaarheid is een kritieke stap wanneer uw oplossing wordt geschaald.

Herstel na noodgevallen in geografie met één regio

Als u uw uptime wilt maximaliseren, moet u vooruitgaan om bedrijfscontinuïteit te behouden en voorbereidingen te treffen voor herstel na noodgevallen met Azure Cosmos DB voor MongoDB vCore.

Hoewel Azure-services zijn ontworpen om de uptime te maximaliseren, kunnen er niet-geplande servicestoringen optreden. Een plan voor herstel na noodgevallen zorgt ervoor dat u een strategie hebt voor het afhandelen van regionale servicestoringen.

Azure Cosmos DB voor MongoDB vCore maakt automatisch back-ups van uw gegevens met regelmatige tussenpozen. De automatische back-ups worden gemaakt zonder dat dit van invloed is op de prestaties of beschikbaarheid van de databasebewerkingen. Alle back-ups worden automatisch op de achtergrond uitgevoerd en afzonderlijk van de brongegevens in een opslagservice opgeslagen. Deze automatische back-ups zijn handig in scenario's wanneer u per ongeluk resources verwijdert of wijzigt en later de oorspronkelijke versies vereist.

Automatische back-ups worden in verschillende intervallen bewaard op basis van of het cluster momenteel actief of onlangs is verwijderd.

Bewaarperiode
Actieve clusters 35 dagen
Verwijderde clusters 7 dagen

Ontwerpen voor hoge beschikbaarheid

Hoge beschikbaarheid (HA) moet zijn ingeschakeld voor kritieke Azure Cosmos DB voor MongoDB vCore-clusters waarop productieworkloads worden uitgevoerd. In een cluster met hoge beschikbaarheid fungeert elke shard als een primaire samen met een hot-stand-by-shard die is ingericht in een andere beschikbaarheidszone. Replicatie tussen de primaire en de secundaire shard is standaard synchroon. Wijzigingen in de database blijven behouden op zowel de primaire als de secundaire (hot-stand-by) shards voordat een reactie van de database wordt ontvangen.

De service onderhoudt statuscontroles en heartbeats voor elke primaire en secundaire shard van het cluster. Als een primaire shard niet meer beschikbaar is vanwege een zone- of regionale storing, wordt de secundaire shard automatisch gepromoveerd tot de nieuwe primaire en wordt een volgende secundaire shard gebouwd voor de nieuwe primaire. Als een secundaire shard niet meer beschikbaar is, maakt de service automatisch een nieuwe secundaire shard met een volledige kopie van gegevens van de primaire.

Als de service een failover van de primaire naar de secundaire shard activeert, worden verbindingen naadloos gerouteerd naar de nieuwe primaire shard.

Synchrone replicatie tussen de primaire en secundaire shards garandeert geen gegevensverlies als er een failover is.

Volgende stappen