嘉宾介绍
--------------------------------------------------------------------------
许马门是Brocade资深架构师，首席软件工程师，具有20余年的工作经验，曾就职于Juniper及多家创业公司，精通网络技术和SDN实战。
分享正文
--------------------------------------------------------------------------
今天讲的是SDN的实战,但说到实战,可能还是牵强了点，SDN技术代表了某种意义上的未来，所以现在来说,并不是大规模应用的阶段。所以,我们可以去设想SDN会在时候才会大规模应用,首先在那些网络位置,哪些应用上可以开始SDN的工作，今天我们讲讨论一下关于SDN开发的初级话题，如何来构建一个SDN应用。我讲的可能并不是特别精确的,希望大家谨慎地听吧。
我大概归纳了三个approach，位于不同的api level，我们先来看一看opendaylight这个SDN控制器的架构图,相信大家一定很熟悉。
南向接口,odl核心和北向接口.我们可以分别在三个位置进行编程
对于第一种方法:
1)网络复杂度不高,网元单一,拓扑固定,服务固定
2)服务抽象再向上提供服务的必要性不大
3)面向特定的网元管理协议的编程或许就可以解决问题
对于这样的应用,我们或许可以抛开SDN控制器,或者自己就作为一个小型的解决特殊问题的控制器，譬如,你有这样的一个应用,你通过外围应用得知道某个用户违反了某个策略，需要下一条流表项来阻止他，而你管理的网络规模较小，譬如你就可以仅仅对某一台汇集交换机进行操作就可以完成这个任务，那么这样的话你的确不需要一个很大的SDN控制器来帮你做这个事情，譬如你可以利用of的lib库直接编程就可以了，那这段代码只是主要代码的一个业务调用，去开通或者关闭某个用户的接入。
在这个应用中,我们就可以这样做,当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/
一般而言, 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/
在ODL内部已经有了很多很多的可以引用的东西，如果现有的模块可以满足你的需求，那就直接使用。我们知道，odl的内部开发主要是基于yang model的md-sal来编程的，那么对于这样的编程，很多时候并不一定是编程实现本身的价值，更主要的是对于网络问题的语义理解和模型定义。对于通用性很强的问题都会有yang model 的rfc定义，一般的开发人员是不太可能去做这样的工作的。
当然，去做ODL内部的编程肯定也是有意义的，譬如可以加强的ODL本身的理解。对于一些特殊的网络设备和环境以及业务逻辑，自己去定义一个yang model，然后进行开发也是可以的。
1)网络复杂,网元众多,类型各异
2)对于网络管理的冗余性和高可用性要求高
3)服务需要再次抽象
4)实现服务模块的可重用性
这个是第三种方法，我大概就是总结了这三种approach吧。
目前来说，对于一般开发者而言，我觉得第二种方法可能是最好的切入，也更有可能得到比较理想的结果。我最后再来讲讲第二种方法。
譬如这个是brocade的一个基于SDN controller的商业应用，换成其他的业务逻辑都是可以的，整个框架是类似的。
1）通过其他独立系统去感知网络：这里是通过sflow去获得流量信息；
2）送到analytical节点去做分析；
3）如果trigger业务逻辑，在这个例子里是预先定义的流量模型，譬如你某种流量超出了预定值；
4）调用北向api去使能网络
这是一个通用的架构模型，今天的分享到此结束。
Q&A
SDN实战团提问：
上海-HL
Q1：假如控制器需要对包进行实时的相应，那应该采取第二种方法还是第三种方法？
A1：这个问题，要看是什么包了，假如是对于SDN控制器核心很关键的包，譬如openflow packet-in，那当然是在odl内部实现。
Q2：对于packet-in需要采用第三种方法？
A2：是的，可以参见odl的框架图，南向接口上有的,openflow, netconf等等
Q3：采用第三种方法也能像第二种方法一样通过sFlow拿到流量吗？
A3：这个是两种类型的包，其实你的问题是需不需要把在odl的南向接口上增加sflow等等协议的问题，这里面有一个基本的原则，sflow是属于data forwarding层面的东西，对于南向的接口来说就太重了。
Q4:我的意思是第三种方法能否拿到sFlow collector的信息？
A4:你当然可以用第三种方法把sflow加到SDN控制器里去，但是，这样，你的sdn的cpu cycle就恐怕要很大程度的变成sflow collector 和analyzer了。
Q5：我知道odl控制器不支持sFlow，但是如果采用第三种方法，能否通过调用sFlow collector的api获取到流量信息？
A5：你这个问题问得挺好的，理论上你也可以用odl和sflow collector/analyzer来接，譬如你在那个sflow collector 实现一个netconf server，然后用netconf 和它对接，假如你觉得sflow collector和analyzer的特性可以用yang model来定义，你也可以认为这个model可以被大家使用，你可以做这样的尝试。
Q6：sealong
如果考虑实时性的问题，第一种方法是不是目前最好的，我对java开发的controller性能有疑虑。
A6：controller的性能，这个对于单个transaction来说，odl当然不是最好的，odl有一个performance 的group，你可以去看看，用第一种方法当然性能要好一些，譬如针对openflow 下流表这个事情，of-lib ansic肯定要快一点，但是在实际上，许多的openflow交换机本身支持的pps就不是那么高的，你最后会发现瓶颈在交换机上。关于cluster的问题，odl的clustering的方案很多的，各种scenarios。
OpenDayLight研究群提问：
Q7：胖子@南京
问个问题，sflow跟服务器主机直接的通信，是通过什么实现的？是不是在ovs里面加个转发流表，把数据量转发到sflow collector？
A7：brocade switch supports sflow,for ovs, you can refer the ovs documentation to configure it.
Q8：探索者
在二次开发中 在integration版本的中 安装已有模块neutron之类的 是不是版本 固定了，不能其他版本？
A8：原理上说neutron的版本可以跟Odl版本不一样，但最后选择被测试多的用这样更稳定。
Q9：理工大学--飘零
对于初学者，是不是版本较低的odl更适合呢？而且hydrogen版是否支持主从控制器的切换呢？
A9：呵呵，对于初学者，我也是初学者，假如是初学者，我觉得装什么都合适，至少去装一下都是好的，基本的北向的api还是可以用的，当然，假如你的view很大，那我觉得装latest最好了。各种模块都可以试验一下。
Q10：河北-少帅
sdn交换机现在与传统网络对接，odl有相关的路由模块吗？如果没有，想开发一个怎么入手。
A10：take vyatta router as example,we had bunch of yang files to define the vyatta router.turn the netconf to restconf via MD-SAL.anyway, for the user space invokers, it's more like a protocol adaption..if you wanna do something with routing protocols, openconfig maybe will be something potential..actually, we had seen openconfig implementation is in progress in ODL.