Zuverlässigkeit in Azure Cosmos DB

Azure Cosmos DB für NoSQL ist ein global verteilter, multimodellbasierter Datenbankdienst, der Dokumentdatenmodelle mit flexiblen Schemas unterstützt. Azure Cosmos DB bietet umfassende Zuverlässigkeitsfeatures, einschließlich mehrerer Konsistenzstufen, mit denen Sie Leistung und Verfügbarkeit ausgleichen können, zonenredundante Bereitstellungen, die vor Verfügbarkeitszonenfehlern, multi-regions-Replikation mit vom Dienst verwaltetem oder vom Kunden verwaltetem Failover und kontinuierlichen und regelmäßigen Sicherungsoptionen für den Datenschutz geschützt sind.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Sie Azure Cosmos DB widerstandsfähig für verschiedene potenzielle Ausfälle und Probleme machen, einschließlich vorübergehender Fehler, Verfügbarkeitszonenausfälle, Regionsausfälle und Servicewartung. Außerdem wird beschrieben, wie man Sicherungen verwendet, um sich von anderen Arten von Problemen zu erholen, und es werden wichtige Informationen zur Azure Cosmos DB Servicelevel-Vereinbarung (SLA) hervorgehoben.

Bereitstellungsempfehlungen für die Produktion

Das Azure Well-Architected Framework bietet Empfehlungen für Zuverlässigkeit, Sicherheit, Kosten, Vorgänge und Leistung. Informationen dazu, wie sich diese Bereiche gegenseitig beeinflussen und zu einer zuverlässigen Azure Cosmos DB Lösung beitragen, finden Sie unter Architecture best practices for Azure Cosmos DB.

Übersicht über die Zuverlässigkeitsarchitektur

In diesem Abschnitt werden einige der wichtigen Aspekte der Funktionsweise des Diensts beschrieben, die aus Zuverlässigkeitsperspektive am relevantesten sind. Im Abschnitt wird die logische Architektur vorgestellt, die einige der Ressourcen und Features enthält, die Sie bereitstellen und verwenden. Außerdem wird die physische Architektur erläutert, die Details zur Funktionsweise des Diensts unter den Deckeln bereitstellt.

Logische Architektur

Die primäre Ressource, die Sie bereitstellen, ist ein Azure Cosmos DB account. Jedes Konto kann über mehrere Datenbanken mit mehreren Containern verfügen. Container dienen als logische Einheiten der Verteilung und Skalierbarkeit. Sie können Container wie Sammlungen, Tabellen und Diagramme erstellen, je nachdem, welche API Sie für die Interaktion mit Azure Cosmos DB verwenden. Weitere Informationen zum Ressourcenmodell finden Sie unter Datenbanken, Container und Elemente in Azure Cosmos DB. Jeder Container verwendet Partitionierung, die hohe Skalierung und hohe Leistung unterstützt.

Sie konfigurieren den Durchsatz, der die Menge der Systemressourcen darstellt, die Sie zum Abfragen und Arbeiten mit Ihren Daten verwenden können. Sie können den Durchsatz manuell bereitstellen, die Automatische Skalierung verwenden , um die Kapazität basierend auf den Anforderungen Ihrer Workload dynamisch anzupassen, oder den serverlosen Kontotyp verwenden, um für Ihre tatsächliche Nutzung in Rechnung zu stellen.

Ein einzelnes Konto kann sich über mehrere Azure-Regionen erstrecken, was Ihre Ausfallsicherheit bei regionalen Ausfällen erhöht. Sie können mehrere Regionen für das Lesen konfigurieren, und wenn Sie die Stufe "Geschäftskritisch" verwenden, können Sie mehrere Regionen zum Schreiben verwenden. Azure Cosmos DB repliziert Ihre Daten automatisch geographisch. Das Verhalten der Georeplikation wird von der verwendeten Konfiguration beeinflusst, z. B. der Konsistenzstufe, die angibt, wie Sie Kompromisse zwischen Datenkonsistenz, Verfügbarkeit, Latenz und Durchsatz herstellen möchten. Unterschiedliche Konsistenzstufen optimieren für unterschiedliche Anliegen, unterstützen unterschiedliche Garantien und bieten verschiedene Arten von regionsübergreifender Replikation.

Physische Architektur

Azure Cosmos DB speichert mehrere replicas Ihrer Daten zur Redundanz. Der Dienst mindert automatisch Replikatausfälle, indem das Quorum über die Replikate in jeder Region hinweg aufrechterhalten wird. Dieser Ansatz garantiert hohe Verfügbarkeit und schützt vor Datenverlust bei einzelnen Knotenfehlern, ohne dass Anwendungsänderungen oder Konfiguration erforderlich sind.

Intern verwaltet Azure Cosmos DB Ihre Daten über verschiedene Konstrukte wie physical partitions, partitionssätze und replica sets. Ausführlichere Informationen zur Funktionsweise Azure Cosmos DB finden Sie unter Global data distribution with Azure Cosmos DB - under the hood.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zur Behandlung vorübergehender Fehler.

Es wird empfohlen, die Azure Cosmos DB SDKs zu verwenden. Die SDKs bieten automatisch Unterstützung für verschiedene Aspekte der Resilienz, einschließlich der Behandlung vorübergehender Fehler durch automatische Wiederholungen und der Beachtung von vom Dienst gesendeten Ratenbegrenzungen. Weitere Informationen finden Sie unter Design resilient applications with Azure Cosmos DB SDKs.

Wenn Sie mit einem Multiregion-Konto arbeiten, unterstützt das SDK auch eine schwellenwertbasierte Verfügbarkeitsstrategie, auch hedging genannt, wo es parallele Leseanforderungen an mehrere Regionen sendet und die schnellste Antwort akzeptiert. Dieser Ansatz kann die Anwendungsleistung verbessern, wenn in einer Region vorübergehend eine höhere Latenz als üblich auftritt.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer 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. Microsoft wählt die zu verwendenden Verfügbarkeitszonen aus.

Diagramm mit einem Azure Cosmos DB Konto mit einer Replikatmenge, die drei Replikate enthält, die über drei separate Verfügbarkeitszonen verteilt werden.

Ein Azure Cosmos DB Konto kann mehrere Regionen (Standorte) für globale Verteilung, Skalierung und Failover verwenden. Sie konfigurieren Zonenredundanz für jede Region in Ihrem Konto separat.

Die Verwendung von Zonenredundanz in Azure Cosmos DB hat keine erkennbaren Auswirkungen auf die Leistung oder Latenz. Für den ausgewählten Konsistenzmodus sind keine Anpassungen erforderlich, und es ist keine Änderung des Anwendungscodes erforderlich.

Es wird empfohlen, Zonenredundanz in Regionen zu verwenden, in denen sie unterstützt wird, insbesondere für Konten mit einer Region. 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.

Tipp

Das Aktivieren von Zonenredundanz ist eine hervorragende Möglichkeit, die Resilienz Ihrer Azure Cosmos DB-Datenbank zu erhöhen, ohne zusätzliche Anwendungskomplexitäten einzuführen oder die Leistung zu beeinträchtigen. Je nach Kontokonfiguration entstehen möglicherweise nicht einmal zusätzliche Kosten.

Wenn Sie zonenredundanz nicht aktivieren, ist das Konto in dieser Region nicht zonenzonal . Nichtzonale Konten könnten Replikate in einer einzelnen Verfügbarkeitszone platzieren, was zu möglichen Ausfallzeiten führt, wenn in dieser bestimmten Zone ein Problem auftritt.

Requirements

  • Region support: Sie können Zonenredundanz in Azure Regionen aktivieren, die Verfügbarkeitszonen unterstützen. Informationen dazu, ob Ihre Region Verfügbarkeitszonen unterstützt, finden Sie in der Liste der unterstützten Regionen.

    Zonenredundanz ist keine kontoweite Einstellung. Azure Cosmos DB Konten können mehrere Regionen umfassen, und jede Region kann unabhängig für die Verwendung von Verfügbarkeitszonen konfiguriert werden. Regionen, die Keine Verfügbarkeitszonen unterstützen, verhindern nicht, dass Sie Zonenredundanz in anderen Regionen innerhalb desselben Kontos aktivieren.

  • Serverlose Konten: Sie können redundante serverlose Zonenkonten nur konfigurieren, wenn Sie sie erstellen. Sie können vorhandene serverlose Konten nicht ohne Verfügbarkeitszonen in eine Verfügbarkeitszonenkonfiguration konvertieren. Für unternehmenskritische Workloads empfehlen wir die Verwendung des bereitgestellten Durchsatzes.

Überlegungen

  • Mehrere gleichzeitige Zonenausfälle: Ein Single-Region-Konto mit Zonenredundanz kann die Lese- und Schreibverfügbarkeit beibehalten, wenn ein Ausfall eine einzelne Verfügbarkeitszone betrifft. Wenn sich der Ausfall jedoch auf mehrere Verfügbarkeitszonen oder die gesamte Region auswirkt, verlieren Single-Region-Konten Lese- und Schreibzugriff, bis der Dienst wiederhergestellt wird. Erwägen Sie, ein Multi-Region-Konto bereitzustellen, wenn Sie für den gleichzeitigen Ausfall mehrerer Zonen widerstandsfähig sein müssen.

  • 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. Es wird dringend empfohlen, Zonenredundanz zu aktivieren, wenn Ihr Konto für die Verwendung einer einzelnen Region konfiguriert ist oder wenn sie für die Verwendung eines einzelnen Schreibbereichs mit mehreren Lesebereichen konfiguriert ist.

Cost

Regionen, in denen Zonenredundanz aktiviert ist, werden mit einem Aufpreis berechnet. Die Premium-Preise für Verfügbarkeitszonen entfallen jedoch für Konten, die mit Schreibvorgängen in mehreren Regionen konfiguriert sind, und für Sammlungen, die für die Verwendung des automatischen Durchsatzmodus konfiguriert sind. Weitere Informationen finden Sie unter Azure Cosmos DB – Preise.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

Bei den meisten Konten aktivieren Sie Zonenredundanz nur, wenn Sie einem Azure Cosmos DB Konto eine neue Region hinzufügen. Um die Verfügbarkeitszonenunterstützung für ein vorhandenes Konto zu aktivieren, fügen Sie eine Region hinzu, und aktivieren Sie Zonenredundanz darauf. Sie können einem Prozess folgen, um einen temporären Bereich hinzuzufügen, damit Sie Zonenredundanz in Ihrer ursprünglichen Region konfigurieren können. Ausführliche Schritte finden Sie unter Aktivieren der Zonenredundanz für ein Azure Cosmos DB-Konto.

Bei serverlosen Konten müssen Sie zonenredundanz aktivieren, wenn Sie das Konto erstellen.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie ein Azure Cosmos DB Konto für Zonenredundanz konfigurieren, und alle Zonen sind betriebsbereit.

  • Cross-zone operation: Azure Cosmos DB leitet Anforderungen automatisch an Replikate über Verfügbarkeitszonen weiter, sodass jedes Replikat eine Anforderung verarbeiten kann.

  • Zonenübergreifende Datenreplikation: Wenn ein Client eine Änderung an daten vorgibt, wird diese Änderung auf mehrere Replikate in verschiedenen Zonen angewendet, um ein Quorum zu erreichen. Dieser Ansatz wird als synchrone Replikation bezeichnet. Die synchrone Replikation stellt eine hohe Datenkonsistenz sicher, wodurch die Wahrscheinlichkeit eines Datenverlusts während eines Zonenfehlers reduziert wird. Verfügbarkeitszonen befinden sich relativ nah beieinander, was bedeutet, dass es minimale Auswirkungen auf Latenz oder Durchsatz gibt.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie ein Azure Cosmos DB Konto für Zonenredundanz konfigurieren, und es gibt einen Ausfall in einer der Zonen.

  • Erkennung und Reaktion: Die Azure Cosmos DB-Plattform ist dafür verantwortlich, einen Fehler in einer Verfügbarkeitszone zu erkennen. Sie müssen keine Maßnahmen ergreifen, um ein Zonenfailover zu initiieren.
  • Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone abfällt. Sie können jedoch Azure Resource Health verwenden, um den Status einer einzelnen Ressource zu überwachen, und Sie können Resource Health Alerts einrichten, um Sie über Probleme zu informieren. Sie können auch Azure Service Health verwenden, um den Gesamtstatus des Diensts zu verstehen, einschließlich aller Zonenfehler, und Sie können Service Health Alerts einrichten, um Sie über Probleme zu informieren.

  • Aktive Anforderungen: Wenn eine Verfügbarkeitszone nicht verfügbar ist, beendet Azure Cosmos DB alle in Bearbeitung ausgeführten Anforderungen, die mit Replikaten in der betroffenen Zone verbunden sind, und die Anwendung muss diese Anforderungen wiederholen. Stellen Sie sicher, dass Ihre Anwendung vorbereitet ist, indem Sie eine Anleitung zur vorübergehenden Fehlerbehandlung ausführen.

  • Erwarteter Datenverlust: Es ist kein erwarteter Datenverlust durch einen Zonenfehler zu erwarten.

  • Erwartete Ausfallzeiten: Während Zonenausfällen kann es zu kurzen Unterbrechungen bei den Verbindungen kommen, die in der Regel einige Sekunden dauern, während der Datenverkehr umverteilt wird. Stellen Sie sicher, dass Ihre Anwendungen vorbereitet sind, indem Sie den Leitfaden zur Behandlung vorübergehender Fehler befolgen.

  • Redistribution: Azure Cosmos DB leitet eingehende Anforderungen automatisch an fehlerfreie Replikate in anderen Verfügbarkeitszonen weiter. Wenn eine Verfügbarkeitszone einen Ausfall aufweist, wird der von der Plattform bereitgestellte Durchsatz automatisch in andere Replikate umgeleitet.

