Portál AbcLinuxu, 29. března 2024 09:03

Xen vs. KVM: Souboj v extrémních podmínkách

6. 5. 2010 | Jirka Bourek
Články - Xen vs. KVM: Souboj v extrémních podmínkách  

V tomto článku porovnáme dvě FOSS řešení pro virtualizaci v Linuxu – Xen a KVM, podrobíme je zátěžovým testům a zjistíme, jak se s nimi vypořádají a kde narazí na své limity.

Obsah

Krátké představení

link

Virtualizace prožívá za posledních několik let velký rozmach. A aby také ne – velká část aplikací a síťových služeb nevyžaduje ke svému běhu výkon celého fyzického serveru, ale v mnoha případech by bez virtualizace nic „menšího“ k dispozici nebylo. Možnost migrace virtuálních strojů mezi více hostiteli navíc přináší další výhody, mezi něž patří vyrovnávání vytížení hostitelů či možnost běhu virtuálního stroje bez přerušení, i když je hostitele potřeba restartovat třeba kvůli aktualizaci jádra.

Xen logo

Xen

link

Xen vznikal v době, kdy si o hardwarové podpoře virtualizace mohli na architektuře x86 vývojáři nechat jenom zdát, virtuální stroj tedy běží paravirtualizovaně – to znamená, že jádro hosta musí být patřičně upraveno, aby se nepokoušelo používat instrukce, které může použít pouze kód běžící v privilegovaném režimu.

V současnosti není začleněn v jádře s odůvodněním, že je příliš invazivní, znečišťuje kód architektury x86 a případnými regresemi by trpěli všichni uživatelé Linuxu – i ti, kteří o používání Xenu (nebo virtualizace obecně) nemají zájem.

KVM logo

KVM

link

KVM si naopak cestu do hlavní řady našlo poměrně rychle, první verze byla začleněna krátce po začátku vývoje do jádra 2.6.20 (podpora pro procesory AMD byla začleněna o verzi později do 2.6.21). Využívá hardwarovou podporu virtualizace v procesoru hostitelského stroje, jedná se tedy o plnou virtualizaci, která nevyžaduje žádné úpravy hostovaného operačního systému.

(Podrobnější informace přesahují rámec tohoto článku, můžete je najít v mnoha jiných článcích i zde na Abclinuxu.)

Testy a testovací sestava

link

Hardware

link

Pro testovaní byl použit server Intel S5000PAL osazený následujícími komponentami:

Procesor:2× Quad-Core Xeon E5420 (2,5 GHz)
Paměť:4× 4GB FB-DIMM DDR2 (667MHz)
Pevné disky:2× 500GB Seagate (ST3500320NS)
2× 1000GB Seagate (ST31000340NS)

Z disků byla sestavena 2 pole RAID1 (softwarový RAID), na menším poli byl nainstalován hostitelský operační systém a vytvořen swap o velikosti 8 GB. Větší pole sloužilo jako úložiště pro disky virtuálních strojů – nad polem bylo vytvořeno LVM, každý logický svazek sloužil jako disk.

Stroj disponuje dvěma síťovými kartami. První – eth0 – slouží jako rozhraní do fyzické sítě; eth1 byla pomocí bridge spojena se síťovými kartami virtuálních strojů, aby se z hostitele bylo možné pomocí SSH přihlásit na hosty; eth1 nebyla fyzicky připojena nikam.

Za zapůjčení testovacího stroje děkuji společnosti THINline interactive s.r.o, provozovateli Českého hostingu.

Software

link

Jako operační systém byl zvolen Debian Lenny. Xen byl testován na jádře 2.6.26 (balík linux-image-2.6.26-2-xen-amd64), verzi hypervizoru 3.2.1 (balík xen-hypervisor-3.2-1-amd64).

Protože se KVM poměrně rychle vyvíjí, byla použita verze z Debianu Unstable – v té době nejnovější jádro 2.6.31 (balík linux-image-2.6.31-1-amd64) a kvm-85 (85+dfsg-4.1).

Testovány byly dvě výkonnostní varianty virtuálních strojů. První varianta měla k dispozici celé CPU a 2048 MB paměti, druhá měla k dispozici 1/4 CPU a 512 MB paměti (tyto varianty budou v textu nadále podle využitelného času CPU označovány jako 1/1 a 1/4.) Při všech testech bylo hostitelskému systému ponecháno k dispozici jedno jádro CPU, které hosté nesměli využívat.

