elasticsearch/docs/reference/modules/remote-clusters.asciidoc

[[remote-clusters]]
== Remote clusters
You can connect a local cluster to other {es} clusters, known as _remote
clusters_. Remote clusters can be located in different datacenters or 
geographic regions, and contain indices or data streams that can be replicated
with {ccr} or searched by a local cluster using {ccs}.

With <<xpack-ccr,{ccr}>>, you ingest data to an index on a remote cluster. This 
_leader_ index is replicated to one or more read-only _follower_ indices on your local cluster. Creating a multi-cluster architecture with {ccr} enables you to 
configure disaster recovery, bring data closer to your users, or establish a 
centralized reporting cluster to process reports locally.

<<modules-cross-cluster-search,{ccs-cap}>> enables you to run a search request
against one or more remote clusters. This capability provides each region with a
global view of all clusters, allowing you to send a search request from a local
cluster and return results from all connected remote clusters. For full {ccs}
capabilities, the local and remote cluster must be on the same
{subscriptions}[subscription level].

Enabling and configuring security is important on both local and remote
clusters. When connecting a local cluster to remote clusters, an {es} superuser
(such as the `elastic` user) on the local cluster gains total read access to the
remote clusters. To use {ccr} and {ccs} safely, 
<<remote-clusters-security,enable security>> on all connected clusters 
and configure Transport Layer Security (TLS) on at least the transport level on
every node.

Furthermore, a local administrator at the operating system level
with sufficient access to {es} configuration files and private keys can
potentially take over a remote cluster. Ensure that your security strategy
includes securing local _and_ remote clusters at the operating system level.

To register a remote cluster,
<<remote-clusters-connect,connect the local cluster>> to nodes in the
remote cluster using sniff mode (default) or proxy mode. After registering
remote clusters, <<remote-clusters-privileges,configure privileges>> for {ccr} 
and {ccs}.

[[sniff-mode]]
[discrete]
=== Sniff mode

In sniff mode, a cluster is created using a name and a list of seed nodes. When
a remote cluster is registered, its cluster state is retrieved from one of the
seed nodes and up to three _gateway nodes_ are selected as part of remote
cluster requests. This mode requires that the gateway node's publish addresses
are accessible by the local cluster.

Sniff mode is the default connection mode.

[[gateway-nodes-selection]]
The _gateway nodes_ selection depends on the following criteria:

* *version*: Remote nodes must be compatible with the cluster they are
registered to:
** Any node can communicate with another node on the same
major version. For example, 7.0 can talk to any 7.x node.
** Only nodes on the last minor version of a certain major version can
communicate with nodes on the following major version. In the 6.x series, 6.8
can communicate with any 7.x node, while 6.7 can only communicate with 7.0.
** Version compatibility is
symmetric, meaning that if 6.7 can communicate with 7.0, 7.0 can also
communicate with 6.7. The following table depicts version compatibility between
local and remote nodes.
+
[%collapsible%open]
.Version compatibility table
====
include::remote-clusters-shared.asciidoc[tag=remote-cluster-compatibility-matrix]
====

IMPORTANT: Elastic only supports {ccs} on a subset of these configurations. See
<<ccs-supported-configurations>>.

* *role*: By default, any non-<<master-node,master-eligible>> node can act as a
gateway node. Dedicated master nodes are never selected as gateway nodes.

* *attributes*: You can define the gateway nodes for a cluster by setting
<<cluster-remote-node-attr,`cluster.remote.node.attr.gateway`>> to `true`.
However, such nodes still have to satisfy the two above requirements.

[[proxy-mode]]
[discrete]
=== Proxy mode
In proxy mode, a cluster is created using a name and a single proxy address.
When you register a remote cluster, a configurable number of socket connections
are opened to the proxy address. The proxy is required to route those
connections to the remote cluster. Proxy mode does not require remote cluster
nodes to have accessible publish addresses.

The proxy mode is not the default connection mode and must be configured.
Proxy mode has the same <<gateway-nodes-selection, version compatibility
requirements>> as sniff mode. 

[%collapsible]
[[proxy-mode-version-compatibility]]
.Version compatibility matrix
====
include::remote-clusters-shared.asciidoc[tag=remote-cluster-compatibility-matrix]
====

IMPORTANT: Elastic only supports {ccs} on a subset of these configurations. See
<<ccs-supported-configurations>>.

include::cluster/remote-clusters-security.asciidoc[]
include::cluster/remote-clusters-connect.asciidoc[]
include::../../../x-pack/docs/en/security/authentication/remote-clusters-privileges.asciidoc[]
include::cluster/remote-clusters-settings.asciidoc[]