Zonenwiederherstellung

Wenn die Verfügbarkeitszone wiederhergestellt wird, stellt Azure Cosmos DB Replikate automatisch in der Verfügbarkeitszone wieder her und leitet den Datenverkehr zwischen Replikaten normalerweise um.

Test auf Zonenfehler

Verfügbarkeitszonenfailover und -wiederherstellung für Azure Cosmos DB werden von Microsoft vollständig verwaltet. Sie müssen keine Fehlerprozesse der Verfügbarkeitszone initiieren oder überprüfen.

Widerstandsfähigkeit bei regionalen Ausfällen

Wenn Sie ein Azure Cosmos DB-Konto in einer einzelnen Region bereitstellen, führt ein regionenweiter Ausfall, der alle Azure Cosmos DB-Knoten betrifft, in der Regel nicht zu einem Datenverlust, verhindert jedoch, dass Ihre Anwendung auf die Daten zugreift. Azure Cosmos DB stellt den Datenzugriff wieder her, nachdem sich der Dienst in der betroffenen Region erholt hat. Datenverlust tritt nur auf, wenn in der Region eine nicht behebbare Katastrophe auftritt.

Um sich auf die seltenen Fälle von Regionsausfällen vorzubereiten, können Sie Azure Cosmos DB so konfigurieren, dass verschiedene Haltbarkeits- und Verfügbarkeitsebenen unterstützt werden, indem Sie eine der folgenden Ansätze verwenden:

In der folgenden Tabelle sind die Wiederherstellungsoptionen zusammengefasst, die basierend auf der Kontokonfiguration und dem Typ des Ausfalls verfügbar sind. In späteren Abschnitten dieses Artikels finden Sie ausführliche Details zu diesen Optionen und dem zugehörigen Verhalten.

Konfiguration Ausfalltyp Auswirkungen auf die Verfügbarkeit Auswirkungen auf die Verfügbarkeit Was zu tun ist
Konto mit einer Region Regionsausfall Lese- und Schreibzugriff geht verloren, bis der Dienst wiederhergestellt wird. Kein Datenverlust, es sei denn, die Region erlebt eine nicht wiederherstellbare Katastrophe. Warten Sie auf die Dienstwiederherstellung, oder fordern Sie die Kontowiederherstellung von der Sicherung in eine andere Region an.
Konto mit mehreren Regionen und einer Schreibregion Lesen eines Ausfalls von Regionen SDK leitet anhand der bevorzugten Regionskonfiguration zu verfügbaren Regionen um.

Bei Konten, die eine starke Konsistenz mit nur zwei Regionen verwenden oder bei denen die Begrenzung der Veralterung das Veraltetkeitsfenster überschreitet, geht die Schreibverfügbarkeit ebenfalls verloren, es sei denn, Sie nehmen die betroffene Region offline.		 Kein Datenverlust. Stellen Sie den ausreichenden Durchsatz in verbleibenden Regionen sicher. Bei starker oder gebundener Konsistenz sollten Sie in Betracht ziehen, die betroffene Region offline zu nehmen.
Konto mit mehreren Regionen und einer Schreibregion Ausfall der Schreibregion (mit aktiviertem PPAF) Automatisches Failover auf Partitionsebene; kein manueller Eingriff erforderlich. Wenn das Konto eine starke Konsistenz verwendet, gehen keine Daten verloren. Wenn das Konto keine starke Konsistenz verwendet, können unreplizierte Daten im unwahrscheinlichen Fall verloren gehen, dass die Region dauerhaft an Datenverlust leidet. Keine Aktion erforderlich. PPAF verwaltet Failover automatisch.
Konto mit mehreren Regionen und einer Schreibregion Schreibbereichsausfall (ohne PPAF) Die Schreibverfügbarkeit geht verloren, bis ein Offlinevorgang einer Region oder ein vom Dienst verwaltetes Failover abgeschlossen ist. Lesevorgänge werden aus gesunden Regionen fortgesetzt. Wenn das Konto eine starke Konsistenz verwendet, gehen keine Daten verloren. Wenn das Konto keine starke Konsistenz verwendet, können unreplizierte Daten im unwahrscheinlichen Fall verloren gehen, dass die Region dauerhaft an Datenverlust leidet. Führen Sie einen Offlinevorgang für einen Bereich aus. Wenn das vom Dienst verwaltete Failover aktiviert ist, initiiert Azure Cosmos DB das Failover automatisch, dies kann jedoch eine Stunde oder mehr dauern. Ändern Sie den Schreibbereich während des Ausfalls nicht.
Konto mit mehreren Schreibzugriffsregionen Ausfall in jedem Gebiet Automatisches Routing an gesunde Regionen über die SDK-Konfiguration; kein manueller Eingriff erforderlich. Kürzlich aktualisierte Daten in der fehlgeschlagenen Region sind möglicherweise in den verbleibenden Regionen nicht verfügbar. Für den unwahrscheinlichen Fall, dass die Region permanenten Datenverlust erleidet, können nicht replizierte Daten verloren gehen. Stellen Sie den ausreichenden Durchsatz in verbleibenden Regionen sicher. Nach der Wiederherstellung stellt Azure Cosmos DB automatisch unreplizierte Daten mithilfe der konfigurierten Konfliktlösungsmethode wieder her.
Jede Kontokonfiguration Datenbeschädigung oder versehentliches Löschen Keine Auswirkungen auf die Verfügbarkeit. Mögliche Datenverluste, je nachdem, wann die Beschädigung oder Löschung erkannt wird. Zeitpunktbezogene Wiederherstellung (fortlaufende Sicherung) oder Wiederherstellung aus regelmäßiger Sicherung.

Hinweis

Dieser Artikel konzentriert sich auf die Zuverlässigkeitsaspekte der Multiregion-Features von Azure Cosmos DB. Es gibt weitere Vorteile für mehrere Lese- und Schreibbereiche, z. B. höhere Leistung und Skalierung für global verteilte Anwendungen. Sie sollten Ihre gesamte Lösungsarchitektur bewerten und alle Vorteile der Verwendung dieser Funktionen berücksichtigen.

SDKs und Resilienz

Die Azure Cosmos DB SDKs sind ein wichtiger Bestandteil der Resilienzstrategie Ihrer Anwendung. Wenn Sie über ein Konto mit mehreren Regionen verfügen, wirkt sich die SDK-Konfiguration darauf aus, wie Anforderungen zwischen Regionen weitergeleitet werden, einschließlich der bevorzugten Regionen, mit denen eine Verbindung hergestellt werden soll, und Regionen, die ausgeschlossen werden sollen. SDKs überwachen die Verfügbarkeit von Regionen und Partitionen und können sich dynamisch so konfigurieren, dass gesunde Regionen und Partitionen verwendet werden, z. B. über den Trennschalter auf Partitionsebene.

