Proxmox'ta Ceph ile Dağıtık Depolama

Proxmox kümesi kurdunuz, üç düğümünüz var ve şimdi yüksek erişilebilirlik istiyorsunuz. Ama HA'nın çalışması için sanal makine disklerinin tüm düğümlerden erişilebilir olması gerekiyor; her düğümün kendi yerel ZFS havuzunda duran diskler bunu sağlamıyor. İşte Proxmox Ceph kurulumu tam olarak bu boşluğu doldurur: düğümlerin yerel disklerini tek bir dağıtık depolama havuzunda toplar, veriyi düğümler arasında çoğaltır ve bir düğüm çöktüğünde diğerlerinden hizmet vermeye devam eder.

Ceph güçlüdür ama ucuz değildir — donanım olarak da, dikkat olarak da. Yavaş bir ağ üzerine kurulmuş ya da üç kopya yerine iki kopyayla yapılandırılmış bir Ceph kümesi, tek bir sunucudan daha kırılgan olabilir. Bu rehberde Ceph'in Proxmox üzerinde nasıl kurulduğunu, ağ planının neden en kritik karar olduğunu, monitor ve OSD kavramlarını, pool ile PG ayarlarını ve sağlık uyarılarının gerçek anlamlarını anlatacağım. Kümeniz henüz yoksa önce Proxmox cluster kurulumu yazısındaki adımları tamamlayın; Ceph çalışan bir küme olmadan kurulmaz.

Ceph Mimarisi: MON, MGR, OSD ve PG#

Ceph'i anlamak için dört bileşeni bilmek yeterlidir.

OSD (Object Storage Daemon), her fiziksel diske karşılık gelen süreçtir. Bir düğümde altı disk varsa altı OSD çalışır. Veri fiziksel olarak buralarda durur ve her OSD kendi diskinin sağlığından sorumludur.

MON (Monitor), kümenin haritasını tutar: hangi OSD ayakta, hangi düğüm nerede, veri nasıl dağıtılıyor. İstemciler önce MON'a sorup haritayı alır, sonra doğrudan OSD'lerle konuşur — yani MON veri yolunda değildir, ama olmadan küme çalışmaz. MON'lar kendi aralarında quorum kurar, bu yüzden tek sayıda olmalıdır: 3 ya da 5.

MGR (Manager), istatistik toplar, web arayüzü verisi üretir ve modülleri çalıştırır. En az bir tane gerekir, yedeklilik için iki tane önerilir.

PG (Placement Group), veriyi OSD'lere dağıtmak için kullanılan mantıksal kova. Ceph her nesneyi bir PG'ye, her PG'yi de replika sayısı kadar OSD'ye eşler. PG sayısı doğrudan dengeyi ve performansı etkiler; modern sürümlerde pg_autoscaler bu sayıyı otomatik ayarlar ve bunu açık bırakmanız en iyisidir.

İstemci bir blok yazdığında olan şudur: veri parçalara bölünür, CRUSH algoritmasıyla hangi PG'ye gideceği hesaplanır, PG'nin birincil OSD'sine yazılır, birincil OSD veriyi diğer replikalara kopyalar ve tüm replikalar onaylayınca istemciye "yazıldı" cevabı döner. Bu son cümle performansın anahtarıdır: her yazma, ağ üzerinden replika sayısı kadar tur atar. Ağınız yavaşsa disklerinizin hızı hiç önemli değildir.

Ağ Planı — En Kritik Karar#

Ceph'te başarısızlıkların çoğu ağdan gelir. Yukarıdaki yazma zincirini hatırlayın: her yazma işlemi replikalara ulaşıp onay bekliyor. 1 GbE bir hat üzerinde bu, saniyede yaklaşık 120 MB'lık teorik bir tavan demektir ve gerçek dünyada bunun altında kalırsınız. Ceph için en az 10 GbE ağ planlayın; bunu karşılayamıyorsanız Ceph yerine daha basit bir paylaşımlı depolama düşünün.

İkinci kural: Ceph trafiğini corosync ile aynı ağa koymayın. Bir OSD arızalandığında Ceph otomatik yeniden dengeleme (rebalance) başlatır ve hattı doldurur; aynı hatta corosync varsa küme quorum kaybeder, HA devreye girer ve düğümler kendini yeniden başlatır. Yani tek bir disk arızası, tüm kümenin çökmesine dönüşür. Bu senaryoyu üretimde birden fazla kez gördüm.

Ceph iki ayrı ağ tanımı kabul eder:

Küçük kurulumlarda public ve cluster ağını aynı 10 GbE hatta birleştirmek kabul edilebilir; ama corosync'i ayırmak pazarlığa açık değildir. Ağ arayüzlerini planlarken bond kullanmak da iyi bir fikirdir; ağ tarafının ayrıntılarını Proxmox ağ yapılandırması: bridge ve VLAN yazısında ele aldım.

Güvenlik duvarınızda açılması gereken portlar:

Kurulum: pveceph ile Adım Adım#

Proxmox, Ceph kurulumunu pveceph aracıyla oldukça basitleştirir. İşlemi sırayla yapın; adımların sırası önemlidir.

1. Tüm düğümlere Ceph paketlerini kurun. Bu komutu kümedeki her düğümde ayrı ayrı çalıştırın:

# Abonelik yoksa no-subscription deposunu kullan
pveceph install --repository no-subscription

# Kurulan sürümü doğrula
ceph --version

2. Ceph'i yalnızca bir düğümde başlatın ve ağları burada tanımlayın:

# pve1 üzerinde — public ve cluster ağlarını ayrı ver
pveceph init --network 10.10.50.0/24 --cluster-network 10.10.51.0/24

# Yapılandırmayı gör (küme genelinde /etc/pve altında paylaşılır)
cat /etc/pve/ceph.conf

3. Monitor'leri oluşturun. İlk MON init sırasında oluşur; diğerlerini kendi düğümlerinde ekleyin:

# pve2 üzerinde
pveceph mon create
# pve3 üzerinde
pveceph mon create

# Durumu kontrol et — üç MON quorum'da olmalı
ceph mon stat
ceph quorum_status --format json-pretty | grep -A5 quorum_names

4. Manager ekleyin. En az iki tane olsun ki biri düşünce arayüz ve istatistikler devam etsin:

# pve2 üzerinde yedek MGR
pveceph mgr create

5. OSD'leri oluşturun. Kullanacağınız diskler tamamen boş olmalı — üzerinde bölüm tablosu, LVM ya da eski dosya sistemi kalıntısı varsa Ceph reddeder:

# Diskin gerçekten boş olduğunu doğrula
lsblk
ceph-volume inventory /dev/sdb

# Gerekiyorsa temizle (DİKKAT: veri silinir)
wipefs -a /dev/sdb
sgdisk --zap-all /dev/sdb

# OSD oluştur
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# Hızlı bir NVMe'yi DB/WAL cihazı olarak ayır (mekanik disklerde büyük fark yaratır)
pveceph osd create /dev/sdd --db_dev /dev/nvme0n1 --db_size 60

# Ağaç yapısını gör
ceph osd tree

Mekanik disk kullanıyorsanız --db_dev parametresini mutlaka değerlendirin: metadata ve yazma öncesi günlüğü hızlı bir NVMe'ye taşımak, mekanik disklerin rastgele yazma performansını ciddi biçimde iyileştirir. DB cihazının boyutunu OSD kapasitesinin yüzde birkaçı olacak şekilde planlayın ve tek bir NVMe'ye çok fazla OSD bağlamayın — o NVMe ölürse bağlı tüm OSD'ler birlikte gider.

Pool Oluşturma ve Replika Ayarı#

Veri, pool'lar içinde saklanır. Proxmox için bir RBD (RADOS Block Device) pool'u oluşturursunuz ve sanal makine diskleri buraya yazılır.

# Pool oluştur — autoscaler açık, varsayılan 3 kopya
pveceph pool create vm-pool --pg_autoscale_mode on --add_storages 1

# Replika ayarlarını açıkça belirt
ceph osd pool set vm-pool size 3
ceph osd pool set vm-pool min_size 2

# Kontrol
ceph osd pool ls detail
ceph df

size ve min_size değerleri kümenizin dayanıklılığını belirleyen iki sayıdır ve buradaki en yaygın hata, alan kazanmak için size 2 kullanmaktır.

size 2, min_size 1 kombinasyonu özellikle tehlikelidir: tek kopya kalmışken yazmaya devam eder ve o tek kopya da bozulursa veri geri dönüşsüz kaybolur. Üretimde 3/2 dışında bir şey kullanmayın; alan yetmiyorsa disk ekleyin, replika düşürmeyin.

Pool oluşturulduğunda --add_storages 1 sayesinde Proxmox depolama tanımı otomatik eklenir. Elle eklemek isterseniz:

pvesm add rbd ceph-vm --pool vm-pool --content images,rootdir --krbd 0
pvesm status | grep ceph-vm

CephFS de kurabilirsiniz; ISO dosyaları, şablonlar ve yedekler gibi paylaşımlı dosya ihtiyaçları için kullanışlıdır:

# Metadata sunucusu oluştur (birkaç düğümde)
pveceph mds create

# Dosya sistemini kur ve depolamaya ekle
pveceph fs create --name cephfs --pg_num 32 --add-storages 1

Sağlık Takibi ve Uyarıların Anlamı#

Ceph'in sağlık durumunu okumak, onu işletmenin yarısıdır. Temel komut basittir:

