Fehlerbehebung und bekannte Probleme

Diese Seite enthält Schritte zur Fehlerbehebung für einige häufige Probleme und Fehler.

Bekannte Probleme

  • Wenn keine Ein-/Ausgabe im Dateisystem erfolgt, wird in den Leistungsdiagrammen die Meldung „Für den ausgewählten Zeitraum sind keine Daten verfügbar“ angezeigt. Leistungsmetriken werden nur generiert, wenn Ein-/Ausgabe erfolgt. Weitere Informationen zu Messwerten finden Sie unter Instanzen und Vorgänge überwachen.
  • Die folgenden Lustre-Funktionen werden nicht unterstützt:
    • Clientseitige Datenkompression
    • Persistentes Client-Caching
  • Einige Lustre-Befehle werden nicht unterstützt.
  • Es gibt einige Ausnahmen von der POSIX-Konformität.
  • Managed Lustre kann nicht auf Shielded VMs bereitgestellt werden. Der Versuch, das Lustre-Kernelmodul in einer Secure Boot-Umgebung zu laden, schlägt mit dem folgenden Fehler fehl: ERROR: could not insert 'lustre': Required key not available.

Probleme mit Instanzvorgängen

In den folgenden Abschnitten werden Probleme im Zusammenhang mit Instanzvorgängen beschrieben.

Vorgang kann nicht in die Warteschlange gestellt werden

Wenn beim Starten eines Vorgangs ein Fehler ähnlich einem der folgenden angezeigt wird:

ERROR: (gcloud.lustre.instances.import-data) ABORTED: unable to queue the operation
ERROR: (gcloud.lustre.instances.export-data) ABORTED: unable to queue the operation
ERROR: (gcloud.lustre.instances.update) ABORTED: unable to queue the operation

Dieser Fehler tritt auf, wenn Sie versuchen, einen Vorgang zu starten, während ein anderer Vorgang desselben Typs bereits auf derselben Instanz ausgeführt wird.

  • Import/Export:Managed Lustre unterstützt jeweils nur einen aktiven Übertragungsvorgang pro Instanz. Das Einreihen in die Warteschlange wird für Übertragungsvorgänge nicht unterstützt.
  • Instanz aktualisieren:Managed Lustre lässt jeweils eine aktive Aktualisierung pro Instanz zu und ermöglicht es, einen zusätzlichen Aktualisierungsvorgang in die Warteschlange zu stellen.

Warten Sie, bis der aktuelle Vorgang abgeschlossen ist, bevor Sie einen neuen starten.

Compute Engine-Probleme

Wenn beim Bereitstellen eines Managed Lustre-Dateisystems auf einer Compute Engine-Instanz Probleme auftreten, führen Sie die folgenden Schritte aus, um das Problem zu diagnostizieren.

Prüfen, ob die Managed Lustre-Instanz erreichbar ist

Prüfen Sie zuerst, ob Ihre Managed Lustre-Instanz von Ihrer Compute Engine-Instanz aus erreichbar ist:

sudo lctl ping IP_ADDRESS@tcp

Informationen zum Abrufen des Werts von IP_ADDRESS finden Sie unter Instanz abrufen.

Ein erfolgreicher Ping gibt eine Antwort ähnlich der folgenden zurück:

12345-0@lo
12345-10.115.0.3@tcp

Ein fehlgeschlagener Ping gibt Folgendes zurück:

failed to ping 10.115.0.3@tcp: Input/output error

Wenn der Ping fehlschlägt:

  • Achten Sie darauf, dass sich Ihre Managed Lustre-Instanz und Ihre Compute Engine-Instanz im selben VPC-Netzwerk befinden. Vergleichen Sie die Ausgabe der folgenden Befehle:

    gcloud compute instances describe VM_NAME \
  --zone=VM_ZONE \
  --format='get(networkInterfaces[0].network)'

gcloud lustre instances describe INSTANCE_NAME \
  --location=ZONE --format='get(network)'

    Die Ausgabe sieht so aus:

    https://www.googleapis.com/compute/v1/projects/my-project/global/networks/my-network
projects/my-project/global/networks/my-network

    Der Ausgabe des Befehls gcloud compute instances describe ist https://www.googleapis.com/compute/v1/ vorangestellt. Alles, was auf diesen String folgt, muss mit der Ausgabe des Befehls gcloud lustre instances describe übereinstimmen.

  • Prüfen Sie die Firewallregeln und Routingkonfigurationen Ihres VPC-Netzwerk, um sicherzustellen, dass Traffic zwischen Ihrer Compute Engine-Instanz und der Managed Lustre-Instanz zugelassen wird.

