[rabbitmq-discuss] Understanding RabbitMQ clustering

Wed Nov 24 13:18:30 GMT 2010

Hi,

On this mailing list, Jon had described once that they use a setup like
this:

*Haproxy as a TCP proxy sitting in front of the RabbitMQ clustered servers
and acts as a failover and load balancer mechanism.
The clustered RabbitMQ instances use the standard RabbitMQ clustering
mechanism and have the same queues, exchanges, and whatnot on each box.
*
However, here on the rabbitQM mailing list, I got to know that: queues are
not replicated on all the nodes. Instead the queue remain specific to the
node on which it was declared.

For millions of messages handling capability, I want a very similar setup
like Jon's, along with the active-passive ability of those RabbitMQ
instances , so that means a setup like this:

*HA proxy->3 Clustered RabbitMQ instances->Each RabbitMQ instance is having
an independent HA active-passive setup (i.e. effectively 6 instances).......
*
Does this look scalable ? Am I missing something ? Anything else I can
add/replace....

Many thanks,
Kshitiz Garg

On Mon, Nov 1, 2010 at 7:12 PM, Jon Brisbin <
jon.brisbin at npcinternational.com> wrote:

>
> 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20101124/e4265c13/attachment-0001.htm>