点击上方蓝字关注我们

多年以前，由于基于传统协议的控制平面缺乏灵活性，无法满足多样的业务对数据平面的转发需求，软件定义网络(SDN)被提了出来。业界希望通过一种转控分离、开放解耦的架构，让网络资源能够被上层应用通过标准的API，更加灵活的按需分配。在这种架构下，SDN控制器提供北向接口给上层应用，实现网络资源的动态管理；并通过OpenFlow、NETCONF、SNMP、RESTCONF等南向接口控制底层网络设备数据平面转发行为及设备管理。可见，SDN控制器的架构以及南向接口是SDN的关键技术点，不夸张的说，这两方面是决定整个SDN方案成败的关键因素。在控制器领域，尽管OpenDaylight，ONOS和Ryu等开源系统已经逐渐被各个厂家和用户所接受，但由于南向接口OpenFlow的天然缺陷以及单体架构控制器的日渐臃肿，使得基于传统架构和技术的SDN解决方案，迟迟无法达到最初的设计理念，很难适应业务对网络的需求。

从本期开始，小编将连续出三篇系列文章，以ONOS(开放网络操作系统)为例，详细分析控制器的架构、网络设备可编程接口的发展趋势，解析以去中心化、云原生、协议无关为设计目标的下一代SDN体系结构，并分享星融在这方面的最新实践。

什么是ONOS？

ONOS是领先的开源SDN控制器，被广泛应用于构建下一代SDN / NFV解决方案。它为SDN提供控制平台和管理网络的组件(例如交换机和链接)，并运行网络应用程序提供通信服务。如果您熟悉传统的嵌入式交换机操作系统，则会发现ONOS可以管理整个网络而不是单个设备，可以大大简化多台交换机的软硬件配置管理和部署。如果您熟悉SDN控制器，则应该感到宾至如归，因为ONOS是一个可扩展的模块化的分布式SDN控制器。

接下来我们看看ONOS的设计原则和总体架构。

ONOS的设计遵循四条基本原则：

第一，高可用性，高可扩展性和高性能；

第二，要对网络资源进行高度抽象并简练地表示出来；

第三，要做到协议无关及硬件无关；

第四，网络应用程序的模块化。

图1 ONOS的总体架构

ONOS整体架构可分为三层，分别为：

1、北向接口(NBI)，应用程序使用这些接口来了解网络状态(例如遍历拓扑图、拦截网络数据包)，并控制网络数据平面。

2、分布式核心，负责管理网络状态，并将状态的变化通知给网络应用程序。核心层内部使用的数据库是可扩展的分布式键/值存储数据库Atomix。

3、南向接口(SBI)，由共享协议库和特定设备的驱动程序构成的插件集合。

接下来我们主要介绍下分布式核心和南向接口层如何通过P4runtime协议与设备交互。

分布式核心

ONOS分布式核心由许多子系统组成，子系统负责网络拓扑、主机跟踪、数据包拦截、流编程等的维护和管理。主要的子系统有：

• Device Subsystem- 管理网络设备集群

• Link Subsystem- 管理网络链路

• Host Subsystem- 管理主机及其在网络上的位置

• Topology Subsystem- 管理网络拓扑及实时状态的更新

• Packet Subsystem- 允许应用程序收发业务报文(从/往网络设备)

• Path Subsystem-计算/查找网络设备之间或终端主机之间的路径

• FlowRule Subsystem- 管理网络设备的流表规则

这些服务大多是使用分布式表(映射)构建的，而这些表存储在atomix数据库中，接下来让我们来看下Atomix数据库。

它可以跨一组分布式服务器进行扩展，并实现故障时的容错处理。Atomix是构建分布式系统的通用工具，它是一个基于Java开发的系统，其支持以下功能特性：

• 分布式数据结构，包括maps、sets、trees、counters

• 分布式通信，包括直接消息传递和发布/订阅

• 分布式协作，包括locks、leader elections、barriers

• 管理群组成员

