Load Balancing

Universal Messaging can work in environments where a third-party load balancer is in use. The main requirement is that the load balancer must support so-called "session stickiness". This means that when a load balancer assigns a client to a server in the cluster when initializing the client session, the load balancer will preferentially assign all subsequent communication from the client to the same server during the same client session.

From a technical point of view, load balancing for Universal Messaging can be used with either a single node or an active/active cluster. Before you choose to use a dedicated third-party load balancer to balance the load between Universal Messaging clients and servers, you should consider the following load balancing features already available in Universal Messaging:

If a load balancer is needed to force clients to establish connections to multiple Universal Messaging servers instead of just one server, then this feature can be used. Universal Messaging clients support a feature where connections to Universal Messaging servers will be done in a round-robin fashion. You can define the set of available servers using a semicolon(;) separated RNAME list. See the section Communication Protocols and RNAMEs for details.

If a load balancer is needed to improve the event throughput by splitting the Universal Messaging server load to multiple servers, then the Horizontal Scalability feature of Universal Messaging should be considered. It allows a single client session to connect to multiple servers/clusters simultaneously. See the section Horizontal Scalability for details.

If a load balancer is needed to improve the performance of an active/active Universal Messaging cluster by balancing the connections through all Universal Messaging cluster nodes, this feature should be considered.

In an active/active cluster, best performance is achieved when client connections are established to the master node (refer to the section The "Follow the Master" feature). Thus, having all clients connected to the master node will normally give better performance than when connections are balanced through all cluster nodes equally.

The Universal Messaging feature "follow-the-master" will not work in an optimal way if a load balancer is in use. Follow-the-master is an important Universal Messaging setting, as in most cases this is the most performant way to use an active/active cluster.

With a load balancer, when the client is redirected to connect to a slave node and follow-the-master is activated, the slave node will send the address of the master back to the client and will disconnect. Then the client will try to connect to the master, using the master's URL returned by the slave node, bypassing the load balancer. In that case, the client should be able to establish a direct connection to the master, otherwise the connect will always fail.

If the client doesn't have direct access to the cluster nodes and connection should always be done through the load balancer, then follow-the-master should not be set on clients.

To allow the follow-the-master behavior in this case, a possible solution would be to run a separate Universal Messaging Admin API client tool/script on the load balancer itself, whose sole purpose would be to get information from the Universal Messaging cluster about which node is the current master, then re-direct all the client connections to this node. This workaround can also be used by clients which don't support the "follow-the-master" feature.