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

[Lars Ellenberg]

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?

Thanks,

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