POLITECHNIKA ŚLĄSKA WYDZIAŁ INŻYNIERII MATERIAŁOWEJ I METALURGII

Kierunek: Informatyka Przemysłowa

Specjalność: Inteligentne systemy przemysłowe

Rodzaj studiów: Stacjonarne II stopnia

praca dyplomowa magisterska

Maciej STACHOWICZ

WIRTUALIZACJA APLIKACJI.

PORÓWNANIE TECHNOLOGII

Kierujący pracą: Recenzent:

dr inż. Marcin BLACHNIK prof. dr hab. Tadeusz WIECZOREK

Katowice, czerwiec, 2011 r.

Spis treści

1. Wstęp ................................................................................................................................... 5

1.1. Cel i zakres pracy ......................................................................................................... 6

2. Historia wirtualizacji. .......................................................................................................... 8

2.1. Wirtualizacja aplikacji - rozwój rozwiązań ................................................................ 11

3. Koncepcja wirtualizacji – opis, podział ............................................................................. 18

3.1. Wirtualizacja sieci ...................................................................................................... 20

3.1.1. Wirtualne sieci lokalne ....................................................................................... 21

3.1.2. Wirtualna sieć prywatna - VPN .......................................................................... 23

3.1.3. Wirtualizacja routerów – VRF ............................................................................ 24

3.1.4. Wirtualne przełączniki – VSS ............................................................................. 26

3.1.5. Wirtualne usługi sieciowe ................................................................................... 27

3.2. Wirtualizacja pamięci ................................................................................................. 27

3.2.1. Sposób implementacji wirtualizacji pamięci masowych ................................... 29

3.2.2. Metody wirtualizacji systemów pamięci masowych .......................................... 31

3.3. Wirtualizacja serwerów .............................................................................................. 31

3.3.1. Emulacja ............................................................................................................. 32

3.3.2. Parawirtualizacja ................................................................................................. 33

3.3.3. Pełna wirtualizacja .............................................................................................. 34

3.3.4. Wirtualizacja na poziomie hosta ......................................................................... 35

3.4. Wirtualizacja prezentacji ............................................................................................ 36

3.4.1. User State Virtualization ..................................................................................... 37

3.4.2. Wirtualizacja sesji i VDI ..................................................................................... 39

3.5. Korzyści wynikające z wirtualizacji .......................................................................... 40

4. Wirtualizacja aplikacji ....................................................................................................... 41

4.1. Środowisko standardowe, a zwirtualizowane ............................................................ 43

4.2. Narzędzia służące wirtualizacji aplikacji ................................................................... 47

4.2.1. Microsoft Application Virtualization .................................................................. 47

4.2.2. Symantec Workspace Streaming ........................................................................ 50

4.2.3. Endeavors Jukebox Application ......................................................................... 51

5. Badania eksperymentalne .................................................................................................. 54

5.1. Wykorzystane programy podczas testowania ............................................................ 54

5.1.1. Monitor wydajności ............................................................................................ 55

5.1.2. Pozostałe wykorzystane programy ..................................................................... 55

5.2. Metodologia wykonania badań ................................................................................ 58

5.3. Wyniki ........................................................................................................................ 60

5.3.1. Czas otworzenia głównego okna aplikacji .............................................................. 61

5.3.2. Obciążenie procesora............................................................................................... 63

5.3.3. Wykorzystanie pamięci operacyjnej........................................................................ 66

5.3.4. Generowany ruch sieciowy ..................................................................................... 68

5.3.5. Czas tworzenia zwirtualizowanej aplikacji ............................................................. 73

5.4. Wnioski .......................................................................................................................... 73

6. Podsumowanie ...................................................................................................................... 75

Spis rysunków ........................................................................................................................... 78

Spis wykresów .......................................................................................................................... 79

Spis tabel ................................................................................................................................... 80

Literatura ................................................................................................................................... 81

5

1. Wstęp

Instalacja oprogramowania to jedno z nielicznych zadań jakie należą

do obowiązków administratora zajmującego się stacjami roboczymi. Sam proces

instalacji oprogramowania w sposób tradycyjny jest bardzo żmudny i czasochłonny.

Proces ten wymaga od administratora podejścia do każdej stacji roboczej, wykonania

instalacji danego oprogramowania, opcjonalnie jeżeli jest to konieczne jego

konfiguracji. W przedsiębiorstwach posiadających stosunkowo małą ilość komputerów

sam proces instalacji oprogramowania nie zajmie wiele czasu, lecz będzie on wzrastał

wraz z ilością stacji roboczych. Kolejny aspekt związany z oprogramowaniem

znajdującym się na stacjach roboczych to zarządzanie nim. Konflikty między

aplikacjami, awarie stacji roboczych od strony sprzętu, czy to wynikające z błędnego

działania aplikacji. Ciągły rozwój oprogramowania, wydawanie przez producentów

nowych wersji, uaktualnień wprowadzających poprawy w działaniu programu.

Wszystko to powoduje, iż administracja stacjami roboczymi od strony znajdującego się

na niej oprogramowania, zarządzanie nim i utrzymywanie w stanie poprawnego

funkcjonowania jest procesem czasochłonnym i ciągłym w czasie. Obecnie istnieje

wiele rozwiązań mających na celu usprawnienie i ułatwienie zadań związanych

z dystrybucją oprogramowania na stacje robocze jak i zarządzania nim. Jak można

rozwiązać takie problemy? Skorzystanie z możliwości oferowanych przez GPO

(ang. Group Policy Object), czy też SCCM (ang. System Center Configuration

Manager), znacznie skracają czas potrzebny do instalacji na każdym komputerze

aplikacji jednak nie rozwiązują one pozostałych problemów. W przypadku tych

rozwiązań aplikacje przesyłane są do klienta przez sieć, a ich instalacja następuje

automatycznie. Idealnym w takich przypadkach wydaje się zastosowanie stosunkowo

młodej, ale prężnie rozwijanej technologii wirtualizacji aplikacji.

Wirtualizacja aplikacji pozwala na szybkie wdrożenie oprogramowania na stacjach

roboczych w przypadku dodawania nowych do istniejącej infrastruktury, bądź

wynikających z awarii już istniejących stacji roboczych, kiedy należy zapewnić

użytkownikowi nowe stanowisko pracy. Tak elastyczne i szybkie przygotowywanie

stacji roboczej pod kątem oprogramowania jakie się na niej znajduje wynika z faktu,

iż zwirtualizowana aplikacja jest odizolowana od systemu operacyjnego.

6

Ponadto wirtualizacja aplikacji daje możliwość efektywnego zarządzania licencjami,

co pozwala na lepsze kontrolowanie wykorzystania oprogramowania na które licencje

są ograniczone. Administrator ma możliwość określania takich rzeczy jak maksymalna

ilość stanowisk na której jednocześnie może zostać uruchomiona aplikacja, bądź

tworzenia licencji wygasających po określonym czasie.

Niniejsza praca przedstawia rozwój wirtualizacji i jej podział. A jej głównym celem

jest zaprezentowanie wybranych rozwiązań służących wirtualizacji aplikacji. Przybliża

ona sposób działania takiego rozwiązania, korzyści z niego płynącej nie tylko dla

administratora, ale i całego przedsiębiorstwa.

1.1. Cel i zakres pracy

Celem pracy było omówienie i porównanie stosowanych rozwiązań pozwalających na

wirtualizacje apliakcji.

Zakres pracy obejmuje omówienie opracowanych rozwiązań na bazie oprogramowania

Microsoft App-V, Symantec SWS oraz Endeavors Jukebox Application, Zakres ponadto

obejmuje testy porównawcze trzech przedstawionych platform pod kątem weryfikacji

wykorzystania zasobów serwera i klienta podczas uruchomienia zwirtualizowanej

aplikacji, oraz proces tworzenia zwirtualizowanej aplikacji na przykładzie aplikacji Matlab

2008A.

Praca obejmuje przedstawienie historii wirtualizacji wraz z rozwojem obecnie dostępnych

rozwiązań służących wirtualizacji aplikacji – w szczególności tych poddanych badaniom

w dalszej części pracy. Przedstawiony został podział wirtualizacji w oparciu o stos

logiczny sprzęt/oprogramowanie. Na tej podstawie został omówiony każdy z rodzajów

wirtualizacji, zwracając uwagę na sposób działania jak i na korzyści wynikające z danego

typu wirtualizacji. Oprócz bardzo popularnej wirtualizacji serwerów znalazło się miejsce

na wirtualizacje stacji roboczych, sieci, czy pamięci masowych. Rozdział 4 pracy został

poświęcony wirtualizacji aplikacji i wybranym rozwiązaniom. Przedstawione w nim

zostały różnice działania pomiędzy aplikacjom zwirtualizowaną oraz zainstalowaną

w sposób tradycyjny, wraz z korzyściami wynikającymi z wdrożenia rozwiązania

służącego do wirtualizacji aplikacji.

7

Ponadto rozdział ten zawiera przedstawienie rozwiązania firmy Microsoft, Symantec

oraz Endeavors. Sposobu i możliwości ich wdrożenia w zależności od wielkości sieci jak

i ilości docelowo wirtualizowanych aplikacji oraz wymaganych komponentów do

poprawnego działania.

Rozdział 5 zawiera informacje dotyczące środowiska testowego, w którym instalowane

były poszczególne rozwiązania oraz opis narzędzi które pozwoliły dokonać badań zużycia

zasobów.

Najważniejszym osiągnięciem pracy było dokonanie badań eksperymentalnych

pozwalających określić wykorzystanie zasobów serwera podczas dostarczania aplikacji do

stacji roboczych, jak i weryfikacja wykorzystania zasobów na jednej ze stacji roboczych

podczas uruchomienia aplikacji zwirtualizowanej jak i tej zainstalowanej w sposób

tradycyjny.

8

2. Historia wirtualizacji.

Początek rozwoju wirtualizacji można datować na lata 50 XX wieku. W tym czasie

w kilku kluczowych ośrodkach powstawały projekty będące zalążkiem tego co dzisiaj jest

powszechnie wykorzystywane. Pierwsze z istotnych wydarzeń w tej dziedzinie

to stworzenie systemu operacyjnego dla tranzystorowych komputerów mainframe Altas.

System opracowano na uniwersytecie w Manchesterze, przy współpracy firm Ferranti

i Plessey. Był to pierwszy system, który wykorzystał stronicowanie oraz pamięć

wirtualną.[1] Kolejne dwa projekty prowadzone również w latach 50 XX wieku to projekt

firmy IBM oraz MIT (ang. Massachusetts Institute of Technology). Firma IBM w 1963

roku stworzyła platformę sprzętową IBM M44/44X. Całość składała się z głównej

maszyny fizycznej M44 opartej o platformę sprzętową IBM 7044 oraz maszyn wirtualnych

(44X). Wówczas komputery 44X nazywane były "pseudo-machines" współdzieliły one

pamięć jak i oprogramowanie komputera głównego. Całe rozwiązanie było rozwiązaniem

czysto sprzętowym i polegało na dokładnym sklonowaniu komputera matki przez 44X.[2]

Kolejny projekt jak już zostało napisane wcześniej powstawał w Massachusetts Institute

of Technology. Pod przewodnictwem profesora Fernando Corbató niewielka grupa

programistów opracowała CTSS (ang. Compatible Time-Sharing System). CTSS jak samo

rozwinięcie akronimu wskazuje pozwalał na współdzielenie czasu procesora. Za sam

przydział zasobów i jego planowanie odpowiedzialny był program nadzorca. Badania

i rozwój CTSS został wsparty przez firmę IBM, co pozwoliło na przyspieszenie prac oraz

skupienie się na poprawie przydzielania zasobów przez program nadzorczy.[1]

W roku 1963 programiści MIT rozpoczęli prace nad kolejnym projektem o nazwie MAC

(ang. „Machine-Aided Cognition”). Głównym założeniem projektu było stworzenie na

bazie CTSS systemu MULTIC, który w przyszłości stał się systemem UNIX. Kolejne lata

to założenie Cambridge Scientific Center. W ramach tej instytucji rozpoczął się projekt

CP-40 jego wyniki zostały zaimplementowane w serwerach firmy IBM o nazwie

System/360 Model 40. Program kontrolny w tym przypadku pozwalał na uruchomienie 14

maszyn wirtualnych, dzielił on fizyczny dysk twardy na "mini-dyski" i prowadził kontrolę

dostępu do nich wykorzystując algorytm CWW.

9

Następne kroki rozwoju wirtualizacji to wprowadzenie przez IBM na rynek systemu

System/360 M67 wzbogaconego o moduł TSS (ang. Time Sharing System). Z racji iż

zespół z Cambridge nie miał dostępu do tego systemu dokonał on jego emulacji na

młodszym modelu M40. Tak powstał projekt CP/CMS. Rok 1970 to zapowiedź wydania

przez IBM systemu System/370, miał on mieć zaimplementowane wszystkie rozwiązania

wielozadaniowości i wirtualizacji, czyli TSS oraz CP/CMS. To właśnie przy pracach nad

wprowadzeniem System/370 pierwszy raz zostało użyte słowo "hypervisor". Określenie to

odnosi się do programu kontrolującego uruchamianie maszyn wirtualnych.[2] Lata 70 to

dynamiczny rozwój przez IBM System/370. W roku 1974 została wydana druga wersja,

dwa lata później trzecia. Następnie światło dzienne ujrzała wersja 5 System/370 – był to

rok 1977 oraz wersja szósta rok 1979. Kolejne lata to ciężka praca dla firmy IBM wiążąca

się z wprowadzaniem wielu poprawek do niestabilnego systemu VM/SP1.

W roku 1988 powstała firma Connectix Corp. (przejęta przez firmę Microsoft w roku

2003). To właśnie programiści tej firmy stworzyli program umożliwiający wirtualizację

systemów operacyjnych. Popularny dzisiaj Microsoft Virtual PC, początkowo służył do

uruchamiania systemu Windows na hoście z systemem Mac OS X. Kolejne lata to

powstanie firmy Citrix Systems, dziś jest to jeden z głównych graczy na rynku

wirtualizacji. Narodziny kolejnej znaczącej firmy w dziedzinie wirtualizacji to rok 1998,

kiedy grupa studentów biorących udział w pracach badawczych na Uniwersytecie

Standford w Kalifornii zakłada firmę VMware. Już rok później ukazał się pierwszy

z produktów cieszący się do dzisiaj duża popularnością Worksation. [1] Pisząc o takich

produktach jak VMware Workstation, czy Microsoft Virtual PC nie można zapomnieć

o Oracle Virtualbox. Program stosunkowo młody, bo stworzony w 2007 roku przez firmę

Innotek GmbH, dzisiaj jak już zostało wcześniej napisane wydawany pod logiem firmy

Oracle. Mimo krótkiego stażu na rynku wirtualizacji systemów operacyjnych, dynamiczny

rozwój programu zaowocował wydaniem wersji 4.0 w grudniu 2010 roku. I tak produkty

Virtualbox, Workstation i Virtual PC są dzisiaj głównymi graczami jeżeli chodzi

o programy umożliwiające tworzenie maszyn wirtualnych.

W kolejnych latach to również czołowi producenci procesorów przyczynili się do rozwoju

wirtualizacji implementując bezpośrednio w swoich produktach odpowiednie technologie.

Firma Intel w roku 2005 wypuściła na rynek pierwsze procesory (serii procesorów Pentium

4 662 i 672) z technologią wirtualizacji VT, znaną wcześniej pod nazwą kodową

"Vanderpool".

Z kolei AMD wprowadziło na rynek w 2006 roku grup

wspierających technologie wirtualizacji AMD

Na Rysunku 1 zostały zestawione wydarzenia

początkowy okres to rozwój odpowiednich technologii, dost

w obrębie dużych korporacji,

tamten czas infrastruktury. Kolejne lata to powstanie firm, które s

w dzisiejszych czasach.

Obecnie wirtualizacja mo

firmach, ale i przez użytkowników domowych

który w tej dziedzinie został zapocz

Rysunek

Wymienione wcześniej firmy tj. Citrix System

dostawcami rozwiązań z zakresu wirtualizacji w obcych czasach. Ka

wcześniej już firm posiada swoje flagowe produkty umo

systemów operacyjnych, czy aplikacji. Ponadto je

można tutaj wymienić

czy InstallFree. Każda z nich posiada mniej

służące wirtualizacji aplikacji.

rozwój kilku rozwiązań słu

Atlas

Rok 1958

Rok 1961

CTSS

Z kolei AMD wprowadziło na rynek w 2006 roku grupę pierwszych procesorów

cych technologie wirtualizacji AMD-V (wcześniejsza nazwa "Pacifica")

zostały zestawione wydarzenia, o których była mowa wcze

to rozwój odpowiednich technologii, dostępny

ych korporacji, które mogły sobie pozwolić na stworzenie kosztownej na

tamten czas infrastruktury. Kolejne lata to powstanie firm, które s

w dzisiejszych czasach.

Obecnie wirtualizacja może być wykorzystywana nie tylko w ś

firmach, ale i przez użytkowników domowych, wszystko dzięki post

który w tej dziedzinie został zapoczątkowany ponad pół wieku temu.

Rysunek 1. Ważniejsze wydarzenia dziedziny wirtualizacji

śniej firmy tj. Citrix Systems, VMware oraz Microsoft s

ą ń z zakresu wirtualizacji w obcych czasach. Każ

firm posiada swoje flagowe produkty umożliwiające wirtualizacje serwerów,

systemów operacyjnych, czy aplikacji. Ponadto jeżeli chodzi o wirtualizacje aplikacji

na tutaj wymienić takie firmy jak Symantec, Novell,

żda z nich posiada mniej, bądź bardziej rozpowszechnione produkty

ce wirtualizacji aplikacji. W kolejnym podrozdziale pracy został przedstawiony

ą ń służących wirtualizacji aplikacji.

IBM M44/44x

Rok 1963

Rok 1967

CP-40

Connectix Corp

Rok 1988

Rok 1989

Citrix Systems

10

ę pierwszych procesorów

niejsza nazwa "Pacifica").[2]

o których była mowa wcześniej. Jak widać

ępnych tylko i wyłącznie

ć na stworzenie kosztownej na

tamten czas infrastruktury. Kolejne lata to powstanie firm, które są dobrze znane

w średnich, czy małych

ęki postępowi technologii,

d pół wieku temu.

niejsze wydarzenia dziedziny wirtualizacji

, VMware oraz Microsoft są znaczącymi

z zakresu wirtualizacji w obcych czasach. Każda z wymienionych

ące wirtualizacje serwerów,

eli chodzi o wirtualizacje aplikacji

takie firmy jak Symantec, Novell, Endeavors, Xencode

bardziej rozpowszechnione produkty

W kolejnym podrozdziale pracy został przedstawiony

VMware

Rok 1998

11

2.1. Wirtualizacja aplikacji - rozwój rozwi ązań

Sama historia wirtualizacji aplikacji to nieustanna walka pomiędzy największymi

dostawcami w zakresie technologii wirtualizacji. W przeciwieństwie do maszyn

wirtualnych, wirtualizacja aplikacji to stosunkowo młoda dziedzina. Na początku XXI

wieku wiele firm posiadało już jakieś doświadczenie w zakresie dostarczania aplikacji do

stacji roboczych, posiadały takowe rozwiązania działające lepiej bądź gorzej,

bądź przymierzały się do opracowania takiego rozwiązania.

Najistotniejsze było zautomatyzowanie procesu instalacji oprogramowania,

wyeliminowanie konieczności podchodzenia administratora do każdej stacji roboczej

z nośnikiem w celu wgrania aplikacji i jej konfiguracji.

W roku 2001 firma SoftwareWoW (w późniejszych latach firma zmieniła nazwę

na Softricity) stworzyła oprogramowanie dające takie możliwości.[3] SoftGrid stworzony

przez zespół SoftwareWoW został wykupiony przez giganta z Redmond 17 kwietnia 2006

roku. Był to ważny krok dla firmy Microsoft w swojej strategii dotyczącej wirtualizacji.

Firma mogła pod swoim szyldem udostępnić koleje rozwiązanie tym razem upraszczając

zarządzanie aplikacji oraz ich dostarczanie do użytkownika końcowego.[4]

Pierwsze wersje SoftGrid były pisane jako oprogramowanie wieloplatformowe, pracowały

na serwerze opartym o system Unix, na którym znalazł się serwer WWW Apache.

Oficjalnie nigdy nie została wydana wersja SoftGrid oznaczona jako 1.0. Prace nad nią

trwały w czasie gdy firma nazywała się jeszcze SoftwareWoW. W tamtej wersji przed

