I have been using file device class disk backups for the past 5 years via san storage and just have not been satisfied with the storage systems. I have asked others in this forum before whether they experience problems with san based storage when using TSM because TSM seems to push storage systems with such high amounts of I/O that the controllers cann't handle the speed very well and the controller hangs or even crashes regardless of the storage vendor. I also have totally threw out the idea of using a large san storage system to share amongst other servers and applications with TSM because TSM will hog the san storage controller and cause problems on the other attached systems. My main reasons for looking at VTL was speed I heard was very good pushing large amounts of data, it is a separate disk based storage system for TSM only to use and compression. My concern on the EMC VTL side is where the compression is being done? Is it software based compression or hardware based? Our IBM rep stated that IBM's TS7510 is currently using software based compression and using compression will tax the controllers cpu and actually recommended not to use it. He also said they are currently testing hardware based compression and will be coming out with the TS7510 using hardware based compression that will off load the cpu cycles from the linux management server onto an adapter and compression will be much faster and less taxing to the management servers.
The VTL systems just seem to be faster, more stable, allows compression so you get a bigger bang for you buck and manages like a tape library all give the VTL an advantage over device class FILE based storage. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of TSM_User Sent: Thursday, January 05, 2006 12:18 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: VTL experiences? Much of the documentation out there will tell you that the benefit of the VTL is the speed. It is true the VTL is very fast. Some of that same documentation talks about not turning on the virtual compression because it will slow the speed. I've seen in cut the speed in half. But... I've seen a VTL with Virtualized compression turned on still operate as fast as real tape. I make this point because I think you should use the virtualized compression. This way the same 5 TB's of disk space you were using for your file device class might yield 10 to 15 TB's or more of backup space under the VTL. True you could turn on client side compression. But, I like the compression being done on the back end so that there is no stress put on the servers that are backing up themselves. One thing I should also clear up. In my last post I mentioned IBM with SATA disk. I got a friendly reminder from EMC that the CDL's have been shipping with SATA disk since this past November. That also reminded me that the IBM VTL called the TS7510 is using the IBM DS line of disk which has been out for some time now. I remember EMC making the same note when it first came out with the CDL. See the disk subsystem's under both the IBM and EMC VTLs have been out for some time. So just like EMC correctly noted when the CDL first came out you should note today about the IBM TS7510. They really are not new products when it comes to the disk subsystem. In both cases you could choose to purchase the disk subsystems used by the VTLs directly from either IBM or EMC and use them with a file device class. Granted I realize that both EMC and IBM have a specific configuration of their disk subsystems that they put under their VTLs. In my own experience I've used a file device class with TSM V5.2 and earlier and an EMC CDL. I liked the CDL a great deal. We had the same class of EMC disk behind a clarion setup to use a file device class. The same amount of disk behind the CDL performed better. I believe part of the reason is the logic in the FalconStor software. It uses disk for its virtual tapes in 5 GB increments and uses logic to ensure it picks the least busy disk for the next 5 GB that is used. I know with V5.3 giving you the ability to write to multiple filespaces which could be on multiple LUNS gives you something over V5.2. I still think that cycling through separate LUNS though isn't as good as the way the VTL allocates in 5 GB chunks across many more LUNS. FalconStor may have a white paper on how they do it but I would encourage you to ask your vendor who ever it is to come on site and discuss this with you in greater detail. Whether you pick a VTL from EMC or IBM (or someone else for that matter), or you pick a disk subsystem with the file device class you must test yourself to see what will work best in your environment. I make no claim that a VTL is for everyone or that it will outperform real tape in every situation. I simply think it should be one of the things you strongly consider. More and more of us are seeing the benefit of moving small files off tape to disk but we may have been seeing 2:1 or 3:1 compression with those small files on tape. A 1:1 of disk can be costly but when you use virtualized hardware compression behind a CDL it may make things more cost effective if you get 2:1 or 3:1 for small files. "Allen S. Rout" <[EMAIL PROTECTED]> wrote: >> On Wed, 4 Jan 2006 14:42:29 -0600, "Dearman, Richard" said: > Anyone out there have any good or bad experiences with VTL solutions. I > was thinking about budgeting for 1 or 2 in order to phase out the > current san file system I am using for TSM disk storage. There are > several vendors out there with VTL solutions most notably IBM and EMC. > My first choice would be to choose IBM but it is a new product and EMC > has been in the market longer. Would you be willing to expound on why you'd prefer sticking disk behind a VTL volume virtualizer, instead of sticking it behind a DEVCLASS=FILE volume virtualizer? I would default in the other direction, so I'm interested in your thinking. - Allen S. Rout --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less **************************EMAIL DISCLAIMER*************************** This email and any files transmitted with it may be confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited. If you have received this e-mail in error, please delete it and notify the sender or contact Health Information Management 312.413.4947.