Correctly setting up networking is very important for your nodes and cluster.
There are a lot of different installation scenarios and networking issues: the first step for configuring the nodes to build a cluster is to correctly set the node discovery.
You need a working Elasticsearch installation and know your current networking configuration (that is, IP).
For configuring networking, we will perform the following steps:
- Open the Elasticsearch configuration file with your favorite text editor.
- Using standard Elasticsearch configuration
config/elasticsearch.ymlfile, your node is configured to bind on all your machine interfaces and does discovery broadcasting events to the nodes listed indiscovery.zen.ping.unicast.hosts. This means that it sends signals to the machine in unicast list and waits for a response. If a node responds to it, they can join in a cluster. - If another node is available in the same LAN, they join the cluster.
- To customize the network preferences, you need to change some parameters in the
elasticsearch.ymlfile, as follows:
cluster.name: ESCookBook
node.name: "Node1"
network.host: 192.168.1.35
discovery.zen.ping.unicast.hosts:
["192.168.1.35","192.168.1.36[9300-9400]"]This configuration sets the cluster name to Elasticsearch, the node name, the network address, and it tries to bind the node to the address given in the discovery section:
- We can check the configuration during node loading.
- We can now start the server and check whether the networking is configured:
[...][INFO ][o.e.p.PluginsService ] [PARO] loaded plugin
[ingest-geoip] [...][INFO ][o.e.p.PluginsService ] [PARO] loaded
plugin [lang-python] [...][INFO ][o.e.p.PluginsService ] [PARO]
loaded plugin [sql] [...][INFO ][o.e.n.Node ] [PARO] initialized
[...][INFO ][o.e.n.Node ] [PARO] starting ... [...][INFO ]
[o.e.t.TransportService ] [PARO] publish_address
{192.168.1.35:9300}, bound_addresses {[fe80::1]:9300},
{[::1]:9300}, {192.168.1.35:9300} [...][INFO ]
[o.e.c.s.ClusterService ] [PARO] new_master {PARO}{7kRRhYpeQx-
fub3-1h3sWQ}{EtRxMnNnTJGvp2giGuAxkQ}{127.0.0.1}{192.168.1.35:9300},
reason: zen-disco-elected-as-master ([0] nodes joined) [...]
[INFO ][o.e.h.HttpServer ] [PARO] publish_address
{192.168.1.35:9200}, bound_addresses {[fe80::1]:9200},
{[::1]:9200}, {192.168.1.35:9200} [...][INFO ][o.e.n.Node ] [PARO]
startedIn this case, we have:
- The transport bound to
0:0:0:0:0:0:0:0:9300and192.168.1.35:9300 - The REST HTTP interface bound to
0:0:0:0:0:0:0:0:9200and192.168.1.35:9200
The main important configuration keys for networking management are:
cluster.namesets up the name of the cluster. Only nodes with the same name can join togethernode.name: if not defined, it is automatically assigned by Elasticsearch
It allows defining a name for the node. If you have a lot of nodes on different machine, it is useful to set this name meaningful to easy locate them. Using a valid name is more easy to remember than a generate name such as whqVp_4zQGCgMvJ1CXhcWQ. You always must set up a node.name if you need to monitor your server. Generally, node name is the same of host server name for easy maintenance.
The network.host defines the IP of your machine to be used in bind the node. If your server is on different LANs or you want to limit the bind on only a LAN, you must set this value with your server IP.
The discovery.zen.ping.unicast.hosts allows you to define a list of hosts (with ports or port range) to be used to discover other nodes to join the cluster. This setting allows using the node in LAN where broadcasting is not allowed or auto discovery is not working (that is, packet filtering routers). The referred port is the transport one, usually 9300. The addresses of the hosts list can be a mix of:
- host name, that is,
myhost1 - IP address, that is,
192.168.1.2 - IP address or hostname with the port, that is,
myhost1:9300,192.168.168.1.2:9300 - IP address or hostname with a range of ports, that is,
myhost1:[9300-9400],192.168.168.1.2:[9300-9400]
Before Elasticsearch 5.x, the default network configuration was the auto discovery with broadcast: this behavior is deprecated and removed in version 5.x or above because it generates a lot of issues during cluster management and it doesn't work in cloud deployment and generally in corporate networking due to the block on broadcasting protocol.