Güncellendi:
GlusterFS, birden fazla sunucudaki depolama alanını ortak bir dosya sistemi görünümü altında sunabilen dağıtık bir dosya sistemidir. Kapasite ve erişim tasarımında esneklik sağlayabilir; ancak ağ bölünmesi, kopya tutarlılığı ve bakım süreçleri açıkça planlanmalıdır. Yeni kurulumdan önce projenin ve kullandığınız dağıtımın güncel sürüm, paket ve destek durumunu doğrulayın.
Görseli büyüt →
Brick ve volume kavramları
Brick, GlusterFS’e sunulan sunucu ve dizin birleşimidir. Volume, bir veya daha fazla brick’in belirli bir düzenle bir araya getirildiği mantıksal yapıdır. Brick dizininin üzerinde hangi yerel dosya sisteminin kullanıldığı, aygıt kapasitesi ve mount sürekliliği veri katmanını etkiler.
Dağıtılmış bir volume dosyaları brick’ler arasında yerleştirebilir; bu tek başına her dosyanın birden çok kopyasını oluşturmaz. Replicated volume ise belirli bir replikasyon düzeni kullanır. Dispersed gibi farklı düzenlerin kapasite ve onarım davranışı ayrıca değerlendirilmelidir. Topoloji adını yalnız “yedekli” sözcüğüyle özetlemeyin.
Kurulum öncesi hazırlık
Sunucuların isim çözümlemesi, zaman eşitlemesi, ağ erişimi, disk mount noktaları ve seçilen paket sürümü tutarlı olmalıdır. Üretim dosyalarının bulunduğu diski doğrulamadan biçimlendirme veya brick hazırlama komutu çalıştırmayın. Deneme ortamında yeni ve ayrı disklerle ilerlemek yanlış aygıt seçiminin etkisini sınırlar.
- İş yükünün küçük dosya, büyük dosya ve eşzamanlı erişim davranışını belirleyin.
- Replica sayısını ve fiziksel hata alanlarını gerçek sunucu/raf düzeniyle eşleştirin.
- Resmi sürüm belgesine göre trusted storage pool ve volume oluşturma adımlarını uygulayın.
- İstemci erişimini ve seçilen volume seçeneklerini sınırlı test verisiyle doğrulayın.
Eski bir dağıtımın paket komutlarını yeni işletim sistemine kör biçimde taşımayın. Desteklenen istemci ve sunucu birleşimi ile yükseltme yolunu belirlemeden canlı kümeyi değiştirmeyin.
Quorum, heal ve split-brain
Quorum, arıza veya ağ bölünmesi sırasında hangi koşullarda işlemlerin sürdürülmesine izin verileceğini belirleyen kararın parçasıdır. Yanlış quorum tasarımı kullanılabilirliği veya tutarlılığı etkileyebilir. Daha fazla düğüm eklemek, kurallar yanlışsa sorunu kendiliğinden çözmez.
Heal, kopyalar arasındaki eksikleri tamamlamaya yönelik süreçtir. Split-brain ise çelişen kopyaların hangi verisinin esas alınacağını belirsizleştiren bir durumdur. Dosyanın yalnız en yeni tarihli kopyasını seçmek her uygulama için doğru çözüm değildir; kaynak veriyi, uygulama tutarlılığını ve resmi çözüm prosedürünü inceleyin.
Bakım sırasında neyi izlemelisiniz?
Brick durumu, ağ hataları, heal kuyruğu, dosya gecikmesi, istemci hataları ve boş alanı birlikte izleyin. Kapasite ekleme, yeniden dengeleme veya arızalı brick değiştirme veri hareketi oluşturur. Bu işlemlerin aktif uygulama yüküne etkisini ölçün ve durdurma/geri dönüş koşullarını belirleyin.
Replica kopyaları yedekleme politikası değildir. Yanlış dosya silme veya uygulama kaynaklı bozulma kopyalara yansıyabilir. Ayrı erişimle korunan yedek, tutarlılık kontrolü ve geri yükleme denemesi işletim planına dahil edilmelidir.
Diğer yaklaşımlarla karşılaştırma
Bir sunucunun dosya sistemini paylaşmak için NFS, farklı erişim türlerini tek platformda toplamak için Ceph veya uygulama nesneleri için object storage daha uygun olabilir. Kararı yalnız ölçek veya hız iddiasıyla değil; erişim semantiği, hata davranışı ve ekibin bakım kapasitesiyle verin.
Sık sorulan sorular
- Distributed volume otomatik olarak replica içerir mi?
-
Hayır. Dosya dağıtımı ve kopya tutma farklı topoloji özellikleridir; seçilen volume düzenini açıkça doğrulayın.
- Split-brain oluştuğunda heal her zaman kendiliğinden çözer mi?
-
Çelişen kopyaların doğru kaynağı belirlenmeden otomatik onarım yeterli olmayabilir. Uygulama verisini ve resmi çözüm adımlarını incelemek gerekir.
Sonraki adım
Depolama modelini Ceph mimarisi ve dosya paylaşımını NFS güvenlik rehberi ile karşılaştırın.
