Maintaining the Redundant License Manager Pool

Once redundant License Managers are set up, you can use lspool or WlmAdmin from any computer on the network to view information about the redundant License Manager pool. You must set the LSHOST environment variable to point to one of the redundant License Managers when using lspool.

NOTE   Some lspool options dynamically change the redundant License Manager configuration, but do not write the changes permanently to the redundant license file. When the redundant License Managers are restarted, the changes are lost. However, other lspool options make permanent changes. See Using lspool to Maintain a Redundant License Manager Pool for more details.

Following are some Redundant License Manager Pool maintenance related scenarios.

Scenario 1: Adding a Redundant License Manager to an Existing License Manager Pool

The system administrator can add a redundant License Manager to an existing License Manager pool using the following steps.

Let's assume that an existing pool, consisting of S1, S2, and S3 hosts, exists in the network and a new redundant License Manager host S4 is to be added.

The steps are listed below:

1.Obtain the redundant license configuration file (lservrlf) from the leader License Manager S1.

2.Place the file obtained in step 1 into the S4 License Manager's installation directory.

3.Edit the file using the rlftool utility and add S4 to it.

4.Restart the License Manager on S4.

5.Add S4 to the pool using the lspool utility (using the -a command described above) from the leader License Manager.

Scenario 2: When the Leader License Manager Goes Down and Comes Up

When the leader License Manager goes down, it sends the message to the follower License Managers in the pool. Then, one of the followers, having highest priority, declares itself as the new leader of the pool. All the new license requests will obtain tokens from the new leader and existing requests will be transferred to the new leader as well (during their token updates routine). Meanwhile, if the original leader comes up again as a redundant License Manager, then it will be restored as the leader. Leader conflict occurs but seamlessly gets resolved on the basis of priority of License Managers defined in lservrlf. If there are any running clients, they shift to the leader License Manager using the failover mechanism.

Scenario 3: The lservrlf File is Corrupted

If any RMS License Manager is started with a corrupted lservrlf file, it never becomes redundant License Manager. It acts like a non-redundant License Manager. If an existing lservrlf file gets corrupted, then any new changes in lservrlf will not be reflected.

Scenario 4: Simultaneous Editing of Redundant License File

If you are editing an existing redundant license file, to avoid synchronization problems because someone else is adding licenses in the redundant license file while you have it open, we recommend you make a copy of the file under another name, make your changes, and then rename it back to its original name when you are done. The changes you make to the redundant license file will not take effect until you copy the changed file to a redundant License Manager in the pool (or edit it directly on the License Manager using the precautions discussed above) and then restart that License Manager.