ADSM-L

Re: TSM SERVER MIGRATION from STK ACSLS tape library to IBM 3584

2006-03-28 16:58:55
Subject: Re: TSM SERVER MIGRATION from STK ACSLS tape library to IBM 3584
From: Laura Mastandrea <lmastand AT CHOOSEBROADSPIRE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 28 Mar 2006 15:55:55 -0600
Thank you.





                                                                         To
         ADSM-L AT VM.MARIST DOT EDU
                                                                         cc

                                                                       From
                                                                    Sent by

           "Allen S. Rout" <asr AT UFL DOT EDU>  on  03/28/2006 08:48 AM
           "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
                                                                    Subject
         Re: [ADSM-L] TSM SERVER MIGRATION from STK ACSLS tape library to
         IBM 3584

           Please respond to
        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>










>> On Tue, 28 Mar 2006 11:32:19 +1000, Steven Harris
<steve AT STEVENHARRIS DOT INFO> said:

> Here is one way to do a gradual migration.

Superb advice.  I'd suggest one embellishment:

Set up the new primary stgpools, and the new-primary->new-copy
housekeeping at the outset (step 2) .  Then, set the old-primary
stgpools to have RECLAIMSTGPOOLS of the corresponding new-primary.

This takes one usually very heavy use of tape drives, and contributes
its' efforts to the migration.  It introduces the possibility that
something might get written to old-primary, and then reclaimed to
new-primary before it gets copied to old-copy, but that doesn't seem
particularly likely, and the data in new-primary -will- get copied to
new-copy.




> 1. Set up your new library and devclasses to use it.

> 2. set up a new set of copypools parallel to your old set of copypools,
and
> run backup stg commands on all your primary pools until the copypools on
the
> new library are up to date - this may take weeks, depending on how much
data
> is to be copied, but can be stopped and restarted as necessary. Change
> housekeeping to copy new data to both new and old copypools. If you are
> using 5.3 parallel processing commands watch for the limit of 16 parallel
> commands at once.

> 3. Once the copypools are caught up, you can change your housekeeping to
> stop copying data to the old copypools.

> 4. create a new set of primary pools to parallel your old setup.  Change
> your diskpools to migrate to the new primary pools.  Change your
> managementclasses that go straight to tape to point to the new primary
> pools.  Change your housekeeping to backup the new primary pools to the
new
> copypools.

> 5. Make the nextstg of each of the old primary pools to be its new
> equivalent.  Run migration on the old pools to move the data off to the
new
> pools. The new migrate stg command with a duration will drip feed this
over
> time.

> 6. Finally, when everything is copied, run del vol on each of the old
> copypool volumes (discardd=yes will be needed) and any old primary pool
> volumes (discardd=no) that need it, and clean up old definitions.



- Allen S. Rout





DISCLAIMER:
This communication, along with any documents, files or attachments, is intended 
only for the use of the addressee and may contain legally privileged and 
confidential information. If you are not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of any information 
contained in or attached to this communication is strictly prohibited. If you 
have received this message in error, please notify the sender immediately and 
destroy the original communication and its attachments without reading, 
printing or saving in any manner. This communication does not form any 
contractual obligation on behalf of the sender or, the sender's employer, or 
the employer's parent company, affiliates or subsidiaries.