LTO4 drives will read, but not write LTO2 media.
Kelly Lipp
CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777 x7105
www.storserver.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Howard Coles
Sent: Thursday, March 19, 2009 1:52 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Mixing LTO2 and LTO4 drives and media in the same library
We do this with a mixed LTO3 and LTO2 drives. We did not partition the
library. However, I would highly suggest putting the smaller format higher in
the drive number list. DRIVE01 = LTO2 . . . DRIVE10 =LTO4. That will keep the
LTO4 drives available for LTO4 tapes, if LTO4 drives will read and write LTO2
tapes.
See Ya'
Howard
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of David McClelland
> Sent: Thursday, March 19, 2009 9:13 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Mixing LTO2 and LTO4 drives and media in the same
> library
>
> 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
>
|