From: Michael Ryom <Michael@RyomHerold.dk>
To: pve-devel@lists.proxmox.com
Cc: Michael Ryom <Michael@RyomHerold.dk>
Subject: [PATCH ha-manager v2 12/14] usage: dynamic: smooth the unaccounted node load
Date: Sun, 18 Oct 2026 14:45:56 +0200 [thread overview]
Message-ID: <20261018124559.24305-13-Michael@RyomHerold.dk> (raw)
In-Reply-To: <20261018124559.24305-1-Michael@RyomHerold.dk>
The dynamic scheduler acts on point-in-time samples of the node and
guest usage stats. The part of the node load that is not caused by any
HA-managed service (non-HA guests, the ZFS ARC, Ceph daemons, the IO of
a rebalance migration itself, sampling skew between node and guest
stats) is noisy, and acting on a single sample makes the automatic load
balancer prone to oscillation: a single dominant HA resource on a small
cluster qualifies for a migration (and afterwards, for its reverse) as
soon as the node base loads fluctuate around each other by a fraction
of the resource's own load.
Decompose each node's load into the usage of the HA-managed services
actually running on it plus a residual, and smooth only the residual
with an exponentially moving average that the manager keeps across
scheduling rounds (not persisted for a CRM failover, like the other
balancer state).
The service usages themselves are deliberately not smoothed: they are
fully modeled by the scheduler, so known structural changes (a service
was migrated, started or stopped, or its measured load changed) take
effect immediately, transient service load spikes remain handled by the
hold duration, and the expected log of no existing regression test
changes. The residual, on the other hand, cannot be attributed to
anything the balancer could act on, and its expected reaction to a
rebalance motion is zero, so a lagging average is safe to act on.
The expected log of test-crs-dynamic-auto-rebalance9 changes, as the
effective base load difference now stays well below the qualification
point and vm:100 is not migrated back and forth anymore.
Signed-off-by: Michael Ryom <Michael@RyomHerold.dk>
---
src/PVE/HA/Manager.pm | 10 ++-
src/PVE/HA/Usage/Dynamic.pm | 73 ++++++++++++++++++-
.../test-crs-dynamic-auto-rebalance9/README | 4 +
.../log.expect | 38 ----------
4 files changed, 85 insertions(+), 40 deletions(-)
diff --git a/src/PVE/HA/Manager.pm b/src/PVE/HA/Manager.pm
index b804602..1721fae 100644
--- a/src/PVE/HA/Manager.pm
+++ b/src/PVE/HA/Manager.pm
@@ -95,6 +95,10 @@ sub new {
# load_balance() is not considered for rebalancing
cooldown => {},
},
+ # exponentially moving average of the unaccounted node load, kept
+ # across rounds by PVE::HA::Usage::Dynamic; also not persisted for a
+ # CRM failover
+ dynamic_stats_smoothing_state => {},
group_migration_round => 3, # wait a little bit
}, $class;
@@ -623,7 +627,11 @@ sub recompute_online_node_usage {
if ($have_dynamic_scheduling) {
$online_node_usage = eval {
$service_stats = $haenv->get_dynamic_service_stats();
- my $scheduler = PVE::HA::Usage::Dynamic->new($haenv, $service_stats);
+ my $scheduler = PVE::HA::Usage::Dynamic->new(
+ $haenv,
+ $service_stats,
+ $self->{dynamic_stats_smoothing_state},
+ );
$scheduler->add_node($_) for $online_nodes->@*;
return $scheduler;
};
diff --git a/src/PVE/HA/Usage/Dynamic.pm b/src/PVE/HA/Usage/Dynamic.pm
index 76d0fea..fc88ddf 100644
--- a/src/PVE/HA/Usage/Dynamic.pm
+++ b/src/PVE/HA/Usage/Dynamic.pm
@@ -8,12 +8,83 @@ use PVE::RS::ResourceScheduling::Dynamic;
use base qw(PVE::HA::Usage);
+# weight of the newest sample in the exponentially moving average of the
+# unaccounted node load; with one sample per CRM scheduling round (~10s),
+# 0.25 averages over roughly the last minute
+my $usage_smoothing_alpha = 0.25;
+
+# Smooths the *unaccounted* part of each node's load with an exponentially
+# moving average kept in $state across invocations.
+#
+# The node load is decomposed into the usage of the HA-managed services
+# running on it plus a residual, and only the residual is smoothed. The
+# residual captures the load that cannot be attributed to any HA-managed
+# service (non-HA guests, ZFS ARC, Ceph daemons, the IO of a rebalance
+# migration itself, sampling skew between the node and guest stats). Those
+# point-in-time samples are noisy, and acting on a single sample makes the
+# load balancer prone to oscillation, while their expected reaction to a
+# rebalance motion is zero, so a lagging average is safe to act on.
+#
+# The service usages themselves are deliberately not smoothed: they are
+# fully modeled by the scheduler, i.e. known structural changes (a service
+# was migrated, started or stopped, or its load changed) take effect
+# immediately, and transient service load spikes are already handled by the
+# hold duration of the load balancer.
+my $smooth_unaccounted_node_load = sub {
+ my ($state, $node_stats, $service_stats) = @_;
+
+ # usage per node of the HA-managed services actually running on it
+ my $accounted = {};
+ for my $sid (keys %$service_stats) {
+ my ($node, $running, $usage) = $service_stats->{$sid}->@{qw(node running usage)};
+ next if !$running || !defined($node) || !$usage;
+ next if !defined($usage->{cpu}) || !defined($usage->{mem});
+
+ $accounted->{$node}->{cpu} += $usage->{cpu};
+ $accounted->{$node}->{mem} += $usage->{mem};
+ }
+
+ for my $node (sort keys %$node_stats) {
+ my $stats = $node_stats->{$node};
+ next if !defined($stats->{cpu}) || !defined($stats->{mem});
+
+ # the residual may become negative if the samples disagree, e.g.
+ # right after a service stopped; only the reconstructed node load is
+ # clamped, so that the residual average is not biased upwards
+ my $residual_sample = {
+ cpu => $stats->{cpu} - ($accounted->{$node}->{cpu} // 0.0),
+ mem => $stats->{mem} - ($accounted->{$node}->{mem} // 0),
+ };
+
+ my $residual = $state->{$node};
+ if (!defined($residual)) {
+ $residual = $state->{$node} = $residual_sample;
+ } else {
+ for my $field (qw(cpu mem)) {
+ $residual->{$field} = $usage_smoothing_alpha * $residual_sample->{$field} +
+ (1 - $usage_smoothing_alpha) * $residual->{$field};
+ }
+ }
+
+ my $cpu = $residual->{cpu} + ($accounted->{$node}->{cpu} // 0.0);
+ my $mem = $residual->{mem} + ($accounted->{$node}->{mem} // 0);
+ $stats->{cpu} = $cpu > 0.0 ? $cpu : 0.0;
+ $stats->{mem} = $mem > 0 ? int($mem) : 0;
+ }
+
+ # drop state of meanwhile removed nodes
+ delete $state->{$_} for grep { !$node_stats->{$_} } keys %$state;
+};
+
sub new {
- my ($class, $haenv, $service_stats) = @_;
+ my ($class, $haenv, $service_stats, $smoothing_state) = @_;
my $node_stats = eval { $haenv->get_dynamic_node_stats() };
die "did not get dynamic node usage information - $@" if $@;
+ $smooth_unaccounted_node_load->($smoothing_state, $node_stats, $service_stats)
+ if defined($smoothing_state);
+
my $scheduler = eval { PVE::RS::ResourceScheduling::Dynamic->new() };
die "unable to initialize dynamic scheduling - $@" if $@;
diff --git a/src/test/test-crs-dynamic-auto-rebalance9/README b/src/test/test-crs-dynamic-auto-rebalance9/README
index 93b27c4..56bb608 100644
--- a/src/test/test-crs-dynamic-auto-rebalance9/README
+++ b/src/test/test-crs-dynamic-auto-rebalance9/README
@@ -14,3 +14,7 @@ imbalance improvement of about 10.4% exceeds the default margin of 10%.
Acting on the raw samples moves the dominant resource back and forth with
every flip, even though the fluctuation is well within the noise of a real
node's base load.
+
+With the exponentially moving average over the unaccounted node load, the
+effective base load difference stays well below the point where a motion
+qualifies, so no motion may be issued at any point.
diff --git a/src/test/test-crs-dynamic-auto-rebalance9/log.expect b/src/test/test-crs-dynamic-auto-rebalance9/log.expect
index efd4d2c..73e381a 100644
--- a/src/test/test-crs-dynamic-auto-rebalance9/log.expect
+++ b/src/test/test-crs-dynamic-auto-rebalance9/log.expect
@@ -19,48 +19,10 @@ info 21 node1/lrm: service status vm:100 started
info 22 node2/crm: status change wait_for_quorum => slave
info 120 cmdlist: execute node node1 set-dynamic-stats cpu 5.064 mem 0
info 120 cmdlist: execute node node2 set-dynamic-stats cpu 4.536 mem 0
-info 140 node1/crm: auto rebalance - migrate vm:100 to node2 (expected change for imbalance from 52.8% to 47.2%)
-info 140 node1/crm: got crm command: migrate vm:100 node2
-info 140 node1/crm: migrate service 'vm:100' to node 'node2'
-info 140 node1/crm: service 'vm:100': state changed from 'started' to 'migrate' (node = node1, target = node2)
-info 141 node1/lrm: service vm:100 - start migrate to node 'node2'
-info 141 node1/lrm: service vm:100 - end migrate to node 'node2'
-info 143 node2/lrm: got lock 'ha_agent_node2_lock'
-info 143 node2/lrm: status change wait_for_agent_lock => active
-info 160 node1/crm: service 'vm:100': state changed from 'migrate' to 'started' (node = node2)
-info 163 node2/lrm: starting service vm:100
-info 163 node2/lrm: service status vm:100 started
info 220 cmdlist: execute node node1 set-dynamic-stats cpu 4.536 mem 0
info 220 cmdlist: execute node node2 set-dynamic-stats cpu 5.064 mem 0
-info 220 node1/crm: auto rebalance - migrate vm:100 to node1 (expected change for imbalance from 52.8% to 47.2%)
-info 220 node1/crm: got crm command: migrate vm:100 node1
-info 220 node1/crm: migrate service 'vm:100' to node 'node1'
-info 220 node1/crm: service 'vm:100': state changed from 'started' to 'migrate' (node = node2, target = node1)
-info 223 node2/lrm: service vm:100 - start migrate to node 'node1'
-info 223 node2/lrm: service vm:100 - end migrate to node 'node1'
-info 240 node1/crm: service 'vm:100': state changed from 'migrate' to 'started' (node = node1)
-info 241 node1/lrm: starting service vm:100
-info 241 node1/lrm: service status vm:100 started
info 320 cmdlist: execute node node1 set-dynamic-stats cpu 5.064 mem 0
info 320 cmdlist: execute node node2 set-dynamic-stats cpu 4.536 mem 0
-info 360 node1/crm: auto rebalance - migrate vm:100 to node2 (expected change for imbalance from 52.8% to 47.2%)
-info 360 node1/crm: got crm command: migrate vm:100 node2
-info 360 node1/crm: migrate service 'vm:100' to node 'node2'
-info 360 node1/crm: service 'vm:100': state changed from 'started' to 'migrate' (node = node1, target = node2)
-info 361 node1/lrm: service vm:100 - start migrate to node 'node2'
-info 361 node1/lrm: service vm:100 - end migrate to node 'node2'
-info 380 node1/crm: service 'vm:100': state changed from 'migrate' to 'started' (node = node2)
-info 383 node2/lrm: starting service vm:100
-info 383 node2/lrm: service status vm:100 started
info 420 cmdlist: execute node node1 set-dynamic-stats cpu 4.536 mem 0
info 420 cmdlist: execute node node2 set-dynamic-stats cpu 5.064 mem 0
-info 440 node1/crm: auto rebalance - migrate vm:100 to node1 (expected change for imbalance from 52.8% to 47.2%)
-info 440 node1/crm: got crm command: migrate vm:100 node1
-info 440 node1/crm: migrate service 'vm:100' to node 'node1'
-info 440 node1/crm: service 'vm:100': state changed from 'started' to 'migrate' (node = node2, target = node1)
-info 443 node2/lrm: service vm:100 - start migrate to node 'node1'
-info 443 node2/lrm: service vm:100 - end migrate to node 'node1'
-info 460 node1/crm: service 'vm:100': state changed from 'migrate' to 'started' (node = node1)
-info 461 node1/lrm: starting service vm:100
-info 461 node1/lrm: service status vm:100 started
info 1020 hardware: exit simulation - done
--
2.47.3
next prev parent reply other threads:[~2026-10-18 12:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 12:45 [PATCH cluster/ha-manager/manager/docs v2 00/14] auto rebalance: fix failure retry loop and oscillation Michael Ryom
2026-10-18 12:45 ` [PATCH cluster v2 01/14] datacenter config: add HA auto-rebalance margin mode and cooldown Michael Ryom
2026-10-18 12:45 ` [PATCH ha-manager v2 02/14] manager: factor out checking whether a resource motion is queued or running Michael Ryom
2026-10-18 12:45 ` [PATCH ha-manager v2 03/14] test: add auto rebalance test cases for failing rebalance motions Michael Ryom
2026-10-18 12:45 ` [PATCH ha-manager v2 04/14] fix #8059: manager: auto rebalance: do not retry failed rebalance motions right away Michael Ryom
2026-10-18 12:45 ` [PATCH ha-manager v2 05/14] test: add auto rebalance test case for an immediate reverse motion Michael Ryom
2026-10-18 12:45 ` [PATCH ha-manager v2 06/14] manager: auto rebalance: add optional cooldown for moved resources Michael Ryom
2026-10-18 12:45 ` [PATCH ha-manager v2 07/14] test: add auto rebalance test case for a marginal absolute improvement Michael Ryom
2026-10-18 12:45 ` [PATCH ha-manager v2 08/14] manager: auto rebalance: allow an absolute margin Michael Ryom
2026-10-18 12:45 ` [PATCH ha-manager v2 09/14] sim: hardware: report actual running state in cluster service stats Michael Ryom
2026-10-18 12:45 ` [PATCH ha-manager v2 10/14] sim: hardware: allow setting a base load for nodes Michael Ryom
2026-10-18 12:45 ` [PATCH ha-manager v2 11/14] test: add auto rebalance test case for fluctuating node base loads Michael Ryom
2026-10-18 12:45 ` Michael Ryom [this message]
2026-10-18 12:45 ` [PATCH manager v2 13/14] ui: crs options: expose the auto-rebalance margin mode and cooldown Michael Ryom
2026-10-18 12:45 ` [PATCH docs v2 14/14] ha-manager: document the auto-rebalance margin mode, cooldown and failed migrations Michael Ryom
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=20261018124559.24305-13-Michael@RyomHerold.dk \
--to=michael@ryomherold.dk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.