VMware ESX 3.5 és a Microsoft Hyper-V összehasonlítása

Címkék

Lepenye Tamás kollégám blogján immár 12 részletes cikk foglalkozik a két virtualizációs technológia részletes, objektív összehasonlításával. Abban szerettünk volna segítséget adni, hogy a két megoldás közti különbségekről szóló szakmai beszélgetésekhez támpontokat adjunk. A legfrissebb cikk itt. Az alján ott a link az összes korábbira is.

Hozzászólások

Ezt terveztem en is blogkent bekuldeni, de feltem a flame-tol. Hat meglassuk, most mi lesz.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A blog nagyon jó,kár hogy a Xen kimaradt (igaz utalás van rá több helyen). A Red Hat is szállít Virtualizációs megoldást (igaz jelenleg ez a Xen-re épül), de a Qumranet megvásárlásával már saját megoldása van. Ezt össze lehetett volna vetni a másik kettővel. A Xen igaz nem Ubuntun hanem Red Hat -on azért előfordul nem amatőr rendszerekben is: http://www.redhat.com/about/news/prarchive/2008/scania.html

Mi a cikk lényege? Hát hogy a KVM mindkét HV-nál jobb, mert Linus is megmondta. :)

--
Q: What's the difference between Lem's Solaris and Sun's Solaris?
A: One's an alien presence that drives all who encounter it mad, and the other one's been made into a movie by Andrei Tarkovsky.

Igen, az ESX olyan, a Hyper-V-ből hiányzó tulajdonságait állítja be "szinte lényegtelennek", amit egy olyan ember se nevezne annak, aki használja is, és a Hyper-V olyan tulajdonságait nevezi "forradalmi, áttörő" -nek, ami a kutyának nem kell. Ezzel nincs semmi gond, biztosan lesz jó néhány ember, akit ez a pártatlan összehasonlítás ismét meggyőz, én csak annyit tudok, hogy egyelőre nem látom az iparban a mozgolódást, azok érdeklődnek a Hyper-V iránt, akik eddig is Windows-oztak. Arra teljesen jó (DRS+Vmotion-mentes környezetben), talán leveri egy picit a vmware árakat.

Jaj, Istenkém! :I

Ha lenne egy kis humorérzéked és/vagy látnád a hozzászólásom végén a smiley-t, akkor rájönnél, hogy egyáltalán nem gondoltam komolyan azt, amit leírtam.

Mellesleg személy szerint pont az a bajom a dologgal, amit itt utánad már többen is leírtak: microsoftos ember írta, ezért by default nem tudom pártatlannak venni. Nem azért, mert kételkednék eme szándékban (bár az MS előéletéből adódóan erre lenne okom), hanem azért, mert nem vagyok meggyőződve arról, hogy a szerző pl. egy Unix/Linuxon futó VMware ESX szerverre is szerzett annyi és olyan komoly üzemeltetési tapasztalatot, mint a Hyper-V-vel.

--
Q: What's the difference between Lem's Solaris and Sun's Solaris?
A: One's an alien presence that drives all who encounter it mad, and the other one's been made into a movie by Andrei Tarkovsky.

1) Lepenye Tamas nem olyan regen dolgozik a Microsoft-nal, eddig MS-tol teljesen fuggetlen cegnel dolgozott, kabe egy-masfel eve ment at.
2) Ha venned a faradsagot, es vegigolvasnad, sok helyen kiemeli, hogy ebben meg abban bizony-bizony az ESX a jobb. Es nem ugy mondja, mint akinek a fogat huzzak.

Ettol fuggetlen valamennyire muszaj vedeni a munder becsuletet, mert az sehol nem veszi jol ki magat, hogy az az ember, aki a kommunikacioert felel, a ceg termekeit fikazza nyilvanosan - meg ha ezt a blogjaban teszi is.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ezzel a gondolkodasmoddal ezen az oldalon nagyon sok ember nem tekintheto elfogulatlannak.

Termeszetesen ezzel nem azt mondom, hogy ugy kell a szavaira tekinteni, mint szentirasra, nyilvan vannak dolgok, amiket fenntartassal kell fogadni, reszben azert, mert nem ert a VMware-hez, reszben azert, mert az MS megoldasokat jobban ismeri.

Ezzel egyutt azonban enszerintem nem a legjobb dolog barkirol, akinek a nevjegyen a Microsoft szerepel, mint munkaltato, kijelenteni, hogy agymosott hulye. Marpedig itt a legtobben - ha nem is mondjak ki nyiltan - igencsak ilyen felhanggal kommentelnek.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

az idok folyaman tett rola az MS, ha egy MS szaki ( jelen esetben egy MVP ) hasonlit ossze MS es !MS termeket, akkor alapbol ketkedjek a partatlansagaban.
sorry evvan.

en ezt nem mondtam.
felolem erthet az MS termekekhez, nem a szellemi kepessegeit minositettem. sot. MVP tehat hivatalbol jol kell ertsen hozza.

ha egy MS alkalmazott, aki abbol el, hogy MS termekeket ad el, es supportal, ir egy ilyen osszehasonlitast, akkor az elfogultsag vadja még lehet meg is all.

ui
ha VMWare alkalmazott irta volna, akkor is valoszinu huznam picit a számat.

Elolvastam. CSeppet sem pártatlan. Olyan dolgokat bagatelizál, amik valóban fontosak, és elfelejti felhívni bizonyos "apróságokra" a figyelmet. Két ilyet említenék:

- A Hyper-V alatt Windows 2008 fut, amit patchelni kell és újra kell indítani havonta egyszer. Mivel quick migration != vmotion, az újraindítás előtt az adott fizikai szerverről elmozgatott virtuális oprendszerekről mindenképpen leszakadnak kliensek (néhány percre). Azaz hiába nem volt hardver hiba, 100%-kos rendelkezésre állás nem hozható Hyper-V-vel. ESX-nél ez nem csak hogy megoldható, de tudomásom szerint olyan patch sem jött ki még hozzá, ami miatt újra kellett volna indítani a szervert.

