Réparer une connexion de montage EFS

Introduction

A lit ses fichiers partagés, mais B ne peut pas se connecter au même EFS. Diagnostiquez la connexion, restaurez le montage de B et limitez l’accès aux serveurs prévus.

Terminez d’abord les deux exercices EFS précédents. Ce nouvel environnement fournit le système existant, le point d’accès, le fichier original et les hôtes. Utilisez AWS CLI configurée, SSH et AWS View ; aucun compte personnel ni ressource précédente n’est nécessaire.

Lien avec les certifications

Schéma conceptuel ; consultez les identifiants de votre nouvel environnement.

Diagnostiquer et réparer la règle réseau NFS

Dans cette étape, trouvez la couche défaillante et réparez le groupe de stockage.

Travaillez dans /home/labex/project. resources.json contient les identifiants du stockage et des applications :

cd /home/labex/project
aws sts \
  get-caller-identity
FS_ID=$(jq -r .fault.filesystem_id resources.json)
MOUNT_TARGET_ID=$(jq -r .fault.mount_target_id resources.json)
AP_ID=$(jq -r .fault.access_point_id resources.json)
EFS_GROUP_ID=$(jq -r .fault.storage_group_id resources.json)
APP_GROUP_ID=$(jq -r .application_group_id resources.json)
APP_A_IP=$(jq -r '.clients["application-a"].ip' resources.json)
echo "$FS_ID"
echo "$MOUNT_TARGET_ID"
echo "$AP_ID"
echo "$EFS_GROUP_ID"
echo "$APP_GROUP_ID"
echo "$APP_A_IP"

Lisez le fichier existant par les deux applications :

curl -i http://127.0.0.1:8081/uploads/original-upload.txt
curl -i http://127.0.0.1:8082/uploads/original-upload.txt

A renvoie 200 OK avec Original upload from application A, B renvoie 404 Not Found. Inspectez les montages :

ssh -F ssh_config application-a 'findmnt -t nfs4 /srv/shared'
ssh -F ssh_config application-b 'findmnt -t nfs4 /srv/shared'

A possède un montage NFS. B n’en a aucun et findmnt retourne 1. Avant de modifier chemins ou permissions, vérifiez si B atteint le point réseau :

MOUNT_IP=$(aws efs \
  describe-mount-targets \
  --mount-target-id "$MOUNT_TARGET_ID" \
  --query 'MountTargets[0].IpAddress' --output text)
echo "$MOUNT_IP"
ssh -F ssh_config application-b "nc -zvw2 $MOUNT_IP 2049"

La connexion échoue. nc teste TCP sans créer de montage. Une racine ou identité POSIX incorrecte peut bloquer des fichiers après connexion, mais n’explique pas cet échec TCP.

Confirmez la disponibilité de la cible et inspectez son groupe :

aws efs \
  describe-mount-targets \
  --mount-target-id "$MOUNT_TARGET_ID" \
  --query 'MountTargets[].{ID:MountTargetId,State:LifeCycleState,Subnet:SubnetId}'
aws efs \
  describe-mount-target-security-groups \
  --mount-target-id "$MOUNT_TARGET_ID"
aws ec2 \
  describe-security-groups \
  --group-ids "$EFS_GROUP_ID" \
  --query 'SecurityGroups[].IpPermissions'

La règle NFS autorise TCP 2049 uniquement depuis l’adresse privée de A avec un CIDR /32. Elle exclut B. Remplacez-la par une règle du groupe des applications :

aws ec2 \
  revoke-security-group-ingress \
  --group-id "$EFS_GROUP_ID" \
  --protocol tcp \
  --port 2049 \
  --cidr "$APP_A_IP/32"

Autorisez les deux membres du groupe :

aws ec2 \
  authorize-security-group-ingress \
  --group-id "$EFS_GROUP_ID" \
  --ip-permissions "IpProtocol=tcp,FromPort=2049,ToPort=2049,UserIdGroupPairs=[{GroupId=$APP_GROUP_ID}]"
ssh -F ssh_config application-b "nc -zvw2 $MOUNT_IP 2049"

La nouvelle connexion réussit. Vous avez réparé le réseau sans ouvrir NFS à 0.0.0.0/0 ni remplacer le système.

Restaurer le montage de B avec le point existant

Dans cette étape, connectez B au répertoire partagé existant sans remplacer les données de A.

Inspectez le point fourni avant de le monter :

aws efs \
  describe-access-points \
  --access-point-id "$AP_ID" \
  --query 'AccessPoints[].{ID:AccessPointId,Root:RootDirectory.Path,User:PosixUser}'

Sa racine est /uploads et son identité numérique correspond à l’utilisateur applicatif fourni. Les deux applications doivent choisir ce même point pour partager les fichiers. Ne créez pas un autre système et ne copiez pas les fichiers sur le disque local de B.

