Ważne aktualizacje:
W październiku 2018 r. AWS rozszerzył możliwości technologii sieciowej, na której opiera się EFS, dzięki czemu teraz działa on natywnie na zarządzanych połączeniach VPN i peeringach między regionami VPC, bez uciekania się do obejścia proxy opisanego poniżej.
https://aws.amazon.com/about-aws/whats-new/2018/10/amazon-efs-now-supports-aws-vpn-and-inter-region-vpc-peering/
EFS dodał obsługę połączeń za pośrednictwem obwodów AWS Direct Connect pod koniec 2016 r.
https://aws.amazon.com/blogs/aws/amazon-efs-update-on-premises-access-via-direct-connect-vpc/
Komentarze podniosły kilka interesujących kwestii, ponieważ w początkowym czytaniu pytania mogłem nabrać większej znajomości EFS niż ty.
Najpierw trochę tła:
„Elastyczny” w elastycznym systemie plików odnosi się przede wszystkim do automatycznego skalowania przestrzeni dyskowej i przepustowości, a nie elastyczności dostępu zewnętrznego.
EFS nie wydaje się mieć żadnych znaczących ograniczeń dotyczących ilości danych, które można przechowywać. Udokumentowany maksymalny rozmiar dowolnego pojedynczego pliku w woluminie EFS wynosi 52 673 613 133 135 872 bajtów (52 TiB) . Większość pozostałych limitów jest podobnie hojna.
EFS jest szczególnie „elastyczny” w sposobie rozliczania. W przeciwieństwie do systemów plików na woluminach EBS, przestrzeń nie jest wstępnie przydzielana w systemie EFS i płacisz tylko za to, co przechowujesz na podstawie średniej godzinowej. Twoje ładunki rosną i kurczą się (są „elastyczne”) w zależności od tego, ile przechowujesz. Po usunięciu plików przestajesz płacić za zajmowane miejsce w ciągu godziny. Jeśli przechowujesz 1 GB przez 750 godzin (≅ 1 miesiąc), a następnie go usuwasz, lub jeśli przechowujesz 375 GB przez 2 godziny, a następnie je usuwasz, miesięczny rachunek będzie taki sam ... 0,30 USD. Jest to oczywiście coś zupełnie innego niż EBS, który z radością obciąży Cię kwotą 37,50 USD za przechowywanie 375 GB 0x00na pozostałe godziny w miesiącu.
Model wyceny pamięci masowej S3 jest bardzo podobny do EFS, ponieważ fakturowanie pamięci masowej zatrzymuje się natychmiast po usunięciu obiektu, a koszt wynosi ~ 1/10 kosztu pamięci masowej EFS, ale jak wielokrotnie wspominaliśmy ja i inni, S3 nie jest system plików. Narzędzia takie jak s3fs-fuse próbują zapewnić „mostek impedancji”, ale istnieją nieodłączne trudności w traktowaniu czegoś, co nie jest tak naprawdę systemem plików, jak gdyby to był (ewentualna spójność nadpisywania nie jest najmniejszą z nich). Tak więc, jeśli potrzebujesz prawdziwego „systemu plików” i jest to aplikacja, w której dostęp musi być współużytkowany, lub trudno jest określić wymaganą przestrzeń dyskową lub chcesz skalować ją na żądanie, EFS może być przydatny.
I wygląda świetnie, gdy masz 8,0 EiB wolnej przestrzeni.
$ 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
Ale ważne jest, aby korzystać z usługi przechowywania najbardziej odpowiedniej dla twoich aplikacji. Każda z opcji ma prawidłowe przypadki użycia. EFS jest prawdopodobnie najbardziej wyspecjalizowanym rozwiązaniem pamięci masowej oferowanym przez AWS, posiadającym węższy zestaw przypadków użycia niż EBS lub S3.
Ale czy możesz użyć go spoza VPC?
Oficjalna odpowiedź brzmi : nie :
Montowanie systemu plików za pomocą prywatnych mechanizmów łączności VPC, takich jak połączenie VPN, peering VPC i AWS Direct Connect, nie jest obsługiwane.
- http://docs.aws.amazon.com/efs/latest/ug/limits.html
EFS jest obecnie ograniczony tylko do dostępu EC2 do Linuksa. To także w VPC. Wkrótce zostaną dodane kolejne funkcje. Możesz śledzić ogłoszenia AWS dotyczące uruchomionych nowych funkcji.
- https://forums.aws.amazon.com/thread.jspa?messageID=732749
Jednak praktyczną odpowiedzią jest Tak , mimo że nie jest to oficjalnie obsługiwana konfiguracja. Aby to działało, konieczne są specjalne kroki.
Do każdego systemu plików EFS przypisano końcowe adresy IP w komputerze VPC przy użyciu elastycznych interfejsów sieciowych (ENI), zwykle po jednym dla każdej strefy dostępności, i chcesz mieć pewność, że zainstalujesz ten w strefie dostępności pasujący do instancji, nie tylko ze względu na wydajność, ale również również dlatego, że obowiązują opłaty za przepustowość podczas przesyłania danych przez granice stref dostępności.
Interesującą rzeczą w tych ENI jest to, że wydają się nie używać tabel tras dla podsieci, do których są przyłączone. Wydaje się, że mogą reagować tylko na instancje wewnątrz VPC, niezależnie od ustawień grupy zabezpieczeń (każdy system plików EFS ma własną grupę zabezpieczeń do kontroli dostępu).
Ponieważ żadne trasy zewnętrzne nie są dostępne, nie mogę uzyskać dostępu do punktów końcowych EFS bezpośrednio przez moją sprzętową sieć VPN ... więc zwróciłem się do mojego starego kumpla HAProxy, który rzeczywiście (jak przewidywano @Tim) jest konieczny, aby to zadziałało. Jest to prosta konfiguracja, ponieważ EFS używa tylko portu TCP 2049.
Używam HAProxy na t2.nano (HAProxy jest bardzo wydajny), z konfiguracją, która wygląda mniej więcej tak:
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
Ten serwer znajduje się w us-east-1b, więc używa punktu końcowego us-east-1b jako podstawowego, a dwa pozostałe jako kopii zapasowych, jeśli punkt końcowy w 1b kiedykolwiek nie przejdzie kontroli poprawności.
Jeśli masz VPN w swoim VPC, następnie podłącz wolumin, używając adresu IP tej instancji proxy jako celu (zamiast bezpośrednio używać punktu końcowego EFS) i voilà podłączyłeś system plików EFS spoza VPC.
Z powodzeniem zamontowałem go na zewnętrznych maszynach Ubuntu, a także serwerach Solaris¹ (gdzie EFS okazał się bardzo przydatny w przyspieszaniu ich wycofywania z użytku, ułatwiając migrację usług z dala od nich).
W niektórych sytuacjach, takich jak przenoszenie danych do AWS lub równoległe uruchamianie starszych systemów chmurowych na określonych danych podczas migracji, EFS wydaje się być zwycięzcą.
Oczywiście starsze systemy, posiadające dłuższy czas podróży w obie strony, nie będą działać tak dobrze, jak instancje EC2, ale należy się tego spodziewać - nie ma wyjątków od praw fizyki. Mimo to EFS i brama HAProxy wydają się stabilnym rozwiązaniem umożliwiającym działanie na zewnątrz.
Jeśli nie masz VPN, to para maszyn HAProxy, jedna w AWS i jedna w twoim centrum danych, może również tunelować EFS przez TLS, ustanawiając indywidualne połączenie TCP z ładunkiem opakowanym w TLS na potrzeby transportu każdego EFS połączenie przez Internet. Nie technicznie VPN, ale szyfrowane tunelowanie połączeń. To także wydaje się działać całkiem dobrze.
¹ Solaris 10 jest (co nie dziwi) domyślnie nieco zepsuty - początkowo root nie wydawał się mieć specjalnych uprawnień - pliki na woluminie EFS utworzone przez root są własnością root, ale nie można ich edytować chowndla innego użytkownika z Solaris machine ( Operation not permitted), mimo że wszystko działa zgodnie z oczekiwaniami klientów Ubuntu. Rozwiązaniem w tym przypadku jest pokonanie demona mapowania identyfikatora NFS na komputerze Solaris svcadm disable svc:/network/nfs/mapid:default. Zatrzymanie tej usługi sprawia, że wszystko działa zgodnie z oczekiwaniami. Ponadto wywołanie /usr/sbin/quotaprzy każdym logowaniu musi być wyłączone w /etc/profile. Mogą istnieć lepsze lub bardziej poprawne rozwiązania, ale to Solaris, więc nie jestem wystarczająco ciekawy, aby to zbadać.