Belajar Ceph - High Availability & Fault Tolerance

#Pendahuluan

Selamat datang di episode 12 series Belajar Ceph! Setelah observability di episode 11, sekarang saatnya memastikan cluster kalian bisa bertahan ketika hal buruk terjadi. Episode ini membahas high availability & fault tolerance — desain dan operasi yang membuat Ceph tetap melayani meskipun ada komponen yang gagal.

Filosofi utama Ceph adalah tidak ada komponen tunggal yang menjadi titik mati. MON, MGR, MDS, dan RGW semua dirancang untuk redundansi, dan data direplikasi melintasi failure domain yang berbeda. Tetapi high availability bukan hanya soal desain — dia juga soal bagaimana kalian merespons kegagalan saat terjadi.

Di akhir episode ini kalian akan paham cara membuat komponen redundan, mengatur failure domain CRUSH dengan benar, menangani OSD failure dan penggantian disk, serta memahami operasi heal, backfill, dan scrub. Mari kita mulai.

#Redundansi Komponen Cluster

#Redundansi MON

MON menjaga state cluster dan butuh quorum mayoritas. Dengan tiga MON, cluster tetap berfungsi selama maksimal satu MON mati. Redundansi diatur dengan menempatkan MON di host yang berbeda:

ceph orch apply mon node1,node2,node3
ceph mon stat

ceph orch apply mon menempatkan satu MON per host. ceph mon stat menampilkan daftar MON dan apakah quorum terbentuk. Jangan pernah menaruh dua MON di host yang sama karena satu host mati bisa langsung menghancurkan quorum.

#Redundansi MGR, MDS, dan RGW

MGR berjalan dalam mode active-standby: satu MGR aktif melayani dashboard dan module, sisanya standby siap menggantikan. MDS aktif bisa berjumlah banyak sekaligus untuk CephFS (active-active, lihat episode 6). RGW bersifat stateless sehingga mudah di-scale dan diletakkan di belakang load balancer.

ceph orch ps
ceph mgr stat
ceph fs status myfs

ceph orch ps menampilkan semua daemon beserta host dan statusnya. Pastikan setidaknya ada satu MGR standby, MDS standby sesuai rank, dan lebih dari satu RGW jika lalu lintas object storage penting.

#CRUSH Failure Domains dan Isolasi

#Failure Domain di Level Host

Failure domain menentukan batas minimal jarak antar replika. Default Ceph memakai host: dua replika tidak akan pernah menempati host yang sama. Untuk skala yang lebih besar, naikkan ke rack atau bahkan datacenter:

ceph osd crush rule dump replicated_rule
ceph osd tree

ceph osd crush rule dump menunjukkan struktur rule termasuk type host. ceph osd tree menampilkan hierarki yang sebenarnya. Jika semua OSD cluster ada di satu rack, failure domain rack tidak memberikan perlindungan ekstra.

#Mengatur Hierarki di CRUSH Map

Untuk memanfaatkan failure domain di level lebih tinggi, bangun hierarki yang benar di CRUSH map:

ceph osd crush add-bucket rack-a rack
ceph osd crush move node1 rack=rack-a
ceph osd crush move node2 rack=rack-a

ceph osd crush add-bucket membuat bucket bertipe rack, dan ceph osd crush move memasang host ke dalamnya. Setelah hierarki rapi, buat rule baru yang memakai failure domain rack agar replika tersebar antar rack.

#Isolasi Device

Isolasi juga berlaku pada level device: pastikan replika tidak menempati disk yang secara fisik berada di enclosure yang sama. Pada hardware yang sensitif, gabungkan hierarki host dengan bucket tambahan seperti chassis agar dua disk dalam satu chassis tidak membawa replika yang sama.

#Menangani OSD Failure dan Penggantian Disk

#Deteksi Awal dan Respons

Saat OSD down, Ceph otomatis menandainya dan mulai memindahkan data untuk mempertahankan jumlah replika. Respons pertama adalah memahami penyebab: cek log, cek disk, dan cek hardware:

ceph osd tree
ceph osd perf
journalctl -u ceph-osd@3 --since "30 min ago"

