Belajar Vault - Vault High Availability (HA) Cluster & Raft Storage

#Pendahuluan

Setelah di episode 19 sebelumnya kita membahas integrasi Vault dengan Terraform dan Ansible — menjadikan Vault sebagai source of truth saat infrastruktur di-provisioning otomatis — pada episode kali ini kita mulai memasuki Fase 6: HA, Hardening, Observability & Production Readiness. Dan kita memulai fase terakhir ini dari fondasi yang paling krusial: membangun Vault High Availability (HA) Cluster dengan Raft Integrated Storage.

Kalian mungkin berpikir, "kenapa harus repot-repot membuat cluster? Vault kan sudah jalan di server satu saya". Benar — tapi bayangkan skenario berikut: aplikasi kalian mengambil secret dari Vault setiap kali melakukan bootstrap, database dynamic credentials dibuka lewat Vault, dan sertifikat TLS internal diterbitkan oleh Vault. Sekarang server Vault itu mati karena kerusakan disk atau maintenance rutin. Apa yang terjadi? Semua aplikasi yang butuh secret baru ikut lumpuh. Vault yang single node adalah single point of failure (SPOF) — satu titik yang bisa menjatuhkan seluruh sistem.

Ini bukan teori. Di dunia kerja nyata, Vault adalah salah satu komponen yang paling "diandalkan tapi dilupakan" sampai ia mati. Seperti jantung: selama berdetak normal kita tidak sadar, begitu berhenti, seluruh tubuh berhenti. Episode ini akan mengajarkan kalian bagaimana membuat Vault yang tetap hidup meskipun satu atau bahkan dua node-nya mati, plus memahami protokol yang menjamin konsistensi data di baliknya: Raft.

#Pembahasan Utama

#Masalah Single Node dan Mengapa Kita Membutuhkan HA

Sebelum masuk ke konfigurasi, mari jernihkan dulu mengapa single node tidak pernah diterima di lingkungan produksi:

1. SPOF (Single Point of Failure) — jika node mati, seluruh request secret gagal.
2. Maintenance windows — upgrade Vault atau patch OS membutuhkan downtime; di produksi, downtime Vault = downtime aplikasi.
3. Scalability terbatas — semua request read dan write dibebankan ke satu proses.
4. Kepatuhan — banyak standar (PCI-DSS, SOC 2, ISO 27001) mengharuskan sistem kritis memiliki redundancy dan recovery objective yang jelas.

Konsep HA di Vault sederhana: bukan berarti beberapa node melayani semua request secara paralel. Arsitekturnya adalah satu Active node yang melayani request read dan write, dikelilingi oleh satu atau lebih Standby node yang mereplikasi seluruh data dan siap mengambil alih saat Active node gagal. Fokus episode ini adalah bagaimana replikasi itu bekerja dan bagaimana mengelolanya dengan benar.

#Raft Integrated Storage: Penyimpanan Terdistribusi Bawaan Vault

Sejak Vault versi 1.4, kalian tidak perlu lagi menyediakan penyimpanan eksternal terpisah untuk membuat cluster. Vault punya Raft Integrated Storage — sebuah storage backend terdistribusi yang ditanam langsung di dalam biner Vault.

Keunggulan utama Raft integrated storage:

• Tanpa dependency eksternal — tidak perlu mengoperasikan cluster Consul lagi; satu sistem yang harus dipelajari operasionalnya, bukan dua.
• Consistency — Raft menjamin data di semua node selalu identik (strongly consistent), berbeda dengan model eventual consistency.
• Operasional lebih sederhana — provisioning, upgrade, dan backup hanya berurusan dengan satu stack.
• Snapshot untuk DR — mekanisme backup bawaan (vault operator raft snapshot save) yang akan kita bahas di episode 22.

#Arsitektur Vault HA: Active, Standby, dan Konsensus

Dalam satu cluster Vault, hanya ada satu Active node. Semua request write (menulis secret, membuat token, menerbitkan sertifikat) dan read dilayani oleh node ini. Node Standby bertugas:

• Mereplikasi data melalui log Raft — setiap perubahan yang diterima Active node dikirim ke follower sebagai replicated log entry.
• Mengalihkan request — jika aplikasi secara tidak sengaja memanggil node Standby, Vault merespons dengan HTTP 307 redirect menuju address Active node. Jadi dari sisi client, tidak perlu tahu node mana yang aktif.
• Menjadi pengganti — ketika Active node mati, Raft melakukan leader election dan salah satu Standby terpilih menjadi Active baru dalam hitungan detik (biasanya 5–10 detik tergantung jaringan dan konfigurasi).

Pemilihan leader dilakukan dengan protokol Raft Consensus. Setiap node memiliki peran: leader (active) atau follower (standby). Ketika leader tidak lagi mengirim heartbeat, follower akan memulai pemilihan. Keputusan hanya diambil jika mayoritas node (quorum) setuju — di sinilah keamanan terhadap split-brain berada.

#Praktik: Membangun Cluster Vault 3 Node dengan Raft

Sekarang saatnya praktik. Kita akan membangun cluster 3 node dengan IP:

• vault-node-1 → 10.0.0.11
• vault-node-2 → 10.0.0.12
• vault-node-3 → 10.0.0.13

Konfigurasi inti setiap node hampir identik — yang membedakan hanya node_id, api_addr, dan cluster_addr. Perhatikan blok storage "raft":

storage "raft" {
  path   = "/opt/vault/data"
  node_id = "vault-node-1"
 
  retry_join {
    leader_api_addr = "https://10.0.0.11:8200"
  }
  retry_join {
    leader_api_addr = "https://10.0.0.12:8200"
  }
  retry_join {
    leader_api_addr = "https://10.0.0.13:8200"
  }
}
 
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = false
  tls_cert_file = "/etc/vault.d/tls/vault.crt"
  tls_key_file  = "/etc/vault.d/tls/vault.key"
}
 
api_addr     = "https://10.0.0.11:8200"
cluster_addr = "https://10.0.0.11:8201"
 
ui  = true
log_level = "Info"

storage "raft" {
  path   = "/opt/vault/data"
  node_id = "vault-node-2"
 
  retry_join {
    leader_api_addr = "https://10.0.0.11:8200"
  }
  retry_join {
    leader_api_addr = "https://10.0.0.12:8200"
  }
  retry_join {
    leader_api_addr = "https://10.0.0.13:8200"
  }
}
 
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = false
  tls_cert_file = "/etc/vault.d/tls/vault.crt"
  tls_key_file  = "/etc/vault.d/tls/vault.key"
}
 
api_addr     = "https://10.0.0.12:8200"
cluster_addr = "https://10.0.0.12:8201"
 
ui  = true
log_level = "Info"

storage "raft" {
  path   = "/opt/vault/data"
  node_id = "vault-node-3"
 
  retry_join {
    leader_api_addr = "https://10.0.0.11:8200"
  }
  retry_join {
    leader_api_addr = "https://10.0.0.12:8200"
  }
  retry_join {
    leader_api_addr = "https://10.0.0.13:8200"
  }
}
 
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = false
  tls_cert_file = "/etc/vault.d/tls/vault.crt"
  tls_key_file  = "/etc/vault.d/tls/vault.key"
}
 
api_addr     = "https://10.0.0.13:8200"
cluster_addr = "https://10.0.0.13:8201"
 
ui  = true
log_level = "Info"

Hal-hal penting pada konfigurasi di atas:

• node_id harus unik di setiap node — ini adalah identitas permanen node di dalam cluster. Jika node_id sama, Raft akan menolak node bergabung.
• retry_join berisi address semua node yang berpotensi menjadi leader. Saat node boot dan belum menjadi bagian dari cluster, ia akan terus mencoba "menemukan" cluster lewat address ini.
• api_addr adalah address yang dilihat client; cluster_addr adalah address untuk komunikasi antar node Vault (port 8201). Keduanya wajib diisi agar failover dan redirect bekerja benar.

#Langkah 1: Inisialisasi Node Pertama

Jalankan Vault di ketiga node, lalu inisialisasi hanya node pertama:

export VAULT_ADDR=https://10.0.0.11:8200
vault operator init

Hasilnya berupa Unseal Keys (Shamir) dan Initial Root Token. Simpan dengan aman — kita masih memakai unseal manual di episode ini (auto-unseal akan kita pelajari di episode 21). Lalu unseal node pertama:

vault operator unseal "Unseal Key 1"
vault operator unseal "Unseal Key 2"
vault operator unseal "Unseal Key 3"

Setelah threshold terpenuhi, node-1 menjadi sealed=false. Node ini otomatis menjadi leader cluster karena belum ada node lain.

#Langkah 2: Join Node Kedua dan Ketiga

Sekarang node-2 dan node-3 bergabung ke cluster. Perintah vault operator raft join membutuhkan address leader (atau address api_addr salah satu node yang sudah ada):

export VAULT_ADDR=https://10.0.0.12:8200
vault operator raft join https://10.0.0.11:8200

export VAULT_ADDR=https://10.0.0.13:8200
vault operator raft join https://10.0.0.11:8200

Output yang sukses kurang lebih:

Key       Value
---       -----
Joined    true

Node-2 dan node-3 perlu di-unseal juga dengan Unseal Keys yang sama (kunci master cluster itu satu — dibagikan ke semua node):

vault operator unseal "Unseal Key 1"
vault operator unseal "Unseal Key 2"
vault operator unseal "Unseal Key 3"

#Langkah 3: Verifikasi Status dan Peers

Dari node mana pun (dengan token yang valid), kita bisa memeriksa kesehatan cluster:

export VAULT_ADDR=https://10.0.0.11:8200
vault status

Key                Value
---                -----
Sealed             false
HA Enabled         true
HA Cluster         vault-cluster-abc123
HA Mode            active
Active Since       2026-08-02T08:15:00.000Z

Perhatikan baris HA Enabled true dan HA Mode active — inilah tanda bahwa node melayani request. Sekarang lihat peta cluster dengan vault operator raft list-peers:

vault operator raft list-peers

Node          Address              State     Voter
----          -------              -----     -----
vault-node-1  10.0.0.11:8201       leader    true
vault-node-2  10.0.0.12:8201       follower  true
vault-node-3  10.0.0.13:8201       follower  true

Semua node berstatus voter dengan true — berarti mereka ikut serta dalam pengambilan keputusan konsensus. Node-1 adalah leader, dua lainnya follower.

#Quorum dan Toleransi Kegagalan

Kunci memahami Raft adalah konsep quorum: jumlah node mayoritas yang harus setuju sebelum cluster mengambil keputusan. Rumusnya: quorum = floor(n/2) + 1. Untuk 3 node, quorum = 2. Artinya minimal 2 node harus hidup agar cluster masih bekerja.

Dari tabel di atas kalian bisa melihat mengapa 3 node adalah konfigurasi minimum yang layak untuk produksi, dan 5 node untuk lingkungan yang sangat kritis. Dengan 3 node, satu node mati masih aman; dua node mati berarti kehilangan quorum. Dengan 5 node, dua node mati masih aman.

#Kesalahan Umum (Common Pitfalls)

Pengalaman operasional Vault HA di lapangan penuh dengan jebakan. Berikut yang paling sering terjadi:

Satu hal yang perlu digarisbawahi: jangan pernah langsung menghapus data folder /opt/vault/data pada node yang gagal untuk "reset". Jika node tersebut masih dihitung sebagai voter, cluster tetap menganggapnya bagian dari quorum dan ini bisa membuat cluster mati total. Gunakan perintah resmi untuk menonaktifkan node dari perspektif cluster sebelum mengambil tindakan fisik.

#Penutup

Pada episode 20 ini kita telah memahami mengapa single node Vault tidak layak untuk produksi, bagaimana Raft Integrated Storage memberikan penyimpanan terdistribusi tanpa dependency eksternal, bagaimana arsitektur Active-Standby bekerja, dan bagaimana membangun cluster 3 node secara langkah demi langkah: konfigurasi storage "raft", vault operator raft join, inisialisasi, unseal, hingga verifikasi dengan vault operator raft list-peers. Kita juga mempelajari tabel quorum — 3 node untuk produksi standar, 5 node untuk lingkungan kritis — plus daftar kesalahan umum yang sering menghancurkan cluster di dunia nyata.

Satu hal yang kalian pasti sadari saat praktik: setelah setiap restart server, kalian harus unseal manual dengan Unseal Keys. Di production, ini adalah mimpi buruk operasional — siapa yang menjamin operator bangun jam 3 pagi saat maintenance window selesai? Kabar baiknya, ada solusi elegan: auto-unseal menggunakan Cloud KMS, yang akan kita bahas tuntas di episode 21. Dengan auto-unseal, Vault akan membuka segelnya sendiri secara otomatis saat boot — tanpa intervensi manusia. Pastikan tetap semangat, kita masih punya lima episode terakhir yang seru! 🚀