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.

A nevem Center. System Center.

A Microsoft pár napja bejelentette, hogy megújítja a teljes System Center termékcsaládját, hogy azok a lehető legjobb megoldást nyújtsák magán- vagy hibrid felhők kialakításához és üzemeltetéséhez. Miközben a bejelentést elég nagy csinnadratta kísérte, úgy érzem, viszonylag gyorsan napirendre tért felette az iparág. Sőt, megkockáztatom, talán nem is ért el az üzenet a mostani, vagy a potenciális felhasználókhoz. Pedig merem állítani, hogy a rendszerfelügyelet, a virtualizáció és a (magán, hibrid) számítási felhők világában az évtized egyik legfontosabb és valószínűleg egyik legkockázatosabb lépését jelentette be a cég. Néhány pontban a lényeg:

• Minden System Center termék új verzióval jelentkezik. Nincs kivétel. Az egyedi termék-életciklusokat szinkronizálta a cég.
• Minden komponens megszűnik önálló termék lenni: egyetlen terméket lehet majd vásárolni, amit úgy hívnak, hogy “System Center".
• A termékek szinte mindegyike Cross-platform képességeket kap, vagyis nem csak Windows rendszerek felügyeletét lehet majd elvégezni. A SCOM már eddig is rendelkezett ilyen képességgel, most pedig tovább erősít a hálózatfelügyelet és a Java alkalmazás szerverek területén, az SCCM-ről ezt 2011-ben az MMS-en jelentettük be, az Orchestrator mindig is ilyen volt, a Virtual Machine Managernek pedig egyik újdonsága, hogy a Hyper-V mellett vSphere és XenServer felügyeletet is ellát majd.
• A System Centernek két kiadása lesz: Standard és Datacenter – vagyis nem lesz “Enterprise”. Funkcionális különbség nem lesz közöttük, kizárólag abban térnek el, hogy hány virtuális környezetre (Virtual Operating System Environment – VOSE) engedélyezett a használatuk. Standard esetén ez kettő, Datacenter esetén korlátlan.
• A termék licencelésének alapja – szerverek felügyelete esetén – kizárólag a fizikai processzor lesz. Nem lesz szerver licence, Management Server licenc stb. Meg kell számolni a processzorok számát, a rajtuk futó virtuális gépek számát, aztán választani a Standard vagy Datacenter kiadások között.
• A System Center termékekhez automatikusan jár SQL Runtime (gyakorlatilag “megfelelő mennyiségű” SQL Standard) – amelyet persze csak a System Center komponensekhez lehet majd használni.
• A csomaghoz megjelenik egy “Unified Installer” (UnI). Ez egy olyan eszköz, amellyel egyetlen kérdőív kitöltése után a teljes csomag automatikus telepítése elvégezhető. Világos, hogy az UnI nem lesz képes minden komponens minden összetett architektúrájának lekövetésére, de amikor kis környezetek (értsd: 1000 PC alatt!!) felügyeletét kell kialakítani, akkor jó szolgálatot fog tenni.

A legfontosabb változás?

Miért gondolom, hogy ez az évtized egyik legfontosabb bejelentése a maga területén? Meglátásom szerint azért, mert ezzel a Microsoft egyszerre gerjeszt új versenyt a régi és az új piacokon.

A Microsoftot hagyományosan a négy nagy rendszerfelügyeleti gyártó – HP, IBM, Computer Associates, BMC -  mögé sorolják a piacon, azzal a megjegyzéssel, hogy a Configuration Manager és az Operations Manager a legnagyobb installált bázisú szoftverek a maguk területén. Ezekkel a cégekkel és megoldásaikkal nem triviális versenyezni: olyan sokat fektettek már be, pénzben, tudásban, képzésben stb. az ügyfelek a versenytársak szoftvereibe, hogy csak a “tétet emelve” lehet ingerküszöb fölé nőni. Velük szemben tehát az drasztikusan egyszerűsített licencelés, és egyúttal a megemelt értékajánlat jelenthet alternatívát.

Ugyanakkor a legélesebb verseny nem itt zajlik. A VMware 13 évvel ezelőtti megjelenése, majd 11 évvel ezelőtti betörése az adatközpontokba legalább olyan forradalmi volt, mint az iPhone megjelenése az okostelefonok piacán. Kezdetben mindenki a meglévő piachoz mérte őket, s abban a tekintetben (értsd: a hagyományos rendszerfelügyelet tekintetében) a VMware nem számított nagy játékosnak. Mára fordult a kocka: a vSphere család a VMware cloud megoldásai és rendszerfelügyeleti portfóliója az egyik legerősebb rendszerfelügyeleti szállítóvá predesztinálja. És legyen bármilyen bonyolult a VMware licencelése, az még mindig nagyságrenddel egyszerűbb, és még mindig olcsóbb, mint a hagyományos rendszerfelügyeleti szállítók kínálata. Okos dolog volt a VMware részéről, hogy felvásároltatta magát az EMC-vel. Ez a húzás lehetővé tette, hogy ne merüljön el az ajánlat egy HP vagy egy IBM kínálat-tengerében, és a cég az EMC védőszárnyai alatt megőrizhesse dinamizmusát. Mára már látszik, hogy a védőszárny alatt micsoda madár fejlődött ki…Meglátásom szerint a Microsoft e második kihívást talán még nagyobbnak látja – s a teljes portfólió egybegyúrása egyetlen ajánlattá ez ellen is megfelelő fegyver lehet. Ettől a pillanattól kezdve ugyanis már nem lehet csak a Virtual Machine Manager-t összehasonlítani a vCenterrel. A “minden vagy semmi” ajánlat egyúttal a “minden vagy semmi” összehasonlításokat is magával hozza. Arról már nem is beszélve, hogy a mind nagyobb helyet követelő számítási felhő megoldásoknál már nem is lehet csupán egy-egy komponensre alapozni. A cloud a rendszerfelügyelet vonatkozásában is mindent visz.

A következmények a világban

Az ügyfelekre gyakorolt legfontosabb hatás, hogy újabb szerver-konszolidációt indíthat el. Egyrészt nagyobb virtuális gép sűrűség esetén jelentős árcsökkenés érhető el, másrészt a teljes portfólió teljesebb rendszerfelügyeletet tesz lehetővé, ami a legfőbb gátja a virtualizáció és magán számítási felhők további terjedésének. A konszolidáció, no meg az x86/84 rendszerek javuló skálázhatósága tovább fogja szűkíteni a Unix rendszerek életterét (ebbe a Linux nem tartozik). A maradó rendszerek és a Linux szerverek pedig immáron natív módon felügyelhetők System Center megoldásokkal.

Azt gondolom, hogy a Microsoft döntése lépéskényszerbe hozta a hagyományos rendszerfelügyeleti gyártókat, s talán nem túlzás azt mondani, hogy hosszú távon a teljes üzleti modelljük átgondolására késztetheti őket.

