Важные обновления:
В октябре 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 свободного места.
$ df -h | egrep '^Filesystem|efs'
Filesystem Size Used Avail Use% Mounted on
us-west-2a.fs-5ca1ab1e.efs.us-west-2.amazonaws.com:/ 8.0E 121G 8.0E 1% /srv/efs/fs-5ca1ab1e
us-west-2a.fs-acce55ed.efs.us-west-2.amazonaws.com:/ 8.0E 7.2G 8.0E 1% /srv/efs/fs-acce55ed
Но, конечно, важно использовать сервис хранилища, наиболее подходящий для ваших приложений. Каждый из вариантов имеет свои допустимые варианты использования. EFS, вероятно, является наиболее специализированным из решений для хранения данных, предлагаемых AWS, с более узким набором вариантов использования, чем EBS или S3.
Но можете ли вы использовать его снаружи VPC?
Официальный ответ - нет :
Монтирование файловой системы через частные механизмы подключения VPC, такие как VPN-подключение, пиринг VPC и AWS Direct Connect, не поддерживается.
- http://docs.aws.amazon.com/efs/latest/ug/limits.html
В настоящее время EFS ограничен только доступом к EC2 Linux. Это тоже в рамках VPC. Дополнительные функции будут добавлены в ближайшее время. Вы можете следить за объявлениями AWS о появлении новых функций.
- https://forums.aws.amazon.com/thread.jspa?messageID=732749
Тем не менее, практический ответ - да , хотя это официально не поддерживаемая конфигурация. Чтобы это работало, требуются некоторые специальные шаги.
Каждой файловой системе EFS назначаются IP-адреса конечных точек в вашем VPC с использованием эластичных сетевых интерфейсов (ENI), обычно по одному на зону доступности, и вы хотите быть уверены, что монтируете один в зоне доступности, соответствующей экземпляру, не только по соображениям производительности, но и также потому, что плата за пропускную способность применяется при транспортировке данных через границы зоны доступности.
Интересно, что эти ENI не используют таблицы маршрутизации для подсетей, к которым они подключены. Кажется, что они могут отвечать только на экземпляры внутри VPC, независимо от настроек группы безопасности (каждая файловая система EFS имеет свою собственную группу безопасности для управления доступом).
Поскольку никакие внешние маршруты недоступны, я не могу получить доступ к конечным точкам EFS напрямую через аппаратную VPN ... поэтому я обратился к своему старому приятелю HAProxy, который действительно (как и предсказывал @Tim) необходим для этой работы. Это простая конфигурация, поскольку EFS использует только TCP-порт 2049.
Я использую HAProxy на t2.nano (HAProxy очень эффективен) с конфигурацией, которая выглядит примерно так:
listen fs-8d06f00d-us-east-1
bind :2049
mode tcp
option tcplog
timeout tunnel 300000
server fs-8d06f00d-us-east-1b us-east-1b.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000
server fs-8d06f00d-us-east-1c us-east-1c.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000 backup
server fs-8d06f00d-us-east-1d us-east-1d.fs-8d06f00d.efs.us-east-1.amazonaws.com:2049 check inter 60000 fastinter 15000 downinter 5000 backup
Этот сервер находится в 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, поэтому мне не интересно исследовать.