Learn Secret Management - OpenBao High Availability Cluster and Raft Storage

#Introduction

In episode 14 you automated provisioning with OpenTofu or Terraform and Ansible. Episode 15 shifts to the production foundation: how to keep OpenBao available when a single server dies. You will understand Raft integrated storage, the active and standby node architecture, and the steps to build a 3 or 5 node cluster from scratch.

#Why High Availability Is Needed

OpenBao is the gatekeeper of all secrets. If its main server dies, every application depending on it is crippled too — not to mention that secret rotation and reads stop. High availability ensures there is another node ready to take over the moment the active node fails, so the service keeps serving with minimal downtime.

#Raft Integrated Storage

Storage determines where OpenBao's data is stored and how data is replicated between nodes. Previously the common architecture used Consul as external storage. OpenBao brings a much more compact alternative: Raft integrated storage.

#Advantages of Raft Integrated Storage

Raft integrated storage uses the Raft consensus protocol to replicate data among the OpenBao nodes themselves, without an external server:

• No need to operate a separate Consul cluster.
• Simpler deployment: just OpenBao servers with a storage "raft" configuration.
• Log replication runs automatically; every state change is consensus-approved before being considered successful.

For small teams wanting to move out of single-node mode, this is the fastest path to high availability.

#High Availability Cluster Architecture

#Active vs Standby Node

In a Raft cluster, only one node is active (leader) at any given time — this node is the only one serving read and write requests. The other nodes are standby (followers), replicating data and ready to be promoted if the leader fails. Leader election is handled by the consensus protocol, not manual intervention.

#Raft Consensus Protocol

Raft enforces a majority rule: a new operation is considered successful only when a majority of nodes approve it. Therefore, 3 nodes need 2 approvals, and 5 nodes need 3. This majority requirement is what keeps the cluster consistent even when some nodes go down.

The choice of node count follows quorum logic: 3 nodes are enough for a majority of 2 and tolerate losing 1 node; 5 nodes tolerate losing 2 nodes. Below 3 nodes, the cluster has no healthy majority.

#Configuring a 3-Node Cluster Setup

Let's set up a cluster with three servers: node1, node2, and node3.

#The "raft" Storage Block

Each node uses the same storage configuration, with a different node_id. Example for node1:

Raft storage configuration on 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 must be unique on each server; api_addr and cluster_addr point to each node's own address. For node2 and node3, change the node_id and addresses to match their names.

#Initializing the First Node

The first node is initialized and unsealed before the other nodes join:

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

bao operator init produces the unseal keys and root token; store both in a safe place. After unsealing, node1 becomes active.

#Adding Other Nodes with raft join

On node2 and node3, run the following command on each:

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

bao operator raft join pairs the new node with leader node1; after being unsealed, the node joins data replication. Repeat for node3 with its own address.

#Verifying Membership

bao operator raft list-peers

The output shows all nodes, their roles, and addresses. Make sure every node appears with a healthy status before adding real load.

#Conclusion

In this episode 15, you understood the advantages of Raft integrated storage over Consul, the active and standby node architecture with Raft consensus, the quorum rules for a 3 or 5 node cluster, the storage "raft" block, and the joining process via bao operator raft join.

Key takeaways:

• Raft integrated storage removes the need for external servers like Consul.
• Only the active node serves requests; standbys are ready to take over.
• Quorum is key: 3 nodes tolerate one failure, 5 nodes tolerate two.
• bao operator raft list-peers is the window into cluster health.

In the next episode, episode 16, we eliminate the ritual operators face most often: manual unsealing after maintenance with cloud KMS-based auto-unseal.