Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP

在 Amazon EVS 和 FSx for ONTAP 上构建高可用 Oracle 数据库 | AWS 架构博客

在 Amazon EVS 和 FSx for ONTAP 上构建高可用 Oracle 数据库

已投资 VMware Cloud Foundation (VCF) 的企业希望在不重新设计应用程序或重新培训运维团队的情况下，将 Oracle 数据库迁移至 AWS。运行在 Amazon 弹性 VMware 服务 (Amazon EVS) 上的 Oracle 可利用亚毫秒级存储延迟、基于快照的备份、跨区域灾难恢复 (DR) 以及独立的存储扩展能力，同时保留现有的 VMware 运维工作流程。

在本文中，我们将展示如何在 Amazon EVS 和 Amazon FSx for NetApp ONTAP 上构建完整的 Oracle 数据库环境。您将了解存储、计算、网络和灾难恢复层如何协同工作，以实现高可用性、跨区域 DR 和亚毫秒级存储延迟，同时保留熟悉的 VMware 运维工具。

通过本文，您将学习：

• 如何在运行 VMware Cloud Foundation 9.1 的 Amazon EVS 上设计 Oracle 数据库架构。
• 如何为 Oracle 工作负载选择最佳 EC2 裸机实例类型和虚拟机规格。
• 如何使用 Amazon FSx for NetApp ONTAP 作为 NFS 数据存储，为 Oracle 数据和日志卷构建存储。
• 如何规划跨区域灾难恢复的 SnapMirror 复制。
• 如何评估将现有 Oracle 工作负载从本地 VMware 迁移到 EVS 的选项。

Amazon EVS 在 Amazon 虚拟私有云 (Amazon VPC) 内的 Amazon 弹性计算云 (Amazon EC2) 裸机实例上直接运行 VMware Cloud Foundation (VCF) 环境。通过 VCF 9.x，Amazon EVS 提供裸机基础设施和 VLAN 子网，然后您使用 Broadcom 的 VCF 安装程序（自部署模式）部署 VCF。VCF 9.x 还支持评估模式，因此您可以在应用许可证密钥之前验证设计，Amazon EVS GitHub 仓库中的解决方案提供了 CloudFormation 和 Terraform 模板，用于自动化分阶段部署 VCF 9。Amazon FSx for NetApp ONTAP 提供托管的 ONTAP 存储，支持 NFS、SMB、iSCSI 和 TCP 上的 NVMe 访问。FSx for NetApp ONTAP 可实现亚毫秒级响应时间、多 GBps 的吞吐量，以及每个文件系统高达 80,000 IOPS（参见 FSx for ONTAP 性能）。

如需更多信息，请参阅 FSx for NetApp ONTAP 功能。

有关部署步骤（包括资源分配、存储配置、Oracle 安装和 SnapMirror 设置）的详细说明，请参阅我们的配套文章：在 Amazon EVS 上使用 FSx for ONTAP 分步部署 Oracle 数据库。

解决方案架构

本节描述了在两个 AWS 区域内，使用 Amazon EVS 和 Amazon FSx for NetApp ONTAP 存储构建高可用 Oracle 数据库部署的架构。图 1 展示了从本地通过混合连接到生产 EVS 环境和跨区域 DR 的编号数据流。

图 1：在 Amazon EVS 上运行的 Oracle 数据库，结合 FSx for NetApp ONTAP 和跨区域 SnapMirror DR

该架构包含八个功能组件，详见下文。

架构组件

这些编号项对应图中所示的数据流。

• 混合连接 — 本地数据中心通过 AWS Direct Connect 连接到 AWS，以获得专用的低延迟带宽。
• 中转路由 — AWS Transit Gateway 在生产 VPC、DR 区域和本地网络之间路由流量。

• 工作负载接入 — 流量通过运行在 i7i.metal-24xl Amazon EC2 裸金属实例上的 EVS 数据库集群，使用 VCF 9.1 进行传输。

• 热迁移 — VMware HCX（混合云扩展）通过复制辅助的 vMotion 或批量迁移，将 Oracle 虚拟机从本地 VMware 迁移到 EVS，实现接近零停机时间。

• NFS 数据路径 — 每个 ESXi 主机将 Amazon FSx for NetApp ONTAP 挂载为 NFS 存储库。Oracle 虚拟机以块设备（NFS 存储库上的 VMDK）形式访问数据库卷，延迟低于毫秒级，最高可达 80,000 IOPS。每个主机通过独立的 NFS 路径连接到 FSx for ONTAP，实现集群内带宽的分布。

