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.
Azure Cosmos DB funktioniert anders als viele andere Azure-Dienste, wenn es um Konfigurationen mit hoher Verfügbarkeit geht. Anstatt sich auf eine sekundäre Instanz zu verlassen, die vom Kunden zur Resilienz bereitgestellt wird, werden Azure Cosmos DB-Konten mit einer Mehrregionseinrichtung konfiguriert, die Daten aktiv in ausgewählten Regionen repliziert. Während eines regionalen Ausfalls kann ein Failover zu einer anderen Region initiiert werden, um die Verfügbarkeit aufrechtzuerhalten.
Wenn ein Azure Cosmos DB-Konto fehlschlägt, bleibt der Dienstname unverändert. Wenn der öffentliche Endpunkt für die Konnektivität verwendet wird, können Systeme unabhängig vom Failoverstatus weiterhin über dieselbe DNS-Auflösung auf den Dienst zugreifen. Die DNS-Auflösung funktioniert nahtlos, auch wenn nur eine Region oder eine Teilmenge von Diensten von einem Ausfall betroffen ist. Diese integrierte Resilienz reduziert die Anzahl der Aufgaben für Geschäftskontinuität und Notfallwiederherstellung (BCDR), die für Azure Cosmos DB erforderlich sind.
Für Kunden, die private Endpunkte verwenden, ist eine zusätzliche Konfiguration erforderlich, um die Failoverunterstützung sicherzustellen. Dieses Dokument enthält eine Beispielarchitektur eines Azure Cosmos DB-Kontos, das private Endpunkte für sichere Netzwerkverbindungen nutzt, und beschreibt die erforderlichen Schritte für verschiedene BCDR-Szenarien.
Beispiel Architektur
Diese Architektur verwendet primäre und sekundäre Regionen, um sowohl aktiv/aktiv als auch aktiv/passiv für Failoverszenarien zu unterstützen. Jede Region enthält ein Netzwerk, in dem das Azure Cosmos DB-Konto und andere Workload-Lösungen bereitgestellt werden. Das Azure Cosmos DB-Konto mit mehreren Regionen verfügt über private Endpunkte in beiden Regionen, um eine nahtlose Konnektivität sicherzustellen. Mit diesem Setup können Anwendungen eine Verbindung mit dem nächstgelegenen privaten Endpunkt herstellen und dabei die Leistung optimieren und während eines Failoverereignisses Resilienz beibehalten.
Die beiden privaten Endpunkte können nicht dieselbe private DNS-Zone für denselben Endpunkt verwenden. Daher verfügt jede Region über eine eigene private DNS-Zone. Jede regionale Zone ist an das Hubnetzwerk für diese bestimmte Region angefügt. Dieses Design nutzt das DNS-Weiterleitungsszenario, um die Auflösung bereitzustellen. Daher steht unabhängig von der Region der virtuellen Maschine (VM), die auf den privaten Endpunkt zugreift, ein lokaler Endpunkt für die Verbindung mit Azure Cosmos DB zur Verfügung. Für Verbindungen, die aus einem Rechenzentrum stammen, würde eine VPN-Verbindung mit dem Hubnetzwerk in der jeweiligen Region hergestellt.
Um DNS-Auflösungen zu gewährleisten, konfiguriert jedes Rechenzentrum eine bedingte Weiterleitung zu einer der beiden DNS-Resolver-Servergruppen. Dadurch wird sichergestellt, dass die Auflösung am nächstgelegenen Netzwerkstandort erfolgt, um eine optimale Konnektivität zu gewährleisten.
Architekturkonzepte
Azure Cosmos DB unterstützt mehrere private Endpunkte pro Konto, sodass Sie regional verteilte Endpunkte über verschiedene virtuelle Netzwerke hinweg erstellen können. So könnten Sie beispielsweise einen privaten Azure Cosmos DB-Endpunkt in beiden Regionen haben, wobei jeder Datenverkehr unabhängig vom jeweiligen virtuellen Netzwerk bedient.
In herkömmlichen Hub-and-Spoke-Topologien ist dieses Setup aufgrund von Einschränkungen der privaten DNS-Zone weniger häufig – jede Zone kann nur einen Eintrag pro DNS-Namen enthalten. Sobald Sie einen privaten Endpunkt mit einer privaten DNS-Zone verknüpfen, müssen alle zusätzlichen Endpunkte in anderen Regionen separate private DNS-Zonen verwenden, um DNS-Konflikte zu vermeiden.
Darüber hinaus sind private Azure Cosmos DB-Endpunkte nicht regionsgebunden. Sie können einen privaten Endpunkt in einer Region bereitstellen, um auf ein azure Cosmos DB-Konto zuzugreifen, das in einer anderen Region gehostet wird und flexible Netzwerkkonfigurationen ermöglicht.
Um eine ordnungsgemäße Auflösung sicherzustellen, sollte jede Region eine eigene regionsspezifische private DNS-Zone dem lokalen Endpunkt zugeordnet haben. Mit diesem Setup können Ressourcen in den einzelnen Regionen den Datenverkehr ordnungsgemäß weiterleiten. Während die Bereitstellung privater Endpunkte in derselben Region wie Ihr Azure Cosmos DB-Konto häufig für die Kosten- und Latenzoptimierung bevorzugt wird, kann die Unterstützung privater Endpunkte mit mehreren Regionen für hochverfügbarkeits- und regionale Failoverszenarien von entscheidender Bedeutung sein, um den fortgesetzten privaten Zugriff auch dann sicherzustellen, wenn eine Region nicht verfügbar ist.
Failoverszenarien
Diese Topologie unterstützt die folgenden Szenarien, die jeweils eigene Überlegungen zum DNS-Failover haben.
| Scenario | Description | DNS-Aspekte |
|---|---|---|
| Szenario 1 – Azure Cosmos DB-Failover | Eine Dienstunterbrechung in der primären Region erfordert, dass Azure Cosmos DB in eine sekundäre Region übergeht. | Keine Änderungen erforderlich |
| Szenario 2 – Failover für andere Dienste | Eine Dienstunterbrechung wirkt sich auf andere Dienste in der primären Region aus, aber das Failover von Azure Cosmos DB ist nicht erforderlich. | Wenn sich der Ausfall auf die in der primären Region gehosteten DNS-Server auswirkt, müssen die bedingten Weiterleitungen von der lokalen Bereitstellung in die sekundäre Region aktualisiert werden. |
| Szenario 3 – Gesamter Regionsausfall | Ein großer Dienstausfall wirkt sich auf mehrere Dienste aus und erfordert ein Failover sowohl für Azure Cosmos DB als auch für andere Dienste. | Bedingte Weiterleitungen von lokalem DNS müssen in die sekundäre Region aktualisiert werden. |
| Szenario 4 – Konfiguration mit mehreren Schreibvorgängen | Azure Cosmos DB und andere Dienste arbeiten in einer aktiven/aktiven Konfiguration in mehreren Regionen. | Keine Änderungen erforderlich |
Szenario 1: Azure Cosmos DB-Notfallumschaltung
In diesem Szenario erfordert ein Problem mit dem Azure Cosmos DB-Konto, dass es auf eine sekundäre Region umgeschaltet wird. Da Azure Cosmos DB für hohe Verfügbarkeit konzipiert ist, sind regionale Ausfälle ungewöhnlich, sollten aber dennoch geplant sein.
Wenn Azure Cosmos DB erzwungenes Failover (Offlineregion) auslöst, wird ein Failover zur sekundären Region durchgeführt, wobei das Netzwerk-Routing unverändert bleibt. Es sind keine Änderungen an DNS erforderlich, jede Region verwendet weiterhin ihren lokalen privaten Endpunkt, um mit Azure Cosmos DB zu kommunizieren. Nach dem Failover (Offline-Region) wird der Dienst wie folgt ausgeführt:
Wenn die primäre Region wieder gesund ist, wird das Azure Cosmos DB-Account auf die ursprüngliche Schreibregion zurückgesetzt, ohne dass Änderungen an der Netzwerkkonfiguration erforderlich werden.
Szenario 2: Failover anderer Dienste
In diesem Szenario liegt das Problem nicht bei dem Azure Cosmos DB-Konto, sondern bei den Diensten, die eine Verbindung damit herstellen, z. B. Anwendungsdienste, virtuelle Computer oder Container. Diese Dienste müssen gemäß ihren jeweiligen Notfallwiederherstellungsplänen in eine sekundäre Region überführt werden.
Beispielsweise können virtuelle Computer Azure Site Recovery verwenden, um Workloads im Voraus zu replizieren, während Anwendungsdienste mithilfe von CI/CD-Pipelines oder plattformeigenen Skalierungsfeatures in der sekundären Region erneut bereitgestellt werden können.
Sobald die Dienste in der sekundären Region aktiv sind, können sie sofort mit der Verbindung mit Azure Cosmos DB über den lokalen regionalen privaten Endpunkt beginnen. Azure Cosmos DB erfordert keine Änderungen, um dies zu unterstützen. Die Endpunkte werden bereits bereitgestellt, um den nahtlosen Zugriff aus mehreren Regionen zu ermöglichen.
Wenn ein lokales Netzwerk über VPN verbunden ist, bleibt die Konnektivität bestehen, solange die DNS-Auflösung über den Hub funktioniert. Wenn die DNS-Infrastruktur des Hubs jedoch betroffen ist (z. B. aufgrund eines VM- oder DNS-Dienstausfalls), müssen die lokalen DNS-Weiterleitungen möglicherweise neu konfiguriert werden, um auf die DNS-Resolver der sekundären Region zu verweisen, bis die primäre Region wiederhergestellt wird.
Nach dem Failover funktionieren Dienste in der sekundären Region wie gezeigt:
Sobald die primäre Region wiederhergestellt ist, können Dienste zurückgeführt werden, und alle temporären DNS-Änderungen für lokale Systeme können rückgängig gemacht werden.
Szenario 3: Ausfall des gesamten Bereichs
In diesem Szenario gibt es einen regionalen Ausfall, der so schwerwiegend ist, dass sowohl das Azure Cosmos DB-Konto als auch die abhängigen Anwendungsdienste in eine sekundäre Region überführt werden müssen.
Dieses Failover folgt einem kombinierten Modell, das den vorherigen beiden Szenarien ähnelt: Die Azure Cosmos DB-Instanz schlägt in ihre sekundäre Schreibregion um, und Azure-Dienste (z. B. Web-Apps, VMs oder Container) werden erneut bereitgestellt oder in der sekundären Region aktiviert. Die primäre Region ist effektiv nicht funktionsfähig, aber die Architektur stellt sicher, dass Dienste weiterhin mit minimalen Unterbrechungen aus der sekundären Region ausgeführt werden.
Falls, wie in früheren Fällen, das primäre Hub-Netzwerk aufgrund eines Ausfalls der DNS-Infrastruktur nicht in der Lage ist, die DNS-Auflösung vorzunehmen, sollten die lokalen bedingten DNS-Weiterleiter vorübergehend so aktualisiert werden, dass sie Resolver in der sekundären Region verwenden, um die private Endpunktkonnektivität aufrechtzuerhalten.
Nach dem Failover funktioniert die Architektur wie gezeigt:
Sobald die primäre Region wiederhergestellt wurde, können Arbeitslasten zurückübertragen werden, und lokale DNS-Einstellungen können auf ihre ursprüngliche Konfiguration zurückgesetzt werden.
Szenario 4: Konfiguration mit mehreren Schreibvorgängen
In diesem Szenario ist Azure Cosmos DB für Schreibvorgänge mit mehreren Regionen konfiguriert, sodass sie Schreibvorgänge in mehreren Regionen gleichzeitig akzeptieren kann. Ein Ausfall tritt in einer Region auf, was sich auf lokale Anwendungsdienste auswirkt, aber Azure Cosmos DB bleibt aufgrund seiner verteilten Natur global verfügbar.
Da Multi-Write-Accounts über eigene regionale Lese-/Schreib-Endpunkte verfügen, ist kein Azure Cosmos DB-Failover erforderlich. Die Anwendung wechselt nahtlos zu einer anderen aktiven Region, in der die Dienste noch ausgeführt werden. Sie kann weiterhin mit dem regionalen privaten Endpunkt in Azure Cosmos DB lesen und schreiben. Wichtige Verhaltensweisen in diesem Szenario:
- Es ist kein Azure Cosmos DB-Failover erforderlich – die anderen Regionen verarbeiten Weiterhin Schreibvorgänge nahtlos.
- Anwendungsdienste (z. B. App Services, AKS oder VMs) werden in einer alternativen Region aktiviert oder zentral hochskaliert.
- Regionale private Endpunkte werden bereits bereitgestellt und ermöglichen eine sofortige Konnektivität ohne DNS-Änderungen.
- Lokale Clients funktionieren weiterhin, solange ihre DNS-Weiterleitungen an einen gültigen privaten Endpunkt aufgelöst werden können. Wenn DNS-Dienste in der fehlerhaften Region betroffen sind, sollten sie vorübergehend auf die DNS-Resolver in der aktiven Region verweisen.
Wenn die primäre Region wiederhergestellt wird, können Anwendungsdienste bei Bedarf fehlschlagen. Es sind keine Änderungen an Azure Cosmos DB erforderlich. Die Plattform repliziert weiterhin Daten in allen Schreibbereichen wie konfiguriert.
