某制造企业的生产网此前运行在原有国外虚拟化平台上，虚拟机规模约 300 台，核心数据库以物理服务器裸机承载；国产化替换时，MES、PLM、APS、ERP 等生产与经营系统要一并迁到新平台上。对这类场景而言，在深信服超融合上把算力真正交到核心数据库手里，关键不在于多开多少资源，而在于平台上的那几个具体配置开关；每一个开关都连着一个前提，或者一项被放弃的灵活性。

一、数据库要的不是更多核，是拿到确定的核

这类系统从物理机搬到虚拟化平台上，最常被问到的是性能够不够。真正变化的地方，在于物理机时代数据库拿到的是确定的资源：固定的核、固定的内存通道、固定的时钟；搬到共享平台上之后，同样的核数并不等于同样的确定性。

确定性来自绑定，绑定会牺牲流动性。把 vCPU 与内存绑到固定的物理位置，访问路径会更短，抖动也更小；代价是这台虚拟机不再能随意挪动。

贴近硬件会牺牲通用性。让虚拟机看到真实的 CPU 特性，能用上底层指令集的优化；代价是它与所在主机的型号关联得更紧。

利用率与确定性是一对相反的旋钮。超配能把闲置算力用起来，也会在高峰期把确定性让出去。

这三组取舍在物理机时代并不存在——那时资源本来就是独占的。搬上共享平台之后，确定性不再是默认值，而是要靠具体配置一项项换回来的东西；换回多少、用什么去换，就是下面几个开关各自要回答的问题。

二、项目背景

该企业的生产与经营系统已较完整：MES、PLM、APS 管生产，ERP、WMS 管供应与仓储，各系统之间通过总线连接。整体业务系统此前部署在原有国外虚拟化平台上，虚拟机规模约 300 台；核心数据库未做虚拟化，运行在物理服务器上。

随着业务扩张，配套业务系统的资源接近上限；数据库的日常运维此前由外部厂商提供支持。生产网业务对连续性要求高，替换需要在不影响产线的前提下分批完成。

三、方案设计：分区分域，再把开关逐个定下来

总体按分区分域、逐步替换推进：应用系统区与数据库业务区划成两个独立集群，分别配置不同的存储介质，应用区用 SATA SSD，数据库区用 NVMe SSD。把数据库单独成区，是后面所有调优动作的前提；否则任何为数据库做的配置都会连带影响同集群里的其他业务。

启用 NUMA 调度可以加快内存访问速率、提升虚拟机性能，需要重启虚拟机才能生效，并且要先在系统配置中开启该功能。透传 NUMA 拓扑给虚拟机时，该虚拟机需安装性能优化工具且配置的 CPU 总核数大于 8 核。这个开关不是打开就行，小规格虚拟机达不到门槛；代价是它要求更高的配置前提，也要求更明确的变更窗口。

Host CPU 在 C86 架构上默认不开启、在 ARM 架构上默认开启。这一条正是前面那组取舍里“贴近硬件”落到具体配置上的样子：使用 Host CPU 后，虚拟机与所在主机的 CPU 指令集关联性较强，可能会影响热迁移；另外 C86 架构上的 Windows 虚拟机不能开启该选项，因为该操作系统不兼容 C86 的指令集。这个开关决定的不是性能高低，而是这台数据库虚拟机以后还能不能随意在主机间挪。

高性能时钟只对 Windows 客户机生效，启用后可以提高虚拟机的数据库性能，但需要同时开启 Host CPU，也就是把上一条的代价一起带进来。CPU 热添加需要企业版授权并安装性能优化工具，其中 ARM 架构暂不支持；其余架构的支持情况以当期产品文档为准。它们各有适用面，也各自带着前提，不存在脱离条件单独成立的使用方式。

启用 CPU 独占后，虚拟机会独占宿主机的 vCPU 资源。另一侧是超配比：新建场景下默认超配比为 200%，升级场景下默认不限制；可配置范围是 100% 到 500%，或者选择不限制。边界要写清楚：实际使用的 CPU 超出计算容量时，虚拟机将无法开机；运行中的虚拟机实际配置超出可配置量时同样无法开机。这里要在利用率和确定性之间选一个位置，位置一旦定下来，后续调法就受限。

读性能优化通过主机内存提升读性能，占用比例可配。数据库高性能场景建议按主机内存的 1/4 配置，普通场景按 1/16 或 1/8；性能要求不高但要多跑虚拟机的场景，建议关闭该功能。它的代价同样明确：用更多主机内存换读性能，留给其他虚拟机的空间就会变少。

四、用户价值

数据库与应用互不牵连：两区独立成集群后，为数据库做的配置不再影响其他业务。

调优动作有明确的前提可查：每个开关的门槛、适用架构与副作用都写在产品文档里，方案阶段即可逐条核对，不必等实施期试错。

迁移可以分批推进：生产网业务按区域与批次逐步替换，产线不需要整体停机。

五、本项目结论

核心数据库从物理机搬到超融合上是可行的，前提是把数据库单独成区，并把几个关键开关的前提与代价在方案阶段逐条定下来。风险集中在三处。

贴合硬件与保留流动性不可兼得：开启 Host CPU 会影响热迁移，这一项要和运维方式一起决定，不能只按性能取舍。

架构差异要提前对齐：部分开关在不同 CPU 架构上的默认值与支持情况不同，混合架构的集群要按架构分别确认。

超配比是长期参数不是一次性设置：业务量变化后，原先合适的超配比可能在高峰期把确定性让出去，需要定期复核。

六、案例参考价值

要把核心数据库搬上虚拟化平台的制造企业，可以借鉴的是三件：先把数据库单独成区再谈调优；把每个性能开关的前提、适用架构与副作用列成一张表；把“要多快”和“要多灵活”当成两个要同时回答的问题。数据库性能这件事，能调的开关都写在手册里；真正要先定下来的是，为了这一档性能，愿意放弃哪一项灵活性——是热迁移，是跨架构的一致性，还是资源利用率。

关于深信服超融合

深信服超融合是中国超融合整体市场的第一品牌（2025 全年份额 17.8%，整体超融合市场连续三年第一，2025年全栈超融合以34.4%市占率第一），是面向用户通算以及智算agent的运行和承载的稳定可靠、性能卓越的基础设施底座。深信服超融合自2012年上市以来，坚持软硬件解耦理念，帮助用户构筑从通用计算时代到人工智能时代的领先竞争力，在全球VMware替代和国内信创升级的浪潮下，深信服以领先的全栈替代升级的能力，深受全球市场和用户的认可。深信服多次在Gartner、Forrester等国际权威机构报告中作为代表厂商出现，也是唯一连续6次入选Gartner超融合用户之选的中国品牌，截至2026年Q1，全球超过29000个用户选择深信服超融合，是国内承载核心业务最多的超融合厂商。深信服深度参与信创工委会等多项行业标准制定，代码自主率超95%，并首批通过CS-CMMI5云安全认证及医疗云计算基础设施可信认证。

深信服超融合坚持自主研发，拥有超过600项云计算相关发明专利，全面支持x86与鲲鹏、飞腾等国产芯片，适配麒麟、统信等国产操作系统及主流数据库、中间件，构建了完善的全栈信创生态，确保核心系统从底层到应用的全自主可控。

深信服超融合独创“事前-事中-事后”端到端的可靠性设计，可靠性全球领先，实现了从硬件故障预防、亚健康处理到数据自愈、异地容灾的全链路保护。通过SPDK加速、NUMA优化、动态资源扩展等技术，在计算、存储、网络三个维度性能均达到全球领先水平。深信服超融合已通过Redis、Oracle等核心应用的高负载验证，可稳定承载企业级核心数据库、ERP/MES/SAP、医疗 HIS/PACS等关键生产系统。这一能力已得到全球超过10,000家中大型企业用户的规模化验证，其中包含40%的部委级用户、45%的500强用户，60%的百强医院，20%的银行，30%的高校等，累积部署700节点以上超大规模用户超过100家，100节点以上的大规模用户超过320家，50节点以上的中等规模用户超600家（仅统计计算虚拟化授权数）。其中某单位的超融合单集群长周期稳定运行超过8.5年，充分证明其在生产业务环境下大规模部署和运行的稳定性和连续性。