2016. március 29., kedd

vSphere HTML5 Web Client

Ha egy kicsit zavarosan akarok fogalmazni, akkor a húsvéti nyuszi meghozta az első fecskét :)

A lényeg, hogy fling formájában megérkezett az első HTML5 és Javascript alapú vSphere Web Client. A fejlesztők célja nem az volt, hogy egyből egy teljes körű klienst készítsenek, hanem mihamarabb bemutassanak egy működő, de még erősen korlátos képességű verziót. Nem nagyon tudtam neki elleneállni, hogy ezzel kezdjem a napot :)

Mivel én Windows alapú vCenter szervert használok, így az ide vonatkozó konfigurációs lépéseket mutatom be.

  • Töltsük le innen a server-configure.bat file illetve a h5ngcVA-1.0.0.0-3680819_OVF10.ova file-okat
  • Másoljuk be a vCenter szerver egy tetszőleges mappájába a server-configure.bat file-t
  • Admin módban indítsuk el, és ha minden ok, akkor a vCenter szerver aktuális konfigja alapján készít három file-t: ds.properties, stroke.js, webclient.properties
  • Az .OVA file alapján hozzuk létre a Web Client appliance-t (sima next-next)
  • Kapcsoljuk be, majd SSH-val lépjünk be rá.
  • Hozzuk létre a  következő három mappát: /etc/vmware/vsphere-client/,/etc/vmware/vsphere-client/config/, /etc/vmware/vsphere-client/vsphere-client/
  • Sorrenben a fenti három folderbe másoljuk be a stroke.js, ds.properties ill. a webclient.properties file-okat
  • Tanácsos beállítani ntp szervert, hogy az időszinkron redben legyen: /etc/init.d/vsphere-client ntp_servers ntp1,ntp2,..
  • És start :/etc/init.d/vsphere-client start (ez nálam kb. 90 másodpercig tartott, szóval türelem...)

Nincs más hátra, mint megnézni mit is kaptunk :)

https://appliance_ip_címe:9443/ui

Home képernyő

Viszonylag kevés dolog működik még, de azért éremes megnézni. A leírás alapján ezeket tudja:

  • alap vm power opciók
  • megváltoztathatunk néhány virtuális gép paramétert
  • van konzol
  • van host és vm summary 
  • hostok közti vmotion (storage vMotion nincs)
  • vm létrehozás (még nem tud minden opciót)
  • monitoring (korlátozottan, pl. real time adatok nincsenek)
Néhány screenshot a kliensből:


vm szerkesztés

Performancia chart


vmotion

A kliens legnagyobb előnye egyelőre az, hogy van:) Látszik hogy elkezdődött valami, és várhatóan sűrűn jönnek majd a kisebb-nagyobb fejlesztések.



2016. március 16., szerda

vSphere Single Host Management - VMware Host Client

Ezt is megértük: A rövid időn belül 5 (pontosabban már 6) verziót megélt ESXi Embedded Host Client fling most már hivatalosan is az ESXi része. Konkrétan az ESXi 6.0 U2 része lett, ami tegnap jelent meg. Kapott egy szép új nevet is, illetve csak elhagyták az "Embedded" részt, így lett belőle ESXi Host Client.

A használatáról itt és itt találtok részletes és nagyon hasznos magyar nyelvű leírást.

A kliens továbbra is letölthető a szokásos helyről is, főleg hogy várhatóan sokkal gyakrabban lesz belőle új verzió, mint az ESXi-ből.

Most már tartozik hozzá hivatalos dokumentáció, és elolvasható a Release notes is.

Aki még nem próbálta, most már tényleg ne várjon tovább!!

2016. február 5., péntek

vExpert 2016

Álmodtam egy nagyot, és november elején jelentkeztem a programba. A VMware ma jelentette be, hogy kiket választottak, és nagy örömömre felfedeztem magam a listában.

Mivel ez az első évem, így nem pontosan tudom ennek előnyeit, de nagyon örülök neki és köszönöm hogy beválasztottak.

Remélem a munkahelyemen is értékelik majd :)

A teljes list itt található: http://blogs.vmware.com/vmtn/2016/02/vexpert-2016-award-announcement.html

2016. január 28., csütörtök

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.




2016. január 22., péntek

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.

2016. január 19., kedd

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.

2016. január 15., péntek

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.