Redfish

Referenz zum Treiber Redfish: HTTPS-Verbindung zu einem BMC, Adressierung über Ressourcenpfad und JSON-Zeiger, Lesevorgänge, Schreibvorgänge per PATCH und Typen.

Der Treiber Redfish liest und schreibt Verwaltungsdienste nach DMTF Redfish: die REST-API, die BMCs von Servern (Baseboard Management Controller), Gehäuse und andere Hardware im Rechenzentrum für die Verwaltung außerhalb des Betriebssystems anbieten. Das ist ein gewöhnlicher Treiber im Client-Betrieb, Ganter Lab verbindet sich mit der Anlage, und der Übertragungsweg ist immer HTTPS: Gehärtete BMCs bieten nichts anderes an, und der Treiber fällt von sich aus nie auf einfaches HTTP zurück.

Typische Punkte, die so gelesen werden: Betriebszustand der Stromversorgung, Zustand von Secure Boot, Zustand von Gehäuse und Verwaltungscontroller, Firmwareversion, Temperaturen und Lüfterwerte aus den Ressourcen zur Wärme.

Verbindungsfelder

Beim Verbinden prüft der Treiber den Dienst, indem er die Dienstwurzel (/redfish/v1/) liest. Das TLS-Zertifikat des BMC muss die übliche Zertifikatsprüfung von Windows bestehen: Ein selbst ausgestelltes Zertifikat eines BMC muss von diesem Rechner als vertrauenswürdig eingestuft sein, bevor sich das Gerät verbindet. Eine fehlgeschlagene Verbindung sagt auf der Seite Ereignisse und in der Protokolldatei des Tages, warum, mit dem zugrunde liegenden Fehler dahinter, ein abgelehntes Passwort und ein nicht vertrauenswürdiges Zertifikat sind also auseinanderzuhalten.

Das Abfrageintervall ist einstellbar: Der Standard des Geräts (1000 ms) gilt für jeden Tag, der keinen eigenen nennt.

Adressierung der Tags

Ein Redfish-Tag wird über einen Ressourcenpfad und einen wahlweisen JSON-Zeiger in das Dokument adressiert, das diese Ressource zurückgibt:

Beispiele der zusammengesetzten Adresse (als Vorschau der Quelle auf dem Bus gezeigt, die nur gelesen wird):

• redfish/v1/Systems/1#/PowerState: der Betriebszustand des Systems als Zeichenkette.
• redfish/v1/Chassis/1/Thermal#/Temperatures/0/ReadingCelsius: der erste Temperaturfühler, als Zahl.
• redfish/v1/Systems/1/SecureBoot#/SecureBootEnable: Secure Boot, als Wahrheitswert.

Bei einem Lesevorgang holt der Treiber die Ressource per GET, liest das JSON, folgt dem Zeiger und wandelt das Ergebnis in den erklärten Datentyp des Tags. Ein Zeiger, der nichts im Dokument benennt, und ein Feld, das das Dokument als JSON-null trägt, lesen beide als kein Wert: Der Tag geht auf schlechte Qualität, und seine Regel für Lesefehler entscheidet, was dargestellt wird, statt dass das Wort null als guter Messwert ankommt. Eine Antwort, die kein JSON ist, wird unmittelbar als der erklärte Typ gelesen.

Schreiben

Tags mit einer schreibbaren Zugriffsart schreiben das adressierte Feld per PATCH: Der Treiber baut das kleinste JSON-Dokument, das nur den Pfad des Zeigers abdeckt (bei /Parent/Child den Rumpf {"Parent":{"Child":<value>}}), und sendet es an die Ressource. Daraus folgen zwei Einschränkungen:

• Ein Schreibvorgang verlangt einen JSON-Zeiger. Ein Tag auf das ganze Dokument (leerer Zeiger) lässt sich nicht schreiben: Der Bereich des Tags lehnt die Kombination schon beim Bearbeiten ab und sagt, dass das Feld fehlt, und ein Versuch, der den Dienst dennoch erreicht, schlägt mit dem Grund im Journal fehl.
• Der BMC entscheidet, was schreibbar ist; ein PATCH, den der Dienst ablehnt, liest sich als fehlgeschlagener Schreibvorgang.

Wie überall sonst ist der Wert, den Sie in das Schreibfeld des Tags tippen, der technische Wert, und die Umrechnungsstufen des Tags werden rückwärts durchlaufen, bevor der Rohwert auf den Bus geht, wie auf der Seite Connector beschrieben.

Unterstützte Datentypen

Boolean, Int32, Int64, Float, Double und String. Wählen Sie den Typ, der zum JSON-Feld passt: Wahrheitswerte für Kennzeichen wie SecureBootEnable, Zahlen für Messwerte, Zeichenketten für Zustände wie PowerState oder Health.

Befehle

Ein Redfish-Dienst veröffentlicht je eine Aktion für alles, worum er gebeten werden kann, jede unter ihrem eigenen Pfad unter der Ressource, auf die sie wirkt. Die Station rät sie nicht, weil nur die Dokumentation der Hardware sagt, welche es gibt: Sie erklären sie am Gerät, auf der Karte Befehle seiner Seite. Jeder Befehl trägt einen Namen, den Aktionspfad (redfish/v1/Systems/1/Actions/ComputerSystem.Reset) und wahlweise den Namen des einen Werts, den er nimmt (ResetType); der Befehl Ausführen in der Zeile sendet ihn, und was der Dienst geantwortet hat, wird zurückgemeldet. Ein Befehl wird außerdem zu einer Methode am Gerät im eigenen OPC UA-Adressraum dieser Station, alles, was eine Methode aufrufen kann, kann ihn also erteilen.

Der Wert reist als Rumpf der Anfrage. Ein Wert, der bereits JSON ist, wird so gesendet, wie er geschrieben steht; alles andere wird als {"<der Name, den Sie erklärt haben>": "<der Wert>"} gesendet, was die Form ist, die die Reset-Aktion von Redfish selbst erwartet.

Gerätesuche

Die Schaltfläche Suchen liest einen Dienst: Tragen Sie seine Adresse auf der Karte Umfang des Suchlaufs auf der Seite des Treibers ein (https://bmc-host oder die Adresse, die der Hersteller dokumentiert), und der Suchlauf geht das erste System, den ersten Verwaltungscontroller und das erste Gehäuse dieses Dienstes durch und bietet das Gerät mit diesen Punkten fertig zum Hinzufügen an. Der Suchlauf liest den Dienst über HTTPS und ohne Anmeldedaten, weil er läuft, bevor es das Gerät gibt, das sie hielte, ein Dienst, der jede Anfrage anmeldepflichtig macht, antwortet also nichts und wird stattdessen von Hand angelegt. Die eigene Suche von Redfish über SSDP braucht UDP-Multicast, das der Treiber im Prozess nicht macht, über Rundruf wird also nichts gefunden: Der Suchlauf liest die Adresse, die Sie ihm geben.