Google Distributed Cloud wurde entwickelt, um das Ausmaß von Fehlern zu begrenzen und Funktionen zu priorisieren, die für die Geschäftskontinuität entscheidend sind. In diesem Dokument wird erläutert, wie die Funktionalität Ihrer Cluster im Falle eines Fehlers betroffen ist. Diese Informationen können Ihnen dabei helfen, Bereiche bei der Fehlerbehebung zu priorisieren, wenn Sie ein Problem haben.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.Zu den Hauptfunktionen von Google Distributed Cloud gehören die folgenden Kategorien:
- Arbeitslasten ausführen: Vorhandene Arbeitslasten können weiter ausgeführt werden. Dies ist der wichtigste Aspekt für die Aufrechterhaltung des Geschäftsbetriebs. Auch wenn in Ihrem Cluster ein Problem auftritt, werden die vorhandenen Arbeitslasten möglicherweise weiterhin ohne Unterbrechung ausgeführt.
- Arbeitslasten verwalten: Sie können Arbeitslasten erstellen, aktualisieren und löschen. Dies ist der zweitwichtigste Aspekt, um Arbeitslasten zu skalieren, wenn der Traffic zunimmt, auch wenn der Cluster ein Problem hat.
- Nutzercluster verwalten: Sie können Knoten verwalten, Nutzercluster aktualisieren, upgraden und löschen. Dies ist weniger wichtig als die Überlegungen zum Anwendungslebenszyklus. Wenn auf den vorhandenen Knoten Kapazität vorhanden ist, wirkt sich die Unfähigkeit, Nutzercluster zu ändern, nicht auf Nutzerarbeitslasten aus.
- Administratorcluster verwalten: Sie können den Administratorcluster aktualisieren und upgraden. Das ist die am wenigsten ausschlaggebende Überlegung, weil der Administratorcluster keine Nutzerarbeitslasten hostet. Wenn in Ihrem Administratorcluster ein Problem auftritt, werden Ihre Anwendungsarbeitslasten weiterhin ohne Unterbrechung ausgeführt.
In den folgenden Abschnitten werden diese Kategorien der Hauptfunktionen verwendet, um die Auswirkungen bestimmter Arten von Fehlerszenarien zu beschreiben.
Fehlermodi
Die folgenden Fehlertypen können sich auf die Leistung von Google Distributed Cloud-Clustern auswirken.
ESXi-Hostfehler
In diesem Fehlerszenario funktioniert ein ESXi-Host, auf dem VM-Instanzen ausgeführt werden, auf denen Kubernetes-Knoten gehostet werden, möglicherweise nicht mehr oder wird partitioniert.
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Störung | Mögliche Störung und automatische Wiederherstellung | Mögliche Störung und automatische Wiederherstellung | Störung und automatische Wiederherstellung | Störung und automatische Wiederherstellung |
| Erklärung | 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. |
| Wiederherstellung | 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. |
| Prävention | 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
In diesem Fehlerszenario wird eine VM möglicherweise unerwartet gelöscht, ein Bootlaufwerk kann beschädigt werden oder eine VM kann aufgrund von Betriebssystemproblemen manipuliert werden.
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Störung | Mögliche Störung und automatische Wiederherstellung | Mögliche Störung und automatische Wiederherstellung | Störung und automatische/manuelle Wiederherstellung | Störung und manuelle Wiederherstellung |
| Erklärung | 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. |
| Wiederherstellung | 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. Informationen zum Wiederherstellen der VM der Steuerungsebene des Administratorclusters finden Sie unter VM der Steuerungsebene des Administratorclusters reparieren. |
Informationen zum Wiederherstellen der VM der Steuerungsebene des Administratorclusters finden Sie unter VM der Steuerungsebene des Administratorclusters reparieren. |
| Prävention | Stellen Sie Arbeitslasten auf Hochverfügbarkeitsweise bereit, um Unterbrechungen zu minimieren. | Verwenden Sie HA-Nutzercluster, um die Möglichkeit einer Unterbrechung zu minimieren. | – | – |
Speicherfehler
In diesem Fehlerszenario kann der Inhalt einer VMDK-Datei beschädigt sein, da eine VM nicht richtig heruntergefahren wurde, oder ein Datenspeicherfehler kann dazu führen, dass etcd-Daten und PersistentVolumes (PVs) verloren gehen.
etcd-Fehler
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Störung | Keine Unterbrechung | Mögliche Störung und manuelle Wiederherstellung | Störung und manuelle Wiederherstellung | Störung und manuelle Wiederherstellung |
| Erklärung | – | 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. |
| Prävention | – | Google Distributed Cloud bietet einen manuellen Prozess zur Wiederherstellung nach einem Fehler. | Google Distributed Cloud bietet einen manuellen Prozess zur Wiederherstellung nach einem Fehler. | Google Distributed Cloud bietet einen manuellen Prozess zur Wiederherstellung nach einem Fehler. |
PV-Fehler bei der Nutzeranwendung
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Störung | Mögliche Unterbrechung | Keine Unterbrechung | Keine Unterbrechung | Keine Unterbrechung |
| Erklärung | Dies betrifft die Arbeitslasten, die das fehlgeschlagene PV verwenden. Stellen Sie Arbeitslasten auf Hochverfügbarkeitsweise bereit, um Unterbrechungen zu minimieren. |
– | – | – |
Fehler beim Load-Balancer
In diesem Fehlerszenario kann ein Load Balancer-Fehler sich auf Nutzerarbeitslasten auswirken, die Dienste vom Typ LoadBalancer verfügbar machen.
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Störung und manuelle Wiederherstellung | ||||
| Erklärung |
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. Die Dauer der Unterbrechung durch das MetalLB-Failover nimmt mit zunehmender Anzahl der Load Balancer-Knoten zu. Bei weniger als 5 Knoten dauert die Unterbrechung weniger als 10 Sekunden. |
|||
| Wiederherstellung | Seesaw HA erkennt den Fehler automatisch und führt ein Failover zur Sicherung der Instanz durch. Google Distributed Cloud bietet einen manuellen Prozess zur Wiederherstellung nach einem Seesaw-Fehler. |
|||
Defekten Cluster wiederherstellen
In den folgenden Abschnitten wird beschrieben, wie Sie einen fehlerhaften Cluster wiederherstellen.
Wiederherstellung nach ESXi-Hostfehlern
Google Distributed Cloud 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 Nutzer von Google Distributed Cloud transparent.
Wiederherstellung nach VM-Fehlern
Zu den VM-Fehlern gehören:
Unerwartetes Löschen einer VM.
Beschädigung des VM-Bootlaufwerks, z. B. wenn ein Bootlaufwerk aufgrund von Spam-Journallogs schreibgeschützt wird.
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.
Google Distributed Cloud 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. Wenn Sie eine VM der Administratorsteuerungsebene wiederherstellen möchten, wenden Sie sich an Cloud Customer Care.
Wiederherstellung nach Speicherfehlern
Einige Speicherfehler können durch vSphere HA und vSAN bewältigt werden, ohne dass die Google Distributed Cloud beeinträchtigt wird. Bestimmte Speicherfehler können jedoch durch die vSphere-Ebene verursacht werden, die zu Datenkorruption oder -verlust in verschiedenen Google Distributed Cloud-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 vor Kurzem bereitgestellte 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-Datenbeschädigungen oder -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. Dieses Szenario kann in einem HA-Cluster auftreten, 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. Weitere Informationen finden Sie unter Fehlgeschlagenes etcd-Replikat ersetzen.
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 nichts bewirkt. 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
Sie können bestimmte Speicherlösungen von Partnern verwenden, um PersistentVolumes von Nutzeranwendungen zu sichern und wiederherzustellen. Eine Liste der Speicherpartner, die für die Google Distributed Cloud qualifiziert sind, finden Sie unter Mit Anthos kompatible Speicherpartner.
Wiederherstellung nach Load-Balancer-Fehlern
Bei einem gebündelten Seesaw-Load Balancer 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. Führen Sie das Upgrade auf der VM der Administratorsteuerungsebene aus, auf der der Zugriff auf die Steuerungsebene möglich ist.
Informationen zu integrierten Load Balancern (F5) erhalten Sie vom F5-Support.
Für den gebündelten MetalLB-Load Balancer werden Clusterknoten als Load Balancer verwendet. Die automatische Knotenreparatur wird bei Problemen mit Load Balancern nicht ausgelöst. Sie können den manuellen Vorgang ausführen, um den Knoten zu reparieren.