[Pacemaker] [RFC] [Patch] DC node preferences (dc-priority)
Lars Ellenberg
lars.ellenberg at linbit.com
Fri May 25 00:04:16 UTC 2012
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
More information about the Pacemaker
mailing list