Co se disků týče, pro každý virtuální stroj byly vytvořeny tři logické svazky, jeden pro systém, jeden pro datový oddíl, na kterém se prováděly testy, a jeden pro swap. Na systémovém oddílu byl použit souborový systém ext3, na datovém xfs.

Kompletní nastavení Xenu je možné vyčíst z konfiguračního souboru:

memory = 2048
maxmem = 2048
name = "virtual1"
cpus= "^0"
vif = ['ip=192.168.150.11,mac=00:00:10:01:23:01,bridge=br0']
disk = ['phy:mapper/obrazy-vsys1,sda,w','phy:mapper/obrazy-vdata1,sdb,w','phy:mapper/obrazy-vswap1_1,sdc,w']
kernel = "/boot/vmlinuz-2.6.26-2-xen-amd64"
ramdisk = "/boot/initrd.img-2.6.26-2-xen-amd64"
root = "/dev/sda1 ro"

KVM se nastavuje parametry předanými na příkazové řádce, každý stroj byl spouštěn takovýmto skriptem:

#!/bin/bash

tunctl -t tap1_01
ip l s tap1_01 up
brctl addif br0 tap1_01

kvm -drive file="/dev/mapper/obrazy-vvsys1",index=0,if=virtio,boot=on -boot c -m 2048 \
 -drive file="/dev/mapper/obrazy-vvdata1",index=1,if=virtio,boot=off \
 -drive file="/dev/mapper/obrazy-vvswap1_1",index=2,if=virtio,boot=off \
 -net nic,vlan=0,macaddr=00:00:10:01:23:01,model=virtio -net tap,vlan=0,ifname=tap1_01,script=no \
 -monitor tcp::44001,server,nowait -vnc :1

ip l s tap1_01 down
brctl delif br0 tap1_01
tunctl -d tap1_01

Poznámka – přestože všechny hostované stroje měly k dispozici swap, žádný ho při testech nevyužil.

U KVM si můžeme všimnout parametru if=virtio u konfigurace disků a síťové karty. Hardwarová podpora virtualizace v CPU se nevztahuje na I/O a práci s hardwarem, takže v nejzákladnějším nastavení by bylo nutné práci disků i síťové karty emulovat (a KVM by tak bylo degradováno na úroveň Qemu). Výše zmíněný parametr proto vytvoří v hostitelském stroji taková zařízení, aby bylo možné použít paravirtualizované ovladače.

Co se týče variant 1/4, je nutné nějakým způsobem omezit využívání CPU daným virtuálním strojem. Xen umožňuje nastavit limity využívání CPU na maximální hodnotu (v našem případě 25&nbs,; %) napevno příkazem

xm sched-credit -d virtual1 -c 25

Virtuální stroj KVM běží v systému jako samostatný proces a v Linuxu není jednoduché spolehlivě omezit využívání procesoru procesem. Z toho důvodu jsou při startu všechny procesy KVM pomocí mechanismu řídících skupin [control groups] omezeny tak, že smí využít pouze tolik procesorů, aby na jeden virtuální stroj připadla čtvrtina výkonu.

Testy

link

Cílem jednotlivých testů bylo nejenom srovnat výkon jednotlivých typů virtualizace, ale – tam, kde to je možné – porovnat s výkonem na fyzickém stroji a zjistit tak výkonnostní úbytek u daného typu virtualizace – při paralelním běhu těchto testů se používá stejná výkonnostní varianta hostů.

U některých testů byl navíc srovnáván i běh obou výkonnostních variant zároveň – v takových případech je zjišťováno, jestli výkonnostní varianta 1/4 opravdu disponuje jenom čtvrtinou výkonu oproti 1/1. (Pevné stanovení výkonu je důležité například v případě, kdy jsou hostované stroje pronajímány zákazníkům, kteří platí podle přiděleného výkonu – tam chceme, aby skutečný podaný výkon odpovídal tomu, co je stanoveno).

Zde je také potřeba předeslat, že většina testů není příliš podobna nějakému reálnému provozu – jedná se o testy syntetické, které v mnoha případech přespříliš vytěžují hostitelský systém. To nám umožňuje zhodnotit i to, jak se jednotlivá virtualizační řešení zachovají v mezní situaci.

Následuje popis jednotlivých testů a dosažené výsledky:

