[ClusterLabs] multi-state constraints
arvidjaar at gmail.com
Tue May 11 06:56:56 EDT 2021
On Tue, May 11, 2021 at 10:50 AM Alastair Basden
<a.g.basden at durham.ac.uk> wrote:
> 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
> 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 do not normally use PCS so am not familiar with its syntax. I assume
there should be documentation that describes how to define location
constraints with rules. Maybe someone who is familiar with it can
provide an example.
> 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.
> 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/
> Manage your subscription:
> ClusterLabs home: https://www.clusterlabs.org/
More information about the Users