Load balancing 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.
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.
Offering performance without limitations, the best-value hardware load balancer on the market supports any environment. Licensed for unlimited throughput, bandwidth and features, upgrading is seamless if your requirements change down the line.
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.