Don't take this as 'true', it is just a quick guideline to start
doing a sizing
of a library and server. There are more things you need to
consider,
like network bandwidth availability, size of clients (both in files
and gig),
backup windows, special situations or databases (Oracle, MSSQL,
Exhange,
others), rate of change of files, etc, etc, but this should get you
started.
If others have some similar guidelines or rules of thumb, I would
like to
see them or to 'fix' these!
It may be old, but rules of thumb I have been told are:
(This will probably generate an oversized config, but you
will probably
not run out of space and it will last for a while after it
is installed.
on Sun 1 processor per SCSI card and one per gigabit card, one more
for database and one for general overhead. Ok, this is
overkill, but
you will not run out of processor power. -- I don't know how
it scales
on Intel processors or Windows.
I have only speced LTO's so only one per scsi channel (to keep from
overcommitting SCSI bandwidth. Make sure you can keep your
drives
streaming with SCSI bandwidth and that you have backplane
bandwidth
that will allow the SCSI adapters to take the data from the
disks too.
Of the data being backed up, take the number of copies you want
to keep long term, and multiply it by 3x . Make this the
uncompressed
capacity of the tapes in the library. This gives the library
size in slots
when you divide the capacity in gig by the uncompressed size
of the
tapes you are using).
Number of tapes - get enough to fill the library and enough to
support your
off site storage needs. If you are doing remote replication
it is possible
to have libraries at both sites that are large enough to
handle remote
replication of data and not have to take tapes out for
offsite storage.
On tape drives, two drives, but add more if you think you need it to
get
data out of the disk pools and onto tape in a reasonable
amount of
time, and if you are going to do co-location. ... Specing
this
inteligently needs more details. But like CPU and memory,
it seems
like you can never have enough. NEVER calculate tat you can
use
compression, for either time or sizing estimates. Just use
it as a
'nice supprise'. At my current site we have lots of images,
and it
does not compress well (and sometimes I think compression
expands
this particular data, but I have no empiracle evidence).
On disk space, estimate the size of your system (20G?), and database
with journals (Number of files on all clients * number of
copies you keep on disk and
on tape in all storage pools * 512 bytes each), plus at
least enough for
one full copy of incrementals (the larger of daily, weekly,
or whatever).
As always, round up, and more is better.
On RAM for the CPU. Again to much is never enough, but I would like
to
hear from others as to their 'rule of thumb' for sizing RAM.
For a better sizing, snag your local VAR that has TSM technical experience
and
put them to work. Yes, they will want to sell it all to you, but they will
work for
the answers they give you too. (I used to work for a VAR and sold both TSM
and
Veritas NBU. And I do not support or sell this stuff for anyone but my
current
employer, so take all this info for what it cost you :)
... I hope this helps. ... Jack
> -----Original Message-----
> From: Farren Minns [SMTP:fminns AT WILEY.CO DOT UK]
> Sent: Tuesday, April 09, 2002 10:56 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: TSM and Capacity Planning
>
> Hello again TSMers
>
> I am currently in the process of preparing a capacity planning document
> for
> our TSM set-up so that I can at least try to estimate when our Server will
> become pushed to its limits.
>
> I was wondering who else has done this recently and if there are any good
> sources of inf. on the net that may be of help to me.
>
> At the moment we have TSM Server 3.7.3.8 running on a Sun Solaris E250
> (400Mhz, 1GB memory). We have 28 client running on Solaris, OS/2, NT and
> one Linux for good measure. We have one 3494 tape library housing two 3590
> tape drives (J Tapes - 20Gb compress, 10 uncompressed).
>
> I can easily work out approx. how many tapes we are going to need; how
> much
> free space we have in the library; how much disk space we may need for the
> database, log etc. But the thing I need help with is figuring out how much
> client data we can back up within a certain window. All clients seem to
> have different rates at which they can process data; some machines are
> remote; some use compression etc. etc. etc. I'm am quite new to this and
> would be interested in other peoples experiences in doing this kind of
> thing.
>
> I guess there are so many questions that to sit here and type them all
> would be foolish. I'm more interested in finding out what the crucial
> questions I should be asking are (are you still with me, I know I'm
> rambling now).
>
> Also, I'm interested in learning more about the tuneable parameters within
> TSM (Server and Client); what sort of things I could do to improve data
> throughput, database performance, tape performance etc.
>
> Basically, any help, pointers etc regarding this type of thing would be
> very much appreciated.
>
> Thanks very much
>
> All the best
>
> Farren Minns - Trainee Solaris and TSM system admin
>
> John Wiley & Sons
|
