[ClusterLabs] Antw: Re: Antw: [EXT] staggered resource start/stop
Ulrich.Windl at rz.uni-regensburg.de
Tue Apr 6 08:45:39 EDT 2021
>>> Klaus Wenninger <kwenning at redhat.com> schrieb am 06.04.2021 um 14:38 in
Nachricht <8dc001d0-c3ed-d9d1-ea91-3a7ebd83b7c0 at redhat.com>:
> On 3/29/21 12:47 PM, Reid Wahl wrote:
>> On Mon, Mar 29, 2021 at 3:35 AM Ulrich Windl
>> <Ulrich.Windl at rz.uni-regensburg.de
>> <mailto:Ulrich.Windl at rz.uni-regensburg.de>> wrote:
>> >>> d tbsky <tbskyd at gmail.com <mailto:tbskyd at gmail.com>> schrieb
>> am 29.03.2021 um 04:01 in Nachricht
>> <CAC6SzHLi0ufVhE3RM57e2V=t_mOmL5ECX8AY3gtcfGmOfKDaxg at mail.gmail.com
>> <mailto:t_mOmL5ECX8AY3gtcfGmOfKDaxg at mail.gmail.com>>:
>> > Hi:
>> > since the vm start/stop at once will consume disk IO, I want to
>> > start/stop the vm
>> > one‑by‑one with delay.
>> I'm surprised that in these days of fast disks and SSDs this is
>> still an
>> Maybe don't delay the start, but limit concurrent starts.
>> Or maybe add some weak ordering between the VMs.
>> kind=Serialize does this. It makes the resources start consecutively,
>> in no particular order. I added the comment about ocf:heartbeat:Delay
>> because D mentioned wanting a delay... but I don't see why it would be
>> necessary, if Serialize is used.
> Wasn't the reason behind all of that the fact that VMs claim to be started
> once the hypervisor is running (at least without any additional measures)
> and that as a consequence starting them serialized wouldn't change much -
> hence the delay (or something more elaborate that actually detects when
> services in a VM are mostly up and not imposing lots of IO or whatever
> load anymore).
That's true: If you boot a typical PVM, then the hypervisor considers the VM
started when actually pvgrub is still in its boot menu. Then there's some I/O
loading kernel and initrd, and then begins the actual I/O.
Maybe limiting the I/O bandwidth would be preferable over serializing starts.
More information about the Users