中国移动SDN/NFV研究员 董文英:中国移动数据中心SDN产品研发探索

2017/8/22 19:39:32 来源:DTDATA 作者: 分类:会议活动

谢谢大家。我今天分享的主题是中国移动SDN研发探索和思考。中国移动从2015年提出了NovoNet下一代革新网络,大家会很关注NovoNet究竟是什么,为什么是一个革新的网络。NovoNet可以拆出两个词,一个是创新、一个是网络。在创新方面,NovoNet提出了三个概念,新架构、新运营、新服务。我们可能在传统的理念认为运营商更多是封闭性的,厂家提供资源和设备。但是现在互联网的冲击之后,越来越多的人发现传统的模式有些low,我们需要新的变革来改变原来的这种网络运营方式。新架构里面我们要改变原来都是硬件化的、固定化的网络模式,要转向软件化、虚拟化、可编程的新结构。让整个架构可以更灵活的、更快捷的去适应用户的需求,提高用户的体验。在运营方面,我们会去侧重于把控制做集中化,把调度做得更灵活,把资源的利用化更大化。服务上我们会推荐开放、敏捷。NovoNet的网络层面我们会涉及到移动网络、IP网络、传输网络、数据中心四个场景。



NovoNet的核心技术是SDN/NFV,NFV就是把传统的硬件东西做软件化、做虚拟化。SDN则侧重于网络的流量调度、流量的控制。NovoDC就是NovoNet里面的数据中心场景,我们整个的架构会分成四层,最上面是SDN的应用层,是面向于用户的,然后中间有一个云操作系统层,就是云的数据中心平台。再往下是SDN的控制层,就包含了控制器,还有厂商的VNFM,是用来控制NFV网元资源,最下层是传统的转发设备层,有硬件和软件的,还有不同厂家的增值网元。整个架构里面除了我们这主要的四层,还有一些辅助模块来帮助。


移动的NovoDC里面是面向用户,我们不是单一的用户,而是多租户的场景。我们可以有更多的企业去共享网络,每一个用户在移动云网络里面自己的网络服务都是互相隔离的,不用担心自己的网络资源会被别人攻击,或者被别人共享掉,或者有不应该有的方式。


中国移动其实还有一个变革,不仅仅在架构上,也在研发方式上。原来都是厂商提供完整的产品给运营商:运营商提供需求,厂商来实现。现在我们更关注的是自己去实践,当然这个实践并不是说我们要抢夺厂商的市场,我们只是说希望以一种更开放的方式理解厂商的产品、厂商的架构,去接纳厂商之间的合作方式,所以我们也建设了移动自己的SDN资源体系。SDN资源体系跟NovoNet的整体架构类似,也分成四个层次。最上面是应用层,移动有自己的SDN-O产品,中间是openstack,我们有自己的云平台,在SDN控制层,移动有自己的SDN控制器的产品体系,而针对增值网元的网络功能控制方面,更多的是依赖厂商的VNFM产品。最下面是转发层,在移动自研的SDN产品体系,包括软件和硬件,在NFV增值网元,我们更多会依赖于厂商的产品支撑。在座的厂商如果愿意跟移动合作,欢迎跟我们联系。


SDN-O这层移动的产品叫SDN APP,特点是我们希望去提高用户体验,所以我们在设计这个SDN APP产品的时候,我们希望它更友好、更便捷,所以操作是采用图形化、拖拉式的操作,而不是表单的方式,这是很大的变化。在SDN-O它的南向会跟移动的云平台,会跟移动的SDN控制器,以及VNFM之间分别有接口,这些接口已经做了标准化的定义。SDN控制器这层,是整个DC里面的控制核心,移动的SDN控制器跟openstack有紧密的结合,主要管理云网络里面二层和三层流量,另外,会在与增值网元的连通性方面做控制。SDN控制器在云平台里提供了定制化的插件和驱动,用户的请求达到openstack之后、经过这些插件和驱动会到达控制器,然后SDN控制器针对请求分析出控制指令通过南向的接口下发到转发层资源,实现把具体的网络配置下发到转发设备。第三方网元的配合上面,我们是采用一种相对解耦的控制方式,增值网元自身的服务功能是由openstack里面的插件提供。但是数据中心里面二三层的流量是由控制器接管的,需要把流量正常的导向到所需要的提供服务的增值网元上。控制器在跟第三方增值网源之间有接口,这个接口的作用就是控制什么样的流量该到哪一个用户的哪一个增值网络上。


移动的SDN控制器,目前是对资源的管理和控制,主要包括两个方面:转发设备的网络配置,和增值网元的网络互通性接口控制。目前SDN控制器在功能上实现二三层的转发,实现控制管理,还有安全控制,线速。在北向是标准的openstack的接口,跟SDN APP之间有标准的接口。南向目前支持的是openflow。这张图是中国移动SDN控制器的架构图,移动的SDN控制器是基于开源OpenDayLight平台研发的,架构上会有很大的相似,但是我们最大的改进可能是在SAL层的处理。不知道在座有多少人对开源的SDN控制器有多少了解,这些平台是在南向的插件这层实现了很多,在功能上我们觉得是相对完善的,但是在性能上还是有很大得空间,这是移动在做SDN产品的研发过程中面对的最大的挑战,因为毕竟移动要面对的网络不是10台或者20台,或者几十台的小部署,我们要面对的是上百台甚至上万台的产品。SDN控制器的性能方面,是否稳定,高可靠性,这些都是我们要面对的挑战。


中国移动的SDN控制器除了我们在使用基于这种开源平台扩展之外,我们会定义很多的接口。这页是SDN控制器跟第三方的增值网元之间的接口,我们目前支持的第三方增值网元包括网关设备,负载均衡,防火墙设备,我们定义的标准接口涵盖SW、SDN网关、FW/NAT,负载均衡器等。这些接口已经跟一些厂家做了对接,在移动省公司也做了试点。除了增值网元的接口标准化之外,针对数据中心内的转发设备我们也定义了标准的接口,其中,针对硬件交换机我们定义了标准的TTP模型,这组TTP模型要求硬件转发设备支持OpenFlow的方式实现转发,这跟传统的硬件设备是有差异的,传统的交换设备的二、三层转发功能是基于配置实现的,并且这些配置相对是固定的、少变化的,最好是一次配置、永远不变。但是这种特点在SDN的场景下,是不满足要求的,因为当SDN部署上之后用户对你提出的要求和需求会变的更多,而且允许你响应的时间更短。这时候要面对的是经常性的变化,而且是精准性的变化,用户需要控制的流量,不再是一个网段,很可能就是很详细的一个特定的MAC、IP,甚至是源、目的端口。所以当这种需求被提出来的时候,openflow这种灵活控制协议的价值就会凸显出来,我们也觉得它更适合控制性要求非常强的场景。所以移动的SDN里面在控制硬件交换机上,我们首先选择的是在openflow上的尝试,我们定义了标准的模型,我们会要求在硬件交换机支持openflow,要遵循这种移动定义好的pipeline。目前移动针对硬件交换机的TTP规范是以白皮书的形式对外公布。


除了SDN控制器以外,中国移动在SDN领域另外一个尝试就是定制化交换机。移动的定制化交换机的方式是采用通用的硬件和定制化软件开发相结合的方式,到目前已经经历了三个版本,第一个版本还是传统的二三层,第二个版本会增加上一个支持VTEP能力,第三个版本就是支持openflow。目前基于OpenFlow的定制化交换机已经内部发布了第一个版本,在实验室已经跟SDN控制器进行了对接测试。目前我们已经能够二三层已经互通,我们基于openflow去控制硬件交换机,然后来实现物理之间的流量打通,目前在移动内的SDN产品就实现了。


关于定制化交换机,移动定义的TTP白皮书也在ODCC里面推出了,如果大家有兴趣可以下载。另外,如果大家对TTP或者硬件交换机感兴趣,也可以联系我们,我们可以做进一步合作探讨和尝试。关于TTP的测试,大家有兴趣可以听一下另外一位同事讲的。


还有一个就是研发思考。因为我自己本身是做开发的,所以可能我更关注的是我们在SDN开发过程中面对的问题,和我们被提出的一些需求。首先就是说SDN控制器这个层面,SDN我们都知道控制和转发分离了,在控制层面上我们会面对的挑战有哪些。其实SDN控制器有很多的产品,有商业化也有开源的。SDN控制器每一家实现的方式不一样,有人会推荐分布式控制的方式,认为SDN控制器不能集中,因为都集中到一起的话就是单点,当成为一个单点的话可扩展性就会受到限制。另外一种观点,如果都分散的话,没有一个集中控制的点就无法做统一的分析和调度,这可能是一个矛盾的问题。所以从开发的角度我更倾向于把集中式的控制跟分布控制做整合,我们会把一些比较抽象的东西放在集中式的控制平台上做,但是当更关注细节的控制指令,比如说细分领域的控制产品,针对特定的转发控制会放在分布式的子控制器上做,这样会做一个平衡。


第二个挑战,网络资源部署对SDN适配能力的挑战。我不知道其他的公司会不会遇到,可能移动面对这个需求会更多一些,因为移动所面对的厂家太多了。移动不会被某个单一厂家绑定。当我们面对这么多厂家的时候,如何做统一的调度和控制。因为每个厂家不一样,不可能做一个大而全的东西,这个东西把所有产品都涵盖了,都囊括了,没有任何一个厂家可以在这儿说能做到这一点。从运营商的角度上来说,我们需要去兼容所有的厂家,这个需求是我们绕不开的。但是每个厂家都是不同的,这个现实也是真实存在的。这时候我们怎么做?从移动的角度来说希望推动一个解耦的方案,我们希望各个厂家来配合移动做一个统一的接口,厂家可以保持自己的优势,自己可以在内部做性能上的改进,提供一些特色功能题。但是同时需要能够跟其他厂家配合部署,需要跟控制器的厂家去配合调用,这个时候大家就需要一个统一的接口,所有人都适配这个接口。从控制层来说,用这个接口去面对所有不同的、现在已知的、和未来未知的一些厂家,从设备的层面上说,要提供这种接口来面对可能有的,或者已有的SDN控制器产品。所以我们希望云开放接口是业界一起参与进来的。


第三个是网络资源虚拟化对SDN转发效率的挑战。我们知道很多的网络转发设备,或者说增值网元设备,其实都不是简单拿传统的方式就OK,很多人要做网卡驱动的改进和规划,才能达到他真正想达到的效果。比如说防火墙设备,当我们在一个SDN场景下,我们希望网络的转发设备是更标准化的,最好X86的服务器就可以替代,但是NFV的应用厂家会说X86的设备的网卡不足以满足我们的需求。所以移动会在SDN产品架构中,去做一套软件的控制,跟硬件加速的结合。我们欢迎专注于网络加速的解决方案的厂家参与进来,可以在转发设备本身层面上提高转发性和转发能力,同时在控制层面上可以要有一种更灵活的SDN控制器。


第四个挑战就是不同的应用挑战对SDN控制器可扩展性的挑战,我们习惯的开发方式是先明确需求,但是当需求变化越来越快的时候,会发现原来的传统的开发模式赶不上市场和用户的要求。尤其在SDN的场景里,比方说仅仅是一个数据中心的场景,今天用户可能告诉你这两个是通的,明天可能就不通了。你说拿防火墙的控制,但是当有一天告诉你这个控制也不够了,要增加一种流量,这时候怎么办?我们觉得是这样的,做SDN的话,尤其在控制器层我们要考虑有一个高性能、强可扩展性的平台,同时提供的应用开发能力却是更快捷的,我们希望当用户提出一个需求的时候可以快速的响应,但是我响应它而开发出来一个功能,并不需要推翻原来开发的产品,而是可以在原来的产品上快速的迭代、快速的更新、快速的部署,这可能是我们更理想的一种SDN的,尤其是控制层面的应用开发场景。所以说我们希望SDN的控制器是更倾向于平台化的发展,而不是说一个应用化的发展。


另外,移动的SDN里面不仅有数据中心的场景,还有传输网络,每个场景里面对控制性的性能要求不一样。比方说到传输网络里,关注的更多的是时延性,响应的速度,网络控制的快捷性。但是在数据中心里面,稍微晚几百毫秒,感觉影响并没有那么大。但是SDN更关注数据会不会丢,这两个场景完全不一样。归结到一起,我们希望SDN平台化和应用化都很重要,我们可以用统一的平台,但是每一个场景可以通过应用来更好的适配。每个应用去适配,分别控制具体的场景,这可能是我觉得比较好的去满足不同业务场景混杂模式下的挑战。谢谢大家。

相关资讯

    暂无相关的资讯...

共有访客发表了评论 网友评论

验证码: 看不清楚?