vCenter Multi-Hypervisor Manager

Csak idő kérdése volt, hogy a VMware mikor jelenik meg valamilyen vCenter kiegészítéssel, amellyel lehetővé válik más virtualizációs környezetek menedzselése is. Ha jól tudom, a System Center már lehetővé teszi, hogy vCenter megléte mellett bizonyos feladatokat elvégezzünk a a VMware környezetünkben is. Úgy tűnik, egyre több cég használ egynél több virtualizációs megoldást. A lenti ábra egy mostani amerikai felmérésből való, amiből az előző állítás is következik.

 

Ha valakit érdekel a felmérés teljes eredménye, akkor innen letöltheti.

 

Egy nagyon új termékről van szó, ami kb. 10 napja jelent meg. Minden információ, ami ezzel kapcsolatban elérhető, itt található: http://www.vmware.com/support/pubs/vcenter-multihypervisor-manager-pubs.html

Enyhén szólva elég korlátozott tudású a kiegészítő. Bár az én véleményem szerint nem is kellene ebbe túl sok energiát fektetni, de biztosan nincs igazam.

 

Nézzük egy kicsit közelebbről meg a terméket. Két külön telepítendő komponense van. Ezt nem részletezem, nem nagy dolog. A dokumentációból kimásolt ábrán látszik a lényeg.

 

 

 

Egy kicsit ellentmond annak a törekvésnek, hogy az új dolgokat már csak a Web kliensen keresztül lehet használni, mert ez egy hagyományos plug-in a régi kliensben. Ha feltelepítettük a vCenter szerverre, majd a kliensben is telepítettük a plug-int, akkor nézzük, mi is változik.

 

 

Az Inventory részre új lakó költözött, a vCenter Multi Hypervisor Manager. Ha elindítjuk, akkor a vCenter nevére kattintva felvehetjük az inventory-ba az első nem ESX szerverünket. Meg kell adni a Hyper-V szerver nevét vagy IP címét, és egy olyan accountot, amivel csatlakozni tudunk a hosthoz. Ez a verzió csak Windows 2008 és 2008 R2-n futó Hyper-V szervereket képes kezelni. Ha sikeresek voltunk, akkor a valami ilyesmit kapunk.

 

 

Látható, hogy kinézetben igyekeztek mindenben követni azt amit megszoktunk, de azért a "fülek" és lehetőségek száma lényegesen kevesebb.

Nézzünk egy listát a lehetőségeinkről:

• Hostokat tudunk felvenni, törölni, valamint meg tudjuk nézni a konfigurációjukat
• Virtuális gépeket tudunk létrehozni a Hyper-V hostokon
• Meglévő virtuális gépek tulajdonságait tudjuk szerkeszteni
• Tudunk CD-t,DVD-t, floppy-t csatolni a virtuális géphez, így pl. az op. rendszer telepítését is el tudjuk végezni.
• A szokásos "power" műveleteket el tudjuk végezni hostok és virtuális gépek esetén

Nézzünk meg néhány képet. A következő egy host Summary ablak.

 

 

Ez pedig egy virtuális gép tulajdonságainak módosításaira szolgáló ablak.

 

 

 

Végül pedig nézzük, hogy kell új diszket adni egy meglévő géphez.

 

 

Kíváncsi lennék a véleményetekre, hogy szerintetek szükséges-e ilyen irányba fejleszteni a vCenter környezetet, vagy pedig mindenhez használjuk az ahhoz leginkább megfelelő alkalmazást. Jelenleg elég kevés tudást pakoltak az MHM plug-inbe, de a kényszer miatt gondolom gyors fejlődés előtt áll.

 

 

 

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

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.