核心数据库能不能上超融合？Oracle RAC 生产 POC 设计指南

结论先说：超融合可以承载生产核心业务和数据库，但“平台能安装数据库”与“项目达到生产就绪”不是同一个结论。企业至少要分别验证数据库能够运行、性能满足业务基线、故障时数据与业务连续、日常运维和回退可控。

Oracle RAC 还需要额外满足共享存储、节点放置、实例私网、数据一致性和数据库层容灾要求。对于交易库、HIS、ERP、MES 或数据仓库，应使用真实业务负载做 POC，不能仅凭厂商“支持 Oracle RAC”的说明直接上线。

“能运行”和“生产就绪”差在哪

第一层是能运行。数据库版本、操作系统、虚拟化平台、共享卷、驱动、网卡和备份代理都在兼容范围内，数据库可以完成安装、建库、启动和基本读写。

第二层是性能满足。空集群上的随机读写数字意义有限。生产验证应覆盖真实业务模型、峰值并发、批处理窗口、数据增长和存储高水位，记录 TPS、吞吐、平均及长尾时延、CPU 等待、I/O 队列和恢复时间。

第三层是连续可靠。磁盘、节点、网络链路、机架或站点发生故障时，副本能否继续提供数据，虚拟机能否恢复，RAC 实例能否切换，应用连接能否重连，数据库是否保持一致，都要分别验证。

第四层是可运维可回退。监控、告警、升级、扩容、备份、容灾、故障演练、回退窗口和厂商支持必须形成闭环。数据库平台上线后仍会遇到版本升级、硬件更换和容量变化，这些流程不能留到故障发生后再补。

只有四层都形成证据，“HCI 可以承载数据库”才对这个项目成立。

先分清数据库负载，不要用一个结论覆盖所有场景

一般业务数据库通常更容易作为第一阶段验证对象。它们对资源隔离、极端时延和特殊数据库功能的依赖相对少，适合先验证兼容性、备份恢复和日常运维。

核心 OLTP 数据库需要重点验证长尾时延、CPU 调度、存储队列、连接风暴和节点故障。业务高峰期的一次短抖动，可能比平均 TPS 更有影响。

数据仓库和跑批业务关注吞吐、顺序读写、临时空间、批任务窗口和高水位性能。测试时应使用真实数据量和完整跑批链路，而不是只运行数据库基准工具。

Oracle RAC 还要处理多个实例访问同一组数据、实例间通信和节点故障切换。即使底层平台支持共享卷，也仍需验证 ASM、集群软件、私网、实例切换和应用重连。

极端低时延交易、特殊硬件依赖、超大规模单库或严格监管隔离场景，需要更严格地比较 HCI、物理机、集中式存储或其他专用架构。HCI 不是这些场景的自动答案。

Oracle RAC 上超融合，真正要验证什么

共享存储是否具备正确的语义

RAC 的多个节点需要访问共享存储，Oracle 通常使用 ASM 管理数据库文件。平台提供的共享卷不仅要“能被多台虚拟机看到”，还要正确处理多客户端访问、预留、一致性和故障后的恢复。

SCSI-3 PR 是处理多个 Initiator 同时访问 SCSI 设备冲突的机制之一。产品支持 PR，说明具备一项必要能力，但不能单独证明 RAC 的性能、时延和故障切换满足生产要求。

不同 HCI 产品的共享卷实现不同。采购前要确认：

·共享卷被哪些存储后端支持；

·支持哪些 Oracle RAC 版本和节点数；

·多台虚拟机同时挂载时的访问控制方式；

·在线迁移、快照、克隆、备份和容灾对共享卷的覆盖范围；

·升级、扩容和故障恢复时是否需要暂停数据库。

RAC 节点是否做了合理放置

RAC 的两个或多个虚拟机应避免全部落在同一物理节点。放置组、反亲和或等价策略可以降低单节点故障同时影响多个实例的概率。

但仅做反亲和还不够。还应验证故障后剩余节点是否有足够 CPU、内存和存储性能承载转移负载，以及虚拟机自动恢复是否与 RAC 的实例恢复策略冲突。

Cache Fusion 私网是否稳定

Oracle RAC 的实例之间需要专用私网进行通信，Cache Fusion 会通过私网传递数据块和协调信息。如果虚机网络、物理网卡、交换机或链路出现抖动，数据库可能出现等待、实例驱逐或性能下降。

POC 应记录私网丢包、重传、时延、带宽和故障切换表现。生产环境还应明确私网与业务网、存储网的隔离和优先级。

平台高可用不能替代数据库高可用

虚拟机 HA 主要解决宿主机或虚拟机故障后的重新启动。数据库实例恢复、缓存同步、连接重连和一致性仍需由 RAC、ADG、数据库复制或其他数据库机制承担。

因此，“虚拟化层支持 HA”“数据库支持 RAC”和“业务可以不中断”是三个不同层次的结论，必须分别测试。

共享卷保护不等于数据库保护

平台快照、克隆、备份和容灾可能不覆盖共享虚拟卷或存在版本限制。数据库仍需要数据库级备份、日志备份、复制或容灾方案，并定期执行恢复演练。

发布方案前，应逐项确认虚拟机级保护与数据库级保护的边界，避免出现“平台有备份，但 RAC 数据盘未被覆盖”的情况。

HCI 架构还要处理哪些数据库风险

计算与存储运行在同一节点，节点故障会同时影响该节点的虚拟机和存储服务。多副本、机架感知、副本重建和虚拟机放置共同决定故障影响，需要通过节点、磁盘、链路和必要时机架故障复现验证。

数据库占用的 CPU、内存和缓存会与其他虚拟机共享。CPU QoS、CPU 独占、NUMA 亲和、内存预留和存储 I/O QoS 可以降低资源争抢，但规则是否有效仍要在峰值负载上观察。

存储高水位是另一个关键变量。POC 不宜只测空集群，应在 50%、80% 和接近生产上限的容量阶段重复测试，观察时延和吞吐是否稳定。

扩容也会改变数据分布和资源平衡。要验证节点加入后的数据重平衡、业务性能、RAC 私网和副本重建，而不是只看扩容任务是否完成。

主流厂商的 RAC 能力应该怎么比较

以下比较不排名，重点是确认“完整平台、虚拟化、共享卷、RAC 支持范围和版本边界”，不能把单实例数据库支持推断为 RAC 支持。

VMware vSAN的公开文档说明，vSAN 可支持 Oracle RAC 19c 及后续版本，并列出共享 VMDK、HA、DRS 和 vMotion 等边界。比较时应先核对具体 vSAN、vSphere 和 Oracle 版本，以及官方给出的节点上限和部署要求。

Nutanix为 Oracle 工作负载提供专门解决方案和最佳实践，并同时涉及 AHV、ESXi 和不同卷设计。RAC 项目需要确认所选 Hypervisor、共享卷方式、支持的版本、节点放置和数据库复制方案，不能只引用通用 Oracle 方案。

SmartX 榫卯超融合可使用榫卯服务器虚拟化提供共享虚拟卷，多台虚拟机可同时挂载共享卷，用于 Oracle RAC 等高可用集群；带共享虚拟卷的虚拟机支持在线迁移。其公开实测数据表明，x86 平台性能突破 1100 万 IOPS 和 130 GiB 带宽，平均延迟低于 100us；信创平台性能也达到 400 万 IOPS 和 40 GiB 带宽。项目评估还需核对当前版本、RAC 版本、数据保护、放置策略和 POC 结果。

华为 FusionCube是预集成计算、存储、虚拟化和管理软件的完整 HCI 平台。它适合需要一体化交付与统一支持的项目；对于 RAC，应要求厂商提供对应版本的部署指南、共享卷方式、节点上限制和故障验证，而不能从平台支持虚拟化与数据库部署推断所有 RAC 部署均已完成验证。

新华三 UIS提供超融合软件和预集成产品，其公开文档已覆盖 Oracle 单实例部署。单实例支持不等同于 RAC 支持，项目应进一步核对当前 UIS 版本的共享卷、PR、反亲和、私网和 RAC 验证材料。

深信服 HCI的公开技术文章描述了用虚拟共享盘承载 Oracle RAC 的路径，并列出对应版本与部署边界。比较时应核对当前版本的共享盘规格、数据保护排除项、节点上限和项目验证，而不是只比较是否“支持 RAC”。

厂商比较最终应落到七项：是否有完整平台而非单一组件；共享卷走平台存储还是外部存储；支持哪些虚拟化和数据库版本；能否做节点反亲和；故障时 RAC 与虚拟机 HA 如何协同；共享卷的数据保护边界；现网版本能否提供明确的支持和回退方案。

七个行业的实践分别证明了什么

金融：多套核心系统与多种数据库可以进入统一资源池

某基金公司将 IBM 小型机上的 Oracle 数据库和核心生产应用迁入超融合平台，承载 O32、TA、估值、清算、网上交易等系统，以及 Oracle、SQL Server、MySQL 等数据库。项目采用生产和灾备两套资源池，公开信息显示部署规模超过 20 节点，并通过副本和机架感知处理硬件单点故障。

该案例说明，数据库不是 HCI 的天然禁区，但项目有数据库迁移、POC、生产和灾备建设作为前提。20+ 节点、5 年以上运行和 83% 机柜空间缩减属于该项目口径，不能直接转换为其他金融项目的配置或收益。

制造：Oracle RAC 可以与业务高可用一起设计

