This document describes an enhancement of Ganeti’s instance placement by taking into account that some nodes are vulnerable to common failures.
Contents
Currently, Ganeti considers all nodes in a single node group as equal. However, this is not true in some setups. Nodes might share common causes of failure or be even located in different places with spacial redundancy being a desired feature.
The similar problem for instances, i.e., instances providing the same external service should not placed on the same nodes, is solved by means of exclusion tags. However, there is no mechanism for a good choice of node pairs for a single instance. Moreover, while instances providing the same service run on different nodes, they are not spread out location wise.
We propose to the cluster metric (as used, e.g., by hbal and hail) to honor additional node tags indicating nodes that might have a common cause of failure.
As for exclusion tags, cluster tags will determine which tags are considered to denote a source of common failure. More precisely, a cluster tag of the form htools:nlocation:x will make node tags starting with x: indicate a common cause of failure, that redundant instances should avoid.
The following components will be added cluster metric, weighed appropriately.
The weights for these components might have to be tuned as experience with these setups grows, but as a starting point, both components will have a weight of 0.5 each. In this way, any common-failure violations are less important than any hard constraints missed (instances on offline nodes, N+1 redundancy, exclusion tags) so that the hard constraints will be restored first when balancing a cluster. Nevertheless, with weight 0.5 the new common-failure components will still be significantly more important than all the balancedness components (cpu, disk, memory), as the latter are standard deviations of fractions.
Appart from changing the balancedness metric, common-failure tags will not have any other effect. In particular, as opposed to exclusion tags, no hard guarantees are made: hail will try allocate an instance in a common-failure avoiding way if possible, but still allocate the instance if not.
Inequality between nodes can also restrict the set of instance migrations possible. Here, the most prominent example is updating the hypervisor where usually migrations from the new to the old hypervisor version is not possible.
As for exclusion tags, cluster tags will determine which tags are considered restricting migration. More precisely, a cluster tag of the form htools:migration:x will make node tags starting with x: a migration relevant node property. Additionally, cluster tags of the form htools:allowmigration:y::z where y and z are migration tags not containing :: specify a unidirectional migration possibility from y to z.
An instance migration will only be considered by htools, if for all migration tags y present on the node migrated from, either the tag is also present on the node migrated to or there is a cluster tag htools::allowmigration:y::z and the target node is tagged z (or both).
For the simple hypervisor upgrade, where migration from old to new is possible, but not the other way round, tagging all already upgraded nodes suffices.
These tags are of advisory nature only. That is, all htools will strictly obey the restrictions imposed by those tags, but Ganeti will not prevent users from manually instructing other migrations.