Le serveur ne répond plus et personne ne se trouve sur place devant le rack. Pour redémarrer un serveur à distance, il faut disposer d'un moyen d'accès qui fonctionne indépendamment du système d'exploitation bloqué et qui ne nécessite aucune intervention d'un technicien sur place : le Baseboard Management Controller, ou BMC.
Le BMC est alimenté par la source d'alimentation de secours du bloc d'alimentation et reste accessible même lorsque le système est éteint ou bloqué. Il permet de redémarrer un serveur à distance, même si le système d'exploitation ne répond plus. Redfish et IPMI fournissent à cet effet des commandes telles que « Graceful Shutdown », « Hard Reset » et « PowerCycle », dans cet ordre précis.
Le BMC reste accessible, même si le serveur ne répond plus
Chaque serveur doté d'un processeur de gestion autonome dispose d'un « Baseboard Management Controller » (BMC). Le BMC est intégré à la carte mère, dispose de sa propre interface réseau et fonctionne indépendamment du processeur principal. Sur le marché, ce composant porte différents noms selon les fabricants : Dell l'appelle iDRAC, HPE iLO, Supermicro conserve l'abréviation BMC, tandis que Raritan propose, avec ses appareils KVM-over-IP externes, une alternative pour les serveurs ne disposant pas d'un accès BMC propre au fabricant. Le BMC est connecté à la ligne de veille du bloc d'alimentation et est donc alimenté même lorsque le serveur est éteint ou que le système d'exploitation est bloqué. Un « kernel panic », un processus bloqué ou un système complètement figé n'y changent rien. Le BMC continue de fonctionner tant que le bloc d'alimentation lui-même est alimenté.
C'est cette fonctionnalité qui rend possible l'accès à distance au niveau du serveur. Sans BMC, il ne resterait plus qu'à débrancher le câble d'alimentation, avec tous les risques que cela comporte pour les systèmes de fichiers et les processus en cours d'exécution. Grâce au BMC, un serveur peut être géré à distance via deux protocoles fonctionnant en parallèle : IPMI et Redfish. Ces commandes parviennent au BMC via le réseau de gestion, qui, dans l’idéal, est séparé du réseau de production. L’article „ Séparer le réseau de gestion : une architecture redondante pour les situations d’urgence ” explique comment mettre cela en œuvre. Le principe sous-jacent est décrit plus en détail dans l’article Gestion hors bande.
Redémarrage à distance d'un serveur : la chaîne d'escalade
Redfish est la norme REST adoptée par la DMTF qu'il maintient et qui couvre désormais la plupart des générations récentes de serveurs. Il prend en charge des commandes d’alimentation clairement nommées : ForceOff pour un arrêt forcé immédiat, GracefulShutdown pour un arrêt contrôlé via le système d’exploitation, GracefulRestart pour un redémarrage avec fermeture des processus en cours et PowerCycle pour un arrêt complet suivi d’une remise sous tension. IPMI, le protocole plus ancien mais toujours largement utilisé, offre les mêmes fonctions de base via l’outil en ligne de commande ipmitool, avec une structure moins uniforme et sans les options d’authentification plus modernes de Redfish.
En fonctionnement, ces commandes suivent un ordre bien défini. Tout d’abord, l’arrêt en douceur : le système d’exploitation reçoit le signal de fermer les processus et de démonter complètement les systèmes de fichiers. Si le serveur ne réagit pas dans un délai raisonnable, s’ensuit la réinitialisation matérielle, c’est-à-dire un redémarrage immédiat sans tenir compte des processus en cours. Si cela reste également sans effet, on passe au « PowerCycle » : coupure totale de l'alimentation, courte pause, puis remise sous tension. Viennent ensuite deux autres étapes, qui sont plus rarement nécessaires, mais qui existent au cas où le serveur lui-même ne serait plus le véritable problème.
| Étape | Mesure | Effet |
|---|---|---|
| 1 | Arrêt en douceur | Le système d'exploitation s'arrête de manière contrôlée |
| 2 | Réinitialisation matérielle | Redémarrage immédiat sans tenir compte des processus en cours |
| 3 | PowerCycle | Couper complètement le courant, puis le remettre en marche |
| 4 | Réinitialisation BMC | Le processeur de gestion redémarre tout seul |
| 5 | PDU | Une multiprise à interrupteurs coupe l'alimentation électrique depuis l'extérieur |
Pourquoi l'ordre est important
Une réinitialisation matérielle agit rapidement, et c'est précisément ce qui la rend séduisante dès qu'un serveur ne répond plus. Il existe néanmoins une raison valable entre ces deux étapes, ce n'est pas une simple formalité.
Si vous suivez les étapes dans l'ordre, au lieu de recourir immédiatement à une réinitialisation matérielle, vous perdrez, dans le pire des cas, quelques minutes d'attente. Si vous les ignorez, vous risquez d'endommager le système de fichiers et de devoir effectuer une restauration qui prendra bien plus de temps que les quelques minutes qu'aurait nécessité la procédure normale.
Quand même le BMC ne répond plus
Il arrive rarement, mais ce n'est pas exclu, qu'un BMC se bloque, par exemple à la suite d'une mise à jour de firmware défectueuse ou d'une erreur logicielle interne. Dans ce cas, une réinitialisation ciblée du BMC via l'interface série permet généralement de résoudre le problème. Si le BMC ne répond plus non plus, la dernière solution consiste à utiliser une unité de distribution d'alimentation (PDU) commutable. La PDU est placée entre la prise de courant et le serveur et peut être activée ou désactivée via le réseau, indépendamment du serveur et de son BMC. Elle se trouve donc à l'extrémité de la chaîne. Elle coupe complètement l'alimentation du serveur, sans qu'aucun composant du serveur lui-même n'ait besoin d'intervenir.
Pour se rendre compte du coût que peut représenter le fait de se passer de ces étapes, il suffit de se pencher sur l'alternative. Si, au lieu de cela, une personne doit effectivement se rendre au centre de données, les coûts d'une intervention sur place s'élèvent, selon les informations fournies par vsight.io entre 150 et 1 000 dollars américains, en fonction du déplacement, du temps d’attente et de la disponibilité des techniciens (vsight.io, 2026). Cette fourchette provient d’une source américaine et ne peut pas être transposée telle quelle aux réalités allemandes ou autrichiennes. Elle permet néanmoins de donner un ordre de grandeur des économies réalisées grâce à un système d'accès à distance efficace.
coût estimé d'une intervention sur site, source américaine.
vsight.io, 2026
Définir au préalable sa propre chaîne d'escalade
Un serveur en panne suit rarement le schéma de la dernière panne. En définissant au préalable les cinq étapes pour sa propre flotte, on n'a pas besoin, en cas d'urgence, de réfléchir à la commande à donner ensuite.
Foire aux questions
Que faire si le BMC se bloque lui aussi ?
Si le BMC ne répond plus aux commandes Redfish ou IPMI, seule une PDU commutable permet généralement de remédier au problème. Elle coupe l'alimentation électrique depuis l'extérieur, que le BMC fonctionne encore ou non. Un accès série via la console peut auparavant permettre une réinitialisation ciblée du BMC, sans avoir à redémarrer le serveur lui-même.
Une réinitialisation matérielle est-elle dangereuse ?
Une réinitialisation matérielle n'est pas dangereuse en soi, mais elle peut endommager des données si des opérations d'écriture sont en cours, car les systèmes de fichiers et les bases de données n'ont pas la possibilité de se fermer de manière contrôlée. C'est pourquoi la chaîne d'escalade commence toujours par un arrêt en douceur (Graceful Shutdown), qui donne cette possibilité au système d'exploitation.
Faut-il pour cela une PDU commutable ?
Une PDU commutable n'est pas absolument indispensable, car un BMC permet déjà de gérer la plupart des pannes via Redfish ou IPMI. Elle s'avère utile en tant que dernier recours dans le cas rare où le BMC lui-même ne répondrait plus et où une intervention sur site serait autrement inévitable.
torck développe elle-même un logiciel permettant de redémarrer un serveur à distance, allant de l'arrêt en douceur (Graceful Shutdown) jusqu'aux PDU commutables, et le teste dans un premier temps dans son propre environnement de test. Les équipes de Maxhütte-Haidhof, Vienne et Rabat gèrent leurs propres serveurs via ce système et savent donc par expérience à quel moment une commande de réinitialisation peut ne pas aboutir. Le partenaire contractuel est la société allemande torck GmbH ; il s'agit d'un contrat sans chaîne de sous-traitants. Si vous souhaitez voir comment Flotte KVM Si vous souhaitez découvrir cette chaîne d'escalade pour votre propre parc de serveurs, n'hésitez pas à convenir d'une démonstration du produit ou d'un premier entretien, sans engagement et sans pression commerciale.