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.

  • 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 Stackdriver 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 Laufwerk ohne Startfunktion hinzu, stellen Sie es aber nicht bereit. 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. Hängen Sie das Dateisystem ein:

      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 auf der Debug-Instanz, an die der nichtflüchtige Boot-Speicher angeschlossen ist (z. B. /dev/sdb), den folgenden Befehl aus:

    $ 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 zu einem Fehler führen. Wenn Sie beispielsweise sekundäre Bereiche in einem Subnetzwerk ändern und gleichzeitig eine VM erstellen, kann der folgende Fehler zurückgegeben werden: 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 hängt mit der Verfügbarkeit von Compute Engine-Ressourcen zusammen und ist 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 Ihre 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, bedeutet dies, dass die Zone die angeforderte Ressource oder den angeforderten Maschinentyp nicht anbietet. Unter Regionen und Zonen erfahren Sie, 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 Datenverkehr standardmäßig verbieten, werden auch SSH-Verbindungen und der gesamte interne Datenverkehr 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 GCP Console bietet für jede Netzwerkschnittstelle einer Instanz Netzwerkdetails. 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).

Weitere Informationen finden Sie unter den Abschnitten zur Fehlerbehebung in der Dokumentation zu Virtual Private Cloud:

Probleme mit SSH beheben

Unter bestimmten Umständen kann es passieren, 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, ob in der Liste der Firewalls die Regel default-allow-ssh enthalten 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. Rufen Sie zuerst mit dem gcloud-Tool den externen natIP-Wert für Ihre Instanz ab:

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

Stellen Sie mit dem Befehl nc eine Verbindung zur Instanz her:

# 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 zur Klärung mit dem gcloud-Tool als ein anderer 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.

Nichtflüchtigen Speicher 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 ein neues Laufwerk auf der Grundlage des Snapshots aus dem vorigen Schritt:

    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. Befolgen Sie die Anweisungen 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.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation