Cluster managers

Cluster managers provide dynamic load balancing services and improve the availability of SafeLinx Servers in your deployment. Each installation of a SafeLinx Server creates a single cluster manager resource. Cluster manager support applies to mobile access services and messaging services only. Cluster managers do not distribute traffic for connections that are made through HTTP access services.

You can define a SafeLinx Server as a principal node, subordinate node, or both. A principal node dispatches traffic to subordinate nodes. A subordinate node is configured to accept traffic from one or more principal nodes. A cluster manager that is defined as both a principal and subordinate node dispatches traffic and processes data. There is only one principal node per cluster group.

To dispatch traffic for a specified network, make sure that the messaging services are configured as the principal node in a cluster.

To dispatch traffic for a messaging mobile network connection (MNC), make sure that the MNC is installed and configured on the same system as the messaging services.

A principal node initiates communication to subordinate nodes. As part of the role of receiving and dispatching traffic, a principal node maintains two-way communication with subordinate nodes. Provide backup for SafeLinx Servers that are configured as principal nodes to make sure that critical resources are available.

Subordinate nodes send load information to principal nodes and control when to begin or end accepting traffic from principal nodes based on a configurable distribution algorithm. The following distribution algorithms are available:
The principal node continuously repeats the sequence of distributing traffic to a series of subordinate nodes, one after the other.
Weighted round-robin
The principal node continuously repeats the sequence of distributing traffic to a series of subordinate nodes. This action is based on configurable CPU utilization thresholds, called low and high water marks.
Device/MNC based
The principal node distributes traffic to subordinate nodes based on the MNC or unique device identifier from which it came.

When a principal node shuts down, the cluster manager notifies subordinate nodes to stop any pending transactions that get routed back through the principal node.

Subordinate nodes can be configured to one of three states:
The normal mode of operation in which the cluster manager dispatches traffic according to the distribution algorithm configured for the subordinate node.
A mode of operation in which the cluster manager immediately notifies the subordinate node to stop any pending transactions.
A mode of operation in which the cluster manager does not route new traffic to this subordinate node. This mode of operation allows the traffic to terminate after all pending transactions are completed. To verify that all traffic is terminated, use the wg_monitor utility and check the number of active sessions. For more information about the monitoring utility, see Monitoring packet flow.

Subordinate nodes can be pooled into cluster groups, and principal nodes can be configured to dispatch traffic only to subordinate nodes in these groups. By default, if a cluster manager has no groups to manage, it manages all subordinate nodes that are not assigned to a cluster group. For more information, see Configuring cluster nodes.

You can improve the performance of connectionless MNCs, such as ip-lan, by binding the UDP port to a specific IP address. For more information, see Configuring cluster nodes for connectionless MNCs.
Note: If you upgrade the release version of the SafeLinx Servers in a cluster, always upgrade the principal node before the subordinate nodes. All nodes in a cluster must run the same version.