Fehlerbehebung bei Clientverbindungen

Wenn beim Bereitstellen oder Herstellen einer Verbindung zu einem Managed Lustre-Dateisystem auf einer Client-VM oder -Instanz Probleme auftreten, folgen Sie dieser Anleitung, 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 Client-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:

  • Prüfen Sie, ob sich Ihre Managed Lustre-Instanz und Ihre Client-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 Befehls gcloud compute instances describe hat das Präfix https://www.googleapis.com/compute/v1/. 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 sie Traffic zwischen Ihrer Client-Instanz und der Managed Lustre-Instanz zulassen.

LNet-Akzeptanzport prüfen (ältere Instanzen)

Das Flag --gke-support-enabled ist veraltet und beim Erstellen neuer Managed Lustre-Instanzen nicht mehr erforderlich. Möglicherweise haben Sie jedoch ältere Instanzen, die mit diesem Flag erstellt wurden.

Wenn Sie eine Verbindung zu einer älteren Instanz herstellen, bei der GKE-Support aktiviert war, müssen Sie LNet auf allen Compute Engine-Clientinstanzen so konfigurieren, dass der accept_port 6988 verwendet wird. Weitere Informationen finden Sie unter LNet für Instanzen konfigurieren.gke-support-enabled

Führen Sie den folgenden Befehl aus, um zu prüfen, ob eine vorhandene Instanz mit diesem veralteten Flag konfiguriert wurde:

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

Wenn der Befehl gkeSupportEnabled: true zurückgibt, müssen Sie LNet auf Ihren Client-VMs konfigurieren.

Ubuntu-Kernelversion stimmt nicht mit Lustre-Client überein

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 Kernel-Version:

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 Kernel-Versionen, 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 Nachrichten zu suchen:

dmesg | grep -i lustre

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

dmesg | grep -i error

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.

Kein Zugriff auf Managed Lustre aus einem Peering-Projekt

Wenn Sie von einer VM in einem VPC-Netzwerk mit Peering 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 und so die Konnektivität zwischen ihnen herstellen.

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

Bereitstellung auf Shielded VMs schlägt fehl (Secure Boot)

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 Fehler: ERROR: could not insert 'lustre': Required key not available. fehl.

Informationen, die in eine Supportanfrage aufgenommen werden sollten

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

sosreport ausführen:Mit diesem Dienstprogramm werden Systemlogs und Konfigurationsinformationen erfasst und ein komprimierter Tarball generiert:

sudo sosreport

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