Migracja VMware do Proxmox VE: jak odebrać pilotaż

Pierwsza maszyna uruchomiła się już na Proxmox Virtual Environment. Teraz trzeba sprawdzić, czy użytkownik może wykonać swoją pracę, dane są spójne, a zespół potrafi odtworzyć usługę. Pilotażem nazywamy tu próbę przeniesienia jednej usługi na kopii, w odizolowanej sieci; odbiór pilotażu poprzedza produkcyjne przełączenie. Po dobrym odbiorze wiesz, które kroki możesz powtórzyć przy kolejnych VM, a które wymagają osobnej oceny i miejsca w harmonogramie.

Wybierz usługę, która odpowie na pytania o migrację

Do pilotażu wybierz usługę o znanych zależnościach i takim znaczeniu, aby jej próbę można było przeprowadzić w kontrolowanych warunkach. Sama mała VM niewiele pokaże, jeśli później planujesz przenieść aplikację korzystającą z bazy, udziałów sieciowych i zewnętrznej autoryzacji. Zapisz, które cechy wybranego systemu odpowiadają kolejnym planowanym migracjom.

Przed testem opisz jedną pełną czynność użytkownika: od logowania przez zapis danych do odczytania wyniku. Może to być przygotowanie dokumentu w środowisku testowym, zapis w bazie i wygenerowanie raportu. Wskaż osobę, która oceni rezultat. Administrator odpowie za host i system operacyjny; właściciel aplikacji potwierdzi, że wynik ma sens biznesowy.

Zbierz też zależności: nazwy usług i serwerów, kierunki połączeń, konta usługowe, katalogi danych i zadania uruchamiane w tle. Potwierdzaj je na konfiguracji aplikacji, harmonogramach oraz połączeniach obserwowanych podczas wykonania scenariusza. Każdej zależności przypisz test. Pełniejszą inwentaryzację środowiska przed migracją opisaliśmy w artykule „Co sprawdzamy przed każdą migracją serwera?”.

Co sprawdzić po imporcie maszyny z VMware?

Po imporcie sprawdź start systemu, sterowniki, widoczność dysków oraz konfigurację sieci, a następnie wykonaj scenariusz aplikacji. Importer Proxmox VE pomaga przenieść maszynę i odwzorować jej konfigurację, lecz część ustawień może wymagać dostosowania. W Windows uwzględnij przygotowanie sterowników VirtIO odpowiednich dla planowanych urządzeń.

Zaplanuj też porządki w systemie gościa. Usuń narzędzia VMware Tools (w Linuksie zwykle open-vm-tools) i zainstaluj QEMU Guest Agenta, włączając go także w opcjach VM w Proxmox VE; agent umożliwia hostowi m.in. kontrolowane zamknięcie systemu oraz współpracę z mechanizmem freeze/thaw używanym podczas operacji takich jak snapshot czy backup. W przypadku aplikacji korzystających z własnych mechanizmów spójności, np. VSS w Windows, konfigurację warto zweryfikować osobno. Nowa wirtualna karta sieciowa to dla systemu inny adapter: w Windows ustawienia statycznego IP trzeba zwykle wprowadzić ponownie, a w Linuksie nazwa interfejsu może się zmienić (np. z ens192 na ens18) i unieważnić dotychczasową konfigurację sieci.

Porównaj konfigurację źródła i celu: tryb rozruchu, pamięć, procesory wirtualne, dyski oraz interfejsy. W konsoli systemu gościa zweryfikuj, czy widoczne są wszystkie wymagane woluminy. W Menedżerze urządzeń Windows sprawdź stan kontrolerów i kart; w Linuksie porównaj wykryte urządzenia i konfigurację interfejsów z listą wejściową. Kryterium jest zgodność z projektem i brak nierozwiązanych błędów dotyczących urządzeń potrzebnych aplikacji.

Próbę wykonuj w wydzielonej sieci z kontrolowanym dostępem do zależności. Zanim uruchomisz kopię, sprawdź przypięcie karty do właściwego bridge'a/VLAN-u i reguły routingu oraz zapory. Z maszyny testowej sprawdź połączenia do wybranych produkcyjnych adresów i portów, które zgodnie z projektem powinny być niedostępne. Wynik porównaj z regułami i logami zapory; samo nieudane połączenie może też wynikać z niedziałającej usługi. Próbę uznaj za poprawną, gdy zaobserwowana blokada odpowiada zaplanowanej regule. Także zadania wysyłające pocztę, płatności lub dane do innych systemów powinny mieć testowe odbiorniki albo zostać wyłączone na czas próby.

