rssLink RSS for all categories
 
icon_red
icon_green
icon_blue
icon_red
icon_orange
icon_green
icon_green
icon_red
icon_green
icon_red
icon_green
icon_green
icon_green
icon_red
icon_green
icon_orange
icon_green
icon_blue
icon_red
icon_red
icon_green
icon_green
icon_green
icon_red
icon_orange
icon_green
icon_green
icon_green
icon_green
icon_red
icon_red
 

FS#28247 — SBG

Attached to Project— Reseau Internet et Baies
Incident
Strasbourg
CLOSED
100%
Nous vennons de perdre l'intégralité de l'alimentation électrique des équipements réseaux.
Nous investiguons.
Date:  Monday, 20 November 2017, 16:29PM
Reason for closing:  Done
Comment by OVH - Thursday, 09 November 2017, 07:53AM

Comment by OVH - Thursday, 09 November 2017, 07:55AM

Nous avons un problème d'alimentation électrique, apparemment
les groupes électrogènes n'ont pas fonctionné correctement.
Dans SBG1 se situe la salle de routage du site. Les routeurs
sont down depuis 7h14.


Comment by OVH - Thursday, 09 November 2017, 10:58AM

ERDF a réparé un des 2 liens 20KV. Le second est toujours down.
Les générateurs sont UP, les 2 salles de routage sont en cours de démarrage
SBG2 devrait être UP d'ici 20min
SBG1/SBG4 d'ici 1h-2h.


Comment by OVH - Thursday, 09 November 2017, 12:03PM

Le trafic reprends doucement, on est a un peu plus d'1/3 des IP de nouveau UP


Comment by OVH - Thursday, 09 November 2017, 12:09PM

Voici un etat des lieu :

-SBG1 est de nouveau alimenté
-SBG2 est de nouveau alimenté, excepté les baies 73A01 a 73A18
-SBG4 est toujours down, nos equipes travaillent a alimenter SBG4.


Comment by OVH - Thursday, 09 November 2017, 12:42PM

Toutes les baies ont été rallumées.
Nous vérifions que tout remonte correctement et nous sommes en cours d'identification des services/clients encore impactés.


Comment by OVH - Thursday, 09 November 2017, 17:53PM

Il reste encore en panne:
- 2100 serveurs dédié
- 1500 instances PCI
- 25000 VPS
- 300 hosts PCC


Comment by OVH - Thursday, 09 November 2017, 19:27PM

Il reste :
- 1600 serveurs dédiés
- 1200 instances PCI
- 21000 VPS
- 250 hosts PCC


Comment by OVH - Thursday, 09 November 2017, 20:10PM

Pour aider à gérer l'incident les équipes de renfort de RBX et LIM
sont arrivés sur le site vers 16h00. Depuis, plus de 50 personnes
travaillent dans le DC sans relâche pour remettre en route tous
les services de clients au plus vite.

Un camion avec les pièces "spares" est arrivé sur le place vers
17h30, en cas de casse de matériel, nous allons pouvoir remplacer
les serveurs au plus vite.

La "war room" tourne depuis 8h00 à RBX avec toutes les équipes
concernées par l'incident, nous centralisons toutes les informations
et nous coordonnons les actions entre les équipes.

Le support 1007 a été indisponible ce matin à cause de probleme
de réseau à RBX http://travaux.ovh.net/?do=details&id=28244
Nous avons remis en route tout le PABX au plus vite.

Nous avons fait le suivi des incidents avec tous les clients
Entreprise à travers les équipes Support TAM pour s'assurer que
tous leurs services sont UP.


Comment by OVH - Thursday, 09 November 2017, 22:22PM

Il reste :
- 1025 serveurs dédiés
- 1150 instances PCI
- 2700 VPS
- 250 hosts PCC

Les serveurs restants sont concernés par les dysfonctionnements des switchs liés aux tâches ci-après :
http://travaux.ovh.net/?do=details&id=28269
http://travaux.ovh.net/?do=details&id=28268
http://travaux.ovh.net/?do=details&id=28267


Comment by OVH - Friday, 10 November 2017, 00:27AM

Bonjour,
Ce matin à 7h23, nous avons eu une panne majeure sur notre site de Strasbourg (SBG) : une coupure électrique qui a mis dans le noir nos 3 datacentres SBG1, SBG2 et SBG4 durant 3h30. Le pire scénario qui puisse nous arriver.

Le site de SBG est alimenté par une ligne électrique de 20kV composée de 2 câbles qui délivrent chacun 10MVA. Les 2 câbles fonctionnent ensemble, et sont connectés à la même source et sur le même disjoncteur chez ELD (Strasbourg Électricité Réseaux). Ce matin, l’un des 2 câbles a été endommagé et le disjoncteur a coupé l’alimentation des datacentres.

Le site SBG est prévu pour fonctionner, sans limite de temps, sur les groupes électrogènes. Pour SBG1 et SBG4, nous avons mis en place, un premier système de 2 groupes électrogènes de 2MVA chacun, configurés en N+1 et en 20kV. Pour SBG2, nous avons mis en place 3 groupes en N+1 de 1.4MVA chacun. En cas de coupure de la source externe, les cellules haute tension sont reconfigurées automatiquement par un système de bascule motorisé. En moins de 30 secondes, les datacentres SBG1, SBG2 et SBG4 sont ré-alimentés en 20KV. Pour permettre toutes ces bascules sans couper l’alimentation électrique des serveurs, nous disposons d’onduleurs (UPS) sachant fonctionner sans aucune alimentation durant 8 minutes.

Ce matin, le système de basculement motorisé n’a pas fonctionné. L’ordre de démarrage des groupes n’a pas été donné par l’automate. Il s’agit d’un automate NSM (Normal Secours Motorisé), fournit par l’équipementier des cellules haute-tension 20kV. Nous sommes en contact avec lui, afin de comprendre l’origine de ce dysfonctionnement. C’est toutefois un défaut qui aurait dû être détecté lors des tests périodiques de simulation de défaut sur la source externe. Le dernier test de reprise de SBG sur les groupes date de la fin du mois mai 2017. Durant ce dernier test, nous avons alimenté SBG uniquement à partir des groupes électrogènes durant 8H sans aucun souci et chaque mois nous testons les groupes à vide. Et malgré tout, l’ensemble de ce dispositif n’a pas suffi aujourd’hui pour éviter cette panne.

Vers 10h, nous avons réussi à basculer les cellules manuellement et nous avons recommencé à alimenter le datacentre à partir des groupes électrogènes. Nous avons demandé à ELD de bien vouloir déconnecter le câble défectueux des cellules haute tension et remettre le disjoncteur en marche avec 1 seul des 2 câbles, et donc limité à 10MVA. La manipulation a été effectuée par ELD et le site a été ré-alimenté vers 10h30. Les routeurs de SBG ont été joignables à partir de 10h58.

Depuis, nous travaillons, sur la remise en route des services. Alimenter le site en énergie permet de faire redémarrer les serveurs, mais il reste à remettre en marche les services qui tournent sur les serveurs. C’est pourquoi chaque service revient progressivement depuis 10h58. Notre système de monitoring nous permet de connaitre la liste de serveurs qui ont démarré avec succès et ceux qui ont encore un problème. Nous intervenons sur chacun de ces serveurs pour identifier et résoudre le problème qui l’empêche de redémarrer.

A 7h50, nous avons mis en place une cellule de crise à RBX, où nous avons centralisé les informations et les actions de l’ensemble des équipes. Un camion en partance de RBX a été chargé de pièces de rechange pour SBG. Il est arrivé à destination vers 17h30. Nos équipes locales ont été renforcées par des équipes du datacentre de LIM en Allemagne et de RBX, ils sont tous mobilisés sur place depuis 16H00. Actuellement, plus de 50 techniciens travaillent à SBG pour remettre tous les services en route. Nous préparons les travaux de cette nuit et, si cela était nécessaire, de demain matin.

Prenons du recul. Pour éviter un scénario catastrophe de ce type, durant ces 18 dernières années, OVH a développé des architectures électriques capables de résister à toutes sortes d’incidents électriques. Chaque test, chaque petit défaut, chaque nouvelle idée a enrichi notre expérience, ce qui nous permet de bâtir aujourd’hui des datacentres fiables.

Alors pourquoi cette panne ? Pourquoi SBG n’a pas résisté à une simple coupure électrique d’ELD ? Pourquoi toute l’intelligence que nous avons développée chez OVH, n’a pas permis d’éviter cette panne ?

La réponse rapide : le réseau électrique de SBG a hérité des imperfections de design liées à la faible ambition initialement prévue pour le site.

La réponse longue :
En 2011, nous avons planifié le déploiement de nouveaux datacentres en Europe. Pour tester l’appétence de chaque marché, avec de nouvelles villes et de nouveaux pays, nous avons imaginé une nouvelle technologie de déploiement de datacentres, basée sur les containers maritimes. Grâce à cette technologie, développée en interne, nous avons voulu avoir la souplesse de déployer un datacentre sans les contraintes de temps liées aux permis de construire. A l’origine, nous voulions avoir la possibilité de valider nos hypothèses avant d’investir durablement dans un site.

C’est comme ça que début 2012, nous avons lancé SBG avec un datacentre en containers maritimes : SBG1. Nous avons déployé 8 containers maritimes et SBG1 a été opérationnel en seulement 2 mois. Grâce à ce déploiement ultra rapide, en moins de 6 mois nous avons pu valider que SBG est effectivement un site stratégique pour OVH. Fin 2012, nous avons décidé de construire SBG2 et en 2016, nous avons lancé la construction de SBG3. Ces 2 constructions n’ont pas été faites en containers, mais ont été basées sur notre technologie de « Tour » : la construction de SBG2 a pris 9 mois et SBG3 sera mis en production dans 1 mois. Pour pallier aux problèmes de place début 2013, nous avons construit très rapidement SBG4, l’extension basée encore sur les fameux containers maritimes.

Le problème est qu’en déployant SBG1 avec la technologie basée sur les containers maritimes, nous n’avons pas préparé le site au large scale. Nous avons fait 2 erreurs :
1) nous n’avons pas remis le site SBG aux normes internes qui prévoient 2 arrivées électriques indépendantes de 20KV, comme tous nos sites de DCs qui possèdent plusieurs doubles arrivées électriques. Il s’agit d’un investissement important d’environ 2 à 3 millions d’euros par arrivée électrique, mais nous estimons que cela fait partie de notre norme interne.
2) nous avons construit le réseau électrique de SBG2 en le posant sur le réseau électrique de SBG1, au lieu de les rendre indépendant l’un de l’autre, comme dans tous nos datacentres. Chez OVH, chaque numéro de datacentre veut dire que le réseau électrique est indépendant d’un autre datacentre. Partout sauf sur le site de SBG.

La technologie basée sur les containers maritimes n’a été utilisée que pour construire SBG1 et SBG4. En effet, nous avons réalisé que le datacentre en containers n’est pas adapté aux exigences de notre métier. Avec la vitesse de croissance de SBG, la taille minimale d’un site est forcément de plusieurs datacentres, et donc d’une capacité totale de 200.000 serveurs. C’est pourquoi, aujourd’hui, pour déployer un nouveau datacenter, nous n’utilisons plus que 2 types de conceptions largement éprouvées et prévues pour le large scale avec de la fiabilité :
1) la construction de tours de 5 à 6 étages (RBX4, SBG2-3, BHS1-2), pour 40.000 serveurs.
2) l’achat des bâtiments (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) pour 40.000 ou 80.000 serveurs.

Même si l’incident de ce matin a été causé par un automate tiers, nous ne pouvons nous dédouaner de la responsabilité de la panne. A cause du déploiement initial basé sur les containers maritimes, nous avons un historique à rattraper sur SBG pour atteindre le même niveau de normes que sur les autres sites d’OVH.

Cet après-midi, nous avons décidé du plan d’actions suivant :
1) la mise en place de la 2ème arrivée électrique, totalement séparée, de 20MVA ;
2) la séparation du réseau électrique de SBG2 vis-à-vis de SBG1/SBG4, ainsi que la séparation du futur SBG3 vis-à-vis de SBG2 et SBG1/SBG4;
3) la migration des clients de SBG1/SBG4 vers SBG3 ;
4) la fermeture de SBG1/SBG4 et la désinstallation des containers maritimes.

Il s’agit d’un plan d’investissement de 4-5 millions d’euros, que nous mettons en route dès demain, et qui, nous l’espérons, nous permettra de restaurer la confiance de nos clients envers SBG et plus largement OVH.

Les équipes sont toujours en train de travailler sur la remise en route des derniers clients impactés. Une fois l’incident clos, nous appliquerons les SLA prévus dans nos contrats.

Nous sommes profondément désolés pour la panne générée et nous vous remercions des encouragements que vous nous témoignez durant cet incident.

Amicalement
Octave

Edit le 11/11/17 à 22h : correction d'une erreur dans les unités évoquées (KVA était indiqué à la place de kV).


Comment by OVH - Friday, 10 November 2017, 01:20AM

Les équipes vont se relayer cette nuit. Une partie de l’équipe
continuent les travaux de remise en route de services jusqu'à
6h00 pendant que d'autres équipes sont parties dormir dans un
hôtel proche de SBG afin de reprendre les opérations demain à
6h00. De cette manière, nous allons pouvoir tout terminer pour
demain matin avant 8h00. Les équipes RUN à Montréal ont repris
les opérations et aident à distance les équipes qui bossent
cette nuit à SBG.


Comment by OVH - Friday, 10 November 2017, 01:28AM

Il reste :
- 799 serveurs dédiés
- 1150 instances PCI
- 2400 VPS
- 200 hosts PCC


Comment by OVH - Friday, 10 November 2017, 03:24AM

Il reste :
- 710 serveurs dédiés
- 903 instances PCI
- 2400 VPS
- 170 hosts PCC


Comment by OVH - Friday, 10 November 2017, 09:34AM

Hello,
This morning at 7:23 am, we had a major outage in our Strasbourg site (SBG): a power outage that left three datacenters without power for 3.5 hours. SBG1, SBG2 and SBG4 were impacted. This is probably the worst-case scenario that could have happened to us.

The SBG site is powered by a 20kV power line consisting of 2 cables each delivering 10MVA. The 2 cables work together, and are connected to the same source and on the same circuit breaker at ELD (Strasbourg Electricity Networks). This morning, one of the two cables was damaged and the circuit breaker cut power off to the datacenter.

The SBG site is designed to operate, without a time limit, on generators. For SBG1 and SBG4, we have set up a first back up system of 2 generators of 2MVA each, configured in N+1 and 20kv. For SBG2, we have set up 3 groups in N+1 configuration 1.4 MVA each. In the event of an external power failure, the high-voltage cells are automatically reconfigured by a motorized failover system. In less than 30 seconds, SBG1, SBG2 and SBG4 datacenters can have power restored with 20kV. To make this switch-over without cutting power to the servers, we have Uninterrupted Power Supplies (UPS) in place that can maintain power for up to 8 minutes.

This morning, the motorized failover system did not work as expected. The command to start of the backup generators was not given by the NSM. It is an NSM (Normal-emergency motorised), provided by the supplier of the 20kV high voltage cells. We are in contact with the manufacture/suplier to understand the origin of this issue. However, this is a defect that should have been detected during periodic fault simulation tests on the external source. SBG's latest test for backup recovery were at the end of May 2017. During this last test, we powered SBG only from the generators for 8 hours without any issues and every month we test the backup generators with no charge. And despite everything, this system was not enough to avoid today’s soutage.

Around 10am, we managed to switch the cells manually and started to power the datacenter again from the generators. We asked ELD to disconnect the faulty cable from the high voltage cells and switch the circuit breaker on again with only 1 of the 2 cables, and therefore were limited to 10MVA. This action was carried out by ELD and power was restored at approximately 10:30 am. SBG's routers were back online from 10:58 am onwards.


