Awarie 2019

Co opisujemy w tym wątku?

W tym wątku będziemy publikować informacje związane z awariami aby być transparentni względem naszych klientów co robimy w przypadkach gdy wystąpią awarie.

Jak?

Informacje w postach są aktualizowane na bieżąco poprzez ich edycję gdy sytuacja ulegnie zmianie.
Jeśli awaria jest już zażegnana, taka informacja pojawi się na samej górze posta.

Inne przydatne wątki cykliczne

5lajków

Naprawione!

Dokładny przebieg zdarzeń znajduje się niżej

n90.lvlup.pro

2019.04.05

09:29

Serwer dedykowany przestaje odpowiadać

09:40

Zlecamy restart sprzętowy

09:48

Restart sprzętowy zwraca błąd.
Wygląda to na kwestie sprzętową a nie np. zawieszenie się serwera.
Czekamy na reakcję techników OVH.

10:22

Serwer dedykowany już odpowiada na ping.

10:25

Szybkie sprawdzenie potwierdza że wszystkie VPSy na n90 są włączone i powinny działać poprawnie.

10:27

Z raportu OVH wynika że soft reboot wystarczył aby przywrócić serwer do działania.
To ciekawe, w takim razie podczas awarii musiałaby wystąpić awaria systemu do twardego restartu :thonking:

8lajków

Naprawione!

Poniżej cały przebieg zdarzeń

n102.lvlup.pro

2019.04.05

14:00

Serwer przestał odpowiadać.

14:15

Został wysłany sygnał do twardego restartu

14:17

Serwer odpowiada ponownie na ping.

7lajków

n*.lvlup.pro

17.04.2019

09:55

Zauważyliśmy że po upgrade

wszyscy klienci VPS KVM nie mogą zmieniać płyt w wirtualnym napędzie VPS’a.
Szukamy przyczyny i rozwiązania.

11:06

Zanim znajdziemy rozwiązanie w najnowszej wersji lub autorzy załatają błędy, wracamy do starszej wersji

3lajki

Naprawione!

Niektóre węzły KVM

Problem z siecią na:

  • n93
  • n109
  • n110
  • n111
  • n112
  • n113

19:54

Pojawiły się silne utraty pakietów

20:30

Sytuacja zaczyna się stopniowo poprawiać

21:06

OVH tworzy publiczny ticket na temat tej awarii dotyczącej szafy rackowej G126B22:
http://travaux.ovh.com/?do=details&id=38379

21:26

Problem wygląda na rozwiązany :partying_face:

9lajków

Naprawione!

n78.lvlup.pro

07.06.2019 12:37 - 14:05

Panel proxmox nie reagował na polecenia, nie można było też wyłączyć / włączyć serwera z naszego panelu klienta.

Włączone już wcześniej VPSy działały tak jak trzeba.

6lajków

Naprawione!

n128.lvlup.pro

10.06.2019

16:26

Obserwujemy problem z jednym dyskiem NVMe, sprawdzamy to bliżej, będzie to wymagało wyłączenia wszystkich VPS na tym węźle

16:38

Po restarcie, dodatkowy dysk NVMe znów zaczął być widoczny, VPSy ruszyły jak trzeba.
Na pierwszy rzut oka wszystko wygląda ok.
Jako następny krok sprawdzimy w ticketach czy ucierpiały dane klientów.

7lajków

Naprawione!

Poniżej cały przebieg zdarzeń

n78.lvlup.pro

11.06.2019

00:05

Obserwujemy dalsze, “ciche” problemy z Proxmox na tym węźle.

Nasz system backpów zgłasza błędy więc gdy tylko obsługa będzie na nogach, postaramy się jak najszybciej ewakuować VPSy na inne węzły aby uniknąć szkód dla naszych klientów.

15:21

Próbujemy przenieść jedną z usług standardową metodą, która niestety zawodzi. Przechodzimy do planu B - sprawdzamy czy kopie zapasowe w naszym archiwum są sprawne.

15:32

Okazuje się że wszystkie kopie usług zlokalizowanych na n78 są uszkodzone :frowning: Przechodzimy do planu C - bezpośrednie przenoszenie wirtualnych dysków VPSów pomiędzy węzłami.

15:50

Pierwsza z przeniesionych usług działa poprawnie. Powoli rozpoczynamy migrację kolejnych usług tą metodą.

17:05

30% usług zostało przeniesionych

17:25

50% usług zostało przeniesionych

17:50

75% usług zostało przeniesionych

18:27

W trakcie przenoszenia ostatniej usługi, n78 przestał odpowiadać.

18:30