- Hyper-V alatt nem lehettséges resource grouppokat definiálni, azaz 1 host képes leültetni akár az egész fizikai szervert.

Miért, azt nem kell patch kedden patchelni? Ki ad utána supportot rá, amikor nem standard telepítés?

De hagyjuk, mert ez nem oldja meg a resource grouppok kérdését (nálunk a CIO ez alapján számláz cégen belül az egyes ágazatoknak), a dinamikus memória-kezelésről nem is beszélve (mert a cikkel ellentétben ESX alatt el lehet venni illetve vissza lehet adni egy virtual hostnak memóriát, erre való a lufi driver).

Magam részéről úgy látom, hogy a Hyper-V egyetlen előnye, hogy a vmware ESXi ingyenes lett miatta.

Ez a patch-kedd miatti ujrainditas szvsz baromsag. Nem mondom, hogy a Windows-t nem kell patchelni, de ez update politka kerdese, hogy mikor teszed fel es mely patcheket. Nyilvan, aki nyaklo nelkul engedi felmenni a patcheket eles rendszerre, plane teszteles nelkul, annak bizony sokszor borul a bili. Persze ehhez erteni kell, meg tesztelni kell, meg... egyszoval dolgozni kell vele.
Siman lehet amugy olyan upgrade policy-t csinalni, amiben havi szintre lebontva tudsz legalabb haromkilences rendelkezesre allast biztositani. Amugy meg szaz szazalekos rendelkezesre allast jelenleg semmivel sem lehet biztositani, mert aramszunet, netszakadas, egerragta kabel barmikor elofordulhat.
--

resource group: ez igaz, viszont nem feltetlen kell leultesse a szervert. A SCOM eleg sokmindenre jo, tobbek kozt elszabadult processzek kilovesere is. Ami gaz, az mindossze annyi, hogy linuxos agent egyelore nincs.


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Elolvastad, amit johans írt? Nem tudod upgradelni se, mert nincs vmotion (ami szerintük nem is kell), hogy átpakold a gépeket. Tegyük is félre a nagy rendelkezésre állású dolgokat, nézzük azt, aminek csak úgy futnia kéne: a vmotion átállási ideje pont belefér, hogy a kapcsolódó alkalmazások, emberek, stb ne fossák össze magukat. Van, ahol ha 10 percre kiesel, alkalmazások, partner szolgáltatások sora borul el, itt most megint nem a HA cuccokról beszélek (bár lehetne arról is), hanem egyszerű backend szolgáltatásokról, tehát a kiesési időbe még bele is férhet, na de ki adna pénzt egy olyan dologért, ahol ezt az egészet havonta el kell játszani. Ennyi erővel lehetne fizikai szerveren is azt' átraknád a diszket hibernálás után (majdnem).

Ez a SCSI fencing commandos cucc kurva jó alkalmazásszintű clustereknél, ott pont így kell csinálni, de szerintem nem itt.

Hat nem is tudom, cegek eddig hogy a mennydorgos istennyilaba migraltak gepeket minimalis leallassal vmotion nelkul.

Nem mondom, hogy a vmotion nem jo dolog, de konyorgom, HA rendszerek eddig is voltak, amikor meg a hyper-v megcsak kosza gondolat sem volt a szelben! Emberek eddig is csinaltak kritikus atallasokat es uzemeltettek HA rendszereket, vagy ez a tudas a hyper-v megjelenesevel gyokeresen elveszett?

Igen, vannak dolgok, amik penzbe kerulnek, vmotion-t is lehet szerezni - penzert. A virtualizacio amugy is eleg nyagy penznyelo a gepek minosege miatt, a HA megintcsak nem a csoringerek technologiaja.

Amugy meg a vilagon senki nem kotelez senkit a Hyper-V vagy az ESX hasznalatara, egyszeruen csak be vannak mutatva feature-k ebbol meg abbol. Nyilvan, mivel a cikk a Hyper-V bevezetese utan kozvetlen jelent meg, a termek szolgaltatasai jobban ki vannak domboritva, mint a hibai - de te sem teszed az ablakba az ESX osszes letezo hibajat ha el akarod adni valakinek.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Na most a hir bekuldoje Budai Peter, a Microsoft Magyarorszagtol, kollegaja gondolom szinten ugyanott dolgozik (de ha nem, akkor sem lesz fuggetlen szakember) - ami nem baj, csak tudni kell, hogy ezeknek az embereknek az a dolguk (legalabbis reszben), hogy a sajat portekajukat dicserjek.
Hogy miert itt a HUP-on az szamomra rejtely.

- Use the Source Luke ! -

Hittéritőkkel még nem találkoztál? Akik a jövedelmed vagy vállalkozásod egy részéért helyet bérelnek neked a menyországban?

Másrészről: Nyitott gondolkodás kell, nem szabad szemellenzővel szemlélni a világot, főleg nem olyan területen ahol gyorsan történnek az események.

Oke, akkor utaljuk az osszes linuxos hirt is, hiszen ez UNIX portal! LOL.
Azert mert te utalod az MS-t, mas esetleg erdeklodhet a MS termekei irant. Ha nem is teljesen elfogulatlan a cikk, arra mindenkeppen jo, hogy a Hyper-V nehany tulajdonsagat kozelebbrol is bemutassa, mas szemszogbol, mint ahogy eddig tettek.

Kulonben meg meg mindig ervenyes az, hogy ha nem erdekel egy cikk, a vilagon senki nem kotelez az elolvasasara, a hozzakommentelesere meg foleg. Amennyire tudom, mar minden bongeszon van lehetoseg a fulet bezarni.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Azért küldtem be ezeket az írásokat nektek, mert kb. két hónapja volt erről egy hosszabb szakmai beszélgetésünk itt, és szerettük volna, ha teljesebb képet lát mindenki - mindkét oldalról megközelítve. Természetesen minden szentnek maga felé hajlik a keze, de Tamás talán a legpártatlanabb szaki az MS-nél, akit ismerek.

Budai Péter
TechNet programmenedzser
Microsoft Magyarország
http://www.microsoft.hu/technet

