Quorum

Quorum to minimalna liczba głosów węzłów potrzebna klastrowi do utrzymania sprawnego działania.

Quorum w systemach rozproszonych i klastrowych

Quorum oznacza zasadę, według której grupa współpracujących ze sobą węzłów może uznać określony stan za ważny dopiero wtedy, gdy opowie się za nim wystarczająca część uczestników. Nie chodzi wyłącznie o samo istnienie urządzeń w sieci, lecz o ograniczenie ryzyka, że kilka odłączonych od siebie fragmentów systemu zacznie działać tak, jakby każdy z nich był jedynym prawidłowym środowiskiem. Taki problem jest określany jako podział sieci albo split-brain. Jego skutkiem może być jednoczesna modyfikacja tych samych danych przez różne grupy węzłów, a późniejsze połączenie może ujawnić sprzeczne wersje informacji.

W praktyce quorum służy do podejmowania decyzji dotyczących między innymi wyboru lidera, uruchomienia usługi, zatwierdzenia konfiguracji, przełączenia na kopię zapasową oraz prawa do zapisu. System nie musi wymagać pełnej zgody wszystkich węzłów. Zwykle określa się minimalną liczbę głosów, po której przekroczeniu uznaje się, że decyzja ma wystarczające poparcie. Pozostałe węzły mogą być chwilowo niedostępne, wyłączone, opóźnione albo odizolowane, a mimo to działanie może zostać utrzymane, o ile dostępna część środowiska nadal posiada wymagane głosy.

Quorum większościowe, równe i ważone

Najczęściej spotykany model opiera się na większości. Jeżeli w głosowaniu uczestniczy nieparzysta liczba węzłów, łatwiej wskazać grupę mającą przewagę, ponieważ nie występuje remis. Dla trzech węzłów wymagane są zwykle dwa głosy, a dla pięciu trzy. Taki układ pozwala przetrwać utratę części uczestników, ale nie zapewnia działania po odłączeniu połowy środowiska. Jeżeli pozostała grupa nie ma większości, powinna wstrzymać operacje wymagające wspólnej decyzji, nawet gdy technicznie nadal może odpowiadać na niektóre żądania.

W modelu równym każdy węzeł ma jeden głos. Jest to rozwiązanie łatwe do zrozumienia, ale nie zawsze odpowiada rzeczywistej roli poszczególnych elementów. W modelu ważonym określonym węzłom przypisuje się większe znaczenie, na przykład ze względu na ich lokalizację, stabilność łącza albo funkcję kontrolną. Takie podejście może być użyteczne, lecz wymaga ostrożności. Błędnie dobrane wagi mogą sprawić, że awaria jednego miejsca pozbawi całe środowisko możliwości podejmowania decyzji albo przeciwnie, pozwoli małej grupie uzyskać zbyt dużą kontrolę.

Stosuje się również dodatkowy głos przyznany elementowi rozjemczemu, nazywanemu witness lub arbitrem. Nie musi on przechowywać pełnej kopii danych. Jego zadaniem jest pomóc rozstrzygnąć, która z dwóch odizolowanych grup ma prawo kontynuować pracę. Rozjemca powinien znajdować się w niezależnej lokalizacji i korzystać z odrębnej ścieżki komunikacji. Umieszczenie go w tym samym miejscu co główna grupa nie rozwiązuje problemu utraty lokalizacji, zasilania albo łączności.

Quorum a spójność danych i dostępność usług

Najważniejszy kompromis dotyczy relacji między spójnością a dostępnością. Wymóg uzyskania quorum ogranicza ryzyko powstania dwóch sprzecznych źródeł prawdy, ale może czasowo zablokować zapis, gdy zbyt mała liczba węzłów pozostaje osiągalna. Z punktu widzenia użytkownika wygląda to czasem jak niedostępność usługi, choć mechanizm ochronny działa prawidłowo. Zatrzymanie operacji bywa bezpieczniejsze niż dopuszczenie do niezależnych zmian, których późniejsze połączenie wymagałoby trudnego scalania.

Przy analizie quorum należy odróżnić dostępność procesu od dostępności danych. Węzeł może działać, odpowiadać na polecenia administracyjne i utrzymywać połączenie lokalne, a jednocześnie nie mieć prawa do zapisu, ponieważ nie widzi wystarczającej liczby pozostałych uczestników. Podobnie cała grupa może być osiągalna z jednej lokalizacji, lecz niezdolna do uzyskania większości, jeśli część głosów znajduje się w innym miejscu i utracono połączenie między lokalizacjami.

