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

Сервер для виртуализации: хост, на котором гипервизор (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 виртуальных машин

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

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

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

Цифры в таблице: ориентир для типовой офисной и корпоративной нагрузки без экстремальных требований к 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.

Автор статьи