前言

本文将从某运营商的一个云资源池案例浅析使用的网络技术及原因，分享Overlay、SDN、二层DCI技术在云数据中心场景中的实际应用。

关于什么是Overlay，为什么云数据中心需要Overlay，这和云数据中心多业务多租户的业务特性、新型网络构架下需要大二层的特性、网络自动化有比较大的关系，有关的信息和文章有很多，篇幅有限本文就不再赘述。

A省某运营商的资源池作为内部多业务共用的一个基础设施，与大部分云数据中心一样，也需要多租户的特性、自动化的网络、大二层特性，因此也需要Overlay技术来支撑其业务的云化发展。

先简单介绍两种常见的网络Overlay的实现思路：由服务器实现的主机Overlay和由网络交换机设备实现Overlay。

l  主机Overlay

图1.1.▲主机Overlay图示

如上图所示，“主机Overlay”的隧道入口建立在服务器的vSwitch上，实现各服务器之间通过VPN来进行业务数据的传输。由于云计算业务一般都需要实现全网的二层互通，因此会使用VXLAN、NVGRE等L2 VPN协议。图1.2为Openstack社区版本主机Overlay的实现逻辑。

图1.2.▲主机Overlay结构示意

主机Overlay最主要的优点是不需要基础网络设备支持任何高级功能，实现与基础网络设备无关，TOR、Spine交换机作为该网络中的P设备，只需要实现基本的转发即可，表项压力较小。而且它还是天然的软件定义网络，有很好的灵活性。以往被诟病最多的性能问题上，在当下网卡已经支持基本的VXLAN等隧道协议栈offload的情况下已经得到了有效的缓解。

而在裸金属场景下，服务器无法安装虚拟化层，但数据中心又需要将OS与网络策略配置解耦避免安全事件，因此需要使用智能网卡脱离OS层面来提供各种vSwitch提供的隧道封装、安全过滤、QOS的特性，但智能网卡的方案需要上层应用做开发工作，对数据中心管理者提出了较高的开发要求。

l  网络Overlay

而另外一种方式即为“网络Overlay”，是由交换机来实现Overlay的隧道，如下图所示：

图1.3.▲网络Overlay示意

业界最主流通用的做法就是EVPN+VXLAN，其中EVPN作为控制平面，VXLAN作为转发平面。在TOR交换机上作为隧道入口（VTEP），在整个基础网络上构建一个叠加网络。

此方式最大的优势是可以做到被接入到Overlay中业务服务器的无关，不管是虚机、裸金属、小型机，对于接入设备来说不需要关注网络是怎么实现的。

这里有一张图可以借鉴MPLS网络的思路来看分别在服务器和交换机上实现Overlay思路上的区别：

图1.4.▲MPLS思路理解Overlay实现方式

以MPLS的思路，可以将主机Overlay中vSwitch理解为PE设备，负责封装隧道和维护控制面，而网络交换机均为P设备，仅负责转发。

网络Overlay可以理解为，Leaf交换机承担了PE的功能，负责封装隧道和维护控制面，而上层的Spine交换机为P设备，仅负责转发，服务器中的vSwitch则在此时承担MCE的功能。

l  A省某运营商云资源池案例

对于A省某运营商资源池来说，其接入的服务器种类较多，还没有办法完全做到所有的服务器全部为虚拟化服务器，其中不乏裸金属服务器等一些其它还不能云化的服务器。因此，采用主机Overlay无法覆盖到所有设备。而智能网卡方案对于非研发型运营者来说技术复杂度过高。

因此，该案例中，客户的实际部署方案为网络Overlay，使用交换机实现Overlay和SDN，将虚机、非虚拟化服务器接入无差别。

l  SDN如何在云数据中心里发光发亮

SDN在云数据中心里是干什么的？这个要从云计算说起，我们先来看下面一组场景：

A研发部门的老林需要开一个虚机，传统未云化的情况下的流程是这样的：

这个流程的时间周期一般为N小时-N天不等，如果需要什么变更，这个流程可能还要再走一遍。资源使用者效率低，运维管理人员工作量也很大。

在实现资源池化后，企业内部完全可以像在阿里云、AWS一样，自助开通管理自己的虚拟机，还能拥有一个可自行管理的独立网络环境，以满足业务、研发部门的各种IT支撑需求。

如果不实现网络的自动化、自助化，用户就无法获得一个独立可管理的网络环境，资源池化的效率及成本收益会大幅度减少。

A省某运营商作为一个IT业务密集型大型国企，云化技术可以大幅度提升其内部IT支撑的服务效率，亦可大幅提高其IT资源的利用率。因此在其资源池中采用SDN技术，通过软件编程实现网络自动化，就显得非常重要。

l  哪种SDN实现手段更适合云数据中心？

在SDN这个概念中，也有着各种实现方式，比如Openflow、Netconf、OVSDB等在网络设备上实现SDN的方式，也有通过RPC、Openflow、OVSDB等方式控制vSwitch的主机Overlay的实现方式。具体应该采用主机Overlay还是网络Overlay，本文第一章已经做了浅析。

在云数据中心中已经确定采用网络Overlay的情况下，选择哪种实现SDN的网络设备管理协议的实现方式？

业界大部分采用网络Overlay的云数据中心，包括A省某运营商的云资源池均采用了Netconf“下发配置型”的SDN实现方式加上EVPN作为VXLAN的控制平面。其中表项维护由BGP负责，配置变更由Netconf进行下发。

为什么不采用Openflow等可以对网络转发进行直接控制维护的SDN方式呢？

问题在于Openflow这种纯粹的集中控制、分布转发，并且精细到控制每条流的SDN实现方式对于云数据中心的网络自动化的需求并没有过人的收益。反而在某些场景下，大量的流表可能会导致控制平面的瓶颈，因此导致该技术存在着对控制器要求过高，可靠性不足的问题。

而脱胎于MPLS思想，采用分布式控制、分布式转发的成熟、可靠、可扩展理念的EVPN技术，辅以不会对控制平面造成巨大压力或者不可靠因素的“下发配置型”Netconf技术的SDN实现方式，将更加切合可靠性为第一要素云数据中心场景。

l  A省某运营商云资源池SDN实践

A省某运营商的云资源池中有大量对外服务型业务，其中不乏重要业务，可靠性自然是重中之重，因此选择Netconf+EVPN作为SDN网络控制平面是符合其业务需求的选择。

图2.1.▲SDN对接逻辑示意

客户实践中选择基于Openstack开发的商业产品作为其云管平台，部署SDN控制器与Openstack进行对接，Openstack通过SDN控制器对交换机、防火墙、负载均衡设备进行自动化控制和业务编排，实现其云计算业务的自动化和自助化，大幅度提高业务开通和变更效率

l  多种L2 VPN技术选择

不同的数据中心之间需要一个L2 VPN是一个常见的需求，用以满足虚拟机动态迁移提高资源灵活性、容灾等业务需求。而跨数据中心部署需要一个横跨两个甚至多个数据中心的二层网络。

L2 VPN技术的传统方式包括VPLS、OTV（厂家私有技术）等，其中VPLS要求整个链路上的设备都需要支持和部署维护，另外VPLS存在以太网本身泛洪影响面过大的问题，在DCI场景下这些问题就会被放大很多倍。而OTV是一个解决了很多VPLS问题的协议，配置维护起来也非常便捷，但其是一个厂商私有化的协议，没有被广泛使用。

使用EVPN VXLAN来实现DCI的二层互联是一个新的选择：VXLAN可以同时支持L2\L3的VPN，EVPN控制平面使用BGP路由传递MAC信息，也可以解决VPLS中存在的很多小毛病。

l  VXLAN实现云数据中心L2 DCI的多种方法

VXLAN来实现使用数据中心间L2 DCI根据场景不同也有多种方法可以选择，常见两种方式为VXLAN L2 Mapping和VLAN Hand-off 的方式。

VXLAN L2 Mapping：

VXLAN L2 Mapping的实现方式如下图所示：

图3.1.▲VXLAN L2 Mapping原理图示

l  这种方式对比传统的VPLS、裸纤直通的方式的优势包括：

l  对比两个数据中心TOR之间直接用VXLAN互通方案，可以将两个数据中心网络设备中的VNI规划及运维规划解耦，并大幅度减少TOR作为VTEP时的硬件资源消耗。

l  对比OTV等私有协议，EVPN VXLAN为开放协议，具备跨厂商异构部署的优势。

VLAN Hand-off：

除使用VXLAN L2 Mapping，另一种方式是采用VLAN Hand-off的方式：

图3.2.▲VLAN Hand-off原理图示

这种方式是使用独立的2组或多组交换机建立一个与数据中心内部网络无关的DCI层。DCI层上的交换机之间通过EVPN VXLAN建立隧道，需要互联的数据中心出口将VXLAN映射为VLAN后通过DCI层与对端的对应VLAN互通。

VLAN Hand-off 的优势除VXLAN L2 Mapping 中所描述的对比优势之外，其组网也非常灵活，对原有数据中心网络及设备要求更低，并且还可以通过DCI来引入一些公共的外部资源。

l  A省运营商资源池的实践

A省运营商云资源池因历史原因存在着部分原有以传统烟囱方式建设的机房和使用EVPN VXLAN的机房进行互联互通需求，并且由于集采周期会导致每年入围的数据中心厂家都有可能不一样，因此需要一种“解耦”的方式来实现数据中心之间的二层互通。另外直接拉裸纤扩展性差，采用VPLS、私有协议的方式对整体网络和设备要求过高。因此最终采用VLAN Hand-off方式，构建一个DCI层，实现其多个使用VXLAN的云资源池和原有传统组网技术网络之间的二层互通，并且采用SDN控制器及与云平台互通，实现资源池间DCI互通策略自动化下发。

技术的选择是由业务驱动的，也许再加上一点其它客观因素，但每个行业有其独特的业务背景、每个场景有其特性、每个网络都有其历史、管理和运营人员也都有其不同的技术风格和习惯。因此，本文的案例也不代表这些技术在其它类型的云数据中心就一定适合，但希望能通过本文可以让大家对这些技术和背后的需求有更多的理解，也希望能够有所帮助和启发。

如有兴趣想要更深入了解云数据中心的真实案例可以关注下一篇《从实战浅析运营商云资源池网络—解析流量模型》