Performance Standby Nodes

In Vault High Availability tutorial, it was explained that only one Vault server will be active in a cluster and handles all requests (reads and writes). The rest of the servers become the standby nodes and simply forward requests to the active node.

If you are running Vault Enterprise 0.11 or later, those standby nodes can handle most read-only requests. For example, performance standbys can handle encryption/decryption of data using transit keys, GET requests of key/value secrets and other requests that do not change underlying storage. This can provide considerable improvements in throughput for traffic of this type, resulting in aggregate performance increase linearly correlated to the number of performance standby nodes deployed in a cluster.

»Server Configuration

Performance standbys are enabled by default when the Vault Enterprise license includes this feature. If you wish to disable the performance standbys, you can do so by setting the disable_performance_standby flag to true.

Since any of the nodes in a cluster can get elected as active, it is recommended to keep this setting consistent across all nodes in the cluster.

»Enterprise Cluster

A highly available Vault Enterprise cluster consists of multiple servers, and there will be only one active node. The rest can serve as performance standby nodes handling read-only requests locally.

»Integrated Storage

When using Vault integrated storage to persist Vault data, you can add non-voter nodes to scale read-only workloads without worrying about the quorum count. (Non-voting node is an Enterprise-only feature of integrated storage.)

$ vault operator raft join -non-voter <active_node_api_address>

A non-voting node has all Vault data replicated just like other voting nodes. The difference is that the non-voting node does not contrribute to the quorum count.

»Help and Reference

• Performance Standby Nodes
• High Availability Mode
• Consul Storage Backend