GlusterFS ile Dağıtık Dosya Sistemi

Tek bir NFS sunucusuyla çalışırken hep aynı endişe vardır: o makine düşerse tüm uygulama sunucuları aynı anda dosyalarını kaybeder. Bu tek nokta arızayı ortadan kaldırmanın yollarından biri dağıtık dosya sistemi kurmaktır ve GlusterFS bu alanda kurulumu en anlaşılır seçeneklerden biridir. Birden çok sunucunun diskini tek bir mantıksal dosya sistemi hâline getirir; veriyi otomatik olarak çoğaltır ve bir düğüm düştüğünde hizmet kesintisiz devam eder.

Bu rehberde üç düğümlü, yedekli bir GlusterFS kümesini sıfırdan kuracağız: brick ve volume kavramları, düğümlerin birbirini tanıması, replica volume oluşturma, istemcilerin bağlanması, split-brain durumunun ne olduğu ve nasıl onarıldığı, performans ayarları ve GlusterFS'in gerçek sınırları. Ayrıca hangi iş yüklerinde GlusterFS'in doğru seçim olmadığını da açıkça söyleyeceğim, çünkü yanlış senaryoda kurulan bir dağıtık dosya sistemi çözdüğünden fazla sorun üretir.

GlusterFS Ne Zaman Gerekir#

GlusterFS, birden çok sunucudaki disk alanlarını birleştirip tek bir dosya sistemi olarak sunan, kullanıcı alanında çalışan bir yazılımdır. Özel bir donanım, metadata sunucusu ya da merkezî bir dizin gerektirmez; her düğüm eşittir ve dosyanın nerede olduğu bir algoritmayla hesaplanır. Bu tasarım, kurulumun basit ve düğüm eklemenin kolay olmasını sağlar.

Doğru kullanım alanları oldukça belirgindir: birden çok web sunucusunun ortak yükleme dizini, medya ve belge arşivleri, yedek depoları, log toplama alanları ve konteyner ortamlarında kalıcı hacimler. Ortak noktaları, dosyaların görece büyük ve okuma ağırlıklı olmasıdır.

GlusterFS'in iyi olmadığı senaryoları da baştan bilmek gerekir. Milyonlarca küçük dosyanın sürekli listelendiği iş yüklerinde metadata işlemleri (stat, lookup) her düğüme sorulmak zorunda kalır ve performans yerel diskin çok altına iner; klasik örnek, kaynak kodu ağacının doğrudan Gluster üzerinde derlenmesidir. Veritabanı veri dizinini de Gluster üzerinde tutmayın; rastgele küçük yazma ve fsync semantiği bu mimariye uygun değildir. Düşük gecikme kritikse ya yerel blok depolama ya da nesne depolamaya yönelin.

Basit bir karşılaştırma karar vermeyi kolaylaştırır:

Sadece paylaşım istiyorsanız ve düğüm yedekliliği gerekmiyorsa NFS paylaşımı kurulumu çok daha az işletme yüküyle aynı işi görür.

Temel Kavramlar: Brick, Volume ve Peer#

Üç kavram üzerine kurulu bir sistemdir.

Brick, bir düğümdeki bir dizindir — kümeye katılan en küçük yapı taşı. Genellikle ayrı bir diskte, XFS ile biçimlendirilmiş bir bağlama noktasının altındaki alt dizin olur.

Volume, birden çok brick'in birleşiminden oluşan ve istemcilere sunulan mantıksal dosya sistemidir.

Peer, kümeye katılmış bir sunucudur. Düğümler glusterd servisi üzerinden birbirini tanır.

Volume tipleri, verinin brick'ler arasında nasıl dağıtıldığını belirler:

