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!

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.

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…

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

Nem is tudom. milyen régóta szerettem volna megírni ezt a cikksorozatot. Annyi tévhit és leegyszerűsítés él a témáról a köztudatban, hogy az el sem mondható, miközben ténylegesen szinte senki nem vizsgálta ezt a területet. Általánosak az olyan megfogalmazások, hogy “a virtualizáció és a magas rendelkezésre állás kéz a kézben jár”, meg hogy “hypervisor fürtöket alkotva automatikusan magasabb rendelkezésre állású rendszert lehet kialakítani”, vagy például “a virtualizáció nyújtotta magas rendelkezésre állást biztosító technológiák kiváltják az alkalmazás szintű clusterezést” stb. stb. A következő tanulmányban négy konkrét alkalmazás példáján szeretném megmutatni mi igaz és mi nem ezekből az állításokból. A négy alkalmazás az Active Directory, az IIS, az Exchange DAG és az Oracle RAC – jó okom van épp ezt a négyet választani, később kiderül miért.

Alapozás
Mindenek előtt néhány definíció. Magas rendelkezésre állást biztosító technológiáról  (highly available, HA) akkor beszélünk, amikor van egy módszer, eszköz, technikai lehetőség, amely segítségével egy adott, vagy akár többféle meghibásodás esetén a rendszer a szolgáltatás kiesését minimalizálja. Ha ez a minimalizálás olyan jól sikerül, hogy semmiféle kiesés nem történik, legalábbis felhasználói szemszögből ez nem érzékelhető, akkor az adott módszert hibatűrő (fault tolerant, FT) megoldásnak hívjuk. Előbbire példa mondjuk egy Microsoft fail-over cluster: ha meghibásodik egy fürttag, akkor a szolgáltatások kis kiesés mellett átvándorolnak egy másik fürttagra. Az utóbbira – tehát a hibatűrésre – jó példa mondjuk egy RAID tömb: még ha meghibásodik is egy merevlemez, semmi gond, a RAID tömb működése biztosítja a szolgáltatást. Tipikusan NEM szokták a hibatűrő megoldások közé sorolni mondjuk azt, amikor IP-cím konfiguráció során kettő vagy több DNS kiszolgáló címét adjuk meg, pedig ez is szép példája a szolgáltatás tovább élésének: a TCP/IP hálózati forgalom-kezelés biztosítja, hogy egy kiszolgáló elérhetetlensége esetén a számítógép automatikusan egy másikhoz fordul.

A cikkben szolgáltatás szintű (alkalmazás szintű) magas rendelkezésre állást biztosító technológiának fogok nevezni minden olyan megoldást, amely egy szolgáltatás (pl. AD, Exchange SQL stb.) magasabb rendelkezésre állását biztosíthatja. Ezek a technológiai megoldások nagyon sokfélék lehetnek, konkrétan a mi kiválasztott alkalmazásainknál:

• Többszörözés – pl. Active Directory. Ha több tartományvezérlőt állítok üzembe, akkor magasabb lesz az AD szolgáltatásom rendelkezésre állása.
• Network Load Balance (NLB) – hálózati forgalomelosztó mechanizmus; Többek között az IIS szolgáltatás magasabb rendelkezésre állását segítő megoldás. Terheléselosztó szerepe is van, de ez a mi szempontunkból most mellékes.
• Fail-over cluster – az operációs rendszerbe beépített mechanizmus, amelyet sok más szoftver mellett az Exchange 2010 Data Availability Group rendszere is használja, hogy ezáltal biztosítson adatbázis szintű magas rendelkezésre állást.
• Egyedi, alkalmazás szintű megoldás – Erre jó példa az Oracle Real Application Cluster (RAC).

  Még egyszer: sokféle technika, azonos cél: az adott szolgáltatás folyamatosan működjön.

A szolgáltatás elérhetetlenségének, leállásának többféle oka is lehet. Tervezetett leállásnak fogom nevezni azokat a leállásokat, melyek ideje előre meghatározott, és tevékenység pedig szándékolt. Leginkább a karbantartás, tervezett leállás, tervezett bővítés, csere stb. tartozik ide. A nem tervezett leállás fogalmát akkor veszem majd elő, amikor valamilyen váratlan meghibásodásról beszélünk.

Gazdagép fürtözésnek (host cluster) nevezik azt a módszert, amikor a virtualizációs kiszolgálók alkotnak egy fürtöt, szervercsoportot, és meghibásodás esetén átveszik és futtatják a meghibásodott hardver virtuális gépeit.



Gazdagép fürtözés

Vendéggép fürtözésnek (guest clustering) hívjuk azt a megoldást, amikor két virtuális gép között alakítunk ki fail-over clustert. Ilyenkor nem a gépek, hanem – akárcsak a fizikai környezetben – a szolgáltatások vándorolnak egyik kiszolgálóról a másikra.

Vendéggép fürtözés

Figyelem! Ebben a cikkben vendéggép fürtözésnek fogok hívni minden szolgáltatás szintű magas rendelkezésre állást biztosító technológiát, függetlenül attól, hogy az technológiai értelemben ténylegesen fürtözés-e.

Előfeltevések
A közbeszédben sohasem mondjuk ki, de itt most le kell írnom, hogy az alábbi gondolatsor a következő előfeltevésen alapul: bárhogy is alakítsuk át a rendszerünk architektúráját, egyforma ügyességgel vagyunk képesek üzemeltetni azt. A valóságban ez közel sincs így, mégis szükséges a lenti okfejtéshez hozzáfűzni. Miért? Azért mert a most következő gondolatsor feltételezi, a “ceteris paribus”-t, vagyis minden egyéb feltétel változatlan voltát.

Ezen túl feltételezem, hogy a technológiában rejlő potenciál teljes egészében felhasználható. Például egy VMware cluster tipikusan egy telephelyen működik. Site Recovery Managerrel azonban a megoldás védkezni képes a teljes telephely megsemmisülése ellen is. Én azt feltételezem, hogy pénz, paripa, fegyer rendelkezésre áll bámilyen potenciálisan meglévő lehetőség tényleges megvalósítására.

Kérdések
Most, hogy a legfontosabb fogalmakat tisztáztuk, tegyük fel a kérdéseket, amelyekre a tanulmányban választ keresünk:

1. 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?
2. 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 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?
3. 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?

Mára elég, innen folytassuk legközelebb…