3.1 NFVI资源与虚拟化层
3.1 NFVI 资源与虚拟化层
本节摘要：NFVI 是 NFV 的地基，它把通用服务器的计算、存储、网络资源虚拟化成统一资源池，VNF 跑在这个池子上。本节讲清三大资源域各自的特点、虚拟化层怎么做资源抽象屏蔽硬件异构性、以及虚拟机 vs 容器两种载体的选型取舍。
学习目标
阅读完本节，你应当能够：
- 说清 NFVI 的三大资源域和各自的关键技术
- 解释虚拟化层（VL）的资源抽象机制
- 对比虚拟机和容器两种载体的优劣
- 说明 OpenStack 和 Kubernetes 在 NFVI 里的角色
- 判断什么场景用虚拟机、什么场景用容器
一、问题与直觉
NFV 要让网络功能跑在通用服务器上，但通用服务器长什么样？一台 x86 服务器有 CPU、内存、硬盘、网卡，这些是散的资源。如果要在这台服务器上同时跑一个 vFirewall、一个 vRouter、一个 vLB，怎么分配 CPU 给它们？怎么让它们各自有独立的内存空间？怎么让它们的网络流量互不干扰？
这就是 NFVI 要解决的问题。它通过虚拟化层（hypervisor 或容器运行时），把一台或多台物理服务器的资源，抽象成可以灵活分配的虚拟资源池。VNF 从这个池子里按需申请资源，用完归还。多个 VNF 共享同一批物理硬件，但彼此隔离互不干扰。
理解 NFVI 的关键在于明白：它不只是"装个虚拟机那么简单"。电信级 NFVI 对可靠性（99.999% 可用）、性能（低延迟高吞吐）、隔离性（VNF 互不影响）的要求，远超普通企业云。这也是为什么 NFVI 的搭建和运维是个专门的工程领域。
二、核心原理
2.1 三大资源域
NFVI 把资源分成三个域：
计算域：服务器的 CPU 和内存。虚拟化层把物理 CPU 切成虚拟 CPU（vCPU），把物理内存切成虚拟内存块，分配给各个 VNF。关键技术包括 CPU 虚拟化（基于硬件辅助的 Intel VT-x / AMD-V）、内存虚拟化（影子页表、EPT）。计算域要关注的是 CPU 亲和性（把 VNF 的 vCPU 绑定到特定物理核，减少缓存抖动）和 NUMA 感知（跨 NUMA 节点访问内存会慢）。
存储域：包括本地磁盘和分布式存储。VNF 的镜像、配置数据、运行时状态都需要存储。关键技术包括块存储（给 VNF 当虚拟硬盘，如 Ceph RBD）、对象存储（存 VNF 镜像，如 Ceph RGW）、文件存储（共享配置，如 NFS）。电信场景对存储的 IOPS 和延迟敏感（比如 vEPC 的用户数据库要快速读写），往往用 SSD 或 NVMe。
网络域：这是 NFVI 最复杂的部分。VNF 之间要通信、VNF 要和外部网络通信，所有流量都要经过虚拟网络。关键技术包括虚拟交换机（OVS，Open vSwitch，在服务器内部转发 VNF 间的流量）、虚拟网络接口（给 VNF 分配虚拟网卡）、Overlay 网络（VXLAN、GRE，在物理网络之上构建虚拟网络）。网络域的性能直接决定 VNF 的吞吐量，是性能优化的重点。
| 资源域 | 关键资源 | 关键技术 | NFV 特有考量 |
|---|---|---|---|
| 计算 | CPU、内存 | VT-x、EPT、CPU亲和性 | 绑核减少抖动 |
| 存储 | 磁盘、SSD | 块/对象/文件存储 | 高 IOPS、低延迟 |
| 网络 | 网卡、带宽 | OVS、VXLAN、虚拟网卡 | 高吞吐、低延迟 |
2.2 虚拟化层的资源抽象
虚拟化层（Virtualization Layer，VL）是 NFVI 的核心。它向上提供统一的虚拟资源接口，向下适配各种物理硬件。这种"中间层"的设计带来了硬件无关性——VNF 不用关心跑在什么硬件上。
资源抽象的工作方式：
虚拟化层拦截 VNF 对资源的请求，转换成对物理硬件的实际操作。比如 VNF 要"写一个数据块到虚拟磁盘"，虚拟化层把这个请求转换成"写到物理 SSD 的某个位置"。VNF 看到的是一块连续的虚拟磁盘，实际数据可能分散在多个物理磁盘上。
这种抽象的代价是性能开销（虚拟化层转发请求需要时间，叫"虚拟化税"），收益是灵活性（VNF 可以自由迁移、按需分配资源）。下一节会专门讲怎么降低这个性能开销。
2.3 虚拟机 vs 容器：两种载体
VNF 跑在什么载体上？有两种主流选择：虚拟机（VM）和容器（Container）。它们的差异直接影响 NFVI 的设计和 VNF 的性能。
| 维度 | 虚拟机（VM） | 容器（Container） |
|---|---|---|
| 隔离机制 | hypervisor 硬件级隔离 | namespace 内核级隔离 |
| 资源占用 | 大（每个 VM 含完整 guest OS） | 小（共享宿主机内核） |
| 启动速度 | 分钟级 | 秒级 |
| 性能开销 | 较大（经 hypervisor） | 较小（直接用宿主机内核） |
| 安全隔离 | 强（硬件级） | 相对弱（共享内核） |
| 运维方式 | 传统虚拟化管理 | Kubernetes 编排 |
虚拟机的优势是隔离性强——每个 VM 有自己的内核，一个 VM 被攻破不影响其他。劣势是资源占用大、启动慢。早期 NFV（第一代 VNF）几乎都用虚拟机，因为隔离性好、与传统网络设备的管理模式接近。
容器的优势是轻量——共享宿主机内核，资源占用小、启动快、密度高。劣势是隔离性相对弱（共享内核意味着容器逃逸漏洞会影响宿主机和其他容器）。新一代 NFV（CNF）用容器，更贴合云原生理念。
💡 关键直觉：虚拟机和容器不是非此即彼。实际部署里，对隔离性要求高的 VNF（如多租户共享平台的 vFirewall）用虚拟机更稳；对启动速度和密度要求高的 VNF（如边缘场景的轻量功能）用容器更优。很多 NFVI 平台同时支持两者——OpenStack 管 VM，Kubernetes 管容器，NFVO 统一编排。
2.4 OpenStack 与 Kubernetes
NFVI 的管理（VIM 角色）最常用的两个开源平台：
OpenStack 是传统的 VIM，主要管虚拟机。它提供计算（Nova）、网络（Neutron）、存储（Cinder）等服务的统一管理，是第一代 NFV 的基础设施标准。OpenStack 成熟稳定，但偏重虚拟机，对容器的原生支持弱。
Kubernetes（K8s） 是容器编排的事实标准，正在成为云原生 NFV 的新 VIM。它管的是容器（Pod），提供调度、扩缩容、滚动更新、服务发现等能力。随着 CNF 成为主流，K8s 在 NFVI 里的地位越来越重要。
两者的关系是互补而非替代：
ETSI Release 4 已经把容器基础设施管理纳入架构，定义了 CISM（Container Infrastructure Service Management）等新组件，让 NFVO 能同时编排 OpenStack 上的 VM 和 K8s 上的容器。
三、工程实践要点
3.1 NFVI 的可靠性设计
电信级 NFVI 要求 99.999% 可用（即每年停机不超过 5 分钟）。这对基础设施设计提出高要求：
- 硬件冗余：服务器双电源、网卡绑定、存储多路径，单点故障不停服。
- 高可用集群：VNF 实例跑在集群里，某台物理机挂了，VNF 自动迁移到其他节点。
- 故障域隔离：把资源池分成多个故障域（如每个机房一个域），一个域出问题不影响其他。
3.2 资源调度的考量
VIM 调度 VNF 时要考虑：
- CPU 亲和性：把对性能敏感的 VNF 绑定到专属物理核，避免与其他 VNF 抢 CPU。
- NUMA 感知：把 VNF 的 vCPU 和内存分配在同一个 NUMA 节点，避免跨节点访问的延迟。
- 网络拓扑感知：频繁通信的 VNF 部署在同一台物理机或同一机架，减少网络跳数。
这些调度策略对 VNF 的实际性能影响很大。同样的 VNF，调度得好性能可能差出 30%-50%。
3.3 虚拟机和容器的混合策略
实际部署中，混合使用两种载体的策略：
| VNF 类型 | 推荐载体 | 原因 |
|---|---|---|
| 多租户隔离的安全功能 | 虚拟机 | 隔离性要求高 |
| 核心网功能（vEPC） | 虚拟机 | 稳定性、传统兼容 |
| 边缘轻量功能 | 容器 | 密度高、启动快 |
| 新部署的云原生服务 | 容器 | 贴合 DevOps |
⚠️ 常见坑：有些团队为了"云原生"盲目把所有 VNF 都改造成容器，结果发现某些功能（特别是需要内核级隔离或特殊硬件访问的）在容器里跑不稳定。载体选择要按 VNF 特性来，不要为了追潮流一刀切。
NFVI 要点速览
- NFVI 三大资源域：计算（CPU/内存）、存储（块/对象/文件）、网络（虚拟交换机/虚拟网卡），网络域最复杂也最影响性能。
- 虚拟化层是 NFVI 核心：把物理硬件抽象成统一虚拟资源池，提供硬件无关性，代价是"虚拟化税"性能开销。
- 虚拟机隔离强但重，容器轻但隔离弱：按 VNF 的隔离性和性能需求选载体。
- OpenStack 管 VM，Kubernetes 管容器：两者互补，NFVO 统一编排，ETSI Release 4 已纳入混合管理。
- 电信级 NFVI 要求 99.999% 可用：靠硬件冗余、高可用集群、故障域隔离实现。
- 资源调度影响性能 30%-50%：CPU 亲和性、NUMA 感知、网络拓扑感知是关键调度策略。
- 载体选择按 VNF 特性：不要为了追云原生潮流把所有功能强行容器化。
下一节专门讲性能——虚拟化带来的吞吐量损失怎么用 DPDK、SR-IOV、SmartNIC 来弥补。
四、NFVI 的三个现实约束
讲完理想分层的资源池，必须补上三个让架构师失眠的现实约束。约束一，大二层网络的规模天花板：VNF 迁移要求二层可达，但二层网络的广播域规模有物理上限，超大规模数据中心实际靠 Underlay 路由加 Overlay 隧道撑起"伪大二层"——设计时要在迁移自由度和网络复杂度之间选边。约束二，NUMA 与网卡亲和性：高性能 VNF 的虚拟机必须与直通网卡同 NUMA 节点，跨节点的内存访问能让转发性能腰斩；这把"随便调度"的自由度砍掉一大块，调度器必须懂拓扑。约束三，资源碎片化：虚拟化层的内存页巨页分配、CPU 绑核策略会在长期运行中产生碎片，导致"总量够用却分配不出来"的假性资源枯竭，运维需要定期整理或重启迁移。三个约束共同说明一件事：NFVI 不是"装个虚拟化软件"那么简单，它是把数据中心当一台超级计算机来调优的工程——第 2 节的性能优化会接着展开这些话题。
五、资源画像：给 VNF 画"体检表"
资源池化之后，调度质量的瓶颈从"有没有资源"变成"了不了解负载"。每个 VNF 上线前应该提供一份资源画像，包含四类信息：稳态需求（常规负载下的 CPU、内存、网卡带宽的均值与九十五分位）、峰值需求（洪峰时的资源上限与可持续时间）、敏感性矩阵（哪类资源紧张最先影响指标——转发类 VNF 对网卡队列敏感、信令类对 CPU 抖动敏感）、噪声容忍度（同宿主机邻居负载的干扰承受边界，决定能否与其他 VNF 混部）。画像的价值贯穿全生命周期：容量规划拿它算供给、调度器拿它做放置决策、弹性伸缩拿它定阈值。没有画像的 VNF 只能靠超额供给兜底，资源利用率长期在两三成徘徊——这是很多 NFV 项目"虚拟化了但没省钱"的直接原因。画像从哪来：厂商声明值打底，上线后用监控数据持续修正，一个季度后画像的预测精度就是运维团队的核心资产之一。
再补一段混部策略的实战权衡。同宿主机上混跑多个 VNF 能把利用率从三成拉到六成，但代价是干扰风险——时延敏感的用户面与 CPU 密集的深度包检测共置，前者的抖动会立刻恶化。成熟的做法是给宿主机打"负载性格标签"：时延敏感型独占或仅与同类混部、吞吐型可自由混部、批处理型填缝利用碎片资源；调度器按标签放置，比按瞬时负载调度的稳定性高一个量级。混部不是要不要的问题，是怎么分级的问题。