Ceph Dağıtık Depolama Rehberi

Son Güncelleme: Haziran 2026

Ceph, sunucu altyapılarında yüksek erişilebilirlik, ölçeklenebilirlik ve hata toleransı sağlamak için kullanılan dağıtık depolama çözümüdür. Özellikle sanallaştırma, bulut sunucu, yedekleme ve büyük veri senaryolarında tek bir disk ya da tek bir depolama cihazına bağımlılığı azaltarak daha dayanıklı bir yapı sunar.

Bu rehberde Ceph’in ne olduğunu, hangi bileşenlerden oluştuğunu, blok depolama, nesne depolama ve dosya sistemi kullanım senaryolarını, kurulum öncesi planlamayı ve güvenli yönetim önerilerini sade ama teknik açıdan doyurucu şekilde inceleyeceğiz.

İçindekiler

• Ceph Nedir?
• Ceph Mimarisi ve Temel Bileşenler
• Ceph Depolama Türleri
• Kurulum Öncesi Planlama
• Örnek Kurulum Mantığı
• Performans ve Kapasite Planlama
• Güvenlik, Yedekleme ve Bakım Önerileri
• Pratik Kullanım Senaryoları
• Sıkça Sorulan Sorular
• Sonuç

Ceph Nedir?

Ceph, birden fazla sunucudaki diskleri tek bir mantıksal depolama havuzu gibi kullanmayı sağlayan açık kaynaklı bir dağıtık depolama sistemidir. Klasik depolama yaklaşımında veriler çoğunlukla tek bir NAS, SAN veya fiziksel disk grubunda tutulurken Ceph, veriyi kümeye dahil edilen farklı sunuculara dağıtarak hem kapasiteyi hem de dayanıklılığı artırır.

Ceph’in temel amacı, depolama altyapısında tek hata noktası riskini azaltmaktır. Bir disk, sunucu veya ağ bağlantısı arızalansa bile doğru yapılandırılmış bir Ceph kümesi veriyi diğer kopyalardan sunmaya devam edebilir. Bu nedenle Ceph; sanallaştırma platformları, özel bulut altyapıları, yedekleme sistemleri, medya arşivleri ve yüksek kapasiteli veri saklama ihtiyaçları için tercih edilir.

Ceph, veriyi sabit bir merkezi yöneticiye bağlı kalmadan dağıtmak için CRUSH algoritmasını kullanır. CRUSH, verinin hangi disklere yazılacağını belirleyen akıllı bir yerleşim mekanizmasıdır. Böylece sistem büyüdükçe kapasite eklemek için sadece yeni diskler veya yeni sunucular kümeye dahil edilebilir.

• Ölçeklenebilirlik: Yeni disk ve sunucu eklenerek kapasite yatay şekilde artırılabilir.
• Hata toleransı: Veri çoğaltma veya silme kodlama yöntemiyle disk arızalarına karşı korunabilir.
• Esnek kullanım: Blok, nesne ve dosya sistemi depolama senaryolarını destekler.
• Açık kaynak yapı: Lisans maliyeti olmadan özelleştirilebilir ve topluluk desteğiyle geliştirilebilir.

Ceph Mimarisi ve Temel Bileşenler

Ceph’i doğru anlamak için mimarideki temel bileşenleri bilmek gerekir. Her bileşenin görevi farklıdır ve üretim ortamında bu rollerin ayrı sunuculara dağıtılması önerilir.

OSD Nedir?

OSD, Object Storage Daemon yani nesne depolama hizmeti anlamına gelir. Ceph kümesinde verinin yazıldığı ve okunduğu asıl servis OSD’dir. Genellikle her fiziksel disk veya SSD için bir OSD çalıştırılır. OSD’ler veriyi saklar, diğer OSD’lerle çoğaltma yapar, disk sağlığını takip eder ve küme içi yeniden dengeleme işlemlerine katılır.

MON Nedir?

MON, Monitor yani izleyici bileşendir. Ceph kümesinin haritasını, OSD durumlarını, erişim bilgilerini ve quorum adı verilen karar çoğunluğu yapısını yönetir. Üretim ortamında tek MON kullanmak önerilmez; genellikle 3 veya 5 MON düğümü tercih edilir. Bu sayede bir izleyici düğüm devre dışı kalsa bile küme çalışmaya devam edebilir.

MGR Nedir?

