Comment puis-je résoudre l'erreur « nfs : le serveur 127.0.0.1 ne répond pas » lors du montage de mon système de fichiers EFS ?

Dernière mise à jour : 18/07/2022

Mon serveur Amazon Elastic File System (Amazon EFS) ne répond pas et se bloque avec le message d'erreur « nfs : le serveur 127.0.0.1 ne répond pas ». Comment puis-je résoudre ce problème ?

Courte description

Voici les raisons courantes pour l'erreur le serveur ne répond pas :

  • Le client NFS ne peut pas se connecter au serveur EFS.
  • Un redémarrage ou un arrêt de l'instance s'est produit. Ou toute autre déconnexion de l'instance EC2 s'est produite. Ces événements entraînent une déconnexion du réseau entre le client NFS et le serveur EFS. Ce comportement n'est pas conforme à la RFC TCP. Les déconnexions peuvent entraîner le blocage des réponses d'Amazon EFS à une instance Amazon Elastic Compute Cloud (Amazon EC2) ou à un client NFS pendant plusieurs minutes.
  • L'option de montage noresvport n'était pas utilisée lors du montage du système de fichiers à l'aide d'un client NFS.
  • Il peut y avoir un problème avec la version du noyau à l'origine de l'échec du montage EFS. Par exemple, il existe un certain nombre de problèmes connus de clients NFS avec RHEL6 qui provoquent des symptômes similaires à ceux des systèmes de fichiers qui ne répondent pas. Dans les versions antérieures du noyau de RHEL6.X, le système de fichiers peut devenir indisponible et ne pas se remonter. Des blocages de connexion NFS peuvent se produire dans Amazon EFS si vous exécutez :
    • RHEL ou CentOS 7.6 ou version ultérieure (version noyau de 3.10.0-957).
    • Toute autre distribution Linux avec les versions du noyau 4.16 à 4.19.

Solution

1.    Utilisez l'option de montage noresvport lors du montage de votre système de fichiers. Cette option garantit que le client NFS utilise le nouveau port source TCP lorsqu'une connexion réseau doit être rétablie. L'utilisation de noresvport garantit la disponibilité ininterrompue du système de fichiers EFS après un événement de récupération du réseau.

$   sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport mount-target-ip:/ mnt

Si vous utilisez l'assistant de montage EFS, l'option noresvport est présente par défaut. Si vous utilisez NFS pour le montage, vous devez ajouter ce paramètre explicitement. Pour plus d'informations, consultez la section Options de montage NFS recommandées.

2.    Vérifiez la version du noyau. Il peut y avoir des problèmes avec la version particulière du noyau, tels que RHEL ou CentOS 7.6 ou version ultérieure (version du noyau 3.10.0-957), qui peuvent entraîner l'échec du montage du système de fichiers. Si vous exécutez l'une de ces versions du noyau, redémarrez pour récupérer l'accès au système de fichiers. Pour vérifier que la version du noyau est à l'origine du problème, vérifiez la sortie de la commande ps lorsque vous ne parvenez pas à exécuter ls :

$ ps auxwwwm | grep <mount_point_IP>

Si la version du noyau est défectueuse, mettez-la à jour. Il est recommandé d'utiliser la génération actuelle du client Linux NFS4v.1 ou une version ultérieure pour de meilleures performances.

3.    Vérifiez que le client peut se connecter au serveur en exécutant la commande suivante :

telnet <ip-of-efs> 2049

Consultez les journaux du client NFS (journaux du système d'exploitation de l'instance EC2) sous /var/log/messages pour détecter les erreurs. Les journaux peuvent se trouver dans le répertoire /var/log/syslog ou /var/log/dmesg, selon votre système d'exploitation.

De même, si vous avez monté le système de fichiers à l'aide de l'assistant de montage, examiner les journaux EFS util dans le répertoire /var/log/amazon/efs. L'assistant de montage EFS dispose d'un mécanisme de journalisation intégré.

4.    Vérifiez que vous pouvez vous connecter à votre instance EC2.

5.    Vérifiez si EC2 est surchargé en raison d'une sur-utilisation des ressources. Pour ce faire, surveillez les mesures EC2 dans Amazon CloudWatch, telles que CPUUtilization et les mesures liées au réseau. Les ressources peuvent inclure le processeur, la mémoire, les problèmes au niveau des applications, etc.

  • Sur-utilisation de la mémoire : cela peut se produire lorsque la RAM est sur-utilisée. La sur-utilisation signifie que l'instance est à court d'espace mémoire, si, par exemple, une application commence à consommer davantage de RAM. La sur-utilisation entraîne des erreurs de mémoire insuffisante (OOM). Lorsqu'elles sont déclenchées, ces erreurs mettent fin aux processus dont le score OOM est élevé ou qui consomment plus de mémoire. Idéalement, lorsque des erreurs OOM se déclenchent, l'instance reste inaccessible.
    Pour résoudre temporairement les erreurs d'OOM, redémarrez le système afin de libérer de l'espace mémoire.
    Pour une solution à plus long terme, surveillez l'utilisation des ressources système à l'aide d'outils tels que "atop" et "top". Ensuite, passez à un autre type d'instance qui convient mieux à votre charge de travail. Pourquoi mon instance EC2 Linux ne répond-elle pas lors d'une sur-utilisation des ressources ?
  • Performances du réseau : passez en revue les performances réseau de l'instance. Parfois, même si les mesures CloudWatch indiquent une faible utilisation du réseau, il peut y avoir micro-éclatement. Le micro-éclatement envoie une grande quantité de trafic à partir d'une charge de travail en quelques secondes. Le micro-éclatement dure généralement moins d'une minute. Cette poussée est masquée dans les graphiques CloudWatch et les statistiques Amazon Elastic Block Store (Amazon EBS), car le plus petit intervalle utilisé dans ces outils est d'une minute. Surveillez le comportement de micro-éclatement à l'aide d'outils tels que sar, nload, iftop. Pour plus d’informations, consultez Pourquoi mon instance Amazon Elastic Compute Cloud (Amazon EC2) dépasse-t-elle les limites de son réseau alors que l'utilisation moyenne est faible ?

6.    Passez en revue les mesures EFS CloudWatch et vérifiez si la limitation se produit au niveau de l'EFS. Cela signifie qu'EFS fonctionne au-delà de ses capacités. Si vous utilisez le mode Bursting Throughput, passez en revue la mesure CloudWatch BurstBalance pour déterminer si le solde de transmission en rafales est réduit. Passez également en revue les mesures CloudWatch de débit autorisé pour déterminer si vous utilisez un débit supérieur à la quantité allouée. Pour plus d'informations sur les crédits de transmission en rafales, consultez Comment fonctionnent les crédits de transmission en rafales Amazon EFS ?

Si vos applications ont besoin d'un débit quasi continu, utilisez le mode Débit alloué. Avant de passer du mode Débit en rafale au mode Débit alloué, réfléchissez à la quantité de débit à allouer. Pour déterminer la quantité minimale de débit alloué dont vous avez besoin, vérifiez l'utilisation du débit moyen de votre système de fichiers au cours des deux semaines précédentes. Notez le pic le plus élevé, arrondi au mégaoctet supérieur. Pour plus d’informations, consultez Quels sont les modes de débit disponibles dans EFS et quel est le mode de débit adapté à ma charge de travail ?


Cet article vous a-t-il été utile ?


Avez-vous besoin d'aide pour une question technique ou de facturation ?