diff --git a/website/content/docs/enterprise/replication.mdx b/website/content/docs/enterprise/replication.mdx index 8a1977f7da..40164b4530 100644 --- a/website/content/docs/enterprise/replication.mdx +++ b/website/content/docs/enterprise/replication.mdx @@ -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 +![](/img/replication-overview.png) + +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. + +![Performance Replication - primary](/img/vault-mount-filter-7.png) + +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). diff --git a/website/public/img/replication-overview.png b/website/public/img/replication-overview.png new file mode 100644 index 0000000000..32cdbfc195 Binary files /dev/null and b/website/public/img/replication-overview.png differ diff --git a/website/public/img/vault-mount-filter-7.png b/website/public/img/vault-mount-filter-7.png index af154af462..90a4e871b0 100644 Binary files a/website/public/img/vault-mount-filter-7.png and b/website/public/img/vault-mount-filter-7.png differ