Brocade China Blog

OpenDayLight实战入

by JohnnyTang on ‎11-19-2015 10:30 PM (1,249 Views)

 

   今天讲的是SDN的实战,但说到实战,可能还是牵强了点,SDN技术代表了某种意义上的未来,所以现在来说,并不是大规模应用的阶段。所以,我们可以去设想SDN会在时候才会大规模应用,首先在那些网络位置,哪些应用上可以开始SDN的工作,今天我们讲讨论一下关于SDN开发的初级话题,如何来构建一个SDN应用。我讲的可能并不是特别精确的,希望大家谨慎地听吧。

 

   我大概归纳了三个approach,位于不同的api level,我们先来看一看opendaylight这个SDN控制器的架构图,相信大家一定很熟悉。

1.jpg

 

  南向接口,odl核心和北向接口。我们可以分别在三个位置进行编程

 

  对于第一种方法:

  •  网络复杂度不高,网元单一,拓扑固定,服务固定
  •  服务抽象再向上提供服务的必要性不大
  •  面向特定的网元管理协议的编程或许就可以解决问题

   对于这样的应用,我们或许可以抛开SDN控制器,或者自己就作为一个小型的解决特殊问题的控制器,譬如,你有这样的一个应用,你通过外围应用得知道某个用户违反了某个策略,需要下一条流表项来阻止他,而你管理的网络规模较小,譬如你就可以仅仅对某一台汇集交换机进行操作就可以完成这个任务,那么这样的话你的确不需要一个很大的SDN控制器来帮你做这个事情,譬如你可以利用of的lib库直接编程就可以了,那这段代码只是主要代码的一个业务调用,去开通或者关闭某个用户的接入。

 
2.jpg

   

   

 

   在这个应用中,我们就可以这样做,当dpi检测到入侵或者策略违反,就直接下个OpenFlow流就可以,这个是第一种方法。一般来说,在这个层面编程就更像是EMS针对网元级别的编程,你可以使用各种特定网络设备支持的协议来编程:openflow, ovsdb, snmp ,soap, netconf ...当你的网络变大,要实现的业务变得更多的时候,这里就像我们用单片机逻辑开发解决问题比较麻烦时,我们可以基于操作系统来编程。反正操作系统提供了各种的驱动和HAL,我们去系统调用就可以了。于是我们引入了SDN控制器,由它去管理各种南桥接口,同时向北向提供各种类似user space的api,一般而言,我们的应用就focus在这个层面。

上次我们在南京的时候,做了一些小例子,其实这些例子(基于odl)在opendaylight网站上都有https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:User_Guide,譬如这个页面可以看到对于openflow的各种处理。当然,我们今天的SDN编程主要还是基于ODL来讲的,所以,除了OpenFlow的处理,其他的北向api支持是依赖于ODL本身的https://git.opendaylight.org/gerrit/#/admin/projects/

 

4.jpg

   

   

   一般而言,ODL内部模块是基于OSGi + MD-SAL开发的,所以,你可以选择性去安装你所需要的模块来提供更多的北向api,对于odl你也可以通过这个地址去得到当前北向api的能力集.http://[SDN controller's ip address]/apidoc/explorer/index.html,里面会有对api的基本描述和参数定义,当然,如果需要对语义进一步的了解,需要查看更进一步的文档。odl的user guide里面有对每个比较大的project的介绍和使用说明,这是第二种方法。

那第三种方法,就是要到controller内部编程了。这个目前来说,我觉得实际需求不是很大,当然,只是我个人的观点。正如大家看到的https://jenkins.opendaylight.org/

6.png

   

 

   在ODL内部已经有了很多很多的可以引用的东西,如果现有的模块可以满足你的需求,那就直接使用。我们知道,odl的内部开发主要是基于yang model的md-sal来编程的,那么对于这样的编程,很多时候并不一定是编程实现本身的价值,更主要的是对于网络问题的语义理解和模型定义。对于通用性很强的问题都会有yang model 的rfc定义,一般的开发人员是不太可能去做这样的工作的。

当然,去做ODL内部的编程肯定也是有意义的,譬如可以加强的ODL本身的理解。对于一些特殊的网络设备和环境以及业务逻辑,自己去定义一个yang model,然后进行开发也是可以的。

  • 网络复杂,网元众多,类型各异
  • 对于网络管理的冗余性和高可用性要求高
  • 服务需要再次抽象
  • 实现服务模块的可重用性

  这个是第三种方法,我大概就是总结了这三种approach吧。

  目前来说,对于一般开发者而言,我觉得第二种方法可能是最好的切入,也更有可能得到比较理想的结果。我最后再来讲讲第二种方法。

3.jpg

 

  譬如这个是brocade的一个基于SDN controller的商业应用,换成其他的业务逻辑都是可以的,整个框架是类似的。
1)通过其他独立系统去感知网络:这里是通过sflow去获得流量信息;
2)送到analytical节点去做分析;
3)如果trigger业务逻辑,在这个例子里是预先定义的流量模型,譬如你某种流量超出了预定值;
4)调用北向api去使能网络
  这是一个通用的架构模型,今天的分享到此结束。

 

本文转自SDNLAB