标签:
<本文原文于 20016/01/11 发表于 CSDN 从OpenStack视角看NFV,作者为本人,编辑记者为陈晨luminous>。
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架构中的不同的层面,承担不同的功能。
下图是 SDxCentral 网络的一个用户调查显示的使用 NFV 的驱动力:
ETSI: European Telecommunications Standards Institute 欧洲电信标准化组织
2012年11月,国际上七大电信网络运营商选择 ETSI 作为 NFV 行业规范制定组织,来制定他们所需要的 NFV 标准,并且在成员之间共享经验和做早期实现。目前,ETSI NFV 已经发展为包括主要电信企业和IT提供商的 超过 270 家企业的一个国际组织。来自国内的几个参与者:
ETSI NFV 组的主要工作就是制定 NFV 标准。他们已经发布的 NFV 标准架构为:
该架构有三个主体组成部分:
OPNFV 是一个开放社区(Open Community),它致力于使用开源的组件来实现符合 ETSI NFV 标准架构要求的运营商级别的、整合的、开放的平台。可见,OPNFV 的目的是整合一些开源方案,做 NFV 开源的产品化。它的实现的几个特点:
OPNFV 于2016年3月发布的最新的 Brahmaputra 版本的架构:
该架构的几个特点:
有 ETSI NFV 组负责制定 NFV 标准,有 OPNFV 负责提供开放实现的参考架构,那各个公司就知道自己的在其中的位置了:OpenStack 厂商忙着说自己的产品可以作为 NFVI,电信应用厂商说他们的产品可以提供NVFs,MANO 厂商说他们的产品可以作为 MANO 等等。
Mirantis 在 ETSI NFV、OPNFV 和 OpenStack 等开放组织内都是核心成员,而且它成立了专门的 NFV 部门(部门 Leader Sutapa Bansal 在加入 Mirantis 之前在 Cisco 和 Juniper 都工作过,因此具有深厚的网络行业背景)。他们在 2015 年9 月份发布的 MOS 7.0 中就增加了对 NFV 的支持,其技术架构为:
该架构的几个特点:
该实现架构的特点和他们目前的合作伙伴:
以提供 vSBC VNF 的 Metaswitch 公司为例,该公司看起来有相当强的实力:
(来源)
几个特点:
类别 | 需求 | 说明 |
总体 |
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 |
OPNFV 成员企业提出的部分 OpenStak 需求对应的 blueprint:
ETSI NFV 提出的部分 OpenStack 需求以及状态:
通信业已进入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 测试案例包括:
(3)实施阻力:多供应商方案的整合难度、ROI 不清晰、商业方案不成熟、软件的稳定性、安全性顾虑和转换成本等是主要阻力
(1)移动、电信等运营商和华为、中兴、H3C 等网络设备提供商来说,需要更多地参与 NFV 标准制定,以获得影响力和推动力。在目前的 ETSI NFV 组织中,只有中国电信、中兴和华为是成员,这应该说是远远不够的,而且这些成员到底投入多少,还是不得而知。
(2)对国内初创 OpenStack 公司来说,当前,在 NFV 离进入生产系统还有相当长的一段距离,特别是国内 NFV 生态成熟度还很低的情况下,一方面,需要务实地踏踏实实地把 OpenStack 私有云做好,把产品的 RAS 提高到能满足 NFV 要求的程度;另一方面,需要制定自己的NFV策略,关注NFV 的成熟度推进和商业落地情况,在适当的时机再切入。
参考资料:
OpenStack 企业私有云的若干需求(7):电信行业解决方案 NFV
标签:
原文地址:http://www.cnblogs.com/sammyliu/p/5346565.html