That's what collocation does.
Without collocation when migrating the data from primary storage to storage
pools TSM will just right to the current tape, fill it up, mount another.
With collocation it writes to tapes in the collocation group (if space is
available), or mounts a scratch tape (if one is available).
So the cost is more mounts during the creation of copypool volumes, but the
benefit is when you are in DR mode.
TSM keeps it collocated only if you set your definitions for collocation.
It's defined when you set up the storage pool:
--+-----------------------------+--+---------------------+----->
'-COLlocate--=--+-No--------+-' '-REClaim--=--percent-'
+-GRoup-----+
+-NODe------+
'-FIlespace-'
Larry Clark
----- Original Message -----
From: "Park, Rod" <rod.park AT TYSON DOT COM>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Tuesday, March 17, 2009 3:04 PM
Subject: Re: [ADSM-L] volumes in a collocation group?stg
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.
|
