本文详细介绍了红帽为支持在红帽 OpenShift 虚拟化上运行单实例 Oracle 数据库 19c 所做的工程方面的努力。它提供了全面的参考架构，涵盖功能、性能、可扩展性和实时迁移的验证结果，以及指向 GitHub 上托管的测试工件的链接。
我们将展示 OpenShift 虚拟化能够为要求严苛的生产工作负载（如 Oracle 数据库）提供可靠的性能，在不牺牲性能的情况下提供可行的虚拟化替代方案。这尤其适用于参与评估和采用在 OpenShift 虚拟化上部署单实例 Oracle 数据库方案的技术领导者、架构师、工程团队和项目经理。
架构设计原则侧重于计算、网络和存储的资源分配、分区和抽象层优化。使用 HammerDB 和 TPC-C 基准完成的性能测试证明，Oracle 数据库可以在采用本地 NVMe 存储的 OpenShift 虚拟化上成功运行，性能表现优于红帽 OpenShift 数据基础。本文还将重点介绍可观测性和监控，使用 Prometheus 和 Grafana 来获取基础架构和特定于 Oracle 的见解。
背景
许多客户正在寻找不以牺牲性能为代价的虚拟化替代方案。OpenShift 虚拟化可为要求严苛的生产工作负载（包括企业数据库）提供可靠的性能。
在传统软件架构中，Oracle 数据库是最常见的组件之一。为了支持有兴趣评估和采用在 OpenShift 虚拟化上部署 Oracle 数据库方案的客户，红帽准备了专门的工程资源，旨在提供在 OpenShift 虚拟化上运维 Oracle 数据库的优化体验。
本文假定读者已了解红帽 OpenShift 容器平台。我们不打算讨论 Oracle 数据库的通用架构，也不打算讨论性能调优，而是重点阐述用于设置和配置 OpenShift 虚拟化的架构选项，从而使 Oracle 数据库达到最佳性能。
本文面向以下参与评估、验证和决定采用在 OpenShift 虚拟化上部署 Oracle 单实例数据库方案的专业人士：
- 技术领导者（如 VP、CTO）：负责针对在混合云或本地云场景中运行 Oracle 数据库工作负载的日常运维，优化 ROI（投资回报率）和 TCO（总拥有成本）的利益相关者。
- 架构师：客户架构师可以查看参考架构和测试结果，以评估 OpenShift 虚拟化是否是其企业组织中托管 Oracle 数据库工作负载的可行平台。本文提供了架构要求，并使架构师能够运行独立的验证。
- 工程团队：工程团队可以利用红帽在此评估期间使用的性能测试，以及 GitHub 上提供的可重用工件，加速测试设置和自动化进程，从而简化验证流程。
- 项目经理：项目经理可以使用参考架构来确定受影响的组件和负责任的团队。他们还可以使用标准化测试。
OpenShift 虚拟化架构概述
OpenShift 虚拟化是红帽对开源 KubeVirt 项目的实施。它基于标准的 OpenShift 平台构建。虚拟机（VM）在容器化 pod 内运行，OpenShift 容器平台像管理任何 pod 一样管理虚拟机，其中虚拟机实例能够访问与常规容器应用相同的平台服务，包括安全、网络和存储。唯一的区别在于虚拟机直接在 pod 级别进行管理，这与在容器内运行的常规工作负载应用不同。
架构组件：
- 基于内核的虚拟机（KVM）：作为 OpenShift 上的虚拟机监控程序，是 Linux 内核的组成部分。
- 虚拟机实例（VMI）：每个由 VMI 表示的虚拟机均由 QEMU 利用 KVM 创建，以模拟硬件，QEMU 会创建用户空间级隔离。
- KubeVirt：Kubernetes 附加组件，用于将虚拟机作为 Kubernetes 资源进行管理，使虚拟机看起来像一个 pod。
virt-operator：负责管理 KubeVirt 组件的安装和更新。virt-controller：处理虚拟机生命周期管理（比如，失败时重启、扩展）。virt-handler：运行于已启用 KubeVirt 的节点上的守护进程，负责通过 KVM/QEMU 管理主机上的虚拟机。virt-launcher：每个 VM Pod 对应一个此组件，充当编排器，负责管理 pod 内的 QEMU/KVM 虚拟机进程。- 自定义资源（CR）：用于定义虚拟机、运行虚拟机实例以及进行调度/管理策略。
- pod 封装器：充当 QEMU 进程的封装器。VMI 在 pod 内作为虚拟客户机操作系统运行。
- 存储：OpenShift 虚拟化支持各种存储解决方案，包括各种 Kubernetes 原生选项（如 OpenShift 数据基础、Portworx），以及更传统的企业级解决方案（如 iSCSI、光纤通道（FC）SAN 存储等）。Kubernetes 原生存储解决方案 OpenShift 数据基础基于开源 Ceph 项目构建，提供可扩展的冗余存储，并具有针对 Kubernetes 环境优化的抽象层。OpenShift 数据基础还支持动态置备持久卷（PV）和持久卷声明（PVC），从而简化存储管理。
对于此 Oracle 数据库验证项目，我们将考虑多种存储替代方案。但是，由于 OpenShift 数据基础与 Kubernetes 无缝集成，因此它将成为本文档范围内的主要关注点。在部署 Oracle 数据库工作负载时，务必评估并选择最能满足您的性能要求和运维需求的存储解决方案。
网络：虚拟机通过 Multus（CNI 元插件）或单根 I/O 虚拟化（SR-IOV）访问网络，其中 Multus 在 pod 级别定义。
Oracle 数据库设计原则
当 Oracle 数据库在虚拟化操作系统上运行时，虚拟机负责确保数据库获得足够的系统资源，以便高效运维并保持弹性。由于现实世界中的基础架构资源是有限的，因此必须谨慎设计基础架构，以平衡资源分配并适应各种工作负载的不同需求。
在基础架构级别提升 Oracle 数据库性能的常见架构方法需遵循以下原则：
- 资源分配：分配充足的计算、存储和网络资源，以消除障碍。
- 资源分区：在资源有限的情况下，对资源需求进行分区并实施量身定制的解决方案，以满足特定需求。
- 抽象层优化：避免不必要或低价值的抽象层，以灵活性换取性能提升。
Oracle 数据库在很大程度上依赖于以下三类主要的系统资源：
- 计算：包括 vCPU、IO 线程、内存以及跨节点扩展的能力。
- 网络：Oracle 数据库对 I/O 性能高度敏感。客户端访问与存储访问具有不同的吞吐量和延迟要求。因此，Oracle 数据库架构针对不同类型的流程采用独立的网络。
- 存储：重做日志、数据库表和备份具有不同的读/写性能需求。您应尽可能将它们放置到单独的物理存储上，以确保最佳的 I/O 性能。
OpenShift 虚拟化提供了所需的功能和灵活性，可支持基于系统资源分区需求的各种资源分配方法。
参考架构
本部分将讨论 OpenShift 虚拟化上的 Oracle 数据库设计中，架构方面的注意事项和解决方案选项。
计算
确保 Oracle 数据库具有充足的计算资源，使 OpenShift 虚拟化平台能够提供以下方面的直接控制力：
- 配置 vCPU 和内存分配，以实现资源纵向扩展。
- 确保 OpenShift 虚拟化集群的可扩展性，可实现横向扩展。
- 控制虚拟机 IO 线程数分配，以消除 pod 级 I/O 障碍。
- 避免为托管 Oracle 数据库工作负载的虚拟机过度分配资源，即分配的虚拟化 CPU 或内存总量超过系统上的物理资源总量。
网络
Oracle 数据库流量在网络延迟、吞吐量和可靠性方面具有不同的性能要求。OpenShift 容器平台 pod Multus 是一种能够实现网络流量分区并协调多种网络协议的功能。请考虑以下事项：
- 为 OpenShift SDN、存储和虚拟机实施不同的网络路径。
- 对于 Oracle RAC 数据库安装，进一步隔离 RAC 实例间互连通信和“公共”网络通信的网络流量。
- 对于对延迟和吞吐量敏感的任务关键型工作负载，考虑利用 SR-IOV 作为虚拟网络接口，创建从虚拟机到底层物理资源的直接路径。
存储
如前文所述，OpenShift 虚拟化支持广泛的存储解决方案，涵盖 OpenShift 数据基础和 Portworx 等 Kubernetes 原生选项和 iSCSI 和光纤通道（FC）SAN 等传统企业系统。具备这样的灵活性，使得用户能够选择最适合其性能和运维需求的存储。
虽然在选择适当的存储选项方面没有通用的规则，但以下原则可作为指导：
- 在运维灵活性需求（易于置备、与平台集成）和性能（IO 延迟、吞吐量）要求之间取得平衡。
- 支持 Oracle RAC 数据库可能需要的多重写入选项（两个或多个虚拟机之间的共享卷）。
硬件配置
初始性能测试的设计范围仅限于当前可用的一组硬件资源。
集群规格：
- 4 台戴尔 R660 服务器
- 128 个 CPU 线程（2 个英特尔至强 Gold 6430 插槽）
- 256GB 内存
- 1TB 根磁盘
- 4 个 1.5TB NVME 驱动器
- 4 个 25Gbps Broadcom NIC
- 2 个 25Gbps Intel 810 NIC
OpenShift 虚拟化配置
虽然 OpenShift 虚拟化和 OpenShift 数据基础存储的默认配置能提供合理的性能，但为了优化数据库中典型的 IO 密集型工作负载的测试平台，我们对配置进行了进一步更改：
- 将 OpenShift 数据基础配置为使用性能配置文件。
- 配置了 OpenShift 数据基础和 OpenShift 虚拟化，以将 OpenShift 数据基础存储流量与常规软件定义网络（OpenShift 容器平台 SDN）流量分离开来。（第 8 章.网络要求 | 规划您的部署 | 红帽 OpenShift 数据基础 | 4.18）
- 使用单独的物理网络接口，将虚拟机（Oracle 数据库和 HammerDB 测试框架）的流量与 OpenShift 数据基础存储和 OpenShift 容器平台 SDN 隔离开来。为了减少延迟并提高吞吐量，通过单根 I/O 虚拟化（SR-IOV）为受影响的虚拟机引入了网络接口（图 2）。
集群规格：
- OpenShift 版本：4.18.9
- OpenShift 虚拟化：通过 OperatorHub 启用
- 节点：
- 3 个混合（控制平面/工作/存储）节点
- 1 个工作节点
- 网络（特定于 Oracle 数据库虚拟机）：
- 配备 4 个 Broadcom 25Gbps NIC 的 LACP 绑定，通过分区隔离 OpenShift SDN、OpenShift 数据基础存储客户端及 OpenShift 数据基础存储复制流量。
- 两个英特尔 x810 25GB NIC 用于处理虚拟机流量，通过两个不同的子网（公共和私有），并利用 SR-IOV 提供给虚拟机。
- 存储（特定于 Oracle 数据库虚拟机）：OpenShift 数据基础存储（由 4 个 1.5 TB NVMe 驱动器提供支持）配置了性能配置文件，并使用单独的存储网络。
Oracle 数据库配置
用于托管 Oracle 数据库的虚拟机大小适中，以避免资源过度分配，并比较不同硬件选项的测试结果。Oracle 数据库尚未针对事务处理性能委员会基准 C（TPC-C）测试进行专门调优，除了基于最佳实践进行的一些常见调优更改外，主要采用默认配置。
我们根据虚拟机的大小、基准测试工作负载的具体情况以及监控信息来选择调优参数。通过将测试结果与基线数据进行对比，我们评估了每项变更的实际效果。按照《数据库性能调优指南》中的建议，可对 Oracle 数据库配置进一步优化。
图 3 显示 Oracle 数据库和 HammerDB 客户端访问位于同一网络上。虚拟机的数据卷配置为预分配磁盘空间，以改进写入操作。
我们执行了单独的临时测试，通过使用本地存储 operator 添加 NVMe 存储，评估存储对数据库性能的影响。
虚拟机规格：
- 操作系统：RHEL 8.10
- 虚拟机数量：1
- vCPU：16
- 内存：48GB
- 存储：250GB（根和数据库数据驻留在同一卷上）作为来自 RH ODF 的块设备
- DataVolume：使用“preallocation: true”（厚置备）创建。
- 网络：使用 SR-IOV 连接到公共子网。
Oracle 数据库单实例设置：
Oracle 数据库版本：19c 企业版，附带版本更新 26（版本号 19.26）
- 该数据库采用文件系统作为数据文件存储目标（具有 OpenShift 数据基础支持的存储的根卷），并通过 OMF（Oracle 托管文件）进行管理。
- 为确保测试与未来版本的 Oracle 数据库的兼容性，采用容器数据库（CDB）架构创建了数据库。
- 内存分配使用 32GB 的总内存作为数据库创建向导的输入（允许 Oracle 数据库安装程序自动评估 SGA/PGA 的分配比例）。
- 其他调优参数：
- 4 个数据文件手动扩展到 32GB
- REDO 日志大小调整为 4GB
- 4 个 REDO 日志磁盘组
- FILESYSTEMIO_OPTIONS：SETALL（允许异步 IO 和直接 IO）
- USE_LARGE_PAGES：AUTO（优化大型 SGA 的 CPU 使用率）
注意：对于使用由 NVME 提供支持的存储进行的性能测试，已使用 NVME 设备挂载了单独的文件系统，并将其指定为数据文件的目标存储位置。
可观测性和监控
OpenShift 提供了一个功能强大的集成式可观测性平台，可整合跨基础架构和应用层的监控。它原生支持指标收集、日志记录和警报，并且可以进行扩展以包含来自 Oracle 数据库等外部应用的可观测性数据。这种统一的方法可降低运维复杂性，同时实现端到端可见性。
OpenShift 虚拟化的可观测性功能已无缝集成到同一平台中，使您能够监控虚拟机、系统资源和工作负载（比如，在单个一致的监控堆栈中监控 Oracle 数据库）。
部署于 OpenShift 中的 Oracle 数据库可观测性导出器会收集 Oracle 数据库性能指标和元数据，并将这些内容提供给 Prometheus。Grafana 则对这些指标进行可视化展示，提供实时信息面板来检测 Oracle 数据库和虚拟机层中的异常模式、资源压力和性能问题。
为了增强数据库级分析，您可以在性能测试期间利用 HammerDB，捕获快照并生成 AWR（自动工作负载存储库）报告。这些报告结合来自 Prometheus 和 Grafana 的指标，可让您从多个维度更全面地了解工作负载行为和潜在障碍。
此外，Oracle 数据库企业管理器可作为补充工具，提供针对 Oracle 数据库量身定制的详细诊断和专门的监控功能。它与 OpenShift 的统一可观测性平台搭配使用，可确保全面覆盖基础架构和特定于 Oracle 数据库的运维见解。
图 5 显示了作为 OpenShift 虚拟化平台的可观测性和监控设置的一部分部署的示例 Grafana 信息面板。
图 6 显示了在 OpenShift 虚拟化平台上部署的示例 Oracle 数据库 Grafana 信息面板。
系统性能评估
性能测试旨在测量 OLTP（在线事务处理）工作负载下的数据库事务吞吐量和查询延迟。我们使用开源数据库性能测试软件 HammerDB，通过 TPC-C 基准测试，针对具有前述系统详情的单实例 Oracle 数据库模拟了 OLTP 工作负载。TPC-C 测试模拟了真实的订单管理系统，包含 80% 的写入操作和 20% 的读取操作，涵盖高频客户订单、付款、库存检查和批量交付等场景。测试执行过程中，HammerDB 在 OpenShift 虚拟化中的 Oracle 数据库上生成 TPC-C 工作负载。
测试覆盖范围概述
借助 HammerDB 测试框架，我们配置了 scale-run 配置文件以模拟具有实际意义的工作负载：虚拟用户数量从最初 20 个逐步扩展到 100 个，每次测试运行使用 500 个数据仓库且持续 20 分钟。此设计旨在反映真实生产场景，并评估系统在扩展事务负载下的性能。
基于参考架构配置，测试结果表明，采用 OpenShift 数据基础存储的单实例 Oracle 数据库，在每分钟新订单数（NOPM）和每分钟事务数（TPM）指标方面表现出色。但是，与 OpenShift 数据基础设置相比，具有本地 NVMe 存储的单实例 Oracle 数据库提供了更出色的性能表现。虽然平均延迟数据相对稳定，但我们偶尔会观察到延迟峰值现象。
结语
OpenShift 虚拟化是用于部署 Oracle 数据库 19c 工作负载的可行且可靠的平台。OpenShift 虚拟化易于设置，可为创建虚拟机提供强大的支持。综合这些因素，OpenShift 虚拟化已成为同类虚拟化技术产品的有力竞争者和替代选择。当前对 Oracle 数据库 19c 的性能验证表明，该数据库在 OpenShift 虚拟化平台上展现出企业级性能表现。
通过对本地 NVMe 存储进行临时测试，我们评估了高性能存储选项的影响，并发现明确迹象表明，升级到 FC SAN 等高性能存储解决方案可显著提升整体性能。
对于高性能工作负载，建议考虑以下方案：
- 针对 Oracle 数据库数据文件和重做日志，采用 FC SAN 等高性能存储选项，以优化性能。
- 为虚拟机、OpenShift SDN 和存储网络划分独立网络，建议在 OpenShift 虚拟化节点上使用单独的物理设备。
- 如果硬件支持，SR-IOV（单根 I/O 虚拟化）可优化托管 Oracle 数据库工作负载的虚拟机虚拟网络接口的性能。
- 根据您工作负载的具体需求，通过 Oracle 数据库的
USE_LARGE_PAGES参数配置 HugePages：此配置可调整内存页面大小，建议用于提高性能，尤其是在处理大于默认设置的 SGA 时。
您可以在此 Git 存储库中找到 HammerDB 测试脚本。
oracle-db-appdev-monitoring GitHub 项目旨在为 Oracle 数据库提供可观测性，使用户能够轻松跨应用和数据库了解性能并诊断问题。阅读相关说明，在 OpenShift 平台上设置项目。
