Серверы для виртуализации: настройка и аппаратные требования при 10, 30 и 50 ВМ

Серверы для виртуализации (https://dorfa.ru/catalog/resheniya-dlya-biznesa/servery-dlya-virtualizatsii/) — это тщательно выверенный баланс процессорной мощности, памяти, скорости дисков и сетевых каналов. Ошибка в одном звене, и инфраструктура начинает тормозить, а расходы растут быстрее, чем бизнес-задачи. Подход «чем мощнее, тем лучше» здесь не работает: избыточные конфигурации стоят слишком дорого, а слабые быстро оказываются узким местом.

В этой статье мы разберем, как выбрать отправную точку для виртуализации на 10 ВМ, как масштабироваться к 30 ВМ и что потребуется для серьезной консолидации на 50 ВМ.

1. Какие нагрузки будут на ВМ?

Перед тем как обсуждать процессоры, объёмы памяти и типы дисков, важнее понять одно: виртуализация — это игра про нагрузку, а не про количество. Две компании с одинаковыми «30 виртуалками» могут потребовать совершенно разные серверы для ВМ, если набор их задач различается.

В целом нагрузки делят на три класса:

1. Офисные ВМ. Легкие приложения, RDP-пулы, CRM базового уровня.
2. Сервисные ВМ. Веб-серверы, файрволы, контроллеры домена, небольшие API.
3. Тяжёлые ВМ. Базы данных, аналитические сервисы, 1С с RAS, high-load-приложения.

Попробуйте прямо сейчас оценить: сколько ВМ каждого типа у вас будет? Этот ответ определит, какими должны быть ваши серверы для виртуализации на ближайшие годы.

Эксперт по системной инженерии Евгений Астахов говорит: «90% ошибок в проектировании виртуализации — это игнорирование профиля нагрузки. Сначала нагрузка, потом конфигурация. Всегда».

2. Аппаратный блок: от процессора до сети

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

Серверы для ВМ должны быть сбалансированы: сильный CPU не вытянет систему с медленными дисками, а NVMe-хранилище не раскроется на перегруженном процессоре. И чем больше ваш кластер: будь то 10, 30 или 50 виртуальных машин, тем важнее соблюдать этот баланс.

Эксперты нередко сравнивают виртуализацию с оркестром, где каждый аппаратный компонент —свой инструмент, и если один играет фальшиво, слышно это всем.

2.1. Центральный процессор (CPU): Ядра, потоки и здравый смысл

CPU — сердце сервера, но в виртуализации важна не только мощность, но и умение распределять её между десятками задач. Здесь играет ключевую роль понятие vCPU — виртуального ядра, которое гипервизор назначает ВМ. Это не физическое ядро, а «доля» вычислительных ресурсов, которую сервер выделяет виртуальной машине.

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

Рекомендации по overcommit просты:

• 1:2 для легких и офисных ВМ;
• 1:1 для тяжелых, нагруженных систем, особенно СУБД и аналитики.

Теперь к практическим расчетам:

• Для 10 ВМ (в основном офисных). Большинство таких систем комфортно работает даже при 8–12 физических ядрах. Односокетный сервер на Xeon Silver или базовом EPYC обеспечит достаточно ресурса.
• Для 30 ВМ (смешанный профиль). Здесь уже нужен 16–24-ядерный процессор. Важно не просто количество ядер, но и частота: сервисные ВМ чувствительны к задержкам.
• Для 50 ВМ (есть тяжёлые СУБД). Это территория старших линеек — AMD EPYC с 32–48 ядрами или Intel Xeon Gold. Здесь уже важно не только ядро, но и масштабируемость всей платформы, включая поддержку объёмов памяти и PCIe-линий под NVMe.

Инженер Никифор Павлов подметил: «Не бывает универсального CPU для виртуализации. Сначала профиль ВМ, затем математика, потом выбор платформы».

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

2.2. Оперативная память (RAM): главный лимитирующий фактор

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

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

Базовая формула: (Память на ВМ × количество ВМ) + 10–20% под гипервизор = минимальный объём RAM.

Примеры:

• 10 ВМ (офисные): 3 ГБ × 10 ≈ 30 ГБ + резерв → достаточно 64 ГБ.
• 30 ВМ (смешанные): итоговый объём уже выходит на 128–192 ГБ.
• 50 ВМ (сервисные + тяжёлые): здесь необходимы 256–384 ГБ, иногда 512 ГБ.

И еще один важный момент: Современные платформы EPYC и Xeon используют многоканальную архитектуру памяти — 8–12 каналов. Если вы заполняете не все каналы, общий пропускной канал падает, и ВМ получают меньше скорости при работе с памятью.

2.3. Подсистема хранения (Storage): где прячутся узкие места

Виртуализация — это дисковый шторм. Любое действие ВМ — загрузка, swap, база данных, обновление — создаёт операции ввода-вывода (IOPS). Поэтому главный параметр хранилища — не объём, а скорость обработки операций.

• Для 10 ВМ подойдёт массив на SATA SSD. Быстро, просто и недорого.
• Для 30 ВМ SATA уже станет ограничением: лучше переходить на NVMe U.2/U.3 — они дают кратно выше IOPS.
• Для 50 ВМ NVMe обязательны, и только в RAID 10 — это комбинация отказоустойчивости и высокой производительности.

Стандартная схема:

• RAID 1 под систему хоста;
• RAID 10 под рабочие ВМ;
• отдельное пространство под шаблоны и ISO.

Почему RAID 10? Он обеспечивает минимальные задержки и предсказуемое время отклика, что критично для тяжёлых СУБД. Отдельно важно понимать разницу между локальным хранилищем и внешней СХД: локальное быстрее и дешевле, но хуже масштабируется. СХД — идеал для кластеров, но требует инвестиций. Этому вопросу стоит посвятить отдельный материал.

2.4. Сетевая подсистема (Network): артерии виртуализации

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

Минимум даже для маленького стенда — 2 физических порта: один под управление (Management), другой под трафик ВМ.
Для более серьёзных конфигураций трафик разделяют на несколько VLAN или физических интерфейсов:

• Management
• VM Data
• Storage
• vMotion / Migration

Для 30–50 ВМ рекомендуют 4 и более физических интерфейсов. Если используется хранилище по сети — SAN или vSAN — лучше смотреть в сторону 10–25 GbE. LACP или teaming позволят объединить интерфейсы для отказоустойчивости и увеличения пропускной способности — без этого кластер может стать хрупким.

Инженер виртуальных сетей Марина Королёва подмечает: «Трафик виртуалки живёт своей жизнью. Он активнее, хаотичнее и тяжелее предсказуемых сетевых схем. Поэтому сеть должна быть запасной и гибкой».

Что следует помнить

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

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

Итоговый совет прост: ничего не покупайте, пока не поймете свою нагрузку. Это сэкономит деньги, нервы и обеспечит фундамент, на котором ваша инфраструктура сможет расти без болезней.