System Center dla SQL HA

System Center wspiera monitorowanie klastrów wysokiej dostępności SQL Server w środowiskach korporacyjnych.

Rola System Center w monitorowaniu SQL Server HA

System Center dla SQL HA oznacza wykorzystanie narzędzi z rodziny Microsoft System Center do obserwowania środowisk SQL Server zapewniających wysoką dostępność. Najczęściej chodzi o System Center Operations Manager (SCOM) oraz pakiety zarządzania dla SQL Server. SCOM zbiera informacje o stanie instancji, baz danych, usług SQL Server, agentów, węzłów klastra oraz mechanizmów replikacji. Na tej podstawie może generować alerty, zdarzenia i dane dotyczące trendów wydajnościowych.

Wysoka dostępność SQL Server może być realizowana między innymi przez Always On availability groups albo przez SQL Server Failover Cluster Instance. Są to różne mechanizmy i ich monitoring wymaga sprawdzania innych elementów. Availability group wykorzystuje repliki baz danych i endpointy HADR, natomiast FCI opiera się na klastrze Windows Server Failover Clustering oraz współdzielonym magazynie danych. System Center nie zastępuje tych mechanizmów, lecz nadzoruje ich działanie i sygnalizuje odchylenia od oczekiwanego stanu.

Obserwowane repliki, klastry i zależności

W przypadku Always On availability groups monitoring powinien obejmować rolę repliki, stan synchronizacji baz, tryb dostępności oraz możliwość wykonywania przełączenia. Istotne są stany takie jak synchronizing, synchronized, not synchronizing, initializing i reverting. Dla replik synchronicznych szczególne znaczenie ma informacja, czy baza pomocnicza jest zsynchronizowana z bazą podstawową. Dla replik asynchronicznych opóźnienie może być spodziewanym elementem konfiguracji, ale jego wzrost wymaga oceny względem parametrów danego środowiska.

System Center może również wykrywać problemy z usługą SQL Server, SQL Server Agentem, komunikacją między replikami oraz konfiguracją endpointu Database Mirroring. W SQL Server endpoint HADR służy do komunikacji replik Always On; jego dostępność zależy między innymi od uruchomienia usługi, reguł zapory i poprawnych uprawnień. Alert dotyczący braku komunikacji nie wskazuje automatycznie na uszkodzenie bazy. Przyczyną może być zatrzymana usługa, problem sieciowy, niedostępny port albo błąd certyfikatu używanego przez endpoint.

Dla Failover Cluster Instance trzeba sprawdzać stan zasobów klastra, nazwy sieciowe, adresy IP, zależności grup zasobów, dostęp do magazynu oraz aktualnie aktywny węzeł. Przełączenie roli SQL Server na drugi węzeł może być prawidłową reakcją na awarię, ale częste lub nieplanowane przełączenia wskazują na problem wymagający analizy. SCOM może korelować zdarzenia z wielu elementów, jednak interpretacja alertu powinna uwzględniać dzienniki SQL Server, System i FailoverClustering.

Alerty, wydajność i weryfikacja stanu

Monitoring wysokiej dostępności nie ogranicza się do sprawdzenia, czy proces sqlservr.exe działa. Działająca usługa może jednocześnie obsługiwać bazę w stanie awaryjnym, mieć narastającą kolejkę wysyłania dziennika transakcji albo utracić synchronizację z repliką. Dlatego reguły monitorujące powinny rozróżniać awarię usługi, niedostępność repliki, opóźnienie synchronizacji, brak miejsca na dysku, problemy z plikiem dziennika i długotrwałe blokady.

Do oceny Always On przydatne są widoki dynamicznego zarządzania, w szczególności sys.dm_hadr_database_replica_states, sys.dm_hadr_availability_replica_states oraz sys.availability_replicas. Dostarczają one danych o stanie baz i replik z perspektywy instancji SQL Server. Informacje o sesjach i błędach komunikacji można uzupełniać danymi z sys.dm_os_wait_stats (typ oczekiwania HADR_TRANSPORT_FLOW_CONTROL) oraz dziennika błędów SQL Server. Same zapytania nie powinny być traktowane jako zamiennik monitoringu, lecz jako sposób potwierdzenia przyczyny alertu wygenerowanego przez System Center.

SCOM pozwala centralizować alerty i przypisywać je do określonych obiektów monitorowanej infrastruktury. W praktyce ważne jest prawidłowe ustawienie progów, poziomów ważności i reguł wyciszania. Zbyt niski próg opóźnienia może generować alarmy podczas normalnych operacji, a zbyt wysoki może opóźnić reakcję na rzeczywistą utratę odporności. Każdy alert powinien być sprawdzany w kontekście topologii: liczby replik, trybu synchronicznego lub asynchronicznego, roli podstawowej oraz planowanych prac administracyjnych.

Diagnostyka incydentu w środowisku SQL Server

Analizę problemu warto rozpocząć od ustalenia, czy wystąpiła awaria samego SQL Server, problem klastra Windows, czy utrata komunikacji między replikami. Następnie należy porównać czas alertu SCOM z wpisami w SQL Server Error Log, Podglądzie zdarzeń i dziennikach FailoverClustering. W przypadku Always On trzeba sprawdzić bieżący stan każdej repliki, stan synchronizacji poszczególnych baz oraz wartości log_send_queue_size i redo_queue_size, jeżeli są dostępne w używanym widoku diagnostycznym.

Jeżeli problem dotyczy FCI, należy zweryfikować, który węzeł posiada grupę zasobów SQL Server, czy wszystkie zasoby są online oraz czy węzeł ma dostęp do wymaganych dysków. Wymuszenie przełączenia bez wcześniejszego ustalenia przyczyny może utrudnić diagnostykę i spowodować kolejne przerwanie pracy. W availability group trzeba dodatkowo odróżnić zmianę roli primary wynikającą z zaplanowanego failover od nieoczekiwanego przełączenia po utracie quorum lub komunikacji.

Po usunięciu przyczyny alert nie powinien być zamykany wyłącznie dlatego, że usługa ponownie działa. Należy potwierdzić powrót baz do oczekiwanego stanu, zakończenie synchronizacji, brak zaległych ostrzeżeń oraz poprawną ścieżkę połączeń aplikacji. Weryfikacja powinna obejmować także kopie zapasowe, zadania SQL Server Agent i monitoring pozostałych replik. Dopiero spójny obraz tych elementów pozwala uznać incydent wysokiej dostępności za zakończony.