Virtualizáció vagy privát felhő?

Bár a felhő technológiák évek óta velünk vannak, szakmai körökben még most is előfordul, hogy keverik a szerver virtualizációt és a privát felhőt. Számtalan alkalommal láttam, hallottam, amikor egy informatikai vezető büszkén beszélt a privát felhőjükről, miközben nem volt nekik olyan. Mások értetlenkedtek a privát felhő szókapcsolaton is, mondván, miért hívjuk most másképp a szerver virtualizációt, felesleges majmolni a divatot. Miért, nem ugyanaz a kettő? Könnyen bemutatható, hogy nem.

A NIST szerint

Nézzük mi a felhő. A NIST – tehát az amerikai szabványügyi hivatal – definíciója szerint a számítási felhő egy működési modell, amely bárhol használható, kényelmes, igény szerinti hálózati hozzáférést biztosít konfigurálható, közös blokkokból álló számítási erőforrásokhoz, amely erőforrások azonnal kiadhatók minimális felügyeleti erőfeszítéssel vagy szolgáltatói közreműködéssel. (Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (…) that can be rapidly provisioned and released with minimal management effort or service provider interaction.)

A NIST szerint a számítási felhők öt lényeges tulajdonsággal (essential characteristics) rendelkeznek:

• Igény szerinti önkiszolgálást biztosítanak (On-demand self service)
• Jó hálózati hozzáféréssel rendelkeznek (Broad network access)
• Erőforrás készletekre épülnek (Resource pool)
• Teljes rugalmasságot biztosítanak (Rapid elasticity)
• Mért szolgáltatások (Measured Service)

Mindezekről részletesen írtam már korábban a "Számítási felhő – egyszerűen" cikkben. A magán számítási felhő, vagyis privát cloud a NIST értelmezésében a felhő működési modell egy terítési módja (a négy közül). Ha rövidre szeretném zárni a diskurzust, már csak annyit kellene írnom, hogy amennyiben a virtualizációt is pont így kell definiálni, akkor a két dolog azonos. Ha nem, akkor nem. 😉 De legyünk egy kicsit kényelmesebbek és elmélkedjünk még a különbségeken. Megéri.

A szerver virtualizáció a ma ismert formájában kb. egy évtizede kísér minket. A szerver virtualizáció egy technológia, amely erőforrás absztrakciót tesz lehetővé – közös fizikai erőforrásokat izolál, vagyis választ el, és virtualizál, bizonyos értelemben szabványosít. A virtualizáció jobb erőforrás-kihasználást biztosít, ez egyúttal a megtérülésének fő forrása is.

A magán számítási felhő (a továbbiakban: felhő) a virtualizációhoz képest egy másik dimenzióban létezik. Ha a virtualizáció a repülőgép, akkor a felhő egy légitársaság. A két fogalom, bár egymással kapcsolatosak, nem tartoznak azonos kategóriába. A virtualizáció létezhet önkiszolgálás nélkül is, számítási felhő nem. A virtualizációnál nem feltétel az erőforrás készletek használata, a felhőnek ez alapvető része. A virtualizációs környezetek többnyire nem mért szolgáltatások – a felhők minden esetben azok. Csodálkozol, hogy a ti felhőnek mondott rendszeretekben nincs mérés és számlázás? Sajnálom, nem privátfelhőn dolgozol. Nincs nálatok önkiszolgálás? Sajnálom, az a rendszer nem privát felhő. Nincs értelme erőforrás blokkokban gondolkodnotok, mert túl kicsi a rendszeretek? Sajnálom, az nem privát felhő. Van, aki azt mondja, hogy a virtualizációs rendszerek, ahogy egyre érettebbek lesznek, szép lassan magán számítási felhővé alakulnak. Kötve hiszem. A sok repülőgép nem légitársaság, hanem repülőgép flotta. Nem ugyanaz. A magán számítási felhő nem egy jó erősen automatizált virtualizáció.

