Andy, Regarding the point made below about writing 100GB exchange files on smaller VTL volumes, you are probably aware of this but you could make use of the maximum size threshold parameter on the VTL storage pool. Any data whose size matches or exceeds the threshold will be sent straight to the next storage pool in your architecture preferably the physical tape pool thus alleviating the load on the VTL and avoiding large data spanning across multiple VTL volumes.
In our environment, each of our TSM servers is configured as its own VTL Library (We allocated a certain number of expandable VTL volumes per server in the VE for Tape Console and checked them in TSM); the VTL pool sits between the disk and tape pools; we defined maximum size thresholds on our disk and VTL storage pools. The only tape contention issues we encounter on rare occasions are concurrent migrations and storage pool backups needing the same volume; they are quickly resolved either by letting the server negotiate the priority between the processes or by canceling one of the processes and initiating at a later time. I hope you work out your issues with the VTL Andy. BERTAUT TCHUISE Storage Support Administrator Legg Mason Technology Services *410-580-7032 [email protected] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Huebner,Andy,FORT WORTH,IT Sent: Tuesday, July 07, 2009 3:21 PM To: [email protected] Subject: Re: [ADSM-L] VTL Tape Size The top problems we are trying to solve are tape contention and utilization. Contention is a little troublesome from time to time. Utilization is why we did some testing to the extreme of 10GB volumes. There are some very interesting points: >> I think your volume size should be something fitting the data type >> going into the storage pool. Putting 100GB exchange db files on 10gb >> volumes or 1kb files on 100GB volumes doesn't seem efficient.<< Object size is a little hard to define. We have big DBs to millions of tiny files. >> Some considerations: - This varies with the different VTL vendor's, but some had a maximum number of Virtual Tapes that was allowed in the system, which would argue for larger volumes. - On the other hand, smaller volumes reduce the amount of reclamation you have to do (depending on your data) - If you ever want to export to physical tapes, you might want to just use the same size that you are emulating. I.E. 400GB for LTO3>> I had not considered the number of slots in the emulated library. There is no chance of the VTL moving data to physical tape, our libraries are not supported. >>If you try to provide virtual sequential access mount points for each >>client session you may need during client processing, you will likely >>need much more system resources to complete nightly backups.<< We are currently using the VTL's, so the overall design of the storage pools and what goes where and when it goes there is running smoothly. We go to disk first except for the large objects. >>Another thing to think about is, have you sized the virtual library to >>have enough capacity for all your primary storage pool needs, or will >>the primary pool have to migrate to real tape?<< We have already seen the spanning tape problem with backup storage pool and have a procedure to handle that. That is annoying. The VTLs are large enough to hold the primary copy, but they are approaching their maximum capacity. >> We make use of "expandable" virtual volumes with an initial size of >> 5G and a max size of 60G and it works well in my opinion.<< We tried expandable or capacity on demand, but found that we generally fill the tapes so all we gained was an ambiguous scratch tape count. We do have compression on; we average nearly 2:1. The leaning here seems to be in the 50GB range. Thank you for the responses so far. Andy Huebner 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. IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you.
