Планирование серверной инфраструктуры для виртуализации - задача не из простых. Особенно когда речь идёт о VMware vSphere, одной из самых требовательных к железу платформ виртуализации. Неправильный выбор компонентов оборачивается медленной работой виртуальных машин, постоянными проблемами с производительностью и головной болью администраторов. Если вы ещё решаете, стоит ли вообще оставаться на VMware, начните с обзора «виртуализация VMware: что нужно знать».
Дилемма обычно одна и та же: купить несколько серверов попроще или один мощный. С 2024 года к ней добавилась вторая, не менее дорогая: как считать ядра, потому что платить за vSphere теперь приходится именно за них. Разберём это отдельным разделом - на выбор процессора лицензии влияют сильнее, чем любые тесты.
Сначала о том, что такое vSphere. Это платформа виртуализации VMware: гипервизор ESXi, система управления vCenter Server и набор компонентов для высокой доступности, отказоустойчивости и производительности. Подробный разбор самой платформы и её инструментов - в обзоре vSphere Client, здесь речь только про железо под неё.
VMware vSphere работает по принципу «bare metal»: ESXi устанавливается прямо на физическое железо, без промежуточной операционной системы. Это даёт максимальную производительность и предъявляет жёсткие требования к совместимости оборудования.
Большая часть требований к железу под vSphere - те же, что и к любому серверу под виртуализацию. Много памяти, быстрые диски, запас по сети, ECC, резервированное питание: под Proxmox, Hyper-V или KVM вы придёте примерно к тому же списку. Специфика vSphere начинается в двух местах: строгий список поддерживаемого оборудования (об этом отдельный раздел ниже) и лицензирование по ядрам, которое меняет арифметику выбора процессора. Всё остальное - общая для виртуализации инженерия.
Виртуальная машина - изолированная программная среда, которая эмулирует полноценный компьютер со своими ресурсами процессора, памяти, дисков и сетевых интерфейсов. Каждая машина конкурирует за физические ресурсы сервера, поэтому нагрузку нужно считать заранее.
Гипервизор ESXi умеет сглаживать нехватку: разделяет одинаковые страницы памяти между похожими машинами, сжимает неактивные страницы, распределяет процессорное время. Но все эти механизмы работают только как амортизатор. Если ресурсов не хватает системно, они лишь оттягивают момент, когда всё начнёт тормозить.
Стоечные серверы остаются самым частым выбором под vSphere. 1U подходит для компактных инсталляций, 2U даёт баланс плотности и возможностей расширения, 4U - максимум дисков и карт расширения.
Блейд-серверы хороши для крупных развёртываний за счёт плотности и централизованного управления, но требуют серьёзных первоначальных вложений в шасси.
Башенные серверы используют в небольших офисах, где важны простота обслуживания и низкий уровень шума.
Выбор процессора влияет на производительность vSphere сильнее всего, и одним быстродействием дело не ограничивается. С 2024 года он влияет ещё и на счёт за лицензии, поэтому решение принимается сразу по двум осям.
VMware vSphere поддерживает только 64-битные процессоры с аппаратной виртуализацией - Intel VT-x или AMD-V. Без них ESXi просто не установится.
У Intel привычная схема Bronze / Silver / Gold / Platinum осталась в прошлом поколении. Сейчас линейка называется Xeon 6 и использует числовые индексы: 6500P и 6700P (Granite Rapids-SP) закрывают основную массу корпоративных задач, 6900P - верхний сегмент вплоть до 128 ядер. Буква P означает производительные ядра. Версии с E-ядрами дают больше ядер на сокет. При лицензировании по ядрам это работает против вас, да и однопоточная производительность у них ниже. Под классическую серверную виртуализацию берите линейку с P-ядрами.
У AMD актуальны EPYC 9005 (Turin) в диапазоне от 16 до 192 ядер и EPYC 8004 (Siena) для компактных и энергоэффективных конфигураций. По количеству ядер и каналов памяти AMD традиционно щедрее, и для плотной консолидации это заметно.
Если в старых руководствах вам попадаются Xeon E-2100/E-2200 или EPYC 3000, имейте в виду: это железо 2018-2019 годов. Оно работает, но покупать его в новую инсталляцию в 2026 году смысла нет.
Единого «правильного» коэффициента переподписки vCPU к физическим ядрам VMware не публикует, и любая статья, которая называет одно число, упрощает. Рабочие ориентиры такие: от 1:1 до 3:1 проблем обычно не создаёт, на 3:1-5:1 начинает проявляться деградация, после 6:1 она чаще всего заметна пользователям. Для нагруженных баз данных и приложений, чувствительных к задержке, разумнее держаться ближе к 1:1.
Но коэффициент - это прикидка на этапе закупки. Мерить надо другое: CPU Ready - время, которое виртуальная машина простояла в очереди, ожидая физическое ядро. Практический порог - держать этот показатель не выше 5%. Если он выше, у вас переподписка независимо от того, какой красивый коэффициент был в проекте.
Hyper-Threading и SMT увеличивают плотность машин, но логи