Dépannage

Cette page décrit les étapes de dépannage qui pourraient vous être utiles si vous rencontrez des problèmes lors de l'utilisation de Filestore.

Performances ralenties

  1. Vérifiez que vous utilisez le type de machine recommandé pour la VM cliente.
  2. Si votre VM cliente exécute Linux, assurez-vous que les options d'installation par défaut sont définies.

  3. Assurez-vous que la VM cliente se trouve dans la même région que l'instance Filestore. Procéder à l'installation dans plusieurs régions entraîne non seulement une réduction des performances, mais également des coûts de mise en réseau.

  4. Assurez-vous que votre instance Filestore n'est pas à pleine capacité ou presque. Lorsque la capacité est presque saturée, tout espace restant est fortement fragmenté, ce qui ralentit les opérations de lecture et d'écriture. La quantité d'espace libre nécessaire pour éviter ce scénario dépend de la casse. Nous vous recommandons de configurer des alertes d'espace disque faible.

  5. Testez les performances de votre instance Filestore à l'aide de l'outil fio.

    Si les résultats du test montrent que les performances sont anormalement lentes, contactez votre responsable de compte. En revanche, si les résultats présentent des performances semblables ou supérieures à celles attendues, passez à la section suivante.

Cas d'utilisation entraînant un ralentissement des performances

Voici quelques cas d'utilisation et scénarios entraînant des performances médiocres :

Charges de travail impliquant des volumes élevés de petits fichiers

Les partages de fichiers Filestore assurent la sécurité des données et la conformité du protocole NFS à l'aide de l'option d'exportation sync. Pour la plupart des opérations de modification de données, l'instance Filestore attend que les données soient stockées avant de répondre aux requêtes de la VM cliente. Lorsque de nombreux fichiers sont impliqués dans une opération, le client effectue toute une série d'opérations synchrones et la latence cumulée augmente.

Ce cas de figure se présente par exemple lorsque vous extrayez une archive du partage de fichiers, telle que des fichiers tar. TAR effectue de nombreuses opérations synchrones dans une série lors de l'extraction d'une archive contenant de nombreux fichiers. Par conséquent, les performances sont réduites.

Si vous essayez de copier de nombreux petits fichiers dans un partage de fichiers, essayez de créer des fichiers en parallèle avec un outil tel que gsutil:

mkdir -p /mnt/nfs/many_files_rsync/
time gsutil -m -q rsync -rp many_files /mnt/nfs/many_files_rsync/

Copie des données entre Cloud Storage et Filestore

La copie de données de Cloud Storage vers une instance Filestore à l'aide de gsutil est incontestablement lente. Il n'existe pas de mesure d'atténuation connue.

Latence lors de l'installation et de la désinstallation d'un partage de fichiers

Lors de l'installation d'un partage de fichiers à l'aide des options d'installation par défaut, la commande d'installation tente de découvrir la méthode de transport compatible avec l'instance Filestore, ce qui introduit une latence de trois secondes.

Le daemon mountd tente d'abord d'utiliser UDP, qui n'est pas compatible avec Filestore. Une fois que le délai d'essai initial expire, il reviendra au protocole TCP. Pour contourner ce processus de découverte et éliminer la latence ajoutée, vous pouvez spécifier l'option d'installation tcp, par exemple :

sudo mount -o tcp 10.0.0.2:/vol1 /mnt/nfs

Cette option d'installation est particulièrement importante si vous vous servez d'une installation automatique avec autofs.

Filestore ne répond pas

L'instance Filestore ne répond pas aux requêtes ping ou traceroute

Les instances Filestore ne répondent pas aux requêtes ping ou traceroute, car Filestore n'autorise pas ICMP.

Pour tester la connectivité à une instance Filestore, vous pouvez exécuter showmount à partir du client:

sudo showmount -e filestore-ip

L'instance Filestore répond avec son système de fichiers exporté, par exemple:

Export list for 10.139.19.98:
/vol1 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8

Vous pouvez également vérifier si le client peut accéder aux informations RPC de Filestore en exécutant:

sudo rpcinfo -p <filestore-ip>

La réponse est semblable à ce qui suit :

program vers proto   port  service
 100000    4   tcp    111  portmapper
 100000    3   tcp    111  portmapper
 100000    2   tcp    111  portmapper
 100000    4   udp    111  portmapper
 100000    3   udp    111  portmapper
 100000    2   udp    111  portmapper
 100024    1   udp   2046  status
 100024    1   tcp   2046  status
 100003    3   tcp   2049  nfs
 100227    3   tcp   2049
 100021    1   udp   4045  nlockmgr
 100021    3   udp   4045  nlockmgr
 100021    4   udp   4045  nlockmgr
 100021    1   tcp   4045  nlockmgr
 100021    3   tcp   4045  nlockmgr
 100021    4   tcp   4045  nlockmgr
 100005    3   udp   2050  mountd
 100005    3   tcp   2050  mountd

Maintenance planifiée

De temps en temps, Cloud Filestore ne répond plus pendant quelques minutes, puis redevient actif en raison d'un événement de maintenance programmé. Pour en savoir plus sur le contrat de niveau de service de Filestore, consultez la page Contrat de niveau de service.

Filestore n'est pas compatible avec les intervalles de maintenance définis par le client. La planification des intervalles de maintenance pour Filestore n'est également pas disponible pour les clients.

L'instance a été supprimée alors qu'elle était toujours installée sur le client

Si une opération sur un fichier ou une commande Unix telle que df, ls ou toute opération de lecture/écriture cesse de répondre, l'instance Filestore a probablement été supprimée alors qu'elle était installée sur le client.

Vérifiez si l'instance existe encore :

    gcloud filestore instances list

Si l'instance n'est plus répertoriée, vous pouvez reprendre le contrôle en créant une instance avec la même adresse IP et le même nom de partage de fichiers que l'instance supprimée. Une fois l'instance créée, l'opération qui ne répond pas s'exécute et renvoie une erreur. Si vous n'avez pas besoin de l'instance Filestore, vous pouvez désinstaller le partage de fichiers et le supprimer.

Pour éviter qu'un tel incident ne se reproduise, assurez-vous de désinstaller l'instance Filestore avant de la supprimer.

L'instance affiche l'état REPAIRING

L'instance Filestore est dans un état non opérationnel pour des raisons internes. Elle n'est pas contrôlable par l'utilisateur et se répare automatiquement. L'instance n'est pas disponible pendant cette période et vous n'avez rien à faire.

Problèmes de capacité

Espace insuffisant sur l'appareil

Vérifiez si l'instance Filestore dispose de suffisamment d'inodes en exécutant la commande suivante sur la VM cliente :

df -i

La commande renvoie un résultat semblable au suivant :

Filesystem           Inodes        IUsed      IFree         IUse%  Mounted on
10.0.0.2:/vol1    134217728        13         134217715     1%     /mnt/test

Chaque fichier stocké sur le partage de fichiers consomme un inode. Si la valeur IUse% atteint 100%, vous ne pouvez pas stocker d'autres fichiers sur le partage de fichiers, même si vous n'avez pas atteint la capacité maximale allouée. Le nombre d'inodes évolue en fonction de la capacité. Si vous souhaitez ajouter davantage d'inodes, vous devez augmenter la capacité.

Les commandes "df" et "du" indiquent différentes quantités d'espace disque disponible.

Lorsqu'un fichier ouvert par un processus en cours d'exécution est supprimé, l'espace disque utilisé par le fichier n'est pas libéré tant que le fichier n'est pas fermé. Les commandes df tiennent compte de l'espace utilisé par les fichiers ouverts supprimés, contrairement à la commande du. Cette différence de calcul explique que la commande du affiche souvent plus d'espace libre que df.

