Awarie i przerwy w działaniu 2021

Awarie i przerwy

W tym wątku będziemy publikować informacje o awariach oraz o zaplanowanych przerwach w działaniu usług lvlup.pro.

Opisując te zdarzenia publicznie na forum nasi klienci będą mieć szybszy dostęp do informacji że coś może być nie tak z ich usługami lub będą mogli się przygotować na wcześniej zaplanowane przerwy.
Oprócz obsługi w tym wątku mogą pisać także nasze roboty które wykryją nieprawidłowości w działaniu naszych usług.

Warto zobaczyć

Wątek w którym piszemy na bieżąco o wprowadzonych zmianach w naszych usługach

Poprzedni wątek z awariami z roku 2020

7 polubień

:white_check_mark: VPSy na n179.lvlup.pro

Naprawione.
Poniżej pełen przebieg zdarzeń

03.01.2021

16:28

Węzeł n179.lvlup.pro przestaje odpowiadać.
Wszystkie VPSy na nim są niedostępne.

16:57

Sprawdzenie serwera zlecone do techników w centrum danych po nieudanym sprzętowym reboocie.
Czekamy na reakcję OVH.

17:01

Podobno jest coś nie tak ze złączem elektrycznym/zasilaczem (?)

17:16

Ze względu na aktywny w tym czasie KVM, obsługa OVH wyłączyła monitoring i zignorowała problem z serwerem. Po wyłączeniu KVM ponownie próbujemy hard reboota aby podjęli próbę jeszcze raz.

17:32

Ponowne wysłanie informacji do techników po nieudanym reboocie sprzętowym.

18:11

Po hard reboocie wykonanym przez obsługę OVH wszystko wydaje się działać już poprawnie.
Wszystkie aktywne VPSy zostały automatycznie włączone po starcie węzła.

04.01.2021

17:25

Wszystkie zgłoszenia dotyczące awarii zostały odpisane oraz dodaliśmy +24h do ważności usług które zostały dotknięte przez awarię.

8 polubień

Ten wątek jest zamknięty aby odpowiedzi mogła dodawać tylko obsługa.
Mimo zamknięcia ten wątek jest aktualizowany przez obsługę.

:white_check_mark: Sieć VPSów na n85.lvlup.pro

09.01.2021

10:39

Packet loss przekraczający 30%

11:00

Sprawdzamy to, wygląda na kwestię sieci w OVH, nadal szukamy przyczyn po swojej stronie

12:06

Wysłaliśmy ticket do OVH ze zebranymi MTR.
Póki co nie znaleźliśmy problemu po stronie lvlup.pro.
Podejrzewamy uszkodzony port switcha dostępowego lub uszkodzoną kartę sieciową serwera dedykowanego. W tej samej szafie mamy też n160.lvlup.pro ale z nim nie ma problemu.

12:10

Kopiuj-wklej weszło za mocno, problem jest z serwerem n85 a nie z n179.
Poprawiłem tytuł posta.

12:57

Przyspieszyliśmy ticketa przez infolinię OVH

13:22

Wprowadzamy węzeł w tryb rescue więc wszystkie VPSy zostają wyłączone

13:28

Sieć to nie jedyna rzecz z którą jest problem. Rescue też nie działa ¯\_(ツ)_/¯

15:22

Sytuacja z packet loss uległa znacznej poprawie.
Teraz widzimy 33% loss co ~10 min zamiast praktycznie w trybie ciągłym.
Niestety problem wygląda nadal na nierozwiązany a OVH nie odpisało nam już dalej na ticket mimo podania szczegółów około 13:35.

22:51

Obserwowaliśmy sytuację, wygląda na to, że problem rozwiązał się coś około 16:30.

11 polubień

:white_check_mark: VPSy na n88.lvlup.pro

Usługi są już dostępne, pełen przebieg zdarzenia poniżej.

14.01.2021

12:06

n88.lvlup.pro przestał odpowiadać bez wyraźnej przyczyny w logach

12:19

Zlecilismy hard reboot

12:29

Hard reboot nie zadziałał.
Podejrzewamy problem ze sprzętem,.
OVH zleciło technikom sprawdzenie tego.

14:11

Ping do n88 wrócił, wygląda na to, że obsługa OVH testuje sprzęt.
Trochę to zajęło więc podejrzewamy wymianę płyty głównej.
VPSy na n88 nie są jeszcze sprawne ale wygląda na to, że już niedługo będą.

15:14

Otrzymaliśmy wiadomość o wymianie płyty głównej przez obsługę OVH.
VPSy na n88 powróciły do życia.

15.01.2021

17:13