MGR, Manager yani yönetici servisidir. Ceph’in performans metriklerini, izleme verilerini ve yönetim arayüzlerini sağlar. Dashboard, Prometheus entegrasyonu ve çeşitli yönetim modülleri MGR üzerinden çalışır. MGR, günlük operasyonlarda kümenin izlenmesini kolaylaştırır.

MDS Nedir?

MDS, Metadata Server yani meta veri sunucusudur. CephFS kullanıldığında dosya ve dizin meta verilerini yönetir. Blok depolama veya nesne depolama kullanımında MDS zorunlu değildir; ancak CephFS ile paylaşımlı dosya sistemi kurulacaksa gereklidir.

RGW Nedir?

RGW, RADOS Gateway bileşenidir. S3 uyumlu nesne depolama erişimi sağlar. Uygulamalar, yedekleme yazılımları veya medya servisleri RGW üzerinden Ceph’e nesne depolama mantığıyla bağlanabilir.

Ceph Depolama Türleri

Ceph’in güçlü yönlerinden biri farklı depolama modellerini aynı altyapı üzerinde sunabilmesidir. Bu sayede tek bir küme hem sanal makineler için blok depolama hem de uygulamalar için nesne depolama sağlayabilir.

RBD ile Blok Depolama

RBD, RADOS Block Device yani blok cihazı anlamına gelir. Sanal makinelerin disk imajları, veritabanı diskleri veya uygulama sunucularının kalıcı diskleri RBD üzerinde tutulabilir. Sanallaştırma ortamlarında RBD, yüksek erişilebilirlik açısından güçlü bir seçenektir. Örneğin bir hypervisor (sanallaştırma ana makinesi) arızalandığında sanal makine diski Ceph üzerinde durduğu için başka bir düğümden tekrar başlatılabilir.

CephFS ile Dosya Sistemi

CephFS, POSIX uyumlu paylaşımlı dosya sistemi sunar. Web sunucuları arasında ortak dosya alanı, medya içerik havuzu veya uygulama dosyaları için kullanılabilir. Ancak CephFS tasarlanırken MDS kaynakları, meta veri yoğunluğu ve dosya sayısı dikkatle planlanmalıdır.

RGW ile Nesne Depolama

Nesne depolama, dosyaları klasik dizin yapısı yerine obje ve bucket mantığıyla saklar. RGW sayesinde Ceph, S3 benzeri API yapılarıyla kullanılabilir. Yedekleme arşivleri, log saklama, görsel ve video dosyaları, uygulama çıktıları bu model için uygundur.

Kurulum Öncesi Planlama

Ceph kurulumu yalnızca paket yüklemekten ibaret değildir. Başarılı bir Ceph altyapısı için kapasite, ağ, disk türü, hata toleransı ve bakım stratejisi önceden tasarlanmalıdır. Küçük test ortamlarında 3 düğümlü yapı yeterli olabilir; ancak üretim ortamında iş yüküne göre daha fazla OSD düğümü planlanmalıdır.

• Düğüm sayısı: Minimum 3 düğüm, quorum ve hata toleransı için sağlıklı bir başlangıçtır.
• Ağ tasarımı: Public network ve cluster network ayrımı performans ve güvenlik açısından önemlidir.
• Disk seçimi: NVMe, SSD ve HDD farklı gecikme ve IOPS değerleri sunar; iş yüküne göre ayrılmalıdır.
• Replikasyon oranı: 3 kopya veri güvenliği sağlar ancak kullanılabilir kapasiteyi düşürür.
• Failure domain: Veri kopyalarının aynı disk, aynı sunucu veya aynı kabin içinde kalmaması hedeflenmelidir.

Ceph için en kritik konulardan biri ağ gecikmesidir. OSD’ler sürekli birbirleriyle konuştuğu için zayıf ağ altyapısı doğrudan performans kaybına neden olur. Bu nedenle üretim ortamında mümkünse 10 Gbps veya daha yüksek hızlı ağ bağlantıları tercih edilmelidir.

Ceph’i sanallaştırma altyapısında kullanmak istiyorsanız, Sanal Sunucu ve Kiralık Sunucu seçenekleri arasında iş yükünüze uygun kaynak planlaması yapmanız önemlidir. Yoğun disk I/O gerektiren yapılarda fiziksel kaynakların ayrılmış olması performans tahmin edilebilirliğini artırır.

Örnek Kurulum Mantığı

Ceph kurulumu dağıtıma, sürüme ve tercih edilen yönetim aracına göre değişebilir. Güncel yapılarda cephadm sık kullanılan yönetim yöntemlerinden biridir. Aşağıdaki komutlar, üretim ortamına doğrudan uygulanacak kesin kurulum reçetesi değil; temel mantığı göstermek için örnek akış niteliğindedir.

Cephadm Kurulum Başlangıcı

İlk düğümde Ceph kurulum aracı hazırlanır ve bootstrap işlemi yapılır. Bootstrap, ilk MON ve MGR servislerinin oluşturulmasını sağlar.

curl --silent --remote-name --location https://download.ceph.com/rpm-squid/el9/noarch/cephadm
chmod +x cephadm
./cephadm bootstrap --mon-ip 192.168.10.10

Kurulum tamamlandıktan sonra Ceph komut satırı aracıyla küme durumu kontrol edilebilir.

ceph status
ceph health detail

Yeni Düğüm Ekleme

Ceph kümesine yeni sunucu eklemek için SSH anahtar erişiminin doğru yapılandırılması gerekir. Ardından düğüm orkestrasyon yapısına dahil edilir.

ceph orch host add ceph-node-02 192.168.10.11
ceph orch host add ceph-node-03 192.168.10.12

Diskleri OSD Olarak Kullanma

Boş diskler listelenir ve uygun diskler OSD olarak kümeye eklenir. Üretim ortamında yanlış diskin seçilmemesi için disk seri numarası ve bağlantı yolu dikkatle kontrol edilmelidir.

ceph orch device ls
ceph orch daemon add osd ceph-node-02:/dev/sdb
ceph orch daemon add osd ceph-node-03:/dev/sdb

OSD eklendikten sonra Ceph veriyi yeni disklere yeniden dağıtmaya başlayabilir. Bu süreçte performans dalgalanmaları yaşanabileceği için yoğun üretim saatlerinde büyük ölçekli disk ekleme işlemlerinden kaçınılmalıdır.

Performans ve Kapasite Planlama

Ceph performansı yalnızca disk hızına bağlı değildir. Ağ, CPU, bellek, OSD sayısı, placement group ayarları, replikasyon yöntemi ve istemci iş yükü birlikte değerlendirilmelidir. Bu nedenle Ceph performans planlamasında tek bir metrik yerine bütünsel yaklaşım gerekir.

• IOPS ihtiyacı: Veritabanı ve sanal makine diskleri yüksek IOPS ister; HDD tabanlı yapı bu iş yükünde yetersiz kalabilir.
• Sıralı aktarım: Büyük yedek dosyaları ve medya arşivleri için throughput yani aktarım hızı daha önemlidir.
• Gecikme: Küçük bloklu yoğun yazma işlemlerinde latency yani gecikme kritik hale gelir.
• Bellek kullanımı: OSD başına yeterli RAM ayrılmalı, işletim sistemi ve servisler için boş alan bırakılmalıdır.
• CPU yükü: Replikasyon, sıkıştırma, şifreleme ve recovery işlemleri işlemci tüketimini artırabilir.

Kapasite planlamasında ham kapasite ile kullanılabilir kapasite karıştırılmamalıdır. Örneğin 3 kopyalı replikasyon kullanıldığında 90 TB ham disk kapasitesi teorik olarak yaklaşık 30 TB kullanılabilir alan sunar. Erasure coding yani silme kodlama daha verimli kapasite kullanımı sağlayabilir; ancak CPU tüketimi ve gecikme etkisi dikkate alınmalıdır.

Güvenlik, Yedekleme ve Bakım Önerileri

Ceph yüksek dayanıklılık sağlasa da tek başına yedekleme çözümü değildir. Replikasyon, disk veya düğüm arızasına karşı koruma sağlar; ancak yanlışlıkla silme, uygulama hatası, fidye yazılımı veya operatör hatası gibi risklere karşı ayrı yedekleme stratejisi gerekir. Bu nedenle kritik veriler için Yedekleme Hizmeti gibi ek koruma katmanları değerlendirilmelidir.

• Ağ izolasyonu: Ceph cluster network dış erişime kapalı tutulmalı, yalnızca gerekli düğümler erişebilmelidir.
• Yetki yönetimi: CephX anahtarları servis bazlı oluşturulmalı, tüm uygulamalara yönetici anahtarı verilmemelidir.
• Şifreleme: Disk seviyesinde veya istemci tarafında şifreleme ihtiyaçlara göre planlanmalıdır.
• Güncelleme politikası: Ceph sürüm yükseltmeleri bakım penceresinde ve önce test ortamında denenerek yapılmalıdır.
• İzleme: Disk doluluk oranı, OSD down durumu, recovery hızı ve latency düzenli takip edilmelidir.

Ceph bakımında en sık yapılan hatalardan biri doluluk oranlarını geç fark etmektir. Küme belirli doluluk eşiklerini aştığında veri yeniden dağıtımı zorlaşabilir ve performans düşebilir. Bu nedenle kapasite alarmı yalnızca yüzde 95 gibi geç bir seviyede değil, daha erken eşiklerde oluşturulmalıdır.

ceph df
ceph osd df tree
ceph osd status

OSD arızası durumunda önce problemin diskten mi, ağdan mı, servis yapılandırmasından mı kaynaklandığı anlaşılmalıdır. Her uyarıda doğrudan OSD silmek, veri riskini artırabilir. Kontrollü bakım yaklaşımı, Ceph’in güvenilirliğini korumanın temel şartıdır.

Pratik Kullanım Senaryoları

Ceph, farklı ölçeklerde ve farklı ihtiyaçlarda kullanılabilir. Ancak her senaryoda doğru tasarım yapılmalıdır; küçük bir web sitesi için karmaşık Ceph kümesi gereksiz olabilirken, çok sayıda sanal makine barındıran bir altyapıda Ceph ciddi avantaj sağlar.

Sanallaştırma Altyapısında Ortak Depolama

Birden fazla hypervisor kullanılan yapılarda sanal makine disklerinin tek bir fiziksel sunucuda kalması yüksek risk oluşturur. Ceph RBD ile sanal makine diskleri dağıtık depolama üzerinde tutulabilir. Böylece donanım arızasında sanal makinelerin başka düğümlerde çalıştırılması kolaylaşır. Bu senaryo, Türkiye VDS Sunucu veya farklı lokasyonlardaki VDS altyapıları için planlama yapılırken değerlendirilebilir.

Yedekleme ve Arşiv Havuzu

Yedeklerin tek bir diskte tutulması, felaket kurtarma açısından risklidir. Ceph RGW ile uygulama yedekleri S3 uyumlu bir depolama alanına yazılabilir. Bu yaklaşım özellikle günlük, haftalık ve aylık yedeklerin merkezi bir havuzda saklanmasını kolaylaştırır.

Medya ve İçerik Depolama

Görsel, video ve belge gibi büyük dosyaların yönetildiği projelerde nesne depolama modeli pratik bir çözüm sunar. Uygulama sunucuları dosyaları kendi lokal diskinde tutmak yerine Ceph RGW üzerindeki bucket alanına gönderebilir. Böylece uygulama sunucusu sayısı artsa bile dosya erişim modeli merkezi kalır.

Özel Bulut Altyapısı

OpenStack veya benzeri özel bulut mimarilerinde Ceph; imaj, volume ve obje depolama katmanında kullanılabilir. Bu sayede bulut platformu üzerinde oluşturulan sanal makineler, dağıtık ve dayanıklı bir depolama altyapısından faydalanır. Daha esnek kaynak planlaması için Bulut Sunucu seçenekleri de değerlendirilebilir.

Sıkça Sorulan Sorular

Sonuç

Ceph dağıtık depolama, yüksek erişilebilirlik ve yatay ölçeklenebilirlik gerektiren modern sunucu altyapıları için güçlü bir çözümdür. RBD ile sanal makine diskleri, CephFS ile paylaşımlı dosya sistemi ve RGW ile S3 uyumlu nesne depolama sunabilmesi, Ceph’i esnek bir depolama platformu haline getirir.

Bununla birlikte Ceph doğru planlama yapılmadan kurulursa beklenen performansı ve dayanıklılığı sağlayamayabilir. Disk türü, ağ kapasitesi, düğüm sayısı, replikasyon politikası, izleme sistemi ve yedekleme stratejisi birlikte değerlendirilmelidir. Özellikle üretim ortamlarında Ceph’i tek başına bir yedekleme çözümü olarak görmek yerine, dayanıklı depolama katmanı olarak konumlandırmak daha doğru bir yaklaşımdır.

Corelux altyapı çözümleriyle sanallaştırma, bulut sunucu, kiralık sunucu ve yedekleme ihtiyaçlarınız için ölçeklenebilir bir temel oluşturabilirsiniz. Projenizin disk I/O, kapasite ve erişilebilirlik gereksinimlerine göre Kiralık Sunucu, Sanal Sunucu ve Yedekleme Hizmeti seçeneklerini değerlendirerek daha güvenilir bir depolama mimarisi planlayabilirsiniz.