ITPub博客

首页 > IT基础架构 > 服务器/存储 > 在 Amazon EVS 和 FSx for ONTAP 上构建高可用 Oracle 数据库 | Amazon Web Services

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

服务器/存储 作者:ITPUB社群 时间:1970-01-01 08:33:46 0 删除 编辑

已投资 VMware Cloud Foundation (VCF) 的企业希望将其 Oracle 数据库迁移到 AWS,而无需重新架构应用程序或重新培训运维团队。Amazon Elastic VMware Service (Amazon EVS) 上的 Oracle 可以利用亚毫秒级存储延迟、基于快照的备份、跨区域灾难恢复 (DR) 以及独立的存储扩展,同时保留现有的 VMware 运维工作流。

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

在本文中,您将学习如何:

  • 在运行 VMware Cloud Foundation 9.1 的 Amazon EVS 上设计 Oracle Database 架构。

  • 为 Oracle 工作负载选择最优的 EC2 裸金属实例类型和 VM 规格。

  • 使用 Amazon FSx for NetApp ONTAP 作为 Oracle 数据和日志卷的 NFS 数据存储来架构存储。

  • 规划 SnapMirror 复制以实现跨区域灾难恢复。

  • 评估将现有 Oracle 工作负载从本地 VMware 迁移到 EVS 的迁移选项。

Amazon EVS 直接在 Amazon Virtual Private Cloud (Amazon VPC) 内的 Amazon Elastic Compute Cloud (Amazon EC2) 裸金属实例上运行 VMware Cloud Foundation (VCF) 环境。借助 VCF 9.x,Amazon EVS 预置裸金属基础设施和 VLAN 子网,然后您使用 Broadcom 的 VCF Installer(自部署模式)部署 VCF。VCF 9.x 还支持评估模式,因此您可以在应用许可证密钥之前验证设计,而 Solutions for Amazon EVS GitHub 仓库提供了 CloudFormation 和 Terraform 模板,用于自动化分阶段 VCF 9 部署。Amazon FSx for NetApp ONTAP 提供托管的 ONTAP 存储,支持 NFS、SMB、iSCSI 和 NVMe over TCP 访问。FSx for NetApp ONTAP 可以提供亚毫秒级响应时间、数 GBps 的吞吐量,以及每个文件系统高达 80,000 IOPS(参见 FSx for ONTAP 性能)。

有关更多信息,请参阅 FSx for NetApp ONTAP 功能。

有关分步部署流程(包括预置、存储配置、Oracle 安装和 SnapMirror 设置),请参阅我们的配套文章:在 Amazon EVS 上结合 FSx for ONTAP 逐步部署 Oracle Database。

解决方案架构

本节介绍在 Amazon EVS 上结合 Amazon FSx for NetApp ONTAP 存储跨两个 AWS 区域部署高可用 Oracle Database。图 1 展示了从本地通过混合连接进入生产 EVS 环境以及跨区域 DR 的编号数据流。

图 1:在 Amazon EVS 上结合 FSx for NetApp ONTAP 和跨区域 SnapMirror DR 的 Oracle Database

该架构由八个功能组件组成,将在下文中进行描述。

架构组件

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

  • 混合链路 — 本地数据中心通过 AWS Direct Connect 连接到 AWS,以获得专用的低延迟带宽。

  • 中转路由 — AWS Transit Gateway 在生产 VPC、DR 区域和本地网络之间路由流量。

  • 工作负载落地 — 流量到达运行在 i7i.metal-24xl Amazon EC2 裸金属实例上、采用 VCF 9.1 的 EVS 数据库集群。

  • 实时迁移 — VMware HCX(Hybrid Cloud Extension)使用 Replication Assisted vMotion 或批量迁移,将 Oracle 虚拟机从本地 VMware 迁移到 EVS,几乎零停机。

  • NFS 数据路径 — 每个 ESXi 主机将 Amazon FSx for NetApp ONTAP 挂载为 NFS 数据存储。Oracle 虚拟机以块设备(NFS 数据存储上的 VMDK)形式访问数据库卷,延迟低于毫秒,IOPS 最高可达 80,000。每个主机都有自己独立的 NFS 路径连接到 FSx for ONTAP,从而在整个集群中分配带宽。

  • 跨区域 DR — SnapMirror 将 FSx for ONTAP 卷(数据、日志、二进制文件)异步复制到 DR 区域,恢复点目标(RPO)可配置。

  • 动态路由 — NSX Tier-0 网关通过 BGP 与 Amazon VPC Route Server 建立对等连接。这是单向 BGP。Route Server 监听 NSX 通告的路由并将其写入 VPC 路由表,但不会将 VPC 路由通告回 NSX。

  • DR 故障转移 — 故障转移时,Transit Gateway 将流量路由到 DR 区域,预先配置的备用 Oracle 虚拟机在那里挂载 SnapMirror 副本卷。

