Roundrobin untuk file yang masuk

8

Sekelompok file baru dengan nama file unik secara teratur "muncul" 1 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.


1 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.

Alexander Gladysh
sumber
5
Saya suka pertanyaan ini. Ini adalah hal yang saya bicarakan untuk mendorong kembali ke SF dalam manifesto pra-pemilihan saya.
Tom O'Connor
Saya akan sangat menghargai jika orang yang memilih untuk menutup pertanyaan ini, menguraikan motivasi mereka dalam komentar. Terutama pemilihan di luar topik. Terima kasih.
Alexander Gladysh
@AlexanderGladysh Secara historis, kami belum terlalu tertarik pada pertanyaan gaya "desain saya sistem". Kebetulan bahwa masalah di sini sebenarnya dapat dipecahkan dalam ruang lingkup yang cukup sempit, itulah sebabnya saya menjawabnya. Tidak semua orang setuju dengan saya dan Tom.
sysadmin1138
Hmm. OKE, apakah ada tempat yang lebih baik untuk menanyakan pertanyaan ini?
Alexander Gladysh
@AlexanderGladysh ServerFault Chat tampaknya menjadi tempat pertanyaan terbuka seperti ini berakhir.
sysadmin1138

Jawaban:

5

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.

Unggahan yang skalabel

  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!

sysadmin1138
sumber
3

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.

MadHatter
sumber
2
Apa yang menurut Anda kurang mengingat apa yang ditanyakan ? Jika gagal hanya untuk membahas perincian yang belum diberikan dalam pertanyaan, maka itu bukan jawaban jika pertanyaannya bukan pertanyaan, tentunya? Dan Anda telah membuatnya sangat jelas bahwa Anda berpikir bahwa pertanyaannya adalah pertanyaan yang bagus.
MadHatter
1
Saya hanya cenderung mengajukan pertanyaan tentang pertanyaan, sebagai komentar atas pertanyaan itu, tetapi begitulah.
Tom O'Connor
Saya lebih suka setuju dengan Anda; tetapi karena Anda mengkanonisasi pertanyaan itu, saya agak merasa Anda setidaknya telah membeatifikasi jawaban apa pun yang sepenuhnya didasarkan padanya ;-)
MadHatter
2
Itu akan menjadi masalah ekumenis.
Tom O'Connor
Terima kasih, @MadHatter, atas masukan Anda. Saya menambahkan beberapa info ke pertanyaan.
Alexander Gladysh