Kami memiliki cluster GlusterFS yang kami gunakan untuk fungsi pemrosesan kami. Kami ingin mengintegrasikan Windows ke dalamnya, tetapi mengalami beberapa masalah untuk mengetahui bagaimana menghindari satu-titik-kegagalan yaitu server Samba yang melayani volume GlusterFS.
File-flow kami berfungsi seperti ini:
- File dibaca oleh simpul pemrosesan Linux.
- File-file tersebut diproses.
- Hasil (bisa kecil, bisa sangat besar) ditulis kembali ke volume GlusterFS saat selesai.
- Sebagai gantinya, hasil dapat ditulis ke basis data, atau mungkin menyertakan beberapa file dengan berbagai ukuran.
- Node pemrosesan mengambil pekerjaan lain dari antrian dan GOTO 1.
Gluster sangat bagus karena memberikan volume yang didistribusikan, serta replikasi instan. Ketahanan bencana bagus! Kami menyukainya.
Namun, karena Windows tidak memiliki klien GlusterFS asli, kami memerlukan beberapa cara agar simpul pemrosesan berbasis Windows kami untuk berinteraksi dengan penyimpanan file dengan cara yang sama tangguh. The negara GlusterFS dokumentasi bahwa cara untuk menyediakan akses Windows adalah dengan menyiapkan server Samba di atas yang dipasang volume yang GlusterFS. Itu akan menyebabkan aliran file seperti ini:
Itu terlihat seperti titik kegagalan bagi saya.
Salah satu opsi adalah untuk mengelompokkan Samba , tetapi yang tampaknya didasarkan pada kode yang tidak stabil sekarang dan dengan demikian tidak berjalan.
Jadi saya mencari metode lain.
Beberapa detail kunci tentang jenis data yang kami lemparkan:
- Ukuran file asli dapat berkisar dari beberapa KB hingga puluhan GB.
- Ukuran file yang diproses dapat berkisar dari beberapa KB hingga satu atau dua GB.
- Proses tertentu, seperti menggali dalam file arsip seperti .zip atau .tar dapat menyebabkan BANYAK penulisan lebih lanjut karena file yang terkandung diimpor ke file-store.
- Penghitungan file bisa mencapai 10 dari jutaan.
Beban kerja ini tidak bekerja dengan pengaturan Hadoop "ukuran unit kerja statis". Demikian pula, kami telah mengevaluasi objek-toko S3-gaya, tetapi menemukan mereka kurang.
Aplikasi kami dibuat khusus dalam bahasa Ruby, dan kami memiliki lingkungan Cygwin pada node Windows. Ini mungkin membantu kita.
Salah satu opsi yang saya pertimbangkan adalah layanan HTTP sederhana pada sekelompok server yang memiliki volume GlusterFS terpasang. Karena semua yang kami lakukan dengan Gluster pada dasarnya adalah operasi GET / PUT, yang tampaknya mudah ditransfer ke metode transfer file berbasis HTTP. Tempatkan mereka di belakang pasangan loadbalancer dan node Windows dapat HTTP PUT ke konten hati biru kecil mereka.
Apa yang saya tidak tahu adalah bagaimana koherensi GlusterFS akan dipertahankan . Lapisan HTTP-proxy memperkenalkan latensi yang cukup antara ketika node pemrosesan melaporkan bahwa hal itu dilakukan dengan menulis dan ketika itu benar-benar terlihat pada volume GlusterFS, bahwa saya khawatir tentang tahap pemrosesan selanjutnya yang mencoba mengambil file tidak akan Temukan. Saya cukup yakin bahwa menggunakan direct-io-mode=enableopsi-mount akan membantu, tetapi saya tidak yakin apakah itu cukup . Apa lagi yang harus saya lakukan untuk meningkatkan koherensi?
Atau haruskah saya mengejar metode lain sepenuhnya?
Seperti yang ditunjukkan Tom di bawah, NFS adalah pilihan lain. Jadi saya menjalankan tes. Karena file-file yang disebutkan di atas memiliki nama yang disediakan klien yang perlu kami pertahankan, dan dapat dibuat dalam bahasa apa pun, kami perlu mempertahankan nama-nama file tersebut. Jadi saya membangun direktori dengan file-file ini:
Ketika saya memasangnya dari sistem Server 2008 R2 dengan NFS Client diinstal, saya mendapatkan daftar direktori seperti ini:
Jelas, Unicode tidak dilestarikan. Jadi NFS tidak akan bekerja untuk saya.
ctdbstabil dan siap untuk digunakan produksi dan kalimat pertama dalam tautan yang Anda berikan membuat yang kedua tidak valid karena jika tidak pernah diperbarui. Saya berencana membuat ini, tetapi sebelum saya melakukan ini, saya pindah pekerjaan ke lingkungan yang hampir bebas jendela.