Выбираем сервер для виртуализации

Вопрос выбора сервера для виртуализации сводится не к тому, какой бренд надёжнее или какая модель популярнее — а к тому, какие конкретно нагрузки будут запущены, сколько виртуальных машин одновременно, и как изменятся эти цифры через год. Именно от ответов на эти вопросы зависит, сколько нужно ядер, памяти, какой RAID выбрать и когда стоит думать о втором процессоре.

Что выбрать: VPS/VDS, выделенный сервер или собственная виртуализация

Прежде чем искать конкретное железо, стоит проверить, нужен ли физический сервер вообще. Если задача — разместить один-два небольших сервиса и не хочется заниматься администрированием, VPS или VDS закроет вопрос дешевле и быстрее. Аренда виртуальной машины у провайдера не требует вложений в оборудование, ИБП и серверную стойку — это рабочий вариант для небольших проектов с предсказуемой нагрузкой.

Выделенный сервер (bare metal) отличается тем, что ресурсы не делятся с другими арендаторами. Это важно при нагрузках, чувствительных к задержкам: высоконагруженные базы данных, финансовые приложения, системы с жёсткими SLA. Такой вариант тоже обходится без покупки оборудования, но стоит дороже VPS и предполагает ограниченную гибкость в конфигурации.

Собственный физический сервер под гипервизор — это выбор тех, кто хочет полного контроля: над конфигурацией, расположением данных, политикой резервирования. Затраты на покупку и обслуживание выше, зато через два-три года TCO при активном использовании обычно оказывается ниже аренды. Этот вариант оправдан, когда нагрузок несколько, они разнородные и вы планируете добавлять новые сервисы в уже работающую инфраструктуру.

Когда нужен сервер для виртуализации

Практический смысл виртуализации — держать несколько изолированных окружений на одном физическом хосте вместо того, чтобы покупать отдельный сервер под каждый сервис. Типовые задачи: одновременная работа 1С и базы данных, тестовые контуры для разработки, VDI для сотрудников на удалёнке, смешанная инфраструктура Windows Server и Linux.

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

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

С чего начать выбор

Самая распространённая ошибка при выборе сервера — ориентироваться на бюджет в первую очередь. Из этого получается либо сервер с избыточными характеристиками, которые никогда не понадобятся, либо машина, которую придётся заменить через год, когда закончится RAM или упрётся в лимит ядер. Правильная последовательность — сначала профиль нагрузки, потом цена.

Профиль нагрузки — это не абстрактное «нужно несколько серверов». Это конкретные цифры: сколько ВМ планируется сейчас, сколько через 12–18 месяцев, сколько vCPU и RAM нужно каждой, какие приложения критичны к дисковым операциям, нужна ли высокая доступность. Когда эти данные есть, выбор между конфигурациями становится расчётной задачей, а не угадыванием.

Capacity planning сложнее, чем кажется, если вы делаете это впервые, — но даже грубая оценка лучше отсутствия оценки. Берёте текущее потребление ресурсов на серверах или рабочих станциях, которые будете виртуализировать, добавляете 20–30% на накладные расходы гипервизора, добавляете запас на год роста. Это и будет отправная точка для выбора железа.

Какие данные нужно собрать перед покупкой

Чтобы расчёт был точным, а не приблизительным, соберите следующие данные до того, как смотреть на конфигурации серверов:

1. Сколько ВМ будет работать одновременно сейчас и через 12–24 месяца.
2. Какой объём vCPU и RAM нужен каждой ВМ в типовом режиме и в пиковой нагрузке.
3. Какие приложения требовательны к IOPS: базы данных, почтовые серверы, 1С — это другая нагрузка на диски, чем статические веб-серверы.
4. Нужна ли высокая доступность (HA): если сервер должен выдержать отказ одного узла без остановки ВМ, это меняет подход к выбору конфигурации и количеству хостов.
5. Есть ли уже работающая инфраструктура с которой нужна совместимость: гипервизор, система хранения, сетевое оборудование.
6. Кто будет администрировать: команда с опытом или один системный администратор — это влияет на выбор платформы виртуализации и, соответственно, на требования к железу.

Выбор процессора

Процессор в сервере виртуализации решает две задачи одновременно: обеспечивает вычислительные ресурсы для всех запущенных ВМ и управляет изоляцией между ними на уровне инструкций. Поэтому здесь важны не только частота и количество ядер, но и поддержка аппаратной виртуализации — Intel VT-x или AMD-V. Без этих расширений гипервизор работает через программную эмуляцию, что существенно снижает производительность.

Главная характеристика для виртуализации — количество физических ядер (pCPU), а не маркетинговые «потоки». Каждая ВМ получает виртуальные ядра (vCPU), которые гипервизор отображает на физические. При overcommit — когда суммарное количество vCPU больше, чем pCPU, — производительность снижается, если ВМ активны одновременно. Для офисных ВМ это допустимо: они редко загружают CPU одновременно. Для баз данных, 1С или VDI overcommit нужно ограничивать или исключать полностью.

Ориентир для расчёта: соотношение vCPU к pCPU 2:1–4:1 считается безопасным для смешанных нагрузок. Если большинство ВМ — офисные приложения с невысокой активностью, допустимо 6:1–8:1. При наличии тяжёлых баз данных или VDI на том же хосте лучше держаться не выше 2:1 для этих конкретных ВМ.

Больше ядер или выше частота

Для смешанной корпоративной среды, где в одном хосте сочетаются офисные ВМ и один-два экземпляра СУБД, компромисс — процессор с 16–32 физическими ядрами и тактовой частотой от 2,5 ГГц в boost. Именно boost-частота, а не базовая, определяет, как быстро обрабатываются однопоточные пики нагрузки.

Intel Xeon или AMD EPYC

AMD EPYC предлагает больше ядер на сокет при сравнимой цене и опережает Intel по количеству каналов памяти и полосе пропускания PCIe. Это выгодно, когда нужно максимальное количество ВМ на одном хосте или высокая пропускная способность между процессором и хранилищем. Актуальные поколения EPYC также поддерживают PCIe 5.0 и DDR5, что важно при работе с NVMe-пулами.

Intel Xeon остаётся сильным вариантом в корпоративных средах, где уже существует экосистема совместимого ПО, протестированного именно на платформе Intel: часть корпоративных систем мониторинга, ПО резервного копирования и ERP-систем официально сертифицированы под Xeon-платформы. Также Xeon выгоден на вторичном рынке: серверы прошлого поколения на Xeon E5/E7 стоят значительно дешевле новых EPYC при сопоставимых характеристиках для нетребовательных сценариев.

Оперативная память: главный ресурс хоста виртуализации

Если процессор определяет, сколько ВМ может работать параллельно, то RAM определяет, могут ли они вообще работать нормально. Нехватка памяти — первое узкое место, которое появляется в виртуальной инфраструктуре при росте. Когда хост исчерпывает RAM, гипервизор начинает использовать своп или механизм balloon driver, принудительно забирая страницы у ВМ — это немедленно приводит к деградации производительности всех запущенных машин, а не только перегруженной.

Формула для расчёта: сложите объём RAM всех планируемых ВМ, добавьте 10–15% на накладные расходы гипервизора и ещё 20–30% как резерв на рост. Например, если сейчас планируется 10 ВМ по 8 ГБ — суммарно 80 ГБ — добавьте 8–12 ГБ на гипервизор и 20–25 ГБ запаса. Итого: сервер должен иметь не менее 128 ГБ установленной RAM, а лучше 192 ГБ, если планируется добавление ВМ в течение года.

Для серверной виртуализации обязательна память с коррекцией ошибок — ECC. Это не опция, а базовое требование: одиночная ошибка в RAM без ECC может привести к краше гипервизора и одновременной остановке всех ВМ на хосте. Современные серверные платформы используют DDR5 RDIMM или LRDIMM — последний тип позволяет устанавливать больший объём памяти за счёт буферизации, что критично при конфигурациях 512 ГБ и выше.

Как рассчитать RAM с запасом на рост

Конкретный пример: вы разворачиваете инфраструктуру на 12 ВМ — 4 с Windows Server по 16 ГБ, 6 Linux-серверов по 8 ГБ и 2 тестовых контура по 4 ГБ. Суммарно: 64 + 48 + 8 = 120 ГБ. Добавляем 15% на гипервизор — 18 ГБ. Итого: 138 ГБ. С учётом роста на год и возможности поднять ещё 3–5 ВМ — минимально нужна конфигурация на 192 ГБ, а оптимально — 256 ГБ.

При выборе сервера проверяйте не только объём установленной памяти, но и количество свободных слотов DIMM. Если 192 ГБ уже заняты четырьмя планками по 48 ГБ в единственных четырёх слотах — расширить без замены планок не получится. Хорошая конфигурация — когда текущий объём закрыт половиной доступных слотов: это позволяет просто доставить память, а не перебирать конфигурацию.

Механизмы экономии памяти — memory ballooning, KSM (kernel samepage merging), дедупликация страниц — снижают фактическое потребление при дублирующихся данных в RAM. Это полезно как оптимизация, но не как основа планирования. Рассчитывать инфраструктуру исходя из того, что KSM «сэкономит 20%», — ошибка: при разнородных нагрузках реальный эффект будет намного меньше.

Диски и RAID: где нужна скорость, а где надёжность

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

Для системного диска гипервизора обычно достаточно небольшого SSD или пары в RAID 1 — здесь важна надёжность, а не скорость. Рабочий пул под ВМ — это совсем другая история: здесь количество операций ввода-вывода в секунду (IOPS) напрямую влияет на отзывчивость всех запущенных машин. SAS-диски дают приемлемую производительность при большом объёме хранения, SATA SSD — хороший баланс цены и скорости, NVMe — максимальный IOPS при минимальной латентности. При интенсивной виртуализации с базами данных или VDI NVMe-накопители окупают разницу в цене за счёт прироста производительности на уровне всей инфраструктуры.

Какой RAID выбрать под виртуальные машины

Важно понимать: RAID обеспечивает доступность данных при отказе диска, но не защищает от удаления файлов, программных сбоев или ransomware. Резервное копирование — это отдельный слой защиты, который не заменяется никаким уровнем RAID.

Когда важнее NVMe и SDS, чем классический RAID-контроллер

Если вы строите не одиночный хост, а кластер из двух и более серверов, аппаратный RAID-контроллер перестаёт быть единственным решением — и часто уступает программно-определяемому хранилищу. Такие решения как Ceph, ZFS или VMware vSAN управляют данными на уровне кластера, распределяя нагрузку и обеспечивая отказоустойчивость между несколькими физическими узлами. Это не имеет смысла для одиночного сервера, но если вы уже думаете про расширение до двух-трёх хостов — этот вариант стоит рассмотреть на этапе проектирования.

NVMe-накопители, подключённые через HBA-контроллер напрямую, дают более предсказуемую латентность по сравнению с аппаратными RAID-контроллерами с буферизацией. Это критично именно для OLTP-баз и транзакционных систем, где время ожидания записи на диск напрямую влияет на время отклика приложения.

Сеть и отказоустойчивость: почему одного 1GbE уже мало

Пропускная способность сети напрямую влияет на скорость миграции ВМ между хостами, скорость репликации данных хранилища и производительность VDI. Одиночный гигабитный порт — узкое место при активном использовании нескольких ВМ одновременно: суммарный сетевой трафик 10–15 активных машин легко насыщает 1GbE. Для большинства современных конфигураций стартовая точка — два порта 10GbE с агрегацией (LACP) или резервированием.

При VDI или распределённом хранилище на уровне кластера стоит рассматривать 25GbE или выделенную сеть для трафика хранилища (storage network). Это позволяет разделить пользовательский трафик и трафик репликации данных между узлами, избегая конкуренции за полосу. Технология SR-IOV позволяет напрямую пробросить физический сетевой адаптер в ВМ в обход гипервизора — это снижает накладные расходы и улучшает производительность для сетевых нагрузок.

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

Запас на рост: масштабирование без полной замены сервера

«Запас на рост» — это не просто свободные слоты и ресурсы. Это конкретные характеристики платформы: поддерживает ли материнская плата второй процессор, сколько незаполненных слотов DIMM доступно, есть ли свободные отсеки под накопители, сколько слотов PCIe занято и сколько свободно. Если всё это максимально заполнено при первоначальной конфигурации, «запас» существует только в рекламном материале.

