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.

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.

Ingyenes Quest vWorkspace Desktop Optimizer

Tapasztalatból és a dokumentációkból tudjuk, hogy VDI környezetben a szokásos fizikai környezetben használt desktop image-ből kreált gépek performancia szempontjából nem lesznek optimálisak. A Quest készített egy kis alkalmazást, amivel az általuk összegyűjtött ajánlott beállításokat érvényre tudjuk juttatni akár egy már kész virtuális desktopon, de akár a base image-en is.
Nyílván a saját VDI rendszerükhöz készítették (vWorkspace Desktop), de ugyanúgy hasznos lehet VMware View és Citrix XenDestop esetében is. További információ, és letöltés a Quest közösségi oldaláról, innen.

SDRS - A legjobban várt új funkció

A vSphere 5 megjelenése után Duncan Epping készített egy listát a vSphere újdonságairól. A 140 újdonság közt persze vannak kevésbé fajsúlyos dolgok is, de talán nem véletlenül került első helyre a SDRS, azaz a Storage DRS.

Az SDRS három féle módon is segít az üzemeltetésben (automatikus datastore kiválasztás új vm készítésekor, I/O terhelés elosztás, valamint "tárhely elfogyás elleni védelem"), de nekem mindenképp a harmadik az, ami miatt várom a vSphere 5 upgrade-et. Nyílván a másik kettő is hasznos, de olyan környezetben, ahol a szabad storage terület nem valami sok, ott a harmadik képesség lesz leginkább hasznunkra. Márpedig én pontosan így vagyok vele. Van egy Datacenter, ahol minden datastore túlfoglalt, így tulajdonképpen bármikor előfordulhat, hogy valamelyikben teljesen elfogy a hely. Aki már futott bele ilyen szituációba, az tudja hogy nem túl kellemes. Főleg, ha fontos virtuális szerverek futnak rajta. Nézzük, milyen segítséget kapunk.

A vSphere 5-ben megjelenik a Datastore Cluster fogalma. Ez ugyanazt jelenti, mint hostok esetében az eddig megszokott cluster fogalom, csak ebben az esetben a Datastore Cluster-t alkotó Datastore-ok alkotnak egy közös erőforráscsoportot.

A képen látható módon a három datastore alkot egy clustert. A Summary fülön leolvashatóak a fontosabb paraméterek. Hány tagja van, mennyi az összes kapacitás, mennyi a legnagyobb szabad terület, stb.
A hagyományos cluster-hez hasonlóan tudjuk bekapcsolni a SDRS-t. Jobb klikk a cluster néven, majd Edit settings..

Itt is lehetőségünk van arra, hogy csak ajánlásokat tegyen a SDRS, és majd mi azok alapján lépünk, vagy pedig teljesen automatikusan mindig hajtsa is végre a megfelelő mozgatásokat (SDRS Automation). Majd azokat a fontos paramétereket állíthatjuk be, amelyek szabályozzák az SDRS működését (SDRS Runtime Rules)

Itt állíthatjuk be azt is, hogy az SDRS vegye-e figyelembe az I/O terhelés egyenlőtlenségeit. Csak egy megjegyzés ezzel kapcsolatban. Amikor különböző bemutatókon olyan storage-okat látok, amelyek már egyben tartalmaznak FC,SATA, és Flash diszkeket, valamint azt ígérik, hogy majd a storage eldönti, hogy a terhelés függvényében hol tárol egy adott .VMDK file-t, akkor mindig eszembe jut ez a funkció. Azaz hogy érdemes-e ilyen környezetben használni. De mint a bevezetőben említettem, inkább a tárhely elfogyás elleni védelemmel szeretnék foglalkozni.
Ezzel kapcsolatban a Utilized Space és No recommendations until utilization difference between source and destination is értékeivel szabályozhatjuk az SDRS működését. Az előbbivel azt mondjuk meg, hogy mekkora foglaltság esetében (%) lépjen működésbe az SDRS. Azaz pl. amíg minden datastore foglaltsága egy adott érték alatt van, addig nem történik mozgatás. Az utóbbi érték megadásával kizárhatjuk azt, hogy egymástól alig eltérő foglaltságú datastore-ok között történjen mozgatás. (A képen ez az érték 5%) A téma szempontjából a többi beállítható paraméter érdektelen.

Felmerül a kérdés, hogy ha vmdk mozgatásra kerül sor, akkor az SDRS miként választja ki a mozgatandó virtuális gépet, illetve a cél datastore-t. (Természetesen azt is megengedhetjük, hogy egy adott virtuális gép diszkjeit ne tartsa közös datastore-on, így akár vmdk szinten is történhet mozgatás)
A minél optimálisabb eredmény eléréséhez az SDRS különböző statisztikákat vezet mind a datastore-ok, mind a virtuális diszkekkel kapcsolatban. Pl. ha úgy látja, hogy egy datastore a statisztikák alapján 30 órán belül eléri a Utilized Space által megadott értéket, akkor oda nem fog mozgatni gépet (vagy diszket), mert hamarosan onnan kellene elmozgatni esetleg más diszkeket, hogy megfeleljen a feltételeknek.

