License Management with Univa License Orchestrator (1/2)

During the last months I was busy working on a new product named Univa License Orchestrator. We reached the early alpha phase now and I think it is time to share some information what Univa License Orchestrator is and how it can help in your environment.

One of the upcoming patch releases of Univa Grid Engine 8.1 (and 8.0) will be integrated with the Univa License Orchestrator 1.0.0 to:

  • allow Univa Grid Engine jobs to consume software license keys and tokes provides by one or multiple license servers that might be spread across an enterprise
  • easily manage licenses in one or multiple Univa Grid Engine clusters
  • support license consumption outside the control of Univa Grid Engine or other queuing systems (e.g. by applications that are started interactively)
  • be able to define policies for how to share licenses between sites, departments, projects or other organizational units that exists in a company.

License Management

Exclusive Use of Licenses in Univa Grid Engine Clusters

When software licenses are to be used exclusively by Univa Grid Engine jobs and when there are no external applications that might consume that type of software licenses then this can be realized without a Univa License Orchestrator instance by defining a consumable resource in the Univa Grid Engine configuration.

> qconf -sc
#name            shortcut   type      relop requestable consumable default  urgency  
#-------------------------------------------------------------------------------------
...
license1         lic1       INT       <=    YES         YES        0        1
...

This consumable resource can be initialized on the global host level with the maximum amount of the available licenses. Node locked licenses might be realized by defining the maximum number of licenses for a host in the corresponding complex values of the host configuration.

> qconf -se global
hostname              global
complex_values        lic1=10
...

Users that require a software license for their job express this by adding a corresponding resource request during the submission of the job. There are also several ways for administrators or operators and some even for users to ensure requests for licenses are added automatically. An example are job classes which contain the request for a certain type of software license for a specific job type.

> qconf -sjc job_template
jcname job_template
variant_list default
l_hard lic1=1
...

> qsub -jc job_template

The Univa Grid Engine scheduler will then automatically take care that only so much jobs of that type are started so that at not point in time the configured maximum value will be exceeded.

Using Licenses within Univa Grid Engine and also Externally

If there are applications outside the control of Univa Grid Engine which also require the same license type then the setup has to become more complex.

The Univa Grid Engine scheduler needs to know how many licenses are in use when it tries to schedule new jobs. The bookkeeping, which is integrated into the Univa Grid Engine scheduler component, is then not sufficient anymore and therefore an administrator has to setup a load sensor to feed required information into the Univa Grid Engine system.

Load Sensors are customer defined scripts that are able to communicate with license management servers to request the currently available amount of licenses and they are also able to communicate with Univa Grid Engine to pass this information to the Univa Grid Engine scheduling component so that the Univa Grid Engine system will not exceed the defined limits.

Creating such load sensors can be a difficult task when multiple licenses managements components are in use in the enterprise or when licenses are consumed by jobs of multiple Univa Grid Engine clusters as well as by external applications. It will be even more complicated when applications do not immediately consume the license they request after being started or when there is a delay between the consumption of the license and the corresponding update of the license statistics in the license management software.

If the bookkeeping is not correct then this might cause situations where queuing systems start a job that will fail or it might lead to jobs that block the cluster due to the absence of an available license.

Sharing licenses between multiple Univa Grid Engine clusters and external applications

The integration of Univa Grid Engine and Univa License Orchestrator addresses those scenarios. It ensures that jobs in multiple Univa Grid Engine clusters can consume licenses from multiple license servers. It is also possible to take external applications into account which consume such licenses.

‘ULO

This is achieved by making Univa License Orchestrator the center for information on all activities happening to software licenses in the enterprise. On the one hand the Univa License Orchestrator product is able to communicate with multiple license management components (e.g FlexNet Publisher instances) to collect available license types along with their maximum and currently available license key or token amounts. On the other hand Univa Grid Engine clusters (of potentially different versions) are enabled to appropriately handle incoming license requests before the underlying application that wants to consume the license has even been started.

Bringing both products together will enable users to utilize the available software licenses at a maximum and will give administrators a way to define site wide policies how software licenses should be shared between different organizational units.

blog comments powered by Disqus