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

Переезжаем на vCenter 5: Web Client пока тормозит, DRS с affinity-правилами спасает

Мигрируем с vCenter 4.1 на vCenter 5.0. Web Client красивый, но медленный - работаем на C#-клиенте. Настраиваем DRS affinity для разделения продакшн и тестовых ВМ.

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

VMware vCenter 5.0 с vSphere Web Client и переработанным HA/DRS вышел летом 2011 года

VMware объявил vCenter 5.0 в июне, а мы уже успели поднять его в одной из клиентских сред. Повод для миграции с vCenter 4.1 был конкретный: клиент вырос, ESXi-хостов стало больше, и старая HA-топология начала вызывать вопросы при сбоях. Плюс интересовал обновлённый DRS.

Рассказываем, что получилось.

Web Client: красиво, но пока не для работы

Первое, на что все обращают внимание в vCenter 5 - это новый Web Client на Adobe Flex. VMware явно делают на него ставку: браузерный интерфейс, не нужен Windows для администрирования, всё такое.

На практике - интерфейс медленный. Не катастрофически, но ощутимо: открытие списка ВМ, переключение между вкладками, загрузка графиков производительности - всё это ждёшь. На нашем стенде Web Client работал заметно медленнее C#-клиента на той же машине.

Решение простое: ставим C#-клиент (vSphere Client) и работаем через него. Он никуда не делся, в vCenter 5 поддерживается полноценно. Web Client пощупали, оценили направление - и пока закрыли.

Новая HA-топология: Primary/Secondary вместо Election

В vCenter 4.1 HA-кластер выбирал хосты в роли Primary (до 5 штук) через механизм Election, остальные были Secondary. Это иногда создавало нестандартные ситуации при нескольких одновременных сбоях.

В vCenter 5 схему переработали. Теперь один хост - Master, остальные Slave. Master хранит состояние кластера, мониторит агентов на Slave-хостах и инициирует рестарт ВМ при отказах. Если Master падает - Slave-хосты выбирают нового из тех, у кого есть доступ к общему датастору.

На практике это проще понимать и проще отлаживать. Когда HA-события логируются, теперь сразу видно: кто был Master, кто принял решение о рестарте, на каком хосте ВМ поднялась.

DRS и affinity-правила: отделяем продакшн от теста

Вот это была основная причина миграции. У клиента на одном кластере крутились и продакшн-ВМ, и тестовые стенды. DRS в 4.1 мог совершенно спокойно перебалансировать нагрузку и положить ресурсоёмкий тест рядом с боевой базой данных на одном хосте.

В vCenter 5 affinity-правила (VM-Host Affinity Rules) стали гибче. Настроили следующим образом:

  • Группа хостов "prod-hosts" - два физических сервера с большим объёмом RAM, выделены под продакшн.
  • Группа хостов "dev-hosts" - оставшиеся хосты, менее мощные.
  • Группа ВМ "prod-vms" - все боевые ВМ клиента: файловый сервер, AD, почта, 1С.
  • Правило "Must run on": prod-vms - только на prod-hosts.
  • Правило "Should run on": dev-вм - предпочтительно dev-hosts (мягкое, не жёсткое).

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

После настройки запустили DRS в режиме Automatic с агрессивностью на 3 (из 5). За несколько дней он сам перебалансировал кластер: тяжёлые тестовые стенды с разработчиками уехали на dev-хосты, продакшн остался на своих.

Admission Control и правило N+1

Отдельно разобрались с Admission Control в новой HA-схеме. У клиента 4 хоста в кластере. Настроили политику "Host Failures Cluster Tolerates" = 1: кластер резервирует ровно столько ресурсов, чтобы при выходе одного хоста все ВМ поместились на оставшихся трёх.

Это требует, чтобы ни один хост не был загружен больше чем на 75% в нормальном режиме. DRS в этом помогает: если загрузка начинает расти, он мигрирует ВМ до того, как Admission Control начнёт блокировать включение новых машин.

Раньше с такой конфигурацией разбирались вручную и на глаз. Теперь vCenter сам считает слоты и показывает в разделе HA Summary сколько слотов свободно и сколько заблокировано политикой.

Что ещё заметили

Storage vMotion в vCenter 5 работает заметно стабильнее при миграции больших дисков. Мигрировали несколько VMDK по 200+ ГБ между датасторами - без зависаний, с нормальным прогрессом.

vSphere Update Manager при апгрейде ESXi-хостов с 4.1 до 5.0 в целом справился. Один хост пришлось обновлять вручную через ISO - VUM не нашёл нужный драйвер сетевой карты и отказался продолжать. Победили через ручную установку и импорт в VUM-инвентарь.

Лицензирование изменилось: vSphere 5 перешёл на модель с ограничением по объёму RAM на хост в зависимости от edition. Для клиента это пока не критично - у них Enterprise Plus, лимит высокий. Но для небольших инсталляций это стоит считать заранее.

Web Client продолжаем наблюдать - обновления VMware выходят регулярно, и производительность интерфейса явно будет улучшаться итерациями. Пока же C#-клиент никуда не убираем.

Если работаете с VMware-инфраструктурой и планируете переход на vCenter 5 - готовы помочь спланировать миграцию и настроить DRS/HA под вашу топологию в рамках сопровождения ИТ-инфраструктуры.

Контакт

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

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