This chapter helps you decide which nodes to use as license server nodes. The following issues are discussed:
This section discusses the resources used by the license server. When you select a server node, you may need to take into account the system limits on these resources. For small numbers of licenses (under about 100), most of these items should not be a problem on any workstation.
When you run lmgrd, it automatically starts up one copy of each vendor daemon specified in the DAEMON line(s) in the license file. Each time a TCP client connects to the server, it uses a process file descriptor. If the maximum number of file descriptors is exceeded, additional vendor daemons will be started to accommodate the overflow requests. Globetrotter Software has found that this is a rare occurrence—even on large networks. See your operating system's documentation to determine what the maximum number of file descriptors is for your computer.
When using TCP a single vendor daemon can support as many users as the system limit for file descriptors, which ranges from 256 on SunOS 4.x to 4000 on OSF/1. When files are exhausted, additional vendor daemons are spawned to allow for extra file descriptors. When using UDP, there is no limit to the number of end users per vendor daemon process, since they can share a single socket in the vendor daemon.
Each client connected to a license server uses one socket. The total number of sockets used by the license server programs is slightly larger than the total number of simultaneous clients.
If you have a very large number of licenses (a few hundred), you should confirm that the system limit on the number of sockets and file descriptors is adequate to handle all of the licenses.
On SCO®systems, the default number of sockets may be set fairly low; if you choose to run a server on such a machine, you may need to reconfigure your kernel to have more sockets.
For small numbers of clients, the license servers use very little CPU time. The servers might have only a few seconds of CPU time after many days.
For a large number of clients (who are each exchanging heartbeat messages with the server), or for high checkout/checkin activity levels (hundreds per second), the amount of CPU time consumed by the server may start to become significant although, even here, CPU usage is normally not high. In this case, you may need to ensure that the server machine you select will have enough CPU cycles to spare.
 | Note: Globetrotter Software has never encountered a situation where CPU cycles were an issue. |
The only output file created by the license server is the log file. The log file contains one line for each checkout and one line for each checkin. If you have a lot of license activity, the log file will grow very large. You will need to consider where to put this file and how often to delete or prune it. The license administrator can opt not to log messages if disk space is at a premium. See “NOLOG” and “REPORTLOG”.
Note that the log file should be on a local file on the server machine. See “Diskless Nodes and Remote Mounted Disks” for a discussion of remote file systems.
The daemon log file output can be switched after the daemons are running. The technique to do this involves piping the stdout of lmgrd to a shell script that appends to the file for each line.
This is done as follows:
Instead of the “normal” startup:
% lmgrd> LOG |
Start lmgrd this way:
% lmgrd | sh -c 'while read line; do echo "$line" >> LOG ; done' |
With this startup method, the output file “LOG” can be renamed and a new log file will be created. You could even make “LOG” a symbolic link and change the value of the link to switch the log file.
The FLEXlm daemons use little memory. Typically, lmgrd uses approximately100 kB and the vendor daemons use approximately 120 kB each.
FLEXlm sends relatively small amounts of data across the network. Each transaction, such as a checkout or checkin, is typically satisfied with less than 1Kbyte of data transferred. This means that FLEXlm licensing can be effectively run over slow networks (such as dial-up SLIP lines) for small numbers of clients.
For large number of clients (hundreds), each of which will be exchanging heartbeat messages with the vendor daemon, the network bandwidth use may start to become significant. In this case you should run client and server on the same local area network.
In high-traffic networks you may also want to avoid setting LM_LICENSE_FILE to a port@host address. Instead, the license administrator should place a copy of the license file in a filesystem local to the application. See “Specifying Location of the License File” and Chapter 3, “The License Finder.”
Globetrotter Software recommends that you do not use remote mounted disks when you run the license server. In other words, we recommend that lmgrd, the vendor daemons, the license file, and the log file are all on locally mounted disks. If any of these files is on a remote mounted disk, you will be doubling the points of failure which could lead to a loss of all of your licenses. When all files are mounted locally, the licenses will be available as long as the server machine is up; but when the files are on a different machine, then the loss of either the license server machine or the file server machine will cause the licenses to not be available.
Diskless nodes are the extreme case of not using local disks. We recommend that you do not use diskless nodes as license servers, since the files are necessarily accessed from a remote disk. In addition, FLEXlm sometimes (at the option of the vendor) makes a security check which fails on a diskless node. If you find that you are having problems with a lock file, one possibility is that you are attempting to run on a diskless node. The simplest solution is to select a different node for your license server.
With FLEXlm you can set up redundant license servers to operate as a single logical license server. This feature is controlled solely by the SERVER lines in the license file; the software vendor does not need to do anything in his application or in his vendor daemon to enable this capability.
Redundant servers help ensure the availability of your licenses in the event of a system crash. The cost is some additional administration. If you are willing to deal with the extra overhead, and you want to ensure that all of your licenses are available even if one machine crashes, then you may want to use redundant servers.
Alternatively, working with your software vendor you may be able to split up your licenses among multiple independent servers. This is simpler to administer, and still allows you to have at least some of the licenses available even if one machine goes down.
To set up redundant servers, you must provide the hostid for three machines to your software vendor, who will in return give you a license file with three SERVER lines. You need to make sure that each license server has lmgrd, the vendor daemon program and the license file on a local file system. (For some caveats on remote file systems, see “Diskless Nodes and Remote Mounted Disks”). You then start lmgrd on each license server.
In a redundant server configuration, no licenses are available until there is a quorum of servers. A quorum of servers is defined as a strict majority of the servers listed in the license file, so a quorum in a three-server configuration is two. In other words, if only one server in a three server configuration is running, then no licenses will be available. As soon as two of the three servers are running and communicating with each other, then all of the licenses will be available.
The license file will determine whether a license server is needed. If all the FEATURE (or INCREMENT/UPGRADE) lines have a license-count of 0 (UNLIMITED), then no server is needed. This type of license can be called uncounted. Alternatively, if any FEATURE lines have a non-zero license-count, then a server is required to count those licenses. If a vendor wants to use FLEXlm without a server, they must issue uncounted licenses.