Sinkronisasi real-time dua arah pohon file besar antara dua server linux yang jauh

21

Dengan pohon file besar yang saya maksud adalah sekitar 200 ribu file, dan terus bertambah setiap saat. Namun, sejumlah kecil file sedang diubah dalam jam tertentu.

Dengan bidirectional saya maksudkan bahwa perubahan dapat terjadi di kedua server dan perlu didorong ke yang lain, sehingga rsync tampaknya tidak sesuai.

Maksud saya adalah bahwa kedua server sama-sama berada di pusat data, tetapi secara geografis jauh dari satu sama lain. Saat ini hanya ada 2 server, tetapi itu dapat berkembang seiring waktu.

Secara real-time, boleh saja ada sedikit latensi antara sinkronisasi, tetapi menjalankan cron setiap 1-2 menit sepertinya tidak benar, karena sebagian kecil file dapat berubah dalam jam tertentu, apalagi menit.

EDIT : Ini berjalan di VPS jadi saya mungkin terbatas pada jenis hal-hal tingkat kernel yang bisa saya lakukan. Juga, VPS tidak kaya sumber daya, jadi saya akan menghindar dari solusi yang membutuhkan banyak ram (seperti Gluster?).

Apa pendekatan terbaik / paling "diterima" untuk menyelesaikan ini? Sepertinya ini akan menjadi kebutuhan bersama, tetapi saya belum dapat menemukan pendekatan yang diterima secara umum, yang mengejutkan. (Saya mencari keamanan massa. :)

Saya telah menemukan lsyncd untuk memicu sinkronisasi di tingkat perubahan sistem file. Tampaknya pintar meskipun tidak super umum, dan saya agak bingung dengan berbagai pendekatan lsyncd. Ada hanya menggunakan lsyncd dengan rsync, tetapi tampaknya ini bisa rapuh untuk dua arah karena rsync tidak memiliki gagasan tentang memori (mis. Untuk mengetahui apakah file yang dihapus pada A harus dihapus pada B atau apakah itu file baru pada B yang harus disalin ke A). lipsync tampaknya hanya implementasi lsyncd + rsync, kan?

Lalu ada yang menggunakan lsyncd dengan csync2 , seperti ini: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ... Saya condong ke arah pendekatan ini, tetapi csync2 sedikit aneh, meskipun saya berhasil melakukan tes. Saya sebagian besar khawatir bahwa saya belum dapat menemukan banyak konfirmasi komunitas dari metode ini.

Orang-orang di sini tampaknya sangat menyukai Unison, tetapi tampaknya itu tidak lagi dalam pengembangan aktif dan tidak jelas bahwa ia memiliki pemicu otomatis seperti lsyncd.

Saya telah melihat Gluster yang disebutkan, tetapi mungkin berlebihan untuk apa yang saya butuhkan?

UPDATE: fyi- Saya akhirnya pergi dengan solusi asli yang saya sebutkan: lsyncd + csync2. Tampaknya bekerja dengan cukup baik, dan saya suka pendekatan arsitektural untuk memiliki server yang sangat longgar, sehingga masing-masing server dapat beroperasi tanpa batasnya sendiri terlepas dari kualitas tautan di antara mereka.

linux cluster synchronization lsyncd csync2 dlo
sumber
Perubahan apa yang perlu Anda tangani? Pembuatan, penghapusan, modifikasi EG.
sciurus
Juga, apakah Anda mengharapkan konflik? Bisakah file yang sama dimodifikasi di kedua server?
sciurus
Semua perubahan: kreasi, penghapusan, modifikasi. Ada potensi konflik, tetapi harus jarang terjadi. Saya tidak keberatan jika saya hanya menerima peringatan tentang konflik yang kemudian harus saya selesaikan secara manual.
dlo

Jawaban:

5

DRBD dalam mode Dual-primer dengan Proxy adalah opsi.

kuanta
sumber
Proksi tampaknya bukan sumber terbuka atau gratis, bukan? Saya tidak yakin saya mengerti konsekuensi dari tidak memiliki Proxy dalam mode async: selama downtime yang lama, jika tidak ada Proxy, buffer output [kecil?] Dapat terisi dan kami akan kehilangan sinkronisasi? Apakah sulit untuk pulih dari itu?
dlo
Lihat jawaban saya di atas. Saya tidak berpikir proxy adalah hal yang Anda butuhkan. Bahkan selama downtime kecil, perangkat drbd-meta akan menandai blok "kotor" dan akan mentransfernya setelah koneksi dinyalakan kembali. Saya pikir perbedaan utama antara proxy dan mode-async adalah bahwa mode-async menggunakan buffer maksimum dari beberapa MB. Setelah itu disinkronkan sebelum mengisi buffer lagi. Proxy dapat memungkinkan buffer yang lebih besar (diperlukan jika Anda memiliki latensi besar atau dapat menulis jauh lebih cepat secara lokal daripada jarak jauh).
Nils
2

