[Pacemaker] dealing with non uptodate dual primary drbd resources and possible constraints

[Bart Coninckx]

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