WX3520X+云集群组网问题

不可以，清空配置 组网

官方最佳实践文档明确建议从双链路备份改造云集群时，清空配置再组建集群；但技术上不是强制必须清空，有不停业务、保留业务配置的割接方案，风险点和操作方式下面给您说明H3C。

原理：云集群初始化逻辑是 Leader（主 AC）的配置批量同步给 Follower（备 AC），集群建成后由 Master 统一管控、实时同步；Follower 原有业务配置会被 Leader 下发的配置覆盖，不是两台配置合并，这是最核心的一点H3C。

1、能不能不清空原有配置直接上云集群？

✅ 可以做到 “Leader 保留原有业务配置不清空”，但备 AC（Follower）加入集群后，本机原有配置会被 Leader 同步覆盖，相当于备 AC 的旧配置直接丢失。 ⚠️ 官方写的 “建议清空配置”，本质是规避两类冲突：

1. 双链路备份遗留的wlan ap-backup、AP 备份组、备份隧道、双机相关配置，和云集群热备容器冲突，容易出现 AP 注册异常、客户端表项不同步、倒换异常；
2. 两台 AC 上 IP、VLAN、接口、模板不一致，集群初始化同步时引发冲突、激活集群配置时反复重启、业务闪断。

所以：Leader 那台 AC 可以保留现网业务配置不清空，作为集群主；但备 AC 不能保留自己原来独立的业务配置，加入集群后会被覆盖，不存在 “两台 AC 各自旧配置全部保留、自动合并” 的模式。

2、适合您短窗口、配置多、还要升级的割接方案（现网工程常用，有落地案例）

前提：两台 WX3520X 先升级到同版本 V9（E1404P01 及以上，云集群基线版本），License 规格一致、硬件模块一致，提前规划独立的云集群成员 IP 网段（单独心跳网段，不能和业务网段冲突）H3C

1. 割接前：两台 AC 完整备份current-configuration、AP 注册文件、本地认证文件，导出存档；
2. 选现网稳定主 AC 作为 Leader：保留它全部业务配置不清空，只删除这台 AC 上【双链路备份相关配置】（ap-backup、client-backup、备份隧道、备份组）；
3. 另外一台 AC（原备 AC）：清空或者单独删除 wlan 备份相关配置，只保留基础管理、路由，不要保留业务 wlan 模板；
4. 先配置 Leader 的 cloud-cluster member-id、member-ip，激活集群配置，此时 Leader 单机成集群；
5. 再配置第二台 AC 的 member-id、member-ip、join-cluster 指向 Leader 集群 IP，激活加入集群；
6. 集群协商成功后，Leader 自动把全套业务配置同步到 Follower；同步完成后，再把 AP 的备份模式从双链路备份改成云集群内置热备；
7. 验证：AP 双注册到云集群、客户端快速备份、主备倒换，再清理残留双链路备份命令。

这个就是从双链路备份迁移云集群、Leader 不清空业务配置的工程案例方案，很多项目这么割接，但不属于官方标准推荐流程，属于 “风险可控的改造方式”。

3、备选方案（如果窗口极小、不想碰云集群改造）

如果窗口太短，不想承担集群激活、同步的不确定性：继续使用双链路备份，V9 版本双链路备份本身也支持 AP + 客户端热备份，只是没有云集群统一配置同步能力，需要两台 AC 手工同步配置；等后续维护长窗口再迁云集群。

4、重点风险提醒（一定要提前评估）

1. cloud-cluster configuration active激活命令，大概率会触发设备重启，这个是不可避免的；
2. 集群成员 IP 必须独立网段，路由可达；
3. 两台 AC 版本必须完全一致，版本不一致会加入失败；
4. 本地文件（map-configuration 引用的 AP 脚本、证书文件）不会自动同步，需要手动拷贝到两台 AC 的 flash，否则倒换后失效；
5. 一旦集群同步异常，会出现配置覆盖、无线业务批量掉线，必须提前回滚方案（切回双链路备份）。

5、简单总结

• ❌ 不能做到：两台 AC 都保留各自原有业务配置、直接组建集群，配置不会合并；
• ✅ 可以做到：主 AC（Leader）不清空业务配置，删掉双链路备份配置，另一台 AC 作为 Follower 加入、被主 AC 同步覆盖，属于工程落地可行方案，有现网案例；
• 📌 官方推荐：空配置开局集群，是最稳、故障最少的方案，适合窗口充足场景；