💮7x03 SD-WAN 漫步云网端·多样的SD-WAN by VeloCloud拓扑

今天我们继续来聊一聊VMware SD-WAN by VeloCloud产品。在VMware NSX家族众多产品中，VeloCloud是进入Gartner WAN Edge Infrastructure领导者象限的产品。

伴随着企业数字化转型的潮流，不少企业(尤其是金融行业)都将目光投向SD-WAN解决方案，用于实现包括多站点互联、带宽优化、自动化分支机构部署等功能。从晓冬近半年接触的客户和参与的项目来看，针对SD-WAN产品的交流、PoC、成功案例数量也比往年有所增加。

在今天分享的前半部分，我们先抛开演示用例的框架，一起由浅入深地来聊一聊企业使用VeloCloud实现SD-WAN几种典型的拓扑和场景。借此机会，特别感谢来自VMware的好友李廷，在我学习时间VeloCloud过程中给予的细致讲解和热心帮助。

01x01.一个数据中心+两个(多个)分支机构

这是最简单的一种场景，用于SD-WAN管理的编排器和云网关一般会部署在数据中心，利用ESXi自身的高可用性、分布式资源调度等实现SD-WAN管理和控制平面的健康稳定运行。

对于数据中心A而言，他是SD-WAN网络中最核心的节点，部署在该数据中心的Edge设备将作为“Hub角色”，用于接收分支站点“Spoke角色”Edge设备主动发起的隧道建立请求；也用于多个“Spoke角色”之间的互通，相当于一台“云网络网关”。为了便于理解和表述，后续晓冬会用“分支站点a”代指“部署在分支站点a的两台Edge设备(HA)”

如下图所示：管理员可以设置“Spoke角色”的Edge主动连接向指定的“Hub角色”发起隧道建立请求。

对于分支站点a和分支站点b来说，它们将分别与数据中心A主动发起隧道建立请求。当隧道正常建立之后，数据中心A自然知道分支站点a和分支站点b的WAN口信息以及通过OSPF、BGP学习到的路由信息。此时，如果分支站点a尝试与分支站点b通信，那么有两种可行的路径：

第一种路径，分支站点a的流量在经过Edge的封装后，(一般)通过Internet发送到数据中心A，由于数据中心A有分支站点b的路由条目，会将该流量发往分支站点b，分支站点b在解封装后继续往下转发；总体而言流量路径是a-A-b。在这种路径下，最大的优点莫过于数据中心A可以非常容易地对所有SD-WAN流量进行审计，可以满足一些企业(尤其是金融行业)的合规性要求。

当然，这种路径下对于数据中心A的带宽会有比较高的要求，因为所有的流量均需要经过数据中心A的Edge设备。有些企业出于带宽利用率最大化、效率最高的考量，在没有合规性的约束下，更希望分支站点a和分支站点b能够实现点对点的通信。这就是第二种路径，由于数据中心A有分支站点a和分支站点b的WAN信息，在分支站点a和分支站点b之间试图通信的时候，两个分支站点间会建立动态的B2B隧道。流量将不再经过数据中心A，而是直接a-b或者b-a这样的路径。

实现的方式只需要在配置文件中勾选允许建立B2B(Brunch to Brunch)隧道即可，如下图所示：

01x02.两个(多个)数据中心与两个(多个)分支站点

这是相对复杂的一种场景，但也是晓冬在项目中最常遇到的场景。同样地，用于SD-WAN管理的编排器和云网关一般会部署在数据中心，利用ESXi自身的高可用性、分布式资源调度等实现SD-WAN管理和控制平面的健康稳定运行；只不过它们可以集中部署在同一个数据中心，也可以将VCG分别部署在不同的数据中心。可见SD-WAN管理与控制平面组件的部署模式和容灾方案是非常灵活的，能满足用户的各种要求。

这种场景模式下的第一个问题，就是分支站点a和分支站点b应该向那个数据中心站点的“Hub角色”主动发起隧道建立请求呢？在实际项目中，分支站点a和分支站点b均会分别向数据中心A和数据中心B建立静态隧道，不存在“选择”的问题。

另一个问题是，在这种场景模式下，四个站点之间的数据流走向又该如何呢？假设管理员定义分支站点a与数据中心A之间的隧道优先级高于与数据中心B之间的隧道(分支站点b与之相对应)，同时出于合规审计的需求，不允许分支站点a与分支站点b之间建立动态B2B隧道。

可以看到，分支站点之间的通信不会同时经过两个数据中心。这是因为数据中心A与分支站点a和分支站点b均有静态隧道。当数据中心A接收到分支站点a发往分支站点b的数据包后，会直接通过与分支站点b的隧道进行数据转发，并不会经由数据中心B再发往分支站点b。当然，如果管理员允许建立B2B隧道，那么分支站点a与分支站点b之间可通过动态隧道的建立，直接进行点对点的SD-WAN流量互通。对于分支站点a而言，如果要和数据中心B通信，会直接通过之间的静态隧道进行SD-WAN通信。

