如今，运营商对于网络功能虚拟化 (NFV) 的优势已经达成普遍的认同。然而传统的单机部署方式并不能够帮助NFV所带来服务所需的敏捷性，这就意味着要采用云平台这种强有力的基础设施抽象化方式。OpenStack 在构建 NFV 基础设施 (NFVI) 方面起着至关重要的作用。但 OpenStack 的设计初衷是管理公有云中的应用负载，因此将其应用在通信行业时，必须对其进行扩展以满足运营商级需求。
借助云技术体系实现 NFV
虚拟化基础设施管理器 (VIM) 的作用
在 NFV 情境下，VIM 位于 NFV 管理和编排 (MANO) 体系的最底层（参见图 1）。ETSI NFV 小组将 NFVI 的虚拟化层（操作系统和虚拟机管理程序）与 VIM 做了区分。
NFV参考架构
图1：NFV参考架构
开源与云化基础设施
云市场中有种日益增长的趋势，那就是普遍采用开源软件来实现云化基础设施。Heavy Reading 的研究表明，有很大比例的运营商都想在虚拟化层中采用开源 Linux 操作系统和 KVM 虚拟机管理程序以及将 OpenStack 用作 VIM。
OpenStack 之所以成为 VIM 主流的开源选择，是因为 OpenStack 的插件化和可编程架构，这种架构便于添加新特性。许多运营商都设想构建一个基于 Linux-KVM-OpenStack 体系的 NFV 云 (NFVI) 和 NFVI 管理层。
实现基于 OpenStack 的运营商级 VIM
为什么 OpenStack 要具备运营商级特性？
OpenStack 的设计初衷是为那些由全网规模的企业所构建的无状态 Web 应用管理公有云基础设施。这些 Web 应用通常称为“牛群 (cattle)”负载，因为牛是消耗品 — 一头牛病倒了可以再找一头牛替代它。因此，牛群负载几乎不需要维护，如果它们发生了硬件或虚拟机 (VM) 故障，换掉就是了。
VNF 与公有云负载截然不同。许多 VNF 都对 VM 在云基础设施上的部署方式有着非常具体的、细粒度的要求，这是因为这些 VNF 需要一致的、可预测的性能和极低的延迟。电信网络的运营商级需求与公有云的需求全然不同，因此 OpenStack 及其处理的虚拟化层需要扩充运营商级特性来支持运营商网络对响应时间的严苛要求。
OpenStack 是一个优秀的开源软件工程，每个新版本都更稳定、更成熟，但同时它又高度复杂，每半年就会增加数千行代码，因此更像是一个松散耦合的工具集而非一个经过测试、集成、可立即投入运行的解决方案。开发人员往往醉心于在主干代码中添加新特性，常会忽视一些普通但重要的问题，如错误修复和运营稳定性。因此，OpenStack 需要变得更健壮，能在任何环境供生产使用，当然也包括运营商级场景。而且，在运营商级情境下，OpenStack 必须得有一套适当的运营特性。
帮助 OpenStack 以运营商级方式管理 NFVI 的扩展
在性能方面，OpenStack 的运营商级扩展需要考虑：
·虚拟 CPU (vCPU) 拓扑配置。为了准确地在云资源上部署（或“调度”）VNF，OpenStack 的调度组件 Nova 需要更精细地了解资源以及资源是否配置得当以提供 VNF 所需的性能。该运营商级扩展能让 OpenStack 以更灵活的方式向客户机 VM 提供插槽和 vCPU（内核）的组合。
·客户机 vCPU 绑定物理 CPU (pCPU)。该特性与上一特性互为补充，因为 Nova 需要有个机制来确保所选择的虚拟拓扑能绑定到特定的物理 CPU 上以保障性能。
·客户机非一致性内存访问 (NUMA) 节点部署和拓扑感知能让 OpenStack 了解服务器资源的分区方式以及 CPU、输入/输出 (I/O) 设备和内存等与插槽的连接方式。这可确保在 NUMA 宿主机上执行负载的 CPU 使用本地内存，不会因访问其他 NUMA 节点上的 RAM 而导致延迟。该扩展还支持跨 NUMA 节点的新 OpenStack 类型模板，从而帮助客户机 OS 智能地确定如何在这些节点之间分配负载。
·基于 I/O (PCIe) 的 NUMA 调度。基于 I/O 的 NUMA 调度支持对已分配有宿主机 PCI 设备的客户机 VM 进行智能的 NUMA 节点部署，从而再次避免不必要的、可导致延迟的内存事务。
·为客户机 RAM 分配大页面内存。这将启用在公有云场景中通常禁用的大页面特性。执行高速 I/O 操作的 VNF 需要持续访问支持超大页面的服务器上的内存。这与公有云恰恰相反。
·PCI SR-IOV 网络直通支持。该特性使 Nova 能够感知 Neutron 端口可用于调度的相关物理网络。
下列这组扩展能在 OpenStack 作为虚拟网络控制点运行时提供 99.9999% 的可靠性：
·双控制节点架构可确保高可用性。OpenStack 采用单节点控制架构，当控制器发生故障时，实例化的 VM 将继续运行，但无法监视其运行状况。运营商级版本则提供一对同步的控制节点，两者之间可进行亚秒级故障切换。
·改进的 Ceilometer 可扩展性和性能可增强监控以及对当前分散在不同 OpenStack 组件上的监控数据（性能量度、故障和警报）的整合。
·改进的 VM 管理功能，如亚秒级 VM 死机检测，与之相比，非运营商级 OpenStack 实现执行此操作则需要 60 秒。
·支持软件滚动升级。该特性是在 OpenStack 主干代码中逐步实现的，以免每次发布新代码时都要重新安装 OpenStack。
·改进的安全特性，如支持 AAA 安全性基础设施、基于角色的身份验证和高可用性 (HA) 存储。
·可扩展性增强：运营商级的 OpenStack 版本需要支持数百个计算节点来实现大规模 VNF 分布，最终通过联合不同的 OpenStack 域来支持分布式 VNF。
·一键安装。运营商级 OpenStack 的实施应当能简单、快速地安装 — 例如，从 U 盘不到 30 分钟就安装完成。
实现运营商级 OpenStack 的路径
对运营商而言，依靠自身力量开发出一套符合运营商级要求的OpenStack显然需要花费大量的时间和经历。NFV 市场还处在非常原始的阶段，但想要发展，首先需要的就是行动起来。因此在 NFV 建设过程中，选择适当的 OpenStack 提供商就成了一条更为有效的实现途径。
只要所选的 OpenStack 提供商参与社区事务并且是开源软件和开源方案的坚定支持者，那所用的 OpenStack 版本有悖标准的风险还是很低的。就 NFV 而言，OpenStack 实现的稳定性、性能和支持水平与其跟主干代码的一致性同样重要。
运营商应当注意其选择的运营商级 OpenStack 提供商不能仅仅是为社区提供专有开发。它们应当评估供应商在社区中的活跃度，包括加入时间、提交记录、既往贡献与其在社区中认可度的相关性，例如供应商员工被选为社区领导。虽然供应商可以先于社区满足市场需求从而增强自己在 OpenStack 方面的差异化竞争，但只要供应商快速用更先进的软件版本替代其专有开发并向上游流程提交自己开发的功能，那其运营商级 OpenStack 实现就会逐渐成为标准。
据惠普企业 (HPE) NFV 技术顾问陈艳庆介绍，HPE 是 OpenStack 项目的主要领导者，拥有2名董事会成员和3名技术委员会成员，是 OpenStack 社区的首席贡献着。在 OpenStack 领域，HPE 提供三种产品以满足不同用户的需求：
·社区版：基于原生 OpenStack 代码构建，同时 HPE 在此基础上进行了自动化安装、基本的功能测试、bug修复和系统加固等工作。
·企业版：HPE 进行了充分的测试和系统加固工作，完善了平台功能，提高了稳定性和性能，旨在满足企业级应用在按群星、高可用性、高可扩展性方面的要求。
·电信版：基于企业版构建，扩展了对电信级应用（如：NFV）的支持，包括多样的数据面和虚拟化层的加速方案、高效的故障检测和恢复机制、以及智能的虚拟化网元管理功能。
总结
OpenStack 是 ETSI NFV 架构的一个重要组成部分，在将物理基础设施抽象化为可编程的云平台以及在云上管理负载方面发挥着关键作用。尽管从运营商级性能的角度来看，OpenStack 作为云管理层尚有些不足，但 OpenStack 社区正通过多种途径为其增加至关重要的运营商级功能，包括由供应商、OPNFV 联盟和 NFV 子小组等开发的功能。
不过，相关供应商不仅应致力于通过上游流程为 OpenStack 社区提供扩展，还应在第一时间采纳社区认可的运营商级特性。选择 OpenStack 供应商的一个关键标准就是供应商在 OpenStack 社区中的影响力。这要看供应商的贡献记录、其 OpenStack 实施的参与度以及因服务社区而获得的尊重程度。
供应商围绕 OpenStack 所做的创新将使运营商能够尽早享受 NFV 的优势。随着主流运营商掌握 NFV 并建立新的服务敏捷性基准，那些希望保持竞争力的运营商将不得不紧跟步伐。只要 OpenStack 的运营商级特性越来越标准化，其作为运营商首选 VIM 的前景将一片光明。
来源：