uruchomieniem cała aplikacja musiała być przesłana do klienta, implementowała ona

również wszystkie potrzebne zmiany w rejestrze systemowym i usuwała je w chwili nie

wykorzystywania aplikacji. Zmiana nazwy firmy na Softricity to również zmiana wersji

tworzonego oprogramowania na 2.0. Z tą zmianą wiązało się stworzenie od podstaw

całego programu wraz z nową filozofią przesyłania aplikacji. Stworzony system plików

SFT pozwolił na "poprawne" przesyłanie plików do klienta, odtąd nie było potrzeby

przesyłania wszystkich plików, aby uruchomić aplikacje.[5] Wersja 3.0, która ukazała się

w 2003 roku to w głównej mierze poprawienie szybkości przesyłania aplikacji,

przeprojektowanie modułu izolującego aplikacje od innych. Wersja ta to również pełna

integracja z usługą Active Directory pozwalając tym samym na udostępnianie programów

określonym użytkownikom bądź grupom.[6]

12

Rok wydania Nazwa 2001 Softgrid 2.0 2003 Softgrid 3.0 2006 Softgrid 4.0 2008 App-V 4.5 2009 App-V 4.5 SP1 2010 App-V 4.6

Tabela 1. Kolejne wydania rozwiązania SoftGrid (App-V)

Tabela 1 przedstawia główne wersje programu dzisiaj znanego pod nazwą App-V.

Obecnie dostępna jest już wersja 4.6 wydana w ramach pakietu oprogramowania MDOP

przez firmę Microsoft. App-V stał się ważnym produktem firmy Microsoft pozwalając jej

zaistnieć na rynku wirtualizacji aplikacji.

Kolejnym graczem na tym rynku stała się firma Citrix. Dysponowała ona swoim

rozwiązaniem zapewniającym dostarczanie aplikacji użytkownikom. Technologia SBC

(ang. server-based computing) to technologia w której aplikacja znajduje się na serwerze,

na nim jest zarządzana oraz uruchamiana. Do klienta w takim przypadku przesyłane jest

tylko z serwera GUI danej aplikacji.[7] W 2001 roku Citrix Systems wydał MetaFrame

"XP" w wersji 2.0, rozwiązanie bazujące na technologii SBC. Pozwalało to potencjalnym

użytkownikom zrezygnować z instalacji aplikacji lokalnie, a dawało możliwość

przeniesienia ich na serwer. Główna wada tego rozwiązania wynikała z braku trybu offline.

Mówiąc inaczej użytkownik chcąc pracować z daną aplikacja musiał utrzymywać

połączenie sieciowe. Wynikały z tego sytuacje w których mimo tego, że aplikacja była na

serwerze, była również instalowana lokalnie na np. laptopach pracowników.

Odpowiedziom na ten problem było zapowiedzenie przez Softricity w 2003 roku trybu

offline w swoim rozwiązaniu, dzięki temu wykluczało to sytuację taką, jak w przypadku

rozwiązania firmy Citrix. Z racji na dobre relacje między obiema firmami postanowiono

połączyć korzyści płynące z obu rozwiązań. Firma Softricity udostępniła oprogramowanie

Zero Touch, które integrowało sposób dystrybucji aplikacji przez SBC z możliwością

wirtualizacji jakie dawał SoftGrid. Za pomocą interfejsu udostępnianego przez WWW

administratorzy mogli określić, która aplikacja w jaki sposób ma zostać dostarczona.

Po wykupieniu Softricity przez Microsoft oprogramowanie Zero Touch zostało wycofane

i współpraca obu firm została zakończona.[8]

13

Rok 2005 to rozpoczęcie przez firmę Citrix Systems prac nad projektem o kodowej nazwie

Tarpon. Projekt Tarpon to zestawienie technologii pozwalającej na tworzenie z aplikacji

"paczek" oraz ich przesyłanie do klienta. Uruchomienie aplikacji odbywało się w obrębie

Citrix Application Isolation Environment (AIE) na komputerze klienta. Główny powód

rozpoczęcia takiego projektu, wspomniany już wcześniej, to umożliwienie pracownikom

mobilnym uruchamiania aplikacji nie będąc podłączonym do sieci.[9] Ostatecznie

końcowy efekt projektu Tarpon stał się częścią Presentation Server 4.5 wydanego

w roku 2007.[10]

Rok wydania Nazwa

2001 MetaFrame XP 2002 MetaFrame XP FR1 2002 MetaFrame XP FR2 2003 MetaFrame XP Presentation Server 2004 MetaFrame Presentation Server 3.0 2005 Presentation Server 4.0 2007 Presentation Server 4.5 2007 Presentation Server 4.5 SP1 2008 XenApp 5.0 2010 XenApp 6.0

Tabela 2. Kolejne wydania rozwiązań firmy Citrix[8]

Odnosząc się jeszcze do firmy Citrix jak widać z Tabeli 2 rozwój oprogramowania

opartego na technologii SBC następował dość szybko, aż do stworzenia oprogramowania,

które opierało się na wirtualizacji aplikacji. Z biegiem lat i rozwojem tegoż

oprogramowania zmianom ulegała również jego nazwa, aż do obecnej dzisiaj XenApp

udostępnianej w wersji 6.0.

Kolejny ze znaczących w dzisiejszych czasach gracz rynku wirtualizacji to wspomniana

już wcześniej firma VMware, która została założona w 1998 roku przez Diane Greene.

Wymieniona w części tekstu dotyczącego początków wirtualizacji i maszyn wirtualnych

nie bez powodu. VMware (ang. Virtual Machine ware) przez długi czas swojej

działalności skupiał się na dziedzinie wirtualizacji związanej z systemami operacyjnymi.

Główny cel firmy to rozpowszechnienie i przeniesienie maszyn wirtualnych z mainframe

do komputerów osobistych. I w tym zakresie firma prowadziła swoje działania.

14

Jeden z flagowych produktów firmy VMware Workstation pozwalający na konfiguracje

i uruchamianie maszyn wirtualnych doczekał się w roku 2009 już swojej 7 wersji.[11]

W między czasie VMware wszedł na rynek z rozwiązaniami służącymi do wirtualizacji

serwerów tj. VMware GSX oraz VMware ESX. Zaistnienie na rynku związanym

z wirtualizacją aplikacji to rok 2008. W tym roku VMware wykupiło od firmy Jitit produkt

nazywany Thinstall. Pierwsza wersja tego oprogramowania została wydana w 2001 roku.

Początkowo program potrafił powiązać tylko biblioteki DLL z danym plikiem

wykonywalnym, w późniejszym czasie została wprowadzona koncepcja wirtualnego

rejestru. W wersji 3.0 została wprowadzona możliwość robienia "paczki" z danej aplikacji

na podstawie kopii migawkowej. Od roku 2008 aplikacja pod skrzydłami VMware

zmieniła nazwę na ThinApp i została ponownie wydana jako wersja 4.0.[12]

W porównaniu z wcześniej już przedstawionym rozwiązaniem firmy Citrix i Microsoft,

ThinApp nie pracuje w architekturze klient serwer. Rozwiązanie firmy VMware pozwala

na przygotowanie paczki z aplikacją, która następnie pracuje w swoim wirtualnym

środowisku. Wynikowa aplikacja ma postać pliku wykonywalnego, może być

rozpowszechniania i dystrybuowana jako portable. ThinApp nie wymaga instalacji

żadnego dodatkowego oprogramowania na hoście klienta.

Następny produkt z dostępnych w dzisiejszym czasie rozwiązań to Symantec Workspace

Streaming. Tak jak we wcześniejszych przypadkach nie jest to program stworzony od

podstaw przez firmę Symantec. Za początki tego, co dzisiaj firma Symantec udostępnia

w zakresie wirtualizacji aplikacji należy uznać program firmy FSlogic noszący nazwę

Protect. Pierwsza wersja programu została wydana w 2003 roku. Program znajdował

zastosowanie zarówno na komputerach domowych jak i tych znajdujących się

w przedsiębiorstwach. Program po uruchomieniu tworzył chronioną sesję. Wszystko co

znajdowało się na stacji roboczej – programy, ustawienia aplikacji, dane – od momentu

uruchomienia ochrony stawało się dostępne w trybie tylko do odczytu. Dzięki takiej sesji

wszelkie dane znajdujące się do tej pory na stacji roboczej były chronione przed zmianami.

Całość dla użytkownika była niewidoczna, sprawiało to wrażenie normalnej pracy

z systemem. Użytkownik mógł wprowadzać w systemie wszelkie zmiany tak jak do tej

pory, jednak były one przechowywane w obrębie chronionej sesji uruchomionej przez

program Protect. Rysunek 2 przedstawia oddzielenie sesji systemu od tej stworzonej przez

program Protect.

15

Po zakończeniu chronionej sesji komputer powracał do stanu sprzed jej uruchomienia.

Sesja tworzona przez program mogła być zapisywana tymczasowo bądź na stałe

w zależności od potrzeb użytkownika. Użytkownik danej stacji roboczej mógł powrócić do

swojej sesji, mając dostęp do zmian których dokonał w systemie. Program Protect

umożliwiał tworzenie wielu chronionych sesji na jednej stacji roboczej odizolowanych od

siebie. Istniała również możliwość importu/exportu danej sesji, dawało to możliwość

przeniesienia danej sesji na inną stację roboczą. Przy założeniu że jej "podstawowa"

konfiguracja była taka sama.[13]

Rysunek 2. Logicznie oddzielone obszary sesji chronionej i systemu

Tak wyglądał zalążek dzisiejszego rozwiązania firmy Symantec. W późniejszych latach

firma FSLogic Inc. została przejęta przez firmę Altiris. Firma Altiris powstała w roku 1998

po wydzieleniu jej z firmy matki KeyLabs. Zajmowała się ona zarządzaniem

oprogramowaniem w firmie KeyLabs, oraz rozwijała własne produkty ułatwiające takie

zadania.

W 2003 roku Altiris przejął korporacje Wise Solutions, Inc. i zajął się rozwojem jej

głównego produktu Wise. Po przejęciu FSLogic przez firmę Altiris program Protect

zostaje rozwinięty, a nazwa zostaje zmieniona na Software Virtualziation Solution. SVS

pozwalał na umieszczenie aplikacji w wirtualnych warstwach bez instalowania plików

w systemie operacyjnym. Takie rozwiązanie jest możliwe właśnie dzięki FSLogic Protect.

Aplikacja była umieszczana w zarządzanych warstwach nazywanych VSP (ang. Virtual

Software Package), pozwalało to na aktywacje, dezaktywacje danej aplikacji,

pozostawiając przy tym bazowe pliki systemu bez zmian. [14]

16

W 2006 roku AppStream rozpoczął współpracę z firmą Alitirs, od tego momentu

możliwym stało się wykorzystanie rozwiązania AppStrem w branży IT w połączeniu

z SVS. Wynikiem takiego połączenia była możliwość odizolowania aplikacji do siebie i od

systemu dzięki technologii wirtualizacji oraz ich dostarczenie do użytkownika końcowego

"na żądanie" dzięki rozwiązaniu AppStream.[15]

Finał omawianego rozwiązania to wykupienie zarówno firmy Altiris jak i AppStream

przez korporacje Symantec w 2007 roku. Od tego momentu oba rozwiązania są rozwijane

jako całość pod wspomnianą już nazwą Symantec Endpoint Virtualziation Suite.

Kolejnym i ostatnim z omawianych w tej części pracy rozwiązań jest Application Jukebox

firmy Endeavors Technologies. Z jednej strony rozwiązanie najmniej znane z dotychczas

opisywanych, z drugiej zaś sama firma określa się jako pioniera w dziedzinie wirtualizacji

aplikacji i dostarczania ich "na żądanie" do klienta. Korporacja powstała w 1996 roku,

jej założycielem był dr. Arthur S. Hitomi pracownik naukowy uniwersytetu znajdującego

się w mieście Irvine w stanie Kalifornia. Firma od początku istnienia zajmowała się

zagadnieniami związanymi z dystrybucją i przesyłaniem oprogramowania do klienta

końcowego. Endeavors przedłożyło swój pierwszy patent dotyczący strumieniowego

przesyłania aplikacji w roku 1997, został on nagrodzony w roku 2002. W między czasie

tj. w roku 2000 firma Tadpole Technology nabyła Endevadors. Współpraca obu firm

przyczyniła się do powstania rozwiązania nazwanego AppExpress pozwalającego na

przesyłanie aplikacji i ich wirtualizację oraz zarządzanie.

W kolejnych latach Tadpole nabywa firmę Stream Theory, Inc wraz z jej rozwiązaniem

StreamFlow. W późniejszych latach korporacja wykorzystała oba rozwiązania

(AppExpress i StreamFlow), aby wydać w 2008 roku swój flagowy produkt w zakresie

wirtualizacji aplikacji nazwany Jukebox Application. Rozwiązania dzięki którym powstał

Jukebox Application reprezentowały dwa odmienne sposoby interakcji z systemem klienta

oraz aplikacjami na nim się znajdującymi, które Jukebox łączy w sobie.[16]

Pierwsze z nich AppExpress wirtualizowało aplikacje w taki sposób, aby mogły one być

w pełni interaktywne i zintegrowane z systemem. Użytkownik końcowy miał wrażenie

że aplikacja zainstalowana jest w sposób lokalny. Aplikacja zwirtualizowana za pomocą

tego rozwiązania wchodziła w interakcje ze wszystkimi lokalnymi, czy sieciowymi

zasobami, oraz innymi aplikacjami nie zależnie od tego czy były one zwirtualizowane,

czy nie. Główny problem jaki nie został rozwiązany przy tego typu rozwiązaniu

z możliwością interakcji to konflikty między aplikacjami.

17

StreamFlow przeznaczony był do przesyłania i wirtualizacji gier uruchamianych

w odizolowanym środowisku - zapobiegało to konfliktom. Główną wadą tego podejścia

był stopień interakcji jaki aplikacja posiadała z systemem operacyjnym, czy innymi

aplikacjami. Z racji, iż oprogramowanie zwirtualizowane dzięki StreamFlow było

odizolowane od systemu operacyjnego nie mogło korzystać z zasobów komputera, czy też

nie mogła być w interakcji z innymi aplikacjami.[17]

3. Koncepcja wirtualizacji

W pierwszym rozdziale mówi

o maszynach wirtualnych, cz

pamięci wirtualnej w komputerze mainframe Altas. Jak wida

pojęcie odnoszące się do wielu

odnosić termin wirtualizacji w bran

pozostałych dzięki wprowadzeniu tzn. warstwy abstrakcji. W ten sposób zostaje

zwiększona elastyczność

Przedstawiając jeszcze bardziej rozwini

napisać, że produkty

przynajmniej kilka z głównych wymienionych punktów:

• dodają warstwę

• ich zastosowanie powoduje zmnie

• izolują zasoby komputera, czego efektem jest zwi

• eliminują redundancj

Rysunek

Aplikacja

Interfejs

System operacyjny

Pamięć

Sieć

Koncepcja wirtualizacji – opis, podział

W pierwszym rozdziale mówiącym o początkach wirtualizacji, moż

o maszynach wirtualnych, czy wirtualnych aplikacjach, jak i o pierwszym wykorzystaniu

ci wirtualnej w komputerze mainframe Altas. Jak widać wirtualizacja

ą ę do wielu aspektów, jednak nie zależnie od tego

termin wirtualizacji w branży IT oznacza odizolowanie jednego zasobu od

wprowadzeniu tzn. warstwy abstrakcji. W ten sposób zostaje

kszona elastyczność danego środowiska oraz uzyskuje się łatwiejsze zarz

ąc jeszcze bardziej rozwiniętą, ale mimo to ogóln

czy technologie dające możliwość wirtualizacji spełniaj

przynajmniej kilka z głównych wymienionych punktów:

ą warstwę abstrakcji pomiędzy oprogramowaniem, a sprz

ich zastosowanie powoduje zmniejszenie złożoności środowiska,

ą zasoby komputera, czego efektem jest zwiększenie niezawodno

ą redundancję i zwiększają wykorzystanie infrastruktury IT.

Rysunek 3. Zakres zastosowania wirtualizacji[19]

Aplikacja

Interfejs

System operacyjny

Pamięć

Wirtualne apliakcje

Prezentacja wirtualna

Maszyna wirtualna

Pamięć wirtualna

Sieć wirtualna

18

tkach wirtualizacji, można było przeczytać

ak i o pierwszym wykorzystaniu

wirtualizacja jest to szerokie

nie od tego, do czego będzie się

e jednego zasobu od

wprowadzeniu tzn. warstwy abstrakcji. W ten sposób zostaje

ę łatwiejsze zarządzanie.

imo to ogólną definicję można

ść wirtualizacji spełniają

a sprzętem,

ś środowiska,

ększenie niezawodności,

wykorzystanie infrastruktury IT.[18]

Wirtualne apliakcje

Prezentacja wirtualna

Maszyna wirtualna

Pamięć wirtualna

Sieć wirtualna

19

Rysunek 3 po lewej stronie przedstawia tradycyjny stos sprzęt/oprogramowanie, podczas

gdy prawa część rysunku przedstawia ten sam stos gdy zostanie użyta wirtualizacja.

Obrazuje to w prosty sposób, że wirtualizacja może być i jest stosowana na każdym

z poziomów tego stosu. Jak już wcześniej zostało napisane jest to szerokie pojęcie dlatego

też ciężko o mniej ogólną definicję wirtualizacji niż ta, która została przedstawiona. I tak

w przypadku sieci tradycyjnej jest ona przypisana do określonej lokalizacji, zaś sieć

wirtualna może pozwolić na lokalizowanie zasobów, które są rozproszone. W przypadku

pamięci jest ona przypisana do danej lokacji zaś ta zwirtualizowana pozwala na

zapisywanie danych i wykonywanie kopii zapasowych z wykorzystaniem sieci.

Aplikacje zainstalowane w sposób tradycyjny przypisane są do sprzętu i systemu

operacyjnego na którym zostały zainstalowane, z kolei aplikacja zwirtualizowana nie jest

w ten sposób przywiązana do systemu. Zwirtualizowana aplikacja może być dostępna na

każdym komputerze na żądanie.[19]

Na podstawie Rysunku 3 można w łatwy sposób stworzyć podział techniki wirtualizacji

w zależności od tego jakiego zasobu ona dotyczy.

Podział wirtualizacji wygląda następująco:

• wirtualizacja sieci,

• wirtualizacja pamięci masowych,

• wirtualizacja stacji roboczych,

• wirtualizacja serwerów,

• wirtualizacja aplikacji.

W dalszej części tego rozdziału na podstawie tak właśnie stworzonego podziału każdy

z rodzajów zostanie omówiony w celu lepszego zrozumienia koncepcji wirtualizacji.

Jedynym wyjątkiem w tym wypadku będzie wirtualizacja aplikacji. Z racji, iż jest to temat

którego ta praca dotyczy temu zagadnieniu poświęcony zostanie osoby rozdział.

20

3.1. Wirtualizacja sieci

Jak zostało przedstawione wcześniej w obecnych czasach, każdy z poziomów stosu

logicznego może i jest poddawany wirtualizacji, koncepcja ta dotyczy również sieci.

Wirtualizacja sieci polega na łączeniu dostępnych zasobów sprzętowych i programowych

oraz funkcji sieci w centralną jednostkę administracyjną. Odbywa się to poprzez dzielenie

dostępnego pasma na kanały, gdzie każdy jest niezależny od pozostałych.

Każdy z kanałów może być przypisany do dowolnego urządzenia, bądź komputera.

Każdy z nich jest niezależnie zabezpieczony oraz każdy użytkownik ma dostęp do

zasobów tej sieci z dowolnego komputera.[20] W przypadku wirtualizacji sieci można

mówić o rozwiązaniach typu "jeden do wielu", bądź "wiele do jednego". Dzięki pierwszej

grupie rozwiązań, jedna sieć fizyczna obsługuje wiele sieci wirtualnych. Zaś w przypadku

grupy "wiele do jednego" następuje konsolidacja (połączenie) wielu sieci.

Obok takich rozwiązań jak VPN, czy VLAN można mówić o:

• wirtualizacji routerów – VRF (ang. Virtual Routing/Forwarding),

• wirtualnych przełącznikach – VSS (ang. Virtual Switching System),

• wirtualnych usługach sieciowych.[21]

Rozwiązania takie jak VPN, czy VSS można przypisać do rozwiązań typu "wiele do

jednego", gdzie wiele różnych sieci fizycznych zostaje połączonych w jedną sieć logiczną.

Z kolei rozwiązania VLAN i VRF można zaliczyć do grupy "jeden do wielu", pozwalają

