Kiedy ktoś z zewnątrz słyszy o migracji serwera, zwykle wyobraża sobie weekend spędzony przy szafie rackowej, nowe maszyny, instalację oprogramowania i moment przełączenia użytkowników na nowe środowisko.
To oczywiście część całego procesu.
Ale z naszego doświadczenia wynika, że o powodzeniu migracji decyduje coś zupełnie innego.
Przygotowanie.
Po kilkudziesięciu zrealizowanych migracjach możemy powiedzieć jedno – sama technologia rzadko jest największym problemem. Problemy zaczynają się wtedy, gdy ktoś zakłada, że wszystko o swoim środowisku już wie.
A infrastruktura IT ma to do siebie, że lubi przypominać o rzeczach, o których wszyscy dawno zapomnieli.
Zaczynamy od pytania: co naprawdę działa w tym środowisku?
Dokumentacja jest bardzo pomocna.
O ile jest aktualna.
W praktyce często spotykamy dokumentację sprzed kilku lat, która nie uwzględnia nowych usług, dodatkowych serwerów czy zmian w konfiguracji. Czasem okazuje się, że jedyną dokumentacją jest administrator, który akurat jest na urlopie albo odszedł z firmy kilka miesięcy temu.
Dlatego pierwszym etapem nie jest instalacja nowego serwera ani przygotowanie platformy wirtualizacyjnej.
Najpierw poznajemy środowisko.
Sprawdzamy, jakie usługi działają, które z nich są krytyczne dla organizacji i jakie zależności występują pomiędzy poszczególnymi systemami.
Nie robimy tego z ciekawości.
Robimy to dlatego, że brak jednej pozornie mało istotnej usługi potrafi unieruchomić cały proces biznesowy.
Sama lista maszyn niczego nie gwarantuje
Inwentaryzacja to znacznie więcej niż eksport listy maszyn wirtualnych.
Chcemy wiedzieć, za co odpowiada każda z nich.
Czy jest kontrolerem domeny?
Serwerem plików?
Bazą danych?
A może wykonuje jedno zadanie dziennie, o którym nikt już nie pamięta, dopóki nie przestanie działać?
Kilka razy trafiliśmy na usługi, o których nikt już nie pamiętał. Dopiero ich wyłączenie pokazało, że od lat wykonywały niewielkie, ale krytyczne zadanie dla całego środowiska.
To właśnie na tym etapie najczęściej odkrywamy zależności, których wcześniej nikt nie był świadomy.
Im wcześniej je poznamy, tym spokojniej przebiega późniejsza migracja serwera.
Backup? Sprawdzamy, zamiast zakładać
Jedno z najczęściej zadawanych pytań brzmi:
„Czy macie backup?”
Prawie zawsze odpowiedź brzmi „tak”.
Drugie pytanie jest znacznie ciekawsze.
„Kiedy ostatnio ktoś odtworzył z niego dane?”
I tutaj bardzo często zapada cisza.
Nie dlatego, że backup nie istnieje.
Po prostu od lat nie było potrzeby jego wykorzystania.
Dlatego przed rozpoczęciem migracji nie ograniczamy się do sprawdzenia, czy kopie zapasowe są wykonywane.
Sprawdzamy również, czy można je odtworzyć.
To niewielka różnica w podejściu.
Ale właśnie ona decyduje o tym, czy backup będzie realnym zabezpieczeniem, czy tylko uspokajającym raportem wysyłanym codziennie na skrzynkę administratora.
Weekend nie rozwiązuje wszystkich problemów
Większość migracji realizujemy poza godzinami pracy klienta.
Najczęściej w weekend.
Nie dlatego, że tak wypada.
Po prostu daje to przestrzeń na spokojną weryfikację środowiska przed ponownym udostępnieniem go użytkownikom.
Ale nawet najlepiej wybrane okno serwisowe nie zastąpi przygotowania.
Jeżeli harmonogram jest nierealny albo nikt nie przewidział czasu na testy, sobota bardzo szybko zamieni się w niedzielę, a niedziela w nerwowe oczekiwanie na poniedziałkowy poranek.
Plan awaryjny powstaje jeszcze przed rozpoczęciem prac
Każda migracja jest inna.
Łączy je jednak jedna zasada.
Nigdy nie zakładamy, że wszystko przebiegnie idealnie.
Dlatego jeszcze przed rozpoczęciem prac przygotowujemy scenariusz powrotu do poprzedniego środowiska.
Mamy określone, w którym momencie można jeszcze bezpiecznie wycofać zmiany i kto podejmuje decyzję o takim kroku.
Paradoksalnie właśnie dzięki temu bardzo rzadko musimy z tego planu korzystać.
Nowa infrastruktura powinna rozwiązywać przyszłe problemy, a nie tylko obecne
Migracja infrastruktury IT to dobry moment, żeby spojrzeć kilka lat do przodu.
Czy obecny serwer ma zapas pamięci?
Czy wydajność macierzy będzie wystarczająca po uruchomieniu kolejnych usług?
Czy sieć nie stanie się wąskim gardłem?
To pytania, które warto zadać jeszcze przed zakupem sprzętu.
Podobnie wygląda planowanie migracji do Proxmox VE.
Sama instalacja platformy zajmuje stosunkowo niewiele czasu.
Znacznie więcej uwagi poświęcamy odpowiedzi na pytanie, jak będzie wyglądało to środowisko za trzy lub pięć lat.
Testy to ostatni etap przed przekazaniem środowiska
Nie kończymy migracji w momencie uruchomienia maszyn wirtualnych.
Sprawdzamy, czy wszystkie usługi działają poprawnie, czy użytkownicy mają dostęp do swoich zasobów, czy backup wykonuje się prawidłowo i czy nowe środowisko osiąga zakładaną wydajność.
Dopiero wtedy uznajemy projekt za zakończony.
Dokumentacja nie jest obowiązkiem. Jest inwestycją.
Na końcu powstaje dokumentacja.
Nie dlatego, że wymaga tego procedura.
Powstaje po to, żeby za rok kolejny administrator nie musiał od nowa odkrywać całego środowiska.
Dobra dokumentacja skraca czas reakcji na awarie, ułatwia rozwój infrastruktury i sprawia, że kolejne modernizacje są znacznie prostsze.
Dobra migracja zaczyna się dużo wcześniej
Migracja serwera nie zaczyna się od instalacji nowego oprogramowania.
Nie zaczyna się również od wyłączenia starego serwera.
Zaczyna się od zadawania pytań.
Co działa?
Co od czego zależy?
Co stanie się, jeżeli ten element przestanie odpowiadać?
Czy naprawdę potrafimy odtworzyć dane z backupu?
Dopiero kiedy znamy odpowiedzi na te pytania, możemy spokojnie przejść do właściwego wdrożenia.
Niezależnie od tego, czy planowana jest migracja do Proxmox VE, wdrożenie Proxmox czy modernizacja innej platformy wirtualizacji, jedno pozostaje niezmienne.
Dobra migracja zaczyna się na długo przed wyłączeniem starego serwera.