Wow! Quite a setup. I've worked on a couple of engagements with 24 x 3592 tape drives, but 72 drives, 1900 paths, and 200 stg agents must be interesting, to say the least.
Off the top of my head: Advantages: 1 scratch pool, "lazy man's load balancing", with all TSM clients accessing all drives. Disadvantages: single point of failure with one LM (even if HA'ed, would be a mess to clean up if a failure occurs while busy, and with 50 TB per night, I assume the environment is busy 24x7), difficult management and maintenance of all the paths, spaghetti galore for any VISIO of the environment, D/R requires tracking all tapes as opposed to a necessary subset, conflict of scheduling if all 72 drives are in use prempting another instances processing, plus there's got to be a few other gotchas. At the risk of offending the architect, it sounds to me like not enough planning went into the design (which could be due to lack of customer requirements). Most shops, with various applications and purposes, would divvy up the TSM resources (prod, test, QA, DBs, file servers, etc.), and come up with something that has several specific areas designed for a particular goal. Do all 200 stg agents need LAN-free? If less than 300-500 GB, a GB ethernet connection saves on licensing. Are all 13 TSM server clients "load balanced", or would some be better utilized to use more disk for buffering, and fewer than 72 drives for day-to-day processing? Amazing. ----- Original Message ----- From: Sean English <[EMAIL PROTECTED]> Date: Wednesday, February 6, 2008 15:12 Subject: [ADSM-L] Question on TSM environment sizes To: [email protected] > Just wanted to poll the list and find out if anyone has a setup > similar to > ours and any experiences (positive and negative) with that setup. > > 1 TSM library manager running TSM 5.3.5.2 with 1900 drive path > statements,18 frame 3584 tape library with 5600 tapes and 72 > 3592 drives > 13 TSM library clients running TSM 5.3.3.1 and TSM 5.3.5.2 all > connectingto the 1 TSM library manager > Backing up around 50 TBs a night. > > Thanks, > Sean English >
