mirror of
https://github.com/optim-enterprises-bv/vault.git
synced 2025-10-30 10:12:35 +00:00
Add paths filter doc (#13435)
* Add paths filter doc * Add a description about the screenshot * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Update website/content/docs/enterprise/replication.mdx Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com> * Remove extra sentense * Update the diagram * Update the diagram Co-authored-by: Loann Le <84412881+taoism4504@users.noreply.github.com>
This commit is contained in:
Yoko Hyakuna
@@ -47,9 +47,19 @@ replication that is configured between the primary and secondary. These types
|
||||
of relationships are either **disaster recovery** or **performance**
|
||||
relationships.
|
||||
|
||||
## Performance Replication and Disaster Recovery (DR) Replication
|
||||
|
||||
|
||||
The following table shows a capability comparison between disaster recovery and performance replications.
|
||||
|
||||
| Capability | Disaster Recovery | Performance |
|
||||
| -------------------------------------------------------------------------------------------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 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 |
|
||||
|
||||
## Performance Replication
|
||||
|
||||
_Performance Replication_:
|
||||
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).
|
||||
@@ -61,7 +71,48 @@ 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.
|
||||
|
||||
_Disaster Recovery (DR) Replication_:
|
||||
### 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
|
||||
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
|
||||
identifiable data not be physically transferred to locations outside the
|
||||
European Union unless the region or country has an equal rigor of data
|
||||
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.
|
||||
|
||||
You can set filters based on the mount path of the secrets engines and
|
||||
namespaces.
|
||||
|
||||
|
||||
|
||||
In the above example, the `EU_GDPR_data/` path and `office_FR` namespace will
|
||||
not be replicated and remain only on the primary cluster.
|
||||
|
||||
On a similar note, if you want to avoid secondary cluster's data to be
|
||||
replicated, you can mark those secrets engine and/or auth methods **local**.
|
||||
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.
|
||||
|
||||
```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
|
||||
step-by-step instructions.
|
||||
|
||||
|
||||
## Disaster Recovery (DR) Replication
|
||||
|
||||
In disaster recovery (or DR) replication, secondaries share the same underlying configuration,
|
||||
policy, and supporting secrets (K/V values, encryption keys for `transit`, etc) infrastructure
|
||||
as the primary. They also share the same token and lease infrastructure as the primary, as
|
||||
@@ -71,12 +122,6 @@ original primary on the election of the DR secondary.
|
||||
DR is designed to be a mechanism to protect against catastrophic failure of entire clusters.
|
||||
They do not forward service read or write requests until they are elected and become a new primary.
|
||||
|
||||
| Capability | Disaster Recovery | Performance |
|
||||
| -------------------------------------------------------------------------------------------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| 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 |
|
||||
|
||||
For more information on the capabilities of performance and disaster recovery replication, see the Vault Replication [API Documentation](/api/system/replication).
|
||||
|
||||
|
||||
BIN
website/public/img/replication-overview.png
Normal file
BIN
website/public/img/replication-overview.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 482 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 131 KiB After Width: | Height: | Size: 135 KiB |
Reference in New Issue
Block a user