目录
文章目录
前文列表
《数据中心网络架构演进 — 从传统的三层网络到大二层网络架构》
《数据中心网络架构演进 — 从物理网络到虚拟化网络》
《数据中心网络架构演进 — CLOS 网络模型的第三次应用》
《数据中心网络架构演进 — 从 Underlay 到 Overlay 网络》
《数据中心网络架构演进 — SDN 将控制面与数据面分离》
《数据中心网络架构演进 — 从私有云到多云到混合云》
《数据中心网络架构演进 — 从 VQN 到 SD-WAN》
前言
NFV 博大精深，本文仅作浅析，让初学者可以快速了解 NFV 是什么、做什么、为什么。但要搞懂 NFV 怎么做？岂是一篇博文能够讲得明白。技术层面，本文分别介绍了 NFVO、NFVI 的架构，以及着重介绍了 VIM 的高性能与高可用特性。其余的内容，推荐阅读《NFV 技术白皮书》和《NFVI 技术白皮书》。
NFV
Network Functions Virtualization(NFV) is a network architecture concept that uses the technologies of IT virtualization to virtualize entire classes of network node functions into building blocks that may connect, or chain together, to create communication services.
NFV（Network Function Virtualization，网络功能虚拟化）通过软、硬件解耦及功能抽象，使电信运营商的网元功能（Network Function）不再依赖于专用硬件设备，转而使用基于行业标准的 x86 服务器、存储和交换设备等通用型硬件以及相关的计算、网络虚拟化技术来承载网元功能的虚拟化软件实现。一方面基于 x86 标准的 IT 设备成本低廉，能够为运营商节省巨大的投资成本，另一方面开放的 API 接口，也能帮助运营商获得更多、更灵活、更具弹性的网络能力。NFV 可以让这些硬件资源得到充分灵活的共享，实现新业务的快速开发和部署，并基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈。
笔者认为 NFV 技术诞生和发展的主要原因是：电信网的发展是一个不断引入新技术持续创新的过程，通信网络和业务始终在不断地进行着变革。从最初的模拟通信、数据通信，到当代互联网、IT 技术。NFV 的本质就是 IT 与 CT 融合（ICT），将传统封闭的电信网络转变为灵活开放的云化结构，借助云的力量完成成本控制、业务赋能和最重要的数字化转型。
NFV 的最终目标
NFV 将传统的软硬一体的物理网元从逻辑上拆分为硬件、虚拟层和上层网元三层，并引入了 MANO 端到端管理编排系统。考虑到初期引入 NFV 的复杂性，业界通常会选择多种过渡方案，包括软硬解耦方案，指定配对集成方案等，但这些方案仅可以实现 NFV 所带来的部分优势，无法实现 “多域资源共享、上层业务灵活编排”。为推动产业发展，加速产业成熟并充分实现 NFV 的优势，设定了 NFV 远期发展目标为：NFV 硬件、虚拟层和上层应用三层完全解耦，任意配对，且满足 NFV 的相关功能和性能等要求。
- 要求硬件完全基于通用硬件，相关存储可支持存储型服务器，存储方案可支持分布式存储；
- 要求虚拟层（包括 Hypervisor 和 VIM）满足电信级功能和性能要求；
- 要求上层应用基于云化理念进行重构，充分发挥 NFV 的优势;
- 要求满足电信级可靠性；
- 为配合三层全解耦模式，MANO 系统中的协同编排器 Ocheterostor 要求与 VNFM、VIM 要实现异厂家解耦。
NFV 的理念：从运营商到行业的渗透
NFV 并不局限于网元本身，还包括一套体系，从编排器到 VNFM 到 VIM，从 VNF 到 NFVI，在行业领域也开始有了一些延伸，如数据中心方案中的 vRouter/vFW/vLB，如 uCPE（将 x86/ARM CPU 中剩余的计算资源管理起来，运行第三方 IT APP 或 CT 网元），甚至在园区出口都有可能在一定条件下用 NFV 网元实现灵活认证。除此之外，编排的概念也在跨场景中得到应用，如园数融合、DC 和 DCI 融合，提供一个统一入口、端到端视图。
ETSI NFV 参考架构
ETSI（European Telecommunications Standards Institute，欧洲电信标准化协会） 为 NFV 定义的一个标准参考抽象框架，以便所有参与者可以依照共同的框架完成相关研发工作。参考框架是可扩展的，可以从最基本的设计和功能开始一直延伸到能容纳极端网络流量的配置，参考架构包括了完整的基础架构层、虚拟基础设施管理层、资源管理与业务流程编排层、OSS 层以及网络功能层。其中网络功能层中的虚拟网元（VNF）就逻辑功能而言与物理网元（PNF）相同。
基础架构层与虚拟基础设施管理层
在基础架构层（NFVI Hardware），基于最新科技的商业通用计算、存储和网络资源，这些基础架构资源部署了 Hypervisor 层（NFVI Software）以便运行虚拟化，可以为电信运营商们的虚拟网络功能在标准服务器上提供线速的网络性能。同时，还可以结合 Linux 实时多任务操作系统、SR-IOV、DPDK、vSwitch、KVM 等技术，确保电信级网络运行的性能和可靠性。最终达到在标准商用 IT 硬件资源上运行电信级网络。
由于在基础设施层使用了大量标准商用 IT 硬件，因此对这些硬件的管理便显得极为重要。需要一个统一的、全面的基础架构平台管理工具，这个管理工具允许 IT 运维团队和网络运维团队采用更加简单、自动化的方式去管理、配置、协作 NFV 的基础设施。管理软件应当基于 REST API 等通用接口设计，易于扩展到整个数据中心的设备管理甚至云管理，以便大大降低设备运营成本，同样也降低为 NFV 网络功能提供快速运行平台服务的时间。在这个基础之上，虚拟基础设施管理层（VIM）将实现真正意义上 NFV 领域内的基础设施即服务（IaaS），它利用云操作系统实现分钟级别的基础架构资源分配和服务部署，对外提供标准的 API，实现高度自动化云部署管理和云服务管理。由于 OpenStack 优秀的面向 IT 架构能力，所以就成为了 NFV VIM 的标准解决方案。
资源管理与业务流程编排层
在 NFV 管理层还需要一个编排器，用于实现 NFV 网络功能的组织和编排，以及全局资源（跨数据中心，跨资源池）的管理和监控，这个模块的功能就是 ETSI 定义的 NFVO（NFV Orchestrator），是 NFV 网络功能运营的关键组件。由此可见，运营商在这一层上需要一个第三方的、独立于设备制造商的 Orchestrator，可以和来自不同设备制造商或者软件开发商的网元进行对接，这是开放 NFV 生态系统的关键，让运营商不再被厂商锁定。
OSS 层
对于电信 OSS/BSS（Operations Support System/Business Support System，运营支撑系统/业务支撑系统）支撑领域，包含了众多软件，这些软件产品线涵盖基础架构领域、网络功能领域，功能上支持传统的错误管理和复杂的服务管理，以满足电信行业所有的 FCAPS 需求。所以，电信运营商需要把 NFV 技术架构和现有的 OSS/BSS 系统集成在一起。
SDN 控制层
尽管 SDN 控制器没有在 ETSI 参考框架中被列出。但作为基础架构层里面很重要的一个环节，网络虚拟化必须要支持业界最新的网络技术，不管是虚拟网络还是物理网络，是传统网络技术还是 OpenFlow 技术等，都需要一个控制和管理层去支持它，SDN 控制器应当支持物理网络和虚拟网络自动的资源分配，支持 Overlay 网络，支持 L2 和 L3 数据流的控制和转发，支持 SDN 网络和非 SDN 网络的数据桥接。
NFV 的生态合作
显而易见的是，在整个 NFV 的生态系统中，运营商希望能够根据自己的业务需求和实际情况，灵活选择 NFV 框架中每一个组件的合作伙伴。然而，无论是在基础架构层、还是虚拟网络功能应用、或者管理和功能编排层，不同的合作伙伴在实现 NFV 框架内的每个模块的方法都不尽相同。电信运营商都希望 NFV 平台是一个可以自由选择合作伙伴的平台，在这个平台上运营商可以根据自己的业务需求来选择应用软件，最终的 NFV 架构可能集成了多方的技术和产品。显然，运营商需要的是一个开放环境的 NFV 生态系统。
在整个 NFV 生态系统中，运营商需要面对三种合作伙伴：
- 技术合作伙伴：技术公司和供应商，包括网络设备供应商（NEP），原厂设备供应商（OEM）和电信运营商，在技术创新、集成和基础架构框架等方面展开合作。
- 应用合作伙伴：应用开发商（ISV），在开放基础架构框架上提供应用软件和功能。
- 服务合作伙伴：系统集成商。
ETSI NFV MANO 架构
NFV MANO（NFV Management and Orchestration，NFV 的管理与编排架构）：为上图天蓝色部分，作为 NFV 的资源管理与业务流程编排层，其中主要的三个功能模块为 NFVO，VNFM 和 VIM。
-
NFVO（NFV Orchestrator，NFV 编排器）：在 NFV 中，可能存在多个 NFVI 对应着不同域的 VIM 资源，也可能存在多个 VNFM 分别管理它们的 VNF 资源。所以，在它们之上还需要一个能协调管理这些资源与服务的编排层，这就是 NFVO。
- 对于 VNFM 的资源：NFVO 需要与多个 VNFM 的接口交互，分别创建这些 VNF，还需要创建完 VNF 后，还要管理 VNF 的拓扑，对这些 VNF 进行编排，也就是实现 VNFFG（VNF Forwarding Graph，VNF 转发），也就是 SFC（Service Function Chain，服务功能链）。
- 对于 NFVI 的资源：NFVO 需要与多个 VIM 的接口交互，协调，认证，分配，释放这些资源。
-
VNFM（VNF Manager，VNF 管理器）：VNFM 主要管理 VNF 的生命周期，负责包括：调用 VIM，根据 VNFD（VNF Descriptor）创建/终结 VNF，监控 VNF，VNF 的 self-healing，扩容/缩容等工作。可以存在多个 VNFM。
- VNFD（VNF Descriptor，VNF 描述器）：VNFD 就是一个 VNF 的部署模板，包含了一个 VNF 所需要的全部信息。VNF Catalog，就是 VNFDs 的目录清单。
- VNF（VIrtual Network Function，虚拟化的网络功能）：网络功能不再运行在专用硬件设备上，而是通过虚拟化运行在虚拟机中，这就是 VNF。运营商网络的关键组成部分就是这些虚拟化的网络功能，在保留电信级能力和网络功能特性的状态下实现网络功能虚拟化。
-
VIM（Virtualized Infrastructure Manager，虚拟基础设施管理器）：VIM 是虚拟基础设置资源管理平台，通常是一个云平台，属于 NFVI 的一部分。可以存在多个 VIM。在电信领域中，VIM 通常就是 OpenStack。
上图左边的部分从下往上看，最下面是 NFVI，往上是 VNF 实例，再往上连接着网络运营商传统的 EMS（Element Management System，网元管理系统）和 OSS/BSS，可以看到 MANO 架构中的 VNFM 和 NFVO 也分别与这两个系统有交互接口，满足 NFV 与 OSS 层的集成需求。
NFVI 与 NFVI-POP 架构
NFVI（NFV Infrastructure，NFV 基础设施）：作为 NFV 基础架构层与虚拟基础设施管理层的抽象。包括硬件资源、 虚拟化层及其上的虚拟资源。其中硬件资源包含计算、存储、网络等硬件设备及管理系统（PIM），虚拟资源则包含计算、存储、网络虚拟化资源及其管理系统（VIM）。
- VIM（Virtualized Infrastructure Manager，虚拟基础设施管理器）：VIM 是虚拟基础设置资源管理平台，通常是一个云平台，属于 NFVI 的一部分。可以存在多个 VIM。在电信领域中，VIM 通常就是 OpenStack。
- PIM（Physical Infrastructure Manager，物理基础设施管理器）：服务器、存储服务器、网络交换设备等硬件设备的集中式运维管理平台。
实践经验中发现，在 NFV 网络架构方面，应构建出层次化的 NFVI，继而承载多种类型的虚拟化网元。结合 ETSI 的 NFVI 定义和业界共识提出了 NFVI-POP 的概念。**NFVI-POP（Network Function Virtualization Infrastructure Point of Presence，NFVI 局站）**是指部署了计算、存储、网络资源，符合运营商 NFV 硬件和虚化技术要求，由 NFVI 管理系统管理，提供 VNF 业务承载能力的局站。NFVI-POP 是运营商构建 NFVI 的基本单元，可部署在网络 DC 或通信机房内，如下图所示：
NFVI-POP 主要包含四大节点：计算节点、存储节点、管理节点和网络节点：
-
计算节点：由 x86 服务器构成，包含硬件资源、操作系统、虚拟化层（含 vSwitch）、虚拟机，用于承载各类电信业务 VNF。
-
存储节点：主要包含集中式存储（专用磁盘阵列）、分布式存储（使用计算节点硬盘）两种形态，为 VNF 镜像、NFVI 系统管理信息、OAM 数据提供可靠的存储。
-
管理节点：包含 VIM、PIM、SDN 控制器。VIM 对网元所需的虚拟资源进行管理；PIM 用于管理物理硬件的资源和状态；NFVI-POP SDN 控制器对内部网络进行配置和流量调度，并且对 NFVI-POP 间的 OAM 管理网络、灾备数据存储同步网络 等进行协同管理。管理节点需要同 VNFM、NFVO、新一代运营支撑系统等进行对接和协同，才能实现完整的管理闭环。
-
网络节点：主要为各类节点提供物理组网方式，并作为与外部网络连接的网关， 为各节点的数据、管理、监控等流量，提供接入、汇聚和路由能力。
VIM 技术参数
NFV VIM（虚拟基础设施管理层）要实现的就是为 NFV 提供基础设施即服务（IaaS）。所以，当我们在讨论 VIM 的时候，就是在讨论 OpenStack。但是很显然的，社区版本的 OpenStack 在支持力度、性能优化、稳定性等方面都与电信运营商 NFV 的要求存在着距离。首先不妨来比较一下企业级云平台和电信级云平台的差别：
| 企业级云平台（IT） | 电信级云平台（CT） | |
|---|---|---|
| 硬件要求 | 1-10Gb NIC | 10-100Gb NIC，>= 6 端口，链路聚合，SR-IOV，VT-d，FPGA/ASIC 加速 |
| 虚拟化 | 多虚拟化异构（ESXi、Xen、KVM、Hyper-V） | KVM |
| 云平台 | 多云、混合云 | OpenStack |
| 性能要求 | 相对不高 | 低延时，高转发，QoS，DPDK，PCI-E Passthrough，SR-IOV，虚拟化性能开销 < 5% |
| 可靠性 | 99.99% | 99.999% |
| 故障检测 | 分钟级 | 秒级 |
| 管理范围 | 虚拟资源 | 虚拟资源与物理资源（多厂商） |
| 分层解耦 | 无特殊要求 | 要求高，跨厂家管理，层间接口标准化 |
高性能要求
出于商务敏感的原因不便在此分享 VIM 定制化功能的经验和实践，但是分享一些笔者层级研究过的公开内容还是可以的。
《OpenStack Nova 高性能虚拟机之 NUMA 架构亲和》
《OpenStack Nova 高性能虚拟机之 CPU 绑定》
《OpenStack Nova 高性能虚拟机之大页内存》
《启用 SR-IOV 解决 Neutron 网络 I/O 性能瓶颈》
NFV 网元（CT）和 VM（IT）的差异
这里的 VM 是指基于虚拟化平台运行的IT网元，比如你在数据中心云平台之上申请虚机，在其中运行你自己的应用软件。NFV 网元 和 VM 两者有相同点，也有不同点。两者最大的共同点都是基于虚拟化环境，受云平台管理，有生命周期管理。至于不同点：
- 一个是性能需求，一般的 VM 网元数据需求比较低，普通网卡就可以搞定。NFV 网元包括控制类和转发类，控制类的性能要求比较低。而转发类的网元性能要求比较高，一般在 5G 的网元转发面会选择 SR-IOV，这就不属于 x86 的性能了。
- 第二个差异是网元形态，分为主机型和路由型，VM 属于主机型，它基本上就是对外提供服务，一个 IP 就够了；NFV 网元是路由型，它不仅要管自己对外的路由，同时还要管下面网元的发布，因为他本身就是一个 CT 网元的替代，这样就可以实现把流量牵引过来。
- 第三个就是 NFV 网元是支持 CT 网元特有的 VLAN 和 QINQ的子接口，而 IT 网元不带 VLAN。
- 最后一个是架构，比如在数据中心用 IT 网元，最顶层就是云平台，云平台是一个总入口。NFV 网元总入口不再是云平台，而是总的编排器 NFVO，它会调 VNMF，然后再调下面的数据，这个地方两者有不少差异。
NFV 从 IT 中的借鉴
NFV 资源池化提供统一服务
NFV 网元本身不能跨服务器，虚拟化层就不可能提供这种技术，甚至 NFV 网元还不能跨 NUMA，跨 NUMA 的内存访问会损耗 30% 左右的性能。也就是说，单个 NFV 网元的性能是非常有限的，那怎么解决这个问题呢？这个时候就要借鉴IT资源池的概念，将若干 NFV 网元集中管理，形成 NFV 资源池，对外提供统一的服务。另外，运营商在网络重构时会建立多级 DC，在部署时按照 NFV 流量特征和业务特征选择合适的 DC 承载，比如低延时，大流量的部署位置相对低点的 DC，不太在乎延时的、小流量的部署在位置更高一点的 DC。
将数据库引入 NFV 资源池
NFV 池化以后，作为 CT 网元的一种，必然要考虑可靠性，要考虑当一个 NFV 网元故障时如何如何保证业务不中断，保证用户体验不到资源池内的故障。这是非常必要的。IT 的可靠性和 CT 不是一个水平的，服务器故障比较常见，一般容易接受，而作为网络的重要组成部分，CT 可靠性要求非常高，看下运营商集采就有体会，稳定性测试是非常严格的。原先的 CT 实体设备是一个独立的、分散的网元，物理位置并不是集中的。而 NFV 池化物理上会部署在同一 DC 内 NFV 池是集中管控的，这时可以将 IT 资源池中的数据库技术引入进来。
有了数据库，多个功能相同的 NFV 网元可以将数据保存在数据库中，当某一个 NFV 网元故障时，就能够从数据库中恢复出它的运行数据，保证会话不中断，用户不感知。那为什么不用虚机的热迁移技术呢？原因有两个，一是强依赖于共享存储，成本高，另一个是 NFV 在使用 SR-IOV 时无法迁移（举例来说，PF 直通模式，NFV 网元迁移后，虚拟化层没有机制调用 NFV 网元中的PF驱动，迁移前后网卡的配置信息是不同的，如果不能重新初始化那网卡无法正常运行）。
除了故障热切换，当不同 NFV 间流量不均衡时，也可以依靠数据库技术在 NFV 间进行流量调配，比如我们发现某个网元 CPU 使用率或者用户数已经达到阈值了，而另一个 NFV 网元比较空闲，这时可以依靠数据库技术把部分用户数据在 NFV 之间迁移，并且这种调配也是用户无感知的。也就是说，数据库技术在 NFV 池化中是非常有用的。
在 5GC 架构中有一个非常关键的技术：计算与存储分离。如上所述，在 IT 领域开始习以为常的事情，实际上在 CT 中并不常见。
NFV 资源池弹性扩缩容
不管是虚机还是容器，弹性扩缩容是一个非常典型的特性，这是虚拟化一个非常明显的优势。流量潮汐是因为设备所处的地理环境是不同而带来的，有的地区是办公楼集中的，白天流量大，夜晚流量减少，有的是生活区，反过来，白天流量小，晚上开始流量增大。用NFV资源池来按需应对就非常有效。先定好弹性策略，流量下降到一定程度就先将剩余用户集中到少量NFV网元上（当然这个过程也是借助数据库的），再缩减 NFV 网元数目。
参考文章
http://www.c114.com.cn/news/151/a927808.html
https://www.sdnlab.com/14852.html
相关阅读：