如何在超融合架构下实现 CPU 资源管理优化?

在信创加速落地与硬件飞速升级的双重驱动下,企业虚拟化平台建设面临着严峻挑战。一方面,为保障稳定性而采用的保守资源分配策略,本就导致 CPU 利用率低下;Chiplet 架构带来的核心数激增,更在缺乏精细管理的情况下进一步加剧了资源空置与浪费。另一方面,硬件架构的演进也放大了跨节点访问的延迟,严重时会直接导致关键应用性能下降,制约系统的整体吞吐量与业务表现。

因此,如何在保障关键业务稳定运行的同时,突破资源利用率瓶颈,实现资源调度灵活管理,达到降本增效,成为了信创场景下 IT 基础设施优化的重要挑战。

在此背景下,SMTX OS(榫卯企业云平台和榫卯超融合中的超融合软件)提供了多种计算资源管理特性,**通过 CPU 资源分区管理方案,结合 NUMA 亲和性调度与 CPU QoS 配置等多种技术,优化虚拟化环境中的计算资源管理与分配,**帮助企业在资源利用率与业务性能之间寻找最佳平衡点,满足更多业务场景计算需求的同时实现降本增效。

传统计算资源管理方案存在的问题与挑战

在虚拟化环境的规模化部署中,传统 CPU 资源管理机制已经暴露出一系列深层矛盾,集中体现在稳定性与资源成本难以平衡、硬件演进加剧资源浪费、跨 NUMA 节点访问性能衰减这三大维度,成为制约企业 IT 效能的核心障碍。

低利用率与高成本矛盾加剧

在传统 CPU 资源管理模式下,为保障核心业务(如数据库、实时交易系统)的稳定性,多数企业采用"低水位运行"的保守策略,对 CPU 资源使用设定严格的资源使用上限,例如通常要求 CPU 平均利用率不超过 60%,并且业务越关键,这一阈值往往设定得越低。同时,为了应对潜在的突发负载高峰,运维团队可能还会在规划中预留一部分资源作为缓冲。

这种**"为稳定牺牲效率"**的模式虽然规避了资源争抢风险,却也导致物理服务器平均利用率长期处于低位,硬件采购与运维成本居高不下,难以适应信创场景下 IT 集约化、降本增效的诉求。

硬件演进加剧资源浪费

随着 Chiplet 技术的成熟,单颗 CPU 的核心数呈现爆发式增长;统计数据表明,近年来硬件演进使得 CPU 核心数达到五年前的 3-4 倍。

图源:This Chart is Key to Understanding the Growth of AI,STH

理论上 CPU 核心数的增加代表物理主机可承载更多虚拟机,以提升资源效能。但在实际生产环境中,由于缺少精细化管理,企业往往为了规避性能风险而压制主机 CPU 使用率阈值,导致核心数激增反而造成了闲置算力规模同步扩大,进一步放大了资源浪费,形成了**"硬件投入越高、闲置损耗越大"**的恶性循环。

NUMA 架构带来性能制约

Chiplet 技术的发展同样使得在 NUMA 架构下跨节点内存访问延迟显著增大,当缺乏有效的 NUMA 亲和性策略时,CPU 访问远端 NUMA 节点的内存单元延迟将远高于本地内存访问,随着 CPU 核数增加,这一延迟也成为了关键业务性能的主要制约因素,可能直接导致关键应用程序的响应时间延长、处理速度大幅下降。

以海光 C86 7360 24 核 CPU 测试数据为例,CPU 中各个 CPU 核心间访问延迟与 NUMA 节点间距离成正比,同 NUMA 节点中访问延迟在 40 ns 左右,而跨 NUMA 节点下访问延迟最高可达十倍以上。

海光 C86 7360 24 核 CPU 各核心访问延迟测试结果(自行测试)

HiSilicon Kunpeng 920-6426 64 核 CPU 各核心访问延迟测试结果

图源:Measuring CPU core-to-core latency,GitHub

更为严重的是,单个物理服务器上部署的虚拟机数量增加将使得 NUMA 拓扑复杂性激增,造成难以追溯的性能衰减,成为运维团队的痛点之一。同时,虚拟机规模的扩大也将带来更激烈的资源争抢,这种资源冲突会进一步加剧跨节点访问延迟问题的负面影响,形成恶性循环,最终显著制约系统整体吞吐量与关键业务性能。

在实际虚拟环境中,上述问题并非孤立存在。Chiplet 推动的核心数激增,放大了资源浪费与 NUMA 延迟的影响;而企业为规避性能风险采取的过度预留策略,又反向拖累资源利用率。这种"性能-成本"的博弈,迫使企业陷入两难:牺牲高性能与稳定性换取利用率,又或者为稳定高性能承受高昂成本。

要从这一困境中破局,就需要在资源调度机制层面实现突破:既要通过物理级隔离 保障核心业务性能,又要以细粒度弹性分配机制 提升资源利用率,同时规避 NUMA 架构的性能陷阱

SMTX OS 解决方案:CPU 资源分区管理

为平衡关键业务性能与资源利用率,SMTX OS 中将 CPU 资源划分为三个动态资源池:

  • **系统预留资源池:**运行系统服务(如计算、存储、网络等),支持动态资源调整,确保底层系统服务稳定运行,不受上层业务负载波动影响。
  • **虚拟机独占资源池:**为数据库、中间件等追求极致性能的业务隔离资源争抢,基于 NUMA 亲和性调度降低访问延迟满足高性能需求。
  • **虚拟机共享资源池:**承载其它一般性业务,通过配置 QoS 策略实现灵活管理共享资源分配,允许高优先级业务抢占资源,在利用率最大化的同时维持基础性能。

通过物理隔离弹性调度的结合,既确保核心业务"零干扰"运行,又实现闲置资源动态复用,提升整体资源,破解稳定性与成本效率的长期矛盾。

系统预留:保障系统服务稳定运行

系统预留资源池作为底层基础设施的核心资源池,专用于承载虚拟化控制面、分布式存储服务、网络及运维监控组件等关键系统服务。通过独立资源预留与物理隔离,确保即使在业务高负载场景下,系统服务仍然能够稳定响应,避免因与业务资源进行争抢导致管理平面延迟或服务中断。 同时,根据性能与网络要求的不同,系统预留资源的占用也将动态进行调整,例如集群启用 Boost 模式将额外预留 3 个 CPU 核心,启用RDMA 或双活集群将额外预留 1 个 CPU 核心,从而实现在保障基础架构可靠性的同时,降低资源浪费。

独占资源:高性能业务资源保障

在企业 IT 环境中,数据库、实时交易系统等关键业务对计算性能与稳定性要求严苛,传统虚拟化架构中资源争抢导致的性能波动和延迟问题,往往成为业务连续性的潜在威胁。

CPU 独占

为了满足高性能业务的资源保障需求,榫卯超融合提供了 CPU 独占功能,通过物理级资源隔离技术,为高优先级业务提供专属算力保障。该功能将虚拟机 vCPU 与物理核心(pCPU)进行绑定,结合 pCPU 隔离机制,确保独占资源完全专供目标业务,杜绝其他虚拟机抢占。

NUMA 亲和性调度

考虑到关键业务对极致性能的需求,SMTX OS 6.2.0 及之后版本对于启用 CPU 独占的虚拟机将自动应用 NUMA(Non-Uniform Memory Access,非一致性内存访问)亲和性调度策略。

在 NUMA 架构下,不同的内存器件和 CPU 核心从属不同的 NUMA Node,CPU 访问内存的时间取决于 CPU 与内存的相对位置,通过优先访问相对位置较近的内存可缩短延迟。

因此,对于启用 CPU 独占的虚拟机,NUMA 亲和性调度策略会将虚拟机使用的 CPU 优先分配在相同 NUMA node,并在虚拟机开机时为虚拟机分配相同 NUMA node 上的内存,减少跨 NUMA 节点访问内存的延迟,从而进一步提升虚拟机整体性能。

通过部署达梦数据库对内存访问速度进行测试,结果表明,启用 NUMA 亲和性调度后将带来 11 % 左右的性能提升。

共享资源:灵活管理提高利用率

对于承载一般性业务的虚拟机,为了提高资源使用率往往使用共享计算资源。但当主机 CPU 超分比例较高时,共享物理资源的虚拟机将面临严重的资源争抢风险,不经控制可能导致关键业务无法获取到足够资源,或因某一虚拟机过度占用导致其他业务都受到影响。为此,自 SMTX OS 6.2.0 版本,我们支持了 CPU QoS 设置,帮助企业通过配置 CPU 份额、预留与限制灵活管理共享 CPU 资源

CPU 份额

当主机上面临 CPU 资源争抢时,不同虚拟机承载的业务重要性不同,也就意味着 CPU 分配的优先级不同。**CPU 份额的设置可以使用户清晰地标识出虚拟机在面临资源争抢时的优先级,从而使系统自动将资源分配倾向于承载更重要业务的虚拟机,**满足实际的业务保障需要。

CPU 预留

在实际运行中,承载重要或长期稳定业务的虚拟机需要能分配到稳定充足的 CPU 性能,以确保不会因资源争抢导致核心业务延迟甚至中断。CPU 份额的设置虽然保障了虚拟机分配到资源的优先级,但是有限的 CPU 资源和虚拟机数量的增加,将导致原有份额对应到的实际分配量降低,仍然可能发生虚拟机分配到的 CPU 资源无法满足虚拟机运行需要的情况。

而已有的 CPU 独占功能,由于在独占资源空闲时无法复用且受限于 CPU 核心数量,会导致主机承载量低,成本高昂,因此仅适用于极少数追求极致性能的业务。此时,为了覆盖更多需稳定性保障的场景,用户可以为这类虚拟机设置 CPU 预留,**通过更细粒度单位的资源预留,可以使 CPU 资源更灵活的分配给更多的虚拟机,同时当虚拟机实际处于空闲或未使用所有预留的 CPU 资源时,这部分资源也能够重新分配给其他虚拟机使用,**提高 CPU 资源的利用率。

CPU 限制

在集群管理中,业务方往往倾向于申请超过实际使用需求的资源以确保自身业务运行或以备不时之需,但对于企业的运维管理人员而言,这意味着集群或主机可能面临着更严重的资源争抢风险。为此,**支持为虚拟机配置 CPU 资源限制,能够在不改变虚拟机配置层面满足业务方需求的情况下,使管理员灵活回收与管理 CPU 资源,**同时预防突发负载或异常故障导致虚拟机大量占用 CPU 资源、影响其他虚拟机运行的情况。

应用案例

某金融机构在虚拟化平台中需同时承载核心交易系统(高优先级)与批量报表生成业务(低优先级)。传统模式下,为确保交易系统稳定性,运维团队采用 "静态超分 + 手动观测" 的粗放管理方式:

  • **资源分配:**根据可用 vCPU 总数,按生产环境 2:1、测试环境 5:1 的超分比部署虚拟机。例如,一台 64 核启用超线程主机最多部署 256vCPU 的生产虚拟机。
  • **观测调整:**初始部署后,通过监控 CPU 利用率动态增减虚拟机数量。若交易高峰期整体利用率超过 60%,则手动迁移部分低优先级业务。

在这一模式下,会出现两方面问题:

  • **资源浪费:**为避免交易系统性能波动,实际平均利用率可能低于 50%,硬件成本高昂。
  • **性能风险:**突发负载时,低优先级业务(如报表生成)与交易系统争抢资源,导致交易延迟飙升,可能触发风控告警。

而采用 SMTX OS 后,通过对 CPU 资源进行分区分配与管理,可以对物理资源利用率实现有效提高:

  • **系统预留:**为系统预留 8 vCPU,保障系统服务运行。
  • **重要业务独占:**为核心交易系统设置 32 vCPU 独占,独占虚拟机不受其他虚拟机资源争抢影响,CPU 平均使用率可提升至 80%。
  • **其他业务共享:**剩余 88 vCPU 可提高超分比至 3:1 部署 264 vCPU 虚拟机,通过优先级与预留策略,将 CPU 使用率上限提高至 75%,并在夜间回收空余资源用于批量业务。

这一方案下,集群 CPU 平均使用率可由 50% 提升至约 75%,减少物理资源浪费。同时,同等硬件条件下可部署虚拟机 vCPU 总量可由 256 vCPU 提升至 296 vCPU。整体方案不仅帮助用户保障了核心生产业务的稳定性,还大幅提升物理资源利用率,切实落实降本增效。

小结

面对资源浪费与性能保障的冲突,SMTX OS 将 CPU 资源进行分区管理,通过 "系统-独占-共享"三级动态资源池,破解核心矛盾。系统预留资源池独立保障基础架构系统服务稳定运行;独占资源池以物理级隔离与 NUMA 亲和性调度,为关键业务提供零干扰的极致性能;共享资源池借助 QoS 策略,在高低优先级任务间弹性分配资源,实现利用率提升。三者协同,真正实现**"关键业务坚如磐石,闲置资源物尽其用"** 的运维目标。此外,用户还可以结合DRS技术,可以实现多个主机之间的计算资源均衡。

您还可下载**《超融合技术原理与特性解析合集》**系列电子书,了解更多超融合虚拟化、存储、管理、运维、网络与安全、容器管理等方面的技术解读!

《超融合技术原理与特性解析合集(一)虚拟化与存储》

《超融合技术原理与特性解析合集(二)管理与运维》

《超融合技术原理与特性解析合集(三)全栈能力》

推荐阅读:

参考文章:

  1. This Chart is Key to Understanding the Growth of AI,STH

  2. Measuring CPU core-to-core latency

https://github.com/nviennot/core-to-core-latency?tab=readme-ov-file

相关推荐
志凌海纳SmartX3 天前
SmartX 榫卯企业云平台 + 亚信安全 DeepSecurity 企业云安全防护联合解决方案
smartx·企业云·亚信安全
喝醉的小喵4 天前
iptables 规则重启机器后丢失导致k8s网络不可用
网络·后端·容器·kubernetes·虚拟化
失伟5 天前
Stratovirt安装及使用
运维·虚拟化
爱学习的小囧8 天前
VCF 9.0+Harbor 搭建私有 AI 模型仓库(PAIS)超详细教程
服务器·人工智能·虚拟化·esxi8.0
淼淼爱喝水9 天前
VMware vCenter 安装与使用超详细教程
虚拟化
爱学习的小囧9 天前
ESXi 重置密码详细攻略(全场景覆盖)
服务器·esxi·vmware·虚拟化
tianrun12349 天前
ARMv8 两级页表内存属性合并原理
虚拟化·mmu·armv8
爱学习的小囧10 天前
ESXi 7.0 多网卡网络配置详细攻略(新手易懂版)
网络·智能路由器·esxi·vmware·虚拟化
志凌海纳SmartX10 天前
详解超融合如何支持虚拟机同步复制与 CloudTower 高可用,构建全栈容灾体系
容灾·smartx·榫卯超融合
爱学习的小囧12 天前
ESXi 8.0 升级 9.0 详细攻略:安全升级、避坑与排障全指南
服务器·网络·安全·虚拟化·esxi8.0