Node and File Share Majority

Node and File Share Majority to model kworum, w którym rolę świadka pełni udział sieciowy zamiast dysku współdzielonego.

Node and File Share Majority jako model kworum

Node and File Share Majority to tryb kworum używany w klastrze pracy awaryjnej Windows Server Failover Clustering, w którym głosy należą zarówno do węzłów, jak i do świadka w postaci udziału plikowego. Udział sieciowy pełni funkcję dodatkowego głosu arbitrażowego. Nie jest to współdzielony dysk przeznaczony do przechowywania baz danych, maszyn wirtualnych ani plików aplikacji. Jego zadaniem jest pomóc klastrowi ustalić, która część infrastruktury może zachować prawo do uruchamiania zasobów po utracie komunikacji między węzłami.

Każdy węzeł klastra może mieć głos, a file share witness otrzymuje jeden głos w mechanizmie kworum. Klaster pozostaje online wtedy, gdy dostępna część głosów przekracza połowę wszystkich aktualnie uwzględnianych głosów. W praktyce udział plikowy jest szczególnie przydatny przy parzystej liczbie węzłów, ponieważ może rozstrzygnąć remis między dwiema równolicznymi częściami klastra. Nie zastępuje on jednak poprawnej komunikacji klastrowej ani nie naprawia awarii sieci, kontrolera domeny, systemu plików lub samej aplikacji.

Rola świadka plikowego w rozstrzyganiu podziału klastra

Najważniejszym zastosowaniem Node and File Share Majority jest ochrona przed scenariuszem split-brain, czyli sytuacją, w której odseparowane od siebie węzły uznają jednocześnie, że mają prawo uruchamiać te same zasoby. Taki stan mógłby doprowadzić do równoczesnego zapisu danych przez dwie części klastra. Głos świadka pomaga wskazać stronę, która zachowa kworum, podczas gdy druga część zostanie zatrzymana albo pozbawiona możliwości uruchamiania zasobów klastrowych.

Udział plikowy nie działa jak klasyczny magazyn współdzielony. Wykorzystywany jest do utrzymywania informacji potrzebnych do arbitrażu kworum, a nie do obsługi zwykłego wejścia i wyjścia aplikacji. Z tego powodu jego pojemność nie jest podstawowym parametrem projektu. Istotniejsze są dostępność udziału, możliwość nawiązania połączenia SMB, prawidłowe uprawnienia konta klastra oraz niezależność lokalizacji świadka od węzłów, które mają wzajemnie rozstrzygać konflikt.

Warunki poprawnego działania Node and File Share Majority

Świadek powinien znajdować się w lokalizacji, która nie ulegnie tej samej awarii co jeden z głównych węzłów. Jeśli udział plikowy jest umieszczony na serwerze podłączonym do tej samej szafy, przełącznika, zasilania lub segmentu sieci co jeden z węzłów, awaria wspólnego elementu może jednocześnie odebrać klastrowi dostęp do świadka. Wtedy konfiguracja formalnie zawiera file share witness, ale jego wartość arbitrażowa w konkretnym scenariuszu awarii może być ograniczona.

Wymagane jest również zapewnienie dostępu do udziału dla mechanizmów klastra. Należy sprawdzić rozwiązywanie nazwy serwera świadka, trasę sieciową, reguły zapory, dostępność protokołu SMB oraz uprawnienia udziału i systemu plików. Sama możliwość otwarcia katalogu z poziomu konta administratora nie potwierdza jeszcze, że klaster może korzystać ze świadka. Diagnostyka powinna obejmować stan zasobu świadka, zdarzenia Failover Clustering oraz komunikaty dotyczące utraty głosu, niedostępności udziału i zmiany stanu kworum.

Ograniczenia projektowe i diagnostyka klastra

Node and File Share Majority nie jest uniwersalnym rozwiązaniem dla każdego układu węzłów. Dobór modelu kworum zależy od liczby węzłów, rozkładu awarii, lokalizacji ośrodków, jakości połączeń między nimi oraz tego, czy środowisko ma działać także po utracie całej lokalizacji. W nowszych wersjach Windows Server klaster może dynamicznie zarządzać głosami węzłów, dlatego analiza nie powinna opierać się wyłącznie na nominalnej liczbie komputerów. Trzeba sprawdzić bieżący stan głosów i konfigurację konkretnego klastra.

Podczas diagnostyki należy rozdzielić trzy różne problemy: awarię samego węzła, utratę komunikacji między węzłami oraz brak dostępu do file share witness. Czasowa niedostępność udziału nie musi oznaczać awarii danych aplikacyjnych, ale może obniżyć liczbę dostępnych głosów poniżej wymaganego progu. Z kolei przywrócenie połączenia z udziałem nie gwarantuje automatycznego odtworzenia poprawnego działania zasobów, jeżeli wcześniej wystąpiły błędy zależności, problemy z usługą klastra albo uszkodzenie konfiguracji. Ocena powinna więc obejmować topologię sieci, uprawnienia, dzienniki zdarzeń i rzeczywisty stan zasobów, a nie tylko obecność katalogu udostępnionego w sieci.