Le 9 novembre dernier, l’hébergeur OVH a connu une panne de grande envergure suite à une coupure électrique qui a affecté deux de ses datacenters à Strasbourg. En conséquence, plusieurs sites Internet hébergés par l’entreprise sont devenus inaccessibles.Dans un premier temps, Octave Klaba , PDG d’OVH a annoncé sur Twitter que les deux datacenters strasbourgeois (SGB1 et SGB4) sont tombés en panne après que leurs deux arrivées électriques sont tombées. Apparemment, les deux groupes électrogènes censés pallier ce genre d’ennuis n’ont pas fonctionné puisqu’ils « se sont mis en défaut ». En conséquence, l’alimentation a été coupée sur la salle de routage.
Par la suite, l’entreprise a mené son enquête et Klaba a partagé les résultats de celle-ci. Il a commencé par parler de l’architecture du site SBG. « Le site SBG est alimenté par une ligne de 20 kV composée de deux câbles délivrant chacun 10 MVA. Les deux câbles fonctionnent ensemble, et sont connectés à la même source et sur le même disjoncteur chez ELD (Strasbourg Electricity Networks). Ce matin, l'un des deux câbles a été endommagé et le disjoncteur a coupé l'alimentation du centre de données.
« Le site SBG est conçu pour fonctionner, sans limites de temps, sur les générateurs. Pour SBG1 et SBG4, nous avons mis en place un premier système de sauvegarde de deux générateurs de 2 MVA chacun, configurés en N + 1 et 20 kV. Pour SBG2, nous avons mis en place trois groupes en configuration N + 1 de 1,4 MVA chacun. En cas de coupure de courant externe, les cellules haute tension sont automatiquement reconfigurées par un système de basculement motorisé. En moins de 30 secondes, les datacenters SBG1, SBG2 et SBG4 peuvent être restaurés avec 20 KV. Pour effectuer ce basculement sans couper l'alimentation des serveurs, nous avons mis en place des alimentations sans interruption (UPS) qui peuvent maintenir l'alimentation jusqu'à huit minutes. »
Malgré toutes ces précautions, le système de basculement motorisé n’a pas fonctionné comme prévu ce matin-là. Pour être plus précis, la commande de démarrage des générateurs de secours n'a pas été donnée par l'automate. Raison pour laquelle OVH s’est tourné vers le fabricant pour comprendre l’origine de ce problème. L’hébergeur reconnaît toutefois qu’il s’agit là d’un défaut qui aurait dû être détecté lors de tests de simulation de pannes périodiques sur la source externe.
« Le dernier test de récupération de sauvegarde de SBG a eu lieu fin mai 2017. Lors de ce dernier test, nous avons alimenté SBG uniquement depuis les générateurs pendant huit heures sans aucun problème et chaque mois, nous testons les générateurs de secours vides. Et malgré tout, ce système n'était pas suffisant pour éviter la panne », a regretté Klaba.
La commande automatique n’ayant pas été passée à l’automate, OVH a été obligé de procéder manuellement pour alimenter le centre de données à partir de générateurs. L’hébergeur a ensuite contacté ELD pour lui demander de déconnecter le câble défectueux des cellules haute tension et de remettre en marche le disjoncteur avec seulement un des deux câbles, et donc limité à 10 MVA. « Cette action a été effectuée par ELD et le courant a été rétabli vers 10 h 30. Les routeurs de SBG étaient de retour en ligne à partir de 10 h 58 », a-t-il assuré.
« Afin d'éviter des scénarios catastrophiques comme celui-ci, OVH a développé au cours des 18 dernières années des architectures électriques capables de résister à toutes sortes de pannes de courant. Chaque test, chaque défaut, chaque nouvelle idée ont enrichi notre expérience nous permettant de construire des datacentres fiables aujourd'hui.
« Alors pourquoi cet échec? Pourquoi SBG n'a-t-il pas supporté une simple coupure de courant ? Pourquoi toute l'intelligence que nous avons développée chez OVH ne pourrait-elle pas empêcher cette catastrophe ?
« La réponse courte : le réseau électrique de SBG a hérité de tous les défauts de conception qui étaient le résultat des petites ambitions initialement prévues pour cet endroit. »
Donnant plus de détails, Klaba a rappelé qu’en 2011, OVH a planifié le déploiement de nouveaux centres de données en Europe. « Afin de tester l'appétit pour chaque marché, avec de nouvelles villes et de nouveaux pays, nous avons inventé une nouvelle technologie de déploiement de centres de données. Avec l'aide de cette technologie développée en interne, nous espérions obtenir la flexibilité nécessaire pour déployer un datacenter sans les contraintes de temps associées aux permis de construire. À l'origine, nous voulions avoir la possibilité de valider nos hypothèses avant de faire des investissements substantiels dans un endroit particulier. »
« C'est ainsi que début 2012, nous avons lancé le datacenter SBG1 constitué de conteneurs maritimes. Nous avons déployé huit conteneurs maritimes et SBG1 était opérationnel en moins de deux mois. Grâce à ce déploiement ultrarapide qui a pris moins de six mois, nous avons pu confirmer que SBG est bien un emplacement stratégique pour OVH. À la fin de 2012, nous avons décidé. »
Le problème était que, en déployant SBG1 avec la technologie basée sur les conteneurs maritimes, OVH était incapable de préparer le site pour un projet à grande échelle.
Aussi, Klaba a reconnu que son entreprise a fait deux erreurs :
- Nous n'avons pas rendu le site SBG conforme aux normes internes qui requièrent deux alimentations électriques séparées de 20 KV, comme tous nos sites DC, qui sont équipés de deux alimentations électriques. C'est un investissement majeur d'environ 2 à 3 millions d'euros par alimentation électrique, mais nous pensons que cela fait partie de notre standard interne ;
- Nous avons construit le réseau électrique de SBG2 en le plaçant sur le réseau électrique de SBG1 au lieu de les rendre indépendants l'un de l'autre, comme dans tous nos centres de données. Chez OVH, chaque numéro de centre de données indique que la grille d'alimentation est indépendante des autres centres de données. Partout sauf sur le site SBG.
La technologie basée sur les conteneurs maritimes n'a été utilisée que pour construire SBG1 et SBG4. « En fait, nous avons réalisé que le datacenter de conteneur ne correspond pas aux exigences de notre métier. Sur la base du taux de croissance de SBG, la taille minimale d'un site doit être égale à celle de plusieurs centres de données, et donc avoir une capacité totale de 200 000 serveurs. C'est pourquoi, pour déployer un nouveau centre de données aujourd'hui, nous n'utilisons que deux types de conceptions qui ont été largement testés et planifiés pour des projets de grande envergure et de fiabilité :
- La construction de tours de cinq à six étages (RBX4, SBG2-3, BHS1-2), pour 40 000 serveurs ;
- L'achat de bâtiments (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) pour 40 000 ou 80 000 serveurs. »
Raison pour laquelle, même si l'incident qui a frappé OVH a été causé par un automate tiers, l’hébergeur assure qu’il ne peut pas nier sa propre responsabilité pour la panne. « Nous avons un peu de travail à faire sur SBG pour atteindre le même niveau de qualité que les autres sites OVH », a reconnu Klaba.
Un plan d’action à hauteur de 4 à 5 millions d’euros a été adopté pour « nous permettre de redonner confiance à SBG et à OVH ». Il s’agit notamment :
- De l'installation d'une deuxième alimentation électrique 20 MVA complètement séparée ;
- De séparer le réseau électrique SBG2 de SBG1/SBG4, ainsi que la séparation du futur SBG3 de SBG2 et SBG1/SBG4 ;
- D’effectuer une migration des clients SBG1/SBG4 vers SBG3 ;
- de fermer SBG1/SBG4 et de désinstaller des conteneurs maritimes.
Source : message d'Octave Klaba
Envoyé par toutwd
, ou 