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解析的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！