Xen vs. KVM: Práce se sítí (a závěr)

24. 8. 2010 | Jirka Bourek | Systém | 30295×

Práce se sítí

Práce se sítí byla testována nástrojem netperf (verze 2.4.4-5 z repozitáře Debianu). Provedeny byly test 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 5 ; netperf -t TCP_CRR -H 192.168.150.1$((a+1))" &

Test začíná pětivteř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

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	618,10	0,00
průměr	631,59	1007,48
maximum	649,20	2204,25

TCP_STREAM	KVM 1/1	Xen 1/1
minimum	831,58	1265,56
průměr	919,37	1357,36
maximum	988,27	1470,03

2. 14 paralelně běžících testů

Test proběhl na 28 hostech 1/4, testovalo se v párech.

TCP_CRR	KVM 1/4	Xen 1/4
minimum	453,89	3,20
průměr	585,68	451,67
maximum	681,80	500,49

TCP_STREAM	KVM 1/4	Xen 1/4
minimum	132,65	158,78
průměr	155,69	182,67
maximum	262,21	227,39

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

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	710,70	825,38	627,69	655,49
průměr	717,86	833,31	656,36	714,75
maximum	725,50	839,48	682,70	768,58

TCP_STREAM	KVM 1/1	Xen 1/1	KVM 1/4	Xen 1/4
minimum	796,81	339,10	104,59	67,68
průměr	850,83	479,00	157,95	284,11
maximum	997,91	864,74	292,01	397,37

Shrnutí

V minulém testu byla práce se sítí jednou slabinou Xenu oproti KVM. V nové verzi některé z problémů zmizely:

• Test TCP_STREAM na Xenu nevytěžoval fyzickou síťovou kartu eth0.

• Žádný host nespadl během testu.

• Silnější varianta hosta již dosahuje i vyšší přenosové rychlosti.

Na druhou stranu u testu TCP_CRR byly výsledky Xenu stále špatné – během až tří z pěti opakování testu přestala na hostech dočasně fungovat síť – buď se k nim nebylo ani možné připojit přes SSH, nebo se netperf nedokázal připojit na svůj testovaný protějšek. (Při výpočtech hodnot uvedených v tabulkách nebyly tyto případy započítány.)

KVM podalo přibližně stejné výkony jako při minulém testu, pouze se o něco snížil objem přenesených dat.

Závěr

Během uplynulého roku KVM učinilo značný pokrok. Nejvážnější výkonnostní problémy zmizely a výkonnost hostů se téměř ve všech ohledech zlepšila. Nová verze Xenu 4.0 si naopak pohoršila oproti starší 3.2 testované loni. Zde by bylo možné namítnout, že použitá verze 4.0.1~rc3 je verze vývojová, nicméně v rámci stabilní řady 4.0 nelze očekávat, že by se výkonnost mezi 4.0.1~rc a 4.0.1 nějak významně měnila.

KVM se tedy během roku dokázalo vypořádat se svými slabinami a stalo se tak zdatným konkurentem Xenu i v těch oblastech, kde měl Xen donedávna navrch.

       

Komentáře

[VSi]

Výborně zpracovaný článek s hodnotnými informacemi, ať už jde o výsledky nebo samotnou metodiku testů.

Vývoj KVM směrem k lepším výsledkům je očekávaný, zlášť po jeho "adopci" u Red Hatu. U XENu bych ale upozornil na problematické srovnání s předchozím testem. Použité Xen dom0 jádro 2.6.32 využívá tzv. pv-ops, což je zjednodušeně snaha více integrovat Xen s jádrem, což byl v minulosti u Xenu dost problém.

Xen pak funguje interně podstatně jinak než u jader 2.6.18, 2.6.26, nebo "aktuálního" 2.6.27. Pv-ops pro Xen dom0 je relativně nová věc, která není považována za zcela stabilní. O vlivu na výkon jsem se nic nedočetl. Stálo by tedy za vyzkoušení (minimálně v těch testech s největším propadem výkonu) použít např. 2.6.27 ze zdrojů Xen Cloud Platform, což je to samé jádro, které používá "nejvíc enterprise Xen" - Citrix XenServer. Navíc dom0 jádro a userland se doporučuje mít 32bit, což nemá vliv na možnost přidělení paměti na 4GB pro guesty, ale nemělo by to mít vliv ani na výkon, spíš na stabilitu.

