Skocz do zawartości
nrm

[HOST IS DOWN] Oktawave.pl

Polecane posty

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

Udostępnij ten post


Link to postu
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.

Udostępnij ten post


Link to postu
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

Edytowano przez .ojciecRydzyk

Udostępnij ten post


Link to postu
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

 

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dołącz do rozmowy

Możesz pisać i zarejestrować się później. Jeśli masz konto,Zaloguj się teraz, aby publikować na swoim koncie.

Gość
Odpowiedz...

×   Wklejony jako tekst z formatowaniem.   Wklej jako zwykły tekst

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.


  • Kto przegląda   0 użytkowników

    Brak zalogowanych użytkowników przeglądających tę stronę.

×
×
  • Utwórz nowe...

Ważne informacje

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