Chapter 4

Selecting Server Machines

---

This chapter helps you decide which machines to use as license server machines.

4.1 Resources Used by the Server

This section discusses the resources used by the license server. When you select a server machine, you may need to take into account the system limits on these resources. For small numbers of licenses (under about 100), most of these system limits are not a problem on any workstation.

4.1.1 Sockets

When using TCP/IP ports, a single vendor daemon supports as many users as the per-process system limit for file descriptors. When no more file descriptors are available to a daemon, 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, because they can share a single socket in the vendor daemon (UDP has other drawbacks, and TCP is preferred). If there are more than 1000 concurrent clients being supported by a single vendor daemon, then it’s probably good to split the license file into more than one file, from different servers, to lighten the networking traffic (which requires the vendor to agree to issue new licenses). Licensed applications check out licenses from multiple servers using a license-file list via the LM_LICENSE_FILE environment variable.

Each FLEXlm-licensed application 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.

On older 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.

The number of sockets available for Windows 95/98/ME clients is about 60. In general, NT/2000/XP is preferred for server systems, where there is no such limit, and the operating system is better designed for server processes.

4.1.2 CPU Time

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 has enough CPU cycles to spare.

4.1.3 Disk Space

The only output files created by the license servers are the debug and report log files. The report log files are used to generate accurate usage reports by SAMreport. If you have a lot of license activity, these log files grow very large. You need to consider where to put these files and how often to rotate and archive them. The license administrator has the option to suppress log file output if disk space is at a premium.

It is recommended that the log files are local files on the server machine(s) to avoid networking dependencies.

See Also

Section 2.1.1, “Setting the Path with an Environment Variable”
Section 6.2, “Starting the License Manager Daemon on UNIX Platforms”
Appendix G, “The Report Log File”
Appendix H, “The Debug Log File”

4.1.4 Memory

The FLEXlm daemons use little memory. On SunOS, lmgrd uses approximately2 MB and the vendor daemons use approximately 2 MB each, although memory usage increases in the vendor daemon with the size of the license file, size of the options file, and the number of concurrent users.

4.1.5 Network Bandwidth

FLEXlm sends relatively small amounts of data across the network. Each transaction, such as a checkout or checkin, is typically satisfied with less than 1 KB 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 a large number of FLEXlm-licensed applications (hundreds), each of which exchange heartbeat messages with the vendor daemon, the network bandwidth used may start to become significant. In this case, run the FLEXlm-licensed application and server on the same local area network, which may require splitting licenses between two files for two servers. Users can use a license-file list in the LM_LICENSE_FILE environment variable to have effective access to both servers.

See Also

Section 2.1, “Specifying Location of the License File”

4.2 Remote Mounted Disks

Macrovision recommends that you do not use remote mounted disks when you run the license server. In other words, it is recommended that lmgrd, the vendor daemons, the license file, and the debug and report log files are all on locally mounted disks. If any of these files is on a remote mounted disk, you double the points of failure which could lead to a temporary loss of all of your licenses. 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 to be unavailable.

4.3 Redundant License Servers

If you wish to use redundant servers, select stable systems as server machines; in other words, do not pick systems that are frequently rebooted or shut down for one reason or another. Redundant license server machines are any supported server machines.

FLEXlm supports two methods of redundancy:

via a license-file list in the LM_LICENSE_FILE environment variable
via a set of three redundant license servers

With LM_LICENSE_FILE list redundancy, each one of a group of license servers serves a subset of the total licenses. The end user sets LM_LICENSE_FILE to a list of license files, where each license file refers to one of the license servers. The application then tries each server in the list, in order, until it succeeds or gets to the end of the list.

With three-server redundancy, if any two of the three license servers are up and running (two out of three license servers is referred to as a quorum), the system is functional and serves its total complement of licenses.

See Also

Section 3.5, “Managing Multiple License Files.”

4.3.1 Redundancy via License-File List

This is best explained by example. If ten licenses are desired for both “f1” and “f2,” the vendor issues two sets of licenses with a count of 5 for each of “f1” and “f2.” The server machines (unlike three-server redundancy) can be physically distant.

The license files look like:

License 1 for “chicago”

SERVER chicago 17007ea8 1700
VENDOR sampled /etc/mydaemon
FEATURE f1 sampled 1.000 01-jan-2005 5 26C7DD9C0186
FEATURE f2 sampled 1.000 01-jan-2005 5 8CE46C57041D

License 2 for “tokyo”

SERVER tokyo 17a07e08 1700
VENDOR sampled /etc/mydaemon
FEATURE f1 sampled 1.000 01-jan-2005 5 16BE40E1D98D
FEATURE f2 sampled 1.000 01-jan-2005 5 6DB6F3E402DF

The user in Chicago could set LM_LICENSE_FILE to:

1700@chicago:1700@tokyo

The user in Tokyo could set LM_LICENSE_FILE to:

1700@tokyo:1700@chicago

Remember to separate the license file names with a colon (“ : ”) on UNIX and with a semicolon (“ ; ”) on Windows. The application attempts the first server in the list, and if that fails for any reason, the second server is tried.

4.3.2 Three-Server Redundancy

These three-server redundant servers need to have excellent communications on a reliable network and need to be located on the same subnet. The three servers must be located physically close to each other. This form of redundancy requires that the servers exchange heartbeats periodically, and poor communications can cause poor performance. Avoid configuring redundant servers with slow communications or dial-up links.

Three-server redundancy is designed to provide hardware failover protection only and does not provide load-balancing. Use LM_LICENSE_FILE list, instead, if load-balancing is desired. This is because with three-server redundancy, only one of the three servers is “master,” capable of issuing licenses. Since all clients must contact the “master,” all clients must have reliable networking to a single machine.

4.3.3 Comparing Three-Server to License-File List

Are there any drawbacks to using the license-file list for redundancy?

Yes. By default, once a license job has successfully checked out a license from one host, all subsequent checkouts must be satisfied from the same host. If the application requires more than one license, this could result in a license denial when the license is available on another server. An application bypasses this restriction if it is coded with the use of multiple FLEXlm license jobs. Only your application vendor knows if their application is programmed in this manner.

If the application supports license queueing, all licenses are queued only from the first host on the list rather than the request moving to another server on the list.

Finally, if one server becomes unavailable, some licenses are unavailable.

When is it recommended to use a license-file list for redundancy rather than three-server redundant servers?

When there’s less system administration available to monitor license servers.
When load-balancing is needed for FLEXlm-licensed applications located far apart, e.g., London and Tokyo, make servers available locally, with remote servers available as backup.
License-file list is more forgiving if you lose quorum.
License-file list is not limited to three servers (any number work).
Clients do not require reliable networking to a single machine with license-file list, so this is recommended where networking itself requires redundancy.

4.4 Counted vs. Uncounted Licenses

The license file determines whether a license server is needed. If all the FEATURE (or INCREMENT) lines have a license count of 0 (unlimited) or “uncounted”, then no server is needed. This type of license is 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.

The license server is able to serve uncounted licenses as well. This is done so that:

transactions can be logged into the report log for all license requests, which can then be reported on by SAMreport
options file constraints can be applied to the licenses

To have uncounted licenses served, include a SERVER line in the license file, and put the USE_SERVER line immediately after the SERVER line. The vendor daemon serves the uncounted licenses, and the USE_SERVER line indicates to applications that requests must go to the license server for authorization.

	FLEXlm Version Notes

“uncounted” keyword introduced in v6 FLEXlm client library.