LNet-Akzeptanzport prüfen

Managed Lustre-Instanzen können so konfiguriert werden, dass sie GKE-Clients unterstützen, indem Sie beim Erstellen das Flag --gke-support-enabled angeben.

Wenn die GKE-Unterstützung aktiviert wurde, müssen Sie LNet auf allen Compute Engine-Instanzen so konfigurieren, dass accept_port 6988 verwendet wird. Weitere Informationen finden Sie unter LNet für Instanzen konfigurierengke-support-enabled.

Führen Sie den folgenden Befehl aus, um zu ermitteln, ob die Instanz für die Unterstützung von GKE-Clients konfiguriert wurde:

gcloud lustre instances describe INSTANCE_NAME \
  --location=LOCATION | grep gkeSupportEnabled

Wenn der Befehl gkeSupportEnabled: true zurückgibt, müssen Sie LNet konfigurieren.

Versionskonflikt zwischen Ubuntu-Kernel und Lustre-Client

Bei Compute Engine-Instanzen, auf denen Ubuntu ausgeführt wird, muss die Ubuntu-Kernelversion mit der jeweiligen Version der Lustre-Clientpakete übereinstimmen. Wenn Ihre Lustre-Clienttools nicht funktionieren, prüfen Sie, ob Ihre Compute Engine-Instanz automatisch auf einen neueren Kernel aktualisiert wurde.

So prüfen Sie die Kernelversion:

uname -r

Die Antwort sieht in etwa so aus:

6.8.0-1029-gcp

So prüfen Sie die Version des Lustre-Clientpakets:

dpkg -l | grep -i lustre

Die Antwort sieht in etwa so aus:

ii  lustre-client-modules-6.8.0-1029-gcp 2.14.0-ddn198-1  amd64  Lustre Linux kernel module (kernel 6.8.0-1029-gcp)
ii  lustre-client-utils                  2.14.0-ddn198-1  amd64  Userspace utilities for the Lustre filesystem (client)

Wenn die Kernelversionen, die von beiden Befehlen zurückgegeben werden, nicht übereinstimmen, müssen Sie die Lustre-Clientpakete neu installieren.

In „dmesg“ nach Lustre-Fehlern suchen

Viele Lustre-Warnungen und ‑Fehler werden im Linux-Kernel-Ringpuffer protokolliert. Der Befehl dmesg gibt den Kernel-Ringpuffer aus.

Verwenden Sie grep in Kombination mit dmesg, um nach Lustre-spezifischen Meldungen zu suchen:

dmesg | grep -i lustre

Oder suchen Sie nach allgemeineren Fehlern, die möglicherweise damit zusammenhängen:

dmesg | grep -i error

Informationen, die in eine Supportanfrage aufgenommen werden sollten

Wenn Sie den Fehler beim Bereitstellen nicht beheben können, erfassen Sie Diagnoseinformationen, bevor Sie eine Supportanfrage erstellen.

sosreport ausführen:Dieses Dienstprogramm erfasst Systemlogs und Konfigurationsinformationen und generiert einen komprimierten Tarball:

sudo sosreport

Hängen Sie das Archiv sosreport und alle relevanten Ausgaben von dmesg an Ihre Supportanfrage an.

GKE-Probleme

Bevor Sie die Schritte zur Fehlerbehebung in diesem Abschnitt ausführen, lesen Sie die Einschränkungen beim Herstellen einer Verbindung zu Managed Lustre von GKE aus.

Aktualisierte Mindestinstanzkapazität

Die Mindestkapazität für Managed Lustre-Instanzen wurde auf 9.000 GiB aktualisiert. Wenn Sie Instanzen mit 9.000 GiB mit dem Managed Lustre-CSI-Treiber erstellen möchten, aktualisieren Sie Ihre Clusterversion auf 1.34.0-gke.2285000 oder höher.

Falsche Leistungsstufe für dynamisch bereitgestellte Lustre-Instanzen

Beim dynamischen Bereitstellen einer Lustre-Instanz schlägt die Instanzerstellung mit einem InvalidArgument-Fehler für PerUnitStorageThroughput fehl, unabhängig vom Wert für perUnitStorageThroughput, der in der API-Anfrage angegeben ist. Dies betrifft GKE-Versionen vor 1.33.4-gke.1036000.

