Freigeben über

Zuverlässigkeit in Azure Cosmos DB for MongoDB vCore

  • Artikel

GILT FÜR: MongoDB-vCore

Dieser Artikel enthält ausführliche Informationen zur regionalen Resilienz mit Verfügbarkeitszonen und Unterstützung bei regionsübergreifender Notfallwiederherstellung und Geschäftskontinuität für Azure Cosmos DB for MongoDB vCore.

Eine Übersicht über die Architektur der Zuverlässigkeit in Azure finden Sie unter Zuverlässigkeit in Azure.

Unterstützung für Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

Weitere Informationen zu Verfügbarkeitszonen in Azure finden Sie unter Was sind Verfügbarkeitszonen?.

Um die Verfügbarkeitszonenunterstützung zu erhalten, müssen Sie hohe Verfügbarkeit (HA) aktivieren.

Hochverfügbarkeit vermeidet Datenbankausfälle, indem Standbyreplikate jedes Shards in einem Cluster verwaltet werden. Wenn eine Shard ausfällt, schaltet Azure Cosmos DB for MongoDB vCore eingehende Verbindungen von der fehlerhaften Shard auf das Standbyreplikat um.

Wenn Hochverfügbarkeit in einer Region aktiviert ist, die Verfügbarkeitszonen unterstützt, werden Hochverfügbarkeits-Replikatshards in einer anderen Verfügbarkeitszone als ihre primären Shards bereitgestellt. Hochverfügbarkeitsreplikate empfangen keine Anforderungen von Clients, es sei denn, ihre primäre Shard fällt aus.

Wenn Hochverfügbarkeit deaktiviert ist, verfügt jede Shard über einen eigenen lokal redundanten Speicher (LRS) mit drei synchronen Replikaten, die vom Azure Storage-Dienst verwaltet werden. Wenn ein einzelnes Replikat ausfällt, erkennt der Azure Storage-Dienst den Fehler und erstellt die relevanten Daten transparent neu. Informationen zur LRS-Speicherbeständigkeit finden Sie unter Zusammenfassung der Redundanzoptionen. Beim Ausfall einer Region besteht jedoch das Risiko umfangreicher Ausfallzeiten und möglicher Datenverluste.

Erstellen einer Ressource mit aktivierten Verfügbarkeitszonen

Um Verfügbarkeitszonen zu aktivieren, müssen Sie Hochverfügbarkeit beim Erstellen eines Clusters oder im Abschnitt Skalierung eines vorhandenen Clusters im Azure-Portal angeben.

Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität

Bei der Notfallwiederherstellung (DR) geht es um die Wiederherstellung nach Ereignissen mit schwerwiegenden Auswirkungen, z. B. Naturkatastrophen oder fehlerhaften Bereitstellungen, die zu Downtime und Datenverlust führen. Unabhängig von der Ursache ist das beste Mittel gegen einen Notfall ein gut definierter und getesteter Notfallplan und ein Anwendungsdesign, die Notfallwiederherstellung aktiv unterstützt. Bevor Sie mit der Erstellung Ihres Notfallwiederherstellungsplans beginnen, lesen Sie die Empfehlungen zum Entwerfen einer Notfallwiederherstellungsstrategie.

Bei DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In einem Modell der gemeinsamen Verantwortung stellt Microsoft sicher, dass die grundlegenden Infrastruktur- und Plattformdienste verfügbar sind. Gleichzeitig replizieren viele Azure-Dienste nicht automatisch Daten oder greifen automatisch auf eine ausgefallene Region zurück, um eine regionsübergreifende Replikation in eine andere aktivierte Region durchzuführen. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die auf Azure Platform as a Service (PaaS)-Angeboten laufen, bieten Funktionen und Anleitungen zur Unterstützung von Notfallwiederherstellung und Sie können dienstspezifische Funktionen zur Unterstützung einer schnellen Wiederherstellung nutzen, um Ihren Notfallwiederherstellungsplan zu entwickeln.

Azure Cosmos DB for MongoDB vCore bietet keinen integrierten automatischen Failover und keine Notfallwiederherstellung. Die Planung für hohe Verfügbarkeit ist ein wichtiger Schritt, wenn Ihre Lösung skaliert wird.

Notfallwiederherstellung für eine Region

Planen Sie zum Maximieren der Betriebszeit voraus, um die Geschäftskontinuität aufrechtzuerhalten und die Notfallwiederherstellung mit Azure Cosmos DB for MongoDB vorzubereiten.

Während Azure-Dienste so konzipiert sind, dass die Betriebszeit maximiert wird, können ungeplante Dienstausfälle auftreten. Ein Notfallwiederherstellungsplan stellt sicher, dass Sie über eine Strategie für die Behandlung von regionalen Dienstausfällen verfügen.

Azure Cosmos DB for MongoDB vCore erstellt in regelmäßigen Abständen automatisch Sicherungen Ihrer Daten. Die automatischen Sicherungen erfolgen ohne Beeinträchtigung der Leistung oder Verfügbarkeit des Datenbankbetriebs. Alle Sicherungskopien werden automatisch im Hintergrund ausgeführt und getrennt von den Quelldaten in einem Speicherdienst gespeichert. Diese automatischen Sicherungen sind in Szenarien hilfreich, in denen Sie Ressourcen versehentlich löschen oder ändern und später die ursprünglichen Versionen erfordern.

Automatische Sicherungen werden in verschiedenen Intervallen aufbewahrt, je nachdem, ob der Cluster aktuell aktiv oder kürzlich gelöscht ist.

Beibehaltungsdauer
Aktive Cluster 35 Tage
Gelöschte Cluster 7 Tage

Entwurf für Hochverfügbarkeit

Hohe Verfügbarkeit (HA) sollte für kritische Azure Cosmos DB for MongoDB vCore Cluster aktiviert werden, die Produktionsworkloads ausführen. In einem HA-aktivierten Cluster dient jede Shard als Primärshard, zusammen mit einer Hot-Standby-Shard, welcher in einer anderen Verfügbarkeitszone bereitgestellt wird. Die Replikation zwischen der primären und der sekundären Shard ist standardmäßig synchron. Jede Änderung der Datenbank wird sowohl auf der primären als auch auf der sekundären Shard (Hot-Standby) beibehalten, bevor eine Antwort aus der Datenbank empfangen wird.

Der Dienst verwaltet Integritätsprüfungen und Heartbeats für jede primäre und sekundäre Shards des Clusters. Wenn eine primäre Shard aufgrund eines Zonen- oder regionalen Ausfalls nicht verfügbar wird, wird die sekundäre Shard automatisch höhergestuft, um zur neuen primären Shard zu werden, und folgend wird eine neue sekundäre Shard für die neue primäre Shard erstellt. Wenn eine sekundäre Shard nicht verfügbar ist, erstellt der Dienst automatisch eine neue sekundären Shard mit einer vollständigen Kopie der Daten aus der primären Shard.

Wenn der Dienst ein Failover von der primären zur sekundären Shard auslöst, werden Verbindungen nahtlos unter den Abdeckungen an die neue primäre Shard weitergeleitet.

Die synchrone Replikation zwischen der primären und sekundären Shard garantiert, dass kein Datenverlust auftritt, wenn ein Failover vorhanden ist.

Nächste Schritte