mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-18 12:37:02 +02:00
a43e292424
* conversion stage 1 * correct image paths * add sidebar title to frontmatter * docs/concepts and docs/internals * configuration docs and multi-level nav corrections * commands docs, index file corrections, small item nav correction * secrets converted * auth * add enterprise and agent docs * add extra dividers * secret section, wip * correct sidebar nav title in front matter for apu section, start working on api items * auth and backend, a couple directory structure fixes * remove old docs * intro side nav converted * reset sidebar styles, add hashi-global-styles * basic styling for nav sidebar * folder collapse functionality * patch up border length on last list item * wip restructure for content component * taking middleman hacking to the extreme, but its working * small css fix * add new mega nav * fix a small mistake from the rebase * fix a content resolution issue with middleman * title a couple missing docs pages * update deps, remove temporary markup * community page * footer to layout, community page css adjustments * wip downloads page * deps updated, downloads page ready * fix community page * homepage progress * add components, adjust spacing * docs and api landing pages * a bunch of fixes, add docs and api landing pages * update deps, add deploy scripts * add readme note * update deploy command * overview page, index title * Update doc fields Note this still requires the link fields to be populated -- this is solely related to copy on the description fields * Update api_basic_categories.yml Updated API category descriptions. Like the document descriptions you'll still need to update the link headers to the proper target pages. * Add bottom hero, adjust CSS, responsive friendly * Add mega nav title * homepage adjustments, asset boosts * small fixes * docs page styling fixes * meganav title * some category link corrections * Update API categories page updated to reflect the second level headings for api categories * Update docs_detailed_categories.yml Updated to represent the existing docs structure * Update docs_detailed_categories.yml * docs page data fix, extra operator page remove * api data fix * fix makefile * update deps, add product subnav to docs and api landing pages * Rearrange non-hands-on guides to _docs_ Since there is no place for these on learn.hashicorp, we'll put them under _docs_. * WIP Redirects for guides to docs * content and component updates * font weight hotfix, redirects * fix guides and intro sidenavs * fix some redirects * small style tweaks * Redirects to learn and internally to docs * Remove redirect to `/vault` * Remove `.html` from destination on redirects * fix incorrect index redirect * final touchups * address feedback from michell for makefile and product downloads
89 lines
3.6 KiB
Markdown
89 lines
3.6 KiB
Markdown
---
|
|
layout: "guides"
|
|
page_title: "Performance Standby Nodes - Guides"
|
|
sidebar_current: "guides-operations-performance-nodes"
|
|
description: |-
|
|
This guide will walk you through a simple Vault Highly Available (HA) cluster
|
|
implementation. While this is not an exhaustive or prescriptive guide that
|
|
can be used as a drop-in production example, it covers the basics enough to
|
|
inform your own production setup.
|
|
---
|
|
|
|
# Performance Standby Nodes
|
|
|
|
~> **Enterprise Only:** Performance Standby Nodes feature is a part of _Vault Enterprise_.
|
|
|
|
In [Vault High Availability](/guides/operations/vault-ha-consul.html) guide, 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](/docs/secrets/transit/index.html)
|
|
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.
|
|
|
|
|
|
## Reference Materials
|
|
|
|
- [Performance Standby Nodes](/docs/enterprise/performance-standby/index.html)
|
|
- [High Availability Mode](/docs/concepts/ha.html)
|
|
- [Consul Storage Backend](/docs/configuration/storage/consul.html)
|
|
- [Vault Reference Architecture](/guides/operations/reference-architecture.html)
|
|
|
|
|
|
## 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`](/docs/configuration/index.html#vault-enterprise-parameters)
|
|
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.
|
|
|
|
!> Consider a scenario where a node with performance standby _disabled_
|
|
becomes the active node. The performance standby feature is
|
|
disabled for the whole cluster although it is enabled on other nodes.
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
The number of performance standby nodes within a cluster depends on your Vault
|
|
Enterprise license.
|
|
|
|
Consider the following scenario:
|
|
|
|
- A cluster contains **five** Vault servers
|
|
- Your Vault Enterprise license allows **two** performance standby nodes
|
|
|
|
|
|
|
|
In this scenario, the performance standby nodes running on VM 8 and VM 9 can
|
|
process read-only requests. However, the _standby_ nodes running on VM 6 and VM
|
|
10 simply forward all requests to the active node running on VM 7.
|
|
|
|
|
|
> **NOTE:** The selection of performance standby node is determined by the
|
|
active node. When a node is selected, it gets promoted to become a performance
|
|
standby. This is a race condition that there is no configuration
|
|
parameter to specify which nodes to become performance standbys.
|
|
|
|
|
|
## Next steps
|
|
|
|
Read [Production Hardening](/guides/operations/production.html) to learn best
|
|
practices for a production hardening deployment of Vault.
|