A VMware ESX 3.5 és a Hyper-V összehasonlítása – 11. kör

(Eredetileg a 9-10-11. kör egy cikknek készült. Végül olyan terjedelmes lett, hogy három cikkre bontottam, viszont a kereszthivatkozásokat nem gyomláltam ki belőlük. Érdemes egyszerre elolvasni őket.)

Erőforrás-használat kiegyenlítése
Kevesen tudják, de erőforrás-használat kiegyenlítésre mindkét gyártónak van megoldása. A VMware-nek, ahogy azt a HA-nál már említettük a DRS végzi ezt, a Microsoftnál pedig a felsorolható funkciók egy részét a System Center Virtual Machine Manager (SCVMM)önmagában tartalmazza, más részüket a System Center Operations Manager-rel együtt valósítja meg. A téma persze itt is a kereteket feszegeti, úgyhogy teljes elemzésre nem tudunk sort keríteni. Egyetlen szemszögből nézzük most a témát: virtuális gépek mozgatása.

A VMware Distributed Resource Schedulere igazából két feladatot végez: a megfelelő helyre rakja ki a virtuális gépet amikor az megszületik (Initial placement), majd annak működése során, ha szükségesnek látja, folyamatosan rakosgatja egyik kiszolgálóról a másikra – természetesen a szolgáltatás megszakadása nélkül, VMotion-nel integrálva. Mikor láthatja szükségesnek a DRS a gép mozgatását? Íme a lista:

  • CPU túlterhelődés egy adott kiszolgálón. Ha a processzorokból kifogy a szufla, egy virtuális gép áthelyezése egy másik kiszolgálóra kielégítheti a megnövekedett számítási igényt.
  • Memória túlfoglalás egy adott kiszolgálón. Ha túl sok gép túl sok memóriát igényel, akkor átkerülhet egy másik node-ra, ahol van elég.
  • Együttmozgás. Ha az egyik gép átmozog, mozogjon vele egy (vagy több) másik is.
  • Géptaszítás. Ha egy gép egy kiszolgálóra kerül, akkor egy másik vándoroljon el onnan. Van például két webkiszolgálónk NLB-fürtben. Célszerű a két gépet külön állomásokon tartani, hogy összeomlás esetén ne álljon le a szolgáltatás.
  • Karbantartás. A szervert le kell üríteni, hogy karbantarthassuk.
  • Kiszolgáló kiürítés lekapcsoláshoz. Ha DRS úgy látja, hogy kevesebb kiszolgálóra is össze lehetne sűríteni a virtuális gépeinket, akkor erre javaslatot tesz. Ha megfogadjuk a tanácsát, akkor a felesleges kiszolgálókat ki is kapcsolja. Majd igény szerint bekapcsolja őket Wake-On-Lan-nal.

Nagyon impozáns képességek ezek. Ha azt vesszük, hogy mindez integrált a VMotion-nel, a virtuális gépeknek garantált kapacitásokkal, az erőforrás pool-okkal – no, hát ez ma a virtualizáció csúcsa. Lehet ezt felülmúlni?

Performance and Resource Optimization
Igen, lehet, sőt, bizonyos vonatkozásban már most felülmúlták. A Microsoft is készített egy, a fentihez hasonló rendszert, ami néhány megvalósított képességeiben most is, potenciáljában pedig messze a DRS előtt jár. Miről is van szó?

A DRS egyfajta monitorozó feladatot végez. Látja a kiszolgálók CPU foglaltságát, memória-foglaltságát, továbbá látja a virtuális gépek néhány alapadatát, de a virtuális gépeket úgy kezeli, mintha kis gombócok lennének – nem lát beléjük, nem látja az alkalmazásokat, és a figyelt paraméterek száma nagyon korlátozott.

