[Translate to German:]

Lizenzserver in HA-Umgebungen

Einerseits eine möglichst hohe Verfügbarkeit bereitstellen und andererseits auf jeden Fall die Anzahl der gekauften Lizenzen einhalten – ein bekanntes Spannungsfeld zwischen Softwarehersteller und Anwender. Mit dem Triple-Mode-Redundancy-System bietet Wibu-Systems eine Lösung für Anwender z.B. im produzierenden Gewerbe. Sie kommt ohne Offenlegung von Lizenzzugriffen oder Kompromissen auf Vertrauensbasis aus.

Ein fiktives Beispiel

Seit Jahren ruft Herr Dr. Schwabe, zuständig für die Lizenzeinkäufe eines großen, mittelständischen Solarpanelproduzenten, regelmäßig bei Herrn Zenz an. Jedes Jahr das gleiche Thema: Die Software zur Qualitätssicherung der produzierten Solarpanels sei zwar gut, doch gebe es seltene, aber merkliche Ausfälle am Lizenzserver. Völlig unnötig sei so eine Lizenzierung, die mache höchstens Probleme. Man sei doch vertrauenswürdig.

Herr Zenz weiß es besser. Gerade letzten Monat erst kam bei einem Supportfall heraus, dass in einem anderen Unternehmen mehr Lizenzen verwendet als bezahlt wurden. Dort hätten seine aus Gutgläubigkeit ausgestellten Kulanzlizenzen zur Überbrückung von Serverproblemen die Firma beinahe eine nicht unerhebliche Umsatzeinbuße beschert.

Eine gute Antwort

Doch dieses Jahr hat Herr Zenz endlich eine gute Antwort für Herrn Dr. Schwabe: Wibu-Systems bietet nun eine Lösung an, die beiden Seiten gerecht wird:

  • Hohe Verfügbarkeit: Ein Serverausfall oder eine Störung führen nicht zu einem Ausfall.
  • Lizenzkontrolle: Es sind alle gekauften Lizenzen ständig verfügbar – aber nur genau die gekaufte Anzahl.

Als Triple-Mode-Redundancy-System (TMR-Verbund) kommt das Konzept mit einer Mischung aus einem 2-aus-3-Lizenzkonzept und betriebsbewährter Rechenzentrumstechnologie daher. Wie gut, dass Herr Zenz für neue Lizenzen bereits auf das aktuelle Lizenzierungssystem „Universal Firm Code“ umgestiegen ist, denn das ist Voraussetzung für TMR-Lizenzen.

Lizenzaufbau

Jede Lizenz wird dreifach ausgestellt und dabei mit einer speziellen Kennung, der TMR-Id versehen. Diese TMR-Id ist eine zusätzliche Eigenschaft der Lizenzanzahl. Die TMR-Id wird verwendet, um die drei zusammengehörenden Lizenzen eindeutig zu identifizieren. Es müssen Firm Code, Product Code und TMR-Id gleich sein, damit die drei Lizenzen eine TMR-Lizenz bilden. Daher wählt man die TMR-Id am besten als fortlaufende Nummer bei jeder neu erstellten TMR-Lizenz.

Andere Eigenschaften der Product Items werden nicht auf Gleichheit geprüft, denn dies würde zu Komplikationen bei späteren Update-Programmierungen führen. Sinnvollerweise sind die drei Lizenzen einer TMR-Lizenz natürlich in allen Eigenschaften gleich.

Gleiche CmContainer

Die drei Lizenzen werden in drei verschiedene CmContainer programmiert, die aber alle die gleiche CmActId haben müssen. Der TMR-Verbund verbindet nur CmContainer mit gleicher CmActId zu einem virtuellen CmContainer. Der Anwender sieht nur diesen einen virtuellen CmContainer. Es bleibt verborgen, dass dieser CmContainer aus drei einzelnen besteht. Virtuelle CmContainer haben eine konfigurierbare, in der Regel zufällig erzeugte Seriennummer mit einem neuen Maskenbyte 131, also z.B. 131-59885682.

Selbstverständlich kann man auch aus drei CmDongles einen solchen virtuellen CmContainer bilden; auch in diesem Fall hat der virtuelle CmContainer eine Seriennummer, die mit 131 beginnt.

2-aus-3-Konzept

Damit eine TMR-Lizenz gültig und somit verfügbar ist, muss eine Mehrheit von mindestens zwei der drei zusammengehörenden Lizenzen verfügbar sein. Ist nur eine der drei Lizenzen vorhanden, taucht die TMR-Lizenz nicht im virtuellen CmContainer auf.

Mit einem CmContainer, der nur eine einzelne Lizenz einer TMR-Lizenz enthält, kann man nicht viel anfangen: Der CodeMeter-Server verhindert die Verwendung einer Lizenz, die über eine TMR-Id verfügt. So eine Lizenz kann ausschließlich in einem TMR-Verbund betrieben werden.

