Redfish vs IPMI: как устроено удалённое управление сервером

Что такое BMC и out-of-band управление

Официальное руководство Intel по управлению серверами определяет BMC так: «Контроллер управления платой BMC — специализированный микроконтроллер, встроенный в большинство серверных плат Intel. Он служит основой архитектуры IPMI и обеспечивает автономный мониторинг и восстановление на уровне аппаратуры и прошивки управления платформой». Иначе говоря, BMC — это отдельный микроконтроллер на плате сервера, который живёт независимо от основного процессора и операционной системы.

Именно эта независимость и называется out-of-band управлением. Официальное определение Intel: «Внеполосное управление OOB означает прямой обмен с BMC в обход операционной системы; состояние платформы можно получить и восстановительные действия можно запустить, даже когда обычные внутриполосные механизмы недоступны». Практический смысл: через BMC можно включить сервер, посмотреть датчики температуры, примонтировать образ ОС или получить консоль — даже если сама операционная система на сервере зависла или ещё не установлена.

Что такое IPMI: определение и история версий

Официальная спецификация IPMI (совместно опубликованная Intel, Hewlett-Packard, NEC и Dell) определяет предмет так: «Интеллектуальное управление платформой — это автономные функции мониторинга и восстановления в аппаратуре и прошивке; инвентаризация, мониторинг, журналирование и восстановление доступны независимо от основных процессоров, BIOS и операционной системы».

Официальная история версий по таблице ревизий самой спецификации: IPMI v1.0 — первый релиз 16 сентября 1998 года; IPMI v1.5 — первый релиз 21 февраля 2001 года; IPMI v2.0 («документ о втором поколении IPMI») — первый релиз 12 февраля 2004 года. IPMI 2.0 остаётся широко распространённым протоколом управления серверами и сегодня, спустя более двадцати лет после первого релиза линейки.

Что такое Redfish: официальное определение DMTF

Официальная спецификация DMTF (Distributed Management Task Force — организация-разработчик стандарта) определяет Redfish так: «Redfish — стандарт управления через интерфейс REST и модель данных на основе схем; он подходит для устройств от отдельных серверов до компонуемой инфраструктуры и крупных облачных сред». То есть Redfish — это не конкретный продукт, а открытый стандарт REST API поверх строго определённой JSON-схемы данных.

Зачем DMTF создал Redfish взамен IPMI-over-LAN

Документ DMTF описывает проблему прежних стандартов: «Устаревшие ИТ-стандарты, включая IPMI, часто ограничивались общим минимальным набором функций, поэтому производители создавали собственные несовместимые расширения и снижали совместимость платформ». То есть у разных производителей получались несовместимые друг с другом расширения одного протокола.

Решение сформулировано там же: «Redfish впервые выпущен в 2015 году для управления программно определяемыми гибридными ИТ-средами. Стандарт использует привычные разработчикам HTTP, REST и JSON, а его данные читаемы машинами и людьми. Первая версия была ориентирована на серверы и стала защищённой многосерверной заменой IPMI-over-LAN». Официально Redfish — это прямой ответ на ограничения именно сетевого варианта IPMI, а не полная отмена BMC как класса устройств.

Безопасность: TLS у Redfish и уязвимость IPMI 2.0 по данным NIST

Спецификация Redfish DSP0266 (редакция v1.25.0, раздел 13.1.1) требует поддержки TLS 1.2 с рекомендациями RFC 7525 либо более новой версии. В ней отдельно отмечено, что разрешение TLS 1.1 в прежних редакциях устарело. Это требование к реализации интерфейса; безопасность конкретного сервера дополнительно зависит от настройки прошивки, сертификатов и изоляции управляющей сети.

У IPMI 2.0 есть задокументированная государственной базой уязвимостей проблема. Официальная запись NIST National Vulnerability Database (CVE-2013-4786) формулирует её так: «Аутентификация RAKP в IPMI 2.0 позволяет удалённому злоумышленнику получить хэш пароля из HMAC в ответе BMC и проводить офлайн-подбор». Это официальная, независимая (не вендорская) запись в государственной базе уязвимостей США — не отраслевая молва.

Модель данных: JSON-схема Redfish против бинарных SDR у IPMI

Официальное руководство DMTF по ресурсам и схемам Redfish описывает принцип: «Каждый ответ Redfish содержит данные JSON со свойствами, строго заданными схемой соответствующего ресурса». Определить схему конкретного ответа можно программно: «Схему конкретного ресурса можно определить по значению свойства @odata.type в каждом ответе Redfish». Вендорские расширения при этом официально предусмотрены отдельным именованным полем, а не произвольной надстройкой: «Идентификатор расширения производителя или поставщика делит объект Oem на отдельные разделы».

У IPMI подход принципиально другой — данные о датчиках официально описаны как бинарная запись: «SDR — запись данных датчика, содержащая его тип, расположение, сведения о событиях и доступе». Вендорские расширения командного набора IPMI официально устроены через числовой идентификатор производителя: «Номер организации по реестру IANA занимает первые три байта данных запроса» — то есть расширение опознаётся по номеру IANA Enterprise Number, а не по человекочитаемой JSON-схеме.

Как Redfish и IPMI сосуществуют на практике: HPE iLO и Dell iDRAC

На практике Redfish не вытеснил IPMI полностью — крупные вендоры серверов официально поддерживают оба протокола на одном и том же BMC. Официальная документация HPE Server Management Portal для iLO формулирует это прямо: «HPE iLO позволяет управлять использованием IPMI через Redfish API» — то есть у HPE включение/выключение IPMI как раз управляется через сам Redfish API.

У Dell аналогичная картина: официальное руководство пользователя iDRAC9 в таблице лицензируемых функций отдельными строками перечисляет «RESTful API iDRAC и Redfish» и «IPMI 2.0» с одинаковой пометкой «Yes» на всех уровнях лицензии iDRAC9 (Basic, Express, Express for Blades, Enterprise, Datacenter) — то есть оба протокола входят даже в базовый уровень лицензии одновременно, без взаимного исключения.

Частые вопросы