ADSM-L

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

2009-03-17 15:05:23
Subject: Re: [ADSM-L] volumes in a collocation group?stg
From: "Park, Rod" <rod.park AT TYSON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 17 Mar 2009 14:04:35 -0500
Ok, we've never collocated our copy pools because I was under the impression 
that TSM consolidates each node to a small subset of tapes which in turn makes 
restores very fast/less mounts blah blah blah, but if you're writing out new 
backup data for each node from the night before out to a copypool tape, how 
does TSM keep it collocated? It seems like it would have to move that data 
around every day to keep a nodes data to a small subset of tapes and each day 
it would keep moving the same data and the next day's new data to another 
subset of tapes. Please correct me if I'm wrong and point me in the right 
direction because we do have the same issue at our DR test with multiple mounts 
and multiple nodes requesting the same tapes.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Larry Clark
Sent: Tuesday, March 17, 2009 1:54 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] volumes in a collocation group?stg

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.

This email and any files transmitted with it are confidential and intended 
solely for the use of the addressee. If you are not the intended addressee, 
then you have received this email in error and any use, dissemination, 
forwarding, printing, or copying of this email is strictly prohibited. Please 
notify us immediately of your unintended receipt by reply and then delete this 
email and your reply. Tyson Foods, Inc. and its subsidiaries and affiliates 
will not be held liable to any person resulting from the unintended or 
unauthorized use of any information contained in this email or as a result of 
any additions or deletions of information originally contained in this email.

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