Windows Server Failover Clustering (WSFC)

WSFC to mechanizm systemu Windows leżący u podstaw klastrów pracy awaryjnej i grup dostępności Always On.

Rola WSFC w klastrze pracy awaryjnej

Windows Server Failover Clustering (WSFC) to funkcja systemu Windows Server, która łączy kilka serwerów w logiczny klaster i nadzoruje działanie uruchomionych w nim ról. Poszczególne serwery są nazywane węzłami. Jeżeli węzeł przestanie odpowiadać, usługa klastra może przenieść określoną rolę na inny dostępny węzeł. Przenoszona rola obejmuje między innymi nazwę sieciową, adres IP, zależne usługi oraz zasoby dyskowe albo inne zasoby wymagane przez konkretną aplikację.

WSFC nie jest samą aplikacją biznesową ani mechanizmem automatycznego naprawiania każdego błędu systemu. Zapewnia koordynację stanu węzłów, wybór właściciela zasobów, wykrywanie awarii i kontrolowane przełączanie ról. Sposób działania zależy od aplikacji korzystającej z klastra. W przypadku klastra plikowego istotne są udziały i zależności magazynu, natomiast w przypadku SQL Server Always On Availability Groups WSFC dostarcza warstwę koordynacji klastra, lecz sama grupa dostępności może działać bez współdzielonego dysku danych.

Węzły, kworum i świadek klastra

Jednym z najważniejszych elementów WSFC jest kworum. Klaster musi ustalić, która część jego członków ma prawo działać. Mechanizm ten ogranicza ryzyko podziału klastra na dwie niezależne grupy, które jednocześnie próbowałyby przejąć te same role. Głosowanie zależy od liczby skonfigurowanych węzłów oraz od typu świadka. Świadkiem może być dysk świadka, udział plikowy albo świadek w chmurze. Wybór konfiguracji powinien uwzględniać topologię awarii, dostępność sieci i sposób rozmieszczenia serwerów.

WSFC wykorzystuje między innymi pojęcia głosów, bieżącej konfiguracji kworum i dynamicznego kworum. Dynamiczne kworum pozwala zmieniać udział poszczególnych węzłów w głosowaniu, aby klaster mógł kontynuować pracę po określonych awariach. Nie oznacza to jednak, że dowolna liczba uszkodzonych serwerów zostanie automatycznie obsłużona. Błąd sieci między lokalizacjami, utrata świadka, niedostępność kontrolera domeny lub niespójna konfiguracja mogą doprowadzić do zatrzymania zasobów mimo sprawności części maszyn. Dlatego analiza WSFC obejmuje zarówno stan serwerów, jak i stan sieci oraz magazynu.

Role klastra, zależności i przełączanie usług

W klastrze WSFC zasoby są grupowane w role, dawniej określane także jako grupy zasobów. Rola może zawierać nazwę sieciową, adresy IP, usługi systemowe, dyski klastra oraz zasoby specyficzne dla aplikacji. Zależności określają kolejność uruchamiania i zatrzymywania elementów. Jeżeli na przykład usługa wymaga określonego woluminu albo nazwy sieciowej, brak tego zasobu może uniemożliwić pełne uruchomienie roli. Samo przeniesienie grupy na inny węzeł nie gwarantuje więc dostępności aplikacji, jeśli zależny element pozostaje niedostępny.

Stan klastra można sprawdzać z użyciem narzędzi PowerShell dostarczanych z rolą Failover Clustering. Polecenie Get-ClusterNode pokazuje stan węzłów, Get-ClusterGroup prezentuje role i ich właścicieli, a Get-ClusterResource pozwala przejrzeć zasoby oraz ich bieżący stan. Informacje o konfiguracji kworum zwraca Get-ClusterQuorum. Do kontroli gotowości konfiguracji służy Test-Cluster, natomiast szczegółowe dzienniki klastra można zebrać poleceniem Get-ClusterLog. Wyniki tych poleceń należy interpretować razem z Podglądem zdarzeń, szczególnie z dziennikami związanymi z FailoverClustering, systemem, siecią i magazynem.

Diagnostyka awarii WSFC w środowisku serwerowym

Diagnostykę rozpoczyna się od ustalenia, czy problem dotyczy pojedynczego węzła, komunikacji między węzłami, kworum, magazynu czy konkretnej roli. Warto sprawdzić, czy węzły widzą się po wymaganych interfejsach sieciowych, czy rozwiązywanie nazw DNS zwraca prawidłowe adresy oraz czy usługa Cluster Service działa na wszystkich odpowiednich serwerach. W klastrach korzystających ze współdzielonego magazynu trzeba dodatkowo zweryfikować dostęp do dysków, rezerwacje SCSI, ścieżki MPIO i błędy kontrolera lub macierzy. W klastrach SQL Server należy oddzielić stan WSFC od stanu instancji SQL Server, replik i punktów końcowych Always On.

Typowym błędem diagnostycznym jest uznanie komunikatu o przełączeniu roli za przyczynę awarii. Taki wpis często opisuje jedynie skutek wcześniejszego zdarzenia, na przykład utraty odpowiedzi węzła, zerwania ścieżki do magazynu albo niespełnienia zależności zasobu. Należy porównać znaczniki czasu w logach wszystkich węzłów i ustalić pierwsze zdarzenie poprzedzające failover. Trzeba też sprawdzić, czy przełączenie było automatyczne, ręczne, czy wywołane przez politykę restartu zasobu. Po zmianach konfiguracji zasadna jest ponowna walidacja klastra narzędziem Test-Cluster, z uwzględnieniem zaleceń dotyczących konkretnej roli i wersji Windows Server.