Tercih edilen konumdaki coğrafi olarak dağıtılmış dosya sistemi

Standart bir dosya sunucusunu bir WAN üzerinden birkaç siteye dağıtması gereken bir uygulama oluşturuyorum. Temel olarak, her sitenin çeşitli boyutlarda (bazıları 100'lerin MB aralığında, ancak en küçükleri) çok sayıda çeşitli dosya yazması gerekir ve uygulama, çarpışmaların sorun olmayacağı şekilde yazılır. Aşağıdaki nitelikleri karşılayan bir sistem kurmak istiyorum:

1. Her site, dosyaları paylaşılan bir "ad alanında" depolayabilir. Yani, tüm dosyalar aynı dosya sisteminde görünecektir.
2. Her site, gerekli olmadıkça WAN üzerinden veri göndermez. Yani, WAN'ın her iki tarafında da aynı mantıksal dosya sistemine "birleştirilecek" yerel depolama olacaktır.
3. Linux ve Ücretsiz ($$$) bir Artı

Temel olarak, merkezi bir NFS paylaşımı gibi bir şey gereksinimlerin çoğunu karşılar, ancak yerel olarak yazılan verilerin yerel kalmasına izin vermez. WAN'ın uzak taraflarındaki tüm veriler her zaman yerel olarak kopyalanır.

Lustre'ye baktım ve onunla bazı başarılı testler yaptım, ancak dosyaları dağıtılmış depolamada oldukça eşit bir şekilde dağıtıyor gibi görünüyor. Belgeleri inceledim ve otomatik olarak uzak depolama yerine yerel depolamayı "tercih edecek" bir şey bulamadım. En düşük gecikmeli depolama ile giden bir şey bile iyi olurdu. Çoğu zaman bu uygulamanın gereksinimlerini karşılayacaktı.

Aşağıda sorulan bazı soruların cevapları:

• Sunucu düğümleri: başlatmak için 2 veya 3. Her sunucu, onlarca eşzamanlı okuma / yazma istemcisine bağlanır.
• WAN Topology tam ağ ve güvenilirdir. (büyük şirket, maliyet bürokrasi kadar sınırlayıcı değildir)
• İstemci yük devretme: Aslında istemcilerin yük devretme olmasını düşünmemiştim (çoğunlukla şu anki uygulamamız bunu tek bir sitede yapmıyor). Pratik cevap, coğrafi olarak dağıtılan her sitedeki sunucuların, hizmet verdikleri müşteriler için tek hata noktası olması bekleniyordu. Yine de, burada belirli bir şey düşünürseniz, bu tartışmaya oldukça uygun olacağını düşünüyorum.
• Roll-my-own: Ben rsync / unison düşündüm, ancak bu çalışmanın "dinamik" bölümünü sorunsuz bir şekilde yapmak için biraz fantezi mantık gerekir. Yani, dosya yerel gibi görünüyor, ancak yalnızca istek üzerine alınır.
• MS-DFS: Kesinlikle bakmam gereken bir şey gibi görünüyor. Ana sorunum, bağlanan istemcilerin çoğu NFS istemcisi olduğu için Windows'ta NFS sunucusu yapılandırması / güvenilirliği / performansı konusunda emin olamamak olabilir.

Linux gereksinimi hakkında utanç. Windows DFS tam olarak bunu yapar. 2003 R2'den bu yana, bunu blok düzeyinde de yapıyor.

Bazı sorular:

• Bu şeye katılmayı kaç tane "sunucu" düğümü düşünüyorsunuz?

• WAN bağlantı topolojisi neye benziyor-- hub ve bağlı, tam ağ? Ne kadar güvenilir?

• Yerel sunucunun başarısız olması durumunda istemcilerin coğrafi olarak yerel olmayan bir sunucuya yük devretmesini bekliyor musunuz?

Windows DFS-R, potansiyel olarak ağır lisans maliyetleri olsa da, aradığınız şeyi kesinlikle yapar.

Çarpışmaların bir sorun olmadığını ve dağıtılmış bir kilit yöneticisine ihtiyacınız olmadığını söylüyorsunuz, bu yüzden bunu rsync veya Unison gibi kullanıcı araçlarıyla yapabilir ve sadece NFS'li dosyaların derlemesini yerel istemcilere aktarabilirsiniz. Bu çirkin ve bir çoğaltma topolojisi oluşturma ve aslında kullanıcı alanı araçlarını çalıştırmak için bir tür sistemi birlikte çalmak zorunda kalacaksınız, ancak lisanslama maliyeti gittikçe kesinlikle ucuz olurdu.

AFS'yi düşündünüz mü ?

Andrew Dosya Sistemi (AFS), tüm istemci iş istasyonlarına homojen, konumdan saydam bir dosya adı alanı sunmak için bir dizi güvenilir sunucu kullanan dağıtılmış ağa bağlı bir dosya sistemidir.

Anladığım kadarıyla, son gelişmelerin çoğu OpenAFS projesinin arkasındaydı .

"Tercih edilen yerellik" özelliğinin kullanılabilir olup olmadığını bilmek için projeye yeterince aşina olduğumu iddia edemiyorum, ancak aksi halde kulağa iyi bir uyum gibi geliyor.

Luster'deki OST havuzlarına baktınız mı ?

Otomatik olmayacaktır, ancak OST havuzları ile belirli OST / OSS'lere dizinler / dosyalar atayabilirsiniz - temel olarak OST'lerde varsayılan yuvarlak liste / şeritleme yerine ilke tabanlı depolama ayırma.

Böylece site başına bir dizin ayarlayabilir ve bu dizini o sitenin yerel OST'lerine atayabilirsiniz, bu da tüm G / Ç'yi yerel OST'lere yönlendirir. Hala küresel bir isim alanı olacak.

WAN bağlantıları (yerel önbellek sunucuları ve bunun gibi şeyler) üzerinden Lustre'yi geliştirmek için çok fazla çalışma var, ancak hepsi hala ağır geliştirme AFAIK altında.

Belki NFS ama uygulama sunucularında Cachefs ile hedefinize ulaşırsınız . Anladığım gibi, yazılı her şey hala merkezi sunucuya gidecek, ama en azından okumalar yerel olarak önbelleğe alınabilir. Bu, kullanım alışkanlıklarınıza bağlı olarak potansiyel olarak okumaları geciktirebilir.

Ayrıca, mabye UnionFS göz atmaya değer. Bununla birlikte, her konumun bir NFS dışa aktarımı olacağını düşünüyorum ve daha sonra her konumdaki UnionFS'yi kullanabilirsiniz ve konumdaki diğer tüm NFS bağlarının bir dosya sistemi olarak görünmesini sağlayabilirsiniz. Bununla ilgili deneyimim yok.

Diskleri çoğaltmak için DRBD'ye bakabilirsiniz. http://www.drbd.org/ . Bu, şimdi Çekirdeğe dönüştüren bir linux Yüksek Kullanılabilirlik çözümüdür.

Ancak, bunun bazı sınırlamaları vardır:

1. Yalnızca iki düğüm kurulabilir
2. WAN, DRBD'yi sağlam tutacak kadar güvenilir olmayabilir.

Basit tutmak istiyorsanız, bir rsync'e bir göz atın, birçok sorunu çözer ve yazılabilir.

Chironfs üzerinde kontrol .

Belki de dosya sistemi temelinde istediğinizi yapabilir.

Btsync, iyi bir deneyim yaşadığım başka bir çözüm. Dosyaları aktarmak için BitTorrent protokolünü kullanır, böylece sahip olduğunuz daha fazla sunucu yeni dosyaları senkronize etmek kadar hızlı olur.

Rsync tabanlı çözümden farklı olarak, dosyaları / klasörleri ne zaman yeniden adlandırdığınızı algılar ve bunları sil / kopyala yerine tüm düğümlerde yeniden adlandırır.

Daha sonra btsync istemcileri yerel ağdaki klasörleri paylaşabilir.

Bulduğum tek dezavantajı (MS DFS ile karşılaştırıldığında), yerel bir dosya kopyasını algılamayacağıdır. Bunun yerine tüm akranlara yüklenen yeni bir dosya olarak yorumlayacaktır.

Şimdiye kadar btsync en iyi senkronizasyon çözümü gibi görünüyor ve Windows, Linux, Android ve ARM cihazlarına (örn. NAS) yüklenebilir