Since then, we have been working on restarting services. Powering the site with energy allows the servers to be restarted, but the services running on the servers still need to be restarted. That's why each service has been coming back gradually since 10:30 am. Our monitoring system allows us to know the list of servers that have successfully started up and those that still have a problem. We intervene on each of these servers to identify and solve the problem that prevents it from restarting.

At 7:50 am, we set up a crisis unit in RBX, where we centralized information and actions of all the different teams involved. A truck from RBX was loaded with spare parts for SBG. It arrived at its destination around 5:30 pm. To help our local teams, we sent teams from the LIM datacenter located in Germany and personnel from RBX datacenter, all of which have been mobilized on site since 4 PM. Currently, more than 50 technicians are working at SBG to get all services back online. We are preparing the work through night and if necessary into tomorrow morning.

In order to avoid catastrophic scenarios such as this one, over the past 18 years, OVH has developed electrical architectures that can withstand all sorts of power outages. Every test, every flaw, every new idea has enriched our experience allowing us to build reliable datacentres today.

So why this failure? Why didn’t SBG withstand a simple power failure? Why couldn’t all the intelligence that we developed at OVH, prevent this catastrophe?

The quick answer: SBG's power grid inherited all the design flaws that were the result of the small ambitions initially expected for that location.

Now here is the long answer:

Back in 2011, we planned the deployment of new datacenters in Europe. In order to test the appetite for each market, with new cities and new countries, we invented a new datacenter deployment technology. With the help of this internally developed technology, we were hoping to get the flexibility that comes with deploying a datacenter without the time constraints associated with building permits. Originally, we wanted the opportunity to validate our hypotheses before making substantial investments in a particular location.

This is how, at the beginning of 2012, we launched SBG1 datacenter made of shipping containers. We deployed 8 shipping containers and SBG1 was operational in less than 2 months. Thanks to this ultra-fast deployment which took less than 6 months we were able to confirm that SBG is indeed a strategic location for OVH. By the end of 2012, we decided to build SBG2 and in 2016, we launched the construction of SBG3. These 2 datacenters were not constructed from containers, but were based on our "Tower" technology. The construction of SBG2 took 9 months and SBG3 will be put in production within a month. In order to address the issue of space, at the beginning of 2013, we built SBG4 very quickly, based again on the much talked about shipping containers.

The issue was that, by deploying SBG1 with the technology based on shipping containers, we were unable to prepare the site for a large-scale project.

We made 2 mistakes:

1) We did not make the SBG site compliant with internal standards which require 2 separate 20kV electrical feeds just like all our DC locations, which are equipped with dual electrical feeds. It is a major investment of about 2 to 3 million euros per electrical feed but we believe this is part of our internal standard.

2) We built SBG2's power grid by placing it on SBG1's power grid instead of making them independent of each other, as in all our data centers. At OVH, each datacenter number indicates that the power grid is independent of other datacenters. Anywhere except on the SBG site.

The technology based on shipping containers was only used to build SBG1 and SBG4. As a matter of fact, we realized that the container datacenter doesn't fit the requirements of our trade. Based on SBG's growth rate, the minimum size of a site must be equal to several datacenters, and therefore have a total capacity of 200,000 servers. That's why in order to deploy a new datacenter today, we are only using 2 types of designs that have been widely tested and planned for large-scale projects and reliability:

1) the construction of 5 to 6-story towers (RBX4, SBG2-3, BHS1-2), for 40,000 servers.
2) purchasing buildings (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) for 40,000 or 80,000 servers.

Even if this morning's incident was caused by third-party automaton, we cannot deny our own liability for the breakdown. We have some catching uptp do on SBG to reach the same level of standards as other OVH sites.

During the course of the afternoon, we decided on the following action plan:
1) the installation of a second, completely separate 20MVA electrical feed;
2) separating SBG2 power grid from SBG1/SBG4, as well as the separation of the future SBG3 from SBG2 and SBG1/SBG4;
3) migration of SBG1/SBG4 customers to SBG3;
4) closing SBG1/SBG4 and the uninstallation of the shipping containers.

This is a EUR 4-5 million investment plan, which we are launching tomorrow and hope will enable us to restore our customers' confidence in SBG and OVH.

Our teams are still hard at work to restore services to the last of the impacted customers. Once the incident is completely resolved we will apply the SLA under our contracts.

We are deeply sorry for this incident and we thank the trust that you place in us.

Best,
Octave

Edited on the 11th November at 10PM : Unit error correction (KVA was used instead of kV)


Comment by OVH - Friday, 10 November 2017, 16:05PM

We still have 100% of the infrastructure UP.
At this stage, 99% of the serveurs are up and running.
We are working on the 1%: we change the hardware, remplace the pieces ..

All the teams stay mobilized to resolve remaining isolated issues.


Comment by OVH - Friday, 10 November 2017, 18:22PM

100% of the infrastructure has been UP since yesterday 11h00.
We are working the hardware issues. We still have:
- dedicated servers
380 serveurs

- pci / vps
64 hosts with
1000 VPS/PCI
no issue on ceph

- pcc
88 hosts are down. no issue on storage.
all the VMs are running on vSpheres:
no customer is impacted.


Comment by OVH - Friday, 10 November 2017, 18:44PM

At 6pm, the additional teams came from GRA and RBX to SBG.


Comment by OVH - Friday, 10 November 2017, 22:11PM

Une nouvelle équipe de RBX est arrivée sur place pour donner un coup
de main sur SBG. Les infrastructures sont UP depuis hier 11h00. Depuis
le travail consiste à faire démarrer les serveurs. Normalement les
serveurs démarrent seuls et automatiquement, sauf qu'il y a toujours
un faible % de serveurs qui ont de problèmes divers et variés:
- problème hardware, la carte mère à remplacer, l'alimentation qui
n'a pas supporté la coupure
- le problème de boot, le montage de disques, le kernel panic, la
compatibilité entre le kernel et la carte mère
- le firewall du client mal configuré qui empêche la prise en main
du serveur par le client.

Il nous reste un peu moins de 400 serveurs toutes les offres à faire
démarrer. Nous avons tous les types de problèmes hardware avec ces
serveurs et nous remplaçons les pièces défectueuse serveur par serveur
grâce au stock de pièce détaché arrivé par camion hier fin de
l’après midi.

Un technicien arrive à gérer environ 25 interventions lourdes par
jour, des cas aussi lourd qu'aujourd'hui. Avec 400 problèmes encore
sur la TODO, le calcul est simple: il nous faut entre 15 à 25 tech
pour terminer l'incident. C'est pourquoi les équipes se relayent
sans cesse depuis hier midi grâce au staff qui est arrivé des autres
DCs. #OneTeam

Les équipes RUN au Canada ont repris la gestion de problèmes soft
et aident les équipes de DC. Nous avons les configurations de l'IPMI
qui ont sauté, les problèmes de boot, les problèmes de kernel, etc.
Aussi, pour les services comme PCI/VPS/PCC, les équipes produit
gèrent les infrastructures pour rallumer les machines virtuelles
de clients. Il reste 64 hosts PCI en panne hardware et nous
remplaçons les pièces pour ces hosts. Progressivement les VPS
et les PCI qui sont encore down vont revenir durant cette nuit.

On pense d'arriver à moins de 100 serveurs down pour début de la
journée de samedi. Nous avons prévu les équipes qui vont démarrer
le travail ce Samedi matin aussi bien dans le DC, le RUN et le
support. La war room à RBX continuera à orchestrer les actions
communes.


Comment by OVH - Friday, 10 November 2017, 22:28PM

Nous avons 30 techs sur place qui vont travailler toute la nuit
avec 5 managers pour coordonner les travaux. On espère descendre
à moins de 100 serveurs pour le matin puis terminer les 100
derniers pour demain midi. La fin est hyper lente et insoutenable
à attendre.


Comment by OVH - Saturday, 11 November 2017, 03:41AM

22:11
A new Team from RBX has now arrived on site to help the SBG team. The infrastructure has been UP since 11:00 yesterday. The priority is to get the servers re-started. Normally, the servers re-start automatically, except that there are always a small percentage of servers with various problems: hardware problems, motherboard to be replaced, power supply which couldn't stand the power cut, boot problems, disk not mounting properly, kernel issue, compatibility between kernel and motherboard, client's firewall not configured properly preventing the client to start his servers…

We have just under 400 servers left. We have all types of hardware problems with these servers and we replace the defective parts server by server thanks to the stock of spare parts arrived by truck yesterday, end of the afternoon.

A technician manages about 25 heavy interventions per day. With 400 issues to solve, the calculation is simple: we need between 15 to 25 technicians to complete the incident. That's why the teams take turns since yesterday noon thanks to the staff who arrived from the others DCs. #OneTeam

RUN teams in Canada have resumed software issues and help the DC teams to progress faster. We have IPMI configurations that jumped, boot problems, kernel problems, etc.
Also, for services such as PCI/VPS/PCC, product teams will manage infrastructure to power up virtual machines of clients. There are still 64 PCI hosts down and we replace the parts for these hosts. Progressively VPS and the PCIs that are still down will come back during the night.

We are thinking of reaching less than 100 servers down by the start of the day on Saturday 11th. We've arranged for the teams to be able to work this Saturday morning in the DC, RUN as well as the support. The war room in RBX will continue to coordinate all actions.

22:27

We have now 30 technicians on site who will work all night long with 5 managers to coordinate the work. We're hoping to get off
to less than 100 servers in the morning and then finish the 100 by noon tomorrow.


Comment by OVH - Saturday, 11 November 2017, 07:40AM

PCI/VPS:
il reste 10 hosts à réparer. les hosts sont très complexes
et il faut compter 1H par host

SD (SYS/OVH)
il reste encore un peu plus de 200 serveurs à réparer.

---------------

PCI/VPS: there is 10 hosts that has to be reparted. the
host is very complex and we need 1H per host.

Servers (SYS/OVH)
We have 200 serveurs that the hardware issues that we
are working on.


Comment by OVH - Saturday, 11 November 2017, 20:10PM

Restant de la panne, pas encore revenu, avec un problème hardware sur lequel on est toujours en train de travailler: 73 serveurs. Nous avons 5 équipes de 4 personnes qui bossent dessus.

Nous avons 125 serveurs qui sont DOWN après l'incident, normalement rien à avoir avec l'incident. Il s'agit de l'activité "monitoring" standard mais qui n'a pas été traité dans les bons délais car tout le monde a été sur l'incident. Depuis ce matin, nous avons une équipe qui bosse dessus et nous allons la monter à 4 équipes à partir de demain matin jusqu'à vendredi. On pense que nous aurons un volume plus important sur cette activité durant les prochains jours. On vient d’affréter une avion qui va faire la navette entre Lille et Strasbourg à partir de demain pour que le matin on dépose les équipes de Roubaix à SBG et on les reprenne le soir. La première rotation sera fait demain matin à 7h00.

Sur les PCI, il reste encore 8 hosts (700 VPS), on est à fond dessus pour avoir 0 ce soir.



*English Version*

Following the incident, we now have 73 servers remaining with hardware issues that we are still working to resolve.
Currently there are five teams of four people working on it.
 
We had 125 servers DOWN after the incident which were not directly related to the original failure. This is standard "monitoring" activity, but  were not processed in a timely manner due to the fact that everyone was working on the main incident. Since this morning, we have had a team working on it and we're going to reinforce this team with up to 4 additional teams starting tomorrow morning until Friday. It is expected that we will have a larger volume on this activity in the coming days.

We have chartered a plane that will shuttle between Lille and Strasbourg starting tomorrow so that in the morning we can fly teams from Roubaix to SBG and pick them up again in the evening. The first rotation will be done tomorrow morning at 7:00 am.

Regarding PCI, there are still 8 hosts (700 VPS) down, we anticipate there will be 0 tonight.


Comment by OVH - Saturday, 11 November 2017, 22:08PM

Tous les hosts PCI sont UP. On regarde maintenant les VPS/PCI
qui resteraient DOWN. Si vous avez encore de souci, merci de
m'envoyer un Direct Message (DM) via le twitter @olesovhcom
avec les informations techniques: IP / NOM de VPS


*English version*

All PCI hosts are now UP. We're now watching VPS/PCIs that are remaining DOWN. If you're still having trouble, thank you for
sending me a Direct Message (DM) via twitter @olesovhcom with technical information: IP / VPS NAME


Comment by OVH - Sunday, 12 November 2017, 16:16PM

76 servers remains DOWN:
- 16 during the incident
- 60 after the incident (36 less that 24 hours)


Comment by OVH - Friday, 17 November 2017, 22:28PM

Tous les services sont UP depuis Dimanche très tard dans la nuit.


Comment by OVH - Friday, 17 November 2017, 22:35PM

Bonjour,
Voici le post-mortem de l'incident.

Le jeudi 9 novembre, à 7 h 04, le site de Strasbourg, hébergeant 4 datacentres, a été privé d’énergie. Malgré toutes les sécurisations mises en place, la coupure électrique s’est propagée dans les datacentres et a provoqué un arrêt électrique de 40 386 serveurs hébergés sur le site.

À 10 h 39 le site a été réalimenté, puis les services ont progressivement redémarré. A 18 h 00, 71 % des serveurs étaient fonctionnels, et le vendredi 10 novembre à 23 heures, 99 % des serveurs étaient fonctionnels. Une minorité de services a été affecté jusqu’au dimanche 12 novembre.


Déroulé de l’incident en temps réel (jeudi 9 novembre) :
----------------------------------------------------------
7h04:07 : disjonction du côté d’Électricité de Strasbourg Réseau (ESR) et perte de l’alimentation électrique des deux lignes.
7h04:17 : les groupes électrogènes haute tension (HT) ne démarrent pas.
7h12:48 : l’onduleur 6 (UPS) arrive en fin d’autonomie batterie.
7h15:48 : l’onduleur 5 arrive en fin d’autonomie batterie.
7h17:25 : l’onduleur 2 arrive en fin d’autonomie batterie.
7h18:00 : les premières tentatives manuelles de redémarrage des groupes HT ont échoué.
7h18:39 : l’onduleur 1 arrive en fin d’autonomie batterie.
7h19:19 : l’onduleur 4 arrive en fin d’autonomie batterie.
7h21:00 : l’onduleur 3 arrive lui aussi en fin d’autonomie batterie.
7h21:00 : les salles de routage ne sont plus alimentées électriquement.
7h21:03 : nouvelle tentative manuelles de démarrage du groupe HT numéro 1.
7h22:42 : nouvelle tentative manuelles de démarrage du groupe HT numéro 2.
7h30 : la cellule de crise locale est opérationnelle.
7h50 : la cellule de crise centrale au siège de Roubaix est opérationnelle.
Entre 7h50 et 10h39 : multiples tentatives manuelles de redémarrage des groupes électrogènes accompagnées par nos experts en génie électrique.
10h39 : ESR rétablit l’alimentation secteur.
10h58 : les routeurs sont de nouveau joignables.
11h : les interventions sur les serveurs le nécessitant sont en cours.
14h : arrivée d’une première équipe renfort
16h : des renforts venus de nos sites de Francfort (Allemagne) et de Roubaix arrivent.
17h30 : un camion de 38 tonnes rempli de pièces détachées arrive sur place.
22h : 97 % des serveurs fonctionnent, 91 % répondent au ping.


Quelle est la cause de la disjonction côté ESR ?
------------------------------------------------
L’ensemble du site est alimenté par 1 alimentation électrique de 20MVA réalisée avec 2 câbles de 20kV. La cause de la disjonction est liée à une altération d’un des 2 câbles souterrains, qu’ESR a réparé rapidement. Les causes de l’altération de ce câble ne sont pas encore déterminées à date. Des investigations sont en cours par ESR.


