qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: 2 Node HA Cluster
Date Fri, 10 Aug 2012 13:26:08 GMT
On Thu, 2012-08-09 at 20:01 +1000, Gavin Alexander wrote:
> 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?

Yes that's the plan.

> Obviously the burden of maintaining both strategies long term will be
> a pain...

> (any).  Is it possible to bind to a specific local IP?

Not yet, see https://issues.apache.org/jira/browse/QPID-3351

> 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...... :)
> 
Sounds like a good setup, good luck!


> 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
> 



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


Mime
View raw message