SDN之NOS概述

网络操作系统（NOS）是一个用于配置和控制白盒交换机网络的平台，其核心职责是监控交换机的状态（例如，检测端口和链路故障），维护反映当前网络状态的拓扑的全局视图，并使其对控制应用（Control Apps）可用，控制应用依次“指示”网络操作系统根据它们提供的服务来控制通过底层交换机的数据包流量。本文通过ONOS来介绍NOS的总体结构。

ONOS架构

ONOS的总体架构如图1所示：

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

2、分布式核心，负责管理网络状态，并将有关该状态的相关更改通知应用程序。核心的内部是一个可扩展的键/值对存储Atomix。

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

图1

图1所示，该设计是高度模块化的，将给定的部署配置为包含所需的模块子集。我们需要着重注意三点。

首先是NBI的范围，ONOS可以被看作一个操作系统，无论是控制程序还是人工操作，对底层硬件的所有访问均由ONOS进行。这意味着所有北向API的联合必须足以配置、操作和控制网络。例如，NBI分别包括用于配置和操作的gNMI和gNOI。这也意味着NBI包括一个用来了解底层网络状态变化的拓扑API，以及一个用于控制底层交换机的FlowObjective API。

虽然我们通常将运行在网络操作系统之上的应用程序描述为实现网络控制平面，但实际上，运行在ONOS上的各种应用程序都可以实现从监视网络状态的GUI到传统CLI的所有功能。

ONOS上的应用程序包括零接触管理平面，它提供添加到网络的新硬件，从而确保安装了正确的软件、证书、配置参数和管道定义。如图2所示，ONOS没有固定的NBI：ONOS上可能运行着多个应用程序和服务层。零接触配置是ONOS不同于传统操作系统的一个重要方面，ONOS目前在单个信任域中运行。

图2

其次，ONOS将控制应用程序要施加在网络上的行为的抽象规范映射到需要与网络中每个交换机通信的具体指令上。应用程序可以根据不同的需求选择不同的方式，网络范围内、与拓扑无关的应用可以选择使用高级Intent，需要更精细控制的可以使用Flow Objectives，它是以设备为中心的编程结构。应用程序使用它们来控制固定功能和可编程管道。

图3

最后，信息在ONOS可以同时“向下”和“向上”流动。我们通常使用ONOS NBI来控制网络的应用程序，但南向插件也会将有关底层网络的信息传递到ONOS核心，包括拦截数据包、发现设备及其端口、报告链路质量等等。ONOS核心与网络设备之间的这些交互由一组适配器（例如OpenFlow、P4Runtime）处理，这些适配器隐藏了与设备进行通信的细节，从而使ONOS核心及其上运行的应用程序与各种网络设备隔离开来。例如，ONOS被用于控制黑盒交换机、白盒交换机、光学设备和蜂窝基站。

分布式核心

ONOS核心由许多子系统组成，每个子系统负责网络状态的特定方面（例如拓扑、主机跟踪、数据包拦截、流编程）。每个子系统维护其自己的服务抽象，实现负责在整个集群中传播状态。

许多ONOS服务是使用分布式表（映射）构建的，而这些表又是使用分布式键/值存储实现的。任何研究过现代云服务设计方式的人都会对它很熟悉，它可以跨一组分布式服务器进行扩展，并实现Raft共识算法以在出现故障时实现容错。

ONOS使用Atomix作为其存储，Raft是Atomix的核心算法，提供了丰富的编程原语集，ONOS使用这些原语来管理分布式状态，并使控件应用更易于访问。

Atomix Primitives

前面介绍了Atomix作为键/值存储的情况，但Atomix也可以描述为构建分布式系统的通用工具。它是一个基于Java的系统，其中包括对以下内容的支持：

• 分布式数据结构，包括地图、集合、树和计数器。
• 分布式通信，包括直接消息传递和发布/订阅。
• 分布式协调，包括锁定和障碍等。
• 管理群组成员。

例如，Atomix包含AtomicMap和DistributedMap原语。两者都使用额外的方法扩展了Java的Map实用程序。在AtomicMap的情况下，原语使用乐观锁执行原子更新，从而确保所有操作都是原子的（并且映射中的每个值都有单调递增的版本号）。相反，DistributedMap原语支持最终一致性。这两种原语都支持对相应映射更改的基于事件的通知。客户端可以通过在映射上注册事件侦听器来侦听插入/更新/删除的条目。

Atomix有助于协调ONOS实例，主要体现在两个方面：

首先，作为一种水平可扩展的服务，在任何给定时间运行的ONOS实例的数量取决于工作负载和在出现故障时保证可用性所需的复制级别。Atomix组成员原语用于确定可用实例的集合，从而可以检测到已转换的新实例和已失败的现有实例。

其次，每个实例的主要工作是监视和控制网络中物理交换机的子集。ONOS采取的方法是为每个交换机选择一个主实例，在该实例中，只有主实例向给定的交换机发出（写入）控制指令。所有实例都可以监视（读取）交换机状态。然后，这些实例使用Atomix leader-election原语来确定每个交换机的主交换机。如果ONOS实例发生故障，则使用相同的原语为交换机选择新的主控制器。新交换机也采用相同的方法。

服务

ONOS通过定义一组核心表（映射）构建在Atomix上，这些表又被打包为一组可用于控制应用程序（和其他服务）的服务集合。表和服务是看待同一事物的两种方式：一种是键/值对的集合，另一种是应用程序和其他服务与这些键/值对交互的接口。图4描绘了各个层，其中中间的三个组件（拓扑、链接和设备）是示例ONOS服务。

图4

注意，图4中的拓扑服务没有关联的映射，而是间接访问Link和Device Services定义的映射。拓扑服务将生成的网络图缓存在内存中，这为应用程序提供了一种低延迟、只读的方式访问网络状态。拓扑服务还计算图的生成树，以确保所有应用程序都看到相同的广播树。

总的来说，ONOS定义了一个服务的互连图，图4仅显示了一个很小的子图。图5对该视图进行了扩展，说明了ONOS核心的其他方面。其中有几点需要注意。

图5

第一，路径服务依赖于拓扑服务(跟踪网络图)和主机服务(跟踪连接到网络的主机)，应用程序可以通过查询了解主机与主机之间的端到端路径。注意，箭头方向代表依赖关系，但是如图5所示，信息在两个方向上流动。

第二，主机服务有一个北向的接口和一个南向的接口。路径服务使用其北向接口读取与主机相关的信息，而主机位置提供程序使用其南向接口写入与主机相关的信息。主机服务本身只不过是Atomix映射的包装程序，用于存储有关主机的信息。

第三，主机位置提供程序监听网络流量（例如，拦截ARP、NDP和DHCP包），以了解连接到网络的主机，然后将其提供给主机服务。主机位置提供程序反过来依赖包服务来帮助其拦截那些包。数据包服务为其他ONOS服务定义了一种与设备无关的方式，以指示底层交换机捕获并将选择的数据包转发到控制平面。ONOS服务还可以使用数据包服务将数据包注入数据平面。

第四，尽管图5中所示的服务图旨在发现网络拓扑，但在许多情况下，拓扑是固定的，并且是预先知道的。当控制平面为特定拓扑定制时，通常会发生这种情况。对于这种情况，拓扑服务从依赖关系图中位于其上方的控制应用程序（或高级服务）接受配置指令。ONOS包括这样的配置服务，称为Network Config，如图6所示。NetworkConfig依次接受来自人工操作员或自动编排器的配置指令，例如图2中的示例ZTP控制应用程序。

图6

我们刚才介绍的一系列示例(图4、5和6)说明了如何从各个部分构建ONOS的基础。为了完整起见，下面总结了最常用的ONOS服务:

主机：记录连接到网络的终端系统（计算机或虚拟机）。由一个或多个主机发现应用程序填充，通常通过拦截ARP、NDP或DHCP包来填充。

设备：记录特定于基础设施设备的信息（交换机、ROADM等），包括端口。由一个或多个设备发现应用填充。

链接：记录连接基础设施设备/端口的链接属性。由一个或多个链接发现应用程序填充（例如，通过发送拦截LLDP数据包）。

拓扑：使用图形抽象表示整个网络。它构建在“设备和链接”服务之上，并提供了一个由基础设施设备作为顶点，基础设施链接作为边而组成的连贯图形。

主控：使用Atomix领导选举原语，以选择集群中的哪个ONOS实例成为基础设施设备的主设备。在ONOS实例发生故障（例如服务器电源故障）的情况下，可确保为其他的设备尽快选出新的主设备。

集群：管理ONOS集群配置。它提供有关Atomix集群节点以及所有对等ONOS节点的信息。Atomix节点构成了实际的集群，这是达成共识的基础，而ONOS节点实际上仅仅是用于将控制逻辑和I / O扩展到网络设备的客户端。

网络配置：规定有关网络的元信息，例如设备及其端口、主机、链接等。提供有关网络的外部信息以及ONOS核心和应用程序该如何处理网络。由协调器应用程序、ZTP控制应用程序或操作员手动设置。

组件配置：管理ONOS核心和应用程序中各种软件组件的配置参数。此类参数（即如何处理外部流规则、地址或DHCP服务器、轮询频率等）允许定制软件的行为。由操作员根据部署需要进行设置。

数据包：允许核心服务和应用程序拦截数据包（输入数据包）并将数据包发送回网络。这是大多数主机和链接发现方法（例如ARP、DHCP、LLDP）的基础。

流规则：提供以设备为中心的匹配/操作对，用于对设备的数据平面转发行为进行编程。它要求根据设备的表管道结构和功能来组成流规则条目。

流目标：提供以设备为中心的抽象，以与管道无关的方式对设备的转发行为进行编程。它依靠Pipeliner子系统来实现与表无关的流目标与表特定的流规则或组之间的映射。

几乎每个应用程序都要使用上述服务，因为它们提供了有关网络设备及其拓扑的信息。

北向接口

ONOS NBI有多个部分。首先，对于ONOS的给定配置中包含的每个服务，都有一个对应的API。例如，图1所示的“ Topology”接口正是图4所示的拓扑服务提供的API。其次，由于ONOS允许应用程序定义和使用自己的Atomix表，因此可以将Atomix编程接口视为ONOS NBI的另一部分。第三，ONOS NBI包括gNMI和gNOI。这些是独立于ONOS定义的标准化接口，作为ONOS NBI的一部分得到支持。最后，ONOS提供了一组用于控制底层交换机的接口。

图1描绘了流规则和流目标。流目标共有三种类型：过滤、转发和下一步。过滤目标根据流量选择器确定是否允许流量进入管道；转发目标通过将数据包中的选择字段与转发表进行匹配来确定允许哪些流量流出管道；下一步目标指出应该对流量进行什么样的处理，例如报头如何重写等。

过滤→转发→下一步

过滤阶段可能会允许匹配特定MAC地址、VLAN标签和IP地址的数据包进入管道；转发阶段在路由表中查找IP地址；下一个阶段将根据需要重写标头，并将数据包分配给输出端口。

挑战在于如何将这些与管道无关的目标映射到相应的管道相关规则上。在ONOS中，此映射由流目标服务管理，如图7所示。

图7

在内部，流目标服务被组织为特定于设备的处理程序的集合，每个处理程序都使用ONOS设备驱动程序机制实现。抽象流目标指令应如何映射到流规则操作实现的设备驱动程序行为称为Pipeliner。

Pipeliner能够将流目标映射到流规则和P4编程的管道上。图7给出的示例展示了前一种情况，其中包括到OpenFlow 1.3的映射。在后一种情况下，Pipeliner利用了Pipeconf，该结构维护了以下元素之间的关联：

1.每个目标交换机的管道模型。

2.需要特定于目标的驱动程序才能将流指令部署到交换机。

3.特定于管道的转换器，用于将流目标映射到目标管道中。