Po wymianie sprzętu obserwowaliśmy węzeł, jednak problem wygląda na całkowicie rozwiązany.
Wszystkie zgłoszenia dotyczące awarii zostały odpisane.
Dodaliśmy +24h do ważności usług które zostały dotknięte awarią.

5 polubień

:spiral_calendar: :white_check_mark: UPbot na Discord

Przerwa techniczna została już zakończona, poniżej plan i przebieg zdarzeń

15.01.2021

Będziemy migrować upbota.
Spowoduje to przerwę w jego działaniu na około 15 min.
Przez ten czas nie będzie można dołączyć do naszego serwera Discord.

22:00 - 23:00

Zaplanowane okienko serwisowe

22:54

UPbot wyłączony

23:06

UPbot ponownie dostępny na discordzie.
Zostało jeszcze kilka rzeczy do zrobienia.

23:12

UPbot jest całkowicie sprawny po migracji.

4 polubienia

:spiral_calendar: :white_check_mark: Panel klienta i piaskownica

Migracja panelu klienta zakończona, poniżej pełen opis

17.01.2021

~13:00

Planujemy migrację panelu klienta między centrami danych.

Zanim do tego przejdziemy, będziemy dokonywać pewnych zmian i symulacji na piaskownicy.
sandbox.lvlup.pro i api.sandbox.lvlup.pro może być niedostępne i resetowane wiele razy w ciągu dnia.

Przed samą finalną migracją produkcyjnego panelu klienta i strony www.lvlup.pro oraz api.lvlup.pro poinformujemy z wyprzedzeniem, a zaplanowana przerwa w działaniu nie powinna przekroczyć 15 min, celujemy w 5 min niedostępności.

~23:00

Praktycznie wszystko jest już przygotowane do migracji.
Kwestia przełączenia kilku rzeczy i gotowe.

23:32

Przesuwamy migrację na jutro ze względu na problem z systemem whitelistowania adresów IP w Paysafecard. Ich panel dla sprzedawcy już ponad godzinę bez skutku dodaje adres do dozwolonych.

18.01.2021

~08:00 - 11:00

Orientacyjny czas zaczęcia migracji

10:04

Kwestia z PSC nadal się nie rozwiązała.
Czekamy na odpowiedź od PSC.

11:26

Przekładamy migrację, obecnie trudno powiedzieć na kiedy.

15:10

Sprawa PSC jest już rozwiązana.
Czekamy na bardziej dogodną porę do migracji.

22:45

Migrację zaczniemy prawdopodobnie około 22:55

22:59

Zaczęliśmy migrację

23:07

Główna część migracji zakończona.
Najprawdopodobniej nie straciliśmy ani jednego requesta, nie było żadnego downtime.
Jedyna niedogodność to utrata zalogowanych sesji.

Reszta migracji przebiegnie już w tle, bez zaburzeń dla klientów.

19.01.2021

00:12

Po przejrzeniu ruchu do panelu i braku błędów po migracji, przywróciliśmy cykliczne wykonywanie zadań (cron) które zajmuje się u nas np. realizacją zamówień.

01:28

Migracja zakończona.
Poza wylogowaniem zalogowanych sesji nie stwierdziliśmy żadnych problemów dla klientów.

7 polubień

:spiral_calendar: :white_check_mark: Panel klienta

20.01.2021

~00:05

Przeprowadzimy krótką ~5 min przerwę która pozwoli nam wprowadzić zmianę zmniejszającą czas przerw przy przyszłych standardowych aktualizacjach panelu do zera.

00:16

Aktualizacja zakończona pomyślnie, czas niedostępności wynosił około 2-3 min

5 polubień

:white_check_mark: VPSy na n183.lvlup.pro

Usługi są już dostępne, pełen przebieg zdarzenia poniżej.

23.01.2021

21:17

n183.lvlup.pro przestał odpowiadać

21:26

Sprawdzamy to.

21:30

Nie widzimy wyraźnej przyczyny w logach.
Obstawiamy problem sprzętowy

21:31

Zleciliśmy hard reboot

21:38

Hard reboot się nie powiódł.
Jeszcze bardziej obstawiamy problemy ze sprzętem.
Czekamy na reakcję techników OVH w centrum danych.

21:46

Mamy ping

21:48

Serwer wydaje się działać ponownie, weryfikujemy.

21:50

Według techników serwer był wyłączony.
Najwidoczniej sam się wyłączył lub ktoś się potknął o kabel :thinking:

21:52

Wszystko wygląda już w porządku :slight_smile:
VPSy na n183 wyglądają sprawnie.

5 polubień

:white_check_mark: :snail: :turtle: Wolne serwisy lvlup.pro

Problem rozwiązany.
Poniżej pełny przebieg zdarzeń.

25.01.2021

Obserwujemy wolniejsze działanie naszych stron.
Wliczając w to stronę, panel klienta, forum i inne.

15:09

Widzimy, że Cloudflare kieruje nasz ruch przez Japonię czy Stany Zjednoczone zamiast przez Europę.
To tłumaczy wolniejsze ładowanie naszych stron.

15:21

Zgłosiliśmy ten problem do Cloudflare

15:44

Otrzymaliśmy odpowiedź od Cloudflare.

Informują nas, że pakiety nie zawsze idą najbliższą drogą.
Czasami może być tak, że np. przeciążone cache zostaną zastąpione innymi, dalszymi geograficznie.
Zostaliśmy zachęceni zmianą planu na najwyższy, 100 razy droższy od aktualnego aby móc wymusić region który obsługuje nasze strony. Póki co z tego nie skorzystamy.

Będziemy obserwować sytuację, jeśli będzie trwać zbyt długo to go wyłączymy lub poszukamy innego dostawcy CDN.

16:24

Problem wydaje się już nie występować lub być mniej uciążliwy.
Obserwujemy sytuację.

26.01.2021

12:46

Wygląda ok. Problem nie występuje od momentu wczorajszego wpisu (16:24).

7 polubień

:spiral_calendar: :white_check_mark: Panel klienta

Wykonaliśmy aktualizację i zwiększenie zasobów dla panelu.
Poniżej pełny przebieg

26.01.2020

12:39

Restartujemy panel klienta aby powiększyć VM na której przebywa.
Przerwa nie powinna zająć dłużej niż 5 min

12:44

Panel klienta już działa na większej VM.

5 polubień

:white_check_mark: VPSy na n84.lvlup.pro

03.02.2021

04:04

Węzeł n84 przestaje być dostępny

04:11

Sprawdzamy logi.
Prawdopodobna przyczyna to błąd kernela lub CPU, zlecamy hard reboot

04:13

Węzeł włączył się i działa poprawnie.
VPSy wróciły do działania po nagłym restarcie.

5 polubień

:white_check_mark: VPSy na n84.lvlup.pro

VPSy na n84.lvlup.pro są już ponownie dostępne.
Poniżej dokładne informacje:

04.02.2021

04:34

Proxmox przestaje poprawnie działać

06:39

Po wstępnej diagnozie zlecamy soft reboot

06:45

Po nieudanym soft reboot zlecamy hard reboot

07:17

Rozpoczynamy diagnozę w trybie rescue

07:37

Kończymy diagnozę w rescue, zlecamy reboot

08:12

Zaczynamy zgrywać kopię wszystkich dysków VPS na tym węźle, potrwa to około 40 min

09:18

Mamy ponad 75% postępu robienia kopii

09:54

Po skopiowaniu wszystkich VPSów, podejmujemy ostatnią próbę startu systemu

09:58

Po naprawie systemu, węzeł wydaje się działać poprawnie.
Weryfikujemy.

10:22

Sprawdziliśmy, VPSy na n84 działają już poprawnie :white_check_mark:

06.02.2021

17:16

Odpisaliśmy na zgłoszenia dotyczące awarii i dodatkowo potwierdziliśmy że usługi dotknięte awarią działają poprawnie. Dodaliśmy +24h do ważności wszystkich usług znajdujących się na n84.

5 polubień

:hammer_and_wrench: Logowanie kluczem U2F na forum

Badamy problemy z logowaniem 2FA i kluczem sprzętowym

17.02.2021

17:20

Otrzymaliśmy sygnał od jednego użytkownika forum, gdzie niemożliwe było zalogowanie się z użyciem klucza jako 2FA.

17:27

Planujemy zaktualizować forum do nowszej wersji gdzie są dostępne lepsze logi tego zdarzenia podczas mniejszej ilości użytkowników online

18:22

Aktualizujemy testowo naszą piaskownicę forum

19:03

Piaskownica wygląda ok, czekamy na mniej osób online aby zaktualizować forum produkcyjne

21:09

Wyłączamy i aktualizujemy forum

21:18

Forum jest zaktualizowane

21:30

Problem nie ustąpił

22:06

Zgłosiliśmy problem autorom Discourse

4 polubienia

:white_check_mark: :fire: :fire_engine: VPSy na n146.lvlup.pro

Usługi które były obecne na n146 zostały pomyślnie odtworzone z najnowszej kopii na innym sprzęcie.
Poniżej pełen przebieg zdarzeń.

10.03.2021

