Monitoring replikacji

Monitoring replikacji to nadzór nad opóźnieniem i błędami agentów synchronizujących dane między serwerami.

Co obejmuje monitoring replikacji danych

Monitoring replikacji to ciągła obserwacja procesu kopiowania lub synchronizowania danych pomiędzy serwerem źródłowym a jednym albo większą liczbą serwerów docelowych. Sprawdza się nie tylko, czy agent replikacji działa, lecz także czy dane są dostarczane w oczekiwanym czasie i w poprawnej kolejności. Podstawowym parametrem jest opóźnienie replikacji, czyli różnica między momentem zapisania zmiany na źródle a momentem jej zastosowania na serwerze odbiorczym. W zależności od architektury może być mierzone jako czas, liczba nieprzetworzonych rekordów, rozmiar kolejki albo pozycja dziennika zmian.

Równie ważne jest rozróżnienie między replikacją aktywną a pozornie działającą. Agent może pozostawać uruchomiony, a jednocześnie nie przesyłać nowych zmian z powodu błędu uwierzytelniania, braku miejsca, zerwanego połączenia lub zatrzymania kolejki. Dlatego system monitorujący powinien kontrolować stan procesu, wiek ostatniej poprawnie zastosowanej zmiany, liczbę błędów, liczbę ponowień oraz aktualny rozmiar zaległości. Sam komunikat „usługa działa” nie potwierdza prawidłowego przepływu danych.

Opóźnienie, kolejki i kompletność synchronizacji

Opóźnienie należy oceniać w odniesieniu do charakteru danych i przyjętego trybu pracy. Replikacja asynchroniczna może przez pewien czas wykazywać niezerową zwłokę, ponieważ zapis na serwerze źródłowym nie musi czekać na potwierdzenie odbiorcy. Nie oznacza to automatycznie awarii. Problem zaczyna się wtedy, gdy opóźnienie systematycznie rośnie, przekracza ustalony próg albo uniemożliwia wykorzystanie serwera docelowego do odczytu, raportowania lub przełączenia awaryjnego.

W praktyce analizuje się zarówno średnią, jak i wartości maksymalne. Krótkie skoki mogą wynikać z dużej transakcji, chwilowego obciążenia dysku lub przerwy sieciowej, natomiast stały wzrost kolejki wskazuje na trwającą niewydolność procesu. Należy porównywać tempo napływu zmian z tempem ich wysyłania i zastosowania. Jeżeli źródło generuje zmiany szybciej, niż agent potrafi je przesłać, zaległość będzie narastać nawet przy poprawnym działaniu wszystkich procesów. Kontrola kompletności obejmuje także wykrywanie pominiętych zakresów, powtórzonych operacji i rozbieżności sum kontrolnych, jeżeli dana implementacja je udostępnia.

Źródła alarmów i ścieżka analizy błędu

Skuteczny monitoring łączy dane z kilku miejsc: status agenta, dzienniki aplikacyjne, systemowe zdarzenia usług, statystyki sieciowe oraz informacje o wykorzystaniu procesora, pamięci i magazynu danych. W logach szczególnie istotne są kody błędów, identyfikatory sesji, nazwy źródła i odbiorcy, znaczniki czasu oraz numer lub zakres zmiany, której nie udało się przetworzyć. Komunikat powinien pozwalać ustalić, czy problem wystąpił podczas odczytu zmian, transmisji, zapisu do kolejki czy zastosowania danych po stronie odbiorczej.

Alarm powinien zawierać próg, czas trwania i kontekst, aby odróżnić incydent od chwilowego zakłócenia. Przykładowo osobno można zgłaszać brak postępu przez określony czas, przekroczenie dopuszczalnego opóźnienia, zatrzymanie agenta, wzrost kolejki oraz powtarzający się błąd tej samej zmiany. Po otrzymaniu alarmu najpierw porównuje się czas ostatniego sukcesu z czasem ostatniej próby, następnie sprawdza dostępność obu serwerów, połączenie i miejsce na dysku. Dopiero później należy oceniać konflikt danych lub uszkodzenie kolejki. Taka kolejność ogranicza ryzyko usunięcia śladów potrzebnych do ustalenia przyczyny.

Weryfikacja połączenia i przywrócenie prawidłowego przepływu

Diagnostyka powinna rozpocząć się od ustalenia, czy zmiany są nadal zapisywane na serwerze źródłowym oraz czy agent posiada dostęp do właściwego dziennika lub kolejki. Następnie sprawdza się rozwiązywanie nazw, trasę sieciową, port używany przez konkretny mechanizm replikacji, ważność poświadczeń i uprawnienia konta usługi. Jeżeli połączenie jest poprawne, trzeba przeanalizować ograniczenia odbiorcy: brak wolnego miejsca, blokady plików, niedostępność magazynu, zbyt wolne operacje wejścia-wyjścia albo odrzucenie zmiany z powodu niespójnego schematu.

Po usunięciu przyczyny nie wystarczy skasować alarmu. Należy potwierdzić, że liczba zaległych zmian maleje, znacznik ostatniego sukcesu przesuwa się naprzód, a log nie zawiera nowych błędów. Jeżeli agent wykonuje automatyczne ponowienia, trzeba sprawdzić, czy nie powtarza bez końca tej samej nieprzetwarzalnej operacji. W przypadku rozbieżności danych bezpieczna procedura wymaga ustalenia zakresu problemu, zachowania logów i użycia mechanizmu ponownej synchronizacji właściwego dla zastosowanego rozwiązania. Na komputerze przeznaczonym do obsługi narzędzi administracyjnych warto dodatkowo kontrolować poprawność czasu systemowego, ponieważ niespójne znaczniki czasu utrudniają ocenę opóźnienia i kolejności zdarzeń.