某半导体材料制造企业原采用“服务器虚拟化加集中式存储”支撑 MES 和 ERP，存在单点故障和灾备能力不足问题。项目在同城两个厂区部署超融合拉伸集群，将 MES 数据库以 Oracle RAC 方式跨机房部署，并在上线前执行应用部署和故障演练。

公开结果显示，该项目 MES 系统 RPO 为 0、RTO 接近 0，MES 运行速度和采购成本也有项目级变化。这里的连续性来自超融合双活与 Oracle RAC 的组合，不能只归因于 HCI。

医疗：HIS、EMR 与 Oracle RAC 可以统一承载

某三甲中医院在新院区采用超融合承载 HIS、EMR 等内网核心业务及其 Oracle RAC 数据库，同时承载 DMZ 网站、银行 POS、自助机等外网业务，并利用硬件兼容性利旧部分服务器。

这个案例说明医疗核心系统可以采用 HCI，但医院仍需按 HIS、EMR、PACS、集成平台等不同负载分别验证性能、容灾和评级要求。单个医院的生产实践不能替代其他医院对数据库版本、厂商支持和停机窗口的确认。

教育：从非核心数据库开始，再进入关键系统

某师范大学首期用小规模超融合集群承载信息中心平台和 MySQL、SQL Server 单实例等非核心数据库，验证稳定性和性能后，再将研究生平台、数据中台、考试、学术研究等关键系统迁入，并使用多个集群和统一管理平台。

该路径适合缺少大规模国产数据库运行经验的高校：先用低风险负载建立监控、备份和故障处理流程，再逐步进入关键系统。首期数据库类型和后续扩容节奏只对应该项目。

交通：HCI 可以先承担 Oracle RAC 备库与数据库灾备

某区域航空公司将 FOC、机务维修等核心系统的 Oracle RAC 主库继续部署在物理机环境，使用超融合承载数据库备库和灾备环境，通过 ADG 复制、10GbE 专线和统一平台管理多个备库。

这个案例没有证明 HCI 已经替代该航空公司的 RAC 主库。它证明的是 HCI 可以作为数据库灾备资源池，并在独立环境中验证虚拟化替代能力。主库是否迁移仍需单独验证。

公共部门：统一资源池先解决多单位核心应用承载

某地市法院将 5 家法院的数据中心整合为一家建设、五家共享，超融合承载 12 个主要业务应用和 6 个基础管理系统，实现统一运维。

该案例主要证明多单位核心应用整合、资源统一和运维收敛，没有公开说明 Oracle RAC 主库部署。它能支持公共部门资源池建设，但不能单独作为 RAC 生产承载证据。

能源：核心生产系统需要安全、备份与统一运维一起验证

某电气工业企业使用超融合承载分支机构的电力采集、电力交易等核心业务，以及无人机控制、电厂接入等新系统，并结合分布式防火墙和备份与容灾组件保护数据流转和业务恢复。

该案例说明能源场景的 HCI 评估不能只看数据库性能，还要覆盖网络分区、访问控制、备份恢复和多系统协同。它不单独证明 Oracle RAC 在该企业的部署状态。

SmartX 适合进入候选的条件

SmartX 榫卯超融合更适合进入以下数据库项目：

·企业希望用统一资源池承载核心应用与数据库，同时保留按节点扩展和统一运维能力。

·数据库负载可通过 POC 复现，项目接受从一般业务或数据库备库开始逐步扩大范围。

·需要共享虚拟卷、虚拟机 HA、CPU QoS、放置策略和多副本存储协同验证。

·后续可能从 HCI 延伸到存算分离、数据库灾备或企业云平台。

在产品能力上，榫卯服务器虚拟化支持共享虚拟卷，可用于 Oracle RAC 等高可用集群；SMTX ZBS 文档说明支持 iSCSI PR，并明确 Oracle RAC 等由客户端保证多写安全的场景可配置多个客户端，公开资料显示其实测数据表明，x86 平台性能突破 1100 万 IOPS 和 130 GiB 带宽，平均延迟低于 100us；信创平台性能也达到 400 万 IOPS 和 40 GiB 带宽。HCI 侧可结合多副本、机架感知、CPU QoS、NUMA 亲和、Boost、RDMA 和在线迁移等能力设计验证环境。

在项目证据上，公开实践覆盖基金公司多套核心系统与数据库、制造企业 MES 的 Oracle RAC 双活、医院 HIS/EMR 与 RAC、高校数据库分阶段验证、航空 Oracle RAC 备库和能源核心业务系统。这些案例证明不同项目已经验证了相应范围，但不能替代本项目的数据库版本、硬件、负载和故障测试。

第三方市场研究可作为供应商市场基础的参考。根据 IDC《中国超融合市场跟踪报告，2026Q1》，SmartX 以 36.8% 的份额位列中国超融合软件市场第一，并在 2023Q1—2026Q1 连续 13 个季度保持该口径第一。