00:36

Węzeł n146.lvlup.pro staje się niedostępny

01:36

Mimo wykrycia przez monitoring OVH problemu z pingiem, nie została wykonana żadna reakcja ze strony obsługi OVH, dziwne, zazwyczaj nie trwa to dłużej niż 30 min a wymiana sprzętu zwykle trwa może z godzinę.

03:53

OVH wstawiło informację o tym, że w serwerowni SBG2 wybuch pożar:

We are currently facing a major incident in our DataCenter of Strasbourg with a fire declared in the building SBG2.
Firefighters were immediately on the scene but could not control the fire in SBG2.
The whole site has been isolated, which impacts all our services on SBG1, SBG2, SBG3 and SBG4.
If your production is in Strasbourg, we recommend to activate your Disaster Recovery Plan.
All our teams are fully mobilized along with the firefighters.
We will keep you updated as more information becomes available.
OVH Tasks  

Akurat w tym budynku serwerowni mamy tylko ten jeden serwer.
Czekamy na przywrócenie usługi do działania.

W przypadku gdyby serwer spłonął, sprawdziliśmy jakimi kopiami dysponujemy.
Najnowsze kopie dla n146 są z zakresu czasu 08:01 - 08:12 wtorek 09.03.2020.
Nie zdążyły się więc wykonać kopie zaraz przed pożarem ale mamy te z dnia przed.

Nie mamy wolnych zasobów na innych serwerach dedykowanych z oferty FR.
Nie jest też możliwy zakup nowych.
Ze względu na nietypową sytuację prosimy o kontakt osób przez ticket którym zależy na szybszym przywróceniu usługi, jesteśmy w stanie przywrócić kopię na UpRyze lub Upryze Turbo jednak wymagana jest w tym przypadku zmiana adresu IP VPSa.

05:24

Istnieje możliwość, że całe SBG2 zostało zniszczone.

Czekamy na więcej oficjalnych informacji od OVH.

06:32

Biorąc pod uwagę wszystkie informacje z jakimi udało nam się zapoznać, nie liczymy na to że jesteśmy w stanie odzyskać działanie n146 przynajmniej przez 48h.
Postanowiliśmy spisać ten sprzęt na straty i odzyskać usługi z kopii zapasowych.

Prosimy o utworzenie zgłoszenia:
https://www.lvlup.pro/pl/panel/pomoc/

a przydzielimy inny adres IP i przywrócimy najnowszą kopię usługi w regionie PL z 9 marca ze względu na brak miejsca w FR.
Jeszcze dziś roześlemy mailing do wszystkich osób dotkniętych awarią.

11:24

To pewne, cała serwerownia OVH SBG2 spłonęła więc n146 przestało istnieć :fire: :derelict_house:

Obsłużyliśmy awarię 10% usług z n146

13:05

30% usług zostało przywróconych

14:51

40% usług zostało przywróconych

15:29

60% usług zostało przywróconych

15:42

70% usług zostało przywróconych

16:05

90% usług zostało przywróconych

16:10

100% usług zostało przywróconych. Po krótkiej przerwie dla obsługi przejdziemy do odpisywania na wszelkie zgłoszenia dotyczące awarii.

18:04

Wysłaliśmy mailing do klientów dotkniętych awarią z dodatkowymi informacjami.

Szanowny kliencie,
Dziś w godzinach 0:36 - 16:10 Twoja usługa nie była dostępna. Niedostępność była spowodowana pożarem w centrum danych w którym znajdował się węzeł n146 na którym znajdował się Twój VPS. Obecnie usługa jest już dostępna, ale nie włączaliśmy jej ze względu na zachowanie spójności danych. Przywróciliśmy najnowszą dostępną kopię (09.03.2021) na innym węźle.

Ze względu na zmianę regionu na którym znajduje się usługa byliśmy zmuszeni do zmiany adresu IP. Z tego powodu może być konieczna ponowna konfiguracja sieci.
Nowy adres :

Pełen przebieg awarii jest aktualizowany na forum
https://forum.lvlup.pro/t/awarie-i-przerwy-w-dzialaniu-2021/17326/16

11.03.2021

17:00

Awaria była jedną z tych która wpada pod kategorię “siły wyższej”, jednak aby zrekompensować niedostępność VPS dodaliśmy do usług dotkniętych awarią +24 h ważności.

14 polubień

:white_check_mark: VPSy na n180.lvlup.pro

Testowo zaktualizowaliśmy ostatnio kilka węzłów.
Wygląda na to, że ten upgrade wymusi na nas restarty sprzętu.
Obecny kernel nie współpracuje z qemu, musimy wykonać reboot aby załadować nowszy kernel.

11:30

Obserwujemy problemy z VPSami które zostały niedawno wyłączone i włączone.

12:40

Wysyłamy mailing do klientów na n180 na temat restartu/hibernacji ich VPS

12:43

Zaczynamy proces hibernacji tych VPS których się da

12:46

Udała się hibernacja około połowy VPSów, czyli te które nie były ostatnio restartowane i mają dłuższy uptime np. 100 dni.
Reszta zostanie wyłączona i włączona, są to VPSy które od niedawnego restartu VM mają problemy z Proxmox.

12:53

Restart węzła zakończony, czekamy na włączanie i wznawianie VPS

12:55

Wszystkie VPSy zostały wznowione lub wystartowane ponownie.
Obserwujemy czy Proxmox działa już w porządku

13:10

Problem wygląda na rozwiązany.

8 polubień

Usługi na n175 i n180 działają już poprawnie.
Poniżej przebieg zdarzeń

:white_check_mark: VPSy na n180.lvlup.pro

12:11

Węzeł traci kontakt z siecią

12:30

Sprawdzamy to.
Wygląda na to, że przyczyną niedostępności sieci jest atak.
OVH nałożyło filtr na n180.

13:30

Filtr z n180 został zdjęty.
Sieć wróciła do normy.
Usługi powinny działać już poprawnie, weryfikujemy.

13:40

Sprawdziliśmy, usługi działają już poprawnie

:white_check_mark: VPSy na n175.lvlup.pro

12:29

Węzeł traci kontakt z siecią

12:30

Sprawdzamy to

12:47

Sieć została przywrócona, monitorujemy sytuację

12:51

Otrzymaliśmy informację od obsługi OVH, że problem został rozwiązany przez odłączenie i podłączenie kabla sieciowego.

13:00

Możemy potwierdzić w logach, że to faktycznie miało miejsce i pomogło.

5 polubień

:white_check_mark: Panel klienta

28.04.2021

17:28

Duża aktualizacja

została niepoprawnie wypuszczona i może nie działać cały panel klienta.
Pracujemy nad rozwiązaniem, przewidywany czas rozwiązania to 15-30 min

17:53

Wypuściliśmy łatkę, wszystko powinno być już ok.

Instrukcje jeśli panel nadal nie działa

Dla niektórych użytkowników panel nadal może nie działać gdyż w pamięci podręcznej przeglądarki może być zainstalowana starsza wersja.
Jeśli panel nadal nie działa, należy użyć kombinacji klawiszy Ctrl + F5 aby wymusić pobranie nowej poprawionej wersji.

Nowa wersja powinna pobrać się automatycznie po upływie maksymalnie 24h lub kilku odświeżeniach strony, w razie problemów prosimy o kontakt mailowy lub kontakt na publicznym kanale discord.

5 polubień

:white_check_mark: Panel klienta - (re)instalacja systemu na VPS

Reinstalacja systemu w panelu klienta działa już poprawnie.
Poniżej przebieg zdarzeń:

04.05.2021

01:22

Zmieniliśmy kilka rzeczy przy panelu klienta które wpływają pozytywnie na niezawodność API

06.05.2021

10:00

Wygląda na to, że nasze zmiany z 4 maja polepszyły niezawodność ale spowodowały częściowy brak komunikacji panelu klienta z węzłami czego nie zauważyliśmy w tamtym momencie.

Planujemy rozwiązać to dziś do około 17:00 zmieniając całkowicie sposób komunikacji panelu z serwerami dedykowanymi.
Mamy już to gotowe mniej więcej w połowie gdyż i tak to planowaliśmy zrobić w maju.

17:56

Właśnie kończymy aktualizację wszystkich węzłów.
Po wypuszczeniu jeszcze dziś nowej wersji panelu klienta, problem powinien być rozwiązany.
Nowy planowany czas to 19:00

18:17

Wszystkie węzły zostały pomyślnie zaktualizowane.
Przeprowadzamy ostatnie testy przed wypuszczeniem nowej wersji panelu klienta.

18:44

Nowa wersja panelu klienta jest w trakcie procesu wypuszczania, wystarczy już tylko poczekać na koniec pracy naszych automatów.

19:59

Łatka nie pomogła, odbieranie akcji na węzłach działa, nadawanie ich przez panel już nie.
Sprawdzamy to.

21:46

Druga łatka nie pomogła, dalej diagnozujemy.

22:14

Problem rozwiązany.
Okazało się, że poprzednia poprawka działała ale na produkcyjnym serwerze była wrzucona starsza wersja bez niej.

5 polubień