Allgemeine Fehlerbehebung

Diese Seite enthält hilfreiche Informationen über die schrittweise Fehlerbehebung in Verbindung mit Compute Engine-Instanzen.

Fehlerbehebung bei allgemeinen Problemen mit Instanzen

Die Instanz kann nicht gestartet werden

Die folgenden Tipps können Ihnen bei der Fehlerbehebung eines nicht bootenden nichtflüchtigen Speichers helfen.

  • Das Bootlaufwerk ist voll. Wenn das Bootlaufwerk voll ist und Ihr Betriebssystem die automatische Größenanpassung nicht unterstützt, können Sie keine SSH-Verbindung zur Instanz herstellen. Sie müssen eine neue Instanz erstellen und das Bootlaufwerk neu erstellen. Siehe Eine nicht zugängliche Instanz oder ein vollständiges Bootlaufwerk wiederherstellen.

  • Prüfen Sie die Ausgabe des seriellen Ports Ihrer VM-Instanz.

    Die Debug-Meldungen von BIOS, Bootloader und Kernel einer Instanz werden an den seriellen Port der Instanz ausgegeben und stellen dort wichtige Informationen über etwaige Fehler oder Probleme der Instanz zur Verfügung. Wenn Sie das Logging für die Ausgabe des seriellen Ports in Cloud Logging aktivieren, können Sie auch dann auf diese Informationen zugreifen, wenn die Instanz nicht ausgeführt wird. Siehe Ausgabe des seriellen Ports ansehen.

  • Aktivieren Sie den interaktiven Zugriff auf die serielle Konsole.

    Sie können den interaktiven Zugriff auf die serielle Konsole einer Instanz aktivieren, um sich anzumelden und Bootprobleme von der Instanz aus zu beheben, ohne dass die Instanz dafür vollständig gebootet sein muss. Weitere Informationen finden Sie unter Mit der seriellen Konsole interagieren.

  • Prüfen Sie, ob das Laufwerk über ein gültiges Dateisystem verfügt.

    Wenn das Dateisystem beschädigt oder ungültig ist, kann die Instanz nicht gestartet werden. Überprüfen Sie das Dateisystem des Laufwerks:

    1. Trennen Sie das betreffende Laufwerk gegebenenfalls von allen Instanzen:

      gcloud compute instances delete old-instance --keep-disks boot
      
    2. Starten Sie eine neue Instanz mit dem neuesten von Google bereitgestellten Image:

      gcloud compute instances create debug-instance
      
    3. Fügen Sie das Laufwerk als Nicht-Boot-Laufwerk hinzu, hängen Sie es aber nicht ein. Ersetzen Sie DISK durch den Namen des Laufwerks ohne Startfunktion. Beachten Sie, dass auch ein Gerätename angegeben wird. Dadurch kann das Laufwerk innerhalb der Instanz einfach ermittelt werden:

      gcloud compute instances attach-disk debug-instance --disk DISK --device-name debug-disk
      
    4. Stellen Sie eine Verbindung zur Instanz her:

      gcloud compute ssh debug-instance
      
    5. Ermitteln Sie die Root-Partition des Laufwerks. Diese erkennen Sie an der part1-Notation. In diesem Fall befindet sich die Root-Partition des Laufwerks unter /dev/sdb1:

      user@debug-instance:~$ ls -l /dev/disk/by-id
      total 0
      lrwxrwxrwx 1 root root  9 Jan 22 17:09 google-debug-disk -> ../../sdb
      lrwxrwxrwx 1 root root 10 Jan 22 17:09 google-debug-disk-part1 -> ../../sdb1
      lrwxrwxrwx 1 root root  9 Jan 22 17:02 google-persistent-disk-0 -> ../../sda
      lrwxrwxrwx 1 root root 10 Jan 22 17:02 google-persistent-disk-0-part1 -> ../../sda1
      lrwxrwxrwx 1 root root  9 Jan 22 17:09 scsi-0Google_PersistentDisk_debug-disk -> ../../sdb
      lrwxrwxrwx 1 root root 10 Jan 22 17:09 scsi-0Google_PersistentDisk_debug-disk-part1 -> ../../sdb1
      lrwxrwxrwx 1 root root  9 Jan 22 17:02 scsi-0Google_PersistentDisk_persistent-disk-0 -> ../../sda
      lrwxrwxrwx 1 root root 10 Jan 22 17:02 scsi-0Google_PersistentDisk_persistent-disk-0-part1 -> ../../sda1
      
    6. Führen Sie eine Dateisystemprüfung der Root-Partition aus:

      user@debug-instance:~$ sudo fsck /dev/sdb1
      fsck from util-linux 2.20.1
      e2fsck 1.42.5 (29-Jul-2012)
      /dev/sdb1: clean, 19829/655360 files, 208111/2621184 blocks
      
    7. Stellen Sie das Dateisystem bereit:

      user@debug-instance:~$ sudo mkdir /mydisk
      
      user@debug-instance:~$ sudo mount /dev/sdb1 /mydisk
      
    8. Prüfen Sie, ob das Laufwerk über Kernel-Dateien verfügt:

      user@debug-instance~:$ ls /mydisk/boot/vmlinuz-*
      /mydisk/boot/vmlinuz-3.2.0-4-amd64
      
  • Prüfen Sie, ob das Laufwerk über einen gültigen MBR (Master Boot Record) verfügt.

    Führen Sie den folgenden Befehl für die Debug-Instanz aus, an die das nichtflüchtige Bootlaufwerk angehängt ist, zum Beispiel /dev/sdb:

    $ sudo parted /dev/sdb print
    

    Bei einem gültigen MBR sollten Informationen über das Dateisystem aufgeführt sein:

    Disk /dev/sdb: 10.7GB
    Sector size (logical/physical): 512B/4096B
    Partition Table: msdos
    Disk Flags:
    
    Number  Start   End     Size    Type     File system  Flags
     1      2097kB  10.7GB  10.7GB  primary  ext4         boot
    

Instanz kann nicht erstellt werden

Der folgende Tipp kann Ihnen bei der Fehlerbehebung helfen, wenn eine Instanz nicht erstellt wird.

  • Gleichzeitige Vorgänge zum Ändern oder Erstellen von Ressourcen können einen Fehler verursachen. Wenn Sie beispielsweise sekundäre Bereiche in einem Subnetz ändern und gleichzeitig eine VM erstellen, wird möglicherweise der folgende Fehler zurückgegeben: The resource 'projects/[PROJECT]/regions/[REGION]/subnetworks/default' is not ready. Wiederholen Sie in diesem Fall einfach den fehlgeschlagenen Vorgang.

  • Wenn Sie einen Ressourcenfehler wie ZONE_RESOURCE_POOL_EXHAUSTED oder ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS beim Anfordern neuer Ressourcen erhalten, bedeutet dies, dass die Zone Ihrer Anfrage gerade nicht nachkommen kann. Dieser Fehler ist auf die Verfügbarkeit von Compute Engine-Ressourcen in der Zone und nicht auf Ihr Compute Engine-Kontingent zurückzuführen.

    Hier einige Tipps zur Abhilfe:

    • Da diese Situation temporär ist und sich aufgrund schwankender Nachfrage laufend ändern kann, senden Sie die Anfrage später einfach noch einmal.
    • Versuchen Sie nach Möglichkeit, die Ressourcen in einer anderen Zone der Region oder in einer anderen Region zu erstellen.
    • Ändern Sie nach Möglichkeit die Konfiguration der angeforderten VM. Kleinere Maschinentypen sind leichter zu erhalten als größere. Wenn Sie Ihre Anfrage ändern und beispielsweise die Anzahl der GPUs verringern oder eine benutzerdefinierte VM mit weniger Arbeitsspeicher oder vCPUs verwenden, haben Sie vielleicht damit Erfolg.
    • Reservieren Sie Compute Engine-Ressourcen in einer Zone. So können Sie dafür sorgen, dass die benötigten Ressourcen bei Bedarf zur Verfügung stehen.
    • Denken Sie beim Erstellen einer Instanz auf Abruf daran, dass VMs auf Abruf freie Kapazitäten sind, die unter Umständen zu Spitzenbedarfszeiten nicht erhältlich sind.
    • Wenn Sie beim Anfordern neuer Ressourcen den Fehler notFound oder does not exist in zone erhalten, kann die Zone Ihrer Anfrage bezüglich der Ressource oder des Maschinentyps nicht nachkommen. Unter Regionen und Zonen können Sie sehen, welche Features in den einzelnen Zonen verfügbar sind.

Netzwerktraffic zu/von der Instanz wird unterbrochen

Compute Engine lässt nur Netzwerktraffic zu, dem die Firewallregeln Ihres Projekts ausdrücklich das Erreichen Ihrer Instanz erlauben. Alle Projekte erhalten automatisch ein Standardnetzwerk, das bestimmte Arten von Verbindungen zulässt. Wenn Sie jeglichen Traffic standardmäßig ablehnen, werden auch SSH-Verbindungen und der gesamte interne Traffic abgelehnt. Weitere Informationen finden Sie auf der Seite Firewallregeln.

Zusätzlich müssen möglicherweise die TCP-Keep-Alive-Einstellungen angepasst werden, um die standardmäßige zehnminütige Zeitüberschreitung bei inaktiven Verbindungen zu umgehen. Weitere Informationen finden Sie unter Kommunikation zwischen Instanzen und dem Internet.

Fehlerbehebung bei Firewallregeln oder Routen einer Instanz

Die Google Cloud Console stellt Netzwerkdetails für jede Netzwerkschnittstelle einer Instanz bereit. Sie können sich alle Firewallregeln oder Routen, die für eine Schnittstelle gelten, oder nur die von der Schnittstelle verwendeten Regeln und Routen ansehen. In beiden Fällen können Sie feststellen, welche Firewallregeln und Routen für die Instanz gelten und welche tatsächlich verwendet werden (wenn Prioritäten und Verarbeitungsreihenfolgen andere Regeln oder Routen überschreiben).

Siehe dazu auch die Informationen zur Fehlerbehebung in der Dokumentation zu Virtual Private Cloud:

Probleme mit SSH beheben

Unter bestimmten Umständen kann es vorkommen, dass eine Linux-Instanz keine SSH-Verbindungen mehr akzeptiert. Dafür kann es viele Gründe geben, etwa ein volles Laufwerk oder eine falsche sshd-Konfiguration. In diesem Abschnitt finden Sie eine Reihe von Tipps und Ansätzen für die Behebung häufiger SSH-Probleme.

Firewallregeln prüfen

Compute Engine stellt für jedes Projekt eine Gruppe standardmäßiger Firewallregeln bereit, die Traffic über SSH erlauben. Sollte die Standard-Firewallregel, die SSH-Verbindungen zulässt, auf irgendeine Weise entfernt werden, können Sie nicht auf die Instanz zugreifen. Prüfen Sie mit dem gcloud-Befehlszeilentool die Liste der Firewalls und achten Sie darauf, dass die default-allow-ssh-Regel vorhanden ist.

gcloud compute firewall-rules list

Sollte sie fehlen, fügen Sie sie wieder hinzu:

gcloud compute firewall-rules create default-allow-ssh --allow tcp:22

Fehler mithilfe der seriellen Konsole beheben

Sie können den Lese-/Schreibzugriff auf die serielle Konsole einer Instanz aktivieren, um sich bei dieser anzumelden und Probleme mit der Instanz zu beheben. Dies ist besonders hilfreich, wenn eine Anmeldung mit SSH nicht möglich ist oder die Instanz keine Verbindung zum Netzwerk hat. Die serielle Konsole bleibt auch unter diesen beiden Bedingungen zugänglich.

Wie Sie interaktiven Zugriff aktivieren und eine Verbindung zur seriellen Konsole einer Instanz herstellen, erfahren Sie unter Mit der seriellen Konsole interagieren.

Netzwerk testen

Sie können mit dem netcat-Tool eine Verbindung zu Ihrer Instanz an Port 22 herstellen und prüfen, ob die Netzwerkverbindung funktioniert. Sollte ein SSH-Banner wie SSH-2.0-OpenSSH_6.0p1 Debian-4 zu sehen sein, funktioniert die Netzwerkverbindung und Sie können Firewallprobleme ausschließen. Verwenden Sie zuerst das gcloud-Tool, um die externe natIP für die Instanz abzurufen:

gcloud compute instances describe example-instance --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
198.51.100.8

Führen Sie dann den Befehl nc aus, um eine Verbindung zu Ihrer Instanz herzustellen:

# Check for SSH banner
user@local:~$ nc [EXTERNAL_IP] 22
SSH-2.0-OpenSSH_6.0p1 Debian-4

Als neuer Nutzer anmelden

Eine fehlgeschlagene Anmeldung ist möglicherweise auf das verwendete Konto zurückzuführen, beispielsweise wenn die Berechtigungen in der Datei ~/.ssh/authorized_keys für die Instanz falsch festgelegt wurden.

