Un serveur qui ne répond plus à trois heures du matin, une mise à jour de BIOS à passer sur un site distant, une baie entière à administrer sans se déplacer : l’accès distant aux serveurs est le quotidien de l’exploitation. Presque chaque machine professionnelle embarque pour cela un contrôleur IPMI. Ce standard a pourtant ses angles morts, que les équipes découvrent en général au pire moment. Ce comparatif met côte à côte les trois familles d’accès : le contrôleur embarqué des constructeurs (IPMI, iDRAC, iLO), les solutions remote KVM matérielles, et les outils logiciels. L’objectif est simple : savoir lequel utiliser pour quel serveur, et lequel restera disponible le jour où les autres auront disparu.
Que sont KVM et IPMI ?
KVM et IPMI désignent deux voies d’accès distant à un serveur : le KVM transporte clavier, écran et souris vers un poste éloigné par un boîtier matériel, l’IPMI est le protocole d’administration intégré à la carte mère. Le second reste joignable même machine éteinte. Les deux se complètent plus qu’ils ne s’opposent, à condition de savoir ce que chacun garantit.
KVM : clavier, écran et souris déportés
Une précision s’impose d’emblée, tant la confusion est répandue jusque dans les résultats de recherche. Le KVM dont il est question ici n’a rien à voir avec l’hyperviseur de virtualisation du noyau Linux, qui porte le même acronyme. Il s’agit du KVM matériel, Keyboard Video Mouse, dont la déclinaison réseau, le KVM sur IP, transporte la console d’une machine vers n’importe quel poste autorisé.
IPMI : le standard d’administration embarquée
L’IPMI (Intelligent Platform Management Interface) s’appuie sur un composant discret mais puissant : le BMC, un contrôleur autonome soudé à la carte mère, alimenté dès que le serveur est branché. Par lui, un administrateur relève les capteurs (températures, tensions, ventilateurs) et consulte les journaux matériels. Il redémarre électriquement la machine et, selon les licences, ouvre une console à distance, y compris quand le système d’exploitation est planté ou absent.
iDRAC, iLO, XClarity : le BMC selon les constructeurs
Le standard est commun, les implémentations ne le sont pas, et cette nuance pèse lourd en exploitation.
Un contrôleur par marque, des interfaces disparates
iDRAC chez Dell, iLO chez HPE, XClarity chez Lenovo : chaque constructeur livre son propre contrôleur, bâti sur les fondations communes mais habillé d’une interface, d’outils et de comportements maison. Sur un parc mono-marque, cette diversité passe inaperçue. Sur un parc hétérogène, elle se traduit par autant de consoles, de procédures et de cycles de mise à jour que de constructeurs présents en baie.
Fonctions avancées sous licence
Le contrôleur de base est inclus, ses fonctions les plus utiles le sont rarement. La console graphique distante et le montage de médias virtuels sont généralement réservés aux licences supérieures, iDRAC Enterprise chez Dell, iLO Advanced chez HPE. Le coût réel de l’administration embarquée se calcule donc licence comprise, serveur par serveur. Le successeur du standard, l’API Redfish, modernise progressivement ces échanges sans changer cette logique commerciale.
Les limites de l’IPMI en environnement critique
Aucune de ces limites n’interdit l’usage du contrôleur embarqué. Toutes méritent d’être connues avant l’incident, pas après.
Sécurité : un protocole ancien à isoler
Le standard a été conçu à la fin des années 1990, et son ancienneté se paie. Des faiblesses documentées touchent son mécanisme d’authentification, et les agences de sécurité recommandent de longue date de ne jamais exposer un BMC à Internet. La pratique saine est connue : un réseau d’administration dédié, isolé du réseau de production, des firmwares maintenus à jour et des comptes par défaut désactivés. Ce cloisonnement demande une discipline durable, sur chaque machine du parc. Dans les environnements soumis à audit, cette discipline se prouve en plus de se pratiquer : inventaire des contrôleurs, traçabilité des accès, politique de mise à jour documentée. Le coût caché du contrôleur embarqué se loge dans cette gouvernance, rarement chiffrée au moment de l’achat.
Console, latence et dépendance au contrôleur
La qualité de la console distante varie fortement d’un BMC à l’autre : réactivité, résolution, compatibilité des navigateurs. Surtout, l’accès repose entièrement sur le contrôleur lui-même. Un BMC figé, un firmware corrompu ou une carte réseau d’administration en défaut, et la machine redevient injoignable autrement qu’en salle. Le composant qui devait garantir l’accès de secours devient alors le maillon manquant.
KVM sur IP : l’accès matériel unifié
La logique du KVM sur IP est inverse : plutôt que de dépendre d’un composant du serveur, on lui adjoint un équipement indépendant.
Indépendant du BMC comme du système
Le boîtier capte la sortie vidéo réelle de la machine et émule clavier et souris au niveau matériel. Ce que voit l’opérateur est ce qu’afficherait un écran branché en salle : le BIOS, la séquence de démarrage, l’écran de panne, le système en fonctionnement. Aucun agent à installer, aucune dépendance au BMC ni à l’état du système. Un Dominion KX III de Raritan donne ainsi à plusieurs utilisateurs simultanés un accès au niveau du BIOS sur des dizaines de serveurs.
Un point d’accès unique pour un parc hétérogène
Dell, HPE, Lenovo ou machines assemblées : le procédé ne fait aucune différence, puisqu’il travaille sur les signaux, pas sur les logiciels. Les équipes y gagnent une console unique pour tout le parc, des droits d’accès centralisés et une journalisation homogène des connexions. Les formats s’adaptent à l’échelle du besoin : boîtier individuel au format Zero U glissé derrière un serveur isolé, ou commutateur multi-ports qui dessert une baie complète depuis un seul équipement. Pour les équipements réseau dépourvus de sortie vidéo, switches et routeurs, la même logique passe par un serveur de port console et l’accès série.
VNC, RDP, SSH : l’accès in-band en complément
Les outils logiciels restent les plus utilisés au quotidien, et pour de bonnes raisons : ils sont inclus, universels et confortables. Leur limite est structurelle : ils dépendent du système d’exploitation et du réseau de production. Un OS planté, une pile réseau en défaut ou une machine à reconfigurer avant son premier démarrage les rendent inopérants. Ils couvrent l’exploitation normale ; ils disparaissent précisément dans les situations où l’accès distant devient vital.
Choisir selon la criticité du serveur
| Critère | BMC (IPMI, iDRAC, iLO) | KVM sur IP | Logiciel (VNC, RDP, SSH) |
|---|---|---|---|
| Fonctionne si l’OS est planté | Oui, si le BMC répond | Oui | Non |
| Accès BIOS et séquence de démarrage | Oui, selon licence | Oui | Non |
| Parc multi-constructeurs | Une console par marque | Console unique | Client universel |
| Chemin réseau | Port dédié ou partagé avec le serveur, à isoler | Indépendant du serveur | Réseau de production |
| Coût | Inclus, fonctions sous licence | Investissement matériel | Inclus ou faible |
L’arbitrage se fait serveur par serveur, sur trois questions : que coûte une heure d’indisponibilité de cette machine, combien de constructeurs cohabitent dans la baie, et quelles exigences d’audit pèsent sur les accès. Les serveurs ordinaires vivent très bien avec leur BMC et un outil logiciel. Les machines critiques d’un data center, elles, justifient la voie matérielle indépendante, précisément parce qu’elle ne partage aucun mode de défaillance avec le reste. La configuration la plus courante en pratique est mixte : le contrôleur embarqué et les outils logiciels pour tout le parc, et l’accès matériel réservé au cœur critique, dimensionné au plus juste. Cette répartition contient l’investissement tout en garantissant qu’aucun scénario de panne ne laisse l’équipe sans porte d’entrée.
FAQ : IPMI et accès distant aux serveurs
L’IPMI fonctionne-t-il serveur éteint ?
Le BMC reste alimenté dès que le serveur est raccordé au secteur : l’IPMI permet donc de consulter les capteurs et les journaux, et de démarrer électriquement une machine éteinte. Cette disponibilité suppose une seule condition : que le contrôleur lui-même et son accès réseau restent fonctionnels.
Le KVM sur IP fonctionne-t-il si le serveur est planté ?
Un boîtier KVM sur IP reste opérationnel quel que soit l’état du système : il capte la sortie vidéo de la machine et émule le clavier au niveau matériel. Écran de panne, noyau figé ou passage dans le BIOS : l’opérateur voit exactement ce qu’afficherait un écran branché directement sur le serveur.
Quelle différence entre IPMI et iDRAC ?
iDRAC est l’implémentation Dell du contrôleur d’administration embarqué, bâtie sur le standard IPMI et enrichie d’une interface et de fonctions propres. Chaque constructeur possède la sienne, iLO chez HPE, XClarity chez Lenovo, avec des licences distinctes pour les fonctions avancées comme la console graphique distante.
L’IPMI restera l’outil du quotidien, et c’est très bien ainsi. La vraie question est celle du jour où il ne suffit plus : quels serveurs justifient un accès matériel indépendant, et par quel chemin. Un inventaire du parc classé par criticité y répond en une réunion de travail, et un boîtier en prêt d’évaluation tranche le reste sur pièces.
