Adding my $0.02 from a decently sized higher ed deployment . . .
Your core and distribution topology will undoubtedly have influence on your chosen WLAN deployment. You essentially are looking at two options:
- Manage lots of lower capacity controllers in a distributed fashion, or
- Manage fewer high capacity controllers in a centralized fashion
With AOS 8, both methods are easy, as whether it is 1 controller or tens/hundreds, the configuration hierarchy makes them fairly easy to manage. However, I chose centralized in order condense the amount of infrastructure we are managing.
We have two data centers and each one has a separate "MM domain" (not sure that is a correct term, but it's what I use). Both DCs have 2 primary clusters of 7240XM controllers. One of the DCs has a third smaller cluster that we consider "early release" - a place to first install new code, try new features, etc, as it represents a sampling of academic, staff, residential, and classroom environments. Ideally, we would've only maintained a total of three clusters instead of five; however, we were exceeding the number of devices per Airwave server and needed to slice things up a bit to accommodate those limits.
Our configuration hierarchy for the controllers is set up as follows:
/md
/md/osu
/md/osu/cluster1
/md/osu/cluster1/controllers...
/md/osu/cluster2
/md/osu/cluster2/controllers...
- All controller-specific configuration is added at the controller level. This includes things like hostname, vrrp, time, spanning-tree, management vlan, and interface config, including port-channeling
- All vlans, vlan pools/mapping, and airwave configuration is added at the cluster level. This ensures that we can maintain the L2-cluster configuration and avoid scenarios where an L2 cluster breaks and resorts to L3.
- ALL other configuration, including ap-groups and profiles therein, are created at the orgainzation level (/md/osu). This ensures that no matter where an AP first lands during master discovery, the cluster it first touches has the correct LMS IP (read: cluster VIP) and can migrate APs to the correct cluster.
- We write NO configuration at the top level (/md) as to avoid any Aruba defaults overwriting custom configurations made at that level
That's probably plenty of opinion, but if you have any targeted questions, feel free to follow up.
Good luck!