Xen 3.1: Windows через HVM и 15% прироста I/O у Linux-доменов

Xen 3.1 вышел буквально на этой неделе, и мы немедленно обновили тестовый стенд - благо он у нас для того и существует, чтобы не ждать месяц перед тем как трогать что-то в production.

Что нас вообще интересовало в 3.1

У нас с Xen 3.0 были два отдельных источника боли. Первый - Windows-гости через HVM вели себя непредсказуемо: иногда зависали при интенсивном дисковом I/O, иногда просто падали с BSoD без явной причины. Второй - Linux-домены работали нормально, но в сравнении с железом проспросматривалось отставание, особенно при работе с дисками через блочные устройства.

Именно под это и была написана основная часть changelog 3.1: улучшенный HVM и работа с паравиртуализованными драйверами.

HVM: Windows-гости наконец-то живут спокойно

После обновления прогнали стандартный набор нагрузок по Windows-гостям - файловый сервер с параллельными записями, 1С в тестовой конфигурации, база данных под нагрузкой. Все три сценария, которые раньше периодически роняли гостей, отработали без сюрпризов.

Это не значит, что HVM в Xen стал идеальным. Windows внутри HVM-домена всё равно работает медленнее, чем para-virtualized Linux: нет паравиртуализованных драйверов для сети и диска, всё идёт через эмуляцию. Но стабильность - это уже другой разговор. Падающий гипервизор никакой производительностью не компенсируешь.

Ключевое замечание из нашего тестирования: если на хосте включен Intel VT-x или AMD-V, HVM работает значительно лучше, чем без аппаратной поддержки. Мы проверяли на двух разных серверах - один с VT-x, один без. Разница ощутимая. Если планируете держать Windows в Xen, CPU с аппаратной виртуализацией - не опция, а требование.

Para-virt Linux: I/O прибавил порядка 15%

Это наблюдение оказалось для нас более интересным практически. Тестировали на одном и том же железе: dom0 на CentOS 5, гость - тоже CentOS 5, нагрузка - iozone по нескольким паттернам. Сравнивали 3.0 и 3.1 на одинаковом наборе тестов.

Прирост на последовательном чтении и записи - около 15% в пользу 3.1. Случайный доступ дал чуть меньше, но тоже в плюс. Цифра не огромная, но стабильная: повторяли три раза в разные дни, результаты держались в пределах погрешности.

Откуда прирост - в changelog честно расписано: переработан путь I/O между domU и dom0 через блочный бэкенд, снижены накладные расходы на переключение контекста при операциях с диском. На уровне архитектуры это звучит правдоподобно.

Один нюанс. Результаты сильно зависят от того, как настроен dom0: сколько vCPU у него выделено, как настроен планировщик (мы используем credit scheduler по умолчанию), насколько загружен хост другими доменами во время теста. Прогонять iozone на полностью нагруженном хосте и сравнивать с результатами на пустом - бессмысленно. Мы гоняли при минимальной сторонней нагрузке.

Что дальше: миграция dev-серверов с физики

На основе результатов тестов решили начать плановую миграцию dev-серверов с физического железа в Xen. Пока речь о Linux-машинах - те пойдут как para-virt, там профит понятен. Windows dev-сервер пока оставим на физике ещё на один цикл: HVM стал стабильнее, но производительность эмуляции нас не устраивает для рабочей разработки.

Схема миграции простая:

• Инвентаризация - список dev-серверов с текущей нагрузкой и профилем использования I/O и RAM.
• Приоритет - сначала те, у кого низкая I/O нагрузка и нет привязки к специфичному железу.
• Параллельный прогон - на переходный период держим физическую машину live, домен в Xen работает рядом, сравниваем поведение под реальной нагрузкой разработчиков.
• Вывод физики - только после двух-трёх недель спокойной работы в Xen.

Это не быстрый процесс. Зато не нервный. Полный перевод dev-инфраструктуры на Xen - несколько месяцев работы при таком подходе, но это нормально. Торопиться здесь некуда.

Про VMware

Нас несколько раз спросили: зачем Xen, если есть ESXi, который тоже стал бесплатным? Ответ простой: у нас уже есть инфраструктура на Xen, команда с ним работает, и менять стек ради смены стека смысла нет. Кроме того, Xen с открытым исходным кодом - это другой уровень контроля над тем, что происходит внутри. Для managed-инфраструктуры клиентов это важно.

Продолжаем следить за обоими вариантами, но конкретная миграция идёт на Xen.