Nie zawsze da się odróżnić martwy serwer od serwera, który po prostu bardzo długo milczy
Jeśli druga maszyna nie odpowiada, najbardziej naturalne pytanie brzmi: „czy padła?”. Problem w tym, że przez zawodną sieć dokładnie tak samo może wyglądać serwer działający poprawnie, ale odcięty, przeciążony albo bardzo wolny. W systemie bez znanej górnej granicy opóźnienia samo milczenie nie jest dowodem śmierci. Praktyczne systemy używają timeoutów i failure detectorów, ale są to decyzje oparte na założeniach i prawdopodobieństwie, nie absolutna wiedza. To jeden z powodów, dla których awarie częściowe są znacznie trudniejsze niż zwykły crash jednego programu.
Na jednym komputerze awaria jest bardziej lokalna
Gdy proces lokalny kończy się i system operacyjny informuje o jego zakończeniu, inny proces dostaje relatywnie jasny sygnał. W sieci obserwator widzi przede wszystkim wiadomości i ich brak. Jeżeli heartbeat nie dotarł, nie wiadomo od razu, czy nadawca przestał działać, czy tylko zerwano trasę pomiędzy maszynami.
Milczenie ma wiele możliwych przyczyn
Serwer może być wyłączony, ale może też wykonywać długą pauzę garbage collectora, czekać na dysk, mieć przeciążony procesor, być odcięty przez awarię przełącznika albo działać poprawnie po drugiej stronie podziału sieci. Z perspektywy obserwatora wszystkie te przypadki mogą przez pewien czas wyglądać identycznie: brak odpowiedzi.
Timeout jest założeniem operacyjnym
Systemy produkcyjne nie mogą czekać nieskończenie, dlatego ustalają limity. Po określonym czasie uznają węzeł za podejrzany, wybierają nowego lidera albo kierują ruch gdzie indziej. Taki mechanizm jest konieczny, ale może się pomylić. Zbyt krótki timeout potraktuje powolną maszynę jak martwą; zbyt długi wydłuży prawdziwą awarię z punktu widzenia użytkownika.
Fałszywe podejrzenie może samo stworzyć problem
Jeżeli system uzna działający lider za martwy i zacznie wybierać nowego, podczas gdy stary nadal wykonuje pracę, trzeba mieć mechanizmy zapobiegające sprzecznym decyzjom. Dlatego protokoły consensusowe używają kadencji, numerów epok i quorum. Problem detekcji awarii łączy się więc bezpośrednio z problemem uzgadniania, kto ma prawo podejmować decyzje.
Systemy rozproszone żyją z niepewnością
Amazon w materiałach o systemach rozproszonych podkreśla, że niezależne awarie i niedeterministyczność prowadzą do sytuacji, w których nie zawsze można wiedzieć, czy coś faktycznie uległo awarii. To fundamentalna różnica wobec intuicji z programowania na jednej maszynie. Zamiast absolutnego „serwer żyje / serwer nie żyje” praktyka często operuje na „odpowiada wystarczająco szybko / nie odpowiada w czasie, który uznajemy za bezpieczny”.
Failure detector jest podejrzeniem o określonej jakości
W teorii rozproszonej failure detector nie musi być nieomylną wyrocznią. Może chwilowo podejrzewać zdrowy proces albo późno wykryć prawdziwy crash. Badania pokazują, że nawet taka niedoskonała dodatkowa informacja wystarcza w niektórych modelach do rozwiązywania problemów, których czysta asynchroniczność nie pozwala rozwiązać. Praktyczny heartbeat robi podobną rzecz: zamienia absolutne pytanie „czy serwer żyje?” w operacyjne „czy zachowuje się wystarczająco dobrze, by nadal na nim polegać?”.
Dlaczego „slow is the new down” bywa sensowną polityką
Dla usługi obsługującej użytkownika serwer odpowiadający po 30 sekundach może być funkcjonalnie równie bezużyteczny jak serwer wyłączony, jeśli deadline żądania wynosi sekundę. Routing i health checks często klasyfikują więc węzły według zdolności do spełnienia oczekiwanego czasu odpowiedzi, nie metafizycznego stanu życia. To podejście zwiększa dostępność, ale musi być ostrożne, by przeciążenie chwilowe nie wywołało masowych, zsynchronizowanych failoverów.
To ma również konsekwencję dla automatycznego failoveru. Jeśli obserwator zbyt łatwo uzna wolny węzeł za martwy, może uruchomić przełączenie, choć stary serwer nadal zapisuje dane. Jeśli będzie zbyt ostrożny, prawdziwa awaria potrwa dłużej. Dlatego systemy HA łączą heartbeat z quorum, fencingiem, lease'ami lub innymi mechanizmami odbierającymi dawnemu liderowi prawo do działania. Samo wykrycie „braku odpowiedzi” prawie nigdy nie wystarcza jako pełny protokół bezpieczeństwa.