Pembaruan penting:
Pada bulan Oktober, 2018, AWS memperluas kemampuan teknologi jaringan yang menopang EFS sehingga sekarang bekerja secara alami di seluruh koneksi VPN yang dikelola dan peeling VPC lintas wilayah, tanpa menggunakan solusi proxy yang dirinci di bawah ini.
https://aws.amazon.com/about-aws/whats-new/2018/10/amazon-efs-now-supports-aws-vpn-and-inter-region-vpc-peering/
EFS menambahkan dukungan untuk konektivitas melalui sirkuit AWS Direct Connect pada akhir 2016.
https://aws.amazon.com/blogs/aws/amazon-efs-update-on-premises-access-via-direct-connect-vpc/
Komentar telah menimbulkan beberapa masalah menarik, karena dalam membaca awal saya atas pertanyaan ini, saya mungkin telah mengasumsikan lebih akrab dengan EFS daripada yang mungkin Anda miliki.
Jadi, pertama, sedikit latar belakang:
"Elastis" dalam Sistem File Elastis merujuk terutama pada penskalaan otomatis ruang penyimpanan dan throughput - bukan fleksibilitas akses eksternal.
EFS tampaknya tidak memiliki batasan yang berarti pada jumlah data yang dapat Anda simpan. Ukuran maksimum yang didokumentasikan dari setiap file tunggal pada volume EFS adalah 52.673.613.135.872 byte (52 TiB) . Sebagian besar batasan lainnya juga murah hati.
EFS sangat "elastis" dalam hal tagihannya. Tidak seperti sistem file pada volume EBS, ruang tidak dialokasikan sebelumnya pada EFS, dan Anda hanya membayar untuk apa yang Anda simpan pada basis rata-rata per jam. Tagihan Anda bertambah dan menyusut ("elastis") berdasarkan pada jumlah yang Anda simpan. Ketika Anda menghapus file, Anda berhenti membayar untuk ruang yang mereka tempati dalam waktu satu jam. Jika Anda menyimpan 1 GB selama 750 jam (month1 bulan) lalu menghapusnya, atau jika Anda menyimpan 375 GB selama 2 jam dan kemudian menghapusnya, tagihan bulanan Anda akan sama ... $ 0.30. Ini tentu saja sangat berbeda dari EBS, yang dengan senang hati akan menagih Anda $ 37,50 untuk menyimpan 375 GB 0x00untuk sisa jam dalam sebulan.
Model penetapan harga penyimpanan S3 sama dengan EFS, karena penagihan untuk penyimpanan berhenti segera setelah Anda menghapus suatu objek, dan biayanya ~ 1/10 biaya EFS, tetapi seperti yang saya dan yang lain telah sebutkan berkali-kali, S3 bukan berkas sistem. Utilitas seperti upaya sekering s3fs untuk memberikan "jembatan impedansi" tetapi ada kesulitan yang melekat dalam mencoba untuk memperlakukan sesuatu yang sebenarnya bukan sistem file seolah-olah itu (konsistensi akhirnya untuk overwrite bukan yang paling penting). Jadi, jika "filesystem" nyata adalah yang Anda butuhkan, dan itu untuk aplikasi di mana akses perlu dibagi, atau ruang penyimpanan yang dibutuhkan sulit untuk ditentukan atau Anda ingin skala pada permintaan, EFS mungkin berguna.
Dan, ini terlihat keren ketika Anda memiliki 8.0 EiB ruang kosong.
$ 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
Tetapi, tentu saja, penting untuk menggunakan layanan penyimpanan yang paling tepat untuk aplikasi Anda. Setiap opsi memiliki kasus penggunaan yang valid. EFS mungkin yang paling khusus dari solusi penyimpanan yang ditawarkan oleh AWS, memiliki satu set kasus penggunaan yang lebih sempit daripada EBS atau S3.
Tetapi bisakah Anda menggunakannya dari luar VPC?
Jawaban resmi adalah Tidak :
Memasang sistem file melalui mekanisme konektivitas pribadi VPC seperti koneksi VPN, peeling VPC, dan AWS Direct Connect tidak didukung.
- http://docs.aws.amazon.com/efs/latest/ug/limits.html
EFS saat ini terbatas hanya untuk akses Linux EC2 saja. Itu juga di dalam VPC. Fitur lainnya akan ditambahkan segera. Anda dapat mengawasi pengumuman AWS untuk fitur baru yang diluncurkan.
- https://forums.aws.amazon.com/thread.jspa?messageID=732749
Namun, jawaban praktisnya adalah Ya , meskipun ini bukan konfigurasi yang didukung secara resmi. Untuk membuatnya berfungsi, beberapa langkah khusus diperlukan.
Setiap sistem file EFS ditugaskan alamat IP titik akhir di VPC Anda menggunakan antarmuka jaringan elastis (ENI), biasanya satu per zona ketersediaan, dan Anda ingin memastikan Anda memasang satu di zona ketersediaan yang cocok dengan instance, tidak hanya karena alasan kinerja, tetapi juga karena biaya bandwidth berlaku ketika mengangkut data melintasi batas zona ketersediaan.
Hal yang menarik tentang ENI ini adalah bahwa mereka tampaknya tidak menggunakan tabel rute untuk subnet yang dilampirkan. Mereka tampaknya hanya mampu merespons kejadian di dalam VPC, terlepas dari pengaturan grup keamanan (setiap sistem file EFS memiliki grup keamanan sendiri untuk mengontrol akses).
Karena tidak ada rute eksternal yang dapat diakses, saya tidak dapat mengakses titik akhir EFS langsung melalui VPN perangkat keras saya ... jadi saya menoleh ke teman lama saya HAProxy, yang memang (seperti yang diprediksi oleh @Tim) diperlukan untuk membuat pekerjaan ini. Ini konfigurasi langsung, karena EFS hanya menggunakan port TCP 2049.
Saya menggunakan HAProxy pada t2.nano (HAProxy sangat efisien), dengan konfigurasi yang terlihat seperti ini:
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
Server ini berada di us-east-1b sehingga ia menggunakan titik akhir us-east-1b sebagai primer, dua lainnya sebagai cadangan jika titik akhir dalam 1b pernah gagal dalam pemeriksaan kesehatan.
Jika Anda memiliki VPN ke VPC Anda, Anda kemudian memasang volume menggunakan alamat IP instance proxy ini sebagai target (alih-alih menggunakan titik akhir EFS secara langsung), dan voila Anda telah memasang sistem file EFS dari luar VPC.
Saya telah memasangnya dengan sukses pada mesin Ubuntu eksternal dan juga server Solaris¹ (di mana EFS terbukti sangat berguna untuk mempercepat dekomisioning mereka dengan membuatnya lebih mudah untuk memigrasi layanan dari mereka).
Untuk situasi tertentu, seperti memindahkan data ke AWS atau menjalankan sistem legacy dan cloud secara paralel pada data tertentu selama migrasi, EFS tampak seperti pemenang.
Tentu saja, sistem legacy, yang memiliki waktu pulang-pergi yang lebih tinggi, tidak akan berkinerja sama baiknya dengan instance EC2, tapi itulah yang diharapkan - tidak ada pengecualian untuk hukum fisika. Meskipun demikian, EFS dan gateway HAProxy tampaknya menjadi solusi yang stabil untuk membuatnya bekerja secara eksternal.
Jika Anda tidak memiliki VPN, maka sepasang mesin HAProxy, satu di AWS dan satu di pusat data Anda, juga dapat melakukan tunnel EFS melalui TLS, membangun koneksi TCP individual dengan muatan yang dibungkus dengan TLS untuk pengangkutan masing-masing EFS individu koneksi di Internet. Bukan secara teknis VPN, tetapi tunneling koneksi terenkripsi. Ini juga tampaknya berkinerja cukup baik.
OlSolaris 10 agak (tidak mengherankan) agak rusak secara default - awalnya, root tampaknya tidak memiliki hak istimewa - file pada volume EFS yang dibuat oleh root dimiliki oleh root tetapi tidak dapat chowndiedit ke pengguna lain dari Mesin Solaris ( Operation not permitted), meskipun semuanya berfungsi seperti yang diharapkan dari klien Ubuntu. Solusinya, dalam hal ini, adalah mengalahkan daemon pemetaan ID NFS pada mesin Solaris menggunakan svcadm disable svc:/network/nfs/mapid:default. Menghentikan layanan ini membuat semuanya berfungsi seperti yang diharapkan. Selain itu, permohonan /usr/sbin/quotapada setiap login harus dinonaktifkan di /etc/profile. Mungkin ada solusi yang lebih baik atau lebih benar, tetapi ini Solaris, jadi saya tidak cukup penasaran untuk menyelidikinya.