Montez-le sur B avec l’assistant officiel et TLS :

ssh -F ssh_config application-b \
  "sudo mkdir -p /srv/shared && sudo mount -t efs -o tls,stunnel,lookupcache=positive,accesspoint=${AP_ID} ${FS_ID}:/ /srv/shared"
ssh -F ssh_config application-b 'findmnt -t nfs4 /srv/shared'

lookupcache=positive revérifie sur le serveur les noms auparavant absents lorsqu’une autre application crée un fichier. Cela rend l’exercice court observable ; les réglages en production demandent une évaluation de performance séparée. Voir les options de cache NFS Linux.

B affiche NFS 4 sur /srv/shared. Son application utilise déjà ce répertoire ; la requête suivante lit directement EFS :

curl -i http://127.0.0.1:8082/uploads/original-upload.txt
ssh -F ssh_config application-a 'stat -c "%i %u:%g" /srv/shared/original-upload.txt'
ssh -F ssh_config application-b 'stat -c "%i %u:%g" /srv/shared/original-upload.txt'

B renvoie le contenu original et les deux hôtes montrent le même inode et propriétaire. Vous avez récupéré le fichier existant sans créer une autre copie.

Vérifier les nouveaux fichiers et la limite d’accès

Dans cette étape, prouvez que B écrit des fichiers partagés et que le client indépendant reste exclu.

Envoyez un nouveau fichier par B puis lisez-le par A :

curl -i -X PUT --data-binary 'Shared upload after connection repair' \
  http://127.0.0.1:8082/uploads/shared.txt
curl -i http://127.0.0.1:8081/uploads/shared.txt

B renvoie 201 Created, A 200 OK avec le même contenu. Dans AWS View, lisez shared.txt sur les deux cartes.

Le serveur de référence appartient à un autre groupe. Confirmez qu’il ne peut pas ouvrir une nouvelle connexion NFS :

ssh -F ssh_config reference-c "nc -zvw2 $MOUNT_IP 2049"

Cette connexion doit échouer avec un statut non nul. C’est la limite voulue, pas une autre panne applicative. Confirmez que son fichier indépendant reste disponible :

curl -i http://127.0.0.1:8083/uploads/reference.txt

Il renvoie 200 OK avec Unrelated reference upload remains unchanged. Les applications réparées et la référence conservent des périmètres réseau distincts.

Les applications lisent le même nouveau fichier après réparation. Les identifiants varient entre environnements.

Libérer le stockage

Dans cette étape, supprimez le stockage jetable après le test tout en conservant les hôtes et le réseau fournis.

Rétablissez les répertoires locaux des applications et démontez :

ssh -F ssh_config application-a \
  'printf "{\"upload_directory\":\"/srv/uploads\"}\n" | sudo tee /etc/uploads-app/config.json'
ssh -F ssh_config application-b \
  'printf "{\"upload_directory\":\"/srv/uploads\"}\n" | sudo tee /etc/uploads-app/config.json'
ssh -F ssh_config application-a 'sudo umount /srv/shared'
ssh -F ssh_config application-b 'sudo umount /srv/shared'

Les identifiants viennent de resources.json ; supprimez ces ressources exactes. Commencez par le point d’accès et la cible :

aws efs \
  delete-access-point \
  --access-point-id "$AP_ID"
aws efs \
  delete-mount-target \
  --mount-target-id "$MOUNT_TARGET_ID"
aws efs \
  describe-mount-targets \
  --file-system-id "$FS_ID"

Attendez que MountTargets soit vide puis supprimez le système et son groupe :

aws efs \
  delete-file-system \
  --file-system-id "$FS_ID"
aws ec2 \
  delete-security-group \
  --group-id "$EFS_GROUP_ID"

Confirmez des réponses réussies et vides :

aws efs \
  describe-file-systems \
  --query 'FileSystems[?Name==`fs03-shared-uploads`].FileSystemId'
aws ec2 \
  describe-security-groups \
  --filters Name=group-name,Values=fs03-efs-access \
  --query 'SecurityGroups[].GroupId'

Les listes de stockage doivent être vides. Conservez les serveurs, groupes originaux, sous-réseau et fichier de référence. Exécutez la vérification tant que les lectures autorisées sont possibles.

Résumé

Vous avez distingué disponibilité du stockage, accessibilité TCP, choix du montage et permissions. Vous avez réparé la règle avec le groupe des applications, restauré l’accès de B au fichier original et testé un fichier entre serveurs en excluant la référence. Enfin, vous avez supprimé le stockage dans l’ordre de dépendance.

Pour approfondir ce sujet, consultez la documentation AWS : Règles réseau des clients et cibles de montage; Diagnostiquer les délais d’attente et échecs d’accès au montage.