Belajar Elasticsearch - High Availability & Disaster Recovery

#Pendahuluan

Sampai episode 28 kalian membangun Elasticsearch yang terotomasi dan terdokumentasi. Tapi ada pertanyaan terakhir yang belum dijawab: apa yang terjadi jika satu node mati, satu rack terbakar, atau satu region dilanda bencana? Jawabannya bergantung pada dua konsep: high availability (HA) yang menjaga cluster tetap melayani saat komponen gagal, dan disaster recovery (DR) yang memastikan data serta layanan bisa dipulihkan setelah kegagalan besar.

Episode 29 membahas desain cluster multi-node untuk HA (master quorum anti split-brain, redundansi data node, zone-aware replica allocation), strategi deployment multi-region, perencanaan RPO dan RTO, prosedur failover, konsistensi data, serta cara menguji DR secara berkala.

#Desain Cluster Multi-Node untuk HA

#Master Quorum dan Anti Split-Brain

Master node mengelola state cluster: keputusan shard placement, pembuatan index, dan keanggotaan node. Agar cluster sehat, master dipilih berdasarkan mayoritas node master-eligible. Aturan quorum: jumlah master-eligible yang dibutuhkan = floor(total master-eligible / 2) + 1. Jika mayoritas hilang, cluster berhenti memproses — ini sengaja, untuk mencegah split-brain (dua master yang hidup berdampingan dan merusak state secara bersamaan).

Praktik terbaiknya: gunakan dedicated master nodes dalam jumlah ganjil — tiga node untuk menahan satu kegagalan, lima untuk menahan dua:

node.name: master-01
node.roles: [ master ]
discovery.seed_hosts: ["master-01", "master-02", "master-03"]

Jangan menaruh data di node master. Pemisahan peran ini membuat cluster lebih stabil — master tetap berfungsi walau data node penuh atau sedang reindex.

#Redundansi Data Node

Data tersebar dalam shards, dan shards punya replica (episode 2). Jika tiap index memiliki minimal satu replica, setiap shard punya salinan di node lain — satu data node mati tidak menghilangkan data, dan cluster tetap melayani pencarian.

{
  "index": { "number_of_replicas": 1 }
}

Pastikan jumlah data node cukup untuk menampung primary dan replica secara terpisah. Untuk satu index dengan satu replica, minimal dua data node di zona yang berbeda.

#Zone-Aware Replica Allocation

Replica hanya berguna jika ia berada di infrastruktur yang berbeda dari primary. Allocation awareness memaksa Elasticsearch menyebar shard berdasarkan atribut — biasanya zona ketersediaan (availability zone):

node.attr.zone: az-a

{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": ["zone"]
  }
}

Dengan konfigurasi ini, primary dan replica tidak akan pernah berada di zona yang sama. Jika satu zona mati, replica di zona lain siap diangkat. Jika kalian ragu di mana sebuah shard berada, gunakan GET /_cluster/allocation/explain untuk diagnosis.

#Strategi Deployment Multi-Region

HA menjaga cluster tetap hidup, tapi tidak melindungi dari bencana yang mematikan satu cluster. Untuk itu, jalankan cluster terpisah di lebih dari satu region. Pola yang paling umum:

• Active-passive: cluster utama melayani produksi; cluster cadangan standby. Sinkronisasi via cross-cluster replication (CCR) (episode 22) atau snapshot.
• Active-active: kedua cluster melayani traffic dan saling mereplikasi — lebih kompleks karena butuh penanganan conflict.

CCR memakai model leader-follower: index di cluster utama menjadi leader, index di region cadangan mengikutinya secara async. Replikasi hanya butuh index leader di remote cluster.

PUT /produk-copy/_ccr/follow

Read di region cadangan bisa diarahkan ke follower; write tetap di leader. Untuk pembacaan lintas cluster sekaligus, cross-cluster search (episode 22) tetap berlaku.

#Perencanaan RPO dan RTO

Dua angka ini menjadi kompas semua keputusan DR:

RPO menentukan frekuensi sinkronisasi. CCR dengan replikasi async memberi RPO kecil (menit); snapshot SLM (episode 20) memberi RPO besar (jam). RTO menentukan kecepatan failover — seberapa cepat follower di-promote, klien dipindah, dan index di-unfollow.

Pilihan arsitektur mengikuti angka ini: layanan log yang boleh kehilangan satu jam data cukup memakai snapshot harian; platform pembayaran dengan RPO menit wajib memakai CCR dan infrastruktur yang selalu standby. Dokumentasikan kedua angka ini dan pastikan targetnya realistis — RPO/RTO yang tidak pernah diuji hanyalah angka di atas kertas.

#Prosedur Failover

Saat bencana terjadi, failover harus mengikuti runbook yang sudah dilatih, bukan improvisasi. Urutan umum untuk pola active-passive dengan CCR:

1. Konfirmasi bahwa region utama benar-benar mati dan traffic sudah berhenti.
2. Di region cadangan, cek bahwa lag replikasi terkendali dan follower masih utuh.
3. Promote follower menjadi primary dengan POST /produk-copy/_ccr/unfollow lalu arahkan write ke sana.
4. Pindahkan klien, DNS, atau load balancer ke region cadangan.
5. Verifikasi kesehatan dan indeks, lalu pantau terus-menerus.

#Menguji Disaster Recovery

DR yang tidak pernah diuji akan gagal di saat paling dibutuhkan. Uji secara berkala dengan simulasi kegagalan nyata:

• Chaos testing: matikan satu data node, satu master node, satu zona.
• Simulasi region down: alihkan traffic ke region cadangan dan jalankan beban di sana.
• Restore drill: pulihkan data dari snapshot di cluster baru dan bandingkan integritasnya.
• Ukur target: catat waktu failover dan kehilangan data aktual, bandingkan dengan RPO/RTO.

Jadikan pengujian ini agenda terjadwal (misal kuartalan), dengan dokumentasi hasil dan perbaikan yang ditindaklanjuti. Semakin sering kalian mematikan cluster di lab, semakin tenang kalian menghadapi kegagalan sungguhan.

#Penutup

Di episode 29 kalian menguasai dua lapisan ketangguhan. Di lapisan HA: desain cluster multi-node dengan dedicated master berjumlah ganjil, master quorum sebagai tameng split-brain, redundansi data node lewat replica, dan zone-aware replica allocation agar primary serta replica tidak berada di satu zona. Di lapisan DR: cluster multi-region dengan CCR leader-follower, perencanaan RPO dan RTO, runbook failover, konsistensi data eventual, dan pengujian DR berkala.

Inti yang harus dibawa pulang:

• Quorum anti split-brain: dedicated master ganjil, mayoritas yang sehat dibutuhkan.
• Replica itu redundansi, tapi hanya berarti jika berada di infrastruktur berbeda (zone-aware).
• RPO/RTO menentukan arsitektur: CCR untuk RPO kecil, snapshot untuk retensi jangka panjang.
• Failover harus menjadi runbook yang dilatih, bukan improvisasi saat krisis.
• DR diuji secara berkala — chaos testing, restore drill, dan pengukuran target.

Infrastruktur kalian sekarang kuat dan tangguh. Di episode terakhir, episode 30, kita menyatukan semuanya: production deployment checklist dan best practices — capacity planning, security hardening, monitoring dan alerting, backup restore testing, change management, rolling upgrade, troubleshooting, performance baseline, incident response, cost optimization, serta fitur-fitur advanced Elasticsearch 8.x yang siap dipakai. Sampai jumpa!