mirror of
https://github.com/elastic/elasticsearch.git
synced 2025-04-25 07:37:19 -04:00
792f9c1647
* [DOCS] Remote cluster migration guide * Review feedback * Clarify that any extra local privileges will be suppressed by the cross-cluster API key’s privileges
99 lines
4 KiB
Text
99 lines
4 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
|
|
|
|
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::
|
|
beta:[]
|
|
For clusters on version 8.10 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 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.
|
|
* *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]]
|
|
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.
|
|
|
|
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[]
|