mirror of
https://github.com/optim-enterprises-bv/vault.git
synced 2025-11-02 03:27:54 +00:00
capped perf replication (#15338)
This commit is contained in:
Loann Le
@@ -141,7 +141,7 @@ $ curl \
|
||||
|
||||
## Disable Performance Primary
|
||||
|
||||
This endpoint disables performance replication entirely on the cluster. Any
|
||||
This endpoint disables Performance Replication entirely on the cluster. Any
|
||||
performance secondaries will no longer be able to connect. Caution: re-enabling
|
||||
this node as a primary or secondary will change its cluster ID; in the secondary
|
||||
case this means a wipe of the underlying storage when connected to a primary,
|
||||
@@ -426,7 +426,7 @@ $ curl \
|
||||
|
||||
## Enable Performance Secondary
|
||||
|
||||
This endpoint enables performance replication on a secondary using a secondary activation
|
||||
This endpoint enables Performance Replication on a secondary using a secondary activation
|
||||
token.
|
||||
|
||||
!> This will immediately clear all data in the secondary cluster!
|
||||
@@ -511,7 +511,7 @@ $ curl \
|
||||
|
||||
## Disable Performance Secondary
|
||||
|
||||
This endpoint disables performance replication entirely on the cluster. The cluster will no
|
||||
This endpoint disables Performance Replication entirely on the cluster. The cluster will no
|
||||
longer be able to connect to the performance primary.
|
||||
|
||||
!> Re-enabling this node as a performance primary or secondary will change its cluster ID;
|
||||
|
||||
@@ -12,7 +12,7 @@ description: >-
|
||||
## Overview
|
||||
|
||||
-> **Note**: All versions of [Vault Enterprise](https://www.hashicorp.com/products/vault/)
|
||||
have support for Disaster Recovery replication. Performance Replication requires
|
||||
have support for Disaster Recovery replication. Performance Replication requires
|
||||
Vault Enterprise Premium.
|
||||
|
||||
Many organizations have infrastructure that spans multiple datacenters. Vault
|
||||
@@ -49,18 +49,18 @@ relationships.
|
||||
|
||||
|
||||
|
||||
The following table shows a capability comparison between disaster recovery and performance replications.
|
||||
The following table shows a capability comparison between Disaster Recovery and Performance Replication.
|
||||
|
||||
| Capability | Disaster Recovery | Performance |
|
||||
| Capability | Disaster Recovery | Performance Replication |
|
||||
| -------------------------------------------------------------------------------------------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Mirrors the configuration of a primary cluster | Yes | Yes |
|
||||
| Mirrors the configuration of a primary cluster’s backends (i.e., auth methods, secrets engines, audit devices, etc.) | Yes | Yes |
|
||||
| Mirrors the tokens and leases for applications and users interacting with the primary cluster | Yes | No. Secondaries keep track of their own tokens and leases. When the secondary is promoted, applications must reauthenticate and obtain new leases from the newly-promoted primary. |
|
||||
| Allows the secondary cluster to handle client requests | No | Yes |
|
||||
| Allows the secondary cluster to handle client requests | No | Yes |
|
||||
|
||||
## Performance Replication
|
||||
|
||||
In performance replication, secondaries keep track of their own tokens and leases
|
||||
In Performance Replication, secondaries keep track of their own tokens and leases
|
||||
but share the underlying configuration, policies, and supporting secrets (K/V values,
|
||||
encryption keys for `transit`, etc).
|
||||
|
||||
@@ -71,10 +71,10 @@ in `transit`, etc.) can be satisfied by the local secondary, allowing Vault to s
|
||||
relatively horizontally with the number of secondaries rather than vertically as
|
||||
in the past.
|
||||
|
||||
### Paths Filter
|
||||
### Paths Filter
|
||||
|
||||
The primary cluster's mount configuration gets replicated across its secondary
|
||||
clusters when you enable performance replication. In some cases, you may not
|
||||
clusters when you enable Performance Replication. In some cases, you may not
|
||||
want all data to be replicated. For example, your primary cluster is in the EU
|
||||
region, and you have a secondary cluster outside of the EU region. [General Data
|
||||
Protection Regulation (GDPR)](https://www.eugdpr.org/) requires that personally
|
||||
@@ -84,7 +84,7 @@ protection regulation as the EU.
|
||||
|
||||
To comply with GDPR, leverage Vault's **paths filter** feature to abide by
|
||||
data movements and sovereignty regulations while ensuring performance access
|
||||
across geographically distributed regions.
|
||||
across geographically distributed regions.
|
||||
|
||||
You can set filters based on the mount path of the secrets engines and
|
||||
namespaces.
|
||||
@@ -100,14 +100,14 @@ Local secrets engines and auth methods are not replicated or removed by
|
||||
replication.
|
||||
|
||||
**Example:** When you enable a secrets engine on a secondary cluster, use the
|
||||
`-local` flag.
|
||||
`-local` flag.
|
||||
|
||||
```shell-session
|
||||
```shell-session
|
||||
$ vault secrets enable -local -path=us_west_data kv-v2
|
||||
```
|
||||
|
||||
-> **Learn:** Refer to the [Performance Replication with Paths
|
||||
Filter](https://learn.hashicorp.com/tutorials/vault/paths-filter) tutorial for
|
||||
Filter](https://learn.hashicorp.com/tutorials/vault/paths-filter) tutorial for
|
||||
step-by-step instructions.
|
||||
|
||||
|
||||
|
||||
@@ -120,7 +120,7 @@ e6876c97-aaaa-a92e-b99a-0aafab105745 vault-secondary-1.vault-secondary-intern
|
||||
|
||||
## Enable Performance Replication On Primary
|
||||
|
||||
With the initial clusters setup, we can now configure them for performance replication.
|
||||
With the initial clusters setup, we can now configure them for Performance Replication.
|
||||
|
||||
First, on the primary cluster, enable replication:
|
||||
|
||||
@@ -138,7 +138,7 @@ The token in the output will be used when configuring the secondary cluster.
|
||||
|
||||
## Enable Performance Replication On Secondary
|
||||
|
||||
Using the token created in the last step, enable performance replication on the secondary:
|
||||
Using the token created in the last step, enable Performance Replication on the secondary:
|
||||
|
||||
```shell
|
||||
kubectl exec -ti vault-secondary-0 -- vault write sys/replication/performance/secondary/enable token=<TOKEN FROM PRIMARY>
|
||||
|
||||
Reference in New Issue
Block a user