This section helps you decide which nodes to use as license server nodes.
Resources Used by the Server
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.
Processes
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 client connects to the server it uses a process file descriptor. If a vendor daemon runs out of file descriptors, it automatically starts up another copy of itself. The process file descriptor limit on most systems is at least 128, so the vendor daemon does make a copy of itself until at least 120 to 125 clients are simultaneously connected (a few file descriptors are used for other things).
For small numbers of licenses the number of processes used is D+1, where D is the number of vendor daemons specified in the license file. For a license file specifying one vendor daemon and a large number of licenses, the number of processes used is approximately 1+(N/P), where N is the number of simultaneous clients and P is the maximum number of file descriptors allowed per process.
Sockets
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 some systems, such as SCO " , 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.
CPU Time
For small numbers of clients, the license servers use very little CPU cycles. 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. In this case, you might need to ensure that the server machine you select has CPU cycles to spare.
Disk space
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 grows very large. Consider where to put this file and how often to delete or prune it.
Note: 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.
Switching output of daemon log file
The daemon log file output can be switched after the daemons are running. This involves piping the stdout of lmgrd to a shell script that appends a file for each line, as follows:
The daemon log file output can be switched after the daemons are running. This involves piping the stdout of lmgrd to a shell script that appends a file for each line, as follows. Instead of the "normal" startup:
With this startup method, the output file "LOG" can be renamed and a new log file is created. You can make "LOG" a symbolic link and change the value of the link to switch the log file.
Memory
The FLEX lm daemons use little memory. Typically, lmgrd uses approximately150 kB and the vendor daemons use approximately 200 kB each.
Network bandwidth
FLEX lm 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 FLEX lm 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 exchanges 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.
Diskless Nodes and Remote Mounted Disks
Globetrotter Software recommends that you do not use remote mounted disks when you run the license server. 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, the points of failure which could lead to a loss of all of your licenses doubles. When all files are mounted locally, the licenses are 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 causes the licenses not to 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, FLEX lm 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.
Redundant Servers
With FLEX lm , 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 is not required to change 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 easier to administer, and allows you to have at least some of the licenses available, even if one machine goes down.
Setting up redundant servers
To set up redundant servers, you must provide the hostid for three machines to your software vendor, who will provide you with 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, seeDiskless Nodes and Remote Mounted Disks ). You then start lmgrd on each license server.
Quorums and redundant servers
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 are available. As soon as two of the three servers are running and communicating with each other, then all of the licenses are available.