Belajar Ceph - Advanced Pool & CRUSH Strategies

#Pendahuluan

Selamat datang di episode 15 series Belajar Ceph! Sampai di episode ini kalian sudah menguasai pool dasar dan tuning performa. Sekarang kita masuk ke strategi yang lebih presisi: advanced pool & CRUSH strategies — kemampuan memanfaatkan hardware heterogen, mengisolasi workload, dan mengelola migrasi data dengan kendali penuh.

Tidak semua storage diciptakan sama. Dalam satu cluster, kalian bisa punya HDD besar untuk data dingin, SSD untuk metadata, dan NVMe untuk workload panas. CRUSH map adalah alat yang mengatur data mana yang boleh menempati device mana, sehingga setiap jenis hardware dipakai sesuai kekuatannya.

Di akhir episode ini kalian akan paham cara memakai device classes, menyusun CRUSH map rules, membangun tiering dan cache pools, mengisolasi performa antar workload, serta melakukan migrasi pool dan rebalancing dengan aman. Mari kita mulai.

#Device Classes dan CRUSH Map Rules

#Apa Itu Device Class

Device class adalah label yang otomatis melekat pada OSD berdasarkan jenis device: hdd, ssd, atau nvme. Label ini menjadi dasar rule CRUSH untuk menempatkan data hanya pada kelas device tertentu:

ceph osd crush class ls
ceph osd tree

ceph osd crush class ls menampilkan class yang tersedia. Saat OSD baru dibuat, Ceph mendeteksi device dan menandai class-nya secara otomatis. Untuk cluster heterogen, pastikan setiap OSD memiliki class yang benar.

#Membuat CRUSH Rule Berbasis Class

Rule CRUSH menentukan bagaimana data dipilih dari hierarki. Untuk menempatkan pool hanya di SSD:

ceph osd crush rule create-replicated ssd-fast \
  default host ssd
ceph osd pool set pool-ssd crush_rule ssd-fast

ceph osd crush rule create-replicated membuat rule bernama ssd-fast yang memakai failure domain host dan class ssd. Lalu ceph osd pool set crush_rule menetapkan rule tersebut ke pool.

#Cluster dengan Hardware Heterogen

Dengan device classes, satu cluster bisa menampung beberapa jenis device sekaligus tanpa saling mengganggu. Pool metadata ditempatkan di NVMe, pool data panas di SSD, dan pool arsip di HDD. Ini jauh lebih efisien dibandingkan memaksa semua data memakai kelas device yang sama.

#Tiering dan Cache Pools

#Konsep Cache Tier

Cache tiering menempatkan data panas di pool cepat dan memindahkannya ke pool lambat saat sudah dingin. Meskipun fitur tiering klasik di Ceph sudah deprecated, konsepnya tetap relevan dan bisa diimplementasikan ulang secara manual dengan device classes dan kebijakan pindah data.

ceph osd pool create hot 128
ceph osd pool set hot crush_rule nvme-fast
ceph osd pool create cold 128
ceph osd pool set cold crush_rule hdd-archive

ceph osd pool set crush_rule menunjuk pool hot ke rule NVMe dan cold ke rule HDD. Dengan skema ini, aplikasi bisa menulis ke pool yang sesuai atau memindahkan data antar pool saat suhu datanya berubah.

#Strategi Tiering Manual

Tiering manual dilakukan dengan proses rutin: object yang sering diakses dipindahkan ke pool panas, yang jarang diakses dipindahkan ke pool dingin. RGW bahkan mendukung lifecycle rule dengan StorageClass untuk memindahkan object antar pool secara otomatis — ini akan kita bahas di episode 17.

#Isolasi Performa untuk Workload Berbeda

#Pemisahan Pool per Workload

Workload dengan karakteristik berbeda sebaiknya tidak berbagi pool. Database membutuhkan latency konsisten, sedangkan backup toleran terhadap throughput rendah namun rakus kapasitas. Pemisahan pool memberikan kontrol untuk tuning yang berbeda: ukuran replika, PG, dan class device masing-masing.

ceph osd pool set pool-db crush_rule nvme-fast
ceph osd pool set pool-backup crush_rule hdd-archive
ceph osd pool set pool-backup size 2

ceph osd pool set size bahkan bisa berbeda antar pool. Pool database memakai replika penuh dan NVMe, sementara pool backup memakai HDD dan replika lebih sedikit untuk menghemat kapasitas.

#Memantau Isolasi

Untuk memastikan isolasi berjalan, pantau metrik per pool seperti latency dan IOPS. Jika latency pool database naik bersamaan dengan aktivitas backup, berarti isolasi device-nya belum cukup ketat — mungkin karena rule CRUSH masih menempatkan kedua pool pada device yang sama.

#Migrasi Pool dan Rebalancing

#Menambah atau Mengubah Rule

Saat hardware ditambah atau dikurangi, kalian mungkin perlu mengubah rule pool. Ini bisa diakukan tanpa downtime karena Ceph memindahkan data secara bertahap:

ceph osd pool set pool-arsip crush_rule hdd-archive
ceph status

Setelah crush_rule diubah, Ceph mulai memindahkan PG ke OSD yang sesuai rule baru. Pantau ceph status hingga semua PG active+clean dan tidak ada backfill yang tertunda.

#Rebalancing Setelah Menambah OSD

Saat OSD baru masuk, cluster menyeimbangkan ulang data agar semua OSD terpakai merata. Kecepatan rebalance bisa dikontrol:

ceph config set osd osd_max_backfills 4
ceph config set osd osd_recovery_max_active 8

osd_max_backfills dan osd_recovery_max_active mengontrol seberapa agresif Ceph memindahkan data. Untuk cluster yang sibuk, turunkan nilai ini saat jam kerja dan naikkan saat maintenance window.

#Penutup

Di episode ini kalian sudah memahami strategi lanjutan untuk pool dan CRUSH: memakai device classes untuk menempatkan data pada hardware yang tepat, menyusun CRUSH map rules berbasis class, membangun tiering dan cache pools untuk arsitektur hybrid, mengisolasi performa antar workload dengan pool yang terpisah, serta melakukan migrasi pool dan rebalancing dengan kendali penuh.

Inti yang harus dibawa pulang:

• Device class (hdd, ssd, nvme) menandai OSD secara otomatis.
• CRUSH rule berbasis class mengarahkan data ke kelas device tertentu.
• Tiering manual memindahkan data panas ke pool cepat dan dingin ke pool lambat.
• Pool terpisah per workload memungkinkan tuning dan replikasi yang berbeda.
• Mengubah crush_rule memicu migrasi data bertahap tanpa downtime.
• Kecepatan rebalance dikendalikan dengan osd_max_backfills dan recovery limits.

Di episode 16 selanjutnya kita akan membahas Ceph in Kubernetes & Cloud Native — Ceph CSI untuk RBD dan CephFS, integrasi Rook, OpenStack Cinder, dan ekosistem cloud native, perbandingan deploy Ceph di Kubernetes vs Ceph eksternal, serta pola orchestration storage dengan operator. Saatnya menjembatani Ceph dengan era cloud native!