Setting up networking_ElasticSearch Cookbook（Second Edition）-QQ阅读女频古言网

上QQ阅读APP看书，第一时间看更新

Setting up networking

Correctly setting up networking is very important for your nodes and cluster.

There are a lot of different installation scenarios and networking issues; we will cover two kinds of networking setups in this recipe:

A standard installation with an autodiscovery working configuration
A forced IP configuration, used if it is not possible to use autodiscovery

Getting ready

You need a working ElasticSearch installation, and you must know your current networking configuration (such as your IP addresses).

How to do it...

In order to configure networking, we will perform the following steps:

With your favorite text editor application, open the ElasticSearch configuration file. Using the standard ElasticSearch configuration file (config/elasticsearch.yml), your node is configured to bind to all your machine interfaces and does an autodiscovery of the broadcasting events, which means that it sends signals to every machine in the current LAN and waits for a response. If a node responds to this, it can join and be a part of a cluster. If another node is available in the same LAN, it can join the cluster too.

Note

Only nodes that run the same ElasticSearch version and cluster name (the cluster.name option in elasticsearch.yml) can join each other.
To customize the network preferences, you need to change some parameters in the elasticsearch.yml file, such as:
```
cluster.name: elasticsearch
node.name: "My wonderful server"
network.host: 192.168.0.1
discovery.zen.ping.unicast.hosts: ["192.168.0.2","192.168.0.3[9300-9400]"]
```
This configuration sets the cluster name to ElasticSearch, the node name, and the network address, it then tries to bind the node to the address given in the discovery section.

We can check the configuration when the node is being loaded. Now, start the server and check whether the networking is configured. The following code shows how it looks:

[...][INFO ][node            ] [ESCookBook] version[1.4.0.beta1], pid[74304], build[f1585f0/2014-10-16T14:27:12Z]
[...][INFO ][node            ] [ESCookBook] initializing ...
[...][INFO ][plugins         ] [ESCookBook] loaded [transport-thrift, river-twitter, mapper-attachments, lang-python, lang-javascript], sites [head, HQ]
[...][INFO ][node            ] [ESCookBook] initialized
[...][INFO ][node            ] [ESCookBook] starting ...
[...][INFO ][thrift          ] [ESCookBook] bound on port [9500]
[...][INFO ][transport       ] [ESCookBook] bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address {inet[/192.168.1.19:9300]}
[...][INFO ][cluster.service ] [ESCookBook] new_master [ESCookBook][YDYjr0XRQeyQIWGcLzRiVQ][MBPlocal][inet[/192.168.1.19:9300]], reason: zen-disco-join (elected_as_master)
[...][INFO ][discovery       ] [ESCookBook] elasticsearch-cookbook/YDYjr0XRQeyQIWGcLzRiVQ
[...][INFO ][http            ] [ESCookBook] bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/192.168.1.19:9200]}
[...][INFO ][gateway         ] [ESCookBook] recovered [0] indices into cluster_state
[...][INFO ][node            ] [ESCookBook] started

In this case, we see that:

The transport layer binds to 0:0:0:0:0:0:0:0:9300 and 192.168.1.19:9300
The REST HTTP interface binds to 0:0:0:0:0:0:0:0:9200 and 192.168.1.19:9200

How it works...

The following parameters are crucial for the node to start working:

cluster.name: This sets up the name of the cluster. Only nodes with the same name can join together.
node.name: If this field is not defined, it is automatically assigned by ElasticSearch. It allows you to define a name for the node. If you have a lot of nodes on different machines, it is useful to set this name to something meaningful in order to easily locate them. Using a valid name is easier to remember than a system-generated name, such as whqVp_4zQGCgMvJ1CXhcWQ. You must always set up a name for the node.name parameter if you need to monitor your server.
network.host: This defines the IP address of the machine used to bind the node. If your server is on different LANs or you want to limit the bind to only a LAN, you must set this value to your server's IP address.
discovery.zen.ping.unicast.hosts (this is optional if multicast is possible): This allows you to define a list of hosts (with ports or port ranges) to be used in order to discover other nodes to join the cluster. This setting allows you to use the node in a LAN where broadcasting is not allowed or autodiscovery is not working (such as packet-filtering routers). The referred port is the transport port, usually 9300. The addresses of the host list can be a mix of:
- The hostname (such as, myhost1)
- The IP address (such as, 192.168.1.2)
- The IP address or host name with the port, such as myhost1:9300, 192.168.168.1.2:9300
- The IP address or host name with a range of ports (such as, myhost1:[9300-9400], 192.168.168.1.2:[9300-9400])

Defining unicast hosts is generally required only if discovery is not working. The default configuration of ElasticSearch has autodiscovery on nodes in a LAN.