2012. november 6., kedd

TSM BA Client 6.3 Cluster Wizard

Mostanában kellett egy új Windows 2008-as MSCS cluster mentését beállítanom. Utoljára ilyet még a Windows 2003-as környezetben kellett elvégeznem, pontosan már nem is emlékszem, melyik TSM BA klienset használva. Így lelkiekben felkészültem arra, hogy a következő lépéseken kell majd átrágnom magam:
  • kliens telepítés a node-okra
  • cluster node (node-ok) regisztrálása a TSM szerveren
  • egy clusterezett diszken a TSM környezet létrehozása (dsm.opt)
  • scheduler service létrehozása a cluster paramétereinek és a TSM ajánlásoknak megfelelően
  • az így létrehozott scheduler service felvétele a cluster csoportba mint 'Generic Service'
  • Registry replication, függések beállítása, stb
  • csoport failover
  • a szolgáltatás itteni felvétele
  • stb.
  • stb.
Mielőtt elkezdtem volna a telepítés, az éppen használt kliens verziónak (6.3.0.16) átfutottam a dokumentációját, nehogy legyen valami meglepetés a telepítés során. És akkor láttam meg, hogy létezik egy wizard, ami éppen a cluster mentések beállítását segíti. Ez két okból is nagyon örvendetes újítás:
  • minden olyan információt, ami a cluster mentéséhez szükséges, maga olvassa ki a cluster-ből, nem nekem kell összeszedni
  • másrészt, nagyon kellett koncentrálni, hogy valamit a fenti számos lépés során el ne írjunk, mert ebből is sok probléma keletkezett régebben.
Hogy is megy 6.3-as klienssel és 2008 vagy 2008 R2 clusterrel?


Nyílván az első két pontot itt is el kell végeznünk, de utána már végigvezet minket a beállítás folyamatán.


Nyílván a 'Help me protect my cluster' opciót választjuk, majd két Next.
 
Adjuk meg, hogy az adott node-on futó cluster csoportok közül melyikhez akarunk mentést beállítani.

Utána megadhatjuk, hogy mely clusterezett diszket (diszkeket) szeretnénk menteni.
 
Utána rákérdez, hogy hol akarjuk majd tárolni a dsm.opt file-t. Azaz nem nekünk kell azt létrehozni, és kitalálnunk, hogy miféle beállításokat kell megadni, hanem ezen lépéseken keresztül eljutunk majd egy korrekt módon összerakott dsm.opt állományig.


A következő két lépésben megmondjuk, hogy mi legyen a scheduler service neve, ill. ha használni szeretnénk a TSM Client Acceptor szolgáltatást, akkor annak is megadhatjuk a nevét.
Utána kell megadnunk azt a node nevet és jelszót, amit a kliens beállítás előtt a TSM szerveren már regisztráltunk.
Ezután már csak a logok helyét kell megadni. Célszerűen ugyanoda érdemes a logokat pakolni, ahova előzőleg a dsm.opt file-t is tettük.
Ezután már csak végre kell hajtatni a beállításokat az Apply gomb megnyomásával.
 
Ezután ha ellenőrizzük a node-okat, akkor láthatjuk, hogy létrejöttek a szolgáltatások, a cluster csoportokban a szolgáltatásoknak megfelelő erőforrások a megfelelő beállításokkal.

Véleményem szerint ez egy nagyon hasznos újítása a 6.3-as kliensnek.







2012. szeptember 7., péntek

VMware HAL (Hands on Lab)

A WMware konferenciák egyik leglátogatottabb "szolgáltatása" a Hands on Lab. Aki volt olyan szerencsés, és ott lehetett az előző évek valamelyikén, az megtapasztalhatta, hogy komoly sorbaállás után lehet csak szabad gépet kapni. (Bár az is igaz, hogy igen nagy számú vékony kliens miatt gyorsan haladt a sor).

A WMworld 2012-re egy kicsit átalakították az infrastruktúrát. Legalábbis a hírek szerint...
Most már saját eszközzel is be lehet ülni egy elkülönített területre, és Wifi segítségével kapcsolódni lehet a HAL környezethez.

Ha a hír csak ennyi lenne, akkor nem lenne érdemes pazarolni rá a biteket. A lényeg, hogy a VMware a konferencia, konferenciák után  nem szünteti meg a környezetet, hanem elérhetővé teszi, mint online szolgáltatás.

Ennek béta tesztelése hamarosan indul, amire már most fel lehet iratkozni ezen az oldalon. Hogy legyen elképzelésünk arról, hogy pontosan miket is lehet majd kipróbálni, létezik egy poszter, amin minden fontos információ megtalálható.

Nem hiszem, hogy a szeptemberi vmug rendezvényre ez már elérhető lesz, de a következőn néhány vékony kliens kihelyezésével a látogatók is biztosan kipróbálhatják majd.

2012. augusztus 29., szerda

FT és SMP Virtuális szerverek

Gondolom sokan hitték azt, hogy a vSphere 5.1 már tartalmazni fogja az FT képességet több processzoros virtuális gépek esetében is. Sajnos ez nincs így, viszont a VMworld-ön már bemutatták működés közben, így már nem lehet messze az éles bevezetéstől.

Néhány változás, fejlesztés az eddig ismert FT technológiához képest:
  • vLockStep protokoll helyett bevezetik az SMP FT protokollt
  • az FT logging networknek már 10GB-os hálózat kell
  • shared VMDK helyett tükrözött/szinkronizált VMDK-t használ az SMP FT, azaz mindkét virtuális gépnek (primary,secondary) lesz saját konfigurációs fájlja, saját VMDK, stb.
  • az elsődleges és másodlagos gépeket futtató hostoknak a szükségük van egy ún. 'tie break' datastore-ra, amit mindketten elérnek. Ez egy backup lehetőség arra az estre, ha az FT logging networkkel lenne valami gond
  • Lehetőség lesz snapshot készítésére, így a mentés is megoldottá válik

A megjelenés dátumáról nem találtam információt.

2012. február 4., szombat

vCenter Operations 5.0

Január 24.-én megjelent a vCenter Operations 5.0. Ebből is létezik 60 napos próba verzió, amit véleményem szerint mindenkinek érdemes telepítenie. Ezzel egy időben megszüntették a CapacityIQ-t, mint önálló terméket. Sőt, azoknak akiknek meglévő CapacityIQ licenszük van, ingyenesen válthatnak a vCenter Operations Advanced verzióra. Akit érdekel működés közben, érdemes a lenti videót megnéznie. Amennyiben kellő tapasztalatot szerzek a termékkel, igyekszem megosztani veletek.



 .

Scripting Games 2012

Ha jól számolom, már harmadszor rendezik meg Scripting Games elnevezésű "versenyt". 2010-ben minden feladatra küldtem be megoldást,és szerencsém is volt. Nyertem egy PowerShell könyvet is, ami viszont Amerákából útban Magyarországra elveszett. Ettől függetlenül hasznos volt. Bár a feladatok nyílván nem kötődnek a PowerCLI használatához, de sokat lehet tanulni a scriptek megírása közben. Akit érdekel, az a lenti linken tájékozódhat az idei versenyről.
2012 Scripting Games

2011. november 21., hétfő

vCloud Director Appliance

Talán a VMware-nél is érezték, hogy egy vCloud Director teszt környezet felállítása nem egy egyszerű feladat. Ezért készítettek egy aplliance-t, amiben előre feltelepítettek mindent (Red Hat, Oracle, vCloud Director). Így az egész leegyszerűsödik egy OVF deploy-ra.
További segítségként készítettek egy Evaluation Guide-ot, ami lépésenként végigvisz a telepítéseken (kezdve a vCenter szerverrel), és a konfiguráción. Bejelentkezés után egy 60 napos licencet kapunk, ami a bejelentkezéstől számítva él (nem a telepítéstől)

Bevallom, nekem egyelőre a vCloud Director eléggé homályos terület, igazából nem is tudtam, hol kezdjek hozzá. Így viszont azt hiszem, a kezdetei lépéseket magam is megteszem.

Mindez megtalálható: https://www.vmware.com/tryvmware/index.php

Ha lesz értékelhető információm a tesztelésről, szintén megosztom.

2011. november 14., hétfő

Linked Clone Pool és a replika vm

Az általam használt View környezetben feltünt, hogy a replika vm-ek száma jelentősen nagyobb,  mint a rendszerben lévő linked clone típusú pool-ok száma. Miközben az elmélet szerint minden pool-hoz egy darab replika tartozik.
A nagy számú replikának valószínűleg az az oka, hogy elég sokszor futott hibára a recompose folyamat, mivel szűkében voltam mindig is a storage területnek. Bár azt nem értem, hogy ha a hibás pool tagokra elindítok egy recompose folyamatot, és az alap virtuális gép, valamint a felhasznált snapshot ugyanaz, akkor miért nem használja a már meglévő replikát?
Mivel ezek a replikák elég sok helyet foglalnak el, ezért szerettem volna tudni, hogy az egyes gépekhez mely replika tartozik. Így ha van olyan replika, amelyik valami hiba folytán maradt a rendszerben, azt bátran törölhetném. Mivel ez a rendszerből könnyen nem olvasható ki, ezért a VMUG közösséghez fordultam segítségért. CZW-től jött a gyors válasz: a descriptor vmdk file-ban megtalálom a szükséges infót. A ParentFileNameHint sor tartalmazta az adott vm-hez tartozó replika vm nevét. Ha pl. a virtuális gép neve V400212, akkor a V400212.vmdk file-ban található az információ.
Most már csak az a kérdés, hogy ha 100 gép esetében kell kinyernem azt az infót, akkor mit tegyek. Mivel a PowerCLI elég közel áll hozzám, és pont erre találták ki, azért azt kezdtem el nézegetni. Hogy egy kicsit felgyorsítsam a dolgokat, a PowerCLI fórumon is feltettem egy kérdést, amire Luc Dekens rövidesen válaszolt is. A továbbiakban az ő útmutatására is támaszkodok.

Legyen a kiválasztott gép a fent is említett V400212:

$vmName = "V400212"

Kérdezzük le, hogy milyen diszkek tartoznak a géphez:

Get-VM -Name $vmName | Get-HardDisk

CapacityKB Persistence Filename
---------- ----------- --------
15728640 Persistent ...FS20_VDI_SYS] V400212MOL/V400212-000001.vmdk
2097152 IndependentPersis... ...isk-D-e61dac41-43c4-499f-8334-40c495ce04c9.vmdk
20480 IndependentPersis... ...0_VDI_SYS] V400212/V4002121-internal.vmdk

A vSphere kilensben leellenőrizve látható, hogy a -00001 végű vmdk a virtuális gép C: meghajtója. Meglepő módon, pont a V400212.VMDK nem szerepel a lekérdezés eredményében. Viszont, ha megnézzük a V400212-000001.vmdk descriptor file tartalmát akkor látható benne a következő bejegyzés:

parentFileNameHint="V400212.vmdk"

Azaz, a virtuális gépet alkotó file-ok között van egy V4000212.VMDK nevű is, ami valószínűleg pont a linked clone technológia miatt szükséges.

Tételezzük fel, hogy a fenti diszkek valamelyikének szeretnénk beleolvasni a descriptor file-jába. Legyen ez az első a fenti három közül. Ha a Get-Datastore paranccsal lekérdezzük, akkor a Name paraméter érték "Hard disk 1" lesz.

$hdName = "Hard disk 1"
$hd = Get-VM -Name $vmName | Get-HardDisk | where {$_.Name -eq $hdName}

A $hd objektum Filename paamétere tartalmazza a vmdk file teljes elérési útját. Ezt egy kis bűvészkedéssel szét tudjuk szedni a Datastore nevére és a file névre.

$ds = Get-Datastore -Name $hd.Filename.Split(']')[0].TrimStart('[')
$vmdkPath = $hd.Filename.Split(']')[1].TrimStart(' ')

Ahhoz, hogy a szokásos Powershell parancsokkal hozzá tudjunk férni a datastore elemihez, hozzunk létre egy új PSDrive objektumot.

New-PSDrive -Location $ds -Name ds -PSProvider VimDatastore -Root '\'

Ettől kezdve, a ds: megadásával tudunk hivatkozni a a virtuális gépet tartalmazó Datastore root mappájára. Ha pedig ez így van, akkor egyszerűen olvassuk el az ott lévő file-ok tartalmát.

$source = ("ds:\" + $vmdkPath).Replace('/','\')
Get-Content -Path $source

Sajnos a várt eredmény helyett a következő üzenetet kapjuk:

Get-Content : Cannot use interface. The IContentCmdletProvider interface is not implemented by this provider.
At line:21 char:12
+ Get-Content <<<< -Path $source
+ CategoryInfo : NotImplemented: (:) [Get-Content], PSNotSupportedException
+ FullyQualifiedErrorId : NotSupported,Microsoft.PowerShell.Commands.GetContentCommand

Azaz, a VimDatastore PSProvider-ben nincs implementálva a Get-Content cmdlet. Akkor most hogyan tovább? Nincs más hátra, mint hogy megpróbáljuk átmásolni a .vmdk file-t a lokális gépre. Legyen ez a temp folder.

$temp = (Get-ChildItem Env:TEMP).Value
$destination = $temp + '\' + $vmdkPath.Split('/')[1]

Ezek után a $source értéke: ds:\V400212\V400212-000001.vmdk
A $destination pedig: D:\DOCUME~1\ZSoltesz\LOCALS~1\Temp\V400212-000001.vmdk
Maga a másolás:

Copy-DatastoreItem -Item $source -Destination $destination

Remélhetőleg, most már meg tudjuk nézni a fuile tartalmát.

Get-Content -Path $destination

És az eredmény:

# Disk DescriptorFile
version=1
CID=df51c9e2
parentCID=86745223
createType="vmfsSparse"
parentFileNameHint="V400212.vmdk"
# Extent description
RW 31457280 VMFSSPARSE "V400212-000001-delta.vmdk"
# The Disk Data Base
#DDB
ddb.longContentID = "2b70c5743a0fbfed935a57b5df51c9e2"
ddb.encoding = "UTF-8"


Hurrá! Győzelem! Illetve mégsem:( Ez, mint az elején írtam, nem annak a diszknek a leíró file-ja, amelyet szeretnénk, de ebben találunk rá hivatkozást, nevezetesen a parentFileNameHint="V400212.vmdk sorban.

Ezek után viszont már nagyon gyorsan eljuthatunk a kívánt információig. A fenti módszerrel másoljuk át a temp mappába a V400212.vmdk-t, majd nézzük meg annak a tartalmát.

Az eredmény:

# Disk DescriptorFile
version=1
CID=86745223
parentCID=3260994c
createType="vmfsSparse"
parentFileNameHint="/vmfs/volumes/4b9776cc-9ad21a92-391f-00215e4cb38d/replica-2d2fdc7f-5e15-4b9d-89be-/replica-2d2fdc7f-5e15-4b9d-89be-.vmdk"
# Extent description
RW 31457280 VMFSSPARSE "V400212-delta.vmdk"

# The Disk Data Base
#DDB

ddb.encoding = "UTF-8"
ddb.longContentID = "2b6a3f59ef1ff403a0c2983786745223"

Innen pedig egy kis bűvészkedés a file tartalmával, nevezetesen:

$replica=Get-Content -Path $destination|?{$_ -like 'Parentfile*'}
$replica.split('/')[5].trim('"')

És meg is kaptuk a replika nevét: replica-2d2fdc7f-5e15-4b9d-89be-.vmdk

Ezek után már csak azt a kódot kell megírni, amelyikkel sorra tudjuk venni az érintett virtuális gépeket, és megtudjuk mi az igazság.

Nem tudom, hogy a fenitől létezik-e sokkal egyszerűbb megoldás, de ez működik. Köszönet még egyszer CZW-nek, valamint Luc Dekens-nek.