У меня есть сервер, который находится за пределами AWS. Я хотел бы иметь возможность подключить к нему том EFS, но я не уверен, возможно ли это.
Возможно, если вы создадите VPC и создадите туннель через VPN?
Кто-нибудь знает, возможно ли это?
У меня есть сервер, который находится за пределами AWS. Я хотел бы иметь возможность подключить к нему том EFS, но я не уверен, возможно ли это.
Возможно, если вы создадите VPC и создадите туннель через VPN?
Кто-нибудь знает, возможно ли это?
Ответы:
Важные обновления:
В октябре 2018 года AWS расширила возможности сетевой технологии, лежащей в основе EFS, и теперь она изначально работает через управляемые VPN-подключения и пиринг VPC между областями, не прибегая к обходному пути прокси, подробно описанному ниже.
https://aws.amazon.com/about-aws/whats-new/2018/10/amazon-efs-now-supports-aws-vpn-and-inter-region-vpc-peering/
В конце 2016 года EFS добавила поддержку подключения через каналы AWS Direct Connect.
https://aws.amazon.com/blogs/aws/amazon-efs-update-on-premises-access-via-direct-connect-vpc/
Комментарии подняли некоторые интересные вопросы, так как в моем первоначальном прочтении этого вопроса я мог предположить, что вы знакомы с EFS больше, чем вы.
Итак, сначала немного предыстории:
«Elastic» в Elastic File System относится в первую очередь к автоматическому масштабированию пространства хранения и пропускной способности, а не гибкости внешнего доступа.
EFS, похоже, не имеет каких-либо значимых ограничений на объем данных, которые вы можете хранить. Документированный максимальный размер любого отдельного файла на томе EFS составляет 52 673 613 135 872 байта (52 ТБ) . Большинство других ограничений также щедры.
EFS особенно «эластичен» в способе выставления счетов. В отличие от файловых систем на томах EBS, пространство в EFS не выделяется заранее, и вы платите только за то, что храните, в среднем за час. Ваши расходы растут и уменьшаются (они «эластичны») в зависимости от того, сколько вы сохранили. Когда вы удаляете файлы, вы перестаете платить за занимаемое ими пространство в течение часа. Если вы храните 1 ГБ в течение 750 часов (≅1 месяц) и затем удаляете его, или если вы сохраняете 375 ГБ в течение 2 часов, а затем удаляете его, ваш ежемесячный счет будет таким же ... $ 0,30. Это, конечно, сильно отличается от EBS, который с радостью выставит вам счет в размере 37,50 долл. США за хранение 375 ГБ
0x00
за оставшиеся часы месяца.Модель ценообразования S3 во многом аналогична EFS, так как выставление счетов за хранение прекращается, как только вы удаляете объект, а стоимость EFS составляет ~ 1/10 от стоимости EFS, но, как я и другие упоминали много раз, S3 не является файловая система. Утилиты, такие как s3fs-fuse, пытаются создать «мост импеданса», но существуют трудности при попытке обработать что-то, что на самом деле не является файловой системой, как если бы это было (конечная согласованность для перезаписывающих данных - не последняя из них). Таким образом, если вам нужна настоящая «файловая система», предназначенная для приложения, в котором доступ должен быть разделен, или требуется недостаточно места для хранения, или вы хотите, чтобы он масштабировался по требованию, EFS может оказаться полезной.
И это выглядит круто, когда у вас есть 8.0 EiB свободного места.
Но, конечно, важно использовать сервис хранилища, наиболее подходящий для ваших приложений. Каждый из вариантов имеет свои допустимые варианты использования. EFS, вероятно, является наиболее специализированным из решений для хранения данных, предлагаемых AWS, с более узким набором вариантов использования, чем EBS или S3.
Но можете ли вы использовать его снаружи VPC?
Официальный ответ - нет :
Тем не менее, практический ответ - да , хотя это официально не поддерживаемая конфигурация. Чтобы это работало, требуются некоторые специальные шаги.
Каждой файловой системе EFS назначаются IP-адреса конечных точек в вашем VPC с использованием эластичных сетевых интерфейсов (ENI), обычно по одному на зону доступности, и вы хотите быть уверены, что монтируете один в зоне доступности, соответствующей экземпляру, не только по соображениям производительности, но и также потому, что плата за пропускную способность применяется при транспортировке данных через границы зоны доступности.
Интересно, что эти ENI не используют таблицы маршрутизации для подсетей, к которым они подключены. Кажется, что они могут отвечать только на экземпляры внутри VPC, независимо от настроек группы безопасности (каждая файловая система EFS имеет свою собственную группу безопасности для управления доступом).
Поскольку никакие внешние маршруты недоступны, я не могу получить доступ к конечным точкам EFS напрямую через аппаратную VPN ... поэтому я обратился к своему старому приятелю HAProxy, который действительно (как и предсказывал @Tim) необходим для этой работы. Это простая конфигурация, поскольку EFS использует только TCP-порт 2049.
Я использую HAProxy на t2.nano (HAProxy очень эффективен) с конфигурацией, которая выглядит примерно так:
Этот сервер находится в us-east-1b, поэтому он использует конечную точку us-east-1b в качестве основной, а два других - в качестве резервных копий, если конечная точка в 1b не проходит проверку работоспособности.
Если у вас есть VPN в вашем VPC, вы затем монтируете том, используя IP-адрес этого экземпляра прокси-сервера в качестве цели (вместо того, чтобы использовать конечную точку EFS напрямую), и вуаля, вы смонтировали файловую систему EFS извне VPC.
Я успешно смонтировал его на внешних машинах Ubuntu, а также на серверах Solaris (где EFS оказалась очень удобной для ускорения их вывода из эксплуатации, упрощая миграцию служб с них).
В определенных ситуациях, например при переносе данных в AWS или параллельной работе с устаревшими и облачными системами на конкретных данных во время миграции, EFS кажется победителем.
Конечно, унаследованные системы с более высоким временем прохождения туда-обратно не будут работать так же хорошо, как экземпляры EC2, но это следовало ожидать - не существует исключений из законов физики. Несмотря на это, EFS и шлюз HAProxy, похоже, являются стабильным решением для внешней работы.
Если у вас нет VPN, то пара компьютеров HAProxy, одна в AWS и одна в вашем центре обработки данных, также может туннелировать EFS через TLS, устанавливая отдельное соединение TCP с полезной нагрузкой, заключенной в TLS, для передачи каждой отдельной EFS. соединение через интернет. Технически не VPN, а зашифрованное туннелирование соединений. Это также, кажется, работает довольно хорошо.
ArSolaris 10 (что неудивительно) по умолчанию несколько нарушено - изначально у root не было особых привилегий - файлы на томе EFS, создаваемом root, принадлежат root, но не могут быть
chown
изменены другим пользователем из Машина Solaris (Operation not permitted
), хотя все работает как ожидается от клиентов Ubuntu. Решение, в этом случае, состоит в том, чтобы победить демон сопоставления идентификаторов NFS на машине Solaris с помощьюsvcadm disable svc:/network/nfs/mapid:default
. Остановка этого сервиса заставляет все работать как ожидалось. Кроме того, вызов для/usr/sbin/quota
каждого входа в систему должен быть отключен в/etc/profile
. Возможно, есть лучшие или более правильные решения, но это Solaris, поэтому мне не интересно исследовать.источник
По состоянию на 20 декабря 2016 года Amazon анонсировала AWS Direct Connect, который можно использовать для монтирования файловой системы EFS на локальных серверах. Итак, в основном, есть встроенная функция, которая позволяет вам использовать AWS EFS вне VPC.
В качестве предварительного условия вам необходимо включить и установить соединение AWS Direct Connect, а затем использовать nfs-utils, которые вы должны использовать при монтировании EFS в экземплярах EC2.
Дополнительную информацию можно найти по следующему URL . Я только что опубликовал это, так как я тоже искал это будущее, чтобы другие знали, что есть родное решение для подключения EFS вне VPC.
источник