On 19 Mar 2014, at 6:56 am, Bingham <knee-jerk-react...@hotmail.com> wrote:
> > My problem is that I need to have rabbitmq running on both node1 and node2. > I also need the IP to fail over if rabbitmq were to fail on the current node. > > The 2 rabbitmq services are communicating with each other. > Data is pushed to the clients. > > Even though the IP may currently live on node1, data may flow through node1 > then through node2 (via rabbit) and out to client. > > Rnode1 -------> client1 > / /|\ > DB---->VIP | > \|/ > Rnode2 --------> client2 > > > > Maybe I should not have these resources grouped together since that implies > collocation infinity for IP and rabbitmq? Correct. It also sounds like rabbitmq should be a master/slave resource > > > Steve > > > From: and...@beekhof.net > Date: Tue, 18 Mar 2014 11:44:34 +1100 > To: pacemaker@oss.clusterlabs.org > Subject: Re: [Pacemaker] Don't want to stop lsb resource on migration > > > On 14 Mar 2014, at 1:00 am, Bingham <knee-jerk-react...@hotmail.com> wrote: > > > Hello, > > > > My setup: > > I have a 2 node cluster using pacemaker and heartbeat. I have 2 > > resources, ocf::heartbeat:IPaddr and lsb:rabbitmq-server. > > I have these 2 resources grouped together and they will fail over > > to the other node. > > > > > > > > question: > > When rabbitmq is migrated to node1 from node2 I would like to > > 'not' have the the </etc/init.d/rabbitmq-server stop> happen on the failed > > server (node1 in this example). > > 'migrate' has special meaning here. > After a failure rabbitmq is moved (stopped on the old node and started on the > new one), which is different from a migration. > > Leaving rabbitmq in an unclean state on node1 would definitely not be a good > idea. > > > > > Is it possible to do this in crm? > > > > I realize that I could hack the initscript's case statement for > > stop to just "exit 0", but I am hoping there is a way to do this in crm. > > > > > > Thanks for any help, > > Steve > > > > > > _______________________________________________ > > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > > > Project Home: http://www.clusterlabs.org > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > Bugs: http://bugs.clusterlabs.org > > > _______________________________________________ Pacemaker mailing list: > Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: > http://www.clusterlabs.org Getting > started:http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: > http://bugs.clusterlabs.org > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
