vCenter 6.0U1 friss telepítés után hiányzik a Licensing rész a Web kliensben (megoldva)

Nem olyan régen kérdeztem a VMUG levelező listán, hogy a fenti jelenséggel kapcsolatban nincs-e valakinek ötlete. Senki nem reagált rá, ami így utólag már teljesen érthető.
Röviden összefoglalom a körülményeket. Egy teljesen új vCenter 6.0U1 környezetet építettünk, amiben egy külön gépre került a Platform Service Controller, mivel várhatóan más vCenter szerverek is lesznek a jövőben, és ilyen esetben a külső PSC a javasolt. Mi továbbra is a Windows változatot használjuk.
Hiba nélküli telepítés után az volt a jelenség, a Web kliensből teljesen hiányzott a Licensing rész, és pl. amikor egy hostot akartam berakni a vCenter alá, a License résznél hibát is dobott a kliens.
Mivel már minden szóbajöhető dolgot kipróbáltunk, nem maradt más hátra, mint esetként bejenelteni a VMware-nek.

Mint kiderült, általános problémáról van szó, amiről egy külön KB cikket is írtak: KB2135810

Az a fura, hogy majdnem két hónap telt el az U1 megjelenése óta, és most, a hibabejelentésem után született a KB cikk. Azaz eddig más ezt a hibát nem igen jelentette.

VCP6-DCV Delta

A VMware adott egy 65%-os kedvezményt amennyiben október 31-ig nekifutok a VCP6-DCV (vagy VCP6-DCV Delta) vizsgának, így október 30-ra be is foglaltam egy időpontot a Training360 oktató központjában. Ha már választhattam, akkor a Delta vizsgát tettem le. Kevesebb kérdést tartalmaz, és szertettem volna tényleg csak az újdonságokra és változásokra koncentrálni.

Nem véletlen választottam a lehető legkésőbbi időpontot. Szerettem volna, ha addigra átállunk a teljes éles környezettel vSphere 6-ra, így szerezhettem volna elég tapasztalatot közben. Ez sajnos nem történt meg, így egy kis tesztkörnyezetet építettem, és azon próbáltam ki az új vagy megváltozott 6-os képességeket.
A következő forrásokat használtam:

http://www.vladan.fr/vcp6-dcv/
http://www.virten.net/vmware/vcp6-dcv-delta-study-guide-whats-new-v5-5-to-v6-2v0-621d/
http://go.veeam.com/vmware-certification-vcp6-dcv-study-guide-exam-blueprint.html
Próba vizsga

Mivel szeretem a papír alapú könyveket is, ezért még beszereztem a Mastering VMware vSphere 6 könyvet is.

A vizsgáról néhány szó. A szokásos módon minden gördülékeny volt. Megérkeztem a Training360-hoz, és kb. 10 perc múlva már ott ültem a gép előtt. Ami meglepő volt, hogy a delta vizsga ellenére sok olyan kérdés volt, ami nem köthető a 6-os verzióhoz. Nem tudom milyen a nem delta vizsga, de nekem úgy tűnt, mintha ez a vizsga a teljes vizsgának lenne egy kevesebb kérdésből álló változata, amiben szép számmal voltak olyan kérdések is, amik nem köthetők a hatos verzióhoz.

A vizsga sikerült, így most 2017.10.30-ig érvényes VCP6-DCV vizsgám van, illetve ez automatikusan meghosszabbította a VCP5-DCV vizsga lejárati idejét is.

Ha majd elérhető lesz a VCAP6 (azt hiszem más lesz a neve), akkor persze szeretném azt is letenni, bár a meglévő VCAP5-DCV vizsgám (egyelőre) nem jár le. Ehhez persze az is kell, hogy valahogy hozzájussak egy jelentősebb kedvezményhez, mivel ezeket a vizsgákat mgamnak finaszírozom, és az advanced viszga ára emlékeim szerint 3-400 dollár.

Elérhető VMworld 2013 előadások

Nem emlékszem, hogy az előző években hogy volt, de a mostani rendezvény után közvetlenül elérhetővé tettek néhány előadást.

A kedvencem, bár bevallom még nem néztem végig, a PowerCLI-t bemutató, a megszokottól mélyebb szakmai előadás, természetesen Luc Dekens és Alan Renouf előadásában.

