新华三孟丹:NFV资源池实现中的技术探讨

近日,在第三届未来网络发展大会SDN/NFV技术与应用创新分论坛上,新华三解决方案部架构师孟丹女士发表了主题为《NFV资源池实现中的技术探讨》的主题演讲。

孟丹指出,新华三的NFV核心理念主要分为三个部分:标准、开放、整体交付。标准指的是新华三的方案符合ETSI架构、有编排层、生命周期管理层、云平台层,有NFVI,有VNF网元,有EMS;开放是指层之间是解耦的,网元可以跑在友商的服务器、云平台上,目前多家运营商已经做过解耦测试。整体交付是和单设备交付相对应的,现在交付的是端到端方案。

上图中的可管理是指对NFV网元进行配置管理、生命周期管理、扩缩容管理等控制动作,可呈现是可以端到端展示多层级的资源使用状况,同时还可以对方案中的实体网元一并管理及呈现。

基于上述理念,可构建灵活定义、快速部署、随需调整和高可靠的NFV解决方案。

NFV理念:从运营商到行业的渗透

孟丹表示,早期也有基于X86平台的路由器,但是它不是跑在虚拟化平台之上,也没有NFV关联的网元。后来NFV概念不断明确,形成了一个标准的体系架构。NFV并不局限于网元本身,还包括一套体系,从编排器到VNFM到VIM,从网元到NFVI,在行业领域也开始有了一些延伸,如数据中心方案中的vRouter/vFW/vLB,如uCPE(将X86/ARM CPU中剩余的计算资源管理起来,运行第三方IT APP或CT网元),甚至在园区出口都有可能在一定条件下用NFV网元实现灵活认证。除此之外,编排的概念也在跨场景中得到应用,如园数融合、DC和DCI融合,提供一个统一入口、端到端视图。

下面讨论NFV网元(CT)和VM(IT)的差异,这里的VM是指基于虚拟化平台运行的IT网元,比如你在数据中心云平台之上申请虚机,在其中运行你自己的应用软件。NFV网元和VM两者有相同点,也有不同点。两者最大的共同点都是基于虚拟化环境,受云平台管理,有生命周期管理。

再看不同点,一个是性能需求,一般的VM网元数据需求比较低,普通网卡就可以搞定。NFV网元包括控制类和转发类,控制类的性能要求比较低。而转发类的网元性能要求比较高,一般在5G的网元转发面会选择SRIOV,这就不属于X86的性能了。

第二个差异是网元形态,分为主机型和路由型,VM属于主机型,它基本上就是对外提供服务,一个IP就够了;NFV网元是路由型,它不仅要管自己对外的路由,同时还要管下面网元的发布,因为他本身就是一个CT网元的替代,这样就可以实现把流量牵引过来。

第三个就是NFV网元是支持CT网元特有的VLAN和QINQ的子接口,而IT网元不带VLAN。最后一个是架构,比如在数据中心用IT网元,最顶层就是云平台,云平台是一个总入口。NFV网元总入口不再是云平台,而是总的编排器NFVO,它会调VNMF,然后再调下面的数据,这个地方两者有不少差异。

借鉴IT:NFV资源池化提供统一服务

孟丹指出,NFV网元本身不能跨服务器,虚拟化层就不可能提供这种技术,甚至NFV网元还不能跨NUMA,跨NUMA的内存访问会损耗30%左右的性能。也就是说,单个NFV网元的性能是非常有限的,那怎么解决这个问题呢?这个时候就要借鉴IT资源池的概念,将若干NFV网元集中管理,形成NFV资源池,对外提供统一的服务。另外,运营商在网络重构时会建立多级DC,在部署时按照NFV流量特征和业务特征选择合适的DC承载,比如低延时,大流量的部署位置相对低点的DC,不太在乎延时的、小流量的部署在位置更高一点的DC。

借鉴IT:将数据库引入NFV资源池

NFV池化以后,作为CT网元的一种,必然要考虑可靠性,要考虑当一个NFV网元故障时如何如何保证业务不中断,保证用户体验不到资源池内的故障。这是非常必要的。IT的可靠性和CT不是一个水平的,服务器故障比较常见,一般容易接受,而作为网络的重要组成部分,CT可靠性要求非常高,看下运营商集采就有体会,稳定性测试是非常严格的。原先的CT实体设备是一个独立的、分散的网元,物理位置并不是集中的。而NFV池化物理上会部署在同一DC内NFV池是集中管控的,这时可以将IT资源池中的数据库技术引入进来。

有了数据库多个功能相同的NFV网元可以将数据保存在数据库中,当某一个NFV网元故障时,就能够从数据库中恢复出它的运行数据,保证会话不中断,用户不感知。那为什么不用虚机的热迁移技术呢?原因有两个,一是强依赖于共享存储,成本高,另一个是NFV在使用SRIOV时无法迁移(举例来说,PF直通模式,NFV网元迁移后,虚拟化层没有机制调用NFV网元中的PF驱动,迁移前后网卡的配置信息是不同的,如果不能重新初始化那网卡无法正常运行)。

除了故障热切换,当不同NFV间流量不均衡时,也可以依靠数据库技术在NFV间进行流量调配,比如我们发现某个网元CPU使用率或者用户数已经达到阈值了,而另一个NFV网元比较空闲,这时可以依靠数据库技术把部分用户数据在NFV之间迁移,并且这种调配也是用户无感知的。也就是说,数据库技术在NFV池化中是非常有用的。

借鉴IT:NFV资源池弹性扩缩容

不管是虚机还是容器,弹性扩缩容是一个非常典型的特性,这是虚拟化一个非常明显的优势。流量潮汐是因为设备所处的地理环境是不同而带来的,有的地区是办公楼集中的,白天流量大,夜晚流量减少,有的是生活区,反过来,白天流量小,晚上开始流量增大。用NFV资源池来按需应对就非常有效。先定好弹性策略,流量下降到一定程度就先将剩余用户集中到少量NFV网元上(当然这个过程也是借助数据库的),再缩减NFV网元数目。

这样的好处在于能够降低供电需求,降低散热压力。不过在实际现网中是否使用还是一个值得讨论的问题,网络弹性实际上也意味着不可控,而原来的运营商网络是一个非常明确的系统,但不管怎样,弹性扩缩容提供了一种技术上的可能。

IT资源池中的概念是否要引入到CT?

这部分主要分为三块内容

思考1:NFV资源池部署LB必要性探讨

上图增加了LB负载均衡组件,它的作用是对外屏蔽资源池内部结构。所有外部网络设备只看到LB,并不知道LB后面有多少NFV网元在进行实际的业务处理。

但这里有个问题需要思考一下。CT网元和IT网元是不同的,那么对LB的需求也是不同的。前文提到,NFV转发类网元的性能要求很高,而作为对外统一入出口的LB,其承载的性能压力将是所有NFV南北向流量之和,这远远不是IT资源池中LB所能匹配的。另外,LB作为关键路径,可靠性要求非常高,而为了提供对外统一接口,LB通常采用主备方式部署,如果出现故障,整个NFV资源池都无法再对外提供服务了。

那有没有变通的方式呢?NFV标准架构里最上层是编排器,负责业务的编排,如果能够扩大编排器的范围,将外部网络设备也纳入管控范围,实现端到端管理,那么编排器就有一个全局的视角,在一定程度上可以实现一定粒度的LB。比如编排器直接在配置时对外部网络设备按接口+业务类型直接分配不同的NFV网元,这也实现了负载均衡,只不过是一种静态的、预先规划的负载均衡。这种静态的,再结合NFV间流量调优,也能满足一定场景的需求。

思考2:NFV网元容器化部署必要性探讨

现在云平台不仅提供虚机服务,还可以提供容器服务,给用户更多的选择。那么容器是否适用于NFV网元呢?容器特点之一是轻载,因为它没有操作系统,所以在容器数目负载多的时候,这一部分就可以减少很多服务器的压力。但CT网元和IT网元不一样,同样服务器配置下,NFV网元数目非常少,比IT低一个数量级,尤其转发类NFV网元可能一种CPU只跑一个网元,所以轻载就可能没有那么强的必要性。

容器特点之二是部署速度快,因为它的启动就是直接秒级作用的,非常快。但NFV网元一般启动后就不会关闭,是持续运行的状态,故障倒换时也是预先拉起网元,所以启动时间起到的作用也并不关键。容器最明显的特点就是安全性低,毕竟多容器都是共享同一个HostOS,其中一个容器崩溃如果影响到内核,那么其它容器也必然受到影响,而NFV网元对安全性、隔离性要求是非常高的。

所以是否进行容器化部署还需要探讨,或者采用折衷的方案用虚机+容器来承载NFV网元。

思考3:NFV资源池对云平台的需求

上图中的数据中心方案里,顶层为云平台,用户在云平台上操作,创建网络、子网、端口、Router/VPN/FW/LB,总入口在云平台,VM的生命周期(创建删除)都是由云平台发起的,所以openstack是一个非常完整全面的复杂系统。而在NFV架构里,总入口是编排器,它了解业务,决定NFV生命周期的时机,云平台只是提供北向接口被动响应请求。

孟丹表示,云平台在NFV架构里的地位已经被弱化了,是否相应云平台的功能也不用要求太多?这个问题的提出也是对实际部署问题思考后的结果,每次落地时管理服务器数目的缩减都非常让人头疼,毕竟前期NFV资源池规模小,管理服务器有时候显得太重了,甚至曾经想过能不能VNFM直接对虚拟化层,把云平台这层省略掉,但这样解耦会有问题,所以目前也没有一个可行的方法。

最后,孟丹指出在做NFV资源池的这个方案中,对待IT技术的态度应该是选择性借鉴的,基于低可靠的IT硬件来构建高可靠的CT网络,让方案更合理、更可靠、更有意义。

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

原文发表时间:2019-05-31

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

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券