[ClusterLabs] Antw: [EXT] Re: start vs promote drbd m/s colocation constraint

[Ulrich Windl]

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 03.02.2021 um 00:02 in
Nachricht
<396cc52f2d27b8aab611d2312ba172b07bdc9d7f.camel at redhat.com>:
> On Tue, 2021‑02‑02 at 14:27 ‑0700, Brent Jensen wrote:
>> I've been trying to get my DRBD cluster on Centos8 / Pacemaker 2 to
>> work but have had issues with cluster not failing over (I get error
>> messages like "Refusing to be Primary while peer is not outdated").
>> This has been explained in other posts. In trying different things I
>> changed my constraint from PROMOTE to START and things seem to be
>> working:
>> DOES NOT WORK (works in pacemaker <2)
>> pcs constraint order PROMOTE drbd0‑clone then start fs_drbd
>> 
>> SEEMS TO WORK
>> pcs constraint order START drbd0‑clone then start fs_drbd
> 
> It's definitely a different effect; the second constraint only ensures
> that some instance of drbd0‑clone has started before starting fs_drbd.
> No instance needs to be in the master role before starting fs_drbd.
> 
>> Note: The colocation constraint seems to work even if it's:
>> "pcs constraint colocation add fs_drbd with drbd0‑clone INFINITY
>> with‑rsc‑role=Master id=nfs_on_drbd"
>> or just "pcs constraint colocation add fs_drbd with drbd0‑clone"
> 
> Similarly, the second constraint says only that fs_drbd has to run
> where *any* instance of drbd0‑clone is running, regardless of whether
> it's master or not.
> 
>> What's the correct way for constraints on M/S DRBD? It just feels
>> wrong doing just "start" instead of "promote" like I've been 
> 
> I haven't used DRBD in a while, but I believe newer versions handle the
> equivalent of promotion internally, rather than via the resource agent
> and pacemaker. It could be that you simply don't need a promotable
> clone, just a regular clone. I don't know how that would actually work,
> but it's maybe something to investigate.
> 
>> doing       over the last 15 years. In pacemaker 2.x the master/slave
>> resource changed to clone so this is new to me.
> 
> master/slave ‑> promotable clone was purely a terminology change, the
> behavior is identical

If the names were really changed, I hope people did take care of the resource
agents:

: ${OCF_RESKEY_CRM_meta_master_max=1}
: ${OCF_RESKEY_CRM_meta_master_node_max=1}

;-)

> 
>> Any input is most helpful!
>> Brent
> ‑‑ 
> Ken Gaillot <kgaillot at redhat.com>
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users 
> 
> ClusterLabs home: https://www.clusterlabs.org/