2016. december 28., szerda

vSphere client (vSphere HTML5 Web client) "újdonság"

Amikor márciusban megjelent mint "fling", akkor gondolom minden VMware admin felkapta a fejét, és már azt tervezte, hogy mikor állhat át az új kliens használatára. Még én is írtam róla röviden. Azóta persze látszik, hogy a teljes értékű, mindent tudó kliens még egy jó ideig nem fog elkészülni. Ahogy a fejlesztők megnyilvánulásait látom, ez majd leginkább 2017 őszén várható. Addig marad a hagyományos kliens és a régi Web kliens. A 6.5-ben állítólag sokat fejlődött a Flash alapú kliens is, de annak megtapasztalása a következő év tervei közt szerepel.

Akkor miért is volt érdemes újra előszedni ezt a témát?

Egyrészt ez már hivatalosan, támogatott módon része lett a 6.5-ös rendszernek. Igaz, hogy azóta az nem frissült, sőt tudtommal még azt sem lehet tudni, hogy pontosan mi lesz a menete kizárólag csak a kliens frissítésének. Mivel heti frissítések jönnek ki, ezért az abban lévő tudás, és a letölthető, appliance alapú kliens tudása között egyre nagyobb különbség van. Van egy oldal, ahol elvileg friss információkhoz lehet jutni arról, hogy az új kliensben milyen funkciók nincsenek még implementálva. A dolog szépséghibája, hogy ez azt mutatja, hogy a 6.5-ben integrált módon meglévő kliens mit nem tud még, és nem azt, ahol a fling fejlesztés tart. Ez a táblázat itt található. Aki követi a fejlesztést, az tudhatja, hogy a táblázatban találhat dolgok egy része már elérhető. De még igen sok dolog miatt maradnak a régi kliensek.

Van még egy dolog az új klienssel kapcsolatban. Többször eszembe jutott már, hogy ha nekifogtak a nulláról egy új fejlesztésének, akkor miért nem próbáltak eltérni a mostani kliensek "formájától". Gondolok itt arra, hogy bármelyik Web klienst is nézzük, a fő felépítése azért nagyrészt követi a C# kliens felépítését. Persze értem én , hogy az is nagyon fontos, hogy a sok ezer adminisztrátor átállása minél gördülékenyebb legyen az új kliensre, de talán itt lett volna a lehetőség arra, hogy valami teljesen újat készítsenek. Más felépítés, más logika, stb. Mindez azért jutott az eszembe, mert a legutóbbi (v2.19) verzióban kísérletképpen beletettek egy új "dashboard" szerű főoldalt, ami a többi kliensben nincs. Talán ez abba az irányba mutat, hogy lesznek még szokatlan, újító megoldások a jövőben is. Bár nem egy nagy durranás, de azért érdemes tenni vele egy próbát.


Természetesen vissza lehet állni a szokásos főoldalra, illetve ha több vCenter szerver van, akkor lehet köztük váltogatni.

Bár szerintem az lesz a jövőben, hogy a vRealize Operations felhasználásával fognak majd egy vagy több jópofa dashboard-ot átemelni a kliensbe. Mit gondoltok minderről?

Ezúton kínvánok Nektek Boldog Új Évet!



2016. december 20., kedd

Virtuális gépek címkézése meglévő CMDB adatok alapján, avagy Tag kezelés PowerCLI segítségével

A hatos verzió előtt az ún. "Custom Attributes" használatával tudtunk egyedi megjegyzéseket fűzni a virtuális gépekhez. Egy időben igyekeztem használni, de a beállított értékeket nagyon nehéz volt követni, szükség esetén módosítani, stb. Így egy idő után már nem sok köze volt a valósághoz.
Az új, hatos verzióban megjelent Tag-ek sokkal rugalmasabban kezelhetőek, de ha nem gondoskodunk az értékek aktualizálásáról, akkor az sem sokat ér. Főleg ha a gépek száma már közel van az ezerhez.
Viszont ha van egy olyan nyilvántartásunk, amiben minden fontos adat megtalálható, azok aktualizálása megoldott, akkor adja magát, hogy ezeket a címkéket (vegyesen használom a következőkben a tag és címke kifejezést) onnan töltsük fel, és időnként onnan frissítsük. Erre pedig a PowerCLI tökéletes eszköz. De mielőtt ebbe belemennénk, nézzük meg röviden, milyen lehetőségeink vannak a címkék kezelésére a PowerCLI-ban, illetve mi is az a Tag?

Egyszerűen lekérdezhetjük, hogy milyen parancsok állnak a rendelkezésünkre:



Az infrastruktúra különböző elemeihez (virtuális gépek, hostok, datastore-ok, stb) különböző címkéket fűzhetünk. Pl. egy virtuális géphez hozzáfűzhetünk egy Tulajdonos és/vagy egy költséghely címkét. Ehhez a következő lépéseket kell megtenni.

  • létrehozni egy Tulajdonos nevű Tag ketegóriát
    New-TagCategory -Name "Tulajdonos" -Cardinality single -EntityType VirtualMachine 
  • kategórián belül létrehozni különböző cimkéket
    $NewTag1=New-Tag -Name "Kovács János” -Category Tulajdonos
    $NewTag2=New-Tag -Name „Nagy Béla” -Category Tulajdonos
  • ezeket hozzárendelni egy vagy több virtuális géphez.
    New-TagAssignment -Tag $NewTag1 -Entity $vm1
    New-TagAssignment -Tag $NewTag2 -Entity $vm2


A kategória esetében a "Cardinality" azt jelenti, hogy egy adott objektumhoz az adott kategóriából csak egy vagy akár több is rendelhető-e. Pl. "Produktív", "Teszt" vagy "Fejlesztői" közül pontosan egy címke adható egy géphez.

Természetesen, mint a fenti képen látható, tudunk törölni, módosítani, lekérdezni címkéket, kategóriákat, hozzárendeléseket. Ezekre részleteiben nem térnék ki, egy részük benne lesz a következő példa scriptben.

A konkrét feladat a következő. Létezik egy adatbázis, amiben a gépekről mindenféle információ napkarész állapotban elérhető. Ez egy MS SQL adatbázis. Másrészt vannak a virtuális gépeink, amik alaphelyzetben nem rendelkeznek címkékkel. Ezt csak a Web kliensben tudjuk ellenőrizni (illetve  az új HTML5 kliensben is).


Ha gondom valamelyik géppel, akkor előbb valahol máshol meg kell néznem, hogy kit is kereshetek. Viszont ezek az infók benne vannak az előbb említett adatbázisban, így ha  onnan a fenti Tags mezőket fel tudnám tölteni, akkor kényelmesebb lenne ez ilyen helyzetek kezelése.
Mivel a PowerCLI Powershell alapú, és a Powershell természetesen támogatja az SQL adatbázisok kezelését is, így egy scriptben, direktben át lehet tölteni az adatok az adatbázisból a vCenter inventory-ba.

Mielőtt bármit tennénk, létre kell hozni a szükséges címke kategóriákat. Ebben a konkrét esetben ez így néz ki,

New-TagCategory -Name "Alk.gazda" -Cardinality single -EntityType VirtualMachine
New-TagCategory -Name "Szervergazda" -Cardinality single -EntityType VirtualMachine
New-TagCategory -Name "Emails" -Cardinality single -EntityType VirtualMachine
New-TagCategory -Name "Megjegyzes1" -Cardinality single -EntityType VirtualMachine
New-TagCategory -Name "Application" -Cardinality single -EntityType VirtualMachine
New-TagCategory -Name "PatchPhase" -Cardinality single -EntityType VirtualMachine

New-TagCategory -Name "Prod.Type" -Cardinality single -EntityType VirtualMachine 

Ezután a Powershell-hez hozzá kell adni az SQL használatához szükséges modult, majd kényelmi szempontból elnavigálunk a kérdéses adatbázishoz.

Import-Module sqlps

Set-Location SQLSERVER:\SQL\SQL_szerver\Instance\Databases\CMDB_Database 

Ezután össze kell állítani egy olyan SQL lekérdezést, ami visszaadja a kívánt adatokat. Feltételezve, hogy van egy szervertip mező, ami alapján a VMware virtuális gépek szűrhetőek.

$sqltext="select rtrim(host) host,....,<további mezők> from dbo.CMDBTable where szervertip='VMware'"

Ha ez megvan, akkor a select eredményét be kell tölteni egy tömbbe. A Powershell tartalmaz saját tömb típust, de érdemesebb használni a .Net-ben definiáltat, mivel az sokkal kényelmesebben kezelhető.

$DotNetMOMInfoArray=New-Object System.Collections.ArrayList

$DotNetMOMInfoarray=invoke-sqlcmd -Query $sqltext|select host,szervergazda, Alk.gazda,Emails,megjegyzes1,patchphase,application 

SQL Select-et az Invoke-Sqlcmd -Query parancs segítségével tudunk futtatni. Az így kapott eredményhalmazból azokat a mezőket kell csak a tömbbe tenni, amikkel foglalkozni szeretnénk. A host mező tartalmazza a gépek neveit, a többi pedig olyan értékeket, amikkel címkézni fogjuk a virtuális gépeket. Azaz ebben a konkrét esetben szervergazda, alkalmazás gazda, email címek, megjegyzés1 mező, patch fázis, és alkalmazás azonosító.

Nézzük a script "törzsét" . (a címkékkel kapcsolatos műveletek egy külön eljárásban lesznek)

$vm_lista=get-vm Location Datacenter1

foreach ($vm in $vm_lista)
{

$mom_hostname=$vm.name

$HolVAn=$DotNetMOMInfoArray.Host.IndexOf($mom_hostname)

if ($HolVan -ne -1)
{
    cimke1 'Szervergazda'
    cimke1 'Emails'
    cimke1 'Alk.gazda'
    cimke1 'megjegyzes1'
    cimke1 'patchphase'
    cimke1 'application'
}


$vm_lista változóba betöltjük a szükséges géplistát, majd egyesével megnézzük, hogy az SQL lekérdezésben szerepel-e a gép. Ha igen, akkor a lentebb lévő eljárást meghívjuk a hatféle címke kategóriának megfelelően.

A legegyszerűbb az lenne, ha mindig törölnénk a meglévő címkéket, és újra létrehoznánk őket. De feltételezve, hogy ezek az értékek ritkán változnak meg, jobbnak tűnik az, ha egy kicsit bonyolultabb scriptet írunk, és csak ahhoz nyúlunk, ami megváltozik. Nézzük az eljárást.

function cimke1{

param($t_category)


    if (-not $DotNetMOMInfoArray[$HolVAn].$t_category)
    {
        $DotNetMOMInfoArray[$HolVAn].$t_category='--Nincs--' 
    }

    $ExistingTag=Get-Tag  -Category $t_category |where {$_.name -eq    $DotNetMOMInfoArray[$HolVan].$t_category}
   
  
    if ($ExistingTag)
    {
        $VMTag=Get-TagAssignment -Entity $vm -Category $t_category -ErrorAction SilentlyContinue
        if ($VMTag.Tag.Name -ne $ExistingTag.Name)
        {
             Remove-TagAssignment -TagAssignment $VMTag -Confirm:$false
             New-TagAssignment -Tag $ExistingTag -Entity $vm
        }
       
    }
    else
    {
        $NewTag=New-Tag -Name $DotNetMOMInfoArray[$HolVAn].$t_category -Category $t_category
        $VMTag=Get-TagAssignment -Entity $vm -Category $t_category -ErrorAction SilentlyContinue
        Remove-TagAssignment -TagAssignment $VMTag -ErrorAction SilentlyContinue -Confirm:$false
        New-TagAssignment -Tag $NewTag -Entity $vm

    }


    } cimke #függvény vége 

Néhány megjegyzés.

  • döntés kérdése, hogy ha egy szerver esetében egy adott címke nem létezik, akkor mi legyen. Egyáltalán ne hozzuk létre, vagy ahogy én csináltam, egy "--nincs--" szöveggel jelöljük.
  • $t_category tartalmazza, hogy melyik címke kategóriáról van szó
  • ha egy címke még nem létezik, akkor előbb létre kell hozni
  • ha egy gépnek már van címkéje, de az SQL adatbázisban megváltozott, akkor előbb törölni kell, majd újra létrehozni.

A végére pedig nézzük meg a végeredményt:


Remélhetőleg van még olyan, aki még ezeket nem ismerte és segíteni tudtam.

Végezetül mindenkinek Kellemes Ünnepeket Kívánok!!


2016. december 14., szerda

Xorux - LPAR2RRD Datastore monitoring és egyebek

Ebben az utolsó részben röviden bemutatom, hogy milyen lehetőségeket biztosít datastore monitorozáshoz, illetve milyen egyéb kisebb-nagyobb, de nagyon hasznos képessége van még az lpar2rrd-nek. (Virtuális gépek és hostok monitorozása az előző cikkekben találhatóak)

Datastore

Természetesen ez előzőek ismeretében már elég jól ki lehet találni, hogy mire számíthatunk, ha datasore-okról van szó.

Foglaltság

Szokásos értékek, azaz kapacitás, használt és provisioned tárhely. Ha ez a cikk néhány hónappal hamarabb születik, akkor egészen más jellegű lenne a lenti kép. Ugyanis a régebbi storage esetében thin diszkeket használtam, így a used és a provisioned értékek akár jelentősen eltértek egymástól. Az új felállásban viszont ezt rábíztuk a storage-ra, és a virtuális gépek thick diszkeket kaptak. Ezért nincs igazából eltérés a used és provisioned között.


MB/sec

Nagyon szemléletesen mutatja az írás és olvasás sebességét, amint a lenti ábrán látjátok is. Az y tengely pozitív oldalán mutatja az írás, a negatív oldalán pedig az olvasás nagyságát. Érdemes nagyban is megnézni (mivel a kis méretben a csúcsok eltűnhetnek), hogy lássuk mekkora maximális írási vagy olvasási sebességek történtek az adott intervallumban.


IOPS

Hasonló megoldással mutatja az IOPS értékeket is. 


Datastores TOP

Nem pontosan illik ebbe a sorba, de ha már datastore a téma, akkor van Datasore TOP diagram is. Tetszőleges időszakra táblázatos formában, a szokásos napi, heti, havi és éves időszakokra diagramokon láthatjuk az értékeket. Ezekből pedig van öt különböző, IOPS read és write, data read és write, valamint használt tárhely. Pillanatok alatt átlátható, hogy van-e olyan datasore, ami valamilyen szempontból sokkal jobban terhelt mint a többi.



Egyebek

Nagyon sok ábrán lehetne még bemutatni, hogy a három nagy téma (vm, host, datastore) mellett miket tud még az alkalmazás. De nem szeretném ezzel feleslegesen növelni a bejegyzés méretét. Úgy gondolom, hogy akit az eddigiek nem győztek meg, azt úgysem érdeklik nagyon a kisebb, de nem kevésbé hasznos képességek sem. Aki viszont szívesen kipróbálja, az majd úgyis meglátja miket tud még. De persze néhány fontos dolgot nézzünk még meg :)

Dashboard

Van egy default dashboard, illetve mi is összeállíthatunk újabbakat, amiket névvel ellátva el is tudunk menteni. Tulajdonképen ez egy nagyon kis diagramokból álló oldal. Ránézésre kb. 200 pont széles lehet. Igazából arra jó, hogy a kis ábrára klikkelve megnézhetjük nagy méretben is, hiszen a kis méret miatt még inkább torzulnak a csúcsok. Így néz ki a default egy kis részlete:


A default dashbord tartalmazza az összes host két fajta napi CPU diagramját (részletek a hostok leírásánál), valamint ha készítettünk úgynevezett Custom Group-okat, akkor azokat is.

Saját dashboard-ot pedig úgy készíthetünk, hogy ha az aktuális diagram jobb-felső sarkában van egy csillag, akkor arra kattintva hozzáadhatjuk az aktuálishoz. Ha egy teljesen újat akarunk csinálni, akkor előbb ne felejtsük el a Clear Dashboard gombra kattintva törölni a megjelenített tartalmat. Amikor pedig végeztünk, összeállítottuk úgy ahogy nekünk hasznos, akkor a Save Dashboard-dal nevet adva elmenthetjük.

