ONOS架构之子系统介绍

前言:

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

基础——OSGi:

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设计目标:

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中,一个子系统是一系列服务的集合。

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,它只知道设备的状态而不了解其他的,如怎样跟踪链接状态的信息。

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

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

结语:

本文介绍了ONOS的模块化架构及子系统的结构,并通过具体的两个例子介绍子系统中一些概念的运用情况。希望本文能对各位研究ONOS的研究者有所帮助。

原文发布于微信公众号 - SDNLAB(SDNLAB)

原文发表时间:2015-09-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大数据文摘

硬盘数据恢复的神器有哪些?

27815
来自专栏潇涧技术专栏

Build Android Source Code on Mac

趁着国庆长假,抽出些时间来记录下最近倒腾的一些内容,第一个需要记录的自然是Android源码编译的流程。上班第一天就干了一件事,编译Android 6.0源码,...

1123
来自专栏散尽浮华

linux下syslog-ng日志集中管理服务部署记录

2043
来自专栏JavaEdge

操作系统之设备管理一、I/O管理概述二、I/O硬件组成三、I/O控制方式(重点)四、I/O软件组成五、I/O相关技术六、I/O设备的管理七、I/O性能问题

1.4K6
来自专栏java技术学习之道

常见的Redis面试题及分布式集群讲解

2827
来自专栏一枝花算不算浪漫

Maven项目环境搭建实例.

3987
来自专栏用户2442861的专栏

当你输入一个网址的时候,实际会发生什么

原文:http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/  

1401

如何在Linux上搭建Terraria 游戏服务器?

Terraria是一款二维沙盒游戏,类似于Minecraft(我的世界),允许玩家在开放的世界中探索,构建和战斗。2015年,Terraria开发者宣布支持Li...

5103
来自专栏Android开发指南

1.第三方登陆

3949
来自专栏熊二哥

Maven快速入门

Maven是Java中最为普及的包管理工具,在实际项目中由于依赖的各类jar包非常多,因此概念清晰的处理好各类Jar依赖显得非常重要,接下来通过基础知识,Jar...

5549

扫码关注云+社区