Migracja ERP do prywatnej chmury.
Jak wygląda w praktyce?

Migracja systemu ERP do prywatnej chmury jest jednym z bardziej wymagających projektów infrastrukturalnych. Przenoszona jest nie tylko baza danych, ale cały zestaw usług odpowiedzialnych za sprzedaż, magazyn, produkcję, księgowość, raportowanie i integracje zewnętrzne.

Błąd popełniony podczas migracji może zatrzymać pracę wielu działów. Dlatego projektu nie należy traktować jak prostego kopiowania maszyny wirtualnej pomiędzy serwerami.

Dobrze przygotowana migracja obejmuje analizę obecnego środowiska, budowę platformy docelowej, testowe odtworzenie systemu, próby funkcjonalne, plan przełączenia produkcji i gotową procedurę powrotu do starego środowiska.

W PRO-Admin prywatne chmury dla ERP najczęściej budujemy w oparciu o Proxmox VE. Nie oznacza to jednak, że każdy system powinien otrzymać trzywęzłowy klaster z Ceph i SQL Server Always On. Architektura musi wynikać z rzeczywistych wymagań biznesowych, a nie z listy dostępnych technologii.

Kiedy warto rozważyć migrację ERP do prywatnej chmury?

Decyzja o migracji najczęściej pojawia się, gdy obecne środowisko zaczyna ograniczać rozwój firmy. Typowe powody to:

Migracja nie powinna jednak wynikać wyłącznie z przekonania, że własne serwery są zawsze tańsze.

Przed podjęciem decyzji warto porównać na co najmniej pięć lat koszt obecnego hostingu, licencje ERP, licencje Windows Server i SQL Server, zakup lub dzierżawę infrastruktury, administrację, backup, monitoring, kolokację, koszty przyszłej rozbudowy oraz koszt samej migracji. Sposób liczenia takiego porównania opisaliśmy w artykule Ile naprawdę kosztuje hosting systemu ERP?

Dopiero kompletna analiza TCO pokazuje, czy prywatna chmura ma ekonomiczne uzasadnienie.

Etap 1. Audyt obecnego środowiska

Profesjonalna migracja zaczyna się od zebrania informacji, a nie od instalacji Proxmoxa.

System ERP i jego wersja

Sprawdzamy nazwę i wersję systemu, wykorzystywane moduły, liczbę użytkowników, sposób licencjonowania, wymagania producenta, dostępność instalatorów, własne modyfikacje oraz dodatki dostarczone przez partnera wdrożeniowego.

Jest to szczególnie ważne w starszych środowiskach, w których część komponentów mogła zostać przygotowana indywidualnie i nie jest już dostępna w standardowej dystrybucji producenta.

Baza danych

Analizujemy wersję i edycję SQL Server lub innego silnika, rozmiar bazy, tempo jej wzrostu, model odzyskiwania, harmonogram backupów, czas wykonania pełnej kopii, czas odtwarzania, konfigurację logu transakcyjnego, najcięższe zapytania oraz blokady i opóźnienia storage.

Nie zmieniamy automatycznie takich elementów jak collation, poziom zgodności bazy czy model recovery. Każda taka zmiana musi być zgodna z wymaganiami producenta ERP i poprzedzona testami.

Integracje

Tworzymy listę wszystkich systemów współpracujących z ERP. Mogą to być:

Każda integracja może korzystać z określonego adresu IP, nazwy DNS, certyfikatu, katalogu wymiany albo konta serwisowego. Pominięcie jednej zależności może sprawić, że podstawowe funkcje ERP będą działały, ale proces biznesowy nadal pozostanie zatrzymany.

Infrastruktura

Sprawdzamy obecne serwery, procesory i pamięć, wydajność dysków, wykorzystanie sieci, system wirtualizacji, backup, monitoring, dostęp zdalny oraz wymagania dotyczące dostępności.

Celem jest zbudowanie środowiska na podstawie rzeczywistego obciążenia, a nie wyłącznie liczby użytkowników.

Etap 2. Ustalenie RPO, RTO i okna migracyjnego

Przed zaprojektowaniem architektury trzeba odpowiedzieć na trzy pytania.

Realny czas przestoju można oszacować dopiero po testowej migracji.

Etap 3. Projekt prywatnej chmury

Architektura docelowa może mieć różny poziom złożoności.

