ADSM-L

Re: migration processes with collocation groups

2006-04-23 20:28:23
Subject: Re: migration processes with collocation groups
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sun, 23 Apr 2006 20:27:41 -0400
>> On Sun, 23 Apr 2006 13:52:50 -0500, Roger Deschner <rogerd AT UIC DOT EDU> 
>> said:

> The only solution is policy. (Quick! Grab the Aspirin!) Put it in
> its own copygroup etc, or even its own server image, and then turn
> off collocation completely for it, so that it can migrate on more
> than one drive at once, while still maintaining the desired
> collocation effect. I have discovered (in a real disaster) that,
> despite collocation, such a client is perfectly happy restoring from
> more than one tape drive at once, which is a good thing. Made for a
> very fast restore of an entire huge filesystem, much faster than an
> image restore of the same filesystem.

Yeah, the ideas of collocation start to break down when your
unit-of-collocation is substantially larger than a tape.  I've got
that big-time on my machines which are still on 3590Ks, some of which
back up more than two tapes' data a few days a week.

> Properly deployed, TSM policy should let you do what you really want
> - define a collocation group that can have multiple migration
> processes.  Just beware - it won't be easy!

The biggest reason I haven't even attempted something like this is
that I'm still using DISK stgpools for my landing pad, not FILEs.

FILE stgpools can share free-space; DISK stgpools can't.  So if I want
9 different policy classifications coming in, I need 9 pools all
allocated at peak.  Ew.

Getting off DISK and onto FILE is on my list of stuff to do Real Soon
Now.


- Allen S. Rout

<Prev in Thread] Current Thread [Next in Thread>