vCenter Totals

Három lehetőségünk van, de egy nagyobb környezet esetében igazából csak kettőt érdemes használni. Képes megjelenti egy ábrán a vCenteren lévő összes hostot vagy clustert vagy virtuális gépet. Ez utóbbira gondoltam az előbb. Több ezer virtuális gép esetében elég nehéz lenne bármit leolvasni az ábráról. De pl. clusterek esetében igen hasznos ábrát kapunk:


Cluster Totals

Ez egy újabb szint, ahol információkat tudunk nagyon gyorsan kinyerni az lpar2rrd használatával. Ez annyival több az előző pontban lévőknél, hogy trend ábrát is kapunk. Azaz egy adott cluster esetében láthatjuk, hogy mi várható egy múltbeli időszak alapján a jövőben. (előző hónap, előző három hónap, előző év alapján). Mindezt CPU és memória vonatkozásában is megnézhetjük. Példának nézzünk egy ilyen képernyőt is.


Természetesen az is érdekes lehet, hogy a cluster hostjai hogyan teljesítenek.


Összegzés

Láthattátok, hogy annak ellenére, hogy egy ingyenes alkalmazással van dolgunk, az lpar2rrd nagyon hasznos és sokat tud. Miközben ezek a cikkek születtek, kijött egy kisebb javítás, amiben elvileg az Excelbe is lehet már importálni a historical riportokat. Ez csak arra példa, hogy a fejlesztés nem áll le.
Még egy fontos dolog, amit talán eddig nem említettem. Ezek a diagramok automatikusan frissülnek. azaz ha van egy kedvenc képernyőnk, akkor azt nem kell frissíteni ahhoz, hogy lássuk az új értékeket, hanem ez 20 percenként megtörténik.

Ha esetleg valaki adott neki egy esélyt, és kipróbálta, az pár szóban számoljon be róla, mindenkinek hasznos lehet.





2016. december 8., csütörtök

VMware Learning Zone - 60 napos ingyenes próba előfizetés

Véletlenül vettem észre, nem tudom meddig van ez a lehetőség. Azt hittem, hogy ez egy olyan hatvan nap, amikor a teljes tartalmat szabadon böngészhetem. De sajnos nem így van. Van amit igen, de olyan is van, amiből csak a demóhoz férhetünk hozzá. Pl. a VCP6-os vizsgaanyagok ilyenek.

Az előfizetés nagyon egyszerű, ha már van accountunk a VMware Education oldalán. Belépés után a főoldalon katt a VMware Learning Zone linkre.


Majd Free Trial és Register Now!

Kapunk egy összefoglaló képernyőt, majd folytatás.


Utána egy értesítés, hogy minden kész, lehet kezdeni. (erről email is jön)


Első belépéskor automatikusan elindul egy videó, ahol a lehetőségeket elmondják, de nyugodtan ki lehet hagyni, nem egy bonyolult felületen kell navigálni.
A kezdeti képernyőnk valami ilyesmi.


Ahol nem látjuk azt, hogy Enrolled, ott csak a demó tartalomhoz férhetünk hozzá. Ez gyakorlatilag azt jelenti, hogy a videó kb. első percét lehet megnézni.

Erről többet nem érdemes írni, aki kipróbálja, úgyis végignézi a lehetőségeket.

Regisztrációt követően a későbbiekben a MyEnrollments linkről tudunk továbblépni a tanagyagokat, webcastokat, oktató videókat tartalmazó oldalra.

Jó tanulást!!


2016. december 3., szombat

Xorux - LPAR2RRD Host monitoring

Ma megemlékeztem a Mikulásról egy majdnem 30 kilométeres teljesítménytúrán a Bükkben (1170 m szintemelkedés!!), és persze kaptam is tőle egy kis csomagot. Egy kis ízelítő, hátha valaki kedvet kap hozzá.




Miután megvolt a pihenés, folyadékpótlás :), úgy gondoltam hasznosan töltöm a szombat estét és a lpar2rrd-ről szóló cikkeknek megírom a harmadik részét. Íme.

Aki már olvasta az első és második bejegyzést az lpar2rrd kapcsán, az már nagyjából tudja, mit várhat, ha ESXi host monitorozásról van szó. Természetesen a szokásos (CPU, memória, diszk, hálózat) megvan, de vannak ettől összetettebb diagramok is, aminek egy rész most, de a többség majd az egyéb lehetőségeket bemutató negyedik részben lesz. Mint mondtam, a fejlesztés folyamatos, így várható, hogy a lentiektől eltérő lehetőségeket is beépítenek majd az eljövendő verziókba.

Heatmap

Teljesen hasonló, mint a virtuális gépek esetében. Az elmúlt óra értékei alapján egy színskála felhasználásával mutatja meg, hogy mekkora terheléssel üzemelnek a hostok. A szürke azt jelöli, hogy a host már nem létezik (nincs elmúlt órás adat), de a rendszerben még ott van, a régebbi adatok lekérdezhetőek. Az ábra "élő", azaz az egyes négyzetre kattintva az adott host részletes diagramjaihoz jutunk.



CPU (pool)

Megmutatja, hogy az összes core-ból (bal tengely) ill. rendelkezésre álló GHz-ből (jobb tengely) mennyit használ az adott host. Megszokott módon van elmúlt napi, heti, havi és évi ábra, valamint nagyobb méretben meg lehet nézni az egyes ábrát, valamint egy időszakot is ki lehet jelölni.


