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.