Bekannte Probleme


Auf dieser Seite werden bekannte Probleme beschrieben, die bei der Verwendung von Compute Engine auftreten können.

Allgemeine Probleme

Das Verschieben von VMs oder Laufwerken mit der moveInstance API oder dem gcloud-Tool führt zu unerwartetem Verhalten

Das Verschieben von VM-Instanzen mit dem Befehl gcloud compute instances move oder der Methode project.moveInstance kann zu Datenverlust, dem Löschen von VMs oder anderem unerwarteten Verhalten führen. Wenn Sie VMs verschieben, empfehlen wir, der Anleitung unter VM-Instanz zwischen Zonen oder Regionen verschieben zu folgen.

Laufwerke, die an VMs mit n2d-standard-64-Maschinentypen angehängt sind, erreichen nicht durchgängig die Leistungsgrenzen.

Nichtflüchtige Speicher, die an VMs mit n2d-standard-64-Maschinentypen angehängt sind, erreichen nicht konsistent die maximale Leistungsbegrenzung von 100.000 IOPS. Dies gilt sowohl für Lese- als auch für Schreib-IOPS.

Temporäre Namen für Laufwerke

Während VM-Instanz-Updates, die mit dem Befehl gcloud compute instances update oder der API-Methode instances.update initiiert wird, kann Compute Engine den Namen der Laufwerke Ihrer VM vorübergehend ändern. Dazu werden dem ursprünglichen Namen die folgenden Suffixe hinzugefügt:

  • -temp
  • -old
  • -new

Compute Engine entfernt das Suffix und stellt die ursprünglichen Laufwerknamen nach Abschluss der Aktualisierung wieder her.

Höhere Latenz für einige nichtflüchtige Speicher aufgrund von Größenänderung des Laufwerks

In einigen Fällen kann die Größe von großen nichtflüchtigen Speichern (ca. 3 TB) oder die E/A-Leistung des Laufwerks beeinträchtigt werden. Wenn Sie von diesem Problem betroffen sind, kann es bei Ihren nichtflüchtigen Speichern zu einer erhöhten Latenz während des Größenänderungsvorgangs kommen. Dieses Problem kann sich auf nichtflüchtige Speicher eines beliebigen Typs auswirken.

Höhere Latenz für einige nichtflüchtige Speicher aufgrund von Snapshots

Das folgende Problem wurde am 30. März 2021 behoben.

In einigen Fällen verursachen Snapshots großer nichtflüchtiger Speicher (mindestens 3 TB) Vorgänge, die die E/A-Leistung des Laufwerks beeinträchtigen können. Wenn Sie von diesem Problem betroffen sind, kann es bei den nichtflüchtigen Speichern zu einer höheren Latenz kommen. Dieses Problem kann Auswirkungen auf nichtflüchtige Speicher eines beliebigen Typs haben und durch reguläre oder geplante Snapshots verursacht werden.

Bekannte Probleme bei Linux-VM-Instanzen

Signatur von repomd.xml konnte nicht verifiziert werden.

Auf Red Hat Enterprise Linux- (RHEL)- oder CentOS 7-basierten Systemen kann der folgende Fehler auftreten, wenn Sie versuchen, Software mit yum zu installieren oder zu aktualisieren. Dieser Fehler zeigt an, dass Sie einen abgelaufenen oder falschen GPG-Schlüssel für das Repository haben.

Beispiellog:

[root@centos7 ~]# yum update


...

google-cloud-sdk/signature                                                                  | 1.4 kB  00:00:01 !!!
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
Trying other mirror.

...

failure: repodata/repomd.xml from google-cloud-sdk: [Errno 256] No more mirrors to try.
https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk

Lösung:

Um dieses Problem zu beheben, deaktivieren Sie die GPG-Schlüsselprüfung in der yum-Repository-Konfiguration durch Festlegen von repo_gpgcheck=0. In unterstützten Compute Engine-Basis-Images befindet sich diese Einstellung möglicherweise in der Datei /etc/yum.repos.d/google-cloud.repo. Die VM kann jedoch unterschiedliche Repository-Konfigurationsdateien oder Automatisierungstools enthalten.

Yum-Repositories verwenden in der Regel keine GPG-Schlüssel für die Repository-Validierung. Stattdessen ist der Endpunkt https vertrauenswürdig.

Führen Sie die folgenden Schritte aus, um diese Einstellung zu finden und zu aktualisieren:

  1. Suchen Sie die Einstellung in der Datei /etc/yum.repos.d/google-cloud.repo.

    cat /etc/yum.repos.d/google-cloud.repo
    
    
    [google-compute-engine]
    name=Google Compute Engine
    baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
    enabled=1
    gpgcheck=1
    repo_gpgcheck=1
    gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
       https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
    [google-cloud-sdk]
    name=Google Cloud SDK
    baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
    enabled=1
    gpgcheck=1
    repo_gpgcheck=1
    gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
       https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
    
    
  2. Ändern Sie alle Zeilen mit repo_gpgcheck=1 zu repo_gpgcheck=0.

    sudo sed -i 's/repo_gpgcheck=1/repo_gpgcheck=0/g' /etc/yum.repos.d/google-cloud.repo
  3. Prüfen Sie, ob die Einstellung aktualisiert wurde.

    cat /etc/yum.repos.d/google-cloud.repo
    
    [google-compute-engine]
    name=Google Compute Engine
    baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el7-x86_64-stable
    enabled=1
    gpgcheck=1
    repo_gpgcheck=0
    gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
       https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
    [google-cloud-sdk]
    name=Google Cloud SDK
    baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
    enabled=1
    gpgcheck=1
    repo_gpgcheck=0
    gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
       https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
    

GPG-Fehler: EXPKEYSIG 3746C208A7317B0F beim Aktualisieren von Paketen

Auf Debian- und Ubuntu-Systemen, auf denen Sie das gcloud-Befehlszeilentool manuell installiert haben, einschließlich Ihrer lokalen Workstation, kann ein ähnlicher Fehler wie im folgenden Beispiel auftreten:

W: An error occurred during the signature verification.
The repository is not updated and the previous index files will be used.
GPG error: http://packages.cloud.google.com/apt cloud-sdk-stretch InRelease:
The following signatures were invalid: EXPKEYSIG 3746C208A7317B0F
Google Cloud Packages Automatic Signing Key <gc-team@google.com>

Durch diesen Fehler wird verhindert, dass Sie die neuesten Updates für mehrere Google Cloud-Tools erhalten, darunter die Folgenden:

Um diesen Fehler zu beheben, rufen Sie die neueste gültige apt-key.gpg-Schlüsseldatei von https://packages.cloud.google.com ab:

Debian-Systeme

Führen Sie dazu diesen Befehl aus:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

Ubuntu-Systeme

Führen Sie dazu diesen Befehl aus:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -

Für Compute Engine-VM-Instanzen, auf denen Debian- oder Ubuntu-Images ausgeführt werden, können Sie die neuesten Schlüssel auch erhalten, wenn Sie Ihre Instanzen mit den folgenden Image-Versionen neu erstellen:

  • debian-cloud-Imageprojekt:
    • debian-9-stretch-v20180401 oder Imagefamilie debian-9
    • debian-8-jessie-v20180401 oder Imagefamilie debian-8
  • ubuntu-os-cloud-Imageprojekt:
    • ubuntu-1710-artful-v20180315 oder Imagefamilie ubuntu-1710
    • ubuntu-1604-xenial-v20180323 oder Image-Familie ubuntu-1604-lts
    • ubuntu-1404-trusty-v20180308 oder Imagefamilie ubuntu-1404-lts

Instanzen, die OS Login verwenden, geben nach der Verbindung eine Fehlermeldung zurück

Auf einigen Instanzen, die OS Login verwenden, erhalten Sie möglicherweise die folgende Fehlermeldung, nachdem die Verbindung hergestellt wurde:

/usr/bin/id: cannot find name for group ID 123456789

Ignorieren Sie die Fehlermeldung.

Bekannte Probleme für Windows-VM-Instanzen

  • Obwohl Windows-Instanzen die NVMe-Schnittstelle mit lokalen SSDs verwenden können, ist die NVMe-Unterstützung unter Windows in der Betaphase. Die gleiche Leistung wie bei Linux-Instanzen kann nicht garantiert werden.
  • Nachdem Sie eine Instanz erstellt haben, können Sie nicht sofort eine Verbindung zu ihr herstellen. Alle neuen Windows-Instanzen verwenden das Systemvorbereitungs-Tool sysprep zum Einrichten der Instanz, das dafür 5–10 Minuten benötigt.
  • Windows Server-Images können nur bei einer bestehenden Netzwerkverbindung zu kms.windows.googlecloud.com aktiviert werden und stellen nach 30 Tagen ihre Funktion ein, wenn sie bis dahin nicht authentifiziert wurden. Über KMS aktivierte Software muss alle 180 Tage reaktiviert werden. Der KMS versucht jedoch, alle 7 Tage eine Reaktivierung durchzuführen. Achten Sie darauf, dass Sie Ihre Windows-Instanzen so konfigurieren, dass sie aktiviert bleiben.
  • Wenn Kernelsoftware auf nicht emulierte modellspezifische Register zugreift, erzeugt dies allgemeine Schutzverletzungen, die je nach Gastbetriebssystem einen Systemabsturz verursachen können.