SD-WAN 的核心组成：边缘设备、控制器与编排平台分别做什么？
企业采购 SD-WAN 时，常常会听到一串名词：Edge、Controller、Orchestrator、Gateway、Overlay、Underlay。名称很多，但客户真正需要搞清楚的是：哪一部分负责转发业务，哪一部分负责计算和下发策略，哪一部分负责配置、监控与审计，以及某个组件故障时业务会受到什么影响。
如果这些边界不清楚，项目很容易出现两种误判：一是把“管理平台在线”当成“业务一定正常”；二是把“设备能够转发”当成“智能选路和统一运维已经生效”。
本文从客户实施和故障排查的角度，说明 SD-WAN 边缘设备、控制器、编排平台以及网关分别承担什么职责。
先给结论：用数据面、控制面和管理面理解最清楚
| 层面 | 主要组件 | 核心职责 | 故障时的典型表现 |
|---|---|---|---|
| 数据面 | SD-WAN Edge、Gateway | 接收并转发业务流量，建立和维护数据隧道，执行本地策略 | 站点业务不通、隧道中断、选路异常或性能下降 |
| 控制面 | Controller 或集成式控制组件 | 维护节点和拓扑信息，分发路由与策略，协调安全控制关系 | 新拓扑或新策略无法收敛，节点注册或控制连接异常 |
| 管理面 | Orchestrator / 管理平台 | 配置模板、零接触部署、监控、告警、审计和运维入口 | 无法登录、不能变更或查看监控，但现有数据转发未必立即中断 |
不同厂商可能把 Controller 和 Orchestrator 合并在同一个产品界面或同一组服务中，也可能拆分部署。因此，选型时不要只问产品名称，要问实际功能、部署位置、冗余方式和故障影响。
一、SD-WAN Edge：真正承载客户业务的边缘设备
SD-WAN Edge 通常部署在分支、总部、数据中心或云环境中，可以是物理设备，也可以是虚拟实例。它是用户网络与 WAN 承载之间的业务入口。
常见职责包括：
- 接入局域网、互联网、专线、LTE/5G 等网络。
- 建立并维护 Overlay 加密隧道。
- 识别或分类应用流量。
- 持续检测可用路径的质量。
- 根据已下发的策略执行路径选择和故障切换。
- 执行基础路由、NAT、QoS、访问策略等本地功能。
- 向管理平台上报链路、隧道、应用和系统状态。
客户采购 Edge 时，不能只看吞吐量
标称吞吐量往往是在特定报文大小、功能组合和测试条件下得到的。实际项目还应确认：
- 启用加密隧道、应用识别、QoS 后的可用吞吐。
- 支持的 WAN/LAN 接口数量和类型。
- 并发会话、隧道数量和可管理站点规模。
- 是否支持需要的动态路由、静态路由和网络分段。
- 多条线路的 NAT、地址和运营商环境是否兼容。
- 设备异常时是否支持旁路、双机或快速替换。
- 本地日志和离线转发能力，控制平台不可达时能否继续执行已有策略。
对于中小企业，真正重要的是“启用实际功能后的容量”和“发生故障时怎么替换”，而不是规格表上最大的实验室数字。
二、Controller：维护网络关系并分发控制信息
Controller 可以理解为 SD-WAN 的控制协调层。它通常负责节点身份、拓扑、路由、策略分发或控制连接等工作，让各个 Edge 知道有哪些远端节点、可以建立哪些路径、应该执行哪些网络规则。
控制器并不一定位于所有业务流量的转发路径上。很多架构中，业务数据在 Edge 之间或 Edge 与 Gateway 之间直接传输，而 Controller 负责控制信息。
控制器故障后，业务会不会立刻中断？
答案取决于具体产品架构，但通常需要区分：
- 已有业务：Edge 如果保留现有路由、隧道和策略，可能继续转发一段时间。
- 新节点上线：可能无法注册、认证或获取配置。
- 拓扑变化：新的路由和策略可能无法及时收敛。
- 长期故障：证书、控制会话、隧道维护和策略一致性可能逐步受到影响。
因此，供应商不能只说“控制器高可用”，还应说明高可用节点数量、跨机房方式、状态同步、故障切换和恢复验证结果。
三、Orchestrator：配置、监控和运维的统一入口
Orchestrator 通常提供 Web 管理或 API 能力，是管理员直接使用最多的组件。它可能包含或调用控制器功能，也可能作为独立管理面存在。
常见能力包括：
- 站点和设备生命周期管理。
- 零接触部署或激活流程。
- 设备模板、业务策略和批量变更。
- 链路质量、应用流量和隧道状态监控。
- 告警、日志、审计、配置版本和回滚。
- 角色权限、租户隔离和 API 集成。
管理平台打不开，为什么业务可能仍然正常？
因为管理面故障和数据面故障不是一回事。如果 Edge 已经获得策略并保持现有隧道，管理平台临时不可用时，业务仍可能继续转发。
但这不代表问题可以忽略。管理面不可用会影响：
- 新设备上线和故障替换。
- 策略变更、配置回滚和紧急操作。
- 实时监控、告警和故障取证。
- 账号权限、审计和 API 自动化。
验收时应分别测试“管理面中断”和“数据面中断”，确认两者的故障边界。
四、Gateway：不是所有架构都有，但经常很关键
Gateway 通常用于连接 SD-WAN Overlay 与某个非 SD-WAN 网络或外部服务，例如公有云、SaaS、互联网出口、运营商骨干或没有部署 Edge 的站点。
常见用途包括：
- 让 Edge 接入云或服务商网络。
- 缩短到应用或服务入口的路径。
- 作为区域汇聚和中转节点。
- 连接传统网络、数据中心或第三方服务。
需要注意：Gateway 如果承担业务转发，就属于关键数据面。它的带宽、会话、区域位置、冗余和运营责任，都会影响客户业务。不能只确认“有网关”，还要确认流量是否经过、由谁维护、出现故障怎么绕行。
五、Underlay 与 Overlay：底层线路和上层业务网络
Underlay 是承载 SD-WAN 数据的底层网络，例如互联网专线、企业宽带、MPLS、4G/5G。Overlay 是在这些承载之上建立的逻辑网络和隧道。
| 项目 | Underlay | Overlay |
|---|---|---|
| 由谁提供 | 运营商或企业基础网络 | SD-WAN 平台和 Edge |
| 主要作用 | 提供基础 IP 可达和物理传输 | 形成逻辑拓扑、加密隧道和业务策略 |
| 常见问题 | 丢包、拥塞、NAT、路由绕行、信号差 | 隧道、策略、路由、身份和控制连接异常 |
| 排查方法 | 检查接口、网关、运营商路径和实际质量 | 检查隧道状态、策略命中、路由和控制关系 |
SD-WAN 可以选择和保护路径，但 Overlay 无法摆脱 Underlay 的物理约束。底层所有链路都严重拥塞时，上层没有“好路径”可选。
设备在线但业务不通，应该按哪一层排查？
- 局域网和终端：终端地址、网关、DNS、VLAN、交换机和 Wi-Fi 是否正常。
- Edge 本地状态：接口、路由、NAT、CPU、内存、会话和业务分类是否正常。
- Underlay：运营商网关、互联网可达、丢包、延迟、MTU 和 NAT 条件。
- Overlay：隧道、对端、加密、安全参数和路径状态。
- 控制面：节点是否注册、路由和策略是否正确分发。
- 管理面：平台显示是否与设备实际状态一致，变更是否成功下发。
- 远端服务：总部、防火墙、云资源、应用服务器和第三方 SaaS 是否可用。
采购和验收时必须问的 12 个问题
- Edge 是物理设备还是虚拟实例？启用实际功能后的性能是多少？
- 控制器与编排平台是合并还是拆分？各自部署在哪里？
- 控制面或管理面不可达时，Edge 能否继续转发现有业务？
- 平台和控制组件如何做高可用？是否跨机房或跨区域？
- Gateway 是否在客户业务路径上？容量和冗余如何设计？
- 支持哪些 Underlay：互联网、MPLS、4G/5G、私网或其他承载？
- 应用识别、路径检测和策略下发分别由谁完成？
- 新站点如何激活？设备替换和配置恢复需要多久？
- 是否能看到链路、隧道、应用和策略命中的历史记录？
- 是否支持角色权限、操作审计、配置备份和回滚？
- API 能访问哪些能力？能否与现有监控或工单系统集成？
- 平台、Edge 和 Gateway 的授权、续费和运维责任分别由谁承担？
建议的故障演练
- 断开一个 Edge 的主 WAN，验证业务路径和告警。
- 让管理平台暂时不可达，观察现有业务是否继续运行。
- 模拟控制连接异常，检查新策略和新路由是否还能分发。
- 停止一个 Gateway 或改变到 Gateway 的路径，验证业务绕行。
- 恢复组件后检查状态同步、策略一致性和回切行为。
- 由运维人员仅依据平台和日志完成一次分层定位，评估取证能力。
结论：不要买一组名词，要买清晰的责任边界
理解 SD-WAN 架构的关键，不是背下 Edge、Controller、Orchestrator 和 Gateway 的定义，而是明确：
- 谁转发客户业务。
- 谁维护拓扑、路由和策略。
- 谁负责配置、监控和审计。
- 某个组件故障后，哪些已有业务、新业务和运维操作会受影响。
对中小企业尤其如此。一个合适的 SD-WAN 方案，应在保持架构清晰的同时，减少不必要的组件和授权负担，并把设备替换、平台故障、线路劣化和业务恢复全部纳入验收。
只有当各层职责和故障边界可以被解释、测试和记录，SD-WAN 才不只是“控制台里的一片绿色”，而是一套可运营的企业网络。