ADSM-L

Re: [ADSM-L] volumes in a collocation group?stg

2009-03-17 14:54:56
Subject: Re: [ADSM-L] volumes in a collocation group?stg
From: Larry Clark <lclark01 AT NYCAP.RR DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 17 Mar 2009 14:54:13 -0400
Yes, the underlying problem is they are not collocated and they have
experienced delays because of:
- multiple platforms requesting the same volumes concurrently
- multiple servers on the same platform requesting the same volumes
concurrently
- too many mounts to restore a server
hence collocation, which is not "cheating" but using the features of TSM to
address
volume contention and wait times on mounts. A mechanical mount that takes 3
minutes is a lot of time if your data is spread across 30 volumes versus 10:
20 x 3 x #number of servers.
Larry Clark



----- Original Message -----
From: "David E Ehresman" <deehre01 AT LOUISVILLE DOT EDU>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Tuesday, March 17, 2009 2:39 PM
Subject: Re: [ADSM-L] volumes in a collocation group?stg


That's cheating.  If your DR test restore times are unexceptable you need to
address the underlying problem because you don't get to prep for real
disasters!

Larry Clark <lclark01 AT NYCAP.RR DOT COM> 03/15/09 2:48 PM >>>
Hi Alex,
Yes, this is related to improving restore times in a DR senario...so these
are offsitevols from a copypool.

Larry Clark
(518) 712-5138 Home Office


----- Original Message -----
From: "Alex Paschal" <apaschal AT MSIINET DOT COM>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Sunday, March 15, 2009 2:37 PM
Subject: Re: [ADSM-L] volumes in a collocation group?stg


Hi, All.

The critical piece that Larry mentioned is that he's interested in a
copypool.  If your primary pool is collocated by anything, but your
copypool is not collocated at all, then your copypool data will be mixed
up with no regard for collocation groups.

Nick, if you really want to mix data on tapes (I have no idea why you
would want to, but the beautiful thing about TSM is you can do nearly
anything you want), the first way I can think of is to temporarily
reduce MAXSCRATCH (or temporarily disable collocation), set to
Unavailable the volumes you do _not_ wish to write to, then issue move
[node]data.

Alex


________________________________
Alex Paschal
Storage Solutions Engineer
MSI Systems Integrators
________________________________

Your Business.  Better.



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Nick Laflamme
Sent: Sunday, March 15, 2009 5:42 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] volumes in a collocation group?

On Mar 14, 2009, at 10:23 PM, Larry Clark wrote:

What you say is curious..............only nodes that are in a
collocation
group should have data on the volumes in that collocation group. At
least
that is my understanding.

Your saying more than one collocation group can store data on the same
volume?

I know for collocation by node that would not be true............

Paul already mentioned the scenario in which TSM has to put a a
collocation group member's data on a tape that has data from another
group on it, due to resource constraints. You can get similar results
if a node's collocation group membership changes from one group to
another. In that case, data stays where it is, meaning the tapes now
contain data from two groups on them, even though TSM behaved exactly
as predicted.

I keep wondering if there's a way to mix groups' data on a volume
using MOVE DATA or MOVE NODEDATA, but since neither lets you specify a
target more exactly than a storage group, I haven't seen how yet.

Larry Clark

Nick


This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.

Thank you.

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