Guaranteeing optimum availability, while keeping a strict count of the purchased licenses, is a constant cause for friction between software makers and their users. With the Triple Mode Redundancy system, Wibu-Systems has a solution to this conundrum e.g. for industrial users that work without disclosing license calls and without having to rely on trust alone.
A Fictional Example
Dr. Schwabe, head license buyer at a renowned maker of solar panels, has a habit of calling Mr. Zenz once a year. Every time, it is about the same issue: The quality assurance software works just fine, but then there are sporadic problems with reaching the license server. What is the point of licensing, if it causes problems, he wonders? His company is a company that people can trust.
But Mr. Zenz knows better: Only last month, a support incident revealed that a company used more licenses than it had paid for. The goodwill licenses made available to cover for some recent server issues almost led to a major loss of valid revenue.
This year, Mr. Zenz finally had an answer that Dr. Schwabe could not ignore: Wibu-Systems is offering a solution that combines the best of both worlds:
High availability: Server outages or other problems do not have to mean a real service disruption;
License checks: All purchased licenses are reliably available – no more, no less.
As a Triple Mode Redundancy system (TMR group), the concept works with a combination of a 2-out-of-3 licensing concept and tried-and-tested data center technology. Luckily, Mr. Zenz had already migrated the licensing system to the new Universal Firm Codes, which is a precondition for TMR licenses.
Every license is created in triplicate and given a special ID, the TMR ID, as an additional property to go with the license count. The TMR ID is used as a definite identifier for all three licenses. The firm code, product code, and TMR ID need to match for all three licenses to come together and form one TMR license. Ideally, consecutive numbers are used for each new TMR license.
There is no need to test whether other properties of the product items match, as this would only lead to more complications with later updates. However, it helps if all three licenses going with a TMR license have the same properties.
The three licenses are placed into three separate CmContainers that have to have the same CmActId, as the TMR group can only allocate CmContainers with the same CmActId to a virtual CmContainer. This virtual container is the only one seen by the user, with nothing indicating that it is a virtual receptacle of three separate CmContainers. Virtual CmContainers have fully configurable, typically random serial numbers with a new mask byte 131, e.g. 131-59885682.
The same approach naturally also works with three CmDongles, which would then also form a virtual CmContainer with a serial number starting with 131.
The 2-out-of-3 Rule
For a TMR license to be valid and available, at least two of the three related licenses have to be available. If only one of the three is there, the TMR license will not make an appearance in the virtual CmContainer.
A CmContainer with only one of the constituent licenses is of no use to anyone: The CodeMeter-Server would bar a license with a TMR ID from being used in this case. In effect, such a license could only be used in a full TMR group.
A TMR group consists of a total of five servers, typically operated as virtual machines. The downstream interface with the clients is provided by a double TMR server that the clients can access via a virtual IP address. The TMR server creates the virtual CmContainers and the TMR licenses within them based on the CmContainers kept on the three upstream CodeMeter servers.
Virtual IP Address
In the corporate network, the TMR group can be reached via a single virtual IP address, which channels all queries to the active TMR server. When the TMR server first connects to the network infrastructure, the switch, it informs the system that it wants to receive packets destined both for its own IP address and for the assigned virtual IP addresses.
The passive TMR server monitors the availability of the active TMR server via a regular keep-alive check. Should the active TMR server not be available, its passive counterpart informs the network that the packets for the virtual IP address should now go to it – seamlessly stepping into the place of the active TMR server.
Active and Passive
For this feat to work, the passive TMR server has to be aware of the current state of the active server at all times. The active TMR server ensures this by notifying its passive partner immediately of all changes in its state, including the system configuration, the virtual CmContainers, the current license allocations, and all handles used by the upstream CodeMeter servers.
Whenever the servers are forced to switch places, errors or required maintenance interventions can mean a downtime of a few seconds or the potential loss of individual packets.
Linux TMR Server
The TMR service running on the TMR server is a new development that supports all incoming CodeMeter API calls that are compatible with the first CodeMeter version supporting the Universal Firm Code, namely Version 6.10. The system itself is an original Debian OS equipped with open source software and the TMR service.
Upstream from the double TMR servers, there are the three CodeMeter servers, which can be run under Linux or Windows. With minimal changes to the CodeMeter settings, the licenses on these servers can only be accessed through the two TMR servers. No client could ever use them directly.
TMR licenses can be programmed separately with the high-level programming API or its incarnation in the command line tool CmBoxPgm. When doing so, the mentioned TMR ID would have to be assigned manually. From early 2019, CodeMeter License Central will facilitate integration into existing business processes. This will include mechanisms for replacing individual CmContainers efficiently, e.g. if some hardware problems require a CodeMeter server to be replaced.
At the same time, the software for the TMR server is expanded to create a license request file for the entire group that contains all the required individual remote context files. Such update files received through the same channel will be unpacked and installed onto the upstream CodeMeter servers in the sequence of their arrival. This ensures perfect cooperation between CodeMeter License Central and the TMR group – using the same processes that one would use for a single CodeMeter server. ISVs might only have to add tiny adjustments to their activation software.
The first version of the TMR package will be available for licensing from Wibu-Systems beginning in November 2018. Payment is handled by subscription for each installed TMR group.