Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

A cluster is a collection of nodes.

Being a cluster of Elasticsearch nodes, Java (at least version 8) is required, so the java-1.8.0-openjdk package was installed on each node.

Having the Java dependency satisfied, the next step was to install the elasticsearch package on each cluster node, that is not in the pipeline node. For more information see Install Elasticsearch with RPM.

On coordinating node, along with elasticsearch, the kibana package was installed, too. For more information see Install Kibana with RPM.

On pipeline node was installed the logstash package. For more information see Installing Logstash.

The filebeat package was installed in a dhcp server and in the freeRadius server which implements the Eduroam Service Provider. For more information see Repositories for APT and YUM.

All the packages implementing the cluster's components (elasticsearch, logstash, kibana, filebeat) must be of the same version. This setup is about version 7.8.0.

System Configuration

Each node’s hostname is set to its FQDN, according to the values shown in the VMs DNS table. This value is referenced in the configuration file of Elasticsearch.

It is recommended to disable system swapping, which can result in parts of JVM Heap or even its executable pages being swapped out to disk.

Various communications take place in a cluster, with their connections requiring specific ports being opened in the firewall. The following

...

table represents our situation.

NodeOpen ports
wifimon-node{1,2,3}.rash.al

...

9200/tcp, 9300/tcp
wifimon-kibana.rash.al

...

9200/tcp, 9300/tcp, 5601/tcp
wifimon-logstash.rash.al

...

5044/tcp

Port 9200/tcp is used to query the cluster using the Elasticsearch REST API. Port 9300/tcp is used for internal communication between cluster nodes. Port 5044/tcp is where Logstash listens for beats of log events sent from Filebeat. Port 5601/tcp is used to access Kibana platform from the browser.

SSL/TLS Certificates

The cluster communication is secured by configuring SSL/TLS. The elasticsearch-certutil was used to generate a CA certificate utilized for signing while generating the cluster components certificates. This utility comes with the elasticsearch installation, and in this case was used the one installed in the wifimon-kibana.rash.al node.

...

Code Block
title/etc/elasticsearch/elasticearch.yml
cluster.name: wifimon
node.name: ${HOSTNAME}
node.master: true
node.voting_only: false
node.data: true
node.ingest: true
node.ml: false
cluster.remote.connect: false
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: wifimon-node3.rash.al
discovery.seed_hosts: [
 "wifimon-node1.rash.al",
 "wifimon-node2.rash.al",
 "wifimon-node3.rash.al"
]
#cluster.initial_master_nodes: [
# "wifimon-node1.rash.al",
# "wifimon-node2.rash.al",
# "wifimon-node3.rash.al"
#]
xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: full
xpack.security.http.ssl.key: /etc/elasticsearch/certs/node3.key
xpack.security.http.ssl.certificate: /etc/elasticsearch/certs/node3.crt
xpack.security.http.ssl.certificate_authorities: /etc/elasticsearch/certs/ca.crt
xpack.security.transport.ssl.key: /etc/elasticsearch/certs/node3.key
xpack.security.transport.ssl.certificate: /etc/elasticsearch/certs/node3.crt
xpack.security.transport.ssl.certificate_authorities:
/etc/elasticsearch/certs/ca.crt
xpack.monitoring.enabled: true
xpack.monitoring.collection.enabled: true

Each node has the same value for cluster.name which is a unique name identifying the cluster. This is how a node joins a cluster.

The node.name is set to the value of ${HOSTNAME}, that is the value of the node’s FQDN. This setting can also be configured explicitly to some value.

The node.master makes this node eligible to be elected as a master node which controls the cluster. Every master-eligible node, which is not a voting_only node, can be the master node of the cluster.

The node.ml feature is set to false. This is a machine learning feature which by default is set to true by x-pack extension, which comes installed by elastisearch package since version 6.3.

The cluster.remote.connect setting makes this node function as a cross-cluster client able to connect to remote clusters. This is not the case of this setup so it is set to false.

The network.host functions as a shortcut for the network.bind_host and network.publish_host. The former specifies the interface to listen for requests while the later is used to communicate with other nodes in the cluster.

The discovery.seed_hosts provides a list of nodes for this node to contact in order to join the cluster. It is safe to set this to the list of master-eligible nodes.

The cluster.initial_master_nodes provides a list of master-eligible nodes whose votes count in the very first election of the master node. The nodes in this list must match exactly the node.name of the nodes.

Note
titleNOTE

The cluster.initial_master_nodes setting is only used when starting a new cluster for the very first time. This is known as the cluster bootstrapping. This setting should not be used when restarting or adding a new node in an existing cluster.


The xpack.security.{http,transport}.* settings enable the SSL/TLS encryption for the HTTP and Transport communication protocol, respectively.

The xpack.monitoring.enabled enables/disables the monitoring on the node, while xpack.monitoring.collection.enabled enable/disables the collection of monitoring data.

Note
titleNOTE

It is recommended to setup a separate cluster for monitoring a production cluster. For more information see Monitoring in a production environment.


For more information about the aforementioned settings see Node, Network Settings, Important discovery and cluster formation settings, and Secure a cluster.

...

Code Block
title/etc/logstash/logstash.yml
path.data: /var/lib/logstash
path.logs: /var/log/logstash
queue.type: persisted
xpack.monitoring.enabled: true
xpack.monitoring.elasticsearch.username: "logstash_system"
xpack.monitoring.elasticsearch.password: "${logstash_system_password}"
xpack.monitoring.elasticsearch.hosts: "https://wifimon-kibana.rash.al:9200"
xpack.monitoring.elasticsearch.ssl.certificate_authority:
"/etc/logstash/certs/ca.crt"
xpack.monitoring.elasticsearch.ssl.verification_mode: certificate
xpack.monitoring.elasticsearch.sniffing: true

The path.data and path.logs defines the directories logstash will use to write persistent data and log messages, respectively.

The queue.type set the queue to persisted to provide protection against data loss by using an on-disk queue. For more information see Persistent Queues.

The other settings configures Logstash to send monitoring data over SSL/TLS.

Logstash Pipelines

Logstash pipelines are defined in the /etc/logstash/pipelines.yml file, which contains:

...

The following links were very useful while writing this material and performing the tests mentioned in it.

Elasticsearch Reference - https://www.elastic.co/guide/en/elasticsearch/reference/7.8/index.html

Logstash Reference - https://www.elastic.co/guide/en/logstash/7.8/index.html

Filebeat Reference - https://www.elastic.co/guide/en/beats/filebeat/7.8/index.html

Kibana Guide - https://www.elastic.co/guide/en/kibana/7.8/index.html

Elastic Blog - https://www.elastic.co/blog/