Skocz do zawartości
  • Cześć!

    Witaj na forum RootNode - aby pisać u nas musisz się zarejestrować, a następnie zalogować. Posty pisane z kont niezarejestrowanych nie są widoczne publicznie.

[HOST IS DOWN] Oktawave.pl


nrm
 Udostępnij

Rekomendowane odpowiedzi

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 ;)

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

Cytuj

 

Dzień dobry.

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

W razie pytań zachęcamy do kontaktu.

 

Facebook

Edytowane przez .ojciecRydzyk
Odnośnik do komentarza
Udostępnij na innych stronach

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

 

 

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
 Udostępnij

  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.