Quik Migration vs. VMotion – utoljára

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.

imageÉ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.

image
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.)

image
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.”

13 Responses to Quik Migration vs. VMotion – utoljára

  1. Gábor says:

    Kerdes: a VMotion pontosan ugyanugy reagal a VM-ek clusterezesere, mint a QM? Vagy ott mar kikukucskalnak azok a kis elteresek?

  2. Balazs says:

    A címből már sejtettem, hogy sűrű ködösítésre kell számítani, de ez kiverte a biztit nálam :)Képtelen vagyok megérteni, hogy a VMOTION funkciót miért veszitek "magas rendelkezés" szolgáltatásnak? Ezt már számtalanszor tisztáztuk, hogy a VMOTION elsődleges funkciója, hogy lehetővé teszi a 0 perc leállással történő üzemeltetést. Ennek SEMMI köze nincs a magas rendelkezésreálláshoz, pláne nem az automatizált HA-hoz. Összességében elmondható, hogy:A következtetések alapvetően hibásak emiatt:" 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."Ahogy írtam a VMOTION-nek semmi köze a magas rendelkezésreálláshoz!! Ez nem HA cluster!" 2. Akinek nem számít a magas rendelkezésre állás, annak lényegtelen, hogy a Quick Migration kapcsolat-kiesést okoz."Ez borzasztó komolytalan. Azt próbálja sugalmazni, hogya VMOTION is felesleges. Egy épeszű üzemeltető rögtön felfogja, hogy ha 3 vason patch-elni kell vagy hw-t kell cserélni, akkor le kell állítani a gépet. Nos, ha hyperv-t használ, akkor az ÖSSZES VM esetében kieséssel kell számolni, azaz mehet ki a change request minden VM tulajnak a jóváhagyáshoz és extrém esetben ovábbra is éjszakai vagy hétvégi munka lesz ebből (ami rögtön extra költséget jelent az ügyfélnek). Ha ugyanezt ESX-en csináljuk, akkor pedig élvezhetjük a 0 perces leállás melletti üzemeltetést… Nincs kiesés, nincs hétévgi meló, nincs extra költség.Arról pedig már felesleges is szót ejteni, hogy mi is kell a hyperv alá, hogy a QM működjön (VM-enkénti dedikált LUN, mscs, stb).Tehát még1x.. A magas rendelkezésreállást ne keverjük vmotion-nal vagy qm-mel.

  3. Balázs says:

    Szerintem épp ezt írta le Tamás anno a HUP-on, és most itt is:“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.”Egy dolgot tennék még hozzá, amivel szerintem jópáran egyszerűen nem foglalkoznak. Ha jól emlékszem (mintha a virtualizációs IT (vagy Technet, már nem emlékszem) előadáson anno ezt említették volna, ha nincs igazam majd megcáfoltok), az MS nem azért "találta ki" a Hyper-V-t, hogy elvegye a VMware kenyerét a fenn említett szituációkban, a cél itt nem a hatalmas virtualizált szerverpark üzemeltetése; hanem a kis és középvállati szegmenst célozta meg a Hyper-V-vel, nekik akart olcsó (ingyenes) lehetőséget adni a meglevő pár szervergép jobb kihasználására. Erre szerintem meg is felel, persze aláírom, a Live Migration kényelmesebb lesz. Reméljük nem kell sokat várni az R2-re.

  4. Attila says:

    Szia (Nagy) Balázs!"az MS nem azért "találta ki" a Hyper-V-t, hogy elvegye a VMware kenyerét a fenn említett szituációkban, a cél itt nem a hatalmas virtualizált szerverpark üzemeltetése; hanem a kis és középvállati szegmenst célozta meg a Hyper-V-vel, nekik akart olcsó (ingyenes) lehetőséget adni a meglevő pár szervergép jobb kihasználására."Komolyan elhiszed, hogy a Microsoft csak a kicsire hajt, és fel sem merült a fejében az, hogy a virtualizáció micsoda biznisz, illetve micsoda bizniszt vehet el tőle, ha nem ő diktálja a tempót? Ekkora erővel arra is várhatnánk, hogy ingyen kapjunk Windows-t otthonra.Üdv,Attila

  5. Balázs says:

    Nézd, én nem azt mondom, hogy nem szeretne piacvezető lenni. Minden cég célja az, hogy ő legyen a vezető a saját piacain. Jelenleg nem azok, lehet nem is lesznek egy darabig (vagy soha). Majd meglátjuk. De szerintem a Hyper-V jelenleg nem ezt a célt szolgálja. Sokkal inkább hogy megmutassa, hogy a Microsoft is jelen van a piacon, és tud használható alternatívát nyújtani, mégha el is van maradva a piacvezetőtől jópár dologban. Egy biztos. Jelentősen kibővült azok köre, akik hasznáhatják (és kihasználhatják) a virtualizáció előnyeit, és ez nem kis részben a Hyper-V-nek köszönhető. A verseny, és így a folyamatos fejlődés pedig összességében csak jó nekünk.

  6. Tamas says:

    Ahh, végre, már vártam.Köszönöm a megjegyzéseket.- hardver karbantartás idő: Igen igazad van, és ráadásul ezt nem egszerű javítani a táblázatban. Majd kitalálok valamit.- 2×16 másodperc – állítható paraméter. Azt azért lássátok, hogy a QM a save-state műveletkor tömörít is, ezért pl. 4 GB memória lemezre mentése nem biztos, hogy 4 GB-nyi adat mentését jelenti.- Havi quick migration: igaz amit írsz, de ezt bele lehet paraméterezni a táblázatba, pl. dupla időkkel.- 19 gép: igaz, de ez szépséghiba, a mondanivalón nem változtat. Jól gondolom, ugye?- Determinisztikus idők: igaz, egyszerűsítés. De vajon milyen adatok alapján tudnék nem determinisztikus időkkel számolni? Össze kellene gyűjteni mintákat (sokat) és abból kellene minimum átlagokat számolni. Ilyesmivel nem rendelkezem, arról nem is beszélve, hogy a megbízhatóság-elméletből származó képleteket sem ismerem. Azért az általad emlegetett technikai eszközök érdekelnek.Jó lenne, ha érzékeltetnéd mennyire komoly az a leegyszerűsítés, mert ez az egész modellt negligálhatja. Ebben viszont kételkedem.DRS/DPM – bingó, és köszönöm, hogy nem DRS példát hoztál (az a kevésbé fontos), hanem DPM-et. Ez igaz. Már csak meg kell várni a május végét, amikor megjelenik az első támogatott DPM megoldás. (vsphere)Nota bene: a hyper-v jelenlegi kiadásában nincs DPM, tehát ilyetén jellegű QM sem.

  7. Tamas says:

    RDM – Elhiszem, sőt köszönöm a visszajelzést. Átnézem a korábbi cikkeket és lassan frissítem őket ezek alapján ,mert nem lenne jó, ha téves információk maradnának benne.Fizikai rendszer karbantartása: BIOS frissítés, firmware frissítés, eszközcsere, bővítés, rack átrendezés, vas lecserélése stb.A PRO-DRS-t már összehasonlítottam korábban.A DPM-et azért tartom relevánsabb QM kihívásnak, mert jóval több gépmozgatást igényel. Ahol implementálják, ott a gépek nagyságrenddel többet mozognak, és ott úgy fogy el a QM, mint a bot. A DPM rendszeres mozgást jelent (pl. minden este, minden reggel) és több gép számára, míg a DRS ad-hoc mozgást (erőforrás-szűke esetén) néhány gép számára. Ha egy folyamatos erőforrás-szűke jelentkezik, akkor azt orvosolhatom azonnal, vagy másnap, vagy harmadnap. Ez még minidg összehasonlíthatatlanul gyorsabb, mint a fizikai világban új vasat venni. Az energia-ellátás viszont tipikusan napi ingadozást mutat: olyat nem mondhatok, hogy "majd a change request jóváhagyási folyamat után mozgatjuk a gépet" :-)Még egyszer: QM-VMotion összehasonlítást végeztünk.

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: