Wireless Access

Reply
Highlighted
New Contributor

+10.000 AP in cluster design AOS 8.6

Hi

 

We are facing a design issue when having almost 10.000 Ap's and still growing.

 

At det moment we have set up Cluster 1 and running 3500 aps, and for our understanding talking with several aruba engineers its not possible for airwave to handle more then 4048 Ap's. This leaves us with 1 Cluster = 1 airwave.

 

So we would end up with 3 clusters for controlling up to 12.000 ap's

 

Cluster = 4 x 7240xm (2 in DC1 and 2 in DC2). One DC or 2 controllers should be able to handle all 4048 ap's in case 2 controllers goes down.

 

--Managed Networks

-----MCG

--------Cluster 1

--------Cluster 2

--------Cluster 3

 

 

The Main problem, and where the design issues lays, is how do we administrate how the AP's finds its cluster the best way. 

 

As we see it, we have 3 choices:

 

1. We control the master ip/vrrp of the cluster on the DHCP scoopes in option 43. (ber in mind we have 900 locations) we would have to do a static plan, where we divide the locations in 3. this would't be a very dynamic solution. 

pros.

- No ekstra configurations on the mobility master, and we are still able to inherit configurations from a top level and use i across all clusters.

- No cluster can't be overrunned with ap's per design, because of the division.

cons.

- The administrative headache in maintaining a list where the ap is connecting and the fact that we are letting the dhcp control where our ap should go.

- static configuration on each scopes and the need of a maintained plan for documentation to make sure the cluster is not taking in to many ap's.

 

2.  We use option 43 from DHCP and configure cluster 1's vrrp, like we are doing today. When the AP is hitting cluster 1 we can control where it should go through LMS from the AP-group. This means we need to create and configure a specific ap group with an LMS ip, one for each of the 3 clusters under the ap system profile in the MCG folder. 

pros.

- we control where the ap connect from the mobility master and in the controller environment.

cons.

- We have 25 ap groups and more to come, so this would mean we need 3 x 25 = 75 ap groups for all 3 clusters to handel all the solutions we have. And every time we make a change we should maintain 3 ap groups.

- Potentially cluster 1 could be overrunned if cluster 2 and 3 is unavailable and goes down, because of the the default behavior in discovering the master through DHCP. But then you probably have bigger problems on hand.

 

3. We use option 43 from DHCP and configure cluster 1's vrrp, like we are doing today. we then configure each ap with a static master.

pros.

- we control where the ap connect from the mobility master and in the controller environment.

- No ekstra configurations on the mobility master, and we are still able to inherit configurations from a top level and use the same ap groups across all clusters.

cons.

- Potentially cluster 1 could be overrunned if cluster 2 and 3 is unavailable and goes down.

 

No offens, but we are really hoping that someone in this community is in the same situation as we are. We are really struggling to find the right design, that would scale to more than 10.000 aps taking into account the limitation that airwave have. 

Highlighted
Guru Elite

Re: +10.000 AP in cluster design AOS 8.6

No matter what discovery method you use there will have to be a static plan.  There is no mechanism to automatically move APs from an overloaded cluster to a lightly loaded cluster.

 


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
ArubaOS Consolidated Release Notes
Aruba VIA ASE Solution - Configure VIA VPN
Highlighted
New Contributor

Re: +10.000 AP in cluster design AOS 8.6

Agree, we don't expect loadbalance between clusters. We know that an AP will only live within the cluster it have been assigned. Our main issue here is how do we control this static assignment of where the ap should connect. It's frustrating that we are not able to have only one cluster with all ap's in it. 

 

I'm curious how other companies handle this issue with the same scale.

Highlighted
Guru Elite

Re: +10.000 AP in cluster design AOS 8.6

I will leave it to organizations that to reveal how they are designed for access points at that size.  It is not my place to say what they have running.

 

I will say this based on the limited information you have given:

 

- With regards to discovery, access points only do dhcp, or dns-based recovery once in a clustered environment, so it is not necessarily something you have to constantly maintain.  Once access points find their cluster, the list of ip addresses of all controllers in that cluster (the nodelist) is saved onto the AP's flash.  If the AP reboots because of loss of power or reconfiguration, it does not do discovery again; it simply attempts to connect to all of the ip addresses in the nodelist.  Discovery exists only for access points to initially find their controller when they are new:  https://community.arubanetworks.com/t5/Wireless-Access/AP-termination-in-version-8-Clustering/m-p/428652#M81089

 

 


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
ArubaOS Consolidated Release Notes
Aruba VIA ASE Solution - Configure VIA VPN
New Contributor

Re: +10.000 AP in cluster design AOS 8.6

Yes, you are fully right. We have encountered the same issues.

 

We have made the design in the following way (based on your second suggestion) and running 8.5.0.x, however this is the same on 8.6:

 

Two (HW) Mobility Masters in active-standby mode (please take care with VRRP settings, the HW is a little bit slow and VRRP timers starting to run before the physical ports are available).

 

Below the MM there are 3 clusters:

  • Cluster 1 with 4 controllers, 2 in each datacenter seperated by cluster groups.
  • Cluster 2 and 3 with 2 controllers each, one in each datacenter.

Each Cluster is sharing one VRRP IP pointing to the Cluster leader, but which one is serving as VRRP anchor is not relevant. Termination IP is the VRRP IP of Cluster 1. 

 

We configure AP groups and LMS IPs on the Managed Devices level to ensure that all Clusters have the same information.

 

After first boot, the AP is connecting to Cluster 1 where it will receive the information to connect to cluster 1, 2 or 3. 

 

Cluster 1 is assigned to one Airwave instance, cluster 2 and 3 to another. Keep in mind to include the MM in all Airwave and to ignore the controllers that should not be visible if you need UCC information.

By this method you can limit the number of access points to the suggested limits.

 

At the moment we calculate with 80% of the datasheet limits on all platforms (recommendation of Aruba).

Meaning: 3300 APs per Airwave and per 4 Controllers in full redundancy -> 80% of 2048 for the 7280s ~ 1650 APs.

 

Our platform limit is currently the MM where we have 80% capacity planned -> 8k APs. This will be the bottleneck and everyone is hoping that AirWave 10 on-premise will be there before we hit this limit.

 

Hope this helps. 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: