mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-25 07:37:19 -04:00
7142b47e69
* Adds a prerequisites section covering remote cluster config, node roles, and security. * Moves existing content about remote cluster config to the prereqs. * Updates the remote cluster docs to include information about eligible gateway nodes and tagging for gateway nodes. Closes https://github.com/elastic/elasticsearch/issues/72001
104 lines
4.8 KiB
Text
104 lines
4.8 KiB
Text
[[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.
|
|
|
|
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, similar to the rules for
|
|
<<rolling-upgrades,rolling upgrades>>:
|
|
** 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]
|
|
====
|
|
|
|
* *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. Similar
|
|
to the sniff <<gateway-nodes-selection,gateway nodes>>, the remote
|
|
connections are subject to the same version compatibility rules as
|
|
<<rolling-upgrades,rolling upgrades>>.
|
|
|
|
Proxy mode has the same version compatibility requirements as sniff mode.
|
|
|
|
[%collapsible]
|
|
[[proxy-mode-version-compatibility]]
|
|
.Version compatibility matrix
|
|
====
|
|
include::remote-clusters-shared.asciidoc[tag=remote-cluster-compatibility-matrix]
|
|
====
|
|
|
|
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[]
|