Licensing

For questions and comments regarding RTDA software licensing.

RTDA keyfile and RLM

Submitted by alanbarclay on Wed, 10/05/2011 - 17:22

RTDA supports two forms of licensing

  • RLM (Reprise License Manager)
  • Keyfile

Keyfile licensing is uses a file named 'license.key' (case sensitive) placed in the NC or LM vovserver's configuration (.swd) directory. This file is read by the vovserver and enables a number of slots for NC or a number of users for LM.

Keyfile licensing can only be used for NC and LM, and each vovserver needs its own license.key file. The keyfile is made for a specific hostid, RTDA product, and port number.

RTDA keyfile avoids the need to set up an RLM license server, so it is a little more reliable. However, since the keyfile is made for a hostid, port, product combination, it needs to be re-made if you want to move the NC/LM vovserver to a different machine.

The other significant difference is that with RLM, a machine grabs as many core licenses as the OS says there are processors, where with keyfile, it is the number of job slots configured on the machine.

For an extreme example, a 2-chip hex-core Xeon machine with hyperthreading on, the OS would say it has 24 processors (2 chips * 6 cores/chip * 2 threads/core), so it would take 24 cpu_* licenses with RLM, but if configured with only 2 slots (e.g. for big physical design jobs) it would take only 2 core licenses with keyfile. Thus the NC administrator has more control of the license deployment with a keyfile license.

Another difference is that RTDA keyfile only supports one kind of license, cores/cpus for NC and users for LM. With RLM, the NC and LM licenses can be combined, and RLM also supports FlowTracer and WorkloadAnalyzer.

RTDA keyfile licenses can be concatenated. For example, if you have a perpetual NC license for 64 cores and purchase 24 additional cores for newly-added machines, that could be satisfied by appending a keyfile license for 24 cores to the end of the existing license. When doing so, please be careful to include the comment and blank lines between the two licenses.

Reprise Software RLM troubleshooting guide

Submitted by alanbarclay on Thu, 03/11/2010 - 13:23

Reprise held an online RLM troubleshooting webinar on 10-mar-2010, where participants received a PDF file containing troubleshooting steps and suggestions.   Reprise has graciously granted permission for RTDA to post it here.

Note: The RLM diagnostics are available in 2009.08 and later RTDA releases, which will use RLM version 8.

The RLM End-User manual may be found at:
http://www.reprisesoftware.com/RLM_Enduser.html

Reprise Troubleshooting Guide

 

Failover Licenses

Submitted by alanbarclay on Wed, 11/04/2009 - 13:00

The Reprise License Manager (RLM) used to license RTDA software supports redundant licensing for continued availability when the primary license host has crashed or is off the network.

In contrast to triple-redundant, or triad, license servers supported by FLEXlm, RLM uses a single failover license server. This failover server can support multiple primary servers.

However, it does not protect against RLM not running on the primary host. It only protects against machine crash or network problems that cause the primary host to be off the network.

You must prepare ahead of time to support license failover by selecting a failover host, and obtaining a failover license. Also, you must set the RLM_LICENSE environment variable to include the failover port@host before starting the RTDA tools. For example, a non-redundant setup might set RLM_LICENSE to 7070@bison. If your failover license server is named cheetah you would set RLM_LICENSE to 7070@bison:7070@cheetah.

In the above example, the contents of the RLM failover license on host cheetah would look something like:

HOST cheetah <cheetah-hostid> 7070
ISV rtdad ./rtdad
LICENSE rtdad rlm_failover 1.0 permanent 1 hostid=bison-hostid \
    _failover_host=bison sig="<complicated-alphanum-string>"

WARNING There is a problem in RLM that causes file descriptors to be leaked when the RLM_LICENSE variable includes a failover port@host but no RLM server is running there.

This will eventually cause the vovserver to become non-responsive when file descriptors are exhausted. you can identify the problem by examining the most recent vovserver log file
<project>.swd/logs/server.YYYY.MM.DD.log and searching for 'too many open files'.

If you plan to use RLM failover, we recommend that you set it up all at once, before starting the RTDA software. If this is not possible, please see the Note below.

Guru Note: It is possible to change a vovserver from non-redundant to failover licensing on the fly without a shutdown.

After you have started the failover RLM license server and confirmed that it is running, use the following commands:

% source /path-to-rtda/common/etc/vovrc.{csh,sh}

To get the RTDA commands in your PATH;
(use the one for your shell type)

% vovproject enable project-you-want-to-change
% vovsh -Y 'puts [vtk_server_setenv RLM_LICENSE port@primary:port@failover]'

You can confirm that the server environment was changed by pointing your web browser to

  http://server-host:server-port/server?page=environment

Substitute the values of your vovserver host name and port.

Syndicate content