Hagen,
1) how many nodes/clients do you have (backup) ?
2) how many disk stg pools do have ?
3) what is yr collocation setting on the tape stg pools ?
4) How many tape stg pools do you have ?
5) what type of network to you have between the clients and the TSM server
?

Additionally,  disk pool is not always the best fit solution for an
environment, you might want to reconsider and distribute the load between
the tape drives and the disk pool. You might want to send your "haviest"
node to the disk pool and have your other clients go directly to tapes. Or
if you have TDP modules and you have a lot of logs, you also might want to
consider sending only your logs to disk stg pool.

Regards,

Othonas





Hagen Finley <hfinley AT LONGS DOT COM>@VM.MARIST.EDU> on 02/17/2001 12:37:23 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:  Migration Processes from Diskpools to Tape Devices



    We recently added 40 GBs to our backup diskpool in an effort to speed
up our backup processes. In large part that has worked, however, now we
find the tape devices sit idle all night and, to make matters worse, the
migration process from the diskpool to tape (a six 3590 3494 library)
does not seem to engage more than one drive. So I believe we are actually
worse off now because we have merely moved the bottleneck from the client
to the server to the diskpool to the tape device and now our tape drives
sit idle most of the night. I have contacted TSM support (we are at 4.12)
and they indicated that the migration processes setting (which has been
set as high as 6) does not translate to tape drive mounts as I might have
imagined. Instead in a logic I found difficult to follow, processes are
linked to nodes or at least node filespaces in the backup pool. From
their perspective there appears to be no way to specify migration tape
mounts.
    What we are aiming for is a large enough diskpool to buffer the
entire night's backup volume and then to run our copypool process for
offsiting our copy tapes followed by a migration of the data from the
diskpool to the resident tapes in the library (disk caching is not really
a goal at this time). We can throw a couple hundred GBs at the diskpools,
but that is no help if we can't get the data off the disks in a timely
manner. If we could get the offload to both the copypool and the local
library to take place on multiple drives I think our plan could succeed.
Can anyone shed any light on how we might achieve our aims?

Kind regards,

Hagen Finley
Longs Drugs