List,
An addendum: The client has now performed the change (it's been my first day back onsite with them since working through the planning with them) and they report that it all went swimmingly. From what I've seen there's now a happy co-existence of LTO2 and LTO4 drives and LTO2 and LTO4 media within the same logical (IBM 3584) tape library - LTO2 media is getting mounted into LTO2 or LTO4 drives for R/O activities, LTO2 media is getting mounted only into LTO2 drives for R/W purposes, and LTO4 media is mounted only into LTO4 drives for R/W operations. Simple operational procedures have been updated (e.g. an update to their Q_SCRATCH script to returns how many scratch tapes there are of each media type etc). They may well be keeping some LTO2 drives and media in this configuration for a while longer for generation of their offsite volumes – as long as the capacity figures and support for this make sense, it means they’re not having to shell out on a whole load more LTO4 media up front (which ‘aint cheap) before they need to. Thanks again to the list for your help in reassuring me that this should (and does) indeed work well. I’ll report back in case I hear of anything else on this. David Mc London, UK From: David McClelland [mailto:david.mcclell...@networkc.co.uk] Sent: 23 March 2009 18:06 To: 'Bill Smoldt'; 'ADSM: Dist Stor Manager' Subject: RE: [ADSM-L] Fwd: [ADSM-L] Mixing LTO2 and LTO4 drives and media in the same library 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:smo...@storserver.com] Sent: 23 March 2009 17:19 To: david.mcclell...@networkc.co.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.mcclell...@networkc.co.uk> Reply-To: <david.mcclell...@networkc.co.uk> Date: Fri, 20 Mar 2009 05:39:28 -0600 To: <ADSM-L@VM.MARIST.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@VM.MARIST.EDU"mailto:ads...@vm.marist.edu] On Behalf Of Baker, Jane Sent: 20 March 2009 08:19 To: ADSM-L@VM.MARIST.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@VM.MARIST.EDU"mailto:ads...@vm.marist.edu] On Behalf Of Wanda Prather Sent: 19 March 2009 20:54 To: ADSM-L@VM.MARIST.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.mcclell...@networkc.co.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.12.0/2068 - Release Date: 19/04/2009 20:04
