Belajar Ceph - Performance Tuning & Data Placement

#Pendahuluan

Selamat datang di episode 9 series Belajar Ceph! Cluster kalian sudah berjalan dengan client yang terhubung. Sekarang pertanyaannya bergeser dari "apakah berfungsi" menjadi "seberapa cepat dan efisien". Episode ini membahas performance tuning & data placement — seni membuat cluster Ceph melayani workload lebih cepat tanpa menambah hardware.

Performa Ceph ditentukan oleh banyak lapisan sekaligus: cara OSD menyimpan data di disk, konfigurasi jaringan antar node, jumlah placement group, hingga bagaimana data ditempatkan berdasarkan kelas device. Mengoptimalkan satu lapisan saja jarang cukup; yang penting adalah menemukan bottleneck yang paling membatasi.

Di akhir episode ini kalian akan paham cara mengoptimalkan penyimpanan Bluestore, memisahkan traffic public dan cluster network, men-tune PG dan device classes, serta membaca metrik throughput dan latency untuk membuktikan perbaikan. Mari kita mulai.

#Optimasi OSD dengan Bluestore

#Struktur Bluestore dan DB/WAL

Bluestore adalah backend penyimpanan default Ceph yang menulis data langsung ke raw device. Secara internal, Bluestore memakai tiga area: data (blok data sebenarnya), DB (metadata seperti object map dan omap), serta WAL (write-ahead log untuk durabilitas). Memisahkan DB/WAL ke device yang lebih cepat, seperti NVMe SSD, memberikan peningkatan besar pada latency.

ceph device ls
ceph osd tree

ceph device ls menampilkan perangkat fisik yang terdaftar. Pada deployment cephadm, pemisahan DB/WAL bisa diatur saat pembuatan OSD dengan menunjuk device pendamping via ceph orch daemon add osd.

#Mengatur Parameter Bluestore

Beberapa parameter Bluestore yang sering dit-tune adalah ukuran cache dan mode cache:

ceph config set osd bluestore_cache_size_hint 4G
ceph config set osd bluestore_cache_mode write_around

bluestore_cache_size_hint mengalokasikan cache RAM per OSD. Nilai yang terlalu besar bisa memicu OOM karena cache dialokasikan per OSD di satu node. Mulai dari 1-4 GB per OSD dan pantau memory pressure.

#Tips Penyimpanan Praktis

Aturan praktis yang banyak dipakai operator: taruh DB dan WAL di SSD/NVMe, data di HDD besar, dan pastikan tidak ada OSD yang berbagi device DB dengan terlalu banyak OSD lain. Untuk seluruh workload dengan latency ketat, pertimbangkan cluster all-flash.

#Network Tuning dan Pemisahan Public/Private

#Public vs Cluster Network

Ceph membedakan public network (client ke MON/OSD/RGW) dan cluster network (traffic internal: replikasi, heartbeat, recovery, backfill). Pemisahan ini mencegah backfill besar menyaingi traffic client di NIC yang sama.

ceph config set mon public_network 192.168.100.0/24
ceph config set mon cluster_network 10.0.0.0/24

public_network dan cluster_network bisa berupa beberapa subnet yang dipisahkan koma. Setelah mengubahnya, daemon akan memakai NIC yang sesuai untuk masing-masing jenis traffic.

#Jumbo Frame dan Offload

Pada hardware yang mendukung, aktifkan jumbo frame (MTU 9000) di seluruh path network dan pastikan NIC offload tidak dinonaktifkan:

ip link set dev enp3s0 mtu 9000

MTU 9000 mengurangi overhead paket dan meningkatkan throughput untuk transfer besar. Verifikasi MTU konsisten di seluruh node, karena ketidakcocokan MTU justru memicu fragmentasi dan menurunkan performa.

#Pool Placement Groups, CRUSH Tuning, dan Device Classes

#Jumlah Placement Group

Jumlah PG yang tepat menyeimbangkan granularity rebalance dengan beban CPU. Terlalu sedikit PG membuat distribusi tidak merata; terlalu banyak membebani MON dan OSD saat peering.

ceph osd pool autoscale-status
ceph pg stat

ceph osd pool autoscale-status menampilkan jumlah PG saat ini dan target yang disarankan autoscaler. Untuk workload yang stabil, set pg_autoscale_mode pool ke on dan biarkan Ceph menyesuaikan.

#Device Classes untuk Heterogeneous Storage

Device class memungkinkan Ceph membedakan HDD, SSD, dan NVMe dalam penempatan data. Ini berguna untuk menempatkan metadata yang sensitif latency di SSD sementara data besar di HDD:

ceph osd crush class ls
ceph osd crush class list

ceph osd crush class ls menampilkan class yang sudah ada. Saat OSD dibuat, Ceph otomatis menandai class berdasarkan device. Untuk menempatkan pool tertentu di SSD saja, buat CRUSH rule baru berbasis class ssd dan tetapkan ke pool — detailnya di episode 15.

#Memantau Throughput, Latency, dan Backfill

#Metrik Performa dengan ceph perf

Ceph menyediakan alat untuk melihat counter performa daemon secara real-time:

ceph osd perf
ceph daemon osd.0 perf dump

ceph osd perf menampilkan commit latency per OSD, sedangkan ceph daemon osd.0 perf dump mengeluarkan seluruh counter seperti osd_op_latency dan osd_op_w_process_latency. Kedua nilai ini adalah indikator awal bottleneck.

#Throughput dengan rados bench

Untuk benchmark, Ceph punya alat rados bench yang menulis, membaca, dan menghapus objek dalam satu pool:

rados -p bench-pool bench 60 write --no-cleanup
rados -p bench-pool bench 60 seq

rados bench mengukur IOPS dan bandwidth pada pool yang dipilih. Jalankan saat cluster idle untuk mendapatkan baseline, lalu bandingkan setelah tuning. Jangan lupa menghapus data benchmark jika tidak diperlukan.

#Mengamati Perilaku Backfill

Backfill adalah proses memindahkan data saat OSD baru masuk atau keluar. Backfill yang terlalu agresif bisa menekan performa normal:

ceph config set osd osd_max_backfills 2
ceph config set osd osd_backfill_full_ratio 0.9

osd_max_backfills membatasi jumlah backfill paralel per OSD. Nilai default 1 sudah konservatif; naikkan saat cluster idle dan turunkan saat workload padat. Pantau progres backfill dengan ceph pg dump | grep backfill.

#Penutup

Di episode ini kalian sudah memahami cara men-tune performa cluster Ceph: mengoptimalkan Bluestore dengan pemisahan DB/WAL dan cache, memisahkan public dan cluster network dengan MTU jumbo frame, menyesuaikan PG dan device classes untuk heterogeneous storage, serta memantau throughput, latency, dan perilaku backfill dengan metrik yang bisa diukur.

Inti yang harus dibawa pulang:

• Bluestore memisahkan data, DB, dan WAL; taruh DB/WAL di SSD untuk latency lebih rendah.
• Pisahkan public dan cluster network agar backfill tidak menyaingi traffic client.
• PG autoscaler membantu menjaga jumlah placement group tetap ideal.
• Device classes memungkinkan penempatan data berbeda antara HDD dan SSD.
• ceph osd perf dan rados bench adalah alat ukur awal performa.
• Batasi osd_max_backfills agar recovery tidak mencekik workload normal.

Di episode 10 selanjutnya kita akan membahas security & access control — autentikasi CephX dan manajemen key, RBAC untuk user RGW dan capabilities, keamanan jaringan dengan firewall dan TLS, serta praktik deployment aman untuk storage multi-tenant. Siapkan pola pikir security-first kalian!