proposal of divide replicas by static weight evenly
Signed-off-by: chaosi-zju <chaosi@zju.edu.cn>
This commit is contained in:
chaosi-zju
parent
1b2c6edfba
commit
68656bfbe9
|
|
@ -0,0 +1,212 @@
|
|||
---
|
||||
title: divide replicas by static weight evenly
|
||||
authors:
|
||||
- "@chaosi-zju"
|
||||
reviewers:
|
||||
- "@RainbowMango"
|
||||
- "@XiShanYongYe-Chang"
|
||||
- "@zhzhuang-zju"
|
||||
approvers:
|
||||
- "@RainbowMango"
|
||||
|
||||
creation-date: 2023-11-11
|
||||
---
|
||||
|
||||
# Divide replicas by static weight evenly
|
||||
|
||||
## Summary
|
||||
|
||||
Karmada supports specifying the number of replicas to be allocated to each member cluster in a static weight ratio,
|
||||
e.g., the user specifies that the total replicas of a Deployment is 5,
|
||||
and the requirement is to distribute them into two clusters, member1 and member2, with a static weight of 1:1.
|
||||
|
||||
According to the current implementation, the result must be 3 replicas for member1 and 2 replicas for member2.
|
||||
(5 is an odd number, so it can't be divided equally, and member1 allocates one more).
|
||||
|
||||
This is because for clusters with equal weights, the remainder prefers the cluster with the smaller dictionary order of cluster names
|
||||
in current implementation (the remainder is the number of replicas left over if the total replicas is not exactly divided by the static weights).
|
||||
|
||||
If there are many such Deployments, the total replicas of member1 cluster will be significantly higher than that of member2 cluster,
|
||||
i.e., a potential problem of uneven replicas distribution.
|
||||
|
||||
Therefore, in order to solve the uneven replicas allocation problem without affecting the scheduling inertia,
|
||||
I propose to optimize the sorting of clusters when allocating the remainder as:
|
||||
|
||||
* Sort the clusters first by weights
|
||||
* If the weights are equal, then the clusters are sorted according to the current number of replicas
|
||||
(more current number of replicas implies that the remainders of the last scheduling were randomized to such clusters,
|
||||
and in order to keep the inertia in this scheduling, such clusters should also be prioritized).
|
||||
* If the weights are equal and the current number of replicas is equal too, then the clusters will be randomized.
|
||||
|
||||
|
||||
## Motivation
|
||||
|
||||
### Problem Summary
|
||||
|
||||
The essence of above case is that the "total replicas" is not divisible by the "sum weights", and a remainder is generated.
|
||||
|
||||
The remainder is preferred allocating to clusters with higher dictionary order of cluster name when they have equal weights,
|
||||
which caused unevenness of replicas distribution.
|
||||
|
||||
Therefore, Karmada needs to do:
|
||||
|
||||
* The remainder should be assigned to clusters having equal weights with equal probability
|
||||
* Scheduler rescheduling should ensure inertia of the scheduling result
|
||||
|
||||
### Current realization
|
||||
|
||||
#### Example
|
||||
```
|
||||
sum replicas = 7，clusters = [member1, member2, member3]，weight = 2 : 1 : 1
|
||||
```
|
||||
|
||||
#### Calculation Formula
|
||||
|
||||
```console
|
||||
each cluster allocations = (total replicas * each cluster weight) / sum weights
|
||||
|
||||
remainders = total replicas - sum (each cluster allocations)
|
||||
```
|
||||
|
||||
#### Detail Steps
|
||||
|
||||
* Calculate cluster allocations and remainders：
|
||||
|
||||
```
|
||||
member1 = 7 * 2 / 4 = 3
|
||||
member2 = 7 * 1 / 4 = 1
|
||||
member3 = 7 * 1 / 4 = 1
|
||||
|
||||
so, remainders = 2
|
||||
```
|
||||
|
||||
* Sort clusters: first by weight, then by dictionary order of cluster name (member1 > member2 > member3)
|
||||
* Assign the remainders to the sorted clusters one by one (one for member1 and another for member2)
|
||||
* Eventually: member1 = 4、member2 = 2、member3 = 1
|
||||
|
||||
### Expected goals
|
||||
|
||||
As in the above example, since member2 and member3 have equal weights, when assigning the remainder, it must be assigned to member2 first,
|
||||
which is not expected
|
||||
|
||||
We expect that it will be assigned to member2 and member3 with equal probability.
|
||||
|
||||
|
||||
## Proposal
|
||||
|
||||
Since the unevenness of the current implementation is caused by sorting the clusters in dictionary order,
|
||||
the simplest way is changing it to directly randomize the ordering when the weights are equal.
|
||||
|
||||
However, it requires consideration of scheduling inertia, avoiding biased rescheduling results due to the introduction of randomization.
|
||||
|
||||
Therefore, to solve the problem of uneven replicas allocation, I propose to optimize the ordering of clusters when allocating remainders as:
|
||||
|
||||
1. Sort the clusters first by weights
|
||||
2. If the weights are equal, then the clusters are sorted according to the current number of replicas
|
||||
(more current number of replicas implies that the remainders of the last scheduling were randomized to such clusters,
|
||||
and in order to keep the inertia in this scheduling, such clusters should also be prioritized).
|
||||
3. If the weights are equal and the current number of replicas is equal too, then the clusters will be randomized.
|
||||
|
||||
|
||||
### User Stories
|
||||
|
||||
#### Story 1：expanded replicas scenario
|
||||
|
||||
In expanding replicas scenario, we expect directly increasing replicas in several clusters,
|
||||
avoiding different results calculated when rescheduling due to randomness, which leads to some clusters increasing replicas, while others reducing replica.
|
||||
|
||||
Yet this proposal can avoid this problem:
|
||||
|
||||
```
|
||||
sum replicas = 7，clusters = [member1, member2, member3, member4]，weight = 2 : 1 : 1 : 1
|
||||
|
||||
1、Calculation：【each cluster allocations】= 2、1、1、1，【remainders】= 2 // 7*2/5=2、7*1/5=1
|
||||
2、Sorting：member1 > member2 = member3 = member4
|
||||
3、One possible result：3、2、1、1
|
||||
|
||||
Supposing sum replicas change from 7 to 8
|
||||
|
||||
1、Calculation：【each cluster allocations】= 3、1、1、1，【remainders】= 2 // 8*2/5=3、8*1/5=1
|
||||
2、Sorting：member1 > member2 > member3 = member4 // member2 has more current replicas than member3 / member4
|
||||
3、Result：4、2、1、1 (results ensured inertia)
|
||||
```
|
||||
|
||||
#### Story 2：reduced replicas scenario
|
||||
|
||||
In reducing replicas scenario, we expect directly reducing replicas in several clusters,
|
||||
avoiding different results calculated when rescheduling due to randomness, which leads to some clusters increasing replicas, while others reducing replica.
|
||||
|
||||
Yet this proposal can avoid this problem:
|
||||
|
||||
```
|
||||
sum replicas = 9，clusters = [member1, member2, member3, member4]，weight = 2 : 1 : 1 : 1
|
||||
|
||||
1、Calculation：【each cluster allocations】= 3、1、1、1，【remainders】= 3 // 9*2/5=3、9*1/5=1
|
||||
2、Sorting：member1 > member2 = member3 = member4
|
||||
3、One possible result：4、2、2、1
|
||||
|
||||
Supposing sum replicas change from 9 to 8
|
||||
|
||||
1、Calculation：【each cluster allocations】= 3、1、1、1，【remainders】= 2 // 8*2/5=3、8*1/5=1
|
||||
2、Sorting：member1 > member2 = member3 > member4 // member2 and member3 has more current replicas than member4
|
||||
3、Result：4、2、1、1 or 4、1、2、1 (results ensured inertia)
|
||||
|
||||
```
|
||||
|
||||
#### Story 3：modifying Weight Scenarios
|
||||
|
||||
Modifying the weight scenario generally involves increasing or decreasing each cluster replicas, rescheduling can be directly recalculated.
|
||||
|
||||
However, assuming that the weights are adjusted and the sum replicas is also adjusted, it is important to ensure inertia as much as possible.
|
||||
|
||||
```
|
||||
sum replicas = 6，clusters = [member1, member2, member3, member4]，weight = 1 : 1 : 1 : 1
|
||||
|
||||
1、Calculation：【each cluster allocations】= 1、1、1、1，【remainders】= 2 // 6*1/4=1
|
||||
2、Sorting：member1 = member2 = member3 = member4
|
||||
3、One possible result：2、1、2、1
|
||||
|
||||
1）Supposing weight change to 2 : 1 : 1 : 1
|
||||
|
||||
1、Calculation：【each cluster allocations】= 2、1、1、1，【remainders】= 1 // 6*2/5=2、6*1/5=1
|
||||
2、Sorting：member1 > member3 > member2 = member4 // member3 has more current replicas than member2 / member4
|
||||
3、Result：3 : 1 : 1 : 1 (Minimal adjustments based on weights)
|
||||
|
||||
2）Supposing weight change to 2 : 1 : 1 : 1, and sum replicas change to 7
|
||||
|
||||
1、Calculation：【each cluster allocations】= 2、1、1、1，【remainders】= 2 // 7*2/5=2、7*1/5=1
|
||||
2、Sorting：member1 > member3 > member2 = member4 // member3 has more current replicas than member2 / member4
|
||||
3、Result：3 : 1 : 2 : 1 (results ensured inertia)
|
||||
```
|
||||
|
||||
#### Story 4：expanded clusters scenario
|
||||
|
||||
```
|
||||
sum replicas = 5，clusters = [member1, member2, member3]，weight = 1 : 1 : 1
|
||||
|
||||
1、Calculation：【each cluster allocations】= 1、1、1，【remainders】= 2 // 5*1/3=1
|
||||
2、Sorting：member1 = member2 = member3
|
||||
3、One possible result：2、1、2
|
||||
|
||||
Supposing after clusters expanded，clusters = [member1, member2, member3, member4]，weight = 1 : 1 : 1 : 1
|
||||
|
||||
1、Calculation：【each cluster allocations】= 1、1、1、1，【remainders】= 1 // 5*1/4=1
|
||||
2、Sorting：member1 = member3 > member2 > member4
|
||||
3、Result：1、1、2、1 or 2、1、1、1 (equivalent to move one replica from member1/member3 to member4, others keep unchanged)
|
||||
```
|
||||
|
||||
#### Story 5：reduced clusters scenario
|
||||
|
||||
```
|
||||
sum replicas = 5，clusters = [member1, member2, member3, member4]，weight = 1 : 1 : 1 : 1
|
||||
|
||||
1、Calculation：【each cluster allocations】= 1、1、1、1，【remainders】= 1 // 5*1/4=1
|
||||
2、Sorting：member1 = member2 = member3 = member4
|
||||
3、One possible result：2、1、1、1
|
||||
|
||||
Supposing after clusters reduced，clusters = [member1, member2, member3]，weight = 1 : 1 : 1
|
||||
|
||||
1、Calculation：【each cluster allocations】= 1、1、1，【remainders】= 2 // 5*1/3=1
|
||||
2、Sorting：member1 > member2 = member3
|
||||
3、Result：2、2、1 or 2、1、2 (equivalent to move one replica from member4 to member1/member3, others keep unchanged)
|
||||
```
|
||||
Loading…
Reference in New Issue