Ceph: Perjalanan Menuju 1 TiB/s

 (ceph.io)
4 poin oleh GN⁺ 2024-01-21 | 1 komentar | Bagikan ke WhatsApp
  • Clyso melakukan uji burn-in sebelum memigrasikan klaster Ceph berbasis HDD ke deployment NVMe 10PB, dan mencapai pembacaan 1.0 TiB/s pada satu klaster dengan 630 OSD
  • Perangkat keras final terdiri dari 68 Dell PowerEdge R6615 dengan 10 NVMe per node, tetapi pengujian performa tertinggi dilakukan dengan 63 node yang tersedia dan 630 OSD
  • Bottleneck awal diatasi dengan memperbaiki CPU c-state di BIOS, kontensi pemetaan IOMMU di kernel, dan masalah flag kompilasi RocksDB pada paket upstream Ceph Ubuntu Deb; waktu compaction berkurang sekitar 3x dan penulisan acak 4KB meningkat 2x
  • Puncak konfigurasi replikasi 3X adalah 4MB read 1025GiB/s, 4MB write 270GiB/s, 4KB random read 25.5M IOPS, dan 4KB random write 4.9M IOPS, sementara erasure coding 6+2 mencatat 4MB read 547GiB/s dan write 387GiB/s
  • Risiko yang masih tersisa adalah pada penulisan skala besar, saat sebagian PG masuk ke status active+clean+laggy dan throughput turun drastis; untuk mendapatkan throughput lebih tinggi dengan lebih dari 10 NVMe per node dibutuhkan jaringan 200GbE atau lebih

Desain klaster Ceph NVMe 10PB

  • Pelanggan ingin memigrasikan klaster Ceph berbasis HDD yang ada ke deployment NVMe 10PB, tanpa kebutuhan khusus untuk RBD, RGW, atau CephFS
  • Syarat desain mencakup distribusi ke 17 rak, ruang 4U per rak, daya, pendinginan, kepadatan, dan preferensi vendor
  • Node baru harus diintegrasikan ke klaster yang ada tanpa gangguan layanan, dan jaringannya sudah berupa konfigurasi Ethernet cepat yang telah dibangun
  • Usulan awal adalah menempatkan 34 node dual-socket 2U di 17 rak, tetapi pada akhirnya dipilih konfigurasi berbasis Dell yang dirancang Clyso
    • Penawaran final sekitar 13% lebih murah daripada konfigurasi awal
    • Memori per OSD lebih kecil, tetapi masih sekitar 12GiB per OSD, dan throughput memorinya lebih cepat
    • Menggunakan konfigurasi single-socket, total sumber daya CPU lebih besar, total throughput jaringan lebih besar, serta prosesor AMD terbaru dan RAM DDR5
    • Dengan node yang lebih kecil, dampak kegagalan node terhadap pemulihan klaster berkurang setengahnya

Perangkat keras dan konfigurasi dasar

  • Spesifikasi sistemnya sebagai berikut
    • 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
  • Pelanggan ingin membatasi konsumsi daya tambahan per rak sekitar 1000~1500W
    • Total TDP untuk 4 node per rak diperkirakan minimal 1120W, ditambah daya dasar, puncak CPU, dan inefisiensi catu daya
    • Jika perlu, cTDP prosesor dapat diturunkan untuk mengurangi sekitar 100W per rak
  • Server Dell 1U memiliki konfigurasi yang mendekati generasi terbaru dari sistem laboratorium performa Ceph upstream
    • Selama pengujian ditemukan masalah performa yang tidak ada pada perangkat keras generasi sebelumnya tetapi memengaruhi perangkat keras kali ini

Metode pengujian dan pemilihan benchmark

  • Uji burn-in dilakukan dengan mendeploy klaster Ceph sementara menggunakan CBT dan menjalankan pengujian FIO
  • Pada OSD disetel osd_memory_target sebesar 8GB
    • Untuk produksi, diperkirakan osd_memory_target yang lebih tinggi juga memungkinkan
  • Pelanggan tidak membutuhkan pengujian workload block atau S3, tetapi engine librbd milik FIO digunakan alih-alih RADOS bench
    • RADOS bench pada skala besar sulit menentukan jumlah instance yang diperlukan untuk memenuhi kapasitas klaster, dan sebelumnya pernah perlu beberapa pool bersamaan
    • Untuk dibandingkan dengan hasil lab upstream sebelumnya, digunakan pengujian FIO berbasis librbd yang sama
    • FIO juga dipertimbangkan karena merupakan alat yang dikenal luas dan dipercaya
  • Pengujian kernel RBD tidak dilakukan
    • Engine librbd dapat menghindari masalah mount point lama yang membuat sistem perlu reboot
    • Klaster ini tidak memiliki akses IPMI, dan tenggat penyelesaian pengujian juga ketat
    • Berdasarkan pengujian sebelumnya, bila klien mencukupi maka performa total diperkirakan kurang lebih serupa
  • Target pengujian mencakup replikasi 3X dan erasure coding 6+2
  • msgr V2 diuji baik dalam mode tidak terenkripsi maupun mode secure
    • 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 pertama-tama mengisi volume RBD dengan penulisan besar, lalu menjalankan pengujian IO 4MB dan 4KB masing-masing selama 300 detik
    • Pada eksekusi debugging durasinya dipangkas menjadi 60 detik
    • Proses latar belakang seperti scrub, deep scrub, autoscaling PG, dan balancing PG dinonaktifkan

