İki uzak linux sunucusu arasında büyük dosya ağacının çift yönlü gerçek zamanlı senkronizasyonu


21

Büyük dosya ağacı ile yaklaşık 200k dosya kastediyorum ve sürekli büyüyor. Yine de belirli bir saatte nispeten az sayıda dosya değiştiriliyor.

İki yönlü olarak, değişikliklerin her iki sunucuda da gerçekleşebileceği ve diğerine basılması gerektiği anlamına gelir, bu nedenle rsync uygun görünmez.

Uzak demek istediğim, sunucuların her ikisinin de veri merkezlerinde olduğu, ancak coğrafi olarak birbirlerinden uzak oldukları anlamına geliyor. Şu anda yalnızca 2 sunucu var, ancak bu zamanla genişleyebilir.

Gerçek zamanlı olarak, senkronizasyon arasında biraz gecikme olması sorun değil, ancak her 1-2 dakikada bir cron çalıştırmak doğru görünmüyor, çünkü dosyaların çok küçük bir bölümü herhangi bir saatte bir dakika içinde değişebilir.

EDIT : Bu VPS üzerinde çalışıyor, bu yüzden yapabileceğim çekirdek seviyesindeki şeylerle sınırlı olabilirim. Ayrıca, VPS'ler zengin değil, bu yüzden çok fazla ram gerektiren çözümlerden (Gluster gibi) uzak duruyorum.

Bunu yapmak için en iyi / en "kabul edilen" yaklaşım nedir? Bu ortak bir ihtiyaç olacak gibi görünüyor, ancak genel olarak kabul edilmiş bir yaklaşım bulamadım, ki bu şaşırtıcıydı. (Kitlelerin güvenliğini arıyorum. :)

Dosya sistemi değişim düzeyinde bir senkronizasyon başlatmak için lsyncd ile karşılaştım . Süper yaygın olmasa da, zekice görünüyor ve biraz lsyncd yaklaşımları ile biraz kafam karıştı. Sadece rsync ile lsyncd kullanıyoruz, ancak bu iki yönlü olma açısından kırılgan görünebilir çünkü rsync'de bellek kavramı yoktur (örneğin, A'da silinmiş bir dosyanın B'de mi silinmesi gerektiğini yoksa B'de yeni bir dosya mı olduğunu bilmek) bu A'ya kopyalanmalıdır). Lipsync sadece lsyncd + rsync uygulanması, doğru gibi görünen?

Sonra , csync2 ile lsyncd kullanmak var , bunun gibi: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ... Bu yaklaşıma yöneliyorum, ama csync2 biraz garip, ancak başarılı bir test yaptım. Çoğunlukla bu yöntemi topluluk onayıyla onaylayamadığım için endişeliyim.

Buradaki insanlar Unison'dan çok hoşlanıyor gibi görünüyor, ancak artık aktif olarak geliştirilmediği ve lsyncd gibi bir otomatik tetikleyici olduğu açık değil.

Gluster'ın bahsettiğini gördüm , ama belki de ihtiyacım olan şey için fazla abartı ?

GÜNCELLEME: fyi- Ben bahsettiğim özgün çözüm ile sona erdi: lsyncd + csync2. Oldukça iyi çalışıyor gibi görünüyor ve sunucuların çok gevşek bir şekilde birleştirilmelerinin mimari yaklaşımını seviyorum, böylece her sunucu, aralarındaki bağlantı kalitesinden bağımsız olarak kendi başına süresiz çalışabiliyor.


Ne tür değişikliklere ihtiyacın var? EG oluşturma, silme, değiştirme.
sciurus

Ayrıca, çatışmalar bekliyor musunuz? Aynı dosya her iki sunucuda da değiştirilebilir mi?
sciurus

Tüm değişiklikler: oluşturma, silme, değiştirme. Çatışma potansiyeli var, ancak nadir olmalılar. El ile çözmek zorunda olduğum bir çatışma hakkında bir uyarı alırsam sorun olmaz.
dlo

Yanıtlar:


5

DRBD içinde Çift birincil bir ile mod proxy bir seçenektir.


Proxy açık kaynak veya ücretsiz gibi görünmüyor, değil mi? Zaman uyumsuz modunda bir Proxy bulunmamasının sonucunu anladığımdan emin değilim: uzun süre boyunca, eğer Proxy yoksa, [küçük?] Çıktı arabelleği doldurabilir ve senkronizasyonu kaybedebilir miyiz? Bundan kurtulmak zor mu?
dlo

Yukarıdaki cevaba bakınız. Proxy'nin ihtiyacın olan şey olduğunu sanmıyorum. Küçük bir kesinti süresinde bile, drbd-meta-device "kirli" blokları işaretler ve bağlantı tekrar kurulduktan sonra bunları transfer eder. Bence vekil ve asenkron mod arasındaki ana fark, asenkron modun bazı MB'lerin maksimum tamponunu kullanmasıdır. Bundan sonra tamponu tekrar doldurmak için eşitlenir. Proxy, daha büyük bir tampon belleğe izin verir (büyük gecikme süreniz varsa veya yerel olarak uzaktan çok daha hızlı yazabiliyorsanız gereklidir).
Nils,

