Ceph’i geleneksel SAN depolama ünitelerinden (Pure Storage, NetApp) ayıran en temel özellik, verinin küme içindeki hangi diske (OSD) yazılacağını tutan merkezi bir meta veri tablosuna (lookup table) ihtiyaç duymamasıdır. Bunun yerine Ceph, istemci ve OSD’lerin tamamen deterministik bir matematiksel algoritma kullanarak verinin yerini kendi başlarına hesaplamasını sağlayan CRUSH (Controlled Replication Under Scalable Hashing) haritasını kullanır.
Ancak aynı fiziksel sunucular (veya aynı küme) içerisinde hem kurumsal NVMe/SSD diskler hem de yüksek kapasiteli HDD diskler barındıran hibrit (hybrid) bir Proxmox VE veya bare-metal Ceph kümesinde varsayılan CRUSH kurallarını kullanmak felakete yol açar: Ceph, performans kritik veritabanı disklerini rastgele dönen HDD’lere yazar veya tek bir sunucu (host) kapandığında tüm replikaların aynı sunucudaki farklı disklere düşmesi yüzünden küme veriye erişimi keser (PG_AVAILABILITY).
Bugünkü yazımızda, Ceph CRUSH hiyerarşisini donanım sınıflarına (device-class) göre nasıl böleceğimizi, kabin/sunucu bazlı hata alanlarını (failure-domain) nasıl kurgulayacağımızı ve canlı bir kümede veri kaybı olmadan CRUSH kurallarını nasıl devreye alacağımızı inceliyoruz.
1. CRUSH Hiyerarşisi ve Failure Domain (Hata Alanı) Tasarımı
CRUSH haritası, fiziksel veri merkezi topolojinizi yansıtan ters bir ağaç (tree) yapısındadır (root -> datacenter -> rack -> host -> osd).
Kurumsal bir kümede verinin kopyaları (size = 3) dağıtılırken Ceph’in hangi sınırları aşması gerektiğini failure-domain belirler:
- failure-domain = osd (Asla Üretimde Kullanmayın): Verinin 3 kopyasını aynı sunucudaki 3 farklı diske yazabilir. Tek bir sunucunun anakartı yandığında veya reboot edildiğinde tüm kopyalar aynı anda kaybolur.
- failure-domain = host (Standart 3-5 Sunuculu Kümeler): Ceph, verinin her bir kopyasını mutlaka farklı fiziksel sunuculara yazar. En az 3 fiziksel sunucu gerektirir; bir sunucu tamamen kapansa bile sanal makineler kesintisiz çalışır.
- failure-domain = rack (Büyük Veri Merkezleri): 3 veya daha fazla sunucu kabininiz (Rack) varsa, her kopyayı farklı kabinlere yerleştirerek Top-of-Rack (TOR) switch veya kabin PDU güç kesintilerine karşı tam koruma sağlar.
2. NVMe ve HDD Havuzlarını İzole Etmek (device-class)
Modern Ceph sürümlerinde (Luminous ve sonrası) her OSD ayağa kalkarken disk tipini otomatik algılar ve üzerine bir device-class etiketi basar (nvme, ssd veya hdd).
Adım 1: Mevcut OSD Sınıflarını Doğrulayın ve Düzeltin
Bazen kurumsal RAID kontrolcüler arkasından geçen veya özel PCIe yollarına bağlı NVMe diskler Ceph tarafından yanlışlıkla ssd veya hdd olarak etiketlenebilir. Mevcut ağacı kontrol edelim:
# CRUSH ağacını ve her OSD'nin atandığı device-class etiketini görüntüleyin
ceph osd crush treeEğer bir NVMe disk yanlışlıkla ssd olarak algılanmışsa (örneğin osd.4 ve osd.5), etiketini canlı sistemde kesintisiz olarak düzeltebilirsiniz:
# Eski sınıf etiketini kaldır ve 'nvme' sınıfını ata
ceph osd crush rm-device-class osd.4 osd.5
ceph osd crush set-device-class nvme osd.4 osd.5Adım 2: Sadece NVMe veya Sadece HDD Kullanan CRUSH Kuralları Oluşturmak
Varsayılan replicated_rule kuralı hiçbir cihaz sınıfı ayrımı yapmaz; hem NVMe hem de HDD diskleri aynı havuza karıştırır.
- Sanal Makine ve Veritabanları için saf NVMe kuralı (nvme_replicated):
ceph osd crush rule create-replicated nvme_replicated default host nvme- Yedekleme (Backup) ve Soğuk Arşiv için saf HDD kuralı (hdd_replicated):
ceph osd crush rule create-replicated hdd_replicated default host hdd(Buradaki sözdizimi: create-replicated <kural_adı> <root_düğümü> <failure_domain> <device_class> şeklindedir).
3. Havuzları (Pools) Yeni CRUSH Kurallarına Bağlamak
Oluşturduğunuz kuralları ilgili Ceph havuzlarına atadığınız anda, Ceph arka planda verileri yavaşça (throttled recovery) doğru disk sınıflarına taşımaya başlar:
# 1. Hızlı VM diskleri havuzunu (rbd_nvme) sadece NVMe disklerle sınırla
ceph osd pool set rbd_nvme crush_rule nvme_replicated
# 2. Yedekleme/Arşiv havuzunu (ceph_archive) sadece HDD disklerle sınırla
ceph osd pool set ceph_archive crush_rule hdd_replicatedKritik Uyarı (device_health_metrics Havuzu): Proxmox VE veya Ceph kurulumlarında otomatik oluşan .mgr ve device_health_metrics havuzları genellikle varsayılan replicated_rule üzerinde kalır. Eğer kümenizde hem NVMe hem HDD varsa ve bu sistem havuzlarının yavaş HDD’ler yüzünden gecikmesini istemiyorsanız, onların da CRUSH kuralını nvme_replicated olarak güncelleyin:ceph osd pool set .mgr crush_rule nvme_replicated
4. Farklı Kapasiteli Disklerde Dengesiz Doluluk (ceph-balancer) Çözümü
Aynı NVMe havuzunda hem 1.92 TB hem de 3.84 TB boyutunda diskleriniz varsa, CRUSH algoritması ağırlık (Weight) oranına göre dağıtım yapsa bile bazı OSD’ler %85 doluluğa ulaşırken bazıları %65 seviyesinde kalabilir. Tek bir OSD’nin nearfull (%85) veya full (%95) sınırına dayanması tüm kümenin yazma işlemlerini durdurur.
Modern Ceph kümelerinde yerleşik olarak gelen balancer modülünü upmap modunda aktif etmek, arka planda sıfır veri kaybıyla Placement Group (PG) yerleşimlerini milimetrik olarak dengeler:
# 1. Balancer modülünü aktif edin
ceph balancer on
# 2. En verimli dengeleme algoritması olan 'upmap' modunu seçin
ceph balancer mode upmap
# 3. Dengeleme durumunu ve kümedeki doluluk sapmasını (stddev) kontrol edin
ceph balancer status