Bir Ceph cluster’ında sorun çıktığında ilk soru “hangi komutu çalıştırmalıyım?” değildir. Önce cluster’ın hangi katmanda sorun yaşadığını anlamak gerekir. Bir OSD’nin down olması, PG’lerin degraded görünmesi veya recovery’nin başlaması çoğu zaman aynı olay zincirinin farklı belirtileridir.
Bu rehber, çalışan bir Ceph cluster’ında bu zinciri adım adım okumaya odaklanır. Önce health görünümünden başlayacak, ardından OSD ve Placement Group durumlarıyla sorunun kapsamını daraltacak; recovery, backfill, scrub, bakım, kapasite ve performans etkilerini aynı operasyon bağlamında ele alacağız. RADOS, CRUSH, OSD, RBD, CephFS ve RGW kavramlarına giriş için önce Ceph Nedir? RADOS, RBD, CephFS ve RGW Rehberi yazısını inceleyebilirsiniz.
Komut örnekleri güncel Ceph sürümlerindeki genel yönetim yaklaşımını göstermek içindir. Buradaki amaç komutları tek tek ezberlemek değil, bir belirtiden kök nedene giderken hangi katmana neden bakıldığını anlamaktır. Production ortamında herhangi bir flag, OSD durumu veya recovery ayarı değiştirilmeden önce cluster’ın mevcut health durumu, failure domain yapısı ve çalışan workload mutlaka birlikte değerlendirilmelidir.
Cluster genel durumu
Yerleşim ve dayanıklılık
Doluluk ve dağılım
Backfill ve rebalance
Latency / IOPS / throughput
Trend ve alarm
Bu akışı bir teşhis zinciri gibi düşünmek yararlıdır: health görünümü belirtinin nerede olduğunu gösterir; OSD ve PG katmanı etkilenen alanı daraltır; recovery, kapasite ve performans ise hem problemin hem de yapılacak müdahalenin cluster üzerindeki etkisini ortaya çıkarır. Rehber boyunca aynı sırayı takip edeceğiz.
Cluster sağlığını okumaya nereden başlanır?
Bir alarm görüldüğünde ilk iş ayar değiştirmek değil, cluster’ın ne söylediğini toplamaktır. Bunun için başlangıç noktası genellikle ceph -s veya ceph status çıktısıdır.
ceph -s
ceph health
ceph health detail
ceph -wceph -s tek ekranda MON quorum, MGR, OSD sayıları, PG durumları, kapasite ve recovery gibi temel bilgileri özetler. ceph health detail ise HEALTH_WARN veya HEALTH_ERR durumunun hangi kontrol tarafından üretildiğini anlamak için kullanılır. ceph -w cluster olaylarını ve health değişimlerini akış halinde izlemek için yararlıdır.
MON tarafında quorum durumunu ayrıca görmek gerektiğinde:
ceph mon stat
ceph quorum_statuskullanılabilir. Bir cluster’da OSD problemi görülmesi, sorunun mutlaka fiziksel diskten kaynaklandığı anlamına gelmez. Network gecikmesi, host problemi, kapasite baskısı, slow ops, PG peering veya metadata katmanı da aynı health tablosuna yansıyabilir.
Operasyon notu: HEALTH_OK cluster’ın her açıdan optimum çalıştığını garanti etmez. Aynı şekilde HEALTH_WARN görülmesi de otomatik olarak veri kaybı olduğu anlamına gelmez. Uyarının dayanıklılık, erişilebilirlik, kapasite ve performans açısından ne ifade ettiği ayrı ayrı değerlendirilmelidir.
Güncel komut davranışları için Ceph Monitoring a Cluster dokümantasyonu referans alınabilir.
OSD durumları nasıl yorumlanır?
Health çıktısı storage katmanına işaret ediyorsa bir sonraki adım OSD’lerin gerçekten erişilebilir olup olmadığını ve veri yerleşimine dahil edilip edilmediğini ayırmaktır. OSD yönetiminde en önemli ayrımlardan biri bu nedenle up/down ile in/out durumlarının aynı şeyi ifade etmemesidir.
| Durum | Ne anlatır? | Operasyon açısından anlamı |
|---|---|---|
| up | OSD daemon’u çalışıyor ve cluster ile iletişim kurabiliyor. | Servisin erişilebilir olduğunu gösterir. |
| down | OSD daemon’u erişilebilir değil veya monitor’lar tarafından down olarak değerlendirilmiştir. | Host, servis, disk veya network problemi araştırılmalıdır. |
| in | OSD veri yerleşimi için CRUSH hesaplamasına dahil edilir. | PG’ler bu OSD üzerinde veri tutabilir. |
| out | OSD veri yerleşiminin dışında tutulur. | Verinin başka OSD’lere taşınması ve recovery/backfill süreci tetiklenebilir. |
Temel inceleme komutları:
ceph osd stat
ceph osd tree
ceph osd find <OSD_ID>
ceph osd df treeceph osd tree, OSD’leri CRUSH hiyerarşisi içinde görmeyi sağlar. Böylece problemin tek bir OSD’ye mi, aynı host üzerindeki birden fazla OSD’ye mi yoksa daha geniş bir failure domain’e mi yayıldığı anlaşılabilir. ceph osd df tree ise doluluk dağılımını değerlendirirken özellikle yararlıdır.
Bir OSD’nin down olmasıyla onu hemen out yapmak aynı operasyon değildir. Kısa süreli host bakımı ile kalıcı disk arızasının cluster üzerindeki etkisi farklıdır. OSD’yi out konumuna almak veri yerleşimini değiştirebileceği için gereksiz veri hareketine ve client I/O ile yarışan recovery yüküne neden olabilir.
OSD’nin durumunu görmek tek başına yeterli değildir; asıl soru bu durumun veri yerleşimine ve erişilebilirliğe nasıl yansıdığıdır. Bu noktada Placement Group state’leri devreye girer.
Placement Group durumları ne anlatır?
Placement Group’lar, object’lerin OSD’lere yerleştirilmesinde kullanılan temel mantıksal gruplardır. Operatör açısından önemli olan yalnızca toplam PG sayısı değil, PG’lerin hangi state’lerde bulunduğudur.
| PG state | Genel anlamı | Ne zaman dikkat gerekir? |
|---|---|---|
| active | PG peering işlemini tamamlamış ve client I/O işleyebilir durumdadır. | Tek başına problem değildir. |
| clean | Object kopyaları mevcut placement politikasına uygun durumdadır. | Normal hedef durumdur. |
| degraded | İstenen veri kopyalarının veya EC shard’larının bir bölümü eksiktir. | Dayanıklılık seviyesi düşmüş olabilir; recovery nedeni araştırılmalıdır. |
| undersized | PG istenen sayıda OSD üzerinde replica/shard bulundurmuyordur. | OSD kaybı, placement kısıtı veya recovery problemi olabilir. |
| recovering | Eksik object/shard’lar yeniden oluşturuluyordur. | Uzun sürüyorsa kaynak ve failure durumu incelenmelidir. |
| backfilling | PG verisi yeni hedef OSD’lere taşınıyordur. | Disk ve network yükü client latency’yi etkileyebilir. |
| peering | OSD’ler PG’nin authoritative durumunu belirlemeye çalışıyordur. | Uzun süre devam ederse OSD availability ve PG geçmişi incelenmelidir. |
“inactive” bir PG durumu değil, ceph pg dump_stuck komutunun kategorilerinden biridir. PG’nin client read/write işleyemediği durumu tarif eder ve erişilebilirlik açısından öncelikli alarmdır.
Cluster genel PG durumunu ve belirli bir PG’nin ayrıntısını görmek için:
ceph pg stat
ceph pg dump
ceph pg <PG_ID> queryBelirli bir state’te uzun süre kalan PG’leri filtrelemek için:
ceph pg dump_stuck inactive
ceph pg dump_stuck unclean
ceph pg dump_stuck stale
ceph pg dump_stuck undersized
ceph pg dump_stuck degraded
ceph pg dump_stuck degraded 60kullanılabilir. Bir PG’nin neden active+clean olmadığını değerlendirirken yalnızca PG state’e bakmak yeterli değildir. Acting set, ilgili OSD’lerin up/in durumu, CRUSH yerleşimi, kapasite ve recovery kuyruğu birlikte incelenmelidir.
Ayrıntılı PG yönetimi için Ceph Placement Groups dokümantasyonu kullanılabilir.
Bir OSD’nin veri yerleşiminden çıkması veya PG’lerin degraded/undersized hale gelmesi, cluster’ın veriyi yeniden güvenli bir dağılıma taşımaya çalışmasına yol açabilir. Buradan sonra recovery, backfill ve rebalance kavramlarını birbirinden ayırmak gerekir.
Recovery, backfill ve rebalance arasındaki fark nedir?
Bu üç kavram günlük operasyonda sık birlikte görülür ancak aynı süreci tarif etmez.
| Süreç | Temel amaç | Yaygın tetikleyici |
|---|---|---|
| Recovery | Eksik veya geride kalmış replica/shard’ları yeniden oluşturmak. | OSD kaybı, OSD’nin geri dönmesi, veri dayanıklılığının bozulması. |
| Backfill | PG içeriğini yeni veya farklı hedef OSD’lere taşımak. | OSD’nin in/out değişimi, veri yerleşiminin değişmesi. |
| Rebalance | Cluster’ın veri dağılımını yeni CRUSH/OSD durumuna göre yeniden dengelemek. | Yeni OSD/host ekleme, weight değişikliği, topoloji değişimi. |
Bu süreçlerin ortak noktası, client workload ile aynı disk, CPU ve network kaynaklarını kullanabilmeleridir. Bu nedenle “recovery ne kadar hızlı biterse o kadar iyidir” yaklaşımı her production ortamı için doğru değildir. Hedef, veri dayanıklılığını makul sürede geri kazanırken uygulama latency’sini kontrol altında tutmaktır.
mClock notu: Güncel Ceph sürümlerinde OSD client I/O, recovery ve background işlemlerinin kaynak paylaşımında mClock scheduler kullanılır. Varsayılan balanced profil, client operasyonları ile recovery arasında dengeli davranmayı hedefler. Eski Ceph sürümlerinden kalan osd_max_backfills veya osd_recovery_max_active gibi tuning reçeteleri güncel mClock davranışı dikkate alınmadan doğrudan uygulanmamalıdır.
Bu yalnızca bir tavsiye değildir. mClock aktifken bu ayarları değiştiren komut hata vermeden başarılı görünür, ancak değer sessizce geri alınır ve cluster davranışı değişmez. Sonuç sadece OSD log’unda görülür. Ayarın gerçekten uygulanması için önce osd_mclock_override_recovery_settings seçeneğinin true yapılması gerekir; varsayılan değeri false’tur. Aksi halde operatör tuning yaptığını sanır.
Ceph dokümantasyonu da mClock altında recovery/backfill limitlerinin varsayılanlarını rastgele değiştirmemeyi ve özel ayarların ancak davranışı ölçülerek yapılmasını önerir. Güncel detaylar mClock Config Reference sayfasında yer alır.
Recovery ve backfill veri yerleşimini yeniden düzene sokar; scrub ise mevcut kopyaların gerçekten birbirleriyle tutarlı olup olmadığını kontrol eder. Bu nedenle ikisi aynı süreç değildir ama production operasyonunda birlikte düşünülmeleri gerekir.
Scrub ve deep-scrub neden önemlidir?
Ceph’te replication veya erasure coding bulunması, depolanan verinin hiçbir zaman tutarsız hale gelmeyeceği anlamına gelmez. Scrub mekanizması replica/shard’lar arasındaki tutarlılığı düzenli olarak kontrol eder.
- Scrub: Object metadata ve ilgili yapıları karşılaştırarak tutarsızlıkları tespit etmeye yardımcı olur.
- Deep-scrub: Object içeriklerini de daha ayrıntılı karşılaştırır ve data integrity kontrolünü derinleştirir.
Belirli bir PG üzerinde manuel kontrol gerektiğinde:
ceph pg scrub <PG_ID>
ceph pg deep-scrub <PG_ID>kullanılabilir. Ancak büyük cluster’larda çok sayıda scrub işlemini aynı anda zorlamak doğru yaklaşım değildir. Scrub ve deep-scrub disk I/O ve CPU tüketebilir; yoğun workload dönemleriyle çakıştığında latency üzerinde etkisi görülebilir.
Önemli olan scrub’ı kalıcı olarak kapatmak değil, çalışma pencerelerini ve cluster yükünü doğru yönetmektir. Uzun süre devre dışı bırakılan tutarlılık kontrolleri, sessiz veri sorunlarının daha geç fark edilmesine neden olabilir.
Yoğun workload, bakım veya kontrollü troubleshooting sırasında recovery, backfill ya da scrub gibi background süreçlerini geçici olarak sınırlamak gerekebilir. Cluster flag’leri tam olarak bu noktada güçlü ama dikkatli kullanılması gereken araçlara dönüşür.
Cluster flag’leri ne zaman kullanılmalı?
Ceph’in bazı OSD map flag’leri bakım veya troubleshooting sırasında belirli davranışları geçici olarak durdurmak için kullanılabilir. Bunlar güçlü operasyon araçlarıdır; “warning’i susturmak” amacıyla bırakılmamalıdır.
| Flag | Etkisi | Tipik kullanım düşüncesi |
|---|---|---|
noout | Down OSD’lerin otomatik olarak out yapılmasını engeller. | Kısa ve planlı host/OSD bakımında gereksiz veri hareketini önlemek. |
norecover | Recovery süreçlerini durdurur. | Yalnızca kontrollü, geçici operasyon durumlarında. |
nobackfill | Backfill işlemlerini durdurur. | Client workload üzerindeki geçici baskıyı yönetmek gerekebilir. |
norebalance | Rebalance hareketini durdurur. | Planlı topoloji/değişiklik süreçlerinde geçici kullanım. |
noscrub | Normal scrub işlemlerini durdurur. | Kısa süreli yoğun operasyon pencerelerinde. |
nodeep-scrub | Deep-scrub işlemlerini durdurur. | Geçici performans baskısını azaltmak için kontrollü kullanım. |
Cluster-wide flag set ve unset işlemlerinin temel biçimi şöyledir:
ceph osd set noout
ceph osd unset nooutDiğer flag’lerde de aynı yaklaşım geçerlidir.
Dikkat: norecover, nobackfill veya norebalance gibi flag’ler cluster’ın kendini toparlama süreçlerini geciktirebilir. Bakım bittikten sonra flag’lerin unutulmaması operasyon checklist’inin parçası olmalıdır.
Flag’lerin ve veri hareketinin en sık birlikte gündeme geldiği senaryolardan biri planlı host bakımıdır. Burada amaç yalnızca hostu güvenli biçimde kapatmak değil, o hostun cluster içindeki rolünü kaybettiğinde ne olacağını önceden görmek olmalıdır.
Planlı host bakımı nasıl yönetilir?
Cephadm kullanılan cluster’larda bir hostu yeniden başlatmak veya bakım için kapatmak, doğrudan işletim sistemini shutdown etmekten ibaret olmamalıdır. Önce o host üzerindeki daemon’ların durmasının veri erişilebilirliği ve servis topolojisi üzerindeki etkisi değerlendirilmelidir.
Cephadm tarafında güvenlik kontrolü için:
ceph orch host ok-to-stop <hostname>kullanılabilir. Ardından maintenance mode:
ceph orch host maintenance enter <hostname>ile başlatılabilir. Bakım bittikten sonra:
ceph orch host maintenance exit <hostname>kullanılır.
Maintenance mode host üzerindeki Ceph daemon’larını durdurur. --force ve özellikle güvenlik kontrollerini bypass eden seçenekler rutin kullanım aracı olarak görülmemelidir. MON quorum, MDS availability, OSD redundancy ve diğer servislerin host üzerindeki yerleşimi dikkate alınmalıdır.
Benzer güvenlik kontrolleri ceph osd ok-to-stop ve ceph mon ok-to-stop biçiminde de kullanılabilir.
Güncel cephadm davranışları için Ceph Host Management dokümantasyonu incelenebilir.
Host veya OSD ekleme/çıkarma gibi değişikliklerden sonra yalnızca servislerin ayağa kalkması yetmez; veri dağılımının da yeni topolojiye uyum sağlaması gerekir. Bu noktada balancer devreye girer.
Balancer ne yapar?
Cluster büyüdükçe veya veri dağılımı değiştikçe OSD kullanım oranları tam olarak eşit kalmayabilir. Ceph Manager balancer modülü PG dağılımını optimize ederek OSD’ler arasındaki dengesizliği azaltmaya yardımcı olur.
ceph balancer statusile mevcut durum görülebilir. Güncel Ceph sürümlerinde upmap balancer modu varsayılan yaklaşımdır. Upmap, PG’lerin OSD eşleşmelerine ince ayarlı istisnalar ekleyerek daha dengeli dağılım oluşturabilir.
Ancak “diskler eşit dolu görünsün” hedefi tek başına operasyon hedefi değildir. CRUSH device class, pool politikası, failure domain ve workload dağılımı korunmalıdır. Balancer’ın yaptığı veri hareketinin recovery/backfill yükü oluşturabileceği de hesaba katılmalıdır.
Detaylar için Ceph Balancer Module referansına bakılabilir.
Veri yerleşimi dengeli görünse bile performans problemi devam edebilir. Böyle bir durumda mantıksal OSD/PG durumlarından bir katman aşağı inip OSD’nin veriyi fiziksel olarak nasıl tuttuğuna bakmak gerekir.
BlueStore, RocksDB ve block.db operasyonu neden etkiler?
Bir OSD problemi her zaman yalnızca “disk yavaş” şeklinde açıklanamaz. Modern Ceph OSD’lerinde BlueStore, object verisini doğrudan block device üzerinde yönetir. OSD’nin metadata işlemlerinde RocksDB kullanılır ve bu metadata BlueStore’un block.db alanında tutulabilir.
| Bileşen | Rol | Operasyon notu |
|---|---|---|
| block | OSD’nin ana veri aygıtı. | HDD, SSD veya NVMe olabilir. |
| block.db | RocksDB metadata alanı. | Ana block aygıtından daha hızlı bir cihaz üzerinde ayrılabilir. |
| block.wal | BlueStore write-ahead log alanı. | Ayrı kullanılacaksa ana aygıttan daha hızlı bir cihaz anlamlıdır. |
Özellikle HDD tabanlı OSD’lerde hızlı SSD/NVMe üzerinde block.db kullanılması metadata yoğun workload’larda avantaj sağlayabilir. Ancak DB alanının boyutu, cihaz dayanıklılığı ve aynı hızlı cihazın kaç OSD tarafından paylaşıldığı birlikte değerlendirilmelidir.
BlueStore allocator fragmentation bazı performans problemlerinde ayrıca kontrol edilebilir. Çalışmayan bir OSD için örnek inceleme biçimi:
ceph-bluestore-tool \
--path /var/lib/ceph/osd/ceph-<ID> \
--allocator block free-scoreile allocator durumu görülebilir. Ancak free-score tek başına bir OSD’yi yeniden oluşturma kararı verdirmez. Sonuç; latency, disk health, BlueStore davranışı ve gerçek workload ile birlikte okunmalıdır.
BlueStore’un güncel cihaz ve DB/WAL davranışı için BlueStore Configuration Reference kullanılabilir.
Bu noktada soru artık yalnızca “cluster sağlıklı mı?” değildir; “neden yavaş ve gecikme hangi katmanda oluşuyor?” sorusuna dönüşür. Sağlıklı görünen bir cluster da workload açısından beklenen performansı vermeyebilir.
Performans problemi nasıl ayrıştırılır?
Ceph performansında yalnızca IOPS veya yalnızca throughput değerine bakmak çoğu zaman kök nedeni göstermez. İlk ayrım latency, IOPS ve throughput arasında yapılmalıdır:
| Metrik | Ne anlatır? | Yaygın etkileyen faktörler |
|---|---|---|
| Latency | Bir I/O işleminin ne kadar sürede tamamlandığını. | Disk gecikmesi, network, queue, recovery, CPU, replication. |
| IOPS | Birim zamanda tamamlanan I/O işlem sayısını. | I/O boyutu, media tipi, concurrency, OSD sayısı, scheduler. |
| Throughput | Birim zamanda taşınan veri miktarını. | Disk bandwidth, network bandwidth, object/I/O boyutu. |
Örneğin yüksek throughput alan bir cluster, küçük random I/O workload’unda düşük latency sağlayacağı anlamına gelmez. Benzer şekilde OSD sayısını iki katına çıkarmak her workload’da performansı doğrusal olarak iki katına çıkarmaz. Client concurrency, placement, CPU, network ve failure domain dağılımı sonucu değiştirebilir.
OSD bazındaki gecikmeleri ve kapasite dağılımını hızlıca kontrol etmek için:
ceph osd perf
ceph df
ceph osd df treeçıktıları yararlı bir ilk ayrım sağlar. Burada amaç tek bir “kötü sayı” aramak değil; diğerlerinden ayrışan OSD’leri, kapasite dengesizliklerini ve recovery gibi eş zamanlı süreçleri birlikte görmektir.
Benchmark yapılacaksa amaç “Ceph kaç GB/s yapıyor?” sorusuna tek bir evrensel sayı bulmak değil, kendi workload profilini ölçmektir. RADOS ve RBD seviyesinde benchmark araçları bu amaçla kullanılabilir; ancak production verisi bulunan pool’larda test tasarımı dikkatle yapılmalıdır.
# Örnek araçlar
rados bench ...
rbd bench ...Testlerde en az I/O boyutu, read/write tipi, concurrency, test süresi, replica/EC politikası, pool, client sayısı ve recovery durumu kaydedilmelidir. Aksi halde iki benchmark sonucu birbirleriyle anlamlı biçimde karşılaştırılamaz.
CLI size çoğunlukla o anı gösterir. Production ortamında ise birçok problem bir anda ortaya çıkmadan önce günler veya haftalar boyunca trend değişimi olarak kendini belli eder. Bu yüzden troubleshooting ile monitoring birbirinin alternatifi değil, birbirini tamamlayan iki katmandır.
Dashboard, Prometheus ve Grafana birlikte nasıl kullanılır?
CLI anlık troubleshooting için güçlüdür; uzun dönemli eğilimleri görmek için metric tabanlı monitoring gerekir. Cephadm monitoring stack tarafında Prometheus, node-exporter, Alertmanager ve Grafana gibi bileşenler cluster ve host davranışını zaman içerisinde izlemeyi sağlar.
OSD · MON · MGR · PG
Metric toplama
Trend / dashboard
Alarm yönlendirme
Operasyonda izlenebilecek başlıklardan bazıları:
- OSD up/down ve in/out değişimleri,
- PG state dağılımı,
- OSD latency ve slow ops,
- Cluster ve OSD bazında kapasite,
- Recovery/backfill hacmi,
- Network ve host kaynak kullanımı,
- MON quorum ve daemon availability,
- Scrub / deep-scrub uyarıları.
Buradaki amaç yalnızca kırmızı alarm üretmek değil, olay oluşmadan önce trend değişimini görebilmektir. Örneğin tek bir OSD’nin haftalar boyunca diğerlerinden daha hızlı dolması veya latency’sinin yavaşça yükselmesi, henüz HEALTH_WARN üretmeden önce operasyon ekibine önemli sinyal verebilir.
Cephadm monitoring stack detayları için Ceph Monitoring Services dokümantasyonuna bakılabilir.
Buraya kadar ele aldığımız health, OSD, PG, recovery, kapasite ve performans katmanları gerçek bir arıza anında ayrı ayrı değil, aynı teşhis akışının parçaları olarak karşımıza çıkar. HEALTH_WARN gördüğünüzde amaç uyarıyı susturmak değil, bu zincirde sorunun hangi noktada başladığını bulmaktır.
HEALTH_WARN görüldüğünde nasıl ilerlenmeli?
En sık yapılan hata, health warning’i “silinecek hata mesajı” gibi değerlendirmektir. Daha doğru yaklaşım, warning’in hangi katmanda oluştuğunu sistematik olarak daraltmaktır.
ceph health detail ile gerçek uyarıyı tanımlaBu akışın en önemli noktası, “önce flag koy, sonra bakarız” yaklaşımından kaçınmaktır. Örneğin degraded PG’lerin sebebi down OSD ise norecover kullanmak warning’i çözmez; tam tersine cluster’ın redundancy seviyesini geri kazanmasını geciktirebilir.
Sık yapılan operasyon hataları
HEALTH_WARNmesajını kök nedeni incelemeden mute etmek,- Kısa süreli OSD probleminde gereksiz yere OSD’yi out yapıp büyük veri hareketi başlatmak,
noout,norecover,nobackfillveya scrub flag’lerini bakım sonrasında açık unutmak,- Recovery hızını yalnızca “ne kadar hızlı biter?” üzerinden optimize edip client latency’yi izlememek,
- Eski Ceph sürümlerinden kalan recovery tuning değerlerini mClock kullanılan cluster’a doğrudan taşımak,
- PG state’i görüp ilgili OSD/CRUSH/failure domain bağlamını kontrol etmemek,
- OSD sayısının artışını otomatik ve doğrusal performans artışı gibi değerlendirmek,
- BlueStore DB/WAL yerleşimini workload’dan bağımsız tasarlamak,
- Cluster kapasitesini yalnızca toplam boş alan yüzdesi üzerinden izlemek,
- Monitoring’i sadece Dashboard’a bakmak olarak görmek ve uzun dönem metric/alerting oluşturmamak.
Production bakım checklist’i
Planlı bakım öncesi ve sonrasında basit bir checklist, birçok operasyon hatasını engeller.
| Aşama | Kontrol |
|---|---|
| Bakım öncesi | ceph -s ile cluster’ın mevcut health durumunu kaydet. |
| Bakım öncesi | OSD, PG, kapasite ve aktif recovery/backfill durumunu kontrol et. |
| Bakım öncesi | Host üzerindeki MON/MGR/MDS/RGW gibi diğer servislerin etkisini değerlendir. |
| Bakım | Cephadm kullanılıyorsa maintenance workflow ve safety check’leri kullan. |
| Bakım sonrası | Tüm geçici cluster flag’lerinin kaldırıldığını doğrula. |
| Bakım sonrası | OSD’lerin tekrar up/in olduğunu ve PG’lerin beklenen state’e döndüğünü kontrol et. |
| Bakım sonrası | Recovery bittikten sonra latency, kapasite ve alert trendlerini tekrar değerlendir. |
Ceph cluster yönetiminde temel prensipler
Ceph operasyonunda asıl değer komutu bilmekten değil, o komutun veri yerleşimi, recovery yükü ve client I/O üzerinde ne değiştireceğini öngörebilmekten gelir. Bir OSD kararı PG’leri, PG state’leri recovery’yi, recovery ise client latency ve kapasite davranışını etkileyebilir. Bu nedenle güvenli operasyonun sırası çoğu zaman aynıdır: önce gözlemle, etkisini değerlendir, sonra kontrollü değişiklik yap.
- OSD durumunu PG state’lerinden bağımsız değerlendirmeyin.
- Recovery hızını client latency ve veri dayanıklılığıyla birlikte yönetin.
- Scrub işlemlerini performans düşmanı değil, veri bütünlüğü mekanizması olarak görün.
- Cluster flag’lerini kalıcı konfigürasyon değil, kontrollü operasyon araçları olarak kullanın.
- BlueStore, network ve kapasite katmanlarını troubleshooting sırasında birlikte değerlendirin.
- Dashboard anlık görünüm, Prometheus/Grafana ise trend analizi için kullanılmalıdır.
- Production değişikliklerinden önce mevcut durumu ölçün; değişiklikten sonra aynı metrikleri tekrar karşılaştırın.
Ceph mimarisinin RADOS, CRUSH, RBD, CephFS ve RGW katmanlarını daha geniş çerçevede incelemek için Ceph Nedir? RADOS, RBD, CephFS ve RGW Rehberi yazısına dönebilirsiniz.
Kurumsal Ceph eğitimi
Ceph cluster kurulumu, RADOS ve CRUSH mimarisi, OSD ve PG yönetimi, RBD, CephFS, RGW, monitoring, performance tuning, recovery ve troubleshooting konularını uygulamalı olarak ele almak isteyen teknik ekipler için Absonet tarafından Kurumsal Red Hat Ceph Storage Eğitimi sunulmaktadır.
Kurumunuzun mevcut storage altyapısı, Kubernetes/OpenStack ortamı veya planlanan Ceph mimarisi için eğitim ve teknik çalışma ihtiyaçlarını Absonet ile iletişim üzerinden paylaşabilirsiniz.
Diğer Linux, Kubernetes, veri altyapısı ve açık kaynak içerikleri için Absonet Teknik Rehberler bölümünü inceleyebilirsiniz.
Hazırlayan: Absonet Teknik Ekibi