mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-25 07:37:19 -04:00
4782cf4d91
The reference manual includes docs on version compatibility in various places, but it's not clear that these docs only apply to released versions and that the rules for pre-release versions are stricter than folks expect. This commit adds some words to the docs for unreleased versions which explains this subtlety.
102 lines
4.7 KiB
Text
102 lines
4.7 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*: Dedicated master nodes are never selected as gateway nodes.
|
|
* *attributes*: You can tag which nodes should be selected
|
|
(see <<remote-clusters-settings,remote cluster settings>>), though such tagged 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[]
|