# Genel durum
ceph -s

# Sorun varsa ayrıntı
ceph health detail

# Canlı izleme
ceph -w

# OSD kullanım dağılımı — dengesizliği burada görürsünüz
ceph osd df tree

Sağlıklı bir çıktı şuna benzer:

  cluster:
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3
    mgr: pve1(active), standbys: pve2
    osd: 9 osds: 9 up, 9 in
  data:
    pools:   1 pools, 128 pgs
    objects: 45.2k objects, 178 GiB
    usage:   534 GiB used, 3.0 TiB / 3.5 TiB avail
    pgs:     128 active+clean

pgs: active+clean satırındaki tüm PG'lerin bu durumda olması aradığınız şeydir. Sık karşılaşılan uyarılar ve gerçek anlamları:

HEALTH_WARN: Degraded data redundancy. Bir OSD düşmüş ve veri hedeflenen kopya sayısının altında. Ceph otomatik olarak eksik kopyaları yeniden üretmeye başlar. ceph osd tree ile hangi OSD'nin down olduğuna bakın; disk arızasıysa değiştirin, geçici bir sorunsa systemctl start ceph-osd@N ile geri getirin.

HEALTH_WARN: X pgs backfill_toofull. Yeniden dengeleme yapacak yer kalmamış. Bu ciddi bir uyarıdır; Ceph'te doluluğun yüzde 70-75'i geçmemesi gerekir çünkü bir OSD arızalandığında kalan OSD'lerin onun verisini üstlenecek yeri olmalıdır. Disk ekleyin ya da veri silin.

HEALTH_WARN: clock skew detected. Düğümlerin saatleri kaymış. chronyc tracking ile NTP senkronizasyonunu kontrol edin. Küçük görünen bu sorun MON quorum'unu bozabilir.

HEALTH_WARN: too few PGs per OSD. PG sayısı düşük kalmış; autoscaler açıksa kendisi düzeltir. Kapalıysa ceph osd pool set POOL_ADI pg_num DEGER ile artırın.

HEALTH_ERR: full ratio. Bir OSD full_ratio eşiğini (varsayılan yüzde 95) geçmiş ve küme yazmayı durdurmuş. Acil müdahale gerekir; geçici olarak eşiği yükseltip nefes alabilirsiniz ama kalıcı çözüm kapasite eklemektir:

# Geçici nefes alma — kalıcı çözüm DEĞİL
ceph osd set-full-ratio 0.96
ceph osd set-nearfull-ratio 0.88

Bir OSD'yi kalıcı olarak çıkarmanız gerekirse veriyi önce boşaltın:

# OSD'yi kümeden çıkar (veri diğerlerine taşınır)
ceph osd out osd.5
# Yeniden dengeleme bitene kadar bekle
ceph -w
# Sonra tamamen kaldır
pveceph osd destroy 5

Kapasite Planlama ve Sık Yapılan Hatalar#

Ceph'te kullanılabilir kapasiteyi hesaplarken iki çarpanı birlikte uygulayın: replika sayısı ve doluluk tavanı. Üç kopya ve yüzde 70 hedef doluluk ile, 30 TB ham kapasiteden pratikte yaklaşık 7 TB kullanılabilir alan elde edersiniz. Bu oran ilk bakışta şok edici gelir ama dağıtık dayanıklılığın bedeli budur.

Ayrıca bir düğümün tamamen kaybını da hesaba katın. Üç düğümlü bir kümede bir düğüm giderse kalan iki düğüm tüm veriyi üç kopya hâlinde tutamaz; küme degraded durumda çalışmaya devam eder ama tam yedekliliğe dönemez. Bu yüzden Ceph için pratik minimum üç düğümdür, gerçek rahatlık ise dört ve üzerinde başlar.

En sık yapılan hatalar:

Ceph'i 1 GbE ağ üzerine kurmak. Diskleriniz ne kadar hızlı olursa olsun performans ağ tarafından belirlenir. Yeterli ağınız yoksa Ceph kurmayın.

Corosync ile Ceph'i aynı hatta koymak. Bir rebalance, kümenin tamamını çökertebilir. Bu ayrımı yapmak isteğe bağlı değildir.

size 2 ile alan kazanmaya çalışmak. Bir OSD düştüğünde yazma durur ya da tek kopyayla devam eder. Her iki durum da üretim için kabul edilemez.

Diskleri donanımsal RAID kartının arkasına koymak. Ceph diskleri doğrudan görmek ister; RAID kartı yazma önbelleğiyle araya girdiğinde hem performans hem tutarlılık bozulur. Kart varsa HBA/IT moduna alın.

Doluluğu yüzde 85'e kadar çıkarmak. Bir OSD arızalandığında yeniden dengeleme için yer kalmaz ve küme backfill_toofull durumuna girer. Yüzde 70 civarını hedefleyin.

Ceph'i Proxmox yedeklemesinin yerine koymak. Ceph çoğaltma yapar, yedekleme yapmaz. Yanlışlıkla silinen bir dosya üç kopyadan da silinir. Ayrı bir yedekleme kurgusu şarttır; Proxmox Backup Server kurulumu yazısı bu tarafı anlatıyor.

Sıkça Sorulan Sorular#

Ceph için en az kaç sunucu gerekir#

Pratik minimum üç düğümdür, çünkü üç kopya politikası her kopyanın farklı bir düğümde durmasını gerektirir ve monitor quorum'u da tek sayıda düğüm ister. Üç düğümde bir düğüm kaybettiğinizde küme çalışmaya devam eder ama tam yedekliliğe dönemez. Gerçekten rahat bir işletim için dört ve üzeri düğüm önerilir.

Ceph mi ZFS mi kullanmalıyım#

İkisi farklı problemleri çözer. ZFS tek bir düğümün yerel depolamasını dayanıklı ve özellikli hâle getirir; Ceph ise depolamayı düğümler arasında paylaştırır ve bir düğüm çöktüğünde verinin diğerlerinden erişilebilir kalmasını sağlar. Yüksek erişilebilirlik hedefliyorsanız ve en az üç düğümünüz varsa Ceph'e ihtiyacınız olur. Tek sunucu ya da yerel disk yeterliyse ZFS çok daha basit ve verimlidir.

Ceph performansı neden düşük#

En yaygın üç sebep sırasıyla şudur: ağın yetersiz olması (1 GbE üzerinde Ceph her zaman yavaştır), mekanik disklerde ayrı bir DB/WAL cihazı kullanılmaması ve kümenin doluluk sınırına yaklaşmış olması. Ayrıca ceph osd df tree ile OSD'ler arasında ciddi bir kullanım dengesizliği olup olmadığını kontrol edin; dengesiz dağılım en dolu OSD'yi darboğaza çevirir.

Ceph kurunca ayrıca yedek almam gerekir mi#

Kesinlikle gerekir. Ceph çoğaltma yapar, yani donanım arızasına karşı korur; ancak yanlışlıkla silinen bir dosyayı, bozulan bir veritabanını ya da fidye yazılımının şifrelediği verileri geri getirmez — bu değişiklikler tüm kopyalara anında yansır. Ceph'i dayanıklılık katmanı, yedeklemeyi ise zaman içinde geri dönüş mekanizması olarak düşünün.

PG sayısını elle mi ayarlamalıyım#

Modern Ceph sürümlerinde pg_autoscaler bu işi yeterince iyi yapıyor ve açık bırakmanızı öneririm. Autoscaler pool'un kullanımına göre PG sayısını kademeli olarak ayarlar. Elle müdahaleyi yalnızca özel bir durum varsa, örneğin bir pool'un beklenen boyutunu önceden biliyorsanız target_size_ratio ile yönlendirerek yapın.

Bir OSD diski arızalanırsa ne yapmalıyım#

Ceph zaten eksik kopyaları otomatik olarak yeniden üretmeye başlar, yani acil bir veri kaybı riski yoktur. Sizin yapmanız gereken önce ceph osd out osd.N ile OSD'yi kümeden çıkarmak, yeniden dengeleme bittikten sonra pveceph osd destroy N ile kaldırmak, diski fiziksel olarak değiştirmek ve yeni diski pveceph osd create ile eklemektir. Bu süre boyunca kümenin doluluk seviyesini takip edin.

Kapanış#

Ceph, Proxmox altyapısını tek tek sunuculardan gerçek bir sanal veri merkezine dönüştüren bileşendir; canlı göç ve yüksek erişilebilirlik ancak böyle paylaşımlı bir depolama katmanıyla anlamlı hâle gelir. Aklınızda tutmanız gereken dört kural şudur: ağa yatırım yapın ve corosync'i mutlaka ayırın, üretimde size 3 / min_size 2 dışına çıkmayın, doluluğu yüzde 70 civarında tutun ve Ceph'i asla yedeklemenin yerine koymayın.

Kurduğunuz Ceph havuzunun üzerine yüksek erişilebilirliği eklemek için Proxmox HA kurulumu yazısındaki adımlarla devam edebilirsiniz. Ceph kümesi kuracağınız donanım arıyorsanız dedicated sunucu ve colocation seçeneklerimiz bu iş yükü için uygun bir zemin sunar; kendi dağıtık depolamanızı işletmek istemiyorsanız hazır bulut sunucu paketlerimiz zaten böyle bir altyapı üzerinde çalışır. Kurulum ve bakım tarafını devretmek isterseniz sunucu yönetimi hizmetimiz devreye girer.