Virtual machine high availability (VMHA)

KeyStack VMHA (virtual machine high availability, отказоустойчивость ВМ или буквально высокая доступность ВМ) — сервис, который обеспечивает непрерывную работу виртуальных машин (ВМ) в облаке KeyStack. Основа механизма VMHA — процесс эвакуации рабочих ВМ из отказавших хостов на рабочие.

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

Описание архитектуры

Компонент High Availability реализован на базе программного продукта Consul HashiCorp (распространяемого по лицензии MPL 2.0). За работу VMHA отвечает модуль consul и выполняемый модуль auto_evacuator в его составе.

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

  • На узлах-контроллерах устанавливаются серверные агенты “consul server-agent”, и они образуют RAFT-кластер.

  • На вычислительных узлах устанавливаются клиентские агенты “consul client-agent”, и они образуют SERF-кластер.

Один из серверных агентов на узлах-контроллерах выступает в роли лидера управляющего кластера, и он лидирует в момент эвакуации виртуальных машин с проблемного вычислительного узла. Общение между серверными и клиентскими агентами осуществляется по принципу “все со всеми” раз в десять секунд с использованием группы протоколов Gossip по портам TCP/UDP 8302.

architecture

Архитектура компонента VMHA

Описание процесса автоматической эвакуации виртуальных машин

Компонент VMHA отслеживает работоспособность агентов и обнаруживает такие отказы инфраструктуры, как:

  • аварийная перезагрузка или отключение гипервизора по питанию;

  • аварийная остановка ОС (kernel panic) на гипервизоре;

  • потеря сетевой связности (не обязательно прямой) гипервизора с узлами-контроллерами.

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

Критерием отказа с точки зрения VMHA является одновременное совпадение следующих факторов:

  • Потеря кластером consul-агента на вычислительном узле (Compute-узле);

  • Сервис nova-compute находится в статусе “status: enabled”;

  • Сервис nova-compute находится в состоянии “state: down”;

  • Отказ или отключение указанных на этапе конфигурации критических для нагрузки сетевых интерфейсов (см. раздел “Мониторинг состояния бондов (bonds)”).

Note

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

В случае отказа:

VMHA проверяет состояние сервисов на вычислительных узлах с заданным интервалом. Интервал определяется параметром consul_interval в секундах. При совпадении трех критериев, перечисленных выше, consul детектирует отказ узла.

В зависимости от значения параметра “fencing” возможны следующие варианты:

  • ceph: true/false — занесение в черный список отказавшего узла из кластера CEPH;

  • nova: true/false — исключение отказавшего узла из кластера Nova (nova service disable);

  • bmc: true/false — выключение узла через IPMI/Redfish.

Note

Если Ceph выключен, то пункт выше, касающийся Ceph, можно игнорировать.

В случае успешного выполнения этапа фенсинга VMHA присваивает вычислительному узлу статус “FENCED”.

Следующим этапом происходит эвакуация ВМ. В случае успешной эвакуации всех ВМ узел получает статус “Maintenance mode”.

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

Уведомления

VMHA автоматически отправляет уведомления в мониторинговые системы Prometheus (prometheus alert manager) при возникновении проблем с изоляцией узла из любых вышеперечисленных сервисов, а также при начале эвакуации и при окончании эвакуации. Это позволяет мониторить состояние системы и оперативно реагировать на инциденты.

Настройка и конфигурирование

Работа с параметрами вычислительных ресурсов облака

Администраторы могут настроить запрет на эвакуацию или порядок эвакуации ВМ для оптимизации работы кластера путем выставления приоритетов в виде метаданных:

  • evacuate_order for vm;

  • no_evacuate for vm;

  • no_evacuate for project.

Управление параметрами возможно:

  • через AdminUI;

  • через Horizon;

  • через OpenStack CLI.

Пример команды для OpenStack CLI:

openstack server set --property "evacuate_order=1" <vm_name_or_id>
openstack server set --property "no_evacuate=true"  <vm_name_or_id>
openstack project set --property "no_evacuate=true" <project_name_or_id>

Администратор может назначить статус “Maintenance mode” вычислительным узлам:

  • через AdminUI;

  • через OpenStack CLI.

В случае выхода вычислительного узла из строя и, например, отправки его в ремонт, администратору необходимо установить для этого узла причину отключения disabled_reason, отличную от FENCED:, чтобы узел не попадал под определение “Dead compute”. Администратор платформы может сделать это через интерфейс командной строки. Пример команды – openstack compute service set --disable --disable-reason “some reason” host_name nova-compute. Также администратор может отключить изоляцию вычислительного узла из интерфейса портала администратора, выбрав пункт Disable Fence Mode в меню управления гипервизорами, и затем перевести его в режим обслуживания, выбрав пункт Enable maintenance mode.

Описание параметров конфигурирования VMHA

