Отказоустойчивый кластер (кластер высокой доступности, high availability cluster, HA-кластер) — группа серверов, гарантирующая минимальное время простоя виртуальных машин (ВМ). Отказоустойчивые кластеры используют, например, для поддержки серверов баз данных, хранения важной информации, работы бизнес-приложений. В случае, если один из серверов (узлов) кластера потерял связь с другими узлами или подключённым хранилищем, VMmanager запустит процесс аварийного восстановления — релокации ВМ:

  • перенесёт ВМ с отказавшего узла кластера на рабочие;
  • остановит ВМ на отказавшем узле кластера;
  • изолирует отказавший узел кластера.

Процесс релокации проходит автоматически без участия администратора.

Требования к отказоустойчивому кластеру

В текущей реализации VMmanager вы можете создать отказоустойчивый кластер при следующих условиях:

  • тип лицензии — VMmanager-infrastructure;
  • тип виртуализации — KVM;

  • тип хранилища — Ceph или SAN;

    Тестирование работы отказоустойчивого кластера с хранилищем Ceph не проводилось.

  • на узлах кластера установлены ОС AlmaLinux 8, CentOS 7;

  • в кластере не менее трёх и не более 24 узлов;
  • к кластеру подключено ровно одно хранилище;
  • системное время на всех узлах должно быть синхронизировано.

Обратите внимание!

Функциональность HA-кластера с типом настройки сети IP-fabric имеет ряд ограничений. Например, сервер с платформой нельзя перенести на ВМ в таком кластере.

Логика работы

Используемые сервисы

Для управления отказоустойчивым кластером VMmanager использует:

  • ПО Corosync с сетевой технологией Kronosnet;
  • собственный сервис ha-agent;
  • cобственный микросервис hawatch.

Платформа запускает сервис ha-agent на каждом узле кластера. Сервисы ha-agent взаимодействуют между собой с помощью ПО Corosync. Алгоритмы Corosync назначают один из сервисов ha-agent мастером. В дальнейшем платформа взаимодействует только с этим сервисом с помощью hawatch.

Процедура выбора мастера

Выбор мастера происходит в следующих ситуациях:

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

Чтобы выбор прошёл успешно, в нём должно участвовать (N/2 + 1) узлов, где N — общее число узлов кластера. Значение (N/2 + 1) нужно округлить до целого числа в меньшую сторону. Например, в кластере с двумя узлами должны участвовать оба узла, в кластере с 17 узлами — 9. Если исправных узлов в кластере меньше, чем необходимо, процедура выбора не начнётся. Если узлов будет больше, чем необходимо, то в выборе примут участие только те узлы, которые были готовы к процедуре раньше. Алгоритмы Corosync гарантируют, что информация о времени готовности узлов к выбору одинакова для всех участников кластера.

При выборе мастера каждый из узлов-выборщиков с помощью специального алгоритма рассчитывает свой приоритет и сообщает его остальным участникам кластера. Мастером назначается узел с самым большим приоритетом. После назначения мастера кластер начнёт работу в режиме отказоустойчивости.

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

Обычно процедура выбора занимает около 15 секунд.

Статусы узлов кластера

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

  • рабочие:
    • мастер — узел в рабочем состоянии и выбран мастером;
    • участник — узел в рабочем состоянии;
  • нерабочие:
    • изоляция по сети — узел недоступен по сети, но у узла есть доступ к хранилищу;
    • изоляция по хранилищу — у узла нет доступа к хранилищу, но узел доступен по сети;
    • полный отказ — узел недоступен по сети и у него нет доступа к хранилищу;
  • специальные:
    • выход из HA-кластера — узел недоступен по сети, но узлу доступен проверочный IP-адрес;
    • сеть нестабильна — сеть регулярно теряется на срок менее 15 секунд.


Схема работы HA-кластера

Master — узел-мастер

Slave — узлы-участники

Network storage — сетевое хранилище кластера

Management network — сеть управления узлами кластера

Case1 — пример статуса "изоляция по сети"

Case2 — пример статуса "изоляция по хранилищу"

Case3 — пример статуса "полный отказ"

Определение статуса узла

Сервис ha-agent считает узел повреждённым, если узел потерял связь с другими узлами кластера и/или подключённым хранилищем. Проверка связи проводится с помощью алгоритмов Corosync. Дополнительно узлы кластера записывают информацию о своём статусе в файл на сервере хранилища. Обновление статуса происходит один раз в три секунды. Если информация о статусе не обновлена, мастер определит узел как повреждённый.

Среднее время определения нерабочего статуса — от 15 до 60 секунд.

В настройках отказоустойчивости можно указать проверочный IP-адрес. При потере связи с кластером узел проверит доступность этого IP-адреса с помощью утилиты ping:

  • если IP-адрес недоступен, узел будет изолирован и запустится процесс релокации ВМ;
  • если IP-адрес доступен, узел будет исключён из отказоустойчивого кластера. ВМ на этом узле продолжат работу.

Если узел регулярно теряет связь по сети на срок менее 15 секунд, он получает статус "сеть нестабильна". Процедура релокации в этом случае не проводится.

Процедура аварийного восстановления

Когда узел кластера определяется как отказавший, сервис ha-agent на узле:

  1. Останавливает все ВМ. Если ВМ не удалось остановить, перезагружает узел.
  2. Изолирует узел.
  3. Передаёт информацию о статусе узла мастеру.

Когда мастер получает информацию об отказе узла или самостоятельно определяет узел как отказавший, запускается процедура релокации ВМ. Порядок релокации ВМ зависит от значений приоритетов запуска — чем выше у ВМ значение приоритета, тем раньше она будет перенесена. Процедура релокации запускается только для тех ВМ, которые были выбраны в настройках отказоустойчивости.

После перезагрузки узла его ВМ запустятся, только если узел имеет один из рабочих статусов — "мастер" или "участник" . Запущены будут только ВМ, которые принадлежат этому узлу согласно метаданным кластера. Такой подход позволяет избежать случаев "split brain", когда к одному диску подключаются одновременно две ВМ.

Создание отказоустойчивого кластера

Чтобы создать отказоустойчивый кластер:

  1. Настройте сетевое хранилище.

    1. Настройте узлы хранилища Ceph. Подробнее см. в статье Предварительная настройка Ceph.
    2. Настройте в хранилище файловую систему CephFS. Пример настройки:

      1. Создайте сервер метаданных (MDS) на узле Ceph:

        ceph-deploy --overwrite-conf mds create <node>
        CODE

        <node> — имя узла Ceph

      2. Создайте пулы CephFS для данных и метаданных:

        ceph osd pool create cephfs_data 64 64
        CODE 
        ceph osd pool create cephfs_metadata 64 64
        CODE

      3. Создайте файловую систему CephFS:

        ceph fs new <cephfs_name> cephfs_metadata cephfs_data
        CODE

        cephfs_name — имя файловой системы

    Выполните предварительную настройку iSCSI. Подробнее см. в статье Предварительная настройка SAN.

  2. Подключите хранилище к кластеру. Подробнее см. в статье Управление хранилищами кластера.
  3. Задайте настройки отказоустойчивости. Подробнее см. в статье Настройка отказоустойчивости.

Диагностика

Конфигурационные файлы Сorosync:

  • /etc/corosync/corosync.conf — общие настройки;
  • /etc/corosync/storage.conf — настройки работы с хранилищем.

Лог-файл сервиса ha-agent — /var/log/ha-agent.log.

Лог-файл микросервиса hawatch — /var/log/hawatch.log.

Связанные статьи