Auf dieser Seite erhalten Sie Tipps zu Problemen mit Compute Engine.
Hilfe zur Behebung bestimmter Probleme finden Sie in einem der folgenden Abschnitte:
- Eine Anleitung zur Fehlerbehebung bei allgemeinen Problemen mit Instanzen, z. B. wenn Ihre Instanz nicht gestartet wird, finden Sie unter Fehlerbehebung beim Erstellen, Aktualisieren und Löschen von VMs.
- Schritte zur Behebung von Problemen mit Windows-Instanzen finden Sie unter Fehlerbehebung bei Windows-Instanzen.
Verschiedene Antwortformate ansehen
Die meisten Aktionen der Google Cloud CLI werden mit REST API-Aufrufen ausgeführt. Die Ergebnisse in Schöndruck zeigen nur die wichtigsten der von einem bestimmten Befehl zurückgegebenen Informationen. Um die verschiedenen Antwortformate zu sehen, verwenden Sie das Flag --format, das die Antwort in verschiedenen Ausgabeformaten anzeigt, einschließlich json, yaml und text. Wenn Sie beispielsweise eine Liste der Instanzen im JSON-Format sehen möchten, verwenden Sie --format json:
gcloud compute instances list --format json
Logs von gcloud compute ansehen
Die gcloud CLI erstellt und speichert Logs in einer Logdatei unter $HOME/.config/gcloud/logs, die Sie abfragen können. Um sich die neueste Log-Datei unter Linux anzusehen, führen Sie Folgendes aus:
$ less $(find ~/.config/gcloud/logs | sort | tail -n 1)
Die Logdatei enthält Informationen über alle Anfragen und Antworten, die mit dem gcloud CLI-Tool erfolgt sind.
Wenn Sie die von der gcloud CLI erstellten Logdateien automatisch dauerhaft löschen möchten, verwenden Sie das Attribut max_log_days. Damit wird die maximale Aufbewahrungsdauer von Logdateien vor dem Löschen festgelegt.
Die Standardeinstellung ist 30 Tage. Wenn Sie diesen Attributwert auf „0“ festlegen, wird die automatische Speicherbereinigung für Logs deaktiviert und Logdateien werden nicht gelöscht.
gcloud config set core/max_log_days DAYS_TO_RETAIN_LOGS
Deaktivieren Sie das Datei-Logging der gcloud CLI:
Die Datei $HOME/.config/gcloud/logs belegt Speicherplatz im lokalen Dateisystem.
Die Menge der generierten Logs kann den Speicherplatz im lokalen Dateisystem überlasten, was zu folgenden Problemen führen kann:
- Die Speicherauslastung erreicht die Instanz zu 100 %.
- Die Ausführung von gcloud CLI-Logging-Befehlen schlägt fehl, da kein Speicherplatz mehr vorhanden ist, um eine neue Datei im lokalen Dateisystem zu erstellen.
Wenn Sie das Verhalten der gcloud CLI ändern und das Datei-Logging deaktivieren möchten, verwenden Sie das Attribut disable_file_logging:
gcloud config set core/disable_file_logging True
Ressourcennamen wählen
Beachten Sie bei der Wahl von Namen für Ihre Ressourcen, dass diese Anzeigenamen auf den Support- und Betriebsdashboards innerhalb von Compute Engine sichtbar sein können. Es empfiehlt sich deshalb, Ressourcennamen zu wählen, die keine vertraulichen Informationen enthalten.
Kommunikation mit dem Internet
Eine Instanz kann nur dann direkten Internetzugriff haben, wenn die beiden folgenden Bedingungen erfüllt sind:
- Die Instanz hat eine externe IP-Adresse.
- Das VPC-Netzwerk der Instanz verwendet eine Standardroute, deren nächster Hop das Standard-Internetgateway ist.
Instanzen können auch indirekt über Cloud NAT oder einen instanzbasierten Proxy auf das Internet zugreifen. Weitere Informationen, u. a. zur Konfiguration von Firewallregeln, finden Sie unter Anforderungen für den Internetzugriff.
Inaktive Verbindungen
Google Cloud Netzwerkkomponenten halten inaktive Verbindungen nicht unbegrenzt offen. Um Verbindungsabbrüche zu vermeiden, sollten Sie berücksichtigen, wie die folgenden Komponenten inaktive Verbindungen verarbeiten:
Einträge in der Tabelle zum Nachverfolgen von Verbindungen der Cloud Next Generation Firewall werden entfernt, nachdem ein Flow 10 Minuten lang inaktiv war.
Cloud NAT hat Zeitüberschreitungseinstellungen, die für inaktive Verbindungen für TCP, UDP und ICMP gelten. Die TCP-Zeitlimits umfassen das Zeitlimit für Inaktivität hergestellter TCP-Verbindungen, das Zeitlimit für Inaktivität vorübergehender TCP-Verbindungen und das TCP-
TIME_WAIT-Zeitlimit.Passthrough-Network Load Balancer verfolgen Verbindungen anhand eigener Regeln. Weitere Informationen finden Sie unter Verteilung des Traffics für interne Passthrough-Network Load Balancer und Verteilung des Traffics für regionale externe Passthrough-Network Load Balancer.
Damit inaktive TCP-Verbindungen nicht getrennt werden, können Sie TCP-Keepalive konfigurieren. Dadurch bleiben Verbindungen aktiv, da in regelmäßigen Abständen Pakete (Probes) gesendet werden, um die Leerlauftimeouts zurückzusetzen:
Achten Sie darauf, dass Client- oder Serveranwendungen Sockets mit der Socket-Option
SO_KEEPALIVEerstellen. Informationen zum Öffnen von Sockets mit der OptionSO_KEEPALIVEfinden Sie in der Dokumentation der Anwendung oder Softwarebibliothek.Konfigurieren Sie die folgenden TCP-Keepalive-Parameter:
Der Zeitraum der Inaktivität, der die Zeit angibt, die zwischen dem letzten Nicht-Keep-Alive-Paket und der ersten Keep-Alive-Prüfung in einer Sequenz vergehen muss.
Das Keep-Alive-Intervall, das die Zeit zwischen den einzelnen TCP-Keep-Alive-Prüfungen darstellt.
Die Keep-Alive-Prüfungen stellen die Gesamtzahl der nicht bestätigten TCP-Keep-Alive-Prüfungen dar, die in einer Sequenz gesendet werden, bevor die Verbindung als unterbrochen gilt.
Client- oder Serveranwendungen können die TCP-Keep-Alive-Parameter mithilfe von Socket-Optionen wie TCP_KEEPIDLE, TCP_KEEPINTVL und TCP_KEEPCNT festlegen. Alternativ können Sie die TCP-Keep-Alive-Parameter für Ihr Betriebssystem festlegen.
Die folgenden Beispiele zeigen, wie Sie für Ihr Betriebssystem einen Inaktivitätszeitraum von 60 Sekunden festlegen:
Linux
Führen Sie dazu diesen Befehl aus:
$ sudo /sbin/sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=5Fügen Sie die Einstellungen in der Datei /etc/sysctl.conf hinzu, damit sie nach einem Neustart weiterhin gelten. Diese Kernelparameter gelten sowohl für IPv4 als auch für IPv6, auch wenn sie ipv4 in ihren Namen haben.
Weitere Informationen finden Sie unter Linux TCP Keepalive HOWTO.
macOS
Führen Sie dazu diesen Befehl aus:
$ sudo sysctl -w net.inet.tcp.always_keepalive=1 net.inet.tcp.keepidle=60000 net.inet.tcp.keepinit=60000 net.inet.tcp.keepintvl=60000
Windows
Fügen Sie unter dem Registrierungspfad HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ die folgenden Einstellungen mit dem Datentyp DWORD hinzu oder bearbeiten Sie die Werte, falls die Einstellungen bereits vorhanden sind:
KeepAliveInterval: 1000 KeepAliveTime: 60000 TcpMaxDataRetransmissions: 10
Als ein anderer SSH-Nutzer auf Compute Engine zugreifen
Standardmäßig verwendet das gcloud compute-Befehlszeilentool die Variable $USER, um Nutzer der Datei /etc/passwd hinzuzufügen, damit sie über SSH eine Verbindung zu Instanzen herstellen können. Mit dem Flag --ssh-key-file PRIVATE_KEY_FILE kann bei Ausführung des Befehls gcloud compute ssh ein anderer Nutzer angegeben werden. Beispiel:
gcloud compute ssh example-instance --ssh-key-file my-private-key-file
Weitere Informationen finden Sie in der gcloud-Referenzdokumentation.
Mit der seriellen Konsole interagieren
Sie können interaktiven Zugriff auf die serielle Konsole einer Instanz aktivieren, um über die serielle Konsole Verbindungen zu Instanzen herzustellen und Fehler zu beheben.
Weitere Informationen finden Sie unter Fehlerbehebung mit serieller Konsole.
Datenpaketfragmentierung bei Instanzen auf der Grundlage von benutzerdefinierten Images vermeiden
In VPC-Netzwerken beträgt die standardmäßige maximale Übertragungseinheit (MTU) für Linux-Images und Windows Server-Images 1460 Byte. Die MTU des Netzwerks kann jedoch geändert werden. Weitere Informationen finden Sie in der VPC-Dokumentation in der Übersicht über die maximale Übertragungseinheit.
Beim Erstellen von Clientanwendungen, die mit Compute Engine-Instanzen über UDP-Sockets kommunizieren, können Sie Fragmentierungen vermeiden, wenn Sie die maximale Größe der UDP-Datagram-Daten auf 28 Byte unter der Netzwerk-MTU festlegen. Wenn die MTU des Netzwerks beispielsweise 1.460 Byte beträgt, können Sie bis zu 1.432 Byte an UDP-Daten pro Paket ohne Fragmentierung senden. Wenn die MTU des Netzwerks 1.500 Byte beträgt, können Sie bis zu 1.472 Byte UDP-Daten ohne Fragmentierung senden. Die 28 Byte werden für einen IPv4-Paketheader (20 Byte) und für einen UDP-Datagram-Header (8 Byte) verwendet. Sie können die MTU des Netzwerks auf maximal 8.896 Byte festlegen.
Leistungs- und CPU-Diagnose
Unerwartete Latenzspitzen oder Abstürze in Ihrer Anwendung auf modernen CPU-Plattformen können auf CPU-Bus-Sperren hinweisen. Diese Probleme treten auf, wenn atomare Vorgänge für nicht ausgerichteten Speicher ausgeführt werden.
Sehen Sie sich die Ausgabe des seriellen Ports an, um das Problem zu identifizieren. Suchen Sie nach dem folgenden Logeintrag: x86/split lock detection: #DB: <process_name>/<pid> took a bus_lock trap
at address: 0x<address>.
Die Ausgabe der seriellen Konsole ermöglicht die Erkennung von Ereignissen auf Hardwareebene, z. B. CPU-Bus-Lock-Traps, die auf nicht ausgerichtete Speichervorgänge hinweisen, die die Systemleistung beeinträchtigen können.
Weitere Informationen finden Sie unter Fehlerbehebung bei CPU-Bus-Sperren.