Подтвердить что ты не робот

Время ожидания подключения aws efs

Я следую этому руководству по установке efs на экземпляр AWS EC2, но когда Iam выполняет команду mount

sudo mount -t nfs4 -o vers=4.1 $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone).[EFS-ID].efs.[region].amazonaws.com:/ efs

Я получаю время подключения каждый раз.

mount.nfs4: Connection timed out

В чем может быть проблема?

Спасибо заранее!

4b9b3361

Ответ 1

Connection timed out в EFS происходит из-за того, что группа безопасности с портом 2049, открытым для группы безопасности экземпляра EC2, не добавляется в экземпляр EC2, на котором вы монтируете EFS. Добавление этой sec grp заставит проблему исчезнуть.

Редактировать:

Наряду с открытием порта 2049 необходимо добавить группу безопасности VPC по умолчанию для подключения efs к экземпляру ec2. Как уже упоминалось в учебнике

Это гарантирует, что экземпляр является членом группы безопасности, которую цель монтирования файловой системы Amazon EFS авторизует для подключения на шаге 2: создайте файловую систему Amazon EFS.

PS: я забыл добавить группу безопасности по умолчанию к экземпляру, поэтому я получаю ошибку тайм-аута соединения.

Ответ 2

Я нашел приемлемый ответ здесь неверным и небезопасным, и ответ Бао выше очень близок - за исключением того, что вам не нужна NFS Inbound в вашей группе безопасности EC2 (mount target). Вам просто нужна группа безопасности, назначенная вашему EC2 (даже без правил), чтобы ваша группа безопасности EFS могла быть ограничена этой группой безопасности... вы знаете, для безопасности! Вот что я нашел:

  • Создайте новую группу безопасности для своего экземпляра EC2. Назовите его EFS Target и оставьте все правила пустым
  • Создайте новую группу безопасности для вашего EFS Mount. Назовите его EFS Mount, и в этом добавьте правило inbound для NFS. Установите SOURCE для этого правила в группу безопасности EFS Target, созданную выше. Это ограничивает EFS только возможностью подключения к экземплярам EC2, для которых назначена группа безопасности EFS Mount (см. Ниже). Если вас это не беспокоит, вы можете выбрать "Any" из раскрывающегося списка "Источник", и он будет работать одинаково без добавленного уровня безопасности.
  • Перейдите в консоль EC2 и добавьте группу EFS Target в свой экземпляр EC2, предполагая, что вы добавляете дополнительную безопасность
  • Перейдите в консоль EFS, выберите свою EFS и выберите "Управление доступом к файловой системе"
    • Для каждого целевого объекта EFS Mount (зона доступности) вам необходимо добавить группу безопасности EFS Mount и удалить группу по умолчанию VPC (если вы еще этого не сделали)
  • Теперь команда mount в документации AWS должна работать

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

Ответ 3

Добавьте тип с NFS и порт 2049 во входящую группу безопасности, в которой запущены ваши экземпляры EC2 и EFS. Это работает для меня.

Бао

Ответ 4

У меня была та же проблема, и, следуя инструкциям Amazon AWS, она работала на одном моем сервере, но другой не хотел монтировать том EFS. Анализируя журнал сообщений локального сервера, я обнаружил, что исходящий TCP-трафик был заблокирован, даже если соответствующая группа безопасности была настроена для разрешения любого исходящего трафика (на любом порту, любом внешнем адресе и т.д.). Установка правила для группы безопасности, разрешающего TCP-подключения от хоста EC2 к службе EFS через порт 2049, не дала никакого эффекта, вместо этого задание определенного правила для локального межсетевого экрана iptable получило задание и решило проблему. Я не могу понять, почему произошло это несоответствие, но оно сработало для меня. Насколько я знаю, локальный iptables fw не следует трогать, и он должен получать правила непосредственно от SG с консоли AWS.

Ответ 5

Другой ответ здесь, поскольку я столкнулся с очень похожей ошибкой, и ни один из ответов не подходит.

Я пытался смонтировать NFS, как показано ниже (в моем случае EKS делал это от моего имени, но я тестировал ту же самую команду вручную на рабочем узле с тем же результатом):

[[email protected] ~]# mount -t nfs fs-abc1234.efs.us-east-1.amazonaws.com:/persistentvolumes /mnt/test

Вывод был: mount.nfs: Connection timed out

Когда я просто попробовал ту же команду, но используя / в качестве пути:

[[email protected] ~]# mount -t nfs fs-abc1234.efs.us-east-1.amazonaws.com:/ /mnt/test

Оно работало завораживающе!

Я действительно не понимаю, как возможный неправильный или отсутствующий путь может привести к ошибке time out, но это было единственное, что могло решить эту проблему для меня, все настройки сети остались прежними.

Поскольку я использовал EKS/Kubernetes, я решил смонтировать /, который работает, а затем с помощью subPath изменить точку монтирования тома в конфигурации контейнера.