Ceph: Perjalanan Menuju 1 TiB/s

Ceph: Perjalanan Menuju 1TiB/s

• Artikel yang membahas perjalanan peningkatan performa klaster Ceph, menceritakan bagaimana kecepatan pemrosesan data 1TiB/s berhasil dicapai melalui proses debugging yang panjang dan optimasi performa.
• Membagikan berbagai masalah teknis dan solusinya yang muncul saat perusahaan bernama Clyso membantu membangun klaster Ceph 10 petabyte berbasis NVMe.
• Jaringan milik pelanggan sangat cepat, termasuk salah satu konfigurasi Ethernet tercepat.

Ucapan terima kasih

• Menyampaikan terima kasih kepada pelanggan Clyso, yang berkat kerja sama mereka pengalaman ini bisa dibagikan kepada komunitas Ceph.
• Juga berterima kasih kepada IBM/Red Hat dan Samsung yang menyediakan perangkat keras yang digunakan untuk pengujian perbandingan.
• Ucapan terima kasih juga disampaikan kepada para kontributor Ceph atas upaya mereka menjadikan Ceph perangkat lunak yang luar biasa.

Konfigurasi klaster

• Pelanggan semula mengusulkan 34 node 2U dual-socket yang tersebar di 17 rak, tetapi Clyso mengusulkan berbagai konfigurasi dengan node yang lebih kecil.
• Pada akhirnya dipilih arsitektur Dell untuk menekan biaya, sekaligus memberikan throughput memori yang lebih cepat, lebih banyak sumber daya CPU, dan throughput jaringan yang lebih tinggi.
• Dampak terhadap pemulihan klaster saat node gagal juga berkurang hingga setengahnya.

Konfigurasi pengujian

• Menggunakan CBT untuk menerapkan klaster Ceph sementara dan menjalankan pengujian FIO.
• Menggunakan pengujian FIO berbasis library untuk membagi klaster menjadi unit-unit kecil dan membandingkannya dengan hasil sebelumnya.
• Menguji replikasi 3X dan erasure coding 6+2, serta message version 2 dalam mode encrypted dan secure.

Catatan tentang jumlah PG

• Menguji secara eksperimental dampak jumlah PG terhadap performa.
• Jumlah PG yang tinggi dapat memberikan dampak positif pada performa, tetapi di lingkungan produksi nyata hal ini perlu dipertimbangkan bersama pengaturan lainnya.

Kesulitan di awal

• Setelah pertama kali login ke perangkat keras, mereka kesulitan memecahkan masalah karena performanya lebih rendah dari yang diharapkan.
• Pengujian performa awal terlihat baik, tetapi penurunan performa muncul saat pengujian menggunakan beberapa OSD.

Perilaku aneh

• Saat menjalankan berbagai kombinasi pengujian OSD, ditemukan pola aneh pada performa.
• Diamati bahwa sistem mengalami penurunan performa setelah pengujian multi-OSD, lalu pulih kembali beberapa jam kemudian.

Tiga solusi

• Sedikit meningkatkan performa dengan mengatasi masalah latensi yang disebabkan peralihan CPU c-state.
• Meningkatkan performa secara signifikan dengan menonaktifkan IOMMU.
• Menggandakan performa penulisan acak 4K dengan memperbaiki masalah compile flag RocksDB.

Minggu pertama 2024

• Pada hari pertama tahun baru, fokus pada pengujian performa terganggu karena insiden besar di klaster lain.
• Pada hari Jumat, pengujian performa dilanjutkan dan dikonfirmasi bahwa klaster tetap bekerja dengan baik bahkan di bawah beban tinggi.

Senyum takdir

• Seiring hasil pengujian performa membaik, dikonfirmasi bahwa klaster dapat diskalakan secara linear.
• Pada klaster yang terdiri dari 63 node, berhasil dicapai kecepatan pemrosesan data 635GiB/s.

Death Star yang sebagian berfungsi

• Karena kekurangan node klien, node OSD harus berbagi dengan proses FIO.
• Bahkan dengan konfigurasi ini, performa yang dicapai mendekati 950GiB/s.

Mencapai 1TiB/s

• Dengan menyesuaikan jumlah shard OSD dan jumlah thread messenger, kecepatan pemrosesan data 1TiB/s berhasil dicapai.

Tidur; erasure coding

• Setelah diuji dengan replikasi 3X, klaster dikonfigurasi ulang ke erasure coding 6+2 yang akan digunakan pelanggan, lalu diuji kembali.
• Performa baca mencapai lebih dari 500GiB/s, dan performa tulis hampir menyentuh 400GiB/s.

Pendapat GN⁺:

1. Artikel ini menjelaskan secara rinci proses optimasi performa klaster Ceph, dan memberikan wawasan teknis melalui contoh pencapaian performa tinggi lewat proses pemecahan masalah yang kompleks.
2. Menunjukkan bagaimana kolaborasi dengan pelanggan, upaya para kontributor komunitas, serta berbagai strategi optimasi perangkat keras dan perangkat lunak dapat menghasilkan pencapaian besar di dunia nyata.
3. Tulisan ini memberikan informasi yang bermanfaat tidak hanya bagi para profesional yang menangani sistem penyimpanan data berskala besar, tetapi juga bagi teknisi yang tertarik pada optimasi performa.

[GN⁺]

Komentar Hacker News

• Kabar pencapaian 1TB/s di CERN dan sejarah Ceph
  • Seorang pengguna menyebut bahwa CERN mencapai kecepatan 1TB/s melalui klaster EOS, dan menjelaskan bahwa klaster ini terutama menggunakan HDD serta memiliki lebih banyak node. Ia juga membagikan sejarah menarik bahwa Ceph diciptakan di Dreamhost karena kebutuhan internal, lalu kemudian diakuisisi oleh Redhat.
• Pengalaman mantan pemimpin teknis dan ketertarikan pada Ceph
  • Seorang pengguna mengenang pengalamannya bekerja sebagai pemimpin teknis di Cisco, menyiapkan Kubernetes di bare metal, dan bereksperimen dengan GlusterFS serta Ceph, sambil mengatakan bahwa ia menikmati eksperimen tersebut. Ia juga memuji tulisan itu karena ditulis dengan baik.
• Usulan untuk mengecilkan ukuran node
  • Seorang pengguna menunjukkan bahwa konsumsi energi per node pada sistem saat ini tinggi, dan mengusulkan perlunya upaya rekayasa untuk mengecilkan ukuran node. Menurutnya, dengan begitu lebih sedikit node pun sudah cukup, dan dampak satu kegagalan tunggal terhadap 10 disk dapat dikurangi.
• Sudut pandang historis tentang jumlah penyimpanan data digital
  • Seorang pengguna menyebut bahwa dalam 60 tahun terakhir pasti pernah ada hari ketika untuk pertama kalinya total 1TiB data digital tersimpan di seluruh dunia, dan mengungkapkan kekagumannya bahwa sekarang jumlah data sebesar itu bisa dipindahkan setiap detik.
• Pengalaman peningkatan performa cache Docker melalui klaster Ceph
  • Seorang pengguna membagikan pengalaman mengoperasikan klaster penyimpanan Ceph untuk mempertahankan cache layer Docker, dan mengatakan bahwa throughput meningkat drastis setelah beralih dari EBS ke Ceph. Pengguna ini juga menyebut bahwa Ceph hampir tidak memerlukan perawatan.
• Masalah perangkat lunak pengontrol penyimpanan di dalam Kubernetes
  • Seorang pengguna mengatakan bahwa masalah terbesar terkait dynamic storage di dalam Kubernetes bukan pada I/O, melainkan muncul ketika perangkat lunak pengontrol penyimpanan menghadapi masalah nyata. Secara khusus, ia mengalami masalah saat memakai rook/ceph dan Longhorn, di mana PVC baru terpasang setelah waktu yang sangat lama.
• Analisis performa 1 TiB/s dibanding batas teoretis perangkat keras
  • Seorang pengguna menganalisis bagaimana performa 1 TiB/s dibandingkan dengan batas teoretis perangkat keras, dan menunjukkan bahwa jaringan sedang menjadi bottleneck. Ia juga menyimpulkan bahwa kompleksitas Ceph membebani CPU secara signifikan, dan model threading OSD belum optimal, seraya berharap ada perbaikan.
• Permintaan perbandingan Ceph dengan engine object storage lain
  • Seorang pengguna meminta perbandingan dan benchmark antara Ceph dengan engine object storage lain seperti MinIO dan Garage.
• Pertanyaan tentang kecocokan Ceph untuk penyimpanan basis data transaksional dan latensi IO
  • Seorang pengguna bertanya apakah Ceph cocok untuk penyimpanan basis data transaksional dan bagaimana latensi IO-nya, sambil menyatakan keinginan untuk beralih ke file system murah yang bisa bersaing dengan sistem seperti cluster file system Oracle atau Veritas.