You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The <ahref="https://developer.hpe.com/blog/why-is-redfish®-different-from-other-rest-apis-part-1"target="_blank">first part</a> of this article presented the fundamentals of the Redfish® standard published by the Distributed Management Task Force (DMTF) consortium. This standard issued in 2015 aims to replace the aging Intelligent Platform Management Interface (<ahref="https://www.intel.com/content/www/us/en/products/docs/servers/ipmi/ipmi-home.html"target="_blank">IPMI</a>) to manage the lower layers of the local server or remote servers using a modern REST-type API. The most representative fundamentals are the separation of the protocol from the data modeling, a <ahref="https://developer.hpe.com/blog/getting-started-with-ilo-restful-api-redfish-api-conformance/"target="_blank">self-describing model</a> and OEM extensions. In this second part, you will find other unique properties contributing to the massive adoption by IT equipment manufacturers of this "hypermedia API".
15
+
The <ahref="https://developer.hpe.com/blog/why-is-redfish®-different-from-other-rest-apis-part-1"target="_blank">first part</a> of this article presented the fundamentals of the Redfish® standard published by the Distributed Management Task Force (DMTF) consortium. This standard issued in 2015 aims to replace the aging Intelligent Platform Management Interface (<ahref="https://www.intel.com/content/www/us/en/products/docs/servers/ipmi/ipmi-home.html"target="_blank">IPMI</a>) to manage the lower layers of the local server or remote servers using a modern REST-type API. The most representative fundamentals are the separation of the protocol from the data modeling, a <ahref="https://developer.hpe.com/blog/getting-started-with-ilo-restful-api-redfish-api-conformance/"target="_blank">self-describing model</a> and OEM extensions. In this second part, you will find other unique properties contributing to the massive adoption of this "hypermedia API" by equipment manufacturers.
14
16
15
17
## Actions
16
18
17
19
Redfish® resources support the GET request to retrieve their current state. Modifications or deletions can be performed to certain resources using POST, PUT, PATCH and DELETE requests. Until then, nothing exceptional in the world of REST APIs, except perhaps, that it is possible to retrieve the exhaustive list of possible requests on a given resource, by consulting the `Allow` header of GET request responses. Refer to the <ahref="https://developer.hpe.com/blog/why-is-redfish®-different-from-other-rest-apis-part-1"target="_blank">Allowed requests</a> paragraph in part 1.
18
20
19
-
However, other types of operations are difficult to model with classic HTTP requests. For example, it is impossible to "read" the server's power button to know its status! Asking for the "return to factory settings" requires something else in the model to be executable.
21
+
However, other types of operations are difficult to model with classic HTTP requests. For example, it is impossible to "read" the server's power button to know its status! Asking for the "return to factory settings" of a storage controller may require additional parameters like the preservation (or not) of existing logical volumes.
20
22
21
-
To address these two cases and others, Redfish® offers the concept of Actions. These are special POST requests including the operation(s) to be performed and an empty body or a body with parameters. The POST endpoint as well as the parameters and their possible values are described in an `Actions{}` object contained in the response to a GET. Figure 1 shows the retrieval of the list of possible actions on the `ComputerSystem` subsystem of a given server, as well as their description. In this specific case, it is possible to perform a single action (`#ComputerSystem.Reset`) with a parameter (`ResetType`) which can take several values.
23
+
To address these cases and others, Redfish® offers the concept of **Actions**. These are special POST requests including the operation(s) to be performed and an empty body or a body with parameters. The POST endpoint as well as the parameters and their possible values are described in an `Actions{}` object contained in the response to a GET. Figure 1 shows the retrieval of the list of possible actions on the `ComputerSystem` subsystem of a given server, as well as their description. In this specific case, it is possible to perform a single action (`#ComputerSystem.Reset`) with a parameter (`ResetType`) which can take several values.
22
24
23
25
![Computer system actions](/img/fig1-descriptionactionreset.png"Computer system actions")
24
26
27
+
Figure 1: Computer system actions
28
+
25
29
Figure 2 shows the graceful restart action of a server with its destination (target URI), its payload as well as the payload of the response (`Success`).
The precise description of possible actions in the main body of GET responses allows Redfish® clients to carry out checks to avoid sending erroneous requests, therefore creating unwanted network traffic.
30
36
31
37
## The Redfish® event service
32
38
33
39
The Baseboard Management Controller (BMC) of modern servers communicates with almost all the server's subsystems. This privileged role allows it to be notified of events occurring in the system such as errors appearing in the memory, in the storage controllers or elsewhere. These events are stored in "log" files and SNMP traps can be triggered if the BMC has been configured beforehand.
34
40
35
-
SNMP is an aging protocol that, due to its design, can saturate a network during an event storm. The processing of events by Network Management Systems (NMS) can also constitute a bottleneck in terms of CPU load or storage. Furthermore, the security linked to this protocol is often mentioned as insufficient.
41
+
SNMP is an aging protocol that, due to its design, can saturate a network during an event storm. The processing of events by Network Management Systems (NMS) can also constitute a bottleneck in terms of CPU load or storage. Furthermore, the security linked to SNMP is often mentioned as insufficient.
36
42
37
43
An alternative to SNMP is the Redfish® Event Service which is based on the subscription principle. The major advantage of this principle is that events are sorted at source according to subscription criteria and sent only to subscribers. Thus, the risk of network saturation is reduced. The security of these messages is based on the Transport Layer Security (TLS) protocol used by HTTPS, and which is unanimously considered as secure.
38
44
@@ -44,35 +50,49 @@ The exhaustive list of registers that can be used to subscribe to events is retu
44
50
45
51
![Enumeration of prefixes available for event subscriptions](/img/fig3-registryprefixes.png"Enumeration of prefixes available for event subscriptions")
46
52
53
+
Figure 3: Enumeration of prefixes available for event subscriptions
54
+
47
55
### How to subscribe to events ?
48
56
49
57
Subscription to events is done by a POST request to the standard URI `/redfish/v1/EventService/Subscriptions` that includes, in its body, the IP address of the listening service and the list of events to send to it.
50
58
51
-
The listening service is a web service waiting for traffic on port TCP/443 (default) and that will process the received events. The DMTF provides such a service, available free of charge, on GitHub to facilitate the learning of this concept and for debugging code.
59
+
The listening service is a web service waiting for traffic on port TCP/443 (default) and that will process the received events. The DMTF provides such a service (free of charge) on GitHub to facilitate the learning of this concept and for debugging code.
52
60
53
61
Figure 4 is an example of subscribing to events generated by storage components in an HPE server. The BMC that receives this subscription must send the events to the IP address contained in the `{{EventListener}}` variable. The `Context` property as well as the optional `HttpHeaders` can be useful to the listening system. OEM properties complement the subscription description, with easy-to-understand properties.
The event service also allows you to easily test the subscriptions by creating an action to `/redfish/v1/EventService/Actions/EventService.SubmitTestEvent` with, in its body, the first part of the `MessageId` property correctly populated so that the test event is sent to the correct system (Figure 6).
73
+
Figure 5: Subscription collection
74
+
75
+
The event service also allows you to easily test the subscriptions by creating an test action to `/redfish/v1/EventService/Actions/EventService.SubmitTestEvent` with, in its body, the first part of the `MessageId` property correctly populated so that the test event is sent to the correct system (Figure 6).
Supervising a server fleet involves retrieving indicators such as the temperature of certain components, the energy spent by power supplies, CPUs or fans, in order to create metric reports, graphs or generate alerts. The most obvious recovery method is to locate the URI of the desired indicators and retrieve them on demand. There is an alternative to this "pull" type method: a "push" of indicators from the BMC towards subscribers. This alternative is possible thanks to the Redfish® telemetry service.
83
+
Supervising a server fleet involves retrieving indicators such as the temperature of certain components, the energy consumed by power supplies, CPUs or fans, in order to create metric reports, graphs or generate alerts. The most obvious recovery method is to locate the URI of the desired indicators and retrieve them on demand. There is an alternative to this "pull" type method: a "push" of indicators from the BMC towards subscribers. This alternative is possible thanks to the Redfish® telemetry service.
84
+
85
+
68
86
The telemetry entry point is at `/redfish/v1/TelemetryService` and has the following resources:
69
87
70
-
* Metric Definitions: CPU or memory bus usage, power supply consumption, etc. Each definition contains multiple properties such as the indicator type (decimal, integer, percentage), its maximum-minimum values and the URI allowing its value to be retrieved at a given time.
71
-
* Report definitions. For example, Figure 7 shows a report aggregating all indicators relating to the power used by the system. These definitions also indicate when to generate reports (periodically, on demand, or following a change in state or value). We also find the URI of the generated reports.
72
-
* Definitions of triggering actions. Depending on the value or trend (increasing or decreasing) of certain indicators, one or more actions will be triggered, such as recording in a log file, generating an event or requesting the generation of a new telemetry report.
88
+
***Metric Definitions:** CPU or memory bus usage, power supply consumption, etc. Each definition contains multiple properties such as the indicator type (decimal, integer, percentage), its maximum-minimum values and the URI allowing its value to be retrieved at a given time.
89
+
***Report definitions**: For example, Figure 7 shows a report aggregating all indicators relating to the power used by the system. These definitions also indicate when to generate reports (periodically, on demand, or following a change in state or value). We also find the URI of the generated reports.
90
+
***Definitions of triggering actions**: Depending on the value or trend (increasing or decreasing) of certain indicators, one or more actions will be triggered, such as recording in a log file, generating an event or requesting the generation of a new telemetry report.
Additional components such as network cards and storage controllers are modeled by Redfish® transparently to Redfish® clients. The retrieval of their state, their configuration and their firmware update is done in a similar manner to the other components of the server. This possible with the implementation in the BMC and in these components of the Platform Level Data Model (<a href="https://www.dmtf.org/sites/default/files/standards/documents/DSP0240_1.0.0.pdf" target="_blank">PLDM</a>) protocol. PLDM, published by the DMTF, standardizes messages between the BMC and server components. Thus, manufacturers of add-on cards and generic BMCs providers like OpenBMC, no longer have to implement proprietary protocols to communicate with the different subsystems. Figure 9 shows a Redfish® client communicating with a BMC. HTTPS requests sent by the client are transformed by the BMC into PLDM messages. These are transported by the Management Component Transport Protocol (<a href="https://www.dmtf.org/documents/pmci/mctp-base-specification-121" target="_blank">MCTP</a>) to the component that will respond via the same communication channel. When the dialogue between the BMC and the component is finished, the BMC responds to the client via HTTPS/JSON.
113
+
Additional components such as network cards and storage controllers are integrated in the Redfish® data model transparently to Redfish® clients. The retrieval of their state, their configuration and their firmware update is done in a similar manner to the other components of the server. This is possible with the implementation in the BMC and in these components of the Platform Level Data Model (<ahref="https://www.dmtf.org/sites/default/files/standards/documents/DSP0240_1.0.0.pdf"target="_blank">PLDM</a>) protocol.
114
+
115
+
PLDM, published by the DMTF, standardizes messages between the BMC and server components. Thus, add-on cards manufacturers and generic BMCs providers like <ahref="https://www.openbmc.org/"target="_blank">OpenBMC</a>, no longer have to implement proprietary protocols to communicate with the different subsystems.
116
+
117
+
Figure 9 explains the communication between a Redfish® client and an add-on card. HTTPS requests sent by the client are transformed by the BMC into PLDM messages. These messages are transported by the Management Component Transport Protocol (<ahref="https://www.dmtf.org/documents/pmci/mctp-base-specification-121"target="_blank">MCTP</a>) to the component that will respond via the same communication channel. When the dialogue between the BMC and the component is finished, the BMC aggregates the received PLDM messages and responds to the client via HTTPS/JSON.
92
118
93
119
![Offload Redfish® processing to device](/img/fig9-pldm4rde.png"Offload Redfish® processing to device")
94
120
95
-
121
+
Figure 9: Offload Redfish® processing to device
96
122
97
123
### PLDM for RDE
98
124
@@ -116,6 +142,8 @@ Very quickly after the publication of the first version of Redfish® in 2015, th
116
142
117
143
![ Link to Swordfish® URL](/img/fig10-swordfishschema.png" Link to Swordfish® URL")
118
144
145
+
Figure 10: Link to Swordfish® URL
146
+
119
147
## Security and component integrity
120
148
121
149
The majority of computer manufacturers have implemented secure production methods that guarantee all the components constituting a server do not contain viruses or other malware when leaving the factory or even when leaving the truck at final destination. Indeed, a lot can happen during intercontinental transport of electronic goods!
@@ -128,9 +156,11 @@ The operating system and BMC integrity measurements can be retrieved from the Tr
While the first part of this introduction to Redfish® focused on the architectural specifics of the API, this second part depicts goes deeper in the server data model and its smooth integration with additional components using powerful internal communication standards helping the improvement of security and firmware update.
163
+
While the first part of this introduction to Redfish® focused on the architectural specifics of the API, this second part goes deeper in the server data model and its smooth integration with additional components using powerful internal communication standards helping the improvement of security and firmware update.
134
164
135
165
Overall, the Redfish® API has sufficiently solid foundations to handle future long term developments; on the protocol side, everything is stable with HTTPs and JSON. On the other hand, there are new technologies that are starting to arrive on the market and their modeling by Redfish® is in progress. I am particularly thinking of the "Compute Express Link" (<ahref="https://computeexpresslink.org/"target="_blank">CXL</a>) which will change the internal architecture of the servers and which will therefore have to be modeled. The current <ahref="https://www.dmtf.org/standards/wip"target="_blank">project</a> can be consulted on the DMTF website.
0 commit comments