Virtualizace real-time aplikací

Rok / Year: 2012

Svazek / Volume: 14

Číslo / Issue: 1

Virtualizace real-time aplikací Virtualization of real-time applications Jiří Šlachta, Jan Rozhon, Miroslav Vozňák [email protected],[email protected],[email protected] VŠB – Technická univerzita Ostrava

Abstrakt: V tomto článku se zabýváme dopadem virtualizace na interaktivní aplikace citlivé na velikost zpoždění. Jako typický příklad těchto aplikací byla vybrána IP telefonie. Virtualizace je hojně využívaným prostředkem pro snížení nákladů, zjednodušení administrace a zálohování klíčových aplikací jak v komerční, tak v nekomerční sféře. Cílem tohoto článku je zjistit dopad jednotlivých virtualizačních technik na komunikaci v reálném čase reprezentovanou IP telefonií, konkrétně provozem na protokolech SIP a RTP. Jednotlivé virtualizační techniky jsou zkoumány i z pohledu počtu virtuálních CPU a velikosti paměti a dopadu těchto parametrů na výkon virtualizovaného stroje.

Abstract: In this paper we explore the impact of virtualization the interactive application sensitive to the magnitude of delay. Typical example of such application is IP telephony. Virtualization is frequently used for reducing costs, simplify administration and backup of key applications . The aim of this article is the impact of virtualization technology on communication in real time represented by the IP telephony, namely operation of SIP and RTP. Individual virtualization techniques are examined from the perspective of a virtual CPU memory size and the impact of these parameters on the performance of virtualized machines.

2012/5 – 16. 1. 2012

Virtualizace real-time aplikací Jiří Šlachta, Jan Rozhon, Miroslav Vozňák Fakulta elektrotechniky a informatiky VŠB - Technická Univerzita Ostrava Email: {jiri.slachta,jan.rozhon,miroslav.voznak}@vsb.cz

Abstrakt – V tomto článku se zabýváme dopadem virtualizace na interaktivní aplikace citlivé na velikost zpoždění. Jako typický příklad těchto aplikací byla vybrána IP telefonie. Virtualizace je hojně využívaným prostředkem pro snížení nákladů, zjednodušení administrace a zálohování klíčových aplikací jak v komerční, tak v nekomerční sféře. Cílem tohoto článku je zjistit dopad jednotlivých virtualizačních technik na komunikaci v reálném čase reprezentovanou IP telefonií, konkrétně provozem na protokolech SIP a RTP. Jednotlivé virtualizační techniky jsou zkoumány i z pohledu počtu virtuálních CPU a velikosti paměti a dopadu těchto parametrů na výkon virtualizovaného stroje.

1 Úvod Jedním z významných trendů ICT je tendence nasazovat různé aplikace na virtualizovaná řešení namísto dedikovaných HW platforem. Mezi přínosy, které přínáší tento postup, lze zařadit výšší efektivitu využití HW, jednoduchost zálohování a obnovení aplikací po poruše zařízení či kolapsu OS, bezpečnost, management a nezávislost provozovaných aplikací na HW. Virtualizace, která byla při svých počátcích především výsadou firem a akademického prostředí, se s postupným vývojem rozšířila i na platformy běžných uživatelů, kteří mohou využívat výhod vyplývajících z provozu virtuálních strojů. Jedná se o dlouhodobý trend, což potvrzují i nabídky poskytovatelů služeb, kteří nabízí jako alternativu ke svým hostingovým programům také hostování virtuálních strojů. Uplatnění virtualizace proto nalezneme v mnoha oblastech (serverovny, vývojovová studia, domácnosti, aj.). Výhoda plynoucí z izolace jednotlivých virtuálních strojů je často využívána v kritických aplikacích, u nichž víme, že souběh s dalšími aplikacemi není vhodný. Přenositelnost patří mezi další pozitivní vlastnosti virtuálních strojů. Virtuální stroj je často definován jako konfigurační soubor obsahující vlastnosti virtuálního stroje a datový soubor, který představuje blokové zařízení, na němž je hostovaný operační systém uložen. Tato výhoda předchází časté konfiguraci operačních systémů, stačí nám jen jeden nakonfigurovaný virtuální stroj, jehož kopie můžeme využívat pro testování nových aplikací, a původní originál tak zůstane neporušený. S častějšími použitími virtualizačních řešení je ale nutné uvažovat i o úskalích, která tato řešení přináší. Virtualizace přináší se svými výhodami i jednu velkou nevýhodu ve formě režie, která způsobuje nižší výkon virtuálního stroje, než je k dispozici na reálné, fyzické platformě. Tato režie může způsobit při nasazení aplikací závislých na čase (IP telefonie) vyšší

odezvy a rozptyl zpoždění, což může výrazně degradovat kvalitu hovoru. Cílem této práce proto bude zjistit, jaký vliv mají virtuální stroje na real-time provoz, který bude v našem případě představovat IP telefonii založenou na protokolu RTP. V této je rovněž analyzován vliv velikosti operační paměti a počtu jader procesoru na zpoždění a rozptyl zpoždění.

2 Virtualizační nástroje V rámci zjištění dopadu virtualizace na real-time aplikace jsme zvolili tři velmi často nasazované virtualizační nástroje úplné systémové virtualizace, které budou využity pro měření zpoždění a rozptylu zpoždění. Jedná se o Vmware Player, Kernel-based Virtual Machine (KVM) a VirtualBox. Tyto vybrané virtualizační nástroje jsou volně dostupné pro většinu operačních systémů. Předpoklad je, že KVM bude vzhledem k platformě, nejvýkonnějším virtualizačním nástrojem. Dalším předpokladem je, že VMware Player nebude dosahovat takových výsledků, jako komerční nástroje firmy VMware. Rovněž lze předpokládat, že univerzálnost nástroje VirtualBox jej odsuzuje k nepatrně horším výsledkům než u výše uvedených virtualizačních nástrojů. 2.1 Kernel-based Virtual Machine Vysoké požadavky binárního překladu instrukcí vedly ke kombinování dosud získaných zkušeností z oblasti virtualizace. S příchodem hardwarově asistované virtualizace začal vznikat nový hypervisor ve formě jaderného modulu pro GNU/Linux, který by byl snadně použitelný a měl vysoký výkon. Rozšířením linuxového jádra o modul hypervisora KVM můžeme využít výhod tohoto modelu, díky němuž můžeme spravovat každý virtuální stroj jako standardní linuxový proces.[4] 2.2 VirtualBox Virtualbox je multiplatformním virtualizačním nástrojem, který je navržen pro běh na operačních systémech Windows, Mac OS X, GNU/Linux nebo Solaris na počítačích s mikroprocesory architektury IA-32 a x86-64. Jedná se o virtualizační nástroj úplné virtualizace s hostovaným hypervisorem, tj. je zapotřebí mít k dispozici nainstalovaný operační systém, na kterém může běžet. Virtualbox umožňuje běh virtuálních strojů na všech platformách, na nichž je VirtualBox distribuo-

5–1

VOL.14, NO.1, FEBRUARY 2012

2012/5 – 16. 1. 2012 ván, což umožňuje jednoduchou přenositelnost mezi hostujícími stroji. VirtualBox je aplikací na virtualizaci strojů využívajících hostovaného hypervisora, který je instalován do operačního systému. Čím je VirtualBox význačný, je jeho modularita. Můžeme virtuální stroje spouštět parametrizovaně z příkazové řádky, aniž by došlo k zobrazení okna s virtuálním strojem, nebo z grafického uživatelského rozhraní, v němž si můžeme nastavovat parametry uživatelsky příjemnou cestou.[5] 2.3 VMware Player Nejznámějším příspěvatelem v oblasti virtualizace je firma VMware, jejíž produkty, které jsou určené pro architekturu x86 a x86-64, patří momentálně mezi nejpoužívanější na tomto trhu. Tato společnost nabízí produkty, které obsahují baremetal hypervisora, nebo hostovaného hypervisora, což jim umožňuje pokrýt větší část trhu jejími produkty, které jsou určené jak pro koncové uživatele a jejich desktopy, tak pro datacentra a servery, u nichž je požadovaná vysoká efektivita, škálovatelnost a výkon.