Proxmox VE obsługuje kilka metod migracji istniejących maszyn, w tym import zewnętrznych obrazów dysków i migracje P2V. Oficjalna dokumentacja opisuje zarówno migrację z innych platform, jak i import obrazów obsługiwanych przez qemu-img.

Nie każdy system potrzebuje jednak Ceph. Przy małej liczbie maszyn prostszy ZFS może zapewnić lepszy stosunek wydajności, kosztu i złożoności. Więcej o warstwach HA piszemy w artykule HA dla ERP.

Etap 4. Budowa środowiska docelowego

Po zatwierdzeniu projektu można rozpocząć wdrożenie. Zakres prac zazwyczaj obejmuje:

Środowisko powinno zostać w pełni przygotowane przed przenoszeniem systemu produkcyjnego.

Nowa instalacja czy konwersja starej maszyny?

To jedna z najważniejszych decyzji podczas migracji.

Proxmox umożliwia import obrazów dysków obsługiwanych przez qemu-img, ale sam import nie gwarantuje poprawnego uruchomienia aplikacji. Wybór powinien zostać dokonany po analizie obecnego środowiska, a nie według jednej uniwersalnej zasady.

Windows Server i sterowniki VirtIO

Maszyny Windows na Proxmox powinny korzystać ze sterowników VirtIO dla urządzeń dyskowych i sieciowych. Producent Proxmox zaleca używanie VirtIO w celu uzyskania lepszej wydajności niż przy urządzeniach emulowanych. Nowe wersje sterowników powinny zostać najpierw sprawdzone w środowisku testowym z realistycznym obciążeniem.

Przy konwersji istniejącej maszyny Windows sterownik kontrolera dyskowego trzeba przygotować przed przełączeniem systemu na VirtIO. W przeciwnym razie maszyna może nie uruchomić się po zmianie kontrolera.

Etap 5. Testowa migracja ERP

Testowa migracja jest najważniejszym etapem całego projektu. Jej celem jest przejście przez pełny proces bez wpływu na produkcję. Najczęściej wykonujemy:

1. 1 kopię aktualnej bazy,
2. 2 odtworzenie jej w środowisku testowym,
3. 3 przeniesienie aplikacji i załączników,
4. 4 konfigurację serwera aplikacyjnego,
5. 5 uruchomienie integracji w trybie testowym,
6. 6 pomiar czasu kopiowania i odtwarzania,
7. 7 testy funkcjonalne,
8. 8 analizę wydajności,
9. 9 przygotowanie listy poprawek.

Test pozwala zmierzyć faktyczny czas potrzebny na backup końcowy, transfer danych, restore, uruchomienie usług, testy i przełączenie użytkowników. Dopiero na tej podstawie można określić realne okno produkcyjne.

Kto powinien uczestniczyć w testach?

Sama informacja, że serwer odpowiada na ping, nie oznacza udanej migracji ERP. W testach powinni uczestniczyć przedstawiciele najważniejszych działów: sprzedaży, magazynu, księgowości, produkcji, logistyki i administracji systemem. Każdy zespół powinien sprawdzić swoje podstawowe procesy.

Przykładowe testy:

Testy powinny zostać zakończone formalną akceptacją osób odpowiedzialnych.

Etap 6. Plan migracji produkcyjnej

Po udanej próbie powstaje szczegółowy runbook. Powinien zawierać:

• -kolejność działań i godziny wykonania poszczególnych kroków,
• -osoby odpowiedzialne i dane kontaktowe,
• -sposób komunikacji,
• -listę usług do zatrzymania,
• -procedurę końcowego backupu,
• -sposób przełączenia DNS, adresów lub integracji,
• -testy odbiorowe i kryteria sukcesu,
• -kryteria uruchomienia rollbacku.

Każdy istotny krok powinien mieć właściciela i przewidywany czas wykonania.

Plan rollbacku

Migracja bez rollbacku jest eksperymentem na produkcji.

Plan powrotu powinien określać:

• -do którego momentu można bezpiecznie wrócić,
• -które dane powstałe po przełączeniu trzeba zachować,
• -jak ponownie uruchomić stare środowisko,
• -jak odwrócić zmiany DNS i integracji,
• -kto podejmuje decyzję o wycofaniu migracji.

Najważniejszy problem pojawia się po dopuszczeniu użytkowników do pracy w nowym środowisku. Od tej chwili w bazie pojawiają się nowe transakcje. Prosty powrót do starego serwera mógłby oznaczać ich utratę.

