Instytucja publiczna, której koszty odnowień VMware wzrosły po zmianach licencjonowania, przeszła na klaster Proxmox VE z HA i centralnym backupem. Migracja falami, w nocnych oknach serwisowych, bez przerwy w usługach dla mieszkańców.
Klient to instytucja publiczna, która od lat prowadziła swoje systemy na infrastrukturze VMware. Po zmianach licencjonowania wprowadzonych przez Broadcom (rozliczenie per rdzeń, koniec licencji wieczystych, sprzedaż wyłącznie w subskrypcji) wycena kolejnego odnowienia okazała się wielokrotnie wyższa niż dotychczasowe koszty utrzymania. Dla jednostki działającej z budżetu publicznego taki skok wydatków był trudny do obrony, tym bardziej że nie szła za nim żadna nowa wartość dla użytkowników.
Środowisko obejmowało kilkadziesiąt maszyn wirtualnych i kilka terabajtów danych: systemy dziedzinowe, obieg dokumentów, usługi katalogowe, serwery plików i wydruku. Część z tych systemów obsługuje mieszkańców na bieżąco, więc twardym wymogiem projektu była ciągłość usług: żadnych przerw w godzinach pracy urzędu.
Wspólnie z zespołem IT instytucji wybraliśmy kierunek, który rekomendujemy w takich sytuacjach: migrację z VMware na Proxmox VE, poprzedzoną płatnym audytem z planem migracji. Szczegółowe porównanie obu platform opisaliśmy w artykule Proxmox vs VMware.
Projekt prowadziliśmy według naszego standardowego procesu, tego samego, który opisujemy w checkliście migracji z VMware.
Etap 0: inwentaryzacja. Zaczęliśmy od pełnej inwentaryzacji technicznej z mapą zależności: która maszyna z którą rozmawia, jakie usługi od siebie zależą, kto jest właścicielem biznesowym każdego systemu. To ta mapa zdecydowała o kolejności fal, nie alfabetyczna lista VM-ek.
Projekt docelowy. Zaprojektowaliśmy klaster Proxmox VE z wysoką dostępnością, z kworum i fencingiem skonfigurowanymi tak, żeby awaria pojedynczego węzła kończyła się automatycznym restartem usług na pozostałych. Do tego osobny Proxmox Backup Server jako centralny backup z deduplikacją i regularnymi testami odtwarzania.
Pilotaż. Pierwsza fala objęła wyłącznie maszyny niekrytyczne. Pilotaż wyłapał problem ze sterownikami w części maszyn Windows, zanim jakakolwiek produkcyjna usługa została dotknięta. Poprawiliśmy procedurę przygotowania VM i dopiero wtedy ruszyły kolejne fale.
Migracja falami. Produkcję przenosiliśmy w nocnych oknach serwisowych, fala po fali. Po każdej fali rano odbywały się testy akceptacyjne z udziałem użytkowników: logowanie, wydruki, kluczowe operacje w systemach dziedzinowych. Dopiero podpisany protokół testów zamykał falę.
Plan rollback. Każda fala miała przygotowany plan powrotu: źródłowe maszyny na VMware pozostawały nietknięte do czasu akceptacji, więc wycofanie zmiany sprowadzało się do ponownego uruchomienia oryginału. Sama obecność takiego planu zmieniała rozmowy z właścicielami systemów: zgoda na migrację przychodzi łatwiej, gdy droga odwrotu jest konkretna, a nie deklaratywna.
Dekomisja VMware. Po okresie karencji, w którym stare środowisko stało wyłączone, ale gotowe do startu, zdekomisjonowaliśmy hosty VMware. Część sprzętu wróciła do puli jako zasób testowy.
Najwięcej czasu nie zajmuje kopiowanie danych. Zajmują je ustalenia z właścicielami aplikacji: kto potwierdzi, że system działa, kiedy można go wyłączyć, co dokładnie przetestować rano po migracji. Transfer dysków to najbardziej przewidywalna część całego projektu, harmonogram rozstrzyga się w kalendarzach ludzi, nie w przepustowości sieci.
Pilotaż zwraca się natychmiast. Problem ze sterownikami, który wyszedł na maszynach niekrytycznych, na produkcji oznaczałby niedostępny system dziedzinowy w godzinach obsługi mieszkańców. Fala pilotażowa kosztuje jedno okno serwisowe, a zdejmuje z produkcji całą klasę niespodzianek.
Zacznijcie od audytu VMware z planem migracji: inwentaryzacja, mapa zależności, harmonogram fal i wycena. 5 000 zł netto, kwota odliczana od wartości migracji.
Zamów audyt VMware i plan migracji