Cluster¶
TeskaLabs LogMan.io can be deployed on a single server (aka "node") or as a cluster. TeskaLabs LogMan.io also supports geo-clustering.
Geo-clustering¶
Geo-clustering is a technique used to provide redundancy against failures by replicating data and services across multiple geographic locations. This approach aims to minimize the impact of unforeseen failures, disasters, or disruptions in one location by ensuring the system can keep operating from another location without interruption.
Geo-clustering involves deploying multiple instances of LogMan.io across different geographic regions or data centers and configuring them to work together as a single logical entity. These instances are linked together using a dedicated network connection, which enables them to communicate and coordinate their actions in real-time.
One of the main benefits of geo-clustering is that it provides a high level of redundancy against failures. In the event of a failure in one location, the remaining instances of the system take over and continue to operate without disruption. This not only helps ensure high availability (HA) and uptime, but also reduces the risk of data loss and downtime.
Another advantage of geo-clustering is that it can provide better performance and scalability by enabling load balancing and resource sharing across multiple locations. This means that resources can be dynamically allocated and adjusted to meet changing demands, ensuring that the system is always optimized for performance and efficiency.
Overall, geo-clustering is a powerful technique that helps ensure high availability, resilience, and scalability for critical applications and services. By replicating resources across multiple geographic locations, organizations can minimize the impact of failures and disruptions, while also improving performance and efficiency.
Locations¶
Location "A"¶
Location "A" is the first location to be built. In a single-node setup, it is also the only location.
Node lma1 is the first server built in the cluster.
Nodes in this location are named "Node lmaX". X is the sequence number of the server (e.g. 1, 2, 3, 4, and so on).
If you run out of numbers, continue with lowercase letters (e.g. a, b, c, and so on).
Please refer to the recommended hardware specification for details about nodes.
Location B, C, D and so on¶
Additional locations are labeled B, C, D, and so on, following location A.
Nodes in these locations are named "Node lmLX".
L is a lowercase letter that represents the location in alphabetical order (e.g. a, b, c).
X is the sequence number of the server (e.g. 1, 2, 3, 4, and so on).
If you run out of numbers, continue with lowercase letters (e.g. a, b, c, and so on).
Please refer to the recommended hardware specification for details about nodes.
Coordinating location "X"¶
The cluster MUST have an odd number of locations to avoid the split-brain problem.
For that reason, we recommend building a small, coordinating location with one node (Node lmx1).
We recommend using a virtualization platform for Node lmx1, not physical hardware.
No data (logs, events) is stored at this location.
Types of nodes¶
Core node¶
The first three nodes in the cluster are called core nodes. Core nodes form the consensus within the cluster, ensuring consistency and coordinating activities across the cluster.
Peripheral nodes¶
Peripheral nodes are nodes that do not participate in the cluster consensus. They provide additional capacity for data processing.
Arbiter nodes¶
In contrast to peripheral nodes, arbiter nodes participate in the cluster consensus. Arbiter nodes do not process any data.
Cluster layouts¶
Schema: Example of the cluster layout.
Single node "cluster"¶
Node: lma1 (Location A, server 1).
Two big and one small node¶
Nodes: lma1, lmb1 and lmx1.
Three nodes, three locations¶
Nodes: lma1, lmb1 and lmc1.
Four big and one small node¶
Nodes: lma1, lma2, lmb1, lmb2 and lmx1.
Bigger clusters¶
Bigger clusters typically introduce a specialization of nodes.