image A System Center Operations Manager (SCOM) ezzel szemben egy teljes felügyeleti rendszer. Nem csak belelát a gépekbe, hanem felismeri és menedzseli az alkalmazásokat, de ami még ennél is fontosabb: látja az összefüggéseket. Nem csak azt képes megállapítani, hogy magas egy gép CPU használata, de azt is tudja, miért. Nagyon használja a fizikai lemezeket egy virtuális gép? Vajon rosszul konfigurált a antivírus szoftver, SQL index-építés folyik, vagy elfogyott a gépnek allokált memória és a lapozófájlt használja? Vajon azzal, hogy átköltöztetjük a gépet egyik kiszolgálóról a másikra, megoldottuk a problémát?

A SCOM a tudását ún. Management Pack-ek formájában tárolja. Belső Microsoft szabvány, hogy minden vállalati termékhez management pack-et is kell készíteni, ami tartalmazza azt, hogy mit kell figyelni az adott terméken, a hibák esetén hogyan kell a problémát elhárítani stb. stb. Az hibák kiküszöbölése új értelmet nyert a virtualizáció megjelenésével. A legújabb Management Pack-ek elláthatók “Performance and Resource Optimization” (PRO) képességgel. A PRO képesség az egyik “ragasztó” a SCOM és a SCVMM között. Tegyük fel, hogy magas egy Hyper-V kiszolgáló CPU terheltsége, és a SCOM úgy látja, egy virtuális gép elköltöztetése megoldaná a problémát. Megoldás? A SCOM ügynök riasztása után a SCOM kiszolgáló “javasolja” az SCVMM-nek a virtuális gép átmozgatását, ami azután a rendszerüzemeltető kézi beavatkozásával, vagy automatikusan végrehajtódik. A történet eddig a DRS másolása. Csakhogy Management Pack-et bárki írhat, néhányan már el is kezdték. A Dell például a management pack segítségével figyel a blade kiszolgálók hőmérsékletét, és ha túlmelegedést észlel, akkor “karbantartási módba” kapcsolja a kiszolgálókat, ami azután Quikc Migration-t eredményez. Nem kell részletezni, hogy ez a proaktivitás hozza az igazi rendelkezésre állást. A DRS ilyet nem tud. image Az Emulex a saját HBA kártyáit figyeli és szükség esetén szintén gépmozgatást alkalmaz. A sort végtelenül lehet sorolni, hiszen ezer és egy oka lehet a gépek mozgatásának. A PRO keretrendszer jellege, a hardvert, operációs rendszert és az alkalmazásokat is felölelő monitorozási képessége messze a DRS fölé emeli.

De a Microsoft még ennél is “pimaszabb”. Azt mondja, hogy a PRO még a DRS-t is javíthatja. Ha SCVMM-mel felügyelünk egy ESX rendszert, akkor az ESX-ekre is használhatók a PRO javaslatok. Olyannyira, hogy az ESX kiszolgálók – a licenc megléte esetén – a PRO javaslatokat VMotion-nel végzi el!

Amikor a PRO előnyeit ecseteltem, soha nem felejtem el hangsúlyozni, hogy ma még csak részterületeken és potenciáljában múlja felül a DRS-t. Ennek többféle oka van. A Management Pack-ek itt-ott már elkészültek (lásd Dell, Emulex stb.), és a Microsoft is gyártott már ilyet, de a javaslatok száma még messze nem annyit, amennyi lehetne. A hőmérséklet-figyelés, meg a HBA kártya figyelést az ESX-DRS nem tudja, viszont a gép együttállást-különállás dobozból kicsomagolva is megy a VMWare-nek. A DRS-t mindenki a teljesítmény-optimalizálással köti össze, miközben a legszebb és leghasznosabb tulajdonsága a karbantartási üzemmódba helyezett kiszolgáló automatikus leürítése. (50 VM-nél ez nagy előny!) A SCOM-nál (ma még!) ezt magunknak kellene Management Pack-be varrni, amire nincs mindenkinek erőforrása/pénze/tehetsége/ideje.

Van aztán olyan, amit egyáltalán nem tud még a PRO, mert a hypervisorból hiányzik, ez pedig az elosztott energia-gazdálkodás. Láttuk a DRS képes lekapcsolni a kiszolgálókat, hogy áramot takarítson meg. A Microsoft világban majd csak a Windows Server 2008 R2-vel jön el egy hasonló funkcionalitás, amit Core parking-nak hívnak.

Értékelemzés
”Rendes ember” implementálta a DRS-t, ettől lesz dinamikus az IT – tartja mostanság a közvélekedés. Da vajon tényleg? Vegyük mindkét megoldást egy kalap alá, nevezzük magyarul “erőforrás-használat kiegyenlítés”-nek, és nézzük meg, mi az értéke/haszna egy ilyen dolognak.

Az első érv a funkció mellett, hogy “ha erőforrás szűke” lép fel, akkor azonnal lehet rá reagálni. Igaz. De mikor lép fel erőforrás szűke? Ha rendesen konfiguráljuk a fürtünket, és előre is gondolkodunk kicsit, akkor igen ritkán. Miért is? Képzeljük el, hogy ha tele van egy kiszolgálónk, akkor – mivel a fürt tagjai nagyjából egyenletesen terheltek – azt kell gondolnunk, hogy a fürt többi tagján sincs igazán sok erőforrás. Meg aztán, láthattuk a magas rendelkezésre állás elemzésénél, be kellett állítanunk, hány fürttag kiesését kell elviselnie a teljes rendszernek. Ha számolunk egy nyolctagú fürttel, ami azért nem kicsi magyarországi viszonylatban, akkor az erőforrások legalább 1/8-a szabad kell, hogy legyen (CPU, memória) minden gépen ahhoz, hogy a fürt magas rendelkezésre állású maradhasson. A gyakorlatban ugyanakkor még több a szabad erőforrások aránya, hiszen egy jó rendszerüzemeltető számít arra, hogy újabb és újabb igények sorakoznak majd, ezért beszerzéskor “tartalékokkal” vásárolja a hardvert – okosan és helyesen. Csakhogy ez tovább csökkenti annak valószínűségét, hogy performancia probléma miatt kell vándorolnia a gépeknek.

(Az már egy másik kérdés, hogy mivel a VMware VI Enterprise egy nem olcsó mulatság, a rendszerüzemeltetők néha rászorulnak a “minél kevesebb host” stratégiára. Akár azon az áron is, hogy megszegik a HA előírásokat és sárga vagy piros – tehát a magas rendelkezésre állást nem minden tekintetben teljesítő –  fürtöket üzemeltetnek. Ilyenkor felpörögnek a DRS javaslatok, és valóban hatékonyabb lesz az erőforrások elosztása – csakhogy itt a probléma megoldása mellett magát a problémát is a gyártó generálta.)

Van azután az energia-gazdálkodás, takarékoskodás. Ez nagyon jó funkció, de szerintem csak tényleg nagy (értsd: nagyon nagy!) cégek tudják hasznosítani. Van pl. egy akció a webáruházban, ehhez szükség van egy csomó webszerverre. Az akció elmúltával a virtuális gépek kikapcsolhatók, a fürt pedig összehúzhatja magát. (Nota bene: a PRO lehetővé teszi, hogy a webszerverek terhelésének függvényében újabb és újabb gépeket tudjunk automatikusan csatasorba állítani, értsd provizionálni. Ez is unikum). De komolyan: van 100 szervered 10 hoston. Estére összehúzod magad 7-re? Reggel újra bekapcsoltatod a hármat? Kételkedem. Ami tényleg jó, az az affinitás, anti-affinitás. Ha mozgatok egy gépet, mozogjon egy másik is. És persze a karbantartás-leürítés. Csakhogy ez meg majdnem egészében a tervszerű karbantartáshoz visz vissza minket. Azt meg jól tudjuk kezelni a Quick Migration-nel is.

