On Mon, Jul 19, 2010 at 9:54 PM, William Seligman <selig...@nevis.columbia.edu> wrote: > I had an unusual experience in setting up a Pacemaker+DRBD configuration that > I > thought I'd offer for comment. > > I have two nodes on my HA cluster; for now, let's call them Main and > Assistant. > I have two DRBD resources, Admin and Work. I wanted my standard resource > allocation to be that Admin would be master on Main and slave on Assistant, > and > Work be master on Assistant and slave on Main.
I assume DRBD supports this scenario normally? > > Setting up Admin to be Master on main posed no problems; it was textbook (I'm > omitting the location statements that set the "IP groups" to prefer to be on > specific nodes): > > configure primitive AdminDrbd ocf:linbit:drbd params drbd_resource=admin \ > op monitor interval=60s > configure master Admin AdminDrbd meta master-max=1 master-node-max=1 \ > clone-max=2 clone-node-max=1 notify=true globally-unique=false > configure colocation AdminWithMainIP inf: Admin:Master MainIPGroup > > But thing didn't work when I tried to set it up for Work: > > configure primitive WorkDrbd ocf:linbit:drbd params drbd_resource=work \ > op monitor interval=60s > configure master Work WorkDrbd meta master-max=1 master-node-max=1 \ > clone-max=2 clone-node-max=1 notify=true globally-unique=false > configure colocation WorkWithAssistantIP inf: Work:Master AssistantIPGroup > > What happened was that Work would not be promoted to Master on either Admin or > Main. The log file just said "failed to promote" without any other failure > indication. Which process logged that? If it came from drbd then its almost certainly still a DRBD issue. > I knew the problem wasn't with DRBD, since if I turned off corosync > and just used the DRBD service with drbdadm, I could set Work to primary on > the > assistant node. > > If I forced Work to be master on the Main node: > > configure colocation WorkWithMainIP inf: Work:Master MainIPGroup > > ... it worked fine, promoting Work on the Main node. > > The solution turned out to be not to use "infinity" in that final colocation > statement: > > configure colocation WorkPrefersAssistant 1000: Work:Master AssistantIPGroup > > Then Pacemaker promoted Work on Assistant with no complaints. So it didn't it > when forced, but only did it when asked. > > Any thoughts? Order matters... configure colocation someid score: A:master B What this says, is: promote A where B is running. If B is somewhere A cannot be a master, then it will remain a slave. I suspect what you really wanted was: configure colocation WorkPrefersAssistant inf: AssistantIPGroup Work:Master > > Versions: > > corosync-1.2.5-1.3.el5 > pacemaker-1.0.9.1-1.el5 > heartbeat-3.0.3-2.el5 > drbd-8.3.8-29.el5 > > I'll post the complete configuration files if anyone is interested. > > > _______________________________________________ > 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker > _______________________________________________ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
