Rolling Upgrade

Rolling Upgrade to aktualizacja klastra węzeł po węźle, minimalizująca przestój usługi w trakcie procesu.

Na czym polega Rolling Upgrade klastra

Rolling Upgrade, czyli aktualizacja krocząca, polega na zmianie oprogramowania lub konfiguracji klastra etapami, obejmującymi pojedyncze węzły albo niewielkie grupy węzłów. Przed rozpoczęciem prac administrator sprawdza stan całego środowiska, dostępność kopii zapasowych, zgodność wersji oraz sposób przełączania ruchu między węzłami. Następnie jeden węzeł zostaje wyłączony z obsługi, zaktualizowany, uruchomiony ponownie i poddany testom. Dopiero po potwierdzeniu jego poprawnego działania przechodzi się do kolejnego węzła.

Kluczowym warunkiem takiej procedury jest utrzymanie funkcji usługi przez pozostałe, sprawne węzły. Węzeł aktualizowany nie powinien przyjmować nowych żądań ani wykonywać zadań, które mogłyby zostać przerwane w niekontrolowany sposób. W zależności od rozwiązania stosuje się mechanizmy oznaczane jako drain, cordon, maintenance mode albo graceful shutdown. Ich działanie może obejmować przekazanie sesji, dokończenie bieżących operacji, odłączenie replik lub czasowe przesunięcie obciążenia na inne elementy klastra.

Warunki zgodności przed rozpoczęciem aktualizacji

Rolling Upgrade nie oznacza, że dowolne wersje oprogramowania można mieszać bez ograniczeń. Producent konkretnego silnika klastra musi określać, czy dopuszcza czasową pracę w układzie mieszanych wersji, jak długo może trwać okres przejściowy i które funkcje pozostają wtedy dostępne. Często starsze i nowsze węzły mogą współpracować tylko w ograniczonym zakresie. Włączenie funkcji wymagającej nowego formatu danych lub nowego protokołu może uniemożliwić powrót do poprzedniej wersji.

Przed aktualizacją należy zweryfikować między innymi stan quorum, replikację, opóźnienia zapisu, zależności między usługami oraz dostępne zasoby pozostałych węzłów. Jeżeli klaster działa na granicy wydajności, wyłączenie jednego elementu może spowodować przeciążenie pozostałych i doprowadzić do przerwy mimo zastosowania aktualizacji kroczącej. Istotne są również sterowniki, moduły jądra, biblioteki, certyfikaty, reguły zapory oraz ustawienia klienta. Zmiana samego pakietu klastra nie gwarantuje zgodności całego stosu.

Przebieg, kontrola i możliwość wycofania

Bezpieczna procedura powinna mieć jasno określoną kolejność czynności. Najpierw rejestruje się stan bazowy, w tym zdrowie węzłów, liczbę aktywnych zadań, błędy, wykorzystanie procesora, pamięci i przestrzeni dyskowej. Następnie węzeł jest odprowadzany z ruchu, a administrator potwierdza, że nie posiada już operacji wymagających natychmiastowej obsługi. Po instalacji aktualizacji sprawdza się uruchomienie usług, dołączenie węzła do klastra, komunikację z pozostałymi elementami i poprawność raportowanego stanu.

Test nie powinien ograniczać się do sprawdzenia, czy proces działa. Należy zweryfikować także odczyt i zapis danych, tworzenie nowych połączeń, obsługę awarii pojedynczego węzła oraz zachowanie mechanizmu wyboru lidera, jeżeli taki mechanizm występuje w danym produkcie. Przed przejściem dalej trzeba ustalić kryteria zatrzymania aktualizacji, na przykład utrzymujące się błędy replikacji, utratę quorum, wzrost opóźnień albo nieudaną aktywację usługi. Plan wycofania powinien uwzględniać zarówno powrót do poprzedniej wersji oprogramowania, jak i odtworzenie konfiguracji. Nie każdą zmianę schematu danych można cofnąć przez zwykłe odinstalowanie pakietu.

Rolling Upgrade a diagnostyka po zmianie

Po zakończeniu aktualizacji całego klastra należy porównać jego zachowanie z pomiarami wykonanymi przed zmianą. Analizuje się logi usług, komunikaty dotyczące członkostwa w klastrze, błędy autoryzacji, przerwane połączenia, czasy odpowiedzi oraz stan synchronizacji. Szczególną uwagę zwraca się na błędy pojawiające się dopiero przy komunikacji między wersjami, ponieważ pojedynczy węzeł może przejść lokalny test, a mimo to nie współpracować prawidłowo z resztą środowiska.

W praktyce problemy po Rolling Upgrade często wynikają z pominięcia jednego z etapów: niepełnego opróżnienia węzła, niezgodnej konfiguracji, niewystarczającej ilości zasobów albo zbyt wczesnego włączenia funkcji dostępnej dopiero po zakończeniu migracji wszystkich elementów. Dlatego końcowy odbiór powinien obejmować test ruchu produkcyjnego, kontrolowane przełączenie oraz potwierdzenie, że wszystkie węzły działają na planowanej wersji. Dokumentacja powinna zawierać kolejność aktualizacji, wyniki kontroli, napotkane ostrzeżenia i decyzję o zamknięciu okna serwisowego.