Одна из технологий VMware vSphere, к которой активно привлекается внимание пользователей, — vMotion. С помощью vMotion можно динамически переносить активные виртуальные машины между узлами. В процессе динамической миграции виртуальные машины переносятся до отключения хост-компьютера или выполняется балансировка нагрузки, создаваемой виртуальными машинами в группе узлов. Кроме того, можно освободить хост-компьютер от виртуальных машин перед перезагрузкой или техническим обслуживанием.

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

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

Начинайте с DRS

Путь к высокой доступности начинается с создания кластера vSphere. Даже в отсутствие лицензии планировщика распределенных ресурсов (DRS) начинать необходимо с процесса создания кластера.

. На экране 1 показан пример того, что можно увидеть, если щелкнуть на левой панели узла ESX и перейти на вкладку Configuration, а затем пройти по ссылке для показа лицензируемых компонентов. Обратите внимание, что VMware определяет лицензируемые компоненты для VMware HA и VMware DRS для каждого узла в отдельности. Таким образом, в зависимости от особенностей приобретенных лицензий, необходимые функции могут присутствовать лишь на части узлов компании.

 

Экран 1. Лицензированные компоненты для узла ESX

Не всем известно, что HA и DRS лицензируются в различных выпусках vSphere. HA доступна в недорогих (но и не самых дешевых) выпусках vSphere Standard и Essentials Plus. Чтобы получить DRS, необходимо подняться на ступень вверх к выпуску vSphere Enterprise.

Кластер соответствует группе узлов, ресурсы которых, в том числе вычислительные и память, собраны в единый пул. Кластеры формируют границу администрирования ресурсов, объединяя ресурсы нескольких узлов. Они также устанавливают границу для балансирования нагрузки DRS, формируя жесткий рубеж вокруг коллекции узлов, внутри которой vSphere выравнивает нагрузку со стороны виртуальных машин. Этот жесткий рубеж также определяет узлы, которые могут использоваться HA для перемещения виртуальных машин после отказа исходного узла.

Чтобы создать кластер, щелкните правой кнопкой мыши на центре данных в vSphere Client. Выберите New Cluster, и, как показано на экране 2, появится мастер создания кластера. Каждый кластер нуждается в уникальном имени; можно активизировать один из двух компонентов кластера. В данном примере задействован HA (DRS будет рассмотрен в следующей статье).

 

Экран 2. Создание кластера

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

Контроль доступа

На экране 3 показан первый экран настройки с параметрами для контроля доступа к узлу. Первый параметр, Host Monitoring Status, определяет, будут ли узлы ESX обмениваться сигналами подтверждения соединения для мониторинга vCenter Server. С помощью этого сигнала vCenter Server определяет, активен ли узел. Оставьте этот флажок установленным. Как правило, мониторинг узла полезно оставить включенным, так как для механизма HA важно обнаружить момент отказа узлов.

 

Экран 3. Управление доступом

Второй параметр, Admission Control, определяет действие кластера в случае отказа узла, если не хватает ресурсов для восстановления отказавших виртуальных машин на других узлах кластера. В правильно спроектированном кластере всегда достаточно свободных ресурсов, чтобы переместить виртуальные машины любого отказавшего узла на остальные узлы кластера, но часто не хватает оборудования или оказывается слишком много виртуальных машин. Выбор значения параметра Admission Control зависит от доступности и требований к производительности виртуальных машин. Ситуацию проще всего объяснить на «экстремальном» примере. Предположим, что в кластере четыре узла (рисунок 1). На всех четырех узлах функционируют виртуальные машины. Их так много, что каждый узел полностью загружен (стопроцентное использование).

 

Рисунок 1. Пример кластера с одним отказавшим узлом

В случае отказа узла 2 (Host Number 2), как показано на рисунке 1, задача HA — переместить виртуальные машины на каждый из трех оставшихся узлов со свободным пространством. Однако в данном случае остальные три узла кластера уже работают с коэффициентом использования 100%. После добавления виртуальных машин узла Host Number 2 к остальным трем узлам падает производительность всех виртуальных машин — далеко не лучший результат. Последствия выхода из строя единственного узла в плохо спроектированном кластере могут оказаться гораздо более серьезными, чем потеря самого узла. Применяя механизм HA, необходимо предусмотреть избыточные ресурсы, которые не используются, пока какой-нибудь узел не выйдет из строя.

Рассмотрим варианты управления запуском (экран 3). Если отключить управление запуском, виртуальные машины будут запускаться даже в отсутствие достаточных ресурсов. На первый взгляд это всегда вредно, но могут возникать ситуации, когда такое положение оправданно. Например, у компании нет средств на закупку дополнительного оборудования, но виртуальные машины необходимо перезапустить, даже ценой снижения производительности. В этом случае отключение управления запуском приводит к компромиссу между производительностью и доступностью. Большинство ИТ-администраторов старается избежать такой ситуации, поэтому по умолчанию режим управления запуском включен.

Если требуется обеспечить как производительность, так и доступность и есть средства для закупки оборудования, следует включить управление запуском. В этом случае доля ресурсов, отводимых для резерва, определяется кластером. Передача этих функций кластеру освобождает администратора от обязанности постоянно следить за доступными ресурсами и потребностями виртуальных машин. Благодаря передаче функций управления ресурсами системе контроля запуска, можно получать уведомления в ситуациях, когда все ресурсы распределены виртуальным машинам или зачислены в резерв. На экране 4 показаны три политики, имеющиеся в распоряжении администратора.

 

Экран 4. Политика управления доступом

Первая политика — Host failures cluster tolerates. Эта политика дает кластеру указание зарезервировать количество ресурсов, соответствующее указанному числу узлов. Если задать значение 1, как в нашем примере, кластер зарезервирует количество ресурсов в расчете на свой самый мощный узел. В результате кластер всегда обеспечит переключение виртуальных машин в случае отказа узла.

В этом процессе определения ресурсов используется метод расчетов на основе «шаблонов» — логических представлений ресурсов памяти и процессора. Более подробное рассмотрение вычислений на основе шаблонов выходит за рамки данной статьи, зато об этом методе замечательно рассказано в статье Данкана Эппинга (http://www.yellow-bricks.com/vmware-high-availability-deepdiv/).

При определении размера кластера важно учитывать, что при назначении резерва доля избыточности в небольших кластерах оказывается более высокой. Присвоение значения 1 выводит из текущего использования ресурсы целого сервера. На рисунке 2 отражены как сильные, так и слабые стороны такого подхода. Выигрыш заключается в том, что при потере узла Host Number 4 всегда найдется место для перемещения виртуальных машин. А недостаток в том, что кластер из четырех узлов функционирует как трехузловой кластер.

 

Рисунок 2. Зарезервирован­ные ресурсы, соответствующие одному узлу

При увеличении числа узлов в кластере снижается общий процент избыточности. В четырехузловом кластере приходится резервировать 25% ресурсов, но один выделенный узел в 10-узловом кластере составит лишь 10% кластера, а в 20-узловом — только 5%.

Не обязательно выделять в резерв столь полновесную долю — это один из доводов в пользу режима Percentage of cluster resources reserved as failover spare capacity. Вместо того чтобы резервировать ресурсы определенного числа узлов, вторая политика задает процент от общих ресурсов кластеров.

Вернемся к приведенному выше примеру. Для защиты каждой виртуальной машины в четырехузловом кластере следует выделить 25% ресурсов. Но не всегда обязательно защищать каждую виртуальную машину, поскольку не все виртуальные машины критически важны. В случае отказа узла менее ценные виртуальные машины могут бездействовать, пока неисправность не будет устранена. Таким образом, уменьшаются требования к резервированию ресурсов кластера. Если подобный подход применим к вашей компании, полезно избрать политику Percentage of cluster resources reserved as failover spare capacity. Используйте этот режим и в случаях, когда требуется точнее управлять долей резервируемых ресурсов.

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

Третий параметр, Specify a failover host, применяется редко. В этом режиме не используется динамическое управление, зато можно выбрать определенный узел, который всегда будет в резерве на случай отказа, — в сущности, кластер никогда не будет применяться в нормальной ситуации. Как правило, выбор этого параметра — не оптимальный вариант, так как нельзя распределить резервы внутри кластера и между несколькими узлами.

Настройка параметров виртуальной машины

На экране 5 показан второй экран настройки механизма HA, Virtual Machine Options. На нем приведены два параметра, определяющие поведение виртуальных машин в конкретных аварийных ситуациях. Оба они представляют параметры общей политики. После создания кластера можно скорректировать каждую настройку для отдельных виртуальных машин.

 

Экран 5. Параметры виртуальной машины

Параметр VM restart policy может иметь низкое (Low), среднее (Medium) и высокое (High) значения. Вспомните, что в ситуации высокой доступности виртуальные машины после отказа перезапускаются на исправных узлах кластера. Нередко требуется запускать определенные виртуальные машины прежде других, на случай недостатка ресурсов. Этот параметр определяет настройки по умолчанию для всех виртуальных машин, обеспечивая каждой виртуальной машине равные условия при определении порядка перезапуска. После формирования кластера нужно скорректировать политику перезапуска каждой виртуальной машины в свойствах кластера. Виртуальные машины со значением High будут перезапущены раньше, чем те, которым назначены уровни Medium или Low.

Еще один параметр на данном экране мастера, Host Isolation response, требуется рассмотреть внимательно. Не будем забывать, что состояние кластера считается исправным, когда каждый из его узлов может обмениваться сигналами с остальными. В случае отказа узла другие обнаруживают отсутствие сигналов подтверждения соединения, и предпринимается попытка использовать механизм HA для эвакуации виртуальных машин на исправные узлы.

Что если узел на самом деле не вышел из строя, а потерял связь с кластером по сети? Такая ситуация весьма вероятна, поскольку кластером ESX используется много различных сетевых соединений. Его виртуальные машины по-прежнему функционируют. В этой ситуации остальные узлы кластера видят, что узел вышел из строя, хотя в действительности это не так. В то же время изолированный узел обнаруживает, что более не получает ответных сигналов подтверждения соединения от других узлов кластера. Какими должны быть его действия в отношении этих виртуальных машин?

Ответ на этот вопрос определяется параметром Host Isolation Response. От выбранного варианта настройки — Leave powered on, Power off и Shut down — зависит, останутся ли виртуальные машины на изолированном узле включенными, будут упорядоченно закрыты или просто отключены (подобно нажатию кнопки электропитания виртуальной машины).

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

Поэтому в большинстве случаев полезно настроить режим Power Off (отключение питания). Это приводит к потере виртуальных машин в случае изолирования, но блокировки снимаются, и виртуальные машины можно перезапустить на оставшихся узлах кластера. После перезапуска виртуальной машины можно исправить изолированный узел и вновь присоединить его к кластеру.

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

Мониторинг виртуальной машины

Последний экран мастера, относящийся к механизму HA, — VM Monitoring (экран 6). Его параметры указывают, следует ли включать мониторинг отдельных виртуальных машин, в отличие от отдельных узлов, настроенных ранее. Они также определяют уровень детализации мониторинга.

 

Экран 6. Мониторинг VM

По умолчанию мониторинг виртуальной машины отключен, так как в этом режиме перезапускается виртуальная машина, от которой не поступает сигналов подтверждения соединения. Эти сигналы могут отсутствовать по разным причинам, часть из которых не имеет никакого отношения к виртуальной машине. Например, прием сигналов может быть невозможен из-за отказа VMware Tools или ошибки в настройке сетевой платы виртуальной машины. В любом случае, даже если виртуальная машина функционирует безупречно, отсутствие сигналов синхронизации может заставить vCenter перезапустить виртуальную машину. Как правило, полезно оставить эту функцию отключенной, пока не будет достигнуто полное понимание всех последствий. Как и в других случаях, всегда можно внести изменения после создания кластера.

Сложность HA необычно высока для службы, которая просто перезагружает виртуальные машины на исправные узлы кластера. Прежде чем ее включить, составьте четкий план. Убедитесь в наличии достаточных ресурсов для автоматического переключения; возможно, для этого придется купить дополнительные серверы. Недостаточные возможности оборудования в сочетании с политиками управления разрешением на запуск могут привести к серьезным проблемам в будущем. Даже включая HA, убедитесь в правильности настроек. Внимательно изучите доступные варианты и продумайте настройки, прежде чем щелкнуть Turn On VMware HA.

Грег Шилдс (virtualgreg@concentratedtech.com) — соучредитель и технический руководитель в компании Concentrated Technology, специализирующейся на ИТ-аналитике и стратегическом консалтинге