Zoltan, I did a consulting gig at a large TSM site a million years ago that sounds similar to yours. In their case, they had a TSM server that was flat out 24*7 and did not have enough time to do even the simplest thing like expire files. My job there was to help figure out what to do. In working with the customer, we kept coming back to his fact that there was not any money to upgrade, that management wouldn't understand the request, that clients were frustrated, blah, blah, blah. They were contemplating a switch to another platform too, but still were unwilling to allocate enough financial resources to do the job correctly.
I blather all of this out there to make the following point: if backup/restore/archive/disaster recovery are of insufficient value to the organization, no amount of technical wizardry will overcome the problem. It is only when we have adequate resources to purchase enough hardware that we have a chance to succeed. In your case, it sounds like you have a good plan. Fight the good fight and get enough bucks to get enough hardware to build a kick ass system. Or don't start... Kelly J. Lipp VP Manufacturing & CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan Forray/AC/VCU Sent: Thursday, January 11, 2007 8:19 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Recommendations for hardware replacement/upgrade We never have enough resources. The 4-LTO drives in one library, are shared amongst 3-TSM servers which transfer over 2TB, nightly. The 4th TSM server is dedicated to Domino backups, which use it's 4-LTO and 4-3592 drives, 24x7, transferring almost 3TB of mostly non-compressable data (I never get more than 800GB on a 3592-2 tape) daily. With the drives being busy almost nonstop, this leaves little time for things like reclamation, etc. Right now, I had to manually bring back 150-offsite LTO tapes with less than 20% utilization, since I don't have time/drives to perform standard offsite reclamation by rebuilding them from the primary onsite tapes. It is a constant, hand-management juggling act, having to constantly intercede when the regular schedules get out-of-whack due to bursts in new data, LTO drives failing, etc. One of the servers is going to grow by 150GB or more of new data (radiological images), daily. So, trying to add one more TSM server to try to share 4-6 drives, just won't work. "Allen S. Rout" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 01/11/2007 10:04 AM Please respond to "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Recommendations for hardware replacement/upgrade >> On Wed, 10 Jan 2007 12:08:22 -0500, Zoltan Forray/AC/VCU <[EMAIL PROTECTED]> said: > Thanks for the feedback. > Yes, I realize you can't beat AIX for I/O bandwidth. Unfortunately, > it comes down to $$$$$$ (doesn't it, always). I think your $/performance-unit is much better on AIX than it will be in intel-land. I call the x86 option cheap now, pricey later. But you've already said that AIX isn't on the table. > I agree it would be beneficial to break things up. However, this would > lead to even more contention for resources (tape, tape > libraries) than we already have. We have enough issues juggling 4-TSM > servers against 3-tape libraries (1-3494 2-3583). I don't understand how you concluded this. Whatever the count of servers you're using, the drive use should be related to the client node count and behavior, and should not be varying too much. Am I missing something? > I hadn't really thought about running multiple TSM server instances on > one machine. Not sure if it is worth the effort/risk! If you are already running multiple TSM servers, you've got the coordination infrastructure in place already. (or you don't in which case God Bless You) That won't be much different if you've got 2 servers on one box. I'm running 11 on one box now: Having relatively small databases makes a huge improvement in reliablity. - Allen S. Rout
