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还有很多、很深入的内容本文还未涉及,后续对相关内容深入了解后再及时与大家分享。

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

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Jerry的SAP技术分享

利用CRM中间件Middleware从ERP下载Customer Material的常见错误

下图是我在ERP创建的Material,为其维护了一个Customer Material AOP。

3848
来自专栏Timhbw博客

Hexo-完全免费全平台搭建个人博客(2)-域名主题设置

2017-03-1011:01:58 发表评论 913℃热度 Hexo-完全免费全平台搭建个人博客(1)-整体搭建 上一篇文章把 Hexo 博客整体搭建一遍了...

37912
来自专栏Python小屋

Python版课堂管理系统中使用UDP广播远程关闭客户端程序思路与源码

本文代码来自于我自己使用开发的一套课堂管理系统,界面是用tkinter编写的,教师端界面如图所示: ? 为了防止学生关闭客户端而接收不到屏幕广播,大概3个月前为...

2995
来自专栏Golang语言社区

从零开始创建一个基于Go语言的web service

20个小时的时间能干什么?也许浑浑噩噩就过去了,也许能看一些书、做一些工作、读几篇博客、再写个一两篇博客,等等。而黑客马拉松(HackAthon),其实是一种自...

4449
来自专栏SDNLAB

VXLAN与EVPN的结合使用

EVPN是近几年最热门的网络技术之一。如果你还没听过EVPN,你的网络技能可能已经落伍了,赶紧看看之前的《EVPN简介》吧!EVPN全称是Ethernet VP...

4253
来自专栏Kevin-ZhangCG

什么是事务?事务的四个特性以及事务的隔离级别

2899
来自专栏DeveWork

制作WordPress“带Gravatar头像评论”小工具(集成主题中、含选项)

最近在进一步折腾WordPress 主题的开发,在侧边栏小工具那里想做一个可独立于主题的、类似插件的带头像评论小工具。通过WordPress 官方文档与一些资料...

2406
来自专栏腾讯NEXT学位

那些让编码效率起飞(前端)的工具了解一下

? | 导语 想晚上吃鸡?前端编码效率提升工具了解一下? 一、Bash篇(Mac) iTerm2 iTerm 2 is a terminal emulato...

1743
来自专栏数据和云

关于 Oracle 存储双活配置和实战

作者简介 ? 任小闯 云和恩墨交付技术顾问,6年以上数据库开发维护工作经历,Oracle 10g OCM,Oracle 11g OCP,曾就职于某互联网行业任数...

3938
来自专栏Android源码框架分析

Android进程保活-自“裁”或者耍流氓

本篇文章是后台杀死系列的最后一篇,主要探讨一下进程的保活,Android本身设计的时候是非常善良的,它希望进程在不可见或者其他一些场景下APP要懂得主动释放,可...

4801

扫码关注云+社区