Настройка и управление KeyVRM¶

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

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

KeyVRM не заменяет Nova, Cinder, Placement, Prometheus и Портал администратора. Сервис использует эти системы как источники данных и исполнительные системы:

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

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

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

HA: Режим High Availability. KeyVRM анализирует состояние вычислительных узлов, находит отказавшие или небезопасные гипервизоры, выполняет фенсинг и формирует рекомендации по эвакуации ВМ.
LB: Режим Load Balancing. KeyVRM анализирует метрики нагрузки гипервизоров и ВМ, находит перегруженные узлы, подбирает целевые гипервизоры и формирует рекомендации по live migration.
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, Prometheus и Redis Sentinel.
KeyVRM синхронизирует список хост-агрегатов с OpenStack.
Для каждого хост-агрегата KeyVRM выбирает workflow по marker и no_op_mode.
HA, LB или HA+LB workflow создает событие и рекомендации, если найдены подходящие действия.
Для созданных рекомендаций запускается ExecutorWorkflow.
По результатам операций событие получает итоговое состояние healthy, warning или error.

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

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

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

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

зоны доступности и хост-агрегаты из Nova;
состав гипервизоров в каждом хост-агрегате;
состояние compute service: state, status, admin_state, disabled_reason, error_details;
инвентарь и потребление ресурсов Placement по VCPU и MEMORY_MB;
ВМ на каждом гипервизоре: флейвор, статус, проект, образ, группа серверов и метаданные;
server groups и правила affinity/anti-affinity;
свойства образов, которые нужны для Nova-like фильтров;
метрики гипервизоров и ВМ из Prometheus: CPU, RAM, сетевая нагрузка, HugePages;
failed interfaces из Prometheus;
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 или live migration для LB.
operation: Журнал фактического исполнения рекомендации: старт, подготовка, выполнение, успешное завершение, повторная попытка, ошибка, очистка или отмена.

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

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

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

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

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

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

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

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

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

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

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

Перед началом работы¶

Перед настройкой KeyVRM через Портал администратора убедитесь, что сервис уже развёрнут в регионе, подключён к Admin UI Backend и доступен в интерфейсе.

В этой статье описаны действия администратора после того, как KeyVRM уже развёрнут и доступен в Портале администратора. Настройка развёртывания, подключений, секретов, сертификатов и интеграций KeyVRM описана в разделе Настройка развёртывания и подключений KeyVRM.

В разделе KeyVRM должны быть доступны:

статус сервиса;
сводка по зонам доступности, хост-агрегатам, активным процессам, проблемным агрегатам и агрегатам в NOOP;
список зон доступности и хост-агрегатов, которые KeyVRM может обрабатывать;
кнопка Глобальная конфигурация.

Перед изменением параметров проверьте, что в регионе уже есть хост-агрегаты и вычислительные узлы:

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

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

Конфигурация KeyVRM¶

Конфигурация KeyVRM разделена на две зоны ответственности:

конфигурация развёртывания и подключений сервиса;
конфигурация обработки региона и бизнес-логики.

Конфигурация развёртывания и подключений сервиса задаёт, где и как запущен KeyVRM и как сервис подключается к внешним системам. Эта часть настраивается при развёртывании региона и не изменяется через Портал администратора. Подробнее см. в разделе Настройка развёртывания и подключений KeyVRM.

Конфигурация обработки региона и бизнес-логики определяет, как KeyVRM обрабатывает регион и конкретные хост-агрегаты. Она хранится в базе данных KeyVRM и изменяется через KeyVRM API, Admin UI Backend или CLI.

К этой части относятся:

включение или выключение обработки региона;
период запуска MasterWorkflow;
Nova-like фильтры, которые KeyVRM учитывает при выборе целевых гипервизоров;
metadata-ключи для HA и LB;
сохранение ephemeral-диска при эвакуации;
режимы фенсинга;
интерфейсы, по которым KeyVRM проверяет отказ перед фенсингом;
параметры Executor;
marker для каждого хост-агрегата;
no_op_mode для каждого хост-агрегата;
резервы CPU и RAM для каждого хост-агрегата;
веса, пороги, период запуска и автозапуск рекомендаций LB для каждого хост-агрегата.

Параметры глобальной конфигурации применяются ко всему сервису KeyVRM. Параметры хост-агрегата применяются только к выбранному хост-агрегату.

Глобальная конфигурация¶

Глобальная конфигурация применяется ко всему сервису KeyVRM. Она задает включение сервиса, период работы master workflow, общие фильтры, настройки HA, LB и Executor.

Глобальная конфигурация создается при запуске KeyVRM и содержит значения по умолчанию. Перед изменением параметров учитывайте, что глобальная конфигурация влияет на работу HA, LB и Executor во всех хост-агрегатах.

Общие настройки¶

В общих настройках задаются:

KeyVRM включён — включает или выключает обработку региона. Если параметр выключен, KeyVRM не запускает обработку хост-агрегатов. Для временной остановки обработки одного хост-агрегата используйте NOOP в конфигурации хост-агрегата;
Период запуска, с — задает период запуска master workflow. Этот период влияет на общий цикл KeyVRM. Для LB дополнительно используется период запуска в конфигурации хост-агрегата;
Фильтры Nova — задают Nova-like фильтры, которые KeyVRM учитывает при выборе целевых гипервизоров. Если поле пустое, фильтры не применяются.

Пример общих настроек глобальной конфигурации представлен на рисунке ниже.

Общие настройки глобальной конфигурации KeyVRM¶

KeyVRM поддерживает следующие Nova-like фильтры:

SERVER_GROUP_AFFINITY_FILTER;
SERVER_GROUP_ANTI_AFFINITY_FILTER;
COMPUTE_FILTER;
COMPUTE_CAPABILITIES_FILTER;
AGGREGATE_INSTANCE_EXTRA_SPECS_FILTER;
AGGREGATE_MULTI_TENANCY_ISOLATION;
IMAGE_PROPERTIES_FILTER.

Укажите фильтры Nova при настройке глобальной конфигурации, если KeyVRM должен учитывать ограничения Nova при выборе целевых гипервизоров.

Настройки HA¶

В настройках HA задается поведение KeyVRM при обработке отказавших или небезопасных гипервизоров.

Пример настроек HA представлен на рисунке ниже.

Настройки HA в глобальной конфигурации KeyVRM¶

К настройкам HA относятся:

Сохранять ephemeral-диск (HA) — передает в Nova флаг сохранения ephemeral-диска при эвакуации ВМ;
Ключ порядка эвакуации (HA) — задает имя metadata-ключа, по которому KeyVRM определяет приоритет эвакуации ВМ. ВМ с меньшим значением обрабатываются раньше;
Ключ отключения эвакуации (HA) — задает имя metadata-ключа, по которому KeyVRM исключает ВМ из автоматической эвакуации;
Таймаут сброса состояния ВМ (HA), с — устаревший параметр, который не влияет на обработку HA в текущей версии;
Fence: интерфейсы (HA) — задает интерфейсы, по которым KeyVRM выполняет проверку при принятии решения о фенсинге и эвакуации;
Fence Ceph (HA) — включает или выключает Ceph fencing;
Fence BMC (HA) — включает или выключает BMC fencing через IPMI или Redfish;
Fence Nova (HA) — включает или выключает Nova fencing;
Bond-интерфейсы (HA) — задает имена bond-интерфейсов, состояние которых KeyVRM учитывает при проверке отказа;
Режим power-fence (HA) — задает действие BMC-фенсинга: poweroff, shutdown или delayed_poweron;
Таймаут power-check (HA), с — задает тайм-аут проверки результата действия BMC-фенсинга.

Перед созданием рекомендаций по эвакуации HA выполняет фенсинг. В зависимости от глобальной конфигурации KeyVRM может использовать следующие механизмы фенсинга:

Ceph-фенсинг добавляет IP гипервизора в Ceph blacklist.
BMC-фенсинг выполняет действие через IPMI или Redfish и проверяет результат в течение тайм-аута power_check_timeout.
Nova-фенсинг переводит nova-compute service в состояние disabled/fenced и при необходимости выставляет forced down.

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

Настройки LB¶

В глобальных настройках LB задается metadata-ключ, который запрещает миграцию ВМ.

Пример настроек LB представлен на рисунке ниже.

Настройки LB в глобальной конфигурации KeyVRM¶

Если у ВМ заданы метаданные по ключу, указанному в настройках LB, KeyVRM преобразует их во внутренний признак no_migr и не создает для такой ВМ рекомендации по live migration.

Настройки Executor¶

В настройках Executor задается поведение сервиса при выполнении рекомендаций.

Пример настроек Executor представлен на рисунке ниже.

Настройки Executor в глобальной конфигурации KeyVRM¶

К настройкам Executor относятся:

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

Если рекомендация создана в статусе manual_action и оператор не подтвердил выполнение до истечения тайм-аута, рекомендация отменяется.

Конфигурация хост-агрегата¶

Конфигурация хост-агрегата задает режим работы KeyVRM и параметры HA/LB для конкретного хост-агрегата.

Новый хост-агрегат создается в KeyVRM с включенным NOOP. Перед началом обработки агрегата выберите режим работы, проверьте параметры выбранного режима и только после этого выключите NOOP.

Общие настройки¶

В общих настройках хост-агрегата задаются:

Маркер — режим обработки хост-агрегата: HA, LB или HA+LB;
Режим NOOP — безопасный режим, в котором KeyVRM не создает HA- и LB-рекомендации для хост-агрегата;
Причина NOOP — комментарий, почему для хост-агрегата включен NOOP.

Пример общих настроек хост-агрегата представлен на рисунке ниже.

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

Если включаете NOOP, укажите причину. Это помогает другим администраторам понять, почему автоматическая обработка агрегата остановлена.

Настройки HA¶

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

Пример настроек HA хост-агрегата представлен на рисунке ниже.

К настройкам HA хост-агрегата относятся:

Резервирование CPU (HA) — доля CPU, которую KeyVRM оставляет свободной при выборе целевого гипервизора для эвакуации;
Резервирование RAM (HA) — доля RAM, которую KeyVRM оставляет свободной при выборе целевого гипервизора для эвакуации.

Значения резервирования задаются в диапазоне от 0 до 1. Значение 0 означает, что дополнительный резерв не задается. Например, значение 0.2 оставляет резерв 20 % ресурса.

Потенциальный целевой гипервизор для HA должен иметь достаточный запас VCPU и RAM по Placement inventory с учетом allocation ratio, reserved, текущего usage и резервов ha_reservation_ratio_cpu и ha_reservation_ratio_ram.

Настройки LB¶

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

Пример настроек LB хост-агрегата представлен на рисунке ниже.

К настройкам LB хост-агрегата относятся:

Множитель CPU (LB) — вес CPU в расчете синтетической нагрузки;
Множитель RAM (LB) — вес RAM в расчете синтетической нагрузки;
Множитель сети (LB) — вес сетевой нагрузки в расчете синтетической нагрузки;
Автозапуск рекомендаций (LB) — определяет, выполняет ли KeyVRM LB-рекомендации автоматически;
Порог нагрузки гипервизора (LB) — значение, выше которого исходный гипервизор считается перегруженным;
Порог нагрузки целевого гипервизора (LB) — максимальная нагрузка целевого гипервизора после виртуального переноса ВМ;
Период запуска (LB), с — период запуска LB-логики для хост-агрегата.

LB использует синтетическую оценку нагрузки. Она рассчитывается как взвешенная сумма CPU, RAM и сетевой нагрузки. Сумма lb_cpu_weight, lb_ram_weight и lb_network_weight не должна превышать 1.0.

Если нужно учитывать только один тип нагрузки, задайте для него вес 1 и оставьте остальные веса равными 0. Если нужно учитывать несколько типов нагрузки, распределите веса между ними так, чтобы сумма не превышала 1.0.

Гипервизор считается перегруженным, если его syn_score выше lb_threshold_overload. Целевой гипервизор должен оставаться ниже lb_threshold_limit после виртуального переноса ВМ.

Для промышленного контура задавайте lb_threshold_limit равным lb_threshold_overload или ниже него. Это снижает риск перенести ВМ на гипервизор, который после миграции сам станет перегруженным.

Период запуска LB задается отдельно от общего периода запуска KeyVRM. Не задавайте период LB меньше 120 секунд. Значение по умолчанию — 300 секунд.

Настройка KeyVRM через Портал администратора¶

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

настройку глобальной конфигурации сервиса;
настройку режимов и параметров для хост-агрегатов.

Глобальная конфигурация определяет общие параметры работы KeyVRM. Конфигурация хост-агрегата определяет, как KeyVRM должен обрабатывать конкретный хост-агрегат: выполнять HA-логику, LB-логику, обе логики последовательно или не выполнять автоматические действия в режиме NOOP.

Настройка глобальной конфигурации¶

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

Откройте Портал администратора.
Перейдите в раздел KeyVRM.
Нажмите кнопку Глобальная конфигурация.
На вкладке Общие настройки проверьте состояние KeyVRM и период запуска.
При необходимости измените список Nova-like фильтров, которые KeyVRM учитывает при выборе целевых гипервизоров.
На вкладке Настройки HA (High Availability) проверьте параметры эвакуации, фенсинга и интерфейсы для проверки отказа.
На вкладке Настройки LB (Load Balancer) проверьте metadata-ключ, который запрещает миграцию ВМ.
На вкладке Настройки Executor проверьте параметры повторных попыток, повторяющихся ошибок и тайм-аут ручной рекомендации.
Нажмите кнопку Сохранить.

После сохранения вернитесь на страницу KeyVRM и проверьте статус сервиса. Если сервис неактивен или на странице отображаются проблемные агрегаты, перейдите к разделу Диагностика.

Настройка хост-агрегата¶

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

Откройте Портал администратора.
Перейдите в раздел KeyVRM.
В списке хост-агрегатов выберите агрегат, который нужно настроить.
Откройте конфигурацию хост-агрегата.
На вкладке Общие настройки выберите режим обработки в поле Маркер:
- HA — для автоматической эвакуации ВМ;
- LB — для балансировки нагрузки;
- HA+LB — для последовательного выполнения HA- и LB-логики.
Если для агрегата нужно выполнять HA, на вкладке Настройки HA (High Availability) задайте резервы CPU и RAM.
Если для агрегата нужно выполнять LB, на вкладке Настройки LB (Load Balancer) задайте веса CPU, RAM и сетевой нагрузки, пороги нагрузки, режим автоматического запуска рекомендаций и период запуска LB.
Проверьте, что параметры выбранного режима заполнены.
Если для агрегата нужно запустить автоматическую обработку, выключите Режим NOOP на вкладке Общие настройки.
Если для агрегата не нужно выполнять автоматические действия, оставьте Режим NOOP включенным и укажите причину в поле Причина NOOP.
Нажмите кнопку Сохранить.

Выключайте Режим NOOP только после проверки параметров хост-агрегата. Это снижает риск автоматических действий KeyVRM до завершения настройки.

Проверка после настройки¶

После настройки проверьте страницу KeyVRM:

статус сервиса — Активен;
нужный хост-агрегат отображается в списке;
для хост-агрегата задан режим обработки;
агрегат не находится в NOOP, если для него должны выполняться автоматические действия;
количество проблемных агрегатов не увеличилось.

Если после настройки KeyVRM не создаёт события или рекомендации, перейдите к разделу Диагностика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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