Redfish Based Platform Management Interface for COM-HPC
February 08, 2022
Blog
The PICMG has defined a set of standardized side-band/out-of-band management commands for the recently published COM-HPC Server-on-Module standard. It is called the COM-HPC Platform Management Interface specification, or COM-HPC PMI for short.
Made for IT Administrators
For operators of distributed systems, the main benefits of COM-HPC PMI concern system maintenance and health management, the detection of anomalies as well as continued system access in the event of system failure to allow them to initiate recovery measures without having to call out a service technician.
COM-HPC PMI implements IPMI and Redfish
The naming of COM-HPC PMI might be a little confusing as it could imply that it is solely an adaptation of the IPMI instruction set, which is usually implemented on a discretely integrated board management controller (BMC) that can be accessed via a network connection, a serial interface and/or LPC/eSPI. In fact, this new platform management interface also implements Redfish, making it much more comprehensive and flexible than first appearances would suggest.
Managed by the Distributed Management Task Force (DMTF), the Redfish standard can be used as an alternative or complement to IPMI-over-LAN and provides a unified RESTful programming interface that is ideal for remote maintenance of edge servers and gateways. It is also called REST API or RESTful API, where REST stands for representational state transfer. The name signifies the transfer of the transition from the current state to the next state of an application.
Ultimately, it is an architecture for web services and distributed systems that uses https requests to access and utilize data. All that’s needed is a browser with a RESTful plug-in and a URL to launch the services. Main advantages of this architecture include the widespread use of the http/https standard for data transfer, which distinguishes Redfish from other services such as SOAP. Also, the payload metadata overhead is smaller as there is no need to create compute intensive XML based messages.
The Redfish Interoperability Standard
The DMTF uses this engineering paradigm for the Redfish interoperability standard – which is available open source – to manage converged and hybrid IT as well as Software Defined Data Centers (SDDCs) simply and securely. Redfish is both human and machine readable, with the payload designed in the JavaScript based data exchange format JSON. The Common Schema Definition Language is used as protocol (OData v4). This combination of fundamentals makes Redfish a hypermedia API. As such, it enables a variety of implementations via a unified interface, allowing the detection of resources as well as their management and that of events and tasks.i
Master data typically includes the name of the manufacturer and the serial number; transactional data comprises, for instance, current processor temperature or power consumption of the board or module. The starting point of any Redfish service is the device URL, followed by the URI (Unified Resource Identifier) /redfish/v1. As a rule, Redfish – just like IMPI – is implemented on a discrete BMC in the target system. This can be the BMC of the carrier board or the module management controller (MMC) of the COM-HPC module. In COM-HPC, information is then requested from the so-called collection services Systems, Chassis and Managers.
Logical system data, such as information about the module manufacturer, integrated processor, status and boot sequence, is retrieved from Systems. Physical information is managed by Chassis. This includes, for example, current temperature or power consumption values and limits. Finally, Managers is used to access information about the OS console, the physically installed management hardware and the administrative functions of the system management subsystem – i.e., the BMC and/or MMC.ii
The Redfish Schema for COM-HPC Implementations
However, Redfish separates the definition of the protocol from the data model (schema). Therefore, the Redfish protocol is basically static, which is good for users. Redfish programmers, on the other hand, can modify each resource defined in the data model independently. This makes Redfish highly flexible and future-proof as it is possible to add resources when necessary or to update the data model of existing resources to meet new requirements.
The tradeoff is that Redfish implementations are never standardized. Neither are the protocol version nor the supported functions in the respective specifications fixed. That’s why there is a Redfish interoperability concept with which to communicate the implementation requirements set forth in a Redfish interoperability profile in a single statement. Such a profile defines both the Redfish protocol requirements a particular implementation should meet, and the subset of the Redfish schema it should support.
The PICMG has now defined a precise Redfish interoperability profile schema for COM-HPC implementations. The way to keep and manage inventories is now the same for each implementation, which secures investments in the long term, even for custom-developed management consoles. Hundreds of ‘shall’ and ‘should’ specifications cover virtually all required functions to monitor and manage distributed systems. Ultimately, it is all about ensuring that services remain available even when a system is out-of-band – i.e., no longer accessible via the standard routes provided during correct system operation.
The PICMG has further specified the physical architecture of the communication channels for the management of COM-HPC Client and Server modules and their carrier boards. The specification says that the Redfish interface should be provided on the carrier board. There is also an option to provide Redfish via an MMC on the module itself. This, however, requires Ethernet connection of the MMC. Compliance with the Redfish interoperability profile for COM-HPC is also mandatory.
Different Implementation Options
The IPMI and Redfish based COM-HPC platform management interface specification can therefore be implemented both on the module and on the carrier, as well as on any combination of variants: Carrier boards with management interface can host modules with and without management interface. And modules with management interface can be operated on carrier boards with BMC or without. Ultimately, this ensures the greatest freedom of choice in the preferred configuration and full interoperability of the entire COM-HPC ecosystem. The only difference is that the side-band and out-of-band management options are of course not the same.
Developers can now decide whether they want a module with COM-HPC PMI, or whether it is sufficient for them to implement COM-HPC PMI via the BMC on the carrier board. The latter option also allows them to control the BMC firmware and its functions there. In general, implementation on the carrier is the less expensive method. To start off with, most common implementations are likely to be solutions that implement COM-HPC PMI on the carrier board.
Resources for implementing Redfish in COM-HPC systems are available at https://github.com/PICMG/com-hpc-redfish. Here, developers can find various JASON mockups for the Redfish interface – from managed carrier boards with either one or four COM-HPC modules with full management and MMC, to the simplest form with managed carrier boards and a simple unmanaged module without COM-HPC IPMI implementation. Users can download and evaluate the mockups on local systems using web browsers. However, prior installation of a RESTful plug-in is required.
Caption: COM-HPC PMI with Redfish uses the popular https standard for communication. A nice side effect for administrators: In most cases, there’s no need for additional firewall rules since the communication goes via the standard TCP port 443.
Caption: The URL followed by redfish/v1 is the starting point for the Redfish services Systems, Chassis and Managers.iii
Caption: Redfish and IPMI implementations vary in level of complexity. Overall, implementation on the carrier board is the recommended method.
congatec is a rapidly growing technology company focusing on embedded and edge computing products and services. The high-performance computer modules are used in a wide range of applications and devices in industrial automation, medical technology, transportation, telecommunications and many other verticals. Backed by controlling shareholder DBAG Fund VIII, a German midmarket fund focusing on growing industrial businesses, congatec has the financing and M&A experience to take advantage of these expanding market opportunities. congatec is the global market leader in the computer-on-modules segment with an excellent customer base from start-ups to international blue chip companies. Founded in 2004 and headquartered in Deggendorf, Germany, the company reached sales of 127.5 million US dollars in 2020. More information is available on our website at www.congatec.com or via LinkedIn, Twitter and YouTube.
i. See intro of this paper. First paragraph on page 3 https://www.dmtf.org/sites/default/files/standards/documents/DSP2044_1.0.4.pdf
ii. See slide 5 at https://www.dmtf.org/sites/default/files/2017_12_RedfishTechnicalOverview.pdf
iii. Source is in Spec (for Members Review only) on page 78
