The big difference between using TSM library/client architecture vs. letting
the TS3500/ALMS do it, is whether you want to share DRIVES between TSM
instances.

If you just use ALMS partitioning, drives have to belong to one library
partition/TSM instance or the other at any given point in time.  The TSM
instances share the robot arm, the I/O door and (normally) the open slots,
but not the drives.  (you can move drives back and forth manually between
library partitions, but it ain't automatic and it ain't convenient.)

If you use TSM library/client architecture, one of the TSM's is the owner of
all the drives.  All the instances can share access to all the drives.
They all make nice with each other sharing and scheduling drive use because
the library owner instance is the traffic cop.

That is a more powerful feature than what ALMS gives you.

VIO can be nice, IF You are moving more cartridges in a day than your I/O
door can hold (which most people don't, with 3592 carts).  And I don't
remember actually how ALMS enforces separation of the partitions by
instance, but it does (if nothing else, each TSM uses one control point that
is defined on a drive, and each drive is in only 1 partition).  For TSM vs.
a non-TSM application to share the library, ALMS is certainly necessary.

But in your case, it depends on exactly what you are trying to achieve.  If
you are happy taking a drive away from your production server, a library
partition created with ALMS should be sufficient, and is very easy to do on
the fly.

W




On Mon, Aug 17, 2009 at 3:46 PM, Keith Arbogast <warbogas AT indiana DOT 
edu>wrote:

> I understand that Advanced Library Management System (ALMS) can be
> used to create logical libraries within physical ones, consisting of
> drives and volser ranges.  But, how does ALMS control access to those
> logical libraries by servers and applications?  What in ALMS allows
> Server A, but not Server B  to access logical library N?  I haven't
> found a description of that in the 3584 documentation.
>
> If a 3584 is accessed ony TSM Library Clients what benefit does
> ALMS offer besides virtual I/O?  I don't mean to undervalue virtual I/
> O, but what role can ALMS play in managing a TSM-only shared library.
>
> We have a TS3500 with 3592-E05 drives, and are running TSM 5.5.3 on
> RHEL.  We are planning to take a drive away from the Production TSM
> server and give it to a test server to verify library/drive
> connectivity on a new server build.  Do I need to setup a Library
> Manager/Library Client architecture for that, or could ALMS do the
> refereeing?
>
> Thank you,
> Keith Arbogast
>