mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-17 20:17:00 +02:00
2c19bbe145
* VAULT-21427 change ui references from K/V to KV * references in docs/ * website json data * go command errors * replace Key/Value with Key Value * add changelog * update test * update secret list header badge * two more test updates
59 lines
2.8 KiB
Plaintext
59 lines
2.8 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: High Availability
|
|
description: Learn about the high availability design of Vault.
|
|
---
|
|
|
|
# High availability
|
|
|
|
Vault can run in a high availability (HA) mode to protect against outages by running multiple Vault servers.
|
|
|
|
|
|
# Design overview
|
|
|
|
The primary design goal for making Vault Highly Available (HA) is to
|
|
minimize downtime without affecting horizontal scalability. Vault is
|
|
bound by the IO limits of the storage backend rather than the compute
|
|
requirements. Being bound by the IO limits simplifies the HA approach and avoids complex
|
|
coordination.
|
|
|
|
Storage backends, such as Integrated Storage, provide additional coordinative
|
|
functions enabling Vault to run in an HA configuration. Supported
|
|
by the backend, Vault will automatically run in HA mode without further
|
|
configuration.
|
|
|
|
When running in HA mode, Vault servers have two states they
|
|
can be: **standby** and **active**. For multiple Vault servers sharing a storage
|
|
backend, only a single instance is active at any time. All standby instances are placed in hot standbys.
|
|
|
|
Only the active server processes all requests; the standby server redirects all requests to an active Vault server.
|
|
|
|
Meanwhile, if the active server is sealed, fails, or loses network connectivity,
|
|
then one of the standby Vault server becomes the active instance.
|
|
|
|
Please note that only _unsealed_ Vault servers may act as a standby.
|
|
If a server is in a sealed state, it cannot act as a standby. Servers in a sealed state cannot
|
|
serve any requests if the active server fails.
|
|
|
|
# Performance standby nodes (Enterprise)
|
|
|
|
Performance Standby Nodes service read-only requests from users or applications.
|
|
Read-only requests are requests that do not modify Vault's storage. Vault quickly scales its ability to service these operations,
|
|
providing a near-linear request-per-second scaling for most scenarios and secrets engines like KV and Transit. Traffic is distributed across performance standby nodes, allowing clients to scale these IOPS horizontally, and control high traffic workloads.
|
|
|
|
If a request comes into a Performance Standby Node that causes a storage to write
|
|
the request, the request is forwarded to the active server. Read-only requests are serviced locally on the Performance Standby.
|
|
|
|
Like traditional HA standbys, a Performance Standby Node becomes the active instance when the active node is sealed, fails, or loses
|
|
network connectivity.
|
|
|
|
# Tutorial
|
|
|
|
Refer to the following tutorials to learn more.
|
|
|
|
- [Vault with Integrated Storage Reference Architecture](/vault/tutorials/day-one-raft/raft-reference-architecture)
|
|
- [Vault HA Cluster with Integrated Storage](/vault/tutorials/raft/raft-storage)
|
|
- [Vault High Availability with Consul](/vault/tutorials/day-one-consul/ha-with-consul)
|
|
- [Performance Standby Nodes](/vault/tutorials/enterprise/performance-standbys)
|
|
|