Если кластер VMware нужно обновить в ближайшем закупочном цикле, считай проект на x86. Выбирай серверы из Broadcom Compatibility Guide и проверяй статус серии процессора для нужной версии VMware Cloud Foundation. Arm оставь для отдельного стенда, RISC-V пока не включай в сравнение закупочных платформ.

Срок «перейдём на Arm через 3–5 лет» в обосновании защищать нечем. Последняя найденная публикация о ESXi-Arm Fling 1.15 датирована 15 декабря 2023 года. VMware описывает экспериментальную сборку, но не называет дату промышленного выпуска.

ESXi-Arm подтверждает работу стенда, а не готовность к миграции

В версии 1.15 VMware исправила ошибки, добавила счётчики производительности виртуальных процессоров и поддержку PCIe на Raspberry Pi Compute Module 4. PCIe проверяли только с NVMe. Совместимость остальных устройств разработчики не гарантировали.

Такой набор годится для лаборатории. На стенде ты проверишь загрузку гостевых систем, драйверы, сборку приложений и свои средства автоматизации. Но результаты не подтвердят, что поставщик сможет привезти серийные Arm-серверы под нужный выпуск VCF и обеспечить их поддержку.

Сама архитектура Arm виртуализации не мешает. В документе Arm Enterprise Virtualization with Arm System IP описаны двухэтапная трансляция адресов, SR-IOV и аппаратная маршрутизация прерываний MSI/MSI-X. Эти механизмы позволяют разделять устройства PCIe между виртуальными функциями и передавать запросы нужным виртуальным процессорам.

Между технической возможностью и закупочной позицией остаются три пробела: поддерживаемый выпуск VMware, серийный сервер в матрице Broadcom и срок поставки. Пока хотя бы одного пункта нет, переносить промышленный кластер на Arm рано.

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

В текущей закупке опаснее взять устаревающую x86-серию

Покупка x86 сама по себе не снимает риск. Broadcom переводит процессоры между двумя статусами: Deprecated и Discontinued.

Серия со статусом Deprecated продолжает работать в текущем крупном выпуске VCF, включая его обновления и исправления. Установщик предупреждает, что следующий крупный выпуск может потерять поддержку. Сервер при этом должен оставаться в Broadcom Compatibility Guide — одной подходящей модели процессора недостаточно.

Статус Discontinued означает больше, чем предупреждение. Установщик блокирует установку соответствующего крупного выпуска VCF на таком процессоре.

В таблице Broadcom для VCF 9.x статус Deprecated получили AMD EPYC 7001 и 7002/7Fx2, Intel Xeon Platinum 8200, а также Xeon Gold 6200 и 5200. В следующем крупном выпуске Broadcom планирует перевести эти серии в Discontinued.

Некоторые платформы упёрлись в ограничение раньше. Xeon E5-2600 v4 и Xeon D-1500 уже относятся к Discontinued в VCF 9.x. Для Xeon Platinum 8100 и Gold 6100/5100 прекращение поддержки указано начиная с VCF 9.2.

Поэтому запрос «предложите сервер под VMware» слишком расплывчат. Поставщик может принести исправную машину с достаточным объёмом памяти, которая не пройдёт установку целевого выпуска. В заявке нужны точная модель сервера, серия процессора и версия VCF.

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

Спецификация под задачу

Посчитаем типовой кластер из трёх узлов. Допущение: на нём работают 60 виртуальных машин, каждой выделено в среднем 4 vCPU и 8 ГБ памяти. Хранилище уже вынесено в отказоустойчивый массив. При отказе одного узла оставшиеся два должны принять всю нагрузку.

Шестидесяти машинам требуется 240 vCPU. При переподписке процессора 3:1 получаем 80 физических ядер на кластер: 240 ÷ 3 = 80. Для режима N+1 два оставшихся узла должны дать эти 80 ядер, поэтому бери по 40 физических ядер на узел, а не по 32.

Память считаем без переподписки: 60 × 8 ГБ = 480 ГБ. После отказа одного сервера нагрузка распределится между двумя — по 240 ГБ. Добавляем по 48 ГБ на гипервизор, служебные процессы и рост: получается 288 ГБ. Ближайшая практичная ступень — 384 ГБ ECC RDIMM на каждый узел.

Итоговая конфигурация одного узла:

x86-процессор или пара процессоров на 40 физических ядер суммарно; точную серию бери из Broadcom Compatibility Guide для выбранного выпуска VCF;
384 ГБ ECC RDIMM с одинаковым заполнением каналов памяти;
два SSD по 960 ГБ в RAID1 под загрузку и служебные разделы;
два порта 25 GbE для трафика виртуальных машин и хранилища;
два отдельных порта управления;
два блока питания с горячей заменой;
корпус 2U с резервом слотов памяти и PCIe.

Цена отказоустойчивости здесь — третий узел и 384 ГБ памяти на каждом сервере, хотя в штатном режиме часть ресурсов простаивает. Если сократить кластер до двух узлов или поставить по 256 ГБ, отказ одной машины потребует выключать часть виртуальных систем.

При другой нагрузке пересчитай три величины. Если средняя машина получает 6 vCPU вместо 4, кластеру понадобится 60 × 6 ÷ 3 = 120 физических ядер, то есть по 60 ядер на каждый из двух работающих узлов. Если средняя память вырастет до 12 ГБ, два узла после отказа должны удержать 720 ГБ — минимум по 384 ГБ без запаса, разумная ступень составит 512 ГБ. Если хранилище подключается по iSCSI и создаёт трафик выше 25 Гбит/с на узел, добавляй вторую пару портов или переходи на 100 GbE после замера нагрузки.

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

Arm стоит тестировать отдельно от срока обновления

Пилот на ESXi-Arm имеет смысл, если компания пишет собственное ПО или хочет заранее проверить гостевые системы на другой архитектуре. Выдели ему отдельный сервер и критерии выхода: запускаются ли нужные образы, доступны ли драйверы, проходит ли нагрузочный тест, работает ли резервное копирование.

Не связывай этот пилот с датой замены x86-кластера. У него другой результат: список совместимого ПО и найденных ограничений, а не готовность промышленной платформы.

Вернуться к Arm в плане миграции можно после появления трёх вещей:

поддерживаемого VMware-продукта;
серийных серверов в Broadcom Compatibility Guide;
результатов испытаний твоих виртуальных машин на такой платформе.

RISC-V пока нечего ставить в одну закупочную таблицу с x86 и Arm. Работа ARM SVE Unleashed от 14 мая 2025 года отмечает сходство моделей векторных инструкций: Arm SVE и RISC-V RVV используют переменную длину вектора. Это свойство архитектуры, а не подтверждение совместимости с VMware. Оно не делает RISC-V кандидатом для текущего кластера, но и не даёт оснований объявлять архитектуру бесперспективной.

Формулировка для закупочного обоснования может звучать так:

Закупаем x86-узлы, которые присутствуют в Broadcom Compatibility Guide и не относятся к сериям, исключаемым из целевого выпуска VCF. Arm проверяем на отдельном стенде. Вернём архитектуру в план промышленной миграции после выхода поддерживаемого продукта VMware, появления серийных серверов в матрице совместимости и испытаний наших виртуальных машин.

Перед согласованием предложения запроси у поставщика точную серию CPU, ссылку на модель сервера в Broadcom Compatibility Guide и письменное подтверждение поддержки выбранного выпуска VCF. Если один из трёх пунктов отсутствует, меняй предложение, а не срок проекта.