int main() { return 0; }

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

Oct 30, 2016 by htfy96

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

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成为了一个重要的工具。

上面这张图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。这样因为同一时间只有一个主，所以缓存一致性自然就解决了。

状态集中 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之类的？

 

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

 

    <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>

Tags:  paper ,  sdn