mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-25 07:37:19 -04:00
6940673e8a
* [DOCS] Update remote cluster docs * Add files, rename files, write new stuff * Plethora of changes * Add test and update snippets * Redirects, moved files, and test updates * Moved file to x-pack for tests * Remove older CCS page and add redirects * Cleanup, link updates, and some rewrites * Update image * Incorporating user feedback and rewriting much of the remote clusters page * More changes from review feedback * Numerous updates, including request examples for CCS and Kibana * More changes from review feedback * Minor clarifications on security for remote clusters * Incorporate review feedback Co-authored-by: Yang Wang <ywangd@gmail.com> * Some review feedback and some editorial changes Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Yang Wang <ywangd@gmail.com>
106 lines
No EOL
5.3 KiB
Text
106 lines
No EOL
5.3 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
|
|
====
|
|
// tag::remote-cluster-compatibility-matrix[]
|
|
[cols="^,^,^,^,^,^,^,^"]
|
|
|====
|
|
| 7+^h| Local cluster
|
|
h| Remote cluster | 5.0->5.5 | 5.6 | 6.0->6.6 | 6.7 | 6.8 | 7.0 | 7.1->7.x
|
|
| 5.0->5.5 | {yes-icon} | {yes-icon} | {no-icon} | {no-icon} | {no-icon} | {no-icon} | {no-icon}
|
|
| 5.6 | {yes-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {no-icon} | {no-icon}
|
|
| 6.0->6.6 | {no-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {no-icon} | {no-icon}
|
|
| 6.7 | {no-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {no-icon}
|
|
| 6.8 | {no-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {yes-icon}
|
|
| 7.0 | {no-icon} | {no-icon} | {no-icon} | {yes-icon} | {yes-icon} | {yes-icon} | {yes-icon}
|
|
| 7.1->7.x | {no-icon} | {no-icon} | {no-icon} | {no-icon} | {yes-icon} | {yes-icon} | {yes-icon}
|
|
|====
|
|
// end::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>>.
|
|
|
|
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[] |