[Pacemaker] [RFC] [Patch] DC node preferences (dc-priority)

[Lars Ellenberg]

On Fri, May 25, 2012 at 10:29:58AM +0200, Lars Ellenberg wrote:
> On Fri, May 25, 2012 at 10:50:25AM +1000, Andrew Beekhof wrote:
> > On Fri, May 25, 2012 at 10:04 AM, Lars Ellenberg
> > <lars.ellenberg at linbit.com> wrote:
> > > On Sun, May 06, 2012 at 09:45:09PM +1000, Andrew Beekhof wrote:
> > >> On Thu, May 3, 2012 at 5:38 PM, Lars Ellenberg
> > >> <lars.ellenberg at linbit.com> wrote:
> > >> >
> > >> > People sometimes think they have a use case
> > >> > for influencing which node will be the DC.
> > >>
> > >> Agreed :-)
> > >>
> > >> >
> > >> > Sometimes it is latency (certain cli commands work faster
> > >> > when done on the DC),
> > >>
> > >> Config changes can be run against any node, there is no reason to go
> > >> to the one on the DC.
> > >>
> > >> > sometimes they add a "mostly quorum"
> > >> > node which may be not quite up to the task of being DC.
> > >>
> > >> I'm not sure I buy that.  Most of the load would comes from the
> > >> resources themselves.
> > >>
> > >> > Prohibiting a node from becoming DC completely would
> > >> > mean it can not even be cleanly shutdown (with 1.0.x, no MCP),
> > >> > or act on its own resources for certain no-quorum policies.
> > >> >
> > >> > So here is a patch I have been asked to present for discussion,
> > >>
> > >> May one ask where it originated?
> > >>
> > >> > against Pacemaker 1.0, that introduces a "dc-prio" configuration
> > >> > parameter, which will add some skew to the election algorithm.
> > >> >
> > >> >
> > >> > Open questions:
> > >> >  * does it make sense at all?
> > >>
> > >> Doubtful :-)
> > >>
> > >> >
> > >> >  * election algorithm compatibility, stability:
> > >> >   will the election be correct if some nodes have this patch,
> > >> >   and some don't ?
> > >>
> > >> Unlikely, but you could easily make it so by placing it after the
> > >> version check (and bumping said version in the patch)
> > >>
> > >> >  * How can it be improved so that a node with dc-prio=0 will
> > >> >   "give up" its DC-role as soon as there is at least one other node
> > >> >   with dc-prio > 0?
> > >>
> > >> Short of causing an election every time a node joins... I doubt it.
> > >
> > > Where would be a suitable place in the code/fsa to do so?
> > 
> > Just after the call to exit(0) :)
> 
> Just what I thought ;-)
> 
> > I'd do it at the end of do_started() but only if dc-priority* > 0.
> > That way you only cause an election if someone who is likely to win it starts.
> > And people that don't enable this feature are unaffected.

Sorry, sent to early.

That would not catch the case of cluster partitions joining,
only the pacemaker startup with fully connected cluster communication
already up.

I thought about a dc-priority default of 100,
and only triggering a re-election if I am DC,
my dc-priority is < 50, and I see a node joining.

That would then happen in
handle_request()
 /*========== DC-Only Actions ==========*/
     if(AM_I_DC) {
             if(strcmp(op, CRM_OP_JOIN_ANNOUNCE) == 0) {
		if ( *** new logic goes here *** )
			return I_ELECTION;
		else
			return I_NODE_JOIN;

Of course, we could even add the dc-priority to the CRM_OP_JOIN_ANNOUNCE
message, so we do only trigger an election if we are likely to lose.

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com