Atomix在ONOS中的一个重要作用是协调ONOS的所有实例，主要体现在两个方面：首先，ONOS具备水平可扩展的能力，在任何时间运行的ONOS实例的数量取决于工作的负载情况和在出现故障时为保证系统可用性所需的备份情况。Atomix group membership原语用于确定可用实例的集合，从而可以检测到已转换的新实例和已失败的现有实例。其次，每个ONOS实例的主要工作是监视和控制网络中物理交换机的子集。ONOS采取的方法是为每个交换机选择一个主实例，只有主实例可以向给定的交换机发出(写入)控制指令，而所有实例都可以监视(读取)交换机状态。这些实例使用Atomix leader-election原语来确定每个交换机的主实例(主控制器)。如果一个ONOS实例发生故障，则使用相同的原语为交换机选择新的主控制器。当有新交换机上线时也采用相同的方法来为其选举主实例。接下来看看ONOS是如何实现对P4Runtime的支持。P4Runtime在传统SDN方案中，OpenFlow一直被看做是控制底层网络数据平面的理想接口之一，但由于硬件支持度不高，在实际部署中并未达到预期效果。P4Runtime作为一种控制器和网络设备之间的数据转发控制接口，和OpenFlow同样具备协议无关性，是一套基于Protobuf和gRPC框架定义的协议。通过P4Runtime协议，SDN控制器可以控制配置支持P4的网络设备。现在P4是数据平面可编程的主流代表，其匹配域和动作域可以任意定制，流表流水线也可以根据网络需求的改变而修改。ONOS是如何支持流水线可变性的呢？首先，ONOS为了解决这个问题，在Core层诸多子系统中横向扩展了一个子系统，叫做PI 框架。PI = Protocol/Program/Pipeline Independent，代表了协议无关、程序无关、以及处理流水线的无关。PI框架是围绕着P4和PSA进行建模的，但PI框架在设计上是面向通用的协议无关思想的，能容纳未来各种协议无关的语言或者协议，目前仅仅是适配到了P4语言。PSA(Portable Switch Architecture)就是P4设备的一个通用架构描述，类似OpenFlow的TTP(Table Type Patterns)。PI架构里包含了一些类、服务和设备驱动的功能描述来建模和控制可编程数据平面，定义了抽象的表项和计数器等等。图2：  PI框架在ONOS中的架构设计首先，最底层是协议插件，有P4 Runtime和gRPC；往上一层是Driver子系统，有P4Runtime、Tofino和BMv2等；最上层是核心层也是PI框架核心所在，它包含了PI模型、FlowRuleTranslation子系统和还有Pipeconf子系统等三大模块。而流水线流表可变性 实现的关键，就是这个FlowRuleTranslation子系统，下文统称为“流表翻译子系统”。PI框架向上既可以支持pipeline无感知的应用，比如之前针对OpenFlow设备编写的程序 ；也可以支持对Pipeline有感知的应用，也就是针对特定的P4程序编写的控制应用。接下来介绍下流表翻译子系统：

图3 FlowRule Translation

PI框架里的流表操作涉及到三个阶段的转换操作，分别对应Pipeliner、Interpreter、P4Info这三个元素，也就是上图中的蓝色部分，是我们pipeconf(.oar)应用里的内容。如果我们使用FlowObjective来下发决策，就会经过Pipeliner把它转换成FlowRule，当然我们也可以直接使用FlowRule。然后P4设备驱动会调用PI框架的FlowRuleTranslation 子系统，借助Pipeline Interpreter把FlowRule转换成PI Table Entry，它是PI框架对一条表项的抽象。最后PI Table Entry会在南向协议插件的P4Runtime Client中借助P4Info转换成P4 Runtime Message这个通信报文，然后在网络中传递给P4设备。如上图3所示，流表操作主要就是三次转换。介绍完分布式核心和P4Runtime，让我们来看看ONOS的发展现状。ONOS的发展现状随着ONOS 2.0版本的发布，当今的ONOS架构提供了一个稳定的基础平台，包含了许多的功能特性，例如简单的第三方应用开发、轻松的分布式集群部署、服务自动导入、已存在大量的第三方应用和拓展组件。但是，ONOS架构当前也同样存在一些限制，比如有限的资源隔离、基于平台的应用仅支持java或JVM-based语言开发；比如应用/服务水平扩展困难、组件无法迁移到平台之外(控制平面功能无法卸载到设备)；再比如与NFV的集成受限且对NFV的支持也同样有限等等。尽管上述限制在本质上都是技术性的，但它们还是限制了ONOS在一些重要的行业场景中的应用，因此我们必须解决ONOS的这些限制。ONF(Open Network Foundation)正在开发一个新的开源架构Micro ONOS(µONOS)以提供真实网络控制、零接触配置和可验证/安全的网络，并使运营商可以完全控制其网络 ，这也是下一代SDN的发展趋势。那么µONOS架构到底如何呢？下篇文章再做介绍。

点点在看行不行