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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Tab Trepagnier
Sent: Saturday, May 27, 2006 6:17 AM
To: ADSM-L AT VM.MARIST DOT EDU
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" <ADSM-L AT VM.MARIST DOT EDU> 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
|
