Realisieren von Hochverfügbarkeit mit Azure Cosmos DB

  • Artikel

GILT FÜR: NoSQL MongoDB Cassandra Gremlin Tabelle

Zum Erstellen einer hochverfügbaren Lösung müssen Sie die Zuverlässigkeitsmerkmale aller Komponenten auswerten. Azure Cosmos DB bietet Features und Konfigurationsoptionen, mit denen Sie Hochverfügbarkeit für Ihre Lösung erzielen können.

In diesem Artikel werden die folgenden Begriffe verwendet:

  • Recovery Time Objective (RTO): Die Zeit zwischen dem Beginn eines Ausfalls, der sich auf Azure Cosmos DB auswirkt, und der Wiederherstellung bis zur vollständigen Verfügbarkeit.
  • Recovery Point Objective (RPO): Die Zeit zwischen dem letzten Schreibvorgang, der ordnungsgemäß wiederhergestellt wurde, und dem Zeitpunkt des Beginns des Ausfalls, der sich auf Azure Cosmos DB auswirkt.

Hinweis

Erwartete und maximale RPOs und RTOs hängen von der Art des Ausfalls ab, Azure Cosmos DB auftritt. Beispielsweise ist bei einem Ausfall eines einzelnen Knotens ein anderes RTO und RPO als bei einem Ausfall einer gesamten Region zu erwarten.

In diesem Artikel werden die Ereignisse beschrieben, die sich auf die Azure Cosmos DB-Verfügbarkeit und die entsprechenden Azure Cosmos DB-Konfigurationsoptionen auswirken können.

Wartung der Replikate

Azure Cosmos DB ist ein mehrinstanzenfähiger Dienst, der alle Details der einzelnen Computeknoten transparent verwaltet. Die Benutzer müssen sich nicht um Patches oder geplante Wartungen kümmern. Azure Cosmos DB garantiert SLAs für Verfügbarkeit und P99-Latenz durch alle automatischen Wartungsarbeiten, die vom System durchgeführt werden.

Replikatausfälle

Replikatausfälle sind Ausfälle einzelner Knoten in einem Azure Cosmos DB-Cluster, der in einer Azure-Region bereitgestellt ist.

Azure Cosmos DB federt Replikatausfälle automatisch ab, indem es die Bereitstellung von mindestens drei Replikaten Ihrer Daten in jeder Azure-Region für Ihr Konto innerhalb eines Quorums von vier Replikaten garantiert. Diese Garantie führt zu einem RTO von 0 und einem RPO von 0 für einzelne Knotenausfälle, ohne dass Anwendungsänderungen oder -konfigurationen erforderlich sind.

In vielen Azure-Regionen lässt sich Ihr Azure Cosmos DB-Cluster auf Verfügbarkeitszonen verteilen. Verfügbarkeitszonen können SLAs erhöhen, da sie physisch getrennt sind und eine unterschiedliche Stromquelle, ein unterschiedliches Netzwerk und eine unterschiedliche Kühlung bieten. Wenn Sie ein Azure Cosmos DB-Konto mithilfe von Verfügbarkeitszonen bereitstellen, bietet Azure Cosmos DB selbst bei einem Zonenausfall ein RTO von 0 und ein RPO von 0.

Wenn Sie die Bereitstellung in einer einzigen Azure-Region vornehmen, ist Azure Cosmos DB ohne zusätzliche Benutzereingaben resilient gegenüber Knotenausfällen. Dank der Redundanz über Verfügbarkeitszonen hinweg ist Azure Cosmos DB resilient gegenüber Zonenausfällen, allerdings entstehen dadurch höhere Kosten.

Sie können die Zonenredundanz nur konfigurieren, wenn Sie einem Azure Cosmos DB-Konto eine neue Region hinzufügen. Für vorhandene Regionen können Sie Zonenredundanz aktivieren, indem Sie die Region entfernen und dann wieder mit aktivierter Zonenredundanz hinzufügen. Für ein Konto mit nur einer Region müssen Sie bei diesem Ansatz eine Region hinzufügen, in die vorübergehend ein Failover erfolgen kann. Anschließend müssen Sie die gewünschte Region entfernen und mit aktivierter Zonenredundanz wieder hinzufügen.

Standardmäßig werden für ein Azure Cosmos DB-Konto nicht mehrere Verfügbarkeitszonen verwendet. Sie können die Bereitstellung über mehrere Verfügbarkeitszonen hinweg auf folgende Weise aktivieren:

Wenn Ihr Azure Cosmos DB-Konto über N Azure-Regionen verteilt ist, gibt es mindestens N x 4 Kopien von allen Ihren Daten. Weitere Informationen dazu, wie Azure Cosmos DB Daten in den einzelnen Regionen repliziert, finden Sie unter Globale Datenverteilung mit Azure Cosmos DB. Ein Azure Cosmos DB-Konto in mehr als zwei Regionen verbessert die Verfügbarkeit Ihrer Anwendung und sorgt für eine geringe Latenz zwischen den zugeordneten Regionen.

Ausfälle in der Region

Ausfälle in der Region sind Ausfälle, die sich über alle Verfügbarkeitszonen hinweg auf Azure Cosmos DB-Knoten in einer Azure-Region auswirken. In den seltenen Fällen von Ausfällen in der Region können Sie Azure Cosmos DB so konfigurieren, dass verschiedene Ergebnisse von Dauerhaftigkeit und Verfügbarkeit unterstützt werden.

Beständigkeit

Wenn ein Azure Cosmos DB-Konto in einer einzigen Region bereitgestellt wird, kommt es in der Regel zu keinem Datenverlust. Der Datenzugriff wird nach der Wiederherstellung der Azure Cosmos DB-Dienste in der betroffenen Region wiederhergestellt. Zu einem Datenverlust kann es nur bei einem nicht behebbaren Notfall in der Azure Cosmos DB-Region kommen.

Um vor vollständigen Datenverlusten geschützt zu sein, die sich aus Unglücken in einer Region ergeben können, stellt Azure Cosmos DB zwei Sicherungsmodi bereit:

  • Fortlaufende Sicherungen sichern jede Region alle 100 Sekunden. Sie ermöglichen es Ihnen, Ihre Daten für einen beliebigen Zeitpunkt mit einer Granularität von 1 Sekunde wiederherzustellen. In jeder Region ist die Sicherung von den in dieser Region zu sichernde Daten abhängig.
  • Regelmäßige Sicherungen sichern vollständig alle Partitionen von allen Containern unter Ihrem Konto, ohne Synchronisierung über Partitionen hinweg. Das Mindestintervall für Sicherungen beträgt eine Stunde.

Wenn ein Azure Cosmos DB-Konto in mehreren Regionen bereitgestellt wird, hängt die Dauerhaftigkeit der Daten von der Konsistenzebene ab, die Sie für das Konto konfigurieren. In der folgenden Tabelle ist für alle Konsistenzstufen die RPO eines Azure Cosmos DB-Kontos aufgeführt, das in mindestens zwei Regionen bereitgestellt wird.

Konsistenzebene RPO für Regionsausfall
Sitzung, konsistentes Präfix, letztlich Weniger als 15 Minuten
Bounded staleness K und T
STARK (Strong) 0

K = Anzahl der Versionen (d. h. Updates) eines Elements.

T = Zeitintervall seit dem letzten Update.

Bei Konten mit mehreren Regionen ist der Mindestwert von K und T 100.000 Schreibvorgänge oder 300 Sekunden. Dieser Wert definiert die minimale RPO für Daten bei Verwendung von begrenzter Veraltung.

Weitere Informationen zu den Unterschieden zwischen den Konsistenzebenen finden Sie unter Konsistenzebenen in Azure Cosmos DB.

Verfügbarkeit

Wenn Ihre Lösung auch bei Regionsusfällen kontinuierlich verfügbar sein muss, können Sie Azure Cosmos DB so konfigurieren, dass Ihre Daten über mehrere Regionen hinweg repliziert werden und bei Bedarf ein transparentes Failover auf verfügbare Regionen erfolgt.

Konten mit einer Region sind nach einem regionalen Ausfall möglicherweise nicht mehr verfügbar. Um jederzeit eine hohe Verfügbarkeit sicherzustellen, empfehlen wir, Ihr Azure Cosmos DB-Konto mit einer einzigen Schreibregion und mindestens einer zweiten Region (Leseregion) einzurichten und dienstseitig verwaltetes Failover zu aktivieren.

Mithilfe eines dienstseitig verwalteten Failovers kann Azure Cosmos DB die Schreibregion eines Kontos mit mehreren Regionen auslagern, um die Verfügbarkeit auf Kosten eines Datenverlusts zu gewährleisten, wie oben im Abschnitt Dauerhaftigkeit beschrieben. Regionale Failover werden im Azure Cosmos DB-Client erkannt und ausgeführt. Sie erfordern keine Änderungen aus der Anwendung. Eine Anleitung zur Aktivierung mehrerer Leseregionen und dienstseitig verwaltetem Failover finden Sie unter Verwaltung eines Azure Cosmos DB-Kontos mithilfe des Azure-Portals.