Weitere Informationen dazu, wie das SDK hohe Verfügbarkeit unterstützt, finden Sie in der Dokumentation zu hoher Verfügbarkeit für das verwendete SDK:

Potenzieller Datenverlust während Regionsausfällen

Wenn Sie ein Azure Cosmos DB Konto in mehreren Regionen bereitstellen, hängt die Datenbeständigkeit von der Konsistenzstufe ab, die Sie für das Konto konfigurieren. In der folgenden Tabelle sind für alle Konsistenzstufen das Wiederherstellungspunktziel (RPO) eines Azure Cosmos DB Kontos aufgeführt, das in mindestens zwei Regionen bereitgestellt wird. Das RPO stellt den potenziellen Datenverlust während eines Regionsausfalls dar.

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.

Mehrere Lesebereiche mit einem einzelnen Schreibbereich

Wenn Ihre Lösung während Regionsausfällen fortlaufende Betriebszeit erfordert, können Sie Azure Cosmos DB so konfigurieren, dass Ihre Daten in mehreren Regionen repliziert werden, wobei Schreibvorgänge von Ihrer primären Region behandelt werden. Sie können Ihre Anwendungen optional so konfigurieren, dass sie eine Verbindung mit bestimmten Lesebereichen herstellen, wodurch die Leistung verbessert werden kann. Wenn eine Region über einen Ausfall verfügt, kann das Konto weiterhin aus fehlerfreien Regionen arbeiten.

Diagramm mit einem Azure Cosmos DB Konto. Region A ist eine Schreib- und Leseregion, und Region B ist ein Lesebereich. Eine Anwendung in Region A führt Lese- und Schreibvorgänge für das Azure Cosmos DB Konto in Region A aus. Eine Anwendung in Region B führt Lesevorgänge für das Konto in Region B durch, schreibt jedoch in Region A. Intern repliziert Azure Cosmos DB Änderungen zwischen den Regionen.

Failover zwischen Regionen

Sie können das Azure Cosmos DB SDK mit einer priorisierten Liste der Lesebereiche konfigurieren. Das SDK verbindet Ihre Anwendung mit der ersten verfügbaren Region in der Liste. Während eines Lesebereichsausfalls erkennt das SDK den Regionsausfall über Back-End-Antwortcodes, kennzeichnet ihn als nicht verfügbar und leitet zukünftige Vorgänge an die nächste verfügbare Region in der Einstellungsliste weiter. Stellen Sie sicher, dass die Liste der bevorzugten Regionen korrekt festgelegt ist und dass sie Ihren geschäftlichen und Latenzanforderungen entspricht. Ausführliche Anleitungen finden Sie unter Problembehandlung bei der Verfügbarkeit des Azure Cosmos DB SDK.

Failover ist der Prozess, um eine der Regionen Ihres Kontos entweder vollständig oder teilweise nicht verfügbar zu machen. Die Auswirkung eines Failovers hängt davon ab, ob es sich bei der Region um einen Schreibbereich oder einen Lesebereich handelt:

  • Wenn ein Schreibbereich nicht verfügbar ist, wird eine andere Region zum Schreibbereich.
  • Wenn ein Lesebereich nicht verfügbar ist, kann diese Region keine Leseanforderungen verarbeiten, und andere Regionen werden stattdessen für Lesevorgänge verwendet.

Azure Cosmos DB bietet mehrere Failovertypen:

  • Automatisches Per-Partition-Failover (PPAF): Intern verteilt Azure Cosmos DB Ihre Daten über mehrere physische Partitionen hinweg. Wenn ein Problem mit der Infrastruktur auftritt, die eine Partition unterstützt, sind möglicherweise keine anderen Partitionen betroffen. PPAF ermöglicht einmaligen Schreibbereichskonten das automatische Fehlschlagen einzelner Partitionen in eine sekundäre Region, während gesunde Partitionen in der primären Region erhalten bleiben. PPAF kann dazu beitragen, Ausfallzeiten zu minimieren und eine schnellere Wiederherstellung während eines Teilregionenausfalls zu ermöglichen. Weitere Informationen finden Sie unter Wie man das Per-Partition Automatic Failover (PPAF) für Azure Cosmos DB einführt und übernimmt.

    Hinweis

    Das automatische Failover pro Partition befindet sich in der öffentlichen Vorschau. Dieses Feature wird ohne Vereinbarung zum Servicelevel bereitgestellt. Weitere Informationen finden Sie unter Supplementale Nutzungsbedingungen für Microsoft Azure Previews.

  • Erzwungenes Failover: Sie können eine der Regionen Ihres Kontos offline schalten. Dies wird auch als vom Kunden verwaltetes Failover oder als Offline-Betrieb in der Region bezeichnet. Dies ist der empfohlene Ansatz zum schnellen Wiederherstellen der Verfügbarkeit während eines Ausfalls. Sie sind dafür verantwortlich, den Ausfall zu erkennen und das Failover auszulösen. Sie können auch erzwungene Failovers verwenden, um Ausfallszenarien in Regionen für Tests zu simulieren, z. B. während einer Notfallwiederherstellungsübung.

    Wenn Sie den Schreibbereich offline schalten, wird der Lesebereich mit der nächsten höchsten Priorität zum neuen Schreibbereich. Wenn Sie einen Lesebereich offline schalten, können Ihre Anwendungen eine Verbindung mit einem anderen Lesebereich im Konto herstellen.

    Durch ein erzwungenes Failover Ihrer Schreibregion besteht die Möglichkeit eines Datenverlusts für alle nicht replizierten Schreibvorgänge.

    Nach einem erzwungenen Failover muss Microsoft die Region wieder online schalten. Bei gesunden Regionen ist dieser Prozess automatisiert, kann aber bis zu mehrere Tage dauern. Wenn die Region innerhalb eines oder zwei Tages nicht wieder online kommt, öffnen Sie einen Supportfall, um Hilfe anzufordern.

  • Schreibbereich ändern: Wenn die Regionen fehlerfrei sind, können Sie die Schreibregion Ihres Kontos ändern. Diese Änderung ist effektiv ein geplantes Failover der Schreibregion für Ihr Konto.

    Das Ändern des Schreibbereichs führt zu keinem Datenverlust, da die Datenreplikation vor der Heraufgestuftung des neuen Schreibbereichs aufholt. Es kann eine kurze Unterbrechung geben, aber Clients, die Wiederholungslogik und andere Techniken zur Behandlung vorübergehender Fehler verwenden, erleben in der Regel keine signifikanten Beeinträchtigungen.

    Für diesen Vorgang müssen die Regionen fehlerfrei sein, also kann er während eines Regionsausfalls nicht durchgeführt werden.

  • Serviceverwaltetes Failover: Wenn Ihr Konto dienstverwaltetes Failover verwendet, ist Microsoft für die Entscheidung verantwortlich, wann zwischen Regionen ein Failover ausgeführt werden soll. Um das vom Dienst verwaltete Failover zu aktivieren, geben Sie Prioritäten für jede Region an. Das Deklarieren eines Ausfalls und auslösen eines vom Dienst verwalteten Failovers kann jedoch erhebliche Zeit in Anspruch nehmen – möglicherweise eine Stunde oder mehr. Führen Sie für eine schnellere Wiederherstellung ein erzwungenes Failover aus, anstatt auf das auslösende Vom Dienst verwaltete Failover zu warten.

    Wenn Microsoft ein vom Dienst verwaltetes Failover für die Schreibregion des Kontos auslöst, können alle nicht replizierten Schreibvorgänge verloren gehen.

    Nach einem vom Dienst verwalteten Failover muss Microsoft eine Region wieder online schalten. Microsoft bringt die Region automatisch online, aber dieser Vorgang kann mehrere Tage dauern.

Requirements

Region support: Sie können jede Azure Region als Lesebereich für Ihr Azure Cosmos DB Konto konfigurieren.

Cost

Durch das Hinzufügen eines zusätzlichen Lesebereichs zu einem Azure Cosmos DB Konto werden Ihre vorhandenen Kosten für jede Region erhöht. Weitere Informationen finden Sie unter Azure Cosmos DB – Preise.

Konfigurieren mehrerer Lesebereiche

Kapazitätsplanung und -verwaltung

Wenn Ihre Anwendung Anforderungen über Regionen verteilt und eine Region offline geht, wird in den verbleibenden Regionen ein höheres Anforderungsvolumen angezeigt. Verwenden Sie automatisch skalierbaren Durchsatz, um die Kapazität dynamisch basierend auf dem Bedarf anzupassen. Wenn Sie den bereitgestellten Durchsatz verwenden, planen Sie eine angemessene Kapazität, um den Verlust einer Region ohne Dienstbeeinträchtigung zu bewältigen, und erwägen Sie die Überbereitstellung. Weitere Informationen finden Sie unter Verwalten der Kapazität mit Überbereitstellung.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie ein Azure Cosmos DB Konto mit mehreren Lesebereichen konfigurieren, und alle Regionen sind betriebsbereit.

  • Standortübergreifender Betrieb: Ihre Anwendung konfiguriert die Region, die Lesevorgänge empfangen soll. Sie können Ihre Anwendung mit einer priorisierten Liste von Regionen konfigurieren oder einige Regionen ausschließen. Weitere Informationen zur Funktionsweise der Regionsauswahl finden Sie unter Diagnose und Problembehandlung bei der Verfügbarkeit von Azure Cosmos DB SDKs in multiregionalen Umgebungen.

    Alle Schreibvorgänge werden an den Schreibbereich Ihres Kontos weitergeleitet.

  • Regionsübergreifende Datenreplikation: Alle Schreibvorgänge treten in der primären Region Ihres Kontos auf. Schreibvorgänge werden basierend auf der konfigurierten Konsistenzstufe des Kontos in die anderen Leseregionen repliziert. Informationen zur maximalen Replikationsverzögerung finden Sie unter potenziellen Datenverlust während Regionausfällen.

Verhalten während eines Lesebereichsfehlers

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie ein Azure Cosmos DB Konto mit mehreren Lesebereichen konfigurieren, und es gibt einen Ausfall in einem der Lesebereiche des Kontos.

Von Bedeutung