Üretimde en yaygın tercih replica 3'tür. Neden üç? Çünkü iki kopyalı bir kümede düğümler arasındaki bağlantı koptuğunda her iki taraf da "hayatta kalan benim" diye düşünebilir ve aynı dosyanın iki farklı sürümü oluşur — buna split-brain denir. Üç düğümde çoğunluk (quorum) kavramı işler: iki düğüm birbirini görüyorsa çoğunluktur, tek kalan düğüm yazmayı reddeder. Disk maliyetini düşürmek isterseniz üçüncü düğümü arbiter olarak kurabilirsiniz; arbiter yalnızca metadata tutar, veri tutmaz, ama oylamada tam bir oy sayılır.

Üç Düğümlü Kurulum#

Üç sunucumuz olsun: gluster1 (10.0.0.11), gluster2 (10.0.0.12), gluster3 (10.0.0.13). Her birinde /dev/sdb diski veri için ayrılmış olsun.

Öncelikle üç makinede de isim çözümlemesini garantiye alın. Gluster düğümleri birbirine isimle başvurur; DNS yoksa /etc/hosts yeterlidir:

# Üç sunucuda da /etc/hosts
10.0.0.11  gluster1
10.0.0.12  gluster2
10.0.0.13  gluster3

Şimdi her düğümde diski hazırlayıp Gluster'ı kurun:

# Diski XFS ile biçimlendir (Gluster XFS önerir)
sudo mkfs.xfs -i size=512 /dev/sdb
sudo mkdir -p /veri/brick1
echo '/dev/sdb /veri/brick1 xfs defaults,noatime 0 2' | sudo tee -a /etc/fstab
sudo mount -a

# Brick dizinini oluştur (mount noktasının KENDİSİ değil, altındaki dizin)
sudo mkdir -p /veri/brick1/gv0

# Gluster sunucusunu kur
sudo apt update && sudo apt install -y glusterfs-server   # Debian/Ubuntu
sudo systemctl enable --now glusterd

mkfs.xfs -i size=512 parametresi tavsiye edilir: Gluster genişletilmiş özniteliklerde (xattr) çok bilgi tutar ve büyük inode boyutu bunların inode içinde kalmasını sağlar.

Brick dizininin bağlama noktasının altında olması da bilinçli bir tercihtir. Disk bir şekilde bağlanamazsa /veri/brick1 boş kalır ve gv0 alt dizini bulunmadığı için Gluster brick'i başlatmayı reddeder — böylece kök diske sessizce yazmaya başlamasının önüne geçilir.

Düğümleri birbirine tanıtın (bu komutlar yalnızca gluster1 üzerinde çalıştırılır):

sudo gluster peer probe gluster2
sudo gluster peer probe gluster3
sudo gluster peer status

Güvenlik duvarında düğümler arası portları açın:

# glusterd yönetim portu ve brick portları
sudo ufw allow from 10.0.0.0/24 to any port 24007:24008 proto tcp
sudo ufw allow from 10.0.0.0/24 to any port 49152:49251 proto tcp

Volume Oluşturma ve İstemci Bağlantısı#

Üç kopyalı bir volume oluşturup başlatalım:

sudo gluster volume create gv0 replica 3 \
  gluster1:/veri/brick1/gv0 \
  gluster2:/veri/brick1/gv0 \
  gluster3:/veri/brick1/gv0

sudo gluster volume start gv0
sudo gluster volume info gv0
sudo gluster volume status gv0

Disk maliyetini düşürmek için üçüncü düğümü arbiter yapmak isterseniz:

sudo gluster volume create gv0 replica 3 arbiter 1 \
  gluster1:/veri/brick1/gv0 \
  gluster2:/veri/brick1/gv0 \
  gluster3:/veri/brick1/gv0

Quorum ayarlarını açıkça belirtmek, split-brain'e karşı en önemli tedbirdir:

sudo gluster volume set gv0 cluster.quorum-type auto
sudo gluster volume set gv0 cluster.server-quorum-type server
sudo gluster volume set gv0 cluster.server-quorum-ratio 51%

