我这个应该是上午最后一个议题了，我觉得应该可以在十二点之前结束。我先稍微介绍一下，我是新华三负责运营商解决方案设计和交互的，我的工作可能偏研发一些，所以我讲的PPT，可能后面可以看到，基本上是研发的更多，可能和上午其他专家讲的差异还是很大的。一般以前我们这种宣讲是市场部来的比较多，这次让我来说的话我可能会讲的更技术一些。

新华三可能很多朋友应该了解，我们主要是以固网为主的，我们目前实际上并没有移动通信，所以我们在运营商的解决方案中，这些经验基本上还是靠着固网网络重构方面积累起来的，我们也做了很多相关的城域网重构，就是以NFV为主的解决方案，还有就是政企专线，还有一个优势的就是在行业里面，后来是在运营商里面的数据中心的解决方案，包括运营商的私有云，我们公司都有参与。所以今天我讲的这些基本上是从我们固网的解决方案中总结出来的。可能额外要稍微说一点，在以往我们稍微有一些参与，就是说MEC边缘计算这一块儿，MEC虽然是5G强相关的，5G启动的，但是我们公司在这方面，我们在边缘云和MEC这一块儿目前实际上是有一些解决方案，并且在运营商中也是有了一定的试点。

大概的网络重构这个概念，三大运营商2016年都分别做了白皮书，是那个时候开始做解决方案的。到现在，这些概念，SDN、NFV还有网络重构概念都不用说了，大家都比较清楚了。但是不过说实话，这个NFV的进展尤其是固网的进展还是没有预期那么快，我这种专门做方案的体会是非常深的。我们之前做了很多年，从开发到落地这个时间还是相当长的。但是不管怎么样，它目前还是在往前走的，我们在现网中已经有了不少落地的点，用户也在承载NFV网源搭建的固网里面。后面我就具体稍微展开一下，主要还是偏技术，可能和前面的风格不太一样。

这个是我们新华三对NFV的一个核心理念的概括性介绍，我们理解的核心理念大概就是三个，分别是标准、开放和整体交付。所谓的标准就是我们是符合NFV架构的，开放是我们的组建之间是可以结合的，我们可以跑在友商的服务器上，也可以跑在其他家的运营平台上。还有一个是整体交付，整体交付是和单设备交付是相对应的。这里有两个到了可管理和可呈现，这个可管理意思就是我们现在NFV网源可以对它进行配置管理和生命周期管理，可呈现就是以端到端的视图来展示我们NFV的使用情况或者是运维方面的情况，而且现在在我们的方案里面，其实现在不仅仅是NFV这一种虚拟化的形态，还有一些实体网源也会纳入到NFV组网方案里面，所以实体和虚体都是可以管理。基于这三个方案是我们可以灵活定义、快速部署、随需调整、高可靠的NFV解决方案。

这一页我稍微提一下，就是现在NFV理念，从运营商到行业的渗透。早期的话，其实很早的时候就也基于X86的路由器，但是它不是跑在虚拟化平台之上，那个时候它也不是NFV网源，现在NFV的概念不断发展明确以后就形成了一个标准的体系架构，这个体系架构基本上是随着5G的发展，5G和NFV是强相关的，但是实际上NFV还有一整套的体系，可能有网关、AFI等等很多的组件，在行业里面慢慢的已经有了一些延伸，其实也不是从现在开始的，很早就有了。最明显的就是数据中心方案里，我们现在给租户的可以提供网关服务的，可以通过虚拟化的方式来承担，为数据的流量提供安全防护，或者是提供一个对外统一的均衡功能的VLB，这些都是NFV的网源。还有一个就是近几年的思科、华为都有的融合网关产品，就是说在原来的小路由器盒子里面，把它那个接盒子可能是基于X86或者是基于ARM及 CPU的，就是把它作为一个虚拟化平台，在这个上面你可以跑第三方APP，也可以跑一些更增强的安全，就是可以跑一些CT网源，这个是在UCP。还有一个我还有一个更大的想法，就是在园区网里面，园区网里面本来就会有很多出口设备，也可能在出口会加一些安全设备，那么在一定的条件下，有可能用NFV的理念来做。另外这个编排器的概念，就是我右边这个图，这个场景是大园区、小数据中心，在这个场景里面，我如果引入编排器的话，我实际上就可以提供一个端到端的视图，我可以直接让园区里的租户，通过编排器统一管理，在里面就可以向本地的数据中心申请支援，而且在可视化和运维方面进行统一管理，我们公司目前也有这样的产品。

