Egy kis PowerCLI - Get-VMHostHardware, avagy hogy határozzuk meg egy host sorozat számát

A feladat nem tűnik túlzottan bonyolultnak, Főleg ha van rá olyan PowerCLI parancs, ami egyből meg is adja  a kívánt sorozat számot.

A Get-VMHostHardware pontosan ezt csinálja.

Csakhogy ez a parancs először a PowerCLI 6.0R2-ben jelent meg 2015.szeptember 15-én, és erre előtte is szükség lett volna.

A működése egyszerű:

Nem csak a sorozatszámot, hanem egyéb fontos adatot is tartalmaz a fizikai szerverrel kapcsolatban.

Nézzük egy régebbi IBM host adatait.

A pirossal aláhúzott string határozottan nem sorozat számra emlékeztet. Ha a Web kliensben megnézzük a Hardware Status részt (ugye a hagyományos kliensben ez a 6-os vCentertől kezdve már sajnos nem elérhető), akkor láthatjuk, hogy honnan is jön ez az érték.

Biztosan megvan az oka, hogy miért van két sor az IBM szerver esetében, de még nem próbáltam megkeresni ezt az okot. Látható, hogy ott van a jó sorozatszám is, csak éppen nem azt választja a Get-VmHostHardware parancs.

De ha már szóba jött a téma, akkor nézzük meg, milyen más lehetőségünk van a PowerCLI segítségével meghatározni a serial numbert. (és persze más paramétereket is, de most konkrétan csak erről lesz szó).

Azt tudjuk, hogy az esxcli paranccsal ezt le tudjuk kérdezni.

Viszont esxcli parancsokat PowerCLI használatával is ki tudunk adni. Nézzük meg ugyanezt a szervert.

A PowerCLI azért is jobb, mert könnyen ki lehet nyerni az összes hostra vonatkoztatva is, csak egy kis ciklus kell hozzá

Van ettől egy bonyolultabb megoldás is, amikor a get-view használatával jutunk el a kívánt értékig.

Konkrétan nézzünk meg egy olyan szervert, amire a Get-VMHostHardware rossz értéket hozott ki

Látható, hogy ennek a szervnek a host mögötti .NET objektumban két darab ServiceTag mezője van, két különböző értékkel. A Get-VMHostHardware egyszerűen veszi az elsőt, és azt jeleníti meg. 

A végére még két megjegyzés

• A Get-VMHostHardware parancs mellett megjelent egy másik hardware közeli parancs is: Get-VMHost-PciDevice
• A fentiek mellett én azért a legszívesebben az RVTools-t használom, ha sok információt kell kigyűjtenem a környezetről. Valamikor nagyon régen már itt is volt róla szó.

Ha valamilyen más módot is ismertek, szívesen veszem ha megosztjátok, illetve ha a fentiekben hibát láttok, azt is jelezzétek.

Egy kis PowerCLI - VMware infrastruktúra KPI adatok lekérdezése

Lehet hogy túlzás KPI-nek nevezni, mi mindenesetre így hívjuk. A lényeg úgyis a tartalom. Arról van szó, hogy minden hónap elején kérnek tőlem bizonyos számszerűsíthető információt a VMware infrastruktúráról.

Mivel a mondás szerint ha már valamit kétszer meg kell csinálni, akkor arra írjunk scriptet, ezért én is így tettem.

Nem nagy dolgokról van szó, de ha valaki még esetleg most ismerkedik a PowerCLI használatával, akár még hasznos dolgot is találhat benne.

Az itt található kód egy kicsit egyszerűsített változata annak amit használok, mivel nálunk több datacenter van, és az adatokat megosztva kérik. A lenti viszont egyben kezeli a vCenteren lévő összes hostot, virtuális gépet valamint datastore-t. De a Location paraméter megadásával könnyen lehet szűkíteni a lekérdezéseket egy bizonyos csoportra.

Ha csak a Datacenter1-ben lévő dolgokkal akarunk foglalkozni, akkor egyszerűen ki kell bővíteni a parancsokat. Pl. 

$Host_ALL=Get-VMHost -Location DataCenter1|?{$_.ConnectionState -ne "Maintenance"}

Megjegyzések a scriptben, bár a nagy része nem szorul magyarázatra.

#Induló értékek meghatározása (dátum, hostok,virtuális gépek, datastore-ok)

#ha szükésges, akkor különböző szűréseket beállíthatunk, pl. csak bekapcsolt gépek,

#csak olyan datastore-ok, amikben nem szerepel az "internal" szó, stb

$Date=Get-Date

$Host_ALL=Get-VMHost |?{$_.ConnectionState -ne "Maintenance"}

$VM_ALL=get-vm |?{$_.Powerstate -eq "PoweredOn"}

$DS_ALL=get-datastore  |?{$_.Name -notlike "*internal*"}

#Host mennyiségi értékek számítása (összes mamória, CPU-k száma, és a hostok száma)

$Host_Mem_osszes_ALL=($Host_ALL|Measure-Object -Property MemoryTotalGB -sum).Sum

$Host_CPU_osszes_ALL=($Host_ALL|Measure-Object -Property NumCPU -sum).Sum

$Host_darab_ALL=($Host_ALL|measure-object).Count

#Datastore szabad és full kapacitások számítása

$DS_Free_Space_ALL=($DS_ALL|Measure-Object -Property FreespaceGB -sum).Sum

$DS_Full_Space_ALL=($DS_ALL|Measure-Object -Property CapacityGB -sum).Sum

#VM mennyiségi adatok (összes vCPU,számosság, abból mennyi a Windows és nem Windows gép)

$VM_CPU_ALL=($VM_ALL|Measure-Object -Property NumCPU -sum).sum

$VM_COUNT_ALL=($VM_ALL|Measure-Object).Count

$VM_COUNT_Windows_ALL=($VM_ALL|?{$_.GuestId -like "*win*"}|Measure-Object).Count

$VM_COUNT_NonWindows_ALL=($VM_ALL|?{$_.GuestId -notlike "*win*"}|Measure-Object).Count

#Provisioned Datastore számítás. Egy kicsit trükkös, mert ezt már csak az extensiondata #felhasználásával lehet lekérdezni, mivel a Get-DataStore ezt az értéket direktben nem
#tartalmazza

$ProvisionedSpace_ALL=(Get-Datastore | ?{$_.Name -notlike "*internal*"}|

Select-Object -Property Name,

CapacityGB,FreeSpaceGB,

@{ Name = "ProvisionedSpaceGB"

   Expression = {($_.ExtensionData.Summary.Capacity - $_.Extensiondata.Summary.FreeSpace + $_.ExtensionData.Summary.Uncommitted)/1GB}

 }|Measure-Object -Property ProvisionedSpaceGB -sum).sum

#Host memória és CPU szabad kapacitások számítása

#Nem bonyolítottam túl, egyszerűen az elmúlt egy hét értékeit lekértem, és abból az összes #hostra számoltam egy átlagot. Így utólag megnézve, lehetne egyszerűsíteni a következő pár
#sort (nem kéne számolgatni a hostokat, mivel tudom mennyi van...), de ez már így marad :)

$Host_ALL_CPU_Percent=0

$Host_ALL_MEM_Percent=0

$Host_Count=0

foreach ($h in $Host_ALL) {

  $HostCpuUsage = (get-stat -entity $h.Name -stat cpu.usagemhz.average -Start ($Date).adddays(-7) -Finish ($Date)|Measure-Object -Property Value -Average).Average

  $HostMemUsage = (get-stat -entity $h.Name -stat mem.consumed.average -Start ($Date).adddays(-7) -Finish ($Date)|Measure-Object -Property Value -Average).Average

  $HostallCPU=$h.CpuTotalMhz

  $HostallMem=$h.MemoryTotalMB

  $Host_ALL_CPU_Percent=$Host_ALL_CPU_Percent+(($HostCPUUsage/$HostallCPU)*100)

  $Host_ALL_MEM_Percent=$Host_ALL_MEM_Percent+((($HostMemUsage/1024)/$HostallMem)*100)

  $Host_Count=$Host_Count+1

  }

$Host_ALL_CPU_Percent=$Host_ALL_CPU_Percent/$Host_Count

$Host_ALL_MEM_Percent=$Host_ALL_MEM_Percent/$Host_Count

#Már csak az értékek kiíratása van hátra

Write-Host "összes CPU core" $Host_CPU_osszes_ALL

Write-Host "fizikia memória mérete" $Host_Mem_osszes_ALL

Write-Host "hostok szám" $Host_darab_ALL

Write-Host "provisioned tárhely" $ProvisionedSpace_ALL

Write-Host "szabad CPU kapacitás: " (100-$Host_ALL_CPU_Percent)

Write-Host "szabad datastore kapacitás" $DS_Free_Space_ALL

Write-Host "szabad Memória kapacitás: " (100-$Host_ALL_MEM_Percent)

Write-Host "teljes datastore kapacitás" $DS_Full_Space_ALL

Write-Host "vCPU szám" $VM_CPU_ALL

Write-Host "vCPU/core" ($VM_CPU_ALL/$Host_CPU_osszes_ALL)

Write-Host "vCPU/VM" ($VM_CPU_ALL/$VM_COUNT_ALL)

Write-Host "virtuális gépek száma" $VM_COUNT_ALL

Write-Host "Virtuális gépek száma (nem Windows)" $VM_COUNT_NonWindows_ALL

Write-Host "Virtuális gépek száma (Windows)" $VM_COUNT_Windows_ALL

A lista sok minden mással kiegészíthető, de pillanatnyilag nekem ennyi információra van szükségem.

TPS (Transparent Page Sharing) változások II.

Az előző bejegyzésben arról volt szó, hogy miért változtatták meg a TPS eddigi jól bevált működését. Azt mindenkinek magának kell eldöntenie, hogy alkalmazkodik az új alapértelmezéshez, vagy azt felülírva visszatér a szokásos beállításokhoz.

Az elején fontos megjegyezni, hogy ami ebben a leírásban van, a mostani állapotot tükrözik. De a bevezetése tulajdonképpen két fontos lépésben történt:

• A bejelentés utáni első nagyobb javítások már tartalmazták a két advanced paramétert, de még nem változtatták meg a TPS működését, illetve a Mem.ShareForceSalting értéke csak 0 vagy 1 lehetett
• A végleges verzióban már alapértelmezett lett a TPS megváltozott működése, és a Mem.ShareForceSalting értéke a 0 vagy 1 mellett 2 is lehet. Illetve nem csak lehet, hanem ez a default érték.

Akkor nézzük meg, hogyan is működik a "salting".

• Bevezettek egy új host konfigurációs paramétert, a Mem.ShareForceSalting-ot. Ezzel szabhatjuk meg, hogy egy adott host hogyan kezelje az inter-vm (virtuális gépek közötti) TPS-t. Ha az értéke nulla, akkor minden marad a régiben, ha pedig 1 vagy 2, akkor megváltozik a működés.
• A megváltozott működés azt jelenti, hogy most már az kevés, ha két vagy több virtuális gépnek van azonos memória lapja, ahhoz hogy a TPS ezeket egy fizikai lapon tárolja, ahhoz az kell, hogy a virtuális gépeknek azonos legyen a "salt" értéke is. 
• Ehhez bevezettek egy új vm szintű paraméter, aminek a neve sched.mem.pshare.salt, és értéke egy tetszőleges string lehet. 
• Ezzel a paraméterrel meghatározhatunk virtuális gép csoportokat, amik között a TPS mégis működhet annak ellenére, hogy a Mem.ShareForceSalting értéke 1 vagy 2. Ehhez csak annyit kell tennünk, hogy ezt a paramétert a csoport minden tagján azonos értékre állítjuk be. Ennek értelme az, hogy bár alkalmazzuk az új biztonságosabb TPS beállításokat, de ha akarunk, tehetünk kivételeket. (pl. security szempontból kevésbé érzékeny gépek esetében)
• Ha a sched.mem.pshare.salt paraméter hiányzik, de a "salting" be van kapcsolva, akkor a "salt" vagy a vc,uuid, gépenként egyedi paraméter vagy a nulla érték lesz. Ez attól függ, hogy a Mem.ShareForceSalting 2 vagy 1. 
• Bármilyen beállítások is vannak, az intra-vm TPS működni fog, azaz egy gépen belül képes lesz a rendszer az azonos memória lapokat összevonni.

