VMware Certified Advanced Professional 6 – Data Center Virtualization Deployment

Bár már hónapok óta a vCenter 6.5 és ESXi 6.5 a legújabb verziók, de még a tárgyban szereplő vizsgából a mai napig nincs 6.5-ös verzió. Igaz, hogy az áttérés sem történt még meg (csak a teszt rendszerben). Így mivel lehetőségem volt viszonylag kedvezményes áron (amit kivételesen nem is nekem kellett fizetnem) egy tanfolyamhoz csomagoltan megkapni a vizsgakupont, így belevágtam. Mivel a kedvezményes ajánlat az ArrowECS-től jött, így egyértelmű volt számomra, hogy a vizsgát is ott teszem le.

Néhány dolog a vizsgával kapcsolatban:

• 27 feladat, amit egy elő környezetben kell megoldani
• HOL szerű környezet, amiben a billentyűkezelésre vonatkozóan van néhány megszorítás, de nem annyira fájdalmas, mint amilyennek elsőre tűnt
• Bő 3 óra, beleszámítva már a pluszba kapott 15 percet is
• A feladatok kb. fele simán megoldható a napi adminisztráció során felszedett ismeretek alapján
• Az 5-ös vizsgához képest gyorsabb környezet, de még mindig lassú, így akár "segíthet" abban, hogy ne sikerüljön a vizsga
• Néhány esetben egy kicsit "trükkös" a feladat. Konkrét feladatot nem írhatok ide le, de pl. olyanra gondoljatok, hogy a leírás szerint meg kell határozni, hogy ki hajtott végre egy konkrét művelet a környezetben, és ha már rájöttünk hogy melyik log-ban kell nézni, akkor kiderül, hogy több felhasználó is kiadta a kérdéses parancsot, vagy ahhoz hasonlót. 
• A legfőbb nehézséget az adja, hogy általában egy bizonyos technológiával dolgozunk napi szinten, viszont a vizsgán a többi is jelen van. Pl. én SAN-t használok, de ettől az iSCSI vagy NAS kezeléssel is tisztában kell lenni
• Ha valaki ódzkodik a scriptektől, de ezt a vizsgát le szeretné tenni, érdemes mégis nekiesnie, mert biztosan jelent jó pár pontot a végső elszámolásnál
• Kiértékelés is scripttel történhet, mert a vizsga után egy órán belül meg is küldik az eredményt. Az ötös vizsgánál erre még kellett két hét, mivel ott valaki ténylegesen átnézte mit is csináltam, és az alapján értékelt. Ennek viszont szerintem van egy nagyon pozitív következménye. Nevezetesen a feladatokat nagyon pontosan kell megfogalmazni, ha azt szeretnék, hogy az eredmény scripttel ellenőrizhető legyen. Pl. az kevés, hogy hozz létre mondjuk egy vDS-t, ettől konkrétabbnak kell lenniük. És minél konkrétabbak, nekünk annál könnyebb dolgunk van.

És végül az eredmény :) Acclaim Badge

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 :)

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!!

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ó

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.

vSphere 5.5

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

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

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

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

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

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

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

Kb. ennyit tudtam kihámozni.

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

 

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

 

Introduction to VMware vSphere Virtual SAN

Introduction to vSphere Flash Read Cache aka vFlash

 

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

VMDK műveletek

Mivel viszonylag még nem túl régen foglalkozok VMware szerver virtualizációval, így biztosan ezért nem találkoztam eddig trükkösebb igényekkel a virtuális gépek diszkjeivel kapcsolatban. Általában a kérések kimerülnek abban, hogy adjak még egy diszket a géphez, vagy növeljem meg valamelyik méretét. Ez utóbbi persze egy Windows 2003-as szerver rendszer partíciója esetében már nem is annyira triviális. Mármint az nem, hogy a Windows-ban a kapott plusz méretet hozzá kell adni a C: particíóhoz. Ez a művelet a többi kötet esetében nem okoz gondot, mert a diskpart segítségével könnyen megcsinálhatjuk. De a diskpart nem használható a rendszerlemez növelésére.
Ehhez szerencsére van egy kis program, amit még a Dell készített, és azt használva a gép kikapcsolása nélkül, futtában képesek vagyunk megnövelni egy 2003 szerver esetében is a C: meghajtót. Aki még esetleg nem ismeri, a Dell honlapjáról letöltheti. Már csak a nevét nem mondtam: az ExtPart.exe-ről van szó.

