When user is using floating license, if the machine with LexFloatServer died, they will likely build another LexFloatServer temporarily or permanently to recover from outage.
In such case, as LexFloatServer needs to be activated, the new LexFloatServer machine cannot be activated.
But, also the first LexFloatServer is already dead, so deactivation cannot be made by user.
Since user wants to recover from the situation as quickly as possible, what would be the best way you guys recommend for such disaster recovery case?
In case of high availability setup you need redundancy. If your customer has 500 floating clients, you should provide your customer with two license keys - the other one for recovery.
So, you can install Lexfloatserver on two different machines. Now when the first machine crashes, and any client tries to refresh, it will get a network errror, so client can send another request to backup server.
That makes sense to have a license key for backup. But, if we give them two license keys (500 clients each), they can simply use up to 1000 floating clients at the same time. (Since two license keys are exactly identical, they can just activate both of them and use both of them. )
With such fail-over handling, usually backup server will not become active until the primary server is down. (Back server will check Primary servers availability and decide when they will become active)
For such behavior, the feature has to be implemented as a part of Floating Server.
Is there any plan of supporting Primary-backup workflow?
Disaster management is your customers concern, if they at all want the disaster management they can buy additional backup licenses for which they should ideally pay you.
Load balancing/high availability is possible if app servers share a common data store, as is the case with Cryptlex Web Server, but LexFloatserver uses local disk as the data store so implementing high availability is not trivial.
We would need to implement Master/Slave setup in LexFloatServer, the feature will be added to todo list, but implementation can’t be guaranteed to be done sooner.
Yes, customers should pay for backup server as well, but usually the price should be cheaper than Primary server since it will not be used til Primary dies. So, life cycle control of the backup server is really important.
As the second option, supporting new expiration mode can help to workaround (improve) this situation like this post:
How it works? We will give our customers with 2 keys:
License Key with long expiration date as a Primary server
License Key with 2 days of expiration date since activation date as a Backup server
Whenever the floating license server dies, user can use the 2nd license key to activate another machine which only valid for 2 days.
Within those 2 days, user can contact to us and we will deactivate the license key 1 manually from dash board. So that user can activate the license key 1 on another machine.
So, supporting new expiration mode (expiration since activation) would help.
This feature would be easier to implement than supporting Primary-Backup support, I believe.
This can actually be implemented in the following manner too:
You can create a web interface for disaster management, which your users can access over web, and if user has a valid key/email (or some other parameters) combination you issue them license keys with two day validity. You can also the regulate the number to prevent the abuse.
I had the same thought as well, but ideally, we want to finish everything without creating another web site for that purpose, in order to avoid additional maintenance cost. Once we have our own web site for users to purchase license, it would make sense to centralize everything to there, though - which we don’t have any plan yet.
The solution of license keys which start ticking after first activation, would require some major changes so will take time, we have other major projects too.
We’re going to sell our products with Floating License soon, so it would be nice to have such feature as early as possible for better disaster recovery for our customers.
But, I understand you guys have multiple major projects, so I would say it is good as long as having it in a month.
Hello everyone, I wondered if this has evolved in the last 4 years? I developed a dockerized application aimed at running in unconnected sites where high availability and high security is mandatory, that I would like to license on a per-instance model. My customers don’t bother too much with paying for a slave FloatServer license running on another site as long as availability is covered. How have the master/slave considerations evolved since December 2016? Is this available in current version? If not, is there a modern way to cover the use case? Cordially
The solution proposed above is the only solution available as of now, where you need to have a standby server that the client connects to in case the primary server is down. So, it essentially means that you have to write some code to handle this situation of switching the server in your app.
We do have an active-passive highly available setup on the roadmap. But it may take 3-4 months till it gets implemented.
One more request for the high-availability setup. We do have customers using the Flex triple-server redundancy setup, and if any of them demand the on-premise option they’ll want to know there is some kind of server backup built in.
