Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird die Unterstützung der Hochverfügbarkeit (Zuverlässigkeit) in Azure Cosmos DB for NoSQL beschrieben. Dabei werden sowohl Verfügbarkeitszonen als auch regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität behandelt.
Ausfallsicherheit von Computeknoten
Azure Cosmos DB verwaltet transparent alle Details einzelner Computeknoten. 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 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. Informationen zu RTO und RPO finden Sie unter Was sind Geschäftskontinuität, hohe Verfügbarkeit und Notfallwiederherstellung?.
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.
Azure Cosmos DB unterstützt Zonenredundanz. Wenn Sie Zonenredundanz aktivieren, verteilt Azure die Replikate Ihrer Daten über mehrere Verfügbarkeitszonen hinweg, wodurch Resilienz für Rechenzentrumsprobleme und Ausfalle bereitgestellt wird. Sie können Zonenredundanz in Azure-Regionen aktivieren, die Verfügbarkeitszonen unterstützen. Informationen darüber, ob Ihre Region Verfügbarkeitszonen unterstützt, finden Sie in der Liste der unterstützten Regionen.
Es wird empfohlen, Zonenredundanz in Regionen zu verwenden, in denen sie unterstützt wird, insbesondere für Konten mit einer Region.
Zonen-Redundanz und Einzelregion-Konten
Wenn Sie über ein Cosmos DB-Konto für eine Einzelregion verfügen, ist es wichtig, gegen Probleme in einer Verfügbarkeitszone resilient zu sein. Das Aktivieren von Zonenredundanz schützt vor totalen Verfügbarkeitsverlusten aufgrund des Ausfalls einer Verfügbarkeitszone.
Da Verfügbarkeitszonen physisch getrennt sind und unterschiedliche Energiequellen, Netzwerke und Kühlung bereitstellen, sind die Verfügbarkeits-SLAs für Azure Cosmos DB für zonenredundante Konten höher als Konten, die keine Verfügbarkeitszonen verwenden.
Zonenredundanz und Konten mit mehreren Regionen
Wenn Sie über ein Konto mit mehreren Regionen verfügen, können Sie optional Zonenredundanz für beliebige oder alle Kontoregionen aktivieren, die Verfügbarkeitszonen unterstützen. Konten für mehrere Regionen können Vereinbarungen zum Servicelevel (SLA) mit hoher Verfügbarkeit erzielen, und die Aktivierung der Zonenredundanz kann die SLAs für die allgemeine Verfügbarkeit, die Sie in diesen Regionen erreichen, weiter verbessern.
Bei Konten mit mehreren Regionen hängt die Auswirkung der Zonenredundanz auf die Verfügbarkeit Ihrer Cosmos DB für NoSQL-Datenbank von der Konsistenzstufe des Kontos ab und welche Regionen Zonenredundanz aktiviert haben. Lesen Sie die nachstehende Tabelle, um die Auswirkungen der Verwendung von Verfügbarkeitszonen in Ihrer Konfiguration mit mehreren Regionen zu schätzen:
| Konsistenzniveau des Kontos | Regionen mit aktivierten Verfügbarkeitszonen | Auswirkung der Verwendung von Verfügbarkeitszonen |
|---|---|---|
| Synchron (hoch) | Eine sekundäre Leseregion | Hoher Vorteil der Zonenredundanz. Bietet einen größeren Mehrwert, da sich der Verlust eines Lesebereichs in diesem Szenario auf die Schreibverfügbarkeit auswirken kann. |
| Synchron (hoch) | Mindestens zwei sekundäre Leseregionen | Weniger Wert der Zonenredundanz. 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. |
| Asynchron (begrenzte Veraltung oder schwächer) | Mindestens ein sekundärer Lesebereich | Weniger Wert der Zonenredundanz. Bietet nur minimalen Mehrwert, da das SDK bereits nahtlose Umleitungen für Lesevorgänge bereitstellt, wenn eine Leseregion ausfällt. |
| Beliebig | Alle Schreibregionen und eine beliebige Anzahl sekundärer Regionen | Hoher Vorteil der Zonenredundanz. Stellt eine höhere Verfügbarkeit für Schreibvorgänge bei Ausfällen von Verfügbarkeitszonen sicher. |
Kosten für die Aktivierung von Zonenredundanz
Regionen, in denen die Zonenredundanz aktiviert ist, werden mit einem Zuschlag von 25 % belastet. Die Premiumpreise für Verfügbarkeitszonen werden jedoch für Konten aufgehoben, die mit Mehrregionen-Schreibvorgängen und/oder für Sammlungen konfiguriert sind, die mit dem Autoskalenmodus konfiguriert sind.
Durch das Hinzufügen einer zusätzlichen Region zu einem Cosmos DB-Konto erhöht sich die Rechnung typischerweise um 100% pro Region. Es gibt jedoch kleine Unterschiede bei den Kosten in den verschiedenen Regionen.
Weitere Informationen finden Sie auf der Seite „Preise“.
SLA-Verbesserungen
Um die Resilienz und Verfügbarkeit eines Azure Cosmos DB-Kontos zu erhöhen, können Sie einen Layering-Ansatz implementieren, der Folgendes umfasst:
- Aktivieren der Zonenredundanz.
- Hinzufügen einer oder mehrerer zusätzlicher Regionen.
- Aktivieren von Schreibvorgängen in mehreren Regionen.
Der Schichtansatz schützt das Konto bei jedem Schritt – von der Verfügbarkeit mit 4 Neunen für eine Konfiguration mit einer einzelnen Region ohne Zonenredundanz, über 4,5 Neunen für eine einzelne Region mit Zonenredundanz, bis hin zur Verfügbarkeit mit 5 Neunen für eine Konfiguration mit mehreren Regionen, bei der die Option für das Schreiben in mehreren Regionen aktiviert ist.
Die folgende Tabelle enthält eine Zusammenfassung der SLAs für jede Konfiguration:
| Leistungsindikator | 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 verfügbar | 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.
Konfigurieren von Verfügbarkeitszonen
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:
Aktivieren der Verfügbarkeitszonenunterstützung
Informationen zum Aktivieren von Zonenredundanz auf Ihrem Azure Cosmos DB-Konto finden Sie unter Migrieren von Azure Cosmos DB für NoSQL zur Unterstützung der Verfügbarkeitszone).
Regionsübergreifende Notfallwiederherstellung und Geschäftskontinuität
Notfallwiederherstellung (DR) bezieht sich auf Methoden, die Organisationen zum Wiederherstellen von Ereignissen mit hohem Einfluss verwenden, z. B. Naturkatastrophen oder fehlerhafte Bereitstellungen, die zu Ausfallzeiten und Datenverlusten 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, finden Sie Unter "Empfehlungen für das Entwerfen einer Notfallwiederherstellungsstrategie".
Für DR verwendet Microsoft das Modell der gemeinsamen Verantwortung. In diesem Modell stellt Microsoft sicher, dass die Basisinfrastruktur und Plattformdienste verfügbar sind. Viele Azure-Dienste replizieren jedoch nicht automatisch Daten oder greifen von einer fehlgeschlagenen Region zurück, um sie in eine andere aktivierte Region zu replizieren. Für diese Dienste sind Sie dafür verantwortlich, einen Notfallwiederherstellungsplan zu erstellen, der für Ihre Workload geeignet ist. Die meisten Dienste, die im Rahmen von Azure-PaaS-Angeboten (Plattform-as-a-Service) ausgeführt werden, bieten Features und Anleitungen zur Unterstützung der Notfallwiederherstellung. Sie können dienstspezifische Features verwenden, um die schnelle Wiederherstellung zu unterstützen, um Ihren DR-Plan 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 |
| Begrenzte Veraltung | 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 | Ausfall | Auswirkungen auf die Verfügbarkeit | Auswirkungen auf die Verfügbarkeit | Vorgehensweise |
|---|---|---|---|---|
| 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 | Vorgehensweise |
|---|---|---|---|
| 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 verfügbar | 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.