Fehlerbehebung und bekannte Probleme

Auf dieser Seite finden Sie 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. Das liegt daran, dass Leistungsstatistiken nur generiert werden, wenn E/A-Vorgänge stattfinden. Weitere Informationen zu Messwerten finden Sie unter Instanzen und Vorgänge überwachen.
  • Die folgenden Lustre-Funktionen werden nicht unterstützt:
    • Clientseitige Datenkompression
    • Nichtflüchtiges Client-Caching
  • Einige Lustre-Befehle werden nicht unterstützt.
  • Es gibt einige Ausnahmen von der POSIX-Konformität.

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 den 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 bereits ein anderer Vorgang desselben Typs auf derselben Instanz ausgeführt wird.

  • Import/Export:Managed Lustre unterstützt jeweils nur einen aktiven Übertragungsvorgang pro Instanz. Die Warteschlange wird für Übertragungsvorgänge nicht unterstützt.
  • Instanzaktualisierung:Mit Managed Lustre ist jeweils nur eine aktive Aktualisierung pro Instanz zulässig. Es kann jedoch ein zusätzlicher Aktualisierungsvorgang in die Warteschlange gestellt werden.

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

Compute Engine-Probleme

Wenn beim Einbinden eines Managed Lustre-Dateisystems in eine 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.

Bei einem erfolgreichen Ping wird eine Antwort ähnlich der folgenden zurückgegeben:

12345-0@lo
12345-10.115.0.3@tcp

Bei einem fehlgeschlagenen Ping wird Folgendes zurückgegeben:

failed to ping 10.115.0.3@tcp: Input/output error

Wenn der Ping-Befehl fehlschlägt:

  • Achten Sie darauf, dass sich Ihre verwaltete 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

    Die Ausgabe des gcloud compute instances describe-Befehls beginnt mit https://www.googleapis.com/compute/v1/. Alles, was auf diesen String folgt, muss mit der Ausgabe des gcloud lustre instances describe-Befehls ü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

Verwaltete Lustre-Instanzen können so konfiguriert werden, dass sie GKE-Clients unterstützen. Geben Sie dazu beim Erstellen das Flag --gke-support-enabled an.

Wenn die GKE-Unterstützung aktiviert wurde, müssen Sie LNet auf allen Compute Engine-Instanzen für die Verwendung von accept_port 6988 konfigurieren. Weitere Informationen finden Sie unter LNet für gke-support-enabled-Instanzen konfigurieren.

Führen Sie den folgenden Befehl aus, um festzustellen, 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.

Fehlende Übereinstimmung zwischen Ubuntu-Kernelversion 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-Client-Tools fehlschlagen, prüfen Sie, ob Ihre Compute Engine-Instanz automatisch auf einen neueren Kernel aktualisiert wurde.

So prüfen Sie Ihre Kernelversion:

uname -r

Die Antwort sieht in etwa so aus:

6.8.0-1029-gcp

So prüfen Sie die Version Ihres 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 aufgeführt werden, nicht übereinstimmen, müssen Sie die Lustre-Clientpakete neu installieren.

dmesg auf Lustre-Fehler prüfen

Viele Lustre-Warnungen und ‑Fehler werden im Linux-Kernel-Ringpuffer protokolliert. Mit dem Befehl dmesg wird der Kernel-Ringpuffer ausgegeben.

Wenn Sie nach Lustre-spezifischen Nachrichten suchen möchten, verwenden Sie grep in Verbindung mit dmesg:

dmesg | grep -i lustre

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

dmesg | grep -i error

Informationen, die in einer Supportanfrage enthalten sein sollten

Wenn Sie den Mount-Fehler nicht beheben können, sammeln Sie Diagnoseinformationen, bevor Sie eine Supportanfrage erstellen.

sosreport ausführen:Dieses Dienstprogramm erfasst Systemlogs und Konfigurationsinformationen und generiert ein komprimiertes Tarball:

sudo sosreport

Hängen Sie das sosreport-Archiv 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 über GKE.

Aktualisierte Mindestkapazität für Instanzen

Die Mindestkapazität für verwaltete Lustre-Instanzen wurde auf 9.000 GiB aktualisiert. Wenn Sie 9.000 GiB-Instanzen über den verwalteten 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

Wenn Sie eine Lustre-Instanz dynamisch bereitstellen, schlägt die Instanzerstellung mit einem InvalidArgument-Fehler für „PerUnitStorageThroughput“ fehl, unabhängig vom in der API-Anfrage angegebenen „PerUnitStorageThroughput“-Wert. Dies betrifft GKE 1.33-Versionen vor 1.33.4-gke.1036000.

Workaround:

Führen Sie ein Upgrade des GKE-Cluster auf Version 1.33.4-gke.1036000 oder höher durch. 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 Kanälen „Regelmäßig“ oder „Schnell“ auswählen, die den Fix enthält.

Kommunikationsports für Managed Lustre

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. Wenn Sie dieses Flag aktivieren, 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 einfügen, wenn Sie den CSI-Treiber aktivieren, unabhängig von Ihrer Clusterversion. Ohne dieses Flag kann Ihr GKE-Cluster die vorhandene Lustre-Instanz nicht einbinden.

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

Logabfragen

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

So geben Sie die Knotenserverprotokolle des verwalteten Lustre-CSI-Treibers zurück:

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

Fehlerbehebung bei der Bereitstellung von Volumes

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. PVC-Ereignisse prüfen:

    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 das PVC neu.

  4. Sollte das Problem weiterhin bestehen, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung bei der Volume-Bereitstellung

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

kubectl describe pod POD_NAME

Probleme bei der Aktivierung von CSI-Treibern

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“ (Vorgang nicht zulässig). 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, führen Sie ein Upgrade Ihres Knotenpools durch, um sicherzustellen, dass kompatible Lustre-Kernelmodule installiert sind.

Mountpoint 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 Einbinden 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.

Mounting failed: No such file or directory (Mounting 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 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 verwalteten Lustre-Instanz herstellen.

Lösung:

  1. Prüfen Sie die IP-Adresse der verwalteten Lustre-Instanz.
  2. Achten Sie darauf, dass sich der GKE-Cluster und die verwaltete Lustre-Instanz im selben VPC-Netzwerk befinden oder richtig 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 Trennen 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. Sollte das Problem weiterhin bestehen, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung beim Löschen von Volumes

Wenn die 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 hängen

Problem: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 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.

Auflö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 die Synchronisierung 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 die Verarbeitung über einen längeren Zeitraum nicht abgeschlossen werden kann (z.B. > 90 Minuten) dauert, 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 geringere Kapazitätserhöhung an.

Probleme mit VPC-Netzwerk

In den folgenden Abschnitten werden häufige Probleme mit VPC-Netzwerk beschrieben.

Kein Zugriff auf Managed Lustre über ein Peering-Projekt

Wenn Sie von einer VM in einem verbundenen VPC-Netzwerk aus 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.

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

Wenn eine VM mehrere Netzwerkschnittstellen-Controller (NICs) hat und sich die verwaltete Lustre-Instanz in einem VPC-Netzwerk befindet, das mit einer sekundären NIC verbunden ist (z.B. eth1) kann das Bereitstellen der Instanz fehlschlagen. Folgen Sie der Anleitung zum Einbinden 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 einbinden.

Berechtigung zum Hinzufügen von Peering für 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 in Ihrem Nutzerkonto nicht über die IAM-Berechtigung servicenetworking.services.addPeering verfügen.

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:

Vorhandene IP-Bereiche ersetzen:

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 dem 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 dem Fehler „Bereich erschöpft“ 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 (1.024 Adressen).