Сколько виртуальных машин потянет сервер: практический расчёт

Почему нет универсального ответа — и как устроен расчёт

Для справки о верхней границе: для Hyper-V в Windows Server 2025 Microsoft декларирует до 1 024 одновременно работающих виртуальных машин и до 2 048 виртуальных процессоров на хост. Эти лимиты — справочный предел платформы, а не цель sizing: план строится от физических ресурсов конкретного сервера — ядер, памяти и производительности дисков.

Поэтому вопрос «сколько ВМ потянет сервер» на самом деле звучит иначе: хватит ли конкретного набора ядер, памяти и дисков под конкретный список нагрузок. Одна виртуальная машина с нагруженной СУБД занимает больше ресурсов, чем десять лёгких служебных сервисов. Отсюда и разброс честных ответов для одного и того же сервера: итог определяет состав списка нагрузок.

Расчёт устроен как пять последовательных шагов: инвентаризация будущих ВМ с профилями ресурсов → бюджет vCPU через коэффициент консолидации → бюджет памяти без переподписки → проверка дисков по IOPS и латентности → запас на рост и отказоустойчивость. Дальше разберём каждый шаг, а в конце соберём всё в сквозной пример.

Важная оговорка: расчёт на бумаге даёт стартовую конфигурацию, а подтверждает её только нагрузка. Все коэффициенты ниже — стартовые допущения расчёта: после запуска плотность проверяется метриками гипервизора, о них — в конце статьи.

И про границы темы. Эта статья — про подготовку входных данных и понимание итога; сам предварительный расчёт за вас выполнит калькулятор из лида. А выбор конкретной аппаратной платформы под готовый итог — процессоры, платформа, вендор — отдельная задача, разобранная в статье о выборе сервера для виртуализации.

Шаг 1. Инвентаризация: профили будущих ВМ

Первый шаг — список: какие виртуальные машины должны работать на сервере и к какому классу нагрузки относится каждая. Для малого и среднего бизнеса почти весь парк складывается из шести типовых профилей:

Размеры в таблице — стартовые допущения для расчёта; если у приложения есть системные требования вендора (1С, СУБД, почтовый сервер), в план идут они. Для узлов сеансов AVD/RDS Microsoft публикует отдельные стартовые оценки плотности: 6 пользователей на vCPU при лёгкой офисной работе, 4 — при средней, 2 — при тяжёлой и 1 vCPU на пользователя для «power»-профиля; сами машины рекомендуется держать в диапазоне 4–24 vCPU и не раздувать сверх 32 ядер. Это ориентиры конкретного сценария узла сеансов, а не универсальное правило для любого терминального сервера.

Итог шага — таблица «имя ВМ → vCPU → память → диск и характер ввода-вывода». Уже на этом этапе видно главное: какие машины требуют гарантированных ресурсов (СУБД, терминалы), а какие спокойно уплотняются.

Шаг 2. vCPU: ядра, потоки и коэффициент консолидации

Бюджет процессора считается по физическим ядрам, а не по потокам. SMT и Hyper-Threading показывают операционной системе вдвое больше логических процессоров, но два потока делят исполнительные блоки одного ядра — это ускорение параллельных задач, но не второе ядро. Считать бюджет по потокам — прямой путь к «на бумаге всё влезает, по факту всё тормозит».

Дальше работает главный механизм виртуализации — консолидация: суммарное число vCPU всех машин может превышать число физических ядер, потому что нагрузки редко пикуют одновременно. Планировщик гипервизора распределяет процессорное время между машинами — вопрос лишь в том, насколько плотно можно уплотнять. Стартовые допущения этой методики:

1:1 — без переподписки — для чувствительных к задержкам машин: СУБД, сервер 1С, нагруженная телефония. Их vCPU резервируются в бюджете ядер полностью: цена простоя выше экономии на ядрах.

2:1–3:1 — для рабочих нагрузок общего профиля: терминальные серверы, бизнес-приложения, почта, файловые серверы. Допустимость такой переподписки определяется требованиями конкретной нагрузки и подтверждается после запуска по CPU ready и задержкам.

4:1–5:1 — для лёгких и эпизодических машин: инфраструктурные роли, тестовые среды, дев-стенды. Плотная упаковка, оправданная редкими пиками.

