Windows Server i SQL Server Cluster

Klaster Windows Server i SQL Server współpracują przez WSFC, zapewniając mechanizm przełączania awaryjnego.

Rola WSFC w klastrze Windows Server i SQL Server

Windows Server Failover Clustering (WSFC) jest platformą wysokiej dostępności w systemie Windows Server. Tworzy grupę współpracujących węzłów, które monitorują stan zasobów i mogą przenieść określoną rolę na inny węzeł po wykryciu awarii. W przypadku SQL Server WSFC nie zastępuje samego silnika bazy danych. Zapewnia mechanizm koordynacji węzłów, głosowania, uruchamiania zasobów oraz przełączania roli, natomiast sposób przechowywania i udostępniania danych zależy od wybranej konfiguracji SQL Server.

Najczęściej spotykane są dwa rozwiązania klastrowe SQL Server. SQL Server Failover Cluster Instance (FCI) korzysta ze wspólnego magazynu danych, na przykład klastra dysków udostępnianych wszystkim węzłom. W danym momencie aktywna instancja działa tylko na jednym węźle, a po awarii usługi może zostać uruchomiona na innym. Always On Availability Groups używa osobnych kopii baz na poszczególnych replikach i wykorzystuje WSFC do utrzymania członkostwa oraz koordynacji pracy grupy dostępności. Te mechanizmy nie powinny być utożsamiane, ponieważ mają inne wymagania dotyczące magazynu, replikacji i procedury odtwarzania.

Przełączanie awaryjne, quorum i zasoby klastra

WSFC podejmuje decyzje na podstawie stanu węzłów i zasady quorum. Quorum ma zapobiegać sytuacji, w której odizolowane części klastra uznają jednocześnie, że powinny obsługiwać tę samą rolę. Konfiguracja głosów obejmuje węzły oraz, zależnie od modelu, dodatkowy głos świadka. Świadkiem może być zasób dyskowy, udział plikowy albo świadek w chmurze, o ile dana konfiguracja i wersja Windows Server go obsługują. Utrata quorum powoduje zatrzymanie lub ograniczenie działania ról klastrowych, dlatego liczba głosów i sposób ich rozmieszczenia muszą odpowiadać topologii infrastruktury.

Rola SQL Server składa się z zasobów zarządzanych przez klaster, takich jak usługa SQL Server, usługa SQL Server Agent, nazwa sieciowa, adres IP i zasoby magazynu wymagane przez FCI. Zależności między zasobami określają kolejność uruchamiania i zatrzymywania. Klient powinien łączyć się z nazwą sieciową instancji lub skonfigurowanym listenerem, a nie ze stałą nazwą aktualnie aktywnego węzła. Podczas przełączenia adres lub nazwa punktu dostępu musi zostać prawidłowo zarejestrowana w DNS, a aplikacja powinna obsługiwać ponowienie połączenia po krótkiej przerwie.

Różnica między FCI a Always On Availability Groups

W SQL Server FCI instancja przechowuje pliki baz na wspólnym magazynie. Przełączenie powoduje uruchomienie tej samej instancji na innym węźle, więc dane pozostają w jednym współdzielonym miejscu. Taka architektura nie tworzy niezależnej kopii plików baz na każdym węźle. Awaria wspólnego magazynu może więc wpłynąć na wszystkie węzły FCI, nawet jeśli system operacyjny każdego z nich działa poprawnie. Diagnostyka musi zatem obejmować ścieżki dysków, stan zasobów magazynu, sterowniki, sieć i dzienniki systemowe.

Availability Groups działają inaczej: baza podstawowa jest synchronizowana z bazami pomocniczymi na innych replikach. Tryb synchroniczny pozwala na automatyczne przełączenie tylko wtedy, gdy spełnione są wymagania dotyczące synchronizacji, konfiguracji replik i dostępności właściwego punktu dostępu. Tryb asynchroniczny ogranicza opóźnienia pracy, ale przy awarii może wystąpić utrata ostatnich transakcji, które nie dotarły jeszcze do repliki. Samo istnienie kilku serwerów WSFC nie gwarantuje więc bezstratnego przełączenia ani automatycznego odtworzenia każdej aplikacji.

Diagnostyka stanu węzłów i instancji SQL Server

Podstawowa kontrola powinna rozpocząć się od sprawdzenia, czy wszystkie węzły mają stan Up, czy grupa klastra posiada quorum oraz czy zasoby roli SQL Server są online. Administrator może użyć narzędzi PowerShell, między innymi poleceń Get-ClusterNode, Get-ClusterGroup i Get-ClusterResource. Do zebrania dzienników klastra służy Get-ClusterLog -UseLocalTime. Wyniki należy porównać z dziennikiem systemowym Windows oraz z plikami ERRORLOG instancji SQL Server, ponieważ błąd usługi, problem DNS, utrata ścieżki do magazynu i utrata quorum mogą wystąpić w różnej kolejności.

W SQL Server warto sprawdzić stan endpointów i sesji replik, stan synchronizacji baz, opóźnienie przesyłania logu oraz przyczynę ostatniego przełączenia. Należy też zweryfikować konta usług, uprawnienia do zasobów, zaporę sieciową, rozpoznawanie nazw i poprawność certyfikatów lub innych mechanizmów używanych przez skonfigurowane endpointy. Każde planowane przełączenie powinno być testowane osobno dla instancji, baz danych i aplikacji klienckiej. Po awarii trzeba potwierdzić nie tylko uruchomienie roli na nowym węźle, lecz także możliwość wykonania połączenia, odczytu i zapisu oraz prawidłowego powrotu do stanu stabilnego.