Maybe this will help... What we did with our CDLs and we are happy with it: - We defined a Scalar i2000 tape library - 8 SDLT tape drives in each VTL (2 CDLs per TSM server(long story)) We did eight drives in library because we calculated that would be about all our hardware could handle when doing Backup Storage pool to our physical 3590E drives. It is never a good idea to starve an actual tape drive. We wanted a different virtual tape drives so we would not have any driver version conflicts with the physical tape drives. - 100GB cartridges. The consultant said that was a good size, it works and we did not try any other sizes.
We backup to disk pools unless the file is greater than 2GB. This was little slower to tape because of the stops and starts. We do compression on the CDL and get nearly 2:1 on average. This makes VTL better than straight disks. We let TSM do all data movement. We do not have the CDL do any tape to tape copies. A backup takes the path of: Host --> AIX_Disks --> CDL All copy tapes are physical tapes. Each TSM server moves about 2TB per night. When we added the CDL's, we "simply" changed where our primary tape pools where and waited our retention period for attrition to reduce the primary tapes, then moved the rest to the CDL. Reclaiming to a different pool is a really nice feature. This config may change when we do our server refresh this year. Andy Huebner -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Joni Moyer Sent: Friday, June 08, 2007 2:02 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] How to Incorporate a CDL into TSM environment? Hi Everyone, I have 1 question about the order of the steps that I must take to fold the CDL into an environment where I will still have a disk storage pool, but will migrate the data to the cdl and hold it there for 30 days before moving it to physical tape media. (Which in my case is LTO2.) Here is what I have planned so far when we implement this: Define CDL library (Emulating IBM 3584) Define path from the server to the CDL library Define drives (Emulating LTO2) Define drive paths Define device class for LTO2 Define primary storage pools with hi=90, lo=70, migdelay=30, next=tape stgpool Label tapes: label libvol library_name search=yes checkin=scratch volrange=A00000,A00203 Update the disk storage pools so that they have a next storage pool directed to the cdl storage pool After this point I'm a little confused as to when migrations & the backups of the pools should be done and in what order. So, for example: AIX --> disk stgpool AIX_CDL --> cdl sequential access stgpool AIX_TAPE --> sequential access stgpool LTO2 AIX_COPY --> offsite stgpool LTO2 Would I do the following? I guess I'm getting a little confused on exactly what order of operations would be best? Client bkups to AIX pool After 24 hrs. migrate AIX pool to AIX_CDL pool Backup stgpool AIX_CDL to AIX_COPY Backup stgpool AIX to AIX_COPY Migrate data to AIX_TAPE after 30 days Backup stgpool AIX_TAPE to AIX_COPY Also, I have heard that you can turn compression on at the CDL drive level. I have purchased an EMC CDL 4400. Would it be best to turn compression on at this level? Or is it possible to define the device class with ultrium2c instead of just ultrium2? Or should I just turn TSM client compression on the larger servers such as Oracle databases and Lotus Notes? I don't want to have too negative of a performance impact, but yet I can't afford to not compress anything... I'm trying to wrap my brain around this whole concept and the best methods/practices to use the CDL. Any thoughts/opinions are greatly appreciated! ******************************** Joni Moyer Highmark Storage Systems, Storage Mngt Analyst III Phone Number: (717)302-9966 Fax: (717) 302-9826 [EMAIL PROTECTED] ******************************** "Prather, Wanda" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 06/08/2007 02:25 PM Please respond to "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To ADSM-L@VM.MARIST.EDU cc Subject Re: How to Incorporate a CDL into TSM environment? You go John! (And a BIG ditto on the compression rate issue - I've NEVER had a customer that got 3:1 over the whole TSM environment.) And let's step back a minute for a sanity check and ask, what IS a VTL anyway? It's disk with some cache and software in front. So if you need to back up 20 TB of disk, why not do as Kelly says and just buy another 20 TB of disk? Answer: In most cases, people buy a 20TB VTL because it's cheaper than adding another 20 TB in their disk array of choice. Why do you think that is? Is it because the vendors are really nice guys? Well, they may be really nice guys, but it's not because they want to give disk away. It's because the VTLs are built of A LESS EXPENSIVE KIND OF DISK. The cheaper disk is slower. Using cheaper disk, the VTL vendors have made it practical and cost effective to eliminate tape backups, FOR SOME CUSTOMERS. When people say they can back up or restore with a VTL faster than tape, it may mean 1) they are replacing slow tape drives 2) they are eliminating tape mount times 3) they no longer have to wait for a tape drive It doesn't mean there aren't cases where tape is faster. There are cases where a VTL really rocks. My favorite is using a VTL for OFFSITE storage and backing up to it directly over fibre. In case of a major problem, you aren't limited in the number of tape drives you have available for restore (you ARE still limited by the size of your fibre pipe). You don't have to physically move tapes around, and the media never leaves your control (If I never spend another minute doing a manual audit looking for misplaced tapes...etc.). And you don't have to collocate in a VTL, since there is zero effective tape mount time. And it is a good solution for people who want to do more Lan-free backups, and are short of tape drives. But you should be buying a VTL for one of THOSE reasons, not for raw speed. You can always create a scenario where you get down to the actual device speed of the underlying technology and hit that bottleneck. Many people never run into that scenario. But some do. Also, FWIW, tape is still cheaper per MB of storage than a VTL. There are price points where they are comparable, or where the benefits of a VTL outweigh the cost differential. But in general, the larger your site in terms of TB to store, the more difference you will see in cost if you go with a VTL vs. tape, with tape still being lower. You gotta first know what you are trying to do, THEN figure out where your bottlenecks are, THEN figure out what technology matches your need and fits your budget. Wanda (I think I'm done for the day now and I'm sure glad it's Friday) Prather ________________________________ From: ADSM: Dist Stor Manager on behalf of Schneider, John Sent: Fri 6/8/2007 1:00 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: How to Incorporate a CDL into TSM environment? Greetings, A lot of the chatter about VTL's being good or bad seems to stem from which vendors you listen to, and what they are trying to sell you. There are a lot of dogmatic statements made by people on both sides of this issue, usually by people with no personal experience about what they are talking about. Somebody has fed them a sales line and they dutifully parrot it back. EMC sold their CDL product for about two years before IBM entered the market. During that time you would not believe how many times I heard IBM pooh-pooh the CDL saying it wasn't a good fit for TSM, didn't perform well, whatever they had to say to compete against it. I even heard someone recently say it was against the law to use a CDL if you used the IBM drivers to talk to it. Against what law exactly? Then after two years IBM came out with their VTL the TS7510, and almost immediately came out with a Redbook about it with a TSM chapter explaining why the TS7510 was such a good fit for TSM! Huh? And not because it was a better product than the EMC one, it was actually slightly slower and only scaled to about a fourth the size of the largest EMC VTL. The only difference is that now IBM had something in the marketplace, and that changed everything. As Wanda has said, a lot of the distinctions fall down to how you use the VTL, and if your expectations are set correctly. It is easy for a vendor presentation to promise the moon without qualifying it's claims. A single-engine DL4100 from EMC can sustain a 1100MB/sec (3.7 TB per hour) write speed like they claim IF: 1) You are writing multiple simultaneous virtual tape streams (like 16 or more), 2) You balance the I/O across at least 4 FC streams coming in the VTL engine, 3) You have at least 5 or more disk drawers to spread out the I/O load. 4) You are not compressing at the VTL engine. If you compress at the VTL engine, your performance will drop off, perhaps as low as a third as fast. This is because the compression is done in software. If you want hardware compression, go with one of the DL6000 series that has an optional hardware compression engine. But the presentations only say 1100MB/sec performance, and so customers install one, set up a single backup to a single virtual tape drive, and when it pegs at ~100MB/sec they think they have been lied to. The other complaint I hear a lot is the claim of 3:1 compression. Almost every vendor puts that in their literature as if it is a solid fact, and not a typical value. I had a customer once get so mad they almost yanked the whole box out and made the vendor take it back because they bought a 10TB VTL, which they sized on the assumption of 3:1 compression. Never mind that the compression they were getting on their existing LTO tape library was on 1.2:1, they were told the VTL would do 3:1, so it should. I had another customer almost throw out IBM because they bought 12 new 3592 tape drives, and they wouldn't perform anywhere near their rated performance. Never mind the fact that data was coming in through a single GigE connection, and the 12 tape drives had an aggregate throughput rating at about times that. Customers looking to purchase any tape or disk technology would be wise to ask questions about how performance numbers were achieved, and look at their own situation to see what results they should expect. Best Regards, John D. Schneider Sr. System Administrator - Storage Sisters of Mercy Health System 3637 South Geyer Road St. Louis, MO. 63127 Email: [EMAIL PROTECTED] Office: 314-364-3150, Cell: 314-486-2359 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Prather, Wanda Sent: Friday, June 08, 2007 10:56 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] How to Incorporate a CDL into TSM environment? ...I understood restore performance suffered with a VTL - the way it has been described to me is that, should a restore need to come from a volume that has been destaged from disk to tape in the VTL, then a restore of a single file from the volume would first have to wait for the vtl to rebuild the tape on disk? Or have I got the wrong end of the stick? Um. Both. Most VTL's are disk-only devices that emulate tape, and do not have the staging issue you describe. Many VTL's will make restores FASTER because the tape mount time goes from potentially minutes to a second or less. (You also don't have to worry about collocating data in a VTL, so your migration times are generally faster as well.) Now that goes with a caveat - you have to PIN YOUR VENDOR TO THE WALL and get documentation about throughput rates. ALL VTL's work about the same way, but they all have different hardware inside the box, so you can get drastically different results. You can easily create a case where restoring 1 VERY LARGE file will take longer on a slow VTL than with fast tape (Say a TS1120, which run get more than 100MB/sec.) It depends on WHICH VTL you are talking about, the speed of the disk in it, the size of the cache in it the speed of your SAN connection and/or HBAs compared to which tape drive, and whether you are talking about restoring lots of little files or a few huge ones. A VTS (don't they make this confusing?) is an IBM-only mixture of disk/tape that emulates tape. It has to pull data off tape and stage it back to disk before you can restore. Normally the VTS is used in a mainframe environment. IBM also makes VTLs, the TS7510 and TS7520, for use in open environments. They are all disk. This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.