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

TSM BA kliens upgrade PowerShell használatával

Bár a TSM egy bizonyos verzió szám fölött támogatja a kliensek automatikus frissítési lehetőségét, mégsem arról szeretnék írni. Igazság szerint nem is tudnék, mivel még ki sem próbáltam. Viszont nagy számú kliens esetén jó ha van olyan módszer, amivel valamennyire automatizálni lehet a frissítéseket.
A következő feltételeknek meg szerettem volna felelni:

• ne legyen szerver újraindítás
• az upgrade során minimalizáljuk a manuális munkát
• minden szerverre testre szabott, az adott szerveren futó beállításokat figyelembe vevő script készüljön

Az új telepítésekkel most nem akarok foglalkozni. Ott végül is nem túl bonyolult a feladat, hiszen a dokumentációk alapján könnyen össze lehet dobni egy scriptet, ami elvégzi a telepítést, létrehozza a szolgáltatásokat, esetleg be is másol egy előre elkészített dsm.opt file-t.
De mi a helyzet akkor, amikor már van egy futó kliens a gépen, és azt szeretnénk frissíteni? Főleg ha nem is egységesen történt a múltban a telepítés, hanem sok esetben esetleg a szerver gazdája telepítette, máskor a TSM admin, stb. Ennek megfelelően a szolgáltatások neve sem feltétlenül egységes, ezen kívül a verziók is széles skálán mozognak. És persze vannak 32 és 64 bites szerverek is, amik más és más telepítő készletet igényelnek.
Ilyen esetben úgy kell megírni a scriptet, hogy vegye figyelembe az egyes gépeken meglévő beállításokat. Ezen beállítások pedig megtalálhatóak a registry-ben. Mivel már sok más feladatra is használtam a PowerShell-t, ezért itt is kézenfekvőnek tűnt a használata.
Ahhoz, hogy a Registry-ből olvassunk, kellenek megfelelő függvények, amik sajnálatos módon hiányoznak a PowerShell-ből. Szerencsére ezeket már megírták mások, és az Interneten keresztül elérhetővé tették számunkra. Pl. ez: http://poshcode.org/2162
Az elképzelés a következő volt. Egy  szöveg file-ban megadott node nevek alapján a script minden egyes gép számára legyárt egy .cmd file-t, amit egyszerűen elküldök a szervergazdának, aki futtatja. Mivel nekem nincs adminisztrátori jogom a szervereken, ezért megkértem egy domain admint, hogy futtassa a scriptemet.
Az egyszerűség kedvéért csak olyan gépekkel foglalkoztam, amelyeken csak szimpla TSM BA kliens volt, semmilyen TDP nem futott rajta. Ez az én esetben kiteszi a gépek 90%-át. Az előkészítés során meghatároztam a node-ok listáját. Mivel a node név megegyezik nálunk a gép nevével, ez nem volt nehéz feladat. Ebből készült a nodelist.txt file. Ezt felhasználva a PowerShell script a lenti sorban látható módon elkezdi feldolgozni a file tartalmát. Nyílván a foreach blokkban történik a feldolgozás.

 

get-content -Path d:\tsm_ps\nodelist.txt|foreach-object {....}

A jobb olvashatóság kedvéért a blokkon belül a $_ változót beraktam a $aktserver változóba.

$aktserver=$_

Ezután meghatároztam a .cmd file-t, amibe a script majd írogatja a szükséges sorokat.

$cmdname="D:\tsm_ps\" + $aktserver + "_upgrade.cmd"

Ezután kell egy kicsit olvasni a Registry-ből. Igazából a node nevekre nincs szükség, hiszen feltételeztem, hogy a node név megegyezik a szerver nevével. Újabb kliensek esetében a node információk a következő helyen találhatóak ($p1), míg a régebbi 5.5 előtti kliensek esetében pedig itt ($p). Bár mint mondtam, ezt az információt nem fogom használni a következőkben.

$p = "HKLM:\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes"
$p1 = "HKLM:\SOFTWARE\IBM\ADSM\CurrentVersion\Nodes"

Nézzük meg, hogy az adott gépen milyen szolgáltatások vannak definiálva. Ha az újraindítást el szeretnénk kerülni, akkor mindenképp le kell állítani a futó szolgáltatásokat az upgrade előtt. De mivel az én esetemben szerettem volna egységesíteni is a beállításokat, így nem csak leállítom, hanem majd törlöm is őket.

$service_list=get-remoteregkey $_ $p_key $property |get-member|where-object{$_.membertype -eq "NoteProperty"}|foreach-object{$_.name}

Itt a get-remoteregkey cmdlet-et használtam, de biztosan található másféle is a poshcode.org oldalon. Itt a három paraméter:

$_ - a gép neve
$p_key - "HKLM:\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Scheduler Service"
$property - "*"

Így a $service_list változóba megkapjuk a szolgáltatások nevét, amit nem csak a leállításra és törlése tudunk használni, hanem akár a szolgáltatások újbóli létrehozására is, ha az upgrade már lefutott.

Mostanra lett meg (majdnem) minden információ, így indulhat a parancs file gyártás. A jobb olvashatóság kedvéért a parancs file minden szekciója elő elhelyeztem egy információs sort. Pl. az első lépés esetén ez így néz ki:

 

"REM " |out-file $cmdname -encoding "Default" -append
"REM Stop TSM services----------------------" | out-file $cmdname -encoding "Default" -append
"REM " |out-file $cmdname -encoding "Default" -append

Első lépésben leállítom a szolgáltatásokat.

$service_list|foreach-object{"net stop " + '"' + $_+        '"'}|out-file $cmdname  -encoding "Default" -append

Majd utána törlöm is őket.

$service_list|foreach-object{"dsmcutil remove /name:" + '"' + $_+       '"'}|out-file $cmdname  -encoding "Default" -append

Mielőtt az upgrade kezdődne, meg kell adni a telepítő anyag elérhetőségét. Én ezt egy hálózati megosztással oldottam meg.

"net use i: \\szerver\dc |out-file $cmdname -encoding "Default" -append

Természetesen itt olyan betűt kell használnunk, amit a szerveren még nem létezik. Illetve arról is gondoskodni kell, hogy a megosztáshoz mindenkinek legyen meg az olvasási joga.

Az előbb azt mondtam, hogy majdnem minden információ megvan, de még egy fontos hiányzik. Mégpedig az, hogy 32 vagy 64 bites operációs rendszerről van-e szó. Ezt a WMI lekérdezésével lehet eldönteni.

$OS=get-wmiobject -class win32_operatingsystem -namespace "root\CIMV2" -computername $aktserver

Azért egy kicsit trükkös a dolog. Pontosabban én nem találtam olyan mezőt a lekérdezés eredményében, ami mindenféle operációs rendszer esetén egyértelműen megmondta volna, hogy 32 vagy 64 bitről van-e szó. Én pl. a következő sor alapján döntöttem el:

if (($OS.Caption.Contains("64") -eq $True) -or ($OS.Caption.Contains("2008 R2") -eq $True))

Ez így különben nem teljesen jó (64 bites Windows 2008 esetén nem jó eredményt ad), de egy kicsit összetettebb feltételrendszer használatával javítható.
Ezen a ponton a script kétfelé ágazik, hiszen eltérő install csomagot kell használni. És ez nem csak magának a BA kliensnek a telepítésére igaz, hanem a C++ 10 Redistributable telepítésére is, ami feltétele a BA használatának. Itt most minden magyarázat nélkül beillesztem a kétféle telepítéshez szükséges parancsokat előállító script részleteket.

64 bit:

$CppInstallstring="I:\TSM_BA_Client_x64\ISSetupPrerequisites\{270b0954-35ca-4324-bbc6-ba5db9072dad}\vcredist_x86.exe /q /c:" + '"' +"msiexec /i vcredist.msi /qn /l*v" + '"'
$CppInstallstring|out-file $cmdname -encoding "Default" -append   
$CppInstallstring_x64="I:\TSM_BA_Client_x64\ISSetupPrerequisites\{7f66a156-bc3b-479d-9703-65db354235cc}\vcredist_x64.exe /q /c:" + '"' +"msiexec /i vcredist.msi /qn /l*v" + '"'
$CppInstallstring_x64|out-file $cmdname -encoding "Default" -append   

 

$installstring = "msiexec /i " + '"' + "i:\TSM_BA_Client_x64\IBM Tivoli Storage Manager Client.msi" + '"' + " RebootYesNo=" + '"' + "No" + '"' + " REBOOT=" + '"' + "Supress" + '"' + " ALLUSERS=1 INSTALLDIR="
$installstring=$installstring + '"' + "c:\program files\tivoli\tsm" + '"' + " ADDLOCAL=" + '"' + "BackupArchiveGUI,BackupArchiveWeb,Api32Runtime,Api64Runtime" + '"'
$installstring=$installstring + " TRANSFORMS=1033.mst /qn /l*v " + '"' + "c:\tsminstall_baclient_log.txt" + '"'
$installstring|out-file $cmdname -encoding "Default" -append

32 bit:
 

$CppInstallstring="I:\TSM_BA_Client\ISSetupPrerequisites\{270b0954-35ca-4324-bbc6-ba5db9072dad}\vcredist_x86.exe /q /c:" + '"' +"msiexec /i vcredist.msi /qn /l*v" + '"'
$CppInstallstring|out-file $cmdname -encoding "Default" -append

$installstring="msiexec /i " + '"' + "i:\TSM_BA_Client\IBM Tivoli Storage Manager Client.msi" + '"' + " RebootYesNo=" + '"' + "No" + '"' + " REBOOT=" + '"' + "Supress" + '"' + " ALLUSERS=1 INSTALLDIR="
$installstring=$installstring + '"' + "c:\program files\tivoli\tsm" + '"' + " ADDLOCAL=" + '"' + "BackupArchiveGUI,BackupArchiveWeb,ApiRuntime" + '"'
$installstring=$installstring + " TRANSFORMS=1033.mst /qn /l*v " + '"' + "c:\tsminstall_baclient_log.txt" + '"'
$installstring|out-file $cmdname -encoding "Default" -append

A TSM BA kliens telepítő paraméterezését összeállító kódban azért van több sorba szétszedve a $installstring változó összerakása, mert egyébként igen hosszú sorokat kaptam volna, ami nehezítette volna az olvasását. A fenti sorok megírása elég nagy odafigyelést igényelt.

Az ezután következő részek már megint egységesek, hiszen ha fut az eddig megírt parancs file, akkor már eljutunk odáig, hogy a BA kliens telepítve van, már csak a szolgáltatásokat kell létrehozni, elindítani.

Mint írtam korábban, most fel lehetne használni a $service_list változót, hiszen abban letároltuk az előző verzió által használt szolgáltatásokat. De én most mégsem ezt használtam. Az okot már említettem, nem volt egységes eddig a telepítés, ezután pedig azt szerettem volna elérni, hogy minden szerveren azonos neve legyen a Scheduler service-nek és a CAD-nek. Ezért inkább egyszerűen létrehoztam a szolgáltatásokat. Előbb a scheduler-t.

$Schedulerstring="dsmcutil install scheduler /name:" + '"' + "TSM Scheduler Service" + '"' + " /clientdir:c:\progra~1\tivoli\tsm\baclient /optfile:c:\progra~1\tivoli\tsm\baclient\dsm.opt /node:" + $aktserver + " /password:adsm /validate:no /autostart:no"
$Schedulerstring| out-file $cmdname -encoding "Default" -append

Majd a Client Acceptor-t.

$CADString="dsmcutil install CAD /name:" + '"' + "TSM Client Acceptor" + '"' + " /cadschedname:" + '"' + "TSM Scheduler Service" +'"' +" /node:" + $aktserver + " /password:adsm /autostart:yes /validate:no"
$CADString| out-file $cmdname -encoding "Default" -append

Most már csak két lépés van hátra. Előbb megszüntetem az ideiglenesen felcsatolt hálózati meghajtót.

"net use i: /delete" |out-file $cmdname -encoding "Default" -append

Majd pedig elindítom a CAD service-t.

"net start " + '"' + "TSM Client Acceptor" +'"'|out-file $cmdname -encoding "Default" -append

És készen is vagyunk:)

Természetesen a teljes script tartalmaz némi log írást, hibakezelést, illetve a meghívatkozott Registry kezelő eljárásokat is.

A végeredmény pedig egy közönséges .cmd file, amit csak futtatnunk kell admin joggal az adott szerveren.

A hosszabb kód részek elég nehezen olvashatóak, de ha kimásoljátok valamilyen szerkesztőbe, akkor áttekinthetőbb lesz.

Ha valakinek kérdése van ezzel kapcsolatban, segítek ha tudok.

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.

Hyper-V V3 vs. VMWare 5 (5.1)

A címével ellentétben nem szeretném összehasonlítani a két terméket, mert csak VMWare-ben szerzett ismereteim és tapasztalataim vannak. De a Netet olvasva, sok embernek az a véleménye, hogy a 3-as Hyper-V tudásban már lassan felveszi a versenyt a VMWare-rel, árban viszont lényegesen olcsóbb. Most nem kifejezetten a Hyper-V árára gondolok, mert azt tartalmazza a Windows Server 2012, így árban az nem jelent plusz költséget. De ahhoz, hogy egy nagyobb vállalat használja a Hyper-V-t, mint fő virtualizációs megoldást, ahhoz már kell az System Center 2012 SP1 is. Ami még nem jelent meg mint termék, így igazi összehasonlítást még nem is lehetne tenni.
Amiért ezt most mégis írom, a véleményetekre lennék kíváncsi.

Gondolom itt mindenki kisebb-nagyobb VMware környezetet üzemeltet, támogat. Milyen érveitek lennének a VMware megtartása mellett, ha valaki azt mondaná nektek, hogy a Microsoft most már hasonló tudást tud nyújtani, kisebb költséggel. Mik lennének azok a szempontok, amik nálatok kizárná az áttérést?

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.

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.

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.