Pour afficher les fichiers supprimés qui sont toujours ouverts par un processus en cours d'exécution, exécutez:

lsof | grep deleted

Impossible de créer une instance

Erreur PERMISSION DENIED lors de la création d'une instance Filestore

  1. Vérifiez si l'API Filestore est activée :

    gcloud services enable file.googleapis.com
    
  2. Assurez-vous de disposer du rôle roles/file.editor. Pour en savoir plus, consultez la section Rôles et autorisations IAM.

  3. Si l'erreur persiste, le rôle file.serviceAgent a peut-être été supprimé du compte de service Filestore. Pour le vérifier, exécutez la commande suivante:

    gcloud projects get-iam-policy project-id-or-number  \
        --flatten="bindings[].members" \
        --format='table(bindings.role)' \
        --filter="bindings.members:service-project-number@cloud-filer.iam.gserviceaccount.com"
    

    où :

    • project-id-or-number est l'ID ou le numéro de votre projet Google Cloud.
    • project-number est le numéro de votre projet Google Cloud.

    La commande doit renvoyer un résultat semblable au suivant :

    ROLE
    roles/file.serviceAgent
    

    Si le fichier roles/file.serviceAgent n'est pas répertorié, vous pouvez le restaurer en exécutant la commande suivante :

    gcloud projects add-iam-policy-binding project-id-or-number  \
        --member serviceAccount:service-project-number@cloud-filer.iam.gserviceaccount.com  \
        --role roles/file.serviceAgent
    

Erreur System limit for internal resources has been reached (Limite du système atteinte pour les ressources internes) lors de la création d'une instance

Cette erreur est due au fait que Filestore atteint un quota réseau interne. Pour chaque réseau VPC sur lequel vous créez une instance Filestore, Filestore doit créer un réseau interne appairé à ce réseau. Ces réseaux internes sont conservés, même lorsque les instances Filestore et les réseaux VPC qui leur sont associés sont supprimés.

Lorsque votre projet dispose de 49 réseaux internes, Filestore ne peut plus en créer, ce qui vous empêchera de créer des instances Filestore sur de nouveaux réseaux VPC. Toute tentative de désactivation entraîne l'une des erreurs suivantes :

System limit for internal resources has been reached. Please request to adjust limit here: https://forms.gle/PFPJ2QD4KnCHzYEx9

Vous pouvez effacer les réseaux internes en désactivant, puis en réactivant l'API Filestore :

gcloud services disable file.googleapis.com

gcloud services enable file.googleapis.com

Si vous ne pouvez pas désactiver l'API parce que vous ne pouvez pas supprimer certaines instances Filestore ou si vous ne souhaitez pas perdre le quota qui vous a été accordé via les demandes d'augmentation de quota, vous pouvez remplir le formulaire suivant pour que vos limites de réseau soient ajustées :

https://forms.gle/PFPJ2QD4KnCHzYEx9

Si vous devez supprimer et créer régulièrement des réseaux VPC et des instances Filestore, deux méthodes permettent d'éviter d'atteindre le quota de réseau :

  • Lorsque vous créez un réseau VPC, utilisez le même nom qu'un ancien réseau utilisé pour la création d'une instance Filestore.

  • Utilisez un pool comportant au maximum 49 réseaux VPC au lieu de les supprimer et de les recréer.

Impossible d'installer le partage de fichiers

Ma VM ou mon pod GKE ne peuvent pas accéder à Filestore

Vérifiez si l'instance Filestore est accessible (ping et traceroute ne sont pas compatibles) en exécutant la commande suivante:

sudo showmount -e <filestore-ip>

La commande doit renvoyer une liste de systèmes de fichiers exportés. Vérifiez ensuite si le client peut accéder aux informations RPC de Filestore en exécutant la commande suivante:

sudo rpcinfo -p <filestore-ip>

Si l'instance Filestore n'est pas accessible, les causes courantes incluent des paramètres réseau ou des paramètres de LCA mal configurés, ou vous tentez d'installer la mauvaise instance.

  1. Vérifiez si le contrôle d'accès basé sur l'adresse IP est activé et si l'adresse IP du client est limitée. Pour en savoir plus, cliquez ici.
  2. Vérifiez les paramètres de pare-feu pour vous assurer que les ports requis sont ouverts. Pour en savoir plus, consultez la section Configurer les règles de pare-feu.
  3. Si vous essayez d'accéder à Filestore depuis un cluster GKE et que l'erreur mount.nfs: access denied by server while mounting ... s'affiche, consultez la section Impossible d'accéder au partage de fichiers à partir des clusters GKE.

Autorisation refusée lors de l'installation d'un partage de fichiers

Vérifiez si des options d'exportation NFS sont répertoriées pour l'instance :

gcloud filestore instances describe instance-id \
    --zone=zone

où :

  • instance-id est l'ID de l'instance Filestore ;
  • zone est la zone où se trouve l'instance Filestore.

La commande renvoie un résultat semblable au suivant :

createTime: '2019-10-11T17:28:23.340943077Z'
fileShares:
- capacityGb: '1024'
  name: vol1
  nfsExportOptions:
  - accessMode: READ_WRITE
    ipRanges:
    - 128.0.0.0/29
    squashMode: NO_ROOT_SQUASH
name: projects/yourproject/locations/us-central1-c/instances/nfs-server
networks:
- ipAddresses:
  - 10.0.0.2
  modes:
  - MODE_IPV4
  network: default
  reservedIpRange: 10.0.0.0/29
state: READY
tier: BASIC_HDD

Si des options nfsExportOptions sont répertoriées, assurez-vous que l'adresse IP de votre client se trouve dans l'une des plages répertoriées sous ipRanges pour le mode accessMode attendu. Si ce n'est pas le cas, vous devez modifier les options d'exportation NFS.

Impossible d'installer un partage de fichiers sur App Engine

Filestore n'est pas compatible avec App Engine.

Impossible d'installer un partage de fichiers à partir d'un cluster GKE

Vous ne pouvez pas installer directement les partages de fichiers Filestore sur des clusters GKE. À la place, vous devez configurer un PV et une PVC.

Impossible d'accéder au partage de fichiers depuis les clusters GKE

Pour obtenir plus d'informations sur le dépannage de Kubernetes ou de Google Kubernetes Engine, vous pouvez également consulter leGuide de dépannage Kubernetes etGuide de dépannage GKE.

Erreur: sortie: mount.nfs: accès refusé par le serveur lors de l'installation x.x.x.x:/file-share-name

Assurez-vous que les valeurs du PV spec.nfs.path et spec.nfs.server correspondent respectivement au nom du partage de fichiers et à l'adresse IP de l'instance Filestore.

Exemple :

Si votre partage de fichiers est nommé vol1 et que l'adresse IP de l'instance Filestore est 10.0.0.2, le PV spec.nfs.path et spec.nfs.server doivent correspondre aux valeurs suivantes:

apiVersion: v1
kind: PersistentVolume
metadata:
 name: fileserver
spec:
 capacity:
   storage: 2T
 accessModes:
 - ReadWriteMany
 nfs:
   path: /vol1
   server: 10.0.0.2

Impossible de désactiver l'API Filestore

Assurez-vous que toutes vos ressources liées à Filestore, telles que les instances et les sauvegardes Filestore, sont supprimées. Vous ne pouvez pas désactiver l'API Filestore lorsque des instances Filestore sont déployées.

Erreur : Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges.

Pour une connexion privée donnée, si votre espace d'adresses IP alloué arrive à épuisement, Google Cloud affiche l'erreur suivante: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges.

Pour en savoir plus sur la résolution de ce problème, consultez la section Épuisement de la plage d'adresses IP.