Kompatybilność z klastrowaniem

Kompatybilność z klastrowaniem określa, czy dana funkcja działa w instancji uruchomionej w klastrze pracy awaryjnej.

Co oznacza kompatybilność funkcji z klastrem pracy awaryjnej

Kompatybilność z klastrowaniem oznacza, że określona funkcja, składnik albo narzędzie może działać w instancji uruchomionej w klastrze pracy awaryjnej. Taka instancja jest obsługiwana przez kilka węzłów, ale w danym momencie aktywna pozostaje na jednym z nich. Jeżeli aktywny węzeł przestanie działać albo zostanie wyłączony na potrzeby konserwacji, zasoby instancji mogą zostać przeniesione na inny węzeł. Funkcja zgodna z klastrem musi prawidłowo reagować na taki przełącznik i nie może zakładać, że przez cały czas działa na jednym, niezmiennym komputerze.

Samo uruchomienie programu na komputerze należącym do klastra nie jest jeszcze dowodem kompatybilności. Istotne jest to, czy funkcja rozpoznaje sposób uruchamiania instancji, korzysta z zasobów zarządzanych przez klaster i zachowuje się poprawnie po zmianie aktywnego węzła. W dokumentacji technicznej kompatybilność może dotyczyć między innymi usług, zadań wykonywanych cyklicznie, mechanizmów monitorowania, konfiguracji, rozszerzeń oraz narzędzi administracyjnych.

Przełączenie awaryjne a stan wykonywanej operacji

Najważniejszym sprawdzianem zgodności jest przełączenie awaryjne, określane jako failover. Podczas tego zdarzenia usługa może zostać zatrzymana na dotychczasowym węźle i uruchomiona na innym. Operacja rozpoczęta przed przełączeniem nie zawsze może być kontynuowana od tego samego miejsca. Funkcja kompatybilna z klastrem powinna więc przewidywać przerwanie procesu, poprawnie zwalniać zasoby i umożliwiać bezpieczne ponowienie działania, jeżeli charakter operacji na to pozwala.

Szczególne znaczenie ma sposób przechowywania stanu. Dane niezbędne do wznowienia pracy powinny znajdować się w zasobie dostępnym dla aktywnego węzła albo być odtwarzane z mechanizmu zaprojektowanego dla danej architektury. Jeżeli funkcja zapisuje ważne informacje wyłącznie na lokalnym dysku węzła, po przełączeniu może utracić kontekst działania. Podobny problem wystąpi, gdy proces korzysta z lokalnego katalogu tymczasowego, pamięci podręcznej lub identyfikatora procesu, który nie istnieje już po uruchomieniu instancji na innym węźle.

Usługi, zależności i komunikacja z instancją

Ocena kompatybilności obejmuje także zależności funkcji od innych usług i zasobów. Klaster musi wiedzieć, które elementy powinny zostać uruchomione razem, w jakiej kolejności należy je przygotować oraz jakie objawy wskazują na niedostępność usługi. Funkcja może być formalnie dostępna w klastrowanej instancji, ale działać nieprawidłowo, jeżeli jej zależność nie jest objęta monitorowaniem albo po przełączeniu nie odtwarza poprawnie połączenia.

Ważna jest również obsługa nazwy logicznej i punktu dostępu używanego przez klientów. Po przełączeniu klient powinien kierować żądania do aktywnej instancji, a nie do nazwy konkretnego węzła, który przestał pełnić funkcję właściciela zasobu. Niektóre połączenia zostaną przerwane i wymagają ponownego ustanowienia. Poprawnie zaprojektowana funkcja nie powinna traktować chwilowej utraty połączenia jako dowodu trwałego uszkodzenia danych ani pozostawiać blokad, plików tymczasowych lub nieukończonych wpisów bez możliwości uporządkowania.

Jak sprawdza się zgodność przed użyciem

Weryfikację należy rozpocząć od dokumentacji konkretnej funkcji oraz używanej wersji instancji. Trzeba sprawdzić, czy producent wymaga określonej konfiguracji klastra, dodatkowych uprawnień, wspólnego zasobu, specjalnego sposobu uruchamiania albo ograniczenia funkcjonalnego. Sama zgodność wersji systemu operacyjnego nie przesądza o zgodności aplikacji z klastrem. Również pomyślne uruchomienie funkcji przed przełączeniem nie potwierdza jeszcze poprawnego działania po awarii.

Praktyczny test powinien obejmować uruchomienie funkcji, kontrolowane przełączenie instancji, obserwację logów oraz sprawdzenie wyniku po ponownym uruchomieniu usługi. Należy zweryfikować, czy zadania nie wykonują się podwójnie, czy operacje przerwane podczas failover mają jednoznaczny status, czy klienci mogą ponownie nawiązać połączenie i czy stan funkcji jest dostępny na nowym węźle. W przypadku wykrycia problemu trzeba rozdzielić błąd samej funkcji od błędu konfiguracji klastra, zależności usług, dostępu do zasobów lub mechanizmu odtwarzania stanu. Dzięki temu kompatybilność z klastrowaniem jest oceniana na podstawie zachowania całego przepływu pracy, a nie wyłącznie obecności programu w klastrowanej instancji.