前言
不久之前，onlab的那群人，发布了ONOS。同时也在SIGCOMM上发表了一篇论文ONOS: Towards an Open, Distributed SDN OS,这引起了很多人的关注。博主刚好得知这个消息，阅读了一遍ONOS的论文，总（翻）结（译）了一下论文的内容，作为自己的论文笔记（好长的笔记）。但是越来越感觉读论文，然后写一些读书或者读论文笔记没有意思。因为写着写着，写成了翻译，完全没有自己的观点。还不如去做些实验，写点教程来得实在。读研究生的生活也感觉有些无所事事了，我想我应该做点有意义的事情，比如学一下Docker, OpenStack之类的。搞学术，学术不让啊！
ABSTRACT
ONOS(Open Networking Operating System)是一个分布式的SDN控制平台。ONOS满足了大规模网络操作系统对性能，拓展性等需求。在论文中，他们提出了来那个个ONOS的模型。第一个模型实现了核心的特性，完成了一个分布式的网络操作系统模型，但是性能不够好。第二个模型则在第一个模型的基础之上，大大提高了ONOS的性能。
INTRODUCTION
为了支持大规模网络的需求，ONOS可能需要满足一下极具挑战性的需求：
- High Throughput: up to 1M requests/second
- Low Latency: 10 - 100 ms event processing
- Global Network State Size: up to 1TB of data
- High Availability: 99.99% service availability
PROTOTYPE 1: NETWORK VIEW, SCALE-OUT, FAULT TOLERANCE
ONOS的第一个模型使用了若干的开源软件来构建整个系统。比如使用FloodLight的一些现有模块，如switch manger、I/O loop、link discovery、module management、以及REST API。也使用到了Zookeeper, Titan, Cassandra以及Blueprints等开源软件。
Global Network View
ONOS维持了一个全网拓扑视图，从而允许一个ONOS集群内的实例能相互之间分享和管理网路信息。其全网拓扑信息包括switch、port、link和host等信息。ONOS使用Titan graph database来存储，并使用Cassandra 来保障分布式和可持续性。由于Cassandra具有一致性存储的特性，所以保障了网络视图的最终一致性。
Scale-out.
ONOS的一个关键特性就是拓展性。ONOS分布式运行在多个服务器上，每一个实例是其管理的网络子集中的交换机的控制器。一个独立的ONOS实例将独立地完成网络的控制，并始终保持与全网视图的一致，即网络中发生状态变化，如添加交换机等时间，都应该由ONOS实例负责将这个事件传播到全局网络视图（Global Network View）。
Fault tolerance
分布式的ONOS允许即使某一个组件甚至某一个ONOS实例Down掉也不会影响整个系统的运行。ONOS允许component作为一个单独的实例去运作，不过也提供了多冗余容灾的能力。多实例的情况下，需要选择出leader，这个在分布式系统中是分厂必要的行为。在OpenFlow1.3版本中，有多控制器的定义。ONOS可以允许交换机连接到多控制器，但是对于交换机而言只有一个控制器是master，其他的是slaver。当某一个ONOS发生故障Down掉之后，他所管理的交换机将由别的ONOS实例接管。ONOS使用Zookeeper来存储交换机和控制器之间的关系数据。每一个ONOS实例都需要连接Zookeeper。Zookeeper曾经是Hadoop的一个子项目。现在已经好似一个顶级项目。它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
Evaluation
ONOS的第一个模型花了4个月的时间（好快！）。但是，这个Prototype的性能表现并不好。论文中举例分析如下：
Consistency and Integrity: 这一部分论文写得比较模糊，没有看懂，所以不发表评论。
Low Performance and Visibility
模型一的性能并不好，特别是延迟比预期的要差许多，比如30s才可以获取到网络拓扑状态变化情况。主要原因在与使用了开源软件，虽然很快可以完成开发，但是这些开源软件之间的协调，并不容易。而且ONOS的开发者并不是特别熟悉这些开源代码，导致性能并不高。
Data Model Issues
由于使用Titan存储，所以所有数据如Port,flow entries等都需要以Vertices存储。而且需要构建一个索引来查询数据如交换机数据。当大量节点加入网络时，并发的数据量就会很大，所以索引构建就会成为瓶颈。即使一个很小的改动，也会引起许多许多数据库更新的操作。
Excessive Data Store Operations
由于使用了Cassandra和Titan,完成这两者之间的数据转换则产生过多的数据存储操作。每一个简单的网络操作都会由于过多的数据读取和写入操作而延迟。原因如下：
Polling
由于时间紧张，第一个模型，并没有实现订阅分发，而是通过周期同步数据，显然这样增加了CPU的使用率。
Lessons Learned
第一个模型的测试能学到一些教训，比如设计更高效的数据模型，减少多余的数据操作，以及更简化的API等等。
PROTOTYPE 2: IMPROVING PERFORMANCE
第二个模型关注于提升性能。所以第二个模型改变了network view architecture,还增加了一个事件通知框架。在第一个模型中，远程操作是造成性能瓶颈的重要原因之一，所以在模型二中，通过减少远程操作的数量和加快远程操作的速度来解决这个问题。改变之后的模型二如下图所示：
RAMCloud Data Store: RAMCloud中文名字应该叫“内存云”，顾名思义，使用内存来代替普通硬盘来存储，从而大大提高存储速度。 Optimized Data Model： 优化向来都是一个复杂的事情。他们新设计了一个data model（中文怎么称呼都不舒服），也不追求数据完整性了，许多更新都是相对独立的，从而大大减少了数据的读写操作，优化了性能。
Topology Cache： 读取拓扑是一个非常耗时的操作，所以新的ONOS将拓扑信息存在高速缓存中，从而提高了读取拓扑的速度。除此之外，他们还构建了一个索引用于更快速地查找数据。构建索引的过程可以在任何时刻由全部的数据生成，但是一般情况下，只有新的ONOS节点接入时，才会读取全部数据，所以从全局来看，这并不会消耗太多时间。
Event Notification： 前面已经提到由于周期获取数据而引起的性能问题，所以一个事件通知机制非常必要。模型二创建了一个实例内部的发布-订阅的事件机制，然后将这个通信系统部署在了Hazelcast上（又一个牛逼的开源软件。）发布订阅模式无需赘述。
Network View API： 关于API的改动，ONOS用自己设计的API取代了生成的Blueprints graph API。Figure4展示了网络视图所包含的内容。ONOS的API主要由以下三个主要部分组成：
- 对底层设施拓扑的抽象描述的接口;
- 处理网络或系统Events（事件）的接口;
- 提供安装流表等信息的接口。
Evaluation
对于模型二的性能主要分为一下三个方面进行测试和评价：
- 对基础网络状态改变的反应
- 对网络事件的反应
- 下发流表路径部署
Basic Network State Changes
网络中状态的改变会阻塞ONOS的操作，直到数据更新完成。所以这一点对整个ONOS的性能影响巨大。
测试案例中使用了三个节点的ONOS集群，连接了81个OpenFlow交换机，组成了一个典型的WAN拓扑，每一个交换机上都有四个活跃的端口。
为测试这个性能，ONOS采用了对比的方式。Table 1中展示了添加一个交换机这个动作所需要的latency。从表中可以看出，使用通用的API，速度最慢。使用自定义的API速度快了很多。因为使用新的Data model仅仅需要一个操作可以完成添加交换机的操作，所以时间从22.2ms下降到了1.19ms。在序列化方面还尝试了Google Protocol Buffers，这个尝试可以将latency下降了0.244ms。最后他们还尝试了使用Infiniband的I/O架构，从而得到了更好的数据。
Reaction to Network Events
这项测试组要用于评价ONOS对网络事件的反应速度等性能。如网路中某一个link down掉之后，ONOS对流量重新路由的过程需要多长时间。这个性能直接关系到SLA（Service-Level Agreement）的性能。
这个实验使用了6个节点的ONOS的集群，数据层面使用mininet模拟了206个软件交换机和416个link。他们将16000条flows添加到网络中，然后关掉网络中的某一个交换端口，则足以导致1000多条flow发生改变，从而重新路由这些flow。其中每一条流有六跳，当某个端口down掉之后，他们都变成7跳的流。
Table 2展示了重新路由进度进行到一半和99%的数据。其中包括从网络时间被捕捉到到下发第一条flow_mod的过程。以及全部Flow_mod都下发。
Path Installation
第三个性能指标测试了ONOS系统的吞吐量。这次测试使用了与第二项性能指标一样的拓扑。但是预下发了15000条静态流表。他们添加了1000条6hops的flow。Table 3展示的测试结果。吞吐量和延时成反比，所以在进程进行到一半的时候吞吐量为18832paths/sec。（好像性能不够好！）
在Prototype2中，ONOS对网络事件的延迟上达到了预期的要求，但是在吞吐量上还没有达到1M path/sec的标准。不过作者们将这个原因归咎与仅仅使用一个ONOS节点来计算路径。如果分布式计算路径效果肯定会更好一些吧。
Demonstration on Internet2
论文作者们将ONOS部署在Internet2上，运行正常。
DISCUSSION: TOWARDS AN OPEN, DISTRIBUTED NETWORK OS
Use Cases
ONOS可以提供的使用案例如下图所示。
后语
ONOS看起来应该是个不错的产品，希望性能和稳定度上能达到不错的水平。在读ONOS论文的过程中，学习到了许多关于分布式计算的知识，也看到了使用开源软件快速开发的模式。我想这些都是我们应该学习的。目前已经有太多优秀的开源软件，合理使用开源软件能够避免重新造轮子的过程。不过我们也从ONOS的例子中看到，并不是使用开源软件叠加就能出来一个非常好的产品，关键的数据模型等方面还是需要研发人员用心设计才能达到一个非常好的效果。希望ONOS能给SDN带来更多市场吧。