In looking at doing centralized licensing in combination with an active/standby (vrrp or fast failover) setup on local controllers, it seems like the limitation on how long it would take for the APs to come up active on the standby controller is going to be limited by the centralized licensing. Supposing I had two controllers in an active/standby with 32 APs. The master controller is the licensing server and has given/recorded 32 licenses as being used by the active controller with 32 APs. Should the active controller fail, the documentation reads that three heartbeats (30 seconds each) would have to be missed before the licenses would go back into the pool. So the question is, what happens to the APs that try to connect over to the standby controller if the licenses still haven't been released by the active? This is all assuming that we have purchased just enough AP licenses to server the amount of APs that we have. I'm hoping I'm missing something otherwise the fast failover is definitely not going to be fast.
ControllerA has 1 license and ControllerB has 64 and centralize licensing has been turned on then ControllerA will have the 64 additional licenses on its table even after ControllerB has gone down ControllerA will keep those in the table for another 30 days The main purpose for license heartbeat is to make sure that those 64 licenses are still available and no other controller has been using those and of course to check that the server is still is still available
(HOME-LOCAL1-CONTROLLER) #show license limits
65 Access Points
65 RF Protect
(HOME-LOCAL1-CONTROLLER) #show license heartbeat stats
License Heartbeat Table
Server IP Address HB Req HB Resp Total Missed Last Update (secs. ago)
----------------- ------ ------- ------------ -----------------------
192.168.1.105 26 11 15 5
I'm not sure I'm totally following all that you're saying. I get the concept of the licenses all being pooled but I'm still getting hung up on whether the license will be available for the standby controller once the active one goes down. Your post points out that the heartbeat is to ensure that the licenses are still in use. According to that it will take 3 X 30 seconds for the central licensing controller to come to the conclusion that they aren't in use and can be used elsewhere. Is this something that you've testing in a real world scenario?
The Chapter on Centralized Licensing is here:
Like Vfabien said,
The centralized licensing feature sends keepalive heartbeats between the license server and the licensing client controllers every 30 seconds. If the licensing server fails to receive three consecutive heartbeats from a client, it assumes that the licensing client is down, and that any APs associated with that client are also down or have failed over to another controller . Therefore, the licensing server adds any licenses used by that client back into to the available pool of licenses. If the license server fails to contact a license client for 30 consecutive days, any licenses individually installed on that client will be removed from the server’s license database."
I understand how the centralized licensing works but it's that heardbeat timing that I'm concerned about. If it takes 90 seconds for the server to realize a client isn't using those licenses any longer, how can it instantly (or right when the active controller goes down) assign those licenses to the standby controller that is taking over for the failed controller? The entire purpose of vrrp and fast failover is that a failure would hopefully be transparent to a user. If the connection is lost for 90 seconds while the standby controller waits to have licesnes available, then it's not fast. I hope that makes better sense. The assumption is that I'm talking about local controllers failing and not the centralized license server itself.
Reading the document cjoseph linked, it looks like you would need to have extra licenses available for a seemless transition. It doesn't look like the identity of the APs is tracked by the centralized server, just the count. So they're not going back into the pool until 90 seconds later.
From my memory of going over license threshold, I believe the APs will switch to the new controller, but shut down their radios until those licenses free up at which point they'll begin working normally. Not an ideal answer, I know but if seemless failover is required, I guess you could still buy the extra licenses...
I agree with your assessment. I was hoping there was another mechanism in place that would prevent that 90 second timer from being a problem but I don't think there is. If someone has a proof of concept that they've seen where this isn't the case, I would be interested. Seems like a limitation in the centralized licensing model to me.
The standby controller is the backup license server. If the master fails, the standby becomes the licensing server period.
When Centralized Licensing is used in conjunction with HA, when a failure occurs and the standby tunnel becomes active, the controller will allow the AP to become active immediately even though the controller may report 0 license available momentarily on the standby controller.
Thanks Michael. That's exactly what I was looking for.
@michaelw wrote:When Centralized Licensing is used in conjunction with HA, when a failure occurs and the standby tunnel becomes active, the controller will allow the AP to become active immediately even though the controller may report 0 license available momentarily on the standby controller.
does that work for all forms of HA, so VRRP, fast failover, LMS/LMS backup?
This only works with AP Fast Failover because the standby tunnel is established ahead of time. This is not the case with previous redundancy protocol such as VRRP.
ok, that is very interesting to know, thank you.
so for a master/master standby setup, with centralized licensing using fast failover is the way to go?
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.