Java教程

OpenDaylight控制器MD-SAL解析

本文主要是介绍OpenDaylight控制器MD-SAL解析,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

一.前言

OpenDaylight开源控制器是业界当前比较流行的SDN控制器,其受到业界关注的主要原因是其具有良好的适应性,可适配不同的南向接口以控制现网各种各样的网络设备,从而使其在未来会有更多的应用场景。除此之外,相比于其它SDN控制器,OpenDaylight引入了基于模型的编程(Model-Driven),并且在软件架构实现中,采用了MD-SAL(Model-Driven Service Abstraction Layer)的中间适配层,以实现北向接口与南向接口的解耦,保证南北向接口独立发展,互不影响。

本文就将重点解析MD-SAL的架构、作用、实现流程及一些关键概念,以协助读者更快掌握基于模型编程的一些关键理念。

二.什么是MD-SAL

图2-1给出了传统的AD-SAL(API Driven-Service Abstraction Layer)与OpenDaylight里MD-SAL架构设计的关键差别。从大的结构上来看,MD-SAL与AD-SAL并没有太多的差别,都是由一些南向/北向的Plugin(SB/NB-Plugin)以及中间的适配层(SAL)组成。适配层主要完成请求的路由过程,也就是将来自北向Plugin的请求发送给合适的南向Plugin,由南向Plugin执行相应的请求。

MD-SAL与AD-SAL设计结构上的差别主要如下:

  • 1.不同于AD-SAL,MD-SAL引入了Data Store的概念,在其提供的Data Store中,存储由北向Application和南向Device所定义的Yang Model数据。

  • 2.北向Plugin、南向Plugin均可对这些Yang Model定义的数据进行存取操作。

  • 3.不同于AD-SAL,在MD-SAL中,北向Plugin与南向Plugin之间的适配由单独的适配Plugin(Adaptation Plugin)来完成。该适配Plugin仅在北向API与南向API不同时才需求。如果北向API与南向API是1:1的关系,那二者就可以通过访问共同的Data Store来实现数据交互,这就避免了AD-SAL中必需的南北向API静态绑定的问题。

引入Data Store及Moel的概念后,MD-SAL所完成的主要工作就是数据提供者(provider)和数据消费者(consumer)之间的连通工作:数据提供者/数据消费者均需向MD-SAL注册;数据提供者在提供数据后,会产生Notification;数据消费者可以向MD-SAL订阅数据,在收到数据发生变化的Noticifaction后,其可以从MD-SAL的Data Store获取数据。

在MD-SAL中的另外一个关键理念是访问Data Store的API是基于Yang Model,通过OpenDaylight提供的Yang Tools Plugin自动生成,这样就避免了AD-SAL中,完全由人工生成对应API可能带来的一些错误风险。

图2-1 MD-SAL与AD-SAL的架构设计差别示意

我们再以图2-1为例来具体说明AD-SAL与MD-SAL的差别,以更好地理解MD-SAL新引进的一些理念:

在图2-1中,NB-Plugin1通过静态绑定访问SB-Plugin1与SB-Plugin2所提供的服务.由于NB-Plugin2所提供的北向接口与SB-Plugin 1/SB-Plugin 2所提供的API不同,就需要通过位于SAL中的Adaptation来访问SB-Plugin1/SB-Plugin2的API。SAL中的请求路由器层(Requesting Routing)则完成北向NB-Plugin与南向SB-Plugin的消息传递。

在MD-SAL场景下,新增了面向服务的北向Yang Model(NB Model Data)和面向设备的南向Yang Model(SB Model Data)。 SB-Plugin/NB-Plugin均通过由Model自动生成的API进行Data Store内数据的存取。NB-Plugin2所需的API转换功能则由另外一个Plugin----Adaptation Plugin完成,该Plugin主要完成Service Yang Model数据向Device Yang Model的数据转换。AD-SAL中原有的消息路由功能在MD-SAL中依然存在。

三.MD-SAL架构

MD-SAL内部实现的抽象架构如图3-1所示。如前所述,其主要分为几个角色:Consumer、Provider、Broker。这三种角色,依据其访问Data Store的不同方式,又分为Binding-Aware和Binding-Independent两大类。角色与类别相组合就可得到如下系列的子系统(subsystem):
1.Provider
a)Binding Independent Providers:与实现语言无关的数据提供者
b)Binding Aware Providers:与实现语言(如Java)相关的数据提供者
2.Consumer
a)Binding Independent Consumer: 与实现语言无关的数据消费者
b)Binding Aware Consumers: 与实现语言(如Java)相关的数据消费者
3.Broker
a)Binding Independent Broker: MD-SAL的核心部分,实现在Provider/Consumer间路由RPC、Notification、Data Change等消息。
b)Binding Aware Broker: 提供与实现语言(如Java)有关的访问Data Store的API

