Dépannage et problèmes connus

Cette page décrit les étapes de dépannage pour certains problèmes et erreurs courants.

Problèmes connus

  • Lorsque aucune E/S n'a lieu sur le système de fichiers, les graphiques de performances affichent le message "Aucune donnée disponible pour la période sélectionnée". En effet, les métriques de performances ne sont générées que lorsqu'il y a des E/S. Pour en savoir plus sur les métriques, consultez Surveiller les instances et les opérations.
  • Les fonctionnalités Lustre suivantes ne sont pas compatibles :
    • Compression des données côté client
    • Mise en cache persistante côté client
  • Certaines commandes Lustre ne sont pas compatibles.
  • Il existe quelques exceptions à la conformité POSIX.

Problèmes liés aux opérations sur les instances

Les sections suivantes décrivent les problèmes liés aux opérations sur les instances.

Impossible d'ajouter l'opération à la file d'attente

Si une erreur semblable à l'une des suivantes s'affiche lorsque vous tentez de démarrer une opération :

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

Cette erreur se produit lorsque vous essayez de démarrer une opération alors qu'une autre opération du même type est déjà en cours sur la même instance.

  • Importation/Exportation : Managed Lustre n'accepte qu'une seule opération de transfert active par instance à la fois. La mise en file d'attente n'est pas compatible avec les opérations de transfert.
  • Mise à jour de l'instance : Managed Lustre n'autorise qu'une seule mise à jour active par instance à la fois, et permet de mettre en file d'attente une opération de mise à jour supplémentaire.

Pour résoudre ce problème, attendez la fin de l'opération en cours avant d'en commencer une autre.

Problèmes liés à Compute Engine

Si vous rencontrez des problèmes lors du montage d'un système de fichiers Managed Lustre sur une instance Compute Engine, suivez ces étapes pour diagnostiquer le problème.

Vérifier que l'instance Managed Lustre est accessible

Tout d'abord, assurez-vous que votre instance Managed Lustre est accessible depuis votre instance Compute Engine :

sudo lctl ping IP_ADDRESS@tcp

Pour obtenir la valeur de IP_ADDRESS, consultez Obtenir une instance.

Un ping réussi renvoie une réponse semblable à la suivante :

12345-0@lo
12345-10.115.0.3@tcp

En cas d'échec du ping, le message suivant s'affiche :

failed to ping 10.115.0.3@tcp: Input/output error

En cas d'échec de votre ping :

  • Assurez-vous que votre instance Managed Lustre et votre instance Compute Engine se trouvent dans le même réseau VPC. Comparez le résultat des commandes suivantes :

    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)'

    Le résultat ressemble à ceci:

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

    La sortie de la commande gcloud compute instances describe est précédée de https://www.googleapis.com/compute/v1/. Tout ce qui suit cette chaîne doit correspondre à la sortie de la commande gcloud lustre instances describe.

  • Examinez les règles de pare-feu et les configurations de routage de votre réseau VPC pour vous assurer qu'elles autorisent le trafic entre votre instance Compute Engine et l'instance Managed Lustre.

Vérifier le port d'acceptation LNet

Les instances Lustre gérées peuvent être configurées pour prendre en charge les clients GKE en spécifiant l'option --gke-support-enabled au moment de la création.

Si la compatibilité avec GKE a été activée, vous devez configurer LNet sur toutes les instances Compute Engine pour qu'elles utilisent le port 6988 accept_port. Consultez Configurer LNet pour les instances gke-support-enabled.

Pour déterminer si l'instance a été configurée pour prendre en charge les clients GKE, exécutez la commande suivante :

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

Si la commande renvoie gkeSupportEnabled: true, vous devez configurer LNet.

Incompatibilité de la version du noyau Ubuntu avec le client Lustre

Pour les instances Compute Engine exécutant Ubuntu, la version du noyau Ubuntu doit correspondre à la version spécifique des packages du client Lustre. Si vos outils client Lustre échouent, vérifiez si votre instance Compute Engine a été automatiquement mise à niveau vers un noyau plus récent.