Összegezve úgy látom, hogy a VMware DRS – önmagában – kevesebb haszonnal bír, mint amekkora a híre.  Egy klasszikus “fájdalompontra adott gyors megoldás”, erejét pedig főleg nagyobb rendszereknél fejti ki. Ettől függetlenül vannak elvitathatatlan előnyei:

  • Integráció. A DRS integrált a HA-val, a VMotionnel, a erőforrás-poolokkal – mindennel, ami az ESX világban létezik.
  • Egyszerű. A PRO képességei beláthatatlanul tágak. Van, akit ez megnyugtat, és van, akit megijeszt.
  • Egyetlen komponens. A PRO a  “Hyper-V- Fail-Over Cluster – SCOM – Management Pack – SCVMM” komponensek együtteséből adódik ki. “Mindent tud” – de méretes is.
  • Gyors megoldás. – A “karbantartáskor leürítem a szervert” egy roppant egyszerű dolog. Egy PRO szintű rendszernek meg sem szabadna kottyannia. Mégis, az MS fejlesztői elfelejtenek apró sikereket elérni. Reméljük azért hamarosan ez is eszükbe jut. (Már továbbítottam az ötletet ;-))

Van még érdekes vonatkozása a DRS-nek, illetve a virtuális gépek mozgatásának, és ezt Magyarországon még soha senki nem feszegette. (VMotion-re és Quick Migration-re egyaránt érvényes!) Vajon a változás-kezelés témakörébe tartozik-e a gépek mozgatása? Erre a VMCommunity egy tagja is kíváncsi volt. 2006-os beszélgetés, de azért érdemes elolvasni. Van, aki annak tartja, van, aki nem. Van, aki a DRS által kezdeményezett mozgást nem tartja annak, és van, aki igen. Nem triviális, viszont fontos a VMotion-Quick Migration vitában. Ott, ahol konzervatívabbak és a változás-kezelés hatálya alá utalják ezt a műveletet, szükségszerűen kell valamiféle engedélyezési kört futni. Csak úgy VMotion? Felejtsd el! Elég tervezett karbantartáskor. Innentől tudjuk… Másrészt, legalább egy alapos végiggondolást igényel kockázat oldalról is. Vajon minek kisebb a a kockázata? Maradjon egy gép, vagy menjen? Erre tényleg egyedileg lehet választ adni. Hiszem, hogy a mozgatás kockázata kicsi, de hogy pontosan mekkora, azt azért nem árt tudni.

Hát így áll – szerintem – a világ a virtuális gépek mozgatása terén. Biztos van olyan helyzet, amikor a VMotion fontos, de hogy a mostani virtualizációs telepítések kevesebb, mint 5%-ánál, az biztos, és NEM a méret, hanem az egyedi igény a meghatározó. Mindenhol máshol “nem rossz, ha van”. Akkor a Microsoft minek fejleszt ilyen funkciót a Windows Server 2008 R2-be? Tudatosan kerültem, hogy akár csak egyszer is leírjam “a Microsoftnak is lesz Live Migration” képessége, pedig lesz. Ha valaki ezután fogna egy szövegszerkesztőt, és minden VMotion szót kicserél “Microsoft Live Migration”-re, majd megkérdezné, fenntartom-e, amit leírtam eddig, akkor azt mondanám neki, hogy fenntartom. Látható az előző cikkbeli táblázatból, hogy van helye a Quikc Migration-nek a nap alatt. Akkor miért gondolja az MS másképp?

Ha valaki engem kérdez, miért szükséges a Live Migration a Windows Server 2008 R2-be, akkor két okot tudok felsorolni: egyrészt tényleg lehet olyan helyzet, amikor Live Migration nélkül romlik a szolgáltatás minősége. Tessék csak a Windows Azurra, vagy Live Mesh-re gondolni (meg arra, hogy ezek mekkora méretűek). De technológiai szükség mellett van egy nagyobb: a megoldással kapcsolatos percepció.

