Сегодня публикуем материал для тех, кого интересуют современные инструменты и протоколы управления ИТ-инфраструктурой. В своей статье по мотивам доклада с HighLoad++ 2025 технический руководитель компании «Прегель» Никита Австрийский рассказывает о том, как построить систему для управления тысячей серверов на базе протокола DMTF RedFish, как понять, чем неудобен его предшественник IPMI и как справиться с несовершенствами RedFish.

Эпоха IPMI: 2000-е, 2010-е и наши дни

IPMI (Intelligent Platform Management Interface) — это классический протокол управления сервером с помощью консольных команд и утилиты командной строки ipmitool. В его создании принимали участие такие гиганты «железной» отрасли, как Intel, HP, Dell и NEC. IPMI был разработан в 90-х годах прошлого века и получил широкое распространение в 2000-е и 2010-е годы.

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

Минусы IPMI

Несмотря на распространённость IPMI, у этого протокола есть и ряд минусов. Во-первых, это различное представление данных о состоянии оборудования. Вы можете получить информацию с разных сенсоров в абсолютно разном виде, и её будет очень тяжело интерпретировать одночтенно. Одни и те же команды IPMI могут делать разное в зависимости от производителя и модели оборудования.

В IPMI много багов безопасности, которые не исправляются годами с момента создания протокола. В качестве примера можно привести проблемы с криптографией, IPMI использует устаревшие шрифты и дефолтные пароли. Поэтому безопасники не любят выдавать доступ к использованию ipmitool рядовым сотрудникам, так что нагрузка у человека, которому права всё-таки выдали, обычно велика.

IPMI усложняет массовое управление серверами: команды везде разные, подключиться можно только к одной единице оборудования, и в итоге не удаётся запрограммировать нормальное поведение.

RedFish: создание, особенности, преимущества

В качестве ответа на эти вызовы компания DMTF создала RedFish, более новый открытый стандарт для управления серверной инфраструктурой.

Это верхнеуровневый стандарт на основе JSON + REST API поверх HTTP, что обеспечивает интеграцию для массового управления при помощи различных языков программирования и даже bash-скриптов. У RedFish большое сообщество с форумами, где можно получить помощь по его использованию, есть библиотеки под разные языки программирования, недавно даже добавили поддержку протокола MCP для работы с ИИ-агентами. Протокол постоянно развивается, информации о нём много, благодаря чему пользоваться им удобно.

RedFish самодостаточен, с ним легко узнать, что происходит с сервером. На иллюстрации ниже представлена корневая структура Redfish-дерева.

Видно, что в нём содержится и по какой ссылке можно получить дополнительную информацию — можно спокойно посмотреть, что происходит у тебя на сервере в текущий момент. Например, «провалившись» в информацию о хосте, легко получить сведения о состоянии питания, о BIOS, процессорах, памяти:

RedFish для управления ЦОДами

Как можно использовать Redfish для управления ЦОДами? У нашей команды есть опыт управления большим парком серверов всего через 4 основных разработанных нами для заказчика микросервиса.

Первый из них — Discovery Inventory. Он отвечал за обнаружение (discovery) устройств в сети, их инвентаризацию по важнейшим показателям, и сохранение всей этой информации в базе данных.

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

Третий сервис отвечал за применение различных настроек BIOS и BMC, что важно для первичного ввода оборудования в эксплуат��цию. После запуска и конфигурирования Redfish из этого сервиса устанавливались необходимые настройки BIOS и BMC - инженерам больше не требовалось ради этого подходить к каждому серверу.

Четвёртый сервис обеспечивал выполнение базовых операций при работе с хостом или BMC (охватывались основные сценарии вроде включения, выключения и перезагрузки).

На иллюстрации ниже — пример процесса инвентаризации на примере библиотеки GoFish, т.к. разработку мы вели на Go.

В эту структуру при обращении к серверу считываются данные, и её легко переложить в БД. Здесь есть, например, информация о BMC, шасси и прошивке:

На иллюстрации выше видно поле Updatable со значением true. Оно позволяет понять, можно ли обновить текущую прошивку. Также здесь видна версия прошивки. Но есть одно «НО».

Что не так с RedFish?

RedFish —  рекомендательный, а не обязательный стандарт, поэтому вендоры где-то следуют ему, а где-то нет. Поэтому в RedFish предусмотрено отдельное поле OEM. Оно представляет собой случайный (на усмотрение вендора) набор полей, внутри которого вендор может разместить любую дополнительную информацию. Что хуже, он может поместить в OEM какую-то важную информацию из классических полей.

