网络功能虚拟化:NFV架构、开发、测试及应用
上QQ阅读APP看书,第一时间看更新

1.4 NFV挑战

虽然目前很多行业针对NFV技术已经开展了许多研究工作,取得了不少研究成果,但NFV还未能得到广泛的应用。2016年4月12日,中国电信科技委主任韦乐平在中国SDN/NFV大会提到SDN/NFV的发展仍处初级阶段,技术还不成熟,标准化和商用化进展还很慢。业界对于SDN/NFV将是未来电信网络的主流趋势已经达成共识,然而落地到现网部署层面仍需要一个较长的过程,整体来看,SDN/NFV还处于Gartner曲线从过度期望进入幻灭到成熟期。因此,对电信网络进行改革创新,给网络运营商带来巨大的利益的同时还面临着许多挑战。

1.4.1 性能问题

电信级的网元设备要求具备高可靠性、高性能等,NFV需要实现这些特殊的性能目标。例如,传统网元设备的可靠性要达到电信级的要求,即5~6个9,而NFV的网元设备是基于COTS(Commercial-Off-The-Shelf)通用服务器,其可靠性通常是按照2~3个9的标准来衡量。虚拟环境中,底层设备的特性,例如处理器的架构、时钟频率、CPU缓存、存储带宽、速度等,对虚拟网络功能VNF性能都有很大的影响。底层平台可提供的性能必须有清晰的明确标识,这样虚拟化设备就能知道能从底层得到多少运算能力。VNF软件的设计同样对VNF性能产生了巨大影响。VNF软件可以通过以下几项技术提高性能。

(1)为了可以在多核或不同主机上执行VNF,高需求的VNF应该通过多线程技术实现。

(2)为了避免操作系统的死锁,VNF应该有独立的存储结构。

(3) VNF应该有独立的网络协议栈,因为在操作系统上实现网络协议栈会消耗大量的计算资源。

(4)实现处理器的亲和性。

1.4.2 虚拟网络功能间的连接问题

传统网络中网络功能的连接可以通过直接连接、两层交换机连接等方法实现,但是虚拟环境中需要使用不同的方法。虚拟机可以在下述几个不同的场景下被连接:

(1)如果两个虚拟网络功能VNF在相同的物理服务器上和局域网上,它们可以通过一个vSwitch连接。

(2)如果两个VNF在相同的物理服务器上,但是不在一个局域网内,第一个VNF通过vSwitch连接到网络接口控制器(NIC)上,然后连接到外部的交换机,交换机再次连接到同一个NIC上,经过另一个局域网的vSwitch,最后与第二个VNF连接。

(3)如果两个VNF在不同的服务器上,第一个VNF通过vSwitch连接到NIC上,然后连接到外部的交换机,交换机连接到目的服务器的NIC上,经过另一个局域网上的vSwitch,最后与第二个VNF连接。

实现单根虚拟化技术(Single-Root I/O Virtualization,SR-IOV)的NICs可以直接连接VM。物理的NIC可跳过中间的虚拟层,直接与虚拟机进行数据交互,反之亦然,以此达到近乎于纯物理环境的性能。它们为虚拟机提供更快、更高的吞吐量。每一个连接技术在性能、灵活性、隔离特性上都有自己的优点,由Hypervisor管理的虚拟接口在性能上比不上实现SR-IOV技术的虚拟接口,但是Hypervisor管理下的虚拟接口更容易配置,更容易支持VM的迁移。我们要根据VNF的负载去选择不同的方式。

1.4.3 网络安全问题

安全是电信行业重要的部分。在虚拟环境下,安全攻击的可能性大大增加。NFV中网络功能的安全性应该等于或者接近现在网络功能的安全级别。根据功能域提供如下的相应安全措施:

(1)虚拟环境域可能存在未经认证的接入或者数据的泄露。安全系统需要在空间上隔离服务型虚拟机,提供认证控制,阻止未经认证的接入或者数据的泄露。

(2)计算域分享计算资源,例如CPU、内存等。安全系统需要建立安全的线程,在存储单元被重新分配前擦除之前的内容,在数据被使用或存储时进行加密。

