Обеспечение высокой доступности (high availability)#

Описание механизма высокой доступности#

Механизм обеспечения высокой доступности (далее – Механизм НА) является набором автоматических характеристик, спроектированных для учёта ситуаций (проблем), которые делают серверы недоступными, а также для безопасного восстановления функционирования после таких ситуаций. Например, механизм HA эффективен при физических разрывах передачи данных по сети или неполадок аппаратного обеспечения хоста.

В первую очередь, механизм НА позволяет запущенным ВМ при нестабильной работе хоста или его недоступности прекратить работу на нём и возобновить ее в другом месте. При этом можно избежать сценария, когда ВМ начинают работу (автоматически или вручную) на новом сервере, а предыдущий их сервер восстанавливает работу, что может привести к запуску экземпляров ВМ на разных серверах с высокой вероятностью порчи и потери данных ВМ.

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

В некоторых случаях механизм НА может также автоматизировать процесс перезапуска ВМ на исправных серверах. Для удобства последовательного запуска сервисов эти ВМ могут распределяться в группы (это даёт возможность запускать административные ВМ прежде зависящих от них ВМ, например, сервер DHCP раньше, чем зависящий от него сервер SQL).

Переполнение пула#

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

Переполнение происходит, если не хватает свободной оперативной памяти в пуле для запуска ВМ, испытывающих отказ. Могут существовать другие малозаметные изменения, ухудшающие работу НА: изменения в виртуальных блочных устройствах (VBD) и сетях могут повлиять на выбор хоста, на котором будет перезапущена ВМ. В настоящий момент Numa vServer не может контролировать все действия, которые ведут к нарушению требований работы НА. При нарушении работы НА высылается асинхронное уведомление.

Numa vServer в реальном времени разрабатывает и осуществляет план обеспечения отказоустойчивости серверов в пуле (failover plan), определяющий действия в случае отказа некоторого количества серверов пула за некоторое заданное время. Важным для понимания является параметр максимального некритического количества отказов хостов (host failures to tolerate). Например, если пул ресурсов состоит из 6 серверов и некритическое количество отказов равняется 3, то пул рассчитывает план обеспечения отказоустойчивости, который позволяет при отказе любых трёх серверов продолжить работу ВМ на других серверах. Если отказывает большее количество, пул считается переполненным. План динамически пересчитывается с учётом анализа операций рабочего цикла и миграций ВМ. Если в процессе изменений (например, добавления новых ВМ в пул) появляется опасность переполнения пула, то система может выслать предупреждение (например, по электронной почте).

Предупреждение о переполнении#

Если при старте или продолжении работы ВМ пул переполняется (overcommitted), система предупреждает об этом. Это предупреждение отображается при отсутствии доступного графического интерфейса в терминал API. Если заданы соответствующие настройки, сообщение может быть отправлено администратору по электронной почте. Затем будет предложено закончить операцию или продолжить ее. Продолжение операции приведет к переполнению пула. Количество информации, используемой ВМ с различными приоритетами, будет отображено в пуле и на хостах.

Изоляция сервера#

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

Требования к конфигурации механизма HA#

Для настройки механизма HA необходимо наличие:

• пула из серверов (обеспечивает высокую доступность на уровне сервера в рамках одного пула ресурсов);

• статические IP-адреса для всех серверов;

• общее хранилище, доступное по протоколам iSCSI, NFS, SMB или Fibre Channel, для создания служебных томов (heartbeat SR) объемом 365 Mб или более.

  Механизм высокой доступности создаёт два тома на heartbeat SR:

  • том объёмом 4 Мбайт на heartbeat;
  • том объёмом 256 Мбайт для хранения метаданных мастера пула, которые будут использованы в случае отказа мастера.

  Примечания

  1. Для большей надежности настоятельно рекомендуется для heartbeat SR использовать общие хранилища данных на основе протоколов NFS или iSCSI, которые не используются в других целях.
  2. Хранилище, подключенное с использованием протоколов SMB или iSCSI, при проверке подлинности с использованием CHAP не может использоваться в качестве heartbeat SR.
  3. В случае использования хранилищ на основе NetApp или EqualLogic необходимо вручную задать адрес дискового устройства (LUN) NFS или iSCSI в массиве данных для использования в качестве хранилища под heartbeat SR.

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

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

• виртуальные диски ВМ должны быть в общем хранилище. Можно использовать любой тип общего хранилища. Только для диска на основе iSCSI, NFS или Fibre Chanel, который предполагается использовать для heartbeat SR, требуется номер логического устройства (Logical Unit Number, LUN). Опционально эти диски также могут быть использованы в качестве обычных виртуальных дисков;
• ВМ могут использовать живую миграцию;
• у ВМ отсутствует соединение с физическими DVD-приводом и USB-устройствами;
• у ВМ есть собственные виртуальные сетевые интерфейсы в сети пула.

