OpenStack再进一步：部署NFV还需要什么

对于电信网络功能虚拟化(NFV)架构而言, OpenStack并不是一个固守现状的方案。OpenStack是一个开源的云管理技术，可提供任何NFV环境中所需的很多能力。这已在许多电信运营商中激起了极大兴趣。

但要实现NFV的所有优势，运营商需要一个NFV平台，能够提供额外的能力以支持分布式的云、增强的网络控制、生命周期管理和高性能的数据平面。

OpenStack/NFV回顾

2010年，RackSpace 和NASA联合发布了OpenStack ，这是一个开源的云计算平台。从那时开始，OpenStack社区得到了极大的发展势头，超过200家公司加入进来。

最初，OpenStack本身并非按照运营商需求想法而设计。所以，在2012年，一些主要的电信运营商发起了旨在将虚拟化和云的理念应用于电信领域的活动。

网络功能虚拟化这一术语正是因此而产生。运营商要求厂商创建虚拟化的网络功能(VNFs)和NFV平台，以帮助他们在部署业务时更加灵活便利，并降低设备和运维成本。

为弥补OpenStack和其他相关开源项目的不足，业界主要的相关方在2014年9月以Linux 基金会合作项目的形式创建了“NFV开源平台”。其目的是为NFV创建一个运营商级的开源的参照平台。业界各方将共同创建这一平台以推动NFV的演进并保证一致性、性能以及多个开源组件间的互通性。

目前，针对电信NFV环境，OpenStack在下述5个方面是有所欠缺的：

1. 分布式。在IT的世界里，企业试图将其数据中心聚合起来以降低成本。但对于NFV而言，这并非总是最佳选择。很多NFV应用要求低时延的实时响应。NFV应用也需要高可用性和灾难生存能力。运营商需要灵活性以便将网络功能部署在一个分布式的架构上— 无论是网络核心、城域边缘、接入甚至可能是客户侧。

图1. 分布式的NFV架构

OpenStack支持Cell，Region和Availabilities Zone，但这些概念对于NFV需求还不够。每个OpenStack的Region提供相互隔离的API端点，各Region间没有协调。典型情况下，一个数据中心中可能有一个或多个Region。Cell组件可提供一个单一的API端点用于汇聚多个Region。

利用Cell，跨Cell的负载分配(“调度”)通过明确的指定或随机选择而生成。Cell组件没有分配机制来基于应用需求选择最佳的位置。

2. 网络连接。VNF根据其网络需求而千变万化。由于它们是部署在整个NFV架构上的，NFV网络的基本需求就是连接，包括数据中心内部的和跨广域网的。基于安全性考虑，要求不同的网络功能仅在需要交换数据时才彼此相连，而NFV控制、数据和管理流量应当相互隔离。

由于网络功能被分解到诸如数据平面组件和一个集中化的控制平面组件中，这些组件间的连接需要保持与传统的集成式架构同样的高可靠性，需要有足够的网络资源以保证来自其它应用的突发流量不会对NFV应用造成影响。

网络应当具备相应的弹性对抗设备故障和不可抗灾难。时延和抖动会有较多变化，从某些控制和管理系统的数百毫秒，到移动网关和云化RAN的几个毫秒。

NFV网络通常包含一个半静态的物理层架构，还有一个更加动态的overlay网络层以满足VNF的需要。Overlay层需要对某些需求做出快速响应，例如业务需求变更和新业务部署。

OpenStack Neutron是OpenStack的网络组件，提供抽象化能力，例如L2和L3的网络，子网、IP地址和虚拟化的中间设备。Neutron具备一个基于插件的架构。连接请求发送给Neutron后，被转发到Neutron中安装的插件，这些插件用于对当前网络的细节进行处理。Neutron被限制在一个单一的网络资源空间内，这些资源通常与一个OpenStack region相关联。无法直接对多个网络域进行跨接，并管理WAN的能力。

关键点： 运营商需要一个平台来建立和管理局域网和广域网(LAN and WAN)架构，以可编程模式创建的运营商应用需要这一架构。

3. 自动化的生命周期管理。作为一个基于软件的方案，NFV一个最大的优势就是其实现运维流程自动化的能力。包括应用的整个生命周期，从部署到监控、伸缩、故障恢复和升级，直到退出。研究表明，这种自动化能力将使得运营商在某些情况下能缩减超过50%的运维成本(OPEX)。

OpenStack Heat允许用户创建模板，以组件资源的语言来描述虚拟应用(“stacks”)，例如包含嵌入式stack的虚机。早期，Heat模板基于AWS CloudFormation ，但最近，Heat编排模板(HOT)的引入，提供了额外的表达呈现能力。Heat聚焦于定义和部署应用stack，但对生命周期的其他阶段，并无特别支持。

OpenStack Solum是一个新项目，被设计用于使云业务更易被购买使用以及集成在开发流程中。它被设计用来提供某些缺失的生命周期自动化功能。通过将 OpenStack Ceilometer的评估能力与Heat相结合，在自动伸缩方面已经开展了一些早期的工作。Heat 目前受限于单一的OpenStack领域。

关键点： 运营商需要一个平台，不仅能够对部署和伸缩实现自动化，还要对复杂的运营商应用中的很多其它生命周期运维工作实现自动化，并附带许多组件功能。

4. NFV架构运维。NFV架构的分布性，跨越运营商网络上的许多位置 – 而不是少数集中的位置 – 这就带来一些特有的挑战，并将影响运维流程和支撑系统。相较于一个集中化的云，NFV的分布式架构意味着，不同位置的云节点的添加、升级、和/或移除将更为频繁。这些过程将尽可能的在远端进行，避免跨区的现场支持。

OpenStack TripleO (OpenStack on OpenStack) 是一个对OpenStack家族实验性的新增功能。该项目旨在使用OpenStack自有的云工具实现OpenStack云的安装、升级和运维的自动化。 TripleO使用Heat在裸机架构上部署OpenStack实例。

关键点： 运营商需要一个针对分布式NFV架构而特别设计的平台，该平台可对复杂的软件stack部署和升级流程实现自动化。

5. 高性能数据平面。很多运营商网络的功能(比如深度包检测、媒体网关、会话边界控制器和移动核心服务网关以及分组数据网络网关)目前是基于定制化硬件实现的，为的是获得更高的处理能力和输入输出吞吐量。在商业服务器上以hypervisor运行这些功能会导致10倍的性能下降。

业界目前正在对新技术加以研究，这些新技术有望提升商业服务器上的数据平面性能，某些情况下甚至接近定制化硬件的水平。

然而，数据平面性能在OpenStacks社区一直是个边缘化的领域。直到最近，随着Juno版本的发布，更多的人开始关注数据平面的加速问题。Juno为虚机调用英特尔的Single Root I/O虚拟化技术提供支持。

关键点： 运营商需要一个平台，用于管理商业服务器上的高性能数据平面网络功能。

OpenStack再进一步：现在部署NFV还需要什么?

全球大多数的运营商都在寻找一个基于OpenStack的开放、多厂商的NFV平台。但正如我们所提到的，OpenStack社区在某些关键NFV 需求上没有给予足够的关注。所缺失的是一个NFV平台，该平台要超越OpenStack的范畴，以帮助客户实现CAPEX和OPEX的削减以及提升业务灵活性的目标。

OpenStack在某些方面仍然处于密集开发的状态。一旦其成熟，OpenStack的功能将更为稳定和丰富，使其更好的满足某些领域的NFV需求。然而，它不可能满足所有需求。

运营商需要一个水平化的NFV平台来提供：

用于VNF的计算、存储和网络资源一个用于NFV编排(NFVO)的集中化平一个用于管理VNF生命周期的集中化VNF管理器(VNFM)这一方式使得消除今天多应用形成的竖井式结构成为可能。

原文链接：http://www.cnii.com.cn/technology/2015-10/23/content_1640533_3.htm

关于OpenStack