Awaria całego serwera

Awaria całego serwera to zdarzenie uniemożliwiające dostęp do wszystkich baz i usług hostowanych na danej maszynie.

Zakres awarii całego serwera

Awaria całego serwera oznacza stan, w którym jedna maszyna przestaje zapewniać dostęp do wszystkich uruchomionych na niej usług albo do całego środowiska, które od tej maszyny zależy. Objawem może być jednoczesny brak dostępu do stron internetowych, aplikacji, udziałów plikowych, baz danych, systemów uwierzytelniania lub innych usług sieciowych. Nie musi to oznaczać jednego konkretnego uszkodzenia. Przyczyną może być problem z zasilaniem, płytą główną, pamięcią operacyjną, procesorem, układem chłodzenia, macierzą dyskową, systemem operacyjnym, konfiguracją sieci albo oprogramowaniem uruchamianym podczas startu.

Ważne jest odróżnienie awarii całego serwera od niedostępności pojedynczej usługi. Jeżeli działa zdalne logowanie i można odczytać stan procesów, lecz nie odpowiada jedna aplikacja, problem może dotyczyć tylko tej aplikacji lub jej zależności. Jeżeli natomiast urządzenie nie odpowiada na połączenia sieciowe, nie reaguje na lokalną konsolę albo samoczynnie się wyłącza, zakres usterki jest szerszy. Brak odpowiedzi może jednak wynikać również z awarii przełącznika, przewodu, zasilacza awaryjnego lub reguł zapory sieciowej, dlatego sama obserwacja z jednego komputera nie wystarcza do postawienia rozpoznania.

Objawy widoczne przed i po zatrzymaniu maszyny

Przed całkowitym zatrzymaniem serwera często występują symptomy ostrzegawcze. Należą do nich narastające opóźnienia, błędy wejścia i wyjścia, samoczynne restarty, komunikaty o przepełnieniu systemu plików, utracie urządzenia blokowego, przegrzewaniu albo błędach pamięci. W systemach uniksowych ślady mogą znajdować się w dzienniku systemowym, na przykład w wynikach mechanizmów logowania jądra i usług. W systemach Windows podobne informacje są rejestrowane w Podglądzie zdarzeń, między innymi w dziennikach System i Application. Nagłe ustąpienie logów nie dowodzi awarii konkretnego podzespołu, ponieważ po utracie zasilania urządzenie może nie zdążyć zapisać ostatnich zdarzeń.

Po awarii można zaobserwować brak odpowiedzi na żądania sieciowe, nieudane połączenia z portami usług, zatrzymanie odpowiedzi DNS, przerwanie sesji plikowych albo błędy aplikacji zgłaszające niedostępność bazy danych. Test polegający na wysłaniu żądania ICMP, często nazywany pingiem, sprawdza tylko możliwość uzyskania odpowiedzi na poziomie sieci i może być zablokowany konfiguracyjnie. Z kolei odpowiedź na ping nie potwierdza poprawnego działania usług. Należy porównywać kilka niezależnych sygnałów: dostępność z różnych urządzeń, stan połączenia fizycznego, działanie konsoli lokalnej, kontrolki sprzętowe, temperatury, komunikaty kontrolera dysków oraz zdarzenia zapisane przed wystąpieniem problemu.

Rozdzielenie przyczyny sprzętowej od programowej

Diagnostykę rozpoczyna się od ustalenia, czy serwer ma zasilanie i czy przechodzi procedurę uruchamiania. Sprawdza się przewody, zasilacz, bezpieczniki, stan modułu zasilania awaryjnego, kontrolki obudowy oraz reakcję na przycisk zasilania. Jeżeli urządzenie nie wykonuje testu POST, czyli wstępnego testu sprzętu wykonywanego przed załadowaniem systemu, podejrzenie kieruje się w stronę zasilania, płyty głównej, pamięci, procesora lub innego elementu niezbędnego do rozpoczęcia startu. Kody dźwiękowe i komunikaty firmware’u trzeba interpretować zgodnie z dokumentacją konkretnej płyty lub platformy, ponieważ ich znaczenie nie jest uniwersalne.

Jeżeli test POST kończy się poprawnie, lecz system nie startuje, analizuje się kolejność urządzeń rozruchowych, stan dysków, komunikaty kontrolera magazynu danych oraz błędy ładowania systemu. Uszkodzenie jednego dysku może spowodować niedostępność całej maszyny, gdy system lub istotne dane znajdują się właśnie na tym nośniku. W przypadku macierzy nie wolno pochopnie inicjalizować, formatować ani przebudowywać konfiguracji, ponieważ takie działania mogą zmienić metadane i utrudnić odzyskanie danych. Najpierw należy zabezpieczyć dostępne informacje, ustalić model kontrolera, kolejność dysków i stan każdego nośnika, a dopiero później wybrać bezpieczną procedurę.

Bezpieczne postępowanie po utracie wszystkich usług

Po stwierdzeniu awarii całego serwera warto zapisać dokładny czas wystąpienia problemu, zakres niedostępności oraz ostatnie wykonane czynności, takie jak aktualizacja, restart, wymiana podzespołu lub zmiana konfiguracji sieci. Nie należy wielokrotnie wymuszać restartu, odłączać dysków w przypadkowej kolejności ani uruchamiać narzędzi naprawczych bez rozpoznania sytuacji. Każde uruchomienie może zmienić stan systemu plików, rozpocząć automatyczną naprawę albo nadpisać informacje potrzebne do analizy. Jeżeli urządzenie się przegrzewa, wydaje nietypowe dźwięki lub pojawia się zapach spalenizny, należy przerwać próby uruchamiania i odłączyć zasilanie zgodnie z zasadami bezpieczeństwa.

Naprawa powinna obejmować nie tylko przywrócenie zasilania i uruchomienie systemu, lecz także weryfikację integralności systemu plików, stanu dysków, pamięci, temperatur, sterowników, usług startowych i połączeń sieciowych. Po odzyskaniu dostępu trzeba sprawdzić, czy wszystkie wymagane usługi rzeczywiście działają oraz czy aplikacje widzą prawidłowe zasoby i dane. W przypadku sprzętu serwerowego diagnostyka wymaga zachowania ostrożności, ponieważ pozornie skuteczny restart może jedynie ukryć przyczynę i doprowadzić do powtórnej awarii. Dokumentacja objawów, komunikatów i wykonanych czynności ułatwia odtworzenie kolejności zdarzeń oraz dobranie dalszego postępowania.