> We have 2-TSM servers acting at Library Managers/Owner, thus each LM has
> its own "3494 category codes", each owns n-3592 drives, etc. This was
done
> for redundancy, fail-over, etc. We have tape drives spinning most of the
> time so having all library functionality and drives attached to only
1-TSM
> server is not a good idea.
Here is our config. It may not answer your direct questions, but show how
we designed and set things up.
- We have two 3584, one at each of our data centers.
- We do not have the 3584 HA feature (HA frame with 2nd robot).
- Each tape drive is singly attached to the san.
- The SAN that has the tape drive spans the datacenters.
So all tape drives are visible to all TSM servers
at both data centers.
- Each is configured as one library (A virtual lib via ASLM, but
there is only one. We wanted to allow for future virt libs,
but haven't needed them.)
- Each library is serviced by one library manager, since there is
only one virt lib in each.
- Since there is only one virt lib, all tape drives are assigned
to it, as are all tapes.
- Each library manager handles it's library for ALL TSM instances
from both data centers. PRI pools and copy pools are defined
to different libraries, so offsite tapes are written to what
looks like local tapes, but are in fact at the other datacenter.
We are fortunate to have the interconnect to allow this.
- The library manager TSM instances are dedicated to this task.
- The virt libs have two tape drives defined with control paths.
One SMC device (AIX) is defined to TSM, while Atape provides
multi-pathing.
- The SAN for the tape drives spans the datacenters, so all TSm
instances at both data centers have access to both library
managers and all tape drives.
- All TSM instances have access to all tape drives.
So as you can see, the driving design of our setup was that
every tsm instance has assess to every tape drive in both
libraries. This allows for very efficient use of the drives.
When we've have major library problems where an entire library is
down, and we've had several of these, we have scrambled to add
disk space to the staging disk pools to keep backups running.
Our Oracle databases are (supposedly) configured to have
archive areas big enough to hold 24 hours of logs, just in case
TSM is down that long.
What you describe, splitting the lib into two virt libs is good,
but it depends on what you are trying to protect against.
> Do I define 2-virtual libraries, 1-per library manager server?
What are you trying to protect against?
- An entire library outage?
- A frame being out?
- A robot going down? (do you have the HA feature?)
- A library manager being down?
- TSM having problems and being down?
- The library manager server being down?
- The tape drive san being down?
- Are you using dual san connections of the tape drives?
If so, are they on separate san's, or at least
separate switches?
Walk through the pieces/parts of your design and ask
what happens if any one piece goes down. Then two pieces,
then 3 . . . .
>Does this
> mean the drives as well as storage cells are defined/associated to each
> "virtual library"?
>
Drives are assigned to a virt lib. But, If you check the
3584 Operator Guide you will find a way to setup and allow
a tape drive to be shared between partitions, but no info
on how it's used.
> Since I have never dealt with the issue of a tape drive "path" being
used
> for library control path/function, I guess I need to define more than
one
> of these paths, in case the drive has a problem?
Yes, you should define at least 2 drives with control paths. And, that
would
be per virt lib. So if you have 2 virt libs you would have 4 drives
defined
with control paths. (at least that's my understanding, but then I've
never
done this)
Rick
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
