On 10/28/11 10:16, Andreas Kurz wrote:
Hi Andreas,
hope you are doing well
hello,
On 10/27/2011 09:34 PM, Bart Coninckx wrote:
Hi,
I found this a rather tough one.
I have a dual primary DRBD setup for Xen live migration.
The DRBD part is taken care of by a master drbd resource (linbit). It
has a monitoring operation that puts it primary (master) if it's
secondary (salve) for some reason.
I was surprised to see that in case of a drbd node with an invalidated
resource, the resource was happily put into primary (master) state
during the sync (so while not being uptodate).
You also noticed the different promotion scores?
No, not particularly, but this piece of code in the resource agent
should prevent it from doing that nomatter what the score is, right?
if [[ $? = 17 ]]; then
ocf_log crit "Refusing to be promoted to Primary without UpToDate data"
break
fi
Obviously this poses a problem, as the cluster might decide to start a
Xen DomU on the non-uptodate drbd node.
Not really as long as the resources are connected. It is completely
valid to use a Primary that is SyncTarget, blocks that are not uptodate
when requested are prefetched from the SyncSource.
Ah, I see: so in a dual primary a SyncTarget is usable anyway, as it
will sync "on the spot". Won't that affect performance drastically?
There is a full sync going on already and besides that, the Xen resource
needs to occasionally wait for some data as well.
Is there any way I can avoid that with a constraint? Or should I go
about things differently so it is not able to set the resource into
master before the acutal sync is done?
There would be different ways .... changing master-max to 1, add an
anticolocation constraint for the Master role and the SyncTarget, or
simply don't start Pacemaker on the SyncTarget if you expect a very long
resync time ... start DRBD manually and wait for the sync to finish.
I see, much clearer now, thx! So basically it is allowed to happen, will
probably slow things down, but I can avoid it by a anticolocation
constraint in between synctarget and master. That last thing might be a
challenge, but I'll try to get it done. If I fail, you'll see mee again ;-)
Regards,
Andreas
Best,
Bart
_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
