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 <acon...@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-unsubscr...@qpid.apache.org > >> For additional commands, e-mail: users-h...@qpid.apache.org > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
