Oracle Cloud InfrastructureでのPeopleSoftのデプロイについて

Oracle Cloud InfrastructureでOracleのPeopleSoftアプリケーションをプロビジョニングするか、データ・センターからOracle Cloud InfrastructureにPeopleSoft環境を移行する場合、複数ホストのセキュアな高可用性トポロジを計画できます。

Oracle Cloud Infrastructureでのデプロイの考慮事項

Oracleでは、異なるサブネット間で適切なセキュリティ要件を実装できるように、ベース・ホスト、データベース、アプリケーションおよびロード・バランサ・インスタンスなどのインスタンスに個別のサブネットを作成することをお薦めします。

プライベートまたはパブリック・サブネット

インターネットのインスタンスへのアクセスを許可するかどうかに応じて、プライベートまたはパブリック・サブネットにインスタンスを作成できます。パブリック・サブネットで作成したインスタンスにはパブリックIPアドレスが割り当てられ、インターネットからこれらのインスタンスにアクセスできます。プライベート・サブネットで作成されたインスタンスにパブリックIPアドレスを割り当てることはできません。したがって、インターネットを介してこれらのインスタンスにアクセスすることはできません。

次のイメージは、パブリックおよびプライベート・サブネットを持つ仮想クラウド・ネットワーク(VCN)を示します。VCNには2つの可用性ドメインがあり、各可用性ドメインにはパブリック・サブセットとプライベート・サブセットがあります。Webサーバーはこのイメージのパブリック・サブネットに配置されるため、Webサーバー・インスタンスにはパブリックIPアドレスがアタッチされます。インターネット・ゲートウェイ(Iw)を介して通信を有効にすることで、パブリック・サブネット内のこれらのOracle Cloudインスタンスにインターネットからアクセスできます。トリガーとの間のトラフィックを有効にするには、ルート表を更新する必要があります。インターネットからのWebサーバーへのトラフィックを許可するには、パブリック・サブネットにロード・バランサを作成する必要があります。インターネットからインスタンスにアクセスするには、パブリック・サブネットにベース・ホストを作成し、Iwからベース・ホストにアクセスする必要もあります。

データベース・サーバーは、このイメージのプライベート・サブネットに配置されます。データ・センターからプライベート・サブネット内のOracle Cloudインスタンスにアクセスするには、動的ルーティング・ゲートウェイ(DRG)を介して接続します。DRGは、オンプレミス・ネットワークとクラウド・ネットワークを接続するゲートウェイです。DRGと顧客の機器間の通信を可能にするには、IPSec VPNまたはOracle Cloud Infrastructure FastConnectを使用します。DRGとの間でトラフィックを有効にするには、ルート表を更新する必要もあります。

図public_private_subnets_jde.pngの説明

シナリオ1:すべてのインスタンスをプライベート・サブネットでデプロイ

Oracleは、内部向けのエンドポイントがない本番環境用のすべてのインスタンスをプライベート・サブネットにデプロイすることをお薦めします。このタイプのデプロイメントは、既存のデータ・センターの拡張機能として、クラウドとのハイブリッドなデプロイメントを行う場合に便利です。

このデプロイメントでは、アプリケーションおよびデータベース・サーバーを含むすべてのインスタンスがプライベート・サブネットにデプロイされます。パブリックIPアドレスはプライベート・サブネットに作成されたインスタンスに割り当てることができないため、インターネットを介してこれらのインスタンスにアクセスすることはできません。この構成のオンプレミス環境からアプリケーション・サーバーにアクセスするには、次の操作を実行します。

アプリケーション・サーバーをプロビジョニングする前に、データ・センターとOracle Cloud Infrastructure DRGの間にIPSec VPNトンネルを構成します。
この構成にベース・ホストを作成し、ベース・ホストからプライベート・サブネット内のすべてのサーバーにアクセスします。

シナリオ2:パブリック・サブネットおよびプライベート・サブネットでのインスタンスのデプロイ

パブリック・サブネット内のインスタンスはいくつか、プライベート・サブネット内のインスタンスはいくつかデプロイできます。このタイプのデプロイメントは、対話型および非対話型のエンドポイントがデプロイメントに含まれている場合に便利です。

