ADSM-L

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

2009-03-23 14:07:16
Subject: Re: [ADSM-L] Fwd: [ADSM-L] Mixing LTO2 and LTO4 drives and media in the same library
From: David McClelland <david.mcclelland AT NETWORKC.CO DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 23 Mar 2009 18:05:34 -0000
Hi Bill,

 

Many thanks for feeding back with this. 

 

(Why do things like this always come through and scare me like that right at
the end of my day in the office just when I’m getting set to head home...!)

 

The APAR suggests 5.5.2.0 and 5.4.4.1 and above are currently affected by
this issue (and perhaps as a result of the IC54738 fix from my reading of
it) – it’s Windows TSM 5.4.3.2 onsite here now (migrating to AIX TSM
5.5.1.1), so I think they’ll just about dodge underneath this issue I
reckon. 

 

The mixed LTO2/4 media/drives is a config they’ll be running for (to the
current plan) about 5 weeks before the wholesale migration to LTO4 drives
and read only LTO2 media.

 

Many thanks,

 

David Mc

London, UK

 

From: Bill Smoldt [mailto:smoldt AT storserver DOT com] 
Sent: 23 March 2009 17:19
To: david.mcclelland AT networkc.co DOT uk; ADSM: Dist Stor Manager
Subject: Re: [ADSM-L] Fwd: [ADSM-L] Mixing LTO2 and LTO4 drives and media in
the same library

 

David,

While I understand that this works in specific circumstances, we’ve had
significant problems with your specific combination.  The problem we
observed will occur with a current release of TSM server and any two-level
gap in LTO generations and the right circumstances.  You may want to wait on
implementation until you are running a TSM version which contains the fix
described in APAR IC59691.  Unless you can live with that feature.

HYPERLINK
"http://www-01.ibm.com/support/docview.wss?uid=swg1IC59691"http://www-01.ibm
.com/support/docview.wss?uid=swg1IC59691

-- 
Bill Smoldt
VP Research & Development
STORServer, Inc.
719-266-8777 x7103



   _____  

From: David McClelland <david.mcclelland AT NETWORKC.CO DOT UK>
Reply-To: <david.mcclelland AT networkc.co DOT uk>
Date: Fri, 20 Mar 2009 05:39:28 -0600
To: <ADSM-L AT VM.MARIST DOT EDU>
Subject: Re: [ADSM-L] Fwd: [ADSM-L] Mixing LTO2 and LTO4 drives and media in
the same library

(War and Peace again - sorry):

Thanks for all of your responses both on and off list. I've put some feelers
out elsewhere on this too (many thanks if you're reading) and have had some
interesting and contradictory responses!

In summary, there do seem to be some folks out there running with exactly
the proposed config below (i.e. LTO2 and LTO4 drives and media in the same
logical/physical library, LTO2 used purely for offsite media generation)
and, provided parameters such as MOUNTLIMIT are set carefully (as well as
separate devclasses and stgpools of course), it is a happy configuration
without undesired LTO2 > LTO4 cross pollination.

The 'Implementing IBM Tape in Unix Systems' Redbook is an excellent read and
talks about this configuration in one of its examples (going against my
reading of the TSM Admin Guide):

"As of Tivoli Storage Manager V5.3.5, LTO4 drives are supported, and any
combination of LTO 2, 3, and 4 drives and media can be used in one library
[...] Although LTO4 drives can read the LTO2 media (but cannot write to it),
care should be taken to avoid attempted writing. Set the MOUNTLIMIT option
for the LTO2 devclass to less than the sum of LTO2 and 3 drives (see the
previous tip), thereby preventing the LTO2 media from being loaded in the
LTO4 drives. The LTO2 media will still be available for normal use by the
LTO2 [and 3] drives.

"['Previous tip' - relates to different scenario but the point is still
valid] Setting the MOUNTLIMIT parameter: For read or write tape mounts,
Tivoli Storage Manager will select LTO3 drives for LTO3 media first. If no
LTO3 devices are available, an available LTO4 drive will be selected for the
LTO3 media. To prevent the case where all LTO4 drives are loaded with LTO3
media (leaving no drives available to read/write LTO4 media), set the
DEVCLASS parameter MOUNTLIMIT appropriately. "

The above is from section 5.11.1 of the Redbook.

Given the headache of repartitioning the 3584 library from its base config
into two partitions without ALMS
(HYPERLINK
"http://www-01.ibm.com/support/docview.wss?uid=swg21145429"http://www-01.ibm
.com/support/docview.wss?uid=swg21145429 gives an
indication of this), its inherent inflexibility plus extra work required
during the migration activity itself, I'm inclined to think that the single
partition library solution above is the way to go after all. I would also be
able to perform a good deal of the TSM Server work (defining devclasses,
stgpools etc) prior to the migration weekend, de-risking the change
somewhat.

That's how I'm looking at the moment - many thanks again for your thoughts.

/David Mc
London, UK



-----Original Message-----
From: ADSM: Dist Stor Manager [HYPERLINK
"mailto:ADSM-L AT VM.MARIST DOT EDU"mailto:ADSM-L AT VM.MARIST DOT EDU] On 
Behalf Of
Baker, Jane
Sent: 20 March 2009 08:19
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Fwd: [ADSM-L] Mixing LTO2 and LTO4 drives and media in
the same library




We have a 3584 with LTO2 & LTO3 which we use via logical partitioning,
it works really well so would recommend that?

As said previously as long as you have separate device classes and
control paths neither will intermix.




-----Original Message-----
From: ADSM: Dist Stor Manager [HYPERLINK
"mailto:ADSM-L AT VM.MARIST DOT EDU"mailto:ADSM-L AT VM.MARIST DOT EDU] On 
Behalf Of
Wanda Prather
Sent: 19 March 2009 20:54
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Fwd: [ADSM-L] Mixing LTO2 and LTO4 drives and media in
the same library

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
>
>


Please check that this email is addressed to you. If not, you should delete
it immediately as its contents may be confidential and its disclosure,
copying or distribution unlawful.

C. & J. Clark International Limited takes steps to prevent the transmission
of electronic viruses but responsibility for screening incoming messages and
the risk of such transmission lies with the recipient.

C. & J. Clark International Limited Trading as Clarks Registered in England
number 141015.
Registered office 40 High Street, Street, Somerset. BA16 0EQ. England.

This message has been scanned for viruses by BlackSpider MailControl -
www.blackspider.com


No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.11.18/2009 - Release Date: 18/03/2009
07:17


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

 

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.11.18/2009 - Release Date: 18/03/2009
07:17


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