I have things configured pretty much as you describe, and I also use
dsmcutil to create the services when using a cluster- Way easier to reduce
mistakes since I can throw it into a batch file and run it on both sides of
the cluster. :)
The issue I'm seeing, though, can be duplicated on a non-cluster. (however
the results seem to happen on some systems but not others) If you take a
Windows 2000 or 2003 server and try the following:
1. Install a regular dsmcad, agent and scheduler service using the default
baclient\dsm.opt file.
2. create a second options file named something different such as dsm2.opt
3. install a second set of services, named differently, and using the
dsm2.opt, and using a different nodename from the first set. (ie. you would
use this if setting up a scheduler for an agent perhaps, or for a cluster
resource group).
4. before starting the dsmcad service, start up a console window
(dsmadmc -console)
5. start dsmcad, wait the minute for the scheduler to kick in
What I see on the console (and in the actlog) is:
- an inital connection using the correct (second) nodename, by the dsmcad as
soon as I start the service
- 1 minute later, I see two more client connections as the scheduler
connects. the first connection uses the wrong (first) nodename, the second
connection uses the correct (second) nodename.
other than that, everything seems to work correctly.....
Paul
----- Original Message -----
From: "TSM_User" <tsm_user AT YAHOO DOT COM>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Monday, February 14, 2005 9:58 PM
Subject: Re: [ADSM-L] Bug? Using multiple client service instances on
Windows server
We have over 20 Windows 2000 Cluster servers. On all of these servers we
have to create 2 sets of all the services. One for the local drive and one
for the cluster. We have never run into the issue you are speaking of.
We use the dsmcutil command to create all our servers via scripting. The
only issue I have ever seen is that if you don't use the short 8.3 name
for the path for "/clientdir" then you can have problems.
I'm not sure if this will help but here is an example of what we use.
ex:
"C:\Program Files\Tivoli\TSM\Baclient\DSMCUTIL" Install /name:"TSM Central
Scheduler" /node:%COMPUTERNAME% /clientdir:C:\Progra~1\Tivoli\TSM\Baclient
/optfile:C:\Progra~1\Tivoli\TSM\Baclient\dsm.opt /pass:%COMPUTERNAME%
/startnow:no /autostart:no
One thing I have noticed is if you ever create services on a cluster you
must ensure that you create them adding the /clustername and /clusternode
options. Also, you have to use the /clusternode:no for the services you
create that aren't for the cluster. Finally you also have to make sure
that you create the cluster services first. If you don't do this
correctly you will get errors but they aren't all as clear as I would
like.
Paul Fielding <paul AT FIELDING DOT CA> wrote:
Several years ago I noticed an interesting behavior when installing
multiple client scheduler services on a server. A ticket was opened with
IBM and the final word came back that there was indeed a bug, the apar was
opened, and we were told it would be resolved. This week I've encoutered
the same situation, so I'm wondering if anyone has also noticed this
behavior? I no longer have the apar number of the original ticket, so I
can't check to see the apar's status.
When installing a scheduler service (with apropriate cad, etc) you must
supply the dsm.opt file fo the service to use. For the first nodename on
the server, this is typically the Tivoli\TSM\baclient\dsm.opt file. When
installing the second set of services for an alternate nodename, you must
supply an alternate dsm.opt file.
If you run a dsmadmc -console while starting the CAD, you may notice that,
when the scheduler service contacts the TSM Server, it touches the server
twice. Under normal circumstances, this is just something I shrugged off
as an 'interesting' thing.
However, after the second service instance is installed, when starting up
the CAD, I noticed that the the first of those two connections was using
the wrong nodename - instead of connecting to the TSM server with the
nodename of the second service, it connected with the nodename of the
first service. The second connection attempt then proceeded to use the
correct nodename. Not knowing exactly what information is sent on each of
those connections, I do not know the implications of this.
Basically what was happening was that when the scheduler service first
starts it grabbed the default dsm.opt location, instead of using the
dsm.opt file defined for that service. By the time it makes it's second
connection attempt, it's read the correct dsm.opt file.
The temporary band-aid was to configure the first scheduler service to use
a *non-standard* dsm.opt - the result being that when the second service
tried to connect using the default location, it failed to find a dsm.opt
file there, and simply connected sucessfully on the second attempt, using
the correct dsm.opt file.
More recently, I've noticed that when this situation occurs, if you set
the first service to use a non-standard dsm.opt file, during the install
process I initially get an error message stating that the service 'Could
not find c:\Program Files\Tivoli\TSM\baclient\dsm.opt' , even though
that's not the dsm.opt file I told it to read. The service then goes and
sucessfully installs. *shrug*.
It doesn't appear to be causing any real grief, but I'm wondering if I'm
the only one seeing this behavior or not, and if anyone may know of any
genuine grief this could cause?
regards,
Paul
---------------------------------
Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term'
|
