Load balancing RabbitMQ
About RabbitMQ
RabbitMQ is an open source message broker. It uses a publish-subscribe model to route data from publishers to consumers. It is scalable and can be load balanced, acting as a reliable and highly available intermediary. It has support for management and monitoring and has a range of tools and plugins available.
Key benefits of load balancing
Here are a few key benefits:
- Ensures the application is always available
- Provides a stable, optimal performance
- Uninterrupted uptime when performing upgrades/maintenance
How to load balance RabbitMQ
RabbitMQ does not require session affinity at the load balancing layer by default. To provide load balancing and high-availability for RabbitMQ, one virtual service is required. The virtual service must be set to listen on the same port as the RabbitMQ service, which listens on port 5672 by default.
Where possible we recommend that Layer 4 Direct Routing (DR) mode is used. This mode offers the best possible performance since replies go directly from the Real Servers to the client, not via the load balancer. It’s also relatively simple to implement. Ultimately, the final choice does depend on your specific requirements and infrastructure.
If DR mode cannot be used, for example, if the real servers are located in remote routed networks, then Layer 7 SNAT mode is recommended. If the load balancer is deployed in AWS or Azure, Layer 7 SNAT mode must be used as Layer 4 direct routing is not currently possible on these platforms.
It may be useful to adjust how much traffic is passed to the RabbitMQ servers depending on their CPU load. This can be done by installing the Loadbalancer.org server feedback agent on each RabbitMQ server and then re-configuring the Virtual Service to make use of the agent. The feedback agent is available for both Linux and Windows servers.
deployment guide
RabbitMQ Deployment Guide
Read deployment guidemanual
Administration manual v8
Read manual
