ADSM-L

[ADSM-L] Fwd: [ADSM-L] Mixing LTO2 and LTO4 drives and media in the same library

2009-03-19 17:03:07
Subject: [ADSM-L] Fwd: [ADSM-L] Mixing LTO2 and LTO4 drives and media in the same library
From: Wanda Prather <wprather AT JASI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 19 Mar 2009 16:54:09 -0400
TSM does support mixing media in the library, but I believe you are correct
that with LTO2 + LTO4 drives and media, you will have a problem.

I've included the text from the 5.5 TSM Admin Guide for Windows below.  I
interpret it to say that there is no way to keep an LTO2 scratch cartridge
from landing in an LTO4 drive, and the LTO4 drive can't write to it and
problems will ensue.

You could indeed partition the library with ALMS.

But the way I've gotten around this before with is to simply create two
logical libraries in 1 physical library.  (This would be especially
convenient since you don't intend to keep this configuration very long.)
CAVEAT:  I have to say I haven't done this since TSM 5.3, so YMMV:

Create a new TSM LTO4 library.  Define the path for the library to point to
the lbx.y.z.q device that Windows sees (this will be a control path in the
library created on one of the LTO4 drives.  This is usually done by the CE,
but can be done easily from teh 3584 web interface.) Actually  I think the
path could also point to the original lba.b.c.d control point on the LTO2
drive, I don't think it matters.  Define the LTO4 drives to the new LTO4
library.

Your original library with the LTO2 drives will still exist just as it did
before.

Check in your LTO4 carts to the LTO4 library, make separate device classes
and storage pools with no mixed media between them.

The TSM server won't know or care that the 2 logical libraries only have 1
physical library.

Again, I haven't done this with TSM 5.4 or 5.5, so test it.  But it used to
work.

W
+++++++++++++++++++++++++++++++++++++++++++++++++++
Mixing Different Media Generations in Libraries

While the Tivoli Storage Manager server now allows mixed device types in an
automated library, the mixing of different generations of the same type of
drive is still not supported. New drives cannot write the older media
formats, and old drives cannot read new formats. If the new drive technology
cannot write to media formatted by older generation drives, the older media
must be marked read-only to avoid problems for server operations. Also, the
older drives must be removed from the library.

Some examples of combinations that the Tivoli Storage Manager server does
not support in a single library are:
v SDLT 220 drives with SDLT 320 drives
v DLT 7000 drives with DLT 8000 drives
v StorageTek 9940A drives with 9940B drives
v UDO1 drives with UDO2 drives

There are two exceptions to the rule against mixing generations of LTO
Ultrium drives and media. The Tivoli Storage Manager server does support
mixtures of the following types:

v LTO Ultrium Generation 1 (LTO1) and LTO Ultrium Generation 2 (LTO2)
v LTO Ultrium Generation 2 (LTO2) with LTO Ultrium Generation 3 (LTO3)
v LTO Ultrium Generation 2 (LTO2) with LTO Ultrium Generation 3 (LTO3) and
LTO Ultrium Generation 4 (LTO4)

The server supports these mixtures because the different drives can read and
write to the different media. If you plan to upgrade all drives to
Generation 2 (or Generation 3 or Generation 4), first delete all existing
Ultrium drive definitions and the paths associated with them. Then you can
define the new Generation 2 (or Generation 3 or Generation 4) drives and
paths.

Notes: 1. LTO Ultrium Generation 3 drives can only read Generation 1 media.
If you are mixing Ultrium Generation 1 and Ultrium Generation 3 drives and
media in a single library, you must mark the Generation 1 media as
read-only, and all Generation 1 scratch volumes must be checked out.

2. LTO Ultrium Generation 4 drives can only read Generation 2 media. If you
are mixing Ultrium Generation 2 and Ultrium Generation 4 drives and media in
a single library, you must mark the Generation 2 media as read-only, and all
Generation 2 scratch volumes must be checked out.

For a discussion of additional considerations when mixing LTO Ultrium
generations, see “Defining and Updating LTO Device Classes” on page 245.
Tivoli Storage Manager does support mixing of 3592 Generation 1 and
Generation 2 drives and media. However, to minimize the potential for
problems, use one of three special configurations. For details, see
“Defining and Updating 3592 Device Classes” on page 237.

If you plan to encrypt volumes in a library, do not mix media generations in
the library.
+++++++++++++++++++++++++++++++++++++++++++++++++++


On Thu, Mar 19, 2009 at 10:13 AM, David McClelland <
david.mcclelland AT networkc.co DOT uk> wrote:

> Hi Team,
>
> I’ve a question about mixing LTO drives and media in the same library –
> LTOn
> and LTOn+2.
>
> • Windows TSM 5.4.3.2 (soon to be migrated to a 5.5.1.1 server running on
> AIX)
> • IBM 3584 single frame library, presently with 4 x IBM LTO2 drives
> • Currently no library clients or storage agents.
>
> My client is looking to migrate from 4 x LTO2 drives to 8 x LTO4 drives in
> their 3584 library (as well as performing some other TSM Server platform
> migration activities).
>
> The LTO drive generation-spanning capabilities are such that LTO4 drives
> can
> read from but not write to LTO2 media; that LTO2 drives can read/write to
> LTO2 media, but will have nothing to do with LTO4 media.
>
> Now, for an interim period, it has been suggested that the library be
> configured with 5 x LTO4 drives and 3 x LTO2 drives. TSM Server and the IBM
> 3584 Tape Library are both stated to support mixed media and tape drives
> between these LTO generations.
>
> However, the idea behind this is that during this interim period, new
> incoming backup data should be written to LTO4 media by the LTO4 drives (as
> well as some existing LTO2 data being moved/consolidated onto LTO4 media),
> and that offsite copies only continue to be generated to LTO2 media using
> the LTO2 drives (various reasons for this, including maintaining media
> compatibility for DR purposes).  If possible, largely I think for
> flexibility, the preference is to achieve this within a single library
> partition.
>
> It’s this last bit that I’m having trouble getting my head around.
>
> Obviously, a new device class (FORMAT=ULTRIUM4C) will be added to the TSM
> Server to make use of the LTO4 drives (making sure that the current LTO2
> device class is locked down to FORMAT=ULTRIUM2C), as will a new set of LTO4
> storage pools pointing to this new device class. However, with both of
> these
> drive types being located in a single library partition I don’t quite see
> how they’ll be able to make sure that only LTO2 scratch tapes get mounted
> into LTO2 drives and that LTO4 drives don’t go trying to write to LTO2
> media. Is it simply a case of manually allocating the LTO2 scratch media to
> the LTO2 copy storagepool (and setting its MAXSCRATCH to 0), and ensuring
> that LTO4 is the only media in the general scratch pool? Will TSM ensure
> that, given we’re explicit in our device class definitions, when a backup
> stgpool operation requests a mount of an LTO2 scratch volume (or indeed an
> LTO2 filling volume) to perform a write it’ll only mount one into one of
> the
> LTO2 drives, and similar for LTO4 media and drives? I suspect not...
>
> Is anyone running with a similar configuration to this (if it’s possible)?
>
> Of course, the other blindingly obvious option is to partition the 3584,
> creating one library partition for the 3 x LTO2 drives and enough slots to
> manage the offsite requirement, and another for the 5 x LTO4 drives with
> the
> remainder of the carts. The client doesn’t have ALMS for quick flexible
> library partitioning (I don’t know about the cost of this feature, but I
> expect that they’d be unwilling to consider it for only an interim period)
> so we’d have to use more rigid non-ALMS partitioning method. This option
> appeals to me in that it’s pretty simple to get my head around, but perhaps
> requires a little more work to perform the library repartitioning.
>
> Any thoughts gratefully received!
>
> Cheers,
>
> David Mc,
> London, UK
>
> No virus found in this outgoing message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 270.11.18/2009 - Release Date:
> 18/03/2009
> 07:17
>
>