Manfaat EBS vs. instance-store (dan sebaliknya) [ditutup]

381

Saya tidak jelas tentang manfaat apa yang saya dapatkan dari EBS vs. instance-store untuk mesin virtual saya di Amazon EC2. Jika ada, tampaknya EBS jauh lebih berguna (berhenti, mulai, bertahan + kecepatan yang lebih baik) dengan perbedaan biaya yang relatif kecil ...? Juga, apakah ada metrik apakah lebih banyak orang menggunakan EBS sekarang tersedia, mengingat masih relatif baru?

amazon-ec2 amazon-web-services amazon-ebs

— HelloWorldy
sumber

1

alestic.com/2012/01/ec2-ebs-boot-recomended

— Jeroen

juga "mikro" hanya tersedia jika Anda menggunakan mesin virtual yang didukung EBS.

— Ali

1

Volume Instance Store jauh lebih cepat dan tidak menggunakan penyimpanan berbasis jaringan!

— Matt

Saya pribadi menggunakan instance-store untuk membuang dan menjalankan koleksi MongoDB ke dalamnya dan meletakkannya di S3 karena dua alasan. Pertama dipisahkan dan tidak akan mengurangi kecepatan tulis pada RAID EBS 10-volume saya. Yang kedua adalah bahwa ini jauh lebih cepat daripada EBS dan karena itu ada pada instans saya, tidak ada gunanya bagi saya untuk membuat volume EBS tambahan untuk melakukan dumping dan menghancurkannya setelah menempatkannya pada S3. Semoga ini membantu dan tidak membangun ...

— Maziyar

2

Saya setengah jalan melalui Panduan Pengguna AWS (700 halaman). Telah membaca dengan seksama tentang EBS dan Penyimpanan Instans. Saya masih tidak mengerti mengapa ada perbedaan seperti itu. Dan bahkan lebih bingung mengapa toko Instance setara dengan S3 tetapi dinamai berbeda. Pertanyaan harus dibuka kembali untuk menerima kontribusi lebih banyak ke jawaban yang bermanfaat.

— Polymerase

293

Intinya adalah Anda harus hampir selalu menggunakan instance yang didukung EBS.

Inilah sebabnya

Mesin virtual yang didukung EBS dapat diatur sehingga tidak dapat (tidak sengaja) dihentikan melalui API.
Mesin virtual yang didukung EBS dapat dihentikan saat Anda tidak menggunakannya dan dilanjutkan saat Anda membutuhkannya lagi (seperti menjeda PC Virtual), setidaknya dengan pola penggunaan saya menghemat lebih banyak uang daripada yang saya habiskan untuk beberapa lusin GB penyimpanan EBS.
Mesin virtual yang didukung EBS tidak kehilangan penyimpanan instan mereka saat rusak (bukan persyaratan untuk semua pengguna, tetapi membuat pemulihan lebih cepat)
Anda dapat mengubah ukuran penyimpanan EBS secara dinamis.
Anda dapat mentransfer penyimpanan instance EBS ke instance baru (berguna jika perangkat keras di Amazon yang Anda jalankan bersisik atau mati, yang memang terjadi dari waktu ke waktu)
Lebih cepat meluncurkan instance yang didukung EBS karena gambar tidak harus diambil dari S3.
Jika perangkat keras instance yang didukung EBS Anda dijadwalkan untuk pemeliharaan , menghentikan dan memulai instance secara otomatis bermigrasi ke perangkat keras baru. Saya juga dapat memindahkan instance yang didukung EBS pada perangkat keras yang gagal dengan menghentikan paksa instance dan meluncurkannya lagi (jarak tempuh Anda mungkin berbeda pada perangkat keras yang gagal).

Saya pengguna berat Amazon dan mengalihkan semua instans saya ke penyimpanan yang didukung EBS segera setelah teknologi keluar dari beta. Saya sangat senang dengan hasilnya.

EBS masih bisa gagal - bukan peluru perak

Perlu diingat bahwa setiap bagian dari infrastruktur berbasis cloud dapat gagal kapan saja. Rencanakan infrastruktur Anda sesuai kebutuhan. Sementara instance yang didukung EBS memberikan tingkat daya tahan tertentu dibandingkan dengan instance penyimpanan sesaat, mereka dapat dan memang gagal. Miliki AMI dari mana Anda dapat meluncurkan mesin virtual baru sesuai kebutuhan di zona ketersediaan apa pun, buat cadangan data penting Anda (mis. Basis data), dan jika anggaran Anda memungkinkan, jalankan beberapa mesin virtual server untuk penyeimbangan beban dan redundansi (idealnya di berbagai zona ketersediaan) ).

