Restarty VPS 25-26.03.2020

Chciałbym się oficjalnie odnieść (niestety trochę z opóźnieniem bo jest sporo innych palących spraw) co do sytuacji z ostatnimi restartami dla prawie wszystkich klientów:

Przynajmniej kilka klientów było mocno zniesmaczonych cała sytuacją a zwłaszcza bardzo krótkim czasem pomiędzy powiadomieniem mailowym a przeprowadzonych restartach.
Jest to uzasadnione bo takie restarty moim zdaniem powinny wiązać się z większym wyprzedzeniem maili które pozwalają się na to przygotować, powiedzmy tydzień przed byłby ok.

Ogólnie sporo rzeczy jednocześnie poszło nie tak.

Napotkane problemy

1. Brak czasu

Niestety nie mieliśmy możliwości poczekać aż tyle czasu co zwykle w przypadku masowych rebootów.
Z godziny na godzinę coraz więcej klientów doświadczało błędu w skutek którego nie mogło włączyć swojej usługi którą przed chwilą wyłączyli.
Włączenie swojej usługi jest sprawą kluczową gdyż to właśnie za włączony serwer płacą nasi klienci.
To pierwszy problem na jaki napotkaliśmy - nie mieliśmy tej wygody poinformować klientów z dużym wyprzedzeniem.

2. Brak sprzętu

Przynajmniej jeden klient poruszył kwestię braku redundancji w przypadku naszej oferty.
To prawda, nie mamy jej zbyt wiele ale w zasadzie tego wymaga nasza oferta.
Na dobrą sprawą nie znajdziemy oferty serwerów dedykowanych która oferuje opcje klasy enterprise w tej cenie na dodatek z charakterystyką korzystną dla serwerów gier (ochrona DDoS, wysoka wydajność per rdzeń CPU, szybki RAM).
Nie sądzę aby klienci byli zadowoleni gdyby musieli zapłacić więcej na dodatek za niżej taktowane CPU i gorszą ochroną antyDDoS.

Nasze “ubezpieczenie” to zamiast inwestować w drogi sprzęt w małej ilości, dużo taniego sprzętu który łatwo zastąpić.
W takim przypadku jeśli coś jest nie tak, po prostu przenosimy klienta na inny sprzęt.
Niestety w tym czasie pojawił się kolejny problem, nie mieliśmy wolnych zasobów sprzętowych na taką operację.

3. Poważny bug

Zakładając ze nawet mamy rezerwowe zasoby, błąd był na tyle poważny że uniemożliwiał 100% łagodne poprawne wyłączenie VPSów czy też uruchomienie nowych procesów w ramach systemd.
Oznacza to że nawet gdybyśmy posiadali live migrację czyli spauzowanie VM, przeniesienie jej i odpauzowanie na innym sprzęcie to nie było to przez ten błąd możliwe lub było bardzo utrudnione.
W momencie gdy mamy mało obsługi, mało czasu oraz skomplikowany problem do rozwiązania, sięgamy po proste rozwiązania aby jak najszybciej przywrócić dostęp do usługi z największą skutecznością.

4. Trudna szybka komunikacja

Nie mieliśmy skutecznego sposobu aby szybko poinformować tylko tych klientów których dotyczy restart.
Całe szczęście udało mi się to rozwiązać trochę wcześniej


Po małych udoskonaleniach obecnie mamy już całkiem przyzwoite narzędzie które pozwala szybciej zająć się problemem zamiast ustalać do kogo wysyłać maile.

5. Niechęć klientów do regularnych restartów

Ta sytuacja jest też niestety wynikiem tego że większość klientów nie jest przygotowana na restarty i w sumie nie chce być przygotowana na nie.
Wnioskuję tak po wypowiedziach w wątku który zakładałem w poprzednim roku a pytałem w sumie o to czy klienci wolą mieć więcej regularnych i zaplanowanych restartów czy może raz na jakiś czas awaryjne:

6. Nieskuteczność live patchów

Powiązane z punktem wyżej odnośnie dopłaty za mniej restartów.
W zasadzie przyjęliśmy na siebie koszt licencji na live patch kernela czyli łatanie jądra systemu bez restartu systemu ale jak widać to też nie pomogło.
Ta metoda ma swoje ograniczenia.

Wnioski

Generalnie nie unikniemy wcześniej zaplanowanych restartów.
Teraz powstaje pytanie z jak dużym wyprzedzeniem potrzebujecie otrzymać powiadomienie że nastąpi restart oraz w jakiej godzinie i dniu tygodnia jest on przez Was preferowany?

