2017. február 2., csütörtök

Egy egyszerű "UNMAP" (VMFS5)

Amióta egy 3PAR 8440-es storage-on tároljuk a virtuális gépeinket, thick (eager zeroed) diszkeket használunk. Azaz a storage-ra bízzuk a hatékony tárhely kezelést. Ez többféle eljárás alapján történhet, pl. deduplikáció vagy zero detection. Az, hogy ezek mennyire hatékonyak, most nem kérdés, a lényeg az, hogy működnek. Pl. egy VMware oldaláról majdnem teleírt 5TB-os datastore esetében ez látszik a storage oldalon:

Ha VMware oldalon nézzük ugyanezt, akkor ez van:


Azaz az 5TB-ból csak 352GB szabad. Eléggé jól látszik a különbség.

Mi történik akkor, ha a fenti datastore-on lévő gépek közül törlünk néhányat? Természetesen a VMware oldalon rögtön látszik a különbség:


Tehát már majdnem 3TB szabad hely van a datastore-on. Viszont ha megnézzük a storage-on, hogy hogyan változik a kötet kihasználtsága, igazából semmit nem látunk. Mintha nem is töröltünk volna. 

Ha azt szeretnénk, hogy tükröződjön storage oldalon is a törlés, akkor az a legegyszerűbb, ha létrehozunk a datastore-on az üres hellyel nagyjából megegyező méretű thick eager zeroed diszket. Ezáltal megtörténik a teljes üres terület nullákkal való feltöltése, így a storage a különböző technikákat használva már tudja csökkenteni a tényleges helyfoglalást. Pl. hozzunk létre egy új gépet a fenti store-on:


Ha elkészült, akkor pedig töröljük. Hagyjunk időt a storage-nak, hogy feldolgozza az új helyzetet, majd nézzük meg úja az első ábrán lévő értékeket.


Több mint 2TB-tal csökkent a tényleges foglalás. Így már jobban néz ki:

VMFS6-os időkben ez talán már majd megtörténik automatikusan, de most még ez manuálisan kell megtennünk.

A fenti képek már az új vSphere kliensben készültek :)


2017. január 20., péntek

Egy kis PowerCLI - Címkék (Tags) használta a get-vm parancsban

Ha már a virtuális gépeinknek vannak címkéi, akkor érdekes lehet az is, hogy miként lehet ezeket használni PowerCLI lekérdezésékben. Címkéket gyárthatunk manuálisan, de ahogy itt olvashatjátok, akár egy meglévő CMDB adatbázisból is feltölthetjük.

Két módszer röviden.

Get-Vm parancs -Tag paraméterének használata

Ha a -Tag paraméter után megadunk egy szöveget, akkor azokat a virtuális gépeket fogja kilistázni, amelyeken valamelyik címke tartalmazza a megadott sztringet (* is használható). Ez is lehet hasznos, ha valamelyik címke jól meghatározott értékeket tartalmaz. Pl. nekünk van egy Patch fázisra vonatkozó címkénk, és ha arra vagyok kíváncsi, hogy melyik gépek tartoznak egy megadott fázisba, akkor csupán ennyi a dolgom:

get-vm -Tag "E1AA" 

Viszont ha az "E1AA" sztring véletlenül szerepel egy másfajta mezőben is, akkor már gond van.


Get-Vm és Get-TagAssignment együttes használata

Ez egy kicsit bonyolultabb, de itt már pontosabban szűkíthetjük a lekérdezéseket.

Get-VM | Select Name,@{N="PatchPhase";E={((Get-TagAssignment -Category PatchPhase -Entity $_ | select -ExpandProperty Tag).Name)}}|?{$_.PatchPhase -eq "E1AA"}


Előbb lekérdezzük az összes gépet, meghatározzuk a PatchPhase értékeket, majd végül szűrünk az "E1AA" értékre. A Select parancs második tagja egy ún. Calculated Property, amely a Property Name-ből (N=) ill. egy property expression-ből (E=) áll.

Ha több címkét is akarunk használni a lekérdezésben, akkor az előbbihez hasonlóan azokra is képezni kell egy-egy property-t. Pl. a következő lekérdezés (az egész egy sor) megadja az összes olyan gépet, aminek a Patch fázisa E1AA, és a szerver gazdája Kovács János.

Get-VM | Select Name,@{N="PatchPhase";E={((Get-TagAssignment -Category PatchPhase -Entity $_ | select -ExpandProperty Tag).Name)}},
@{N="Szervergazda";E={((Get-TagAssignment -Category Szervergazda -Entity $_ | select -ExpandProperty Tag).Name)}}|?{$_.PatchPhase -eq "E1AA" -and $_.Szervergazda -eq "Kovács János"}

