Dotaz: Virtualizace pro terminál server

[virt]

Dostal se mi do rukou jeden velice výkonný stroj s procesory xeon. Chtěl bych na něm provozovat virtualizaci. Jeden virtuální server by měl být asi ltsp server pro 20 klientů, druhý lamp, třetí mail server, popřípadě 4. terminal server pro windows. Který(nejlépe opensource) virtuální software by dokázal potenciál hardware dostatečně využít, abych nepociťoval znatelné výkonnostní ztráty. K dispozici jsou 2 čtyřjádra xeony, 32GB ecc fully buffered ram, 4 SAS disky a 2 sata disky, takže kdyby uměl virtual server přidělovat na úrovni hardwaru procesory, pamět, disky, usb.., bylo by to fajn. Splňuje nějaký virtual server moje požadavky?

Odpovědi

[virt]

.

[diverman]

?

[TomR]

Je-li na HCL, mrknul bych se na VMware ESXi. Není sice OSS, nicméně free od konce července ano. A jelikož na něm ještě před pár týdny VMware vydělávala, nebál bych se ho nasadit i jinak než jen na testování (momentálně ho mám v testu nad strojem který není v HCL a tváří se víc než stabilně).

[virt]

A splňuje mé požadavky co se týče plné virtualizace? Potřebuju, aby měl host přístup k vybraným zařízením hostitele, tak aby mohl hostovaný os používat raid atd. A jak je na tom ohledně výkonu? Koukal jsem, že XEN má 3% výkonností ztrátu oproti solo systému.

[Petr]

A tak jaký je rozdíl mezi VMware ESX a VMware ESXi ?

Je to ESXi nejak osekany ze je FREE ?

[koulinek]

Jde vpodstatě o ten stejný hypervizor jako u ESX, avšak neobsahuje to čemu se u ESX říká servisní konzole. Dále pokud budete chtít využít další funkčionjality, bude již třeba licence.

[TomR]

pravda pravda ... a co se té servisní konzole týče - ESXi dostalo do vínku RCLI, která umí prakticky vše jako konsole v ESX, navíc se dá (až na výjimky, které ještě nejsou plně podporované) použít i právě na ESX (podporuje jak přímo komunikaci s ESX(i) tak i přes VI). Kdesi jsem četl (tuším tu [pdf]), že chce VMware na tenhle způsob ovládání výhledově přejít a starou dobrou konzoli tak jako tak zrušit...

[Pavel]

Lze už mít VMFS i na SATA discích ?
......aby už konečně mohlo VMware ESXi používat i široká veřejnost na běžně dostupných strojích ?

[koulinek]

dá se tak provozovat, ale proč nevyužít třeba iSCSI?

[muficek]

To znamená, že pokud budu mít pro příklad tuto konfiguraci:

Dnešní "běžné PC" - Pentium 4, 2GHz, 2GB RAM
1x IDE disk WesternDigital 80GB
1x IDE CD-ROM mechanika
1x SATA disk WesternDigital 400GB

.......a s naprosto běžným IDE/SATA řadičem, který je integrovaný na základní desce,,
tak budu moct využívat VMware ESXi asi takto ?....

IDE disk 80GB = pro systém VMware ESXi
SATA disk 400GB = pro VMFS storage virtuálních strojů

.....kde VMFS nebylo možné donedávna (alespoň na ESX) používat pro storage virtuálních strojů ?

Rozumím tedy tomu dobře ?

PS: A jak jste to myslel s tím iSCSI ? To bych musel mít data storage někde na síti - ale to zatím domácí podmínky neumožňují

Děkuji za Vaši odpověď.

[TomR]

záleží na použitém SATA řadiči - viz HCL. Osobně mám momentálně testovací ESXi na (oficielně nepodporovaném) HP DL320 G5p a se SATA normálně běží. Nesmí ovšem být aktivovaný RAID, se kterým si konkrétně nad Intel 82801IR opravdu nerozumí

[virt]

Jak je na tom výkonnostně vmware vs. xen?

[stepa]

XEN
mam takhle mnohem vice stroju a jediny problem jsou win - neustale cosi zapisuji na disk a tak disky neustale zamestnavaji (zamerne nepisi ze ZADIRAJI, protoze nezadiraji, ale porad jsou aktivni).

[virt]

Ještě bych si rád ujasnil pár věcí. To co já potřebuju se jmenuje paravirtualizace? A jakou má subjektivně režiji? Zpomalování zápisy na disk asi moc pociťovat nebudu, plánuju pro každý os zvláští disk, popř. 2 a ty dát do raidu. Předpokládám, že rychlejší je předhodit hostovy fyzicky 2 disky, jako by měl k nim plný přístup(pokud je to možné udělat) a potom v hostovy udělat raid, než předhodit hostovy hotový raid jako /dev/md0?

[virt]

A ještě hrozně důležitá otázka. Co virtuální server a 64-bitová architektura?

[virt]

