Oracle SOA SuiteのハイブリッドDRソリューションの構成
開始する前に
このドキュメントで使用されるOracle WebLogic Serverシステムは、Fusion MiddlewareシステムのOracle SOA Suiteエンタープライズ・デプロイメント・ガイド(EDG)で説明されているMAA標準ベスト・プラクティスに従って構成された高可用性環境です。すべてのシナリオが詳細にこの正確なトポロジに従うわけではありませんが、多くの異なるコンポーネントと組合せをカバーし、大規模なデプロイメントで頻繁に使用され、障害回復(DR)システムをデプロイする前に適用する必要がある高可用性推奨事項を実装します。そのため、Oracle WebLogic ServerのハイブリッドDRソリューションのプライマリ・システムの最適なリファレンス例と考えられています。これに基づいて、ハイブリッド・システムをデプロイする前に、ネットワーク、ストレージおよびホスト設定のベスト・プラクティスに関するOracle WebLogic Serverの高可用性およびエンタープライズ・デプロイメントのベスト・プラクティスに精通することをお薦めします。
- Oracle Fusion Middleware高可用性ガイド
- Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド
- Oracle Fusion Middleware MAAベスト・プラクティス- Oracle Fusion Middlewareのエンタープライズ・デプロイメント・ガイド
Oracle Cloud Infrastructureの概念および管理についても理解していることを確認してください。
アーキテクチャ
プライマリ・システムは、オンプレミスにあるOracle SOA Suiteシステムです。スタンバイ・システムは、Oracle Cloud Infrastructure FastConnect (またはサイト間VPN)を使用してオンプレミス環境に接続するOCIテナンシで最初から作成されます。
OCI上の中間層は、Oracle SOA Cloud ServiceまたはOracle SOA Suite on Marketplaceインスタンスではなく、OCI仮想マシン(VM)にSOAをインストールすることで作成されます(Oracle SOA Cloud ServiceまたはOracle SOA Suite on Marketplaceインスタンスがオンプレミス・システムのスタンバイとして正しく動作することを防ぐOSバージョン、OSユーザーおよびディレクトリ構造には制限があります)。
OCIサイトのデータベース層は、Oracle Real Application Clusters (Oracle RAC) DB Systemです。
![maa-soa-hybrid-dr.pngの説明が続きます maa-soa-hybrid-dr.pngの説明が続きます](img/maa-soa-hybrid-dr.png)
図maa-soa-hybrid-dr.pngの説明
このアーキテクチャは、プライマリのオンプレミス・データ・センターで次のコンポーネントをサポートします。
- オンプレミス・ネットワーク
このネットワークは、組織で使用されるローカルネットワークです。トポロジのスポークの一つです。
- ロード・バランサ
単一エントリ・ポイントからバックエンドの複数のサーバーへの自動トラフィック分散を提供します。
- Oracle SOA Suite
SOA環境は、標準のOracle SOA Suiteエンタープライズ・デプロイメント・ガイド(EDG)に従って構成されます。このトポロジは、大規模な配備で頻繁に使用される多くのさまざまなコンポーネントをカバーし、DRシステムを配備する前に適用すべき高可用性推奨事項を実装します。
- Oracle Real Application Clusters(Oracle RAC)
Oracle RACでは、共有ストレージへのアクセス中に可用性を最大化し水平スケーラビリティを実現するために、複数のサーバーにわたって単一のOracle Databaseを実行できます。Oracle RACインスタンスに接続しているユーザー・セッションは、エンド・ユーザー・アプリケーションを変更することなく、停止中にフェイルオーバーして安全に変更をリプレイでき、エンド・ユーザーからの停止の影響を隠すことができます。
このアーキテクチャは、OCIのセカンダリのスタンバイ環境で、次のコンポーネントをサポートします。
- リージョン
Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含むローカライズされた地理的領域です。地方は他の地域から独立し、たくさんの距離(国や大陸など)を分けることができます。
- 仮想クラウド・ネットワーク(VCN)およびサブネット
VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェアで定義されたネットワークです。従来のデータ・センター・ネットワークと同様に、VCNではネットワーク環境を完全に制御できます。VCNには複数の重複しないCIDRブロックを含めることができ、VCNの作成後に変更できます。VCNをサブネットに分割できます。サブネットはリージョンまたは可用性ドメインにスコープ指定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックまたはプライベートにできます。
プライベート・サブネットは、セキュリティ上の理由から一般的にお薦めします。ただし、パブリック・インターネットからリソースにアクセスする必要がある場合(パブリック・インターネットからLoad Balancerにアクセスする場合、パブリック・サブネットに存在する必要があります)。
- 動的ルーティング・ゲートウェイ(DRG)
DRGは、VCNとリージョン外のネットワーク(別のOracle Cloud Infrastructureリージョン内のVCN、オンプレミス・ネットワーク、別のクラウド・プロバイダ内のネットワークなど)間のプライベート・ネットワーク・トラフィックのパスを提供する仮想ルーターです。
- FastConnect
Oracle Cloud Infrastructure FastConnectは、データ・センターとOracle Cloud Infrastructureの間の専用プライベート接続を簡単に作成する方法を提供します。FastConnectは、インターネットベースの接続と比較して、高帯域幅のオプションとより信頼性の高いネットワーキング体験を提供します。
- セキュリティ・リスト
サブネットごとに、サブネットとの間で送受信を許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。
- ルート表
仮想ルート表には、サブネットからVCN外部の宛先(通常はゲートウェイ経由)にトラフィックをルーティングするルールが含まれます。
- ロード・バランサ
Oracle Cloud Infrastructure Load Balancingサービスは、1つのエントリ・ポイントからバックエンド内の複数のサーバーへの自動トラフィック分散を提供します。
- クラウド・ガード
Oracle Cloud Guardを使用して、Oracle Cloud Infrastructure内のリソースのセキュリティをモニターおよびメンテナンスできます。クラウド・ガードはディテクタ・レシピを使用します。ディテクタ・レシピを定義すると、セキュリティの弱点についてリソースを調べたり、特定のリスクのあるアクティビティについてオペレータとユーザーをモニターしたりできます。構成の誤りまたは安全でないアクティビティが検出された場合、クラウド・ガードは、ユーザーが定義できるレスポンダ・レシピに基づいて、修正アクションを推奨し、それらのアクションの実行を支援します。
- DB System
Oracle Database Systemは、フル機能のOracleデータベースの構築、スケーリングおよび管理を可能にするOracle Cloud Infrastructure (OCI)データベース・サービスです。DB Systemは、ローカル・ストレージではなくOCI Block Volumesストレージを使用し、Oracle Real Application Clusters (Oracle RAC)を実行して可用性を高めることができます。
- Oracle Cloud Infrastructure File Storageサービス
Oracle Cloud Infrastructure File Storage Serviceでは、永続的でスケーラブルなエンタープライズ規模のネットワーク・ファイル・システムを提供します。Virtual Cloud Network (VCN)内の任意のベア・メタル、仮想マシンまたはコンテナ・インスタンスからFile Storageサービスのファイル・システムに接続できます。ファイル・ストレージ・サービスは、ネットワーク・ファイル・システム・バージョン3.0 (NFSv3)プロトコルをサポートしています。また、ファイル・ロック機能にはNetwork Lock Manager (NLM)プロトコルをサポートしています。
Oracle Cloud Infrastructure File Storageでは、異なるフォルト・ドメインにある5方向のレプリケートされたストレージを使用して、回復可能なデータ保護の冗長性を提供します。データは、消去エンコーディングで保護されます。File Storageサービスは、広範なユース・ケースでエンタープライズ・ファイル・システムを必要とするアプリケーションとユーザーのニーズを満たすように設計されています。
- Oracle Cloud Infrastructure Block Volumes
Oracle Cloud Infrastructure Block Volumesサービスを使用すると、ブロック・ストレージ・ボリュームを動的にプロビジョニングおよび管理できます。ストレージ、パフォーマンスおよびアプリケーションの要件を満たすように、ボリュームを作成、アタッチ、接続および移動し、必要に応じてボリューム・パフォーマンスを変更できます。ボリュームをインスタンスにアタッチおよび接続した後は、そのボリュームを通常のハード・ドライブのように使用できます。
- Oracle RAC DBシステム
Oracle Real Application Clusters (Oracle RAC)では、顧客は、共有ストレージへのアクセス中に可用性を最大化し水平スケーラビリティを実現するために、複数のサーバーにわたって単一のOracle Databaseを実行できます。Oracle RACインスタンスに接続しているユーザー・セッションは、エンド・ユーザー・アプリケーションを変更することなく、停止中にフェイルオーバーして安全に変更をリプレイでき、エンド・ユーザーからの停止の影響を隠すことができます。Oracle RACの高可用性フレームワークでは、各サービスの構成情報をOracle Cluster Registry (OCR)に格納することでサービスの可用性が維持されます。
Oracle RAC DBシステムはデータベース層にあります。
- Data Guard
Oracle Data Guardは、1つ以上のスタンバイ・データベースを作成、維持、管理および監視する一連の包括的なサービスを提供し、本番のOracleデータベースを中断せずに引き続き使用できます。Oracle Data Guardは、本番データベースのコピーとしてスタンバイ・データベースを維持します。その後、計画停止または計画外停止のために本番データベースが使用できなくなった場合、Oracle Data Guardは任意のスタンバイ・データベースを本番ロールに切り替え、停止に関連する停止時間を最小限に抑えることができます。
トポロジの説明
db-tierでは、プライマリ・データベースとセカンダリ・データベースはOracle Data Guardで構成されています。Oracle Data Guardでは、プライマリ・データベースに適用されるすべての変更がセカンダリ(スタンバイ)データベースにレプリケートされます。
セカンダリ中間層は、OCI仮想マシン(VM)にインストールされます。Oracle Fusion MiddlewareバイナリおよびSOAドメインは、Oracle Cloud Infrastructure File Storageサービスをネットワーク・ファイル・システム・ソリューションとして使用し、Oracle Cloud Infrastructure Block Volumesをノードのプライベート・アクセス・ファイル・システム・ソリューションとして使用する、プライマリのバイナリおよびSOAドメインのレプリカです。プライマリのホスト名別名は、セカンダリ環境のWebLogicサーバーのリスナー・アドレスとしても使用されます。セカンダリ・ロケーションでは、ホスト名の別名はセカンダリ・ホストのIPアドレスで解決されます。
プライマリ・データ・センターのweb- tierは、2つのOracle HTTP Serverホストとロード・バランサ(LBR)を備えたエンタープライズ・デプロイメント・ガイド(EDG)モデルに従います。OCIコンピュート・インスタンスにインストールされているOCI Load BalancerおよびOracle HTTP Serverホストを使用して、同じトポロジがセカンダリ・システムにデプロイされます。セカンダリ・システムでは、OCI Load Balancerのみを使用してWebレイヤーを実装することもできます。OCI Load Balancerは、エンタープライズ・デプロイメント・トポロジに必要なほとんどの機能を提供します。このドキュメントには、OCI Load Balancer、OCI Load BalancerおよびOracle HTTP Serverホストの両方のオプションが含まれています。
システムで実行されているアプリケーションにアクセスするために、一意のフロントエンド・アドレスが構成されます。仮想フロントエンド名は、プライマリ・サイト上のLoad BalancerのIPを指します。スイッチオーバーでは、フロントエンド名がセカンダリ・サイトのOCI Load BalancerのIPを指すようにDNSで更新されます。プライマリ・ロールを持つサイトのLoad Balancer IPを常に指す必要があります。
通常のビジネス操作中、スタンバイ・データベースはフィジカル・スタンバイです。マウント状態であるか、Active Data Guardの使用時に読取り専用モードでオープンされます。スタンバイ・データベースは、プライマリ・データベースからredo
を受信して適用しますが、読取り/書込みモードでオープンすることはできません。Oracle Data Guardは、サーバー指向アーキテクチャ(SOA)スキーマ、Oracle Platform Security Services情報、カスタム・スキーマ、トランザクション・ログ(TLOG)、Java Database Connectivity (JDBC)永続ストアなど、データベース内の情報をセカンダリ・サイトに自動的にレプリケートします。
このドキュメントで説明するDR設定およびライフサイクル検証のステップでは、スタンバイ・データベースをフィジカル・スタンバイからスナップショット・スタンバイに変換して、完全なスイッチオーバーを実行せずにセカンダリ・サイトを検証できます。スナップショット・スタンバイ・モードのデータベースは、完全に更新可能なデータベースです。スナップショット・スタンバイ・データベースは、プライマリ・データベースから受信したredo
データを受信およびアーカイブしますが、適用はしません。スナップショット・スタンバイに適用されたすべての変更は、フィジカル・スタンバイに変換されると破棄されます。
WebLogicドメイン構成は、プライマリ・サイトからセカンダリ・サイトにレプリケートする必要があります。このレプリケーションは、初期DR設定時に必要かつ実行されるため、システムの継続的なライフサイクル中も必要です。プライマリドメインで構成の変更を実行する場合は、セカンダリ場所にレプリケートする必要があります。
通常のビジネス操作中にスタンバイ・データベースが停止すると、プライマリ・データベースから更新を受信せず、同期しなくなることがあります。これにより、スイッチオーバー・シナリオでデータが失われる可能性があるため、通常のビジネス操作中にスタンバイ・データベースを停止することはお薦めしません。スタンバイ中間層ホストを停止できます。ただし、スタンバイホストが停止した場合、プライマリサイトからレプリケートされる構成変更はセカンダリドメインにプッシュされません。この場合、スイッチオーバーが発生すると、スタンバイ中間層ホストを起動し、ドメインがプライマリの変更と同期するため、リカバリ時間目標(RTO)が増加します。
トポロジに関する考慮事項
この設定で考慮される最も関連するトポロジの前提を次に示します。
- プライマリ・システムは既存のオンプレミス環境です。
この環境には、Oracle Real Application Clusters (Oracle RAC)データベース、中間層ホストおよびロード・バランサが含まれます。オンプレミス・システムの設定はこのドキュメントの範囲外です。
- セカンダリ・システムはOracle Cloud Infrastructure(OCI)にあります
セカンダリ・システムはOCI上に最初から作成され、Oracle Cloudバージョンのオンプレミス・システムを提供します。プライマリ・システムになる機能を備えた、完全に標準のOracle Cloudシステムです。
- Oracle SOA Suiteおよびコンポーネント
このドキュメントは、そのコンポーネントを含むOracle SOA Suiteシステムに焦点を当てています。たとえば、Oracle Service Bus、Oracle Business Process Management、Oracle Enterprise Scheduler Serviceなどです。このドキュメントのプロシージャおよび推奨事項は、Oracle SOA Suiteの一部ではない他のOracle Fusion Middlewareコンポーネント(Web CenterやBusiness Intelligenceなど)に適用できますが、それらの詳細およびサポート対象はこの演習から除外されます。
- プライマリ・システムとセカンダリ・システムは対称です。
セカンダリ・システムのノード数は、中間層、Web層およびdb層で同じです。OCIで(Oracle HTTP Serverなしで)OCI Load Balancerを単独で使用する場合、Web層に違いがある可能性があります。
- プライマリ・システムとセカンダリ・システムでは、同様のリソースが使用されます。
使用可能なOCIシェイプは、既存のプライマリ構成のCPUおよびメモリーの正確な値と一致しない場合がありますが、最も類似したシェイプを使用する必要があります。Oracleでは、プライマリ・システムに同様の処理能力を提供する対称スタンバイを使用することをお薦めします。そうしないと、ワークロードがOCIシステムにスイッチオーバーされたときに、パフォーマンスの問題およびカスケード障害が発生する可能性があります。
ネットワークに関する考慮事項
- オンプレミス・ネットワークとOracle Cloud Infrastructure (OCI)間の接続性
オンプレミス・データベースとOCIデータベースは、Oracle Data Guard
redo
トランスポートのためにOracle SQL*Netリスナー(ポート1521)を介して相互に通信する必要があります。オンプレミス・ホストおよびOCI中間層ホストは、SSHポート(rsync
コピー用)を使用して相互に通信する必要があります。Oracleでは、オンプレミス・データ・センターとOCIリージョン間でOracle Cloud Infrastructure FastConnect通信を使用することをお薦めします。Oracle Cloud Infrastructure FastConnectは、予測可能なレイテンシ、ジッターおよびコストを備えた専用のセキュアな接続と帯域幅を提供します。または、オンプレミスとOCI間のセキュアな接続を提供するSite- to- Site VPNを使用できます。ただし、これにより、帯域幅が低く、可変レイテンシ、ジッタおよびコストが実現されます。 - 中間層ホストとリモート・データベース間の接続を無効化します。
中間層ホストは、実行時にリモート・データベースに接続しないことが想定されます。オンプレミスとOCIの間のレイテンシは、通常、このクロスコネクト比を推奨しません。誤った接続およびワークロードの問題を回避するために、中間層ホストからリモート・データベースへの接続を除外します。
- 仮想ホスト名
ベスト・プラクティスとして、プライマリ・オンプレミス・システムでは、物理ノードのホスト名ではなく仮想ホスト名をOracle WebLogic Serverのリスニング・アドレスとして使用することを想定しています。通常、仮想ホスト名は物理ノード・ホスト名の別名です。仮想ホスト名を使用すると、構成を別のホストに簡単に移動できますが、これは必須の要件ではありません。このドキュメントの構成は、OCIのセカンダリ・サーバーが(DNSまたはローカル
/etc/hosts
で解決された)各ノードの別名としてプライマリのリスニング・アドレスとして使用されるホスト名を使用できるかぎり機能します。 - 仮想IPは、管理サーバーのリスニング・アドレスにのみ必要です
自動サービス移行がサポートされており、ローカルの高可用性(HA)に推奨されています。これは、管理対象サーバーが仮想IPアドレスを使用する必要がないことを意味します。ローカル・フェイルオーバーに必要なのは、管理サーバーのみです。ベスト・プラクティスとして、プライマリ・オンプレミス・システムの管理サーバーがVIPアドレスをリスニングすることを想定しています。このドキュメントでは、OCIで管理サーバー用にVIPを構成する手順について説明します。ただし、このVIPアドレスは、このドキュメントを使用してOCIでディザスタ・リカバリを構成するためのハード要件ではありません。プライマリ管理サーバーでVIPをリスニングしない場合は、その点をスキップできます。
- ロード・バランサ
フロントエンド・ロード・バランサ(LBR)はプライマリ・オンプレミス環境で使用され、OCI Load Balancerはスタンバイ環境で使用されます。
- 仮想フロントエンド・アドレス
プライマリシステムでは、クライアントのエントリポイントとして仮想フロントエンド名(mysoa.example.comなどのバニティーURL)を使用する必要があります。このフロントエンド名は、プライマリ・ロード・バランサのIPアドレスを使用してDNSで解決されます。DRトポロジでは、セカンダリシステムは同じ仮想フロントエンド名を使用するように構成されます。セカンダリ・システムへのスイッチオーバーまたはフェイルオーバーが発生すると、セカンダリ・ロード・バランサのIPアドレスを指すように、DNSで仮想フロントエンドの名前が変更されます。このようにして、クライアントからシステムへのアクセスは、プライマリとして使用されているサイトに依存しません。同じことが、システムで使用される仮想フロントエンド名にも適用されます。たとえば、
admin.example.com
などの追加のフロントエンド名を使用して、Oracle WebLogic Server管理コンソールまたはFusion Middleware Controlコンソールの管理機能にアクセスできます。osb.example.com
などの独立したフロントエンド名を使用して、Oracle Service Busサービスにアクセスできます。このドキュメントでは、簡略化のために1つのフロントエンド・ホスト名を使用します。
ストレージに関する考慮事項
- EDGベースのディレクトリ構造
このドキュメントでは、プライマリ・システムのOracle WebLogic Serverドメイン構成にエンタープライズ・デプロイメント・ガイド(EDG)のディレクトリ構造を使用します。EDGモデルでは、エンタープライズ・デプロイメント用のファイル・システムの準備の説明に従って、管理Oracle WebLogic Serverおよび管理対象Oracle WebLogic Serverごとに個別のドメイン・ディレクトリを使用します。例では、EDGディレクトリ構造が参照として使用されています。共有フォルダとプライベート・フォルダの組合せを使用して、より多くのユースケースをカバーします。システムでEDGディレクトリ構造を使用しない場合は、環境の詳細に合せて例を適応させます。
- プライマリ(オンプレミス)のストレージに関する考慮事項共有フォルダ(Oracle WebLogic Server管理サーバー・ドメイン・ディレクトリ、デプロイメント・プラン・ホーム、共有ランタイムなど)だけでなく、Oracle Fusion Middlewareホーム・バイナリおよびローカル構成(管理対象サーバー・ドメイン・ディレクトリ、ノード・マネージャ・フォルダ)もプライマリ・ロケーションのNFSストレージに格納することをお薦めします。これにより、プライマリからスタンバイへのコピーが容易になります。各ホストは独自のバイナリと独自のローカル構成をプライベート(サーバーごとに別々のNFSボリューム)で使用しますが、サイト間での構成のコピーは、共有ストレージにあるとより簡単です。この方法を使用すると、これらすべてを一意のノードからマウントし、単一の操作でリモート・ノードへのrsyncコピーを実行できます。この方法を使用しない場合、コピーは、データをプライベートに格納する各プライマリノードから個別に実行する必要があります。
ノート:
これらのrsync
コピー用に提供されるスクリプトは、どのような場合にも適応できるほど柔軟です。 - セカンダリ(OCI)の共有フォルダに関する考慮事項
中間層ホスト間で共有する必要があるフォルダ(Oracle WebLogic Server管理サーバー・ドメイン・ディレクトリ、デプロイメント・プラン・ホーム、共有ランタイムなど)は、共有記憶域に格納する必要があります。OCIは、ネットワーク・ファイル・システム・ソリューションとしてOracle Cloud Infrastructure File Storageを提供します。
異なるアーティファクトは共有フォルダであり、使用方法とライフサイクルは異なります。使用法に応じて、別々の共有記憶域に配置する必要があります。例:- 共有構成(WebLogic Server管理サーバー・ドメイン・ディレクトリ、デプロイメント・プラン・ホームなど)は、主に管理サーバー・ホストからアクセスされます。残りのホスト(デプロイメント・プラン、共有キーストアなど)から引き続きアクセスされます。これは、1つのOracle Cloud Infrastructure File Storageファイル・システムに配置する必要があります。
- システムが実行時アーティファクトに共有フォルダ(アプリケーションによって作成および読み取られるファイルなど)を使用する場合は、通常、すべての中間層ホストで同時に使用されます。ランタイム・アーティファクトは、別のOracle Cloud Infrastructure File Storageファイル・システムまたはデータベース・ファイル・システム(DBFS)マウントに配置する必要があります。
- セカンダリ(OCI)のプライベート・フォルダ記憶域に関する考慮事項
FMWバイナリおよびローカル構成は、各ホストで個別に使用されます。ホストのデフォルトのブート・ボリュームではなく、外部ストレージに格納することをお薦めします。
- OCIでは、ホストごとにFMWバイナリをOracle Cloud Infrastructure Block Volumesに格納できます。中間層ホストが2つ以上ある場合は、冗長共有バイナリ・ホームを使用することをお薦めします(『高可用性ガイド』を参照)。これを行うには、Oracle Cloud Infrastructure File Storageを使用してFMWバイナリを格納します。
- ローカル構成(WebLogic管理対象サーバー・ドメイン・ディレクトリ、ノード・マネージャ・フォルダなど)は、各ホストでプライベートに使用することが想定されているため、Oracle Cloud Infrastructure Block Volumesに格納できます。または、各ノードによってプライベートにマウントされたOracle Cloud Infrastructure File Storageファイル・システムを使用できます。
プライマリ・サイトからリモート・サイトへのコピーを容易にするために、一意のノードからストレージ・ファイルをマウントし、単一の操作でrsync
コピーを実行できます(ブロック・ボリュームの場合、別のホストがファイルを読取り専用モードでマウントできます)。または、データをプライベートに格納する各ノードからコピーを個別に実行できます。ノート:
これらのrsync
コピー用に提供されるスクリプトは、どのような場合にも適応できるほど柔軟です。 - ストレージ・レプリケーション
オンプレミスとOCIの間のストレージ・レベルでの直接レプリケーションはありません。プライマリからスタンバイへのバイナリおよび構成のコピーは、Oracle Cloud Infrastructure FastConnectまたはサイト間VPN (パブリック・インターネットを使用しない)上のプライベート接続を介して、Secure Shell (SSH)を介して
rsync
で実行されます。構成およびランタイム・アーティファクトのコピーは、顧客のニーズに応じてDBFSに基づくこともできます。これの詳細は後で説明します。 - WebLogic永続ストア
TLOGSおよびJMSメッセージに使用されるWebLogic永続ストアは、JDBC永続ストアであり、データベース表に格納されることを前提としています。このようにして、クラスタのすべてのメンバーから永続ストアにアクセスできます(サービス移行をローカルHAに提供するため)。これは、TLOGSおよびJMSをセカンダリ・サイトに自動的にレプリケートする基礎となるOracle Data Guardも利用します。
データベースに関する考慮事項
データベースを構成する際には、次の点を考慮してください。
- マルチテナンシ
プライマリ・データベースは、マルチテナント・データベース(CDB/PDB)である必要があります。これは、Oracle Cloud InfrastructureでハイブリッドOracle Data Guardを構成するために必要です。
- パッチ・レベル
オンプレミス・データベースのOracleホームは、スタンバイ・データベースと同じパッチ・レベルである必要があります。
- 透過的データ暗号化
プライマリ・データベースとスタンバイ・データベースの両方にTransparent Data Encryption (TDE)を使用して、すべてのデータが暗号化されるようにします。オンプレミス・データベースがTDEでまだ有効化されていない場合は、TDEに変換してから、最もセキュアな環境を提供するようにOracle Data Guardを構成することをお薦めします。
- 高可用性
データベース・レベルでローカル高可用性を取得し、EDGトポロジに従うには、プライマリ・データベースとスタンバイ・データベースの両方にOracle Real Application Clusters (Oracle RAC)を使用します。Oracle RACに重点を置いていますが、この手順は単一のデータベースに適用されます。ただし、Oracle RACを使用して、db層のローカルの高可用性を取得することをお薦めします。
- データベース・サービス
プライマリ・オンプレミスの中間層では、アプリケーション・データベース・サービスを使用してプライマリ・データベースに接続する必要があります。
- Oracle Cloud Infrastructure (OCI)データベース・システム
OCI DB System (ベア・メタル、仮想マシンまたはOracle Exadata Database Service)をスタンバイ・データベースとして使用します。共有または専用であるOracle Autonomous Databaseは、このドキュメントの範囲外です。Oracle Data Guardをオンプレミス・データベースで構成する機能やスナップショット・スタンバイ変換など、ハイブリッド・ディザスタ・リカバリ設定に必要な多くの機能は提供されません。
- WebLogicデータベース接続文字列のTNS別名
このドキュメントでは、TNS別名を使用して、Oracle WebLogic構成でデータベース接続文字列を定義します。TNS別名は、サイトごとに異なり、ローカル・データベースを指す
tnsnames.ora
ファイルを使用して解決されます。プライマリとセカンダリで同じ別名が使用されるため、プライマリからセカンダリにレプリケートした後にWebLogic構成を変更する必要はありません。プライマリがこのアプローチをまだ使用していない場合は、最初の1回かぎりの設定が必要です。詳細は、このドキュメントで後述します。
アイデンティティ管理に関する考慮事項
- Lightweight Directory Access Protocol (LDAP)
プライマリ・システムとスタンバイ・システムの両方から外部LDAPにアクセスできるかぎり、認証に外部LDAPを使用できます(Oracle Unified Directoryなど)。
- LDAPのディザスタ・リカバリ・ソリューション
外部LDAPサービスのディザスタ・リカバリ・ソリューションはこのドキュメントの範囲外であるため、特定のLDAP製品が提供する必要があります。LDAP用のDRソリューションは、LDAPシステムにスイッチオーバーがある場合には変更されない一意のアクセス方法(通常は仮想ホスト名)を提供するべきです。
考慮事項のまとめ
次に、障害時リカバリ・ソリューションを計画する際の考慮事項の概要を示します。
考慮事項 | 概要 | 必須または高推奨 |
---|---|---|
トポロジ | プライマリ・システムは、既存のオンプレミス環境です。 | 強く推奨 |
トポロジ | セカンダリ・システムはOracle Cloud Infrastructure (OCI)上にあり、OCI上に最初から作成されます。 | 必須項目 |
トポロジ | プライマリ・システムとセカンダリ・システムは対称で、db- tier、中間層およびWeb層のノード数が同じです。 | 必須項目 |
トポロジ | プライマリWeb層は、Oracle HTTP Serverの前にあるロード・バランサで構成されます。 | 強く推奨 |
トポロジ | プライマリ・システムとセカンダリ・システムでは、類似のリソース(CPU、メモリーなど)が使用されます。 | 必須項目 |
ネットワーク | オンプレミスとOCI間の接続にはOCI FastConnect、またはSite- to- Site VPNを使用します。パブリック・インターネットを使用しません。 | 必須項目 |
ネットワーク | 中間層ホストとリモート・データベース間の接続を無効にします。構成のレプリケートにOracle Database File System (DBFS)が使用されている場合にのみ必要です。 | 強く推奨 |
ネットワーク | WebLogicサーバーのリスニング・アドレスに仮想ホスト名を使用します。 | 強く推奨 |
ネットワーク | 管理サーバーの仮想IP。 | 強く推奨 |
ネットワーク | 仮想フロントエンド・アドレス。 | 必須項目 |
ストレージ | EDGベースのディレクトリ構造。 | 強く推奨 |
ストレージ | オンプレミスのプライベート・フォルダと共有フォルダを外部ストレージに格納して、rsync操作を一元化するために一意のノードからマウントできるようにします。 | 強く推奨 |
ストレージ | Oracle Cloud Infrastructure File StorageでのOCI共有構成。 | 必須項目 |
ストレージ | OCIファイル・ストレージまたはOracle Databaseファイル・システム(DBFS)でのOCI共有ランタイム。 | 必須項目 |
ストレージ | OCI File StorageのOCI FMWバイナリ・フォルダがプライベートにマウントされました。 | 強く推奨 |
ストレージ | Oracle Cloud Infrastructure Block VolumesでのOCIローカル構成(または、プライベートにマウントされたOCI File Storage)。 | 強く推奨 |
ストレージ | ステージングDBFSマウント(構成にDBFSベースの複製が使用されている場合のみ)。 | 強く推奨 |
ストレージ | rsync に基づくストレージ・レプリケーション(または、構成などの特定のアーティファクトのDBFS)。
|
強く推奨 |
ストレージ | JDBC永続ストア内のWebLogic永続ストア(TLOGS、JMS) | 必須(*JMS情報が関連する場合) |
データベース | オンプレミス・データベースのパッチ・レベルがスタンバイ・データベースと同じです。 | 必須項目 |
データベース | プライマリ・データベースとスタンバイ・データベースのTransparent Data Encryption (TDE)。オンプレミス・データベースがTDEでまだ有効化されていない場合は、Oracle Data Guardを構成する前にTDEへの変換を強くお薦めします。 | 必須項目 |
データベース | ローカル高可用性のためのOracle RACデータベース。 | 強く推奨 |
データベース | プライマリ・マルチテナンシ・データベース。 | 必須項目 |
データベース | データベースに接続するには、デフォルトの管理サービスではなくアプリケーション・データベース・サービスを使用します。 | 必須項目 |
データベース | OCIでは、Oracle Autonomous Databaseではなく、DB System (BM、VMまたはOracle Exadata Database Service)を使用します。 | 必須 |
データベース | WebLogicデータベース接続文字列のTNS別名。 | 強く推奨 |
Identity Management | プライマリ・システムとスタンバイ・システムの両方から外部LDAPにアクセスできるかぎり、認証に外部LDAPを使用できます(Oracle Unified Directoryなど)。 | 必須(外部LDAPの使用は必須ではありませんが、使用する場合は両方のサイトからアクセス可能である必要があります) |
Identity Management | 外部LDAPサービスの障害回復ソリューションはこのドキュメントの範囲外であり、特定のLDAP製品によって提供される必要があります。LDAP用のDRソリューションは、LDAPシステムにスイッチオーバーがあるときに変更されない固有のアクセス方法(通常は仮想ホスト名)を提供するようにしてください。 | 必須(外部LDAPの使用は必須ではありませんが、使用され、DR保護されている場合、LDAPアクセス方法のためにスイッチオーバー/フェイルオーバーが発生したときに同じままの仮想アクセス・アドレスを指定する必要があります) |
必須サービスおよびロールについて
このソリューションには、次のサービスおよび役割が必要です。
各サービスに必要なロールは次のとおりです。
サービス名:ロール | 必須 |
---|---|
Oracle Cloud Infrastructure: administrator |
OCIテナンシに必要なリソース(コンパートメント、DBシステム、コンピュート・インスタンス、FSSリソースおよびロード・バランサ)を作成します。 |
ネットワーク: administrator
|
オンプレミスとOCIの両方で、必要なネットワーク・リソースを構成します:高速接続、VCNおよびOCIのサブネット、ネットワーク・セキュリティ・ルールおよびルーティング・ルール。 |
Oracle Data Guard: root 、oracle およびsysdba |
プライマリ・オンプレミスとスタンバイOCIの間にOracle Data Guardを構成し、ロール変換を実行します。 |
Oracle Database: sysdba |
データベースの管理。 |
Oracle WebLogic Server: root 、oracle |
必要に応じて中間層ホストを構成します。OSレベル構成の実行、ホスト別名の追加、仮想IPアドレスの管理およびファイル・システムのマウント。 |
Oracle WebLogic Server: Weblogic Administrator |
Oracle WebLogic Serverの管理: WebLogic構成の変更を停止、起動および適用します。 |
必要なクラウド・サービスを取得するには、https://docs.oracle.com/pls/topic/lookup?ctx=en/solutions/soa-dr-on-cloud&id=GCSSLを参照してください。