51学通信论坛2017新版

标题: SDN实战团分享（十三）：SDN [打印本页]
作者: admin    时间: 2017-9-17 14:03
标题: SDN实战团分享（十三）：SDN
【编者的话】本文系SDN实战团微信群组织的线上技术分享整理而成，由中国电信广州研究院高级工程师欧亮带来的OpenDaylight在电信网络中的应用的分享。
--------------------------------------------------------------------------
分享嘉宾

[attach]1089[/attach]

欧亮，男，工学博士，中国电信广州研究院高级工程师，OpenDaylight社区顾问委员会顾问，长期从事电信网络规划设计、互联网新技术研究与应用，在SDN领域的研究兴趣包括NFV业务链、广域流量工程、软硬件交换技术。
分享正文
--------------------------------------------------------------------------
大家好！首先自我介绍一下：我来自中国电信广州研究院，我和我的SDN小组是一支来自电信运营商的研发团队，主要从事一些预研性的研究和开发工作。大家可能是从最近的一本关于ODL的新书《OpenDaylight应用指南》中了解到我们在ODL方面做过一些工作，我这里想说的是，我们的工作在整个运营商的SDN/NFV研究拼图中只是很小的一部分，因为这里涉及到宽带IP网、移动网、传输网、接入网、终端、BOSS等各类专业领域的向SDN的演进问题，今天我们没法在这里展开讲，只用一张图来表明一下相关的工作基础和广域网SDN控制器的选型背景。

[attach]1090[/attach]

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

[attach]1091[/attach]

其二，通用功能。作为一个大型运营级控制器及其控制平面，还需要提供良好的软件实现架构和扩展性，这点是以往电信产品所欠缺的，以往的电信产品只画过功能架构，没人认真考虑过一个软件的可实现性和实现架构，同时也需要从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并与运营商控制器进行集成。

[attach]1092[/attach]

这些都是我们已经看到的和亲身感受到的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虚拟机，如下图：

[attach]1093[/attach]

我们在编排层做的工作称为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等等。

[attach]1094[/attach]

最后，介绍一下我们的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会有一个黑客马拉松，届时我们希望能够深度体验。

-------------------------------------------------------------------------- SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立，携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛，每周都会组织定向的技术及业界动态分享，欢迎感兴趣的同学加微信：eigenswing，进群参与，您有想听的话题可以给我们留言。
声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。



欢迎光临 51学通信论坛2017新版 (http://bbs.51xuetongxin.com/) Powered by Discuz! X3