Das IPMI (Intelligent Platform Management Interface) hat sich in knapp 20 Jahren zum Standard beim Management von Computer-Hardware im Unternehmen entwickelt. Künftig soll es aber unter dem Namen Redfish einen Nachfolger geben, der dank seines einfacheren Aufbaus noch mehr Unterstützung finden soll. Dabei zielt Redfish vor allem darauf, IPMI übers Netzwerk (IPMI-over-LAN) abzulösen. Außerdem soll Redfish aus dem Wildwuchs proprietärer IPMI-Erweiterungen lernen und für firmenspezifische Module einen definierten Erweiterungsmechanismus bieten.
Entwickelt wird der Redfish-Standard vom Scalable Platforms Management Forum (SPMF) der Distributed Management Task Force (DMTF). Version 1.0 des Standards [1] wurde im August 2015 veröffentlicht, danach folgten im Dezember 2015 Version 1.0.2 und schließlich im Mai dieses Jahres die Redfish Scalable Platforms Management API Specification 1.0.2. Federführend bei der Ausarbeitung des Standards waren Jeff Autor von HPE und Paul Vancil von Dell. Und so ist es auch kein Zufall, dass HPE (damals noch als HP) schon 2014 auf Proliant-Servern ein Management-Interface namens "HP RESTful API" anbot, das Redfish im Grundsatz ähnelt. Neben den beiden genannten Firmen sind aber noch eine ganze Reihe weiterer Hersteller mit an Bord, etwa Cisco, EMC, VMware, Microsoft, IBM, Fujitsu, Huawei, NetApp und Intel.
Der Standard setzt auf bekannte und erprobte Protokolle und Formate aus der Webwelt. Die Architektur gehorcht dem REST-Modell, das für das Auslesen und die Veränderung von Daten die "Verben" des HTTP-Protokolls verwendet, etwa GET, POST, PATCH und PUT. Dazu gehört die entsprechende Strukturierung der URLs, die den Aufbau der Managementinformationen widerspiegelt. Als Transportprotokoll für die Daten kommt HTTP mit TLS-Verschlüsselung zum Einsatz. Die Daten selbst sind im JSON-Format codiert, das einer verschachtelten Datenstruktur in Javascript entspricht.
Ein weiterer Baustein ist der offene OData-Standard, der den Aufbau der in JSON codierten Daten bestimmt. Ein Beispiel ist der folgende Ausschnitt aus einer JSON-Antwort von einem Redfish-Server, der die URL (OData-ID) für das System-Interface festlegt:
"Systems": {
"@odata.id": "/redfish/v1/Systems"
}
Dank der OData-Struktur ist es möglich, dass Software mit OData-Fähigkeiten auch ohne besondere Redfish-Unterstützung mit Redfish-Firmware interagiert. Beispiele dafür sind die Windows PowerShell oder Excel Power Query. Einfaches Debugging wird dadurch ermöglicht, dass sich die von der Firmware gelieferten Daten im JSON-Format einfach im Browser ansehen lassen. Mehr Komfort bringen Extensions wie JSONView, die durch Zeilenumbrüche und Einrückungen JSON besser lesbar machen.
Zu den über OData in Redfish repräsentierten Ressourcen gehören Systeme, Manager, Chassis, Tasks, Sessions sowie ein AccountService und ein EventService. Einen Ausschnitt zeigt das Diagramm im Bild oben.
Um Daten aus dem System auszulesen, setzt Redfish auf das HTTP-Verb GET. Um Daten zu ändern, können PUT und PATCH zum Einsatz kommen, wobei der Unterschied darin liegt, dass PUT einen Datensatz immer komplett ersetzt, während PATCH nur die aktualisierten Daten ändert. Weil PATCH damit letztlich fehlertoleranter ist, gilt es als der bevorzugte Mechanismus für Updates. Manche Implementierungen unterstützen überhaupt kein PUT. Wie einfach sich Daten abfragen lassen, zeigt das Listing 1.
Listing 1: Redfish mit Python
import requests import json system = requests.get("http://172.17.0.2/redfish/v1/Systems/1").json() print( system['SerialNumber'] ) serial = requests.get("http://172.17.0.2/redfish/v1/Managers/1/SerialInterfaces/1").json() print( serial['BitRate']
Die Management-Software kann sich mit Redfish dafür registrieren, über eintretende Ereignisse benachrichtigt zu werden. Dazu kommt HTTP Push zum Einsatz, das einen Redfish-fähigen HTTPS-Server als Empfänger voraussetzt. Künftig sollen aber auch noch andere Technologien für die Event-Benachrichtigung dazukommen. Bei Supermicro-Firmware beispielsweise ist derzeit eine Registrierung für maximal 16 Events erlaubt.
Zur Authentifizierung sind zwei Mechanismen gedacht: HTTP Basic Authentication und Session Based Authentication. Die Basic Authentication erfordert Username und Passwort, die sich bei jedem HTTP-Request übergeben lassen. Alternativ ist es möglich, sich mit den Credentials zu Beginn einer Session einzuloggen (POST redfish/v1/SessionService/Sessions/) und vom Server ein Session-Token (X-AuthToken) zu erhalten, das bei weiteren Anfragen zur Authentifizierung dient. Je nach Implementierung können neben lokalen Userdaten auch LDAP oder Active Directory als Backend dienen.
Trotz des relativ jungen Alters von Redfish gibt es jetzt schon einige Hardware-Plattformen für den neuen Standard. HP unterstützt Redfish mit der Version 2.30 der iLO-4-Firmware und dem Chassis-Manager des modularen Moonshot-Systems. Supermicro will Redfish auf der X10-Generation seiner Boards und künftigen Baureihen anbieten, wobei alle Baseboard Management Controller (BMC) ab Version 3 das Interface unterstützen sollen. Intel arbeitet währenddessen am Support für UEFI 2.5 HTTP Boot.
Bei Dell kommen Kunden mit Version 2.30.30.30 von iDRAC (integrated Dell Remote Access Controller) in den Genuss von Redfish. Auch das OpenCompute-Projekt arbeitet daran, Redfish in die offene Hardware zu integrieren. Wer selbst noch keine Redfish-fähige Hardware besitzt, kann sich über simulierte Umgebungen (Mockups) damit vertraut machen, die die DMTF online anbietet [2], und sich die Python-Library [3] ansehen, die unter anderem den Code für diese Simulationen enthält.
Im Rahmen des Standards bleibt es jedem Hersteller überlassen, eigene Erweiterungen für Redfish zu programmieren, die über eine "wohldefinierte" Schnittstelle in das System integriert werden. So bietet etwa HP zusätzlich zu den Basisfunktionen noch UEFI-Systemkonfiguration, Smart Storage Status und weitere Aktionen zum erweiterten iLO-4-Management.