[rabbitmq-discuss] Understanding RabbitMQ clustering

Jon Brisbin jon.brisbin at npcinternational.com
Mon Nov 1 13:42:49 GMT 2010


On Oct 30, 2010, at 3:28 AM, Kshitiz Garg wrote:

> Now if I use a HA proxy and have independent RabbitMQs sitting behind
> that proxy, how will that be different from using a HA proxy and have
> clustered RabbitMQs sitting behind that proxy. What is that these
> clustered RabbitMQs have in common?  Actually I want to understand
> "clustering" in this regard.

If the brokers aren't clustered, your individual RabbitMQ brokers won't share users, exchanges, queues, or any other resource. I'm not sure how that affects applications because I haven't tried it. I suspect it wouldn't work very well with round-robin load balancing because consumers might get connected to a different broker than the producers.

If you're using only the failover configuration, though, it would be better. You'd just have to reestablish all your Channels if one of them gets disconnected, assuming the next connection will go to the other broker.

"Clustered" RabbitMQ brokers look the same no matter which actual broker you contact. Messages delivered to one broker will be delivered to consumers on another broker. Without this clustering, you have to create some kind of store-and-forward (maybe using the shovel plugin) or your application has to manage that itself.

If your brokers are clustered, upgrading versions of the broker is, in my experience, fragile. Every version upgrade I've done (we're running it on Ubuntu Linux) results in a dead broker that has to be manually restarted. I've also had to re-configure the broker back into the cluster more times than I'd like. 

<soapbox>
The broker upgrade process could use some attention, IMHO. The broker should restart after upgrades without manual intervention and new versions should ALWAYS be able to migrate data so I don't have to reconfigure all my users and clustering configuration.
</soapbox>

jb


> 
> Thanks,
> Kshitiz Garg
> 
> 
> On Fri, Oct 29, 2010 at 7:12 PM, Jon Brisbin
> <jon.brisbin at npcinternational.com> wrote:
>> 
>> On Oct 29, 2010, at 8:31 AM, Kshitiz Garg wrote:
>> 
>>> Should I refer to "RabbitMQ High Availability Guide" for setting up a
>>> system like yours?
>> 
>> It's certainly a good idea to read that guide. But I'm using an intentionally simplistic setup that follows the transcript here:
>> 
>> http://www.rabbitmq.com/clustering.html#creating
>> 
>> 
>>> does "haproxy" automatically decides the routing of
>>> the message depending on the availability of rabbitMQ instances
>>> sitting behind this ?
>> 
>> Sort of. HAProxy is a TCP/IP "traffic cop". It knows nothing about the contents of the packets it proxies. It simply knows whether or not any of the configured backends is alive and able to receive data.
>> 
>> Maybe a better way to say it is that it decides the routing of the TCP traffic to the broker. It knows nothing about messages.
>> 
>> http://haproxy.1wt.eu/
>> 
>> I'm also using a "best effort" approach. I'm not going to get my britches in a wrinkle if my broker goes down for a few minutes (or a few hours ;) until I get it fixed. I recognize others don't have that luxury.
>> 
>> jb
>> 
>> 
>> 
>>> 
>>> Regards,
>>> Kshitiz
>>> 
>>> On Fri, Oct 29, 2010 at 6:39 PM, Jon Brisbin
>>> <jon.brisbin at npcinternational.com> wrote:
>>>> 
>>>> Do you want failover or clustering (or both)?
>>>> I use both. I have haproxy as a TCP proxy that sits in front of the RabbitMQ servers and acts as a failover and load balancer mechanism.
>>>> Behind the proxy are clustered RabbitMQ instances, which means they use the standard RabbitMQ clustering mechanism and have the same queues, exchanges, and whatnot on each box.
>>>> I then use Spring AMQP to connect to the *proxy*, who decides which of the RabbitMQ instances I actually get connected to.
>>>> 
>>>> Jon Brisbin
>>>> Portal Webmaster
>>>> NPC International, Inc.
>>>> 
>>>> On Oct 29, 2010, at 1:27 AM, Kshitiz Garg wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I have just started working with RabbitMQ for my cloud messaging/eventing application. The proof of concept worked well with rabbitMQ and Spring AMQP. Now, I want to start preparing for scalability.
>>>> I am able to setup a rabbitMQ cluster with 2 rabbitMQs installed on 2 separate machines. Now I want to know what is achieved by "clustering" in terms of rabbitMQ.
>>>> 
>>>> My spring amqp template has been given a connection Factory like this:
>>>> 
>>>>     <!-- RabbitMQ configurations -->
>>>>     <!-- Define a connectionFactory -->
>>>>     <bean id="connectionFactory"
>>>>         class="org.springframework.amqp.rabbit.connection.SingleConnectionFactory">
>>>>         <constructor-arg value="localhost" />
>>>>         <property name="username" value="guest" />
>>>>         <property name="password" value="guest" />
>>>>     </bean>
>>>> 
>>>>     <!-- Configure the admin class -->
>>>>     <bean id="amqpAdmin" class="org.springframework.amqp.rabbit.core.RabbitAdmin">
>>>>         <constructor-arg ref="connectionFactory" />
>>>>     </bean>
>>>> 
>>>> Here I have specified localhost, so now, if I send a amqp message through rabbitMQ and this localhost broker is not up, will that message go through its cluster node automatically ?
>>>> 
>>>> If that's the case, then what do we mean by high availability?
>>>> 
>>>> Thanks,
>>>> Kshitiz Garg
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> rabbitmq-discuss mailing list
>>>> rabbitmq-discuss at lists.rabbitmq.com
>>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>> 
>>>> 
>>>> 
>> 
>> 
>> Jon Brisbin
>> Portal Webmaster
>> NPC International, Inc.
>> 
>> 
>> 
>> 


Jon Brisbin
Portal Webmaster
NPC International, Inc.





More information about the rabbitmq-discuss mailing list