CPU (VMs aggregated)

Egy kis újdonság. Megmutatja, hogy egy adott host fenti ábrán látható terheléséből mennyit vesznek ki az egyes virtuális gépek. Látványos és hasznos ábrák, bár ha nagyon sok virtuális gépet futtat a host, akkor elég nehéz beazonosítani, melyik terület melyik gépnek felel meg. Mivel az összefoglaló ábrák kötött méretűek, ezért az ábrák alján a géplistából is csak egy részlet látható, de oda kattintva lehet görgetni a listát, sőt szűrni is lehet.


Természetesen ha egy ábrára  rákattintunk, akkor több információ kiolvasható a méret miatt is (több képpont), valamint az ábra alján az összes virtuális gép nevét és színét, és az értékeket is láthatjuk.



Memória (Total, Granted, Active, Baloon)

Egy ábrán láthatjuk a fenti négy értéket a szokásos napi, heti, havi, éves megjelenítéssel. Mivel a Ballon értéke szerencsére nulla, így az az érték nem látszik.


Memória (VMs aggregated)

Hasonlóan a CPU használathoz, megnézhetjük, hogy a Granted érték hogyan oszlik el az egyes virtuális gépek között. Itt is probléma, ha nagyon sok gép van, de ha kinagyítjuk a diagramot, akkor pontosabb képet kapunk, és az összes virtuális gép neve, és az átlagos granted érték leolvasható a diagram alján.


Disk (és Net)

Erről nem lehet sokat mondani. Példaként lássuk egy host estében a Disk használat alakulását.


View

Gondoltak arra is, ha valaki egy ábrán szeretné látni a különböző típusú mérések megjelenítését. Ezt nevezi View-nak. Külön van napi, heti, havi és éves értéket megjelenítő fül a GUI-ban.

Egy View a következőket tartalmazza:

  • Host CPU pool
  • Host CPU aggregated
  • Memória használat
  • Memória aggregated
  • Virtuális gépenként CPU használat

Az összes ábra nagyítható, vagy egy részlet kinagyítható belőle.


A fentieken kívül van még néhány lehetőségünk (historical report, TOP listák, stb.), de ezt majd legközelebb. Mint ahogy a Datastore monitorozás és vCenter vagy cluster szintű riportok is az utolsó, negyedik részben lesznek.



2016. december 1., csütörtök

Egy kis PowerCLI - virtual socket és virtual core lekérdezése

Már egy ideje lehetőség van arra, hogy egy virtuális gép esetében ne csak azt mondjuk meg, hogy hány vCPU-t tartalmazzon, hanem azt is, hogy ezek milyen virtuális socket/core elrendezésben legyenek. Ennek több előnye is van, pl. licence szempontból sokszor nem mindegy, hogy 1 db. 4 core-os CPU van a virtuális gépben, vagy pedig 4 db. 1 core-os.

Viszont ha bármelyik kliensben megnézzük egy virtuális gép adatait, ott csak az látszik, hogy mennyi CPU van. Ha az elrendezést is látni szeretnénk, akkor a virtuális gép módosítását kell választani, és ott már látszik.

Ha PowerCLI-t használunk, ott sem másabb a helyzet.


Tegyük fel, hogy olyan listát kell készíteni az SQL-t futtató virtuális gépekről, ahol látszik az is, hogy a fenti képen látható 8 vCPU mennyi virtuális socket-ben helyezkedik el. Ehhez persze lehetne írni szépen formázott kis eljárást, de most inkább maradjunk egy egysoros scriptnél, mivel a lényeg benne van.

 get-vm -Location SQL|get-view|select Name 
                                     ,@{N="vCPU";E={$_.Config.Hardware.NumCPU}}
                                     ,@{N="vSockets";E={$_.Config.Hardware.NumCPU/$_.Config.Hardware.NumCoresperSocket}}
                                     ,@{N="vCores";E={$_.Config.Hardware.NumCoresperSocket}}|ft * -AutoSize 

A fenti script valóban egysoros, csak az olvashatóság miatt van több sorba szétszedve. A "trükk" csupán annyi, hogy ezt az információt a get-view használatával kaphatjuk meg. A végén az -AutoSize nélkül a listát széthúzva mutatná az egész gépernyőn, így viszont összébb húzza az aktuális méreteknek megfelelően.

Az eredmény:


vCPU- amit egyébként is látunk
vSockets - mennyi virtuális socket van a gépben
vCores - egy virtuális socket-ben mennyi virtuális mag taglálható

2016. november 25., péntek

Xorux - LPAR2RRD VM monitoring

Az előző cikkben röviden leírtam, hogy mi is ez, honnan lehet letölteni, és hogyan kell telepíteni. Most azt mutatom be, hogy milyen lehetőségeket tartalmaz virtuális gépek monitorozásához.
Előbb néhány technikai adat.

Az értékeket a következő szabályok szerint tarja meg:

  • 1 perces értékek 60 napig
  • 5 perces értékek 3 hónapig
  • 1 órás értékek fél évig
  • 5 órás értékek egy évig
  • 1 napos értékek 3 évig őrződnek meg

Ezek a beállítások az ingyenes változatban nem módosíthatóak.

