Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する

本稿は、2026 年 10 月 2 日に公開された “Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP” を翻訳したものです。

VMware Cloud Foundation (VCF) への既存投資がある企業は、アプリケーションの再設計や運用チームの再教育を行うことなく、Oracle データベースを AWS に移行したいと考えています。Amazon Elastic VMware Service (Amazon EVS) 上の Oracle は、既存の VMware 運用ワークフローを維持しながら、サブミリ秒のストレージレイテンシー、スナップショットベースのバックアップ、クロスリージョンディザスタリカバリ (DR)、および独立したストレージスケーリングを活用できます。

この記事では、Amazon FSx for NetApp ONTAP を使用して Amazon EVS 上に Oracle Database 環境を設計する方法を紹介します。使い慣れた VMware 運用ツールを維持しながら、ストレージ、コンピューティング、ネットワーキング、ディザスタリカバリの各レイヤーがどのように連携して高可用性、クロスリージョン DR、サブミリ秒のストレージレイテンシーを実現するかを学びます。

この記事では、以下の方法を学びます。

• VMware Cloud Foundation 9.1 が稼働する Amazon EVS 上の Oracle Database アーキテクチャの設計
• Oracle ワークロードに最適な EC2 ベアメタルインスタンスタイプと VM サイジングの選択
• Oracle のデータボリュームおよびログボリューム用の NFS データストアとして FSx for ONTAP を使用したストレージの設計
• クロスリージョン DR のための SnapMirror レプリケーション計画
• 既存の Oracle ワークロードをオンプレミスの VMware から Amazon 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 リポジトリでは段階的な VCF 9 デプロイメントを自動化する AWS CloudFormation および Terraform テンプレートが提供されています。FSx for ONTAP は、NFS、SMB、iSCSI、および NVMe over TCP アクセスを備えたマネージド ONTAP ストレージを提供します。FSx for ONTAP は、サブミリ秒の応答時間、数 GBps のスループット、およびファイルシステムあたり最大 80,000 IOPS を実現できます (FSx for ONTAP のパフォーマンスを参照)。

詳細については、FSx for ONTAP の機能を参照してください。

プロビジョニング、ストレージ設定、Oracle のインストール、SnapMirror のセットアップを含むデプロイメント手順については、関連記事「Amazon EVS と FSx for ONTAP における Oracle Database のデプロイステップ」を参照してください。

ソリューションアーキテクチャ

このセクションでは、2 つの AWS リージョンにまたがる Amazon FSx for ONTAP ストレージを使用した、Amazon EVS 上の高可用性 Oracle Database デプロイメントについて説明します。図 1 は、オンプレミスからハイブリッド接続を経由して本番 Amazon EVS 環境およびクロスリージョン DR に至るデータフローを示しています。

図 1: FSx for ONTAP とクロスリージョン SnapMirror DR を使用した Amazon EVS 上の Oracle Database

このアーキテクチャは 8 つの機能コンポーネントで構成されており、次のセクションで説明します。

アーキテクチャコンポーネント

以下の項目は、図に示されたデータフローに対応しています。

1. ハイブリッドリンク — オンプレミスデータセンターは、AWS Direct Connect を通じて AWS に接続し、低レイテンシーの専用帯域幅を確保します。
2. トランジットルーティング — AWS Transit Gateway が本番 VPC、DR リージョン、オンプレミスネットワーク間のトラフィックをルーティングします。
3. ワークロードランディング — トラフィックは、VCF 9.1 を搭載した i7i.metal-24xl Amazon EC2 ベアメタルインスタンス上で稼働する EVS データベースクラスターに到達します。
4. ライブマイグレーション — VMware HCX (Hybrid Cloud Extension) が、Replication Assisted vMotion または Bulk Migration を使用して、オンプレミスの VMware から Amazon EVS へ Oracle VM をほぼゼロダウンタイムで移行します。
5. NFS データパス — 各 ESXi ホストは FSx for ONTAP を NFS データストアとしてマウントします。Oracle VM は、データベースボリュームにブロックデバイス (NFS データストア上の VMDK) としてアクセスし、サブミリ秒のレイテンシーと最大 80,000 IOPS を実現します。各ホストは FSx for ONTAP への独立した NFS パスを持ち、クラスター全体で帯域幅を分散します。
6. クロスリージョン DR — SnapMirror が FSx for ONTAP ボリューム (データ、ログ、バイナリ) を、設定可能な目標復旧時点 (RPO) で DR リージョンに非同期でレプリケートします。
7. ダイナミックルーティング — NSX Tier-0 ゲートウェイが BGP を介して Amazon VPC Route Server とピアリングします。これは一方向の BGP です。Route Server は NSX によってアドバタイズされたルートをリッスンして VPC ルートテーブルに書き込みますが、VPC ルートを NSX に戻してアドバタイズすることはありません。
8. DR フェイルオーバー — フェイルオーバー時、Transit Gateway は DR リージョンにルーティングし、そこで事前にプロビジョニングされたスタンバイ Oracle VM が SnapMirror レプリカボリュームをマウントします。

