Remplacement de l'IPMI : le parcours de migration vers Redfish


Image de couverture : migration vers Redfish – de l'IPMI vers la norme qui lui succède

La migration de l'IPMI vers Redfish figure désormais parmi les priorités de nombreux centres de données. En juin 2020, les promoteurs de l'IPMI, parmi lesquels figurent Dell, HPE, NEC et Intel, ont annoncé qu'il n'y aurait plus de mises à jour de la norme IPMI et que Redfish en serait le successeur (DMTF, 2020).

En bref

IPMI n'est plus développé depuis 2020 ; son successeur est Redfish, basé sur REST et JSON. La migration vers Redfish se déroule en quatre phases: inventaire de la compatibilité Redfish, exploitation en parallèle des deux protocoles, migration progressive de l'automatisation, désactivation de l'IPMI uniquement là où la transition fonctionne de manière stable.

Pourquoi Redfish est considéré comme le successeur de l'IPMI

L'IPMI, utilisé depuis la fin des années 1990, constituait une avancée pour l'époque. Il offrait une norme d'accès à distance au matériel serveur, compatible avec tous les fabricants. Le DMTF, l'organisme de normalisation à l'origine de ces deux protocoles, décrit ainsi la principale faiblesse de l'IPMI : il est conçu pour le plus petit dénominateur commun (DMTF, 2018). Les fonctionnalités qui n'étaient pas prises en charge de la même manière par tous les fabricants ont été laissées de côté ou ont fait l'objet d'ajouts propriétaires.

Comparaison directe entre IPMI et Redfish
Caractéristique IPMI Redfish
Développement suspendu depuis 2020 en cours, dernière version 2025.2
Base technique protocole binaire REST et JSON
Outils Nécessite son propre ensemble d'outils IPMI Outils standard, tels que curl
Fonctionnalités plus petit dénominateur commun des schémas standardisés pour tous les fabricants
Service de mise à jour du micrologiciel propriétaire, propre à chaque fabricant normalisé depuis la version 2016.2

Depuis la version 1.0 sortie en août 2015, Redfish utilise REST et JSON plutôt qu’un protocole binaire (DMTF, 2017). Cela peut sembler à première vue être un détail technique, mais cela a des conséquences pratiques. Une requête curl adressée à une interface Redfish renvoie une réponse JSON lisible, qui peut être traitée directement. La même requête via IPMI nécessite souvent un outil de ligne de commande spécifique et la connaissance des codes de retour binaires, qui peuvent varier légèrement d'un fabricant à l'autre.

Ce que Redfish a gagné depuis sa première version

La norme n'a cessé d'être enrichie depuis 2015. Avec la version 2016.2, les services de mise à jour du micrologiciel ont été standardisés pour la première fois et sont ainsi accessibles via la même interface chez tous les fabricants qui la prennent en charge (DMTF). La version 2020.4 a notamment ajouté la gestion de l'alimentation et thermique, ainsi que des types de compte spécifiques pour KVMIP et Virtual Media, c'est-à-dire précisément les fonctionnalités nécessaires à l'accès à distance aux consoles de serveurs (DMTF, 2020).

Le développement n'est donc pas achevé. Selon la newsletter du DMTF d'août 2025, la version 2025.2 a à elle seule introduit huit nouveaux schémas et 36 mises à jour de schémas existants. Quiconque procède à une migration adopte donc une norme qui continue d'évoluer.

La migration vers Redfish en quatre phases

  1. Inventaire. Quels serveurs du parc prennent déjà en charge Redfish de manière native, lesquels ne le prennent en charge qu'après une mise à jour optionnelle du micrologiciel, et lesquels ne le prennent pas en charge du tout ? Cet état des lieux est déterminant pour l'ensemble du calendrier à venir et ne doit pas être négligé, aussi banal qu'il puisse paraître.
  2. Fonctionnement en parallèle. Les nouveaux scripts d'automatisation sont développés et testés avec Redfish, tandis que l'exploitation en production continue d'être assurée via IPMI. Ce fonctionnement en parallèle est au cœur de toute migration vers Redfish à faible risque.
  3. Transition progressive. La surveillance, les déploiements de micrologiciels et les scripts de provisionnement migrent progressivement des appels IPMI vers les points de terminaison Redfish, groupe de serveurs par groupe de serveurs, plutôt que d'un seul coup.
  4. Mise hors service. L'IPMI n'est désactivé que pour les serveurs dont la migration est entièrement terminée et qui ont fonctionné de manière stable pendant une période prolongée.
Pourquoi il est irréaliste de tourner la pageLe matériel ancien dont le BMC ne prend pas en charge Redfish reste tributaire de l'IPMI tant qu'il est en service. Les exploitants d'un parc mixte prennent en charge les deux protocoles en parallèle pendant des années. Chaque outil de gestion doit donc maîtriser les deux méthodes simultanément.

Inventaire de la compatibilité Redfish de votre flotteNous déterminons quels sont vos serveurs qui prennent en charge Redfish en natif, ceux qui nécessitent une mise à jour du firmware et ceux qui restent sur IPMI.

Demander un état des stocks

Outils pour la migration

Pour la mise en œuvre pratique, ce qui compte, c'est de savoir quels outils sont déjà présents dans votre propre exploitation et prennent en charge Redfish. De nombreux outils d'automatisation et de gestion prennent désormais directement en charge cette norme, souvent en parallèle de la connexion IPMI existante. KVM Fleet s'appuie lui aussi sur Redfish pour les serveurs récents afin d'interroger de manière cohérente les versions de micrologiciel et les informations système sur l'ensemble de la flotte, sans avoir besoin d'une solution spécifique pour chaque fabricant. La façon dont les mises à jour de micrologiciel peuvent en outre être organisées est décrite dans l'article consacré aux Mises à jour du micrologiciel via des centaines de serveurs. La question d'architecture sous-jacente est traitée dans l'article consacré au KVM sur IP à l'échelle d'un parc informatique.

Foire aux questions

IPMI et Redfish peuvent-ils fonctionner en parallèle au sein d'une même exploitation ?

Oui, c'est d'ailleurs la procédure habituelle. La plupart des BMC modernes prennent en charge les deux protocoles simultanément, ce qui permet aux scripts IPMI existants de continuer à fonctionner tandis que les nouveaux processus d'automatisation sont progressivement migrés vers Redfish. Une migration radicale à une date butoir unique est rarement nécessaire et n'est d'ailleurs pas recommandée dans la pratique.

Qu'advient-il des anciens serveurs qui ne prennent pas en charge Redfish ?

Les serveurs dépourvus d'un BMC compatible Redfish restent tributaires de l'IPMI tant qu'ils sont en service. Un remplacement motivé uniquement par le protocole est rarement rentable d'un point de vue économique ; c'est généralement la fin normale de la durée de vie du matériel qui fait pencher la balance.

Quels outils d'administration prennent déjà en charge Redfish ?

Les grands fabricants de serveurs proposent leurs propres outils compatibles Redfish pour leurs plateformes, complétés par des solutions de gestion prenant en charge cette norme chez plusieurs fabricants. Avant de procéder à la migration vers Redfish, il est utile d'examiner sa propre chaîne d'outils afin de vérifier quels éléments sont déjà compatibles avec Redfish et où une mise à jour est encore nécessaire.

La prochaine étape

KVM Fleet est issu du développement interne de torck et prend déjà en charge Redfish sur les serveurs récents, car l'équipe a elle-même effectué cette transition dans sa propre exploitation. Certaines fonctionnalités du logiciel sont directement issues de cette migration vers Redfish. Pour en savoir plus, rendez-vous sur la Page produit de KVM Fleet.

Une question sur cet article ?

Deux phrases suffisent pour décrire votre situation. La réponse vous sera donnée par quelqu'un qui conçoit lui-même ce genre de systèmes.

Réponse dans un délai d'un jour ouvrable.torck · code with torque
Florian Blischke
Directeur général de torck GmbH · plus de 20 ans d'expérience dans le développement de logiciels
Florian Blischke est directeur général de torck GmbH et travaille depuis plus de 20 ans dans le développement de logiciels. Il est responsable des logiciels sur mesure destinés à l'industrie et au commerce, allant de l'intégration des processus physiques à l'architecture cloud, en passant par l'IoT et les systèmes basés sur les données et l'IA. Chez torck, il supervise notamment la plateforme énergétique Jouvoli et le produit de gestion de flotte KVM Fleet. torck développe ses solutions sur ses sites de Maxhütte-Haidhof, Vienne et Rabat, et accorde une grande importance à la mise au point de logiciels qui fonctionnent réellement en conditions réelles d'exploitation.

Vous vous posez la même question ?

Depuis 2017, nous développons des logiciels pour l'industrie et le commerce depuis Maxhütte-Haidhof, avec des équipes à Vienne et à Rabat. Un premier entretien dure 30 minutes et est gratuit. À l'issue de celui-ci, vous saurez si le projet en vaut la peine, même si la réponse est négative.

Autres articles