Hello Jack,
Check out the Admin Guide, and the RedBooks (ie, Getting Started, v31/v37
Technical Guide & TSM 3.7 Concepts).
In addition to all that stuff, the following TWO ROT's seem to be generally
accepted, working principles:
1 - if the tape vendor (eg, IBM) advises 3:1 compression, we use 2:1 (3 is
okay for marketing, not-so-okay for planning);
2 - plan to use only HALF any given silo occupancy; the other half gets
used for things like DBbackups, tape fragmentation/reclamation, extra
"archive" snapshots, and copy pool processing (even though the latter two
might not stay in the silo, they need to occupy slots as
scratch/filling/full until the librarian can remove!)
The Admin. Guide suggests some basics for disk pool sizing and tape silo
sizing.
We have settled on...
Backup size (ie, total sizing to hold backup data) estimates depend on
retention policies; for us, we have 3 basic backup retention policies: (a)
flat-files = 1.05 * (VE/VD/RE - 1), plus (b) OraData = 4 * db-occupancy
(VE/VD/RE/RO = 4/1/15/35) plus (c) Exchange = 9 * db-occupancy (ie, 8 FULL +
8 INCR/DIFF's). This formula currently ignores the archive logs for Oracle
--- we're still gathering accounting data to adjust for that; for the
INCR/DIFF of Exchange, although we did a swag of 1.0 * db-occup. for that.
INCR/DIFF of Exchange, although we did a swag of 1.0 * db-occup. for that.
Archive size is simply .7 * total client disk capacity * # of archives
over total retention.
*SM server DB & RLOG sizings can vary wildly, depending on client apps;
IBM suggests 1-5% total server storage space for DB, so we use 3% for DB &
2% for RLOG, then monitor things as we go... some servers are using 85% of
8G db allocation, others are using only 30%... really varies according to
site/apps.
For *SM diskpools, you need to guess what your daily traffic load will be,
and size for at least 1.25-2.0 times that --- to avoid migration during
backups; we send large OraData & FULL-Exchange direct to tape, reserving
disk pools for the rest, it's a balancing act between concurrence and
economy of disk/tape allocated.
You'll want to have silo capacity to handle all the backup occupancy plus
(at least) one instance of archive-snapshots plus DBbackups & reclamation,
plus room for DRM/copy-pools and *ANY* growth of client load.
Regards,
Don France
Technical Architect, P.A.C.E.
San Jose, CA
mailto:dfrance AT pacbell DOT net
PACE - http://www.pacepros.com
Bus-Ph: (408) 257-3037
> -----Original Message-----
> From: Jack Palmadesso [mailto:Jack.Palmadesso AT SWPC.SIEMENS DOT COM]
> Sent: Monday, April 24, 2000 6:55 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Guidlines for New *SM server
>
>
> Does anybody know of any guide or any general guidlines to
> help plan out *SM
> enviroments.
>
> How to calculate how much disk space, what size pools,
> database and log
> allowance?
>
> Thanks for any help
>
> Jack Palmadesso
>
|
