If you are using 2 different NICs on the same physical server or two
physically different servers you can define your machine to the 3494 twice.
In this way, I would think the owner thing would be not required.  Just
CHECKOUT LIBVOLUME REMOVE=NO the ones from server A.  Do a checkout
libvolume of all on server B and then check them in STATUS=PRIVATE with a
new set of category codes.  You will need to have new category codes for the
new server.  What happens is the tapes that are not in the library are
ignored and will get marked "UNAVAILABLE" if they are attempted to be
mounted.  But what I would do in each server first thing is mark the tapes
belonging to the other server as "UNAVAILBLE" right off the bat with an
UPDATE VOLUME vvvvvv ACCESS=UNAVAILABLE any that are in a READONLY or
READWRITE state so they will not muck with each other's tapes.  OFFSITES are
not a problem at this time because they cannot be mounted anyway.

This is going to be tricky.  And, unless I actually tested it I would be
nervous there is something I did not consider.  Especially, the fact that
SERVER B is going to try to do stuff to the tapes immediately upon bringup.
But, this can probably be avoided if you mark all the tapes UNAVAILABLE
before you take the database backup.

Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180


-----Original Message-----
From: Cook, Dwight E [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 22, 2002 9:14 AM
To: [EMAIL PROTECTED]
Subject: Re: Server partitioning using TSM library sharing


Whew, being mighty bold but you ~might~ be able to get it to work... I'd do
everything with the library NOT available to the system, this MIGHT allow
you to clean out references to volumes not used on each system without
causing them to roll scratch. Even if you do this you will still need to go
in and alter the category of the tapes bind private volumes to the new
private category of which ever server you set new categories for (be it the
new one or the old one) That is, say your existing server is using 300 & 301
for private and scratch categories... your new/other server, you will need
to alter the private & scratch categories to somethings new like 400 & 401
for that you can use something like
        mtlib -l/dev/lmcp# -C -VABC123 -s012C -t0190
AND remember, just because you have collocation on doesn't mean the data is
fully isolated ! ! ! You still might have data from one node out on a tape
with data from another node.

About the only way you could test this would be to restore the DB to a test
server, delete all the data from one of your sets of nodes, then note all
remaining private volumes (make sure this box doesn't have access to the
library, and to be safe, I'd take it off the network while testing things).
Then restore the data base again and delete all the data from the other set
of nodes, then note all remaining private volumes. If those two sets were
totally unique, then your process (I believe) would work. If you had ANY
overlap in your sets of private volumes, you couldn't perform your task...
        you would have to do a move data against that volume to try to split
out the data on it and start over with your check. Logically, your process
~should~ work IF all data is really collocated but you will have to be very
careful...

Dwight



-----Original Message-----
From: Scott McCambly [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 19, 2002 3:27 PM
To: [EMAIL PROTECTED]
Subject: Server partitioning using TSM library sharing


Hello fellow TSMers,

We have a fairly large TSM server that we are planning to partition into 2
servers. In other words, add a second server and split the client nodes
across the two.

The hardware environment is two AIX TSM servers, both fibre attached to a 10
drive 3494 ATL.

What I am proposing to do (and looking for input) is as follows:

1) Restore a copy of TSM server-A's database to the new TSM server-B
2) Reconfigure the library and drive configuration on TSM server-B to be a
library client to the shared library manager server-A.
3) Identify the nodes that are to be associated with each server.
4) Identify the volumes associated with the nodes for each server (Storage
pools are currently fully collocated by node).
5) Run update libvol to change the owner on the appropriate tapes to be
owned by server-B.
6) Delete the filespace and node definitions for the nodes NOT associated
with each server.
7) Reconfigure half the nodes to point to the new server-B.
8) Pat myself on the back and take the rest of the day off :-)

It seems too simple....  Has anyone done this before? (hard to type with my
fingers crossed)

The big question of course is: what happens to volume ABC123 on server-A
when the filespaces are deleted and the volume empties, gets deleted from
the storage pool, and returned to scratch? Server-B still thinks there is
data on that tape and this proposed solution would only work if he was
allowed to request a mount and read that volume.

Any and all feedback is appreciated!

Scott
Scott McCambly
AIX/NetView/ADSM Specialist - Unopsys Inc.  Ottawa, Ontario, Canada
(613)799-9269

Reply via email to