• 跨区域灾难恢复 — SnapMirror 异步将 FSx for ONTAP 卷（数据、日志、二进制文件）复制到灾难恢复区域，可配置恢复点目标（RPO）。

• 动态路由 — NSX Tier-0 网关通过 BGP 与 Amazon VPC 路由服务器对等。这是单向 BGP。路由服务器监听 NSX 广告的路由并将其写入 VPC 路由表，但不会将 VPC 路由回传给 NSX。

• 灾难恢复切换 — 切换时，Transit Gateway 路由到灾难恢复区域，预先配置的备用 Oracle 虚拟机挂载 SnapMirror 副本卷。

在 EVS 上部署 Oracle 数据库需考虑的因素

在开始部署之前，评估您的 Oracle 工作负载需求与可用的基础设施选项。您对实例类型、虚拟机规模和存储架构的选择会直接影响数据库性能、成本和运营复杂性。

Oracle 授权考虑因素：实例类型选择会影响 Oracle 授权成本，这是一个重要的考虑因素。我们建议请求 AWS 优化和授权评估（AWS OLA）以获取进一步指导。

ESXi 主机的 EC2 实例类型选择

目前，Amazon EVS 支持三种裸金属实例类型用于 ESXi 主机。选择取决于您是优先考虑每核计算速度（i7i）还是每主机内存和存储密度（i4i），以及您希望单个主机垂直扩展的程度。对于大多数新的 Oracle 部署，i7i 是更好的选择，因为 Oracle 查询性能对 CPU 指令吞吐量和存储 IO 延迟敏感。

• i7i.metal-24xl（推荐默认）：96 个 vCPU（48 核），768 GiB 内存。第五代 Intel Xeon 处理器提供改进的计算性能，对 Oracle CPU 密集型查询至关重要。第三代 AWS Nitro SSD 提供增强的实时存储性能和更低的 IO 延迟，适用于 vSAN。

• i7i.metal-48xl：与 24xl 使用相同的第五代 Intel Xeon 处理器，但每主机容量翻倍（192 个 vCPU，96 核，1,536 GiB 内存，最高 100 Gbps 网络和 60 Gbps Amazon Elastic Block Store（Amazon EBS）带宽）。当您需要垂直扩展单个 Oracle 主机时选择此类型，例如用于大型 SGA、高核心数或更少但更密集的主机以减少 VMware 每主机授权。它与 24xl 保持相同的每核性能配置。

• i4i.metal：更高的每主机密度（128 个 vCPU，1,024 GiB 内存，30 TB NVMe）适合需要更少、更大的主机以减少 VMware 授权成本的环境。

VCF 兼容性：所有三种实例类型均支持 VCF 9.1（ESXi 9.1，构建版本 9.1.0.0100.25433460）。VCF 5.2.2（ESXi 8.0U3g）仍可用，但即将停止支持，因此新部署应默认使用 9.x 版本。EVS 环境每集群支持 4–32 个主机。可以在同一 SDDC 内跨集群混合使用实例类型。

Oracle数据库虚拟机的规模配置

根据以下工作负载特征确定Oracle数据库虚拟机的规模：

• 分配与Oracle CPU_COUNT参数匹配的vCPU数量。
• 为SGA（共享全局区）+ PGA（程序全局区）+ 操作系统开销分配内存（SGA通常占用分配的虚拟机内存的75–85%）。
• 在vSAN数据存储上配置虚拟机交换空间（而非NFS）。vSAN使用本地NVMe设备，延迟仅以毫秒级计数。
• 对于超过单插槽核心数量的虚拟机，使用NUMA感知的虚拟机放置策略。
• 将操作系统交换空间和Oracle临时表空间置于vSAN数据存储上，以毫秒级延迟实现零额外成本。

存储架构：vSAN + FSx for NetApp ONTAP

推荐设计将存储职责分为两个层级：

• vSAN（由每个ESXi主机上的本地NVMe驱动器支持）处理低延迟、非复制工作负载：虚拟机启动磁盘、操作系统交换空间和Oracle临时表空间。
• FSx for NetApp ONTAP处理需要基于快照的备份和跨区域复制的Oracle数据文件和重做日志。ESXi主机将FSx for ONTAP卷挂载为NFS数据存储，Oracle虚拟机通过这些数据存储访问标准VMDK文件。