A másik fontos dolog, amit tudni kell, hogy hogyan kezeli a fizikai megjelenítést. Az alap diagramok 400 pont szélesek. Viszont egy teljes napi adatsor 24*60, azaz 1440 értéket tartalmaz. Így a megjelenítéskor átlagolja az értéket. Ez persze hatással van a rövid ideig tartó csúcsokra. Viszont tartalmaz három lehetőséget is arra, hogy teljes részletességgel lássuk az adatokat.

  • ha rákattintunk egy diagramra, akkor külön ablakban, nagyobb méretben megjelenik
  • lehetőségünk van kijelölni egy időszakot a digramon, és azt megnézni nagyobb ábrán
  • illetve vannak ún. historical riportok, ahol megadhatjuk, hogy hány képpont széles legyen a diagram

Akkor nézzük, hogy milyen lehetőségeink vannak virtuális gép monitorozással kapcsolatban.

Heatmap

Egy egyszerű összefoglaló ábra az elmúlt egy óra adatai alapján. Külön CPU és memória értékekkel. Az egyes kis négyzetek linkek is, egy kattintással megnézhetjük az adott gépet részletesebben is.



CPU %

Egy képernyőn megnézhetjük a legutolsó nap, hét, hónap és év értékeit, valamint ezen értékek alapján havi, három havi és éves trendet határoz meg.


Ha valamilyen napon vagy héten belüli ciklikusság van az értékekben, akkor ez innen ránézésre is leolvasható. Fentebb már írtam, hogy a kis méretű ábra miatt az értékek "laposabbak" a valóságosnál. De ha pl. a napi ábrára rákattintunk, akkor már másabb a kép:


De ha pl. a havi ábrának szeretnénk egy kisebb szeletét megnézni, akkor egyszerűen kattintsunk bele az ábrába a kezdethez, majd lenyomva tartva az egeret, húzzuk el addig, amíg ki szeretnénk nagyítani:


Ez egy kb. 11 nappal ezelőtti, egy napnál valamennyivel hosszabb időtartam.

CPU GHz

Nem szaporítom az ábrákat, a trend diagramot leszámítva pontosan olyan mint az előző ábra, csak nem %-ban, hanem GHz-ben vannak kifejezve az értékek.

Memória

Szerkezetében követi a CPU értékeknél megismertet, de itt több értéket jelenít meg egy ábrán:


Látszik a granted, az aktív és szerencsére nem látszik a baloon :)
Itt is van egy trend, amiből jó esetben vonhatunk le következtetéseket.

Disk és Net

Helytakarékosság miatt ide nem szúrnék be ábrát, de a fenti szerkezetben, MB/sec értékekben (illetve ha szükséges, akkor kB/sec) ábrázolja az storage ill. hálózati forgalmat.

vMotion

Nagyon látványosan mutatja be, hogy az adott virtuális gép mikor, melyik hoston futott, ott milyen CPU értékeket produkált GHz-ben. Ebből is van napi, heti, havi és éves ábra. Mivel a fenti gép nem sokat mozgott, ezért egy másik gép értékeit szúrom be:


Látszik, hogy február közepétől megy a monitorozás, onnan számítva május elejéig nem volt mozgás, utána viszont két hónapon belül volt négy is. Ilyet máshol még nem is láttam, szerintem nagyon hasznos.

Custom Groups

Ez egy viszonylag új képessége a programnak (AIX esetében már régebben benn volt). A lényege az, hogy tetszőleges szempont szerint összeválogathatok virtuális gépeket, és azt együtt ábrázoltatom. Az ingyenes verzióban sajnos maximum négy elemű lehet a csoport, de ha veszünk támogatást, akkor tetszőleges számú gépet berakhatunk a csoportba. Ezt tehetjük egyesével, vagy regex kifejezéssel.


Amikor több adatsorunk van, akkor még szűrni is tudunk az ábra alatt. Ha pl. van 4 gépünk, amit együtt érdemes figyelni, akkor ez egy nagyon jó lehetőség. Ha több van, akkor sajnos ezt ebben a verzióban nem tudjuk megtenni. A virtuális gépek összességére is képes trendet meghatározni, és természetesen itt is tudunk kinagyítani, vagy csak egy konkrét időszakra megnézni az értékeket.

Historical reports

Ismét egy nagyon jól használható funkció. Ki tudunk választani akármennyi virtuális gépet, meg tudjuk mondani, hogy mettől meddig akarjuk megjeleníteni az adatokat, megadhatjuk a diagram méretét (ugye ez fontos, mert minél nagyobb időintervallumot választunk, annál több adatpont lesz), és még azt is megmondhatjuk, hogy a CPU, memória, disk, hálózat, vagy a fentebb részletezett vMotion-t is megjelenítő diagramokat akarjuk-e látni. Ez utóbbira egy ábra:


Bizonyos esetekben arra is van mód, hogy a megjelenített ábrákat pdf állományba mentsük, de az ingyenes verzióban ez is csak korlátozottan érhető el.

Összegzés

Mint láthattátok, nagyon jól használható, nagyon látványos az lpar2rrd. Ha valaki tőlem valamilyen ábrát kér, akkor mindig ezt használom, főleg ha régebbi időszakról van szó. És mivel folyamatosan fejlesztik, várható hogy idővel még többet fog tudni.




2016. november 24., csütörtök

Xorux - LPAR2RRD

Régebben elég sok időt eltöltöttem azzal, hogy próbáltam a vCenteren lévő performancia adatok egy részét megőrizni úgy, hogy abból hosszabb távra is lehessen kimutatásokat készíteni mondjuk az 5 perces adatok alapján. Részsikerek voltak (ezekről itt és itt, valamint részben még itt írtam).
Persze világos volt, hogy találok ettől sokkal jobb, kényelmesebb és ingyenes megoldást is ha keresek, de egy kicsit jó volt beleásni magam a vCenter adatbázis felépítésébe.

Ha lesz rá mód, akkor írok a jövőben más termékekről is, de most szeretném nektek bemutatni azt, ami a legjobban tetszett eddig. Ez pedig a Xorux cég Lpar2rrd nevű terméke.

Ezt állítják magukról:

Bring on the market an easy solution for performance monitoring and capacity planning of your highly virtualized environment with the GUI understandable from technician to the management level. Our tools should act as the front-end tools where you can easy and quickly identify load abnormality and locate problems on the infrastructure level.

Nem a VMware az egyetlen amihez fejlesztenek, sőt talán nem is ez a legfontosabb, de majd mint látni fogjátok, komoly munkát végeztek itt is. A telepítése rendkívül egyszerű, mivel egy .OVA file-t kell csak letölteni, és telepíteni. Az appliance előre telepítve tartalmaz minden olyan komponenst, amivel nem csak a VMware, hanem a többi támogatott környezet is monitorozható.


Bár a többihez kell még némi manuális konfiguráció, a VMware esetében használatra kész. A fenti képen látható, hogy kb. mire is használható a termék.

Miután VMware GUI based linkre kattintunk, beállíthatjuk, hogy mely vCenterhez vagy vCenter szerverekhez szeretnénk csatlakozni. Ez a baloldalon található Configure opcióval érhető el. Ott kattintsunk a Create New Credentials gombra, majd adjuk meg a vcenter szerverünk adatait.


Ha több környezetünk van, akkor egyesével vigyük fel a rendszerbe. Ha végeztünk, akkor a run data load megnyomásával el is kezdhetjük az adatgyűjtést.


A termék ingyenes, de vásárolható támogatás is hozz. Ebben az esetben minimálisan több lehetőségünk lesz. De ha eddig bármi problémám volt, a fórumban mindig kaptam választ és megoldást is.

Folyamatos a fejlesztés, és a javítócsomagokat nagyon egyszerűen, a GUI-n keresztül betölthetjük. Ehhez csak le kell tölteni a kis méretű .rar file-t, és a baloldalon az RPAR2RRD alatt lévő Product upgrade funkcióval egyszerűen rá kell mutatni a .rar file-ra és Upload file. Ennyi.

A következő cikkben néhány látványos ábrán szeretném bemutatni, hogy mit is tud. Mivel már 8-9 hónapja használom, ezért már sok adat van, így nemcsak a napi, hanem az éves diagramok is használhatóak. De ezt majd legközelebb.

2016. november 17., csütörtök

Első találkozás a VMware Virtual Volumes (VVols) technológiával

Már biztosan mindenki ismeri a VVols mögötti elméletet, sőt biztosan többen ki is tudtátok már próbálni. Nekem eddig erre nem volt lehetőségem, viszont most már igen. Természetesen egyelőre szó sem lehet az éles használatról, hiszen annak ellenére, hogy már nagyon régen fejlesztik, még mindig nem egy kiforrott dologról beszélünk. Talán a 6.5 valamelyik upgrade csomagja után már komolyabban lehet majd venni. Addig is érdemes ismerkedni vele, elolvasni a lehetőségeket, és amennyiben mód van rá, testközelből megnézni.

Ehhez igazából nem kell más, csak 6-os vCenter és ESXi, valamint egy olyan storage, ami erre fel lett készítve. A felkészítve itt azt jelenti, hogy van hozzá VASA 2.0-ás provider. Jelen esetben ez egy HPE 3par StorServe storage 3.2.2-es firmware-rel.
Nem volt célom azt megnézni, hogy pontosan mit lehet ezzel kezdeni, milyen performanciára képesek az ilyen virtuális gépek, stb, hanem csak azt szerettem volna elérni, hogy legyen egy virtuális gépem, ami egy VVol datastore-on van, és be lehet kapcsolni.

Az egyes storage gyártók eltérnek abban, hogy a fentebb említett VASA provider-t milyen módon valósítják meg. Ez a HP esetében része a firmware-nek, így nagyon leegyszerűsíti a használatát. Fontos, hogy a a GUI-ba ebből semmi nincs kivezetve, minden storage oldali VVol specifikus konfigurálást a parancssorban kell elvégezni.

A showvasa paranccsal lehet lekérdezni a provider állapotát.


Ha még semmit nem csináltunk, akkor a képen látható módon tiltott állapotban van. Ahhoz hogy el tudjuk indítani, ahhoz egy megfelelő tanúsítványra is szükség van. Ha ez megvan, akkor el lehet indítani a startvasa paranccsal.


Most már engedélyezett, ez a része rendben van. A képen még egy fontos dolog látható. Ezt a linket kell majd a vCenter szervernél megadni, amikor a storage provider-t regisztráljuk.

Következő lépésben gondoskodni kell arról, hogy a VVol terminológia szerint létrehozzunk egy storage container-t. Ez a gyakorlatban a 3.2.2-es firmware-től azt jelenti, hogy létre kell hozni egy volume set-et, amit hozzárendelünk egy storage container-hez, a következő két paranccsal: createvvset <vvset_name> illetve setvvolsc -create set:<vvset_name>. Több storage konténerünk is lehet, ezek közül majd a VVol típusú datatsore létrehozásánál lehet választani. Természetesen legalább egy CPG-nek is létezni kell, különben a startvasa hibaüzenettel elszáll. Én egy vvol_vmware_set nevű storage container-t hoztam létre.

Leegyszerűsítve ennyi előkészület kell a storage oldalon HP StoreServe esetében.

Következik a vCenter oldali konfiguráció. Első lépésben fel kell venni a storage provider-erek közé a showvasa parancs által visszaadott linket. Ezen a címe keresztül fog a vCenter szerver, ill. az érintett hostok kommunikálni a storage-on futó vasa szolgáltatással. A beállítást a vCenter Server/Manage/Storage Provider fülön tehetjük meg.


Sikeres regisztráció után megnézhetjük a részleteket:


Illetve a storage provider és storage system részletei is kiolvashatóak:



Miután itt minden rendben van, tovább lehet lépni. Most már van vasa provideren keresztül elérhető storage rendszerünk, elvileg már csak egy VVol típusú datastore-ra van szükségünk, ahova a gépeinket tehetjük. Ehhez a szokásos módon kezdhetünk hozzá: Storage/New Datasore.



Látható, hogy erre a célra van egy speciális datastore típus. Természetesen a továbblépéshez ezt kell választani.


Adjunk nevet a datastore-nak, és válasszuk ki hozzá a megfelelő storage konténert. (Itt van egy kis csalás, mivel már a datastore-t létrehoztam korábban, ezért van kitöltve az Existing Datasore mező).

A következő, egyben utolsó lépésben meg kell adnunk, hogy mely hostok számára akarjuk elérhetővé tenni a most létrehozott datastore-t, és készen is vagyunk.
Megnézhetjük a szokásos Summary fülön, hogy mi is jött létre:


Ezek után már nincs semmi akadálya annak, hogy virtuális gépeket hozzunk létre. Persze ezt még lehet tovább finomítani, hiszen különböző storage policy-kat hozhatunk létre, amivel megmondhatjuk, hogy a virtuális gépek milyen "storage környezetbe" kerüljenek. Pl. thin vagy thick, milyen legyen a RAID szint, legyen-e deduplikáció, stb. Az, hogy milyen lehetőségeink vannak, az a vasa provider által a storage-ről küldött információkból tudja a vCenter szerver. Ebben a konkrét környezetben pl. ilyen lehetőségeink (is) vannak:


Azaz megmondhatjuk, hogy legyen RAID1, legyen a zero detektálás bekapcsolva és a deduplikáció legyen kikapcsolva.
De ha semmit nem hozunk létre, akkor is van egy default policy a VVol-ok számára.

Most már minden adott ahhoz, hogy létrehozzuk az első virtuális gépet. Mielőtt megtennénk, nézzük meg storage oldalról, hogy mi látszik:


Az első parancs (showvvolsc) megmutatja, hogy egy darab storage konténerünk van. Megtévesztő módon azt mondja, hogy egy darab virtuális gép van rajta, de ez nem igaz. A második parancs (showvvolvm) meg is mutatja, hogy nincs. Valószínűleg a HA által létrehozott mappára érti az egyet.

Hozzunk létre egy virtuális gépet egy lemezzel. Legyen ez a vvolvm1. A léterhozást nem részletezem, hiszen ez csak abban tér el, hogy a datastore-nak a korábban létrehozott VVOL3PAR_01-et adjuk meg.

Az elmélet szerint a létrehozott gép két VVol-t kell hogy tartalmazzon (bekapcsolás előtt). Egyet a virtuális diszk számára, egyet pedig a többi paraméter file számára (pl. vmx, diszk leírók, logok). Nézzük, hogy ez igaz-e.


És igaz. Kiolvasható a gép neve, az op. rendszer típusa, a VVol-ok száma, valamint a méretre vonatkozó adatok. Mi történik, ha bekapcsoljuk?


Csak attól, hogy bekapcsoltuk, egyel nőtt a VVol-ok száma. Ez azért van, mert a swap file számára külön VVol jön létre. Bekapcsolás után egyéb más file-ok is keletkeznek, de ez mind bekerül abba a VVol-ba, amiben pl. a .vmx file is van.

Csinálunk egy snapshotot.


Nézzük meg most a VVol-ok számát.


Látható, hogy kettővel nőtt meg a VVol-ok száma. Ennek az az oka, hogy a virtuális gép memóriájáról is készült snapshot, és az mindig külön VVol-ba kerül.

Könnyen kiszámítható, hogy ha pl. van egy gépünk 3 VMDK-val, és van róla két snaphot, ami a memóriát is tartalmazza, akkor összesen 3+1+1+2*3+2=13 darab VVol lesz a storage-on.

A végére egy kis összegzés. A HP által adott dokumentációk alapján viszonylag könnyen el lehetett végezni azokat a beállításokat, amik a rendszer működéséhez szükségesek voltak. Érzetre egy kicsit lassabb volt pl. a gép mozgatás VVol datastore-ról hagyományosra, vagy a datastore tartalmának böngészése, de ez nem biztos hogy valóban így van. Voltak gondok a storage policy-k körül is, de ez lehet hogy csak az én tudatlanságom miatt volt.

Az látszik, hogy a VMware adminisztrátoroknak igen nagy szabadságot adhat a VVol technológia, hiszen a storage admin feladata azzal véget ér, hogy biztosít egy storage konténert a virtuális gépek számára, de azt, hogy melyik gépet milyen módon tároljon a storage, azt már a VMware admin dönti el úgy, hogy storage policy-kat hoz létre a vasa provider által nyújtott információk alapján.

A végére egy kérdés: Nektek van-e már tapasztalatok ezzel kapcsolatban? Esetleg más gyártó termékével kapcsolatban. Van-e aki már élesben használja?