İstemci tarafında yerel FUSE istemcisini kullanın. NFS ile de bağlanmak mümkündür ama yerel istemci, düğüm arızasında otomatik geçiş yapabildiği için tercih edilir:

sudo apt install -y glusterfs-client
sudo mkdir -p /mnt/paylasim

# İlk bağlantı için herhangi bir düğümü gösterebilirsiniz;
# istemci küme topolojisini oradan öğrenir
sudo mount -t glusterfs gluster1:/gv0 /mnt/paylasim
df -hT /mnt/paylasim

Kalıcı bağlama için fstab satırı; backup-volfile-servers seçeneği, ilk düğüm kapalıyken bile bağlanabilmeyi sağlar:

gluster1:/gv0  /mnt/paylasim  glusterfs  defaults,_netdev,backup-volfile-servers=gluster2:gluster3,nofail  0  0

Yedekliliği doğrulamak için basit bir test yapın: bir düğümü kapatın, istemciden dosya yazın, düğümü geri açın ve dosyanın kendiliğinden çoğaldığını görün. Test etmediğiniz yedeklilik, olmayan yedekliliktir — aynı prensip felaket kurtarma planı için de geçerlidir.

Split-Brain ve Kendiliğinden Onarım#

Bir düğüm bir süre kapalı kaldığında geri döndüğünde eksik değişiklikleri almalıdır. Gluster bunu self-heal mekanizmasıyla arka planda yapar. Durumu izlemek için:

# Onarım bekleyen dosyaları listele
sudo gluster volume heal gv0 info

# Onarımı elle tetikle
sudo gluster volume heal gv0

# Split-brain durumundaki dosyaları ayrıca listele
sudo gluster volume heal gv0 info split-brain

Split-brain, aynı dosyanın iki kopyasının birbirinden bağımsız olarak değiştirilmesi ve Gluster'ın hangisinin doğru olduğuna karar verememesi durumudur. Genellikle ağ bölünmesi sırasında, quorum ayarları yapılmamış iki kopyalı volume'larda görülür. Çözüm için bir kaynak seçmeniz gerekir:

# En büyük dosyayı doğru kabul et
sudo gluster volume heal gv0 split-brain bigger-file /yol/dosya.dat

# Belirli bir brick'i doğru kaynak kabul et
sudo gluster volume heal gv0 split-brain source-brick gluster1:/veri/brick1/gv0 /yol/dosya.dat

# En son değiştirilmiş kopyayı seç
sudo gluster volume heal gv0 split-brain latest-mtime /yol/dosya.dat

Split-brain'e düşmemenin yolu, üç kopya (ya da arbiter'lı üç düğüm) kullanmak ve quorum ayarlarını açıkça yapmaktır. İki kopyalı bir kümede quorum tanımlamadan üretime çıkmak, er geç bu durumla karşılaşacağınız anlamına gelir.

Performans Ayarları ve Sınırlar#

GlusterFS'in performans karakteri, klasik bir yerel dosya sisteminden farklıdır ve beklentiyi buna göre kurmak gerekir. Büyük dosyalarda sıralı okuma-yazma ağ hızına yaklaşır. Küçük dosya ve metadata işlemlerinde ise her stat çağrısı replica sayısı kadar düğüme sorulabilir, bu da gecikmeyi katlar.

Web sunucusu senaryosunda en çok işe yarayan ayarlar şunlardır:

# Metadata ve dizin girdisi önbelleklerini büyüt
sudo gluster volume set gv0 performance.cache-size 512MB
sudo gluster volume set gv0 performance.stat-prefetch on
sudo gluster volume set gv0 performance.quick-read on
sudo gluster volume set gv0 performance.io-cache on

# Küçük dosyalarda okuma-önden getirmeyi kapatmak bazen daha iyidir
sudo gluster volume set gv0 performance.read-ahead off

# Mevcut ayarları listele
sudo gluster volume get gv0 all | head -40

Uygulama katmanında yapabileceğiniz en etkili iyileştirme, Gluster'a giden istek sayısını azaltmaktır. PHP kullanıyorsanız OPcache'in dosya sistemi doğrulama sıklığını düşürmek, statik dosyaları bir CDN'in arkasına almak ve oturum verisini Gluster yerine Redis'te tutmak, herhangi bir Gluster parametresinden çok daha fazla fark yaratır.

Ağ tarafında düğümler arasında düşük gecikme şarttır. GlusterFS'i farklı veri merkezleri arasında senkron replica olarak kurmayın; her yazma tüm kopyalara gitmek zorunda olduğu için gecikme doğrudan uygulamanıza yansır. Coğrafi dağıtım gerekiyorsa Gluster'ın asenkron geo-replication özelliği ya da tamamen farklı bir mimari düşünülmelidir; konunun bütününe coğrafi yedeklilik ve çoklu bölge yazısında değiniyorum.

Son olarak: replica, RAID'in yerine geçmez ve ikisi birbirini tamamlar. Düğüm içindeki disk arızalarını RAID karşılar, düğüm arızalarını Gluster karşılar. Ve hiçbiri yedek değildir — silinen dosya tüm kopyalardan silinir.

Sık Yapılan Hatalar ve Tuzaklar#

Brick'i doğrudan bağlama noktasına koymak. /veri/brick1 dizinini brick olarak vermek, disk bağlanamadığında Gluster'ın kök diske yazmasına yol açar. Her zaman bağlama noktasının altında bir alt dizin (/veri/brick1/gv0) kullanın.

İki kopyalı volume'ü quorum'suz üretime almak. Bu, split-brain davetiyesidir. Ya üç kopya kullanın, ya arbiter ekleyin, ya da en azından cluster.quorum-type auto ayarını yapın.

Brick dizinine doğrudan yazmak. Sunucudaki /veri/brick1/gv0 dizinine SSH ile girip dosya kopyalamak çok cazip görünür ama Gluster'ın xattr metadata'sını bozar ve o dosya diğer kopyalara asla senkronize olmaz. Tüm erişim istemci bağlama noktası üzerinden olmalıdır.

Küçük dosya iş yükünü Gluster'a taşımak. Kaynak kodu derleme, oturum dosyaları, milyonlarca küçük önbellek dosyası — bunlar Gluster'ın en zayıf olduğu senaryolardır. Ölçmeden taşımayın.

_netdev ve backup-volfile-servers yazmamak. İlkinin eksikliği açılışta sistemi kilitler; ikincisinin eksikliği ise fstab'da yazan tek düğüm kapalıyken bağlanamamanıza yol açar — yedekli kurmuş olmanıza rağmen.

Heal durumunu izlememek. gluster volume heal gv0 info çıktısında sürekli birikip duran dosyalar varsa, kümeniz göründüğü kadar sağlıklı değildir. Bu komutu izleme sisteminize bir kontrol olarak ekleyin.

Sıkça Sorulan Sorular#

GlusterFS kaç düğümle kurulmalı#

Yedeklilik istiyorsanız pratik minimum üçtür. İki düğümlü replica kurulumlar teknik olarak çalışır ama ağ bölünmesinde split-brain riski taşır, çünkü hiçbir taraf çoğunluk oluşturamaz. Üçüncü düğümü tam kopya olarak kurmak disk maliyetini artırır; bunun yerine arbiter olarak yapılandırırsanız yalnızca metadata tutar, çok az yer kaplar ve oylamada tam bir oy sayılarak split-brain'i engeller.

GlusterFS yerel disk kadar hızlı mı#

Hayır ve bu beklentiyi baştan doğru kurmak gerekir. Büyük dosyalarda sıralı okuma-yazma ağ hızına yaklaşır ve çoğu senaryo için yeterlidir. Ancak her metadata işlemi ağ üzerinden birden çok düğüme gidebildiği için küçük dosya ve dizin listeleme işlemleri yerel diskin belirgin şekilde altında kalır. Uygulamanız çok sayıda küçük dosyaya sık erişiyorsa taşımadan önce mutlaka gerçek verinizle ölçün.

Bir düğüm çökerse ne olur#

Replica volume'de kalan düğümler hizmete devam eder ve istemciler kesinti yaşamaz; FUSE istemcisi çöken düğümü otomatik olarak devre dışı bırakır. Çöken düğüm geri döndüğünde self-heal mekanizması eksik değişiklikleri arka planda kopyalar. Bu süre zarfında yazma performansı bir miktar düşebilir. Quorum ayarlıysa ve çoğunluk kaybolursa (üç düğümden ikisi düşerse) küme veri tutarlılığını korumak için yazmayı reddeder.

GlusterFS mi Ceph mi kullanmalıyım#

GlusterFS kurulumu ve işletmesi belirgin şekilde daha basittir; birkaç düğümlü, dosya paylaşımı odaklı senaryolarda hızlı sonuç verir. Ceph çok daha kapsamlıdır: aynı kümeden blok, nesne ve dosya arayüzü sunar ve çok büyük ölçeklerde daha iyi davranır, ancak öğrenme eğrisi ve işletme yükü de o oranda yüksektir. Onlarca terabayt ve birkaç düğümle çalışıyorsanız Gluster genellikle yeterlidir; petabayt ölçeğine ve çoklu arayüze ihtiyacınız varsa Ceph'i değerlendirin.

Volume'e sonradan düğüm ekleyebilir miyim#

Evet. Yeni sunucuyu gluster peer probe ile kümeye alır, üzerinde brick dizinini hazırlar ve gluster volume add-brick komutuyla volume'e eklersiniz. Replica volume'lerde brick'leri replica sayısının katları hâlinde eklemeniz gerekir; yani replica 3 bir volume'e tek seferde üç brick eklenir. Ekleme sonrası mevcut dosyaların yeni brick'lere yayılması için gluster volume rebalance gv0 start çalıştırmayı unutmayın.

Split-brain'i nasıl önlerim#

En etkili yöntem üç kopya (ya da iki kopya artı bir arbiter) kullanmak ve quorum ayarlarını açıkça yapmaktır: cluster.quorum-type auto ile istemci tarafı, cluster.server-quorum-type server ile sunucu tarafı çoğunluk kontrolü devreye girer. Bunun yanında düğümler arasındaki ağın kararlı olması ve brick dizinlerine asla doğrudan yazılmaması gerekir. Bu üç kural uygulandığında split-brain pratikte karşınıza çıkmaz.

Kapanış#

GlusterFS, tek sunuculu dosya paylaşımının en büyük zaafını — tek nokta arızasını — makul bir karmaşıklıkla ortadan kaldırır. Aklınızda kalması gereken alışkanlıklar şunlar: üç düğüm ya da arbiter'lı üç kopya kullanın ve quorum ayarlarını açıkça yapın, brick dizinini bağlama noktasının altına koyun, brick'lere asla doğrudan yazmayın, fstab satırına _netdev ile birlikte backup-volfile-servers ekleyin ve heal durumunu izleme sisteminize dâhil edin. Küçük dosya yoğun iş yüklerini ise taşımadan önce mutlaka ölçün.

Böyle bir küme için düşük gecikmeli özel ağa ve tam root erişimine ihtiyacınız var; VDS, bulut sunucu ve dedicated sunucu seçeneklerimiz bu kurulum için uygundur. Küme tasarımı, izleme ve bakım tarafını bize bırakmak isterseniz sunucu yönetimi hizmetimiz devreye girer; replikasyonun yedek yerine geçmediğini unutmayın ve ayrı bir kopya için yedekleme çözümlerimize göz atın.