VTL Solutions Used

[dhcolesj]

What VTL Vendor / Solutions do you use with TSM?

• Sepaton
• FalconStor
• IBM
• SUN
• EMC
• Exagrid
• DataLink
• NetApp
• Other

 

[PJ]

None whatsoever. Our management forced us to waste loads of time evaluating a bunch of them because of all the bling on powerpoint they've been attacked with by men in dark suits - and we ended up with what we could have figured out up front. VTL and TSM do not play. If you want LAN-free because you need the performance, a VTL won't help because its slooooow compared to the tapes you could buy for half the money - and if you don't do LAN-free, its utterly pointless anyway.

PJ

 

[janecb]

We use EMC VTL for all of our remote copy pools and do not have an issue with performance. In my previous job we used them for all Databases and Domino servers, and the performance on backups and restores were outstanding..

Janecb

 

[Mikey D]

Emc Dl4206

 

[PJ]

...and the performance on backups and restores were outstanding..

Compared to... what?

PJ

 

[OKTSMGURU21]

We are using a Sepaton VTL for all of our AIX server backups, and I have not quite understood the PROS and CONS of having it.

Been trying to get some insights from this forum,.....but.....

 

[Rob Roy Hathaway]

SEPATON Experience

I have had considerable direct experience implementing SEPATON VTL into TSM environments and can offer a firm testimony that, given appropriate FC connections, it beats the speed delivered from any physical tape I have yet seen. I have used Many generations if IBM, plus HP LTO, DLT, and STK tape.

One problem with discussions of tape speeds is that there are many, many, different tape architectures and generations deployed and in use. The fastest I can compare Sepaton to is the Sun/STK T10000... it compares favorably.

I have used other VTL solutions, and can understand concerns about speed with some of them. With some VTL implementations, there are no UNDERLYING enhancements to the speed limitations of cheap SATA trays and vanilla filesystems behind the scene. Sepaton has created their own filesystem with a very large allocation "chunk" size. That, combined with automatic load balancing across all spindles optimized for sequential I/O can deliver a lot of speed.

Above and beyond raw speed, however, there are additional advantages to VTL in general. It is an order of magnitude more reliable than physical tape. Mount times, and tape positioning seek times are eliminated. Virtual tape drives are free and almost unlimited, (with SEPATON anyway), so you can cost-justify extension of LAN-Free to more clients. Finally, it is easy to use as a "drop-in" replacement for your ageing tape library which can then be relagated to non client visible tasks such as backup stgpool for your DR.

One possible pitfall, benchmarking VTL in general with TSM, is relying on TSM reported throughput numbers from a single small backup across the LAN which has been redirected to a VTL. It will likely show no or little difference to ANY VTL as it is bottlenecked at the LAN and includes both selection list processing and catalog update overhead in it's calculation. Benchmark VTL against workloads that can really stream to tape or VTL. Use a migration process for example... or a large selective, image, or TDP backup.

In the interest of full disclosure, I should point out that I am currently under contract to SEPATON and providing TSM implementation services for them to numerous large TSM customers. The last 8 months of my professional life are a firm testament to the fact that VTL and SEPATON in particular... DO play well in TSM environments. I'd encourage you to check out SEPATON at www.sepaton.com

Irrespective of my obvious bias... I encourage you to dig into the various VTL implementation performance specs and check them all out. VTL has the potential to quickly solve a LOT of backup and administrative scheduling constraints I have encountered over the years.

Bottom line, it is totally unfair to characterize VTL as slow.

Rob Roy Hathaway
TSM Implementation Consultant to SEPATON
Glasshouse Subcontractor

 

[PJ]

I said slow when compared to the tape drives you can buy for half the money and I do stand by that. We have not tried a Sepaton but I'd be surprised if it could reverse our experience with other VTL solutions. We use LAN-free for large databases only - mostly R/3 with oracle, exchange etc. Simply keeping them on disk (more than a PB) would be incredibly expensive and I seriously doubt any VTL solution could come close to the thruput/price relation we achieve using LTO. We're talking about 60-80 MB/s/drive and linear scalability. What would a Sepaton solution cost, that delivers >3GB/s real thruput and holds a Petabyte? How much energy (primary+cooling) will it require?
For all the incremental stuff, nothing will beat a large chunk of SATA plus copypool on tape unless you somehow get the disks cheaper when you add VTLs to them

PJ

 

[[email protected]]

We wanted to use Diligent ProtecTIER - but like someone else on this post , we wasted our time and eventually the management revealed the reason why we did not get anywhere - outsource on the way !!

I have to say the Diligent solution was very impressive on price, flexibility, ease of installation and deduplication factor.

 

[dhcolesj]

So, you're telling me you can make tape perform in TSM so fast that they equal the speeds of disk, and 1200 Virtual tape drives? I'm having a difficult time accepting that. The seek time, and mount times, as well as the number of drives you'd have to buy, along with the size of the server(s) with the number of Fibre cards would seem to make this possible, but that's a lot of infrastructure. However, I'd say this may be possible if you have the right size of files, and types of data. The problem comes in with a multitude of small files spread out across a multitude of tapes. I just can't see tape drives equaling disks in speed. Price yes, speed no. But, I leave open the possibility that I could be completely wrong, I'm just using my experience with tape drives.

 

[PJ]

I agree. Small files do handle a lot better on disk than on tape. However you don't need a VTL for that. Disk (Random Access and Sequential File) can be attached directly to a TSM Server. Obviously you can't access it via SAN from the client (unless you use sanergy - which would be a bad idea for everybody who hasn't developed an affinity to untraceable errors) but why would you? Small files don't gain anything from transferring LAN free anyway. I still have to see a LAN free incremental - no matter which device it goes to - beating the LAN to a random access diskpool using maximum resource utilization. At least our fileservers where actually slower to VTL via SAN than to RA Disk via GB Ethernet. Considering how LAN free works with TSM, I wouldn't expect it any other way.

PJ

 

[javajockey]

I really don't see why it is necessary to buy a VTL. We have had an Apple XSAN in production for 4 years.
So far, there has not been a single drive failure. The hardware is rock solid. I really don't see what a VTL solution will buy you. Tivoli just needs some place to create containers. It will handle the VTL on it's own.
Simply buy any SAN solution and use tape for you Copypool. I have to agree with PJ on the spped xfer rates though. LTO-4 is much fater than spinning media!! If you run reclamation, that should cut back on your small file problems. If you run out of space, simply order more tapes. I will always trust tapes over hard disk to prevent data corruption. I still have tapes in use that are 7 years old. They are LTO-1, but they sill work.

 

[GavinR]

We've looked at a few VTLs, and they are very similar under the covers. The EMC, IBM, SUN & Copan offerings are all based round the same FalconStor engine. The only exception I've seen is the NetApp machine.

We have a couple of EMC DL4100s at the moment and no complaints about perfromance (though we have turned off the software compression).

 

[shcart]

Ibm

Its Management tool is a bit flaky, Updates are none concurrent, No I dont use it for lanfree yet, but probably will.

Whoever wrote the code had an interesting way of handling tape creation. Example
Specify VLIB tape range AB0000 - AB5999
Then when you create the first 50 tapes it creates AB5000-AB5049
You have to go through hoops to get the other AB0000-AB4999 volumes

They could also do with the ability to reclaim space other than the first block for empty volumes. But that would need TSM to scratch the volumne and the library to understand it was scratched. Bring back 3494 emulation all is forgiven.

Basically it was bought to help with mount point issues because unlike simple disk pools it allows me to maintain parallelism for DB backups to keep recoveries as fast as possible.

Thus far its been reliable and not overly difficult to learn.

I would say though that it is still in need of a serious final polish to make it production ready for the average Admin rather than the 'TSM Geek' crowd who probably still reminisce about backups on 2400' reels and installing ADSM 8" floppy disks (**** did they ever release it in that format).

 

[PJ]

Could you not achieve the same thing - only cheaper and a lot more flexible - using sequential file?

PJ

 

[ALT-G]

I have used a plain EMC Clariion for years utilizing the FILE dev class in TSM which auto performs volume management. Last week EMC was in showcasing their VTL solutions and stated that they are based on Clariion technology. The ONLY benift that I was able to determine was the claimed ability to perform hardware compression through drive emulation on the new VTLs, where on my regular Clariion I have client side compression forced. However, contrary to the warnings of a heavy client-side footprint, all my testing has shown that the impact is VERY minimal.
Not sure if management is going to make the leap and purchase it?? But if they do I will try to report back with an evaluation.....
~Rick

 

[josh597]

Dl4100

EMC DL4100 and works great!

Instead of running move data scripts all day, just let reclaim run as normal.

The EDL was a life saver.

 

[PJ]

EMC DL4100 and works great!

Instead of running move data scripts all day, just let reclaim run as normal.

The EDL was a life saver.

Care to elaborate, why you didn't use "reclaim as normal" before?

PJ

 

[redmerlin]

We wanted to buy NetApp but management decided for us that Hitachi was the way to go..... it was not.

 

[josh597]

Care to elaborate, why you didn't use "reclaim as normal" before?

PJ

The problem was that we had more data expiring from tapes than could be reclaimed by a single reclamation process per storage pool reclamation. Reclamation ran constantly (24 hours a day) on all our storage pools and never finished unless we changed the threshold.
So in running multiple reclamation processes we ended up using more tape drives (which we didn't have the luxury of using since disk storage pools were full and trickling over to tape storage pools during the day). What made this even worse is that we were running collocation on several storage pools (even more tapes to reclaim). We just didn't have enough drives, scratch tapes, room in the library or time.

VTL fixed this by allowing us to use as many tape drives as we needed for reclaim.

Hope this info answered your question.