Redfish что это такое
redfish
Смотреть что такое «redfish» в других словарях:
redfish — [red′fish΄] n. pl. redfish or redfishes (see FISH) any of various fishes with a reddish coloration, as the red drum … English World dictionary
redfish — /red fish /, n., pl. (esp. collectively) redfish, (esp. referring to two or more kinds or species) redfishes. 1. Also called ocean perch, rosefish. a North Atlantic rockfish, Sebastes marinus, used for food. 2. See red drum. 3. sheephead. [ … Universalium
redfish — /ˈrɛdfɪʃ/ (say redfish) noun (plural redfish or redfishes) 1. → nannygai. 2. → sockeye. Usage: For variation in the plural inflection, see note at fish1 … Australian-English dictionary
redfish — Nerka Ner ka, n. [Russ. niarka, prob. fr. native name.] (Zo[ o]l.) The most important salmon of Alaska (
redfish — noun Date: 15th century any of various reddish fishes: as a. (1) a marine scorpaenid food fish (Sebastes marinus) of the northern Atlantic coasts of Europe and North America that is usually bright rose red or orange red when mature called also… … New Collegiate Dictionary
redfish — didysis jūrinis ešerys statusas T sritis zoologija | vardynas taksono rangas rūšis atitikmenys: lot. Sebastes marinus angl. hemdurgan; Norway haddock; ocean perch; red bream; redfish; rosefish; snapper rus. золотистый окунь; морской окунь ryšiai … Žuvų pavadinimų žodynas
redfish — noun a) edible red rockfish, Sebastes marinus, found in North America, also called rosefish or ocean perch. b) a large red edible fish, Sciaenops ocellata, also called channel bass or red drum … Wiktionary
redfish — noun (plural same or redfishes) 1》 a bright red edible marine fish. [Sebastes marinus (N. Atlantic), Sciaenops ocellatus (W. Atlantic), and other species.] 2》 Brit. a male salmon in the spawning season … English new terms dictionary
redfish — red•fish [[t]ˈrɛdˌfɪʃ[/t]] n. pl. (esp. collectively) fish, (esp. for kinds or species) fish•es. 1) ich Also called ocean perch rosefish a North Atlantic rockfish, Sebastes marinus used for food. 2) ich red drum 3) ich sheephead … From formal English to slang
Redfish в GAGAR>IN BMC
На сегодняшний день большинство крупных производителей серверного оборудования, таких как (DELL, IBM, HP) включают поддержку RedFish в прошивки для своих BMC контроллеров (Baseboard management controller) Разумеется, разрабатывая серверы GAGAR>IN, мы также добавили поддержку Redfish в наш BMC, который построен на базе открытого проекта OpenBMC. В этой статье расскажем, для чего мы используем RedFish и какие преимущества он нам даёт.
Если по простому, то весь функционал Redfish можно разделить на две больше группы: мониторинг и управление. Большая часть схемы Redfish содержит информацию об инвентаризации системы и текущем состоянии отдельных компонент. Но есть также множество идентификаторов OData (Open Data Protocol), которые отвечают за управление, изменение настроек BMC/UEFI и выполнение определённых команд. В этой статье мы коснёмся лишь мониторинга.
Мониторинг
В рамках развития системы мониторинга Zabbix, о которой мы писали в предыдущей статье об OCP Experience Lab, стояла задача получения основных параметров работы наших серверов, таких как температура процессоров, потребляемая мощность, токи нагрузки, частоты вращения вентиляторов и т.д. в периоды простоя и максимальной нагрузки.
Среди опрашиваемых машин были как наши собственные серверы GAGAR>IN, так и модели других OCP производителей Wiwynn и MiTAC, произведенные по такой же спецификации Tioga Pass. При этом на серверах GAGAR>IN были установлены BMC контроллеры с прошивкой на основе OpenBMC, а на Wiwynn и MiTAC использовался MegaRAC SP-X от AMI (American Megatrends Inc.).
И GAGAR>IN BMC и AMI MegaRAC SP-X поддерживают RedFish в качестве RESTful веб API для получения данных о сенсорах. Причем обе реализации схемы Redfish минимально отличаются друг от друга, что позволило нам разработать универсальный шаблон для Zabbix. Но начнем с простого.
Модель работы Redfish
Любой запрос Redfish формируется агентом используя HTTPS протокол передачи данных. Как правило используется метод GET для получения данных, но может и быть POST, PATCH и DELETE для специфических операций, которые мы обсудим позже. В ответ на запрос сервер формирует ответ в JSON формате, который содержит запрашиваемую информацию или сообщение об ошибке. Типовой URI запроса выглядит следующим образом
Структура дерева ресурсов Redfish
Запрос к корневому элементу дерева ресурсов Redfish возвращает набор элементов «Collections», которые в свою очередь могут содержать подразделы и отдельные конечные элементы. Для реализации Redfish в OCP серверах определены следующие элементы:
https://www.opencompute.org/files/OCP-Summit-2018-OCP-Profile-for-Server-v5.pdf
Для примера, вышеуказанный запрос на получение основной информации о системе возвращает нам JSON примерно вот такого вида (для краткости приведён небольшой фрагмент):
Но для задач мониторинга нас больше интересуют градусы Цельсия, амперы и вольты, поэтому следующий запрос мы шлём на URI:
В ответ получаем длиннющую «простыню», содержащую информацию о состоянии каждого датчика, установленного в системе, а их у нас в сервере несколько сотен. Привожу пример по одному датчику:
Воодушевленные возможностью получения такого огромного массива оперативной информации мы задумались об инструменте для её автоматической обработки. И тут на сцену выходит LLD (low level discovery) от Zabbix.
Низкоуровневое обнаружение в Zabbix
Низкоуровневое обнаружение (Low Level Discovery) даёт возможность автоматического создания элементов данных, триггеров и графиков в Zabbix для различных объектов мониторинга. В нашем случае мы будем создавать элементы данных для каждого датчика, показания которого мы получили в нашем Redfish ответе.
Затем мы будем строить для этого элемента данных графики на основании накопленных данных. Будем также создать прототипы триггеров, которые будут срабатывать при превышении оперативных значении определенных пороговых значений, и отправлять нам сообщения в Телеграмм.
Но вот незадача, мы же не ставим агента Zabbix на BMC. Вместо этого мы хотим парсить ответ на Redfish запрос. Причем Zabbix ждет от нас данные в формате JSON. Но структура этих данных имеет вполне определенный формат который, конечно же отличается от того, что мы получили в Redfish ответе. Что ж, для решения этих задач придется написать пару скриптов!
Скрипты LLD для GAGAR>IN BMC
Но неужели никто до нас не сталкивался с подобной задачей? Быстрый поиск на Zabbix Share показал, что не только сталкивались, но и успешно решали её. В частности удалось найти замечательный фреймворк для DELL iDRAC. Пришлось внести некоторые изменения в скрипты, потому что DELL-овская реализация Redfish отличается от используемой в OpenBMC. В частности идентификаторы OData выглядят следующим образом для разных BMC:
Dell iDRAC: /redfish/v1/Systems/System.Embedded.1/Processors
AMI MegaRAC: /redfish/v1/Systems/Self/Processors
Второй скрипт на Ruby использует выявленные первым скриптом идентификаторы OData (Open Data Protocol) и выполняет по ним отдельные Redfish запросы, после чего сохраняет эти данные локально для дальнейшей обработки. Есть смысл настроить запуск этого скрипта в Zabbix раз в пять минут или даже чаще, если есть желание получить более дискретные графики.
Но стоит учитывать тот факт, что объем хранимых данных в Zabbix вырастет пропорционально, да и poller может не успеть опросить все серверы, особенно если их десятки или даже сотни в дата-центре.
Последний скрипт на простом bash выполняет простую функцию парсера полученного вторым скриптом файла. Он формирует вывод в JSON формате, который может понимать непосредственно Zabbix. Всю остальную красоту рисует для нас Zabbix.
Красивые графики
Создав в Zabbix шаблон для вызова вышеописанных скриптов, мы настроили создание отдельных прототипов данных для каждого обнаруженного датчика, а также прототипов триггеров для тех датчиков, которые имеют пороговые значения. Ну и конечно же не забыли добавить прототипы для графиков, которые вы можете посмотреть ниже.
Вольтаж батарейки UEFI. При снижении значения ниже 2.73 вольт, сработает триггер оповещения. TDP первого процессора в Ваттах. При нагрузке на процессор мощность существенно растёт. Температура 15 ядра первого процессора. При превышении 81С сработает триггер.
Что дальше?
В результате мы получили 745 элементов данных, 118 графиков и 355 триггеров для одного GAGAR>IN BMC. Разумеется, мониторинг это не самоцель, поэтому активные триггеры мы оставили для ключевых элементов данных, таких как перегрев процессоров, общий health-статус компонентов и превышение пороговых значений токов.
Набор скриптов и шаблон Zabbix оформлен в отдельный репозиторий на github, а также выложен на Zabbix Share Стрижка, как говорится, только начата, поэтому мы приглашаем всех пользователей оборудования OCP брать наши наработки за основу и дорабатывать их. Некоторые секции данных, такие как, например, Storage и ManagedBy, в наших скриптах не обрабатываются, и будет здорово, если их поддержка будет кем-то добавлена.
В следующей статье напишем, как мы используем Redfish для управления сервером.
Redfish — альтернатива IPMI не за горами
В сентябре 2014 года группой компаний — лидеров в производстве серверного оборудования было объявлено о планах заменить протокол управления аппаратными средствами, известный среди ИТ специалистов как Intelligent Platform Management Interface (IPMI). Новому протоколу дали имя Redfish.
По мнению разработчиков Redfish, используемый сейчас протокол уже устарел и не позволяет раскрыть весь потенциал управления современным ИТ-оборудованием. IPMI впервые был введён в 1998-м году при поддержке корпораций Intel, Dell, NEC и Hewlett-Packard. В то время серверы ещё управлялись 8-разрядными микроконтроллерами что существенно ограничивало протокол ещё на стадии разработки. В 2004-м году протокол был обновлён до версии 2.0. Основными усовершенствованиями, внесенными в IPMI 2.0, стали новые алгоритмы аутентификации и шифрования, новая функция Serial Over LAN (поддерживает удаленное взаимодействие с приложениями, BIOS и операционной системой), встроенный межсетевой экран и новые параметры конфигурации и регистрации пользователей. IPMI для злоумышленников является прекрасной возможностью получить средства для низкоуровневого доступа к серверу, не требующего средств операционной системы. Проблема безопасности усугубляется еще и тем, что немало IPMI-конфигураций являются доступными и без введения пароля или же используют пароль по умолчанию.
Кроме того, эксперты отметили, что пароли хранятся в открытом виде, отсутствует шифрование отдельных разновидностей IPMI-трафика, а утечка одного-единственного пароля означает полный доступ ко всем серверам группы.
Данные причины являются основными для создания нового протокола, отвечающего современным требованиям как в управлении системами, так и в плане безопасности.
Перед разработчиками Redfish стоит много различных задач по разработке архитектуры, протокола и модели представления данных. Предполагается, что данная архитектура будет поддерживать широкий спектр систем, эксплуатируемых сегодня — от автономных машин до стоек с оборудованием, используемых в облачной сфере. Простота в меру возможностей — ещё одна цель Redfish. Соответствие средам программирования, которые широко принимаются сегодня так же является одним из ключевых принципов.
Среди других принципов, заложенных при проектировании Redfish:
1) интерфейс RESTful с использованием модели данных JSON;
2) протокол и модель данных разделены, что позволяет обновлять их отдельно друг от друга;
3) специальные правила задания версий для протокола и схемы;
4) устранение слабых мест в стандартах интернет-протоколов, в тех местах, где они сталкиваются с архитектурными требованиями, такими как JSON, HTTP и RFCs;
5) протокол сфокусирован на масштабируемых средах, но способен управлять текущими серверными средами;
6) фокус на out-of-band — осуществимымй в BMC и микропрограммных продуктах;
7) функционал должен быть доступным/понятным для среднестатистического пользователь;
8) реализация архитектуры должна быть максимально скрытная в целях безопасности.
Основные причины для использования RESTful:
1) даёт возможность лёгкой реализации в случаях, когда важна экономия (меньший объём передаваемых данных, чем у SOAP, меньше слоёв протокола, чем в WS-Man);
2) направлен на то, что бы стать самым распространённым методом доступа в промышленности;
3) прост в освоении, доступность документации;
4) есть ряд готовых инструментов и сред разработки, которые могут быть использованы для REST;
5) потребление RAM и СPU меньше, чем у других интерфейсов;
6) он поддерживает семантику модели данных и простое отображение общих операций CRUD;
7) соответствует принципу разработки: простота в пользовании;
8) он в равной мере может быть применён как во встроенных окружениях, так и в пространстве приложений, что даёт возможность сведения воедино кода компонентов в пределах экосистемы управления;
9) он изначально не привязан к схеме, благодаря чему хорошо адаптируется к любому языку моделирования;
10) благодаря ему Redfish возможно использовать для безопасного запуска механизмов в промышленности.
Разделение протокола от модели данных
Версия протокола меняется крайне редко, в то время как версии модели данных могут по мере необходимости модифицироваться. Таким образом, в первую очередь ожидаются инновации в модели данных, а не в протоколе. Это позволит по мере необходимости изменять модель данных, не трогая версию API или протокола.
Все ресурсы могут быть выражены в фомате JSON. JSON Schema будет использоваться и расширена для определения классов. Как JSON, так и JSON Schema широко используются и имеют большое количество инструментов для разных языков программирования, которые ускоряют разработку.
Поддержка синхронных и асинхронных операций
В то время как большинство операций в этой архитектуре могут исполняться синхронно, некоторые операции могут занять слишком много времени на выполнение, больше чем клиент согласен ждать. По этой причине некоторые операции могут быть асинхронными по усмотрению службы. Запрос асинхронной операции ничем не отличается от запроса синхронной.
Использование кодов HTTP Response позволит клиенту определить, как была завершена операция: синхронно или асинхронно.
Действия
Операции могут быть разделены на два вида: внутренние и внешние. У протокола есть возможность поддерживать внешние операции — те операции, которые не отображаются свободно на CRUD. Примеры — обновление программного обеспечения или системный сброс. Обновление программного обеспечения рассматривается как три возможных операции: передача образа для обновления в систему, загрузка образа системой и его последующая активация. Возможно объединить эти операции в одно единственное действие или один вызов функции.
В Redfish эти внешние операции называются действиями. Есть определённые действия, заданные в схеме Redfish, которые описывают каждый ресурс. Для этих стандартных действий схема Redfish снабжена нормативным языком. Расширения ОЕМ также разрешены схемой и отнесены к действиям.
Поддержка устройств (консоль, KVM-IP, командная оболочка, виртуальные носители)
В данной архитектуре поддерживается большое разнообразие устройств и служб. Очень важной составляющей являются механизмы поддержки консоли, (KVM-IP), командной оболочки (например, командная строка Linux) и удалённого виртуального носителя. Их поддержка реализована в этом стандарте и выражена в схеме на уровне представления модели данных, однако сами протоколы выходят за рамки этого стандарта.
Проблема с безопасностью в удалённом интерфейсе, который является программируемым, состоит в том, чтобы обеспечить не только защиту передаваемых данных но и защиту самого интерфейса который используется для взаимодействия с Redfish. Тут подразумевается разработка надлежащих механизмов контроля безопасности на уровне интерфейсов и защита каналов обмена данных.
Безопасность
Реализации должны поддерживать TLS v1.1 или выше и использовать только совместимые соединения TLS для транспортировки конфиденциальных данных.
Реализации должны поддерживать AES-256, основанные на TLS. Redfish должны рассмотреть вопрос о поддержке шифров, которые включают проверку подлинности и идентификации без использования доверенных сертификатов: TLS_PSK_WITH_AES_256_GCM_SHA384, TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, TLS_RSA_PSK_WITH_AES_256_GCM_SHA384.
AES-GCM является не только эффективным и безопасным, его аппаратные реализации могут достичь высоких скоростей при низкой стоимости и латентности.
Реализации должны поддерживать замену сертификата по умолчанию, если он предусмотрен, сертификатом, имеющим как минимум 4096 битный ключ RSA и RSA-SHA512 подпись.
Возможности Redfish
1) модель привилегий для мониторинга и управления;
2) системные настройки;
3) конфигурация BIOS;
4) система управления питанием;
5) информационные датчики (мощности / тепловые / жизнеспособности);
6) настройки сети;
7) настройки памяти;
8) журналирование;
9) служба конфигурации Redfish;
10) управление учётными записями;
11) версии микропрограмм;
12) аутентификация внутри инфраструктуры;
13) совместимость с CURL;
14) Автоматизация клиентов;
15) встроенные служебные процессы.
По заявлениям разработчиков, Redfish будет обладать возможностю управлять не только одной системой но и целыми стеллажами систем. Также Redfish — это своего рода реинкарнация IPMI, и это означает, что при переходе на новую систему пользователь не потеряет ни одной из функций, за которые так полюбилась IPMI. Управление по дополнительному каналу дает возможность производить обслуживание независимо от работоспособности ОС. Он может быть использован для мониторинга или изменения настроек BIOS / UEFI, а также контролировать статистику на уровне системы: температура, напряжение, вентиляторы и источники питания. По свежайшим заявлениям создателей, стандарт находится в стадии разработки и вскоре будет представлен для анализа организации по промышленным стандартам.
Эволюция стандартов управления вычислительными системами на примере IPMI и RedFish
В статье рассматриваются основные отличительные особенности стандартов на интерфейсы управления вычислительными системами IPMI и RedFish и делается попытка выявить общие тенденции развития данного класса интерфейсов.
Перспективы развития удалённого управления вычислительными системами всегда представляли интерес как для учёных, так и практиков сферы информационных технологий. Управление на расстоянии позволяет более рационально использовать ресурсы, эффективно управлять сложными комплексами в кризисных ситуациях и в целом значительно увеличивает гибкость системы и снижает эксплуатационные расходы.
Проблематика удалённого управления вычислительными системами возникла практически одновременно с их появлением. Это неудивительно – ведь конструктивные особенности таких систем делают их практически идеальными объектами для работы на расстоянии. Интерфейс IPMI (Intelligent Platform Management Interface), разработанный ещё в 1999 г., был одним из первых и, определённо, одним из самых удачных стандартов удалённого управления. Достаточно сказать, что он до сих пор широко используется практически на всех серверах для управления извне и во многих больших вычислительных системах для внутреннего интеллектуального управления (например, в системах AdvancedTCA [3],[4]).
В 2015 году рабочая группа DMTF (Distributed Management Task Force) предложила для использования первую версию нового стандарта RedFish. Главное его отличие от уже существующих заключается прежде всего в широком применении сторонних стандартов, гибкости в использовании, простоте и быстроте реализации, низкой стоимости обслуживания, а также сравнительной простоте отладки.
Ниже мы рассмотрим основные отличительные особенности данных стандартов и попытаемся выявить общие тенденции развития этого класса интерфейсов.
Структура стандарта 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.