ona na segmentację i odseparowanie sieci od siebie. W dalszej części wymienione

rozwiązania zostaną omówione.

Wirtualizacja sieci spełnia kilka ważnych punktów, które zostały wymienione wcześniej.

Dzięki temu rodzajowi wirtualizacji zwiększona zostaje elastyczność wykorzystania

zasobów, wirtualizacja sieci umożliwia segmentacje sieci, a co się z tym wiąże poprawę

bezpieczeństwa takiej sieci. Wirtualizacja sieci pozwala na jej rekonfigurację w locie,

bez konieczności przełączania kabli, czy urządzeń. Ponadto możliwość dostępu zdalnie do

urządzeń daje dodatkowy atut w postaci uproszczonego zarządzania taką siecią.

21

3.1.1. Wirtualne sieci lokalne

Grupowanie użytkowników w sieciach LAN pozwala na odwzorowanie struktury

organizacyjnej przedsiębiorstwa, niezależnie od fizycznego rozlokowania działów firmy

w poszczególnych budynkach. Jednym z powodów takiego grupowania jest

bezpieczeństwo. Mogą zdarzyć się sytuacje w których osoby zarządzające

przedsiębiorstwem nie chcą, aby informacje z jednego działu były możliwe do

podsłuchania przez osoby postronne pracujące w innych działach firmy. Zaś nie zawsze

jest możliwość, aby pracownicy jednego działu znajdowali się w jednym segmencie sieci.

Kolejnym powodem dla którego warto stosować grupowanie użytkowników w sieciach

LAN to obciążenie sieci. Jeżeli istnieją działy firmy, które z jakichś powodów generują

dużo ruchu sieciowego warto odizolować je od innych, aby nie zalewać tym ruchem całej

sieci. Trzecim z powodów stosowania separacji jest ruch rozgłoszeniowy.

Ruch rozgłoszeniowy rośnie liniowo wraz ze wzrostem ilości komputerów w sieciach

LAN. Separując sieci LAN można ograniczyć ten rodzaj ruchu i uchronić się przed tzn.

"burzą transmisyjną" (ang. brodcast storm) w razie awarii karty sieciowej na skale całej

sieci LAN.[22] W celu zwiększenia elastyczności sieci i możliwości jej konfiguracji

w sposób logiczny, bez zmian fizycznych w strukturze sieci powstały wirtualne sieci

lokalne, popularnie nazywane VLAN (ang. Virtual Local Area Network).

Wirtualna sieć lokalna jest wydzieloną siecią logiczną, w obrębie danej sieci fizycznej.

Sieci VLAN mogą być tworzone na podstawie konkretnych stanowisk pracowników,

bądź działów w danej firmie niezależnie od tego gdzie fizycznie znajdują się użytkownicy.

Urządzenia w sieci VLAN komunikują się tylko i wyłącznie z urządzeniami należącymi do

tej samej lokalnej sieci wirtualnej, co zapewnia już wcześniej wspomniany wzrost

bezpieczeństwa. Na Rysunku 4 przedstawiona jest struktura z trzeba odrębnymi

wirtualnymymi sieciami LAN, co zapewnia niemożliwość podsłuchania ruchu

użytkowników będących w dwóch różnych wirtualnych sieciach lokalnych, a nie wymaga

stosowania osobnych przełączników dla każdego działu.[23]

22

Rysunek 4. Przykładowa struktura sieci

Do zapewnienia komunikacji między różnymi wirtualnymi sieciami LAN stosuje się

routery. Wirtualne sieci lokalne w zależności od sposobu dodawania użytkowników do

nich można podzielić na dwie grupy: statyczne i dynamiczne. W przypadku stycznych

wirtualnych sieci lokalnych administrator przypisuje dany port przełącznika danemu

użytkownikowi, z kolei w drugiej grupie, dynamicznej do konkretnego adresu fizycznego

(MAC) może zostać przypisana konkretna wirtualna sieć LAN. Nie wątpliwie do zalet

wirtualnych sieci lokalnych można zaliczyć ułatwienie zarządzania siecią oparta

o wirtualne sieci LAN oraz większe bezpieczeństwo takiej sieci. Co tyczy się zarządzania

można łatwo konfigurować sieci LAN, dodawać do nich kolejne stacje robocze, bądź

przenosić już istniejące.[23]

Wirtualne sieci lokalne stają się jeszcze bardziej przydatne jeżeli stosuje się je wraz

z wirtualizacją serwerów. W przypadku wirtualizacji serwerów maszyny wirtualne mogą

podlegać migracji, co skutkuje trudnościami w zarządzaniu taką strukturą. W związku

właśnie z tą dynamiczną i mobilną infrastrukturą w przypadku maszyn wirtualnych VLAN

staje się integralną częścią wirtualizacji. Aby ułatwić zarządzanie maszynami wirtualnymi

w takim środowisku wystarczy dodać wszystkie serwery fizyczne do wspólnej wirtualnej

sieci LAN wraz z maszynami wirtualnymi uruchomionymi na nich. W tym momencie

jakakolwiek migracja maszyn wirtualnych mimo tego, iż będzie się odbywać między

fizycznymi serwerami, które de facto mogą znajdować się w różnych oddziałach firmy,

będzie dokonana w obrębie jednej i tej samej wirtualnej sieci lokalnej. Ułatwi to

zapewnienie bezpieczeństwa, zarządzania i śledzenia migracji danych maszyn

wirtualnych.[24]

23

3.1.2. Wirtualna sieć prywatna - VPN

VPN (ang. Virtual Private Network) stosowane są w celu łączenia ze sobą odległych

od siebie komputerów w sieć lokalną. Znajduje to zastosowanie np. w przypadku

przedsiębiorstw mających siedziby w dwóch różnych lokalizacjach geograficznych.

Zestawienie VPN między tymi lokalizacjami powoduje, że wszystkie komputery

w rzeczywistości znajdujące się w dwóch różnych sieciach „widzą się” tak, jak by były

w tej samej sieci lokalnej. Rozwiązanie takie zapewnia pracownikom zdalnym dostęp do

firmowych serwerów. Sieci VPN korzystają z publicznej infrastruktury

telekomunikacyjnej. Wirtualne sieci prywatne stosowane są jako:

• sieci dostępowe - łączą zdalnych użytkowników: czyli pracowników mobilnych,

konsultantów, sprzedawców, lokalne filie, z siedzibą firmy,

• intranet - łączy odległe oddziały tej samej firmy,

• ekstranet - zapewnia ograniczony dostęp do sieci firmowej zaufanym partnerom

biznesowym.

Wyróżniamy sieci VPN typu Client – Site, gdzie kanał VPN zestawiany jest pomiędzy

komputerem pracownika zdalnego, a odległą siecią LAN.

Drugi typ to sieci typu Client – Client , gdzie kanał VPN zestawiany jest pomiędzy

dwoma odległymi sieciami LAN.

Można wyróżnić również dwie topologie sieci VPN tj. Mesh VPN oraz Hub & Spoke.

Mesh VPN – tunele VPN tak jak jest to pokazane na rysunku poniżej zestawiane są na

zasadzie każdy z każdym. Jeżeli pomiędzy danymi lokalizacjami wymagane jest stałe

połączenie (komunikacja) w przypadku takiej topologii bez punktu centralnego jeżeli

połączenie między oddziałem 1 i 2 zostanie utracone mają one możliwość na komunikacje

ze sobą inna drogą.

24

Rysunek 5. Po lewej topologia sieci VPN każdy z każdym. Po prawej topologia gwiazdy

Hub-Spoke (topologia gwiazdy) – w tej topologii istnieje punkt centralny zarządzający

i zestawiający połączenia VPN pomiędzy oddziałami. W tym przypadku z racji istnienia

punktu centralnego jego awaria powoduje zerwanie wszystkich tuneli VPN co skutkuje

zerwaniem komunikacji pomiędzy oddziałami.

3.1.3. Wirtualizacja routerów – VRF

Wcześniej już omówiona technologia sieci VLAN działa w warstwie drugiej

modelu OSI/ISO – warstwa druga operuje na adresach fizycznych stacji roboczych.

Zaś VRF tyczy się routerów, a co za tym idzie technologia ta dotyczy warstwy 3 modelu

OSI/ISO, która operuje na adresach IP. W typowym routerze istnieje jedna tablica

routingu, która przechowuje wszystkie statyczne trasy, jak i procesy routingu. Dzięki VRF

na routerze może istnieć kilka tablic routingu w tym samym czasie. Każda z wirtualnych

tablic VRF jest niezależna, mogą być do niej przypisane procesy i zakresy adresów,

jak i konkretne interfejsy sieciowe. Można wyróżnić dwie implementacje VRF Lite

i IPVPN.

Rysunek 6. Wiele VRF na jednym routerze

25

Rysunek 6 obrazuje router z dwoma wirtualnymi tablicami routingu oznaczonymi jako

VRF 1 i VRF 2. Pierwsza wirtualna tablica VRF odpowiada za przekazywanie pakietów

między interfejsem e1/0, e1/2, a interfejsem s2/0.102. Z kolie druga tablica routingu

przekazuje pakiety między interfejsem e4/2, s2/0.103 i s2/1.103. W tym samym czasie

dany interfejs nie może znajdować się w więcej niż jednej wirtualnej tablicy. Jak widać

VRF zapewnia odseparowanie ścieżek między danymi interfejsami.[25] VRF znalazł

głównie zastosowanie w budowaniu sieci VPN opartych na technice MPLS

(ang. Multiprotocol Label Switching). Jest to najpopularniejszy ze sposobu budowania

sieci VPN, opiera się ona na routerach brzegowych dostawcy usług. Na Rysunku 7 router

brzegowy dostawcy oznaczony jest jako PE, to właśnie w nim zaimplementowany jest

VRF.

Rysunek 7.Wykorzystanie VRF w implementacji sieci VPN opartej o technikę MPLS[26]

W przypadku łączenia dwóch oddziałów organizacji może okazać się, że każdy z VPN

wykorzystywanych w danym oddziale ma takie same adresy IP (korzysta z takiej samej

puli adresowej). W tym momencie trasowanie do konkretnej sieci VPN było by

niemożliwe z racji istnienia konfliktów adresów IP między danymi sieciami prywatnymi.

Aby zapobiec takim sytuacjom stosuje się właśnie wirtualne tablice routingu na routerach

brzegowych dostawcy. Na routerze PE znajduje się jedna tablica routingu dla sieci

publicznych, z kolei pozostałe tablice przeznaczone są dla konkretnych sieci VPN,

w ich obrębie odbywa się routingu odseparowany od innych VPN i Internetu.

26

W momencie połączenia się klienta z dostawcą (CE na rysunku to router brzegowy

klienta), w odpowiedniej dla niego tablicy VRF wyszukiwany jest adres jego

przeznaczenia, by określić jak go trasować. Tablica VRF uczy się tras od routera

brzegowego klienta wykorzystując dynamiczny protokół routingu.

Takie rozwiązanie zwiększa bezpieczeństwo, pozwala w intranecie na odseparowanie

działów przedsiębiorstwa od siebie. Ponadto rozwiązanie takie ma zalety takie jak

wirtualne sieci lokalne z tym, że w tym momencie dotyczy to warstwy 3 modelu OSI na

której pracują routery.[27]

3.1.4. Wirtualne przełączniki – VSS

W celu zwiększenia niezawodności sieci, często stosuje się celową nadmiarowość.

Zwiększanie nadmiarowości w odniesieniu do sieci odbywa się poprzez dublowanie

urządzeń sieciowych, zapewnianie zapasowego połączenia, czy stosując specjalne

protokoły takie jak RSTP (ang. Rapid Spanning Tree Protocol), HSRP (ang. Hot Standby

Routing Protocol), czy VRRP (ang. Virtual Router Redundancy Protocol).

Każdy z wymienionych nadmiarowych protokołów częściowo spełnia swoje zadanie

jednak pracują one w trybie "active-passive". Tryb ten polega na tym, iż jedna ścieżka

obsługuje cały ruch sieciowy, druga w tym czasie jest bezczynna, przejmuje ona zadania

pierwszej w przypadku jej awarii. Takie rozwiązanie powoduje, że zawsze ta jedna ścieżka

jest nie wykorzystana, co w rezultacie daje to, że 50% z dostępnej przepustowości nie jest

wykorzystywane. Stosowanie takich sposobów na redundancje w sieci, pociąga za sobą

jednak ogromną wadę, dodatkowa ilość urządzeń w infrastrukturze sieciowej to dodatkowy

czas jaki administrator musi poświęcić na zarządzanie taką siecią.

Problemy te eliminuje opracowana przez firmę Cisco technologia wirtualizacji

przełączników – Virtual Switching System, dzięki zastosowaniu technologii Multichassis

EtherChannel (MEC) eliminuje ona konieczność stosowania wymienionych protokołów

nadmiarowości. MEC sprawia, że urządzenia są widzenie w sieci jako jedno fizyczne

urządzenie. VSS w przeciwieństwie do protokołów redundancji sieci pracują w trybie

"active-active".[28] Za pomocą odpowiednich modułów, które tworzą wirtualne połączenie

VSL (ang. Virtual Switch Link) przełączniki widziane są w sieci jako jeden.

Oba przełączniki korzystają z jednego pliku konfiguracyjnego, który służy do zarządzania

wszystkimi portami.

27

3.1.5. Wirtualne usługi sieciowe

W sieci można również doprowadzić do izolacji zapór ogniowych, czy urządzeń

równoważących obciążenie. Tradycyjne wdrażanie kolejnych aplikacji na dedykowanych

urządzeniach typu firewall prowadzi do przyrostu urządzeń w sieci. Tak jak można

tworzyć wiele tablic routingu na routerach, wiele prywatnych sieci lokalnych na

przełącznikach tak również można postępować z oprogramowaniem. Firma Cisco

w przełącznikach Catalyst 6500 wprowadziła moduły FWSM (ang. Firewall Service

Module) oraz ACE (ang. Application Control Module). Pozwalają ona na uruchomienie

w obrębie jednego urządzenia wielu aplikacji. Każda aplikacja jest odizolowana od

pozostałych, zmiany w jednej nie mają wpływu na pozostałe. Catalyst 6500 może obsłużyć

wirtualne zapory sieciowe, wirtualne dekodery SSL jak i wirtualne oprogramowanie do

równoważenia obciążenia. Moduł FWSM przygotowany jest dla wirtualnych zapór

sieciowych z kolei moduł ACE wymagany jest przez dekodery SSL, oraz oprogramowanie

do równoważenia obciążenia. Na jednym urządzeniu może zostać uruchomionych

np. wiele instancji FWSM zwanych kontekstami, każdy z nich ma własny plik

konfiguracyjny, a działanie jednego nie ma wpływu na resztę. Korzyści jakie wynikają

z wirtualnych usług sieciowych to przede wszystkim konsolidacja.

Wdrażanie i konfigurowanie nowych urządzeń sprowadza się do prostych operacji jeżeli

mowa jest o urządzeniach wirtualnych.[21]

3.2. Wirtualizacja pami ęci

Kolejny z zasobów jaki może zostać zwirtualizowany to pamięć, jednak nie chodzi

tutaj o pamięć operacyjną stacji roboczych. Wirtualizacja zagościła w sektorze pamięci

masowych. Głównie wirtualizacja znalazła tutaj zastosowanie w obrębie technologii NAS

(ang. Network Attached Storage) i sieci SAN (ang. Storage Area Network). Zagłębienie się

w wirtualizacje w obrębie pamięci masowych wynikało z lawinowego przyrostu informacji

i danych, a zarazem z konieczności maksymalnego wykorzystania zasobów pamięci

masowych. W urządzeniach pamięci masowej dokonuje się proces tworzenia wspólnej

przestrzeni adresowej, w ramach wielu jednostek logicznych utworzonych na urządzeniach

pamięci masowej.

28

Wirtualizacje pamięci masowych można podzielić ze względu na miejsce jej

implementacji, jak i ze względu na to gdzie zachodzi wirtualizacja. Ze względu na miejsce

implementacji wyróżniamy:

• implementacje symetryczną w ścieżce danych (ang. in-band),

• implementację asymetryczną poza ścieżką danych (ang. out-band).

Z kolei jeżeli chodzi o podział ze względu na miejsce, w którym zachodzi sama

wirtualizacja można mówić o metodach:

• In-Fabric,

• In-Array,

• Host-Client.

Technologia wirtualizacji pamięci masowych oprócz swojej podstawowej funkcjonalności

jaką jest prezentacja zasobów dyskowych jako jedną przestrzeń daje możliwość

korzystania z wielu innych usług. Usługi te pozwalają na uproszczenie zarządzania

pamięciami masowymi jak i ochronę danych. [29]

Do usług tych należą:

• thin provisoring,

• wykonywanie kopii lustrzanej,

• kopie migawkowe,

• replikacja danych,

• hierarchiczne zarządzanie pamięcią.

Zastosowanie wirtualizacji pamięci masowych zapewnia szybsze wdrażanie – dyski

wirtualne mogą być w znacznie szybszy sposób zakładane, powiększane

czy przypisywane do danego hosta w odróżnieniu od tradycyjnych pamięci masowych.

Kolejna zaleta wirtualizacji pamięci masowych to bezproblemowa migracja danych,

która może następować bez konieczności wyłączania całego systemu, bez przerywania

pracy aplikacji i użytkowników.

29

Dzięki zastosowaniu wirtualizacji w tym obszarze administrator ma ułatwione

zarządzanie taką infrastruktura pamięci masowych, poprzez centralne zarządzanie,

dużo łatwiejsze staje się wykonywanie kopii zapasowych, czy replikacji.[30]

3.2.1. Sposób implementacji wirtualizacji pamięci masowych

W architekturze in-band, system wirtualizujący umieszczony jest pomiędzy

pamięciami masowymi, a serwerami, czyli jak już wcześniej zostało napisane na ścieżce

danych. System wirtualizujący w takiej architekturze pełni role pośrednika (proxy).

Rysunek 8. Implementacja symetryczna w ścieżce danych

Cały proces przetwarzania operacji wejścia/wyjścia rozpoczyna się w momencie

zainicjowania przez serwer komendy protokołu SCSI. Komenda ta skierowana zostaje do

docelowej jednostki logicznej LU (ang. Logical Unit). Przed dotarciem do docelowej

jednostki wszystkie komendy składowane są i przetwarzane w takiej kolejności w jakiej

zostały przesłane na urządzeniu dedykowanym na, którym znajduje się system

wirtualizujący. System ten następnie staje się inicjatorem połączenia wysyłając

odpowiednie komendy do docelowej jednostki podsystemu dyskowego. W architekturze

in-band wszystkie dane kontrolne wraz z właściwymi danymi przesyłane są tą samą

ścieżką. Ten właśnie sposób przesyłania może sprawić, że wąskim gardłem takiego

rozwiązania będzie dedykowane urządzenie do wirtualizacji.

30

Druga z metod implementacji wirtualizacji pamięci masowych oddziela od siebie

dane kontrolne i dane właściwe. Przesyłane są one osobnymi kanałami. Ścieżki te w tym

przypadku są od siebie odseparowane, a dedykowany system do wirtualizacji znajduje się

poza główną ścieżką przesyłania danych. Taka architektura wymaga często instalacji

dodatkowego oprogramowania – agentów, na serwerach wspierających wirtualizacje.[31]

Rysunek 9. Implementacja asymetryczna poza ścieżką danych

Z racji, że w tym przypadku właściwe dane przesyłane są bezpośrednio między serwerami,

a pamięciami masowymi z ominięciem systemu wirtualizacji eliminowane jest potencjalne

wąskie gardło. System wirtualizujący odpowiada tylko za przesyłanie danych kontrolnych.

Wydajność takiej architektury będzie zależeć od elementów składowych sieci SAN.

Dużą zaletą takiego rozwiązania jest mała ingerencja w już istniejącą sieć SAN,

po wpięciu do takiej sieci dedykowanego systemu wirtualizacji następuje odkrywanie

podsystemów dyskowych. Dystrybucja danych kontrolnych, konfiguracja puli adresów

i jednostek logicznych. Tego typu architektura pozwala na łatwe przejście z tradycyjnej

pamięci masowej do rozwiązania w którym jest ona zwirtualizowana.

31

3.2.2. Metody wirtualizacji systemów pamięci masowych

Pierwsza z metod wirtualizacji systemów pamięci masowych to metoda In-Fabric.

W tej metodzie wirtualizacją zajmuje się dedykowane urządzenie, bądź przełącznik

umieszczony w sieci SAN. Odpowiednie oprogramowanie rozpoznaje pamięci masowe

znajdujące się w danej sieci, tworzy metadane co pozwala administratorowi na zarządzanie

nimi jak jedną logiczną pulą adresów. W przypadku rozwiązań In-Fabric zagnieżdżonych

w przełącznikach wydajność wirtualizacji rośnie ponieważ nie ma takiej potrzeby,

aby dane dodatkowo były przesyłane przez dedykowany do tego system. Rozwiązania tego

typu mogą być implementowane w zróżnicowanym środowisku pod względem sprzętowy

i programowym (rozwiązania tzn. "cross-platform"). Daje to możliwość stworzenia wielu

wirtualnych pól. Zaś wadą tej metody jest pojawienie się w sieci dodatkowego urządzenia

w postaci dedykowanego systemu wirtualizacji co może wpłynąć na wolniejsze

przetwarzanie danych. W przypadku metody Host-Client w pamięciach serwerów plików

i aplikacji instalowane jest odpowiednie oprogramowanie do wirtualizacji danych.

Metoda ta pozwala na rozbudowę systemu wirtualizacji danych w miarę potrzeb może być

ona wykorzystywana do wirtualizacji danych w środowiskach Unix i Windows.

Wadą tej metody jest transfer dużych ilości metadanych przez sieć. W trzeciej metodzie,

In-Array jak sama nazwa wskazuje wirtualizacja pamięci masowych jak i wszystkie

operacje z tym związane odbywają się w macierzy. Dzięki temu sieć pamięci masowych

nie bierze udziału w wirtualizacji, przez co staje się ona wydajniejsza. Metadane w tej

metodzie przechowywane są w obrębie jednej macierzy dyskowej.[32]

.

3.3. Wirtualizacja serwerów

Jeżeli chodzi o wirtualizacje serwerów to istnieją cztery metody wirtualizacji w tym

zakresie. Można tutaj mówić o emulacji, pełnej wirtualizacji, parawirtualizacji

i wirtualizacji na poziomie hosta. Jednak zanim o tych metodach będzie mowa należy

przyjrzeć się chociaż w niewielkim stopniu pracy systemu operacyjnego w natywnym

trybie. Obecne systemy zapewniają różne poziomy dostępu do danych i zasobów. Poziomy

dostępu numerowane są od 0 do 3, tak jak zostało przedstawione na Rysunku 10.

32

Rysunek 10. Pierścienie dostępu

Kod który wykonywany jest w pierścieniu "0" ma najwyższe uprawnienia, może on

bezpośrednio odwoływać się do sprzętu. W pierścieniu "0" pracuje system operacyjny.

Z kolei pierścień "3" to pierścień nazywany usermode, w jego obrębie uruchamiane są

aplikacje, posiada on najmniejsze uprawnienia. Pierścień ten został przedstawiony

ponieważ w przypadku wirtualizacji serwerów/systemów operacyjnych jest ona również

ograniczona tymi zależnościami. W zależności od tego o jakim typie wirtualizacji

serwerów będzie mowa takie będą one wykorzystywać odpowiednie pierścienie.[33]

3.3.1. Emulacja

Emulacja polega na stworzeniu środowiska, które dla wirtualizowanego systemu

widoczne jest jak cały komputer. Każdy z elementów wirtualnego komputera jest

emulowany począwszy od BIOS'u, a skończywszy na CPU. Jak można zobaczyć na

Rysunku 11, emulator pracuje na poziomie innych aplikacji, czyli w pierścieniu uprawnień

oznaczony jako "3".

Dużą zaletą takiego rozwiązania jest możliwość emulowania systemów o innej

architekturze niż rzeczywista architektura komputera na której zainstalowany jest

emulator. Wadą z kolei jest mała wydajność emulowanego systemu.

33

Rysunek 11. Schemat przedstawiający emulacje

Z czasem emulacja ustąpiła miejsca wirtualizacji, a emulowane jest tylko to co nie może

zostać zrealizowane sprzętowo. Takie podejście sprawiło, że systemy zwirtualizowane nie

odbiegają znacznie od systemu rzeczywistego jeżeli chodzi o wydajność.[34]

3.3.2. Parawirtualizacja

Parawirtualizacja wykorzystuje w swoim działaniu program nadzorczy (hypervisor)

typu 1, program nadzorczy umieszczany jest między sprzętem komputerowym,

a systemem operacyjnym. Program nadzorczy w tym przypadku pracuje w obszarze

uprawnień pierścienia "0". Zaś co się tyczy zwirtualizowanych systemów pracują one

w pierścieniu "1". Aplikacje standardowo działają w obrębie uprawnień pierścienia

"3"[34]. Rysunek 12 prezentuje schemat działania parawirtualizacji.

Rysunek 12. Schemat przedstawiający parawirtualizacj ę

34

Mechanizm parawirtualizacji tłumaczy odpowiednie instrukcje zwirtualizowanego systemu

na odwołania programu dozorcy – odwołania te nazywane są hypercalls.

Z racji na ten mechanizm działania, aby system mógł zostać zwirtualizwoany za pomocą

parawirtualizacji należy zmodyfikować jego jądro. System taki musi posiadać

odpowiednio zmodyfikowane jądro, aby odwoływał się on nie bezpośrednio do sprzętu,

a do programu nadzorcy za pomocą odwołań hypercalls. Hypercalls to nic innego jak

odwołania z żądaniami do zasobów. Idea działania jest taka sama jak standardowych

wywołań syscall z tym, że w tym przypadku są one realizowane pomiędzy hypervisorem

i zwirtualizowanym systemem. Zaletą takiej metody wirtualizacji jest duża wydajność

zwirtualizowanego systemu. Wada tej metody wynika z konieczności modyfikacji jądra

wirtualizowanego systemu, ponieważ nie zawsze jest to możliwe.[34]

3.3.3. Pełna wirtualizacja

Pełna wirtualizacja może być realizowana w oparciu o hypervisor typu 1, wtedy jej

schemat będzie identyczny jak dla parawirtualizacji. Ta metoda wirtualizacji może być

również wykonywana w oparciu o program nadzorczy typu 2. Schemat pełnej wirtualizacji

z wykorzystaniem programu nadzorcy typu 2 został przedstawiony na Rysunku 13.

Rysunek 13. Schemat przedstawiający pełną wirtualizacje

Hypervisor typu 2 pracuje pod kontrolą rzeczywistego systemu operacyjnego.

W tym przypadku to system operacyjny udostępnia sprzęt i zasoby dla programu

nadzorczego. Wirtualizację przez hypervisor typu 2 realizuje się metodą binary

translation, direct execution bądź poprzez kompilacje.

35

Pierwsza binary translation polega na tłumaczeniu w locie instrukcji systemu

wirtualizowanego, które będą następnie wykonywane na procesorze za pomocą systemu

rzeczywistego.

Druga metoda to bezpośrednie wykonanie instrukcji systemu zwirtualizowanego

na systemie rzeczywistym – tak jak każda aplikacja. Trzecia metoda polega

na kompilowaniu instrukcji, które wykonywane są po raz pierwszy, każde kolejne

wywołanie takiej instrukcji to uruchomienie jej skompilowanej wersji. Pełna wirtualizacja

umożliwia uruchomienie każdego systemu operacyjnego. W tym przypadku nie jest

konieczne dokonywanie modyfikacji jądra wirtualizowanego systemu tak jak w przypadku

parawirtualizacji. Ten typ wirtualizacji nie zapewnia takiej wydajności jak w przypadku

parawirtualizacji.[34]

3.3.4. Wirtualizacja na poziomie hosta

Podstawową różnicą pomiędzy przedstawionymi do tej pory metodami

wirtualizacji, a wirtualizacją na poziomie hosta jest brak w tym przypadku programu

nadzorczego. We wcześniejszych sposobach zwirtualizowany system komunikował się

z systemem rzeczywistym, czy zasobami za pomocą specjalnej warstwy abstrakcji.

Brak warstwy abstrakcji eliminuje wszelkie różnice w wydajności pomiędzy systemami

zwirtualizowanymi, a rzeczywistym. Wirtualizacja tego typu inaczej nazywana jest

kontenerami (containers) bądź wirtualnym środowiskiem (virtual enviroment).

Schemat tego typu wirtualizacji został przedstawiony na rysunku 14.

Rysunek 14. Schemat wirtualizacji na poziomie hosta

36

Systemy zwirtualizowane w tym przypadku korzystają bezpośrednio z zasobów systemu

rzeczywistego. Robią to one w taki sam sposób jak system rzeczywisty.

Systemy zwirtualizowane korzystają w tym przepadku bezpośrednio z jądra systemu

rzeczywistego.

Oczywiście wszystko to dzieje się za przyzwoleniem systemu rzeczywistego.

Metoda wirtualizacji na poziomie systemu operacyjnego (inaczej na poziomie hosta) jest

funkcjonalnym i logicznym rozwinięciem funkcjonalności chroot z systemów UNIX.

Metoda ta traci trochę na elastyczności, ponieważ każdy zwirtualizowany system musi być

taki sam, jednak mogą one posiadać własne aplikacje.

3.4. Wirtualizacja prezentacji

W dzisiejszych czasach opisana wcześniej już wirtualizacja serwerów wchodzi coraz

szerzej w branże IT. Doczekała się ona również swojego odpowiednika dla stacji

roboczych. Wirtualizacja prezentacji inaczej określana jest jako wirtualizacja stacji

roboczych. W tradycyjnym modelu stacji roboczej, zainstalowany jest na niej system

operacyjny wraz z zestawem odpowiednich aplikacji, uruchamianych przez użytkownika.

Pomiędzy system operacyjnym, aplikacjami, danymi użytkownika i w końcu samym

interfejsem graficznym istnieje logiczne powiązanie. Zastosowanie wobec takiego modelu

wirtualizacji powoduje rozerwanie bezpośredniego powiązania odpowiednich warstw.

Bardzo często pod słowami "wirtualizacja stacji roboczych (desktopów)" kryje się

technologia VDI (ang. Virtual Desktop Infrastrukture), jednak jest to tylko jedna

z możliwych technologii do zastosowania w tym obszarze. Jak zostało napisane na

początku tego rozdziału pojęcie wirtualizacji jest dość obszerne co sprawdza się i w tym

przypadku. W przypadku wirtualizacji stacji roboczych oprócz infrastruktury wirtualnych

pulpitów możemy wyróżnić: wirtualizacje ustawień użytkownika – USV (ang. User State

Virtualization), wirtualizacje sesji, wirtualizacje aplikacji, czy wirtualizacje na

pojedynczych stacjach roboczych z wykorzystaniem maszyn wirtualnych.[35] Została tutaj

wymieniona wirtualizacja aplikacji, co nie jest błędem. Zwirtualizowana aplikacja nie jest

sztywno przypisana do danej stacji roboczej, może ona "wędrować" z użytkownikiem,

zatem można wirtualizacje aplikacji umieścić jako składową wirtualizacji stacji roboczych.

Z czasem wirtualizacja aplikacji zaczęła być wymieniana jak osobny zakres wirtualizacji,

w pracy tej poświęcony zostanie jej osobny rozdział.

3.4.1. User State Virtualization

W przypadku tradycyjnej infrastruktury, ka

swoje stanowisko pracy

Dla administratorów takie podej

wyzwaniem, tym bardziej je

roboczych są trudne do zarz

zapasowych – z pewnoś

o bezpieczeństwo takich danych

USV, które pozwala na przechowywanie danych u

Jest to dobre rozwiązanie w

komputerów. Z punktu widzenia u

każdym mieć dostęp do swoich plików.

typu wirtualizacji. Pierwszy z nich pozwala na w

drugi zaś bazuje na przekierowywaniu folderów.

Roaming User Profil

przemieszczanie się profilu danego u

każde konto ma swój profil. W zale

przechowywania profilu uż

w ścieżce " C:\Documents and Settings"

"C:\Users". Znajdują się tam ustawienia u

podział tych danych oraz to

Dane

dokumenty, zdjęcia, pliki, muzyka, prezentacje itd.

User State Virtualization

W przypadku tradycyjnej infrastruktury, każdy użytkownik w organizacji

swoje stanowisko pracy wyposażone w stacje roboczą na której przechowuje swoje dane.

stratorów takie podejście gdzie dane są zdecentralizowane, jest du

wyzwaniem, tym bardziej jeżeli ilość stacji roboczych jest duża. Dane rozsiane na stacjach

trudne do zarządzania. Trudności mogą pojawić się przy wykonywaniu kopii

z pewnością będzie to proces czasochłonny. Ciężej jest

stwo takich danych.[36] Rozwiązaniem tych problemów jest zastosowanie

USV, które pozwala na przechowywanie danych użytkownika na jednym serwerze.

ązanie w parze z wirtualizacją aplikacji w jednolitym

komputerów. Z punktu widzenia użytkownika może on zmieniać stanowisko pracy i na

ęp do swoich plików.[36] System Windows wspiera dwie

Pierwszy z nich pozwala na wędrowanie profili u

bazuje na przekierowywaniu folderów.

(RUP), określone wcześniej jako technologia pozwalaj

ę profilu danego użytkownika wraz z nim. Pracuj

de konto ma swój profil. W zależności od systemu operacyjnego ró

przechowywania profilu użytkownika. Dla Windows XP profil użytkownika znajduje si

Documents and Settings", a dla nowszych system

ą się tam ustawienia użytkownika i jego dane. Rysunek

podział tych danych oraz to, co mogą zawierać.[37]

Rysunek 15. Składowe profilu użytkownika

Profil użytkwonika

Dane

dokumenty, zdjęcia, pliki, muzyka, prezentacje itd.

Ustawienia

związane z systemem operaycjnym, związane z

apliakcjami

37

ytkownik w organizacji posiada

na której przechowuje swoje dane.

zdecentralizowane, jest dużym

ża. Dane rozsiane na stacjach

zy wykonywaniu kopii

ężej jest również zadbać

zaniem tych problemów jest zastosowanie

ytkownika na jednym serwerze.

w jednolitym środowisku

ć stanowisko pracy i na

System Windows wspiera dwie metody tego

drowanie profili użytkowników,

niej jako technologia pozwalająca na

Pracując na komputerze

ci od systemu operacyjnego różne jest miejsce

żytkownika znajduje się

a dla nowszych systemów (Vista, 7) jest to

ysunek 15 przedstawia

Ustawienia

związane z systemem operaycjnym, związane z

38

Dzięki RUP (ang. Roaming User Profile) wszystkie te dane przechowywane są w jednym

miejscu w sieci. Podczas pierwszego logowania do systemu zostaje stworzony profil

użytkownika. Po jego wylogowaniu zostaje on przesłany na serwer – dotyczy to danych

jak i ustawień. Kiedy użytkownik zaloguje się na innym komputerze niż ten na którym

nastąpiło pierwsze logowanie, wszelkie dane związane z jego profilem zostają przesłane

z serwera. Po wprowadzeniu zmian w profilu np. poprzez stworzenie przez użytkownika

nowych dokumentów, po wylogowaniu profil na serwerze zostaje uaktualniony.[37]

Rozwiązanie to nie sprawdza się w przypadku infrastruktury ze zróżnicowanymi

systemami operacyjnymi Windows XP/Windows Vista, bądź Windows XP/Windows 7.

Wynika to ze zmiany struktury profilu użytkownika wraz z rozwojem systemów

operacyjnych, jak i jego położenia w danym systemie co zostało wspomniane wcześniej.

Dzieje się tak również w przypadku mieszanej infrastruktury pod względem architektury

x86/x64. Jednak największą wadą tego rozwiązania jest to, że profile użytkowników mogą

przybrać bardzo duże rozmiary. W momencie kiedy musi on zostać przesłany do

użytkownika, bądź na serwer proces logowania/wylogowania na stacji roboczej może

trwać bardzo długo. W tym momencie również znacznie wzrasta ruch generowany

w sieci.[38]

W odpowiedzi na rozrastanie się profili użytkowników wraz z Windows 2000 została

wydana druga z technologii, a mianowicie FR (ang Folder Redirection).

Idea tego rozwiązania polega na przekierowaniu folderów należących do profilu

użytkownika np. folderu Moje Dokumenty poza obszar profilu. Foldery wydzielone

z profilu użytkownika wraz z zawartością przechowywane są na udostępnionym udziale

sieciowym. Przy takim rozwiązaniu użytkownik ma dostęp z różnych stacji roboczych do

swoich danych jednak nie do swoich ustawień. W tym przypadku dobrym rozwiązaniem

jest połączenie tych dwóch technologii RUP i FR. Przy takim rozwiązaniu w momencie

logowania się do systemu z serwera zostają przesłane tylko ustawienia związane z danym

profilem użytkownika. Do swoich danych użytkownik ma dostęp poprzez przekierowanie

folderów, co eliminuje konieczność przesyłania danych do klienta i tym samym znika

główny problem stosowania tylko rozwiązania Roaming User Proflie.[38]

39

3.4.2. Wirtualizacja sesji i VDI

Wirtualizacja sesji wywodzi się z modelu cienkiego klienta rozpowszechnionego

przez firmę Citrix w latach 90. Wirtualizacja sesji pozwala na łączenie się wielu

użytkowników z jednym systemem operacyjnym zainstalowanym na jednym serwerze –

każdy użytkownik otwiera nową sesje. Wszystkie aplikacje uruchamiane przez

użytkowników w takim wypadku wykonywane były na serwerze, a do użytkownika

przesyłane było tylko okno graficzne aplikacji. W obecnych czasach firma Microsoft

udostępnia wirtualizacje sesji dzięki usługom terminalowym dostępnym w serwerowej

wersji ich systemu. W systemie Windows Server 2008 R2 tą funkcjonalność przynosi ze

sobą usługa Remote Desktop Service. Technologia wirtualnych pulpitów zdalnych jest

rozwinięciem koncepcji cienkiego klienta i wirtualizacji sesji. VDI udostępnia osobny

odizolowany system operacyjny dla każdego użytkownika.[36] VDI może być

zaimplementowane w dwóch odmianach – jako rozwiązanie osobiste, bądź pula.

Rozwiązanie osobiste – Personal Virtual Desktops gdzie, każdy użytkownik posiada

własne środowisko pracy na którym może zapisywać dane. Pula maszyn wirtualnych,

czyli Pooled Virtual Desktops, gdzie użytkownicy łączą się do jednej z wielu maszyn

po wylogowaniu użytkownika maszyna powraca do stanu pierwotnego.

Technologia VDI to młode rozwiązanie jednak świadczą je już czołowi gracze

w dziedzinie wirtualizacji tj. Citrix, Microsoft, czy VMware. Infrastruktura wirtualnych

pulpitów sprawia, że użytkownik nie jest przywiązany do danego stanowiska, może on

zmieniać swoje miejsce pracy. A do łączenia z maszyną wirtualną może wykorzystać

komputer stacjonarny, laptopa czy cienkiego klienta. Zastosowanie VDI zwiększa

bezpieczeństwo dzięki temu, że każde wirtualne środowisko pracy jest od siebie

odizolowane. Ponadto dane przechowywane są w jednym miejscu, a nie tak jak wcześniej

na komputerach indywidualnych. Do wad tego rozwiązania można zaliczyć koszty

związane z serwerem na którym będą pracować maszyny wirtualne, wymaganie łącza

sieciowego o dostatecznej przepustowości. Jak i w przypadku implementacji rozwiązania

Pooled Virtual Desktops, konieczność stosowania dodatkowego serwera bądź komputerów

osobistych na zapis danych. Wynika to z istoty działania tego rodzaju implementacji,

gdzie dane na których pracuje użytkownik zostają utracone po wylogowaniu się.

Wirtualizacja sesji dzięki usługom terminalowym jest dużo starszą technologią od VDI,

jest ona również mniej kosztowna.

40

Porównując wykorzystanie zasobów serwera, będzie on w stanie udzielić dostępu

za pomocą usług terminalowych większej liczbie użytkowników niż dzięki VDI.

Oczywiście będzie to też zależne od tego jakie aplikacje będą w ten sposób uruchamiane.

Wirtualizacja sesji jednak nie zapewnia takiego bezpieczeństwa jak VDI, ponieważ w tym

przypadku sesje poszczególnych użytkowników nie są od siebie całkowicie odizolowane.

Użytkownicy współdzielą jeden system operacyjny wraz z aplikacjami na nim

zainstalowanymi. [38]

3.5. Korzyści wynikające z wirtualizacji

W zależności od tego jakim sprzętem i infrastrukturą sieciową dysponuje dana

organizacja przed wprowadzeniem wirtualizacji może okazać się, że wydatki do

przystosowania infrastruktury będą nie małe. Wydatki te będą również zależeć od tego

z której gałęzi wirtualizacji przedsiębiorstwo będzie chciało skorzystać, a to może być

