[ClusterLabs] Antw: [EXT] Re: staggered resource start/stop

[Ulrich Windl]

>>> Klaus Wenninger <kwenning at redhat.com> schrieb am 30.03.2021 um 07:32 in
Nachricht <9541d96d-be98-15e4-a8eb-966d2ee0ffa9 at redhat.com>:
> On 3/29/21 8:44 AM, d tbsky wrote:
>> Reid Wahl <nwahl at redhat.com>
>>> An order constraint set with kind=Serialize (which is mentioned in the
first 
> reply to the thread you linked) seems like the most logical option to me.
You 
> could serialize a set of resource sets, where each inner set contains a 
> VirtualDomain resource and an ocf:heartbeat:Delay resource.
>>>
>>>   ⁠5.3.1. Ordering Properties 
>
(https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/2.0/html-single/Pacema

> ker_Explained/index.html#idm46061192464416)
>>>   ⁠5.6. Ordering Sets of Resources 
>
(https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/2.0/html-single/Pacema

> ker_Explained/index.html#s-resource-sets-ordering)
>>       thanks a lot! I don't know there is an official RA acting as
>> delay. that's interesting and useful to me.

I was wondering, too:
If pacemaker had a kind of semaphore (as a  resource) and you could "enlist"
the operations of a resource for such a semaphore,
then those operations could be serialized (semaphore initialized to 1) or
cuncurrency-limited (semaphore initalized to n > 1).
The operation would then wait for the semaphore before starting, and post the
semaphore when finished.

If you really want delays instead of rate-limits, a similar concept would
work:
Again use a two semaphores (requests, events) and initialize both to zero.
Then any one wanting to request an operation would post the requests semaphore
and wait on the events semaphore.
Some new resource "event provider" would wait for the requests and post to
events, either after some fixed delay, some random distribution, or
whatever...

But we are getting away from classic cluster then.

> In this case it might be useful not to wait some defined time
> hoping startup of the VM would have gone far enough that
> the IO load has already decayed enough.
> What about a resource that checks for something running
> inside the VM that indicates that startup has completed?

I guess once a domain is consuming significant CPU, it's running.
One could also check for virtual disk writes; those will happen typically
after initrd has finished, but beware if boot hangs on error...

Regards,
Ulrich

> Don't remember if the VirtualDomain RA might already
> have such a probe possibility.
> 
> Klaus
>> _______________________________________________
>> Manage your subscription:
>> https://lists.clusterlabs.org/mailman/listinfo/users 
>>
>> ClusterLabs home: https://www.clusterlabs.org/ 
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users 
> 
> ClusterLabs home: https://www.clusterlabs.org/