Ha ez még mindig nem lenne elég, akkor beszéljen a pénz. A virtualizáció és a magán számítási felhő – meglátásom szerint – nem azonos megtérülési hajtóerők hozzák létre és tartják fenn, s akár ez is lehet a megkülönböztetésük alapja.


A virtualizációs beruházás (és így a virtualizációs rendszer) megtérülése két dologból fakad. Egyrészt hatékonyabb erőforrás-kihasználást tesz lehetővé, amelyből fajlagos erőforrás-költség csökkenés keletkezik. Másrészt a virtualizáció adta szabványosítás és közös erőforrás-halmaz agilis igény-kiszolgálást eredményezhet, amely vállalati szintű termelékenység növekedést jelent. A magán számítási felhő megtérülése ugyanakkor három tényezőre vezethető vissza.

• Az közös erőforrások kihasználásából fakadó fajlagos erőforrás-költség csökkenés – akárcsak a virtualizációnál
• Az önkiszolgálás, az azonnali kapacitás rendelkezésre állás és a jó hálózati hozzáférésből adódó agilisebb szervezet, vagyis vállalati szintű termelékenység növekedés – akárcsak a virtualizációnál
• A mért – és ezért többnyire visszaszámlázott – szolgáltatás igénybe vevője érdekeltté válik, hogy a szolgáltatás igénybevételével takarékoskodjon, így rendszerszinten a szolgáltatás valamennyi szereplője a motivált az erőforrások takarékos használatára. Ez a takarékoskodás ugyanakkor nem jár az agilitás csökkenésével.

A legutolsó megtérülési hajtóerőt nem lehet eléggé túlbecsülni. Ahogyan az informatikai szervezetek óvatosan és szigorú költségkontroll mellett veszik igénybe a nyilvános IaaS szolgáltatásokat, többször is meggondolva minden egyes forint elköltését, ugyanúgy egy privát felhő esetén a szolgáltatás igénybe vevője kontroll alá helyezi magát az erőforrások használatát illetően, mert a fogyasztása a saját pénztárcája bánja. Ez persze azt is jelenti, hogy a magán felhő szolgáltatója, tipikusan az informatikai szervezet, profit-center, nem pedig költség központ. Nálatok nem profit központ az IT? Akkor az a sejtésem, hogy privát felhőtök sincs…

Microsoft Hyper-V Server 2012 – a kihagyhatatlan(?)

A 2009.-ben írt “Microsoft Hyper-V Server 2008 R2 – a figyelemre méltó Hypervisor” az egyik legolvasottabb cikké vált az évek folyamán. Nos, itt a folytatás. Három év elteltével a Microsoft új verziót készül kiadni (a cikk írásának pillanatában a Hyper-V Server 2012 még Release Candidate állapotú.) Ha a Hyper-V 2008 R2 figyelemre méltó volt – és az volt –, akkor az új változatról nyugodtan kijelenthetem, hogy kihagyhatatlan. Lássuk miért is…

Ami nem változott – név, filozófia és támogatás
Nem változott a termék neve, leszámítva az évszámot, és ami még fontosabb, nem változott a kiadás mögötti filozófia: a Hyper-V Server 2012, akár csak az elődje, korlátozás nélkül tartalmaz minden olyan funkciót és képességet, amelyet a hypervisor használhat. Nincs időkorlát, nincs korlátozott kiszolgálószám, nincs korlátozott memória, processzortámogatás stb. stb. Minden, ami elérhető a Windows Server 2012 Datacenter hypervisorában, megtalálható a Hyper-V Server 2012-ben is. Ebből persze nem kell azt a következtetést levonni, hogy a Microsoft virtualizációja csupán ennyi, a funkciókat jócskán megfejeli a System Center 2012, ami viszont licencdíj köteles. A termék neve nem véletlen: nincs benne a “Windows” szó, amivel azt jelzi a gyártó, hogy nem jár hozzá Windows kiszolgáló futtatási jog. Vagyis: letölthetjük, de ha Windows kiszolgálókat szeretnénk futattni rajta, akkor azok licenceiről külön kell gondoskodnunk (Ebben a cikkben már licencelésről nem írok, csak annyit még, hogy ettől a futtatott példányuk után fizetendő összeg sem nem nő, sem nem csökken.) Kétségünk ne legyen: még ha nem is szerepel a “Windows” a névben, azért technikai értelemben ez mégis csak egy Windows architektúrát hordozó megoldás. Már emiatt is, a Hyper-V Server minden olyan hardver konfiguráción elfut, amelyen Windows szerver működik – a hardver kompatibilitással nincs gond.

És ami változott – a műszaki belbecs
Ami ugyanakkor jelentősen megváltozott, az a szoftver minősége. A fenti idézett cikkben leírt funkciók továbbra is működnek, ezért ebben a cikkben csak és kizárólag azokat emelem ki, amelyek újak, vagy más platformon esetleg csak komoly összegekért érhetők el. Olyan sok az újdonság, hogy már ezek rövid felsorolásával hosszabb cikk kerekedik, mint amekkora a három évvel ezelőtti volt.

Előbb nézzünk néhány technikai paramétert:

• 320 logikai processzor, értsd: processzor mag, és 4 TB fizikai memória támogatása. Mindkettő azt jelenti, hogy élő ember nem fog látni akkora vasat, amit ki ne tudna hajtani a Hyper-V Server 2012.
• A Hyper-V-n futó virtuális gépek ezután maximálisan 64 virtuális processzort és 1 TB RAM-ot támogatnak – Megint csak: a gyakorlat szerint ez lényegében a korlátlanságot jelenti. (Vesd össze: van ahol az ingyenes hypervisor csupán 32 GB memóriát használ.) Az üzenet világos: aligha akad olyan környezet, amit ne lehetne virtualizálni.
• 64 tagú fürtöt lehet alkotni belőle (lássuk be, már a korábbi 16 is bőven elég volt.), egy fürtben pedig 4000 működő virtuális gép lehet – hát, az informatikusok többségének ez is a sci-fi világa. Viszont egy 3-4-5 tagú fürt összehozásának semmi akadálya. Erre pedig igenis van igény.

  
  A maximumok emlegetése helyett sokkal érdekesebb, hogy milyen minimális konfiguráció elégséges a rendszer futtatáshoz:

• Processzor: 2008 óta a követelmények változatlanok: 64-bites architektúra (x64 és nem Itanium!), DEP és hardveres virtualizációs támogatás a feltétel – alig találni már olyan processzor, amely ezt nem teljesíti.
• Memória: A Hyper-V működéséhez 512 MB a minimális elvárás. Természetesen ennél többre van szükségünk, hiszen a virtuális gépek számára is szükség lesz memóriára.
• Tárolóhely: Az alaprendszer 4 GB-on elfér, 8 GB az ajánlott system disk méret. Továbbra is adott az USB meghajtóról való indítás lehetősége.

A telepítés után a kiszolgálónk működhet munkacsoportban vagy tartományban. Fürtözés továbbra is csak ez utóbbi módban lehetséges. A tartománytagság minden előnyét élvezhetjük: egységes, közös identitáskezelés, csoportházirendek, távoli szerver manager használata stb. Ahogy a 2009-es cikkben is írtam: a csoportházirend jelentőségét nem lehet túlbecsülni, mivel szinte minden létező beállítás házirendből, egy pontból és egységesen állítható minden gazdagépre, beleértve a tűzfal-szabályokat, a tanusítványok terjesztését, a frissítési házirendeket, a biztonsági beállításokat stb. 

Ha már telepítettük a rendszer egy vagy több gépre, nézzük milyen újdonsággal szolgálnak az egyes alrendszerek.

Hálózatikezelési újdonságok

