Roundrobin untuk file yang masuk

Sekelompok file baru dengan nama file unik secara teratur "muncul" ¹ pada satu server. (Seperti ratusan GB data baru setiap hari, solusinya harus dapat diukur hingga terabyte. Setiap file berukuran beberapa megabita, hingga beberapa puluh megabita.)

Ada beberapa mesin yang memproses file-file itu. (Puluhan, solusi harus scalable hingga ratusan.) Harus dimungkinkan untuk dengan mudah menambah dan menghapus mesin baru.

Ada server penyimpanan file cadangan tempat setiap file yang masuk harus disalin untuk penyimpanan arsip. Data tidak boleh hilang, semua file yang masuk harus dikirim pada server penyimpanan cadangan.

Setiap myst file yang masuk dikirim ke satu mesin untuk diproses, dan harus disalin ke server penyimpanan cadangan.

Server penerima tidak perlu menyimpan file setelah mengirimnya dalam perjalanan.

Mohon saran solusi yang kuat untuk mendistribusikan file dengan cara, dijelaskan di atas. Solusi tidak boleh berbasis Java. Solusi unix-way lebih disukai.

Server berbasis Ubuntu, berlokasi di pusat data yang sama. Semua hal lain dapat disesuaikan untuk kebutuhan solusi.

¹ Perhatikan bahwa saya sengaja menghilangkan informasi tentang cara file diangkut ke sistem file. Alasannya adalah bahwa file-file tersebut sedang dikirim oleh pihak ketiga oleh beberapa warisan yang berbeda berarti saat ini (anehnya, melalui scp, dan melalui ØMQ). Tampaknya lebih mudah untuk memotong antarmuka lintas-cluster di tingkat sistem file, tetapi jika satu atau solusi lain benar-benar akan memerlukan beberapa transportasi khusus - transportasi warisan dapat ditingkatkan ke yang itu.

Ini adalah salah satu solusi untuk apa yang Anda cari. Tidak ada java yang terlibat dalam pembuatan sistem ini, hanya bit Open Source yang tersedia. Model yang disajikan di sini dapat bekerja dengan teknologi lain selain yang saya gunakan sebagai contoh.

1. File adalah HTTP POST ke alamat DNS Round-Robin tertentu.
2. Sistem POST file kemudian menjatuhkan pekerjaan ke dalam sistem AMQP (Kelinci MQ di sini), melalui sepasang load-balancers, untuk memulai alur kerja pemrosesan.
3. Load Balancers yang menerima HTTP POST masing-masing ada di depan sekelompok server penyimpanan objek OpenStack Swift.
   • Load-balancers masing-masing memiliki dua atau lebih server objek-toko OpenStack Swift di belakangnya.
   • 'Round Robin bukan HA' bisa jadi jika targetnya adalah HA sendiri. YMMV.
   • Untuk daya tahan ekstra, IP di RRDNS bisa berupa klaster LB siaga-panas tersendiri.
4. Server Object Store yang benar-benar mendapatkan POST mengirimkan file ke sistem file berbasis Gluster.
   • Sistem Gluster harus Terdistribusi (alias dibelokkan) dan Digandakan. Ini memungkinkannya untuk mengukur kepadatan yang konyol.
5. Sistem AMQP mengirimkan pekerjaan pertama, membuat cadangan, ke node pemrosesan yang tersedia.
6. Pemrosesan node menyalin file dari penyimpanan utama ke penyimpanan cadangan dan melaporkan keberhasilan / kegagalan sesuai kebutuhan.
   • Pemrosesan mode kegagalan tidak digambarkan di sini. Intinya, teruslah berusaha sampai berhasil. Dan jika itu tidak berhasil, jalankan melalui proses pengecualian.
7. Setelah cadangan selesai AMQP kemudian mengirimkan pekerjaan Pemrosesan ke node pemrosesan yang tersedia.
8. Pemrosesan node baik menarik file ke sistem file lokal atau memprosesnya langsung dari Gluster.
9. Pemrosesan simpul menyimpan produk pemrosesan ke mana pun pergi dan melaporkan keberhasilan ke AMQP.

Pengaturan ini harus dapat mencerna file dengan kecepatan ekstrim yang diberikan server yang cukup. Mendapatkan kecepatan konsumsi agregat 10GbE harus bisa dilakukan jika Anda cukup besar. Tentu saja, memproses data sebanyak itu dengan cepat akan membutuhkan lebih banyak server di kelas mesin pemroses Anda. Pengaturan ini harus ditingkatkan hingga seribu node, dan mungkin lebih dari itu (meskipun seberapa jauh tergantung pada apa, tepatnya, yang Anda lakukan dengan semua ini).

Tantangan teknik yang mendalam akan berada dalam proses manajemen alur kerja yang tersembunyi di dalam proses AMQP. Itu semua perangkat lunak, dan mungkin dibuat khusus untuk tuntutan sistem Anda. Tetapi harus diisi dengan data!

Mengingat Anda telah mengklarifikasi bahwa file akan tiba melalui scp, saya tidak melihat alasan untuk server front-end ada sama sekali, karena mekanisme transport adalah sesuatu yang dapat diarahkan pada layer 3.

Saya akan menempatkan direktur LVS (pasangan) di depan, dengan kumpulan server pemrosesan di belakang dan kebijakan pengalihan round-robin. Itu membuatnya sangat mudah untuk menambah dan mengurangi server ke / dari kolam, itu meningkatkan keandalan karena tidak ada server front-end untuk jatuh, dan itu berarti kita tidak harus menjawab pertanyaan tarikan / dorong tentang mendapatkan file dari front-end ke server pemrosesan karena tidak ada front-end.

Setiap server kumpulan harus melakukan dua hal ketika menerima file - pertama, salin ke penyimpanan arsip, kemudian proses file dan kirimkan dalam perjalanan.