Эти коэффициенты — стартовая гипотеза, которую после запуска проверяет одна метрика: CPU ready — доля времени, когда виртуальная машина готова исполнять код, но ждёт свободного физического ядра. База знаний VMware (Broadcom) прямо называет норму: в штатном режиме ready time должен оставаться ниже 5%, а при систематическом превышении рекомендует либо добавить физических CPU, либо сократить суммарное число vCPU на хосте. Подробнее о метриках — в разделе про контроль.

Два практических правила напоследок. Первое, стартовое: держите виртуальную машину в пределах NUMA-узла — физических ядер одного процессора: обращения к памяти соседнего узла медленнее. Современные гипервизоры умеют пробрасывать гостю vNUMA-топологию, и большие ВМ возможны — но это осознанная настройка под конкретную платформу и нагрузку, а не значение по умолчанию. Второе: выдавать vCPU «на вырост» вредно — Microsoft в рекомендациях по узлам сеансов AVD/RDS отмечает, что с ростом числа ядер растут накладные расходы на синхронизацию, и две машины по 16 vCPU работают лучше одной на 32. Выбор самих процессоров — поколения, ядра, частоты — отдельная тема: разбор в гайде по серверным процессорам AMD EPYC и Intel Xeon.

Шаг 3. Память: сумма ВМ плюс резерв гипервизора

С памятью правило противоположное процессорному: на старте — никакой переподписки. Память, в отличие от процессорного времени, не «дозируется» планировщиком безболезненно: когда физической памяти не хватает, гипервизор начинает отбирать её у машин (ballooning) или сбрасывать страницы в своп — производительность затронутых машин деградирует, а под сильным давлением памяти страдает весь хост. Kingston формулирует это прямо: памяти на хосте должно хватать для самой платформы виртуализации и для всех виртуальных машин с их приложениями, а при достаточном объёме физической памяти влияние механизмов экономии сводится к минимуму. Эти механизмы — страховка на аварийный случай; закладывать их в план не стоит.

Бюджет считается простой суммой: память всех ВМ из инвентаризации плюс резерв самого хоста. В резерв входят гипервизор с управляющей ОС и накладные расходы на каждую работающую машину (структуры данных, видеопамять виртуальных устройств): в расчёте этой статьи закладываем как стартовое допущение 4–8 ГБ на гипервизор и добавку порядка сотен мегабайт на каждую ВМ — точные значения зависят от платформы и уточняются по её документации.

Три правила, которые уберегут от типовых проблем:

Считайте сумму по пикам. Если все машины включены одновременно — а в малом бизнесе это норма, — их память должна помещаться в физическую целиком.

Используйте поддерживаемую платформой ECC-конфигурацию памяти (регистровую или небуферизованную — по требованиям платформы): хост виртуализации консолидирует много сервисов, поэтому цена некорректируемой ошибки памяти здесь выше, чем у одиночного сервера.

Заполняйте каналы памяти по правилам платформы. Пропускная способность памяти зависит от того, как модули распределены по каналам; правила установки (population rules) у каждой серверной платформы свои и описаны в её руководстве. Типовая ошибка — «добить объём одним модулем», оставив каналы незаполненными: дешевле при покупке, дороже в работе. Как выбирать серверную память — типы модулей, ранги, частоты и совместимость — в пошаговом гайде по серверной оперативной памяти.

Шаг 4. Диски: считаем IOPS и латентность

Дисковая подсистема — частый «тихий» ограничитель: ёмкости хватает с запасом, а виртуальные машины ползают. Причина в том, что при консолидации на одном хранилище встречаются десятки потоков ввода-вывода, и важна не ёмкость, а сколько операций в секунду (IOPS) и с какой задержкой выдерживает массив под смешанной нагрузкой случайного доступа.

Оценка на этапе плана делается качественно, по профилям из инвентаризации: СУБД и 1С дают интенсивный случайный ввод-вывод мелкими блоками и чувствительны к латентности; терминальные серверы — всплески при массовом входе пользователей; файловые — последовательное чтение и запись крупными блоками; инфраструктурные роли дисков почти не нагружают. Чем больше в плане машин первых двух профилей, тем жёстче требования к хранилищу.

Практические правила для малого и среднего бизнеса:

Под смешанную нагрузку виртуализации — SSD. Массив жёстких дисков, отлично отдающий последовательный поток, под случайным вводом-выводом десятков ВМ деградирует на порядки; на HDD в таких схемах остаются резервные копии и «холодные» архивы.

Учитывайте цену записи RAID. Массивы с чётностью обслуживают мелкую случайную запись по схеме read-modify-write: перед записью блока читается и пересчитывается чётность, поэтому каждая такая запись оборачивается несколькими дополнительными операциями на дисках — случайная запись на RAID 5/6 заметно дороже, чем на зеркале; при последовательной записи полными страйпами эффект меньше. Под нагрузки с интенсивной случайной записью зеркальные конфигурации предпочтительнее массивов с чётностью.

Разделяйте нагрузки. Система и данные СУБД на быстром массиве, файловые тома — на ёмком, резервные копии — всегда на отдельном устройстве, отдельно от хранилища рабочих ВМ. Выбор класса хранилища — внутренние диски, DAS, NAS или SAN — и разбор уровней RAID: в гайде по выбору СХД.

Шаг 5. Запас на рост и отказоустойчивость

План, посчитанный «впритык», начинает устаревать сразу после запуска: появляются новые сервисы, растут базы, добавляются сотрудники. Стартовое допущение этого расчёта — 60–80% целевой загрузки ядер и памяти: оставшиеся 20–40% — место под рост, пики и миграции без пересборки сервера. Второй резерв — свободные слоты: сервер с незанятыми разъёмами памяти и дисковыми отсеками расширяется добавлением модулей и дисков, полностью забитый — только заменой платформы.

Отдельный вопрос — что произойдёт при отказе. Один хост, каким бы мощным он ни был, — это одна точка отказа для всех виртуальных машин сразу: выход сервера из строя останавливает все размещённые на нём сервисы одновременно. Когда простой критичен, план меняется структурно: два хоста и общая логика N+1 — каждый узел должен уметь принять нагрузку соседа, то есть суммарная загрузка пары держится в пределах ёмкости одного узла. Это заметно увеличивает бюджет на железо, поэтому решение принимается от цены часа простоя, а не «на всякий случай». Как устроена высокая доступность серверной инфраструктуры — уровни резервирования, кластеры, автоматическое восстановление — в отдельном разборе.

И не забудьте про резервное копирование: снапшоты и отказоустойчивость копий не заменяют — план хранения копий ВМ строится по своим правилам, о них — в хабе «Резервное копирование».

Сквозной пример: сервер 32 ядра / 256 ГБ

Соберём методику в цифры. Дано: двухсокетный сервер, 2 процессора по 16 ядер (32 физических ядра, 64 потока), 256 ГБ ECC-памяти, SSD-массив в RAID 10 под рабочие данные. План компании на 60–70 сотрудников — ниже; все числа условные и показывают только арифметику метода.

Читаем результат. По процессору план здоровый: 56 vCPU на 32 ядра — средняя консолидация 1,75:1, бюджет ядер занят на 76%, запас на пики и рост есть. А вот память уже на пределе: 232 ГБ по машинам плюс резерв гипервизора — ≈246 из 256 ГБ. Вывод расчёта: этот сервер тянет 12 запланированных ВМ, но первым ограничителем роста станет память — следующая ВМ потребует либо добавить модули (если есть свободные слоты), либо пересматривать раскладку. Так и должен работать расчёт: он заранее показывает, какой ресурс именно вашего плана исчерпается первым.

Подобрать сервер под итог расчёта — с ядрами, памятью и дисками из вашей раскладки — можно в разделе серверов каталога ANDPRO.

Семь типовых ошибок расчёта

Каждая из этих ошибок выглядит безобидно на этапе плана — и проявляется уже под рабочей нагрузкой:

Как понять, что сервер «кончился»: метрики

Расчёт даёт стартовую раскладку, а живёт она под контролем метрик гипервизора. Смотреть стоит на четыре сигнала:

CPU ready — главный индикатор переподписки процессора: сколько времени машина ждала свободного ядра. Ориентир из базы знаний VMware (Broadcom): в норме — ниже 5%; систематически выше — пора либо добавлять физические CPU, либо сокращать суммарные vCPU на хосте, начиная с машин, которым ядра выданы «на вырост».

Давление на память — сработавший ballooning или своп гипервизора. Любое устойчивое появление этих механизмов означает, что физическая память исчерпана и план требует пересмотра: это именно та ситуация, которой расчёт «без переподписки» должен был не допустить.

Латентность хранилища — задержки операций ввода-вывода на томах с рабочими машинами: рост задержек при свободной ёмкости — классический признак исчерпания IOPS массива.

Динамика роста — сигнал, который легко пропустить: если загрузка памяти устойчиво растёт от замера к замеру, вопрос «когда расширяться» уже решён — осталось выбрать способ: добавить модули и диски, вынести часть нагрузок на второй сервер или перейти к кластеру.

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

Частые вопросы