Das bisherige Lizenzmodell für OSL Storage Cluster, das sich an der Zahl der im Betriebssystem sichtbaren CPUs orientierte, hat sich lange Zeit bewährt, denn es war einfach, geradlinig und auf beliebige Rechnertypen anwendbar. Entsprechend der Leistungsklasse des Systems fiel ein faires Entgelt für das Nutzungsrecht an.
Das soll auch zukünftig so bleiben. Um den aktuellen Entwicklungen und Erfordernissen des Marktes gerecht zu werden, ist dennoch eine Modifizierung des Lizenzmodells notwendig geworden:

• Multicore-CPUs und Chip-Multithreading werden zukünftig zu immer feiner abstufbaren Systemleistungen führen. Die im Betriebssystem sichtbaren CPUs beschreiben die Systemleistung nicht mehr adäquat, da der Gesamtdurchsatz auch über eine große Zahl relativ schwacher virtueller CPUs gesteigert werden kann. Bestes Beispiel: Suns neuer T2000, für den unmöglich eine klassische 32-CPU-Lizenz Anwendung finden kann.
• Dynamisch rekonfigurierbare Systeme können zur Laufzeit die Zahl der CPUs ändern. Natürlich wäre es wünschenswert, wenn man genauso flexibel das Nutzungsrecht erweitern bzw. freigeben könnte.
• Immer kürzere Innovationszyklen werden zukünftig dazu führen, dass Rechner noch schneller ausgetauscht werden. Für das Handling von Applikationen in solchen hochdynamischen Umgebungen ist OSL Storage Cluster mit der Application Control Option bestens gerüstet. Ein noch flexibleres Lizenzmodell kann auch das Handling der Nutzungsrechte vereinfachen.

Um auch zukünftig für alle Systeme, unabhängig von Hersteller, Plattform und Art der Technologie (konventionell oder mit Multicore/Multithreading) ein einheitliches Verfahren nutzen zu können, sind die Lizenzeinheiten oder Licence Units (LU) eingeführt worden: Ausgehend von der Zahl der vCPUs (die für Solaris sichtbaren CPUs) und der Zahl der Sockel/Chips wird nach einer einheitlichen Formel die Zahl der benötigten Lizenzeinheiten ermittelt. In der entsprechenden Ausbaustufe ist dann ein Nutzungsrecht zu erwerben. Für klassische Single-Core/Single-Thread-CPUs entspricht dabei eine CPU einer Lizenzeinheit.

Für vorhandene Systeme bleibt also de facto alles wie bisher und neue Systeme mit CMT oder Multicore-CPUs fügen sich so in das neue Modell ein, dass auch zukünftig eine der Systemleistung angemessene Lizenzierung möglich ist. Für alle Hersteller und Plattformen gibt es eine einheitliche Berechnungsgrundlage, was aufwendige individuelle Zuordnungen erübrigt.

Einen Überblick über die Lizenzeinheiten bei verschiedenen Konstellationen von vCPU- und Sockel-Anzahl bieten die auf der Informationsseite zu Lizenzen verlinkten Tabellen, für nicht enthaltene Ausbaustufen gibt es auf derselben Seite ein Tool zur Berechnung der Licence Units.

Hinweis: Die notwendigen Informationen zu Sockeln und Cores liefert der Betriebssystemkern regulär erst ab Version 5.10, so dass CMT- bzw. Multicore-CPUs mit Solaris 10 oder höher betrieben werden sollten.

Neben der bekannten hostbezogenen Lizenzierung wurde mit Load 27 (OSL SC 3.0) eine neue Art der Lizenzierung - die Clusterlizenz - eingeführt. Damit ist es nun möglich, die Lizenzeinheiten (licence units) clusterweit und dynamisch den Knoten zuzuweisen oder auch zu entziehen. Dies ermöglicht eine optimale und variable Nutzung der erworbenen Lizenzen, insbesondere bei sich oft ändernden Knoten im Cluster.

Damit bestehen jetzt zwei Lizenzierungsmöglichkeiten:

Jedes Modell hat seine Vor- und Nachteile. Bei kleineren Umgebungen (<8 Nodes) wird in der Regel die hostbezogene Lizenzierung vorteilhafter sein. Bei größeren Umgebungen ist vor dem Kauf zu klären (gern können Sie dafür auch die Hilfe unserer Systempartner bzw. auch von OSL in Anspruch nehmen), welches Verfahren den Anforderungen am besten entspricht (sowohl kaufmännisch als auch technisch).

Bitte beachten Sie, dass aus technischen Gründen die beiden Lizenzverfahren nicht gemeinsam in einem Cluster genutzt werden können, d. h. man muss sich vor dem Kauf für die eine oder die andere Variante entscheiden.

Details

Über die Clusterlizenz kann auch eine Vereinfachung des Lizenzierungsverfahrens erreicht werden, da nur noch auf einem Host die Lizenz eingespielt wird. Dieser Host übernimmt dann die Rolle eines Lizenz-Servers. Alle im Cluster befindlichen Knoten fordern dann, während des Bootens der Disk-Virtualisierung, Lizenzeinheiten an. Es werden genau so viele Lizenzeinheiten angefordert, wie benötigt (entsprechend den CPUs/Lizenzeinheiten im Knoten). Wenn also ein System 3 Lizenzen benötigt, werden auch nur 3 Lizenzeinheiten der Cluster-Lizenz genutzt. Eine Staffelung der reservierten Einheiten entsprechend der knotenspezifischen Lizensierung (2, 4, 8, 16, ... LUs) gibt es hier nicht! Außerdem werden nur Lizenzeinheiten für die installierten Packages (Base, Application Control, Extended Data Management) des Knotens vergeben.
Diese Lizenzvergabe ist solange erfolgreich, bis die verfügbaren Lizenzeinheiten aufgebraucht sind. Sind Lizenzeinheiten angefordert worden, werden diese für den Knoten dauerhaft reserviert. Eine automatische Freigabe erfolgt nicht, da dies beim nächsten Boot zu bösen Überrraschungen führen könnte, wenn zwischenzeitlich z. B. Testknoten "ungerechtfertigt" Lizenzen aufgebraucht hätten. Grundlage für das Funktionieren der Clusterlizenzen ist natürlich, dass der Lizenz-Server dauerhaft im Cluster verbleibt.

Folgendes Bild zeigt den Aufbau eines kleinen Beispiel-Clusters mit 4 Knoten in zwei Situationen. Der Knoten big-1 soll dabei ein partitionierbares System sein. Im linken Bild wird big-1 so konfiguriert, dass er drei Lizenzeinheiten benötigt. Für die anderen Systeme (je eine LU) werden die anderen Lizenzen aufgebraucht. Im rechten Bild wird big-1 auf 6 CPUs erweitert und bekommt die nun zusätzlich benötigten 3 Lizenzeinheiten von den übrigen Knoten.