Fura mód a Web kliensben a keresésben ezeket a címkéket még nem lehet normálisan használni.Vagy csak én nem találtam még meg.



2017. január 17., kedd

NMON Visualizer

Többször előfordult már, hogy az esxtop által gyűjtött adatokat jó lett volna megjeleníteni grafikus módon. Erre persze a perfmon.exe is használható, de azért sok tekintetben eléggé körülményes, és nem túl felhasználóbarát.

A címben említett NMON Visualizer az IBM egyik belső fejlesztése, amit 2013-ban nyilvánossá tettek. Nem kifejezetten ilyen adatok megjelenítésére fejlesztették, de erre is jó. A támogatott formátumokat megtaláljátok a linken.

A használata nagyon egyszerű. Le kell tölteni a fenti linkről a  NMONVisualizer_2016-02-29.jar file-t, és futtatni. Az esxtop használatával kapott .csv file-t be kell tölteni, és utána már lehet is nézegetni az adatokat.

Előbb pár szó az esxtop használatáról. Csupán egyetlen dolog, hiszen mindenki ismeri. Ha elindítjuk a default beállításokkal batch módban, akkor látható módon igen rövid idő alatt igen sok adat képződik. Ha szeretnénk egy kicsit csökkenti az adatmennyiséget, akkor két dolgot tehetünk. Egyrészt növelhetjük a mintavételek közti időt (-d kapcsoló), vagy pedig az esxtop-ot elindítva interaktív módban, az egyes kategóriáknál az "F" használatával elvesszük a nem szükséges mezőket. Ha összeállt úgy, ahogy nekünk elégséges, azaz minden felesleges adat megjelenítését kikapcsoltuk, akkor az aktuális beállításból készíteni kell egy új konfig file-t (W), és a batch módú futtatásnál ezt a konfig file-t is megadjuk. Pl.

esxtop  -b  -n infinity -c ./alap1 > /vmfs/volumes/57fe4a2e-21a0072a-c0dc-e41f132e8b64/CD_IMAGES/55_alap1.csv

A fenti parancs az alap1 nevű konfig file-t használja, és addig fut, amíg manuálisan le nem állítjuk. A nagy méretű keletkező file miatt érdemes egy datastore-ra irányítani az output-ot.

Ha a fenti módon előálltak az adatok (akár több hostról is), akkor indítsuk el az NMON Visualizer-t, és töltsük be a .csv file-t, vagy file-okat (mivel akár többet is tud kezelni egy időben)


Ezután egy kevés időt eltöltve fel lehet fedezni, mit is tud ez az alkalmazás. De azért röviden a legfontosabbak:

A baloldalon a fában le tudunk menni az egyes értékekig, de a legalsó "csomópontra" kattintva egyszerre megjeleníti az alatta lévő értékeket. Pl.


Képes .png formátumban lementeni az aktuális képet, illetve a képet alkotó adatsorokat is kinyerhetjük.

Automatikusan meghatározza az adatpontok sűrűségét (mérések száma alapján), de fixen meg is adhatjuk (View/Set Granurality...)

A teljes mérési intervallumot felszabdalhatjuk kisebb időszakokra, így azokat külön is meg tudjuk nézni. Sőt, ezek az intervallumokat le tudjuk menteni, így később egyszerűen betölthető, nem kell újra létrehozni. Pl.



Akár táblázatos formában is megjeleníthetjük az adatokat.


És persze a diagram megjelenítési módját is szabályozhatjuk.

Összefoglalva, egy telepítést sem igénylő pár megabyte-os alkalmazásról van szó, amivel egyszerűen megjeleníthetjük az esxtop eredményét.





2017. január 12., csütörtök

vmware tools 10.1 és 10.0.12

2015 őszétől kezdve a VMware külön letölthetővé tette a VMware Tools-t. Ezáltal az ESXi verziók és a VMware Tools verziók külön életet kezdtek el élni. Azaz anélkül, hogy ESXi patch jönne ki, ha szükséges, új VMware Tools csomagok jelenhetnek. Ennek persze van előnye , de van hátránya is. Hátrány pl. az, hogy ezentúl hiába tartjuk az ESXi-t a legfrissebb állapotban, egyáltalán nem biztos, hogy a róla elérhető Tools is a legújabb. Sőt, inkább az a biztos, hogy nem.

