Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


12.05.2022

Odszyfrowanie historii

Z inicjatywy prezesa IPN, dr. Karola Nawrockiego, powstało Biuro Nowych Technologii. Jego...
01.04.2022

Program partnerski

NGAGEFirma NFON, ogólnoeuropejski dostawca komunikacji głosowej w chmurze, ogłosił...
01.04.2022

SI w TFI PZU

Na platformie do inwestowania inPZU działa już nowa metoda identyfikacji tożsamości...
01.04.2022

Kooperacja w chmurze

To oparta na stworzonej przez NetApp technologii ONTAP i w pełni zarządzana przez...
01.04.2022

Nowe laptopy od Dynabook

Dynabook wprowadza do swojej oferty dwa laptopy z procesorami Intel Core 12. generacji,...
01.04.2022

Ryzen do stacji roboczych

AMD przedstawił nową gamę procesorów Ryzen Threadripper PRO 5000 serii WX.
31.03.2022

Serwery dla MŚP

Firma Lenovo wprowadziła nowe rozwiązania w zakresie infrastruktury IT Future Ready,...
31.03.2022

Innowacyjny kontroler SSD

Microchip zaprezentował nowe kontrolery SSD, które umożliwią obsługę napędów o pojemności...
31.03.2022

Wydajny jak Brother

Brother dodał do swojej oferty trzy nowe, atramentowe urządzenia wielofunkcyjne, które...

Awaria w OVHcloud a plany ciągłości działania

Data publikacji: 04-01-2022 Autor: Krzysztof Kęsicki

Zarządzanie ciągłością działania to złożony proces identyfikacji potencjalnych zagrożeń i ich wpływu na przedsiębiorstwo oraz zdolność do prawidłowej, efektywnej reakcji, która zabezpieczy zasoby, reputację i markę, a także zminimalizuje straty.

 

Tyle mówi teoria. Pytanie brzmi, jak wygląda praktyka, czyli jak są realizowane plany ciągłości działania (PCD) w razie faktycznego zagrożenia? Spróbujemy w poniższym artykule przeanalizować jedną z ostatnich awarii w firmie OVH. Francuski gigant wśród dostawców usług chmurowych, hostingu współdzielonego oraz dedykowanych serwerów zaliczył kolejny poważny incydent, który odbił się głośnym echem na całym świecie i dotknął wielu użytkowników.

 

> Opis awarii


OVH dostarcza swoje usługi w 140 krajach. Z jego oferty korzystają zarówno pojedynczy użytkownicy, małe i średnie firmy, jak i wielcy gracze biznesowi i potężne korporacje. Dlatego też efekt incydentu jest do przewidzenia – o awarii w OVH będą wiedzieli wszyscy. Tak było m.in. w marcu bieżącego roku, gdy na skutek pożaru serwerowni w Strasburgu firma zaliczyła potężną awarię.


Niedawno znowu w OVH zrobiło się gorąco. Nie aż tak jak podczas ostatniego pożaru i nie na taką skalę, ale rzesza użytkowników wylała na forach swoje niezadowolenie i frustrację z powodu zaistnienia tej sytuacji. Skupimy się na zdarzeniu, które miało miejsce 13 października tego roku. Zaczęło się od tego, że po godzinie 9:00 CEST użytkownicy masowo zaczęli zgłaszać bardzo dużo problemów z działaniem serwisów internetowych oraz dostępnością swoich maszyn.


Serwis Downdetector wygenerował tego dnia raport, który pokazał skalę całego problemu – tysiące zgłoszeń w godzinach przedpołudniowych (rys. 1). Zwykle liczba zgłoszeń według danych historycznych serwisu nie przekracza kilku do kilkunastu. Mieliśmy więc do czynienia z bardzo poważną awarią.


Co się dokładnie wydarzyło tego dnia? Według jednego z techników przed awarią wzrosła liczba ataków DDoS. Dostawca internetowy zdecydował się temu przeciwdziałać i zaplanował modyfikację infrastruktury sieciowej. Jak dowiadujemy się z oficjalnego komunikatu firmy OVH, 13 października odbyły się planowane prace serwisowe w strukturze sieci (źródło: status-ovhcloud.com).


Komunikat był krótki i raczej nie niósł ze sobą żadnych obaw czy informacji o podwyższonym ryzyku planowanej operacji: „Zaplanowano na 13 października 2021 prace serwisowe na routerach naszej sieci, aby polepszyć routing. Nie jest przewidywany żaden wpływ na nasze usługi, urządzenia będą odizolowane przed zmianą”. Niestety jak w większości takich prac z niskim ryzykiem problemem okazał się ludzki błąd. Spowodował on, że zwykła rekonfiguracja sprzętu przyniosła nieoczekiwane problemy z funkcjonowaniem całego szkieletu sieci.


> Przyczyny


