Node and Disk Majority

Node and Disk Majority to model kworum klastra, w którym prawo głosu mają węzły oraz dysk świadka.

Node and Disk Majority — czym jest ten model kworum

Node and Disk Majority to sposób podejmowania decyzji o dostępności klastra, w którym głosy pochodzą z dwóch rodzajów elementów: z aktywnych węzłów oraz z wydzielonego dysku świadka. Dysk nie musi pełnić roli magazynu danych aplikacji. Jego zadaniem jest przechowanie informacji potrzebnych do rozstrzygnięcia, która część środowiska ma prawo kontynuować pracę po awarii połączenia między węzłami. Dzięki temu decyzja nie zależy wyłącznie od liczby uruchomionych komputerów uczestniczących w klastrze.

Najważniejszym pojęciem jest kworum. Oznacza ono minimalną liczbę ważnych głosów koniecznych do uznania, że dana część klastra ma wystarczające podstawy do działania. Głosy mogą być przyznawane węzłom, a dodatkowy głos może należeć do dysku świadka. Jeżeli większość zostanie utrzymana, odpowiedzialny mechanizm zarządzający może pozostawić zasoby w trybie aktywnym. Jeżeli większość zostanie utracona, środowisko może zatrzymać wybrane usługi albo ograniczyć ich uruchamianie, aby uniknąć niespójności.

W praktyce model ten ma ograniczać ryzyko tak zwanej sytuacji podziału. Dochodzi do niej wtedy, gdy jeden logiczny klaster zostaje rozdzielony na dwie grupy, które nie mogą się ze sobą komunikować, lecz każda z nich nadal widzi część zasobów. Bez dodatkowego mechanizmu rozstrzygającego obie grupy mogłyby uznać się za uprawnione do obsługi tych samych danych. Dysk świadka działa wtedy jako niezależny punkt odniesienia, pomagający wskazać grupę posiadającą wymagane poparcie.

Node and Disk Majority — kontekst techniczny i porównania

W prostym modelu opartym wyłącznie na węzłach każdy komputer ma jeden głos. Takie rozwiązanie jest łatwe do zrozumienia, lecz jego zachowanie zależy od liczby elementów oraz od tego, jak rozkładają się awarie. Przy nieparzystej liczbie węzłów można uzyskać naturalną większość bez dodatkowego świadka. Przy parzystej liczbie węzłów może powstać remis, a wtedy potrzebny jest element rozstrzygający albo inna zasada arbitrażu.

Node and Disk Majority dodaje do głosowania dysk świadka. W efekcie dysk może zmienić wynik w sytuacji, w której sama liczba węzłów nie wystarcza do jednoznacznej decyzji. Przykładowo, gdy część komputerów traci łączność z pozostałymi, dostęp do świadka może umożliwić jednej stronie zachowanie prawa do pracy, podczas gdy druga strona zostanie wstrzymana. Nie oznacza to, że świadek zastępuje węzeł. Nie uruchamia on aplikacji i nie przejmuje jej obciążeń. Dostarcza jedynie głosu oraz informacji o stanie wymaganych przez mechanizm kworum.

Warto odróżnić ten model od wariantu, w którym świadkiem jest udział plikowy. W obu przypadkach chodzi o dodatkowy głos, jednak sposób przechowywania informacji i zależności awaryjne są inne. Dyskowy świadek wymaga poprawnie działającego dostępu do określonego nośnika, natomiast świadek plikowy korzysta z lokalizacji udostępniającej plik. Różnice dotyczą także odporności na awarie, wymagań sieciowych oraz sposobu monitorowania dostępności.

Znaczenie ma również topologia połączeń. Jeżeli węzły i dysk świadka znajdują się w tej samej zależnej lokalizacji, jedna awaria zasilania lub infrastruktury może pozbawić środowisko wielu głosów jednocześnie. Sam fakt zastosowania dysku świadka nie gwarantuje więc wysokiej odporności. Należy przeanalizować, gdzie znajduje się nośnik, jak jest podłączony, czy jego dostępność jest monitorowana oraz jakie zdarzenia powodują odebranie głosu.

Node and Disk Majority — typowe problemy w konfiguracji

Jednym z częstszych problemów jest umieszczenie świadka na zasobie, który zależy od tego samego sprzętu, zasilania albo połączenia sieciowego co węzły. W normalnych warunkach konfiguracja może działać poprawnie, lecz podczas awarii traci się jednocześnie kilka głosów. W rezultacie mechanizm kworum może zatrzymać usługi, mimo że poszczególne komputery nadal są sprawne.

Inny problem pojawia się wtedy, gdy dysk świadka jest dostępny tylko okresowo. Błędy sterownika, niestabilne połączenie, problemy z kontrolerem albo opóźnienia w komunikacji mogą powodować wielokrotne pojawianie się i znikanie głosu. Takie zachowanie utrudnia ocenę, czy przyczyną przestoju jest awaria węzła, sieci, nośnika czy samej konfiguracji klastra. W logach mogą być widoczne komunikaty o utracie quorum, zmianie właściciela zasobu lub przejściu grupy w stan ograniczonej pracy.

Ryzyko stanowi także ręczne wymuszanie uruchomienia usług bez zrozumienia konsekwencji. Działanie takie może być uzasadnione podczas kontrolowanej procedury awaryjnej, ale powinno wynikać z dokumentacji i znajomości stanu danych. Samo przywrócenie procesu nie rozwiązuje problemu, jeżeli nadal istnieje podział komunikacyjny albo nie wiadomo, która kopia zasobów jest aktualna.

W środowiskach korzystających z tego modelu sprawdza się również, czy zegary, nazwy zasobów, uprawnienia i ścieżki dostępu są spójne. Niewielka rozbieżność w konfiguracji może stać się widoczna dopiero po awarii. Pomocne jest cykliczne testowanie utraty pojedynczego węzła, utraty komunikacji oraz niedostępności świadka. Test powinien obejmować obserwację logów, stanu głosów i zachowania aplikacji, a nie tylko sprawdzenie, czy komputery odpowiadają na polecenia.

Node and Disk Majority — praktyczne wskazówki diagnostyczne

Przed zmianą konfiguracji warto sporządzić prostą mapę zależności. Powinny znaleźć się na niej węzły, kanały komunikacyjne, miejsce przechowywania świadka, źródła zasilania oraz zasoby, które mają być chronione przez kworum. Taki schemat pozwala zauważyć, czy dwa pozornie niezależne elementy korzystają w rzeczywistości z jednego przełącznika, kontrolera lub nośnika.

Następnie należy sprawdzić aktualny stan głosów i przyczyny ostatnich zmian. Przydatne są dzienniki systemowe, rejestry zdarzeń, informacje o stanie dysku oraz komunikaty dotyczące połączeń między węzłami. Nie powinno się oceniać sytuacji wyłącznie na podstawie pojedynczego błędu. Ważna jest kolejność zdarzeń: najpierw mogła wystąpić utrata sieci, później odłączenie świadka, a dopiero na końcu zatrzymanie usługi.

Dobrym zwyczajem jest utrzymywanie kopii konfiguracji, dokumentowanie zmian i ustalenie procedury postępowania po awarii. Należy wiedzieć, kto podejmuje decyzję o ponownym uruchomieniu, jak rozpoznać aktywną część klastra i w jaki sposób zweryfikować spójność danych. Warto także kontrolować stan wolnego miejsca, kondycję nośnika i uprawnienia do lokalizacji świadka. Problemy z dostępem mogą wyglądać podobnie do awarii samego klastra.

Jeżeli środowisko działa na komputerze używanym również do innych zadań, trzeba oddzielić diagnostykę sprzętową od analizy oprogramowania. Niestabilna pamięć, przegrzewanie, błędy dysku lub uszkodzone przewody mogą powodować utratę komunikacji i błędne wnioski dotyczące kworum. Najpierw warto zebrać kopie logów oraz opisać objawy, a dopiero później wykonywać modyfikacje. Ogranicza to ryzyko utraty informacji potrzebnych do ustalenia źródła problemu.

Node and Disk Majority — kiedy zgłosić się do serwisu

Do serwisu warto zgłosić się wtedy, gdy komputer samoczynnie traci dostęp do dysku świadka, pojawiają się powtarzające się komunikaty o utracie większości, system nie uruchamia chronionych usług albo po awarii pozostaje niejasne, która część środowiska jest aktywna. Szczególnej uwagi wymagają sytuacje, w których problem występuje po wymianie dysku, kontrolera, płyty głównej, przewodu lub elementu infrastruktury sieciowej. Objaw może wskazywać zarówno na uszkodzenie podzespołu, jak i na zmianę identyfikacji urządzenia albo niezgodność ustawień.

Przy zgłoszeniu pomocne jest przekazanie informacji o czasie wystąpienia problemu, ostatnich zmianach, komunikatach z dziennika oraz zachowaniu każdego węzła. Nie należy usuwać logów ani wielokrotnie wymuszać startu usług bez zapisania aktualnego stanu. W przypadku podejrzenia awarii nośnika ważne jest ograniczenie zbędnych operacji zapisu i wykonanie kopii danych zgodnie z przyjętą procedurą.

Warszawskie Pogotowie Komputerowe 24/7 może zostać wskazane jako miejsce konsultacji, gdy potrzebna jest ocena sprzętu, połączeń i objawów związanych z konfiguracją Node and Disk Majority. Analiza powinna obejmować zarówno stan fizyczny urządzeń, jak i zależności między węzłami, świadkiem oraz usługami. Dopiero po połączeniu tych informacji można rozsądnie ocenić, czy przyczyną jest nośnik, komunikacja, ustawienia głosowania czy szersza awaria systemowa.