Opinie o OVH

[Mion]

Nooo dziś zaliczyli NOKAUT niczym niedawno Joanna Jędrzejczyk

[Poziomecki]

http://tvn24bis.pl/ze-swiata,75/globalna-awaria-serwerow-ovh,788659.html

[Suspect]

Szczegóły dotyczące walki o przywrócenie zasilania

 

https://twitter.com/olesovhcom

[Poziomecki]

https://twitter.com/OVH_Status

tutaj też

[theqkash]

Ktoś dziś będzie miał bardzo zły dzień....

[Mion]

Panel klienta wstał, ale jest teraz strasznie zmulony. Pewnie "wszyscy" się właśnie zalogowali 

[theqkash]

Wszyscy piszą tickety o rekompensatę ;-)

[Mion]

Nadal nie wszystko działa np:

Cytuj

Wystąpił błąd podczas zlecania restartu (Your VPS area is under maintenance, please come back later)
Wystąpił błąd podczas otwierania usługi KVM

.

I nadal lipa

 

Edytowane 9 Listopada 2017 przez Mion

[Mion]

Nadal nie można zrestartować VPS z Windows

 

[Mruczek]

Godzinę temu, Mion napisał:

Nadal nie można zrestartować VPS z Windows

Ale co chcesz zrestartować? Przecież im całe hosty leżą w SBG.

Ostatnie konkretne dane jakie podali, to:

- 1025 serveurs dédiés
- 150 instances PCI
- 2700 VPS
- 250 hosts PCC

w statusie "down".

[oui]

http://status.ovh.com/vms/index_sbg2.html - kolorow

[Mion]

To już trochę długooooo, bo nie było jakieś klęski żywiołowej, która mogła by tak powalić infrastrukturę lub walnięcia meteorytu w DC, co by uzasadniało, iż nie mogą przez tyle godzin reaktywować swoich usług

[gb1]

@Mion przywrócenie tak dużej infrastruktury nie jest sprawą banalną, zapewne to jeszcze dłuższą chwilę będzie trwało, pomimo zapewne dobrej organizacji i dużych zasobów ludzkich biorących udział w przywracaniu.

 

Jednak czy to istotne czy zostanie przywrócone w dzień czy dwa ? Jestem pewien że bywalcy tego forum posiadają odpowiedni DRP (Disaster Recovery Plan) wcześniej testowany i wdrożony, co pozwala spać spokojnie i nie przejmować się zdarzeniem do przewidzenia u jednego z dostawców. 

 

Tego typu zdarzenia miały miejsce, mają miejsce i będą miały miejsce, z  tego powodu duzi gracze jak Facebook czy Google potrafią regularnie wyłączyć całe data center w celu testowania DRP. Dobrym przykładem jest także "chaos monkey" stosowany w Netflix, którego zadaniem jest celowe losowe i stałe "psucie" systemów aby testować procedury i zabezpieczenia w zakresie ciągłości działania.

Edytowane 9 Listopada 2017 przez gb1

[Mion]

4 minuty temu, gb1 napisał:

przywrócenie tak dużej infrastruktury nie jest sprawą banalną,

OVH to nie jest "serwer w piwnicy" na który spadły sanki januszka i wbiły się w płytę główną i trzeba czekać  aż kupią nową. Przynajmniej tak można było uważać - do dziś uważać.

 

7 minut temu, gb1 napisał:

wcześniej testowany i wdrożony, co pozwala spać spokojnie i nie przejmować się zdarzeniem do przewidzenia u jednego z dostawców. 

To samo można powiedzieć o OVH. Taki plan powinien mieć i reaktywacja nie powinna trwać tyle czasu.

 

5 minut temu, gb1 napisał:

Jednak czy to istotne czy zostanie przywrócone w dzień czy dwa ?

 

 

 

 

[gb1]

1 minutę temu, Mion napisał:

Przynajmniej tak można było uważać - do dziś uważać.

 

Sugeruję zacząć myśleć o DRP przed kolejnym zdarzeniem
 

2 minuty temu, Mion napisał:

Taki plan powinien mieć i reaktywacja nie powinna trwać tyle czasu.

 

"Nie powinno..., powinien mieć....", na koniec dnia i tak najważniejsze jest to czy nasze istotne systemy działają, a to zapewnić może tylko wcześniejsza analiza oraz DRP.

 

Uruchomiłeś DRP ? Jeśli tak to śpij spokojnie i przestań się przejmować.

 

[Mion]

14 minut temu, gb1 napisał:

Sugeruję zacząć myśleć o DRP przed kolejnym zdarzeniem

W teorii tak właśnie miałem, bo o ogólnej liczbie VPS (z Windows) dwa z nich można uznać za zapasowe, ale co z tego jak wszystkie były w DC, które właśnie leży "Strasbourg SBG1".

Więc po tej lekcji widzę, że muszę zmienić swoją politykę DRP 

Dobranoc

 

[Pawel_15]

Wyśmiejecie mnie za to co napiszę ale... tego typu awarie są bardzo uważnie obserwowane przez pewne siły które na szybko analizują zaistniałą sytuację i wyciągają odpowiednie wnioski.

Nie, nie sugeruje tutaj spisku Awarie mogą zdarzyć się każdemu, nawet OVH. Niemniej są na tym globie osoby i instytucje które już wiedzą jaki będzie skutek jak się to i owo wyłączy.

Czym innym jest wiedza na temat gdzie jakie strony się hostują a czym innym jest obserwacja jak są one faktycznie offline.

 

Nie hejtujcie proszę za mocno, nie próbuję wam wmówić że to wina mgły czy czegoś takiego. Po prostu popieprzyło się kilka czynników naraz i "nie działało pół internetu".

[gb1]

11 minut temu, Mion napisał:

Więc po tej lekcji widzę, że muszę zmienić swoją politykę DRP

 

Wnioski wyciągnięte na przyszłość to bardzo dobry początek drogi, sugerowałbym także dodać regularne testy DRP i analizę po testach oraz jeśli potrzeba (nie znam przypadku że nie ma potrzeby) modyfikację DRP. 

 

"W teorii nie ma różnicy pomiędzy teorią i praktyką. W praktyce - jest."

Edytowane 9 Listopada 2017 przez gb1

[Poziomecki]

[Mion]

haha  gigantyczny serwer dobre

Ale ten gigantyczny serwer nadal kuleje

Cytuj

Please note that an incident is currently affecting our services. Service is progressively being restored to affected sites, please see our dedicated task page for details of the incident http://status.ovh.com/?do=details&id=15162 and accept our sincere apologies for any inconvenience caused.

 

http://www.wirtualnemedia.pl/artykul/awaria-ovh-sparalizowala-internet-jedynie-ci-ktorzy-nie-ufaja-nigdy-do-konca-sa-odpowiednio-zabezpieczeni

 

 

Edytowane 10 Listopada 2017 przez Mion

[Mruczek]

Poniższy cytat z http://travaux.ovh.net/?do=details&id=28247 wyjaśnia wiele co zaszło wczoraj, no i jakie OVH ma plany w związku z tym.

 

Cytuj

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 20KVA 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

 

[Pawel_15]

Na rodzimy język można prosić?

[nnd.newbie]

59 minut temu, Pawel_15 napisał:

Na rodzimy język można prosić?

 

Jeden z dwóch kabli się uszkodził. Z tego co zrozumiałem poszło jakieś szuru-buru ( nie jestem dobry w elektryce) i odcięło zasilanie w obu. Powinny ruszyć generatory, ale NSM nie zadziałał i nie ruszyły. Są w kontakcie z producentem NSM i wyjaśniają co poszło nie tak. Ostatnie testy generatorów były w maju i działały bez zastrzeżeń. 

 

O 10 udało im się uruchomić generatory ręcznie, dostawca puścił prąd w jednym kablu i uruchomili serwery. Monitorują komu jeszcze co nie działa i technicy działają. Ściągnęli zasoby ludzkie i ciężarówkę części z innych centrów. Teraz pracuje ponad 50 techników i będą pracować tak długo jak trzeba, nawet całą noc.

 

Potem jest bicie w piersi i tłumaczenie czemu się to stało. SBG było jednym z ich pierwszych centrów i zastosowali kiepską architekturę, kiedy jeszcze nie wiedzieli jaka będzie skala ich działań.

 

W szczególności:

- nie zastosowali dwóch niezależnych 20KV źródeł zasilania, jak jest w ich innych centrach i co jest ich wewnętrznym standardem.

- zbudowali SBG2 na istniejącej infrastrukturze energetycznej SBG1 zamiast kompletnie niezależnej, co też jest zrobione w innych centrach i też jest ich wewnętrznym standardem (każde centrum z inną cyferką to niezależne od innych zasilanie, oczywiście poza SBG)

 

Potem w każdym nowym centrum stosowali już coraz lepsiejszą , nowocześniejszą i sprawdzoną architekturę - więc inne centra są niezagrożone. Obiecują że SBG też doprowadzą do takiej nowej architektury, a docelowo wszyscy klienci z SBG1/SBG4 (czyli stara kontenerowa architektura ) zostaną przeniesieni do SBG3 (nowa architektura towerowa, tip-top mucha nie siada). SBG1/SBG4 zostanie zburzone w cholerę.

 

 

That's the gist of it

Edytowane 10 Listopada 2017 przez nnd.newbie

[Mion]

8 minut temu, nnd.newbie napisał:

Powinny ruszyć generatory, ale NSM nie zadziałał i nie ruszyły.

Scenariusz niczym z "Misia" lub "Alternatywy 4 "  lat 80 

I pojawił się nowy komunikat:

 

[Poziomecki]

I routing im padł bo karty sieciowe były w trybie standby i przywrócili konfig z backupu i dopiero załapały.

 

Diagnoza sieciówek trwała około 40 minut.