Hochverfügbarkeit (Zuverlässigkeit) in Azure Cosmos DB for NoSQL
In diesem Artikel wird die Unterstützung der Hochverfügbarkeit (Zuverlässigkeit) in Azure CosmosDB for NoSQL beschrieben. Dabei werden sowohl Verfügbarkeitszonen als auch regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität behandelt.
Unterstützung für Verfügbarkeitszonen
Azure-Verfügbarkeitszonen sind mindestens drei physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Die Rechenzentren innerhalb jeder Zone sind mit unabhängiger Stromversorgung, Kühlung und Netzwerkinfrastruktur ausgestattet. Bei einem Fehler in der lokalen Zone sind Verfügbarkeitszonen so konzipiert, dass regionale Dienste, Kapazität und Hochverfügbarkeit von den verbleibenden beiden Zonen unterstützt werden, wenn eine Zone betroffen ist.
Ausfälle können von Software- und Hardwareausfällen bis hin zu Ereignissen wie Erdbeben, Überflutungen und Bränden reichen. Fehlertoleranz wird durch Redundanz und logische Isolierung von Azure-Diensten erreicht. Ausführlichere Informationen zu Verfügbarkeitszonen in Azure finden Sie unter Regionen und Verfügbarkeitszonen.
Azure-Dienste mit Unterstützung von Verfügbarkeitszonen bieten das richtige Maß an Zuverlässigkeit und Flexibilität. Für die Konfiguration gibt es zwei Möglichkeiten. Sie können entweder zonenredundant mit automatischer zonenübergreifender Replikation oder zonenbasiert mit Instanzen sein, die an eine bestimmte Zone angeheftet werden. Sie können diese Ansätze auch kombinieren. Weitere Informationen zur zonalen im Vergleich zur zonenredundanten Architektur finden Sie unter Empfehlungen für die Verwendung von Verfügbarkeitszonen und Regionen.
Azure Cosmos DB ist ein mehrinstanzenfähiger Dienst, der alle Details der einzelnen Computeknoten transparent verwaltet. Sie 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.
Azure Cosmos DB bietet Folgendes:
Resilienz einzelner Knoten gegen Ausfälle. 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.
Resilienz von Zonen gegen Ausfälle. Wenn Sie ein Azure Cosmos DB-Konto mithilfe von Verfügbarkeitszonen bereitstellen, bietet Azure Cosmos DB selbst bei einem Zonenausfall eine Wiederherstellungszeitvorgabe (Recover Time Objective, RTO) von 0 und ein Wiederherstellungspunktziel (Recovery Point Objective, RPO) von 0. Weitere Informationen zum RTO finden Sie unter Wiederherstellungsziele.
Mit aktivierten Verfügbarkeitszonen unterstützt Azure Cosmos DB for NoSQL eine zonenredundante Konfiguration.
Voraussetzungen
Ihre Replikate müssen in einer Azure-Region bereitgestellt werden, die Verfügbarkeitszonen unterstützt. Informationen darüber, ob Ihre Region Verfügbarkeitszonen unterstützt, finden Sie in der Liste der unterstützten Regionen.
Ermitteln Sie unter Auswirkung der Verwendung von Verfügbarkeitszonen, ob Verfügbarkeitszonen ihrer aktuellen Konfiguration einen ausreichenden Mehrwert bieten.
Auswirkung der Verwendung von Verfügbarkeitszonen
Die Auswirkung von Verfügbarkeitszonen auf die Hochverfügbarkeit Ihrer Cosmos DB for NoSQL-Datenbank hängen vom Konsistenzniveau des Kontos und den Regionen ab, für die Verfügbarkeitszonen aktiviert sind. In vielen Fällen bieten Verfügbarkeitszonen keinen oder nur einen minimalen Mehrwert, wenn es sich bei dem Konto um ein Mehrregionenkont handelt (sofern es nicht mit hoher Konsistenz konfiguriert wurde).
Schätzen Sie anhand der nachstehenden Tabelle die Auswirkungen der Verwendung von Verfügbarkeitszonen in Ihrer aktuellen Kontokonfiguration ab:
| Konsistenzniveau des Kontos | Regionen mit aktivierten Verfügbarkeitszonen | Auswirkung der Verwendung von Verfügbarkeitszonen |
|---|---|---|
| Asynchron (begrenzte Veraltung oder schwächer) | Beliebige Anzahl sekundärer Leseregionen | Bietet nur minimalen Mehrwert, da das SDK bereits nahtlose Umleitungen für Lesevorgänge bereitstellt, wenn eine Leseregion ausfällt. |
| Synchron (hoch) | Mindestens zwei sekundäre Leseregionen | Bietet einen geringen Mehrwert, da das System ein dynamisches Quorum nutzen kann, wenn eine Leseregion ihre Verfügbarkeit verliert, sodass Schreibvorgänge fortgesetzt werden können. |
| Synchron (hoch) | Eine sekundäre Leseregion | Bietet einen größeren Mehrwert, da sich der Verlust eines Lesebereichs in diesem Szenario auf die Schreibverfügbarkeit auswirken kann. |
| Alle | Schreibregionen und eine beliebige Anzahl von sekundären Regionen | Stellt eine höhere Verfügbarkeit für Schreibvorgänge bei Zonenausfällen sicher. |
| Alle | Eine Region | Einzelne Regionen können nicht von der Failoverfunktion mit mehreren Regionen profitieren. Die Verwendung von Verfügbarkeitszonen schützt vor vollständigen Verfügbarkeitsverlusten aufgrund von Zonenausfällen. |
SLA-Verbesserungen
Da Verfügbarkeitszonen physisch getrennt sind und über unterschiedliche Stromquellen, Netzwerke und Kühlung verfügen, sind Vereinbarungen zum Servicelevel (Service-Level Agreements, SLAs) höher (99,995 %) als bei Konten mit einer einzelnen Region (99,99 %). Regionen, in denen Verfügbarkeitszonen aktiviert sind, haben eine um 25 % höhere Gebühr, während für die ohne Verfügbarkeitszonen keine zusätzlichen Kosten entstehen. Darüber hinaus wird der Premium-Tarif für Verfügbarkeitszonen für Konten erlassen, die mit Schreibvorgängen in mehreren Regionen und/oder für Sammlungen konfiguriert sind, die mit dem Modus für die Autoskalierung konfiguriert sind.
Das Hinzufügen einer zusätzlichen Region zu einem Cosmos DB-Konto erhöht in der Regel die bestehende Rechnung um 100 % (additiv, nicht multiplikativ), wobei es in verschiedenen Regionen kleinere Kostenabweichungen geben kann. Weitere Informationen finden Sie auf der Seite „Preise“.
Das Aktivieren von Verfügbarkeitszonen, das Hinzufügen zusätzlicher Regionen oder das Aktivieren von Schreibvorgängen mit mehreren Regionen kann als Layering-Ansatz verstanden werden, der die Resilienz und Verfügbarkeit eines bestimmten Cosmos DB-Kontos schrittweise erhöht – von der Verfügbarkeit von 99,99 für eine einzelne Region ohne Konfiguration von Verfügbarkeitszonen über 99,995 für eine einzelne Region mit Verfügbarkeitszonen bis hin zu 99,999 Verfügbarkeit für eine Konfiguration mehreren Regionen mit aktivierter Schreiboption für mehrere Regionen. Eine Zusammenfassung der SLAs für jede Konfiguration finden Sie in der folgenden Tabelle.
| 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.
Erstellen einer Ressource mit aktivierten Verfügbarkeitszonen
Sie können Verfügbarkeitszonen nur konfigurieren, wenn Sie einem Azure Cosmos DB NoSQL-Konto eine neue Region hinzufügen.
Um die Unterstützung für Verfügbarkeitszonen zu aktivieren, können Sie Folgendes verwenden:
Unterstützung für das Migrieren zu Verfügbarkeitszonen
Informationen zum Migrieren Ihres Cosmos DB-Kontos zur Unterstützung von Verfügbarkeitszonen finden Sie unter Migrieren von Azure Cosmos DB for NoSQL zur Unterstützung von Verfügbarkeitszonen.
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.
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. Wenn für die Region Verfügbarkeitszonen aktiviert sind, wird die Sicherung in zonenredundanten Speicherkonten gespeichert.
- 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.
Dienstseitig verwaltetes Failover
Wenn Ihre Lösung auch bei Regionsausfällen kontinuierliche Uptime erfordert, 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.
Auf Konten mit einer Region besteht nach einem regionalen Ausfall möglicherweise kein Zugriff mehr. Um jederzeit Geschäftskontinuität 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 Geschäftskontinuität 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.
Lese- und Schreibausfälle
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. An diesem Punkt ist es sicher, mithilfe von [PowerShell, der Azure CLI oder dem Azure-Portal](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account) zur wiederhergestellten Region zurückzuwechseln. 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).
Erkennung, Benachrichtigung und Verwaltung von Ausfällen
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). |
Testen für Hochverfügbarkeit
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.