Résolution des problèmes liés à Amazon EFS : problèmes de performances

Si vous rencontrez des problèmes avec Amazon EFS et que vous avez du mal à les résoudre, vérifiez que vous utilisez un noyau Linux récent. Si vous utilisez une distribution Linux d’entreprise, nous vous recommandons de procéder comme suit :

• Amazon Linux 2 avec le noyau 4.3 ou plus récent

• Amazon Linux 2015.09 ou version ultérieure

• RHEL 7.3 ou version ultérieure

• Toutes les versions Ubuntu 16.04

• Ubuntu 14.04 avec noyau 3.13.0-83 ou version ultérieure

• SLES 12 Sp2 ou version ultérieure

Si vous utilisez une autre distribution ou un noyau personnalisé, nous recommandons la version 4.3 ou version ultérieure.

Note

RHEL 6.9 peut être sous-optimal pour certaines charges de travail en raison des Performances médiocres à l’ouverture de plusieurs fichiers en parallèle.

Impossible de créer un système de fichiers EFS

Une demande de création d’un système de fichiers EFS échoue avec le message suivant :

User: arn:aws:iam::111122223333:user/username is not authorized to
perform: elasticfilesystem:CreateFileSystem on the specified resource.

Action à exécuter

Vérifiez votre politique AWS Identity and Access Management (IAM) pour confirmer que vous êtes autorisé à créer des systèmes de fichiers EFS avec les conditions de ressources spécifiées. Pour plus d’informations, consultez Gestion des identités et des accès pour Amazon Elastic File System.

Accès refusé aux fichiers autorisés sur le système de fichiers NFS

Lorsqu’un utilisateur auquel sont attribués plus de 16 identifiants de groupe d’accès (GID) tente d’effectuer une opération sur un système de fichiers NFS, il peut se voir refuser l’accès aux fichiers autorisés du système de fichiers. Ce problème se produit car le protocole NFS prend en charge un maximum de 16 GID par utilisateur, et tous les GID supplémentaires sont tronqués à partir de la demande du client NFS, comme défini dans la RFC 5531.

Action à exécuter

Restructurez vos mappages d’utilisateurs et de groupes NFS afin qu’un maximum de 16 groupes d’accès (GID) soient attribués à chaque utilisateur.

Erreurs lors de l’accès à la console Amazon EFS

Cette section décrit les erreurs que les utilisateurs peuvent rencontrer lors de l’accès à la console de gestion Amazon EFS.

Erreur lors de l’authentification des informations d’identification pour ec2:DescribeVPCs

Le message d’erreur suivant s’affiche lors de l’accès à la console Amazon EFS :

AuthFailure: An error occurred authenticating your credentials for ec2:DescribeVPCs.

Cette erreur indique que vos informations de connexion ne se sont pas authentifiées correctement auprès du service Amazon EC2. La console Amazon EFS appelle le service Amazon EC2 en votre nom lors de la création de systèmes de fichiers EFS dans le VPC de votre choix.

Action à exécuter

Assurez-vous que l’heure à laquelle le client accède à la console Amazon EFS est correctement définie.

L’instance Amazon EC2 se bloque

Une instance Amazon EFS peut se bloquer si vous avez supprimé la cible de montage d’un système de fichiers sans démonter d’abord le système de fichiers.

Action à exécuter

Avant de supprimer la cible de montage d’un système de fichiers, démontez le système de fichiers. Pour plus d’informations sur le démontage de votre système de fichiers Amazon EFS, consultez Démontage des systèmes de fichiers.

Une application qui écrit de grandes quantités de données se bloque

Une application qui écrit une grande quantité de données dans Amazon EFS se bloque et provoque le redémarrage de l’instance.

Action à exécuter

Si une application est trop longue à écrire toutes les données dans Amazon EFS, Linux peut redémarrer, car il semble que le processus ne répond plus. Deux paramètres de configuration du noyau définissent ce comportement, kernel.hung_task_panic et kernel.hung_task_timeout_secs.

Dans l’exemple suivant, l’état du processus suspendu est indiqué par la commande ps avec D avant le redémarrage de l’instance, ce qui indique que le processus est en attente en E/S.

$ ps aux | grep large_io.py
root 33253 0.5 0.0 126652 5020 pts/3 D+ 18:22 0:00 python large_io.py
/efs/large_file

Pour éviter un redémarrage, augmentez le délai d’attente ou désactivez le mode paniques du noyau lorsqu’une tâche suspendue est détectée. La commande suivante désactive le mode panique du noyau de la tâche suspendue sur la plupart des distributions Linux.

$ sudo sysctl -w kernel.hung_task_panic=0

Performances médiocres à l’ouverture de plusieurs fichiers en parallèle

Les applications qui ouvrent plusieurs fichiers en parallèle ne rencontrent pas l’amélioration attendue des performances en matière de parallélisation E/S.

Action à exécuter

Ce problème se produit sur les clients Network File System version 4 (NFSv4) et clients RHEL 6 qui utilisent NFSv4.1, car ces clients NFS sérialisent les opérations d’ouverture et de fermeture NFS. Utilisez la version 4.1 du protocole NFS et l’une des distributions Linux suggérées qui ne rencontrent pas ce problème.

Si vous ne pouvez pas utiliser NFSv4.1, notez que le client NFSv4.0 Linux sérialise les demandes d’ouverture et de fermeture par ID d’utilisateur et ID de groupe. Cette sérialisation se produit même si plusieurs processus ou plusieurs threads émettent des requêtes en même temps. Le client envoie uniquement une seule opération d’ouverture ou de fermeture sur un serveur NFS à la fois, lorsque tous les ID correspondent. Pour contourner ces problèmes, vous pouvez effectuer l’une des actions suivantes :

• Vous pouvez exécuter chaque processus à partir d’un ID d’utilisateur différent sur la même instance Amazon EFS.

• Vous pouvez conserver les mêmes ID utilisateur sur toutes les requêtes ouvertes, puis modifier l’ensemble des ID de groupe.

• Vous pouvez exécuter chaque processus à partir d’une instance Amazon EC2 distincte.

Paramètres NFS personnalisés entrainant des délais d’écriture

Vous disposez de paramètres de client NFS personnalisés, et jusqu’à trois secondes sont parfois nécessaires pour qu’une instance Amazon EFS voit une opération d’écriture effectuée sur un système de fichiers depuis une autre instance Amazon EFS.

Action à exécuter

Si vous rencontrez ce problème, vous pouvez le résoudre de l’une des façons suivantes :

• Si la mise en cache des attributs est activée sur le client NFS sur l’instance Amazon EFS qui lit des données, démontez votre système de fichiers. Ensuite, remontez-le avec l’option noac pour désactiver la mise en cache des attributs. La mise en cache d’attribut dans NFSv4.1 est activée par défaut.

  Note

  Désactiver la mise en cache côté client peut éventuellement réduire les performances de votre application.

• Vous pouvez également effacer votre cache d’attribut à la demande en utilisant un langage de programmation compatible avec les procédures NFS. Pour ce faire, vous pouvez envoyer une requête de procédure ACCESS immédiatement avant une demande de lecture.

  Par exemple, en utilisant le langage de programmation Python, vous pouvez construire l’appel suivant :

  # Does an NFS ACCESS procedure request to clear the attribute cache, given a path to the file
  import os
  os.access(path, os.W_OK)

La création de sauvegardes avec Oracle Recovery Manager est lente

La création de sauvegardes avec Oracle Recovery Manager peut être lente si Oracle Recovery Manager reste en pause pendant 120 secondes avant de démarrer une tâche de sauvegarde.

Action à exécuter

Si vous rencontrez ce problème, désactivez Oracle Direct NFS, comme décrit dans Enabling and Disabling Direct NFS Client Control of NFS dans le centre d’aide Oracle.

Note

Amazon EFS ne prend pas en charge Oracle Direct NFS.