Dlatego decyzja o ostatecznym przełączeniu musi nastąpić przed rozpoczęciem normalnej pracy albo wymagać szczegółowej procedury synchronizacji danych.

Etap 7. Migracja produkcyjna

Przełączenie zazwyczaj realizuje się w uzgodnionym oknie serwisowym. Typowy przebieg wygląda następująco:

1. 1 potwierdzenie gotowości zespołów,
2. 2 zatrzymanie użytkowników i integracji,
3. 3 wykonanie końcowego backupu,
4. 4 backup logu transakcyjnego, jeśli jest stosowany,
5. 5 przeniesienie lub odtworzenie danych,
6. 6 uruchomienie SQL Server,
7. 7 uruchomienie serwera aplikacyjnego,
8. 8 uruchomienie integracji,
9. 9 wykonanie testów technicznych,
10. 10 testy użytkowników kluczowych,
11. 11 dopuszczenie pozostałych pracowników.

Nie zawsze migracja musi trwać cały weekend. W prostym środowisku przestój może wynosić kilka godzin. W rozbudowanym systemie z dużą bazą, WMS i wieloma integracjami może być znacznie dłuższy.

Nie należy obiecywać czasu 4 lub 8 godzin przed testowym przejściem całej procedury.

Jak ograniczyć przestój?

Możliwe metody zależą od środowiska i wspieranych technologii. Można wykorzystać między innymi:

Największe skrócenie przestoju zwykle nie wynika z szybszego kopiowania danych, ale z usunięcia niewiadomych podczas testowej migracji.

Etap 8. Stabilizacja po migracji

Migracja nie kończy się w momencie pierwszego poprawnego logowania. Przez kolejne dni należy obserwować wykorzystanie CPU i pamięci, opóźnienia storage, blokady SQL, czas wykonywania zapytań, błędy aplikacji, stan integracji, kolejki wymiany danych, backupy, działanie raportów oraz zgłoszenia użytkowników.

Nie należy od razu dokonywać wielu zmian optymalizacyjnych jednocześnie. Najpierw warto zebrać dane z nowego środowiska i porównać je z wartościami z testów.

Optymalizacja SQL Server po migracji

Po przeniesieniu bazy można zweryfikować max server memory, MAXDOP, cost threshold for parallelism, konfigurację TempDB, wzrost plików, opóźnienia danych i logu, Query Store, blokady oraz najcięższe zapytania. Szczegółowe zalecenia opisaliśmy w artykule SQL Server dla ERP.

Nie powinno się automatycznie zmieniać collation ani przebudowywać wszystkich indeksów tylko dlatego, że system został przeniesiony. Zmiany muszą być zgodne ze wsparciem producenta ERP i wynikać z pomiarów.

Backup po migracji

Przed rozpoczęciem normalnej pracy należy potwierdzić, że nowe środowisko jest chronione. Strategia powinna obejmować natywne backupy SQL, backup maszyn wirtualnych, Proxmox Backup Server, kopię poza główną lokalizacją, odpowiednią retencję, monitoring zadań i test odtwarzania - pełen schemat opisaliśmy w artykule Backup ERP.

Pierwszy test restore warto przeprowadzić wkrótce po migracji, a nie czekać na kwartalny harmonogram.

Licencje po przeniesieniu ERP

Migracja może wpływać na licencje systemu ERP, Windows Server, SQL Server, usług RDS, dodatków, oprogramowania backupowego i narzędzi integracyjnych.

Część licencji może być powiązana z adresem MAC, identyfikatorem sprzętu, nazwą serwera, liczbą rdzeni, liczbą użytkowników lub konkretnym środowiskiem hostingowym. Warunki trzeba zweryfikować przed migracją z producentem lub partnerem wdrożeniowym.

Szczególnie ważne jest prawidłowe licencjonowanie Windows Server i SQL Server w środowisku klastra oraz przy możliwości przenoszenia maszyn pomiędzy hostami.

Migracja z hostingu producenta

Migracja z hostingu może być trudniejsza niż przeniesienie własnego serwera. Przed rozpoczęciem projektu należy ustalić:

• -czy klient otrzyma pełną kopię bazy i w jakim formacie,
• -czy dostępne są pliki aplikacji,
• -czy można wyeksportować załączniki,
• -kto przekaże konfigurację integracji,
• -ile trwa przygotowanie danych i czy eksport jest dodatkowo płatny,
• -jak długo dostawca przechowuje stare środowisko,
• -czy licencje mogą zostać przeniesione.

