esx != esxi. esx ma konzolu, esxi nie.
Printable View
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
Cokoliv co tady zaznělo, kromě openVZ/Linux-VServer a případně jejich derivátů.Citace:
Původně odeslal SonnY
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).Citace:
Původně odeslal Jezevec
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.
Jasně, to jsem uved jen jako příklad... SQLko do virtuálu asi fakt ne. To už bys tam pak mohl šoupnout fileserver ;DCitace:
Původně odeslal Jezevec
Preco nie?Citace:
Původně odeslal Marty
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 ;)Citace:
Původně odeslal Marty
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í.Citace:
Původně odeslal Marty
Připojení storage NAS, HP EVA, Centery, Celerry, Avamar, atd. a vše bez problémů ;)
Čili není důvod, prečo nie ;)Citace:
Původně odeslal SonnY
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 ;)
Ne "něco jako", oni používají VMotion ;)Citace:
Původně odeslal Marty
A s fyzickými servery jsem tě špatně pochopil, takže MEA CULPA ;)
Tak teď pleteš jabka s hruškama ty. Ale nebudem se chytat za slovíčko, žejo :)Citace:
Původně odeslal xvojta
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 ;)Citace:
Původně odeslal Marty
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...Citace:
Původně odeslal xvojta
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 ...Citace:
Původně odeslal xvojta
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.