<div bgcolor="#FFFFFF"><div>Eric, <div>I saw your presentation couple of weeks ago about ZeroMQ but I didn't have time to dive into it. </div><div><br></div><div>In my previous statement, there is no prejudice, I simply offered an alternative solution. I'm for the KISS principle, and using the pacemaker/corosync/drbd stack could be a pain in the neck compared to this easy solution provided by RabbitMQ. I also think that's highly depend on your infrastructure, in my case I don't have thousand of nodes or geo-zones so using 2 servers with the RabbitMQ built in cluster solution is a good choice.</div>
<div>Moreover the RabbitMQ built in cluster is highly scalable and it's really easy to add a new node.</div><div><div><br></div><div>I'm open-minded and all for new ideas. </div><div><br></div><div>Regards.</div>
<div>~Seb.</div><br><div class="gmail_quote">
On Sat, May 26, 2012 at 12:02 AM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<span style="font-size:12px">Sebastien,</span>
</div><div><span style="font-size:12px"><br></span></div><div><span style="font-size:12px">For my part, I don't do *any of it*. I'm the author of the ZeroMQ implementation, where this is a non-issue.</span></div>
<div><span style="font-size:12px"><br></span></div><div><span style="font-size:12px">I think that having the Rabbit queues decoupled makes a lot of sense, especially since the code to do this can be generalized across multiple RPC implementations. (i.e. this would be a win for Qpid as well) I'm clearly not a die-hard RabbitMQ admin -- is there a reason to use clustering over a decoupled solution for a greenfield application?</span></div>
<span><font color="#888888">
<div><div><br></div>-- <br>Eric Windisch<div><br></div></div></font></span><div><div>
<p style="color:#a0a0a8">On Friday, May 25, 2012 at 17:54 PM, Sébastien Han wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div>Why don't you use the RabbitMQ builtin cluster solution?<div>I setup an active/active cluster with the buildin mecanism and put an HAProxy on top with a priority on a specific node. (weight and backup options).<br>
<br>
</div><div>For the mirrored queues don't we need to edit the openstack code?</div><div><br></div><div>Cheers.</div><div>~Seb<br><br>
<br><br><div>On Fri, May 25, 2012 at 10:10 PM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.com</a>></span> wrote:<br><blockquote type="cite"><div>
<div style="font-family:Helvetica;font-size:12px"><div>I feel that the best way to deploy RabbitMQ is to run multiple independently queue servers and have separate consumers to these servers. You can then do client-side balancing to select which Rabbit server messages go. To get that in Nova today would be pretty minor -- especially after the matchmaker lands (this can provide client-side balancing of servers).</div>
</div><span><font color="#888888">
<div><div><br></div>-- <br>Eric Windisch<div><br></div></div></font></span><div><div>
<p style="color:#a0a0a8">On Friday, May 25, 2012 at 09:18 AM, Stephen Gran wrote:</p><blockquote type="cite"><div>
<span><div><div><div>Hello,</div><div><br></div><div>I am investigating various high availability options for a pending</div><div>deploy of open stack. One of the obvious services to make resilient is</div>
<div>the mq service. We're going to be using rabbitmq, and we'll most likely</div><div>have N of them in a standard rabbit mq cluster behind a load balancer</div><div>configured as active/passive. One of the obvious improvements on this</div>
<div>would be to use mirrored queues to protect against message loss as well</div><div>as service downtime.</div><div><br></div><div>Are there recommended ways of doing this? I see that I can use durable</div><div>queues, which might work around the problems of openstack checking queue</div>
<div>parameters on reconnect, but it seems a shame there's not an obvious way</div><div>to do this out of the box. Unless I'm missing something?</div><div><br></div><div>Cheers,</div><div>-- </div><div>Stephen Gran</div>
<div>Senior Systems Integrator - <a href="http://guardian.co.uk" target="_blank">guardian.co.uk</a></div><div><br></div><div>Please consider the environment before printing this email.</div><div>------------------------------------------------------------------</div>
<div>Visit <a href="http://guardian.co.uk" target="_blank">guardian.co.uk</a> - newspaper of the year</div><div><br></div><div><a href="http://www.guardian.co.uk" target="_blank">www.guardian.co.uk</a> <a href="http://www.observer.co.uk" target="_blank">www.observer.co.uk</a> <a href="http://www.guardiannews.com" target="_blank">www.guardiannews.com</a> </div>
<div><br></div><div>On your mobile, visit <a href="http://m.guardian.co.uk" target="_blank">m.guardian.co.uk</a> or download the Guardian</div><div>iPhone app <a href="http://www.guardian.co.uk/iphone" target="_blank">www.guardian.co.uk/iphone</a></div>
<div> </div><div>To save up to 30% when you subscribe to the Guardian and the Observer</div><div>visit <a href="http://www.guardian.co.uk/subscriber" target="_blank">www.guardian.co.uk/subscriber</a> </div><div>---------------------------------------------------------------------</div>
<div>This e-mail and all attachments are confidential and may also</div><div>be privileged. If you are not the named recipient, please notify</div><div>the sender and delete the e-mail and all attachments immediately.</div>
<div>Do not disclose the contents to another person. You may not use</div><div>the information for any purpose, or store, or copy, it in any way.</div><div> </div><div>Guardian News & Media Limited is not liable for any computer</div>
<div>viruses or other material transmitted with or as part of this</div><div>e-mail. You should employ virus checking software.</div><div><br></div><div>Guardian News & Media Limited</div><div><br></div><div>A member of Guardian Media Group plc</div>
<div>Registered Office</div><div>PO Box 68164</div><div>Kings Place</div><div>90 York Way</div><div>London</div><div>N1P 2AP</div><div><br></div><div>Registered in England Number 908396</div><div><br></div><div><br></div>
<div>_______________________________________________</div><div>Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a></div><div>Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a></div>
<div>Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a></div><div>More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a></div>
</div></div></span>
</div></blockquote><div>
<br>
</div>
</div></div><br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></div></blockquote></div><br></div>
</div></div></span>
</blockquote>
<div>
<br>
</div>
</div></div></blockquote></div><br></div>
</div><div><span></span></div></div>