Глава 37. Обеспечение высокой доступности ВМ

⁠Глава 37. Обеспечение высокой доступности ВМ

37.1. Обработка сбоев узлов
37.2. Настройка чувствительности HA
37.3. Настройка Fencing (изоляции узла)

Цель данного раздела — предоставить информацию о подготовке к сбоям ВМ и узлов, а также об их восстановлении. Сбои делятся на две категории:

сбои физической инфраструктуры — отказы узлов (аппаратные сбои, проблемы с сетью);
сбои виртуальной инфраструктуры — аварийное завершение работы ВМ (крах ОС, зависание приложений).

В обоих случаях OpenNebula предоставляет механизм автоматического переключения (failover), позволяющий минимизировать время простоя сервисов.

⁠37.1. Обработка сбоев узлов

Когда OpenNebula обнаруживает, что узел перешёл в состояние ERROR, может быть автоматически запущен специальный хук для восстановления сервисов.

По умолчанию в поставке OpenNebula доступен скрипт ft/host_error.rb, который позволяет:

мигрировать или перезапускать ВМ на других узлах;
сократить простой сервисов при аппаратных сбоях.

Примечание

Автоматическая обработка состояния ERROR не включена по умолчанию и требует явной настройки хука.

Настройка хука для состояния ERROR:

Создайте хук на основе шаблона /usr/share/one/examples/host_hooks/error_hook:
```
ARGUMENTS       = "$TEMPLATE -m -p 5"
ARGUMENTS_STDIN = "yes"
COMMAND         = "ft/host_error.rb"
NAME            = "host_error"
STATE           = "ERROR"
REMOTE          = "no"
RESOURCE        = HOST
TYPE            = state
```
В приведённом примере:
- используется миграция ВМ (-m);
- переключение не выполняется, если узел восстановится в течение 5 циклов мониторинга (-p 5).

Зарегистрируйте хук:

$ onehook create /usr/share/one/examples/host_hooks/error_hook

⁠

Таблица 37.1. Параметры скрипта ft/host_error.rb

Параметр	Описание
`$TEMPLATE`	Шаблон узла, перешедшего в состояние ERROR. Передаётся в формате XML, закодированном в base64
`-m`	Миграция ВМ на другой узел (доступно только при использовании shared-хранилищ: NFS, Ceph)
`-r`	Удаление и пересоздание ВМ (состояние ВМ теряется)
`-d`	Полное удаление ВМ
`-f`	Принудительный перезапуск ВМ, находящихся в состояниях SUSPEND или POWEROFF
`-p <n>`	Не выполнять переключение, если узел восстановится в течение <n> циклов мониторинга
`--no-fencing`	Отключить изоляцию (fencing) неисправного узла

Примечание

При сетевых сбоях возможна ситуация, когда одна и та же ВМ запускается одновременно на двух узлах. Это может привести к повреждению данных, особенно при использовании shared-хранилищ.

Для безопасной работы HA-механизма необходимо обязательно настроить fencing (изоляцию неисправного узла). Использование HA без fencing считается небезопасным.