如何介绍网络架构 ONOS架构之子系统介绍 - 名人 - 宁波通达娱乐网

如何介绍网络架构 ONOS架构之子系统介绍

2019-02-22 来源:宁波通达娱乐网 编辑:

为了方便灵活性,ONOS采取的是一种模块化结构,一方面能灵活地组织各种模块,容易让开发者扩展出新的模块,同时通过隔离令系统的模块各司其职而不会互相干扰。实际上ONOS是由多个子系统组成,本文将对ONOS中几个比较有代表性的子系统进行介绍。

ONOS由多个模块组合而成,实际上ONOS是基于OSGi bundles实现的。OSGi是一个基于插件式的软件架构,包含OSGi框架和插件。这种插件被称之为Bundle,Bundle可以被动态地加载和卸载,动态升级也就可以被实现了(有点像Erlang的OTP提供的热代码替换,不过OTP和Erlang结合更紧密),通过使用OSGi,Java应用就可以实现良好的模块化。OSGi框架规范提供了一个通用的安全的Java框架,Bundle服务应用的部署、扩展全都依赖于该框架。

OSGi体系架构:

JVM运行在硬件上,JVM上包含Execution Environment、Modules、Life Cycle、Services、Security等内容。事实上,OSGi是一个非常强大,同样非常复杂的框架。ONOS使用了它,能大大提升灵活性。

ONOS的设计目标包含以下几点:
1.代码的模块化:扩展其他组件更容易。
2.可配置性:灵活的配置能实现灵活的架构,同时也能提高可定制性。
3.问题的分离:每个模块负责自身所属的工作内容。如果子系统间有明确的界限,就可以充分利用模块化的好处。
4.协议不可知:ONOS本身和它的应用都不应该被绑定到特定的协议库或实现。

在ONOS中,每个子系统都有自己的源码树,ONOS吸收了Maven的分层POM组织方式,因而每个子项目拥有自己的pom.xml文件。

至于配置方面,因为ONOS使用了Karaf作为其OSGi框架,这使得动态模块载入成为可能,同时Karaf提供了诸如允许使用标准JAX-RS API去开发REST API使其更安全、运行时方便日志级别的设置和容易扩展的CLI等特性。

在ONOS中,Protocol-aware network-facing模块被用于与网络的交互,Protocol-agnostic system core用于跟踪和服务与网络状态的信息等,应用程序与core通过北向API通讯,而network-facing模块使用南向API与core通讯,通过层层分离,实现模块化。

如果我们要使用一种新的协议,我们必须能够构建出一个相应的network-facing模块,作为一个插件在运行时加载至ONOS。

ONOS中,一个子系统是一系列服务的集合。

ONOS定义了几个主要的subsystem,如:

Device Subsystem:管理基础设备的详细清单;

Link Subsystem:管理基础链接的详细清单;

Host Subsystem:管理终端主机和它们在网络中的位置;

还有一些诸如Topology Subsystem、FlowRule Subsystem等子系统。

在ONOS中,一个子系统的组件驻留在三个主要层,并且可以由一个或多个Java接口实现,如图所示:

Provider:

这是ONOS堆栈中最底层的部分。Provider接口通过特定协议的库通向网络,通过ProviderService接口调用core。protocol-aware provider负责使用多种控制和配置协议与网络互动,同时提供特定服务的感知(sensory)数据给core。有时Provider也会收集来自其他子系统的数据,转换为特定服务的数据。

在Provider中还包含Provider Id,一个Provider必须和一个Id关联标识。

一个子系统可能会包含多个Provider,可以指定Provider是主Provider还是从属的Provider。在ONOS的Device Subsystem中能支持多个Provider。

Manager:

Manager是一个驻留在core中的组件,Manager负责接受来自Provider的信息、为上层应用和服务提供服务等工作。

它提供了数个接口:

一个用于给其他组件读取网络状态的北向接口;

一个用于执行管理命令和应用网络状态的AdminService接口;

一个被Provider用于注册的ProviderRegistry南向接口;

一个提供给已经注册的Provider用来对manager收发信息的ProviderService南向接口;

在core中有一个Store的组件,与Manager紧密结合,它主要负责索引、持久化和同步来自Manager的消息。

Application:

应用程序通过AdminService和其他服务接口聚合消息,被Manager使用和操作。应用程序的功能多种多样,比如显示网络拓扑、节点等。

Application和Provider一样要和一个Id关联,这里称之为ApplicationId。被ONOS用来跟踪应用程序的上下文。一个应用程序若想得到一个合法ID,它必须提供它的名字,使用CoreService注册。

1. Provider的职责例子——Device Subsystem

这个子系统负责发现和跟踪组成网络的设备,同时允许操作者和应用程序控制它们。大多数的ONOS核心子系统都依赖于这个子系统所创建和管理的Device和Port对象模型或其provider被用于与网络交互。

Device Subsystem包含以下几个部分:

一个DeviceManager,通过DeviceProviderService接口与多个Provider关联,通过DeviceService接口与多个监听者(listener)关联。

DeviceProviders,每一个都有自己的网络协议库的支持。

一个DeviceStore,跟踪Device模型对象和生成DeviceEvents。

下图是OpenFlow Subsystem的示意图,可以清楚地看到其南向接口和OF控制器的交互过程:

2.Store的职责例子——集群协调

如果我们部署一套多实例ONOS,实际上它是由多个拥有一个唯一的NodeId的实例或节点组成的集群。每一个节点都可以感知网络的一部分状态。本地的状态分段由节点管理,在集群中以事件传播。事件被Store生成,它们通过分布式储存与集群中的所有节点共享。

根据具体服务的需求,储存的内容可以有不同的特征,如强一致性或最终一致性,这使得每个服务的储存根据需求采用合适的分布机制。

目前ONOS主控部分采用Hazelcast以达到强一致性,而Device、Link等部分的管理使用乐观的复制技术辅以gossip协议以确保最终一致性。

如果两个不同节点上的子系统是相同的,子系统将会直接通过Store与另一个进行同步。但是同步的只是一部分的状态,如,对于DeviceStore,它只知道设备的状态而不了解其他的,如怎样跟踪链接状态的信息。

目前除了拓扑管理这部分,其他所有服务都要访问分布式储存。

两个子系统间的同步示意图如下:

精选图文