Migracja z VMware do Proxmox VE

Rosnące koszty utrzymania VMware były dla klienta impulsem do zmiany platformy wirtualizacji. Do przeniesienia pozostawało kilkanaście maszyn obsługujących systemy biznesowe, Active Directory i bazy danych. Celem było obniżenie kosztów oraz uproszczenie infrastruktury przy zachowaniu ciągłości działania usług.

Wybranym rozwiązaniem został Proxmox Virtual Environment, uzupełniony o Proxmox Backup Server. Projekt objął przygotowanie środowiska, migrację testową i produkcyjną, konfigurację klastra z wysoką dostępnością oraz uruchomienie backupu z testem odtwarzania. Ten przykład pokazuje, jakie elementy trzeba połączyć, aby zmiana hiperwizora przyniosła korzyść również w codziennym utrzymaniu.

Punkt wyjścia: kilka hostów i kilkanaście maszyn wirtualnych

Środowisko klienta działało na kilku hostach VMware. Kopie zapasowe wykonywano osobnym narzędziem, a koszty licencji i utrzymania rosły. Migracja miała uporządkować zarówno warstwę wirtualizacji, jak i sposób zabezpieczania danych.

Zakres prac obejmował:

• analizę istniejącego środowiska VMware;
• przygotowanie infrastruktury pod Proxmox VE, w tym sieci i storage;
• przeniesienie maszyn wirtualnych oraz sprawdzenie działania usług;
• konfigurację klastra i mechanizmów wysokiej dostępności, czyli HA;
• wdrożenie Proxmox Backup Server, harmonogramów kopii i testu odtwarzania.

Przy takim zakresie lista maszyn stanowi dopiero początek analizy. Aplikacja biznesowa może korzystać jednocześnie z bazy danych, usług katalogowych i zasobów sieciowych. Kolejność przenoszenia powinna uwzględniać te zależności, aby po uruchomieniu VM użytkownik mógł rzeczywiście wrócić do pracy.

Jak przebiegała migracja?

Przygotowanie środowiska docelowego

Pierwszy etap obejmował instalację Proxmox VE, konfigurację sieci i przestrzeni dyskowej oraz przygotowanie klastra. Dzięki temu migracja testowa odbywała się już na platformie przeznaczonej do dalszych prac.

W podobnym projekcie konfigurację sieci warto rozpisać jako przyporządkowanie: sieć źródłowa VMware, docelowy most sieciowy, VLAN oraz adresacja maszyny. Porównanie tego zestawienia z ustawieniami obu platform pozwala wychwycić brakującą sieć przed przełączeniem aplikacji. Po stronie storage potrzebne jest miejsce na dyski przenoszonych VM, ich przyrost oraz operacje przewidziane w wybranej metodzie migracji.

Migracja testowa i sprawdzenie kompatybilności

Następnie przeniesiono wybrane maszyny i wykonano testy wydajności oraz kompatybilności. Taki etap pozwala sprawdzić sposób migracji przed objęciem nim kluczowych systemów.

Proxmox VE udostępnia import maszyn z VMware ESXi oraz inne ścieżki przenoszenia, między innymi import OVF i dysków. Dobór metody zależy od konfiguracji źródłowej, rozmiaru danych i dopuszczalnej przerwy. Przed przełączeniem dysku systemowego na kontroler VirtIO SCSI system gościa musi mieć przygotowany właściwy sterownik; dotyczy to szczególnie Windows. Po migracji trzeba także uwzględnić możliwą zmianę identyfikacji karty sieciowej. Szczegóły opisuje dokumentacja migracji do Proxmox VE.

Test wydajności powinien odtwarzać tę samą czynność przed migracją i po niej: na przykład wykonanie raportu na tej samej kopii bazy danych. Zapisany czas w sekundach, przy porównywalnym obciążeniu i tej samej liczbie powtórzeń, daje użyteczny punkt odniesienia. Dopuszczalny czas wykonania należy ustalić z osobą odpowiedzialną za aplikację jeszcze przed testem.

Przeniesienie systemów produkcyjnych

Po etapie testowym przeniesiono kluczowe systemy, ograniczając przestoje i weryfikując działanie usług. Prace podzielono na etapy, zamiast traktować całe środowisko jako jeden niepodzielny transfer.

Czas kopiowania danych i czas niedostępności aplikacji to różne wielkości. Okno serwisowe musi pomieścić zatrzymanie zapisów, czynności wymagające wyłączenia źródłowej VM, uruchomienie systemu docelowego i odbiór aplikacji. Potrzebna jest również rezerwa na powrót do poprzedniego środowiska.

Plan powrotu powinien określać moment podjęcia decyzji i sposób zabezpieczenia danych. Jeśli użytkownicy rozpoczęli już zapisy w nowej bazie, ponowne uruchomienie starej VM pozostawi te zmiany poza systemem. Trzeba wtedy najpierw rozstrzygnąć sposób ich przeniesienia lub odtworzenia. Szerszy kontekst planowania dostępności przedstawia artykuł o migracji do Proxmox VE i ograniczaniu przestojów.

Uruchomienie backupu i test odtwarzania

Projekt obejmował wdrożenie Proxmox Backup Server, skonfigurowanie harmonogramów oraz test odtworzenia danych. W ten sposób nowe środowisko otrzymało również docelowy mechanizm wykonywania kopii.

Przy planowaniu takiego wdrożenia ochronę danych trzeba utrzymać przez cały okres przejściowy: zachować dostęp do dotychczasowych kopii i objąć nowe VM zadaniami backupu. Proxmox Backup Server jest osobnym systemem współpracującym z Proxmox VE. Jego zasoby oraz miejsce przechowywania kopii należy dobrać tak, aby awaria infrastruktury produkcyjnej nie odcięła jednocześnie możliwości odtworzenia.

W Proxmox Backup Server zadania Verify sprawdzają integralność danych kopii. Test odtworzenia powinien dodatkowo obejmować uruchomienie odzyskanej maszyny w odizolowanej sieci i wykonanie operacji w aplikacji. Czas od rozpoczęcia odtwarzania do gotowości usługi, zapisany w minutach, należy porównać z przyjętym maksymalnym czasem przywrócenia działania. Ustawienia kontroli kopii opisuje dokumentacja weryfikacji backupów.

Klaster HA: dostępność zależy od całej architektury

W opisanym wdrożeniu skonfigurowano klaster i HA. Przy projektowaniu takiego środowiska trzeba połączyć quorum, dostęp do dysków maszyn oraz zasoby umożliwiające przejęcie usług po awarii hosta.

Quorum oznacza wystarczającą liczbę głosów do podejmowania decyzji przez klaster. Dokumentacja Proxmox wskazuje co najmniej trzy węzły jako podstawę niezawodnego quorum dla HA. Konfiguracje dwuwęzłowe mogą korzystać z dodatkowego głosu QDevice, ale wymagają osobnego zaplanowania zachowania podczas awarii. Zasady te opisano w dokumentacji klastra Proxmox VE.

HA może uruchomić chronioną maszynę na innym dostępnym węźle po awarii. Aplikacja potrzebuje wtedy czasu na start i odzyskanie gotowości. Pozostałe hosty muszą mieć wystarczająco dużo pamięci i mocy obliczeniowej, a dane VM muszą być dostępne w miejscu jej uruchomienia. Samo dodanie serwerów do klastra nie rozwiązuje tych wymagań.

Jaką rolę odegrały kompetencje zespołu?

Migrację realizował zespół posiadający certyfikat Proxmox VE Clustering and Shared Storage. Zakres tych kompetencji odpowiadał istotnym częściom projektu: projektowaniu klastra, quorum, HA oraz doborowi przestrzeni dyskowej dla maszyn wirtualnych.

