[ClusterLabs] Antw: [EXT] Re: Preferred node for a service (not constrained)

[Strahil Nikolov]

The problem with infinity is that the moment when the node is back - there will be a second failover. This is bad for bulky DBs that power down/up more than 30 min (15 min down, 15 min up).

Best Regards,
Strahil Nikolov






В четвъртък, 3 декември 2020 г., 10:32:18 Гринуич+2, Andrei Borzenkov <arvidjaar at gmail.com> написа: 





On Thu, Dec 3, 2020 at 11:11 AM Ulrich Windl
<Ulrich.Windl at rz.uni-regensburg.de> wrote:
>
> >>> Strahil Nikolov <hunter86_bg at yahoo.com> schrieb am 02.12.2020 um 22:42 in
> Nachricht <311137659.2419591.1606945369370 at mail.yahoo.com>:
> > Constraints' values are varying from:
> > infinity which equals to score of 1000000
> > to:
> > - infinity which equals to score of -1000000
> >
> > You can usually set a positive score on the prefered node which is bigger
> > than on the other node.
> >
> > For example setting a location constraint like this will prefer node1:
> > node1 - score 10000
> > node2 - score 5000
> >
>
> The bad thing with those numbers is that you are never sure which number to
> use:
> Is 50 enough? 100 Maybe? 1000? 10000? 100000?
>

+INFINITY score guarantees that resource will always be active on
preferred node as long as this node is available but allow resource to
be started on another node if preferred node is down.
...
> > I believe I used the value infinity, so it will prefer the 2nd host over
> > the 1st if at all possible.  My 'pcs constraint':
> >

And this was the very first answer to this question.


> > [root at centos-vsa2 ~]# pcs constraint
> > Location Constraints:
> >  Resource: group-zfs
> >    Enabled on: centos-vsa2 (score:INFINITY)
> > Ordering Constraints:
> > Colocation Constraints:
> > Ticket Constraints:
> >
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/