Session VSVC4944- PowerCLI Best Practices: A Deep Dive


A következő a VMware új Log Insight alkalmazásáról szól. Splunk szerű felület, főleg VMware termékekre kihegyezve.

Session VCM7369-S- Uncovering the Hidden Truth in Log Data


Következő kurrens téma a Network virtualization, a VMware NSX.


Session NET5847- NSX: Introducing the World to VMware NSX


Vannak még más témák is, de azoknak a felfedezését rátok bízom. Viszont a két general sesssion-t még beszúrom ide.

Augusztus 26.


Augusztus 27.


Ha keresgéltek, még 3-4 további előadásra is rá lehet lelni.

És a végére egy kérés: Ha még esetleg nem lenne Dropbox accountotok, és szeretnétek, akkor legyetek szívesek ezen a linken keresztül regisztrálni, így segítenétek abban, hogy egy picit növeljem a rendelkezésre álló tárhelyemet: http://db.tt/xKQZXXIt

vSphere 5.5

Mostanság ért véget az amerikai VMworld-ön az első Keynote, amit nagyrészt Pat Gelsinger tartott (CEO). Élóben közvetítették, így meg lehetett nézni/hallgatni.

Úgy tűnik, most már biztosan a Software-Defined Datacenter lesz az az új fogalom, amit nagyon gyakran fogunk hallani. Már egy éve is volt róla szó, de most már sokkal jobban körvonalazódik, mit is jelent ez majd a közeljövőben.

De ami sokunk számára leginkább érdekes lehet, hogy bejelentette a vCloud Suit 5.5-öt, amiben természetesen új Hypervisor is lesz, mégpedig a vSphere 5.5.

Szerintem nem véletlen, hogy csak 5.5 és nem 6.0. Legalábbis abból, ami ott elhangzott, túl nagy újdonságok nem derültek ki. Az biztos, hogy az eddigekhez képest kétszer annyi CPU és memória lehet egy hostban (256 és 4TB). Ez igen soknak tűnik, de a jövőben megjelenő új processzorokkal szerelt szerverekben már simán lehet annyi CPU szál, amit a vSphere 5.1 nem tudna kihasználni. Másrészt pedig lehetővé akarják tenni, hogy "minden" alkalmazás futhasson virtuális gépeken függetlenül attól, hogy mekkora erőforrás igénye is van. Itt is elhagzot egy jelmondat: Apps Love vSphere.

Virtuális gép szinten pedig az eddigi 2TB VMDK méretet növelték meg 64TB-ra.

Bekerül egy új, alkalmazás szintű HA funkció is, de sokat méf arról sem lehet tudni. Az FT sajnos továbbra is csak egy vCPU-t támogat, talán majd a 6.0-ban.

További új funkció a vSphere Flash Read Cache, ami a hostokban lokálisan jelenlévő SSD-k használatát bővíti ki.

Kb. ennyit tudtam kihámozni.

A fentieekn túl volt szó a Software-Defined Storage fogalomról, a virtual SAN-ról, a hálózat virtualizálásról, a Hybrid Service-ről, az új management termékekről (pl. Log Insight)

 

Két érdekes blog bejegyzés a leendő újdonságokról:

 

Introduction to VMware vSphere Virtual SAN

Introduction to vSphere Flash Read Cache aka vFlash

 

 Illetve itt is sok minden megtalálható: Vladan Seget blogja

CPU Ready Time (%RDY)

Ha egy virtuális gépnek CPU-hoz köthető teljesítmény problémái vannak, akkor minden ezzel foglalkozó cikk, leírás első helyen említi a CPU Ready Time értékének ellenőrzését. De mit is jelent ez?

A virtualizáció egyik sajátsága, hogy az egy hoston futó virtuális CPU-knak (vCPU) a hypervisor-ban futó scheduler osztja ki a fizikia CPU-kat (pCPU). Ha több vCPU van, mint pCPU, akkor előfordulhat, hogy az egyik virtuális gépben futó vCPU-nak lenne dolga, de mégis várakoznia kell, mivel az őket kiszolgáló pCPU-kat a scheduler éppen másik virtuális gépnek osztotta ki. A várakozással töltött időt nevezzük CPU Ready Time-nak a VMware terminológiában.

Az teljesen természetes, hogy ez az érték nagyobb mint nulla. Az is igaz, hogy kicsi értékek esetén sincs semmilyen észlelhető hatása a teljesítményre. Már csak az a kérdés, hogy mekkora érték esetén kell elkezdenünk aggódni, és keresni a megoldást a nagy érték csökkentésére. Mint általában lenni szokott, itt sem határozható meg konkrét érték. Természetesen szamárvezető van, ami azt mondja, hogy 5%/vCPU fölött már oda kell figyelni, 10%/vCPU fölött pedig már kifejezetten rossz a helyzet.

Ha meg szeretnénk határozni egy konkrét virtuális gép esetében ezt az értéket, akkor ez nem is olyan egyszerű dolog. Nézzük meg, hogy mit látunk, ha a vSphere kliensben a performancia fülön megjelenítjük egy konkrét virtuális gép CPU Ready Time értékét.

Itt bizony ezres nagyságrendű értékeket látunk. Hogy lehet ebből %-ban kifejezni, hogy mennyi a CPU Ready Time egy vCPU esetében? Pirossal bekarikáztam a fontosabb információkat. Ezek szerint a fenti diagram 20 másodpercenként frissül, összegzett értékeket tartalmaz a 20 másodperce vonatkoztatva, és ezredmásodpercben jeleníti meg. Ezek szerint a legutóbbi 20 másodpercből 3806 ezredmásodperc volt a Ready Time értéke. Ha ezt %-ban kifejezzük, akkor  

3806/(20*1000))*100=19.3 értéket kapunk. A 19.3% jóval több, mint az 5%, de még a 10%-ot is jóval meghaladja. Akkor ez a gép most rossz állapotban van? Ehhez tudnunk kell azt is, hogy ebben a virtuális gépben mennyi vCPU van, ugyanis ez a 3806 ezredmásodperc az összes vCPU Ready Time értékének összegét tartalmazza. Lehetőség van arra is, hogy a fenti értéket processzoronként is megnézzük. Látható a lenti ábrán, hogy ebben a gépben 8 virtuális CPU van.

 

 

Végezzük el a számítást egy vCPU-ra is, mondjuk arra, amelyiken ez az érték a legnagyobb.  608/(20*1000))*100=3.04, azaz megközelítőleg 3%. Ez már így sokkal jobban mutat.

A VMware adminoknak van más lehetősége is. A vMA-n keresztül futtathatjuk az resxtop utility-t, amivel mindenféle értéket ki tudunk nyerni a hostból. A lenti képen ugyanezt a virtuális gépet (is) láthatjuk.

 

Itt már egy kicsit gyorsabban juthatunk információhoz, hiszen egyből %-ban látjuk az értékeket. Viszont itt is jó nagy a Ready Time értéke, mivel alapból a nyolc processzor összegét mutatja. Viszont ha megnézzük a virtuális gép részleteit, akkor már itt is barátságosabb számokat látunk.

Adódik a kérdés, hogy mit tehetünk akkor, ha ez az érték tartósan nagy, és ez már érezhető lassulást is okoz. Ezt nem feltétlenül egyszerű megválaszolni, de van néhány lehetőség. Pl.

• Ha kevesebb vCPU is elég, akkor csökkentsük a vCPU-k számát egy adott virtuális gépben
• Ha van rá lehetőség, akkor csökkentsük a vCPU/pCPU arányt (mondjuk virtuális gépek áthelyezésével)
• Nem teszteltem, de azt olvastam, hogy inkább két darab sok vCPU-t tartalmazó gépet futtassunk egy hoston, mint egy darab sok vCPU-s gépet több darab 1-2 vCPU-s géppel
• Növeljük a fizikai processzorok számát:)

 

 

Túlzott erőforrás igények negatív hatásai

Virtuális gépek igénylésekor mindenki igyekszik sok erőforrást kérni a saját szervere számára. Legtöbb esetben többet, mint amire szükség lenne. A fizikai világban nincs semmi negatív hatása annak, ha egy szerverben pl. 4 processzor van, de a rajta futó rendszer megelégedne akár egy processzor is (Maximum a szerver fogyasztása megnő). Sőt itt valóban érdemes már az elején telerakni a gépet processzorral vagy memóriával, mert ki tudja mi lesz akkor, ha bővíteni kellene, de nem lesz rá pénz a későbbiekben.

Sajnos ez a hozzáállás nem változott meg a virtualizáció bevezetése után sem. Nyílván az alkalmazások erőforrás igényeinél is igyekeznek olyan értékeket megadni, amik túl vannak a valós igényeken. Nem egyszer fordult már elő, hogy pl. túlzott lemez igény esetében alkudoztam, végül lényegesen kevesebben egyeztünk meg, és a gép a mai napig üzemel.

Milyen negatív hatása van, ha több erőforrást kérünk a gépünk számára, mint ami szükséges? Fontos dolog, hogy akkor beszélhetünk csak negatív hatásról, ha valamelyik erőforrást túlfoglaltuk. Azaz több memória van kiosztva, mint ami fizikailag a hostban van, vagy több virtuális CPU van az egy hoston futó virtuális gépekben, mint amennyi fizikai mag van bennük.

Túl sok vCPU

Egy operációs rendszer általában feltételezi, hogy az általa kezelt processzorok megközelítőleg azonos órajelen működnek. Ez a fizikai világban nyilvánvaló. Virtualizáció esetén viszont a hypervisor-nak kell biztosítania, hogy az operációs rendszer „azt higgye” hogy minden általa kezelt processzor azonos órajelen működik. Abban az esetben, ha az összes virtuális CPU száma <= mint a fizikai magok száma, akkor ez nem tűnik nehéz feladatnak, hiszen akkor minden vCPU megkap egy fizikai magot, nem kell osztoznia más gépekkel. De a virtualizáció egyik lényege pont az, hogy a meglévő erőforrásokat minél jobban kihasználjuk, ezért egy fizikai CPU-t 2,3,4 vagy még több vCPU-t kiszolgál. Ebben az esetben a hypervisor CPU scheduler-ének a feladata, hogy egy bizonyos algoritmus alapján kiszolgálja az összes virtuális gépet. Nem nehéz belátni, hogy ha több vCPU van, mint pCPU, akkor előfordulhat az, hogy egy több vCPU-t tartalmazó virtuális gép egyik processzora tudna dolgozni, de egy másik vCPU éppen akkor nem kap a scheduler-től processzor erőforrást, így az előző is várakozni kényszerül. Minél több vCPU van egy virtuális gépben, ez annál valószínűbb. Ebből pedig következik, hogy feleslegesen kért több processzor negatívan befolyásolja (befolyásolhatja)a hoston futó összes virtuális gép teljesítményét. Ez nyílván egy bizonyos mértékig nem észlelhető, de eljuthat egy olyan mértékig, amikor már a gép működésén is észre lehet venni.

A másik negatív hatás, hogy a virtuális gép memória overhead-je megnő (több vCPU, több memória igény), ezáltal feleslegesen vesz el memóriát más gépek elől. Ráadásul ez a memória hozzá lesz rendelve a géphez, nem vesz részt a különböző memória optimalizáló eljárásokban.

Sok ilyan igénnyel találkozok, ahol több processzort kérnek a gépbe. Pedig a helyes módszer az lenne (leszámítva persze néhány kivételt), ha egy processzorral indulna a gép, és ha ez a későbbiekben kevésnek bizonyul, lehet növelni a számát. Az újabb operációs rendszerek esetén nem probléma persze a több processzorról átállni egy processzorra, de a régebbiek esetében ezzel lehetnek problémák, így inkább mindig a kevéstől a több felé kellene haladni.

 Túl sok RAM

Itt is igaz amit az előző pont végén írtam, azaz minél több memóriát adunk egy virtuális gépnek, annál nagyobb lesz a memória overhead. (Az a memória mennyiség, amit a virtuális gép futtatásához használ a hypervisor)

Ezen kívül megnő a virtuális gép diszk igénye is. Ráadásul ez két helyen is jelentkezik.

• az operációs rendszer lapozó file mérete függ a memória mérettől (ez persze szabadon állítható, de pl. egy Windows 2008 R2, ha mást nem mondunk akkor a RAM méretének kb. 150%-át is képes lefoglalni).  Azaz egy 20GB RAM esetén biztosítanunk kell, hogy alapesetben 30GB-os lapozó file-nak legyen hely.
• a másik pedig az a diszk terület, amit a fizikai host használ abban az esetben ha már semmilyen módszerrel nem tudja kielégíteni a virtuális gépek memória igényét a fizikai memóriájából, ezért kénytelen a virtuális gépnek egy swap területből „memóriát” biztosítani, hasonlóan mint ahogy az általános operációs rendszerek használják a lapozó file-t. Azért, hogy a host ezt minden esetben meg tudja tenni, minden virtuális gép esetében biztosít egy a virtuális gép RAM méretével megegyező diszk területet. Ez talán nem tűnik soknak elsőre, de ha pl. van 15 db 4GB-os gépünk, akkor ez már 60GB. Ha nem bővelkedünk storage területben, akkor igen is számítani tud 10-20GB is.

Túl nagy diszkek

Talán ez a legnyilvánvalóbb. Ha több diszket kérünk egy virtuális géphez, akkor kevesebb marad a többinek. Illetve az olcsónak nem nevezhető SAN-os diszkekből többet kell használni, mint ami valójában szükséges lenne.

Szerencsére a VMware nyújt erre is megoldást. Ez pedig a Thin provisioned diszkek használata. Ez a következőképen működik. Valaki kér a virtuális géphez egy 100GB-os diszket, és persze kap is. Az operációs rendszer számára látszik a 100GB. Viszont a tényleges foglalása a storage-on annyi, amennyit valóban elfoglalnak az állományok, mappák a lemezen. Ha ez 10GB, akkor a tényleges foglalás 10GB. Természetesen ennek vannak előnyei és hátrányai is.

• nem bánunk pazarlóan a tárterülettel
• ki tudunk osztani a ténylegesnél több diszket is (pl. egy 500GB-os storage területen akár 1TB szumma diszk igényű virtuális gépet ), viszont
• monitorozni kell a tényleges helyfoglalást, mert ha az összes hely elfogy, leállnak az azon a területen futó virtuális gépek (storage DRS jól jön ilyen esetben, feltéve ha a legdrágább licensszel rendelkezünk)
• ha a fentebb említett 100GB-os diszkre a rendszergazda felmásol egy 90GB-os mappát, majd törli azt, akkor ez a törölt terület a storage számára már foglalt marad. (A következő ESX verziók már biztosan fognak erre is megoldást biztosítani a VMware tools-on keresztül)
• amikor először írunk egy eddig nem használt diszk területre, az lassabban fog megtörténni, mint egy nem Thin provisioned diszk esetében
• nem mindig használhatunk ilyen diszket (Fault Tolerance és MSCS cluster megköveteli a Thick diszk használatát

Összefoglalva, igyekezzünk mindig csak annyi erőforrást kérni, amennyire szükségünk van. Ha alulméreteztünk valamit, biztosan kérni fogjuk a bővítést, de ha valamiből sok van, szinte biztos hogy nehéz meggyőzni a szerver gazdáit, hogy kevesebbel is hasonló teljesítményre lenne képes a gépe.

CloudCred

A VMware kb. két hónappal ezelőtt elindított egy "játékot", aminek az a célja, hogy a részt vevők játszva szerezzenek információkat a Cloud technológiáról, miközben kisebb-nagyobb ajándékokhoz is hozzá lehet jutni.
A fődíj nagyon vonzó, hiszen egy komplett két személyes út Barcelonába a VMworld-re, szálással, repülőjeggyel, és némi költőpénzzel. Sajnos ebben az esetben nem a szerencse dönti el a nyertes személyét, hanem a legtöbb pontot elért játékos kapja. Az meg teljesen lehetetlen küldetés. Bevallom én belekezdtem, mint sok minden másba is. Sajnos elég időigényes, és nagy a csábítás, hogy ne csináljak meg mindent teljesen becsületesen. Főleg ha az adott téma nem is nagyon érdekel.
Ha valaki kedvet kapna hozzá, itt nézzen szét: www.cloudcredibility.com