On Tue, Jun 09, 2009 at 06:11:21PM +0200, Lars Marowsky-Bree wrote:
> On 2009-06-09T13:24:57, Lars Ellenberg <lars.ellenb...@linbit.com> wrote:
>
> > generic question about master score and globally-unique=false.
> > I don't think it can even work.
>
> Why not? They do.
>
> > but if they can work, how, and why,
> > are master scores supposed to work?
> >
> > if _by definition_ the instances are not distinguishable,
> > why would placing a master preference on drbd-xy:1 prevent
> > drbd-xy:1 from being allocated on the "wrong" node
> > accessing the "wrong" data?
> >
> > if we are "globally-unique=false" (and I really think drbd would fall
> > into that category), then there is no difference whether I place
> > the better score on drbd-xy:0 or drbd-xy:1.
> > appart from _accidentally_ colocating drbd-xy:0 with the same (group of)
> > hosts, "most of the time".
> >
> > what am I missing?
>
> I'm not sure I follow. Placing a master preference for an anonymous
> instance effectively applies to the whole clone on that node.
>
> If you set a negative/zero master preference on a node, drbd won't run
> there.
>
> If you set a positive one, the highest scoring node will be preferred.
>
> Maybe I'm missing the real question?
regarding the protection against going online with stale data
("outdate peer"), I said:
> > what we actually are doing right now is placing location
> > constraints on the master role into the cib from the "fence-peer"
> > handler, and removing them again from the "after-sync-target"
> > handler. sort of works.
and you suggested to
> Here I think we need a more extensive discussion. Why doesn't your
> handler modify the master score instead, but add additional
> constraints?
now.
replication link breaks.
I am still up-to-date, my instance is :0,
I place a "negative master score" for the other clone instance (:1),
and a _very_ positive one for myself (:0).
admin brings down the cluster.
admin brings up the cluster, thinking he fixed the replication linke
problem. but actually the replication link problem is still not fixed.
[ or any other scenario ]
crm decides to place the clone instances in an other order (should not
matter, because they are "anonymous", right).
say :0 is now located on a node that only has access to stale data.
but it is the only one with a positive master score.
outch.
==> if clone placement is arbitrary, and clone instances are
indistinguishable, master scores placement on clone instances
can only useful with a lifetime of "reboot".
persistent (lifetime forever) master scores on clone instances
with globally-unique=false is nonsense.
master scores are not useful to express
"dont go online with stale data".
correct?
or do still not understand the purpose crm_master, and how it works?
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________
Pacemaker mailing list
Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
