RE: [WIRELESS-LAN] 'Clustering' and 'failover' in the context of Aruba
Hi John, We just went through the same scenario. We now have an Aruba/Alcatel 6000 with dual controllers...200 AP's as well. I concluded the following. 1.) Two controllers (same box) side A B, A-side is active, B-side is redundant. A-side fails, B-side takes over 2.) Major/minor upgrade - Upgrade B-side, swap, everything looks good, do a copy/synch to the A-Side 3.) Major/minor upgrade - Upgrade B-side, swap, upgrade fails, revert back to A-side 4.) Minor hardware failure - 1 controller fails, still operational 5.) Major hardware failure - backplane failure = tons of phone calls Item #5 is my weakest link. However, because the 6000 has dual-everything (except the chassis), I felt my exposure was minimal. I could not justify the cost of an additional 6000 for 100% redundancy. I looked at the smaller boxes with decentralized distribution...but the smaller boxes couldn't handle all 200 AP's simultaneouslyPlus it just adds complexity to our already overworked staff (troubleshooting would be more complicated). I hope this is helpful. Russ -Original Message- From: John Rodkey [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 7:24 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] 'Clustering' and 'failover' in the context of Aruba We are currently considering expanding our existing wireless environment to cover additional dorms. By doing so, we will exceed the capacity of our current controller, and can either add an additional controller card or for a slight incremental cost, add another controller. We planned to add the additional controller, with the idea that the controller would allow redundancy/failover/clustering to happen, so that if one controller were to go down, for instance, the other would take over. We were subsequently told that this was a faulty understanding of the failover function. So we thought we might be able to try another approach: every other WAP would be controlled by alternating controllers. That way, if controller A, with waps 1,3,5,7,9... on it were to go down, the coverage in any given building would be halved, because controller B, with waps 2,4,6,8 ... would continue to run. Nope, that is a bad idea, says the contact: each controller will maintain its own heat map and routing info, etc. and as a result, there would be nowhere to look for a unified picture of the wireless network. So I'm confused: what is the exact nature of controller clustering or failover under Aruba? Given somewhere in the neighborhood of 200 APs, how should one configure the controllers John ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] 'Clustering' and 'failover' in the context of Aruba
John, Others on the list have responded and given some good answers to your question. Let me add my experience and 2 cents. At Emory we have 1500 APs running in two Aruba systems - one for the Academic side of the house and one for our Healthcare organization. Needless to say, our Healthcare organization demands high availability :-) Our architecture is similar on each side - one set of redundant master controllers and multiple local controllers. In the Aruba architecture, the masters' function is to manage overall global issues - configuration, user and AP lists, heat maps, IDS correlation functions, etc. Masters can also support AP connections, like the local controllers. We don't have any APs homing to our master controllers (but we could if we wanted to). Instead, we home APs to local controllers. We also have a dedicated local controller as a back-up, i.e., if any of the local controllers fail, the APs would re-home to the backup. We have one local backup/system, and can withstand ONE controller failure at a time. Initially this a bit pricy, but as we've expanded, we find that a single backup controller works very well. In the past two years, we've only lost one controller (bad sup card), so our backup controllers are idle virtually all of the time. BTW - it is EASY (and necessary) to direct an AP or group of APs to specific controllers. In the command line, the syntax (vers 2.5 and below) is ap location location code lms-ip specific controller IP address. You can also set the backup controller using (again, ver 2.5 and below) ap location location code bkplms-ip backup controller IP address. There are a number of ways to build redundancy with the Aruba system, with the best way dependent on your situation. The method you mentioned with interleaving APs to different controllers WILL work because of Aruba's mobility/roaming capability. The problem arises if you only have one master and one local. Losing the master will prevent the global functions from happening (heat map, configuration, IDS correlation, etc) and the loss of servicing APs that are homed to it. Losing the local results in loss of ability to service the APs homed to it. Aruba licenses each controller to support a set number of APs. If you lose a controller, those APs will home where you told them to go, but if that backup doesn't have capacity (based on it's licensing) to handle those APs, they are effectively down. That's why we use an N+1 local controller model for our redundancy - a dedicated backup can handle all APs on any active controller - but sits idle most of the time. I realize that my ramblings on this subject may not be quite clear - so if you need additional explanations, or just want to pick my brain, touch base with me off the list. I've gone over a number of different redundancy scenarios as we've built our network, and may be able to offer some useful advice. - Stan Brooks - CWNA/CWSP Emory University Network Communications Division 404.727.0226 [EMAIL PROTECTED] AIM: WLANstan Yahoo!: WLANstan MSN: [EMAIL PROTECTED] -Original Message- From: John Rodkey [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 7:24 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] 'Clustering' and 'failover' in the context of Aruba We are currently considering expanding our existing wireless environment to cover additional dorms. By doing so, we will exceed the capacity of our current controller, and can either add an additional controller card or for a slight incremental cost, add another controller. We planned to add the additional controller, with the idea that the controller would allow redundancy/failover/clustering to happen, so that if one controller were to go down, for instance, the other would take over. We were subsequently told that this was a faulty understanding of the failover function. So we thought we might be able to try another approach: every other WAP would be controlled by alternating controllers. That way, if controller A, with waps 1,3,5,7,9... on it were to go down, the coverage in any given building would be halved, because controller B, with waps 2,4,6,8 ... would continue to run. Nope, that is a bad idea, says the contact: each controller will maintain its own heat map and routing info, etc. and as a result, there would be nowhere to look for a unified picture of the wireless network. So I'm confused: what is the exact nature of controller clustering or failover under Aruba? Given somewhere in the neighborhood of 200 APs, how should one configure the controllers John ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
RE: [WIRELESS-LAN] 'Clustering' and 'failover' in the context of Aruba
John, We are an Aruba shop, The way we have it setup here at BC is a Master (with all Vlans configured on it) and 4 local controllers (sup2's around 600 AP70's) The master is our failover, all 600 AP's are spread across the 4 locals and the master is our backup (no AP's on it). I had a problem with a local 1 and when it failed about 200 AP's failed over to the master and the users had no Idea. Now it sounds like our topology is different than yours but as long as your master can handle all the AP's that would fail over to it you should not have a problem. Brian J David Network Systems Engineer Boston College -Original Message- From: John Rodkey [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 7:24 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] 'Clustering' and 'failover' in the context of Aruba We are currently considering expanding our existing wireless environment to cover additional dorms. By doing so, we will exceed the capacity of our current controller, and can either add an additional controller card or for a slight incremental cost, add another controller. We planned to add the additional controller, with the idea that the controller would allow redundancy/failover/clustering to happen, so that if one controller were to go down, for instance, the other would take over. We were subsequently told that this was a faulty understanding of the failover function. So we thought we might be able to try another approach: every other WAP would be controlled by alternating controllers. That way, if controller A, with waps 1,3,5,7,9... on it were to go down, the coverage in any given building would be halved, because controller B, with waps 2,4,6,8 ... would continue to run. Nope, that is a bad idea, says the contact: each controller will maintain its own heat map and routing info, etc. and as a result, there would be nowhere to look for a unified picture of the wireless network. So I'm confused: what is the exact nature of controller clustering or failover under Aruba? Given somewhere in the neighborhood of 200 APs, how should one configure the controllers John ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
