SDN分布式控制器的一些总结

话说天下大势分久必合合久必分

SDN

先来摘抄一下什么是SDN1

As originally defined, SDN refers to a network architecture where the forwarding state in the data plane is managed by a remote control plane decoupled from the former

到底解决了什么问题呢?

  • 以前,控制下一跳把包从那个口丢出来的逻辑是分布在各个设备之上的,这样配置起来就很麻烦了,之后进化出了配置中心这样的东西,把配置集中了起来管理,这可能是SDN的想法来源之一
  • 之前,在交换机上,决定哪几个口二层可达,可以利用VLAN机制。最早的时候就是根据交换机端口来决定,之后发现问题越来越复杂,渐渐地需要利用MAC/IP来判断VLAN。这是业务逻辑越来越复杂的体现,传统的依赖硬件/内核,难以自由定制的方案越来越难以满足需求2
  • 同时,之前的能处理复杂情况的交换机非常昂贵,几家巨头形成了垄断
  • 配置不通用。不同设备、不同厂家的配置不统一
  • 传统的网络结构是Partially Observable的,容错性很好,但每个节点只能看到自己的信息,使得无法达到最优的路由等方式

分久必合

由于硬件性能的提高,VXLAN等网络虚拟化技术的出现,云/大型数据中心的需求,SDN成为了一个重要的工具。

screenshot-from-2016-10-30-20-43-12

上面这张图1就是SDN的主要原理。网络中的大多数底层设备(Switch)只负责根据流表,在Match到头部等于某个特征时,转发到指定port;或去询问控制器。控制器则一方面负责在设备中安插/更新流表(通过南向API),负责以前的逻辑部分。另一方面与应用程序进行交互(北向API,因为流表是一个非常底层的东西,例如OpenDayLight的这个API3),给应用程序提供一个抽象的Network View。

但北向API现在非常混乱,缺乏标准。南向API有OpenFlow等标准可以供Switch执行。Switch既可以是硬件(FPGA,专用电路),也可以是软件(OpenVSwitch),只要遵守相应的标准4就行了,这样就能利用廉价硬件+编程实现之前高端交换机的效果。

分布式控制器

在SDN中控制器有哪些作用呢?

  • 处理包
  • 安插流表规则

合久必分

别忘了,最早SDN的目的就是为了配置变方便,于是大家就想搞一台服务器做Controller,Switch都来请求这一台服务器就好了。

这样一合,省事是省事了,但单点故障也就变得很常见了。同时,集群数量变多了,1500台的集群每秒能产生100000多条流,而一台控制器每秒只能处理30000条左右的流。于是,大家八仙过海各显神通,又利用了分布式的很多技巧把控制器拆成物理上多台5。(接下来的具体文章引用懒得写了)

容错 – replica

如何High fault tolerence呢?Replica。最早有12这篇用state replica machine来保证副本和主的状态一致,然后数据统一写到数据库里,大家来ZK抢主。后来发现性能不行,于是14一篇在数据库/controller之间做了个cache,写入是write back。这样因为同一时间只有一个主,所以缓存一致性自然就解决了。

replica1

状态集中 vs 剥离

个人认为,这个方法的好处在于把状态存储剥离了出去,尽管可能表现不理想,但是一个比较好的方向。同样的还有OpenDayLight的思路,利用了现成的分布式KV。

另外的一些方法,则是直接将状态和控制器放在一起(主流):

  • 6、HyperFlow,不需要中心数据库:用二段提交的方法,使得每个Controller的状态一致。但这样最多也就在几个Controller的时候比较有效,多了之后二段提交就经受不住了。
  • Google的Onix应该有两种方案,一种是利用分布式消息队列,需要某个数据的subscribe某个topic,其它人更新了publish一下,这样一致性相对损失较小,性能也不错。
  • Onix的另一种方案是针对快速更新的数据,使用DHT来存储。但这样一致性就牺牲地比较多了,但效率极高
  • 还有Shared Memory乱搞的……

单一控制器 vs 地位不对等

之前说的这些,要求都是基于“每个Controller的地位是对等的”这个原则,因此也被称为单一控制器。

实际上,对于不同子网,我们可以采用不同的控制器,这就叫做扁平控制器。

更进一步,有人认为,一个子网中的大多数的Flow处理都能被本地控制器完成,只有少数请求才需要丢到中央控制器去处理。由此形成了2-tier的控制器结构。

静态switch – controller mapping vs 动态

之前,很多switch – controller的对应是静态的:Switch维护一个Controller List,一个挂了就去找下一个。这样很不方便更新,而且Switch检测间隔会很大,Controller挂了可能到了下一次还不知道。

于是就有人想到:在Controller – Switch中间加一个Scheduler,根据Controller的负载、距离来源的Switch的距离来选择分配到哪一个Controller上。

还有人搞了个中间层,来过滤掉某些包不能被Controller看见的部分,也过滤掉Controller下发的结果中无权作用在Switch上的部分。

这部分想象空间很大,而且和最近在做的一些东西有关

最近的一些想法

Q:为什么2-tier的控制器没推起来?

A:要显式在写程序的时候指定哪些东西处理不了,很麻烦。而且不灵活

Q:分布式控制器本质上是什么问题?

A:本质是状态同步的问题。如果我们存在一种方法能低延时、高可用地强一致地访问到所有状态,那么我们只需要加机子就行了。但和之前已经研究那么多的DB一参照,就知道这种东西不存在,所以各个方案都牺牲了一些东西

Q:为什么不用外界已有的东西,剥离出来状态同步部分而都自己造了轮子?(看见有人造了ZK缩水版。。)

A: ???(延时?占领市场?水文章?

Q:有什么可做的?

A: 个人认为单纯应用Distributed System的某种方案已经基本都水过了……需要挖掘SDN网络的一些特殊性,也许可以做到一些改进?时空局部性(Cache?)?流量特征(某类流量 <-> 需要控制器的状态有映射?让某类控制器专门处理某类流量这样可以缓存什么的?)?自动划分Tier 1/ Tier 2之类的?

 

嘛……总之还需要继续再看些文章等等有没有想法……

 

1.
Kreutz D, Ramos FMV, Verissimo P, Rothenberg CE, Azodolmolky S, Uhlig S. Software-Defined Networking: A Comprehensive Survey. arXiv:14060440 [cs]. 十月 2016. http://arxiv.org/abs/1406.0440. 见於 十月 30, 2016.
2.
虚拟局域网. 收入: 维基百科,自由的百科全书. ; 2016. https://zh.wikipedia.org/w/index.php?title=%E8%99%9A%E6%8B%9F%E5%B1%80%E5%9F%9F%E7%BD%91&oldid=41839460. 见於 十月 30, 2016. [Source]
3.
OpenDaylight Controller:RESTCONF Northbound APIs – OpenDaylight Project. https://wiki.opendaylight.org/view/OpenDaylight_Controller:RESTCONF_Northbound_APIs. Published 2016年10月30日. 见於 十月 30, 2016.
4.
OpenFlow Switch Specification(Version 1.5.1). 十月 2016. https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.1.pdf. 见於 十月 30, 2016.
5.
Jarraya Y, Madi T, Debbabi M. A Survey and a Layered Taxonomy of Software-Defined Networking. IEEE Communications Surveys & Tutorials. 2016;16(4):1955-1980. doi: 10.1109/COMST.2014.2320094 [Source]
6.
Fonseca P, Bennesby R, Mota E, Passito A. A replication component for resilient OpenFlow-based networking. 十月 2016:933-939. doi: 10.1109/NOMS.2012.6212011 [Source]

发表评论