Управление 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`	Журнал фактического исполнения рекомендации.

Конфигурация хост-агрегата задаёт параметры его обработки, включая marker со значением HA, LB или HA+LB и параметр no_op_mode. Назначение и настройка параметров описаны в разделе Конфигурация хост-агрегата.

В журнале 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 через Портал администратора и API сервиса. Портал обращается к API 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`.

Поиск событий эвакуации и миграции в OpenSearch¶

Для проверки выполнения эвакуации и живой миграции ВМ используйте журналы KeyVRM в OpenSearch Dashboards. По журналам можно найти ВМ, определить UUID связанной с ней рекомендации и проверить историю изменения ее статусов.

На Портале администратора перейдите в раздел Журналы событий > Анализ логов.
В OpenSearch Dashboards откройте вкладку Discover и выберите шаблон индексов, соответствующий журналам KeyVRM. На скриншотах ниже используется шаблон flog-*. Если подходящего шаблона нет, создайте его по инструкции в разделе Создание шаблона индексов в OpenSearch.
Установите временной диапазон, соответствующий времени выполнения операции. По умолчанию используется интервал 15 минут. Если записи не найдены, проверьте, охватывает ли выбранный диапазон время события.
При необходимости добавьте фильтр по полю Logger.keyword с условием is и значением infra.keyvrm.
Для удобства просмотра результатов добавьте колонки Hostname, log_level, Logger, programname и Payload. Для этого в списке доступных полей слева нажмите + напротив нужного поля. Поиск можно выполнять и без дополнительных колонок.
Если необходимо найти события эвакуации ВМ, введите в строке DQL запрос:
```
"Evacuating server"
```
В результатах поиска найдите нужную ВМ. В поле Payload указаны UUID ВМ и имена исходного и целевого гипервизоров.

Результаты поиска событий эвакуации ВМ в OpenSearch¶
Если необходимо найти события живой миграции ВМ, используйте запрос:
```
"Migrating server"
```
В результатах поиска также указаны UUID ВМ и имена исходного и целевого гипервизоров.

Результаты поиска событий миграции ВМ в OpenSearch¶
Определите UUID нужной ВМ в поле Payload. Если UUID уже известен, поиск по сообщениям Evacuating server и Migrating server можно пропустить.
Для поиска UUID рекомендации введите следующий запрос, заменив <vm_id> на UUID виртуальной машины:
```
Payload: "Received openstack_request_id" and Payload: "vm_id=<vm_id>"
```
Например, для ВМ с UUID 9db72c10-e765-48a1-b5f3-b51fead09567 используйте запрос:
```
Payload: "Received openstack_request_id" and Payload: "vm_id=9db72c10-e765-48a1-b5f3-b51fead09567"
```
В поле Payload найдите UUID рекомендации после текста for recommendation.

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

Поиск UUID рекомендации KeyVRM по UUID виртуальной машины¶
Для просмотра истории статусов рекомендации введите следующий запрос, заменив <rec_id> на UUID рекомендации:
```
Payload: "Recommendation <rec_id> status updated"
```
Например, для рекомендации 34ba8d1f-e5e5-4e0e-8a9b-db13cabe4e45 используйте запрос:
```
Payload: "Recommendation 34ba8d1f-e5e5-4e0e-8a9b-db13cabe4e45 status updated"
```
Проверьте время записей и значения статусов в поле Payload.

Статус success означает успешное выполнение рекомендации. В истории также могут присутствовать статусы started, preparing, running, retry и error.

Учитывайте последовательность изменения статусов: запись error может предшествовать повторной попытке выполнения рекомендации. Для оценки результата проверьте наиболее позднюю запись по времени.

История статусов рекомендации эвакуации с ошибками и повторными попытками¶

История статусов рекомендации миграции с результатом success¶

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

При работе с 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 выполняет их.