>> On Mon, 13 Mar 2006 12:03:04 -0500, Robin Sharpe <Robin_Sharpe AT BERLEX DOT
>> COM> 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
|
