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

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

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

Раздел Cвязность и ограждения позволяет назначить индивидуальные настройки связности и ограждения узла.

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

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

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

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

• Тип ограждения.

• Тип связности.

• Пулы данных.

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

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

Ограждение

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

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

Тип ограждения по умолчанию: VIRTUAL.

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

• 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.

Связность

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

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

• 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.

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

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

При использовании кластерного транспорта GFS2 оптимальным считается использование типов:

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

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

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

• Ограждение: 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 (Исправно), его можно удалить форсированно, то есть исключительно из базы системы управления.

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