Ceph Benchmark Nasıl Yapılır? RADOS Bench

Ceph benchmark, depolama kümesinin yalnızca ulaşabildiği en yüksek hızı değil; farklı nesne boyutları ve eşzamanlı istek seviyeleri altında nasıl davrandığını anlamak için yapılır. Sağlıklı bir testte throughput, IOPS, gecikme, hata oranı ve kaynak kullanımı birlikte değerlendirilmelidir.

Ceph performansını ölçerken iki farklı katmanı birbirinden ayırmak gerekir. RADOS Bench, istemciden doğrudan RADOS katmanına giden yolu test eder. S3 benchmark ise load balancer, TLS, Ceph Object Gateway (RGW), kimlik doğrulama ve bucket index gibi ek bileşenleri de ölçüme dahil eder.

Ceph Benchmark Neyi Ölçer?

Ceph benchmark testleri temelde sistemin belirli bir iş yükü altındaki kapasitesini ve davranışını ölçer. Ancak tek bir test sonucuyla “Bu Ceph cluster hızlıdır” demek mümkün değildir.

Doğru bir performans değerlendirmesinde şu değerler birlikte incelenmelidir:

• Throughput: Saniyede aktarılan veri miktarıdır. Genellikle MB/s veya GB/s olarak gösterilir.
• IOPS veya object/s: Saniyede tamamlanan işlem ya da nesne sayısıdır.
• Average latency: İsteklerin ortalama tamamlanma süresidir.
• P95 ve P99 latency: İsteklerin en yavaş bölümündeki gecikmeyi gösterir.
• Hata oranı: Başarısız olan veya yeniden denenmek zorunda kalan isteklerin oranıdır.
• Kaynak kullanımı: OSD, RGW ve istemci tarafındaki CPU, bellek, disk ve ağ kullanımını kapsar.

Örneğin yüksek throughput elde edilirken P99 gecikmesi saniyeler seviyesine çıkıyorsa sistem toplu veri aktarımında hızlı olabilir; ancak gecikmeye duyarlı uygulamalar için uygun olmayabilir.

RADOS Bench ile S3 Benchmark Arasındaki Fark Nedir?

RADOS Bench ve S3 benchmark aynı Ceph kümesini test edebilir ancak aynı veri yolunu ölçmez. Bu nedenle iki aracın sonuçlarını doğrudan karşılaştırmak yerine birlikte yorumlamak gerekir.

RADOS Bench sonuçları iyi, S3 sonuçları düşükse problem doğrudan disklerde olmayabilir. RGW sayısı, load balancer yapılandırması, TLS maliyeti, bucket index, istemci kapasitesi veya S3 bağlantı ayarları darboğaz oluşturuyor olabilir.

Ceph bileşenleri ve RADOS mimarisi hakkında daha fazla bilgiye ihtiyacınız varsa önce Ceph nedir? rehberimizi inceleyebilirsiniz.

Benchmark Hedefi Nasıl Belirlenir?

Benchmark çalıştırmadan önce hangi soruya cevap aradığınızı belirleyin. Aksi durumda elde ettiğiniz rakamlar yüksek görünse bile gerçek kullanımınız açısından anlamlı olmayabilir.

Test öncesinde şu soruların cevapları net olmalıdır:

• Gerçek iş yükünde kullanılan nesne boyutları nelerdir?
• İş yükü ağırlıklı olarak yazma mı, okuma mı yapıyor?
• Aynı anda yaklaşık kaç istemci veya bağlantı çalışacak?
• Uygulama RADOS, RBD, CephFS veya S3 arabirimlerinden hangisini kullanacak?
• Öncelik toplam throughput mu, işlem sayısı mı, düşük gecikme mi?
• Test edilen pool replicated mı yoksa erasure coded mı?
• Üretimde load balancer ve TLS kullanılacak mı?

Örneğin milyonlarca küçük nesne saklayan bir S3 uygulamasını yalnızca 4 MiB nesnelerle test etmek yanıltıcıdır. Benzer şekilde yedekleme amacıyla kullanılan bir sistemi sadece 64 KiB nesnelerle ölçmek de gerçek iş yükünü temsil etmez.

Ceph Benchmark Öncesinde Cluster Nasıl Kontrol Edilir?

