2018-10-20 08:33:59 -04:00
|
|
|
[[modules-remote-clusters]]
|
|
|
|
== Remote clusters
|
|
|
|
|
|
|
|
ifndef::include-xpack[]
|
2019-02-19 14:53:35 -05:00
|
|
|
The _remote clusters_ module enables you to establish uni-directional
|
|
|
|
connections to a remote cluster. This functionality is used in
|
2018-10-20 08:33:59 -04:00
|
|
|
<<modules-cross-cluster-search,cross-cluster search>>.
|
|
|
|
endif::[]
|
|
|
|
ifdef::include-xpack[]
|
2019-02-19 14:53:35 -05:00
|
|
|
The _remote clusters_ module enables you to establish uni-directional
|
|
|
|
connections to a remote cluster. This functionality is used in
|
|
|
|
{stack-ov}/xpack-ccr.html[cross-cluster replication] and
|
2018-10-20 08:33:59 -04:00
|
|
|
<<modules-cross-cluster-search,cross-cluster search>>.
|
|
|
|
endif::[]
|
|
|
|
|
|
|
|
Remote cluster connections work by configuring a remote cluster and connecting
|
|
|
|
only to a limited number of nodes in the remote cluster. Each remote cluster is
|
2019-02-19 14:53:35 -05:00
|
|
|
referenced by a name and a list of seed nodes. When a remote cluster is
|
2018-10-20 08:33:59 -04:00
|
|
|
registered, its cluster state is retrieved from one of the seed nodes so that by
|
|
|
|
default up to three _gateway nodes_ are selected to be connected to as part of
|
|
|
|
remote cluster requests. Remote cluster connections consist of uni-directional
|
|
|
|
connections from the coordinating node to the previously selected remote nodes
|
2019-02-19 14:53:35 -05:00
|
|
|
only. You can tag which nodes should be selected by using node attributes (see <<remote-cluster-settings>>).
|
2018-10-20 08:33:59 -04:00
|
|
|
|
|
|
|
Each node in a cluster that has remote clusters configured connects to one or
|
|
|
|
more _gateway nodes_ and uses them to federate requests to the remote cluster.
|
|
|
|
|
|
|
|
[float]
|
|
|
|
[[configuring-remote-clusters]]
|
|
|
|
=== Configuring Remote Clusters
|
|
|
|
|
|
|
|
Remote clusters can be specified globally using
|
|
|
|
<<cluster-update-settings,cluster settings>> (which can be updated dynamically),
|
|
|
|
or local to individual nodes using the `elasticsearch.yml` file.
|
|
|
|
|
|
|
|
If a remote cluster is configured via `elasticsearch.yml` only the nodes with
|
|
|
|
that configuration will be able to connect to the remote cluster. In other
|
|
|
|
words, functionality that relies on remote cluster requests will have to be
|
|
|
|
driven specifically from those nodes. Remote clusters set via the
|
|
|
|
<<cluster-update-settings,cluster settings API>> will be available on every node
|
|
|
|
in the cluster.
|
|
|
|
|
|
|
|
The `elasticsearch.yml` config file for a node that connects to remote clusters
|
|
|
|
needs to list the remote clusters that should be connected to, for instance:
|
|
|
|
|
|
|
|
[source,yaml]
|
|
|
|
--------------------------------
|
|
|
|
cluster:
|
|
|
|
remote:
|
|
|
|
cluster_one: <1>
|
|
|
|
seeds: 127.0.0.1:9300
|
|
|
|
cluster_two: <1>
|
|
|
|
seeds: 127.0.0.1:9301
|
|
|
|
|
|
|
|
--------------------------------
|
|
|
|
<1> `cluster_one` and `cluster_two` are arbitrary _cluster aliases_ representing
|
|
|
|
the connection to each cluster. These names are subsequently used to distinguish
|
|
|
|
between local and remote indices.
|
|
|
|
|
|
|
|
The equivalent example using the <<cluster-update-settings,cluster settings
|
|
|
|
API>> to add remote clusters to all nodes in the cluster would look like the
|
|
|
|
following:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------
|
|
|
|
PUT _cluster/settings
|
|
|
|
{
|
|
|
|
"persistent": {
|
|
|
|
"cluster": {
|
|
|
|
"remote": {
|
|
|
|
"cluster_one": {
|
|
|
|
"seeds": [
|
|
|
|
"127.0.0.1:9300"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
"cluster_two": {
|
|
|
|
"seeds": [
|
|
|
|
"127.0.0.1:9301"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
"cluster_three": {
|
|
|
|
"seeds": [
|
|
|
|
"127.0.0.1:9302"
|
|
|
|
]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------
|
|
|
|
// CONSOLE
|
|
|
|
// TEST[setup:host]
|
|
|
|
// TEST[s/127.0.0.1:9300/\${transport_host}/]
|
|
|
|
|
|
|
|
A remote cluster can be deleted from the cluster settings by setting its seeds
|
|
|
|
to `null`:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------
|
|
|
|
PUT _cluster/settings
|
|
|
|
{
|
|
|
|
"persistent": {
|
|
|
|
"cluster": {
|
|
|
|
"remote": {
|
|
|
|
"cluster_three": {
|
|
|
|
"seeds": null <1>
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------
|
|
|
|
// CONSOLE
|
|
|
|
// TEST[continued]
|
|
|
|
<1> `cluster_three` would be removed from the cluster settings, leaving
|
|
|
|
`cluster_one` and `cluster_two` intact.
|
|
|
|
|
|
|
|
[float]
|
|
|
|
[[remote-cluster-settings]]
|
|
|
|
=== Remote cluster settings
|
|
|
|
|
|
|
|
`cluster.remote.connections_per_cluster`::
|
|
|
|
|
|
|
|
The number of gateway nodes to connect to per remote cluster. The default is
|
|
|
|
`3`.
|
|
|
|
|
|
|
|
`cluster.remote.initial_connect_timeout`::
|
|
|
|
|
|
|
|
The time to wait for remote connections to be established when the node
|
|
|
|
starts. The default is `30s`.
|
|
|
|
|
|
|
|
`cluster.remote.node.attr`::
|
|
|
|
|
|
|
|
A node attribute to filter out nodes that are eligible as a gateway node in
|
|
|
|
the remote cluster. For instance a node can have a node attribute
|
|
|
|
`node.attr.gateway: true` such that only nodes with this attribute will be
|
|
|
|
connected to if `cluster.remote.node.attr` is set to `gateway`.
|
|
|
|
|
|
|
|
`cluster.remote.connect`::
|
|
|
|
|
|
|
|
By default, any node in the cluster can act as a cross-cluster client and
|
|
|
|
connect to remote clusters. The `cluster.remote.connect` setting can be set to
|
|
|
|
`false` (defaults to `true`) to prevent certain nodes from connecting to
|
|
|
|
remote clusters. Remote cluster requests must be sent to a node that is
|
|
|
|
allowed to act as a cross-cluster client.
|
|
|
|
|
|
|
|
`cluster.remote.${cluster_alias}.skip_unavailable`::
|
|
|
|
|
|
|
|
Per cluster boolean setting that allows to skip specific clusters when no
|
|
|
|
nodes belonging to them are available and they are the targetof a remote
|
|
|
|
cluster request. Default is `false`, meaning that all clusters are mandatory
|
|
|
|
by default, but they can selectively be made optional by setting this setting
|
|
|
|
to `true`.
|
|
|
|
|
2018-10-31 12:32:53 -04:00
|
|
|
`cluster.remote.${cluster_alias}.transport.ping_schedule`::
|
|
|
|
|
|
|
|
Sets the time interval between regular application-level ping messages that
|
|
|
|
are sent to ensure that transport connections to nodes belonging to remote
|
|
|
|
clusters are kept alive. If set to `-1`, application-level ping messages to
|
|
|
|
this remote cluster are not sent. If unset, application-level ping messages
|
|
|
|
are sent according to the global `transport.ping_schedule` setting, which
|
|
|
|
defaults to ``-1` meaning that pings are not sent.
|
|
|
|
|
2018-12-18 15:09:58 -05:00
|
|
|
`cluster.remote.${cluster_alias}.transport.compress`::
|
|
|
|
|
|
|
|
Per cluster boolean setting that enables you to configure compression for
|
|
|
|
requests to a specific remote cluster. This setting impacts only requests
|
|
|
|
sent to the remote cluster. If the inbound request is compressed,
|
|
|
|
Elasticsearch compresses the response. If unset, the global
|
|
|
|
`transport.compress` is used as the fallback setting.
|
|
|
|
|
2018-10-20 08:33:59 -04:00
|
|
|
[float]
|
|
|
|
[[retrieve-remote-clusters-info]]
|
|
|
|
=== Retrieving remote clusters info
|
|
|
|
|
2019-02-19 14:53:35 -05:00
|
|
|
You can use the <<cluster-remote-info, remote cluster info API>> to retrieve
|
2018-10-20 08:33:59 -04:00
|
|
|
information about the configured remote clusters, as well as the remote nodes
|
|
|
|
that the node is connected to.
|