Wichtig

Wenn Sie die Schreibkonfiguration mit einer einzelnen Region mit mehreren Leseregionen ausgewählt haben, wird dringend empfohlen, die Azure Cosmos DB-Konten, die für Produktionsworkloads verwendet werden, zu konfigurieren, um das vom Dienst verwaltete Failover zu ermöglichen. Diese Konfiguration ermöglicht Azure Cosmos DB ein Failover der Kontodatenbanken in verfügbare Regionen. Ohne diese Konfiguration verliert das Konto für die gesamte Dauer des Ausfalls der Schreibregion die Schreibverfügbarkeit. Manuelles Failover schlägt aufgrund fehlender Regionskonnektivität fehl.

Warnung

Auch bei aktiviertem dienstseitig verwaltetem Failover kann ein teilweiser Ausfall manuell für das Azure Cosmos DB-Dienstteam erforderlich sein. In diesen Szenarien kann es bis zu 1 Stunde (oder mehr) dauern, bis ein Failover wirksam wird. Für eine bessere Schreibverfügbarkeit bei teilweisen Ausfallen empfehlen wir zusätzlich zum vom Dienst verwalteten Failover die Aktivierung von Verfügbarkeitszonen.

Mehrere Schreibregionen

Sie können Azure Cosmos DB so konfigurieren, dass Schreibvorgänge in mehreren Regionen akzeptiert werden. Diese Konfiguration ist nützlich, um die Schreiblatenz in geografisch verteilten Anwendungen zu verringern.

Wenn Sie ein Azure Cosmos DB-Konto für mehrere Schreibregionen konfigurieren, wird keine starke Konsistenz unterstützt, und es können Schreibkonflikte auftreten. Weitere Informationen zum Beheben dieser Konflikte finden Sie unter Konflikttypen und Lösungsrichtlinien bei Verwendung mehrerer Schreibregionen.

Wichtig

Das häufige Aktualisieren derselben Dokument-ID (oder das häufige erneute Erstellen derselben Dokument-ID nach der TTL oder dem Löschen) wirkt sich aufgrund einer erhöhten Anzahl von im System generierten Konflikten auf die Replikationsleistung aus.  

Region zur Konfliktlösung

Wenn ein Azure Cosmos DB-Konto für Schreibvorgänge in mehreren Regionen konfiguriert ist, fungiert eine der Regionen bei Schreibkonflikten als Vermittler.

Bewährte Methoden für Schreibvorgänge in mehrere Regionen

Hier finden Sie einige bewährte Methoden, die Sie beim Schreiben in mehrere Regionen berücksichtigen sollten.

Halten Sie lokalen Datenverkehr lokal

Wenn Sie Schreibvorgänge in mehrere Regionen verwenden, sollte die Anwendung Lese- und Schreibdatenverkehr, der aus der lokalen Region stammt, ausschließlich in die lokale Cosmos DB-Region ausgeben. Vermeiden Sie regionsübergreifende Aufrufe, um optimale Leistung zu erzielen.

Es ist wichtig, dass die Anwendung Konflikte minimiert, indem die folgenden Antimuster vermieden werden:

  • Senden desselben Schreibvorgangs an alle Regionen, um die Wahrscheinlichkeit einer kurzen Antwortzeit zu erhöhen

  • Zufälliges Ermitteln der Zielregion für einen Lese- oder Schreibvorgang pro Anforderung

  • Verwenden einer Roundrobin-Richtlinie, um die Zielregion für einen Lese- oder Schreibvorgang pro Anforderung zu ermitteln

Vermeiden der Abhängigkeit von Replikationsverzögerungen

Sie können Schreibkonten mit mehreren Regionen nicht für eine starke Konsistenz konfigurieren. Die Region, in die geschrieben wird, reagiert, unmittelbar nachdem Azure Cosmos DB die Daten lokal repliziert, während die Daten global asynchron repliziert werden.

Obwohl selten, kann eine Replikationsverzögerung auf einer oder wenigen Partitionen auftreten, wenn Sie Daten georeplizieren. Die Replikationsverzögerung kann aufgrund seltener Störungen im Netzwerkdatenverkehr oder aufgrund unüblich hoher Konfliktlauflösungsraten auftreten.

