Allocating instances across zones
Allocation of instances across zones depends on the group scaling type.
In manually scaled groups
In manually scaled groups, instances are distributed evenly between zones.
In accordance with the deployment policy, instances are added to each zone sequentially, one at a time. If the list of zones is exhausted, but the desired number of instances is not created, zones are reused.
Tip
We recommend creating an instance group so that its size is a multiple of the number of zones.
In this case, every zone will host the same number of instances, and a network load balancer (if any) will evenly allocate the load between instances.
If the group size is not a multiple of the number of zones, some zones will host less instances than others, but no more than one instance less.
Examples
If you listed zones in the [ru-central1-d, ru-central1-a] order in the YAML specification, and the size of the group is 4, then after allocation you will have two VM instances in each zone:
| Step | ru-central1-d | ru-central1-a | Left |
|---|---|---|---|
| 1 | 1 | 0 | 3 |
| 2 | 1 | 1 | 2 |
| 3 | 2 | 1 | 1 |
| 4 | 2 | 2 | 0 |
If you listed zones in the [ru-central1-d, ru-central1-a] order in the YAML specification, and the size of the group is 5, then after allocation you will have three instances in ru-central1-d and two instances in ru-central1-a:
| Step | ru-central1-d | ru-central1-a | Left |
|---|---|---|---|
| 1 | 1 | 0 | 4 |
| 2 | 1 | 1 | 3 |
| 3 | 2 | 1 | 2 |
| 4 | 2 | 2 | 1 |
| 5 | 3 | 2 | 0 |
Let's assume you listed three zones in the [ru-central1-d, ru-central1-a, ru-central1-b] order in the specification, and the fixed size of the group is 2, which is lower than the number of zones. In this case, one VM instance will be created both in ru-central1-d and ru-central1-a, and no VM instances will be created in ru-central1-b. Although we do not recommend such configuration, it is not prohibited.
In automatically scaled groups
Unlike fixed-size groups, the order of zones in automatically scaled instance groups makes no difference.
The number of instances in zones is determined by the automatic scaling algorithm based on the average utilization and average load per zone. It can change depending on the restrictions set by the user:
-
min_zone_size(minimum zone size): The zone cannot have fewer instances than specified inmin_zone_size.This restriction allows you to maintain a reserve of instances in the zone in case of a sudden load increase.
You may specifymin_zone_size=0. In this case, the zone may be empty. -
max_size(maximum size of the whole group): The group cannot have more instances than specified inmax_size(in total for all zones).By limiting the number of instances in an automatically scaled group you can control your finance costs.
Examples
The min_zone_size restriction is taken into account during allocation
Let's say min_zone_size is equal to 2, and the automatic scaling algorithm calculated that you need 0 instances in the zone. In this case, you will have 2 instances in the zone, because that is the minimum allowed number of instances in the zone.
The min_zone_size and max_size restrictions are taken into account during allocation
Let's assume you have a min_zone_size of 5, max_size of 20, and the automatic scaling algorithm allocated instances across the zones as follows: 15 + 10 + 5.
-
You have 30 instances in total. This is 10 instances more than
max_size. The algorithm removes instances from each zone until 10 are removed in total.
The more instances there are in a zone, the more instances you can remove from it. However, at least 5 instances must remain in every zone. -
One possible allocation option is 9 + 6 + 5.
Six instances are removed from the largest zone (15 before, 9 after), four are removed from the medium zone (10 before, 6 after), and nothing is removed from the smallest group, because it already has the minimum allowable number of instances (5).