Kurumsal yapılarda object storage ihtiyacı genelde “S3 uyumlu bir yer” talebiyle başlar: yedek, log arşivi, artefact deposu, doküman saklama, SIEM ham veri… Fakat üretim gerçekliği şudur: Ceph’i ayakta tutan şey kurulum komutu değil, arıza sırasında toparlanma fiziğidir. Bu fiziği de en çok iki karar belirler:
- Failure domain (hangi arıza sınırında veri kaybetmemeyi hedefliyorsun?)
- Recovery bütçesi (o arızadan ne hızla ve hangi maliyetle çıkacaksın?)
Ceph’i nerede kullanırım, nerede fren yaparım?
Ceph’in güçlü olduğu yer: genel amaçlı, paylaşımlı, ölçeklenebilir depolama. RGW (S3), RBD (block) veya CephFS (file) ile farklı ihtiyaçları tek platformda birleştirebilirsiniz.
Ama şu iki durumda “sadece Ceph var diye” yük taşımayın:
- Uygulama, depolama gecikmesine aşırı hassassa (özellikle küçük IO’lar ve sync yazım)
- Operasyon ekibiniz 7/24 Ceph olaylarını yönetebilecek olgunlukta değilse (backfill/rebalance/scrub/recovery)
Failure domain: Kaç kopya değil, kopyalar nerede?
Ceph’te replika sayısı (ör. size=3) önemli ama eksik bir cümledir. Asıl soru şudur:
Aynı veri kopyaları aynı host’ta mı, aynı rack’te mi, aynı odada mı, aynı “power domain”de mi?
Kurum içi ortamlarda en pratik failure domain katmanları:
- host: aynı fiziksel sunucu arızası
- rack: rack PDU/ToR arızası veya bakım etkisi
- room / pod: oda/salon bazlı güç veya soğutma olayları
- site / DC: veri merkezi kaybı (bu seviye ayrı konu: stretch cluster vs async replication)
Ceph tarafında bunu CRUSH map ile tanımlarsınız. Hedefiniz: kopyaların “aynı hatada birlikte ölmemesi”.
Ağ ve fizik: Recovery’nin gizli belirleyicileri
Ceph’te en çok göz ardı edilen gerçek: recovery trafikten ibaret değildir, disk ve CPU da yer. OSD’ler hem kullanıcı IO’su hem de recovery için yarışır.
Pratik mimari kararlar:
- Public / cluster network ayrımı: mümkünse ayrı NIC/VLAN, en azından QoS ile ayrıştırma
- Jumbo frame: altyapı oturmuşsa (uçtan uca), recovery süresini düşürür; oturmamışsa gürültü üretir
- Disk sınıfları: NVMe + HDD karışımı varsa, pool ayrımı ve device class ile bilinçli kullanın
Kapasite planı: “Normalde çalışıyor” yetmez
Ceph kapasite planında iki kritik rezerv vardır:
- Arıza rezervi: bir OSD/host/rack kaybında replika yeniden dağıtımı için boşluk
- Recovery zaman rezervi: bu dağıtımı SLO’yu bozmadan bitirebilme
Benim sahada işleyen basit kuralım:
- Replika pool’larında (size=3) uzun ömürlü kullanımlarda %65–70 doluluk üstünü riskli kabul edin
- Erasure coding kullanacaksanız, “ham kapasite kazancı”na değil rebuild maliyetine bakın
Operasyonel tasarım: OSD düştüğünde ne olacak?
OSD düşmesi normaldir. Panik değil, prosedür gerekir.
Minimum runbook soruları:
- OSD “down” mı, “out” mu?
- Disk mi gitti, host mu gitti, ağ mı gitti?
- Cluster “degraded” / “undersized” / “backfill_wait” gibi hangi PG state’lerde?
- Recovery throttle ayarları prod IO’yu öldürüyor mu?
Örnek yaklaşım:
- Önce nedeni ayır: disk arızası mı (SMART), host reboot mu, NIC link mi?
- Kısa süreli olayda “out” etme refleksini geciktir: “flap” arızada gereksiz veri hareketi üretir
- Arıza kalıcıysa OSD’yi out edip kontrollü recovery başlat
- Recovery bitmeden ikinci büyük değişikliği açma (özellikle OSD ekleme/çıkarma)
Alarm ve metrik: “Degraded” tek başına geç kalır
Alarm tarafında yalnızca “HEALTH_WARN” yeterli değildir. Ben şu sinyalleri birlikte izlerim:
PGs degraded / undersized / stalemisplacedoranı ve trendi- Recovery throughput (MB/s) ve ETA hissi
slow opsveosd perfgecikmeleri- Doluluk: en dolu OSD ile en boş OSD farkı (imbalance)
Bu metrikler “cluster bozuldu”dan önce “cluster toparlanamaz hale geliyor” sinyalini verir.
Güvenlik: S3 anahtarı, root şifresi kadar değerlidir
Ceph RGW tarafında en çok yapılan hata, S3’ü “iç servis” sanıp gevşek bırakmaktır. Pratik kontrol listesi:
- RGW’yi segmentle (üretim ağına açık “genel servis” gibi davranmasın)
- TLS’yi standartlaştır (in‑cluster TLS termination + mTLS ihtiyacı)
- IAM benzeri politikaları ve bucket policy’leri netleştir
- “Backup bucket” ile “uygulama bucket”larını ayrı tenant/pool’a böl (blast radius)
Sonuç: Ceph başarısı bir “arıza simülasyonu” kadar gerçektir
Ceph’i iyi yapan şey “bugün çalışması” değil; yarın bir rack gittiğinde hâlâ kontrol edilebilir olmasıdır. Failure domain’i doğru tarif edip, recovery bütçesini kapasite ve ağla desteklediğinizde Ceph kurumsal ortamda gerçekten değer üretir: daha az vendor bağımlılığı, daha iyi ölçek ve daha tutarlı operasyon.