+7 (844) 245-94-88
pc@huananzhi.ru
Сервер для виртуализации: хост, на котором гипервизор (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 (рендеринг, тяжёлые расчёты). Для ВМ с интенсивными вычислениями долю ядер на машину нужно увеличивать, для ВМ с большими базами данных в первую очередь растёт объём ОЗУ, а не число потоков.
Overcommit CPU и RAM: когда можно и когда нельзя
Overcommit — это выделение виртуальным машинам ресурсов больше, чем есть в хосте физически. Гипервизор позволяет это делать, но с разными последствиями для CPU и памяти.
Для CPU overcommit безопасен благодаря планировщику: vCPU получают кванты времени. Типовые коэффициенты: 1:4–1:6 для веб-серверов, файловых сервисов, лёгких СУБД; 1:8–1:10 для VDI с одинаковой ОС и пиками в разное время. Для latency-sensitive нагрузок (биллинг, 1С с интенсивными блокировками, торговые системы) — не выше 1:2, лучше 1:1. Формула: сумма vCPU всех ВМ / физические ядра = коэффициент. Если он >6, растут задержки планировщика.
С памятью сложнее. Overcommit RAM реализуется через ballooning, KSM (дедупликация страниц) и swap гипервизора. Безопасно только для тестовых или одинаковых ВМ с большим объёмом неиспользуемой памяти. В продакшене, особенно под СУБД, 1С, кэширующие сервисы, overcommit RAM запрещён: это приводит к свопу хоста и падению отклика всех ВМ. Правило: сумма выделенной RAM не должна превышать физическую минус 2–4 ГБ на гипервизор.
- VMware ESXi: использует ballooning, KSM, Hypervisor Swap. Настройка резерваций памяти для критичных ВМ.
- Proxmox VE: KSM через KSM, ballooning через virtio-balloon, но при overcommit возможен OOM-killer.
- Hyper-V: Dynamic Memory — безопасный overcommit только для ВМ с указанным min/max RAM.
Вывод: CPU overcommit — норма, RAM overcommit — только в лаборатории или для некритичных ВМ с явным мониторингом.
Минимальные и рекомендуемые требования: дом и продакшен
Требования к серверу для виртуализации зависят от сценария. Для дома и лаборатории достаточно потребительской платформы, для продакшена — серверной с ECC и резервированием.
Дом / лаборатория. Минимум: 4 ядра (8 потоков) — Ryzen 5, Core i5; 32 ГБ DDR4 (не ECC); 1 NVMe 512 ГБ под систему и ВМ. Этого хватит на 3–5 лёгких ВМ (роутер, файловая, тестовая Windows). Рекомендуется: 8–16 ядер (Ryzen 7/9, Core i7/i9), 64–128 ГБ RAM, 2 NVMe (система + ВМ), 2.5/10 GbE. Позволяет запустить 10–15 ВМ, включая 1С и СУБД для тестов.
Продакшен. Минимум: 16 ядер (32 потока) — Xeon Silver, EPYC 7002; 128 ГБ DDR4 ECC; 2 SSD в RAID1 под гипервизор, 4+ NVMe в RAID10 под ВМ; 2 БП; 10 GbE. Тянет 10–15 ВМ малого бизнеса. Рекомендуется: 32–64 ядра (64–128 потоков) — Xeon Gold, EPYC 7003; 256–512 ГБ ECC; NVMe RAID с кэшем; 25 GbE; iDRAC/IPMI. Для 30–50 ВМ с СУБД и 1С.
| Параметр | Дом/лаборатория | Продакшен |
|---|---|---|
| CPU | 4–16 ядер | 16–64 ядра |
| RAM | 32–128 ГБ non-ECC | 128–512 ГБ ECC |
| Диски | 1–2 NVMe | RAID10 NVMe + RAID1 SSD |
| Сеть | 1–2.5 GbE | 2×10/25 GbE |
| БП | один | два с резервом |
Для продакшена ECC и IPMI не опциональны: без них ошибка памяти или зависание хоста кладут все ВМ, а удалённая перезагрузка недоступна.
Сетевые карты и виртуальные коммутаторы
Сеть в виртуализации — не только пропускная способность, но и задержки, и нагрузка на CPU. Виртуальный коммутатор (vSwitch в ESXi, Linux bridge/OVS в Proxmox, Hyper-V Virtual Switch) обрабатывает каждый пакет, и без аппаратных offload’ов это ложится на ядра хоста.
Ключевые технологии:
- SR-IOV — прямое проброс NIC в ВМ, обходит vSwitch, снижает CPU и задержки. Требует поддержки CPU (VT-d/AMD-Vi) и NIC.
- VMDq — очередь на карте для распределения трафика по ВМ.
- VirtIO / VMXNET3 — паравиртуальные драйверы, быстрее эмулированной e1000.
Для продакшена минимум — 2 порта 10 GbE (Intel X520/X710, Mellanox ConnectX-4). Разделяйте трафик: management, vMotion/live migration, iSCSI/NFS, VM traffic — разные VLAN или физические порты. 1 GbE хватает только для 2–3 ВМ без интенсивного обмена; для iSCSI или бэкапов он становится бутылочным горлышком.
Виртуальные коммутаторы: настройте jumbo frames (MTU 9000) для storage-сети, LACP для агрегации, но помните: LACP не ускоряет одну ВМ, только сумму потоков. В Proxmox OVS даёт больше функций (VLAN, QoS), но Linux bridge проще и быстрее. В ESXi vSwitch — стандарт, распределённый vDS нужен для кластера.
Если ВМ обмениваются трафиком внутри хоста, трафик идёт через vSwitch и consumes CPU. Для высоких нагрузок (балансировщики, кластеры БД) используйте SR-IOV или passthrough.
Примеры расчёта под конкретные ВМ: 1С, СУБД, терминалы, файлы
Расчёт ресурсов удобно вести по профилям ВМ, затем суммировать и добавлять запас.
- 1С + SQL (PostgreSQL/MS SQL). На 20–30 пользователей: 4–6 vCPU, 16–24 ГБ RAM, 100–200 ГБ NVMe. На 50–100: 8–12 vCPU, 32–64 ГБ RAM, NVMe RAID. Ключевое — диск: 1С чувствительна к latency, поэтому только SSD/NVMe, не HDD.
- СУБД (PostgreSQL, MySQL, MS SQL). Для 50–100 ГБ БД: 8 vCPU, 32 ГБ RAM (буферный пул 16–24 ГБ), 200 ГБ NVMe. Для 500+ ГБ: 16 vCPU, 64–128 ГБ RAM, NVMe RAID10. Overcommit RAM запрещён.
- Терминальный сервер (RDP). Windows Server + 15–20 пользователей: 4 vCPU, 16 ГБ RAM, 80 ГБ SSD. На каждого следующего пользователя +0.2 vCPU и +0.5 ГБ RAM. Для 50 пользователей: 8 vCPU, 32 ГБ RAM.
- Файловый сервер (SMB/NFS). 2–4 vCPU, 8–16 ГБ RAM, диски по объёму (HDD RAID + SSD кэш). Пропускная способность важнее ядер.
Пример: хост для 1С (8 vCPU, 32 ГБ), СУБД (8 vCPU, 64 ГБ), терминалов (8 vCPU, 32 ГБ), файлов (2 vCPU, 8 ГБ) и двух тестовых (2 vCPU, 4 ГБ). Сумма: 28 vCPU, 144 ГБ RAM, ~1 ТБ NVMe. Добавляем резерв 30% и 4 ГБ на гипервизор: получаем 36 vCPU, 192 ГБ RAM. При overcommit CPU 1:2 достаточно 18 физических ядер (36 потоков), но RAM — 192 ГБ без overcommit. Это конфигурация уровня Xeon Silver 4210 + 256 ГБ ECC.
Готовые конфигурации в нашем каталоге
В каталоге серверы для виртуализации есть готовые 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 хоста расчётом чётности.
Частые вопросы
Можно ли переподписывать ОЗУ хотя бы немного, как ядра?
Чем отличаются требования Proxmox VE от VMware ESXi по железу?
Нужен ли отдельный диск под систему гипервизора?
Как понять, что серверу для виртуализации не хватает ресурсов?
Что из этого можно купить
В наличии, с доставкой по России