Im Idealfall sollten Lesebereichsausfälle auf Clientebene behandelt werden, indem die bevorzugte Regionsliste in der SDK-Konfiguration ordnungsgemäß konfiguriert wird. Wenn das SDK ordnungsgemäß konfiguriert ist, erkennt es automatisch den Ausfall und leitet Lesevorgänge an die nächste verfügbare Region um, ohne dass ein serverseitiges Failover erforderlich ist.

  • Erkennung und Reaktion: Die Verantwortung für das Erkennen des Ausfalls und der Reaktion hängt vom Typ des Failovers ab, den Ihr Konto verwendet.

    • PPAF: PPAF gilt in der Regel nicht für Lesebereichsausfälle. Bei Konten mit starker Konsistenz und nur zwei Regionen reduziert der Verlust der Leseregion das Konto auf eine einzelne Region, die kein dynamisches Quorum beibehalten kann. In diesem Szenario kann PPAF aktiviert werden, um die Verfügbarkeit zu erhalten, indem die betroffenen Partitionen in die gesunde Region verschoben werden.

    • Erzwungenes Failover: Sie sind für die Durchführung eines erzwungenen Failovers verantwortlich. Ausführliche Schritte finden Sie unter Erzwungenes Failover für Ihr Azure Cosmos DB-Konto durchführen.

      Wenn Sie kein Failover ausführen, hängt das Verhalten Ihres Kontos von der Konsistenzstufe ab:

      • Starke Konsistenz: Eine starke Konsistenz erfordert mindestens zwei Regionen, um das dynamische Quorum beizubehalten. Wenn weniger als zwei Regionen verfügbar sind und Sie kein Failover ausführen, verliert das Konto die Schreibverfügbarkeit bis zur Wiederherstellung des Diensts.

      • Konsistenz der gebundenen Fälligkeit: Die Konsistenz der gebundenen Fälligkeit beruht auf der Aufrechterhaltung eines bestimmten Fälligkeitsschwellenwerts zwischen Regionen. Wenn die Länge des Regionsausfalls den Schwellenwert überschreitet, kann das System die Konsistenz zwischen Schreibvorgängen nicht beibehalten. Wenn Sie kein Failover ausführen, verliert das Konto die Schreibverfügbarkeit, bis die Wiederherstellung des Diensts erfolgt.

    • Serviceverwaltetes Failover: Wenn das vom Dienst verwaltete Failover aktiviert ist, erkennt Microsoft schließlich den Ausfall und initiiert ein Failover Ihres Kontos. Dieser Vorgang kann jedoch erhebliche Zeit in Anspruch nehmen, z. B. eine Stunde oder mehr. Führen Sie für eine schnellere Wiederherstellung ein erzwungenes Failover aus, anstatt auf das auslösende Vom Dienst verwaltete Failover zu warten.

  • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Aber:

  • Aktive Anforderungen: Alle aktiven Anforderungen können beendet werden und müssen nach Abschluss des Failovers vom Client erneut ausgeführt werden. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, indem sie nach kurzer Zeit erneut versuchen, vermeiden sie in der Regel erhebliche Auswirkungen.

  • Erwarteter Datenverlust: Ein Ausfall in einem Lesebereich verursacht keinen Datenverlust. Azure Cosmos DB berücksichtigt weiterhin Konsistenzgarantien für Lesevorgänge.

  • Erwartete Ausfallzeiten: Die Anzahl der Ausfallzeiten für Ihr Konto hängt von der Art des Failovers ab, den Ihr Konto verwendet.

    • PPAF: Wenn PPAF aktiviert ist, erkennt und wiederhergestellt das System automatisch den Fehler, in der Regel innerhalb von 3 Minuten, ohne manuelle Eingriffe.

    • Erzwungenes Failover: Ausfallzeiten hängen von:

      • Wie lange es dauert, bis Sie den Ausfall ermitteln und ein Failover initiieren.

      • Wie lange das Failover dauert, was in der Regel ein paar Sekunden dauert.

        Warnung

        Führen Sie während Ausfallszenarien keine Konfigurationsvorgänge (Steuerungsebene) für die betroffene Region aus, da sie zu Kontoinkonsistenzen und zur Verzögerung der Wiederherstellung führen. Einige Beispiele für Vorgänge der Steuerungsebene, die vermieden werden sollen, sind:

        • Ändern des Schreibbereichs oder Ändern der Failoverpriorität
        • Aktualisieren des Kontos auf die Konfiguration mit mehreren Schreibvorgängen
        • Aktualisieren von Konsistenzstufen oder anderen Kontoeinstellungen
        • Aktualisieren von Konfigurationen für private Endpunkte oder Netzwerkeinstellungen
        • Aktualisieren von Kontodurchsatz- oder Skalierungsvorgängen
        • Alle anderen Vorgänge, die die Kontokonfigurations- oder Regionseinstellungen ändern

    • Serviceverwaltetes Failover: Microsoft ist für das Initiieren eines vom Dienst verwalteten Failovers verantwortlich, und die Ausfallzeiten, die Ihre Kontoerfahrungen verursachen, basieren auf der Zeit, die Microsoft zum Deklarieren des Ausfalls und Initiieren des Failovers benötigt. In einigen Situationen kann es eine Stunde oder mehr dauern. Wenn bei Ihrem Konto Unterbrechungen beim Schreiben auftreten und Sie die Schreibverfügbarkeit schnell wiederherstellen müssen, führen Sie ein erzwungenes Failover aus.

  • Umverteilung: Bei erzwungenem Failover oder vom Dienst verwaltetem Failover wird die betroffene Region getrennt und als offline gekennzeichnet.

    Zur Verarbeitung von Ausfällen von Leseregionen sind keine Änderungen an Ihrem Anwendungscode erforderlich. Die Azure Cosmos DB SDKs umleiten Lesevorgänge an die nächste verfügbare Region in der Liste der bevorzugten Regionen. Wenn keine der Regionen in der bevorzugten Regionsliste verfügbar ist, fallen Lesevorgänge automatisch auf den aktuellen Schreibbereich des Kontos zurück, wie im Dienst konfiguriert.

    Hinweis

    Wenn Sie private Endpunkte mit einem Azure Cosmos DB-Konto verwenden, stellen Sie sicher, dass das private DNS nach der Offline-Region-Operation ordnungsgemäß weitergeleitet wird. Ausführliche Anweisungen finden Sie unter Überlegungen zum Failover für private Endpunkte.

Verhalten während eines Schreibbereichsfehlers

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie ein Azure Cosmos DB Konto mit mehreren Lesebereichen konfigurieren, und es gibt einen Ausfall im Schreibbereich des Kontos.

  • Erkennung und Reaktion: Die Verantwortung für das Erkennen des Ausfalls und der Reaktion hängt vom Typ des Failovers ab, den Ihr Konto verwendet.

    • PPAF: Microsoft erkennt den Ausfall automatisch und initiiert ggf. ein Failover einiger Partitionen. Ihre Anwendung muss keine Maßnahmen ergreifen.

    • Erzwungenes Failover: Sie sind für die Durchführung eines erzwungenen Failovers verantwortlich. Ausführliche Schritte finden Sie unter Erzwungenes Failover für Ihr Azure Cosmos DB-Konto durchführen.

      Wenn Sie kein Failover ausführen, verliert das Konto die Schreibverfügbarkeit, bis die Wiederherstellung des Diensts erfolgt.

      Wenn es einen Ausfall der Schreibregion Ihres Kontos gibt, vermeiden Sie das Ausführen einer Änderung der Schreibregion-Operation. Schreibbereichsänderungen gelingen nicht bei einem Ausfall der Quell- oder Zielregion. Der Grund dafür ist, dass das Regionsänderungsverfahren eine Konsistenzüberprüfung enthält, die eine Verbindung zwischen den Regionen erfordert.

    • Serviceverwaltetes Failover: Microsoft erkennt automatisch den Ausfall und initiiert ein Failover Ihres Kontos. Ihre Anwendung muss keine Maßnahmen ergreifen.

  • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Aber:

  • Aktive Anforderungen: Alle aktiven Anforderungen können beendet werden und müssen nach Abschluss des Failovers vom Client erneut ausgeführt werden. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, indem sie nach kurzer Zeit erneut versuchen, vermeiden sie in der Regel erhebliche Auswirkungen.

  • Erwarteter Datenverlust: Wenn Sie Ihr Konto mit starker Konsistenz konfigurieren, tritt kein Datenverlust auf. Andernfalls könnten alle unrepplizierten Schreibvorgänge nach Abschluss des Failovers verloren gehen. Informationen zu dem maximalen Datenverlust, der während eines Regionsausfalls erwartet wird, finden Sie unter Potenziellen Datenverlust während Regionsausfällen.

  • Erwartete Ausfallzeiten: Die Anzahl der Ausfallzeiten für Ihr Konto hängt von der Art des Failovers ab, den Ihr Konto verwendet.

    • PPAF: Wenn PPAF aktiviert ist, erwarten Sie eine kurze Unterbrechung, die in der Regel etwa 3 Minuten beträgt.

    • Erzwungenes Failover: Ausfallzeiten hängen von:

      • Wie lange es dauert, bis Sie den Ausfall ermitteln und ein Failover initiieren.
      • Wie lange das Failover dauert, was in der Regel ein paar Sekunden dauert.

    Warnung

    Führen Sie bei Ausfallszenarien in der betroffenen Region keine Operationen auf Steuerungsebene durch, da diese zu Kontoinkonsistenzen und zur Verzögerung der Wiederherstellung führen. Einige Beispiele für Vorgänge der Steuerungsebene, die vermieden werden sollen, sind:

    • Ändern des Schreibbereichs oder Ändern der Failoverpriorität
    • Aktualisieren des Kontos auf die Konfiguration mit mehreren Schreibvorgängen
    • Aktualisieren von Konsistenzstufen oder anderen Kontoeinstellungen
    • Aktualisieren von Konfigurationen für private Endpunkte oder Netzwerkeinstellungen
    • Aktualisieren von Kontodurchsatz- oder Skalierungsvorgängen
    • Alle anderen Vorgänge, die die Kontokonfigurations- oder Regionseinstellungen ändern
    • Serviceverwaltetes Failover: Microsoft ist für das Initiieren eines vom Dienst verwalteten Failovers verantwortlich, und die Ausfallzeiten, die Ihre Kontoerfahrungen verursachen, basieren auf der Zeit, die Microsoft zum Deklarieren des Ausfalls und Initiieren des Failovers benötigt. In einigen Situationen kann es eine Stunde oder mehr dauern. Führen Sie ein erzwungenes Failover aus, um die Verfügbarkeit von Schreibvorgängen schnell wiederherzustellen.

  • Umverteilung: Die Umverteilung des Schreibdatenverkehrs hängt vom Typ des Failovers ab, den Ihr Konto verwendet.

    • PPAF: Azure Cosmos DB schaltet automatisch die fehlerhafte Partition in eine gesunde Region um.

    • Erzwungenes Failover: Wenn Sie ein erzwungenes Failover ausführen, ändert sich der Schreibbereich Ihres Kontos in der von Ihnen angegebenen Region.

    Hinweis

    Wenn Sie private Endpunkte mit einem Azure Cosmos DB-Konto verwenden, stellen Sie sicher, dass das private DNS nach der Offline-Region-Operation ordnungsgemäß weitergeleitet wird. Ausführliche Anweisungen finden Sie unter Überlegungen zum Failover für private Endpunkte.

    • Serviceverwaltetes Failover: Azure Cosmos DB befördert automatisch eine der sekundären Regionen des Kontos zur neuen primären Schreibregion. Das Failover erfolgt in eine andere Region in der Reihenfolge der von Ihnen festgelegten Regionenpriorität.

