寄稿：パナソニック インフォメーションシステムズ での Oracle Database@AWS 検証レポート – 閉域接続・バックアップ・Data Guard・監視構成の検証

本稿は、パナソニック インフォメーションシステムズ社による「Oracle Database@AWS 検証レポート – 閉域接続・バックアップ・Data Guard・監視構成の検証」について、検証を実施された 田村 俊樹 様に寄稿いただきました。

はじめに

東京リージョンでの Oracle Database@AWS 稼働を見据え、技術的な実現可能性と課題を把握するため、先行してバージニア北部環境とオレゴン環境において、Oracle Database@AWS の設計・構築を行いました。

本記事では、閉域接続、バックアップ構成、Oracle Data Guard、監視構成について検証を実施した内容をご紹介します。

構成詳細

AWS 側では、ODB ネットワーク、Application VPC（今回の検証ではアプリケーションは未配置）、Transit VPC、及びこれらを接続する Transit Gateway の構成を採用しました。

OCI との閉域接続は ODB ピアリングを利用して確立しました。今回の検証では、Oracle Database@AWS は AWS リージョン内に設置された OCI 管理の Exadata インフラ上の VM で稼働し、AWS 側の ODB Networkと閉域接続されています。ODB ピアリングは Amazon Virtual Private Cloud と ODB ネットワーク間のセキュアな通信を実現します。

※ ODB ピアリング、ODB ネットワークに関してはこちらのブログをご参照ください。

一方、OCI 側では VCN 内の Compute からローカルピアリングゲートウェイ(以下、LPG )を通じて Exadata クラスタに接続する構成を採用し、リージョン間は動的ルーティングゲートウェイ (以下、DRG )で接続されています。DRG は OCI リージョン間の接続を担い、LPG は VCN 間のピアリングを提供することで、閉域網での通信を可能にしました。

検証目的

オンプレミスで稼働可能な構成を AWS と OCI 上でどのように再現できるかを検討し、その設計が Oracle Database@AWS で正常に稼働可能であることを確認することを目的としました。

検証観点

閉域接続を確認するため、AWS と OCI 間での疎通検証を実施しました。さらに、RMAN を用いたバックアップ取得の可否を確認し、監視構成については、AWS 側に OMS/OMR、Exadata 環境に Oracle Enterprise Manager Management Agent を導入し、閉域接続を介して CPU 使用率や I/Oなどのメトリクスを収集し、Oracle Enterprise Manager（以下、OEM）サーバに転送できることを確認しました。

※ Oracle Enterprise Manager (OEM) Management Agent は、ホスト上で実行中のターゲットをモニタリングし、その情報を中間層 Oracle Management Service (OMS) に送信するソフトウェアコンポーネントです。詳細については、Oracle ドキュメントの「Oracle Enterprise Manager Cloud Control 12c の概要」と「Oracle Enterprise Manager Cloud Control 13c の概要」を参照してください。

加えて、Data Guard 構成の可否を検証し、AWS 側のネットワーク、OCI 側のネットワークそれぞれでの同期が正常に行えることを確認しました。バックアップ方式については、OCI の Object Storage を利用した場合の構成手順を検証し、災害対策やデータ保護の観点からも有効な構成であることを確認しました。

OEM による監視構成

今回の検証では、OEM を用いて Oracle Database@AWS 上の Exadata 環境を監視しました。AWS 側では、Transit VPC 内に EC2 インスタンス（RHEL9）を配置し、OEM の管理サービス（以下、OMS）と管理リポジトリ（以下、OMR）を構成しました。OCI 側の Exadata データベースノードには OEM エージェントを導入し、CPU 使用率や I/O 性能などのメトリクスを収集できることを確認しました。（①の通信）

※ Oracle Management Repository (管理リポジトリ)は、 OMA によって収集された情報が格納されるリポジトリデータベースです。詳細については、Oracle ドキュメントの「Oracle Enterprise Manager Cloud Control 12c の概要」と「Oracle Enterprise Manager Cloud Control 13c の概要」を参照してください。

OCI 側では VCN 内に Compute インスタンス（RHEL9）を配置し、同様に監視エージェントを導入することで、Exadata の稼働状況を確認しました。(②の通信)

これにより、AWS と OCI 双方から Exadata のメトリクス収集と可視化が可能となり、閉域接続を介した監視構成の有効性を確認しました。

Data GuardによるDR構成

今回の検証では、Data Guard を利用して DR サイトへのデータベース同期を実現しました。AWS 側（①の通信）と OCI 側（②の通信）から Oracle Database@AWS の Exadata 環境に対して Data Guard 構成を設定し、OCI コンソールの作業リクエストで「スタンバイデータベースの作成」が成功したことにより、構成が正常に完了したことを確認しました。

障害発生時には AWS リージョンまたは OCI リージョンのいずれかでフェイルオーバが可能となり、高可用性と災害対策の観点で有効性を確認できました。

当初は、バージニア北部環境とオレゴン環境の ODB ネットワーク間の通信を VPC ピアリングで構成することを検討しました。しかし、VPC ピアリングでは推移的な接続がサポートされないため、複数ネットワーク間の経路確立ができませんでした。そこで、Transit Gateway を利用した構成に変更した結果、期待通りの通信が可能となりました。

検証結果

閉域接続は AWS 側と OCI 側の双方で問題なく成立し、Oracle Database@AWS からのバックアップ取得も可能であることを確認しました。監視構成についても、メトリクス転送が正常に行えることを確認しています。これにより、東京リージョンでの設計においても同様の構成が適用可能であると考えています。

さらに、Data Guard による DR 構成が有効であり、フェイルオーバが可能であることを確認しました。これにより、災害対策の観点からも高い信頼性を確保できることを確認しました。

まとめ

今回の検証は、東京リージョンでの設計に向けた参考情報として、閉域接続やバックアップ構成の成立を確認することを目的としました。今後は東京リージョンでの再検証を行い、運用設計に反映していく予定です。