Pour vérifier la version de votre noyau :

uname -r

La réponse est semblable à ce qui suit :

6.8.0-1029-gcp

Pour vérifier la version de votre package client Lustre :

dpkg -l | grep -i lustre

La réponse est semblable à ce qui suit :

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)

Si la version du noyau listée par les deux commandes ne correspond pas, vous devez réinstaller les packages clients Lustre.

Vérifier si des erreurs Lustre sont présentes dans dmesg

De nombreux avertissements et erreurs Lustre sont consignés dans le tampon circulaire du noyau Linux. La commande dmesg imprime le tampon circulaire du noyau.

Pour rechercher des messages spécifiques à Lustre, utilisez grep avec dmesg :

dmesg | grep -i lustre

Vous pouvez également rechercher des erreurs plus générales qui pourraient être liées :

dmesg | grep -i error

Informations à inclure dans une demande d'assistance

Si vous ne parvenez pas à résoudre l'échec du montage, collectez des informations de diagnostic avant de créer une demande d'assistance.

Exécutez sosreport : cet utilitaire collecte les journaux système et les informations de configuration, puis génère un fichier tarball compressé :

sudo sosreport

Joignez l'archive sosreport et toute sortie pertinente de dmesg à votre demande d'assistance.

Problèmes liés à GKE

Avant de suivre les étapes de dépannage de cette section, consultez les limites lors de la connexion à Managed Lustre depuis GKE.

Capacité minimale des instances modifiée

La capacité minimale des instances Managed Lustre a été mise à jour et est désormais de 9 000 Gio. Pour créer des instances de 9 000 Gio à l'aide du pilote CSI Lustre géré, mettez à niveau la version de votre cluster vers la version 1.34.0-gke.2285000 ou ultérieure.

Niveau de performances incorrect pour les instances Lustre provisionnées dynamiquement

Lors de l'approvisionnement dynamique d'une instance Lustre, la création de l'instance échoue avec une erreur InvalidArgument pour PerUnitStorageThroughput, quelle que soit la valeur perUnitStorageThroughput spécifiée dans la requête API. Cela affecte les versions de GKE 1.33 antérieures à 1.33.4-gke.1036000.

Solution :

Mettez à niveau le cluster GKE vers la version 1.33.4-gke.1036000 ou ultérieure. Si vous utilisez le canal stable, il est possible qu'une version plus récente ne soit pas encore disponible. Dans ce cas, vous pouvez sélectionner manuellement une version des canaux "Standard" ou "Rapide" qui inclut le correctif.

Ports de communication Managed Lustre

Le pilote CSI Managed Lustre utilise différents ports pour communiquer avec les instances Managed Lustre, en fonction de la version de votre cluster GKE et des configurations Managed Lustre existantes.

  • Port par défaut (988) : pour les nouveaux clusters GKE exécutant la version 1.33.2-gke.4780000 ou ultérieure, le pilote utilise le port 988 pour la communication Lustre par défaut.

  • Ancien port (6988) : le pilote utilise le port 6988 dans les scénarios suivants :

    • Versions antérieures de GKE : si votre cluster GKE exécute une version antérieure à 1.33.2-gke.4780000, l'indicateur --enable-legacy-lustre-port est requis lors de l'activation du pilote CSI. L'activation de ce flag permet de contourner un conflit de port avec gke-metadata-server sur les nœuds GKE.
    • Instances Managed Lustre existantes compatibles avec GKE : si vous vous connectez à une instance Managed Lustre existante qui a été créée avec l'indicateur --gke-support-enabled, vous devez inclure --enable-legacy-lustre-port lorsque vous activez le pilote CSI, quelle que soit la version de votre cluster. Sans cet indicateur, votre cluster GKE ne pourra pas monter l'instance Lustre existante.

    Pour en savoir plus sur l'activation du pilote CSI avec l'ancien port, consultez Ports de communication Lustre.

Requêtes de journaux

Pour vérifier les journaux, exécutez la requête suivante dans l'explorateur de journaux.

Pour renvoyer les journaux du serveur de nœuds du pilote CSI Lustre géré :

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

Résoudre les problèmes de provisionnement de volumes

Si la PersistentVolumeClaim (PVC) reste à l'état Pending et qu'aucun PersistentVolume (PV) n'est créé au bout de 20 à 30 minutes, une erreur s'est peut-être produite.

  1. Vérifiez les événements PVC :

    kubectl describe pvc PVC_NAME

  2. Si l'erreur indique des problèmes de configuration ou des arguments non valides, vérifiez vos paramètres StorageClass.

  3. Recréez la PVC.

  4. Si le problème persiste, contactez l'assistance Cloud Customer Care.

Résoudre les problèmes d'installation de volumes

Une fois le pod planifié sur un nœud, le volume est installé. Si cela échoue, consultez les événements du pod et les journaux kubelet.

kubectl describe pod POD_NAME

Problèmes d'activation du pilote CSI

Symptôme :

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

ou

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

Cause : Le pilote CSI n'est pas activé ou n'est pas encore en cours d'exécution.

Solution :

  1. Vérifiez que le pilote CSI est activé.
  2. Si le cluster a été mis à l'échelle ou mis à niveau récemment, patientez quelques minutes pour que le pilote devienne fonctionnel.
  3. Si l'erreur persiste, consultez les journaux lustre-csi-node pour voir si le message "Operation not permitted" (Opération non autorisée) s'affiche. Cela indique que la version du nœud est trop ancienne pour être compatible avec Managed Lustre. Pour résoudre ce problème, mettez à niveau votre pool de nœuds vers la version 1.33.2-gke.1111000 ou ultérieure.
  4. Si les journaux indiquent "LNET_PORT mismatch" (Incompatibilité LNET_PORT), mettez à niveau votre pool de nœuds pour vous assurer que les modules du noyau Lustre compatibles sont installés.

Le point de montage existe déjà

Symptôme :

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

Cause : Le montage de plusieurs volumes provenant de différentes instances Managed Lustre avec le même nom de système de fichiers sur un même nœud n'est pas pris en charge.

Résolution : Utilisez un nom de système de fichiers unique pour chaque instance Managed Lustre.

Échec du montage : fichier ou répertoire inexistant

Symptôme :

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

Cause : Le nom du système de fichiers spécifié est incorrect ou n'existe pas.

Résolution : vérifiez que le fs_name de votre configuration StorageClass ou PV correspond à l'instance Managed Lustre.

Échec du montage : erreur d'entrée/de sortie

Symptôme :

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

Cause : le cluster ne peut pas se connecter à l'instance Managed Lustre.

Solution :

  1. Vérifiez l'adresse IP de l'instance Managed Lustre.
  2. Assurez-vous que le cluster GKE et l'instance Managed Lustre se trouvent dans le même réseau VPC ou sont correctement appairés.

Erreurs internes

Symptôme : rpc error: code = Internal desc = ...

Résolution : si l'erreur persiste, contactez l'assistance Cloud Customer Care.

Résoudre les problèmes de désinstallation de volumes

Symptôme :

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

Solution :

  1. Forcez la suppression du pod :

    kubectl delete pod POD_NAME --force

  2. Si le problème persiste, contactez l'assistance Cloud Customer Care.

Résoudre les problèmes de suppression de volumes

Si le PV reste à l'état "Libéré" pendant une période prolongée (par exemple, plus d'une heure) après la suppression du PVC, contactez l'assistance Cloud Customer Care.

Résoudre les problèmes d'expansion de volume

PVC bloqué dans ExternalExpanding

Problème constaté : l'état du PVC ne passe pas à Resizing et les événements affichent ExternalExpanding.

