OpenStack 企业私有云的若干需求（7）：电信行业解决方案 NFV

<本文原文于 20016/01/11 发表于 CSDN 从OpenStack视角看NFV，作者为本人，编辑记者为陈晨luminous>。

1. NFV 和相关的国际组织和社区

1.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 相关的国际组织和社区

1.2.1 ETSI’s Industry Specification Group on Network Functions Virtualisation (ISG 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 OPNFV - 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 的需求

类别 需求 说明
总体

1. 可靠性

2. 扩展性：需要跨地域的扩展性

3. 稳定性

4. 弹性

1. RAS 需要满足运营商级别的要求：VNF 的可靠性必须达到 99.999%；安全性和QoS比如和物理网络相同等。

2. https://wiki.opnfv.org/display/multisite （有看到华为的级联OpenStack 方案）
网络

1. SR/IOV 支持

2. OVS 性能优化和 DPDK 支持

3. 多通道 （multi-queue）vhost-user

4. 支持 Service Function Chains （SFC）

5. IPv6 支持

1. 关于 SRIOV 本身，可以参考我的 KVM 介绍（4）：I/O 设备直接分配和 SR-IOV [KVM PCI/PCIe Pass-Through SR-IOV]；关于 Nova 和 SRIOV，可以参考我的 OpenStack 企业私有云的若干需求（1）：Nova 虚机支持 GPU

2. OVS 性能优化 

3. 服务功能链（SFC）
计算

1. NUMA/CPU pinning 支持

2. Anti-affinity groups 支持

3. KVM Huge pages 支持

4. Nova scheduler 性能优化

https://wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement
其它配套项目

1. MANO - OpenStack Tacker 项目

2.  Congress: Policy-as-a-Service 

3. Mistral: Workflow service 

4. Neutron “Stadium” subprojects: 包括一些了 NFV 相关的项目

5. Senlin：集群即服务 

https://wiki.openstack.org/wiki/Tacker

https://wiki.openstack.org/wiki/Congress

https://wiki.openstack.org/wiki/Mistral

http://governance.openstack.org/reference/projects/neutron.html

https://wiki.openstack.org/wiki/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 标准制定、方案测试和实施。”2016年2月23日，在西班牙巴塞罗那召开的世界移动通信大会期间，Linux基金会、中国移动、华为联合发起OPEN-Orchestrator (OPEN-O)项目倡议“，来加速 NFV 编排器的成熟度和商业落地 （来源）。

（2）对国内初创 OpenStack 公司来说，当前，在 NFV 离进入生产系统还有相当长的一段距离，特别是国内 NFV 生态成熟度还很低的情况下，一方面，需要务实地踏踏实实地把 OpenStack 私有云做好，把产品的 RAS 提高到能满足 NFV 要求的程度；另一方面，需要制定自己的NFV策略，关注NFV 的成熟度推进和商业落地情况，在适当的时机再切入。

参考资料：

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/sammyliu/p/5346565.html