From: "Dominik Rusovac" <d.rusovac@proxmox.com>
To: "Daniel Kral" <d.kral@proxmox.com>,
"Michael Ryom" <Michael@RyomHerold.dk>,
<pve-devel@lists.proxmox.com>
Subject: Re: [PATCH ha-manager 3/7] manager: auto rebalance: require a minimum absolute imbalance improvement
Date: Wed, 14 Oct 2026 15:03:54 +0200 [thread overview]
Message-ID: <DM4KYX3OHYPG.33TP3Q3YTN6LS@proxmox.com> (raw)
In-Reply-To: <DM4K40LS6MM9.3I8DPQ80XKSE8@proxmox.com>
On Wed Oct 14, 2026 at 2:23 PM CEST, Daniel Kral wrote:
> On Sun Sep 20, 2026 at 6:22 PM CEST, Michael Ryom wrote:
>> The automatic load balancer only requires a relative improvement of the
>> node imbalance (default 10%). When a single resource dominates the
>> cluster load, the relative margin provides almost no hysteresis: with
>> two nodes, a resource load v and a node base load difference d, the
>> relative improvement of moving the resource is 2d / (v + d), so it
>> exceeds a margin m as soon as d > v * m / (2 - m). For a mid-size VM
>> that is a base load difference of about half a percentage point, well
>> within the normal fluctuation of e.g. the ZFS ARC or Ceph daemons, and
>> each fluctuation then qualifies a motion (and, after it was carried
>> out, its reverse).
>>
>> Additionally require the imbalance improvement to exceed a minimum
>> absolute value of 5 percentage points. This creates a dead band for
>> motions that shuffle load without meaningfully improving the cluster
>> balance. No expected motion of an existing regression test is affected;
>> the smallest occurring improvement there is 9.6 percentage points.
>>
>> Like the backoff and cooldown constants, this could be exposed as a
>> ha-auto-rebalance-* option later.
>
> I think the absolute minimum imbalance improvement is a good idea.
>
> The relative 'margin' was only introduced to compensate for the
> initially unbound imbalance value for different cluster sizes, which was
> changed to be in [0,1] for all cluster sizes only in a later revision.
>
> Though I'd prefer if this can be configured by users from the get-go.
> For simplicity, I'd merge it with the ha-auto-rebalance-margin option,
> and add a flag which can switch the value's semantic meaning between
> 'relative' (the default, because of backwards compatibility) and
> 'absolute'.
+1
>
> Except if there really are use cases which require both a relative and
> an absolute minimum imbalance improvement?
tbh atm I cannot come up with a use case
actually, I'd find it kind of strange to insist that the relative change
in the load imbalance also corresponds to the absolute change, and vice
versa
[snip]
next prev parent reply other threads:[~2026-10-14 13:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 16:22 [PATCH ha-manager 0/7] auto rebalance: fix failure retry loop, oscillation and idle-cluster churn Michael Ryom
2026-09-20 16:22 ` [PATCH ha-manager 1/7] fix #8059: manager: auto rebalance: back off failed motions and add per-resource cooldown Michael Ryom
2026-10-14 11:49 ` Daniel Kral
2026-09-20 16:22 ` [PATCH ha-manager 2/7] env: dynamic service stats: use host-side memory footprint of guests Michael Ryom
2026-09-21 9:18 ` Dominik Rusovac
2026-09-20 16:22 ` [PATCH ha-manager 3/7] manager: auto rebalance: require a minimum absolute imbalance improvement Michael Ryom
2026-09-22 6:18 ` Dominik Rusovac
2026-09-22 10:09 ` Michael Ryom
2026-10-14 12:23 ` Daniel Kral
2026-10-14 13:03 ` Dominik Rusovac [this message]
2026-09-20 16:22 ` [PATCH ha-manager 4/7] sim: hardware: report actual running state in cluster service stats Michael Ryom
2026-09-20 16:22 ` [PATCH ha-manager 5/7] sim: hardware: allow setting a base load for nodes Michael Ryom
2026-09-20 16:22 ` [PATCH ha-manager 6/7] usage: dynamic: smooth the unaccounted node load Michael Ryom
2026-09-20 16:22 ` [PATCH ha-manager 7/7] manager: auto rebalance: only balance under actual node resource pressure Michael Ryom
2026-10-14 14:29 ` Daniel Kral
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DM4KYX3OHYPG.33TP3Q3YTN6LS@proxmox.com \
--to=d.rusovac@proxmox.com \
--cc=Michael@RyomHerold.dk \
--cc=d.kral@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox