OpenDaylight Lithium SR2版本Entity Ownership Service分析及OFplugin规模部署可用预测

【编者的话】本文系OpenDayLight SDNLAB研究群(群号:194240432)分享整理而成,本期我们邀请的主讲者盛科张东亚,他将分享OpenDaylight Lithium SR2版本EntityOwnershipService分析及OFplugin规模部署可用预测。

分享嘉宾
--------------------------------------------------------------------------------------------------

张东亚@fortitudepub,最初在北京华为负责路由协议研发,近四年在盛科负责sdn/of交换机以及opstk网络方案相关的研发,积极关注并参与开源社区,给ryu/oftest这些都提交过补丁并合入,持续关注sdn新方案及落地的可能性。同时也是OpenDayLight中文社区活跃用户。
--------------------------------------------------------------------------------------------------
分享正文
大家好,我是盛科网络负责sdn研发的张东亚,作为sdn设备的提供商,业余非常关注sdn生态圈的发展,最近抽时间研究了li版本of plugin的代码,记录了一些心得,跟大家分享,由于是业余研究,难免有纰漏错误,希望抛砖引玉,大家多多交流。十分感谢sdnlab给予的机会,希望大家多多支持sdnlab以及odl中文社区。

大家应该注意到10月8号odl发布了lithium sr2版本,我在群内也看到有相关的讨论了,我这次的分享,就主要集中在lithium首次release和sr2这个版本在of实现上的差异部分。sr版本用于协调odl各个子项目的发布,后续还会有sr3和sr4版本的发布,大家可以继续关注。

如果有尝鲜的群友,应该注意到在odl的karaf中,会注意到带有-li后缀的feature,这些feature代表的就是lithium版本针对于h版本的ofplugin的问题所做的新的设计与实现,关于详细的设计,大家可以参考odl wiki上名为lithium design proposal的页面。

由于我们的客户有时会问到有没有稳定的支持ha的控制器方案,所以这次我注意到lithium design中引入了一个名为EntityOwnershipService的服务,这个服务是针对于odl的bug 4105所做的修改,在odl controller的DistributedEntityOwnershipService对象中有详细的实现过程。

bug4105被bug4104所依赖,我们查看bug可以看到,目前的h版本中,ofplugin在多控制器集群中,并不支持集群实例的主备,也就意味着多个控制器上的ofplugin都可能去编程底下的of设备,出现流表混乱等问题。而entityservice这个服务,就是为了解决这个问题而来,他的功能依赖于odl mdsal底层的shard所用的raft一致性协议。

具体的做法就是,针对于一个由openflow:dpid所标示的of设备,每个集群实例上的ofplugin都注册自己为candidate,利用raft的选主机制,选出一个ofplugin做为主,ofplugin得到升主通知后,就作为该设备的rpc owner,并通过openflow的role request消息设置自己为master,其他raft follower实例则设置自己为slave,这样就在一定程度上解决了不支持主备的问题。

entityowner这个服务是一个通用的服务,其他app也可以自己注册一个全集群唯一的entity,从而实现多集群实例下的选主操作,并在主故障时,处理新主实例的升主操做,提高app的可用性。具体的使用办法是在自己app的yang模型里,增加对entityownerservice的引用。

根据我这边针对sr2该特性的验证结果,三个控制器实例下做集群已经可以正确的设置主实例为master,其他为slave,从bug4104自己邮件列表上ericcson的测试反馈,新的design在稳定性及时序下还有一些问题,大家可以继续关注bugzilla和odl相关的邮件列表。

另外,在验证过程中,我遇到了bug4473这个lithum design中存在的不兼容ovs 2.4.0的table feature消息中的nxm扩展的问题,会导致of设备不能被加进到inventory数据库中,这个问题暂时还未被fix,大家在使用中,可以注意降级,避免浪费时间定位。

综合近期的关注,我个人认为odl ofplugin离商用还有一段距离,邮件列表上ericsson在提交一些集群自动化测试用例,相信后续odl集群功能会逐渐的优化改进,如果有急切需求的话,个人还是推荐ryu加外置成熟分布式数据库的方案。

好了,本次的分享就暂时结束了,平时潜水居多,后续业余时间会多参与大家代码的交流,毕竟我喜欢开源的一个原因就是show me the code,再次谢谢sdnlab,也感谢大家的聆听。分享内容结合代码部分请点击:https://www.sdnlab.com/community/article/103
--------------------------------------------------------------------------------------------------
Q&A

Q1::南京-小爱
请问你是如何利用邮件列表的

Bugs.opendaylight.org,点击左上角的browse可以按项目查看问题状态,不需要注册,如果提bug需要注册,odl应该很欢迎大家提bug

Q2:南京-小爱
那么盛科有在实际环境中部署opendaylight或者说有什么odl的应用场景吗

盛科的客户据我的观察,有些采用自研控制器支持主备,目前已经商用。也有基于分布式数据库加ryu的商用案例。

Q3:朱坚
群里有人搭建了ODL集群的吗?

估计由于ODL这块的功能和文档不给力,应该很少人搞过。不像ONOS的集群功能在一开始就作为亮点突出,也有部署实例可供参考。

Q4:IT难人
怎么看plugin代码?从哪些方面

关于plugin的代码,建议从plugin自带的app如lldp speaker和frm这些入手,特别是frm,能够理解如何从mdsal到of sal并最终下发给设备的过程,单独的l2switch或者lacp项目也是不错的参考。

Q5:IT难人
那plugin和openflowjava先看哪个?还是两个一起看?您的意见?因为我比较关注快速上手,才能更深入理解odl以及SDN。

plugin的北向接口是用plugin的yang定义渲染出的rest接口,openflowjava项目是具体的协议实现,建议理解openflowplugin,因为它是作为一个app存在的,看代码的花话我建议先找个低版本的比较好,就像读linux源码都是从很低的版本讲起。

Q6:華科-笑傲秋航
我想知道怎样使用锂版,使得ovs网桥能够设置它为控制器

安装ofplugin,然后用ovs-vsctl设置控制器就可以了

Q7:某某@地球
腾讯有几个sdn?我听说的是他们用的某vendor的控制器。

腾讯据我了解到的小道信息,h3c做的控制器解决虚拟化的问题,这个之前网上万总的介绍。另外基于bgp ls做te的应该是华为北研所做的方案。不过odl开发可能没有ryu迅速,最近opstk liberty版本已经支持用ryu做为ovs agent的native流表下发接口了,ryu的稳定性会进一步加强,二级控制器可能更适合。

-----------------------------------------------------------------------------------------------------
OpenDayLight SDNLAB研究群(群号:194240432)定位为面向SDN/ODL相关技术的初学者进行交流、学习、分享,吸引了来自高校、云服务提供商、互联网厂商、设备厂商、运营商等单位的从业人员近千人,每周会组织定向的技术及业界动态分享,如果你有需要分享的请加Q:117511567联系。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/14696.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于15-11-12
0