Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

PWRK$LMSRV process switching nodes

SOLVED
Go to solution
Douglass Anderson
Regular Advisor

PWRK$LMSRV process switching nodes

Why is PWRK$LMSRV process switching nodes in a two server cluster?
Also, Is there an easy way to force it to switch to a different node?
8 REPLIES
Karl Rohwedder
Honored Contributor
Solution

Re: PWRK$LMSRV process switching nodes

It's long time ago, what I used Pathworks on more than one member in a cluster, but switching from one node to another node is a totally new concept for me :-).

What hardware and software are you running?
Are there any error message in the logfiles
under PWRK$LOGS and PWRK$LMLOGS?

regards Kalle

Re: PWRK$LMSRV process switching nodes

Good Morning Douglass...

Your Pathworks question(s) is one of intrigue. I'm sorry to have to respond to your question with a question, but, are you saying that the "pwrk$lmsrv" process is stopping on one node and then restarting on the second node in the cluster? If so, do any of the other Pathworks processes such as pwrk$lmmcp or the pwrk$xxdaemon processes also stop and start?
Do you have cluster/group name aliasing enabled, and/or DNS Round-Robin Load Balancing? Karl's suggestion of checking the "evtlog.dat" file may prove very beneficial..

Thanx,
whynot3k

Douglass Anderson
Regular Advisor

Re: PWRK$LMSRV process switching nodes

Hardware: 2-node homogenous ES40 cluster, running OpenVMS V7.3-1.
Software: Advanced Server V7.3A for OpenVMS (V7.3-120A)

The PWRK$LMSRV process does not stop. It's only used on one node or the other when people connect to Pathworks services via the OSICS alias. The switch from node to node was what I'm curious about. I thought that Pathworks did not automatically load balance
Most likely, this issue has something to do with our DNS switching the order of the node entries for the OSICS alias...
That's how load balancing works for TELNET users. I thought Pathworks worked differently
Robert Gezelter
Honored Contributor

Re: PWRK$LMSRV process switching nodes

Douglass,

I am in the middle of something at the moment, but check if it is on the node with the lower CPU utilization.

If that is the case, you can force the CPU utilization (and the server to the other node) by running a CPU-bound loop at a VERY low priority -- say 0). For example, the program:

$ x: goto x

in a batch job at priority 0 would do the trick.

- Bob Gezelter, http://www.rlgsc.com
Uwe Zessin
Honored Contributor

Re: PWRK$LMSRV process switching nodes

It depends on the node lookups. One of my customers uses a NETBIOS entry with 2 IP-addresses in a WINS server. There is a tool on Microsoft's web site for diagnostics in this area:
http://support.microsoft.com/kb/830578/en-us
.

Re: PWRK$LMSRV process switching nodes

Good Morning Douglass...

I believe that you are correct regarding the telnet users and the OSICS aliasing for the two nodes in the cluster, due to the "Group-Name-Alias" and Round-Robin servicing within the DNS-Server. If I remember correctly, your suspicion that Pathworks worked differently, is also correct -- in a manner of fashion.

I seem to remember that Pathworks actually supported multiple "user-connect" protocols; such as TCP/IP, serviced by the "knbdaemon" process; NETBEUI, serviced by the "nbdaemon" process; as well as DECNET, etc. And the Load-Balancing was actually a function of an application or protocol-service for DECNET (60-03), or TCP/IP (08-00), or whatever; and not actually Pathworks "per se". I believe that DECNET utilizes a "Cluster-Alias", which is very similar to "Group-Alias" for TCP/IP.

So you might be able to test/verify the Load-Balancing is working as expected, by having a specific user connect via NETBEUI or DECNET (and assuming no "Cluster-Alias" having been defined), instead of using the telnet-TCP/IP protocol which would use the DNS Server for "Group-Name-Alias".

I shall try and dig thru some old notes and documentation, as I think that there may be a way of defining "relative-cpu" performance, (hence, defining which system should handle more workload) for DECNET Load-Balancing via one of the NCP/NCL/LANCP utilities... Hope this helps.

Thanx,
whynot3k

Re: PWRK$LMSRV process switching nodes

Good Morning Douglass...

After checking on some notes and with a fellow colleague, we did come across a couple more items for you Pathworks Cluster. The following "NCP" commands help to define the Cluster-Alias and max connections for a Pathworks v4.x environment with Decnet-Phase-IV...

NCP> SET EXECUTOR ALIAS INCOMING

Specifies whether the local node is willing to accept incoming requests directed to the alias node identifier specified for the local node. The alias node identifier is described under the ALIAS NODE parameter. There are two options for ALIAS INCOMING:

ENABLED Specifies that the local node will accept incoming connect requests directed to the alias node identifier. This is the default if an alias node identifier has been specified.

DISABLED Specifies that the local node will not accept the incoming connect requests directed to the alias node identifier.

NCP> SET EXECUTOR ALIAS MAXIMUM LINKS

Specifies the maximum number of logical links for the local node that can use the alias node identifier. The alias node identifier is described under the ALIAS NODE parameter. The maximum value for
ALIAS MAXIMUM LINKS is 200. The default value is 32.

As you can see from the above commands, there was a limitation for max-links of only 200.

I have also attached a text file, that is a portion of the Pathworks v5.x documentation that explains how to set up a "Pathworks-Cluster-Alias" which is NOT the same as the "Decnet-Cluster-Alias".

This procedure is transport/protocol independent and will Load-Balance between the two (or more) nodes in a cluster, regardless of TCP/IP, Decnet, Netbeui... Be advised that if there is already a "Decnet-Cluster-Alias" in place, you must stipulate a different name for the "Pathworks-Cluster-Alias." Hope this helps...

Thanx,
whynot3k
Douglass Anderson
Regular Advisor

Re: PWRK$LMSRV process switching nodes

solved