Pengaruh jumlah PG terhadap performa

  • Pada pengujian lab upstream sebelumnya, dipastikan bahwa jumlah PG dapat sangat memengaruhi performa
  • Dengan jumlah PG rendah, clumpiness pada distribusi acak dapat memengaruhi performa, dan sebagian dapat diredakan dengan balancing tambahan
  • Pada klaster cepat, kontensi PG lock di dalam OSD juga bisa berperan penting terhadap performa keseluruhan
    • Masalah ini sulit diredakan selain dengan menambah jumlah PG
  • Bahkan pada pengujian yang hanya memakai 60 OSD, performa random read untuk pool RBD replikasi 3X terus naik hingga 16384 PG
    • Write mencapai puncaknya lebih awal, tetapi tetap ada manfaat hingga 2048 PG
  • Jumlah PG tinggi tidak boleh diterapkan begitu saja ke produksi
    • Default Ceph seperti panjang PG log dan PG stat update dapat berpengaruh
    • Praktik lama 100 PG per OSD mungkin perlu ditinjau ulang apakah masih valid

Masalah performa awal dan perilaku aneh

  • Login pertama ke perangkat keras baru baru bisa dilakukan pada pekan setelah Thanksgiving di AS, dan rencananya semula adalah validasi burn-in 1~2 minggu sebelum integrasi ke klaster lama
  • Pengujian performa level rendah awalnya tampak bagus
    • Pengujian jaringan iperf mendekati 200Gb/s per node
    • Performa dasar beberapa drive NVMe pada sebagian node juga tampak wajar
  • Sistem operasi pada seluruh 68 node ternyata salah dideploy ke 2 drive OSD, bukan ke drive boot internal Dell BOSS m.2
    • Akibatnya, alih-alih pengujian 3 node 30 OSD seperti rencana, pengujian dilakukan hanya dengan 8 NVMe per node
  • Hasil Ceph pertama jauh di bawah harapan, bahkan setelah mempertimbangkan berkurangnya jumlah OSD
    • Hanya random read yang mendekati tingkat yang masih bisa diterima, tetapi tetap belum cukup
  • Saat dipersempit ke pengujian satu node dan satu OSD, muncul pola tidak normal
    • Sistem yang bekerja baik pada pengujian satu OSD menjadi lambat setelah pengujian 8 OSD
    • Setelah itu, pengujian satu OSD pun tetap buruk selama beberapa jam sebelum pulih
    • Jika tidak diberi pengujian multi-OSD, performa tetap tinggi
  • Saat FIO dijalankan langsung pada drive, masalah yang sama tidak muncul kembali
  • Selama pengujian 8 OSD, satu OSD tertentu menggunakan CPU jauh lebih banyak daripada OSD lain
  • Profil wallclock OSD menunjukkan banyak waktu dihabiskan pada io_submit, pola yang biasanya muncul saat antrean drive penuh dan kernel mengalami blocking

Tiga perbaikan

  • Mode performa BIOS dan c-state

    • Perbaikan pertama adalah BIOS ternyata tidak berada pada mode maximum performance, sehingga CPU c-state aktif
    • Ceph sangat sensitif terhadap latensi yang ditimbulkan perpindahan CPU c-state
    • Setelah c-state dinonaktifkan melalui mode maximum performance, performa meningkat 10~20%, tetapi masih belum cukup untuk mencapai target

  • Kontensi IOMMU

    • Masalah kedua terlihat dari perf profile di sisi kernel
    • Pada eksekusi buruk, banyak waktu habis di native_queued_spin_lock_slowpath dan jalur pemetaan DMA IOMMU
    • alloc_iova
    • iommu_dma_alloc_iova
    • iommu_dma_map_sg
    • nvme_map_data
    • nvme_queue_rq
    • Setelah IOMMU dinonaktifkan di kernel, performa 4MB read/write pada pengujian 8 node meningkat signifikan
    • Namun setelah perbaikan ini, masalah random write 4KB masih tersisa

  • Flag kompilasi RocksDB

    • Masalah ketiga adalah performa random write 4KB dan compaction RocksDB yang lebih rendah dari perkiraan
    • Pada Ceph sebelumnya, gejala serupa terkait dengan dua penyebab
    • Kompilasi tanpa dukungan TCMalloc
    • Kompilasi tanpa flag cmake yang tepat dan optimasi compiler yang sesuai
    • Paket Ceph Ubuntu upstream memang menyertakan TCMalloc
    • Dari build log paket Ubuntu 17.2.7 terkonfirmasi bahwa RocksDB tidak dibangun dengan flag kompilasi yang benar
    • Canonical dan Gentoo sudah memperbaiki masalah ini di build mereka sendiri
    • Pengguna cephadm Debian/Ubuntu yang memakai container upstream tampaknya tidak terdampak
    • Setelah membangun paket custom 17.2.7 yang sudah diperbaiki, waktu compaction turun sekitar 3x dan performa random write 4KB naik 2x

Pengujian skala besar pada pekan pertama 2024

  • Pada 2 Januari, pengujian performa tertunda karena harus menangani gangguan besar pada klaster lain yang terkait
  • Mulai hari Jumat, CBT dan pengujian dikonfigurasi ulang, dan kali ini semua 10 drive per node bisa digunakan
  • Jumlah klien FIO ditambah hingga rata-rata menjadi sekitar 1 klien FIO dengan io_depth 128 per OSD
  • Pengujian 3 node mencatat 63GiB/s untuk random read 4MB
  • Pengujian 10 node mencatat 213.5GiB/s
    • Ini hampir skala linear dibanding 3 node, sekitar 98.4%
  • Saat itu hanya 63 dari 68 node yang bisa dipakai
    • 32 node, 320 OSD diletakkan di satu sisi
    • Pada 31 node klien dijalankan 10 proses FIO per node
  • Pada skala 320 OSD, dicapai 635GiB/s read dan lebih dari 15 juta IOPS random read 4KB
  • Rata-rata latensi dan tail latency konsisten selama pengujian skala besar
    • Diperkirakan karena jumlah PG dan klien FIO ditingkatkan seiring bertambahnya OSD
    • Pengujian berada pada kondisi IO yang sangat tinggi, dan diperkirakan sudah mencapai titik saat menambah IO lagi tidak menaikkan performa, hanya menaikkan latensi

Mencapai 1 TiB/s pada 630 OSD

  • Karena tidak ada lagi node klien terpisah untuk pengujian kapasitas penuh, proses FIO ditempatkan bersama node OSD
    • Ada kemungkinan 1/63 klien berkomunikasi dengan OSD lokal sehingga memberi sedikit keuntungan jaringan
    • Sebaliknya, menempatkan klien FIO bersama node OSD juga bisa menurunkan performa
  • Deployment CBT untuk 630 OSD pada 63 node memakan waktu sekitar 15 menit
  • Percobaan pertama mencapai sekitar 950GiB/s, sangat dekat dengan 1 TiB/s
  • Setelah itu jumlah OSD shard dan async messenger thread dikurangi, dan tuning Reef RocksDB diterapkan
    • Performa read sedikit turun, tetapi performa write membaik
    • Performa random write meningkat hampir 20%
    • Dampak yang lebih besar tampaknya berasal dari perubahan shard/thread
  • Juga dilakukan eksperimen dengan menggandakan jumlah PG dan kembali menaikkan jumlah klien
    • Random read 4MB sedikit membaik seiring bertambahnya jumlah klien
    • IOPS random read kecil justru memburuk
    • Pada 8 FIO per node, total 504 proses, performa sequential write turun tajam
  • Saat 504 proses FIO menjalankan write 4MB, sebagian PG masuk ke status active+clean+laggy
    • Seiring waktu, jumlah PG laggy bertambah walau throughput hanya sebagian dari performa yang seharusnya mampu dicapai klaster
    • Hingga workload selesai, klaster tidak pulih dari kondisi tersebut
    • Menurut dokumentasi Ceph, dalam status laggy, replica gagal mengakui lease baru dari primary tepat waktu sehingga IO berhenti sementara
  • Pada akhirnya, konfigurasi default Ceph yaitu 8 shard, 2 thread per shard, dan 3 msgr thread paling cocok untuk read 4MB
  • Dengan 256K PG, 630 OSD, dan 504 proses klien FIO, ceph -s menampilkan 1.0 TiB/s read
    • Seluruh 630 OSD berada dalam status up/in
    • Semua 262145 PG berada dalam status active+clean
    • Operasi read yang ditampilkan adalah 266.15k op/s

Hasil erasure coding 6+2

  • Klaster tujuan migrasi aktual pelanggan memakai konfigurasi erasure coding 6+2, sehingga perlu pengujian terpisah
  • Untuk pengujian EC, dipilih nilai PG, shard, dan klien yang bekerja baik pada pengujian sebelumnya
  • Karena async messenger thread terlihat sibuk, dilakukan percobaan menambah jumlahnya melebihi default
  • Pada 4~5 async msgr thread, performa berikut dicapai
    • Read: lebih dari 500GiB/s
    • Write: hampir 400GiB/s
  • Alasan read 6+2 EC lebih lambat daripada replikasi 3X adalah perbedaan overhead jaringan
    • Pada replikasi, primary OSD cukup membaca data lokal dan mengirimkannya ke klien, sehingga overhead jaringan praktis 1X
    • Pada 6+2 EC, primary harus membaca 5 dari 6 chunk dari replica untuk menyusun object, lalu mengirimkannya ke klien
    • Total overhead jaringan permintaan kira-kira (1 + 5/6)X
  • Pada write, polanya justru terbalik
    • Pada replikasi 3X, object yang dikirim klien ke primary diteruskan lagi oleh primary ke dua secondary, sehingga total overhead jaringan 3X
    • Pada EC, hanya perlu mengirim 7/8 chunk ke secondary, sehingga untuk write besar performanya lebih cepat
  • IOPS untuk IO kecil adalah persoalan berbeda
    • Pada read/write yang sangat kecil, Ceph mengakses semua OSD yang berpartisipasi dalam PG object tersebut
    • Walaupun data yang dibutuhkan hanya ada pada satu chunk, data tetap diambil dari semua OSD yang ikut dalam stripe
    • Clyso menghidupkan kembali PR untuk partial stripe reads pada erasure coding yang mereka implementasikan pada musim panas 2023, dan hasilnya besar
    • Belum jelas apakah ini dapat di-merge ke Squid

Dampak enkripsi msgr

  • Untuk memperkirakan dampak jika pelanggan memakai enkripsi tingkat msgr, dilakukan juga pengujian msgr v2 encryption
  • Hasil saat enkripsi diaktifkan dibandingkan dengan hasil sebelumnya baik pada replikasi 3X maupun erasure coding 6+2
  • Dampak terbesar muncul pada read besar
    • Turun dari sekitar 1 TiB/s menjadi sekitar 750GiB/s
  • Item lain menunjukkan penurunan performa yang lebih ringan tetapi konsisten
  • Pengujian scaling PG dan pengujian kernel RBD juga diinginkan, tetapi sistem harus dikembalikan ke pelanggan untuk proses re-imaging dan integrasi

Ringkasan performa puncak akhir

  • Angka tertinggi yang dicapai dalam pengujian adalah sebagai berikut
Item 30 OSDs (3x) 100 OSDs (3x) 320 OSDs (3x) 630 OSDs (3x) 630 OSDs (EC62)
Co-located FIO No No No Yes Yes
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
  • Setelah pengujian selesai, seluruh perangkat keras di-reimage, dan OSD baru dideploy ke klaster HDD pelanggan yang sudah ada
  • Migrasi dikendalikan dengan upmap-remapped script milik Dan, dan sekitar 80% data lama dipindahkan ke OSD berbasis NVMe
  • Pada awalnya diputuskan untuk tidak langsung memakai semua tuning dari pengujian, melainkan terlebih dahulu memastikan operasi klaster pada sebagian besar konfigurasi default
  • Data pengujian ini nantinya dapat digunakan untuk tuning tambahan jika pelanggan mengalami masalah performa

Tantangan yang tersisa dan batas skalabilitas

  • Masalah laggy PG yang muncul pada beban write skala besar masih perlu diselesaikan
    • Tidak dapat diterima jika Ceph kolaps ketika workload write membesar
  • Pengujian ini menegaskan bahwa Ceph dapat memenuhi kapasitas 2×100GbE NIC
  • Untuk menaikkan throughput lebih jauh saat menggunakan lebih dari 10 drive NVMe per node, dibutuhkan 200GbE atau lebih
  • IOPS lebih kompleks
    • Jumlah PG bisa sangat berpengaruh
    • Model threading OSD juga memainkan peran penting
    • Pada berbagai deployment, sering terbentur batas sekitar 400K~600K random read IOPS per node
  • Sebagai titik perbaikan, disorot antarmuka async msgr dengan kernel, serta cara thread OSD dibangunkan saat pekerjaan baru masuk ke shard queue
  • Pernah dilakukan modifikasi pada kode OSD untuk hasil yang lebih baik di bawah beban tinggi, tetapi dengan konsekuensi latensi beban rendah menjadi lebih buruk
  • Peningkatan IOPS memerlukan pendekatan dari beberapa arah dan kemungkinan penulisan ulang sebagian kode threading OSD

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-21
Pendapat di Hacker News

  • Ceph punya sejarah yang menarik
    Para pendiri DreamHost membuatnya karena kebutuhan internal, dan DreamHost pada dasarnya sudah menjalankan layanan seperti VPS, OS/database/server aplikasi terkelola, sebelum istilah IaaS dan PaaS mapan di industri
    Setelah itu Ceph dipisahkan menjadi perusahaan sendiri dan diakuisisi oleh Red Hat
    https://en.wikipedia.org/wiki/DreamHost

    • Saya masih pelanggan DreamHost, dan ingat tulisan blog atau newsletter waktu itu yang kira-kira berbunyi “kami sedang mencoba membuat sesuatu bernama Ceph, mungkin bisa jadi sesuatu yang keren”
      Itu masa ketika belum ada kalimat pemasaran yang dipoles untuk menjual setiap kalimat; mereka sekadar membagikan sesuatu yang sedang mereka utak-atik
      Seingat saya, itu adalah proyek kuliah salah satu pendirinya, lalu para pendiri lain ikut mendukungnya; saya juga tahu Docker punya asal-usul yang mirip
    • Sedikit tambahan, Ceph juga dibuat oleh Sage Weil, pendiri DreamHost, saat ia menjalani program pascasarjana di UC Santa Cruz
      UCSC adalah tempat yang menghasilkan banyak riset storage bagus

  • Artikel yang bagus. CERN juga baru-baru ini mencapai 1TB/s, tetapi bukan dengan Ceph, melainkan dengan EOS(https://cern.ch/eos)
    https://www.home.cern/news/news/computing/exabyte-disk-stora...
    Namun klaster EOS kami memiliki jauh lebih banyak node dan sebagian besar memakai HDD. CERN juga menggunakan Ceph secara luas

    • Keren. Saya penasaran bagaimana pandangan kalian terhadap Ceph. Apakah rencananya dalam jangka panjang akan bermigrasi ke EOS?

  • Saya benar-benar menyukai eksperimen seperti ini. Saat bekerja sebagai tech lead di Cisco, saya punya kemewahan untuk menyusun Kubernetes di bare metal, lalu menyiapkan GlusterFS dan Ceph sendiri agar bisa mempelajari serta membandingkan mana yang lebih baik
    Seingat saya itu sekitar 2017/2018, masa yang menyenangkan. Artikel ini juga sangat bagus

    • Untuk meningkatkan waktu respons Aerospike, saya harus menjalankan banyak benchmark yang membandingkan bukan hanya tipe instance AWS, tetapi juga kecepatan masing-masing instance dalam tipe yang sama
      Sebagian NVMe SSD sudah lebih banyak dipakai daripada yang lain sehingga ada perbedaan, dan itu benar-benar pekerjaan yang tidak masuk akal
    • Berarti kamu pengguna Heketi. Saya juga punya pengalaman serupa pada periode yang sama dan itu sangat menyenangkan. Semuanya terasa begitu baru, dan juga rusak

  • Saya berharap ada yang mencoba mengecilkan skala node lebih jauh. Sistem yang dijelaskan di sini memakai 10 disk per node dengan sekitar 300W/node, jadi kira-kira 30W per disk
    Overhead-nya cukup besar, dan untuk mendapat sedikit saja redundansi juga butuh ruang penyimpanan yang cukup banyak
    Dengan sedikit rekayasa, rasanya keseluruhan bisa diperkecil menjadi sepersepuluh. Misalnya membuat komputer single-board kecil dengan 4 lane PCIe untuk NVMe, 2x10GbE(2 soket SFP+), CPU ARM atau RISC-V yang cukup cepat, lalu menambahkan eMMC atau slot SD untuk boot
    Dengan begitu skalanya bisa diturunkan hingga hanya beberapa node, dan paparan risiko satu kegagalan yang sekaligus menghilangkan 10 disk juga berkurang
    Sepertinya banyak sistem seperti ini bisa dimasukkan ke enclosure 4U, dan secara opsional bisa juga memasukkan 2 switch yang sepenuhnya independen di enclosure yang sama untuk mengagregasi node internal

    • Dulu saya pernah menjalankan klaster Ceph 5 node dengan beberapa ODROID-HC2
      Karena prosesornya armhf, instalasinya benar-benar menyakitkan, tapi setelah mulai berjalan, semuanya bekerja dengan baik. Hanya saja lambat karena NIC 1Gb tunggal
      Saat itu tujuannya hanya untuk belajar
      [0] https://www.hardkernel.com/shop/odroid-hc2-home-cloud-two/
    • Konsep ini sudah bisa divalidasi dengan antarmuka modul komputasi SODIMM dari Nvidia
      Saya akan segera menerima dua ARM Turing RK1 7W, masing-masing menghasilkan 4GB/s lewat PCIe 3x4, dan papan klaster Turing Pi 2 bisa memasang 4 modul dalam form factor ITX
      Dengan total biaya 820 dolar, saya berharap mendapat lebih dari 3Gbps per watt
      Sejauh ini bottleneck-nya ada pada lane PCIe. SSD 2TB seharga 90 dolar pun tertulis 7GB/s di PCIe 4x4, jadi saya belum melihat single-board computer sebagai solusi optimal
      Lini Ampere Altra tampaknya mendukung PCIe 4x128 pada 40W, jadi blade 1U dengan jaringan 100G bisa menarik
      Namun, bahkan di homelab pun saya melihat banyak bug terkait ARM dan optimasi yang hilang, jadi mungkin sulit mengatakan solusi seperti ini sudah siap untuk datacenter
    • Dengan makin banyaknya switch 100Gbps murah dan antarmuka 100Gbps, 10Gbps makin terlihat usang
      Untuk membenarkan konfigurasi Ceph dengan antarmuka 10Gbps saat ini, ukurannya harus benar-benar kecil dan sangat murah
      Pada skala sekecil itu, kemungkinan lebih baik menaruh penyimpanan NVMe lokal di tiap server
    • Jika membuat perhitungan kasar yang agak aneh, klaster ini memproses sekitar 0,8Gbps per watt
      Perhitungan kasarnya seperti 1TB/s × 8 bit/byte × 1024GB/TB ÷ 34 node ÷ 300W
      Sistem ARM yang sangat efisien seperti Mac mini baru memakai sekitar 10W dalam penggunaan interaktif dan bisa menangani jaringan 10Gbps, jadi kira-kira 1Gbps per watt dari sisi data
      Artinya, secara kasar klaster di artikel asli berada pada tingkat bit/detik/watt yang mirip dengan sistem ARM yang sangat efisien
      Saya tidak yakin memakai node kecil akan benar-benar meningkatkan efisiensi, malah mungkin lebih mahal. Performa per watt server kuat zaman sekarang cukup bagus
      Bagaimanapun, ini adalah perangkat lunak open-source yang berjalan di hardware umum, jadi orang bisa mencobanya sendiri dengan beberapa ratus dolar
    • Sumber utama inefisiensi dalam struktur ini tampaknya adalah kontroler NVMe
      Jika sistem operasi dan perangkat NVMe berjauhan, kontroler harus menebak maksud request lalu menangani batching dan wear leveling sebaik mungkin, sehingga secara alami muncul inefisiensi
      Fitur baru FDP(flexible data placement) adalah upaya untuk mengatasi ini dengan memberi sistem operasi lebih banyak kendali
      Yang terbaik adalah menariknya ke sisi sistem operasi host, dan mengekspos flash semirip mungkin dengan “array transistor bodoh berukuran raksasa yang terpasang sebagai perangkat PCIe”
      Jika lapisan abstraksi dihilangkan, rasanya kita bisa menyusun unit hardware seperti Atom yang punya NIC 100Gbps terintegrasi dan jumlah flash yang sebanding untuk mendapatkan paralelisme sistem yang diinginkan

  • Pasti pernah ada satu titik dalam sejarah ketika total data digital yang tersimpan di seluruh dunia pertama kali mencapai 1TiB
    Hari itu hampir pasti terjadi dalam 60 tahun terakhir
    Namun sekarang, sebuah server milik organisasi yang cukup acak memindahkan data sebanyak itu setiap detik. Padahal bukan negara atau proyek riset supranasional

    • Saya teringat dulu pernah menghitung dan hasilnya menunjukkan PC desktop saya mungkin lebih kuat daripada gabungan semua komputer di Bumi sekitar tahun 1978
    • Setidaknya sudah lebih dari sekitar 20 tahun lalu. Saya ingat seorang sysadmin lama pernah bercerita tentang mengelola petabyte sebelum 2003

  • Artikel yang menarik. Kami menjalankan klaster storage Ceph untuk mempertahankan cache layer Docker
    Setelah pindah dari EBS ke Ceph, perbedaan throughput-nya sangat besar. Throughput tulis naik dari 146MB/s dan 3.000 IOPS menjadi 900MB/s dan 30.000 IOPS
    Bagian terbaiknya adalah ini hampir langsung bekerja begitu saja. Selain sesekali hal seperti filesystem trim, nyaris tidak perlu dirawat
    Ini peningkatan besar untuk sistem cache
    [0] https://depot.dev/blog/cache-v2-faster-builds

    • Hampir 10 tahun lalu saya melakukan hal yang sangat mirip. Untuk standar performa yang sama, biaya EBS lebih dari 10 kali lebih mahal daripada klaster Ceph di atas disk node
      Pada akhirnya kami pindah ke rack sendiri dan memangkas biaya lagi hampir menjadi sepersepuluh, lalu menjadi lebih bebas karena punya kapabilitas operasional internal
    • Saya penasaran apakah EBS di-host di bare metal. Ceph-nya di-host bagaimana—bare metal milik sendiri/sewaan, atau virtual machine EC2?
      Dari blognya saja tidak langsung jelas

  • Masalah terburuk yang saya alami dengan dynamic storage internal klaster bukanlah masalah I/O murni
    Masalahnya lebih pada software storage controller Kubernetes yang tidak menangani masalah dunia nyata dengan baik, misalnya ketika pod mati dan PVC tidak ter-attach sampai timeout yang sangat panjang selesai, sementara pod tetap berada dalam status ContainerCreating sampai kunci PVC dilepas
    Hal semacam ini terjadi di beberapa klaster yang memakai rook/ceph dan Longhorn

  • Saya penasaran apakah ada yang pernah menjalankan Ceph di homelab. Terakhir kali saya melihatnya, kebutuhan hardware-nya cukup besar

    • Kebutuhannya masih besar. Dari pengalaman pernah men-deploy untuk produksi maupun homelab, kalau tujuannya bukan sekadar menambah pengalaman atau menyiapkan demo, sebaiknya tidak usah
      Saat berjalan dengan baik, hasilnya luar biasa, tetapi begitu ada masalah, bisa menjadi sumber sakit kepala besar
      Kalau memang tertarik pada distributed storage itu sendiri, ada pilihan yang lebih baik untuk konfigurasi homelab
      seaweedfs selama bertahun-tahun sangat stabil baik di skala kecil maupun sangat besar, dan kami benar-benar memindahkan konfigurasi Ceph produksi ke sana
      Saat berada di dunia Kubernetes, Longhorn juga stabil
      GlusterFS juga masih oke jika sejak awal tahu apa yang harus ditanggung
    • Pernah saya pakai; web UI, object storage, dan file storage-nya sangat keren
      Namun sangat sulit mendapatkan performa yang layak, dan di cluster kecil metadata daemon bisa cukup mudah berhenti
      Akhirnya, setelah tidak terasa menyenangkan lagi, saya kembali ke ZFS di satu mesin
    • Saya punya pengalaman memakai Ceph baik di lingkungan kerja maupun lingkungan yang mirip homelab
      Pertama-tama, perlu diingat bahwa Ceph adalah sistem storage terdistribusi, jadi asumsi dasarnya adalah memakai beberapa node
      Untuk belajar, semuanya bisa divirtualisasi di satu mesin, tetapi akan jauh lebih baik jika ada mesin fisik terpisah
      Seperti ZFS, Ceph lebih menyukai akses fisik langsung ke disk
      Selain itu, dibutuhkan koneksi jaringan yang cukup baik. Menurut saya, inilah bagian yang biasanya terbayang orang ketika memikirkan kebutuhan hardware Ceph yang tinggi
      Idealnya minimal 10GbE, dan jika menginginkan performa lebih tinggi, dibutuhkan lebih dari itu. Khususnya untuk pekerjaan seperti backfill, traffic jaringan bisa sangat besar
      Jika bisa mendapatkan perangkat homelab dengan murah, 25Gbps juga bagus; 50Gbps secara teknis mendekati jalan buntu, sedangkan 100Gbps bekerja dengan baik
      Meski begitu, untuk homelab, mini PC murah atau NUC dengan 10GbE pun sudah cukup berjalan, dengan performa yang dapat diterima dan manfaat belajar yang memadai
      Ceph bisa dipasang langsung di bare metal, atau jika ingin menempuh jalur Kubernetes di homelab, bisa memakai Rook(https://rook.io/)
      Semoga membantu, dan kalau ada pertanyaan tambahan, silakan beri tahu
    • Ada tulisan blog dari pihak Ceph tentang memasang Ceph di beberapa Raspberry Pi 4
      Pada level itu, jelas sulit disebut hardware besar
      [1] https://ceph.io/en/news/blog/2022/install-ceph-in-a-raspberr...
    • Saya menjalankan Ceph di lab saya. Memang memakai CPU cukup banyak, tetapi kalau bersedia memakai jaringan cepat, ia berjalan dengan baik
      Minimal 10Gb, sebaiknya 40Gb atau lebih, dan jika memakai disk berputar, ada baiknya beberapa node masing-masing memiliki setidaknya 6 disk
      Jika semuanya SSD, kemungkinan besar jumlah disk per node bisa jauh lebih sedikit

  • Saya menghitungnya karena ingin melihat bagaimana 1 TiB/s dibandingkan dengan batas teoretis perangkat keras sebenarnya
    Klaster ini terdiri dari 68 node, dan tiap node adalah Dell PowerEdge R6615(https://www.delltechnologies.com/asset/en-us/products/server...)
    Konfigurasi yang dipakai adalah R6615 dengan 10 bay drive U.2, dan link U.2 mentransfer data melalui 4 lane PCIe generasi ke-4. Satu lane PCIe adalah 16 Gbit/s, dan berkat encoding 128b-132b overhead-nya sekitar 3%, jadi bisa diabaikan
    Jadi bandwidth link maksimum untuk satu link U.2 adalah 16×4=64 Gbit/s, atau 8 Gbyte/s. Namun drive U.2 NVMe yang digunakan, Dell 15.36TB Enterprise NVMe Read Intensive AG, tampaknya punya throughput baca 7 Gbyte/s(https://www.serversupply.com/SSD%20W-TRAY/NVMe/15.36TB/DELL/...), jadi link U.2 8 Gbyte/s bukan bottleneck
    Karena ada 10 drive U.2 per node, tiap node bisa menghasilkan I/O baca lokal hingga 10×7=70 Gbyte/s
    Namun bandwidth jaringan tiap node hanya 200 Gbit/s (2×100GbE Mellanox ConnectX-6), yaitu 25 Gbyte/s. Artinya pada pembacaan jarak jauh, kemampuan drive 70 Gbyte/s tidak bisa dimanfaatkan penuh dan jaringan menjadi bottleneck
    Dengan asumsi tidak ada bottleneck jaringan tambahan, 68 node dapat menyediakan pembacaan lewat jaringan sebesar 68×25=1700 Gbyte/s. Penulis sebenarnya membenchmark 1 TiB/s, tepatnya 1025 GiB/s=1101 Gbyte/s, jadi sekitar 65% dari maksimum teoretis 1700 Gbyte/s
    Ini cukup bagus, tetapi jika semua node bisa sepenuhnya memenuhi link jaringan 200 Gbit/s secara bersamaan, secara teori masih bisa sedikit lebih baik
    Saat membaca keseluruhan artikel, saya mendapat kesan bahwa kompleksitas Ceph memberi beban cukup besar pada CPU. Cukup mengejutkan bahwa hanya karena modul tidak dikompilasi dengan -O2 (“Fix Three” yang ditautkan penulis: https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1894453), pada workload I/O murni “sebagian workload bisa menjadi hingga 5 kali lebih lambat”(https://bugs.gentoo.org/733316)
    Aneh juga melihat thread OSD membuang CPU secara berlebihan karena memegang spinlock IOMMU. Saya setuju dengan kesimpulan bahwa model threading OSD tidak optimal
    Benchmark sintetis 100% baca yang relatif sederhana seharusnya tidak sampai memunculkan kontensi threading. Kalau bagian arsitektur perangkat lunak Ceph itu dirancang dengan baik. Ini masalah yang bisa diperbaiki, jadi saya berharap para developer Ceph menaikkan prioritasnya

    • Saya ingin menambahkan bahwa saya belum pernah melihat masalah IOMMU di Ceph
      Di lab Ceph upstream ada perangkat generasi sebelumnya dari sasis 1U Dell yang sama dengan prosesor AMD Rome, dan pada skala serupa, sekitar 30 OSD, perangkat itu menghasilkan performa mirip tanpa mengalami masalah ini
      Pelanggan mengatakan mereka pernah melihat masalah ini sebelumnya di data center mereka, dan berharap bisa menemukan penyebabnya bersama AMD
      Musim panas lalu saya sempat melakukan sedikit pekerjaan untuk memperkuat sementara model threading lama OSD. Misalnya double buffering handoff antara async msgr dan thread pekerja, serta adaptive thread wakeup
      Dalam kondisi berbeban, ini bisa sangat meningkatkan performa dan efisiensi, tetapi ada konsekuensi berupa latensi yang meningkat pada beban rendah. Secara default, Ceph sangat agresif membangunkan thread ketika ada I/O baru masuk ke shard tertentu
      Saya berdiskusi dengan satu developer inti lain, dan kami berdua menyimpulkan bahwa perombakan total kode threading lebih masuk akal
    • Benchmark ini adalah I/O acak. Disk tersebut “hanya” sedikit di atas 1 juta IOPS baca acak 4K, yang jika dikonversi sekitar 5 GiB/s
      Dengan 320 OSD, hasilnya sekitar 1,6 TiB/s
      Setidaknya itu angka yang saya temukan. Memang tidak banyak ulasan disk NVMe enterprise seperti ini
      Meski begitu, angkanya tampak cocok dengan NIC. Pada skala ini, sebagian besar workload kemungkinan terlihat seperti I/O acak di lapisan storage
    • Saya rasa overhead PCIe TLP dan perintah NVMe menjelaskan selisih antara 7 GB/s dan 8 GB/s

  • Yang mengejutkan adalah mengapa memilih node 1U, yang lebih sulit didinginkan, dengan konfigurasi 10 SSD/2×100Gb NIC
    Jika memakai node 2U dengan 24 SSD dan 2×200Gb atau 400Gb NIC, bottleneck jaringan bisa dihilangkan, dan konsumsi daya juga bisa dikurangi berkat kipas yang lebih besar dan lebih lambat serta jumlah paket CPU yang lebih sedikit. Jumlah core per soket juga bisa saja lebih banyak
    Jika jumlah node berkurang, dampak kegagalan memang menjadi lebih besar, tetapi sekitar 34 node sepertinya bukan masalah yang terlalu besar
    Dengan node yang lebih sedikit, mungkin juga bisa membangun jaringan yang lebih datar dengan sekitar 4 switch

    • Seperti yang Anda katakan, dampak kegagalan adalah faktor utama, dan umumnya membuat patching serta penggantian hardware tidak terlalu membebani
      Rak dan switch sudah ada dan juga banyak digunakan untuk tujuan lain, jadi ruang fisik tambahan karena Ceph sangat kecil :)