Cause : Il se peut que le champ allowVolumeExpansion soit manquant ou défini sur false.

Résolution : Assurez-vous que StorageClass dispose de allowVolumeExpansion: true.

kubectl get storageclass STORAGE_CLASS_NAME -o yaml

Échec de l'élargissement : argument non valide

Symptôme : VolumeResizeFailed: rpc error: code = InvalidArgument ...

Cause : La taille demandée n'est pas valide (par exemple, elle n'est pas un multiple de la taille de pas ou elle est hors limites).

Résolution : vérifiez les plages de capacité valides et mettez à jour le PVC avec une taille valide.

Échec de l'expansion : erreur interne

Symptôme : VolumeResizeFailed ... rpc error: code = Internal

Solution : réessayez l'expansion en réappliquant le PVC. Si l'opération échoue à plusieurs reprises, contactez Cloud Customer Care.

Délai dépassé

Symptôme : VolumeResizeFailed avec DEADLINE_EXCEEDED.

Cause : L'opération prend plus de temps que prévu, mais elle est peut-être toujours en cours.

Résolution : Patientez jusqu'à la fin de l'opération. Le module de redimensionnement réessayera automatiquement. Si le problème persiste pendant une longue période (par exemple, > 90 minutes), contactez l'assistance.

Quota dépassé

Symptôme : l'expansion échoue en raison des limites de quota.

Solution : Demandez une augmentation de quota ou une augmentation de capacité plus faible.

Problèmes liés aux réseaux VPC

Les sections suivantes décrivent les problèmes courants liés aux réseaux VPC.

Impossible d'accéder à Managed Lustre depuis un projet appairé

Pour accéder à votre instance Lustre gérée à partir d'une VM dans un réseau VPC appairé, vous devez utiliser Network Connectivity Center (NCC). NCC vous permet de connecter plusieurs réseaux VPC et réseaux sur site à un hub central, ce qui assure la connectivité entre eux.

Pour savoir comment configurer NCC, consultez la documentation Network Connectivity Center.

L'installation de Lustre sur une VM à plusieurs cartes d'interface réseau échoue

Lorsqu'une VM comporte plusieurs cartes d'interface réseau et que l'instance Managed Lustre se trouve sur un VPC connecté à une carte d'interface réseau secondaire (par exemple, eth1), le montage de l'instance peut échouer. Pour résoudre ce problème, suivez les instructions pour effectuer le montage à l'aide d'une carte d'interface réseau secondaire.

Impossible de se connecter à partir de la plage de sous-réseaux 172.17.0.0/16

Les clients Compute Engine et GKE dont l'adresse IP se trouve dans la plage de sous-réseau 172.17.0.0/16 ne peuvent pas monter les instances Managed Lustre.

Autorisation refusée pour ajouter le peering au service servicenetworking.googleapis.com

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'.

Cette erreur signifie que vous ne disposez pas de l'autorisation IAM servicenetworking.services.addPeering dans votre compte utilisateur.

Consultez Contrôle des accès avec IAM pour savoir comment ajouter l'un des rôles suivants à votre compte :

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

Impossible de modifier les plages allouées dans CreateConnection

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

Cette erreur est renvoyée lorsque vous avez déjà créé un peering VPC sur ce réseau avec des plages d'adresses IP différentes. Il existe deux solutions :

Remplacez les plages d'adresses IP existantes :

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

Vous pouvez également ajouter la nouvelle plage d'adresses IP à la connexion existante :

  1. Récupérez la liste des plages d'adresses IP existantes pour l'appairage :

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

  2. Ajoutez ensuite la nouvelle plage au peering :

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

La plage d'adresses IP est épuisée.

Si la création d'une instance échoue en raison d'une erreur de plage épuisée :

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

Suivez le guide VPC pour modifier la connexion privée existante et ajouter des plages d'adresses IP.

Nous vous recommandons d'utiliser une longueur de préfixe d'au moins /20 (1 024 adresses).