Tom/Tab, For what it's worth, my experience is that troubleshooting TSM clients that are VM guests is nothing like dealing with physicals. Assume absolutely nothing. For example, don't assume that the network transfer rate you see on backups has any relationship whatsoever to the network xfer rate you will see on restores. I have seen some VM guests that could run 30MB/s backups, but restores were consistantly 800KB/s! I have also seen performance improvements of 8x simply from "powering" off & on a guest. Besides that, I have some guests that actually run faster TSM backups when they are using the "vlance" virtual nic (which is old 100mb code) rather than the "high-performance" gigabit "vmxnet" nic. Better yet, running comparisons on 8 identical VM guests running the same app returned 7 with very similar performance, and one that was not only magnitudes faster than it's brothers, it was faster than the physical machine we configured to benchmark against the VM's!
I'm not familiar with diskxtender, but does it not let you use journaling for the TSM backups? Steve Schaub Systems Engineer, WNI BlueCross BlueShield of Tennessee 423-752-6574 (desk) 423-785-7347 (cell) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Tab Trepagnier Sent: Saturday, May 27, 2006 6:17 AM To: [email protected] Subject: Re: [ADSM-L] TSM and Diskxtender - Windows Tom, We've seen the same phenomenon. We have TSM 5.1.7 running in a Windows 2003 Sp1 file server with almost 2 million files. The file server is itself running on VMWare and connected to LUNs on our EMC Clariion SAN. 1.5 years ago, that same server had 1.7 million files, was a physical server, and used direct-attached disks. Backups took 3 hours. Now with the mix of products and technologies I've listed, backups are taking *more* than 24 hours, meaning we're backing up that server every other day. Here's the odd part: The Clariion, DiskXtender, and VMWare are all EMC products. We submitted a description of our problem to all three divisions. * DiskXtender support said they don't support installing into a virtual server; sucks to be us. * Clariion support suggested we group our ATA LUNs so that all the LUNs in any RAID group are on the same storage processor. * VMWare support suggested changing the server from a 2-way to a 1-way server and removing its affinity from processor 0. So far we've done everything recommended to us, mostly by VMWare, but it hasn't fixed anything. This problem does not just affect backups. It also affects anti-virus scheduled scans, file searches, and enumerating contents of folders with many child objects. In other words, it appears to be a directory-scanning issue, not a backup issue. I don't have an answer for you. Only my experience that what you're seeing is happening elsewhere, too. Note that we are planning to upgrade our entire TSM system to V 5.3.3+ in about a week. We'll see if that makes any difference. Tab Trepagnier TSM Administrator Laitram, L.L.C. "ADSM: Dist Stor Manager" <[email protected]> wrote on 05/18/2006 03:24:16 PM: > TSM Window Client 5.2.3.4 > TSM Server 5.2.2.5 > Diskxtender 5.6 > > We have a large Windows box with millions of files on it. We utilize > the HSM components of Legato/EMC Diskxtender to migrate the unused > files to TSM media. We have the Diskxtender option set to NOT recall > a file when the accessing program is TSM. > > With all that said, the incremental backup of these millions of files > takes too long. One of my co-workers thinks he read somewhere (cannot > find again) that there is a way to have the TSM client not interface > with the TSM server for migrated files. IE, to completely skip a file > that is migrated, and not do the normal comparision to determine the > file has changed/not changed. > > Has anyone ever heard of something like this? If so - what is the > process? > > Thanks in advance... > > -Tom Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm
