>>> 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.
I don't have this luxury. 5 of my 7 production servers do not have any
external/SAN disk - only what the Dell x86 server came with.
>>> 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.
We have everything from Oracle to Notes to MS-SQL to MySQL database systems
and many of them are fixed on disk/logging space, thus the demand on the
TSM servers being there to empty logs....
>>> Are you using dual san connections of the tape drives? If so, are they
on separate san's, or at least separate switches?
Again a luxury I don't have. All tape drives have 1-fibre attachment.
Don't have enough switches to go beyond that. Currently all on one
SAN/fibre - supposed to be getting a new switch that will give me more
ports but no redundancy.
>>> 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.
How is TSM setup to use "virtual drives" - my current understanding is that
Drives are defined to a Library and Paths connect the Library and Drives to
a TSM server. The Library Manager (drive owner) server delegates the drives
it "owns/manages" to a TSM server that needs it. So, how would a virtual
drive move from one TSM server to another if the TSM server that "owns" it
is down, without redefining the paths/drives to another Library Manager?
Are all drives defines/assigned to multiple Library Manager servers?
>>> 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)
I've meant to ask - how does the library appear to the TSM server OS? Is
it /dev/smc0,1,2,etc or /dev/IBMchanger0,1,2,etc?
On Tue, Apr 23, 2013 at 1:05 PM, Richard Rhodes <rrhodes AT firstenergycorp DOT
com
> wrote:
> > 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.
>
--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
|
