Uzaktaki sunucularla 1 milyon dosyayı verimli bir şekilde senkronize etme seçenekleri

Çalıştığım bir şirkette her biri 100-300 baytlık küçük dosyalar olan "çalma listeleri" diye bir şeye sahibiz. Bir milyon kadar var. Her saat yaklaşık 100.000 kişi değişiyor. Bu çalma listelerinin her kıtada farklı kıtalardaki 10 uzak sunucuya yüklenmesi gerekiyor ve ideal olarak 2 dakikadan kısa sürede hızlıca gerçekleşmesi gerekiyor. Master'da silinen dosyaların tüm kopyalarda da silinmesi çok önemlidir. Şu anda altyapımız için Linux kullanıyoruz.

İçeriği karşılaştırmadan tüm dosyaları kopyalamak için -W seçeneğiyle rsync'i denemeyi düşünüyordum. Henüz denemedim ama belki rsync ile daha fazla deneyime sahip insanlar uygun bir seçenek olup olmadığını bana söyleyebilir?

Hangi diğer seçenekleri göz önünde bulundurmaya değer?

Güncelleme: Cevap olarak lsyncd seçeneğini seçtim, ancak en popüler olduğu için. Önerilen diğer alternatifler de kendi başlarına geçerlidir.

Anlık güncelleştirmeler de kabul edilebilir olduğundan, lsyncd'yi kullanabilirsiniz .
Dizinleri izler (inotify) ve rsynckölelere dönüşür.
Başlangıçta bir tam olarak yapacaktır rsync, bu biraz zaman alacaktır, ancak bundan sonra sadece değişiklikler iletilir.
Dizinlerin yinelenen izlenmesi mümkündür, eğer bir köle sunucusu kapalıysa, geri dönene kadar eşitleme yeniden denenir.

Bunların hepsi tek bir dizinde ise (veya statik bir dizin listesi), incron da kullanabilirsiniz .
Buradaki dezavantajı, klasörlerin özyinelemeli izlenmesine izin vermemesidir ve senkronizasyon işlevini kendiniz uygulamanız gerekir.

GlusterFS gibi dağıtılmış bir dosya sistemi kullanmayı düşünün . Akılda çoğaltma ve paralellik göz önünde bulundurularak tasarlanan GlusterFS, inotify ve içeren geçici çözümlerden 10 adede kadar sunucuyu daha sorunsuz ölçeklendirebilir rsync.

Bu özel kullanım için, 10 kopya bir 10-sunucu GlusterFS birimi 10 kopya oluşturabilir (yani sunucu başına 1 kopya / tuğla), böylece her kopya bir birimdeki diğer her bir kopyalamanın aynası olacaktır. GlusterFS dosya sistemi güncellemelerini otomatik olarak tüm kopyalara yayar.

Her konumdaki istemciler yerel sunucularıyla iletişim kurar, bu nedenle dosyalara okuma erişimi hızlı olur. Anahtar soru, yazma gecikmesinin kabul edilebilir derecede düşük tutulabilmesidir. Bunu cevaplamanın tek yolu denemek.

Bunun rsynciçin normal şekilde çalışacağından şüpheliyim , çünkü bir milyon dosyayı taramak ve uzak sistemle 10 kez karşılaştırmak uzun zaman alacaktı. inotifyDeğiştirilmiş dosyaların listesini tutan ve uzak sunuculara iter (eğer bu değişiklikler başka bir şekilde giriş yapmazsa) gibi bir sistemi uygulamaya çalışacağım . Daha sonra bu listeyi, aktarılması gereken dosyaları hızlı bir şekilde tanımlamak için kullanabilirsiniz - belki de rsync ile (veya daha iyi 10 paralel örneği ile).

Düzenleme: Biraz çalışarak, değişiklik yapıldığında dosyaları kopyalamak için bu inotify / log watch yaklaşımını bile kullanabilirsiniz.

Bazı daha fazla alternatif:

• Birincil sunucuda bir dosyayı silerken veya eklerken , senkronize olmayan bir şekilde kapanıp aynı uzaktaki sunuculardaki aynı dosyayı silmek (veya eklemek) için RabbitMQ veya Gearman'e bir iş ekleyin.
• Dosyaları bir veritabanında saklayın ve uzaktaki sunucuları eşitlemek için çoğaltmayı kullanın.
• ZFS'niz varsa ZFS çoğaltmasını kullanabilirsiniz .
• Bazı SAN'larda dosya çoğaltması vardır. Bunun internet üzerinden kullanılıp kullanılamayacağı hakkında hiçbir fikrim yok.

Bu, MongoDB ve belki de GridFS için ideal bir hikaye kitabı kullanım örneği gibi görünüyor . Dosyalar nispeten küçük olduğundan, GridFS API'sini kullanmak uygun olsa da, MongoDB tek başına yeterli olmalıdır.

MongoDB bir nosql veritabanıdır ve GridFS bunun üzerine bir dosya depolama yapısıdır. MongoDB, çoğaltma ve paylaşma için birçok seçenek sunar , bu nedenle kullanım durumunuzda çok iyi ölçeklenmelidir.

Sizin durumunuzda muhtemelen birincil veri merkezinizde bulunan ana cihazdan (aynı konumda yerine çalışma yapmak istemeniz durumunda belki ikincisi) ve dünyaya dağılmış on "kölen" den oluşan bir kopya seti ile başlayacaksınız. Ardından, yazma performansının yeterli olup olmadığını kontrol etmek için testler yapın ve düğümlerinizin çoğaltma zamanlarını kontrol edin. Daha fazla performansa ihtiyaç duyuyorsanız, kurulumu keskin bir hale getirebilirsiniz (çoğunlukla yazma yükünü daha fazla sunucuya dağıtmak için). MongoDB, "ucuz" bir donanıma sahip büyük kurulumları ölçeklendirmek üzere tasarlanmıştır, böylece performansı artırmak için bir dizi ucuz sunucuya atabilirsiniz.

Bir S3 Backend kullanırdım ve sonra sadece ihtiyacım olan tüm sunuculara monte ederim - Bu şekilde, herkes zaten anında senkronize olur

Henüz belirtilmemiş gibi görünen bir seçenek, tüm dosyaları tek bir sıkıştırılmış dosyaya arşivlemektir. Bu, toplam boyutu önemli ölçüde azaltmalı ve milyonlarca ayrı dosyayla ilgilendiğiniz tüm masrafları ortadan kaldırmalıdır. Tüm dosya kümesini büyük bir güncellemeyle değiştirerek, kaldırılan dosyaların kopyalarda kaldırıldığından emin olabilirsiniz.

Dezavantajı elbette gereksiz yere birçok dosya aktarıyor olmanızdır. Sıkıştırma sayesinde küçültülmüş boyutla dengelenmiş olabilir veya olmayabilir. Ayrıca bu kadar çok dosyayı sıkıştırmanın ne kadar süreceği konusunda hiçbir fikrim yok.