VMHA ведет статистику состояний для каждой зоны доступности отдельно. В эту статистику входят три главных состояния: alive, dead, maintenance mode.

  • dead_compute_threshold — отвечает за пороговое значение единовременно отказавших вычислительных узлов в зоне доступности, попадающих под определение “Dead compute”.

    Note

    Если количество отказавших вычислительных узлов превышает значение dead_compute_threshold, эвакуация ВМ прекращается, а фенсинг узлов не проходит. Узел считается отказавшим (попадающим под определение “Dead compute”) с момента фиксации отказа и до того момента, как этот статус сменяется на Maintenance mode (ММ). После присвоения статуса MM такие вычислительные узлы перестают учитываться параметром alive_compute_threshold и остаются в статусе MM, чтобы с ними можно было выполнить работы по обслуживанию.

  • alive_compute_threshold — отвечает за пороговое значение исправных вычислительных узлов.

  • consul_shared_storage (true/false) — отвечает за наличие хранилища с общим доступом. Значение по умолчанию — true.

  • consul_fencing_nova (true/false) — отвечает за фенсинг для сервиса Nova. Значение по умолчанию — true.

Note

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

  • consul_fencing_ceph (true/false) — отвечает за фенсинг для сервиса Ceph. Значение по умолчанию — false.

  • consul_fencing_ipmi (true/false) — отвечает за фенсинг для сервиса IPMI. Значение по умолчанию — false.

  • alive_compute_count — регулирует количество активных вычислительных узлов. Значение по умолчанию — 3.

  • dead_compute_count — регулирует количество отказавших вычислительных узлов, подпадающих под определение “Dead compute”. Значение по умолчанию — 3.

  • consul_enable_bond_check (true/false) — отвечает за мониторинг бондов. Значение по умолчанию — false. Подробнее о мониторинге бондов см. ниже.

  • fence_failed_bond — (true/false) — отвечает за фенсинг вычислительных узлов, на которых обнаружены отказавшие бонды, при условии, что для параметра consul_enable_bond_check выставлено значение true. По умолчанию fence_failed_bond имеет значение false, фенсинг не проводится, а вычислительный узел переходит в disable с префиксом. Подробнее о состоянии бондов см. ниже.

  • consul_bond_names — список имен бондов, перечисленных через запятую.

  • consul_prometheus_request_period — регулирует период запроса для Prometheus. Значение по умолчанию — 120 секунд.

  • consul_prometheus_request_step — регулирует период запроса для Prometheus. Значение по умолчанию — 30 секунд.

Описание параметров конфигурирования bmc

  • bmc_power_fence_mode — регулирует режим работы сервера после проведения фенсинга. В зависимости от значения параметра bmc_power_fence_mode VMHA отправляет команду на IPMI. После успешного выполнения команды nova Compute-узел принудительно перезагружается либо отключается по питанию. Возможные опции:

  • hardreboot — при выборе этой опции происходит жесткая перезагрузка сервера.

  • reset — при выборе этой опции происходит перезапуск сервера.

  • poweroff (режим по умолчанию) — при выборе этой опции в процессе фенсинга происходит выключение сервера.

  • consul_interval — регулирует интервал запуска механизма “service-check”. Значение по умолчанию — 30 секунд.

  • bmc_user — имя пользователя для сервиса bmc.

  • bmc_password — пароль для подключения пользователя к сервису bmc. Этот пароль должен быть сохранен в защищенном хранилище секретов (Vault).

  • bmc_type — отвечает за тип bmc:

  • bmc;

  • ipmi.

  • bmc_suffix — суффикс для запросов в bmc.

  • bmc_verify_ssl (true/false) — по умолчанию такой же сертификат ЦА, что и везде. Возможно выключить проверку, выбрав false.

Мониторинг состояния бондов (bonds)

Бонд (bond) — соединение физических интерфейсов. Мониторинг состояния бондов проводится с помощью специальной настройки VMHA. Можно одновременно мониторить несколько бондов.

Если бонд теряет связь с коммутатором (и считается отказавшим), то VMHA отключает вычислительный узел. Новые ВМ не будут созданы и не переедут на такой узел.

Бонд считается отказавшим, если:

  • все физические интерфейсы, подчиненные бонду (slave-интерфейсы) были в неработоспособном состоянии в течение двух минут (настраивается опцией prometheus_request_period);

  • сам бонд был выключен на уровне ОС.

Чтобы включить эту настройку VMHA, настройте параметры в конфигурационном файле региона https://gitlab.domain_name/project_k/deployments/<REGION>/globals.d/REGION.yml следующим образом:

  • consul_enable_bond_check — поставьте опцию true;

  • consul_bond_names — перечислите имена бондов через запятую.

Затем прогоните пайплайн через LCM.

Путь до конфигурационного файла в LCM: https://gitlab.domain_name/project_k/deployments/<REGION>/globals.d/.

Фенсинг вычислительных узлов при обнаружении упавших бондов

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

При обнаружении отказа бонда (параметры отказа бонда см. выше) для соответствующего вычислительного узла будет произведен фенсинг и последующая эвакуация согласно существующей механике.

Типичные ошибки и их решения

Неудачный фенсинг Nova, Ceph или IPMI

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

Процесс эвакуации ВМ будет приостановлен при обнаружении отказа узла кластера при неудачной попытке:

  • исключения отказавшего узла из кластера Nova (nova service disable);

  • исключения отказавшего узла из кластера CEPH (osd blacklist) (применимо только в случае применения фенсинга Ceph);

  • выключения узла через IPMI (power off).

При неудачном выполнении фенсинга VMHA не выполняет эвакуацию ВМ с вычислительного узла.