ADSM-L

Re: Multiple instances + shared TSM configuration

2005-03-23 09:31:16
Subject: Re: Multiple instances + shared TSM configuration
From: asr AT UFL DOT EDU
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 23 Mar 2005 09:30:58 -0500
==> On Wed, 23 Mar 2005 08:34:58 -0500, "John E. Vincent" <adsm-l-alias AT 
clacorp DOT com> said:


> I have another one that just came up though. As I've mentioned in the
> past, we're running tsm 5.2.2 and db2 8.1.4.

> On one of our development boxes, we've setup a second instance. This is
> strictly for resource isolation but we'd like to share backups between the
> two instances freely. The instances aren't federated at all. Since I have
> multiple instances, what's the best way to share backups between these two?

> If I create multiple nodes, is there a way to specify a different dsm.sys
> for the second instance?

> Is it even possible to share a node across multiple instances on the same
> machine?


You can certainly share a node across instances, in fact you have to do some
work to -avoid- it. :)

If you specifically want to share backups between them, then I assume you're
prepared for the opportunities for chaos when both copies of database FOOBAR
cut log LOG0000012.LOG, and the need to distinguish by timestamp the full
backups that came from FOOBAR on db2inst1 vs. FOOBAR on db2inst2.

The way we specify different configurations for our different instances is to
have a ~/tsm/tsm.opt file in the instance homedir for every instance.

We refer to it by having the instance's environment contain the right DSMI*

DSMI_DIR=/usr/tivoli/tsm/client/api/bin
DSMI_CONFIG=/u/ne6prd8/tsm/tsm.opt
DSMI_LOG=/export/db2home/ne6prd8/tsm/

These tsm.opt files consist of a single line.  For example, for the instance
named 'ne6prd8', the line is


server dbback_ne6prd8


which you'll recognize as a reference to a server stanza in the dsm.sys.  That
stanza looks like this

servername dbback_ne6prd8
   COMMmethod         TCPip
   TCPPort            1610
   TCPWindowsize      64
   TCPBuffsize        128
   TCPServeraddress   tsm-int.cns.ufl.edu
   passwordaccess     generate
   nodename           ne6prd8


and I've got one for every instance, production, test, etc..


So: I'm using the same dsm.sys to communicate many different "server"
configurations, most of which differ mostly by the nodename asserted.  I'm
telling each db2 instance which "server" to use via the tsm.opt, which is
private to the instance.


To get the two-instances-using-same-node behavior, then all I need to do is
tell both db2inst1 and db2inst2 to use the same "server".  Since they're on
the same hardware, you will have all the password cache behavior taken care
of.


In fact, if you're content with both of the instances having their backups
conflated with the node's system backups, you can avoid the entire rigamarole,
and the API will use the system TSM setup.


- Allen S. Rout

<Prev in Thread] Current Thread [Next in Thread>