przerwy w działaniu bez redundancji

Przerwy w działaniu bez redundancji to skutek braku zapasowej infrastruktury przejmującej ruch w razie awarii.

Brak ścieżki przejęcia ruchu podczas awarii

Przerwy w działaniu bez redundancji występują wtedy, gdy usługa zależy od pojedynczego elementu infrastruktury, a jego uszkodzenie nie uruchamia żadnego zapasowego mechanizmu. Takim elementem może być jeden serwer, pojedynczy zasilacz, jeden przełącznik sieciowy, jedno łącze internetowe, jeden kontroler macierzy albo tylko jedna instancja aplikacji. Jeżeli cały ruch użytkowników trafia do tego samego składnika, awaria tego składnika oznacza niedostępność usługi, nawet gdy pozostałe urządzenia działają poprawnie.

Redundancja nie polega wyłącznie na posiadaniu dodatkowego sprzętu w magazynie. Zapasowy element musi być odpowiednio skonfigurowany, mieć dostęp do aktualnych danych i dysponować mechanizmem przejęcia obciążenia. W zależności od architektury może to być klaster wysokiej dostępności, replikacja danych, zapasowe łącze, zasilanie awaryjne, równoważenie ruchu lub ręcznie uruchamiana procedura odtworzeniowa. Jeżeli drugi element nie jest gotowy do pracy albo nie ma aktualnej kopii danych, jego obecność nie zapewnia rzeczywistej ciągłości działania.

Jak pojedynczy punkt awarii powoduje niedostępność

Pojedynczy punkt awarii, określany jako single point of failure, jest składnikiem, którego uszkodzenie zatrzymuje cały wymagany przepływ danych lub obsługę użytkowników. Przykładem może być serwer działający bez drugiej instancji. Awaria płyty głównej, pamięci operacyjnej, dysku systemowego, interfejsu sieciowego albo systemu operacyjnego może wtedy odciąć aplikację, niezależnie od tego, czy sama sieć lokalna i komputery użytkowników funkcjonują prawidłowo.

Podobny skutek występuje przy zależnościach ukrytych poza głównym serwerem. Usługa może działać na dwóch komputerach, ale korzystać z jednego serwera DNS, jednej bramy sieciowej, jednego urządzenia przechowującego dane lub jednego źródła zasilania. W takim układzie awaria wspólnego zależnego elementu nadal powoduje przerwę w działaniu. Istotne jest również rozróżnienie między nadmiarowością sprzętową a nadmiarowością danych. Dwa serwery korzystające z tej samej uszkodzonej kopii bazy nie zapewniają ochrony przed utratą lub niedostępnością informacji.

Objawy i metody potwierdzenia problemu

Przerwa może objawiać się całkowitym brakiem odpowiedzi, błędami połączenia, przekroczeniem czasu oczekiwania, zerwaniem sesji albo częściowym działaniem aplikacji. Użytkownik może widzieć komunikat o niedostępnym zasobie, podczas gdy inne funkcje pozostają dostępne. W systemach sieciowych często pojawiają się utracone pakiety, brak odpowiedzi na zapytania DNS, niedostępność bramy domyślnej albo zmiana statusu interfejsu. W przypadku urządzenia fizycznego mogą wystąpić alarmy zasilania, przegrzewania, uszkodzenia dysku lub kontrolera.

Potwierdzenie braku redundancji wymaga prześledzenia całej ścieżki od klienta do usługi. Należy ustalić, z jakim adresem i portem łączy się aplikacja, przez jakie urządzenia przechodzi ruch, gdzie znajdują się dane oraz które elementy dostarczają zasilanie i rozwiązywanie nazw. Sama obserwacja, że drugi serwer jest włączony, nie wystarcza. Trzeba sprawdzić, czy faktycznie przyjmuje ruch, czy posiada aktualny stan danych i czy przełączenie zostało przetestowane. Przydatne są dzienniki systemowe, monitoring dostępności, historia zdarzeń sprzętowych, pomiary czasu odpowiedzi oraz kontrolowane testy odłączenia pojedynczych elementów.

Ograniczanie skutków i planowanie odtworzenia

Usunięcie problemu zaczyna się od wskazania elementów, których awaria zatrzymuje usługę, a następnie od dobrania mechanizmu zapasowego do rodzaju ryzyka. Dla zasilania może to być drugi zasilacz podłączony do niezależnego obwodu, dla sieci — dodatkowy przełącznik lub łącze, a dla danych — replikacja i sprawdzone kopie zapasowe. Dwie jednostki powinny być rozpatrywane razem z ich zależnościami: wspólna szafa, wspólne chłodzenie, ten sam kanał komunikacyjny lub jedno źródło energii mogą stworzyć wspólny punkt awarii.

Ważnym elementem jest procedura przełączenia oraz powrotu do normalnej pracy. Powinna określać, kto podejmuje decyzję, jakie warunki uruchamiają przejęcie ruchu, jak kontroluje się spójność danych i w jaki sposób przywraca uszkodzony składnik. Należy także mierzyć czas wykrycia awarii, czas przełączenia oraz zakres ewentualnej utraty danych. Bez regularnych testów redundancja pozostaje założeniem konfiguracyjnym, a nie potwierdzoną właściwością systemu. Każda zmiana sprzętu, konfiguracji sieciowej lub oprogramowania może ponownie wprowadzić pojedynczy punkt awarii, dlatego mapa zależności powinna być aktualizowana po modernizacji infrastruktury.