Montage du système de fichiers élastique (EFS) en dehors d'AWS

J'ai un serveur en dehors d'AWS. J'aimerais pouvoir y monter un volume EFS, mais je ne sais pas si c'est possible.

Peut-être que si vous créez un VPC et que vous créez un tunnel sur VPN?

Est ce que quelqu'un sait si c'est possible?

Mises à jour importantes:

En octobre 2018, AWS a étendu les capacités de la technologie réseau sous-jacente à EFS afin qu'il fonctionne désormais de manière native sur les connexions VPN gérées et l'homologation VPC entre régions, sans recourir à la solution de contournement du proxy détaillée ci-dessous.

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

EFS a ajouté la prise en charge de la connectivité via les circuits AWS Direct Connect fin 2016.

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

Les commentaires ont soulevé des questions intéressantes, car dans ma première lecture de la question, j'ai peut-être supposé que vous connaissiez mieux l'EFS.

Donc, d'abord, un peu de contexte:

Le «Elastic» dans Elastic File System se réfère principalement à la mise à l'échelle automatique de l'espace de stockage et du débit - et non à la flexibilité d'accès externe.

EFS ne semble pas avoir de limites significatives sur la quantité de données que vous pouvez stocker. La taille maximale documentée de tout fichier unique sur un volume EFS est de 52 673 613 1335 872 octets (52 TiB) . La plupart des autres limites sont tout aussi généreuses.

L'EFS est particulièrement "élastique" dans la façon dont il est facturé. Contrairement aux systèmes de fichiers sur les volumes EBS, l'espace n'est pas préalloué sur EFS, et vous ne payez que ce que vous stockez sur une base horaire moyenne. Vos charges augmentent et diminuent (elles sont "élastiques") en fonction de la quantité que vous avez stockée. Lorsque vous supprimez des fichiers, vous cessez de payer pour l'espace qu'ils occupaient dans l'heure. Si vous stockez 1 Go pendant 750 heures (≅1 mois) puis le supprimez, ou si vous stockez 375 Go pendant 2 heures puis le supprimez, votre facture mensuelle serait la même ... 0,30 $. C'est bien sûr tout à fait différent d'EBS, qui vous facturera volontiers 37,50 $ pour le stockage de 375 Go 0x00pour les heures restantes du mois.