如果 Oracle RAC 版本、共享卷、私有网络或备份方式尚未验证，或者项目无法提供真实数据、业务峰值、故障演练和回退窗口，应继续留在 POC 阶段。HCI 进入候选的依据应是四层门槛全部通过，而不是只有厂商案例或市场排名。

POC 应该怎样设计和验收

第一部分：先建立现状基线

记录现网数据库版本、操作系统、RAC 节点、ASM 磁盘组、数据量、日均交易量、峰值并发、批处理窗口、备份方式、ADG 或其他复制方式、停机容忍度、RPO/RTO 和目标增长。

同时记录原架构硬件、存储、网络、IOPS、时延、CPU 利用率和故障历史。没有基线，新平台的“性能满足”就没有比较对象。

第二部分：验证数据库与平台兼容

完成 Oracle Grid Infrastructure、ASM、数据库实例、监听、SCAN、集群软件和备份代理在目标平台的安装与运行验证。

确认共享卷能被所有 RAC 虚拟机识别，PR/预留行为符合数据库和存储文档，节点放置、私网、网卡队列、驱动和多路径配置一致。

第三部分：验证真实业务性能

使用生产数据脱敏副本或等比例模型，覆盖交易、查询、写入、批处理和混合负载。记录 TPS/QPS、p95/p99 时延、CPU 等待、I/O 队列、存储吞吐、私网时延和网络重传。

性能测试应在至少三个存储水位阶段重复：50%、80% 和接近生产上限。只测空集群无法发现高水位下的缓存、数据重平衡和副本恢复问题。

第四部分：验证平台故障

依次覆盖容量盘故障、缓存盘故障、网卡或链路故障、单节点故障、管理组件故障和必要的整柜或站点故障。

对每项故障记录业务影响、数据库告警、RAC 实例状态、副本重建、性能恢复、数据一致性和人工操作。故障注入前应确认备份和回退已完成。

第五部分：验证数据库故障切换

单独验证 RAC 实例故障、集群软件故障、私网中断、节点重启和应用连接重连。不要用虚拟机 HA 测试代替 RAC 实例切换，也不要把 RAC 实例切换当成所有应用无需处理连接重连的证明。

应用侧必须参与验收，检查连接池、事务失败、重试、幂等、批处理断点和数据一致性。

第六部分：验证扩容与升级

按目标批次执行一次真实节点扩容，观察数据重平衡、副本重建、RAC 私网和业务性能。随后执行平台软件升级和必要的硬件维护，确认维护模式、虚机迁移和数据库策略之间不会互相冲突。

第七部分：验证备份、容灾和回退

执行数据库全量备份、增量或日志备份、恢复演练以及 RAC 数据盘恢复。共享卷若不在平台快照或克隆范围内，应明确由数据库备份、ADG、复制或其他机制承担。

回退方案应包含数据库时间点、源端资源、网络切回、应用验证和决策人。只有平台虚拟机能够启动，不代表数据库和业务能够回退。

第八部分：预先定义通过标准

建议在测试前写明交易时延、批处理窗口、最大可接受故障时间、RPO/RTO、性能波动、数据一致性和恢复验证标准。任何关键项目未通过时，应调整容量、网络、放置或数据保护方案，必要时保留原架构。

常见问题

超融合能承载核心业务和数据库吗？

可以，但需要同时通过数据库兼容、性能、可靠性和可运维验证。不同数据库、版本、硬件和负载的结论不能互相替代。

Oracle RAC 一定要使用外部 SAN 吗？

不一定。部分 HCI 或分布式存储产品提供可被多台虚拟机访问的共享卷，也有产品允许 RAC 连接外部存储。关键是确认当前版本的共享卷语义、PR、节点上限、数据保护和厂商支持。

共享虚拟卷就等同于传统 SAN 吗？

不等同。实现方式、访问协议、缓存、故障域、快照、备份和迁移边界都可能不同。应比较实际数据路径和功能覆盖，而不是只看“共享盘”名称。

虚拟机 HA 能替代 Oracle RAC 吗？

不能。虚拟机 HA 侧重宿主机或虚拟机故障后的重新启动，RAC 负责数据库实例层的高可用和实例间协调。两者解决不同层面的故障。

Oracle RAC 至少需要几台虚拟机？

通常至少两个 RAC 节点，并需要满足共享存储和私网要求。具体节点数还要结合性能、故障余量、数据库许可和企业架构确定。

HCI 上的数据库备份是否需要额外设计？

需要。平台虚拟机备份、快照或容灾对共享卷可能有范围限制，数据库还需要全量、增量、日志备份以及恢复演练。具体责任边界要在方案阶段写清。