Эксперты в подборе IT-оборудования
Планирование серверной инфраструктуры для виртуализации - задача не из простых. Особенно когда речь идёт о 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 увеличивают плотность машин, но логические потоки не равны физическим ядрам. При расчёте лицензий, кстати, они и не считаются - лицензируются именно физические ядра.
Разговор про лицензии в руководстве по железу может показаться лишним. Он не лишний: после покупки VMware компанией Broadcom (сделка закрыта в ноябре 2023) модель лицензирования изменилась так, что теперь диктует конфигурацию сервера.
Вечных лицензий больше не продают. Только подписка. Уже купленные вечные лицензии продолжают работать, но с окончанием контракта на поддержку вы теряете обновления, патчи и официальную поддержку.
Платят за физические ядра, с минимумом 16 ядер на каждый процессор. Отсюда прямое следствие для закупки: сервер на двух восьмиядерных процессорах будет оплачен как 32 ядра. Половину вы просто подарите. Процессоры меньше 16 ядер под vSphere брать бессмысленно - это первое правило, которого нет ни в одном старом руководстве по выбору железа.
Обратная сторона тоже есть. 128-ядерный процессор в двухсокетном сервере - это 256 лицензируемых ядер на один хост. При подписке, которая продлевается ежегодно, гонка за максимальным количеством ядер перестала быть бесплатной. Оптимум сместился к процессорам средней плотности с высокой частотой: платите за меньшее число ядер, а производительность добираете тактами.
Редакций Standard и Enterprise Plus для новых договоров больше нет - остались бандлы vSphere Foundation (VVF) и Cloud Foundation (VCF).
Отдельно стоит помнить историю с минимальным объёмом заказа: в апреле 2025 Broadcom анонсировал минимум 72 лицензируемых ядра независимо от реального размера инсталляции, а позже в том же году отыграл решение назад, вернувшись к 16. Если планируете закупку по старым расчётам, перепроверьте условия на дату вашего договора - в этой области за два года менялось многое.
Считайте лицензии до выбора процессора, а не после. Разница между конфигурацией на процессорах по 16 ядер и по 8 ядер в железе - несколько десятков тысяч рублей, а в подписке на три года - в разы больше.
И честная оговорка для российского читателя: официальных поставок и поддержки VMware в России нет с 2022 года, Broadcom этого не изменил. Всё написанное выше актуально для тех, у кого vSphere уже развёрнут и кто продолжает его эксплуатировать и расширять. Таких инсталляций много. Если же платформа только выбирается, сравнение живых вариантов есть в разборе гипервизоров 2026 года, и требования к железу оттуда отличаются несильно.
ОЗУ - самый дефицитный ресурс на любой платформе виртуализации. Когда памяти не хватает, гипервизор начинает выгружать страницы на диск, и производительность падает не на проценты, а в разы.
Складывается из четырёх частей:
| Размер инфраструктуры | Рекомендуемый объём ОЗУ |
|---|---|
| Малый офис (до 15 ВМ) | 128-256 ГБ |
| Средний офис (15-50 ВМ) | 512 ГБ - 1 ТБ |
| Крупное предприятие (50+ ВМ) | 1 ТБ и более |
Цифры ориентировочные: пятнадцать терминальных машин и пятнадцать баз данных - это совсем разные объёмы.
ECC-память на серверах виртуализации - стандарт де-факто. Формально ESXi её не требует, но одиночная ошибка в памяти на хосте с тридцатью виртуальными машинами задевает все тридцать сразу. Подробно про то, чем ECC отличается от обычной памяти, мы писали отдельно.
Модули RDIMM и LRDIMM позволяют набрать больший суммарный объём, чем обычные. Актуальное поколение - DDR5; DDR4 остаётся только в конфигурациях на старых платформах.
Заполнять каналы памяти надо симметрично. Сервер с одной планкой на процессор потеряет значительную часть пропускной способности подсистемы памяти, и никакой процессор это не компенсирует.
Производительность хранилища определяет отзывчивость виртуальных машин. Медленные диски становятся узким местом даже при мощном процессоре и большом объёме ОЗУ.
SSD стали стандартом для серверов виртуализации: высокие IOPS, низкая задержка, стабильная производительность под нагрузкой. NVMe даёт максимум для требовательных нагрузок - баз данных и приложений с интенсивным вводом-выводом. Гибридные массивы сочетают быстрые SSD под активные данные и ёмкие HDD под архив.
При выборе SSD смотрите на ресурс записи (DWPD) и наличие защиты от потери питания. Потребительский SSD в датасторе под несколько десятков машин изнашивается быстро и в момент пропадания питания может потерять содержимое кэша записи.
Пункт, на котором спотыкаются чаще всего, потому что требования изменились, а привычки остались. Раньше ESXi спокойно грузился с USB-флешки или SD-карты, и многие до сих пор так и закладывают в проект.
Сейчас это плохая идея. С седьмой версии ESXi заметно активнее пишет на загрузочное устройство служебные разделы, и флеш-память низкой выносливости выходит из строя за месяцы - на семёрке этим обожглись массово. Формально USB и SD поддерживаются и в девятой версии. Но ориентир для новых установок другой: постоянное устройство от 128 ГБ - M.2 NVMe, SATA SSD или SATADOM с нормальным ресурсом. Два таких устройства в зеркале - разумная страховка, потому что смерть загрузочного диска выводит хост из кластера целиком.
RAID 1 подходит для загрузочных устройств и небольших системных томов.
RAID 10 - рабочий вариант для датасторов под виртуальные машины. Штраф на запись у него минимальный: каждая запись идёт на два диска, без чтения и пересчёта чётности. А нагрузка от виртуализации почти всегда смешанная и случайная.
RAID 5 и 6 экономят дисковое пространство, но каждая операция записи превращается в несколько операций на дисках. Под датастор с активными машинами это чувствуется, под архивные и резервные тома - нет. Решать по характеру нагрузки, а не по формуле «золотая середина».
vSAN собирает хранилище из локальных дисков самих хостов, без внешней СХД. Каждый сервер в таком кластере должен иметь кэширующие устройства (SSD или NVMe), накопители под постоянное хранение и сетевые адаптеры от 10 Гбит/с. Данные распределяются и реплицируются между узлами автоматически.
Стоит помнить, что vSAN лицензируется по ёмкости: часть входит в бандл, остальное докупается терабайтами. На общий счёт за инфраструктуру это влияет заметно.
От пропускной способности и надёжности сети зависит работа всех сервисов на хосте.
10 Гбит/с - нынешний стандарт для серверов vSphere. Этого хватает на комфортный vMotion, репликацию vSAN и трафик машин. 25 Гбит/с и выше нужны кластерам с интенсивным сетевым обменом и всерьёз нагруженным vSAN.
Минимум четыре порта на сервер, разнесённых по задачам:
Агрегация каналов повышает пропускную способность и переживает отказ одного порта. Развести пути по портам мало - разводите их по разным адаптерам. Два порта одной карты умирают вместе с картой. Какие порты нужно открыть между хостами и vCenter, мы разбирали отдельно - на этом спотыкаются при каждом первом развёртывании.
Совместимость - место, где vSphere отличается от свободных гипервизоров сильнее всего. VMware ведёт строгую политику сертификации и поддерживает только протестированные конфигурации. Сервер, собранный «из хороших комплектующих», может работать, а может не увидеть контроллер хранилища после планового обновления.
Первое, что нужно знать в 2026 году: списка «VMware HCL» по старому адресу больше нет. Он переехал вместе с продуктом и называется теперь Broadcom Compatibility Guide. Половина инструкций в интернете и во внутренних регламентах до сих пор ведёт на старые ссылки, и это первая причина, по которой проверку совместимости пропускают.
Проверять надо три вещи по отдельности - списки на них разные, и «сервер целиком» ни одну из них не заменяет:
К каждой позиции в списке привязана конкретная версия ESXi и конкретный диапазон версий прошивки и драйвера. Формулировка «наш сервер есть в HCL» без указания версии ничего не означает: модель, сертифицированная под ESXi 7, может не значиться под девятой.
Ручная сверка по списку - не единственный путь. В vSphere Lifecycle Manager есть встроенные отчёты о совместимости - на уровне отдельного хоста и на уровне кластера. Платформа сама сверяет установленное железо, прошивки и драйверы с базой Broadcom и показывает, что не проходит. Инструмент недооценённый - многие администраторы про него не знают и продолжают сверять модели глазами.
Запускать проверку совместимости стоит перед каждым обновлением версии, а не после. Обновление на неподдерживаемой конфигурации - это ситуация, когда хост поднимается, а датастор не подключается.
Dell Technologies (PowerEdge), HPE (ProLiant, Synergy), Lenovo (ThinkSystem), Cisco (UCS), Supermicro. У этих вендоров под vSphere сертифицированы и платформы целиком, и штатные контроллеры с сетевыми картами - это снимает большую часть вопросов. Если подбираете конфигурацию с нуля, сервер HPE ProLiant или PowerEdge в заводской комплектации почти наверняка окажется в списке.
Вариантов три, и все рабочие. Первый - подобрать близкую сертифицированную конфигурацию у того же вендора, обычно вопрос решается заменой контроллера. Второй - уточнить у производителя: часть моделей проходит сертификацию силами партнёра и появляется в списке позже. Третий - принять риск сознательно, если речь про тестовый или лабораторный контур, где отсутствие поддержки некритично. Чего делать не стоит - ставить несертифицированное железо в продакшн и узнавать об этом в момент, когда понадобится обращение в поддержку.
Обновлять их надо согласованно с версией ESXi, а не по отдельности и не «на всякий случай». Комбинация свежей прошивки контроллера со старым драйвером - классический источник проблем, которые выглядят как случайные. VMware Tools ставятся на все виртуальные машины: без них не работают корректное выключение, драйверы паравиртуализованных устройств и часть механизмов мониторинга.
Серверы vSphere потребляют много и требуют нормального охлаждения.
Резервированные блоки питания в продакшн-среде обязательны, с запасом мощности порядка 20-30% на пиковые нагрузки и последующий рост. Сертификат 80 Plus Gold или Platinum окупается на длинной дистанции за счёт счетов за электричество, хотя срок окупаемости сильно зависит от тарифа и загрузки.
Вентиляторы с переменной скоростью снижают потребление в периоды низкой активности. Жидкостное охлаждение может понадобиться для плотных конфигураций там, где воздушного потока не хватает, но для типовой инсталляции малого и среднего бизнеса это избыточно.
Считать тепловыделение стоит по суммарной потребляемой мощности: почти вся электрическая мощность, которую взял сервер, выходит из него в виде тепла.
Конфигурация зависит от нагрузки, бюджета и требований к производительности. Ниже - три отправные точки, а не догма.
Для небольших организаций. Процессор: один Xeon 6500P или AMD EPYC 8004 от 16 ядер - меньше брать невыгодно из-за лицензионного минимума. ОЗУ: 128-256 ГБ DDR5 ECC. Диски: пара SSD под загрузку в зеркале плюс 4 SSD на 1,9 ТБ в RAID 10 под датастор. Сеть: 2 × 10 Гбит/с.
Для средних и крупных предприятий. Процессор: Xeon 6700P или EPYC 9005. ОЗУ: 512 ГБ - 1 ТБ DDR5 ECC. Диски: NVMe под кэш и SAS SSD под данные. Сеть: 4 × 10 или 2 × 25 Гбит/с.
Для максимальной производительности. Процессор: Xeon 6900P или старшие EPYC 9005 - с оглядкой на лицензии, потому что каждое ядро здесь оплачивается. ОЗУ: 1-4 ТБ DDR5. Диски: all-flash на NVMe. Сеть: 25/40/100 Гбит/с.
Горизонтальное масштабирование - добавление узлов в кластер - даёт лучшую отказоустойчивость и гибкость распределения ресурсов. Вертикальное, через наращивание ресурсов существующих серверов, проще в управлении, но упирается в потолок платформы: свободные слоты памяти и линии PCIe заканчиваются.
При планировании закладывайте запас 50-100% по критичным ресурсам - и прежде всего по памяти, она заканчивается раньше остального. Дополнительно нужен резерв на отработку отказа: в кластере из четырёх узлов каждый должен уметь принять нагрузку выбывшего соседа, иначе отказоустойчивость существует только на бумаге.
С подпиской по ядрам у роста появилась ещё одна плоскость. Каждый новый хост приносит с собой минимум 16 лицензируемых ядер на процессор - вдобавок к цене самого железа. Иногда дешевле доложить памяти в существующие серверы, чем добавить пятый узел.
Выбор сервера под vSphere требует одновременного взгляда с трёх сторон: производительность, список совместимости и стоимость лицензий на горизонте контракта. Уроните любую из трёх - и получите либо тормоза, либо отказ в поддержке, либо счёт, которого не ждали.
Разобраться с самой платформой и её версиями помогут материалы про все версии ESXi и их требования и про то, зачем нужен vCenter Server. Про то, где снимки виртуальных машин выручают, а где создают проблемы, - в статье про снапшоты и подводные камни.
Собираете сервер под vSphere или расширяете существующий кластер?
Инженеры ITTELO подберут конфигурацию под вашу нагрузку, сверят платформу, контроллер и сетевые карты со списком совместимости, помогут посчитать ядра под лицензии, соберут и протестируют сервер под задачу перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
