Перейти к содержанию

Связность и ограждение

Общая информация

Настройки связности и ограждения — определение механизмов контроля доступности сервера и управления его питанием.

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

В окне Серверы<Имя сервера>Связность и ограждение можно получить информацию о текущих настройках:

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

Дополнительно рекомендуется изменять настройки кластера во вкладке Кластеры – <Имя кластера> – Связность и ограждение.


Ограждение

Ограждение — это процесс получения подтверждения того, что аварийный сервер перешел в состояние, не допускающее повреждения ВМ (по умолчанию - выключен).

Тип ограждения может принимать несколько значений и, в соответствии с этим определяется, каким образом система управления будет пытаться оградить сервер при обнаружении аварии. Сервис ограждения циклически пытается оградить узлы, находящиеся в статусе HERMIT (Ограждается), в соответствии с настройками.


Типы ограждений

  • IPMI.

    Использует управляющие команды ВМС для форсированного выключения узла. Контроллер делает попытки подключиться к IPMI узла и послать команду форсированного выключения узла. Контроллер должен иметь доступ к данному интерфейсу: контроллер и IPMI узла должны либо быть в одной сети, либо должна быть настроена маршрутизация между данными сетями.

    При данном типе ограждение узла будет признано успешным только в случае, если IPMI-интерфейс был доступен и подтвердил, что сервер действительно выключен.

    Таким образом, контроллер не признает огражденным узел, если у узла было выключено питание.

    Примечание

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

    Внимание

    При определении типа ограждения IPMI следует учитывать, что невозможно выбрать данный вариант в случае использования кластерного транспорта GFS2.

  • VIRTUAL.

    Признает сервер выключенным через 30 секунд после наступления аварии (по умолчанию).

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

    Внимание

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

  • SSH.

    Использует подключение SSH для передачи команды выключения.

    Контроллер делает попытки подключиться к узлу и выполнить команду форсированного выключения узла.

    Предупреждение

    Данный тип ограждения не сработает в случае, если была потеряна сетевая связность в управляющей сети (KERNEL).
    Рекомендуется использовать данный тип ограждения при использовании высокой доступности ВМ для того, чтобы защититься от сбоев или отказов программных модулей SpaceVM.

  • NODE.

    Использует вызов управляющих команд через систему управления кластером.

    В момент настройки данного типа ограждения контроллер передает на узел флаг самоограждения. В случае, когда узел теряет связь с контроллером, он пытается выполнить следующие действия:
    - Выключение контейнера сетевых служб.
    - Корректное выключение всех ВМ максимум за 40 секунд.
    - Отмонтирование всех LUN GFS2.
    - Выключение узла.

    Данный тип ограждения позволяет защититься при использовании высокой доступности ВМ от выключения питания серверов. Но при этом контроллер также не может гарантировать, что узел огражден.

  • AUTO.

    Использует варианты последовательно: IPMI, SSH, NODE.

    Данный тип ограждения позволяет защититься при использовании высокой доступности ВМ от выключения питания серверов (NODE), от отказа или сбоя программных модулей (SSH, IPMI), от потери сетевой связности (IPMI).


Настройки ограждения

В окне НастройкиКонтроллер - Информация можно отредактировать некоторые параметры ограждения:

  • Начальный таймаут между попытками ограждения узлов.

    По умолчанию: 15 секунд.

  • Максимальный таймаут между попытками ограждения узлов.

    По умолчанию: 600 секунд.

  • Перевод узла в статус Failed при достижении максимального таймаута.

    По умолчанию: выкл.

  • Множитель увеличения таймаута между попытками.

    По умолчанию: 2.

    Пример ограждения
    - Конфигурация:
    Тип ограждения узла: IPMI.
    Начальный таймаут между попытками ограждения узлов: 15 секунд.
    Максимальный таймаут между попытками ограждения узлов: 600 секунд.
    Перевод узла в статус Failed при достижении максимального таймаута: выкл.
    Множитель увеличения таймаута между попытками: 2.

    - Порядок действий:
    1. Сразу после перехода узла в статус HERMIT (Ограждается) производится первая попытка ограждения узла с контроллера.
    2. В случае удачного выключения узла он переходит в статус FAILED (Ошибка).
    3. Если первая попытка не удалась, то через 15 секунд (начальный таймаут между попытками ограждения узлов) попытка повторяется.
    4. Если вторая попытка не удалась, то через 30 секунд (15 * 2) (2 - множитель увеличения таймаута между попытками) попытка повторяется.
    5. Если третья попытка не удалась, то через 60 секунд (30 * 2) (2 - множитель увеличения таймаута между попытками) попытка повторяется.
    ...

    Тайм-аут будет увеличиваться до 600 секунд (максимальный таймаут между попытками ограждения узлов) и продолжаться до бесконечности, пока Администратор либо не оградит узел вручную, либо ограждение закончится успешно.


Связность

Тип связности узла отвечает за метод принятия решения о том, что на сервере произошла авария.


Типы связностей

  • KERNEL.

    Контролирует исполнение модулей системы управления на сервере.

    Контроллер открывает поток данных (grpc stream) до каждого узла по его UUID (hostname) и отправляет узлу свой IPv4-адрес. Узел при открытом потоке данных сравнивает присланный ему адрес контроллера с адресом из его конфигурации и при совпадении раз в 1 секунду посылает через поток данных heartbeat. Контроллер при каждом получении heartbeat обновляет 2 метки с временем жизни 30 секунд (error label) и 60 секунд (hermit label) о доступности узла.

    Если контроллер признал узел недоступным, то начинается процедура ограждения.

  • KERNEL_STORAGE.

    Дополнительно к проверкам KERNEL раз в 5 секунд проверяются метаданные пула данных сервера на общем с контроллером файловом сетевом хранилище.

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

    Происходит проверка и KERNEL, и STORAGE. Если одна из проверок не пройдена, контроллер начинает процедуру ограждения.

    Внимание

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

  • AUTO.

    Выполняет все доступные проверки связности по порядку.


Оптимальный выбор типов связности и ограждения

Оптимальным считается использование типов:

  • Ограждение: IPMI.

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

  • Связность: AUTO.


Статусы узла

  • CREATING (Создается).

    Узел находится в процессе установки.

  • ACTIVE (Исправно).

    Узел исправен и работает.

  • FAILED (Ошибка).

    Узел был недоступен и его оградили (fence), виртуальные машины могут быть перезапущены на других узлах.

  • ERROR (Ошибка).

    Узел недоступен.

  • HERMIT (Ограждается).

    Узел недоступен продолжительное время и его необходимо оградить для перезапуска виртуальных машин на других узлах.

  • DELETING (Удаляется).

    Узел находится в процессе удаления из кластера.

  • SERVICE (Сервисный режим).

    Узел находится на техобслуживании.

Условия перехода между статусами узла:

  • При установке узел сначала находится в статусе CREATING (Создается).

  • После успешного добавления узел переходит в статус ACTIVE (Исправно).

  • В случае неуспешного добавления узел переходит в статус FAILED (Ошибка).

    В этом случае рекомендуется посмотреть в журнале задач ошибку задачи добавления, разобраться с ошибкой, форсированно удалить узел и добавить его снова.

  • При потере связи контроллера с узлом последний переходит из статуса ACTIVE (Исправно) сначала в статус ERROR (Ошибка), а затем по истечению дополнительного времени и отсутствии связи в статус FAILED (Ошибка), если узел на контроллере, или в статус HERMIT (Ограждается) для всех остальных узлов.

    При переходе узла в статус ERROR (Ошибка) контроллер пытается подключиться по SSH к узлу и перезапустить супервизор контроллера.

  • Контроллер постоянно циклически пытается опросить все известные ему узлы. Если узел НЕ ACTIVE и НЕ SERVICE и связь с ним появляется, то он переходит в статус ACTIVE (Исправно).

  • Администратору для перевода узла на техобслуживание необходимо перевести узел в статус SERVICE (Сервисный режим). При этом все принадлежащие узлам сущности и связи узла переходят в статус FAILED (Ошибка). ВМ узла перед переводом узла в статус SERVICE (Сервисный режим) должны быть выключены.

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

  • После неуспешного удаления переходит в статус FAILED (Ошибка). В этом случае рекомендуется посмотреть в журнале задач ошибку задачи удаления, разобраться с ошибкой и форсированно удалить узел. В случае, если узел не находится в статусе ACTIVE (Исправно), его можно удалить форсированно, то есть исключительно из базы системы управления.

Часто задаваемые вопросы по связности и ограждению.