[HOST IS DOWN] Oktawave.pl

[nrm]

https://status.oktawave.com/

 

Siekło 28.03.2018 11:13 tango down

 

PING goto.pl.oktawave.com (195.149.198.21): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
^C
--- goto.pl.oktawave.com ping statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss

 

Host is back up after 12 minutes of downtime as of Wed Mar 28 2018 11:23:54

 

Oj, dawno nic się nie działo

[Artur Pajkert Hekko.pl]

Wiadomo, każdemu się może zdarzyć... 3majmy kciuki za kolegów, żeby im się szybko udało opanować sytuację.

 

[Robert]

Już jest online

[nrm]

Dodałem https://status.oktawave.com/ w pierwszym poście, może się w przyszłości przydać, aczkolwiek jestem w Okta w zasadzie od samego początku i na szczęście tych awarii nie ma za dużo.

[Marek607]

U mnie działało bez problemu chyba z rok czy dwa, a wczoraj wieczorem po problemie z dyskami  trzeba było odzyskiwać z kopii bo nawet support nie mógł podnieść instancji.

Dzisiaj od rana rzucało na sieci, ale widze że już chyba w miarę ok.

Ogólnie prawo murphiego - jak działało to jak skała, jak się zepsuło to wszystko na raz.

 

Ważne że chyba ogarneli sytuacje i jest ok.

[.ojciecRydzyk]

Cytuj

 

Dzień dobry.

Dziś w godzinach porannych obserwowaliśmy problemy związane z infrastrukturą sieciową, co utrudniało dostęp do naszej chmury 😤. W tej chwili udało się nam ustabilizować sytuację i przywrócić pełną dostępność 😀.

W razie pytań zachęcamy do kontaktu.

 

Facebook

Edytowane 28 Marca 2018 przez .ojciecRydzyk

[oui]

Jest i wyjaśnienie: 

Cytuj

Informujemy, że awaria sieci w dniu 28.03.2018 obejmująca swoim zasięgiem wszystkie subregiony Oktawave została usunięta. Podkreślamy, że awaria dotyczyła tylko warstwy sieciowej, a więc dostępu z zewnątrz do naszej infrastruktury i nie miała wpływu na warstwę obliczeniową oraz danych.

 

Przebieg awarii

 

Pierwsze symptomy niestabilnego działania sieci zostały zarejestrowane 27.03.2018 o godzinie 17:15. Ich efektem była przebudowa drzewa STP (STP topology changed, https://pl.wikipedia.org/wiki/Protokół_STP) i w efekcie 22 sekundowa przerwa w działaniu sieci publicznej. W kolejnych godzinach liczba operacji przebudowy STP systematycznie ulegała zwiększeniu, szczytową wartość osiągając w godzinach porannych 28.03.2018. Powodowało to kilkudziesięciosekundowe przerwy średnio co około 10 minut. W rezultacie można było zaobserwować zawieszanie komunikacji z OCI, zawieszanie terminali SSH etc.

W miarę zwiększania częstotliwości przebudowy STP równolegle zwiększała się liczba procesów renegocjacji protokołu MLAG (https://en.wikipedia.org/wiki/MC-LAG) pomiędzy przełącznikami agregacyjnymi pracującymi jako para w klastrze HA. Przez te urządzenia przechodzi cały ruch Oktawave i są to urządzenia Mellanox SN2700 wyposażone w interfejsy sieciowe 100 Gbps. Sukcesywnie powtarzana renegocjacja MLAG także generowała przerwy w działaniu sieci.

Po analizie oraz wykonaniu wszystkich czynności możliwych do przeprowadzenie zgodnie z dokumentacją urządzeń, także wymianie potencjalnie wadliwych połączeń pomiędzy przełącznikami i stwierdzeniu braku możliwości diagnozy i usunięcia przyczyny we własnym zakresie, został wezwany suport producenta. Inżynierowie Mellanox w ciągu kilkunastu minut od zgłoszenia podjęli próbę przywrócenia stabilności działania urządzeń, jednak ostatecznie dopiero około godziny 15:00 przyczyna została zidentyfikowana.

 

Przyczyna

 

Inżynierowie Mellanox w efekcie analizy stwierdzili, że liczba pakietów typu LACP (https://en.wikipedia.org/wiki/Linkaggregation#LinkAggregationControlProtocol) na wszystkich interfejsach urządzenia przekracza dozwolony przez producenta limit CPU (procesora), w efekcie czego następuje odrzucenie niektórych pakietów, a to w konsekwencji prowadzi do destabilizacji linków LACP, braku komunikacji MLAG i przebudowę drzewa STP. Naprawa przeprowadzona przez suport producenta polegała na zwiększeniu zidentyfikowanego limitu. Niestety, jest to operacja nieopisana w dokumentacji i niemożliwa do przeprowadzenia samodzielnie. Producent ustawia limit fabrycznie i nie umożliwia jego zmiany, niestety w przypadku Oktawave był on zbyt niski, a inżynierowie Oktawave nie mieli żadnej możliwości korekty tych ustawień.

 

Stan

 

Obecnie cała sieć działa prawidłowo, niemniej system jest pod ciągłą obserwacją zarówno inżynierów Oktawave, jak i inżynierów Mellanox. Jednocześnie producent pracuje nad ustaleniem przyczyny zbyt niskiego ustawienia limitów pakietu LACP i ewentualnym zaproponowaniem innych zmian mających zapobiec podobnym zdarzeniom w przyszłości.

Poprzednie zdarzenia