Eric,
I saw your presentation couple of weeks ago about ZeroMQ but I didn't have
time to dive into it.
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 comp
Sebastien,
For my part, I don't do *any of it*. I'm the author of the ZeroMQ
implementation, where this is a non-issue.
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. thi
Why don't you use the RabbitMQ builtin cluster solution?
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).
For the mirrored queues don't we need to edit the openstack code?
Cheers.
~Seb
On Fri,
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 matchm
Stephen,
On Fri, May 25, 2012 at 3:18 PM, Stephen Gran
wrote:
> Hello,
>
> I am investigating various high availability options for a pending
> deploy of open stack. One of the obvious services to make resilient is
> the mq service. We're going to be using rabbitmq, and we'll most likely
> have
Hello,
I am investigating various high availability options for a pending
deploy of open stack. One of the obvious services to make resilient is
the mq service. We're going to be using rabbitmq, and we'll most likely
have N of them in a standard rabbit mq cluster behind a load balancer
configure
6 matches
Mail list logo