Pravděpodobně si takové srovnání udělám, takže alespoň využiju metodiku popsanou v článku.

[kyytaM]

Osobne som pri pvops jadrach zaznamenal tiez vykonove regresie, bolo to ale uz nejaky pol rok dozadu. Old-school Xen jadra su vdaka forwad-portovaniu dostupne aj vo verziach napr. 2.6.34, takze moze to byt tiez pekny test.

Druha vec je, ze Xen 4.0 priniesol mnoho noviniek, ale vela veci z noviniek nefungovalo vobec alebo nefungovalo tak, ako malo. Myslim, ze tento tyzden by mala vyjst verzia 4.0.1 s peknou nadielkou oprav (rc6 je zatial). :)

[...]

Ta "adopce" nemusi priamo suvisiet s narastom vykonu, na Xen-e pracovali X rokov od zaciatku a teraz to vyzera ako slepa ulicka, ktorej sa chcu zbavit.

[VSi]

Předpokládal jsem, že když v Red Hatu před nějakou dobou KVM přijali a teď to prodávají jako produkční věc, tak že na něm za tu dobu něco udělali. Ale přesně jsem to nezkoumal.

Xen jednu dobu skutečně vypadal, že bude mít špatnou budoucnost. Zvlášť relativně nedávno, kdy se pro dobré výsledky stále muselo používat jádro 2.6.18. Byly obavy po převzetí společností Citrix. Přijde mi ale, že teď už to tak špatně nevypadá. Citrix vyvíjí Xen a nové management API otevřeně, přechod na pv_ops by měl zajistit provoz i s vanilla jádrem.

[Dadam]

Protože bych rád aktuální informace, zeptám se tady: můžu Xen použít jako náhradu za VirtualBox, nebo je určený pro jiný typ nasazení (třeba na serveru)?

[kyytaM]

Na desktopovu virtualizaciu je Xen dost tazkopadne riesenie, ktore prinesie vo vacsine pripadov viac skody aka uzitku. KVM je vdaka standardnemu kernelu o nieco vhodnejsie.

[vaslaV]

Sel bych do KVM - preci jen se zda, ze ma lepsi budoucnost.

[Dadam]

OK, děkuju vám oběma za odpověď

[Let_Me_Be]

Hmm, sakra a to jsem si rikal ze bych ty dualboot Windows (co jsem nedavno nainstalovat kvuli hram) mohl nahodit do Xenu a dedikovat jim grafiku... no jeste si budu muset nejaky ten rok pockat.

Kazdopadne super clanek.

[ha]

XEN ve verzi 4 má jednu velkou výhodu a to živou synchronizaci hostů na více fyzických hostitelích. Nevíte někdo, jak je na tom KVM (Kemari, ...)?

[melkors]

Funguje

[Heron]

Migrace v KVM funguje.

[ha]

Nemám na mysli migraci, ale fault tolerant synchronizaci - že na 2 fyzicky oddělených hostitelích běží identický systém a v případě výpadku jednoho převezme roli ten druhý. Dřív jsem četl o Kemari, je už součástí KVM nebo se musí pořád patchovat? Je stabilní? Jaký je výkon oproti živé synchronizaci v XEN 4?

[VSi]

Tohle podle mě absolutně není možné bez silné podpory OS nebo aplikací. Nějaký odkaz by nebyl?

Běžná je fault-tolerance ve smyslu sdíleného nebo replikovaného datového úložiště, kde při pádu hostitele musí všechny VM znovu nabootovat na jiném hostiteli.

Na popsanou funkcionalitu by bylo potřeba synchronně replikovat paměť (a možná i CPU cache), na což neexistuje dostatečně rychlé rozhraní (neuvažujeme-li speciální věci jako SGI NUMAlink). Rozhodně běžný systém nemůže najednou běžet na 2 různých strojích ve fault-tolerant režimu. Instrukce nějakého programu např. vykonává 1 procesor v nějakém stroji. Ten stroj spadne, takže se přijde minimálně o obsah CPU registrů a CPU cache - jak by se z toho měl OS vzpamatovat, aby to nebylo poznat? Leda by se vrátil na nějaký kompletní snapshot (teoreticky třeba jen několik ms starý), což zase zavání např. ztrátou potvrzených transakcí v databázi.

Podobnou funkcionalitu má OpenVMS, ale i tam s tím podle mě musí aplikace počítat. Stejně tak IBM Parallel Sysplex. Reálně se tyhle věci řeší na aplikační úrovni, viz např. Oracle Real Application Cluster.

[ha]

http://wiki.xensource.com/xenwiki/Xen4.0 "Remus Fault Tolerance".

[VSi]

Díky. Zajímavé. Takže je to periodická (asynchronní) synchronizace kompletního stavu, kdy se vždy na okamžik musí zastavit virtuální CPU, udělat snapshot, a pak ho spustit a přenést snapshot na druhý systém. Podstata je v tom, že veškeré externí I/O jako síť je bufferované podle dokončení té synchronizace.

I při použití Infinibandu nebo 10GbE to nebude nic pro velkou zátěž, protože by to mělo nechutné latence. Možná pokud by existoval HW na propojení 2 (nebo víc) strojů na úrovni PCIe linek, by to bylo použitelnější. Ale pro určitou oblast použití, kde o výkonnost až tak nejde, je to skutečně zajímavé. Pokud to půjde omezit jen na replikaci disku ve stylu DRBD, která díky integraci přímo do Xenu bude efektivnější, bude oblast použití větší. Každopádně do produkční kvality to má podle mě ještě pár let vývoje a testování.

[vaslaV]

Loadbalancing—Automaticallyloadbalancevirtual desktops across available hosts to ensure optimal performance

http://www.redhat.com/virtualization/rhev/desktop/

Vzhledem k tomu, ze se ma zanedlouho ukazat RHEL6, zrejme se dockame take novinek u RHEV.

btw: on i slavny RAC ma sve mouchy (za urcitych okolnosti se umi pekne pokakat).

[chsajarsa]

Fault-tolerance ma i VMware. Vim,ze tam to delaji tak, ze kazdy VM potrebuje dedikovanou sitovku po ktere bezi kopie pameti. Maji tam nejaka pocitadla a je u toho stroje tolerovano urcite zpozdeni. Zkousel jsem to v praxi a funguje to docela obstojne. Ma to. ale jedno neprijemne omezeni, protoze to umoznuje, aby VM melo jen jedno CPU. Na VMwordu,ale ukazovali,ze takhle umeji chranit i konkretni aplikace (nejaka DB myslim Oracle tam byl) a fungovalo jim to i pro vice CPU. Duvod proc to nenasadili jsou patenty,ale pry uz to maji pripravene pustit to do produkce.

[..... Izak .....]

Ano, jinak to omezeni na 1 CPU neni fyzicky problem v bete to tam slo i na vice CPU ... je to licencni problem, nebot M$ podal zalobu na vmware a chce, aby se platila licence 2x (neb to bezi na 2 strojich) ... vmware ale tvrdi ze kdyz ji tam nelze vubec 2x zadat a ze je to jen jedna kopie a ze na 2 stroji v soucasnosti nebezi, nebot se na ni neni mozno pripojit ... takze az rozhodne soud, bude vice CPU a ukaze se, zda se bude, nebo nebude platit 2x M$ za licence vcetne programu ... ono totiz tohle kompletne zborilo jejich clustery ... neb je to levnejsi

[jura321]

Super článek, podrobný, odborný, aktuální a se zajímavou problematikou, která dnes táhne. Palec nahoru autorovi, jen více článků... jura321 PS. Uvítal bych i články pro méně zkušené, tj. např. instalace a konfigurace KVM na desktopu, vytváření sítě v kvm atd..

[pet]

http://en.gentoo-wiki.com/wiki/KVM

Je to pro gentoo a je to v anglictine, ale je to polopatisticky.

[Grunt]

man qemu. KVM je teď sice hodně populární, ale jinak to není nic jiného než staré dobré Qemu.

[..... Izak .....]

tak to je hezky blabol ))

Z qemu to vyuziva jen definici virtualniho PC ... stejne jako Xen ) ... ale virtualizace jiz probiha uplne jinak )

[Grunt]

Aha. Takže když napíšu man kvm tak to že tam naskočí:

QEMU(1)                                                                                                                                                                            QEMU(1)

NAME
       qemu-doc - QEMU Emulator User Documentation

SYNOPSIS
       usage: qemu [options] [disk_image]

DESCRIPTION
       The QEMU PC System emulator simulates the following peripherals:

       -   i440FX host PCI bridge and PIIX3 PCI to ISA bridge

je jen čistá shoda náhod, že?

[trekker.dk]