Nem marad érintetlen a VMware sem. Vita tárgyát képezheti, hogy elégséges-e a Microsoft portfóliója, de abban nincs vita, hogy a Microsoft potens versenytársa immár a VMware-nek. Ugyanakkor a Microsoftnak itt nem elégséges csak a rendszerfelügyeleti termékeit csatasorba állítania. A hypervisor képességek, már pusztán a prekoncepciók miatt is, legalább akkora hatással lesznek a rendszerek kiválasztása során, mint a rendszerfelügyelet.

A következmények Magyarországon

Hogyan változik nálunk a helyzet? Magyarországon évek óta a System Center termékek csomagban vásárlását ajánlottuk az ügyfeleknek, és ők többnyire hallgattak a tanácsainkra. Számukra a változás minimális. A Datacenter változatokat processzorszámra vetítve ekvivalensen váltjuk be. Az Enterprise változatoknál pedig egy licencért változatért két standard-ot adunk, amely így megint csak értékazonos váltás lesz.. Van ugyanakkor egy olyan ügyfélkör is, akik komponenseket, tipikusan SCOM-ot vagy SCCM-et vásároltak. Attól függően, hogy van-e érvényes szoftverfrissítésük vagy sem, másképp-másképp élhetik meg a változást. A frissítés-védelemmel rendelkezők azt tapasztalhatják, hogy bizonyos átváltási arány mellett hirtelen ölükbe hullik a teljes portfolió. Ez azonnali pozitív hír. A frissítésük meghosszabbítása ugyanakkor megdrágul. Akik nem rendelkeznek frissítés-védelemmel, és csak egy komponenst vásároltak, nos ők nehezebb helyzetbe kerülnek, mivel mostantól csak a drágább csomag lesz elérhető számukra – kivéve, ha egyébként szerver konszolidáció is zajlik náluk, mivel a konszolidáció árcsökkentő hatású.

Elképzelhetők olyan vásárlók is, akik a rendszerfelügyeletük kialakítását nem egy kiforrott stratégia mentén végzik, hanem aktuális problémákra gyors és egyszerű megoldást keresnek. Nos, nekik a System Center ajánlat esetleg kevésbé lesz vonzó, bár persze adott helyzettől és ártól függhet, mit gondolhatnak a Microsoft megoldásáról.

S végül lesznek olyan ügyfelek, amelyek számára ez a System Center csomag – még a legkisebb kiszerelésben is -  egyelőre nagy és bonyolult. Számukra a Microsoft még nem mondott semmit. A bejelentés egyelőre adós a System Center Essentials jövöjének felvázolásával.

Ha mindehhez még hozzáveszem a “Windows Server 8” és a benne lévő Hyper-V új képességeit, azt hiszem nem túlzás, ha azt mondom: az izgalmak csak most kezdődnek.

A Nagy Vihar (Perfect storm)

 A perfect storm is an expression that describes
an event where a rare combination of circumstances
will aggravate a situation drastically

– Wikipedia –

Meglepően csöndesen fogadta a virtualizáció világa a nyár elején, hogy a Gartnernek az x86 virtualizációs piacra vonatkozó, 2011-es “Magic Quadrant” (MQ) elemzése a Microsoft megoldását a vezető negyedbe helyezte. Pedig megér néhány sort elmélkedni ennek a változásnak a jelentőségén, főleg a nyári, és a várható őszi események fényében.

Mi a fene az a Magic Quadrant?

A “Magic Quadrant” egy vezetői elemzői módszer, a Gartner saját találmánya. Sok mindenre használhatják: a segítségével fel lehet térképezni egy termékportfoliót, vagy – mint esetünkben – elemezni lehet egy piaci szegmenset, amely jelentős növekedéssel kecsegtet, s amelyben a versenytársak igyekeznek megkülönböztetni magukat. Egy MQ szinte soha nem egy konkrét termékre vonatkozik, hanem mindig egy üzleti problémára, amelyet a versenyben résztvevők egy vagy több termékkel és/vagy megoldással, szolgáltatásokkal igyekeznek lefedni. A Gartner jelenleg 53 piaci szegmensre végez el rendszeresen elemzéseket, ezek egyike az x86 virtualizáció piaca. Az elemzések között vannak régóta vezetettek és egész újak is – a szóban forgó virtualizációs elemzés az utóbbiak közé tartozik, másodszor jelent meg. A MQ végterméke egy tanulmány, benne egy 4×4-es tábla, amelyben a felmérés eredményeként a Gartner elemzői elhelyezik a piaci szereplőket. Nagyjából így:

 

Az elemezés kétféle koordinátát tartalmaz, a végrehajtási képességet (Ability to Execute) és a vízió teljességét (Completness of Vision). Nézzük röviden, melyik mit takar.

A végrehajtás képessége (Ability to Execute)
Maga a végrehajtás képessége is egy összetett mutató, amelyet eltérő súlyozással az alábbi vizsgált tényezők alkotják:

• Termékek/szolgáltatások
• Általános életképesség (Overall Viability
• Kereskedelmi tevékenység és árazás.
• Piaci reagálóképesség a jelenben és a múltban
• Marketing tevékenység végrehajtás (Marketing execution)
• A felhasználók tapasztalatai (Customer Experience
• Üzemmenet (Operations

Sajnos meghaladja a cikk terjedelmét mindegy egyes tényező kifejtése, akit érdekel, azt a cikk végén található hivatkozásnál elolvashatja. Amire érdemes odafigyelni az az, hogy a tényezők a jelenre és a múltra, valamint a konkrét végrehajtásra összpontosítanak.

A vízió teljessége (Completness of Vision)
Ahogy az előző, úgy ez a koordináta is egy meglehetősen összetett dolog, amely az alábbi tényezőket egyesíti:

• A piac megértése (Market Understanding)
• Marketing stratégia (Marketing Strategy)
• Kereskedelmi stratégia (Sales Strategy)
• Termékstratégia (Offering (Product) Strategy)
• Üzleti modell (Business Model)
• Vertikális/iparági stratégia (Vertical/Industry Strategy)
• Innováció (Innovation)
• Földrajzi stratégia (Geographic Strategy)

Részletekre itt sincs mód, de megint csak érdemes észrevenni, hogy itt a gyártók (nyilvános) terveit, elképzeléseit elemzi a Gartner, vagyis a jelen és a jövő a fő szempont

A Magic Quadrant negyedei
A kétféle dimenzió mentén végül négy területre osztja a piacot a Gartner:

• Vezetők (Leaders) – Jól teljesítenek a piacon és jól pozícionálják magukat a jövőre tekintettel.
• Vízionálók (Visioners) – Értik merre tart a piac, vagy van elképzelésük arról, hogyan igazodjanak a változó piachoz, de a jelenlegi végrehajtás nem elég jó .
• Kihívók (Challengers) – Jól működnek, esetleg dominálják a piac egyes részeit, de nem mutatják, hogy kellően értenék merre tart a piac, illetve hogyan változnak az igények.
• Réspiaci szereplők (Niche players) – Kétféle szereplő is előfordulhat itt: Vannak, akik kis szereplők, de jól fókuszálnak egy-egy részterületre. Emellett vannak, lehetnek globális szereplők, akik nem fókuszáltak, és nem elég innovatívak vagy nem teljesítenek elég jól a piacon.

Mire kapunk választ egy MQ-ban?
Látható, hogy a végeredmény látszólag egyszerű, az értékelési szempontok viszont egyáltalán nem azok. Gyakori hiba egy-egy MQ értelmezésnél, hogy a teljes mutató helyett csupán egy-egy tényezőt “lát bele” az olvasó az elemzés eredményébe. Azt például semmiképp sem mondhatjuk, hogy a függőleges tengely csak marketing és kereskedelem, a vízszintes meg technológia. Egy MQ végeredményben olyan kérdésekre próbál választ adni, hogy:

• Mely gyártók a számottevő szereplők a piacon?
• Ki vagy kik a piacvezetők?
• Érdemes-e egy adott technológiánál egy adott megoldás szállítóját figyelembe venni?
• Milyen a versenyzők egymáshoz viszonyított helyzete?
• Mire kell készülni egy gyártó kiválasztása esetén? (Pl.: előremutató technológia és innováció, de gyenge támogatás stb.)
• A megoldásoknak, gyártóknak  milyen erős és gyenge pontjaik vannak?

Vagyis egy MQ egy döntést segítő, azt előkészítő tanulmány, olyan szakértőktől, akiknek napi feladata ezt a technológiai szegmenset és a szereplőket figyelni. Fontos tudni, hogy az MQ erősen épít az ügyfelektől kapott visszajelzésekre. Végeredményben ők látják ilyennek, vagy olyannak a megoldásokat.

Változások és elemzések az új kiadásban
A 2010-es és 2011-es éveket összevetve jó néhány változás látható. Eltűnt a Novell, ennek oka, hogy felvásárolták, s a tanulmány készítésének időszakában még nem dőlt el a SUSE részleg sorsa. Jövőre valószínűleg visszatér a most már leválasztott SUSE csapat. Az elmúlt évben az Oracle racionalizálta a portfólióját, ezért már csak egyszer szerepel. A Citrix erősített a végrehajtásban, ezért a vezető negyedbe került. Végül a Microsoft egy jobb piaci megértést, illetve innovatívabb portfóliót mutatott fel, ezért jobbra mozdult, így szintén bekerült a vezető negyedbe. Érdemes megnézni azt is, mit ír a Gartner a piac két legnagyobb szereplőjéről.

• VMware:  Erőssége a stratégia és a tervei a magán és hibrid számítási felhőkre vonatkozóan. (Naná, ők fújják a passzát szelet!). Technológiai vezető és innovátor. Magas ügyfél-elégedettség és nagy installált bázis, különösen az (amerikai értelemben vett) nagyvállalatok és technológiai szolgáltatók körében. A VMware-nek a Gartner szerint oda kell figyelnie árbevétel növekedésre, tekintettel arra, hogy a nagyvállalati szegmens telítődik, a kis- és középvállalatok viszont alacsonyabb árakat várnak. Figyelnie kell arra, hogy továbbra is figyeljenek rá – erősödik a verseny a Microsofttal. Végezetül az elemzők felhívják a figyelmet, hogy a VMware függ az olyan kihívásokkal teli piacoktól mint az IT szolgáltatás automatizáció.
• Microsoft: erőssége, hogy a virtualizációs rendszerfelügyelet ismerős lehet a Windows üzemeltetők számára. Erős Windows Server pozíciói vannak az (amerikai értelemben vett!) középvállalatoknál. Ezen cégekhez jó megoldásokat és árakat ad. Végezetül a Microsoft az Microsoft, vagyis egyike a négy AAA cégnek a S&P500-as listáján (értsd: a cég pénzügyi helyzete stabil). A Microsoftnak figyelnie kell arra, hogy nehéz lesz átkonvertálnia vagy körbebástyáznia a VMware installált bázisát, különösen a nagyvállalatoknál. Az MS erős versenyre számíthat a partneri csatornákért és a szolgáltatókért folytatott küzdelemben. Végül a Gartner szerint gond az, hogy a Hypervisor szülő partíciója Windows.

Érdekes megállapítás – de általam is tapasztalt tény – hogy a VMware magas árai, és az abból képzett partneri kedvezmény miatt a partnerek szívesebben árulják a “jövedelmezőbb” megoldást.

A 2011-es elemzés jelentősége
A legnagyobb és legfontosabb változás kétségkívül a Microsoft vezető negyedbe való belépése. Számos  nagy informatikai szervezet ugyanis szinte csak akkor áll szóba egy-egy szállítóval egy adott megoldással kapcsolatban, ha az már a vezető negyedben van. Erre a tanulmányra komoly ajtók nyílnak meg. Mindezt ráadásul a 2009-es, tehát a már nem egészen mai gyerek Hyper-V-vel és SCVMM-mel érte el a cég!

A Nagy Vihar
A nyár folyamán néhány esemény tovább növelte a piacon a feszültséget és a várakozásokat. Júliusban a VMware bejelentette a vSphere családja új generációját, nem mellesleg az új licencelési elveit is. Ez meglehetősen sok ellenérzést váltott ki – és ekkor nagyon finoman fogalmaztam. (Kollégáim két hosszú cikkben elemezték a történteket és a következményeket itt, meg itt.) Az VMware ügyfelek elégedettsége erőteljesen csökkent és a megbízható szállítói mivolta megkérdőjeleződött. Sokáig fog tartani, mire a helyi mérnökök ezt a csorbát szorgos munkával kiköszörülik, ha egyáltalán ez lehetséges. De ez még mindig nem a vége. A Microsoft augusztus folyamán elkezdte csepegtetni az új generációs operációs rendszeréről az információkat, és már mindenki tudja, hogy az igazán fontos bejelentések a jövő heti BUILD konferencián várhatók. Vigyázó szemetek Anaheim-re vessétek!

Azt hiszem, hogy a Gartner által kinyilvánított MS vezetői pozíció, a VMware ügyfél-elégedettségi fiaskója és a teljes Windows kínálat (kliens, szerver, Phone és Azure) valamint System Center termékcsalád minden tagjának új verziója együtt egy igazi tökéletes vihar. Előszélnek megteszi ez: Bringing Hyper-V to Windows “8”. Izgalmas ősz következik !

Keddtől BUILD!

A Microsoft számítási felhő megoldásai

A kezdeti alapozó cikkek után azt gondoltam érdemes lenne megvizsgálni, hogyan hat a számítási felhő, mint működési modell megjelenése az informatikai ipar egyes szegmenseire, a versenyre, ezen belül a Microsoft stratégiájára. Ez az elemzés ugyanakkor a levegőben lógna, ha legalább néhány sorban nem ismertetném a Microsoft jelenlegi felhő megoldási portfolióját. Először minden egyes szolgáltatás logóját be szerettem volna vágni, de aztán annyi jött össze, hogy inkább dobtam az ötletet és egy összefoglaló ábrát kerestem. Sikerült is halászni egyet, megpróbálom egy-két mondatban ismertetni a fontosabb ajánlatokat. Szerencsére az ábra szerkezete követi a korábban leírtakat és a szolgáltatási modellek szerint csoportosítja azt, amit a Microsoft ma tud.

Windows Live szolgáltatások

Ugyan alapvetően nem üzleti szolgáltatásról van szó, de ezer szállal kötődi azokhoz, egyéb iránt pedig minden Microsoft SaaS megoldás ősének tekinthetők. Önkényes módon a “Live” szolgáltatásokat kétféle csoportba soroltam: úgy érzem, vannak inkább “platform” elemek, és aztán arra épülő “alkalmazások”. Kezdjük a platform elemekkel.

• Windows Live ID (“platform”)– Ez a hitelesítési mechanizmus az alapja az összes Microsoft online szolgáltatásnak szóljon üzleti vagy otthoni felhasználókhoz. Annak idején mindenki felhördült amikor a Microsoft úgy próbálta pozícionálni még 2001-2002 környékén ezt a szolgáltatást, mint az Internet potenciálisan egyetlen és egységes identitás kezelő rendszere. Aztán tessék megnézni, hol tartunk ma? Senki sem ágál különösebb ellene, hogy egy másik cég tényleg meg is csinálta azt, amit az MS szeretett volna. A céget úgy hívják: Facebook.
• Skydrive (“platform”) – Online adattárolási rendszer 25 GB tárhellyel. Integrált a levelezési, a webes Office és a fényképmegosztó szolgáltatással. A Mesh-sel egyelőre nem, de logikus következő lépés lenne.
• Hotmail (“alkalmazás”): 1998 óta a Microsoft első számú, és azóta is versenyképes webes levelező rendszere. Mára online  naptár és névjegyalbum szolgáltatással is rendelkezik, a böngésző(k) mellett elérhető az Office Outlookjából és mobiltelefonokról is.
• Messenger (“alkalmazás”): azonnali üzenetküldő szolgáltatásnak indult, de ma már inkább mondanám a közösségi hálók legjobb helyben  futtatható kliens-alkalmazásának. Ennek a közösségi jelenlétnek a része a csevegés, hang és/vagy képi kapcsolat. A közösségi hálózat lehet a Windows Live, a Facebook, a LinkedIn és a Myspace is.
• Windows Live Profile (“alkalmazás”): A Windows Live azonosítóhoz megadhatunk magunkról mindenféle adatot, kapcsolatokat építhetünk a barátainkkal (akiknek az adatai aztán a Live névjegyalbumban és a Messenger kapcsolataink között visszaköszönnek.) A Live Profile integrálni képes a különböző közösségi hálózatokból érkező eseményeket, leveleket, megosztásokat stb.
• Windows Live Mesh (“alkalmazás”): Fájl szinkronizációs szolgáltatás különböző eszközök között (PC, Notebook, Home szerver, média center, cloud)

A Windows Live szolgáltatásokhoz szorosan kapcsolódnak az Office Live szolgáltatások. Korábban az Office Live két részből állt: az Office Live Workspace-ből és az Office Live Small Businessből. A megcélzott közönség az otthoni felhasználók és a kisvállalatok voltak. Az élet azonban rohan, ezek a szolgáltatás is átalakulnak. Az Office Live Workspace utódja az Office Web Apps on Skydrive. Ez a megoldás tartalmaz böngészőből elérhető webes Office alkalmazásokat és Skydrive tárhelyet, ámde úgy, hogy a tárhely a hagyományos Office alkalmazásokból is elérhető. (Lásd alábbi kép)

Az Office Live Small Business képességei a jövőben az Office 365 szolgáltatásban élnek majd.

Office 365

A júliusban véglegesedő szolgáltatás a Microsoft SaaS portfóliójának zászlóshajója. Egyrészt jelent egy új licencelési modellt (nem tárgyaljuk most), másrészt egy csomó, számítási felhőből elérhető szolgáltatást, úgy mint:

• Exchange Online – levelezés, címtár, feladat- és naptárkezelés.
• Sharepoint Online – csoportmunka, együttműködés.
• Lync Online (ma még Office Communictions Online) – online jelenlét, csevegés, pc-pc hangkapcsolat.
• Office Web alkalmazások – böngészőből elérhető és működő Word, Excel, Powerpoint, Outlook, Onenote.

Az Office 365-öt kiegészít jó néhány, többnyire levelezéssel kapcsolatos szolgáltatás: ForeFront Online Protection for Exchange (malware- és levélszemét szűrés) Exchange Online Archiving (levelezés archiválás), Exchange Hosted Encryption (levéltitkosítás).

Az Office 365-nek vannak/leszek speciális ajánlatai is, például felsőoktatási intézmények számára. (Live @ Edu)

További, üzleti felhasználóknak szánt szolgáltatások:

• Microsoft Dynamics CRM Online A első fecske a Microsoft üzleti alkalmazás portfóliójából.
• Windows Intune – A Microsoft desktop felügyeleti rendszerének szolgáltatás alapú változata. (hardver- és szoftver leltár, vírusvédelem, riasztások, távfelügyelet.)
• TellMe – Hangintegrációs szolgáltatás. Telefonos (Bing Voice), TV-s (Kinect), Autós (Ford Sync) és PC-s szoftverekben egyaránt megtalálható.
• Bing – térkép és keresési szolgáltatások integrálása vállalati környezetbe.

Platform szolgáltatások

A Microsoft platform szolgáltatásai mögé általában odabiggyesztik az “Azure” szócskát, azért, mert a szoftver nevek megegyeznek a helyben telepíthető változatokkal. Beszélhetünk ezek alapján Windows szerverről és Windows Azure-ról, SQL szerverről és SQL Azure-ról stb. Egy felsorolás szerű ismertetés:

• Windows Azure – Egy számítási felhőben futó operációs rendszer, amelynek feladata az ezen operációs rendszerre írt alkalmazások futtatása. Sok tekintetben persze különleges operációs rendszer, hiszen a feladata a rajta futó alkalmazás jó válaszidejének biztosítása, automatikus skálázása, felügyelete, bárol és bárhányan használják is azt. Ezért aztán olyan képességekkel is ellátták, amelyek a hagyományos környezetben még nemigen fordulnak elő. Ilyenek például a Content Delivery Network, a Virtual Network, és a Virtual Machine futtatás. Kevéssé ismert, de Windows Azure-ra nem csak .Net segítségével lehet fejleszteni, hanem PHP, Java, Ruby, Python és Eclipse is a fejlesztők rendelkezésére áll.
• SQL Azure – Az Azure szolgáltatás család számítási felhőre írt adatbázis kezelője. Feladata természetesen az adattárolás a Storage képességgel, a lekérdezések kezelése vagy éppen a üzleti intelligencia alkalmazások kiszolgálása.
• Windows Azure Appfabric – Számítási felhő alapú middleware alkalmazás, amelynek a segítségével helyi és felhőben futó komponenseket lehet összekötni. A főbb komponensei: Service bus, a hozzáférés vezérlés, gyorsítótárazás és a (biztalk) integráció.

Az Azure-hoz tartozik egy Piactér is, ahol egyrészt fellelhetők az Azure platformon futó adatszolgáltatók, valamint azok a független szoftvergyártók, amelyek a saját SaaS ajánlatukhoz a Windows Azure-t választották platformnak.

Infrastruktúra szolgáltatások

Akinek eddigre Microsoft mérgezése lett, azt el kell szomorítanom: a legerősebb alkalmazás portfóliót még nem is ismertettem. A cikk szempontjából viszont  ez szakasz rövidebb lesz, azon oknál fogva, hogy az IaaS szolgáltatások a legismertebben a Microsoft portfoliójából, meg azért is, mert ezeknek a termékeknek vagyok a szakértője és a későbbiekben sokkal-sokkal részletesebben szeretnék róluk írni. Tehát most ismét csak felsorolásszerűen:

• Windows szerver – Általános célú hálózati operációs rendszer hitelesítéshez (Active Directory, ADFS) hálózati szolgáltatásokhoz (DNS, DHCP, NAP,VPN,  RRAS, Direct Access stb. stb.), alkalmazások futtatásához, virtualizációhoz, terminál szolgáltatáshoz stb. stb.
• Hyper-V – A Microsoft bare metal hypervisora az IaaS rendszerek virtualizációs alapja.
• A System Center termékcsalád – Desktop és szerver, Microsoft vagy más gyártó, fizikai és virtuális komponensek teljes körű felügyeletét célul kitűző rendszerfelügyeleti család. System Center Operations Manager, Configuration Manager, Service Manager, Orchestrator, Data Protection Manager, Virtual Machine Manager.
• VMM Self Service Portal 2 – A magán számítási felhők absztraktciós rétege önkiszolgálási és költségszámítási képességekkel.
• Dynamic Datacenter Toolkit – Adatközpont szolgáltatók számára IaaS szolgáltatás építését biztosító megoldás.
• ForeFront Identity Manager – Hitelesítő és hozzáférési rendszerek felügyelete önkiszolgáló képességekkel helyi számítási felhő szolgáltatások kialakításához

Összegzés

Azt gondolom az iménti egyáltalán nem rövid – de még így sem teljes körű – felsorolás több dolgot is megmutat. Egyrészt azt, hogy a számítási felhők messze többet jelentenek, mint a virtualizáció újracsomagolása. Jelenti továbbá azt, hogy a Microsoft nem a levegőbe beszél, amikor azt állítja, hogy a fejlesztői túlnyomó részét számítási felhők kialakítására és megújítására állította át. Végül előre vetíti, hogy a számítási felhők az iparági hagyományos versengést egészen átalakítják, megváltoztatják – de erről majd legközelebb írok.

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.

Virtualizáció és magas rendelkezésre állás – 6

Elérkeztünk az utolsó alkalmazás elemzéséhez, s amilyen összetett architektúrákat lehet megálmodni, olyan egyszerű maga táblázat:

Kieső komponens	RAC – fizikai	Ora – VMware HA-val	Ora – Hyper-V clusterrel	Ora – VMware FT-vel	RAC VMware HA-val	RAC Hyper-V clusterrel	RAC VMware   FT-vel
Adatbázis	x	NS	NS	NS	NS	NS	NS
Alkalmazás	x	NS	NS	NS	NS	NS	NS
Operációs rendszer	x	NS	NS	NS	NS	NS	NS
Szerver hardver	x	NS	NS	NS	NS	NS	NS
SAN kapcsolat	x	NS	NS	NS	NS	NS	NS
SAN tároló	x	NS	NS	NS	NS	NS	NS
Teljes telephely	x	NS	NS	NS	NS	NS	NS

Az Oracle úgy látja jónak, hogy harmadik gyártó virtualizációs platformján nem támogatja a saját szoftvereit, pontosabban az ügyfélnek bizonyítania kell, hogy a probléma, amelyet bejelentett, nem áll kapcsolatban a hamadik fél hypervisorával. (Bővebben itt: http://oraclestorageguy.typepad.com/oraclestorageguy/2009/04/what-the-oracle-vmware-support-statement-really-meansand-why.html) Azoknál, akiknél az adatbáziskezelő szabvány az Oracle adatbáziskezelője, a virtualizációs szabvány pedig Vmware vagy Hyper-V, egyetlen út marad: fizikai környezetben maradni. Mivel még egy esetleges támogatás meglétekor sem bírna olyan képességekkel a rendszer, mint natív környezetben (mint azt a korábbi alkalmazáoknál láttuk), igazából ez talán nem is fáj. Következtetésem az Oracle RAC esetén hasonló, mint korábban: az alkalmazás szintű magas HA/FT megoldások nem nélkülözhetők.

A cikksorozat elején kiválasztottunk négy alkalmazást, amelyek egymástól eléggé eltérő módon biztosítják a magas rendelkezésre állás lehetőségét, mostanra kiderült, hogy bármely megoldás elhagyása azt jelenti, hogy a virtualizációs HA/FT-vel felépített rendszerünk bizonyos típusú, ritkának és különlegesnek nem mondható szituációkat nem kezel le. Nézzük meg a sorozat elején feltett kérdéseket:

• Virtualizációs HA megoldással magasabb rendelkezésre állást leszünk-e képesek elérni olyan szolgáltatás esetén, amelyet korábban semmilyen HA vagy FT technikával sem védtünk? – Még nem válaszoltunk a kérdésre, egyelőre többszörözött rendszerekkel foglalkoztunk.

• Virtualizációs HA megoldással magasabb rendelkezésre állást tudunk-e elérni olyan szolgáltatás esetén, amely korábban rendelkezett saját HA/FT megoldással, de a virtualizálás során ezt megszűntettük? (“Nincs már rá szükség” felkiáltással.) – A vizsgálat alapján kijelenthetjük, hogy nem tudunk magasabb rendelkezésre állást elérni, sőt, az eredeti szintet sem érjük el, függetlenül attól, hogy virtualizációs oldalon HA vagy FT, ESX vagy Hyper-V az építőkocka.

• A kérdést úgy is feltehetjük, hogy az egyedi szolgáltatás-szintű HA megoldások helyett lehet-e egységes virtualizációs HA megoldást alkalmazni a szolgáltatásokra? Vagy még másképpen: kiváltja-e a Virtualizációs HA megoldás az alkalmazás szintű HA megoldásokat? – Sem nem lehet egységes HA megoldást alkalmazni, sem pedig azt nem állíthatjuk, hogy a virtualizációs HA/FT megoldások kiválthatnák az eredeti architektúrákat.

• Virtualizációs HA megoldással tudunk-e TOVÁBBI rendelkezésre állást nyerni olyan szolgáltatások esetén, amelyeknek a virtualizációs projekt előtt volt saját HA/FT megoldása és ezt a projekt után is megtartottuk? – Ha pusztán a HA/FT megoldásokat figyeljük, akkor erre NEM a válasz.

Persze koránt sem varrtunk el minden szálat, a cikksorozat következő részeiben az alábbi kérdésekre keresünk válaszokat:

• virtualizáció technológiája (izoláció, provizionálás, standard környezet, snaphost technológia) miképp befolyásolja a szolgáltatás rendelkezésre állását?
• A HA és FT megoldások hajszálra egyformán szerepeltek a táblázatokban. Tényleg semmi különbség nincs köztük, vagy valamit nem vizsgáltunk? Azért mégsem mindegy, hogy HA vagy FT, nem?
• Mi az előnye – ha van – az Exchange kiszolgálók guest clustering-be szervezésének?
• A fail-over cluster rendszerek kiváltását hypervisor HA-ra azzal is indokolni szokták, hogy így Windows szerver licencet lehet megtakarítani, hiszen Enterprise Edition helyett elegendő a Standard használata. Igaz ez?
• Az első részben feltételeztük, hogy “mindent egyformán jól tudunk üzemeltetni”. Mi történik, ha ezt a peremfeltételt elhagyjuk?

Marad tehát bőven témánk, folytatjuk…

Virtualizáció és magas rendelkezésre állás – 5

Két alkalmazásnál már úgy láttuk, hogy a szolgáltatás szintű magas rendelkezésre állás nem elhagyható opció. Nézzük most meg az Exchange-et. Elvégre AD és NLB elérhető egy Windows Standard változattal is, Exchange clusterhez viszont minimum Windows Enterprise Edition szükségeltetik, tehát pénzre megy a játék(*). A korábbi táblázatunk Exchange alkalmazásra vonatkoztatva az alábbiak szerint alakul:

Kieső komponens	Exch – DAG fizikai	Exch – VMware HA-val	Exch – Hyper-V clusterrel	Exch – VMware FT-vel	Exch DAG VMware HA-val	Exch DAG Hyper-V clusterrel	Exch DAG VMware   FT-vel
Adatbázis	x				NS	NS	NS
Alkalmazás	x				NS	NS	NS
Operációs rendszer	x				NS	NS	NS
Szerver hardver	x	x	x	x	NS	NS	NS
SAN kapcsolat	x	x	x	x	NS	NS	NS
SAN tároló	x	x(*)	x(*)	x(*)	NS	NS	NS
Teljes telephely	x	x(*)	x(*)	x(*)	NS	NS	NS

A táblázat bal fele – most már mondhatjuk – a szokásos. Az alacsonyabb logikai rétegben dolgozó virtualizációs HA  képtelen bizonyos szituációkat lekezelni. Ráadásul  a le nem kezelt szituációk még talán gyakoribbak, mint a lekezeltek, főleg ha azt is számítjuk, hogy a táblázat nem csak a nem tervezett, de a tervezett leállásokat is tartalmazza. Azt nem mondom, hogy egy adatbázis szétesés mindennapi eset, de egy javítócsomag telepítés az alkalmazásra vagy az operációs rendszerre már sokkal inkább. A következtetésem ismét ugyanaz, mint korábban: lemondani az alkalmazás szintű Exchange fürtözésről és pusztán a virtualizációs HA/FT megoldásokra támaszkodni – ez visszalépés a magas rendelkezésre állás biztosítása terén.

A táblázat jobb oldala már újdonság. NS, vagyis “not supported” (nem támogatott). A pontos megfogalmazás így hangzik:

“Microsoft doesn’t support combining Exchange high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers. DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn’t employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.”

Forrás: http://technet.microsoft.com/en-us/library/aa996719.aspx

Mielőtt bárki csúnya-csúnya microsoftozna, íme a VMware álláspont:

Before you set up MSCS, review the list of functionality that is not supported for this release, and any
requirements and recommendations that apply to your configuration.The following environments and functionality are not supported for MSCS setups with this release of vSphere:
* Clustering on iSCSI, FCoE, and NFS disks.
* Mixed environments, such as configurations where one cluster node is running a different version of ESX/ESXi than another cluster node.
* Clustered virtual machines as part of VMware clusters (DRS or HA).
* Use of MSCS in conjunction with VMware Fault Tolerance.
* Migration with VMotion of clustered virtual machines.
* N-Port ID Virtualization (NPIV)
* With native multipathing (NMP), clustering is not supported when the path policy is set to round robin.
* You must use hardware version 7 with ESX/ESXi 4.0.

Forrás: www.vmware.com/pdf/vsphere4/r41/vsp_41_mscs.pdf

Ez az utóbbi cikk egyébként nagyon pontos, és számos együttélési problémára rávilágít (RDM lezemek, egyáltalán storage kezelés, multipath, clustered vmdk, 2003 vs 2008 fürtök stb stb.) érdemes olvasgatni. Ha a táblázat bal oldala szerint a virtualizációs HA/FT megoldások csökkentik a rendszer képességét, hogy különböző meghibásodásokra reagáljon, a jobb oldala pedig a “nem támogatott” helyzetbe sodorna minket, a következtetés egyértelmű: ha komolyan gondoljuk az Exchange adatbázis kiszolgálók magas rendelkezésre állását, akkor Exchange Mailbox Store szerepkört nem keverünk össze virtualizációs HA/FT megoldással.

Ez viszont nem jelenti azt, hogy ne lehetne egy mailbox szerepkört virtualizálni. Lehet, guest clustering segítségével – ez a téma viszont nem tartozik szorosan a tárgyhoz, majd máskor tárgyaljuk.

Még egy fontos dolgot tisztáznunk kell. Vajon minden fail-over clusteres alkalmazás esetén azonos szabályokat kell alkalmaznunk? Ez egyáltalán nem biztos. Az eredeti alkalmazások között ugyan nem szerepel, de érdekes példa lehet a Microsoft SQL szerver. Szemben az Exchange csapattal, itt a host + guest cluster támogatott.

• Guest Failover Clustering is supported for SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 in a virtual machine for the supported hardware virtualization environments listed in this article provided all of the following requirements are met: 
  • The Operating System running in the virtual machine (the “Guest Operating System”) is Windows Server 2008 or higher
  • The virtualization environment meets the requirements of Windows 2008 Failover Clustering, as documented in the following Microsoft Knowledge Base article:

    943984 (http://support.microsoft.com/kb/943984/ ) The Microsoft Support Policy for Windows Server 2008 Failover Clusters

[…]

Q5: Is Quick and Live Migration with Windows Server 2008 R2 Hyper-V supported with SQL Server?
A5: Yes, Live Migration is supported for SQL Server 2005, SQL Server 2008, and SQL Server 2008 R2 when using Windows Server 2008 R2 with Hyper-V or Hyper-V Server 2008 R2.Quick Migration, which was introduced with Windows Server 2008 with Hyper-V and Hyper-V Server 2008, is also supported for SQL Server 2005, 2008, and 2008 R2 for Windows Server 2008 with Hyper-V, Windows Server 2008 R2 with Hyper-V, Hyper-V Server 2008, and Hyper-V Server 2008 R2.

Forrás: http://support.microsoft.com/?id=956893

Furcsa fricska, hogy az előbb idézett vSphere dokumentum általánosan a Microsoft cluster megoldásra vonatkozik, tehát az SQL szerverre is, míg a Microsoft a maga részéről a guest clustered SQL kiszolgálók migrációját nem bánja.

Végeredményben tehát két dolgot legalább meg kell tanulnunk:

1. A fail-over cluster – NEM ELHAGYHATÓ magas rendelkezésre állást biztosító technológia.
2. A guest fail-over cluster és a host cluster megoldások vagy egyáltalán nem keverhetők, vagy pedig erősen meg kell nézni, hogy mely gyártó mely alkalmazásnál milyen megkötéseket ad meg.

Folytatjuk…

—————

(*) – Ezt az “érvet” még elemezzük egy későbbi cikkben

Virtualizáció és magas rendelkezésre állás – 4

Az előző cikkben az AD-t elemeztük, de persze komolyan senki sem gondolhatja – virtualizáció ide vagy oda – hogy egyetlen kiszolgálóra bízza ezt a szolgáltatást. Most nézzük meg, hogy egy alapvetően más módszert alkalmazó szoftvernél mi a helyzet. Az IIS rendelkezésre állásának növelésére hagyományosan NLB-t alkalmaznak. Az AD mintájára készítsük el újra a táblázatunkat

Kieső komponens	IIS – NLB, fizkai	IIS – VMware HA-val	IIS – Hyper-V clusterrel	IIS – VMware FT-vel	IIS – NLB-vel és VMware HA-val	IIS NLB-vel és Hyper-V clusterrel	IIS NLB-vel és FT-vel
Adatbázis
Alkalmazás	x				x	x	x
Operációs rendszer	x				x	x	x
Szerver hardver	x	x	x	x	x(*)	x(*)	x
SAN kapcsolat	x(*)	x	x	x	x	x	x
SAN tároló	x(*)	x(*)	x(*)	x(*)	x(*)	x(*)	x(*)
Teljes telephely	x(*)	x(*)	x(*)	x(*)	x(*)	x(*)	x(*)

Szinte teljesen azonos táblázatot kaptunk, mint az előző cikkben. Az eredeti táblázatból tudjuk, hogy az NLB nem foglalkozik azzal, hogy az IIS átal szolgáltatott tartalom mennyire jó, ha az IIS fut, akkor az NLB könyörtelen oszt rá felhasználókat, akik hibaüzeneteket kapnak vissza.

Az IIS leállását semelyik virtualizációs technológia sem veszi észre: ha működik az operációs rendszer, de az IIS nem, az a host cluster megoldásokat nem zavarja.. Az NLB elhagyása még akkor is elfelejtendő, ha csak a rendelkezésre állásra ügyelünk és a terheléselosztással nem is számolunk.

Ha visszahozzuk az NLB-t, akkor jobbára visszakapjuk az eredeti, virtualizáció nélküli megoldásunkat, de azért a szerver hardverek kiesésénél nem árt ügyelni a cluster helyes konfigurációjára. Mind a VMware HA esetén, mind pedig a Hyper-V-nél be KELL konfigurálni az anti-affinitás szabályokat, amellyel elérhetjük, hogy a két vagy több VM, amely IIS-t futtat NLB-vel, lehetőleg külön fizikai szerveren fusson, ellenkező esetben egy esetleges szerver meghibásodás mindenképpen leállással jár – a fizikai környezetben ilyen szituáció nem fordulhat elő. A VMware megoldásánál tehát mindenképp Distributed Resource Schedulerre (DRS) van szükség, ez viszont csak a drágább kiadásokban érhető el. Ez pedig súlyos következményekkel jár: egy virtualizált NLB farmnak lehet kisebb a rendelkezésre állása, egy fizikai implementációhoz mérve – Vmware fault-tolerant ide vagy oda. Az én végkövetkeztetésem: az NLB nem váltható ki semmilyen host cluster megoldással, és még együttes alkalmazásuk is odafigyelést igényel.

Folytatjuk…..

Virtualizáció és magas rendelkezésre állás – 3

Amikor virtuális környezetbe költöztetjük a szolgáltatásainkat futtató operációs rendszereket, dönthetünk arról, hogy megtartjuk, vagy elhagyjuk a korábban alkalmazott HA vagy FT megoldásokat. Ráadásul virtualizáció implementálásakor használhatunk HA helyett FT-t is – legalábbis VMware esetén. Mivel ez így meglehetősen széles választék, nézzük alkalmazásonként, hogyan változik a táblázatunk. Kezdjük az AD-vel.

Kieső komponens	AD fizkai, 2 DC	AD – VMware HA-val	AD – Hyper-V clusterrel	AD – VMware FT-vel	AD – két DC-vel és VMware HA-val	AD – két DC-vel és Hyper-V clusterrel	AD -  két DC és VMware FT-vel
Adatbázis	x				x	x	x
Alkalmazás	x				x	x	x
Operációs rendszer	x				x	x	x
Szerver hardver	x	x	x	x	x	x	x
SAN kapcsolat	x	x	x	x	x	x	x
SAN tároló	x	x(*)	x(*)	x(*)	x(*)	x(*)	x(*)
Teljes telephely	x	x(*)	x(*)	x(*)	x(*)	x(*)	x(*)

Ez egy nagyon érdekes táblázat. Az első két oszlopa azt a szituációt mutatja, amikor elhagyjuk a dupla tartományvezérlőt. Sajnos sem a VMware HA, sem a Hyper-V cluster nem óv meg bennünket az AD adatbázisok megsérülése esetén a szolgáltatás kiesésétől. Sőt! Ugyanez a helyzet a VMware FT esetén is. Persze a dolog érthető: mindkét HA megoldás alacsonyabb rétegben dolgozik. Ráadásul még kiosztottam mindkét oszlopban egy csomó csillagot. Lássuk a magyarázatot:

1. SAN kapcsolat bontása esetén a VMware HA fürt adott kiszolgálóján a virtuális gépek elhasalnak és egy másik kiszolgálón indulnak el
2. Ugyanebben a szituációban a Hyper-V cluster redirekciót hajt végre és a VM-ek tovább üzemelnek.
3. Szerver hardver meghibásodás esetén a VMware FT által védett tartományvezérlős VM hibátlanul üzemel tovább
4. SAN kapcsolat vesztésnél a VMware FT által védett tartományvezérlős VM hibátlanul üzemel tovább
5. SAN tároló összeomlásakor mindhárom megoldásnál kézzel kell elindítani egy site-failover tevékenységet – már persze ha erre felkészültünk. Ugyanez a helyzet teljes telephely összeomláskor. Egyik esetben sem olyan automatikus az átállás mint a két telephelyen, egymástól függetlenül üzemelő tartományvezérlők esetén, a horribilis költségekről már nem is beszélve.

   Most gondoljuk el, hogy milyen szituációk esetén nem véd ez az architektúra:

• AD meghibásodás
• OS indulási problémák (sérült boot sector, kékhalál stb.)
• OS rendszeres karbantartás (havi frissítések)
• OS átkonfigurálás, ha újraindítással jár.

Az előző cikkben említettem, hogy érdemes mérni a magas rendelkezésre állás működését, a hibákat, az átállásokat stb. Ha ezt nem tesszük, akkor nem tudjuk, hogy a fenti felsorolás az összes kiesés hány százalékát érinti. Látatlanban én azt mondom, hogy ez a négy pont nem elhanyagolható.

A másik három oszlopnál visszatér a “teljes” védelem, de ezt nem a virtualizációs HA megoldásoknak, hanem az alkalmazás belső védelmének köszönhetjük. Ráadásul ha virtuális gép költöztetéses megoldást választunk az AD esetén akkor az 5. pont itt is érvényes. Összességében a táblázatból az szűrhető le, hogy IGEN NAGY HIBA lenne elhagyni az AD esetén a saját maga által biztosított magas rendelkezésre állást. Virtualizációval ezen csak rontani lehet, beleértve  a VMware FT megoldást is. Meglepő az eredmény? Nézzük meg, hogy alakul ez az IIS-nél.

Folytatjuk…

Virtualizáció és magas rendelkezésre állás – 2

Amikor magas rendelkezésre állást biztosító technológiákat alkalmazunk, a tervezés során pontosan fel kell mérnünk, hogy egy-egy megoldás milyen típusú meghibásodás ellen nyújt védelmet, és mi az, amit nem visel el. Nézzünk erre példát virtualizáció nélkül. A sorokban a meghibásodások típusát, az oszlopokban a különböző szolgáltatás szintű magas rendelkezésre állást biztosító technológiákat soroltam fel. Az architektúránál feltételeztem, hogy a kiszolgálók nem SAN-ról indulnak, de az adatbázisuk, vagy az IIS által átadott tartalom már a SAN-on van. (Ha SAN Boot-ot feltételeznék, akkor a SAN kapcsolat kiesés megegyezne a szerver kiesés sorral, a SAN tároló kiesés pedig a teljes telephely kieséssel). X-el jelölöm, amikor egy adott komponens kiesése ellen védelmet nyújhat egy adott technológia, utána pedig magyarázatot fűzök a táblázathoz. Értelem szerűen a táblázat “felbontása” lehet sokkal finomabb is, pl. milyen típusú adatbázis meghibásodások, milyen típusú szerver meghibásodások stb. stb. Én itt most egy-egy komponens teljesen használhatatlanná válásával számoltam. Még egy megjegyzés: más eszközöm nem lévén, vastaggal és zöld háttérrel jelöltem az Oracle RAC-ot, mivel az hibatűrő megoldás is egyben – vagyis a meghibásodások a felhasználó szemszögéből nem észlelhető. (Kivéve a SAN hibát és a teljes telephely átállást.)

Kieső komponens	AD – két tartományvezérlővel	IIS – NLB-vel	Exchange DAG	Oracle RAC
Adatbázis	x		x	x
Alkalmazás	x	x	x	x
Operációs rendszer	x	x	x	x
Szerver hardver	x	x	x	x
SAN kapcsolat	x	x(*)	x	x
SAN tároló	x	x(*)	x	x(*)
Teljes telephely	x	x(*)	x	x(*)

Az Active Directory több telephelyen elszórható, egymással replikációs kapcsolatot tartó kiszolgálókból áll, ún. tartományvezérlőkből áll. Mindegyik tartományvezérlő saját adatbázist kezel. Ha ezek közül egyik meghibásodik, akkor az adott szerveren a szolgáltatás nem üzemel, a kliensek pedig automatikusan másik kiszolgálóhoz fordulnak.

NLB-vel védett IIS esetén az “adatbázis” lehet egy könyvtárstruktúra. Ennek eltűnése nem állítja le az IIS szolgáltatást, ezért az adott IIS kiszolgálóhoz fordulók valamilyen hibakódot ad vissza a kliensek kérésére. Minden egyéb meghibásodáskor az NLB gondoskodik arról, hogy a felhasználók megkapják a kérésüknek megfelelő adatot. NLB fürtöt pl. DNS Round robin segítségével több telephelyre is szétszórhatunk, bár ilyenkor bizonyos kliensek hibára futhatnak – ezért a (*) megjegyzés.

Az Exchange DAG és a Oracle RAC minden, általam felsorolt hiba ellen képes védekezni annyi megjegyzéssel, hogy egy Oracle RAC különböző telephelyek között csak úgy tud elhelyezkedni, ha a távolság nem haladja meg a 100 Km-t. Ez ritka kivételeket leszámítva bőven elegendő. Az Exchange-nek a távolság nem akadály, az Amsterdam-Dublin átállás simán elképzelhető.

Ha valaki a fenti okfejtést kissé bonyolultnak tarja, annak felhívom a figyelmét, hogy a magas rendelkezésre állás nem is minden aspektusát vettük figyelembe. Exchange esetén például tervezhetünk a kommunikációs csatornák magas rendelkezésre állásával is, nem csak az adattárolás magas rendelkezésre állásával.

Ez a táblázatos módszer (persze nem az itteni móricka változat, hanem egy precízen kifejtett) egyébként alkalmas egy-egy beruházás megtérülésének utólagos számításához. Ha ismerjük a rendszerünk jelenlegi rendelkezésre állását, a kiesések okát és költségét, akkor a beruházás utáni rendelkezésre állás növekedés (kiesés csökkenés) költsége megtakarításként jelentkezik. Magas rendelkezésre állást implementálni csak akkor érdemes, ha mérjük is, hogy milyen magas a magas, nem mondtam még? Virtualizációs terveknél pedig azt sem árt tudni, hogy melyik fajta kiesés mekkor súllyal esik latba. Miért is? Mert virtualizációs környezetben egész más lesz ez a táblázat.

Folytatjuk…