ADSM-L

Option Set management

2004-08-03 20:37:04
Subject: Option Set management
From: Steve Harris <Steve_Harris AT HEALTH.QLD.GOV DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 4 Aug 2004 10:36:11 +1000
Hi all,

I'm wrestling with client option set management in a distributed TSM 
environment.

I currently have one TSM instance and manage option sets by nested macros, with 
changes to the options file where the difference is unique to this server.

e.g.
nt_common_cloptset.mac :
define clientopt %1 inclexcl 'exclude "*:\microsoft uam volume\*"'
define clientopt %1 inclexcl 'exclude "*:\microsoft uam volume\...\*"'
define clientopt %1 inclexcl 'exclude "*:\...\ea data. sf"'
define clientopt %1 inclexcl 'exclude "*:\...\pagefile.sys"'
...
define clientopt %1 inclexcl 'exclude "*:\WINNT\security\edb.log"'
  
and this is invoked by

nt_oracle_cloptset.mac : 
delete cloptset nt_oracle
define cloptset nt_oracle description="Standard Options for NT Oracle Database 
servers"
define clientopt nt_oracle schedmode prompted
define clientopt nt_oracle subdir yes
macro nt_common_cloptset.mac nt_oracle
macro nt_common_cloptset_arch.mac nt_oracle
define clientopt nt_oracle inclexcl 'exclude.dir "*:\Oradata"'
define clientopt nt_oracle inclexcl 'exclude.archive "*:\Oradata\*"'
...
define clientopt nt_oracle inclexcl 'exclude "listener.log"'
define clientopt nt_oracle inclexcl 'exclude.archive "listener.log"'

upd node QHCESA-DB1 clopt=nt_oracle
upd node QHOBI-DB1 clopt=nt_oracle
upd node age-db1   clopt=nt_oracle

This all works fairly well in the reasonably controlled environment that I 
currently service.

The new environment will have 25 or more TSM servers and thousands of clients, 
with a wide geographic spread, controlled centrally.

I'd like to 

1. Make node installations as easy as possible 
2. enforce standard backup policies everywhere

But, I don't have any control over the clients, there are no standard directory 
names (other than as supplied by the OS), filesystem layouts, nothing.

Thus I need to be able to distribute tight Client option sets for each sort of 
client,  but with enough flexibility to allow for client to client differences. 
 I also need to be able to make the same change to all clients of a given 
class, eg to stop backing up all *.gif files.

All I can think ofat the moment is some sort of programmatic Cloptset 
generation process, but that is difficult to update. What would be nice would 
be a facility to allocate multiple optionsets to a node, in a defined heirachy, 
but that function isn't available yet ;(

I'm sure some of you university environments have met this sort of issue 
before.  How did you solve it? 

  




***********************************************************************************
This email, including any attachments sent with it, is confidential and for the 
sole use of the intended recipient(s).  This confidentiality is not waived or 
lost, if you receive it and you are not the intended recipient(s), or if it is 
transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this 
email is prohibited.  It may be subject to a statutory duty of confidentiality 
if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in 
error, you are asked to immediately notify the sender by telephone or by return 
email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************

<Prev in Thread] Current Thread [Next in Thread>
  • Option Set management, Steve Harris <=