这种分离为临时I/O提供了本地NVMe速度，同时为持久化数据库文件增加了快照、克隆和SnapMirror功能。

为何选择主机级NFS数据存储而非客机内NFS（dNFS）？使用dNFS时，所有Oracle NFS流量必须通过NSX叠加网络和NSX Edge节点才能到达FSx for ONTAP，这会形成单一Edge瓶颈。而使用NFS数据存储时，每个ESXi主机可直接通过自己的网络带宽与FSx for ONTAP通信，不存在Edge瓶颈或额外延迟跳转。

FSx for NetApp ONTAP规模规划要点

重要：Oracle数据库必须使用100% SSD。我们不建议对Oracle数据库卷使用容量池分层。所有Oracle卷的分层策略应设置为“无”。重要：SSD容量规划。当SSD层级达到容量上限时，FSx for ONTAP将阻止写入操作。监控SSD使用率并预留容量空间（最低保持20%空闲）。重要：读写吞吐量不对称性。在6 GB/s的文件系统中，读取吞吐量可达6 GB/s，但写入吞吐量仅限约1 GB/s。根据Oracle写入工作负载需求规划吞吐量容量。此写入上限适用于每个高可用性（HA）对。若需扩展单个HA对之外的写入吞吐量，请部署包含多个HA对的文件系统，并将Oracle卷分布在额外聚合中以实现跨HA对的写入负载均衡。此部署不是自动完成的，需提前规划布局以保持写入密集型数据集的平衡。

网络架构

Amazon EVS使用VLAN子网（在环境创建时定义且后续不可更改）对流量进行分段。

VPC路由服务器取代VPC内的静态路由。NSX Tier-0网关通过BGP与路由服务器端点对等通信。这是单向BGP：路由服务器监听来自NSX的路由并将其写入VPC路由表，但不会将VPC路由回传至NSX。VPC之外的路由仍保持在Transit Gateway的静态配置。

NSX-T对Oracle的网络隔离

• 为生产数据库网段（DB子网）分配专用Tier-1网关
• 为应用层（App子网）和外围网络分配独立Tier-1网关
• 分布式防火墙规则限制Oracle监听器访问（TCP 1521端口）仅限授权应用网段
• Oracle实例间的微隔离防止横向移动

重要提示：安全组规则不会在VLAN子网接口上执行。请使用网络ACL和NSX分布式防火墙进行流量控制。

高可用性与灾难恢复

• SnapMirror复制频率决定RPO（恢复点目标）。请根据业务需求进行配置。

• 在DR集群中预先部署备用Oracle虚拟机，以减少恢复时间目标（RTO）。

• 复制二进制卷，以便在恢复过程中无需重新安装Oracle。

• 使用Ansible/SnapCenter实现故障转移自动化，以减少人为错误。

Oracle灾难恢复的许可考虑：灾难恢复复制的实现方式会影响许可。如果您有许可相关问题，我们建议申请AWS优化和许可评估（AWS OLA）。为符合Oracle许可规则，可选方案是通过NetApp SnapMirror将Oracle虚拟机从生产环境复制到DR环境。在发生故障转移之前，将DR复制卷作为数据保护（DP）卷保留，且不要在DR主机上将其挂载为NFS数据存储，以避免Oracle双重许可。只有在声明故障转移后，才中断SnapMirror复制，将NFS数据存储挂载到DR主机并启动虚拟机。即使没有虚拟机运行，提前将SnapMirror卷作为数据存储挂载到主机上，也可能导致Oracle认为这些主机上存在“安装”，从而需要在整个DR集群中进行许可。

从本地VMware迁移到EVS的数据库迁移

下表比较了从本地VMware迁移到EVS的迁移选项。

选项 | 方法 | 最适合场景 | 下线时间 --- | --- | --- | --- 1 | VMware HCX实时迁移 | 现有本地VMware | 几乎为零（vMotion）或计划批量迁移 2 | SnapMirror | ONTAP到ONTAP | 本地Oracle运行在NetApp ONTAP上 | 几分钟（最终同步切换） 3 | Oracle PDB迁移 | PDB/CDB多租户模型 | 简短（仅最终切换） 4 | RMAN备份/恢复 | 非ONTAP本地（通用） | 几小时（备份+恢复+应用）

有关每种迁移选项的详细步骤，请参阅我们的配套文章：逐步在Amazon EVS上部署Oracle数据库，使用FSx for ONTAP。

安全性

Oracle在Amazon EVS上的安全性涵盖从网络隔离到数据库级加密的多个层次。下表总结了各层级的安全控制措施。

层级 | 控制措施 --- | --- 网络隔离 | NSX-T Tier-1网关隔离数据库/应用/外围网络段 东西向流量 | NSX分布式防火墙：限制TCP 1521端口到授权应用段 南北向流量 | FortiGate或等效的VPC检查点用于入站/出站过滤 静态加密 | 使用AWS密钥管理服务（AWS KMS）加密FSx for ONTAP卷 传输加密 | VPC加密用于NFS流量，IPsec用于跨区域SnapMirror 数据库加密 | Oracle透明数据加密（TDE）提供额外保护 管理访问 | 零信任访问（例如Banyan或Zscaler）用于VMware管理控制台 VLAN子网安全 | 网络ACL（安全组不会在VLAN接口上执行）

(up to 54% savings)

实例类型选择

i7i.metal-24xl 相比 i4i.metal 实现约 10% 的性价比提升

FSx for ONTAP 吞吐量

根据写入工作负载进行合理配置，并随时调整

FSx for ONTAP 存储

Oracle 采用 100% SSD，非生产环境实现存储效率优化

数据传输

将 FSx for ONTAP 部署在与 EVS 集群相同的可用区

SnapMirror 复制

根据 RPO 设置复制频率（频率越低成本越低）

Oracle 灾备授权

通过 NetApp SnapMirror 将生产环境的 Oracle 虚拟机复制到灾备环境，保持灾备复制卷作为数据保护（DP）卷，直到发生故障转移事件前不要在灾备主机上挂载为 NFS 数据存储，以避免 Oracle 双重授权。当发生故障转移事件时，中断 SnapMirror 复制，将 NFS 数据存储挂载到灾备主机，并启动虚拟机。我们建议申请 AWS 优化与授权评估（AWS OLA）以获取进一步指导。

非生产环境

减少主机数量，对开发/测试数据应用分级存储

总结

在 Amazon EVS 上部署 Oracle 数据库，结合 Amazon FSx for NetApp ONTAP 可实现高可用性、跨区域灾备和亚毫秒级存储延迟，同时融合 VMware 运维一致性与 AWS 云经济性：

• 性能：i7i.metal-24xl 实现高达 23% 的计算性能提升和 50% 的 IO 延迟降低。FSx for ONTAP 提供亚毫秒级延迟，最高支持 80,000 IOPS。详情请参阅 AWS GovCloud (US) 区域的 Amazon EC2 i7i 实例文档。

• 可用性：vSphere HA、SnapMirror 跨区域复制和可选的 Oracle Data Guard。

• 可管理性：通过 SnapCenter 实现秒级备份、克隆和恢复，与数据库规模无关。

• 迁移灵活性：HCX（实时迁移）、SnapMirror（ONTAP 到 ONTAP）、PDB 迁移（多租户）和 RMAN（通用方案）。

• 安全性：NSX 微分割、AWS KMS 加密和零信任访问。

• 成本效率：i7i 实例提升性价比、实时吞吐量调整和 AWS Savings Plans。

此架构在保持您熟悉的 VMware 运维工具和流程的同时，可提供类似 Oracle RAC 和 Data Guard 的高可用性、跨区域灾备和基于存储的备份克隆功能。

下一步操作

开始部署请执行以下步骤：

• 在目标区域中创建 Amazon EVS 环境。请参阅《Amazon EVS 用户指南》获取设置说明。

• 在与 EVS 集群相同的 VPC 和可用区中部署 Amazon FSx for NetApp ONTAP 文件系统。

• 按照配套文章中的逐步说明挂载 NFS 数据存储、创建 Oracle VMDK 和配置 SnapMirror 灾备。

• 首先在非生产环境进行测试，然后迁移生产 Oracle 工作负载。

附加资源

• 《Amazon EVS 用户指南》

• EVS 支持的 VCF 版本和实例类型

• 为 EVS 配置 FSx for ONTAP 作为 NFS 数据存储

• FSx for NetApp ONTAP 与 EVS 集成

• Amazon EVS 定价

• 《AWS 博客：介绍 Amazon EVS》

• NetApp Oracle 自动化工具包

• 在 Amazon EVS 上使用 FSx for ONTAP 分步部署 Oracle 数据库（配套文章）

作者简介

'"`