Benchmark öncesinde cluster sağlığını ve devam eden arka plan işlemlerini kaydedin. Recovery, backfill, degraded placement group veya yoğun scrub işlemleri sonuçları önemli ölçüde etkileyebilir.

ceph -s
ceph health detail
ceph osd stat
ceph osd perf
ceph df
ceph osd df tree

Test raporuna en azından aşağıdaki bilgileri ekleyin:

• Ceph sürümü
• Node ve OSD sayısı
• Disk türleri ve disk başına OSD yapısı
• Public ve cluster network hızları
• Pool tipi, replica sayısı veya erasure coding profili
• PG autoscaler ve CRUSH yapılandırması
• RGW instance sayısı
• Load balancer ve TLS kullanımı
• Test istemcisinin CPU, bellek ve ağ kapasitesi

BlueStore DB/WAL yerleşimi neden kaydedilmeli?

OSD’lerde kullanılan veri aygıtlarının yanı sıra BlueStore block.db ve block.wal yerleşimi de benchmark raporuna eklenmelidir. Özellikle HDD tabanlı OSD’lerde RocksDB verisinin daha hızlı bir SSD veya NVMe üzerindeki block.db alanında tutulması, metadata yoğun iş yüklerinin davranışını etkileyebilir.

Ancak block.db ve block.wal aygıtlarını genel amaçlı bir “NVMe cache” olarak tanımlamak doğru değildir. Bunlar BlueStore mimarisinin belirli veri ve metadata bileşenleridir. Ceph’in eski cache tiering özelliği ise Reef sürümünden itibaren kullanım dışı bırakılmıştır ve yeni ortamlarda önerilmemektedir. Güncel ayrıntılar için BlueStore yapılandırma dokümantasyonu incelenebilir.

Daha ayrıntılı sağlık kontrolleri ve yönetim komutları için Ceph cluster yönetimi rehberimizden yararlanabilirsiniz.

RADOS Bench Nasıl Kullanılır?

rados bench, Ceph ile birlikte gelen ve bir pool üzerinde yazma, sıralı okuma ve rastgele okuma testleri yapabilen bir araçtır. RGW, RBD ve CephFS katmanlarını devre dışı bırakarak doğrudan RADOS performansına odaklanır.

Benchmark için test pool’u oluşturma

Test verilerini üretim verilerinden ayırmak için özel bir benchmark pool’u kullanılması daha güvenlidir. Laboratuvar ortamındaki en basit oluşturma komutu şöyledir:

ceph osd pool create ceph_bench

Bu komut yalnızca temel bir örnektir. Gerçek karşılaştırmada test pool’unun replica sayısı, erasure coding profili, CRUSH rule ve diğer özellikleri hedef iş yükünde kullanılacak pool ile aynı olmalıdır. Cluster’a uygun olmayan rastgele bir PG sayısı belirlemek yerine PG autoscaler ve mevcut tasarım dikkate alınmalıdır.

Pool yapılandırmasını kontrol etmek için:

ceph osd pool get ceph_bench all
ceph osd pool stats ceph_bench

RADOS yazma testi

Aşağıdaki komut 300 saniye boyunca yazma testi gerçekleştirir. --no-cleanup seçeneği, yazılan nesneleri daha sonra yapılacak okuma testleri için pool içinde bırakır.

rados -p ceph_bench bench 300 write --no-cleanup

RADOS Bench varsayılan olarak 4 MiB nesne boyutu ve 16 eşzamanlı işlem kullanır. Bunlar aracın varsayılanlarıdır; gerçek uygulamanızın ideal test değerleri olmak zorunda değildir.

Küçük nesne testi

64 KiB nesneler, CPU tüketimi, işlem kapasitesi ve istek başına oluşan maliyetin daha görünür olmasını sağlar:

rados -p ceph_bench bench 300 write -b 65536 -t 16 --no-cleanup

Throughput odaklı test

4 MiB nesne ve daha yüksek thread sayısı, cluster’ın toplam veri aktarım kapasitesini görmek için kullanılabilir:

rados -p ceph_bench bench 300 write -b 4194304 -t 64 --no-cleanup

-b parametresi bayt cinsinden nesne boyutunu, -t ise eşzamanlı işlem sayısını belirtir. Nesne boyutu parametresi yalnızca yazma testinde kullanılır.

Sıralı okuma testi

Yazma testi --no-cleanup ile tamamlandıktan sonra aynı nesneler üzerinde sıralı okuma testi yapılabilir:

rados -p ceph_bench bench 300 seq

Sıralı okuma testinin, yazma testini gerçekleştiren aynı istemciden çalıştırılması gerekir. RADOS Bench, test nesnelerini oluştururken istemci ve çalışma bilgilerini nesne adlarında kullanır.

Rastgele okuma testi

rados -p ceph_bench bench 300 rand

Okuma testlerinden önce mutlaka write --no-cleanup çalıştırılmış olmalıdır. Aksi durumda RADOS Bench okuyabileceği test nesnelerini bulamaz.

RADOS Bench verilerini temizleme

Test tamamlandıktan sonra oluşturulan benchmark nesnelerini temizleyin:

rados -p ceph_bench cleanup

Birden fazla istemci veya farklı test çalışması kullanıyorsanız --run-name ile her çalışmaya ayrı isim vermek, test verilerinin karışmasını önler. Pool’u tamamen silmek istiyorsanız hedef cluster ve pool adını ayrıca doğrulayın; pool silme işlemi geri alınamaz.

RBD ve CephFS Performansı Nasıl Test Edilir?

RADOS Bench, temel depolama katmanını ölçse de RBD veya CephFS kullanan gerçek uygulamanın bütün veri yolunu temsil etmez. Uygulamanız block storage ya da paylaşımlı filesystem kullanıyorsa ayrıca ilgili erişim katmanında test yapılmalıdır.

rbd bench, belirli bir RBD image üzerinde read, write veya karma I/O üreterek throughput ve latency ölçebilir. Daha gerçekçi sanal makine veya uygulama testlerinde ise ayrılmış bir RBD image işletim sistemine map edildikten sonra fio kullanılabilir.

CephFS testlerinde yalnızca büyük dosya throughput değerine bakmak yeterli değildir. Dosya oluşturma, silme, stat ve dizin listeleme gibi metadata işlemleri MDS katmanını daha görünür hâle getirir.

RBD ve CephFS testlerinin ayrıntılı komutları ayrı bir rehber olacak kadar geniştir. Bu yazıda temel RADOS katmanı ile S3/RGW performansının ayrıştırılmasına odaklanıyoruz.

RADOS Bench Sonuçları Nasıl Yorumlanır?

RADOS Bench çıktısında genellikle bandwidth, IOPS, average latency, maximum latency ve latency standard deviation değerleri bulunur.

• Bandwidth: Cluster’ın saniyede aktarabildiği ortalama veri miktarıdır.
• IOPS: Saniyede tamamlanan ortalama işlem sayısıdır.
• Average latency: Bir işlemin ortalama tamamlanma süresidir.
• Maximum latency: Test sırasında görülen en yüksek gecikmedir.
• Standard deviation: Gecikmenin test boyunca ne kadar değişken olduğunu gösterir.

Ceph için her ortamda geçerli tek bir “iyi benchmark sonucu” bulunmaz. Sonuç; disk türüne, OSD sayısına, ağ hızına, replica veya erasure coding yapısına, nesne boyutuna ve istemci sayısına göre değişir.

Önemli olan yalnızca en yüksek MB/s değerini bulmak değil, concurrency arttıkça throughput ve gecikmenin nasıl değiştiğini görmektir. Throughput artık yükselmiyor fakat latency hızla artıyorsa sistem doygunluk noktasına yaklaşmış olabilir.

Object Size ve Thread Sayısı Nasıl Seçilir?

Sağlıklı bir Ceph benchmark için farklı nesne boyutları ve concurrency seviyeleri test edilmelidir. Aşağıdaki tablo başlangıç matrisi olarak kullanılabilir:

Her nesne boyutunu örneğin 1, 8, 32, 64 ve 128 concurrency seviyelerinde test edebilirsiniz. Ancak istemcinin CPU veya ağ kapasitesi doluyorsa artırılan concurrency Ceph’i değil, test istemcisini ölçmeye başlayabilir.

Ceph RGW ve S3 Benchmark Nasıl Yapılır?

Uygulama Ceph’e S3 API üzerinden bağlanacaksa RADOS Bench tek başına yeterli değildir. Gerçek istek yolunda Ceph Object Gateway, TLS, kimlik doğrulama, load balancer ve bucket index gibi ek bileşenler bulunur.

S3 performans testi için kullanılabilecek araçlardan biri açık kaynaklı MinIO Warp aracıdır. Warp; PUT, GET, STAT, DELETE ve mixed workload testleri çalıştırabilir.

Benchmark kullanıcısı oluşturma

Test için üretim kullanıcılarından ayrı ve yalnızca benchmark amacıyla kullanılacak bir RGW kullanıcısı oluşturabilirsiniz:

radosgw-admin user create \
  --uid="warp-bench" \
  --display-name="Warp Benchmark"

Komut çıktısında access key ve secret key bulunur. Bu bilgileri herkese açık terminal çıktılarında, ekran görüntülerinde veya raporlarda paylaşmayın.

Warp bağlantı bilgilerini tanımlama

export WARP_HOST="s3.example.com"
export WARP_ACCESS_KEY="<ACCESS_KEY>"
export WARP_SECRET_KEY="<SECRET_KEY>"
export WARP_TLS="true"

S3 PUT testi

Aşağıdaki örnek, 1 MiB nesneler ve 32 eşzamanlı işlemle beş dakikalık yazma testi çalıştırır:

warp put \
  --bucket=ceph-warp-bench \
  --duration=5m \
  --obj.size=1MiB \
  --concurrent=32

S3 GET testi

warp get \
  --bucket=ceph-warp-bench \
  --duration=5m \
  --obj.size=1MiB \
  --concurrent=32

Karışık S3 iş yükü testi

Gerçek uygulamalar çoğu zaman yalnızca okuma veya yalnızca yazma yapmaz. Aşağıdaki örnek GET, STAT, PUT ve DELETE işlemlerini aynı test içinde çalıştırır:

warp mixed \
  --bucket=ceph-warp-bench \
  --duration=5m \
  --obj.size=1MiB \
  --concurrent=32 \
  --get-distrib=45 \
  --stat-distrib=30 \
  --put-distrib=15 \
  --delete-distrib=10

İşlem dağılımını gerçek uygulamanızın davranışına göre değiştirmelisiniz. Örneğin arşiv sistemi yazma ağırlıklı çalışırken içerik dağıtım sistemi GET ağırlıklı olabilir.

S3 Benchmark Sırasında Hangi Testler Yapılmalı?

Kapsamlı bir S3 benchmark planında aşağıdaki senaryolar bulunmalıdır:

• Tek başına PUT performansı
• Tek başına GET performansı
• HEAD veya STAT işlemleri
• LIST işlemleri
• Nesne silme performansı
• Okuma ve yazmanın birlikte yapıldığı mixed workload
• Büyük nesneler için multipart upload
• Farklı object size değerleri
• Farklı concurrency seviyeleri
• Tek istemci ve çoklu istemci karşılaştırması

Tek bir benchmark istemcisi 10 veya 25 Gbit ağ bağlantısını dolduramıyor olabilir. Böyle bir durumda birden fazla istemci kullanarak test yapılmalıdır. Dağıtık testlerde istemcilerin saatlerinin NTP veya eşdeğer bir yöntemle senkronize olması önemlidir.

RADOS Hızlı, S3 Yavaşsa Nereye Bakılmalı?

Benchmark istemcisini kontrol edin

İstemci CPU’su, ağ kartı veya TCP bağlantı kapasitesi dolduysa test sonucu Ceph’in gerçek kapasitesini göstermez. İstemcide CPU, ağ kullanımı, retransmission ve açık bağlantı sayıları izlenmelidir.

Load balancer ve TLS katmanını kontrol edin

Load balancer üzerindeki connection limitleri, TLS termination maliyeti, timeout değerleri ve backend dağılımı S3 performansını sınırlayabilir. İsteklerin RGW instance’ları arasında dengeli dağıtılıp dağıtılmadığını kontrol edin.

RGW kaynak kullanımını inceleyin

RGW servislerinde CPU, bellek, bağlantı sayısı ve istek kuyruğu takip edilmelidir. Bir RGW instance’ı tamamen doluyken diğerlerinin düşük kullanımda olması load balancer veya bağlantı kalıcılığı kaynaklı bir dağılım sorununa işaret edebilir.

Bucket index yapısını kontrol edin

Çok fazla nesne barındıran bucket’larda bucket index shard yapısı performansı etkileyebilir. Özellikle küçük nesne ve yüksek istek sayısı bulunan ortamlarda dynamic bucket resharding durumu kontrol edilmelidir.

Benchmark Sırasında Hangi Metrikler İzlenmeli?

Benchmark aracının çıktısı tek başına yeterli değildir. Test çalışırken Ceph ve altyapı metrikleri eş zamanlı izlenmelidir.

ceph -w
ceph osd perf
ceph osd pool stats ceph_bench

Prometheus ve Grafana kullanılıyorsa şu metriklere odaklanılabilir:

• OSD apply ve commit latency değerleri
• Disk IOPS, throughput ve queue depth
• OSD ve RGW CPU kullanımı
• Node ve istemci ağ trafiği
• Paket kaybı ve TCP retransmission
• RGW PUT, GET ve diğer işlem sayıları
• RGW request latency değerleri
• Bucket ve kullanıcı bazlı istek miktarları
• Recovery, backfill ve scrub etkinliği
• Başarısız veya timeout olan S3 istekleri

Ceph’in RGW performans sayaçları, kullanıcı ve bucket seviyesinde işlem sayısı, aktarılan veri ve gecikme hakkında ek görünürlük sağlayabilir.

Tekrarlanabilir Ceph Benchmark Planı Nasıl Oluşturulur?

Benchmark sonuçlarının karşılaştırılabilir olması için her test aynı yöntemle tekrarlanmalıdır. Örnek bir çalışma planı şöyledir:

1. Cluster sağlığını ve yapılandırmasını kaydedin.
2. İstemci, ağ ve Ceph metriklerini izlemeye başlayın.
3. Yaklaşık bir dakikalık ısınma testi çalıştırın.
4. Asıl testi en az beş dakika sürdürün.
5. Aynı testi üç kez tekrarlayın.
6. Throughput, IOPS, latency ve hata oranlarını kaydedin.
7. Her seferinde yalnızca bir değişkeni değiştirin.
8. Test sonrasında cluster’ın normal duruma dönmesini bekleyin.

Uzun süreli kullanım davranışını görmek istiyorsanız kısa testlerin ardından 30 dakika veya birkaç saat süren soak testleri de çalıştırabilirsiniz. Bu testler sıcaklık artışı, cache etkisi, uzun süreli kuyruklanma ve kaynak tüketimi gibi sorunları ortaya çıkarabilir.

Ceph Benchmark Sırasında Yapılan Yaygın Hatalar

• Sadece varsayılan 4 MiB RADOS Bench sonucuna bakmak
• Gerçek iş yükünden farklı object size kullanmak
• Üretim pool’u veya üretim S3 bucket’ı üzerinde test yapmak
• Warp’ın benchmark bucket’ını temizlediğini gözden kaçırmak
• --no-cleanup kullanmadan RADOS okuma testi yapmaya çalışmak
• Replicated ve erasure coded pool sonuçlarını doğrudan karşılaştırmak
• Recovery veya backfill sırasında alınan sonucu normal performans kabul etmek
• Tek bir istemcinin tüm cluster kapasitesini kullanabileceğini varsaymak
• Yalnızca ortalama gecikmeye bakıp P95 ve P99 değerlerini görmezden gelmek
• Aynı anda birden fazla yapılandırmayı değiştirerek darboğazın kaynağını belirsizleştirmek
• RADOS Bench ve S3 benchmark sonuçlarının aynı veri yolunu ölçtüğünü düşünmek
• RBD veya CephFS performansını yalnızca RADOS Bench sonucuyla değerlendirmek

Benchmark Sonuçları Nasıl Raporlanmalı?

İyi bir benchmark raporu yalnızca en yüksek sonucu değil, test koşullarını ve sistem davranışını da göstermelidir.

Raporun sonunda şu sorular cevaplanabilmelidir:

• Hangi concurrency seviyesinde throughput artışı durdu?
• Doygunluk noktasında latency ne kadar yükseldi?
• Darboğaz istemcide mi, RGW’de mi, ağda mı yoksa OSD katmanında mı?
• Küçük ve büyük nesneler arasında nasıl bir fark oluştu?
• Test sonuçları hedeflenen uygulama performansını karşılıyor mu?

Ceph Benchmark Hakkında Sık Sorulan Sorular

RADOS Bench, Ceph RGW performansını ölçer mi?

Hayır. RADOS Bench doğrudan RADOS katmanını test eder; RGW, S3 API, TLS, load balancer ve bucket index ölçüme dahil olmaz. RGW performansı için ayrıca S3 benchmark yapılmalıdır.

RADOS Bench, RBD ve CephFS performansını ölçmek için yeterli mi?

Hayır. RADOS Bench temel storage katmanı hakkında bilgi verir ancak RBD istemcisi, sanal makine I/O yolu, CephFS, MDS ve filesystem işlemleri ölçüme dahil olmaz. RBD için rbd bench veya fio, CephFS için ise ayrılmış filesystem üzerinde uygun dosya ve metadata iş yükleri kullanılmalıdır.

İyi bir Ceph benchmark sonucu kaç MB/s olmalıdır?

Her cluster için geçerli sabit bir değer yoktur. Sonuç OSD sayısı, disk türü, ağ hızı, pool koruma yöntemi, nesne boyutu ve concurrency gibi birçok değişkene bağlıdır. En doğru karşılaştırma hedef iş yükü ve aynı koşullarda alınmış önceki ölçümlerdir.

Benchmark testi ne kadar sürmelidir?

Hızlı kontroller için birkaç dakika yeterli olabilir. Karşılaştırılabilir sonuçlar için yaklaşık bir dakikalık ısınma sonrasında en az beş dakikalık ölçüm ve üç tekrar uygulanabilir. Uzun süreli davranış için ayrıca soak testi yapılmalıdır.

Ceph benchmark üretim ortamında yapılabilir mi?

Yapılabilir ancak testin ciddi kaynak tüketebileceği unutulmamalıdır. Ayrı pool ve bucket kullanılmalı, test düşük trafik saatinde veya bakım penceresinde çalıştırılmalı ve cluster metrikleri yakından izlenmelidir.

RADOS hızlıyken S3 neden yavaş olabilir?

Çünkü S3 istek yolu daha uzundur. İstemci, DNS, load balancer, TLS, RGW, kimlik doğrulama ve bucket index gibi bileşenlerin her biri ek gecikme veya kapasite sınırı oluşturabilir.

Ceph S3 benchmark için hangi araç kullanılabilir?

MinIO Warp; PUT, GET ve mixed workload testleri için kullanılabilecek araçlardan biridir. Araç seçiminden daha önemli olan, testin gerçek object size, işlem dağılımı ve concurrency değerlerini temsil etmesidir.

Benchmark verileri test sonrasında silinmeli mi?

Evet. RADOS Bench nesneleri ve S3 test verileri işlem sonrasında temizlenmelidir. Temizlik yapmadan önce kullanılan pool ve bucket’ın yalnızca benchmark için ayrıldığından mutlaka emin olunmalıdır.

Sonuç: Ceph Performansı Tek Bir Rakamdan İbaret Değildir

Sağlıklı bir Ceph benchmark çalışması, ekranda görülen en yüksek MB/s değerini paylaşmaktan ibaret değildir. Asıl amaç sistemin hangi iş yükünde doygunluğa ulaştığını, gecikmenin ne zaman yükseldiğini ve darboğazın hangi katmanda oluştuğunu belirlemektir.

RADOS Bench ile temel depolama katmanını, S3 benchmark ile uygulamanın kullanacağı uçtan uca veri yolunu ölçebilirsiniz. RBD ve CephFS kullanan sistemler için ise ilgili istemci ve erişim katmanlarında ayrıca benchmark yapılmalıdır.

Farklı object size ve concurrency değerlerini test ederek, cluster metriklerini eş zamanlı izleyerek ve aynı senaryoyu tekrar ederek güvenilir sonuçlara ulaşabilirsiniz.

Ceph mimarisi, kurulum, kapasite planlama ve performans analizi konularında ekibinizin yetkinliğini geliştirmek isterseniz kurumsal Red Hat Ceph Storage eğitimi içeriğimizi inceleyebilirsiniz. Mevcut cluster’ınızın performans sorunlarını birlikte değerlendirmek için Absonet ile iletişime geçebilirsiniz.

Hazırlayan: Absonet Teknik Ekibi