qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavin Alexander <gavin.alexan...@gmail.com>
Subject Re: 2 Node HA Cluster
Date Thu, 09 Aug 2012 10:01:57 GMT
Hi Alan,

Thanks for getting back to me.
Some of limitations would make this a no go for me at the moment.
I'm guessing the "older cluster" module will be phased out gradually?
Obviously the burden of maintaining both strategies long term will be
a pain...

By "bind address" - I mean, when qpidd starts up it listens on 0.0.0.0
(any).  Is it possible to bind to a specific local IP?

For those interested.
The configuration that I've settled on is
Two Nodes running qpidd + 1 Quorum Node
Each node has 2 Nics, allocated on separate switching infrastructure/networks.
One network is for cluster comms the other to serve requests (its also
used as a backup interface - I'm using Totem - RRP (Redundant Ring
Protocol)).

Now for some performance testing...... :)

/gav







On 2 August 2012 06:01, Alan Conway <aconway@redhat.com> wrote:
> I should have also said: There is a new HA module in Qpid that will
> eventually replace the older cluster module. You should take a look at
> that as well, if you're starting out on a new project.
>
> http://qpid.apache.org/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Active_Passive_Cluster.html
>
> On Fri, 2012-07-27 at 01:02 +1000, Gavin Alexander wrote:
>> Hi All,
>>
>> I'm looking to set up a durable HA broker and had a few questions.
>> First off, sorry if these questions are more appropriate on a Linux-HA
>> forum... just trying to see if other people have come across the same
>> issues.
>>
>> After setting up a two node cluster and being quite happy with the
>> ease of config - I realised that I would have to solve the split-brain
>> problem.
>> So, using 3 virtual machines, I followed the guide @
>> https://cwiki.apache.org/confluence/display/qpid/Configuring+qpidd+with+Cluster+Manager
>> which works reasonable well - (I've had a few issues with rgmanager
>> hanging occasionally during failover... but I digress...)
>>
>> The environment that I'm using at the moment is on a bunch of Linux
>> KVM's, but it will eventually be moved to physical infrastructure.
>> I have some reasonable performance requirements and the hardware I'm
>> using is quite expensive - so adding another node for HA just to
>> maintain a quorum seems "wasteful".
>>
>> So, I'm investigating if a 2 node setup is possible.
>>
>> Is it possible to do HA with two nodes (without a "real" qdisk)?
>> I've tried adding a 3rd node (a cheap virtual machine) for quorum only
>> - I.e. it doesn't run qpidd and is only used for quorum.  It seems to
>> work - although I haven't thoroughly tested all failure scenarios yet.
>> Other idea's I've had are
>>  - Using Qdisk heuristics to generate more votes - everything I read
>> seems to suggest not to do this...
>>  - Integrating with a load balancer (there's an existing LVS cluster
>> on the same network - that I can piggy-back on) to protect against
>> split-brain "somehow" :)
>>  - Leave it as a two node cluster and rely on corosync totem protocol,
>> or interface bonding for fault tolerance. Then, if a split brain does
>> occur, it's pretty certain (about 99.9% :) that clients wouldn't be
>> able to access the cluster anyway.
>>
>>
>> A couple of questions...
>> Do cluster messages require acknowledgement from cluster nodes before
>> sending ack's back to the client (if the clients require
>> acknowledgement)? And hence, does adding more nodes degrade
>> performance?
>> Has anyone ever tried running qpid over something like drbd?
>> Is it possible to specify a bind address for qpidd?
>>
>> Look forward to any replies/guidance/commentary
>>
>> Thanks,
>>
>> /gav
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message