Menyinkronkan jutaan file antara dua server Linux

10

Saya memiliki server yang mengekspor direktori yang berisi ~ 7 juta file (kebanyakan gambar) dari disk lokal ke klien jaringan melalui NFS .

Saya perlu menambahkan yang kedua demi HA, dan untuk tetap sinkron dengan yang pertama dengan delta sesedikit mungkin di antara keduanya.

Penelitian menyarankan untuk menggunakan lsyncd atau solusi berbasis inotify lainnya untuk ini, tetapi mengingat jumlah file yang membuat arloji inotify membutuhkan waktu yang lama. Hal yang sama untuk rsync .

Solusi lain yang mungkin tampaknya drdb , atau sistem file cluster seperti ceph atau glusterfs , tapi saya tidak punya pengalaman dengan itu dan tidak tahu mana yang akan lebih tepat dan mengatasi dengan baik banyak file dan masih memberikan kinerja yang layak.

Perhatikan bahwa sebagian besar aktivitas dibaca dengan sedikit penulisan yang terjadi.

user60039
sumber
2
DRDB berfungsi dengan baik dan mudah diatur dan dipahami dalam pengaturan klaster 2-mesin; Namun itu tidak akan skala dalam waktu dekat. Mungkin ada juga pendekatan lain terhadap subjek. highscalability.com/blog/2012/6/20/…
Rui F Ribeiro
Apakah Anda mencoba menjalankan rsyncdalam mode daemon? Ini akan mempercepat pembuatan daftar file saat menjalankan rsyncperintah, tetapi akan intensif RAM tergantung pada jumlah file.
Thomas
berapa lama penundaan yang bisa Anda toleransi? jika Anda dapat mentolerir beberapa menit (atau lebih), menggunakan btrfsatau zfsmungkin opsi, dikombinasikan dengan tugas cron untuk membuat snapsnots dan zfs sendatau btrfs sendmereka ke server cadangan. jauh lebih cepat dan beban kerja yang jauh lebih ringan (untuk mesin pengirim dan penerima) daripada rsync karena snapshot + send tidak perlu membandingkan cap waktu file atau checksum.
cas
BTW, dengan ceph Anda juga mendapatkan pilihan untuk menggunakannya sebagai objek toko (misalnya seperti s3 amazon atau openstacks's swift) daripada sistem file. Bahkan, ceph's fs sebenarnya berlapis di atas objek-store-nya.
cas
@ Thomas: rsync -amenggunakan daemon (sumber) membutuhkan waktu 200 menit untuk menyelesaikan, yang lebih dari apa yang dapat diterima. @cas: btrfs sendmungkin layak dicoba, saya akan memeriksanya. Saya tidak bisa pindah ke toko objek karena saya bukan pengembang aplikasi yang menggunakan file.
user60039

Jawaban:

1

Saya cenderung menyarankan replikasi yang merupakan data agnostik, seperti drbd. Sejumlah besar file akan menyebabkan apa pun berjalan pada tingkat yang lebih tinggi daripada "penyimpanan blok" menghabiskan banyak waktu berjalan pohon - seperti yang Anda temukan menggunakan rsync atau membuat jam tangan tidak sah.

Versi singkat dari kisah pribadi saya mendukungnya: Saya belum pernah menggunakan Ceph, tapi saya cukup yakin ini tidak ada dalam target pasar utama mereka berdasarkan kesamaannya dengan Gluster. Namun, saya telah mencoba menerapkan solusi semacam ini dengan Gluster selama beberapa tahun terakhir. Sudah berjalan dan berjalan sebagian besar waktu itu, meskipun beberapa pembaruan versi utama, tetapi saya tidak punya akhir masalah. Jika tujuan Anda lebih banyak redundansi daripada kinerja, Gluster mungkin bukan solusi yang baik. Terutama jika pola penggunaan Anda memiliki banyak panggilan stat (), Gluster tidak bekerja dengan baik dengan replikasi. Ini karena panggilan stat ke volume yang direplikasi pergi ke semua node yang direplikasi (sebenarnya "batu bata", tetapi Anda mungkin hanya akan memiliki satu bata per host). Jika Anda memiliki replika 2 arah, misalnya, setiap stat () dari klien menunggu respons dari kedua batu bata untuk memastikannya menggunakan data saat ini. Kemudian Anda juga memiliki overhead FUSE dan kurangnya caching jika Anda menggunakan filesystem gluster asli untuk redundansi (daripada menggunakan Gluster sebagai backend dengan NFS sebagai protokol dan automounter untuk redundansi, yang masih payah karena alasan stat ()) . Gluster bekerja sangat baik dengan file besar di mana Anda dapat menyebarkan data ke beberapa server; striping data dan distribusi berfungsi dengan baik, karena memang untuk itulah tujuannya. Dan replikasi tipe RAID10 yang lebih baru berkinerja lebih baik daripada volume yang direplikasi lurus sebelumnya. Tapi, berdasarkan apa yang saya tebak adalah model penggunaan Anda, saya akan menyarankan untuk tidak melakukannya. Kemudian Anda juga memiliki overhead FUSE dan kurangnya caching jika Anda menggunakan filesystem gluster asli untuk redundansi (daripada menggunakan Gluster sebagai backend dengan NFS sebagai protokol dan automounter untuk redundansi, yang masih payah karena alasan stat ()) . Gluster bekerja sangat baik dengan file besar di mana Anda dapat menyebarkan data ke beberapa server; striping data dan distribusi berfungsi dengan baik, karena memang untuk itulah tujuannya. Dan replikasi tipe RAID10 yang lebih baru berkinerja lebih baik daripada volume yang direplikasi lurus sebelumnya. Tapi, berdasarkan apa yang saya tebak adalah model penggunaan Anda, saya akan menyarankan untuk tidak melakukannya. Kemudian Anda juga memiliki overhead FUSE dan kurangnya caching jika Anda menggunakan filesystem gluster asli untuk redundansi (daripada menggunakan Gluster sebagai backend dengan NFS sebagai protokol dan automounter untuk redundansi, yang masih payah karena alasan stat ()) . Gluster bekerja sangat baik dengan file besar di mana Anda dapat menyebarkan data ke beberapa server; striping data dan distribusi berfungsi dengan baik, karena memang untuk itulah tujuannya. Dan replikasi tipe RAID10 yang lebih baru berkinerja lebih baik daripada volume yang direplikasi lurus sebelumnya. Tapi, berdasarkan apa yang saya tebak adalah model penggunaan Anda, saya akan menyarankan untuk tidak melakukannya. yang masih menyebalkan karena stat () alasan). Gluster bekerja sangat baik dengan file besar di mana Anda dapat menyebarkan data ke beberapa server; striping data dan distribusi berfungsi dengan baik, karena memang untuk itulah tujuannya. Dan replikasi tipe RAID10 yang lebih baru berkinerja lebih baik daripada volume yang direplikasi lurus sebelumnya. Tapi, berdasarkan apa yang saya tebak adalah model penggunaan Anda, saya akan menyarankan untuk tidak melakukannya. yang masih menyebalkan karena stat () alasan). Gluster bekerja sangat baik dengan file besar di mana Anda dapat menyebarkan data ke beberapa server; striping data dan distribusi berfungsi dengan baik, karena memang untuk itulah tujuannya. Dan replikasi tipe RAID10 yang lebih baru berkinerja lebih baik daripada volume yang direplikasi lurus sebelumnya. Tapi, berdasarkan apa yang saya tebak adalah model penggunaan Anda, saya akan menyarankan untuk tidak melakukannya.

