HiveMQ and Load Balancers

A load balancer is a specialized technology used to evenly distribute incoming traffic across a cluster of servers.

Load balancing is not a core feature of MQTT as defined in the official MQTT specification and the HiveMQ platform does not ship with or require the use of any specific load balancer. However, for production use cases, HiveMQ clusters are usually placed behind a load balancer to further enhance scalability and improve overall system performance.

The use of a load balancer in your MQTT infrastructure can offer several advantages:

  • Increase scalability: Load balancers enable horizontal scalability that dynamically distributes incoming connection requests across available brokers. This allows the system to add brokers as needed to handle increased traffic and reduces stress on individual broker nodes.

  • Improve availability: Load balancing ensures that if one broker instance fails or experiences difficulty, new incoming requests are redirected to the remaining healthy nodes. This filters out overloaded servers and minimizes the impact of individual node failures on the availability of the overall system.

  • Enhance efficiency: Load balancing employs algorithms to determine the distribution of work based on the dynamic state of the system. This adaptability makes it possible to evenly utilize broker capabilities for optimal system performance.

  • Heighten security: Load balancers provide an entry point into the internal system. This allows the load balancer to inspect and filter incoming requests to limit unwanted traffic. Additionally, the load balancer hides server details such as the number of brokers and the broker IP addresses from the connecting clients.

HiveMQ works seamlessly with a wide range of load balancers such as HAProxy, NGINX, and others.
For more information, see our blog post Using HAProxy to Load Balance HiveMQ with the New Health API.

In a HiveMQ deployment, the load balancer sits between your MQTT clients (publishers and subscribers) and multiple HiveMQ brokers.The primary goal of a load balancer in MQTT is to efficiently manage client connections to maintain an even distribution of incoming MQTT messages to all available brokers.

Load balancers use various algorithms to determine how to distribute incoming traffic among the brokers. Commonly used load balancing algorithms include round-robin, least connections, weighted distribution, and IP hash.

The least connections algorithm is a popular choice for load balancing MQTT broker clusters due to its simplicity, scalability, fault tolerance, and ability to adapt to changing conditions. However, the selection of a suitable load balancing algorithm depends on your specific deployment requirements, the load balancers capabilities, and your broker cluster configuration.

The following diagrams illustrate the basic setup of a HiveMQ deployment with and without a load balancer:

With and without load balancing
Your HiveMQ broker provides numerous ways to optimize performance and ensure high availability straight out of the box. To see how HiveMQ shared subscriptions automatically distribute messages among a subscription group in a balanced manner, see Shared Subscriptions. To learn how HiveMQ protects your cluster from stressful situations, see Cluster Overload Protection.

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.