vSphere 6.0 Update 2: лечим vMotion после трёх месяцев тихого ужаса

В декабре прошлого года мы обновили один из хостов кластера vSphere 6.0 - плановая замена сервера, железо пришло с уже более свежей версией ESXi из той же ветки 6.0. Разница в build-номере небольшая, патч-уровни разные. VMware формально это поддерживает в ограниченном режиме, но что-то пошло не так. vMotion начал валиться примерно в 30% случаев с невнятной ошибкой про несовместимость CPU feature masks. HA работал, DRS работал, виртуалки жили - но вживую мигрировать их между хостами было как в лотерею.

Три месяца мы с этим жили. Временный workaround - подключить EVC-режим на кластере - убрал ошибку, но срезал возможности CPU на виртуалках. Для большинства рабочих нагрузок это не критично, но несколько машин с интенсивной математикой сразу потеряли в скорости, и там это почувствовали. Обещали пофиксить с очередным обновлением.

Обновление вышло.

Что в Update 2

У VMware вышла документация с release notes, там несколько десятков исправлений. Нас интересовала конкретно история с vMotion и mixed build numbers в кластере - это известный баг, подтверждённый в VMware KB. Update 2 его закрывает. Дополнительно в релизе:

• Поддержка новых платформ - Broadwell-EP/EN (Xeon E5 v4), новые серверы Cisco UCS, обновлённые списки совместимости HP и Dell.
• Исправления сети - несколько раздражающих багов с vSphere Distributed Switch, включая один с потерей пакетов при определённых конфигурациях LACP.
• NSX и vSAN - там свои списки исправлений, нас не касается, но в примечаниях упоминается.
• Общая стабильность - несколько PSOD (Purple Screen Of Death, аварийный дамп ESXi) с известными сценариями воспроизведения.

Нас интересует первое и последнее.

Процедура через Update Manager

У нас стандартный стек: vCenter Server Appliance 6.0, Update Manager на отдельной виндовой VM. Обновление кластера из четырёх хостов делали в рабочий день - не самое смелое решение, но инфраструктура на сопровождении работает под нагрузкой круглосуточно, и ждать выходных не было смысла: Update Manager с включённым DRS справляется без ручного переключения.

Последовательность была такая:

1. Сканирование через Update Manager - подключаем Baseline с нужным патчем, сканируем все хосты, убеждаемся что нет конфликтов.
2. Snapshot vCenter VCSA - страховка на случай если что-то пойдёт не так с апплайансом. Делается быстро, лежит пока идёт обновление.
3. Remediate поочерёдно - Update Manager переводит хост в Maintenance Mode, DRS эвакуирует VM на соседние хосты, накатывает патч, перезагружает, выводит из Maintenance Mode. Потом следующий.
4. Выход из EVC-режима - после того как все хосты на одном build уровне, EVC убираем и проверяем vMotion вручную.

По времени: каждый хост уходит в maintenance примерно на 20-25 минут, из них минут 10-12 - сама перезагрузка ESXi. На четыре хоста - около полутора часов с учётом пауз и проверок. DRS справился без нашего вмешательства: нагрузка размазалась по оставшимся хостам равномерно, ничего не упало.

После обновления

vMotion заработал нормально. Мы прогнали ручные миграции между всеми парами хостов - каждый раз успешно, без ошибок про CPU feature masks. EVC отключили, виртуалки с математической нагрузкой вернулись на нормальный профиль процессора.

Что неожиданно заметили: после обновления несколько хостов показали незначительно другие метрики памяти в vCenter - balloon driver реже срабатывает при той же нагрузке. Возможно, это эффект одного из исправлений memory management, возможно - совпадение. Понаблюдаем.

Один момент, который стоит упомянуть: Update Manager при сканировании показал один хост с несовместимым VIB от стороннего вендора (инструментарий мониторинга железа). Обновление на него накатилось нормально, но VIB стал неактивным - потребовалась установка обновлённой версии от вендора. Мы на это наткнулись только после того как хост вышел из maintenance и агент мониторинга железа перестал отвечать. Полезно перед remediate проверять список VIB-ов руками.

Итог

Три месяца с кривым vMotion - это неприятно, особенно когда баг воспроизводится не всегда, а где-то в 30% случаев, и каждый раз приходится объяснять, почему живая миграция не прошла. Теперь закрыто. EVC в кластере включать разучились, хосты на одном уровне - жить можно.

Если кто-то ещё не обновился с 6.0 GA или U1 - Update 2 выглядит стабильным вариантом для планового обслуживания.