Dlaczego klaster z dwóch węzłów to najgorszy wybór: problem większości

Kupiłeś drugi serwer i zbudowałeś klaster. Czujesz się bezpieczniej: są teraz dwie maszyny, a jeśli jedna padnie, druga niesie dalej.

Nie niesie. Klaster z dwóch węzłów jest bardziej kruchy niż pojedynczy węzeł, a dzień, w którym się tego dowiadujesz, bywa zwykle złym dniem.

Dlaczego

Decyzje w klastrze podejmuje się większością. Jeśli działają dwa z trzech węzłów, większość jest i klaster pracuje dalej. Jeśli padnie jeden z dwóch, pozostały jeden węzeł nie jest większością, więc klaster sam się blokuje: maszyny działają dalej, ale konfiguracji nie da się zmienić, nowej maszyny nie da się uruchomić, a większość pracy zarządczej staje.

To nie jest wada, to celowy projekt. Alternatywa jest znacznie gorsza: gdy dwa węzły się nie widzą, oba mówią, że ja stoję, a drugi padł, i uruchamiają tę samą maszynę wirtualną w dwóch miejscach. Ten sam dysk jest zapisywany z obu stron, a dane zostają uszkodzone nieodwracalnie.

Klaster chroni cię więc, blokując cię. Ale przy dwóch węzłach ta ochrona włącza się przy połowie wszystkich awarii.

Właściwą liczbą jest trzy

W klastrze trzech węzłów, gdy padnie jeden, zostają dwa, większość się trzyma i życie toczy się dalej. Dlatego liczba trzy pojawia się w dokumentacji klastrów wszędzie.

Trzecia maszyna nie musi być mocna. Ona tylko oddaje głos, nie musi wykonywać żadnej pracy. Mała maszyna, nawet stary komputer, wystarczy.

Jeśli naprawdę nie chcesz trzeciej maszyny, można zamiast tego postawić mały węzeł świadka, istniejący wyłącznie po to, by głosować. Nie jest pełnym węzłem i nie uruchomisz na nim maszyn, ale dopełnia arytmetykę większości do trzech. Jeśli zamierzasz zostać przy dwóch węzłach, przynajmniej to ustaw.

Jeśli zostajesz przy dwóch węzłach, wiedz to

Gdy jeden węzeł zostaje wyjęty do serwisu, pozostały pojedynczy węzeł też staje się niezarządzalny. Nawet planowa aktualizacja zostawia cię więc zablokowanym.

Da się ręcznie powiedzieć, że niech pojedynczy węzeł też decyduje, ale to otwiera z powrotem dokładnie opisane wyżej ryzyko podwójnego uruchomienia. Robi się to tymczasowo, świadomie i krótko; nie jest to rozwiązanie trwałe.

Zbudowanie klastra to nie robienie kopii zapasowych

To dwie rzeczy najczęściej mylone. Klaster służy dostępności: żeby praca trwała, gdy maszyna padnie. Kopia zapasowa służy odzyskaniu: żebyś mógł wrócić po uszkodzeniu albo omyłkowym skasowaniu danych.

Klaster nie przywróci maszyny wirtualnej skasowanej przez pomyłkę. Skasowanie rozchodzi się natychmiast na wszystkie węzły, bo klaster istnieje po to, by widziały to samo. Nawet mając klaster, nadal będziesz potrzebował kopii zapasowych.

Co robi Atlas

Atlas traktuje klaster nie jako pojęcie, tylko jako stan: ile jest węzłów, ile głosuje, czy większość trzyma się w tej chwili.

Miejscem, w którym pomaga to najbardziej, jest aktualizowanie. Przed aktualizacją węzła Atlas patrzy, ile maszyn na nim może przenieść się na inny węzeł, i podpowiada ci kolejność. Podpowiedź pozostaje podpowiedzią: polecenie migracji nie wykonuje się samo, przycisk naciskasz ty.

Jeden szczegół ma tu szczególne znaczenie i trafia wprost w temat tego wpisu. Polecenie pytające o stan klastra zawodzi w ten sam sposób w dwóch różnych sytuacjach: przy faktycznym byciu maszyną samodzielną i przy byciu członkiem klastra, którego warstwa klastrowa się rozpadła. Jeśli tych dwóch się nie rozróżni, produkt mówi, że klastra nie ma i większość jest w porządku, dokładnie w chwili, gdy klaster się rozpadł. Czyli produkuje najbardziej uspokajające zdanie w najgroźniejszym momencie.

Atlas rozróżnia je, patrząc na to, czy istnieje plik konfiguracji: ten plik zapisywany jest razem z członkostwem i zostaje na miejscu nawet wtedy, gdy warstwa klastrowa się rozpadnie. Rozróżnienie mieszka w jednym miejscu, bo wcześniej było zapisane osobno w trzech różnych miejscach i wszystkie trzy miały ten sam błąd.