Tak zkouším ten XEN. Tady jsou nějaké testy. Oba os jsou opensuse 11. Guest je paravirtualizován. Disk je externí přes usb. Guest má /dev/sdc3, host /dev/sdc1

time dd if=/dev/urandom bs=1M count=1000 | gzip -9 > /dev/null


HOST:

1000+0 vstoupivších záznamů
1000+0 vystoupivších záznamů
1 048 576 000 bajtů (1,0 GB) zkopírováno, 177,791 s, 5,9 MB/s

real	2m57.800s
user	0m53.855s
sys	2m7.132s


GUEST:
..
5.8 MB/s
..
real	3m1.769s
user	0m53.579s
sys	2m8.440s



time dd if=/dev/zero bs=1M count=1000 of=/test.img


HOST:

25.3 MB/s
real	0m41.477s


GUEST:

27.6 MB/s
real 0m37.991s

Má někdo nápad jak ještě porovnat výkony obou systémů?

[virt]

A plně virtualizovaný debian:

time dd if=/dev/urandom bs=1M count=1000 | gzip -9 > /dev/null

5,7 MB/s
real 3m5.011s

Co že je jen tak malý rozdíl? Já myslel že xen má větší režii? nebo testuju špatně?

[VSi]

Praktickou zkušenost nemám, ale doporučuji se podívat na tohle:

http://support.zcu.cz/images/Grant.xen64.linuxalt.prednaska.pdf

Případně i na video z LinuxAlt, které je už možné stáhnout.

Taky mě překvapilo, jak malou režii Xen má, oproti tomu VMWare server / VMWare workstation.

[virt]

Když mám procesor s hardwarovou podporou virtualizace, tak co bude rychlejší paravirtualizace nebo plná? A o kolik. Ty moje testy toho asi moc neřeknou :).

[VSi]

Co jsem pochopil z té přednášky, tak paravitrualizace (pokud se nepletu, tak je to ten případ, kdy je nutná úprava kernelu, tj. s Windows není možná) má výrazně menší režii, protože virtualizační software nemusí tak moc předstírat reálný hardware.

Plná virtualizace je potřeba pro běh Windows a má režii větší, ale HW podpora virtualizace umožňuje tuhle režii dost omezit.

Jak jsem to pochopil, tak HW podpora pro virtualizaci má zásadní význam pro výkon virtualizovaných Windows a v případě Linuxu s jejím použitím není nutné mít upravené jádro, což není tak zásadní přínos.

[virt]

No právě instalace třeba ubuntu jako paravirtualizovaného ghosta je náročnější než plně virtualizovaného a docela často v ubuntu vycházejí aktualizace jádra tak proto uvažuju o nasazení plné virtualizace pro ubuntu, ještě bych potřeboval vědět, o kolik bude pomalejší.

[muficek]

Jak je to teda s tím VMFS na SATA discích ?

Lze již storovat virtuální stroje na SATA disky ?

[FF]

Rekl bych, ze hodne bude zalezet na typu zateze, t.j. jake aplikace tam pobezi.

Pres 1 rok jsem provozoval Xen (openSUSE 10.2) v nasledujici konfiguraci: terminalovy server v domene 0 (kvuli rychlejsi odezve grafiky) a dva lamp servery ve virtualnich strojich. Masina mela 2 dvoujadrove CPU, 8 GiB pameti a SATA disky. Pri beznem provozu to fungovalo OK, ale problemy nastavaly ve dvou pripadech: (1) kdyz ve virtualni masine bezely procesy s intenzivnim zapisem na disk, pak terminalovy server (v domene 0) mel tak velke latence, ze uzivatele provozujici interaktivni procesy nadavali. (2) Nejaky proces (v nasem pripade uzivatelsky skript v matlabu) alokoval velke mnozstvi pameti a terminalovy server zacal swapovat (presneji "pageovat"). Krome velmi pomale odezvy se dely veci, ktere jsem nikdy na normalni swapujici masine nevidel (procesy v podivnem stavu, ...). Vetsinou jsem radsi rebootoval. Tipoval jsem to na chyby v (xen-) jadre. Soucasne verze uz tim mozna netrpi - nevim.

V kazdem pripade jsem nyni kvuli vykonu a stabilite presel na konfiguraci, kdy terminalovy server bezi pod normalnim jadrem (openSUSE 10.3). Na separatnim stroji (se dvema 1 GHz PIII) mi bezi 2 lamp servery ve virtualnich masinach pod Xenem (take openSUSE 10.3). Tahle konfigurace mi zatim vyhovuje, protoze interaktivni odezva u webovych aplikaci neni kriticka a ta stara masina to vykonnostne bez problemu zvlada.

Byt vami, tak bych se soustredil hlavne na ty latence pri interaktivnim pouzivani, kdyz probihaji nejake I/O operace (No, pokud by se spustil Beagle vsem 20 uzivatelum najednou, tak by to neutahlo ani klasicke jadro.) Mozna by stalo za to se mrknout na nabidku VMware. Xen je prima pro webove servery, ale u terminalovych serveru bych byl kvuli latencim opatrny.