ONOS白皮书中篇之ONOS架构

    编者按：本系列分三篇对ONOS白皮书进行翻译，接《ONOS白皮书上篇》，本文翻译白皮书中的第5部分ONOS架构，如有不当之处，欢迎指正。

5.ONOS架构

    ONOS从一开始就从服务提供商的角度开展架构设计。具备高可用性、可扩展以及性能良好等基本性能，并且还有强大的北向接口抽象层和南向接口。

ONOS具有下述核心功能：

 ■分布式核心平台，提供高可扩展性、高可用性以及高性能，实现运营商级SDN控制平面特征。ONOS以集群方式运行的能力使得SDN控制平台和服务提供商网络具有类似Web风格的灵活性。

 ■北向接口抽象层/APIs，将网络和应用与控制、管理和配置服务的发展解耦。这个抽象层也是SDN控制平台和服务提供商网络具有类似Web风格灵活性的因素之一。

 ■南向接口抽象层/APIs，通过插件式南向接口协议可以控制OpenFlow设备和传统设备。南向接口抽象层隔离ONOS的核心功能和底层设备，屏蔽底层设备和协议的差异性。南向接口是从传统设备向OpenFlow白牌设备迁移的关键。

 ■软件模块化，让ONOS像软件系统一样，便于社区开发者和提供者进行开发、调试、维护和升级。

5.1分布式核心

    ONOS可以作为服务部署在服务器集群上，在每个服务器上运行相同的ONOS软件，因为对称性部署是一项很重要的设计考量，可以在ONOS服务器发生故障时可以快速地进行故障恢复。而且网络运营商可以在不发生中断的情况下添加服务器，轻松地扩容控制平面处理能力。ONOS实例协同工作形成被其它网络和应用视作单一的平台。应用和网络设备无需知道是和单一的ONOS实例交互还是和多个ONOS实例交互。这一特征实现了ONOS的可扩展性，可以无缝扩充ONOS容量。就是分布式核心平台所具有的特色性能。

    分布式核心提供实例间的通信、状态管理，领导选择等服务。事实上，多个实例表现为一个逻辑实体。通过使用Publish/Subscribe模型中的高速消息，ONOS实例可以将更新信息快速通知给其他实例。ONOS内部设计恢复协议来处理因为实例故障而引起的更新丢失。ONOS使用多种机制管理实例的操作状态，并且每种机制与状态类型一一对应。其中典型的例子就是应用意图、拓扑数据库和流表，每个都有独一无二的规模、读/写模式和持久化需求。一个领导选择服务确保交换机有且只有一个主实例。同时，消息通信、状态管理和领导选择机制保证了集群的高吞吐量、低时延以及高可用性。

    这意味着什么？对设备而言，只有一个主ONOS实例，如果这个主实例出现故障，则连接另一个实例，无需重新创建新实例并重新同步流表。对于应用而言，可以通过网络图形抽象层持续获取网络的视图。此外，实例故障和数据平面的故障对应用来说是透明的，这样可以极大地简化应用开发和错误处理。

    从业务角度看，ONOS提供了一个高可用的环境，应用可以有效地避免遭遇网络相关的停工期。而且，服务提供商可以随着网络的发展轻松地扩容控制平面容量，并且不会产生网络中断。通过相同的机制，网络运营商按照实例下线、更新、上线的步骤能够实现零当机更新软件。

总而言之，分布式核心是ONOS架构特征的关键，使得SDN控制平面达到电信级要求。

5.2北向抽象层

    ONOS架构中有两个强大的北向抽象层：意图框架和全局网络视图。意图框架屏蔽服务运行的复杂性，允许应用向网络请求服务而不需要了解服务运行的具体细节，这就意味着网络运营商和应用开发者可以进行高级编程。他们可以轻松地提出意图：一个策略声明或连接需求。

