Ahojte. Ktory software je najvhodnejsi pre server zamerany na poskytovanie virtualnych serverov? Chcem si casom spravit server s VPSkami a preto ma zaujima, ktora paltforma je navhodnejsia ako zaklad.
Printable View
Ahojte. Ktory software je najvhodnejsi pre server zamerany na poskytovanie virtualnych serverov? Chcem si casom spravit server s VPSkami a preto ma zaujima, ktora paltforma je navhodnejsia ako zaklad.
Dost záleží co na tom budeš provozovat a na čem to budeš provozovat. Na linuxu třeba kvm, openVZ...
V praci pouzivame na nasich serverech Debian linux s XEN + Ganeti clustering.
Pred timto jsme meli OpenVZ, ale neosvedcilo se to.
Mohl bys rozvest v cem openVZ zklamal?
edit: jinak ja jsem prave nasazoval virtualizaci (ve velmi malem rozsahu - 4 virtualni stroje) a vybral jsem si KVM (potreboval jsem plnou virtualizaci a tak i paravirtualizovane blokove zarizeni a sitovka se hodi). Protoze uz je to ve vanilla kernelu tak me prislo jednodussi to rozbehat.
No poptam se na to. Osobne se zrovna o tohle nestaram, ke mne se akorat donesla zmena platformy :)
Ono na linux je to nejvykonejsi reseni. Je tam naprosto minimalni vykonosti propad. Ale kdyz jsem o tom premyslel, tak zrova pro gentoo byly dostupne stare kernely - jeste dneska je jako stabilni oznacen 2.6.18 a 2.6.24 uz je oznacen ~* (experimentalni). Jeste jsou i 2.6.27 ale to uz je maskovane.
Navic jsem potreboval tu plnou virtualizaci a michat 64bit a 32bit stoje(to sice nebylo nutne, ale bylo to zadouci).
Jinak RedHat ted nejak misto xenu zacal tlacit prave KVM.
Ale jinak ja to ovladam pres libvirt a tak zrovna a ten zvlada i ovladani xen stroju. Takze z hlediska obsluhy by uz nebyl rozdil.
No bude sa jednat o server za 50-100k, ale este nemam nic vybrane, nakolko to nie je momentalne aktualne.
Ako som pisal, bude sa jednat o server, kde pobezia VPSka. Co hovorite na VMWare ESXi? Co som cital, tak to nahradza "nosny" system, ma to nejakych 30 MB. Nie je teda nutne instalovat linux, win, freebsd ani nic podobne, aby na to mohli ist virtualne masiny, ale esxi to cele nahradi.
Jo, ale taky nepoběží žádný systém nativní rychlostí (což považuju dost za výhodu kvm/xen apod., že hostitelský systém běží normální rychlostí a je na něm možné pustit kritické aplikace), ale pokud to nepotřebuješ, budiž. V takovém případě ale jednoznačně běž do certfikovaného serveru, je to hodně vybíravé na hardware (ESX ostatně taky).
Dál se to celé spravuje z windows-only grafické konzole, někomu to může vyhovovat někomu ne.
No hlavne by som tam chcel mat skalovatelnost vykonu medzi jednotlive vps.
Znami mi poradil ze asi najlepsie riesenie je nahodit linux a az nan vpska. Cital som ze najlepsi virtualizacny nastorj je quemu. Je to tak, alebo je vhodnejsie/lepsie nieco ine? Pytam sa tieto stupidne otazky, preto, aby som nemusel stracat cas ucenim sa prace s niecim, co na koniec bude mat nejake nedostatky o ktorych som na zaciatku nevedel.
qemu jedine pokud chces emulovat jinou architekturu.
Jinak KVM, coz je v podstate qemu na steroidech(hw virualizace) a nebo Xen, ktery afaik pouziva taky kusy kodu z qemu.
Jinak je mozne uvazovat i o openVZ (zadna ztrata vykonu, ale je to omezene), nebo virtualboxu, ktery ma ted i podporu serveroveho provozu (ovaladni pres terminal - ale u neho si skutecne nejsem jisty, jesli ho lze nasadit produkcne).
Jestli jsem tě pochopil dobře a chceš mít detailní možnosti přidělování výkonu jednotlivým virtuálním strojům, tak v podstatě nemá cenu přemýšlet o ničem jiném než o virtualizaci na úrovni operačního systém (tj. openVZ, Linux-VSever...)
Třeba v openVZ si s tímhle můžeš opravdu vyhrát, možná až moc. V ESXi/kvm toho moc nevymyslíš, počet virtuálních procesorů, limity na paměť a disk a tím to hasne, i když teda možnosti ESXi už si moc nepamatuju.
Osobně jsem odchovaný na platformě VMware, sám používám VMware server (ať na desktopu s win nebo na serveru s ořezaným lin jako pokus napodobit ESX). V práci mám na starosti VMware Infrastructure, na serveru s 2x QC, 16GB RAM a 4 diskovejma polema.
Nemáme na tom mission critical stroje, ale vývojové instalace. S výkonem jsme zatím velmi spokojeni, ale běží nám tam jen cca. 6 strojů (2x linux a 4x W2003/2008 a SQL).
Konkrétní dotazy (zvláště srovnání produktů VMware) můžu zodpovědět...
PS. alternativou je taky MS, k provozu toho jejich virtualizátoru si můžeš stáhnout WinServer2008 a pokud na tom jen pojedeš VMka, je to free. Nezkoušel jsem.
Mně se VMWare server hodně líbil, ale poslední dobou mi začíná čím dál víc lézt krkem. Občas to umí být trochu nestabilní, jak webové rozhraní, tak dokonce samotné virtuální mašiny.
Nejvíc mě ale z poslední doby dostalo, když jsem jednu virtuální mašinu restartoval a ona nechtěla najet. Webové rozhraní hlásilo jenom nějakou obecnou chybu, nic konkrétního. Zoufale jsem pak googlil na webu, čím to může být a zjistil jsem, že musí upgradovat na novou verzi, že se prostě VMWare rozhodnul upozornit uživatele na novou verzi tím, že nepůjdou nastartovat virtuální mašiny. Samozřejmě upgrade taky chvíli trvá, takže downtime byl ve výsledku docela velký.
Jo, obecně VMware zřejmě nemusí být ve všem na špici. Přece jen, co si budem povídat, zcela jistě těží z toho, že byl "první" a obecně z pionýrských úspěchů - ale na úkor nových technologií. Řekl bych, že rivalové dokážou často nabídnout zajímavější featury.
Ad verze - osobně jedu na VMware Serveru pre-2.x verzích, neb 2.x na Win je úděs - instalátor místo cca. 140MB má necelých 400, instaluje si Apache na management interface a vyžaduje ho. Nainstaloval jsem, ale obratem šel bohužel pryč... všude jedu na verzi 1.0.8. (ale to není nikde mission-critical)
Pre 2-x verze jsou na linuxu problem. Nelze je s novymi kernely pouzivat (2.6.26 tusim). Pouziva to nejake depreceated features. Nevim presne co. Lze to nejak obejit, ale pak nelze korektne vypnout host PC.
Jinak vmware ma velmi pekne GUI. To naprikald virt-manager na spravu xen ci kvm stroju je nestabilni a malo toho umi. Na druhou stranu libvirtd, na kterym je to postaveny, stabilni je a tak staci restartovat GUI a nic se nedeje. Navic prace z prikazove radky je luxusni.
To s tím kernelem nemůžu potvrdit, mně se to vždy podařilo rozchodit. Aktuálně mi nic na linuxu neběží, tak to nemůžu ověřit, s jakou verzí kernelu.
Vždy jsem ale kompiloval svoje moduly.
Osobně se mi co do mgmt interface moc líbí VMware Console. Proto mě mrzí, že ji není možné použít na ESX.
Tušíte někdo, jestli je k ESX nějaká standalone aplikace na management? Přesně něco jako VMware Console. Mají VMware Remote Console, ale jen jako ten blbý plugin do prohlížeče...
Ano. Je to closed source, takze moduly se musi kompilovat zvlast proti konkretnimu kernelu. Vypada to, ze uz jsou na to funkcni patche viz zde, ale byly s tim problemy a evidentne to stale neni moc OK. Ja uz vmware taktez na linuxu nepouzivam, takze blizsi report nemuzu podat. Co je ale pekna vychytavka - umi 64bit na 32bit hostu. KVM tohle neumi a do virtualboxu to bylo zavedeno nedavno.
Console funguje nativne i pod linuxem (ale tebe predpokladam trapi MacOSX).
Pockejte k ESX je snad konzole defaultni vec ne. To k cemu uz konzole neni a jenom webovej ksicht je vmware server 2.0, nicmene s jistymi omezenimi lze pouzit i ta k ESX.
Jinak se to jmenuje VMware Infrastructure Client
Ještě jinak (ale sám v tom mám taky bordel, opravte mě když tak):
Marty napsal, jestli je k ESX serveru samostatná konzole, myslím, že se uspal, a chtěl napsat, jestli je k Serveru 2.0 samostatná konzole, což pokud vím není (jenom to webové rozhraní), ale k ESX určitě je. Ta konzole, kterou jsem k ESX 3.x viděl vyžadovala .NET a proto říkám, že by mě překvapilo, kdyby jela i pod linuxem.
Neupsal jsem se - fakt jsem myslel k ESX.
Používám konzoli k VMware Serveru 1.x, ale s tou se na ESX připojit nejde. Stejně tak nemám k dispozici žádný standalone SW, kterým se dá managovat ESX. Ve VMware Serveru 1.x v mgmt interface je v login screenu webu odkaz na stažení, ale u mojí instalace ESX není. Ale možná to jen náš admin zakázal :)
HollyG, dík, ale pod VMware Infrastructure Client se mi zatím nedaří nic najít. Kdyby byl link, nezlobil bych se :-)
Marty: pokud vím, tak ta konzole se běžně stahuje přímo ze serveru, na kterém si ESX nainstaluješ. Něco jsem našel tady:
http://www.petri.co.il/5_ways_to_adm...esx_server.htm
esx != esxi. esx ma konzolu, esxi nie.
Infrastructure Client vzdycky stahnu z webovky ESX, resp. Virtual Center serveru, je samozrejme i na instalackach prave Virtual Center serveru (ESX ne, to je ciste linuxacka vec).
ESXi jde managovat timhle klientem taky, ostatne jde pripojit i do Virtual Center, dokonce pokud si to dobre pamatuju po nahrani licence to umi i ficury plnyho ESX, i kdyz asi ne vsechny.
Z ESXi stahnout konzole nejde jak pise SonnY, koneckoncu je to delany jako minimalisticka vec.
A c ohovorite na MS Hyper-V, alebo Xen Server?
Hyper-V bude jeste nejakou dobu trvat, nez bude mit smysl hodnotit pouzitelnost ve firemnim prostredi (management, funkce)
Teraz mi vlastne doslo, ze ten OpenVZ, ktoremu som sa chcel venovat nie je platformovo nezavysli, respektive ze na tom moze ficat len linux, navyse s jednym kernelom. Ktore zo spominanych rieseni je nezavysle, v tom zmysle, ze nema spolocny kernel, teda je mozne tma rozbehnut na vps freebsd, macos, windows, proste oddelena virtualizacia?
Napisi jen par pozorovani a par nactenych informaci:
XEN - enterprise reseni, mel by mit nejvetsi vykon, neni uplne snadne nakonfigurovat sit
QEMU - velmi jednoduche, velmi pomale ( s kqemu to ujde, ale stejne nic extra), umi to export videa do VNC
virtualbox - velmi dobre reseni na desktop, velmi svizne, bez problemu, doporucuji
Nevím co řešíte, technologicky je nejdále vmware. ESXi je jasná volba. Je grátis a managovat (ano, není to procházka růžovou zahradou) jde např.přes PowerShell. Pokud chceš vCenter, musíš zaplatit.
HyperV je dost k ničemu, jelikož běží na W2k8 serveru - naopak ESXi vrstva má 32 MB. To je dosti velký rozdíl - myslím, že si tady nároky W2k8 na HW umí spočítat každý.
HyperV je podle všeho derivát XENu.
Další výhodu, kterou ESXi nabízi je WMFS. Což se na tomto poli opět s NTFS nedá srovnávat.
Takže asi toliko můj názor.
Pokud trváš na Linuxu, pak XEN.
http://www.virtualization.info/2008/...r-v-which.html
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.
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 :-)
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.
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.
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.
SQLko pokud je dost zatizeny, tak potrebuje vetsinou takovej vykon, ze bys tak jako tak moh na danym zeleze provozovat jen prave jeden virtualni stroj s tim SQLkem. Mno a pak specielne u jedne "neuzasnejsinasvete" firmy (M$) zjistis, ze na virtualu mas leckde precijen oneco vetsi latence a ze to co na tom zeleze naprimo jede bez potizi virtual nezvlada.
Takze pro testovaci ucely/maly nezatizeny db/... je to OK, ale pokud mas DB desitky/stovky GB a desitky/stovky pristupujicich useru zaroven ... mas dost casto problem vubec sehnat dostatecne dimenzovany zelezo (at zije levny prgani v .NET a spol).
Přesně tak. No a co si budeme povídat, virtualizace platformy pro datově náročný služby jako fileserving a DB hosting asi úplně ideální nebude - hlavně kvůli zbytečně velké komplikaci připojení storage. A každá taková věc právě zvyšuje latence, jak už zmínil Jezevec.
Virtualizace platformy je IMHO více než vhodná pro aplikační servery a jiné služby datově nenáročné, ale např. kolísající nebo vyžadující škálovatelnost.
Dále ideální samozřejmě jako backup/failover prvky různých aplikačních clusterů, testovací prostředí, atd.
My používáme VMs právě pro vývoj a testování, je to k nezaplacení...
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.
:-)
Nemohu souhlasit, řada zákazníků používá ESX přímo na produkci, kompletně u všech serverů (až na vyjímky) - včetně DB aplikací (výroba, apod. - čili nízká latence je důležitá) a všichni si to chválí.
Připojení storage NAS, HP EVA, Centery, Celerry, Avamar, atd. a vše bez problémů ;)
Čili není důvod, prečo nie ;)
P.S. Ne, nepracuju pro vmware ;-)
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 ;)
Tak teď pleteš jabka s hruškama ty. Ale nebudem se chytat za slovíčko, žejo :)
Netvrdím samozřejmě, že nikdo nepoužívá virtualizaci v produkci - naopak to přináší mnoho výhod. Ale platí to, co řekl Jezevec, při určitým požadavku na výkon budeš rád, když ti např. SQL poběží na jednom fyzickým HW, natož to zkoušet virtualizovat.
Co tady zmiňuješ jsou minimálně v případě Centery záležitosti secure archivace a dosledovatelnosti, ostatně Centera sama je takový trochu virtualizovaný storage cluster :) A Avamar (software!) je typickej příklad pro součást backendu fileserveru, takže proč ne... ale já nejsem zastánce virtualizace pro fileserving a DB, jak už jsem říkal, takže to podporovat nebudu :)
Nebudem, neb Centera je CAS (Content Adressed Storage) takže mezi storage patří. To že uvnitř je to modfikovaný linux, je věc jiná. Zvenku je to storage. Můžeš na něm pustit třeba FTPko - no problemo ;)
Ano AVAMAR je software, uvedl jsem ho pro ilustraci, protože ze storage úzce souvisí ;) Ale jinak máš pravdu, storage jako taková, to opravdu není :-)
A tak mě napadá, nejsem si jistý, ale nejdou náhodou BLADE servery škálovat a distribuovat pak jejich společný výkon?
VMware rozložení jednoho VM na více fyz. strojů neumí. Jestli to umí nějaká platforma bladů, to nevím... AFAIK ne...
Ad Centera a FTP, to by bylo slušný zvěrstvo, koupit za miliony/desítky milionů Centeru a pustit na tom FTP ;D Nicméně samozřejmě jako vstup pro data k archivaci ano...
Nj, podivej se na to asi takhle, mam tu dva stroje 2x4 jadra + 64GB RAMeti. Bezi na tom SQLko (primo) a na druhym ESX. Neni to sice stroj na hranici vykonostnich moznosti (daj se tam pridat jak procesory tak ramka), ale ...
Ono totiz to SQLko na virtualu samozrejme pobezi, zprovoznit ho, pokud ses na to pripraven je otazka par minut - vpodstate jen premountovat disky, jenze vykon klesne rekneme o 10% (!pokud na stejnym stroji nepobezi nic jinyho!).
Ty si muzes dovolit mit na virtualu dvojnasobek vykonu nez potrebujes ? Abych moh provozovat virtualne SQLko pri odpovidajicim vykonu, potreboval bych tudiz virtualizovat stejne odpovidajici vykon => na zeleze bych nic neusetril, naopak by me to stalo licence na ESX. Stejne tak bych na tom nebyl onic lip v pripade vypadku zeleza (umim nastartovat v ESXu primo backup libovolnyho fyzickyho stroje, staci ho primountovat).
+ jako bonus narazis pri virtualizaci na to, ze ne vsechno funguje - napr se kolegum pokud vim nepovedlo rozchodit seriovej port, ac ho zelezo ma, z virtualu se na nej dostat nejde.
O 10% kdyz na tom nepobezi nic jineho by u novych serveru (procesoru) s plnou podporou virtualizace mohlo byt.
Problem je nekde jinde, pokud se na virtualy nastavuje vic jak 2 procesory a 4GB RAM a jsou to vytizeny servery jako SQL nebo exchange, vmware uz pro to proste neni a ten narust vykonu neni jak by mel byt.
Alespon tolik z pozorovani realnyho produkcniho prostredi.
IBM, 3GHz Xeon (Tulsa), 32GB RAM, to cele 2x ve vmware clusteru, FC storage.
I kdyz je pravda ze ted prikoupenej server by na tom mohl byt lepe, ale brzo na nejake srovnani.
Nekdy pred rokem jsem videl benchmarky Xenu a procesorovy vykon byl pomalejsi v radu procent, tech 10% mi uz pripada docela dost. Samozrejme se jedna o paravirtualizaci, plna je o vyrazne pomalejsi.
napr. tady to je cca 2%: http://www.open-mag.com/00133844936.shtml
Procesorový je ten nejmenší problém. Já bych se fakt divil, kdyby počet transakcí za sekundu byl u virtuálního stroje nižší jen o 10 % oproti fyzickému počítači, protože jsem to zkoušel měřit, ale na o dost slabším hardwaru (určitě jsem neměl FC diskové pole), proto se raděj o čísla moc netahám a jenom se divím.
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.
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...
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)
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.
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 %.
Pod jakym OS a s jakou virtualizaci? Pravda je, ze jsem ted lehce zagoogloval a dost lidi pozoruje zpomaleni diskovych operaci pod xenem...
tak treba na linuxu je propad diskovych operaci brutalni u vsech nastroju vyjma openVZ. Taktez pri plne virtualizaci je brutalni propad na NIC.
Smysl je ten, ze to pole by bylo k tomu vyhrazeny tak jako tak (uz jen kvuli mistu), s tim ze ale na tom serveru muze bezet par dalsich stroju ;-) S vyuzitim dalsi vyhod vmware clusteru, jako je DRS a HA, porad s tou jednou diskovou polici.
Samozrejme to neni nesmi byt pripad, ze by i ten jeden VM hranicil vykonove s moznostmi HW toho serveru, pak to skutecne nema smysl.
Jenže buď se bavíme o maximálním výkonu, pak virtualizace ne, a nebo se bavíme o dostupnosti, pak je to jedno a virtualizace je vhodná.
Pro kombinaci obojího navrhuji dedikovaný stroj a failover cluster proti virtuální mašině, kde na maximálním výkonu už tak nesejde... hlavně, že to běží :-)
Ten cluster je trosku problem, na windows 2008, ktery podporujou jen urcity storage, ktery dostat do ESX zrovna moc nejde. Ale to uz bych zachazel do moc podrobnosti ;D
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.
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.
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 ;D
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.
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.
Tak pravdu mají IMHO všichni, ale každý myslí na trochu jiný segment a jinou aplikaci.
HollyG měl pravdu, když mi na ICQ psal, že tahle diskuze se zvrhává někam do hospody k pivu ;D
Jak rika Marty.
Jinak ja s tim taky naprosto souhlasim, jen diskuse o trochu vyse se stocila k tomu, zda ty nejnarocnejsi servery maji smysl provozovat na virtualnim prostredi, k tomu taky smerovalo ono blade/FC/whatever reseni, kde ma smysl uvazovat zda mi to vezme 10% vykonu navic oproti provozu primo na zeleze ;-)
Akorad nejuzsim hrdlem se ted nestavaji procesory, ale velikost RAM, ktera je pri virtualizaci at uz v SOHO nebo enterprise proste porad maaalo :)
I kdyz ono kdyz se na jeden server naseka xy virtualnich, taky uz to neni idealni, i primo vmware doporucuje tak max kolem 10 serveru na jeden fyzickej.
Ono co se pole tejce, jeho cena cca 10x preleze cenu serveru. Pole potrebujes pokud chces ten cluster, ale jinak bud proto, ze potrebujes vykon nekolika diskama nedosazitelny nebo proto ze potrebujes obrovkej prostor.
Mimochodem, 4 SSD nahradej vykonem (IOps) cca 60 disku (oboji R10). Mam informace, ze to takhle uz leckde kupujou, je to vyhodny i cenove, a to pres to, ze 1 SSDcko te bude stat 1/4MKc.
já souhlasím s tím pivem ;)
Nevim co je na tom pravdy, ale podle http://www.cdr.cz/a/26452 bude pri mnoha nahodnych zapisech (typicky DB) na SSD vznikat vnitrni fragmentace a vykon (otazka zda i IOps) pujde drasticky dolu. Kazdopadne ja osobne bych SSD na databazi v zadnem pripade nenasadil, leda nejaky RO pristup..