Checklista migracji z VMware do Proxmox

Dobra migracja to nudna migracja. Jeśli w noc przełączenia dzieje się coś ciekawego, to znaczy, że coś poszło nie tak na etapie planowania. Cała robota, która decyduje o wyniku, odbywa się przed pierwszą konwersją: inwentaryzacja, backupy, plan rollback i pilotaż. Sama konwersja dysków to najmniej ryzykowny fragment projektu.

Ta checklista powstała z naszych projektów migracji z VMware do Proxmox: od kilkunastu VM w jednej serwerowni po środowiska liczone w setkach maszyn. Nie każdy punkt będzie dotyczył waszego środowiska, ale każdy pominięty świadomie jest lepszy niż pominięty przypadkiem. Jeśli zastanawiacie się, czy zmiana platformy w ogóle ma sens, zacznijcie od porównania Proxmox vs VMware i policzenia kosztów w kalkulatorze TCO.

Przed migracją

Ten etap zajmuje najwięcej czasu i to jest w porządku. Orientacyjnie: przy środowisku do 20 VM cała migracja to 2-3 tygodnie, przy 20-100 VM liczcie 4-8 tygodni, a większość tego czasu to właśnie przygotowanie.

• Pełna inwentaryzacja VM z zależnościami aplikacji. Nie tylko lista maszyn z vCenter, ale mapa: kto z kim gada, która aplikacja pada, gdy baza jest niedostępna, co startuje w jakiej kolejności. To ta mapa wyznacza fale migracji.
• Mapowanie sieci: VLAN i port group na bridge i VLAN w Proxmox. Każdy port group z vSwitch/DVS musi mieć swój odpowiednik na Linux bridge lub OVS z właściwym tagiem VLAN. Rozpiszcie to w tabeli przed startem, nie w trakcie.
• Backup wszystkiego przed startem i test odtworzenia. Backup, którego nikt nie odtworzył, to hipoteza, nie zabezpieczenie. Minimum jedna VM przywrócona z backupu na środowisku testowym przed pierwszą konwersją.
• Spis licencji Windows, SQL Server i weryfikacja przenośności. Część licencji jest wiązana ze sprzętem, część z liczbą rdzeni, część aktywuje się po zmianie platformy od nowa. Lepiej wiedzieć przed migracją niż po telefonie od audytora.
• Wybór metody migracji per VM. Import przez ESXi importer, konwersja obrazu qemu-img, backup i restore, albo reinstalacja i przeniesienie danych. Jedna metoda dla wszystkich maszyn to prawie nigdy nie jest dobra odpowiedź.
• Plan rollback per VM. Dla każdej maszyny odpowiedź na pytanie: co robimy, jeśli po przeniesieniu nie działa, i ile czasu mamy na tę decyzję. Zwykle rollback to po prostu ponowne włączenie VM na VMware, ale musi to być zapisane, a nie ustalane o trzeciej w nocy.
• Okna serwisowe uzgodnione z biznesem. Terminy, godziny, kto akceptuje przestój i kto odbiera telefon, gdy okno się przeciąga. Bez tego IT migruje, a biznes dowiaduje się z niedziałającego systemu.
• Pilotaż na 2-3 niekrytycznych VM. Pierwsza fala to zawsze maszyny, których awaria nikogo nie zaboli. Na nich weryfikujecie metodę, czasy i procedurę, zanim dotkniecie czegokolwiek produkcyjnego.
• Sterowniki virtio przygotowane wcześniej. Windows bez sterowników virtio nie zobaczy dysku po przełączeniu kontrolera na virtio-scsi. ISO ze sterownikami wgrane na storage Proxmoxa i procedura instalacji przetestowana na pilotażu.
• Pomiar wydajności bazowej. Zmierzcie czasy odpowiedzi aplikacji, IOPS i obciążenie na VMware przed migracją. Bez punktu odniesienia każda dyskusja "po migracji jest wolniej" to spór opinii, nie danych.

W trakcie migracji

