VMware vSphere 4: тестируем vStorage API и готовимся к миграции продакшена

На прошлой неделе VMware официально выпустила vSphere 4. Не просто очередной мажорный апдейт - компания переименовала всю платформу, перетрясла архитектуру гипервизора и выпустила сразу ESX 4.0, ESXi 4.0 и vCenter Server 4. Ждали этого релиза с зимы, когда настраивали vMotion на ESX 3.5 и в конце поста написали: «Следим за vSphere 4». Вот и дождались.

Подняли тестовую ферму на ESX 4.0 в первые же дни после релиза. Первое, что хотелось проверить - не архивировать список changelog, а посмотреть на конкретную боль: бэкапы виртуалок в продакшене.

Почему бэкап VM раньше был неприятной темой

На ESX 3.x стандартная схема резервного копирования через снэпшот работала так: агент на машине-бэкапа или скрипт давали команду создать snapshot, копировали диск, после чего snapshot удалялся. Проблема - в момент создания и особенно удаления snapshot VM «зависала» на несколько секунд. Это и есть stunned snapshot: гипервизор тормозит виртуалку, чтобы зафиксировать состояние диска. На загруженной VM с большим объёмом изменений это могло тянуться неприятно долго - в районе десятков секунд. Для базы данных или почтового сервера такая пауза не радует ни клиента, ни нас.

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

vStorage API: что изменилось

vSphere 4 вводит vStorage APIs for Data Protection (VADP). Это набор интерфейсов, через которые агент бэкапа работает с дисками VM напрямую, минуя гипервизор как посредника для IO-операций. Вместо того чтобы монтировать снэпшот через хост и тянуть данные через него же, агент получает прямой доступ к VMDK через транспортный слой.

Поддерживаются несколько транспортов: SAN (прямо с LUN, мимо хоста вообще), HotAdd (агент на отдельной VM в том же датацентре подключает диски напрямую) и NBD (по сети, для случаев когда SAN/HotAdd недоступны). Stunned snapshot при этом всё равно происходит - никуда не делся сам механизм заморозки на момент создания checkpoint - но пауза сокращается до долей секунды, потому что копирование данных идёт уже без участия работающей VM.

Что мы намерили на стенде

Подняли тестовую среду: два хоста ESX 4.0 на одном iSCSI-хранилище, vCenter 4, несколько VM разного размера. В качестве бэкап-агента использовали инструмент, который умеет работать через VADP - в нашем случае интеграция через VMware Consolidated Backup (VCB) 1.5, пока без полноценного нового агента, который только начинают адаптировать под API четвёртой версии.

Результаты на трёх машинах, примерно одного профиля (Windows с SQL):

• Скорость чтения диска VM во время бэкапа - выросла примерно втрое по сравнению с той же схемой на ESX 3.5 через SAN-транспорт. Объяснение простое: хост перестал быть узким местом в IO-пути.
• Заметная пауза на VM - практически исчезла. Раньше на активной базе мы видели 20-40 секунд «заморозки», теперь это миллисекунды по счётчику vCenter.
• Нагрузка на хост во время бэкапа упала ощутимо - агент работает отдельно, хост не тратит CPU на пережёвывание IO.

Цифры условные - всё зависит от конкретного железа, транспорта и нагрузки. Но порядок цифр повторялся на разных тестовых прогонах стабильно.

Что ещё заметили в vSphere 4

Параллельно с бэкапами посмотрели на другие изменения:

• Distributed vSwitch - теперь сетевая конфигурация настраивается на уровне vCenter и распространяется на все хосты кластера, а не настраивается на каждом хосте отдельно. Звучит как мелочь, пока у тебя три хоста. На шести уже актуальнее.
• vNetwork и улучшения в работе с 10GbE - у нас на стенде обычные гигабитные адаптеры, но видно, что VMware серьёзно работала над сетевым стеком.
• ESX 4.0 vs ESXi 4.0 - функционально они теперь ближе друг к другу, чем в третьей версии. Сервисная консоль в ESX 4.0 всё ещё есть, но VMware явно движется к тому, что ESXi - это правильный путь.

Отдельная тема - лицензирование. VMware перешла на модель лицензирования по процессорам с ограничением по ядрам (up to 6 cores per CPU включены в базовую лицензию, больше - доплата). Это меняет математику для серверов с современными многоядерными процессорами. Надо считать под каждого клиента отдельно.

Что дальше

По результатам тестового стенда - vSphere 4 готова к тому, чтобы переводить на неё продакшен. Stunned snapshots были одним из главных аргументов против агрессивного расписания бэкапов, теперь этот аргумент ослаб.

Планируем поэтапную миграцию продакшен-хостов: первая волна в июне, оставшиеся в июле. Стратегия - сначала менее критичные хосты, следим неделю, потом основные. vCenter будет обновлён первым, так как без него управлять смешанной фермой ESX 3.5 + ESX 4.0 неудобно, но технически возможно на период перехода.

Клиентам, чью инфраструктуру мы ведём, миграцию согласуем отдельно по каждому - у всех разный состав хостов и разные требования к окнам обслуживания.