> 1) How many WAPs are you currently managing with a single Airwave > appliance?
881 right this moment. > 2) What is the (average) polling interval used? 300 seconds. > 3) Do you have multiple Airwave servers, and if so, how many WAPs > managed on each one? How do you plan to scale--additional separate > servers, or a beefier single server? No, just the one. > 4) What are your server specs? (Vendor, OS, number of CPUs and their > speed, amount of RAM, number of active NICs, etc.) Currently running on: Dell Poweredge 1750 w/dual 3.06GHz Xeon, 6GB Ram, mirrored 73GB 10,000 rpm SCSI-320 drives running RedHat Enterprise Linux 3 (32-bit). We've just received a new server that will replace the Dell: Sun SunFire V40Z w/quad Opteron 852s (2.6GHz), 16GB Ram, mirrored 73GB 15,000 rpm scsi-320 drives running Redhat Enterprise Linux 4 (32-bit). */ This is a huge server but it was a Sun educational special that made it a better deal than a lesser one. /* */ We bought two dual-CPU licenses to legally run on the quad-CPU box /* > 5) How is performance on your server? Do you notice performance > degradation over time? About how much memory is used under average > load? How busy are the CPUs under average load? How much network > traffic is generated from polling? Ours gets sluggish but not (usually) to the point of needing a reboot. Pulling up the "Users-All" page takes several minutes. I'm convinced that much of this delay is in the generating and rendering of the html on the broswer. I say this because I've found that SQL queries of the same data directly against the database come back much more quickly. Yes, we have noticed some degradation over time and, just last week, had to reboot the server after it had been up for almost 100 days. I assume that most of the processes get killed and restarted nightly during their maintenance jobs. We had a problem a few versions ago where SNMP polling died. Airwave engineers whipped us up a patch in an hour or so and then then next version had the problem fixed. Since that problem, I've had a cron job that periodically checks the age of the newest file in /var/airwave/rrd/dot11_counters. We haven't seen the problem reoccur but I saw no compelling reason to remove the cron job. As far as memory and CPU: I don't do any sar reporting or anything like that for continuous data. Looking at 'top' right now, I see a load agerage of 4.4. Memory usage is another thing altogether. As you probably know, Linux will use available memory for disk buffering. Unlike Solaris, which I am more familiar with, Linux does not seem to return this free memory when disk activity is low and large processes exit. Thus, we start out with 5GB of free memory and progressively get down to around 100Mb free. We run a backup of the machine each night, which obviously does a lot of disk I/O, which consumes the disk buffer memory. It's not unusual to see some tiny bit of swap in use after the machine has been up for weeks. I haven't measured the network traffic from polling. We've got Gigabit interfaces and haven't noticed any network contention. > 6) How do you manage security concerns? (i.e. most Airwave processes > running as root, installed in /root, root ssh remote logins enabled by > default on default port, most components are written in Perl which can > easily be modified if the machine is compromised, compilers are > installed locally, etc.etc.etc.) Many of these are addressed by running under RedHat Enterprise Linux, which allows us to run 'up2date' to get the latest patches. You have to be careful not to clobber any packages that have been modified by Airwave. Note that running under RHEL is not for the faint of heart. There's a lot of fiddling and package reconciliation to do. I had considered running the Fedora image that comes with AMP for this upgrade, but the SunFire V40z won't boot off that CD directly. I'm sure there's a scsi driver that needs to be added but I didn't fool with it any further. I had a similar problem when we first got the Dell 1750 and it needed a network driver. AMP support was familiar with the problem and talked me through adding the driver and getting things installed, so I'm pretty confident that we could get the SunFire V40z running on their Fedora image if we really wanted to. Redhat only costs like $50 for educational customers and we've now got a site license. I asked Airwave if they'd consider making RHEL their primary platform, but they were concerned that folks would balk at the additional license cost. After I've paid for the server and the AMP software, I'm not going to sneeze at another $50! I've since heard that they're talking to RedHat about licensing. In the mean time, they tell me that they are switching from Fedora to CentOS distribution which is almost identical to RedHat Enterprise Linux. This should make it much easier to run under RHEL. They may have already made the switch. Anyway, back to security: We definitely don't allow anyone to log into the box that doesn't need to. A simple 'ps' will show you passwords to the database, etc. Only admins and the noc can get a shell on the box. We review the nightly incremental backups to see which files have changed to detect any mischief. We run the iptables firewall that comes with RHEL and keep the machine locked down tight. ssh only from my workstation and the noc. https accesss only from on-campus. A few ports open for ntp and our backup software and everything else is closed off. > Inquiring minds want to know (and want to get the statistics we need to > manage the network). I'd love to get tuning info on the Postgres database. It's bound to need some different settings running in 16GB of RAM than what it has at 6GB. Database profiling and optimizing could surely improve performance. All that said, I really love the product. This is like the product that we would write in-house if we had to do it. Add to it the fact that Airwave engineers are so responsive to our requests and needs and that's why we dropped the big bucks for a monster server and another license to run the package. Ask me in a few weeks if the new server is noticeable faster. Crossing my fingers.... :-) -- Earl Barfield -- Academic & Research Technologies / Information Technology Georgia Institute of Technology, Atlanta Georgia, 30332 Internet: [EMAIL PROTECTED] [EMAIL PROTECTED] ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