Migrujemy falami, według mapy zależności z inwentaryzacji. Każda fala kończy się weryfikacją i formalnym potwierdzeniem, zanim ruszy kolejna.

• Kolejność od najmniej krytycznych. Systemy testowe i wewnętrzne narzędzia idą pierwsze, bazy danych i systemy produkcyjne na końcu, gdy procedura jest już przećwiczona.
• Scalenie snapshotów przed konwersją. Łańcuch snapshotów na VMware potrafi wysypać konwersję albo dać obraz z niespójnymi danymi. Konsolidacja przed eksportem, zawsze.
• Weryfikacja każdej VM po przeniesieniu. Usługi wstały, sieć działa we właściwym VLAN, wszystkie dyski są widoczne i zamontowane. Krótka lista kontrolna per maszyna, odhaczana, nie "na oko".
• Zachowanie adresów MAC tam, gdzie licencje są z nimi związane. Część oprogramowania wiąże aktywację z adresem MAC karty sieciowej. Proxmox pozwala ustawić MAC ręcznie, trzeba tylko wiedzieć, które maszyny tego wymagają.
• Aktualizacja DNS i adresacji, gdy jest potrzebna. Jeśli maszyna zmienia adres, wpisy DNS, reguły firewalla i konfiguracje aplikacji klienckich muszą pójść za nią w tym samym oknie.
• Monitoring obu środowisk równolegle. Przez cały okres przejściowy patrzymy i na Proxmox, i na VMware. U nas to Prometheus i Grafana, ale liczy się zasada: żadne środowisko nie zostaje bez nadzoru.
• Stary host zostaje online do potwierdzenia. Wyłączona VM na VMware to wasz najszybszy rollback. Hosty ESXi nie są kasowane ani reinstalowane, dopóki wszystkie fale nie zostaną formalnie odebrane.
• Dokumentowanie odstępstw na bieżąco. Każde "tu zrobiliśmy inaczej niż w planie" trafia do notatek od razu. Po dwóch tygodniach nikt nie pamięta, czemu jedna VM ma inny kontroler dysku niż reszta.

Po migracji

Projekt nie kończy się w momencie, gdy ostatnia VM wstaje na Proxmoksie. Kończy się, gdy nowe środowisko jest zabezpieczone, przetestowane i udokumentowane, a zespół umie je obsługiwać.

• Wszystkie VM wpięte w politykę backupu PBS. Każda przeniesiona maszyna ma harmonogram w Proxmox Backup Server, z retencją i weryfikacją. Maszyna poza polityką backupu to incydent czekający na termin, więcej o samej strategii w artykule o backupie 3-2-1 z PBS.
• Test restore minimum jednej VM. Pełne odtworzenie z PBS na czystym zasobie i sprawdzenie, że system startuje i aplikacja działa. Tak samo jak przed migracją: backup bez testu restore to hipoteza.
• Test failover i HA. Jeśli macie klaster, kontrolowane wyłączenie węzła i obserwacja, czy VM przenoszą się zgodnie z oczekiwaniami. Lepiej zobaczyć to w teście niż przy pierwszej awarii zasilania.
• Przegląd wydajności po tygodniu. Porównanie metryk z pomiarem bazowym sprzed migracji. Tydzień realnego ruchu pokazuje to, czego nie pokaże żaden test syntetyczny.
• Dekomisja VMware dopiero po okresie karencji. Ustalcie z góry, jak długo stare środowisko stoi wyłączone, ale gotowe do startu. Dopiero po tym okresie kasujecie datastory i przeznaczacie sprzęt do innych zadań.
• Aktualizacja dokumentacji i runbooków. Procedury awaryjne, schematy sieci, lista kontaktów, instrukcje restartu usług. Wszystko, co wskazywało na vCenter, musi teraz wskazywać na Proxmox.
• Szkolenie zespołu. Administratorzy muszą swobodnie poruszać się po nowym środowisku zanim wydarzy się pierwsza awaria. Prowadzimy takie szkolenia z Proxmox jako element wdrożenia albo osobno.

Pytania, które słyszymy najczęściej