Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Ben: Thanks for your suggestions: > See: 5.3.2. Prevent Resources from Moving after Recovery > At: http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Clusters_from_Scratch/index.html I had already followed the suggestions made here, as per the line in my cib: rsc_defaults $id="rsc-options" \ resource-stickiness="100" But, that does not seem to work in this case. There is only one NIC on each of the two boxes. After reading, seems we should really invest in 2 more NICs and a gigabit crossover cable, but that still won't solve all problems. On Thu, May 27, 2010 at 04:19:47PM +0200, Lars Ellenberg wrote: > > May I point to this thread: > [Pacemaker] DRBD 2 node cluster and STONITH configuration > does drbd really need stonith? > > http://www.mail-archive.com/pacemaker@oss.clusterlabs.org/msg04312.html > > where I try to explain the various scenarios, > and what is needed to deal with them. > Good read, thank you. Not sure why resource stickiness isn't work as expected, my understanding was setting a high default stickiness would prevent resources from moving about, which would solve the problem. However it only works in this case: node1 is master node1 nic dies node2 takes over node1 comes back online [A] resources stay on node2 split-brain, discard node1's data, all ok but NOT this: node2 is master node2 nic dies node1 takes over node2 comes back online [B] resources *move to node1* (why do they do this?) outdated data on node1, clients connecting, potential for diverging data sets. [A] is fine, [B] a problem. granted, keeping node1 always as master is reasonable, but not full-proof. I would expect pacemaker's behavior to be symmetric, but it isn't, and I need to find out way.