Подбор сервера для виртуализации начинается не с числа ядер и не с объёма памяти, а с измерения нагрузки и требований к доступности. Оценить необходимо CPU и RAM виртуальных машин, NUMA, производительность хранения, сеть, совместимость гипервизора и способность кластера продолжать работу при отказе узла.
Исследовательская база: 2020–2026 годы · Дата проверки материала: · Материал не заменяет проектирование конкретной инфраструктуры.
С чего начинается подбор сервера
Прежде чем выбирать процессоры, соберите инвентаризацию ВМ и измерения в репрезентативный период: обычные рабочие дни, расчётные пики, резервное копирование и специальные нагрузки. Отдельно отметьте критичные сервисы и планы роста.
| Что измерять | Минимальные данные | Почему это важно |
|---|---|---|
| Виртуальные машины | Количество ВМ, роли, vCPU, выделенная и фактически используемая RAM | Роли и степень одновременной загрузки различаются |
| CPU | Среднее и пиковое потребление, p95/p99, CPU Ready/steal, длительность пиков | Нужно оценить contention и запас производительности |
| Хранение | Полезный объём, рост, read/write IOPS, размер блока, latency, пропускная способность | Ёмкость и производительность — разные задачи |
| Сеть | VM traffic, storage, backup, live migration, replication | Разные типы трафика конкурируют за пропускную способность |
| Отказоустойчивость | Критичность, допустимые RPO/RTO, отказ узла/стойки/площадки | От этого зависит архитектура, а не только конфигурация сервера |
Не существует универсальной формулы «20 ВМ = 256 ГБ RAM» или «4 vCPU на одно ядро». Эти числа без данных о нагрузке не являются инженерным расчётом.
CPU, vCPU и overcommit
Физическое ядро, логический поток SMT и vCPU — разные сущности. Два SMT-потока одного ядра разделяют часть исполнительных ресурсов и не равны двум физическим ядрам. Гипервизор планирует выполнение vCPU на физических вычислительных ресурсах.
CPU overcommit означает, что суммарное количество назначенных vCPU может превышать количество физических ядер, доступных хосту. Это работает, пока виртуальные машины не требуют весь выделенный CPU одновременно.
| Профиль нагрузки | Что учитывать при выборе CPU | Отношение к overcommit |
|---|---|---|
| Инфраструктурные службы, малонагруженные приложения | Параллельность, средний CPU, пиковая одновременность | Возможен больший коэффициент — после измерений |
| 1С, СУБД, latency-sensitive приложения | Производительность одного ядра, задержки и лицензирование | Нужна более осторожная политика |
| VDI, тестовые и пакетные задачи | Число одновременных сессий и пики | Зависит от расписания нагрузки и SLA |
В документации RHEL 9 Red Hat приводит ориентир около 5 vCPU на одно физическое ядро при нагрузке ниже 100% и не рекомендует более 10 выделенных vCPU на ядро. Это рекомендация для RHEL/KVM, а не общий отраслевой норматив. Источник: Red Hat.
Для VMware ESXi 8 Broadcom рекомендует оценивать CPU Ready и Co-Stop наряду с использованием CPU. Значения CPU Ready порядка 5–10% на vCPU требуют внимания; это ориентиры ESXi, а не универсальный SLA. Источник: Broadcom.
96 назначенных vCPU на 24 физических ядрах дают формальный коэффициент 4:1. Это не доказывает, что производительности хватит: 96 vCPU могут быть почти неактивны либо одновременно обслуживать тяжёлые СУБД.
NUMA и оперативная память
NUMA — архитектура, при которой задержка доступа к памяти зависит от того, к какому NUMA-узлу она подключена. Для крупной ВМ с активным использованием памяти важно учитывать локальность CPU и RAM; большое количество сокетов само по себе не гарантирует ускорения.
Для критичных ВМ расчёт RAM должен учитывать не только память гостевых ОС, но и расходы гипервизора, служб управления, хранения и резерв на отказ узла. Overcommit памяти может вызвать ballooning, swap и нехватку RAM во время пика или аварийного перезапуска.
RAM хоста ≥ RAM ВМ + гипервизор + управление + сервисы хранения + резерв HA- Проверьте объём фактически необходимой RAM, а не только суммарно назначенной ВМ.
- Учитывайте NUMA-топологию, каналы памяти, правила заполнения DIMM и потенциал расширения.
- Не рассчитывайте ресурсы хоста из условия, что вся RAM может быть предоставлена ВМ.
- При CPU/GPU passthrough и SR-IOV уточняйте ограничения конкретной платформы на миграцию и распределение памяти.
Подробно о каналах, ECC и RDIMM — в статье «Оперативная память сервера».
СХД: ёмкость и производительность
Для виртуализации нужно рассчитывать два разных показателя: полезную ёмкость дисков и производительность операций ввода-вывода. Большая ёмкость не гарантирует высокие IOPS, а рекламное значение IOPS без профиля нагрузки малоинформативно.
| Параметр | Что означает | Что фиксировать в ТЗ |
|---|---|---|
| IOPS | Операций ввода-вывода в секунду | Размер блока, read/write, random/sequential, queue depth |
| Latency | Время ответа операции | Среднее и p95/p99, особенно для СУБД |
| Throughput | Объём данных за секунду | MB/s или GB/s для backup и миграции |
| Capacity | Полезный объём хранения | Текущие данные, рост, snapshots, запас и накладные расходы |
| Архитектура | Плюсы | Риски и условия |
|---|---|---|
| Локальные диски | Простота, потенциально малая задержка | Для HA/миграции требуется дополнительная архитектура репликации или перемещения дисков |
| Общая СХД — SAN/NAS | Общий доступ к данным ВМ для нескольких хостов | Пути, контроллеры, коммутаторы и СХД не должны оставаться единичными точками отказа |
| HCI / распределённое хранение | Объединение вычислений и хранения | Ceph/аналоги конкурируют с ВМ за CPU, RAM, диски и сеть; нужен резерв на rebalance |
RAID выбирают по профилю записи, отказоустойчивости и времени восстановления, а не по правилу «виртуализация — значит RAID 10». RAID не заменяет резервное копирование. См. RAID 1/5/6/10 и NVMe, SAS и SATA.
Сеть хостов виртуализации
Сеть должна поддерживать трафик самих ВМ, доступ к хранилищу, перенос ВМ, резервное копирование, управление и кластерные механизмы. Необязательно выделять физический порт для каждого класса, но изоляцию, QoS и резервирование нужно проектировать отдельно.
| Класс трафика | Назначение | Основной риск |
|---|---|---|
| Management / OOB | Управление гипервизором и BMC | Недоступность администрирования и аварийного доступа |
| VM traffic | Сервисы и пользователи | Конкуренция с хранилищем и миграцией |
| Storage | iSCSI, NFS, Ceph, NVMe-oF и др. | Задержки и потеря пропускной способности |
| Live migration | Перенос памяти и состояния ВМ | Долгая миграция, влияние на рабочий трафик |
| Backup / replication | Копии и репликация | Пики передачи данных и перегрузка линков |
1GbE может подходить для управления и лёгких сценариев, но не следует автоматически считать его достаточным для производственного storage и миграций. Выбор 10/25/40/100GbE зависит от нагрузки, дисковой архитектуры и числа одновременных операций.
Два порта 25GbE в LACP не гарантируют 50 Гбит/с для одного TCP-потока: балансировка зависит от хеширования и поведения конкретной сети.
Кластер, quorum и HA
Кластер — это не просто несколько физических серверов. Нужно спроектировать членство в кластере, quorum/witness, fencing, хранение, резервирование сети и запас ресурсов. Механизм HA обычно обнаруживает отказ узла и перезапускает защищённые ВМ на другом узле. Это не означает нулевой простой.
| Вопрос | Что проверить |
|---|---|
| Два или три узла? | Требования конкретного гипервизора и хранилища; универсального минимума нет |
| Quorum / witness | Как система предотвращает split-brain при разделении сети |
| Fencing | Как исключается одновременная запись двух конфликтующих узлов |
| Ресурс N+1 | Хватит ли CPU и RAM у оставшихся узлов после отказа |
| Единичные точки отказа | Контроллер СХД, коммутатор, питание, сеть управления, кабель |
Например, Windows Failover Clustering поддерживает двухузловые конфигурации с правильно настроенным witness. Для других продуктов, включая SpaceVM и решения на Ceph, требования к числу узлов могут отличаться. Документация Microsoft.
ProtectedDemand ≤ (N − F) × CapacityNode × TargetUtilizationЗдесь N — число одинаковых узлов, F — сколько отказов требуется пережить, CapacityNode — полезная ёмкость узла в одной и той же метрике, TargetUtilization — допустимая загрузка после отказа. Эта формула — инженерная модель, не обязательное требование платформы.
Три одинаковых узла по 100 условных вычислительных единиц, резерв на отказ одного, целевая загрузка после отказа 80%. Допустимая защищённая нагрузка: (3 − 1) × 100 × 0,8 = 160 единиц. Нагрузка 190 единиц в эту модель N+1 не помещается.
Live migration, backup и DR
Live migration переносит работающую ВМ между хостами с минимальным простоем, но сама по себе не доказывает наличие HA: в Hyper-V миграция возможна и без failover-кластера. Перемещение зависит от доступности хранения, сети, совместимости CPU и объёма изменяемых страниц памяти.
| Механизм | Какую проблему решает | Чего не гарантирует |
|---|---|---|
| Live migration | Плановое обслуживание и распределение нагрузки | Автоматический запуск ВМ после аварии |
| HA | Восстановление сервиса при отказе узла | Нулевой простой, сохранность данных при катастрофе |
| Replication | Копия ВМ/данных в другом месте | Независимая точка восстановления вместо backup |
| Backup | Восстановление данных из независимых копий | Мгновенное переключение без простоя |
| Disaster Recovery | Восстановление после крупной аварии | Отсутствие потерь без заданных RPO/RTO |
RPO задаёт допустимую потерю данных во времени; RTO — целевую длительность восстановления сервиса. Их необходимо определить до выбора архитектуры, иначе требование «отказоустойчивый сервер» не имеет точного инженерного смысла. См. резервное копирование и восстановление.
Требования гипервизоров
Точные минимумы относятся к конкретной версии продукта и способу установки. Инсталляционный минимум нельзя использовать как рекомендацию для промышленного HA-кластера. Перед закупкой проверяйте актуальную документацию производителя и матрицу совместимости конкретной серверной модели.
| Платформа / версия из исследования | На что обратить внимание | Документация |
|---|---|---|
| SpaceVM 6.5.9 | Одиночный сервер — ограниченный режим. Для полного функционала в исследовании указаны 3+ физических сервера, внешняя NAS/SAN и 2×10GbE. | SpaceVM |
| zVirt 4.5 | Минимальные требования хоста отличаются от рекомендуемых для Hosted Engine. Возможность RAM overcommit не означает безопасное 2:1 для любого workload. | Orion soft |
| РЕД Виртуализация 8.0 | Ориентиры ресурсов для ВМ не заменяют sizing по телеметрии; учитывать отдельную высокоскоростную сеть хранения. | РЕД СОФТ |
| Альт Виртуализация PVE 11.2 | При HA важны quorum и QDevice; для Ceph учитывать дополнительные CPU/RAM и пропускную способность сети. | Альт |
| ROSA Virtualization | Требования ROSA 3.1 нельзя автоматически приписывать ROSA 4; необходимо сверить руководство конкретной версии. | ROSA |
| Hyper-V / Windows Server 2025 | Кластер, witness, live migration и Hyper-V Replica решают разные задачи; учитывать лицензирование по ядрам. | Microsoft |
| VMware ESXi 8, RHEL/KVM 9 | Проверять CPU Ready/Co-Stop, NUMA, память и конкретные ограничения платформы. | Broadcom / Red Hat |
Технические минимумы и рекомендованные требования взяты из исходного исследовательского MD (проверка от 07.11.2026); перед закупкой необходимо повторно проверить версии и действующие документы. Здесь не приводится список «сертифицированных РАМЭК», поскольку такие сведения должны подтверждаться по конкретным моделям и версиям ПО.
Пример расчёта ресурсов
Исследовательский пример: 20 ВМ, из них четыре критичных DB/app, десять обычных и шесть с нерегулярной нагрузкой. Назначено 96 vCPU; измеренная одновременная пиковая потребность CPU — 36 условных единиц производительности физических ядер; рабочий набор RAM — 620 ГБ; storage peak — 45 тыс. read и 18 тыс. write IOPS. Требование — пережить отказ одного узла.
96 физических ядер не следует напрямую из 96 vCPU.
Нужен запас под гипервизор и размещение ВМ после аварии.
Считаем профиль ввода-вывода, concurrency и storage latency.
Из этих цифр нельзя обоснованно получить конкретное число серверов: не задана допустимая загрузка после аварии, характеристики выбранного CPU, фактическая NUMA-топология, схема хранения и гипервизор. Правильная последовательность: измерения → критичность → гипервизор → запас N+1 → CPU/RAM → storage → сеть → совместимость → испытания.
Типичные ошибки в ТЗ
- Указывать только «64 ядра / 512 ГБ» без профиля нагрузки, лицензий и резерва после отказа.
- Принимать фиксированный overcommit 4:1 как обязательный или заведомо безопасный для любого гипервизора.
- Считать два SMT-потока двумя полноценными физическими ядрами.
- Выбирать RAID10 без учёта интенсивности записи, стоимости ёмкости и времени восстановления.
- Считать, что два 25GbE-порта дают 50GbE на каждый одиночный поток.
- Приравнивать live migration к HA, а HA — к резервному копированию и DR.
- Считать, что наличие трёх хостов автоматически обеспечивает N+1 при любой нагрузке.
- Переносить требования, сертификаты и матрицы совместимости одной модели сервера на другую.
Чек-лист перед закупкой
Нагрузка
- Инвентаризация ВМ и прогноз роста
- CPU средний, peak, p95 и CPU Ready/steal
- RAM working set и реальная потребность
- IOPS, latency и объём данных
Платформа
- Название и версия гипервизора
- Совместимость CPU/NIC/HBA/RAID/firmware
- Проверка гостевых ОС и драйверов
- Ограничения миграции и passthrough
Отказоустойчивость
- RPO/RTO и сценарии отказа
- Quorum, witness, fencing
- Запас CPU/RAM по модели N+1
- Тест аварийного перезапуска ВМ
Сеть и данные
- Разделение traffic classes
- Резервные сетевые пути и SAN
- Backup, репликация, проверка restore
- Ресурсы Ceph/HCI при rebalance
Конкретный сервер, его спецификация (BOM), актуальная запись в реестре, совместимость с гипервизором и гарантийные условия проверяются отдельно. Исследование не подтверждает какую-либо модель или конфигурацию РАМЭК автоматически.
Первичные источники
Ниже приведена сокращённая подборка технических первоисточников из приложенного исследовательского материала. В статье разграничены общие инженерные принципы, рекомендации производителей и расчётные примеры. Для проектирования используйте документы на выбранные версии.
- Red Hat — RHEL 9, virtual CPU overcommit
- Broadcom — ESXi 8.0 rightsizing и NUMA
- Microsoft — Hyper-V NUMA
- Microsoft — Hyper-V Live Migration
- Microsoft — quorum witness
- Microsoft — Failover Cluster networks
- zVirt 4.5 — planning requirements
- SpaceVM — требования к компонентам
- Альт Виртуализация PVE 11.2 — руководство
- ROSA — документация
- fio — параметры тестов I/O
- NIST — Recovery Point Objective
- NIST — Recovery Time Objective
- Microsoft — Windows Server 2025 licensing