Обеспечение высокой доступности (high availability)#
Описание механизма высокой доступности#
Механизм обеспечения высокой доступности (далее – НА) является набором автоматических характеристик, спроектированных для учёта ситуаций (проблем), которые делают серверы недоступными, а также для безопасного восстановления функционирования после таких ситуаций. Например, механизм HA эффективен при физических разрывах передачи данных по сети или неполадок аппаратного обеспечения хоста.
Внимание
Механизм НА должен ВСЕГДА использоваться в системах с многоканальным подключением к хранилищу и агрегацией сетевых интерфейсов.
В первую очередь, механизм НА позволяет запущенным ВМ при нестабильной работе хоста или его недоступности прекратить работу на нём и возобновить ее в другом месте. При этом можно избежать сценария, когда ВМ начинают работу (автоматически или вручную) на новом сервере, а предыдущий их сервер восстанавливает работу, что может привести к запуску экземпляров ВМ на разных серверах с высокой вероятностью порчи и потери данных ВМ.
Механизм НА автоматически восстанавливает административный контроль над пулом в случае, если мастер пула становится недоступным или его работа становится нестабильной.
В некоторых случаях механизм НА может также автоматизировать процесс перезапуска ВМ на исправных серверах. Для удобства последовательного запуска сервисов эти ВМ могут распределяться в группы (это даёт возможность запускать административные ВМ прежде зависящих от них ВМ – например, сервер DHCP раньше, чем зависящий от него сервер SQL).
Предупреждение
Механизм НА спроектирован для работы с многоканальным подключением хранилищ и агрегированными сетевыми интерфейсами, и они должны быть сконфигурированы ПЕРЕД активацией НА. Если этого не было сделано, то вследствие нестабильности сетевого оборудования может возникнуть непредвиденное поведение хоста при перезагрузке (так называемое самоизолирование, selffensing)
Переполнение пула#
Пул считается переполненным (overcommitted), если работающие ВМ не могут перезапуститься на одном из прочих серверов пула вследствие достижения в пуле критического количества отказов хостов. Данный показатель задаётся администратором. Переполнение происходит, если не хватает свободной оперативной памяти в пуле для запуска ВМ, испытывающих отказ. Могут существовать другие малозаметные изменения, ухудшающие работу НА: изменения в виртуальных блочных устройствах (VBD) и сетях могут повлиять на выбор хоста, на котором будет перезапущена ВМ. В настоящий момент Numa vServer не может контролировать все действия, которые ведут к нарушению требований работы НА. При нарушении работы НА высылается асинхронное уведомление.
Numa vServer в реальном времени разрабатывает и осуществляет план обеспечения отказоустойчивости серверов в пуле (failover plan), определяющий действия в случае отказа некоторого количества серверов пула за некоторое заданное время. Важным для понимания является параметр максимального некритического количества отказов хостов (host failures to tolerate). Например, если пул ресурсов состоит из 6 серверов и некритическое количество отказов равняется 3, то пул рассчитывает план обеспечения отказоустойчивости, который позволяет при отказе любых трёх серверов продолжить работу ВМ на других серверах. Если отказывает большее количество, пул считается переполненным. План динамически пересчитывается с учётом анализа операций рабочего цикла и миграций ВМ. Если в процессе изменений (например, добавления новых ВМ в пул) появляется опасность переполнения пула, то система может выслать предупреждение (например, по электронной почте).
Предупреждение о переполнении#
Если при старте или продолжении работы ВМ пул переполняется (overcommitted), система предупреждает об этом. Это предупреждение отображается при отсутствии доступного графического интерфейса в терминал API. Если заданы соответствующие настройки, сообщение может быть отправлено администратору по электронной почте. Затем будет предложено закончить операцию или продолжить ее. Продолжение операции приведет к переполнению пула. Количество информации, используемой ВМ с различными приоритетами, будет отображено в пуле и на хостах.
Изоляция сервера#
В случае если происходит отказ сервера, теряется структура коммутации сети или возникает проблема с управляющим стеком, сервер самоизолируется (самоогораживается) для того, чтобы исключить запуск одних ВМ на двух серверах одновременно. После запуска изоляции сервер немедленно перезагружается, а работа всех ВМ прекращается. Остальные серверы регистрируют остановку ВМ и далее ВМ перезагружаются в соответствии с определенными для них приоритетами. Изолированный сервер начинает процесс перезагрузки и после перезапуска пытается войти заново в пул ресурсов.
Требования к конфигурации механизма HA#
Чтобы использовать функцию высокой доступности, необходимо:
- пул из серверов (обеспечивает высокую доступность на уровне сервера в рамках одного пула ресурсов);
Примечание
Рекомендуется использовать механизм НА только в пулах, состоящих из не менее чем трех серверов.
- статические IP-адреса для всех серверов;
Примечание
Если IP-адрес сервера изменяется, когда включена высокая доступность, механизм высокой доступности предположит, что сеть хоста вышла из строя. Изменение IP-адреса может заблокировать хост и оставить его в не загружаемом состоянии. Чтобы исправить эту ситуацию, отключите механизм высокой доступности с помощью команды: xe host-emergency-ha-disable, сбросьте мастера пула с помощью команды: xe pool-emergency-reset-master, а затем снова включите высокую доступность.
- общее хранилище, доступное по протоколам iSCSI, NFS, SMB или Fibre Channel, для создания служебного томов (heartbeat SR) объемом 365 Mб или более.
Механизм высокой доступности создаёт два тома на heartbeat SR:
- том объёмом 4 Мбайт на heartbeat;
- том объёмом 256 Мбайт для хранения метаданных мастера пула, которые будут использованы в случае отказа мастера.
Примечание
Для большей надежности настоятельно рекомендуется для heartbeat SR использовать общие хранилища данных на основе протоколов NFS или iSCSI, которые не используются в других целях.
Примечание
Хранилище, подключенное с использованием протоколов SMB или iSCSI, при проверке подлинности с использованием CHAP не может использоваться в качестве heartbeat SR.
Примечание
В случае использования хранилищ на основе NetApp или EqualLogic необходимо вручную задать адрес дискового устройства (LUN) NFS или iSCSI в массиве данных для использования в качестве хранилища под heartbeat SR.
- для максимальной надежности рекомендуется использовать выделенный сетевой интерфейс для сети управления высокой доступностью.
Чтобы виртуальная машина была защищена механизмом высокой доступности, она должна быть мобильной. Это означает, что:
- виртуальные диски ВМ должны быть в общем хранилище. Можно использовать любой тип общего хранилища. Только для диска на основе iSCSI, NFS или Fibre Chanel, который предполагается использовать для heartbeat SR, требуется номер логического устройства (Logical Unit Number, LUN). Опционально эти диски также могут быть использованы в качестве обычных виртуальных дисков;
- ВМ могут использовать живую миграцию;
- у ВМ отсутствует соединение с физическими DVD-приводом и USB устройствами;
- у ВМ есть собственные виртуальные сетевые интерфейсы в сети пула.
Примечание
При включенном механизме НА настоятельно рекомендуется агрегировать интерфейс управления на серверах пула, а также использовать многопоточные (multipath) хранилища в основе heartbeat SR.
При создании 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.
Если в пуле возникают сбои сервера и число допустимых сбоев падает до нуля, защищенным виртуальным машинам не гарантируется запуск. В таких случаях генерируется системное предупреждение. Если происходит другой сбой, все виртуальные машины, для которых установлен приоритет protected, ведут себя в соответствии с приоритетом best-effort.
Порядок запуска#
Порядок запуска - это порядок, в котором серверы с включенной высокой доступностью будут пытаться перезапустить защищенные виртуальные машины при возникновении сбоя. В значения свойства order для каждой защищенной виртуальной машины определяют порядок запуска.
Свойство order ВМ используется сервисами высокой доступностью, а также другими функциями, которые запускают и завершают работу ВМ. Любая ВМ может иметь набор свойств order, а не только защищенные ВМ. Однако сервисы высокой доступности используют свойство order только для защищенных виртуальных машин.
Значение свойства order является целым числом. Значение по умолчанию равно 0, что является наивысшим приоритетом. Защищенные ВМ со значением order 0 перезапускаются первыми. Чем выше значение свойства order, тем позже в последовательности перезапускается виртуальная машина.
Значение свойства order виртуальной машины можно задать с помощью интерфейса командной строки:
Активация механизма высокой доступности в пуле#
Механизм НА может быть активирован в пуле при помощи интерфейса командной строки. Там же необходимо установить для различных ВМ уровни приоритета перезапуска при переполнении (overcommitting) пула.
Примечание
При активации НА некоторые операции, которые могут негативно сказаться на плане перезапуска ВМ, например, извлечение сервера из пула, могут бездействовать.
Для включения механизма HA для выбранного пула следует выполнить следующую последовательность действий:
- проверить, что к пулу присоединено совместимое хранилище данных. Совместимыми являются хранилища на основе протоколов iSCSI, NFS или Fibre Channel (подробнее см.6.16 Создание и настройка хранилищ данных);
-
для каждой виртуальной машины, которую необходимо защитить, установить приоритет перезапуска и порядок запуска, выполнив команду:
-
включить механизм HA в пуле и при необходимости указать время ожидания:
timeout - это период, в течение которого сеть или хранилище недоступны узлам в пуле. Если не указать timeout при включении высокой доступности, то timeout по умолчанию будет 30 секунд. Если какой-либо сервер не может получить доступ к сети или хранилищу в течение времени ожидания, он самостоятельно перезапустится.
- запустить команду
pool-ha-compute-max-host-failures-to-tolerate. Эта команда вернет максимальное количество отказов хоста, допустимое с точки зрения механизма HA:
Допустимое (некритическое) количество отказов определяется моментом отправки тревоги: система пересчитывает план отказоустойчивости в зависимости от изменения состояния пула и таким образом система определяет объём памяти пула для определения количества некритических отказов для надежной работы защищенных ВМ. Система сигнализирует о тревоге, если расчетный уровень падает ниже заданного для ha-host-failures-to-tolerate.
- задать значение параметра допустимого количества отказов в пуле. Оно должен быть не более рассчитанного на предыдущем шаге значения:
Вывод ВМ из механизма высокой доступности#
Чтобы вывести ВМ из механизма высокой доступности, необходимо использовать команду:
При необходимости можно снова включить высокую доступность для виртуальной машины, установив для параметра ha-restart-priority значение restart или best-effort.
Восстановление недоступного сервера#
Если по какой-то причине сервер не может получить доступ к файлу состояния высокой доступности, то возможно он стал недоступен. Для того чтобы восстановить установки необходимо деактивировать высокую доступность следующей командой:
Если сервер был мастером пула, он должен возобновить обычную работу с деактивированной высокой доступностью. Подчиненные серверы соединяются заново и автоматически деактивируют высокую доступность. Если сервер был подчиненным участником пула и не может соединиться с мастером, необходимо принудительно перезагрузить сервер как мастер пула и/или направить к новому мастеру:
После успешного перезапуска всех серверов следует активировать высокую доступность снова:
Выключение сервера при активированном механизме высокой доступности#
Если происходит завершение работы или перезагрузка хоста, то работающий сервис высокой доступности может решить, что произошел сбой сервера. Для корректного завершения работы сервера, с включенной высокой доступностью, сначала деактивируйте сервер, затем извлеките его и завершите его работу. Для завершения работы сервера следует выполнить следующую последовательность команд:
Выключение ВМ с приоритетом protected#
ВМ не может завершить работу при активированной высокой доступности. Для завершения работы ВМ сначала следует деактивировать высокую доступность, а затем выключить ВМ.
Примечание
Если завершить работу ВМ из гостевой системы, то ВМ автоматически перезапустится. Для завершения работы следует сначала деактивировать высокую доступность в параметрах ВМ.