Migracja trudniejsza niż się wydaje

Minął już blisko miesiąc od momentu rozpoczęcia wdrożenia, aż wreszcie Nowacki i jego zespół uznali, ze są gotowi do rozpoczęcia migracji serwerów.

Zwłaszcza, że do tego czasu Serwiński przeprowadził sporo eksperymentów z VMware Converter, narzędziem wspomagającym migrację oprogramowania z serwerów fizycznych do maszyn wirtualnych, które jest standardowo dołączane do pakietu Virtual Infrastructure. Migracja kilku pierwszych serwerów przebiegła sprawnie i bez problemów.

Ale wkrótce okazało się, że wysoka wydajność i łatwość użycia tego narzędzia ma swoją cenę. Migracja ze starych serwerów fizycznych do nowych maszyn wirtualnych wyeliminowała niektóre wcześniejsze problemy związane ze sprzętem, ale jednocześnie wydawało się, że istotnie wzrosło znaczenie drobniejszych błędów, które nawarstwiły się przez lata działania systemu, gdy instalowano lub deinstalowano różne aplikacje i ich aktualizacje, a także wskutek znanego zjawiska zaśmiecenia samego systemu Windows.

W praktyce wyglądało to tak, że niektóre serwery pracowały bez zarzutu, ale inne działały zdecydowanie wolniej niż na starych komputerach.

Po serii dodatkowych testów i analiz sytuacji stało się jasne, że najlepiej pracują serwery w których system i aplikacje zostały zainstalowane względnie niedawno. Stąd wniosek, że w wypadku najstarszych maszyn funkcjonujących od dawna, lepiej odtworzyć ich konfigurację od podstaw kompletnie reinstalując system, aplikacje i dane.

Tego typu decyzja oznaczała jednak istotne wydłużenie planowanego wcześniej czasu migracji. Oprogramowanie VMware jest oczywiście wyposażone w narzędzia, które pozwoliły na zainstalowanie czystego serwera w kilka minut, ale to było najłatwiejsze zadanie.

Znacznie trudniej było przebrnąć przez dokumentację aplikacji by określić, jak została ona skonfigurowana podczas pierwotnej instalacji i co należałoby zmienić obecnie. W efekcie cała trójka administratorów spędziła znacznie więcej czasu na rozmowach telefonicznych z pracownikami wsparcia technicznego producenta aplikacji niż zajęło im nauczenie się instalacji i konfiguracji oprogramowania VMware.

Kolejne bolesne doświadczenie wynikło z wcześniejszej naiwności

Choć w czasie planowania starannie sprawdzono gwarancje zgodności sprzętu z systemem VMware, ale nikomu nie przyszło do głowy przeprowadzić analizę, czy producenci aplikacji oferują dla nich wsparcie techniczne w wypadku uruchamiania na serwerach zwirtualizowanych, a okazuje się, ze w niektórych po prostu go odmawiają.

Firmy te nie mają wątpliwości i nie wahają się udzielać wsparcia, gdy aplikacja jest uruchamiana pod kontrolą od lat nieaktualizowanego systemu operacyjnego lub korzysta ze starego sprzętu, który dyszy ostatkiem sił, ale wirtualizacji obawiają się jak ognia.

Przynajmniej częściowo ta ostrożność dostawców jest zrozumiała i administratorzy z działu IT wiedzą, że jeśli pojawią się jakieś problemy z wydajnością aplikacji związane ze sprzętem to będą musieli rozwiązać je sami albo zreplikować na serwerze fizycznym i dopiero wtedy żądać wsparcia technicznego.

W niektórych wypadkach okazuje się, że pracownicy wsparcia technicznego dostawcy oprogramowania po prostu słabo się orientują w problemach związanych z wirtualizacją i np. nie rozróżniają VMware Workstation lub Server od takich pakietów jak VMware ESX.

Ale jeden producent zdecydowanie i otwarcie odmówił wsparcia dla instalacji aplikacji na wirtualnym serwerze. Problem ten udało się jednak dość łatwo rozwiązać. Podczas kolejnej rozmowy dotyczącej instalacji i konfiguracji oprogramowania administratorzy Wirtpol po prostu w ogóle nie wspominali o wirtualizacji. W efekcie aplikacja została uruchomiona bez problemów.

Ta rezerwa, ignorancja lub odmowa wsparcia dla wirtualizacji spowodowały, że pracownicy działu IT poczuli się niezbyt komfortowo. Na szczęście, przynajmniej na razie, nie pojawiły żadne problemy, które można by wiązać z wirtualizacją.

Rozmawiając prywatnie Nowacki i Dyra przyznawali, że trochę nieświadomie wmanewrowali się w znacznie większą odpowiedzialność za działanie systemu IT, ale na obecnym etapie wdrożenia trudno się już z tego wycofać.

Etap 6: jakie nauki płyną z praktycznych doświadczeń?

Dopiero w pięć miesięcy od momentu, gdy zespół IT zaczął rozpakowywać pierwsze pudła z nowymi elementami sprzętu, wdrożenie zwirtualizowanego systemu zostało formalnie zakończone. Około półtora miesiąca zajęło dopasowywanie konfiguracji środowiska VMware tak by pracowało stabilnie, szkolenia i testowanie systemu. A aż trzy miesiące trwał proces ręcznej migracji aplikacji, przy założeniu, że mają one być bez większych przerw wciąż dostępne dla użytkowników.

Gdy realizacja projektu zbliżała się już do końca Nowacki zaczął się zastanawiać czy nie lepiej było skorzystać z usług zewnętrznych specjalistów by przyspieszyć wdrożenie.

Ale już pierwsze miesiące eksploatacji zwirtualizowanego systemu przyniosły Nowackiemu dość miłe zaskoczenie - sieć i serwery pracowały stabilniej niż można było oczekiwać. Oczywiście pojawiło się przynajmniej kilkanaście problemów związanych z drobnymi błędami w oprogramowaniu VMware, przede wszystkim dotyczącymi mechanizmów zarządzania, ale w sumie były one znacznie mniejsze i łatwiejsze do rozwiązania w porównaniu z wcześniejszymi problemami do których rozwiązywania pracownicy działu IT byli przyzwyczajeni.

Ciężka praca związana z przebudową infrastruktury praktycznie od podstaw miała też dodatkową ważną zaletę. Zespół IT został zmuszony do gruntownego odświeżenia swojej wiedzy na temat jego działania i zasad funkcjonowania wszystkich aplikacji. By nie stracić płynących z tego korzyści Nowacki zadbał o to by wszystkie etapy wdrożenia były starannie dokumentowane. Jeśli więc w przyszłości pojawi się konieczność kolejnej modernizacji technologii lub zasadniczej przebudowy architektury systemu to zespół IT będzie do tego lepiej przygotowany niż dotąd.