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

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

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

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

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

• тип ограждения;

• тип связности;

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

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

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

Связность

Тип связности узла отвечает за метод принятия решения о том, что на сервере произошла авария.
Может быть следующих типов:

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

• KERNEL_IPMI – дополнительно раз в 5 секунд проверяется доступность IPMI-интерфейса сервера с контроллера. Происходит проверка и KERNEL, и IPMI. Если что-то недоступно, то контроллер начинает процедуру ограждения.

• KERNEL_STORAGE – дополнительно раз в 5 секунд проверяется метаданные пула данных сервера на общем с контроллером файловом сетевом хранилище. Происходит проверка и KERNEL, и STORAGE. Если что-то недоступно, то контроллер начинает процедуру ограждения.

Хранилище можно выбрать только в настройках сервера, но не кластера. Если выбрать данный тип связности, то может возникнуть ошибка, при которой узел отмечается как "недоступен".

• AUTO – кроме проверки KERNEL связи при наличии настроек IPMI проверяется его доступность. При наличии общего пула данных проверяется и последний.

В данный момент проверка пула данных недоступна.

Ограждение

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

Тип ограждения узла может быть следующим:

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

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

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

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

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

• NODE: использует вызов управляющих команд через систему управления кластером. В момент настройки данного типа ограждения контроллер передает на узел "флаг" самоограждения. В случае, когда узел теряет связь с контроллером, он пытается выполнить следующие действия:

  * выключение контейнера сетевых служб;
  * корректное выключение всех ВМ максимум за 40 с;
  * отмонтирование всех LUN gfs2;
  * выключение хоста.
  

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

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

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

В окне Настройки – Контроллер в Настройках ограждения есть редактируемые поля:

• начальный тайм-аут между попытками ограждения узлов (по умолчанию - 15 секунд);

• максимальный тайм-аут между попытками ограждения узлов (по умолчанию - 600 секунд);

• множитель увеличения тайм-аута между попытками (по умолчанию - 2).

• перевод узла в статус Failed при достижении максимального тайм-аута (по умолчанию - выкл).

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

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

Статусы узла и переходы между ними

Статусы узла:

• CREATING (Создается) - узел находится в процессе инсталляции;

• ACTIVE (Исправно) - узел активен и работает;

• FAILED (Ошибка) - узел был недоступен и его оградили (fence), виртуальные машины могут быть перезапущены на других узлах;

• ERROR (Ошибка) - узел недоступен;

• HERMIT (Ограждается) - узел недоступен продолжительное время и его необходимо оградить для перезапуска виртуальных машин на других узлах;

• DELETING (Удаляется) - узел находится в процессе удаления из кластера;

• SERVICE (Сервисный режим) - узел находится на техобслуживании.

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

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

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

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

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

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