ADSM-L

Re: Capacity Planning

2005-03-21 13:47:33
Subject: Re: Capacity Planning
From: John Monahan <JMonahan AT COMPURES DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 21 Mar 2005 12:53:58 -0600
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
             <tsm AT KLOEK DOT COM>
             Sent by: "ADSM:                                            To
             Dist Stor                 ADSM-L AT VM.MARIST DOT 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.

<Prev in Thread] Current Thread [Next in Thread>