WARNING: Version 6.1 of Elasticsearch has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Transport
editTransport
editThe transport module is used for internal communication between nodes within the cluster. Each call that goes from one node to the other uses the transport module (for example, when an HTTP GET request is processed by one node, and should actually be processed by another node that holds the data).
The transport mechanism is completely asynchronous in nature, meaning that there is no blocking thread waiting for a response. The benefit of using asynchronous communication is first solving the C10k problem, as well as being the ideal solution for scatter (broadcast) / gather operations such as search in Elasticsearch.
TCP Transport
editThe TCP transport is an implementation of the transport module using TCP. It allows for the following settings:
Setting | Description |
---|---|
|
A bind port range. Defaults to |
|
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 |
|
The host address to bind the transport service to. Defaults to |
|
The host address to publish for nodes in the cluster to connect to. Defaults to |
|
Used to set the |
|
The socket connect timeout setting (in
time setting format). Defaults to |
|
Set to |
|
Schedule a regular application-level ping message
to ensure that transport connections between nodes are kept alive. Defaults to
|
It also uses the common network settings.
TCP Transport Profiles
editElasticsearch allows you to bind to multiple ports on different interfaces by the use of transport profiles. See this example configuration
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 bind to -
bind_host
: The host to bind -
publish_host
: The host which is published in informational APIs -
tcp_no_delay
: Configures theTCP_NO_DELAY
option for this socket -
tcp_keep_alive
: Configures theSO_KEEPALIVE
option for this socket -
reuse_address
: Configures theSO_REUSEADDR
option for this socket -
tcp_send_buffer_size
: Configures the send buffer size of the socket -
tcp_receive_buffer_size
: Configures the receive buffer size of the socket
Long-lived idle connections
editElasticsearch opens a number of long-lived TCP connections between each pair of
nodes in the cluster, and some of these connections may be idle for an extended
period of time. Nonetheless, Elasticsearch requires these connections to remain
open, and it can disrupt the operation of the 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.
Transport Tracer
editThe transport module has a dedicated tracer logger which, when activated, logs incoming and out going requests. The log can be dynamically activated
by settings the level of the org.elasticsearch.transport.TransportService.tracer
logger to TRACE
:
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:
PUT _cluster/settings { "transient" : { "transport.tracer.include" : "*", "transport.tracer.exclude" : "internal:discovery/zen/fd*" } }