在 EVS 上部署 Oracle Database 时需要考虑的因素

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

Oracle 许可注意事项:实例类型选择会影响 Oracle 许可成本,这是一个需要考虑的重要因素。我们建议申请 AWS Optimization and Licensing Assessment (AWS OLA) 以获取进一步指导。

ESXi 主机的 EC2 实例类型选择

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

  • i7i.metal-24xl(推荐的默认选项):96 个 vCPU(48 核),768 GiB RAM。第五代 Intel Xeon 提供更高的计算性能,这对 Oracle CPU 密集型查询至关重要。第三代 AWS Nitro SSD 为 vSAN 提供增强的实时存储性能和更低的 IO 延迟。

  • i7i.metal-48xl:与 24xl 相同的第五代 Intel Xeon,但每主机容量翻倍(192 个 vCPU、96 核、1,536 GiB RAM、最高 100 Gbps 网络和 60 Gbps Amazon Elastic Block Store (Amazon EBS) 带宽)。当您希望纵向扩展单个 Oracle 主机时选择此类型,例如用于大型 SGA、高核心数,或使用更少但更密集的主机以降低 VMware 每主机许可费用。它保持与 24xl 相同的每核性能特征。

  • i4i.metal:更高的每主机密度(128 个 vCPU、1,024 GiB RAM、30 TB NVMe)适合需要更少但更大主机以降低 VMware 许可成本的环境。

VCF 兼容性:所有三种实例类型都支持 VCF 9.1 与 ESXi 9.1(build 9.1.0.0100.25433460)。VCF 5.2.2(ESXi 8.0U3g)仍然可用,但已处于支持终止路径上,因此新部署应默认使用 9.x。一个 EVS 环境每个集群支持 4–32 个主机。您可以在同一 SDDC 内的不同集群中混合使用实例类型。

Oracle Database 客户机的虚拟机规模

根据以下工作负载特征来确定 Oracle 数据库虚拟机(VM)的规格:

  • 分配的 vCPU 数量应与 Oracle 的 CPU_COUNT 参数相匹配。

  • 内存规格应满足 SGA + PGA + 操作系统开销(通常 SGA 占已分配 VM 内存的 75–85%)。

  • 在 vSAN 数据存储(而非 NFS)上配置 VM 交换空间。vSAN 使用本地 NVMe,延迟为个位数毫秒。

  • 对于超过单插槽核心数的 VM,使用 NUMA 感知的 VM 放置策略。

  • 将操作系统交换空间和 Oracle 临时表空间放在 vSAN 数据存储上,以零额外成本获得个位数毫秒延迟。

存储架构:vSAN + FSx for NetApp ONTAP

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

  • vSAN(由每台 ESXi 主机上的本地 NVMe 驱动器提供支持)处理低延迟、非复制型工作负载:VM 启动磁盘、操作系统交换空间和 Oracle 临时表空间。

  • FSx for NetApp ONTAP 处理需要基于快照的备份和跨区域复制的 Oracle 数据文件和重做日志。ESXi 主机将 FSx for ONTAP 卷挂载为 NFS 数据存储,Oracle VM 访问这些数据存储上的标准 VMDK。

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

为什么使用 NFS 数据存储(主机级)而不是客户机内 NFS(dNFS)?使用客户机内 NFS 时,所有 Oracle NFS 流量在到达 FSx for ONTAP 之前都要经过 NSX 覆盖网络和 NSX Edge 节点。这会形成单一的 Edge 瓶颈点。使用 NFS 数据存储时,每台 ESXi 主机使用自己的网络带宽直接与 FSx for ONTAP 进行 NFS 通信。没有 Edge 瓶颈,也没有额外的延迟跳数。

FSx for NetApp ONTAP 规格考量

重要:Oracle 请使用 100% SSD。我们建议不要对 Oracle 数据库卷使用容量池分层。将所有 Oracle 卷的分层策略设置为 none。重要: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 Route Server 替代了 VPC 内的静态路由。NSX Tier-0 网关通过 BGP 与 Route Server 端点建立对等连接。这是单向 BGP:Route Server 监听来自 NSX 的路由并将其编程到 VPC 路由表中,但不会将 VPC 路由通告回 NSX。在 VPC 之外,路由在 Transit Gateway 处仍为静态路由。

面向 Oracle 的 NSX-T 分段

  • 为生产数据库分段(DB 子网)提供专用的 Tier-1 网关

  • 为应用层(App 子网)和外围网络提供独立的 Tier-1。

  • 分布式防火墙规则将 Oracle 监听器访问(TCP 1521)限制为仅授权的应用分段。

  • Oracle 实例之间的微分段可防止横向移动。

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

高可用性与灾难恢复

  • SnapMirror 复制频率决定 RPO。请根据业务需求进行配置。

  • 在 DR 集群中预先配置备用 Oracle VM,以缩短恢复时间目标(RTO)。

  • 复制二进制卷,以便在恢复期间无需安装 Oracle。

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

DR 的 Oracle 许可注意事项:DR 复制的实现方式会影响许可。如果您有许可相关问题,我们建议申请 AWS 优化与许可评估(AWS OLA)。为遵守 Oracle 许可规则,另一种方法是通过 NetApp SnapMirror 将 Oracle VM 从生产环境复制到 DR。将 DR 复制卷保留为数据保护(DP)卷,在宣布故障转移事件之前不要将其作为 NFS 数据存储挂载到 DR 主机上,以避免 Oracle 双重许可。只有在宣布故障转移后,才断开 SnapMirror,将 NFS 数据存储挂载到 DR 主机上,并启动 VM。即使没有 VM 启动,预先将 SnapMirror 卷挂载为数据存储也意味着 Oracle 二进制文件可在这些主机上访问,Oracle 可能将其视为需要在整个 DR 集群中获得许可的“安装”。

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

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

| 选项 | 方法 | 最适合 | 停机时间 |
| --- | --- | --- | --- |
| 1 | VMware HCX 实时迁移 | 现有本地 VMware | 接近零(vMotion)或计划批量迁移 |
| 2 | SnapMirror ONTAP 到 ONTAP | 本地 NetApp ONTAP 上的 Oracle | 分钟级(最终同步切换) |
| 3 | Oracle PDB 重定位 | PDB/CDB 多租户模型 | 短暂(仅最终切换) |
| 4 | RMAN 备份/恢复 | 非 ONTAP 本地环境(通用) | 小时级(备份 + 恢复 + 应用) |

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

安全性

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

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

成本优化

Amazon EVS 上 Oracle 的成本优化侧重于将基础设施容量与工作负载需求相匹配,并利用 AWS 定价模型。下表总结了计算、存储、网络和 Oracle 许可方面的关键策略。我们建议申请 AWS Optimization and Licensing Assessment (AWS OLA) 以获取进一步指导。

| 组件 | 策略 |
| --- | --- |
| EC2 裸金属主机 | Compute Savings Plans 或 Reserved Instances(最高节省 54%) |
| 实例类型选择 | i7i.metal-24xl 相比 i4i.metal 提供约 10% 的性价比提升 |
| FSx for ONTAP 吞吐量 | 根据写入工作负载合理配置,并可动态调整 |
| FSx for ONTAP 存储 | 对 Oracle 使用 100% SSD,对非生产环境使用存储效率功能 |
| 数据传输 | 将 FSx for ONTAP 放置在与 EVS 集群相同的可用区 |
| SnapMirror 复制 | 根据 RPO 安排复制频率(频率越低 = 成本越低) |
| Oracle DR 许可 | 通过 NetApp SnapMirror 将 Oracle VM 从生产环境复制到 DR,将 DR 复制卷保留为数据保护(DP)卷,在宣布故障转移事件之前不将其挂载为 DR 主机上的 NFS 数据存储,以避免 Oracle 双重许可。当宣布故障转移事件时,断开 SnapMirror,在 DR 主机上挂载 NFS 数据存储,并启动 VM。我们建议申请 AWS Optimization and Licensing Assessment (AWS OLA) 以获取进一步指导。 |
| 非生产环境 | 使用更少的主机,并对开发/测试数据应用分层 |

总结

在 Amazon EVS 上使用 Amazon FSx for NetApp ONTAP 部署 Oracle 数据库,可提供高可用性、跨区域 DR 和亚毫秒级存储延迟,同时将 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 Relocation(多租户)和 RMAN(通用)。

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

  • 成本效率:通过 i7i 提升性价比、动态吞吐量调整和 AWS Savings Plans。

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

后续步骤

要开始此部署:

  • 在目标区域中预置 Amazon EVS 环境。有关设置说明,请参阅 Amazon EVS 用户指南。

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

  • 按照我们配套文章中的分步操作,挂载 NFS 数据存储、创建 Oracle VMDK 并配置 SnapMirror DR。

  • 先在非生产环境中测试,然后迁移生产 Oracle 工作负载。

其他资源

  • Amazon EVS 用户指南

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

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

  • 将 FSx for NetApp ONTAP 与 EVS 配合使用

  • Amazon EVS 定价

  • AWS 新闻博客上的 Amazon EVS 介绍

  • 适用于 Oracle 的 NetApp 自动化工具包

  • 在 Amazon EVS 上使用 FSx for ONTAP 逐步部署 Oracle 数据库(配套文章)


转载声明:本文为转载整理,原文版权归原作者及原站点所有。

原文来源:AWS Architecture Blog

原创地址:https://aws.amazon.com/blogs/architecture/architect-highly-available-oracle-database-on-amazon-evs-and-fsx-for-ontap/

原文作者:Satish Bhoi;如有侵权,请联系管理员删除。

请登录后发表评论 登录
全部评论

注册时间:2022-11-21

  • 博文量
    1090
  • 访问量
    546760