Beispielsweise führt eine Architektur, in der die Anwendung in die Region A schreibt, aber aus der Region B liest, eine Abhängigkeit von der Replikationsverzögerung zwischen den beiden Regionen ein. Wenn die Anwendung jedoch Lese- und Schreibvorgänge in derselben Region durchführt, bleibt die Leistung auch bei Vorliegen einer Replikationsverzögerung konstant.

Bewerten der Sitzungskonsistenz für Schreibvorgänge

In der Sitzungskonsistenz verwenden Sie das Sitzungstoken sowohl für Lese- als auch für Schreibvorgänge.

Bei Lesevorgängen sendet Azure Cosmos DB das zwischengespeicherte Sitzungstoken an den Server mit einer Garantie, dass Daten empfangen werden, die dem angegebenen (oder einem aktuelleren) Sitzungstoken entsprechen.

Bei Schreibvorgängen sendet Azure Cosmos DB das Sitzungstoken an die Datenbank mit einer Garantie, dass die Daten nur dann beibehalten werden, wenn der Server das bereitgestellte Sitzungstoken abgeholt hat. In Schreibkonten mit einer einzelnen Region ist immer garantiert, dass die Schreibregion das Sitzungstoken abgeholt hat. In Schreibkonten mit mehreren Regionen hat jedoch die Region, in die Sie schreiben, möglicherweise Schreibvorgänge, die für eine anderen Region ausgestellt wurden, nicht abgeholt. Wenn der Client mit einem Sitzungstoken aus Region B in Region A schreibt, kann die Region A die Daten erst beibehalten, wenn Änderungen in Region B abgeholt wurden.

Es ist am besten, Sitzungstoken nur für Lesevorgänge und nicht für Schreibvorgänge zu verwenden, wenn Sie Sitzungstoken zwischen Clientinstanzen übergeben.

Minimieren von schnellen Aktualisierungen für dasselbe Dokument

Die Aktualisierungen des Servers, um Konflikten zu beheben oder deren Fehlen zu bestätigen, können mit Schreibvorgängen kollidieren, die von der Anwendung ausgelöst werden, wenn dasselbe Dokument wiederholt aktualisiert wird. Wiederholte Aktualisierungen in schneller Folge auf dasselbe Dokument führen zu höheren Wartezeiten während der Konfliktauflösung.

Obwohl gelegentliche Bursts bei wiederholten Aktualisierungen für dasselbe Dokuments unvermeidlich sind, sollten Sie vielleicht in Betracht ziehen, eine Architektur zu erkunden, in der stattdessen neue Dokumente erstellt werden, wenn der stationäre Datenverkehr schnelle Aktualisierungen für dasselbe Dokument über einen längeren Zeitraum sieht.

Das geschieht beim Ausfall einer Region

Clients mit Konten mit einer einzigen Region müssen mit einem Verlust der Lese- und Schreibverfügbarkeit rechnen, bis der Dienst wiederhergestellt ist.

Konten mit mehreren Regionen weisen je nach den folgenden Konfigurationen und Ausfalltypen unterschiedliche Verhaltensweisen auf.

Konfiguration Outage Auswirkungen auf die Verfügbarkeit Auswirkungen auf die Verfügbarkeit Aktion
Eine Schreibregion Lesen eines Ausfalls von Regionen Alle Clients leiten Lesevorgänge automatisch an andere Regionen weiter. Es tritt kein Verlust der Lese- oder Schreibverfügbarkeit für alle Konfigurationen auf. Die Ausnahme ist eine Konfiguration von zwei Regionen mit starker Konsistenz, die bis zur Wiederherstellung des Diensts die Schreibverfügbarkeit verliert. Oder wenn Sie dienstseitig verwaltetes Failover aktivieren, kennzeichnet der Dienst die Region als fehlerhaft, und es erfolgt ein Failover. Kein Datenverlust. Stellen Sie sicher, dass während eines Ausfalls in den verbleibenden Regionen genügend Anforderungseinheiten (RUs) zur Unterstützung des Lesedatenverkehrs bereitgestellt sind.

Wenn der Ausfall beendet ist, passen Sie die bereitgestellten RUs entsprechend neu an.
Eine Schreibregion Schreiben eines Ausfalls von Regionen Die Clients leiten Lesevorgänge an andere Regionen weiter.