При создании VLAN и агрегированных интерфейсов они могут оказаться не подключенными. В этой ситуации ВМ не будут под защитой механизма НА. В этом случае нужно использовать команду xe pif-plug для ввода VLAN и PIF-объектов агрегаций сервера в действие, благодаря чему ВМ смогут стать мобильными. Точно определить, почему ВМ не являются мобильными, можно, используя команду xe diagnostic-vm-status для анализа существующих ограничений.

Приоритет запуска и перезапуска ВМ#

Виртуальные машины могут иметь приоритеты запуска protected (защищенная), best-effort (лучшая попытка) или unprotected (незащищенная). Приоритет задается через параметр ha-restart-priority в настройках виртуальной машины. Поведение перезапуска для виртуальных машин в каждом приоритете отличается.

Приоритет protected#

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

Если защищенная виртуальная машина не может быть запущена (например, при переполнении пула), сервисы высокой доступности будут пытаться запустить виртуальную машину до тех пор, пока ВМ не запустится на освободившихся или дополнительных ресурсах пула.

Значение: ha-restart-priority: restart

Приоритет best-effort#

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

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

Значение: ha-restart-priority: best-effort

Приоритет unprotected#

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

Значение: ha-restart-priority: пустая строка

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

Порядок запуска#

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

Свойство order ВМ используется сервисами высокой доступностью, а также другими функциями, которые запускают и завершают работу ВМ. Любая ВМ может иметь набор свойств order, а не только защищенные ВМ. Однако сервисы высокой доступности используют свойство order только для защищенных виртуальных машин.

Значение свойства order является целым числом. Значение по умолчанию равно 0, что является наивысшим приоритетом. Защищенные ВМ со значением order=0 перезапускаются первыми. Чем выше значение свойства order, тем позже в последовательности перезапускается виртуальная машина.

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

1

xe vm-param-set uuid=<vm_uuid> order=<число>

Активация механизма высокой доступности в пуле#

Механизм НА может быть активирован в пуле при помощи интерфейса командной строки. Там же необходимо установить для различных ВМ уровни приоритета перезапуска при переполнении (overcommitting) пула.

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

1. Проверьте, что к пулу присоединено совместимое хранилище данных. Совместимыми являются хранилища на основе протоколов iSCSI, NFS или Fibre Channel (подробнее см. Создание и настройка хранилищ данных).

2. Для каждой виртуальной машины, которую необходимо защитить, установите приоритет перезапуска и порядок запуска:

   1	xe vm-param-set uuid=<vm_uuid> ha-restart-priority=restart order=1

3. Включите механизм HA в пуле и при необходимости укажите время ожидания:

   1	xe pool-ha-enable heartbeat-sr-uuids=<sr-uuid> ha-config:timeout=<время-в-секундах>

   Для параметра heartbeat-sr-uuids необходимо указать UUID общего хранилища. Возможно использование нескольких общих хранилищ, для этого введите их UUID через запятую.

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

4. Выполните команду, которая вернет максимальное количество отказов хоста, допустимое с точки зрения механизма HA:

   1	xe pool-ha-compute-max-host-failures-to-tolerate

   Допустимое (некритическое) количество отказов определяется моментом отправки тревоги: система пересчитывает план отказоустойчивости в зависимости от изменения состояния пула и таким образом система определяет объём памяти пула для определения количества некритических отказов для надежной работы защищенных ВМ. Система сигнализирует о тревоге, если расчетный уровень падает ниже заданного для ha-host-failures-to-tolerate.

5. Задайте значение параметра допустимого количества отказов в пуле. Оно должно быть не более рассчитанного на предыдущем шаге значения:

   1	xe pool-param-set ha-host-failures-to-tolerate=<число-серверов> uuid=<pool-uuid>

Вывод ВМ из механизма высокой доступности#

Для вывода ВМ из механизма высокой доступности выполните:

1

xe vm-param-set ha-always-run=false uuid=<vm-uuid>

При необходимости можно снова включить высокую доступность для виртуальной машины, установив для параметра ha-restart-priority значение restart или best-effort.

1

xe vm-param-set uuid=<vm-uuid> ha-restart-priority=<restart|best-effort>

Восстановление недоступного сервера#

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

1

xe host-emergency-ha-disable --force

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

1

xe pool-emergency-transition-to-master uuid=<host-uuid>

1

xe pool-emergency-reset-master master-address=<new-master-hostname-or-ip-address>

После успешного перезапуска всех серверов следует активировать высокую доступность снова:

1

xe pool-ha-enable heartbeat-sr-uuid=<sr_uuid>

Выключение сервера при активированном механизме высокой доступности#

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

1. Деактивируйте сервер:

   1	xe host-disable host=<host_name>

2. Извлеките сервер:

   1	xe host-evacuate uuid=<host_uuid>

3. Завершите его работу.

   1	xe host-shutdown host=<host_name>

Выключение ВМ с приоритетом protected#

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