2012. november 11., vasárnap

TXNBYTELIMIT (dsm.opt)

Még 2011-ben belefutottam abba a problémába, hogy a TSM BA kliens 6.2.3-as verziójától kezdve a direkt szalagra történő virtuális gép mentési sebessége az előző verziókhoz képest töredékére esett vissza. Ez a sebesség visszaesés a virtuális diszkek TSM szerveren való megváltozott tárolási módjából fakadt. Ezen sokat lehetett segíteni a ún. kontroll file-ok lemezes pool-ba irányításával. Erről részletesen írtam itt és itt.

Végül a problémát a TXNBYTELIMIT paraméter megváltoztatásával lehetett orvosolni. Bár azt a sebességet továbbra sem tudja produkálni, mint pl. a 6.2.2-es kliens, de ez már így tökéletesen használható.

A TXNBYTELIMIT értéket a dsm.opt file-ban adhatjuk meg. Értékével azt szabályozzuk, hogy a TSM kliens mennyi adatot küldhet a TSM szerverre, mielőtt a TSM szerver a saját adatbázisában el nem könyveli a tranzakciót. Ez a 6.3-as kliensben 300KB és 32GB között mozoghat. Nyílván ez úgy segít a mentés gyorsításában, hogy meglehetősen nagy értéket állítunk be. Ekkor ugyanis a TSM kliensnek ritkábban kell arra várnia, hogy a TSM szerver visszajelezze az átküldött adatok sikeres tárolását.

Természetesen a nagy értéknek lehet negatív hatása is, hiszen sikertelen tranzakció esetén újra át kell küldeni a teljes adat mennyiséget. Én konkrétan a 16GB-os értéket használom. További növelés nem gyorsította fel a mentést.

2012. november 10., szombat

vSphere Data Protection 5.1 - Telepítés, konfigurálás

Annak ellenére, hogy a vSphere Data Recovery (VDR) 2.0 megjelenésekor konferenciákon, cikkekben az az információ jelent meg, hogy az a verzió már egészen használható, sőt szereztem vele jó tapasztalatokat is, mégis azt kell mondjam, hogy meglehetősen problémás a használata. Főbb problémák közé tartozik a nagyon lassú visszatöltés, a teljesen sztochasztikus mentési sebesség (ugyanaz a gép egyszer fél óra, máskor két óra), illetve ha az NFS tároló és a host között valamiért megszakadt a kapcsolat, akkor kivárhatatlan hosszúságú integritás ellenőrzés kezdődött.

Reményeim szerint a vSphere 5.1 mellé a VDR helyett csomagolt vSphere Data Protection (VDP) kellemesebb alkalmazás lesz (Csak az Essentials verzióhoz nem használható). Hogy ez tényleg így van-e, egy 5.1-es teszt környezetben kipróbálom. A tesztelés közben szerzett tapasztalatokat szeretném 2-3 posztban megosztani Veletek. Az első részben a telepítés és konfiguráció lépéseit fogom áttekinteni.

A VDP három változatban tölthető le. 0,5TB, 1TB, 2TB Ezzel a döntéssel meghatározzuk azt, hogy mekkora tárterületet használhatunk mentéseink tárolására. Döntésünk végleges, nincs átjárás az egyes változatok között:( Viszont egy vCenter alatt több appliance is futhat.

A kezdéshez már csak egy működő vCenter 5.1 környezet és némi szabad tárterület szükséges. Szokásos módon, Appliance formájában kapjuk meg, így adott az első lépés:
Nem akarlak az OVA telepítés lépéseivel feleslegesen fárasztani titeket, de az első képernyőt érdemes megnézni.
Arra szeretném felhívni a figyelmeteket, hogy annak ellenére, hogy a 0,5TB-os verziót telepítettem, az appliance bizony 868GB helyet foglal el. Ez a 2TB-os verzió esetében több mint 3TB-ot jelent.
Mint mondtam a telepítés lépéseit nem akarom részletezni. A folyamat az új Web kliens bal felső sarkában követhető.
A telepítés végeztével vessünk egy pillantást a kész gép beállításaira. Látható pl, hogy ez a viszonylag nagy méret hogy jön össze. A 2TB-os verzió esetében is 256GB.os diszkekből áll a virtuális gép.


Most már ideje bekapcsolni a gépet, hogy a kezdeti konfigurációt elvégezhessük. Ameddig a gép bootol, szerezzünk be fix IP címet (DHCP nem támogatott), valamint regisztráljuk be a DNS szerverünkbe olyan néven, ahogy hivatkozni szeretnénk rá a későbbiekben. Ez a kép fogad minket a konzolon:

Láthatjuk, hogy akár itt is elvégezhetnénk a konfigurációt, de ha a képen hivatkozott oldalra bejelentkezünk, sokkal kellemesebb felületen dolgozhatunk. Tehát a böngészőbe írjuk be: https://vdp_ip_cim:8543/vdp-configure.
Itt érdemes megemlíteni, hogy az első induláskor az ún. install módba jelentkezünk be, de ha ezen túljutunk, akkor legközelebb már konfigurációs mód jelenik majd meg, ami sokkal több lehetőséget tartalmaz. Tehát akkor most lépjünk be az install módba, a root/changeme név/jelszó páros használatával.
 
A következő tetszetős képernyőt kapjuk:
Nézzük az elsőt, ahol a hálózati beállításokat tehetjük meg. Ha nem sikerül a név feloldás, nem tudunk tovább lépni, tehát mint említettem előtte legyen meg a DNS bejegyzés.
A következőn válasszuk ki a megfelelő időzónát.
 
A következő ablakban a 'changeme' jelszó helyett kell megadnunk valami "erősebbet". Mint látható, van néhány feltétel.
Már csak egy lépés van hátra. Meg kell adni a vCenter szerver adatait, accountot, jelszót, az SSO szerver címét.
Ezután már csak a 'Finish' van hátra.
Végül újra kell indítani a virtuális gépet (kapunk erről üzenetet is). A dokumentáció is felhívja rá a figyelmet, ez az újraindítás kb. 30 percig fog tartani. Valóban sokáig tart, érdemes közben a konzolt figyelni, hol tart a folyamat.
Ha a gép újraindult, jelentkezzünk be újra. Ekkor természetesen a már előzőleg megadott jelszót kell használnunk. Mint írtam korábban, ún. konfigurációs módban indul el virtuális gép, ahol többek között az előbbiekben bemutatott beállításokat tudjuk megváltoztatni, vagy itt tudjuk elvégezni a jövőben az Appliance frissítéseket, valamint az egyes szolgáltatásokat tudjuk leállítani/indítani.


A következő részben már konkrétan a mentések beállításával, időzítésével, és általában a VDP képességivel szeretnék foglalkozni.

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