Ohne dienstseitig verwaltetes Failover verlieren Clients die Schreibverfügbarkeit. Die Wiederherstellung der Schreibverfügbarkeit erfolgt nach einem Ausfall automatisch.

Bei dienstseitig verwaltetem Failover kommt es auf den Clients zu einem Verlust der Schreibverfügbarkeit, bis der Dienst ein Failover auf eine von Ihnen ausgewählte neue Schreibregion durchführen konnte.		 Wenn Sie die starke Konsistenzebene nicht auswählen, repliziert der Dienst einige Daten möglicherweise nicht in die verbleibenden aktiven Regionen. Diese Replikation hängt von der von Ihnen ausgewählten Konsistenzebene ab. Wenn in der betroffenen Region dauerhafte Datenverluste auftreten, könnten Sie nicht replizierte Daten verlieren. Stellen Sie sicher, dass während eines Ausfalls in den verbleibenden Regionen genügend RUs zur Unterstützung des Lesedatenverkehrs bereitgestellt sind.

Lösen Sie während des Ausfalls kein manuelles Failover aus, da es nicht erfolgreich sein kann.

Wenn der Ausfall beendet ist, passen Sie die bereitgestellten RUs entsprechend neu an. Konten, die die API für NoSQL verwenden, stellen möglicherweise auch die nicht replizierten Daten in der fehlerhaften Region aus Ihrem Konfliktfeed wieder her.
Mehrere Schreibregionen Regionaler Ausfall Es besteht die Möglichkeit eines vorübergehenden Verlusts der Schreibverfügbarkeit, was analog zu einer einzelnen Schreibregion mit dienstseitig verwaltetem Failover ist. Das Failover der Konfliktauflösungsregion kann auch zu einem Verlust der Schreibverfügbarkeit führen, wenn zum Zeitpunkt des Ausfalls eine hohe Anzahl von Schreibkonflikten auftritt. Kürzlich aktualisierte Daten in der fehlerhaften Region sind in den verbleibenden aktiven Regionen möglicherweise nicht verfügbar, abhängig von der ausgewählten Konsistenzebene. Wenn in der betroffenen Region dauerhafte Datenverluste auftreten, können Sie nicht replizierte Daten verlieren. Stellen Sie während eines Ausfalls sicher, dass in den verbleibenden Regionen genügend bereitgestellte RUs vorhanden sind, um mehr Datenverkehr zu bewältigen.

Wenn der Ausfall beendet ist, können Sie die bereitgestellten RUs entsprechend anpassen. Wenn möglich stellt Azure Cosmos DB nicht replizierte Daten in der fehlerhaften Region automatisch wieder her. Diese automatische Wiederherstellung nutzt die Konfliktlösungsmethode, die Sie für Konten konfigurieren, die die API für NoSQL verwenden. Für Konten, die andere APIs verwenden, nutzt diese automatische Wiederherstellung Last Write Wins (der letzte Schreibvorgang gewinnt).

Weitere Informationen zu Lese-/Regionalausfällen

  • Die betroffene Region wird getrennt und als offline gekennzeichnet. Die Azure Cosmos DB SDKs leiten Leseaufrufe an die nächste verfügbare Region in der Liste der bevorzugten Regionen weiter.

  • Wenn keine der Regionen in der Liste verfügbar ist, wird für die Aufrufe automatisch ein Fallback zur aktuellen Schreibregion durchgeführt.

  • Zur Verarbeitung von Ausfällen von Leseregionen sind keine Änderungen an Ihrem Anwendungscode erforderlich. Wenn die betroffene Leseregion wieder online ist, wird sie mit der aktuellen Schreibregion synchronisiert und steht dann wieder für die Verarbeitung von Leseanforderungen zur Verfügung, wenn sie vollständig aufgeholt hat.

  • Nachfolgende Lesevorgänge werden an die wiederhergestellte Region weitergeleitet, ohne dass Änderungen an Ihrem Anwendungscode erforderlich sind. Sowohl beim Failover als auch beim erneuten Verknüpfen einer zuvor ausgefallene Region hält Azure Cosmos DB weiterhin die Lesekonsistenzgarantien ein.

  • Selbst in dem seltenen und unglücklichen Fall, dass eine Azure-Region dauerhaft nicht wiederherstellbar ist, gibt es keinen Datenverlust, wenn Ihr Azure Cosmos DB-Konto mit mehreren Regionen mit starker Konsistenz konfiguriert ist. Ein Azure Cosmos DB-Konto mit mehreren Regionen weist die zuvor im Abschnitt Dauerhaftigkeit angegebenen Dauerhaftigkeitsmerkmale auf.

