Reparar una conexión de montaje EFS

Introducción

A lee sus cargas compartidas, pero B no puede conectar con el mismo EFS. Diagnostica la conexión, restaura el montaje de B y conserva el acceso limitado a las aplicaciones previstas.

Completa primero las dos prácticas EFS anteriores. Este entorno nuevo proporciona el sistema existente, el punto de acceso, la carga original y los servidores. Usa AWS CLI configurada, SSH y AWS View; no necesitas recursos anteriores ni una cuenta AWS personal.

Relación con certificaciones

Esquema conceptual; consulta los identificadores reales del entorno nuevo.

Diagnosticar y reparar la regla NFS

En este paso, identifica la capa que falla y repara el grupo de seguridad del almacenamiento.

Trabaja en /home/labex/project. resources.json registra los identificadores de almacenamiento y aplicaciones:

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"

Lee la carga existente mediante ambas aplicaciones:

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 devuelve 200 OK con Original upload from application A; B devuelve 404 Not Found. Inspecciona sus montajes:

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

A tiene un montaje NFS. B no tiene ninguno y findmnt devuelve estado 1. Antes de cambiar rutas o permisos, comprueba si B llega al punto de conexión:

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 conexión falla. nc prueba TCP sin crear un montaje. Una raíz o identidad POSIX incorrecta puede impedir acceso a archivos después de conectar, pero no explica este fallo TCP.

Confirma que el destino está disponible y revisa su grupo:

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 regla permite TCP 2049 solo desde la dirección privada de A con CIDR /32. Incluye únicamente A y excluye B. Sustitúyela por una regla del grupo de aplicaciones:

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

Permite a ambos miembros del grupo de aplicaciones:

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 conexión nueva funciona. Reparaste la red sin abrir NFS a 0.0.0.0/0 ni reemplazar el sistema.

Restaurar el montaje de B con el punto existente

En este paso, conecta B al directorio compartido existente sin reemplazar los datos de A.

Inspecciona el punto proporcionado antes de montarlo:

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

Su raíz es /uploads y su identidad numérica corresponde al usuario preparado. Ambas aplicaciones deben elegir el mismo punto para compartir cargas. No crees otro sistema ni copies archivos al disco local de B.

Móntalo en B con el asistente oficial y 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 vuelve a consultar nombres antes ausentes cuando otra aplicación crea un archivo. Hace observable esta práctica breve; los ajustes de caché en producción necesitan evaluar rendimiento por separado. Consulta las opciones de caché NFS de Linux.

B muestra NFS 4 en /srv/shared. La aplicación ya usa ese directorio, así que la siguiente solicitud lee EFS directamente:

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 devuelve el contenido original y ambos servidores muestran el mismo inode y propietario. Recuperaste acceso al archivo existente sin crear otra copia.

Verificar nuevas cargas y el límite de acceso

En este paso, demuestra que B escribe archivos compartidos y que el cliente ajeno permanece excluido.

Carga un archivo mediante B y léelo mediante 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 devuelve 201 Created; A devuelve 200 OK con el mismo contenido. En AWS View, lee shared.txt desde ambas tarjetas.

El servidor de referencia pertenece a otro grupo. Confirma que no puede abrir una conexión NFS nueva:

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

La conexión debe fallar con estado distinto de cero. Es el límite deseado, no otro fallo de la aplicación. Confirma que su carga independiente sigue disponible:

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

Devuelve 200 OK y Unrelated reference upload remains unchanged. Las aplicaciones reparadas y la referencia conservan ámbitos de red distintos.

Ambas aplicaciones leen la misma carga nueva después de reparar la conexión. Los identificadores varían entre entornos.

Liberar el almacenamiento

En este paso, elimina el almacenamiento desechable después de probar la reparación y conserva los recursos preparados.

Restaura los directorios locales de ambas aplicaciones y desmonta:

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'

Los identificadores proceden de resources.json; elimina esos recursos exactos. Empieza por el punto de acceso y el destino:

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"

Espera a que MountTargets esté vacío y elimina el sistema y su grupo:

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

Confirma respuestas correctas y vacías:

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'

Las listas de almacenamiento deben estar vacías. Conserva servidores, grupos originales, subred y carga de referencia. Ejecuta la comprobación mientras aún puedas realizar consultas autorizadas.

Resumen

Distinguiste disponibilidad del recurso, conectividad TCP, selección del montaje y permisos. Reparaste la regla con el grupo de aplicaciones, restauraste el archivo original en B y probaste una carga entre servidores manteniendo excluida la referencia. Finalmente eliminaste el almacenamiento en orden de dependencia.

Para ampliar este tema, consulta la referencia de AWS: Reglas de red del cliente y del destino de montaje; Diagnosticar tiempos de espera y fallos de acceso al montar.