A fentiekből kitűnik, hogy az SDRS nagy segítséget jelent (majd, ha eljutunk az éles bevezetésig) abban, hogy ne teljen be egy adott datastore. Persze ettől még nem lesz nagyobb kapacitásunk, de segít a meglévő (esetleg szűkös) tárterület jobb kihasználásában.

VMware Data Recovery 2.0

A vSphere 5 bejelentésével egy időben a VMware Data Recovery-nek (a továbbiakban VDR) is elérhetővé vált egy új verziója. Ráadásul a fő verzió szám ugrott egyet, így akár arra is gondolhattam volna, hogy egy sor újdonság, fejlesztés lesz benne. Mivel az előző verziót élesben használom egy kis környezetben, és mint egy régebbi bejegyzésben írtam, nagyon hiányzik egy riportoló, mail küldő funkció, ezért ez volt az első amit az új funkciók között kerestem. Erről egy kicsit később.
A telepítésről nem akarok részletesen írni, mivel az semmit nem változott. Az upgrade-re sem kell sok betűt pazarolni, mivel ha a régi környezet mentéseit tartalmazó diszkjeit (vagy megosztásait) lecsatoljuk, majd az új appliance-hez felcsatoljuk, akkor tulajdonképpen készen is vagyunk.

Akkor vegyük sorra, mi változott:

• 64 bites CentOS 5.5 operációs rendszeren fut az Appliance.
• Növelték a mentések, integritás ellenőrzések sebességét. Aki már használta, az tudja hogy főleg az utóbbi esetében szükség is volt rá. 100-200GB mentés esetében képes volt órákig tekergetni a diszket úgy, hogy visszajelzés csak arról volt, hogy éppen történik valami. De hogy éppen hol tart, kb. mennyi idő van még hátra, stb. arról mélyen hallgatott.
• A megszakadt integritás ellenőrzést most már tudja folytatni. Eddig, ha valami miatt nem végzett, minden kezdődött előröl. Az ellenőrzés során nem csak azt ellenőrzi, hogy az adatok rendben vannak-e, hanem a megőrzési szabályoknak megfelelően törli a feleslegessé vált mentéseket.
• Most már van egy kis beleszólásunk abba, hogy ezek az ellenőrzések mikor fussanak le. Ha nem állítunk be semmit, vagy a Default-ot választjuk, akkor minden hétköznap délelőtt kilenc és délután öt között fog futni

• Az ellenőrzések futtatása alatt is képes menteni vagy visszatölteni
• Van email küldési lehetőség. Az smtp szerver beállítása semmiben nem különbözik más rendszerekétől. Ezen kívül pedig csak azt tudjuk beállítani, hogy mely napokon és hány órakor akarjuk kapni a levelet. Ennyi. A levél tartalma logikusan felépített, és minden fontos információt tartalmaz. (Appliance paraméterek, futott jobok, mentett gépek, sikertelen mentések, mentési idők, destination-ök állapota)

• Lehetőségünk van arra, hogy futó backup job esetében felfüggesszük a jobot olyan értelemben, hogy amit éppen ment azt még befejezi, de új virtuális gépek mentésébe már nem kezd bele

Néhány tulajdonság, képesség ami nem változott:

• Továbbra is a kisebb környezetek mentésének ideális eszköze. A hangsúly a kisebben van, mivel továbbra is élnek a korlátok (egy appliance max. 100 gépet képes menteni, egy vCenteren max. 10 appliance lehet, max. 2 destination tartozhat egy VDR-hez, és ezek mérete is korlátos)
• Dinamikusan képes új gépeket is menteni, amennyiben datacentert, clustert, vagy foldert jelölünk ki. Ilyenkor az adott helyre bekerült új gép mentése automatikusan megtörténik a következő futásnál.
• Rendkívül rugalmas retention policy (léteznek előre beállított sablonok, de ha kell mi magunk állítjuk be, hogy hány darabot őrizzen meg a legutolsó mentésekből, mennyit a heti mentésekből, a haviból, negyedévesből, évesből)
• A mentési ablak is csak úgy állítható, ahogy az ellenőrzéseket is tudjuk ütemezni. Azaz korlátozhatjuk egy adott időszakra, de pontosan nem tudjuk megmondani, hogy mikor történjen a mentés
• Külön kliens program telepítése után képes file szintű visszaállításra is (itt a telepítés egy .exe file bemásolását jelenti csupán)
• Tudtam, hogy valami fontosat elfelejtek: a nagyon jó deduplikációs  képességet