Według opisu incydentu na stronie dostawcy prace rozpoczęły się w planowanym oknie serwisowym tuż po godzinie 9:00 CET. Przewidziana zmiana dotyczyła rekonfiguracji urządzeń sieciowych w centrum przetwarzania danych w Vint Hill w USA. Prace zaczęły się zgodnie z ustalonym grafikiem. Na początek zablokowano zewnętrzny protokół routingu (ang. Border Gateway Protocol, BGP), rozpoczęto serwis urządzeń i wprowadzono zmiany w konfiguracji. Podczas zmiany mapy routingu wystąpił problem. Według OVH jeden z rekonfigurowanych routerów nie przyjął ostatniej cyfry w nowym wpisie. Spowodowało to, że protokół routingu został zmieniony z zewnętrznego BGPv4 na protokół wewnętrzny OSPF (ang. Open Shortest Path First). Tablica routingu OSPF zapełniła się, doprowadzając do przeciążenia RAM-u i procesora urządzenia. Miało to wpływ na całkowite zablokowanie routingu IPv4. Routing IPv6 cały czas był dostępny. Zespół prowadzący prace zauważył błąd i od razu przystąpił do eskalacji problemu, czyli powiadomił zespół kryzysowy o zdarzeniu.


Taki jest oficjalny opis na stronie dostawcy, z którego wynika, że cały incydent był związany z błędnym działaniem sprzętu, który nie przyjął konfiguracji. Z drugiej strony mamy informacje z mediów społecznościowych, na których sam prezes i założyciel OVHcloud, Octave Klaba, napisał, że problem był spowodowany błędem ludzkim.


Faktem jest, że do awarii doszło podczas planowanych prac, czyli podczas ingerencji ludzkiej w strukturę i konfigurację systemu. Gdyby doszło do niej podczas normalnej pracy ośrodka, to pewnie nikt nie miałby zbyt wielkich zastrzeżeń – kolejna awaria sprzętu, która co jakiś czas się zdarza. Tutaj jednak mieliśmy do czynienia ze zdarzeniem podczas prac planowanych, w które najprawdopodobniej wkradł się błąd ludzki. A to już całkowicie zmienia optykę postrzegania tego przypadku przez odbiorców usług.


> Sposób reakcji


Prześledźmy teraz pokrótce, jak zareagowała firma i jakie kroki zostały podjęte. Zaraz po wykryciu błędu nastąpiła eskalacja do sztabu kryzysowego, który po dosłownie kilku minutach uruchomił procedurę zarządzania kryzysowego zgodnie z wdrożonymi w strukturze organizacji procedurami zarządzania ciągłością działania.


Każda zmiana w infrastrukturze krytycznej musi przed wdrożeniem na produkcję mieć dokładny opis kroków, które będą wykonywane. Trzeba oszacować ryzyko dla danych prac. Dodatkowo należy uzasadnić potrzebę zmian i szczegółowo opisać procedurę powrotu – tzw. rollback. Bez tych elementów żadna zmiana nie może być zatwierdzona i zaimplementowana w środowisku produkcyjnym. Pierwszą rzeczą, jaką spróbowano wykonać również w tym przypadku, było zastosowanie procedury rollback. Niestety z tego, co czytamy w komunikacie, procedura nie zadziałała. Zdecydowano więc, aby zupełnie odizolować urządzenie poprzez całkowite jego wyłączenie. Do tej operacji był potrzebny ktoś na miejscu. Po kilku minutach do telekonferencji sztabu kryzysowego został dołączony przedstawiciel zespołu data center. Po kilkunastu minutach technik z zespołu DC rozpoczął już prace na miejscu. Należy dodać, że w USA była to 3:00 rano. Pierwotnie rozważano odłączenie okablowania światłowodowego, aby odizolować felerne urządzenie od sieci i spowodować przywrócenie serwisów. Po rozeznaniu w sytuacji (kolejne kilkanaście minut) zdecydowano finalnie o wyłączeniu zasilania routera. Możliwe, że technik na miejscu stwierdził, że rozpinanie większej ilości okablowania zajmie więcej czasu i będzie bardziej skomplikowane, a ponadto mogą się pojawić błędy przy ponownym wpinaniu poszczególnych połączeń. O godzinie 10:18 CET wadliwy router został wyłączony. Po chwili pierwszy z niedziałających serwisów został przywrócony. W ciągu kolejnych 10 minut do działania wróciły wszystkie pozostałe usługi. Tuż przed 11:00 CET stwierdzono, że kryzys został zażegnany z technicznego punktu widzenia. Pokrywa się to z faktycznym wykresem liczby zgłoszeń od użytkowników, która w tym okresie zdecydowania zmalała.

 

 

[...]

 

Autor jest specjalistą ds. utrzymania infrastruktury data center. Zajmuje się problematyką budowy, utrzymania i zarządzania centrami przetwarzania danych oraz koordynowaniem zmian dotyczących krytycznej infrastruktury IT.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"