A másik változás, hogy különválasztotta a mostani operációs rendszerekhez és a régi, már nem támogatott operációs rendszerekhez tartozó Tools verziókat a VMware. Ez elég friss dolog, októberben vált elérhetővé ez a fajta konstrukció. Ennek megint csak lehet értelme, de a számozást egy kicsit átgondolhatták volna. Az lenne a logikus, hogy pl. a 10.0.6-nak a 10.0.12 a frissítése lenne. Pedig nem. Pontosabban régi operációs rendszerek esetében igen, újak esetében nem. A 10.0.12 annak a Tools-nak a verziója, amit a régi operációs rendszerekhez használhatunk. A 10.1 viszont frissíti a 10.0.6-ot újabb rendszerek esetében. . Lehet, hogy csak nekem tűnik zavarosnak? Persze meg lehet magyarázni. A 10.0.x a továbbiakban mindig a régi rendszerekhez lesz használható (bár itt nagy fejlesztésekre nyilván nem kell gondolni), A 10.1.x  pedig az aktuális operációs rendszerekre lesz telepíthető.

A harmadik változás, hogy most már külön Release Notes készül mindkét féle kiadáshoz. Ha máshonnan nem, onnan lehet tudni, hogy mihez mi való. Release Notes 10.0.12 és Release Notes 10.1.0. Az előző bekezdésben emlegetett régebbi és új operációs rendszerek fogalma is értelmet nyer, ha elolvassuk a két dokumentumot.

A fentiek miatt borul a szokásos Tools telepítés is.  Mivel alapállapotban a Tools aktuális verzióját az ESXi-n lévő productLocker linken lévő verzióhoz hasonlítja a rendszer. Természetesen megtehetjük, hogy minden ESXi szerveren a megfelelő helyre felmásoljuk a letöltött és kicsomagolt Tools-t, de ez sok host esetében igen macerás lenne, és minden egyes újabb verzió esetében újra végig kellene csinálni.

E helyett a következő módon járhatunk el.

  • Hozzunk létre egy minden host által látható datastore-on egy mappa struktúrát. (ha követni akarjuk az eddigi felállást, akkor packages/6.0.0
  • Ebbe másoljuk bele a kicsomagolt Tools-t (floppies és vmtools almappák)
  • A vsphere kliensben minden hoston módosítsuk a UserVars.ProductLockerLocation beállítást úgy, hogy az új, közös elérésű helyre mutasson
  • SSH-ne belépve a hostokra a productLocker linket szintén változtassuk meg úgy, hogy az új helyre mutasson. (vagy egy host restart is megteszi)

Persze ha fentieket 100 hoston kell megcsinálni, akkor megint csak nem egyszerű a feladat. Viszont erre találták ki a PowerCLI-t :)

Szokásomhoz híven nem egy szépen kidolgozott scriptet mutatok, hanem csak egyszerűen azt, hogy mit kell tartalmaznia ahhoz, hogy a fenti beállításokat számunka megcsinálja.

$command="c:\powershell\pL.txt" #pL.txt tartalmazza a hoston futattandó parancsokat
$user = "root"
$pw="tikosjelszo"

$host1=get-vmhost host1

$remoteserver=$user+"@"+$host1.Name

get-advancedsetting -Entity $host1 -Name "UserVars.ProductLockerLocation"|set-advancedsetting -Value "/vmfs/volumes/57fe4a2e-21a0072a-c0dc-e41f132e8b64/packages/6.0.0" -Confirm:$false #megváltoztatjuk, hogy az új helyre mutasson

$host1|get-vmhostservice| Where { $_.Key -eq "TSM-SSH"}|start-vmhostservice #engedélyezzük az SSH-t


write-output "yes"|c:\powershell\plink.exe -ssh $remoteserver -pw $pw -m $command #lefuttajuk a pL.txt-ben lévő parancsokat. 

A pL.txt-ben a következő két parancs van:

rm /productLocker
ln -s /vmfs/volumes/57fe4a2e-21a0072a-c0dc-e41f132e8b64/packages/6.0.0 /productLocker

Azaz töröljük a meglévő linket, majd újra létrehozzuk úgy, hogy a megosztott helyre mutasson. Mindezt pedig a plink.exe parancssori alkalmazással használatával érjük el.

Ha a fenti script köré írunk valamilyen ciklust, ami végigmegy a hostokon, akkor már készen is vagyunk.

Ha ezek után megnézzük a virtuális gépeink állapotát, akkor semmilyen változást nem fogunk észrevenni, mivel az ellenőrzés akkor történik meg, amikor bekapcsolunk egy gépet, vMotion-nel elmozgatunk egy gépet, vagy pedig a gépen belül a vmtools szervizt újraindítjuk. Ekkor már az adott gép esetében csak akkor fogjuk azt látni, hogy a legfrissebb tools van rajta, ha valóban az van rajta, ami a közös elérésű datastore-on van. (Ez egyébként a 10.1-es esetében a 10272-őt jelenti)

És persze ezek után már a szokásos módokon mehet a vmwere tools frissítés (kliensből, PowerCLI segítségével, stb)

Remélem segítettem a fentiekkel!

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.