| Excerpt |
|---|
HaProxy with load balancing and keepalive options enabled could be used to provide high availability of your RabbitMQ cluster. The need of a load balancing proxy in front of the RabbitMQ cluster is presented due to the fact that sometimes the serving member of the cluster either looses connection or fails to serve and the message is lost. |
A load balancing solution with “awarness” of the state of the cluster members must be appliedis required.
Since RabbitMQ does not use indexes , and the immediate messaging answer is required, we should apply the most HaProxyprovides an efficient and yet simple to maintain solution.
In this case HaProxy is applied with load balancing and keepalive options enabled.
To set up HAProxy for your RabbitMQ cluster, follow these steps:
...
Despite the fact that our Queues are replicated across each HA node, there is only one available instance of each Queue, and it resides on the node on which it was created, or in the case of failure, the instance that is promoted to master. RabbitMQ is conveniently routing us to that node in this case:
| Gliffy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Unfortunately for us, this means that we suffer an extra, unnecessary network hop in order to reach our intended Queue. This may not seem a major issue, but consider that in the above example, with 3 nodes and an evenly-balanced Load Balancer, we are going to incur that extra network hop on approximately 66% of requests. Only one in every three requests (assuming that in any grouping of three unique requests we are directed to a different node) will result in our request being directed to the correct node.