OpenStack中SDN泛谈4 (SDN发展与架构)

现实世界的SDN远多于这个系列的介绍，这个系列只是选取了开源的，并且与OpenStack相关的SDN做介绍。还有各种没有与OpenStack做集成的，或者是厂商闭源的SDN。一个个去分析似乎也不太现实，我们这次来看看SDN的共性。毕竟掌握了本质再来看个体更有效。

SDN的发展

有关软件控制网络的想法很早就提出了，在上世纪90年代，网络可编程（programmable network）的概念就在Active Networking中提出。而控制层面（control plane）的分离在2004年也由IETF ForCES Working Group提出。但是在OpenFlow提出之前，这些都只是小范围的研究讨论，发展并不快。虽然说OpenFlow不能代表SDN，但是不可否认，OpenFlow的出现了加速了SDN的发展。现在的SDN体系也是由早期的OpenFlow Controller发展而来。之后发展成SDN Controller，也就是说SDN的范围不再局限于OpenFlow。近期的SDN发展，更多提的是SDN platform和SDN operating system，讲的都是基于SDN构建平台，构建生态。这两者有什么区别，目前我也很难从字面上给出解释。不过这两者都更进一步，不再局限于网络，而是以网络为中心，做更多的事情。

SDN的发展时间与OpenStack的发展时间有一定的重合。而Cloud Networking是SDN的主要场景之一，两者的碰撞不可避免。一方面，OpenStack的流行能带动SDN的发展，另一方面，SDN的演进可以提升OpenStack集群的规模。以后一定能看到更多的OpenStack + SDN的应用。

SDN架构

这个系列之前介绍了几种SDN，细心的朋友估计也能看出SDN的架构大致来了，下面我来总结一下吧。

Application & Orchestration Tier

传统的SDN架构里面没有这一层，在SDN platform里面新增了这一层。而OpenStack也在这一层。SDN想要接入到OpenStack，必须要在这一层完成适配，将OpenStack的请求转换成SDN的请求。在这一层不需要关心SDN底层的具体实现，因为SDN已经将底层网络抽象成纯软件的概念。

Northbound Interface

Northbound Interface是SDN将底层网络抽象成软件概念，并暴露出来的接口。

Application & Orchestration Tier通过Northbound Interface接入SDN Controller。这个接口通常是，但不局限于是RESTful API。像ODL还提供了OSGI接口，而OVN和Dragonflow直接提供DB读写的接口。

换一个角度，不论底层的SDN是什么，单看OpenStack提供的networking服务，Neutron server也可以看成是一个Northbound Interface。因为它提供了相应的网络数据模型的RESTful API。

Control Plane Tier

SDN的核心部分。又分成了几个部分：

Database

SDN自己是一个集群内运行的软件。有自己的状态和数据，因此必须要有一个Database来存储相关的数据。而SDN主要是进行网络运算，网络运算的要求就是高速，低延时。因此对Database的性能要求也比较高。基于内存的NoSQL数据库通常具有更好的性能，更快的响应速度，这个系列前面介绍的几乎所有的SDN都是采用的这类数据库。在这类数据库中，Cassandra是选用多的数据库，OpenContrail，Midonet，Dragonflow都支持Cassandra。并且有报告表明，Cassandra的性能的确优于同类的其他数据库。

鉴于Database的重要性，通常会将Database部署在独立的节点，并且考虑到HA和水平扩展，Database节点也会部署成一个集群。

Message

由于SDN是一个集群内运行的软件，因此SDN需要定义自己的消息通讯机制，以供集群内的各个节点之间通讯。像ODL和Midonet采用的是RPC作为消息机制，OpenContrail则是参考MPLS VPN自己制定的消息通讯机制，OVN和Dragonflow则是简单的消息发布订阅机制。

SDN Controller

终于到了SDN Controller，根据ONF（Open Networking Foundation）的定义，SDN Controller是一个逻辑集中的控制器。逻辑集中的控制器，那物理上就不一定集中了。实际上哪怕是集中式SDN控制器，出于HA和水平扩展的考虑，也不会部署成物理集中。而SDN控制器也朝着分布式的方向发展。像OpenContrail，Midonet，OVN，Dragonflow都有不同程度的分布式。有关集中式，分布式控制器的特点，我在之前的SDN闲聊中有过介绍，这边就不再多说。

SDN控制器包含了各个网络功能的实现。也就是一个个Network service。具体的来说，Network service就是将Northbound的抽象数据和Southbound的具体网络协议做了适当的转换和翻译。也就是这样，原本生硬晦涩的network element，经过Network Service可以灵活的通过软件来定义。

SDN Controller还包括了数据层面（Data plane）的接口，当然，这个接口一般不会太具体。

Southbound Protocol

各类控制协议和网络协议。虽然感觉上很多，但是常见的还是OpenFlow和NetConf。这是network elements暴露出来的接口，只有支持相应协议的网络设备才有可能成为SDN的一部分。

Data Plane Tier

这一层就是实际的网络设备层，包含各种网络设备。网络设备本身也分为physical device和virtual device。Physical device就是支持OpenFlow或者NetConf或者其他控制协议的交换机，路由器和其他的网络设备。这些硬件设备目前占据SDN市场的大份额，也是各大传统网络设备厂商的地盘。Virtual device，就是支持OpenFlow或者其他控制协议的虚拟网络设备。像OVS，OpenContrail的vRouter。Virtual device被认为是有发展前景的，并且在成本上也优于physical device。

SDN的功能

虽然Cloud computing对SDN的意义非常大，但是SDN并非是为了Cloud computing而诞生的。SDN的提出是为了简化日趋复杂的网络架构，降低网络管理的难度和成本。随着SDN和Cloud computing的发展，数据中心趋于虚拟化。SDN的初衷倒也是契合Cloud networking的目的。从发展趋势上看，SDN具备了以下功能才能算是功能完善。

• Cloud Networking：为数据中心和云提供虚拟化的网络服务。这是所有SDN的标配，要是没有这个功能，都不好意思跟别人说自己是SDN。
  
• NFV： 作为虚拟网络界的另一股发展力量。NFV在电信运营商场景非常受欢迎。借助SDN可以更好的实现NFV。像ODL和OpenContrail明确表示了支持NFV场景，而ONOS主打SP场景，在NFV领域也当仁不让。在OpenStack环境下，还可以借助networking-sfc项目实现NFV，Dragonflow目前在这方面有所动作。
  
• Container Network：容器这几年的发展是如火如荼，容器网络作为容器技术的一部分，也是各个SDN发展的重点。在OpenStack环境下，可以借助kuryr项目实现容器网络和SDN的结合。Midokura和Huawei作为kuryr项目的发起者和大贡献者，对应的Midonet和Dragonflow自然借助kuryr项目实现容器网络与SDN的集成。OVN自己也在做一些容器网络集成的尝试ovn-kubernetes。OpenContrail自己实现了容器网络的集成。从容器的发展来看，基于CNI的kubernetes网络模型接受程度更高。


• Physical provider Network：SDN虽然管理的是虚拟网络，但是有些应用场景也要求与物理网络的连通。
  

SDN与开源

开源只是技术的开发手段，与SDN并非强相关。一些闭源的SDN市场和口碑都不错，例如VMware的NSX。但是从OpenStack的发展来看，SDN的开源之路似乎是趋势。OpenStack通过开源，统一了IaaS层面的标准，为整个云计算带来了新的发展。现在SDN仍然没有一个压到一切的方案，虽然ODL和ONOS背景强大，但是似乎也并没有让其他SDN臣服。开源SDN仍然是一条漫漫长路。

SDN未来

SDN被认为是Next generation networking。传统的IT、BFSI（银行金融服务）、电信等领域，都在积极探索SDN。在移动服务和大数据分析场景下，对SDN也有一定的诉求。根据Allied Market Research的研究，在2022年，SDN的市场将达到1.3亿美金。过段时间专门分析一下这个研究报告。

就像随着数据中心的发展，Cloud computing也随着发展一样，随着网络技术的发展，SDN的发展只会越来越成熟，应用越来越广。