İşleme fonksiyonumuz için kullandığımız bir GlusterFS kümemiz var. Windows'un ona entegre olmasını istiyoruz, ancak bir GlusterFS birimine hizmet veren bir Samba sunucusu olan tek hata noktasından nasıl kaçınılacağını bulmakta sorun yaşıyoruz.
Dosya akışımız şu şekilde çalışır:
- Dosyalar bir Linux işlem düğümü tarafından okunur.
- Dosyalar işlenir.
- Sonuçlar (küçük olabilir, oldukça büyük olabilir) yapıldıkça GlusterFS birimine geri yazılır.
- Sonuçlar bunun yerine bir veritabanına yazılabilir veya çeşitli boyutlarda birkaç dosya içerebilir.
- İşlem düğümü, kuyruktan ve GOTO 1'den başka bir işi alır.
Gluster, dağıtılmış bir hacim ve anında çoğaltma sağladığı için harika. Afet esnekliği güzel! Severiz.
Ancak, Windows'un yerel bir GlusterFS istemcisi olmadığından, Windows tabanlı işlem düğümlerimizin dosya deposuyla benzer şekilde esnek bir şekilde etkileşime girmesi için bir yol bulmamız gerekir. GlusterFS belgelerine durumları , Windows erişimi sağlamak için bir yol üstünde bir Samba sunucusu kurmak olduğunu GlusterFS hacmini monte. Bu şöyle bir dosya akışına yol açar:
Bu benim için tek bir başarısızlık noktasına benziyor.
Bir seçenek Samba'yı kümelemektir , ancak bu şu anda ve dolayısıyla çalışmayan dengesiz koda dayanmaktadır.
Başka bir yöntem arıyorum.
Attığımız veri türleri hakkında bazı önemli ayrıntılar:
- Orijinal dosya boyutları birkaç KB ile onlarca GB arasında herhangi bir yerde olabilir.
- İşlenen dosya boyutları birkaç KB ile GB veya iki arasında olabilir.
- .Zip veya .tar gibi bir arşiv dosyasında kazma gibi belirli işlemler, içerilen dosyalar dosya deposuna içe aktarıldıkça daha fazla yazmaya neden olabilir.
- Dosya sayıları 10 milyona girebilir.
Bu iş yükü "statik iş birimi boyutu" Hadoop kurulumuyla çalışmaz. Benzer şekilde, S3 tarzı nesne depolarını değerlendirdik, ancak onları eksik bulduk.
Uygulamamız Ruby'de özel olarak yazılmıştır ve Windows düğümlerinde bir Cygwin ortamımız vardır. Bu bize yardımcı olabilir.
Düşündüğüm bir seçenek, GlusterFS biriminin takılı olduğu sunucular kümesindeki basit bir HTTP hizmetidir. Gluster ile yaptığımız tek şey aslında GET / PUT işlemleri olduğundan, HTTP tabanlı bir dosya aktarma yöntemine kolayca aktarılabilir gibi görünüyor. Onları bir yük dengeleyici çiftinin arkasına koyun ve Windows düğümleri küçük mavi kalplerin içeriğine HTTP PUT ekleyebilir.
Bilmediğim şey GlusterFS tutarlılığının nasıl sağlanacağıdır . HTTP-proxy katmanı, işlem düğümü yazma ile yapıldığını bildirdiğinde ve GlusterFS biriminde gerçekten göründüğünde, dosyayı almaya çalışan sonraki işlem aşamalarından endişe duymamam arasında yeterli gecikme sağlar. bul onu. direct-io-mode=enableBağlama seçeneğini kullanmanın yardımcı olacağından eminim , ancak bunun yeterli olup olmadığından emin değilim . Tutarlılığı artırmak için başka ne yapmalıyım?
Yoksa tamamen başka bir yöntem mi izlemeliyim?
Tom'un aşağıda belirttiği gibi, NFS başka bir seçenektir. Bu yüzden bir test yaptım. Yukarıda belirtilen dosyalar saklamamız gereken istemci tarafından sağlanan adlara sahip olduğundan ve herhangi bir dilde gelebileceğinden, dosya adlarını korumamız gerekir. Bu dosyalar ile bir dizin oluşturdum:
NFS İstemcisi kurulu olarak bir Server 2008 R2 sisteminden bağladığımda, şöyle bir dizin listesi alıyorum:
Açıkçası, Unicode korunmuyor. NFS benim için çalışmayacak.
ctdbistikrarlı ve üretim için hazır olduğunu düşündüğüne ve verdiğiniz bağlantıdaki ilk cümlenin ikincisini geçersiz kıldığından, asla güncellenmediği için inanıyorum . Bunu kurmayı planlıyordum, ama bunu yapmadan önce işleri neredeyse penceresiz bir ortama çevirdim.