Cet article fait partie de notre guide: Réussir son projet de Disaster Recovery

Incendie dans le datacenter : comment éviter le chaos et les flammes

La deuxième partie de cette histoire inspirée de faits réels explique ce qui a mal tourné et comment la catastrophe aurait pu être évitée.

Il a fallu un jour entier et la moitié de la nuit au centre de secours pour prendre le relais de nos activités informatiques. Et encore, cela ne concernait que nos systèmes les plus prioritaires. Avec un climatiseur mobile, une ligne temporaire et un petit onduleur, nous avons pu rétablir les communications téléphoniques.

Le remplacement des composants calcinés du tableau électrique principal prendrait des semaines, mais nous devions aussi comprendre ce qui s'était passé afin que cela ne se reproduise plus.

Voici les six points de défaillance que nous avons découverts et dûment notés dans notre rapport de reprise après sinistre.

1. Les climatiseurs

Nous avions des climatiseurs de secours, mais la plupart étaient alimentés par un seul et même tableau électrique. Seules les deux unités redondantes et l'unité du local de l'onduleur étaient alimentées par une autre source, une idée que le concepteur trouvait logique, mais qui en fait compromettait la redondance dans laquelle nous avions investi.

Le courant de déclenchement sur le disjoncteur principal n'était pas correctement paramétré, et les techniciens et sous-traitants n'avaient pas coordonné les disjoncteurs. Du coup, quand un problème s'est produit sur un climatiseur, c'est le disjoncteur principal qui a sauté, au lieu du seul disjoncteur secondaire concerné, coupant ainsi 80 % du système de refroidissement.

Une thermographie infrarouge a été réalisée sur le tableau électrique, mais avec seulement une partie des climatiseurs en fonctionnement. Cette charge partielle n'a pas entraîné de véritable surchauffe du jeu de barres, ce qui fait que les tests n'ont pas permis de mettre en évidence le faux contact ayant provoqué l'explosion.

Le second tableau électrique se trouvait dans la même armoire que le premier, encore une décision prise pour rester dans le budget, de sorte que les deux jeux de barres étaient juste à côté l'un de l'autre. Quand le premier a explosé, il a détruit le second, et nous avons tout perdu.

2. La conception du datacenter

Un autre point concernait la conception du datacenter. Comme notre groupe électrogène desservait tout le bâtiment, le commutateur de transfert se trouvait au sous-sol, avant le tableau électrique. Il n'a pas détecté qu'une panne de courant était imminente, mais la destruction du tableau électrique aurait de toute façon entraîné une coupure à notre niveau.

Avec un groupe électrogène partagé, nous aurions dû disposer de plusieurs commutateurs de transfert automatique, dont un réservé au datacenter. Ainsi, si l'alimentation du datacenter avait été interrompue sans que le reste du bâtiment soit touché, le groupe aurait démarré pour fournir une alimentation de secours.

Nous étions opposés à ce que le local électrique soit accessible depuis le datacenter, car nous ne voulions pas que des électriciens passent par notre espace informatique. On ne nous a pas écoutés. Le climatiseur du local électrique fonctionnait toujours alors que les unités du datacenter étaient arrêtées, ce qui a créé un différentiel de pression. Quand la porte a été ouverte, la chaleur et la fumée dégagées par l'explosion se sont répandues.

3. Le détecteur de fumée

Notre détecteur et avertisseur autonome de fumée s'est déclenché instantanément, mais il commandait également le système d'extinction d'incendie au gaz qui, lui, n'était pas correctement paramétré.

Du coup, au lieu de se contenter d'une alarme, il a déclenché la libération du gaz dès qu'il a détecté la fumée.

Les particules de fumée ont également encrassé les filtres de tous les équipements qui fonctionnaient encore. Le seul point positif est que le climatiseur du local électrique était sur le même circuit que les deux unités redondantes, de sorte qu'il ne s'est pas arrêté. Sans système de refroidissement, l'onduleur aurait rapidement surchauffé et se serait arrêté avant la salle informatique.

L'onduleur doit se mettre en dérivation et maintenir l'alimentation électrique des ordinateurs venant du réseau, mais les tests ont révélé que la dérivation n'était pas correctement câblée. Avec un seul climatiseur, nous étions doublement vulnérables.

4. L'établissement des priorités

Notre onduleur pouvait procéder à un arrêt en ordre des serveurs via le réseau, mais nous n'avons jamais fait les branchements nécessaires. Nous avions d'autres priorités.

Nous avons également appris qu'un bouton d'arrêt d'urgence n'était pas vraiment nécessaire, car les locaux n'avaient pas de faux-plancher et nous n'avions pas recours au confinement.

Les ingénieurs ont imposé le bouton le plus dangereux de l'industrie au prétexte que « tous les datacenters en ont un », sans même l'équiper d'un cache ou d'une protection quelconque pour éviter qu'il soit utilisé de manière hâtive.

Les administrateurs des datacenters doivent accomplir un nombre incalculable de tâches. Il faut apprendre à définir des priorités du mieux possible, avec des stratégies véritablement applicables.

5. Les alertes DCIM

Quand j'ai demandé à l'outil de gestion de l'infrastructure du datacenter de ne m'alerter qu'en cas d'incident grave, la limite était basée sur la température admissible fixée par l'ASHRAE, qui était plus élevée que la température de refroidissement effectivement paramétrée dans notre datacenter.

Comme chez nous la valeur de refroidissement était défini à la température précédemment recommandée (beaucoup plus basse qu'il n'aurait fallu), la panne s'est produite bien avant que l'alerte ne soit donnée, ce qui a fait perdre un temps précieux au niveau de la gestion du sinistre.

L'outil de contrôle aurait également dû montrer que huit climatiseurs sur dix étaient en panne et en identifier les causes. Mais nous n'avions pas acheté le module d'équipement mécanique du système et, par conséquent, n'avons pas été informés des défaillances de refroidissement.

6. Le manque de formation et de certification

Evidemment, nous aurions dû être mieux formés à l'utilisation du système de gestion du datacenter. L'interface utilisateur était complexe et fournissait tellement de données détaillées qu'il était difficile de s'y retrouver. Nous avons essayé la modifier pour obtenir plus facilement une vue d'ensemble, mais elle n'était pas très configurable.

Le service informatique aurait dû être impliqué dans le choix de ce système important et avoir la possibilité de le tester avant la décision d'achat, comme nous le faisons pour d'autres logiciels.

En résumé, nous n'étions absolument pas conformes au niveau Tier III, et une véritable certification aurait révélé toutes ces failles.

Notre société a trop voulu rogner sur les dépenses en sous-traitant notre sauvegarde et notre centre de secours. Mais pour ce qui est de l'absence d'un plan concret dûment développé et testé, je suis entièrement responsable.

A l'occasion du rapport de reprise après sinistre, nous avons examiné sous toutes ses coutures notre contrat avec le centre de secours, et nous avons pu y apporter des améliorations. Nous nous sommes aussi fait aider pour élaborer un plan de reprise après sinistre, que nous testons désormais deux fois par an en réalisant un transfert de notre activité en conditions réelles.

Dernière mise à jour de cet article : avril 2017

Soyez le premier à commenter

M'envoyer une notification dès qu'un autre membre commente.

Merci de créer un identifiant pour pouvoir poster votre commentaire.

- ANNONCES GOOGLE

Close