The only catch in the whole scenario is support on Sun.
This option is listed as valid in 3.1.2.x+ options for AIX, but not for
Sun. Hence, it appears they are dropping support for (what used to be)
their own hardware (3494/3590 combos) on non-AIX hosted platforms, but
don't have the TSM SAN drive sharing support for AIX yet (but that wouldn't
do me any good anyway).
If I had a clue as to what they were thinking when they released this
support, I'd be alot better off. As it is, it appears the right hand knows
not what the left hand is doing. In the meantime, customers that invested
in the software technology and the library hardware technology look to be
hung out to dry.
That's okay though. Veritas supports the config I'm speaking of. And to
tell you the truth, we've waited long enough to have a valid drive sharing
config on any of our platforms. We have AIX, Sun and HP servers, but only
one type of library: 3494 with 3590s. What's harder: replacing all your
libraries, or all your software? Both aren't fun, but the new
installations require drive sharing, period. We have over 80 3590B/E
drives in 15 libraries in three different datacenters attached to over 17
ADSM servers.
If they don't deliver - and soon, I'll be signing off of here in 1 year.
We can't wait any longer for them to catch up.
David
Sheelagh Treweek <sheelagh.treweek AT computing-services.oxford.ac DOT uk> on
02/16/2000 02:54:32 AM
Please respond to Sheelagh Treweek
<sheelagh.treweek AT computing-services.oxford.ac DOT uk>
To: dmhendri AT fedex DOT com
cc: ADSM-R AT VM.MARIST DOT EDU
Subject: Re: Tape Sharing?
Hi David,
[Discussion moved to requirements list ... ]
You don't need the 3.7 features in order to share drives in the 3494.
As I understand it there are no plans to implement those features for
sharing SCSI libraries on the 3494. The 3494 can already be shared by
multiple *SM servers - you assign different categories for each server
for private/scratch tapes : I'm sure you know this already.
Now, the 3590/3590E drives can be shared at 3.1.2.x when you have the
microcode which includes the 'autoshare' features and when you turn
on the new ADSM server option "3494SHARED YES".
However, although this enables you to take some advantage of the 3494s
ability to share a library running multiple *SM servers and to share
the 3590 drives, the sharing is as yet not quite intelligent enough -
or so I have found when I have been expermenting with this recently.
[Of course, the drives need to be cabled to each of the servers,
either using the dual-host features (or maybe SAN Data Gateway?).]
For example, if you have rmt1 on server A and rmt1 (same unit) on
server B and you do 'update drive 3494lib rmt1 online=yes' then each
*SM server can access the drive. The usual round robin algorithm
comes into play and when a tape mount is needed the drive can be used.
When it is in use on A the drive appears to be 'offline' on B.
This is where the difficulty lies if server B wants also to access the
drive. It cannot tell the difference between 'offline/busy' and
'offline/broken' (or whatever). The end result on server B trying to
allocate the drive is that it can fail to queue for a mount point and
instead just fails the request to mount. This behaviour is different
from *SMs normal behaviour when if a drive was just busy, it would
(for many operations) queue for the mount point.
It may be that the microcode could be made to tell *SM better what the
drive was doing and then *SM itself could be more intelligent in its
drive sharing. It may be desirable for the administrator to be able
to tell *SM explicitly that a drive was being shared?
It may then be possible to further enhance the selection criteria when
mounting tapes - you might want to have 4 drives exclusive to A and 2
shared with B; you might want to say mount on an 'exclusive' drive in
preference to mounting on a 'shared' drive when available resources
permit. This would give some chance of load balancing?
This is a subject that I have been interested in for quite some time
and I am pleased that we are on the way to getting the (for us)
expensive 3590E resources shareable across *SM servers. I'd be very
interested in knowing what others would think on this subject?
Just for the record we currently run 2 ADSM servers (H70, R40),
sharing a 6-frame 3494 with 10 3590E drives. We split them 6:4 and
would like to at least share 2 drives across the server. I also have
a 3.7 test server which is connected to the same 3494 and can access
just 2 of the drives; it is on this and one of the others I have been
experimenting a little; it isn't really usable in production when it
can fail requests in the manner described.
In the future we may well run more servers/drives - and intelligent
sharing would be very nice for us. Especially if the *SM servers were
handling different work profiles and there could well be times when
drives are idle on one and could be used on another.
The other disadvantage I would see in going with the 3.7 LM sharing is
that you introduce a single point of fail for all servers in tape
mounting; if the LM server goes down, then tape mounting stops on all
TSM servers. It needs some failover to another server - but that may
be too complex to be worthwhile?
Thanks, Sheelagh
------------------------------------------------------------------------
Sheelagh Treweek Email: sheelagh.treweek AT oucs.ox.ac DOT uk
Sheelagh Treweek Email: sheelagh.treweek AT oucs.ox.ac DOT uk
Oxford University Computing Services Tel: +44 (0)1865 273205
13 Banbury Road, Oxford, OX2 6NN, UK Fax: +44 (0)1865 273275
|
