Fehlerbehebung

Auf dieser Seite finden Sie Schritte zur Fehlerbehebung für einige häufige Probleme und Fehler.

FAILED-Instanz

Der Status FAILED bedeutet, dass die Instanzdaten verloren gegangen sind und die Instanz gelöscht werden muss.

Parallelstore-Instanzen im Status FAILED werden weiterhin in Rechnung gestellt, bis sie gelöscht werden.

Eine Anleitung zum Abrufen des Status einer Instanz finden Sie unter Instanzen verwalten: Instanz abrufen.

Informationen zum Löschen einer Instanz finden Sie unter Instanzen verwalten: Instanz löschen.

Zeitüberschreitungen bei der dfuse-Bereitstellung oder bei Netzwerktests

Wenn beim Mounten Ihrer Parallelstore-Instanz für den Befehl dfuse -m das Zeitlimit überschritten wird oder wenn für Netzwerktestbefehle wie self_test oder daos health net-test das Zeitlimit überschritten wird, kann dies an einem Netzwerkverbindungsproblem liegen.

Führen Sie Folgendes aus, um die Verbindung zu den Parallelstore-Servern zu prüfen:

self_test --use-daos-agent-env -r 1

Wenn beim Test ein Verbindungsproblem gemeldet wird, gibt es zwei mögliche Gründe:

Der DAOS-Agent hat bei der Einrichtung möglicherweise die falsche Netzwerkschnittstelle ausgewählt.

Möglicherweise müssen Sie Netzwerkschnittstellen ausschließen, die die IP-Adressen in der Liste access_points nicht erreichen können.

1. Führen Sie ifconfig aus, um die verfügbaren Netzwerkschnittstellen aufzulisten. In der Beispielausgabe werden möglicherweise mehrere Netzwerkschnittstellen wie eth0, docker0, ens8, lo usw. angezeigt.

2. Beenden Sie „daos_agent“.

3. Bearbeiten Sie /etc/daos/daos_agent.yml, um die unerwünschten Netzwerkschnittstellen auszuschließen. Entfernen Sie die Kommentarzeichen in der Zeile exclude_fabric_ifaces und aktualisieren Sie die Werte. Die Einträge, die Sie einfügen, sind für Ihre Situation spezifisch. Beispiel:

   exclude_fabric_ifaces: ["docker0", "ens8", "lo"]
   

4. Starten Sie den daos_agent neu.

Die IP-Adresse der Instanz oder des Clients steht in Konflikt mit internen IP-Adressen.

Parallelstore-Instanzen und -Clients können keine IP-Adresse aus dem Subnetzbereich 172.17.0.0/16 verwenden. Weitere Informationen finden Sie unter Bekannte Probleme.

ENOSPC, wenn in der Instanz ungenutzte Kapazität vorhanden ist

Wenn für Ihre Instanz die minimale oder (standardmäßig) die ausgewogene Striping-Methode verwendet wird, können ENOSPC-Fehler auftreten, auch wenn die vorhandenen Dateien nicht die gesamte Kapazität der Instanz nutzen. Dies tritt wahrscheinlich beim Schreiben großer Dateien auf, die in der Regel größer als 8 GiB sind, oder beim Importieren solcher Dateien aus Cloud Storage.

Verwenden Sie maximales File-Striping, um die Wahrscheinlichkeit dieser Fehler zu verringern.

Fehlerbehebung bei Google Kubernetes Engine

Im folgenden Abschnitt finden Sie einige häufige Probleme und Schritte zur Behebung.

Transport endpoint is not connected in Arbeitslast-Pods

Dieser Fehler ist auf die Beendigung von dfuse zurückzuführen. In den meisten Fällen wurde dfuse aufgrund von zu wenig Arbeitsspeicher beendet. Verwenden Sie die Pod-Annotationen gke-parallelstore/[cpu-limit|memory-limit], um dem Parallelstore-Sidecar-Container mehr Ressourcen zuzuweisen. Sie können gke-parallelstore/memory-limit: "0" festlegen, um die Arbeitsspeicherbeschränkung für den Sidecar zu entfernen, wenn Sie nicht wissen, wie viel Arbeitsspeicher Sie ihm zuweisen möchten. Diese Methode funktioniert nur bei Standardclustern. Bei Autopilot-Clustern können Sie mit dem Wert 0 die Ressourcenlimits und -anfragen für den Sidecar-Container nicht aufheben. Sie müssen explizit ein höheres Ressourcenlimit für den Sidecar-Container festlegen.

Nachdem Sie die Anmerkungen geändert haben, müssen Sie den Pod für Ihre Arbeitslast neu starten. Wenn Sie einer laufenden Arbeitslast Annotationen hinzufügen, wird die Ressourcenzuweisung nicht dynamisch geändert.

Pod-Ereigniswarnungen

Wenn Ihre Arbeitslast-Pods nicht gestartet werden können, prüfen Sie die Pod-Ereignisse:

kubectl describe pod POD_NAME -n NAMESPACE

Die folgenden Lösungen beziehen sich auf häufige Fehler.

Probleme bei der Aktivierung von CSI-Treibern

Häufige Fehler bei der Aktivierung von CSI-Treibern:

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

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

Diese Warnungen weisen darauf hin, dass der CSI-Treiber nicht aktiviert ist oder nicht ausgeführt wird.

Wenn Ihr Cluster gerade skaliert, aktualisiert oder aktualisiert wurde, ist diese Warnung normal und sollte vorübergehend sein. Es dauert einige Minuten, bis die CSI-Treiber-Pods nach Clusteroperationen funktionsfähig sind.

Prüfen Sie andernfalls, ob der CSI-Treiber in Ihrem Cluster aktiviert ist. Weitere Informationen finden Sie unter CSI-Treiber aktivieren. Wenn die CSI aktiviert ist, wird auf jedem Knoten ein Pod mit dem Namen parallelstore-csi-node-id angezeigt, der ausgeführt wird.

Fehler bei AttachVolume.Attach

Nachdem der Pod für einen Knoten geplant wurde, wird das Volume an den Knoten angehängt und der Mounter-Pod wird erstellt, wenn die Knotenbereitstellung verwendet wird.

Dies geschieht auf dem Controller und umfasst den Schritt „AttachVolume“ im „attachdetach-controller“.

Fehler „MountVolume.MountDevice“

Nachdem das Volume an einen Knoten angehängt wurde, wird es für den Knoten bereitgestellt.

Dies geschieht auf dem Knoten und umfasst den Schritt „MountVolume.MountDevice“ von kubelet.

MountVolume.SetUp-Fehler

Nachdem das Volume auf dem Knoten bereitgestellt wurde, wird es bereitgestellt und dem Container im Pod zur Verfügung gestellt. Dies geschieht auf dem Knoten und umfasst den Schritt „MountVolume.SetUp“ in kubelet.

Fehlerbehebung bei VPC-Netzwerken

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 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())"
   )
   

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

Das Erstellen einer Instanz kann mit dem folgenden Fehler „Bereich erschöpft“ fehlschlagen:

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

Wenn diese Fehlermeldung angezeigt wird, folgen Sie der VPC-Anleitung, um den IP-Bereich neu zu erstellen oder den vorhandenen IP-Bereich zu erweitern.

Wenn Sie eine Parallelstore-Instanz neu erstellen, müssen Sie den IP-Bereich neu erstellen, anstatt ihn zu erweitern.

Wartung aufgrund eines restriktiven Budgets für Pod-Störungen blockiert

In der Google Cloud -Konsole wird möglicherweise die folgende Fehlermeldung angezeigt, die darauf hinweist, dass die Wartung nicht fortgesetzt werden kann, da ein PodDisruptionBudget (PDB) so konfiguriert ist, dass keine Pod-Entfernungen zulässig sind:

GKE can't perform maintenance because the Pod Disruption Budget allows for 0 Pods evictions.

Wenn diese Fehlermeldung angezeigt wird, gehen Sie so vor, um den problematischen Pod zu ermitteln:

1. Klicken Sie auf die Fehlermeldung, um das Steuerfeld mit Fehlerinformationen zu öffnen.

2. Suchen Sie im Abschnitt Budgets für Pod-Störungen, die keine Pod-Entfernung zulassen nach dem Namen des Pods.

3. Wenn der Pod parallelstorecsi-mount ist, können Sie diesen Fehler ignorieren, da er die Wartung nicht verhindert. Prüfen Sie für alle anderen Pods Ihre PDB.