[Документация Yandex Cloud](../../../../index.md) > [Yandex Compute Cloud](../../../index.md) > [Концепции](../../index.md) > [Группы виртуальных машин](../index.md) > [Группы ВМ при зональном инциденте](overview.md) > Мультизональная группа с ВМ в зоне инцидента

# Мультизональная группа ВМ Yandex Compute Cloud с ВМ в зоне инцидента

{% note tip %}

Рекомендуется использовать несколько зональных [групп ВМ](../index.md), распределенных по [зонам доступности](../../../../overview/concepts/geo-scope.md), вместо одной мультизональной группы. Так вы получите более гранулярный контроль за распределением и обновлением ВМ, сможете управлять группами ВМ в каждой зоне независимо друг от друга.

{% endnote %}

Чтобы скомпенсировать выпавшие из группы мощности ВМ из проблемной зоны, рекомендуется заранее задавать размер группы ВМ с запасом. Если это не сделано, на время инцидента увеличьте размер группы ВМ в работающих зонах.

Также рекомендуется использовать параметр `max_expansion`, отвечающий в [политике развертывания](../policies/deploy-policy.md) за максимальное количество ВМ, на которое можно расширить группу при ее обновлении. В соответствии с этим параметром при обновлении сначала будут создаваться новые ВМ и только потом удаляться старые. При этом в случае автовосстановления новая ВМ всегда будет создаваться в той же зоне, где и старая, если эта зона доступна.

Функциональность группы ВМ при увеличении размера будет отличаться в зависимости от [политики масштабирования](../policies/scale-policy.md):

