Hi,<br><br>On this mailing list, Jon had described once that they use a setup like this:<br><br><b>Haproxy as a TCP proxy sitting in front of the RabbitMQ clustered servers and acts as a failover and load balancer mechanism.<br>
The clustered RabbitMQ instances use the standard RabbitMQ clustering mechanism and have
the same queues, exchanges, and whatnot on each box.<br></b><br>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.<br>
<br>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:<br><br><b>HA proxy->3 Clustered RabbitMQ instances->Each RabbitMQ instance is having an independent HA active-passive setup (i.e. effectively 6 instances).......<br>
</b><br>Does this look scalable ? Am I missing something ? Anything else I can add/replace....<br><br>Many thanks,<br>Kshitiz Garg<br><br><br><br><div class="gmail_quote">On Mon, Nov 1, 2010 at 7:12 PM, Jon Brisbin <span dir="ltr"><<a href="mailto:jon.brisbin@npcinternational.com" target="_blank">jon.brisbin@npcinternational.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br>
On Oct 30, 2010, at 3:28 AM, Kshitiz Garg wrote:<br>
<br>
> Now if I use a HA proxy and have independent RabbitMQs sitting behind<br>
> that proxy, how will that be different from using a HA proxy and have<br>
> clustered RabbitMQs sitting behind that proxy. What is that these<br>
> clustered RabbitMQs have in common? Actually I want to understand<br>
> "clustering" in this regard.<br>
<br>
</div>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.<br>
<br>
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.<br>
<br>
"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.<br>
<br>
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.<br>
<br>
<soapbox><br>
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.<br>
</soapbox><br>
<font color="#888888"><br>
jb<br>
</font><div><div></div><div><br>
<br>
><br>
> Thanks,<br>
> Kshitiz Garg<br>
><br>
><br>
> On Fri, Oct 29, 2010 at 7:12 PM, Jon Brisbin<br>
> <<a href="mailto:jon.brisbin@npcinternational.com" target="_blank">jon.brisbin@npcinternational.com</a>> wrote:<br>
>><br>
>> On Oct 29, 2010, at 8:31 AM, Kshitiz Garg wrote:<br>
>><br>
>>> Should I refer to "RabbitMQ High Availability Guide" for setting up a<br>
>>> system like yours?<br>
>><br>
>> It's certainly a good idea to read that guide. But I'm using an intentionally simplistic setup that follows the transcript here:<br>
>><br>
>> <a href="http://www.rabbitmq.com/clustering.html#creating" target="_blank">http://www.rabbitmq.com/clustering.html#creating</a><br>
>><br>
>><br>
>>> does "haproxy" automatically decides the routing of<br>
>>> the message depending on the availability of rabbitMQ instances<br>
>>> sitting behind this ?<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> <a href="http://haproxy.1wt.eu/" target="_blank">http://haproxy.1wt.eu/</a><br>
>><br>
>> 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.<br>
>><br>
>> jb<br>
>><br>
>><br>
>><br>
>>><br>
>>> Regards,<br>
>>> Kshitiz<br>
>>><br>
>>> On Fri, Oct 29, 2010 at 6:39 PM, Jon Brisbin<br>
>>> <<a href="mailto:jon.brisbin@npcinternational.com" target="_blank">jon.brisbin@npcinternational.com</a>> wrote:<br>
>>>><br>
>>>> Do you want failover or clustering (or both)?<br>
>>>> 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.<br>
>>>> 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.<br>
>>>> I then use Spring AMQP to connect to the *proxy*, who decides which of the RabbitMQ instances I actually get connected to.<br>
>>>><br>
>>>> Jon Brisbin<br>
>>>> Portal Webmaster<br>
>>>> NPC International, Inc.<br>
>>>><br>
>>>> On Oct 29, 2010, at 1:27 AM, Kshitiz Garg wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> 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.<br>
>>>> 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.<br>
>>>><br>
>>>> My spring amqp template has been given a connection Factory like this:<br>
>>>><br>
>>>> <!-- RabbitMQ configurations --><br>
>>>> <!-- Define a connectionFactory --><br>
>>>> <bean id="connectionFactory"<br>
>>>> class="org.springframework.amqp.rabbit.connection.SingleConnectionFactory"><br>
>>>> <constructor-arg value="localhost" /><br>
>>>> <property name="username" value="guest" /><br>
>>>> <property name="password" value="guest" /><br>
>>>> </bean><br>
>>>><br>
>>>> <!-- Configure the admin class --><br>
>>>> <bean id="amqpAdmin" class="org.springframework.amqp.rabbit.core.RabbitAdmin"><br>
>>>> <constructor-arg ref="connectionFactory" /><br>
>>>> </bean><br>
>>>><br>
>>>> 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 ?<br>
>>>><br>
>>>> If that's the case, then what do we mean by high availability?<br>
>>>><br>
>>>> Thanks,<br>
>>>> Kshitiz Garg<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> rabbitmq-discuss mailing list<br>
>>>> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
>>>> <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
>>>><br>
>>>><br>
>>>><br>
>><br>
>><br>
>> Jon Brisbin<br>
>> Portal Webmaster<br>
>> NPC International, Inc.<br>
>><br>
>><br>
>><br>
>><br>
<br>
<br>
Jon Brisbin<br>
Portal Webmaster<br>
NPC International, Inc.<br>
<br>
<br>
<br>
</div></div></blockquote></div><br>