Belajar Secret Management - OpenBao High Availability Cluster dan Raft Storage

#Pendahuluan

Di episode 14 kalian mengotomasi provisioning dengan OpenTofu atau Terraform dan Ansible. Episode 15 bergeser ke fondasi produksi: bagaimana membuat OpenBao tetap tersedia saat satu server mati. Kalian akan memahami Raft integrated storage, arsitektur active dan standby node, serta langkah membangun cluster 3 atau 5 node dari nol.

#Mengapa High Availability Diperlukan

OpenBao adalah penjaga pintu semua rahasia. Jika server utamanya mati, semua aplikasi yang bergantung padanya ikut lumpuh — belum lagi rotasi dan pembacaan secret berhenti. High availability memastikan ada node lain yang siap menggantikan begitu node aktif gagal, sehingga layanan tetap melayani dengan downtime yang minimal.

#Raft Integrated Storage

Storage menentukan di mana data OpenBao disimpan dan bagaimana data direplikasi antar node. Sebelumnya arsitektur umum memakai Consul sebagai storage eksternal. OpenBao membawa alternatif yang jauh lebih ringkas: Raft integrated storage.

#Keunggulan Raft Integrated Storage

Raft integrated storage memanfaatkan protokol konsensus Raft untuk mereplikasi data di antara node-node OpenBao itu sendiri, tanpa server eksternal:

• Tidak perlu mengoperasikan cluster Consul terpisah.
• Deployment lebih sederhana: cukup server OpenBao dengan konfigurasi storage "raft".
• Replikasi log berjalan otomatis; setiap perubahan state dikonsensuskan sebelum dianggap sukses.

Bagi tim kecil yang ingin keluar dari mode single node, ini jalur tercepat menuju ketersediaan tinggi.

#Arsitektur High Availability Cluster

#Active vs Standby Node

Dalam cluster Raft, pada satu waktu hanya ada satu node yang menjadi active (leader) — node inilah satu-satunya yang melayani permintaan read dan write. Node lain berstatus standby (follower), mereplikasi data dan siap di-promote jika leader gagal. Pemilihan leader diatur oleh protokol konsensus, bukan oleh intervensi manual.

#Raft Consensus Protocol

Raft menjalankan aturan mayoritas: sebuah operasi baru dianggap berhasil jika mayoritas node menyetujuinya. Karena itu, untuk 3 node dibutuhkan 2 persetujuan, dan untuk 5 node dibutuhkan 3. Ketentuan mayoritas inilah yang membuat cluster tetap konsisten meskipun sebagian node turun.

Pemilihan jumlah node mengikuti logika kuorum: 3 node cukup untuk mayoritas 2 dan toleran kehilangan 1 node; 5 node memberikan toleransi kehilangan 2 node. Di bawah 3 node, cluster tidak punya mayoritas yang sehat.

#Konfigurasi Setup Cluster 3-Node

Mari susun cluster dengan tiga server: node1, node2, dan node3.

#Blok storage "raft"

Setiap node memakai konfigurasi storage yang sama, dengan node_id yang berbeda. Contoh untuk node1:

Konfigurasi storage raft pada node1

storage "raft" {
  path = "/opt/openbao/data"
  node_id = "node1"
}
 
listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = true
}
 
api_addr = "http://node1.example.com:8200"
cluster_addr = "http://node1.example.com:8201"

node_id harus unik di tiap server; api_addr dan cluster_addr mengarah ke alamat masing-masing node. Untuk node2 dan node3, ganti node_id dan alamatnya sesuai nama masing-masing.

#Inisialisasi Node Pertama

Node pertama di-init lalu di-unseal sebelum node lain bergabung:

export BAO_ADDR=http://node1.example.com:8200
bao operator init
bao operator unseal
bao operator raft list-peers

bao operator init menghasilkan unseal keys dan root token; simpan keduanya di tempat aman. Setelah unseal, node1 menjadi active.

#Menambahkan Node Lain dengan raft join

Pada node2 dan node3, jalankan perintah berikut masing-masing:

export BAO_ADDR=http://node2.example.com:8200
bao operator raft join http://node1.example.com:8200
bao operator unseal

bao operator raft join memasangkan node baru ke leader node1; setelah di-unseal, node ikut mereplikasi data. Ulangi untuk node3 dengan alamatnya sendiri.

#Verifikasi Keanggotaan

bao operator raft list-peers

Output menampilkan semua node, peran masing-masing, dan alamatnya. Pastikan setiap node muncul dengan status sehat sebelum menambahkan beban nyata.

#Penutup

Pada episode 15 ini, kalian memahami keunggulan Raft integrated storage dibandingkan Consul, arsitektur active dan standby node dengan konsensus Raft, aturan kuorum cluster 3 atau 5 node, blok storage "raft", serta proses bergabung lewat bao operator raft join.

Inti yang harus dibawa pulang:

• Raft integrated storage menghilangkan kebutuhan server eksternal seperti Consul.
• Hanya active node yang melayani permintaan; standby siap menggantikan.
• Kuorum adalah kunci: 3 node toleran satu kegagalan, 5 node toleran dua.
• bao operator raft list-peers adalah jendela kesehatan cluster.

Di episode 16 berikutnya, kita menghilangkan ritual yang paling sering dihadapi operator: unseal manual setelah maintenance dengan auto-unseal berbasis cloud KMS.