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: SV: Library unavailable
Hi, I am using the command line. As for the serial number, I´ll remove the defined library and redefine it without using this clause, and then create the path...and see what happens. I´ve already removed TSM and reinstalled it. The IBMtaped daemon is up and running. IBMtaped version is 1.5.3 and I ran the IBMtapeutil facility to check the Media Changer and Drives and everything seems to be ok, at least at OS level. Mario From: Christian Svensson To: ADSM-L@VM.MARIST.EDU Sent: Tuesday, July 7, 2009 2:48:34 AM Subject: SV: Library unavailable Hi, I normally don't use the ISC or WebGUI to define any drives or libraries. But you need to define the path between. Another thing I see is that the Serial number that you specify on both strings is different. Try to use the command line instead of the GUI, >define libr LIBLT01 libtype=SCSI >define path TSMSERVER liblt01 srct=server destt=libr device=/dev/X >define dr liblt0 DRIVE0 >define path TSMSERVER drive0 srct=server destt=dr libr=liblt01 device=/dev/ >define dr liblt0 DRIVE1 >define path TSMSERVER drive1 srct=server destt=dr libr=liblt01 device=/dev/ >define dr liblt0 DRIVE2 >define path TSMSERVER drive2 srct=server destt=dr libr=liblt01 device=/dev/ If it still don't work. Make a search in the message file for your drives or look in /proc for more information. You maybe also need to upgrade your drivers for your IBM drives. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Från: ADSM: Dist Stor Manager [ads...@vm.marist.edu] för Mario Behring [mariobehr...@yahoo.com] Skickat: den 7 juli 2009 07:04 Till: ADSM-L@VM.MARIST.EDU Ämne: Library unavailable Hi list, When trying to define drives I get the following message: DEFINE DRIVE LIBLTO1 LIB1DRIVE0 ELEMENT=256 ONLINE=Yes WWN="500308FF421B4001" SERIAL="1110165508" ANR2017I Administrator SERVER_CONSOLE issued command: DEFINE DRIVE LIBLTO1 LIB1DRIVE0 ELEMENT=256 ONLINE=Yes WWN=500308FF421B4001 SERIAL=1110165508 ANR8444E DEFINE DRIVE: Library LIBLTO1 is currently unavailable. The library is defined... DEFINE LIBRARY LIBLTO1 LIBTYPE=SCSI SERIAL="013203721000" SHARED=NO ANR2017I Administrator SERVER_CONSOLE issued command: DEFINE LIBRARY LIBLTO1 LIBTYPE=SCSI SERIAL=013203721000 SHARED=NO ANR8400I Library LIBLTO1 defined. The library is an IBM ULT3583-TL with 3 drives. TSM is 5.2.2.2 running on Linux SuSE. I cannot upgrade it due to license issues...not at this time anyway. TSM Server was running fine until a week ago when it stopped at some point...not clear to me. I removed it completely and I am trying to install it again, but it keeps telling me the library is unavailable. The TSM Device Driver was installed, but I believe it was not being used because it does not support the current Linux Kernel version. tsmlinux:/opt/tivoli/tsm/devices/bin # ./tsmscsi TSM device driver not available for kernel release 2.4.21-241-smp Any help is appreciated. Mario
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" 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
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" 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" > > 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
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.
TSM6.1 on Linux
For those that tested 6.1 in a Linux environment I'm looking for any problems you had. During my testing on AIX and Windows I had failures during the installation which were always DB2 related. I'm getting ready to bring up TSM on a Linux box and am looking for your experience. This is a new installation not an upgrade. This is a test but I really want to get a working environment up as quickly and easily as possible. In the end I will blow this away and bring it up on an IBM p series box running Linux which will hopefully be just as easy but for now this is just a test on a blade I was given till the other hardware arrives. I will direct 2 LTO2 drives to this box from the 3584 along with a VTL that is coming in this week. Learning Linux from scratch so I really have no idea how these devices are even found. I have SAN disk displayed for DB and I need to figure out how to get all that set up too, unfortunately it's not something I've figured out. I can tap some other Linux resources here for help with that I hope. I'm taking notes on what I've done with specific commands since I certainly won't remember it tomorrow. I really hate asking for documents others have put together but in this case, since I'm being pressured to get this going, I certainly would appreciate anything others have put together if anyone may have something already. Thanks for any info you can provide. Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-B1P (858)826-4062 (office) (858)412-9883 (blackberry) Email: geoffrey.l.g...@saic.com
TSM & EMC DL3D 4000
Would anyone using TSM with a EMC DL3D 4000, care for some experience exchange ? I'm specially interested in this vtl's replication functions for disaster recovery purposes. What kind of procedures *must* be setup in order to successfully and painlessly recover TSM on the remote site (on an active and awaiting machine). I'm also interested in some real world performance figures. Thks, jmC PS: Please contact me directly if you prefer. Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. 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 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" 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" > > 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 t
Re: TSM6.1 on Linux
On 7 jul 2009, at 19:34, Gill, Geoffrey L. wrote: For those that tested 6.1 in a Linux environment I'm looking for any problems you had. During my testing on AIX and Windows I had failures during the installation which were always DB2 related. I'm getting ready to bring up TSM on a Linux box and am looking for your experience. This is a new installation not an upgrade. This is a test but I really want to get a working environment up as quickly and easily as possible. In the end I will blow this away and bring it up on an IBM p series box running Linux which will hopefully be just as easy but for now this is just a test on a blade I was given till the other hardware arrives. I've installed 6.1 on debian and opensuse. Unfortunately, TSM 6.1 on a minimal install is untested (and not very well documented) and the deployment engine will fail in horrible ways. If you just install opensuse including a gui, java, ksh and more (select everything), it will work quite easily. One thing: Linux on x86 is only supported in 64 bit mode! Another thing, make 100% sure that you local hostname (output of hostname) is not mapped to 127.0.0.2 but to a real IP address of your server. There is some misfeature in DB2 that actually depends on real TCP/IP communications to the localhost based on the hostname (rather than 127.0.0.1). On debian I did a few tricks (bypassing the DE), and all was fine. I have a feeling that debian is a better OS for running TSM than OpenSUSE (or bypassing the DE is a good idea, take your pick ;-)). May I enquire why you'd want to replace the most robust OS on the planet (AIX) on your p series with Linux? Not that I don't like Linux, I just think AIX is superior. I will direct 2 LTO2 drives to this box from the 3584 along with a VTL that is coming in this week. Learning Linux from scratch so I really have no idea how these devices are even found. I have SAN disk displayed for DB and I need to figure out how to get all that set up too, unfortunately it's not something I've figured out. I can tap some other Linux resources here for help with that I hope. I'm taking notes on what I've done with specific commands since I certainly won't remember it tomorrow. I really hate asking for documents others have put together but in this case, since I'm being pressured to get this going, I certainly would appreciate anything others have put together if anyone may have something already. given that I always think that the best platform to run TSM on is the one you are most familiar with, stick with AIX! Linux is great, really, but AIX is better. Thanks for any info you can provide. Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-B1P (858)826-4062 (office) (858)412-9883 (blackberry) Email: geoffrey.l.g...@saic.com -- Met vriendelijke groeten, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: TSM6.1 on Linux
> May I enquire why you'd want to replace the most robust OS on the > planet (AIX) on your p series with Linux? Not that I don't like Linux, > I just think AIX is superior. I've had this conversation with the folks who, I'm sure if you ask them, know better than me. There is a move to 'consolidate' everything around here with those in charge, I guess, thinking it's going to cut costs and 'make things easier'. They ask me who knows AIX in case I'm not around too. Added together both mean nothing to me since from what I've seen AIX is perfectly easy to learn by those who have been using UNIX for years. Looks to me like the maintenance cost of RedHat 5 and AIX are comparable so there isn't much savings there if any. Because linux runs on the p series they are pretty much telling me it won't be AIX. So far the learning curve for me, along with research, install failures, more research, missing packages, more research, bad documentation and more research is outweighing any reason they can come up with for wanting to go Linux. Then again, what do I know. > given that I always think that the best platform to run TSM on is the > one you are most familiar with, stick with AIX! Linux is great, > really, but AIX is better. Agreed. Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-B1P (858)826-4062 (office) (858)412-9883 (blackberry) Email: geoffrey.l.g...@saic.com > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of > Remco Post > Sent: Tuesday, July 07, 2009 3:00 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: TSM6.1 on Linux > > On 7 jul 2009, at 19:34, Gill, Geoffrey L. wrote: > > > For those that tested 6.1 in a Linux environment I'm looking for any > > problems you had. During my testing on AIX and Windows I had failures > > during the installation which were always DB2 related. I'm getting > > ready > > to bring up TSM on a Linux box and am looking for your experience. > > This > > is a new installation not an upgrade. This is a test but I really want > > to get a working environment up as quickly and easily as possible. In > > the end I will blow this away and bring it up on an IBM p series box > > running Linux which will hopefully be just as easy but for now this is > > just a test on a blade I was given till the other hardware arrives. > > > > I've installed 6.1 on debian and opensuse. Unfortunately, TSM 6.1 on a > minimal install is untested (and not very well documented) and the > deployment engine will fail in horrible ways. If you just install > opensuse including a gui, java, ksh and more (select everything), it > will work quite easily. One thing: Linux on x86 is only supported in > 64 bit mode! Another thing, make 100% sure that you local hostname > (output of hostname) is not mapped to 127.0.0.2 but to a real IP > address of your server. There is some misfeature in DB2 that actually > depends on real TCP/IP communications to the localhost based on the > hostname (rather than 127.0.0.1). > > On debian I did a few tricks (bypassing the DE), and all was fine. I > have a feeling that debian is a better OS for running TSM than > OpenSUSE (or bypassing the DE is a good idea, take your pick ;-)). > > > > > > > > I will direct 2 LTO2 drives to this box from the 3584 along with a VTL > > that is coming in this week. Learning Linux from scratch so I really > > have no idea how these devices are even found. I have SAN disk > > displayed > > for DB and I need to figure out how to get all that set up too, > > unfortunately it's not something I've figured out. I can tap some > > other > > Linux resources here for help with that I hope. I'm taking notes on > > what > > I've done with specific commands since I certainly won't remember it > > tomorrow. I really hate asking for documents others have put together > > but in this case, since I'm being pressured to get this going, I > > certainly would appreciate anything others have put together if anyone > > may have something already. > > > > given that I always think that the best platform to run TSM on is the > one you are most familiar with, stick with AIX! Linux is great, > really, but AIX is better. > > > > > > > Thanks for any info you can provide. > > > > > > > > Geoff Gill > > TSM Administrator > > PeopleSoft Sr. Systems Administrator > > SAIC M/S-B1P > > (858)826-4062 (office) > > > > (858)412-9883 (blackberry) > > Email: geoffrey.l.g...@saic.com > > > > > > -- > Met vriendelijke groeten, > > Remco Post > r.p...@plcs.nl > +31 6 248 21 622
SV: TSM6.1 on Linux
Hi Geoff, As I said to you in the last email. If you install Linux and use a supported platform such SuSE Enterprise Linux (SLES) or RedHat Enterprise Linux (RHEL) you will have a good start. If you install a minimal SLES or RHEL make sure you have following packages installed on your server because this is what TSM DB2 require * Read/Write access to /etc/inittab * RPM Builder (standard for SLES and RHEL) * java-sun5 * libstdc++5 (Also called libstdc++33 or compat-libstdc++-33) * libaio, libaio0 and libaio1 * GNU C Library (also called glibc) * SELinux must be set to permissive or disable mode. If you talk to IBM you need following packages installed as minimum. GNU C libraries, Version 2.3.3-98.38 or later IBM Java 1.5 Selinux must be set to permissive or disabled If I where you. Make sure you choose a operating system that you and your team can easy administrate. Sure AIX is more stable then Linux but Linux has a lot of good stuff coming out during 09Q4 and 2010 that will speed up Linux A LOT Keep your eyes open for Tux3, Btrfs and EXT4 filesystems. They will probably speed up your TSM database/log and storage pools. And we have customers that backup 22TB+ every night on TSM 5.5 based on multiple Windows Server 2003 x64. Sure it will be less nodes per TSM Server but it is at least a operating system they TSM Admins can support and make sure it works. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson Från: ADSM: Dist Stor Manager [ads...@vm.marist.edu] för Gill, Geoffrey L. [geoffrey.l.g...@saic.com] Skickat: den 8 juli 2009 00:16 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: TSM6.1 on Linux > May I enquire why you'd want to replace the most robust OS on the > planet (AIX) on your p series with Linux? Not that I don't like Linux, > I just think AIX is superior. I've had this conversation with the folks who, I'm sure if you ask them, know better than me. There is a move to 'consolidate' everything around here with those in charge, I guess, thinking it's going to cut costs and 'make things easier'. They ask me who knows AIX in case I'm not around too. Added together both mean nothing to me since from what I've seen AIX is perfectly easy to learn by those who have been using UNIX for years. Looks to me like the maintenance cost of RedHat 5 and AIX are comparable so there isn't much savings there if any. Because linux runs on the p series they are pretty much telling me it won't be AIX. So far the learning curve for me, along with research, install failures, more research, missing packages, more research, bad documentation and more research is outweighing any reason they can come up with for wanting to go Linux. Then again, what do I know. > given that I always think that the best platform to run TSM on is the > one you are most familiar with, stick with AIX! Linux is great, > really, but AIX is better. Agreed. Geoff Gill TSM Administrator PeopleSoft Sr. Systems Administrator SAIC M/S-B1P (858)826-4062 (office) (858)412-9883 (blackberry) Email: geoffrey.l.g...@saic.com > -Original Message- > From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of > Remco Post > Sent: Tuesday, July 07, 2009 3:00 PM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: TSM6.1 on Linux > > On 7 jul 2009, at 19:34, Gill, Geoffrey L. wrote: > > > For those that tested 6.1 in a Linux environment I'm looking for any > > problems you had. During my testing on AIX and Windows I had failures > > during the installation which were always DB2 related. I'm getting > > ready > > to bring up TSM on a Linux box and am looking for your experience. > > This > > is a new installation not an upgrade. This is a test but I really want > > to get a working environment up as quickly and easily as possible. In > > the end I will blow this away and bring it up on an IBM p series box > > running Linux which will hopefully be just as easy but for now this is > > just a test on a blade I was given till the other hardware arrives. > > > > I've installed 6.1 on debian and opensuse. Unfortunately, TSM 6.1 on a > minimal install is untested (and not very well documented) and the > deployment engine will fail in horrible ways. If you just install > opensuse including a gui, java, ksh and more (select everything), it > will work quite easily. One thing: Linux on x86 is only supported in > 64 bit mode! Another thing, make 100% sure that you local hostname > (output of hostname) is not mapped to 127.0.0.2 but to a real IP > address of your server. There is some misfeature in DB2 that actually > depends on real TCP/IP communications to the localhost based on the > hostname (rather than 127.0.0.1). > > On debian I did a few tricks (bypassing the DE), and all was fine. I > have a feeling that debian is a better OS for running TSM than > OpenSUSE (or bypassing the DE is a good idea, take your pick ;-)). > > > > > > >
