浅谈 SDN 与云网络

SDN 软件定义网络

1.1，什么是 SDN？

什么是 SDN？这个问题似乎自从 SDN 的诞生到现在就一直存在争议的问题。SDN 的官方解释上提出了 SDN 的三个特性：集中化管理、控制转发分离、开放的 API。可以这么说，只要满足 SDN 的三个特性的，就是 SDN。SDN 是一种理念，一种思想。在我们架构网络的时候，SDN 是一种新的思路。

SDN 的三大特性：

• 集中化的管理：有统一的管理入口。比方说我有 100 台交换机，对着 100 台交换机的配置管理，不需要逐个交换机配置，可以通过一个统一的控制器配置着 100 台交换机。这就是集中化的管理。
• 控制转发分离：在 SDN 的网络种，SDN 所希望的是交换机应该足够的“傻瓜”。交换机的功能应该只是匹配和动作（match & action）。里面的邻居子系统、ACL 规则、路由、网关等功能都应该在交换机上完成，而不是在控制器上完成。当然也是一种理想的情况。也是大部分宣称自己是 SDN 云网络的产品做到的地方。在 Open vSwitch 的 Dragonflow 云网络中，其实就把邻居子系统和网关的部分功能做到 SDN 控制器上，主要的目的是为了解决东西流量的分布式以及减少故障域。在 Dragonflow 的云网络中还是保留了不少传统云网络的实现。
• 开放的 API：在 SDN 的架构中，开放的 API 成为北向接口。传统网络的交换机的配置基本上都是 CLI 配置，或者 Netconf 配置，这样的配置接口很难实现通过软件控制网络。对于我们的这些软件开发者来说，如果通过可以对网络编程，就需要一个统一的开放的 API 进行调用。这也是 SDN 的核心思想可编程的网络。

1.2，SDN 有什么好处？

这个问题其实有很多人问过我，SDN 究竟有什么好处？有些比较直接会问，用了 SDN 网络性能会不会提升 30%？用了 SDN 之后，会不会多出很多新的网络功能？我的观点是 SDN 的提出不是一场网络的革命，而是一次网络的发展。架构云网络的过程中，SDN 给我们带来最大的好处是通过 SDN 实现的网络功能所付出的代价会比传统网络的要小很多。这个代价主要是指这几个个方面：开发周期、网络复杂度、架构的完整度、网络 IO 路径长度、冗余耦合度。

我们很早之前就有考虑将云网络和第三方的安全产品整合，提供一套更安全的云网络。安全的厂家只要把原来的安全产品做成实例，运行到云网络中即可。但是最大的问题是云网络，如何将流量引流到虚拟化的安全产品？为了引流我们需要创建更多的 Vlan，需要更多的桥，并且第三方的安全厂家还需要识别我们的实例的迁移日志，配合迁移做规则的调整，我们也需要开放很多本来不应该开放的 API（提供 vlan、桥的创建、日志的筛选）。最终这个计划还是终止了，因为代价太高了。我们的整体网络架构都有大量的改动，同时网络的 IO 路径增加了近一倍，并且开发周期预计要两个季度，更重要的是和第三方的整合项目是不应该存在这么多的交叉开发过程。后来我们的 SDN 云网络终于开发完成了。引流的工作集中在 SDN 控制器完成，整体的网络架构基本没有任何改动。网络 IO 路径没有变化。即使实例的迁移我们的 SDN 控制器也能够识别出来，不需要第三方安全厂家监听日志事件。实现这样的功能一个月就能完成了。这就是 SDN 的最大的好处了。当然这是我们对 SDN 云网络的技术实现细节有关系，后续我会专门写一篇关于品高 SDN 云网络的介绍文章，专门讲一讲这一方面的事情。

传统的云网络

2.1，传统的云网络

传统的云网络：就是基于 Linux kernel 的网络协议栈提供的传统网络组件实现云网络的基本功能。比方说：安全组就用 Linux 自带的 iptables 实现、子网隔离就用 Linux 自带的 Vlan 实现、地址转换就用 Linux 自带的 NAT 实现、流量控制就用 Linux 自带的 TC 实现、路由功能 Linux 自带的 route table 实现等等。再配合一些网络规划，用其中一两台服务器作为网络节点（云网络的出口核心路由器）。最后配合上云的调度能力。这样传统的云网络就构建起来的。

传统的云网络确实也存在不少的问题:

• 网络节点的网络业务过于集中，容易出现单点故障。
• 东西南北流量混合，网络质量不高。
• 传统 Linux 网络协议栈的网络功能捆绑严重，资源消耗严重。
• Vlan 的子网隔离，数量不足。
• 横向扩展能力差，网络规模难以扩展。
• 纵向吞掉性能，受网络节点点单限制。

为了解决传统网络的这些问题，其实很多企业、开源组织也是付出了不少的努力。说到底其实最关键的就是把网络节点的业务功能下沉到计算节点（分布式的虚拟化网络）。当然还有其他的问题，这是不会这么快暴露出来。

2.2 Open vSwitch 云网络之路

前段时间看了《通向高可用与分布式的OpenStack 网络之路》。我得到很多的启发，深深地体会到云网络之路确实艰辛并且曲折。我对比了Open vSwitch 的发展之路和品高的SDN 云网络做了一些分析。如下图：

(点击放大图像)

一个成熟的商用云网络有一个准入条件就是高可用。Open vSwitch 在Neutron L3HA 版本中实现了的HA。但是在后续的几个版本中，因为架构上冲突Neutron L2POP & ARP Respondar 、DVR、Dragonflow 的版本中HA 就无法兼容了。Open vSwitch 的发展之路总结起来就是把网络节点上网络功能（FW，Gateway，NAT，ROUTE，DHCP 等功能）下沉到计算节点。也是提高为了网络容灾能力。不可否认Open vSwitch 是一个成功的产品，目前很多云厂商也是在Open vSwitch 的基础上实现自己的云。

SDN 的云网络

SDN 的提出确实给了我们很多的新的想法。首当其中的想法就是：如果云网络是通过 SDN 实现的，是不是可以解决传统云网络难以解决的问题呢？对于一个新的技术，我们必须要有足够的宽容度。我们的做法是通过 SDN 实现和传统云网络一样功能的云网络，不要求 SDN 去突破性能，创造新功能。我们和 Dragonflow 不同，我们不是部分功能使用 SDN，而是全部网络功能都通过 SDN 实现。这想法确实有点疯狂，但是可行性上是完全没有问题的。

我们制定了一些 SDN 的要求：

• 摆脱网络节点。
• 不使用 Linux 网络协议栈自带的网络组件。
• 计算节点使用 Open vSwitch 作为分布式虚拟交换机。
• 使用 SDN 控制器，将全部的云网络业务功能都集中在 SDN 控制器。
• SDN 控制器和 Open vSwitch 的通信使用 OpenFlow 协议。
• SDN 控制器集群高可用。

在开发的过程中，我们深刻地体会到 SDN 的强大之处。我们不仅仅完成了我们当初制定的要求，我们也通过 SDN 带来了很多新的网络特性。隐藏式分布式虚拟化网关、实例迁移规则不用重新配置、网络功能可热插拔、网络业务的叠加不会增加 IO 路径、网络可视化、ARP 预处理以及 ARP 预填充等等。所有网络功能都在 SDN 控制器，所有网络规则都是按需分配自动超时，控制器集群高可用。后续我会和大家分享一下 Bingo SDN 的网络功能。

SDN 的云网络开发过程中我们也确实遇到了很多问题。比方说，OpenFlow 协议对一些网络功能功能的不支持，Open vSwitch 中有一些 Bug，SDN 网络的新建连接性能低，SDN 控制器集群高可用等等。最后我们还是突破这些问题，后续我会和大家分享的 Bingo SDN 的遇到的问题和解决方法。

不可否认，SDN 的云网络确实是一套可行并且正确的发展之路。SDN 给了我们云网络更多发展的空间。

感谢魏星对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。