Google Distributed Cloud ist darauf ausgelegt, 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 sich ein Fehler auf die Funktionalität Ihrer Cluster auswirkt. Diese Informationen können Ihnen helfen, bei Problemen die Bereiche für die Fehlerbehebung zu priorisieren.
Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.Die Kernfunktionalität von Google Distributed Cloud umfasst 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. Selbst wenn bei Ihrem Cluster ein Problem auftritt, werden die vorhandenen Arbeitslasten möglicherweise ohne Unterbrechung weiter ausgeführt.
- Arbeitslasten verwalten: Sie können Arbeitslasten erstellen, aktualisieren und löschen. Dies ist der zweitwichtigste Aspekt beim Skalieren von Arbeitslasten, wenn der Traffic zunimmt, selbst wenn es beim Cluster ein Problem gibt.
- Nutzercluster verwalten: Sie können Knoten verwalten sowie Nutzercluster aktualisieren, aktualisieren und löschen. Dies ist weniger wichtig als die Überlegungen zum Anwendungslebenszyklus. Wenn auf den vorhandenen Knoten Kapazität verfügbar ist, hat die Möglichkeit, Nutzercluster nicht zu ändern, keine Auswirkungen auf die Nutzerarbeitslasten.
- Administratorcluster verwalten: Sie können den Administratorcluster aktualisieren und upgraden. Dies ist die am wenigsten wichtige Überlegung, da der Administratorcluster keine Nutzerarbeitslasten hostet. Wenn bei Ihrem Administratorcluster ein Problem auftritt, werden Ihre Anwendungsarbeitslasten ohne Unterbrechung weiter ausgeführt.
In den folgenden Abschnitten werden diese Kategorien von Hauptfunktionen verwendet, um die Auswirkungen bestimmter Arten von Fehlerszenarien zu beschreiben.
Fehlermodi
Die folgenden Fehlertypen können die Leistung von Google Distributed Cloud-Clustern beeinträchtigen.
ESXi-Hostfehler
In diesem Fehlerszenario funktioniert ein ESXi-Host, auf dem VM-Instanzen ausgeführt werden, die Kubernetes-Knoten hosten, möglicherweise nicht mehr oder netzwerkpartitioniert.
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Unterbrechung | Mögliche Unterbrechung und automatische Wiederherstellung | Mögliche Unterbrechung und automatische Wiederherstellung | Störung und automatische Wiederherstellung | Störung und automatische Wiederherstellung |
| Erklärung | Die Pods, die auf den VMs ausgeführt werden, die vom ausgefallenen Host gehostet werden, werden unterbrochen und automatisch auf andere fehlerfreie VMs umgeplant. 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 könnte beschädigt oder eine VM aufgrund von Betriebssystemproblemen beeinträchtigt sein.
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Unterbrechung | Mögliche Unterbrechung und automatische Wiederherstellung | Mögliche Unterbrechung und automatische Wiederherstellung | Störung und automatische/manuelle Wiederherstellung | Störung und manuelle Wiederherstellung |
| Erklärung | Die Pods, die auf den fehlgeschlagenen Worker-VMs ausgeführt werden, werden unterbrochen und von Kubernetes automatisch auf andere fehlerfreie 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 durch ein nicht ordnungsgemäßes Herunterfahren einer VM beschädigt werden oder ein Datenspeicherfehler kann zum Verlust von etcd-Daten und nichtflüchtigen Volumes (PVs) führen.
etcd-Fehler
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Unterbrechung | Keine Störung | 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 dem Fehler. | Google Distributed Cloud bietet einen manuellen Prozess zur Wiederherstellung nach dem Fehler. | Google Distributed Cloud bietet einen manuellen Prozess zur Wiederherstellung nach dem Fehler. |
PV-Fehler bei der Nutzeranwendung
| Arbeitslasten ausführen | Arbeitslasten verwalten | Nutzercluster verwalten | Administratorcluster verwalten | |
|---|---|---|---|---|
| Unterbrechung | Mögliche Störung | Keine Störung | Keine Störung | Keine Störung |
| 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 sich ein Load-Balancer-Fehler 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 2 Sekunden und bei Verwendung von F5 bis zu 300 Sekunden dauern. Die Dauer der Failover-Unterbrechung des MetalLB nimmt zu, wenn die Anzahl der Load-Balancer-Knoten zunimmt. Bei weniger als 5 Knoten erfolgt die Störung innerhalb von 10 Sekunden. |
|||
| Wiederherstellung | Seesaw-Hochverfügbarkeit erkennt den Fehler automatisch und führt den Failover auf die Sicherungsinstanz 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 nutzt vSphere HA, um eine Wiederherstellung nach einem ESXi-Hostausfall bereitzustellen. vSphere HA kann ESXi-Hosts kontinuierlich überwachen und die VMs auf anderen Hosts bei Bedarf automatisch 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. ein Bootlaufwerk, das aufgrund von Spam-Journallogs schreibgeschützt wird.
VM-Bootfehler aufgrund von Problemen mit der Laufwerk- oder Netzwerkeinrichtung, z. B. wenn die VM nicht gestartet werden kann, 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, Nutzersteuerungsebenen 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. Wenden Sie sich an Cloud Customer Care, wenn Sie VM-Fehler auf der Administrator-Steuerungsebene wiederherstellen möchten.
Wiederherstellung nach Speicherfehlern
Einige Speicherausfälle können durch vSphere HA und vSAN behoben werden, ohne Google Distributed Cloud zu beeinträchtigen. Bestimmte Speicherausfälle können jedoch auf vSphere-Ebene auftreten, was zu Datenbeschädigung oder -verlust in verschiedenen Google Distributed Cloud-Komponenten führen kann.
Die zustandsorientierten Informationen zu einem Cluster und Nutzerarbeitslasten werden an folgenden Orten gespeichert:
- etcd: Jeder Cluster (Administratorcluster und Nutzercluster) hat eine etcd-Datenbank, in der der Status (Kubernetes-Objekte) des Clusters gespeichert ist.
- PersistentVolumes: Werden 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 eine Sicherung erstellt wird, bevor eine Anwendung bereitgestellt wurde, und diese Sicherung dann zur Wiederherstellung des Clusters verwendet wird, wird die kürzlich 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.
Der Fehler bei etcd-Datenbeschädigung oder -verlust kann in 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 Hochverfügbarkeitscluster auftreten, in der die Daten eines der etcd-Replikate beschädigt sind oder verloren gehen. Das Problem kann ohne Datenverlust behoben werden, indem das fehlgeschlagene etcd-Replikat durch ein neues im bereinigten Zustand 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, daher hilft es nicht, die fehlgeschlagenen etcd-Replikate durch neue zu ersetzen. 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 nichtflüchtige Volumes von Nutzeranwendungen zu sichern und wiederherzustellen. Eine Liste der Speicherpartner, die für Google Distributed Cloud qualifiziert sind, finden Sie unter Anthos Ready Storage-Partner.
Wiederherstellung nach Load-Balancer-Fehlern
Für den gebündelten Seesaw-Load-Balancer können Sie den Load-Balancer nach Fehlern 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 Administrator-Steuerungsebene aus, auf der Zugriff auf die Steuerungsebene besteht.
Wenden Sie sich für integrierte Load-Balancer (F5) an den F5-Support.
Für gebündelte MetalLB-Load-Balancer werden Clusterknoten als Load-Balancer verwendet. Bei Problemen mit dem Load-Balancer wird die automatische Knotenreparatur nicht ausgelöst. Sie können den manuellen Prozess ausführen, um den Knoten zu reparieren.