Nie uruchamiaj równolegle dwóch kopii z tą samą tożsamością w sieci produkcyjnej. Pilotaż ma sprawdzić przeniesienie usługi, bez uruchamiania drugiego niezależnego źródła zapisów.

Karta odbioru jednej usługi

Poniższa karta jest propozycją do dostosowania przed próbą. Do każdego punktu dopisz nazwę usługi, osobę odbierającą, datę, rezultat i odnośnik do dowodu. Progi liczbowe uzgodnij z właścicielem aplikacji przed rozpoczęciem pomiarów.

1. Start po restarcie. W oknie testowym uruchom ponownie system gościa i wykonaj scenariusz logowania oraz zapisu. Zachowaj czas startu, wynik testu i zdarzenia usług zależnych. Odbiór: wymagane usługi startują w uzgodnionej kolejności, bez ręcznej naprawy po każdym restarcie.
2. Dane i uprawnienia. Na tej samej zamrożonej próbce porównaj zestaw rekordów lub wynik raportu przed i po migracji. Dla aplikacji bazodanowej użyj jej funkcji kontroli spójności (np. DBCC CHECKDB w Microsoft SQL Server) albo procedury producenta; dla plików porównaj wskazane katalogi i uprawnienia kont testowych. Odbiór: zgodne wyniki i brak nieuzasadnionego rozszerzenia dostępu. Sama liczba plików nie dowodzi zgodności ich zawartości.
3. Praca użytkownika. Osoba biznesowa wykonuje ustalony scenariusz, zapisuje identyfikator transakcji i sprawdza jej wynik w systemie zależnym. Odbiór: operacja kończy się prawidłowo, a efekt jest widoczny we właściwym miejscu. Test samego otwarcia strony logowania jest niewystarczający.
4. Czas wykonania. Zmierz ten sam raport lub operację na tej samej próbce danych przed migracją i po niej, przy porównywalnym obciążeniu. Pierwszy pomiar po restarcie odrzuć, bo system działa z zimną pamięcią podręczną, a następnie zapisz czas pięciu powtórzeń i oblicz medianę. Zmianę policz jako (mediana po migracji / mediana przed migracją − 1) × 100%, przy czym czas bazowy musi być większy od zera. Odbiór: wynik mieści się w uzgodnionym limicie. Jeżeli wcześniej nie ustalono dopuszczalnej różnicy, wynik można jedynie odnotować — nie da się na jego podstawie jednoznacznie zaliczyć ani odrzucić testu.
5. Backup po migracji. W konfiguracji zadania sprawdź, czy obejmuje właściwą VM i wymagane dyski. Po wykonaniu kopii zapisz identyfikator zadania, datę punktu odtworzenia i wynik. Następnie odtwórz ją pod nowym identyfikatorem VM, w odizolowanej sieci lub z odłączoną kartą sieciową, aby kopia nie weszła do sieci produkcyjnej, i powtórz test aplikacji. Odbiór: usługa działa z danych odtworzonych, w uzgodnionym czasie i z akceptowalną aktualnością danych. Sposób przeprowadzenia takiej próby opisujemy szerzej w artykule „Proxmox Backup Server: jak sprawdzić odtwarzanie usług”.
6. Monitoring i odpowiedzialność. Dla testowej usługi wywołaj bezpieczny alarm, np. kontrolowane zatrzymanie testowej aplikacji w uzgodnionym oknie. Zapisz moment wystąpienia zdarzenia i odbioru powiadomienia. Odbiór: komunikat trafia do wyznaczonej osoby, wskazuje właściwą usługę i znika po usunięciu przyczyny.

Przy niezaliczonym punkcie zanotuj konkretną poprawkę i powtórz związany z nią test. Nie zamieniaj wyniku negatywnego na pozytywny samym dopiskiem „do poprawy później”, jeśli problem blokuje pracę użytkownika lub bezpieczny powrót.

