Zgodność wersji w klastrze

Zgodność wersji w klastrze wymaga, by wszystkie węzły korzystały z tego samego poziomu poprawek instancji.

Na czym polega zgodność wersji w klastrze

Zgodność wersji w klastrze oznacza, że współpracujące węzły używają wydań oprogramowania, które mogą bezpiecznie wymieniać dane, obsługiwać wspólne zadania i korzystać z tego samego modelu konfiguracji. W praktyce nie zawsze chodzi o identyczny numer całego pakietu. Istotne są również poziomy poprawek, aktualizacje komponentów klastrowych, wersje bibliotek komunikacyjnych, modułów zarządzających oraz formaty danych zapisywanych na współdzielonym magazynie. Dwa węzły mogą mieć tę samą główną wersję, ale różne poprawki bezpieczeństwa lub poprawki błędów, co nadal może powodować niezgodność.

Przed dołączeniem węzła do klastra system zwykle sprawdza zgodność wersji agenta, usług sterujących, protokołów komunikacyjnych i konfiguracji. Jeżeli kontrola nie jest wykonywana albo została wyłączona, różnica może ujawnić się dopiero podczas przejęcia zasobu, odtwarzania stanu po awarii lub synchronizacji danych. Skutkiem bywają odrzucone połączenia, błędy wyboru lidera, niepełna replikacja, restart usług albo utrata możliwości wykonania operacji administracyjnej. Dlatego numer wersji powinien być traktowany jako element topologii klastra, a nie wyłącznie jako informacja o zainstalowanym programie.

Poziom poprawek a kompatybilność komunikacji

Najczęściej stosuje się zasadę utrzymywania wszystkich węzłów na tym samym wydaniu głównym, tej samej wersji podrzędnej i tym samym poziomie poprawek. Wydanie główne może zmieniać sposób działania usług, format komunikatów lub procedury wyboru koordynatora, natomiast poprawka może modyfikować implementację istniejącego mechanizmu. Jeżeli producent dopuszcza czasową pracę mieszaną podczas aktualizacji, określa zwykle dokładny zakres obsługiwanych różnic oraz kolejność aktualizacji. Taka kompatybilność nie oznacza, że dowolne dwa wydania mogą działać razem.

Szczególnej uwagi wymagają zmiany dotyczące protokołu komunikacyjnego, mechanizmów uwierzytelniania, szyfrowania, serializacji danych i struktur metadanych. Starszy węzeł może nie rozumieć nowych pól komunikatu, a nowszy komponent może oczekiwać informacji, których starsza wersja nie wysyła. Czasem nowsze oprogramowanie zachowuje tryb zgodności wstecznej, ale jest to funkcja konkretnego produktu i konkretnej ścieżki aktualizacji. Nie należy zakładać jej istnienia tylko na podstawie podobnych numerów wersji. Wymagania z dokumentacji producenta trzeba odnieść do rzeczywistego wydania, systemu operacyjnego i roli danego węzła.

Aktualizacja klastra i okres pracy mieszanej

Podczas planowanej aktualizacji administrator powinien najpierw sprawdzić macierz kompatybilności, wymagania dotyczące kopii zapasowej oraz możliwość wycofania zmiany. W klastrach obsługujących aktualizację kroczącą wyłącza się pojedynczy węzeł, aktualizuje jego oprogramowanie, uruchamia testy i dopiero potem przechodzi do kolejnego węzła. Przed rozpoczęciem należy potwierdzić stan replikacji, dostępność zasobów, quorum lub równoważny mechanizm utrzymania większości oraz poprawne działanie ścieżek przełączania awaryjnego. Węzeł z nieudaną aktualizacją nie powinien być ponownie włączany do produkcyjnej komunikacji bez ustalenia przyczyny.

Jeżeli producent przewiduje okres pracy mieszanej, może on służyć wyłącznie do wykonania kontrolowanej procedury migracyjnej. W tym czasie nie powinno się uruchamiać funkcji dostępnych tylko w nowej wersji, zmieniać formatu współdzielonych danych ani wykonywać nieudokumentowanych modyfikacji konfiguracji. Po aktualizacji wszystkich węzłów trzeba zweryfikować jednolitość wersji, stan usług, synchronizację danych, dzienniki zdarzeń i zachowanie po kontrolowanym przełączeniu. Równie ważne jest usunięcie pozostałości starego pakietu, nieaktualnych bibliotek oraz konfiguracji, które mogłyby spowodować ponowne uruchomienie węzła w niewłaściwym stanie.

Objawy niezgodności i zakres diagnostyki

Do typowych objawów niezgodności wersji należą komunikaty o odrzuconym dołączeniu węzła, błędy negocjacji protokołu, powtarzające się rozłączenia, nieudane synchronizacje oraz różnice w stanie zasobów widzianym przez poszczególne węzły. Diagnostykę zaczyna się od zebrania dokładnych numerów wersji wszystkich komponentów, a nie tylko centralnej aplikacji. Należy porównać również architekturę systemu, zainstalowane poprawki, wersje sterowników, modułów klastrowych i narzędzi administracyjnych. Następnie analizuje się czas wystąpienia problemu oraz korelację z ostatnią aktualizacją lub zmianą konfiguracji.

Przywrócenie zgodności wymaga zastosowania zatwierdzonej przez producenta ścieżki: aktualizacji starszego węzła, czasowego obniżenia wersji nowszego komponentu albo odtworzenia całego środowiska z kompatybilnego obrazu i konfiguracji. Sam restart usług zwykle nie usuwa różnicy wersji. Po wykonaniu zmiany należy sprawdzić komunikację między każdym węzłem, poprawność replikacji, przejęcie zasobów i zachowanie po ponownym uruchomieniu. Wyniki warto zapisać w dokumentacji administracyjnej, aby kolejna aktualizacja nie opierała się na niepełnych informacjach o stanie klastra.