VMware HA и vMotion: год в production и накопленные грабли

Примерно год назад мы перевели несколько клиентских площадок на полноценный HA-кластер VMware Infrastructure 3.5 - два хоста ESX, общий SAN, лицензии Enterprise с vMotion и DRS. Достаточно времени, чтобы понять, что работает именно так, как написано в документации, а что ведёт себя немного иначе.

Как устроен наш типовой кластер

Конфигурация стандартная: два физических хоста ESX 3.5, общее iSCSI-хранилище на VMFS-томах, VirtualCenter для управления, изолированная сеть для vMotion (гигабит, отдельный vSwitch). HA и DRS включены. Количество ВМ на объект - от десяти до двадцати, в зависимости от нагрузки.

На каждом хосте два физических порта для service console и VMkernel, плюс отдельные порты под vMotion и storage. Казалось бы, классика, но именно сетевая часть принесла больше всего сюрпризов.

Heartbeat и ложные срабатывания изоляции

HA в VMware Infrastructure работает через heartbeat между хостами. Если хост перестаёт получать heartbeats от партнёра по сети service console и при этом не может пропинговать isolation address (по умолчанию - шлюз), он объявляет себя изолированным и выполняет isolation response. По умолчанию isolation response - это «оставить ВМ работать», но многие ставят «выключить» или «suspend», чтобы не получить split-brain с дублирующимися машинами.

Проблема в том, что ложные срабатывания случаются чаще, чем ожидаешь. У нас было два инцидента:

Первый - кратковременный сбой коммутатора на пять-семь секунд. Хост потерял heartbeat, не достучался до шлюза через тот же коммутатор и сработал isolation response. ВМ ушли в suspend. Пользователи заметили. Реальной проблемы с хостом не было.

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

Что помогло:

Добавить второй isolation address. По умолчанию один - шлюз. Но его можно настроить через advanced параметры HA (das.isolationaddress1 и далее). Мы добавили IP storage-контроллера, который живёт в другом сегменте. Теперь хост считается изолированным только если не достучался до обоих адресов. Ложных срабатываний стало значительно меньше.

Резервировать uplink service console. У нас был один физический порт на service console - этого мало. После инцидента добавили второй vmnic в team. Теперь потеря одного физического порта не означает потерю heartbeat.

Настроить das.failuredetectiontime. По умолчанию 15 секунд. На нервных сетях можно поднять до 20-30 секунд - это даёт время на кратковременные флапы. Компромисс с временем реакции на реальный отказ, но для нашей инфраструктуры приемлемо.

vMotion: когда помогает, а когда раздражает

vMotion работает хорошо. Миграция десятка гигабайт оперативки укладывается в десять-пятнадцать секунд без заметного прерывания сервисов - мы проверяли пингом и мониторингом. Для нагруженных ВМ немного дольше, но в пределах разумного.

Главный практический вывод: vMotion требует симметрии хостов. Процессоры должны быть одного семейства - Intel-to-Intel или AMD-to-AMD, и желательно совместимого stepping. У одного клиента мы добавили второй хост с процессором чуть новее первого, и vMotion для части ВМ отказал по несовместимости CPU features. Решилось включением EVC (Enhanced vMotion Compatibility) в настройках кластера - кластер маскирует инструкции до наименьшего общего знаменателя. Небольшая потеря производительности для ВМ с интенсивными вычислениями, но зато миграция работает.

DRS экономит больше, чем кажется

DRS (Distributed Resource Scheduler) мы поначалу считали удобством, а не экономией. Оказалось иначе.

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

Но главный эффект - в режиме плановых работ. Когда нужно обслужить один хост, DRS сам эвакуирует с него ВМ на второй, не требуя ручного vMotion по одной машине. Раньше мы делали это руками - муторно и долго. Сейчас: включаешь Maintenance Mode на хосте, DRS начинает миграции, через несколько минут хост пустой. Экономия времени при каждом обслуживании ощутимая.

Рекомендуем держать DRS в режиме Fully Automated для балансировки и Manual для вхождения в Maintenance Mode - чтобы иметь контроль над моментом начала миграций при обслуживании. Хотя в большинстве случаев автоматика справляется.

Про Fault Tolerance - пока в стороне

В VI3.5 есть ещё Fault Tolerance (FT), которая обеспечивает нулевое время восстановления через синхронное зеркалирование состояния ВМ. Ограничения серьёзные: только однопроцессорные ВМ, требует отдельной гигабитной сети для logging, есть нюансы с производительностью. Мы смотрели, но пока не внедряли - HA с временем восстановления в минуту-полторы для большинства клиентских задач достаточно, а сложность FT добавляет операционных рисков.

Итог на сейчас

Связка HA + vMotion + DRS на двух хостах - рабочая конфигурация для сопровождения инфраструктуры среднего бизнеса. Не без граблей, но грабли известны и обходятся настройками. Главное, что поняли за год: настройки по умолчанию подходят для демо, но не для production. Isolation address, heartbeat timeout, EVC, резервирование сети service console - всё это нужно осознанно настраивать при развёртывании, а не когда уже прилетел первый инцидент.