下面我们来讨论一下NFV网元就是CT和VMIT无的差异。这个里面VMIT网元就是虚拟化平台上运营的网元，比如说在数据中心平台上，你申请一个点在上面跑你的应用软件，那么NFV网元和IT网元实际上是有相同和不同的，那么共同点其实非常直观，都是跑在虚拟化平台之上的，都是云平台调虚拟化拉起来的，都会有社会周期管理，但是我列的这些还是有一些不同点的，比如说第一个就是性能需求，一般的IT的网元，就是VM的数据需求是比较低的，一般你用普通网卡就可以搞定它的性能。但是特殊情况，后面的话可能现在会有一些比如说基于AI或者是大数据的时候他们可能会引用多GPU，这个是另说。但是NFV的网元包括两类，一个是控制类一个是转发类，控制类的性能要求比较低，这里没有写。但是转发类的网元，这一部分的性能要求是比较是比较高的。一般在我们现在5G的网元转发面，它会选择我们的SRIOV，它的性能已经不是我们的X86的性能了。第二个差异就是主机型和路由型，这个就是平台给你分的，实际上你就是一个IP，你APP在上面跑的时候，你也不会关心，你基本上是三四层以上了，所以你基本上就是对外提供服务，一个IP就够了，但是NFV网元不是，它是路由型的，就是你看着是一个网元，实际上它后面有很多很多主机型网元在那里，所以他不仅要管自己对外的路由，同时还要下面网元的发布，因为他是路由型的，因为他本身就是一个CT网元的替代，这样我们就可以把流量牵引过来，这一点的差异还是很大的。第三个就是NFV的网元是支持CT网元特有的VLAN和QINQ的子结构，你们看IT网元，网元出来是不带VLAN的，所以这个就是明显的差异。最后一个是它的架构，比如说像IT网元，IT网元我们一般在数据中心里用的话，最顶层就是云平台，作为一个重入口，那么SDN是嵌入到这个SDN里面的，就是云平台是一个总入口。那么等到NFV以后，实际上我们这个总入口就已经不再是云平台了，而是总的编排器，就是NFVO，他会调VNMF，然后调下面的数据，是这样的层次关系，这个地方两者也是有不少的差异。

这一页就是说NFV网元，大家知道NFV的网元本身是不能跨服务器的，这些都是跑在一个服务器上的，而且另外一点就是NFV网元出于性能考虑，基本上是不会跨移路CPU部署，因为这个内存访问性能损失还是非常大的，所以这个结论大概就是说单个NFV网元，一般我们在一路CPU上面跑一个或者是两个，所以说它的性能是非常有限的。那么这种思路固网是这样的，移网也是这样的，因为大家都意识到了这个问题。那么单个网元是有限的，那怎么办呢？这个时候就要借助NFV资源池对外提供服务，这个是比较容易理解的。另外就是运营商在网络重构的时候会建立多层DC，这个概念也是大家比较容易接受的，在我们现在的项目中基本上也是这样部署的。比如说像固网里面的ITM业务，因为这个ITM系统本身就在这个里面，所以说我们相关的NFV网元都是集中部署的，这样走的话还是非常有效的，而且它本来对时延就不是特别在意。