Problemumgehung :

Aktualisieren Sie den GKE-Cluster auf Version 1.33.4-gke.1036000 oder höher. Wenn Sie den Stable Channel verwenden, ist möglicherweise noch keine neuere Version verfügbar. In diesem Fall können Sie manuell eine Version aus den regulären oder schnellen Channels auswählen, die die Korrektur enthält.

Managed Lustre-Kommunikationsports

Der Managed Lustre-CSI-Treiber verwendet je nach GKE-Clusterversion und vorhandenen Managed Lustre-Konfigurationen unterschiedliche Ports für die Kommunikation mit Managed Lustre-Instanzen.

  • Standardport (988) : Bei neuen GKE-Clustern mit Version 1.33.2-gke.4780000 oder höher verwendet der Treiber standardmäßig Port 988 für die Lustre-Kommunikation.

  • Legacy-Port (6988) : Der Treiber verwendet Port 6988 in den folgenden Szenarien:

    • Frühere GKE-Versionen:Wenn auf Ihrem GKE-Cluster eine Version vor 1.33.2-gke.4780000 ausgeführt wird, ist das Flag --enable-legacy-lustre-port erforderlich, wenn Sie den CSI-Treiber aktivieren. Durch Aktivieren dieses Flags wird ein Portkonflikt mit dem gke-metadata-server auf GKE-Knoten umgangen.
    • Vorhandene Managed Lustre-Instanzen mit GKE-Unterstützung:Wenn Sie eine Verbindung zu einer vorhandenen Managed Lustre-Instanz herstellen, die mit dem Flag --gke-support-enabled erstellt wurde, müssen Sie --enable-legacy-lustre-port angeben, wenn Sie den CSI-Treiber aktivieren, unabhängig von Ihrer Clusterversion. Ohne dieses Flag kann Ihr GKE-Cluster die vorhandene Lustre-Instanz nicht bereitstellen.

    Weitere Informationen zum Aktivieren des CSI-Treibers mit dem Legacy-Port finden Sie unter Lustre-Kommunikationsports.

Logabfragen

Führen Sie die folgende Abfrage in Log-Explorer aus, um Logs zu prüfen.

So geben Sie die Logs des Managed Lustre-CSI-Treiberserverknotens zurück:

resource.type="k8s_container"
resource.labels.pod_name=~"lustre-csi-node*"

Fehlerbehebung bei der Volume-Bereitstellung

Wenn der PersistentVolumeClaim (PVC) im Status Pending bleibt und nach 20 bis 30 Minuten kein PersistentVolume (PV) erstellt wird, ist möglicherweise ein Fehler aufgetreten.

  1. Prüfen Sie die PVC-Ereignisse:

    kubectl describe pvc PVC_NAME

  2. Wenn der Fehler auf Konfigurationsprobleme oder ungültige Argumente hinweist, prüfen Sie die StorageClass-Parameter.

  3. Erstellen Sie den PVC neu.

  4. Falls das Problem weiterhin auftritt, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung beim Bereitstellen von Volumes

Nachdem der Pod einem Knoten zugewiesen wurde, wird das Volume bereitgestellt. Wenn dies fehlschlägt, prüfen Sie die Pod-Ereignisse und die Kubelet-Logs.

kubectl describe pod POD_NAME

Probleme beim Aktivieren des CSI-Treibers

Symptom :

MountVolume.MountDevice failed for volume "yyy" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name lustre.csi.storage.gke.io not found in the list of registered CSI drivers

oder

MountVolume.SetUp failed for volume "yyy" : kubernetes.io/csi: mounter.SetUpAt failed to get CSI client: driver name lustre.csi.storage.gke.io not found in the list of registered CSI drivers

Ursache:Der CSI-Treiber ist nicht aktiviert oder wird noch nicht ausgeführt.

Lösung :

  1. Prüfen Sie, ob der CSI-Treiber aktiviert ist.
  2. Wenn der Cluster vor Kurzem skaliert oder aktualisiert wurde, warten Sie einige Minuten, bis der Treiber funktioniert.
  3. Wenn der Fehler weiterhin auftritt, suchen Sie in den lustre-csi-node-Logs nach „Operation not permitted“. Dies weist darauf hin, dass die Knotenversion zu alt ist, um Managed Lustre zu unterstützen. Aktualisieren Sie Ihren Knotenpool auf Version 1.33.2-gke.1111000 oder höher, um dieses Problem zu beheben.
  4. Wenn in den Logs „LNET_PORT mismatch“ angezeigt wird, aktualisieren Sie Ihren Knotenpool, um sicherzustellen, dass kompatible Lustre-Kernelmodule installiert sind.