ceph osd tree menunjukkan OSD yang down. Baca log OSD yang bersangkutan untuk melihat apakah ini masalah disk, network, atau proses. Jangan langsung menghapus OSD sebelum mengetahui penyebabnya.

#Penggantian Disk dengan Aman

Jika disk rusak, ganti dengan prosedur terkendali. Untuk OSD yang masih bisa didecommission secara graceful:

ceph osd out osd.3
ceph osd wait-for-active-clean --timeout 1800

ceph osd out menandai OSD agar datanya dipindahkan. Tunggu sampai cluster kembali active+clean sebelum mematikan OSD. Untuk OSD yang sudah tidak bisa diakses sama sekali, langsung lanjut ke proses destroy dan ganti disk di hardware.

#Menambahkan OSD Pengganti

Setelah disk baru terpasang, tambahkan OSD baru. cephadm akan mendeteksi device baru dan bisa mendeploy otomatis jika --all-available-devices aktif, atau secara manual:

ceph orch daemon add osd node2:/dev/sdd
ceph osd tree

OSD baru masuk dengan ID baru dan cluster mulai menyeimbangkan ulang. Tidak ada operasi yang harus menghentikan layanan — itulah keuntungan dari failure domain dan replikasi yang dirancang dengan baik.

#Heal, Backfill, dan Scrub Operations

#Heal dan Self-Healing

Konsep self-healing adalah inti Ceph: ketika sebuah OSD gagal, cluster mendeteksi kekurangan replika dan segera memulai pemulihan tanpa intervensi manusia. Proses ini berjalan bertahap agar tidak membebani cluster, dan kalian bisa memantaunya lewat status PG:

ceph pg stat
ceph -w

ceph -w menampilkan event real-time termasuk progres backfill dan recovery. Perhatikan istilah recovering, backfilling, dan degraded — semuanya normal saat cluster sedang menyembuhkan diri.

#Backfill vs Recovery

Backfill adalah pengisian ulang data ke OSD yang baru atau yang tertinggal jauh, sementara recovery adalah sinkronisasi objek yang tidak konsisten pada OSD yang sudah ada. Keduanya berbagi bandwidth, sehingga pengaturan seperti osd_max_backfills dari episode 9 tetap relevan.

#Scrub dan Deep Scrub

Scrub adalah verifikasi berkala yang membandingkan metadata dan data antar replika untuk mendeteksi kerusakan diam-diam. Deep scrub membaca seluruh data fisik untuk memverifikasi checksum. Jadwalkan scrub secara rutin:

ceph config set osd osd_scrub_begin_hour 2
ceph config set osd osd_scrub_end_hour 5
ceph osd deep-scrub all

osd_scrub_begin_hour dan osd_scrub_end_hour membatasi scrub pada jam sepi. ceph osd deep-scrub all memicu deep scrub manual saat kalian mencurigai kerusakan data.

#Penutup

Di episode ini kalian sudah memahami cara membuat cluster Ceph tahan terhadap kegagalan: memastikan redundansi MON, MGR, MDS, dan RGW, mengatur failure domain CRUSH di level host dan rack, menangani OSD failure dengan penggantian disk yang terkendali, serta memahami operasi heal, backfill, dan scrub untuk menjaga integritas data.

Inti yang harus dibawa pulang:

• MON butuh quorum mayoritas; tempatkan di host yang berbeda.
• MGR aktif-standby, MDS active-active, dan RGW stateless dan mudah di-scale.
• Failure domain menentukan jarak minimal antar replika.
• Keluarkan OSD dengan ceph osd out dan tunggu active+clean sebelum mengganti disk.
• Backfill mengisi OSD baru, recovery menyinkronkan objek yang tidak konsisten.
• Scrub dan deep scrub menjaga integritas data dari kerusakan diam-diam.

Di episode 13 selanjutnya kita akan membahas multi-site & geo-replication — arsitektur RGW multisite dan replikasi data, konfigurasi zonegroups, routes, dan failover, use case untuk object storage global, serta model konsistensi dan sinkronisasi lintas site. Bersiap membawa cluster kalian ke level geografis!