Otrzymujemy informację od OVH o rozpoczętej interwencji na węźle.

18:51

Interwencja zakończona, węzeł został podniesiony do życia poprzez łagodny reboot. Obsługa ponownie rozpoczyna przenoszenie ostatniej usługi.

18:59

100% usług na n78 zostało ewakuowanych na inne węzły

Po przerwie zerkniemy czy interwencja na węźle przywróciła go do pełnej sprawności czy też nadal występuje jakiś problem.

7lajków

Naprawione!

Poniżej cały przebieg zdarzeń

Klaster z usługami wewnętrznymi

01.10.2019

~15:20

Rutynowa aktualizacja aplikacji która odpowiada za aktualizację innych aplikacji <mem z Xzibit>
Została ona wprowadzona przy okazji ostatniego przenoszenia się między klastrami k8s:


W skrócie, Argo CD automatycznie synchronizuje zawartość repo git do rzeczywistej infrastruktury czyli generalnie podejście w stylu “infrastruktura jako kod”.

Pomyliłem się podczas wykonywania komendy która powinna łagodnie zamienić tą aplikację na nowszą wersję, bez żadnych przerw dla innych usług poza samą sobą na powiedzmy 20sek.

Druga komenda którą wykonałem usuwała tą aplikację, niestety usunęła się tylko po części.
Ta działająca część przestała widzieć repozytorium więc appka stwierdziła że skoro nie ma nic a w klastrze jest wszystko to nowszym stanem jest “nic” więc taki zaczęła aplikować czyli generalnie usuwać wszystko co nadzorowała z naszych usług wewnętrznych np.

  • zabbix
  • grafana na stats.lvlup.pro
  • status.lvlup.pro
  • panel klienta v3
  • panel klienta v4
  • www.lvlup.pro
  • upbot

To tylko lista kilku z nich, w sumie było ich około 40

Jedyne czego nie nadzorowała to replikowana baza danych MySQL.
Wcześniej przy projektowaniu tego wszystkiego stwierdziłem że takie rzeczy jednak wolę nadzorować ręcznie.
Spodziewałem się że to pewnie kwestia czasu zamiast wszystko postawić w kilka minut to wszystko zniszczy tak szybko. Jak widać nie pomyliłem się.

15:24

Rozpoczynam naprawę, ogranicza się to do wykonania jakichś 4 komend które automatycznie stwierdzą czego brakuje i to dodadzą.

15:42

W zasadzie wszystkie usługi już się zainstalowały i działają poza systemem instalacji/reinstalacji systemu w panelu klienta.

Od strony OVH nie zadziałała prawidłowo jedna z usług, wymagało to mojej ręcznej interwencji w DNS oraz konfigurację wszystkich węzłów, całe szczęście to też mam zautomatyzowane, kwestia powiedzmy dwóch komend.

16:13

Zweryfikowałem, wszystko działa już jak trzeba

Wpływ na klientów

Niewielki

VPSy nadal powinny działać poprawnie, ostatnio zwiększyłem na wszelki wypadek ilość czasu przez jaki działają wpisy DHCP więc niedostępność panelu v4 nie powinna wpłynąć na dostępność samych usług.

Nie działały transparentne statystyki, główny panel klienta v2 nadał działał i nadal można było np. utworzyć u nas zgłoszenie w przypadku problemów technicznych czy dokonać płatności.
Forum jest całkowicie niezależne i również działało prawidłowo przez ten czas.

Co poszło nie tak?

Błąd ludzki.
Zignorowałem swoją własną dokumentację, jedną komendę wpisałem z pamięci zamiast popatrzeć jak wykonywałem to wcześniej

Jakie zabezpieczenia zadziałały?

Trzymanie wszystkich możliwych konfiguracji w repozytorium się odpłaciło, postawienie wszystkiego od nowa (ok 40 usług) na czystych hostach to kwestia kilku minut.
Dobrze było mieć regularne zewnętrzne kopie zapasowe jednak całe szczęście się nie przydały tym razem.
Trzymanie kluczowych elementów takich jak instancje bazy danych czy wirtualne dyski z danymi poza zasięgiem automatów

Jak temu zaradzimy w przyszłości?

Cenna lekcja dla mnie, więcej czytać, mniej pisać w terminalu nawet jeśli dotyczy to prawdopodobnie banalnej sprawy.
Aplikacja do trzymania porządku i synchronizacji jest bronią obusieczną, trzeba na to bardziej uważać.

12lajków

Naprawione!

Poniżej cały przebieg zdarzeń

Klaster z usługami wewnętrznymi

05.10.2019

14:58

Zaczynamy upgrade kubernetes z powodu wydania nowej łatki powiązanej z bezpieczeństwem.

15:27

Część usług mimo zakończenia aktualizacji klastra nadal nie działa.
Głównym problemem jest niedostępność panelu v4 który ma wpływ na reinstalację oraz serwer DHCP który przydziela adresy IP dla VPSów.
W niektórych okolicznościach może to powodować brak dostępu do sieci na niektórych VPSach.
W momencie awarii dzierżawy DHCP trwały max 1h więc awaria trwająca dłużej niż tyle może mieć zły wpływ na klientów.

~16:28

Serwer DHCP oraz dokonywanie reinstalacji z panelu klienta już działa

16:45

Udało nam się naprawić pozostałe usługi jednak pracujemy nadal aby zapewnić im większą niezawodność, działają trochę w trybie awaryjnym.

~17:20

Wszystkie usługi działają w 100%, dodatkowo dokonaliśmy kilku zmian i modernizacji aby zmniejszyć awaryjność na przyszłość.
Udało się usprawnić proces przyszłych aktualizacji.
Zgłosiliśmy też problem do OVH i czekamy na rozwiązanie, gdyż klaster po aktualizacji ma problemy z DNS co prawdopodobnie miało spory wpływ na bardzo powolne uruchamianie usług po aktualizacji.

17:50

Zmodyfikowany kod serwera DHCP gotowy

17:55

Na wszystkich węzłach jest już włączony serwer DHCP w nowej wersji.
Przydziela on dzierżawy na 24h aby ewentualne podobne awarie tego typu w przyszłości miały mniejszy wpływ na klientów.

Przemyślenia i wnioski

  • nie ważne jak mała wydaje się aktualizacja, prawa Murphy’iego są nieubłagane
  • aktualizacja usług zarządzanych przez zewnętrzne firmy lepiej robić w godzinach roboczych
  • potrzebujemy większej niezależności serwera DHCP od panelu klienta, utworzyłem już na ten temat wewnętrzny ticket aby to wykonać.
4lajki

Rezerwacja miejsca, dodamy treść później.

1lajk

W toku

Znów otrzymujemy informacje o banach, pracujemy nad tym aby skutecznie skomunikować się z zespołem FiveM i wyjaśnić to raz na zawsze.

Naprawione

EDIT: Nie otrzymujemy już informacji od naszych klientów o tym problemie.

FiveM - licencje

Nie jest to sprawa dotycząca bezpośrednio lvlup, problem wynika z firmy zewnętrznej jednak jako że sporo klientów używa tego oprogramowania to sądzę że warto o tym wspomnieć.

Otrzymaliśmy dziś wiele sygnałów od naszych klientów o problemach z dołączeniem na ich serwery oparte o modyfikację FiveM postawione na serwerach VPS w lvlup.pro. Problem wydaje się dotyczyć tylko części serwerów, nie wszystkich.

Podczas rozmów na naszym serwerze Discord powstała inicjatywa społeczności (dzięki @DBanaszewski :heart: ) i został utworzony wątek na forum twórców tej modyfikacji

Wynika z niego że twórcy są w trakcie odblokowywania serwerów.

Jeśli z jakiegoś powodu logowanie do serwera nadal nie działa, prosimy o kontakt z twórcami FiveM poprzez email podany w komunikacie błędu który pojawia się przy dołączaniu do serwera.

10lajków

Naprawione

Wpłaty Dotpay

Po stronie Dotpay występuje problem techniczny.
Wpłaty są przyjmowane i akceptowane poprawnie, jednak nie są do nas wysyłane informacje o płatnościach.
Z tego powodu nasz panel klienta nie dodaje wpłat automatycznie bo nie dostaje od Dotpay sygnału aby to zrobić :frowning:

Do czasu rozwiązania tego problemu przez Dotpay, dodajemy wpłaty ręcznie.
Prosimy o informację w zgłoszeniu a postaramy się jak najszybciej dodać środki.

EDIT
Wygląda na to że zaistniały jakieś zmiany w Clouflare które miały wpływ na dostarczalność wiadomości od Dotpay w starszym systemie z którego korzystaliśmy.
Użyliśmy nowszego systemu Dotpay i wszystko już działa automatycznie tak jak wcześniej, plus uzyskaliśmy nowszą wersję serwisu do wpłat dla naszych klientów

6lajków

Właśnie otrzymałem pieniążki na portfelu, zajęło to około 3 godziny. Aa bo wy ręcznie dodajecie…

O awariach w 2020 będziemy informować w tym wątku