Quite a complex set of questions that I don't think you will find a magic bullet for. The biggest factor in your capacity planning will be your typical growth rate, so if you can begin to track that, then you have won half the battle. Most people will track history using a combination of TSM accounting log, custom scripts, and possibly Tivoli Data Warehouse to determine past activity and typical growth trends. Once you know your average growth rate for items like the TSM database, average daily backup of all nodes, # nodes added yearly, etc. then you can extrapolate that information over your forecast period.
It sounds like you need to get a hold of your daily backup figures and then based on the amount of time you have for daily processing, figure out what you need to meet those requirements. Once you know that, then apply your typical growth rate figures out for X amount of months. You can use the real performance numbers of your tape architecture or go with published performance numbers if you are looking at a new tape architecture, to determine the estimated amount of time it will take to do a storage pool backup, migration, etc. on one tape drive. If you have 4 hours to do your stg pool backups, then you will know how many tape drives you'll need to accomplish the task. The same procedure can be used to calculate estimated time requirements for all the parts of your TSM daily processing. You can also use the growth rate figures to estimate disk space needed for TSM DB, diskpool, etc. You can use the a combination of the average daily backup figure and the TSM database size/growth rate figure to determine when you will need to break up into multiple TSM servers or use multiple network cards. i.e. If your average daily backup is 2 TB and you have a 4 hour window in which to accomplish your backups, one Gigabit network connection on the TSM server isn't going to do the job. For special cases outside your normal growth rate, you should be able to estimate the impact that will have on your TSM environment by estimate the average daily backup increase for that case, and how that will increase the time on each chain in your TSM processing. Then you can apply your standard growth numbers to those new items and figure out how much hardware, etc. you will need to throw at TSM to still meet your daily processing requirements. IBM and most business partners also do TSM assessments or health checks or some other named type engagement where they will come in with tools they have developed specifically for TSM capacity planning that can also help you in this area. Of course these are paid engagements, and the tools and methodologies are protected intellectual property. ______________________________ John Monahan Senior Consultant Enterprise Solutions Computech Resources, Inc. Office: 952-833-0930 ext 109 Cell: 952-221-6938 http://www.computechresources.com Jeff Kloek <[EMAIL PROTECTED]> Sent by: "ADSM: To Dist Stor ADSM-L@VM.MARIST.EDU Manager" cc <[EMAIL PROTECTED] .EDU> Subject Capacity Planning 03/21/2005 11:23 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] .EDU> For the last few years, I was the point-man in the UNIX department at my last job for Tivoli Storage Manager support. We had a separate department called Storage Management that contained the "Architects" of that environment. During my time there, I got very interested in TSM and have studied it a great deal. Now I'm at a company who also uses TSM, but where there isn't an architecture type of group, and we're running into growth related issues. I believe the end-run of a detailed study of TSM results in: a) the ability to predict the impact of a specific client (or group of clients) growth on the overall needs for that environment, and b) the ability to predict the increased needs of storage pool disk and tape mount requirements based on changes like that in item a) above. Up to this point, I'm just not quite there. I've built some reports like daily host backup amounts, daily changes in host occupancy; studied the details of the policy domains, policy sets, management classes, and copy groups, obtained a general understanding of the retention policies, etc., but I still don't quite have my hands around the big picture. Right now, we're in a situation where our daily backups are going to disk just fine. The problem we're having with the enormous increase in Email backups (we don't currently delete anything due to a recent decree by management) is that our offsite copy pool backups are no longer completing within the 24 hour magic window. I suspect there is a set of procedures that is generally accepted that would help to define increasing needs for the TSM environment. I'm sure I need to begin capturing the daily amounts of data that gets backed up in the BACKUP STORAGE POOL processes, and perhaps even the MIGRATION processes. All that being said, is there a set of guidelines that can help me define exactly what increase in hardware we might need, or something that would help me to tell management that "to add another X amount of drives would get us back to completing the offsite copy pool process (and thus the entire day's processing) to within the 24 hour window? Details: TSM Server 5.2.2.0 on AIX 5.2 7026/6H1; 4Gb memory; 3584 Library; 18 LTO2 drives. Currently there are no drives to spare to add additional mounts for the Backup Storage Pool processes.
