Belajar Ceph - Operational Readiness & Runbooks

#Pendahuluan

Selamat datang di episode 19 series Belajar Ceph! Kemampuan teknis saja tidak cukup untuk mengoperasikan storage yang digunakan banyak tim. Yang membedakan operasional profesional dari sekadar mencoba-coba adalah kesiapan: runbook yang jelas, proses yang teruji, dan tim yang terlatih. Episode ini membahas operational readiness & runbooks.

Ketika cluster bermasalah di tengah malam, reaksi terbaik bukan mengingat-ngingat tutorial, melainkan membuka runbook yang sudah disiapkan dan mengikuti langkah-langkahnya. Runbook yang baik mengubah insiden yang menegangkan menjadi checklist yang bisa dieksekusi dengan tenang.

Di akhir episode ini kalian akan bisa menyusun runbook untuk skenario umum, menjalankan maintenance dan upgrade dengan aman, mempersiapkan prosedur recovery dan pelatihan tim, serta membangun dokumentasi operasional yang hidup. Mari kita mulai.

#Menyusun Runbook untuk Insiden

#Anatomi Runbook yang Baik

Runbook yang baik memiliki struktur tetap untuk setiap skenario: gejala, penyebab umum, langkah diagnosis, langkah mitigasi, dan kriteria selesai. Mulailah dengan skenario yang paling sering terjadi: cluster HEALTH_WARN, OSD down, PG stuck, latency tinggi, dan kapasitas menipis.

ceph status
ceph health detail
ceph osd tree

Tiga perintah di atas adalah pembuka standar diagnosis apa pun. ceph status memberi ringkasan, ceph health detail menjelaskan alasan warning, dan ceph osd tree memeriksa status OSD.

#Contoh Runbook: OSD Down

Ambil contoh runbook OSD down. Langkah-langkahnya:

1. Identifikasi OSD mana yang down dari ceph osd tree.
2. Periksa log OSD untuk penyebab: disk error, network, atau crash.
3. Jika hanya sementara, tunggu OSD naik kembali atau restart daemon.
4. Jika disk rusak, ikuti prosedur penggantian dari episode 12.
5. Verifikasi PG kembali active+clean.

Runbook semacam ini ditulis sekali, dipakai berulang, dan diperbarui setiap kali ada pelajaran baru dari insiden.

#Maintenance Window dan Upgrade

#Mengelola Maintenance Window

Maintenance memerlukan perencanaan: pilih jam sepi, beri tahu pemilik workload, dan pastikan tidak ada perubahan lain yang berjalan bersamaan. Untuk operasi yang memengaruhi banyak OSD, gunakan perintah yang mengurangi risiko:

ceph osd set noout

ceph osd set noout mencegah Ceph menandai OSD sebagai out saat restart karena maintenance, sehingga tidak terjadi rebalance data yang tidak perlu. Jangan lupa ceph osd unset noout setelah selesai.

#Rolling Upgrade

Upgrade Ceph dilakukan secara bertahap per daemon agar layanan tidak pernah berhenti penuh. Dengan cephadm, upgrade cukup ditrigger ke versi target:

ceph orch upgrade start --ceph-version 19.2.0
ceph orch upgrade status

ceph orch upgrade start melakukan rolling upgrade otomatis: MON dulu, lalu MGR, lalu OSD satu per satu. ceph orch upgrade status memantau progresnya. Selama upgrade, pantau health cluster dan siapkan rollback bila diperlukan.

#Disaster Recovery Procedures dan Training

#Prosedur Recovery yang Teruji

Prosedur disaster recovery hanya berarti jika sudah diuji. Simpan prosedur untuk setiap skenario utama: kehilangan satu node, kehilangan satu site (jika multisite), korupsi data, dan penghapusan tidak sengaja. Setiap prosedur merujuk pada runbook dan langkah verifikasi yang jelas.

ceph status
ceph health detail
ceph fs status myfs

ceph fs status memverifikasi bahwa filesystem CephFS pulih setelah recovery. Jadikan urutan verifikasi ini bagian dari akhir setiap prosedur recovery.

#Melatih Tim

Runbook yang tidak pernah dilatih akan gagal saat dipakai sungguhan. Jadwalkan sesi pelatihan berkala: game day simulation di mana salah satu anggota memutus sebuah OSD di environment staging, lalu tim mengikuti runbook untuk memulihkannya. Latihan ini mengungkap lubang di prosedur sebelum menjadi insiden nyata.

#Dokumentasi dan Knowledge Base Tim

#Dokumentasi yang Hidup

Dokumentasi operasional sebaiknya hidup bersama infraestruktur: arsitektur cluster, daftar pool dan rule, peta kredensial, kontak pemilik workload, dan change log. Simpan di tempat yang bisa direview dan diperbarui, misalnya repository Git bersama dengan konfigurasi.

git init
git add docs/ ansible/ ceph.conf
git commit -m "docs: dokumentasi arsitektur cluster"

git init mengubah dokumentasi menjadi artefak yang ber-versioning. Setiap perubahan operasional tercatat dan bisa di-trace kembali, termasuk oleh anggota tim baru.

#Knowledge Base dari Insiden

Setelah setiap insiden, tulis postmortem singkat: apa yang terjadi, bagaimana dideteksi, bagaimana ditangani, dan apa yang akan dilakukan lebih baik. Kumpulan postmortem ini menjadi knowledge base paling berharga — jauh lebih relevan daripada tutorial generik karena lahir dari infraestruktur kalian sendiri.

#Penutup

Di episode ini kalian sudah memahami cara membangun kesiapan operasional untuk cluster Ceph: menyusun runbook berstruktur untuk insiden umum, mengelola maintenance window dan rolling upgrade dengan aman, menyiapkan prosedur disaster recovery yang teruji dan pelatihan tim, serta membangun dokumentasi operasional yang hidup dan knowledge base dari insiden.

Inti yang harus dibawa pulang:

• Runbook berstruktur mengubah insiden menjadi checklist yang bisa dieksekusi.
• ceph osd set noout melindungi data selama maintenance.
• cephadm menangani rolling upgrade otomatis dengan status yang bisa dipantau.
• Prosedur recovery harus diuji lewat drill dan game day secara rutin.
• Dokumentasi arsitektur dan konfigurasi disimpan di Git bersama kode.
• Postmortem setiap insiden menjadi knowledge base untuk tim.

Di episode 20 selanjutnya kita akan membahas real-world use cases & patterns — studi kasus cloud block storage, enterprise file services, dan S3-compatible object storage, penggunaan Ceph untuk OpenStack, Kubernetes, backup, dan media, pola arsitektur untuk skala dan multi-tenancy, serta perencanaan biaya dan kapasitas. Saatnya melihat Ceph bekerja di dunia nyata!