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
• Problèmes liés aux opérations sur les instances
• Maintenance
• Problèmes liés à Compute Engine
• Problèmes liés à GKE
• Problèmes liés au réseau VPC

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 du client
• Certaines commandes Lustre ne sont pas prises en charge.
• Il existe quelques exceptions à la conformité POSIX.
• Managed Lustre ne peut pas être installé sur des VM protégées. La tentative de chargement du module de noyau Lustre dans un environnement de démarrage sécurisé échoue et génère l'erreur suivante : ERROR: could not insert 'lustre': Required key not available.

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 de mettre l'opération en 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 tentez 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 ne prend en charge 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 autorise une 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 démarrer une autre.

Maintenance

L'état MAINTENANCE indique que l'instance fait l'objet d'une maintenance planifiée de l'hôte.

Pour les instances dont la capacité est supérieure au seuil de taille de pas pour leur niveau de performances, la maintenance de l'hôte nécessite l'arrêt et le redémarrage des machines virtuelles sous-jacentes. Cela entraîne un temps d'arrêt planifié pouvant aller jusqu'à quatre heures.

Si votre instance est à l'état MAINTENANCE :

• Temps d'arrêt : l'instance n'est pas disponible dans cet état.
• Planification : Google coordonne régulièrement ces événements avec vous à l'avance. Cette coordination est généralement gérée par vos contacts d'assistance désignés, tels qu'un responsable de compte technique (TAM).
• Facturation : l'instance vous est toujours facturée lorsqu'elle est à l'état MAINTENANCE, car vos données sont conservées.
• SLO : les instances à l'état MAINTENANCE sont exclues des calculs des objectifs de niveau de service (SLO).

Une fois la maintenance terminée, l'instance revient automatiquement à l'état ACTIVE.

Problèmes liés à Compute Engine

Si vous rencontrez des problèmes lors de l'installation d'un système de fichiers Managed Lustre sur une instance Compute Engine, procédez comme suit 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

Un ping échoué renvoie le message suivant :

failed to ping 10.115.0.3@tcp: Input/output error

Si votre ping échoue :

• Assurez-vous que votre instance Managed Lustre et votre instance Compute Engine se trouvent sur le même réseau VPC. Comparez la sortie 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 Managed Lustre 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 accept_port 6988. Consultez Configurer LNet pour les instancesgke-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 de 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 clients Lustre. Si vos outils clients Lustre échouent, vérifiez si votre instance Compute Engine a été mise à niveau automatiquement 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)

S'il existe une différence entre la version de noyau listée par les deux commandes, vous devez réinstaller les packages clients Lustre.

Vérifier les erreurs Lustre dans dmesg

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

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

dmesg | grep -i lustre

Ou, pour 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 de l'installation, 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 une archive tar compressée :

sudo sosreport

Joignez l'archive sosreport et tout résultat pertinent 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 mise à jour de l'instance

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 Managed Lustre, mettez à niveau la version de votre cluster vers 1.34.0-gke.2285000 ou une version ultérieure.

Niveau de performances incorrect pour les instances Lustre provisionnées de manière dynamique

Lors du provisionnement 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 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 une version ultérieure. Si vous utilisez le canal stable, une version plus récente n'est peut-être 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 une version ultérieure, le pilote utilise par défaut le port 988 pour la communication Lustre.

• Port hérité (6988) : le pilote utilise le port 6988 dans les scénarios suivants :

  • Versions GKE antérieures : si votre cluster GKE exécute une version antérieure à 1.33.2-gke.4780000, l'option --enable-legacy-lustre-port est requise lors de l'activation du pilote CSI. L'activation de cette option permet de contourner un conflit de port avec le 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'option --gke-support-enabled, vous devez inclure --enable-legacy-lustre-port lors de l'activation du pilote CSI, quelle que soit la version de votre cluster. Sans cette option, votre cluster GKE ne pourra pas installer l'instance Lustre existante.

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

Requêtes de journal

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 Managed Lustre :

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éé après 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 les paramètres de votre 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, vérifiez les événements du pod et les journaux du 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, recherchez "Operation not permitted" dans les journaux lustre-csi-node. Cela indique que la version du nœud est trop ancienne pour prendre en charge Managed Lustre. Pour résoudre ce problème, mettez à niveau votre pool de nœuds vers la version 1.33.2-gke.1111000 ou une version ultérieure.
4. Si les journaux affichent "LNET_PORT mismatch", mettez à niveau votre pool de nœuds pour vous assurer que les modules de noyau Lustre compatibles sont installés.

Le point d'installation 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 : l'installation de plusieurs volumes à partir de différentes instances Managed Lustre portant le même nom de système de fichiers sur un seul nœud n'est pas compatible.

Solution : utilisez un nom de système de fichiers unique pour chaque instance Managed Lustre.

Échec de l'installation : aucun fichier ni répertoire de ce type

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 de système de fichiers spécifié est incorrect ou n'existe pas.

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

Échec de l'installation : 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 sur le même réseau VPC ou qu'ils sont correctement appairés.

Erreurs internes

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

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 "Released" pendant une période prolongée (par exemple, plus d'une heure) après la suppression de la PVC, contactez l'assistance Cloud Customer Care.

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

PVC bloquée dans ExternalExpanding

Symptôme : l'état de la PVC ne passe pas à Resizing, et les événements affichent ExternalExpanding.

Cause : le champ allowVolumeExpansion est peut-être manquant ou défini sur false.

Solution : assurez-vous que StorageClass comporte allowVolumeExpansion: true.

kubectl get storageclass STORAGE_CLASS_NAME -o yaml

Échec de l'expansion : 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 en dehors des limites).

Solution : vérifiez les plages de capacité valides et mettez à jour la PVC avec une taille valide.

Échec de l'expansion : erreur interne

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

Solution : réessayez l'expansion en appliquant à nouveau la PVC. Si l'opération échoue à plusieurs reprises, contactez l'assistance 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.

Solution : patientez jusqu'à la fin de l'opération. Le redimensionneur réessayera automatiquement. S'il reste bloqué pendant une longue période (par exemple, plus de 90 minutes), contactez l'assistance.

Quota dépassé

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

Solution : demandez une augmentation de votre quota ou une augmentation de capacité plus petite.

Problèmes liés au réseau VPC

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

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

Pour accéder à votre instance Managed Lustre à 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 de Network Connectivity Center.

Échec de l'installation de Lustre sur une VM à plusieurs cartes d'interface réseau

Lorsqu'une VM possède plusieurs contrôleurs d'interface réseau (NIC) et que l'instance Managed Lustre se trouve sur un VPC connecté à une carte d'interface réseau secondaire (par exemple, eth1), l'installation de l'instance peut échouer. Pour résoudre ce problème, suivez les instructions pour installer à l'aide d'une carte d'interface réseau secondaire NIC.

Impossible de se connecter à partir de la plage de sous-réseau 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 installer d'instances Managed Lustre.

Autorisation refusée pour ajouter l'appairage 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 sur 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 appairage VPC sur ce réseau avec différentes plages d'adresses IP. 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

Ou ajoutez 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 à l'appairage :

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

Épuisement de la plage d'adresses IP

Si la création de l'instance échoue avec une erreur d'épuisement de la plage d'adresses IP :

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 afin d'ajouter des plages d'adresses IP.

Nous vous recommandons une longueur de préfixe d'au moins /20 (4 096 adresses).