* [Группы ВМ фиксированного размера](#increase-fixed-size)
* [Группы ВМ с автоматическим масштабированием](#increase-scalable)

Смотрите также особенности других действий в группе ВМ при зональном инциденте:

* [Автоматическое восстановление ВМ в группе](#autohealing)
* [Обновление ВМ в группе](#update)
* [Завершение операций в группе ВМ, начатых до инцидента](#operation-completion)

## Группы ВМ фиксированного размера {#increase-fixed-size}

В группах фиксированного размера ВМ распределяются строго равномерно по зонам доступности. Это поведение сохраняется и при зональном инциденте.

Если в группу добавить ВМ в количестве, кратном количеству зон, то в каждую зону будет определено равное количество ВМ. Новые ВМ в работающих зонах будут созданы сразу, новые ВМ в проблемной зоне будут созданы после окончания инцидента.

Если в группу добавить ВМ в количестве, не кратном количеству зон, то остаток будет распределяться только среди работающих зон. Если распределение по зонам уже неравномерное, чтобы восстановить равномерность, ВМ будут добавляться в ту зону, где меньше всего ВМ, вне зависимости от того, работает зона или нет.

> Например: ВМ группы размещены по одной в трех зонах `kz1-a`, `kz1-b` и `kz1-d`.
>
> В отсутствие инцидента, если увеличить размер группы на 2 ВМ, то распределение по зонам будет следующим:
> * `kz1-a`: 2 ВМ;
> * `kz1-b`: 2 ВМ;
> * `kz1-d`: 1 ВМ.
> 
> В случае инцидента в зоне `kz1-b`:
> * `kz1-a`: 2 ВМ;
> * `kz1-b`: 1 ВМ;
> * `kz1-d`: 2 ВМ.

Таким образом, вы можете самостоятельно разработать алгоритм для автоматической компенсации выбывших ресурсов в проблемной зоне.

{% note warning %}

При зональном инциденте часть ВМ, добавляемых в группу фиксированного размера, будет попадать в проблемную зону. Рекомендуется обеспечивать запас по производительности и соблюдать количество ВМ, кратное числу зон.

{% endnote %}

## Группы ВМ с автоматическим масштабированием {#increase-scalable}

В группах с автоматическим масштабированием новые ВМ распределяются по зонам доступности по принципу наилучшей эффективности, исходя из параметров, заданных в [политике масштабирования](../policies/scale-policy.md#auto-scale-policy).

> Например, если для работы сервиса требуется 9 ВМ и сервис размещен в двух зонах доступности, то в каждой зоне должно быть по 9 ВМ, то есть суммарно 18.
> 
> Или, если для сервиса требуется 9 ВМ и сервис размещен в трех зонах доступности, то суммарно в группе должно быть 12 ВМ.

{% note tip %}

Чтобы скомпенсировать выпавшие из группы мощности ВМ из проблемной зоны, рекомендуется задавать максимальное количество ВМ (параметр `max_size` политики масштабирования) с запасом.

{% endnote %}

Вне зависимости от [типа автоматического масштабирования](../scale.md#auto-scale-type) количество ВМ в проблемной зоне перестает изменяться. Во время инцидента ВМ создаются и удаляются только в зонах, не затронутых инцидентом. Новые ВМ создаются до исчерпания квоты `max_size` политики масштабирования.

_Зональный_ тип автоматического масштабирования не предполагает равномерного распределения ВМ по зонам. В зонах, не затронутых инцидентом, ВМ создаются или удаляются в зависимости от нагрузки.

_Региональный_ тип автоматического масштабирования предполагает равномерное распределение ВМ по зонам. Во время инцидента может возникнуть дисбаланс в этом распределении.

После завершения инцидента ВМ автоматически перераспределяются по всем зонам в зависимости от выбранного типа автоматического масштабирования.

## Автоматическое восстановление ВМ в группе {#autohealing}

Во время зонального инцидента механизм [автоматического восстановления](../autohealing.md#healthcheck-cases) ВМ продолжает функционировать в работающих зонах:

* ВМ, считающиеся неработоспособными по [статусу в Compute Cloud](../autohealing.md#auto-healthcheck), по-прежнему будут восстанавливаться вне какой-либо квоты.
* ВМ, считающиеся неработоспособными по [состоянию приложения](../autohealing.md#functional-healthcheck), будут восстанавливаться в рамках квоты `max_unavailable`, отвечающей в [политике развертывания](../policies/deploy-policy.md) за максимальное количество ВМ, которые могут быть недоступны при обновлении группы. ВМ из проблемной зоны не учитываются в квоте `max_unavailable` во время инцидента при работе механизма автоматического восстановления, поэтому процесс восстановления в оставшихся зонах функционирует штатно.

## Обновление ВМ в группе {#update}

Во время зонального инцидента можно произвести обновление ВМ до новой версии.

В доступных зонах изменения применяются сразу, а в проблемной достигают целевого состояния по окончании инцидента. 

{% note warning %}

Чтобы обезопасить группу от полной потери всех ВМ при обновлении, ВМ из проблемной зоны учитываются в квоте `max_unavailable` [политики развертывания](../policies/deploy-policy.md). Поэтому для обновления ВМ группы во время инцидента следует увеличивать значение параметра `max_expansion`.

{% endnote %}

## Завершение операций в группе ВМ, начатых до инцидента {#operation-completion}

Если обновление ВМ началось до зонального инцидента, то даже если в момент инцидента производились операции с ВМ в проблемной зоне, процесс не зависнет, а продолжится в оставшихся зонах, если не превышена квота `max_unavailable` [политики развертывания](../policies/deploy-policy.md). После окончания инцидента оставшиеся ВМ в проблемной зоне будут доведены до целевого состояния.

{% note info %}

Сервис стремится довести группу ВМ до заданного целевого состояния, поэтому допустимо смешение различных сценариев изменения группы.

{% endnote %}

> Например, если до инцидента делалось обновление ВМ, а после возникла необходимость в масштабировании, то новые ВМ будут создаваться уже по новой целевой спецификации.

### Полезные ссылки {#see-also}

* [Группы виртуальных машин Yandex Compute Cloud при зональном инциденте](overview.md)
* [Временное отключение зон доступности для групп ВМ Yandex Compute Cloud](../disable-enable-zone.md)