Ceph Nedir? RADOS, RBD, CephFS ve

Ceph; birden fazla sunucu ve depolama aygıtını tek bir dağıtık depolama sistemi olarak çalıştırabilen açık kaynaklı bir Software-Defined Storage (SDS) platformudur. Aynı cluster üzerinden block storage (RBD), file storage (CephFS) ve S3 uyumlu object storage (RGW) sunabilir. Ceph’in temelinde RADOS bulunur; verinin cluster içerisinde hangi OSD’lere yerleştirileceği ise CRUSH algoritması kullanılarak hesaplanır.

Bu mimari sayesinde Ceph, tek bir storage controller’a bağımlı olmadan kapasiteyi ve veriyi birden fazla node üzerine dağıtabilir; disk veya node arızalarında eksik veri kopyalarının yeniden oluşturulmasına imkân verir ve cluster topolojisi değiştiğinde veri dağılımını yeniden dengeleyebilir.

Ceph özellikle sanallaştırma, özel bulut, Kubernetes, OpenStack, object storage ve büyük ölçekli veri merkezi altyapılarında ölçeklenebilir depolama katmanı oluşturmak için kullanılan dağıtık bir storage çözümüdür.

Ceph Storage Nedir?

Ceph, depolama kapasitesini tek bir fiziksel storage cihazına veya merkezi bir controller’a bağımlı olmadan birden fazla sunucu ve disk üzerine dağıtan açık kaynaklı bir depolama platformudur.

Ceph’in önemli özelliklerinden biri, aynı storage cluster üzerinden farklı depolama servislerinin birlikte sunulabilmesidir:

• RBD (RADOS Block Device) ile block storage,
• CephFS ile POSIX uyumlu dağıtık file storage,
• RGW (RADOS Gateway) ile S3 ve Swift uyumlu object storage.

Bu nedenle Ceph’i yalnızca “dağıtık disk sistemi” olarak tanımlamak eksik kalır. Ceph; storage donanımını, veri yerleşimini, veri dayanıklılığını, failure domain yapısını ve istemci erişimini tek bir dağıtık mimari altında yöneten kapsamlı bir storage platformudur.

Proje hakkında genel bilgiye Ceph’in resmî teknoloji sayfasından, mimari ayrıntılara ise resmî Ceph mimari dokümantasyonundan ulaşılabilir.

Ceph Ne İşe Yarar ve Kullanım Alanları Nelerdir?

Ceph’in temel amacı, çok sayıda disk ve sunucudan oluşan depolama kaynaklarını tek bir ölçeklenebilir storage cluster olarak kullanabilmektir.

Yaygın kullanım alanları arasında şunlar bulunur:

• Sanal makineler için block storage sağlanması,
• OpenStack altyapılarında storage backend olarak kullanılması,
• Kubernetes ortamlarında persistent storage sağlanması,
• S3 uyumlu kurum içi object storage altyapısı oluşturulması,
• Birden fazla istemcinin erişebildiği dağıtık dosya sistemi kurulması,
• Özel bulut ve veri merkezi altyapılarında ölçeklenebilir storage katmanı oluşturulması,
• Yüksek kapasite gerektiren veri işleme, arşiv ve benzeri storage iş yüklerinin desteklenmesi.

Ceph’in doğru tercih olup olmadığı yalnızca ihtiyaç duyulan terabayt veya petabayt miktarına bakılarak belirlenmemelidir. IOPS, throughput, latency, veri dayanıklılığı, erişilebilirlik, büyüme beklentisi ve kurumun operasyon kapasitesi birlikte değerlendirilmelidir.

Ceph Nasıl Çalışır? Mimariye Genel Bakış

Ceph mimarisinin temelinde RADOS – Reliable Autonomic Distributed Object Store bulunur.

RBD, CephFS ve RGW farklı erişim yöntemleri sağlasa da temel veri katmanı RADOS’tur.

Uygulamalar / Sanal Makineler / Kubernetes
                    |
          +---------+---------+
          |         |         |
         RBD      CephFS      RGW
          |         |         |
          +---------+---------+
                    |
                  RADOS
                    |
             Placement Groups
                    |
                  CRUSH
                    |
                 OSD'ler
                    |
                 Diskler

Bir Ceph client, güncel cluster map bilgisini Monitor servislerinden alır. Client ve OSD daemon’ları CRUSH algoritmasını kullanarak bir object’in hangi OSD’lerde bulunması gerektiğini hesaplayabilir.

Bu yaklaşımın önemli sonucu, her I/O işleminin merkezi bir storage controller veya merkezi object-location tablosu üzerinden geçirilmesinin gerekmemesidir.

Ceph Mimarisi ve Temel Bileşenleri Nelerdir?

Burada önemli bir ayrıntı vardır: OSD yalnızca fiziksel diskin adı değildir. Ceph OSD daemon’u verinin storage üzerinde saklanmasının yanı sıra read/write, replication, recovery ve cluster içi veri yönetimi süreçlerinin aktif bir parçasıdır.

RADOS Nedir?

RADOS, Ceph Storage Cluster’ın temel dağıtık object storage katmanıdır.

Ceph’e yazılan veri RADOS içerisinde object’ler halinde saklanır. Bu object’ler doğrudan belirli fiziksel disk isimlerine sabitlenmez. Veri önce pool ve Placement Group yapısıyla ilişkilendirilir, ardından CRUSH kullanılarak uygun OSD’lere eşlenir.

Bu soyutlama sayesinde cluster’a yeni disk veya yeni storage node eklendiğinde veri yerleşimi değişen cluster topolojisine göre yeniden hesaplanabilir.

CRUSH Algoritması Nedir?

CRUSH – Controlled Replication Under Scalable Hashing, Ceph’in object’lerin hangi OSD’lerde bulunacağını hesaplamak için kullandığı veri yerleşim algoritmasıdır.

Ceph client’ları ve OSD daemon’ları merkezi bir object-location tablosuna bağımlı olmak yerine CRUSH ve cluster map bilgisini kullanarak verinin konumunu hesaplayabilir.

CRUSH aynı zamanda fiziksel altyapının failure domain yapısının tanımlanmasına imkân verir.

Örneğin:

datacenter
  |
  +-- rack-01
  |     |
  |     +-- host-01
  |     +-- host-02
  |
  +-- rack-02
        |
        +-- host-03
        +-- host-04

Bir veri koruma politikası yalnızca farklı diskleri değil; farklı host, rack veya daha üst failure domain’leri hedefleyecek şekilde tasarlanabilir.

Bu nokta production Ceph tasarımında kritiktir. Üç veri kopyası oluşturmak tek başına yeterli değildir. Kopyaların hangi fiziksel failure domain’ler arasında dağıtıldığı da veri dayanıklılığının bir parçasıdır.

Placement Group (PG) Nedir?

Ceph, object’leri doğrudan sabit bir OSD listesine bağlamak yerine Placement Group (PG) adı verilen mantıksal gruplar üzerinden OSD’lere eşler.

Object
   |
   v
Pool
   |
   v
Placement Group
   |
   v
CRUSH
   |
   v
OSD'ler

Placement Group katmanı, object’ler ile fiziksel OSD’ler arasında bir soyutlama sağlar.

Cluster büyüdüğünde, küçüldüğünde veya OSD durumları değiştiğinde Ceph, yeni cluster map ve CRUSH hesaplamalarına göre veri dağılımını yeniden düzenleyebilir.

Modern Ceph sürümlerindeki PG autoscaler, uygun Placement Group sayısının yönetilmesini kolaylaştırır. Buna rağmen pool tasarımı, cluster büyüklüğü ve veri dağılımı birlikte değerlendirilmelidir.

RBD, CephFS ve RGW Arasındaki Farklar Nelerdir?

Ceph mimarisiyle ilk kez çalışan teknik ekiplerin en sık karıştırdığı konulardan biri RBD, CephFS ve RGW servislerinin hangi kullanım senaryolarına karşılık geldiğidir.

RBD (RADOS Block Device) Nedir?

RBD – RADOS Block Device, Ceph üzerinde block device sunmak için kullanılan storage servisidir.

Ceph block device’ları thin-provisioned ve yeniden boyutlandırılabilir yapıdadır. RBD; snapshot, cloning ve mirroring gibi gelişmiş block storage özelliklerini de destekler.

Sanal makine diskleri, OpenStack ve benzeri platformların block storage ihtiyaçları RBD’nin yaygın kullanım alanları arasındadır.

CephFS (Ceph File System) Nedir?

CephFS, RADOS üzerinde çalışan POSIX uyumlu dağıtık dosya sistemidir.

Birden fazla istemcinin aynı filesystem alanına erişmesi gereken senaryolarda kullanılabilir.

CephFS’te filesystem metadata’sı RADOS üzerinde tutulur ve Metadata Server (MDS) servisleri tarafından yönetilir. Dosya verisi de RADOS üzerinde saklanır.

RGW (RADOS Gateway) Nedir?

RADOS Gateway – RGW, Ceph Storage Cluster üzerinde object storage erişimi sağlayan servistir.

RGW, Amazon S3 ve OpenStack Swift ile uyumlu API arabirimleri sağlayabilir.

Bu nedenle bir kurum kendi veri merkezinde S3 uyumlu object storage altyapısı oluşturmak istediğinde Ceph RGW değerlendirilebilecek seçeneklerden biridir.

Ceph’te Veri Dayanıklılığı Nasıl Sağlanır?

Ceph’te disk veya host arızalarına karşı veri dayanıklılığı temel olarak replication veya erasure coding yöntemleri kullanılarak sağlanabilir.

Replication

Replicated pool’larda aynı object’in birden fazla kopyası, CRUSH kurallarına uygun OSD’ler üzerinde tutulur.

Örneğin replica size değeri 3 olan bir pool’da object’in üç kopyasının bulunması hedeflenir.

Replication operasyonel olarak anlaşılması görece kolay bir yöntemdir; ancak üç kopyalı bir yapı doğal olarak önemli miktarda raw storage kapasitesi kullanır.

Erasure Coding

Erasure Coding kullanımında veri, data chunk ve coding chunk parçalarına ayrılır.

Erasure coding profilinde k data chunk sayısını, m ise coding chunk sayısını belirler. Örneğin k=4, m=2 profilinde bir object toplam altı chunk’a dağıtılır. Uygun CRUSH ve failure domain tasarımı altında iki chunk’ın kaybına kadar veri kalan chunk’lar kullanılarak yeniden oluşturulabilir.

Erasure coding özellikle büyük ölçeklerde replication’a göre daha yüksek kapasite verimliliği sağlayabilir. Bunun karşılığında coding işlemleri, recovery davranışı, CPU kullanımı ve I/O karakteri açısından farklı operasyonel maliyetler ortaya çıkar.

Bu nedenle “erasure coding daha az disk kullanır, o halde bütün pool’lar EC olmalıdır” yaklaşımı doğru değildir. Veri koruma yöntemi workload’a göre tasarlanmalıdır.

Ceph Bir Backup (Yedekleme) Sistemi midir?

Hayır. Ceph’in replication veya erasure coding mekanizmaları bağımsız bir backup politikasının yerine geçmez.

Replication ve erasure coding, belirli donanım arızalarına karşı veri dayanıklılığı sağlar. Ancak kullanıcı tarafından silinen veri, uygulama tarafından bozulan içerik veya hatalı çalışan bir otomasyon storage sistemi içindeki diğer veri kopyalarını da etkileyebilir.

Ceph üzerinde tutulan kritik veriler için kurumun RPO ve RTO hedeflerine uygun bağımsız backup ve gerektiğinde disaster recovery politikaları ayrıca tasarlanmalıdır.

Bir OSD veya Disk Arızalandığında Ceph Nasıl Tepki Verir?

Bir OSD erişilemez hale geldiğinde ilgili Placement Group’ların durumu değişebilir ve Ceph cluster health uyarıları oluşabilir.

Cluster konfigürasyonuna, arızanın süresine ve mevcut veri kopyalarına bağlı olarak Ceph eksik veri parçalarını diğer OSD’ler üzerinde yeniden oluşturmaya başlayabilir.

Bu süreçlerde sık karşılaşılan üç kavram vardır:

• Recovery: Eksik veya güncel olmayan veri parçalarının yeniden oluşturulması,
• Backfill: Veri parçalarının hedef OSD’lere aktarılması,
• Rebalancing: Cluster topolojisi değiştiğinde veri dağılımının yeniden dengelenmesi.

Bu işlemler çalışan client workload’larıyla aynı disk, CPU ve network kaynaklarını kullanabilir.

Bu nedenle production Ceph tasarımında yalnızca cluster’ın normal çalışma performansı değil, arıza ve recovery sırasında göstereceği davranış da hesaba katılmalıdır.

Ceph Kapasitesi Nasıl Hesaplanır? Raw ve Usable Capacity

Ceph tasarımında sık yapılan hatalardan biri bütün disk kapasitelerini toplayıp bu değeri doğrudan kullanılabilir kapasite olarak değerlendirmektir.

Basit bir örnek:

10 disk × 10 TB = 100 TB raw kapasite

Bu değer yalnızca fiziksel disklerin toplam kapasitesini ifade eder.

Eğer replicated bir pool size=3 ile çalışıyorsa yalnızca üç kopyalı replication overhead’i dikkate alındığında teorik logical kapasite yaklaşık:

100 TB / 3 ≈ 33,3 TB

olur.

Ancak bu değer production ortamında “33,3 TB’ın tamamını güvenli şekilde doldurabiliriz” anlamına gelmez.

Gerçek kapasite planlamasında ayrıca:

• Recovery ve rebalancing için bırakılacak boş kapasite,
• Cluster doluluk ve güvenlik eşikleri,
• Replication veya erasure coding politikası,
• Failure domain yapısı,
• Pool ve metadata kullanımı,
• Tasarıma göre BlueStore DB/WAL için ayrılan kapasite,
• TB ve TiB gösterimleri arasındaki fark

birlikte değerlendirilmelidir.

Özetle Ceph’te raw capacity ile usable capacity aynı şey değildir.

Ceph Altyapısında Network Neden Önemlidir?

Dağıtık storage sisteminde network, storage mimarisinin dışında kalan yardımcı bir bileşen değildir. Doğrudan veri yolunun bir parçasıdır.

Client I/O trafiği, OSD’ler arası replication, recovery ve backfill işlemleri network kaynaklarını kullanır.

Bu nedenle hızlı SSD veya NVMe disklerden oluşan bir Ceph cluster’ın network kapasitesi yetersizse storage aygıtlarının sağlayabileceği performanstan tam olarak yararlanılamayabilir.

Ceph’in güncel donanım önerileri veri merkezinde en az 10 Gb/s networking tavsiye eder; önemli workload’larda 25 Gb/s, yoğun storage node’larında ise daha yüksek bağlantı hızları gerekebilir.

Network tasarımında yalnızca port hızına değil;

• Switch kapasitesine,
• Oversubscription oranlarına,
• Latency değerlerine,
• Network yedekliliğine,
• Rack topolojisine,
• Failure domain tasarımına,
• Recovery ve backfill sırasında oluşabilecek ek trafiğe

de bakılmalıdır.

Donanım ve network planlamasıyla ilgili güncel öneriler Ceph Hardware Recommendations dokümantasyonunda incelenebilir.

Ceph İçin Her Disk Uygun mudur?

Ceph farklı storage aygıtları üzerinde çalışabilir. Ancak production ortamında disk seçimi yalnızca kapasite ve birim fiyat üzerinden yapılmamalıdır.

Değerlendirilmesi gereken başlıklardan bazıları şunlardır:

• HDD, SATA SSD veya NVMe kullanım amacı,
• Beklenen IOPS ve latency,
• SSD endurance değerleri,
• Power Loss Protection desteği,
• BlueStore DB/WAL yerleşimi,
• Disk başına kapasite,
• Recovery sırasında oluşacak I/O yükü,
• Disk arızası sonrasında yeniden oluşturulması gereken veri miktarı.

Özellikle yüksek hızlı storage sistemlerinde yalnızca sıralı MB/s değerleri üzerinden donanım seçmek yanıltıcı olabilir.

Ceph ile RAID Arasındaki Fark Nedir?

RAID ve Ceph, veri dayanıklılığıyla ilgili bazı benzer ihtiyaçlara dokunsa da aynı seviyede çalışan teknolojiler değildir.

RAID çoğunlukla tek bir sunucu veya storage enclosure içerisindeki disk grubunu yönetir.

Ceph ise veri yerleşimini birden fazla disk, host ve gerektiğinde rack gibi daha geniş failure domain’ler arasında yönetebilen dağıtık bir storage platformudur.

Bu nedenle “Ceph mi RAID mi?” sorusu çoğu projede iki eşdeğer ürünün doğrudan karşılaştırılması değildir.

Ceph ve Kubernetes Birlikte Kullanılabilir mi?

Evet. Ceph, Kubernetes workload’larına persistent storage sağlamak için kullanılabilir.

Kullanım senaryosuna göre:

• RBD, block storage gerektiren workload’larda,
• CephFS, birden fazla Pod’un ortak bir filesystem’e erişmesi gereken senaryolarda

tercih edilebilir.

Ceph block device’ları, ceph-csi kullanılarak Kubernetes Persistent Volume’larının arkasında dinamik olarak sağlanabilir. Konuyla ilgili güncel örnekler Ceph’in resmî Kubernetes entegrasyonu dokümantasyonunda yer almaktadır.

Ceph ve OpenStack Birlikte Kullanılabilir mi?

Ceph, OpenStack altyapılarında yaygın olarak kullanılan storage seçeneklerinden biridir.

RBD; sanal makine diskleri, image storage ve block storage gibi ihtiyaçlarda OpenStack servisleriyle entegre edilebilir.

Bu entegrasyon, compute platformlarının dağıtık Ceph Storage Cluster üzerinde block storage kullanabilmesine imkân verir.

Ceph Hangi Durumlarda Mantıklıdır?

Ceph özellikle aşağıdaki durumlarda güçlü bir adaydır:

• Storage kapasitesinin zaman içinde büyümesi bekleniyorsa,
• Tek bir storage controller’a bağımlılığın azaltılması isteniyorsa,
• Block, file ve object storage ihtiyaçlarının aynı platform altında karşılanması gerekiyorsa,
• Kubernetes, OpenStack veya özel bulut altyapısı kuruluyorsa,
• Disk ve node arızalarının dağıtık mimari içerisinde karşılanması isteniyorsa,
• Storage altyapısının yatay olarak büyütülmesi gerekiyorsa.

Ceph Hangi Durumlarda Gereksiz Olabilir?

Ceph güçlü bir storage platformudur ancak her depolama problemi için doğru çözüm değildir.

Örneğin:

• Küçük bir ortamda yalnızca basit bir shared filesystem gerekiyorsa,
• Yatay büyüme ihtiyacı bulunmuyorsa,
• Dağıtık storage’ın sağladığı özelliklere ihtiyaç yoksa,
• Cluster’ı yönetecek Linux ve storage operasyon yetkinliği bulunmuyorsa,
• Operasyonel karmaşıklığın sağlayacağı teknik faydadan daha yüksek olduğu küçük altyapılarda

daha basit storage çözümleri teknik ve ekonomik olarak daha uygun olabilir.

Ceph kullanmanın amacı “dağıtık olduğu için Ceph kullanmak” değil, dağıtık storage mimarisinin çözdüğü problemlere gerçekten ihtiyaç duyulan durumda doğru sistemi tasarlamaktır.

Ceph Kurulumunda Sık Yapılan Hatalar

Ceph cluster kurmak ile birkaç yıl sonra da sağlıklı çalışabilecek production Ceph altyapısını tasarlamak aynı şey değildir.

Sık karşılaşılan hatalar arasında:

• Raw kapasiteyi usable kapasite olarak kabul etmek,
• Failure domain tasarımını cluster kurulduktan sonra düşünmek,
• Network kapasitesini yalnızca normal client I/O yüküne göre planlamak,
• Recovery ve backfill trafiğini hesaba katmamak,
• Disk seçiminde yalnızca kapasite ve sıralı throughput değerine bakmak,
• Workload belirlenmeden RBD, CephFS veya RGW kararı vermek,
• OSD sayısındaki artışın her durumda doğrusal performans artışı sağlayacağını varsaymak,
• Cluster’ı sürekli yüksek doluluk seviyelerinde çalıştırmak,
• Monitoring ve alarm tasarımını kurulum sonrasına bırakmak,
• Replication’ı backup olarak değerlendirmek.

Ceph Cluster Sağlığı Nasıl Kontrol Edilir?

Bir Ceph cluster’ın genel durumunu görmek için ilk kullanılabilecek komutlardan biri:

ceph -s

veya:

ceph status

Health uyarılarının ayrıntısını görmek için:

ceph health detail

OSD durumlarını incelemek için:

ceph osd status
ceph osd tree

Placement Group durumlarının özetini görmek için:

ceph pg stat

Bu komutların çıktıları tek başına her problemin kök nedenini göstermez. Ancak troubleshooting sırasında cluster’ın mevcut durumunu anlamak için ilk resmi sağlar.

Örneğin HEALTH_WARN görüldüğünde amaç yalnızca warning’i ortadan kaldırmak değil, uyarının veri dayanıklılığı, kapasite veya performans açısından ne anlattığını belirlemektir.

Ceph Performansını Belirleyen Faktörler Nelerdir?

Ceph performansını tek bir donanım bileşeni veya tek bir konfigürasyon parametresi belirlemez.

Başlıca değişkenler arasında:

• Disk tipi ve disk başına IOPS,
• OSD sayısı ve OSD dağılımı,
• CPU kapasitesi,
• BlueStore DB/WAL yerleşimi,
• Network bandwidth ve latency,
• Replication veya erasure coding politikası,
• Object ve I/O boyutu,
• RBD, CephFS veya RGW workload karakteri,
• Client concurrency,
• Recovery ve backfill işlemleri,
• Cluster doluluk oranı

bulunur.

Bu nedenle başka bir Ceph cluster üzerinde alınmış benchmark sonucunu kendi altyapınız için doğrudan performans hedefi olarak kullanmak doğru değildir.

Ceph Hakkında Sık Sorulan Sorular

Ceph açık kaynak mı?

Evet. Ceph açık kaynaklı bir dağıtık storage platformudur. Projenin resmî sitesi ceph.io adresindedir.

Ceph ücretsiz mi?

Upstream Ceph yazılımı açık kaynaklıdır. Ancak production Ceph altyapısının toplam maliyetinde sunucular, diskler, network, enerji, veri merkezi kaynakları, monitoring ve operasyonel uzmanlık birlikte değerlendirilmelidir.

Ceph object storage mı?

Ceph yalnızca object storage değildir. Aynı RADOS altyapısı üzerinde RBD ile block storage, CephFS ile file storage ve RGW ile object storage sağlayabilir.

Ceph S3 destekliyor mu?

Evet. Ceph Object Gateway – RGW, Amazon S3 uyumlu object storage API erişimi sağlayabilir.

Ceph SAN yerine kullanılabilir mi?

Bazı sanallaştırma ve block storage projelerinde Ceph RBD geleneksel SAN çözümlerine alternatif olarak değerlendirilebilir. Ancak latency, performans, uygulama uyumluluğu, operasyonel gereksinimler ve büyüme beklentileri incelenmeden birebir ürün değişimi olarak ele alınmamalıdır.

Ceph Kubernetes ile çalışır mı?

Evet. Kubernetes ortamlarında Ceph RBD ve CephFS üzerinden persistent storage sağlanabilir. RBD tarafında ceph-csi ile dinamik Persistent Volume provisioning uygulanabilir.

Ceph backup yerine geçer mi?

Hayır. Replication ve erasure coding donanım arızalarına karşı veri dayanıklılığı sağlar ancak bağımsız bir backup politikasının yerine geçmez.

Ceph öğrenmek zor mudur?

Temel Ceph kurulumu ve yönetim komutları görece kısa sürede öğrenilebilir. Production seviyesinde Ceph yönetiminde ise RADOS, CRUSH, Placement Group, failure domain, recovery, kapasite ve performans ilişkilerinin birlikte anlaşılması gerekir.

Ceph Öğrenmeye Nereden Başlanmalı?

Ceph öğrenirken doğrudan komut ezberlemek yerine önce storage mimarisini anlamak daha sağlıklı bir yaklaşımdır.

Önerilen öğrenme sırası:

1. RADOS mimarisi,
2. OSD, MON ve MGR görevleri,
3. Pool ve Placement Group mantığı,
4. CRUSH ve failure domain tasarımı,
5. Replication ve erasure coding,
6. RBD, CephFS ve RGW servisleri,
7. Cluster deployment ve yönetim,
8. Monitoring ve health durumları,
9. Recovery ve troubleshooting,
10. Performans ve kapasite planlama.

Komutların nasıl çalıştığını bilmek başlangıçtır. Production Ceph yönetiminde asıl önemli olan, yapılan değişikliğin veri yerleşimi, recovery yükü, failure domain ve çalışan client’lar üzerindeki etkisini öngörebilmektir.

Kurumsal Ceph Eğitimi

Ceph mimarisini yalnızca teorik olarak değil; cluster kurulumu, RADOS, CRUSH, OSD yönetimi, RBD, CephFS, RGW, monitoring, performance tuning ve troubleshooting çalışmalarıyla uygulamalı olarak ele almak isteyen teknik ekipler için Absonet tarafından Kurumsal Red Hat Ceph Storage Eğitimi sunulmaktadır.

Eğitim içeriğinde Ceph mimarisi; production ortamlarında karşılaşılabilecek kapasite planlama, failure domain, rebalancing, recovery, block/object/file storage ve performans senaryolarıyla birlikte ele alınmaktadır.

Kurumunuzun mevcut storage mimarisi, Kubernetes/OpenStack altyapısı veya planlanan Ceph projesine göre eğitim içeriğinin uyarlanması için Absonet ile iletişime geçebilirsiniz.