Region-Wiederherstellung

Microsoft muss eine Region wieder online bringen. Wenn eine Region nach einem Ausfall wiederhergestellt wird, bringt Microsoft die Region automatisch online. Dieser Vorgang kann jedoch mehrere Tage dauern.

Von Bedeutung

Nach einem erzwungenen Failover bringt Microsoft die Region für gesunde Regionen automatisch wieder online. Wenn die Region innerhalb eines oder zweier Tage nicht wieder online kommt, öffnen Sie einen Supportfall, um Unterstützung anzufordern.

Nachdem die Region online ist, unterscheiden sich die aktionen, die Sie ausführen, je nachdem, ob sich der Ausfall in einem Lesebereich oder in einem Schreibbereich befand.

  • Nach Lesebereichsausfällen: Wenn die betroffene Region wieder online ist, wird sie mit dem aktuellen Schreibbereich synchronisiert und steht erneut zur Verfügung, um Leseanforderungen zu verarbeiten, nachdem sie vollständig erfasst wurde. 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.

  • Nach Ausfällen der Schreibregion: Wenn die betroffene Region wieder online ist, wird sie im Azure-Portal als "online" angezeigt und steht als Lese-Region zur Verfügung. An diesem Punkt ist es sicher, den Schreibbereich wieder in den wiederhergestellten Bereich zu ändern.

    Von Bedeutung

    Die wiederhergestellte Region wird nicht automatisch wieder zur Schreibregion zurückgesetzt, sobald sie wiederhergestellt wird. Es liegt in Ihrer Verantwortung, als Schreibbereich wieder in die wiederhergestellte Region zu wechseln, sobald dies sicher ist.

    Es gibt keine Datenverluste oder Verfügbarkeitsverluste vor, während oder nachdem Sie den Schreibbereich geändert haben. Ihre Anwendung ist weiterhin hochverfügbar.

    Falls irgendwelche Schreibvorgänge nicht repliziert wurden, bevor die Region offline geschaltet wurde, können Sie die nicht replizierten Schreibvorgänge aus dem Konfliktfeed lesen. Ihre Anwendung kann den Konfliktfeed lesen, konflikte basierend auf anwendungsspezifischer Logik lösen und die aktualisierten Daten nach Bedarf in den Container zurückschreiben.

Test auf Regionsfehler

Ihre Anwendung behandelt möglicherweise keine regionalen Failover ordnungsgemäß, auch wenn Ihr Azure Cosmos DB Konto hoch verfügbar ist. 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 forced Failover mithilfe von PowerShell, dem Azure CLI oder dem Azure Portal auf, und überwachen Sie die Anwendung. Nachdem Sie den Test abgeschlossen haben, können Sie den Failover auf die primäre Region zurücksetzen, sobald die Region automatisch wieder online ist, und dann das vom Dienst verwaltete Failover für das Konto wiederherstellen. Wenn die Region innerhalb ein oder zwei Tagen nicht wieder online kommt, öffnen Sie einen Supportfall, um Hilfe anzufordern.

Wenn Ihr Konto PPAF verwendet, können Sie ein Partitionsfailover simulieren. Weitere Informationen finden Sie unter Testen des PPAF-Setups (Simulieren des Fehlers).

Mehrere Schreibregionen

Sie können Azure Cosmos DB so konfigurieren, dass Schreibvorgänge in mehreren Regionen akzeptiert werden. Diese Konfiguration kann eine sehr hohe Ausfallsicherheit für Ausfälle in Regionen bieten. Es ist auch nützlich, die Schreiblatenz in geografisch verteilten Anwendungen zu reduzieren.

Diagramm mit einem Azure Cosmos DB Konto. Region A und Region B sind beide Schreib- und Lesebereiche. Eine Anwendung in Region A führt Lese- und Schreibvorgänge für das Azure Cosmos DB Konto in Region A aus. Eine Anwendung in Region B führt Lese- und Schreibvorgänge für das Azure Cosmos DB Konto in Region B durch. Intern repliziert Azure Cosmos DB asynchron Änderungen zwischen den Regionen.

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

Es ist wichtig, den Entwurf Ihrer Anwendung und ihre Funktionsweise mit mehreren Schreibbereichen zu berücksichtigen. Überprüfen Sie die bewährten Methoden für Schreibvorgänge mit mehreren Regionen.

Requirements

Region support: Sie können jede Azure Region als Lese- oder Schreibbereich für Ihr Azure Cosmos DB Konto konfigurieren.

Cost

Durch das Hinzufügen eines zusätzlichen Schreibbereichs zu einem Azure Cosmos DB Konto werden ihre vorhandenen Kosten für jede Region erhöht. Weitere Informationen finden Sie unter Azure Cosmos DB – Preise.

Konfigurieren mehrerer Schreibbereiche

Sie können mehrere Schreibbereiche für Ihr Konto konfigurieren, wenn Sie das Konto erstellen oder jederzeit, nachdem das Konto erstellt wurde. Weitere Informationen finden Sie unter Konfigurieren mehrerer Schreibbereiche.

