Monitoring grupy dostępności

Monitoring grupy dostępności to nadzór nad stanem replik, opóźnieniem synchronizacji i gotowością do przełączenia.

Zakres monitorowania grupy dostępności

Monitoring grupy dostępności obejmuje obserwację stanu replik, przepływu danych między repliką podstawową i pomocniczymi oraz warunków wymaganych do bezpiecznego przełączenia ról. W rozwiązaniu Always On Availability Groups firmy Microsoft każda replika przechowuje własną kopię baz danych należących do grupy. Replika podstawowa przyjmuje operacje zapisu, a repliki pomocnicze otrzymują rekordy dziennika transakcji i odtwarzają je w swoich kopiach baz.

Podstawowym celem monitoringu jest szybkie wykrycie sytuacji, w której kopia pomocnicza przestaje nadążać za podstawową, nie może wysyłać potwierdzeń albo utraciła połączenie z pozostałymi elementami konfiguracji. Sam fakt, że replika jest oznaczona jako uruchomiona, nie potwierdza jeszcze aktualności danych. Potrzebne jest sprawdzenie stanu synchronizacji baz, zaległości dziennika oraz gotowości do wykonania określonego rodzaju przełączenia.

Repliki, synchronizacja i zaległość dziennika

W monitoringu rozróżnia się między stanem repliki a stanem poszczególnych baz danych w grupie. Replika może być dostępna, lecz konkretna baza może znajdować się w stanie synchronizacji, niesynchronizowania albo oczekiwania na ponowne uruchomienie procesu przesyłania. Istotne są również role replik, ich tryb dostępności oraz tryb synchronizacji. Tryb synchroniczny wymaga potwierdzenia dostarczenia i zapisania danych dziennika po stronie pomocniczej przed uznaniem operacji za zakończoną, natomiast tryb asynchroniczny nie czeka na takie potwierdzenie przy każdym zapisie na replice podstawowej.

Ważnym wskaźnikiem jest ilość dziennika transakcji, która została wygenerowana na replice podstawowej, ale nie została jeszcze wysłana, odebrana, zapisana lub odtworzona na replice pomocniczej. W SQL Server te etapy są rozdzielone: dziennik może oczekiwać na wysłanie, znajdować się w kolejce odbiorczej albo czekać na odtworzenie. Duża kolejka wysyłania wskazuje zwykle na problem z transportem lub wydajnością odbiorcy, a duża kolejka odtwarzania może wynikać z obciążenia dysku, blokad, niewystarczających zasobów procesora albo dużej liczby operacji wymagających zastosowania.

Opóźnienie danych a możliwość przełączenia

Opóźnienie synchronizacji nie powinno być oceniane wyłącznie na podstawie pojedynczego pomiaru. Krótkotrwały wzrost kolejki może pojawić się podczas intensywnej operacji zapisu i zniknąć po jej zakończeniu. Trwałe narastanie zaległości oznacza jednak, że replika pomocnicza nie przetwarza dziennika z szybkością wystarczającą do utrzymania aktualnej kopii. Monitoring powinien rejestrować trend, czas trwania problemu oraz jego wpływ na możliwość odczytu i przełączenia.

Gotowość do przełączenia zależy od rodzaju operacji. Przełączenie planowane powinno być wykonywane wtedy, gdy odpowiednia replika pomocnicza jest zsynchronizowana i spełnia wymagania konfiguracji. W trybie synchronicznym możliwe jest przełączenie bez utraty zatwierdzonych transakcji, jeśli wszystkie wymagane warunki są spełnione. Przełączenie wymuszone w sytuacji awaryjnej może odbyć się przy stanie niesynchronizowanym, ale wtedy istnieje ryzyko utraty transakcji, które nie dotarły jeszcze do repliki pomocniczej. Monitoring powinien więc oddzielnie sygnalizować dostępność usługi, stan synchronizacji i ryzyko utraty danych.

Źródła informacji i reakcja na alarm

Stan grupy można analizować za pomocą panelu Always On Availability Groups w SQL Server Management Studio, widoków dynamicznego zarządzania oraz dzienników SQL Server i systemu operacyjnego. Szczególnie użyteczne są informacje zwracane przez widoki sys.dm_hadr_availability_replica_states, sys.dm_hadr_database_replica_states i sys.availability_replicas. Pozwalają one zestawić role replik, stan połączenia, stan synchronizacji oraz szczegóły dotyczące baz należących do grupy. Przy interpretacji wyników trzeba uwzględnić, z której repliki wykonano zapytanie, ponieważ nie wszystkie informacje o pozostałych replikach są dostępne w identycznym zakresie z każdego węzła.

Alarm powinien prowadzić do ustalenia konkretnej przyczyny, a nie do automatycznego przełączenia roli. Najpierw sprawdza się łączność między replikami, stan punktów końcowych database mirroring, błędy w dzienniku SQL Server, obciążenie procesora, opóźnienia magazynu danych oraz dostępne miejsce na woluminach. Następnie porównuje się kolejkę wysyłania i odtwarzania oraz ustala, czy problem dotyczy jednej bazy, całej repliki, czy komunikacji między serwerami. Diagnostyka i naprawa środowiska serwerowego wymagają zachowania spójności konfiguracji, ponieważ pochopne usunięcie bazy z grupy albo wymuszenie przełączenia może zwiększyć zakres niespójności i utrudnić późniejszą synchronizację.