在 Amazon EVS 和 FSx for ONTAP 上构建高可用 Oracle 数据库架构
内容提要
本文介绍在Amazon EVS上结合FSx for NetApp ONTAP部署高可用Oracle数据库的架构，利用i7i裸金属实例运行VMware Cloud Foundation，通过NFS数据存储实现亚毫秒延迟和8万IOPS，并使用SnapMirror跨区域容灾，同时涵盖实例选型、存储分层、网络分段、安全、迁移方案及成本优化建议。
延伸解读
存储分层设计：vSAN 与 FSx for ONTAP 的分工
文章建议将存储职责拆分：vSAN 基于本地 NVMe，负责 VM 启动盘、OS swap 和 Oracle 临时表空间等低延迟、非复制型负载；FSx for ONTAP 则承载需要快照备份和跨区域复制的 Oracle 数据文件与重做日志。这种分离既保留了本地 NVMe 的瞬时 IO 速度，又为持久化数据库文件增加了快照、克隆和 SnapMirror 能力。读者需注意，Oracle 卷应使用 100% SSD 并关闭分层策略，否则 SSD 写满会阻塞写入。
网络路径选择：NFS 数据存储优于 in-guest NFS
文章对比了两种 NFS 访问方式：in-guest NFS 会让所有 Oracle NFS 流量经过 NSX overlay 和 NSX Edge 节点，形成单点瓶颈；而将 FSx for ONTAP 挂载为 ESXi 主机的 NFS 数据存储，每台主机直接与 FSx 通信，利用各自网络带宽，无 Edge 瓶颈和额外延迟跳数。此外，VLAN 子网接口不强制执行安全组规则，需依赖网络 ACL 和 NSX 分布式防火墙进行流量控制。
跨区域容灾与 Oracle 许可的平衡
SnapMirror 异步复制决定 RPO，预置 DR 集群中的待机 Oracle VM 可降低 RTO。但文章特别提醒 Oracle 许可风险：若将 DR 复制卷预先挂载为 NFS 数据存储，即使没有 VM 开机，Oracle 二进制文件在主机上可访问，可能被 Oracle 视为“安装”而要求整个 DR 集群许可。合规做法是保持 DR 卷为数据保护（DP）卷，不挂载为数据存储，仅在宣布故障切换时才中断 SnapMirror、挂载并启动 VM。
实例选型与成本优化要点
文章推荐 i7i.metal-24xl 作为多数新 Oracle 部署的默认选择，因其第五代 Intel Xeon 提供更高计算性能，且 Nitro SSD 降低 IO 延迟；i7i.metal-48xl 适合垂直扩展单主机，i4i.metal 则适合需要更少、更大主机以降低 VMware 许可成本的场景。成本方面，可考虑 Compute Savings Plans 或 Reserved Instances（最高节省 54%），并将 FSx for ONTAP 与 EVS 集群置于同一可用区以减少数据传输费用。
Q&A
在 Amazon EVS 上部署 Oracle 数据库，推荐使用哪种 EC2 裸金属实例类型？为什么？
推荐使用 i7i.metal-24xl。它配备 96 vCPU（48 核）、768 GiB 内存，采用第五代 Intel Xeon 处理器，可提供更好的计算性能，对 Oracle CPU 密集型查询至关重要；同时其第三代 AWS Nitro SSD 能提供更低的 IO 延迟。对于大多数新 Oracle 部署，i7i 是更好的选择，因为 Oracle 查询性能对 CPU 指令吞吐量和存储 IO 延迟敏感。
如何为 Oracle 数据库设计存储架构，以兼顾性能和快照/容灾能力？
推荐将存储职责分为两层：vSAN（基于本地 NVMe）处理低延迟、非复制工作负载，如 VM 启动盘、OS swap 和 Oracle 临时表空间；FSx for NetApp ONTAP 处理需要快照备份和跨区域复制的 Oracle 数据文件和重做日志。ESXi 主机将 FSx for ONTAP 卷挂载为 NFS 数据存储，Oracle VM 通过标准 VMDK 访问。这种分离既为临时 IO 提供本地 NVMe 速度，又为持久数据库文件增加快照、克隆和 SnapMirror 能力。
使用 FSx for NetApp ONTAP 作为 NFS 数据存储相比在客户机内使用 NFS（dNFS）有什么优势？
使用 NFS 数据存储时，每个 ESXi 主机直接使用自己的网络带宽与 FSx for ONTAP 通信，没有 NSX Edge 瓶颈和额外延迟跳。而客户机内 NFS 的所有 Oracle NFS 流量都经过 NSX 覆盖网络和 NSX Edge 节点，形成单一 Edge 瓶颈。
如何配置跨区域灾难恢复（DR）以满足 Oracle 许可要求并降低 RTO？
使用 SnapMirror 异步复制 FSx for ONTAP 卷（数据、日志、二进制）到 DR 区域，复制频率决定 RPO。为降低 RTO，在 DR 集群预置备用 Oracle VM，并复制二进制卷以便恢复时无需安装 Oracle。为避免 Oracle 双重许可，将 DR 复制卷保留为数据保护（DP）卷，在声明故障转移前不要将其挂载为 NFS 数据存储；故障转移时再中断 SnapMirror，挂载 NFS 数据存储并启动 VM。可使用 Ansible/SnapCenter 自动化故障转移。
从本地 VMware 迁移 Oracle 到 EVS 有哪些方案？各自适用场景和停机时间如何？
有四种方案：1) VMware HCX 实时迁移，适用于现有本地 VMware，停机时间接近零（vMotion）或计划内批量迁移；2) SnapMirror ONTAP 到 ONTAP，适用于本地 Oracle 运行在 NetApp ONTAP 上，停机时间分钟级（最终同步切换）；3) Oracle PDB 重定位，适用于 PDB/CDB 多租户模型，停机时间短暂（仅最终切换）；4) RMAN 备份/恢复，适用于非 ONTAP 本地环境（通用），停机时间数小时（备份+恢复+应用）。
在 Amazon EVS 上运行 Oracle 时，有哪些成本优化策略？
关键策略包括：EC2 裸金属主机使用 Compute Savings Plans 或 Reserved Instances（最高节省 54%）；选择 i7i.metal-24xl 比 i4i.metal 性价比高约 10%；FSx for ONTAP 吞吐量根据写入工作负载合理配置并可动态调整；Oracle 卷使用 100% SSD，非生产数据可使用存储效率功能；将 FSx for ONTAP 放在与 EVS 集群相同的可用区以减少数据传输费用；SnapMirror 复制频率根据 RPO 调整（频率越低成本越低）；对于 DR 许可，通过 SnapMirror 复制 Oracle VM 并保持 DP 卷不挂载以避免双重许可；非生产环境使用更少主机并对开发/测试数据应用分层。建议申请 AWS OLA 获取进一步指导。
