Arrêt de Chorus : les raisons de la panne du datacenter de Bull

Que s'est-il passé dans la salle du datacenter de Bull à Trélazé mercredi 19 juin ?

 Selon nos sources, ce que Bull qualifie d'incident d'exploitation trouve son origine dans le déclenchement intempestif des systèmes anti-incendie d'une des salles du datacenter du prestataire à Trélazé (à côté d'Angers), suite à une erreur dans l'intervention d'un sous-traitant qui a provoqué une réaction en chaîne. Dans cette salle, ces systèmes sont basés sur l'envoi de gaz à haute pression (50 à 60 bars) censé étouffer les flammes. En sortant des buses de diffusion à ces pressions, le gaz crée un bruit très fort, entraînant des vibrations. Ce sont ces dernières qui sont préjudiciables aux disques durs que renferment les baies de stockage, les équipements affectés par l'incident de mercredi dernier. Les vibrations provoquées par l'onde sonore peuvent en effet entraîner l'arrêt du disque, la destruction des têtes de lecture, voire la destruction totale du support. Dans le cas de l'AIFE, la panne de Chorus s'explique par la défaillance de 3 disques dans une baie de stockage qui en compte une centaine. 

A noter que Bull s'est refusé à tout commentaire sur les causes de la panne, privilégiant la thèse d'un incident d'exploitation banal. Dans le mail que la société nous a retourné vendredi dernier suite à nos sollicitations, le prestataire parle "d'un retour aux conditions normales d'exploitation en moins d'une heure". C'est oublier un peu vite les conséquences pour les clients : la partie cœur du progiciel Chorus, auxquels se raccordent 25 000 utilisateurs, est restée hors service entre mercredi en milieu de journée et lundi à la première heure. Comme l'explique Loïc de Montgolfier, directeur général Europe de l'Ouest chez SunGard Availability Services, un prestataire spécialisé dans les problématiques de continuité de services, "la question du retour aux conditions normales pour l'exploitant est un faux débat. Seules les conséquences pour le ou les clients importent. La durée d'un incident chez un exploitant a d'ailleurs peu d'importance, c'est le nombre d'interruptions par an qui devrait servir de critère discriminant". L'AIFE indique dans un communiqué son intention de "poursuivre le règlement de l'incident sur le plan juridique et financier avec son prestataire, la société Bull". 

S'agit-il d'un incident d'exploitation courant ?

Clairement non. La défaillance de disques durs suite à une onde de choc sonore demeure assez rare. Bizarrement, un scénario de ce type s'est produit il y a un mois dans un autre datacenter, situé en région parisienne. Là aussi, le déclenchement du système d'incendie au gaz, suite à une mauvaise manipulation, a entraîné la destruction de nombreux disques durs. 

Selon Fabrice Coquio, président de l'hébergeur Interxion en France, les problèmes que sont susceptibles de causer les systèmes d'incendie au gaz à haute pression sont connus depuis 2010. "L'apparition de ces problèmes remonte à l'arrivée de nouvelles générations de disques durs, plus denses, qui se sont révélés sensibles aux lâchés de gaz, détaille ce dernier. La sortie du gaz à 50 ou 60 bars génère une onde sonore de 120 à 130 décibels (db), l'équivalent d'un avion de ligne en plein décollage." Une onde qui rebondit contre les parois des salles, mais également à l'intérieur même des baies de stockage. Interxion précise d'ailleurs avoir équipé les buses de ses 34 datacenters de silencieux, ce qui permet de réduire l'onde sonore de 20 à 25 db. "Suffisant pour éviter tout impact dans les baies", assure Fabrice Coquio, qui relève que les concepteurs de salles informatiques (Tyco et Siemens principalement) préconisent cette solution ou le remplacement des buses par de nouveaux modèles. Signalons que les constructeurs de baies eux-mêmes proposent en option des systèmes d'absorption des ondes sonores à l'intérieur de leur matériel, même si ces dispositifs restent encore méconnus. Des contre-mesures existent donc bel et bien. "Ces interactions entre les gaz sous pression et les nouvelles générations de disques illustrent la complexité grandissante de nos métiers, note Fabrice Coquio. Si vous n'êtes pas un expert de l'hébergement, vous risquez de confronter vos clients finaux à ce type de problème". 