02x01.灵活的转发策略

在了解完VeloCloud最基本的两种部署场景后，我们再来看看VeloCloud如何“基于策略进行流量转发的”。

如上图所示，用户分支站点(Spoke节点)有两条不同运营商Internet线路，不妨就以电信线路、联通线路举例。在实现SD-WAN后，用户出于安全合规的考量，保留原先的SSL-VPN或者专线，一些特殊的流量依旧通过该线路进行转发，VeloCloud不对这类流量进行封装；一般情况下，管理员会将两条运营商的线路逻辑上捆绑成一条，VeloCloud会根据线路质量(如延迟、利用率等)优先选择合适的线路进行SD-WAN流量的封装与转发，同时提供强大的高可用性和稳定性；当然，管理员同样可以根据需要，定义特定的流量(如语音视频)通过特定的线路进行封装转发。由于VeloCloud灵活的转发策略，完全可以道一句流行的广告词“总有一款方案适合你”。

对于新建分支站点(这是最常见的需求)来说，由于暂无业务运行，构建SD-WAN节点并不会涉及业务中断等场景。但若是针对现网进行改造，如【采用SD-WAN来实现“去专线”“去VPN”等需求】，如何物理部署Edge设备就是管理员“不可不察也”的问题。

03x01.网关模式

最简单易行的物理部署方式就是“网关模式”。通俗来讲，无论是Internet流量、还是SD-WAN流量均会经过Edge设备；当流量经过Edge设备，Edge会识别流量类型，仅对WAN流量进行封装转发，实现网络互通；实际上此时的Edge设备承担着“路由转发”“协议封装”“选路优化”等功能。这种模式下，难免会出现诸如“替换当前广域网设备”等情况，需要有一段时间的网络割接和停机维护时间。但这种物理部署模式拓扑清晰，非常便于管理员运维与排障，因此许多用户更倾向于选择这种物理部署模式。同时，在一些门店环境，Edge设备也可同时作为无线AP使用。总体而言，VeloCloud是整个虚拟云网络拓扑中非常关键的一环。

03x02.旁路模式

另外的一种物理部署模式叫做“旁路模式”。管理员可在不改变现有网络拓扑的情况下，实现SD-WAN需求。比如管理员明确“要保留现有广域网设备”，此时用户就更适合采用“旁路模式”物理部署Edge设备。在这种模式下，上文所提的“路由转发”“选路优化”“协议封装”等功能中，前两个功能均由其他设备实现。对于WAN范畴的流量，会被路由到Edge设备执行封装，然后在经由其他设备通过Internet线路实现转发；而其他诸如Internet流量、专线流量等，将不会经过Edge设备。由于对现有网络拓扑变化相对少，因此几乎不会有因为线路割接而引起中断的情况，但排障相对复杂，对IT运维而言有一定的难度。

现在，我们重新来看一下本连载的总体拓扑：

站点数量为2个，HQ(右侧)代表数据中心，Edge为Hub角色，下联HQ站点LAN网络为10.1.10.0/24；

BO(左侧)代表分支站点，Edge为Spoke角色，下联BO站点LAN网络为10.2.11.0/24和10.2.12.0/24；

两个站点的Edge设备均以“路由模式”物理连接。

在上一篇连载中，晓冬已经演示了如何注册VCE设备到VCO，这里就不再赘述Spoke角色的VCE发起注册的步骤了。两者唯一的不同是分支站点的Edge配置文件需要定义向数据中心Hub角色主动发起隧道建立请求而已。

等待分支站点的VCE成功注册后，管理员在VCO平台上可以清楚地看到这些变化。

此时，我们在HQ站点部署的Web虚拟机就可以通过SD-WAN连通BO站点部署的App虚拟机和DB虚拟机。如下图所示：其中10.2.10.1为BO站点的Edge设备WAN口IP，1.0.0.4为HQ站点的Edge公网IP地址(BO站点的Edge设备会向这个IP地址发起隧道建立请求)。

管理员也可在VCO管理界面验证不同站点之间的SD-WAN连接：

如下图所示：在hq-edge-01端测试bo-edge-01连通性，可以看到对端的公网IP为1.0.0.102，本地端的IP为1.0.0.4，SD-WAN连接正常。

10.2.11.0/24和10.2.12.0/24作为BO站点的业务网络，将通过Cloud VPN(SD-WAN)实现路互通。

今天的分享主要是对VeloCloud部署模型的介绍与科普，由于用户的需求存在比较大的个性化差异，本篇内容也只能从最简单的角度来帮助各位在VeloCloud学习和实践过程中理解和归纳。

在实际项目中，为了实现虚拟云网络的互通，还包括Edge静态或者动态路由配置、子网规划、VLAN定义等其他关键设置操作；晓冬将在下一篇分享中对这些具体的配置进行演示说明，敬请关注。