Управление KeyVRM¶

KeyVRM (KeyStack Virtual Resource Manager) управляет отказоустойчивостью и балансировкой нагрузки виртуальных машин на уровне зон доступности и хост-агрегатов. Сервис регулярно собирает состояние региона, анализирует состояние вычислительных узлов и виртуальных машин, формирует рекомендации по эвакуации или миграции ВМ и передаёт их на выполнение через Executor.

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

Для анализа состояния региона, выполнения операций и управления конфигурацией KeyVRM использует следующие системы и сервисы:

из OpenStack получает топологию региона, зоны доступности, хост-агрегаты, гипервизоры, ВМ, группы серверов, образы и ресурсы Placement;
из VictoriaMetrics через Prometheus-совместимый API получает метрики CPU, RAM, сетевой нагрузки, HugePages и состояния интерфейсов;
из Redis Sentinel получает heartbeat гипервизоров;
через Nova, Cinder, Neutron и Placement выполняет миграции, эвакуации и сопутствующие операции;
через BMC, IPMI, Redfish, Ceph и Nova выполняет фенсинг;
через Temporal оркестрирует периодические и длительные процессы;
в PostgreSQL хранит конфигурацию, снимки региона, события, рекомендации и операции;
через Портал администратора предоставляет операторам доступ к просмотру и изменению бизнес-конфигурации.

Собственного компонента для экспорта метрик у KeyVRM нет: сервис читает метрики, уже собранные в VictoriaMetrics.

Режимы работы KeyVRM¶

Для каждого хост-агрегата KeyVRM использует активный режим обработки. Режим задаётся параметром marker в конфигурации хост-агрегата:

Режим	Описание
`HA`	Режим High Availability. KeyVRM анализирует состояние вычислительных узлов, находит отказавшие или небезопасные гипервизоры, выполняет фенсинг и формирует рекомендации по эвакуации ВМ.
`LB`	Режим Load Balancing. KeyVRM анализирует метрики нагрузки гипервизоров и ВМ, находит перегруженные узлы, подбирает целевые гипервизоры и формирует рекомендации по живой миграции.
`HA+LB`	Комбинированный режим. KeyVRM сначала запускает HA-логику. Если HA создала рекомендации по эвакуации, LB в этом цикле не запускается. Если HA не создала рекомендации, KeyVRM проверяет период `lb_period` и при необходимости запускает LB-логику.

Если для хост-агрегата не задан marker или включён no_op_mode, KeyVRM запускает NoopWorkflow. В этом режиме сервис видит хост-агрегат, учитывает его в обзоре, но не создаёт HA- и LB-рекомендации.

Новые хост-агрегаты создаются в базе данных KeyVRM с включённым no_op_mode=true. Это защищает регион от автоматических действий до тех пор, пока оператор не проверит параметры агрегата, не выберет режим marker и не выключит NOOP.

Как работает цикл KeyVRM¶

KeyVRM работает циклически. За запуск цикла отвечает MasterWorkflow.

Общий порядок работы:

Worker создаёт или обновляет расписание Temporal.
По расписанию запускается MasterWorkflow.
MasterWorkflow читает app_config.
Если app_config.enabled=false, цикл завершается без обработки.
Если сервис включён, KeyVRM синхронизирует период расписания с app_config.period.
KeyVRM проверяет уже запущенные процессы, чтобы не планировать конфликтующие действия над одними и теми же гипервизорами.
Запускается HarvesterWorkflow.
HarvesterWorkflow собирает данные из OpenStack, VictoriaMetrics и Redis Sentinel.
KeyVRM синхронизирует список хост-агрегатов с OpenStack.
Для каждого хост-агрегата KeyVRM выбирает процесс обработки по marker и no_op_mode.
Процесс обработки HA, LB или HA+LB создаёт событие и рекомендации, если найдены подходящие действия.
Для созданных рекомендаций запускается ExecutorWorkflow.
По результатам операций событие получает итоговое состояние healthy, warning или error.

