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. .. figure:: Media/architecture.jpg :alt: architecture :figclass: bg-warning :target: ../_images/architecture.jpg Архитектура компонента 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" openstack server set --property "no_evacuate=true" openstack project set --property "no_evacuate=true" Администратор может назначить статус "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//globals.d/REGION.yml`` следующим образом: - ``consul_enable_bond_check`` — поставьте опцию ``true``; - ``consul_bond_names`` — перечислите имена бондов через запятую. Затем прогоните пайплайн через LCM. Путь до конфигурационного файла в LCM: ``https://gitlab.domain_name/project_k/deployments//globals.d/``. **Фенсинг вычислительных узлов при обнаружении упавших бондов** Вы можете включить фенсинг вычислительных узлов, если на них обнаружены отказавшие бонды. Для этого поставьте опцию ``true`` для параметра ``fence_failed_bond``. При обнаружении отказа бонда (параметры отказа бонда см. выше) для соответствующего вычислительного узла будет произведен фенсинг и последующая эвакуация согласно существующей механике. Типичные ошибки и их решения ----------------------------- Неудачный фенсинг Nova, Ceph или IPMI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ В случае невозможности изоляции вычислительного узла эвакуация не происходит. Попытки изоляции циклически продолжаются раз в 30 секунд до момента успешной изоляции вычислительного узла. Такие попытки будут выполняться бесконечно. Попытки изоляции прекращаются, если связь с вычислительным узлом восстанавливается между попытками изоляции. Процесс эвакуации ВМ будет приостановлен при обнаружении отказа узла кластера при неудачной попытке: - исключения отказавшего узла из кластера Nova (nova service disable); - исключения отказавшего узла из кластера CEPH (osd blacklist) (применимо только в случае применения фенсинга Ceph); - выключения узла через IPMI (power off). При неудачном выполнении фенсинга VMHA не выполняет эвакуацию ВМ с вычислительного узла.