Mindenki döntse el magában, hogy ez így megérdemli-e a 2.0-ás verziót...

VMware környezet és a TSM BA Client 6.2.3.x

A közelmúltban lehetőségem volt részleteiben tesztelni a Tivoli Data Protection for VMware-t. De most nem a teszt eredményéről szeretnék írni, hanem a fenti TSM kiegészítéshez kötelezően használandó 6.2.3.x kliensről. Egy régebbi bejegyzésben volt már arról szó, hogy a jól működő 6.2.2.x kliens után, ha áttérünk a 6.2.3.x-re, akkor egy igen kellemetlen meglepetésben lesz részünk. Pontosabban csak abban az esetben a mentéseinket fizikai szalagokon (tehát nem VTL) tároljuk. A jelenség az, hogy visszaállításkor minden 128MB után a kliens mintegy 2 percig elgondolkodik, majd újabb 128MB, és így tovább egészen a visszaállítás végéig. Könnyű belátni, hogy egy átlagos virtuális szerver esetében is ez mennyire le tudja lassítani a visszaállítást.
A tesztelés során többek között ennek a viselkedésnek az okára is kíváncsi voltam, illetve szerettem volna megtudni, hogy orvosolható-e ez.Mint majd láthatjátok részben igen.

Nézzük előbb a fenti fura viselkedés okát. A 6.2.2.x verzióban ha megnézzük egy virtuális gép esetében, hogy a TSM milyen és mennyi file-t tárol le, akkor a következőt tapasztaljuk:

Client's Name for File: \NODE1\SNAPSHOT_026000000_2011091300115-8\BUDATS02.ovf

Stored Size: 6,715

Client's Name for File: \NODE1\SNAPSHOT_026000000_2011091300115-8\Hard Disk 1\JOB026000001\MBLK0000.DAT

Stored Size: 40,968.00 M

Client's Name for File: \NODE1\SNAPSHOT_026000000_2011091300115-8\Hard Disk 1\JOB026000001\MBLK0000.NCTL

Stored Size: 369

Client's Name for File: \NODE1\SNAPSHOT_026000000_2011091300115-8\Hard Disk 2\JOB026000002\MBLK0000.DAT

Stored Size: 18,599.33 M

Client's Name for File: \NODE1\SNAPSHOT_026000000_2011091300115-8\Hard Disk 2\JOB026000002\MBLK0000.NCTL

Stored Size: 385

Látható, hogy egy két diszket tartalmazó gép esetében összesen öt file kerül a szalagokra. Egy .ovf file, a diszkek, illetve diszkenként egy un. kontroll file. Ez így a visszaállíthatóság szempontjából optimális megoldás, hiszen egyetlen pozicionálással egy teljes diszket el tud olvasni a TSM szerver a szalagrol.

Mivel a TSM 6.2.3.x-et fel kellett készíteni az inkrementális mentések tárolására is (persze ehhez szükséges a TDP is, de ez most nem fontos), ezért az IBM megváltoztatta a virtuális gépek tárolási módját. Nézzünk egy részletet a fenti géphez kapcsoló mentés szalagon található file-jaiból.

Client's Name for File: \NODE1\SNAPSHOT_001000000_2011091-3131944\Hard Disk 1\JOB001000001\MBLK0000-.DAT

Stored Size: 128.02 M

Client's Name for File: \NODE1\SNAPSHOT_001000000_2011091-3131944\Hard Disk 1\JOB001000001\MBLK0001-.DAT

Stored Size: 128.02 M

Client's Name for File: \NODE1\SNAPSHOT_001000000_2011091-3131944\Hard Disk 1\JOB001000001\MBLK0002-.DAT

Stored Size: 128.02 M

Client's Name for File: \NODE1\SNAPSHOT_001000000_2011091-3131944\Hard Disk 1\JOB001000001\MBLK0003-.DAT

Stored Size: 128.02 M

Látható, hogy a tárolás szempontjából lényegesen megváltozott a helyzet. A fenti virtuális gépet  nem 5, hanem közel 1000 darabban tárolja a TSM szerver. (Minden egyes darabhoz tartozik egy kontroll file is, valamint a 60GB-ot kb. 480 db 128MB-os darabban tárolja)
Ennek kivédésére a legjobb megoldás az lenne, ha a fizikai szalagokat lemezes pool-lal tudnánk helyettesíteni, hiszen ott kevésbé okoz gondot a nagy számú file, mivel nem gond a pozicionálás. De mi van, ha ez nem lehetséges? Egy új, dsm.opt-ba írható opcióval lényegesen fel tudjuk gyorsítani a visszatöltést. Ehhez előbb létre kell hoznunk a TSM szerveren egy új lemezes pool-t (legyen MC_VCB_CONTROL), majd pedig a policy domain-ban egy új management class-t. A gyorsítás lényege, hogy a kontroll file-okat nem a szalagon tároljuk a feldarabolt diszkek között, hanem diszken. Így, ha a MAXNUNMP értékét megfelelően állítjuk be, akkor visszaállításkor a TSM szerver a gyors lemezes pool-ból ki tudja olvasni a kontroll file-okat.
A dsm.opt file a következő sort kell beszúrni:

VMCTLMC   MC_VCB_CONTROL

Számomra a végkövetkeztetés az, hogy ha nem akarjuk használni a TDP for VMware-t, akkor maradjunk inkább a 6.2.2.x verziójú kliensek használatánál. Ezzel nem csak a fenti problémákat tudjuk elkerülni, hanem nyilvánvalóan a mentés is gyorsabb lesz.

VMware Syslog Collector használata vSphere 4 környezetben

Az ötös verzió egyik újdonsága, hogy saját syslog gyűjtő szolgáltatást tartalmaz, azaz minden külső alkalmazás nélkül elérhetjük, hogy a hostjaink logját egy központi helyen tároljuk. Persze ezt eddig is megtehettük a vMA segítségével, de aki Windows környezetben érzi jól magát (mint én), annak ez nagy segítséget jelent. (Tudom, hogy ebben a körben többségben vannak a Linux hívők és ismerők, de én már azt hiszem így maradok)

Mivel a Syslog Collectornak van vCenter független telepítési módja, azért jött az ötlet: mi lenne ha a meglévő vSphere 4 környezet logjait is már ezzel gyűjtögetném egy helyre. Erre igazából csak egy 64 bites, elegendő szabad diszk kapacitással rendelkező szerverre van szükség, hiszen az egész nem más mint egyetlen szolgáltatás, ami nem is kér sok erőforrást.
Az egyelőre nem tiszta számomra, hogy licence szempontjából ez rendben van-e, de kipróbálni akkor is érdemes.

A telepítés nagyon egyszerű.
Indítsuk el a vCenter 5 telepítőjét, majd onnan a VMware Syslog Collector telepítést.

A szokásos üdvözlő és egyéb képernyő után megadhatjuk a telepítés alap könyvtárának és a logok tárolásának helyét.

A Repository helyét szabadon megváltoztathatjuk, de arra ügyelni kell, hogy a könyvtárstruktúra maradjon meg, mivel az feltétele a helyes működésnek.

Itt válasszuk a Stanadalone módot. Utána már csak a default portokat kell elfogadnunk, valamint hogy milyen IP címen akarjuk elérni a Syslog szervert. (Ha esetleg több IP címe lenne a szervernek)

Ha mindez megvan, akkor a telepítés néhány másodperc alatt megtörténik. Ezután már csak annyi a dolgunk, hogy a hostokon beállítsuk a most telepített Syslog szerver IP címét.

A beállítás után, ha visszanézünk a Syslog szerverre, akkor láthatjuk a beállított mappában minden Host egy külön almappába küldi a logokat.

Az egyes logok megnyitása után annyi furcsaság látszik, hogy a logbejegyzések közötti elválasztó karakter nem az új sor, hanem a <166> karakter sorozat. Ahhoz, hogy olvasható legyen a log, ki kell cserélni a <166> stringet egy új sor jelre. Pl. a Notepad++ esetében a \n szekvenciára. Így már olvasható az eredmény:

Tehát mielőtt nekikezdenénk a nagy upgrade folyamatnak, már előtte élvezhetjük a vSphere 5 egyik újdonságát.

Egy kis kiegészítés. Amennyiben utólag szeretnénk módosítani az egyes log file-ok méretét, illetve a megmaradó rotációk számát, akkor az operációs rendszertől függő helyen lévő vmconfig-syslog.xml file-t kell szerkeszteni.

Az .xml helye és tartalma:

Windows 2003 –> C:\Users\All Users\VMware\VMware Syslog Collector\vmconfig-syslog.xml
Windows 2008 –> C:\ProgramData\VMware\VMware Syslog Collector\vmconfig-syslog.xml

<defaultValues>
<port>514</port>
<protocol>TCP,UDP</protocol>
<maxSize>2</maxSize>
<rotate>8</rotate>
<sslPort>1514</sslPort>
</defaultValues>

VMware vSphere Health Check Report v5.0.0

