OpenStack再进一步：部署NFV还需要什么
你好，游客
OpenStack再进一步：部署NFV还需要什么
来源：OneAPM_Official&
　　对于电信网络功能(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)这一方式使得消除今天多应用形成的竖井式结构成为可能。
相关新闻 & & &
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款私有云外围环境支持（包括支持CDN 、商业SDN控制器、防火墙和VPN/专线等）
向上扩展性（PaaS 和 SaaS 等支撑）
企业数据中心IT环境支持（包括裸金属/Bare metal、F5 、、跨云网络连通、租户计费、备份等支持）
行业解决方案 （、大数据、等等）
成体系的服务，包括培训、运维、支持等
&本文原文于
发表于 CSDN ，作者为本人，编辑记者为陈晨luminous&。
1. NFV 和相关的国际组织和社区
1.1.1 定义
& &NFV 的全称是 Network Functions Virtualisation，即网络功能虚拟化。先来看看它的定义：&网络功能虚拟化（NFV）是利用在通用的计算、存储、网络接口和交换架构之上构建的云计算虚拟化技术来承载（host）、链（chain）和管理（manage）标准化的虚拟网络功能（virtual network functions (VNFs)）的一种可扩展的弹性的网络服务进化模型。&。
& &在解释之前，先看下面这张图，你基本就会明白了它的含义：
& 上图中，左边是传统的网络功能，比如防火墙、NAT、负载均衡、DNS、DPI 等等，它们都是由专有的（定制的）、集成的（数据面和控制面在一个设备之中的）的硬件设备提供的；右边是 NFV，它是开放的弹性的方案，由在构建于标准的硬件（基本上是x86服务器和商用的存储和网络设备）上的云环境中的物理机或者虚机或者容器内的标准化的提供虚拟网络功能的软件提供网络功能。和传统的方案相比，NFV&中，网络功能都是虚拟化的，因此都变成了 vFW、vNAT、vLB 等等。
&简单来说，NFV 是运行在标准云之上的应用提供虚拟网络服务的一种新的架构。相比之下，SDN 是承载 NFV 的云基础架构层中提供网络虚拟化的一个组件。因此，NFV 和 SDN 处于NFV架构中的不同的层面，承担不同的功能。
1.1.2 为什么要 NFV
下图是 SDxCentral 网络的一个用户调查显示的使用 NFV 的驱动力：
敏捷性和灵活性是主体，占50%比重，这个可以从上面的图中也能看出来
VNF 的安装部署更方便
测试新的 VNF 会更加的方便和快速
避免升级当前系统来部署新的 NFV
降低运行和投入成本，合计占36%，主要包括：
使用 COTS 硬件，来降低硬件成本
可以使用共享的 VNFI，减少投入
商业硬件的更新周期会更快，能做到更快地提升性能和功能
加速市场适应能力，占 14%
1.2 NFV 相关的国际组织和社区
&ETSI:&European Telecommunications Standards Institute &欧洲电信标准化组织&
2012年11月，国际上七大电信网络运营商选择 ETSI 作为 NFV 行业规范制定组织，来制定他们所需要的 NFV 标准，并且在成员之间共享经验和做早期实现。目前，ETSI NFV 已经发展为包括主要电信企业和IT提供商的 超过 270 家企业的一个国际组织。来自国内的几个参与者：
组织成员：中国电信、中兴、华为
参与者：移动、联通、H3C
ETSI NFV 组的主要工作就是制定 NFV 标准。他们已经发布的 NFV 标准架构为：
该架构有三个主体组成部分：
NFVI：NFV Infustructure，即运行 NFV 应用的云基础设施即服务层。
VNFs：Virtual network functions，在 NFV 架构中提供虚拟网络功能的各种应用。
MANO：NFV Management & Orachastration，即 VNFs 管理和编排组件，管理各个 VNF 的生命周期（包括安装、扩展、升级和卸载等），以及 VNF 需要的虚拟化资源的管理。
1.2.2 &- Open NFV
OPNFV 是一个开放社区（Open Community），它致力于使用开源的组件来实现符合 ETSI NFV 标准架构要求的运营商级别的、整合的、开放的平台。可见，OPNFV 的目的是整合一些开源方案，做 NFV 开源的产品化。它的实现的几个特点：
选择一系列的开源组件来构建一个开放的符合 ETSI ISG NFV 参考架构要求的实现，包括打包、安装程序、文档、测试案例和文档等
向各开源项目提出 NFV 的需求
使用 OpenStack 作为 VNFI（这也是为什么 OpenStack 社区急吼吼地喊出在 NFV 上要实现对 VMware 的弯道超车了）。
使用 Linux 作为各个节点的操作系统
支持 SDN 和标准的 Neutron
VNF 可以部署在物理机或者虚拟内（将来可以部署在容器内）
选择&Apex、Compass、Fuel 和 Joid 作为部署工具
OPNFV 于2016年3月发布的最新的&Brahmaputra 版本的架构：
该架构的几个特点：
使用 OpenStack Liberty 版本
使用 DPDK 和 ODP 做数据平面加速
支持 OpenDaylight、OpenContrail、ONOS 等开源 SDN 以及基于 OVS 的标准 Neutron
使用 KVM 和 Ceph
2. 两个 NFV 产品的架构
有 ETSI NFV 组负责制定 NFV 标准，有 OPNFV 负责提供开放实现的参考架构，那各个公司就知道自己的在其中的位置了：OpenStack 厂商忙着说自己的产品可以作为 NFVI，电信应用厂商说他们的产品可以提供NVFs，MANO 厂商说他们的产品可以作为 MANO 等等。
2.1 Mirantis NFS 参考架构
Mirantis 在 ETSI NFV、OPNFV 和 OpenStack 等开放组织内都是核心成员，而且它成立了专门的 NFV 部门（部门 Leader Sutapa Bansal 在加入 Mirantis 之前在 Cisco 和 Juniper 都工作过，因此具有深厚的网络行业背景）。他们在 2015 年9 月份发布的 MOS 7.0 中就增加了对 NFV 的支持，其技术架构为：
该架构的几个特点：
Mirantis 提供运营商级别的 OpenStack 平台作为 NFVI，包括 SDN、数据平面加速以及其它增强
Mirantis 联合许多商业合作伙伴提供 VNFs 和 MANO
Mirantis 做整合和测试
该实现架构的特点和他们目前的合作伙伴：
以提供 vSBC VNF 的 Metaswitch 公司为例，该公司看起来有相当强的实力：
2.2 HP 的 NFV 参考架构
几个特点：
HP 自己提供 OpenStack 和 SDN 作为 VNFI
HP 自己有 VFN Director 作为 MANO
没有说明 VNF 和 VNF managers 的来源
3. NFV 对 OpenStack 的需求
2. 扩展性：需要跨地域的扩展性
1. RAS 需要满足运营商级别的要求：VNF 的可靠性必须达到 99.999%；安全性和QoS比如和物理网络相同等。
2.&&（有看到华为的级联OpenStack 方案）
1. SR/IOV 支持
2. OVS 性能优化和 DPDK 支持
3. 多通道 （multi-queue）vhost-user
4. 支持&Service Function Chains （SFC）
5. IPv6 支持
1.&关于 SRIOV 本身，可以参考我的&；关于 Nova 和 SRIOV，可以参考我的&
1.&NUMA/CPU pinning 支持
2.&Anti-affinity groups 支持
3. KVM Huge pages 支持
4. Nova scheduler 性能优化
其它配套项目
1.&MANO -&OpenStack Tacker 项目
2. &Congress: Policy-as-a-Service&
3. Mistral: Workflow service&
4. Neutron &Stadium& subprojects: 包括一些了 NFV 相关的项目
5. Senlin：集群即服务&
OPNFV 成员企业提出的部分 OpenStak 需求对应的 blueprint：
ETSI NFV 提出的部分 OpenStack 需求以及状态：
4. 展望和个人观点
4.1 前景展望
& & 通信业已进入4.0时代，这是一个IT与CT充分融合的时代，NFV和SDN技术是实现自动部署和敏捷运营的关键技术。NFV 代表将来，应该是比较确定的。因为随着 x86 服务器性能的进一步增强，和 IaaS 层面的云计算的进一步完善，特别是 SDN 的出现，NFV 在技术上的障碍将会逐一消除。因此，随着 NFV 一步一步落地，各大网络设备提供商和网络服务提供商在行业内的定位，将会可能出现重新洗牌的可能。
& & 同时，也应该看到，作为 NFVI 的 OpenStack 目前在稳定性、扩展性、可用性和性能方面，离 NFV 生产系统的需求还有相当长的距离。特别是考虑到电信行业运营商级别在这些方面的非常高的要求，NFV 离真正进入生产系统时间将比较长。在 VNF 应用上，也将会是按照一定的步骤分布进行。
& & 因此，目前阶段，更多的是在标准制定、应用案例和需求甄别阶段，因此，各个参与方需要做的，就是明确自己的期望再进行长期布局。近期的主要参与者，应该是以大的运营商、网络软件提供商和 OpenStack 提供商为主，他们将会通过彼此的协作去推动行业和标准。
这是 SDxCentral 的一些调查结果：
（1）如何看到 OPNFV：对 NFV Vendors、运营商和 OpenStack 等开源项目都很重要
（2）NFV 使用现状：很多人在观望，部分人在测试，还有相当一部分人没动静
网上公开可以搜索到的 NFV 测试案例包括：
2014 年 10 月韩国最大的通信服务提供商&KT 宣布将和 Alcatel-Lucent 一起在韩国测试 NFV &（）
Deutsche Telekom 同 A10 Networks 一起搭建 NFV 测试环境 （）
2015 年6月，中兴通讯宣布 &&中兴通讯独家承建的中国移动RCS项目是世界最大的基于vIMS的RCS项目，预计2015年底达到1亿用户，可以提供IMS + RCS + VoWiFi +VoLTE 融合业务。同时，它也是世界最大的NFV商用网络&。（）
2016 年 OpenStack Austin Summit 上，NFV 将会是讨论的重点之一，当时候应该会有更多的测试案例被披露出来。&
（3）实施阻力：多供应商方案的整合难度、ROI 不清晰、商业方案不成熟、软件的稳定性、安全性顾虑和转换成本等是主要阻力
4.2 对国内NFV行业的个人观点
（1）移动、电信等运营商和华为、中兴、H3C 等网络设备提供商来说，需要更多地参与 NFV 标准制定，以获得影响力和推动力。在目前的 ETSI NFV 组织中，只有中国电信、中兴和华为是成员，这应该说是远远不够的，而且这些成员到底投入多少，还是不得而知。
华为作为国内唯一、国际上也为数不多的兼具网络设备提供商和 OpenStack 产品提供商身份的公司，具有非常好的基础去推进 NFV；当然，NFV 和其当前的传统网络，也会存在左右手互搏的问题，因此可能给其策略带来不确定性。
中兴作为国内主要的网络提供商之一，能看到它在 ETSI NFV 和 OPNFV 等组织中的参与，但是，它缺乏自己的 OpenStack 产品，这在将来可能会是个潜在的问题。
移动、电信、联通等运营商，需要更多的参与 NFV 标准制定、方案测试和实施。&日，在西班牙巴塞罗那召开的世界移动通信大会期间，Linux基金会、中国移动、华为联合发起OPEN-Orchestrator (OPEN-O)项目倡议&，来加速 NFV 编排器的成熟度和商业落地 （）。
（2）对国内初创 OpenStack 公司来说，当前，在 NFV 离进入生产系统还有相当长的一段距离，特别是国内 NFV 生态成熟度还很低的情况下，一方面，需要务实地踏踏实实地把 OpenStack 私有云做好，把产品的 RAS 提高到能满足 NFV 要求的程度；另一方面，需要制定自己的NFV策略，关注NFV 的成熟度推进和商业落地情况，在适当的时机再切入。
参考资料：
阅读(...) 评论()私有云外围环境支持（包括支持CDN 、商业SDN控制器、防火墙和VPN/专线等）
向上扩展性（PaaS 和 SaaS 等支撑）
企业数据中心IT环境支持（包括裸金属/Bare metal、F5 、、跨云网络连通、租户计费、备份等支持）
行业解决方案 （、大数据、等等）
成体系的服务，包括培训、运维、支持等
&本文原文于
发表于 CSDN ，作者为本人，编辑记者为陈晨luminous&。
1. NFV 和相关的国际组织和社区
1.1.1 定义
& &NFV 的全称是 Network Functions Virtualisation，即网络功能虚拟化。先来看看它的定义：&网络功能虚拟化（NFV）是利用在通用的计算、存储、网络接口和交换架构之上构建的云计算虚拟化技术来承载（host）、链（chain）和管理（manage）标准化的虚拟网络功能（virtual network functions (VNFs)）的一种可扩展的弹性的网络服务进化模型。&。
& &在解释之前，先看下面这张图，你基本就会明白了它的含义：
& 上图中，左边是传统的网络功能，比如防火墙、NAT、负载均衡、DNS、DPI 等等，它们都是由专有的（定制的）、集成的（数据面和控制面在一个设备之中的）的硬件设备提供的；右边是 NFV，它是开放的弹性的方案，由在构建于标准的硬件（基本上是x86服务器和商用的存储和网络设备）上的云环境中的物理机或者虚机或者容器内的标准化的提供虚拟网络功能的软件提供网络功能。和传统的方案相比，NFV&中，网络功能都是虚拟化的，因此都变成了 vFW、vNAT、vLB 等等。
&简单来说，NFV 是运行在标准云之上的应用提供虚拟网络服务的一种新的架构。相比之下，SDN 是承载 NFV 的云基础架构层中提供网络虚拟化的一个组件。因此，NFV 和 SDN 处于NFV架构中的不同的层面，承担不同的功能。
1.1.2 为什么要 NFV
下图是 SDxCentral 网络的一个用户调查显示的使用 NFV 的驱动力：
敏捷性和灵活性是主体，占50%比重，这个可以从上面的图中也能看出来
VNF 的安装部署更方便
测试新的 VNF 会更加的方便和快速
避免升级当前系统来部署新的 NFV
降低运行和投入成本，合计占36%，主要包括：
使用 COTS 硬件，来降低硬件成本
可以使用共享的 VNFI，减少投入
商业硬件的更新周期会更快，能做到更快地提升性能和功能
加速市场适应能力，占 14%
1.2 NFV 相关的国际组织和社区
&ETSI:&European Telecommunications Standards Institute &欧洲电信标准化组织&
2012年11月，国际上七大电信网络运营商选择 ETSI 作为 NFV 行业规范制定组织，来制定他们所需要的 NFV 标准，并且在成员之间共享经验和做早期实现。目前，ETSI NFV 已经发展为包括主要电信企业和IT提供商的 超过 270 家企业的一个国际组织。来自国内的几个参与者：
组织成员：中国电信、中兴、华为
参与者：移动、联通、H3C
ETSI NFV 组的主要工作就是制定 NFV 标准。他们已经发布的 NFV 标准架构为：
该架构有三个主体组成部分：
NFVI：NFV Infustructure，即运行 NFV 应用的云基础设施即服务层。
VNFs：Virtual network functions，在 NFV 架构中提供虚拟网络功能的各种应用。
MANO：NFV Management & Orachastration，即 VNFs 管理和编排组件，管理各个 VNF 的生命周期（包括安装、扩展、升级和卸载等），以及 VNF 需要的虚拟化资源的管理。
1.2.2 &- Open NFV
OPNFV 是一个开放社区（Open Community），它致力于使用开源的组件来实现符合 ETSI NFV 标准架构要求的运营商级别的、整合的、开放的平台。可见，OPNFV 的目的是整合一些开源方案，做 NFV 开源的产品化。它的实现的几个特点：
选择一系列的开源组件来构建一个开放的符合 ETSI ISG NFV 参考架构要求的实现，包括打包、安装程序、文档、测试案例和文档等
向各开源项目提出 NFV 的需求
使用 OpenStack 作为 VNFI（这也是为什么 OpenStack 社区急吼吼地喊出在 NFV 上要实现对 VMware 的弯道超车了）。
使用 Linux 作为各个节点的操作系统
支持 SDN 和标准的 Neutron
VNF 可以部署在物理机或者虚拟内（将来可以部署在容器内）
选择&Apex、Compass、Fuel 和 Joid 作为部署工具
OPNFV 于2016年3月发布的最新的&Brahmaputra 版本的架构：
该架构的几个特点：
使用 OpenStack Liberty 版本
使用 DPDK 和 ODP 做数据平面加速
支持 OpenDaylight、OpenContrail、ONOS 等开源 SDN 以及基于 OVS 的标准 Neutron
使用 KVM 和 Ceph
2. 两个 NFV 产品的架构
有 ETSI NFV 组负责制定 NFV 标准，有 OPNFV 负责提供开放实现的参考架构，那各个公司就知道自己的在其中的位置了：OpenStack 厂商忙着说自己的产品可以作为 NFVI，电信应用厂商说他们的产品可以提供NVFs，MANO 厂商说他们的产品可以作为 MANO 等等。
2.1 Mirantis NFS 参考架构
Mirantis 在 ETSI NFV、OPNFV 和 OpenStack 等开放组织内都是核心成员，而且它成立了专门的 NFV 部门（部门 Leader Sutapa Bansal 在加入 Mirantis 之前在 Cisco 和 Juniper 都工作过，因此具有深厚的网络行业背景）。他们在 2015 年9 月份发布的 MOS 7.0 中就增加了对 NFV 的支持，其技术架构为：
该架构的几个特点：
Mirantis 提供运营商级别的 OpenStack 平台作为 NFVI，包括 SDN、数据平面加速以及其它增强
Mirantis 联合许多商业合作伙伴提供 VNFs 和 MANO
Mirantis 做整合和测试
该实现架构的特点和他们目前的合作伙伴：
以提供 vSBC VNF 的 Metaswitch 公司为例，该公司看起来有相当强的实力：
2.2 HP 的 NFV 参考架构
几个特点：
HP 自己提供 OpenStack 和 SDN 作为 VNFI
HP 自己有 VFN Director 作为 MANO
没有说明 VNF 和 VNF managers 的来源
3. NFV 对 OpenStack 的需求
2. 扩展性：需要跨地域的扩展性
1. RAS 需要满足运营商级别的要求：VNF 的可靠性必须达到 99.999%；安全性和QoS比如和物理网络相同等。
2.&&（有看到华为的级联OpenStack 方案）
1. SR/IOV 支持
2. OVS 性能优化和 DPDK 支持
3. 多通道 （multi-queue）vhost-user
4. 支持&Service Function Chains （SFC）
5. IPv6 支持
1.&关于 SRIOV 本身，可以参考我的&；关于 Nova 和 SRIOV，可以参考我的&
1.&NUMA/CPU pinning 支持
2.&Anti-affinity groups 支持
3. KVM Huge pages 支持
4. Nova scheduler 性能优化
其它配套项目
1.&MANO -&OpenStack Tacker 项目
2. &Congress: Policy-as-a-Service&
3. Mistral: Workflow service&
4. Neutron &Stadium& subprojects: 包括一些了 NFV 相关的项目
5. Senlin：集群即服务&
OPNFV 成员企业提出的部分 OpenStak 需求对应的 blueprint：
ETSI NFV 提出的部分 OpenStack 需求以及状态：
4. 展望和个人观点
4.1 前景展望
& & 通信业已进入4.0时代，这是一个IT与CT充分融合的时代，NFV和SDN技术是实现自动部署和敏捷运营的关键技术。NFV 代表将来，应该是比较确定的。因为随着 x86 服务器性能的进一步增强，和 IaaS 层面的云计算的进一步完善，特别是 SDN 的出现，NFV 在技术上的障碍将会逐一消除。因此，随着 NFV 一步一步落地，各大网络设备提供商和网络服务提供商在行业内的定位，将会可能出现重新洗牌的可能。
& & 同时，也应该看到，作为 NFVI 的 OpenStack 目前在稳定性、扩展性、可用性和性能方面，离 NFV 生产系统的需求还有相当长的距离。特别是考虑到电信行业运营商级别在这些方面的非常高的要求，NFV 离真正进入生产系统时间将比较长。在 VNF 应用上，也将会是按照一定的步骤分布进行。
& & 因此，目前阶段，更多的是在标准制定、应用案例和需求甄别阶段，因此，各个参与方需要做的，就是明确自己的期望再进行长期布局。近期的主要参与者，应该是以大的运营商、网络软件提供商和 OpenStack 提供商为主，他们将会通过彼此的协作去推动行业和标准。
这是 SDxCentral 的一些调查结果：
（1）如何看到 OPNFV：对 NFV Vendors、运营商和 OpenStack 等开源项目都很重要
（2）NFV 使用现状：很多人在观望，部分人在测试，还有相当一部分人没动静
网上公开可以搜索到的 NFV 测试案例包括：
2014 年 10 月韩国最大的通信服务提供商&KT 宣布将和 Alcatel-Lucent 一起在韩国测试 NFV &（）
Deutsche Telekom 同 A10 Networks 一起搭建 NFV 测试环境 （）
2015 年6月，中兴通讯宣布 &&中兴通讯独家承建的中国移动RCS项目是世界最大的基于vIMS的RCS项目，预计2015年底达到1亿用户，可以提供IMS + RCS + VoWiFi +VoLTE 融合业务。同时，它也是世界最大的NFV商用网络&。（）
2016 年 OpenStack Austin Summit 上，NFV 将会是讨论的重点之一，当时候应该会有更多的测试案例被披露出来。&
（3）实施阻力：多供应商方案的整合难度、ROI 不清晰、商业方案不成熟、软件的稳定性、安全性顾虑和转换成本等是主要阻力
4.2 对国内NFV行业的个人观点
（1）移动、电信等运营商和华为、中兴、H3C 等网络设备提供商来说，需要更多地参与 NFV 标准制定，以获得影响力和推动力。在目前的 ETSI NFV 组织中，只有中国电信、中兴和华为是成员，这应该说是远远不够的，而且这些成员到底投入多少，还是不得而知。
华为作为国内唯一、国际上也为数不多的兼具网络设备提供商和 OpenStack 产品提供商身份的公司，具有非常好的基础去推进 NFV；当然，NFV 和其当前的传统网络，也会存在左右手互搏的问题，因此可能给其策略带来不确定性。
中兴作为国内主要的网络提供商之一，能看到它在 ETSI NFV 和 OPNFV 等组织中的参与，但是，它缺乏自己的 OpenStack 产品，这在将来可能会是个潜在的问题。
移动、电信、联通等运营商，需要更多的参与 NFV 标准制定、方案测试和实施。&日，在西班牙巴塞罗那召开的世界移动通信大会期间，Linux基金会、中国移动、华为联合发起OPEN-Orchestrator (OPEN-O)项目倡议&，来加速 NFV 编排器的成熟度和商业落地 （）。
（2）对国内初创 OpenStack 公司来说，当前，在 NFV 离进入生产系统还有相当长的一段距离，特别是国内 NFV 生态成熟度还很低的情况下，一方面，需要务实地踏踏实实地把 OpenStack 私有云做好，把产品的 RAS 提高到能满足 NFV 要求的程度；另一方面，需要制定自己的NFV策略，关注NFV 的成熟度推进和商业落地情况，在适当的时机再切入。
参考资料：
阅读(...) 评论()