Zuverlässigkeit in Azure Operator Nexus
Wichtig
Diese Funktion steht derzeit als Vorschau zur Verfügung. Vorschauversionen werden Ihnen zur Verfügung gestellt, wenn Sie die zusätzlichen Nutzungsbedingungen akzeptieren.
In diesem Artikel wird die Zuverlässigkeitsunterstützung in Azure Operator Nexus beschrieben und die intraregionale Resilienz mittels Verfügbarkeitszonen behandelt. Eine ausführlichere Übersicht über die Zuverlässigkeit in Azure finden Sie unter Azure-Zuverlässigkeit.
Unterstützung für Verfügbarkeitszonen
Azure-Verfügbarkeitszonen sind mindestens drei physisch getrennte Gruppen von Rechenzentren innerhalb jeder Azure-Region. Die Rechenzentren innerhalb jeder Zone sind mit unabhängiger Stromversorgung, Kühlung und Netzwerkinfrastruktur ausgestattet. Bei einem Fehler in der lokalen Zone sind Verfügbarkeitszonen so konzipiert, dass regionale Dienste, Kapazität und Hochverfügbarkeit von den verbleibenden beiden Zonen unterstützt werden, wenn eine Zone betroffen ist.
Ausfälle können von Software- und Hardwareausfällen bis hin zu Ereignissen wie Erdbeben, Überflutungen und Bränden reichen. Fehlertoleranz wird durch Redundanz und logische Isolierung von Azure-Diensten erreicht. Ausführlichere Informationen zu Verfügbarkeitszonen in Azure finden Sie unter Regionen und Verfügbarkeitszonen.
Azure-Dienste mit Unterstützung von Verfügbarkeitszonen bieten das richtige Maß an Zuverlässigkeit und Flexibilität. Für die Konfiguration gibt es zwei Möglichkeiten. Sie können entweder zonenredundant mit automatischer zonenübergreifender Replikation oder zonenbasiert mit Instanzen sein, die an eine bestimmte Zone angeheftet werden. Sie können diese Ansätze auch kombinieren. Weitere Informationen zur zonalen im Vergleich zur zonenredundanten Architektur finden Sie unter Empfehlungen für die Verwendung von Verfügbarkeitszonen und Regionen.
Azure Operator Nexus bietet standardmäßig Bereitstellungen mit Verfügbarkeitszonenredundanz. Operator Nexus-Komponenten wie Cluster Manager und Network Fabric Controller werden alle in einem AKS-Cluster (Azure Kubernetes Service) bereitgestellt, der Verfügbarkeitszonen verwendet. Andere Dienstabhängigkeiten, z. B. Storage Account Service und KeyVault, werden ebenfalls mit Verfügbarkeitszonenredundanz konfiguriert.
Hinweis
Operator Nexus On-Premises-Instanz implementiert ein Multi-Rack-Design, das physische Redundanz auf allen Ebenen des Stapels bietet. Jedes Rack ist als Fehlerdomäne oder Nexus-Zone konzipiert. Kundenworkloads können über mehrere Racks/Knoten hinweg bereitgestellt werden, was im Wesentlichen der Verwendung von Multiverfügbarkeitszonen ähnelt.
Ausgefallene Azure-Verfügbarkeitszonen
Bei Ausfall einer Verfügbarkeitszone funktionieren Cluster-API-Aufrufe und Ressourcenanbieter weiterhin ohne Unterbrechung. Es gäbe keine Auswirkungen auf derzeit ausgeführte lokale Mandantenworkloads oder auf die Möglichkeit, neue Mandantenworkloads zu erstellen. Außerdem sollte kein Datenverlust auftreten, da die Resilienz von Operator Nexus und anderen Ressourcentypen gewährleistet wird.
Failover-Unterstützung für Azure-Verfügbarkeitszonen
Bei Ausfall einer Verfügbarkeitszone wird automatisch und ohne Benutzerinteraktion eine Verbindung mit einer anderen Azure-Verfügbarkeitszone hergestellt.
Verfügbarkeit von Operator Nexus-Instanz-Bereitstellungen
Die Sicherstellung der Verfügbarkeit in den Azure Operator Nexus-Workloadbereitstellungen ist eine geteilte Aufgabe. Wie im vorherigen Abschnitt beschrieben, werden die AKS-basierten Operator Nexus-Ressourcen mit Verfügbarkeitszonenredundanz bereitgestellt. In diesem Abschnitt werden bewährte Methoden bezüglich der Verfügbarkeit lokaler Workloads behandelt.
Im Allgemeinen lassen sich Verfügbarkeitsziele durch lokale und georedundante Bereitstellungen erreichen.
Nexus-Zone: Ein Mechanismus für lokale Workloadredundanz
Lokale Operator Nexus-Instanzen bestehen aus einem Multi-Rack-Design, das physische Redundanz auf allen Ebenen des Stapels bietet. Jedes Rack wird als Fehlerdomäne festgelegt und kann daher als Nexus-Zone konfiguriert werden, in der diese Zonen für lokale redundante Workloadbereitstellungen verwendet werden können und vorzugsweise verwendet werden sollten.
Nexus-Instanz: Ein Mechanismus für die Geoworkloadredundanz
Die lokalen Nexus-Instanzen werden in einer bestimmten Azure-Region gehostet. Wie bereits erwähnt, werden die verwendeten Azure-Dienste und Nexus-Ressourcen in mehreren Verfügbarkeitszonen dieser Azure-Region bereitgestellt.
Um Workloads georedundant bereitzustellen, sollten Nexus-Instanzen, die geografisch verteilt sind, d. h. nicht im selben Betreiberrechenzentrum (möglicherweise nicht einmal in derselben geografischen Region) und in verschiedenen Azure-Regionen gehostet werden, verwendet werden.
Warnung
Die Bereitstellung von Workloads auf zwei geografisch verteilten Nexus-Instanzen reicht nicht aus, um echte Georedundanz zu erreichen, es sei denn, die georedundanten Nexus-Instanzen werden in verschiedenen Azure-Regionen gehostet.
Im unwahrscheinlichen Fall, dass eine Azure-Region nicht mehr verfügbar ist, sind auch die Azure-Dienste sowie die Nexus-Ressourcen in dieser Region nicht verfügbar. Dies wirkt sich zwar nicht auf ausgeführte Workloads aus, verhindert jedoch Funktionen wie das Starten neuer Workloads, Analysen usw.
Mehrere Nexus-Instanzen am selben geografischen Standort
Es gibt Szenarien, in denen mehrere Nexus-Instanzen am selben geografischen Standort bereitgestellt werden müssen. Workload-Georedundanz wird offensichtlich nicht erreicht, indem Workloads auf Nexus-Instanzen am selben geografischen Standort bereitgestellt werden.
Abgesehen von der Verfügbarkeit sind beim Aufbau von zuverlässigen Strukturen zwei weitere Aspekte zu beachten: Resilienz und die Fähigkeit zur Wiederherstellung nach Fehlern. Die Wiederherstellung nach Fehlern und die Fähigkeit, Wiederherstellungszeitvorgaben (Recovery Time Objective; RTO) zu erreichen, erfordert eine Begrenzung des Schadens- bzw. Auswirkungsradius von Fehlern. Wenn mehrere Nexus-Instanzen am gleichen geografischen Standort bereitgestellt werden, müssen diese Nexus-Instanzen in verschiedenen Azure-Regionen gehostet werden, damit Resilienz gewährleistet ist. Wenn eine Azure-Region ausfällt, sind die Auswirkungen dadurch auf eine Nexus-Instanz beschränkt.