Nekem nem igazán a pártatlanságával volt problémám. A neten lehet találni sokkal elfogultabb/elvakultabb írásokat is. Elég korrekt azokhoz képest.
De azt nehezem emésztem meg, hogy például szerinte a VI-ba integrált nic teaming az kevésbé jó, mint a különböző hw gyártók által kiadott utility.
Valamint (bár ez nem csak ebben a témakörben nagy vita tárgya) mikro/monolitkus kernel és a driverek. És miért rosszabb az a driver, amit a VMWare patchel/tesztel, mint amit hw gyártó ad ki Win serverekhez?

Továbbá - bár ezt elég jól kitárgyalja abban a bejegyzésben, de mások folyton ezzel jönnek - a hw támogatottság. Nézte már valaki HCL-t ESX-re? Nem nagyon találni olyan aktuális brand servert amit ne támogatna. Szinte az összes elterjedt server komponenst támogatja, még alaplapi nvidia hálókártyát is:)

Még egy utoljára: a hypervisor mérete igen is számít. Jó dolog, hogy egy szervert merevlemez és esetleges RAID kártya nélkül tudok összeállítani. Nagyobb brand gyártók sorozatban kínálják így a gépeket(pl.: IBM x3850 M2, azt nem tudom szállít-e valamelyik cég Hyper-V megoldást ilyen formában). Persze SAN-ról is lehet bootolni, akinek az tetszik, de egy rossz zónázással bajba tud kerülni az ember.

a citrix xenservert nem lett volna erdemes osszehasonlitani a masik ket termekkel?

Lehet, egyedül vagyok a bénaságommal, de ez a link nekem rohadtul nem akar bejönni.
Valami login.live.com-ra írányít át.
flame://Most akkor amíg nincs msn azonosítóm, addig nem nézhetem meg a cikket?!
Csak ezért inkább nem lépek be.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Minden tiszteletem a blog írójának, ismerőseim szerint egy nagyon jó szakember, de egy picit érdekesen nézi a dolgokat. Egy két dologban jobbnak írja az ESX-et, de aztán mégis ugyanott Hyper-V a nyerő. Valamint az ESXnél, megjegyez olyasmit hiánynak amit a Hyper-V sem tud.

Szerintem egy kicsit eléggé alul értékeli a VMotiont. Az, hogy nem biztos végrehajtódik elég kicsi az esélye és szerintem ott már egy Quick Migrationt sem lehet megcsinálni. Arról nem is beszélve, hogy VMotion használatakor lehet a MS féle módszerrel is migrálni. Ez ebben az esetben is minimális kieséssel jár. Szerintem a -a szerző számításával élve- QM-nél sem lehet megbecsülni a szükséges időt, mert ez a művelet sokban függ a hálózat és a SAN sebességtől.

Egy kicsit az az értésem, kkv szinten próbálta összehasonlítani a két rendszert ("Az ESXi célpiaca inkább a kis- és középvállalatok."). Ha egy picit nagyobb méretekben gondolkozna, rájönne, hogy a VMotion, HA(akár guest heartbeat monitorral), DRS nem is olyan alábecsülendő. Nem beszélve egy esetleges shared environmentről több ügyféllel, ahol a Port Groupok elengedhetetlenek.

Ráadásul a MSnak eléggé fel kell kötnie a gatyát a VI4 megjelenése után, mert vannak benne elég nyálcsorgató ficsörök. Mint például a fault tolerance, ami minimális plusz erőforrással egy másik hoston is futtatja a megadott virtuális gépet és ha az eredeti host kiesik akkor sem érzi meg a gép. Valamint ilyen apróságok még mint distributed switchek, host konfigurációs profilok. Egy olyan környezetben ahol 10-20+ host van ezek igazi áldások. Valamint végre integrálják a GUI-ba a Storage Vmotiont.

Sziasztok!

Lepenye Tamás vagyok, én írtam a cikkeket. Engedjétek meg, hogy néhány megjegyzést tegyek a témához, illetve az itteni hozzászólásokhoz.

A cikksorozatot valóban a hup.hu egyik flame kategóriájú bejegyzés (m$ aranyköpés) után indítottam, mert úgy láttam, hogy elég nagy az ismerethiány és a félinformáció/féltudás a témában. Eredetileg csak a Quick Migration-t és a VMotion-t szerettem volna összehasonlítani, de mivel csak lógott volna a levegőben, inkább nyakamba vettem a teljes alapplatform összehasonlítását. A szándékom az volt, hogy azok, akik virtualizációba fognak, a korábbinál mélyebb, alaposabb képpel rendelkezzenek. A cikksorozat első körében írtam az elfogultság esetleges vádjáról, ma is tartom magam ehhez:

“Nos, a webnaplóból mindenki tudja, hogy a Microsoftnál dolgozom, ezért aztán, ha úgy tetszik, lehet majd legyinteni az elkövetkezedő írásokra, hogy részrehajló, hiszen egy MS alkalmazott írta. Ezzel együtt megpróbálok mindent elkövetni, hogy objektív és elfogulatlan összehasonlítást írjak, már amennyire ez lehetséges.”

Ügyfelektől és VMware mérnököktől kapott visszajelzések alapján úgy gondolom, érdemes volt a sorozatot megírni, függetlenül a munkáltatóm kilététől.

A Xen hiányát én is sajnálom, a dolgok azonban aligha alakulhattak volna másképp. A cikkeket hosszas irodalmazás előzte meg mindkét termék vonatkozásában, és amint látjátok, így is fél évig tartott (és még nem fejeződött be) a publikálás. A Xen behozása a képbe még inkább lelassította volna a cikkek megjelenését és az egész próbálkozás hiábavaló lett volna. Ha visztont van köztetek olyan mérnök, aki ért a Xen-hez és szívesen ír, elolvasnám és az ő értékelését.

