Amazon Web Services ブログ

Oracle Database を迅速かつ簡単に Amazon FSx for OpenZFS に同期する

このブログは 2022 年 3 月 30 日に Matt McClernon (Solutions Architect Manager) によって執筆された内容を日本語化した物です。原文はこちらを参照して下さい。

Oracle Database 環境のフリートを同期させることは、あらゆる規模の組織において大きな運用上の負担になる可能性があります。このブログ記事では、Amazon FSx for OpenZFS を使用して、複数の環境間で Oracle Database のデータを数秒でクローンすることにより、運用の複雑さを軽減して俊敏性を向上させ、コストを削減する方法について説明します。

今日の IT 運用チームは、最高レベルの可用性とレジリエンシー、パフォーマンスを維持しながら、増え続けるデータを管理するという困難な課題に直面しています。これらの課題は、エンタープライズリソースプランニング（ERP）や、カスタマーリレーションシップマネジメント（CRM）のアプリケーションスイートを利用している組織で、更に大きくなっています。これらのシステムには通常、開発、テスト、ステージング、およびその他の環境に分散された非常に大規模なデータベースのフットプリントが含まれます。

この環境のフリートを最新の状態に保つために、データベース管理者（DBA） は、本番用データベースのデータとコードを継続的に手動で同期する必要があります。Recovery Manager（RMAN）や、Data Pump などのネイティブツールを使用しても、このプロセスは時間がかかり、エラーが発生しやすく、非効率的で、生産性を損ない、ビジネスの俊敏性を低下させる可能性があります。最悪の場合、DBA は複数の異なるコピーデータを保存するために追加の容量をプロビジョニングする必要があり、大規模な分散デプロイメントではコストが 20 倍も増加します。

Amazon EC2 と Amazon FSx for OpenZFS を使用することにより、容量を追加することなく、ペタバイト規模の Oracle Database を数秒でクローンでき、分散環境全体における更新速度とリソース消費の削減が可能になります。OpenZFS のスペース効率に優れたコピーオンライトテクノロジにより、従来のデータベース重複排除では数時間から数日かかっていたデータベース同期が、FSx for OpenZFS のクローン作成ではわずか数秒に短縮されます。

この記事では、Amazon FSx for OpenZFS の機能と、Amazon EC2 上で動作する Oracle Database を組み合わせることで、データベースのクローン作成処理を高速化し、データベースフリートにコスト最適化されたストレージ基盤を提供する方法を紹介します。

ソリューション概要

Amazon FSx for OpenZFS は、OpenZFS ファイルシステム上に構築され、AWS Graviton ファミリーのプロセッサを搭載し、NFS プロトコル経由でアクセスできる、フルマネージドの共有ファイルストレージサービスです。Amazon FSx for OpenZFS は、Amazon FSx ファミリーに追加された最新の製品で、NetApp ONTAP や、Windows File Server、Lustre などの一般的なファイルシステムを搭載した、機能豊富で安全かつ高性能なファイルストレージを提供します。

Amazon FSx ファイルシステムを Oracle Database のデプロイメントに使用する方法はいくつかあります。Amazon FSx を使用すると、高可用性の Oracle Real Application Cluster（RAC）のデプロイメントにおいて、高いパフォーマンスとコスト効率の良い共有ストレージを提供することができます。また、FSx ファイルシステムを個々の Oracle Database ホストにアタッチし（このブログで実施しています）、完全に管理されたスケーラビリティと、豊富なデータ管理機能を活用できます。

Amazon FSx for OpenZFS の高速クローン作成機能を利用するためには、FSx for OpenZFS ファイルシステムのボリュームにソースデータを格納する必要があります。スペース効率の良いクローン作成を可能にする FSx for OpenZFS の機能として、スナップショットとクローンボリュームがあります。

スナップショットは、ある時点の FSx for OpenZFS ボリュームの読み取り専用イメージです。これらはファイルシステムのデータと一緒に保存され、ファイルシステムのストレージ容量を消費します。クローンボリュームは、スナップショットを使用して初期化された書き込み可能なコピーであり、初期状態では作成元のスナップショットと同じデータを含んでいます。同じスナップショットから複数のクローンボリュームを作成することができます。クローンボリュームは瞬時に作成され、クローンボリュームに変更が加えられるまでは、ストレージ容量は消費されません。これらの機能を組み合わせることで、本番データベースの同一の基礎データによる一貫性のあるポイントインタイムを、複数の非本番環境に数秒で同期させることができます。

