scottk/vault
1
0
Fork 0
mirror of https://github.com/optim-enterprises-bv/vault.git synced 2026-01-08 21:21:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

backport of commit f1649fcde3 (#21072)

Browse Source 
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
This commit is contained in:
hc-github-team-secure-vault-core
2023-06-08 10:14:13 -04:00
committed by GitHub
parent b22c946057
commit 7c8d7d0e94
1 changed files with 33 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
website/content/docs/enterprise/replication.mdx
View File

@@ -42,14 +42,17 @@ All communication between primaries and secondaries is end-to-end encrypted
with mutually-authenticated TLS sessions, setup via replication tokens which are
exchanged during bootstrapping.
## Replicated data
What data is replicated between the primary and secondary depends on the type of
replication that is configured between the primary and secondary. These types
of relationships are either **disaster recovery** or **performance**
relationships.
of relationships are either **disaster recovery** or
**performance replication** relationships.
![](/img/replication-overview.png)
The following table shows a capability comparison between Disaster Recovery and Performance Replication.
The following table shows a capability comparison between Disaster Recovery
and Performance Replication.
| Capability | Disaster Recovery | Performance Replication |
| -------------------------------------------------------------------------------------------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -58,6 +61,30 @@ The following table shows a capability comparison between Disaster Recovery and
| 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 |
Everything written to storage is classified into one of three categories:
* `replicated` (or "shared"): all downstream clusters receive it
* `local`: only downstream disaster recovery clusters receive it
* `ignored`: not replicated to downstream clusters at all
When mounting a secret engine or auth method, you can choose whether to make it a
local mount or a shared mount.
Shared mounts (the default) usually replicate all their data to performance secondaries, but
they can choose to designate specific storage paths as local. For example, PKI mounts
store certificates locally. If you query the roles on a shared PKI mount, you'll see
the same result for that mount when you send the query to either the performance primary or
secondary, but if you list stored certs, you'll see different values.
Local mounts replicate their data only to disaster recovery secondaries. A local mount
created on a performance primary isn't visible at all to its performance secondaries.
Local mounts can also be created on performance secondaries, in which case they aren't visible
to the performance primary.
There exist other storage entries that aren't mount specific. For example, the Integrated
Storage Autopilot configuration is an `ignored` storage entry, which allows for disaster recovery
secondaries to have a different configuration than their primary. Tokens and leases are written to
`local` storage entries.
## Performance Replication
In Performance Replication, secondaries keep track of their own tokens and leases
@@ -222,9 +249,9 @@ its encrypted barrier.
## Mutual TLS and Load Balancers
Vault generates its own certificates for cluster members. All replication traffic
uses the cluster port using these Vault-generated certificates after initial
bootstrapping. Because of this, the cluster traffic can NOT be terminated at the
Vault generates its own certificates for cluster members. All replication traffic
uses the cluster port using these Vault-generated certificates after initial
bootstrapping. Because of this, the cluster traffic can NOT be terminated at the
cluster port at a load balancer level.
## Tutorial