Um mehrere Schreibbereiche effektiv zu verwenden, muss Ihre App auch entsprechend konfiguriert werden. Weitere Informationen finden Sie unter Multi-Region-Schreibvorgänge in Anwendungen, die Azure Cosmos DB nutzen, konfigurieren.

Kapazitätsplanung und -verwaltung

Wenn Ihre Anwendung Anforderungen über Regionen verteilt und eine Region offline geht, wird in den verbleibenden Regionen ein höheres Anforderungsvolumen angezeigt. Verwenden Sie die automatische Skalierung des Durchsatzes, um die Kapazität dynamisch basierend auf der Nachfrage anzupassen. Wenn Sie den bereitgestellten Durchsatz verwenden, planen Sie eine angemessene Kapazität, um den Verlust einer Region ohne Dienstbeeinträchtigung zu bewältigen, und erwägen Sie die Überbereitstellung. Weitere Informationen finden Sie unter Verwalten der Kapazität mit Überbereitstellung.

Verhalten, wenn alle Regionen funktionsfähig sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie ein Azure Cosmos DB Konto mit mehreren Schreibbereichen konfigurieren, und alle Regionen sind betriebsbereit.

Verhalten während eines Regionenausfalls

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn Sie ein Azure Cosmos DB Konto mit mehreren Schreibbereichen konfigurieren, und es gibt einen Ausfall in einem der Lese- oder Schreibbereiche des Kontos.

  • Erkennung und Reaktion: Ihre Anwendung erkennt den Verlust der Region. Azure Cosmos DB SDKs bieten automatische Regionsauswahlfunktionen, die Lese- und Schreibvorgänge an fehlerfreie Regionen weiterleiten.

  • Benachrichtigung: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Region abfällt. Aber:

  • Aktive Anforderungen: Alle aktiven Anforderungen können beendet werden und müssen nach Abschluss des Failovers vom Client erneut ausgeführt werden. Wenn Ihre Clients vorübergehende Fehler angemessen behandeln, indem sie nach kurzer Zeit erneut versuchen, vermeiden sie in der Regel erhebliche Auswirkungen.

  • Erwarteter Datenverlust: Kürzlich aktualisierte Daten sind in anderen Regionen möglicherweise nicht verfügbar. Informationen zu dem maximalen Datenverlust, der während eines Regionsausfalls erwartet wird, finden Sie unter Potenziellen Datenverlust während Regionsausfällen. Im unwahrscheinlichen Fall, dass die betroffene Region permanenten Datenverlust erleidet, könnten nicht replizierte Daten verloren gehen.

  • Erwartete Ausfallzeiten: Es gibt keine erwarteten Ausfallzeiten in Konfigurationen mit mehreren Schreibvorgängen, vorausgesetzt, SDKs sind ordnungsgemäß konfiguriert mit ApplicationRegions oder PreferredRegions.

    Tipp

    Um optimale Ergebnisse zu erzielen, sollten global verteilte Anwendungen von einem globalen Lastenausgleichsdienst wie Azure Front Door oder Azure Traffic Manager bereitgestellt werden. Diese Dienste können regionale Beeinträchtigungen erkennen und den Datenverkehr automatisch an Anwendungsinstanzen in einer fehlerfreien Region weiterleiten.

  • Redistribution: Die Azure Cosmos DB-SDKs erkennen automatisch, dass die Region fehlerhaft ist und Lese- und Schreibvorgänge an die nächste verfügbare Region in der Liste der bevorzugten Regionen umleitet. Im Anwendungscode sind keine Änderungen erforderlich.

    Tipp

    Wenn Ihre Anwendung von Azure Front Door oder Traffic Manager bereitgestellt wird, erkennen diese Dienste auch regionale Beeinträchtigungen und leiten den Datenverkehr an eine gesunde Region weiter.

Region-Wiederherstellung

Wenn die betroffene Region wieder online ist, wird die Region im Azure-Portal als "online" angezeigt und wieder verfügbar.

Die Schreibdaten, die nicht repliziert wurden, als der Bereich fehlgeschlagen ist, werden ü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.

Test auf Regionsfehler

Um Failoverszenarien mit mehreren Regionen zu testen, können Sie mithilfe eines erzwungenen Failovers einen Schreibbereich offline schalten. Dieser Vorgang simuliert einen Regionsausfall, und Sie können beobachten, wie Ihre Anwendung reagiert.

Sichern und Wiederherstellen

Für die meisten Lösungen sollten Sie sich nicht ausschließlich auf Sicherungen verlassen. Verwenden Sie stattdessen die in diesem Handbuch beschriebenen anderen Funktionen, um Ihre Resilienzanforderungen zu unterstützen. Sicherungen schützen jedoch vor einigen Risiken, die andere Ansätze nicht vermeiden. Weitere Informationen finden Sie unter Was sind Redundanz, Replikation und Sicherung?.

Datenverlust kann aufgrund versehentlicher Löschungen oder anderer Probleme in Ihrer Anwendung auftreten, die zu Datenbeschädigungen führen. Wenn Sie ein Konto für eine einzelne Region verwenden, kann es zu Datenverlust kommen, da in der Azure Cosmos DB-Region eine nicht wiederherstellbare Katastrophe auftreten könnte. Um Sie vor Datenverlust zu schützen, bietet Azure Cosmos DB eine Reihe von Sicherungs- und Wiederherstellungsfunktionen. Sie können Sicherungen und Aufbewahrung basierend auf Ihren Anforderungen an die Wiederherstellbarkeit und den Kostenanforderungen konfigurieren. Weitere Informationen finden Sie unter Onlinesicherung und bedarfsgesteuerte Wiederherstellung in Azure Cosmos DB.

Resilienz gegenüber Wartungsarbeiten an Diensten

Azure Cosmos DB verwaltet transparent alle Details einzelner Computeknoten und führt automatisch Patching und andere Arten der geplanten Wartung durch. Die Azure Cosmos DB SLAs für Verfügbarkeit und Latenz gelten für alle automatischen Wartungsvorgänge, die das System ausführt.

Service-Level-Vereinbarung

Der Service level agreement (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit jedes Diensts und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter Dienstleistungsvereinbarungen für Onlinedienste.

Azure Cosmos DB stellt SLAs für eine Reihe von Konfigurationen und Dienstmerkmalen bereit, einschließlich Verfügbarkeit, Latenz, Durchsatz und Konsistenz.

Die Verfügbarkeits-SLAs unterscheiden sich je nachdem, ob Sie eine der folgenden Produktfunktionen verwenden:

  • Bereitgestellter Durchsatz
  • Single-Region-Konto mit Unterstützung der Verfügbarkeitszone (Zonenredundanz)
  • Konten, die mehrere Lesebereiche verwenden
  • Konten, die mehrere Schreibbereiche verwenden (Geschäftskritische Ebene)

Verwandte Inhalte

  • Last updated on