Hezkej blábol jsi vyplodil ty. KVM v podstatě není nic jiného, než náhrada jaderného modulu kqemu; o zbytek se stále stará Qemu, rozdíl je jenom v tom, že místo emulace/práce s kqemu využívá systémová volání, které poskytuje kvm.

[none]

Chvalim chvalim! Dobry clanek, presne to jsou informace, ktere me zajimaji! Je jasny, ze KVMko v oblasti virtualizace jde dopredu a bude 'the best of' v linuxu. Xen jen pomalu vymira. Diky vyvojarum jadra a RH je KVM na vzestupu. Jen jednu pripominku k forme - nemohlo by byt formatovani vysledku treba v tabulkach? A jeste vetsiho efektu by bylo dosazeno peknymi barevnymi grafy.

Jeste jednou chvalim a diky!

[Robert Krátký]

nemohlo by byt formatovani vysledku treba v tabulkach?

Ono to je v tabulkách... máš na mysli orámování políček?

[none]

Mas pravdu, je to v tabulkach. Prislo mi to na prvni pohled takove neusporadane a spatne citelne. Ramecek by tomu pomohl a mozna i lepsi zarovnani hodnot.

[Robert Krátký]

Tak jsem se to pokusil vylepšit. Doplnil jsem zarovnání čísel doprava a ohraničení tabulek.

[none]

Diky, zda se to byt lepsi...

[VSi]

Je jasny, ze KVMko v oblasti virtualizace jde dopredu a bude 'the best of' v linuxu. Xen jen pomalu vymira.

To je otázka, u které bych si nebyl tak jistý. Xen byl převzat Citrixem, postavili na něm dost dalších produktů, umřít ho jen tak nenechají. Mohli Xen uzavřít, neudělali to, a vývoj je otevřený v rámci projektu Xen Cloud Platform (název se veze na aktuálním buzzwordu cloud, ale v podstatě jde o open-source bázi XenServeru a nového RPC-XML XEN API).

[none]

No mas asi pravdu, ze to neni jednoznacne, ale prinejmensim velmi pravdepodobne. Velkou vyhodou KVM je to, ze je ve vanila jadre a ma zajistenou podporu komunity. Diky linuxove filozofii bude KVM jediny hypervizor v jadre a ze by ho mel nahradit Xen si prilis nedovedu predstavit. Vnimam to tak, ze je tady KVM a ti ostatni, kteri se budou muset ohanet aby si svuj utrzeny kus kolace udrzeli. Nejsem si jisty, jestli je Citrix XenServer OpenSource, nevis jak to je?

[none]

Odpovim si sam: http://virtualization.info/en/news/2010/02/citrix-xenserver-is-now-open-source.html

[..... Izak .....]

No v distribucich je Xen mrtvy o tom zadna, ale XenEnterprise je zivotaschopny ...

Me na nem nastaval pouze jedna vec, udelal jsem upgrade pres DVD (jina nesla), pak mi nsel dat novy klic na dalsi rok, byly spatne klice, tak jsem to opravil podle fora na citrixu a zase prd, jen uz to psalo zase neco jineho ... do toho ta jeho hloupa instalace, ktera porad tvrdi, ze zformatuje disk ... nastesti to nedela, kdyz tam neco je, ale presto rika, ze data znici ... na zabiti tohle ... a aby toho nebylo malo, tak upgrade na versi, ktera chybu nemela nesla ani pres patch, ani pres DVD ... takze tim u me XenEnterprise skoncil a byl nahrazen KVM ... KVM nastesti prevezme virt. stroje bez problemu, jen jsem si prejmenoval ten bordel, co XenEnt. udela na LVM ) na neco humanreadable ....

Ale jako XenEnt. je jinak fajn produkt ... bude zit z jednoho duvodu, protoze Citrix jej vyuziva, maji i XenApp a jine veci, tedy integruji jej do svych produktu a tim padem je budou jejich zakaznici pouzivat jako bonus ... zbytek je nezajima ... hold budou mit 90% v citrix produktech a aplikacich a treba 10% v ostatnich pripadech ...

[Lupic]

Zajímalo by mě ještě srovnání toho samého stroje s pokud by bylo nainstalováno VMWARE ESXi v4. Nebo nemáte někdo porovnání?

[kyytaM]

Pokial viem, licencia VMware neumoznuje vykonovat a publikovat benchmarky.

[Lupic]

to je ale škoda, několik esxi provozujeme a pokud bude další virt. stroj potřeba,tak by KVM by mohlo přicházet v úvahu.

[trekker.dk]

Hm, to zní jako "náš produkt je krám, takže vám zakazujeme to říkat nahlas"

[Heron]

Podobnou doložku najdeš u mnoha produktů. Má to svůj smysl.

[TomCat1]

Má to svůj smysl.

Jiný, než zmiňuje trekker.dk?

[Věroš]

Oficiální důvod je "Nechceme, abyste dělali benchmarky při suboptimálním nastavení".

Neoficiální může být různý.

[Heron]

Jistě, že ano.

[Jozef Vondrák]

To je ale náhodička, našel jsem takový skripty tak jsem je spustil a vypadly z toho tydle čísílka ... tak se na vás obracím jestli nevíte co to znamená?

[..... Izak .....]

neumoznuje, ale proc se ji zabyvat ze ... zvlaste v CR ... ja ac jsem VCP, tak jsem zadnou NDA nepodepisoval )

[trekker.dk]

Článek se zabývá pouze FOSS řešeními a nemám v plánu na tom něco měnit (obzvlášť ne vzhledem k informaci zmíněné níže, ještě se tak nechat žalovat od nějakých neschopáků, to určitě...)

[Heron]

Dělali jsme interní testy pro naše potřeby mezi KVM a ESX3 (plné, nikoliv ESXi) a výkonově jsou obě virtualizace srovnatelné (co také čekat u plně HW virtualizace).

Rozdíly tedy nejsou ve výkonu ale ve službách kolem. Vmware toho nabízí daleko více. Pochopitelně za jiné peníze.

[..... Izak .....]

ESX3 a plna virtualizace bych moc nespojoval ) ... to snad u ESX4, ktery uz umi i vyuzit HW-Virt, umi skutecne adresovat RAM a jine feature )

[JoHnY2]

Meril jste nekdo rozdil mezi pouzitim qcow2/raw a LVM?

Slysel jsem, ze se za posledni rok hodne zlepsilo prave qcow2. Docela by me to zajimalo, protoze pro moje snazeni je qcow2/raw vyrazne sikovnejsi nez LVM, kde nemuzu s imagema zonglovat po siti jak me napadne.

[anon123]

Clanek je hezky, ale mel bych par vyhrad.

Myslim, ze autor by si mel ujednotit co je to HOST a co je to VM. Nemluvime o konfiguraci Xenu ci KVM hostitele, ale konfiguraci VM (Virtualniho Masiny/Stroje). Dale by se mel zminovat jen o VM a ne stroj. Stroj muze byt chapan jako HOST.

Sam moc nechapu co je to Xen 1/1. Kolikrat nevim, jestli jste testovaci script spoustel na Hostiteli ci ve Virtualnim stroji.

Pro me osobne by bylo jednodusi videt tabulku s: XEN, 4x VM - 7 vCPU, 2GB RAM, atd.

Dale bych rozebral ten script. Dost zalezi, jestli dany program zvlada multithreading ci ne a jak dobre.

Zrovna ted resim python script (single thread), ktery se vykona mnohem rychleji, kdyz jadro napinuji, nez kdyz necham vsechny jadra k pouziti. Prepinani mezi jadry tvori vyssi reziji (Credit scheduler).

Xen ted vyuziva Credit Scheduler (vychozi). Vyber applikace ma tedy velky vliv na test.

Docela, by bylo zajimave udelat mix VMs, jako clovek najde v normalnim prostredi a merit idle time. Kolikrat, kdyz vidim VMware oproti Xenu (stejne prostredi), tak Xen je proste lepsi a hbytejsi.

Jinak by nebyl spatny napad nechat bezet xentrace na hostu, kdyz bezi test ve VM a pak analyzovat (xenanalyze), jak se vyuzivaji jadra a kde by mohl byt problem ve vykonu.

Kdyz budu mit cas, tak ten scriptik overim s xentrace/xenanalyze a pak sem hodim analyzu, jakym zpusobem se ty jadra vyuzivaji.

Jinak diky za tu praci. Fakt to je makacka. Delal jsem takovou analyzu na 2D performance se single/multiprocesor HAL ve Windows XP VM. Prace je to hodne...

[jimik]

Prosím jak omezit výkon cpu jednotlivých virtuální hostů pod KVM?