Ha már az előző bejegyzésben szó esett a vCheck scriptről, ami a PowerCLI-t kedvelőknek ad segítséget a rendszerük feltérképezésére, akkor ejtsünk szót a másik, nagyon régóta fejlesztett eszközről is, a VMware vSphere Health Check Report-ról is. Ezt Perl-ben fejleszti William Lam, és már a 38-as verziójánál tart. Ez futtatható vMA-ból, de ha feltelepítjük a VMware vSphere CLI-t, akkor akár Windows alól is.
Futás közben jelentősen leterheli a Windows-t, így arra a fél órára érdemes minden más tevékenységet szüneteltetni. Az output egy .htm file, ami a környezet méretétől függően elég nagyra is meghízhat. (kb. 40 Host és kb. 400 VM esetében 3-4MB).

Itt részletes leírást kapunk a lehetséges paraméterekről, ötleteket a használat módjával kapcsolatban, illetve script tudásáról is kaphatunk egy átfogó képet.
Külön fórum tartozik hozzá, ahol a felhasználók a fejlesztő felé jelezhetik problémáikat, fejlesztési ötleteiket, stb.

Ami még érdekesség, hogy akár vSphere 5 környezetben is futtathatjuk, a fejlesztő felkészítette néhány, csak ott lévő képesség riportolására is (storage DRS).

PowerCLI vCheck 5.40

Nem tudom, ki milyen eszközt használ arra, hogy gyors áttekintést kapjon a virtuális környezete állapotáról, értesüljön a hibákról, lássa mi történt mostanság (ha többen adminisztrálnak) a virtuális gépek terén, stb. Mivel még a VMware megismerése előtt szívesen foglalkoztam Powershell-lel, nagyon örültem amikor láttam, milyen aktív közösségi élet folyik a PowerCLI terén. Így arra gondoltam, majd PowerCLI lesz az alapja annak a napi riportnak, amit készítek. Még mielőtt igen nagy energiát fektettem volna bele, belebotlottam Alan Renouf nagyon hasznos és nagyon sok mindenre kiterjedő scriptjére, a vCheck-re. Rendületlenül fejlődik a script, nem csak Alan által, hanem a közösség tagjai is legalább ötlet szinten hozzájárulnak.  Nem sorolnám fel, hogy milyen lekérdezéseket hajt végre, akit érdekel töltse le innen, és akár a futtatása nélkül (a script elejének elolvasásával) is meggyőződhet a tudásáról.

Használatának feltételei:

• Powershell 2.0
• VMware vSphere PowerCLI 4.1 U1
• VMware vCenter Update Manager PowerCLI 4.1 (opcionális)

A script változtatás nélkül egy HTML formátumú levelet kreál, és küld el a megadott címre, címekre. A kényelmesebb használat érdekében két módosítást végeztem el.

• A riportot a levélben mint csatolt állományt küldöm el.
• Beintegráltam a vSphere kliensbe, így mindig az előző éjszakai állapotot onnan is meg tudom tekinteni

Ahhoz, hogy csatolt állományként kapjam a riportot, módosítani kellett a Send-SMTPmail eljárást a következő módon:

function Send-SMTPmail($to, $from, $subject, $smtpserver, $body, $att1) {
    $mailer = new-object Net.Mail.SMTPclient($smtpserver)
    $msg = new-object Net.Mail.MailMessage($from,$to,$subject,$body)
    $mailer.useDefaultCredentials = $true
    $att = new-object Net.Mail.Attachment($att1)
    $msg.Attachments.Add($att)
    $msg.IsBodyHTML = $true
    $mailer.send($msg)
}

A tényleges küldésnél pedig:

if ($SendEmail) {
    Write-CustomOut "..Sending Email"
    $Filename = "C:\tmp\" + $VIServer + "vCheck" + "_" + $Date.Day + "-" + $Date.Month + "-" + $Date.Year + ".htm"
    $MyReport | out-file -encoding ASCII -filepath $Filename
    send-SMTPmail $EmailTo $EmailFrom "$VISRV vCheck Report" $SMTPSRV "Lásd a csatolt állományban!!" $Filename
}

A vSphere kliens integráció egy kicsit trükkösebb, de mint itt olvasható nem lehetetlen. Érdemes megcsinálni, mert praktikus, és milyen jó látni, hogy egy saját plugin is van a vSphere kliensben:)

  Végül egy részlet a riportból:

vSphere Licencing Advisor

Miután végleges lett az új licence konstrukció, a VMware letölthetővé tette a tárgyban szereplő toolt, amivel mindenki saját maga ellenőrizheti, hogy a meglévő környezetét mekkora plusz költséggel tudná vSphere 5-re upgrade-elni. Szerencsés esetben persze ingyenesen, de az előző bejegyzés alapján látható, hogy lesznek vesztesei az új konstrukciónak. A tool letölthető innen.

A telepítés ettől egyszerűbb nem is lehetne (illetve de, ha telepíteni sem kellene). Indulás után meg kell adni a vCenter szerver nevét vagy IP címét, valamint a bejelentkezési adatokat. Ha több vCenter szerverünk van, akkor egy kis .txt file-ban is lehetőségünk van a szerverek felsorolására, majd a tool-lal beolvastathatjuk.
Az infrastruktúra méretétől függően néhány perc alatt kész is van a kimutatás. Mielőtt az eredményt megtekinthetnénk, az alábbi információt jeleníti meg, ami segít a verziók közti eligazodásban.



Az eredmény egy könnyen áttekinthető táblázat, amelyben néhány alap információt láthatunk. Köztük a lényeget: a meglévő licenceink alapján mennyi vRAM használatára vagyunk jogosultak, illetve jelenleg mennyit használunk.

Pozitív változások a vSphere 5 licencek terén

A július 12-én történt vSphere 5 bejelentés körül támadt nagy öröm mámort csupán egyetlen negatív hír árnyékolta be. Ez a hír pedig nem ám valami régen várt funkció hiánya volt, hanem a licenc struktúra megváltoztatása. Nevezetesen a vRAM alapú licencelés bevezetése.

Miért is váltott ki ellenérzést a meglévő, vagy éppen a virtuálizációt a közeljövőben tervező felhasználók között? Természetesen azért, mert könnyen belátható módon nagyon sok infrastruktúra esetében az áttérés az 5-ös verzióra jelentős többlet költséggel járna. Vegyünk egy egyszerű példát. 2 darab szerver esetében (egyenként 2 darab 4 magos processzorral valamint egyenként 256GB RAM-mal számolva) elegendő 4 darab Enterprise Plus licence vásárlása vSphere 4 alkalmazásakor.
A bejelentés szerint négy darab vSphere 5 Enterprise Plus licence 4*48GB vRAM használatát tette lehetővé. Az összesen 192GB vRAM. Ahhoz, hogy a szervereinkben lévő összes RAM-ot kihasználhassuk, ahhoz még további licencek vásárlása szükséges.
Bár a VMware indokait is meg lehet érteni, a felhasználók számára ez egy elég barátságtalan lépés volt. Meg is teltek a különböző fórumok, blogok az ezzel foglalkozó hozzászólásokkal. Olyanok is elhangzottak, hogy  inkább akkor Hyper-V vagy Xen, mert az lényegesen olcsóbb. Persze kevesebbet is nyújtanak, de ha egy adott költséget nem lehet túllépni, akkor nincs mit tenni.
Úgy tűnik, ezek a negatív hangok eljutottak a megfelelő helyre is, mert hat nappal ezelőtt a VMware bejelentette, hogy bár a vRAM szerinti licencelést megtartja, de módosítja az egyes licencekkel együtt használható vRAM nagyságát. A példában vázolt konfigurációt még így sem lehet teljes mértékben kihasználni a négy darab Enterprise Plus licence vásárlásával, de azért már sokkal kedvezőbb a helyzet. Ha hozzávesszük, hogy a fenti fizikai memória egy szerverben még elég ritka (256GB), így már a felhasználók igen nagy százalékának nem jelent költség növekedést a vSphere 5-re való áttérés.
Bár a teljes igazsághoz hozzátartozik, hogy minél alacsonyabb licence konstrukcióval rendelkezik valaki (pl. Essentials), annál nagyobb esélye van arra, hogy az áttérés csak plusz licence vásárlásával oldható meg. Így meglepő lenne, ha a módosítások hatására teljesen megszűnne a felhasználói panasz áradat.

A lenti táblázatban az eredeti és módosított értékek láthatóak.

vSphere Edition	Previous vRAM  Entitlement	New vRAM Entitlement
vSphere Enterprise+	48 GB	96 GB
vSphere Enterprise	32 GB	64 GB
vSphere Standard	24 GB	32 GB
vSphere Essentials+	24 GB	32 GB
vSphere Essentials	24 GB	32 GB
Free vSphere Hypervisor	8 GB	32 GB
vSphere Desktop	Unlimited	Unlimited

VMware View for Android

Azt hiszem, már sokan várták, hogy iPad után mikor lesz Androidon is elérhető a View kliens. Ez az idő most jött el. Nekem üröm az örömben, hogy csak tableten érhető el, telefonon nem. Remélem ez hamarosan meg fog változni.

Két link:

Android Market: https://market.android.com/details?id=com.vmware.view.client.android&feature=search_result

A fejlesztők oldala: http://blogs.vmware.com/euc/2011/07/android-tablets-now-have-an-awesome-view.html

Hibás VMware Data Recovery működés

Bár a virtuális gépek mentésére használt elsődleges eszköz a TSM, bizonyos esetekben jól meghatározott gépek körére tökéletes megoldás nyújthat a VDR is. Főleg, hogy az 1.2.0-ás verzió már egészen megbízhatóan működik. Most persze ellentmondtam a bejegyzés címének, de tényleg ez az igazság. Hogy néha mégis történik egy kis gubanc? Melyik termékkel nem?

