Table of Contents * Previous Chapter * Next Chapter
This chapter helps you decide which nodes to use as license server nodes.
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.
Globetrotter Software has never encountered a situation where CPU cycles were an issue.
The only output files created by the license servers are the debug and report log files. These log files contain one line for each checkout and one line for each checkin. If you have a lot of license activity, these log files will grow very large. You will need to consider where to put these files and how often to delete or prune them. The license administrator can opt not to log messages to the debug log file if disk space is at a premium. See Section 6.2.9, `NOLOG,' on page 32 and Section 6.2.10, `REPORTLOG,' on page 33.
Note that the log files should be local files on the server machine(s). See Section 5.2, `Diskless Nodes and Remote Mounted Disks,' on page 27 for a discussion of remote file systems.
The debug 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.
This technique applies to Unix systems only.
Since on Unix it is prudent to avoid running processes as root that do not require root permissions, we strongly recommend that you run lmgrd as a non-privileged user.
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 Section 2.1, `Specifying Location of the License File,' on page 8 and Chapter 3, `The License Finder' on page 19.
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 Section 5.2, `Diskless Nodes and Remote Mounted Disks,' on page 27). 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.
With v5 FLEXlm, or higher, the license server can optionally serve uncounted licenses as well. This is done so that the REPORTLOG file will include transactions for all license requests. To do this, include a SERVER line in the license file, and put the USE_SERVER line immediately after the SERVER line. The vendor daemon will service the uncounted licenses, and the USE_SERVER line indicates to applications that they will be authorized by the server.
Table of Contents * Previous Chapter * Next Chapter