EFS-Mount (Elastic File System) außerhalb von AWS

Ich habe einen Server außerhalb von AWS. Ich möchte ein EFS-Volume darauf mounten können, bin mir aber nicht sicher, ob dies möglich ist.

Vielleicht, wenn Sie eine VPC erstellen und einen Tunnel über VPN erstellen?

Weiß jemand, ob das möglich ist?

Wichtige Updates:

Im Oktober 2018 erweiterte AWS die Funktionen der Netzwerktechnologie, auf denen EFS basiert, so dass es nun nativ über verwaltete VPN-Verbindungen und überregionales VPC-Peering hinweg funktioniert, ohne auf die unten beschriebene Proxy-Problemumgehung zurückzugreifen.

https://aws.amazon.com/about-aws/whats-new/2018/10/amazon-efs-now-supports-aws-vpn-and-inter-region-vpc-peering/

EFS hat Ende 2016 Unterstützung für Konnektivität über AWS Direct Connect-Leitungen hinzugefügt.

https://aws.amazon.com/blogs/aws/amazon-efs-update-on-premises-access-via-direct-connect-vpc/

In den Kommentaren wurden einige interessante Fragen aufgeworfen, da ich bei meiner ersten Lektüre der Frage möglicherweise mehr mit EFS vertraut war als Sie.

Also zunächst ein bisschen Hintergrund:

Das "Elastic" im Elastic File System bezieht sich hauptsächlich auf die automatische Skalierung von Speicherplatz und Durchsatz - nicht auf die Flexibilität des externen Zugriffs.

EFS scheint keine sinnvollen Grenzen für die Datenmenge zu haben, die Sie speichern können. Die dokumentierte maximale Größe einer einzelnen Datei auf einem EFS-Volume beträgt 52.673.613.135.872 Byte (52 TiB) . Die meisten anderen Grenzen sind ähnlich großzügig.

EFS ist in der Art, wie es abgerechnet wird, besonders "elastisch". Im Gegensatz zu Dateisystemen auf EBS-Volumes ist der Speicherplatz in EFS nicht vorab zugeordnet, und Sie zahlen nur für das, was Sie im Stundendurchschnitt speichern. Ihre Ladungen wachsen und schrumpfen (sie sind "elastisch"), je nachdem, wie viel Sie gespeichert haben. Wenn Sie Dateien löschen, zahlen Sie nicht mehr für den Speicherplatz, den sie innerhalb einer Stunde belegt haben. Wenn Sie 1 GB für 750 Stunden (≅1 Monat) speichern und dann löschen, oder wenn Sie 375 GB für 2 Stunden speichern und dann löschen, ist Ihre monatliche Rechnung dieselbe ... 0,30 USD. Dies ist natürlich etwas ganz anderes als EBS, das Ihnen gerne 37,50 USD für die Speicherung von 375 GB 0x00für die verbleibenden Stunden im Monat in Rechnung stellt .

Das Speicher-Preismodell von S3 ist dem von EFS sehr ähnlich, da die Abrechnung für Speicher beendet wird, sobald Sie ein Objekt löschen, und die Kosten ~ 1/10 der Kosten von EFS betragen Dateisystem. Dienstprogramme wie s3fs-fuse versuchen, eine "Impedanzbrücke" bereitzustellen, aber es gibt inhärente Schwierigkeiten, etwas zu behandeln, das nicht wirklich ein Dateisystem ist, als wäre es (letztendlich ist die Konsistenz beim Überschreiben nicht die geringste davon). Wenn Sie also ein echtes "Dateisystem" benötigen und es für eine Anwendung gedacht ist, bei der der Zugriff gemeinsam genutzt werden muss oder der Speicherplatzbedarf schwer zu bestimmen ist oder bei Bedarf skaliert werden soll, ist EFS möglicherweise hilfreich.

Und es sieht cool aus, wenn Sie 8,0 EiB freien Speicherplatz haben.

$ 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

Es ist jedoch wichtig, den für Ihre Anwendungen am besten geeigneten Speicherdienst zu verwenden. Jede der Optionen hat ihre gültigen Anwendungsfälle. EFS ist wahrscheinlich die spezialisierteste der von AWS angebotenen Speicherlösungen und weist eine engere Gruppe von Anwendungsfällen auf als EBS oder S3.

Aber können Sie es von außerhalb der VPC verwenden?

Die offizielle Antwort lautet Nein :

Das Mounten eines Dateisystems über private VPC-Konnektivitätsmechanismen wie eine VPN-Verbindung, VPC-Peering und AWS Direct Connect wird nicht unterstützt.

- http://docs.aws.amazon.com/efs/latest/ug/limits.html

EFS ist derzeit nur auf den EC2-Linux-Zugriff beschränkt. Auch das innerhalb der VPC. Weitere Funktionen werden in Kürze hinzugefügt. Sie können die AWS-Ankündigungen für neu eingeführte Funktionen im Auge behalten.

- https://forums.aws.amazon.com/thread.jspa?messageID=732749

Die praktische Antwort lautet jedoch Ja , obwohl dies keine offiziell unterstützte Konfiguration ist. Damit es funktioniert, sind einige spezielle Schritte erforderlich.

Jedem EFS-Dateisystem werden Endpunkt-IP-Adressen in Ihrer VPC über elastische Netzwerkschnittstellen (ENI) zugewiesen, normalerweise eine pro Verfügbarkeitszone, und Sie möchten sicherstellen, dass Sie diejenige in der Verfügbarkeitszone bereitstellen, die der Instanz entspricht, nicht nur aus Leistungsgründen, sondern auch Dies liegt auch daran, dass beim Transport von Daten über die Grenzen der Verfügbarkeitszone hinweg Bandbreitengebühren anfallen.

Das Interessante an diesen ENIs ist, dass sie anscheinend nicht die Routing-Tabellen für die Subnetze verwenden, an die sie angeschlossen sind. Sie scheinen in der Lage zu sein, unabhängig von den Einstellungen der Sicherheitsgruppen nur auf Instanzen innerhalb der VPC zu reagieren (jedes EFS-Dateisystem verfügt über eine eigene Sicherheitsgruppe zur Zugriffssteuerung).

Da keine externen Routen verfügbar sind, kann ich nicht direkt über mein Hardware-VPN auf die EFS-Endpunkte zugreifen. Ich habe mich daher an meinen alten Freund HAProxy gewandt, der in der Tat (wie von @Tim vorhergesagt) erforderlich ist, damit dies funktioniert. Die Konfiguration ist unkompliziert, da EFS nur den TCP-Port 2049 verwendet.

Ich verwende HAProxy auf einer t2.nano (HAProxy ist sehr effizient) mit einer Konfiguration, die ungefähr so ​​aussieht:

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

Dieser Server befindet sich in us-east-1b. Daher wird der Endpunkt us-east-1b als primärer und die beiden anderen als Backup verwendet, falls der Endpunkt in 1b jemals eine Integritätsprüfung nicht besteht.

Wenn Sie einen VPN in Ihre VPC haben, montieren Sie dann die Lautstärke über die IP - Adresse dieser Proxy - Instanz als Ziel verwenden (anstelle der Verwendung der EFS Endpunkt direkt), und voilà Sie montiert haben die EFS Dateisystem von außerhalb der VPC.

Ich habe es erfolgreich auf externen Ubuntu-Rechnern sowie auf Solaris¹-Servern gemountet (wobei sich EFS als sehr nützlich erwiesen hat, um deren Außerbetriebnahme zu beschleunigen, indem es die Migration von Diensten von diesen erleichtert).

Für bestimmte Situationen, wie das Verschieben von Daten in AWS oder das parallele Ausführen von Legacy- und Cloud-Systemen auf bestimmten Daten während einer Migration, scheint EFS ein Gewinner zu sein.

Natürlich funktionieren die älteren Systeme mit höheren Umlaufzeiten nicht so gut wie EC2-Instanzen, aber das ist zu erwarten - es gibt keine Ausnahmen von den Gesetzen der Physik. Trotzdem scheinen EFS und das HAProxy-Gateway eine stabile Lösung für den externen Betrieb zu sein.

Wenn Sie kein VPN haben, können zwei HAProxy-Maschinen, eine in AWS und eine in Ihrem Rechenzentrum, EFS über TLS tunneln und so eine individuelle TCP-Verbindung mit der in TLS verpackten Nutzlast für den Transport jedes einzelnen EFS herstellen Verbindung über das Internet. Technisch gesehen kein VPN, sondern verschlüsseltes Tunneling von Verbindungen. Dies scheint auch recht gut zu funktionieren.

¹Solaris 10 ist (nicht überraschend) standardmäßig fehlerhaft - anfangs schien root keine besonderen Berechtigungen zu haben - Dateien auf dem von root erstellten EFS-Volume gehören root, können jedoch nicht von root chownan einen anderen Benutzer weitergeleitet werden Solaris-Maschine ( Operation not permitted), obwohl alles wie von Ubuntu-Clients erwartet funktioniert. In diesem Fall besteht die Lösung darin, den NFS-ID-Zuordnungsdämon auf dem Solaris-Computer mithilfe von zu deaktivieren svcadm disable svc:/network/nfs/mapid:default. Wenn Sie diesen Dienst beenden, funktioniert alles wie erwartet. Außerdem muss der Aufruf von /usr/sbin/quotabei jedem Login in deaktiviert werden /etc/profile. Es gibt vielleicht bessere oder korrektere Lösungen, aber es ist Solaris, daher bin ich nicht neugierig genug, dies zu untersuchen.

Am 20. Dezember 2016 kündigte Amazon AWS Direct Connect an, mit dem ein EFS-Dateisystem auf lokalen Servern bereitgestellt werden kann. Grundsätzlich gibt es also eine native Funktion, mit der Sie AWS EFS außerhalb der VPC verwenden können.

Voraussetzung ist, dass Sie die AWS Direct Connect-Verbindung aktivieren und herstellen und dann die nfs-utils verwenden, die Sie beim Mounten des EFS in den EC2-Instanzen verwenden sollten.

Weitere Informationen finden Sie unter der folgenden URL . Ich habe dies gerade gepostet, da ich auch nach dieser Zukunft gesucht habe, damit andere wissen, dass es die native Lösung für die EFS-Konnektivität außerhalb der VPC gibt.