Сервер для виртуализации: сколько ядер и памяти нужно

Сервер для виртуализации: хост, на котором гипервизор (VMware ESXi, Proxmox VE или Hyper-V) одновременно исполняет несколько виртуальных машин, деля между ними ядра, память и диски одного комплекта железа. В отличие от рабочей станции с одной ОС, ресурсы здесь считаются сразу на пул ВМ, и ошибка расчёта бьёт по всем сервисам хоста. Ниже: сколько ядер и ОЗУ закладывать под виртуализацию, почему память обычно упирается раньше CPU и какую роль играют ECC и дисковый массив.

Зачем виртуализации выделенный сервер, а не обычный ПК

Десктопное железо технически способно запустить гипервизор, но не рассчитано на непрерывную нагрузку нескольких ВМ. У серверных платформ три отличия, напрямую влияющие на стабильность виртуальной инфраструктуры:

Поддержка ECC-памяти: десктопные чипсеты и большинство потребительских процессоров её не поддерживают, а без коррекции ошибок сбой в памяти способен уронить сразу несколько ВМ.
Много каналов памяти и линий PCIe: платформы вроде X99 дают 8 каналов DDR4 на 2 процессора и достаточно линий PCIe под RAID-контроллер, сеть и накопители одновременно.
Резерв по питанию и охлаждению: серверные корпуса и блоки питания рассчитаны на непрерывную работу 24/7, а не на несколько пиковых часов в день.

Двухпроцессорная платформа LGA 2011-3 с парой Xeon E5 v4 закрывает эти требования и остаётся экономичным вариантом консолидации ВМ: до 44 ядер (88 потоков) на топовых моделях серии, 8 каналов DDR4 ECC REG и линии PCIe для аппаратного RAID.

Что важнее: ядра или память

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

Принцип «не переподписывать» CPU и RAM

Переподписка (overcommit) ядер: рабочая практика, соотношение vCPU к потокам 2:1–4:1 для смешанной офисной нагрузки, поскольку редко все ВМ одновременно упираются в процессор. С памятью рисковать не стоит:

Переподписка RAM ведёт к подкачке на уровне гипервизора, а это на порядок медленнее физической памяти и просаживает отклик сразу у всех ВМ хоста.
Для баз данных, 1С и терминальных серверов лучше держаться ближе к 1:1–2:1, поскольку эти нагрузки чувствительны к задержкам планировщика.
Правило по умолчанию: сумма RAM всех ВМ плюс резерв гипервизора не должна превышать физическую RAM хоста; ядра, в отличие от памяти, можно распределять с запасом гибко.

При выборе конфигурации в разделе серверы для виртуализации в первую очередь стоит смотреть на объём и тип памяти, а число ядер подбирать под совокупную вычислительную нагрузку профиля ВМ.

Почему для виртуализации нужна ECC-память

ECC (Error-Correcting Code), память с аппаратной коррекцией однобитных ошибок и обнаружением двухбитных, обязательная для хостов с несколькими одновременно работающими ВМ. Любая некорректированная ошибка на таком сервере затрагивает не одно приложение, а все машины, использующие этот регион RAM или общий пул гипервизора.

Для двухпроцессорных серверов применяется DDR4 ECC REG (registered): регистровые модули снижают электрическую нагрузку на контроллер памяти процессора и позволяют собирать конфигурации на 128–256 ГБ и выше без потери стабильности. Разница между обычной и серверной памятью и почему для виртуализации ECC REG обязательна, разобрана отдельно: что такое ECC-память, ECC REG vs обычная. Подбор модулей под конкретную плату: раздел оперативная память.

Быстрый отказоустойчивый диск для хоста виртуализации

Дисковая подсистема, второе по значимости узкое место после памяти, особенно при нескольких ВМ с активным вводом-выводом. Требования к хранилищу виртуализации отличаются от требований рабочей станции по трём пунктам:

SSD вместо HDD: при параллельном обращении нескольких ВМ к одному массиву случайный доступ на HDD деградирует кратно сильнее последовательного, а гипервизор как раз и генерирует случайную нагрузку вперемешку от разных машин.
RAID для отказоустойчивости: отказ одного диска не должен останавливать все ВМ хоста; массив 5/6/10 из нескольких SSD даёт запас и по надёжности, и по суммарной пропускной способности.
Аппаратный RAID-контроллер: снимает с CPU хоста вычисление чётности и держит батарейный/флеш-кеш для сохранности данных при отключении питания, в отличие от программного RAID на стороне гипервизора.

В готовых конфигурациях HUANANZHI это реализовано на связке SSD Intel S4510 (серверные накопители под смешанную нагрузку чтения и записи) и аппаратного контроллера HP P840 с собственным кешем: массив собирается и тестируется на заводе перед отгрузкой.

Требования гипервизоров: VMware ESXi, Proxmox VE, Hyper-V

Три платформы виртуализации предъявляют схожие требования к железу; различия скорее в лицензировании и экосистеме, чем в базовых аппаратных потребностях.

VMware ESXi

Требует процессор с аппаратной виртуализацией (Intel VT-x с EPT) из списка совместимости VMware; серверные Xeon E5 v4 в нём присутствуют. ESXi ставится на отдельный носитель (USB/SD или SSD), оставляя весь RAID-массив под датастор ВМ, и лицензируется по числу процессоров на хосте, что делает двухпроцессорную платформу предсказуемой единицей масштабирования.

Proxmox VE

Опенсорсный гипервизор на базе Debian и KVM: платформа бесплатна, лицензируется только опциональная подписка на репозиторий обновлений. Поддерживает полную виртуализацию (KVM) и контейнеры LXC с меньшими накладными расходами по памяти для сервисов без отдельной гостевой ОС. Требования к CPU и памяти совпадают с ESXi; встроена поддержка ZFS для программного RAID, хотя для нагруженных сценариев аппаратный контроллер с батарейным кешем предпочтительнее.

Hyper-V

Роль Windows Server или отдельный Hyper-V Server требует процессор с поддержкой SLAT: у современных Xeon она есть. Плотно интегрируется со стеком Microsoft (Active Directory, System Center), что удобно при инфраструктуре на Windows Server. Требования к памяти и диску идентичны предыдущим платформам: RAM как жёсткий лимит на сумму ВМ, RAID из SSD под виртуальные диски VHDX.

Практический расчёт ресурсов на N виртуальных машин

Определить профиль ВМ. Файловый сервер и веб-сервис требуют мало CPU, но заметный объём ОЗУ под кеш; сервер БД, наоборот, активно читает диск и требует памяти под буферный пул; терминальный сервер считается по числу параллельных сессий, обычно 1–2 ГБ ОЗУ на пользователя плюс общесистемный запас.
Просуммировать ядра и ОЗУ по всем ВМ с учётом переподписки CPU (2:1–4:1 для лёгкой нагрузки) и без переподписки ОЗУ.
Добавить резерв гипервизора: обычно 8–16 ГБ ОЗУ и 2–4 потока CPU сверх суммы ВМ на служебные процессы, снапшоты и миграции.

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

Таблица масштабирования: профиль нагрузки → ресурсы хоста

Число ВМ	Типовой профиль	Ядра/потоки хоста	ОЗУ хоста	Диск (SSD, RAID)
3–5	Файловый сервер, 1С-сервер, контроллер домена	16–24 потока	64–96 ГБ	2× SSD 1 ТБ, RAID 1
6–10	Смешанный пул: веб, почта, терминальные сессии, тестовые стенды	32–48 потоков	128 ГБ	4× SSD 2 ТБ, RAID 5/10
10–15	Плотная консолидация офисной инфраструктуры плюс 1–2 нагруженные СУБД	48–64 потока	192–256 ГБ	6× SSD 2 ТБ, RAID 10
15+	Корпоративная консолидация, кластер из нескольких хостов	64–80 потоков на хост	256 ГБ и выше на хост	6+ SSD 2 ТБ, RAID 10, резервный хост

Цифры в таблице: ориентир для типовой офисной и корпоративной нагрузки без экстремальных требований к CPU (рендеринг, тяжёлые расчёты). Для ВМ с интенсивными вычислениями долю ядер на машину нужно увеличивать, для ВМ с большими базами данных в первую очередь растёт объём ОЗУ, а не число потоков.

Готовые конфигурации в нашем каталоге

В каталоге серверы для виртуализации есть готовые 2U-серверы HUANANZHI на плате X99 с двумя процессорами Intel Xeon E5 v4 (LGA 2011-3), памятью DDR4 ECC REG и SSD Intel S4510 в RAID на аппаратном контроллере HP P840. Платформа закрывает требования VMware ESXi, Proxmox VE и Hyper-V без доработок.

2× Intel Xeon E5-2697 v4 (36 ядер, 72 потока суммарно), 128 ГБ DDR4 ECC REG, 4× SSD 2 ТБ в RAID, от 521 952 ₽. Закрывает профиль на 6–10 ВМ смешанной офисной нагрузки из таблицы выше.
2× Intel Xeon E5-2698 v4 (40 ядер, 80 потоков суммарно), 256 ГБ DDR4 ECC REG, 6× SSD 2 ТБ в RAID. Подходит для плотной консолидации 10–15+ ВМ или для хоста, где к пулу ВМ добавлена одна-две нагруженные базы данных.

Процессоры и модули памяти для апгрейда существующего сервера или сборки нестандартной конфигурации: разделы серверные процессоры и оперативная память.

Заключение

Ключевое решение при выборе сервера для виртуализации: не гнаться за максимальным числом ядер, а сначала закрыть объём ОЗУ под сумму профилей всех ВМ без переподписки, добавить ECC REG для устойчивости к ошибкам памяти и собрать дисковый массив из SSD на аппаратном RAID-контроллере. Ядра допустимо распределять с переподпиской 2:1–4:1 для лёгкой нагрузки, но для баз данных и терминальных серверов держаться ближе к 1:1–2:1. Двухпроцессорная платформа X99 на Xeon E5 v4 со 128–256 ГБ DDR4 ECC REG закрывает большинство сценариев консолидации от 5 до 15+ ВМ на VMware ESXi, Proxmox VE или Hyper-V. Подобрать готовую конфигурацию под свой профиль нагрузки или уточнить расчёт под конкретное число ВМ можно в разделе серверы для виртуализации HUANANZHI.

Совет на практике

Перед закупкой железа выпишите не «сколько у нас серверов сейчас», а профиль каждой будущей ВМ отдельно: ядра, ОЗУ, тип нагрузки (CPU-bound или I/O-bound). Суммарная память по факту почти всегда оказывается больше, чем кажется на глаз, потому что гостевые ОС и службы съедают ресурсы даже в простое.

Частые ошибки при выборе сервера для виртуализации

Переподписывают память так же смело, как ядра, рассчитывая на «динамическое перераспределение»: в результате гипервизор уходит в подкачку, и тормозят сразу все ВМ хоста, а не одна.
Берут десктопный процессор без поддержки ECC ради экономии, не понимая, что единичная ошибка памяти на таком хосте способна затронуть сразу несколько виртуальных машин одновременно.
Не закладывают резерв гипервизора (8-16 ГБ ОЗУ, 2-4 потока CPU) сверх суммы ресурсов ВМ, и в моменте пиковой нагрузки не хватает памяти даже на снапшот или миграцию.
Собирают программный RAID средствами гипервизора вместо аппаратного контроллера с батарейным кешем, экономя на контроллере, но теряя в отказоустойчивости и нагружая CPU хоста расчётом чётности.

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

Можно ли переподписывать ОЗУ хотя бы немного, как ядра?

Технически гипервизоры это позволяют, но на практике переподписка памяти приводит к подкачке на уровне хоста, которая на порядок медленнее физической RAM. Для предсказуемой работы сумма памяти всех ВМ плюс резерв гипервизора не должна превышать физический объём хоста.

Чем отличаются требования Proxmox VE от VMware ESXi по железу?

Базовые требования к CPU и памяти практически идентичны, разница в лицензировании и экосистеме. Proxmox VE бесплатен и опционален по подписке на обновления, ESXi лицензируется по числу процессоров на хосте.

Нужен ли отдельный диск под систему гипервизора?

Для ESXi это стандартная практика: гипервизор ставится на отдельный носитель (USB/SD или небольшой SSD), а весь RAID-массив полностью отдаётся под датастор виртуальных машин. Для Proxmox и Hyper-V так делать не обязательно, но тоже удобно с точки зрения обслуживания.

Как понять, что серверу для виртуализации не хватает ресурсов?

Первый сигнал: рост задержек отклика внутри ВМ при нормальной загрузке CPU хоста, это обычно означает нехватку памяти и начало подкачки. Второй сигнал: снапшоты и миграции ВМ занимают заметно больше времени, чем раньше, это говорит о нехватке резерва гипервизора.