在编程上，流目标是一种数据结构，与相关的构造函数例程打包在一起。控制应用程序构建目标列表，并将其传递给ONOS以执行。以下代码示例显示了为指定通过网络的端到端流而构建的流目标。将它们应用于底层设备的过程是在其他地方完成的，并未包含在示例中。

上面的示例创建了“下一个目标”和“转发目标”，下一个目标对流程应用进行处理。Treatment设置了输出端口，但也可以选择将originalTreatment传入的参数应用到createFlow。

南向接口

ONOS灵活性的关键在于其能适应不同的控制协议。控制交互和关联抽象是受OpenFlow协议启发的，但ONOS旨在确保核心（以及在核心之上编写的应用程序）与控制协议的细节隔离。

本节将仔细研究ONOS如何适应多种协议和异构网络设备。

Provider 插件

ONOS定义了一个南向接口（SBI）插件框架，其中每个插件都定义了一些南向（面向网络）的API。插件被称为Protocol Provider，充当SBI与底层网络之间的代理，其中没有限制每个插件可以使用什么控制协议与网络通信。Provider在SBI插件框架中注册，并开始充当在ONOS应用程序和核心服务（上方）和网络环境（下方）之间传递信息和控制指令的管道，如图8所示。

图8

图8包括两种通用的Provider插件。第一种是特定于协议的，OpenFlow和gNMI就是典型的例子，这些Provider中的每一个都有效地将API与实现相应协议的代码捆绑在一起。第二种类型（图中的示例为 DeviceProvider、 HostProvider和 LinkProvider）使用其他一些ONOS服务与环境间接交互。

设备驱动程序

除了将核心与协议规范隔离之外，SBI框架还支持将设备驱动程序插件作为一种机制，将代码（包括Provider）与特定于设备的变体隔离开来。设备驱动程序是模块的集合，与Protocol Provider一样，设备驱动程序选择实现这些功能的方式没有任何限制。设备驱动程序也可以作为ONOS应用程序部署，从而可以动态安装和卸载。

可扩展的性能

ONOS是一个逻辑上集中的SDN控制器，因此，必须确保它能够及时响应可扩展的控制事件。面对故障，它也必须保持可用性。下文介绍了ONOS如何扩展以满足这些性能和可用性要求。其中ONOS代表集中式网络控制的最新技术：

• 规模：ONOS最多支持50个网络设备；5000个网络端口；5万用户；1M路由。
• 性能：ONOS每天最多支持1万次配置操作；每秒500k流量操作（持续）；1k拓扑事件/秒（峰值）；50ms检测端口/切换事件；5ms检测端口/关闭事件。

生产部署至少要运行三个ONOS实例，每个实例都在32核/ 128GB-RAM服务器上运行，并使用Kubernetes作为Docker容器部署。每个实例都捆绑了一个相同（但可配置）的核心服务、控制应用程序和protocol provider，其中ONOS使用Karaf作为其内部模块化框架，该捆绑包还包括Atomix。

ONOS的重构也在进行中，以便更紧密地与微服务架构保持一致。名为µONOS的新版本利用了ONOS的现有模块化功能，但独立包装和扩展了不同的子系统。尽管原则上本文介绍的每个核心服务都可以打包为独立的微服务，但是这样做太细粒度了，不切实际。相反，µONOS采用以下方法。首先，它将Atomix封装在自己的微服务中。其次，它将每个控制应用程序和南向适配器作为单独的微服务运行。第三，它将核心划分为四个不同的微服务：（1）导出网络图API 的拓扑管理微服务；（2）导出P4Runtime API的控制管理微服务；（3）导出gNMI API 的配置管理微服务；（4） 导出gNOI API 的操作管理微服务。

原文链接：

https://sdn.systemsapproach.org/onos.html

出处：《软件定义的网络：一种系统方法》

作者：Larry Peterson，Carmelo Cascone，Brian O'Connor和Thomas Vachuska

来源：

https : //github.com/SystemsApproach/SDN

责任编辑：边小白、大脸肥飞猫