<commit_before>---
layout: "docs"
page_title: "High Availability"
sidebar_current: "docs-concepts-ha"
description: |-
  Vault can be highly available, allowing you to run multiple Vaults to protect against outages.
---

# High Availability Mode (HA)

Vault supports a multi-server mode for high availability. This mode protects
against outages by running multiple Vault servers. High availability mode
is automatically enabled when using a data store that supports it.

You can tell if a data store supports high availability mode ("HA") by starting
the server and seeing if "(HA available)" is output next to the data store
information. If it is, then Vault will automatically use HA mode. This
information is also available on the
[Configuration](https://www.vaultproject.io/docs/configuration/index.html) page.

To be highly available, one of the Vault server nodes grabs a lock within the
data store. The successful server node then becomes the active node; all other
nodes become standby nodes. At this point, if the standby nodes receive a
request, they will either forward the request or redirect the client depending
on the current configuration and state of the cluster -- see the sections below
for details. Due to this architecture, HA does not enable increased
scalability. In general, the bottleneck of Vault is the data store itself, not
Vault core. For example: to increase the scalability of Vault with Consul, you
would generally scale Consul instead of Vault.

Certain storage backends can support high availability mode, which enable them
to store both Vault's information in addition to the HA lock. However, Vault
also supports split data/HA mode, whereby the lock value and the rest of the
data live separately. This can be done by specifying both the `storage` and
`ha_storage` stanzas in the configuration file with different backends. For
instance, a Vault cluster can be set up to use Consul as the `ha_storage` to
manage the lock, and use Amazon S3 as the `storage` for all other persisted
data.

The sections below explain the server communication patterns and each type of
request handling in more detail. At a minimum, the requirements for redirection<commit_msg>updating link<commit_after>---
layout: "docs"
page_title: "High Availability"
sidebar_current: "docs-concepts-ha"
description: |-
  Vault can be highly available, allowing you to run multiple Vaults to protect against outages.
---

# High Availability Mode (HA)

Vault supports a multi-server mode for high availability. This mode protects
against outages by running multiple Vault servers. High availability mode
is automatically enabled when using a data store that supports it.

You can tell if a data store supports high availability mode ("HA") by starting
the server and seeing if "(HA available)" is output next to the data store
information. If it is, then Vault will automatically use HA mode. This
information is also available on the
[Configuration](/docs/configuration/index.html) page.

To be highly available, one of the Vault server nodes grabs a lock within the
data store. The successful server node then becomes the active node; all other
nodes become standby nodes. At this point, if the standby nodes receive a
request, they will either forward the request or redirect the client depending
on the current configuration and state of the cluster -- see the sections below
for details. Due to this architecture, HA does not enable increased
scalability. In general, the bottleneck of Vault is the data store itself, not
Vault core. For example: to increase the scalability of Vault with Consul, you
would generally scale Consul instead of Vault.

Certain storage backends can support high availability mode, which enable them
to store both Vault's information in addition to the HA lock. However, Vault
also supports split data/HA mode, whereby the lock value and the rest of the
data live separately. This can be done by specifying both the `storage` and
`ha_storage` stanzas in the configuration file with different backends. For
instance, a Vault cluster can be set up to use Consul as the `ha_storage` to
manage the lock, and use Amazon S3 as the `storage` for all other persisted
data.

The sections below explain the server communication patterns and each type of
request handling in more detail. At a minimum, the requirements for redirection
{'fraction_non_alphanumeric': 0.04244092681807754, 'fraction_numerical': 0.0004588208304657031, 'mean_word_length': 4.706806282722513, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 1, 'lorem ipsum': 0, 'www.': 1, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6632854', 'n_tokens_mistral': 1050, 'n_tokens_neox': 1027, 'n_words': 666}