Dynamic Memory в Hyper-V SP1: тестируем на кластере с 1С, плотность ВМ растёт

SP1 для Windows Server 2008 R2 вышел в феврале, и главной темой во всех обсуждениях стали две фичи Hyper-V: RemoteFX для VDI и Dynamic Memory для серверных виртуалок. RemoteFX - это отдельная история про GPU-виртуализацию, которая нас сейчас не касается. А вот Dynamic Memory мы запустили в тестовую эксплуатацию на реальном кластере. Пишем по свежим следам.

Контекст: откуда взялась задача

У одного из клиентов на обслуживании - двухузловый Hyper-V кластер на Windows Server 2008 R2, два хоста по 48 ГБ RAM. Основная нагрузка - виртуалки с 1С: сервер 1С, несколько клиентских терминальных серверов, SQL Server под базы данных. Память распределялась статически: каждой ВМ при создании назначалась фиксированная плашка и менять её на лету было нельзя, только перезагрузка гостя.

Проблема классическая. В пиковые часы - утро, начало рабочего дня, когда все заходят в 1С - серверам не хватает оперативной памяти. В нерабочее время те же серверы держат выделенные гигабайты впустую. Мы это видели в графиках Zabbix уже давно: ночью половина выделенной памяти не используется, днём несколько ВМ упираются в лимит. Классический overprovisioning, который невозможно исправить без Dynamic Memory или миграции на ESXi с его memory balloon driver.

После установки SP1 на оба узла кластера - обновление прошло штатно, миграция ВМ работала во время патчинга - включили Dynamic Memory на тестовой группе виртуалок.

Как это работает в SP1

Dynamic Memory в Hyper-V работает иначе, чем balloon driver в VMware. Вместо того чтобы «надувать» драйвер внутри гостя и принудительно отбирать страницы, Hyper-V использует механизм hot-add памяти: гостю добавляются или убираются физические блоки RAM через виртуальный DIMM-слот. Гость при этом должен уметь работать с горячим добавлением памяти - что Windows Server 2008/R2 и Windows 7 умеют, а более старые системы нет.

Для каждой ВМ задаётся три параметра:

• Startup Memory - сколько памяти выдать при старте.
• Minimum RAM - нижняя граница, ниже которой хост не опустится.
• Maximum RAM - верхняя граница, выше которой гость не получит.

Плюс параметр Memory Buffer - процент «запаса» сверх того, что реально используется гостем. По умолчанию 20%: если гость использует 4 ГБ, хост держит под него 4.8 ГБ, чтобы было пространство для роста без задержки на добавление.

Что получилось на практике

Тестовую группу составили из четырёх ВМ: два терминальных сервера 1С и два вспомогательных сервера. До SP1 каждому был выделен фиксированный объём - в сумме 32 ГБ на эту группу. Настроили Dynamic Memory со Startup = Minimum = 2 ГБ, Maximum - у терминальных серверов 12 ГБ, у вспомогательных 6 ГБ.

Первую неделю наблюдали плотно. Выводы:

Утренний пик обрабатывается нормально. Когда пользователи начинают подключаться к терминальным серверам 1С, хост динамически поднимает им память. Задержки с доставкой памяти не заметны в логах и не ощущаются пользователями. Хост успевает отреагировать раньше, чем гость начинает активно свопировать.

Ночью память возвращается в пул. К двум часам ночи терминальные серверы отдали обратно почти всё, что взяли сверх минимума. Физически это видно в Hyper-V Manager и в метриках хоста - доступная память хоста ночью заметно больше, чем до SP1.

Реальное пиковое потребление группы снизилось. До SP1 группа держала 32 ГБ постоянно. Теперь в пик группа берёт примерно 26-27 ГБ, в ночное время - около 12 ГБ. Это не магия экономии, это просто честное отражение реальной нагрузки вместо статического overprovisioning.

Плотность ВМ на кластере выросла. Высвободившееся пространство позволило добавить ещё несколько виртуалок, которые раньше не влезали в доступные ресурсы. По грубой оценке - около 25% больше ВМ на том же железе.

Что требует внимания

Не всё работает автоматически. Несколько вещей, с которыми пришлось разобраться:

Minimum RAM - важнее, чем кажется. Если поставить слишком низкий минимум, хост в момент нехватки ресурсов начнёт агрессивно урезать гостей. Для 1С-серверов с активными пользователями это заканчивается тормозами. Мы поставили минимум не меньше 50% от типичного рабочего потребления - это страховка от того, что хост начнёт отбирать память в самый неподходящий момент.

Memory Buffer надо калибровать. Дефолтные 20% работают нормально, но на терминальных серверах с непредсказуемым профилем нагрузки мы подняли до 25%. Ценой чуть большего overhead получаем более плавное поведение при всплесках.

Не все гостевые ОС поддерживают. Windows XP, Server 2003 - не работают с Dynamic Memory. У клиента несколько старых ВМ на XP осталось - они по-прежнему на статике. Смешанная конфигурация кластера вполне работает: часть ВМ на Dynamic Memory, часть на статике.

Live Migration и Dynamic Memory. При Live Migration ВМ между узлами кластера Dynamic Memory работает корректно - память мигрирует вместе с ВМ, минимум и максимум сохраняются. Проверили несколько раз специально.

Итог на этом этапе

Две недели на реальном кластере с 1С - результат положительный. Dynamic Memory работает так, как написано в документации: память выдаётся по потребности, возвращается когда не нужна, жёстких просадок по производительности гостей не зафиксировано.

Это не серебряная пуля и не замена нормального планирования мощностей. Если у тебя постоянно не хватает RAM на всех ВМ одновременно - Dynamic Memory не поможет, нужно железо. Но как инструмент для сглаживания неравномерной нагрузки - работает. VMware Balloon Driver делал похожее, и многие клиенты смотрели на ESXi именно из-за этой возможности. Теперь аналог есть в Hyper-V, и переходить ради этого на другой гипервизор смысла нет.

RemoteFX пока не трогали - нет подходящего стенда с нужным GPU на хостах. Поставим отдельно.