“Tévedések vígjátéka”
A Vmotion alkalmas arra, hogy félreértsék. Az értékesítésben résztvevő kereskedők (és nem a mérnökök!) a VMotion kapcsán a “magas rendelkezésre állás” hívószót alkalmazzák szinte mindig. A partner napon bőven volt alkalmam hallgatni VMware mérnökök ezzel kapcsolatos elégedetlenségét, hiszen az ügyfélben keltett túlzott várakozásokat nekik kell aztán hűteni. Minderre még a VMware marketingje is rákontráz: a clustert, a DRS-t és a VMotion-t együtt úgy pozicionálják, hogy “olyan ez, mintha egy nagy szervered lenne, egyben látod a rendelkezésre álló processzor, memória stb. erőforrásokat, és tetszés szerint allokálhatsz belőle.” Ez a mondat nem teljesen hamis, de megint csak túlzott várakozásokat hoz létre. Nekem személyesen is több ügyfélnél kellett tisztáznom azt, hogy a VMware nem képes több fizikai kiszolgálót egyetlen virtuális hosttá tenni. Személy szerint egyébként még a túlzott várakozások közé sorolom azt is, hogy az ügyfelek elkezdik nem használni a belső guest-clustering megoldásokat, mondván, van VMotion és HA. Látható a táblázatból, hogy ez rövidlátó stratégia, technológiai vakság.

“Álmodozások kora”
Van azután egy érzelmi hatás, ami a működő gépek mozgatásával kapcsolatos. Nem véletlenül hoztam a cikk elején, mennyire nagy hatást gyakorolt rám is a VMotion demó. Elhivatott szakmabéli vagyok (még így éjjel fél egykor is :-)) és van egy álmom, hogy az IT jobbá tehető. A VMotion ennek az álomnak a megvalósulását ígéri. Olyan egyszerű és olyan átlátható. A Microsoft megoldása – amely “csak” 99%-ban hozza azt, amit lehetne egyébként, “eladhatatlan”. Az IT szakember arról fantáziál, hogy lehet jobb IT-t csinálni. És VMotion-t vesz, mert ragaszkodik az álmaihoz. Az ár/érték arány számításhoz ugyanis fel kell ébredni, ki kell ábrándulni. És ki szeret kiábrándulni? A Quick Migration nem teljesíti az álmokat és a felsővezetésnek is “eladhatatlan”.

“A hiúság vására”
És végül, de nem utolsó sorban, említsük meg, bizony a hiúság is szerepet játszik VMotion sikerében. “Na ne hogy már mi ne legyünk dinamikusak!” “Na nehogy éppen nekünk ne kelljen ez a fantasztikus dolog! Hiszen mi akkora nagyvállalat vagyunk mint ide Kuskunlacháza!”
Évek óta nem találkoztam olyan informatikussal, aki ne kisírt szemmel panaszkodott volna, mennyire nincs pénz az IT fejlesztésekre. Tudni kell, hogy van Magyarországon, nem egy és nem kettő olyan cég, ahol irdatlan mennyiségű pénzt tapsol el az IT minden évben. Ezen cégek közül nem kevés azt a stratégiát vallja, hogy “minden termékből a legkiválóbbat”, vagyis többnyire a legdrágábbat. Se stratégia, se standardizáció, se platform-építés. Lokális maximum. Helyi kis szemétdombok. A virtualizáció ráadásul – még a borsos VI árak mellett is – extrém hamar megtérülő, kristálytisztán kimutatható költségcsökkenést hozó technológia. Hol van itt akadály? Sehol.

A fenti három attitűd mind-mind alátámasztja, hogy hiába volt technológiailag helyes elhalasztani a Live Migration funkciót a Hyper-V-ből a megjelenés tartása érdekében, marketing szempontból ez katasztrófális következményekkel járt, amit – ismerjük el – ügyesen és szorgalmasan ki is használt a versenytárs (lásd korábbi összehasonlító demó). A helyzet jövőre lezáródni látszik, hacsak a Continuous Replication nem okoz némi turbulenciát… de erről majd máskor.

Táblázat

No.

Tulajdonság

VMware ESX 3.5
DRS

Microsoft Hyper-V
PRO

1.

Ajánlások CPU túlterheltség esetén

Igen

Igen

2.

Ajánlások memória túlallokálás esetén

Igen

Igen

3. Karbantartás-leürítés Igen Megvalósítható
4.