uzależnione od profilu działania danej firmy jak i jej wielkości.

W literaturze dotyczącej IT jak i w Internecie wymieniane korzyści związane

z wirtualizacją w głównej mierze dotyczą wirtualizacji serwerów. Zapewne jest to

związane z tym, że to właśnie wirtualizacja serwerów jest najbardziej rozpowszechniona

i to ona przynosi najbardziej wymierne korzyści. Wirtualizacja serwerów dzięki ich

konsolidacji, czyli stworzeniu z 10 serwerów fizycznych np. tylko 2 w obrębie których

pracuje 10 zwirtualizowanych systemów. Zmieszenie ilości sprzętu komputerowego

w serwerowni. Zmniejszenie wydatków na energie elektryczną jak i klimatyzacje dużych

zapchanych serwerowni. To oczywiste zyski pieniężne Konsolidacja pozwala również na

lepsze wykorzystanie sprzętu komputerowego, który do tej pory był wykorzystywany

w niewielkim stopniu. Łatwiejsze w tym przypadku staje się również wykonywanie kopii

zapasowych, czy migracja wirtualnych systemów na inny serwer fizyczny np. podczas prac

konserwacyjnych. Środowisko takie z racji na scentralizowanie zasobów jest również

łatwiej zarządzane. Pozostałe gałęzie wirtualizacji może i nie przynoszą tak dużych

widocznych na pierwszy rzut oka korzyści materialnych jednak ich zastosowanie na pewno

również przyniesie korzyści. Ogólne pisząc zastosowanie wirtualizacji w przedsiębiorstwie

usprawni zarządzanie zasobami. Każdy z rodzajów wirtualizacji oddaj do dyspozycji mniej

lub bardziej scentralizowane środowisko pod względem zasobów i danych. Jak wiadomo

zarządzanie takim środowiskiem jest dużo łatwiejsze i efektywniejsze.

41

4. Wirtualizacja aplikacji

W momencie omawiania podziału wirtualizacji została opisana technologia VDI.

Wykorzystywana w celu dostarczenia do użytkownika końcowego całego wirtualnego

pulpitu, bądź określonej aplikacji. W przypadku infrastruktury wirtualnych pulpitów

korzystają one z mocy obliczeniowej serwera na którym się znajdują. VDI może okazać się

idealnym rozwiązaniem w przypadku przedsiębiorstw świadczących usługi centrum

pomocy telefonicznej. Gdzie pracownicy pracują w systemie zmianowym i korzystają

z małej ilości aplikacji, które nie są również wymagające pod względem sprzętowym.

Skorzystanie w takim przypadku z Pooled Virtual Desktops wydaje się być bardzo dobrym

rozwiązaniem. Rozwiązanie VDI jest kosztowne do wdrożenia – oczywiście zależy to

również od stanu istniejącej infrastruktury. Im więcej aplikacji do dostarczenia dla

użytkowników i im więcej samych użytkowników tym większa musi być moc

obliczeniowa serwerów, które udostępniają wirtualne maszyny. W przypadku instytucji,

gdzie korzysta się z dużej ilości różnych aplikacji rozwiązanie VDI będzie bardzo

kosztowne do wdrożenia, jak i może okazać się nie opłacalne. Do takich instytucji można

zaliczyć szkoły wyższe, gdzie wachlarz aplikacji z jakich się korzysta może być znacznie

większy niż w niejednym przedsiębiorstwie. W momencie kiedy dana

organizacja/przedsiębiorstwo wykorzystuje wiele aplikacji jak i charakteryzuje się ona

dużą liczbą użytkowników, dobrym do wdrożenia rozwiązaniem może okazać się

wirtualizacja aplikacji. Tak jak w każdym wcześniejszym rodzaju wirtualizacji,

który został omówiony tak i w tym tworzona jest warstwa abstrakcji pomiędzy zasobami.

W przypadku wirtualizacji aplikacji warstwa ta powstaje pomiędzy systemem

operacyjnym, a aplikacją. Pozwala to na odizolowanie aplikacji od systemu operacyjnego.

Dla lepszego zobrazowania zagadnienia wirtualizacji aplikacji warto przyjrzeć się relacjom

panującym pomiędzy systemem operacyjnym, a aplikacją zainstalowaną w tradycyjny

sposób i tą zwirtualizowaną. Każda z aplikacji niezależnie od tego, czy zwirtualizowana,

czy też nie do poprawnego działania potrzebuje dostępu do zasobów systemowych.

Każda tworzy swoje wpisy w obrębie rejestru systemowego, dodaje do systemu własne

biblioteki, czy korzysta z już istniejących. Rysunek 16 przedstawia ogólny schemat

współistnienia w systemie dwóch różnych aplikacji, które zostały zainstalowane w sposób

tradycyjny.

42

Rysunek 16. Korzystanie z zasobów przez normalne aplikacje[39]

Jak widać z Rysunku 16 i jak zostało napisane wcześniej, aplikacje korzystają z zasobów

systemowych takich jak, pliki konfiguracyjne – pliki .ini, biblioteki dll, wpisy rejestru.

Dane związane z profilem użytkownika i dokumentami. Usługi systemowe pozwalające

aplikacji na dostęp np. do drukarek. W przypadku tradycyjnej instalacji każda aplikacja do

wymienionych zasobów ma prawa w trybie odczytu i zapisu. Taki stan rzeczy może

powodować konflikty pomiędzy aplikacjami. Standardowe podejście do instalacji aplikacji

na pewno przyczynia się do mniej komfortowej, a może i mniej stabilnej pracy systemu

wynikającej z rozrastającego się rejestru jak i dużej ilości bibliotek, co może skutkować

zmniejszeniem wydajności systemu.

Rysunek 17. Wirtualna aplikacja w systemie operacyjnym[40]

Wcześniej zostało już wspomniane, że aplikacja zwirtualizowana jest odizolowana od

systemu, dzięki dodatkowej warstwie abstrakcji. Działanie takiej aplikacja zostało

przedstawione na Rysunku 17.

43

Aplikacja taka znajduje się w wirtualnym środowisku i to w nim jest ona uruchamiana.

W skład takiego wirtualnego środowiska wchodzą wszystkie pliki jakich dana aplikacja

wymaga do poprawnego działania. Włączając w to klucze rejestru jak i biblioteki.

Wirtualny rejestr ma strukturę identyczną do rejestru w rzeczywistym systemie

operacyjnym, jednak zawiera on tylko wpisy z których będzie korzystać dana aplikacja.

To samo tyczy się pozostałych plików takich jak biblioteki dll, czy pliki z ustawieniami.

Aplikacja zwirtualizowana ma dostęp do bibliotek i rejestru systemowego, ale tylko

w trybie do odczytu. Dzięki dokładnemu odwzorowaniu w wirtualnym środowisku

struktury niezbędnych do działania plików, oraz rejestru użytkownik pracujący z taką

aplikacją może swobodnie korzystać z całej funkcjonalności jaką przynosi ona ze sobą.

Istnienie odizolowanego środowiska eliminuje dodawanie plików i wpisów w rejestrze do

systemu rzeczywistego. Takie podejście nie powoduje powstawania konfliktów między

aplikacjami, czy nawet daje możliwość uruchomienia dwóch tych samych aplikacji

w różnych wersjach w tym samum czasie. Dodatkowo wirtualne środowisko sprawia,

że umieszczona w nim aplikacja pracuje dokładnie tak jak gdyby była zainstalowana.[40]

4.1. Środowisko standardowe, a zwirtualizowane

Wirtualna aplikacja jest odizolowana od systemu, a jak ma się to do zarządzania takimi

aplikacjami? Tutaj warto przyjrzeć się procesowi jakiemu podlegają środowiska stacji

roboczych pod kontem znajdującego się na nich oprogramowania. Proces wdrażania

aplikacji to zbiór wszystkich czynności dzięki którym aplikacje znajdujące się na stacji

roboczej są dostępne dla jej użytkowników. Z procesem wdrażania aplikacji związanych

jest kilka czynności. Czynności te to: instalacja, aktywacja oprogramowania, dezaktywacja

oprogramowania, konfiguracja, uaktualnienia i deinstalacja. Nie koniecznie muszą one

następować po sobie w ściśle określony sposób. Nie zawsze w każdym przypadku będą

wykonywane wszystkie, może się zdarzyć, że dla jednego rodzaju oprogramowania

wystarczy wykonać tylko ich część. Będzie to zależało od złożoności danego

oprogramowania, jego przeznaczenia jak i samego licencjonowania. Wszystkie te

wymienione wcześniej czynności zostały przedstawione na Rysunku 18.

44

Rysunek 18. Wdrażanie oprogramowania. Cykl życia

Instalacja jest pierwszy etapem wdrażania aplikacji na stacji roboczej. Po zainstalowaniu

w zależności od danej aplikacji może być wymagana jej aktywacja, bądź dodatkowa

konfiguracja przed pierwszym uruchomieniem. Na tym proces wdrażania aplikacji się nie

kończy. Z biegiem czasu zostają wydane nowe wersje aplikacji, z poprawioną

funkcjonalnością, czy z nowymi łatami zwiększającymi bezpieczeństwo.

Większość aplikacji w takim przypadku zaktualizuje się automatycznie pobierając nową

wersję z Internetu. Jednak w przypadku, kiedy jest to niemożliwe konieczna jest

interwencja administratora. Instalacja aktualizacji to kolejny czas poświęcony na

zarządzaniu oprogramowaniem. Biorąc pod uwagę, że w tradycyjnym środowisku proces

instalacji, konfiguracji i aktualizacji oprogramowania musi być wykonany nie na jednej,

a na wielu stacjach roboczych można uświadomić sobie jak bardzo czasochłonne jest to

zajęcie. Ponadto w takim rozwiązaniu użytkownik jest przypisany do danej stacji roboczej,

w razie awarii może on korzystać z innej jednak wiąże się to z przystosowaniem jej do

jego potrzeb tzn. zainstalowaniu na niej wszystkich aplikacji jakich potrzebuje do swojej

pracy. Wszystko to pokazuje, że proces wdrażania oprogramowania i jego późniejsze

zarządzanie jest procesem cyklicznym. W przedsiębiorstwach korzystających z dużego

wachlarza aplikacji, do których na pewno można zaliczyć szkoły wyższe jest to proces

ciągły w czasie i czasochłonny.

45

Podsumowując tradycyjny sposób dostarczania aplikacji tj. przez ich manualną instalacje

jest nieelastyczny i czasochłonny – trudno szybko odpowiedzieć na zmianę używanych

aplikacji, brak scentralizowanego zarządzania sprawia, że ciężko jest kontrolować

z biegiem czasu to co na jakich stacjach roboczych się znajduje.

W przypadku wykorzystania wirtualizacji aplikacji sytuacja zarządzania i wdrażania

oprogramowania diametralnie się zmienia. W zasadzie mówiąc o wirtualizacji aplikacji nie

należy mówić o wdrażaniu oprogramowania – czyli o wszystkich wymienionych

czynnościach. Lecz o dostarczaniu oprogramowania do użytkowników końcowych.

Oczywiście schemat przedstawiony na Rysunku 18 można odnieść do wirtualizacji

aplikacji, jednak w tym przypadku taki proces jak instalacja, czy konfiguracja odbywa się

dla danej aplikacji tylko raz, niezależnie od ilości stacji roboczych na których ma się ona

znaleźć. Wirtualna aplikacja nie jest instalowana na stacji roboczej jest ona na niej

publikowana. Dzięki odizolowaniu aplikacji od systemu operacyjnego niesie to za sobą

następujące korzyści:

• użytkownik nie jest przywiązany do swojego stanowiska pracy - logując się na

innym komputerze również będzie miał dostęp do aplikacji przez niego

używanych,

• proste zarządzanie – instalacja, konfiguracja, uaktualnienie aplikacji odbywa się

tylko raz, aplikacja taka może być dostarczona wszędzie,

• prostsza migracja między systemami – raz zwirtualizowana aplikacja może być

uruchamiana na różnych systemach operacyjnych. Może ona być dostarczana

również do różnych rozwiązań VDI,

• zwiększone bezpieczeństwo – z racji na izolacje aplikacji użytkownik ma

zmieszone pole manewru jeżeli chodzi o jej modyfikacje,

• dostarczanie aplikacji do oddziałów zamiejscowych – publikacja aplikacji może

odbywać się przez serwer WWW,

• możliwość szybkiej odpowiedzi na zmieniające się potrzeby w zakresie

wykorzystywanych aplikacji,

• brak konfliktów – odizolowanie aplikacje nie powodują konfliktów w systemie,

• scentralizowane zarządzanie – wszystkie aplikacje znajdują się w jednym miejscu,

na serwerze z którego publikowane są na stacjach roboczych.[41]

46

Niezależnie od badanego rozwiązania służącego wirtualizacji aplikacji do stworzenia

pełnej funkcjonującej infrastruktury wymagane jest istnienie w sieci co najmniej trzech

hostów z zainstalowanym i skonfigurowanym odpowiednim oprogramowaniem. Zostały

one przedstawione na Rysunku 19.

Rysunek 19. Droga zwirtualizowanje apliakcji – do stworzenia do opublikowania

Komputer 1 – na nim znajdzie się oprogramowanie pozwalające na tworzenie paczek

z aplikacjami. W sieci można znaleźć gotowe paczki dla różnych rozwiązań i tak np. na

stronie www.sftdownloads.com udostępniane są aplikacje pracujące z Microsoft App-V.

Jednak jest ich ograniczona ilość, ponadto chcąc tworzyć własne aplikacje

wykorzystywane w danym środowisku niezbędne jest istnienie komputera z odpowiednim

do tego oprogramowaniem. Rolę tego komputera z powodzeniem może pełnić maszyny

wirtualna uruchamiana dzięki, któremuś z dostępnych do tego celu na rynku rozwiązań.

Zalecane jest, aby zwirtualizowane aplikacje każdorazowo tworzone były na czystej

instalacji systemu operacyjnego. Zminimalizuje to ryzyko niepoprawnego nadzoru

instalacji programu.

Sercem każdego z badanych rozwiązań jest host pełniący rolę serwera(komputer 2),

z zainstalowanym odpowiednim oprogramowaniem. Serwer ten odpowiada za

przechowywanie i udostępnianie wcześniej zwirtualizowanych aplikacji.

Ponadto administrator ma możliwość zarządzania aplikacjami ich dodawania, usuwania,

czy określania docelowej grupy użytkowników, która będzie z danej aplikacji mogła

korzystać. Oprogramowanie zainstalowane na serwerze pozwala również na dokonywanie

czynności administracyjnych dla danego rozwiązania. Ostatni z komputerów

przedstawiony na Rysunku 19 jako komputer 3 jest to stacja robocza na której instalowane

jest oprogramowanie umożliwiające użytkownikowi końcowemu korzystanie ze

zwirtualizowanych aplikacji.

47

W taki sposób przedstawiają się ogólne założenia dotyczące komputerów wymaganych do

stworzenia działającego środowiska w którym wykorzystana będzie wirtualizacja aplikacji.

Oczywiście liczba hostów klienckich nie jest ograniczony tylko i wyłącznie do jednego

komputera, będzie to zależne od ilości użytkowników końcowych korzystających z danego

rozwiązania.

4.2. Narzędzia służące wirtualizacji aplikacji

Narzędzia dzięki którym można wprowadzić do środowiska IT aplikacje w formie

zwirtualizowanej zostały już w pewnym stopniu przedstawione w drugim rozdziale

niniejszej pracy. W tym podrozdziale zostaną one przedstawione od strony technicznej.

Można jeszcze raz wymienić dostępne na rynku rozwiązania:

• Microsoft App-V (dawniej Softgrid),

• Symantec Endpoint virtualziation Suite (dawniej SVS),

• Endevadors Jukebox Application,

• VMware Thinstall,

• Novell,

Z racji, że część badawcza pracy została oparta o pierwsze z 3 wymienionych rozwiązań

w dalszej części to właśnie te narzędzia zostaną opisane i przedstawione.

4.2.1. Microsoft Application Virtualization

Całość tego rozwiązania stanowią cztery komponenty, dwa z nich to

oprogramowanie instalowane na serwerze tj. App-V Streaming Server oraz App-V

Management Server. Kolejne dwa to App-V Sequencer, od niego wszystko się zaczyna

służy on do przygotowywania zwirtualizowanych aplikacji, ostatni zaś to oprogramowanie

instalowane po stronie klienta App-V Client.

48

Działanie App-V Sequencer polega na monitorowaniu procesu instalacji aplikacji,

która ma zostać zwirtualizowana, dzięki temu program może określić dokładnie jakie pliki

należą do tej aplikacji, z jakich bibliotek korzysta i jakie tworzy klucze rejestru.

Zwirtualizowana za pomocą App-V Sequencer aplikacja nie zawiera plików jakie można

przypisać do normalnej aplikacji, podczas procesu wirtualizacji zostają utworzone pliki

właściwe dla tego rozwiązania. Aplikacja taka zwiera następujące pliki o rozszerzeniach:

SFT, DSFT, OSD, SPRJ, ICO, MSI. Plik z rozszerzeniem SFT został już wymieniony przy

okazji opisywania historii rozwiązana App-V (dawniej Softgrid), zawiera on wszystkie

pliki, z których aplikacja korzysta jak i pliki jej samej. Jest on podzielony na dwa bloki

oznaczone FB1 i FB2. Blok FB1 zawiera pliki, które muszą zostać przesłane do klienta,

aby uruchomić aplikacje zaś dane z bloku FB2 wysyłane są na żądanie. Kolejny plik

z rozszerzeniem DSFT to plik różnicowy w stosunku do SFT, tworzony podczas

uaktualnienia aplikacji. Plik OSD (ang. Open Software Description) zawiera wszystkie

niezbędne informacje dla klienta które pozwalają mu na zlokalizowanie i uruchomienie

danej aplikacji. SPRJ to główny plik projektu może zostać zapisany w celu późniejszych

zmian, zawiera listę wszystkich plików, kluczy rejestru dołączonych podczas procesu

tworzenia wirtualnej aplikacji. Skrót ICO odpowiada ikonom programu wirtualizowanego.

MSI to pakiet Windows Installer, który może zostać opcjonalnie stworzony podczas

procesu wirtualizacji.[42]

Mimo wymienionych, aż 4 komponentów nie wszystkie muszą zostać wykorzystane do

stworzenia infrastruktury w której zastosowana zostanie wirtualizacja aplikacji.

Rozwiązanie to może zostać wdrożone na trzy różne sposoby. Można tutaj mówić o:

• standalone model,

• streaming model,

• full infrastructur model.

Niezależnie od wybranej architektury istnieją dwa komponenty, które będą zawsze

wykorzystywane. Pierwszy z nich to App-V Sequencer, drugi to App-V Client

oprogramowanie instalowane na stacjach roboczych.

Standalone mode czyli architektura samodzielna wykorzystuje tylko dwa komponenty

podane wcześniej, czyli Sequencer i oprogramowanie klienckie, jak zostało napisane

wcześniej jest to niezbędne minimum i to na nim ten model opiera swoje działanie.

49

Aplikacje poddawane są wirtualizacji poprzez ich sekwencjonowanie, a całość zapisana

zostaje do pakietu MSI. Zawiera on wszelkie dane wraz z plikiem SFT niezbędne do

zainstalowania takiej aplikacji.

Dystrybucja pakietu MSI może odbywać się poprzez Group Policy Object, poprzez

rozprowadzanie na nośnikach typu pendrive, wykorzystując udostępniony zasób sieciowy

bądź jeżeli w sieci istnieje rozwiązanie SMS/SCCM to dzięki nim również można dokonać

dystrybucji. Rozwiązanie takie pozwala skorzystać z dobrodziejstw jakie niesie za sobą

wirtualizacja aplikacji jednak nie wszystkich. Jest to dobre rozwiązanie w przypadku

użytkowników nie mających dostępu do serwera App-V, pracujących bez podłączenia do

sieci, bądź gdy jest wdrożone już rozwiązanie typu SMS/SCCM, bądź gdy przepustowość

sieci jest za mała do dystrybucji oprogramowania z jej wykorzystaniem.

Drugi z modeli oprócz oprogramowania do tworzenia zwirtualizowanych aplikacji oraz

oprogramowania klienckiego wykorzystuje komponent App-V Streaming Server.

Ponadto wymagane jest tutaj rozwiązanie, które będzie publikować ikony aplikacji na

stacjach roboczych, w tym celu mogą zostać wykorzystane możliwości niejednokrotnie

wspominanego GPO. W tym przypadku zwirtualizowane aplikacje w formie pierwotnej