(3)基础设施域(网络部分)分享逻辑的网络层(vSwitch)和物理的NICs。安全系统需要利用安全的网络技术,例如TLS、IPSec、SSH等。

(4)使用APIs提供应用域可编程的编排以及与基础设施层的交互。

另外,像数据通信、VM间的迁移等都需要在安全的环境下进行。

1.4.4 NFV的标准问题

传统电信运营商提供的业务构建在完善标准的基础上,基于NFV的宽带网络由于硬件虚拟化技术的应用,其网络架构发生实质性的变化。新的架构产生了新的逻辑功能单元,如Orchestrator、VNFM、VIM等,这些功能单元之间、功能单元与VNF及VM之间均产生了新的接口。虚拟化的网络环境下,哪些接口需要进行标准化,哪些接口可以采用私有接口不进行开放,这些问题均需要明确并进行相关的标准化工作。在虚拟化的环境下,部分逻辑网元间的接口及协议未发生变化,但原有的接口及网元的交换流程有可能发生变化,如EMS与OSS之间,将新增虚拟化相关的网管信息及设备运行维护信息。

1.4.5 系统集成问题

NFV本身解决的是业务网络的自动部署问题,从架构看也是一个巨型的ICT系统集成工程,分解一下包括NFVI的集成、VNF的集成和业务网络的集成,涉及的系统、厂家、地域、接口都非常多,工程难度比目前的公共云和私有云更高;虽然是自动部署,但目前电信网络部署的各环节(规划、实施、调测、升级、优化、运维等)都会涉及并执行,如何进行实施部署将是一个很复杂的问题,对集成商的技术要求非常高。

1.4.6 运营商业务引入NFV问题

如何引入NFV,运营商面临技术路线、网络架构、业务部署、运维模式的重大选择。

(1) NFV增加了网络运营灵活性,降低了网络产品实现门槛,但是显著增加了网元的集成难度,对运营商的软件能力提出了极大要求,NFV提供的业务快速迭代需求是建立在运营商强大的软件开发集成能力之上的。针对硬件资源层、虚拟资源层、虚拟网络功能层中的每一层,运营商面临的重要问题是选择自主开发还是依赖厂商。“自主开发”需要维持较大规模的开发团队,及时发现需求,快速开发产品;而“依赖厂商”是继续沿用传统的规范制定、测试、采购方式,导致业务的部署和更新周期长、节奏慢。

(2) NFV实现网络设备及连接控制的软硬件分离,使得各种资源可集中管理、动态调度,提供更灵活的网络功能设计和结构规划空间。运营商网络架构需要调整为网络重构或者逐步演进。网络重构需要大规模地新建虚拟化网元,直接部署在数据中心,替换核心网机房里的传统设备,统一规划电信云和私有云、硬件资源池和虚拟资源池,虽然这种方式可以最大化地发挥优势,但是系统风险大。逐步演进的方式是逐步探索和制定NFV的管理、维护方案及配套流程,采用虚拟化技术逐步替换现有网元,最终过渡到全NFV网络,但是此方式需要兼顾两种网络架构而且兼容互通要求。现在行业考虑采用第二种方式,NFV要与现有系统兼容、共存。

(3)传统网络业务部署的流程是先根据所部署的业务进行网络容量测算,然后采集硬件设备,最后调试上线。而在虚拟化网络中,NFV先实现业务编排,然后计算并申请资源池中的资源,最后完成网络能力的部署,这使得现有业务部署的流程需要打破和革新。

(4) NFV呈现了一个高度灵活、可编程的网络,需要定制化、精细化的运营机制相匹配才能有效发挥作用。NFV增强了网络的自动化能力,能够大大地减轻传统运维的压力,提升运维的效率,但对运维转型提出了新的要求。以往的维护模式是以网络设备为单元,依靠管理平台收集、监管、呈现网络状态,保障网络质量;而在虚拟化网络中,需要依靠软件实现自动化的运维服务。在日常维护中,运营商提供NFV资源调度软件对VNF进行维护,硬件需要由云资源维护团队统一负责,因此维护人员除了掌握传统电信技术、协议外,还需掌握NFV系统基本知识,同时精通IP、IT、虚拟资源管理算法及软件,这对现行的运维模式产生了较大的冲击。