SystemZ | 2022-01-13 16:03:53 UTC | #1
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.
Wątek w którym piszemy na bieżąco o wprowadzonych zmianach w naszych usługach
https://forum.lvlup.pro/t/dziennik-zmian-lvlup-pro-2021/17327
Poprzedni wątek z awariami z roku 2020
https://forum.lvlup.pro/t/awarie-2020/13151
https://forum.lvlup.pro/t/awarie-i-przerwy-w-dzialaniu-2022/20366
SystemZ | 2021-01-04 16:27:10 UTC | #2
Naprawione.
Poniżej pełen przebieg zdarzeń
Węzeł n179.lvlup.pro przestaje odpowiadać.
Wszystkie VPSy na nim są niedostępne.
Sprawdzenie serwera zlecone do techników w centrum danych po nieudanym sprzętowym reboocie.
Czekamy na reakcję OVH.
Podobno jest coś nie tak ze złączem elektrycznym/zasilaczem (?)
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.
Ponowne wysłanie informacji do techników po nieudanym reboocie sprzętowym.
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.
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ę.
SystemZ | 2021-01-03 17:16:05 UTC | #3
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ę.
SystemZ | 2021-01-03 16:10:53 UTC | #4
SystemZ | 2021-01-09 21:52:08 UTC | #5
Packet loss przekraczający 30%
Sprawdzamy to, wygląda na kwestię sieci w OVH, nadal szukamy przyczyn po swojej stronie
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.
Kopiuj-wklej weszło za mocno, problem jest z serwerem n85 a nie z n179.
Poprawiłem tytuł posta.
Przyspieszyliśmy ticketa przez infolinię OVH
Wprowadzamy węzeł w tryb rescue więc wszystkie VPSy zostają wyłączone
Sieć to nie jedyna rzecz z którą jest problem. Rescue też nie działa ¯\_(ツ)_/¯
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.
Obserwowaliśmy sytuację, wygląda na to, że problem rozwiązał się coś około 16:30.
SystemZ | 2021-01-15 16:13:10 UTC | #6
Usługi są już dostępne, pełen przebieg zdarzenia poniżej.
n88.lvlup.pro przestał odpowiadać bez wyraźnej przyczyny w logach
Zlecilismy hard reboot
Hard reboot nie zadziałał.
Podejrzewamy problem ze sprzętem,.
OVH zleciło technikom sprawdzenie tego.
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ą.
Otrzymaliśmy wiadomość o wymianie płyty głównej przez obsługę OVH.
VPSy na n88 powróciły do życia.
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ą.
SystemZ | 2021-01-15 22:16:50 UTC | #7
Przerwa techniczna została już zakończona, poniżej plan i przebieg zdarzeń
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.
Zaplanowane okienko serwisowe
UPbot wyłączony
UPbot ponownie dostępny na discordzie.
Zostało jeszcze kilka rzeczy do zrobienia.
UPbot jest całkowicie sprawny po migracji.
SystemZ | 2021-01-19 00:30:39 UTC | #8
Migracja panelu klienta zakończona, poniżej pełen opis
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.
Praktycznie wszystko jest już przygotowane do migracji.
Kwestia przełączenia kilku rzeczy i gotowe.
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.
Orientacyjny czas zaczęcia migracji
Kwestia z PSC nadal się nie rozwiązała.
Czekamy na odpowiedź od PSC.
Przekładamy migrację, obecnie trudno powiedzieć na kiedy.
Sprawa PSC jest już rozwiązana.
Czekamy na bardziej dogodną porę do migracji.
Migrację zaczniemy prawdopodobnie około 22:55
Zaczęliśmy migrację
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.
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ń.
Migracja zakończona.
Poza wylogowaniem zalogowanych sesji nie stwierdziliśmy żadnych problemów dla klientów.
SystemZ | 2021-01-19 23:18:02 UTC | #9
Przeprowadzimy krótką ~5 min przerwę która pozwoli nam wprowadzić zmianę zmniejszającą czas przerw przy przyszłych standardowych aktualizacjach panelu do zera.
Aktualizacja zakończona pomyślnie, czas niedostępności wynosił około 2-3 min
SystemZ | 2021-01-23 20:55:45 UTC | #10
Usługi są już dostępne, pełen przebieg zdarzenia poniżej.
n183.lvlup.pro przestał odpowiadać
Sprawdzamy to.
Nie widzimy wyraźnej przyczyny w logach.
Obstawiamy problem sprzętowy
Zleciliśmy hard reboot
Hard reboot się nie powiódł.
Jeszcze bardziej obstawiamy problemy ze sprzętem.
Czekamy na reakcję techników OVH w centrum danych.
Mamy ping
Serwer wydaje się działać ponownie, weryfikujemy.
Według techników serwer był wyłączony.
Najwidoczniej sam się wyłączył ~~lub ktoś się potknął o kabel~~ :thinking:
Wszystko wygląda już w porządku :slight_smile:
VPSy na n183 wyglądają sprawnie.
SystemZ | 2021-01-26 11:47:56 UTC | #11
Problem rozwiązany.
Poniżej pełny przebieg zdarzeń.
Obserwujemy wolniejsze działanie naszych stron.
Wliczając w to stronę, panel klienta, forum i inne.
Widzimy, że Cloudflare kieruje nasz ruch przez Japonię czy Stany Zjednoczone zamiast przez Europę.
To tłumaczy wolniejsze ładowanie naszych stron.
Zgłosiliśmy ten problem do Cloudflare
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.
Problem wydaje się już nie występować lub być mniej uciążliwy.
Obserwujemy sytuację.
Wygląda ok. Problem nie występuje od momentu wczorajszego wpisu (16:24).
SystemZ | 2021-01-26 11:45:37 UTC | #12
Wykonaliśmy aktualizację i zwiększenie zasobów dla panelu.
Poniżej pełny przebieg
Restartujemy panel klienta aby powiększyć VM na której przebywa.
Przerwa nie powinna zająć dłużej niż 5 min
Panel klienta już działa na większej VM.
SystemZ | 2021-02-03 03:18:41 UTC | #13
Węzeł n84 przestaje być dostępny
Sprawdzamy logi.
Prawdopodobna przyczyna to błąd kernela lub CPU, zlecamy hard reboot
Węzeł włączył się i działa poprawnie.
VPSy wróciły do działania po nagłym restarcie.
SystemZ | 2021-02-06 16:26:19 UTC | #14
VPSy na n84.lvlup.pro są już ponownie dostępne.
Poniżej dokładne informacje:
Proxmox przestaje poprawnie działać
Po wstępnej diagnozie zlecamy soft reboot
Po nieudanym soft reboot zlecamy hard reboot
Rozpoczynamy diagnozę w trybie rescue
Kończymy diagnozę w rescue, zlecamy reboot
Zaczynamy zgrywać kopię wszystkich dysków VPS na tym węźle, potrwa to około 40 min
Mamy ponad 75% postępu robienia kopii
Po skopiowaniu wszystkich VPSów, podejmujemy ostatnią próbę startu systemu
Po naprawie systemu, węzeł wydaje się działać poprawnie.
Weryfikujemy.
Sprawdziliśmy, VPSy na n84 działają już poprawnie :whitecheckmark:
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.
SystemZ | 2021-02-17 21:07:10 UTC | #15
Badamy problemy z logowaniem 2FA i kluczem sprzętowym
Otrzymaliśmy sygnał od jednego użytkownika forum, gdzie niemożliwe było zalogowanie się z użyciem klucza jako 2FA.
Planujemy zaktualizować forum do nowszej wersji gdzie są dostępne lepsze logi tego zdarzenia podczas mniejszej ilości użytkowników online
https://github.com/discourse/discourse/commit/c031434b8653dc1a67e8da3712c0866cfde62cb6
Aktualizujemy testowo naszą piaskownicę forum
Piaskownica wygląda ok, czekamy na mniej osób online aby zaktualizować forum produkcyjne
Wyłączamy i aktualizujemy forum
Forum jest zaktualizowane
Problem nie ustąpił
Zgłosiliśmy problem autorom Discourse
https://meta.discourse.org/t/unknown-cose-algorithm-encountered-alg-257/180104
SystemZ | 2021-03-24 15:00:20 UTC | #16
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ń.
Węzeł n146.lvlup.pro staje się niedostępny
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ę.
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.
http://travaux.ovh.net/?do=details&id=49471
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.
Istnieje możliwość, że całe SBG2 zostało zniszczone.
https://twitter.com/olesovhcom/status/1369504527544705025
Czekamy na więcej oficjalnych informacji od OVH.
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ą.
To pewne, cała serwerownia OVH SBG2 spłonęła więc n146 przestało istnieć :fire: :derelict_house:
https://twitter.com/olesovhcom/status/1369504527544705025?refsrc=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1369504527544705025%7Ctwgr%5E%7Ctwcon%5Es1c10&ref_url=https%3A%2F%2Fpublish.twitter.com%2F%3Fquery%3Dhttps3A2F2Ftwitter.com2Folesovhcom2Fstatus2F1369504527544705025widget%3DTweet
Obsłużyliśmy awarię 10% usług z n146
30% usług zostało przywróconych
40% usług zostało przywróconych
60% usług zostało przywróconych
70% usług zostało przywróconych
90% usług zostało przywróconych
100% usług zostało przywróconych. Po krótkiej przerwie dla obsługi przejdziemy do odpisywania na wszelkie zgłoszenia dotyczące awarii.
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
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.
SystemZ | 2021-03-31 11:11:03 UTC | #17
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.
Obserwujemy problemy z VPSami które zostały niedawno wyłączone i włączone.
Wysyłamy mailing do klientów na n180 na temat restartu/hibernacji ich VPS
Zaczynamy proces hibernacji tych VPS których się da
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.
Restart węzła zakończony, czekamy na włączanie i wznawianie VPS
Wszystkie VPSy zostały wznowione lub wystartowane ponownie.
Obserwujemy czy Proxmox działa już w porządku
Problem wygląda na rozwiązany.
SystemZ | 2021-04-15 11:41:44 UTC | #18
Usługi na n175 i n180 działają już poprawnie.
Poniżej przebieg zdarzeń
Węzeł traci kontakt z siecią
Sprawdzamy to.
Wygląda na to, że przyczyną niedostępności sieci jest atak.
OVH nałożyło filtr na n180.
Filtr z n180 został zdjęty.
Sieć wróciła do normy.
Usługi powinny działać już poprawnie, weryfikujemy.
Sprawdziliśmy, usługi działają już poprawnie
Węzeł traci kontakt z siecią
Sprawdzamy to
Sieć została przywrócona, monitorujemy sytuację
Otrzymaliśmy informację od obsługi OVH, że problem został rozwiązany przez odłączenie i podłączenie kabla sieciowego.
Możemy potwierdzić w logach, że to faktycznie miało miejsce i pomogło.
SystemZ | 2021-04-28 16:08:17 UTC | #19
Duża aktualizacja
https://forum.lvlup.pro/t/dziennik-zmian-lvlup-pro-2021/17327/32?u=systemz
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
Wypuściliśmy łatkę, wszystko powinno być już ok.
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.
SystemZ | 2021-05-06 20:15:46 UTC | #20
Reinstalacja systemu w panelu klienta działa już poprawnie.
Poniżej przebieg zdarzeń:
Zmieniliśmy kilka rzeczy przy panelu klienta które wpływają pozytywnie na niezawodność API
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.
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
Wszystkie węzły zostały pomyślnie zaktualizowane.
Przeprowadzamy ostatnie testy przed wypuszczeniem nowej wersji panelu klienta.
Nowa wersja panelu klienta jest w trakcie procesu wypuszczania, wystarczy już tylko poczekać na koniec pracy naszych automatów.
Łatka nie pomogła, odbieranie akcji na węzłach działa, nadawanie ich przez panel już nie.
Sprawdzamy to.
Druga łatka nie pomogła, dalej diagnozujemy.
Problem rozwiązany.
Okazało się, że poprzednia poprawka działała ale na produkcyjnym serwerze była wrzucona starsza wersja bez niej.
SystemZ | 2021-06-07 14:04:15 UTC | #21
VPSy na n177 działają już poprawnie.
Poniżej pełen przebieg zdarzeń
Część VPS przestała działać poprawnie.
Sam sprzęt i system na pierwszy rzut oka działa w porządku.
Sprawdzamy n177.
Sytuacja nie wygląda na pilną.
Sprawdzamy n177 jeszcze raz.
Wygląda na to, że jednak sytuacja jest pilna.
Niekompatybilności wersji powodują praktycznie brak działania Proxmox a co za tym idzie interakcji z VPS jeśli np. zostały wyłączone.
Aktualizujemy i rozpoczynamy restart serwera.
Wysyłamy mail do klientów
Wszystkie VPSy zostały uruchomione ponownie po łagodnym restarcie sprzętu.
Po szybkiej weryfikacji usługi działają poprawnie
Planowana obsługa zgłoszeń związanych z awarią
Każdy klient na n177 bez interakcji z nami otrzyma +24h do ważności usługi w zamian za niedogodności
Wszystkie zgłoszenia dotyczące awarii zostały odpisane. Klienci otrzymali +3 dni ważności dla usług dotkniętych awarią.
Aylin | 2021-09-14 23:57:42 UTC | #22
Poniżej przebieg prac konserwacyjnych.
Zaplanowanie prac technicznych na 15.09.2021, pomiędzy 0:30 a 13:00.
Spowodują one niedostępność panelu klienta, API v2 i API v4 przez około 15-30 minut w podanym zakresie czasu. Nie przewidujemy aby niedostępność potrwała dłużej niż 1 godzina.
Obsługa przygotowuje się do rozpoczęcia prac technicznych.
Rozpoczęcie konserwacji.
Prace konserwacyjne zostały zakończone. Panel klienta, API v2 i API v4 wracają do życia.
Obsługa potwierdza że wszystko działa poprawnie, przerwa techniczna jest zakończona sukcesem :slight_smile:
Aylin | 2021-10-13 20:57:32 UTC | #23
Poniżej lista węzłów, zaznaczony checkbox oznacza że prace na węźle zostały zakończone.
Zaplanowanie prac technicznych na 13.10.2021, pomiędzy 22:00 a 23:30.
Spowoduje to niedostępność wszystkich usług z oferty Turbo w podanym zakresie czasu. Prace obejmą aktualizację panelu Proxmox oraz restart węzłów.
Wszyscy klienci których usług dotyczą prace otrzymają informację drogą mailową.
Wysłanie przypomnienia o pracach technicznych drogą mailową.
Rozpoczynamy zaplanowane prace techniczne
Prace techniczne zostały zakończone, wszystkie węzły działają poprawnie :slight_smile:
Aylin | 2021-10-13 12:04:51 UTC | #24
- awaria sieci OVHPoniżej przebieg zdarzenia.
Wszystkie węzły przestają kontaktować się ze światem, nie działa także panel klienta, API v2, API v4 oraz forum.
Po szybkim sprawdzeniu wygląda to na problem sieciowy po stronie OVH.
Sieć jest dostępna na 13 węzłach oraz forum.
Sieć jest dostępna na 21 węzłach.
Wszystkie węzły, forum, panel klienta oraz API v2 i v4 działają poprawnie.
Wszystkie aktywne VPS otrzymują +24h ważności w ramach rekompensaty za dzisiejszą niedostępność.
Problem z siecią wynikł przez błędną konfigurację, związaną z pracami technicznymi OVH nad ulepszeniem ochrony przed atakami DDoS.
Aylin | 2021-11-10 14:03:02 UTC | #25
Obecnie węzeł działa już poprawnie, poniżej przebieg zdarzeń.
Węzeł wygląda na działający, poprawnie odpowiada na ping.
Podczas odpisywania na zgłoszenia obsługa zauważa problem z węzłem. Po bliższym przyjrzeniu się okazuje się że około 01:00 następuje “urwanie” logów, nie wykonały się także nocne kopie zapasowe.
Węzeł poprawnie odpowiada na ping, ale nie ma możliwości zalogowania się do panelu Proxmox. Po podłączeniu się widzimy błędy kernela. Wygląda na to że mamy zombie :zombie:
Obsługa decyduje o restarcie węzła. Plan zakłada wykonanie łagodnego restartu, a jeżeli to nie zadziała to przejście do twardego restartu. Wysyłamy maila z informacją do klientów których usługi znajdują się na węźle.
Łagodny restart węzła.
Brak reakcji, przechodzimy do twardego restartu.
Po twardym restarcie węzeł wraca do życia, wszystkie VPSy uruchamiają się poprawnie.
Dodanie +24h ważności dla usług dotkniętych awarią.
Wysłanie maili do klientów z dodatkową informacją.
Wszystkie zgłoszenia dotyczące awarii zostały odpisane.
Aylin | 2021-12-15 21:08:18 UTC | #26
Poniżej lista węzłów, zaznaczony checkbox oznacza że prace na węźle zostały zakończone.
Zaplanowanie prac technicznych na 07.12.2021, pomiędzy 22:00 a 23:30.
Spowoduje to niedostępność wszystkich usług z oferty KVM FR w podanym zakresie czasu. Prace obejmą aktualizację panelu Proxmox oraz restart węzłów.
Wszyscy klienci których usług dotyczą prace otrzymają informację drogą mailową.
Przypomnienie o pracach technicznych drogą mailową.
Rozpoczynamy zaplanowane prace techniczne.
Prace techniczne zakończone bez przeszkód :slight_smile:
Aylin | 2021-12-15 22:01:54 UTC | #27
Poniżej lista węzłów, zaznaczony checkbox oznacza że prace na węźle zostały zakończone.
Zaplanowanie prac technicznych na 15.12.2021, pomiędzy 22:00 a 23:30.
Spowoduje to niedostępność wszystkich usług z oferty UpRyze w podanym zakresie czasu. Prace obejmą aktualizację panelu Proxmox oraz restart węzłów.
Wszyscy klienci których usług dotyczą prace otrzymają informację drogą mailową.
Przypomnienie drogą mailową.
Rozpoczynamy zaplanowane prace techniczne.
Prace zakończone :slight_smile: