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.