Selecting Server Machines

> ## 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, each FLEXlm-enabled application connected to a license server uses one or more sockets. The number of sockets any one FLEXlm-enabled application requires is dependant on FLEXlm implementation details; consult your vendor for this information. The number of sockets available to the license server is defined by the per-process system limit for file descriptors. The total number of sockets used by the license server is slightly larger than the total number needed by the FLEXlm-enabled applications which are served by it. When using UDP, there is no limit to the number of applications per license server, because they can share a single socket from the server.

> If the number of sockets required by the license server on a single machine becomes excessive, then it’s probably good to split the license file into more than one file, onto different servers, to lighten the networking traffic (which requires the vendor to agree to issue new licenses). Licensed applications then check out licenses from multiple servers using a license-file list via the `LM_LICENSE_FILE` environment variable.

> #### 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 F, “The Report Log File”
> - Appendix G, “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.

FLEXlm End Users Guide
July 2003