Amazon EVS 上の Oracle Database デプロイメントで考慮すべき要素

デプロイメントを開始する前に、利用可能なインフラストラクチャオプションに対して Oracle ワークロードの要件を評価してください。インスタンスタイプ、VM サイジング、ストレージアーキテクチャについて行う決定は、データベースのパフォーマンス、コスト、運用の複雑さに直接影響します。

Oracle ライセンスに関する考慮事項: インスタンスタイプの選択は Oracle のライセンスコストに影響するため、考慮すべき重要な要素です。さらなるガイドラインについては、AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。

ESXi ホスト向けの EC2 インスタンスタイプの選択

Amazon EVS は現在、ESXi ホスト向けに 3 つのベアメタルインスタンスタイプをサポートしています。選択は、コアあたりのコンピューティング速度 (i7i) を優先するか、ホストあたりのメモリとストレージ密度 (i4i) を優先するか、また単一ホストを垂直方向にどの程度スケールしたいかによって異なります。ほとんどの新規 Oracle デプロイメントでは、Oracle のクエリパフォーマンスが CPU の命令スループットとストレージ IO レイテンシーに敏感であるため、i7i がより良い選択です。

• i7i.metal-24xl (推奨デフォルト): 96 vCPU (48 コア)、768 GiB RAM。第 5 世代 Intel Xeon は改善されたコンピューティングパフォーマンスを提供します。第 3 世代 AWS Nitro SSD は、vSAN 向けに、強化されたリアルタイムストレージパフォーマンスと低い IO レイテンシーを提供します。
• i7i.metal-48xl: 24xl と同じ第 5 世代 Intel Xeon ですが、ホストあたりの容量は 2 倍 (192 vCPU、96 コア、1,536 GiB RAM、最大 100 Gbps のネットワークおよび 60 Gbps の Amazon Elastic Block Store (Amazon EBS) 帯域幅)。大規模な SGA、高いコア数、または VMware のホストあたりライセンスを削減するためのより少なく高密度なホストなど、単一の Oracle ホストを垂直方向にスケールしたい場合に選択します。24xl と同じコアあたりのパフォーマンスプロファイルを維持します。
• i4i.metal: より高いホストあたり密度 (128 vCPU、1,024 GiB RAM、30 TB NVMe) で、より少なく大きなホストを必要とする環境に適しています。

VCF 互換性: 3 つのインスタンスタイプすべてが ESXi 9.1 (ビルド 9.1.0.0100.25433460) を備えた VCF 9.1 をサポートします。VCF 5.2.2 (ESXi 8.0U3g) は引き続き利用可能ですが、サポート終了に向かっているため、新規デプロイメントはデフォルトで 9.x を使用すべきです。Amazon EVS 環境はクラスターあたり 4〜32 ホストをサポートします。同じ SDDC 内のクラスター間でインスタンスタイプを混在させることができます。

Oracle Database ゲスト向けの VM サイジング

以下のワークロード特性に基づいて Oracle Database VM をサイジングします。

• Oracle の CPU_COUNT パラメーターに一致する vCPU 数を割り当てます。
• SGA + PGA + OS オーバーヘッド向けにメモリをサイジングします (通常、割り当てられた VM メモリの 75〜85% を SGA に)。
• VM スワップを vSAN データストア上に設定します (NFS ではない)。vSAN は 1 桁ミリ秒のレイテンシーを持つローカル NVMe を使用します。
• 単一ソケットのコア数を超える VM には NUMA 対応の VM 配置を使用します。
• 追加コストなしで 1 桁ミリ秒のレイテンシーを得るために、OS スワップと Oracle の一時表領域を vSAN データストア上に配置します。

ストレージアーキテクチャ: vSAN + FSx for ONTAP

推奨される設計では、ストレージの役割を 2 つの階層に分割します。

• vSAN (各 ESXi ホスト上のローカル NVMe ドライブで構成) は、低レイテンシーで非レプリケーションのワークロードを処理します。 ( VM ブートディスク、OS スワップ、Oracle 一時表領域)
• FSx for ONTAP は、スナップショットベースのバックアップとクロスリージョンレプリケーションを必要とする Oracle データファイルと REDO ログを処理します。ESXi ホストは FSx for ONTAP ボリュームを NFS データストアとしてマウントし、Oracle VM はそれらのデータストア上の標準 VMDK にアクセスします。

この分離により、一時的な IO にはローカル NVMe の速度を提供しつつ、永続的なデータベースファイルにはスナップショット、クローン、SnapMirror の機能を追加できます。

なぜゲスト内 NFS (dNFS) ではなく NFS データストア (ホストレベル) なのか？ ゲスト内 NFS では、すべての Oracle NFS トラフィックが FSx for ONTAP に到達する前に NSX オーバーレイと NSX Edge ノードを経由します。これにより単一の Edge ボトルネックが生じます。NFS データストアでは、各 ESXi ホストが自身のネットワーク帯域幅を使用して FSx for ONTAP と直接 NFS で通信します。Edge ボトルネックも余分なレイテンシーホップもありません。

FSx for 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 ボリュームを分散させて、書き込みがペア間で分散されるようにします。この配置は自動ではないため、書き込みの多いデータセットのバランスを保つために、事前にレイアウトを計画してください。

ネットワークアーキテクチャ

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 を決定します。ビジネス要件に基づいて設定します。
• 目標復旧時間 (RTO) を短縮するために、DR クラスターにスタンバイ Oracle VM を事前にプロビジョニングします。
• 復旧中に Oracle のインストールが不要になるように、バイナリボリュームをレプリケートします。
• ヒューマンエラーを減らすために、Ansible/SnapCenter でフェイルオーバーを自動化します。

DR に関する Oracle ライセンスの考慮事項: DR レプリケーションの実装方法に基づいてライセンスへの影響があります。ライセンスに関する質問がある場合は、AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。

Oracle のライセンス規則に準拠するための代替案として、NetApp SnapMirror を通じて Oracle VM を本番環境から DR にレプリケートする方法があります。Oracle の二重ライセンスを回避するため、フェイルオーバーイベントが宣言されるまで、DR のレプリケートされたボリュームを DR ホスト上で NFS データストアとしてマウントせず、データ保護 (DP) ボリュームとして保持してください。フェイルオーバーイベントが宣言された時点ではじめて、SnapMirror を解除し、DR ホスト上で NFS データストアをマウントし、VM の電源を入れます。VM の電源が入っていなくても SnapMirror ボリュームをデータストアとして事前にマウントすることは、それらのホスト上で Oracle バイナリにアクセス可能になることを意味し、Oracle はこれを DR クラスター全体でライセンスを必要とする「インストール」とみなす可能性があります。

オンプレミス VMware から Amazon EVS へのデータベース移行

以下の表は、オンプレミス VMware から Amazon EVS への移行オプションを比較しています。

各移行オプションの詳細な手順については、関連記事「Oracle Database Deployment on Amazon EVS and FSx for ONTAP: Best Practices」を参照してください。

セキュリティ

Amazon EVS 上の Oracle のセキュリティは、ネットワーク分離からデータベースレベルの暗号化まで、複数のレイヤーにまたがります。以下の表は、各レイヤーのセキュリティコントロールをまとめたものです。

コスト最適化

Amazon EVS 上の Oracle のコスト最適化は、インフラストラクチャ容量をワークロード需要に合わせることと、AWS の料金モデルを使用することに重点を置いています。以下の表は、コンピューティング、ストレージ、ネットワーキング、Oracle ライセンスにわたる主要な戦略をまとめたものです。さらなるガイドラインについては、AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。

まとめ

FSx for ONTAP を使用した Amazon EVS 上での Oracle データベースのデプロイメントは、VMware の運用一貫性と AWS クラウドの経済性を組み合わせながら、高可用性、クロスリージョン DR、サブミリ秒のストレージレイテンシーを提供します。

• パフォーマンス: 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-to-ONTAP)、PDB リロケーション (マルチテナント)、RMAN (汎用)。
• セキュリティ: NSX マイクロセグメンテーション、AWS KMS 暗号化、ゼロトラストアクセス。
• コスト効率: i7i による価格性能の向上、臨機応変なスループット調整、AWS Savings Plans。

このアーキテクチャは、使い慣れた VMware の運用ツールと手順を維持しながら、Oracle RAC や Data Guard の機能に類似した高可用性、クロスリージョン DR、ストレージベースのバックアップとクローンを提供します。

次のステップ

このデプロイメントを始めるには:

1. 対象リージョンに Amazon EVS 環境をプロビジョニングします。セットアップ手順については Amazon EVS ユーザーガイドを参照します。
2. EVS クラスターと同じ VPC およびアベイラビリティーゾーンに FSx for ONTAP ファイルシステムをデプロイします。
3. NFS データストアのマウント、Oracle VMDK の作成、SnapMirror DR の設定については、関連記事のステップバイステップ手順に従います。
4. まず非本番環境でテストし、その後本番の Oracle ワークロードを移行します。

その他のリソース

• Amazon EVS ユーザーガイド
• Amazon EVS がサポートする VCF バージョンとインスタンスタイプ
• Amazon EVS を使用した FSx for ONTAP
• Amazon EVS の料金
• AWS News Blog での Amazon EVS の紹介
• Amazon EVS と FSx for ONTAP における Oracle Database のデプロイステップ (関連記事)

著者について

翻訳はソリューションアーキテクト 齋藤が担当しました。原文はこちらです。