Ceph: 1 TiB/s'ye Giden Yolculuk

Ceph: 1TiB/s'ye Giden Yolculuk

• Ceph kümesinin performans iyileştirme yolculuğunu anlatan bu yazı, uzun süren hata ayıklama ve performans optimizasyonu süreçlerinin ardından 1TiB/s veri işleme hızına ulaşma hikâyesini aktarıyor.
• Clyso adlı şirketin, NVMe tabanlı 10 petabaytlık bir Ceph kümesinin kurulmasına yardımcı olurken karşılaştığı çeşitli teknik sorunlar ve bunlara getirilen çözümler paylaşılıyor.
• Müşterinin ağı son derece hızlı ve Ethernet yapılandırmaları arasında en hızlılardan biri.

Teşekkür

• Clyso'nun müşterisine teşekkür ediliyor; onların iş birliği sayesinde deneyimlerin Ceph topluluğuyla paylaşılması mümkün olmuş.
• Karşılaştırmalı testlerde kullanılan donanımı sağlayan IBM/Red Hat ve Samsung'a da teşekkür ediliyor.
• Ayrıca Ceph'ü harika bir yazılım hâline getirmek için emek veren Ceph katkıcılarına da teşekkür iletiliyor.

Küme yapılandırması

• Müşteri 17 raf boyunca 34 adet çift soketli 2U düğüm önermiş olsa da, Clyso daha küçük düğümler kullanan çeşitli yapılandırmalar önermiş.
• Sonunda Dell mimarisi seçilerek maliyet düşürülmüş; daha hızlı bellek aktarım hızı, daha fazla CPU kaynağı ve daha yüksek ağ aktarım kapasitesi sağlanmış.
• Düğüm arızası durumunda kümenin toparlanması üzerindeki etki yarıya indirilmiş.

Test yapılandırması

• CBT kullanılarak geçici bir Ceph kümesi dağıtılmış ve FIO testleri çalıştırılmış.
• Kütüphane tabanlı FIO testleriyle küme küçük birimlere bölünmüş ve önceki sonuçlarla karşılaştırılmış.
• 3X replikasyon ve 6+2 erasure coding test edilmiş; message version 2 ise encrypted mode ve secure mode ile sınanmış.

PG sayısı hakkında uyarı

• PG sayısının performans üzerindeki etkisi deneysel olarak test edilmiş.
• Yüksek PG sayısı performansa olumlu etki yapabilse de, gerçek üretim ortamında diğer ayarlarla birlikte değerlendirilmesi gerektiği belirtiliyor.

Zor başlayan süreç

• Donanıma ilk kez giriş yapıldıktan sonra, beklenenden düşük performans nedeniyle sorun gidermek zor olmuş.
• İlk performans testleri iyi görünse de, birden çok OSD kullanılan testlerde performans düşüşü yaşanmış.

Tuhaf davranış

• Farklı OSD test kombinasyonları çalıştırılırken performansta garip örüntüler fark edilmiş.
• Sistemin çoklu OSD testlerinden sonra performansının düştüğü, ancak birkaç saat sonra yeniden toparlandığı gözlemlenmiş.

Üç çözüm

• CPU c-state geçişlerinden kaynaklanan gecikme sorunu çözülerek performans bir miktar artırılmış.
• IOMMU devre dışı bırakılarak performans önemli ölçüde yükseltilmiş.
• RocksDB derleme bayraklarıyla ilgili sorun çözülerek 4K rastgele yazma performansı iki katına çıkarılmış.

2024'ün ilk haftası

• Yeni yılın ilk gününde başka bir kümede yaşanan büyük arıza nedeniyle performans testlerine odaklanılamamış.
• Cuma günü performans testlerine yeniden başlanmış ve kümenin yüksek yük altında da iyi çalıştığı doğrulanmış.

Kaderin gülümseyişi

• Performans test sonuçları iyileştikçe, kümenin doğrusal biçimde ölçeklendiği doğrulanmış.
• 63 düğümlü bir kümede 635GiB/s veri işleme hızına ulaşılmış.

Kısmen çalışan Ölüm Yıldızı

• Yeterli istemci düğümü olmadığı için OSD düğümleri ile FIO süreçlerinin paylaşılması gerekmiş.
• Buna rağmen 950GiB/s'ye yakın performans elde edilmiş.

1TiB/s'ye ulaşmak

• OSD shard sayısı ve messenger thread sayısı ayarlanarak 1TiB/s veri işleme hızına ulaşılmış.

Uyku; erasure coding

• 3X replikasyon ile test yapıldıktan sonra, müşterinin kullanacağı 6+2 erasure coding ile küme yeniden yapılandırılarak test edilmiş.
• Okuma performansı 500GiB/s'nin üzerine çıkarken, yazma performansı neredeyse 400GiB/s'ye ulaşmış.

GN⁺ görüşü:

1. Bu yazı, Ceph kümesinde performans optimizasyonu sürecini ayrıntılı biçimde anlatarak, karmaşık sorun çözme süreçleri üzerinden yüksek performansa ulaşılmış somut bir örnek sunuyor ve teknik içgörü sağlıyor.
2. Müşteriyle iş birliğinin, topluluk katkıcılarının emeğinin ve çeşitli donanım ile yazılım optimizasyon stratejilerinin gerçek dünyada nasıl büyük sonuçlar doğurabildiğini gösteriyor.
3. Bu yazı, yalnızca büyük ölçekli veri depolama sistemleriyle çalışan uzmanlara değil, performans optimizasyonuna ilgi duyan mühendislere de faydalı bilgiler sunuyor.

[GN⁺]

Hacker News görüşleri

• CERN'in 1TB/s'ye ulaşma haberi ve Ceph'in geçmişi
  • Bir kullanıcı, CERN'in EOS kümesi üzerinden 1TB/s hıza ulaştığını belirtirken, bu kümenin ağırlıklı olarak HDD kullandığını ve daha fazla düğüme sahip olduğunu açıklıyor. Ayrıca, Ceph'in Dreamhost'ta şirket içi ihtiyaçlar nedeniyle ortaya çıktığını ve daha sonra Redhat tarafından satın alındığını anlatan ilginç geçmişini paylaşıyor.
• Geçmişte teknik lider olarak edinilen deneyim ve Ceph'e duyulan sempati
  • Bir kullanıcı, Cisco'da teknik lider olarak çalışırken Kubernetes'i bare metal üzerinde kurduğunu ve GlusterFS ile Ceph'i denediğini hatırlatarak bu tür denemelerden keyif aldığını söylüyor. Ayrıca, yazının iyi kaleme alınmış olduğunu belirterek övgüde bulunuyor.
• Düğüm boyutunun küçültülmesine yönelik öneri
  • Bir kullanıcı, mevcut sistemde düğüm başına enerji tüketiminin yüksek olduğuna dikkat çekerek düğüm boyutunu küçültmeye yönelik mühendislik çalışmaları gerektiğini öneriyor. Bunun sayesinde daha az düğümün yeterli olabileceğini ve tek bir arızanın 10 diski etkilemesi riskinin azaltılabileceğini savunuyor.
• Dijital veri depolama miktarına tarihsel bir bakış
  • Bir kullanıcı, son 60 yıl içinde dünyada ilk kez 1TiB dijital verinin depolandığı bir gün mutlaka yaşanmış olması gerektiğini söylerken, bugün artık bu miktarda verinin her saniye taşınabiliyor olmasına şaşırdığını ifade ediyor.
• Ceph kümesiyle Docker cache performansını artırma deneyimi
  • Bir kullanıcı, Docker katman cache'ini korumak için bir Ceph depolama kümesi işlettiğini ve EBS'den Ceph'e geçtikten sonra throughput'un büyük ölçüde arttığını paylaşıyor. Bu kullanıcı ayrıca Ceph'in neredeyse hiç bakım gerektirmediğini söylüyor.
• Kubernetes içindeki depolama denetleyicisi yazılımı sorunları
  • Bir kullanıcı, Kubernetes içinde dinamik depolamayla ilgili en büyük sorunun I/O değil, depolama denetleyicisi yazılımının gerçek sorunlarla karşılaştığında ortaya çıktığını belirtiyor. Özellikle rook/ceph ve Longhorn kullanırken PVC'nin ancak uzun bir süre sonra bağlanması sorununu yaşadığını aktarıyor.
• Donanımın teorik sınırlarına kıyasla 1 TiB/s performans analizi
  • Bir kullanıcı, 1 TiB/s performansının donanımın teorik sınırlarıyla nasıl karşılaştırıldığını analiz ediyor ve ağın darboğaz oluşturduğunu belirtiyor. Ayrıca, Ceph'in karmaşıklığının CPU üzerinde kayda değer bir yük oluşturduğunu ve OSD threading modelinin optimize edilmediği sonucuna vararak iyileştirme umduğunu söylüyor.
• Ceph ile diğer object storage engine'leri arasında karşılaştırma talebi
  • Bir kullanıcı, Ceph'in MinIO, Garage gibi diğer object storage engine'leriyle karşılaştırıldığı benchmark'ları görmek istediğini söylüyor.
• Ceph'in işlemsel veritabanı depolamasına uygunluğu ve IO gecikmesine dair soru
  • Bir kullanıcı, Ceph'in işlemsel veritabanı depolaması için uygun olup olmadığını ve IO gecikmesinin nasıl olduğunu sorarken, Oracle'ın cluster file system'i veya Veritas gibi sistemlerle rekabet edebilecek daha ucuz bir dosya sistemine geçmek istediğini belirtiyor.