推奨されるアーキテクチャでは、Data Guard スタンバイデータベース（本番用または既存のスタンバイから同期可能）からソースデータをレプリケートして、本番用データベースのパフォーマンスに影響を与えないようにします。シンプルかつ効率的にするために、ダウンストリームの非本番データベースは、Data Guard スタンバイソースデータベースと同じ EC2 インスタンス上で動作するように構成しています。Data Guard スタンバイデータベースと FSx for OpenZFS ファイルシステムは、最適なパフォーマンスを得るために同じ AWS アベイラビリティーゾーンに配置します。

ウォークスルー

上記のアーキテクチャ図に示したような環境を構築するために、必要となるウォークスルーの詳細な手順を説明します。この手順を実行することで、Amazon FSx for OpenZFS の機能を活用して Oracle Database のクローン作成を最適化および高速化するソリューションの基盤を構築することができます。ブログ記事の後半では、より堅牢で拡張性の高いソリューションの構築に役立つより詳細な内容をいくつか説明します。

前提条件

自身の環境で同様のデプロイメントを作成するには、次の前提条件を満たす必要があります。

実装

  1. Oracle Database の AWS クイックスタート  のデプロイ方法より、新規の VPC を使用して AWS アカウントにデプロイします。CloudFormation のスタック作成画面で、Data Guard Configuration パラメータの値として「Data Guard」を入力します。クイックスタートのデプロイは VPCStack と、BastionStack、OracleStack の 3 つの CloudFormation スタックで構成されています。3 つのフルデプロイメントには約 45 分かかります。
  1. 上記手順のクイックスタートデプロイで作成したスタンバイ EC2 インスタンスと同じアベイラビリティゾーンとサブネットに、FSx for OpenZFS ファイルシステムをプロビジョニングします。上記手順のクイックスタートデプロイでは、2 つの Oracle データベースが 2 つのアベイラビリティゾーンにそれぞれ 1 つずつ作成されます。サブネット ID は、*-OracleStack-* という名前の CloudFormation スタックの出力タブから取得することができます。
    ファイルシステムのプロビジョニングには数分かかります。完了すると、FSx コンソールから属性を確認することができます。
  1. 新しい FSx for OpenZFS ファイルシステムに関連付けられたセキュリティグループが、Oracle スタンバイデータベースに関連付けられたセキュリティグループからの NFS トラフィックを許可していることを確認します。スタンバイデータベースに関連付けられたセキュリティグループ ID は、前述の CloudFormation の出力タブ画面の StandbyInstanceID の値から EC2 インスタンス ID を確認して、EC2 コンソールでこのインスタンスのインスタンス詳細ページを開き、セキュリティタブを選択して取得します。
  1. スタンバイデータベースをホストする EC2 インスタンスに、新しい OpenZFS ファイルシステムをマウントします。FSx for OpenZFS コンソールでボリュームを選択し、右上のアタッチを選択すると、NFS マウントのコマンドが表示されます。

    表示された NFS マウントコマンドのオプションは、NFS を介した汎用的なファイルアクセスに適していますが、Oracle では、データベースのバージョンやファイルの種類によって異なるいくつかの特定マウントオプションを推奨しています。Oracle データファイルに必要な明示的な NFS マウントオプションについては、My Oracleサポートノートの「1567137.1」および「359515.1」をご確認ください。FSx for OpenZFS ボリュームのアタッチで表示された NFS マウントコマンドのオプションと、 My Oracle サポートノートで推奨されているマウントオプションを使用して、スタンバイデータベースの EC2 インスタンスにファイルシステムをマウントします。
  1. プライマリデータベースから新しい Data Guard スタンバイデータベースを作成し、マウントされた OpenZFS ファイルシステムにそのデータファイルを格納します（または、既存のスタンバイからカスケードします）。ダウンストリームのデータベースクローンのソースとして機能する OpenZFS ベースの新しいスタンバイデータベースを作成する最も効率的な方法は、Oracle RMAN Duplicate from Active Database 手法を使用することです。これにより、稼働中のプライマリデータベースをスタンバイ EC2 インスタンスにコピーし、データファイルを FSx for OpenZFS ボリュームに書き込むという作業を 1 ステップで行うことができます。このユースケースの重要な呼び出しは、RMAN Duplicate スクリプトで db_file_name_convert SPFILE パラメータを使用して、データファイルの場所を FSx for OpenZFS ファイルシステムに確実に変換することです。
  1. プライマリデータベースと、OpenZFS ボリュームを使用しているスタンバイデータベースが同期していることを確認します。これは、SQLPLUS を使用して Data Guard ビュー V$DATAGUARD_PROCESS にクエリすることで確認できます。
  1. クローンを作成する各非本番環境で以下の操作を実施してください。
    • OpenZFS ベースのソーススタンバイデータベースで、Data Guard のマネージドリカバリーを一時的に停止します。
      SQLPLUS> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
    • AWS FSx コンソールを使用して、FSx for OpenZFS ソースボリュームのスナップショットを取得します。
    • ソーススタンバイデータベースで、Data Guard のマネージドリカバリーを再有効化します。
      SQLPLUS> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT
    • 上記の手順で取得したスナップショットを使用して、FSx for OpenZFS のクローンボリュームを作成します。
    • 上記の手順で作成したクローンボリュームをスタンバイ EC2 インスタンスにマウントします（ユニークなマウントパスを使用）。上記ステップで作成したクローンボリュームは、クローンを作成するダウンストリームの非本番環境専用となります。そのため、対象環境（開発、テスト、ステージング）に特化したマウントポイントへマウントする必要があります。スタンバイ EC2 インスタンスのマウントパスに意味のある名前を付与して、FSx for OpenZFS のコンソールからクローンボリュームの DNS 名を指定して、上記手順と同じ NFS マウントオプションでクローンボリュームをマウントしてください。
    • 新しいクローンボリューム内のデータベース名を、非本番環境の名前（Dev、Test、Staging）に変更します。この最後の手順は、クローン ボリュームに保存されたデータベース名を、ターゲット環境名（開発、テスト、ステージングなど）に合わせて変更するために必要です。クローンボリュームには最初、ソース（本番環境）上で表示されるのと同じスタンバイデータファイルのコピーが含まれるためです。そして、クローンボリュームに格納されている FSx for OpenZFS ファイルシステムのサブディレクトリ名を Linux シェルから mv で変更し、以下コマンドでデータベース制御ファイルを再作成します。
      CREATE CONTROLFILE SET DATABASE "<Dev|Test|Staging>" RESETLOGS

堅牢なソリューション構築

上記の手順は、スペース効率に優れたデータベースクローン作成の基礎を築くのに役立ちます。このセクションでは、その基礎の上に堅牢で保守が容易なソリューションを構築するための、いくつかの追加検討事項を紹介します。

クローンのソース

スペース効率に優れた OpenZFS のスナップショットとクローン技術を活用するには、ソースとなる Oracle Database のデータファイルを、NFS 経由でマウントされた FSx for OpenZFS ボリュームに保存する必要があります。お客様は一般的に、最新のデータとコードの変更をすべて取り込み、新しい製品、機能、および統合をテストし、ステージングするための優れたベースラインを提供するために、本番環境の最近のコピーから非本番データベースを更新する必要があります。したがって、本番環境のプライマリデータベースをソースとして選択するのは自然なことです。多くのお客様は、ディザスタリカバリ保護のために Data Guard スタンバイデータベースをすでに導入しており、バックアップとレポート作成をオフロードすることによって、本番システムのメンテナンスへの影響を最小限に抑えています。この場合に推奨されるアプローチは、クローンを作成する必要があるすべてのダウンストリームの非運用データベースのソースとして、専用の Data Guard スタンバイデータベースを使用することです。プライマリと直接同期させるか、既存のスタンバイからカスケード接続することができます。スタンバイをソースにすることの利点は、REDO の適用を一時的に無効にしてデータベースを静止化させ、複製ボリュームのベースラインとして機能する一貫したポイントインタイム スナップショットを提供できる点です。これにより、データベースのリフレッシュ時にクローン化したデータベース名を変更する手順も簡略化できます。

OpenZFS スナップショットおよびクローンボリュームの管理

スナップショットとクローンボリュームを組み合わせることで、最適化されたデータクローン作成の基盤を実現します。単一のソースから複数のスナップショットとクローンボリュームを作成することで、処理のオーバーヘッドと影響を最小限に抑えながら、大規模なデータセットのコピーを高速かつスペース効率よく作成することができます。コピーオンライトにより、スナップショットのストレージ消費量はソースデータベースサイズの単純な倍数ではなく、変更した量の係数となります。

高レベルの効率性と速度を実現するために、クローンボリュームはソーススナップショットへの依存性を保持します。つまり、依存性のあるクローンボリュームが使用されている間は、ソーススナップショットを削除することができません。非本番データベースの有効期限が長く、大幅な変更が行われる場合は、そのクローンボリュームをソーススナップショットから分割し、依存関係を削除することを選択できます。依存関係を削除するためには、クローンから独立した書き込み可能なコピーである新しい完全コピーボリュームを作成する必要があります。完全コピーボリュームは完全に独立しており、ソーススナップショットの全てのデータを含みます。

ソースボリュームとクローンボリュームの両方に変更が加えられるにつれ、ストレージ容量の消費量が増加します。このため、ファイルシステムのストレージ消費量を注意深く監視する必要があります。また、定期的に未使用のスナップショットやクローンボリュームを削除して、容量を解放することもお勧めします。

Oracle Database 名の変更

クローン作成プロセスの最後に行うデータベース名の変更は、データベース制御ファイルを再作成するため、破壊的な操作となります。非本番データベースを、ソースのスタンバイデータベースと同じ EC2 インスタンスで実行している場合は、クローンボリューム上のファイルシステムのみ変更し、ソースボリューム上のファイルシステムは変更しないように、特別な注意が必要です。スタンバイデータベースのソースとダウンストリームの非本稼働ターゲットを別々の EC2 インスタンスに分割することで、より高い保護機能を実現することができます。別々の EC2 インスタンスに分割するかどうかは、Oracleのライセンス権利に依存します。

クリーンアップ

このウォークスルーでデプロイした AWS リソースの使用が終了した後に、削除を実施することで更なる課金を回避できます。

Oracle Database の AWS クイックスタートを使用して Oracle 関連のインフラリソースをデプロイした場合、まず QuickStart CloudFormation テンプレートで作成された VPC 内の FSx for OpenZFS 関連リソースを削除する必要があります。代わりに別の VPC に FSx for OpenZFS コンポーネントを作成した場合は、FSx for OpenZFS リソースを保持するか、Oracle Database の QuickStart リソースを削除した後に FSx for OpenZFS リソースを削除することが可能です。

Oracle Database の QuickStart リソースを削除するには、デプロイしたリージョンで、関連する CloudFormation スタックを削除してください。

まとめ

このブログでは、Amazon FSx for OpenZFS の機能を活用して、Oracle Database のクローン作成手順を最適化および高速化するソリューションの基盤の構築と、さらに堅牢で拡張性の高いソリューションの構築を支援する方法について説明しました。FSx for OpenZFS で利用できるスペース効率の高いスナップショットとクローンボリュームのパワーを活用することで、運用チームは、ストレージコストを最小限に抑えながら、本番の Oracle Database から大量のダウンストリームデータベースを定期的にクローン作成することで、競合する複数のデータベース利用者の要求を満たすという負担を軽減することができます。

FSx for OpenZFS は、Amazon FSx ファミリーのファイルストレージ製品で利用できるオプションの一つに過ぎません。Oracle Database を実行しているお客様は、FSx for Netapp ONTAP にデータファイルを保存して、シンプロビジョニング、レプリケーション（SnapMirror）、ポイントインタイムクローン作成（FlexClone）を利用することも可能です。例えば、FSx for NetApp ONTAP FlexClone でも、同じようにスペース効率に優れた高速なクローン作成を実現することもできます。

このブログ記事では、Oracle Database の高速なクローン作成に焦点を当てましたが、FSx for OpenZFS の機能を活用することで、効率的なストレージ管理を実現できる別のユースケースも数多く存在します。ここでは、このマネージドサービスの将来的な利用方法について、いくつか提案します。

翻訳はプロフェッショナルサービス本部の葉山が担当しました。