Pourquoi la perte d’un câble a entraîné une coupure d’alimentation ?
--------------------------------------------------------------------
Le site de Strasbourg est alimenté par deux câbles délivrant 20MVA et donc connectés sur le même disjoncteur. Le déclenchement du disjoncteur a entraîné la coupure des deux lignes.


Pourquoi les générateurs haute tension ne se sont-ils pas mis en route ?
------------------------------------------------------------------------
SBG1 et SBG4 sont alimentés par 2 groupes électrogènes (HT), de 2MVA chacun, qui prennent le relais en cas de coupure électrique. L’inverseur normal/secours motorisé n’a pas rempli sa fonction correctement et n’a pas démarré les groupes électrogènes.

Après investigation, nous avons constaté que l’ordre de démarrage des groupes haute tension (HT) n’avait pas été envoyé par l’automate pilotant l’inverseur.

Le fabriquant de cet automate est venu l’expertiser. Il s’avère qu’il était bloqué en défaut « automatisme verrouillé », ce qui explique l’absence de démarrage des groupes HT. Des investigations sont en cours pour comprendre l’origine de ce blocage.

L’équipe d’intervention du fabricant a remis l’automate en état de fonctionnement normal. Nous n’avons pour l’instant pas d’explication à cette erreur. En l’attente des conclusions, nous assurons la permanence en roulement d’une personne dédiée 24 heures/24 et 7 J/7 afin d’être en mesure de forcer la bascule manuellement pour parer à un éventuel nouveau défaut de l’automate.

Dans les prochains jours, nous allons réaliser le test en charge du site ce qui nous permettra de valider le bon fonctionnement de l’automate.


Pourquoi les tentatives de démarrage des groupes HT ont-elles échoué ?
----------------------------------------------------------------------
Le datacentre SBG2 est alimenté avec 2 groupes électrogènes BT de 1.4MVA chacun. L’un de ces 2 groupes BT était en « mode maintenance ». En « mode maintenance », dans le cas d’une coupure électrique, les 2 groupes électrogènes HT de SBG1 fournissent l’énergie à SBG2, à la place du groupe électrogènes BT en maintenance.

Jeudi le 9 novembre, lorsque que le site a été privé d’énergie, l’inverseur normal/secours motorisé n’a pas rempli sa fonction correctement et n’a pas donné l’ordre de démarrage aux groupes HT.

Nous avons donc procédé à des tentatives de démarrage manuelles.

Pour faire fonctionner la charge électrique de SBG1, SBG4 et SBG2 avec l’un des deux groupes BT en « mode maintenance », il faut absolument que les 2 groupes HT fonctionnent ensemble afin de fournir 4MVA. Comme les 2 groupes électrogènes HT ne sont pas parvenus à se synchroniser, nous avons alors découplé les 2 groupes électrogènes HT pour les faire fonctionner séparément. Un groupe seul délivrant uniquement 2MVA ne peut tenir la charge demandée et il s’arrête. Nous avons effectué de multiples essais dans différentes configurations, sans succès.


Combien de temps a-t-il fallu pour rétablir les services ?
----------------------------------------------------------
Des moyens exceptionnels ont été mis en place afin de rétablir au plus vite les services.


État des lieux général :
------------------------
Jeudi à 22 heures, 97 % des serveurs (hardware) étaient de nouveau fonctionnels ainsi que 91 % des services (software). Vendredi à minuit, 99 % des serveurs étaient de nouveau opérationnels ainsi que 96,2 % des services.

Dans le détail :

Private Cloud :
----------------
Jeudi 9 novembre
·       23h : 78,59% des vCenters opérationnels 

Vendredi 10 novembre
·         5h : 100% des vCenters opérationnels


Object Storage/Cloud Archive :
-------------------------------
Jeudi 9 novembre, 13h35 : 100 % opérationnel


PCS :
-----
Jeudi 9 novembre, 13h35 : PCS/PCA 100% opérationnel

PCI/VPS* : (*zoning PCI : les « régions PCI » ont une nomenclature différente de celle des datacenters)
------------------------
11h30 : API est UP sur le région SBG1/SBG2/SBG3
17h : 98% instances OK région SBG3
20h00 : 98% instances OK région SBG1
21h00 : 92% instances OK région SBG2

Vendredi 10/11
16h00 : 100% instances OK région SBG1
16h30 : 100% instances OK région SBG2

Samedi 11/11
18h : 100% instances OK région SBG3


SD :
----
Jeudi 9/11
21h : 93,05% des serveurs dédiés sont opérationnels

Vendredi 10/11
17h : 99,1% des serveurs dédiés sont opérationnels


Comment avez-vous géré la situation ?
--------------------------------------
Dès 7 h 50, une cellule de crise est activée à Roubaix afin de coordonner toutes les actions des équipes. Octave Klaba, le CEO et fondateur d’OVH, rend compte de l’évolution de la situation en temps réel, via les réseaux sociaux. Des explications détaillées sont aussi fournies sur la tâche travaux.
 
En parallèle, les équipes support françaises s’organisent avec leurs homologues québécoises pour répondre à un maximum de sollicitations. Les clients Grands Comptes concernés sont contactés afin de leur apporter des solutions rapides et concrètes.
 
À Strasbourg, les équipes datacentres sont vite renforcées par des techniciens venus de nos centres de données allemands (Francfort) et français (Roubaix). Un véritable pont routier et ferroviaire est mis en place. Vers 17 h 30, un camion de 38 tonnes provenant du centre logistique d’OVH en métropole lilloise, leur apporte toutes les ressources matérielles additionnelles nécessaires pour les heures à venir. Plusieurs camions arriveront les jours suivants, suite à la mise en place d’une astreinte logistique à Roubaix.

Ces équipes ont ainsi travaillé sans relâche, nuit et jour, pour rétablir les services de tous les clients, allant jusqu’à justifier l’organisation et la mise en place d’un pont aérien entre Lille et Strasbourg afin d’accélérer les rotations des équipes présentes sur place durant le week-end et toute la semaine.


Quel est le plan d’action mis en place suite à cet évènement ?
---------------------------------------------------------------
Comme évoqué précédemment, nous avons immédiatement pris des mesures pour proscrire ce type d’incident à Strasbourg (SBG) ainsi que sur l’ensemble de nos sites.

Ce plan d’actions va se déployer en 2 phases.

À court terme
-------------
Nous avons demandé un rapport détaillé au fournisseur de l’automate.

Puisque le basculement de l’automate normal/secours motorisé n’a pas fonctionné, nous avons une présence dédiée 24 heures sur 24 et 7 jours sur 7, afin de pouvoir réaliser manuellement la manœuvre en cas de non-fonctionnement de l’automatisme. Cette astreinte sécurise le site en attendant qu’un test en charge puisse confirmer le bon fonctionnement de l’automate.

Pour la partie inverseur normal/secours, nous allons rapidement remplacer la partie automatisme par un automate « maison », qui nous permettra d’en maîtriser complètement le fonctionnement et de le monitorer. Un système identique est déjà en production à Gravelines.

Nous avons demandé un rapport détaillé à ESR concernant l’origine de l’avarie.

Une étude de faisabilité concernant le raccord d’une deuxième arrivée électrique de 20MVA est également lancée. En attendant, nous avons lancé une 2eme étude : la mise en place de 2 disjoncteurs isolés, un par câble, ce qui permettrait de secourir un éventuel défaut sur l’un des 2 câbles.

Nous allons effectuer la séparation du réseau électrique de SBG2 vis-à-vis de SBG1/SBG4 ainsi que la séparation du futur SBG3, vis-à-vis de SBG2 et SBG1/SBG4. De cette manière, chaque datacentre disposera de son alimentation de secours indépendante.

Un audit électrique est également en cours pour l’ensemble de nos sites.

À noter : à l’heure actuelle, lorsqu’un serveur est commandé sur le site de Strasbourg, il apparaît par défaut au sein de l’espace client comme hébergé au sein de SBG1, même s’il est hébergé à SBG2 ou SBG4. C’est un bug d’affichage. Cette anomalie sera corrigée très rapidement afin de laisser apparaître le datacentre réel au sein duquel le serveur est hébergé.


À long terme
------------
La technologie basée sur les containers maritimes ne sera plus utilisée par OVH. En effet, elle n’a été utilisée que pour construire SBG1 et SBG4, et hérite des imperfections de design liées à la faible ambition initialement prévue pour le site. Aujourd’hui, nous réalisons qu’elle n’est plus adaptée aux exigences de notre métier et aux normes OVH. Nous allons donc démanteler SBG1 et SBG4.

Pour cela, une migration de l’ensemble des services de nos clients hébergés sur SBG1 et SBG4 sera opérée vers SBG2 et SBG3 ou sur d’autres datacentres OVH.


Nous sommes sincèrement désolés pour cette panne et nous faisons le nécessaire afin que ce type d'incident ne se reproduise plus.

Amicalement
Octave


Comment by OVH - Saturday, 18 November 2017, 02:31AM

*English version*


Hello,
Here is the post-mortem of the incident.

On Thursday, November 9, at 07:04, the Strasbourg site, hosting 4 datacenters, experienced an electrical power cut. Despite all the security measures put in place, the power outage spread to the other datacenters and caused an electrical shutdown of the 40,386 servers hosted on the site.

At 10:39 electrical power was restored on the site and the services gradually restarted. By 6:00 pm, 71% of the servers were functional again, and on Friday, November 10th at 11:00 pm, 99% of the servers were functional. A minority of services remained impacted until Sunday, November 12th.


Timeline of the incident (Thursday, November 9th):
----------------------------------------------------------
7:04:07 : The power grid of electrical power supplier ESR (Électricité de Strasbourg Réseau) experiences à power failure leading to a loss of power supply on both lines.
7:04:17 : The High Voltage Power Generators (HV) do not start.
7:12:48 : Inverter 6 (UPS) reaches the end of its battery life.
7:15:48 : Inverter 5 reaches the end of its battery life.
7:17:25 : Inverter 2 reaches the end of its battery life.
7:18:00: The first manual attempts to restart the HV Generators are unsuccessful.
7:18:39 : Inverter 1 reaches the end of its battery life.
7:19:19 : Inverter 4 reaches the end of its battery life.
7:21:00 : Inverter 3 also reaches the end of its battery life.
7:21:00 : Routing centers are no longer electrically powered.
7:21:03 : New attempt to manually start the #1 HV Generator group.
7:22:42 : New attempt to manually start the #2 HV Generator group.
7:30:00 : Local crisis team is operational.
7:50:00 : Central crisis team at Roubaix HQ is operational.
Between 7:50 and 10:39: multiple manual attempts to restart the power generators with the help of our electrical engineering experts.
10:39 : ESR restores the power supply.
10:58 : The routers are reachable again.
11:00 : Interventions on the servers requiring attention are in progress.
14:00 : Arrival of a first team of reinforcements
16:00 : Arrival of reinforcements from our sites in Frankfurt (Germany) and Roubaix.
17:30 : A 38-ton truck, filled with spare parts arrives on site.
22:00 : 97% of the servers are up and running again, 91% respond to ping.


Why did the power supply break down at ESR ?
------------------------------------------------
The entire site is powered by one 20MVA power supply via two 20kV cables. The cause of the power failure is linked to an alteration of one of the 2 underground cables, which ESR repaired quickly. The causes of the alteration of this cable are not yet determined. Investigations are ongoing by ESR.


Why did the failure of one cable cause a power cut?
--------------------------------------------------------------------
The Strasbourg site is powered by two cables delivering 20MVA and therefore connected to the same circuit breaker. The tripping of the circuit breaker caused the two lines to break.


Why didn't the high-voltage generators start up?
------------------------------------------------------------------------
SBG1 and SBG4 are powered by two High Voltage (HV) Power Generators, each delivering 2MVA, which are meant to take over in case of power failure. The normal inverter/emergency inverter engine failed to function properly and did not start the Power Generator groups.

After investigation, we found that the PLC driving the inverter had not sent the command to start the High Voltage (HV) Power Generators.

The manufacturer of this automated device has assessed the failure. It turns out that the PLC was locked in a default "locked automatics" mode, which explains why the command to start the HV Generators was never sent. Investigations are underway to understand the origin of this blockage.

The manufacturer's response team returned the PLC to normal operation. As of now, we have no explanation for this error. As we wait for the conclusions of the enquiry, we ensure the permanent rotation of a dedicated person, 24 hours a day, 7 days a week, in order to manually throw the switch, should the automatic device again fail to operate.

In the coming days, we will be running stress tests and performance tests on site in order for us to warrant the proper functioning of the automatic device.


Why did the attempts to start the HV Generator groups fail?
----------------------------------------------------------------------
The SBG2 datacentre is powered by two 1.4MVA LV Generator groups. One of these two LV units was in "maintenance mode". When one of the units is in "maintenance mode", should an electrical power failure occur, the 2 HV Generator sets of SBG1 also supply SBG2 with power, in replacement of the LV generator that is under maintenance.

On Thursday, November 9th, when the site experienced a power failure, the normal inverter / emergency inverter engine did not perform its function properly and did not send the signal to start the HV Generators.

We therefore made numerous attempts to start them manually.

To operate the electrical load of SBG1, SBG4 and SBG2 when one of the two LV units is in "maintenance mode", it is imperative that the 2 HV units work together in order to be able to provide 4MVA. As the 2 HV Generator groups failed to synchronize, we then decoupled the 2 HV Generators in order to operate them separately. But a single group, delivering only 2MVA, cannot hold the requested load and thus the Generators went into emergency stop. We performed multiple tests in different configurations, without success.


How long did it take to restore services?
----------------------------------------------------------
Exceptional resources were put in place to restore services as quickly as possible.


General overview :
------------------------
At 22:00 on Thursday, 97% of the servers (hardware) were back up and running and 91% of the services (software) were running again. By midnight on Friday, 99% of the servers were operational again as well as 96.2% of the services.

In details :

Private Cloud:
----------------
Thursday, November 9th
· 23:00: 78,59% of vCenters are operationnal 

Friday, November 10th
05:00: 100% of vCenters are operationnal


Object Storage / Cloud Archive:
-------------------------------
Thursday, November 9th, 13:35: 100% operational


PCS:
-----
Thursday, November 9th, 13:35: PCS / PCA 100% operational

PCI/VPS *: (*PCI zoning: "PCI regions" have a different nomenclature than datacenters)
------------------------
11:30 : API is UP for the region SBG1/SBG2/SBG3
17:00 : 98% instances OK for region SBG3
20:00 : 98% instances OK for region SBG1
21:00 : 92% instances OK for region SBG2

Friday 10/11
16:00: 100% instances OK for region SBG1
16:30: 100% instances OK for region SBG2

Saturday 11/11
18:00 : 100% instances OK for region SBG3


SD:
----
Thursday 9/11
21:00 : 93.05% of the dedicated servers are operational

Friday 10/11
17:00 : 99.1% of the dedicated servers are operational


How did you handle the situation?
--------------------------------------
From 7:50 am, a crisis team was activated in Roubaix to coordinate all the actions of the different teams. Octave Klaba, the CEO and founder of OVH, reported in real-time on the evolution of the situation, via social networks. Detailed explanations were also provided on the work task.
 
In parallel, the French support teams coordinated with their Quebec counterparts to be able to respond to a maximum number of calls from clients. Key accounts customers were contacted to provide them with quick and effective solutions.
 
In Strasbourg, the datacenter teams were quickly reinforced by technicians from our German (Frankfurt) and French (Roubaix) datacenters. A true road and rail bridge was set up. Around 17:30, a 38-ton truck from the OVH logistics center in the Lille metropolitan area arrived on site to provide the teams with all the additional material resources needed for the coming hours. Several other trucks would arrive in the following days, following the establishment of a logistics standby system in Roubaix.

These teams worked tirelessly, night and day, to restore the services of all clients, even justifying the organization and implementation of an airlift between Lille and Strasbourg to speed up the rotation of teams on site during the weekend and all week long.


What action plan has been implemented following this incident ?
---------------------------------------------------------------
As mentioned above, we immediately took measures to prevent this type of incident from happening again, in Strasbourg (SBG) as well as on all our sites.

This action plan will be deployed in 2 phases.

Short term
-------------
We requested a detailed report from the vendor of the automated PLC controller.

Since the automatic switchover of the normal inverter/emergency inverter engine did not work, we now have a 24/7 dedicated presence on site, in order to be able to throw the switch manually, should the PLC fail again. This 24/7 standby ensures the power security of the site until a series of stress and performance tests can confirm the proper functioning of the controller.

As far as the normal/emergency inverter is concerned, we are going to quickly replace the automated controller with an "in-house" controller, which will allow us to fully master its functioning and monitor it. An identical system is already used in production in Gravelines.

We asked ESR for a detailed report on the origin of the fault.

A feasibility study for the connection of a second 20MVA electrical line is also underway. In the meantime, we have launched a second study: the implementation of two isolated circuit breakers, one for each cable, which would help to circumvent a possible failure on one of the two cables.

We are going to separate SBG2's electricity network from SBG1/SBG4's as well as separate the future SBG3 from SBG2 and SBG1/SBG4. In this way, each datacenter will have its own independent backup power supply.

An electrical audit is also underway for all of our sites.

Note: Currently, when a client orders a server on the Strasbourg site, it appears by default within the client area as being hosted on SBG1, even if it is hosted on SBG2 or SBG4. This is a bug in the display and will be corrected very quickly in order to indicate the actual datacenter on which the server is hosted.


Long-term
------------
The technology based on maritime containers will no longer be used by OVH. Indeed, this setup has only been used to build SBG1 and SBG4 and it thus inherited all the design flaws related to the initial low ambitions we had for this site. Today, we realize that this setup is no longer adapted to the requirements of our business and does not align with OVH standards. We are therefore going to dismantle SBG1 and SBG4.

In order to do this, we will migrate all of our customer's services hosted on SBG1 and SBG4, moving them either to SBG2 and SBG3 or to other OVH datacentres.

We are truly sorry for this breakdown and we are doing everything necessary to ensure that such an incident never happens again.

Sincerely
Octave
 


Comment by OVH - Monday, 20 November 2017, 16:28PM

OVH
9 listopada 2017 – Incydent w centrum danych SBG

W czwartek, 9 listopada 2017, o godzinie 7: 04, w obiekcie w Strasburgu, na którego terenie znajdują się cztery centra danych, wystąpiła awaria zasilania elektrycznego. Mimo zastosowanych przez OVH zabezpieczeń, incydent spowodował przerwę w dosyle prądu do centrów danych i odcięcie zasilania 40 386 serwerów.

O godzinie 10:39 zasilanie elektryczne w obiekcie zostało ponownie uruchomione, następnie sukcesywnie przywracano prawidłowe funkcjonowanie usług. O godzinie 18:00 działało 71% serwerów, natomiast w piątek, 10 listopada, o godzinie 23:00 pracowało 99 % serwerów. Niewielki procent usług pozostawał niedostępny do niedzieli, 12 listopada.

Przebieg incydentu w czasie rzeczywistym (czwartek, 9 listopada):

O godz. 7:04:07 następuje przerwa w dosyle prądu po stronie elektrowni Électricité de Strasbourg Réseau (ESR) i utrata zasilania dwóch linii energetycznych.
7:04:17 agregaty wysokiego napięcia nie uruchamiają się.
7:12:48 rozładowuje się zasilacz 6 (UPS).
7:15:48 rozładowuje się zasilacz 5.
7:17:25 rozładowuje się zasilacz 2.
7:18:00 pierwsze próby ręcznego uruchomienia agregatów wysokiego napięcia kończą się niepowodzeniem.
7:18:39 rozładowuje się zasilacz 1.
7:19:19 rozładowuje się zasilacz 4.
7:21:00 rozładowuje się zasilacz 3.
7:21:00 sale routingu pozbawione są zasilania elektrycznego.
7:21:03 ponowna ręczna próba uruchomienia agregatu wysokiego napięcia nr 1.
7:22:42 ponowna ręczna próba uruchomienia agregatu wysokiego napięcia nr 2.
7:30:00 lokalny sztab kryzysowy jest w pełni operacyjny.
7:50:00 centralny sztab kryzysowy w Roubaix jest w pełni operacyjny.
Między godziną 7:50 a 10:39 ponawiane są wielokrotnie próby manualnego uruchomienia agregatów pod nadzorem naszych ekspertów wyspecjalizowanych w inżynierii elektrycznej.
10:39:00 ESR przywraca zasilanie elektryczne.
10:58:00 routery odzyskują zasilanie.
11:00 trwają czynności mające na celu przywrócenie funkcjonowania serwerów, które tego wymagają.
14:00 przybycie pierwszego dodatkowego zespołu pomocniczego.
16:00 na miejsce docierają zespoły wsparcia z naszych obiektów we Frankfurcie i w Roubaix.
17:30 na miejsce dociera ciężarówka załadowana 38 tonami części zamiennych.
22:00 działa 97 % serwerów, 91 % odpowiada na ping.
Jaka jest przyczyna przerwy w dosyle prądu przez ESR?

Zasilanie energetyczne w całym obiekcie SBG zapewnia jedna linia elektryczna 20 MVA składającą się z 2 kabli 20 kV. Przerwa w dosyle prądu wiązała się z uszkodzeniem jednego z dwóch kabli, który został szybko naprawiony przez ESR. Przyczyny uszkodzenia kabla nie są na ten moment jeszcze ustalone. ESR prowadzi w tym zakresie stosowne badania.
Dlaczego uszkodzenie jednego kabla spowodowało przerwę w zasilaniu?

Obiekt w Strasburgu zasilany jest dwoma kablami dostarczającymi 20 MVA i podłączonymi do tego samego wyłącznika. Otwarcie wyłącznika spowodowało odcięcie dwóch linii.
Dlaczego nie uruchomiły się generatory wysokiego napięcia?

Centra danych SBG1 i SBG4 posiadają zasilanie rezerwowe w postaci dwóch agregatów wysokiego napięcia, 2 MVA każdy, które włączają się w przypadku awarii zasilania elektrycznego. Automatyczny przełącznik nie zadziałał prawidłowo i nie uruchomił agregatów.

Po zbadaniu tej kwestii odkryliśmy, że polecenie uruchomienia agregatów nie zostało wysłane przez automat sterujący przełącznikiem.

Producent automatu przeprowadził stosowną ekspertyzę, w wyniku której stwierdził, że automat został zablokowany, co wyjaśnia, dlaczego agregaty się nie uruchomiły. Prowadzimy dalsze prace mające na celu zbadanie przyczyn tej blokady.

Zespół interwencyjny producenta przywrócił prawidłowe działanie automatu. Nie znamy jeszcze w tym momencie przyczyn zaistniałego błędu. W oczekiwaniu na pełne wyjaśnienia wprowadziliśmy dyżury (24 godz./7 dni w tygodniu) pracownika oddelegowanego do ręcznego przełączenia zasilania na zasilanie rezerwowe na wypadek ponownego wystąpienia błędu w automacie.

W najbliższych dniach przeprowadzimy próby obciążeniowe w obiekcie, które pozwolą na sprawdzenie poprawnego funkcjonowania automatu.
Dlaczego próby uruchomienia agregatów wysokiego napięcia zakończyły się niepowodzeniem?

