Difference between revisions of "Scheduler/NormalizedWeights"
| (5 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
== Overview == | == Overview == | ||
| − | + | Weighs were originally used in the scheduler, but they are also used in the | |
| − | them. This makes difficult to properly use multipliers for establishing | + | cells code. This is still applicable to them also. |
| − | the relative importance between two weighters (one big magnitude | + | |
| − | shade a smaller one). For example, a | + | Currently we are using the raw values directly from the available weighers, |
| − | values will need a multiplier that is big enough | + | instead of normalizing them. This makes difficult to properly use multipliers |
| − | regard to the RAM | + | for establishing the relative importance between two weighters (one big magnitude |
| + | will shade a smaller one). | ||
| + | |||
| + | For example, a weigher that is returning 0 and 1 as values will need a multiplier | ||
| + | that is big enough, so that it is taken into account with regard to the RAM weigher, | ||
| + | that would return higher values (i.e. free RAM). The current workaround is the | ||
| + | usage of big enough multipliers for each weigher, or using a large enough weight | ||
| + | value. However, even if a system is properly configured, a RAM upgrade would | ||
| + | imply a review and reconfiguracion of the weighers (if the infrastructure is | ||
| + | heterogeneous, the problem is even worse). | ||
This blueprint aims to introduce weight normalization so that we can apply | This blueprint aims to introduce weight normalization so that we can apply | ||
| − | + | multiple weighers easily. All the weights will be normalized between 0.0 and | |
| − | + | 1.0, so that the final weight for a host will be as follows: | |
| − | normalized between 0.0 and 1.0, so that the final weight for a host | ||
| − | will be as follows: | ||
weight = w1_multiplier * norm(w1) + w2_multiplier * norm(w2) + ... | weight = w1_multiplier * norm(w1) + w2_multiplier * norm(w2) + ... | ||
This way it is easier for a resource provider to configure and establish the | This way it is easier for a resource provider to configure and establish the | ||
| − | importance between the | + | importance between the weighers, since the operator knows well in advance that |
| + | the maximum value that a weigher will return is 1.0 and the minimum is 0.0. | ||
Two kinds of normalization will be provided: | Two kinds of normalization will be provided: | ||
| − | * If the | + | * If the weigher specifies the upper and lower values, the weighed objects will be normalized with regard to these values. |
| − | * In the case that the | + | * In the case that the weigher does not supply the lower and upper limits for the weighed objects, the maximum and minimum values from the weighed objects will be used. |
| + | |||
| + | Moreover, the RamWeigher used the multiplier to change its beahaviour. To | ||
| + | change the "spreading" behaviour to "stacking" an operator has to put a | ||
| + | negative multiplier. Hoever, if somebody is using several weighers this won't | ||
| + | be true. | ||
== Examples == | == Examples == | ||
| − | === | + | === New weigher returing 0 and 1 === |
| − | + | ||
| + | Currently the RamWeigher returns the available RAM in MB as the weight for a | ||
| + | node. Assume that we are implementing a weigher that will return 0 and 1 | ||
| + | values (for example true or false for a cached instance image). If we have | ||
| + | nodes with some GB of RAM, we should put a multiplier big enough to make the | ||
| + | new weigher influence the final weight. If we upgrade the nodes to some hundreds | ||
| + | of GB of RAM, we readapt also the weigher. If we have an heterogeneous cluster, | ||
| + | we should study carefully how we can make this weigher really count. | ||
| + | |||
| + | === Cells RamByInstanceTypeWeigher and MuteChildWeigher === | ||
| − | + | The MuteChildWeigher is a good example of inflating a weight so that it can be | |
| − | + | significant enough so as to compete with the RamByInstanceTypeWeigher. It has | |
| + | defined a 'mute_weight_value=1000.0' and a 'mute_weight_multiplier=-10.0' so | ||
| + | that it can really influence the final weight. However, if we introduce some | ||
| + | nodes with a lager RAM, we should need to reconfigure it. | ||
| − | + | == Upgrade Notes == | |
| − | + | * https://review.openstack.org/#/c/27160/ | |
| − | + | * Weights are normalized, so there is no need to inflate multipliers | |
| + | artificially. The maximum weight that a weigher will put for a node is 1.0 | ||
| + | and the minimum is 0.0. | ||
| + | * nova.cells.weights.weight_offset.WeightOffsetWeigher introduces a new | ||
| + | configuration option 'offset_weight_multiplier' | ||
| + | * https://review.openstack.org/#/c/36417/ | ||
| + | * Introduce stacking flags for weighers. Negative multipliers should not be | ||
| + | using for stacking, but the weighers are still compatible (the issue a | ||
| + | deprecation warning message). | ||
| + | * https://review.openstack.org/#/c/55873/ | ||
| + | * The mute_weight_value has been removed so the operators need | ||
| + | to adjust the mute_weight_multiplier to a proper value if they weren't | ||
| + | using the defaults. If they're using the defaults, no action is needed, | ||
| + | since the multiplier has been adjusted. | ||
| + | * https://review.openstack.org/#/c/44255/ | ||
| + | * New flag that allows an operator to weigh the nodes based on the % of RAM. | ||
Latest revision as of 16:26, 9 December 2013
Contents
Overview
Weighs were originally used in the scheduler, but they are also used in the cells code. This is still applicable to them also.
Currently we are using the raw values directly from the available weighers, instead of normalizing them. This makes difficult to properly use multipliers for establishing the relative importance between two weighters (one big magnitude will shade a smaller one).
For example, a weigher that is returning 0 and 1 as values will need a multiplier that is big enough, so that it is taken into account with regard to the RAM weigher, that would return higher values (i.e. free RAM). The current workaround is the usage of big enough multipliers for each weigher, or using a large enough weight value. However, even if a system is properly configured, a RAM upgrade would imply a review and reconfiguracion of the weighers (if the infrastructure is heterogeneous, the problem is even worse).
This blueprint aims to introduce weight normalization so that we can apply multiple weighers easily. All the weights will be normalized between 0.0 and 1.0, so that the final weight for a host will be as follows:
weight = w1_multiplier * norm(w1) + w2_multiplier * norm(w2) + ...
This way it is easier for a resource provider to configure and establish the importance between the weighers, since the operator knows well in advance that the maximum value that a weigher will return is 1.0 and the minimum is 0.0.
Two kinds of normalization will be provided:
- If the weigher specifies the upper and lower values, the weighed objects will be normalized with regard to these values.
- In the case that the weigher does not supply the lower and upper limits for the weighed objects, the maximum and minimum values from the weighed objects will be used.
Moreover, the RamWeigher used the multiplier to change its beahaviour. To change the "spreading" behaviour to "stacking" an operator has to put a negative multiplier. Hoever, if somebody is using several weighers this won't be true.
Examples
New weigher returing 0 and 1
Currently the RamWeigher returns the available RAM in MB as the weight for a node. Assume that we are implementing a weigher that will return 0 and 1 values (for example true or false for a cached instance image). If we have nodes with some GB of RAM, we should put a multiplier big enough to make the new weigher influence the final weight. If we upgrade the nodes to some hundreds of GB of RAM, we readapt also the weigher. If we have an heterogeneous cluster, we should study carefully how we can make this weigher really count.
Cells RamByInstanceTypeWeigher and MuteChildWeigher
The MuteChildWeigher is a good example of inflating a weight so that it can be significant enough so as to compete with the RamByInstanceTypeWeigher. It has defined a 'mute_weight_value=1000.0' and a 'mute_weight_multiplier=-10.0' so that it can really influence the final weight. However, if we introduce some nodes with a lager RAM, we should need to reconfigure it.
Upgrade Notes
* Weights are normalized, so there is no need to inflate multipliers artificially. The maximum weight that a weigher will put for a node is 1.0 and the minimum is 0.0. * nova.cells.weights.weight_offset.WeightOffsetWeigher introduces a new configuration option 'offset_weight_multiplier'
* Introduce stacking flags for weighers. Negative multipliers should not be using for stacking, but the weighers are still compatible (the issue a deprecation warning message).
* The mute_weight_value has been removed so the operators need to adjust the mute_weight_multiplier to a proper value if they weren't using the defaults. If they're using the defaults, no action is needed, since the multiplier has been adjusted.
* New flag that allows an operator to weigh the nodes based on the % of RAM.
