Исправить подключение монтирования EFS

Введение

A читает общие загрузки, но B не подключается к тому же EFS. Диагностируйте соединение, восстановите монтирование B и сохраните доступ только для нужных серверов приложений.

Сначала завершите две предыдущие практики EFS. Новая среда содержит существующую систему, точку доступа, исходную загрузку и узлы. Используйте настроенную AWS CLI, SSH и AWS View; ресурсы прежней VM и личная учётная запись AWS не нужны.

Связь с сертификацией

Схема концептуальная; идентификаторы смотрите в новой среде.

Диагностировать и исправить правило NFS

На этом шаге найдите сбойный уровень и исправьте группу хранилища.

Работайте в /home/labex/project. resources.json содержит идентификаторы хранилища и приложений:

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"

Прочитайте существующую загрузку через оба приложения:

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 возвращает 200 OK с Original upload from application A, B — 404 Not Found. Проверьте монтирования:

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

У A есть NFS, у B его нет; findmnt возвращает 1. Прежде чем менять пути или права, проверьте доступ B к сетевой точке:

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"

Соединение не устанавливается. nc проверяет TCP без монтирования. Неверный корень или POSIX-идентичность может мешать файлам после подключения, но не объясняет этот TCP-сбой.

Подтвердите доступность цели и изучите её группу:

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'

Правило разрешает TCP 2049 только частному адресу A через CIDR /32, исключая B. Замените его правилом группы приложений:

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

Разрешите обоих участников группы:

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"

Новое соединение успешно. Сеть исправлена без открытия NFS для 0.0.0.0/0 и без замены файловой системы.

Восстановить монтирование точки доступа на B

На этом шаге подключите B к существующему общему каталогу без замены данных A.

Проверьте подготовленную точку перед монтированием:

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

Корень — /uploads, числовая идентичность соответствует пользователю приложения. Для общих загрузок обеим приложениям нужна одна точка. Не создавайте другую систему и не копируйте файлы на локальный диск B.

Смонтируйте на B официальным помощником с 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 повторно проверяет ранее отсутствовавшие имена после создания файла другим приложением. Так результаты короткого упражнения видимы; кеш в рабочей среде требует отдельной оценки производительности. См. параметры кеша Linux NFS.

B показывает NFS 4 в /srv/shared. Приложение уже настроено на этот путь, поэтому следующий запрос читает 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 возвращает оригинальный текст, inode и владельцы совпадают на обоих узлах. Доступ к существующему файлу восстановлен без копии.

Проверить новые загрузки и границу доступа

На этом шаге докажите общую запись B и исключение независимого клиента.

Загрузите через B и прочитайте через 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 возвращает 201 Created, A — 200 OK с тем же текстом. Прочитайте shared.txt на двух карточках AWS View.

Контрольный сервер состоит в другой группе. Проверьте невозможность нового NFS-соединения:

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

Соединение должно завершиться ненулевым статусом. Это нужная граница, а не новая неисправность приложения. Проверьте независимый контрольный файл:

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

Он возвращает 200 OK с Unrelated reference upload remains unchanged. Приложения и контрольный сервис сохраняют разные сетевые области.

Оба приложения читают новый общий файл. Идентификаторы различаются между средами.

Освободить хранилище

На этом шаге удалите временный ресурс после теста и сохраните подготовленные узлы и сеть.

Верните локальные каталоги приложений и размонтируйте:

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'

Удаляйте только точные идентификаторы из resources.json. Начните с точки доступа и цели монтирования:

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"

Дождитесь пустого MountTargets, затем удалите систему и группу хранилища:

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

Подтвердите успешные пустые ответы:

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'

Списки хранилища должны быть пустыми. Сохраните серверы, исходные группы, подсеть и контрольный файл. Запустите проверку, пока авторизованные чтения ещё доступны.

Резюме

Вы различили состояние ресурса, TCP-доступность, выбор монтирования и файловые права. Исправили правило через группу приложений, восстановили исходный файл на B и проверили новую общую загрузку, оставив контрольный клиент исключённым. Затем удалили хранилище в порядке зависимостей.

Подробнее см. в документации AWS: Сетевые правила клиентов и целей монтирования; Диагностика тайм-аутов монтирования и отказов доступа.