2

Senkronizasyon yerine, neden aynı dosya sistemini NFS üzerinden paylaşmıyorsunuz?


2
NFS, korkunç, sadece korkunç. Her şey daha iyi NFS daha olurdu
AliGibbs

2
Çoklu sunucu kurulumunun ana noktalarından biri yük devretme / yedekliliktir. Bu nedenle bir sunucunun diğeri olmadan devam edebilmesi gerekir.
dlo

O zaman sorunuza değinmeliydiniz - kesinlikle makul bir cevabı oylamaya gerek yok!
Bart B,

fyi Ben aşağı oy vermedim - başkası yaptı. Ama evet, başlamak için bundan bahsetmeliydim.
dlo,

@Bart: Pekala - iki uzak bölgeye aynı anda erişim bulunduğundan bahsetti. Bu nedenle, HA-NFS'yi yerleştirseniz bile, bu kötü bir çözüm olacaktır, çünkü bir taraf NFS erişimi sırasında gecikme yaşayacaktır. Ve ben de aşağı oy vermedim. Ancak, AliGibbs'i destekleyecek kadar uzun süredir NFS yöneticisi oldum. : - /
Nils

2

Dağıtılmış bir dosya sistemi uygulamak, özellikle de sunucu kümeleri büyüyecekse, bunu araçlarla ve komut dosyalarıyla birlikte kullanmaktan daha iyidir. Ayrıca indirgenmiş bir düğümü daha iyi idare edebileceksiniz.

Gluster'ın (ya da AFS'nin) fazla abartıldığını sanmıyorum.


Gluster 1GB koç gerektirir? gluster.com/community/documentation/index.php/… ... Ben de bir VPS'deyim , bu yüzden AFS'nin gerektirebileceği çekirdek düzeyinde değişiklikler yapmak konusunda emin değilim. Fakat uygun bir dağıtılmış fs'nin daha iyi bir yol olduğunu görmeye başladım.
dlo

Evet, üzgünüm daha önce VPS ana bilgisayarlarını kullandığınızı anlamadım. Hem sunucu hem de istemci olan alt yapı belleği ayak izleri küçük değildir ve büyük ölçüde büyüyebilir. DRBD daha uygun sesler.

AFS gitmenin yolu.
Anthony Giorgio

2

Senin durumunda çift birincil modda bir DRBD kombinasyonu ve gfs veya ocfs öneririm.

DRBD'nin ikili primerde dezavantajı senkron modunda çalışacak olmasıdır. Ancak yazma hızı burada önemli değil gibi görünüyor?

DRBD'ye bir alternatif, birçok (2+) iSCSI-Hedefini kullanan bir Yumuşak Baskın1 olabilir - ancak iki düğmeli DRBD'yi tercih ederim.


1
Eşzamanlı mod kötü olurdu - Buna ihtiyacım yok ve sunucular kıtalar arasında bir WAN üzerinden bağlı olduğundan performansı düşürmek istemem. Ama zaman uyumsuz modda çift birincil olamaz mı?
dlo

Şu anda DRBD 8.3.5 kullanıyorum - orada çift birincil moda geçmek için eşitleme modunda ("C") olmanız gerekiyor. DRBD proxy ile kişisel bir deneyimim yok, ancak Veritas Volume Replicator ile benzer gözüküyor - ancak her iki taraftan da yazma erişimi istediğiniz için bu kesinlikle uygun değil. Blok düzeyinde senkronizasyon modu sandığınız kadar kötü olmayabilir - belki de gfs ve / veya ocfs yazabilir.
Nils,

GFS2 ve OCFS2'yi karşılaştıran bir almanca makaleye baktım. Bundan en azından OCFS2 tamponlanmış dosya sistemi erişimini destekliyor gibi görünüyor. GFS2 bu makalede daha eski olduğu için önerilmektedir. GFS2 ile ilgili ayrıntılar için GFS2'deki RedHat belgelerine bakın - bu da arabelleğe alma kullanır - ancak en iyi performansı elde etmek için eşzamanlı yazma işlemleri için farklı dizinler kullanmalısınız.
Nils,

0

Yukarıda gösterildiği gibi, her biri avantajları ve sakıncaları olan birçok çözüm vardır.

Sanırım tüm ağacı sürüm kontrolü altına almayı ( örneğin Subversion ) ve cron işlerinde her iki sunucudan da periyodik olarak kontrol etmeyi düşünürdüm .


0

Aynı şeyle ilgili bir arayıştan biraz önce bittikten sonra allık ile gidiyorum. Ancak, herhangi bir performans testi yapmadım veya bulamadım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.