After a node joins the cluster clustering license does not load

[Ziggy Filek]

I have a cluster with 3 ES80s on a common sistem disk on an EVA.
I tried to boot an AS2100A with a private system disk into this cluster by copying the CLUSTER_AUTHORIZE.DAT and setting VAXCLUSTER to 2. The node did successfully join the cluster, but allowed only logins from its console complaining "Product requires software license".
What is worse the ES80s were OK until you tried to boot them, in which case they would disable logins complaining "VMSCLUSTER license not loaded".
The AS2100 does have a VMSCLUSTER license loaded with the required 1100 units, but these units were obtained by using the MOD_UNITS option on a 1050 units license (reason:laziness). the ES80s have the proper 3300 units between them. Is this a problem with using the "MOD_UNITS" option (in which sace registering the original PAK on the AS2100 license database should fix it) or is it a problem with there being two license databases. Where should be the AS2100 belonging units registered?
I'd be grateful for any insights.
Ziggy

[Karl Rohwedder]

The 'normal' way would be to install a single cluster-wide license database on a shared disk.
The individual licenses can then be setup for the specific nodes using the /INCLUDE or /EXCLUDE qualifiers.

regards Kalle

[Jan van den Ende]

Ziggy,

if for some reason Kalle's proposal (being the better solution normally) can not be used, the, for each node,
--- in SYLOGICALS !!!!
DEFINE/SYSTEM/EXEC LMF$LICENSE_LDB to point to the LDB that contains (ALL of) its licenses.
(oops, this is from memory, not real sure that this is the exact logical name, please verify!)
The important things are the /EXEC, and the timing of the DEFINE : very early in the bootstrap, only SYLOGICALS (or called from that) will do.

But again, a cluster common LMF is preferable.
And if that is NOT on a common system disk in SYS$COMMON, then you also need the above logical name.

hth

Prost.

Have one on me.

jpe

Proost.

[Karl Rohwedder]

The logical name for the license database is:

(LNM$SYSCLUSTER_TABLE)

"LMF$LICENSE" = "CNC_SF:LMF$LICENSE.LDB"

regards Kalle

[Volker Halle · Accepted solution]

Ziggy,

another strategy regarding license databases in a cluster with multiple system disks is:

- put all licenses from all systems into one file
- copy that one file to all system disks into SYS$COMMON:[SYSEXE]
- whenever you make updates to that one file, re-copy it

This is guaranteed to always work. Whether a license db on a common disk can be accessed early enough during boot, may change in future releases.

The problem is as follows:

When a node has to load a license, it compares the cluster-wide loaded license units against the value in it's license database. If the no. of loaded units exceeds the units in it's license database, it will not load the license.

In your example, the ES80 sees 3300 units loaded (the other 2 ES80 + the Alpha 2100). It only has 3300 units in it's local license db, so it won't load that license.

Volker.

[Ziggy Filek]

Volker: Thanks for your help.
When one issues $LICENSE LOAD , what gets loaded is the total units available in all PAKS registered, not just the minimum units necessary for that node. When you write:

"In your example, the ES80 sees 3300 units loaded (the other 2 ES80 + the Alpha 2100). It only has 3300 units in it's local license db, so it won't load that license."

do you mean not total units "loaded" but total units "used" by all nodes already in cluster?
Everybody:
I intend to try the following: Register and load the original AS2100 PAK for clustering on the big cluster (this will add 1100 units for the total of 4400 units) and then, on the AS2100, issue
$LICENSE MODIFY /UNITS=4400 VMSCLUSTER
this is because I have tons of licenses on 2100 that have nothing to do with the big cluster, and I want to avoid reistering them everywhere.
Do you think my approach will work?
Thanks
Ziggy

[John Gillings]

Ziggy,

>$LICENSE MODIFY /UNITS=4400 VMSCLUSTER
>this is because I have tons of licenses
>on 2100 that have nothing to do with the
>big cluster, and I want to avoid
>reistering them everywhere.
>Do you think my approach will work?

It might "work", but it's in direct contravention of your license agreement. Increasing the units on a PAK is only allowed while the node the PAK was purchased for is being repaired, and a larger capacity system is being used as a temporary replacement.

> do you mean not total units "loaded" but total units "used" by all nodes already in cluster?

All license PAKs except those with option "NO_SHARE" are inherently cluster wide. All nodes must LOAD sufficient units for all cluster nodes that wish to use the product. For AVAILABILITY PAKs that means when a node LOADs a product, it needs to see enough units to cover the usage requirments of all nodes in the cluster which have the product already loaded, plus its own usage.

The simplest way to do that is with a common LDB. If that's not feasible, make sure all nodes have an exact copy of the same LDB. Although it's sometimes possible to make things work with non-identical LDBs, it's very likely you'll create a boot order dependence. Murphy's law says you won't realise until the most inconvenient possible time.

If you wish to restrict a particular product to a subset of nodes in the cluster, make sure all the PAKs for that product have an identical INCLUDE or EXCLUDE list.

One fairly straightforward way of dealing with the situation you describe is to "dump" your LDB as PRODUCT REGISTER commands. Make a copy of your LDB and use:

$ LICENSE ISSUE/PROCEDURE */ALL /OUTPUT=ALLPAKS.COM

Now merge the procedures from your cluster and the single node. Add commands to set INCLUDE lists where required. Again, use wildcards to make sure they're all identical:

$ LICENSE MODIFY someproduct/ALL/INCLUDE=(node1,node2,node3)

Execute the procedure to build a combined LDB. You also have a backup of all your PAKs in human readable form.

The easiest way to get your head around this behaviour is to stop thinking about the PAK as "belonging" to a particular node. Instead, think if it as that node's contribution to the cluster wide pool of license units.

[Ziggy Filek]

Just for the record, I (or rather my employer) owns clustering license for every node I have, so I'm not in violation of any license agreements. If you have bought units in succesive pieces on successive PAKs, then for test purposes it is sometimes much quicker to increase units than to register all of the original PAKs.
I have successfully completed my project and I have now a 4-node cluster. Your help was invaluable. I thank everyone very much for your time