Daripada menyinkronkan, mengapa tidak berbagi sistem file yang sama melalui NFS?

Bart B
sumber
2
NFS mengerikan, hanya mengerikan. Apa pun akan lebih baik daripada NFS
AliGibbs
2
Salah satu poin utama dari pengaturan multi-server adalah failover / redundancy. Jadi satu server harus dapat melanjutkan tanpa yang lain.
dlo
Anda seharusnya menyebutkan hal itu dalam pertanyaan Anda - tidak perlu memberikan jawaban yang masuk akal!
Bart B
fyi saya tidak mengundurkan diri - orang lain melakukannya. Tapi ya, saya seharusnya menyebutkan itu sejak awal.
dlo
@ Bart: Ya - dia menyebutkan bahwa ada akses bersamaan di dua situs yang jauh. Jadi, bahkan jika Anda memasang HA-NFS itu akan menjadi solusi yang buruk, karena satu sisi akan menderita latensi selama akses-NFS. Dan saya tidak downvote juga. Tapi saya sudah menjadi admin NFS cukup lama untuk mendukung AliGibbs. : - /
Nils
2

Menerapkan sistem file terdistribusi mungkin lebih baik daripada meretas ini bersama-sama dengan alat dan skrip, terutama jika cluster server akan tumbuh. Anda juga dapat menangani simpul yang jatuh dengan lebih baik.

Saya tidak berpikir Gluster (atau AFS) sama sekali berlebihan.


sumber
Gluster membutuhkan ram 1GB? gluster.com/community/documentation/index.php/… ... Saya juga menggunakan VPS, jadi saya tidak yakin membuat perubahan level kernel yang mungkin diperlukan AFS. Tapi saya mulai melihat bahwa fs yang didistribusikan dengan benar adalah jalan yang lebih baik.
dlo
Ya, maaf saya tidak tahu sebelumnya bahwa Anda menggunakan host VPS. Jejak memori gluster, baik server dan klien, tidak kecil dan mereka dapat tumbuh secara substansial. DRBD terdengar lebih tepat.
AFS adalah cara untuk maju.
Anthony Giorgio
2

Dalam kasus Anda, saya akan merekomendasikan kombinasi DRBD dalam mode dual-primer dan gfs atau ocfs.

Kekurangan dari DRBD dalam dual-primer adalah bahwa itu akan berjalan dalam mode sinkron. Tetapi kecepatan tulis sepertinya tidak penting di sini, kan?

Alternatif untuk DRBD mungkin Soft-Raid1 menggunakan banyak (2+) iSCSI-Target - tapi saya lebih suka DRBD dengan dua node.

Nils
sumber
1
Mode sinkron akan menjadi buruk - Saya tidak membutuhkannya, dan saya tidak ingin merusak kinerja karena server terhubung melalui WAN di seluruh benua. Tapi tidak bisakah Anda memiliki dual-primer dalam mode async?
dlo
Saat ini saya menggunakan DRBD 8.3.5 - di sana Anda harus berada dalam mode sinkronisasi ("C") untuk masuk ke mode primer ganda. Saya tidak punya pengalaman pribadi dengan proxy DRBD tetapi tampaknya mirip dengan Replikator Volume Veritas - tetapi ini mungkin tidak cocok karena Anda ingin akses tulis di kedua sisi. Mode sinkronisasi pada level blok mungkin tidak seburuk yang Anda kira - mungkin gfs dan / atau ocfs dapat buffer tulis.
Nils
Saya baru saja memeriksa artikel berbahasa Jerman yang membandingkan GFS2 dan OCFS2. Dari itu setidaknya OCFS2 tampaknya mendukung file-system-buffered akses. GFS2 direkomendasikan dalam artikel itu karena sudah lebih tua. Lihat dokumentasi RedHat pada GFS2 untuk detail tentang GFS2 - ini menggunakan buffering juga - tetapi Anda harus menggunakan dir yang berbeda untuk penulisan bersamaan untuk mendapatkan kinerja terbaik.
Nils
0

Seperti ditunjukkan di atas, banyak solusi tersedia, masing-masing dengan kelebihan dan kekurangannya.

Saya pikir saya akan mempertimbangkan menempatkan seluruh pohon di bawah kontrol versi ( Subversion , misalnya) dan secara berkala memeriksa / memperbarui dari kedua server dalam pekerjaan cron.

Paul Preziosi
sumber
0

Baru saja mengakhiri sedikit pencarian tentang hal yang sama, aku akan pergi dengan kesal. Namun, saya belum melakukan atau menemukan tes kinerja apa pun.

cbaltatescu
sumber