Для агрегатов без marker или с включённым no_op_mode KeyVRM выполняет только noop-activity и не создаёт события и рекомендации.

Снимок региона¶

KeyVRM принимает решения не по живым объектам напрямую, а по снимку региона. В начале каждого цикла HarvesterWorkflow собирает данные из внешних систем, сериализует их и сохраняет в region_data. HA- и LB-алгоритмы работают с этим снимком как с согласованным состоянием региона на момент запуска цикла.

Снимок региона содержит:

зоны доступности и хост-агрегаты из Nova;
состав гипервизоров в каждом хост-агрегате;
состояние службы вычислительного узла: state, status, admin_state, disabled_reason, error_details;
инвентарь и потребление ресурсов Placement по VCPU и MEMORY_MB;
ВМ на каждом гипервизоре: флейвор, статус, проект, образ, группа серверов и метаданные;
группы серверов и правила affinity/anti-affinity;
свойства образов, которые нужны для фильтров Nova;
метрики гипервизоров и ВМ из VictoriaMetrics: CPU, RAM, сетевая нагрузка, HugePages;
данные о недоступных интерфейсах из VictoriaMetrics;
heartbeat гипервизора из Redis Sentinel.

KeyVRM использует метаданные ВМ для запрета действий и приоритизации эвакуации:

метаданные по ключу ha_no_evacuate_key преобразуются во внутренний признак no_evac;
метаданные по ключу lb_no_migrate_key преобразуются во внутренний признак no_migr;
метаданные evacuate_order используются как приоритет эвакуации: ВМ с меньшим значением обрабатываются раньше.

Если для ВМ не задан приоритет эвакуации, KeyVRM чередует выборку ВМ с наибольшим потреблением CPU и RAM: сначала выбирает ВМ с наибольшим потреблением CPU, затем ВМ с наибольшим потреблением RAM, затем следующую ВМ по CPU и следующую ВМ по RAM.

События, рекомендации и операции¶

В KeyVRM используются три основные сущности:

Сущность	Назначение
`event`	Один запуск HA-, LB- или HA+LB-логики для конкретного хост-агрегата и снимка региона.
`recommendation`	Одно предложенное действие над ВМ: эвакуация для HA или живая миграция для LB.
`operation`	Журнал фактического исполнения рекомендации.

В журнале operation фиксируются:

старт;
подготовка;
выполнение;
успешное завершение;
повторная попытка;
ошибка;
очистка;
отмена.

Статус события показывает стадию процесса: создано, генерирует рекомендации, сгенерировало рекомендации, ожидает ручного действия, исполняется или завершено. Состояние события показывает итоговую оценку: healthy, warning или error.

Событие получает состояние error, если все рекомендации события завершились ошибкой. Если часть рекомендаций выполнена, а часть завершилась ошибкой или была отменена, событие может завершиться с состоянием warning.

Рекомендация создаётся в одном из стартовых статусов:

Статус	Описание
`created`	Рекомендация готова к автоматическому выполнению.
`manual_action`	Executor запущен, но ожидает ручное подтверждение. Если подтверждения нет до истечения `executor_manual_action_timeout`, рекомендация отменяется.

Для LB-рекомендаций KeyVRM показывает расчёт нагрузки:

Исходная нагрузка — ожидаемое состояние гипервизора, с которого выполняется живая миграция;
Целевая нагрузка — ожидаемое состояние гипервизора, на который выполняется живая миграция.

В расчёте нагрузки отображаются значения CPU, RAM, сетевой нагрузки и общий syn_score. syn_score рассчитывается по метрикам и весам, заданным в настройках LB хост-агрегата.

Executor выполняет рекомендации через Nova:

для HA запускает эвакуацию ВМ на выбранный целевой гипервизор;
для LB запускает живую миграцию ВМ на выбранный целевой гипервизор;
после отправки операции опрашивает статус миграции в Nova;
записывает изменения в operations;
при известных ошибках пытается очистить port binding и volume attachment;
если количество повторений одной и той же ошибки достигает значения поля Макс. одинаковых ошибок, переводит рекомендацию в финальную ошибку и отправляет alert.

Если рекомендация перешла в финальную ошибку, обработка хост-агрегата для LB не останавливается.

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

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

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

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

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

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

Подготовка KeyVRM к работе¶

Перед началом эксплуатации разверните KeyVRM и выполните первичную настройку:

включение и развёртывание сервиса описаны в разделе Включение KeyVRM;
подключение к мультирегиональному Порталу администратора описано в разделе Подключение KeyVRM к мультирегиональному Порталу администратора;
глобальная конфигурация описана в разделе Глобальная конфигурация;
назначение и настройка фильтров Nova описаны в разделе Фильтры Nova;
конфигурация хост-агрегатов описана в разделе Конфигурация хост-агрегата;
проверка результата описана в разделе Проверка после настройки.

Временное отключение автоматических действий¶

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

Для временного отключения автоматических действий выполните следующие действия:

Откройте Портал администратора.
Перейдите в раздел KeyVRM.
В таблице зон доступности выберите нужную зону.
В строке хост-агрегата откройте меню действий и выберите Редактирование конфигурации.
Включите Режим NOOP.
В поле Причина NOOP укажите причину, например, плановые работы или обновление.
Нажмите кнопку Изменить.
Выполните работы в регионе.
После завершения работ повторно откройте конфигурацию хост-агрегата.
Выключите Режим NOOP.
Нажмите кнопку Изменить.

Режим NOOP в конфигурации хост-агрегата KeyVRM¶

Если работы затрагивают несколько хост-агрегатов, включите NOOP для каждого из них.

После выключения NOOP проверьте, что в поле Маркер отображается нужный режим, а Режим NOOP выключен.

Активное состояние хост-агрегата KeyVRM¶

Просмотр состояния и событий хост-агрегата¶

Для просмотра состояния хост-агрегатов выполните следующие действия:

Откройте Портал администратора.
Перейдите в раздел KeyVRM.
Выберите зону доступности.
Проверьте значения в столбцах Маркер и Режим NOOP.

Хост-агрегаты зоны доступности в KeyVRM¶

Для просмотра событий нажмите на название хост-агрегата. На странице агрегата отображаются текущее событие и история событий с идентификатором, статусом, маркером, состоянием и временем создания.

Управление рекомендациями¶

KeyVRM создаёт рекомендации по результатам HA- и LB-обработки.

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

Для LB-рекомендаций параметр lb_recommendations_auto_run определяет стартовый режим:

если true, рекомендации создаются в статусе created и Master сразу запускает Executor;
если false, рекомендации создаются в статусе manual_action, а Executor ожидает ручное подтверждение.

В ручном режиме оператор должен запустить рекомендацию до истечения тайм-аута ручной рекомендации. Если тайм-аут истёк, рекомендация отменяется.

При marker=HA+LB HA имеет приоритет над LB. Если HA создала рекомендации по эвакуации, LB в этом цикле не запускается. Это защищает регион от плановой живой миграции в момент, когда хост-агрегату может требоваться аварийная эвакуация.

Диагностика¶

Если KeyVRM не создаёт события, рекомендации или операции, проверьте возможные причины.

Причина	Что проверить
KeyVRM выключен	Проверьте, что в глобальной конфигурации включён параметр KeyVRM включён.
Хост-агрегат находится в `NOOP`	Проверьте Режим NOOP и Причину NOOP в конфигурации хост-агрегата. Пока `NOOP` включён, KeyVRM не создаёт HA- и LB-рекомендации для агрегата.
Не задан режим обработки	Проверьте поле Маркер в конфигурации хост-агрегата. Для обработки агрегата должен быть выбран режим `HA`, `LB` или `HA+LB`.
В глобальной конфигурации не указаны фильтры Nova	Проверьте поле Фильтры Nova. Если поле пустое, KeyVRM не применяет фильтры при выборе целевых гипервизоров. Подробнее см. в разделе Фильтры Nova.
LB запущен слишком рано	Проверьте Период запуска, с в конфигурации хост-агрегата, время последнего LB-события и время последней LB-рекомендации.
Перегрузки нет	Проверьте `syn_score` гипервизоров и значение Порог перегрузки гипервизора, %.
Нет подходящего целевого гипервизора для LB	Проверьте ресурсы Placement, фильтры Nova, занятые исходные и целевые гипервизоры, а также значение Предельная нагрузка таргет-гипервизора, %.
Ручная LB-рекомендация отменена	Проверьте, не истёк ли Таймаут ручной рекомендации, мин. Если оператор не запустил рекомендацию до истечения тайм-аута, рекомендация отменяется.
Рекомендация завершилась ошибкой	Откройте операции рекомендации и проверьте последнюю ошибку. Если все рекомендации события завершились ошибкой, событие получает состояние `error`.
HA не может выполнить фенсинг	Проверьте `ha_fence_ceph`, `ha_fence_bmc`, `ha_fence_nova`, поле Fence: интерфейсы (HA) и параметры подключения к Ceph, BMC, IPMI или Redfish. Поле Таймаут power-check (HA), с задаёт тайм-аут проверки результата действия BMC-фенсинга. Установите значение поля исходя из фактического времени полного отключения питания оборудования.
Не включён ни один механизм фенсинга	Проверьте, что в глобальной конфигурации включён хотя бы один механизм фенсинга: Fence Ceph (HA), Fence BMC (HA) или Fence Nova (HA). Если не включён ни один fencer, HA-событие завершается ошибкой без рекомендаций по эвакуации.
Нет метрик VictoriaMetrics	Проверьте доступность VictoriaMetrics и наличие метрик CPU, RAM, сетевой нагрузки, HugePages и состояния интерфейсов.
В одном хост-агрегате смешаны обычные ВМ и ВМ с HugePages	Разделите такие ВМ по разным хост-агрегатам или уточните допустимую конфигурацию у ответственного инженера.
ВМ запрещена к эвакуации или миграции	Проверьте метаданные, которые соответствуют ключам `ha_no_evacuate_key` и `lb_no_migrate_key`.

Ограничения¶

При работе с KeyVRM учитывайте ограничения:

не используйте KeyVRM одновременно с другими механизмами автоматической эвакуации ВМ и балансировки нагрузки в одном регионе;
не выключайте NOOP для нового хост-агрегата до проверки marker и параметров HA/LB;
если поле Фильтры Nova пустое, KeyVRM не применяет фильтры Nova при выборе целевых гипервизоров;
HA+LB работает последовательно, а не параллельно;
LB не запускается в цикле HA+LB, если HA создала рекомендации по эвакуации;
HA не создаёт рекомендации по эвакуации, если не включён ни один механизм фенсинга;
Таймаут сброса состояния ВМ (HA), с не влияет на обработку HA в текущей версии;
ручная LB-рекомендация отменяется, если оператор не запустил её до истечения тайм-аута ручной рекомендации;
если рекомендация перешла в финальную ошибку, обработка хост-агрегата для LB не останавливается;
KeyVRM не переводит гипервизор в режим обслуживания, если после эвакуации на нём осталась хотя бы одна ВМ;
событие получает состояние error, если все рекомендации события завершились ошибкой;
событие получает состояние warning, если часть рекомендаций выполнена, а часть завершилась ошибкой или была отменена;
LB завершает событие ошибкой, если в одном хост-агрегате одновременно обнаружены обычные ВМ и ВМ с HugePages;
KeyVRM не выполняет живую миграцию на этапе построения LB-плана: сначала сервис создаёт рекомендации, затем Executor выполняет их.