ADG Оставить заявку
Блог Инфраструктура 4 мин чтения

VMware vSphere 5.5 Update 1: накатываем на кластер и закрываем давние жалобы клиентов

Обновляем кластер vSphere 5.5 до Update 1: фиксы VMXNET3, совместимость vMotion, реальный порядок действий и что проверить после накатки.

Контекст момента

VMware выпускает vSphere 5.5 Update 1 с исправлениями VMXNET3 и улучшениями совместимости vMotion

VMware выпустила vSphere 5.5 Update 1 - и мы довольно быстро взялись за его накатку на несколько клиентских кластеров. Не из любви к приключениям, а потому что в Release Notes оказалось несколько пунктов, которые напрямую касались жалоб, копившихся с прошлого года.

Основная история здесь - VMXNET3 и вопросы совместимости при vMotion. Расскажем по порядку, потому что пара моментов в процессе вызвала удивление даже у людей, которые давно работают с vSphere.

Почему не ждали

С момента выхода vSphere 5.5 осенью несколько клиентов периодически сообщали о странных сетевых просадках на конкретных ВМ. Симптомы разные: кратковременные потери пакетов без видимой причины, иногда - сброс TCP-соединений в моменты нагрузки. Общее у всех - VMXNET3 как сетевой адаптер у проблемных ВМ.

Диагностика каждый раз шла по одному пути: проверяем физику, смотрим distributed switch, смотрим хост, убеждаемся что всё в порядке - и упираемся в известный баг в VMXNET3. VMware подтвердила его в базе знаний ещё в конце 2013-го, пообещала фикс в ближайшем обновлении. Update 1 - это и есть тот самый фикс.

Второй пункт - vMotion между хостами с разными версиями CPU microcode. У одного из клиентов кластер собирался в два захода: сначала несколько хостов, потом докупили ещё несколько - в результате хосты одного поколения, но с разным микрокодом после обновлений. vMotion иногда отказывался мигрировать ВМ без видимой причины, а иногда - мигрировал, но с предупреждением, которое никто не понимал как интерпретировать. Update 1 улучшает EVC-поведение в таких ситуациях.

Порядок накатки

Для кластера под нагрузкой порядок важен - Update Manager всё это делает за тебя, но понимать что происходит нужно.

  • Сначала vCenter Server. Обновление vCenter до 5.5 U1 идёт первым. ESXi-хосты 5.5 без обновления продолжают работать под управлением обновлённого vCenter без проблем - обратная совместимость сохраняется.
  • Потом ESXi-хосты через Update Manager. Хосты уходят в maintenance mode по одному, DRS сам мигрирует ВМ. Главное - убедиться что кластер не работает на пределе ресурсов и есть куда мигрировать.
  • Проверка после каждого хоста. Не ждать пока обновятся все - после первого хоста проверить что ВМ запустились нормально, сеть работает, vMotion туда-обратно проходит.

Обновление Tools и virtual hardware version на ВМ - отдельный разговор. Это не обязательно делать сразу, и мы обычно рекомендуем клиентам прокатить это позже, планово, с согласованными окнами обслуживания для критичных систем.

Что проверяли после обновления

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

По vMotion-совместимости: проверили кластер со смешанным microcode. Миграции стали проходить чище, предупреждения исчезли. EVC-режим на кластере остался как был - Update 1 не требует его менять, просто улучшает поведение в граничных ситуациях.

Один момент, который удивил: после обновления ESXi-хостов у нескольких ВМ с Windows Server 2012 R2 поднялась версия VMXNET3-драйвера автоматически через VMware Tools - без перезагрузки гостевой ОС это не применилось, что логично, но в мониторинге это выглядело как «ВМ требует reboot» без объяснения почему. Предупреждаем об этом заранее, чтобы не было вопросов ночью от дежурных.

Что из этого следует

Сопровождение VMware-инфраструктуры - это в том числе отслеживание таких вот обновлений и оценка: накатывать срочно или подождать. Update 1 для нас попал в категорию «накатить быстро» именно из-за VMXNET3: баг подтверждён вендором, фикс есть, жалобы клиентов живые.

Параллельно убедились, что наш процесс через Update Manager работает без сюрпризов - хосты обновились, ВМ мигрировали, простоев не было. По времени на кластер из нескольких хостов ушло рабочее утро с запасом.

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

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.