Melden Sie sich mit dem gcloud-Tool als ein neuer Nutzer an. Geben Sie dazu in der SSH-Anfrage einen anderen Nutzernamen an. Das gcloud-Tool aktualisiert dann die Metadaten des Projekts, um den neuen Nutzer hinzuzufügen und den SSH-Zugriff zuzulassen.

user@local:~$ gcloud compute ssh [USER]@example-instance

Dabei ist [USER] der neue Nutzername für die Anmeldung.

Laufwerk auf einer neuen Instanz verwenden

Wenn Ihnen die obigen Schritte nicht weiterhelfen und die relevante Instanz über einen nichtflüchtigen Speicher gebootet wird, können Sie den nichtflüchtigen Speicher trennen und an die neue Instanz anhängen. Ersetzen Sie DISK durch den Namen Ihres Speichers:

gcloud compute instances delete old-instance --keep-disks=boot
gcloud compute instances create new-instance --disk name=DISK boot=yes auto-delete=no
gcloud compute ssh new-instance

Instanzen ohne Herunterfahren untersuchen

Möglicherweise können Sie auf eine Instanz nicht zugreifen, die weiterhin fehlerfrei den Produktionsverkehr abarbeitet. In diesem Fall bietet es sich an, das Laufwerk zu untersuchen, ohne die Betriebsfähigkeit der Instanz für die Nutzer zu unterbrechen. Erzeugen Sie zuerst einen Snapshot des Bootlaufwerks dieser Instanz. Legen Sie dann ein neues Laufwerk auf der Grundlage des Snapshots an, erstellen Sie eine temporäre Instanz und fügen Sie den neuen nichtflüchtigen Speicher schließlich der temporären Instanz hinzu und hängen Sie ihn ein, um die Fehlersuche vorzunehmen.

  1. Erstellen Sie ein neues VPC-Netzwerk, in dem die geklonte Instanz gehostet werden kann:

    gcloud compute networks create debug-network
    
  2. Fügen Sie eine Firewallregel hinzu, die SSH-Verbindungen zum Netzwerk zulässt:

    gcloud compute firewall-rules create debug-network-allow-ssh --allow tcp:22
    
  3. Erstellen Sie einen Snapshot des betreffenden Laufwerks. Ersetzen Sie dabei DISK durch den Namen des Laufwerks:

    gcloud compute disks snapshot DISK --snapshot-name debug-disk-snapshot
    
  4. Erstellen Sie mit dem Snapshot aus dem vorigen Schritt ein neues Laufwerk:

    gcloud compute disks create example-disk-debugging --source-snapshot debug-disk-snapshot
    
  5. Erstellen Sie eine neue Debug-Instanz ohne externe IP-Adresse:

    gcloud compute instances create debugger --network debug-network --no-address
    
  6. Fügen Sie der Instanz das Debug-Laufwerk hinzu:

    gcloud compute instances attach-disk debugger --disk example-disk-debugging
    
  7. Folgen Sie den Anweisungen zum Herstellen einer Verbindung zu einer Instanz ohne externe IP-Adresse.

  8. Nach der Anmeldung bei der Debugger-Instanz führen Sie die Fehlerbehebung auf der Instanz durch. Prüfen Sie zum Beispiel die Instanzlogs:

    $ sudo su -
    
    $ mkdir /mnt/myinstance
    
    $ mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/myinstance
    
    $ cd /mnt/myinstance/var/log
    
    # Identify the issue preventing ssh from working
    $ ls
    

Startskript verwenden

Wenn keiner der vorherigen Vorschläge weitergeholfen hat, können Sie ein Startskript erstellen, um Informationen unmittelbar nach dem Start der Instanz zu erfassen. Folgen Sie der Anleitung zum Ausführen von Startskripts.

Anschließend müssen Sie die Instanz mit gcloud compute instances reset zurücksetzen, damit die Metadaten wirksam werden. Alternativ können Sie die Instanz mit einem diagnostischen Startskript neu erstellen:

  1. Führen Sie gcloud compute instances delete mit dem Flag --keep-disks aus.

    gcloud compute instances delete INSTANCE --keep-disks boot
    
  2. Fügen Sie eine neue Instanz mit demselben Laufwerk hinzu und geben Sie das Startskript an.

    gcloud compute instances create example-instance --disk name=DISK,boot=yes --startup-script-url URL
    

Das Skript compute-ssh-diagnostic ist ein guter Ausgangspunkt für die Erfassung von Diagnoseinformationen bei den häufigsten Problemen.