Actually, depending on the model of the VTS there are performance issues. Even a B18 has only about 35MB/sec throughput if I remember correctly. Think about it for a minute. These are ESCON connected. ESCON has a lot of white space. You are lucky to see 9+ MB/sec per path. There are only four on the original B18 and less on other models. BE CAREFUL.
Now, the B20 is a horse and performance is probably not an issue. Plus it supports 8 pathways and FICON soon if it already doesn't. But, I am with everybody on this. A VTS is really not a good place to send general TSM data. -----Original Message----- From: Jeff Connor [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 11:58 AM To: [EMAIL PROTECTED] Subject: Re: TSM and VTS - virtual volumes Zlatko, I don't thing there is a performance issue writing TSM data to a VTS. The reasons you probably would avoid sending TSM data to a VTS are: 1. With a VTS, you get your biggest "bang for the buck" with applications that typically do not fill an entire tape. Many mainframe applications typically do not create individual files that fill entire tapes. That means with a VTS, the physical space occupied by each logical volume is only as big as the individual dataset. Sure some jobs stack one file after another to fill a tape but many jobs usually do not. Applications like DFHSM and TSM will keep appending to a tape until it is completely full. If they can fill a high capacity tape, like a Magstar tape, then why not create them on a "native" 3590 versus in the VTS? The main idea behind the VTS is to fill tapes for applications that are not designed to do it on their own or to basically fill your high capacity tapes as much as possible. 2. Since virtual volumes are removed from the VTS disk cache on a first in first out basis, depending the average disk cache life of your virtual volumes, many of your TSM tape mounts could result in "backend" physical tape mounts to recall the logical volume back to disk so TSM could append more data to the tape. Generally workload that generates lots of VTS backend tape mounts might not be best for the VTS and can lead to a condition IBM calls thrashing. It can depend on things like your workload, number of backend drives, etc. 3. The VTS performs reclamation in the similar manner to TSM. Over time, as logical volumes expire, when a stacked(physical 3590 VTS tape) has only a few "good" logical volumes left, those logical volumes are eligible to be moved to another stacked volume to be sure the 3590 tapes are filled to capacity. You set a reclamation threshold just like in TSM. Now imagine a scenario where stacked volume 999999 has two logical volumes left on it, 100000 and 100001, and 999999 is now eligible for reclaim. Logical volumes 100000 and 100001 are moved to stacked volume 999990 and 999999 is now a scratch volume for the VTS. This operation required two of your VTS backend drives to move the logical volumes from one stacked volume to another. Now say 10 minutes later, logical volume 100000 happens to be a TSM volume and it only has 20% valid data left. Volume 100000 is now eligible for reclaim so TSM asks for the volume and it is now recalled to the VTS disk cache so it can be used. The data is move from logical volume 100000 to 100002. Now TSM marks 100000 as scratch and now the space on stacked volume 999990 is free space. So basically what just happened is. The VTS moved a volume from one physical tape to another. Then TSM comes along shortly after and scratches one of the volumes we just moved. As you can see, a whole lot of physical mounts and recalls can result by putting TSM on the VTS. 4. Another thing to consider is, say you are doing a bare metal recovery of a large client and nearly all the VTS tape volumes are no longer in the VTS cache. Your restore would have to wait for each tape to be recalled from the stacked physical tape to the VTS cache before TSM could use the tape in the restore. This could theoretically increase your restore elapsed time. Hope this helps, Jeff Connor Niagara Mohawk Power Corp Zlatko Krastev/ACIT <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 12/06/2001 09:53:28 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: TSM and VTS - virtual volumes If VTS is artifically configured TSM server backend this leads to another question - virtual volumes performance. We read recently on the list that TSM using VTS is having not so good performance. Is this true or not I cannot prove and cannot have clear opinion. But virtual volumes are by definition TSM server backing up to TSM server. And if TSM-TSM performance is good why not TSM-VTS (i.e. TSM) performance be good? And how we can define "good" or "better" or "average"? If TSM-VTS is performing "not so good" is TSM-TSM having similar performance (measured in GB/hour or something similar)? If both perform at comparable speeds can we say both are "not so good" or TSM-TSM performs better? Sorry for asking so many questions. I have no mainframe (and VTS) to answer them by myself. Zlatko Krastev IT Consultant Michael Bartl <[EMAIL PROTECTED]> on 03.12.2001 10:48:11 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: TSM and VTS I remember from an IBM presentation a few years ago that the technology behind VTS is TSM. So using a VTS library on a TSM server means stacking the same intelligent tape management technology for two instances. This can eliminate some of the benefits. On one hand, when collocation is "inactivated" by VTS, access performance to your data may drop. On the other hand, VTS uses quite a lot of disk caching to improve performance. It depends on the structure of a TSM servers data, whether the gain or loss in performance will be stronger. Best regards, Michael -- Michael Bartl mailto:[EMAIL PROTECTED] Office of Technology, IT Germany/Austria Tel: +49-89-92699-806 Cable & Wireless Deutschland GmbH. Fax: +49-89-92699-302 Landsberger Str. 155, D-80687 Muenchen http://www.cw.com/de Bill Mansfield wrote: > > The fact is that TSM does not always write tapes 'til they are full. If > you have a bunch of small nodes using collocation or backupsets, you can > wind up with a lot of expensive tape with little content. Using the VTS > would allow you to stack these nearly empty tapes onto one tape. I'm not > sure whether this defeats the purpose of collocation, since I'm not sure > that the virtual tapes will stay collocated inside the VTS, though. > > _____________________________ > William Mansfield > Senior Consultant > Solution Technology, Inc >