Znaczenie takiego przygotowania widać w konkretnych decyzjach: które maszyny mają być chronione przez HA, skąd uzyskają dostęp do danych i gdzie zostaną uruchomione po utracie hosta. Certyfikacja wspiera przygotowanie zespołu; poprawność konkretnej konfiguracji ocenia się przez testy jej działania.

Po czym poznać, że migracja jest zakończona?

Odbiór warto oprzeć na krótkiej liście czynności wykonywanych wspólnie z administratorem i właścicielem aplikacji. Poniższe kryteria można wykorzystać przy planowaniu podobnego projektu:

1. Na stacji testowej zalogować się kontem domenowym i otworzyć wymagany zasób sieciowy. Wynikiem ma być poprawne uwierzytelnienie oraz dostęp zgodny z uprawnieniami.
2. W aplikacji wykonać uzgodnioną operację testową, zapisać wynik i ponownie go odczytać. Odbiór powinien potwierdzać działanie całego procesu biznesowego, w tym połączenia z bazą.
3. Porównać czas wykonania wybranej operacji z pomiarem sprzed migracji. Wynik musi mieścić się w ustalonym wcześniej limicie, przy porównywalnych warunkach testu.
4. Odtworzyć kopię VM w odizolowanej sieci, uruchomić usługę i sprawdzić oczekiwany stan danych. Zmierzony czas przywrócenia powinien odpowiadać wymaganiom firmy.
5. Dla usług objętych HA przeprowadzić uzgodniony test awarii w kontrolowanych warunkach. Obserwować uruchomienie VM na innym węźle, gotowość aplikacji i obciążenie pozostałych hostów.

Wyniki tych czynności dają podstawę do zamknięcia okna migracyjnego i ustalenia, kiedy można wycofać źródłowe maszyny oraz dotychczasowe narzędzia.

Efekty wdrożenia i rzeczywisty koszt utrzymania

W tym projekcie przejście na Proxmox VE przyniosło obniżenie kosztów, uproszczenie obsługi środowiska, integrację z Proxmox Backup Server oraz przygotowanie infrastruktury do dalszej rozbudowy. Wspólny ekosystem wirtualizacji i backupu uporządkował wykonywanie kopii i ich odtwarzanie.

Skala oszczędności w kolejnym środowisku wymaga jednak własnego porównania. Należy zestawić koszty pozostania przy VMware z kosztami migracji, subskrypcji, sprzętu, backupu i pracy administratorów w tym samym okresie. Do kalkulacji trzeba również włączyć czas równoległego utrzymywania obu platform.

Proxmox VE jest oprogramowaniem open source dostępnym bez opłaty za korzystanie z platformy. Płatne subskrypcje zapewniają dostęp do repozytorium Enterprise, a zakres wsparcia zależy od poziomu. Rozliczenie subskrypcji opiera się na liczbie zajętych fizycznych gniazd CPU, bez opłat per rdzeń, per VM ani per użytkownik w ramach tego modelu. Nie zmienia to zasad licencjonowania systemów i aplikacji działających wewnątrz maszyn.

Do planowania wsparcia dla środowiska produkcyjnego można wykorzystać ofertę subskrypcji Proxmox. Wybór wariantu powinien uwzględniać znaczenie usług oraz kompetencje zespołu, który będzie je utrzymywał.

Kiedy warto rozważyć podobną migrację?

Dobrym momentem jest odnowienie umowy VMware, wymiana serwerów albo przebudowa backupu i dostępności. Wtedy można ocenić całość wydatków i zaplanować prace wspólnie, zamiast finansować kilka niezależnych zmian.

Przed decyzją należy porównać wymagania aplikacji z możliwościami platformy docelowej. Szczególnej uwagi wymagają zależności od konkretnych funkcji VMware, integracje narzędzi zarządzających oraz warunki wsparcia dostawców oprogramowania. Inny przykład połączenia migracji z decyzjami dotyczącymi storage i backupu przedstawia opis migracji VMware do Proxmox VE w Proacta.