Une autre source industrielle confirme, tout en trouvant des circonstances atténuantes à Bull. "Le métier de l'urbanisation des salles machines est devenu très complexe. Tout un ensemble de bonnes pratiques doivent être prises en compte, par exemple concernant l'emplacement des machines par rapport aux buses. Et l'hébergeur doit faire au mieux avec ses autres contraintes, comme le remplissage optimal de la salle." 

L'AIFE (Chorus) est-il le seul client touché par la panne ?

 Dans son e-mail à la rédaction, Bull précise que "les conditions d'exploitation dégradées pendant cette heure ont pu avoir des impacts chez certains de nos clients". Au pluriel. Deux sources ont ainsi confirmé au MagIT que La Poste avait également été affectée par l'incident survenu à Trélazé le 19 juin. En juin 2012, le groupe avait renouvelé son contrat avec Bull. Courant jusqu'en 2018, celui-ci porte sur la mise à disposition d'une infrastructure d'hébergement sécurisée, "à très haute disponibilité, répondant aux besoins de continuité de service des activités stratégiques du Groupe La Poste", selon un communiqué du prestataire. Une partie de cette infrastructure est hébergée à Trélazé. Suite à nos demandes, le service de presse de La Poste nous a expliqué dans un premier mail : "L'incident qu'a connu le datacenter géré par Bull à Trélazé n'a eu aucun impact sur notre relation client". Avant de préciser, dans un second courriel, que "le système de production comptable et achats (du groupe, NDLR) a redémarré lundi matin dernier à 9 heures", confirmant les conséquences opérationnelles de la panne chez Bull sur son système d'information. 

Le plan de continuité d'activité de Chorus était-il suffisant ?

C'est LA question qui surgit en premier chez nombre de nos interlocuteurs : pourquoi un logiciel déployé aussi largement que Chorus et aux fonctions aussi critiques a-t-il mis autant de temps à redémarrer ? Après avoir constaté l'impossibilité d'assurer la cohérence des données avec trois disques durs en rade, l'AIFE a décidé, le 20 au matin, d'activer son plan de reprise d'activité (PRA). Et celui-ci a fonctionné... comme prévu. L'architecture mise en place pour Chorus repose en effet sur une unique baie pour le stockage des données de production, ainsi que sur une sauvegarde sur disque répliquée dans deux datacenters (une sauvegarde à Trélazé, une seconde sauvegarde sur un site distant). 

Autrement dit, alors que le système semble critique pour le fonctionnement de l'Etat, il ne repose pas sur un système redondant permettant une bascule en temps réel d'un environnement à un autre. Un choix délibéré car, au moment de la passation du contrat avec Bull et du design de l'architecture, les technologies de réplication en temps réel d'une baie à l'autre étaient déjà disponibles. Bien entendu, le choix d'une architecture permettant des bascules à chaud entre deux baies se serait traduit par un coût supplémentaire pour l'AIFE, un budget non négligeable étant donné les tarifs élevés des baies de stockage. 

Malgré tout, ce choix ainsi que la relative faiblesse des niveaux de service sur Chorus (99,5 % selon un document de Bull, soit 44 heures d'indisponibilité par an) surprennent plus d'un spécialiste. Pour Loïc de Montgolfier, de Sungard Availability Services, "compte tenu du nombre d'utilisateurs reliés à Chorus, il est étonnant qu'un plan de continuité d'activité plus exigeant n'ait pas été mis en place. 44 heures d'indisponibilité par an sur ce progiciel, cela représente tout de même 550 années homme potentiellement perdues par an !" A noter que Bull a fait mieux que le seuil des 99,5 % en 2012, avec un taux de disponibilité de 99,8 % selon l'AIFE. Seul, Fabrice Coquio, d'Interxion, n'est guère surpris par ce plan peu sophistiqué : "Très peu de sociétés, y compris parmi les très grands comptes, ont mis en place de vrais systèmes de continuité d'activité, même pour leurs applications critiques. Les plans de reprise d'activité ne devraient être déclenchés qu'en dernier recours. Ce n'est malheureusement pas le cas".