Kapan Tidak

Pada beberapa titik waktu, mungkin lebih murah untuk mencapai IO yang lebih cepat di Instance Store. Ada saat ketika itu memang benar. Sekarang ada banyak pilihan untuk penyimpanan EBS, melayani banyak kebutuhan. Opsi dan harganya terus berkembang seiring perubahan teknologi. Jika Anda memiliki banyak contoh yang benar-benar sekali pakai (mereka tidak banyak mempengaruhi bisnis Anda jika mereka pergi begitu saja), lakukan perhitungan biaya dan kinerja. Mesin virtual yang didukung EBS juga bisa mati kapan saja, tetapi pengalaman praktis saya adalah bahwa EBS lebih tahan lama.

— Eric J.
sumber

4

Ya, di atas adalah pemikiran saya juga ... Semoga entah bagaimana di sini menulis tentang preferensi mereka untuk toko contoh sebagai perbandingan ...

— HelloWorldy

5

Instance store yang didukung EC2 juga dapat diatur untuk tidak berhenti secara tidak sengaja.

— Jim Soho

44

Saya sebenarnya mengalihkan sebagian besar instance EC2 yang didukung EBS untuk menggunakan toko instan. Itu sangat tergantung pada apa yang ingin Anda capai. Saya beralih karena IO yang lebih baik dan karena saya melihat setiap instance EC2 sebagai sekali pakai setiap saat, atau: ia akan rusak setiap saat dan saya akan kehilangan semua yang ada pada instance seperti itu. Merancang seperti itu membantu untuk mendapatkan sistem HA nyata. Lihat juga stu.mp/2011/04/the-cloud-is-not-a-silver-bullet.html

— Jim Soho

2

@ Jim: Setidaknya ketika saya menulis jawaban setahun yang lalu, Anda mendapatkan IO yang jauh lebih baik dengan menghapus sejumlah instance EBS ke dalam konfigurasi perangkat lunak RAID daripada menggunakan penyimpanan instance. Ini juga jauh lebih cepat untuk meluncurkan instance pengganti dari dukungan EBS daripada dari dukungan S3 (penyimpanan contoh diambil dari S3, yang bisa lambat). Saya belum melakukan banyak hal pada AWS 6 bulan terakhir atau lebih; segalanya mungkin telah berubah.

— Eric J.

2

Tampaknya sedikit berat sebelah - walaupun dimungkinkan untuk menjalankan instance yang didukung EBS dan mempertahankan penekanan yang berat pada daur ulang, saya berpikir bahwa memiliki pendatang baru yang melihat posting ini dan kemudian membuat instance yang Didukung EBS berbahaya karena mereka kemungkinan tidak akan mempertahankan itu penekanan yang sama pada daur ulang, yang mungkin merupakan komponen paling penting dari setiap infrastruktur cloud. Dan sebagian besar orang yang melihat ini pasti baru dalam hal ini

— Peter Berg

69

99% pengaturan AWS kami dapat didaur ulang. Jadi bagi saya itu tidak masalah jika saya menghentikan sebuah contoh - tidak ada yang hilang. Misalnya aplikasi saya secara otomatis digunakan pada instance dari SVN, log kami ditulis ke server syslog pusat.

Satu-satunya manfaat penyimpanan instan yang saya lihat adalah penghematan biaya. Jika tidak, mesin virtual yang didukung EBS akan menang. Eric menyebutkan semua kelebihannya.

[2012-07-16] Saya akan mengucapkan jawaban ini sangat berbeda hari ini.

Saya belum memiliki pengalaman yang baik dengan contoh yang didukung EBS dalam setahun terakhir ini. Downtime terakhir pada AWS cukup banyak menghancurkan EBS juga.

Saya menduga bahwa layanan seperti RDS menggunakan beberapa jenis EBS juga dan yang tampaknya berfungsi sebagian besar. Dalam hal kami mengelola diri kami sendiri, kami telah menyingkirkan EBS jika memungkinkan.

Menyingkirkan perluasan tempat kami memindahkan cluster basis data kembali ke besi (= perangkat keras nyata). Satu-satunya bagian yang tersisa di infrastruktur kami adalah server DB tempat kami membagi beberapa volume EBS ke dalam RAID perangkat lunak dan mencadangkan dua kali sehari. Apa pun yang akan hilang di antara cadangan, kita bisa hidup dengannya.

EBS adalah teknologi yang agak flakey karena pada dasarnya volume jaringan: volume yang terpasang ke server Anda dari jarak jauh. Saya tidak meniadakan pekerjaan dilakukan dengan itu - itu adalah produk yang luar biasa karena pada dasarnya terbatas gigih penyimpanan hanya sebuah API panggilan jauhnya. Tapi itu hampir tidak cocok untuk skenario di mana kinerja I / O adalah kuncinya.

Dan di samping bagaimana perilaku penyimpanan jaringan, semua jaringan dibagi pada instance EC2. Semakin kecil instance (mis. T1.micro, m1.small) semakin buruk karena antarmuka jaringan Anda pada sistem host yang sebenarnya dibagi di antara banyak VM (= instance EC2 Anda) yang berjalan di atasnya.

Semakin besar contoh yang Anda dapatkan, semakin baik tentu saja. Lebih baik di sini berarti masuk akal .

Ketika kegigihan dibutuhkan, saya akan selalu menyarankan orang untuk menggunakan sesuatu seperti S3 untuk memusatkan antara contoh. S3 adalah layanan yang sangat stabil. Kemudian, otomatiskan pengaturan instance Anda ke titik di mana Anda dapat mem-boot server baru dan siap dengan sendirinya. Maka tidak perlu memiliki penyimpanan jaringan yang hidup lebih lama dari instance.

Jadi semuanya, saya tidak melihat manfaat untuk contoh yang didukung EBS apa pun. Saya lebih suka menambahkan satu menit ke bootstrap, kemudian jalankan dengan SPOF potensial.

— Sampai
sumber

1

Apakah ada peningkatan signifikan kinerja IO dengan EBS IOPS-volume jenis dibandingkan dengan standar? Seandainya, kata di atas berlaku untuk volume EBS IOPS, juga.

— honzajde

4

Kedua teknologi berkembang. Saya memutar-mutar komentar ini pada tahun 2014, ketika saya memiliki "Provisi IOPS" EBS, tetapi - "toko contoh" sekarang SSD, yang bahkan lebih cepat dari sebelumnya !! Penyimpanan Ephemeral akan selalu menang dalam hal kecepatan. Jadi saya menggunakan keduanya - menyimpan "persistent" stuff di EBS, memiliki semua file temp, log, "TempDB" database, swap-file dan hal-hal lain di Instance-store. MANFAAT DARI KEDUA!

— Alex

Bagaimana jika Anda membutuhkan database terdistribusi yang perlu menyimpan datanya secara terdistribusi dan persisten. Tidakkah Anda membutuhkan EBS karena penyimpanan instan tidak persisten?

— CMCDragonkai

@ CMCDragonkai Tentu saja Anda lakukan. Ada banyak pilihan hari ini, misalnya AWS mulai menawarkan penyimpanan berbasis SSD. Saya akan melihat mereka dan kembali melakukan analisis (single vs. RAID, dll.). Saya juga akan mencari cara mendapatkan contoh terbesar yang mungkin karena throughput jaringan. EBS masih menjadi masalah pada instance seperti t1.micro.

— Hingga

Bagian dari jawaban ini tentang kinerja jaringan cukup usang - untuk beberapa saat sekarang, telah ada berbagai contoh yang dapat "dioptimalkan EBS" dengan biaya tambahan yang kecil, dan beberapa yang seperti itu secara default (tanpa biaya tambahan) ), yang memiliki antarmuka jaringan khusus untuk EBS, lih. docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html

— Josip Rodin

41

Kami menyukai toko contoh. Ini memaksa kita untuk membuat instance kita sepenuhnya dapat didaur ulang, dan kita dapat dengan mudah mengotomatiskan proses membangun server dari awal pada AMI yang diberikan. Ini juga berarti kita dapat dengan mudah menukar AMI. Juga, EBS masih memiliki masalah kinerja dari waktu ke waktu.

— sehugg
sumber

6

Netflix juga membuat rekomendasi yang sama.

— Kingz

2

Jadi di mana Anda menyimpan file persisten berbasis blok Anda?

— CMCDragonkai

17