意图框架示例：

 ■在主机A与B之间建立连接

 ■在交换机Y与Z之间建立带宽为z的光通道

 ■阻止主机A与B通信

    意图框架处理所有应用的请求，判断可以满足哪些应用，解决应用之间的冲突，执行管理者的策略，对网络编程提供请求的功能，交付请求的服务给应用。

    一个意图转化为多个目标。例如，一个连接2个主机的意图转化为2个目标，各提供一个方向的流。将意图转化的目标编译成指令发送给网络设备，整个流程按照网络运维人员指定的策略进行。从某种程度上说这个方法可以解决意图之间的冲突。

    全局网络视图为应用提供了网络视图，包括主机、交换机以及网络相关的状态参数，如利用率。应用可以通过APIs对网络视图进行编程，一个API可以为应用以网络图的形式提供网络视图。基于网络图可以进行以下工作：

 ■创建一个简单的应用，当该应用获得网络全局视图后计算最短路径。

 ■通过监控网络视图和编程改变路径调节负载（流量工程）最大化网络利用率。

 ■将流量从正在升级或因病毒被隔离的网络中引导出来。

    确切的说，北向接口抽象层和APIs将应用与网络细节进行隔离。而且也可以隔离需要了解网络事件（如链路中断）的应用和其它应用。反而言之，将网络操作系统与应用隔离，网络操作系统可以管理来自多个、竞争应用的请求。从业务角度看，提高了应用开发速度，允许网络改变并且保证应用不会当机。

 5.3南向接口抽象层

    南向抽象层由网络组件构成，例如交换机、主机或是链路。ONOS的南向抽象层将每个网络组件表示为通用格式的对象。通过这个抽象层，分布式核心可以维护网络组件的状态，并且不需要知道底层设备的具体细节。总之，分布式核心可以实现南向接口协议和设备无感知。这个网络组件抽象层允许添加新设备和协议，以可插拔的形式支持扩展，插件根据规格映射（或翻译）通用网络组件描述或操控设备，反之亦然。所以，南向接口确保ONOS控管多个不同的设备，即使它们使用不同的协议（OpenFlow、NetConf等）。

    南向接口的分层结构如图3所示，最底层是网络设备，ONOS通过协议与设备连接，协议细节被网络组件插件或适配器屏蔽。事实上，南向接口的核心是在不知道具体协议细节和网络组件的条件下维护网络组件对象（设备、主机、链路）。通过适配层API，分布式核心可以与网络组件对象状态保持一致，适配层API将分布式核心与协议细节和网络组件相隔离。

南向抽象层的主要优势包括：

 ■用不同的协议管理不同的设备，不会对分布式核心造成影响。

 ■扩展性强，可以在系统中添加新的设备和协议。

 ■轻松地从传统设备转移到支持OpenFlow的白牌设备。

5.4软件模块化

    软件模块化是ONOS一大特征，基于软件的形式可以很方便地进行添加、改变和维护。ONOS团队在模块化方面投入很多心血，务必让开发者可以简单快捷地操作软件。

    何为模块化？将软件拆分为若干组件以及组件之间的交互。从如下的示意图所示，ONOS的主体架构是围绕分布式核心的分层架构。所以，从宏观结构上说，北向接口与南向接口API将应用、分布式核心和适配层相互隔离，可以独立添加新的应用和协议适配器。

    同样，从具体细节来看，分布式核心内部的子结构也能体现模块化特征，分布式核心的存在价值就是约束所有子系统的规模并保证模块的可拓展性。此外，连接不同模块的接口是至关重要的，允许模块不依赖其他模块独立更新。这样就可以不断更新算法和数据结构，并且不会影响整体系统或是应用。

    显然，ONOS很重视接口，因为接口可以促进模块业务和职责的分离，尽量使子系统之间的交互更为自然、简单。这一特点是确保软件稳定更新的关键。例如，尽量提供南向API的抽象程度，避免将不同协议的偏差传递到上层，并且强化分布式核心而不是适配层来创建网络模型对象。

    ONOS源代码的树形结构不仅仅为了遵循而是要加强这些结构原则。合理控制模块大小并且模块之间保持适当依赖形成一个非循环的结构图，模块之间通过API模块相互关联，正如下图所示。

软件模块化的好处归纳为以下几点：

 ■保证架构的完整性和连贯性

 ■简化测试结构，允许更多的集成测试

 ■减小系统某部分改变的负面影响，从而降低维护难度

 ■组件具有可拓展和可定制的特性

 ■规避循环依赖的情况

本文来源于SDNLAB，可点击此阅读原文。如果您对本文感兴趣，可参与以下互动方式与作者近距离交流。

如果您对本文感兴趣，可参与以下互动方式与作者近距离交流。

（1） 微博（http://weibo.com/sdnlab/）

（2） 微信(账号：SDNLAB)

（3） QQ群

    SDN研究群（214146842）

    OpenDaylight研究群（194240432）