Lepenye Tamás webnaplója

Amióta összeállítgatom a webnapló statisztikáját, rendre hozom fél évenként az 50 000 találatot. Vagyis ez inkább fordítva van: ötvenezrenként statisztikát csinálok ;-). Most is így történt. Nagyjából 2006. júniusa óta tart ez a látogatottsági trend, néha egy hajszálnyit laposabban, most éppen egy másik hajszálnyit meredekebben. (A függőleges vonal a munkahelyváltás időpontja.)

A cikkek téma szerinti kumulatív megoszlása folytatja a korábbi tendenciákat. Az “IT 2.0” még nagyobb teret nyert, de a “Munkahely” kategória növekedése megállt. A teljes blogra vonatkozóan a cikkek majdnem 70%-a négy téma köré csoportosul (IT Üzemeltetés, Munkahely, IT 2.0 (Virtualizáció) és “IT közösség”). Ha az elmúlt fél évet tekintem, akkor a fő téma a virtualizáció volt, emellett a megelőző félévhez képest képest kicsit többet írtam az üzemeltetésről és kevesebbet a munkahelyről.

Ami sajnálok, hogy keveset írtam a kommunikáció megoldásokról és keveset a licencelésről – ez utóbbira pedig a szóbeli visszajelzések alapján szükség lenne.

Ez egy régi történet, még 2008 februárjában vetette fel Mike DiPetrillo. Az utóbbi napokban Bognár Attila megjegyzéseiben újra előbukkant a téma, és vele egyetértésben úgy gondoltam, megér egy bejegyzést.

A probléma
Az bizonyára tudjátok, hogy a modern virtualizációs megoldások nem emulálják a processzorokat, hanem csak virtualizálják. Ez azt jelenti, hogy a virtuális gépek bár virtuális CPU-t látnak, annak funkcionalitása lényegében mindenkor megegyezik a fizikai processzor funkcionalitásával. No, mármost a processzorgyártók a közöttük folyó verseny miatt újabb és újabb utasításkészlettel vértezték fel a termékeiket, amelyeket viszont nem engedtek megjelenni a konkurenciánál. Így azután egy Intel és egy AMD utasítás-készlete, regisztereinek száma és funkciója ma jelentősen eltér egymástól. Ha egy virtuális gépet átmozgatunk egyik fizikai kiszolgálóról a másikra, a mozgatásnak van egy olyan fázisa, amikor a forrás-gépen megállítjuk a virtuális processzort, az éppen futó utasításokat és regiszter-értékeket pedig a cél-gépre másoljuk, egy új virtuális processzorba. Ha azonban az új gépen nincsenek meg a forrás-gép regiszterei és utasításai, akkor a másolás nem történik meg, a gép futása pedig kárt szenvedhet. Hasonló a helyzet akkor is, azonos gyártótól származik a forrás- és a célprocesszor is, de a forrás-CPU olyan utasítás-készlettel rendelkezik, amely nem található meg a cél-CPU-n.

Megoldás a VMware-től
Hogy az esetleges virtuálisgép-összeomlásokat megakadályozza, a VMware ESX a VMotion művelet elvégzése előtt ellenőrzi a forrás- és a célprocesszort. Ha azt látja, hogy az utasítás-készletek eltérnek egymástól, akkor megakadályozza a művelet végrehajtását. Az ESX 3.5 U2 még ennél is tovább megy és bevezeti az “Enhanced VMotion Compatibility” funkciót. Ennek lényege, hogy egy fürtön belül minden processzorra maszk húzható, vagyis a virtuális gépek elől elrejthetők az új utasítás-készletek. A fürt szinten egységes utasítás-készlet lehetővé teszi, hogy a VMotion műveleteket sikeresen végre lehessen hajtani. Miután a fürt minden tagja j processzort kapott, a maszkot le lehet venni és az utasítás-készlet használatba vehető.

A Hyper-V működése
Mike DiPetrillo rosszul tudta: mind a Virtual Serverben, mind pedig a Hyper-V-ben VAN processzor kompatibilitás ellenőrzés. A mozgatás során először lementjük a virtuális gép állapotát, majd a célgépen, a mentett állapot betöltése előtt, ellenőrizzük, hogy betölthetők-e a lementett virtuális processzor utasításai. Ha nem, akkor nem történik meg az adott gépen a visszaállítás, az erőforrás csoportnak keresnie kell egy kompatibilis processzorral rendelkező node-ot. Ha nincs ilyen, akkor a mozgatás meghiúsul – de a virtuális gép stabilitása nem kerül veszélybe. Mellesleg van mód arra, hogy inkompatibilis processzorok között mozgatni lehessen gépeket. Nem kell nagy csodára gondolni: pusztán arról van szó, hogy a Quick Migration során be lehet állítani, mi legyen az erőforrás kikapcsolt állapotba tételekor a teendő a virtuális géppel (Offline action). Ha az állapotmentés (save state) helyett azt mondjuk, legyen lekapcsolás (Shut down), máris nincs állapot, amit át kellene vinni, tehát a virtuális gép átköltözhet egyik fizikai kiszolgálóról a másikra – egy újraindítással megfűszerezve.

A történet itt véget is érhetne, a a vmware-es kollégák nem nyugodtak és összehoztak egy videót arról, mennyire “nem működik” a processzor kompatibilitás ellenőrzés a Hyper-v esetén. Intel-AMD demót nem lehet bemutatni a fentiek miatt, maradt hát az azonos gyártó de eltérő utasítás-készlet szituáció. Ha valaki megnézi a videót, első az elszörnyülködés. Te jó ég! Hogy még ezt sem tudja! Hogy lehet egy ilyen termékben megbízni! Mielőtt azonban mindenki teljes letargiába esik, érdemes néhány dolgot “észrevenni”:

1. A videón egy desktop alkalmazás az állatorvosi ló. Nem egy levelező kiszolgáló, nem egy adatbázis-kezelő, nem egy ERP rendszer, nem egy fájl- és nyomtatókiszolgáló, nem egy webszerver stb. stb. Miért? Nem lenne hatásosabb, és főleg, életszagúbb, ha ismert szerver-alkalmazást mutattak volna be? Nem lehetséges, hogy azért ezt az alkalmazást használták a videó készítői, mert nem ismernek olyan szerver szoftvert, amely a fenti utasítás-készlet különbség hatására összeomlik?
2. OK, rendben. Lehet, hogy nincs ilyen szerver alkalmazás. Akkor miért nem olyan utasítás-készletet mutatnak, amely releváns? Nem lehet, hogy azért, mert az SSE 4.1-es utasításkészletet az egyetlen, amin be lehet mutatni ezt a hibát?
3. Az SSE 4.1-et tipikusan multi-média alkalmazások használják. Gyakori használata ez a szerver-virtualizáció termékeknek? Aligha.

Persze adódik a kérdés: ez esetben tulajdonképpen lényegtelen az utasítás-készlet ellenőrzés? Nem, nem az. Látni kell, hogy a VMware ESX lassan nyolc éves termék. Ez idő alatt rengeteg processzor került ki a piacra és bizonyára sokkal könnyebb lenne demózni egy 2002-2003 táján kiadott proci és egy mai közötti inkompatibilitást. A VMware-nek, már csak a termék története miatt is, létre kellett hoznia ezt a funkciót.

A Hyper-V, az ESX-hez képest, az újabb processzorokon fut (megköveteli a hardveres virtualizáció támogatást). Bár a processzorok erőteljesen fejlődnek, a fejlődés jelenleg a magokra, és olyan képességekre koncentrál, amelyet a virtualizációs gazdagépek tudnak kiaknázni, az utasítás-készlet bővülés ritkább (de amint láttuk nem szűnt meg teljesen). Ahogy haladunk előre az időben, úgy válik egyre valószínűbbé, hogy újabb utasítás-készletek lesznek elérhetők. Ha ezeket a szerver alkalmazások is kihasználják, akkor majd a Hyper-V is szembesül azokkal a problémákkal, amelyekkel az ESX már korábban találkozott. Ma még ez nincs így.

Vagyis, összefoglalva: a vmware-es kollégák által készített demó egy ténylegesen meglévő, de jelenleg még marginális probléma felnagyítása. A célja pedig, hogy a bizonytalan ügyfeleket elriassza a hyper-v-től. Úgy szokás ezt nevezni, hogy FUD.

Ki a fene az a Joe Wilcox? – gondolhatjátok most páran. Nos, ő egy újságíró, és az EWEEK-en több blogot is vezetett. Ezek egyike a Microsoft-Watch. 2006. novemberében vette át a feladatot, és azt gondolom, hogy nagyon magas szinten végezte a munkáját. Az ő írásai révén értettem meg például:

• hogyan működik a Microsoft, mint üzleti vállalkozás.
• miért fontos a keresés témaköre
• miért fontos a mobil informatika
• hogyan működik a Microsoft marketingje
• milyen hibkat követett el a Microsoft a Vista piacra dobásakor és hogyan igyekszik azt elkerülni a Windows 7 bevezetése során.
• stb. stb.

Nem mondom, hogy mindig egyet értettem vele, de a gondolatai segítettek eligazodni nem csak a Microsoft, de a teljes IT iparág világában. Joe kritikusan, de igazságosan írt a Microsoftról, precízen elemezte az üzleti eredményeit, kommentálta a reklámjait, megjegyezte a vezető jóslatait, aztán megnézte teljesülnek-e. Fantasztikus módon ismeri a cég belső szerkezetét, vezetőit, elemzéseket írt, amikor valaki távozott, amikor valakit előléptettek, vagy átcsábítottak a konkurenciától.

Hát, most kirúgták. Recesszió van. Azt hiszem túl értékes a tudása, hogy egy másik orgánumnak ne kellene, úgyhogy előb-utóbb újra írogatni fog majd. Azért mégis sajnálom: munkanélkülésig, bizonytalanság – kemény világ, velünk is megeshet.

Ha látom majd hol bukkan fel jelezni fogom.

És még valami: több mint 100 webnaplót követek – néhányat nagyon alaposan, néhányat csak felületesen. Viszont csak 5 RSS előfizetésem van a mobiltelefonomban. A Microsoft-Watch az egyik – volt.

Az úgy volt, hogy a munkám során egyre többször kellett az ügyfelek számára, munkatársak számára stb. összehasonlítgatni az ESX VMotion és a Microsoft Quick Migration funkcióit. A dolog egyre sűrűbben előfordult, rengeteg ködös gondolattal találkoztam szóban és írásban, ezért elkerülhetetlenné vált egy cikk megírása. El is kezdtem, de aztán rájöttem, hogy alapok nélkül nincs értelme, így született meg a majd fél éven át írt összehasonlító cikksorozat, melynek megírása során én magam is sokat tanultam. Végül a konkrét Quick Migration – VMotion elemzés a 10. cikkben íródott meg – s milyen furcsa  - ez a cikk egyetlen megjegyzést sem kapott. (Igaz, a HUP-on megtárgyaltuk a téma egy részét). Az érvelést senki nem cáfolta, még csak nem is kritizálta. Ez egyrészt jó, másrészt azt sejtem, hogy a Excel táblába valójában senki nem kukkantott bele.

Én viszont az egyik ügyfélnél a napokban eljátszottam vele, és úgy gondoltam, néhány képet érdemes megosztani ezen a helyen is. Az eredeti tábla adataival egy “Lehetőségelemzést (What..If Analysis)” végeztem. Ilyenkor meg lehet adni, hogy melyek legyenek a változó adatok, illetve melyek legyenek a megjelenítendő eredmény-cellák. Változónak a negyedik sor három oszlop adtam meg (A gépek száma, amelyen az elosztott alkalmazás fut C4:E4), eredmény-cellák pedig a 22. sorban a rendelkezésre állás értékei (C22:E22) Az eredeti cikkben is említettem ezt a módszert, de nem készítettem róla ábrákat. A vizsgálat, ugye, arra vonatkozik, miként csökken a rendelkezésre állás, ha egyre több – nem redundáns – kiszolgáló alkotja. Az ábrán jó látható, hogy a fizikai kiszolgálók esetén jobban csökken, a QM és a VMotion esetén kevésbé, ez utóbbi kettő szinte fedik egymást. Az ábra léptékéből kevésbé látszik, de el kell mondani, hogy a QM és a VMotion vonala nem párhuzamos, a Quick migration esetén a csökkenés nagyobb, a különbség viszont elenyésző. Mit mond az ábra:

1. VMotion és a Quick Migration technológiák hasznosak, mert növelik a szolgáltatások rendelkezésre állását.
2. A három szituáció közül a legjobban a VMotion teljesít.
3. A Quck Migration karakterisztikája nem a fizikai eszközökéhez, hanem a VMotion-höz hasonlatos .
4. Amekkora a különbség a QM és a VMotion vonal között, annyi rendelkezésre állást lehet “nyerni” a technológiai váltással. (Vagyis elenyészőt.)
5. A kiszolgálók számára növekedésével a rendelkezésre állás erősen csökken, ez a QM/VMotion csak lassítja/csökkenti, de nem szünteti meg.

A következő esetet úgy készítettem, hogy a fizikai és a VMotion adatokat változatlanul hagytam, a Quick Migration-nél viszont 2 VM-es környezettől kezdődően egy tartalék VM-et iktattam a rendszerbe, vagyis az egyik rész-szolgáltatást redundássá tettem (pl. egy webszervernek van egy párja és NLB-ben működnek együtt.) Az összehasonlítás persze “igazságtalan”, de a célom az volt, hogy megvizsgálja, hogyan hat a rendszerre, ha a hypervisor szintű fürtözést legalább egy vendég-gép magas rendelkezésre állásával ötvözöm.

Jól látható, hogy, a Quick Migration-ös eset “jól reagál” a plusz VM-re, a szolgáltatás rendelkezésre állása javul, méghozzá sokkal jobban, mintha QM helyett Live Migration-t kezdenénk használni. Tegyük rögtön hozzá, hogy abban az esetben, ha a VMotion-ös rendszernél alkalmaztuk volna ugyanezt, a vonal éppúgy megugrott volna. Az ábrából az alábbi következetés vonható le:

1. A vendég rendszerekben megvalósított magas rendelkezére állás biztosítása hatékonyabb (jobban tartja vízszintesen a vonalat, illetve magasabban fut a vonal), mint akár a Quick Migration, akár a VMotion alkalmazása.
2. Lehet a Quick Migration-ös rendszerekkel magasabb rendelkezésre állást biztosítani, mint a VMotion-ösökkel, ha az utóbbinál a tervezés során elhanyagolják a vendég VM-ekben implementálható magas rendelkezésre állási technológiákat.
3. A Quick Migration és a VMotion nem váltja ki az alkalmazás szinten biztosított magas rendelkezésre állási technológiákat.

A harmadik ábra az előző kiteljesítése. Itt úgy módosítottam az adatokat, hogy a Quick Migration esetében minden VM teljes, alkalmazás szintű rendundanciát élvez. (Ez megint “igazságtalan”, de a vizsgálatnak megint csak “hatás” vizsgálata a célja.)

Az ábrából levonható következtetések:

1. Az alkalmazás szinten megvalósított magas rendelkezésre állásnak nincs párja. (Legalábbis itt nincs :-)). Sokkal jobban tűri a rendszer összetettebbé válását, mint bármely más módszer.
2. Virtualizált környezetben sem szűnik meg az alkalmazás szintű technológiák haszna, sőt, akinek igazán számít a HA, az ezt a módszert alkalmazza.

Összességében elmondható, hogy:

1. Akinek számít a magas rendelkezésre állás, az nem mond le az alkalmazás szintű (VM szintű) eszközök használatáról. Ebben az esetben mindegy, hogy VMotion vagy Quick Migration segíti.
2. Akinek nem számít a magas rendelkezésre állás, annak lényegtelen, hogy a Quick Migration kapcsolat-kiesést okoz.

Miért fontos ezen gimnasztikázni? Azért, mert a VMotion-t ma kötelező elemnek érzik az ügyfelek(*), míg a Quick Migration-t alkalmatlannak tartják arra, amire a Microsoft javasolja. Az is igaz, hogy csupa olyan ügyfél gondolja ezt, aki maga még nem használta. Ahol implementálták, elégedettek vele.

Idáig az eredeti cikk kiegészítése. Ugyanakkor már a HUP-on is leírtam, ezért itt is elmondom, hogy az érvelés ugyan helyes, de van olyan szituáció, amikor nem állja meg a helyét. Idézek magamtól:

“A fenti okfejtésből egy dolog maradt ki: mi van akkor, ha maga a virtuális gép léte és működése a szolgáltatás? Akkor fordul elő ez a helyzet, ha a “vas” szolgáltatója és a tényleges, VM-ek hordozta szolgáltatás gazdája egymástól független, vagy azért mert eleve valamilyen hostolás/Outsource stb. helyzetről van szó, vagy pedig azért, mert olyan irdatlan nagy az IT. Nos ekkor a QM könnyűnek találtatik, nem elégséges.” (2008. dec. 6. - HUP)

Nos, pontosan ezt történt a Microsoft esetében is. A Microsoft IT rendszere az egyik legnagyobb elosztott vállalati IT a világon. Számos szempontból különleges, egyedi. Többek között abban például, hogy a saját vállalati szoftvereinket rendre béta3 körüli állapotukban bevezetjük, majd a bevezetés tapasztalatai alapján szükség szerint módosítunk a szoftveren. “Edd meg, amit főztél!”, angolul dogfooding. Így történt ez a Hyper-V-vel is. A Quick Migration gyenge pontja, ahogy azt decemberben leírtam, rendesen meg is jelent.

A cikk címébe is beleírtam, hogy a témát utoljára feszegetem. A Windows Server 2008 R2 megjelenésével a VMotion megszűnik “megkülönböztető képesség” lenni, megfutjuk a kötelező kört. Lesz persze a vSphere-ben “teljes hibatűrés” – de az más lapra tartozik.

Már “csak” azt kell a fejekben tisztában tenni, hogy mikor használjuk a hypervisor szintű és mikor vendég-OS szintű HA technológiát. Függetlenül a hypervisor gyártójától.

--------------------------------

(*)  A virtualization.info-tól idézve (kiemelés tőlem): “Microsoft will join the party in early 2010, when it will finally have that live migration (available for free as well) that customers perceive as a mandatory feature of every hypervisor.”