Migracja z VMware na Proxmox Rzeszów

Jak zaplanować migrację w zakładzie, który nie ma spokojnego tygodnia?

Odwracając zwykłą kolejność. W firmie z pracą jednozmianową najpierw powstaje harmonogram techniczny, a potem szuka się dla niego wolnego weekendu. U poddostawcy pracującego w ruchu ciągłym najpierw zbieramy listę przerw, które i tak wystąpią, a dopiero potem dopasowujemy do nich zakres prac.

Takich przerw jest więcej, niż się wydaje. Przezbrojenie między jednym zleceniem a drugim daje kilkadziesiąt minut, w których system wydający programy nie jest nikomu potrzebny. Przegląd okresowy maszyny daje okno dłuższe i znane z dużym wyprzedzeniem. Do tego dochodzą postoje z powodu oczekiwania na materiał, tygodnie o mniejszym obłożeniu i przerwy świąteczne, jeżeli zakład wtedy stoi.

Zbieramy ten kalendarz razem z osobą prowadzącą harmonogram produkcji, wpisujemy do planu projektu na równi z zadaniami technicznymi i traktujemy jako ograniczenie twarde. Migracja, która wchodzi w okno nieuzgodnione z produkcją, jest w takim zakładzie porażką nawet wtedy, gdy technicznie się udała.

Ile trwa przerwa przy każdym z Waszych systemów?

To jest pierwsza tabela, którą składamy po inwentaryzacji, i to ona wyznacza kolejność całego projektu. Nie interesuje nas w niej rozmiar dysku, tylko odpowiedź na pytanie, kto przestaje pracować.

System	Kto stoi, gdy zniknie na pół godziny	Kiedy przełączamy
Serwer wymiany programów z maszynami	operatorzy przy sterownikach, natychmiast	przezbrojenie albo przegląd maszyny
Baza systemu produkcyjnego	wydawanie i rozliczanie zleceń	postój materiałowy, zmiana o mniejszym obłożeniu
Kontroler domeny	logowanie na hali po kilkunastu minutach	dowolne okno, o ile drugi kontroler pracuje
Serwer dokumentacji technicznej	technolodzy i jakość, nie produkcja	dzień roboczy, po uzgodnieniu z biurem
Maszyna zbierająca dane z produkcji	nikt, dane nadrabiają się później	dowolne okno, także w trakcie pracy
Serwer kopii zapasowych	nikt bezpośrednio, rośnie ryzyko	okno dowolne, ale nie razem z inną migracją
Brama sieciowa i tunele	wymiana plików z odbiorcami	po godzinach pracy biura

Ostatnia kolumna powstaje we współpracy z Wami i to ona zwykle wydłuża projekt, a nie sama praca techniczna. Wiersz pierwszy przenosimy na koniec, mimo że kusi, żeby zacząć od rzeczy najważniejszej. Kolejność jest odwrotna: droga musi być przetarta zanim dotkniemy systemu, którego zatrzymanie widać na hali w minutę.

Co się dzieje, gdy maszyna nie wstaje przed początkiem zmiany?

Wraca stara, i to jest decyzja podjęta wcześniej, a nie w trakcie. Przed otwarciem każdego okna zapisujemy trzy rzeczy: godzinę, po której przerywamy i wycofujemy zmianę, objaw, który uznajemy za wystarczający powód do wycofania, oraz nazwisko osoby po Waszej stronie, która tę decyzję potwierdza.

Brzmi to formalnie, ale ma bardzo praktyczny powód. W środku nocy, przy systemie, który wstaje wolniej niż zwykle, każdy zespół ma naturalną skłonność do czekania jeszcze piętnaście minut, potem jeszcze piętnaście, aż zabraknie czasu i na uruchomienie, i na powrót. Ustalona wcześniej godzina usuwa ten mechanizm.

Sam powrót jest prosty, dopóki nie kasujemy niczego po starej stronie. Wyłączamy maszynę w Proxmoksie, włączamy ją na VMware i wracamy do analizy przy dziennym świetle. Zasoby po starej stronie zwalniamy dopiero po Waszej pisemnej akceptacji całości, więc ta droga jest otwarta przez cały projekt, a nie tylko w pierwszych dniach.

Co dzieje się z kopiami i monitoringiem, gdy środowisko jest w dwóch miejscach?

Przez kilka tygodni część maszyn stoi po nowej stronie, a część po starej i to jest normalny stan takiego projektu. Niebezpieczne jest w nim jedno: łatwo zostawić maszynę, która nie ma już kopii w starym systemie i nie ma jej jeszcze w nowym.

Dlatego kopie przepisujemy przed przeniesieniem, a nie po nim. Maszyna przechodząca w danym oknie ma zadanie kopii przygotowane po nowej stronie i uruchamiane pierwszej nocy, a stare zadanie wyłączamy dopiero po potwierdzeniu, że nowe zakończyło się poprawnie. Przez ten czas dane bywają zabezpieczone podwójnie i to jest koszt, na który świadomie się godzimy.

Tak samo traktujemy progi w monitoringu. Nowa maszyna trafia pod nadzór, zanim zacznie pracować produkcyjnie, z progami przeniesionymi ze starego środowiska i skorygowanymi po pierwszym tygodniu pomiaru. Środowisko bez monitoringu przez kilka tygodni migracji jest gorszym pomysłem niż odłożenie całego projektu.

Co zostaje na papierze po zakończeniu migracji?

Więcej niż w typowym projekcie i jest to świadome, bo w łańcuchu dostaw dokument bywa równie potrzebny co działający system. Zestaw wygląda tak samo przy każdym takim zleceniu.

Raport z przebiegu prac: co przeniesiono, w jakich oknach, ile trwała każda przerwa i co zostało zmienione po drodze. Zaktualizowany opis środowiska z klastrem, magazynem, siecią i zależnościami między maszynami. Procedury odtwarzania napisane pod nową platformę, sprawdzone w próbie, a nie przepisane z instrukcji producenta. Wynik odtworzenia losowej maszyny ze zmierzonym czasem. Wreszcie wpisy w rejestrze zmian, po jednym na okno, z zatwierdzeniem po Waszej stronie.

Ten komplet zamyka projekt i jednocześnie odpowiada na większość pytań, jakie przy najbliższym przeglądzie zada Wasz odbiorca. Nie powstaje na jego użytek, tylko przy okazji, i to jest najtańszy sposób, żeby taki dokument w ogóle istniał.

Odpowiedź na pytanie, czy w ogóle warto tę zmianę robić, znajdziecie na stronie Proxmox czy VMware. Postawienie środowiska od zera opisuje wirtualizacja serwerów, bieżący nadzór po odbiorze administracja serwerami, a kwotę miesięczną dla swojego środowiska sprawdzicie w kalkulatorze.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026