umieszczane są na serwerze na którym zainstalowany jest komponent App-V Streaming

Server. Odpowiada on za przesłanie aplikacji do klienta. Wykorzystywane są tutaj bloki

opisane wcześniej (FB1 i FB2) znajdujące się w pliku SFT. W tym rozwiązaniu nie jest

wykorzystywany serwer SQL nie wymagane jest również Active Directory.

App-V Streaming Server w celu określenia praw dostępu do określonych aplikacji

wykorzystuje listy ACL (ang. Access Control List).

W przypadku pełnej infrastruktury głównym komponentem całości staje się App-V

Management Server. Ponadto dla tego modelu wymagane jest zainstalowanie na serwerze

bazy danych oraz skonfigurowanie usługi Active Directory. Management Server ma

w sobie pełną funkcjonalność serwera pozwalającego na przesyłanie aplikacji do

użytkowników (App-V Streaming Server). Ponadto publikuje on ikony aplikacji na

stacjach roboczych. Nie jest konieczne w tym momencie wykorzystanie dodatkowego

rozwiązania do publikowania aplikacji na stacjach roboczych. Pełny model może zostać

zastosowany wszędzie tam gdzie w sieci nie ma istniejącego rozwiązania do publikowania

aplikacji, ponadto tam gdzie wskazane jest wykorzystanie pełnej funkcjonalności

rozwiązania App-V.[43]

50

4.2.2. Symantec Workspace Streaming

W przypadku rozwiązania firmy Symantec administrator dostaje do dyspozycji

kilka komponentów głównych tj. Streaming Server, Launch Server i Streamlet Engine,

dodatkowo Streaming Console. Kolejne komponenty to oprogramowanie instalowane na

stacjach roboczych Symantec Workspace Agents i Wise Visual Composer. Wise Visual

Composer służy do tworzenia zwirtualizowanych aplikacji, zwirtualizowana aplikacja

przyjmuje postać jednego pliku o rozszerzeniu XPF (ang. Extensible Package Format)

to w nim znajdują się wszystkie dane umożliwiające uruchomienie zwirtualizowanej

aplikacji. Pierwszy z wymienionych komponentów Streaming Server jak sama nazwa

wskazuje odpowiada za przesyłanie aplikacji do użytkownika końcowego. Komunikuje się

on z kolejnym komponentem Streamlet Engine od którego otrzymuje aplikacje podczas jej

wgrania na serwer wraz z informacjami do jakiego użytkownika dana aplikacja ma trafić.

Streamlet Engine zapewnia scentralizowane przechowywanie danych. Administrator jak

i użytkownicy nie wchodzą podczas pracy w bezpośrednią interakcje z tymi

komponentami. Launch Server oraz Streaming Console dostarczają graficznego interfejsu

z poziomu przeglądarki WWW. Pierwszy z nich – Launch Server – odsługuje interfejs dla

użytkowników końcowych, z poziomu którego można wybrać aplikacje do uruchomienia.

Launch Serwer generuje stronę WWW z zawartością zależną od danego użytkownika.

Drugi zaś z tych komponentów służy administratorowi do zarządzania całym

rozwiązaniem.[44] Począwszy od konfiguracji każdego z komponentów, poprzez

zarządzanie użytkownikami i grupami, skończywszy na generowaniu raportów.

Rozwiązanie to może zostać wdrożone na dwa różnie sposoby, wybór odpowiedniego

będzie w głównej mierze uwarunkowany ilością obsługiwanych aplikacji jak i wielkością

organizacji. Pierwszy z nich zakłada, że wszystkie wymienione do tej pory komponenty

związane z serwerem instalowane są na jednym komputerze. Rozwiązanie takie nazywane

jest architekturą single-node, w tym przypadku nie jest tak bardzo istotna rola każdego

z komponentów ponieważ pracują one na jednym serwerze. Ten typ architektury może być

z powodzeniem stosowany w przypadku ograniczonej ilości aplikacji jak i ograniczonego

zasięgu przedsiębiorstwa.

Druga z architektur zakłada rozproszenie poszczególnych komponentów całego systemu,

architektura nazywana jest multi-node. W tym przypadku wymienione komponenty można

podzielić na dwie grupy.

51

W pierwszej z tych grup znajduje się Streaming Server oraz Launch Server, grupa ta

nazywana jest Multi-node Front End. Druga grupa nazywana jest Multi-node Back End,

a w jej skład wchodzi Streaming Console i Streamlet Engine. Podział ten został

zobrazowany na Rysunku 20.

Rysunek 20. Architektura rozproszona rozwiązania firmy Symantec

Zgodnie z opisanymi zadaniami każdego z komponentów w tej architekturze istnieje jeden

serwer zapewniający zarządzanie całością (multi-node back end) oraz większa ilość

serwerów odpowiedzialnych za przesyłanie aplikacji do użytkownika końcowego

(multi-node front end). Instalując w dużych sieciach kilak serwerów Front End rozłożony

zostanie ruch sieciowy między nie, poza tym zapewnia to lepsze zarządzanie aplikacjami

dla danej grupy użytkowników – jeden dział korzysta z jednego serwera. [44]

4.2.3. Endeavors Jukebox Application

Endeavors udostępnia swoje rozwiązanie w trzech wersjach: Lite, Enterpirse

i SaaS. Niezależnie od wersji całość składa się z trzech komponentów, Jukebox: Server,

Studio i Player. W przypadku tego rozwiązania tworzenie zwirtualizowanej aplikacji

odbywa się dzięki Jukebox Player. Tak jak w przypadku wcześniej opisanych rozwiązań

odbywa się to na zasadzie monitorowania instalacji aplikacji. W pierwszej fazie tworzony

jest plik projektu, ma on rozszerzenie STW.

52

Gotowa zwirtualizowana aplikacja ma postać jednego pliku o rozszerzeniu STP

(ang. Streaming Package), plik ten zawiera wszystkie niezbędne dane do przesłania

aplikacji do klienta i jej uruchomienia. Większą część pliku STP stanowią dane

zwirtualizowanej aplikacji przechowywane w osobnym pliku STC (ang. Streaming

Content). Kolejny plik w obrębie STP to plik w którym przechowywane są wszelkie

metadane dla plików aplikacji i kluczy rejestru, jest to plik AIB (ang. (Application

Installation Blueprint). Ponadto w obrębie pliku STP znajdują się ikony dla danej aplikacji.

Zwirtualizowana aplikacja w momencie wgrania na serwer przez twórców

oprogramowania określana jest mianem Appset.[45]

Oprogramowanie które jest trzonem całej infrastruktury w tym przypadku to Jukebox

Server, w skład którego niezależnie od wersji wchodzą trzy główne usługi tj. Licence,

Admin i Stream Service. Rysunek 21 przedstawia schemat systemu Jukebox po stornie

serwera, gdzie również zostały wyszczególnione wspomniane już usługi. Chodzi tutaj

o usługi: Licence, Admin i Stream.

Rysunek 21. Schemat systemu Jukebox Server

Pierwsza z usług jak sama nazwa wskazuje odpowiada za licencje (Licence Service)

zarządza ona licencjami użytkowników, zlicza wykorzystanie danych aplikacji przez

użytkowników. Usługa licencjonowania sprawdza licencje dla aplikacji aktualnie

uruchomionych, przez poszczególnych użytkowników. Admin Service jest składnikiem

który dostarcza graficzny interfejs z poziomu przeglądarki WWW.

53

Administratorowi pozwala on na kompleksowe zarządzanie rozwiązaniem od dodawania

i konfiguracji zwirtualizowanych aplikacji, poprzez konfiguracje komponentów serwera,

po zarządzanie i sprawowanie kontroli nad użytkownikami mającymi dostęp do systemu.

Użytkownicy zaś mają dostęp do strony dzięki której mogą uruchomić zwirtualizowane

aplikacje. Konieczność korzystania ze strony wiąże się tylko z pierwszym uruchomieniem

aplikacji, w celu jej dodania do oprogramowania Jukebox Player.

Ostatnia z usług, czyli Stream Service odpowiedzialna jest za przechowywanie,

zarządzanie i przesyłanie aplikacji do użytkownika końcowego. Usługa ta przy przesyłaniu

aplikacji przestrzega ograniczeń ustawionych przez usługę odpowiedzialną za licencje.[45]

Tak wygląda Jukebox w wersji Lite. Kolejne dwie wersje tak jak to zostało przedstawione

na Rysunku 21 wyposażone są w dodatkowe komponenty Enterprise Portal bądź SaaS

Portla w zależności od wersji.

Wersja Enterprise daje możliwość integracji całego rozwiązania z usługą Active Directory.

Rozwiązanie takie pozwala na przypisanie danej grupy użytkowników do konkretnych

aplikacji. W przypadku wersji Lite użytkownik miał dostęp do wszystkich

opublikowanych na serwerze aplikacji. Ponadto wersja Enterprise może zostać

zintegrowana z Group Policy Object (GPO), w celu automatycznego przesyłania aplikacji

do klienta końcowego. W tym momencie aplikacje przesyłane są do użytkownika po

zalogowaniu do systemu.[48] Integracja z Active Directory pozwala na lepsze zarządzanie

całym systemem. Kolejna wersja daje możliwość zbudowania własnego portalu WWW

udostępniającego odpłatnie aplikacje dla klientów, bo tak właśnie działa SaaS

(ang. Software as a Service), czyli aplikacja jako usługa. SaaS daje możliwość korzystania

z pełnej funkcjonalności aplikacji bez konieczności zakupywania licencji i instalowania jej

na komputerze.

54

5. Badania eksperymentalne

Jednym z głównych założeń pracy było porównanie wybranych narzędzi służących

do wirtualizacji aplikacji pod kątem wykorzystania podstawowych zasobów serwera,

takich jak pamięć operacyjna, czy procesor. Porównanie stanu zasobów klienta podczas

uruchamiania zwirtualizowanej aplikacji. Dodatkowo został sprawdzony czas tworzenia

zwirtualizowanej aplikacji. Środowisko testowe składało się z 3 komputerów pełniących

rolę klientów oraz serwera. Na serwerze zainstalowany został system Windows Server

2008 R2, zaś na stacjach roboczych znalazł się system Windows XP SP3 oraz Windows 7.

Konfiguracja sprzętowa serwera oraz klienta wyglądała następująco:

• Serwer to jednostka wyposażona w procesor Intel Xeon 5110 o zegarze

taktowanym częstotliwością 1.6 GHz. Wyposażony w 2 GB pamięci operacyjnej

FB-DDR2, dysk twardy WDC WD2500YD – 7,200 obr/min, rozmiarze bufora

16 MB oraz karcie sieciowej Intel PRO/1000 EB.

• Stacja robocza to jednostka Dell Optiplex GX280, wyposażona w procesor Intel

Pentium 4 o taktowaniu 2,8 GHz, 2 GB pamięci DDR2 800, dysku twardym WDC

WD400BD o prędkości 7,2000 obr/min i rozmiarze bufora 8 MB.

5.1. Wykorzystane programy podczas testowania

Podczas testowania zostały wykorzystane 4 następujące narzędzia:

• Monitor wydajności systemu Windows,

• Program PsExec,

• Microsoft Network Monitor,

• AutoIt.

W dalszej części znajduje się krótki opis każdego z nich i tego jaką rolę pełniło podczas wykonywania testów.

55

5.1.1. Monitor wydajno ści

Podstawowym narzędziem wykorzystanym do diagnostyki obciążenia serwera jak

i klienta był Monitor wydajności dostarczany wraz z systemem Windows Server 2008 R2.

Monitor wydajności pozwala na kontrolowanie w czasie rzeczywistym aplikacji bądź

sprzętu. Daje również możliwość zapisywania monitorowanych wielkości do dziennika,

tworzenia raportów bądź ustawienia alertów[46]. W pracy została wykorzystana

możliwość tworzenia modułów zbierających dane (ang. Data Set Collector). W skład

modułu zbierającego dane mogą wchodzić następujące komponenty:

• liczniki wydajności,

• dane śledzenia zdarzeń,

• informacje o konfiguracji systemu (wartości kluczy rejestru).

Zestawy takie można uruchamiać jak i zatrzymywać o określonym czasie. Pozwalają one

na zebranie określonych liczników w jednym module. Wyniki ich działania mogą być

zapisane w formacie Monitora wydajności (.blg) – pozwala to na bezpośrednie

wyświetlenie wyników w postaci wykresów w Monitorze Wydajności, bądź zapisanie ich

do pliku CSV.[47] W pracy została wykorzystana możliwość tworzenia modułów

zawierających określone przez użytkownika liczniki wydajności.

5.1.2. Pozostałe wykorzystane programy

Kolejne trzy wykorzystane programy to narzędzie PsExec, Microsoft Network Monitor oraz AutoIt.

Pierwsze z nich to narzędzie wchodzące w skład grupy programów PsTools – jest to zbiór programów ułatwiających zarządzanie stacjami roboczymi, bądź serwerem w sposób lokalny lub zdalny. Zestaw zawiera narzędzia pozwalające między innymi na:

• wyświetlenie informacji o systemie,

• zarządzać procesami w systemie,

• zmianę haseł kont użytkowników,

• zdalne wykonywanie programów.[48]

56

To właśnie ostatnia z wymienionych możliwości została wykorzystana podczas

przeprowadzania testów. PsExec do swojego działania nie wymaga instalacji na klientach

żadnego dodatkowego oprogramowania. Pozwala on na zdalne uruchomienie dowolnego

polecenia/programu, a jego największą zaletą jest uruchamianie interaktywnych

poleceń.[49] Właśnie ta możliwość została wykorzystana w celu zautomatyzowania

uruchamiania zwirtualizowanej aplikacji na poszczególnych klientach.

Składnia polecenia programu PsExec wykorzystywana podczas testowania:

Psexec\\ip_hosta –u nazwa_użytkownik –p hasło polecenie

Kolejny wykorzystany program Microsoft Network Monitor pozwala na przechwytywanie

ruchu sieciowego oraz jego analizę. Program rejestruje adresy IP hostów wysyłających jak

i odbierających pakiety, odpowiednio adres źródłowy i docelowy. Protokół wykorzystany

podczas transmisji wraz z całą zawartością ramki, oraz dokładny czas przechwycenia

pakietów[50]. Program daje możliwość stworzenia filtrów przez co można ograniczyć

wyświetlane dane tylko do tych, które w danej chwili nas interesują.

Filtry mogą być tworzone na podstawie zmiennych bądź właściwości, które wynikają

z przechwyconego ruchu.[51] Poniżej został zamieszczony przykład filtrów dla lepszego

zobrazowania ich konstrukcji.

Tcp.Flags.Syn == 1

Po zastosowaniu takiego filtrowania zostaną wyświetlone tylko i wyłącznie pakiety

z ustawioną flagą synchronizacji.

Conversation.ProcessName == "svchost.exe"

Z kolei po użyciu takiego filtru otrzymamy tylko ten ruch, który dotyczył procesu

systemowego svchost. Rejestrowanie ruchu pakietów pozwoliło na określenie dokładnego

czasu rozpoczęcia komunikacji pomiędzy klientem, a serwerem podczas uruchamiania

aplikacji.

57

Ostatni z programów został wykorzystany w celu określenia czasu mijającego od momentu

rozpoczęcia przesyłania aplikacji do wyświetlenia jej głównego okna. Autoit jest

darmowym programem służącym do skryptowego automatyzowania aplikacji z GUI

pracujących pod kontrolą systemu Windows. Program przypomina swoją składnią języki

Basic, wykorzystując manipulację "oknami" aplikacji pozwala na zautomatyzowaną

instalację oprogramowania.[52] Skrypt przedstawiony w Tabeli 3 dla każdego z rozwiązań

wyglądał niemalże identycznie. Jedyne różnice występowały przy komendzie Run, która

odpowiadała za uruchomienie zwirtualizowanej aplikacji. Samo działanie skryptu kolejno

sprowadzało się do:

1. Zapisania aktualnego czasu do pliku tekstowego.

2. Uruchomienie żądanej aplikacji – polecenie run. Składnia polecenia to

run("uruchamiany program", "lokalizacja programu").

3. Odczekanie skryptu, aż do momentu pojawienia się okna aplikacji Matlab. Polecenie

WinWaitActive('Matlab 7.6.0 (R2008a)').

4. Odnotowanie aktualnego czasu.

#include <Date.au3>

$file = FileOpen("czas.txt",1)

$time = @HOUR & ":" & @MIN & ":" & @SEC

$time2 = @HOUR & ":" & @MIN & ":" & @SEC

FileWriteLine($file,"Czas uruchomienia apliakcji" & _Now())

Run('"C:\Program Files\Symantec\Workspace Streaming\Bin\exeForService.exe" -

AppStream "All Users\Pulpit\MATLAB R2008a.lnk"',"C:\Program

Files\Symantec\Workspace Streaming\Bin")

WinWaitActive('MATLAB 7.6.0 (R2008a)')

FileWriteLine($file,"Czas zamkniecia apliakcji " & _Now())

WinClose('MATLAB 7.6.0 (R2008a)')

Tabela 3. Skrypt pozwalający na określenie czasu po jakim wyświetliło się okno aplikacji

Czasy te były mierzone dla każdej konfiguracji zwirtualizowanej aplikacji podczas

pierwszego i drugiego uruchomienia. Uzyskane wyniki były średnim czasem z dziesięciu

prób.

58

5.2. Metodologia wykonania badań

Proces całego badania niezależnie, czy dotyczył serwera bądź klienta opierał się na

wykorzystaniu czterech wcześniej przedstawionych narzędzi. Dla każdego z badanych

rozwiązań zwirtualizowaną aplikacją był pakiet Matlab 2008A. Wykorzystanie zasobów

serwera oraz klienta było sprawdzane podczas pierwszego jak i drugiego uruchomienia

aplikacji. Jak i w różnych konfiguracjach zwirtualizowanej aplikacji zależnej od

możliwości jakie dawało konkretne narzędzie.

Podczas testów został wykorzystany prosty skrypt pozwalający na wywołanie Monitora

wydajności na serwerze, oraz aplikacji Matlab na stacjach roboczych z uwzględnieniem

odstępu czasowego pomiędzy poszczególnymi poleceniami. Zwłoka czasowa między

kolejnymi uruchomieniami aplikacji miała na celu uniknięcie sytuacji kiedy, serwer

w jednym czasie otrzymuje wszystkie żądania od klientów. Skutkowało by to

jednorazowym odczytaniem danych z dysku i przesłaniu do każdego z klientów. Skrypt

uruchamiany był z hosta nie będącego w grupie komputerów klienckich.

W Tabeli 4 i 5 zostały przedstawione skrypty wykorzystane podczas badania serwera

oraz klienta. Pierwszy ze skryptów był wykorzystywany przy testowaniu serwera.

Odpowiadał za uruchomienie zestawu liczników na serwerze, oraz aplikacji Matlab na

poszczególnych stacjach roboczych. Drugi ze skryptów identyczny z pierwszym z tym,

że ograniczał się do uruchomienia zwirtualizowanej aplikacji na jednym hoście.

@echo OFF

echo Uruchomienie Monitora wydajności

psexec \\192.168.1.129 -u klient -p P@ssw0rd. cmd /C "logman start test-

serwera"

TIMEOUT /T 60

echo Uruchamianie Matlaba na kliencie 1

psexec \\192.168.1.121 -u klient -p P@ssw0rd. -i "C:\Matlab\bin\Matlab.exe"

TIMEOUT /T 20

echo Uruchamianie Matlaba na kliencie 2

psexec \\192.168.1.125 -u klient -p P@ssw0rd. -i "C:\Matlab\bin\Matlab.exe"

TIMEOUT /T 20

echo Uruchamianie Matlaba na kliencie 3

psexec \\192.168.1.142 -u klient -p P@ssw0rd. -i "C:\Matlab\bin\Matlab.exe"

Tabela 4. Skrypt wykorzystany przy badaniu serwera

59

Tabela 5 zawiera niemalże identyczny skrypt, który posłużył do testowania stacji roboczej.

Tak ogólnie wyglądały oba skrypty przy testowaniu rozwiązań. Jedyna różnica była

w poleceniu psexec, które odpowiadało za uruchomienie zwirtualizowanej aplikacji.

Wynikało to z faktu iż każde z rozwiązań używało własnego oprogramowania na stacji

roboczej do uruchomienia aplikacji.

@echo OFF

echo Uruchomienie Monitora wydajności

psexec \\192.168.1.129 -u klient -p P@ssw0rd. Cmd /C „logman start test-

klienta"

TIMEOUT /T 60

echo Uruchamianie Matlaba na kliencie

psexec \\192.168.1.121 -u klient -p P@ssw0rd. -i "C:\Matlab\bin\Matlab.exe" Tabela 5. Skrypt do testowania stacji roboczej

Według wcześniej przedstawionej składni polecenia psexec zostały utworzone kolejno

polecenie uruchamiające monitor wydajności oraz aplikację Matlab na stacjach roboczych.

Do uzyskania przerw czasowych pomiędzy uruchomieniem monitora wydajności,

a kolejnymi wywołaniami zwirtualizowanej aplikacji na klientach wykorzystane zostało

polecenie TIMEOUT wraz z parametrem /T skutkuje to oczekiwaniem przez podany po

parametrze czas wyrażany w sekundach.

Sam proces badania przedstawiony poniżej w sposób schematyczny sprowadzała się do

następujących czynności:

• Uruchomienie programu Network Monitor:

• Podczas badania serwera uruchamiany był na każdym kliencie

• Podczas badania klienta uruchamiany był na serwerze.

• Wywołanie skryptu – dla serwera (Tabela 4), bądź dla klienta (Tabela 5).

• Zatrzymanie Monitora wydajności oraz Network Monitora.

Istotną rzeczą przed przystąpieniem do testów była synchronizacja czasu na każdym

z komputerów. Było to konieczne ze względu na to, iż czas rozpoczęcia transmisji

aplikacji określany był z wykorzystaniem Network Monitora. Z kolei ten właśnie czas

nanoszony był na wyniki Monitora wydajności zanotowanego na serwerze.

60

Ta właśnie zależność pomiędzy tymi dwoma programami wymagała synchronizacji czasu.

Z racji, że przy każdym rozwiązaniu komputery znajdowały się w domenie czas na

stacjach roboczych synchronizowany był z kontrolerem domeny. Do synchronizacji

zostało wykorzystane polecenie NET TIME.

5.3. Wyniki

W przypadku stacji roboczej porównany został czas po jakim następuje otwarcie

głównego okna aplikacji. Wykorzystanie pamięci operacyjnej oraz procesora w czasie

uruchomienia aplikacji. Generowany ruch sieciowy pomiędzy klientem, a serwerem

podczas uruchamiania aplikacji. Te same wartości dotyczą również badań związanych

z serwerem. W przypadku badań stacji roboczej wszystkie te wielkości zostały zmierzone

dla każdego z wybranych rozwiązań jak i dla aplikacji zainstalowanej w sposób

tradycyjny.

Każde z rozwiązań było testowane w sposób przedstawiony we wcześniejszej części pracy.

Wybrana aplikacja do testowania jaką był Matlab 2008A, została stworzona w kilku

konfiguracjach w zależności od możliwości danego rozwiązania.

Dla konkretnego rozwiązania konfiguracje wyglądały następująco:

• Jukebox Lite:

o paczka stworzona bez kompresji danych, rozmiar 787 MB.

o paczka stworzona z wykorzystaniem algorytmu kompresji LZMA, rozmiar

400 MB

• Microsoft App-V

o paczka stworzona bez kompresji danych, rozmiar 782 MB

o paczka stworzona z wykorzystaniem kompresji ZLIB, rozmiar 427 MB

• Symantec Workspace Streaming

o paczka stworzona bez kompresji danych, rozmiar 780 MB

61

Monitorowanie zasobów stacji roboczej zostało rozpoczęte na minutę przed

uruchomieniem zwirtualizowanej aplikacji, zaś koniec monitorowania następował na

minutę po otwarciu głównego okna aplikacji.

Przedłużenie czasu monitorowania miało na celu zbadanie w jakim stopniu

wykorzystywane są monitorowane zasoby komputera po otwarciu głównego okna

aplikacji, które nie było równoznaczne z gotowością do pracy tej aplikacji.

5.3.1. Czas otworzenia głównego okna aplikacji

Pierwszy z wykresów przedstawia czas po jakim pojawiło się okno główne

aplikacji dla paczki stworzonej bez kompresji danych. Do wykresu dla porównania został

również dodany czas dla aplikacji zainstalowanej lokalnie. Najdłuższym w tym przypadku

czasem charakteryzuje się rozwiązanie firmy Symantec – ponad 3 minuty. Jak widać czas

który Symantec Workspace Streaming potrzebuje na stworzenie wirtualnego środowiska

na stacji roboczej jest bardzo długi i znacznie odbiega on od rozwiązań konkurencji.

Najmniejszym czasem może się poszczycić w tym przypadku rozwiązanie firmy Microsoft

tj. 28 sekund. Mimo wszystko czas dla pierwszego uruchomienia znacznie odbiega od

czasu zanotowanego dla instalacji lokalnej równej 8 sekund. Jest to związane

z koniecznością przesłania aplikacji z serwera. Drugie uruchomienie kiedy aplikacja

znajduje się na stacji roboczej charakteryzuje się skróconym czasem. Rozwiązanie firmy

Symantec w tym przypadku potrzebuje 17 sekund, aby wyświetlić okno główne aplikacji.

Najmniejszy czas w tym przypadku należy ponownie dla rozwiązania firmy Microsoft

i wynosi 10 sekund. Jest to czas porównywalny do czasu zarejestrowanego w przypadku

aplikacji zainstalowanej lokalnie.

62

Wykres 1. Uruchomienie aplikacji Matlab, bez kompresji danych

Dla paczki stworzonej z kompresją danych to nadal rozwiązanie firmy Microsoft może

pochwalić się czasem najbardziej zbliżonym do aplikacji zainstalowanej lokalnie. Jednak

czasy te są większe niż w przypadku aplikacji bez kompresji to najbardziej widać na

przykładzie rozwiązania Endeavors Jukebox.

Wykres 2. Uruchomienie aplikacji Matlab, z kompresją danych

00:28

04:05

00:32

00:08

00:10

00:17

00:22

00:00 00:28 00:57 01:26 01:55 02:24 02:52 03:21 03:50 04:19

Microsoft App-V

Symantec SWS

Jukebox Application

Instalacja lokalna

Czas [s]

Drugie uruchomienie Pierwsze uruchomienie

00:29

00:43

00:08

00:11

00:32

00:00 00:07 00:14 00:21 00:28 00:36 00:43 00:50

Microsoft App-V

Jukebox Application

Instalacja lokalna

Czas [s]

Drugie uruchomienie Pierwsze uruchomienie

63

5.3.2. Obciążenie procesora

Wykresy poniżej przedstawiają procent minionego czasu, jaki procesor zużywa do

wykonania wątku czynnego, innymi słowy jest to wyrażone procentowo obciążenie

procesora w danej chwili czasu. Jest to podstawowy wskaźnik obrazujący pracę procesora.

Każda linia na danym wykresie zawiera znacznik, oznaczony nim został czas w którym

zostało otwarte okno główne aplikacji.

Wykres 3. Wykorzystanie procesora. Aplikacja z kompresją danych - pierwsze uruchomienie

Wykres 4. Wykorzystanie procesora. Aplikacja z kompresją danych. Drugie uruchomienie

0

20

40

60

80

100

120

0:00 0:07 0:14 0:21 0:28 0:36 0:43 0:50 0:57 1:04

Ob

cią

żen

ie p

roce

sora

[%

]

Czas [s]

Jukebox (kompresja) App-V (kompresja) Instalacja rzeczywista

0

20

40

60

80

100

120

0:00 0:07 0:14 0:21 0:28 0:36 0:43 0:50

Ob

cią

żen

ie p

roce

sora

[%

]

Czas [s]

App-V (kompresja) Jukebox (kompresja) Instalacja rzeczywista

64

Spośród badanych rozwiązań w przypadku uruchamiania aplikacji zwirtualizowanej

poddanej kompresji – wykresy 3 i 4, zarejestrowane obciążenie procesora na stacji

roboczej jest najwyższe dla rozwiązania Jukebox. Utrzymuje się ono na wysokim

poziomie, aż do momentu otwarcia okna aplikacji. Nie jednokrotnie obciążenie w tym

przypadku osiągało niemalże 100%. App-V mimo dużo szybszego wyświetlenia okna

aplikacji cechuj się mniejszym obciążeniem procesora w czasie całego czasu

monitorowania w porównaniu z Jukebox Application.

Wykres 5. Wykorzystanie procesora. aplikacja bez kompresji danych. Pierwsze uruchomienie

Wykres 6. Wykorzystanie procesora. Aplikacja bez kompresji danych. Drugie uruchomienie

0

20

40

60

80

100

120

0:00 0:14 0:28 0:43 0:57 1:12 1:26

Ob

cią

żen

ie p

roce

sora

[%

]

Czas [s]

App-V (bez kompresji) Jukebox (bez kompresji) Instalacja rzeczywista

0

20

40

60

80

100

120

0:00 0:07 0:14 0:21 0:28 0:36 0:43 0:50

Ob

cią

żen

ie p

roce

sora

[%

]

Czas [s]

App-V (bez kompresji) Jukebox (bez kompresji) Instalacja rzeczywista

65

Wykres 7. Wykorzystanie procesora dla SWS. Aplikacja bez kompresji danych. Pierwsze uruchomienie.

Wykres 8. Wykorzystanie procesora dla SWS. Aplikacja bez kompresji danych. Pierwsze uruchomienie

Podczas badania wybranych rozwiązań dla aplikacji stworzonej bez kompresji danych,

ogólny kształt wykresów (5 i 6) obrazujących obciążenie procesora dla narzędzi Jukebox

i App-V nie ulega zmianie. Dodatkowo na kolejnych dwóch wykresach (7 i 8) zostało

przedstawione obciążenie generowane w przypadku badań rozwiązania firmy Symantec.

Jest ono zdecydowanie niższe niż to generowane przy badaniu rozwiązania Jukebox,

jednak należy zwrócić uwagę na czas po jakim w przypadku pierwszego uruchomienia

zostało otwarte okno aplikacji – ponad 3 minuty. Momentami również osiąga ono wysokie

wartości sięgające 80, a nawet prawie 100%. Podczas drugiego uruchomienia aplikacji

mimo dużo szybszego wyświetlenia okna głównego, obciążenie procesora przez długi czas

jest podwyższone i oscyluje w okolicach 10%.

0

20

40

60

80

100

120

0:00 0:28 0:57 1:26 1:55 2:24 2:52 3:21 3:50 4:19

Ob

cią

żen

ie p

roce

sora

[%

]

Czas [s]

0

10

20

30

40

50

60

0:00 0:14 0:28 0:43 0:57 1:12 1:26

Ob

cią

żen

ie p

roce

sora

[%

]

Czas [s]

66

Dodatkowo na wykresach od 3 do 6 zostało przedstawione obciążenie generowane podczas

uruchamiania aplikacji zainstalowanej lokalnie, gdzie do momentu otwarcia okna aplikacji

obciążenie jest bardzo małe, prawie zerowe.

Obciążenie występujące w kolejnych chwilach jest zbliżone do tego generowanego przez

Microsoft App-V. W przypadku drugiego uruchomienia aplikacji przy badaniach App-V

można zauważyć szybsze ustabilizowanie się pracy procesora w porównaniu z aplikacją

instalowaną lokalnie.

5.3.3. Wykorzystanie pamięci operacyjnej

Wzrost wykorzystania pamięci operacyjnej zarejestrowany na stacjach roboczych

podczas uruchomienia zwirtualizowanej aplikacji został przedstawiony poniżej. Wykres 9

odnosi się do pierwszego uruchomienia aplikacji, zaś Wykres 10 przedstawia

wykorzystania pamięci operacyjnej przy drugim uruchomieniu. Dodatkowo na obu

wykresach zostało przedstawione wykorzystanie pamięci dla instalacji lokalnej. Tak jak

w przypadku obciążenia procesora na wykresach znajdują się znaczniki określające

moment otwarcia okna głównego aplikacji.

Wykres 9. Wykorzystanie pamięci operacyjnej. Pierwsze uruchomienie

Jak widać na Wykresie 9 w każdym przypadku po otwarciu okna głównego aplikacji

obserwowany jest nadal wzrost wykorzystanej pamięci operacyjnej.

0

50

100

150

200

250

300

350

400

0:00 0:28 0:57 1:26 1:55 2:24 2:52 3:21 3:50 4:19

Pa

mię

ć R

AM

[M

B]

Czas [s]

App-V (kompresja) Jukebox (kompresja) App-V (bez kompresji)

Jukebox (bez kompresji) SWS Instalacja rzeczywista

67

Największe wykorzystanie pamięci operacyjnej podczas procesu uruchamiania aplikacji

można odnotować dla rozwiązania firmy Microsoft. Podczas tego procesu najmniejszy

wzrost został zaobserwowany dla aplikacji zainstalowanej lokalnie.

Biorąc pod uwagę cały okres monitorowania rozwiązanie Jukebox cechuje się bardzo

podobnym wykorzystaniem pamięci operacyjnej w stosunku do instalacji lokalnej,

Wykres 10. Wykorzystanie pamięci operacyjnej. Drugie uruchomienie

W przypadku drugiego uruchomienia również po wyświetleniu okna głównego aplikacji

nadal można zaobserwować wzrost wykorzystania pamięci RAM. Biorąc pod uwagę cały

okres monitorowania ustabilizowanie wykorzystania pamięci operacyjnej następuje na

bardzo zbliżonym poziomie. Dotyczy to zarówno aplikacji poddanych wirtualizacji jak i tej

zainstalowanej lokalnie. Zanotowanie mniejszego w tym przypadku wzrostu

wykorzystania pamięci operacyjnej wszystkich rozwiązań w stosunku do aplikacji

zainstalowanej w sposób tradycyjny może wynikać ze sposobu działania tych rozwiązań.

Każde z tych rozwiązań pobierało z serwera podczas pierwszego uruchomienia tylko

niezbędne minimum plików potrzebna do działania zwirtualizowanej aplikacji. Z kolei

aplikacja uruchamiana w sposób tradycyjny może podczas startu ładować więcej plików

do pamięci, aby zapewnić jak najbardziej płynne i szybkie działanie, stąd wzrost

wykorzystania pamięci operacyjnej może być nieznacznie większy.

0

20

40

60

80

100

120

140

0:00 0:14 0:28 0:43 0:57 1:12 1:26 1:40

Pa

mię

ć R

AM

[M

B]

Czas [s]

App-V (kompresja) Jukebox (kompresja) App-V (bez kompresji)

Jukebox (bez kompresji) SWS Instalacja rzeczywista

68

5.3.4. Generowany ruch sieciowy

Wykresy związane z siecią przedstawiają ilość odebranych przez komputer kliencki

danych w danej chwili czasu. Zostało to przedstawione w wersji sumarycznej

(Wykres 11), oraz jako zmiany w czasie natężenia ruchu sieciowego odbieranego przez

klienta(Wykresy 12-16). Z racji, iż Monitor wydajności rejestrował wszystkie wartości

monitorowanych wielkości co 1 sekundą, wykres obrazuje ilość odebranych danych

w każdej sekundzie. Mimo iż dla każdego z rozwiązań wirtualizowaną aplikacją był

Matlab 2008A, ilość przesłanych danych do klienta znacznie się różni w zależności od

wykorzystanego rozwiązania.

Wykres 11. Ilość danych odebranych przez klienta

Jak widać na Wykresie 11 największa ilość danych została przesłana do klienta

w przypadku badania rozwiązania firmy Microsoft. Dotyczy to zarówno aplikacji

stworzonej z kompresją (131 MB) danych jak i bez (57 MB). Dla porównania rozwiązanie

firmy Symantec przesłało do klienta 71 MB – jest to konfiguracja aplikacji bez kompresji.

W przypadku aplikacji skompresowanej najmniejszą ilość danych przesyła Jukebox

Application tj. 27 MB.

131

57

77

27

71

0 20 40 60 80 100 120 140

Bez kompresji

Kompresja

Bez kompresji

Kompresja

Mic

roso

ft A

pp

-V

En

de

vad

ors

Juk

eb

ox

Sy

ma

nte

c

SW

S

Odebrane dane [MB]

69

Wykres 12. Odbierany ruch sieciowy przez klienta. Pierwsze uruchomienie aplikacji z kompresją danych

Jak widać na Wykresie 12 poziom ruchu generowany przez oba rozwiązania znacznie się

różni między sobą. Ruch odbierany przez klienta podczas pierwszego uruchomienia

aplikacji dla rozwiązania Jukebox nie przekracza 2MB/s. Dla rozwiązania firmy Microsoft

poziom ruchu odbieranego przez klienta jest znacznie większy i sięga on nawet 6 MB/s.

Mimo większej ilości danych jak przesyłane było przy badaniach rozwiązania App-V,

dzięki właśnie ruchowi na wyższym poziomie następuje szybsze otwarcie okna aplikacji

jak i przesłanie niezbędnej ilości danych.

Wykres 13. Odbierany ruch sieciowy przez klienta. Pierwsze uruchomienie aplikacji bez kompresji danych

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

0:00 0:07 0:14 0:21 0:28 0:36 0:43 0:50 0:57 1:04

Ob

cią

żen

ie [

MB

]

Czas [s]

App-V (kompresja) Jukebox (kompresja)

0

2

4

6

8

10

12

0:00 0:28 0:57 1:26 1:55 2:24 2:52 3:21 3:50

Ge

ne

row

an

y r

uch

[M

B]

Czas [s]

App-V (bez kompresji) Jukebox (bez kompresji) SWS

70

Wykres 14. Odbierany ruch sieciowy przez klienta. Pierwsze uruchomienie aplikacji z kompresją danych

Ruch generowany podczas przesyłania aplikacji nie poddanej kompresji został

przedstawiony na dwóch Wykresach 13 i 14. Dokonano tego z racji na lepszą czytelność

zmian w ruchu dla rozwiązań Jukebox i App-V.

Dla aplikacji nie poddanej kompresji poziom ruchu dla rozwiązania firmy Microsoft

w pewnym momencie sięga prawie 12 MB/s. Przez większość czasu monitorowania

poziom ruchu był wyższy od 2MB/s i spadł w momencie otwarcia na stacji roboczej okna

aplikacji. Jukebox tak jak i wcześniej utrzymuje ruch na poziomie 2 MB/s,

poza początkową faza przesyłania gdzie osiągnął on poziom do 6MB/s. Jak widać na

Wykresie 13 rozwiązanie SWS w końcowej fazie generuje ruch na poziomie dochodzącym

prawie do 8MB/s. W przypadku drugiego uruchomienia, kiedy minimum danych

związanych z aplikacjom zostało już przesłanych do klienta ruch odbierany jest bardzo

mały, co przedstawia Wykres 15. Najwyższy ruch w tym przypadku to pik wygenerowany

przez rozwiązanie Jukebox. Dotyczy on przypadku uruchamiania aplikacji bez kompresji

danych i sięga prawie 200 kB/s.

0

2

4

6

8

10

12

0:00 0:07 0:14 0:21 0:28 0:36 0:43 0:50 0:57 1:04 1:12

Ge

ne

row

an

y r

uch

[M

B]

Czas [s]

App-V (bez kompresji) Jukebox (bez kompresji)

71

Wykres 15. Odbierany ruch sieciowy przez klienta. Drugie uruchomienie aplikacji

Kolejne dwa Wykresy (16 i 17) dotyczą testów serwera, gdzie na trzech stacjach

roboczych była uruchamiana zwirtualizowana aplikacja. Jest to zestawienie danych

wysłanych przez serwer przez cały okres monitorowania. Początek wykresu równy jest

wysłaniu żądania aplikacji przez pierwszego klienta. Kolejne uruchomienia aplikacji tak

jak zostało to napisane wcześniej w tej pracy odbywało się po upływie 15 do 20 sekund od

poprzedniego. Rozwiązanie Jukebox charakteryzuje się ruchem generowanym na

najmniejszym poziomie. Dla aplikacji bez kompresji jest on na poziomie 1MB/s – 2MB/s.

W przypadku aplikacji skompresowanej jest on równie na niskim poziomie

0,5MB/s – 1MB/s. App-V generuje ruch na najwyższym poziomie w przypadku aplikacji

bez kompresji początkowo dochodzi on do poziomu 6-8 MB/s. Jak widać na Wykresie 17

po upływie około 50 sekund spada on do poziomu w granicach 1MB/s i utrzymuje się tak,

aż do zakończenia przesyłania wszystkich danych. Ruch dla SWS jest dosyć specyficzny

i w tym przypadku. Przez bardzo długi okres jest on na bardzo niskim poziomie.

W końcowej fazie wzrasta do poziomu około 8MB/s, aby później spaść do około 1MB/s.

0

50

100

150

200

250

0:00 0:07 0:14 0:21 0:28 0:36 0:43

Ge

ne

row

an

y r

uch

[k

B]

Czas [s]

App-V (kompresja)

Jukebox (kompresja)

App-V (bez kompresji)

Jukebox (bez kompresji)

SWS

Wykres 16. Ruch sieciowy po stronie serwera. Aplikacja bez kompresji danych

Wykres 17. Ruch sieciowy po stronie serwera. Aplikacja z kompresj

0,00

2,00

4,00

6,00

8,00

10,00

00:00 00:50

Ge

ne

row

an

y r

uch

[M

B]

0,00

0,50

1,00

1,50

2,00

2,50

3,00

3,50

4,00

4,50

0:00 0:25

Ge

ne

row

an

y r

uch

[M

B]

ch sieciowy po stronie serwera. Aplikacja bez kompresji danych

. Ruch sieciowy po stronie serwera. Aplikacja z kompresj

01:40 02:30 03:20 04:10 05:00 05:50

Czas [s]

0:50 1:15 1:40 2:05 2:30 2:55 3:20

Czas [s]

72

ch sieciowy po stronie serwera. Aplikacja bez kompresji danych

. Ruch sieciowy po stronie serwera. Aplikacja z kompresją danych

05:50

APP-V

JUKEBOX LITE

SYMANTEC

APP-V

JUKEBOX LITE

73

5.3.5. Czas tworzenia zwirtualizowanej aplikacji

W przypadku technologii wirtualizacji aplikacji wszystko zaczyna się od stworzenia takiej

aplikacji. Sam proces tworzenia zwirtualizowanej aplikacji jest bardzo podobny do siebie

niezależnie od zastosowanego rozwiązania. Jednak czasy tworzenia takiej aplikacji są

bardzo zróżnicowane.

Wykres 18. Czas tworzenia zwirtualizowanej aplikacji

Najmniej czasu na stworzenie zwirtualizowanej aplikacji na podstawie aplikacji Matlab

potrzebuje rozwiązanie firmy Microsoft. Jukebox radzi sobie bardzo dobrze w przypadku

przygotowywania aplikacji bez kompresji danych, jednak stworzenie aplikacji z kompresją

danych to już ponad godzina. Symantec tworzył zwirtualizowana aplikację – bez kompresji

danych, niecałą godzinę.

5.4. Wnioski

Do tej pory przedstawione zostały wyniki badań dotyczące stacji roboczej i jedynie

ruch sieciowy generowany przez serwer w przypadku obsługi żądań trzech klientów.

Pozostałe parametry serwera takie jak wykorzystanie pamięci operacyjnej, czy procesora

również zostały poddane monitorowaniu, w sposób opisany we wcześniejszej części pracy

jednak nie zostały one tutaj zamieszczone. Powód ich nie zamieszczenia wynikł z bardzo

znikomego obciążenia zasobów serwera w przypadku tylko trzech komputerów klienckich.

12:12

16:55

18:41

66:49

59:17

0:0 12:0 24:0 36:0 48:0 60:0 72:0

Bez kompresji

Kompresja

Bez kompresji

Kompresja

Mic

roso

ft

Ap

p-V

En

de

vad

ors

Juk

eb

ox

Sy

ma

nte

c

SW

S

Czas [min]

74

W przypadku procesora był to skokowy wzrost wartości obciążenia o 2-3% w stosunku do

poziomu kiedy serwer nie odbierał żadnych żądań przesłania aplikacji.

Wzrost wykorzystania pamięci operacyjnej w czasie przesyłania do trzech klientów

aplikacji oscylował w granicy 20-50 MB. Taki stan rzeczy pokazuje, że całość obciążenia

związanego z obsługą aplikacji przechodzi na stacje roboczą, a serwer który został

wykorzystany do testów w pracy mógłby publikować znacznie większą ilość aplikacji dla

równie większej ilości użytkowników.

Zbierając wszystko co zostało przedstawione do tej pory w części badawczej pracy można

pokrótce scharakteryzować każde z rozwiązań. Oczywiście wszystko to dotyczy procesu

uruchamiania zwirtualizowanej aplikacji jaką był Matlab 2008A.

Microsoft Application Virtualization:

• najkrótszy czas potrzeby do wyświetlenia okna głównego aplikacji,

• najmniejsze obciążenie procesora,

• największy wzrost wykorzystania pamięci operacyjnej – pierwsze uruchomienie

• wysyła do klienta najwięcej danych związanych z wirtualizowaną aplikacjom,

• ruch sieciowy generowany na najwyższym poziomie,

• najkrótszy czas tworzenia zwirtualizowanej aplikacji.

Endevadors Jukebox Application:

• najdłuższy czas potrzeby do wyświetlenia okna głównego aplikacji – czas 22

sekund,drugie uruchomienie bez kompresji danych,

• największe obciążenie procesora do momentu otwarcia okna głównego aplikacji

jak i po nim,

• najmniejszy wzrost wykorzystania pamięci operacyjnej – dla pierwszego

uruchomienia,

• wysyła najmniej danych w przypadku aplikacji poddanej kompresji,

• ruch sieciowy generowany na najniższym poziomie,

• najdłuższy czas tworzenia aplikacji z kompresją danych.

75

Symantec SWS:

• najdłuższy czas potrzebny do wyświetlenia okna głównego aplikacji – rzędu 3 do 4

minut przy pierwszym uruchomieniu

• średnie obciążenie procesora,

• średni wzrost wykorzystania pamięci operacyjnej – dla pierwszego uruchomienia,

• wysyła najmniej danych,

• ruch sieciowy na wysokim poziomie, ale tylko w krótkim przedziale czasu, poza

nim niski,

• najdłuższy czas tworzenia zwirtualizowanej aplikacji bez kompresji danych.

6. Podsumowanie

W dzisiejszych czasach wirtualizacja coraz szerzej zagląda do branży IT. Jeżeli chodzi

o wirtualizacje aplikacji na rynku dostępne są rozwiązania takich firm jak Microsoft,

Citrix, VMware, Endeavors, Novell, Symantec, czy InstallFree. W pracy zostały

przedstawione i poddane testom rozwiązania firmy Microsoft, Endeavors i Symantec,

wybór właśnie na te rozwiązania padł nie bez powodu. Warto przyjrzeć się w tym

momencie procentowemu udziałowi firm na rynku związanym z wirtualizacją aplikacji.

W roku 2010 największy udział na tym rynku miała firma Microsoft tj. 15%, kolejno były

to firmy Citrix i VMware z udziałem 11% i 7%. Według firmy ITIC pozostała część rynku

nie korzystała z wirtualizacji aplikacji. Taki podział udziałów sugeruje, że w pracy mogły

zostać przetestowane równie dobrze właśnie rozwiązania tych trzech firmy, najbardziej

znanych. W pracy jednak postawiono również na rozwiązania mniej znane, które

w przypadku raportu firmy ITIC nie zostały w nim uwzględnione. Porównanie rozwiązania

App-V, które na rynku wirtualizacji aplikacji ma największy procent udziału. Rozwiązania

Jukebox firmy Endeavors, która uważa się za pioniera w technologii wirtualizacji

i dostarczania aplikacji do klienta na żądanie. I na koniec rozwiązanie firmy Symantec,

która w głównej mierze specjalizuje się w dziedzinie bezpieczeństwa danych. Taki wybór

badanych rozwiązań miał pokazać, czy te mniej znane zasługują na uwagę podczas

ewentualnego wdrażania wirtualizacji aplikacji w istniejącą infrastrukturę. Jak pokazały

wyniki przeprowadzonych badań każde z rozwiązań podczas procesu uruchamiania

aplikacji charakteryzuje się odmiennym wykorzystaniem zasobów.

76

Istotnym w tym przypadku jest ruch generowany przez poszczególne rozwiązania,

ponieważ może on mieć kluczowe znaczenie przy wdrażaniu takiego rozwiązania.

Microsoft App-V generuje ruch na najwyższym poziomie, przesyła on również przy

pierwszym uruchomieniu największą ilość danych. Korzyścią takiego działania

niewątpliwie jest szybkie dostarczenie aplikacji do użytkownika, jednak w momencie

odwołania się do serwera wielu użytkowników w zbliżonym czasie ruch na tym poziomie

może okazać się wąskim gardłem sieci. Rozwiązanie Jukebox generuje ruch na bardzo

niskim poziomie, co widać po przeprowadzeniu testów stacji roboczej jaki i serwera

z udziałem 3 komputerów klienckich. Daje to dłuższy czas oczekiwania na aplikacje przez

klienta jednak niweluje w pewnym stopniu zapchanie sieci.

Ruch generowany przez SWS jest specyficzny ponieważ przez dłuższy czas żądania

aplikacji jest on na prawie zerowym poziomie, jednak w momencie wzrostu osiąga on

poziom porównywalny do rozwiązania firmy Microsoft. Jeżeli chodzi o funkcjonalność

każdego z rozwiązań to jest ona zbliżona do siebie. Zaczynając od tworzenia aplikacji

najbardziej intuicyjny jest program firmy Microsoft oraz Symantec, w którym istnieje

możliwość tworzenia aplikacji krok po kroku za pomocą kreatora. Jukebox nie daje takiej

możliwości co w fazie poznawania tej części oprogramowania wymaga poświęcenia

większej ilości czasu na przygotowanie aplikacji jednak nie jest to skomplikowany proces.

Po stronie serwera każde z rozwiązań dysponuje własnym narzędziem do zarządzania

dostępnym z poziomu strony WWW, czy też jako przystawka konsoli MMC

(ang. Microsoft Management Console) w przypadku App-V. Każde z nich ma bardzo

zbliżoną funkcjonalność zaczynając od możliwości dodana nowych paczek z aplikacjami

przez zarządzanie użytkownikami, którzy mają do nich dostęp, po generowanie raportów

wykorzystania aplikacji. Bardzo istotną rzeczą w przypadku oprogramowania na serwerze

jest możliwość jego rozbudowy i dostosowywania pod konkretne środowisko i potrzeby.

Każde z badanych rozwiązań daje możliwość stworzenia rozbudowanej infrastruktury

z centralnym punktem odpowiadającym za zarządzanie całościom, daje to możliwość

budowy infrastruktury wirtualizacji aplikacji w większych przedsiębiorstwach. W tym

wypadku najbardziej korzystnie wypada rozwiązanie firmy Microsoft, które może być

wdrożone w trzech architekturach w zależności od istniejącej już infrastruktury i korzyści

które mają zostać osiągnięte.

77

W przedsiębiorstwach, gdzie niejednokrotnie pracownik potrzebuje dostępu do aplikacji

będąc w podróży, czy też w domu. Wszędzie tam wprowadzenie wirtualizacji aplikacji

może okazać się bardzo dobrym posunięciem. Jeżeli chodzi o wybór konkretnego

rozwiązania będzie to zależało od indywidualnych potrzeb danego przedsiębiorstwa.

Na pewno można napisać, że rozwiązania mniej znane, przy rozwiązaniu firmy Microsoft

również zasługują na uwagę. Nie odbiegają one funkcjonalnością od rozwiązania App-V,

a w niektórych przypadkach po dłuższym użytkowaniu może okazać się że przewyższają

to rozwiązanie. Niezależnie od wyboru rozwiązania sama wirtualizacji aplikacji jest

sposobem na usprawnienie zarządzania i kontroli nad aplikacjami niosącym wiele zalet.

78

Spis rysunków Rysunek 1. Ważniejsze wydarzenia dziedziny wirtualizacji ........................................................................... 10

Rysunek 2. Logicznie oddzielone obszary sesji chronionej i systemu ............................................................. 15

Rysunek 3. Zakres zastosowania wirtualizacji................................................................................................. 18

Rysunek 4. Przykładowa struktura sieci .......................................................................................................... 22

Rysunek 5. Po lewej topologia sieci VPN każdy z każdym.. ........................................................................... 24

Rysunek 6. Wiele VRF na jednym routerze. ................................................................................................... 24

Rysunek 7.Wykorzystanie VRF w implementacji sieci VPN opartej o technikę MPLS ................................. 25

Rysunek 8. Implementacja symetryczna w ścieżce danych. ............................................................................ 29

Rysunek 9. Implementacja asymetryczna poza ścieżką danych. ..................................................................... 30

Rysunek 10. Pierścienie dostępu. ..................................................................................................................... 32

Rysunek 11. Schemat przedstawiający emulacje. ............................................................................................ 33

Rysunek 12. Schemat przedstawiający parawirtualizację. ............................................................................... 33

Rysunek 13. Schemat przedstawiający pełną wirtualizacje. ............................................................................ 34

Rysunek 14. Schemat wirtualizacji na poziomie hosta. ................................................................................... 35

Rysunek 15. Składowe profilu użytkownika. .................................................................................................. 37

Rysunek 16. Korzystanie z zasobów przez normalne aplikacje ....................................................................... 42

Rysunek 17. Wirtualna aplikacja w systemie operacyjnym ............................................................................. 42

Rysunek 18. Wdrażanie oprogramowania. Cykl życia .................................................................................... 44

Rysunek 19. Droga zwirtualizowanje apliakcji – do stworzenia do opublikowania. ....................................... 46

Rysunek 20. Architektura rozproszona rozwiązania firmy Symantec. ............................................................ 51

Rysunek 21. Schemat systemu Jukebox Server ............................................................................................... 52

79

Spis wykresów Wykres 1. Uruchomienie aplikacji Matlab, bez kompresji danych ................................................................. 62

Wykres 2. Uruchomienie aplikacji Matlab, z kompresją danych..................................................................... 62

Wykres 3. Aplikacja z kompresją danych - pierwsze uruchomienie ............................................................... 63

Wykres 4. wykorzystanie procesora. Aplikacja z kompresją danych. Drugie uruchomienie .......................... 63

Wykres 5. wykorzystanie procesora. aplikacja bez kompresji danych. Pierwsze uruchomienie ..................... 64

Wykres 6. wykorzystanie procesora. aplikacja bez kompresji danych. Drugie uruchomienie ........................ 64

Wykres 7. Ruch sieciowy dla rozwiązania Symantec. Pierwsze uruchomienie ............................................... 65

Wykres 8. Ruch sieciowy dla rozwiązania Symantec. Drugie uruchomienie .................................................. 65

Wykres 9. Wykorzystanie pamięci operacyjnej. Pierwsze uruchomienie ........................................................ 66

Wykres 10. Wykorzystanie pamięci operacyjnej. Drugie uruchomienie. ........................................................ 67

Wykres 11. Ilość danych odebranych przez klienta. ........................................................................................ 68

Wykres 12. Odbierany ruch sieciowy przez klienta. Pierwsze uruchomienie aplikacji z kompresją danych .. 69

Wykres 13. Odbierany ruch sieciowy przez klienta. Pierwsze uruchomienie aplikacji bez kompresji danych 69

Wykres 14. Odbierany ruch sieciowy przez klienta. Pierwsze uruchomienie aplikacji z kompresją danych .. 70

Wykres 15. Drugie uruchomienie aplikacji bez kompresji danych. Ruch sieciowy ........................................ 71

Wykres 16. Ruch sieciowy po stronie serwera. Aplikacja bez kompresji danych ........................................... 72

Wykres 17. Ruch sieciowy po stronie serwera. Aplikacja z kompresją danych .............................................. 72

Wykres 18. Czas tworzenia zwirtualizowanej aplikacji. .................................................................................. 73

80

Spis tabel Tabela 1. Kolejne wydania rozwiązania SoftGrid (App-V). ............................................................................ 12

Tabela 2. Kolejne wydania rozwiązań firmy Citrix.[ ....................................................................................... 13

Tabela 3. Skrypt pozwalający na określenie czasu po jakim wyświetliło się okno apliakcji. .......................... 57

Tabela 4. Skrypt wykorzystany przy badaniu serwera ..................................................................................... 58

Tabela 5. Skryp do testowania stacji roboczej ................................................................................................. 59

81

Literatura 1 Ł.Wadowski, P. Masztafiak; "Historia wirtualizacji cz. 1", www.virtual-it.pl, 2009

2 M. Lelusz, "Rys historyczny technologii wirtualizacji." www.blog.inleo.pl, 2009

3 T. Mangan; "10 year's after WoW", www.brianmadden.com, 2011

4 "Microsoft Completes Acquisition of Softricity" www.microsoft.com

5 T. Mangan; Zbiór artykułów, "Story from the Grid", www.appvirtguru.com

6 B. Madden; "Softricity announces SoftGrid 3.0: Is this the future of server-based computing?",

ww.brianmadden.com, 2003

7 "Server based computing", 2X Software Ltd. 2010

8 B. Madden; "Citrix Presentation Server 4.5 Book's", 2008

9 B. Madden; "A Technical Analysis of Citrix's Application Streaming Announcement",

www.brianmadden.com

10 P. Musich; "Citrix to Release Tarpon Technology", www.eweek.com, 2007

11" VMware Workstation History", www.geeni.in, 2010

12 "Happy birth day ThinApp", www.vmware.com, 2010

13 "FSLogic Protect Administrator Guide", FSLogic Inc. 2003

14 "Software Virtualization solution", www.en.wikipedia.org

15 "Altiris & AppStream Ink Pact on Software Virtualization", www.dabcc.com, 2006

16 "Focus Solution Profile: Endeavors Technologies", 2007 Focus Consulting

17 Virtualization datasheet, Endeavors Technologies Ltd, 2009

18 D. Rule, R. Dittner, "The best damn server virtualization book period", Syngress Publishing, Inc. 2007

19 "Czym jest wirtualizacja ?"; www.microsoft.com

20 R. Krzywania "Wirtualizacja sieci komputerowych" PCSS, 2010

21 R. Janus; "Zwirtualizować można całą sieć", www.virtualfocus.pl, 2008

22 A. S. Tanenbaum; "Sieci komputerowe", Helion, 2005

23 A. Johnson, "Switching Basics and Intermediate Routing CCNA 3 Labs and Study Guide

24 R. Janus; "VLAN dla zaawansowanych", www.netfocus.pl , 2010

25 V. Moreno; "Network virtualization", Cisco Press, 2006

26 "Cisco: The basics about VRF implementation" 2009

27 S. Adamiec; "MPLS VPN – Virtual Private Network"; www.tech-portal.pl

28 J. Chustecki, D. Newman; "VSS – wirtualizacja przełączników Catalyst 6500", www,networld.pl, 2008

29 Sz. Pomorski; "Wirtualziacja pamięci masowych"; www.networld.pl 2009

30 K. Jakubik, N McAllister, S. Norall, "Wirtualizować można wszystko" www.virtualizationstandard.pl,

2008

31 Sz. Pomorski "Wirtualizacja pamięci masowych" www.networld.pl 2009

32 J. chustecki; "Trzy metody wirtualizacji pamięci masowych" www.virtualizationstandard.pl, 2007

33 VMware, "Understanding Full Virtualization, Paravirtualization, and Hardware Assist", VMware Inc,

2007

82

34 J. N. Matthews; E. M. Dow; T. Deshane;"Running Xen: A Hands-On Guide to the Art of Virtualization";

Prentice Hall, 2008

35 D.Vile, T. Lock, M.Atherton, J.Collins; "Desktop Virtualization for dummies" John Wiley & Sons, Ltd,

2010

36 "Demos and Tutorials - Microsoft User State Virtualization" www.technet.microosft.com

37 M. Tulloch; " Windows User State Virtualization-Part 1:Technologies and Issues"

www.windowsnetworking.com; 2010

38 M. Tulloch; "VDI vs. Session Virtualization", www.biztechmagazine.com, 2011

39 App-V Architecture, www.app-vsupport.com

40 Ch. Hampton, "Application Virtualization", www.realtimepublishers.com

41 D. Clark, "Application virtualization: The natural extension to VDI", Xtarvirt Ltd., 2009

42 A. Alvarez, "Getting started with Microsoft Application Virtualization 4.6", Packt Publishing, 2011

43 Zespół Solution Accelerators–Management and Infrastructure, "Infrastructure Planning and Design guide:

Microsoft Application Virtualization 4.6", Microsoft Corporation, 2010

44 Przewodnik: "Symantec™ Workspace Streaming 6.1 SP6 Administration Guide", Symantec Corporation,

2010

45 Przewodnik: "Application Jukebox server: Administration guide", endevadors Technologies, Inc. 2010

46 Overview of Windows Performance Monitor: http://technet.microsoft.com/en-us/

47 Creating Data Collector Sets: http://technet.microsoft.com/en-us/

48 PsTools: http://technet.microsoft.com

49 PsExec: http://technet.microsoft.com

50 How to capture network traffic with Network Monitor: http://support.microsoft.com

51 Network Monitor Fields and Properties for Filtering: http://social.technet.microsoft.com

52 Autoit Overview: http://www.autoitscript.com