Re: VTL Tape Size
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 btchu...@leggmason.com -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Huebner,Andy,FORT WORTH,IT Sent: Tuesday, July 07, 2009 3:21 PM To: ADSM-L@VM.MARIST.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
Re: VTL Tape Size
We are setup with the primary pools in the data center and the copies off-site. All of our primary data ends up in the VTL expect the NAS and DPM (Exchange) which go straight to physical tape. I am less concerned about the spanning issue because we have experience with it and most of the DBs that will span even with 100GB tapes are completed early enough not to be a problem. We have 4 VTLs, 1 TSM server is using a pair. The goal is to move to a 1:1 setup. With that change we are looking at changing the volume size and we are checking to see what others are doing and why to see if we missed any pluses or minuses of using smaller or larger volumes. It seems that 50GB is popular with some 100's and 200's, but no clear winner on why. It is nice to see that most at least have a reason why. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Tchuise, Bertaut Sent: Wednesday, July 08, 2009 8:00 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] VTL Tape Size 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 btchu...@leggmason.com -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Huebner,Andy,FORT WORTH,IT Sent: Tuesday, July 07, 2009 3:21 PM To: ADSM-L@VM.MARIST.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
VTL Tape Size
We are about to bring up new TSM servers and one of questions that has come up is how big to make the VTL tapes? We currently use 100GG and have tried 10GB with our test server. The question is what size it popular and why? 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.
Re: VTL Tape Size
Hi, 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. Regads, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Huebner,Andy,FORT WORTH,IT Sent: dinsdag 7 juli 2009 16:36 To: ADSM-L@VM.MARIST.EDU Subject: VTL Tape Size We are about to bring up new TSM servers and one of questions that has come up is how big to make the VTL tapes? We currently use 100GG and have tried 10GB with our test server. The question is what size it popular and why? 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. ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e m e s s a g e c o n t e n t . A l t h o u g h t h e s e n d e r e n d e a v o u r s t o m a i n t a i n a c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n i s v i r u s - f r e e a n d w i l l n o t b e l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m a n y v i r u s t r a n s m i t t e d . O n a l l o f f e r s a n d a g r e e m e n t s u n d e r w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s o f D e l i v e r y f r o m A t o s O r i g i n e x c l u s i v e l y a p p l y . T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y s u b m i t t e d t o y o u o n y o u r r e q u e s t . A t o s O r i g i n N e d e r l a n d B . V . / U t r e c h t K v K U t r e c h t 3 0 1 3 2 7 6 2
Re: VTL Tape Size
Andy, My experience may not map to the problem you are trying to solve, but I chose a relatively small VTL tape size (50GB) and have not regretted it. The trade-off is total number of virtual tapes vs total number of anticipated simultaneous tape mounts. Say you have a 60TB VTL (usable), and you want to emulate LTO4 tapes. If you went with the default size (400GB) you would have about 150 virtual tapes in your pool. Say also that there are 300 TSM clients to be backed up each night. Each one will need at least one virtual tape during their backups, and some of them might need 4 or 8 for performance reasons. You would have only 150 tapes for 300 clients? You could spread out their schedules, of course, but that will still be problematic. After a few weeks you might have a bunch of them full, but not ready to reclaim, or waiting on reusedelay, and not have enough available tapes for all the tape mounts you need. With 50GB tapes, you would have over 1200 virtual tapes. Tapes would fill up sooner, of course, but they could be reclaimed sooner, too, and be returned to scratch. Your overall disk utilization will go up. One thing to bear in mind is that if you have single files that are bigger than your virtual tape size, the file will have to span multiple virtual tapes. This is no problem for TSM, but it does mean that each of the virtual tapes involved in that one file will not be mountable until after that large file is finished backing up. We have seen the unusual situation where a single 300GB Exchange database was backing up, and happened to run over into our 'backup stgpool' window. The 'backup stgpool' was waiting on a tape mount of a certain volume, but when we checked we could see that the volume was not mounted or in use by anybody else. After some digging we noticed that the virtual volume in question had been mounted some hours earlier in a backup session for a single large Exchange file, and that backup was still going on. As soon as that file finished backing up, the virtual tapes mounted and the 'backup stgpool' continued. 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? If so, that is another argument in favor of relatively small virtual tapes, because they won't migrate until they are full. In our case, using the migration threshhold to cause the migration to occur didn't work well because of how TSM calculates percent full, so we ended up writing a script that automatically migrates (using move data) virtual tapes as they age, so that we are sure we always have enough scratch tapes for our next backups. Best Regards, John D. Schneider The Computer Coaching Community, LLC Office: (314) 635-5424 Toll Free: (866) 796-9226 Cell: (314) 750-8721 Original Message Subject: [ADSM-L] VTL Tape Size From: Huebner,Andy,FORT WORTH,IT andy.hueb...@alconlabs.com Date: Tue, July 07, 2009 9:36 am To: ADSM-L@VM.MARIST.EDU We are about to bring up new TSM servers and one of questions that has come up is how big to make the VTL tapes? We currently use 100GG and have tried 10GB with our test server. The question is what size it popular and why? 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.
Re: VTL Tape Size
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 ended up going with 200GB volumes for everything, and it seems to work well. I might consider something smaller if I was redoing it today. Regards, Shawn Shawn Drew Internet karel@atosorigin.com Sent by: ADSM-L@VM.MARIST.EDU 07/07/2009 11:06 AM Please respond to ADSM-L@VM.MARIST.EDU To ADSM-L cc Subject Re: [ADSM-L] VTL Tape Size Hi, 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. Regads, Karel -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Huebner,Andy,FORT WORTH,IT Sent: dinsdag 7 juli 2009 16:36 To: ADSM-L@VM.MARIST.EDU Subject: VTL Tape Size We are about to bring up new TSM servers and one of questions that has come up is how big to make the VTL tapes? We currently use 100GG and have tried 10GB with our test server. The question is what size it popular and why? 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. This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Please note that certain functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc. ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g
Re: VTL Tape Size
Andy, Just an opinion here. 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. Managing mount points need only be done during daily server maintenance processing. I would still be using a random access disk pool to provide staging space for client backups. The L in VTL stands for Library and it should be treated as such. For many years IBM has recommended that we back up to a staging area to enhance client performance and reduce resource needs. During server maintenance, data should be placed onto longer term storage devices (libraries) for daily expiration and reclamation processing.. I don't think that strategy changes with a VTL. On another not I have a client with a VTL running in a Windows environment with around 200 clients(not sure what you have). Their VTL vendor suggested a volume size of 20Gb. This eventually created ~15000 volumes. When the TSM server used the VTL, the overhead from mounting hoards of virtual volumes brought their server to its knees. I mean it would not even respond to session requests so it could not complete nightly client backups at all. Not to mention the headaches of managing 15000 volumes from the TSM interface (GUI or CLI). They too were trying to backup directly to the VTL during nightly client backups. We had to return there management class destinations back to a random access storage pool and process their data during daily sever maintenance as TSM is designed to do. We set up the VTL to emulate LTO2 (200GB volume size) and used the VTL like a library, migrating the nightly backup data to the VTL. Large Oracle backups do directly to the VTL but are limited in number. The client is fat and happy now, backing up ~1.5TB nightly with plenty of time left and the TSM server performance is stellar. Regards, Nicholas ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 07/07/2009 11:18:26 AM: [image removed] Re: [ADSM-L] VTL Tape Size John D. Schneider to: ADSM-L 07/07/2009 11:19 AM Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Please respond to ADSM: Dist Stor Manager Andy, My experience may not map to the problem you are trying to solve, but I chose a relatively small VTL tape size (50GB) and have not regretted it. The trade-off is total number of virtual tapes vs total number of anticipated simultaneous tape mounts. Say you have a 60TB VTL (usable), and you want to emulate LTO4 tapes. If you went with the default size (400GB) you would have about 150 virtual tapes in your pool. Say also that there are 300 TSM clients to be backed up each night. Each one will need at least one virtual tape during their backups, and some of them might need 4 or 8 for performance reasons. You would have only 150 tapes for 300 clients? You could spread out their schedules, of course, but that will still be problematic. After a few weeks you might have a bunch of them full, but not ready to reclaim, or waiting on reusedelay, and not have enough available tapes for all the tape mounts you need. With 50GB tapes, you would have over 1200 virtual tapes. Tapes would fill up sooner, of course, but they could be reclaimed sooner, too, and be returned to scratch. Your overall disk utilization will go up. One thing to bear in mind is that if you have single files that are bigger than your virtual tape size, the file will have to span multiple virtual tapes. This is no problem for TSM, but it does mean that each of the virtual tapes involved in that one file will not be mountable until after that large file is finished backing up. We have seen the unusual situation where a single 300GB Exchange database was backing up, and happened to run over into our 'backup stgpool' window. The 'backup stgpool' was waiting on a tape mount of a certain volume, but when we checked we could see that the volume was not mounted or in use by anybody else. After some digging we noticed that the virtual volume in question had been mounted some hours earlier in a backup session for a single large Exchange file, and that backup was still going on. As soon as that file finished backing up, the virtual tapes mounted and the 'backup stgpool' continued. 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? If so, that is another argument in favor of relatively small virtual tapes, because they won't migrate until they are full. In our case, using the migration threshhold to cause the migration to occur didn't work well because of how TSM calculates percent full, so we ended up writing a script that automatically migrates (using move data) virtual tapes as they age, so that we are sure we always have enough scratch tapes for our next backups
Re: VTL Tape Size
Andy, John D. and Mario raised good points. As for our VTL environment, we have a blend of IBM TS7520/7510 (3955 3954 Machine Types). 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. With Compression enabled, we get more out of each VTL volume without exposing ourselves to extremely long migrations, backups of the storage pools and other administrative processes. As a side note, the intersection between TSM and the VTL is a bit tricky, for instance, though we defined VTL volumes with a max size of 60G in the Virtual Engine for Tape Console, we get a different estimated capacity once the virtual volume are checked in TSM and being written to. See below for illustration. Volume Name Storage Device EstimatedPct Volume Pool NameClass Name Capacity Util Status --- -- - - X40025P_USER_VTL VTL2 126.5 G 91.1 Full X40050P_USER_VTL VTL2 180.0 G 14.8 Filling BERTAUT TCHUISE Storage Support Administrator Legg Mason Technology Services *410-580-7032 btchu...@leggmason.com -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Huebner,Andy,FORT WORTH,IT Sent: Tuesday, July 07, 2009 10:36 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] VTL Tape Size We are about to bring up new TSM servers and one of questions that has come up is how big to make the VTL tapes? We currently use 100GG and have tried 10GB with our test server. The question is what size it popular and why? 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.
Re: 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.
Re: VTL Tape Size
I typically use 50GB volume size if it works out well with the VTL limits. Like others have mentioned, be sure to check your VTL maximums for volumes/slots and mount points/virtual drives. __ John Monahan Infrastructure Services Consultant Logicalis, Inc. 5500 Wayzata Blvd Suite 315 Golden Valley, MN 55416 Office: 763-226-2088 Mobile: 952-221-6938 Fax: 763-226-2081 john.mona...@us.logicalis.com http://www.us.logicalis.com -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Huebner,Andy,FORT WORTH,IT Sent: Tuesday, July 07, 2009 9:36 AM To: ADSM-L@VM.MARIST.EDU Subject: VTL Tape Size We are about to bring up new TSM servers and one of questions that has come up is how big to make the VTL tapes? We currently use 100GG and have tried 10GB with our test server. The question is what size it popular and why? 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.
Re: VTL Tape Size
What Nicholas says is totally true. TSM can get very resource constrained when it has lots and lots of simultaneous mounts to manage. In our design, we have a separate TSM instance running on the same server as some of the others (AIX environment) and that instance is just a library master, handling tape mount requests for all the others. This instance sometimes has 170-190 simultaneous tape mounts while servicing 10 TSM instances' tape mount requests. We ended up having to add LIBSHRTIMEOUT 60 to the dsmserv.opt, too, to keep timeouts between the library master and library clients from happening. If I had the choice, we would have sufficient disk space in front of the VTL for 24-48 hours worth of backups, then migrate daily to the VTL with a much smaller number of tape mounts. But management thought it was a waste of money to have disk in front of disk, and at the time I had no strong argument to support it. On the other hand, we have some smaller environments with Windows 2003 TSM servers and 60-150 clients each, and they do their backups straight to VTL, and we schedule them so they only have 20-30 simultaneous mounts at a time, and this works fine. So it depends on the scale of problem you are trying to solve. Best Regards, John D. Schneider The Computer Coaching Community, LLC Office: (314) 635-5424 Toll Free: (866) 796-9226 Cell: (314) 750-8721 Original Message Subject: Re: [ADSM-L] VTL Tape Size From: Nicholas Rodolfich nrodolf...@cmaontheweb.com Date: Tue, July 07, 2009 12:20 pm To: ADSM-L@VM.MARIST.EDU Andy, Just an opinion here. 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. Managing mount points need only be done during daily server maintenance processing. I would still be using a random access disk pool to provide staging space for client backups. The L in VTL stands for Library and it should be treated as such. For many years IBM has recommended that we back up to a staging area to enhance client performance and reduce resource needs. During server maintenance, data should be placed onto longer term storage devices (libraries) for daily expiration and reclamation processing.. I don't think that strategy changes with a VTL. On another not I have a client with a VTL running in a Windows environment with around 200 clients(not sure what you have). Their VTL vendor suggested a volume size of 20Gb. This eventually created ~15000 volumes. When the TSM server used the VTL, the overhead from mounting hoards of virtual volumes brought their server to its knees. I mean it would not even respond to session requests so it could not complete nightly client backups at all. Not to mention the headaches of managing 15000 volumes from the TSM interface (GUI or CLI). They too were trying to backup directly to the VTL during nightly client backups. We had to return there management class destinations back to a random access storage pool and process their data during daily sever maintenance as TSM is designed to do. We set up the VTL to emulate LTO2 (200GB volume size) and used the VTL like a library, migrating the nightly backup data to the VTL. Large Oracle backups do directly to the VTL but are limited in number. The client is fat and happy now, backing up ~1.5TB nightly with plenty of time left and the TSM server performance is stellar. Regards, Nicholas ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 07/07/2009 11:18:26 AM: [image removed] Re: [ADSM-L] VTL Tape Size John D. Schneider to: ADSM-L 07/07/2009 11:19 AM Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Please respond to ADSM: Dist Stor Manager Andy, My experience may not map to the problem you are trying to solve, but I chose a relatively small VTL tape size (50GB) and have not regretted it. The trade-off is total number of virtual tapes vs total number of anticipated simultaneous tape mounts. Say you have a 60TB VTL (usable), and you want to emulate LTO4 tapes. If you went with the default size (400GB) you would have about 150 virtual tapes in your pool. Say also that there are 300 TSM clients to be backed up each night. Each one will need at least one virtual tape during their backups, and some of them might need 4 or 8 for performance reasons. You would have only 150 tapes for 300 clients? You could spread out their schedules, of course, but that will still be problematic. After a few weeks you might have a bunch of them full, but not ready to reclaim, or waiting on reusedelay, and not have enough available tapes for all the tape mounts you need. With 50GB tapes, you would have over 1200 virtual tapes. Tapes would fill up sooner, of course, but they could be reclaimed sooner, too, and be returned to scratch. Your overall disk utilization will go up. One thing to bear in mind is that if you have single files