Výkon CPU

link

Výkon CPU byl testován zašifrováním 5 GB nul pomocí openssl, výsledek se zahazoval. Nuly byly šifrovány proto, že je možné je snadno získat čtením z /dev/zero, aniž by bylo třeba jakkoliv zapojit pevný disk. Výsledná zašifrovaná data směřovala do /dev/null:

time dd if=/dev/zero bs=1048576 count=5120 | openssl \
enc -aes-256-cbc -salt "0123456789abcdef" -pass pass:opravduhloupeheslo >/dev/null

Pomocí time se měřila doba, za kterou se daná úloha dokončila.

1. Test s jediným běžícím procesem

link

Testovací proces byl postupně spuštěn na hostiteli, na jednom KVM 1/1 hostu a jednom Xen 1/1 hostu. Ve všech případech byl test třikrát opakován. V tabulce jsou uvedeny minimální, průměrné a maximální doby běhu testovacího procesu. V závorce je uveden nárůst doby běhu na virtuálním stroji oproti hostiteli v procentech.

HostitelKVM 1/1Xen 1/1
minimum47,639 s51,975 s (+9,1 %)50,674 s (+6,3 %)
průměr47,679 s52,025 s (+9,1 %)50,715 s (+6,3 %)
maximum47,705 s52,103 s (+9,2 %)50,785 s (+6,4 %)

2. Sedm paralelně běžících procesů

link

V tomto testu bylo na hostiteli spuštěno sedm testovacích procesů zároveň, doba běhu byla porovnávána s během sedmi testovacích procesů, z nichž každý běžel na jednom testovacím stroji varianty 1/1.

HostitelKVM 1/1Xen 1/1
minimum 47,734 s 51,966 s (+8,9 %) 50,897 s (+6,6 %)
průměr 47,851 s 52,107 s (+8,9 %) 51,068 s (+6,7 %)
maximum 47,925 s 52,209 s (+8,9 %) 51,218 s (+6,9 %)

3. 28 paralelně běžících procesů

link

Tentokrát bylo na hostiteli spuštěno 28 testovacích procesů paralelně (pomocí řídících skupin bylo zajištěno, že tyto procesy mohly využívat pouze 7 jader CPU). Doba běhu je opět porovnávána se stejným počtem testovacích procesů, každý běžel na vlastním testovacím stroji varianty 1/4.

HostitelKVM 1/4Xen 1/4
minimum 2 m 42,412 s 2 m 34,811 s (-4,7 %) 3 m 26,774 s (+27,3 %)
průměr 3 m 0,337 s 3 m 21,183 s (+11,6 %) 3 m 31,076 s (+17,0 %)
maximum 3 m 16,374 s 3 m 33,572 s (+8,7 %) 3 m 33,434 s (+8,7 %)

4. Test na strojích o různém výkonu

link

Celkem bylo paralelně spuštěno 19 testovacích procesů, 16 z nich na hostech 1/4 a tři na hostech 1/1 (na hostiteli byly procesy omezeny pomocí řídících skupin – 16 procesů mělo k dispozici 4 CPU a zbývající tři procesy každý po jednom CPU.

V tomto testu není srovnáván poměr výkonu hostitele a hostů, ale poměr výkonů mezi jednotlivými výkonnostními variantami. V tabulce jsou uvedeny průměrné hodnoty doby běhu testů a poměr doby trvání na jednotlivých výkonnostních variantách.

HostitelKVMXen
1/1 0 m 47,916 s 0 m 52,137 s 0 m 58,980 s
1/4 3 m 10,689 s 3 m 27,366 s 3 m 25,973 s
poměr 3,980 3,977 3,492

Shrnutí

link

Zpracovávání uživatelských úloh náročných na CPU je pro virtualizaci nejméně problematická zátěž, protože většinu kódu je možné spustit nativně a zpracování privilegovaných instrukcí v jádře hostovaného systému zabírá víceméně zanedbatelné množství času.

V případě, že má každá běžící úloha (či host) pro sebe své CPU (test 1 a 2), je výkonnostní ztráta za virtualizaci u obou řešení víceméně rovnocenná a oproti běhu na hostiteli se jedná o jednotky procent; KVM ztrácí za Xenem o dva až tři procentní body. U třetího testu, kdy se úlohy (hosté) musí o CPU střídat, se projevuje fakt, že přepínání procesů (virtuálních strojů) má svou režii. KVM si v porovnání s předchozími testy pohoršuje o dva procentní body a Xen o více než deset procentních bodů (režie za virtualizaci se tedy blíží 20 %)

V testu srovnávajícím poměr výkonu různých variant hostů se ukázalo, že KVM s řídícími skupinami v této zátěži poměrně dobře dodržuje nastavené výkonnostní varianty jednotlivých strojů – od teoretické hodnoty 4 se odchyluje o 0,5 % a od hostitele o necelou desetinu procenta. Xen je na tom hůře, od teoretické hodnoty se odchyluje o celých 12 %.

Úlohy náročné na výpočetní výkon hostitele zjevně nejsou ve virtualizovaném prostředí nijak problematické a víceméně nezáleží na tom, které virtualizační řešení je použito. Lepší výsledky KVM v testu velkého počtu paralelně běžících úloh zde nejsou zcela rozhodující – pokud by na daném hostiteli trvale běželo tolik úloh, lze říci, že je takový hostitel přetížen a že by si situace zasluhovala alespoň jeden stejný hostitelský stroj navíc1.

1 Zde samozřejmě také záleží na způsobu využívání hostitele. Pokud mají jednotlivé stroje administrativně vyhrazeny omezený výkon, „přetížení“ velkým počtem úloh nám nevadí. V takovém případě je nicméně nutné rozhodnout se mezi Xenem, který v takové situaci podává o něco horší výkony, a KVM, které s řídícími skupinami neumožňuje v situaci, kdy na hostiteli téměř nic neběží, omezit přidělený výpočetní výkon na méně než jedno CPU.

CPU + práce s diskem (1)

link

Výkon při využívání těchto systémových prostředků současně byl testován rozbalením zdrojových kódů jádra. Zdrojové kódy byly rozbalovány desetkrát po sobě, každá kopie do samostatného adresáře. Pomocí time bylo měřeno, za jak dlouho se rozbalování dokončí.

1. Test bez paralelní práce

link

Testovací proces byl postupně spuštěn na hostiteli2, na jednom KVM 1/1 hostu a jednom Xen 1/1 hostu. Ve všech případech byl test třikrát opakován.

HostitelKVM 1/1Xen 1/1
minimum 5 m 10,147 s 2 m 50,257 s (-45,1 %) 4 m 54,941 s (-4,9 %)
průměr 5 m 11,105 s 2 m 52,423 s (-44,6 %) 4 m 56,981 s (-4,5 %)
maximum 5 m 12,231 s 2 m 55,511 s (-43,8 %) 4 m 58,776 s (-4,3 %)

2. Sedm paralelně běžících procesů

link

Test byl spuštěn sedmkrát paralelně na hostiteli, na sedmi KVM 1/1 hostech a sedmi Xen 1/1 hostech. Test byl třikrát opakován.

HostitelKVM 1/1Xen 1/1
minimum 26 m 17,560 s 22 m 45,506 s (-13,4 %) 44 m 47,015 s (+70,3 %)
průměr 38 m 43,156 s 71 m 57,967 s (+85,9 %) 50 m 55,523 s (+31,5 %)
maximum 46 m 25,065 s 137 m 40,253 s (+196,6 %) 57 m 53,668 s (+24,7 %)

Shrnutí

link

Práce s diskem je naopak pro virtualizované prostředí poměrně problematická zátěž – většina práce sestává z operací s virtualizovaným hardwarem, které je nutné „přeložit“ pro hardware skutečný – to se v tomto testu také ukázalo. Samotné rozbalování nebylo příliš náročné na CPU a zátěž se tak v podstatě skládala ze zápisů mnoha souborů na disk3.

Poměrně překvapující je proto výsledek virtuálních strojů 1/1, které při samostatném běhu rozbalování zdrojových kódu jádra dosáhly kratšího času než samotný hostitel, KVM dokonce výrazně kratšího. S největší pravděpodobností je to důsledek ukládání zapisovaných dat do paměti se zpožďováním skutečného zápisu na disk.

Při paralelním běhu byl výkon KVM podstatně horší. Zatímco Xen si s paralelním rozbalováním poradil poměrně dobře, testovací běh KVM způsobil velké přetížení hostitelského systému – při vzdálené práci přes SSH byla odezva na stisk klávesy řádově několik vteřin a v dmesg se objevovala hlášení typu

BUG: soft lockup – CPU#0 stuck for 135s! [kswapd0:179]
INFO: task pdflush:1648 blocked for more than 120 seconds.

a podobná. Oproti Xenu také trvalo déle úlohu zpracovat.

Poznámka – zatímco Xen u této úlohy při každém běhu podával víceméně stejné výkony, KVM z nějakého důvodu podávalo při každém běhu různé – při jednom běhu dosáhlo všech sedm hostitelů času okolo půl hodiny, při jiném naopak všem hostům trvalo zpracování stejného testu hodiny dvě. Pokud někoho napadne, čím by to mohlo být způsobeno, nechť dá vědět v diskuzi.

K dobru je zde KVM možné přičíst to, že po dokončení testů se situace vrátila do normálního stavu, s hostitelem i hosty bylo možné normálně pracovat a žádný host nezhavaroval. Také je zde vhodné uvážit, že takováto zátěž, kdyby měla být provozována v produkčním prostředí, by si zasluhovala více než jeden fyzický stroj.

2 Ve všech případech, kdy se na hostiteli testuje úloha využívající souborový systém, je tento souborový systém vytvořen na LVM oddílu. V případě, že na hostiteli běží několik testů paralelně, je na LVM vytvořeno tolik oddílů, kolik úloh běží.

3 To s sebou hlavně při paralelním běhu testovacích úloh navíc přináší nutnost neustále měnit polohu hlaviček disku, což se podepisuje na výkonu i při běhu na hostiteli.

CPU + práce s diskem (2)

link

Tento test byl proveden překladem jádra (výchozí konfigurace pro architekturu amd64). Jádro bylo přeloženo třikrát po sobě, každý překlad ze samostatné kopie zdrojových kódů. Na rozdíl od předchozího testu, který značně vytěžoval hlavně disky, je v tomto případě více využíván procesor a úložiště spíše okrajově.

Měřena byla doba běhu testu, tj. celková doba překladu ze tří kopií zdrojových kódů.

1. Test bez paralelizace

link

Test byl proveden na hostiteli a porovnáván s během na hostu KVM 1/1 a Xen 1/1.

HostitelKVM 1/1Xen 1/1
real 24 m 19,559 s 31 m 33,392 s (+29,7 %) 27 m 6,909 s (+11,5 %)

2. Test sedmi paralelně běžících procesů

link

Na hostiteli byl proveden test sedmi paralelně běžících testovacích procesů, které byly omezeny na používání pouze sedmi CPU v systému. Výsledek byl porovnáván s během na hostech varianty 1/1.

HostitelKVM 1/1Xen 1/1
minimum 30 m 10.0s 34 m 5.1s (+13,0 %) 27 m 56.3s (-7,4 %)
průměr 30 m 20.6s 34 m 59.5s (+15,3 %) 29 m 15.1s (-3,6 %)
maximum 30 m 29.5s 35 m 19.7s (+15,9 %) 29 m 42.6s (-2,6 %)

3. Test 28 paralelně běžících procesů

link

Tento test byl míněn víceméně jako zátěžový, cílem bylo zjistit, jestli nedojde k pádu/zatuhnutí některého z hostů. Na hostiteli se netestovalo, testována byla varianta hostů 1/4.

KVM 1/4Xen 1/4
minimum 136 m 58,057 s 134 m 24,515 s
průměr 140 m 51,606 s 135 m 9,248 s
maximum 143 m 32,285 s 136 m 6,894 s

4. Test na strojích o různém výkonu

link

Obdobně jako u podobného testu využívání CPU bylo spuštěno 19 testovacích procesů, z toho 16 na hostech 1/4 a 3 na hostech 1/1. Opět bylo cílem zjistit, jak dobře dokáží jednotlivá virtualizační řešení zajistit rozdíly ve výkonu, když je požadujeme.

KVMXen
1/1 36 m 52,858 s 34 m 17,063 s
1/4 131 m 26,102 s 121 m 8,294 s
poměr 3.563 3.533

Shrnutí

link

V tomto testu při všech variantách vytížení podává KVM horší výkony než Xen – práce s diskem je zde sice okrajová, ale i tak dostatečně významná na to, aby výkon KVM utrpěl. Nejvýraznější rozdíl je u testu bez paralelizace, nejméně výrazný u velkého počtu naráz běžících překladů.

Poměrně překvapivý je výsledek Xenu při běhu sedmi překladů paralelně, kde byli hosté rychlejší než hostitel.

Při testu izolace mezi různými výkonnostními variantami se projevilo to, že Linux víceméně nemá žádný způsob4, jak dobře omezovat nebo dělit přístup k disku; omezování využívání CPU využívání disků přímo neovlivňuje. Xen si v tomto případě víceméně udržel svůj výsledek z minulého testu, KVM si pohoršilo a dostalo se na úroveň Xenu.

Test, který byl míněn jako zátěžový, hosté bez problémů zvládli.

4 V jádře 2.6.33 se objevila první vlaštovka, ale zatím se jedná pouze o první krok z mnoha.

Práce s diskem

link

Čistá práce s diskem byla testována zápisem velkého souboru pomocí dd:

dd if=/dev/zero of=soubor.bin bs=1048576 count=16384

Testována byla doba běhu testu (a tím rychlost zápisu na disk).

1. Test bez paralelizace

link

Na hostiteli se v tomto testu zapisoval soubor o velikosti 112 GB, aby se omezil vliv diskové cache. Zápis na hostiteli trval 1438,360 s, což dělá 79,74 MB/s. Výsledky hostů (průměrné hodnoty ze tří běhů) jsou uvedeny v tabulce:

KVM 1/1 Xen 1/1
průměr 273,366 s (59,93 MB/s) 207,862 s (78,82 MB/s)
odchylka -24,8 % -1,2 %

(Minimální a maximální doba běhu se u KVM od průměru lišila o 1 sekundu, u Xenu to bylo 5 vteřin.)

2. Sedm paralelně běžících procesů

link

Na hostiteli se tentokrát zapisovalo sedm souborů o velikosti 16 GB, každý z nich na samostatný souborový systém o velikosti 20 GB.

Hostitel KVM 1/1 Xen 1/1
minimum 1347,32 s (12,16 MB/s) 10039.80s (1,63 MB/s … -86,6 %) 2838,39 s (5,77 MB/s … -52,5 %)
průměr 1266,38 s (12,94 MB/s) 9495,70 s (1,73 MB/s … -86,7 %) 2693,75 s (6,08 MB/s … -53,0 %)
maximum 1177,20 s (13,92 MB/s) 8252,03 s (1,99 MB/s … -85,7 %) 2534,50 s (6,46 MB/s … -53,6 %)

Shrnutí

link

Ani v těchto testech si KVM nevedlo příliš dobře. Přestože je disk zpřístupněn pomocí paravirtualizovaného ovladače virtio, je vidět výrazný propad jak proti hostiteli, tak proti Xenu. Při testu s paralelním během byl hostitel přetížen podobným způsobem jako při rozbalování zdrojových kódů jádra, i když v menší míře.

Při běhu bez paralelních přístupů k disku dosahuje Xen téměř stejného výkonu, jako hostitel. Režie spojená s během KVM byla cca 25 %. Běh s paralelním přístupem ukázal podstatně horší výsledky: Xen si pohoršil na 50 % výkonu hostitele a KVM se propadlo na necelých 15 %.

Bez souběžného přístupu je podávaný výkon KVM tolerovatelný, ale pokles při paralelním běhu je v podstatě za hranicí použitelnosti systému, což v tomto případě platí nejenom pro KVM, ale i pro Xen. Na druhou stranu i zde platí, že tato zátěž by si zasloužila více než jeden hostitelský stroj.

Práce se sítí

link

Práce se sítí byla testována nástrojem netperf (verze 2.4.4-5 z repozitáře Debianu). Provedeny byly testy počtu transakcí, které je možné uskutečnit mezi dvěma stroji (test TCP_CRR, výsledkem je počet transakcí za sekundu), a test propustnosti mezi těmito hosty (test TCP_STREAM, výsledek je udán v milionech bitů za sekundu). Všechny testy byly pětkrát opakovány.

ssh 192.168.150.1$a "sleep 1 ; netperf -t TCP_CRR -H 192.168.150.1$((a+1))" &

Test začíná vteřinovým čekáním, aby se hostitel stihl připojit na testované hosty bez čekání a tedy aby se všechny testy spustily pokud možno naráz. Za a je ve for cyklu dosazováno podle počtu testovaných strojů.

1. Tři paralelně běžící testy

link

Test proběhl na šesti 1/1 hostech, testovalo se v párech, tzn. první host se připojoval na druhý, třetí host na čtvrtý atd.

TCP_CRR KVM 1/1 Xen 1/1
minimum 662,1 391,7
průměr 680,6 2703,3
maximum 693,5 3943,9
TCP_STREAM KVM 1/1 Xen 1/1
minimum 834,46 1,9
průměr 979,55 2082,0
maximum 1060,14 5362,8

2. Test na různých variantách hostů

link

V tomto případě byl testován jeden pár hostů 1/1 proti 8 párům 1/4.

TCP_CRR KVM 1/1 Xen 1/1 KVM 1/4 Xen 1/4
minimum 693,6 50,1 577,6 68,9
průměr 701,7 60,3 604,7 1078,8
maximum 704,4 69,3 655,2 1600,5
TCP_STREAM KVM 1/1 Xen 1/1 KVM 1/4 Xen 1/4
minimum 958,0 1,27 183,9 17,91
průměr 1030,0 16,89 200,2 794,86
maximum 1085,2 47,52 231,1 1507,61

Shrnutí

link

I přes čísla v tabulkách, kde Xen zdánlivě dosahuje lepších výsledků, se nedá říct, že by na tom v těchto testech byl lépe, a to z následujících důvodů:

Naproti tomu KVM podávalo bez problémů vcelku stabilní výkony – minimální ani maximální hodnoty se příliš neodchylují od průměru. Počet transakcí byl víceméně rovnocenný bez ohledu na výkonnostní variantu, poměr objemu přenesených dat byl 1:55.

Jako v předchozích případech je samozřejmě potřeba mít na paměti to, že taková zátěž je v reálném provozu vcelku nepravděpodobná.

5 Využívání sítě hosty nebylo v těchto testech nijak explicitně omezováno, poměr objemu přenesených dat blížící se hodnotě 1:4 je pravděpodobně důsledkem toho, že rychlejší datové přenosy hosté nestíhali kvůli omezení času CPU.

Co se netestovalo a další srovnání

link

Práce s pamětí

link

Práce s pamětí nebyla měřena žádným benchmarkem, můžeme nicméně srovnat, jak obě virtualizační technologie s pamětí pracují a jaké z toho pro ně plynou výhody a nevýhody. Částečně se přitom zaměříme i na to, jak dostupné mechanismy umožňují přidělit hostům více paměti, než má hostitel.

K čemu je to dobré? Málokdy se stane, že by všichni hosté najednou potřebovali využít všechnu paměť, která je jim přidělena. Rozdáním většího množství paměti je tedy možné hostitele využít intenzivněji, aniž by tím výrazně utrpěl výkon.

Poměrně často používaná technologie je „balónový ovladač“, který zabere paměť v hostovi tak, aby ji nebylo možné použít; tuto paměť je poté možné vrátit hostiteli k využití jinde. Jak KVM, tak Xen (a další) tento mechanismus využívají. Je nicméně potřeba brát v potaz, že tento mechanismus vyžaduje spolupráci hosta, který musí danou paměť nějak uvolnit, když je to po něm požadováno.

S tím souvisí i fakt, že přinejmenším u KVM je tento ovladač (virtio_balloon) zcela obyčejný ovladač6, je ho tedy možné vyjmout z jádra, pokud se k tomu správce hosta rozhodne. Uvolňování paměti tímto způsobem tedy není příliš spolehlivé.

V jádře 2.6.32 se objevila technologie KSM, což je mechanismus, který periodicky prochází fyzickou paměť hostitele (a tedy i hostů) a hledá identické stránky. Tyto stránky následně sloučí – ve fyzické paměti nechá pouze jednu kopii, paměť zbylých kopií je uvolněna k použití jinde.

KVM tuto technologii přijalo poměrně rychle, prakticky ihned po vydání jádra 2.6.32 (od 2.6.33 je možné sloučené stránky odswapovat), ve kterém se KSM objevilo poprvé. Xen od verze 4.0 umožňuje něco podobného (nedohledal jsem, jestli používá nějak upravené KSM nebo svůj vlastní mechanismus). Od verze 4.0 Xen také umí využít mechanismus přechodné paměti, který ještě nebyl začleněn do hlavní řady jádra a KVM jej nepoužívá.

Velmi důležitý rozdíl je ale ve způsobu, jak oba virtualizační mechanismy pracují s pamětí hostitele a jak ji přidělují hostům. Xen mapuje paměťové stránky hostů přímo do hardwarových tabulek stránek hostitele – neumožňuje tedy systému správy paměti v hostiteli s těmito stránkami nijak pracovat, což mimo jiné znamená, že tyto stránky nelze odswapovat.

Virtuální stroj KVM z pohledu operačního systému vypadá jako běžný (téměř) proces – jeho paměť tedy lze odswapovat – záležitosti s tím spojené řeší mechanismus stínových stránek nebo hardwarová podpora přímo v CPU. To určuje i způsob, jak je možné na hostech nasadit nejčastěji praktikovanou metodu využívání více paměti, než je fyzicky k dispozici – swapování. Zatímco u KVM je možné prostě hostům přidělit více paměti a žádný swap (swapování vyřeší hostitel), u Xenu je nutné dát každému hostovi k dispozici jeho vlastní swap, což je méně flexibilní a navíc to vytlačuje víc práce s diskem směrem k hostovi.

Lze tedy říci, že KVM je na tom díky spolupráci se správou paměti hostitele v mezních situacích o něco lépe. Prakticky se to ale může projevit jenom v případě, že je hostům přiděleno více fyzické paměti, než má hostitel k dispozici. Pokud se ji všichni hosté pokusí využít zároveň, všechny výše zmíněné mechanismy pravděpodobně selžou – v takovém případě KVM začne swapovat, kdežto Xen (pokud si dobře pamatuji) zastaví některý z virtuálních strojů.

6 Například pro VMware platí to samé.

Práce s diskem pomocí iozone

link

Iozone je nástroj pro benchmarkování souborového systému (a v podstatě tedy i hardwaru pod ním, pokud je souborový systém stejný). V nejjednodušším volání (iozone -a) provádí několik typů testů (zápis, přepis, čtení, náhodné čtení, …) na různě velkých datových souborech (od 64 kB do 512 MB) s různě velkými záznamy (od 4 kB po 16 MB). Výstupem je objem dat za sekundu, který lze daným způsobem zpracovat.

Původně se výsledky tohoto testu měly objevit mezi benchmarky výše, ale při paralelním běhu se v naměřených datech objevily nesrovnalosti: Xen podle průměrných hodnot podal lepší výkon než KVM (ztráta oproti hostiteli 20 %, KVM mělo cca 40 %), nicméně na všech virtuálních strojích KVM testy doběhly do cca 10 minut, kdežto na virtuálních strojích pod Xenem běh trval tři hodiny. Zjištěná data by tedy bylo nutné dodatečně upravovat a vypovídací hodnota takových výsledků by pravděpodobně nebyla nijak velká.

Při běhu na jednom hostu KVM podalo o cca 20 % větší výkon než hostitel (pravděpodobně vliv cache), Xen o 4 % horší.

Závěr

link

Jak je vidět, z těchto měření nelze nijak dobře vyvozovat, které z virtualizačních řešení je lepší. Za normálního provozu je výkonnost srovnatelná a pokud hostitele přetížíme, je přetížen bez ohledu na to, jak virtualizujeme.

Před vydáním Xenu 4.0 bylo KVM trochu ve výhodě, co se vlastností týče, nyní je situace víceméně vyrovnaná. Při rozhodování, které řešení nasadit, je nicméně zapotřebí brát v potaz i to, že KVM začleněné v hlavní řadě jádra rychle přijímá nové vlastnosti (z nichž většina zlepšuje výkon). Uživatelé Xenu musí čekat na to, až vyjde verze pro novější jádro.

Tato lepší spolupráce s hlavní řadou jádra společně s faktem, že za KVM se postavil Red Hat, jsou důvody, proč mnoho vývojářů věří, že KVM nakonec nad Xenem zvítězí jak co se výkonnosti, tak co se počtu nasazení týče.

Související články

Xen - základy virtualizácie
Xen – představení, historie, budoucnost
Seriál: Virtualizace na úrovni jádra

Další články z této rubriky

Úvod do Dockeru (1)
Paralelizace běžných činností v konzoli pomocí GNU Parallel
Unixové nástroje – 26 (triky pro práci v Bashi)
Unixové nástroje – 25 ((s,c)fdisk, gdisk, parted a findmnt)
Linux: systémové volání splice()

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.