A common issue in cluster environment is the split brain condition. A split brain occurs when some nodes of the cluster are not able to communicate properly, but instead continue to work like two separate, distinct clusters leading to data or service inconsistency. To prevent this situation a common solution is to introduce the concept of a quorum: only the portion of the cluster which includes half+1 of the nodes can continue to work, while the other portion ceases operating, thus avoiding inconsistencies.
A NetEye cluster requires at least three nodes in order to guarantee resiliency against outages and to avoid downtime during maintenance. In a three nodes installation, the quorum is set to 2 and therefore it is possible to lose one node while still guaranteeing data integrity and NetEye availability.
NetEye clusters involve three main technologies:
DRBD provides clustered storage which synchronizes data between nodes, and mounts the partition on the node where the service is running
PCS is responsible for running services and moving them between nodes when necessary
Elasticsearch provides its own cluster solution and does not rely on PCS and DRBD technologies
Customers often consider three-node installations too expensive for several reasons:
Storage costs: all three nodes need to have the same amount of storage to synchronize DRBD resources and Elasticsearch data
RAM and CPU: all three nodes may run the same services and therefore they must have same computational power
License costs: it requires three full NetEye licenses
A voting-only node is a NetEye node which circumvents the limitations above. This type of node is a standard NetEye machine with several modifications aimed at reducing resource usage and therefore costs. As the name implies, the only purpose of a voting-only node is to provide a quorum for DRBD, PCS and Elasticsearch:
DRBD is set up in diskless mode: data are not synchronized on the voting-only node and minimum disk space is required.
The machine is configured as a PCS quorum device. A quorum device can join a PCS cluster providing quorum but the node cannot run resources.
Elasticsearch is configured as a voting-only master-eligible node: data will not be synchronized, machine-learning jobs cannot be run on it, and data will not be ingested. Elasticsearch is required only in NetEye SIEM clusters.
A voting-only node may run on a virtual machine with 4 vCPU, 8GB RAM and 60GB storage, thus reducing costs in comparison with a physical machine while maintaining cluster reliability.
Note that Elasticsearch as a voting-only master-eligible node is not available with the OSS license.
When using Kibana in environments that require a proxy to reach external services, you might encounter issues with unrecognized SSL certificates. Specifically, if the proxy is exposed with its own certificate and acts as an SSL terminator, requests made by Read More
In a previous post we went through the configuration of Elastic Universal Profiling in NetEye, seeing how we can profile applications written in programming languages that do not compile to native code (for example Python, PHP, Perl, etc.) But what Read More
Elastic 8.16, which comes with NetEye 4.39, made Elastic Universal Profiling generally available for self-hosted installations. This means that NetEye SIEM installations will now be able to take advantage of the continuous profiling solution by Elastic. In this blog post Read More
In the first part of this series, we explored how Jira Service Management (JSM) helps streamline Incident Management, aligning with ITIL v4 best practices. Incident Management aims to restore normal service operation as quickly as possible after a disruption, ensuring Read More
Hello everyone! Today, I'd like to briefly discuss an improvement to the update and upgrade procedures that we've started to adopt with NetEye 4.39! What we wanted to improve One aspect that made quite an impact was that whenever the Read More