另外还有三个附属的子系统,即:

  • 1)BI Data Repository:存储Yang Model所定义的配置和临时性数据。

  • 2)Binding Schema Repository:配置Java-Yang之间关系和转换规则的库

  • 3)Binding Generator:实现由Yang自动生成对应Java API的函数库。

图3-1 MD-SAL架构示意图

四.MD-SAL Plugin生命周期

MD-SAL本身不提供任何的Model,所有的Model都是由对应的Plugin来提供。MD-SAL只是提供了相应的注册机制以及Plugin之间的连接机制。

在MD-SAL中,所有Plugin,包括定制的协议、应用、适配层及其它都有相同的生命周期,这个生命周期主要分为两大阶段:设计和运行。

在设计阶段,各Plugin主要需要完成如下的事情:

  • 1.设计者需首先确定待设计的Plugin需要消费哪些数据以及其对应的Yang Model

  • 2.引入由上述所依赖Yang Model自动生成的Java API(SAL API)。

  • 3.设计者确定待设计的Plugin准备提供哪些数据和服务,依据此来设计对应的Yang Model,再利用Yang Tools来生成对应的Java API(SAL API)。

  • 4.针对自动生成的Java API,定制实现设计者所需要的功能。与其它辅助的Helper Class一起打包成OSGI对应的Bundle。

图4-1 MD-SAL Plug-in生命周期示意图

图4-1简单列出了整个过程的流程示意:

  • 1.借助于Yang Tools,即可基于设计者定义的Yang Model生成Java API;

  • 2.借助于Maven Build Tools,即可生成“API”、“Plugin”的OSGI Bundle。

  • 3.将这些Bundle集成到Controller中,即可由这些Plugin动态提供相应的功能。

当这些Bundle被动态集成到Controller中时,Plugin的运行阶段就被激活了。它就可以通过MD-SAL与其它的Plugin进行交互,操作Data Store中基于各类Yang Model定义的数据了。具体的流程可通过如下的一个实例(Flow Programmer Service/Plugin)来解释:

在图4-2所示的场景中,该Plugin的运行流程如下(依图中所示步骤)

  • 1.Flow Programmer Service向MD-SAL注册 “Flow Deleted” Notification,该注册过程在OpenDaylight Controll和这个Plugin启动的时候就已完成。

  • 2.“Flow Deleted” OpenFlow包到达Controller。该包是通过Controller与交换机的TCP/TLS连接,由OpenFlow的库函数接收并传递给OpenFlow Plugin.

  • 3.OpenFlow Plugin解析这个数据包,由解析得到的数据包创建一个 “Flow Deleted” Notification. 该Notification实际上是一个不可改变(Immutable)的 “Flow Deleted” DTO(Data Transfer Object),是通过基于Model自动生成的API(Model-generated OF Plugin API)来创建和填充。

  • 4.OpenFlow Plugin将该Notification发送给SAL,由SAL路由到在第1步中注册侦听这个消息的Consumer,也即Flow Programmer Service/Plugiin

  • 5.Flow Programmer Service/Plugin接收到包含Notification DTO的Notification.

Flow Programmer Service/Plugin基于该DTO,通过Model-generated OF Plugin API来获取到被删除的流数据信息。

图片

图4-2: Plugin运行阶段流程示意(Flow Programmer Service)

对于其它Packet-In的场景,也就是由交换机发送数据包给Controller,如ARP或者LLDP数据包,其过程与上述流程基本类似,也是感兴趣的App注册相应的Notification。当Openflow Plugin基于所收到的数据包生成对应的Notification时,该Notification会被发送给SAL,由SAL路由给之前注册的接收者。

五.结语

基于Yang Model的编程是OpenDaylight当前区别于其它SDN控制器的关键特征,也是未来实现网络功能软件化,重点业务集中控制与快速部署的重要技术。OpenDaylight的MD-SAL为基于Yang Model的各类Plugin实现提供了最基础的架构,了解并熟练掌握它是实现基于Yang Model编程的关键环节。MD-SAL还有很多、很深入的内容本文还未涉及,后续对相关内容深入了解后再及时与大家分享。


这篇关于OpenDaylight控制器MD-SAL解析的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!