Привет, Хабр! Летом мы рассказывали о сложном, но очень интересном пути в создании UEFI-загрузчика для серверных продуктов компании OpenYard. Теперь хочется перейти к его постоянному спутнику ― BMC, без которого сегодня трудно представить полноценную серверную платформу.
Когда говорят о серверной платформе, в центре внимания обычно оказываются процессоры, память, накопители и сетевые карты ― словом, всё то, что напрямую влияет на производительность. Но у любой современной серверной системы есть ещё один, менее заметный слой, без которого нормальная эксплуатация быстро превращается в набор компромиссов. Речь о BMC ― встроенном ПО, которое остаётся на посту даже тогда, когда основной сервер выключен, завис или вообще не дошёл до загрузки ОС.
Именно BMC позволяет удалённо включить машину, посмотреть консоль, смонтировать образ для установки системы, проверить температуру, питание и аппаратные логи. На словах это звучит как стандартный набор возможностей. На практике же именно здесь очень быстро проявляется разница между формально работающим решением и системой, с которой действительно удобно жить в эксплуатации.
Что такое BMC и почему он важен
Baseboard Management Controller (BMC) ― это специализированный независимый микроконтроллер, встроенный в материнские платы серверов и промышленных рабочих станций. Если совсем по-простому, это компьютер внутри компьютера: он живёт своей жизнью, имеет собственную прошивку и продолжает работать независимо от того, что происходит с основной ОС.
Именно поэтому через BMC можно управлять сервером даже в тех случаях, когда на нём случился kernel panic, завис гипервизор или система ещё даже не установлена.
В повседневной эксплуатации это означает довольно простые, но критически важные вещи. Если сервер упал ночью в удалённой стойке, не нужно отправлять инженера в ЦОД только ради того, чтобы нажать кнопку питания или подключить монитор. Если нужно срочно переустановить систему, образ можно смонтировать удалённо. Если есть подозрение на перегрев, проблемы с питанием или сбой одного из компонентов, нужная телеметрия и логи тоже, как правило, приходят именно через BMC. Поэтому в инфраструктурной жизни это давно уже не факультативная опция, а базовый рабочий инструмент.
Если совсем коротко, BMC нужен для четырёх базовых сценариев:
удалённого управления питанием сервера,
доступа к консоли и сервисным функциям независимо от ОС,
мониторинга аппаратного состояния,
сбора событий, логов и диагностической информации.
У каждого крупного производителя серверного оборудования есть собственный BMC-стек и своё имя для него: Dell развивает iDRAC, HPE ― iLO, Lenovo и IBM ― IMM. Игроки поменьше часто используют готовые платформы от American Megatrends или Insyde Software. И вот здесь начинается важная для нас часть истории: заметная доля современных решений такого класса уже так или иначе опирается на OpenBMC ― открытый проект, который стал технологической базой для нового поколения BMC-прошивок.
OpenBMC как точка опоры
Если упростить, OpenBMC ― это open source-платформа для создания прошивки BMC. По сути, специализированная операционная система для контроллера управления сервером. В отличие от старых закрытых реализаций, где у каждого вендора был собственный стек со своими ограничениями, OpenBMC предлагает более понятную и модульную архитектуру на базе Linux и Yocto Project. Аппаратная конфигурация здесь описывается в текстовых файлах и манифестах, а значительная часть логики строится вокруг набора user-space-сервисов.
Именно этот путь выбрал и OpenYard. Причины были вполне прагматичными: открытые исходные коды, доступная документация, минимум закрытых компонентов и возможность глубоко адаптировать платформу под собственные задачи. Для серверного решения это важно не только с инженерной точки зрения, но и с точки зрения прозрачности, безопасности и сертификации.
На практике OpenBMC был для нас привлекателен сразу по нескольким причинам:
даёт доступ к исходному коду и предсказуемую архитектурную базу,
позволяет снизить зависимость от закрытых компонентов,
даёт большой объём базовой функциональности из коробки,
оставляет пространство для глубокой продуктовой доработки под собственные требования.
На первый взгляд сценарий кажется очевидным: берём OpenBMC, адаптируем под своё железо, проверяем базовые сервисы ― и задача решена. Но довольно быстро выясняется, что между «OpenBMC запустился на новой платформе» и «этим действительно удобно пользоваться в реальной инфраструктуре» существует довольно ощутимая разница. Базовый проект дает крепкий фундамент: удалённое управление питанием, работу с сенсорами, журналы событий, KVM, Virtual Media, настройку сети, NTP и пользователей. Проблема в другом: почти в каждом из этих пунктов реальная эксплуатация требует либо большей глубины, либо большей гибкости, либо просто более внятного пользовательского сценария.
Поэтому задача OpenYard с самого начала состояла не в том, чтобы просто завести OpenBMC на своей платформе. Нам было важно построить на его основе собственное решение, пригодное для нормальной повседневной работы. Так появился OYBMC ― форк и отдельный слой разработки, в котором типовая адаптация закончилась довольно быстро, а дальше началась уже полноценная инженерная работа.
Где заканчивается портирование и начинается продукт
Один из первых больших фокусов ― веб-интерфейс. Несмотря на общий тренд на автоматизацию, WebUI в BMC по-прежнему остаётся важной частью пользовательского опыта. Даже в хорошо автоматизированной среде регулярно возникает очень земной сценарий: быстро зайти в интерфейс, посмотреть состояние железа, открыть журнал событий, проверить один конкретный узел или за пару кликов выполнить разовое действие без отдельного скрипта и плясок вокруг API. Поэтому интерфейс в OYBMC не остался формальной надстройкой над сервисами, а стал полноценной зоной развития.
Стек при этом мы сознательно не меняли: основой остался Vue.js. Но сам интерфейс заметно переработали и с точки зрения внешнего вида, и с точки зрения сценариев использования. Появилась более удобная навигация, элементы быстрого доступа, сводные таблицы, дополнительные визуальные объекты ― словом, интерфейс стал менее служебным и более пригодным для каждодневной работы.
Причём это потребовало не только аккуратной фронтенд-разработки, но и серьёзной оптимизации. Любая лишняя диаграмма или ещё один слой телеметрии очень быстро превращают BMC-интерфейс в тяжёлую конструкцию. Нам хотелось получить обратный эффект. В итоге после переработки WebUI стал не только функциональнее, но и быстрее оригинального.
Не меньше изменений потребовала и функциональная часть. Это как раз та зона, где у инженеров обычно начинаются самые оживлённые дискуссии: что вообще должен уметь современный BMC, а что уже можно считать излишеством. Для кого-то достаточно минимального мониторинга датчиков и удалённого управления питанием. Для кого-то обязательны глубокая инвентаризация, удобная работа с логами, уведомления, гибкие права доступа и расширенные сервисные сценарии. Практика показывает, что чем ближе система к реальной эксплуатации, тем быстрее побеждает второй подход.
Базовый OpenBMC закрывает значительную часть стартовых задач, но многие сервисы в стандартной реализации работают довольно аскетично. Поэтому большую долю действительно важных сценариев нам пришлось дорабатывать.
Что именно пришлось усиливать
Вот несколько направлений, где это проявилось особенно заметно.
Во-первых, логирование. Нам было важно не просто фиксировать событие как таковое, а давать ему контекст: из какого сервиса оно пришло, с какого IP-адреса была инициирована операция, под каким пользователем она произошла. Без этого лог остаётся просто набором записей. С таким контекстом он уже превращается в рабочий инструмент разбора инцидентов.
Во-вторых, сенсорика. Мы ушли от сценария «показать текущее значение прямо сейчас». Для эксплуатации важнее не только знать, что температура процессора в данный момент в норме, но и видеть динамику: как она менялась за последние часы, не было ли резких скачков, можно ли выгрузить историю для разбора конкретного кейса.
В-третьих, система охлаждения. Здесь мы ориентировались не на абстрактное «лишь бы работало», а на те ожидания, которые давно сформированы у пользователей решений Dell и HPE. В результате в OYBMC появился не только преднастроенный термопрофиль, который можно использовать как универсальную точку старта, но и более гибкая настройка самой логики охлаждения.
Наконец, Virtual Media. В стандартной реализации OpenBMC этот механизм в основном заточен под монтирование ISO-образов для удалённого развёртывания ОС. Для базового сценария этого достаточно, но в реальной работе периодически нужны и более гибкие варианты ― особенно в сервисных и диагностических задачах.
На практике это выглядит вполне приземлённо. В логах важно не просто увидеть факт смены конфигурации, а сразу понять, кто именно и откуда её менял. В сенсорике важно не только текущее значение температуры, но и история, по которой можно разобрать инцидент. В системе охлаждения всё упирается в знакомый компромисс между шумом, температурой и запасом по надежности. А в Virtual Media удобнее иметь не только возможность подсунуть системе ISO, но и нормальный способ передать файлы для обслуживания и диагностики без лишних обходных путей.
Права доступа, которые не мешают жить
Очень важной частью решения стала ролевая модель. Базовые роли OpenBMC ― Admin, Operator и No-Access ― хороши как отправная точка, но для корпоративной среды этого обычно мало. У разных сотрудников почти всегда разный уровень полномочий: одному нужен доступ к KVM, другому ― только к сетевым настройкам, третьему ― право пользоваться IPMI без возможности менять всё остальное. Поэтому в OYBMC была реализована более гранулярная модель прав с возможностью создавать кастомные роли.
Для таких ролей можно отдельно управлять доступом, например, к следующим функциям:
IPMI;
графической консоли KVM;
Virtual Media;
сетевой конфигурации.
Для реальной эксплуатации это не приятный бонус, а нормальный способ не раздавать лишние полномочия там, где они не нужны.
Что добавили сверх базового OpenBMC
Если говорить о том, что заметно расширяет возможности OYBMC по сравнению с базовым OpenBMC, то здесь выделяется сразу несколько направлений.
В частности, мы добавили:
расширенную поддержку SNMP, включая SNMP v3 с шифрованием;
конфигурацию Syslog;
отправку уведомлений по SMTP;
мониторинг и управление RAID-контроллерами;
поддержку PLDM для работы со встроенным ПО компонентов сервера там, где это поддерживается самими компонентами.
По отдельности всё это выглядит как набор частных инженерных задач. Вместе ― это уже совсем другой уровень пригодности системы к жизни в инфраструктуре, где важны не только базовые возможности, но и то, насколько удобно встраивать сервер в существующие процессы мониторинга, обслуживания и диагностики.
Интерфейсы и интеграция
Отдельно стоит сказать про поддерживаемые интерфейсы. Для нас принципиально важным оставался Redfish как современный и стандартизованный способ управления сервером. При этом мы старались не уходить в проприетарные расширения там, где можно было остаться в рамках стандарта. Параллельно сохранялась поддержка IPMI ― старого, но всё ещё востребованного интерфейса, который во многих инфраструктурах продолжает жить по вполне понятным практическим причинам. Существенную роль играет и SNMP, особенно в телеком- и инфраструктурных сценариях, где сервер должен нормально встраиваться в уже существующие контуры мониторинга, а не заставлять заказчика перестраивать половину процессов под новый инструмент.
Если собрать это в короткий перечень, то для OYBMC ключевыми внешними интерфейсами остаются:
Redfish;
IPMI;
SNMP v2c / v3.
Самая трудоемкая часть ― инвентаризация
Пожалуй, одной из самых энергозатратных частей разработки стала инвентаризация компонентов сервера. Снаружи задача выглядит почти банально: показать, какие CPU, DIMM, накопители и PCIe-карты установлены в системе. Но внутри за этим скрывается довольно большой объём низкоуровневой работы.
Для сбора инвентарной информации используются:
SMBIOS;
MCTP over PCIe;
IPMB.
В результате OYBMC умеет получать данные о процессорах, оперативной памяти, PCIe-картах расширения и накопителях SAS, SATA и NVMe.
И здесь особенно важен не сам факт чтения данных, а то, насколько стабильно, единообразно и предсказуемо это работает на разных конфигурациях. Именно на таких, казалось бы, технических мелочах качество системы проверяется особенно быстро.
Масштабирование на другие платформы
В завершение стоит сказать и о масштабируемости решения внутри линейки OpenYard. Весь описанный выше функционал, включая интерфейсную часть и сервисные доработки, был создан примерно за полтора года командой менее чем из десяти человек. Первой целевой платформой стал сервер OpenYard на базе Intel Xeon Scalable 3rd Gen (Ice Lake) ― RS101I/RS201I.
После того как OYBMC стал доступен для внешнего тестирования, мы параллельно занимались и тем, чтобы сам процесс переноса на другие платформы был не разовой инженерной акробатикой, а воспроизводимой процедурой. В среднем такой переезд занимал 2-3 месяца, включая как минимум один цикл внутреннего тестирования. То есть система довольно быстро перестала быть решением «под одну конкретную железку» и показала, что её можно масштабировать дальше без ручной магии в каждом новом случае.
В итоге менее чем за два года OpenYard получил не просто адаптированный OpenBMC для собственного железа, а самостоятельное решение с заметно расширенной функциональностью, более удобной повседневной эксплуатацией и хорошим запасом для дальнейшего развития.
Open source-фундамент сам по себе ещё не делает систему законченной. Всё самое интересное начинается в тот момент, когда поверх него появляется собственная инженерная логика, дисциплина в доработках и готовность доводить базовые механизмы до состояния, в котором ими действительно удобно пользоваться каждый день.