SDN实战团分享(十九):OpenDaylight在电信网络中的应用

大家好!首先自我介绍一下:我来自中国电信广州研究院,我和我的SDN小组是一支来自电信运营商的研发团队,主要从事一些预研性的研究和开发工作。大家可能是从最近的一本关于ODL的新书《OpenDaylight应用指南》中了解到我们在ODL方面做过一些工作,我这里想说的是,我们的工作在整个运营商的SDN/NFV研究拼图中只是很小的一部分,因为这里涉及到宽带IP网、移动网、传输网、接入网、终端、BOSS等各类专业领域的向SDN的演进问题,今天我们没法在这里展开讲,只用一张图来表明一下相关的工作基础和广域网SDN控制器的选型背景。

从图中可以看到,整个IP运营网络分为接入网、IDC、城域网、移动分组域、IP骨干网、运营支撑系统几个部分,实验和试点工作几乎覆盖了整个网络领域,既包括基于传统网络和SDN集中控制思想的骨干网、DCI和IP RAN等环境的流量优化调度,也包括接入/城域网的网元虚拟化等等,说明运营商对SDN/NFV的需求是全面的、庞大。同时,传统网络与新型SDN/NFV设备共存、新型控制平面与传统承载控制平面共存也引入了演进问题。这张图有两个关键词:网络庞大、新旧共存,这是对SDN控制器应用环境的初步需求。按我们的理解,运营商广域网SDN控制器为保证专业性和兼容性,需要提供两方面功能: 其一,专业功能。随着我们对控制器所应用的场景和专业领域的进一步细分,可以用2个维度对控制器的专业功能进行描述,一个是控制平面采用的技术,包括:基于传统路由控制平面的SDN过渡技术、NFV控制面技术和OpenFlow技术(这几种技术可以共存于同一个控制器);另一个是功能场景维度,例如:EPC、IPRAN、VPN、TE、DCI等等,运营商对于SDN控制器的专业功能需求是非常丰富的。

其二,通用功能。作为一个大型运营级控制器及其控制平面,还需要提供良好的软件实现架构和扩展性,这点是以往电信产品所欠缺的,以往的电信产品只画过功能架构,没人认真考虑过一个软件的可实现性和实现架构,同时也需要从IT技术中引入HA、能力开放、接口抽象、模型化、自动化部署等大量新技术。

理解了上述问题,就不难理解为什么运营商和传统的Vendor都会不约而同地选用ODL这类大型的控制器,它绝不是 “OpenFlow控制器”或者“承载-控制相分离”所能覆盖的。我们之前也认真分析过其它一些SDN控制器,如floodlight和OpenContrail,OpenContrail中采用的技术令人印象深刻,不仅网络功能强劲,也让我们了解到如何在实现架构中引入大量IT开源新技术对复杂的网络进行配置和管理。同样,大家也知道,2013年以前大家讲控制器都是在谈OF控制器,而今floodlight等单一OF控制器正在逐步淡出运营商的视野。

举几个例子大家就容易明白:我想在传统IP网做一个流量优化调度,可以无需OF设备,只需用ODL的BGP-LS模块采集链路状态或者BGP路由,通过BGP(或者BGP改进)来下发路由策略,这个场景可以在DC出口,也可以在城域网出口或者国际网络;又如,我想在IP网络边缘部署vDPI等NFV设备,可以用ODL的业务链插件来实现主要的配置功能;再举一例,某用户擅长做IP RAN网络的业务开发,但不擅长做HA架构和PCEP/OF等接口,也不知道该如何开放出API,此时可以借用ODL的通用功能,用户只需专注于IP RAN的plug-in能力就可以迅速完成整体控制器开发,如果恰巧运营商已经使用ODL平台,该用户只需做好plug-in并与运营商控制器进行集成。

这些都是我们已经看到的和亲身感受到的ODL这类开源平台的明显优势,一种是软件架构的优势,包括:基于OSGi的可裁剪软件框架、MD-SAL的资源抽象、YANG模型与YANG tool提供的北向接口开放性(基于YANG定义文档,用户就可以在预研阶段定义出功能标准和API)、集群/LB能力;另一种是功能性优势:集成了BGP/IGP、LLDP资源发现、NETCONF/OF/SNMP等大量新老协议族,以及资源模型化、策略管理等。ODL最大的特点是,在这个平台上,用户的开发工作量明显降低,系统开放性好。据我们了解,大多数公司初次接触ODL后均能在3-6月内快速做出一个产品原型。

当然,我们自己和不少朋友也都在抱怨ODL里面“坑”不少,很多主线项目从安装调试,到代码和文档都存在问题,也有人诟病ODL对运营商网络领域的问题聚焦不够、运行性能低下等问题,但我相信,只要社区保持较高热度,通过快速迭代这些问题迟早会解决,我所在的ODL顾问组,每月都有例会,平时邮件也很频繁,主要讨论功能特性排序、开发/测试问题报告、案例分享,我们可以观察到社区已走向正轨。同时,社区的快速成长减少了未来控制器领域技术垄断的可能,也促进了可能的商业版的统一性,正如今天Openstack社区所形成的格局,而传统网络供应商依然可以通过控制器专业功能和VNF获得新市场。

ODL社区的项目从早期氢版本的十几个发展到现在70多个,初期知道ODL controller、MD-SAL和L2 Switch几个模块以及YANG Tool就能动手搭建一个系统,而今从AAA到VTN和SFC等大量模块的存在,新用户需要聚焦就非常困难。随着ODL应用场景的扩展,我相信已经很少有人能达到所谓全面掌握的程度,毕竟术业有专攻,即使是网络工程师,也有传输、宽带、移动、终端等不同的专业分工,这都会给初学者带来不少困惑。从我们的经验看,如果您只是对专业网络问题感兴趣,经过对核心模块和架构有一定了解后,就可以集中精力在ODL部署和专业功能项目上,如BGPCEP,并参与到社区项目的开发工作,更有可能是您需要自己设计一个专业场景下的ODL plug-In。对controller等通用功能的改动会面临未来ODL版本升级的风险。

下面介绍一下我们自己将ODL应用于IP广域网的开发和IP智能边缘业务链PoC,这个PoC是2014年开发的,详细的细节可以参考我们的新书,这里只概括一下。由于是一个NFV业务链,光做一个ODL控制器无法实现这个功能,需要三个层面的开发:用于资源管理和用户管理的编排器、用于物理网络和虚拟网络控制的SDN Controller以及与现网的运营支撑系统接口层、支持高性能NFV的转发层。同时,我们最终移除了Openstack组件以简化架构,直接用Qemu管理KVM虚拟机,如下图:

我们在编排层做的工作称为SCP(业务控制平台),这一块的开发难点是用户Session的管理、业务模板定制、资源监控及其可视化管理、OSS接口,这块工作的基础来自于我们以往在运营商承载控制平台方面的积累。

而在SDN控制器方面由于有ODL的支持,我们可以很快在氢版本上做出控制器功能架构,并通过YANG文件快速定义转发策略配置模块、业务链管理模块的功能,通过maven和YANG Tool将上述文件自动生成为API和模块的代码框架,将控制策略转换为OpenFlow流表或转发表。并通过OpenFlow模块控制SFC转发层流表,通过Netconf模块配置转发模块和DPDK加速环境,核心功能非常简洁清晰。缺陷是由于初次接触,花费了大量时间学习使用和修改bug。另外,我们也与Intel、华为等公司合作,加入到部分项目,学习到很多经验。

在转发层,我们做的工作主要是支持NSH封装、流分类、转发图加载,开发的难点是实现基于DPDK的NFV加速层和我们自己提出的PF可编程转发能力,通过这两方面能力共存可以实现NFV设备的高性能灵活转发能力。

目前,对ODL的通用能力方面我们已经较少关注,仅保留控制器集群、功能可裁剪性的评测,更多精力是重点关注和参与专业项目,如BGP-FS扩展、策略控制、业务链SFC、OVSDB等等。

最后,介绍一下我们的ODL新书——《OpenDaylight应用指南》。该书主要面向初学者和中级技术人员,以及一些没有时间但需要快速了解ODL社区及其项目的专业人士。ODL项目介绍的内容来自社区官方文档,大部分项目经过我们的编译调试和试用,但不是完备的测试,书的后半段是我们的开发实践,不仅仅是控制器,也包括了一些编排和转发层的开发工作,这些工作应理解为概念验证而非产品实现。

从开始有想法到最终面世,该书前后历时近9个月,作为一种新技术传播方式,在当今无疑是比较慢的。这其中的周折在于,开发用的是氢版,开发后期换成氦版,从AD-SAL到后来MD-SAL,不得不重新理解和改进核心代码,而当书开始动笔时,又经历了锂版本发布,社区项目和文档变得面目全非,陡增了数十个项目,不得不重新整理。与锂版相比,书中介绍的项目并不算多,一方面正如前面所说,无人能精通所有项目,我们只能选择我们理解的和有兴趣的项目。因此希望大家谅解。今后,我们也会加强通过网站和SDNLAB这类论坛与各位业界同仁进行交流学习,后会有期。今天就讲到这里,谢谢大家! Q&A

Q1:请问ODL支持新的应用直接以新插件的形式安装就行了吗?

A1:可能有的插件并不能那么快,需要自己调试与ODL的集成,ODL目前每个模块的“坑”也还不少,甚至是比较大的bug,调试也不是想象中那么顺利,很多朋友都反映过,即使现在有问题,我相信将来通过快速迭代还是有可能解决。

Q2:vsdk没有ovs的功能,为什么还要单独列出ovs呢,?vsdk颜色不一样是什么意思了?

A2:ovdk=dpdk+ovs的功能, ovdk已经停止维护,已经合并如ovs社区版, 我们提到ovs和ovdk是使用了intel的解决方案,他们对ovs有单独的加速优化。

Q3:请问ODL最多控制多少台设备?

A3:关于ODL最多控制多少台设备的问题,我们现在正在测试odl对OpenFlow设备的管理能力,目前还没有结果,但这不等于odl整体的管理能力,包括HA能力。我们现在用odl只是用于小型资源池控制,目前还不存在性能压力,但海量流表的下发速度确实是一个很大的问题。

Q4:Intel的方案跟开源的ovs-dpdk相比有什么不同吗?

A4:现在Intel已经放弃ovdk,现在只有OVS社区版中的ovs+dpdk的方案。

Q5:业务编排还是用odl-sfc 来实现的吗?

A5:业务编排的实现是在odl-sfc项目之前,现在的sfc项目我们只是参与和评估,并没有实质性贡献。

Q6:请问在广域网优化与TE方面对OpenFlow与BGPPCEP的考虑是怎样的?二者的应用场景是如何区分的?

A6:目前我们在骨干网TE还是使用传统BGP技术及其能力增强,如BGP-FS或BGP-LS,来模拟OpenFlow能力,而非使用OpenFlow技术本身。在DCI上的调度上则可以使用OpenFlow+BGP+PCEP。这是我的观点。

Q7:理论上ODL控制器不是和其管理的每台屋里设备直接相连的,他跨设备的管理随着设备的增多影响有多大?

A7:这个问题业界也没有想的很清楚,我们也没有答案,只能去探索和等待。我们现在尝试的是控制器和白牌盒一体(在白牌盒的CPU上运行裁剪过的ODL),减少管理控制距离和代价。

Q8:请问选择放弃open stack层的具体考量,同时怎么看MANO架构?

A8:openstack的neutron网络不能支持业务链这类复杂虚拟网络的管理和配置,所以当时就暂时放弃openstack,专注在业务链组网能力和资源OAM能力的开发上。将来只要VIM或者MANO达到ODL对网络的控制水准,我们还是会优先考虑与MANO类标准进行集成。

Q9:请问你们的OpenFlow网络具体是在什么地方用到?是基于什么样的需求选择OpenFlow?

A9:我们现在在虚拟化组网、DCI、SDN/overlay网关设备上会使用OpenFlow。

Q10:请问国内运营商对ODL vs ONOS是什么看法呢?

A10:个人观点来看,我们对ODL与ONOS都抱着同样积极的态度,我们乐见两者的解决方案能够互通,或者互为所用。

Q11:虚拟化组网可以理解就是正常的ovs,其他方面OpenFlow的优势在于什么?

A11:也不完全是这样,我们也有SR-IOV方案和NIC上的交换方案。

Q12:ODL获取拓扑和管理拓扑的api在哪里找得到?

A12:ODL最多提供的一个二层拓扑比如LLDP。在业务链的实现当中这是远远不够的,我们需要全局的资源视图,所以我们自己开发了资源监控agent来完成资源状态和拓扑的采集。

Q13:ODL对NFV的管理到什么程度了?能方便的实现虚机的漂移吗?

A13:ODL不负责虚拟机管理,这个是VIM或者MANO做的事情。

Q14:您认为ODL要想达到商用水准,需要加快改善的地方有哪些?

A14:这个问题太大,ODL不足的地方太多,目前来看离商用水准个人认为还有相当的距离,架构方面、代码本身、社区的成熟度、与编排器和OSS集成等问题都有待解决,但是做为一个商用控制器的框架基础还是非常给力的。