• Hálózati kártyák aggregálása (NIC teaming) – Bármilyen,  Receive Side Scaling képességgel rendelkező, azonos sávszélességű hálózati kártya összefogható egy csoportba, növelve ezzel a hálózati rendelkezésre állást és elosztva a terhelést. A teaming szoftver képes együttműködni a hálózati switchekkel, de tud független módon is üzemelni. Többféle algoritmust ismer a terhelés elosztására. A funkció jelentősége abban rejlik, hogy két hálózati kártyával is “legjobb gyakorlat szerinti” redundáns fürtkonfigurációt tudunuk létrehozni.
• Új hálózati switch képességek – A Hyper-V új verziójában a hálózati switchek új képességekkel bővültek. Szabályozható a virtuális gépeknek szánt sávszélesség, tükrözhetőek a portok, védelmet kaphatnak a virtuális gépek az illegális DHCP vagy router advertisment forgalommal szemben.
• Kiegészíthető hálózati switchek – Ha valakinek kevés lenne a beépített switchek képessége, kicserélheti másikkal, például a CISCO eszközeivel. Persze lehet, hogy elég csak kiegészíteni egy-egy funkcióval. Több gyártó is akad már, akik virtuális tűzfalat, antivírus ellenőrző modult, vagy DoS támadás ellen védő szoftvert gyárt a Hyper-V hálózati kapcsolójához.
• SMB 3.0. A Windows Server 2012 – és így a Hyper-V Server is, már az új 3.0-ás SMB protokollt használja. Ennek óriási a jelentősége. Megnyílik az új az SMB alapú fürtök létrehozásához,  jobb sávszélesség kiahsználás érhető el az SMB Multichannel segítségével, és a Hyper-V server együttműködhet a Windows Serverekkel kialakított scale-out fájlszerver fürtökkel.

Tárolókezelés

• Virtuális Fibre Channel adapter. A virtuális gépek hardver eszközkészlete egy új, szintetikus eszközzel egészült ki. A Virtuális FC kártyák éppúgy viselkednek, mint a fizikai társaik. Közvetlenül elérhetnek FC SAN eszközöket, zónázhatók stb. Ráadásul nem veszítik el a mozgathatóságukat, a Live Migration funkció továbbra is alkalmazható rájuk.
• CSV2 – A Microsoft valódi fürtözött fájlrendszere – Cluster Shared Volumes -  erőteljesen megújult. Javult a teljesítménye, gyorsabban lehet létrehozni rajta virtuális gépeket, vagy éppen rámásolni egy virtuális merevlemezt. A mentéseknél megszünt az átirányítási mód, ez szintén jobb teljesítményt eredményez. A CSV immár titkosítható a beépített Bitlockernek köszönhetően, és integrálható a szintén újdonságnak számító tárolóvirtualizációs képességekkel. A legfontosabb újdonsága mégis talán az lesz, hogy a CSV kötetek ellenőrzéséhez és javításához nem kell karbantartási üzemmódba kapcsolni – vagyis ez nem érinti majd a virtuális gépek rendelkezésre állását.
• VHDX virtuális merevlemez formátum – Az új Hyper-V-ben bemutatkozik egy új merevlemez formátum is. A régi VHD-k természetesen továbbra is használhatók, de az alapértelmezett formátum a VHDX lesz. Az új virtuális merevlemez típus a korábbi 2 TB helyett akár 64 TB nagyságú is lehet – egyelőre egyedülálló módon. Ezen felül a belső adatstruktúráját úgy alakították át, hogy jobban ellenálljon az esetleges adatvesztéseket okozó meghibásodásoknak.
• Storage virtualizáció – A Hyper-V Server 2012 egy komoly tárolóvirtualizációs megoldást kapott. Formázatlan lemezeket lemez-csoportokba (pool) foglalhatjuk. Ezeken azután virtuális lemezeket hozhatunk létre valódi mérettel vagy thin provisioning módszerrel, ahogy tetszik. Ezeket a virtuális lemezeket látják majd a Hyper-V szülőpartíciók valódi lemezeknek

