Duquesne Group Duquesne Group

English version
Blog des experts

Les avis et les commentaires exprimés dans les blogs sont ceux des experts individuels. Ils ne représentent pas nécessairement l'opinion du cabinet. Contactez-nous pour en savoir +
French version
Blogs

In these blogs, individual experts freely express their own opinions and comments. They do not necessarily reflect the opinion of the firm. Contact us to find out more


Panne Delta : quelle leçon en tirer ?


La Compagnie Delta Airlines a subi une avarie dans son Data center aux USA qui a mis à l'arrêt la majeure partie de son activité.

Disposant de peu d'information à ce jour, nous essayons toutefois d'en tirer quelques enseignements.



Panne Delta : quelle leçon en tirer ?

Avant propos

Nous travaillons avec les éléments connus dans la presse au 11/08/2016 qui sont assez limités et gardent une part d'ombre.

Nous savons que la production informatique est un métier difficile et souvent regardé avec négligence. Notre intention n'est pas de donner des leçons faciles mais de rappeler que ces métiers doivent être valorisés, car sans eux le chaos finit toujours par s'installer ...

La panne électrique

Le déroulement des événements, tel qu'il est présenté à ce jour, donne pour origine une défaillance dans un Power Control Module (PCM) du centre informatique.

Nous ne savons pas à quoi est due cette défaillance, mais elle est associée à des problèmes de surtension (causes ou conséquences ?) à une coupure par le fournisseur (normale dans le cas présenté) et à un incendie concernant au moins ce PCM.

Rappelons que dans un Data Centre classique l'alimentation électrique est habituellement en trois niveaux :
  • le fournisseur électrique alimente des batteries d'onduleurs
  • ces batteries d'onduleurs alimentent les alimentations électriques des serveurs
  • les serveurs eux-mêmes transforment ce courant selon leurs besoin (12V continu, etc...)

Si le fournisseur électrique est défaillant (ce fut le cas ici à cause de Delta), il est remplacé par des générateurs électriques qui prennent le relais en une dizaine de minutes, sachant que les serveurs eux ne subissent aucune coupure puisqu'ils sont directement sur les onduleurs.

Si ce schéma est respecté, on ne voit pas bien comment le scénario de Delta peut se produire, sauf à imaginer qu'il y a des éléments actifs sur le chemin électrique qui ont provoqué une coupure d'une voie. Des éléments tels que des PCM peuvent effectivement se trouver dans ce cas. Ils doivent être entre la fourniture ondulée et les serveurs, donc à priori en salle près des racks. S'ils sont à cet endroit, on ne voit pas bien comment ils peuvent générer un problème chez le fournisseur ... sauf si la cause leur est externe (court circuit ?) ou sauf si l'alimentation électrique n'est pas organisée comme décrit plus haut ...

Les éléments fournis sont assez flous et ne permettent pas de comprendre vraiment ce qui s'est passé.

Toujours est-il que :

  • les alimentations électriques en data center sont potentiellement complexes, leur conception fiable nécessite des compétences d'ingénieurs en électricité

  • une installation bien conçue peut se détériorer si sa maintenance n'est pas vigilante et si les impacts des changements opérés ne sont pas appréciés et managés.

  • il convient de surveiller les éléments actifs électriques, des remontées d'alerte doivent être en place et surveillées.

La connexion électrique des serveurs

Voilà un sujet difficile ...

Normalement (encore une fois ...) un serveur, surtout s'il est critique, est doté de deux alimentations électriques internes chacune branchée à une voie d'arrivée indépendante (A et B). Si A est défaillant, le serveur bascule sur B. Ceci peut s'imaginer au niveau du serveur ou d'un chassis de lames ou d'un rack.

Lorsqu'on emploie des serveurs qui n'ont qu'une alimentation interne, on recourt alors à un dispositif de bascule externe (dit STS Static Transfer Switch) qui permet de basculer vite d'une voie à une autre.

Donc en résumé, tous les serveurs disposent de deux voies d'alimentation aussi indépendantes que possibles sur des onduleurs différents et derrière potentiellement des générateurs différents et ErDF en bout de ligne.

Pour arriver à la situation décrite par Delta, de trois choses l'une :

  • soit cet agencement n'est pas en place (ou bien il l'a été et ne l'est plus)

  • soit il a été ajouté des éléments qui créent des pannes "de mode commun" qui vont frapper A et B (portions de câble communes ou proches).

  • soit un sinistre général (feu sur plusieurs voies malencontreusement mises proches, ...) a brisé cette organisation

Normalement ce sinistre général doit être paré (extinction etc.).

Les 300 serveurs "non connectés à une alimentation de secours".

Delta annonce avoir 7000 serveurs au total dont "300 non connectés à une alimentation de secours".

Cela n'est pas précisé mais nous supposons qu'il s'agit de serveurs physiques. On ne nous parle pas non plus de stockage, ni de réseau, ce qui est étonnant.

Vu ce qui précède, nous ne savons pas ce que signifie la phrase "connectés à une alimentation de secours" car ce n'est pas ainsi normalement que les choses se présentent :

  • Les serveurs sont connectés à une ou deux voies d'arrivée électrique (voire plus dans les Data Centers les plus exigeants)
  • Ces voies d'arrivée sont alimentées diversement (onduleurs en permanence, eux mêmes chargés par ErDF ou un générateur selon les périodes).

Il faut donc croire pour comprendre cette phrase, que Delta connecte ses serveurs à ErDF (pardon Georgian Power) en direct et qu'en plus 6700 d'entre eux (7000-300) bénéficient d'une connexion à des onduleurs ou générateur avec une bascule qui s'est avérée problématique.

In fine seule cette situation (de type "salle technique") pourrait expliquer qu'il y a eu coupure pour tous les serveurs puis réalimentation pour 6700 d'entre eux.

La relation des serveurs avec les métiers

On pourrait penser que les 300 serveurs "non connectés au secours" sont d'importance secondaire. Or la suite des événements montre qu'il n'en est rien puisque leur absence pèse lourdement sur la reprise.

Cette notion de dépendance d'un serveur envers un autre mérite qu'on s'y arrête car en général, la bonne pratique est :
  • de limiter absolument les cas de dépendance synchrone, car ils créent des "étreintes mortelles"
  • de privilégier des mécanismes plus souples, asynchrones ou "par abonnement"
  • ou, si l'on ne peut faire autrement de mettre ces serveurs en dépendance ensemble dans la même machine physique.

Nous supposons bien évidemment qu'il ne s'agit pas de serveurs techniques de type "anti-virus" ou "single sign-on" ou autre "gestion des logins" car cela serait criminel de ne pas les "brancher sur le secours".

Par ailleurs et cela est très important, cette affaire démontre que la relation avec les activités prioritaires n'a pas été faite ou n'a pas été maintenue :
nous sommes en effet en présence de serveurs nécessaires aux activités critiques mais non considérés comme prioritaires.

Voilà encore une entorse aux bonnes pratiques qui veulent :
  • que les activités métiers prioritaires soient connues avec leurs exigences de reprise
  • que leurs moyens (dont serveurs) soient identifiés et bénéficient de protection et de plan de reprise

Sans cette analyse (BIA pour les connaisseurs de la norme ISO 22 301) la divergence s'installe entre les exigences des métiers et la réalité sous sinistre.

Or nous sommes en présence de l'outil de production d'une compagnie aérienne qui doit organiser et gérer des vols avec des équipages, des passagers et des avions. Tout arrêt de l'informatique arrête la production. Tout système informatique sous-jacent est donc hautement critique.

La problématique de la reprise

Sur ce sujet, nous ne partageons pas complétement la critique générale faite par les média : reprendre en deux jours dans un contexte aussi désastreux, c'est plutôt rapide.

Nous sommes en effet en présence :
  • de serveurs mal arrêtés avec des données potentiellement corrompues
  • de dépendance dans les reprises avec des moyens indisponibles
  • de nécessité de retour arrière sur certains traitements
  • de perte de contact avec la réalité (où sont les avions ? les pilotes ? etc.)
  • de saisies à la main nombreuses, problématiques et à contrôle réduit
  • de rattrapage de traitements du passé perdus
  • d'accès en mode lecture uniquement alors qu'une saisie serait nécessaire
  • et d'un personnel énormément mis sous stress

Les conséquences de ce sinistre ne seront vraisemblablement complètement effacées que dans quelques mois si cela est jamais possible.

Il serait par ailleurs intéressant de savoir comment ce sinistre a été traité dans ses débuts :
  • quand a-t-il été découvert (à 2h du matin ? à 8h ?)
  • par qui et comment (outil de surveillance, appel d'un opérateur ?)
  • quelles alertes ont été lancées ?
  • quels moyens techniques de surveillance a servi ?
  • quel bilan des serveurs en panne était possible ?
  • quelles escalades ont été faites ?
  • quelle cellule de crise ?
Emmanuel Besluau
Vendredi 12 Août 2016

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Articles du même auteur :

Halte aux PCA bidons ! - 19/01/2014

1 2