A VDR egyik nagy hiányossága, hogy nem képes üzeneteket küldeni a mentések státuszáról. Éppen ezért fordulhatott elő, hogy néhány napig a backup jobok nem futottak le. Ez onnan derült ki, hogy folyamatosan ellenőrzöm a snapshotok méretét, korát, és az egyik mentendő szervernél feltűnt, hogy a VDR által készített snapshot még mindig létezett. Hogy pontosan mi történt, az már nem fog kiderülni. De az biztos, hogy a VDR már nem törölte a saját maga által kreált snapshot, a mentéshez saját magához felcsatolt diszkek még mindig ott voltak, illetve a backup sem futott attól az eseméyntől kezdve.

Gyors keresés a Neten, és a következő KB cikkhez jutottam el. Bár a körülmények nem voltak teljesen azonosak, de mégis kecsegtetett némi reménnyel.
A cikkben foglaltaknak megfelelően letöltöttem a fixdeletable.py Perl scriptet, bemásoltam a virtuális gép folderébe, majd futtattam.

Látható, hogy bizonyos vmdk file-ok esetében végre is hajtotta a módosításokat (törölhetővé tette a snapshotokat). Ezután létrehoztam egy snapshotot, majd a snapshot manager-ben a Delete All paranccsal igyekeztem megszabadulni az összes snapshottól. A várt siker helyett a következő üzenet fogadott:

A zárolást nyílván nem okozhatta más, mint maga a VDR, hiszen a két diszk továbbra is látszott a VDR erőforrásai között. Ezután még négy lépés hiányzott a sikerhez:

