去年冬天帮一家制造企业做无线改造核心是一台 Aruba 70xx 无线控制器固件跑的是 ArubaOS 8.x。项目上线三个月一直很稳直到某个周一早上控制器电源模块报警直接重启园区里两百多个 AP 齐刷刷掉线。员工刷不开考勤、扫码枪连不上 Wi-Fi、产线终端全断。事后复盘硬件本身只是小毛病真正要命的是整套架构一台控制器扛所有业务压根没做 Master Redundancy主备冗余。这件事之后我把 Aruba 8.x 的 Master Redundancy 又从头到尾捋了一遍。很多人对 8.x 的理解还停留在配置个备份控制器就完事的阶段其实 8.x 的控制平面架构和 6.x 完全不是一回事Master这个词指代的对象变了冗余的实现方式也跟着变了。这篇文章就围绕Aruba 70xx 无线控制器在 ArubaOS 8.x 下的 Master Redundancy 配置展开把架构背景、参数含义、完整配置命令、验证方法以及切换失败时的排查链路都讲透。不管你是刚接触 Aruba 的新手还是从 6.x 转过来的老网工都能照着这篇把主备冗余跑起来。1. 8.x 里的Master已经不是 6.x 那个 Master 了不少工程师配 Master Redundancy 配得云里雾里根子在于用 6.x 的思维去套 8.x 的架构。所以先别急着敲命令先把谁是 Master、冗余的是谁这件事掰清楚否则后面参数填错方向配完了也切不过去。1.1 从 master-local 到 Mobility Master 的控制平面重构ArubaOS 6.x 时代架构非常直白一台master controller管配置和转发的大脑下面挂若干台local controller管本地 AP 和客户端。要做冗余就是给 master 配一台 standby master两台之间跑 VRRPmaster 挂了 standby 顶上这就是 6.x 的 Master Redundancy。到了 8.x架构被彻底重构控制平面被单独拆出来形成了Mobility MasterMM 受管节点Managed Node / MC的两级结构。MM 负责全局策略、配置下发、AP 白名单这些大脑工作受管节点也就是原来意义上的控制器负责干活承接 AP 上线和客户端数据转发。AP 的控制隧道先连到受管节点受管节点再跟 MM 建立连接。这个变化带来的直接后果是8.x 里Master这个角色落到了 Mobility Master 身上。你要做的冗余是让两台 MM 互为主备而不是像 6.x 那样给一台控制器配备份。理解了这一点Master Redundancy这个词的指向就清楚了。1.2 70xx 在 8.x 部署里的身份选择70xx 系列7005、7010、7024、7030是 Aruba 的中小规模控制器8.x 里它有两种典型用法。一种是老老实实当受管节点上面再放一台虚拟 MM 统一管理另一种是在相对简单、预算有限的部署里直接用硬件控制器承担 Mobility Master 的角色——8.x 是允许硬件设备充当 MM 的因为 MM 说白了就是控制平面进程硬件控制器有计算能力就能跑。两种用法下Master Redundancy 的配置逻辑是一致的区别只是你冗余的是专职 MM还是兼职 MM 的控制器。我个人的经验是如果分支或中小园区只有两台 70xx直接让它们组成 MM 主备是最省事、最省钱的做法如果是总部级多控制器集群那就老老实实单独上 MM让 70xx 专心当受管节点。1.3 Master Redundancy 到底冗余了哪些东西搞清楚对象之后再看冗余的内容。Master Redundancy 本质上做了三件事VIP 接管两台设备之间跑 VRRP对外暴露一个虚拟 IPVIP。所有受管节点、AP 指向这个 VIP谁持有 VIP 谁就是当前生效的 Master。主设备宕机备设备在秒级内接管 VIP。数据库同步MM 上的配置、策略、AP 数据库等是要在主机和备机之间保持同步的。备机之所以能无缝接管是因为它手里有一份和主机几乎一致的配置库。状态同步与心跳两台设备之间通过独立通道互发心跳判断对端是否还活着同时把运行状态做同步。说白了主备冗余的目标就一句话任何一台挂了受管节点和 AP 都感觉不到大脑换人。要做到感觉不到VRRP、数据库同步、心跳三样缺一不可。下一节开始准备动手。2. 开工前先把三件事定死版本、心跳网络、许可配置命令就那么几行但真正决定这套冗余靠不靠谱的是开工前的规划。我见过太多命令敲得挺溜、一测切换就翻车的案例问题几乎都出在准备阶段没定死三件事。2.1 版本与硬件必须对齐第一件事主备两台的 ArubaOS 版本必须完全一致。这里的一致是精确到补丁号的8.6.0.0 和 8.6.0.1 都算不一致。版本不一致时VRRP 可能能起来但数据库同步会失败或者同步完配置错乱切换后行为诡异。升级维护时也要注意两台要一起升不能只升一台。第二件事是机型能力对齐。主备最好用同型号或能力相当的设备虽然配置允许异型号互备但容量、端口、许可差异会在切换后暴露出来。比如主机是 7030、备机是 7010主机扛 500 个 AP 一切正常切到备机就顶不住了这种冗余了个寂寞的情况在实际项目里并不少见。2.2 VRRP 心跳网络怎么划规划第二件事心跳网络的划分。VRRP 的心跳和数据库同步的数据流都跑在一张网络上。这张网络怎么划直接决定冗余质量。我的做法是专线专用。给主备两台之间单独拉一条直连链路或者一个专用 VLAN只跑冗余流量不和业务流量混。理由很简单——如果心跳和数据库同步跟业务流量挤在一个接口上业务高峰时链路拥塞心跳丢包很容易触发误切换。本来主备都活着结果业务一忙就来回切反而制造了故障。规划时还要注意几点VRRP 使用的 VLAN 必须是两台设备都可达的同一二层域这个二层域要保证低延迟、低丢包别跨过一堆交换机堆叠环VIP 要选一个从未被占用的地址最好在规划表里单独登记避免和 DHCP 池、网关地址冲突。2.3 许可与容量核对规划第三件事许可。8.x 里 MM 和受管节点对应的许可类型不同做冗余前要确认两台设备都有对应的许可。尤其要注意如果备机平时不参与转发业务很容易在采购时漏配许可等到切换那一刻才发现备机许可不够那就尴尬了。容量方面也要算一笔账。备机要能承接主机全部的业务负载包括核对项说明常见坑AP 数量许可备机许可 AP 数要 ≥ 主机实际在线 AP 数只按采购数买没留冗余余量客户端容量备机最大并发客户端要覆盖主机高峰期切换直接过载隧道/带宽备机转发能力要匹配数据中心型业务切换后卡顿功能许可PEF、RFProtect 等按需备机缺高级功能许可把这三件事定死再动手配置后面基本就是一马平川。下面进入实操。3. 两台设备的完整配置链路配置阶段我习惯分三步走先把基础接口和网络准备好再配 master-redundancy 主体参数最后确认 IPSec 和数据库同步。下面以两台 70xx 组成 MM 主备为例IP 规划我假设如下你对照自己的规划替换即可。角色设备管理/心跳 IP说明主机ActiveMM1172.16.30.1VRRP 优先级高备机StandbyMM2172.16.30.2VRRP 优先级低VRRP VIP虚拟172.16.30.100受管节点/AP 指向它3.1 基础接口与网络准备先把承载 VRRP 的 VLAN 和接口配好两台都要配。假设心跳 VLAN 为 VLAN 30(MM1) [mynode] #configure terminal (MM1) [mynode] (config) #vlan 30 (MM1) [mynode] (config-vlan-30) #exit (MM1) [mynode] (config) #interface gigabitethernet 0/0/1 (MM1) [mynode] (config-if) #switchport mode access (MM1) [mynode] (config-if) #switchport access vlan 30 (MM1) [mynode] (config-if) #exit (MM1) [mynode] (config) #interface vlan 30 (MM1) [mynode] (config-if) #ip address 172.16.30.1 255.255.255.0 (MM1) [mynode] (config-if) #exitMM2 上把接口地址换成 172.16.30.2其余一致。这一步看着简单但有个细节别在配 master-redundancy 之前就把接口 IP 配成 VIPVIP 是由 master-redundancy 接管生成的你手动配上去会冲突。3.2 master-redundancy 参数逐个拆解基础网络就绪后进入正题。在两台上分别进入 master-redundancy 配置上下文(MM1) [mynode] (config) #master-redundancy (MM1) [mynode] (config-master-redundancy) #master-vrrp 30 (MM1) [mynode] (config-master-redundancy) #vrrp-ip 172.16.30.100 (MM1) [mynode] (config-master-redundancy) #peer-ip-address 172.16.30.2 ipsec Abc12345xy (MM1) [mynode] (config-master-redundancy) #exit (MM1) [mynode] (config) #write memoryMM2 上做对应配置(MM2) [mynode] (config) #master-redundancy (MM2) [mynode] (config-master-redundancy) #master-vrrp 30 (MM2) [mynode] (config-master-redundancy) #vrrp-ip 172.16.30.100 (MM2) [mynode] (config-master-redundancy) #peer-ip-address 172.16.30.1 ipsec Abc12345xy (MM2) [mynode] (config-master-redundancy) #exit (MM2) [mynode] (config) #write memory逐个参数解释一下别照抄master-vrrp 30指定 VRRP 运行在 VLAN 30 上。这个 VLAN 必须是对端可达的同一二层域。填错 VLAN 是 VRRP 起不来的头号原因。vrrp-ip 172.16.30.100VRRP 虚拟 IP两台必须填完全相同的值。这是整个冗余的对外门牌号受管节点和 AP 都认它。peer-ip-address ... ipsec ...指定对端的真实 IP并给出 IPSec 预共享密钥。注意这里填的是对端的地址——MM1 填 MM2 的MM2 填 MM1 的两台填反了会连不上。ipsec后面的密钥两台必须一致。VRRP 优先级通常不用手动指定协议会根据设备状态选举但你要是想强制某台当主可以确认它对 VIP 的优先级更高。我一般依赖默认选举即可。3.3 IPSec 预共享密钥与数据库同步peer-ip-address里那段ipsec Abc12345xy是主备之间建立加密通道的预共享密钥PSK。为什么冗余链路要加密因为数据库同步会把你的全局配置、策略、密钥信息都传过去明文传输等于把配置对全网广播安全性上说不过去。两台设备的 PSK 必须一字不差。我踩过的坑一次现场两台设备密钥一个是大小写混写、一个全是小写看着差不多实际完全不同结果 VRRP 能起、数据库死活不同步排查了大半天才发现是密钥不一致。建议密钥用一个固定规则生成配完两台对着抄一遍。配好 master-redundancy 之后数据库同步通常是自动进行的。主机上的配置会按节奏同步到备机。如果你想手动触发一次同步在配置模式下执行同步命令(MM1) [mynode] (config) #database synchronize同步完成后备机上应该能看到和主机一致的配置。这里提醒一句同步是单向的是按当前 Active 设备推送给 Standby 设备的方向走的所以千万别在备机上改配置然后指望它同步到主机那是反向的改不进去还可能被覆盖。4. 验证怎么确认主备真的活了配置敲完不代表冗余就成了。切换这种事平时看着一切正常真到关键时刻掉链子的情况太多了。所以配置完必须做完整的验证我一般分三层查状态、验同步、做实测。4.1 几个必看的查询命令先看 VRRP 是否正常建立。在两台上分别执行 VRRP 状态查询确认一台是 Master 状态、一台是 Backup 状态且 VIP 出现在主设备上(MM1) [mynode] #show vrrp输出里重点看三样VRRP 状态Master/Backup、虚拟 IP 是否正确、优先级和抢占设置是否符合预期。如果两台都显示 Backup或者都显示 Master那就是典型的双主或双备故障冗余不但没生效还可能引发地址冲突。再看主备冗余自身的状态(MM1) [mynode] #show master-redundancy这条命令能看到当前节点在主备关系里的角色、对端地址、同步状态等关键信息。正常情况下一台显示 Active、一台显示 Standby同步状态为已完成。如果对端显示不可达回头查 IPSec 密钥和 peer-ip-address。还可以查看受管节点的连接情况确认它们连的是 VIP 而不是某台设备的物理 IP(MM1) [mynode] #show switches列表里受管节点的状态应该是 Up并且连接地址指向 VIP。如果有节点连的是物理 IP说明它的配置指向错了切换时它不会跟着走。4.2 数据库同步的状态怎么看数据库同步是冗余的命脉。同步没做好的话备机接手后拿到的是旧配置会出现策略错乱、AP 无法上线等一堆问题。查看同步状态我一般关注两个方面一是同步是否完成、有没有报错二是同步的内容范围是否覆盖了你关心的模块比如 AP 数据库、策略、License 相关配置。如果主机上刚做了大改动建议手动触发一次同步再验证别依赖应该同步了吧这种心态。同步异常时最常见的三个原因网络不通心跳 VLAN 配错、IPSec 密钥不一致、或者同步过程中链路抖动导致中断。逐个排除即可。4.3 真刀真枪做一次切换测试状态都对还不够。必须做真实的切换测试而且要选在业务低峰期提前通知相关方。测试方法有两种一种是软切换在主机上执行指令让它主动让出主角色观察备机是否接管另一种是硬切换直接拔掉主机的上行链路或者断电模拟最恶劣的故障场景。我建议两种都做一遍软切换验证配置正确性硬切换验证真实故障下的切换速度。观察重点VIP 是否顺利漂移到备机用连续 ping VIP 看丢包持续时间受管节点和 AP 是否自动重新连上备机登录备机看 AP 上线数量切换后配置是否和主机一致重点核对策略、AP 数据库业务是否恢复让终端实际连一次 Wi-Fi 验证。切换测试做完记得切回原状态并把测试过程和结果记录下来写进运维文档。这一份记录下次出问题的时候就是救命的参考。5. 切换失败的排查链路从 VRRP 到 DB 同步前面讲的是顺风顺水的情况。但实际项目里我遇到过太多次配置看着都对、切换就是不行的诡异场景。下面把典型的排查链路完整还原一遍你照着这条路走基本能定位到问题。5.1 VRRP 起不来的三类原因VRRP 起不来症状通常是两台都进不了正常的 Master/Backup 关系或者干脆没有 VRRP 状态。排查顺序我是这么走的第一步确认二层可达。VRRP 依赖二层广播如果心跳 VLAN 没有真正打通到对端比如中间交换机没放行这个 VLAN、或者 VLAN 划错VRRP 报文根本到不了对端。查的方法很直接看接口状态、看 MAC 表、看是否能在同 VLAN 内互相 ping 通物理 IP。第二步确认 VLAN 配置一致。两台设备上的master-vrrp引用的 VLAN ID 必须指向同一个二层域。有时候两台设备 VLAN ID 一样但对接的物理口划到了不同 VLAN看着都是 VLAN 30实际不在一个广播域这就是典型的隐形坑。第三步确认 VIP 没冲突。VIP 如果和网络里已有的地址撞了VRRP 会异常。养成习惯规划 VIP 前先在整个二层域里 ping 一下确认没人用。我把这三类原因整理成表现场排查可以逐行对照现象可能原因排查动作两台都 Backup收不到对端 VRRP 报文查二层连通性、VLAN 放行两台都 Master心跳双向中断查直连链路、防火墙拦截VRRP 不启动VLAN ID 或接口配置错核对 master-vrrp 与接口VIP 异常VIP 地址冲突全二层域 ping 探测5.2 DB 同步卡住的排查思路VRRP 正常、状态也对但数据库同步卡住或者报错这种问题更隐蔽。我的排查思路是这样的先看IPSec 通道。主备之间的数据库同步数据是走 IPSec 加密通道的如果 IPSec 建立失败同步自然做不了。IPSec 失败的第一嫌疑是预共享密钥不一致前面提过一定要逐字符核对。第二嫌疑是对端 IP 填错尤其注意两台设备互相填的应该是对方的地址。再看时间同步。这点很容易被忽略——IPSec 和日志都依赖设备时间如果两台设备的时间差得离谱IPSec 的密钥协商可能直接失败同步也随之失败。所以配置冗余前先给两台设备配上可靠的 NTP 源把时间对齐。最后看同步内容本身。有时候同步命令发出去了但某些配置模块因为特殊原因比如版本差异、许可缺失无法同步。这种情况下同步状态会卡在某个阶段。此时可以手动再触发一次同步配合日志观察卡在哪一步。5.3 切换后 AP 掉线怎么定位最让人头疼的场景切换成功了VIP 也漂移了但 AP 大面积掉线或者只上来一半。这种情况我遇到的根因通常有两个方向。第一个方向是AP 的控制器指向问题。如果 AP 是通过 DHCP Option 或者 DNS 发现控制器而它们指向的是主机的物理 IP 而不是 VIP那切换后 AP 还是去找已经挂掉的物理 IP自然上不了线。修法是把 AP 发现机制统一指向 VIP。第二个方向是备机的容量或许可问题。切换后所有 AP 涌向备机如果备机 AP 许可不够、或者处理能力不足就会出现一部分 AP 上线、一部分反复重连的现象。这种问题在测试阶段用全量 AP 压测就能提前发现别等真实故障才暴露。定位时我会先登录备机看show switches里 AP 的实际在线数和主机切换前的数量对比差额就是掉线的那部分再结合 AP 的调试日志看它到底卡在发现阶段还是认证阶段。6. 文档里不会写的几个细节命令和排查链路讲完了最后分享几个我这些年做 Aruba 主备冗余攒下来的、文档里基本不会提但特别影响体验的细节。6.1 心跳链路一定要独立前面强调过一次这里再敲一遍心跳和数据库同步走的那条链路尽量物理独立或者至少 VLAN 独立。有些项目为了省事让心跳和业务共用一个上行口平时看着没事业务一忙就出问题。我见过一次园区高峰期同一个口既要转发客户端流量、又要跑同步数据结果同步超时备机配置落后了几分钟正好那几分钟主机挂了切过去发现配置是旧的策略对不上客户投诉了半天。这种坑靠规划就能避免。6.2 时间同步是最不起眼的地基NTP 这种东西配的时候觉得无关紧要出问题的时候才知道是它在作妖。IPSec、日志时间戳、故障时间线对齐全都依赖设备时间一致。我现在的习惯是任何涉及两台以上设备协同的项目第一步就把 NTP 配好确认两台时间差在秒级以内再动其他配置。这个习惯帮我省过不少排查时间。6.3 升级维护的操作顺序做冗余的另一个价值是让升级维护不中断业务。操作顺序上有个讲究先升备机再切主备最后升原主机。具体说就是先把备机升级并重启等它回来、和主机重新建立同步然后主动做一次切换让升级好的备机变成 Active确认业务正常后再把原来的主机升上去。整个过程业务基本无感。反过来如果先升主机主机一重启业务就断了冗余的意义也就没了。还有一点升级前一定要确认两台 target 版本一致以及备机的配置同步是最新的。我见过升级时备机配置落后升级完切过去发现缺了一部分策略又得回切处理白白折腾。6.4 别把主备关系当配完就不管最后说个心态问题。主备冗余不是配置完就一劳永逸的配置会漂移、密钥会过期、链路会老化。我建议把这几件事纳入日常巡检每月查一次主备状态和同步状态每季度做一次切换演练每次重大配置变更后手动触发一次同步并确认备机已跟上。这套习惯坚持下来真出故障那天你会感谢自己。把这些都做到位Aruba 70xx 在 8.x 下的 Master Redundancy 才算真正落地——不是配置单上打了个勾而是半夜机房报警时你能安心接着睡。