1. 先搞清楚 70xx 上 Master Redundancy 到底在保什么Aruba 无线控制器 70xx 系列很多朋友是拿它当中小园区或者分支机构的大脑来用的。到 8.x 版本AOS 的架构彻底转向了 Master / Local 分层Controller 的角色被拆得更细。8.x 之前一台 Master 基本就是唯一的大脑配置、认证、策略、AP 上线全靠它一旦它出问题下面的 Local 和 AP 虽然还能靠转发面撑一小会儿但控制面的事情基本停摆客户端掉线、新 AP 上不来、Portal 页面打不开现场一团乱。8.x 这套Master Redundancy主控冗余想解决的正是这个单点问题两台 Master 互相盯着一主一备或者双主谁的数据库新、谁的 VRRP 优先级高谁就接管另一台随时顶上。我第一次在 70xx 上做这个配置是因为一个客户的核心机房只有一台 7030 做 Master机房里跳电一次整栋楼的无线认证就瘫了二十分钟。那次之后客户拍板要加冗余我就开始认真研究 8.x 的这套机制。这篇文章就把我当时踩过的坑、配过的命令、验证过的方法完整地摊开讲一遍从为什么要做讲到怎么做、怎么验、怎么排错适合已经有一点 ArubaOS 基础、但没正儿八经上过 Master Redundancy 的朋友参考。1.1 单台 Master 挂掉的后果比想象中严重很多人觉得AP 上有配置Master 挂了照样能转发这话只对了一半。在 ArubaOS 8.x 的架构里AP 的控制隧道是挂在 Local 或者 Master 上的认证、AAA 交互、集中转发的隧道建立、策略下发这些都离不开 Master。Master 一挂已经认证过的客户端可能还能靠数据面继续跑一阵子但只要涉及重新认证、AP 重连、策略更新立刻卡住。更麻烦的是8.x 里 Master 承担着数据库本地用户、认证记录、AP 数据库的统一下发职责它一停整个网就像大脑缺氧。而 70xx 系列的定位本身就偏轻量中枢一台设备要扛几十上百个 APCPU 和内存的余量并不算特别宽裕硬件层面的老化、电源故障、人为误操作比如改配置把管理口锁死都是现实风险。所以给 70xx 做 Master Redundancy不是为了炫技是为了在真正的故障窗口里把整网失能十分钟压缩成抖一下、几秒恢复。我当时的判断很简单客户既然用了 7030 扛核心就没有理由不给它配一个备胎。这个备胎不一定非得是同样闲着的硬件它可以同时承担一部分转发任务关键时候才顶上来做主控。1.2 Master Redundancy 的核心机制是数据库 VRRP 心跳这套机制拆开看是三根支柱理解了这三根配置就不容易配错。第一根是数据库同步。两台 Master 之间会同步配置数据库和本地数据库包括 WLAN 配置、认证策略、本地用户这些信息。同步是增量的谁手里数据新谁就在主控位。8.x 里这部分由 Master 之间的对等关系来维护配置一致是前提。第二根是VRRP 虚拟 IP。这是整个方案里最关键的一个设计。真实的 Master 有各自的物理 IP但对下Local、AP、外部 AAA暴露的是一个 VRRP 虚拟 IP也就是虚拟主控地址。所有 Local 都指向这个虚拟 IP这样无论哪台 Master 在主控位IP 都不变下面完全无感。Master 切换的本质就是 VRRP 主备关系的切换谁拿到虚拟 IP谁就是 Master。第三根是心跳链路。两台 Master 之间要有一条能互相探活的通道通常就是它们直连的管理网段。这条链路会跑 IPSec 加密的对等通信心跳断了对端就认为你挂了触发抢占或者接管。这三根支柱里数据库同步决定了切过去之后配置对不对VRRP 决定了谁接管心跳决定了什么时候切。任何一根出问题冗余就是纸糊的。1.3 70xx 里哪些型号能玩这套不是所有 70xx 都能无差别地上 Master Redundancy。7005、7010 这种入门型号在 AP 容量和功能授权上都有取舍做冗余前一定要先看 datasheet 和授权。7024、7030 这类中端型号做 Master Redundancy 相对从容也是我实操最多的型号。硬件上两台 Master 最好是同型号如果不同型号也要确认它们能组成冗余对否则容易在数据库同步阶段报奇怪的错。还有一个坑是授权License。Master Redundancy 相关的功能通常需要对应的高级授权缺授权时你会发现命令能敲下去但状态一直起不来。我的习惯是配置前先show license把该有的都确认一遍宁可提前补也别配到一半卡住。2. 配置前的规划与准备把地基打牢Master Redundancy 这种两台设备协同的配置最忌讳上来就敲命令。前期规划做扎实后面能省一大半排错时间。我在客户现场踩过的坑里至少一半是IP 规划没想清楚时间没对齐对端地址填错这类低级的规划问题完全不涉及技术难度。2.1 网络拓扑和 IP 该怎么分先给两台 Master 划好地址。假设我们有 Master-A 和 Master-B 两台 70xx管理网段是 10.10.10.0/24那么规划大概是这样的设备/对象角色建议地址说明Master-A主控设备10.10.10.11/24物理管理地址Master-B备用设备10.10.10.12/24物理管理地址虚拟主控 IPVRRP VIP10.10.10.10/24所有 Local 指向它心跳/对等链路两台之间同网段即可通常复用管理口这里要强调一点虚拟主控 IP 是给下面设备指向用的两台 Master 的物理 IP 是它们自己用的。很多人配完 VRRP 之后忘记把 Local 上配置的 Master 地址从物理 IP 改成虚拟 IP结果主备切了下面的设备还在死盯着已经挂掉的物理 IP切换等于没发生。这是最常见的配了但没用的原因。另外两台设备之间的 RTT 建议很低最好在同一机房、同一交换机下因为数据库同步和心跳对延迟比较敏感。如果有条件给心跳留一条独立的链路更稳妥管理网和心跳混跑也行但要保证这条链路不会被 STP 收敛或者链路抖动频繁打扰。2.2 时间和基础配置必须先对齐两台设备的时间必须一致我习惯在配冗余之前先把 NTP 配上让两台 Master 指向同一个时间源。时间差太大的时候数据库同步的版本判断会出现诡异的比较结果轻则同步慢重则主备角色反复横跳。顺手把 hostname、default-gateway 这些基础项也配好hostname 最好和角色对应比如 aruba-master-a / aruba-master-b后面看日志时一眼就能分清是谁在说话。具体的基础配置大概是这样(host) [mynode] (config) #hostname aruba-master-a (aruba-master-a) [mynode] (config) #ntp server 10.10.10.1 (aruba-master-a) [mynode] (config) #ip default-gateway 10.10.10.254 (aruba-master-a) [mynode] (config) #clock timezone Asia/Shanghai对应地Master-B 上把 hostname 换成 aruba-master-b其余保持一致。配完之后用show clock和show ntp status确认两台时间对齐这一步别嫌烦我见过不止一次因为时间没对齐导致 master-redundancy 状态卡在 INIT。2.3 型号、授权、版本三件套先检查动手前把这三样确认清楚能避免很多无用功型号两台是否同型号或官方支持组成冗余对的型号授权Master Redundancy 相关的 License 是否已经安装版本两台 AOS 版本是否一致或者至少是官方允许协同的版本。版本这块我特别提醒一句AOS 8.x 的小版本之间差异不算小两台 Master 版本不一致时虽然有时也能同步但历史上出现过同步后行为不一致的情况。稳妥做法是先把两台刷成同一个版本再配冗余。检查命令(aruba-master-a) [mynode] #show version (aruba-master-a) [mynode] #show license (aruba-master-a) [mynode] #show switchesshow switches能看到当前 8.x 集群里各个控制器的角色为后面验证做准备。3. VRRP 虚拟 IP 的搭建冗余的命根子VRRP 是 Master Redundancy 的核心配置本身不难但细节多配错了就是看起来有主备实际不切换。我一般先单独把 VRRP 配好验一遍再叠加 master-redundancy这样出了问题是哪一层的一眼就能分清。3.1 VRRP 基础配置的逐行拆解在两台 Master 上各自对管理所在的 VLAN 接口启用 VRRP。以 Master-A 为例假设管理口在 VLAN 1(aruba-master-a) [mynode] (config) #interface vlan 1 (aruba-master-a) [mynode] (config-submode) #ip address 10.10.10.11 255.255.255.0 (aruba-master-a) [mynode] (config-submode) #exit (aruba-master-a) [mynode] (config) #vrrp 1 (aruba-master-a) [mynode] (config-vrrp) #ip address 10.10.10.10 (aruba-master-a) [mynode] (config-vrrp) #priority 110 (aruba-master-a) [mynode] (config-vrrp) #preempt (aruba-master-a) [mynode] (config-vrrp) #authentication aruba123 (aruba-master-a) [mynode] (config-vrrp) #exitMaster-B 上把接口地址改成 10.10.10.12VRRP priority 改成 100比 A 低其余保持一致(aruba-master-b) [mynode] (config) #interface vlan 1 (aruba-master-b) [mynode] (config-submode) #ip address 10.10.10.12 255.255.255.0 (aruba-master-b) [mynode] (config-submode) #exit (aruba-master-b) [mynode] (config) #vrrp 1 (aruba-master-b) [mynode] (config-vrrp) #ip address 10.10.10.10 (aruba-master-b) [mynode] (config-vrrp) #priority 100 (aruba-master-b) [mynode] (config-vrrp) #authentication aruba123 (aruba-master-b) [mynode] (config-vrrp) #exit几个关键参数说一下vrrp 1里的 1 是 VRID两台必须用同一个 VRIDip address填的是虚拟 IP不是自己的物理 IPpriority决定谁当主数值大的当主两台必须不同preempt表示抢占主挂了备接管之后主恢复回来会重新抢回主控位。注意VRRP 的认证密码两台必须一致否则会一直卡在认证失败状态备机永远接管不了。3.2 虚拟 IP 规划里最容易忽略的一个细节虚拟 IP 必须是管理网段里空闲的地址不能和任何设备冲突也不能是网络号或广播号。我遇到过客户随手填了个地址结果跟机房里某台打印机撞了VRRP 起来了但 ARP 冲突间接导致切换不稳定。配完 VRRP一定要用show vrrp 1确认状态是 MASTER 还是 BACKUP两台状态应该一主一备。(aruba-master-a) [mynode] #show vrrp 1输出里重点关注 State、Priority、Virtual IP 这几列。正常情况下A 是 MASTER、B 是 BACKUP。如果两台都是 BACKUP 或都是 MASTER说明 VRRP 通信没建起来先查链路和认证。3.3 把 Local 指向虚拟 IPVRRP 配好之后千万不要忘记这一步所有 Local 控制器以及需要指向 Master 的其他设备上原来指向物理 IP 的地方全部改成虚拟主控 IP。8.x 里 Local 是通过master相关的配置指向主控的改完之后它就会一直盯着 10.10.10.10不管实际是哪台设备在主控位。这一步是整个方案无感切换的关键。我当时在客户现场就是因为漏改了 Local 的指向第一次测试切换时下面完全没反应排查了半天才发现 Local 还指着物理 IP。改完之后切换瞬间就通了。所以我把这一步单独拎出来强调别嫌啰嗦。4. master-redundancy 的配置与数据库同步VRRP 是前提master-redundancy 才是让两台设备真正结为冗余对的动作。这部分的核心是配置对等地址、对等密钥然后建立数据库同步。4.1 配置对等关系与 IPSec 密钥在 Master-A 上进入 master-redundancy 配置模式指定对端Master-B的真实物理 IP并配置对等密钥(aruba-master-a) [mynode] (config) #master-redundancy (aruba-master-a) [mynode] (config-master-redundancy) #peer-ip-address 10.10.10.12 (aruba-master-a) [mynode] (config-master-redundancy) #peer-ipsec-key aruba123在 Master-B 上做对称配置对端指向 Master-A(aruba-master-b) [mynode] (config) #master-redundancy (aruba-master-b) [mynode] (config-master-redundancy) #peer-ip-address 10.10.10.11 (aruba-master-b) [mynode] (config-master-redundancy) #peer-ipsec-key aruba123两边的peer-ipsec-key必须完全一致大小写、特殊字符都不能错。密钥不一致时对等隧道建不起来状态会停在类似 INIT 或失败的状态日志里能看到 key mismatch 之类的提示。我一般会把密钥设得既有大小写又有符号别用纯数字减少被猜到的可能但同时也记牢因为输错一位就废了。提示具体进入 master-redundancy 后的子命令名称和可用选项随 AOS 8.x 小版本可能有细微差别敲之前先打问号看命令补全确认当前版本支持哪些子命令。4.2 数据库同步怎么触发和验证对等关系建立后数据库同步会被触发。8.x 里同步是基于版本的增量同步正常会看到两台设备状态互相确认。可以手动触发同步来加速(aruba-master-a) [mynode] #database synchronize执行后观察日志和状态。验证的常用命令(aruba-master-a) [mynode] #show master-redundancy (aruba-master-a) [mynode] #show database synchronize重点看对等状态是否是 UP / established同步是否有报错。数据库同步不是一次性的事配置变更后会继续同步所以两台设备的配置漂移不能太大否则同步会一直报冲突。我实测下来的体会是同步初始阶段最慢尤其本地数据库里东西多的时候比如一堆本地用户、证书第一次全量同步可能要几分钟。耐心等一等别急着判断失败。同步过程中如果中途断了心跳会从头再来所以初期一定要保证链路稳定。4.3 让角色关系定型谁主谁备数据库同步完成、VRRP 角色明确之后主备关系就定型了拿到虚拟 IP 的那台VRRP 优先级高的 A同时是 Master 主控B 是备控。此时用show master-redundancy应该能看到两端互相 recognize角色清晰。如果 VRRP 主备和 master 主备不一致说明配置哪里有矛盾比如 VRRP 优先级和预期相反或者两台都配了 preempt 导致争抢。我建议配置完成后按这个顺序验证一遍先看show vrrp一主一备再看show master-redundancy两端对等 UP最后看show switches里主备角色清楚。三步都对才算真正配好。5. 切换测试与常见问题排查实录配置完成不等于能用一定会遇到看着正常、切换却掉链子的情况。把切换测试当成验收的一部分是我做这套方案最大的心得。下面把我实测过的切换方法和典型问题整理出来。5.1 手动验证切换的几种方法最直接的验证方式是让主控下线看备控能不能自动接管、下面是否无感。手法有几种安全性从高到低排列正常重启主控在主控上执行reload等它起来的过程里观察备控是否接管、Local 是否无感。这种方式最接近真实故障推荐。断开主控的上行链路拔掉主控管理/上行链路模拟链路故障观察 VRRP 是否切换。调整 VRRP 优先级临时把主控优先级调低、备控调高触发切换用于不中断业务的验证。我的习惯是先做一次优先级调整的软切换业务基本无感确认机制通了再找窗口做一次真重启确认极端情况也可用。软切换如果都不成功真重启也白搭先修好再说。切换后要验证的点虚拟 IP 是否漂移到备控、Local 是否还在线、客户端是否重新认证、AP 是否正常。如果虚拟 IP 漂移了但客户端掉线问题多半在数据库同步说明备控拿到的配置和主控不一致切过去后行为变了。5.2 常见问题速查表现象可能原因排查方向两端状态一直不能建立对等密钥不一致、物理 IP 填错检查 peer-ipsec-key 和 peer-ip-addressVRRP 两台都是 BACKUP认证密码不一致、VRID 不一致用 show vrrp 对比两端配置VRRP 一主一备但切换不生效Local 指向的还是物理 IP检查 Local 的 master 配置切换后配置不一致数据库同步未完成或有冲突show database synchronize 看报错主恢复后反复横跳preempt 配置不当或链路抖动检查 preempt 和心跳链路质量状态卡在同步中很久首次全量同步数据量大观察日志耐心等待或手动触发时间不一致导致角色混乱未配置统一的 NTP两台都指向同一时间源这张表是我自己排错时反复用到的基本覆盖了八成以上的现场问题。每次遇到新的我会补充进去时间久了就成了自己的急救手册。5.3 一个让我印象深刻的坑心跳链路被管理网拖累有一次客户的 Master Redundancy 老是偶发性地切换日志里能看到对等关系短暂中断又恢复。查了半天最后发现两台 Master 的心跳跑在了一个频繁 STP 收敛的管理网段上链路每次收敛对等心跳就丢一次丢到阈值就触发切换切完又恢复来回折腾。后来我把两台之间的心跳单独划了一条链路或者至少保证这条路径足够稳定、不参与频繁的生成树变化问题就消失了。这个坑给我一个很深的体会冗余方案的稳定性很多时候不取决于配置命令而取决于底层网络的质量。心跳链路必须是安静的任何频繁抖动的东西都会把它玩坏。所以我现在做这套方案一定会问一句这两台之间的链路稳不稳会不会有 STP 或者其它周期性抖动如果答案是不太确定那就先解决链路问题再配冗余。5.4 数据库同步的独家避坑经验数据库同步这块我踩的坑最多总结几条实战经验配置变更尽量在同步完成后做。初始同步没完成就大改配置容易导致两边版本判断混乱同步反复失败。本地数据库别塞太多东西。本地用户、证书这一类数据越多同步越慢。能走外部 AAA 的就别全放本地。同步不是实时的有周期。别测完一个改动立刻就想看对端生效给它几个周期的时间或者手动database synchronize触发。同步出问题先看日志。8.x 的日志里对同步失败的原因写得很细key、版本、链路都会写清楚比盲猜高效得多。这几条没有一条写在官方文档的显眼位置但每一条都来自真实现场希望对你有用。我个人在实际操作里的体会是70xx 上做 Master Redundancy命令本身半小时就能配完真正花时间的是前期规划、链路准备和切换验证。千万别把命令敲完状态是绿的当成完工一定要真真切切地切一次看下面到底有没有感觉。最后再分享一个小习惯我会把两台 Master 的 VRRP 状态、对等状态、同步状态做成一张核查清单每次变更前后都过一遍时间久了这套东西就从玄学变成确定性操作了。