この構成では、一部のアプリケーション・インスタンスはパブリック・サブネットに配置され、その他のアプリケーション・インスタンスはプライベート・サブネットに配置されます。たとえば、内部ユーザーにサービスを提供するアプリケーション・インスタンスと、外部ユーザーをサービスする別のアプリケーション・インスタンスのセットがあるとします。このシナリオでは、内部トラフィックを処理するアプリケーション・インスタンスをプライベート・サブネットに配置し、パブリック・サブネットの外部トラフィックを提供するアプリケーション・サーバーを配置します。また、パブリック・サブネットの外部トラフィックを処理するアプリケーション・サーバーを配置するのではなく、中間アプリケーション・インスタンスにパブリック・ロード・バランサを設定することもできます。ベース・ホストをパブリック・サブネットに配置した場合、ベース・ホストにはパブリックIPアドレスが割り当てられ、インターネットを介してアクセスできます。プライベート・サブネット内のインスタンスには、ベース・サーバーを介してアクセスできます。

シナリオ3:パブリック・サブネットのすべてのインスタンスのデプロイ

Oracleでは、クイック・デモンストレーション、または内部エンドポイントがない生産的な等級デプロイメントにこのデプロイメントをお薦めします。このデプロイメントは、独自のデータ・センターがない場合、またはVPN経由でインスタンスにアクセスできず、インターネット経由でインフラストラクチャにアクセスする場合にのみ適しています。

このデプロイメントでは、アプリケーションとデータベース・インスタンスを含むすべてのインスタンスが、パブリック・サブネットにデプロイされます。

パブリック・サブネットのすべてのインスタンスには、パブリックIPアドレスがアタッチされています。パブリックIPアドレスを持つインスタンスはインターネット経由でアクセスできますが、セキュリティ・リストとセキュリティ・ルールを使用することでアクセスを制限できます。管理タスクを実行するために、Oracleでは、ベース・ホストをこの構成に配置することをお薦めします。このシナリオでは、管理ポートをパブリック・インターネットには開きませんが、ベース・ホストのみに管理ポートを開き、ベース・ホストからのみインスタンスにアクセスできるようにセキュリティ・リストおよびセキュリティ・ルールを設定します。

アンチアフィニティ

Oracle Cloud Infrastructureの可用性ドメインで高可用性を実現するために複数のインスタンスを作成しますが、フォルト・ドメインを使用することでインスタンスのアンチアフィニティを実現できます。

フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャをグループ化したものです。各可用性ドメインには3つのフォルト・ドメインがあります。フォルト・ドメインを使用すると、インスタンスを1つの可用性ドメイン内の同じ物理ハードウェア上に配置しないようにできます。そのため、1つのフォルト・ドメインに影響するハードウェア障害またはOracle Computeハードウェア・メンテナンスは、他のフォルト・ドメイン内のインスタンスには影響しません。障害ドメインを使用することで、インスタンスを予期しないハードウェア障害や計画済の停止から保護できます。

データベースの高可用性を実現するために、2ノードのOracle Real Application Clusters (Oracle RAC)データベース・システムを作成できます。Oracle RACの2つのノードは、デフォルトでは常に別のフォルト・ドメインに作成されます。そのため、データベース・ノードは同じ物理ホスト上でも同じ物理ラック上にもありません。これにより、基礎となる物理ホストやラック・スイッチの障害上位からデータベース・インスタンスが保護されます。

アーキテクチャ

PeopleSoftのこれらのデプロイメント・オプションの計画に使用できる主要な概念について説明します。

高可用性を実現する一方で、PeopleSoftを単一の可用性ドメインにデプロイするアーキテクチャ。このアーキテクチャは、アプリケーション・インスタンスが停止しても、アプリケーションが使用可能なことを確認する場合に使用します。可用性ドメインの他の使用可能なアプリケーション・インスタンスは、リクエストの処理を続行します。
高可用性を確保しながら、複数の可用性ドメインにPeopleSoftをデプロイするためのアーキテクチャ。このアーキテクチャは、1つの可用性ドメインが停止してもアプリケーションが使用可能なことを確認する場合に使用します。別の可用性ドメインのアプリケーション・インスタンスに引き続きアクセスできます。
高可用性および障害時リカバリを実現する一方で、PeopleSoftをデプロイするためのアーキテクチャ。このアーキテクチャは、アプリケーションの障害時リカバリ・サイトを異なるリージョンに設定する場合に使用します。

このアーキテクチャは、手動で実行されるPeopleSoftデプロイメント、またはOracle Cloud InfrastructureのPeopleSoft自動化ツールを使用することで有効です。

インターネット経由でデータベースおよびアプリケーション・ホストにアクセスしないことを考慮して、すべてのアーキテクチャ・ダイアグラムをお薦めします。

単一の可用性ドメインにPeopleSoftをデプロイするためのアーキテクチャ

このアーキテクチャは、高可用性を確保しながら、単一の可用性ドメインでのPeopleSoftアプリケーションのデプロイメントを示します。

アーキテクチャは、VCNとは、単一の可用性ドメイン内のVCNの個別サブネットに配置されているベース、ロード・バランサ、アプリケーションおよびデータベース・ホストで構成されます。ベース・ホストはパブリック・サブネットにデプロイされ、他のすべてのインスタンスはプライベート・サブネットにデプロイされます。ビジネス要件に基づいて、異なるインスタンスをパブリックまたはプライベート・サブネットに配置できます。専用サブネット内のインスタンスには、ポート22で「bastion」ホストを介してアクセスできます。また、データ・センターとOracle Cloud Infrastructure DRG間にIPSec VPNトンネルを設定してある場合は、DRGにアクセスできます。

このアーキテクチャでは、冗長インスタンスがアプリケーション層およびデータベース層にデプロイされ、可用性ドメイン内で高可用性が確保されます。これにより、アプリケーション・インスタンスが停止しても、アプリケーションが使用可能なことが保証されます。可用性ドメインの他の使用可能なアプリケーション・インスタンスは、リクエストの処理を続行します。可用性ドメイン内のすべてのアプリケーション・インスタンスがアクティブです。ロード・バランサ・インスタンスは、リクエストを受信し、アプリケーション・サーバーに送信します。可用性ドメイン内のアプリケーションのこの高可用性は、アプリケーション・インスタンスを別のフォルト・ドメインに配置することで実現できます。フォルト・ドメインを使用すると、インスタンスを1つの可用性ドメイン内の同じ物理ハードウェア上に配置しないようにできます。そのため、1つのフォルト・ドメインに影響するハードウェア障害またはハードウェア・メンテナンスは、他のフォルト・ドメインのインスタンスには影響しません。

プライベート・サブネットのインスタンスは、パッチをダウンロードし、オペレーティング・システムおよびアプリケーションの更新を適用するためにインターネットへのアウトバウンド接続を必要とします。そのためには、VCNでネットワーク・アドレス変換(NAT)ゲートウェイを使用します。NATゲートウェイでは、プライベート・サブネットのホストはインターネットへの接続を開始してレスポンスを受信できますが、インターネットから開始されたインバウンド接続を受信できません。

Oracleは、Oracle Cloud Infrastructureにデプロイされたデータベースとアプリケーションがリカバリ計画の堅牢なバックアップを保持することをお薦めします。データベースおよびアプリケーション・インスタンスのバックアップをOracle Cloud Infrastructure Object Storageに格納することをお薦めします。プライベート・サブネット内のデータベースおよびアプリケーション・インスタンスは、サービス・ゲートウェイを使用してOracle Cloud Infrastructure Object Storageにバックアップできます。サービス・ゲートウェイは、インターネットを通過せずにOracle Cloud Infrastructure Object Storageにアクセスできます。

Oracle Cloud Infrastructure Object Storageへの自動およびオンデマンド・データベース・バックアップは、Oracle Cloud Infrastructureコンソールを使用して構成できます。これには、Swiftエンドポイントを使用してOracle Cloud Infrastructure Object Storageに接続する必要があります。Oracle Cloud Infrastructure Object Storage上のすべてのデータベース・バックアップは、Transparent Data Encryption (TDE)ウォレット暗号化と同じマスター・キーで暗号化されます。自動データベース・バックアップ・サービスでは、週次増分バックアップ計画を使用して、30日間の保存ポリシーでデータベースをバックアップします。必要に応じて、データベースのオンデマンド・フル・バックアップを実行することもできます。

アプリケーションのバックアップは、Oracle Cloud Infrastructure Block Volumesのポリシーベースのバックアップ機能を使用して構成できます。Oracle Cloud Infrastructure Block Volumesでは、スケジュールに基づいてボリューム・バックアップを自動的に実行し、選択したバックアップ・ポリシーに基づいて保存する機能が提供されます。これにより、データのコンプライアンス要件および規制要件に準拠できます。3つの事前定義済バックアップ・ポリシー(Bronze、SilverおよびGold)があります。各バックアップ・ポリシーには、事前定義済のバックアップ頻度と保存期間が設定されています。

Peoplesoft_single_availability_domain_ha_topology.pngの説明が続きます

図peoplesoft_single_availability_domain_ha_topology.pngの説明

このアーキテクチャは、次の層に分かれています。

バス・ホスト:ベース・ホストはオプションのコンポーネントであり、プライベート・サブネットのインスタンスにアクセスするためのジャンプ・サーバーとして使用できます。
Load Balancer層:この層には、PeopleSoft Webサーバーにトラフィックをロード・バランシングするOracle Cloud Infrastructure Load Balancingインスタンスが含まれています。ロード・バランサはユーザーからリクエストを受信し、それらのリクエストをアプリケーション層にルーティングします。
アプリケーション層:この層には、高可用性を提供するために、PeopleSoftアプリケーション・サーバー、PeopleSoft Webサーバー、ElasticSearchサーバーおよびPeopleSoft Process Schedulerの冗長インスタンスが含まれています。インスタンスが停止した場合でもアプリケーションへのアクセスを続行できるように、アプリケーション層内のすべてのサーバーの冗長インスタンスを設定します。
PeopleToolsクライアント: PeopleToolsクライアントを使用して、開発、移行、アップグレードなどの管理アクティビティを実行します。
データベース層:この層には、Oracle Cloud Infrastructureデータベース・システム・インスタンスが含まれます。高可用性の要件として、Oracleでは、2ノードのOracle Real Application Clusters (Oracle RAC)データベース・システムまたはOracle Cloud InfrastructureのOracle Database Exadata Cloud Serviceシステムを使用することをお薦めします。

複数の可用性ドメインにPeopleSoftをデプロイするアーキテクチャ

このアーキテクチャは、複数の可用性ドメインでのPeopleSoftアプリケーション・サーバーのデプロイメントを示します。2つの可用性ドメインにわたって個別のサブネットに配置されているベース、ロード・バランサ、アプリケーションおよびデータベース・ホストを持つVCNを示しています。

アーキテクチャ・ダイアグラムでは、ベース・ホストがパブリック・サブネットにデプロイされ、他のすべてのインスタンスはプライベート・サブネットにデプロイされます。ビジネス要件に基づいて、パブリック・サブネットまたはプライベート・サブネットにインスタンスを配置できます。専用サブネット内のインスタンスには、ポート22で「bastion」ホストを介してアクセスできます。また、データ・センターとOracle Cloud Infrastructure DRG間にIPSec VPNトンネルを設定してある場合は、DRGにアクセスできます。すべてのインスタンスが2つの可用性ドメインでアクティブです。アーキテクチャ内のパッシブ・コンポーネントは、可用性ドメイン2のデータベース・ホストのみです。

可用性ドメイン1および可用性ドメイン2の基本ホストはアクティブであり、常に両方の可用性ドメインのインスタンスに対してSSHリクエストを提供できます。オンプレミスのDNSまたは外部のDNSサービスは、PeopleSoftアプリケーションの要求を受け取ります。これらのリクエストは、可用性ドメイン1または2のロード・バランサのいずれかにラウンドロビン負荷分散されます。その後、ロード・バランサによって、可用性ドメイン1または2の基礎となるPeopleSoft Webサーバーの1つにリクエストがルーティングされます。その後、PeopleSoft WebサーバーによってリクエストがPeopleSoftアプリケーション・サーバーの1つにルーティングされ、最終的にアプリケーション・サーバーは、リクエストを可用性ドメイン1のアクティブなデータベース・インスタンスに転送して処理されます。

可用性ドメイン1が使用可能でない場合は、可用性ドメイン1ロード・バランサのエントリをDNSサービスから手動で削除し、データベースを可用性ドメイン2のデータベース・インスタンスに切り替える必要があります。DNSサービスから受信したリクエストは、可用性ドメイン2のロード・バランサにルーティングされ、最終的に可用性ドメイン2のデータベースにルーティングされて処理されます。

Peoplesoft_multiple_availability_domain_ha_topology.pngの説明が続きます

図peoplesoft_multiple_availability_domain_ha_topology.pngの説明

基礎ホスト:ベース・ホストはオプションのコンポーネントであり、アプリケーションおよびデータベースのインスタンスにアクセスするためのジャンプ・ホストとして機能する各可用性ドメインでプロビジョニングできます。可用性ドメイン1と可用性ドメイン2の両方の基本ホストがアクティブな状態です。
ロード・バランサ・インスタンス: Oracle Cloud Infrastructure Load Balancingインスタンスは、両方の可用性ドメインのアプリケーション・サーバー間でトラフィックを分散します。可用性ドメイン1と2の両方のロード・バランサ・インスタンスがアクティブです。PeopleSoft URLで受信したリクエストは、可用性ドメイン1のロード・バランサにラウンド・ロビン・ロード・バランシングされ、オンプレミスまたは外部のDNSサービスによって2にロードされます。
アプリケーション層:可用性ドメイン1と可用性ドメイン2の両方に、PeopleSoftアプリケーション・サーバー、PeopleSoft Webサーバー、ElasticSearchサーバーおよびPeopleSoft Process Schedulerの冗長インスタンスが含まれています。2つの可用性ドメインにまたがるアプリケーション層のすべてのインスタンスは、アクティブ状態です。
PeopleToolsクライアント: PeopleToolsクライアントを使用して、開発、移行、アップグレードなどの管理アクティビティを実行します。
データベース層:両方の可用性ドメインで可用性の高いデータベース・インスタンスを構成します。可用性ドメイン1は、プライマリ・データベースのインスタンスをホストします。可用性ドメイン2はスタンバイ・データベース・インスタンスをホストします。各可用性ドメインで、高可用性を保証するために2つ以上のデータベース・インスタンスが設定されています。データベース・インスタンスが可用性ドメイン1で使用できない場合、可用性ドメイン1の2番目のデータベース・インスタンスはリクエストの処理を続行します。

同期モードでOracle Active Data Guardを使用して、リージョン内の可用性ドメイン間でデータベースをレプリケートします。

複数のリージョンにまたがるPeopleSoftのデプロイのアーキテクチャ

このアーキテクチャでは、高可用性および障害時リカバリを保証する一方で、複数のリージョンにわたるPeopleSoftアプリケーション・サーバーのデプロイメントが示されています。これは、2つのリージョンにわたって、異なるサブネットに配置されているベース、ロード・バランサ、アプリケーションおよびデータベース・インスタンスを持つVCNを示しています。リージョン内のすべての可用性ドメインが停止した場合でも、PeopleSoftアプリケーション・インスタンスへのアクセスを可能にするために、複数のリージョンにPeopleSoftをデプロイします。

アーキテクチャ・ダイアグラムは、2つのリージョンを示しています。リージョン1では、リージョン内の複数の可用性ドメイン間で高可用性を確保するために、PeopleSoftは複数の可用性ドメインにデプロイされます。リージョン2は、障害時リカバリ領域です。すべてのインスタンスは、リージョン1の2つの可用性ドメインでアクティブです。アーキテクチャのパッシブ・コンポーネントは、可用性ドメイン2のデータベース・ホストとリージョン2のすべてのインスタンスです。Oracleでは、リージョン2の可用性ドメイン内の各層にデプロイするインスタンス数は、リージョン1の可用性ドメインにデプロイされるインスタンス数と同じにする必要があります。これにより、障害時リカバリの起動後に、アプリケーション・インスタンスがロード全体を占有することができます。

このアーキテクチャは、リージョン1の1つの可用性ドメインと、障害時リカバリのリージョン2の1つの可用性ドメインにのみデプロイすることもできます。ただし、このアーキテクチャでは、リージョン1の可用性ドメインのフォルト・トレランスは提供されません。アプリケーションがデプロイされている可用性ドメインのみが使用可能でない場合は、アプリケーションをリージョン2にフェイルオーバーするために障害時リカバリを起動する必要があります。

リージョン1では、可用性ドメイン1および可用性ドメイン2の基本ホストがアクティブであり、常に両方の可用性ドメインのインスタンスに対してSSHリクエストを提供できます。オンプレミスのDNSまたは外部のDNSサービスは、PeopleSoftアプリケーションの要求を受け取ります。これらのリクエストは、可用性ドメイン1または2のロード・バランサのいずれかにラウンドロビン負荷分散されます。その後、ロード・バランサによって、可用性ドメイン1または2の基礎となるPeopleSoft Webサーバーの1つにリクエストがルーティングされます。その後、PeopleSoft WebサーバーによってリクエストがPeopleSoftアプリケーション・サーバーの1つにルーティングされ、最終的にアプリケーション・サーバーは、リクエストを可用性ドメイン1のアクティブなデータベース・インスタンスに転送して処理されます。

リージョン1のインスタンスが使用可能でない場合は、リージョン2のインスタンスに手動で切り替える必要があります。このシナリオでは、リージョン2のロード・バランサおよびデータベース・インスタンスが、プライマリのロード・バランサおよびデータベース・インスタンスとして機能します。PeopleSoft URLで受信したリクエストはリージョン2のロード・バランサにルーティングされ、そこでリージョン2の基礎となるPeopleSoft Webサーバーにトラフィックがルーティングされます。PeopleSoft WebサーバーはリクエストをPeopleSoftアプリケーション・インスタンスにルーティングし、PeopleSoftアプリケーション・サーバーはリクエストをリージョン2のデータベース・インスタンスに転送して処理します。

アーキテクチャ・ダイアグラムでは、ベース・ホストおよびロード・バランサがパブリック・サブネットにデプロイされ、他のすべてのインスタンスはプライベート・サブネットにデプロイされます。ビジネス要件に基づいて、パブリック・サブネットまたはプライベート・サブネットにインスタンスを配置できます。専用サブネット内のインスタンスには、ポート22で「bastion」ホストを介してアクセスできます。また、データ・センターとOracle Cloud Infrastructure DRG間にIPSec VPNトンネルを設定してある場合は、DRGにアクセスできます。

Peoplesoft_multiple_regions_ha_topology.pngの説明が続きます

図peoplesoft_multiple_regions_ha_topology.pngの説明

このアーキテクチャは、次のコンポーネントをサポートします。

基礎ホスト:ベース・ホストはオプションのコンポーネントであり、アプリケーションおよびデータベースのインスタンスにアクセスするためのジャンプ・ホストとして機能する各可用性ドメインでプロビジョニングできます。可用性ドメイン1と可用性ドメイン2の両方の基本ホストがアクティブな状態です。
ロード・バランサ・インスタンス: Oracle Cloud Infrastructure Load Balancingインスタンスは、両方の可用性ドメインにあるアプリケーション・サーバー間でトラフィックを分散します。リージョン1の可用性ドメイン1および2は、プライマリ・インロード・バランサ・インスタンスをホストします。
アプリケーション層:リージョン1の可用性ドメイン1と可用性ドメイン2には、PeopleSoftアプリケーション・サーバー、PeopleSoft Webサーバー、ElasticSearchサーバーおよびPeopleSoft Process Schedulerの少なくとも1つのインスタンスが含まれています。リージョン1にある2つの可用性ドメイン内のすべてのインスタンスがアクティブな状態にある。リージョン2のアプリケーション層インスタンスはパッシブ状態です。複数の可用性ドメイン間およびリージョン間でアプリケーション・サーバーを同期するには、rsyncを使用します。
PeopleToolsクライアント: PeopleToolsクライアントを使用して、開発、移行、アップグレードなどの管理アクティビティを実行します。
データベース層:リージョン1の可用性ドメイン1はプライマリ・データベース・インスタンスをホストします。スタンバイ・データベース・インスタンスは、リージョン1およびリージョン2の可用性ドメイン2にホストされています。各可用性ドメインで、高可用性を保証するために2つ以上のデータベース・インスタンスが設定されています。データベース・インスタンスが可用性ドメイン1で停止した場合は、可用性ドメイン1の2番目のデータベース・インスタンスがリクエストの処理を続行します。リージョン1が使用できない場合、リージョン2のデータベース・インスタンスはリクエストを処理します。

Oracleでは、Oracle Active Data Guardを同期モードで使用してリージョン内の可用性ドメイン全体でデータベースをレプリケートすることをお薦めします。複数のリージョンにまたがってデータベースをレプリケートするには、非同期モードでOracle Active Data Guardを使用します。