Построение программного обеспечения управляющих контроллеров на основе открытых интерфейсов IPMI, HPI, RedFish

Сергей Жуков, Игорь Починок, Auriga Inc., НИВЦ МГУ

В статье описывается построение архитектуры программного обеспечения для управляющего контроллера на основе интерфейса SAF HPI. На нижнем уровне управляющий контроллер взаимодействует c интеллектуальными контроллерами по интерфейсу IPMI и с неинтеллектуальными устройствами. На верхнем уровне управляющий контроллер поддерживает интерфейс Redfish и протокол MQTT, которые реализованы поверх интерфейса HPI; эти реализации логически отделены от внутренней архитектуры системы.

Интерфейс IPMI

Интерфейс IPMI (Intelligent Platform Management Interface) – стандарт низкоуровневого интерфейса управляющего контроллера и набор сопутствующих стандартов (протокол IPMB, формат FRU-информации и т. д.), введённый компанией Intel в 1997 году. Версия 2 опубликована в 2004 году и актуальна до сих пор. Представляет из себя набор низкоуровневых команд типа запрос-ответ.

Благодаря поддержке Intel стандарт стал очень популярен и до сих пор многие из существующих контроллеров реализуют IPMI. В частности, стандарт PICMG ATCA (Advanced Telecommunications Architecture), популярный в телекоммуникационной отрасли, основан на IPMI.

В модели IPMI каждый управляющий контроллер несёт на себе набор сенсоров, каждый из которых имеет номер и специальное описание (SDR – Sensor Data Record), значение сенсора может быть прочитано специальной командой. Изменение состояния сенсора может порождать события.

Сенсоры могут быть числовые (нести значение) и дискретные (находиться в одном или нескольких состояниях). Для числовых сенсоров задаются пороги, при выходе за пороги происходят события. Для дискретных сенсоров события происходят при изменении состояния сенсора. События сохраняются в логе (SEL – System Event Log), возможно задавать действия в ответ на события (PEF – Platform Event Filtering).

Интерфейс IPMI в настоящее время устарел и в связи с этим имеет существенные недостатки:
– интерфейс очень низкоуровневый: формат каждой команды детально расписан по байтам и битам;
– длина команды ограничена – максимум 32 байта;
– ограничено количество сенсоров на одном контроллере – максимум 1024 (но, например, для контроллеров ATCA ограничение ещё строже – максимум 768);
– отсутствует единый механизм для управляющих воздействий: изменения состояния сигналов, установки значений управляющих регистров (создаются специальные команды для каждого случая);
– размер значения в команде для числовых сенсоров – 8 бит, вычисление реального значения сенсора производится клиентом с использованием коэффициентов из описания сенсора SDR; в результате реальное значение может иметь большую погрешность.

Интерфейс RedFish

Этот интерфейс разработан организацией DMTF в 2015 году, позиционируется как замена IPMI.

Интерфейс высокоуровневый, использует HTTP и RESTful Web Services для передачи данных, XML для описания структур данных, JSON как формат данных в процессе передачи.

Используется объектная сетецентричная модель данных. Объекты содержат ссылки на другие объекты, существуют объекты – коллекции объектов. Модель данных описана схемой, которая является неотъемлемой частью стандарта. Схема поставляется в двух форматах: XML и JSON.

Для доступа к данным используются стан- дартные HTTP-операции (GET, PUT, POST, DELETE), таким образом, клиентский доступ возможен из любого Web-браузера.

Если результатом запроса является массив объектов, возможно чтение этого массива по частям, начиная с любого места.

В то же время схема Redfish ориентирована более на управление серверами и дата-центрами, чем на управление системами в общем случае (например, в телекоммуникационной отрасли). Так, в схеме нет общей модели сенсоров и элементов управления (контролов). Предусмотрен ряд особых случаев: сенсоры температуры, напряжения и скорости вращения вентиляторов (тахометры). Дискретные сенсоры не поддерживаются. В связи с этим построение на основе модели данных Redfish архитектуры программного обеспечения для управляющего контроллера в достаточно общем случае может быть затруднительно.

Интерфейс HPI

HPI (Hardware Platform Interface) – интерфейс доступа к аппаратным платформам, разработанный организацией SAF (Systems Availability Forum). Интерфейс основан на механизме удалённого вызова процедур (RPC).

Интерфейс описывается в терминах типов данных и прототипов функций языка Си, но также существуют привязки к языкам Java и Python.

Модель данных HPI основана на IPMI, но основные недостатки её устранены:
– числовые сенсоры имеют размер 64 бита, тип целый (знаковый или беззнаковый) или плавающий;
– трансляция значений на стороне клиента не требуется, реализация HPI сразу возвращает реальное значение;
– определены элементы управления (controls) различных типов: бинарные (вкл/ выкл), дискретные, аналоговые;
– система (домен HPI) строится как набор ресурсов, каждый ресурс содержит набор сенсоров и элементов управления и может поддерживать горячую замену;
– система может содержать до 232 ресурсов;
– каждый ресурс может содержать до 232 сенсоров и до 232 элементов управления.

Интерфейс HPI можно рассматривать как хороший компромиссный вариант между IPMI и Redfish.

Пример построения архитектуры системы управления на основе HPI

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

Управляемые объекты включают в себя:
– неинтеллектуальные сенсоры и устройства, подключённые по протоколу 1-wire, I2C (сенсоры температуры, напряжения, тока, мощности, влажности, давления и т. д.);
– неинтеллектуальные дискретные сенсоры на основе сигналов GPIO (General Purpose Input/Output – сигналов ввода-вывода общего назначения);
– дискретные элементы управления на основе сигналов GPIO (включение/выключение соответствующего сигнала); – интеллектуальные устройства охлаждения с интерфейсом Modbus;
– интеллектуальные вспомогательные управляющие контроллеры с интерфейсом IPMI.
– дочерние управляющие контроллеры того же типа, подключённые к материнскому контроллеру по выделенному сетевому соединению и не имеющие внешнего интерфейса (таким образом, управляющие контроллеры образуют иерархию).

Для интерфейса с внешним миром должны были использоваться интерфейсы SNMP, Redfish и графический Web-интерфейс, а также протокол MQTT для встраивания контроллера в инфраструктуру IoT (Internet of Things – интернет вещей).

При разработке, в качестве основы для архитектуры управляющего контроллера выбрана модель данных HPI. Также HPI используется в качестве интерфейса между ядром программного обеспечения и управляемыми объектами. Каждый из интерфейсов нижнего уровня экспортирует набор ресурсов HPI, по своим правилам. Все ресурсы объединяются ядром в единый набор ресурсов, и функции ядра работают со всеми ресурсами одинаковым образом.

Архитектура программного обеспечения показана на схеме.

Для разных интерфейсов нижнего уровня отображение на модель данных HPI выглядит следующим образом:
– каждое устройство 1-wire отображается на отдельный ресурс, поддерживающий горячую замену (устройства 1-wire могут динамически добавляться на шину и удаляться с неё);
– один HPI-ресурс создаётся для всех GPIO-сигналов, все дискретные сенсоры и элементы управления принадлежат этому ресурсу;
– для устройств, подключённых по I2C, каждый набор логически связанных между собой устройств отображается как отдельный HPI-ресурс;
– каждый интеллектуальный контроллер охлаждения, подключённый по Modbus, представляет собой отдельный ресурс, его регистры отображаются на сенсоры и управляющие элементы HPI;
– каждый интеллектуальный IPMI-контроллер представляет собой отдельный ресурс, в соответствии со стандартом отображения между IPMI и HPI;
– каждый дочерний контроллер экспортирует набор HPI-ресурсов, эти ресурсы встраиваются в набор ресурсов материнского контроллера как есть, лишь с изменением номера во избежание конфликта по номерам ресурсов.

Для отображения устройств 1-wire, I2C, Modbus на HPI в составе программного обеспечения разработаны специальные модули. Для отображения интерфейса IPMI используется открытое программное обеспечение.

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

Аналогично сделана реализация протокола MQTT, для включения управляющего модуля в состав инфраструктуры интернета вещей (IoT). Модуль интерфейса с MQTT использует верхний интерфейс HPI, топики MQTT используют номера или имена ресурсов, сенсоров и элементов управления (например, часть строки топика, соответствующая значению сенсора 20 на ресурсе 2 может выглядеть как "/sensors/value/2/20").

Таким образом, построение архитектуры программного обеспечения управляющего контроллера на основе интерфейса и модели данных HPI позволило интегрировать в единую модель данных разнородные управляемые объекты и предоставить для доступа к этой модели данных различные интерфейсы верхнего уровня, реализация которых логически отделена от внутренней архитектуры системы.

Архитектура программного обеспечения управляющего контроллера