Le modèle de tarification du stockage de S3 est à peu près le même que celui d'EFS, car la facturation du stockage s'arrête dès que vous supprimez un objet, et le coût est ~ 1/10 du coût d'EFS, mais comme moi et d'autres l'avons mentionné à plusieurs reprises, S3 n'est pas un système de fichiers. Des utilitaires comme s3fs-fuse tentent de fournir un "pont d'impédance" mais il y a des difficultés inhérentes à essayer de traiter quelque chose qui n'est pas vraiment un système de fichiers comme si c'était le cas (la cohérence éventuelle pour les remplacements n'étant pas la moindre). Donc, si un véritable "système de fichiers" est ce dont vous avez besoin, et qu'il s'agit d'une application dont l'accès doit être partagé, ou l'espace de stockage requis est difficile à déterminer ou si vous souhaitez qu'il évolue à la demande, EFS peut être utile.

Et, ça a l'air cool quand vous avez 8,0 EiB d'espace libre.

$ 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

Mais il est bien sûr important d'utiliser le service de stockage le plus adapté à vos applications. Chacune des options a ses cas d'utilisation valides. EFS est probablement la plus spécialisée des solutions de stockage proposées par AWS, avec un ensemble de cas d'utilisation plus étroit que EBS ou S3.

Mais pouvez-vous l'utiliser depuis l'extérieur du VPC?

La réponse officielle est non :

Le montage d'un système de fichiers sur des mécanismes de connectivité privée VPC tels qu'une connexion VPN, l'homologation VPC et AWS Direct Connect n'est pas pris en charge.

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

EFS est actuellement limité à un accès Linux EC2 uniquement. Cela aussi au sein du VPC. Plus de fonctionnalités seront ajoutées bientôt. Vous pouvez garder un œil sur les annonces AWS pour les nouvelles fonctionnalités lancées.

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

Cependant, la réponse pratique est Oui , même s'il ne s'agit pas d'une configuration officiellement prise en charge. Pour le faire fonctionner, certaines étapes spéciales sont nécessaires.

Chaque système de fichiers EFS se voit attribuer des adresses IP de noeud final dans votre VPC à l'aide d'interfaces réseau élastiques (ENI), généralement une par zone de disponibilité, et vous voulez être sûr de monter celle dans la zone de disponibilité correspondant à l'instance, non seulement pour des raisons de performances, mais aussi également parce que des frais de bande passante s'appliquent lors du transport de données à travers les limites des zones de disponibilité.

La chose intéressante à propos de ces ENI est qu'elles ne semblent pas utiliser les tables de routage pour les sous-réseaux auxquels elles sont attachées. Ils semblent pouvoir répondre uniquement aux instances à l'intérieur du VPC, quels que soient les paramètres du groupe de sécurité (chaque système de fichiers EFS a son propre groupe de sécurité pour contrôler l'accès).

Puisqu'aucune route externe n'est accessible, je ne peux pas accéder aux points de terminaison EFS directement via mon VPN matériel ... alors je me suis tourné vers mon ancien copain HAProxy, qui en effet (comme @Tim l'a prédit) est nécessaire pour que cela fonctionne. C'est une configuration simple, car EFS utilise uniquement le port TCP 2049.

J'utilise HAProxy sur un t2.nano (HAProxy est très efficace), avec une configuration qui ressemble à ceci:

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

Ce serveur est dans us-east-1b, il utilise donc le point de terminaison us-east-1b comme principal, les deux autres comme sauvegardes si le point de terminaison dans 1b échoue un contrôle d'intégrité.

Si vous avez un VPN dans votre VPC, vous montez ensuite le volume en utilisant l'adresse IP de cette instance de proxy comme cible (au lieu d'utiliser directement le point de terminaison EFS), et voilà que vous avez monté le système de fichiers EFS depuis l'extérieur du VPC.

Je l'ai monté avec succès sur des machines Ubuntu externes ainsi que sur des serveurs Solaris¹ (où EFS s'est avéré très pratique pour accélérer leur mise hors service en facilitant la migration des services loin d'eux).

Dans certaines situations, comme le déplacement de données vers AWS ou l'exécution de systèmes hérités et cloud en parallèle sur des données spécifiques lors d'une migration, EFS semble être un gagnant.

Bien sûr, les systèmes hérités, ayant des temps d'aller-retour plus longs, ne fonctionneront pas aussi bien que les instances EC2, mais c'est normal - il n'y a pas d'exceptions aux lois de la physique. Malgré cela, EFS et la passerelle HAProxy semblent être une solution stable pour le faire fonctionner en externe.

Si vous n'avez pas de VPN, une paire de machines HAProxy, une dans AWS et une dans votre centre de données, peut également tunneler EFS sur TLS, établissant une connexion TCP individuelle avec la charge utile enveloppée dans TLS pour le transport de chaque EFS individuel connexion via Internet. Pas techniquement un VPN, mais un tunneling crypté des connexions. Cela semble également très bien fonctionner.

¹Solaris 10 est (sans surprise) quelque peu cassé par défaut - initialement, root ne semblait pas avoir de privilèges spéciaux - les fichiers sur le volume EFS créé par root appartiennent à root mais ne peuvent pas être chownédités à un autre utilisateur à partir de la Solaris machine ( Operation not permitted), même si tout fonctionne comme prévu des clients Ubuntu. Dans ce cas, la solution consiste à supprimer le démon de mappage d'ID NFS sur la machine Solaris à l'aide de svcadm disable svc:/network/nfs/mapid:default. L'arrêt de ce service fait que tout fonctionne comme prévu. De plus, l'invocation de /usr/sbin/quotasur chaque connexion doit être désactivée dans /etc/profile. Il peut y avoir des solutions meilleures ou plus correctes, mais c'est Solaris, donc je ne suis pas assez curieux pour enquêter.

Depuis le 20 décembre 2016, Amazon a annoncé AWS Direct Connect qui peut être utilisé pour monter un système de fichiers EFS sur des serveurs locaux. Donc, fondamentalement, il existe une fonctionnalité native qui vous permet d'utiliser AWS EFS en dehors du VPC.

Comme condition préalable, vous devrez activer et établir la connexion AWS Direct Connect, puis utiliser les nfs-utils comme vous devez utiliser lors du montage de l'EFS dans les instances EC2.

Plus d'informations peuvent être trouvées sur l' URL suivante . Je viens de poster ceci, car j'avais également cherché cet avenir, pour que les autres sachent qu'il existe une solution native pour la connectivité EFS en dehors du VPC.