Migracja z VMware na Proxmox Olsztyn

Dlaczego przy obiekcie sezonowym trudnością jest odbiór, a nie samo okno?

W większości firm najtrudniejszą częścią takiej migracji jest znalezienie czasu. Produkcja pracuje na zmiany, magazyn wydaje towar codziennie rano, a przerwa na przełączenie maszyny musi zmieścić się między jednym a drugim zadaniem. W warmińskim obiekcie ten problem praktycznie nie istnieje: od listopada do marca przestój nikogo nie kosztuje, okna serwisowe są długie, a nikt nie stoi nad głową.

Problem jest odwrotny i mniej oczywisty. Zimą po systemie nie chodzi żaden użytkownik, więc nie ma nikogo, kto zauważyłby, że drukarka fiskalna wybiera zły sterownik, że kalendarz obłożenia pokazuje ceny sprzed sezonu albo że potwierdzenia przestały wychodzić do gości. Środowisko przechodzi wszystkie testy techniczne i wygląda poprawnie, bo nikt nie próbował go użyć tak, jak używa się go w lipcu.

Dlatego w obiekcie sezonowym odbiór dzielimy na dwa etapy i dopiero drugi z nich zamyka projekt.

Jak wygląda harmonogram liczony wstecz od dnia otwarcia?

Termin otwarcia jest datą twardą, bo pierwsze rezerwacje przyjmuje się na długo przed nią. Wszystko inne układa się względem niej, a nie względem dnia podpisania umowy.

Kiedy	Etap	Co musi być gotowe
październik	spis środowiska i decyzja o zakresie	lista maszyn, zależności i wymagań licencyjnych
listopad	przygotowanie Proxmoksa i migracja próbna	klaster, magazyn, sieć oraz zmierzony czas kopiowania
grudzień i styczeń	przenoszenie maszyn po kolei	wszystkie systemy po nowej stronie, stare nadal żywe
luty	kopie, monitoring i odbiór techniczny	zadania kopii, progi alarmowe, próba odtworzenia
marzec i kwiecień	praca na nowej platformie bez gości	poprawki po pierwszych tygodniach, dokumentacja
pierwszy tydzień sezonu	potwierdzenie pod realnym obciążeniem	lista kontrolna recepcji, zgoda na wygaszenie VMware

Terminy przesuwają się w zależności od tego, kiedy obiekt faktycznie zamyka sezon, ale kolejność zostaje. Marzec jest ostatnim rozsądnym momentem na przenoszenie maszyn, bo w kwietniu obiekt zajmuje się przygotowaniem do otwarcia, a nie informatyką.

Kto sprawdzi, że system działa poprawnie, skoro nikt na nim nie pracuje?

Odpowiedź składa się z dwóch części i obie są konieczne.

Pierwsza to scenariusz testowy, który przygotowujemy razem z kierownikiem obiektu jeszcze przed migracją. Nie jest to lista usług do odhaczenia, tylko przejście całej drogi, jaką pokonuje rezerwacja: zapytanie z portalu, wpis w systemie, przydział pokoju, meldunek, obciążenie rachunku, wydruk dokumentu, wysłanie potwierdzenia na adres testowy i nocne zamknięcie dnia. Każdy z tych kroków dotyka innej maszyny i innej integracji, więc scenariusz wychwytuje rzeczy, których nie widać z panelu administracyjnego.

Druga część to lista kontrolna dla recepcji na pierwsze dni po otwarciu. Krótka, kilkanaście punktów, każdy do potwierdzenia jednym słowem. Czy drukarka wydała paragon, czy terminal się połączył, czy program otworzył się na wszystkich stanowiskach, czy gość dostał potwierdzenie. W tych dniach jesteśmy w podwyższonej gotowości i to jest część projektu, a nie osobna usługa.

Jak długo trzymamy stare środowisko?

Dłużej niż zwykle i to świadomie. Przy migracji w firmie pracującej cały rok zasoby VMware zwalnia się po odbiorze, bo odbiór odbywa się pod realnym obciążeniem i mówi wszystko, co trzeba wiedzieć. Tutaj odbiór wypada w lutym, w pustym obiekcie, więc mówi znacznie mniej.

Stare hosty zostają więc nietknięte przez zimę, przez wiosnę i przez pierwszy pełny tydzień pracy z gośćmi. Przez cały ten czas powrót jest decyzją na kilka minut: wyłączamy maszynę po nowej stronie, uruchamiamy starą, przenosimy dane z okresu przejściowego. Dopiero po tym tygodniu i po Waszej pisemnej zgodzie zwalniamy zasoby, a subskrypcję VMware zostawiamy do wygaśnięcia zamiast przerywać ją wcześniej.

Kosztuje to jeden sezon dłuższego utrzymywania starego sprzętu i jest to najtańsze ubezpieczenie w całym projekcie.

Co robimy z maszynami, które pracują tylko latem?

Nie przenosimy ich. System obsługujący wypożyczalnię sprzętu, stanowisko przy plaży albo obsługę wydarzeń zwykle pracuje kilka miesięcy w roku i przez pozostałe stoi wyłączony. Migrowanie takiej maszyny razem z całą jej historią oznacza przeniesienie także wszystkich zaległości: starych wersji bibliotek, ustawień po poprzednim dostawcy, zadań w harmonogramie, których nikt nie pamięta.

Zamiast tego budujemy ją po nowej stronie od nowa, z aktualnymi wersjami, i zapisujemy jako szablon do uruchamiania w kolejnych latach. Dane historyczne zostają w kopii archiwalnej. Efekt jest taki, że po migracji środowisko jest mniejsze, niż było, a maszyna sezonowa startuje w maju w stanie, który ktoś świadomie zaprojektował.

Przy okazji tego przeglądu zwykle odpada jeszcze kilka maszyn, których nikt nie używał od lat. Wyłączamy je na miesiąc, sprawdzamy, czy ktokolwiek się upomni, i dopiero potem gasimy na stałe.

Co dostajecie na koniec i za co płacicie

Na koniec dostajecie działające środowisko na Proxmoksie, dokumentację klastra, magazynu i sieci, procedury odtwarzania maszyn, przepisane zadania kopii oraz raport z przebiegu: co przeniesiono, ile to trwało i co zmieniono po drodze. Dostępy administracyjne są Wasze, więc dalsze prowadzenie środowiska możecie zlecić nam albo poprowadzić samodzielnie.

Płacicie za pracę jednorazową, liczoną od liczby maszyn, wielkości dysków i liczby systemów Windows wymagających sterowników. Sprzęt i opcjonalna subskrypcja wsparcia producenta są osobno, bo zostają Wasze niezależnie od tego, kto potem obsługuje środowisko.

Zanim podejmiecie decyzję o samej zmianie platformy, warto przeczytać porównanie Proxmoksa z VMware, gdzie zestawiamy koszt odnowienia z kalendarzem obiektu. Budowę i prowadzenie środowiska opisuje wirtualizacja serwerów, a codzienny nadzór nad maszynami po migracji administracja serwerami.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026