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).
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.
| 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
- 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.
- 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.
- 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.
- 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.
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.
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.