Historia wirtualizacji, czyli od dużych maszyn do środowisk biznesowych

Wirtualizacja nie jest nowym wynalazkiem. Powstała w komputerach klasy mainframe. Odeszła w zapomnienie poza światem systemów typu UNIX, by pojawić się w środowisku x86.

Automat zarządza, wirtualizacja jest standardem

Ponieważ sam fakt uruchamiania maszyn wirtualnych jest już standardem w biznesie, nacisk kładzie się na automatyzację dostarczania zasobów i eksploatacji środowiska. Proces tworzenia maszyny, uruchamiania, zarządzania jej pracą, kontroli poprawności i ochrony przed naruszeniem bezpieczeństwa staje się zautomatyzowany, obejmując cały proces życia maszyny. Nieużywane serwery poza szczytem można wyłączyć, można również zapewnić aplikacjom odporność na pojedyncze awarie dzięki klastrom wirtualizacyjnym. Całością zarządza się z dopracowanego środowiska.

Pierwsze próby związane z wirtualizacją pochodzą z lat 60., gdy w firmie IBM pracowano nad oprogramowaniem CP-67. W tym czasie każde zadanie było wykonywane w formie wsadowej, z kart dziurkowanych, zatem w wielu przypadkach kosztowny sprzęt był wykorzystywany w niewielkim stopniu. Z kolei opracowanie systemu operacyjnego dla wielu użytkowników pracujących interaktywnie z wielodostępem czasowym było na tyle trudne, że inżynierowie stosowali tradycyjne podejście związane z uproszczeniem pracy wsadowej.

W roku 1964 rozpoczęto pracę nad systemem CP-40 dla komputerów mainframe System/360, który miał zapewnić równoczesną pracę maszyn wirtualnych. Umożliwiało to radykalne uproszczenie systemu operacyjnego eksploatowanego wewnątrz takiej maszyny, gdyż wystarczyło, by wspierał on pracę jednego użytkownika, zatem pasował idealnie do modelu pracy wsadowej. Kolejną wersją tego wczesnego hypervisora był system CP-67, dostarczający każdemu z użytkowników maszyny mainframe interaktywne narzędzie CMS (Conversational Monitor System). CP-67 umożliwiał współdzielenie pamięci, dostarczając także prywatnej przestrzeni adresowej. Był to bardzo poważny krok naprzód, gdyż wirtualizacja ułatwiała uruchamianie testowanych programów - w razie załamania aplikacji można było analizować zawartość pamięci wirtualnej, by efektywnie usuwać błędy.

Zobacz również:

  • 5 priorytetów, które obniżają koszty chmury i usprawniają operacje IT

Od testów do tworzenia aplikacji

Do roku 1972 ten hypervisor był jedynie projektem badawczym, wykorzystywanym wewnętrznie, dostępnym publicznie na licencji pseudo-open source. Początkowo nie planowano jego sprzedaży komercyjnej. Okazał się jednak tak ważnym produktem, że był używany częściej do testowania i tworzenia aplikacji niż do optymalizacji pracy wsadowej. Gdy ukazał się niemal 40 lat temu, stał się znacznie cenniejszy od osobno rozwijanego produktu separacji czasowej, gdyż oferował znacznie więcej - elastyczność i doskonałe wsparcie przy tworzeniu aplikacji.

Partycjonowanie stało się sławne

Następcą tej technologii jest logiczne partycjonowanie LPAR stosowane do dziś w maszynach i systemach firmy IBM. Jest to standardowa opcja serii System z. Nad podobnym rozwiązaniem pracowały także inne firmy, takie jak Hitachi Data Systems. W latach 80. stało się to typową opcją podziału obciążeń w komputerach klasy mainframe. Partycjonowane zasoby można modyfikować bez restartu komputera, przy czym możliwe są także bardzo głębokie zmiany, z redefinicją urządzeń włącznie. Partycjonowanie LPAR w maszynach IBM jest certyfikowane do poziomu Common Criteria EAL5, co odpowiada zestawom fizycznie rozłącznych maszyn.

LPAR to nie tylko mainframe

Technologia LPAR została w 2001 r. przeniesiona poza świat mainframe, pojawiając się w maszynach pSeries oraz iSeries, chociaż z nieco inną specyfikacją. Obecnie z LPAR mogą pracować różne systemy operacyjne, m.in. z/OS, z/VM, AIX i Linux. Ponadto przy systemach storage pojawiło się partycjonowanie zasobów, umożliwiające podział jednej fizycznej macierzy na wiele instancji wirtualnych, które można połączyć z partycjonowanymi systemami uruchomionymi na jednym komputerze.

Procesy wsadzone do więzienia

Gdy pojawiły się komputery klasy PC x86, początkowo wydajność procesora była zbyt mała, by wirtualizacja miała sens. Nie było nawet takiej potrzeby, gdyż zanim opracowano systemy z wielodostępem czasowym, obsługujące wielu użytkowników, standardem w świecie PC była stacja robocza z systemem MS-DOS i Windows 3.x oraz serwer plików Novell Netware. Dopiero w miarę wzrostu zainteresowania serwerami z procesorami klasy x86 pojawił się pomysł oddzielenia części procesów od siebie, by zadania, uruchomione w pewnym podzbiorze drzewa katalogów systemu UNIX, nie mogły wpływać na siebie. Koncepcja bardzo lekkiej wirtualizacji, polegającej na "zamknięciu w więzieniu", pojawiła się w darmowym systemie FreeBSD w roku 1999, a następnie była szybko rozwijana. Obecnie wiele systemów typu UNIX ma podobny mechanizm, umożliwiający wydzielenie części drzewa (chroot, jail, zone), a następnie oddelegowanie uprawnień do niego dla innego użytkownika. W takim chronionym podsystemie można przydzielić uprawnienia dla innego użytkownika, a jednocześnie uniemożliwić mu ingerencję poza środowisko, w którym pracuje. W ten sposób uzyskuje się wiele wirtualnych zestawów procesów, które nie mogą wpływać na siebie i nie widzą nic poza własnym środowiskiem wewnątrz jail.

Zamiast więzienia - zona

Pierwszym systemem, który komercyjnie wprowadził technologię jail, był Sun Solaris (tutaj nazywa się to zone), który skorzystał z pięcioletnich doświadczeń w systemie FreeBSD. Idea ta została także zaadaptowana do AIX 6, jest obecna w wielu dystrybucjach Linuksa. W odróżnieniu od pełnej wirtualizacji, którą zapewnia partycjonowanie w systemie AIX albo dzisiejsze maszyny wirtualne w środowisku x86, środowiska takie jak chroot czy zone mają za zadanie poprawę bezpieczeństwa. Jednocześnie cechują się niedużym narzutem mocy obliczeniowej oraz prostotą. Dzięki temu zyskały bardzo szybko zastosowanie w wielu środowiskach. Zony w systemie Solaris mogą działać zarówno w architekturze x86, jak i SPARC. W odróżnieniu od wirtualizacji x86 pracuje tutaj jeden obraz systemu operacyjnego, który w spójny i sprawny sposób zarządza pamięcią operacyjną. Jest to dobry model, w którym dla każdej usługi systemowej można przygotować osobną strefę bezpieczeństwa - w razie przełamania zabezpieczeń usługi system operacyjny nadal pozostaje bezpieczny. Separowane środowiska chroot/zone są stosowane do dziś w serwerach usługowych pracujących w systemach typu UNIX, gdyż jest to technologia sprawna, bezpieczna i ma nieduży narzut mocy obliczeniowej.

DOS na nowym komputerze?

Razem ze wzrostem mocy obliczeniowej procesorów pojawiły się nowe wydania systemów operacyjnych. W momencie przejścia z systemów bazujących na MS-DOS do 32-bitowych systemów na jądrze NT pojawiła się potrzeba uruchomienia starszych aplikacji. W Windows służył do tego specjalny mechanizm ntvdm, ale razem z rozwojem systemu Linux oraz FreeBSD pojawiła się potrzeba opracowania mechanizmu, który zapewniłby zgodność z systemem MS-DOS lub opracował wirtualizowane środowisko pracy. Powstałe przy tym narzędzia typu dosbox, QEMU i Bochs umożliwiły uruchomienie pełnej instalacji systemu MS-DOS, a także jego darmowego odpowiednika, jakim jest FreeDOS. Emulacja bywa realizowana na dwa sposoby - albo przez pełne emulowanie całej struktury procesora klasy x86 i typowych podzespołów komputera PC (tak robi to Bochs), albo przez emulację środowiska PC, przy czym kod jest uruchamiany w procesorze zgodnym z x86 (tak działa QEMU oraz Virtualbox). To pierwsze podejście umożliwia uruchomienie aplikacji napisanych dla x86 na innym sprzęcie, takim jak procesory RISC, ale ceną, którą się za to płaci, jest istotne spowolnienie działania hostowanego systemu i aplikacji. Jednak takie oprogramowanie umożliwia dobre debugowanie programu w niewidoczny dla niego sposób. Obecnie emulatory takie stanowią część wielu dystrybucji Linuksa, posiadają również swoje wersje dla systemów Windows. Z kolei hypervisor taki jak QEMU dokonuje w locie binarnej translacji kodu i jest znacznie sprawniejszy od emulatora. W miarę rozwoju tego oprogramowania oba podejścia znalazły swoje miejsce najpierw w sferze użytkowników akademickich, a później - korporacyjnych, z komercyjnym wsparciem technicznym.

Dobry pomysł, dobry program

Ponieważ wydajność procesorów stale rosła, niewielka wtedy firma VMware opracowała oprogramowanie przeznaczone do uruchamiania hostowanego wewnątrz maszyny wirtualnej systemu Windows na komputerach klasy x86 z systemem Windows oraz Linux. Jest to klasyczny hypervisor, który umożliwia uruchomienie maszyny wirtualnej na zgodnym procesorze, gdyż nie emuluje on wszystkich składników komputera z CPU włącznie. Ponieważ platforma x86 była standardem na desktopach i niedużych serwerach, firma VMware postanowiła opracować oprogramowanie właśnie pod kątem tej platformy. Wynikiem prac był pakiet VMware Workstation, VMware Server (GSX) oraz późniejszy VMware Player, przy czym równolegle opracowywano kompletny system wykorzystujący Linuksa wraz z odpowiednimi modułami i własnościowym oprogramowaniem VMware. Ten pakiet ewoluował, zyskując kolejne opcje i możliwości, a obecnie jest to VMware ESX. Najpoważniejszym problemem przy tworzeniu oprogramowania był fakt, że procesory x86 do niedawna nie zawierały sprzętowego wsparcia wirtualizacji (a to mają maszyny mainframe i większe serwery typu UNIX). W tym czasie nastąpił radykalny wzrost mocy obliczeniowej procesorów Intela i AMD, umożliwiający konsolidację zadań. Zamiast kupowania osobnego serwera pod kątem każdej aplikacji z osobna działy IT mogły już uruchamiać systemy w maszynach wirtualnych.

Inne projekty

Oprócz wirtualizacji w wykonaniu firmy VMware prowadzone były inne projekty, które również miały na celu opracowanie hypervisora dla środowiska x86. Takim projektem był Xen, który charakteryzował się o wiele prostszą konstrukcją niż ówczesne VMware GSX. Cały projekt hypervisora Xen został zakupiony przez firmę Citrix, która wzbogaciła kod o nowe opcje. Jest to jednocześnie hypervisor przeznaczony głównie do hostowania maszyn Windows, ale najważniejsza jego część jest objęta licencją open source. Znając założenia i standard sprawdzonego hypervisora Xen, firma Microsoft opracowała własny hypervisor, dodając go do serwerowego wydania Windows. Produkt ten znamy teraz jako Hyper-V. Chociaż jest spokrewniony pod względem niektórych własności z XenServerem Citriksa, jest napisany od nowa, na własnościowej licencji Microsoftu, tej samej, z której korzysta Windows. Obecnie Hyper-V stanowi standard wirtualizacji Microsoftu, z kolei Citrix XenServer wyposażono w dodatkowe opcje, których Hyper-V nie posiada.

Obecnie systemy x86 zbliżają się do możliwości dużych maszyn typu UNIX, ale LPAR nadal stanowi wzorzec wirtualizacji na maszynach mainframe i Power. Jest to część firmware systemu, przy czym wydajność jest tak duża, że z powodzeniem można równolegle hostować 40-50 wirtualnych partycji, przy czym wiele z nich może być klasy mission critical. Założenia znane z maszyn mainframe czy Power przechodzą także do systemów klasy x86 - oprogramowanie wirtualizujące umożliwia organizację serwerów w pule zasobów, między którymi maszyny są przenoszone w miarę potrzeb, by uzyskać oczekiwany poziom obciążenia i opcje niezawodności.

Komentarz

W nawiązaniu do wirtualizacji należy powiedzieć o głównych przyczynach powstania tej technologii. Było to poszukiwanie większej redundancji i bez-pieczeństwa danych na wypadek awarii; obniżenie kosztów energii elektrycznej; uniezależnienie się wirtualnych systemów operacyjnych od warstwy sprzętowej; możliwości dokładnego odwzorowania środowiska produkcyjnego na testowe przy małym nakładzie fi nansowym; a także zmniejszenie TCO i zwiększenie ROI. Wirtualizacja to również dążenie do obniżenia kosztów energii elektrycznej i utrzyma-nia systemów. Dziś koszty energii stanowią w 57% serwery, macierze, urządzenia sieciowe, a w 34% klimatyzacja. Wirtualizacja odpowiada na potrzeby minimalizacji kosztów, ale może się odnosić także do usług świadczonych biznesowi przez IT poprzez: zunifi kowanie katalogu usług; zapewnienie przewi-dywalności poziomu ich świadczenia i komplekso-wości zarządzania nimi; optymalne wykorzystanie infrastruktury; skrócenie czasu odpowiedzi IT na potrzeby biznesu oraz wzrost udziału inwestycji w innowacje. Analizujemy trendy rozwoju wirtuali-zacji, wiemy także, jakie oszczędności ona generuje, i razem z klientem możemy zbudować wartość dodaną poprzez wykorzystywanie wirtualizacji w realizowaniu projektów.

MACIEJ CHOMA, architekt IT, Biuro Architektury i Infrastruk-tury, ATENA Usługi Informatyczne i Finansowe

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200