vSphere 4.1 HA на четырёхузловом кластере: час диагностики, минута исправления

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

Кластер у них четыре узла: два старых хоста и два новых, которые добавили в начале года. Физически разные поколения железа - разное количество ядер, разный объём RAM. Это важно для дальнейшего.

Что пошло не так

После обновления до vSphere 4.1 и перенастройки HA новые VM перестали запускаться. Точнее, запускались, но тут же падали с ошибкой вида «недостаточно ресурсов для включения виртуальной машины» - и это при том, что хосты по мониторингу загружены дай бог на треть.

Первая мысль - что-то с лицензией после обновления. Проверили. Лицензия в порядке.

Вторая мысль - проблема с конкретным датастором. Тоже нет - VM, которые уже работали, прекрасно себе крутятся, место на SAN есть.

Третья мысль - может, DRS что-то чудит. Покрутили правила размещения - не помогло.

Примерно через сорок минут кто-то из команды открыл настройки HA-кластера и внимательно посмотрел на раздел Admission Control. И вот там всё сразу встало на места.

Причина: admission control и разнородный кластер

vSphere HA использует admission control для того, чтобы гарантировать: при отказе одного хоста оставшиеся смогут принять все его VM. Логика простая и правильная. Проблема возникает, когда кластер неоднородный.

Политика admission control по умолчанию в vSphere - Percentage of cluster resources reserved as failover spare capacity. При этом режиме vCenter смотрит, сколько ресурсов нужно зарезервировать под возможный failover, и не разрешает запуск новых VM, если свободного места меньше этого порога.

В нашем случае кластер из четырёх хостов с разными характеристиками: старые хосты дают заметно меньше CPU и RAM, чем новые. vCenter при расчёте слотов использует самую маленькую VM в кластере как эталон размера слота. Если в кластере есть VM с нестандартным профилем ресурсов - например, с явно прописанными Reservations - размер слота может стать очень маленьким, и тогда система «считает», что зарезервированных слотов уже недостаточно.

Именно это и произошло. При миграции на 4.1 параметры кластера были выставлены стандартными значениями по умолчанию, но одна старая VM имела явные Reservation по памяти - осталась с предыдущих настроек. Это подтянуло расчёт слотов вниз, и admission control начал считать кластер «полным» задолго до реальной нагрузки.

Как исправили

Потратили час на диагностику. Само исправление заняло минуту.

Открыли свойства кластера, раздел VMware HA - Admission Control. Переключили политику с Host failures cluster tolerates (в нашем случае было выставлено значение «1») на Percentage of cluster resources reserved с явно выставленным процентом - 25% CPU и 25% RAM. Это примерно соответствует одному хосту из четырёх с запасом.

После применения настройки vCenter пересчитал доступные ресурсы - и новые VM начали стартовать без проблем.

Параллельно почистили старые Reservation у VM, которые их не требовали по реальной нагрузке. Явные Reservation нужны только там, где есть реальная причина гарантировать минимум ресурсов - обычно для баз данных и критичных приложений. Ставить Reservation «на всякий случай» или по привычке - прямой путь к тому, что HA-кластер начнёт вести себя неожиданно.

Что стоит знать при настройке HA на разнородном кластере

Несколько наблюдений из этой истории:

• Admission control - это не баг, это фича. Система делает ровно то, для чего предназначена: не даёт запустить VM, если при отказе хоста ресурсов для failover не хватит. Неприятно, но правильно.
• Стандартные значения по умолчанию не всегда подходят. Особенно при разнородном кластере или при наличии VM с явными Reservation. Нужно смотреть на реальную конфигурацию.
• Слоты считаются по наименьшей VM с учётом Reservation. Это контринтуитивно: маленькая VM с большой Reservation «раздувает» расчётный размер слота и уменьшает их количество.
• Percentage-политика предсказуемее на разнородном железе. Она напрямую выражает «сколько ресурсов кластера держим под failover», без неочевидных расчётов слотов.

Сам vSphere 4.1 при обновлении ощущается заметно стабильнее 4.0 в части HA - меньше ложных срабатываний изоляции хоста, которые в предыдущей версии иногда случались при кратковременных сетевых проблемах. DRS тоже стал чуть умнее: рекомендации по балансировке нагрузки приходят реже, зато точнее.

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