An Introduction to the WMS Database
An Introduction to the WMS Database
06-26-2015 10:02 AM
Would you like to know more about the Wireless Management System (WMS) database? This article provides an introduction.
WHAT IS WMS?
The first thing to know is that “WMS” refers to different things in different contexts. It’s a designation for the different data-sets managed by the Master controller. The three main data-sets are ARM-data, WIP/IDS-data and RF-data.
As it was explained to us by an engineer from Aruba Customer Engineering (ACE), every minute, every AP goes off-air for 100 ms (seems like a long time, doesn’t it) to scan its environment and report its findings to the Master controller. The Master controller crunches this data and returns instructions to the APs. Thus, based on its ARM configuration and profile, an AP will scan for particular information and receive appropriate instructions. If you visit “Dashboard > Security” you will see the fruit of the WIP/IDS exchanges. And if you open up VisualRF, you will see the RF-data. When you talk about WMS, you need to be clear about what data you are including in your discussion.
Where is the WMS database maintained? Depends on which data-set you refer to. Let’s begin with WIP/IDS-data. To setup WIP, visit “Configuration > WIZARDS > WIP” in the Master controller GUI. You may also need to visit “Configuration > ADVANCED SERVICES > All Profiles > IDS” to modify some profile settings. The details are beyond the scope of this article but your configuration has a huge impact on the amount of data collected and processed by your master controller.
The controller stores the WIP/IDS-data in a MySQL database and you can get a snapshot of your database with the “wms export-db <filename>” command. This command creates a text script that can be sourced to create the tables and insert the data into a database on your own MySQL server. Very convenient. But before you can run the script on a modern version of MySQL, you will need to fix some syntax. It used to be legal to assign a default value to a field defined as “auto_increment”* (AOS uses MySQL version 3.22.32). Here is the command to use in vi to fix the syntax:
:%s/\(.*\)DEFAULT ‘0’ \(.*\)auto_increment/\1\2auto_increment/g
Now visit the Security Dashboard in the controller GUI. The information you see there comes from this database. Click on the number shown at the intersection of row “Rogue,” column “Active APs.” A list of currently classified rogues will display in the bottom pane. When you highlight a row in that pane the “Locate” button will become enabled. Click the Locate button. If the response says “No matches found” and it says “No matches found” for every row you look at, what does this mean?
In AOS 6.4.3, the default behavior was changed to disable the location data. According to the Technical Support Engineer we worked with, most customers do not use this feature and it has a heavy cost in both table size and memory consumption. To enable this feature, check the “Statistics update” box on the “IDS WMS General” profile. (Suggestion to Aruba: don’t display the “Locate” button if the feature is not enabled.) There is also a setting in this profile for “Collect Stats for Monitored APs and Clients.” The purpose of this setting and its relation to “Statistics update” is unknown.
We wanted to start with a known configuration and a clean database so we turned to the “wms clean-db” command. But the documentation and articles on this command and its relation to the “wms reinit-db” command is confusing. So we inspected our MySQL database and put dummy records in any tables that were empty. Then we used “wms import-db <filename>” to load the database on a test controller (you also need to issue “write mem,” and “reload” to reboot the controller.) We ran “wms clean-db” and took a snapshot of the database. We then reloaded the original database, ran “wms reinit-db” and took another snapshot. We then compared these two snapshots. Clean-db truncates the subset of tables holding WIP/IDS-data. Reinit-db truncates all the tables in the database. What are those other, non-WIP tables used for?
In our database those other tables were empty. As explained to us by our Aruba Systems Engineer, when AOS 6.3 was released, the RF-data was relocated to AirWave. The RF-data is still collected by the Master controller but it is handed off to AirWave and never stored locally. For us, there is no difference between running “wms clean-db” and “wms reinit-db.” But for those on AOS 6.2 or earlier, their RF-data is in this MySQL database and reinit-db will wipe it out, along with the WIP/IDS data. If you are running AOS 6.3 or later (we run 184.108.40.206), you may have never known that the VisualRF data used to be stored on the controller.
We know very little about this aspect of WMS. We can only guess that it is held in data structures in memory. But if you offload WMS, you will also be offloading the controller tasks related to ARM-data.
Very early in your reading about WMS you will be introduced to the idea of “Offloading” WMS to AirWave. Though it is short, the best documentation we could find about offloading WMS is in the “Aruba Networks and AirWave 8.0 Best Practices Guide.” Offloading is an important issue so let’s explore it.
One article on AirHeads** advises you to check the output of “show wms counters.” We think what the author meant to say is that if the “Total Tree Count” is approaching the “Max RB-tree Count,” then you should consider offloading. Here is the output for the smaller of our two Master-Local networks:
(MasterA) #show wms counters
Total Tree Count
MAX RB-tree Count
Max Count Exceeded – APs
Max Count Exceeded – STAs
An “RB-tree” is a highly efficient data structure and its value seems to place some sort of bound on the number of APs and/or clients that can be juggled by WMS. If you watch these counters throughout the day you will see the “Total Tree Count” peak when your network is busiest and ebb as activity declines. The “MAX RB-tree Count” can be adjusted by the “Max RBTree Entries” setting in the “IDS WMS Local System” profile. The setting defaults to 0 which means that AOS determines its value.
On the larger of our two Master-Local networks, AOS set the “MAX RB-tree Count” to 700,000. Very early in the day we would see our “Total Tree Count” hit that bound, which was then followed by non-zero values for the “Max Count Exceeded” counters. We began increasing the “MAX RBTree Entries” value and found that we had to set it at 1,800,000 in order avoid exceeding it. We read somewhere that each entry consumes 500 bytes so we watched our system closely as we began increasing it. We did not see a problem develop in our free memory allocation but we may have been looking in the wrong place.
Occasionally, when we entered a CLI command related to WMS, the system would pause and then respond with a message saying something like “wms is busy, try again later,” even though “show mem” and “show cpu” revealed no signs of stress. It was explained to us that “show cpu” is an average utilization for all the processors, while the WMS process is bound to a single processor. We did not know how to get a view on the utilization of that specific processor. Some resource is obviously struggling though, because our Security Dashboard often hangs when clicking around.
We also looked into the “show wms system” command. The documentation for this command does not include an explanation for the section of output labeled “WMS Offload State” but on our larger network it reinforces the idea that we need to Offload WMS:
(MasterB) #show wms system
WMS Offload State
We were advised to offload WMS by two tiers at TAC, by our Systems Engineer, by every reference on AirHeads and even by the CLI output of the “show wms system” command. But when we casually mentioned offloading WMS while visiting with some members of the ACE team, we were strongly advised not to offload. The general message was that there was a time when offloading WMS was a good idea but that time was past. Offloading is now likely to cause more problems than it solves. In our particular case we could not offload even if we wanted to because our AMP servers could not handle the additional load. Our solution, which is already in the works, is to upgrade our M3 Master controllers to 7240s.
“WMS” is not a well-defined term. “WMS” documentation is sparse and some of it is outdated. Get familiar with your WID/IDS configuration, it represents a large chuck of WMS. Know where your RF-data is stored. If you are considering offloading WMS, make sure you have up-to-date and expert advice on the benefits, consequences and alternatives.
* Our thanks to Chris Karakas at http://www.karakas-online.de/forum/viewtopic.php?t=2732