A fentiek ismeretében nézzük meg, hogy milyen különböző esetek lehetségesek.

Mem.ShareForceSalting=0
A TPS hagyományos módon működik, azaz  ha van is a virtuális géphez beállított sched.mem.pshare.salt érték, azt nem veszi figyelembe.

Mem.ShareForceSalting=1
A "salting" be van kapcsolva. Ha létezik a sched.mem.pshare.salt paraméter, akkor azt fogja használni (azaz azonos értékkel bíró gépeknél lesz inter-vm TPS), ha viszont nincs, akkor a "salt" értéke nulla lesz, azaz szintén működni fog a TPS

Mem.ShareForceSalting=2
Ez az alapértelmezett. A "salting" be van kapcsolva. Ha nem létezik a sched.mem.pshare.salt paraméter (ez a default), akkor a .vmx-ben lévő vc.uuid értéke lesz a "salt". Mivel ez gépenként egyedi érték, ez gyakorlatilag azt jelenti, hogy az inter-vm TPS nem működik. Ha a paraméter létezik, akkor viszont azt fogja használni, így azonos "salt" érték esetében lesz inter-vm TPS. Itt elméletileg előfordulhat az is, hogy sem a sched.mem.pshare.salt, sem a vc.uuid nem létezik. Ilyen esetben a host véletlen számokat használ, így szintén nem lesz inter-vm TPS.

Végül nézzük meg egy frissen telepített ESXi 6.0U1 esetében mit is látunk:

Mem.ShareForceSalting default értéke

Nincs sched.mem.pshare.salt paraméter, ez a default

A "salt" értéke default esetben

A jó megoldásnak az tűnik, ha ellenőrizzük egy esetleges host upgrade előtt, hogy általában a TPS mekkora memória megtakarítást jelent, van e balloon használat, memória tömörítés esetleg swap használat, mert ha igen, akkor az upgrade után egészen biztos, hogy még tovább fog romlani a helyzet.

Ha valami nem tiszta vagy szerintetek nem így van, kérem jelezzétek.

Update: Megtaláltam azt a cikket, ami leírja, miért is jelent a TPS kockázatot: Ez lenne az.

TPS (Transparent Page Sharing) változások I.

Mivel nem mai történet (2014 októberében lehetett róla először olvasni), ezért már biztosan mindenki tudja, hogy az új ESXi kiadásokban (nemcsak a hatosban) a virtuális gépek közötti TPS alapból letiltásra került. Ez annak fényében fura lépés, hogy a VMware memóriakezelésének egyik kulcsa volt a TPS. Ha összehasonlítottuk más virtualizációs megoldásokkal, akkor ez a képesség mindig előjött, mint az egyik erős érv a VMware mellett.

Viszont speciális körülmények között sikerült olyan helyzetet előállítani, amikor a TPS biztonsági rést okozott. Régebben megtaláltam azt a tudományos cikket ami ezt leírja, de most képtelen vagyok fellelni. Az egy gépen belüli TPS érintetlen maradt. A VMware-nek is az a hivatalos álláspontja, hogy ezek a körülmények produktív környezetben nem igen reprodukálhatóak, de mivel a "biztonság mindenekelőtt", ezért mégis a TPS alapértelmezett tiltása mellett döntött. Ahogy ők mondják:

"This technique works only in a highly controlled system configured in a non-standard way that VMware believes would not be recreated in a production environment” and “believes information being disclosed in real world conditions is unrealistic” 

A nyilvánvaló kérdés az, hogy mit is kezdjünk ezzel a helyzettel. Mivel mi jelenleg csak cégen belül szolgáltatunk, ezért számomra egyértelmű, hogy új ESXi telepítés után, vagy a már érintett verzióra való upgrade után bekapcsolom a TPS-t. Bár az is igaz, hogy jelenleg nem feltétlenül jelent igazi előnyt a hostjaink nagy részénél, mivel beleférünk a fizikai memóriába (nincs túlfoglalás), és a mai modern architektúrákban nem a szokásos 4 KB-os memória lapokkal dolgozik az ESXi, hanem ún. "large memory page"-eket használ, aminek a mérete 2 MB. Ilyen méretű lapoknál eleve kisebb az esélye, hogy azonos tartalmú darabokat találjon, illetve sok CPU erőforrásba is kerülne az azonos lapok keresése, így ilyen lapoknál nem is használja az ESXi a TPS-t. Viszont nem tudhatom, hogy a terhelés a (közel)jövőben hogyan fog megváltozni, ezért inkább már most engedélyezem. (Főleg hogy host restart is kell a módosításkor)

Azt hiszem a TPS működését mindenki ismeri, de azért egy ábrát beszúrok ide, ami összefoglalja a lényeget.

Persze felmerül a kérdés, ha 2MB-os lapok vannak és ott a TPS nem működik, akkor mi is az értelme az egésznek. Azt tudjuk, hogy a balooning, a memória tömörítés kevésbé hatékony, nem is beszélve a swap használatáról.

Természetesen használja az ESXi a TPS-t, amennyiben elkezd fogyni a szabad memória mérete. Ehhez két fogalommal kell tisztában lenni.

Az egyik a MinFree. Régebben egyszerűen a teljes memória 6 százalékában határozták meg, de a mai, akár több TB memóriát tartalmazó szerverek esetében ez elég durva lenne. Ezért ezt már sávosan határozzák meg. Valaki vette a fáradságot, és WolframAlpha segítségével felrajzolta. Így egy táblázat helyett sokkal szemléletesebben is látható a MinFree értékének alakulása a teljes memória függvényében.

A másik fogalom a memory state. A 6.0 előtti időkben ebből négy volt, az ESXi 6-ban bevezettek egy ötödiket is. Egy adott host esetében az esxtop-ban a memória értékeknél lehet megnézni az aktuális értéket.

Az egészből csak annyi lényeg, hogy amikor a memory state eléri a MinFree értékének 400%-át, elkezdi szétbontani a 2 MB-os memória lapokat 4KB-os lapokká. Azokat viszont a TPS már tudja kezelni, így mielőtt vészesen lecsökkenne a szabad memória mérete, képes bizonyos nagyságú fizikai memóriát felszabadítani.
Ezekről az állapotokról ezen az oldalon vannak hasznos információk.

A következő cikkben azt fogom röviden leírni, hogy technikailag hogyan működik a "salting", azaz hogyan oldották meg a TPS tiltását vagy engedélyezését.

Hogyan győzzük meg a felhasználókat, hogy kevesebb vCPU is elég egy adott virtuális géphez?

Gondolom a fenti kérdést már más is feltette magának. Főleg olyanok, akik elég nagy számú virtuális gépet üzemeltetnek, és az igények ezer irányból érkeznek. Mindenki nagyon gyors gépet akar, és azt gondolják, hogy ezt sok-sok CPU fogja majd nekik garantálni (többek közt). Nyilván vannak esetek, amikor ez így is van, de azért a legtöbbször az igények túlzóak.

Mivel a vCenter szerveren gyűjtött performancia adatok csak igen rövid távra tárolódnak megfelelő részletességgel (bár ezen lehet változtatni, de cserébe igen nagy adatbázis kapunk), ezért hiába mutogatjuk a felhasználónak ez elmúlt egy hét vagy hónap alapján rajzolt diagramokat. Ha pl. csak két óránként van adat, akkor mondhatja hogy a látott mondjuk 30% úgy is kijöhetett, hogy voltak időszakok amikor a CPU 60-70%-on pörgött sok-sok percig, máskor meg csak 5-10%-on.

