Résolution des problèmes de EFS performances d'Amazon - Amazon Elastic File System

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes de EFS performances d'Amazon

En général, si vous rencontrez des problèmes avec Amazon EFS que vous ne parvenez pas à 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

  • RHEL7.3 ou version ultérieure

  • Toutes les versions Ubuntu 16.04

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

  • SLES12 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

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

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

Une demande de création d'un système de EFS fichiers é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 EFS fichiers avec les conditions de ressources spécifiées. Pour plus d’informations, consultez Gestion des identités et des accès pour Amazon EFS.

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

Lorsqu'un utilisateur auquel plus de 16 groupes d'accès IDs (GIDs) ont été affectés tente d'effectuer une opération sur un système de NFS fichiers, l'accès aux fichiers autorisés du système de fichiers peut lui être refusé. Ce problème se produit parce que le NFS protocole prend en charge un maximum de 16 GIDs par utilisateur et que toute demande supplémentaire GIDs est tronquée dans la demande du NFS client, comme défini dans la norme RFC5531.

Action à exécuter

Restructurez vos mappages NFS d'utilisateurs et de groupes afin que chaque utilisateur ne se voie attribuer pas plus de 16 groupes d'accès ()GIDs.

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

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

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 EFS console Amazon :

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

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

Action à exécuter

Assurez-vous que l'heure à laquelle le client accède à la EFS console Amazon est correctement réglée.

L'EC2instance Amazon se bloque

Une EC2 instance Amazon peut se bloquer parce que vous avez supprimé une cible de montage du système de fichiers sans avoir préalablement démonté 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 EFS fichiers Amazon, consultezDé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 sur Amazon se EFS bloque et provoque le redémarrage de l'instance.

Action à exécuter

Si une application met trop de temps à écrire toutes ses données sur AmazonEFS, 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 sur les clients RHEL 6 utilisant la version NFSv4 .1, car ces NFS clients se sérialisent NFS OPEN et fonctionnentCLOSE. Utilisez la version 4.1 du NFS protocole et l'une des distributions Linux suggérées qui ne présente pas ce problème.

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

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

  • Vous pouvez laisser l'utilisateur IDs le même pour toutes les demandes ouvertes et modifier l'ensemble de groupes à la IDs place.

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

NFSParamètres personnalisés entraînant des retards d'écriture

Vous avez des paramètres NFS client personnalisés et il faut jusqu'à trois secondes à une EC2 instance Amazon pour qu'une opération d'écriture soit effectuée sur un système de fichiers à partir d'une autre EC2 instance Amazon.

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 NFS client de l'EC2instance Amazon qui lit les 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 des attributs dans la NFSv4 version .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 vider le cache de vos attributs à la demande en utilisant un langage de programmation compatible avec les NFS procédures. 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 DirectNFS, comme décrit dans la section Activation et désactivation du contrôle direct du NFS client NFS dans le centre d'assistance Oracle.

Note

Amazon EFS ne prend pas en charge Oracle DirectNFS.