Важливі оновлення:
У жовтні 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, ніж ви можете.
Отже, спочатку трохи тла:
"Еластичний" в системі еластичних файлів відноситься насамперед до автоматичного масштабування місця зберігання та пропускної здатності, а не до зовнішньої гнучкості доступу.
Здається, EFS не має жодних значущих обмежень щодо кількості даних, які можна зберігати. Задокументований максимальний розмір будь-якого одного файлу на томі EFS становить 52,673,613,135,872 байт (52 TiB) . Більшість інших меж аналогічно щедрі.
EFS особливо "еластичний" у способі його виставлення рахунків. На відміну від файлових систем на томах EBS, простір не виділяється на EFS, і ви платите лише за те, що зберігаєте щорічно в середньому. Ваші збори зростають і зменшуються (вони "еластичні") залежно від того, скільки ви зберегли. Коли ви видаляєте файли, ви припиняєте платити за місце, яке вони займали протягом години. Якщо ви зберігаєте 1 Гб протягом 750 годин (≅1 місяць), а потім видаляєте його, або якщо ви зберігаєте 375 Гб протягом 2 годин, а потім видаляєте, ваш щомісячний рахунок буде таким самим ... 0,30 долара. Це, звичайно, зовсім інше, ніж EBS, який із задоволенням виставить вам $ 37,50 за зберігання 375 Гб 0x00протягом решти годин у місяці.
Модель ціноутворення на зберігання S3 майже така ж, як і EFS, оскільки виставлення рахунків за зберігання припиняється, як тільки ви видаляєте об'єкт, а вартість становить ~ 1/10 вартість EFS, але, як я та інші згадували багато разів, S3 не є файлова система. Такі утиліти, як s3fs-fuse, намагаються надати "імпедансний міст", але є притаманні труднощі при спробі трактувати щось, що насправді не є файловою системою, як ніби це (можлива послідовність перезаписів не є найменшою з них). Отже, якщо справжня "файлова система" - це те, що вам потрібно, і це для програми, де доступ повинен бути спільним, або потрібний простір для зберігання важко визначити або ви хочете, щоб він масштабувався за потребою, EFS може бути корисним.
І це виглядає круто, коли у вас 8,0 Ебі вільного місця.
$ 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 peering та 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
Цей сервер знаходиться у нас-схід-1b, тому він використовує кінцеву точку us-east-1b як основну, інші два як резервні копії, якщо кінцева точка в 1b коли-небудь не проводить перевірку здоров’я.
Якщо у вашому VPC є VPN, то ви змонтуєте гучність, використовуючи IP-адресу цього проксі-екземпляра як цільову (замість того, щоб використовувати кінцеву точку EFS безпосередньо), і voilà ви встановили файлову систему EFS за межами VPC.
Я успішно встановив його на зовнішніх машинах Ubuntu, а також на серверах Solaris¹ (де EFS виявився дуже зручним для прискорення їх виведення з експлуатації, полегшивши міграцію служб подалі від них).
У певних ситуаціях, наприклад, переміщення даних в AWS або паралельне використання застарілих та хмарних систем на конкретних даних під час міграції, EFS здається переможцем.
Звичайно, застарілі системи, які мають більший час в обидва кінці, не будуть працювати так добре, як випадки EC2, але цього можна очікувати - винятків із законів фізики немає. Незважаючи на це, EFS та шлюз HAProxy здаються стабільним рішенням для того, щоб він працював зовні.
Якщо у вас немає VPN, пара HAProxy-машин, одна в AWS та друга у вашому центрі даних, також може тунелювати EFS через TLS, встановлюючи індивідуальне TCP-з'єднання з корисним навантаженням, загорнутим у TLS для транспортування кожного окремого EFS підключення через Інтернет. Технічно не VPN, але зашифроване тунелювання з'єднань. Це також, здається, працює досить добре.
OSolaris 10 за замовчуванням дещо зламаний - спочатку, як видається, root не має спеціальних привілеїв - файли на томі EFS, створені коренем, є власністю root, але не можуть бути chownвідредаговані іншим користувачем від Solaris machine ( Operation not permitted), хоча все працює так, як очікували від клієнтів Ubuntu. Рішенням в цьому випадку є перемогти демона NFS-ідентифікатора на карті Solaris за допомогою svcadm disable svc:/network/nfs/mapid:default. Якщо зупинити цю послугу, все працює як слід. Крім того, /usr/sbin/quotaпотрібно вимкнути виклик кожного входу /etc/profile. Можливо, є кращі чи правильніші рішення, але це Solaris, тому я не досить цікавий для дослідження.