已阅读
企业免备案CDN加速应该如何上云？
而数据随着处理能力的需求和网络带宽的需求，网络中心开始出现，企业自己建设DWDM的城域网实现同城灾备的也很多，但是随着两地三中心的监管要求，很多大型企业选择了在大型运营商构建的专业托管机房部署自己的数据中心，毕竟有足够的异地互联资源。
2.2 早期的企业上云
2.3 VPC（虚拟私有云）的出现
随着业务的发展，流量越来越大，单体软件架构面临一系列挑战，在那个年代通常有几种办法来解决：
1. 负载均衡：各个云厂商开始提供基于LVS的负载均衡服务，F5等商业软件也被用户采购
2.CDN：如何按照地域提供应用加速服务也成为了一个难以解决的问题，大量的厂商在一段时期疯狂使用免备案CDN，但后期又发现CDN内容被劫持安全性出现问题，多个免备案CDN网络相互干扰，资源更新冲突等问题，应用隐私也无法保护。
基于多地域AZ的分布式VPC和分布式软件架构逐渐成为解决这类问题的一个办法，问题又来了，如果VPC多了，那么VPC-Peering的数量按照O(N^2)增长，运维复杂度成倍的增加.
为了解决这个问题，云计算厂商又提出了Transit VPC的架构，由思科CSR1000v提供的DMv**作为Region Hub来提供VPC互联的解决方案。
也就是以后云计算厂商提出的Transit VPC架构，即构成一个中心化的Transit区域
同一时期，应用软件层面也逐渐的伴随着Docker/K8S等技术的兴起，从单体软件架构向分布式迁移，直到后期逐渐构成以Istio为代表的ServiceMesh架构，伴生的便是完全去中心化的软件架构。
与此同时单个网络运营商的故障带来的巨大损失也被暴露出来。鸡蛋不能放在一个篮子里，那么MultiCloud也就顺理成章的出现了。但是我们注意到传统的DMv**架构还是有明显的Hub-Spoke区分， 应用软件都去中心化了，VPC互联互通又该如何去中心化的实现呢？
MultiCloud的出现使得广域网互联出现明显的去中心化特征，传统的TransitVPC可能成为单点故障，同时伴随着DevOps，企业在云端VPC的扩张速度越来越快，传统的广域网技术已经无法跟上应用的需求了。
在这种背景下，软件定义的风潮开始席卷广域网设备，伴随着DPDK和VPP的出现，基于通用X86 CPU的软件转发能力迅速提高使得NFV这些虚拟化网络设备快速的进入到整个市场。但是技术上如何实现呢？
正如前文介绍思科的DMv**和华为的DSv**一样，本文不涉及厂商，只是透过各个厂家的包装让您看到mGRE+IPSec+NHRP+BGP/OSPF的本质，但是很遗憾的是并未看到华为或者其它SDWAN厂商开放的有价值的技术资料，所以这里以思科的SD-WAN解决方案为示例，但还是仅讨论技术。
思科将SDWAN控制器拆分成三类组件便是出于分布式软件架构和多云部署的考虑，它将业务逻辑分为了编排vBond， 管理vManage，控制vSmart，转发Edge四个不同的功能组件，任何一个组件都能在多云环境下部署并构成集群，如下图所示：
这样极大的提高了在多云环境下的稳定性，任何一个云出现故障都不会导致SDWAN控制器下线。
无论一个NFV后面接的是什么设备或者什么地址，SDWAN第一件事便是考虑到网络安全合规要求，隔离互联网和私有网络。通常我们把一个设备连接互联网的接口称为传输端口（Transport Interface）而连接VPC或者私有网络/数据中心的接口称为业务端口（Service Interface），如下图所示：
同时默认在非安全区域添加了默认安全策略组，仅有授权通过的白名单v**流量和控制器流量可以通过。在转发平面上，通常我们会为他们放置不同的路由虚拟转发表（VRF)将它们完全隔离开。
不同的VPC或者客户的分支站点甚至是数据中心，后面接的网络服务器容器或者是终端，我们都可以抽像为资源，或者就是不同的IP地址段来表示，并且可以通过不同的属性将它们进行v**隔离，也就是我们常说的Overlay层，而Internet区域也被称为Underlay。那么Underlay和Overlay层是如何映射的呢？当然所有的人都会说MP-BGP协议进行TLV扩展来支持键值对（Key-Value Pair）。
直接使用MP-BGP或者BGP-Ev**的问题：
1. Underlay公网地址经常变动，BGP路由协议收敛慢
2. 通常VPC需要跨越NAT，标准的BGP协议NextHop为VPC私网地址，无法穿越NAT
3. 优选路径类型无法在单独的下一跳信息中获得，通常还需要Community熟悉扩展
4. 互联通信还需要NHRP一类的协议进行补充
这些都是思科在尝试使用DMv**技术构建IWAN解决方案时犯的错误，而且正如前文所述新一代的SDWAN需要去中心化的分布式架构，而DMv**或者DSv**的解决方案有明显的中心Hub结构，极易造成单点故障或者规模无法扩展的问题。
思科新一代基于Viptela的SDWAN架构采用递归路径查询的方式，它结合和BGP和LISP的各自优点，将Overlay所对应的VPC网段等资源信息映射到一个被称作为TLOC的资源定位符上，如下图所示，然后再递归查询通过解析TLOC可达性等信息来进行路径选择和策略路由。
具体的TLOC编码如下图所示，我们对每一个VPC站点进行了编码（Site-ID），同时为每一个路由器也编制了System-IP，然后根据它们接入的不同运营商和不同的链路类型，我们为传输接口（Transport Interface）染上了不同的颜色（Color），例如Azure被标记为了Private2（紫色），数据中心的电信链路标记为蓝色（Blue），而联通的线路则标记为红色（Red）。封装形式（Encapsulation）则可以选择明文的GRE传输或者IPsec传输方式。
我们根据这些TLOC编码信息就可以产生v**路由了，即将VPC的网段和资源信息和TLOC绑定了，如下图所示，v**1：Prefix-D1的资源的路由下一跳属性被标记为TLOC <2.2.2.2, INET,IPsec>及<2.2.2.2,MPLS,IPsec>，即v**1：Prefix-D1可以同时通过vEdge-D（system-ip=2.2.2.2）的这台路由器的INET网络和MPLS到达，但是约定必须使用IPsec加密封装的方式传达。
v**路由通过OMP协议更新发送到控制平面vSmart上，并由vSmart集群分发到其它路由器，它的作用和BGP UPDATE消息以及BGP RR路由反射器功能类似。
经过控制器vSmart集群的反射，vEdge-S（1.1.1.1）已经知道v**1：Prefix-D1的资源可以通过2.2.2.2的这台路由器到达了，但是还缺少一些信息，广域网Underlay的地址是什么？加密需要的密钥是什么？这里就需要递归查询的第二步了，如何将TLOC和Underlay的信息关联，很简单，再发一个BGP UPDATE消息让vSmart反射就好了，如下图所示
在TLOC Route信息中包含了IPsec的SPI/Auth/Encryption密钥等信息，同时还有NAT穿越的信息， 因为很多场景中，VPC给路由器分配的是私网地址，NAT地址翻译是云服务提供商做的，所以需要通过某种方式获得自己公网地址，这个时候vEdge会通过向vBond编排器集群查询的方式，让vBond编排器将其公网地址信息反馈回vEdge实现。
在获取了TLOC的Underlay信息后，vEdge-S便对会话进行BFD检验，同时测量延迟抖动和丢包等链路质量特征，它会根据自身的情况，进行TLOC可达性测量，并构造出一张TLOC 路由信息表，如下图所示：
最后，Overlay的v**1：Prefix-D1的路径查询第一步查询TLOC，第二步再查询TLOC路由表，选择可达的或者SLA满足的路径查询到Underlay的封装和传输参数，然后将报文发出。这样的递归查询带来了极大的灵活性，例如我们可以根据不同的v**定义不同的Overlay拓扑结构和选路规则：
随着业务的发展，SaaS类服务越来越多，例如Office 365， Salesforce，Webex等应用的出现。传统的v**架构是采用集中式互联网接入技术带来了极大的性能瓶颈，而分支机构直接上云（Direct Internet Access）或者(Direct-Cloud Access)显得非常重要。
这样就需要对流量有DPI应用识别的能力，并且能够对相应的IP地址和端口进行缓存，因为很多TCP的流量需要第一个包就要重定向到需要的连接上。
而策略定义上，就是定制一个app-list，匹配Google/Dropbox/Office365等应用，某些时候可以将其设置为从一些靠近云端的VPC路由器出去，某些时候也可以将其设置为直接本地通过Internet NAT出去，这也是为什么思科在路由协议上使用递归查询的原因。
我们选择了杭州的AZ部署控制器，由于只是一个演示环境，随便装了五个虚机，一个vManage，一个vSmart，一个vBond作为控制器， 一个Cedge作为SDWAN路由器，还有一个服务器用来签发CA证书和传输证书用。
为了测试一下长距离不同云VPC互通，我们选择了在腾讯云重庆AZ上部署SDWAN路由器，仅部署了一台：
Edge设备上线非常容易，仅需要配置System-IP，Site-ID，Orgnization-Name，vBond的DNS域名或者IP地址，然后接口上配置IPsec封装和Color就好，而相对于传统的IPsec v**需要配置大量的IKEv1/IKEv2,证书密钥等信息，采用SDWAN新建VPC仅需要几分钟的时间，然后VPC内部的网络通过OMP协议自动通告和远端互通：
就此我们轻松的完成了一个VPC新站点的创建，并不需要Fullmesh配置VPC Peering或者构建复杂的Transit VPC。
注：思科官方支持阿里云将会在明年三月，现阶段在阿里云上可以使用G5NE主机采用部署qcow2镜像的方式做一些实验，腾讯云没有官方支持，但也可以通过自带qcow2镜像去玩玩：）
当你需要管理一个多云的环境时，可视化运维便成了非常关键的一步了，最简单的就是链路质量检测，丢包率延迟抖动这些。
然后运维规则里，肯定就有要根据SLA做动态路径选择了，比如某种应用声明式运维，我需要它满足延迟和丢包率在某个阈值一下，例如下图：
还有便是集中的告警日志平台：
通常配置大量的设备还需要模板吧，而且北向接口做配置变更也需要容易回退吧，这套方案选择了NSO使用netconf+Yang model的方式，这些细节做的非常不错
同时还有很多开源的运维工具
另一方面还有一些安全相关的增值服务，抽空一起玩玩
说了这么多，其实只是想从协议实现上和运维上来给大家解释SDWAN应该如何设计，vSmart的那些OMP路由，如果是非网络设备厂商，完全可以借助K8S使用更新ETCD来实现K-V的分布式存储和策略的分布式存储，vBond用一些Public DNS的方式也可以做一些事情，控制平面上Viptela这个方案跟K8S有很多类似之处，比如一个Edge路由器可以算作一个Pod，但是它没法根据实际的网络Scale动态的新增或者减少Pod，或者动态的调整广域网带宽，这些都是可以在后期多云环境里逐渐加强的，另外就是基于AI的运维，这一方面也需要加强。大概就这么多了吧，也希望大家选择SDWAN的时候从最本源的东西和根本的需求着手，不要被一些花哨的功能而忘记了初心。
