Обзор российских серверов Yadro

Тема российских серверов успела надоесть всем.

Одни спрашивают: «А это вообще живое железо или просто наклейка ради реестра?»

Другие: «Сколько оно протянет и что будет, когда через три года захотим нарастить мощности?».

Yadro в этой истории всплывает постоянно. Мы их сервера в проектах видели, руками трогали, иногда ругались, иногда благодарили. Ниже – не академическая инструкция, а нормальный разбор: что за линейки сейчас ходят по рынку и куда их реально ставить.

Сразу оговорка: не претендует на полный каталог, но для ИТ-директора или архитектора это хороший «ориентир по местности».

С чего вообще начать: три фамилии в стойке

Когда заказчик говорит «давайте Yadro», почти всегда речь идет о трех фамилиях:

• VEGMAN – основной рабочий x86-сервер, сейчас уже в «втором поколении».
• X-линейка – более классические двухпроцессорные коробки на Intel, без сильного акцента на импортозамещение в каждом абзаце.
• VESNIN – старший брат на POWER, который живет в тех ЦОДах, где его уже поставили, и просто так его оттуда не вытащишь.

Плюс над всем этим нависает история с RISC-V: Yadro официально двигается туда, но это пока скорее вектор развития, чем железка, которую можно завтра заказать фурой.

Разберем спокойно, без фанатизма.

VEGMAN - «русский универсальный сервер» на практике

Если говорить совсем по-честному, под фразой «поставили Yadro» в 2025-м чаще всего скрывается именно VEGMAN R-серии.

Что это за зверь

VEGMAN R120/R220 второго поколения – двухпроцессорные x86-серверы на Xeon Ice Lake. Стандартная стойка 19", высота 1U или 2U.

По цифрам все прилично: много ядер, нормальный объем памяти, PCIe 4.0 под быстрые диски и сетевухи.

Но сухие характеристики не так важны, как то, куда его ставят в реальных проектах:

• кластеры виртуализации (KVM, отечественные платформы, «облака для себя»);
• базы данных, CRM, ERP, вся эта скучная, но критичная классика;
• VDI и всякие «удаленные рабочие столы», когда пользователи разбросаны по филиалам.

Как это выглядит вживую

Типовая история из жизни.

Заказчик: средний холдинг, несколько площадок, парк разнородный – «тут старые Dell, тут HPE, а здесь вот таинственный китайский сервер, который купили когда-то по акции».

Задача: обновить часть парка, но не ломать все и сразу.

Схема получается такая:

1. Под основные сервисы и виртуализацию ставятся несколько VEGMAN R120 G2.
   Они забирают на себя «ядро» инфраструктуры: AD, основные БД, часть прикладных систем.
2. На периферии остаются старые машины, но уже как второстепенные узлы.
   На них уезжают менее критичные вещи, отчетность, тесты.
3. За два-три года старая техника потихоньку выдавливается, а новые VEGMAN-ы становятся «стандартом по умолчанию».

Важный момент: VEGMAN все-таки нормальный x86-сервер, а не экзотика. К нему можно прицепить знакомые контроллеры, сетевые карты, GPU. Админ, у которого руки росли под Dell/HPE, пару дней поворчит, но потом живет с ним довольно спокойно.

Плюсы и подводные камни

Что обычно нравится:

• гибкость по конфигурациям: от «скромной двухпроцессорной машины» до совсем серьезной сборки с кучей памяти;
• возможность закрыть требования по реестру, не ухнув в какой-то совсем уж нестандартный зоопарк;
• более-менее понятный вендор с нормальной техподдержкой, а не «две коробки в год и потом ищите нас в Телеграме».

Из того, что стоит помнить:

• железо не волшебное. Если попытаться на один R120 посадить и виртуализацию, и тяжелую СУБД, и кусок аналитики, он будет страдать так же, как любой другой сервер в такой нагрузке;
• нужно заранее продумывать, где вы будете расширяться: по памяти, по дискам, по сети. «Взяли на вырост» без расчетов обычно заканчивается тем, что через год опять не хватает.

Линейка X - спокойная классика для тех, кто не хочет приключений

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

Здесь все проще:

• двухпроцессорные Xeon Ice Lake;
• форм-факторы 1U и 2U;
• конфигурации без экстремального фанатизма, но с хорошим запасом для корпоративных задач.

Мы в проектах часто видим такую картину:

• если компания строит парк «с нуля» и упирается в реестр – логично брать VEGMAN;
• если парк смешанный, много уже крутится на обычных Ice Lake-серверах разных брендов, а нужно аккуратно дорастить ресурсы – тогда X-линейка ложится мягче, без ощущения «это что за зверь, как его мониторить и где у него уши».

