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