Архитектура программного обеспечения BMC для мониторинга и управления вычислительными платформами

Введение

BMC (Baseboard Management Controller) выполняет аппаратный мониторинг и удалённое управление независимо от основной ОС (операционная система) при наличии дежурного питания [1]. Его службы получают и представляют данные, как и другие системы мониторинга, но дополнительно воздействуют на оборудование. Поэтому их архитектура должна согласовывать показания, полномочия и результаты команд.

Цель статьи – систематизировать функции ПО BMC и определить архитектурные условия его расширяемости и устойчивости. Для этого сопоставлены спецификация Redfish [2] и документация OpenBMC [3]. Рассмотрены внешние интерфейсы, внутренние службы и пути к аппаратуре; выводы относятся к архитектуре, а не к измеренной скорости работы.

1. Теоретические основы архитектуры BMC

1.1. Назначение и функции BMC в вычислительных платформах

Контроллер исполняет собственную прошивку и при дежурном питании остаётся доступным после выключения основной части сервера. Независимость от ОС не означает работы при полном обесточивании [1].

BMC собирает температуры, напряжения, обороты вентиляторов и состояния компонентов, ведёт журнал событий, управляет питанием и охлаждением. Состав датчиков и дополнительные функции зависят от платформы. В отличие от мониторинга процессов основной ОС, он получает данные непосредственно от устройств.

1.2. Протоколы и интерфейсы взаимодействия BMC

IPMI (Intelligent Platform Management Interface) задаёт команды доступа к датчикам, питанию и журналу SEL (журнал системных событий) через локальные или сетевые каналы [1]. Redfish предоставляет модель ресурсов и REST API (Representational State Transfer Application Programming Interface) на основе JSON (JavaScript Object Notation), с защищённым обменом и механизмами авторизации [2]. Состав доступных операций определяет реализация.

Протокол команды не следует смешивать с путём доступа: внутриполосный путь проходит через основную систему, внеполосный не зависит от её ОС. В последнем случае BMC использует выделенный порт или общий сетевой адаптер. NC-SI (Network Controller Sideband Interface) связывает контроллер с сетевым устройством [4].

К датчикам и исполнительным устройствам BMC обращается через I2C/SMBus, GPIO и другие соединения. LPC/eSPI служат связью с основной системой, PCIe VDM может переносить сообщения MCTP (Management Component Transport Protocol). Таблица разделяет назначение протоколов, шин и транспортов.

Таблица

Назначение протоколов и интерфейсов BMC

2. Компонентная архитектура программного обеспечения BMC

2.1. Многоуровневая модель программного стека BMC

Для сопоставления компонентов предложена трёхуровневая модель: аппаратный доступ, внутренние службы и внешние интерфейсы. Это аналитическое представление, а не обязательная схема любой прошивки.

Драйверы и платформенные настройки образуют нижний уровень. Службы среднего уровня приводят показания к общей модели, проверяют пороги, ведут журналы и исполняют управляющие операции. Верхний уровень предоставляет эти данные и операции через IPMI, Redfish и веб-интерфейс. Между уровнями должны совпадать типы, единицы измерения и признаки доступности.

В OpenBMC данное разделение реализуют ядро Linux, службы systemd и обмен через D-Bus [3, 5]. dbus-sensors публикует показания [6], phosphor-state-manager координирует переходы состояний [7], phosphor-pid-control регулирует охлаждение [8]. Связи показаны на рисунке.

Рис. Компонентная архитектура ПО BMC на примере OpenBMC

2.2. Подсистема сбора телеметрии и мониторинга

Телеметрия объединяет опрос и события. В OpenBMC dbus-sensors читает данные через hwmon, D-Bus или драйверы, проверяет пороги и публикует значения и состояния [6]. Период опроса зависит от динамики показателя, допустимой задержки и нагрузки на шины.

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

2.3. Подсистема управления и автоматизации воздействий

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

Перед исполнением проверяются полномочия, состояние оборудования и допустимость перехода, затем регистрируется результат. Принудительное выключение может привести к потере данных [1, разд. 28.3], поэтому его отличают от штатного завершения работы. При потере ответа результат команды выясняют по фактическому состоянию.

3. Анализ архитектурных решений ПО BMC

3.1. Разделение компонентов и масштабируемость

Разделение компонентов ограничивает объём изменений: новый датчик поддерживаемого типа может потребовать лишь настройки, нового типа – также драйвера и обработки телеметрии. Потребители получают показания через общий интерфейс, без прямого доступа к устройствам [6].

Контракт D-Bus должен согласовывать имена объектов, типы, единицы измерения и признаки доступности [5, 6]. С ростом числа датчиков увеличивается нагрузка от опроса до передачи результатов. Более редкий опрос снижает нагрузку, но увеличивает задержку обнаружения изменений; уведомления D-Bus не исключают чтение датчиков [6].

Масштабирование одного BMC отличается от управления распределённым центром обработки данных. Внешней системе при работе с множеством контроллеров необходимо учитывать различия доступных операций и отказы платформ.

3.2. Безопасность и устойчивость взаимодействия компонентов

Защита команды охватывает весь путь от внешнего запроса до аппаратного действия. Аутентификация, авторизация и защищённый обмен Redfish [2] дополняются внутренними ограничениями и проверкой состояния: наличие права не делает операцию допустимой в любой момент.

Следует различать приём команды, завершение перехода и подтверждение состояния. phosphor-state-manager отражает результат целей systemd в свойствах D-Bus [7], однако перезапуск службы сам по себе не доказывает восстановления платформы. При недоступном датчике автоматическое воздействие должно учитывать неопределённость показаний.

Для повреждения прошивки нужны отдельные средства защиты, обнаружения и восстановления, сформулированные в NIST SP 800-193 [9]. Модульность служб не заменяет эти механизмы.

Заключение

Трёхуровневая модель связывает аппаратный доступ, внутренние службы и внешние интерфейсы BMC. На примере OpenBMC показано, как телеметрия, управление состояниями и охлаждением обмениваются данными через D-Bus и интерфейсы ядра Linux.

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