Side-by-side migration

Side-by-side migration polega na zainstalowaniu nowej wersji serwera obok starej i stopniowym przenoszeniu baz.

Na czym polega migracja side-by-side

Side-by-side migration, czyli migracja równoległa, polega na uruchomieniu nowego środowiska obok dotychczasowego i stopniowym przenoszeniu do niego danych, konfiguracji oraz obsługi użytkowników. Stary serwer pozostaje dostępny przez część procesu, a nowy serwer jest przygotowywany niezależnie. Dzięki temu można sprawdzić działanie aplikacji i baz danych przed przełączeniem całego obciążenia produkcyjnego.

W odróżnieniu od migracji in-place nowa instalacja nie zastępuje bezpośrednio istniejącego systemu na tym samym serwerze. Ogranicza to ryzyko związane z aktualizacją plików systemowych, zmianą bibliotek, sterowników i ustawień usług. Jednocześnie migracja side-by-side wymaga zaplanowania komunikacji między środowiskami, zgodności wersji oraz sposobu synchronizacji danych. W przypadku baz danych konieczne jest ustalenie, czy dane będą przenoszone jednorazowo, czy też przez pewien czas utrzymywana będzie ich bieżąca kopia na nowym serwerze.

Przygotowanie nowego środowiska i zależności

Pierwszym etapem jest spisanie elementów, które muszą zostać odtworzone na nowym serwerze. Obejmuje to system operacyjny, rolę serwera, zainstalowane aplikacje, usługi działające w tle, zadania harmonogramu, certyfikaty, reguły zapory, konta techniczne, udziały plikowe oraz ustawienia połączeń. Sama kopia bazy danych nie wystarcza, jeżeli aplikacja korzysta dodatkowo z określonych sterowników, plików konfiguracyjnych albo katalogów przechowujących załączniki.

Należy sprawdzić zgodność wersji silnika bazy danych, formatów plików, kodowania znaków i mechanizmów uwierzytelniania. Istotne są także nazwy hostów, adresy IP, rekordy DNS, porty sieciowe i parametry połączeń zapisane w aplikacjach. Nowy serwer powinien zostać przetestowany bez kierowania na niego pełnego ruchu produkcyjnego. Test obejmuje między innymi uruchomienie aplikacji, odczyt danych, zapis nowych rekordów, wykonywanie raportów, działanie zadań cyklicznych oraz komunikację z systemami zależnymi.

Przed rozpoczęciem kopiowania trzeba ustalić punkt odtworzenia i sposób powrotu do starego środowiska. Kopia zapasowa powinna być sprawdzona przez próbne odtworzenie, ponieważ samo jej utworzenie nie potwierdza, że można z niej skutecznie odzyskać dane. W planie warto zapisać kolejność czynności, osoby odpowiedzialne za akceptację testów oraz kryteria uznania migracji za zakończoną.

Synchronizacja danych i przełączenie ruchu

W prostym wariancie dane są kopiowane podczas zaplanowanego okna serwisowego, gdy użytkownicy nie wykonują już operacji zapisu. Stary system zostaje wtedy zatrzymany lub przełączony w tryb tylko do odczytu, wykonywana jest końcowa kopia, a następnie dane są importowane do nowego środowiska. Takie podejście jest łatwiejsze do kontroli, ale długość przerwy zależy od rozmiaru danych, wydajności nośników i czasu potrzebnego na walidację.

Jeżeli wymagane jest ograniczenie przerwy, stosuje się mechanizm replikacji, dzienników transakcyjnych albo inną funkcję synchronizacji właściwą dla używanego produktu. W takim układzie nowy serwer otrzymuje zmiany wykonane na starym serwerze aż do momentu przełączenia. Nie wolno zakładać, że każda technologia obsługuje dwukierunkową synchronizację. Często bezpieczniejszy jest model jednokierunkowy, w którym stare środowisko pozostaje źródłem danych, a nowe pełni rolę celu migracji.

Przełączenie może polegać na zmianie konfiguracji aplikacji, rekordu DNS, adresu usługi albo reguły kierującej ruch do właściwego serwera. Po zmianie należy sprawdzić, czy nowe połączenia trafiają do nowego środowiska, czy nie pozostały aktywne procesy zapisujące dane na starym serwerze oraz czy wszystkie wymagane usługi zostały uruchomione. Czas propagacji DNS może powodować, że część klientów przez pewien okres będzie korzystać z poprzedniego adresu, dlatego zmianę trzeba uwzględnić w procedurze przełączenia.

Walidacja po migracji i bezpieczny powrót

Po przełączeniu należy porównać najważniejsze elementy obu środowisk. Kontroluje się między innymi liczbę tabel lub kolekcji, liczbę rekordów w krytycznych obszarach, zakresy identyfikatorów, daty ostatnich modyfikacji oraz wyniki wybranych zapytań kontrolnych. Sama zgodność liczby rekordów nie gwarantuje poprawności migracji, ponieważ dane mogą być niepełne, niepowiązane z właściwymi tabelami albo zapisane z innym kodowaniem.

Testy funkcjonalne powinny obejmować typowe operacje użytkowników i zadania administracyjne: logowanie, wyszukiwanie, dodawanie i modyfikowanie danych, generowanie raportów, import oraz eksport. Należy również sprawdzić logi aplikacji i silnika bazy danych, błędy połączeń, opóźnienia zapytań, działanie kopii zapasowych oraz monitoring zasobów procesora, pamięci, dysku i sieci. Jeżeli nowy serwer działa poprawnie tylko przy małym obciążeniu, migracji nie można uznać za zweryfikowaną.

Plan wycofania powinien określać, w jakich warunkach ruch zostanie skierowany z powrotem do starego środowiska. Po rozpoczęciu zapisu na nowym serwerze powrót może wymagać dodatkowej synchronizacji, aby nie utracić nowych danych. Z tego powodu stary serwer nie powinien być od razu usuwany ani czyszczony. Po okresie obserwacji, potwierdzeniu kompletności danych i wykonaniu aktualnej kopii zapasowej można przejść do kontrolowanego wycofania nieużywanych elementów infrastruktury.