Reparar uma conexão de montagem EFS

Introdução

A lê seus uploads compartilhados, mas B não consegue conectar ao mesmo EFS. Diagnostique a conexão, restaure a montagem de B e mantenha o acesso limitado aos servidores previstos.

Conclua primeiro os dois exercícios EFS anteriores. Este novo ambiente fornece sistema existente, ponto de acesso, upload original e hosts. Use AWS CLI configurada, SSH e AWS View; recursos anteriores ou conta AWS pessoal não são necessários.

Relação com certificações

Diagrama conceitual; confira os identificadores no novo ambiente.

Diagnosticar e reparar a regra de rede NFS

Nesta etapa, encontre a camada com falha e repare o grupo do armazenamento.

Trabalhe em /home/labex/project. resources.json contém os identificadores de armazenamento e aplicações:

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"

Leia o upload existente pelas duas aplicações:

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 retorna 200 OK com Original upload from application A; B retorna 404 Not Found. Confira as montagens:

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

A tem uma montagem NFS; B não tem e findmnt retorna estado 1. Antes de mudar caminhos ou permissões, teste se B alcança o ponto de conexão:

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"

A conexão falha. nc testa TCP sem criar uma montagem. Uma raiz ou identidade POSIX incorreta pode impedir arquivos após a conexão, mas não explica essa falha TCP.

Confirme que o destino está disponível e inspecione seu 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'

A regra permite TCP 2049 somente do endereço privado de A com CIDR /32, excluindo B. Substitua-a pela regra do grupo das aplicações:

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

Permita os dois membros do grupo:

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"

A nova conexão funciona. Você reparou a rede sem abrir NFS para 0.0.0.0/0 nem substituir o sistema.

Restaurar a montagem do ponto de acesso em B

Nesta etapa, conecte B ao diretório compartilhado existente sem substituir os dados de A.

Inspecione o ponto preparado antes de montar:

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

Sua raiz é /uploads e a identidade numérica corresponde ao usuário preparado. Ambas as aplicações devem usar o mesmo ponto para compartilhar uploads. Não crie outro sistema nem copie arquivos para o disco local de B.

Monte em B com o assistente oficial e 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 consulta novamente nomes antes ausentes quando outra aplicação cria um arquivo. Isso torna o exercício curto observável; ajustes de cache em produção exigem avaliação de desempenho separada. Veja as opções de cache NFS do Linux.

B mostra NFS 4 em /srv/shared. Sua aplicação já usa esse caminho, então a próxima solicitação lê EFS diretamente:

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 retorna o conteúdo original e ambos os hosts mostram o mesmo inode e proprietário. O acesso ao arquivo existente foi recuperado sem criar uma cópia.

Verificar novos uploads e o limite de acesso

Nesta etapa, prove a escrita compartilhada de B e a exclusão do cliente independente.

Envie um novo arquivo por B e leia por 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 retorna 201 Created; A retorna 200 OK com o mesmo conteúdo. Leia shared.txt nos dois cartões AWS View.

O servidor de referência pertence a outro grupo. Confirme que ele não consegue abrir uma nova conexão NFS:

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

A conexão deve falhar com estado diferente de zero. É o limite desejado, não outra falha da aplicação. Confira o upload independente da referência:

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

Ele retorna 200 OK com Unrelated reference upload remains unchanged. Aplicações e referência mantêm escopos de rede distintos.

As aplicações leem o mesmo novo upload após o reparo. Os identificadores variam entre ambientes.

Liberar o armazenamento

Nesta etapa, exclua o armazenamento descartável após o teste preservando hosts e rede preparados.

Restaure os diretórios locais e desmonte:

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'

Os identificadores vêm de resources.json; exclua exatamente esses recursos. Comece pelo ponto de acesso e 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"

Espere MountTargets ficar vazio e exclua sistema e grupo:

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

Confirme respostas bem-sucedidas e vazias:

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'

As listas de armazenamento devem estar vazias. Preserve servidores, grupos originais, sub-rede e upload de referência. Execute a verificação enquanto consultas autorizadas ainda estiverem disponíveis.

Resumo

Você separou disponibilidade do recurso, acesso TCP, seleção da montagem e permissões. Reparou a regra pelo grupo das aplicações, restaurou o arquivo original em B e testou um novo upload compartilhado mantendo a referência excluída. Finalmente removeu o armazenamento na ordem de dependência.

Para aprofundar o tema, consulte a documentação da AWS: Regras de rede do cliente e do destino de montagem; Diagnosticar tempos limite de montagem e falhas de acesso.