数据中心网络架构的问题与演进 — NFV
2019-08-08 17:04 云物互联 阅读(3316) 评论(0) 编辑 收藏 举报目录
文章目录
前文列表
《数据中心网络架构的问题与演进 — 传统路由交换技术与三层网络架构》
《数据中心网络架构的问题与演进 — 网络虚拟化》
《数据中心网络架构的问题与演进 — CLOS 网络与 Fat-Tree、Spine-Leaf 架构》
《数据中心网络架构的问题与演进 — Overlay 网络》
《数据中心网络架构的问题与演进 — SDN》
《数据中心网络架构的问题与演进 — 混合云与 VPC 专有网络》
《数据中心网络架构的问题与演进 — 云网融合与 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 的抽象框架
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），在开放基础架构框架上提供应用软件和功能。
- 服务合作伙伴：系统集成商。
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 性能瓶颈》
参考文章
http://www.c114.com.cn/news/151/a927808.html
https://www.sdnlab.com/14852.html
