Only the relative difference for values between different alternatives
is relevant, meaning 0.002 vs 0.004 and 0.2 vs 0.4 will influence the
scoring in the same way. This is not really desirable, because values
closer to 1.0 indicate higher load and thus should influence the
scoring more than differences that are actually tiny, but big when
viewed as a relative difference.
To avoid the issue, simply add 1.0 to all values. Like that, 1.002 vs
1.004 will also be small when viewed as a relative difference.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
When nodes have different stats, the sum of percentage values will be
different for different alternatives, so the linear average is enough.
But when nodes have the same stats, this is not the case, the sum will
be the same, thus the average won't influence the scoring. If there is
an already overcommitted node, all alternatives besides the already
overcommitted node would be scored the same.
To fix it, use the squares of percentages instead, where more evenly
distributed usage across nodes will lead to a smaller value and thus
better scoring.
It's not really necessary to divide by length or take the sqrt, but it
seemed nicer to have something that would give 1.0 if all inputs are
1.0.
Reported-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
We already use functions that take or return the full [T; N]
array, so let's just do the same here, it's a bit shorter
this way.
If we get worried about large values we should implement
versions with `&mut [T; N]` consistently for all math
functions.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Models usage of guests and nodes, and allows scoring nodes on which to
start a new service via TOPSIS. For this scoring, each node in turn is
considered as if the service was already running on it.
CPU and memory usage are used as criteria, with memory being weighted
much more, because it's a truly limited resource. For both, CPU and
memory, highest usage among nodes (weighted more, as ideally no node
should be overcommited) and average usage of all nodes (to still be
able to distinguish in case there already is a more highly commited
node) are considered.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Implement the TOPSIS[0] algorithm to score multi-valued alternatives
according to a given set of weighted criteria.
The number of alternatives cannot be known at compile time, but the
number of criteria should be (a given module using the topsis module
should have one (or more) fixed sets of criteria). Therefore, the
TopsisMatrix is implemented as a Vec of N_CRITERIA-sized arrays.
Compared to the description in [0] the weighing of the matrix
according to the weights of the criteria only happens during distance
calculation to the idealized alternatives. It turned out more natural
like that, because the matrix doesn't need to be mutable.
[0]: https://en.wikipedia.org/wiki/TOPSIS
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
