Restore w środowisku HA

Restore w środowisku HA musi być skoordynowany z mechanizmem wysokiej dostępności, by uniknąć konfliktu ról.

Restore w środowisku wysokiej dostępności

Restore w środowisku HA (High Availability) oznacza odtworzenie danych, konfiguracji albo całej usługi w taki sposób, aby działający mechanizm wysokiej dostępności nie uruchomił równocześnie dwóch instancji pełniących tę samą rolę. W zwykłym systemie można zatrzymać usługę, odtworzyć kopię i ponownie ją uruchomić. W klastrze taki przebieg wymaga wcześniejszego ustalenia, który węzeł jest aktywny, który pozostaje zapasowy oraz który komponent ma prawo przydzielić adres usługi, zasób dyskowy lub ruch klientów.

Przed rozpoczęciem odtwarzania administrator powinien określić zakres operacji: pojedynczy plik, bazę danych, wolumen, maszynę wirtualną, konfigurację usługi czy cały węzeł. Należy także sprawdzić czas wykonania kopii, jej spójność oraz zależności między danymi. Sama obecność pliku kopii zapasowej nie potwierdza, że da się go poprawnie wykorzystać w klastrze. Istotne są również metadane, kolejność dzienników transakcyjnych, identyfikatory instancji, konfiguracja replikacji i zgodność wersji oprogramowania.

Ustalenie właściciela usługi przed odtworzeniem

Najważniejszym etapem restore jest kontrola stanu klastra. Trzeba potwierdzić, który węzeł ma aktualnie rolę aktywną, czy pozostali członkowie klastra są osiągalni oraz czy mechanizm monitorujący nie planuje automatycznego przełączenia podczas prac serwisowych. Jeżeli usługa może zostać uruchomiona przez kilka niezależnych mechanizmów, odtwarzanie bez blokady lub trybu konserwacyjnego może doprowadzić do konfliktu ról. Taki konflikt nazywa się często scenariuszem split-brain: dwa węzły uznają się za uprawnione do obsługi tego samego zasobu.

Bezpieczna procedura zwykle obejmuje kontrolowane przełączenie usługi na wskazany węzeł, czasowe wstrzymanie automatycznego failoveru oraz zastosowanie mechanizmu izolowania uszkodzonego członka, czyli fencing. Fencing ma uniemożliwić staremu lub odłączonemu węzłowi dalszy zapis, na przykład przez odcięcie zasilania albo dostępu do współdzielonego zasobu. Dopiero po jednoznacznym potwierdzeniu, że tylko wybrana instancja może modyfikować odtwarzane dane, można rozpocząć właściwy restore. Po zakończeniu prac blokadę automatycznego przełączania należy usunąć w kontrolowany sposób, z ponownym sprawdzeniem stanu każdego węzła.

Jeżeli system wykorzystuje replikację, trzeba rozróżnić odtworzenie kopii na aktywnym węźle od odbudowy repliki zapasowej. Przywrócenie starej kopii na zapasowym serwerze nie powinno automatycznie oznaczać dołączenia go do produkcyjnej replikacji. Najpierw należy sprawdzić, czy odtworzone dane mają właściwy punkt w czasie, czy nie brakuje dzienników oraz czy partner replikacji zaakceptuje ponowną synchronizację. W przeciwnym razie można uzyskać węzeł pozornie sprawny, lecz zawierający dane starsze niż stan produkcyjny.

Spójność kopii, dzienników i zależności

Restore powinien uwzględniać relację między kopią pełną, kopiami przyrostowymi lub różnicowymi oraz dziennikami zmian. Jeżeli odtwarzany system zapisuje dane w kilku powiązanych lokalizacjach, zachowanie różnych punktów w czasie może naruszyć spójność aplikacji. Dotyczy to między innymi danych głównych, indeksów, plików konfiguracyjnych, certyfikatów, kolejek oraz informacji potrzebnych do odtworzenia stanu klastra. Wymagany punkt odtworzenia powinien być zapisany przed operacją, a jego osiągnięcie należy zweryfikować po zakończeniu.

W środowisku HA trzeba również ustalić, czy przywracane dane mają zastąpić obecny stan, czy zostać odtworzone jako osobna kopia do późniejszego porównania. Nadpisanie aktywnego zasobu bez potwierdzenia punktu odtworzenia może usunąć nowsze, prawidłowe zmiany. Z tego powodu przed restore wykonuje się kontrolną kopię bieżącego stanu albo zachowuje możliwość powrotu do poprzedniej konfiguracji. Dotyczy to także ustawień agenta klastra, reguł monitorowania, zależności usług i parametrów uruchamiania.

Po odtworzeniu należy sprawdzić nie tylko komunikat zakończenia zadania, ale również możliwość odczytu danych, poprawność uprawnień, zgodność sum kontrolnych oraz stan synchronizacji między węzłami. W przypadku usługi bazodanowej sprawdza się integralność struktur i dostępność wymaganych dzienników. W przypadku systemu plików kontroluje się kompletność katalogów, właścicieli oraz atrybuty plików. Następnie trzeba wykonać kontrolowany test przełączenia, aby potwierdzić, że odtworzona usługa może zostać uruchomiona na innym węźle bez utraty dostępu do danych.

Test po restore i powrót do normalnego failoveru

Przywrócenie usługi do stanu produkcyjnego kończy się dopiero po przejściu testów operacyjnych. Należy zweryfikować stan klastra, rolę każdego węzła, dostępność zasobu dla klientów oraz działanie monitoringu. Warto sprawdzić scenariusz kontrolowanego zatrzymania aktywnej instancji i potwierdzić, że zapasowy węzeł przejmuje usługę zgodnie z zaplanowaną polityką. Test powinien obejmować także powrót poprzedniego węzła do klastra, ponieważ ponowne dołączenie może wymagać pełnej synchronizacji albo odbudowy repliki.

Dokumentacja restore powinna zawierać źródło kopii, zakres odtworzenia, punkt w czasie, użyte konto techniczne, kolejność czynności, wynik kontroli spójności i rezultat testu failoveru. Jeżeli wystąpiły rozbieżności, na przykład opóźnienie replikacji albo brak części dzienników, trzeba je odnotować przed przywróceniem automatycznego przełączania. Dopiero gdy jeden węzeł ma jasno określoną rolę właściciela, repliki są zsynchronizowane, a monitoring raportuje stan prawidłowy, można zakończyć tryb konserwacyjny.

W praktyce restore w HA jest więc procedurą zarządzania stanem całego układu, a nie pojedynczym poleceniem kopiowania plików. Błąd w kolejności działań może spowodować nadpisanie nowszych danych, uruchomienie nieaktualnej repliki albo konflikt dwóch aktywnych właścicieli zasobu. Prawidłowo wykonane odtworzenie łączy kontrolę ról, izolowanie nieuprawnionych węzłów, weryfikację kopii, synchronizację replik i test rzeczywistego przełączenia usługi.