Главная → Рубрики → Программное обеспечение → Эволюция стандартов управления вычислительными системами на примере IPMI и RedFish

В статье рассматриваются основные отличительные особенности стандартов на интерфейсы управления вычислительными системами IPMI и RedFish и делается попытка выявить общие тенденции развития данного класса интерфейсов. 

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

Проблематика удалённого управления вычислительными системами возникла практически одновременно с их появлением. Это неудивительно – ведь конструктивные особенности таких  систем  делают  их практически идеальными объектами  для  работы на расстоянии. Интерфейс IPMI (Intelligent Platform Management Interface), разработанный ещё в 1999 г., был одним из первых и, определённо, одним из самых удачных стандартов удалённого управления. Достаточно сказать, что он до сих пор широко используется практически на всех серверах для управления извне и во многих больших вычислительных системах для внутреннего интеллектуального управления (например, в системах AdvancedTCA [3],[4]).

В 2015 году рабочая группа DMTF (Distributed Management Task Force) предложила для использования первую версию нового стандарта RedFish. Главное его отличие от уже существующих заключается прежде всего в широком применении сторонних стандартов, гибкости в использовании, простоте и быстроте реализации, низкой стоимости обслуживания, а также сравнительной простоте отладки.

Ниже мы рассмотрим основные отличительные особенности данных стандартов и попытаемся выявить общие тенденции развития этого класса интерфейсов.

IPMI

Структура стандарта IPMI обладает рядом особенностей, характерных для большинства разработок того времени. Объективно они были предопределены следующими факторами:

1)   невысокий уровень развития процессоров и микроконтроллеров, их низкое быстродействие и высокая цена;

2)  отсутствие широкого спектра готовых решений различных задач как «на чипе», так и в виде программных библиотек и компонентов;

3)  необходимость минимизировать затраты памяти и ширину канала передачи данных при работе с протоколом удалённого управления.

Указанные ограничения задали структуру протокола IPMI на долгие годы вперед. Это классический протокол, ориентированный на сообщения. Каждое сообщение протокола подробно описано  в стандарте. Это позволяет создавать клиенты на базе ПЛИС (программируемые логические интегральные схемы, FPGA), микроконтроллеров или (позднее) систем на кристалле (SoC), что, в свою очередь, понижает стоимость решения и упрощает его встраивание в архитектуру вычислительной системы.

IPMI – это самостоятельный, отдельный протокол, не использующий сторонние стандарты. Основой схемой,  применяемой  для  обмена  данными, является «вопрос-ответ». Формат передачи запросов и ответов по сети (LAN) приведён на рис. 1. Сообщения протокола сильно детализированы на уровне байтов и даже отдельных битов. Пример ответа на запрос IPMI приведён в таблице.

Рис. 1. Формат передачи запросов и ответов протокола IPMI по сети  (LAN)

Пример ответа на запрос IPMI

Система команд IPMI потенциально расширяется с целью учёта интересов отдельных производителей. При этом оба конечных устройства должны поддерживать структуру сообщений полностью или частично. В исходном варианте спецификации IPMI не было иного способа узнать, в каком объёме конечное устройство поддерживает ту или иную систему сообщений,  кроме  как  обратиться  к  нему и получить ответ с кодом успешного  завершения или с кодом ошибки. В версии 2.0 задан специальный набор необязательных к реализации  команд  для реализации этой задачи: Get NetFn Support, Get Command Support.

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

Спецификация IPMI включает также определение специальной шины IPMB, построенной на основе I2C. Таким образом, IPMI является монолитным стандартом, включающим в себя модель данных, протокол обмена и шину передачи.

RedFish

Структура стандарта RedFish значительно отличается от классических протоколов обмена типа IPMI. Важно отметить, что клиент-серверный обмен данными в RedFish строится по принципу REST (Representational State Transfer). Между обменами не сохраняется контекст. Модель данных и протокол обмена разделены. При этом модель данных и протокол обмена строятся с использованием хорошо отлаженных и популярных сторонних стандартов.

Для транспортировки сообщений протокол обмена использует стандарт HTTPS. Данные в теле HTTP-сообщения упакованы при помощи ещё одного стандарта – JSON. Также при обмене используются и HTTP-заголовки, в которых может передаваться разнообразная информация, например ключ сессии.