3 Realizace Metodika použitá v této práci spoléhá na volně dostupné nástroje úplné virtualizace, jejichž virtuální stroje budou spouštěny na výkonném hardware podporujícím hardwarově asistovanou virtualizaci. Vzhledem k požadavku na nízké náklady nebyly testovány komerční virtualizační nástroje. 3.1 Příprava měřícího pracoviště Vybranými virtualizačními nástroji pro realizaci měření jsou volně dostupné nástroje úplné virtualizace. Jedná se konkrétně o nástroje KVM, VirtualBox a VMware Player. Vzhledem k nutnosti existence podpory hardwarově asistované virtualizace ze strany nástroje KVM, je nutné, abychom měli k dispozici procesor podporující Intel-VTx či AMD-V, což jsou konkrétní technologie hardwarové virtualizace největších výrobců x86 kompatibilních procesorů. Shrňme si proto parametry testovaného počítače, který bude hostujícím strojem pro virtuální stroje s komunikačním serverem:  Procesor Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz,  operační paměť o velikosti 8 GiB,  dvě 1Gbps síťové karty RTL8111/8168B PCI Express Gigabit Ethernet,  64bitový operační systém Debian Squeeze.

Obr. 1 : Testovací topologie. Testovací topologie (viz obr. 1) je realizována pomocí jednoho počítače, jednoho 1Gbps přepínače a jednoho generátoru Optixia XM2 s vhodnými moduly. Hostující počítač, na kterém budou spouštěny virtuální stroje, obsahuje dvě síťové karty, z nichž první síťová síťová karta je připojena do školní sítě TUONET, a druhá síťová karta určena pro testovaný segment. Do školní sítě je rovněž zapojeno šasi generátoru, na které se budeme připojovat pomocí řídícího software IxLoad, který provede i následnou analýzu dat. Moduly generátoru, které budou použity pro generování provozu, jsou zapojeny do přepínače testovaného segmentu. 3.2 Měřené parametry Síťové real-time aplikace, mezi které patří IP telefonie, jsou závislé na síťových parametrech, které ovlivňují kvalitu přenosu. Mechanismy, které zajišťují kvalitu přenosu v počítačových sítích s přepínáním paketů, aniž by došlo ke snížení snížení kvality služeb, se nazývají QoS (Quality of Service). Popularita QoS je především díky přenosu hlasu či videa přes IP protokol v sítích, kde vyhrazujeme šířku pásma přenosové trasy a prioritizujeme určitý provoz, aby nedošlo k překročení kritických parametrů, mezi které patří zpoždění, rozptyl zpoždění a ztrátovost paketů. Na zařízení Optixia XM2 jsme schopni z pohledu zpoždění a rozptylu zpoždění měřit následující parametry, jejichž význam popisuje dokumentace k řídícímu software IxLoad[1,2]:  Interarrival Jitter – Je definován jako střední hodnota rozdílu časů příchodu mezi dvěma pakety ve srovnání se střední hodnotou rozdílu času odeslání. Výpočet tohoto rozdílu je realizován pomocí RTP časového razítka obsaženého v RTP paketu. Měřená hodnota je v mikrosekundách.  Delay Variation Jitter – Je definován jako zpoždění v mikrosekundách, které je naměřeno mezi odesláním paketu a jeho přijetím.  One Way Delay – Je doba, kterou paket stráví na přenosovém médiu od jeho vyslání, do jeho přijetí. Tento parametr nelze měřit, pokud se na testovaném zařízení (DUT) provádí změna v obsahu RTP paketu. Tento jev nastává při transkódování.  Post Dial Delay – Je zpoždění, které je naměřeno mezi odesláním SIP zprávy INVITE a přijetím odpovědi od koncového endpointu. Měřená hodnota je v milisekundách.

5–2


2012/5 – 16. 1. 2012 

Media Delay – Je zpoždění, které je počítáno od odeslání SIP zprávy INVITE do přijetí prvního RTP paketu. Měřená hodnota je v milisekundách.  Post Pickup Delay – Je zpoždění, které je naměřeno mezi vyzvednutím hovoru a přijetím prvního audio paketu. Tento interval je měřen od odeslání SIP odpovědi 200 OK a přijetím prvního RTP paketu. Měřená hodnota je v milisekundách. Mezi parametry, které ovlivňují kvalitu přenosu zvuku, patří zpoždění a rozptyl zpoždění. Pokud se zaměříme na celý přenosový řetězec, uvědomíme si, že zdrojem zpoždění a rozptylu zpoždění je mnoho faktorů, které se týkají nejen koncových uzlů, ale také přepínačů a směrovačů, které jsou na cestě mezi nimi. Zpoždění proto definujeme jako dobu, za kterou paket projde sítí mezi počátečním a koncovým uzlem. Mezinárodní telekomunikační unie (ITU) definuje ve svých doporučeních (G.114) tři rozsahy, podle kterých můžeme klasifikovat zpoždění:  Zpoždění do 150 ms je přijatelné pro většinu aplikací.  Zpoždění mezi 150 ms a 400 ms již má výrazný dopad na kvalitu přenášené komunikace.  Zpoždění nad 400 ms je nepřijatelné pro veškeré aplikace přenosu hlasu či videa. Jitter označujeme jako rozptyl zpoždění, jedná se o rozdíl mezi očekávaným a skutečným časem přijetím paketu. Tento jev nastane při průchodu paketu IP sítí, při němž dojde k časovému posunu mezi pakety vlivem jejich řazení ve frontách a směrovačích. [3] Limitní hodnota rozptylu zpoždění je často nastavována na 30 ms. Parametry, které jsme zvolili k měření na generátoru a analyzátoru Optixia XM2, jsou Interarrival Jitter, Delay Variation Jitter a Post Dial Delay. První parametr, Interarrival Jitter, byl vybrán jako parametr skutečného rozptylu, jelikož jeho význam odpovídá definicím rozptylu zpoždění. Během sestavování testovacích souborů jsme hledali další vhodné parametry pro měření. Při generování hovorů docházelo k nízkému zatížení virtuálních strojů, kdy při SIP provozu s hlasovou relací bez transkódování, docházelo pouze k 30-45% zatížení virtuálního stroje, kde při takovém zatížení byly veškeré měřené parametry hluboko pod mezními hodnotami. Vlivem nízkého zatížení virtuálního stroje a také vlivem nedostatečného počtu UDP socketů jsme přistoupili k transkódování hovorů, které způsobí podstatně vyšší zatížení testovaného stroje. Transkódování bylo prováděno mezi kodeky G.711 a G.726. Další předpokládaný parametr, One Way Delay, jsme proto mohli vyloučit, jelikož při transkódování dochází na straně Asterisku ke změně obsahu RTP paketu (RTP payload). Tento parametr lze ale částečně měřit pomocí parametru Delay Variation Jitter, jenž představuje zpoždění mezi endpointem inicializující hovor a zařízením, na kterém běží komunikační server. Poslední zvolený parametr, je Post Dial Delay, který má velmi podobný průběh, jako zbylé parametry zpoždění, které jsou měřené na SIPu (Media Delay a Post Pickup Delay).

3.3 Konfigurace scénáře real-time testu Konfigurace testovacího scénáře je procedura, která spočívá v nastavení síťových parametrů a testovaných parametrů v řídícím software IxLoad. Testovací soubory popisují průběh a vlastnosti testu, který bude aplikován na měřené zařízení s využitím testovacích portů generátoru Optixia XM2. Testovací soubory se skládají z konfigurace a ze scénáře. Konfigurace slouží k nastavení jednotlivých parametrů testů a popisuje vlastnosti testu. Dá se rozdělit na tři části, a to na část s globálními parametry, na část se síťovými parametry a na část aktivity, jež je vybraná k testování. Testovací scénář proto bude mít fixní část, jež má všechny parametry stejné pro všechny testy a variabilní část, která je určena pro vybranou aktivitu. Aktivity lze i vzájemně kombinovat a tak i testovat více parametrů za běhu jedné iterace generování a měření generátoru Optixia. Testovací scénář popisuje jednotlivé fáze testu. Sestavení takového scénáře je realizované pomocí jednoduchých primitiv, které připomínají grafické strukturované programovací jazyky. Scénář použitý v měření virtuálních strojů je velmi jednoduchý. Obě strany mají stejný počet procedur, které jsou vzájemně synchronizovány, takže veškerý postup UAC scénářem je postupný a nemůže dojít k případům, kdy registrovaný generovaný UAC bude volat na neregistrovaný UAC. Počátek měření začíná procedurou start, která volá následující proceduru MakeRegistration. Jakmile dojde k registraci obou stran, tak následuje procedura vytvoření a přijetí hovoru (SIP MakeCall Authentication a SIP ReceiveCall Authentication), kde dojde k inicializaci hovoru. Po potvrzení volající strany proběhne RTP relace a po ukončení této relace hovor končí. Průběh testu aplikací testovacího scénáře, který je realizován aplikací IxLoad, zobrazuje obr. 2 pomocí SIP zpráv.

Obr. 2 : Průběh SIP zpráv v testovacím scénáři v kontextu logické topologie testovacího scénáře. 3.4 Aplikace scénáře real-time testu Po přípravě testovacího souboru, scénáře a konfiguraci komunikačního serveru Asterisk, lze začít testovat zpoždění a rozptyl zpoždění. Před začátkem testování bylo nutné definovat variabilní parametry virtuálních strojů, které budou měněny v průběhu testování, přičemž parametry testovacího souboru a scénáře zůstanou shodné. Jako variabilní parametry jsme sta-

5–3


2012/5 – 16. 1. 2012 novili velikost operační paměti, počet jader procesoru a použitý virtualizér. Měli jsme v úmyslu testovat také frekvenci procesoru, nicméně virtuální stroje, ačkoliv měly k dispozici procesor o nižší frekvenci, vykazovaly shodný výkon, jako stroje s procesorem o frekvenci maximální. Předtím, než došlo k aplikaci scénáře, bylo zapotřebí definovat metodiku, kterou budeme měřit. Bylo nutné přihlížet na mezní kritéria, které byly definány v 3.2, kde je za kritickou hodnotu zpoždění bráno 150 ms a rozptyl zpoždění 30 ms. Specifickou vlastností testu je fakt, že se při něm provádí transkódování na komunikačním serveru mezi kodeky volajícího a volaného UA. Transkódování způsobí, že nemůže dojít k vyhodnocení end-to-end rozptylu RTP zpoždění a celkového RTP zpoždění, a proto jej můžeme vyhodnotit pouze mezi volajícím UA a komunikačním serverem. Průběh scénáře má postupnou, rostoucí zátěž, při níž dochází k RTP a SIP provozu, jehož vlastností ale není předpokládaná linearita při lineárně rostoucí zátěží. Komunikační server Asterisk má tu vlastnost, že s lineárně rostoucí zátěží mu neroste lineárně zpoždění a rozptyl zpoždění. Asterisk reaguje na rostoucí zátěž tak, že po překročení určité hranice zátěže dojde skokově ke zvýšení hodnoty zpoždění a také rozptylu zpoždění. Jestliže Asterisk narazí na výkonnostní limity počítače, na němž je umístěn, začne docházet k odmítání registrací a k prvním neúspěšným hovorům. Obecná metodika, kterou jsme používali pro měření komunikačního serveru, spočívala v několika krocích: 1. Nastavíme parametry virtuálního stroje tak, aby nebyly omezujícími, a zároveň tak, aby byly nastaveny rovné podmínky mezi virtuálními stroji (shodné ovladače, velikost operační paměti i počet virtuálních procesorů) 2. Nastavíme parametry scénáře tak, abychom zjistili horní limit virtuálních strojů. Během testování pozorně sledujeme hodnoty zpoždění a rozptylu zpoždění. Pokud dojde k překročení mezních limitů, test zastavíme a nalezneme takový počet hovorů, při němž nedochází k překročení této hranice. Zároveň nesmí dojít k selhání registrace UAC. 3. Upravíme počet kanálů v testovacím souboru podle počtu hovorů, při nichž nedochází k překročení mezní hodnoty a test spustíme. 4. Výsledkem testu jsou CSV soubory umístěné ve výstupním adresáři IxLoad, který je umístěný v domovském adresáři uživatele, pod kterým IxLoad běží. 5. Takto nastavený scénář použijeme na testování dalších virtuálních strojů se shodně nastaveným počtem virtuálních procesorů. Jediným variabilním parametrem je velikost operační paměti. 6. Jakmile dotestujeme všechny virtualizéry s určitým počtem virtuálních procesorů a všemi kombinacemi velikostí paměti, nastavíme nižší počet virtuálních procesorů a měření opakujeme znovu od bodu 2. Následující tabulka ukazuje dimenzovanou zátěž, jež byla stanovena dle nejvýkonnějšího virtualizéru, který splňoval mezní podmínky, tj. rozptyl zpoždění do 30 ms a zpoždění do 150 ms.

Tab. 1 : Závislost počtu aktivních hovorů na počtu virtuálních procesorových jader. Počet procesorových jader

Počet aktivních hovorů

1

280

2

440

3

600

4

680

Aplikací scénáře, jehož obsah jsme definovali v aplikaci IxLoad, se vygenerují datové soubory, které popisují měřené parametry testu a aktivity. Pro každou zvolenou aktivitu se generují specifické datové soubory ve formátu CSV, jejichž parametry jsou závislé na zvolené aktivitě. Mimo tyto soubory se generují do adresáře s výsledky také kopie testovacího souboru a scénáře, společně se statistikami jednotlivých generujících portů. Měřené parametry nalezneme v souboru VoIP_Peer.csv, z něhož extrahuji měřená data, a následně je zpracuji tak, abych je mohl analyzovat v aplikaci Stagraphics Centurion XV. Nutno podotknout, že vlivem pádu některých portů při testování fyzického stroje nebylo možné naměřit žádná data, přičemž testování virtuálních strojů proběhlo bez problému. Po neúspěšných opakováních testování jsme vyloučili měření fyzického stroje z testování, a proto budeme pouze srovnávat virtuální stroje vzájemně mezi sebou.

4 Výsledky Datové soubory obsahující zdrojová data tvořily základ statistického vyhodnocení. Celý postup spočíval ve vyhodnocení explorační analýzy jednotlivých parametrů, dále pak v ověření předpokladů ANOVA testu, což je ověření nezávislosti výběrů, normalitu výběru a ověření homoskedasticity. Realizace vyhodnocení byla provedena pomocí programu Statgraphics Centurion XV. Rozptyl zpoždění je reprezentován parametrem Interarrival Jitter. 4.1 Klasifikace dle výkonnosti virtualizéru Tato klasifikace popisuje vlastnosti datového výběru, který je sestaven z třech proměnných, které reprezentují jednotlivé virtualizéry, a to z proměnných KVM, VirtualBox a VMware Player. Graf, který zobrazuje krabicové grafy proměnných (KVM, VirtualBox a VMware) parametru Delay Variation Jitter v závislosti na použitém virtualizéru neobsahuje extrémně odlehlá pozorování (v grafu zobrazeny jako červené body, odlehlá pozorování jsou pak zobrazena jako modré body) u proměnných KVM a VMware. Rozsah hodnot je u první sledované proměnné velmi úzký, a proto nemůžeme porovnat rozptýlenost datového souboru. Hodnoty druhého sledovaného parametru, VirtualBox, se jeví jako velmi dobře rozptýlené v celém svém datovém rozsahu. U VMware se kvůli vysokému počtu extrémně odlehlých pozorování jeví průměrná hodnota jako odlehlé pozorování.

5–4


2012/5 – 16. 1. 2012 4.3 Klasifikace dle velikosti operační paměti Tato klasifikace popisuje vlastnosti datového výběru, který je sestaven z čtyř proměnných, které reprezentují velikosti paměti, a to z proměnných 512 MB, 1 GB, 2 GB a 4 GB.

Obr. 3 : Interarrival jitter v závislosti na použitém virtualizéru. 4.2 Klasifikace dle počtu jader procesoru Tato klasifikace popisuje vlastnosti datového výběru, který je sestaven z čtyřech proměnných, které reprezentují počet jader procesoru, a to z proměnných 1 jádro, 2 jádra, 3 jádra a 4 jádra. Parametr Interarrival Jitter obsahuje extrémně odlehlá pozorování (červené body). A to u proměnných 2 jádra a 3 jádra. První sledovaná proměnná, 1 jádro, má největší rozsah hodnot a její hodnoty jsou v datovém souboru rovnoměrně rozloženy, což ukazuje pozice průměru a mediánu. Druhá sledovaná proměnná, 2 jádra, již obsahuje extrémně odlehlá pozorování a její hodnoty jsou soustředěny u dolního kvartilu. Největší počet odlehlých pozorování je zaznamenán u proměnné 3 jádra. Většina hodnot této proměnné se nachází v první polovině souboru dat. Rozsah hodnot čtvrté proměnné je velmi úzký, ale i přesto obsahuje extrémně odlehlá pozorování.

Obr. 4 : Interarrival jitter v závislosti na počtu virtuálních CPU.

Obr. 5 : Interarrival jitter v závislosti na velikosti virtuální paměti. Mezi sledovanými proměnnými, které byly stanoveny na 512 MB, 1 GB, 2 GB a 4 GB, docházelo ke shodě průměrů a veškeré rozsahy dat byly přibližně shodné. Všechny parametry real-time komunikace (Delay Variation Jitter a Interarrival Jitter) obsahovaly velký počet extrémně odlehlých pozorování. Parametr SIP zpoždění (Post Dial Delay) obsahoval ve srovnání s parametry real-time komunikace výrazně méně extrémně odlehlých pozorování, nicméně existenci extrémně odlehlých pozorování se tento parametr nevyhnul. Z výsledků jsme proto usoudili, že virtuální stroje jsou paměťově nezávislé.

5 Závěr Postup, jímž bylo provedeno testování, je sestaven tak, aby měřené parametry zpoždění a rozptylu zpoždění byly pod hranicí mezních hodnot, které jsou definovány doporučením ITU G.114 a také praktickými zkušenostmi. Ačkoliv vlastnosti testu neumožňovaly měřit datový provoz závislý na čase (realtime aplikace) mezi zdrojovými a cílovými uživateli kvůli transkódování přenosu, bylo možné srovnat naměřené hodnoty komunikace mezi zdrojovým uživatelem a serverem poskytující služby IP telefonie. Testovací platformou, využitou pro měření zpoždění a rozptylu zpoždění, byl generátor Ixia XM2 s rozšiřujícími moduly, 1Gbps přepínač a počítač, který hostuje virtuální stroje realizované pomocí virtualizačních nástrojů postavených na bázi open-source či bezplatného licencování. Předpokladem pro testy bylo, že KVM bude nejvýkonnějším virtualizérem pro virtuální stroje. Vůči virtuálním strojům běžících na KVM byla dimenzována zátěž, při které byl stanoven maximální počet hovorových kanálů, při nichž dojde ke splnění mezních kritérií. Proti této referenční hodnotě pak byly naměřeny hodnoty při stejném počtu virtuálních procesorů, ale s odlišnou velikostí virtuální paměti a odlišném virtualizéru. Pokud srovnáme datové výběry jednotlivých virtualizérů, je z explorační analýzy zcela evidentní, že původní předpoklad

5–5


2012/5 – 16. 1. 2012 nejvýkonnějšího virtualizéru se ukázal jako správný. Nejnižšího rozsahu dosahuje aplikace KVM. VMware, ačkoliv patří mezi leadery, tak produkt VMware Player nedosahoval tak stabilních výsledků jako KVM. Jako nejméně výhodné se jeví použití virtualizéru VirtualBox, jehož hodnoty byly ve všech měřených parametrech nejhorší. Z výsledků je zřejmé, že virtuální stroje jsou paměťově nezávislé. Jinak je tomu u závislosti na počtech jader procesoru, kdy i přes dimenzování zátěže na větším množství jader dochází k výrazně nižším zpožděním a rozptylům zpoždění.

Poděkování Na tomto místě patří poděkování projektu č. 218086 FP7 EU, který je řešen na Katedře telekomunikační techniky FEI VŠB – Technické univerzity v Ostravě.

Literatura [1] Ixia, IxLoad Online Help, 913-0918 Rev. A, 2011. [2] Ixia, Ixia Hardware and Reference Manual Release, Part No. 913-1116 Rev. A, 2010. [3] VOZŇÁK, Miroslav. Voice over IP. Ostrava: VŠB-TUO, 2008. ISBN 978-80-248-1828-3. [4] Red Hat. Red Hat Enterprise Linux 6 Virtualization Guide : Guide to Virtualization on Red Hat Enterprise Linux 6 [online]. Raleigh(USA) : [s.n.], 2010. [5] Oracle. User Manual. 4.9.2008, 21.4.2011. Chapter 10. Technical background. Dostupné z WWW:
5–6


Virtualizace real-time aplikací

Recommend Documents