>> On Mon, 13 Mar 2006 12:03:04 -0500, Robin Sharpe <[EMAIL PROTECTED]> said:
[...] I've got 12 servers on 2 boxes at the moment, 6 of which are more or less application-specific. The more TSM server instances, the more complexity, and the more you must depend on automation and automatic validation and monitoring. Because of this, I would recommend against calving off a TSM server only because there is a powerful box running app X. I split one app off to its' own TSM server because of database overhead: WebCT 'Campus Edition' which has some unsavory habits with its' filesystem, and caused lockups. I split one app off because it was excessively sensitive to outages: Content Manager. I split off my Cyrus back ends because each single node of them had "big" databases (though they're teeny compared to yours). So, if you have application Q which you would tend to split off even if the split instance were to stay on your main TSM server, then I'd consider that a candidate for motion to the other box. --- Another thing to consider is that this opens up application Q to the union of the upgrade / outage / maintenance issues of Q and TSM. This might be a non-issue, but could possibly be a big deal. (What, we need new tape drivers, to match the microcode applied yesterday morning on the drives? Well, you can schedule a production outage for next tuesday...) --- Once you're over the automation/planning/monitoring hump for multiple servers, and the additional hump associated with servers on multiple hosts, you'll find that lots of concepts become much easier: DR for the TSM infrastructure gets more straightforward because there's much less implicit state, you've made much more of it explicit. This is a lot of work, but gives good value. - Allen S. Rout