HiveMQ and Load Balancers

Load balancing is a technology to distribute incoming traffic across a cluster of servers.

This has the advantages of:

  • Reducing the individual stress on the nodes

  • Improving the availability and reliability of HiveMQ by distributing only to available nodes

  • Increasing the flexibility of the cluster

Offload SSL/TLS termination

HiveMQ is optimized to use all available resources on a system, so the highest possible throughput of messages can be accomplished. For this reason we recommend offloading the SSL/TLS termination onto the load balancer, if one is available. SSL/TLS termination puts a high load on the system CPU, which may lead to a decrease in the message throughput of HiveMQ. Offloading the SSL/TLS termination onto the load balancer will ensure that a constant level of message throughput can be achieved.

PROXY Protocol

See Proxy Protocol to learn how to use PROXY Protocol with load balancers.

Proxy Protocol cannot be used when HiveMQ is responsible to terminate the SSL/TLS.

Idle timeout

When configuring the idle timeout it is important to consider that in accordance with the MQTT specification HiveMQ will close the MQTT connection, when no packet was received by the MQTT client for 1.5 times its keepAlive value. The load balancer itself will close the underlying TCP connection, as soon as no bi-directional traffic has been noticed for the duration of the idle timeout. Therefore it is vital to configure the idle timeout of the load balancer to at least 1.5 times of the keepAlive value used by the MQTT clients. Otherwise loss of connection for the clients will occur, as soon as they stop sending or receiving MQTT messages of a Quality of Service level greater than 0 for the time that is configured as idle timeout at the load balancer.

The idle timeout needs to be at least 1.5 times the keepAlive value.

Integrating the load balancer when decreasing cluster size

Decreasing the cluster size can sometimes be necessary in your HiveMQ deployments. Examples for this might be maintenance work on the machines the HiveMQ is run on or a rolling upgrade of your HiveMQ. In these cases it is natural that all clients connected to the node that is being shut down will lose their MQTT connections and usually will try to re-connect immediately (depending on the MQTT client implementation of course). This will result in a high number of connection requests at the load balancer as well as the HiveMQ cluster, this peak in network requests should be considered. We recommend removing a node that is scheduled for shut down from the load balancer ahead of time. This way the MQTT clients will distribute amongst the remaining node naturally before the node is shut down, resulting in smaller peak of connection requests.