По нагрузкам X-серверы живут в тех же ролях: виртуализация, приложения, базы. Просто без ярко выраженной «национальной» окраски.

VESNIN - «старый тяжеловес», с которым надо аккуратно

VESNIN – совсем другая история. Это OpenPOWER-сервер, четырехсокетный, с огромным объемом памяти. В свое время его ставили под in-memory-аналитику, очень тяжелые БД и проекты уровня «данных много, времени мало».

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

• как его поддерживать, если вокруг все постепенно уезжает на x86;
• что делать с лицензиями и ПО, которые заточены именно под эту архитектуру;
• когда и как вообще планировать миграцию, чтобы не словить год простоя и чью-нибудь нервную бороду.

Пример живого диалога:

– Давайте все перепишем на x86, ну сколько там того кода…
– А когда вы последний раз туда руками лазили?
– Э-э-э… тот архитектор уже в другой компании, а документация «где-то должна быть».

В таких историях правильный подход обычно один: не дергать VESNIN из стойки просто потому, что модно. Сначала аудит: что крутится, от чего зависят другие системы, какова реальная нагрузка. Потом счет – на что это переносить, сколько выйдет железо, лицензии, работа. И только после этого дорожная карта по миграции.

Что там с RISC-V и «сервером будущего»

Отдельный слой – разговоры про RISC-V. Yadro открыто двигается в эту сторону: разрабатывает свои ядра, участвует в альянсах, пилит инструменты. На уровне новостей это красиво: «своя архитектура, независимость, все наше».

Но с точки зрения ИТ-директора в ноябре 2025-го картина проще и честнее:

• это пока не массовая серверная платформа, которую можно взять и завтра развернуть вместо парка x86;
• на горизонте 3–5 лет она, скорее всего, появится в виде пилотных решений, специализированных кластеров и т.п.;
• при планировании инфраструктуры имеет смысл держать это в уме, но не строить всю стратегию по принципу «мы подождем RISC-V, а пока ничего не купим».

То есть сейчас разумнее считать так: рабочий конь на ближайшие годы – все еще x86 (VEGMAN/X и прочие), а RISC-V встанет рядом, когда дозреет экосистема.

Как с этим работать интегратору и ИТ-директору

Разные компании подходят к выбору по-разному.

Консервативный сценарий

«Нам нужно, чтобы все работало, и чтобы по ночам никто не звонил».

Такие обычно делают так:

• берут одну-две модельные конфигурации VEGMAN или X под ЦОД;
• жестко ограничивают зоопарк: только эти платформы и только в согласованных ревизиях;
• все новые сервисы и виртуализацию сажают на этот стандарт, стараясь не размывать его десятком экспериментов.

Плюс: предсказуемость и упрощенное обслуживание.

Минус: иногда приходится мириться с тем, что «идеального» под конкретный экзотический сервис железа нет, но жить можно.

Агрессивно-экспериментальный подход

«Давайте пробовать все, русский сервер здесь, китайский тут, а вот тут RISC-V».

Иногда так делают компании с сильной внутренней ИТ-командой, которая любит эксперименты.

Выигрыш – в гибкости и возможностях.

Проигрыш – в количестве ночных звонков и объеме документации, если ее все-таки начинают писать.

На практике мы чаще видим третий, более здравый путь.

Смешанный, но управляемый вариант

1. Выделяются 3–4 типовых профиля серверов: виртуализация, БД, хранилище, спецнагрузка.
2. Под каждый профиль выбирается одна-две платформы, чаще всего в том числе Yadro.
3. Все новые проекты стараются посадить именно на эти профили, а «экзотику» допускают только по спецсогласованию.

В результате и импортозамещение есть, и жизнь не превращается в бесконечную борьбу с совместимостью.

Почему Hightech вообще про все это пишет

Потому что для интегратора сервер – это не коробка «с такими-то гигагерцами и гигабайтами», а часть инфраструктурного пазла.

В одном проекте VEGMAN отлично заходит как база для виртуализации.

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

Поэтому, когда в ТЗ появляется строка «рассмотреть Yadro», реальный разговор обычно строится так:

• что у вас уже стоит;
• что критично по производительности и SLA;
• есть ли требования по реестру, по сертификации, по импортозамещению;
• на сколько лет вы планируете вперед.

А уже затем в карточке проекта появляются конкретные фамилии: VEGMAN R, X-серверы, временно живущий VESNIN и возможные пилоты с новыми архитектурами.