ONOS预热篇之开放分布式SDN操作系统（三）

关于构建ONOS（开放式网络操作系统）的项目专题，是通过性能激发创建的实验性分布式SDN控制平台，满足大型运营商网络的可扩展性、可用性需求。提出了2个版本的ONOS原型，第一个原型版本实现的核心功能是实现一个分布式的但在逻辑上集中的全局网络视图、可扩展性和容错。另一个原型版本侧重于提高性能，基于这两个原型的实践，已形成论文发表《ONOS: Towards an Open, Distributed SDN OS》，确定需要ONOS来支持使用案例，如核心网络流量工程和调度，变成一个在可用的开源SDN社区构建分布式网络操作系统平台。

一、 介绍

近年，学术界和产业界对SDN产生了极大的兴趣。一个开放的、厂商中立的、控制数据平面分离的接口如OpenFlow，允许网络硬件和软件独立发展，并促进了免费的开源的网络操作系统的发展，来更换传统的、价格昂贵的、专有的硬件和商用硬件。通过管理网络资源和提供高层次的抽象和APIs，NOS提供一个开放的平台，它简化了创新有益网络应用的创建并且服务于多种硬件网络。

为了支持大型网络，NOS必须满足可扩展性大、性能高、可用性强的需求。根据网络运营商的讨论，并考虑到服务提供商网络中的流量工程使用，我已确定几个极具挑战性的需求，如图1：

图1：ONOS需求

• 高吞吐量，达到1M requests/s；
• 低延迟，事件进程10-100ms；
• 全局网络状态大小，数据量最高达到1TB；
• 高可用性，99.99%的服务可用性。

为了解决上述问题，已在实验系统上运行开放网络操作系统（Open Network Operating System，ONOS）。ONOS采用一个分布式架构，可达到高可用性和高扩展性，为应用程序提供一个全局的网络视图，即使物理上分布在多服务器，逻辑上也可集中管控。ONOS作为一个开源项目，主要通过下面两个重要原型的开发逐渐发展演变： （1）原型1在分布式平台上为扩展性和容错能力致力于全局网络视图； （2）原型2致力于提高性能，尤其是为事件延迟添加了一个事件通知框架，改变数据存储和数据模型并添加缓存层。

二、 原型1：网络视图、扩展和容错

ONOS最初的挑战是创建一个有用的抽象层、全局网络视图、以及在一个系统上跨多个服务器运行在控制层面的扩展和容错能力。使用开源构件建立的第一个原型是为了快速验证以及更深入探索设计的可能性。根据现有的开源SDN控制器Floodlight开发出第一个原型，使用了Floodlight的部分模块，包括交换机管理、I/O回环、链路发现、模块管理和REST APIs。下图显示了原型1的系统架构：

图2：原型1架构

2.1 全局网络视图

ONOS含有全局网络视图功能，在集群中通过ONOS服务器管理和共享网络状态，并提供一个对应底层网络结构的网络视图模型。在每个ONOS实例中发现的网络拓扑和状态，如交换机端口、链路和主机信息构成全局网络视图，并从全局网络视图中读取应用程序确定转发策略，然后将转发策略依次写到网络视图中，当视图信息发生变化时，将变化消息发送到相应的OpenFlow控制器并下发到在指定的交换机上。初始的网络视图数据模型，采用Titan图形数据库实现、使用Cassandra键值存储实现分布式和可持续性，通过Blue-prints图形API暴露网络状态给应用程序。由于Cassandra具有一致性存储的特性，所以保障了网络试图的最终一致性。

2.2 可扩展性

ONOS的一个关键功能是其可扩展性和容错能力的分布式架构，ONOS运行在多个服务器上，每个作为专属的master OpenFlow控制器，管理网络子集中的交换机。一个ONOS将独立完成对网络及交换机的控制并负责全局网络视图之间的状态变化；当数据平面容量增长或者在控制平面需求增加时，附加的ONOS应用实例可以被添加到ONOS集群中分发控制平面的工作负载，体现了良好的可扩展性。

2.3 容错能力

在ONOS分布式体系结构中，当一个组件或ONOS实例失败时，有其他剩他实例的情况下，允许重新分配，保障系统仍能继续工作。ONOS的架构允许在运行时组件存在于一个实例，但是提供多个冗余的实例，接管之前的失败实例来控制组件。在运行时通过在所有实例中选择一个最优实例来代替初始实例。

一个交换机可以连接多个ONOS实例，但是对于每个交换机来说，只有一个主（master）实例控制。这个master实例独自负责发现交换机信息和控制交换机，当一个ONOS主实例失败时，剩余的实例选择一个新的master来控制交换机。与每个交换机一致性匹配度最高的ONOS实例被选择运行最为master，以确保在所有交换机中，被选择的这个ONOS实例能够负责每台交换机。

用Zookeeper管理交换机和控制器之间的关系，包括监测和反馈ONOS实例是否失败；同时，ONOS实例一定要与Zookeeper保持连接为了成为交换机的master控制器。如果一个ONOS实例与Zookeeper失去连接，另一个ONOS实例将负责控制此交换机。Zookeeper使用一个匹配的协议维持与ONOS很大的一致性，且只要大多数服务器可用，Zookeeper就有很强的容错能力。

2.4 评估

第一个ONOS原型开发历经4个月，在2013年4月在ONS（Open Networking Summit）大会上演示了ONOS原型1，这个演示显示ONOS控制几百个虚拟交换机、使用网络视图下发端到端的流、动态添加交换机和ONOS实例到集群中、针对ONOS实例停机的故障转移以及针对链路响应失败重新添加路由等。总体来说，虽然已经实现了系统的基本功能，但是一些设计选择导致性能和可用性并不好，主要表现是一下几个方面：

• 一致性和完整性。Titan在Cassandra上最终要保持数据存储的一致性以及图形架构的完整性，比如一条链路必须连接两个节点；
• 低性能和可见性。原型1延迟比预期差很多，主要原因在于使用开源软件，虽然很快可以完成开发，但是这些开源软件之间的协调，并不容易。而且ONOS的开发者并不是特别熟悉这些开源代码，导致性能并不高；
• 数据模型问题。使用Titan存储导致所有数据如Port,flow entries等都需要以Vertices存储，需要构建一个索引来查询数据，如交换机数据。当大量节点加入网络时，并发的数据量增加导致索引构建就会成为瓶颈；
• 过多的数据存储操作。Titan和Cassandra间的数据转换会产生过多数据存储操作导致延迟；
• 轮询问题。通过周期同步数据，没有实现订阅分发，增加CPU的使用率。

通过模型1的测试及分析，需要设计更高效的数据模型，减少多余的数据操作，实现订阅分发机制以及简化API等。

三、 原型2：性能提高

原型2主要集中关注于提高ONOS的性能，但是这个导致改变了网络视图架构并添加了事件通知架构，如下图所示：

图3：原型2架构

远程数据操作是原型1最大的性能瓶颈之一，所以在原型2中主要通过尽可能快的远程操作、减少ONOS远程操作量这2种方法解决这个问题。主要涉及的优化主要有：

1.RAM云数据存储。使用内存来代替普通硬盘来存储，从而大大提高存储速度；

2.优化数据模型。新设计了一个data model，更新相对独立，大大减少了数据的读写操作，优化了性能；

3.拓扑缓存。原型1读取拓扑非常耗时，ONOS将拓扑信息存在高速缓存中，从而提高了读取拓扑的速度。除此之外，通过构建索引更快速地查找数据。构建索引可以在任何时刻由全部的数据生成，但是一般情况下，只有新接入ONOS节点时，才会读取全部数据，这不会消耗太多时间；

4.事件通知。上文已提到由于周期获取数据而引起的性能问题，所以引入事件通知机制。原型2创建实例内部的发布-订阅的事件机制，将这个通信系统部署在Hazelcast上；

5.网络视图API。ONOS用自己设计的API取代生成的Blueprints graph API。图4展示了网络视图的内容，ONOS的API主要包涵下面的三个部分：

• 对底层设施拓扑的抽象描述的接口；
• 处理网络或系统Events（事件）的接口；
• 提供安装流表等信息的接口。

图4：使用流表创建数据包路径的连通性请求网络视图

3.1 性能评估

原型2的性能主要在以下三个方面进行测试和评价：

• 基础网络状态改变；
• 对网络事件的反应；
• 路径部署；

3.1.1 基础网络状态改变

当网络中状态发生改变，将进行数据更新操作，会阻塞ONOS的操作，将影响整个ONOS的性能。测试案例中使用三个节点的ONOS集群，连接81个OpenFlow交换机，构成一个典型的WAN拓扑，且每个交换机上都有四个活跃的端口。

ONOS采用了对比的方式，表1展示添加一个交换机后需要的latency，结果可以看出，使用通用的API速度最慢；使用自定义的API，速度提高很多。因为新的Data model仅需要一步就可以完成添加交换机操作，时间上从22.2ms降到1.19ms，延迟减少了很多。在序列化方面由原来的Kryo 尝试使用Google Protocol Buffers，这使延迟时间下降了0.244ms。除此之外，在RAM云集群中还尝试使用Infiniband硬件并优化网络的I/O，性能数据得到了提高。

表1：添加一个交换机的延迟性能测试

3.1.2 对网络事件的反应

对网络事件的反应测试主要是针对ONOS对网络事件的反应速度、端到端的延迟等性能，如网络中某一条链路断掉后，ONOS对流量重选路由的过程需要多长时间，这个性能直接关系到SLA（Service-Level Agreement）的性能。

实验测试使用了6个节点的ONOS集群，数据层面使用Mininet模拟206个交换机和416条链路。将16000条flows添加到网络中，然后关掉交换机的其中一个端口，结果分析显示1000多条flows重新选择路由，其中每一条流有6跳，当某一端口关掉之后，重新选择路由，每一条流将变成7跳。

表2显示重选路由进度进行到一半和99%的数据，从网络时间上捕捉到下发第一条flow_mod及全部flow_mod下发的延迟时间。

表2：重选1000条流的路由延迟时间

3.1.3 路径部署

第三个性能指标测试ONOS系统的吞吐量，测试使用了与对网络事件的反应测试相同的拓扑，但是预先下发15000条静态流表，添加1000条6跳的flows。表3测试结果显示的是路径部署的延迟时间，吞吐量与延迟成反比，在所有流进程进行到一半时吞吐量为18832paths/sec。

表3：路径部署延迟时间

3.2 评估

在原型2中，ONOS对说网络事件的延迟达到了预期的要求，但是吞吐量上还没有达到1M path/sec的标准。不过开发者们将这个原因归咎于仅使用了一个ONOS节点来计算路劲。

四、 实例

2014年3月，论文作者们将ONOS原型2部署在Internet2上运行展示，在大会上展示了（1）ONOS的网络视图；（2）在真实WAN上操作；（3）使用虚拟化硬件和软件交换机；（4）加速ONOS和链路故障转移。图5阐明了ONOS的系统配置：地理上分布5个硬件交换机的主干网络，且每个交换机连接一个模拟的软件交换机。并一个在物理架构上使用OVX（OpenVirteX）创建一个含有205个交换机和414条链路的虚拟网络，并且在印度大学NOC实验室有一个8节点的ONOS集群控制此虚拟网络。

图5：Internet2拓扑和配置Demo

图6显示ONOS发现的拓扑，与图5对比，Los Angeles和Chicago 、 Chicago和Washington D.C之间显示的链路是由OVX虚拟，如下图显示：

图6：ONOS GUI显示发现的交换机和链路拓扑

五、 总结：开放分布式SDN操作系统

建立了两个版本ONOS原型，希望将分布式SDN控制平台发展成为一个更完善的网络操作系统满足大型运营商网络性能和可靠性需求。现在意欲开发多个原型案例帮助推进SDN的发展，其中包括系统APIs、抽象、资源隔离以及调度等。另外，将继续致力于满足性能需求以及开发有用的系统开源版本。

后语：小编在翻译总结的过程中，学习到了很多关于全局网络视图以及分布式管理的知识。ONOS应该是不错的控制器产品，甚至于说是不错的SDN 操作系统。ONOS应用了Titan和Cassandra技术保障了数据的完整性，添加了事件通知框架减少了事件的延迟，使用Zookeeper检测和反馈系统状态，提高了容错能力，采用的分布式框架使扩展能力得到延伸，应用最新的OVX虚拟化网络，以及在性能调优上做了更大的改变和进步，期待ONOS开源版本的发布使用！