Как выбрать сервер для виртуализации: CPU, память, диски и сеть

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

Составьте перечень виртуальных машин

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

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

Рассчитайте процессор, а не сумму vCPU

Сумма vCPU полезна как инвентаризация, но не равна требуемому числу физических ядер. Часть ВМ простаивает, другие одновременно выходят на пик. Сначала сложите фактическую загрузку процессора в одинаковые интервалы времени, затем добавьте ресурсы самого гипервизора и согласованный запас.

Коэффициент переподписки выбирают по измеренной нагрузке. Для лёгких служб он может быть выше, для баз данных и систем с жёсткими требованиями к задержке — ниже. Не используйте один коэффициент для всего парка. Проверьте поддержку аппаратной виртуализации, SLAT и, если нужен проброс устройств, IOMMU или VT-d/AMD-Vi.

Память считайте консервативно

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

Оставьте свободные DIMM-слоты для роста, но сохраняйте симметричное заполнение каналов согласно руководству выбранного сервера. Для двухпроцессорной платформы память распределяют между установленными CPU; слоты второго процессора без самого процессора обычно недоступны.

Дисковая подсистема определяется задержкой

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

Разделите системные диски гипервизора, рабочее хранилище ВМ и резервные копии. Выберите RAID или программно определяемое хранилище под конкретную платформу. Если используется ZFS, диски должны быть доступны системе напрямую; аппаратный RAID с собственным кешем под ZFS применять не следует.

Разделите сеть по назначению

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

Проверьте расчёт сценарием отказа

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

Источники

• Microsoft Learn: требования к оборудованию Hyper-V.
• Proxmox VE Administration Guide.