De ez csak egy kis kitérő volt, nem is erről akartam írni. Hanem arról, hogy kaptam pár nap eltéréssel két feladatot, amit a szokásos eszközeimmel nem tudtam volna megcsinálni.
Az első esetben egy olyan gépről volt szó, amely fizikai szerver virtualizálásával készült. A gépben eredetileg egy darab diszk volt, és két partícióra volt felosztva. 10+40GB. Aki virtualizálta a szervert elfelejtette két külön .VMDK file-ba tenni a két partíciót. Most viszont meg kellett növelni a C: méretét, miközben a D: is tele volt már.
A második esetben pedig az a ritka eset állt elő, amikor valaki azt kérte, hogy vegyük vissza a lemezek méretét. Ez azért történhetett, mert a virtuális gép egy másik klónozásával jött létre, és az eredeti gép esetében szükséges volt a 90GB méret, a klón esetében viszont 30 is elég volt.

Ehhez kellett keresnem valamilyen eszközt. Azt már láttam, hogy van a környezetünkben egy régi GParted (Gnome Partition Editor) nevű .ISO file, így megkerestem annak legújabb kiadását, amit itt meg is találtam.

Egy teszt gép segítségével megnéztem mit tud, hogyan kell használni, stb. Mikor úgy gondoltam, hogy már élesben is tudom használni, nekikezdtem.
A két gép esetében eléggé hasonló dolgokat kellett csinálni. A virtualizált szerver esetében a következő lépéseket hajtottam végre.

• mentés a gépről
• egy 15 és egy 40GB-os új diszk hozzáadása
• ezeket még a kikapcsolás előtt inicializáltam a Windowson belül
• gép kikapcsolás
• a GParted CD hozzárendelése a virtuális géphez, majd boot
• az eredeti lemezről a 10GB-os partíció átmozgatása a 15GB-os új lemezre
• az eredeti lemezről a 40GB-os partíció átmozgatása a 40GB-os új lemezre
• a 10GB-os partíció kihúzása a teljes 15GB-os méretre
• az így keletkezett 15GB-os partíció megjelölése, mint boot partíció
• a .vmx file módosítása úgy, hogy az scsi:0:0 az új 15GB-os partícióra mutasson
• miután a CD-t disconnect állapotba tettük, jöhet a bekapcsolás
• a Windows lefuttatja a chkdsk-t, mielőtt elindul
• nekem még az indulás után is kért egy újraindítást. Ennek okát pontosan nem tudom (valaki?)
• a lemez kezelőben ellenőrizni kell, hogy a többi prtíció rendben látszik-e. Ha kell, akkor a megfelelő meghajtó nevet hozzá kell rendelni
• végül a feleslegessé vált eredeti 50GB-os lemez törlése. Itt egy kicsit zavaró lehet, ha csak a virtuális gép tulajdonságaira hagyatkozunk. Nem biztos, hogy mindent jól mutat. Érdemes megnézni a datastore-on is, hogy melyik méretű .VMDK file-nak mi a neve.
• végül egy storage vMotion, hogy az előbbi bizonytalanságot megszüntessük.

A másik gép esetében is hasonlóan jártam el, csak ott mielőtt az új diszkre pakoltam volna a partíciót, előtte át kellett méretezni, hogy elférjen a kisebb lemezen is.

Ha van ettől egyszerűbb módszer a tarsolyotokban, szívesen venném ha megosztanátok velem.

HUTUG 2013.03.08 előadás

