Resize Together политики
В распределённых системах часто применяется архитектура с избыточностью, в рамках которой несколько виртуальных машин или узлов выполняют одинаковую функцию, но имеют разные роли в обработке трафика.
Обычно используется схема primary/secondary (master/slave):
- Primary (основной узел) — основной экземпляр, который обрабатывает практически весь пользовательский трафик и несёт основную вычислительную нагрузку.
- Secondary (резервные узлы) — один или несколько экземпляров, находящихся в режиме горячего (hot standby) или тёплого резерва (warm standby). Они либо: не обрабатывают пользовательский трафик вовсе (passive), либо принимают незначительную долю нагрузки.
По умолчанию система Octopus даёт две рекомендации:
- для основной ВМ — увеличить ресурсы (Resize UP)
- для резервной ВМ — уменьшить ресурсы (Resize Down)
После выполнения этих рекомендаций возникает проблема: если основная виртуальная машина неожиданно выходит из строя и происходит переключение на резервную, то её ресурсы оказываются недостаточными. Резервная машина не сможет выдержать ту нагрузку, которая была на основной.
В результате соглашение об уровне обслуживания (SLA) нарушается.
Цель данной политики — предотвратить такую ситуацию.
Реализация политики Resize Together
Цель: Сохранять наиболее близкую и похожую друг на друга конфигурацию виртуальных машин, чтобы сделать переключение с основной ВМ наиболее плавным.
Предусловия: В общем виде этого сценария не нужно знать, какая ВМ является основной, система сама определит максимальные значения ресурсов и выдаст соответствующие рекомендации.
Шаги:
- Создайте группу ВМ, которые должны сохранять одинаковую конфигурацию.
- Создайте политику Resize Together для этой группы.
Система определит максимальные рекомендуемые (или текущие) значения по каждому из ресурсов в группе, и выдаст рекомендации:
- Resize up рекомендация будет создана для всех ВМ, значение ресурса которых меньше максимального в группе.