Ceph: 1 TiB/s’ye Yolculuk

 (ceph.io)
4 puan yazan GN⁺ 2024-01-21 | 1 yorum | WhatsApp'ta paylaş
  • Clyso, HDD tabanlı Ceph kümesini 10PB NVMe dağıtımına dönüştürmeden önce burn-in testi yaptı ve 630 OSD’lik tek bir kümede 1,0 TiB/s okuma elde etti
  • Nihai donanım 68 Dell PowerEdge R6615 ve düğüm başına 10 NVMe yapılandırmasıydı; ancak en yüksek performans testi, kullanılabilir durumdaki 63 makine ve 630 OSD ile yapıldı
  • İlk darboğazlar BIOS CPU c-state, çekirdek IOMMU eşleme çekişmesi ve upstream Ceph Ubuntu Deb paketindeki RocksDB derleme bayrağı sorunları düzeltilerek giderildi; compaction süresi yaklaşık 3 kat azaldı ve 4KB rastgele yazma 2 kat iyileşti
  • 3X çoğaltma yapılandırmasındaki zirve değerler 4MB okumada 1025GiB/s, 4MB yazmada 270GiB/s, 4KB rastgele okumada 25,5M IOPS, 4KB rastgele yazmada 4,9M IOPS oldu; 6+2 erasure coding ise 4MB okumada 547GiB/s ve yazmada 387GiB/s kaydetti
  • Kalan risk, büyük ölçekli yazmalarda bazı PG’lerin active+clean+laggy durumuna girip aktarım hızının sert düşmesi; düğüm başına 10’dan fazla NVMe ile daha yüksek aktarım için 200GbE veya üzeri ağ gerekiyor

10PB NVMe Ceph kümesinin tasarımı

  • Müşteri, mevcut HDD tabanlı Ceph kümesini 10PB NVMe dağıtımına dönüştürmek istiyordu; RBD, RGW ve CephFS için özel gereksinimleri yoktu
  • Tasarım koşulları arasında 17 rafa dağıtım, raf başına 4U alan, güç, soğutma, yoğunluk ve tedarikçi tercihi yer alıyordu
  • Yeni düğümlerin mevcut kümeye hizmet kesintisi olmadan entegre edilmesi gerekiyordu; ağ ise hâlihazırda kurulmuş hızlı bir Ethernet yapılandırmasıydı
  • İlk öneri, 17 rafa 34 adet çift soketli 2U düğüm yerleştirmekti; ancak sonunda Clyso’nun tasarladığı Dell tabanlı yapılandırma seçildi
    • Nihai teklif, özgün yapılandırmadan yaklaşık %13 daha ucuzdu
    • OSD başına bellek azalmıştı, ancak hâlâ OSD başına 12GiB düzeyindeydi ve bellek aktarım hızı daha yüksekti
    • Tek soketli yapılandırma, daha fazla toplam CPU kaynağı, daha yüksek toplam ağ aktarım hızı, en yeni AMD işlemciler ve DDR5 RAM kullanıldı
    • Daha küçük düğümler kullanılarak düğüm arızasının küme kurtarmasına etkisi yarıya indirildi

Donanım ve temel yapılandırma

  • Sistem özellikleri şöyleydi
    • Nodes: 68 × Dell PowerEdge R6615
    • CPU: 1 × AMD EPYC 9454P 48C/96T
    • Memory: 192GiB DDR5
    • Network: 2 × 100GbE Mellanox ConnectX-6
    • NVMe: 10 × Dell 15.36TB Enterprise NVMe Read Intensive AG
    • OS: Ubuntu 20.04.6 Focal
    • Ceph: Quincy v17.2.7 upstream Deb packages
  • Müşteri, raf başına ek güç tüketimini yaklaşık 1000~1500W ile sınırlamak istiyordu
    • Raf başına 4 düğümün toplam TDP’sinin en az 1120W olduğu; buna temel güç, CPU tepe tüketimi ve güç kaynağı verimsizliğinin ekleneceği tahmin edildi
    • Gerekirse işlemci cTDP’si düşürülerek raf başına yaklaşık 100W azaltılabileceği değerlendirildi
  • 1U Dell sunucu, upstream Ceph performans laboratuvarı sistemlerinin en yeni nesline yakın bir yapıdaydı
    • Önceki nesil donanımda olmayan, ancak bu donanımı etkileyen performans sorunları test sırasında keşfedildi

Test yöntemi ve benchmark seçimi

  • Burn-in testi, CBT ile geçici bir Ceph kümesi dağıtıp FIO testleri çalıştırma yöntemiyle yapıldı
  • OSD’lerde 8GB osd_memory_target ayarlandı
    • Üretimde daha yüksek bir osd_memory_targetın da mümkün olacağı düşünüldü
  • Müşterinin block veya S3 iş yükü testine ihtiyacı yoktu; ancak RADOS bench yerine FIO’nun librbd motoru kullanıldı
    • Büyük ölçekli RADOS bench için kümeyi doyuracak örnek sayısını belirlemek zordur ve geçmişte birden fazla eşzamanlı pool gerekmişti
    • Mevcut upstream laboratuvar sonuçlarıyla karşılaştırmak için aynı librbd tabanlı FIO testi kullanıldı
    • FIO’nun iyi bilinen ve güvenilen bir araç olması da dikkate alındı
  • kernel RBD testi atlandı
    • librbd motoru, eski mount point’ler nedeniyle sistemin yeniden başlatılmasını gerektiren sorunlardan kaçınabilir
    • Bu kümede IPMI erişimi yoktu ve test tamamlama takvimi de sıkışıktı
    • Önceki test ölçütlerine göre yeterli istemci olduğunda toplam performansın genellikle benzer olması beklendi
  • Test hedefleri arasında 3X çoğaltma ve 6+2 erasure coding vardı
  • msgr V2 hem şifresiz modda hem de secure modda test edildi
    • ms_client_mode = secure
    • ms_cluster_mode = secure
    • ms_service_mode = secure
    • ms_mon_client_mode = secure
    • ms_mon_cluster_mode = secure
    • ms_mon_service_mode = secure
  • FIO önce RBD volume’lerini büyük yazmalarla doldurdu, ardından 4MB ve 4KB IO testlerini ayrı ayrı 300 saniye boyunca çalıştırdı
    • Debug çalıştırmalarında süre 60 saniyeye indirildi
    • scrub, deep scrub, PG autoscaling ve PG balancing gibi arka plan süreçleri devre dışı bırakıldı

PG sayısının performansa etkisi

  • Önceki upstream laboratuvar testlerinde PG sayısının performansı ciddi ölçüde etkileyebildiği doğrulandı
  • Düşük PG sayılarında rastgele dağılımdaki clumpiness performansı etkileyebilir; bunun bir kısmı ek balancing ile hafifletilebilir
  • Hızlı kümelerde OSD içindeki PG lock çekişmesi de toplam performansta önemli rol oynayabilir
    • Bu sorunu PG sayısını artırmak dışında hafifletmek kolay değildir
  • Yalnızca 60 OSD kullanılan testlerde bile 3X çoğaltmalı RBD pool’unun rastgele okuma performansı 16384 PG’ye kadar ölçeklendi
    • Yazma daha erken tepeye ulaştı, ancak 2048 PG’ye kadar fayda vardı
  • Yüksek PG sayıları üretime körlemesine uygulanmamalıdır
    • PG log uzunluğu ve PG stat update gibi Ceph varsayılanları etkili olabilir
    • OSD başına 100 PG şeklindeki mevcut uygulamanın hâlâ geçerli olup olmadığının yeniden değerlendirilmesi gerekir

İlk performans sorunları ve tuhaf davranış

  • Yeni donanıma ilk kez ABD’deki Thanksgiving’den sonraki hafta giriş yapılabildi; özgün plan 1~2 haftalık burn-in doğrulamasının ardından mevcut kümeye entegrasyondu
  • Düşük seviyeli performans testleri başta iyi görünüyordu
    • iperf ağ testleri düğüm başına 200Gb/s’ye yaklaşıyordu
    • Bazı düğümlerde NVMe sürücülerinin temel performansı da makul görünüyordu
  • 68 düğümün tamamının işletim sistemi, dahili Dell BOSS m.2 boot sürücüsü yerine yanlışlıkla 2 OSD sürücüsüne dağıtılmıştı
    • Planlanan 3 düğümlü 30 OSD testi yerine düğüm başına yalnızca 8 NVMe kullanarak test yapmak gerekti
  • İlk Ceph sonuçları, azalan OSD sayısı hesaba katılsa bile beklentinin çok altındaydı
    • Yalnızca rastgele okuma, kabul edilebilir düzeye yakın sayılabilecek durumdaydı ama yeterli değildi
  • Tek düğüm ve tek OSD testlerine daraltıldığında anormal bir örüntü ortaya çıktı
    • Tek OSD testinde iyi çalışan sistem, 8 OSD testinden sonra kötü performans göstermeye başladı
    • Daha sonra tek OSD testleri de birkaç saat boyunca kötü performansı sürdürdü ve ardından toparlandı
    • Araya çoklu OSD testi konmadığında performans yüksek kalmaya devam etti
  • FIO doğrudan sürücü üzerinde çalıştırıldığında aynı sorun yeniden üretilemedi
  • 8 OSD testi sırasında belirli bir OSD, diğer OSD’lerden çok daha fazla CPU kullanıyordu
  • OSD wallclock profile, io_submit içinde çok zaman harcandığını gösteriyordu; bu genellikle sürücü kuyruğu dolup çekirdek bloklandığında görülen bir desendir

Üç düzeltme

  • BIOS performans modu ve c-state

    • İlk düzeltme, BIOS’un maximum performance modunda olmaması nedeniyle CPU c-state’in etkin kalmış olmasıydı
    • Ceph, CPU c-state geçişlerinin yarattığı gecikmeye çok duyarlıdır
    • maximum performance moduyla c-state devre dışı bırakılınca performans %10~20 iyileşti, ancak hedef performans için yeterli olmadı

  • IOMMU çekişmesi

    • İkinci sorun, çekirdek tarafındaki perf profile’da ortaya çıktı
    • Kötü çalıştırma sırasında native_queued_spin_lock_slowpath ve IOMMU DMA mapping yollarında çok zaman harcanıyordu
    • alloc_iova
    • iommu_dma_alloc_iova
    • iommu_dma_map_sg
    • nvme_map_data
    • nvme_queue_rq
    • Çekirdekte IOMMU devre dışı bırakılınca 8 düğümlü testte 4MB okuma/yazma performansı ciddi biçimde iyileşti
    • Bu düzeltmeden sonra da 4KB rastgele yazma sorunu kaldı

  • RocksDB derleme bayrakları

    • Üçüncü sorun, 4KB rastgele yazma ve RocksDB compaction performansının beklentinin altında olmasıydı
    • Geçmişte Ceph’te benzer belirtiler iki nedenle ilişkiliydi
    • TCMalloc desteği olmadan derlenmiş olması
    • Uygun cmake bayrakları ve derleyici optimizasyonları olmadan derlenmiş olması
    • Upstream Ceph Ubuntu paketlerinde TCMalloc yer alıyordu
    • 17.2.7 Ubuntu paketinin build log’larında RocksDB’nin doğru derleme bayraklarıyla derlenmediği doğrulandı
    • Canonical ve Gentoo bu sorunu kendi derlemelerinde düzeltmiş durumdaydı
    • Upstream container kullanan Debian/Ubuntu cephadm kullanıcılarının etkilenmediği görülüyordu
    • Düzeltilmiş custom 17.2.7 paketleri derlenince compaction süresi yaklaşık 3 kat azaldı ve 4KB rastgele yazma performansı 2 kat arttı

2024’ün ilk haftasındaki ölçeklendirme testleri

  • 2 Ocak’ta ilişkili başka bir kümede yaşanan büyük ölçekli arızaya müdahale nedeniyle performans testleri gecikti
  • Cuma gününden itibaren CBT ve testler yeniden yapılandırıldı; bu kez düğüm başına 10 sürücünün tamamı kullanılabiliyordu
  • FIO istemci sayısı, ortalama olarak OSD başına io_depth 128 olan yaklaşık 1 FIO istemcisi olacak şekilde artırıldı
  • 3 düğümlü test, 4MB rastgele okumada 63GiB/s kaydetti
  • 10 düğümlü test 213,5GiB/s kaydetti
    • 3 düğüme göre neredeyse doğrusal ölçeklenmeydi; %98,4 düzeyindeydi
  • O sırada 68 düğümden yalnızca 63’ü kullanılabiliyordu
    • 32 düğüm, 320 OSD bir tarafa ayrıldı
    • 31 istemci düğümde düğüm başına 10 FIO prosesi çalıştırıldı
  • 320 OSD ölçeğinde okumada 635GiB/s ve 4KB rastgele okumada 15 milyon IOPS üstü elde edildi
  • Ortalama gecikme ve tail latency ölçeklendirme testlerinde tutarlı görünüyordu
    • PG sayısı ve FIO istemci sayısının OSD’lerle birlikte artırılmasının etkili olduğu düşünüldü
    • Testler IO’nun çok yoğun olduğu durumdaydı ve daha fazla IO eklemenin performansı artırmadığı, yalnızca gecikmeyi yükselttiği noktaya girildiği düşünüldü

630 OSD ile 1 TiB/s’ye ulaşmak

  • Tam kapasite testi için ayrı istemci düğümler kalmadığından FIO prosesleri OSD düğümlerine birlikte yerleştirildi
    • İstemcinin yerel OSD ile iletişim kurma olasılığı 1/63 olduğundan küçük bir ağ avantajı vardır
    • Buna karşılık FIO istemcilerini OSD düğümlerine birlikte koymak performans kaybı yaratabilir
  • 63 düğümde 630 OSD kuran CBT dağıtımı yaklaşık 15 dakika sürdü
  • İlk deneme yaklaşık 950GiB/s ile 1 TiB/s’ye çok yaklaştı
  • Ardından OSD shard ve async messenger thread sayısı azaltıldı ve Reef RocksDB tuning uygulandı
    • Okuma performansı biraz düştü, yazma performansı iyileşti
    • Rastgele yazma performansı neredeyse %20 iyileşti
    • Daha büyük etkinin shard/thread değişikliğinden geldiği düşünülüyor
  • PG sayısını iki katına çıkarma ve istemci sayısını yeniden artırma deneyi de yapıldı
    • 4MB rastgele okuma, istemci sayısı artışıyla biraz iyileşti
    • Küçük rastgele okuma IOPS’i kötüleşti
    • Düğüm başına 8 FIO, toplam 504 prosesle sıralı yazma performansı ciddi biçimde düştü
  • 504 FIO prosesi 4MB yazma yaptığında bazı PG’ler active+clean+laggy durumuna geçti
    • Aktarım hızı kümenin olası performansının yalnızca bir kısmı olmasına rağmen zamanla laggy PG’ler arttı
    • İş yükü bitene kadar küme bu durumdan toparlanmadı
    • Ceph belgelerine göre laggy durumunda replica, primary’den yeni lease’i zamanında acknowledge edemediği için IO geçici olarak durdurulur
  • Sonuçta varsayılan Ceph ayarları olan 8 shard, shard başına 2 thread ve 3 msgr thread, 4MB okuma için en uygun değerlerdi
  • 256K PG, 630 OSD ve 504 FIO istemci prosesi koşullarında ceph -s 1,0 TiB/s read gösterdi
    • 630 OSD’nin tamamı up/in durumundaydı
    • 262145 PG’nin tamamı active+clean durumundaydı
    • Gösterilen okuma işlemi 266,15k op/s idi

6+2 erasure coding sonuçları

  • Müşterinin gerçekten geçiş yapacağı önceki hedef küme 6+2 erasure coding yapılandırmasında olduğundan ayrı test gerekiyordu
  • Önceki testlerde iyi çalışan PG, shard ve istemci değerleri seçilerek EC testi yapıldı
  • async messenger thread’lerinin yoğun çalıştığı görüldüğü için varsayılan değerin üzerine çıkarma deneyi yapıldı
  • 4~5 async msgr thread ile şu performans elde edildi
    • Okuma: 500GiB/s üzeri
    • Yazma: yaklaşık 400GiB/s
  • 6+2 EC okumanın 3X çoğaltmadan yavaş olmasının nedeni ağ overhead’i farkıdır
    • Çoğaltmada primary OSD’nin yerel veriyi okuyup istemciye göndermesi yeterlidir; ağ overhead’i fiilen 1X’tir
    • 6+2 EC’de primary, object’i oluşturmak için replica’lardan 6 chunk’ın 5’ini okumalı, ardından istemciye göndermelidir
    • İsteğin toplam ağ overhead’i yaklaşık (1 + 5/6)X olur
  • Yazmada ters bir tablo ortaya çıkar
    • 3X çoğaltmada istemcinin primary’ye gönderdiği object’i primary iki secondary’ye yeniden gönderir; toplam ağ overhead’i 3X’tir
    • EC’de secondary’lere 7/8 chunk göndermek yeterli olduğundan büyük yazmalarda daha hızlı performans görülür
  • Küçük IO’nun IOPS’i ayrı bir konudur
    • Çok küçük okuma/yazmalarda Ceph, ilgili object’in PG’sine katılan tüm OSD’lere erişir
    • İlgilenilen veri yalnızca bir chunk’ta olsa bile stripe’a katılan tüm OSD’lerden veri alınır
    • Clyso, 2023 yazında erasure coding için partial stripe reads’i uygulayan PR’ı yeniden canlandırdı ve etkisi büyük oldu
    • Squid’e merge edilip edilmeyeceği henüz net değil

msgr şifrelemesinin etkisi

  • Müşterinin msgr düzeyinde şifreleme kullanması durumundaki etkiyi ölçmek için msgr v2 encryption testi de yapıldı
  • 3X çoğaltma ve 6+2 erasure coding taraflarının ikisinde de şifreleme etkin sonuçlar önceki sonuçlarla karşılaştırıldı
  • En büyük etki büyük okumalarda görüldü
    • Yaklaşık 1 TiB/s’den yaklaşık 750GiB/s’ye düştü
  • Diğer kalemlerde daha ılımlı ama tutarlı performans düşüşü görüldü
  • PG scaling testi ve kernel RBD testi de isteniyordu, ancak sistemin re-imaging ve entegrasyon işleri için müşteriye geri verilmesi gerekiyordu

Nihai en yüksek performans özeti

  • Testlerde ulaşılan en yüksek rakamlar şöyleydi
Kalem 30 OSDs (3x) 100 OSDs (3x) 320 OSDs (3x) 630 OSDs (3x) 630 OSDs (EC62)
Co-located FIO Hayır Hayır Hayır Evet Evet
4MB Read 63 GiB/s 214 GiB/s 635 GiB/s 1025 GiB/s 547 GiB/s
4MB Write 15 GiB/s 46 GiB/s 133 GiB/s 270 GiB/s 387 GiB/s
4KB Rand Read 1.9M IOPS 5.8M IOPS 16.6M IOPS 25.5M IOPS 3.4M IOPS
4KB Rand Write 248K IOPS 745K IOPS 2.4M IOPS 4.9M IOPS 936K IOPS
  • Test bittikten sonra tüm donanım re-imaging’den geçirildi ve yeni OSD’ler müşterinin mevcut HDD kümesine dağıtıldı
  • Dan’in upmap-remapped script’iyle migrasyon kontrol edildi ve mevcut verinin yaklaşık %80’i NVMe tabanlı OSD’lere taşındı
  • Başlangıçta testte uygulanan tüm tuning’leri hemen kullanmak yerine, küme davranışının önce çoğunlukla varsayılan yapılandırmada doğrulanmasına karar verildi
  • Test verileri, müşterinin gelecekte performans sorunları yaşaması durumunda sistemi ek olarak tune etmek için kullanılabilir

Kalan işler ve ölçekleme sınırları

  • Büyük ölçekli yazma yükünde ortaya çıkan laggy PG sorununun çözülmesi gerekiyor
    • Yazma iş yükü büyüdüğünde Ceph’in çökmesi kabul edilemez
  • Bu test, Ceph’in 2×100GbE NIC’i doyurabildiğini doğruladı
  • Düğüm başına 10’dan fazla NVMe sürücü kullanıldığında aktarım hızını daha da artırmak için 200GbE veya üzeri gerekir
  • IOPS daha karmaşık
    • PG sayısı büyük etki yaratabilir
    • OSD threading model de önemli rol oynar
    • Birden fazla dağıtımda düğüm başına yaklaşık 400K~600K rastgele okuma IOPS duvarına çarpıldı
  • İyileştirme noktaları olarak async msgr ile çekirdek arasındaki arayüz ve shard queue’ya yeni iş geldiğinde OSD thread’inin uyanma biçimi gösteriliyor
  • Yüksek yükte daha iyi sonuç almak için OSD kodunun değiştirildiği olmuştu, ancak bunun bedeli düşük yükte gecikmenin kötüleşmesiydi
  • IOPS artışı için birden fazla yönden yaklaşım ve bazı OSD threading kodlarının yeniden yazılması gerekebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-21
Hacker News yorumları

  • Ceph'in ilginç bir geçmişi var
    DreamHost'un kurucuları bunu kendi iç ihtiyaçları için yaptı ve DreamHost, IaaS ile PaaS terimleri sektörde yerleşmeden önce fiilen VPS, yönetilen OS/veritabanı/uygulama sunucusu gibi hizmetler veriyordu
    Daha sonra Ceph'i ayrı bir yapıya dönüştürdüler ve Red Hat tarafından satın alındı
    https://en.wikipedia.org/wiki/DreamHost

    • Hâlâ DreamHost müşterisiyim; o zamanlar “Ceph diye bir şey yapmayı deniyoruz, havalı bir şeye dönüşebilir” tonunda blog yazıları ya da bültenler olduğunu hatırlıyorum
      Her cümlesi bir şey satmak için cilalanmış pazarlama dili yoktu; sadece üzerinde oynadıkları şeyi paylaşıyorlardı
      Kuruculardan birinin üniversite projesiydi diye hatırlıyorum, diğer kurucular da destek verip katılmıştı; Docker'ın da benzer bir kökenden geldiğini biliyorum
    • Biraz daha eklemek gerekirse, DreamHost kurucusu Sage Weil bunu UC Santa Cruz'da yüksek lisans yaparken geliştirdi
      UCSC, çok sayıda iyi depolama araştırmasının çıktığı bir yerdi

  • Güzel yazı. CERN de yakın zamanda 1TB/s seviyesine ulaştı, ama bunu Ceph ile değil EOS(https://cern.ch/eos) ile başardı
    https://www.home.cern/news/news/computing/exabyte-disk-stora...
    Ancak bizim EOS kümemizde çok daha fazla düğüm var ve çoğu HDD kullanıyor. CERN, Ceph'i de geniş ölçekte kullanıyor

    • Harika. Ceph'e nasıl baktığınızı merak ediyorum. Uzun vadede EOS'a geçiş gibi bir plan var mı?

  • Bu tür deneyleri gerçekten seviyordum. Cisco'da teknik lider olarak çalışırken bare metal üzerinde Kubernetes kurup GlusterFS ile Ceph'i bizzat yapılandırarak hangisinin daha iyi olduğunu öğrenme ve karşılaştırma lüksünü yaşadım
    Yanlış hatırlamıyorsam 2017/2018 civarıydı; güzel zamanlardı. Bu yazı da çok iyiydi

    • Aerospike yanıt sürelerini iyileştirmek için yalnızca AWS instance türlerini değil, aynı tür içindeki tek tek instance'ların hızını da karşılaştıran bir sürü benchmark çalıştırmak zorunda kaldım
      Bazı NVMe SSD'ler diğerlerinden daha fazla kullanılmış durumdaydı, bu yüzden fark oluşuyordu; gerçekten akıl almaz bir işti
    • Demek Heketi kullananlardandın. Ben de aynı dönemde benzer bir deneyim yaşadım ve gerçekten çok eğlenceliydi. Her şey çok yeniydi, bir yandan da bozuktu

  • Birisi düğüm ölçeğini daha da küçültmeyi denemeli. Burada açıklanan sistem, düğüm başına 10 disk ve yaklaşık 300W/düğüm ile disk başına yaklaşık 30W ediyor.
    Ek yük oldukça büyük ve az da olsa yedeklilik elde etmek için hatırı sayılır miktarda depolama alanı da gerekiyor.
    Biraz mühendislikle bunun tamamını onda birine indirmek mümkün gibi görünüyor. NVMe için 4 PCIe hattı, 2x10GbE (2 adet SFP+ soketi) ve yeterince hızlı bir ARM veya RISC-V CPU'ya sahip küçük bir tek kart bilgisayar yapıp buna önyükleme için eMMC ya da SD yuvası eklemek gibi.
    Böylece birkaç düğümlük ölçeğe kadar inilebilir ve tek bir arızada aynı anda 10 diskin birden kaybedilmesi riski de azalır.
    Bu tür sistemlerden 4U bir muhafaza içine çok sayıda sığdırılabilir; ayrıca isteğe bağlı olarak aynı muhafaza içinde dahili düğümleri toplayan tamamen bağımsız 2 anahtar da yer alabilir.

    • Geçmişte birkaç ODROID-HC2 ile 5 düğümlü bir Ceph kümesi çalıştırmıştım.
      armhf işlemci yüzünden kurulum gerçekten çok sancılıydı, ama bir kez çalışmaya başlayınca iyi işliyordu. Sadece tek bir 1Gb NIC yüzünden yavaştı.
      O zamanlar sadece öğrenme amaçlıydı.
      [0] https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/
    • Nvidia'nın SODIMM compute module interface yapısıyla bu konsept zaten doğrulanabilir.
      Yakında 7W'lık iki ARM Turing RK1 alacağım; her biri PCIe 3x4 üzerinden 4GB/s veriyor ve Turing Pi 2 cluster board ITX form faktöründe bunlardan 4 tane taşıyabiliyor.
      Toplam 820 dolarlık maliyetle watt başına 3Gbps'ten fazlasını bekliyorum.
      Şu ana kadar darboğaz PCIe hatları oldu. 90 dolarlık 2TB SSD'ler bile PCIe 4x4 üzerinde 7GB/s olarak listeleniyor, bu yüzden tek kart bilgisayarın henüz en iyi çözüm olduğunu düşünmüyorum.
      Ampere Altra serisi 40W'ta PCIe 4x128 destekliyor gibi görünüyor; bu yüzden 100G ağ bağlantılı bir 1U blade ilginç olabilir.
      Yine de homelab ortamında bile ARM ile ilgili çok sayıda hata ve eksik optimizasyon gördüğüm için, böyle bir çözümün henüz veri merkezi için hazır olduğunu söylemek zor olabilir.
    • Ucuz 100Gbps switch ve 100Gbps arayüzlerin artmasıyla 10Gbps giderek demode hale geliyor.
      Bugün 10Gbps arayüzlü bir Ceph kurulumunu haklı çıkarmak için onun gerçekten küçük ve çok ucuz olması gerekir.
      Ölçek bu kadar küçükse, her sunucuda yerel NVMe depolama kullanmak daha mantıklı olabilir.
    • Kabaca bir hesapla bu küme watt başına yaklaşık 0.8Gbps işliyor.
      Bu da yaklaşık olarak 1TB/s × 8 bit/bayt × 1024GB/TB ÷ 34 düğüm ÷ 300W hesabı.
      Yeni Mac mini gibi çok verimli ARM sistemleri etkileşimli kullanımda yaklaşık 10W tüketip 10Gbps ağı işleyebiliyor; yani veri açısından watt başına yaklaşık 1Gbps ediyor.
      Yani yazıdaki küme, kabaca, çok verimli bir ARM sistemiyle benzer bit/saniye/watt seviyesinde.
      Küçük düğümler kullanmanın gerçek verimliliği artıracağını sanmıyorum; hatta büyük ihtimalle daha pahalı olur. Günümüzün güçlü sunucuları watt başına oldukça iyi performans veriyor.
      Her hâlükârda bu, genel amaçlı donanım üzerinde çalışan açık kaynaklı bir yazılım; dolayısıyla birkaç yüz dolarla bunu kendiniz de deneyebilirsiniz.
    • Bu yapıda verimsizliğin ana kaynağı muhtemelen NVMe denetleyicisi.
      İşletim sistemi ile NVMe aygıtı birbirinden uzak olduğunda, denetleyici isteklerin niyetini çıkarıp yerleşim ve aşınma dengelemesini elinden gelen en iyi şekilde yapmak zorunda kalıyor; bu da doğal bir verimsizlik yaratıyor.
      Yeni FDP (flexible data placement) özelliği, işletim sistemine daha fazla kontrol vererek bunu çözmeye yönelik bir girişim.
      En iyi yaklaşım bunun host işletim sistemi tarafına çekilmesi ve flash'ın mümkün olduğunca “PCIe aygıtı olarak bağlı devasa, aptal bir transistör dizisi” gibi sunulması olur.
      Soyutlama katmanları kaldırılırsa, istenen sistem paralelliğini elde etmek için entegre 100Gbps NIC ve buna orantılı miktarda flash içeren Atom benzeri donanım birimlerinden oluşan bir yapı kurulabilir gibi görünüyor.

  • Dünyada depolanan toplam dijital veri miktarının ilk kez 1TiB'e ulaştığı tarihsel bir an mutlaka olmuştur.
    O günün neredeyse kesin olarak son 60 yıl içinde bir yerde yaşandığı söylenebilir.
    Ama şimdi, oldukça sıradan bir kurumun sunucusu bu miktarda veriyi her saniye taşıyor. Hem de ulusal ölçekte ya da ulusötesi bir araştırma projesi olmadan.

    • Bir zamanlar hesaplamıştım; masaüstü PC'min yaklaşık 1978 civarında dünyadaki tüm bilgisayarların toplamından daha güçlü çıkmış olması aklıma geldi.
    • En az 20 yıldan daha eski bir durum bu. 2003'ten önce petabyte yönettiklerinden bahseden yaşlı bir sistem yöneticisini hatırlıyorum.

  • İlginç bir yazı. Docker layer cache tutmak için bir Ceph depolama kümesi işletiyoruz.
    EBS'ten Ceph'e geçtikten sonra throughput farkı muazzamdı. Yazma throughput'u 146MB/s ve 3,000 IOPS'tan 900MB/s ve 30,000 IOPS'a çıktı.
    En güzel yanı ise neredeyse kendi kendine çalışması. Ara sıra dosya sistemi trim'i gibi şeyler dışında neredeyse hiç bakım gerektirmiyor.
    Önbellek sistemi için çok büyük bir iyileştirme oldu.
    [0] https://depot.dev/blog/cache-v2-faster-builds

    • Yaklaşık 10 yıl önce çok benzer bir şey yapmıştım. Aynı performans kriterlerinde EBS maliyeti, düğüm diskleri üzerindeki Ceph kümesinden 10 kat daha fazlaydı.
      Sonunda kendi rack'imize taşınarak maliyeti tekrar neredeyse onda birine indirdik ve şirket içinde operasyonel yetkinlik kazanarak daha özgür hale geldik.
    • EBS'yi bare metal üzerinde mi barındırdığınızı merak ediyorum. Ceph'i kendi/kiralık bare metal üzerinde mi, yoksa EC2 sanal makinelerinde mi çalıştırıyorsunuz?
      Sadece blog yazısından bakınca bu hemen netleşmiyordu.

  • Küme içi dinamik depolama ile yaşadığım en kötü sorunlar saf I/O problemleri değildi.
    Asıl mesele, Kubernetes'in depolama denetleyici yazılımının gerçek dünyadaki durumları iyi ele alamamasıydı; örneğin bir pod'un ölmesi, PVC'nin çok uzun bir zaman aşımı bitene kadar bağlanmaması ve pod'un PVC kilidi açılana kadar ContainerCreating durumunda kalması gibi.
    Bunlar rook/ceph ve Longhorn kullanan birden fazla kümede yaşandı.

  • Ev labında Ceph çalıştırmış biri olup olmadığını merak ediyorum. En son baktığımda donanım gereksinimleri epey yüksekti

    • Hâlâ yüksek. Hem prodüksiyon hem de ev labı dağıtımları kurmuş biri olarak, sırf deneyim kazanmak veya demo hazırlamak dışında bir amaç yoksa pek girişmemek daha iyi
      İyi çalıştığında harika, ama bir sorun çıktığında inanılmaz bir baş ağrısına dönüşüyor
      Dağıtık depolamanın kendisine ilginiz varsa, ev labı kurulumu için daha iyi seçenekler var
      seaweedfs hem küçük ölçekte hem de çok büyük ölçekte yıllardır çok kararlıydı; hatta prodüksiyondaki Ceph kurulumunu buna taşıdım
      Kubernetes tarafındayken Longhorn da kararlıydı
      GlusterFS de neyi göze aldığınızı bilerek girerseniz hâlâ fena değil
    • Kullandım; web UI, nesne depolama ve dosya depolama gerçekten çok hoştu
      Ama düzgün performans almak çok zordu ve küçük kümelerde metadata daemon oldukça kolay şekilde durabiliyordu
      Sonunda işin eğlencesi kaçınca tekrar tek makinede ZFS kullanmaya döndüm
    • Hem işte hem de ev labına benzer ortamlarda Ceph kullandım
      Öncelikle Ceph'in bir dağıtık depolama sistemi olduğunu akılda tutmak gerek; yani birden fazla düğüm olması temel varsayım
      Öğrenmek için her şeyi tek bir makinede sanallaştırabilirsiniz, ama ayrı fiziksel makineleriniz varsa çok daha iyi olur
      Ceph, ZFS'ye benzer şekilde disklere fiziksel erişimi tercih eder
      Ayrıca iyi bir ağ bağlantısı gerekir. Bence insanlar Ceph'in yüksek donanım gereksinimlerini düşününce en çok bu kısmı kastediyor
      İdeal olarak en az 10GbE iyidir; daha yüksek performans istiyorsanız bunun da üstüne çıkmanız gerekir. Özellikle backfill gibi işlemlerde ağ trafiği çok olabilir
      Ev labı ekipmanını ucuza bulabiliyorsanız 25Gbps de iyi, 50Gbps teknik olarak çıkmaz sokağa yakın, 100Gbps ise iyi çalışıyor
      Yine de ev labı için 10GbE'li ucuz mini PC'ler veya NUC'lerle gayet çalışır; makul performans ve iyi bir öğrenme deneyimi elde edebilirsiniz
      Ceph'i doğrudan bare metal üzerine kurabilirsiniz; ya da ev labı Kubernetes yoluna gitmek istiyorsanız Rook(https://rook.io/) kullanabilirsiniz
      Umarım yardımcı olur; ek sorularınız varsa söyleyin
    • Ceph tarafında, birkaç Raspberry Pi 4 üzerine Ceph kurulumu anlatan bir blog yazısı var
      O kadarı hiç de büyük donanım sayılmaz
      [1] https://ceph.io/en/news/blog/2022/install-ceph-in-a-raspberr...
    • Kendi labımda Ceph çalıştırıyorum. CPU'yu epey kullanıyor ama hızlı ağı göze alırsanız iyi çalışıyor
      En az 10Gb, mümkünse 40Gb ve üstü iyi olur; döner disk kullanıyorsanız birkaç düğümün her birinde en az 6 disk olması tercih edilir
      Tamamı SSD ise düğüm başına disk sayısını büyük ölçüde azaltmanız muhtemeldir

  • 1TiB/s’nin gerçek donanımın teorik sınırlarıyla nasıl karşılaştırıldığını görmek istediğim için hesap yaptım
    Bu küme 68 düğümden oluşuyor ve her düğüm Dell PowerEdge R6615(https://www.delltechnologies.com/asset/en-us/products/server...)
    Kullanılan yapılandırma, 10 adet U.2 sürücü yuvasına sahip bir R6615 ve U.2 bağlantısı veriyi PCIe 4. nesil 4 hat üzerinden taşıyor. Bir PCIe hattı 16Gbit/s ve 128b-132b kodlaması sayesinde ek yük yaklaşık %3 olduğu için ihmal edilebilir
    Bu nedenle tek bir U.2 bağlantısının azami bağlantı bant genişliği 16×4=64Gbit/s, yani 8Gbyte/s. Ancak kullanılan U.2 NVMe sürücüsü olan Dell 15.36TB Enterprise NVMe Read Intensive AG’nin okuma aktarım hızının 7Gbyte/s olduğu görülüyor(https://www.serversupply.com/SSD%20W-TRAY/NVMe/15.36TB/DELL/...), dolayısıyla 8Gbyte/s’lik U.2 bağlantısı darboğaz değil
    Düğüm başına 10 U.2 sürücü olduğundan, her düğüm en fazla 10×7=70Gbyte/s yerel okuma G/Ç’si üretebilir
    Ancak her düğümün ağ bant genişliği yalnızca 200Gbit/s (2×100GbE Mellanox ConnectX-6), yani 25Gbyte/s. Bu, uzak okumalarda sürücünün 70Gbyte/s kapasitesinin tamamının kullanılamadığı ve darboğazın ağ olduğu anlamına geliyor
    Ek ağ darboğazı olmadığını varsayarsak, 68 düğüm 68×25=1700Gbyte/s ağ okuması sunabilir. Yazar fiilen 1TiB/s, daha doğrusu 1025GiB/s=1101Gbyte/s ölçmüş; bu da teorik azami 1700Gbyte/s’nin %65’i demek
    Oldukça iyi, ancak tüm düğümler aynı anda 200Gbit/s ağ bağlantılarını tamamen doyurabilse teorik olarak biraz daha iyi olabilir
    Yazının tamamını okurken Ceph’in karmaşıklığının CPU üzerinde oldukça büyük bir yük oluşturduğu izlenimini edindim. Modüllerin -O2 ile derlenmemesi bile (yazarın bağlantı verdiği “Fix Three”: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1894453) salt G/Ç iş yüklerinde “bazı iş yüklerini 5 kata kadar yavaşlatabilir”(https://bugs.gentoo.org/733316) olması oldukça şaşırtıcı
    OSD iş parçacıklarının IOMMU spinlock’larını tutmak için CPU’yu aşırı harcaması da tuhaf. OSD iş parçacığı modelinin optimal olmadığı sonucuna katılıyorum
    Görece basit, sentetik %100 okuma kıyaslaması iş parçacığı çekişmesini ortaya çıkarmamalıydı. Tabii Ceph yazılım mimarisinin o kısmı iyi tasarlanmış olsaydı. Düzeltilebilecek bir sorun, umarım Ceph geliştiricileri buna daha yüksek öncelik verir

    • Ceph’te IOMMU sorununu daha önce hiç görmediğimi eklemek isterim
      Upstream Ceph laboratuvarında, Dell’in aynı 1U kasasının bir önceki nesli ve AMD Rome işlemcileri kullanan sistemler var; benzer ölçekte, yaklaşık 30 OSD ile benzer performans veriyorlar ve bu sorunu yaşamıyorlar
      Müşteri bu sorunu kendi veri merkezinde daha önce de gördüğünü söyledi ve AMD ile birlikte nedenini ortaya çıkarabilmeyi umuyoruz
      Geçen yaz OSD’nin mevcut iş parçacığı modelini geçici olarak güçlendirmek için biraz çalışma yaptım. Async msgr ile worker iş parçacıkları arasında devir işlemi için çift tamponlama, uyarlanabilir iş parçacığı uyandırma gibi şeyler
      Yük altında performansı ve verimliliği ciddi biçimde artırabildik, ancak düşük yükte gecikmenin artması pahasına. Ceph, varsayılan olarak belirli bir shard’a yeni G/Ç geldiğinde iş parçacıklarını uyandırma konusunda çok agresif
      Başka bir çekirdek geliştiriciyle bunu tartıştım ve ikimiz de iş parçacığı kodunun baştan aşağı yenilenmesinin daha mantıklı olduğu sonucuna vardık
    • Bu kıyaslama rastgele G/Ç. Diskler 4K rastgele okuma IOPS’ta “yalnızca” 1 milyonun biraz üzerine çıkıyor, bu da yaklaşık 5GiB/s’ye denk geliyor
      320 OSD varsa bu yaklaşık 1.6TiB/s eder
      En azından benim bulduğum sayılar böyleydi. Zaten bu tür kurumsal NVMe disk incelemeleri de çok fazla değil
      Yine de NIC ile uyumlu bir sayı gibi görünüyor. Bu ölçekte çoğu iş yükü, depolama katmanında büyük olasılıkla rastgele G/Ç gibi görünecektir
    • PCIe TLP ek yükünün ve NVMe komutlarının 7GB/s ile 8GB/s arasındaki farkı açıkladığını düşünüyorum

  • Şaşırtıcı olan, neden soğutması daha zor olan 1U düğümler ile 10 SSD / 2×100Gb NIC yapılandırmasının seçildiği
    24 SSD’li ve 2×200Gb ya da 400Gb NIC’li 2U düğümler kullanılsaydı ağ darboğazı ortadan kalkabilir, daha büyük ve daha yavaş fanlar ile daha az CPU paketi sayesinde güç tüketimi de düşebilirdi. Soket başına çekirdek sayısı da daha yüksek olabilirdi
    Düğüm sayısının azalması arıza etki alanını büyütür, ama yaklaşık 34 düğümde bunun o kadar büyük bir sorun olacağını sanmıyorum
    Daha az düğümle, sanırım 4 kadar anahtarla daha düz bir ağ da kurulabilirdi

    • Dediğiniz gibi, ana etken arıza etki alanı ve bu genelde yamaları ve donanım değişimlerini daha az sancılı hale getiriyor
      Raflar ve anahtarlar zaten mevcut ve başka amaçlarla da yoğun biçimde kullanılıyor, bu yüzden Ceph nedeniyle eklenen fiziksel alan çok küçük : )