ADSM-L

Re: [ADSM-L] How to figure collocation overhead

2009-01-15 13:55:42
Subject: Re: [ADSM-L] How to figure collocation overhead
From: Wanda Prather <wanda.prather AT JASI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 15 Jan 2009 13:53:38 -0500
Collocation consumes as much of the library as you tell it to.

When you set MAXSCRATCH on a storage pool, TSM will confine the pool to that
number of tapes.  If you have less tapes available than you have clients,
you get a "do the best you can" collocation.

There are plenty of sites who have more clients than slots in their library.

If you have 100 clients and set MAXSCRATCH for the pool to 50 tapes, TSM
will put each client on a different tape until it hits 50, then it will
double up.

You still get a decent amount of collocation; it's a lot faster for a
restore to skip over another clients data on the same tape, than it is to
rewind, dismount, mount, and reposition to a different tape.

What you have to remember if you are collocating, is that you have to check
your pools periodically and reevaluate maxscratch for the pool.  If your
total amount of data is growing, you will need to up the maxscratch
periodically so that you maintain enough available free tapes in the pool to
provide a reasonable level of collocation.

W

On Thu, Jan 15, 2009 at 1:34 PM, Evans, Bill <bevans AT fhcrc DOT org> wrote:

> Is there a guide or rule of thumb for determining what collocation will
> do to library space?  It is being considered for improving restore
> speeds.
>
> I'm backing up 80TB in 30 volumes(filespaces) on a solaris server.
> Currently there is no collocation set, all data goes to a long-term
> management class, single onsite and off-site tape pools, data churn
> averages < 1TB/night.
>
> Using a 650 slot L700 library, LTO3, TSM 5.5, AIX 5.3.  The library is
> >80% full, so, I'm concerned that starting collocation for the volumes
> will consume the rest of the library.  Each filespace collocation may
> end up with one tape not full (or 30 in this case).
> Thanks,
> Bill Evans
> Research Computing Support
> FRED HUTCHINSON CANCER RESEARCH CENTER
>