Yadro Vegman R4 под нагрузкой zVirt: тепло, IPMI и пропускная способность памяти в аналитике

Yadro анонсировала обновлённую линейку Vegman R4, и у нас появился повод потрогать железо руками - один из клиентов в процессе обновления серверного парка под КИИ, и Vegman R4 попал в шорт-лист. Взяли тестовую конфигурацию, подняли поверх неё zVirt-кластер и неделю гоняли нагрузку, которая ближе всего к реальному use case: аналитические задачи с высоким потреблением памяти и умеренным дисковым трафиком.

Ниже - не пересказ спецификаций, а то, что мы сами увидели при работе.

Конфигурация стенда

Два узла Vegman R4 в двухсокетном исполнении, NVMe-диски в качестве локального хранилища, 25GbE между узлами. Гипервизор - zVirt 4.1, поверх которого подняли несколько виртуальных машин с аналитической нагрузкой: запросы к ClickHouse, периодические ETL-задачи, фоновый агрегатор метрик. Ничего синтетического в чистом виде - набор задач, максимально близкий к тому, что клиент планирует запускать в продуктиве.

Тепловые режимы

Это то, что нас интересовало в первую очередь. Серверы для КИИ часто живут в условиях, далёких от идеальных: не всегда есть прецизионный кондиционер, не всегда воздушный поток организован по учебнику. Хотелось понять, как Vegman R4 ведёт себя под продолжительной нагрузкой.

Гоняли аналитику непрерывно около шести часов. Температуры процессоров держались в диапазоне, который производитель обозначает как штатный, без скачков в сторону терморегулируемого троттлинга. Любопытный момент - скорость вентиляторов. Система управления ими реагирует достаточно плавно: нет резких раскручиваний при кратковременных пиках. Это важно в серверных, где уровень шума критичен для персонала, который там работает.

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

IPMI-интерфейс

Здесь у нас было больше всего скептицизма. IPMI у отечественного железа исторически - это лотерея: либо работает, либо работает "почти". Vegman R4 приятно удивил.

Веб-интерфейс BMC загружается быстро, без артефактов. Консоль KVM через браузер работает без Java-апплетов - это уже само по себе достижение. Управление питанием, мониторинг датчиков, журнал событий SEL - всё на месте и работает предсказуемо. Redfish API доступен и отвечает нормальными JSON-ответами без сюрпризов в формате.

Мы подключили IPMI-порт к нашему Zabbix - добавился без проблем по SNMP. Для тех, кто строит мониторинг через Redfish - эндпоинты стандартные, интеграция с Ansible через community.general.redfish_* модулями тоже встала без патчей.

Единственное замечание: настройки сети BMC через веб-интерфейс иногда требуют двойного применения - задаёшь адрес, сохраняешь, и только после второго сохранения он начинает пинговаться. Воспроизвелось дважды на разных узлах. Через Redfish PATCH это поведение не воспроизводится - там настройки применяются с первого раза.

Пропускная способность памяти под аналитикой

Это основное, зачем мы вообще затеяли тест. Аналитические задачи с большими наборами данных в памяти - чувствительная нагрузка: планировщик zVirt должен нормально размещать виртуальные машины по NUMA-узлам, сами процессоры должны давать нормальную межузловую пропускную способность, и всё это под гипервизором.

Запускали несколько ClickHouse-запросов на агрегацию по таблицам, которые не помещаются целиком в кэш - приходится активно читать из памяти. Параллельно несколько ETL-потоков.

Поведение при NUMA-пиннинге. zVirt позволяет явно назначать виртуальным машинам NUMA-узлы. На Vegman R4 это работает ожидаемо: ВМ, пришпиленная к одному NUMA-узлу, показывает более ровную latency по памяти, чем ВМ, которая размазана по обоим. Ничего неожиданного, но хорошо что это воспроизводится - на некоторых серверах NUMA-топология через гипервизор начинает "гулять".

Поведение при высокой загрузке памяти. Когда суммарный footprint ВМ начинает приближаться к установленному объёму, система начинает использовать KSM (Kernel Samepage Merging) - это стандартное поведение zVirt. На Vegman R4 не заметили аномалий при включении KSM, деградации по аналитическим запросам в измеримых пределах не было. Это хорошо: KSM может давать непредсказуемые задержки на некоторых конфигурациях.

NVMe-oF. Это отдельная история - R4 заявлена с поддержкой NVMe-oF, мы успели поверхностно попробовать только локальные NVMe. Конфигурацию с NVMe-oF target планируем тестировать отдельно - там есть смысл смотреть на поведение вместе с Ceph в качестве хранилища и трафиком репликации.

Что в итоге

Vegman R4 под zVirt с аналитической нагрузкой ведёт себя корректно. Тепловой режим стабильный, IPMI-интерфейс - лучше, чем мы ожидали от отечественного железа этого класса, поведение подсистемы памяти под гипервизором предсказуемое.

Для КИИ-проектов два важных момента, которые мы зафиксировали:

• Сертификация. R4 входит в реестр российской электроники, что снимает часть вопросов при категорировании. Документы на сертификаты есть, и они свежие.
• Поддержка. Это мы проверим позже - на тестовой неделе ничего ломать намеренно не стали, но при переходе на коммерческий контракт интересно посмотреть на SLA по железу.

Следующий шаг - расширенное тестирование с NVMe-oF и оценка поведения под нагрузкой live migration в zVirt. Это будет уже на финальной конфигурации клиента, не на стенде. Если интересует тема выбора железа под КИИ-инфраструктуру с zVirt - этим мы занимаемся в рамках managed-сопровождения.