Конкретный пример: двухпроцессорная платформа с установленным одним CPU и 16 свободными слотами памяти позволяет впоследствии удвоить вычислительные ресурсы без замены материнской платы. Это особенно важно при плановом росте инфраструктуры через 12–18 месяцев: апгрейд обойдётся значительно дешевле замены всего сервера.

Сценарий N+1 — это когда у вас есть дополнительный ресурс, который принимает нагрузку при отказе основного узла. В контексте одного сервера это означает: достаточный запас CPU и RAM, чтобы выдержать выход из строя одной из ВМ и перезапуск без деградации других. В контексте кластера — дополнительный хост, который принимает ВМ при отказе соседа. Для критических инфраструктур планирование с N+1 снижает риски остановки сервисов при неплановых инцидентах.

Готовые конфигурации под типовые сценарии

Четыре практических ориентира — не жёсткие спецификации, а точки отсчёта для ваших расчётов:

• До 10 ВМ (стартовая конфигурация): одноплатформенный сервер с 16–24 физическими ядрами, 128–192 ГБ DDR4/DDR5 ECC, SSD RAID 10 под рабочий пул. Для такой конфигурации подойдут процессоры Intel Xeon Silver или AMD EPYC базового поколения. Бюджет позволяет рассмотреть refurbished-серверы прошлого поколения.
• 10–25 ВМ (оптимальная конфигурация): двухпроцессорная платформа с суммарно 32–64 ядрами, 256–384 ГБ ECC RAM, NVMe или SAS SSD в RAID 10 под рабочий пул, минимум 10GbE. Здесь целесообразны Intel Xeon Gold или AMD EPYC среднего ценового диапазона.
• 1С / SQL Server: процессоры с высокой boost-частотой (3,5+ ГГц), NVMe-накопители в RAID 10, объём RAM рассчитывается из реальных требований СУБД плюс запас. Overcommit по CPU нежелателен.
• Кластер под рост: два и более идентичных хоста, программно-определяемое хранилище или SAN, 25GbE, обязательно N+1 по вычислительным ресурсам. Конфигурация каждого узла — с запасом 40–50% по CPU и RAM от текущей нагрузки.

Типовые ошибки

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

Ставка только на частоту CPU при игнорировании числа ядер — следующая ошибка. 10 офисных ВМ не нужны 5 ГГц при 8 ядрах, но при увеличении числа ВМ до 20 именно ядра, а не частота станут ограничением.

Медленные диски под рабочий пул ВМ: SATA HDD в 2025 году в рабочем пуле виртуализации — это гарантированное узкое место. Задержки дискового ввода-вывода суммируются для всех ВМ, работающих с одним пулом.

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

RAID без резервного копирования: RAID 10 не сохраняет данные от случайного удаления или криптолокера. Бэкап на отдельный носитель или в облако — обязательный элемент инфраструктуры, а не опция.

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

Сколько RAM нужно на 10 ВМ?

Зависит от нагрузки каждой ВМ, но ориентир: если каждой ВМ нужно 8–16 ГБ, считайте суммарный объём, добавляйте 15% на гипервизор и ещё 30% запаса. Для 10 ВМ по 8 ГБ минимально нужно 128 ГБ, оптимально — 192 ГБ.

Когда нужен RAID 10, а не RAID 5?

RAID 10 нужен там, где важна скорость записи и быстрое восстановление при отказе диска без просадки IOPS. RAID 5 подойдёт для архивного хранилища, где нагрузка на запись низкая, а ёмкость важнее скорости.

Что выбрать — Xeon или EPYC?

EPYC выгоднее по числу ядер на сокет и полосе пропускания памяти. Xeon актуален там, где важна совместимость с корпоративным ПО или есть возможность взять качественный сервер прошлого поколения на вторичном рынке.

Можно ли взять б/у сервер под виртуализацию?

Да, если это серверное оборудование корпоративного класса (Dell PowerEdge, HP ProLiant, Supermicro), а не рабочая станция или потребительский десктоп. Проверьте количество свободных слотов RAM, поддержку ECC и возможность установки второго CPU.

Хватит ли 1GbE для виртуализации?

Для 3–5 ВМ с низким сетевым трафиком — да. При 10+ ВМ или наличии VDI — 1GbE становится узким местом. Стартовая точка для современной инфраструктуры — 10GbE.