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

FS#15162 — SBG

Attached to Project— Network
Incident
Strasbourg
CLOSED
100%
We are experiencing an electrical outage on Strasbourg site.
We are investigating.
Date:  Monday, 20 November 2017, 15:57PM
Reason for closing:  Done
Comment by OVH - Thursday, 09 November 2017, 10:55AM

SBG: ERDF repared 1 line 20KV. the second is still down. All Gens are UP. 2 routing rooms coming UP. SBG2 will be UP in 15-20min (boot time). SBG1/SBG4: 1h-2h


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

Traffic is getting back up. About 30% of the IP are now UP and running.


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

Everything is back up electrically.
We are checking that everything is OK and we are identifying still impacted services/customers.


Comment by OVH - Thursday, 09 November 2017, 13:25PM

Hello,
Two pieces of information,

This morning we had 2 separate incidents that have nothing to do with each other. The first incident impacted our Strasbourg site (SBG) and the 2nd Roubaix (RBX). In SBG we have 3 datacentres in operation and 1 under construction. In RBX, we have 7 datacentres in operation.

SBG:
In SBG we had an electrical problem. Power has been restored and services are being restarted. Some customers are UP and others not yet. If your service is not UP yet, the recovery time is between 5 minutes and 3-4 hours. Our monitoring system allows us to know which customers are still impacted and we are working to fix it.

RBX:
We had a problem on the optical network that allows RBX to be connected with the interconnection points we have in Paris, Frankfurt, Amsterdam, London, Brussels. The origin of the problem is a software bug on the optical equipment, which caused the configuration to be lost and the connection to be cut from our site in RBX. We handed over the backup of the software configuration as soon as we diagnosed the source of the problem and the DC can be reached again. The incident on RBX is fixed. With the manufacturer, we are looking for the origin of the software bug and also looking to avoid this kind of critical incident.

We are in the process of retrieving the details to provide you with information on the SBG recovery time for all services/customers. Also, we will give all the technical details on the origin of these 2 incidents.

We are sincerely sorry. We have just experienced 2 simultaneous and independent events that impacted all RBX customers between 8:15 am abd 10:37 am and all SBG customers between 7:15 am and 11:15 am. We are still working on customers who are not UP yet in SBG.
Best, Octave


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

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 PLC. 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 empty.  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 - Saturday, 18 November 2017, 02:33AM

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, 15:51PM

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.