A közelmúltban megkerestek, hogy a következő Hungarian Tivoli User Group (HUTUG) rendezvényen tartsak előadást a VMware mentéséről TSM alkalmazásával. Mivel ez pont az a téma, ami munkámból kifolyólag is napi szinten előkerül, ezért szívesen vállaltam. Az előadásra készült prezentációt letölthetitek innen: VMware mentése TSM használatával.

vSphere Data Protection 5.1 - Restore

Miután a telepítés és a mentések beállítása megtörtént, nézzük meg, hogyan lehet mentett gépet visszaállítani.


Eltelt kb. 10 nap, azóta a mentések rendben megtörténnek minden este, így van miből válogatni a visszaállítás során. Mint majd láthatjátok, itt is az egyszerűségre törekedtek, ami persze nem is baj egy ilyen termék esetében.
Két teljesen különböző visszaállítási lehetőséget kínál a VDP. Az első a teljes gép, a másik pedig az FLR, azaz a file level restore. Előbb nézzük meg az elsőt.

A szokásos struktúrában láthatjuk az eddigi mentéseinket. Innen kiindulva tetszőleges mentett gép, bármely mentéséből visszaállhatunk. A Restore linkre kattintva megadhatjuk a visszaállítás paramétereit.

 

Ugyan ide jutunk, ha pl. a Web kliensben bárhol az egér jobb gombjával rákattintunk a gép nevére.

 

 

Ha az előző képernyőn tovább lépünk, akkor beállíthatjuk, hogy

a mentett gépet akarjuk-e felülírni, vagy pedig egy új gépet akarunk létrehozni a mentésből.

 

 

Már csak egy összefoglaló ablak van hátra, és indulhat is a mentés. A folyamat előrehaladását a taskok között tudjuk nyomon követni.

 

 

Tulajdonképpen ennyi volt a teljes gép visszaállítás. Valóban egyszerű, nem lehet elveszni a beállítások között:)

 

Akkor most nézzük meg, hogy működik az FLR. Használatának van néhány feltétele (operációs rendszerre és file rendszerre vonatkozóan is), de a legfontosabb, hogy csak olyan virtuális gépen kezdeményezhetjük a file level restore-t, amelyiket ezzel a rendszerrel mentettünk, és van rajta VMware tools. Ez akkor is igaz, ha egy másik gép mentéséből van szükségünk néhány file-ra. Így  hiába is próbálunk kapcsolódni a VDP alkalmazáshoz pl. egy notebookról, nem fog sikerülni.

 

Lépjünk be egy előzőleg már mentett gépre, és a böngészőbe írjuk be, hogy: https://vdp_ip_address:8543/flr

 

 

A szokásos kék bejelentkező képernyőt kapjuk. Attól függően, hogy az aktuális gép mentéséből vagy egy másik gép mentéséből szeretnénk visszaszerezni file-okat, basic vagy advanced login módban mehetünk tovább. Egyelőre maradjunk a basic módban, ahogy a fenti képen is látható. Itt helyi adminisztrátori névvel és jelszóval tudunk tovább lépni.

 

 

Sikeres kapcsolódás után ki kell választani, hogy melyik napi mentésre van szükségünk, majd Mount gomb megnyomásával fel tudjuk csatolni a .vmdk file-okat (akár több mentésből is). Majd Close.

 

 

Össze kell kattintatni a szükséges állományokat, majd a Restore Selected Files gomb megnyomása után már csak annyi dolgunk van, hogy megadjuk a visszatöltés helyét, és indulhat is a visszaállítás.

 

 

 

Ezután nézzük meg, hogy lehet másik gép mentéséből file-okat visszaállítani. Említettem az elején, hogy létezik Basic és Advanced login. Az utóbbi abban tér el a basic logintól, hogy egy lokális admin account mellett egy vCenter szerver admin jogú accountot is meg kell adni.

 

 

Ha sikeresen bejelentkeztünk, akkor tulajdonképpen minden ugyanúgy történik, mint a basic login esetén, azzal a különbséggel, hogy az összes gép összes mentéséből válogathatunk, mint ahogy a lenti képeken is látható. Előbb egyesével mountoljunk fel akár több mentést is, majd zárjuk be a Manage mounted backups ablakot.

 

 

Majd pedig, mint az előbb, ki kell választani a visszaállítandó állományokat,

 

 

 

Ha sok file-t akarunk visszaállítani, akkor az hosszabb ideig is eltarthat. A visszatöltés folyamatát a Monitor restores fülön tudjuk követni.

 

 

Ezzel nagyjából végigértem a visszatöltés lehetséges változatain. Természetesen van még néhány egyéb funkciója is a VDP-nek, de talán ennyi elég ahhoz, hogy mindenki eldöntse, ad-e egy esélyt ennek az alkalmazásnak. Nekem jobban tetszik mint a VDR, de igazi tapasztalatokat majd az éles használat során tudok majd szerezni.

Ha valaki már használja, és ki tudja egészíteni az itt és az előző két postban leírtakat, kérem tegye meg. Ezzel is segítve a felhasználói közösséget.

 

NEE projekt (Hands on Lab Online)

Valamikor szeptemberben ebben a posztban írtam arról, hogy a VMWorld 2012 Hands on Lab környezetét egy kicsit átalakítják, és mint online szolgáltatás, tovább él majd. Akkoriban fel lehetett iratkozni egy várólistára, és az volt az ígéret, hogy ha a környezet kipróbálható állapotú lesz, akkor majd jelentkeznek. Nos ez történt meg a napokban. A projektnek a szépen csengő NextGen Education Environment (NEE) nevet adták.

Aki feliratkozott, annak mostanság levelet kell kapnia a admin@projectnee.com e-mail címről. Már akinek nem nyeli el a spam szűrő.

Az alkalmazás csak Firefox, Chrome és Safari böngészők újabb változataival használható, az Internet Explorer nem támogatott. Ha sikeresen beléptünk, akkor a következő felület fogad minket.

Egyelőre viszonylag kevés labor érhető el, de állítólag folyamatosan fogják bővíteni a kínálatot. A használata egyszerű, bár sok mindent kell néha megjeleníteni a képernyőn, ami egy normál méretű monitor esetén zavaró lehet. A  részletekbe nem szeretnék belemenni, mindenkinek érdemes kipróbálnia. Még annyi, hogy a fejlesztők szerint is történhetnek furcsa dolgok a használat során, de folyamatosan tökéletesítik az oldalt. Egy labor elindítása után kb. ilyesmire számítsatok:

További információt találhattok a következő oldalakon:

Online közösség: http://vmware.com/go/hol
Blog: http://blogs.vmware.com/hol

vSphere Data Protection 5.1 - Backup

Az első részben a VDP telepítéséről és konfigurációjáról volt szó. A végére eljutottam odáig, hogy a VDR konfigurációs oldalára bejelentkezve minden szolgáltatás működőképesnek tűnt. Nézzük meg, hogy a Web kliens oldalon milyen változás látható a sikeres telepítés után.

 

A kliens baloldali sávjába beköltözött a VDR, azaz a vCenter regisztráció is sikeres volt. Miután elindítottam, egy kicsit meglepődtem az induló képernyőn. Úgy tűnik, hogy a fejlesztés (vagy éppen a lebutítás) egyik célja az volt, hogy kinézetre pontosan visszaadják a VDR-t. Nekem ez  nem tűnt jó ötletnek, hiszen mégsem egy nagyon sikeres terméket cserélt le a VMWare, de talán az vezérelte a fejlesztőket, hogy a VDR-rel megszerzett ismereteket minél könnyebben fel lehessen itt is használni. Aki tudja, hasonlítsa össze a két felületet:)

 Ugyanaz az ábra, ugyanazok a menük, a Basic Tasks terület is változatlan. Egyedül a legfelső sorban látható, hogy itt más termékről van szó.
