[GE users] CPlex licenses on SGE cluster

craffi dag at sonsorol.org
Wed Aug 26 13:34:16 BST 2009


Just one suggestion - you might want to ask if your software vendor if  
they would be willing to convert the nodelocked licenses into floating  
or concurrent licenses for more efficient cluster usage. It doesn't  
hurt to ask, the vendor has probably hear that request before and the  
end result would be a bit more flexible/efficient for you since the  
software is not tied to a physical asset.

-Chris



On Aug 26, 2009, at 8:25 AM, murple wrote:

> Thanks,
>
> that answered my questions quite well. I didn't think of software
> outside the cluster using the licenses. Btw. I just learned that our
> licenses are node-locked anyway. So that makes thinks even easier.
>
> regards, Andreas
>
>> Software license handling on a cluster is interesting, the
>> implementation depends on specifics within your environment ...
>>
>> In most cases you don't need to integrate the scheduler with the
>> license system:
>>
>> - If you have a sitewide license the cluster scheduler does not  
>> matter
>>
>> - If you have enough licenses to cover all available job slots than
>> the cluster scheduler does not matter, just get the software to work
>> on the cluster and don't bother teaching the cluster or scheduler
>> about the licenses
>>
>> And in the more common cases:
>>
>> - If the license is nodelocked to certain machines then handle it  
>> with
>> SGE requestable resources associated with those machines
>>
>> - If you have less licenses than nodes and the licenses are only used
>> on the cluster than just handle this with a consumable requestable
>> resource that limits the number of running license-needing jobs to  
>> the
>> number of licenses you have
>>
>>
>> It only really gets complicated where you have a software license
>> server that serves clients other than your cluster. In that case you
>> actually have to make the cluster "license aware" because it needs to
>> poll the license server in order to find out how many usable  
>> instances
>> are remaining for each application or application feature. This is
>> where the "Olexen flexlm method" comes into play.
>>
>>
>> What it comes down to is that maybe 80% of the time you don't need to
>> really make the cluster "license aware" - you can just treat the
>> license issue as just another requestable resource with a built-in
>> limit.
>>
>>
>> -Chris
>>
>>
>>
>> On Aug 26, 2009, at 7:28 AM, murple wrote:
>>
>>> Hi,
>>>
>>> I've just been given the task to install some CPlex "token" licenses
>>> (and software) on our cluster. Since I never installed CPlex or any
>>> license aware software on a cluster I have some questions:
>>>
>>> - As I read there are some "cluster aware" license managers out  
>>> there.
>>> What do I get from them? Is there anything compatible with this  
>>> "ILOG
>>> License Manager" for CPlex?
>>>
>>> - What about using the normal license manager in addition to a
>>>  complex (number same as number of licenses):
>>>  1. job request complex
>>>  2. job requests license
>>>  3. job runs
>>>  4. job releases license
>>>  5. job releases complex
>>>
>>> regards, Andreas
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=214358
>>>
>>> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net
>>> ].
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=214361
>>
>> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net 
>> ].
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=214364
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net 
> ].

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=214365

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list