К чему это приводит? К тому, что вы обновляете версию прошивки, выполняете инвентаризацию, а система падает, т.к. просто не может замапить то, что должна замапить. Также некоторые «подводные камни» работы с Redfish описаны здесь.

Классический сценарий обновления

При классическом сценарии обновления (на схеме ниже) мы сначала скачиваем прошивку в нашу систему, затем читаем актуальный MultipartHttpUri в update-сервисе RedFish (там прямо указана ссылка, по которой можно загрузить прошивку).

Обязательно надо проверить версию и понять, удастся ли вообще обновиться. Затем надо загрузить прошивку на устройство. После этого нам будет возвращён Task — задача, которая создаётся в RedFish с некоторым Scheduled. Мы можем поллить эту задачу, чтобы узнать, как она выполняется, и после её завершения провести инвентаризацию. После этого обновление считается успешно выполненным. Но и здесь есть «подводные камни».

Проблемы с обновлением

Иногда возникает ситуация с потерей доступа к оборудованию после обновления. Никаких действий через RedFish при этом выполнить не удаётся. Если вендор не позаботился о том, чтобы после обновления BMC запустила, например, HTTP сервер RedFish, такое вполне может произойти.

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

Ещё могут отличаться сценарии обновления - между вендорами, версиями прошивок или даже версиями RedFish. Можно обновиться по сценарию выше и сразу пройти инвентаризацию, и всё будет хорошо. В другом случае может быть сценарий, при котором оборудование необходимо перезагрузить. А в следующий раз может понадобится подождать 10 минут после создания Task, потому что задача не сразу берётся в расчёт. Из-за этой разницы приходится разрабатывать адаптивный workflow-движок с учётом сценариев обновления у разных вендоров.

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

Событийная модель

К счастью, последнюю проблему можно решить за счёт событийной модели. RedFish может сам сообщать о том, что с ним что-то произошло либо не произошло, по HTTP-вебхуку.

Как показано на иллюстрации выше, достаточно сделать запрос на EventService, подписаться на то, чтобы BMC вам на сервер слала дополнительную информацию, и слушать на обычном EndPoint, что она вам присылает. Таким же образом можно получать логи или информацию обновления, чтобы лишний раз не поллить.

Что удалось сделать благодаря использованию RedFish?

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

Во-вторых, можно интегрироваться с существующим Active Directory для аутентификации через токен вместо базовой аутентификации через логин и пароль (RedFish поддерживает и то, и другое). Возможна и интеграция с Vault для получения секретов.

В-третьих, благодаря RedFish можно построить адаптивную систему обновления серверов независимо от вендора и версии прошивки.

В-четвёртых, все операции с серверами можно выполнять конкурентно — например, запланировав обновление целого парка серверов, в котором 100 машин и больше. Легко узнавать статус задач Task, IPMI такого не позволял. Правда, тут стоит учесть, что в один момент времени можно выполнять только одну операцию — если обновляем, то только обновляем, если меняем настройки, то только меняем настройки.

О чём стоит помнить, используя RedFish

Как я уже упоминал, RedFish - рекомендательный стандарт, и у каждого вендора он реализован по-своему. Многое уходит в OEM-структуры, многие вендоры меняют и корневые структуры RedFish. Иногда поля становится невалидными, и с этим приходится бороться — делать обёртки (если не получается договориться, «костыли» порождают новые «костыли»).

Стоит помнить, что RedFish может работать до очередного обновления BMC, после него могут возникнуть проблемы с совместимостью.

Также приходится разрабатывать адаптеры под разных вендоров. Это неизбежно из-за различий в реализации стандарта.

Ну, и главное, о чём стоит помнить,  по-прежнему требуется первичная настройка оборудования под RedFish. Часто требуется сконфигурировать само оборудование, загрузить RedFish сервер и настроить уже его, по умолчанию это не доступно.

Как преодолеть эти ограничения?

Если вы разрабатываете свою систему управления ЦОД, сначала стоит определиться, с оборудованием каких вендоров и с какими прошивками вы собираетесь работать, какие версии протокола RedFish планируете использовать. Для себя мы выработали следующие важные практики управления большим парком серверов с помощью RedFish:

  • проанализировать то, что у вас есть, выделить общности и различия для разных вендоров.

  • спроектировать и настроить адаптивную систему для различных сценариев.

  • взаимодействовать с командой, разрабатывающей прошивки, для оптимального результата.

Выводы

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

А чтобы узнать больше о мире высоконагруженных систем, приходите на Saint HighLoad 2026! В этом году SHL пройдёт в формате конференции развития. Конференция становится больше практикумом, чем лекциями, а вы — участником, а не слушателем. Больше интерактивных форматов и нетворкинга, знаний, новых контактов и инсайтов!