Aufbau der Systeme

Ein TMR-Verbund besteht insgesamt aus fünf Servern, die man in der Regel als virtuelle Maschinen betreibt. Als Schnittstelle zu den Clients wird ein zweifach vorhandener TMR-Server bereitgestellt, der von den Clients unter einer virtuellen IP-Adresse erreicht werden kann. Der TMR-Server baut die virtuellen CmContainer und die darin befindlichen TMR-Lizenzen auf Basis der CmContainer an den drei nachgelagerten CodeMeter-Servern auf.

Virtuelle IP-Adresse

Im Firmennetz ist der TMR-Verbund unter einer einzigen, virtuellen IP-Adresse erreichbar. Über die virtuelle IP-Adresse werden alle Anfragen an den aktiven TMR-Server geleitet. Dieser hat beim Start der Netzwerkinfrastruktur, also dem Switch, mitgeteilt, dass er neben seiner eigenen IP-Adresse auch die Pakete von der festen, virtuellen IP-Adresse empfangen möchte.

Der nicht-aktive TMR-Server überwacht als passiver TMR-Server die Verfügbarkeit des aktiven TMR-Servers über eine Keep-Alive-Prüfung. Sobald der aktive TMR-Server nicht mehr erreichbar ist, teilt der bislang passive TMR-Server der Infrastruktur mit, dass er ab sofort die Pakete der virtuellen IP-Adresse empfangen möchte und übernimmt nahtlos die Rolle des aktiven TMR-Servers.

Aktiv und Passiv

Dazu ist es notwendig, dass der passive TMR-Server stets über den aktuellen Zustand des aktiven TMR-Servers informiert ist. Daher schickt der aktive TMR-Server immer sofort alle Veränderungen seines Zustands an den passiven Partner. Das sind die Konfiguration des Systems selbst inklusive der konfigurierten virtuellen CmContainer, der aktuellen Lizenzbelegung sowie aller Handles, die an den nachgelagerten CodeMeter-Servern belegt sind.

Systembedingt kommt es bei einer solchen Umschaltung aufgrund eines Fehlers oder auch wegen Wartungsarbeiten zu einer kurzen Unterbrechung von wenigen Sekunden und ggf. zu einzelnen Paketverlusten.

Linux TMR-Server

Der auf dem TMR-Server laufende TMR-Dienst ist eine komplette Neuentwicklung, die eingehende CodeMeter API-Calls kompatibel bis hin zur ersten CodeMeter-Version mit Universal Firm Code, der Version 6.10, unterstützt. Das System ist ein originales Debian-Betriebssystem, auf das dann frei verfügbare Softwarepakete sowie der TMR-Dienst aufgespielt werden.

Hinter den beiden TMR-Servern laufen drei nachgelagerte CodeMeter-Server, die entweder unter Linux oder Windows betrieben werden können. Nach minimalen Änderungen an der CodeMeter-Konfiguration auf diesen Servern stehen die CodeMeter-Lizenzen nur noch den beiden TMR-Servern zur Verfügung; eine direkte Nutzung durch einen Client ist unterbunden.

Businessprozesse

Zunächst können die TMR-Lizenzen unter eigener Verwaltung mit dem High Level Programming-API oder dem darauf aufsetzenden Kommandozeilenwerkzeug CmBoxPgm programmiert werden. Hierbei muss man die oben beschriebene TMR-Id selbst vergeben. Ab Frühjahr 2019 wird die CodeMeter License Central eine einfache Integration in Ihre Businessprozesse ermöglichen. Diese wird dann auch Mechanismen zum sauberen Ersetzen von einzelnen CmContainern bereitstellen, zum Beispiel nach Defekt einer Hardware und dem anschließenden Ersatz eines CodeMeter-Servers.

Gleichzeitig wird die Software am TMR-Server für die nächste Version erweitert, so dass eine Lizenzanfrage-Datei für den ganzen Verbund erzeugt wird, in der die einzelnen Remote-Kontext-Dateien eingepackt sind. Auf gleiche Art gelieferte Update-Dateien werden ausgepackt und nacheinander auf die nachgelagerten CodeMeter-Server eingespielt. Damit wird ein perfektes Zusammenspiel von CodeMeter License Central und TMR-Verbund möglich – und dies unter Verwendung der gleichen Abläufe wie bei einem einzelnen CodeMeter-Server. Auf Softwarehersteller kommen höchstens kleine Anpassungen in der Aktivierungssoftware zu.

Lizenzierung

Das TMR-Paket kann ab November 2018 in der ersten Version bei Wibu-Systems lizenziert werden. Die Abrechnung erfolgt pro installiertem TMR-Verbund in einem Subskriptionsmodell.

 

KEYnote 36 – Herbstausgabe 2018

Nach oben