[an error occurred while processing this directive]
HP OpenVMS Systems |
HP Advanced Server for OpenVMS
|
Previous | Contents | Index |
This chapter explains some License Server configuration changes you may need to make and the impact of those changes on the client(s). The License Server configuration information is explained in the following sections:
The License Server stores information in a database called the License Server state file, which exists on the system as:
PWRK$LICENSE:PWRK$LICENSE_SERVER_STATE.DAT |
The information that is stored in the License Server state file includes the following:
The following sections provide information about the License Server
state file and describe the procedure for recreating it.
3.1.1 License Server Name
The License Server state file stores the name of the License Server. This name is used to facilitate communication between the License Server and clients. When a client is assigned a license, part of the license information saved by the client is the name of the License Server that issued the license. This name is used to contact the License Server when the client attempts to verify its licenses. The name is defined in the following format:
PWRK$Lname |
When the License Server is started for the first time, the template License Server state file provided during installation does not contain the License Server name. The License Server determines its name as follows:
In either case, the value chosen as the name portion of the
License Server name is used to form the License Server name, which is
then stored in the License Server state file. Once established, the
License Server uses the name stored in the state file, even if the
SYS$CLUSTER_NODE or SCSNODE values should change.
3.1.2 Creating a New License Server State File
If the License Server state file is rendered unusable, the License Server will not run. You must create a new License Server state file if this happens. Follow these steps to create a new License Server state file:
Once enabled, the License Server determines its name and initializes the License Server state file before it responds to any client requests. See Chapter 4, Managing Licenses on the OpenVMS Platform, for information about using the License Manager.
Because the License Server begins running with a new License Server state file, all information from any previous License Server state file is lost, including the License Server name, any group information, and all records of client licenses that were previously assigned. If license groups were being used, you must recreate the groups and allocate licenses to them.
When the License Server starts with the new state file and determines its name, two possible problems can occur:
There are two recommended methods for changing the system on which the License Server is run. You can move the License Server and retain the same server name or you can move the License Server and change the server name.
When you move the License Server and retain the server name, it is transparent to users. Clients will not notice that the License Server has moved.
When you move the License Server and change the server name, there is an impact on both server administration and clients:
Use the following procedures for moving the License Server and
retaining the server name or moving the License Server and changing the
server name.
3.2.1 Moving the License Server and Retaining the License Server Name
For the purposes of this example, the License Server is currently running on a system called SYS1, and the License Server is to be moved to a system called SYS2, which is not currently running a License Server.
For the purposes of this example, the License Server is currently running on a system called SYS1, and the License Server is to be moved to a system called SYS2, which is not currently running a License Server.
If there are no available licenses for the version of the server that the client requests, the licensing software looks for a license for a higher version.
By default, the software looks for licenses for subsequent major and minor releases up to 4.3 versions beyond the requested version.
For example, if the request is for Version 5.1, and no licenses are available, the License Server looks for the following license versions in the LMF database:
5.2, 5.3, 5.4
6.0, 6.1, ..., 6.4
7.0, 7.1, ..., 7.4
8.0, 8.1, ..., 8.4
9.0, 9.1, ..., 9.4
You control the version limits by defining the following logical name in the systemwide logical name table before starting the licensing software:
PWRK$LICENSE_VERSION_LIMIT |
You can define the logical name in two different formats:
"+MM.mm"
"MM.mm"
For MM substitute the major release number; for mm substitute the minor release number. The + means that the version is incremental. For example, the highest version searched is the current version plus the incremental version. Without the +, the release number is the absolute value and the search ends at the specified version.
Example 1:
$ DEFINE/SYSTEM PWRK$LICENSE_VERSION_LIMIT "+1.3" |
In this example, the license software looks for licenses for one major release beyond the requested version, and for licenses for three point releases beyond the requested minor release version. If the request is for Version 5.1, and no licenses are available, the License Server or License Registrar looks for licenses in the LMF for the following versions:
5.2, 5.3, 5.4
6.0, 6.1, 6.2, 6.3, 6.4
Example 2:
$ DEFINE/SYSTEM PWRK$LICENSE_VERSION_LIMIT "6.2" |
In this example, the license software looks for licenses for major software versions up to and including Version 6, and for licenses for point releases up to and including .2. If the request is for Version 5.1, and no licenses are available, the License Server or License Registrar looks for licenses in the LMF for the following versions:
5.2
6.0, 6.1, 6.2
In the case where a client is attempting to acquire a client-based PATHWORKS for OpenVMS (Advanced Server) license and no PATHWORKS for OpenVMS (Advanced Server) licenses are available on the local system, the license lookup function may find an Advanced Server for OpenVMS license for the client if one is available. (Advanced Server for OpenVMS licenses are valid for accessing both PATHWORKS for OpenVMS (Advanced Server) servers and Advanced Server for OpenVMS servers.)
Installing the License Server in an OpenVMS Cluster environment provides license service failover in the event that license services terminate on the node running the active License Server.
Normally, the License Server process (PWRK$LICENSE_S) is started on every node of the OpenVMS Cluster that starts the file server, but only one License Server process is active at any one time. The other License Server processes remain dormant until an event, such as system shutdown or a system failure, causes the active License Server process to stop. When the active License Server stops, one of the dormant License Servers becomes active and continues to provide license services to clients.
In most cases, HP recommends that you run the License Server on all nodes of the cluster that run the file server, for maximum availability. The exception is the case where the License Server will serve licenses to WAN clients. Then you will want to limit the License Server to running on one node of the cluster.
In an OpenVMS Cluster environment, the License Server state file is maintained cluster-wide. The file server directory tree starting at PWRK$ROOT must be on a disk that is common to all nodes on the OpenVMS Cluster.
There are a number of ways to determine which node is running the active License Server:
$ SHOW SYSTEM Pid Process Name State Pri I/O CPU Page . . . 00000230 PWRK$LICENSE_S HIB 6 191 0 00:00:01.67 777 . . . |
@SYS$STARTUP:PWRK$DEFINE_COMMANDS.COM |
Figure 3-1 License Server Startup Error Message
License Server cluster-alias is now processing LAN Manager license requests on node active-node |
To prevent the License Server from running on a particular node, you can add the following logical name definition to that node's startup command procedure:
$ DEFINE/SYSTEM PWRK$LICENSE_SERVER_INHIBIT 1 |
In a cluster environment where all nodes use the same startup procedure, check the node name before executing the DEFINE command. |
The SYS$STARTUP:PWRK$LICENSE_S_START.COM file has information about
this logical. The initial value of this logical (and its only value, as
it does not define a dynamic parameter) is logged in the License Server
log file
PWRK$LOGS:PWRK$LICENSE_SERVER_servername.LOG.
The Advanced Server for OpenVMS License Server interprets the value associated with the PWRK$LICENSE_SERVER_INHIBIT configuration parameter in the same manner as does the PATHWORKS V6 for OpenVMS server. This is different from the way a PATHWORKS V5 for OpenVMS server interprets it. Under PATHWORKS V5 for OpenVMS, a value of zero for this parameter indicates that the License Server will be prevented from running on the local node. With Advanced Server for OpenVMS, the configuration parameter value is interpreted as follows:
|
The following example shows how to prevent the License Server from running on node SPOT:
$ IF F$TRNLNM("SYS$NODE") .EQS. "SPOT::" THEN - DEFINE/SYSTEM PWRK$LICENSE_SERVER_INHIBIT 1 |
The next example shows how to allow the License Server to run only on node ROVER:
$ IF F$TRNLNM("SYS$NODE") .NES. "ROVER::" THEN - DEFINE/SYSTEM PWRK$LICENSE_SERVER_INHIBIT 1 |
You can specify the following logical name definition to define which nodes you want the License Server to run on. By default, if this logical is not defined, the License Server will run on all nodes.
$ DEFINE/SYSTEM PWRK$LS_LICENSE_NODES "node1, node2, node3" |
Each node name that you add to this comma-separated list is a node that is allowed to run the License Server. Any node in your OpenVMS Cluster that is not specified in the list when the logical is defined, will not run the License Server.
If you define PWRK$LS_LICENSE_NODES, and define PWRK$LICENSE_SERVER_INHIBIT (described above), the settings you define with PWRK$LS_LICENSE_NODES supersede any settings defined with PWRK$LICENSE_SERVER_INHIBIT. |
The number of client-based licenses available for a product may change because additional product licenses are added to the LMF database, or existing licenses are unloaded, disabled, deleted, or expired from the LMF database.
The License Server must check the LMF database to verify license counts for products currently in the License Server database. The License Server database is updated to reflect LMF database changes at the following times:
You can change the time at which the synchronization occurs by defining the logical PWRK$LSLMFSYNCHMINUTES, as described in Section 3.5.2, Scheduling the LMF Synchronization.
Previous | Next | Contents | Index |