Klaster SQL Server

Klaster SQL Server to konfiguracja wysokiej dostępności, w której instancja może być przejęta przez inny węzeł po awarii.

Architektura klastra SQL Server

Klaster SQL Server, określany jako Failover Cluster Instance (FCI), jest konfiguracją wysokiej dostępności opartą na mechanizmie Windows Server Failover Clustering. Instancja SQL Server działa jako zasób klastra, który może zostać uruchomiony na jednym z kilku węzłów. W danym momencie aktywna jest tylko jedna kopia tej konkretnej instancji FCI, natomiast pozostałe węzły pozostają gotowe do przejęcia jej zasobów po wykryciu awarii albo podczas zaplanowanego przełączenia.

Instancja klastrowa korzysta ze wspólnej przestrzeni dyskowej dostępnej dla węzłów, ponieważ wszystkie węzły muszą mieć dostęp do tych samych plików baz danych, dzienników transakcji i plików systemowych instancji. Z punktu widzenia klienta FCI jest prezentowana przez wirtualną nazwę sieciową i przypisany adres IP. Po zmianie aktywnego węzła nazwa instancji pozostaje taka sama, dlatego aplikacja nie musi wskazywać bezpośrednio fizycznej nazwy komputera, który aktualnie obsługuje połączenie.

Przełączenie instancji po awarii węzła

Mechanizm klastra monitoruje stan węzłów oraz zasobów wymaganych przez SQL Server. Nadzorowane mogą być między innymi usługi instancji, SQL Server Agent, zasoby dyskowe, adres sieciowy i nazwa sieciowa. Jeżeli klaster stwierdzi, że aktywny węzeł albo jeden z jego krytycznych zasobów nie działa poprawnie, może zatrzymać zasoby na tym węźle i uruchomić instancję na innym węźle. Takie działanie nazywa się failover, czyli przełączeniem awaryjnym.

Podczas przełączenia istniejące połączenia klientów zostają przerwane. Po uruchomieniu instancji na innym węźle aplikacja musi nawiązać połączenie ponownie, o ile obsługuje retry logic albo mechanizm ponawiania połączeń. Transakcje, które nie zostały zatwierdzone przed awarią, mogą zostać wycofane podczas odzyskiwania bazy danych. SQL Server wykorzystuje dziennik transakcji do wykonania fazy redo dla operacji zatwierdzonych oraz undo dla operacji niedokończonych.

Failover nie oznacza, że awaria nie powoduje żadnej przerwy. Nowy węzeł musi przejąć zasoby, uruchomić usługi, otworzyć pliki baz danych i przeprowadzić odzyskiwanie. Rzeczywisty czas niedostępności zależy między innymi od rodzaju awarii, szybkości systemu dyskowego, wielkości operacji wymagających odtworzenia oraz konfiguracji klienta. Sama obecność drugiego węzła nie gwarantuje poprawnego działania, jeżeli wspólna pamięć masowa albo sieć klastra jest niedostępna.

Quorum, zależności i ograniczenia rozwiązania

Windows Server Failover Clustering wykorzystuje quorum do podjęcia decyzji, która część klastra może kontynuować pracę. Quorum zapobiega sytuacji, w której odizolowane od siebie grupy węzłów próbowałyby jednocześnie uruchomić tę samą instancję i zapisywać dane niezależnie. Przy ocenie stanu brane są pod uwagę głosy węzłów oraz, zależnie od modelu konfiguracji, dodatkowy głos świadka. Nieprawidłowo zaprojektowane quorum może doprowadzić do zatrzymania zasobów, nawet gdy sam SQL Server nie ma błędu.

Klaster SQL Server nie jest kopią zapasową. W konfiguracji FCI węzły korzystają z tych samych plików baz danych, więc usunięcie danych, błędna aktualizacja, uszkodzenie logiczne albo zaszyfrowanie plików może dotyczyć całej dostępnej instancji. Do odtwarzania danych po takich zdarzeniach potrzebne są niezależne kopie zapasowe oraz sprawdzona procedura przywracania. Failover chroni przede wszystkim przed awarią określonego węzła lub części jego lokalnych zasobów, a nie przed każdym rodzajem utraty danych.

FCI należy odróżnić od Always On Availability Groups w SQL Server. FCI przełącza jedną instancję wraz z jej bazami i wykorzystuje wspólną pamięć masową, natomiast Availability Groups utrzymują repliki baz na osobnych instalacjach SQL Server i synchronizują zmiany przez sieć. Są to różne mechanizmy o odmiennych wymaganiach, sposobie przełączania i modelu ochrony. Nie powinno się więc utożsamiać klastra instancji z replikacją baz danych ani zakładać, że każda konfiguracja Always On działa tak samo jak FCI.

Diagnostyka konfiguracji i przywracanie działania

Analizę problemu rozpoczyna się od ustalenia, czy niedostępność dotyczy samego silnika SQL Server, zasobu klastra, pamięci masowej, komunikacji między węzłami czy aplikacji klienckiej. Należy porównać dzienniki SQL Server z wpisami Failover Cluster Manager i zdarzeniami systemu Windows. Istotne są informacje o utracie quorum, nieudanym montowaniu dysku, błędzie zależności zasobu, problemach z nazwą sieciową oraz automatycznym zatrzymaniu usługi.

Po przełączeniu trzeba sprawdzić, czy instancja działa na oczekiwanym węźle, czy wszystkie bazy są dostępne i czy SQL Server zakończył odzyskiwanie bez błędów. Weryfikacji wymagają również ścieżki plików danych i logów, uprawnienia kont usług, połączenie z magazynem współdzielonym oraz rozwiązywanie wirtualnej nazwy DNS. Osobno należy przetestować połączenie z aplikacji, ponieważ poprawnie działający silnik nie eliminuje problemów z pulą połączeń, zapamiętanym adresem fizycznego węzła albo brakiem obsługi ponownego połączenia.

Przed zmianą konfiguracji klastra powinno się zabezpieczyć dzienniki zdarzeń i ustalić stan baz, aby nie utracić informacji potrzebnych do odtworzenia przebiegu awarii. Naprawa może obejmować przywrócenie zależności zasobów, korektę konfiguracji sieci lub magazynu, odtworzenie usługi SQL Server oraz kontrolowane przeniesienie grupy zasobów na właściwy węzeł. Każde przełączenie i test należy wykonywać z uwzględnieniem wpływu na aktywne połączenia oraz proces odzyskiwania transakcji.