mirror of https://github.com/status-im/consul.git
50 lines
3.5 KiB
Plaintext
50 lines
3.5 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: What is Cluster Peering?
|
|
description: >-
|
|
This page details the cluster peering process for connecting Consul clusters across datacenters, including differences between cluster peering and the similar concept of WAN federation.
|
|
---
|
|
|
|
# What is Cluster Peering?
|
|
|
|
~> This page covers features that are currently in _technical preview_. Features and functionality are subject to change. You should never use the technical preview release in secure environments or production scenarios. Features in technical preview may face performance and scaling issues, with limited support options available.
|
|
|
|
Cluster peering is a Consul feature to allow service connectivity between two independent clusters. Similar to WAN Federation, you can use cluster peering to enable service connectivity between partitions in different datacenters.
|
|
|
|
## Overview
|
|
|
|
Cluster peering allows Consul clusters in different datacenters to communicate with each other. The cluster peering process consists of the following steps:
|
|
1. Create a peering token to share with other clusters
|
|
1. Establish a connection between clusters
|
|
1. Make services available to other clusters
|
|
|
|
For detailed instructions on setting up cluster peering with the Consul CLI, refer to [Create and Manage Peering Connections](/docs/connect/cluster-peering/create-manage-peering).
|
|
|
|
### Differences between WAN federation and cluster peering
|
|
|
|
WAN Federation and cluster peering are different ways to connect clusters across datacenters. The most important distinction is that WAN Federation assumes clusters are owned by the same operators, so it uses the gossip protocol to replicate global states like ACLs. As a result, WAN Federation requires a “primary datacenter" to serve as an authority for replicated data.
|
|
|
|
Regardless of whether you connect your clusters through WAN Federation or cluster peering, human and machine users can use either peering method to issue cross-datacenter queries for data, including service endpoints.
|
|
|
|
| | WAN Federation | Cluster Peering |
|
|
| :----------------------------------------------- | :------------: | :-------------: |
|
|
| Connects clusters across datacenters | ✅ | ✅ |
|
|
| Shares support queries and service endpoints | ✅ | ✅ |
|
|
| Connects clusters owned by different operators | ❌ | ✅ |
|
|
| Functions without declaring “primary datacenter” | ❌ | ✅ |
|
|
| Shares key/value stores | ✅ | ❌ |
|
|
| Uses gossip protocol | ✅ | ❌ |
|
|
|
|
## Technical preview limitations
|
|
Not all features and functionality are available in the technical preview release. In particular, be aware of the following limitations:
|
|
|
|
- Mesh gateways for _service to service traffic_ between clusters are available. However, mesh gateways for _server to server traffic_ are not available.
|
|
- Services exported to peered clusters must not be configured as HTTP.
|
|
- Support for dynamic routing such as splits, custom routes, or redirects is not available at this time.
|
|
- The ``consul intention`` CLI command is not supported.
|
|
- [L7 permissions](/docs/connect/l7-traffic) are not supported.
|
|
- Configuring service failover across peers is not supported.
|
|
- Accessing key/value stores across peers is not supported.
|
|
- Consul datacenters that are already federated stay federated.
|
|
- Non-enterprise Consul instances cannot sync services with namespaces outside of the default namespace.
|