• VDR leállítása
• mivel így a lock megszünt,  a snapshotok törlése
• a VDR lemezei közül a nem oda valók törlése (vigyázva arra, hogy csak a VDR-től vegye el, a datastore-on maradjon
• VDR indítás, ellenőrzés

Ha a Data Recovery rendelkezne valamilyen beépített üzenetküldő szolgáltatással, mindez még a hiba napján megoldódhatott volna. Remélhetőleg a következő verzióban ez a hiányosság megszűnik.

TSM 6.2.2 kliens problémák VMware környezetben

Ahogy ez várható volt, az IBM is igyekszik lépést tartani a többi gyártóval, hogy minél jobban kihasználja a vStorage API for Data Protection (VADP) nyújtotta lehetőségeket.  Bár véleményem szerint soha nem lesz képes olyan szinten integrálni a TSM klienst a VMware környezetbe, mint teszik ezt más gyártók (VEEAM, EMC, stb), de talán nem is az a legfontosabb.  Aki már rendelkezik TSM infrastruktúrával, szeretné minél hatékonyabban használni azt. Pl. ha a VMware támogatja az inkrementális virtuális gép mentést, akkor jó lenne ki is használni a benne rejlő lehetőséget, és nem minden alkalommal lementeni a teljes gépet.

A következőkben szeretném saját tapasztalataim alapján összefoglalni, hogy a TSM mennyit képes használni a VADP lehetőségei közül.

De mielőtt ebbe belemennék, nézzük meg hogy mi a gond a jól ismert VCB-vel. A legnagyobb egyértelműen az, hogy a támogatása meg fog szűnni. Ezt már korábban is ígérte a VMware, de ennek ellenére továbbra is használható. De egészen biztos, hogy ez az állapot változni fog a jövőben. Hátrányként említhetem még a szükséges átmeneti diszk meglétét, vagy még inkább a körülményes visszaállítást (első lépésben a TSM BA klienssel a proxy szerverre, majd a VMware konverterrel beilleszteni az infrastruktúrába).

Nézzük, hogyan fejlődött a TSM a közelmúltban:

-          BA Client 6.2.0

Megjelent a vStorage API használatának lehetősége. Igaz, hogy egyelőre csak a file szintű mentésekhez használta a TSM, de látszott, hogy jó az irány

-          BA Client 6.2.2

Ebben már akár FULLVM akár file szintű mentést is végezhetünk a VADP használatával. Azaz a proxy szerveren a továbbiakban nincs szükség a VCB-re. Mivel a VADP használatkor közvetlenül a datastore-okról történik a mentés, az átmeneti tárterület is felszabadítható. Nem utolsó sorban pedig a visszaállítás leegyszerűsödik egyetlen műveletre

-          BA Client 6.2.3

Még mindig nincs inkrementális vm mentési lehetőség, még mindig nem lehet full vm mentésből egyedi fájlokat visszaállítani.

Miközben arra vártam, hogy mikor jelenik meg az a TSM verzió, ami már a fenti dolgokat is tudja, a fórumokban feltűnt egy TSM for Virtual Environments vagy más néven TDP for VMware nevű termék. Ez a termék  képes inkrementális vm mentésre, képes teljes gép mentésből fájlok visszaállítására, stb. Gondolom ezek után mindenki számára világossá vált, hogy az IBM nem a hagyományos BA klienst fogja tovább okosítani, hanem egy külön terméket fejleszt.  Ami hasonlóan más TDP termékekhez, külön licence ellenében használható.  Nem erre számíttottam….

A fenti információ kissé hivatalosabb formában megtalálható a következő linken.

https://www-304.ibm.com/support/docview.wss?uid=swg21417529

 De aki nem akar sokat olvasni, annak idézem:

„Full VM block level incremental support is provided in the Tivoli Storage Manager Backup-Archive Client version 6.2.3 level for those customers who have purchased the "Tivoli Storage Manager for Virtual Environment - Data Protection for VMware" product. Full VM incremental backup requires VMware Change Block Tracking (CBT) and is only available on virtual machines on ESX 4.0 or later host with virtual hardware level 7.

To enable the Backup-Archive Client full VM incremental support (dsmc backup vm -mode=incremental), run the install package for "TSM for Virtual Environment - TDP for VMware". Under custom install, select the "Data Protection for VMware Enablement File" component. The "Data Protection for VMware Mount" component can also be installed on the same machine to enable the individual file restore from full VM backups. When using these features, use the Client Preference Editor to ensure backup type is set to FULLVM and VM Full type is set to use the vStorage APIs. „

Aki szeretne technikai részleteket megtudni a termékről, az IBM oldalán találhat róla némi információt. Ezek mellett június 26-án az IBM tartott az Interneten egy live traininget, amit utólag is meg lehet nézni egy rövid regisztráció után a következő linken:

https://de202.centra.com/Reg/main/00000034afe663012f4ff1226e007ad8/en_US

Végül pedig szeretném megosztani azokat a tapasztalatokat, amiket a vStorage API-t használó TSM környezet kialakításánál szereztem. Nem állítom, hogy mindenki belefut ezekbe a dolgokba, de a fórumokat olvasva másnak is voltak hasonló tapasztalatai.

-          A restore vm parancs nem működik, ha a vmware környezetben a vcenter alatt közvetlenül nem a Datacenterek vannak, hanem valamilyen megfontolásból mappák. A mentések rendben mennek, de visszatöltéskor hibát jelez. Ez igaz mind a GUI mind a parancssor használata estén

-          Ha már történtek mentések a VCB-vel, és ugyanazokat a gépeket egy adott időtől kezdve a vStorage API-n keresztül mentünk, akkor a GUI nem tudja jól megjeleníteni a kétféle mentését ugyannak a virtuális gépnek (Aktív és inaktív). Ez akkor oldódik fel, ha már elegendő idő eltelik, és törölhető a VCB mentéseket tartalmazó filespace. Amíg ez nem lehetséges, a parancssoros restore a járható út. Ott a –pick opció használatával (és persze az –inactive opcióval) kilistázza mindkét féle mentést.

-           A restore folyamán a vcenter szerveren tömegestől jelenik meg a ’Clear lazy zero’ üzenet. Ez a vcenter működéséből fakad, igaz hogy valamelyest lassítja a visszatöltést, de más problémát nem okoz. A vcenter következő verziójában ígérik, hogy kijavítják. Közvetlen hostra való visszatöltés esetén nem jelentkezik (fórum hozzászólások szerint).

-          Egy virtuális gép diszkje két féle lehet. Thick vagy thin. Az első esetben a diszk létrehozásakor lefoglalja a teljes területet a storage-on, míg a második esetben csak annyit, amennyit ténylegesen elfoglalnak rajta az adatok. Viszont visszatöltés után az eredetileg thin diszk thick lesz. Ezt egy storage vMotion-nel lehet utólag orvosolni. Ez megint csak nem a TSM működéséből fakad, hanem a vStorage API-ból. Gondolom, ez is javítva lesz a későbbiekben.

-          6.2.2 à6.2.3 upgrade után kb. 2 percenként töltött vissza 128MB-ot. Visszatöltött 128MB-ot, majd várt 2 percet, újra visszatöltött 128MB-ot, és így tovább. Erre valaki már nyitott esetet az IBM felé. Ha visszaálltam  6.2.2-re, a 6.2.3-mal mentett adatok visszatöltése továbbra is lassú maradt, de az újabb mentésekből történő visszatöltések már normál sebességűek.

-          Mivel a vm restore egy új gépet hoz létre, ezért a visszatöltött gép újabb mentése hibára fog futni, mert az adott gépnek már más lesz a vm id-je, mint a mentett régebbi verzióké. Ezért vagy törölni kell az adott gép mentésit tartalmazó filespace-t, vagy a vm-nek adni kell egy másik nevet visszatöltés után. (ettől a dns neve nem változik.)