The other factor is storage growth.  You probably want your TSM server
architecture to last awhile, and I've seen estimates ranging from 50-300%
storage CAGR (and consistently seen the estimates exceeded).

There are several approaches:
Buy the biggest, most scalable stuff you can afford, and hope for the
best.  This maximizes the upfront cost, but minimizes the downstream cost.
 You might get promoted before you run out of capacity.
Buy what you think you will need for the next little while, and plan to
upgrade.  This works better for servers than libraries, and you can
usually find a use for an outgrown server.  Also, server price/performance
increases much faster than library price/capacity.
Plan to grow modularly with lots of TSM servers.  Even TSM can't scale a
single server to extremely large environments, and sometimes you're better
off biting the bullet and architecting for multiple servers from the
getgo.

_____________________________
William Mansfield
Senior Consultant
Solution Technology, Inc





"Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/03/2002 04:50 PM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: TSM Server Sizing


The number of servers and amount of storage mean nothing in my opinion.
The
issues of what type of storage it is, how many files on the servers, what
type of workload the server is, what type of server it is, what type of
network connection the server has, what is the backup window, and what
bandwidth is in the network are more interesting issues in the sizing.  If
they are all Gigabit, SAN connected ESS disk, and high end servers then
the
answer is much easier to calculate.

This is not something you just throw into a calculator and bing comes the
answer.  You have to model the environment, categorize the data and
servers,
figure out the critical path, and then you have a hope of configuring a
solution.