去年冬天帮一家制造企业做无线改造，核心是一台 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，两台之间跑 VRRP，master 挂了 standby 顶上，这就是 6.x 的 Master Redundancy。
到了 8.x，架构被彻底重构，控制平面被单独拆出来，形成了Mobility Master（MM）+ 受管节点（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，对外暴露一个虚拟 IP（VIP）。所有受管节点、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 | 说明 |
|---|---|---|---|
| 主机（Active） | MM1 | 172.16.30.1 | VRRP 优先级高 |
| 备机（Standby） | MM2 | 172.16.30.2 | VRRP 优先级低 |
| 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 配成 VIP，VIP 是由 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.100：VRRP 虚拟 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 才算真正落地——不是配置单上打了个勾，而是半夜机房报警时，你能安心接着睡。
