Find us on Google+ FlexNET Publisher – A License to Network (Part 7) - License Server Schemes ~ Inventor Tales

Sunday, March 06, 2011

FlexNET Publisher – A License to Network (Part 7) - License Server Schemes

So we come to a close on our “License to Network” series. 

In this final segment, I talk about different licensing server schemes, single server, distributed, and redundant servers, and how it can affect the I.T. department, and the users at the other end.

This blog post will break down the different servers, the differences between them, and the advantages and disadvantages for each. 

That being said, let’s get to the nuts and bolts, what are the different licensing schemes?

Single Server Licensing

This is the system I’ve described the previous steps in this series, and it’s the most common system I’ve encountered in the ‘real world’.  A single license server uses one license file, containing all your licenses. 

What’s the advantage of this system?  It’s simple.  One server maintains one license, so it has one central point to maintain your licenses. 

Of course this is its downside too.  If the server fails, everyone loses a license until the server is brought back up. 

Now granted, servers don’t tend to drop like flies these days, so running this system is fine.  I’ve known many a system that’s happily run on this type of server.

Distributed Server Licensing

If I had to make a compromise between simplicity, and fault tolerance, I’d choose distributed. 

In a distributed system, you’re licenses are split between two different servers.  For example, if you have ten licenses, you could put five licenses on one server, and five on another (although the number of licenses can be divided in any combination between servers). 

In this system the clients acquire the licenses from either one of the servers, as designated by the environment variable ADSKFLEX_LICENSE_FILE = @SERVERNAME1; @SERVERNAME2

The advantage of this system is that you can have one server fall off line, and you’ll only lose the licenses on that server.  You don’t lose the entire pool.  The department can carry on with the remaining licenses in the pool. 

Granted, losing a significant number of your licenses can be no picnic, but it’s better than the whole pool!

Redundant Server Licensing

This is the most complicated, and the rarest licensing system.  I’ll be up front and say I haven’t configured this one personally, so I don’t know every detail of it.  So I can’t say I’m intimate with the functions of the Redundant System.

That being said, I’ve heard enough from the community to not be eager to try this system.

But it does have one advantage.  Three servers share all your licenses.  However, you can lose one server, and all your licenses remain available.

It sounds pretty tempting right?  So what would be the downside?

The downside is you require three servers, but you can only afford to lose one server.  If you lose two, the entire system goes down, and all licenses are lost.

So why have three?

The third server maintains a quorum.  That is, it makes sure the other two agree. It actually doesn’t directly help you access more licenses.

I’ve also heard (but not personally verified), that one of your servers designates itself primary.  The second becomes the secondary, and the last becomes the quorum. 

Should the server designated primary fail, you have to stop and restart the remaining servers to designate a new primary, or the system still goes down. 

The servers also have to be on the same subnet, and I’ve even heard they have to be in close physical proximity. 

Taking all that into consideration, not to mention that most servers are pretty dependable these days, it seems like a lot of work for not much gain. 

So in my humble opinion, if I need fault tolerance, I’ll take distributed. 

But as I said before, I’ve not personally used this system, so if someone out there has used it, and likes it?  Throw a comment; I’d love to hear about your experiences! 

Also, for additional information, check these documents from the Autodesk Website.

No comments:

Post a Comment