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.
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.
https://lvlup.rok.ovh/t/zaplanowane-prace-techniczne-2019/9594
Dokładny przebieg zdarzeń znajduje się niżej
Serwer dedykowany przestaje odpowiadać
Zlecamy restart sprzętowy
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.
Serwer dedykowany już odpowiada na ping.
Szybkie sprawdzenie potwierdza że wszystkie VPSy na n90 są włączone i powinny działać poprawnie.
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:
Zauważyliśmy że po upgrade https://lvlup.rok.ovh/t/zmiany-techniczne-2019/9563/#69?u=systemz
wszyscy klienci VPS KVM nie mogą zmieniać płyt w wirtualnym napędzie VPS'a. Szukamy przyczyny i rozwiązania.
Zanim znajdziemy rozwiązanie w najnowszej wersji lub autorzy załatają błędy, wracamy do starszej wersji
https://lvlup.rok.ovh/t/zmiany-techniczne-2019/9563/#70?u=systemz
Problem z siecią na:
Pojawiły się silne utraty pakietów
Sytuacja zaczyna się stopniowo poprawiać
OVH tworzy publiczny ticket na temat tej awarii dotyczącej szafy rackowej G126B22:
http://travaux.ovh.com/?do=details&id=38379
Problem wygląda na rozwiązany 🥳
Obserwujemy problem z jednym dyskiem NVMe, sprawdzamy to bliżej, będzie to wymagało wyłączenia wszystkich VPS na tym węźle
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.
Poniżej cały przebieg zdarzeń
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.
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.
Okazuje się że wszystkie kopie usług zlokalizowanych na n78 są uszkodzone 😦 Przechodzimy do planu C - bezpośrednie przenoszenie wirtualnych dysków VPSów pomiędzy węzłami.
Pierwsza z przeniesionych usług działa poprawnie. Powoli rozpoczynamy migrację kolejnych usług tą metodą.
30% usług zostało przeniesionych
50% usług zostało przeniesionych
75% usług zostało przeniesionych
W trakcie przenoszenia ostatniej usługi, n78 przestał odpowiadać.
Otrzymujemy informację od OVH o rozpoczętej interwencji na węźle.
Interwencja zakończona, węzeł został podniesiony do życia poprzez łagodny reboot. Obsługa ponownie rozpoczyna przenoszenie ostatniej usługi.
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.
Poniżej cały przebieg zdarzeń
Rutynowa aktualizacja aplikacji która odpowiada za aktualizację innych aplikacji `` Została ona wprowadzona przy okazji ostatniego przenoszenia się między klastrami k8s: https://lvlup.rok.ovh/t/zmiany-techniczne-2019/9563/#146?u=systemz 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.
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ę.
Rozpoczynam naprawę, ogranicza się to do wykonania jakichś 4 komend które automatycznie stwierdzą czego brakuje i to dodadzą.
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.
Zweryfikowałem, wszystko działa już jak trzeba
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.
Błąd ludzki. Zignorowałem swoją własną dokumentację, jedną komendę wpisałem z pamięci zamiast popatrzeć jak wykonywałem to wcześniej
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
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ć.
Poniżej cały przebieg zdarzeń
Zaczynamy upgrade kubernetes z powodu wydania nowej łatki powiązanej z bezpieczeństwem.
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.
Serwer DHCP oraz dokonywanie reinstalacji z panelu klienta już działa
Udało nam się naprawić pozostałe usługi jednak pracujemy nadal aby zapewnić im większą niezawodność, działają trochę w trybie awaryjnym.
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.
Zmodyfikowany kod serwera DHCP gotowy
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.
https://lvlup.rok.ovh/t/zmiany-techniczne-2019/9563/#149?u=systemz
Rezerwacja miejsca, dodamy treść później.
Znów otrzymujemy informacje o banach, pracujemy nad tym aby skutecznie skomunikować się z zespołem FiveM i wyjaśnić to raz na zawsze.
EDIT: Nie otrzymujemy już informacji od naszych klientów o tym problemie.
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 ❤️ ) i został utworzony wątek na forum twórców tej modyfikacji
https://forum.fivem.net/t/banning-vps-hostings/826090
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.
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ć 😦
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
https://lvlup.rok.ovh/t/zmiany-techniczne-2019/9563/#174?u=systemz
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
