Auf dieser Seite wird erläutert, wie Sie bestimmte GKE On-Prem-Komponenten für Hochverfügbarkeit (HA) und die Wiederherstellung nach Notfällen einrichten.
Hauptfunktion
GKE On-Prem wurde entwickelt, um sicherzustellen, dass Fehler so oft wie möglich in einem Funktionsbereich isoliert und Funktionen priorisiert werden, die wichtig für die Geschäftskontinuität sind.
Es gibt folgende Hauptfunktionen von GKE On-Prem:
Anwendungslebenszyklus
Bestehende Arbeitslasten können kontinuierlich ausgeführt werden. Dies ist die wichtigste Funktionalität, um die Geschäftskontinuität zu gewährleisten.
Sie können Arbeitslasten erstellen, aktualisieren und löschen. Dies ist die zweitwichtigste Funktionalität, da GKE On-Prem Arbeitslasten skalieren muss, wenn der Traffic zunimmt.
Nutzercluster-Lebenszyklus
Sie können Nutzercluster hinzufügen, aktualisieren, upgraden und löschen. Dies ist weniger wichtig, da die Möglichkeit, Nutzercluster zu modifizieren, wirkt sich nicht auf Nutzerarbeitslasten aus.
Lebenszyklus von Administratorclustern
Sie können den Administratorcluster aktualisieren und aktualisieren. Das ist am wenigsten wichtig, weil der Administratorcluster keine Nutzerarbeitslasten hostet.
Fehlermodi
Die folgenden Fehlertypen können sich auf die Leistung von GKE On-Prem-Clustern auswirken.
ESXi-Hostfehler
Ein ESXi-Host, auf dem VM-Instanzen ausgeführt werden, auf denen Kubernetes-Knoten gehostet werden, funktionieren möglicherweise nicht mehr oder werden partitioniert.
| Vorhandene Arbeitslasten | Arbeitslasten erstellen, aktualisieren und löschen | Nutzercluster-Lebenszyklus | Lebenszyklus von Administratorclustern |
|---|---|---|---|
| Mögliche Unterbrechung + automatische Wiederherstellung |
Mögliche Unterbrechung + automatische Wiederherstellung |
Automatische Unterbrechung + automatische Wiederherstellung |
Automatische Unterbrechung + automatische Wiederherstellung |
Die auf den VMs ausgeführten Pods, die vom fehlerhaften Host gehostet werden,werden unterbrochen und werden automatisch auf andere intakte VMs geplant. Wenn Nutzeranwendungen freie Arbeitslastkapazität haben und auf mehrere Knoten verteilt sind, kann die Unterbrechung von Clients, die Wiederholungsversuche implementieren, nicht beobachtet werden. |
Wenn der Hostfehler sich auf die VM der Steuerungsebene in einem Nutzercluster ohne Hochverfügbarkeit oder auf mehreren VMs einer Steuerungsebene in einem Hochverfügbarkeitsnutzercluster auswirkt, kommt es zu einer Unterbrechung. | Wenn der Hostfehler die VM der Steuerungsebene oder die Worker-VMs im Administratorcluster beeinträchtigt, kommt es zu einer Unterbrechung. | Wenn der Hostfehler die VM der Steuerungsebene im Administratorcluster beeinträchtigt, kommt es zu einer Unterbrechung. |
| vSphere HA startet die VMs automatisch auf fehlerfreien Hosts neu. | vSphere HA startet die VMs automatisch auf fehlerfreien Hosts neu. | vSphere HA startet die VMs automatisch auf fehlerfreien Hosts neu. | vSphere HA startet die VMs automatisch auf fehlerfreien Hosts neu. |
| Stellen Sie Arbeitslasten auf Hochverfügbarkeitsweise bereit, um Unterbrechungen zu minimieren. | Verwenden Sie HA-Nutzercluster, um die Möglichkeit einer Unterbrechung zu minimieren. |
VM-Fehler
Eine VM wird vielleicht unerwartet gelöscht oder ein Bootlaufwerk kann beschädigt werden. Außerdem kann eine VM aufgrund von Betriebssystemproblemen manipuliert worden.
| Vorhandene Arbeitslasten | Arbeitslasten erstellen, aktualisieren und löschen | Nutzercluster-Lebenszyklus | Lebenszyklus von Administratorclustern |
|---|---|---|---|
| Mögliche Unterbrechung + automatische Wiederherstellung |
Mögliche Unterbrechung + automatische Wiederherstellung |
Unterbrechung + automatische/manuelle Wiederherstellung |
Unterbrechung + manuelle Wiederherstellung |
Die auf den fehlgeschlagenen Worker-VMs ausgeführten Pods werden unterbrochen und sie werden von Kubernetes automatisch auf andere intakte VMs verschoben. Wenn Nutzeranwendungen freie Arbeitslastkapazität haben und auf mehrere Knoten verteilt sind, kann die Unterbrechung von Clients, die Wiederholungsversuche implementieren, nicht beobachtet werden. |
Wenn die VM der Steuerungsebene in einem Nutzercluster ohne Hochverfügbarkeit oder in mehr als einer Steuerung-VM in einem HA-Nutzercluster fehlschlägt, kommt es zu einer Unterbrechung. | Wenn die VM der Steuerungsebene oder die Worker-VMs im Administratorcluster fehlschlagen, besteht eine Unterbrechung. | Wenn die VM der Steuerungsebene im Administratorcluster fehlschlägt, kommt es zu einer Unterbrechung. |
| Die ausgefallene VM wird automatisch wiederhergestellt, wenn im Nutzercluster die automatische Knotenreparatur aktiviert ist. | Die ausgefallene VM wird automatisch wiederhergestellt, wenn die automatische Knotenreparatur im Administratorcluster aktiviert ist. | Die ausgefallene Worker-VM im Administratorcluster wird automatisch wiederhergestellt, wenn die automatische Knotenreparatur im Administratorcluster aktiviert ist. Sie müssen die fehlerhafte VM der Steuerungsebene im Administratorcluster manuell wiederherstellen. Wenn Sie Hilfe benötigen, wenden Sie sich an den Google-Support. |
Sie müssen die ausgefallene VM der Steuerungsebene im Administratorcluster manuell wiederherstellen. Wenn Sie Hilfe benötigen, wenden Sie sich bitte an den Google-Support. |
| Stellen Sie Arbeitslasten auf Hochverfügbarkeitsweise bereit, um Unterbrechungen zu minimieren. | Verwenden Sie HA-Nutzercluster, um die Möglichkeit einer Unterbrechung zu minimieren. |
Speicherfehler
Der Inhalt einer VMDK-Datei kann beschädigt sein, da sie nicht richtig ausfällt oder ein Datenspeicherfehler auftritt der zum Verlust von etcd Daten undPersistentVolumes (PVs) führt.
etcd-Fehler
| Vorhandene Arbeitslasten | Arbeitslasten erstellen, aktualisieren und löschen | Nutzercluster-Lebenszyklus | Lebenszyklus von Administratorclustern |
|---|---|---|---|
| Keine Unterbrechung | Mögliche Unterbrechung + Manuelle Wiederherstellung |
Unterbrechung + Manuelle Wiederherstellung |
Unterbrechung + Manuelle Wiederherstellung |
| Wenn der etcd-Speicher in einem Nicht-HA-Nutzercluster oder in einem etcd-Replikat in einem HA-Nutzercluster fehlschlägt, kommt es zu einer Unterbrechung. | Wenn der etcd-Speicher in einem Nicht-HA-Nutzercluster oder in einem etcd-Replikat in einem HA-Nutzercluster fehlschlägt, kommt es zu einer Unterbrechung. Wenn das etcd-Replikat in einem Administratorcluster fehlschlägt, kommt es zu einer Unterbrechung. |
Wenn das etcd-Replikat in einem Administratorcluster fehlschlägt, kommt es zu einer Unterbrechung. | |
| GKE On-Prem bietet einen manuellen Prozess zur Wiederherstellung nach einem Fehler. | GKE On-Prem bietet einen manuellen Prozess zur Wiederherstellung nach einem Fehler. | GKE On-Prem bietet einen manuellen Prozess zur Wiederherstellung nach einem Fehler. |
PV-Fehler bei der Nutzeranwendung
| Vorhandene Arbeitslasten | Arbeitslasten erstellen, aktualisieren und löschen | Nutzercluster-Lebenszyklus | Lebenszyklus von Administratorclustern |
|---|---|---|---|
| Mögliche Unterbrechung | Keine Unterbrechung | Keine Unterbrechung | Keine Unterbrechung |
Dies betrifft die Arbeitslasten, die das fehlgeschlagene PV verwenden. Stellen Sie Arbeitslasten auf Hochverfügbarkeitsweise bereit, um Unterbrechungen zu minimieren. |
Fehler beim Load-Balancer
Ein fehlgeschlagener Load-Balancers kann sich auf Nutzerarbeitslasten auswirken, die Dienste vom LoadBalancer-Typ LoadBalancer verfügbar machen.
| Vorhandene Arbeitslasten | Arbeitslasten erstellen, aktualisieren und löschen | Nutzercluster-Lebenszyklus | Lebenszyklus von Administratorclustern |
|---|---|---|---|
| Unterbrechung + Manuelle Wiederherstellung |
|||
|
Es dauert einige Sekunden, bis der Standby-Load-Balancer die VIP-Verbindung zur Administratorsteuerung wiederhergestellt. Die Dienstunterbrechung kann bei Verwendung von Seesaw bis zu zwei Sekunden betragen, bei Verwendung von F5 bis zu 300 Sekunden. Seesaw HA erkennt den Fehler automatisch und führt ein Failover zur Sicherung der Instanz durch. GKE On-Prem bietet einen manuellen Prozess zur Wiederherstellung nach einem Seesaw-Fehler. |
|||
Hochverfügbarkeit aktivieren
vSphere und GKE On-Prem bieten eine Reihe von Features, die zur Hochverfügbarkeit (HA) beitragen.
vSphere HA und vMotion
Wir empfehlen, die folgenden beiden Funktionen im vCenter-Cluster zu aktivieren, auf dem Ihre GKE On-Prem-Cluster gehostet werden:
Diese Funktionen verbessern die Verfügbarkeit und Wiederherstellung, wenn ein ESXi-Host ausfällt.
vCenter HA verwendet mehrere ESXi-Hosts, die als Cluster konfiguriert sind, um eine schnelle Wiederherstellung nach Ausfällen und eine kostengünstige HA für Anwendungen zu ermöglichen, die in virtuellen Maschinen ausgeführt werden. Wir empfehlen, Ihren vCenter-Cluster mit zusätzlichen Hosts bereitzustellen und vS HA Host-Host-Monitoring mit Host Failure Response auf Restart VMs zu aktivieren. Ihre VMs können dann bei einem ESXi-Hostfehler automatisch auf anderen verfügbaren Hosts neu gestartet werden.
vMotion ermöglicht eine reibungslose Migration von VMs von einem ESXi-Host zu einem anderen. Für die geplante Hostwartung können Sie mit der Live-Migration von vMotion die Anwendungsausfallzeiten vermeiden und Geschäftskontinuität gewährleisten.
Administratorcluster
GKE On-Prem unterstützt nicht die Ausführung mehrerer Steuerungsebenen für den Administratorcluster. Die Nichtverfügbarkeit der Administrator-Steuerungsebene hat jedoch weder Auswirkungen auf vorhandene Nutzerclusterfunktionen noch auf Arbeitslasten, die in Nutzerclustern ausgeführt werden.
In einem Administratorcluster gibt es zwei Add-on-Knoten. Wenn dieser ausfällt, kann der andere die Administratorclustervorgänge ausführen. Zur Redundanz verteilt GKE On-Prem wichtige Add-on-Dienste wie kube-dns auf beide Add-on-Knoten.
Wenn Sie in der Konfigurationsdatei des Administratorclusters antiAffinityGroups.enabled auf true setzen, erstellt GKE On-Prem automatisch vSphere-DRS-Anti-Affinitätsregeln für die Add-on-Knoten, wodurch diese verteilt werden auf zwei physische Hosts für hohe Verfügbarkeit.
Nutzercluster
Sie können HA für einen Nutzercluster aktivieren, indem Sie masterNode.replicas in der Nutzercluster-Konfigurationsdatei auf 3 setzen. Dies führt zu drei Knoten im Administratorcluster, von denen jeder eine Steuerungsebene für den Nutzercluster ausführt. Auf jedem dieser Knoten wird außerdem ein etcd-Replikat ausgeführt. Der Nutzercluster funktioniert weiterhin, solange eine Steuerungsebene und ein etcd-Quorum ausgeführt wird. Für ein etcd Quorum müssen zwei der etcd-Replikate funktionieren.
Wenn Sie antiAffinityGroups.enabled in der Konfigurationsdatei des Administratorclusters auf true setzen, erstellt GKE On-Prem automatisch vSphere-DRS-Anti-Affinitätsregeln für die drei Knoten, auf denen die Steuerungsebene des Nutzerclusters ausgeführt wird.
Dadurch werden diese VMs auf drei physische Hosts verteilt.
GKE On-Prem erstellt auch vSphere-DRS-Anti-Affinitätsregeln für die Worker-Knoten in Ihrem Nutzercluster, wodurch diese Knoten auf mindestens drei physische Hosts verteilt werden. Mehrere DRS-Anti-Affinitätsregeln werden pro Nutzercluster-Knotenpool basierend auf der Anzahl der Knoten verwendet. Dadurch wird gewährleistet, dass die Worker-Knoten Hosts finden, auf denen sie ausgeführt werden können, auch wenn die Anzahl der Hosts kleiner als die Anzahl der VMs im Nutzercluster-Knotenpool ist. Wir empfehlen, zusätzliche physische Hosts in Ihren vCenter-Cluster aufzunehmen. Sie sollten DRS außerdem so konfigurieren, dass der Vorgang vollständig automatisiert ist, damit in dem Fall, dass ein Host nicht mehr verfügbar ist, DRS automatisch VMs auf anderen verfügbaren Hosts neu starten kann, ohne gegen die Anti-Affinitätsregeln der VMs zu verstoßen.
GKE On-Prem verwaltet das spezielle onprem.gke.io/failure-domain-name-Knotenlabel, dessen Wert auf den zugrunde liegenden ESXi-Hostnamen eingestellt ist. Nutzeranwendungen, die Hochverfügbarkeit gewährleisten möchten, können podAntiAffinity-Regeln mit diesem Label als topologyKey einrichten, um sicherzustellen, dass ihre Anwendungs-Pods über verschiedene VMs sowie physische Hosts verteilt werden.
Sie können auch mehrere Knotenpools für einen Nutzercluster mit unterschiedlichen Datenspeichern und speziellen Knotenlabels konfigurieren. Ebenso können Sie Regeln vom Typ podAntiAffinity mit diesem speziellen Knotenlabel als topologyKey einrichten, um eine höhere Verfügbarkeit bei Datenspeicherfehlern zu erreichen.
Um HA für Nutzerarbeitslasten zu verwenden, muss der Nutzercluster eine ausreichende Anzahl von Replikaten unter nodePools.replicas haben, wodurch sichergestellt wird, dass die gewünschte Anzahl von Nutzercluster-Worker-Knoten in ausführbarem Zustand sind.
Sie können für Admincluster und Nutzercluster separate Datenspeicher verwenden, um deren Fehler zu isolieren.
Load-Balancer
Es gibt zwei Arten von Load-Balancern, die Sie für Hochverfügbarkeit verwenden können.
Gebündelter Seesaw-Load-Balancer
Für den Bundle-Seesaw-Load-Balancer können Sie HA aktivieren, indem Sie loadBalancer.seesaw.enableHA in der Cluster-Konfigurationsdatei auf true setzen.
Sie müssen auch eine Kombination aus MAC-Lernen, gefälschten Übertragungen und promiscous-Modus in Ihrer Load-Balancer-Portgruppe aktivieren.
Bei HA werden zwei Load-Balancer im Aktiv-Passiv-Modus eingerichtet. Wenn der aktive Load-Balancer ein Problem hat, schlägt der Traffic auf den passiven Load-Balancer um.
Während des Upgrades eines Load-Balancers kommt es zu Ausfallzeiten. Wenn für den Load-Balancer Hochverfügbarkeit aktiviert ist, beträgt die maximale Ausfallzeit zwei Sekunden.
Integrierter F5-BIG-IP-Load-Balancer
Die F5 BIG-IP-Plattform bietet verschiedene Dienste, mit denen Sie die Sicherheit, Verfügbarkeit und Leistung Ihrer Anwendungen verbessern können. Für GKE On-Prem bietet BIG-IP externen Zugriff und L3/4-Load-Balancing-Dienste.
Weitere Informationen finden Sie unter BIG-IP-Hochverfügbarkeit.
Defekten Cluster wiederherstellen
In den folgenden Abschnitten wird beschrieben, wie Sie einen fehlerhaften Cluster wiederherstellen.
Wiederherstellung nach ESXi-Hostfehlern
GKE On-Prem benötigt vSphere HA, um die Wiederherstellung nach einem ESXi-Hostfehler zu ermöglichen. vSphere HA kann kontinuierlich ESXi-Hosts überwachen und die VMs bei Bedarf automatisch auf anderen Hosts neu starten. Dies ist für GKE On-Prem-Nutzer transparent.
Wiederherstellung nach VM-Fehlern
Zu den VM-Fehlern gehören:
Unerwartetes Löschen einer VM.
Beschädigung der VM-Bootlaufwerke; Beispielsweise wird ein Bootlaufwerk aufgrund von Spam-Journallogs schreibgeschützt.
VM-Bootfehler aufgrund von Problemen mit niedriger Leistung oder Problemen mit der Netzwerkeinrichtung Eine VM kann beispielsweise nicht gestartet werden, weil ihr keine IP-Adresse zugewiesen werden kann.
Docker-Overlay-Dateisystem beschädigt.
Verlust der VM zur Administratorsteuerungsebene aufgrund eines Upgradefehlers.
Probleme mit dem Betriebssystem.
Die in diesem Abschnitt beschriebenen VM-Fehler enthalten keine Beschädigung oder Verlust von Daten in den mit der VM verbundenen PV- oder etcd-Datenlaufwerken. Weitere Informationen dazu finden Sie unter Wiederherstellung nach Datenspeicherfehlern.
GKE On-Prem bietet einen automatischen Wiederherstellungsmechanismus für die Administrator-Add-on-Knoten, Steuerungsebenen für Nutzer und Nutzerknoten. Diese Funktion zur automatischen Knotenreparatur kann pro Administratorcluster und Nutzercluster aktiviert werden.
Die VM zur Administratorsteuerung ist speziell so ausgelegt, dass sie nicht von einem Kubernetes-Cluster verwaltet wird. Die Verfügbarkeit wirkt sich nicht auf die Geschäftskontinuität aus. Zur Wiederherstellung von VM-Fehlern in der Administratorsteuerung wenden Sie sich an den Google-Support.
Wiederherstellung nach Speicherfehlern
Einige Speicherfehler können durch vSphere HA und vSAN relativiert werden, ohne dass GKE On-Prem beeinträchtigt wird. Bestimmte Speicherfehler können jedoch durch die vSphere-Ebene verursacht werden, die zu Datenkorruption oder Verlust in verschiedenen GKE On-Prem-Komponenten führen.
Die zustandsorientierten Informationen zu einem Cluster und Nutzerarbeitslasten werden an folgenden Orten gespeichert:
etcd
Jeder Cluster (Administratorcluster und Nutzercluster) verfügt über eine etcd-Datenbank, in der der Status (Kubernetes-Objekte) des Clusters gespeichert wird.
PersistentVolumes
Wird sowohl von Systemkomponenten als auch von Nutzerarbeitslasten verwendet.
Wiederherstellung nach etcd-Datenschäden oder -verlust
Etcd ist die Datenbank, die in Kubernetes zum Speichern aller Clusterstatus verwendet wird, einschließlich des Nutzeranwendungsmanifests. Die Lebenszyklusvorgänge der Anwendung würden nicht mehr funktionieren, wenn die etcd-Datenbank des Nutzerclusters beschädigt oder verloren geht. Die Lebenszyklusvorgänge des Nutzerclusters würden nicht mehr funktionieren, wenn die etcd-Datenbank des Administratorclusters beschädigt oder verloren geht.
etcd bietet keinen zuverlässigen integrierten Mechanismus zur Erkennung von Datenkorruption. Sehen Sie sich die Logs der etcd-Pods an, wenn Sie vermuten, dass die etcd-Daten beschädigt sind oder verloren gegangen.
Wenn ein etcd Pod mit dem Status "pending/error/crashe loop" nicht immer beschädigt ist, bedeutet das nicht, dass die etcd-Daten beschädigt sind oder verloren gehen. Dies kann an den Fehlern auf den VMs liegen, auf denen die etcd-Pods gehostet werden. Sie sollten die etcd-Wiederherstellung nur für Datenkorrelation oder Verlust durchführen.
Damit Sie in einem früheren Clusterstatus Daten durch beschädigte oder beschädigte Daten wiederherstellen können, müssen die etcd-Daten nach jedem Lebenszyklusvorgang im Cluster gesichert werden (z. B. Erstellen, Aktualisieren oder Aktualisieren). , um die Option zu aktivieren. Informationen zum Sichern der etcd-Daten finden Sie unter Administratorcluster sichern und Nutzercluster sichern.
Durch die Wiederherstellung von etcd-Daten wird der Cluster in einen früheren Zustand gesetzt. Wenn also eine Sicherung vor der Bereitstellung einer Anwendung erstellt und dann zur Sicherung des Clusters verwendet wird, wird die Anwendung nicht im wiederhergestellten Cluster ausgeführt. Wenn Sie beispielsweise den etcd-Snapshot eines Administratorclusters verwenden, der vor dem Erstellen eines Nutzerclusters Snapshot erstellt wurde, wird die Steuerungsebene des Nutzerclusters im wiederhergestellten Administratorcluster entfernt. Daher empfehlen wir, den Cluster nach jedem kritischen Clustervorgang zu sichern.
Die etcd-Datenkorrelation/Verluste können in den folgenden Szenarien auftreten:
Ein einzelner Knoten eines etcd-Clusters (drei Nutzer) wird aufgrund von Datenkorruption oder Verlust dauerhaft heruntergefahren. In diesem Fall ist nur ein einzelner Knoten fehlerhaft und das etcd-Quorum ist noch vorhanden. Dies kann in einem HA-Cluster geschehen, in dem die Daten eines der etcd-Replikate beschädigt oder verloren gehen. Das Problem kann ohne Datenverlust behoben werden, indem das fehlerhafte etcd-Replikat im neuen Zustand durch ein neues ersetzt wird.
Zwei Knoten eines etcd-Clusters (drei Nutzercluster) werden aufgrund von Datenfehler oder Verlusten dauerhaft beschädigt. Das Quorum geht verloren, sodass das Ersetzen der fehlgeschlagenen etcd-Replikate durch neue ersetzt werden kann. Der Clusterstatus muss aus Sicherungsdaten wiederhergestellt werden. Weitere Informationen finden Sie unter Nutzercluster aus einer Sicherung (HA) wiederherstellen.
Ein etcd-Cluster mit einem Knoten (Administratorcluster oder Nicht-HA-Nutzercluster) wird aufgrund von Datenkorruption oder Verlust dauerhaft entfernt. Das Quorum geht verloren, daher müssen Sie einen neuen Cluster aus der Sicherung erstellen. Weitere Informationen finden Sie unter Nutzercluster aus einer Sicherung (nicht-HA) wiederherstellen.
Wiederherstellung nach Datenverlust oder Verlust der Nutzeranwendung
GKE On-Prem-Kunden können bestimmte Partnerspeicherlösungen verwenden, um PersistentVolumes von Nutzeranwendungen zu sichern und wiederherzustellen.
Eine Liste der Speicherpartner, die für GKE On-Prem qualifiziert sind, finden Sie unter Anthos-Ready-Speicherpartner.
Wiederherstellung nach Load-Balancer-Fehlern
Für das gebündelte Load-Balancing (Seesaw) können Sie den Fehler beheben, indem Sie den Load-Balancer neu erstellen. Um den Load-Balancer neu zu erstellen, führen Sie ein Upgrade der Seesaw auf dieselbe Version durch, wie unter Upgrade des Load-Balancers für Ihren Administratorcluster ausführen beschrieben.
Wenn Fehler beim Load-Balancer des Administratorclusters auftreten, ist die Steuerungsebene möglicherweise nicht erreichbar. Das bedeutet, dass Sie das Upgrade auf der Administrator-VM ausführen müssen, auf der der Zugriff auf Steuerungsebene möglich ist.
Informationen zu integrierten Load-Balancern (F5) erhalten Sie vom F5-Support.
Mehrere Cluster für die Notfallwiederherstellung verwenden
Wenn Sie Anwendungen in mehreren Clustern auf mehreren vCenters oder Anthos-Plattformen bereitstellen, können Sie während globaler Ausfälle eine höhere globale Verfügbarkeit erzielen und den Extremradius begrenzen.
Bei dieser Konfiguration wird der vorhandene Anthos-Cluster im sekundären Rechenzentrum zur Notfallwiederherstellung verwendet, anstatt einen neuen Cluster einzurichten. Das geht in der folgenden Zusammenfassung:
Erstellen Sie im sekundären Rechenzentrum einen weiteren Administratorcluster und einen weiteren Nutzercluster. In dieser Multi-Cluster-Architektur müssen Nutzer zwei Administratorcluster in jedem Rechenzentrum haben und jeder Administratorcluster einen Nutzercluster ausführen.
Der sekundäre Nutzercluster hat eine minimale Anzahl von Worker-Knoten (drei) und ist dabei ein Hot-Standby.
Anwendungsbereitstellungen können über die beiden vCenters mithilfe von Anthos Config Management repliziert werden. Der bevorzugte Ansatz besteht darin, eine vorhandene DevOps-Toolchain (CI/CD, Spinnaker) zu verwenden.
Im Notfall kann der Nutzercluster auf die Anzahl der Knoten skaliert werden.
Außerdem ist ein DNS-Switchover erforderlich, um Traffic zwischen den Clustern an das sekundäre Rechenzentrum zu leiten.