Weitere Informationen zu Lese-/Regionalausfällen

  • Während eines Ausfalls der Schreibregion macht das Azure Cosmos DB-Konto eine sekundäre Region zur neuen primären Schreibregion, wenn die Option dienstseitig verwaltetes Failover für das Azure Cosmos DB-Konto konfiguriert ist. Das Failover erfolgt in eine andere Region in der Reihenfolge der von Ihnen festgelegten Regionenpriorität.

  • Ein manuelles Failover sollte nicht ausgelöst werden und wird nicht erfolgreich sein, wenn ein Ausfall der Quell- oder Zielregion vorliegt. Der Grund ist, dass die Failoverprozedur eine Konsistenzprüfung enthält, die Konnektivität zwischen den Regionen erfordert.

  • Wenn die zuvor betroffene Region wieder online ist, werden alle Schreibdaten, die während des Ausfalls der Region nicht repliziert wurden, über den Konfliktfeed verfügbar gemacht. Anwendungen können den Konfliktfeed lesen, die Konflikte auf Grundlage der anwendungsspezifischen Logik lösen und die aktualisierten Daten nach Bedarf in den Azure Cosmos DB-Container zurückschreiben.

  • Nachdem die zuvor betroffene Schreibregion wiederhergestellt wurde, wird sie im Azure-Portal als „Online“ angezeigt und als Lesebereich verfügbar. Sie können mit PowerShell, der Azure CLI oder dem Azure-Portal zur wiederhergestellten Region als Schreibregion zurückwechseln. Es gibt keinen Daten- oder Verfügbarkeitsverlust vor, während oder nach dem Wechsel der Schreibregion. Ihre Anwendung ist weiterhin hochverfügbar.

Warnung

Während eines Ausfalls der Schreibregion stuft das Azure Cosmos DB-Konto automatisch eine sekundäre Region über die Option dienstseitig verwaltetes Failover zur neuen primären Schreibregion hoch. Nach der Wiederherstellung wird die ursprüngliche Region aber nicht automatisch wieder als Schreibregion festgelegt. Es ist Ihre Aufgabe, die wiederhergestellte Region mithilfe von PowerShell, Azure-Befehlszeilenschnittstelle oder Azure-Portal wieder als Schreibregion festzulegen (wenn dies wie oben beschrieben als sicher gelten kann).

SLAs

In der folgenden Tabelle sind die Hochverfügbarkeitsfunktionen verschiedener Kontokonfigurationen zusammengefasst.

KPI Schreibvorgänge in einer einzelnen Region ohne Verfügbarkeitszonen Schreibvorgänge in einer einzelnen Region mit Verfügbarkeitszonen Schreibvorgänge in mehreren Regionen und in einer einzelnen Region ohne Verfügbarkeitszonen Schreibvorgänge in mehreren Regionen und in einer einzelnen Region mit Verfügbarkeitszonen Mehrere Regionen, Schreibvorgänge in mehreren Regionen mit oder ohne Verfügbarkeitszonen
Schreibverfügbarkeit (SLA) 99,99 % 99,995 % 99,99 % 99,995 % 99,999%
Leseverfügbarkeit (SLA) 99,99 % 99,995 % 99,999% 99,999% 99,999%
Zonenfehler: Datenverlust Datenverlust Kein Datenverlust Kein Datenverlust Kein Datenverlust Kein Datenverlust
Zonenfehler: Verfügbarkeit Verlust der Verfügbarkeit Kein Verlust der Verfügbarkeit Kein Verlust der Verfügbarkeit Kein Verlust der Verfügbarkeit Kein Verlust der Verfügbarkeit
Regionaler Ausfall: Datenverlust Datenverlust Datenverlust Abhängig von der Konsistenzebene. Weitere Informationen finden Sie unter Kompromisse in Bezug auf Konsistenz, Verfügbarkeit und Leistung. Abhängig von der Konsistenzebene. Weitere Informationen finden Sie unter Kompromisse in Bezug auf Konsistenz, Verfügbarkeit und Leistung. Abhängig von der Konsistenzebene. Weitere Informationen finden Sie unter Kompromisse in Bezug auf Konsistenz, Verfügbarkeit und Leistung.
Regionaler Ausfall: Verfügbarkeit Verlust der Verfügbarkeit Verlust der Verfügbarkeit Kein Verfügbarkeitsverlust bei einem Fehler in der Leseregion, temporär für Fehler in der Schreibregion Kein Verfügbarkeitsverlust bei einem Fehler in der Leseregion, temporär für Fehler in der Schreibregion Kein Verlust der Leseverfügbarkeit, temporärer Verlust der Schreibverfügbarkeit in der betroffenen Region
Preis (1) Nicht zutreffend Bereitgestellte RU/s x 1,25-Rate Bereitgestellte RU/s x N Regionen Bereitgestellte RU/s x 1,25 Rate x N Regionen (2) Schreibrate in mehreren Regionen x N Regionen

1 Für serverlose Konten werden RUs mit dem Faktor 1,25 multipliziert.

2 Die Rate 1,25 gilt nur für Regionen, in denen Sie Verfügbarkeitszonen aktivieren.

Tipps für das Erstellen hochverfügbarer Anwendungen

  • Überprüfen Sie während der Ereignisse das erwartete Verhalten der Azure Cosmos DB-SDKs und welche Konfigurationen sich darauf auswirken.

  • Um Hochverfügbarkeit von Schreib- und Lesevorgängen zu garantieren, konfigurieren Sie Ihr Azure Cosmos DB-Konto so, dass es mindestens zwei Regionen (oder drei, wenn Sie eine starke Konsistenz verwenden) umfasst. Weitere Informationen finden Sie im Tutorial: Einrichten der globalen Verteilung von Azure Cosmos DB mithilfe der API für NoSQL.

  • Aktivieren Sie für Azure Cosmos DB-Konten mit mehreren Regionen, die mit einer einzelnen Schreibregion konfiguriert sind, „Dienstseitig verwaltetes Failover“ über die Azure CLI oder das Azure-Portal. Nachdem Sie das dienstseitig verwaltete Failover aktiviert haben, führt Azure Cosmos DB bei einem regionalen Ausfall ohne Benutzereingabe ein Failover für Ihr Konto durch.

  • Auch wenn Ihr Azure Cosmos DB-Konto hochverfügbar ist, ist Ihre Anwendung unter Umständen nicht richtig dafür konzipiert, hochverfügbar zu bleiben. Um die End-to-End-Hochverfügbarkeit Ihrer Anwendung im Rahmen Ihrer Anwendungs- oder Notfallwiederherstellungstests zu testen, deaktivieren Sei vorübergehend das dienstseitig verwaltete Failover für das Konto. Rufen Sie das manuelle Failover mithilfe von PowerShell, der Azure CLI oder dem Azure-Portal auf, und überwachen Sie dann Ihre Anwendung. Nach Abschluss des Tests können Sie ein Failover zurück zur primären Region durchführen und das dienstseitig verwaltete Failover für das Konto wiederherstellen.

    Wichtig

    Rufen Sie kein manuelles Failover während eines Azure Cosmos DB-Ausfalls in der Quell- oder Zielregion auf. Manuelles Failover erfordert Regionskonnektivität, um die Datenkonsistenz zu gewährleisten, sodass es nicht erfolgreich ist.

  • In einer global verteilten Datenbankumgebung besteht ein direkter Zusammenhang zwischen der Konsistenzebene und der Dauerhaftigkeit der Daten bei einem regionsweiten Ausfall. Wenn Sie Ihren Plan für die Geschäftskontinuität entwickeln, müssen Sie wissen, wie viel Zeit maximal vergehen darf, bis die Anwendung nach einer Störung vollständig wiederhergestellt ist (RTO). Sie müssen auch wissen, über welchen Zeitraum kürzlich durchgeführte Datenupdates maximal verloren gehen dürfen, wenn die Anwendung nach einer Störung wiederhergestellt wird (RPO). Weitere Informationen zu RTO und RPO finden Sie unter Konsistenzebenen in Azure Cosmos DB.

Das geschieht beim Ausfall einer Azure Cosmos DB-Region

Im Falle von Konten mit einer einzelnen Region verlieren Clients während eines Ausfalls der Azure Cosmos DB-Region die Lese- und Schreibverfügbarkeit. Konten mit mehreren Regionen weisen unterschiedliche Verhaltensweisen auf, wie in der folgenden Tabelle beschrieben.

