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.
    <div class="csl-right-inline">
      Kreutz D, Ramos FMV, Verissimo P, Rothenberg CE, Azodolmolky S, Uhlig S. Software-Defined Networking: A Comprehensive Survey. <i>arXiv:14060440 [cs]</i>. 十月 2016. <a href="http://arxiv.org/abs/1406.0440" target="_blank">http://arxiv.org/abs/1406.0440</a>. 见於 十月 30, 2016.
    </div>
  </div>
</div>

<div id="d1kdasqfc4">
  <div class="csl-entry flush">
    <div class="csl-left-margin">
      2.
    </div>

    <div class="csl-right-inline">
      虚拟局域网. 收入: 维基百科,自由的百科全书. ; 2016. <a href="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" target="_blank">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</a>. 见於 十月 30, 2016.<span class="abt-url"> [<a href="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" target="_blank">Source</a>]</span>
    </div>
  </div>
</div>

<div id="k8hhako05">
  <div class="csl-entry flush">
    <div class="csl-left-margin">
      3.
    </div>

    <div class="csl-right-inline">
      OpenDaylight Controller:RESTCONF Northbound APIs &#8211; OpenDaylight Project. <a href="https://wiki.opendaylight.org/view/OpenDaylight_Controller:RESTCONF_Northbound_APIs" target="_blank">https://wiki.opendaylight.org/view/OpenDaylight_Controller:RESTCONF_Northbound_APIs</a>. Published 2016年10月30日. 见於 十月 30, 2016.
    </div>
  </div>
</div>

<div id="n180e21a90">
  <div class="csl-entry flush">
    <div class="csl-left-margin">
      4.
    </div>

    <div class="csl-right-inline">
      OpenFlow Switch Specification(Version 1.5.1). 十月 2016. <a href="https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.1.pdf" target="_blank">https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.1.pdf</a>. 见於 十月 30, 2016.
    </div>
  </div>
</div>

<div id="a1p4ckgg80">
  <div class="csl-entry flush">
    <div class="csl-left-margin">
      5.
    </div>

    <div class="csl-right-inline">
      Jarraya Y, Madi T, Debbabi M. A Survey and a Layered Taxonomy of Software-Defined Networking. <i>IEEE Communications Surveys & Tutorials</i>. 2016;16(4):1955-1980. doi: <a href="https://dx.doi.org/10.1109/COMST.2014.2320094" target="_blank">10.1109/COMST.2014.2320094</a><span class="abt-url"> [<a href="http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6805151" target="_blank">Source</a>]</span>
    </div>
  </div>
</div>

<div id="z1pd0dg983">
  <div class="csl-entry flush">
    <div class="csl-left-margin">
      6.
    </div>

    <div class="csl-right-inline">
      Fonseca P, Bennesby R, Mota E, Passito A. A replication component for resilient OpenFlow-based networking. 十月 2016:933-939. doi: <a href="https://dx.doi.org/10.1109/NOMS.2012.6212011" target="_blank">10.1109/NOMS.2012.6212011</a><span class="abt-url"> [<a href="http://ieeexplore.ieee.org/document/6212011/" target="_blank">Source</a>]</span>
    </div>
  </div>
</div>