Virtuális gépek affinitása

Igen

Megvalósítható

6. Virtuális gépek anti-affinitása Igen Megvalósítható
7.

Energia megtakarítás célzó VM mozgatás felajánlása

Igen

Nem

8. HBA kártyák túlterhelése esetén migráció Nem Igen
9. Fizikai környezet alapján történő beavatkozás (táp, hőmérséklet stb.) Nem Igen
8.

Alkalmazások paraméterei alapján kezdeményezett mozgatás

Nem

Megvalósítható

10.

Egyedi szabályrendszer kialakításának lehetősége, bővíthetőség

Nem

Igen
11. Más platform támogatása Nem Igen
12. Könnyű telepítés Igen Nem

Előzmények

A VmWare ESX 3.5 és a Microsoft Hyper-V összehasonlítása – bevezetés
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 1. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 2. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 3. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 4. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 5. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 6. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 7. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 8. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 9. kör
A VMware ESX 3.5 és a Hyper-V összehasonlítása – 10. kör

8 Responses to A VMware ESX 3.5 és a Hyper-V összehasonlítása – 11. kör

  1. Gábor says:

    Nekem a SCOM-mel mindosszesen egy bajom van, igy virtualizacios teruleten: meg mindig nem lehetseges Microsoftostol eltero rendszerekhez igazitani, tehat nem tudok mittudom en, egy linux szervert felugyeltetni vele – holott a szoftver szamara gyakorlatilag mindegy, hogy milyen rendszeren megy sql indexeles vagy rossz antivirus. Es termeszetesen a kommunikacios protokoll sem nyilt, tehat meg az esely sincs meg arra, hogy legalabb elkezdodjon valami. Igazabol ez nem is a szoftver, inkabb maganak a cegnek a politikajanak a hibaja – meg mindig nem eleg nyiltak, hiaba hirdetik nagy hangon. Mert adminisztracios szempontbol nagyjabol mindenkit hidegen hagyott a .Net fw forrasanak nyiltta tetele, de ha a SCOM-hez kiadnanak nyilt apikat, esetleg alap linuxos agent-eket, az mar adminisztracios szempontbol is merfoldko lenne. Am a MS bizonyos teruleteken ugy latszik, meg mindig ugy gondolja, hogy a nyiltforrasu rendszerek egyfajta jatekplatformok, nem igenyelnek komolyabb odafigyelest, ha menedzsmentrol van szo. Pedig ez egyaltalan nincs igy.

  2. Tamas says:

    Szia!
     
    Egyetértek az igénnyel. Mi a véleményed a Cross Platform Extension-ről?

  3. Bubor says:

    eliras "Igen (20012. március 7.)"s/20012/2012/g

  4. Tamas says:

    Hú, ezt nem értem!

  5. Gati says:

    Tamás, nagyon jónak tartom a cikkeidet, örülök, hogy valaki ilyen jól összeszedte az információkat a témával kapcsolatban. Ebben a cikkben feszegeted a VMware DRS és Microsoft megoldását, hogyan kezeli a két gyártó a terheléselosztás . Az árat mindig kiemeled a VMware oldalon, mint negatívumot. A Microsoft felülegyelti rendszerénél nem adtál meg árat. Nagyon kívácsi lennék, mennyibe kerül egy SCOM felvértezve egy SCVMM -el. Milyen licenense és vas vonzatai vannak ennek. És ennek mennyi a telepítési, beállítási ideje.

  6. Tamas says:

    Olyan sokat kérdeztél, hogy egy teljes cikkben kellene válaszolnom. Mivel azonban erre záros határidőn belül biztos nem lesz módon, próbálok röviden – és emiatt nem teljeskörűen – fogalmazni.Ügyeltem rá, hogy árakról minél kevesebb említést tegyek, és nem emlékszem, hogy egyszer is negatívumként emeltem volna ki a VMware árait. Idézd be légyszi, mire gondoltál. Ebben a cikkben ugyanakkor valóban megemlítettem, hogy a VI nem olcsó mulatság, de itt sem árakról beszélek, hanem arról a szituációról, amikor takarékossági okokból sűrűbb rendszerek jönnek létre.Ami a System Centert illeti. A Microsoft licencelése minden, csak nem egyszerű. Ezt annak ellenére mondom, hogy az alábbi licencelési mód az egyik legegyszerűbb, amit a Microsofttól láttam. Tehát: ahhoz, hogy legyen egy MS menedzselte rendszered, a minimálisan a következő komponensekre van szükséged:1. A Management szerverek operációs rendszerei. Az ár igencsak változó attól függően, hogy fizikai vagy virtuális gépről beszélünk, illetve hogy OEM vagy Volume Licence keretében történik a beszerzés.2. A menedzsment kiszolgálók licencei, vagyis 1 db SCOM, 1 db SCCM, 1 db DPM, darabja kb. 600 Euro. (Az MS weboldalán ennél kevesebbet találsz és dollárban)3. A menedzsment kiszolgálókhoz tartozó SQL kiszolgáló/ kiszolgálók. Megint csak nagyon változatos árakon (Standard vagy Enterprise, a menedzsment szoftverrel egybecsomagolt vagy sem, fürtözött vagy sem stb. stb.)3. A menedzselt kiszolgálókhoz rendelt Server Management Suite Enterprise (SMSE), ami kb. 1300 – 1600 Euro / hypervisor host. Ez két éves követést is tartalmaz, plusz két nagyon fontos jogot:- SCVMM szerver telepítésének és használatának lehetősége- A host OS és KORLÁTLAN mennyiségű szerver VM (és az azokban található alkalmazások) menedzseléseAz SMSE-ből tehát annyit kell venni, ahány hostunk van +1 az SCVMM számára. Az SMSE ára szerintem brutálisan olcsó, nem beszélve arról, hogy a fenti komponensek általános menedzsment eszközök – nem csak virtualizációval kapcsolatban használhatók.Vas + erőforrás igények + telepítés. Gondolom magától értetődik, hogy ez a menedzselt rendszertől függ és persze annak méretétől és komplexitásától. Egy biztos: a System Center termékcsalád egy lazán integrált szoftvercsoport, szemben a Virtual Centerrel, ami önmagában egy kerek egész. Viszont, általános célú szoftverekről van szó, szélesebb menedzsment spektrummal. Az összehasonlítással azért kell óvatosan bánni, mert mást céloz az egyik, illetve a másik. A VMware azt mondja: a virtualizációra legyen egy céleszközöd. (Értsd: ESX, vagy értsd: Virtual Center.) A Microsoft ellenben azt mondja: a virtuális és fizikai komponenseket kezeld egységesen, ugyanazokkal az eszközökkel. És ennek meg is van az eredménye: a VI kicsi, gyors és integrált, ámde szűk spektrumú, a System Center komplex, sokrétű, mindenre kiterjedni igyekvő menedzsment megoldás, ámde emiatt összetettebb, bonyolultabb és az implementálása is több időt vesz igénybe. Még egyszer: ez ennél többet is megér – beszélek is majd róla, de most csak ennyi fért bele a válaszba.

  7. kkiss says:

    Szia Tamás !Most jutottam ismét hozzá, hogy mégegyszer végigolvassamamit írtál, kis pontosítás a táblázatban foglaltakhoz. Fizikai környzetet megváltozása esetén beavatkozás – megvalósíthatóEgyedi szabályrendszer – szinténElvileg -bár gyakorlatban nem próbáltam – HBA túlterhelés esetén migráció: szintén megoldható. A megnövekvő terhelés esetén újabb szerverek bekapcsolása szintén megodlható. Ami igaz – főleg a sales és project managerek oldaláról – a VMotion-t tökéletesen félreértelmezik. Már ha egyáltalán értik a fogalmat. Szintúgy a DRS fogalmát és működését. Legszebb, ha keverik a kettőt, akkor áll fel a ( maradék ) hajam… Sajnos, "előfordul"…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: