mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-24 23:27:25 -04:00
117 lines
5.1 KiB
Text
117 lines
5.1 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}.
|
|
|
|
[[remote-clusters-ccr]]
|
|
[discrete]
|
|
=== {ccr-cap}
|
|
|
|
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.
|
|
|
|
[[remote-clusters-ccs]]
|
|
[discrete]
|
|
=== {ccs-cap}
|
|
|
|
<<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].
|
|
|
|
[[add-remote-clusters]]
|
|
[discrete]
|
|
=== Add remote clusters
|
|
|
|
NOTE: The instructions that follow describe how to create a remote connection from a
|
|
self-managed cluster. You can also set up {ccs} and {ccr} from an
|
|
link:https://www.elastic.co/guide/en/cloud/current/ec-enable-ccs.html[{ess} deployment]
|
|
or from an link:https://www.elastic.co/guide/en/cloud-enterprise/current/ece-enable-ccs.html[{ece} deployment].
|
|
|
|
To add remote clusters, you can choose between
|
|
<<remote-clusters-security-models,two security models>> and
|
|
<<sniff-proxy-modes,two connection modes>>. Both security models are compatible
|
|
with either of the connection modes.
|
|
|
|
[[remote-clusters-security-models]]
|
|
[discrete]
|
|
==== Security models
|
|
|
|
API key based security model::
|
|
For clusters on version 8.14 or later, you can use an API key to authenticate
|
|
and authorize cross-cluster operations to a remote cluster. This model offers
|
|
administrators of both the local and the remote cluster fine-grained access
|
|
controls. <<remote-clusters-api-key>>.
|
|
|
|
Certificate based security model::
|
|
Uses mutual TLS authentication for cross-cluster operations. User authentication
|
|
is performed on the local cluster and a user's role names are passed to the
|
|
remote cluster. In this model, a superuser on the local cluster gains total read
|
|
access to the remote cluster, so it is only suitable for clusters that are in
|
|
the same security domain. <<remote-clusters-cert>>.
|
|
|
|
[[sniff-proxy-modes]]
|
|
[discrete]
|
|
==== Connection modes
|
|
|
|
[[sniff-mode]]
|
|
Sniff mode::
|
|
In sniff mode, a cluster alias is registered with a name of your choosing and a
|
|
list of addresses of _seed_ nodes specified with the
|
|
`cluster.remote.<cluster_alias>.seeds` setting. When you register a remote
|
|
cluster using sniff mode, {es} retrieves from one of the seed nodes the
|
|
addresses of up to three _gateway nodes_. Each `remote_cluster_client` node in
|
|
the local {es} cluster then opens several TCP connections to the publish
|
|
addresses of the gateway nodes. This mode therefore requires that the gateway
|
|
nodes' publish addresses are accessible to nodes in the local cluster.
|
|
+
|
|
Sniff mode is the default connection mode. See <<remote-cluster-sniff-settings>>
|
|
for more information about configuring sniff 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.
|
|
* *role*: By default, any non-<<master-node-role,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]]
|
|
Proxy mode::
|
|
In proxy mode, a cluster alias is registered with a name of your choosing and
|
|
the address of a TCP (layer 4) reverse proxy specified with the
|
|
`cluster.remote.<cluster_alias>.proxy_address` setting. You must configure this
|
|
proxy to route connections to one or more nodes of the remote cluster. When you
|
|
register a remote cluster using proxy mode, {es} opens several TCP connections
|
|
to the proxy address and uses these connections to communicate with the remote
|
|
cluster. In proxy mode {es} disregards the publish addresses of the remote
|
|
cluster nodes which means that the publish addresses of the remote cluster
|
|
nodes need not be accessible to the local cluster.
|
|
+
|
|
Proxy mode is not the default connection mode, so you must set
|
|
`cluster.remote.<cluster_alias>.mode: proxy` to use it. See
|
|
<<remote-cluster-proxy-settings>> for more information about configuring proxy
|
|
mode.
|
|
+
|
|
Proxy mode has the same <<gateway-nodes-selection, version compatibility
|
|
requirements>> as sniff mode.
|
|
|
|
include::cluster/remote-clusters-api-key.asciidoc[]
|
|
|
|
include::cluster/remote-clusters-cert.asciidoc[]
|
|
|
|
include::cluster/remote-clusters-migration.asciidoc[]
|
|
|
|
include::cluster/remote-clusters-settings.asciidoc[]
|
|
|
|
include::cluster/remote-clusters-troubleshooting.asciidoc[]
|