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.