Модель данных не описывается в стандарте жёстко. Её структура формируется описанием в стиле стандарта Microsoft OData с применением XML. Пример реального описания небольшой ветки данных приведён на рис. 2.

Данное описание определяет элемент данных “RoleCollection” типа “Resource.1.0.0.ResourceCollecti on” и устанавливает его связь с элементом данных “Members”, представляющим из себя коллекцию элементов типа “Role.Role”. Необходимые для корректного функционирования схемы другие файлы и пространства имён декларируются директивами “Reference” и “Include”.

На основании одного или нескольких фай лов описания данных, подобных приведённому на рис. 2, сервер RedFish формирует схему данных. Она представляет из  себя  древовидную структуру  с исчерпывающим описанием элементов (включая возможность его записи и/или чтения) и перекрёстными ссылками между ними. Схематичное изображение возможной модели данных приведено на рис. 3.

<!-- Copyright 2014-2015 Distributed Management Task Force, Inc. (DMTF). All rights reserved.-->

<edmx:Edmx Version="4.0">

<edmx:Reference Uri="http://docs.oasis-open.org/odata/odata/v4.0/cs01/vocabularies/Org.OData.Core.V1.xml">

<edmx:Include Namespace="Org.OData.Core.V1" Alias="OData"/>

</edmx:Reference>

<edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/Resource.xml">

<edmx:Include Namespace="Resource.1.0.0"/>

</edmx:Reference>

<edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/Role.xml">

<edmx:Include Namespace="Role"/>

</edmx:Reference>

<edmx:DataServices>

<Schema Namespace="RoleCollection">

<EntityType Name="RoleCollection" BaseType="Resource.1.0.0.ResourceCollection">

<NavigationProperty Name="Members" Type="Collection(Role.Role)">

<Annotation Term="OData.Permissions" EnumMember="OData.Permissions/Read"/>

<Annotation Term="OData.Description" String="Contains the members of this collection."/>

<Annotation Term="OData.AutoExpandReferences"/>

</NavigationProperty>

</EntityType>

</Schema>

</edmx:DataServices>

</edmx:Edmx>

Рис. 2. Пример реального описания небольшой ветки данных (протокол RedFish)

Рис. 3. Схематичное изображение возможной модели данных (протокол RedFish)

Клиент в любой момент может запросить используемую сервером схему данных с помощью GET HTTP- запроса (рис. 4).

В ответ сервер обязан предоставить клиенту используемую схему данных в XML-формате. Таким образом, клиент может, например, предоставить оператору данную схему или самостоятельно определить, какой функционал доступен на данном сервере.

Для работы с данными используются методы  HTTP – в основном GET и POST (для запроса содержимого объекта и его записи соответственно). 

Рис. 4. GET HTTP–запрос используемой сервером схемы данных (протокол Red Fish)

Пример ответа на запрос данных об объекте “Chassis” методом GET дан на рис. 5:

За счёт широкого использования уже отлаженных и популярных стандартов протокол RedFish в значительной степени уменьшает стоимость разработки и упрощает отладку и поддержку конечного продукта. Например, на рис. 6 приведён небольшой фрагмент кода на языке Python, позволяющий очень просто получить серийный номер устройства. Конечно, такая простота покупается ценой значительно более неэкономного использования как вычислительных, так и транспортных ресурсов. Однако при современном развитии техники это не представляет существенной проблемы.

Рис. 5.  Пример ответа на запрос данных об объекте “Chassis” методом GET  HTTP)

Рис. 6. Небольшой фрагмент кода на языке Python для получения серийного номера устройства (протокол Red Fish) 

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

Литература

1. IPMI v 2.0 specification: http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-technical-resources.html
2. Redfish Scalable Platforms Management API Specification:  http://www.dmtf.org/standards/redfish
3. С. Жуков. Архитектура и принципы управления в AdvancedTCA-системах.  «Суперкомпьютеры»,  №2, 2010
4. С. Жуков, И. Починок, В. Медведев. Управление в системах AdvancedTCA: поддержка высокоскоростных механизмов передачи данных между модулями. «Мир компьютерной автоматизации: встраиваемые компьютерные системы», №5, 2013
5. Data Common Schema Definition Language : http://www.odata.org/documentation/