Jak zmierzyć przerwę w dostępności aplikacji?

Przerwę licz od momentu, w którym użytkownik traci możliwość wykonania uzgodnionej czynności, do chwili jej ponownego, poprawnego zakończenia. Czas kopiowania dysku zapisuj osobno. W protokole zachowaj znaczniki czasu z tą samą strefą i zsynchronizowanymi zegarami.

Podziel chronologię na zatrzymanie zapisów, przeniesienie, start oraz testy odbiorcze. Dzięki temu zobaczysz, który etap trzeba skrócić przed kolejną partią. Jeśli najdłużej trwa oczekiwanie na osobę uprawnioną do sprawdzenia aplikacji, szybszy storage tego problemu nie rozwiąże.

W próbie na kopii mierz czas odtworzenia całej sekwencji i nazywaj go czasem próby, a nie przestojem produkcji. Jeżeli używasz innego rozmiaru danych, sieci lub sprzętu, zapisz różnice. Nie mnoż wyniku dla jednej VM przez liczbę wszystkich maszyn bez sprawdzenia zależności i możliwej równoległości prac.

Kiedy przerwać migrację i uruchomić rollback?

Rollback przygotowujesz na podstawie pilotażu, a stosujesz go przy produkcyjnym przełączeniu. Moment decyzji wyznacz od końca uzgodnionego okna, odejmując czas powrotu, ponownych testów oraz rezerwę. Czas rollbacku ustal na podstawie wykonanej próby dla tej usługi. Jeśli nie został zmierzony, harmonogram zawiera założenie wymagające sprawdzenia przed produkcyjnym przełączeniem.

Przykład hipotetyczny: okno kończy się o 02:00. Próba powrotu zajęła 25 minut, testy usługi 15 minut, a uzgodniona rezerwa to 20 minut. Graniczna godzina decyzji wynosi 02:00 − 25 min − 15 min − 20 min = 01:00. To przykład rachunku, nie wynik wdrożenia.

Powrót musi uwzględniać dane zapisane po przełączeniu. Jeśli użytkownicy zaczęli już pracować na nowym systemie, samo włączenie starej VM może oznaczać powrót do wcześniejszych danych. Przed migracją uzgodnij z właścicielem aplikacji sposób zatrzymania zapisów, ich ewentualnego przeniesienia z powrotem i ponownego otwarcia dostępu. Kontrolera domeny nie cofa się przez uruchomienie starej kopii ani przywrócenie snapshotu bez procedury właściwej dla środowiska, bo może to zaburzyć replikację katalogu. Dla innych systemów replikowanych, np. baz danych w klastrze, powrót opisz osobno w planie.

Powrót jest możliwy tylko wtedy, gdy stara VM nadal istnieje. Pozostaw maszynę źródłową wyłączoną, ale nieusuniętą do formalnego odbioru, a okres jej przechowywania uzgodnij przed przełączeniem.

W opisanym przez Symbit projekcie administracji publicznej prace zaplanowano na sobotę, poza godzinami pracy urzędu, a zespół miał przygotowany plan awaryjny. Dzięki temu przed poniedziałkowym startem pracy zostawał zapas czasu na weryfikację danych i działania korygujące. Przebieg projektu opisuje artykuł „Migracja do Proxmox VE bez przestoju”.

Decyzja o kolejnej partii VM

Na zakończenie pilotażu przygotuj krótką decyzję: co odebrano, co trzeba poprawić i do których kolejnych usług można zastosować sprawdzoną metodę. Załącz kartę, chronologię oraz listę różnic między pilotażem a następną partią.

Jeżeli kolejny system używa innego sposobu rozruchu, zewnętrznego urządzenia lub innej architektury aplikacji, potrzebuje osobnej oceny. Sprawdzone scenariusze użytkownika, sposób pomiaru czasu i format dowodów można natomiast wykorzystać ponownie. Jak wygląda cały proces etapowej migracji, od inwentaryzacji i pilotażu po przełączenie i plan powrotu, opisuje nasza oferta migracji VMware do Proxmox VE.

Dokumentacja i źródła

Dokumentacja maszyn wirtualnych Proxmox VE

Demonstracja importera VMware ESXi

Backup i odtwarzanie