[ClusterLabs] multi-state constraints

[Alastair Basden]

Hi Andrei, all,

So, what I want to achieve is that if both nodes are up, node1 
preferentially has drbd as master.  If that node fails, then node2 should 
become master.  If node1 then comes back online, it should become master 
again.

I also want to avoid node3 and node4 ever running drbd, since they don't 
have the disks.

For the link below about promotion scores, what is the pcs command to 
achieve this?  I'm unfamiliar with where the xml goes...



I notice that drbd9 has an auto promotion feature, perhaps that would help 
here, and so I can forget about configuring drbd in pacemaker?  Is that 
how it is supposed to work?  i.e. I can just concentrate on the overlying 
file system.

Sorry that I'm being a bit slow about all this.

Thanks,
Alastair.

On Tue, 11 May 2021, Andrei Borzenkov wrote:

> [EXTERNAL EMAIL]
>
> On 10.05.2021 20:36, Alastair Basden wrote:
>> Hi Andrei,
>>
>> Thanks.  So, in summary, I need to:
>> pcs resource create resourcedrbd0 ocf:linbit:drbd drbd_resource=disk0 op
>> monitor interval=60s
>> pcs resource master resourcedrbd0Clone resourcedrbd0 master-max=1
>> master-node-max=1 clone-max=2 clone-node-max=1 notify=true
>>
>> pcs constraint location resourcedrb0Clone prefers node1=100
>> pcs constraint location resourcedrb0Clone prefers node2=50
>> pcs constraint location resourcedrb0Clone avoids node3
>> pcs constraint location resourcedrb0Clone avoids node4
>>
>> Does this mean that it will prefer to run as master on node1, and slave
>> on node2?
>
> No. I already told you so.
>
>>   If not, how can I achieve that?
>>
>
> DRBD resource agents sets master scores based on disk state. If you
> statically override this decision you are risking promoting stale copy
> which means data loss (I do not know if agent allows it, hopefully not;
> but then it will continue to attempt to promote wrong copy and
> eventually fail). But if you insist, it is documented:
>
> https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/2.0/html/Pacemaker_Explained/s-promotion-scores.html
>
> Also statically biasing one single node means workload will be relocated
> every time node becomes available, which usually implies additional
> downtime. That is something normally avoided (which is why resource
> stickiness exists).
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/
>