Znaczenie ma także sposób potwierdzania zapisu. W niektórych rozwiązaniach operacja jest uznawana za zakończoną dopiero po zapisaniu jej na określonej liczbie kopii. W innych quorum dotyczy przede wszystkim decyzji sterujących, a mechanizmy replikacji mają własne zasady potwierdzania. Dlatego sama informacja, że środowisko korzysta z quorum, nie wystarcza do oceny bezpieczeństwa. Należy sprawdzić, czego dokładnie dotyczą głosy, jak wybierany jest lider, kiedy blokowany jest zapis oraz jak odzyskiwana jest grupa po awarii.

Quorum przy awariach, restarcie i podziale sieci

Podczas awarii pojedynczego węzła pozostałe elementy powinny rozpoznać brak odpowiedzi, odczekać ustalony czas i ocenić, czy nadal posiadają wymagane poparcie. Zbyt krótki czas oczekiwania może prowadzić do niepotrzebnych przełączeń przy chwilowych opóźnieniach. Zbyt długi może wydłużyć reakcję na rzeczywistą awarię. Warto więc obserwować nie tylko stan węzłów, ale również opóźnienia, utratę pakietów, błędy dysków, przeciążenie procesora i problemy z zegarem systemowym.

Po restarcie węzeł nie powinien od razu uzyskiwać prawa do zapisu wyłącznie dlatego, że proces uruchomił się bez błędu. Najpierw powinien odtworzyć stan, sprawdzić aktualność danych i ponownie dołączyć do uzgodnionej grupy. Szczególnej uwagi wymaga sytuacja, w której element był odłączony przez dłuższy czas. Stare informacje mogą wyglądać poprawnie lokalnie, lecz nie odpowiadać bieżącemu stanowi reszty środowiska. Bez procedury ponownej synchronizacji istnieje ryzyko wprowadzenia nieaktualnych zmian.

W przypadku podziału sieci mechanizm quorum powinien doprowadzić do tego, że najwyżej jedna część zachowa możliwość wykonywania operacji wymagających nadrzędnej decyzji. Druga część może zostać przełączona w tryb oczekiwania albo ograniczonej obsługi. Samo odłączenie kabla nie zawsze jest równoznaczne z wyłączeniem urządzenia. Węzeł pozbawiony komunikacji może nadal wykonywać lokalne zadania, dlatego potrzebne są mechanizmy izolacji, blokady zapisu lub automatycznego odcięcia zasobów.

Quorum w codziennej administracji i diagnostyce

Przed wdrożeniem rozwiązania warto opisać wszystkie elementy uczestniczące w głosowaniu, ich lokalizację oraz zależności między nimi. Należy odpowiedzieć na pytania, ile awarii ma zostać obsłużonych jednocześnie, co stanie się po utracie całego miejsca, gdzie znajduje się element rozjemczy i jak zostanie potwierdzony powrót do normalnego działania. Przydatna jest również próba awaryjna przeprowadzona w kontrolowanych warunkach. Pozwala sprawdzić, czy oczekiwane zachowanie zgadza się z rzeczywistą konfiguracją.

W dokumentacji powinny znaleźć się progi quorum, sposób wyboru lidera, procedura ręcznego odzyskiwania oraz zasady postępowania po utracie łączności. Nie powinno się zmieniać progów przypadkowo w trakcie awarii. Obniżenie wymagań może przywrócić część funkcji, ale jednocześnie zwiększyć ryzyko pracy dwóch niezależnych grup. Każda taka decyzja powinna być poprzedzona oceną, czy druga część środowiska została rzeczywiście odizolowana i nie ma możliwości równoległego zapisu.

Jeżeli problem z quorum pojawia się na komputerze, urządzeniu sieciowym lub nośniku używanym do przechowywania danych, wskazane jest zabezpieczenie logów i opisanie momentu wystąpienia usterki. Nie należy wielokrotnie restartować wszystkich elementów bez planu, ponieważ może to utrudnić odtworzenie kolejności zdarzeń. W serwisie Warszawskie Pogotowie Komputerowe 24/7 naprawy są z reguły realizowane do 3 dni roboczych, co może ułatwić zaplanowanie diagnostyki sprzętu związanego z problemem komunikacji lub stabilności pracy.