Bereitstellungspunkt ist bereits vorhanden

Symptom :

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = AlreadyExists
desc = A mountpoint with the same lustre filesystem name "yyy" already exists on
node "yyy". Please mount different lustre filesystems

Ursache:Das Bereitstellen mehrerer Volumes aus verschiedenen Managed Lustre-Instanzen mit demselben Dateisystemnamen auf einem einzelnen Knoten wird nicht unterstützt.

Lösung:Verwenden Sie für jede Managed Lustre-Instanz einen eindeutigen Dateisystemnamen.

Bereitstellung fehlgeschlagen: Datei oder Verzeichnis nicht vorhanden

Symptom :

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = Internal desc = Could not mount ... failed: No such file or directory

Ursache:Der angegebene Dateisystemname ist falsch oder nicht vorhanden.

Lösung:Prüfen Sie, ob der fs_name in Ihrer StorageClass- oder PV-Konfiguration mit der Managed Lustre-Instanz übereinstimmt.

Bereitstellung fehlgeschlagen: Fehler bei Eingabe/Ausgabe

Symptom :

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = Internal desc = Could not mount ... failed: Input/output error

Ursache:Der Cluster kann keine Verbindung zur Managed Lustre-Instanz herstellen.

Lösung :

  1. Prüfen Sie die IP-Adresse der Managed Lustre-Instanz.
  2. Achten Sie darauf, dass sich der GKE-Cluster und die Managed Lustre-Instanz im selben VPC-Netzwerk befinden oder korrekt per Peering verbunden sind.

Interne Fehler

Symptom:rpc error: code = Internal desc = ...

Lösung: Wenn der Fehler weiterhin auftritt, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung beim Aufheben der Bereitstellung von Volumes

Symptom :

UnmountVolume.TearDown failed for volume "yyy" : rpc error: code = Internal desc = ...

Lösung :

  1. Erzwingen Sie das Löschen des Pods:

    kubectl delete pod POD_NAME --force

  2. Falls das Problem weiterhin auftritt, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung beim Löschen von Volumes

Wenn der PV nach dem Löschen des PVC über einen längeren Zeitraum (z. B. mehr als eine Stunde) im Status "Freigegeben" bleibt, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung bei der Volume-Erweiterung

PVC bleibt in „ExternalExpanding“

Symptom:Der PVC-Status ändert sich nicht in Resizing und in den Ereignissen wird ExternalExpanding angezeigt.

Ursache:Das Feld allowVolumeExpansion fehlt möglicherweise oder ist auf false gesetzt.

Lösung:Achten Sie darauf, dass die StorageClass allowVolumeExpansion: true hat.

kubectl get storageclass STORAGE_CLASS_NAME -o yaml

Erweiterung fehlgeschlagen: Ungültiges Argument

Symptom:VolumeResizeFailed: rpc error: code = InvalidArgument ...

Ursache:Die angeforderte Größe ist ungültig (z. B. kein Vielfaches der Schrittgröße oder außerhalb der Grenzwerte).

Lösung: Prüfen Sie die gültigen Kapazitätsbereiche und aktualisieren Sie den PVC mit einer gültigen Größe.

Erweiterung fehlgeschlagen: Interner Fehler

Symptom:VolumeResizeFailed ... rpc error: code = Internal

Lösung:Wiederholen Sie die Erweiterung, indem Sie den PVC noch einmal anwenden. Wenn der Vorgang wiederholt fehlschlägt, wenden Sie sich an Cloud Customer Care.

Frist überschritten

Symptom:VolumeResizeFailed mit DEADLINE_EXCEEDED.

Ursache:Der Vorgang dauert länger als erwartet, wird aber möglicherweise noch ausgeführt.

Lösung:Warten Sie, bis der Vorgang abgeschlossen ist. Der Resizer versucht es automatisch noch einmal. Wenn der Vorgang lange Zeit hängen bleibt (z. B. > 90 Minuten), wenden Sie sich an den Support.

Kontingent überschritten

Symptom:Die Erweiterung schlägt aufgrund von Kontingentlimits fehl.

