Setting up TSM for use with OD

[Shannan]

We are setting up OD on our production environment, and will be initially running OD on one of our CM RMs that also has TSM already installed and running.  I am looking for help/advice on setting up the TSM definitions for OD.  The install guide gives guidance for a new install and we don't have all of the assumed defaults on our TSM per the install guide.  Can anyone summarize the pieces needed to set up TSM for OD use?  I'm not a TSM person - know just enough to do what we are doing with CM and still a newbie with OD.  We are running on Windows.  Any help would be appreciated.  Thank you in advance!

[Justin Derrick]

Hi Shannan.

First things first:  I don't generally recommend intermixing CMOD with other servers.  It's possible to run both on the same system, but when CMOD (or your CM system) gets too big and you need to migrate to a new system, it's chaotic.  Virtual Machines (in the Windows or Linux world) or LPARs (in the AIX world) are an exception, because they're easily portable to new hardware.  That having been said...

You'll need to come up with your own TSM definitions to match your specific requirements.  The guide is a good start, but keep the following tips in mind:

Create a new Storage Set for EACH Application Group in CMOD.
Each Storage Set should have it's OWN Domain, Policy, Management Class, and node definitions inside TSM.

The reason for this is that sometimes the requirements for the retention of documents change -- and when you bundle a number of AGs into a single Storage Set, if you're required to change the retention for one, ALL of the other AGs will be affected.  (And sometimes having data for longer than you should is worse than not having it when you should.)

Don't hesitate to ask more questions as you work your way through this!

-JD.

[Nils Engerby]

A word of caution if you install the OnDemand client on the same machine as TSM. I recently did that in my lab environment and when I uninstalled the OD client (version 8.4.1.04) it blew my TSM installation to pieces. The OD client uninstall dropped the whole registry branch below HKLM\SOFTWARE\IBM\ADSM and probably did some more nasty things since restoring this registry branch was not enough to cure the TSM server...

[Justin Derrick]

Shannan:  Which platform are you on?

Nils:  Bummer about your TSM issues -- I hope you got them fixed without too many other issues.  For what it's worth, that situation would only happen on Windows, both because of the Windows Registry, and the fact that you can't load the client on most of the UNIX platforms.  (Running the client under WINE on Linux is possible though.)

-JD.

[Shannan]

Sorry for the delay in responding, we are running on Windows.  Thanks for the word of caution Nils.  Justin, when you say chaotic, is it terrible to move OD else where in the future?  What makes it so?  TSM?  What are your thoughts on running OD on a virtual (windows) server? 

[Justin Derrick]

The 'chaotic' issues start with balancing the concerns of multiple applications -- it's not just a matter of when can you take CMOD down, but an issue of what are the SLAs and scheduled downtimes and permitted outage windows for ALL applications on the shared machine.  It usually only gets worse from there. 

As I mentioned previously, using virtual machines allows for the fast and easy migration to new hardware without impacting other applications (running inside their own VMs) on the server.

Good luck!

-JD.

[Shannan]

Thanks for the input!  Sounds like the data movement isn't the issue, but more the server and it's applications, etc..., correct?  Don't want to set us up for an impossible future migration if/when the day comes. 

On the virtual - one of my network people said they weren't suggesting the virtual environment for db driven systems - have you had any issues with this?  (we were discussing CM on virtual at the time rather than OD)

[Justin Derrick]

The decision about VMs is up to you and your architecture team.  If you think the server is going to be big (10TB+), or it's going to be accessed by the general public (whose usage is unpredictable), yes, having it on it's own physical server might make sense.  It's less about the type of load (database, webserver, computational) and more about the AMOUNT of load.