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
BTchuise AT leggmason DOT com




-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Huebner,Andy,FORT WORTH,IT
Sent: Tuesday, July 07, 2009 3:21 PM
To: ADSM-L AT VM.MARIST DOT EDU
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.