Lösung: Fordern Sie eine Kontingenterhöhung oder eine kleinere Kapazitätserhöhung an.

VPC-Netzwerkprobleme

In den folgenden Abschnitten werden häufige VPC-Netzwerkprobleme beschrieben.

Kein Zugriff auf Managed Lustre aus einem per Peering verbundenen Projekt

Wenn Sie von einer VM in einem per Peering verbundenen VPC-Netzwerk auf Ihre Managed Lustre-Instanz zugreifen möchten, müssen Sie Network Connectivity Center (NCC) verwenden. Mit NCC können Sie mehrere VPC-Netzwerke und lokale Netzwerke mit einem zentralen Hub verbinden, um eine Verbindung zwischen ihnen herzustellen.

Eine Anleitung zum Einrichten von NCC finden Sie in der Network Connectivity Center-Dokumentation.

Bereitstellen von Lustre auf einer VM mit mehreren NICs schlägt fehl

Wenn eine VM mehrere Netzwerkschnittstellen-Controller (NICs) hat und sich die Managed Lustre-Instanz in einer VPC befindet, die mit einer sekundären NIC (z. B. eth1) verbunden ist, kann die Bereitstellung der Instanz fehlschlagen. Folgen Sie der Anleitung zum Bereitstellen mit einer sekundären NIC, um dieses Problem zu beheben.

Verbindung aus dem Subnetzbereich 172.17.0.0/16 nicht möglich

Compute Engine- und GKE-Clients mit einer IP-Adresse im Subnetzbereich 172.17.0.0/16 können keine Managed Lustre-Instanzen bereitstellen.

Berechtigung zum Hinzufügen von Peering für den Dienst servicenetworking.googleapis.com verweigert

ERROR: (gcloud.services.vpc-peerings.connect) User [$(USER)] does not have
permission to access services instance [servicenetworking.googleapis.com]
(or it may not exist): Permission denied to add peering for service
'servicenetworking.googleapis.com'.

Dieser Fehler bedeutet, dass Sie für Ihr Nutzerkonto nicht die IAM-Berechtigung servicenetworking.services.addPeering haben.

Unter Zugriffssteuerung mit IAM finden Sie eine Anleitung zum Hinzufügen einer der folgenden Rollen zu Ihrem Konto:

  • roles/compute.networkAdmin oder
  • roles/servicenetworking.networksAdmin

Die zugewiesenen Bereiche können in CreateConnection nicht geändert werden

ERROR: (gcloud.services.vpc-peerings.connect) The operation
"operations/[operation_id]" resulted in a failure "Cannot modify allocated
ranges in CreateConnection. Please use UpdateConnection."

Dieser Fehler wird zurückgegeben, wenn Sie bereits ein VPC-Peering für dieses Netzwerk mit anderen IP-Bereichen erstellt haben. Es gibt zwei mögliche Lösungen:

Ersetzen Sie die vorhandenen IP-Bereiche:

gcloud services vpc-peerings update \
  --network=NETWORK_NAME \
  --ranges=IP_RANGE_NAME \
  --service=servicenetworking.googleapis.com \
  --force

Oder fügen Sie den neuen IP-Bereich der vorhandenen Verbindung hinzu:

  1. Rufen Sie die Liste der vorhandenen IP-Bereiche für das Peering ab:

    EXISTING_RANGES="$(
  gcloud services vpc-peerings list \
    --network=NETWORK_NAME \
    --service=servicenetworking.googleapis.com \
    --format="value(reservedPeeringRanges.list())" \
    --flatten=reservedPeeringRanges
)

  2. Fügen Sie dann den neuen Bereich zum Peering hinzu:

    gcloud services vpc-peerings update \
  --network=NETWORK_NAME \
  --ranges="${EXISTING_RANGES}",IP_RANGE_NAME \
  --service=servicenetworking.googleapis.com

IP-Adressbereich aufgebraucht

Wenn die Instanzerstellung mit einem Fehler aufgrund eines aufgebrauchten IP-Adressbereichs fehlschlägt:

ERROR: (gcloud.alpha.Google Cloud Managed Lustre.instances.create) FAILED_PRECONDITION: Invalid
resource state for "NETWORK_RANGES_NOT_AVAILABLE": IP address range exhausted

Folgen Sie der VPC-Anleitung, um die vorhandene private Verbindung zu ändern und IP-Adressbereiche hinzuzufügen.

Wir empfehlen eine Präfixlänge von mindestens /20 (4.096 Adressen).