Witness (File Share Witness)

File Share Witness to udział sieciowy pełniący rolę świadka w kworum klastra bez potrzeby dysku współdzielonego.

Rola File Share Witness w kworum klastra

File Share Witness, określany także jako świadek udziału plikowego, jest zasobem używanym przez Windows Server Failover Clustering do rozstrzygania, która część klastra ma uzyskać quorum. Nie przechowuje danych aplikacji, nie jest dodatkowym węzłem obliczeniowym i nie wykonuje przełączania usług. Jego zadaniem jest dostarczenie dodatkowego głosu w głosowaniu nad utrzymaniem pracy klastra. Udział sieciowy znajduje się poza węzłami klastra, dzięki czemu może pomóc w rozstrzygnięciu sytuacji, w której węzły utraciły wzajemną łączność.

Quorum jest mechanizmem ochronnym. Klaster musi mieć pewność, że aktywna jest tylko jedna uprawniona grupa węzłów. Bez takiego zabezpieczenia mogłoby dojść do podziału klastra na niezależne części, z których każda próbowałaby uruchamiać te same zasoby. Taki stan jest nazywany split-brain. File Share Witness nie naprawia połączenia między serwerami, lecz wpływa na wynik głosowania, gdy dostęp do udziału oraz komunikacja z pozostałymi składnikami klastra pozwalają jednoznacznie określić stronę dysponującą quorum.

Wymagania dotyczące udziału sieciowego

Świadek udziału plikowego musi być dostępny przez sieć dla wszystkich węzłów, które mają brać udział w mechanizmie quorum. W praktyce konfiguruje się udział SMB na oddzielnym serwerze plików albo innym odpowiednio przygotowanym systemie Windows. Udział powinien być niezależny od węzłów klastra. Umieszczenie świadka na jednym z serwerów należących do tego samego klastra osłabiałoby jego wartość, ponieważ awaria tego serwera mogłaby jednocześnie odebrać węzeł oraz głos świadka.

Ważna jest zarówno dostępność ścieżki sieciowej, jak i poprawna autoryzacja. Konto komputera klastra musi mieć możliwość korzystania z udziału oraz zapisu wymaganych informacji. Należy sprawdzić uprawnienia udziału SMB i uprawnienia systemu plików NTFS, ponieważ ograniczenie któregokolwiek z tych poziomów może uniemożliwić użycie świadka. Sama możliwość otwarcia udziału z konta administratora nie potwierdza poprawności konfiguracji: usługa klastra korzysta z własnego kontekstu zabezpieczeń.

Serwer udostępniający File Share Witness powinien mieć stabilną nazwę DNS, przewidywalną adresację oraz łączność z odpowiednimi sieciami klastra. Problemy z rozpoznawaniem nazwy, filtrowanie ruchu SMB, niedostępny port TCP 445, błędny czas systemowy albo nieprawidłowe poświadczenia mogą powodować utratę dostępu do świadka. W efekcie klaster może przejść w stan bez quorum, nawet jeśli same węzły nadal działają.

Głosy, tryby quorum i zachowanie podczas awarii

W Windows Server Failover Clustering każdy węzeł ma domyślnie głos, a świadek może dostarczyć dodatkowy głos. Sposób liczenia zależy od liczby węzłów oraz wybranego modelu quorum. W konfiguracji Node and File Share Majority o wyniku decyduje większość głosów węzłów i udziału plikowego. W większych środowiskach klaster może używać także modelu Dynamic Majority, w którym głosy węzłów są dynamicznie uwzględniane, oraz Dynamic Witness, który pozwala systemowi dostosowywać udział głosu świadka do bieżącej liczby głosujących węzłów.

Świadek nie powinien być traktowany jako zwykła kopia zapasowa ani jako repozytorium plików użytkownika. Utrata jego dostępności może zmienić wynik głosowania, ale nie oznacza automatycznie uszkodzenia danych na woluminach klastra. Z kolei dostępny udział nie zastępuje sprawnej komunikacji klastra między węzłami. Ostateczna decyzja zależy od całej topologii, stanu sieci, liczby aktywnych głosów i aktualnej konfiguracji quorum.

Diagnostyka powinna obejmować właściwości klastra, bieżący model quorum, status zasobu świadka, zdarzenia w dziennikach FailoverClustering oraz dostęp do udziału z użyciem konta komputera klastra. Przydatne są także testy rozpoznawania nazwy, połączenia SMB i uprawnień. Należy odróżnić chwilową utratę łączności od trwałego błędu konfiguracji. Sam komunikat o niedostępności świadka nie wskazuje jeszcze, czy przyczyną jest serwer plików, DNS, zapora, uprawnienia, awaria sieci czy nieprawidłowy model quorum.

Znaczenie konfiguracji świadka dla diagnostyki klastra

Problemy z File Share Witness często ujawniają się dopiero podczas awarii jednego z węzłów albo podczas przerwy w komunikacji między lokalizacjami. Dlatego konfigurację należy oceniać w scenariuszach awaryjnych, a nie tylko na podstawie normalnego działania usług. Sprawdzenia wymagają między innymi niezależność serwera świadka, dostępność SMB, uprawnienia konta klastra, rozwiązywanie nazwy oraz zgodność ustawień z liczbą węzłów. Każda zmiana nazwy serwera, domeny, udziału lub zasad zapory może wpłynąć na działanie mechanizmu quorum.

Przy analizie zdarzeń trzeba porównać czas utraty świadka z informacjami o stanie sieci i węzłów. Jeżeli udział jest niedostępny dla wszystkich węzłów, problem leży zwykle poza samym zasobem klastra. Jeżeli jeden węzeł nie może skorzystać ze świadka, a pozostałe mają dostęp, należy sprawdzić lokalną trasę sieciową, rozpoznawanie nazwy, reguły zapory i uprawnienia. Weryfikacja powinna również potwierdzić, że wskazany udział nadal istnieje i nie został przypadkowo przeniesiony, przemianowany albo objęty inną polityką dostępu.

Naprawa błędu wymaga zachowania ostrożności, ponieważ wymuszenie uruchomienia klastra bez quorum może mieć skutki operacyjne. Najpierw należy ustalić, które węzły są rzeczywiście dostępne, jaki jest aktualny model quorum i czy istnieje ryzyko podziału komunikacyjnego. Dopiero potem można korygować uprawnienia, przywracać łączność z udziałem lub zmieniać konfigurację świadka zgodnie z dokumentacją konkretnej wersji Windows Server. Błędna zmiana głosów albo ręczne wymuszenie quorum bez pełnego obrazu sytuacji może ukryć przyczynę problemu i zwiększyć ryzyko niespójnego działania usług.