Sistem File Penyimpanan Terdistribusi - Yang mana / Apakah ada produk yang siap digunakan?

Dengan Hadoop dan CouchDB di seluruh Blogs dan berita terkait apa penyimpanan (mesin) yang didistribusikan-fault-tolerant yang benar-benar berfungsi.

• CouchDB sebenarnya tidak memiliki fitur distribusi bawaan, setahu saya lem untuk mendistribusikan entri secara otomatis atau bahkan seluruh basis data hilang begitu saja.
• Hadoop tampaknya sangat banyak digunakan - setidaknya mendapat pers yang baik, tetapi masih memiliki satu titik kegagalan: The NameNode. Plus, ini hanya dapat dipasang melalui FUSE, saya mengerti HDFS sebenarnya bukan tujuan utama Hadoop
• GlusterFS memang memiliki konsep apa-apa tapi belakangan ini saya membaca beberapa posting yang membuat saya berpendapat itu tidak cukup stabil
• Lustre juga memiliki satu titik kegagalan karena menggunakan server metadata khusus
• Ceph tampaknya menjadi pemain pilihan tetapi homepage menyatakan itu masih dalam tahap alfa itu.

Jadi pertanyaannya adalah filesystem terdistribusi mana yang memiliki set fitur berikut (tanpa urutan tertentu):

• Kompatibel dengan POSIX
• penambahan / penghapusan mudah node
• konsep shared-nothing
• berjalan pada perangkat keras yang murah (prosesor AMD Geode atau VIA Eden)
• otentikasi / otorisasi bawaan
• sistem file jaringan (Saya ingin dapat me-mount secara bersamaan pada host yang berbeda)

Senang bisa memiliki:

• file yang dapat diakses secara lokal: Saya dapat mengambil simpul ke bawah mount partisi dengan sistem file lokal standar (ext3 / xfs / apa pun ...) dan masih mengakses file

Saya tidak mencari aplikasi yang di-host, melainkan sesuatu yang akan memungkinkan saya untuk mengambil katakan 10GB dari masing-masing kotak perangkat keras kami dan memiliki penyimpanan yang tersedia di jaringan kami, mudah dipasang di banyak host.

Saya pikir Anda harus meninggalkan persyaratan POSIX, sangat sedikit sistem yang mengimplementasikannya - bahkan NFS tidak benar-benar (berpikir mengunci dll) dan yang tidak memiliki redundansi.

Setiap sistem yang menggunakan replikasi sinkron akan lambat secara glasial; sistem apa pun yang memiliki replikasi asinkron (atau "konsistensi akhirnya") akan melanggar aturan POSIX dan tidak berperilaku seperti sistem file "konvensional".

Saya tidak dapat berbicara dengan yang lain, tetapi Anda tampaknya bingung antara 'mesin penyimpanan terdistribusi' dan 'sistem file terdistribusi'. Mereka bukan hal yang sama, mereka tidak boleh keliru untuk hal yang sama, dan mereka tidak akan pernah menjadi hal yang sama. Filesystem adalah cara untuk melacak di mana segala sesuatu berada pada hard drive. Mesin penyimpanan seperti hadoop adalah cara untuk melacak sejumlah data yang diidentifikasi oleh kunci. Secara konseptual, tidak banyak perbedaan. Masalahnya adalah bahwa sistem file adalah ketergantungan mesin penyimpanan ... lagipula, itu perlu cara untuk menulis ke perangkat blok, bukan?

Selain itu, saya dapat berbicara dengan penggunaan ocfs2 sebagai sistem file terdistribusi dalam lingkungan produksi. Jika Anda tidak menginginkan detail yang kasar, berhentilah membaca setelah baris ini: Ini agak keren, tetapi itu bisa berarti lebih banyak downtime daripada yang Anda kira.

Kami telah menjalankan ocfs2 dalam lingkungan produksi selama beberapa tahun terakhir. Tidak apa-apa, tetapi tidak bagus untuk banyak aplikasi. Anda harus benar-benar melihat persyaratan Anda dan mencari tahu apa persyaratannya - Anda mungkin menemukan bahwa Anda memiliki lebih banyak garis lintang untuk kesalahan daripada yang Anda kira Anda lakukan.

Sebagai contoh, ocfs2 memiliki jurnal untuk setiap mesin di cluster yang akan me-mount partisi. Jadi katakanlah Anda memiliki empat mesin web, dan ketika Anda membuat partisi itu menggunakan mkfs.ocfs2, Anda menentukan bahwa akan ada total enam mesin untuk memberi Anda ruang untuk tumbuh. Masing-masing jurnal membutuhkan ruang, yang mengurangi jumlah data yang dapat Anda simpan di disk. Sekarang, katakanlah Anda perlu skala ke tujuh mesin. Dalam situasi itu, Anda perlu untuk mencatat seluruhcluster (mis. unmount semua partisi ocfs2) dan gunakan utilitas tunefs.ocfs2 untuk membuat jurnal tambahan, asalkan ada ruang yang tersedia. Kemudian dan hanya kemudian Anda dapat menambahkan mesin ketujuh ke cluster (yang mengharuskan Anda untuk mendistribusikan file teks ke seluruh cluster kecuali Anda menggunakan utilitas), bawa semuanya kembali, dan kemudian pasang partisi pada ketujuh mesin.

Lihat apa yang saya maksud? Seharusnya ketersediaan tinggi, yang seharusnya berarti 'selalu online', tapi di sana Anda punya banyak downtime ... dan Tuhan melarang Anda penuh sesak untuk ruang disk. Anda TIDAK ingin melihat apa yang terjadi ketika Anda kerumunan ocfs2.

Perlu diingat bahwa evms, yang dulunya merupakan cara yang 'disukai' untuk mengelola kluster ocfs2, telah berlaku seperti burung dodo yang mendukung clvmd dan lvm2. (Dan bukti bagus untuk evms.) Juga, detak jantung dengan cepat akan berubah menjadi proyek zombie yang mendukung tumpukan openais / alat pacu jantung. (Selain: Ketika melakukan konfigurasi cluster awal untuk ocfs2, Anda dapat menentukan 'pcmk' sebagai mesin kluster sebagai lawan dari detak jantung. Tidak, ini tidak didokumentasikan.)

Untuk apa nilainya, kami telah kembali ke nfs yang dikelola oleh alat pacu jantung, karena beberapa detik waktu henti atau beberapa paket tcp yang jatuh karena alat pacu jantung memindahkan bagian nfs ke mesin lain adalah sepele dibandingkan dengan jumlah waktu henti yang kami lihat sebagai dasar. operasi penyimpanan bersama seperti menambahkan mesin saat menggunakan ocfs2.

Saya mungkin salah memahami persyaratan Anda, tetapi apakah Anda sudah melihat http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

Hanya dengan melempar € 0,02 saya di sini: tidak bisakah OpenAFS melakukan apa yang Anda inginkan?

Lihatlah kicauan http://www.cse.nd.edu/~ccl/software/chirp/ dan parrot http://www.cse.nd.edu/~ccl/software/parrot/

Bagaimana dengan Xtreemfs ? versi 1.4 (November 2012) dianggap Kualitas Produksi.

POSIX kompatibel dan memiliki toleransi kesalahan otomatis yang luar biasa.

Lustre memungkinkan beberapa penyimpanan metadata dalam konfigurasi aktif / pasif untuk redundansi, jadi tidak ada titik kegagalan tunggal.

OCFS2 juga layak untuk dilihat.

Perhatikan bahwa memotong persyaratan untuk beberapa akses jaringan simultan memungkinkan untuk beralih ke sesuatu seperti iSCSI atau bahkan cifs atau nfs. The downside adalah Anda harus 'mengukir' potongan uberArray Anda ke dalam gigitan untuk setiap server yang membutuhkan ruang.

Kecuali itu untuk tujuan akademik / pengembangan, hal semacam ini harus didekati mulai dengan persyaratan keseluruhan untuk proyek. Sebagian besar filesystem yang didistribusikan tidak cukup matang untuk penyebaran yang serius - misalnya, apa yang Anda lakukan jika semuanya terkelupas. Jika ini untuk tujuan akademik / pengembangan, maka ini sebenarnya adalah hal yang baik karena Anda bisa belajar banyak dan memperbaiki banyak bug.

Komentar mempertanyakan apakah Anda benar-benar membutuhkan semantik POSIX adalah awal yang baik. Semantik "filesystem" Non-POSIX dapat menjadi jauh lebih fleksibel, mengarah ke sistem yang jauh lebih andal.

Jika ini adalah aplikasi warisan, saya benar-benar bertanya-tanya mengapa filesystem modern yang didistribusikan mungkin dianggap solusi terbaik.

Jangan salah paham - ini mainan yang sangat menyenangkan. Saya hanya tidak ingin bertanggung jawab atas solusi interdependen kompleks yang tidak umum digunakan dan akan sangat sulit untuk diperbaiki ketika serpihan keluar.

Apakah Anda benar-benar benar-benar membutuhkan semantik POSIX? Hidup menjadi jauh lebih mudah jika Anda dapat menggunakan datastore khusus. Kami memiliki datastore yang ditulis secara internal yang efektif merupakan toko nilai kunci terdistribusi yang sangat besar. Anda menyimpan file di dalamnya dan Anda mendapatkan token kembali. Jika Anda ingin file kembali, berikan token yang Anda berikan sebelumnya. Ini didistribusikan, tidak dibagi apa-apa, data direplikasi tiga kali, node dapat ditambahkan dan dihapus sesuka hati, baik server penyimpanan dan server kontrol.

Lustre juga memiliki satu titik kegagalan karena menggunakan server metadata khusus

Lustre dirancang untuk mendukung failover dan MDS / MDT / OSS dapat memiliki sejumlah alamat yang dapat dihubungi, detak jantung dapat digunakan untuk memigrasi layanan di sekitar.

Perlu diketahui bahwa beberapa versi terbaru memiliki masalah di mana unmount tampaknya berfungsi tetapi ada data yang masih terbang ke disk, Namun perlindungan pemasangan ganda seharusnya membantu (terlepas dari masalah menarik yang dimiliki) ....

Saya menyarankan Anda untuk menggunakan MooseFS (sistem file yang didistribusikan Jaringan, toleran, Scaling-out). Ini sesuai dengan POSIX dan sejak rilis 1.6 MooseFS menawarkan otentikasi / otorisasi sederhana, seperti NFS. Lihat juga persyaratan perangkat keras .