下一代超大规模软件定义 络技术实践

云计算的 IT 架构已经在企业应用中表现出明显优势，但 络设计理念却必须是一种推倒重来的思想。为了适应云计算的灵活、弹性扩展、高效和低成本， 络设计要进化为集中式软件管理，可编程化，控制转发层面分离等。本次陈海泉分享了关于下一代超大规模软件定义 络技术实践。

以下是本次分享的内容整理。

大家好，我是 QingCloud 的工程师陈海泉，今天给大家分享一些 SDN/NFV 2.0 架构的 络技术。我解释一下什么是 SDN，SDN 就是软件定义 络。当然也不是所有 络定制一定要软件来实现，因为有很多硬件方案也可以做到 SDN 的效果。

青云QingCloud 用软件定义来实现虚拟 络，我们 2013 年的时候，在公有云上线了第一代产品。当时 SDN 还是一个比较新鲜的事情，用户用的还比较少。到了今天，SDN已经开始普及，连私有云用户也在使用基于SDN的VPC。

随着用户量越来越大，第一版的 SDN 提供的私有 络里面的 VM 超过一定的数量的时候，我们发现性能就有一个比较大的损失，已经无法满足企业用户的需求。所以我们在去年下半年的时候，花了很大功夫去做 SDN/NFV 2.0 的事情。

QingCloud 在 SDN 方案的选型上也做过讨论，用软件还是用硬件方案中考虑的问题主要是以下三个方面：

1. 成本。在公有云上面大家拼的是成本，谁的硬件成本低，谁就能把价格降到最低。如果我们采用硬件方案，在 络设备上面需要增加了很多投资，要替换掉几乎所有的 络设备。
2. 设备依赖。我们的私有云卖的是软件，客户可以按照偏好选择自己的硬件，假如 QingCloud 的 SDN 绑定了某款硬件产品，那我们在面对企业客户的时候，可能连招标的机会都没有，因为客户往往有自己的采购渠道，指定的硬件品牌。
3. 情怀。对于工程师来说，自然是想把产品做得更优秀。参考下优秀的传统行业，就能明白这一点。

其实，计算机 络跟传统快递行业非常的接近，我在后面解释 络知识时，也会拿快递打比方。

为什么说快递跟计算机 络接近呢为 络中的交换机、路由器，其实跟快递行业里的快递员和包裹集散中心非常相似，用户发包裹给快递员以后，快递员会送到快递集散中心，这里可以查询包裹应该被送到哪个地方，然后再将包裹经过多个快递集散中心层层转运，才会送到收件人那里。

顺丰在中国应该是最好的快递公司之一，因为它把转运环节都做全了，只有方方面面都能够控制才能实现压倒性的优势。

上面的插图给了顺丰航空的一个截图。我是看到了这张图，才明白为什么他们能够比别家送得快。因为他们不仅有自营的快递转运点，连飞机都是自己买的。

因此，我们如果把数据包转发的每个流程都控制到，就有可能在整体系统上面做到最优，而采用硬件设备实现这些功能的话，最后带来的是同质化，跟竞争对手相比不会有任何的优势。

综合以上三方面的原因，我们决定开发一套新的 SDN/NFV2.0 方案，取代 1.0 。

在一些大公司里会提供一种叫内部邮件的服务给员工，比如要给财务部门某同事发一个 销单，会查他的工位，比如 2pw067 。然后准备一个信封，把要填的单子放在里面, 收件人地址就填 2pw067 。我不需要知道这个人是在北京，还是在上海，直接用工位 就能发件。我把这个信封交给公司的收发室。收发室其实不具备邮递能力，但是他们也能做快递业务，方法就是对这个信封进行重新封装，收发室有个地址本，能查到 2pw067 这个工位对应的办公楼具体地址。

然后用一个大信封，把我原来的信封装进去，收件人填目标办公楼的收发室员工名字，收件地址是实际的街道地址，然后把具有新地址的信封交给真正的快递公司，比如顺丰。快递公司会把信封发送到对应的办公楼，然后那边的收发室把外层信封拆掉，将里面的信封交给具体的收件人。

拿计算机的术语来讲，内部邮件系统就是虚拟快递公司，真正派件的快递公司，叫做物理快递公司。虚拟 络非常类似，允许用户通过自己定义的地址，进行传输。这个地址用户随便定义，反正物理 络看不到这个地址，也就不受任何限制。

物理机收到 VM 发的包后，会对数据包做封装，再套一个信封，也就是加个包头，写上目标物理机的地址。物理 络设备，根据新的包头把这个数据包发送到对应的物理机，然后物理机那边的终端会把数据包拆开，将里面的数据包转发到目标 VM 。

这里的封包，拆包就是 Overlay 技术，也叫数据封装。听起来很高大上，其实传统行业几百年前就实现了。

下面就是具体的计算机技术细节：实现虚拟 络，比较流行的数据封装协议是 VXLAN ，因为 VXLAN 相比传统的 GRE 协议有一系列的优势。

1. 隧道连接一组物理机。 VXLAN 发包时，可以任意指定目标物理 IP 地址和 ID ，不像 GRE 那样，要在两边配置点对点的连接；
2. 使用 UDP 协议。 UDP 协议的特点是有端口。发包时每个连接都使用不同的源端口。当数据包交给目标服务器 卡的时候， 卡根据这个数据的包头的 IP/端口做 HASH 运算，用于选择不同的 卡队列。而每个 卡队列会绑定到一个 CPU 上面，这样把包会交给不同的 CPU 处理，提升总体性能；
3. 使用基于组播的 Flood & Learn 模式自动管理虚拟 络。这个功能会大幅降低组件虚拟 络的复杂度，因为 VXLAN 的终端，会根据数据包包头的内容，自动建立，并维护一个转发表。回包的时候，根据转发包找到目的物理机的地址。

这里的转发表，拿之前的例子说明，就是企业内部邮件收发室的地址本，把虚拟地址和物理地址对应上。 VXLAN 的这个特殊功能，就是能够自动建立地址本。

基于以上几点，我们觉得 VXLAN 不错，但是仔细的去想，就发现它有两个非常大的不足：

1. 发送广播包时，使用了组播协议，大规模部署会受硬件设备组播路由限制。它在二层 络中使用时，没什么问题，但是在三层 络中使用时，物理路由器上会建立大量的组播路由条目，影响路由器性能，并且增加了路由器运维的难度。
2. Flood& Learn 的机制，会把原来在二层广播的 ARP 包扩大到三层 络。

第二点解释起来比较复杂，先从 ARP 原理讲起。 ARP 的作用是把 IP 地址转换成 MAC 地址。在发包方，如果遇到不认识的 IP 地址，会发个广播包到当前的二层 络，内容大概是：谁的 IP 是 1.2.3.4 ，请告诉 1.2.3.5 。所有 络成员都会收到这个包，但是只有 1.2.3.4 会回包给 1.2.3.5 。这样， 1.2.3.5 就知道了 1.2.3.4 的 MAC 地址，接下来他们就能够通过 MAC 地址互相通信。 Flood & Learn 的原理就是学习 ARP 广播包的行为，建立转发表。

拿之前的企业内部邮件做例子，收发室收到目标地址是 2pw067 的邮件时，他一开始不知道这个地址在几楼的哪个办公室，他会群发 Email 到写字楼的全体员工，说有 2pw067 的包裹。这样收件人会到收发室取邮件，同时把自己的 Email 告诉收发室。

此时，收发室的这个人，会默默在自己的小本上加一行： 2pw067 的 Email 是 XXX@yunify.com 。这样下次在有到 2pw067 的邮件，他直接给 XXX@yunify.com 发邮件，通知他来取件，而不是群发所有人。这个方式最大的问题是，收发室老会群发邮件，而且他每隔一段时间，就要确认下 2pw067 的 Email 有没有发生变化。这样随着规模扩大，广播越来越多，会严重的浪费带宽资源。

虽然物理 络也会使用 ARP 广播，但是广播被限制在二层 络里面。而虚拟 络的载体，实际是三层的物理 络，广播实际上可能被发送到整个数据中心的所有物理机。在大规模部署虚拟 络时，ARP 浪费的带宽可能占 络流量的一半以上。

要解决这个问题，需要做到两点：

• 拦截 ARP 广播，避免发送到全局；
• 使用控制器同步地址本，代替 Flood & Learn 功能。

所以，需要有 SDN 控制器，通过同步规则，取代 VXLAN 自有的 Flood& Learn 功能。

也就是说，有个 HR ，每当有员工人入职，工位变动时，就把他的工位发到公司所有写字楼的收发室，不让他们用广播的方式学习地址。而且收发室收到群发邮件时，会主动回包，而不是把广播包转发到别的收发室。

那么这个控制器需要多少个呢之前曾经了解过一些 SDN 方案，通常只有一个。它负责同步整个集群中所有节点的规则，这么做带来一个问题，当 VM 创建、销毁、迁移的时候，控制器需要把新的规则同步到整个集群所有的节点中。

而优秀的云计算平台，能够让用户秒级创建资源。 VM 创建、销毁、迁移这种事情，在集群中无时无刻都存在，同步规则会变得相当频繁。所以我们做了一个分布式控制器，不仅把控制器分布到每个 VPC ，还分布到每个虚拟 络里。

刚才说了虚拟 络和控制器，第三点 SDN 需要做的就是控制数据平面，其作用就是把数据包从 卡拷贝到 VM 。

传统的数据平面，比如 OpenStack 通常会用 OVS 。 OVS 会有一个问题，它会把数据包传到 UserSpace ，因为有个应用程序，根据流表决定数据包如何转发，这样会带来性能的下降。

而我们的方案完全避免了这个问题，使用自己研发的 DVR 取代 OVS ，所有数据转发都在 LinuxKernel 中完成。 DVR 就是分布式虚拟路由器。它实际上是一个带路由器的交换机，同时具有二层交换，和三层路由的功能。

DVR 这个概念，几乎在所有先进的 NFV 方案的 SDN 中都有，比如 OpenStack 的 DVR ， VMware NSX 的逻辑路由器，OpenContrail 的 vRouter 。

他们名字虽然不同，但是本质是相同的，也就是说，让每个计算节点都拥有虚拟的交换机和路由器。听起来很简单，但是实现它有很大困难，其中之一就是：同一个 络的 DVR， MAC，IP 地址都是相同的，这在物理 络里面是无法想象的，因为打破了 络的基本规律。

但是 DVR 却是 NFV 方案的一个关键。

1. VPC，并且 VPC 主机直接绑定公 IP 。
2. 负载均衡器。可在公 关上对入流量进行分流，转发到多个负载均衡器节点。
3. VM 使用基础 络时，也就是物理 络的 IP 地址在迁移后不变。
4. VPC 和物理 络高效连接。

下面分别解释。

首先是 VPC ，青云QingCloud VPC 功能是 1 月 6 上线的，我们只上线了一周就卖掉了第一批上线的所有物理资源。因为我们公有云的大用户已经深深的认识到必须要有一个 VPC 才能支持自己的海量的资源。业务真的到了一千个 VM 以上的时候，就需要有一个高效的三层 络，取代二层 络。

我们 VPC 设计是支持 64000 台虚拟机，代表着我们控制器控制规则有可能是 6 万条，假如我们把跟 6 万条规则同步到每个 DVR 上去，这同步量非常大。

相信靠我写的代码完全不可能实现。所以设计一开始就给他设计了一个学习的能力。学习不是是基于泛洪的学习，而是根据用户的行为对他进行学习。

这个学习功能，还是拿快递打比方。

快递员通常收到邮件时，会把邮件发到邮件集散中心，那里有人去查地址本，决定邮件对应的下一个邮件集散中心是哪个。然后会交给邮递员经行投递。我们假设每个快递员都能够把包裹投递到任何一个地方，也就是拥有 DVR 的能力。

当发件邮递员投送发给oc的包裹到北辰购物中心 2 楼时，他多做一件事情，给收件的快递员打个电话，告诉他说：哥们，你以后再收到发给 oc 的包，直接交给我，不用送到邮件集散中心。这样收件快递员更新自己的地址本，记上： oc 的包，给快递员老王，让他直接去派送。下次，再有包给 oc 时，他把包交给老王，老王直接派送给 oc ，不必去邮件集散中心绕路。

这就是 VPC 主动学习功能的基本原理，能够实现超大规模的三层 络，却不必同步大量的转发规则。

DVR 除了实现 VPC 功能之外，还有许多别功能。请看上面这张图，除了 VPC ，还有其他四个方向。

• 第一个就是公 关，为了提高公 访问性能，DVR 跟公 关可以直连；
• 第二是 VPC 的虚拟机要能跟硬件设备进行高度的互访，因为我们私有云用户的机房里，不止有虚拟机，还有 Oracle 的数据库、F5 的路由器等等，假如我们让用户把这些业务放到虚拟 络里，虚拟 络就要跟硬件 络进行高速的互访，VPC 跟物理 络互访通过给 VM 绑定物理 络 IP 实现，也就是说一个 VPC 的虚机，除了有自定义的虚拟 IP 地址外，还能有一个对应的物理 络 IP ， DVR 会做地址转换，把物理 IP 转换成私有 IP ，实现跟硬件 络高速互联。
• 第三是 VPC ，可以让用户定义 255 个 C 段，加起来可以有 60000 多个虚拟机。
• 第四，我们还提供了一个边界路由器，可以让用户虚拟资源跟远程的 IDC 之间做一个互通。

除了 VPC ，我们为私有云用户设计了 VBC 功能。 VBC 的特点是里面的 VM ，全部可以直接使用物理 络定义的 IP 地址，而且具备 VPC 的所有功能。 VBC 是一个私有 络和物理路由器的混合 络，能够做到使用物理IP地址的同时，能让 VM 在集群中任意迁移，有保持 IP 地址不变。

最后一个就是负载均衡器集群，设计是这样，我们有一个 关集群连着因特 。比如我有一个 IP 1.2.3.4 ，入流量发送到 VG 1 这里。VG 1 会做第一次的流量转发，把流量转发到用户自己私有的负载均衡器节点里（LB node1、2、3）。它的特点是，返回流量不需要经过进来的 VG 1，而是经过 LB node 对应的不同物理 关发送到因特 。

因为当 VG1 能力受到限制的时候，假如我们所有流量都从它回去的时候，它自己的 络带宽实际上就是整个集群的能力，而我们把它分散之后，就可以做到，出去的流量几乎是没有限制，只要我们的 VG 设备有多少，它的带宽就会有多少，因为流量不需要从默认的线路回去。同时随着用户拓展负载均衡器节点的数量，也扩展了 HTTPS 的卸载能力。

并且我们做到了 4 层/ 7 层的完全透明，也就是说用户通过因特 访问到他们业务的时候，我们在所有转发过程中，都会保留其原地址，用户这边得到的包是直接来自因特 用户的 IP 地址。

QA

1、问题：有的 SDN 必须更换新的物理服务器；有的 SDN 不需要。请帮忙分析一下。

必须更换新的物理服务器的这种 SDN ，属于硬件方案，软件定义 络，硬件实现 络。典型的产品是思科N9000 系列交换机。有的 SDN 不需要换设备，因为代码跑在 X86 服务器上，也就是 NFV 实现。

2、问题：据了解你们新的 SDN 里面 VM 迁移可以保持 IP 不变，你是怎么实现的/h4>

因为 VM 的 IP 在二层 上，使用了虚拟 络，将分散在不同物理机上的 VM ，都连成了一个二层 ，但是路由器使用的是物理路由器，做到了迁移后，IP 不变，也就是虚拟交换机+物理路由器。

3、问题：LB 能否直接连接后端服务器/h4>

可以，不管是 VPC ，还是基础 络，都可以，而且 TCP/HTTP/HTTPS 全透明，后端直接获得客户端源地址。

4、提问：刚才提到 DVR ，能不能详细介绍一下。怎么实现/h4>

具体实现比较复杂，我们改了 LinuxKernel ，让它能够适应 DVR、MAC、IP 重复的情况。因为同一个 段的 VM ， 关的 MAC、IP 都的是一样，而这些 VM 又需要有各自的 DVR 。我们改了很多虚拟交换机的逻辑，也发明了一些功能才做到，但是不太容易解释。而且虚拟 络还能让用户使用虚 IP ，这也是 DVR 的一个难点。我之后还看了下 AWS 的 VPC 功能，他们还不能允许用户定义随便 VIP 。

5、提问：计算机都是和本地 L3 出去，在两个 端，那你这个从本地的 L3 到外 那个 L3 这怎么算/h4>

从本地的 L3 到外 那个 L3 ，在 DVR 层面就是两个虚拟路由器之间的转发，逻辑上也是一跳。

6、提问：SDN和NFV有啥区别/h4>

SDN 只要求软件定义 络，可以是硬件实现， NFV 表示用软件实现虚拟 络，属于 SDN 的一种。

7、提问：一个 VPC 对应一个 VXLANID 以对应多个吗/h4>

青云QingCloud 的 VPC 可以包含 253 个 VXNET ，就是虚拟 络，每个 VXNET 对应一个 VXLAN ID 。 VXLAN 关是分布式，一个 VXLAN 有很多 DVR 。

8、提问：一个 VPC 内 关是不是分布式的，同一个 HOST 内的两台 VM ，不同 段互访可以本地 DVR 转发，还是要到专门的 关设备/h4>

本地 DVR 转发，通过学习功能建立路由表。

9、提问：VXLAN 控制平面的自动学习是怎么实现的/h4>

我们自己发明的一个学习方法，要求 DVR 之间能够互相沟通。之前有讲过，就是那个快递员之间打电话的例子。

10、提问：SDN Controller 是你们自己研发的，还是开源的/h4>

是我们研发的

11、提问：DVR 的配置下发是怎么实现的，是由 SDN Controller 下发的嘛向用了什么协议/h4>

Controller 下发部分规则，建立默认的路由表，更多是靠 DVR 的学习功能，里面学习机制的通信是我们定义的，路由同步是标准的 BGP/OSPF 这些。

原文链接： https://community.qingcloud.com/topic/336/