Q15:ODL现在没几个模块省心的。比如现在ODL的cluster,SFC,OpenFlow plugin,netvirt,都有很大问题,包括platform本身Java CG, SFC的hairpin等问题。这方面你们做了哪些改善么。主要是ODL从一开始就是个厂商主导的community。想问下从用户角度了解下,你们主要关心的地方是哪些功能?

A15:我们主要是对外围的一些功能进行改进,核心功能例如Controller这些主模块的bug是不会去碰的,例如我们知道pack-in功能就有问题,现在的改进在将来的迭代中都会消失,没有意义。我们目前改进了sfc的调度算法,NETCONF模块中RPC调用等一些问题。可以说每个模块都有不同的问题。

Q16:我想了解一下,目前在城域网现网试点情况,可能在哪些网元率先部署NFV?现阶段控制器和转发面能否满足业务和性能需求?

A16:城域网应用还是在边缘POP点、CPE、VPN、CDN等方面。目前组建大的资源池方案还是有难度。但是如果进行分布式部署,目前的控制层面的功能还是太复杂,MANO+ODL在单一POP点部署不是很经济。性能方面还是希望进一步提升,这也是我们关注的重点。

Q17:IDC可以试点,DPDK貌似在转发性能上可以提升不少,效果比较明显。具体不知道是否实际实测过?

A17:我们发布了《中国电信DPDK技术白皮书》,可百度一下,目前已发布到v1.2版本,目前单机测试达到了双向120Gbps的吞吐量(SR-IOV,包长128byte),后续还会继续公布评测结果。

Q18:onos的集群会不会好点?

A18:我们看到有相关报道,并未进行严格比较,四月初ONOS会有一个黑客马拉松,届时我们希望能够深度体验。

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

原文发表时间:2016-04-10

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏哲学驱动设计

《Framework Design Guidelines 2nd Edition》推荐

前言     最近看了《FDG 2nd Edition》,也适当做了些笔记,在这里写这篇文章的目的主要有两个,一是对自己学习的一个记录、积累;另外,还可以用这...

198100
来自专栏大数据架构师专家

2017年 Python工程师面试经历分享(七家)

博主本人 2015 年毕业于郫县某 985 大学通信工程系,因为大学期间一直自己创业所以错过了大四秋招春招,毕业后又在北京继续创业一年,但在创业公司一直无法沉淀...

76420
来自专栏PPV课数据科学社区

使用 Python 创建 AI 比你想象的轻松

原文地址:https://blog.csdn.net/Lunaqi/article/details/76171702

16220
来自专栏带你撸出一手好代码

谈谈代码质量问题

我们编写代码, 假如代码有语法错误,那么编译器将会拒绝通过编译, 假如代码语法正确, 那么编译器会通过编译, 因此, 判断代码是否编写正确, 可以拿代码是否能通...

41490
来自专栏CDA数据分析师

数读 | 为什么运维朋友们都需要学Python?

运维人员需不需要学开发?需不需要学Python?PythonN和Shell有什么区别?天天问这种好水的问题,我实在受不了,决定帮大家扫扫盲。 现阶段,掌握一门开...

46550
来自专栏CDA数据分析师

使用 Python 创建 AI 比你想象的轻松

原文地址:https://blog.csdn.net/Lunaqi/article/details/76171702

21830
来自专栏大数据挖掘DT机器学习

如何处理 Python 入门难以进步的现象?

问题: 如何处理 Python 入门难以进步的现象? 看视频看呀看呀看, 看完了,基础的都懂了 然后就想写点东西 可是无从下手呀,我以为基础不扎实,又去看视...

40640
来自专栏SDNLAB

SDN实战团分享(十九):OpenDaylight在电信网络中的应用

大家好!首先自我介绍一下:我来自中国电信广州研究院,我和我的SDN小组是一支来自电信运营商的研发团队,主要从事一些预研性的研究和开发工作。大家可能是从最近的一本...

37180
来自专栏架构师小秘圈

程序员如何解决时间利用率不高这个大bug?

一直感觉自己时间不够用,因此学习过 GTD 和番茄时间管理法等,每种管理法都有自己的优缺点,也有自己不习惯的部分。经过一长段时间(接近两年)的实践与改良、结合番...

39380
来自专栏JAVA烂猪皮

如何成为10倍速的程序员

国外有个词叫做10x Programmer,直译是以一当十的程序员。我并不认为一个技术大牛能完成10个普通程序员的工作,技术大牛会花1/10的时间把工作做完,然...

14120

扫码关注云+社区

领取腾讯云代金券