Ingatlah bahwa Anda mungkin harus menemukan cara untuk menguasai pemilihan di antara mesin-mesin tersebut, atau menerapkan penguncian terdistribusi. Solusi perangkat blok bersama membutuhkan sistem file yang multi-master aware (seperti GFS), atau mengharuskan hanya satu simpul untuk me-mount filesystem read-write. Sistem file pada umumnya tidak suka ketika data diubah pada tingkat perangkat blok di bawahnya. Itu berarti klien Anda harus dapat mengetahui mana master, dan mengarahkan permintaan tulis di sana. Itu bisa menjadi gangguan besar. Jika GFS dan semua infrastruktur pendukungnya merupakan opsi, drbd dalam mode multi-master (mereka menyebutnya "dual primer") dapat bekerja dengan baik. https://www.drbd.org/en/doc/users-guide-83/s-dual-primary-mode untuk informasi lebih lanjut tentang itu.

Terlepas dari arah mana Anda pergi, Anda cenderung menemukan bahwa ini masih menyulitkan untuk dilakukan secara realtime tanpa hanya memberi perusahaan truk satu truk penuh uang.

dannysauer
sumber
Saya sedang dalam tahap awal migrasi dari perintah rsync di cron ke menggunakan sistem file terdistribusi. Jika Gluster menjalankan stat () pada semua batu bata, saya mungkin perlu mempertimbangkannya kembali sebagai solusi.
Jesusaur
1
Itu hanya terjadi pada sistem file yang direplikasi; ini berjalan stat()pada semua batu bata yang memiliki replika dari blok spesifik yang Anda lihat. Misalnya, jika Anda memiliki replika bergaris 2x2, itu statakan berjalan pada dua batu bata dengan blok yang direplikasi, tetapi tidak pada dua lainnya. Dalam aplikasi saya dengan banyak file kecil (masing-masing dalam urutan satu juta file di bawah 4K data), baik NFS maupun FUSE memberikan kinerja yang baik pada volume yang direplikasi. Dan georeplikasi ke ~ 20 mesin sangat tidak bisa diandalkan di beberapa konfigurasi.
dannysauer
1
Jarak tempuh Anda mungkin berbeda-beda, tetapi saya pindah dari Gluster kemana-mana (yang saya gunakan khusus untuk replikasi, bukan untuk semua hal keren lainnya yang sebenarnya dilakukan Gluster dengan baik) ke rsync pada sistem file asli. :) Saya melihat pindah ke lsyncd ( github.com/axkibe/lsyncd ) sekarang alih-alih cron, jadi saya bisa mendekati waktu-nyata tanpa overhead Gluster.
dannysauer
0

Saya telah beralih dari rsync ke ceph dengan bantuan pengaturan Proxmox VE.

Sekarang saya mengelola 14TB dalam satu cluster dengan replikasi langsung. Selama hampir 4 tahun.

Memperdalam Dhulla
sumber