Mivel most a mentésről lesz szó, vágjunk is bele. Válasszuk a Backup fület, majd a Create New Backup Job link segítségével készítsük el az első jobot. A vSphere Web kliensben megszokott felületű varázsló indul el, amiben néhány lépésen keresztül könnyedén összekattinthatjuk a a kívánt tartalmú mentési feladatot. Előbb a mentendő gépeket kell megadnunk. Itt nem csak egyesével, hanem a gépeket tartalmazó többféle konténer kiválasztásával egyszerre többet is megadhatunk. Olyan apróságokra viszont ügyelni kell, hogy ha pl. egy cluster-t választunk ki, majd később az egyik gépet elmozgatjuk egy másik cluster.be, akkor a gép kikerül a mentések közül.

 

Bár a gépek között ott van maga a VDR is, azt nem lehet ilyen módon menteni. A következő lépésben a mentési gyakoriságot állíthatjuk be.

 

 

Az összes lehetséges beállítási mód leolvasható a fenti képről. Ezután az ún. Retention policy, azaz a megőrzési idők beállítása következik. Itt is minden leolvasható a következő képről.

 

 

Négy féleképpen mondhatjuk meg, hogy a VDP hogyan őrizze meg a mentéseinket. Örökre, megadhatunk egy megőrzési hosszt, megadhatunk egy dátumot, amikor már törlődhetnek, illetve meghatározhatunk egy megőrzési rendszert. Ez a része már a VDR-nek is tetszett. Ezután már csak adnunk kell valami jó nevet, áttekinteni még egyszer a beállításainkat, és készen is vagyunk.

 

 

Kapunk egy figyelmeztetést, hogy a job létrehozása akár több percig is eltarthat. A szükséges idő az érintett virtuális gépek mennyiségével arányos. Ha nézzük közben a taskokat, akkor láthatjuk, hogy minden egyes gépen végez módosításokat a job mentése során.

 

 

Ha mindennel végzett, a job megjelenik a listában.

 

 

A Next Run Time oszlopban az látható, hogy 20:00. Miért pont akkor kezdődik? Erre a választ a Configuration fülön lévő Backup Window Configuration részben találhatjuk.

 

 

Látható, hogy a napot három részre tudjuk osztani. Ebből a zöld színű jelenti azt az időszakot, amikor a mentések futhatnak. Ennek pedig a kezdeti ideje a képen is leolvasható 20:00 óra. Az egyes területek jelentéséről majd egy későbbi posztban írok (talán). A lényeg, hogy itt tudjuk megváltoztatni a mentési ablakot.

Ha eljön az idő, a taskok között láthatjuk, hogy elindultak a mentések.

 

 

A mentés a szokásos módon, snapshot készítéssel történik. Ha mentés közben ránézünk egy virtuális gépre, akkor a következőt láthatjuk.

 

Ha végzet minden géppel, a Reports fülön némi információhoz juthatunk. Egy picit túlzónak tűnik a megnevezés, mert túl sok mindent nem tudunk innen kinyerni. Ez a rész visszalépésnek tűnik a VDR-hez képest.

 

 

Hol tudnánk legkönnyebben leellenőrizni, hogy a mentéseink eredménye rendelkezésre áll-e? Természetesen a Restore fülön.

 

Már néhány mentési megoldást volt szerencsém kipróbálni. Azt kell mondanom, hogy a VDP egyszerű, mint egy fa ék:) A sebesség is nagyon jónak tűnt, de nyílván ezt igazából egy nagyobb környezetben lehetne lemérni.

Összességében eddig tetszik. Egyszerű telepíteni, konfigurálni. A mentések során kevés lehetőség közül választhatunk, de nyílván ez is volt a cél. Azaz minél egyszerűbb legyen a használata. Viszont hiányolom a részletes riportolást, amiből láthatnám pl. a sebességet.

Ahogy mondani szokták, a backup akkor ér valamit, ha vissza is tudunk a mentésből állítani. Ennek szeretnék majd a végére járni a következő részben.