Schreibregionen Dienstseitig verwaltetes Failover Ausblick Aktion
Eine Schreibregion Nicht aktiviert Wenn ein Ausfall in einer Leseregion vorliegt und Sie keine starke Konsistenz verwenden, leiten alle Clients zu anderen Regionen weiter. Es gibt keinen Verlust der Lese- oder Schreibverfügbarkeit, und es gibt keinen Datenverlust. Wenn Sie eine starke Konsistenz verwenden, kann sich ein Ausfall in einer Leseregion auf die Schreibverfügbarkeit auswirken, wenn weniger als zwei Leseregionen verbleiben.

Wenn ein Ausfall in einer Schreibregion vorliegt, dann verlieren Clients die Schreibverfügbarkeit. Wenn Sie keine starke Konsistenz ausgewählt haben, repliziert der Dienst einige Daten möglicherweise nicht in die verbleibenden aktiven Regionen. Diese Replikation hängt von der ausgewählten Konsistenzebene ab. Wenn in der betroffenen Region dauerhafte Datenverluste auftreten, können Sie nicht replizierte Daten verlieren.

Azure Cosmos DB stellt die Schreibverfügbarkeit nach Beendigung eines Ausfall wieder her.		 Stellen Sie sicher, dass während eines Ausfalls in den verbleibenden Regionen genügend RUs zur Unterstützung des Lesedatenverkehrs bereitgestellt sind.

Lösen Sie während des Ausfalls kein manuelles Failover aus, da es nicht erfolgreich sein kann.

Wenn der Ausfall beendet ist, passen Sie die bereitgestellten RUs entsprechend neu an.
Eine Schreibregion Aktiviert Wenn ein Ausfall in einer Leseregion vorliegt und Sie keine starke Konsistenz verwenden, leiten alle Clients zu anderen Regionen weiter. Es gibt keinen Verlust der Lese- oder Schreibverfügbarkeit, und es gibt keinen Datenverlust. Wenn Sie eine starke Konsistenz verwenden, kann sich der Ausfall einer Leseregion auf die Schreibverfügbarkeit auswirken, wenn weniger als zwei Leseregionen verbleiben.

Wenn ein Ausfall in der Schreibregion auftritt, verlieren Clients die Schreibverfügbarkeit, bis Azure Cosmos DB gemäß Ihren Präferenzen eine neue Region als die neue Schreibregion auswählt. Wenn Sie keine starke Konsistenz ausgewählt haben, repliziert der Dienst einige Daten möglicherweise nicht in die verbleibenden aktiven Regionen. Diese Replikation hängt von der ausgewählten Konsistenzebene ab. Wenn in der betroffenen Region dauerhafte Datenverluste auftreten, können Sie nicht replizierte Daten verlieren.		 Stellen Sie sicher, dass während eines Ausfalls in den verbleibenden Regionen genügend RUs zur Unterstützung des Lesedatenverkehrs bereitgestellt sind.

Lösen Sie während des Ausfalls kein manuelles Failover aus, da es nicht erfolgreich sein kann.

Wenn der Ausfall beendet ist, können Sie die Schreibregion wieder in die ursprüngliche Region verschieben und die bereitgestellten RUs entsprechend neu anpassen. Konten, die die API für NoSQL verwenden, können auch die nicht replizierten Daten in der fehlerhaften Region aus Ihrem Konfliktfeed wiederherstellen.
Mehrere Schreibregionen Nicht zutreffend Kürzlich aktualisierte Daten in der fehlerhaften Region sind in den verbleibenden aktiven Regionen möglicherweise nicht verfügbar. Letztliche, konsistente Präfix- und Sitzungskonsistenzebenen garantieren eine Veraltung von weniger als 15 Minuten. Die begrenzte Veraltung garantiert je nach Konfiguration weniger als K Updates oder T Sekunden. Wenn in der betroffenen Region dauerhafte Datenverluste auftreten, können Sie nicht replizierte Daten verlieren. Stellen Sie während eines Ausfalls sicher, dass in den verbleibenden Regionen genügend bereitgestellte RUs vorhanden sind, um mehr Datenverkehr zu bewältigen.

Wenn der Ausfall beendet ist, können Sie die bereitgestellten RUs entsprechend anpassen. Wenn möglich stellt Azure Cosmos DB nicht replizierte Daten in der fehlerhaften Region wieder her. Diese Wiederherstellung nutzt die Konfliktauflösungsmethode, die Sie für Konten konfigurieren, welche die API für NoSQL verwenden. Für Konten, die andere APIs verwenden, nutzt diese Wiederherstellung last write wins (der letzte Schreibvorgang gewinnt).

Nächste Schritte

Als Nächstes können Sie die folgenden Artikel lesen: