[ClusterLabs] trigger something at ?

lejeczek peljasz at yahoo.co.uk
Thu Feb 1 08:31:56 EST 2024



On 31/01/2024 18:11, Ken Gaillot wrote:
> On Wed, 2024-01-31 at 16:37 +0100, lejeczek via Users wrote:
>> On 31/01/2024 16:06, Jehan-Guillaume de Rorthais wrote:
>>> On Wed, 31 Jan 2024 16:02:12 +0100
>>> lejeczek via Users <users at clusterlabs.org> wrote:
>>>
>>>> On 29/01/2024 17:22, Ken Gaillot wrote:
>>>>> On Fri, 2024-01-26 at 13:55 +0100, lejeczek via Users wrote:
>>>>>> Hi guys.
>>>>>>
>>>>>> Is it possible to trigger some... action - I'm thinking
>>>>>> specifically
>>>>>> at shutdown/start.
>>>>>> If not within the cluster then - if you do that - perhaps
>>>>>> outside.
>>>>>> I would like to create/remove constraints, when cluster
>>>>>> starts &
>>>>>> stops, respectively.
>>>>>>
>>>>>> many thanks, L.
>>>>>>
>>>>> You could use node status alerts for that, but it's risky for
>>>>> alert
>>>>> agents to change the configuration (since that may result in
>>>>> more
>>>>> alerts and potentially some sort of infinite loop).
>>>>>
>>>>> Pacemaker has no concept of a full cluster start/stop, only
>>>>> node
>>>>> start/stop. You could approximate that by checking whether the
>>>>> node
>>>>> receiving the alert is the only active node.
>>>>>
>>>>> Another possibility would be to write a resource agent that
>>>>> does what
>>>>> you want and order everything else after it. However it's even
>>>>> more
>>>>> risky for a resource agent to modify the configuration.
>>>>>
>>>>> Finally you could write a systemd unit to do what you want and
>>>>> order it
>>>>> after pacemaker.
>>>>>
>>>>> What's wrong with leaving the constraints permanently
>>>>> configured?
>>>> yes, that would be for a node start/stop
>>>> I struggle with using constraints to move pgsql (PAF) master
>>>> onto a given node - seems that co/locating paf's master
>>>> results in troubles (replication brakes) at/after node
>>>> shutdown/reboot (not always, but way too often)
>>> What? What's wrong with colocating PAF's masters exactly? How does
>>> it brake any
>>> replication? What's these constraints you are dealing with?
>>>
>>> Could you share your configuration?
>> Constraints beyond/above of what is required by PAF agent
>> itself, say...
>> you have multiple pgSQL cluster with PAF - thus multiple
>> (separate, for each pgSQL cluster) masters and you want to
>> spread/balance those across HA cluster
>> (or in other words - avoid having more that 1 pgsql master
>> per HA node)
>> These below, I've tried, those move the master onto chosen
>> node but.. then the issues I mentioned.
>>
>> -> $ pcs constraint location PGSQL-PAF-5438-clone prefers
>> ubusrv1=1002
>> or
>> -> $ pcs constraint colocation set PGSQL-PAF-5435-clone
>> PGSQL-PAF-5434-clone PGSQL-PAF-5433-clone role=Master
>> require-all=false setoptions score=-1000
>>
> Anti-colocation sets tend to be tricky currently -- if the first
> resource can't be assigned to a node, none of them can. We have an idea
> for a better implementation:
>
>   https://projects.clusterlabs.org/T383
>
> In the meantime, a possible workaround is to use placement-
> strategy=balanced and define utilization for the clones only. The
> promoted roles will each get a slight additional utilization, and the
> cluster should spread them out across nodes whenever possible. I don't
> know if that will avoid the replication issues but it may be worth a
> try.
using _balanced_ causes a small mayhem to PAF/pgsql:

-> $ pcs property
Cluster Properties:
  REDIS-6380_REPL_INFO: ubusrv3
  REDIS-6381_REPL_INFO: ubusrv2
  REDIS-6382_REPL_INFO: ubusrv2
  REDIS-6385_REPL_INFO: ubusrv1
  REDIS_REPL_INFO: ubusrv1
  cluster-infrastructure: corosync
  cluster-name: ubusrv
  dc-version: 2.1.2-ada5c3b36e2
  have-watchdog: false
  last-lrm-refresh: 1706711588
  placement-strategy: default
  stonith-enabled: false

-> $ pcs resource utilization PGSQL-PAF-5438 cpu="20"

-> $ pcs property set placement-strategy=balanced # when 
resource stops:
I change it back:
-> $ pcs property set placement-strategy=default
and pgSQL/paf works again

I've not used _utilization_ nor _placement-strategy_ before, 
thus chance that I'm missing something is solid.


More information about the Users mailing list