Eric cukup berhasil. Kami ( Bitnami ) adalah penyedia populer AMI gratis untuk aplikasi populer dan kerangka kerja pengembangan (PHP, Joomla, Drupal, Anda mendapatkan ide). Saya dapat memberi tahu Anda bahwa AMI yang didukung EBS secara signifikan lebih populer daripada yang didukung S3. Secara umum saya pikir contoh yang didukung s3 digunakan untuk pekerjaan terdistribusi, waktu terbatas (misalnya, pengolahan data skala besar) di mana jika satu mesin gagal, yang lain hanya berputar. AMIS yang didukung EBS cenderung digunakan untuk tugas-tugas server 'tradisional', seperti server web atau database yang menjaga keadaan secara lokal dan dengan demikian memerlukan data yang akan tersedia jika terjadi gangguan.

Satu aspek yang saya tidak lihat disebutkan adalah fakta bahwa Anda dapat mengambil snapshot dari instance yang didukung EBS saat berjalan, secara efektif memungkinkan Anda untuk memiliki cadangan infrastruktur Anda yang sangat hemat biaya (snapshot berbasis blok dan tambahan)

— Daniel Lopez
sumber

S3 telah built-in redundansi. EBS tidak memilikinya , jadi Anda harus menggunakan perangkat lunak redundansi di atasnya.

— Pacerier

2

@Pacerier Itu tidak benar, per dokumentasi resmi di docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html

— Josip Rodin

16

Saya memiliki pengalaman yang sama persis seperti Eric di posisi terakhir saya. Sekarang di pekerjaan baru saya, saya akan melalui proses yang sama yang saya lakukan di pekerjaan terakhir saya ... membangun kembali semua AMI mereka untuk instance yang didukung EBS - dan mungkin sebagai mesin 32bit (lebih murah - tetapi tidak dapat menggunakan AMI yang sama pada 32 dan 64 mesin).

Mesin virtual yang didukung EBS diluncurkan dengan cukup cepat sehingga Anda dapat mulai menggunakan Amazon AutoScaling API yang memungkinkan Anda menggunakan metrik CloudWatch untuk memicu peluncuran mesin virtual tambahan dan mendaftarkannya ke ELB (Elastic Load Balancer), dan juga untuk mematikannya saat tidak lagi dibutuhkan.

Semacam ini autoscaling dinamis adalah apa AWS adalah semua tentang - di mana penghematan nyata dalam infrastruktur TI dapat ikut bermain. Cukup mustahil untuk melakukan autoscaling langsung dengan instance yang didukung s3 "InstanceStore" lama.

— j2d3
sumber

13

Saya baru mulai menggunakan EC2 sendiri jadi bukan ahli, tetapi dokumentasi Amazon sendiri mengatakan:

kami sarankan Anda menggunakan toko contoh lokal untuk data sementara dan, untuk data yang membutuhkan tingkat daya tahan yang lebih tinggi , kami sarankan untuk menggunakan volume Amazon EBS atau mencadangkan data ke Amazon S3.

Tekankan milikku.

Saya melakukan lebih banyak analisis data daripada web hosting, jadi kegigihan tidak terlalu penting bagi saya dibandingkan dengan situs web. Mengingat perbedaan yang dibuat oleh Amazon sendiri, saya tidak akan menganggap bahwa EBS tepat untuk semua orang.

Saya akan mencoba mengingat untuk menimbang lagi setelah saya menggunakan keduanya.

— isomorfisma
sumber

9

EBS seperti disk virtual VM:

Tahan lama, mesin virtual yang didukung oleh EBS dapat dengan bebas dimulai dan dihentikan (menghemat uang)
Dapat snapshotted kapan saja, untuk mendapatkan cadangan titik-waktu
AMI dapat dibuat dari snapshot EBS, sehingga volume EBS menjadi templat untuk sistem baru

Penyimpanan instan adalah:

Lokal, jadi umumnya lebih cepat
Non-jaringan, dalam kasus normal EBS I / O datang pada biaya bandwidth jaringan (kecuali untuk contoh yang dioptimalkan EBS, yang memiliki bandwidth EBS terpisah)
Memiliki IO / O per detik terbatas. Bahkan I / O yang disediakan dapat mencapai beberapa ribu IOPS
Rapuh. Segera setelah instance dihentikan, Anda kehilangan segalanya dalam penyimpanan instance.

Di sinilah tempat masing-masing digunakan:

Gunakan EBS untuk mendukung partisi OS dan penyimpanan permanen (data DB, log kritis, konfigurasi aplikasi)
Gunakan penyimpanan instan untuk data dalam proses, log nonkritis, dan status aplikasi sementara. Contoh: penyimpanan penyortiran eksternal, tempfile, dll.
Penyimpanan instan juga dapat digunakan untuk data penting-kinerja, ketika ada replikasi antara instance (NoSQL DB, sistem antrian / pesan yang didistribusikan, dan DB dengan replikasi)
Gunakan S3 untuk data yang dibagikan di antara sistem: input dataset dan hasil yang diproses, atau untuk data statis yang digunakan oleh masing-masing sistem ketika digeber.
Gunakan AMI untuk server yang dapat ditebak dan dapat diluncurkan

— BobMcGee
sumber

4

Kebanyakan orang memilih untuk menggunakan instance yang didukung EBS karena statusnya stateful. Ini lebih aman karena segala sesuatu yang Anda jalankan dan instal di dalamnya, akan bertahan stop / stop atau kegagalan instance.

Instance store tidak memiliki kewarganegaraan, Anda kehilangan semua data di dalamnya jika ada situasi kegagalan misalnya. Namun, ini gratis dan lebih cepat karena volume instance terikat ke server fisik tempat VM berjalan.

— mezi
sumber

2

Untuk seseorang yang baru dengan semua ini dan jika tidak sengaja mendarat di sini

Sampai sekarang semua AMI di bagian quickstart didukung EBS

Juga ada penjelasan yang bagus di dokumen resmi untuk perbedaan antara EBS dan toko Instance

& gambar ini meringkasnya

— Aishwat Singh
sumber

0

Jika Anda menjalankan beberapa instance dan menetapkan layanan terjadwal AWS Instance sebagai salah satu prioritas Anda untuk Menghindari Biaya Tak Terduga , saya akan merekomendasikan untuk tidak menggunakan instance-store .

Seperti yang dijelaskan pada dokumentasi Volume EBS dan jawaban dari j2d3 dan Siddharth Sharma , instance-store dapat berjalan selama yang Anda inginkan, tetapi tidak dapat dihentikan . Berarti layanan tidak dapat dijadwalkan oleh Start / Stop Otomatis atau Pemulihan Instance .

Selain itu, untuk skema semacam ini juga tidak ada manfaatnya menggunakan EBS Backed pada Elastic Beanstalk karena dirancang untuk memastikan bahwa semua sumber daya yang Anda butuhkan tetap berjalan . Itu akan selalu melakukan secara otomatis meluncurkan kembali layanan yang Anda hentikan. Meninjau semua sisanya , dari total biaya penggunaan VPC , EBS , dan ELB yang ditambahkan ke EC2-Classic , EC2-VPC dengan ELB sebagian besar merupakan pilihan terbaik di mana tidak seperti pada EC2-Classic , instance yang dihentikan mempertahankan Elastic yang terkait. Alamat IPdan volume EBS disimpan secara otomatis.

Sebagai kesimpulan , ambil bagian utama dari pertanyaan Anda:

tampaknya EBS jauh lebih berguna (berhenti, mulai, bertahan + kecepatan yang lebih baik) dengan perbedaan biaya yang relatif kecil ...?

Jawabannya adalah ya tetapi jika instance Anda berbasis EBS, itu bisa dihentikan. Itu akan tetap di akun Anda , Anda tidak akan dikenakan biaya untuk itu . Anda hanya akan menagih volume tetapi EBS dibebankan per jam . Anda juga dapat mempertimbangkan bahwa di antara semua jenis yang tersedia, Anda memiliki fleksibilitas untuk Mengubah Ukuran Volume EBS .

Selain manfaat yang telah terdaftar oleh Eric , harus juga diketahui bahwa dalam hal biaya S3 mungkin atau mungkin tidak lebih murah daripada EBS . Saya setuju bahwa perbedaannya relatif kecil dalam biaya jika Anda tetap menjalankan kedua jenis instance dalam platform dan arsitektur aplikasi yang sama sepanjang waktu.

Namun jika ada skenario untuk menjalankan aplikasi pada layanan dengan biaya lebih rendah, tarik semua tugas yang tidak ditangani dan peran mereka ke VPC / EBS melalui pipa atau lambda dalam waktu singkat, katakan <1 jam sehari, yang tidak mungkin dilakukan ketika Anda menggunakan toko contoh , maka itu akan menjadi cerita yang berbeda.

— Chetabahana
sumber