A little history…

The concept of redundant license servers dates back to the early days of licensing software circa 1988. At that time, networks and servers were unreliable and fixing them was a very time-consuming process, often taking days or even weeks. So, when a license server went down, customers wanted a way for their licenses to be available during the outage. Redundant  servers were born.

The most popular license managers still use three redundant servers operating together with exact replicas of the license servers and license files on each of the three machines. Service remains intact as long as at least two servers can communicate with each other and client applications can connect to them. The primary benefit of a properly configured redundant triad is that a customer’s complete inventory of licenses will remain available to at least part of the user community in the event of a single server node failure.

Application developers using these older license managers were unable to communicate with multiple independent servers without  coding complicated licensing routines into each application.  As a result, many of the features of these older license managers simply worked better with redundant servers than with independent servers.  Redundant servers have survived because of the lack of a better approach – until now.

Is there a better way?
A redundant server sounds like a good idea, but is the added administration complexity and overhead worth the trouble in today’s more reliable computing environment? Are redundant servers still the best approach? If vendors and their users had a better option, would they still prefer to use redundant servers? Let’s first examine what can go wrong with redundant servers. Later we will explain the alternative RLM approach.

Server Redundancy Problems

Faulty server deployment decisions: In order for a redundant server trio to operate properly, each server must have a complete and independent copy of the license server software, and license files. Often this setup is not achieved because shortcuts are taken to make the administrator’s job easier, such as placing a single copy of the server software on a shared file system. This situation creates a single point of failure, defeating the purpose of the redundant setup.

Extra administration coordination: If each license server in the triad is managed by a different team of system administrators, then special coordination is needed between them whenever changes are made to any of the license files.

DNS name server time out sensitivity: A redundant trio, especially one on an unreliable or slow network, can suffer outages whenever a DNS name server times out waiting for an address to be resolved. This is a hard problem to diagnose and it not usually well documented in the triad setup guide.

Poor scaling characteristics: Since all licenses that belong to a redundant server group must be combined, there is no way to improve licensing throughput unless the user upgrades all three of the server computers.  And even if he does, there are still operating system limits that govern the number of clients than can be served by a single license server (whether it is a redundant server or not).  If scaling becomes a problem, multiple sets of redundant servers must be deployed. This could be an issue at any site, but it is most problematic where large numbers of your licenses are in use – at your biggest and most important customers.

Version incompatibility between server releases: Whenever a new license is introduced into the common redundant license pool, administrators have to check the version of the license server software associated with that license. If it is later than the current version, then it needs to be copied to all three redundant servers simultaneously to keep the redundant trio in sync.

Some advanced features may be unavailable: Often end-users are unaware that they are making functionality tradeoffs by deploying redundant servers. With redundant servers, access to some valuable license management features, such as license borrowing, may be at best awkward to support or at worst simply unsupported.

Network segmentation problems: Since redundant servers operate only when at least two servers can communicate with each other, a network failure can take one of the servers offline. If you are a user on the “wrong side” of a network break, then you cannot access any of the licenses in the managed pool, even though your local network may be functioning normally. In this case, the license pool is available only to the users who are lucky enough to be on the right side of the break.

Report log consolidation problems: Whenever a redundant license server fails, a new master server must be nominated. If the failed server was writing to a report log, then logs from the new master server must be later combined with the original report log in order to obtain a complete and accurate picture of license usage. If the clocks are not completely in sync, then the report log may be difficult to reconstruct accurately.

ISVs must know all three redundant HOSTIDs: Server redundancy complicates the license creation process for the software vendor because all three hostids must be known at the time the licenses are created or modified. This means that the ISV has to support both redundant and non-redundant license file types. Also, changing any of the hosts in the triad requires license files to be reissued, which must then be reinstalled by the customer across all three redundant server nodes.

An Alternative Approach:

Automatic Support for Decentralized Independent License Servers

The Reprise License Manager does not support redundant servers. Instead it supports decentralized independent license servers. Vendors can take advantage of this new approach automatically without writing a single line of new code.

RLM was designed from day one to support multiple independent servers.  As a result, we have been able to make multiple servers operate in a much more transparent and efficient manner than redundant servers, giving end users more flexibility and control over how their licenses are deployed and managed.

Virtual License Pooling: Conceptually, you can think of the decentralized, independent RLM server approach as a Virtual License Pool. The pool consists of all the licenses managed by servers that the user has access to. Instead of aggregating redundant licenses into a single license file, then replicating it across all three redundant hosts, RLM aggregates the licenses virtually, leaving the licenses on servers that are most conveniently deployed and managed. RLM transparently queues, connects and reconnects to the entire list of decentralized servers giving each user access to his own “virtual pool” of licenses across the enterprise. The RLM servers remain independent, meaning no extra effort is needed to coordinate them.

Transparent reconnection to dispersed license servers: With older license managers, once an application had successfully checked out a license from a given license server, all subsequent license requests from the same application had to be satisfied from the same server. In the event that the application made subsequent license requests and no more licenses were available from that server, the license request was denied even though licenses may exist on another license server. To override this behavior, it was necessary to write complicated disconnect/reconnect logic in order to properly obtain licenses from other servers. With RLM, multiple license checkouts over multiple servers are handled transparently, simplifying the implementation within the application, and also giving the end user more consistent, predictable behavior across all vendors who support RLM on his network.

Enterprise-wide Queuing: Additionally, the RLM design supports license queuing across multiple license pools. With older license managers developers had to write complicated licensing routines using the API to queue at any license server other than the master. Without this special coding, it was possible for pools of licenses were to available on alternate servers, yet remain inaccessible to your application. By contrast, RLM transparently queues on each server (and on each license pool within the server).  Once the application acknowledges the license grant, all other license requests are dequeued.  This happens completely transparently to the application code. End users can decide whether to use queuing or not.

License Server Load Balancing: With RLM, license loads can be balanced by instructing RLM to randomly select the server from the server list to which to connect. Over time, a balanced load will be achieved.
Better License Server Scaling: With RLM, license service can be scaled up by simply adding server machines with new licenses into the existing network.

More Tolerant of Slow Networks: RLM’s design is more forgiving of slow or unreliable networks because a quorum of servers is never required.

Simplified Administration: When you install an RLM license server, you install it in one place, period.  You don’t have to worry if there are identical license files, binaries, etc. on each of the 3 machines.  Your report logs remain independent so that the usage can be summarized across servers to gain a full picture of concurrent usage.