下面的这个就是说NFV池化以后，因为它至少还是CT的一种，本身它必须要考虑这个可靠性，需要考虑说这个资源池里面的一个NFV网元故障的时候，我怎么样保证这个业务系统不终端，保证用户的体验不到资源池里的故障，这个是非常必要的。就是IT的可靠性和CT的可靠性，那肯定不是一个级别的，IT三个九就够的，CT至少要五个九。比如说服务器故障，大家都比较容易接受，但是CT故障它会有KPI考核的，是非常非常严重的。而且前面也说到了原来的CT产品都是分散部署的，可能在接入层，大家都是离用户近，在接入机房这些位置。但是现在NFV池化以后，他不能在同一个DC内，那就提供了一个可能，因为他们离的比较近，所以他们之间可以互相辅助，统一提供服务的。所以这个时候基本上在我们的方案里面就可以把数据库放进来，有了数据库的好处是什么呢？有了数据库就可以把我们的关键数据保存在数据库里面，如果某一个NFV网元故障，故障以后我就可以先拉几个网元，从数据库里面把绘画数据恢复出来，这个时候实际上用户就不用重新上线，他感知不到这个终端。我这种故障切换可能就是一般数据中心里面，就是虚拟化的话会经常提，为什么我们这个时候不用热迁移技术呢？其实这个差别还是很大的，一个是热迁移是比较依赖于共享存储的，共享存储的成本还是比较高的。第二个就是像我们这一套系统，你NFV网元，你出现了几个新的，他可能物理位置发现了变化，这个时候你还有一些周边配套系统也需要跟着修改，比如说你有一个网关，可能网关也要修改一下配置，有可能你要和和相关的SDN网络进行调整配置，重新打一个通道，所以这个不是仅仅说一个网元故障拉几个新的绘画一下就能跑了。第三个就是为什么不能迁移，就是因为这个很多时候会用SRV网卡，这种网卡目前是没有办法迁移的，比如说像SRV，如果我使用的是SRV的集中PF方式，那么这个就需要网元直接进行处理，但是在迁移过程中，虚拟化层没有这个东西让你重新处置，因为这两个网卡的槽味不同，里面的物理性等等都是不同的，所以就根本没有办法做。还有另外一个就是负载均衡，负载均衡就是说比如说不同的NFV网元，当他们的流量不均衡的时候，这个时候你可以通过数据库技术辅助一下，进行一些流量调配。比如说我们可以说判断一下当地某一个NFV的望远，到他的CPU使用率或者是用户规模达到了一个值，另外就是有相对比较空闲的NFV网元的时候，这个时候你可以基于数据库技术把网元进行迁移，而且这种迁移也是用户不感知的，所以总的来看，这个数据库技术在NFV池化中是非常必要的，其实本身是一个IT的概念，现在把它引入到了CT，的确是很有用的。

下面就是弹性扩缩容，这里讲一下流量潮汐现象，就是说这个流量大小和设备的物理位置是比较相关的，比如说你这台设备放在一个办公楼比较集中的商业区，那你白天的流量就会比较大，夜晚的时候流量就降下来了，如果是放在生活区，这个流量可能就是反过来的，白天比较小，傍晚开始这个流量就增大。那么如果当流量降下来以后，我们这个时候可以想办法，把多的用户迁移到少量的NFV网元中，当然这个首先是共享数据库，前移完以后就可以关闭NFV网元，关闭以后有什么好处呢？其实就是可以降低散热的压力，可以降低供电的压力，这个散热压力对服务器还是有很大挑战的。这个只是一种可能，真正在现实中会不会用我觉得这个还是要讨论的，因为你在弹性过程中它是要可控的，因为他太灵活了，运营商是非常明确的，要求管理特别精确的一个系统，所以是不是使用，这个还是有待商榷的，不管怎么样，这个弹性扩缩容还是提供了一种技术上的可行性，就是你可以扩容和缩容来适应流量变化。

前面是我们把一些IT的技术引到CT里面，一些共性的探讨，下面可能就是我列出来的一些对于IT资源池中的概念是否引入到CT的思考。我大家看一下这张图，这个图和前面有一个变化，就是上面有一个LB负载均衡组件，你可以看到，下面有一堆网络设备，它只需要看到这个LB设备就可以了，它和LB设备建立通信打交道，不用看到里面的NFV资源池。但是这个组网图有什么问题呢？首先是这个CT网元和IT网元有一个明显的不同，就是CT网元的性能是非常高的，而这个LB所在的位置，而且我们NFV网元基本上都是南北向溜溜，很少有东西向流量，那么这个LB的流量压力是所有后面所有NFV流量压力的综合，所以它的性能压力是非常非常大的。

第二个问题就是说LB，大家看到，它实际上至少我们了解的就是说不管是固网、移网，因为你想提供对外一个统一的呈现，基本上都是用储备方式部署的，那么储备方式部署就是如果说这个设备发生了故障的话，那么到后面的NFV资源池基本上就是相当于和外界断了联系了，所以这个影响还是相当大的。那么有没有什么变通的方式呢？这个可能我们在方案设计里面也考虑到了，就是说NFV的架构实际上有一个编排器在最上层，这个编排器本身只是管到NFV网元这一层，但是如果它扩大到外部设备这一层，这个是有可能的，因为这个和IT不一样，IT的话你访问的终端，就是你那个远程可能是和网络用户根本没有办法沟通，但是你在CT里面，这个外部网络设备，基本上你是能管理到的，至少我们现在组网落地的时候是可以管理到，那么如果你能管到端到端，那实际上你就可以做一个静态的相对力度小一点的LB。比如说我们可以通过这个编排器，控制外部网络设备，比如说这个接口是什么样业务类型的流量分到这个NFV网元来处理，另外一个接口的就分到另外一个处理，这样就是一个静态的提前规划的负载均衡，这种方式再结合刚才提到的一些通过数据库来进行NFV之间的一个负载均衡，这样也可以满足流量场景的要求。

第二各思考就是NFV网元容器华部署的必要，因为我今天看到刚才赵主任也说过这个，容器化就是说现在的云平台也在提供容器化服务，比如说我们公司的云平台就可以提供VI服务业可以提供容器服务，这样你可以给AI用户更多的选择，因为容器特别轻载。那么容器这个技术是否适合于NFV网元呢？我们依次看一下这个容器的特点，特点之一就是轻载，为什么轻载？因为他没有操作系统，所以说比如说在容器数目负责多的时候，这一部分就可以减少不少服务器的压力。但是CT网元和IT网元不一样，我在服务器上，比如说我一般跑两到四个CT网元就可以了，但是如果是IT的话我可以跑几十个，所以他们的量级是不一样的，所以我在跑CT网元数比较少的情况下，这个轻载就可能没有那么强的必要性。

那么容器特点二就是部署速度快，因为它的启动就是直接秒级作用的，非常快。至少NFV的网元他至少要把操作系统起来，操作系统起来还是要花一些时间的。但是这个里面我们要考虑到，这个NFV网元一般起来以后，它是CT的角色，一般起来以后一般不会没事就给他关掉。首先是不会关闭，另外一个就是在故障切换的时候，我们不是说出了故障再去拉一个虚机，然后把我的东西迁过去，基本上我们的方案都是先把这个备份的网元拉起来，只是故障的时候，我先把流量业务迁过去，迁完以后都OK以后，我再重新拉起一个新的网元，这个时候你启动快的优势实际上我也用不到。但是我们看一下容器的一个特别明显的确定，这个一般说到确定都会说这一点，就是安全性非常低，因为所有的容器都是共享的，如果某一个容器，因为比如说它如果崩溃掉了，影响到内核，那么其他的容器都会受到影响。所以对NFV来说，对安全性、隔离性的要求还是非常重要的，所以说是否采用容器化部署还是需要探讨的，或者采用比较折中的方案，就是虚机加容器的方式。

这个是我最后一个思考，就是NFV资源池对于云平台的需求，可以看一下后面的数据中心架构，这个架构我刚才说到了，就是顶层的云平台，就是我们用户在云平台上进行操作，你可以创建网络，创建子网，创建虚机，然后给虚机去创网关，就是虚机的生命周期管理都是在这个上面操作的，所以说这个OpenStack的确是非常复杂的操作，这个非常非常庞大，后面的容器也会越来越大。然后我们可以看一下左边的NFV架构里面，这个我是用黄色专门标出来了，这个位置就非常低，因为这个时候的总入口是编排器，就是由编排器来决定，用户在编排器上操作，来决定什么时候把NFV网元拉起来，所以第一个在这一张图里面，像我们公司一般会把这个在NFV架构里的云平台我们叫小云，我不知道别人是不是这么叫，其实从这个叫法就知道这个云平台目前在NFV架构里面的地位是弱化的。弱化了以后就要相应的考虑到云平台的功能是不是也不用这么多了？至少它的界面是不是用不到了？这个可能是我们要考虑的，这个问题为什么提出来呢？就是我们在部署和落地的时候，每次都纠结这个管理服务器的数，因为现在有这么多的组件，对管理服务器的数目要求是比较高的。可能我们也想过一些解决方案，因为我觉得这个小云的作用并不大，我们想能不能直接通过VIM和NFV直接调资源，但是目前还没有一个可行的方法。

我今天稍微总结一下，就是说我们在做NFV资源池这个方案里面，实际上我们对IT技术是选择性借鉴的，基于低可靠的IT硬件来构建高可靠的CT无网络，我们也在不断的优化不断的讨论，希望把方案做的更合理，更可靠，更有意义。然后我们新华三是在固网的NFV领域积极发力的厂家，我们希望看到更多的案例，因为5G不是一出生就是和NFV强绑定的，那么固网是一个存在很久的没有变化的领域，引入NFV的动力实际上相对缺乏，但是我们觉得NFV的价值对于固网是同样适用的，我们也在积极配合运营商进行这方面的尝试，也希望得到更多的关注。

谢谢大家。