構成の計画

セカンダリ・システムを作成する前に、Oracle Cloud Infrastructureでプライマリ・システムのリソースと構成を計画します。

スナップショット・スタンバイまたはリモート・リフレッシュ可能クローンの選択

次の内容を確認して、スナップショット・スタンバイ・クローンまたはリモート・リフレッシュ可能クローンを使用するかどうかを確認します。

ノート:

リモート・リフレッシュ可能クローンは、Oracle Autonomous Database Serverlessでのみ使用できます。

Oracle Autonomous Database on Dedicated Exadata Infrastructureを使用している場合は、設定およびライフサイクルにスナップショット・スタンバイ機能を使用します。Oracle Autonomous Database on Dedicated Exadata Infrastructureには、リモート・リフレッシュ可能クローン機能は実装されていません。

Oracle Autonomous Database Serverlessを使用している場合は、設定およびライフサイクルにリモート・リフレッシュ可能クローンまたはスナップショット・スタンバイ機能を使用できます。次のことを考慮して決定します。

スナップショット・スタンバイ

長所:
- 設定およびライフサイクル操作が容易です。スタンバイをスナップショットに変換する場合、またはフィジカル・スタンバイに戻す場合、セカンダリでウォレットを変更する必要はありません。
- スナップショット・スタンバイには、スタンバイ・リージョンに追加のデータベースは必要ありません。スタンバイ・データベースのみが存在し、スナップショットに変換してフィジカル・スタンバイに戻すことができます。
- スナップショット・スタンバイのスタンバイを使用してセカンダリを検証する場合、実際にはスイッチオーバーの場合に使用するものと同じ自律型データベースを使用しています。そのため、スイッチオーバー時に使用するウォレットと同じウォレットを使用しているため、接続性に関して検証がより現実的です。
短所:
- スタンバイ・データベースがスナップショット・スタンバイ・モードの場合、スタンバイ・データベースはプライマリからredoを受信しますが、適用しません。セカンダリをテストしている間に緊急フェイルオーバーまたはスイッチオーバーを実行する必要がある場合は、プライマリと同期するように、まずフィジカル・スタンバイに変換する必要があります。これにより、スイッチオーバー時間が若干遅れる可能性があります。

リモート・リフレッシュ可能クローン

長所:
- リモート・リフレッシュ可能クローンは、個別の自律型データベースです。スタンバイ中間層を設定するとき、またはライフサイクル中にセカンダリをテストするときに、スタンバイ・データベースと直接対話することはありません。
短所:
- 別の自律型データベースであるため、追加の自律型データベース・インスタンスとして請求されます。
- 設定およびライフサイクル操作はより複雑です。ウォレットは、実際のスタンバイ・データベースとリモートのリモート・リフレッシュ可能クローンの間で、1つまたはもう1つを指すように毎回切り替える必要があります。

どちらか一方のアプローチを選択しても、システムの耐用期間全体にわたって同じアプローチを使用することが強制されるわけではありません。適切な手順を使用しているかぎり、障害回復の設定に使用するアプローチからライフサイクル中に別のアプローチを使用できます。一部の操作のスナップショット・スタンバイを、他のテスト用のリフレッシュ可能なクローンと組み合せることもできます。たとえば、セカンダリでのプロビジョニングおよびワークロード検証にはスナップショットを使用しますが、システムの負荷が高いときに、スパース・テストにはリフレッシュ可能なクローンを使用します。この方法で、スナップショットからフィジカル・スタンバイへの変換で大規模なredo applyによって発生するオーバーヘッド(および発生する可能性のあるスイッチオーバー遅延)を回避できます。

プライマリ・システムの考慮事項

プライマリOracle WebLogic Server for Oracle Cloud Infrastructure、Oracle SOA Suite on MarketplaceまたはOracle Fusion Middlewareシステムが作成され、Oracle Autonomous Databaseサービスを使用していることを前提としています。Oracle Cloud Infrastructure (OCI)にセカンダリ・システムを実装する予定の場合は、プライマリ・システムの次の考慮事項を確認してください:

プライベート・サブネット
Oracle Autonomous DatabaseとOracle SOA Suite on Marketplaceの両方がプライベート・サブネットに配置されます。
Oracle Autonomous Database Serverlessを使用する場合のプライベート・エンドポイント
Oracle Autonomous Database Serverlessシステムは、プライベート・エンドポイント(PEP)を介して公開されます。
Oracle Cloud Infrastructure Load Balancing
フロント・エンドのOCI Load Balancerによって、OCI用のOracle WebLogic Server、Oracle SOA Suite on MarketplaceまたはOracle Fusion Middlewareシステムが公開されます。

OCI Load Balancerは、クライアント・アクセス要件に応じてパブリックまたはプライベートにできます。マルチADリージョンの暗黙的な高可用性機能の場合、OCI Load Balancerをリージョナル・サブネットに配置します。
Oracle Cloud Infrastructure File Storage
Oracle WebLogic Server for Oracle Cloud Infrastructure、Oracle SOA Suite on MarketplaceまたはOracle Fusion MiddlewareシステムのDRシステムでは、WebLogicクラスタの様々なノードによって共有されるOracle Cloud Infrastructure File Storageマウントを使用します。マウントは、リージョン間で構成をレプリケートするために使用されます。
- Oracle SOA Suite on Marketplaceシステムでは、新しいファイル・ストレージを作成するか、既存のファイル・ストレージを再利用できます。/u01/soacs/dbfs/share/ディレクトリにマウントされます。このディレクトリの名前にもかかわらず、これはOracle Autonomous DatabaseのOracle Database File System (DBFS)マウント・ディレクトリではありません。Oracle SOA Suite on Marketplaceスタックで「ファイル・ストレージの構成」を選択していることを確認します。プロビジョニング中またはプロビジョニング後にオプションを選択できます。
- Oracle WebLogic Server for Oracle Cloud Infrastructureシステムでは、新しいファイル・ストレージを作成するか、既存のファイル・ストレージを再利用できます(/u01/sharedディレクトリにマウント)。Oracle WebLogic Server for OCIスタックで「ファイル・システムの追加」を選択していることを確認します。プロビジョニング中またはプロビジョニング後にオプションを選択できます。
- その他のサービスでは、プライマリ中間層ノードとセカンダリ中間層ノードの両方でOCI File Storageマウントを手動で作成する必要がある場合があります。Oracle WebLogic Server for Oracle Cloud InfrastructureまたはOracle SOA Suite on Marketplaceを使用していない場合は、ストレージを作成するための詳細およびステップについて、OCI File Storageのドキュメントを参照してください。