VMware ESX 3.5 Update 2: патчим без vMotion и фиксируем регламент

VMware выкатила ESX 3.5 Update 2 - пачка патчей безопасности плюс несколько исправлений стабильности, часть из которых касается работы со снапшотами и сетевыми драйверами. Ничего революционного, но обновление из серии «поставь, не тяни».

У нескольких клиентов стоит ESX в конфигурации «два хоста, общий SAN, без лицензии vMotion». Хочешь обновить хост - думай ногами, потому что живой миграции нет. Именно на этой конфигурации мы и отработали процедуру, которую теперь собираемся зафиксировать как стандарт.

Как выглядит патчинг без vMotion

vMotion - это удобно: перегнал машину на второй хост на лету, обновил первый, вернул. У нас лицензия Enterprise не везде, часть клиентов сидит на Standard. Значит, миграция только через выключение или через suspend. Мы выбрали suspend - он быстрее перекладывается и позволяет поднять машину почти мгновенно на другом хосте.

Последовательность получилась такая:

Уведомить клиента заранее. Suspend - это не downtime в полном смысле, но несколько секунд пауза есть. Для большинства сервисов незаметно, для некоторых - критично. Лучше предупредить за день.

Перевести первый хост в Maintenance Mode. VirtualCenter начинает ворчать, что хост недоступен для новых задач, - это нормально. Никакой автоматики нет, только признак для оператора.

Suspend и перенести все ВМ на второй хост. По одной. На втором хосте suspend-файл подхватывается с SAN - если хранилище общее, перемещать данные не нужно, только зарегистрировать и возобновить. У нас на одном объекте было восемь машин; ушло минут двадцать вместе с проверками.

Обновить хост через esxupdate. Подключаешься по SSH, запускаешь esxupdate с нужным пакетом, ждёшь. Перезагружаешь хост. Проверяешь, что всё поднялось, что агенты VirtualCenter подключились, что хранилища видны.

Вернуть ВМ обратно. Снова suspend на втором хосте, возобновление на первом. Выводим первый из Maintenance Mode.

Повторить для второго хоста. В этот момент все машины снова на первом, второй уходит в обслуживание.

Получается два окна по двадцать-тридцать минут с интервалом. Не элегантно, но работает.

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

Без неожиданностей не обошлось. На одном хосте после обновления не поднялся один из vmnic - оказалось, Update 2 обновляет несколько драйверов сетевых адаптеров, и на конкретной плате потребовалась перенастройка привязки vSwitch к физическому интерфейсу. Ничего страшного, но без заготовленного конфига сети потеряли бы время. Сейчас добавили в чеклист: перед патчингом снять конфиг сетевых коммутаторов хоста (esxcfg-vswitch -l и esxcfg-nics -l), положить рядом.

Второй момент - снапшоты. На одной машине висел старый снапшот, про который, судя по всему, все забыли. При suspend такая машина пишет файл состояния поверх снапшота, и потом при возобновлении на другом хосте иногда возникает путаница. Машина поднялась нормально, но лишние нервы были. Чеклист пополнился: перед обслуживанием хоста - удалить все снапшоты на его ВМ.

Почему вообще фиксируем регламент

Когда мы только начинали с ESX в production, патчинг делался по наитию - у кого руки дошли, тот и обновил, как умеет. С ростом числа объектов такой подход перестаёт работать: разные люди делают по-разному, что-то забывается, что-то делается в неудобный момент. А обновления безопасности надо ставить в разумные сроки, особенно когда ESX-хост торчит в сеть без лишних экранов.

В рамках сопровождения инфраструктуры мы сейчас пишем регламент патчинга ESX на все типовые конфигурации: один хост, два хоста без vMotion, кластер с vMotion. Этот случай - средний, самый распространённый у клиентов в нашем портфеле.

Регламент будет включать: чеклист до обслуживания, последовательность действий, типовые проверки после обновления, список команд для диагностики. Не ракетостроение, но иметь под рукой готовый документ лучше, чем каждый раз восстанавливать по памяти.

Что с самим Update 2

По существу - стабильнее. Одна из машин на старом ESX 3.5 периодически роняла сетевой интерфейс гостя без видимых причин; после Update 2 на этом же железе симптом пропал. Возможно, совпадение, возможно - одно из исправлений в release notes, которые VMware описывает достаточно кратко.

Снапшоты по ощущениям стали немного шустрее - commit большого снапшота прошёл заметно быстрее, чем на предыдущей версии. Но это одно наблюдение, не статистика.

В целом: обновление плановое, ставить стоит. Сам процесс - неприятная ручная работа, но предсказуемая. Когда у нас появился ESXi как бесплатная опция, казалось, что патчинг там проще; на практике у ESX и ESXi свои особенности, и для серьёзного production мы пока держимся за полный ESX с VirtualCenter.