Reprise après sinistre avec accès hors bande

La reprise après sinistre avec accès hors bande transforme une panne du noyau survenue à deux heures du matin, qui aurait normalement nécessité un déplacement nocturne en voiture, en une simple session sur son propre ordinateur. Le système d'exploitation ne démarre plus, l'administrateur responsable est chez lui, loin du centre de données, mais il peut néanmoins accéder au serveur.

RTO, RPO et le module DER.4 du BSI

Deux indicateurs clés définissent tout plan d'urgence. Le « Recovery Time Objective », ou RTO, décrit le délai maximal tolérable avant la remise en service d'un système. Le Recovery Point Objective (RPO) désigne la perte de données maximale tolérable, mesurée en intervalle de temps depuis la dernière sauvegarde opérationnelle. Ces deux valeurs déterminent la rapidité et l'exhaustivité avec lesquelles une restauration doit s'effectuer, et donc aussi quels outils peuvent être envisagés à cette fin.

Sans accès hors bande, le RTO dépend de la disponibilité d'une personne capable de se rendre au centre de données, ainsi que du temps de trajet lui-même. Avec un BMC opérationnel, elle ne dépend plus que de la rapidité avec laquelle quelqu’un se connecte et connaît les étapes à suivre. Cette différence se fait particulièrement sentir aux heures creuses, la nuit, le week-end ou lorsque la personne responsable est en déplacement.

Le module « IT-Grundschutz » DER.4 Gestion des situations d'urgence décrit ce que doivent apporter la prévention et la gestion des urgences dans ce contexte, de l'analyse des risques jusqu'à la procédure de reprise d'activité rodée par des exercices (BSI, Compendium sur la sécurité informatique de base, édition 2023). L’accès hors bande ne remplace pas un plan d’urgence complet, mais constitue un élément essentiel qui rend les valeurs de RTO courtes réalistes, car il élimine le facteur « temps de trajet » de l’équation. Cet article explique comment détecter une panne à l'avance grâce aux données des capteurs et aux alertes, avant même que la restauration ne doive commencer. Surveillance matérielle de la flotte : données des capteurs, alertes, tableaux de bord.

La reprise après sinistre avec accès hors bande : mise en pratique

C'est lorsque le système d'exploitation lui-même est à l'origine du problème que l'on se rend compte de toute sa valeur. Après un « kernel panic », une mise à jour qui a échoué ou une partition de démarrage endommagée, le BMC reste accessible, quel que soit l'état du système principal. La console permet souvent de visualiser directement l’erreur et, grâce à Virtual Media, de monter un système de secours ou un support d’installation vierge, sans aucun accès physique au serveur.

Si même le BMC ne répond plus, il est possible de le réinitialiser de manière ciblée à l'aide d'ipmitool, sans que le système principal ne soit affecté, car le BMC et le processeur principal sont des composants distincts. L'un des éléments clés de cette procédure de restauration est la chaîne d'escalade contrôlée, allant de l'arrêt en douceur (Graceful Shutdown) jusqu'au PDU, telle que décrite dans l'article Gestion à distance de l'alimentation : redémarrer les serveurs bloqués sans intervention sur site décrit. Pour automatiser ces processus, il est possible d'intégrer des interfaces Redfish dans des outils courants tels qu'Ansible ou Terraform, de sorte qu'un script de redémarrage exécute les mêmes étapes que celles indiquées dans le manuel d'urgence, au lieu de les saisir manuellement à chaque fois. Les ressources d’alimentation et de démarrage nécessaires à cet effet sont décrites dans la Spécification Redfish de la DMTF indépendamment du fabricant, ce qui permet de réutiliser les scripts sur différents modèles de serveurs.

Ce qui doit figurer dans le manuel d'urgence

Un manuel d'urgence qui ne mentionne pas l'accès hors bande ne tire pas parti de l'option de restauration la plus rapide disponible. Il doit inclure les adresses IP des BMC, la procédure d'accès via le serveur de saut et les étapes concrètes à suivre pour les scénarios de panne les plus courants, allant de l'arrêt en douceur (Graceful Shutdown) à la réinstallation via Virtual Media. Il est également important de préciser qui est habilité, en cas d’urgence, à décider du niveau de restauration à mettre en œuvre. En l’absence d’une personne clairement désignée ou d’un remplaçant, un retard survient souvent dans une situation critique, car plusieurs intervenants attendent une autorisation que personne ne donne concrètement. Le manuel d’urgence définit donc ce pouvoir de décision de manière aussi précise que les voies d’accès techniques elles-mêmes. Les listes de contacts deviennent obsolètes plus rapidement que ne le prévoient la plupart des équipes dès lors que personne ne les met à jour après un changement de personnel. Une brève vérification lors de chaque exercice permet de maintenir de manière fiable à jour les noms, numéros de téléphone et remplaçants.

En cas de panne totale du réseau principal, il faut disposer d'une deuxième voie d'accès au réseau de gestion, indépendante de la liaison montante habituelle. Sans cette redondance, même le meilleur BMC ne sert à rien si c'est justement la connexion qui y mène qui fait défaut. Les identifiants d'accès eux-mêmes doivent être conservés en dehors des systèmes concernés, par exemple dans un coffre-fort physique ou dans un système de gestion des mots de passe distinct, qui ne se trouve pas sur les mêmes serveurs que ceux qui sont justement inaccessibles en cas d'urgence. Un manuel d’urgence qui se trouve uniquement sur le serveur de fichiers en panne est justement inutile au moment où on en a besoin.

Pourquoi la reprise après sinistre ne fonctionne pas sans entraînement

Seule une restauration réellement effectuée via Virtual Media permet de vérifier si l'image de secours enregistrée est encore à jour, si les identifiants documentés sont corrects et si les étapes décrites fonctionnent dans la pratique ou ne sont qu'une belle théorie sur le papier. Un tel exercice ne nécessite pas d’interrompre l’ensemble des opérations. Il suffit, dans une fenêtre de test, de réinitialiser de manière ciblée un serveur non critique via Virtual Media et d’exécuter chaque étape telle qu’elle est décrite dans le manuel, y compris les identifiants d’accès et les moyens de contact qui y sont indiqués. En documentant cet exercice avec la date et les lacunes identifiées, on rend visibles les progrès réalisés au fil des différents cycles, au lieu de repartir de zéro à chaque fois.

La fréquence à laquelle cet exercice doit être réalisé dépend du niveau de criticité des systèmes concernés. Un exercice annuel constitue le minimum requis ; pour les systèmes particulièrement critiques, il est recommandé de le réaliser à des intervalles plus courts.

Foire aux questions

Que doit contenir un manuel d'urgence ?

Les voies d'accès à tous les BMC, les étapes documentées pour les scénarios de panne les plus courants et une deuxième voie d'accès en cas de panne du réseau principal. Il est tout aussi important de désigner des interlocuteurs avec un système de remplacement, afin que le plan ne soit pas compromis par l'absence d'une seule personne.

Où enregistre-t-on les identifiants d'accès à BMC ?

En dehors des systèmes censés les protéger, par exemple dans un coffre-fort physique ou dans un système de gestion des mots de passe distinct, hébergé sur une infrastructure propre. Si les identifiants se trouvent uniquement sur un serveur de fichiers qui, en cas d'urgence, pourrait lui-même être affecté, l'accès est justement bloqué au moment où on en a besoin.

À quelle fréquence faut-il s'entraîner à réagir en cas d'urgence ?

Au moins une fois par an, voire plus souvent pour les systèmes critiques. Chaque exercice permet de détecter les images obsolètes, les identifiants erronés ou les processus interrompus, qui passent inaperçus lors de la simple rédaction du manuel d'urgence.

torck développe son propre logiciel spécialement pour ce type de situation d'urgence et teste régulièrement les procédures de restauration via Virtual Media sur sa propre infrastructure à Maxhütte-Haidhof, Vienne et Rabat, avant que les clients ne s'y fient. Cette expérience est mise à profit dans KVM Fleet comme base pour l'automatisation des étapes de restauration. Le partenaire contractuel est la société allemande torck GmbH : un contrat unique remplace une chaîne de sous-traitants, avec une direction de projet germanophone et un fuseau horaire commun aux trois sites. Si vous souhaitez compléter votre propre manuel d’urgence par un accès hors bande, n’hésitez pas à prendre rendez-vous pour un premier entretien.

Prendre rendez-vous