A módszertanról annyit, hogy a cikk után mindig írtam egy összefoglaló táblázatot zölddel kiemelve az tulajdonságban a jobb értéket, pirossal a rosszabbat. A táblázat soraihoz viszont nincs súlyérték rendelve méghozzá azért, mert minden ügyfél/környezet/projekt mást és mást tarthat fontosanak. Van, akinek lényeges, hogy hány virtuális gép futhat maximum egy hoston, mások számára ez legfeljebb érdekes adat. Van, akinek fontos a Port Grouping, és nagyon sokan vannak, akinek nem. Apropó Port Grouping:b a 6. körben filozofálgattam róla, hogy mire is való. Úgy próbáltam körüljárni, hogy látható legyen, mi a haszna a meglétének vagy mi a kára a hiányának. Különösebb megjegyzést nem kaptam, de ha úgy érziktek, valamit nem vettem észre, vagy nem vettem figyelembe, akkor írjatok megjegyzést a cikkhez.

Az egyes összehasonlítási szempontokat igyekeztem kifejteni: miért került a termékbe, hogyan érdemes vele bánni, kinek lehet hasznos stb. stb. Ha ez alapján úgy gondoltam, ez vagy az csak keveseket érint, nos, az vita tárgyát képezheti, bátorítok mindenkit, hogy írja meg a véleményét. Akár a blogon, akár itt, szívesen válaszolok.

Johans megjegyzéséhez (2008. december 3., szerda - 14:39).
A hotfixek számáról és egyéb karbantartási feladatokról valóban nem írtam még eleget, de a 10. részben azért érintettem. Már csak azért is, mert itt elemztem a Vmotion és a Quick migration hatását a rendelkezésre állásra. Mit szólsz az Excel táblához? Látható belőle, hogy mit old meg a VMotion, és mit nem. Ami az ESX javítófoltokat illeti, már több mint száz van belőlük, és jópár újraindítást is igényel. A VMware VI része egyébként egy Update Manager is a frissítések terítésére.
A Resource Pool-okról szintén csak érintőlegesen foglalkoztam a 2. körben. Ennek egyszerűen az az oka, hogy ez a menedzsment témakörbe tartozik és még nem került rá sor. Az viszont tévedés, hogy a hyper-v egyetleg vendéggéptől lefeküdhet. A 2. körben még a dialógus ablakokat is kitettem, ahol látható, egészen hasonló módon lehet a két rendszert konfigurálni. A 7. körben pedig arra jöttem rá, hogy az ESX I/O multipath terheléselosztása jóval gyengébb, mint a hyper-v-é. Bevallom ezen én is meglepődtem.

( johans | 2008. december 3., szerda - 18:18 )
”De hagyjuk, mert ez nem oldja meg a resource grouppok kérdését (nálunk a CIO ez alapján számláz cégen belül az egyes ágazatoknak), a dinamikus memória-kezelésről nem is beszélve (mert a cikkel ellentétben ESX alatt el lehet venni illetve vissza lehet adni egy virtual hostnak memóriát, erre való a lufi driver).”
A 3. körben foglalkoztam a memória-túlfoglalás témakörével. Nem állítottam, hogy ESX alatt nem lehet elvenni és visszadni virtuális memóriát a virtuális gépeknek.

( hrgy84 | 2008. december 3., szerda - 18:27 )
resource group: ez igaz, viszont nem feltetlen kell leultesse a szervert. A SCOM eleg sokmindenre jo, tobbek kozt elszabadult processzek kilovesere is. Ami gaz, az mindossze annyi, hogy linuxos agent egyelore nincs.
A 2. kör alapján a hyper-v sem tétlen a területen. SCOM Cross-platform agent a jövő év első félévében várható, jelenleg még béta állapotban van, de aki akarja, kipróbálhatja.

( Mico | 2008. december 3., szerda - 19:34 )
Elolvastad, amit johans írt? Nem tudod upgradelni se, mert nincs vmotion (ami szerintük nem is kell), hogy átpakold a gépeket.
De igen, lehet frissíteni a hostokat, mert van Quick Migration. A 9. cikkben írtam le, miért tartom a két technológiát összehasonlíthatónak,  10 cikkben pedig azt, hogy ez milyen mértékben érinti a rendelkezésre állást.

( hassan | 2008. december 3., szerda - 22:49 )
De azt nehezem emésztem meg, hogy például szerinte a VI-ba integrált nic teaming az kevésbé jó, mint a különböző hw gyártók által kiadott utility.
Ilyet nem is írtam. A 6. cikkben volt szó a NIC Teaming-ről. A táblázatos konklúzió az volt, hogy NIC Teaming mindkét rendszerben van, de integrált NIX Teaming csak az ESX-ben. Azért fontos ez a megállapítás, mert az kering a neten, hogy nincs NIC teaming a Hyper-V-ben.

( hassan | 2008. december 3., szerda - 20:35 )
Egy két dologban jobbnak írja az ESX-et, de aztán mégis ugyanott Hyper-V a nyerő. Valamint az ESXnél, megjegyez olyasmit hiánynak amit a Hyper-V sem tud.
Megesik, hogy bizonyos tulajdonsággal szoftver rendelkezik, a másik meg nem. Néha meg fordítva. Egyetlen táblázat-bejegyzés van, ahol az ESX-re azt írtam “Nincs”, a hyper-v-nél meg azt, hogy megvalósítható, de ez mutatja meg a PRO keretrendszer jellegét, ami az MS stack erőssége. Lehet, hogy már most van ilyen PRO-tip, de erről nincs pontos információm. A potenciál megléte/ meg nem léte viszont fontos információ. Vagy te másik sorra gondoltál?

Üdv:

Lepenye Tamás

Szervusz Tamás!

A beépített dolog/3rd party dolog csupán azért szúrja a szemem, mert ennyi erővel a VI-hoz készített plugineket is fel lehetne sorolni az ESX-hez. Nem mondom, hogy egy 3rd party alkalmazás rosszabb, mert például pont azt ESX-nél az SVMotion pótolja a Storage VMotion hiányosságát.
Amit johansnak írtál a patchekről: többek között itt jön elő a VMotion előnye a QM-nel szemben:
kiesés nélkül migrálja a gépeket update előtt a hostról a vmeket, updateel és újraindít. A vm-ek/kliensek meg sem érzik. Míg ez QM-el mindegyik guestnél egy kis kiesés. Ezt te is leírtad az egyik fejeztben, bár ott úgy tűnt nem igazán tartod jelentősnek(amit meg is értek, mert ízlések és pofonok különbözőek, de az ügyfél az első -általában :)).

Az I/O problémára nagyon jól rávilágítottál az ESX kapcsán. Nagyobb rendszereknél égető probléma. Nem is olyan régen futottunk bele mi is egy rosszul megtervezett VI kapcsán.

Amúgy írásod eléggé hiánypótló volt magyar nyelvterületen, bár azért látszik hogy a Hyper-V-t jobban ismered(nem meglepő :)). Számos olyan tulajdonságát megismertem a Hyper-V-nek amivel eddig nem voltam tisztában, mert ESX-el foglalkozom. És a közeljövőben nem esélyes az átnyergelés.
Jó lenne egy magyar virtualizációs oldal, ami esetleg cégtől függetlenül adna infókat különböző technikákról.

Mit szólsz a VI4 újdonságaihoz? Ezek közül várható valami a Hyper-V-ben is?

Mivel megszólítottál, válaszolok.

ESX3.5 patchek. 8 kritikus patch-set jött ki az idén. Ezek újraindítást igényeltek. Ráadásul ebből is volt 2 olyan, ami elég gyorsan jött ki egymás után ahhoz, hogy össze lehessen várni a tesztelések során.

A patchek felrakása nem okozott szolgáltatás kiesést. Egyetlen másodpercet sem.

Amit írsz a 10. fejezetben - elnézést, nem szoktam vulgáris lenni, de erre nincs jobb kifejezés - a takony cukrozása. Egyrészt irreálisak az adatok, rendelkezésre állásra manapság a 99,5% - 99,7% a normális elvárás, méghozzá az applikáció szintjén, 93% meg 95% -os rendelkezésre állás már 8 éve sem volt elfogadható a legtöbb business kritikus alkalmazás esetén.

Másrészt a "Mennyire gyors?" táblázat egy merő fikció: ha valaki utánaszámol, a táblázat szerint a memóriát lementeni és visszatölteni a fizikai hordozó elméleti maximum sávszélességével lehet, késleltetés nélkül. Nincs protokoll overhead, a storage felé senki más nem forgalmaz, egyetlen más virtuális gép sem fut hostoló oprendszeren, aki szintén nem akar a storage felé forgalmazni semmi mást (a közbeeső switchekről és directorokról nem is beszélve). Ja, és a storage nem diszkre írja az adatokat, hanem teljes egészében cache-be. Én sajnos a mátrixon kívül élek, a való világban 8 giga adat diszkre írása és visszaolvasása közepesen terhelt SAN és storage esetén 1,5-4 perc, és nem 32 másodperc. És ugye ezt nem egyszer, hanem kétszer kell eljátszani egy karbantartás alatt, mert vissza is kell kerülniük a helyükre a guest os-eknek.

A memóriára vonatkozó rész: úgy emlékeztem, hogy van valahol egy olyan mondat az anyagban, hogy sem processzorok számát, sem a memória méretét nem lehet megváltoztatni a guestnek, ezen mindkét megoldásnak lenne mit javítania. Most újra átfutva ezt nem találom, ha tényleg nincs benne az anyagban akkor elnézést kérek, írjuk az év végi nemalvás számlájára.

(megjegyzem a támogatott memória menyiségnél leírtak szintén eléggé elrugaszkodottak a mindennapok valóságától. Tudomásom szerint elvétve van olyan intel szerver, amibe 256GB-nál több memóriát lehet rakni, és ha lehet, akkor ezt 8GB-os vagy nagyobb modulokból kell megtenni, ami heroin árban van. A cégcsoport, ahol dolgozom több, mint 500 gépen futtat ESX-et - ezeknek csak kis része tertozik hozzánk - , és a "standard" ESX konfiguráció 4x4 core, 64 vagy 128 GB memória. Egészen egyszerűen ez egy olyan kiegyensúlyozott konfiguráció, ami pénzügyileg is megéri.)

Az viszont tévedés, hogy a hyper-v egyetleg vendéggéptől lefeküdhet.

Én meg inkább azt mondanám, hogy nem csak a hyper-v feküdhet le egy vendéggéptől, hanem bármelyik virtualizációs megoldás... Egy guestből kihasználható hypervisor/host-kernel/hardver sebezhetőségtől bármelyik megdögölhet, rosszabb esetben akár a guest-ből való kitörésre is alkalmas lehet.

 

(hassan | 2008. december 4., csütörtök - 17:43 )

A beépített dolog/3rd party dolog csupán azért szúrja a szemem, mert ennyi erővel a VI-hoz készített plugineket is fel lehetne sorolni az ESX-hez.

Azt gondolom, hogy bizonyos feltételek mellett harmadik gyártó megoldása is bekerülhet az összehasonlításba. A feltételek:

1. Ne növelje az árat, legyen ingyenes.

2. Tüntessük fel (tüntessem fel :-)), hogy nem beépített megoldás, és jelezzük a támogatást jellegét a platform tulajdonosa részéről.

3. Legyen támogatás a harmadik gyártó részéről: verziózás, hibajavítás stb. Egy weboldalra feldobott script például nem valószínű, hogy ilyen. Ezt azért tartom fontosnak, mert ebben az esetben vállalati környezetben is bevezethető a kiegészítés.

Az általam említett  NIC teaming a fenti feltételeket teljesíti. Ha a későbbiekben úgy esne, hogy egy ingyenes VI plug-in elkerüli a figyelmemet és emiatt “lepontoznám” az ESX-et, akkor jelezzétek nekem megjegyzésben, és javítani fogom a cikket.

 

kiesés nélkül migrálja a gépeket update előtt a hostról a vmeket, updateel és újraindít. A vm-ek/kliensek meg sem érzik. Míg ez QM-el mindegyik guestnél egy kis kiesés. Ezt te is leírtad az egyik fejeztben, bár ott úgy tűnt nem igazán tartod jelentősnek (amit meg is értek, mert ízlések és pofonok különbözőek, de az ügyfél az első -általában :)).

Egyszerűen nem ért semmit, amit a témán dolgoztam, ha ezt írod. Komolyan az látszik a cikkből, hogy én a mundér becsületét védem? Nem hiszem el! Ha a QM-et mentegetném, akkor az lenne a gondolatmenetem, hogy “na, jó, első lépésnek megteszi, de majd nézzétek meg a Win 2008 R2-t, stb. stb.” Nem, nem, nem.

 

Azért készítettem azt az Excel táblát, hogy kiderüljön, milyen hatása van a VMotion-nek és a QM-nek a rendelkezésre állásra. Johansnál is kiverte a biztosítékot a 93%-os rendelkezésre állás, nos, éppen az ilyen szélsőérték mutatja meg, hogy miről is van szó. 50 gép, amely egy szolgáltatást alkot. Ha egy gép kiesik, megáll a szolgáltatás. (Tudom én, hogy a valóságban ilyen nincs, de nézd ezt úgy, mintha egy nagyító lenne.) 50 gép, és mindegyik Vmotion-nel költözik, a VMware a szívét is kitette, minden mozgatás sikerül stb. stb. És mégis, a számított rendelkezésre állás 95,37. Miért? Hát azért, mert minden VM-ben karban kell tartanod az OS-t, meg az azon futó rész-szolgáltatás komponenst és esetleg újra is kell indítanod. Megtett mindent a Vmotion, amit lehetett? Igen. Elég ez? Nem. Ezért nincs a valóságban ilyen. A valóságban az van, hogy az 50 kiszolgálós rendszer valójában 100 kiszolgálós, hogy a rész-szolgáltatásoknak legyen tartalékja arra az időre is, amig az OS-t karban tartod. Na, most képzel el, hogy minden rész-szolgáltatás redundáns. Pl.: nem egy web front-end van, hanem kettő. Az egyik gazdagépet, amelyiken az egyik web front-end VM fut, le kell üríteni. QM-et használsz. Átviszed. Kiesik a VM  - és legyen úgy, ahogy Johans írja, mozogjon az a gép 3 percig. Elérhetetlen lesz a virtuális gép? Igen, elérhetetlen lesz. Elérhetetlen lesz a szolgáltatás? Nem, mert a tartalék végzi a dolgát.  Vagyis, a következőket állítom:

 

1. Ha valakinek fontos a rendelkezésre állás, akkor redundánssá teszi a szolgáltatását – függetlenül attól, hogy a virtualizációs rétegben mi történik. A VMotion nem elég. Ebben az esetben viszont már lényegtelen, hogy QM-et, vagy VMotion-t használ.

2. Ha valaki nem teszi redundánssá a szolgáltatását, akkor neki nem fontos a rendelkezésre állás. Ez esetben viszont megint csak lényegtelen, hogy QM-et, vagy VMotion-t használ.

 

A fenti okfejtésből egy dolog maradt ki: mi van akkor, ha maga a virtuális gép léte és működése a szolgáltatás? Akkor fordul elő ez a helyzet, ha a “vas” szolgáltatója és a tényleges, VM-ek hordozta szolgáltatás gazdája egymástól független, vagy azért mert eleve valamilyen hostolás/Outsource stb. helyzetről van szó, vagy pedig azért, mert olyan irdatlan nagy az IT. Nos ekkor a QM könnyűnek találtatik, nem elégséges. Hadd jegyezzem meg: ismerem magyarország 20 legnagyobb árbevételű cégének IT-ját annyira, hogy tudjam, ők nem tartoznak ebbe a kivételbe.

No, ez a véleményem dióhéjban. Erről szól lényegében a 10. cikk. Érdemes tekergetni azt a táblázatot, szerintem tanulságos dolgok jönnek ki belőle.

 

Mit szólsz a VI4 újdonságaihoz? Ezek közül várható valami a Hyper-V-ben is?

Külön cikket szánok neki, remélem még decemberben eljutok odáig.

 

( johans | 2008. december 4., csütörtök - 18:36 )

úgy emlékeztem, hogy van valahol egy olyan mondat az anyagban, hogy sem processzorok számát, sem a memória méretét nem lehet megváltoztatni a guestnek, ezen mindkét megoldásnak lenne mit javítania.

A negyedik körben írtam ezt: “A virtuális hardver képességeit ugyanakkor még lehet fejleszteni. Egyik gyártónak sem támogatja, hogy a virtuális hardvert működés közben adjuk hozzá, vagy vegyük el a gépektől.” Mindkét gyártó a következő generációs termékében tervezi megjelentetni ezt. Erre gondoltál?

a "standard" ESX konfiguráció 4x4 core, 64 vagy 128 GB memória.

Ezek blade-ek?

 

( Hunger | 2008. december 4., csütörtök - 19:51 )

Egy guestből kihasználható hypervisor/host-kernel/hardver sebezhetőségtől bármelyik megdögölhet, rosszabb esetben akár a guest-ből való kitörésre is alkalmas lehet.

Ez jogos aggodalom, de nem erről beszéltünk, hanem a teljesítmény-igények kordában tartásáról.

Üdv:
Lepenye Tamás

Kedves Tamás!

Először is szeretném megköszönni cikksorozatodat, sajnos nem tudtam még végig olvasni, de igyekezni fogok... :-)

A VMotion/QM kérdéskörhöz annyit tennék most így röviden hozzá: a VMware HA és VMotion lényege elsősorban abban rejlik szerény meglátásom szerint, hogy akár egyetlen VM-mel is megnövekedik a rendelkezésre állás, mindenféle redundancia növelés nélkül (aminek több oldalról is jelentkezik költségnövelő hatása). Ez pedig sok esetben akár elegendő is, úgymond out-of-the-box, néhány kattintással. (valahol erről is szólna a virtualizáció, lásd jövőben megjelenő FT: minek legyen kettő abból, amiből alapvetően egy is elég?)

Hogy egy VM esetén a QM adott esetben nem számottevő rendelkezésre állást csökkenést jelent? Így is fel lehet fogni, de 2010-ig még tovább nőni fog a konszolidálási ráció, ergó egyetlen hipervizor kiesése még több VM leállását eredményezi, ergo a technológia fontossága csak nőni fog, hiszen egy hipervizor leállása sokkal több szolgáltatás, adott esetben több részleg működőképesség befolyásolja, ...
(Még azt is számoljuk bele, hogy a Hyper-V Live Migration még mindig csak 1.0 verziójú lesz.)

Összeségében azért komolyan kiváncsi lennék, hogy 2011-ben valóban mit is fogsz írni a Hyper-V Live Migration technológiáról :-)

DRS szempontból a cikkedben felhozod, hogy VMotion a változás-kezelés hatálya alá esik/eshet: a virtualizáció paradigmaváltása miatt valószínűleg egyebek is változhatnak: könnyen lehet, hogy a DRS általi VMotion nem igényel változás kezelést, hiszen a definíció szerint a VM nem adott ESX-en fut, hanem adott fürtön. Változás kezelést pedig az fog igényelni, ha egy ESX bekerül egy fürtbe/kikerül onnan, illetve ki tudja, hogy hosszú távon mi, ha a Storage VMotion is eljut idővel oda, hogy arra is lesz DRS...

Ha már Storage VMotion is előjött: úgy gondolom a VMware infrastruktúrának nem gyenge jellemzője az már *ma*, hogy fizikai infrastruktúra karbantartás miatt egy VM-nek már nem kell leállnia.

Hasonló terület a memória-túlfoglalás: kiszolgáló VM-ek esetén is lehet komoly jelentősége, ugyanis ha kiesik 1 (2, ...) ESX, nyilván kevesebb fizikai erőforrás marad működtetni ugyanazon VM-eket, de a túlfoglalási képességnek köszönhetően kevésbé kell túlméretezni a rendszert, ez nyilván főleg kevés számú ESX esetén jelentős (mondjuk kisebb cégeknél - lásd célcsoportok kérdéskör! -, ahol 2 vagy 3 ESX vígan biztosít minden szolgáltatást).

Ezen megjegyzéseket nem kötekedésnek szánom, mindössze egyetértek néhány hozzászólóval, hogy valamennyire igyekeztél elsimítani a két technológia közötti különbség jelentőségét - amit természetesen meg is értek (ezért hálátlan szerep valamely cég sapkáját viselve összehasonlítani).

Üdv,

Attila

Szia Attila!

Alapvetően egyetértek veled, néhány dologban azonban kiegészítelek:
"A VMware HA és VMotion lényege elsősorban abban rejlik ..." - A QM lényege is ugyanebben rejlik. A VMware talán ügyesebben csomagol, mint az MS, az ügyfelek sokkal inkább hajlanak a VMware Management csomagjának a megvásárlására (főleg, hogy a VMotion is abban van). Ha valaki SCVMM-mel egészítik ki a hyper-v hostokat, akkor egy VM magas rendelkezésre állásának beállítása szó szerint egy kattintás. És igen, teljesen egyetértek, erről kell szólnia a virtualizációnak.
Egyébként ne legyenek illúzióink: a VMware HA egy kutyaközönséges "shared nothing" elvű cluster, a HW igényei is teljesen egészében hasonlítható az MS Fail-over clusterhez.

"ergó egyetlen hipervizor kiesése még több VM leállását eredményezi" - nagyon fontos, hogy a gépek nem leállnak, hanem megállnak, a memória állapotukat a hypervisor a lemezre menti (Save state). A másik fürtön ebből a "mentett állapotból" éled fel a gép. - Egyéb iránt pedig érvényes az, amit korábban mondtam: ritka az az eset, amikor a VM működőképessége a cél. Többnyire a benne lévő alkalmazásra kell koncentrálni.

"kiváncsi lennék, hogy 2011-ben valóban mit is fogsz írni a Hyper-V Live Migration technológiáról :-)
" - remélem azt fogom írni, hogy bárki, tényleg ingyen, hozzájuthat.

"DRS szempontból a cikkedben felhozod..." - rögtön hozzáteszem, hogy a változáskezelés dilemmája a PRO-ra is igaz. Azért van létjogosultsága a kérdésnek, mert ma még virtualizációs réteg és az alkalmazások kezelése nem természetesen összenőtt dolgok, pedig annak kellene lennie. Mondok egy példát: az Exchange 2007 SP1 egy olyan szoftver, amely támogatott virtualizált környezetben, az SVVP keretében még ESX 3.5U2 alatt is. Eddig remek, de a támogatásnak az is feltétele, hogy a hoston, amin a VM fut, a processzor túlfoglalás aránya nem lehet 2:1-nél több. Mi következik ebből? Az, hogy a DRS/PRO hozhat létre olyan helyzetet, amikor egy Exchange nem támogatott szituációba kerül. Ez pedig gond. Egy ITIL értelemben vett probléma-kezelési folyamatban az lenne a konklúzió, hogy mivel a rendszer automatikusan nem tud ilyen kérdéseket kezelni, ezért a döntést az embernek kell meghoznia a változást pedig "kézzel" kell végrehajtani.

Az lenne a megoldás, ha a DRS/PRO ismerné a VM-en belüli alkalmazást és tudná, hogy ha ez és ez a gép egyik kiszolgálóról a másikra vándorol, akkor az további mozgatásokat kell, hogy indukáljon. A DRS - jelenlegi formájában - erren nem alkalmas. A PRO igen, de a szükséges Management Pack még nem eszerint dolgozik. A Vmware egyébként éppen azért vásárolta fel a b-hive-ot, hogy az ilyen jellegű problémákat meg lehessen oldani.

"úgy gondolom a VMware infrastruktúrának nem gyenge jellemzője az már *ma*, hogy fizikai infrastruktúra karbantartás miatt egy VM-nek már nem kell leállnia." - Igen, ebben teljesen igazad van.

Üdv:

Lepenye Tamás

Szia Tamás!

Ha a Hyper-V Live Migration ingyenes lesz, nem kizárt, hogy a VMware VMotion is (lásd ESXi). De addig még sok cég jelenik meg és megy tönkre a szilikon völgyben, 2010 nagyon messze van...
De ez elsősorban piaci politika, fordított esetben a Microsoft is pont ugyanezt tenné, mint amit most csinál a VMware. (Teljesen érthető módon, a Microsoftot szintén megértem számos korlátozó kérdés kapcsán, még akkor is, ha nem feltétlenül tetszik.)

A VMware HA-nak azért szépsége és nagyszerűsége, hogy nagyon egyszerű. Mármint alap felhasználói szempontból. Ha más miatt nem, hát tárolórendszer takarékossági/felügyeleti szempontból is jobb a VMware HA, túl isteníteni nem kell, de nincs is rá szüskg
(Sajnos még mindig nem tudtam végigolvasni az összes cikkedet, de itt-ott olvasni néhány SCVMM szépségről, mint például a CD/DVD iso többszörözésről - nem tudom ezekre kitértél-e...)

DRS és szépséges mellékei: igen, és sok egyéb hasonló terület van még a virtualizáció körül, ami mind-mind annak tudható be, hogy most kezdi úgy isten igazából eregetni a szárnyait. Azaz megold néhány dolgot, de új problémákat is előhoz. De persze minden technológiai fejlődés hasonló jelenségeket hoz magával.

Üdv,

Attila

"SCOM Cross-platform agent a jövő év első félévében várható, jelenleg még béta állapotban van, de aki akarja, kipróbálhatja."
1) Ugye mindketten ismerjuk a MS kiadasi politikajat annyira, hogy a junius vegeben remenykedjunk? :-)
2) Azt mondtam, hogy egyelore nincs. Ugy gondolom, hogy akinek fontos a rendszere, az nem mer egy alig-dokumentalt beta allapotu programot implementalni eles rendszerbe. Valoban jol mutathat az ilyen egy virtualis gepen belul, de a mukodo rendszer az teljesen mas lapra tartozik.

Az objektivitasrol: Az az igazsag, hogy ez nem a te hibad. Sajnos a Microsoft reszerol annyi hibas kommunikacio tortent a nyiltforrasu kozosseggel, hogy amikor jo iranyban akar elmenni, akkor is eroteljes fenntartassal fogadjak a dolgot. Ezen sem te, sem mas nem fog tudni egy csapasra valtoztatni, ehhez sajnos ido kell.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

1, - reménykedjünk ;-)
2, - igaz, a nem kész termékeknél mindig csak óvatosan. Viszont vannak, akik egyáltalán nem tudnak ezekről a fejlesztésekről, ezért tartottam fontosanak elmondani. Izgalmas lesz a jövő év az interoperabilitás területén.

Az objektivitásról: igyekszem, ahogy eddig. Köszönöm, hogy a "szigorú, de igazságos" stílust használjátok. Azt gondolom, értékes oldallá vált a beszélgetés.

Üdv:

Lepenye Tamás

Hello,
Nagyon szep iromany, sajnos nem vagyok a temaban kepben, ezert csak rad tudok tamaszkodni. A proci korlatnal celoztal, hogy mi a mostani korlat gepekben, illetve mire van ertelmes igeny, ezt vartam vmware 256gigas memoria korlatozasanal is. Tehat itt szukseg van-e tobb ramra? Neztem ibm arulmar olyan gepet amibe belemegy tobb ram.
Remelem a vegen nagyvonalakban osszehasonlitod a tobbi megoldassal (akar meg ibm pseries is).

A 4. korben talaltam egy elirast "17.
Netware 6.5 Server x Igen (20012. március 7.)"
Egyel tobb 0-at irtal az evnel.

Alapvetoen mindig az adott alkalmazas memoriaigenye donti el, hogy mennyi memoria szukseges egy virtualis gepnek. Mondok peldat: egy apache 256 mega rammal vigan elfutkarozik php + mod_python + mod_perl + mpm_itk + 8-10 vhost tarsasagaban, gond nelkul. Am ha ehhez a rendszerhez hozzacsatolnak egy tomcat-et, a memoriaigeny minimum saccperkabe 512 megabajttal megno, azaz az eredetihez kepest az uj rendszernek 3x-os memoriamennyiseg szuksegeltetik. A tomcat-hez tobb alkalmazast hozzaadva a memoria megintcsak no.
Tehat itt erosen a futtatni kivant alkalmazasok memoriaterhelese hatarozza meg a virtualis rendszer valos memoriaigenyet. Ehhez jon meg az operacios rendszer onterhelese, ami peldaul Windows eseten kb. 80 es 200 MB kozott lehet (optimista becsles).
Egy virtualis rendszert kozel hasonloan kell tervezni mint egy valos rendszert, a kulonbseg csak annyi, hogy a virtualis gepeket hostolo gazdagepet kell nagyon jol megvalasztani. A belul futo vendeggep szamara azonban nagyon sok szempontbol irrelevans, hogy virtualis gepen fut avagy sem, hiszen az emulacio pont arra szolgal, hogy a hostolt alkalmazas elol ezeket a dolgokat elrejtse.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Az elírást javítottam, köszi.

A memória-korlát jóval erőteljesebb, mint a processzor-korlát. A virtualizáció pedig scale-up típusú szerepkör. Nem csak az IBM árul ilyen vasat: a Unisys ES7000 Model 7600R is képes akár 1 TB memóriát fogadni.
Már a magyar méretkategória esetén is látom a lehetőségét ilyen rendszerek alkalmazásának. No, mindezek miatt nem úgy kezeltem ezt a paramétert, mint azt tettem a processzorok esetében.

Egyébként az ESX4-ben nem véletlenül szerepel első helyen a 64 bites támogatás: ez ugrás-szerű növekedést jelent majd a skálázhatóságban.

Üdv:

Lepenye Tamás