Aggiornamenti importanti:
Nell'ottobre 2018, AWS ha ampliato le capacità della tecnologia di rete alla base di EFS, in modo che ora funzioni nativamente attraverso connessioni VPN gestite e peering VPC inter-regione, senza ricorrere alla soluzione proxy descritta di seguito.
https://aws.amazon.com/about-aws/whats-new/2018/10/amazon-efs-now-supports-aws-vpn-and-inter-region-vpc-peering/
EFS ha aggiunto il supporto per la connettività tramite i circuiti AWS Direct Connect alla fine del 2016.
https://aws.amazon.com/blogs/aws/amazon-efs-update-on-premises-access-via-direct-connect-vpc/
I commenti hanno sollevato alcuni problemi interessanti, dal momento che nella mia lettura iniziale della domanda, potrei aver assunto più familiarità con EFS di quanto tu possa avere.
Quindi, prima di tutto, un po 'di background:
"Elastico" in Elastic File System si riferisce principalmente al ridimensionamento automatico dello spazio di archiviazione e della velocità effettiva, non alla flessibilità dell'accesso esterno.
EFS non sembra avere limiti significativi sulla quantità di dati che è possibile archiviare. La dimensione massima documentata di ogni singolo file su un volume EFS è 52.673.613.135.872 byte (52 TiB) . La maggior parte degli altri limiti è altrettanto generosa.
L'EFS è particolarmente "elastico" nel modo in cui viene fatturato. A differenza dei filesystem sui volumi EBS, lo spazio non è preallocato su EFS e si paga solo per ciò che si memorizza su base oraria media. Le tue cariche crescono e si riducono (sono "elastiche") in base a quanto hai archiviato. Quando elimini i file, smetti di pagare per lo spazio che occupavano entro un'ora. Se memorizzi 1 GB per 750 ore (≅1 mese) e poi lo elimini, o se memorizzi 375 GB per 2 ore e poi lo elimini, la tua fattura mensile sarebbe la stessa ... $ 0,30. Questo è ovviamente abbastanza diverso da EBS, che ti farà felice $ 37,50 per la memorizzazione di 375 GB 0x00per le restanti ore del mese.
Il modello di prezzi di archiviazione di S3 è molto simile a EFS, poiché la fatturazione per l'archiviazione si interrompe non appena si elimina un oggetto e il costo è ~ 1/10 del costo di EFS, ma come io e altri abbiamo già menzionato molte volte, S3 non è un filesystem. Utilità come s3fs-fuse tentano di fornire un "ponte di impedenza" ma ci sono difficoltà intrinseche nel tentativo di trattare qualcosa che non è veramente un filesystem come se lo fosse (l'eventuale coerenza per le sovrascritture non è la meno importante). Quindi, se un vero "filesystem" è ciò di cui hai bisogno, ed è per un'applicazione in cui l'accesso deve essere condiviso, o lo spazio di archiviazione ha bisogno di spazio è difficile da determinare o vuoi ridimensionarlo su richiesta, EFS può essere utile.
Inoltre, sembra interessante quando si dispone di 8,0 EiB di spazio libero.
$ 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
Ma è ovviamente importante utilizzare il servizio di archiviazione più appropriato per le tue applicazioni. Ciascuna delle opzioni ha i suoi casi d'uso validi. EFS è probabilmente la più specializzata delle soluzioni di archiviazione offerte da AWS, con un set più ristretto di casi d'uso rispetto a EBS o S3.
Ma puoi usarlo dall'esterno del VPC?
La risposta ufficiale è No :
Il montaggio di un file system su meccanismi di connettività privata VPC come una connessione VPN, peering VPC e AWS Direct Connect non è supportato.
- http://docs.aws.amazon.com/efs/latest/ug/limits.html
EFS è attualmente limitato al solo accesso EC2 Linux. Anche quello all'interno del VPC. Altre funzionalità verranno aggiunte presto. Puoi tenere d'occhio gli annunci AWS per le nuove funzionalità lanciate.
- https://forums.aws.amazon.com/thread.jspa?messageID=732749
Tuttavia, la risposta pratica è Sì , anche se questa non è una configurazione ufficialmente supportata. Per farlo funzionare, sono necessari alcuni passaggi speciali.
A ciascun file system EFS vengono assegnati indirizzi IP dell'endpoint nel VPC mediante interfacce di rete elastiche (ENI), in genere uno per zona di disponibilità e si desidera essere sicuri di montare quello nella zona di disponibilità corrispondente all'istanza, non solo per motivi di prestazioni, ma anche perché si applicano costi di larghezza di banda durante il trasporto dei dati attraverso i confini della zona di disponibilità.
La cosa interessante di queste ENI è che non sembrano usare le tabelle di instradamento per le sottoreti a cui sono collegate. Sembrano essere in grado di rispondere solo alle istanze all'interno del VPC, indipendentemente dalle impostazioni del gruppo di sicurezza (ogni file system EFS ha il proprio gruppo di sicurezza per controllare l'accesso).
Poiché non sono accessibili route esterne, non riesco ad accedere agli endpoint EFS direttamente tramite la mia VPN hardware ... quindi mi sono rivolto al mio vecchio amico HAProxy, che in effetti (come previsto da @Tim) è necessario per far funzionare questo. È una configurazione semplice, poiché EFS utilizza solo la porta TCP 2049.
Sto usando HAProxy su un t2.nano (HAProxy è molto efficiente), con una configurazione simile a questa:
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
Questo server si trova in us-east-1b, quindi utilizza l'endpoint us-east-1b come primario, gli altri due come backup se l'endpoint in 1b non supera mai un controllo di integrità.
Se si dispone di una VPN nel VPC, montare quindi il volume utilizzando come destinazione l'indirizzo IP di questa istanza proxy (anziché utilizzare direttamente l'endpoint EFS) e voilà è stato montato il filesystem EFS all'esterno del VPC.
L'ho montato con successo su macchine Ubuntu esterne e su server Solaris¹ (dove EFS si è dimostrato molto utile per accelerare la loro disattivazione facilitando la migrazione dei servizi da loro).
Per alcune situazioni, come lo spostamento di dati in AWS o l'esecuzione di sistemi legacy e cloud in parallelo su dati specifici durante una migrazione, EFS sembra un vincitore.
Naturalmente, i sistemi legacy, con tempi di andata e ritorno più alti, non funzioneranno come le istanze EC2, ma è prevedibile: non ci sono eccezioni alle leggi della fisica. Nonostante ciò, EFS e il gateway HAProxy sembrano essere una soluzione stabile per farlo funzionare esternamente.
Se non si dispone di una VPN, una coppia di macchine HAProxy, una in AWS e una nel proprio data center, può anche eseguire il tunneling di EFS su TLS, stabilendo una singola connessione TCP con il payload racchiuso in TLS per il trasporto di ogni singolo EFS connessione attraverso Internet. Tecnicamente non una VPN, ma tunneling crittografato di connessioni. Anche questo sembra funzionare abbastanza bene.
¹Solaris 10 è (non sorprendentemente) in qualche modo rotto per impostazione predefinita - inizialmente, root non sembrava avere privilegi speciali - i file sul volume EFS creati da root sono di proprietà di root ma non possono essere chowneditati a un altro utente dal Macchina Solaris ( Operation not permitted), anche se tutto funziona come previsto dai client Ubuntu. La soluzione, in questo caso, è quella di sconfiggere il demone di mapping degli ID NFS sulla macchina Solaris usando svcadm disable svc:/network/nfs/mapid:default. L'arresto di questo servizio fa funzionare tutto come previsto. Inoltre, è /usr/sbin/quotanecessario disabilitare l'invocazione di ogni accesso /etc/profile. Potrebbero esserci soluzioni migliori o più corrette, ma è Solaris, quindi non sono abbastanza curioso di indagare.