202 lines
8.3 KiB
Plaintext
202 lines
8.3 KiB
Plaintext
[[modules-transport]]
|
|
=== Transport
|
|
|
|
REST clients send requests to your {es} cluster over <<modules-http,HTTP>>, but
|
|
the node that receives a client request cannot always handle it alone and must
|
|
normally pass it on to other nodes for further processing. It does this using
|
|
the transport networking layer. The transport layer is used for all internal
|
|
communication between nodes within a cluster, all communication with the nodes
|
|
of a <<modules-remote-clusters,remote cluster>>, and also by the
|
|
`TransportClient` in the {es} Java API.
|
|
|
|
[[transport-settings]]
|
|
==== Transport settings
|
|
|
|
The following settings can be configured for the internal transport that
|
|
communicates over TCP. These settings also use the common
|
|
<<modules-network,network settings>>.
|
|
|
|
`transport.port`::
|
|
A bind port range. Defaults to `9300-9400`.
|
|
|
|
`transport.publish_port`::
|
|
The port that other nodes in the cluster
|
|
should use when communicating with this node. Useful when a cluster node
|
|
is behind a proxy or firewall and the `transport.port` is not directly
|
|
addressable from the outside. Defaults to the actual port assigned via
|
|
`transport.port`.
|
|
|
|
`transport.bind_host`::
|
|
The host address to bind the transport service to. Defaults to
|
|
`transport.host` (if set) or `network.bind_host`.
|
|
|
|
`transport.publish_host`::
|
|
The host address to publish for nodes in the cluster to connect to.
|
|
Defaults to `transport.host` (if set) or `network.publish_host`.
|
|
|
|
`transport.host`::
|
|
Used to set the `transport.bind_host` and the `transport.publish_host`.
|
|
|
|
`transport.connect_timeout`::
|
|
The connect timeout for initiating a new connection (in
|
|
time setting format). Defaults to `30s`.
|
|
|
|
`transport.compress`::
|
|
Set to `true` to enable compression (`DEFLATE`) between
|
|
all nodes. Defaults to `false`.
|
|
|
|
`transport.ping_schedule`::
|
|
Schedule a regular application-level ping message
|
|
to ensure that transport connections between nodes are kept alive. Defaults to
|
|
`5s` in the transport client and `-1` (disabled) elsewhere. It is preferable
|
|
to correctly configure TCP keep-alives instead of using this feature, because
|
|
TCP keep-alives apply to all kinds of long-lived connections and not just to
|
|
transport connections.
|
|
|
|
`transport.tcp.no_delay`::
|
|
Enable or disable the {wikipedia}/Nagle%27s_algorithm[TCP no delay]
|
|
setting. Defaults to `network.tcp.no_delay`.
|
|
|
|
`transport.tcp.keep_alive`::
|
|
Configures the `SO_KEEPALIVE` option for this socket, which
|
|
determines whether it sends TCP keepalive probes.
|
|
Defaults to `network.tcp.keep_alive`.
|
|
|
|
`transport.tcp.keep_idle`::
|
|
Configures the `TCP_KEEPIDLE` option for this socket, which
|
|
determines the time in seconds that a connection must be idle before
|
|
starting to send TCP keepalive probes. Defaults to `network.tcp.keep_idle` if set,
|
|
or the system default otherwise.
|
|
This value cannot exceed `300` seconds. In cases where the system default
|
|
is higher than `300`, the value is automatically lowered to `300`. Only applicable on
|
|
Linux and macOS, and requires Java 11 or newer.
|
|
|
|
`transport.tcp.keep_interval`::
|
|
Configures the `TCP_KEEPINTVL` option for this socket,
|
|
which determines the time in seconds between sending TCP keepalive probes.
|
|
Defaults to `network.tcp.keep_interval` if set, or the system default otherwise.
|
|
This value cannot exceed `300` seconds. In cases where the system default is higher than `300`,
|
|
the value is automatically lowered to `300`. Only applicable on Linux and macOS,
|
|
and requires Java 11 or newer.
|
|
|
|
`transport.tcp.keep_count`::
|
|
Configures the `TCP_KEEPCNT` option for this socket, which
|
|
determines the number of unacknowledged TCP keepalive probes that may be
|
|
sent on a connection before it is dropped. Defaults to `network.tcp.keep_count`
|
|
if set, or the system default otherwise. Only applicable on Linux and macOS, and
|
|
requires Java 11 or newer.
|
|
|
|
`transport.tcp.reuse_address`::
|
|
Should an address be reused or not. Defaults to `network.tcp.reuse_address`.
|
|
|
|
`transport.tcp.send_buffer_size`::
|
|
The size of the TCP send buffer (specified with <<size-units,size units>>).
|
|
Defaults to `network.tcp.send_buffer_size`.
|
|
|
|
`transport.tcp.receive_buffer_size`::
|
|
The size of the TCP receive buffer (specified with <<size-units,size units>>).
|
|
Defaults to `network.tcp.receive_buffer_size`.
|
|
|
|
[[transport-profiles]]
|
|
===== Transport profiles
|
|
|
|
Elasticsearch allows you to bind to multiple ports on different interfaces by
|
|
the use of transport profiles. See this example configuration
|
|
|
|
[source,yaml]
|
|
--------------
|
|
transport.profiles.default.port: 9300-9400
|
|
transport.profiles.default.bind_host: 10.0.0.1
|
|
transport.profiles.client.port: 9500-9600
|
|
transport.profiles.client.bind_host: 192.168.0.1
|
|
transport.profiles.dmz.port: 9700-9800
|
|
transport.profiles.dmz.bind_host: 172.16.1.2
|
|
--------------
|
|
|
|
The `default` profile is special. It is used as a fallback for any other
|
|
profiles, if those do not have a specific configuration setting set, and is how
|
|
this node connects to other nodes in the cluster.
|
|
|
|
The following parameters can be configured on each transport profile, as in the
|
|
example above:
|
|
|
|
* `port`: The port to which to bind.
|
|
* `bind_host`: The host to which to bind.
|
|
* `publish_host`: The host which is published in informational APIs.
|
|
|
|
Profiles also support all the other transport settings specified in the
|
|
<<transport-settings,transport settings>> section, and use these as defaults.
|
|
For example, `transport.profiles.client.tcp.reuse_address` can be explicitly
|
|
configured, and defaults otherwise to `transport.tcp.reuse_address`.
|
|
|
|
[[long-lived-connections]]
|
|
===== Long-lived idle connections
|
|
|
|
A transport connection between two nodes is made up of a number of long-lived
|
|
TCP connections, some of which may be idle for an extended period of time.
|
|
Nonetheless, Elasticsearch requires these connections to remain open, and it
|
|
can disrupt the operation of your cluster if any inter-node connections are
|
|
closed by an external influence such as a firewall. It is important to
|
|
configure your network to preserve long-lived idle connections between
|
|
Elasticsearch nodes, for instance by leaving `tcp.keep_alive` enabled and
|
|
ensuring that the keepalive interval is shorter than any timeout that might
|
|
cause idle connections to be closed, or by setting `transport.ping_schedule` if
|
|
keepalives cannot be configured. Devices which drop connections when they reach
|
|
a certain age are a common source of problems to Elasticsearch clusters, and
|
|
must not be used.
|
|
|
|
[[request-compression]]
|
|
===== Request compression
|
|
|
|
By default, the `transport.compress` setting is `false` and network-level
|
|
request compression is disabled between nodes in the cluster. This default
|
|
normally makes sense for local cluster communication as compression has a
|
|
noticeable CPU cost and local clusters tend to be set up with fast network
|
|
connections between nodes.
|
|
|
|
The `transport.compress` setting always configures local cluster request
|
|
compression and is the fallback setting for remote cluster request compression.
|
|
If you want to configure remote request compression differently than local
|
|
request compression, you can set it on a per-remote cluster basis using the
|
|
<<remote-cluster-settings,`cluster.remote.${cluster_alias}.transport.compress` setting>>.
|
|
|
|
|
|
[[response-compression]]
|
|
===== Response compression
|
|
|
|
The compression settings do not configure compression for responses. {es} will
|
|
compress a response if the inbound request was compressed--even when compression
|
|
is not enabled. Similarly, {es} will not compress a response if the inbound
|
|
request was uncompressed--even when compression is enabled.
|
|
|
|
|
|
[[transport-tracer]]
|
|
==== Transport tracer
|
|
|
|
The transport layer has a dedicated tracer logger which, when activated, logs incoming and out going requests. The log can be dynamically activated
|
|
by setting the level of the `org.elasticsearch.transport.TransportService.tracer` logger to `TRACE`:
|
|
|
|
[source,console]
|
|
--------------------------------------------------
|
|
PUT _cluster/settings
|
|
{
|
|
"transient" : {
|
|
"logger.org.elasticsearch.transport.TransportService.tracer" : "TRACE"
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
|
|
You can also control which actions will be traced, using a set of include and exclude wildcard patterns. By default every request will be traced
|
|
except for fault detection pings:
|
|
|
|
[source,console]
|
|
--------------------------------------------------
|
|
PUT _cluster/settings
|
|
{
|
|
"transient" : {
|
|
"transport.tracer.include" : "*",
|
|
"transport.tracer.exclude" : "internal:coordination/fault_detection/*"
|
|
}
|
|
}
|
|
--------------------------------------------------
|