转载

浅谈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云网络做了一些分析。如下图：

(点击放大图像)

浅谈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给了我们云网络更多发展的空间。

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

原文 http://www.infoq.com/cn/articles/sdn-and-cloud-network

正文到此结束