Centrum danych SBG2 jest wyposażone w zasilanie awaryjne w postaci 2 agregatów niskiego napięcia 1,4 MVA każdy. Jeden z nich pozostawał w trybie «konserwacja». W przypadku trybu «konserwacja», w momencie wystąpienia odcięcia zasilania, obydwa agregaty wysokiego napięcia SBG1 dostarczają energię elektryczną do SBG2, zastępując tym samym agregat niskiego napięcia pozostający w trybie «konserwacji».

W czwartek, 9 listopada 2017, kiedy nastąpiła przerwa w zasilaniu obiektu, automatyczny przełącznik zasilania rezerwowego nie zadziałał prawidłowo i nie wydał polecenia uruchomienia agregatów.

W tej sytuacji podjęliśmy próby ręcznego uruchomienia agregatów.

Dla zapewnienia zasilania elektrycznego centrów SBG1, SBG4 i SBG2 przy użyciu jednego z dwóch agregatów niskiego napięcia w trybie «konserwacja», jest absolutnie konieczne, aby funkcjonowały jednocześnie obydwa agregaty wysokiego napięcia, co umożliwia dostarczenie 4 MVA. Jako że 2 agregaty wysokiego napięcia nie zsynchronizowały się, rozłączyliśmy je, aby każdy z nich pracował oddzielnie. Jeden agregat dostarczający jedynie 2 MVA nie jest w stanie utrzymać zadanego obciążenia i wyłącza się. Podjęliśmy wielokrotne próby, stosując różne konfiguracje, niestety bez powodzenia.
W jakim czasie zostało przywrócone prawidłowe funkcjonowanie usług?

W celu jak najszybszego przywrócenia prawidłowego działania usług podjęte zostały środki nadzwyczajne.

Sprawozdanie ogólne:

W czwartek o godzinie 22:00 działało 97% serwerów (hardware) oraz 91% usług (software). W piątek funkcjonowało 99 % serwerów oraz 96,2 % usług.



Sprawozdanie szczegółowe:

Private Cloud :

Czwartek, 9 listopada 2017
23.00 78,59% działających vCenter.

Piątek, 10 listopada
05:00 100% działających vCenter.

Object Storage/Cloud Archive

Czwartek, 9 listopada 2017
13:35 100% operacyjności.

Public Cloud Storage :

Czwartek, 9 listopada 2017
13:35 PCS/PCA 100% operacyjności.

Public Cloud Instances/VPS*: (*regiony PCI: w przypadku PCI stosujemy inną nomenklaturę niż w przypadku centrów danych)
Czwartek, 9 listopada
11:30 API jest dostępne w regionach SBG1/SBG2/SBG3.
17:00 98% instancji jest online w regionie SBG3.
20:00 98% instancji jest online w regionie SBG1.
21:00 92% instancji jest online w regionie SBG2.

Piątek, 10 listopada
16:00 100% instancji jest online w regionie SBG1.
16:30 100% instancji jest online w regionie SBG2.

Sobota, 11 listopada
18:00 100% instancji jest online w regionie SBG3.

Serwery dedykowane:
Czwartek, 9 listopada
21:00 93,05% serwerów dedykowanych jest ponownie uruchomionych.

Piątek, 10 listopada
17:00 99,1% serwerów dedykowanych jest ponownie uruchomionych.

Jak przebiegało zarządzanie zaistniałą sytuacją?

O godzinie 7:50 powołany został sztab kryzysowy w Roubaix w celu koordynacji wszystkich działań zespołów. Octave Klaba, CEO i założyciel OVH, na bieżąco relacjonuje przebieg wydarzeń w mediach społecznościowych. Szczegółowe wyjaśnienia publikowane są również na stronie travaux.ovh.net.

W tym samym czasie francuskie zespoły wsparcia klienta organizują pracę z zespołami z Kanady w taki sposób, aby odpowiedzieć na jak największą liczbę zapytań klientów.

W Strasburgu zespoły obsługujące centra danych szybko otrzymują wsparcie zespołów technicznych z Frankfurtu i z Roubaix. Uruchomiony zostaje specjalny transport drogowy i kolejowy. Około godziny 17:30 na miejsce dociera ciężarówka załadowana 38 tonami części zamiennych pochodzących z centrum logistycznego OVH w Lille, które są niezbędne do prowadzenia prac w najbliższych godzinach. Kilka kolejnych ciężarówek wysłanych zostaje w następnych dniach, co możliwe jest dzięki wprowadzeniu dyżurów pracowników logistyki w Roubaix.

Zespoły pracują nieprzerwanie w trybie dobowych zmian, aby jak najszybciej przywrócić funkcjonowanie usług wszystkich Klientów. W celu przyspieszenia wymiany ekip pracujących na miejscu przez cały weekend i cały tydzień uruchomiony zostaje transport lotniczy między Lille a Strasburgiem.
Jaki plan działania został wdrożony po zaistniałych wydarzeniach?

Jak już wcześniej zostało wspomniane, natychmiast podjęliśmy kroki mające na celu zapobiec w przyszłości takim incydentom w Strasburgu (SBG), jak również w naszych pozostałych obiektach.

Plan działania przewiduje 2 fazy:

Faza krótkoterminowa

Poprosiliśmy o szczegółowy raport producenta automatu przełącznika zasilania awaryjnego.

Ponieważ przełączenie automatu nie zadziałało prawidłowo, wprowadziliśmy dyżur pracowniczy (24 godziny na dobę/7 dni w tygodniu), aby w przypadku potrzeby, przełączyć ręcznie zasilanie na zasilanie awaryjne. Dyżur ten jest środkiem zabezpieczającym obiekt do momentu, kiedy próby obciążeniowe potwierdzą prawidłowe funkcjonowanie automatu.

Jeśli chodzi o przełącznik zasilania awaryjnego, część odpowiedzialna za automatyczne przełączanie zostanie zastąpiona autorskim rozwiązaniem, które umożliwi pełną kontrolę nad funkcjonowaniem systemu oraz pozwoli nam na jego monitoring. Identyczny system wykorzystywany jest już w Gravelines.

Zwróciliśmy się również do ESR o szczegółowy raport dotyczący przyczyn awarii.

Rozpoczęliśmy ponadto sprawdzenie możliwości podłączenia drugiej linii energetycznej 20 MVA. Jednocześnie prowadzimy badania nad innym rozwiązaniem - wdrożeniem dwóch niezależnych wyłączników zasilania, po jednym dla każdego kabla, co stanowiłoby zabezpieczenie na wypadek ewentualnego uszkodzenia jednego z dwóch kabli.

Dodatkowo oddzielimy sieć elektryczną SBG2 od SBG1/SBG4 oraz przyszłe centrum SBG3 od SBG2 i SBG1/SBG4. W ten sposób każde centrum danych będzie dysponowało swoim własnym, niezależnym zasilaniem awaryjnym.

Prowadzony jest jednocześnie audyt zasilania energetycznego we wszystkich obiektach OVH.

Uwaga: obecnie, jeśli Klient zamawia serwer zlokalizowany w Strasburgu, pojawia się on automatycznie w Panelu klienta jako serwer zlokalizowany w SBG1, nawet jeśli jest zlokalizowany w SBG2 lub SBG4. Powodowane jest to błędem w wyświetlaniu informacji. Błąd ten zostanie jak najszybciej usunięty, aby oznaczenie lokalizacji serwera odpowiadało rzeczywistemu centrum danych, w którym się znajduje.

Faza długoterminowa

Technologia konstrukcji centrów danych oparta na kontenerach morskich nie będzie już stosowana przez OVH. W rzeczywistości została ona użyta tylko do konstrukcji SBG1 i SBG4 i nie sprawdziła się w dalszych planach rozwoju centrów danych OVH. Jesteśmy świadomi, że technologia ta nie sprostała wymaganiom obowiązującym w branży i normom w OVH. W związku z tym przystąpimy do demontażu kontenerów SBG1 i SBG4.

Jednocześnie przeprowadzimy migrację wszystkich usług naszych klientów z SBG1 i SBG4 do SBG2 i SBG3 oraz do innych centrów danych OVH.

Octave