[DOCS] Add 'Selecting gateway and seed nodes' section to CCS docs (#48297)
This commit is contained in:
parent
e65c60915a
commit
f4fa61b2f2
|
@ -246,9 +246,31 @@ PUT _cluster/settings
|
|||
If `cluster_two` is disconnected or unavailable during a {ccs}, {es} won't
|
||||
include matching documents from that cluster in the final results.
|
||||
|
||||
[float]
|
||||
[discrete]
|
||||
[[ccs-works]]
|
||||
== How {ccs} works
|
||||
|
||||
include::./remote-clusters.asciidoc[tag=how-remote-clusters-work]
|
||||
|
||||
[discrete]
|
||||
[[ccs-gateway-seed-nodes]]
|
||||
=== Selecting gateway and seed nodes
|
||||
|
||||
Gateway and seed nodes need to be accessible from the local cluster via your
|
||||
network.
|
||||
|
||||
By default, any master-ineligible node can act as a gateway node. If wanted,
|
||||
you can define the gateway nodes for a cluster by setting
|
||||
`cluster.remote.node.attr.gateway` to `true`.
|
||||
|
||||
For {ccs}, we recommend you use gateway nodes that are capable of serving as
|
||||
<<coordinating-node,coordinating nodes>> for search requests. If
|
||||
wanted, the seed nodes for a cluster can be a subset of these gateway nodes.
|
||||
|
||||
[discrete]
|
||||
[[ccs-network-delays]]
|
||||
=== How {ccs} handles network delays
|
||||
|
||||
Because {ccs} involves sending requests to remote clusters, any network delays
|
||||
can impact search speed. To avoid slow searches, {ccs} offers two options for
|
||||
handling network delays:
|
||||
|
@ -272,11 +294,9 @@ latency.
|
|||
+
|
||||
See <<ccs-unmin-roundtrips>> to learn how this option works.
|
||||
|
||||
|
||||
|
||||
[float]
|
||||
[[ccs-min-roundtrips]]
|
||||
=== Minimize network roundtrips
|
||||
==== Minimize network roundtrips
|
||||
|
||||
Here's how {ccs} works when you minimize network roundtrips.
|
||||
|
||||
|
@ -301,7 +321,7 @@ image:images/ccs/ccs-min-roundtrip-client-response.png[]
|
|||
|
||||
[float]
|
||||
[[ccs-unmin-roundtrips]]
|
||||
=== Don't minimize network roundtrips
|
||||
==== Don't minimize network roundtrips
|
||||
|
||||
Here's how {ccs} works when you don't minimize network roundtrips.
|
||||
|
||||
|
|
|
@ -13,12 +13,16 @@ connections to a remote cluster. This functionality is used in
|
|||
<<modules-cross-cluster-search,{ccs}>>.
|
||||
endif::[]
|
||||
|
||||
// tag::how-remote-clusters-work[]
|
||||
Remote cluster connections work by configuring a remote cluster and connecting
|
||||
only to a limited number of nodes in that remote cluster. Each remote cluster
|
||||
is referenced by 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 to be connected to as part of remote
|
||||
cluster requests. All the communication required between different clusters
|
||||
cluster requests.
|
||||
// end::how-remote-clusters-work[]
|
||||
|
||||
All the communication required between different clusters
|
||||
goes through the <<modules-transport,transport layer>>. Remote cluster
|
||||
connections consist of uni-directional connections from the coordinating
|
||||
node to the selected remote _gateway nodes_ only.
|
||||
|
|
Loading…
Reference in New Issue