In <bitnet.adsm-l%0012900001025586000004*@MHS>, jlawson AT itthartford DOT com
(Jerry Lawson) writes:
>Date: January 26, 1996 Time: 07:53
>From: Jerry Lawson
> ITT Hartford Insurance Group
> (203) 547-2960 jlawson AT itthartford DOT com
>-----------------------------------------------------------------------------
>First - I want to thank all of you who responded to my earlier "Storage
>Management 101" question. I'm now ready to move on to a harder issue!
>
>We have decided that we need to split up am existing storage pool setup (and
>associated management classes) into two separate pools. This is being done
>primarily because of changes we need to make in how tapes are managed, but the
>net effect will be a separation of our existing large pool into two pools; one
>for servers, and one for desktop machines. Thanks to the earlier answers, we
>now have the new pools setup on our MVS Server. (Both pools will be on the
>same server.)
>
>Now for Storage Management 102:
>
>It appears that there are 3 ways to do this:
>
>1. We can run Export/Import and move everything associated with a node from
>one pool to another.
>
>2. We can use the GUI interface, and simply change the Policy Domain that a
>node is assigned, giving it a new Policy Domain in the new pool.
>
>3. I can change the Backup definitions for a Policy Domain, substituting the
>new pool name for the old one. This would do all the nodes in a Policy Domain
>at one time, as opposed to the above method, which is by node.
>
>I have concerns about what happens with all of the above three methods. The
>first one (Import/Export) seems to have a lot of overhead associated with it
>that might be unnecessary, since we are not really moving anyone off of the
>server - just within pools. It appears that I can control the assignment of
>the node to a new Policy Domain and/or Storage pool with this method; however,
>since these are server backups, and we use 3480 tape, there are many, many
>tape volumes associated with each node.
>
>The second and third choices seem much better suited to my needs, since we are
>staying on the same server. I ran a test of the second method, and it looked
>to be reasonable efficient, with only a rebinding of the data to the new
>Policy Domain when the next incremental was run. However, it appears to me
>that I now have data spread across 4 storage pools - the DASD and Tape pools
>from the original Domain, and the DASD and tape pools from the new domain. Is
>this a problem?
>
>We have rejected Move Data as an option, since it works on a pool level,
>rather than a node level. I haven't got a clue which tape volumes are
>involved here, since there is no easy way to check which tapes contain data
>for which clients without listing the contents of each of the 600 tapes we
>already have in use.
>
>Have any of you tried to do this? Do you have a suggestion that I have missed
>or a better way of doing this?
>
>Thanks for your time - this was a rather long post.
>
>Jerry Lawson
>ITT Hartford Insurance Group
>jlawson AT itthartford DOT com
Is your current tape pool collocated? If it is the I suggest using move
commands if you must reorganize the tapes.
But moving the data isn't necessary as far as ADSM restores are concerned.
Restores will still work fine after
you move the nodes to a new domain even if you don't move the data.
To do the moves you need to identify what tapes are assigned to what nodes.
With any cmdline admin client do 'q vol' and capture the list. Edit the list
to make a macro with one line for each tape volume like this --
q con <volume_name> count=1
Capture this list and massaged it to find the volumes for the nodes you
are interested in. Then submit 'move data <volume_name> stg=<newtapepool>'
commands.
Good luck!
Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550
|
