Contexte

L’intervention technique prévue les 12 et 13 juin derniers avait plusieurs objectifs :

•  installer de nouveaux matériels (serveurs, mémoires, commutateurs réseaux, serveurs de stockage, …) et migrer des services sur ces nouveaux matériels
•  réorganiser et sécuriser le réseau
•  réorganiser les serveurs dans les baies.
•  sécuriser l’alimentation électrique des serveurs

Certaines de ces interventions, délicates à mener, nécessitant une assistance extérieure, l’Abes a été obligée de programmer cet arrêt en semaine. De plus, une partie de ces interventions était un préalable à d’autres actions, planifiées durant l’arrêt prévu du 18 au 23 juillet – un arrêt imposé par notre hébergeur, le Cines, qui procède à de lourds travaux de sécurisation de son infrastructure électrique.

Le fait que cette intervention se soit révélée aussi « catastrophique » n’est pas dû à un manque de préparation – une équipe du DSI ayant travaillé depuis plusieurs mois à son organisation – mais à un malheureux jeu de pannes matérielles successives et improbables qui ont entrainé une impossibilité pour l’Abes de reprendre le service dans les délais annoncés.

Les faits marquants

• jeudi 12 juin à 16h : l’intervention débute normalement

• nuit de jeudi 12 à vendredi 13 : lors du redémarrage des serveurs, 3 matériels essentiels tombent en panne : 2 commutateurs réseaux et le serveur de stockage principal. De plus, du fait d’une configuration erronée, certains nouveaux matériels refusent également de fonctionner normalement. La panne la plus grave est celle affectant le serveur de stockage. En effet, celui-ci héberge les bases de données des Thèses, la base miroir du Sudoc (la base XML), ainsi que tous les serveurs (virtuels) d’indexation associés à ces 2 bases de données.
•  vendredi – samedi – dimanche : face à ces pannes, les équipes informatiques de l’Abes établissent une nouvelle stratégie afin de pouvoir reprendre le service et surtout éviter toute corruption de données.
• lundi 16 juin : grâce à cette intervention, le service peut reprendre partiellement. Les applications du Sudoc (WinIBW, interface publique, Colodus) et Calames fonctionnent normalement, malgré quelques perturbations passagères durant les 2 jours suivants. Malheureusement, du fait de la panne du serveur de stockage, les applications des Thèses ainsi que les services autour de la base miroir du Sudoc (Périscope, SelfSudoc, webservices) ne reprennent pas.
•  mardi 17 juin : l’Abes s’engage dans deux voies distinctes :

• reconstruire l’ensemble de services en panne sur de nouveaux serveurs puis restaurer les données à partir des sauvegardes
•  en parallèle, continuer à tenter avec notre prestataire de réparer le serveur de stockage.

• mercredi 18 : après plusieurs tentatives infructueuses, le serveur de stockage est partiellement réparé. Cependant, une nouvelle intervention est nécessaire. Elle est planifiée par le prestataire le jeudi matin. Le mercredi soir, l’Abes décide donc logiquement de ne pas reprendre le service puisque l’intervention prévue le jeudi matin nécessite à nouveau un arrêt. Malheureusement, après avoir repoussé une première fois l’intervention au jeudi après midi, le prestataire l’annule car … il a commandé la mauvaise pièce ! Suite à cette mauvaise nouvelle, l’Abes prend la décision de reprendre au plus tôt le service sur des nouveaux serveurs, de restaurer les données et de faire fonctionner le serveur partiellement réparé pour les quelques services qui n’ont pu être migrés sur de nouveaux serveurs.

•  soirée du jeudi et matinée du vendredi : après quelques ajustements, l’ensemble des services de l’Abes réouvre le vendredi après midi.

Et la suite ?

L’Abes va maintenant s’atteler à :

• terminer la migration des données encore présentes sur le serveur incriminé. Cette action est bien entendu déjà engagée.
• se prémunir pour que cette suite d’évènements ne puisse plus se reproduire. Du matériel réseau en secours va être acquis et tous les matériels de stockage seront doublés. L’intervention du 12 juin avait d’ailleurs cet objectif – un objectif qui, comme vous le comprendrez, n’a pu être mené à son terme. Durant cette intervention, il était en effet initialement prévu de migrer la majeure partie des données du serveur de stockage tombé en panne sur 2 nouveaux serveurs, avec duplication des données sur ces serveurs.
•  ajuster les procédures d’exploitation afin de pouvoir réagir au plus vite en cas de panne

Stéphane Rey, chef du Département Système d’Information