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

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

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

Функциональность группы ВМ при увеличении размера будет отличаться в зависимости от политики масштабирования:

• Группы ВМ фиксированного размера
• Группы ВМ с автоматическим масштабированием

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

• Автоматическое восстановление ВМ в группе
• Обновление ВМ в группе
• Завершение операций в группе ВМ, начатых до инцидента

Группы ВМ фиксированного размераГруппы ВМ фиксированного размера

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

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

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

Например: ВМ группы размещены по одной в трех зонах 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 ВМ.

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

Группы ВМ с автоматическим масштабированиемГруппы ВМ с автоматическим масштабированием

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

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

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

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

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

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

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

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

Во время зонального инцидента механизм автоматического восстановления ВМ продолжает функционировать в работающих зонах:

• ВМ, считающиеся неработоспособными по статусу в Compute Cloud, по-прежнему будут восстанавливаться вне какой-либо квоты.
• ВМ, считающиеся неработоспособными по состоянию приложения, будут восстанавливаться в рамках квоты max_unavailable, отвечающей в политике развертывания за максимальное количество ВМ, которые могут быть недоступны при обновлении группы. ВМ из проблемной зоны не учитываются в квоте max_unavailable во время инцидента при работе механизма автоматического восстановления, поэтому процесс восстановления в оставшихся зонах функционирует штатно.

Обновление ВМ в группеОбновление ВМ в группе

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

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

Завершение операций в группе ВМ, начатых до инцидентаЗавершение операций в группе ВМ, начатых до инцидента

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

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