4lajki

osobiście uważam że 3 dni to wystarczający czas

3:00-4:00 w nocy? :thonking:

myślę że jakoś na początku lub w środku kiedy jest najmniejszy ruch, czyli wtorek-środa

3lajki

A w obecnej sytuacji jak częsta byłaby ta regularność? Raz na dwa tygodnie (tak chyba rozważano rok temu)? Czy może tylko raz na miesiąc?

O jakiej 3-4 restart? Jak ja ręcznie usługę muszę włączyć to mam specjalnie budzik na 4 nastawiać? No nigdy w życiu xD Normalne jakieś godziny restartów i będzie git

Polecam autostart sobie zrobić :thinking:

2lajki

W pterodactylu? No powodzenia

Z tego co widać to w listopadzie 2019 wreszcie dodali takie opcje, dokładnie w tym commicie:

Proponuję zebrać statystyki, na forum jest niewielka ilość klientów które się wypowiedzą.

@bopke a widzisz że ten commit jest odrzucony?

Co rozumiesz przez odrzucony? Znajduje się w branchu develop, czyli aktualnie głównym branchu aplikacji.

1lajk

Obecnie rozważamy regularne restarty co 3 miesiące, co 2 miesiące lub co miesiąc.
W przypadku ważnych patchów które wymagają restartu wtedy dalibyśmy znać X dni o których mowa że wam wystarczy. Staramy się ustalić ten X.

Weź pod uwagę rozwiązanie hybrydowe :upside_down_face:
Metryki nie wyrażają tyle co komentarze klientów, najlepiej mieć po prostu oba źródła danych.

1lajk

Tak 36h przed planowanym restartem.

Obojętnie.

Ja mam wszystkie potrzebne usługi ustawione w startupie więc nawet jakby został teraz wykonany restart to byłoby mi to obojętne.

Co do serwerów MC i innych nie korzystam z gotowych rozwiązań typu Pterodactyl. Do serwera MC napisałem sobie własną konsolę w PHP i mam ten problem ze startupem rozwiązany.

Według mnie najlepszym dniem na restarty jest poniedziałek o 3/4 w nocy. Mówię to na podstawie statystyk osób online na moim serwerze TeamSpeak.

Informacja o planowanym restarcie w moim przypadku czy to 3 dni czy 4 czy 1 - zastanawiam się komu to robi jakąkolwiek różnicę - jeśli restarty miałyby być w nocy. Jest mi to obojętne czy dowiem się o tym dzień czy tydzień przed - bo jestem przygotowany (po prostu - zwyczajnie - nawet jak sam robię restart) - że moje usługi zasypiają spokojnie i spokojnie się budzą.

OVH na przykład jeśli planuje prace konserwacyjne, informuje o nich miesiąc i 14 dni przed planowaną przerwą w usługach.

pt., 3 kwi 2020, 12:01
(…) informujemy, że prace modernizacyjne rozpoczną się w dniu 2020-05-04 na infrastrukturze, na której hostowane są konta e-mail powiązane z Państwa hostingiem i/lub z usługą MX Plan. Na 15 dni przed rozpoczęciem prac wyślemy dodatkowe przypomnienie e-mailem. Operacja będzie dotyczyła Państwa domeny oraz usług poczty elektronicznej.

mBank natomiast 2 dni przed informuje o tym, że

W godzinach 2.30 - 7.30 nie zapłacisz kartą w sklepie, nie wypłacisz gotówki
z bankomatu oraz nie skorzystasz z wpłatomatu.
Między 2.30 - 9.30 nie zalogujesz się do serwisu transakcyjnego oraz aplikacji mobilnej .
Od 2.00 do 10.00 nie złożysz wniosku.
W godzinach 22.00 - 10.00 na mLinii nie zrealizujemy żadnej operacji na Twoim rachunku, ale w razie potrzeby zablokujemy Twoją kartę.

Nie wiem jakie usługi hostują klienci, jak one działają, jak ważne jest działanie usługi w godzinach nocnych.

Myślę, że więcej “niestabilności” jest w działaniu usługi klienta niż w tym restarcie comiesięcznym vpsa. Jeżeli komuś ma przeszkadzać taki restart, to najprędzej osobie, która nie ma podstawowo zabezpieczonych swoich usług przed najzwyklejszą awarią sprzętu/wyłączeniem serwera. Mi one zawadzać nie będą, jeśli mają przyczynić się do stabilności vpsa - super.

10lajków