Dağıtık depolama denildiğinde aklıma ilk gelen her zaman Ceph olmuştur. Açık kaynak, commodity donanımda çalışan, tek bir cluster’dan blok, dosya ve nesne depolamayı aynı anda sunan bir platform. Ama Ceph’in giriş eşiği yüksek — kavramlar karmaşık, terminoloji yoğun ve ilk kurulum deneyimi genelde hayal kırıklığıyla sonuçlanır. Bu yazıda Ceph’in mimarisini temelden açıklayacağım ve ev lab’ında ilk cluster’ınızı kurmak için pratik bilgiler vereceğim.
Neden Ceph?
Klasik depolama yaklaşımında bir sunucu üzerinde diskler bulunur ve o sunucu tek bir hata noktasıdır (SPOF). RAID bu sorunu disk seviyesinde çözer ama sunucu seviyesinde çözmez — sunucunun güç kaynağı, anakartı veya ağ bağlantısı arızalandığında veriye ulaşamazsınız.
Dağıtık depolama ise veriyi birden fazla sunucuya yayar, her verinin birden fazla kopyasını tutar ve herhangi bir sunucunun arızalanmasında hizmeti kesintisiz sürdürür. Ceph bunu yaparken ek bir avantaj sunar: ölçeklenebilirlik. Kapasiteye veya performansa ihtiyaç duyduğunuzda cluster’a yeni sunucu eklersiniz ve Ceph otomatik olarak veriyi yeni sunuculara dengeleyerek yayar.
Ceph’i öne çıkaran temel özellikler: üç depolama modeli tek cluster’da (blok, dosya, nesne), merkezi metadata sunucusu yok (CRUSH algoritması ile veri konumu hesaplanır), commodity donanımda çalışır, self-healing (arızalanan disk veya sunucudan sonra otomatik recovery) ve açık kaynak olması.
Mimari: RADOS Temeli
Ceph’in altında RADOS (Reliable Autonomic Distributed Object Store) yatar. Her şey — blok verisi, dosya, nesne — sonunda RADOS nesneleri olarak saklanır. RADOS, Ceph’in kalbidir.
OSD (Object Storage Daemon)
Her disk (veya partition) bir OSD tarafından yönetilir. OSD daemon’u veri okuma/yazma, replikasyon, recovery ve scrubbing işlerini yapar. Bir sunucuda birden fazla OSD çalışabilir — tipik olarak her disk için bir OSD.
OSD’nin backend storage engine’i BlueStore’dur. BlueStore, diskin tamamını doğrudan yönetir — üzerinde geleneksel bir dosya sistemi yoktur. Bu, double-write penalty’yi ortadan kaldırır ve özellikle SSD’lerde çok daha iyi performans sağlar. Eski FileStore backend’i artık kullanılmıyor.
MON (Monitor)
Monitor daemon’ları cluster durumunu takip eder. Cluster map’lerini (OSD map, MON map, PG map, CRUSH map) tutar ve dağıtır. Paxos konsensüs protokolü ile MON’lar arasında tutarlılık sağlanır.
Minimum 3 MON önerilir (quorum için tek sayı gerekir). MON’lar çok fazla kaynak tüketmez — genelde OSD sunucularında co-locate edilebilir. Ancak büyük cluster’larda (100+ OSD) MON’ları ayrı sunuculara taşımak tercih edilir.
MGR (Manager)
Manager daemon’u cluster metriklerini toplar, dashboard sunar ve ek modüller (Prometheus exporter, balancer, crash collector vb.) barındırır. Active/standby modda çalışır. En az 2 MGR önerilir.
MDS (Metadata Server)
MDS sadece CephFS kullanılıyorsa gereklidir. Dosya sistemi metadata’sını (dizin yapısı, dosya izinleri, inode bilgileri) yönetir. Active/standby veya multi-active konfigürasyonunda çalışabilir. RBD veya RGW kullanıyorsanız MDS’e ihtiyacınız yoktur.
CRUSH Algoritması
CRUSH (Controlled Replication Under Scalable Hashing), Ceph’in en önemli inovasyonudur. Geleneksel dağıtık sistemlerde merkezi bir metadata sunucusu “bu veri nerede” sorusunu yanıtlar. Bu sunucu bir darboğaz ve tek hata noktasıdır.
CRUSH ise veri konumunu deterministik olarak hesaplar. Client, verinin hangi OSD’de olduğunu herhangi bir sunucuya sormadan kendi başına hesaplayabilir. Hesaplama girdileri: nesnenin pool içindeki Placement Group (PG) numarası, cluster’ın CRUSH map’i ve CRUSH kuralları.
CRUSH map, cluster’ın fiziksel topolojisini tanımlar. Hiyerarşi genelde şöyledir: root (tüm cluster) → datacenter → rack → host → OSD. CRUSH kuralları bu hiyerarşiyi kullanarak verilerin farklı failure domain’lere yayılmasını sağlar.
# CRUSH kuralı: her kopya farklı host'ta
rule replicated_rule {
id 0
type replicated
step take default
step chooseleaf firstn 0 type host # failure domain = host
step emit
}type host ifadesini type rack olarak değiştirirseniz kopyalar farklı rack’lere dağılır. Bir sunucu tamamen çökse bile veriye erişim korunur.
Placement Groups (PG)
PG kavramı Ceph’in en kafa karıştırıcı bileşenlerinden biridir. Neden doğrudan “nesneyi OSD’ye eşle” denmiyor?
Sebep ölçeklendirmedir. Bir pool’da milyonlarca nesne olabilir. Her nesnenin hangi OSD’de olduğunu ayrı ayrı takip etmek çok maliyetli olurdu. Bunun yerine nesneler PG’lere eşlenir (hash ile) ve PG’ler OSD’lere eşlenir (CRUSH ile). PG sayısı yüzlerle binlerle ifade edilirken, nesne sayısı milyonlarla ifade edilir — bu aradaki soyutlama katmanı yönetimi mümkün kılar.
PG sayısı seçimi önemlidir. Çok az PG = kötü veri dağılımı. Çok fazla PG = gereksiz memory ve CPU tüketimi. Genel kural:
PG sayısı = (OSD sayısı × 100) / replika sayısı
→ En yakın 2'nin kuvvetine yuvarlaÖrneğin 6 OSD ve 3 replika için: (6 × 100) / 3 = 200, en yakın 2’nin kuvveti = 256 PG. Modern Ceph sürümleri autoscaler özelliği ile PG sayısını otomatik ayarlayabilir — yeni başlayanlar için aktif bırakın.
Depolama Modelleri
RBD (RADOS Block Device)
Ceph üzerinde blok cihazlar oluşturur. Sanal makine diskleri, Kubernetes PersistentVolume, iSCSI target olarak kullanılabilir. Thin provisioning (sadece yazılan veri kadar yer kaplar), snapshot ve clone (copy-on-write, anlık) destekler.
# RBD pool ve image oluşturma
ceph osd pool create rbd_pool 128
rbd pool init rbd_pool
rbd create --size 10G rbd_pool/my_disk
# Linux'ta mount etme
rbd map rbd_pool/my_disk
mkfs.ext4 /dev/rbd0
mount /dev/rbd0 /mnt/ceph-disk
# Snapshot
rbd snap create rbd_pool/my_disk@snap1
rbd snap ls rbd_pool/my_diskCephFS
POSIX uyumlu dağıtık dosya sistemi. Birden fazla client aynı anda okuma/yazma yapabilir. MDS daemon’ları metadata yönetimini üstlenir. NFS/SMB alternatifi olarak düşünülebilir.
RGW (RADOS Gateway)
S3 ve Swift uyumlu nesne depolama gateway’i. HTTP üzerinden RESTful API sunar. Yedekleme, arşivleme ve cloud-native uygulamalar için idealdir.
# RGW kullanıcı oluşturma
radosgw-admin user create --uid=myuser --display-name="My User"
# Herhangi bir S3 client ile kullanılabilir
aws s3 mb s3://my-bucket --endpoint-url http://ceph-rgw:7480Ev Lab’ında İlk Cluster
Minimum 3 sunucu (veya VM) önerilir. Her birinde en az 1 OSD diski, 4GB RAM ve 2 CPU core yeterlidir.
Cephadm ile Kurulum
# İlk node'da bootstrap
curl --silent --remote-name \
https://raw.githubusercontent.com/ceph/ceph/reef/src/cephadm/cephadm
chmod +x cephadm
./cephadm bootstrap --mon-ip 192.168.1.10
# Diğer node'ları ekleme
ssh-copy-id root@node2
ssh-copy-id root@node3
ceph orch host add node2 192.168.1.11
ceph orch host add node3 192.168.1.12
# OSD'leri ekleme
ceph orch apply osd --all-available-devices
# Cluster durumu
ceph status
ceph osd treePool Stratejileri
Replikasyon: Verinin tam kopyalarını tutar. size=3, min_size=2 en yaygın konfigürasyon. Avantajı basitlik ve okuma performansı. Dezavantajı alan verimsizliği — 1TB veri için 3TB ham kapasite gerekir.
Erasure Coding (EC): Veriyi parçalar ve parity ekler. k=4, m=2 ile 6 parça oluşturulur, 2 kayba tolerans. Sadece 1.5x ham kapasite gerekir. Dezavantajı yazma performansının düşük olması. Sık erişilen veriler için replikasyon, arşiv ve yedek için EC kullanın.
# Replicated pool
ceph osd pool create vm-disks 128 128 replicated
ceph osd pool set vm-disks size 3 min_size 2
# Erasure coded pool
ceph osd erasure-code-profile set ec42 k=4 m=2
ceph osd pool create archive 128 128 erasure ec42Networking: Public ve Cluster Network
Ceph’in ağ mimarisi performansı doğrudan etkiler. Ceph iki ayrı ağ kullanmak üzere tasarlanmıştır:
Public Network — İstemcilerin Ceph cluster’a eriştiği ağ. MON bağlantıları, RBD okuma/yazma, CephFS mount, RGW istekleri bu ağdan geçer.
Cluster Network — OSD’lerin kendi aralarında iletişim kurduğu ağ. Replikasyon, recovery, backfill ve heartbeat trafiği burada akar. İstemciler bu ağa erişmez.
Bu iki ağı ayırmak neden önemli? Bir OSD çöktüğünde recovery başlar ve OSD’ler arasında yoğun veri aktarımı olur. Eğer bu trafik istemci trafiğiyle aynı ağı paylaşıyorsa, recovery süresince istemci performansı dramatik düşer. İki ayrı ağ ile recovery trafiği istemci trafiğini etkilemez.
# Bootstrap ile iki ağ tanımlama
cephadm bootstrap --mon-ip 192.168.1.10 \
--cluster-network 10.0.0.0/24
# Mevcut cluster'da cluster network ekleme
ceph config set global cluster_network 10.0.0.0/24Bant genişliği önerileri: minimum 10 Gbps her iki ağ için. 1 Gbps ile başlayabilirsiniz (ev lab’ı) ama production’da 10 Gbps zorunludur. Jumbo frame (MTU 9000) büyük blok I/O’larda ek performans sağlar — ancak ağdaki tüm cihazların desteklemesi gerekir.
BlueStore İnce Ayar
BlueStore üç bileşenden oluşur:
Data — Gerçek nesne verisi. Diskin büyük bölümünü kaplar.
RocksDB (DB) — Nesne metadata’sı, OMAP verileri ve allocation bitmap. LSM-tree tabanlı key-value store.
WAL (Write-Ahead Log) — Yazma işlemleri önce WAL’a kaydedilir, crash durumunda tutarlılık sağlar.
HDD tabanlı OSD’lerde en büyük performans kazanımı, DB ve WAL’ı ayrı bir NVMe SSD’ye taşımaktan gelir. HDD’ler sadece büyük blok veri okuma/yazma yapar; metadata ve WAL işlemleri hızlı SSD’de gerçekleşir.
# OSD oluşturma: DB ve WAL ayrı SSD'de
ceph orch daemon add osd node1:/dev/sdb \
--db-devices /dev/nvme0n1 \
--wal-devices /dev/nvme0n1
# Boyut önerisi:
# DB: OSD kapasitesinin %1-4'ü (4TB HDD → 40-160GB DB)
# WAL: 1-2 GB yeterli
# Bir NVMe SSD, 4-6 HDD OSD'ye hizmet edebilirSSD-only cluster’larda ayrı DB/WAL genellikle gereksizdir — SSD’nin kendisi yeterince hızlıdır.
Device Class ve CRUSH Kuralları
Farklı disk tiplerini (HDD, SSD, NVMe) aynı cluster’da kullanmak yaygındır. Device class özelliği ile her OSD’nin disk tipini tanımlayabilir ve CRUSH kurallarıyla pool-disk eşleştirmesi yapabilirsiniz.
# Device class kontrolü
ceph osd tree
# OSD'ler yanında "hdd" veya "ssd" class'ı görünür
# SSD-only CRUSH kuralı
ceph osd crush rule create-replicated ssd_rule default host ssd
ceph osd pool set fast-pool crush_rule ssd_rule
# HDD-only CRUSH kuralı
ceph osd crush rule create-replicated hdd_rule default host hdd
ceph osd pool set archive-pool crush_rule hdd_ruleBu yaklaşımla aynı cluster’da performans tier (SSD, VM diskleri için) ve kapasite tier (HDD, arşiv için) oluşturabilirsiniz.
Monitoring ve Dashboard
Ceph Dashboard
MGR modülü olarak çalışan web tabanlı yönetim arayüzü:
ceph mgr module enable dashboard
ceph dashboard create-self-signed-cert
ceph dashboard ac-user-create admin -i /tmp/password.txt administrator
# https://node1:8443/Prometheus + Grafana
Production monitoring için standart çözüm:
ceph mgr module enable prometheus
# Metrikler http://node1:9283/metrics adresindeTemel Sağlık Komutları
ceph health detail # Cluster sağlık durumu
ceph osd df tree # OSD kullanım oranları
ceph pg stat # PG durumu
ceph osd perf # OSD performans metrikleri
ceph daemon osd.0 dump_historic_slow_ops # Yavaş işlemlerDüzenli scrub veri bütünlüğünü sağlar. Light scrub (metadata, günlük) ve deep scrub (tam checksum doğrulama, haftalık). Deep scrub I/O yoğundur — düşük trafik saatlerine zamanlayın.
Disaster Senaryoları ve Kurtarma
Ceph’in “no single point of failure” vaadi gerçek, ama yanlış gidemeyecek bir şey yok demek değildir.
Tek OSD kaybı. En yaygın senaryo. Ceph otomatik recovery başlatır. Replicated pool’da veri kaybı riski yok (min_size sağlandığı sürece). Recovery süresi: 4TB HDD, 10 Gbps ağda yaklaşık 1-2 saat.
Tek sunucu kaybı. CRUSH kuralları doğruysa (failure domain = host) veri kaybı olmaz. Ama çok sayıda OSD’nin eşzamanlı recovery’si cluster’a ağır yük bindirir.
MON quorum kaybı. 3 MON’dan 2’si çökerse quorum kaybedilir, cluster read-only moduna geçer. 5 MON kullanmak (2 kaybına dayanıklılık) riski azaltır.
Tam cluster kaybı. Offsite yedekleme olmadan kurtarma mümkün değildir. 3-2-1 kuralı Ceph için de geçerlidir.
# Recovery hızını ayarlama (normal I/O'yu korumak için)
ceph config set osd osd_recovery_max_active 3
ceph config set osd osd_recovery_sleep 0.1Yaygın Hatalar ve İpuçları
Yıllar içinde öğrendiğim dersler:
NTP senkronizasyonunu ihmal etmeyin. MON’lar Paxos protokolü ile çalışır ve zaman farkı 0.05 saniyeyi geçtiğinde sorunlar başlar. chrony mutlaka yapılandırılmalıdır.
Pool’u %80’in üzerinde doldurmayın. Ceph, OSD kullanım oranları dengesiz olduğunda veya genel kapasite yüksek olduğunda nearfull ve full uyarıları verir. Full durumda yazma işlemleri durur. %75’te alarm kurun.
Recovery ve backfill hızını ayarlayın. Varsayılan ayarlar agresiftir. Production’da recovery trafiğinin normal I/O’yu boğmaması için osd_recovery_max_active ve osd_recovery_sleep parametrelerini tuning edin.
min_size’ı 1’e düşürmeyin. min_size=1 demek, tek bir kalan kopya ile yazma işlemi devam eder. O kopya da giderse veri kaybı kesindir. min_size=2 her zaman korunmalıdır. Cluster degraded durumda biraz yavaşlamayı, veri kaybına tercih edin.
OSD’leri manuel olarak out işaretlemeye acele etmeyin. Bir OSD geçici olarak çöktüğünde (sunucu reboot, ağ kesintisi) Ceph varsayılan olarak 10 dakika bekler (mon_osd_down_out_interval). Bu süre içinde OSD geri gelirse gereksiz recovery yapılmaz. Planlı bakım için noout flag’i kullanın.
# Planlı bakım öncesi
ceph osd set noout
# Bakım sonrası
ceph osd unset nooutSonuç
Ceph karmaşık bir sistemdir, ama temelleri anlaşıldığında çok güçlü bir araçtır. RADOS, CRUSH, PG, OSD — bu kavramları kavradığınızda, Ceph’in neden böyle tasarlandığını ve nasıl etkili kullanılacağını anlarsınız. Ev lab’ında 3 sunucu ile başlayıp temel kavramları öğrendikten sonra, aynı bilgiyle petabyte ölçeğinde cluster yönetebilirsiniz — mimari aynı, sadece ölçek değişir.
İlerleyen yazılarda Ceph’i OpenStack ile entegre ederek Cinder, Glance ve Nova backend’i olarak kullanmayı ele alacağız. Ama önce, OpenStack’ın kendisini küçük ölçekte nasıl kuracağımıza bakalım.
