IPMI-Ablösung: Der Migrationspfad zu Redfish


Titelbild: Redfish-Migration – von IPMI zum Nachfolgestandard

Eine IPMI-Redfish-Migration steht in vielen Rechenzentren inzwischen als Notwendigkeit auf der Agenda. Im Juni 2020 erklärten die IPMI-Promoter, zu denen Dell, HPE, NEC und Intel gehören, dass es keine weiteren Updates am IPMI-Standard mehr geben wird und Redfish dessen Nachfolger ist (DMTF, 2020).

Kurz beantwortet

IPMI wird seit 2020 nicht mehr weiterentwickelt, Nachfolger ist Redfish auf Basis von REST und JSON. Die Redfish-Migration läuft in vier Phasen: Inventur der Redfish-Fähigkeit, Parallelbetrieb beider Protokolle, schrittweise Umstellung der Automatisierung, Abschaltung von IPMI nur dort, wo die Umstellung stabil läuft.

Warum Redfish als Nachfolger von IPMI gilt

IPMI, seit den späten 1990er-Jahren im Einsatz, war für seine Zeit ein Fortschritt. Es lieferte einen Standard für den Fernzugriff auf Serverhardware, der über Herstellergrenzen hinweg funktionierte. Der DMTF, das Standardisierungsgremium hinter beiden Protokollen, beschreibt die zentrale Schwäche von IPMI so: Es ist auf den kleinsten gemeinsamen Nenner ausgelegt (DMTF, 2018). Funktionen, die nicht von jedem Hersteller gleich unterstützt wurden, blieben außen vor oder wurden proprietär nachgerüstet.

IPMI und Redfish im direkten Vergleich
Merkmal IPMI Redfish
Weiterentwicklung seit 2020 eingestellt laufend, zuletzt Version 2025.2
Technische Basis binäres Protokoll REST und JSON
Werkzeuge eigenes IPMI-Toolset nötig Standardwerkzeuge, etwa curl
Funktionsumfang kleinster gemeinsamer Nenner standardisierte Schemas für alle Hersteller
Firmware-Update-Service proprietär je Hersteller standardisiert seit Version 2016.2

Redfish setzt seit der Version 1.0 im August 2015 auf REST und JSON statt auf ein binäres Protokoll (DMTF, 2017). Das klingt zunächst nach einem technischen Detail, hat aber praktische Folgen. Ein curl-Aufruf gegen eine Redfish-Schnittstelle liefert eine lesbare JSON-Antwort, die sich direkt weiterverarbeiten lässt. Die gleiche Abfrage über IPMI verlangt oft ein spezielles Kommandozeilenwerkzeug und die Kenntnis binärer Rückgabecodes, die je nach Hersteller leicht unterschiedlich ausfallen können.

Was Redfish seit der ersten Version dazugewonnen hat

Der Standard wurde seit 2015 kontinuierlich erweitert. Mit Version 2016.2 wurden Firmware-Update-Services erstmals standardisiert und damit bei allen unterstützenden Herstellern über dieselbe Schnittstelle abrufbar (DMTF). Version 2020.4 ergänzte unter anderem Power- und Thermal-Management sowie eigene AccountTypes für KVMIP und Virtual Media, also für genau die Funktionen, die beim Fernzugriff auf Serverkonsolen gebraucht werden (DMTF, 2020).

Die Entwicklung ist damit nicht abgeschlossen. Laut dem DMTF-Newsletter vom August 2025 brachte allein die Version 2025.2 acht neue Schemas und 36 Aktualisierungen bestehender Schemas mit sich. Wer migriert, wechselt also zu einem Standard, der sich weiter verändert.

Die Redfish-Migration in vier Phasen

  1. Inventur. Welche Server im Bestand unterstützen Redfish bereits nativ, welche nur über ein optionales Firmware-Update und welche gar nicht? Diese Bestandsaufnahme entscheidet über den gesamten weiteren Zeitplan und sollte nicht übersprungen werden, so unspektakulär sie klingt.
  2. Parallelbetrieb. Neue Automatisierungsskripte werden gegen Redfish geschrieben und getestet, während der produktive Betrieb weiterhin über IPMI abgesichert bleibt. Dieser Parallelbetrieb ist der Kern jeder risikoarmen Redfish-Migration.
  3. Schrittweise Umstellung. Monitoring, Firmware-Rollouts und Provisioning-Skripte wandern nach und nach von IPMI-Aufrufen zu Redfish-Endpunkten, Server-Gruppe für Server-Gruppe statt auf einen Schlag.
  4. Abschaltung. IPMI wird nur für die Server abgeschaltet, bei denen die Umstellung vollständig abgeschlossen und über einen längeren Zeitraum stabil gelaufen ist.
Warum ein Schlussstrich unrealistisch istÄltere Hardware ohne Redfish-Unterstützung im BMC bleibt auf IPMI angewiesen, solange sie im Einsatz ist. Wer eine gemischte Flotte betreibt, unterstützt beide Protokolle über Jahre parallel. Jedes Verwaltungswerkzeug muss deshalb beide Wege gleichzeitig beherrschen.

Inventur der Redfish-Fähigkeit Ihrer FlotteWir lesen aus, welche Ihrer Server Redfish nativ sprechen, welche ein Firmware-Update brauchen und welche auf IPMI bleiben.

Inventur anfragen

Werkzeuge für die Umstellung

Für die praktische Umsetzung zählt, welche Werkzeuge im eigenen Betrieb bereits vorhanden sind und Redfish sprechen. Viele Automatisierungs- und Verwaltungswerkzeuge unterstützen den Standard inzwischen direkt, oft parallel zur bestehenden IPMI-Anbindung. Auch KVM Fleet setzt bei neueren Servern auf Redfish, um Firmware-Stände und Systeminformationen konsistent über die gesamte Flotte hinweg abzufragen, ohne für jeden Hersteller eine eigene Sonderlösung zu brauchen. Wie sich Firmware-Updates darüber hinaus organisieren lassen, beschreibt der Beitrag zu Firmware-Updates über hunderte Server. Die Architekturfrage dahinter behandelt der Beitrag zu KVM-over-IP im Flottenmaßstab.

Häufige Fragen

Können IPMI und Redfish parallel im selben Betrieb laufen?

Ja, das ist sogar der übliche Weg. Die meisten modernen BMCs unterstützen beide Protokolle gleichzeitig, sodass bestehende IPMI-Skripte weiterlaufen, während neue Automatisierung schrittweise auf Redfish umgestellt wird. Ein harter Umstieg an einem einzigen Stichtag ist selten nötig und in der Praxis auch nicht empfehlenswert.

Was passiert mit alten Servern ohne Redfish-Unterstützung?

Server ohne Redfish-fähigen BMC bleiben auf IPMI angewiesen, solange sie im Einsatz sind. Ein Ersatz allein wegen des Protokolls lohnt sich betriebswirtschaftlich selten, den Ausschlag gibt meist das reguläre Ende der Nutzungsdauer der Hardware.

Welche Verwaltungswerkzeuge sprechen bereits Redfish?

Die großen Serverhersteller bieten eigene Redfish-fähige Werkzeuge für ihre Plattformen an, ergänzt durch Verwaltungslösungen, die den Standard über mehrere Hersteller hinweg unterstützen. Vor der Redfish-Migration lohnt ein Blick in die eigene Werkzeugkette, um zu prüfen, welche Bestandteile bereits Redfish sprechen und wo noch eine Aktualisierung nötig ist.

Der nächste Schritt

KVM Fleet stammt aus der eigenen Entwicklung bei torck und spricht bei neueren Servern bereits Redfish, weil das Team den Umstieg im eigenen Betrieb selbst durchlaufen hat. Einzelne Funktionen der Software sind direkt aus dieser Redfish-Migration entstanden. Mehr dazu auf der Produktseite von KVM Fleet.

Frage zu diesem Beitrag?

Zwei Sätze zu Ihrer Situation genügen. Es antwortet jemand, der solche Systeme selbst baut.

Antwort innerhalb eines Werktags.torck · Code mit Drehmoment
Florian Blischke
Geschäftsführer torck GmbH · über 20 Jahre Softwareentwicklung
Florian Blischke ist Geschäftsführer der torck GmbH und seit über 20 Jahren in der Softwareentwicklung tätig. Er verantwortet Individualsoftware für Industrie und Handel, von der Anbindung physischer Prozesse über IoT bis zu Cloud-Architektur und daten- sowie KI-gestützten Systemen. Bei torck begleitet er unter anderem die Energieplattform Jouvoli und das Fleet-Management-Produkt KVM Fleet. torck entwickelt an den Standorten Maxhütte-Haidhof, Wien und Rabat und legt Wert auf Software, die im Betrieb tatsächlich funktioniert.

Steht bei Ihnen dieselbe Frage an?

Wir bauen seit 2017 Software für Industrie und Handel, von Maxhütte-Haidhof aus, mit Teams in Wien und Rabat. Ein Erstgespräch dauert 30 Minuten und kostet nichts. Danach wissen Sie, ob sich das Vorhaben lohnt, auch wenn die Antwort nein lautet.

Weitere Beiträge