VMware vSphere 4 HA и DRS: автоматическая балансировка и перезапуск VM

Когда в мае смотрели на vSphere 4 и тестировали vStorage API, HA и DRS намеренно отложили на потом. Это не те фичи, которые проверяются на стенде из двух хостов за пару часов, - их надо настраивать под реальную инфраструктуру с нормальным числом машин и правильно выверенными admission control parameters. Теперь добрались: у клиента с кластером из четырёх хостов на ESXi 4.0 и вычислительной нагрузкой разного профиля подняли оба механизма в полноценном режиме.

DRS: как настраивали и что получили

Distributed Resource Scheduler - механизм, который следит за загрузкой CPU и памяти по всем хостам кластера и при перекосе переносит виртуалки через vMotion туда, где ресурсов больше. Три режима: Manual (только советует), Partially Automated (автоматически размещает при включении VM, потом советует), Fully Automated (делает всё сам).

Поставили Fully Automated с агрессивностью на уровне 3 из 5 - это значит, что vCenter переедет с рекомендацией только при заметном дисбалансе, не будет елозить виртуалками по поводу каждого небольшого всплеска. По опыту, ставить 4-5 смысла нет: vMotion при всей своей прозрачности - это сетевой трафик, и гонять машины туда-обратно при мелких колебаниях некрасиво.

Пул ресурсов разделили на два: production и dev. У production - гарантированные резервации по CPU и памяти, у dev - всё что останется. DRS уважает эти границы: никакая dev-машина не объест продакшен, даже если DRS решит её перевезти.

Первые несколько дней понаблюдали за логами рекомендаций vCenter. Картина показательная: до DRS часть хостов работала с загрузкой под 70-80%, другие - по 20-30%. Не потому что мы плохо планировали размещение, просто нагрузка у клиента неравномерная по времени суток и дням, и вручную за этим не уследишь. После включения Fully Automated кластер выровнялся. vCenter сделал несколько vMotion-миграций в первые часы, потом - только в ответ на реальные изменения нагрузки. Без нашего участия.

Отдельно настроили affinity и anti-affinity rules для критичных пар VM: некоторые машины должны жить на разных хостах (anti-affinity), некоторые - лучше держать вместе из соображений latency (affinity). DRS эти правила соблюдает и в рекомендациях, и в автоматических переездах.

HA: настройка admission control

High Availability - механизм перезапуска VM при падении хоста. Звучит просто, настройка чуть сложнее.

Самый важный параметр - Admission Control Policy. Он определяет, сколько ресурсов кластера резервируется для сценария «упал один хост». Три варианта политики: по числу хостов, по процентам от кластерных ресурсов, или Host Failures Cluster Tolerates. Выбрали последний: одновременный отказ одного хоста. На четырёх хостах это означает, что HA держит в резерве 25% ресурсов кластера - столько, сколько нужно, чтобы перезапустить всё что было на упавшем хосте.

Важный момент с admission control: если включить HA без этой политики или поставить слишком мягко, vCenter даст включить VM сверх «ёмкости восстановления» и в случае реального отказа попросту не сможет всё перезапустить - ресурсов не хватит. Видели такие конфиги у других, это неприятный сюрприз в момент инцидента.

VM Restart Priority расставили по группам: critical, high, normal. Базы данных и AD-контроллеры - critical, всё остальное продакшен - high, dev - normal. HA восстанавливает в этом порядке, что важно, если кластер в момент отказа сильно нагружен.

Реальный отказ

Примерно через две недели после настройки на одном из хостов умер блок питания. Не плановое отключение, не тест - настоящий физический отказ, хост просто пропал с радаров vCenter.

HA среагировал. По логам vCenter - VM с упавшего хоста начали перезапускаться на остальных трёх примерно через 90 секунд после того, как кластер зафиксировал потерю хоста. Критичные машины поднялись первыми. На всё ушло несколько минут - зависело от времени загрузки ОС и приложений внутри VM, не от vSphere.

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

Для сравнения: без HA в похожей ситуации мы бы узнали об отказе из мониторинга, открыли vCenter, вручную мигрировали или перезапустили VM, проверили состояние - это занимало бы 10-20 минут в лучшем случае. С учётом что инцидент был в нерабочее время - больше.

Что стоит иметь в виду

Shared storage обязателен. HA и DRS работают только при наличии общего хранилища - все хосты должны видеть одни и те же datastore. Локальные диски выпадают из схемы. Здесь у клиента iSCSI-хранилище, общее для всех четырёх хостов, что и позволяет vMotion и перезапуск VM на любом хосте.

vMotion требует отдельной сети. Гонять образы памяти живых VM по тому же линку, что и production-трафик - не лучшая идея. Выделенная сеть под vMotion у клиента была ещё с настройки vMotion в феврале, это упростило конфигурацию.

Heartbeat datastores. В vSphere 4 HA использует не только сетевые heartbeat между хостами, но и heartbeat через shared datastore. Это защита от split-brain: если сеть между хостами упала, но хранилище доступно, HA понимает, что хост жив и не начинает перезапускать его VM на других узлах. Настройка по умолчанию, но стоит проверить что выбранные datastores доступны всем хостам кластера.

Инфраструктуру для клиента ведём в рамках сопровождения, так что HA-событие обработали быстро и отчёт клиенту подготовили в тот же день. Хост сейчас на замене блока питания, кластер работает на трёх, DRS перераспределил нагрузку автоматически.