Using one now and love it. Works great - one of the best LTO library
choices on the market in my opinion. Very
clean, modular expansion path (compared to, say, STK) and very reliable
performance so far. Even if you don't choose
IBM for the library, I recommend their drives, as they're native
fiber...I've read a lot of problems on this list
about SCSI->Fiber bridges. If you have the cash/infrastructure, an
all-fiber design really cuts down on the potential
headaches.
The 3584 has a few non-obvious features:
- all the WWNs for the fiber drives are tied to the slot, not the drive.
This is very cool if you need to
replace a drive, because the WWN doesn't change. So you can bind the
numbers without having to worry about
rebinding/rebooting if you ever have to replace a drive.
- ejects queue in the robot. So if you're using something like bpvault and
ask it to eject 50 tapes and your
CAP only has space for 30, they'll queue up at the robot (the first 30
eject, you take them out, close the CAP,
and the next 20 are put in, etc.) This is great for coordination with
operators...with some other vendors,
anything after the first (number of CAP slots) eject commands are ignored or
fail.
- you can talk to the library over IP via web browser, etc. to get status
information.
However, there are some gotchas. For one, IBM's documentation assumes that
you're going to set it up as a
TLD robot talking over fiber to the robot control host. Well, what if you
want to have a dedicated master that's
the robot control host and media servers using drives within it? The IBM
literature suggests that the robot
control is over IP, but that's not the case - the control is over one of the
fiber paths to the drives - you pick
which drive (or drives) are the control path and your robot control host
talks to the robot over that fiber line.
Or perhaps you can control it as a TLH robot...that configuration has a
hostname field, so perhaps you can control
it over IP. However, we control ours over fiber. Unfortunately, IBM's
documentation is not clear.
I recommend not using the 3.4 GUI's "device wizard" - its on-screen
documentation is flat-out wrong (you CAN have
a robot control host that doesn't control drives), it does capricious things
with your existing configuration, and
Veritas technical support recommends against using it ;) However, adding
the robot as a TLD robot is just like
adding any other TLD: sgscan, add the robot, map the drives, etc.
Another gotcha is to make sure your barcode label vendor knows the library
you're buying so you get the right labels.
And then call Veritas and ask them to send you documentation on the
MEDIA_ID_BARCODE_CHARS entry in vm.conf, otherwise
your barcode of 100101L1 will read as 0101L1 instead of 100101.
IBM's strength is not Netbackup (which is not surprising, since they sell
TSM). However, once the initial install is
done, it's just like any other TLD robot. robtest, etc. still work...other
than changing the robot number, all of our
old scripts (based on STK DLT library) worked fine on the 3584.
There are some NB experts in IBM if you dig for them. E-mail me off-list if
you decide to go the IBM route and want more details or would like to
compare notes.
--
Drew Fabbro
fabbro.andrew AT cnf DOT com
Desk: 503-450-3374 Cell: 503-701-0469
"There is no such word as 'maturity'. There
is only 'maturing' and 'dead'." -- Bruce Lee
|