Fürtözési újdonságok

A Hyper-V 2008 R2-es változata is képes volt fürtök létrehozására, magas rendelkezésre állású virtuális gépek kezelésére, virtuális gépek működés közbeni mozgatására. A 2012-es változat nagyot lépett előre a fürtözés területén is.

• Cluster aware update – Egy fürt egységes frissítése meglehetősen időigényes feladat. Le kell üríteni az első kiszolgálót, meg kell frissíteni, szükség esetén újraindítani, majd folytatni a tevékenységet a második, harmadik stb. node-dal. A fürtre felkészített frissítés ezt a munka folyamatot képes teljesen automatizálni. Így a csoportházirend alkalmazása után már nem csak a konfiguráció beállítása lehet automatikus, de a frissítések elvégzése is – miközben erről a virtuális gépek mit sem érzékelnek.
• VM indítási priorizálás – Ha egy fürttag kiesik, a többi kiszolgáló újraindítja az érintett virtuális gépeket. A gépekhez prioritási értéket lehet hozzárendelni, így a magasabb prioritású gépek előbb indulnak el, mint az alacsonyabb prioritásúak.
• Affinitási / Anti-affinitás szabályok.  – A virtuális gépekhez affinitási vag anti-affinitási szabályokat rendelhetünk. Affinitás esetén két virtuális gép igyekezni fog egy fizikai kiszolgálón futni. Anti-affinitási szabály esetén épp fordítva, a virtuális gépek igyekeznek kerülni egymást.
• Guest clustering – Nem csak a fizikai, de a virtuális gépeket is lehet fürtözni. Ez korábban is lehetséges volt, de csak iSCSI tárolókkal együtt. Az új virtuális HBA révén ezt a korlátot átugrotta a rendszer, FC alaú virtuális fürtöket is létre lehet hozni.
• Vegyes (fizikai-virtuális fürt) létrehozása – Vannak gyártók, amelyek (még) megkövetelik, hogy egy virtualizált környezetben tapasztalható hibát fizikai környezetben is reprodukálja az ügyfél, mielőtt a hibát tovább vizsgálják. A Hyper-V-s környezetben immár tetszőlegesen fizikai-virtuális fürtöt is létrehozhatunk, biztosítva a gyártó által elvárt feltételt.
• Alkalmazás monitorozás – Igaz, hogy csak Windows Server 2012 vendég OS esetén, de már támogatott a fizikai fürtből a virtuális gépben található szolgáltatások monitorozásának lehetősége. A VM-ben futó folyamat leállása esetén a hypervisor képest azt újraindítani.

A virtuális gépek mozgatása korábban kizárólag a fürtökre korlátozódott. A fürt maga a mozgatás határát is jelentette. Ez a Hyper-V Server 2012-ben – ismét csak az iparágban egyedülálló módon – megszűnt. A virtuális gép és egyes elemeinek mozgatására egészen sokfajta lehetősége adódik.

