POLITECHNIKA CZĘSTOCHOWSKA WYDZIAŁ INŻYNIERII PROCESOWEJ, MATERIAŁOWEJ I FIZYKI STOSOWANEJ
POLITECHNIKA ŚLĄSKA WYDZIAŁ IN ŻYNIERII MATERIAŁOWEJ I...
Transcript of POLITECHNIKA ŚLĄSKA WYDZIAŁ IN ŻYNIERII MATERIAŁOWEJ I...
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