Ha rendelkezünk valamilyen komolyabb management megoldással (pl. vRealize Operation), akkor onnan könnyedén tudunk kimutatásokat készíteni a túlméretezett gépekről. De ha ilyenünk nincs, akkor kénytelen vagyunk mi megoldást találni arra, hogy meggyőzzük a felhasználót arról, hogy a kért 4-6 vCPU helyett akár kettő is elegendő lenne.

Már volt egy kétrészes bejegyzés ebben a blogban arról, hogy a vCenter szerver adatbázisát hogyan tudjuk "megcsapolni", azaz mielőtt túlzottan átlagolná az értékeket, hogyan tudjuk azt áttölteni egy másik adatbázisba. 1. rész, 2. rész

Az ott vázolt adatbázist kiegészítettem a virtuális gépek cpu, memória, hálózat, és diszk használatának 5 perces értékeivel, és ezeket az értékeket nagyjából negyven napig megőrzöm. A részletekbe itt nem mennék bele, a megvalósítás teljesen olyan, mint a fent említett két bejegyzésben szerepel.

Az adatokat jelenleg 40 napig őrzöm meg, így nagyjából 10-11 ezer értékem van minden egyes virtuális gépről. Ezt persze meg lehet jeleníteni a szokásos módon, mondjuk egy vonal diagramon, de ez ennyi pont esetében nem néz ki túl jól, bár a lényeg látszik róla.

Minden érték megjelenítése

De én szeretném azt is láttatni, hogy az egyes % értékek kb. hányszor fordultak elő a mért időintervallumban. Erre pedig a hisztogram kiváló lehetőség. Nem találtam az SQL Report Builderben olyan opciót, ami hisztogram szerűen ábrázolta volna az adatokat, pedig a leírásban utalnak rá. De ez nem gond, mert könnyű olyan SQL lekérdezést írni, ami ezeket az értékeket előállítja.

select count(*) as darab,round(stat_value,0) as szazalek from VIEW_VM_STAT_5MIN 
where vm=@VM and stat_name='cpu.usage' group by round(stat_value,0)

A fenti lekérdezésben a @VM az éppen kiválasztott virtuális gépet jelöli, a view_vm_stat_5min pedig azt a View-t takarja, amiben a virtuális gépek ötperces adatai vannak. A round függvény helyett lehet használni pl. a floor függvényt is, nagy eltérés nem lenne miatta.
Nézzük meg, hogy a fenti lekérdezést megjelenítve mit kapunk:

Hisztogram, lineáris 

Erre ránézve már kijelenthető, hogy a CPU használat nagyjából 2 és 20% között mozgott az elmúlt 40 napban. Viszont az ilyen megjelenítésnek lehet egy olyan hátránya, hogy ha igen nagy szórást mutatnak az értékek, akkor a nagy értékek miatt nehezen leolvashatóak a kicsik, mivel a tengely lineáris. Erre találták ki a logaritmikus ábrázolást. Nézzük, hogyan változik a fenti ábra:

Hisztogram, logaritmikus

Ez így már sokkal jobb :)

A fentiekkel azt szerettem volna megmutatni, hogy egy pici munkával ki lehet nyerni és meg lehet jeleníteni olyan adatokat is, amit a vSphere kliensben nem tudunk.

Végezetül nézzünk néhány példát különböző viselkedésű gépekre:

Itt aztán van minden, de azért a jellemző tartomány itt is 1-10%.

A következő gép étvágyát képtelenség volt kielégíteni. Szerencsére megszüntetés előtt áll :)

De nézzünk olyan gépet is, ami egész nap nem csinál semmit. Akkor meg minek tartjuk? :)

Végül egy olyan gép, aminek már régen szerettem volna csökkenteni a vCPU számát, de eddig nem volt olyan eszköz a kezemben, amivel feketén-fehéren (kéken..) megmutathattam volna, hogy amit kértek, az túlzás.

És végül Boldog Új Évet Kívánok az összes (5-10) olvasónak!!!