• Live Storage migráció – A virtuális gépek merevelemezeit leállás nélkül egyik tárhelyről egy másikra lehet mozgatni. Az egyidejű migrációk számát csak a hardver kapacitása korlátozza. Jó szolgáltatot tesz ez a funkció a tárolóalrendszerek átrendezésekor. Mindezt a rendberakott pillanatfelvétel készítésnek köszönhetjük. Korábban pillanatfelvételek ugyan online elkészültek, de a visszaolvasztásukra csak a virtuális gép lekapcsolása után kerülhetett sor. Ez az új verzióban megszűnt. Minden tevékenység online történik.
• Párhuzamos LM – a virtuális gépek együttes mozgatásának csak a hardver szab határt. Akár tucatnyi virtuális gép is mozoghat egyszerre.
• Live VM migrációs – fürt nélkül. Annak sincs akadálya, hogy két olyan kiszolgáló között is mozgathassunk virtuális gépet, amelyek semmilyen közös alrendszerrel nem rendelkeznek. Elég, ha közös tartományban találhatók és van közöttük ethernet kapcsolat, a virtuális gép mozgatása már megoldható.
• Hyper-V replika – A Hyper-V Server 2012  beépítve tartalmaz néhány képességet, amellyel jó eséllyel lehet védekezni az adatközpontok teljes megsemmisülése ellen is. A Hyper-V replika egy aszinkron másolási mechanizmus, amellyel működő virtuális gépekről tarthatunk fenn másolatot egy másik adatközpontban. A rendszer nem csak a folyamatos másolásról, de az átállás teszteléséről is gondoskodik. A kis- középvállalatok persze ritkán engedhetik meg maguknak, hogy tartalék adatközpontot tartsanak fenn. Néhány nagyobb IT szolgáltató viszont új – és megfizethető – termékkel jelenhet meg: adatközpont szolgáltatást nyújthatnak meghibásodás esetére.

A fentieken túl van még jópár figyelemre méltó újdonság

• GenerationID–aware hypervisor – A Windows Server 2012 AD szolgáltatását és a Hyper-V-t egyaránt felkészítették a másik “fogadására”. Az AD és a Hyper-V egyaránt tárol egy GenerationID értéket. Előbbi a maga adatbázisában, az utóbbi a virtuális gép bios-ában. A két érték akkor tér el egymástól, ha a virtuális gépet visszarepítjük az időben, például egy pillanatfelvétel alkalmazásával. Az AD ebben az esetben felkészül a “rendkívüli eseményre” és a replikációs mechanizmusát ehhez igazítja. A funkció eredményeképp éles környezetben is használhatóvá és támogatottá válik a tartománíyvezérlőt tartalmazó virtuális gépen pillanatfelvételt készíteni, mentett állapotba rakni stb.
• Powershell – A Hyper-V Server 2012 az első olyan változat, amelynek minden funkciója, kapcsolódjon az közvetlenül a virtualizációhoz, vagy kötődjön a szülő partíció kezeléséhez, eléhető powershell parancsok formájában. Ha valaki a parancssor világából érkezett: Isten hozta!
• Linux disztribúciók kezelése – 2009-ben kezdődött a Hyper-V virtuális gépeiben található eszközkezelők GPLv2 illetve BSD licenc alá helyezése. A Linux kernel 3.4-től kezdve minden driver a mainline kernel része, vagyis különösebb erőfeszítés nélkül, már a telepítés folyamatától teljes az integráció a hypervisor és a virtuális gép operációs rendszere között. Vagyis ha egy 3.4 vagy újabb kernelt tartalmazó disztribúciót futtatunk, semmit sem kell tennünk, a Linux operációs rendszer “tudja” hova került.
• FreeBSD kezelése – A Linux mellett a Microsoft bejelentette a FreeBSD paravirtualizált eszközkezelőkkel való ellátását is. Egyelőre a 8.x verziókhoz érkezik a kiegészítés, később jönnek a 9.x változatok is.
• Inkrementális mentés – Lehetőségünk lesz pillanatfelvételekre épülő mentések végrehajtására. A mentés során a pillanatfelvétel alapján az előző mentés óta létrejött különbséget menti a rendszer. A visszatöltéskor csak a megfelelő felvétel számot kell megadni, a többi a hypervisor feladata.
• Importálás javítása – A virtuális gépeket végre nem kell exportálni a rendszerek közötti másoláshoz. Az importálás elvégzi a konfigurációs fájlok javítását és regisztrálja a virtuális gépet.

Sok volt? Pedig nem is mindenről esett szó. Kimaradt a hálózati virtualizálás.  a Datacenter Bridging támogatás, az RDMA kártyák támogatása, a QoS, az erőforrás mérés, az erőforrás poolok, az Offload Data Transfer (ODX), a numa támogatás, az SR-IOV támogatás, a dinamikus memória használat finomítása, az RDS integráció, az iSCSI Boot, az MPIO, az asszimetrikus fürt és még jópár dolog.

A Hyper-V 2012 azt állítja: létezik jó minőségű, funkciógazdag, megbízható, skálázható virtualizáció bárki számára. Már csak le kell tölteni, és lehet próbálgatni.

vSphere 4.1 Update 1 – Win7 SP1 támogatással

Többször elégedetlenségemnek adtam hangot, amikor is a Vmware vSphere hypervisora csak meglehetős késéssel kezdte támogatni a Windows 7 és a Windows Server 2008 R2 operációs rendszereket. Most – nagy örömömre – az ellenkezőjéről számolhatok be: még nyilvánosan nem lehet hozzáférni a Win7/2008R2 SP1 letöltésekhez, de az éppen csak megjelent VSphere 4.1 Update1 már támogatja a Windows 7 SP1 és a Windows Server 2008 R2 SP1 rendszereket. Ez egyúttal azt is jelenti, hogy a két cég együttműködése sokat javult az elmúlt évben, és a természetes verseny mellett tudnak és akarnak együttműködni azért, hogy az ügyfeleiknek a legújabb verziókat is azonnal használhassák. Ezt így kell csinálni.

Szervezetek egyesülése és a virtualizáció

Érdekes egybeesés, hogy mind a vállalati, mind pedig az állami szektorban belefutottam egy szervezeti egyesüléses történetbe, s mindkét helyen azonos szituáció alakult ki. Az egyik előd VMware-t futtat, a másik Hyper-V-t. Adódik a kérdés, vajon mi maradjon az egyesülés után? Lehet persze “szerelemből” válaszolni, és nyugodtan elhiheti mindenki, a döntéshozók részéről van is erre hajlam, én mégis azt mondom, mérlegeljünk józanul, ugyanis nem csak technológia és nem is csupán csak pénz áll a dolgok mögött. Nézzük a döntési teret, vagy legalábbis annak nagyobbik részét:

• A vSphere lesz a “szabvány”. Szokták volt mondani, hogy “Sohasem rúgtak még ki senkit azért, mert IBM-et vásárolt”. Vagy a sárkányfűárus sárkányfűre vonatkozó megjegyzése is ideillik: “Ha ez nem segít, akkor semmi”. Nagyjából kiviláglik, hogy az ilyen döntés mögött a legfontosabb hajtóerő a biztonságra törekvés. Előnye még a megoldásnak, hogy homogenitást teremt, amely végső soron és hosszú távon a leginkább kívánatos az üzemeltetési költségek szempontjából. Emellett optimális erőforrás használatot tesz lehetővé, hiszen a egyesített homogén rendszer valószínűleg nagyobb “egybefüggő” kapacitással rendelkezik, mint az egyesülés előtti rendszerek. Persze ennek a döntésnek vannak hátrányai is. Szoftver licenc beszerzést igényel – sokszor nem is keveset. Végre kell hajtani egy migrációs projektet, ez szintén idő és pénz. Ha a Hyper-V-s környezet System Centerrel felügyelt, akkor a beruházás esetleg még nem térült meg, a migráció után pedig néhány komponens (például DPM) nem, vagy csak részben lesz használható. Ezen felül képezni kell a munkatársakat is: vagy azért, mert az üzemeltetői csapatok érintetlenül megmaradnak, ekkor a hyper-v-s részleget fel kell hozni Vmware tudásszintre, vagy azért, mert a vmwares csapat átveszi az összes virtualizációs feladatot, de ekkor a hyper-v-s üzemeltetőknek kell más munkát végeznie, s ahhoz képzés is járul. Végül, ha a csapatot megvágják, akkor végkielégítésekkel kell számolni.
• A Hyper-V lesz a “szabvány”. A fenti helyezet fordított előjellel. A fő motiváció itt a költségtakarékosság lehet. A Hyper-V ár/érték aránya jobb, ha pedig műszakilag is kielégíti az igényeket, akkor nincs akadálya ennek az útnak. Előnye a lépésnek a korábban már emlegetett homogenitás, optimális erőforrás kihasználás. Költségek itt is felmerülnek, nem is kevés: ugyanúgy van migrációs projekt, jelentkezhetnek addícionális System Center licenc költségek. Éppúgy , mint az első esetben, itt is felmerülhet, hogy a korábbi (VMware) beruházás még nem térült meg, a migráció után pedig lehet, hogy további szoftverekről kell lemondani, miközben azok még amortizálódnak.
• Mindkét technológiai a helyén marad, külön rendszerfelügyelettel. Ha az első két verzió hátrányai (migrációs projekt, korábbi, meg nem térülő beruházás, nem kívánatos szervezeti átalakulás) túlságosan is fájnak, akár az is elképzelhető, hogy mindkét rendszer marad a helyén. Ekkor nincs migrációs projekt, minden korábbi befektetés ketyeg tovább, viszont a technológiai erőforrásokkal nem bánik hatékonyan a szervezet, illetve a rendszerfelügyelet emberi erőforrás igénye sem változik.
• Mindkét technológia a helyén marad, egyesített rendszerfelügyelettel. Elsőre ez egy remek ötlet. A Virtual Machine Manager  segítségével a VMware napi üzemeltetési feladatok elláthatók. Nincs migrációs projekt, nincs meg nem térült beruházás, sőt még az üzemeltetési szervezet is csökkenthető valamilyen mértékben. Persze az egyesített rendszerfelügyelet papíron szép, de egyelőre nem varratmentes megoldás. Az SCVMM számos limitációval rendelkezik, a DPM VMware-nél csak a vendég Windows rendszerekhez használható, a SCOM pedig többnyire nem egy VMware, hanem egy HP, BMC, CA vagy IBM megoldással néz szembe – az megér egy külön bejegyzést.

  Láthatjuk, hogy nincs egyetlen járható út, bármely döntésnek előnyei és hátrányai is vannak. Azt pedig, hogy melyiket érdemes választani nem kis mértében befolyásolhatja néhány egyéb tényező is. Ilyen például:

• Licenc szerződések és/vagy támogatás lejárta. Ha az egyik rendszer nagyon öreg, az a migráció felé billentheti a mérleget. Ha már nem is támogatott, az még inkább.
• A rendszer súlya. Ha az egyik egy éles környezet, a másikkal pedig legfeljebb kísérletezget az IT csapat, ott nem kétséges, hogy a homogenizáció vonzóbb lehetőség. Ha mindkét rendszer “nagy”, akkor az az együttélési szituációkat helyezi előtérbe. A “nagy” persze egy relatív fogalom, a szervezet méretéhez, változtatási képességéhez viszonyítok.
• Az üzemeltetők agilitása. Ha az egyik virtualizációs csapat önálló, lelkes és agilis, míg a másik azt sem tudja pontosan, hogy mi van a kezében, akkor ez a homogenitás megteremtése felé terelheti a döntést..
• Az informatikai szervezet érettsége. Az érettebb szervezetek kisebb költséggel, hatékonyabban és agilisen működnek. Ez könnyedén ellensúlyozni képes migrációs költségeket vagy éppenséggel egyik vagy másik termék árelőnyét. Legjobb példa erre a Microsoft 2010 nyári felmérése. A diagramokból látszik, hogy az IT érettség sokkal jobban befolyásolja a költségek alakulását, mint egy adott technolgia kiválasztása.

Azt hiszem sikerült felvillantanom, hogy a probléma sokkal összetettebb annál, minthogy csupán zsigeri preferenciák alapján szülessenek döntések. “Szerelem” helyett bölcs körültekintést ajánlok.