OpenLM Router
When a FlexLM license server goes down, the usual recovery is to change where clients point, with a DNS swap or an edit to LM_LICENSE_FILE on every workstation, and to wait for someone to approve it. OpenLM Router removes both delays. Clients point at the Router port instead of at a license server, and when the primary fails the Router moves them to the backup on its own, typically 60 to 90 seconds after OpenLM Platform reports the primary unhealthy, with the default settings. Nothing on the workstation changes, and the switch does not wait for an approval.
OpenLM Router is delivered as container images. It runs on Linux with Docker. See Deploy OpenLM Router.
Before you begin
Confirm these prerequisites before you plan a Router:
- Your license servers run FlexLM, and the OpenLM Broker on each of them reports to OpenLM Platform. See System requirements.
- Your OpenLM license includes the Router. See System requirements.
- You plan one Router for your OpenLM account. See Current limitations.
OpenLM LicOps is a separate product. It admits scheduler and Kubernetes jobs only when a license seat is free and chooses the server each job checks out from. See OpenLM LicOps.
How the Router works
The Router is a TCP proxy that sits in front of your license servers. It opens a fixed port for each protected application, called the listen port, and forwards whatever arrives there to whichever server currently holds the primary role.
Server health comes from OpenLM Platform, which the Router asks for fresh data about every 10 seconds. The Router checks each pair's health every 30 seconds, and when the active server is reported unhealthy on as many consecutive checks as the failure threshold you set, the Router swaps the target and new client connections go to the backup. With a failure threshold of 3, expect a failover 60 to 90 seconds after OpenLM Platform first reports the primary unhealthy. The time OpenLM Platform takes to notice the failure comes on top of that. The Router never moves a pair onto a backup that OpenLM Platform reports unhealthy.
For a FlexLM triad, a license server that runs on three machines, the Router also checks the machines itself. It treats the server as unhealthy while fewer than two of the three accept a connection from the Router host, even when OpenLM Platform reports the server up.
The Router cannot run on its own. It depends on OpenLM Platform in three ways:
- Health: The Router fails over on the server health OpenLM Platform reports. OpenLM Platform learns each server's health from the OpenLM Broker running on it. If the Router loses contact with OpenLM Platform, it keeps acting on the last readings it received for up to 10 minutes. After that, the readings count as unknown.
- Servers: You select servers from the list of license servers that OpenLM Platform monitors, those where the OpenLM Broker runs and reports. The Router never parses a license file, and you never enter a host name into a failover pair.
- Configuration: You define failover pairs in OpenLM Platform, on the Port Mappings page in LicOps Configuration, and the Router collects them. LicOps Configuration is the OpenLM Platform app under Licenses and Features that configures both OpenLM Router and OpenLM LicOps. For a failover Router, it shows Port Mappings. The Router itself only holds the connection to OpenLM Platform.
A server with no reading in the last 10 minutes is treated as unknown rather than unhealthy. An unknown reading holds the failure count where it is instead of advancing it, so a gap in OpenLM Platform data does not move your clients.
Failover pairs
You protect an application by defining a port mapping, also called a failover pair: one listen port, a primary server, an optional backup, and the policy for moving between them. The following table lists the settings of a pair:
| Setting | What it controls |
|---|---|
| Listen port | The port the Router opens for this pair. Clients use port@router-host and never change it again. Each pair needs its own port. |
| Primary server | The server the pair normally serves from. |
| Backup server | The server it fails over to. It must serve the same vendor daemon and features as the primary, from its own license file, otherwise clients move to it and their checkouts fail. Optional: a pair with no backup is still monitored but has nowhere to fail over to. |
| Failure threshold | How many consecutive unhealthy health checks trigger the move. Accepts 1 to 10. |
| Failback mode | What happens after the primary recovers. Auto returns on its own, and Manual waits for you. |
Pairs fail over independently, so one application moving to its backup does not disturb the others.
When a server fails, the connections its clients held through the Router break with it, and the clients reconnect through the Router to the backup. A forced failover of a healthy server redirects only new connections. Connections already open stay on the server they started on.
What you deploy
The Router runs in your own network, alongside your license servers. It is a component you install, not part of the OpenLM Platform cluster. The following table lists the containers you deploy:
| Container | Role |
|---|---|
| Router API | The proxy itself, plus its REST API. |
| Router UI | The browser page where you connect the Router to OpenLM Platform. |
| MongoDB | Stores the routing configuration and the failover history. |
| Redis | Holds which server each pair is currently serving from, and the Router's background job schedule. |
On the license servers themselves, the Router relies on the OpenLM Broker, which you might already run: it is how OpenLM Platform knows each server and its health. Every server in a pair, the backup included, needs it. See System requirements.
After the Router is connected, you define and edit failover pairs in OpenLM Platform. The Router polls OpenLM Platform for its configuration and reports back what it applied, so traffic only ever leaves your network. Nothing on the OpenLM Platform side opens a connection to the Router, so you need no inbound firewall rule for the OpenLM Platform connection. Clients still need to reach the listen ports of the Router and the vendor-daemon port of each license server.
Terms used in this section
The following table defines the names used in this section:
| Name | What it is |
|---|---|
| OpenLM Router | The program you deploy, and the failover product described here. |
| LicOps Configuration | The OpenLM Platform service where you define failover pairs. It carries the LicOps name because it configures both products. |
| Port Mappings | The page in LicOps Configuration that lists your failover pairs. A port mapping and a failover pair are the same thing. |
| Router UI | The browser page on the Router host where you connect the Router to OpenLM Platform. |
Client Type Router | The kind of identity client the Router signs in with. |
| OpenLM Broker | The OpenLM component on each license server that reports the server and its health to OpenLM Platform. |
Current limitations
The Router has the following limitations:
- Tested with FlexLM only: Other TCP-based license managers are expected to work but are not verified. Contact OpenLM before you rely on one.
- Linux and Docker only: Windows hosts are not supported.
- One Router per OpenLM account: LicOps Configuration works with one Router at a time, the one that reported most recently. A second Router, for another site or as a standby, or a Router next to OpenLM LicOps, makes the page switch between the two. One Router protects as many applications as you give listen ports. Each pair needs its own port. Plan the Router host as you would any other component in the license path. See Keep the Router available.
Next steps
Work through the pages in order:
- System requirements: the host, datastores, network, and OpenLM Platform access the Router needs.
- Deploy OpenLM Router: run the containers and confirm the Router starts.
- Configure OpenLM Router: connect the Router to OpenLM Platform, define failover pairs, and point clients at the Router.
- Operate OpenLM Router: watch pairs, and force a failover or failback by hand.
- Change, upgrade, or remove OpenLM Router: upgrade the Router, move it to a new host, or retire it in a safe order.
- Troubleshoot OpenLM Router: what the common symptoms mean.
- OpenLM Router API reference: the endpoints used for failover, and how to read their responses.
Related
- OpenLM LicOps: the other product that runs on the Router program, for HPC and Kubernetes jobs.
- License Servers: the servers OpenLM Platform monitors, and how redundant license servers are shown.
The documentation team might draft this page using a large language model. A technical writer reviews every page and verifies it against the product before publishing it. A human makes the final decision.