Bios redfish support что это
At the beginning of the standard, the following objectives are set: 1. Safety 2. High Scalable Management (SCALABLE) 3. Human Readable Data 4. Realization of existing hardware
In Redfish, each URL represents a resource, a service or a set of resources. Depending on the REST principle, use the Unified Resource Identifier (URI) to point to resources, the format of the client and resources is defined according to the Redfish architecture, and the client will determine the correct semantic according to the Redfish architecture (RedFish semantics is very intuitive) . In Redfish, all resources are linked from the service entry point (root), which is always located in / redfish / v1.
Json quickly became a modern data format. It is essentially more readable than XML, gets a lot of modern language support, is the fastest growing data format of the web service API; OData defines a set of common RESTful conventions and provides interoperability between APIs. .
In order to achieve these goals, Redfish:
Provide RESTFUL interfaces by using the JSON payload and data model.
Separate the protocol with the data model, which allows individual revisions and uses for each model.
Specifies the version control rules for the protocol and mode.
This document is referenced by OData, OpenAPI, and RFC.
The organizational data model provides clear division and value-added functions in the same payload as standardized projects.
Make data in the payload as much as possible in the context.
Keep the flexibility to achieve. Do not bind the interface to any specific underlying implementation or architecture.
Focus on widely used features. In order to avoid complexity, do not add a function that only a small number of users pay attention to.
Redfish and IPMI
IPMI is a widely supported industry standard that specifies a set of interfaces to provide an external management and monitoring of the CPU, firmware (legacy BIOS or UEFI) and operating system (OS) of the host system. However, IPMI is now a legacy interface that has been in nearly 20 years and cannot meet today's functionality and security needs. IPMI is an older standard for external management, which is limited to a set of "minimum blending mother" commands (eg, power switch, restart, temperature reading, and fan speed). Therefore, users are restricted in a set of functions, because attempts to increase the supplier's extension of the IPMI function is not common on platforms from different vendors. At the same time, users are increasingly developing their own tools to achieve close integration, often have to rely on the management software. The features within IPMI lack standardization, plus more fragments due to repeated OEM extensions, resulting in vendor-specific solutions that cannot meet the needs of outwardly expand data center users.
Access implementation
Copy data to your web server. You can access the Redfish model and back up all files under the MOCK-UP path to the / Redfish / V1 path of your local hard drive, and the server provides the HTML page using the path. For example, you can download NGINX, set the JSON format, then load the model file into the HTML path.
Each URL contains:
Resource section / Redfish / V1
Redfish Schema defines two formats:
Odata- Schema format, Odata Schema Format (CSDL) definition is to facilitate universal ODATA tools and application resolutions
JSON Schema format, JSON Schema format definition is to apply to other environments, such as Python scripts, JavaScript code, and visualization.
GET executes data retrieval. POST is used to create a resource or use actions (see below). DELETE is used to delete resources, but only a few resources can be deleted. Patch is used to change one or more resources, attributes, and PUT is used to fully replace resources (only a few resource can be fully replaced, see below). HEAD is similar to get, but does not return host data, and the program that accesses the RedFish implementation can use the head to get the URI structure.
BIOS configuration management
Support query Next startup device, BIOS configuration option, modify the BIOS password, and restore the BIOS default attribute value.
BIOS configuration item
Advanced: ACPI settings, sleep settings, terminal configuration, serial port redirection settings, support traditional USB device features, XHCI switching, support large-capacity USB storage devices, configuring OptionROM loading policies, PXE settings, startup device detection count settings
Platform Configuration: Supports SATA Controller Settings, USB Settings, Display Device Selection, BIOS Serial Log Output Settings, SOL Function Settings, Software Error Injection Support Settings
Socket Configuration: Supports CPU CORE settings, hyperthreading feature settings, Monitor / MWAIT feature settings, Intel TXT function settings, Intel hardware assisted virtualization technology settings, security mode extension feature settings, hardware prefetch settings, EIST (P state) settings, TDP rating, Intel® Speed SELECT Settings, EIST PSD Function Settings, Turbo Mode Settings, CPU CORE Frequency Settings, Hardware P Status Setting, Hardware PM Interrupt Setting, EPP Setting, C Status Set, T Status Setting, Heat Monitor Settings, Power Performance adjustment settings
Server Management: Supports FRB-2 Timer, Timeout Policy Settings, OS Watch Dog Timers, Timeout Policy Settings
Security: Support Safe Start mode configuration, provide factory default secret key settings
Boot: Supports digital lock key status settings, start mode settings (UEFI and LEGACY), UEFI shell enable settings, start option settings
EDK2 implementation principle
The UEFI Redfish EDK2 solution is a valid and secure solution that end users can use the Redfish REST FULAPI for remote configuration (extra) UEFI platform configuration. For end users, the configuration of the UEFI firmware that accesses the same attribute defined in the Redfish mode is simple. Below is a block diagram of UEFIREDFISHEDK2 implementation. Below EDK2 Redfish Foundation[1]· It is an EDK2redfish Foundation that provides basic EDK2 drivers that communicate with Redfish service ( Redfish service ([19] . The RedFish service can be implemented in BMC to manage the system, or you can manage multiple systems on the network. In the figure EDK2 Redfish Client[2] Refers to the EDK2redfish client, which is an EDK2redfish application that is used to configure the platform by using the Redfish property. The EDK2redfish client also provides the Redfish property, consumption, and update Redfish properties with the UEFI platform. EDK2 Redfish Feature DXE Drivers [17] It is the next project after the EDK2redfish Foundation. Each EDK2redfish feature DXE driver is designed to communicate with a specific Redfish data model defined in the Redfish mode (eg, the attribute defined in the EDK2redfishbiosDXE driver to operate in the Redfishbios data model).
- EDK2redfish host interface DXE driver Redfish Host Interface[6]
Abstract EDK2 DXE drivers, based on the device descriptor and protocol type data provided in the platform-level Redfish host interface (defined in SMBIOS Type 42H [7]), create SMBIOS type 42 records via the EFI SMBIOS protocol. On the EDK2 open source implementation (emulator PKG), the data of the SMBIOS type 42 is from RedfishPlatformConfig.efi[20] Retrieve in the EFI variable created under Efishell. OEM can provide yourself for a platform-specific implementation PlatformHostInterfaceLib[11] Example.
Abstract DXE drivers to get the certificate of the Redfish service. On the EDK2 simulator PKG implementation, credentials use fixed account / passwords to connect to Redfish services established by the Redfish configuration file simulator. OEM can provide itself for a platform-specific implementation RedfishPlatformCredentialLib Example.
- EFI REST EX UEFI driver is RedFish service EFI REST EX UEFI Driver for Redfish service [4]
- EFIREDFISH found UEFI driver EFI Redfish Discover UEFI Driver[3]
EFIREDFISH Discovery Agreement (UEFI Specification 2.8, Section 31.1). Only the Redfish service discovery through the Redfish host interface. Use SSDP to UDP SSDP over UDP[18] The RedFish service found that there is no current. The driver is used to manage the EDK2redfish configuration handler protocol installed by the EDK2redfish feature driver. This is an EDK2redfish client driver written based on EDK2redfish, which is used to initialize the EDK2redfish feature driver.
- EFI REST JSON Structure DXE Driver EFI REST JSON Structure DXE Driver[9]
- EDK2redfish Configuration Handler UEFI Driver EDK2 Redfish Config Handler UEFI Driver[15]
This is the centralized manager of the EDK2redfish function driver, which calls each EDK2redfish feature driver installed EDK2redfish configuration handler protocol EDK2 Redfish Config Handler Protocol [16] The init () function starts to start the EDK2redfish feature driver. The EDK2redfish Configuration Processor driver is a UEFI driver that relies on the EFI REST EX protocol and uses the EFIREDFISH discovery protocol to discover the Redfish service of the system.
- EDK2 content coding library EDK2 Content Coding Library[12]
RedfishPkg\Library\JsonLib [14] This is an open source project Jansson's wrapper, which is a library of APIs that provide operational JSON payload.
- The platform components of the EDK2 simulator PKG:
The RedfishPlatformCredentialLibedk2 emulator platform implemented a certificate to establish communication between the UEFI firmware and the RedFish service. UEFI firmware and Redfish service[10]
The Redfish platform host interface library EDK2 simulator platform implementation provides information on establishing the SMBIOS type 42h record. [11]
Code analysis
Application / RedfishPlatformConfig / Save Network Related parameters to Variable, will be used in the following library;
RedfishPlatformHostingerFaceLib / Using the network parameter generating structure provides the following drive use;
RedfishhostingerfaceDXE / Use the interface provided above, add SMBIOS Type42, provide back Discover driver
The RedfishPlatformCredentialLib / platform verification related library is whether the two verification directions, one is the security startup is turned on, and the other is to exit the boot service, there is corresponding to the interface, provide the following drive.
RedfishcredentialDXE / Provide certification services;
Redfishlib / RedfishgetAuthInfo The above-driven authentication service used in this interface;
A key interface in the entrance RegisterProtocolNotify interface. This function notifies DXECORE When the protocol protocol is installed, the third parameter is sent to the registration of CorelocateHandle or CorelocateProtocol to get the handle or interface of the newly installed specified protocol, with EfiCreateProtocolNotifyEvent The interface function is exactly the same;
RedfishConfigCommonInit Do STOP processing when you exit DXE and exit BS, use it is RedfishCredentialDxe drive;
- RedfishDiscoverDXE / registration &gEfiRedfishDiscoverProtocolGuid, protocol
RedfishClientPkg
The UEFI RedfishClient EDK2 solution is implemented on the EDK2 Redfish Foundation (RedfishPKG), which utilizes the EFI protocol provided by the EDK2 Redfish Foundation to create, consume, and update the Redfish property managed by firmware. The solution requests an instance of the EFI REST EX protocol through the EFI Redfish Discovery Protocol, and interacts with the Redfish service with the Redfish service later. The basic part of this implementation is to map the EDK2 HII option to the corresponding Redfish property that has been defined in the standard Redfish mode published by the DMTF Redfish Working Group. The advantage of this design is that the interoperability between the servers generated by different OEMs is enhanced when configuring the platform through the Redfish service. Use the properties defined in the Redfish standard mode to configure the platform to reduce the cost of the Redfish client tool to have different implementations to comply with OEM servers. The solution also reduces the proprietary BIOS property defined by OEM, resulting in a difference in platform configuration names in the Redfish BIOS property registry, however, these different names refer to the same platform function.
Range of UEFI Redfish client EDK2 implementation
Platform configurable setting This is the first phase of the UEFI Redfish client EDK2 implementation. Associate the RedFish property with the HII option.
Firmware Management Platform Redfish Resources Currently UEFI Redfish Client EDK2 implementation has supported configuration of platform Redfish resources with firmware, but this requires additional support for EDK2 HII. Therefore, the configuration of the firmware management platform Redfish resource will be the second phase.
Below is a block diagram of the implementation of the UEFIREDFISH client EDK2.
Efiedk2redfish client frame diagram The function of each block is described in the following sections,
EDK2 Redfish Foundation [1]
The EDK2redfishred Foundation provides communication facilities with Redfish services. If the Redfish service is found, the credfish service is visited, as an EFI REST EX protocol instance of the Redfish service transport layer, etc. That is, the redfishpkg
Redfish Profile Simulator [2]
EDK2 Redfish JSON Schema to C Structure Convertor [3]
EDK2 Redfish Non-Collection [4] and Collection ***[5]
Non-collected and collected, feature drivers EDK2 Redfish feature drivers are an intermediate driver, it is locatedJSON Schema to C Structure convertersandEFI Platform Configuration to Redfish Protocolbetween. The Redfish feature driver is acquired and sets the platform configuration and combines it with the Redfish JSON Mode C to operate the Redfish JSON resource. Then apply the settings in the RedFish service to the platform configuration, and vice versa, update the platform configuration to the Redfish service. EDK2 Redfish Non-Collecting and Collection Functions Drivers are generated based on Redfish mode naming and automatic script.EDK2 Redfish non-collectionFunction driver manages resources for specific RESDIFSH resource types, and eDK2 Redfish CollectionFunction Driver Management Collection Resources have a member of the same resource type (such as computer system resources and computer system collection resources).
EDKII Redfish Platform Config Protocol [6]
The EDKII Redfish platform configuration protocol is an abstract driver that configures format and storage from the EDK2 EDKII feature driver. This protocol provides access to the platform configuration and the format and configuration storage interface with the Redfish feature driver. This platform can provide your own EDKII Redfish platform to configure driver instances to access the platform-specific configuration format and storage. On the EDK2 open source platform, the EDKII Redfish platform configuration protocol accesses the platform configuration in the format defined by EDK2 HII.
BelowEDKII_REDFISH_PLATFORM_CONFIG_PROTOCOL,
Other instances of EDKII Redfish Platform Config Protocol [7]
For those platform configuration formats based on non-EDK2 HII, driver instances provide their own implementation to get or set up platform configurations.
EDKII Redfish Feature Core DXE Driver [12]
The EdkiiredFish feature core DXE driver provides a protocol interface for automatically generated Redfish function drivers to register themselves for its managed Redfish resource URI.
The Redfish feature core DXE driver records the URI according to the URI hierarchy, and then launches the Redfish feature driver based on the hierarchy when triggering a particular event [11]. This ensures that the upper REDFISH resource is established before the lower resource. For example, computer system resources must be ready before memory resource management, because memory resources are part of the computer system resources.
Start-Up Event to Trigger EDKII Redfish Feature Core [11]
Starting event triggers the EdkiiredFish function core [11] This is an EFI event that triggers the core of the EDKII Redfish function, transmits the URI in the database, and executes a callback registered by the Redfish function driver. The event GUID is defined below the PCD, and the default is set to GefieventReadyTOBOTGUID.
This PCD can be overwritten to any event based on platform implementation. The core of the EDKII Redfish feature can be triggered earlier, such as before the BDS or in the early DXE phase, if the platform provides the EFI REST EX protocol, provided before the BDS phase.
EDK2 HII VFR Form [8]
EDK2 HII VFR Table [8] According to the UEFI specification 2.9 section 35.6 Form browser protocol, EFI_HII_REST_STYLE_FORMSET_GUID is used to represent the HII options declared in this form in this form interact with the REST architecture style. On the EDK2 open source platform, the REST architecture style refers to the Redfish service. In addition to defining EFI_HII_REST_STYLE_FORMSET_GUID in the form range, EFI_IFR_FLAG_REST_STYLE can also assign it to the HII option, which indicates that these options interact with REST services.
EDK2 HII UNI file [9]
EDK2HIIUNI file [9] is used in UNI files x-uefi-redfish Configure language to associate the HII option with a specific Redfish property. If the HII option string is assigned a X-UEFI-RedFish language, the HII option interacts with the EDK2 Redfish function driver.
For example, if the HII option is mapped to the properties in Processor.v1_0_0. X-UEFI-Redfish configuration language declaration is as follows,
X-UEFI-Redfish configuration language format:
The string that uses the X-UEFI-Redfish configuration language declared is the path to the property in the Redfish resource.
The root of the path is the REDFISH resource type represented in the X-UEFI-Redfish configuration language.
This path is independent of the Radfish resource type
Attributes in array objects
Attributes in the collection object:
EDK2 Build Tool [10]
EDK2 Build Tools [10] EDK2 Build is responsible for pulling the necessary EDK2 Redfish JSON mode to the C structure converter and EDK2 Redfish function driver to the EDK2 build process based on the X-UEFI-RedFish configuration language used in the form of HII VFR.
В сентябре 2014 года группой компаний — лидеров в производстве серверного оборудования было объявлено о планах заменить протокол управления аппаратными средствами, известный среди ИТ специалистов как Intelligent Platform Management Interface (IPMI). Новому протоколу дали имя Redfish.
Кроме того, эксперты отметили, что пароли хранятся в открытом виде, отсутствует шифрование отдельных разновидностей IPMI-трафика, а утечка одного-единственного пароля означает полный доступ ко всем серверам группы.
Данные причины являются основными для создания нового протокола, отвечающего современным требованиям как в управлении системами, так и в плане безопасности.
Перед разработчиками Redfish стоит много различных задач по разработке архитектуры, протокола и модели представления данных. Предполагается, что данная архитектура будет поддерживать широкий спектр систем, эксплуатируемых сегодня — от автономных машин до стоек с оборудованием, используемых в облачной сфере. Простота в меру возможностей — ещё одна цель Redfish. Соответствие средам программирования, которые широко принимаются сегодня так же является одним из ключевых принципов.
Среди других принципов, заложенных при проектировании Redfish:
Основные причины для использования 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 широко используются и имеют большое количество инструментов для разных языков программирования, которые ускоряют разработку.
Поддержка синхронных и асинхронных операций
Действия
Операции могут быть разделены на два вида: внутренние и внешние. У протокола есть возможность поддерживать внешние операции — те операции, которые не отображаются свободно на 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, а также контролировать статистику на уровне системы: температура, напряжение, вентиляторы и источники питания. По свежайшим заявлениям создателей, стандарт находится в стадии разработки и вскоре будет представлен для анализа организации по промышленным стандартам.
На сегодняшний день большинство крупных производителей серверного оборудования, таких как (DELL, IBM, HP) включают поддержку RedFish в прошивки для своих BMC контроллеров (Baseboard management controller) Разумеется, разрабатывая серверы GAGAR>IN, мы также добавили поддержку Redfish в наш BMC, который построен на базе открытого проекта OpenBMC. В этой статье расскажем, для чего мы используем RedFish и какие преимущества он нам даёт.
Redfish - это, как всем известно, спецификация и открытый индустриальный стандарт, который пришёл на смену устаревшему IPMI. Он используется для управления серверным оборудованием посредством RESTful интерфейса. Redfish разрабатывается некоммерческой ассоциацией производителей DMTF (Distributed Management Task Force) с 2014 года и к настоящему моменту достаточно заматерел. Актуальная спецификация Redfish версии 1.12.0 была опубликована 21 января 2021 года.
Если по простому, то весь функционал 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
Запрос к корневому элементу дерева ресурсов Redfish возвращает набор элементов "Collections", которые в свою очередь могут содержать подразделы и отдельные конечные элементы. Для реализации Redfish в OCP серверах определены следующие элементы:
Для примера, вышеуказанный запрос на получение основной информации о системе возвращает нам JSON примерно вот такого вида (для краткости приведён небольшой фрагмент):
Но для задач мониторинга нас больше интересуют градусы Цельсия, амперы и вольты, поэтому следующий запрос мы шлём на URI:
В ответ получаем длиннющую "простыню", содержащую информацию о состоянии каждого датчика, установленного в системе, а их у нас в сервере несколько сотен. Привожу пример по одному датчику:
Очевидно, что ReadingCelsius - это текущее значение температуры сенсора для Core 7 CPU1, UpperThresholdNonCritical - это порог высокой температуры, а UpperThresholdCritical - это значение критического состояния. Вот было бы здорово нарисовать эти значения на графике, да еще и генерировать оповещения при превышении UpperThresholdNonCritical. И так для каждого датчика.
Воодушевленные возможностью получения такого огромного массива оперативной информации мы задумались об инструменте для её автоматической обработки. И тут на сцену выходит 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
GAGAR>IN: /redfish/v1/Systems/system/Processors
Мы добавили в свои скрипты дополнительный параметр $TYPE, который позволял указывать тип BMC. В зависимости от этого подставлялись правильные идентификаторы OData.
Кроме этого пришлось повозиться с jq - замечательным обработчиком JSON, работающим в командной строке. Например, для получения заветного значения температурного датчика из приведенного выше JSON, пришлось использовать вот такую конструкцию:
cat $ | jq --arg TYPE "$TYPE" --arg NAME "$NAME" '.[$TYPE] | .[] | select(.Name==$NAME)' | jq ".$" | tr -d "'" | tr -d '"'
где BATCH - это имя файла, TYPE = 'Temperatures', NAME = 'Core 7 CPU1', а ITEM = ReadingCelsius. Если кто-то предложит более оптимальный вариант разбора, мы будем очень признательны.
Первый скрипт на Ruby, делая запросы по верхнему уровню схемы Redfish, обнаруживает все доступные группы элементов данных из всех вышеуказанных "Collections": Processors, Memory, Thermal, Power, Sensors. Настраиваем Zabbix на запуск этого скрипта раз в час - мы же не меняем набивку сервера каждые пять минут.
Второй скрипт на 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 для управления сервером.
Вступление от HP: эта публикация написана одним из наших заказчиков, который по долгу службы пожелал остаться анонимным. Все совпадения имён и айпишников считать случайными. Попробовать сделать то же самое можно в любое время в нашем демо-центре в Москве — желающих просим писать в комментарии.
Приветствую. Меня зовут Эдуард, и я системный администратор в небольшой компании, которая аутсорсит администрирование ИТ-инфраструктуры. Кхм… Уже похоже на клуб анонимных кого-то с проблемами? Ну да ладно, одна интересная проблема у нас действительно была, а сегодня мы расскажем, как мы с ней столкнулись, и как случайно её решили.
Для начала немного предыстории. Все же помнят, как весело было админить удалённое железо раньше, лет 5-8 назад? Пишем заявку инженерам в ДЦ, ждём, когда они подключат KVM, настраиваем BIOS/CMOS, выставляем загрузку по сети, ставим систему (это хорошо, если кто-то добрый уже написал генератор preseed/kickstart-файлов, и в ДЦ есть DHCP/PXE сервер). А потом у нас на всех серверах появился ipmi (ну со временем). Ох, как мы радовались первое время!
И сервер уже вроде бы ставит ОС. Остаётся только наблюдать за этим в консоли, если скучно. Огорчало только то, что BIOS всё равно приходилось обновлять руками и настраивать (ну там HT/VT-d включить, хотя бы). В итоге все серверы были настроены по-разному, в зависимости от того, в каком квартале их ставили. Ну вы же понимаете, что серверы всегда ставил самый младший админ.
Когда мы находили что-то критичное – мы шли и руками переключали настройки. Бардак, да и только. Но вообще всё это нас устраивало до того, как с нами случилась история, о которой я сегодня и буду рассказывать.
Стоит упомянуть, что часть клиентов мы размещаем прямо на своём железе (точнее на виртуалках на этом железе, которое рулится через ). Ну чтобы вам было легче представить – наша система сильно похожа на OpenStack. И вот, в один прекрасный день, к нам пришел заказчик и попросил «на его железе сделать систему для управления виртуальными машинами в приватном облаке». Мы обрадовались, начали ему показывать своё решение (уже после подписания контракта и ТЗ), ему всё понравилось. Всё понравилось, менеджеры уже открывают шампанское (а надо сказать, что контракт по нашим меркам был очень неплохой). И тут клиент показывает пальцем в пункт ТЗ и спрашивает – «а с этим как?». Сидят админы и недоуменно смотрят в этот пункт – «новые серверы должны автоматически добавляться в облако после инвентаризации, установки в стойку и подключения сети-питания». Мы начали показывать – вот смотрите, мы записываем сервер сюда (1c), добавляем его mac-адрес вот сюда (самописная web-морда для управления dhcp-сервером и pxe), запускаем скрипт, сервер загружается по сети, система ставится (мы с облегчением выдохнули, поняв, что хотя бы система ставится сама), потом мы ловим сервер при перезагрузке, усиленно жмем клавишу Del… В общем, представитель клиента посмотрел на это, почесал затылок, походил по переговорке, собрался с мыслями и произнес: «Да где ж тут автоматически? Вот давайте выкинем всё, кроме 1С, всё равно туда бухгалтеры сервер вносить будут, а не я, и того места, куда вы mac-адрес записывали». Ну и вскоре после этого ушел, добавив, что надеется на то, что задачу мы всё же решим.
Потом мы, как обычно, ТЗ решили прочитать. Нашли там всякие интересные пункты, которые мы (ну те, кто делал задачу, а не те, кто ТЗ подписывал и пересказывал его нам) увидели впервые. Например, мониторинг температуры в обход ОС, мониторинг потребления электричества, автоматическая настройка BIOS… Начали размышлять. Сначала склонялись к мысли, что ipmitool всё это может. Потом представили, как всё это будет выглядеть. Подумали про то, как обновлять настройки, про мониторинг датчиков… В общем, разошлись на выходные с задачей «изучить весь гугл на предмет альтернатив ipmi, которые могут».
Приходим в понедельник, все грустные, злые. А один админ сидит и улыбается. Логичным было пристать к нему с расспросами на тему того, зачем он читает ithappens, когда у нас такая беда. Как оказалось, радовался он по поводу того, что читал не ithappens, а Redfish server management spec v 1.0 (читать здесь). Почитали все вместе вслух, злиться перестали. Redfish оказался именно тем, что нам нужно. Взяли менеджера, заставили его обзванивать всех производителей серверов, чтобы найти железку, в которой Redfish реализован. Приходят через час и смеется, показывает пальцем на коробку у входа и говорит «всё, я нашел». Собственно, коробка оказалась коробкой от HP Proliant Gen9. Сервер мы нашли, вернули в лабораторию (и кто вообще догадался новенький неизученный сервер сразу в ДЦ везти…) и приступили к знакомству с HP REST API (которая и является реализацией Redfish в серверах HP).
Так как мы админы (это потом уже нам дали питониста и он нам всё написал и сделал красивый web-интерфейс), то первым делом мы сели писать sh-ники, которые будут делать то, что нам нужно. Конечно, мы бы не советовали ходить в Rest API консольным curl-ом и генерировать JSON через echo (ну или хотя бы потом не показывайте никому это), но вот поделиться примерами взаимодействия с HP ProLiant REST API будем рады (тем более, что сами представители HP нас об этом и попросили).
Возможностей там полно на самом деле, в документации 2 сотни страниц списка объектов и краткого их описания. Мы первым делом пытались выполнить свои основные задачи, как proof-of-concept. Конечно, часть из них можно делать и через IPMI, но мы решили использовать один инструмент, именно API.
Первым делом (ну хорошо, вторым, после подключения сервера в стойке и после того, как HP iLO получит IP-адрес), прописываем все настройки BIOS:
Научимся управлять питанием. Ребут «по кнопке»:
«Выдёргиваем кабель из розетки»:
Отправляем инженера «нажать кнопку питания»:
Спросим у сервера, кто он такой:
PATCH-запросом в эту же ручку можно изменить информацию о сервере внутри iLo.
Спросим MAC-адреса у сервера (да, в итоге мы пошли дальше и DHCP-сервер сам проводил инвентаризацию новых серверов, если находил незнакомый iLO в отдельном VLAN-е – для iLO мы выдавали динамические адрес, а потом уже заводили записи о статических адресах для сетевых карт сервера и интерфейса iLo):
Из предыдущего JSON-а мы вытаскивали также и количество памяти с моделью CPU, потом разработчики сделали интеграцию с 1С, сервер отправлял данные о себе и туда. Здесь же мы определяли и версию BIOS, чтобы ругаться об устаревших (или просто отличающихся по кластеру) версиях.
Ещё через REST API можно снять показания метрик питания (к сожалению, не во всех «уровнях» лицензии iLO):
Ещё мы нашли какую-то жуткую ручку, которая описывает состояние сервера – обороты вентилятора, температуру, состояние разных железок внутри сервера.
А ещё нашли объект, который говорит о состоянии сервера в целом (ОК/fail) и чем он сейчас занимается (в нашем примере он загружался):
В общем, sh-ник мы в итоге написали и отдали его разработчику. Он над нами посмеялся, мы его за это поругали, пригрозили рута отобрать… Но зато он потом написал модуль в наше облачко, который умеет добавлять и управлять серверами через Redfish (и HP REST API, соответственно). Ну а заказ мы в итоге выполнили.
Наверное, пора закругляться. Расскажем про тех, кто играл главные роли во всей это истории.
В статье рассматриваются основные отличительные особенности стандартов на интерфейсы управления вычислительными системами IPMI и RedFish и делается попытка выявить общие тенденции развития данного класса интерфейсов.
Перспективы развития удалённого управления вычислительными системами всегда представляли интерес как для учёных, так и практиков сферы информационных технологий. Управление на расстоянии позволяет более рационально использовать ресурсы, эффективно управлять сложными комплексами в кризисных ситуациях и в целом значительно увеличивает гибкость системы и снижает эксплуатационные расходы.
Проблематика удалённого управления вычислительными системами возникла практически одновременно с их появлением. Это неудивительно – ведь конструктивные особенности таких систем делают их практически идеальными объектами для работы на расстоянии. Интерфейс IPMI (Intelligent Platform Management Interface), разработанный ещё в 1999 г., был одним из первых и, определённо, одним из самых удачных стандартов удалённого управления. Достаточно сказать, что он до сих пор широко используется практически на всех серверах для управления извне и во многих больших вычислительных системах для внутреннего интеллектуального управления (например, в системах AdvancedTCA [3],[4]).
В 2015 году рабочая группа DMTF (Distributed Management Task Force) предложила для использования первую версию нового стандарта RedFish. Главное его отличие от уже существующих заключается прежде всего в широком применении сторонних стандартов, гибкости в использовании, простоте и быстроте реализации, низкой стоимости обслуживания, а также сравнительной простоте отладки.
Ниже мы рассмотрим основные отличительные особенности данных стандартов и попытаемся выявить общие тенденции развития этого класса интерфейсов.
Структура стандарта IPMI обладает рядом особенностей, характерных для большинства разработок того времени. Объективно они были предопределены следующими факторами:
1) невысокий уровень развития процессоров и микроконтроллеров, их низкое быстродействие и высокая цена;
2) отсутствие широкого спектра готовых решений различных задач как «на чипе», так и в виде программных библиотек и компонентов;
3) необходимость минимизировать затраты памяти и ширину канала передачи данных при работе с протоколом удалённого управления.
Пример ответа на запрос IPMI
Очевидно, что при построении стандарта, основной упор делался на подробное описание структуры обмена между управляющим и управляемым агентами. С одной стороны, это экономило вычислительные мощности и пропускную способность транспортных интерфейсов. С другой стороны, протокол не отличается гибкостью, все детали обмена зафиксированы в стандарте, допускаются лишь минимальные отклонения, да и то касательно уменьшения объёма ответа за счёт опциональных полей.
Спецификация IPMI включает также определение специальной шины IPMB, построенной на основе I2C. Таким образом, IPMI является монолитным стандартом, включающим в себя модель данных, протокол обмена и шину передачи.
RedFish
Структура стандарта RedFish значительно отличается от классических протоколов обмена типа IPMI. Важно отметить, что клиент-серверный обмен данными в RedFish строится по принципу REST (Representational State Transfer). Между обменами не сохраняется контекст. Модель данных и протокол обмена разделены. При этом модель данных и протокол обмена строятся с использованием хорошо отлаженных и популярных сторонних стандартов.
Модель данных не описывается в стандарте жёстко. Её структура формируется описанием в стиле стандарта Microsoft OData с применением XML. Пример реального описания небольшой ветки данных приведён на рис. 2.
Данное описание определяет элемент данных “RoleCollection” типа “Resource.1.0.0.ResourceCollecti on” и устанавливает его связь с элементом данных “Members”, представляющим из себя коллекцию элементов типа “Role.Role”. Необходимые для корректного функционирования схемы другие файлы и пространства имён декларируются директивами “Reference” и “Include”.
На основании одного или нескольких фай лов описания данных, подобных приведённому на рис. 2, сервер RedFish формирует схему данных. Она представляет из себя древовидную структуру с исчерпывающим описанием элементов (включая возможность его записи и/или чтения) и перекрёстными ссылками между ними. Схематичное изображение возможной модели данных приведено на рис. 3.
Читайте также: