За последний месяц кругозор многих ИТ-специалистов серьёзно расширился. Вот и я, большую часть профессиональной жизни имевший дело с западным оборудованием, открываю для себя мир отечественного железа. Мне на тестирование достались серверы GAGAR>N V1, созданные в соответствии со стандартом Open Compute Project (ОСP) на основе архитектуры Tioga Pass.

Ну здравствуй, GAGAR>N!

До сих пор я подобного оборудования не видел. Серверы GAGAR>N сделаны по стандарту Open Compute Project. Короткий экскурс о появлении стандарта Open Compute. Несколько лет назад один интернет-гигант создавал оборудование для своего дата-центра. У этой компании, чьи ЦОД могут вместить несколько футбольных полей, был интерес разработать более энергоэффективное и экономичное железо. А потом проект был выпущен «на волю»: архитектуру сделали открытой, включая серверные платы, блоки питания, серверные шасси и стойки OpenRack. По одному из таких вариантов открытого дизайна и сделан сервер GAGAR>N V1.

У серверов нестандартный размер. Когда мы обсуждаем серверы, то привычно представляем себе стойку с типовой шириной 19 дюймов. Серверы GAGAR>N же предназначены для специализированных стоек в 21 дюйм, а уже внутри них разведено питание для серверов. На выходе эта конструкция даёт возможность разместить и запитать больше серверного оборудования, а значит, получить экономию на электричестве, теплоотведении и площади размещения.

С этими общими представлениями я и начал знакомство с GAGAR>N. Скажу сразу, что у меня не было задачи проводить полномасштабное нагрузочное тестирование — была задача только посмотреть функциональность, и как железо работает с самыми простыми задачами.

GAGAR>N изнутри

Первое, что бросается в глаза, — у серверов нет классических блоков питания, которые можно вынуть и заменить «на горячую». Точнее говоря, их нет вообще. В задней части находятся только вентиляторы охлаждения, а питание по внутренней шине подключается непосредственно к стойке.

Чего ещё не найти в GAGAR>N V1, так это мощных процессоров (TDP больше 205 W, но вендор подтверждает их наличие в других моделях) и поддержки более 12 модулей оперативки. Плюс в нём нет возможности зеркалировать модуль M.2 для установки ОС.

Мне на тест-драйв были доставлены два сервера GAGAR>N V1 в такой конфигурации:

• Процессор Intel(R) Xeon(R) Gold 5218R — 2 шт.

• Модули памяти SAMSUNG 3200 DDR4 16Gb — 12 шт.

• Накопитель M2 NVMe 960Gb — 1 шт.

• Накопитель SATA2,5” SSD 960Gb — 2 шт.

• Сетевой адаптер Mezz 2x25GbE Mellanox — 1 шт.

• Трансиверы SFP-10G-SR-S — 2 шт.

• Baseboard Management Controller (BMC) версии v0.08-227-g8b453fe29.

А подключил я всё это вот таким незамысловатым способом:

Подходящих для GAGAR>N стоек у нас в дата-центре нет, и на тест специальную стойку мы не брали. Пришлось немного поколхозничать, чтобы развести питание к серверам. В комплекте с ними шли лабораторные блоки питания с выходом на евровилку.

А ещё — каюсь! — серверы пришлось просто положить на другое оборудование.

Особенность удалённого управления

Серверы в сети, лампочки заморгали, от прикосновения к корпусу чувствуется еле заметная и приятная сердцу инженера вибрация. Вроде всё завелось. Внезапно я обнаружил баг в прошивке модуля удалённого управления. Пытался установить статический IP-адрес для интерфейса управления BMC, а параметры не применялись. Точнее, адрес назначался, а шлюз по умолчанию — нет. Пробовал снова и снова, с молитвами и матами. Ничего не помогало. Попытался добавить эти параметры вручную через ssh. Блеснула надежда. На вид адрес шлюза прописывался, но стоило вынуть провод из BMC для переключения в стоечный коммутатор, как настройки пропадали. Ядрён батон… Обратился к вендору, пообщался с техническим специалистом, чтобы найти способ прописать шлюз в BMC. В результате вместе с экспертом вендора нашли обходное решение — прописали шлюз вручную:

ip route add default via <default_gateway>

И, наконец, всё заработало.

Далеко на этом чувстве успеха я не уехал. На сервер не хотели устанавливаться удалённо с помощью ISO-образа Astra Linux, Альт Сервер, Red OS и Windows Server. Сам вендор эту проблему уже знал и работал над её устранением в следующей версии прошивки. Забегая вперед, нужно сказать, что через 1,5 недели, когда вышло обновление, от этой беды не осталось и следа. Но я не хотел терять время и по совету вендора проверил возможность установки всех этих систем с физического носителя. Брал флешку, записывал на неё загрузочный образ, вставлял в USB на самом сервере. В итоге все ОС на железо установились корректно. Таким образом, проблема подтвердилась только в системе удалённого управления. А раз уж зашла речь о BMC, вот, что о нём удалось узнать:

Чек-лист проверки интерфейса удалённого управления

Тестирование типовых серверных ОС прошло без сучка и задоринки, остался незакрытым только вопрос с Astra Linux Special Edition, графический интерфейс которой не запускался. Этот огрех вендору тоже был известен, и для версии Common Edition 2.12 его решили вместе с производителем Astra с помощью простой донастройки: Работа с видеокартами ASPEED (модули ast и mgag200).

А вот со Special Edition этот финт не сработал — эта ОС запустилась только в режиме командной строки. Производитель в курсе сложностей и заверил нас, что вместе с Astra вопрос решит.

О виртуализации и гипервизорах

Мы тестировали четыре гипервизора: VMware ESXi7.0 Update 3, ECP Veil 5.0, Proxmox 7.1, zVirt 4.3. Останавливаться на каждом из них в отдельности не будем, скучно — практически всё сразу заработало. Кстати, GAGAR>N V1 есть в матрице совместимости VMware — это интересный факт, потому что далеко не все российские производители заморачиваются на этот счёт.

Единственная незадача возникла с ECP Veil. Сетевые адаптеры Mellanox, которые были в составе нашего демооборудования, не подхватились как интерфейсы менеджмента по умолчанию. Пришлось настроить их вручную. Но это некритично — фейл решился одной командой:

net conf ports set-default-port -i <interface_name>

Гибкая настройка производительности

Поскольку серверы оптимизированы для использования в большом количестве, то нужно иметь возможность гибко и точно управлять параметрами питания. При разработке модуля удалённого управления предусматривалась интеграция с решениями от Intel. Что это значит на практике? Инженер может настраивать различные параметры электропитания для разной нагрузки. Например, чтобы процессор, достигая определённого предела по питанию или температуре, автоматически входил в троттлинг и не тратил больше ресурсов или автоматически отключался. Это даёт возможность точно предсказать, сколько серверы будут потреблять электроэнергии в каждый определённый момент времени.

Хороший это парень

В целом моё знакомство с GAGAR>N было исключительно практическим — проверить, что работает. Исследовать производительность задачи не стояло, тем более, что внешние условия для этого не особо располагали.

Что могу сказать по итогам состоявшегося знакомства? Частая проблема отечественного железа в том, что оно порой неприлично сделано. Например, о корпус сервера можно порезать руки. Или софт имеет какие-то свои «детские» болячки. В случае с GAGAR>N никаких неприятностей с корпусом не было — всё сделано прилично. Софт, хоть местами и с костылями, заработал. Производитель идёт на контакт и, по всем признакам, заинтересован бодро развивать свои продукты.

Жаль, не удалось попробовать систему централизованного управления. Изначально Tioga Pass создан для того, чтобы заполнить стойку, как шпроты банку, а без специального средства управления большим числом серверов это утомительно. Производитель предлагает для этого решение Bergen EMS, но испытать его в действии не получилось — не успели предоставить на тест.

Производитель говорит, что при использовании GAGAR>N V1можно сэкономить 13% на электроэнергии и 39% на охлаждении. Правда, эти показатели достижимы для большого числа серверов — расчёт сделан на пять лет для 360 серверов типовой конфигурации. А минимальный эффект в энергоэффективности можно ожидать, применяя от 18 серверов. Потому что перед тем, как завести GAGAR>N V1 в дата-центр, придётся дополнительно вложиться и перестроить систему кондиционирования, купить специальную стойку и подвести к ней питание. Делать это, скажем, для пяти серверов — дорогое мероприятие. Эта переподготовка ЦОД — один из главных вопросов на подумать для построения инфры на GAGAR>N V1. И прежде всего компании нужно точно определить цену этого: просчитать не только стоимость закупки самих серверов и стоек, но и работ по приведению систем кондиционирования и электропитания под их требования.

А у вас был опыт работы с GAGAR>N? Что скажете?

P.S. Кстати, ранее мы посмотрели новые для российского рынка серверы Gooxi, про это можно узнать здесь.

Илья Марченко

Инженер-проектировщик вычислительных комплексов «Инфосистемы Джет»