Virtualizacia

[Jezevec]

Pouzivam v robote ESX server + infrastructure clienta, je to samo placene.

Co se vykonu tejce, pridelujes kolik pameti stroji das (stroj to vidi jako dostupnou RAM), ale prideluje se podle aktualni potreby (=> volna muze byt k dispozici dalsim strojum). Pak pridelujes pocet CPU (v nasi verzi max 4/virtualni stroj) a frekvenci (kolik rezervujes, kolik maximalne a prioritu vuci ostatnim strojum (to plati i o te RAM).

Mame na tom aktualne cca 20 stroju, z toho 1/3 jsou nekriticke provozni stroje, zbytek na testovani.

Kritickeho na tom neni nic z jedineho duvodu, kdyby se podelal HW, nemame to kam rozumne rychle presunout (nemame alternativni dostatecne vykone zelezo, technicky to problem neni, anzto si to virtualni stroje uklada na FC diskovy pole - umi bez problemu i iSCSI).

Umi to (za priplatek) cluster a v nem vyvazovat zatez - migrace virtualnich stroju mezi fyzickym HW za behu.

[Marty]

Umi to (za priplatek) cluster a v nem vyvazovat zatez - migrace virtualnich stroju mezi fyzickym HW za behu.

Pozor, to není ani tak vyvažování zátěže, ale spíš failover. Není možné pustit jednu virt. mašinu na více fyzických strojích (např. pár žiletek v jednom blade šasí a to vše přidělené clusteru na Infrastructure).

Ale VMware teď má představit nějakou novinku, využití cloud computingu pro virtualizaci... to by s trochou štěstí právě tohle mohlo přinést, tj. škálování výkonu pro jednu VM přidáváním fyz. hostitelů. Necháme se překvapit

[Jezevec]

Tj, ale umi to udelat to, ze pokud je jeden fyz stroj zatizenej a druhej ne, tak veme virtualni stroj a presune ho na ten nezatizenej.

[Marty]

Jj, volá sa to VMotion a vie sa to aj skriptovať. Dobré je to.
BTW - zajímalo by mě, jak by se to chovalo v praxi na nějakém systému v zatížení (např. SQLko v průběhu provádění nějakýho dotazu) - AFAIK tam totiž určitej výpadek je, co jsem to viděl v praxi, tak např. při souvislým pingu jeden-dva pakety vypadnou.

[Jezevec]

Nj, to je otazka aplikaci, normalne napsana aplikace by to mela bez vetsich obtizi zkousnout. Druha vec je, ze SQLko, specialne zatizeny, se asi virtualne moc neprovozuje. A treti, ze tech normalnich aplikaci posledni dobou osobne moc neznam.

Naopak znam hafo takovych, ktery nerozdejchaj ani celkem ocekavatelnou situaci.

[Marty]

Druha vec je, ze SQLko, specialne zatizeny, se asi virtualne moc neprovozuje..

Jasně, to jsem uved jen jako příklad... SQLko do virtuálu asi fakt ne. To už bys tam pak mohl šoupnout fileserver

[SonnY]

Jasně, SQLko do virtuálu asi fakt ne.

Preco nie?

[xvojta]

Pozor, to není ani tak vyvažování zátěže, ale spíš failover. Není možné pustit jednu virt. mašinu na více fyzických strojích (např. pár žiletek v jednom blade šasí a to vše přidělené clusteru na Infrastructure).

Ale VMware teď má představit nějakou novinku, využití cloud computingu pro virtualizaci... to by s trochou štěstí právě tohle mohlo přinést, tj. škálování výkonu pro jednu VM přidáváním fyz. hostitelů. Necháme se překvapit

Mícháte hrušky s jabkama

DRS - Dynamic resource pool - dynamické přidělování výkonu podle pravidel / potřeby, stahování virtuál z více na jeden fyzický server a vypínání aktuálně nepoužívaných fyzických serverů - např. v noci (dnešní populární green IT)

HA - failover - nahození virtuály po pádu (případný přesun na jiný fyzický server)

VMotion - přesun virtuál za běhu mezi fyzickými servery, to je umožněno VMFS

VMotion Storage - to stejné jako VMotion, ale pro užívaný storage...

VMotion, VMotion Storage a DRS je licenčně pokryto jen nejvyšší verzí ESX Enterprise.

[Marty]

Vojtíku to je sice hezký, že víš co to znamená, ale ani DRS neumí přidělit HW více fyz. strojů zároveň jednomu VM - a to bylo to, co jsem psal.

A netvrdil jsem, že VMotion je failover, ale že je spíš než balancing použitelný pro failover. Pravda je na obou stranách, DRS pro balancing používá něco jako VMotion a stejně tak HA pro failover používá něco jako VMotion

[xvojta]

Vojtíku to je sice hezký, že víš co to znamená, ale ani DRS neumí přidělit HW více fyz. strojů zároveň jednomu VM - a to bylo to, co jsem psal.

A netvrdil jsem, že VMotion je failover, ale že je spíš než balancing použitelný pro failover. Pravda je na obou stranách, DRS pro balancing používá něco jako VMotion a stejně tak HA pro failover používá něco jako VMotion

Ne "něco jako", oni používají VMotion

A s fyzickými servery jsem tě špatně pochopil, takže MEA CULPA

[Petrik]

Co se vykonu tejce, pridelujes kolik pameti stroji das (stroj to vidi jako dostupnou RAM), ale prideluje se podle aktualni potreby (=> volna muze byt k dispozici dalsim strojum).

Muzes mi prosim objasnit k cemu to specialne u serveru je, kdyz servery typicky veskerou volnou pameti pouzivaji jako cache? Musim uznat, ze to zni moc pekne, ale realne pouziti si dokazi predstavit jen u OS ktere se casto restartuji a tedy nedokazi zaplnit svou pamet diskovou cache.

2frelichl:
rekl bych ze HW akcelerace/implementace virtualizace muze delat divy, ty cisla z bechmarku to docela jasne ukazuji.

[frelichl]

rekl bych ze HW akcelerace/implementace virtualizace muze delat divy, ty cisla z bechmarku to docela jasne ukazuji.

O jaké akcelaraci třeba diskového výkonu mluvíme?

[Marty]

Obecně vzato, u virtualizace bude často prvním úzkým hrdlem diskový subsystém a jeho limit IOPS.

Ono RAM a CPU se sdílí dobře, tam nám to příliš nehejbe s latencí a dá se snadno dynamicky přidělovat, ale když to vezmem nejjednodušejc - 1CPU, 1disk - kolik na tom pustíme procesorově náročných strojů a kolik diskově náročných strojů?
V druhém případě výrazně méně. CPU time jde snadněji rozdělit, narozdíl od možností disku...

Proto já nejsem zastáncem virtualizace DB a file serverů, protože to nemá význam - virtualizace má smysl hlavně ve sdílení HW.. a to v tomhle případě prakticky není možné.

Druhá věc je, pokud virtualizaci používáme kvůli failoveru nebo snadné migraci, to jo - ale pak nám nejde o výkon.


Vždy je to o prioritách...

[Petrik]

O jaké akcelaraci třeba diskového výkonu mluvíme?

Bavil jsem se o CPU vykonu, diskovy vykon by virtualizaci nemel byt zasazen vubec, protoze v dnesni dobe uz vykon disku neni nejak vyrazne ovlivnovan radicem disku ci jeho ovladacem, ale diskem, ktery je v celem retezci bezkonkurencne nejpomalejsi (IMHO). To samozrejme plati za situace, kdy na jeden virtualizovany OS pripada jeden disk ci diskove pole.

2Marty: a on je problem dat do serveru vice disku a nejak rozumne je pridelit bezicim OS? Pravda je ze napr. pro zminovane databaze to ponekud problem byt muze, protoze databaze casto dokazi vyuzit 2 a vice disku (RAID poli)

[HollyG]

Tak hlavne kdyz uz budes delat nejaky databazovy nebo jinak narocny server na virtualizaci, tak storage toho stroje bude na samostatnym diskovym poli, coz kdyz spojime s pripojenim FC tenhle problem eliminuje.

[Marty]

Tak hlavne kdyz uz budes delat nejaky databazovy nebo jinak narocny server na virtualizaci, tak storage toho stroje bude na samostatnym diskovym poli, coz kdyz spojime s pripojenim FC tenhle problem eliminuje.

Jenže i tak potřebuješ VM přidělit tolik disků, kolik by měl fyzický stroj, aby byl výkon přijatelný.

Samozřejmě, RAID 10 na 15K FC by mohl postačit pro 3-4 nenáročnější VMs... Ale o "nenáročných" se právě nebavíme.

[HollyG]

Jenže i tak potřebuješ VM přidělit tolik disků, kolik by měl fyzický stroj, aby byl výkon přijatelný.

Samozřejmě, RAID 10 na 15K FC by mohl postačit pro 3-4 nenáročnější VMs... Ale o "nenáročných" se právě nebavíme.

Mozna si nerozumime Ja mluvim o diskove polici, kde pro napr pro ten exchange, resp jeho databazi udelas dedikovane diskove pole jen pro ni, i system je pak na jinem poli

[frelichl]

Bavil jsem se o CPU vykonu, diskovy vykon by virtualizaci nemel byt zasazen vubec, protoze v dnesni dobe uz vykon disku neni nejak vyrazne ovlivnovan radicem disku ci jeho ovladacem, ale diskem, ktery je v celem retezci bezkonkurencne nejpomalejsi (IMHO). To samozrejme plati za situace, kdy na jeden virtualizovany OS pripada jeden disk ci diskove pole.

To je teorie, moje praxe je, že přístup na disk z virtuálního stroje je o mnoho pomalejší než přístup z fyzického stroje. A je vcelku jedno, jestli má virtuální mašina jenom image disku nebo vyhrazený oddíl, propad je pořád obrovský a hlavně se to chová velmi podivně.

S variantou externího pole nemám moc relevantní zkušenosti, zkoušel jsem jenom iSCSI na ne moc kvalitním železe (4x500 GB v softwarovým raid5 respektive raidz na opensolarisu se zfs) a žádná sláva to taky nebyla. Jak to vypadá s drahým FC polem nevím, doufám a předpokládám že líp, ale i tak bych se divil, kdyby byl propad výkonu jenom 10 %.

[Petrik]

Pod jakym OS a s jakou virtualizaci? Pravda je, ze jsem ted lehce zagoogloval a dost lidi pozoruje zpomaleni diskovych operaci pod xenem...

[NeMeM9aA]

tak treba na linuxu je propad diskovych operaci brutalni u vsech nastroju vyjma openVZ. Taktez pri plne virtualizaci je brutalni propad na NIC.

[Jezevec]

Muzes mi prosim objasnit k cemu to specialne u serveru je, kdyz servery typicky veskerou volnou pameti pouzivaji jako cache? Musim uznat, ze to zni moc pekne, ale realne pouziti si dokazi predstavit jen u OS ktere se casto restartuji a tedy nedokazi zaplnit svou pamet diskovou cache.

2frelichl:
rekl bych ze HW akcelerace/implementace virtualizace muze delat divy, ty cisla z bechmarku to docela jasne ukazuji.

Na virtualu provozujem nekolik stroju, jejiz vyuziti je narazovy. Normalne (kdyz nic nedelaj) je pak realne pridelena pamet v radu desitek MB. Ostatne M$ server se typicky chova uplne stejne jako desktopovy widle - sprava pameti je naprosto zoufala.

Ad disky, on je problem dat do serveru vubec nejake disky. U "nejvetsich" bezne dostupnych stroju tam das 8 disku. Das je do R10 a skoncil si. Dostanes se na nejakych max 2kIOps. To je pro provoz jakekoli trochu zatizenejsi DB dost malo. Je to malo i pokud hodlas na tom stroji provozovat virtualizaci, protoze kdyz ti budou vsechny stroje zaroven hrabat na disku, jako ze budou, tak rychle narazis.

O nejakym pridelovani disku bezicim OS si nech jen zdat, to by ti ta virtualizace byla nanic. Samo lze virtualnimu stroji natvrdo pridelit fyzickej disk, ale tim padem na tom disku nemuzes mit data zadnyho jinyho stroje => pri tech 4ech zrcadlech muzes virtualizovat 3 stroje. Ponekud plytvani vykonem CPU/RAM.

Virtualizace je z mych zkusenosti spica na nenarocny aplikace, predevsim je dobry mit kazdou vec na samostatnym stroji. Nemusi se pak clovek bat, ze opatchuje system/apliakce a prestane fungovat neco uplne jineho. Jakmile by nekdo chtel virtualizovat a zaroven mel znacny pozadavky na poskytnutej vykon, tak ho to bude stat nasobky reseni primo na zeleze.

[HollyG]

Ehm, proc by u vazne myslene virtualizace (na produkci) nekdo cpal disky do serveru, kdyz nepocitam RAID1 pro ESX?
Od toho jsou snad DAS pres FC, idealni je spojeni s blade serverama.

[Petrik]

Ehm, proc by u vazne myslene virtualizace (na produkci) nekdo cpal disky do serveru, kdyz nepocitam RAID1 pro ESX?
Od toho jsou snad DAS pres FC, idealni je spojeni s blade serverama.

Treba protoze ne kazda firma ma na FC/blade? Navic neni pravda, ze lokalni pole/disky jsou rychlejsi nez FC (latence, propustnost)?

[HollyG]

To je sice pravda, ale bez FC nebo iSCSI vmware cluster nevyrobis, navic dneska se diskovy pole pouzivaj i treba k zalohovani...
Mel jsem pocit ze se tu bavime o trochu jinych serverech nez domaci multimedia server na sdileni filmu pro 2 PC
Jak treba psal Jezevec, 2x4 jadro-procesor, 64GB RAM atd, tam uz ta cena police neni zase tak vysoka s ohledem na cenu serveru, nehlede na to ze je to proste potreba.

[Petrik]

Promin, ale FC/blade je enterprise reseni, asi se dohodneme na tom, ze vetsina mensich a strednich firem enterprise nema a v dohledne dobe mit nebude, protoze to je proste priliz drahe a vetsinou to neni potreba. Virtualizace je podle me dobre pouzitelna i v SOHO, castokrat firmy potrebuji win terminal server pro remote access ci provoz nejakych win programu a zaroven chteji mit linux server pro vse ostatni. Misto koupe dvou stroju se koupi jeden a nasadi virtualizace, anebo jeste lepe, koupi se dva, a jeden muze slouzit jako zalozni / zalohovaci (na obou bezi totez s virtualizaci). Dnesni HW je jiz dostatecne vykonny na to aby na prumernem serveru (QC s 8GB RAM a 4x disk) pohodlne bezelo vse potrebne (ucetnictvi, IS, samba, maily a pod) ve virtualizaci. To je muj nazor, nenutim nikoho aby s tim souhlasil.