Серверы для виртуализации (https://dorfa.ru/catalog/resheniya-dlya-biznesa/servery-dlya-virtualizatsii/) — это тщательно выверенный баланс процессорной мощности, памяти, скорости дисков и сетевых каналов. Ошибка в одном звене, и инфраструктура начинает тормозить, а расходы растут быстрее, чем бизнес-задачи. Подход «чем мощнее, тем лучше» здесь не работает: избыточные конфигурации стоят слишком дорого, а слабые быстро оказываются узким местом.
В этой статье мы разберем, как выбрать отправную точку для виртуализации на 10 ВМ, как масштабироваться к 30 ВМ и что потребуется для серьезной консолидации на 50 ВМ.
1. Какие нагрузки будут на ВМ?
Перед тем как обсуждать процессоры, объёмы памяти и типы дисков, важнее понять одно: виртуализация — это игра про нагрузку, а не про количество. Две компании с одинаковыми «30 виртуалками» могут потребовать совершенно разные серверы для ВМ, если набор их задач различается.
В целом нагрузки делят на три класса:
- Офисные ВМ. Легкие приложения, RDP-пулы, CRM базового уровня.
- Сервисные ВМ. Веб-серверы, файрволы, контроллеры домена, небольшие API.
- Тяжёлые ВМ. Базы данных, аналитические сервисы, 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, и только после этого собирайте итоговую конфигурацию.
Итоговый совет прост: ничего не покупайте, пока не поймете свою нагрузку. Это сэкономит деньги, нервы и обеспечит фундамент, на котором ваша инфраструктура сможет расти без болезней.