Czasami dostawca udostępnia wyłącznie bazę, podczas gdy część aplikacji, skryptów i konfiguracji pozostaje w jego środowisku. Taki zakres trzeba rozpoznać przed przygotowaniem wyceny.

Migracja z serwera fizycznego

W środowisku fizycznym można rozważyć migrację P2V, czyli konwersję istniejącego systemu do maszyny wirtualnej. Proxmox opisuje techniki P2V oraz różne metody przenoszenia istniejących systemów do Proxmox VE.

Przed konwersją należy sprawdzić tryb startu BIOS lub UEFI, układ partycji, sterowniki kontrolera, aktywację Windows, stare agenty sprzętowe, oprogramowanie zależne od fizycznego urządzenia oraz stan systemu plików.

W starszym środowisku lepszym rozwiązaniem może być budowa nowej maszyny i migracja aplikacji zamiast zachowania całego systemu.

Najczęstsze błędy podczas migracji ERP

ERP może działać, ale nie działa WMS, bankowość lub wymiana z e-commerce. Pierwsza pełna próba w oknie produkcyjnym oznacza, że każdy problem wydłuża przestój. A stara platforma usunięta przed potwierdzeniem kompletności integracji, backupu i dokumentacji odbiera możliwość powrotu.

Ile trwa migracja ERP?

Projekt można podzielić orientacyjnie na:

• -analizę i projekt: od kilku dni do kilku tygodni,
• -budowę infrastruktury: od jednego do kilku tygodni,
• -migrację testową i poprawki: od kilku dni do kilku tygodni,
• -przełączenie produkcji: od kilku godzin do całego weekendu,
• -stabilizację: kilka tygodni.

Czas zależy od skali, dostępności dokumentacji, liczby integracji i współpracy producenta ERP. Podawanie uniwersalnego terminu bez audytu byłoby nierzetelne.

Ile kosztuje migracja ERP do prywatnej chmury?

Koszt projektu może obejmować audyt, projekt architektury, serwery, urządzenia sieciowe, storage, Proxmox VE, licencje Windows i SQL, backup, monitoring, migrację, prace partnera ERP, testy, dokumentację oraz opiekę po przełączeniu.

W małym środowisku można wykorzystać istniejącą lub dzierżawioną infrastrukturę i ograniczyć inwestycję. Rozbudowany klaster z trzema węzłami, redundantną siecią, Ceph, backupem off-site i wysokim SLA może kosztować znacznie więcej.

Z tego powodu jedna kwota, na przykład 130 000 lub 220 000 zł, nie opisuje całego rynku. Wycena musi wynikać z konkretnego projektu.

Kiedy migracja może się zwrócić?

Zwrot zależy od różnicy pomiędzy obecnym abonamentem, kosztem licencji, kosztami dodatkowych użytkowników i integracji a wydatkami na prywatną infrastrukturę, administrację, backup i modernizację po kilku latach.

W niektórych firmach inwestycja zwróci się po kilku latach. W innych hosting producenta pozostanie tańszy przez cały okres użytkowania.

Prywatna chmura może jednak przynieść korzyści, których trudno sprowadzić wyłącznie do ceny:

Co otrzymuje firma po prawidłowej migracji?

Efektem projektu powinno być nie tylko działające ERP. Firma powinna otrzymać:

Dopiero taki rezultat oznacza rzeczywiste przejęcie kontroli nad środowiskiem.

Podsumowanie

Migracja ERP do prywatnej chmury na Proxmox VE może poprawić wydajność, elastyczność i kontrolę nad infrastrukturą. Nie jest jednak prostą konwersją dysku ani weekendowym kopiowaniem bazy.

Bezpieczny projekt wymaga audytu, analizy TCO, projektu architektury, testowej migracji, udziału użytkowników kluczowych, współpracy partnera ERP, planu rollbacku, testów backupu i monitoringu po przełączeniu.

Proxmox może stanowić bardzo dobry fundament prywatnej chmury, ale liczba węzłów, rodzaj storage i mechanizmy HA powinny wynikać z RPO, RTO i kosztu przestoju.

W PRO-Admin rozpoczynamy takie projekty od analizy obecnego środowiska i pełnej listy zależności. Następnie przygotowujemy architekturę, migrację testową oraz szczegółowy runbook przełączenia. Dzięki temu decyzja o migracji opiera się na wynikach testów i konkretnych kosztach, a nie wyłącznie na założeniu, że prywatna chmura zawsze będzie lepsza.