3 障害時リカバリ・サイトの設定と管理
Oracle SOA Suiteエンタープライズ・デプロイメント・トポロジについて確認し、本番サイトおよびスタンバイ・サイトを設定する方法について学習します。
ノート:
スイッチオーバーやフェイルオーバーなどの障害時リカバリ操作は、Oracle Site Guardを使用して自動化できます。『Oracle Site Guard管理者ガイド』を参照してください。
この章の内容は次のとおりです。
- サイトの設定
Oracle障害時リカバリ・サイトの設定方法を確認します。 - Oracle SOAエンタープライズ・トポロジでの本番サイトの作成
Oracle SOAエンタープライズ・デプロイメント・トポロジで本番サイトを作成する方法を学習します。 - スタンバイ・サイトの作成
スタンバイ・サイトを作成する方法を確認します。 - サイトの操作および管理の実行
Oracle Fusion Middleware障害時リカバリ・トポロジを操作および管理する方法を確認します。 - 障害時リカバリのためのOracle Site Guardの使用
Oracle Site Guardは障害時リカバリ・ソリューションで、管理者は、サイトの完全なスイッチオーバーやフェイルオーバーを自動化できるようになります。Oracle Fusion Middleware、Oracle Fusion ApplicationsおよびOracleデータベースの調整されたフェイルオーバーを編成します。 - Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用
Oracle Fusion Middlewareパッチ・セットを適用して、Oracle Fusion Middleware障害時リカバリ・サイトに含まれるOracleホームをアップグレードする方法を説明します。 - DRシナリオにおけるT3/T3s外部クライアントへのアクセスおよび管理
この項では、ディザスタ・リカバリのシナリオのコンテキストにおいて、外部T3/T3sクライアントにアクセスする方法や管理する方法をいくつか説明します。
サイトの設定
Oracle障害時リカバリ・サイトを設定する方法を学習します。
本番サイトの作成を開始する前に、次の点を確認します。
-
「ホスト名の計画」の説明に従って、中間層ホストのホスト名別名を設定します。
-
「ディレクトリ構造とボリュームの設計」の説明に従って、本番サイトの共有ストレージに必要なボリュームを作成します。
-
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定します。
この項には次のトピックが含まれます:
- ディレクトリ構造とボリュームの設計
障害時リカバリ・トポロジで推奨されるディレクトリ構造について確認します。 - ストレージ・レプリケーションの設定
ストレージ・レベルのレプリケーション、Rsyncおよびデータベース・ファイル・システムを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定する方法を学習します。 - FMWデータベース用のOracle Data Guardの構成
Oracle SOA Suiteエンタープライズ・デプロイメントでFMWデータベース用のOracle Data Guardをインストールおよび構成する方法を学習します。
親トピック: 障害時リカバリ・サイトの設定と管理
ディレクトリ構造とボリュームの設計
障害時リカバリ・トポロジで推奨されるディレクトリ構造について学習します。
このドキュメントで推奨されるディレクトリ・レイアウトと異なるものを選択できますが、採用されているモデルを使用すると、コンポーネントが最適に分離され、構成における対称性が保たれるとともに、バックアップと障害時リカバリが容易になり、最大限の可用性が実現されます。
次の一覧では、ディレクトリとディレクトリ環境変数について説明します。
-
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを表します。 -
ORACLE_HOME: この関連ディレクトリ・パスは、Oracle Fusion Middlewareが存在する場所を指します。 -
WL_HOME: この環境変数と関連ディレクトリ・パスには、Oracle WebLogic Serverをホストするために必要なファイルがインストールされて格納されています。 -
PROD_DIR: この環境変数および関連するディレクトリ・パスは、製品スイート(Oracle SOA Suite、Oracle WebCenter Portal、Oracle Identity Managementなど)がインストールされている場所を表します。 -
DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogic Domain情報(構成アーティファクト)が保存されている場所を表します。各種のWebLogic Serverは、同じノード内にある場合でも異なるドメイン・ディレクトリを使用できます。 -
ORACLE_INSTANCE: Oracleインスタンスには、1つ以上のシステム・コンポーネントが含まれます。Oracleインスタンスのディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されます。
「Oracle SOA Suiteに推奨されるディレクトリ構造」を参照してください。
この項には次のトピックが含まれます:
- Oracle SOA Suiteに推奨されるディレクトリ構造
Oracle SOA Suiteに推奨されるディレクトリ構造について確認します。 - Oracle SOA Suiteに推奨されるボリューム設計
Oracle SOA Suiteに推奨されるボリューム設計について確認します。
親トピック: サイトの設定
Oracle SOA Suiteに推奨されるディレクトリ構造
Oracle SOA Suiteに推奨されるディレクトリ構造について学習します。
Oracle Fusion Middlewareでは、単一のバイナリ・インストールから複数のSOA管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリ・ファイルをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのOracleホーム(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがある)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。複数のボリュームによって実現する保護はこれによって保証されませんが、ユーザーによる削除や個々のファイルの破損から保護できます。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムへの配置もサポートされていますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図3-1は、Oracle SOA Suiteのディレクトリ構造のレイアウトを示しています。
図3-1 エンタープライズ・デプロイメントで推奨される共有記憶域ディレクトリ構造
図3-2 エンタープライズ・デプロイメントで推奨されるローカル記憶域ディレクトリ構造
このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
親トピック: ディレクトリ構造とボリュームの設計
Oracle SOA Suiteに推奨されるボリューム設計
Oracle SOA Suiteに推奨されるボリューム設計について学習します。
図3-3および図3-4は、Oracle SOA Suiteのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle SOA Suiteトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
図3-3 Oracle SOA SuiteおよびOracle Business Activity Monitoringエンタープライズ・トポロジのダイアグラム
図3-4 Oracle SOA SuiteおよびOracle Service Busエンタープライズ・デプロイメント参照用トポロジのダイアグラム
このOracle SOA Suiteトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。
-
製品の冗長バイナリ・ファイルを格納する2つのOracleホーム用にボリュームを2つプロビジョニングします(表3-1の
VOLFMW1およびVOLFMW2)。 -
管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(
表3-1のVOLADMIN)。 -
管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(
表3-1のVOLSOA1およびVOLSOA2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。 -
Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(
表3-1のVOLWEB1およびVOLWEB2)。 -
Oracle HTTP Serverのドメイン・ホーム用に各ノードでボリュームを1つプロビジョニングします(表3-1の
VOLOHS1およびVOLOHS2)。ノート:
Web層のホストには、通常、ローカル・ストレージが推奨されます。この構成を定期的に他のアプリケーション層のボリュームにレプリケートして、スタンバイに同期したり、本番WebホストからスタンバイWebホストに直接同期することができます。
表3-1に、図3-3および図3-4に示されているOracle SOA Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。
表3-1 Oracle SOA Suiteのボリューム設計に関する推奨事項
| 層 | ボリューム名 | マウントされるホスト | マウント・ポイント | 備考 |
|---|---|---|---|---|
|
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
|
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
|
Web |
|
|
|
Oracle HTTP Serverのドメイン・ディレクトリのボリューム |
|
Web |
|
|
|
Oracle HTTP Serverのドメイン・ディレクトリのボリューム |
|
Web |
|
|
|
(オプション)静的HTMLコンテンツ用のボリューム |
|
Web |
|
|
|
(オプション)静的HTMLコンテンツ用のボリューム |
|
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
|
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
|
アプリケーション |
|
|
|
管理サーバーのドメイン・ディレクトリおよびその他の共有構成(デプロイメント・プラン、アプリケーション、キーストアなど)のボリューム |
|
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
|
|
|
共有ランタイム・コンテンツのボリューム。 たとえば、ファイル・アダプタ、MFT転送およびその他のランタイム・アーティファクトによって使用されるファイルです。 ノート: このフォルダのかわりにJDBC永続ストアを使用して、JMSメッセージおよびTLOGSをデータベースに格納することをお薦めします。 |
コンシステンシー・グループに関する推奨事項は、次を参照してください。
- Oracle SOA Suiteに推奨されるコンシステンシー・グループ
Oracle SOA Suiteに推奨されるコンシステンシー・グループについて確認します。
親トピック: ディレクトリ構造とボリュームの設計
Oracle SOA Suiteに推奨されるコンシステンシー・グループ
Oracle SOA Suiteに推奨されるコンシステンシー・グループについて学習します。
Oracle SOA Suiteトポロジについては、次のコンシステンシー・グループをお薦めします。
-
管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表3-2の
DOMAINGROUP)。 -
JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表3-2の
RUNTIMEGROUP)。 -
Oracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表3-2の
FMWHOMEGROUP)。
表3-2に、図3-3に示されているOracle SOA Suiteトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。
表3-2 Oracle SOA Suiteのコンシステンシー・グループ
| 層 | グループ名 | メンバー | 備考 |
|---|---|---|---|
|
アプリケーション |
|
|
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
|
アプリケーション |
|
|
共有ランタイム・コンテンツのコンシステンシー・グループ |
|
アプリケーション |
|
|
Oracleホーム用のコンシステンシー・グループ |
ストレージ・レプリケーションの設定
ストレージ・レベルのレプリケーション、Rsyncおよびデータベース・ファイル・システムを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定する方法を学習します。
- ストレージ・レベルのレプリケーション
Oracle Fusion Middleware障害時リカバリ・ソリューションは、Oracle Fusion Middlewareの中間層コンポーネントの障害保護にストレージ・レプリケーション・テクノロジを使用しています。 - Rsync
また、レプリケーションのためにrsyncを使用することもできます。Rsyncは汎用性の高いコピー・ツールで、ローカルにコピーしたり、リモート・シェルを介して別のホストとの間でコピーできます。動作のあらゆる面を制御する多数のオプションが用意されており、コピーするファイルのセットを非常に柔軟に指定できます。 - Oracle Database File System
Oracle Database File System (DBFS)は、構成のレプリケートに使用できる補助的な方法です。概念的には、データベース・ファイルシステムは、データベース表に格納されているファイルおよびディレクトリの最上部に配置されたファイルシステム・インタフェースです。
親トピック: サイトの設定
ストレージ・レベルのレプリケーション
Oracle Fusion Middleware障害時リカバリ・ソリューションは、Oracle Fusion Middlewareの中間層コンポーネントの障害保護にストレージ・レプリケーション・テクノロジを使用しています。
Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定するには、次のようにします。
-
スタンバイ・サイトで、本番サイトのピア・ホストに使用されているホスト名別名と同じホスト名別名が作成されていることを確認します。
-
スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。
-
スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンクを作成します。
ノート:
-
シンボリック・リンクを本番サイトに設定した場合、シンボリック・リンクはスタンバイ・サイトにのみ設定する必要があります。
-
シンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。シンボリック・リンクの詳細は、「ストレージの設定」を参照してください。
-
-
本番サイトにインストールしたものと同じOracle Fusion Middlewareインスタンスをスタンバイ・サイトにインストールする必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているOracleソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。
-
本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、本番サイトとスタンバイ・サイトの共有ストレージ間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。
-
スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。
-
Oracle Fusion Middleware障害時リカバリの本番サイトに含まれているデータベースの障害保護機能がOracle Data Guardによって提供されていることを確認します。Oracle Databaseの障害保護にストレージ・レプリケーション・テクノロジは使用しないでください。
-
スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。
-
本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行することを強くお薦めします。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。
親トピック: ストレージ・レプリケーションの設定
Rsync
また、レプリケーションのためにrsyncを使用することもできます。Rsyncは汎用性の高いコピー・ツールで、ローカルにコピーしたり、リモート・シェルを介して別のホストとの間でコピーできます。動作のあらゆる面を制御する多数のオプションが用意されており、コピーするファイルのセットを非常に柔軟に指定できます。
Rsyncはデルタ転送アルゴリズムを実装し、ソース・ファイルと宛先の既存のファイルとの違いのみを送信することにより、ネットワーク経由で送信されるデータの量を削減します。これらの利点と使いやすい機能により、バックアップとミラーリングに広く使用されているツールです。
rsyncは信頼性が高く、暗黙的な再試行を実装しますが、ネットワークの停止やその他の接続の問題により、引き続きファイルの同期に失敗する可能性があります。したがって、次の条件下では、rsyncをストレージ・レベルのレプリケーションのかわりに使用できます:
- ストレージ・レプリケーションが不可能または実現可能でない場合や、コスト要件を満たしていない場合。
- プライマリおよびスタンバイで、コピーに信頼性が高く安全なネットワーク接続を使用する場合。
- コピーでチェックが実行され、それが有効であることを確認する場合。
- 障害時リカバリ・サイトが定期的に検証される場合。
rsyncを使用してファイル・システム・アーティファクトをレプリケートする方法の詳細は、「ピアツーピア・ファイル・コピーの使用」を参照してください。
親トピック: ストレージ・レプリケーションの設定
Oracle Database File System,
Oracle Database File System (DBFS)は、構成のレプリケートに使用できる補助的な方法です。概念的には、データベース・ファイルシステムは、データベース表に格納されているファイルおよびディレクトリの最上部に配置されたファイルシステム・インタフェースです。
DBFSは、ローカル・ファイルシステムと類似した共有ネットワーク・ファイルシステムを提供し、サーバー・コンポーネントとクライアント・コンポーネントの両方を持つ点で、NFSプロトコルと類似しています。DBFSファイル・システムは、中間層ホストからマウントし、通常の共有ファイル・システムとしてアクセスできます。コンテンツをレプリケートするための中間の場所として使用できます: DBFSマウントにコピーされたコンテンツは、データベース内に存在するため、基礎となるData Guardレプリケーションを介してスタンバイ・サイトに自動的にレプリケートされます。
この方法では、Data Guardレプリカの堅牢性を活用できます。Oracleドライバの再試行ロジックにより可用性が高く、回復可能な動作を提供します。データ・センター間の待機時間が中または高であるシナリオで使用できます。ただし、構成レプリケーションにDBFSを使用すると、設定、データベース・ストレージおよびライフサイクルの観点から、さらなる影響があります:
- DBFSマウントに必要な構成およびメンテナンスのために、若干の複雑さが生じます。マウントするホストにDBクライアントをインストールする必要があり、データベース(表領域、ユーザーなど)およびクライアント(ウォレット、
tnsnames.oraなど)で初期設定が必要なアーティファクトがいくつかあります。(アプリケーションDR共通スクリプトの使用にある)スクリプトdbfs_dr_setup_root.shをサンプル・スクリプトとして参照してください(データベース・クライアントのインストール、データベースへのDBFSスキーマの作成、クライアント・アーティファクトの構成、中間層ホストへのDBFSファイル・システムのマウントが行われています)。 - DBFSマウントにコピーされたコンテンツはデータベースに格納されるため、データベースに追加の容量が必要です。
- ドメイン構成またはバイナリを、DBFSマウントに直接格納することはお薦めしません。これにより、FMWファイルとデータベースの間に非常に強い依存関係が作成されます。かわりに、DBFSを「アシスタンス」ファイル・システムとして使用することをお薦めします: これは、スタンバイ・サイトにレプリケートされる情報を配置するための中間ステージング・ファイル・システムです。スタンバイへのレプリケーションには2つのステップがあります: プライマリのオリジン・フォルダから中間のDBFSマウントへ、そしてスタンバイ・サイトではDBFSマウントからスタンバイの宛先フォルダへ、となります。
- DBFSは、データベースがオープンされている場合にのみマウントできます。Data GuardがActive Data Guard (ADG)ではない場合、スタンバイ・データベースはマウント状態です。したがって、このような場合にスタンバイ・サイトでDBFSマウントにアクセスするには、データベースをスナップショット・スタンバイに変換する必要があります。ただし、ADGを使用する場合、ファイル・システムを読取り用にマウントできるため、スナップショットに遷移する必要はありません。
前述の理由により、すべてのアーティファクトをスタンバイにレプリケートするための汎用ソリューションとしてこの方法を使用することはお薦めしません。たとえば、バイナリをレプリケートするためにDBFSを使用することは過剰です。ただし、この方法は、ストレージ・レプリケーションやrsyncなどの他の方法が実行できない場合に、ドメイン共有構成など、ライフサイクル中にいくつかの動的アーティファクトをレプリケートする際には適しています。DBFSを使用してドメイン構成をレプリケートする方法の例は、『Oracle WebLogic Server for Oracle Cloud Infrastructureの障害時リカバリ』のペーパーを参照してください。
親トピック: ストレージ・レプリケーションの設定
FMWデータベース用のOracle Data Guardの構成
Oracle SOA Suiteエンタープライズ・デプロイメントでFMWデータベース用のOracle Data Guardをインストールおよび構成する方法を学習します。
Oracle Fusion Middleware障害時リカバリ・トポロジで使用されるOracle Databaseの設定に関する推奨事項と考慮事項は、「データベースに関する考慮事項」を参照してください。
Oracle Maximum Availability Architecture (MAA)は、計画停止の停止時間を短縮し、計画外停止を防止、検出およびリカバリするOracleの包括的なアーキテクチャです。
Real Application Clusters (RAC)およびData Guardは、プライマリ・サイトにRACデータベースが含まれ、セカンダリ・サイトにRAC物理スタンバイ・データベースが含まれるデータベースMAAソリューションの基礎を提供します。
ヒント:
また、この項のタスクの多くはOracle Enterprise Manager Cloud Controlを使用して実行することもできます。
Cloud Controlを使用したデータベースの設定および管理は、ダウンタイムの制御および障害時リカバリ操作の簡略化に役立ちます。
Enterprise Manager Cloud Control 13cのインストールの詳細は、『Cloud Control基本インストレーション・ガイド』を参照してください。
Cloud Controlを使用したOracle Data Guardの設定の詳細は、『Oracle Enterprise Managerライフサイクル・マネージメント管理者ガイド』のOracleスタンバイ・データベースのプロビジョニングに関する項を参照してください。
- 前提条件
- Oracle Data Guard環境の説明
- Data Guardの構成手順
- Data Guard Broker構成の検証
- データベースのスイッチオーバーおよびスイッチバックのテスト
データベースのスイッチオーバーおよびスイッチバックを実行できます。
親トピック: サイトの設定
前提条件
次の前提条件が満たされていることを確認してください。
-
スタンバイ・サイトのOracle RACクラスタおよび自動ストレージ管理(ASM)インスタンスが作成済です。
-
スタンバイ・サイトおよび本番サイトのOracle RACデータベースでフラッシュ・リカバリ領域を使用しています。
-
Oracle RACデータベースが
archivelogモードで実行されています。 -
スタンバイ・サイトのデータベース・ホストにOracleソフトウェアがすでにインストールされています。
-
共有
ORACLE_HOME構成では、TNS_ADMINディレクトリはローカルの非共有ディレクトリである必要があります。
Oracle Data Guard環境の説明
この項で示す例には、表3-3で説明する環境変数が含まれています。
表3-3 プライマリおよびスタンバイ・データベースで使用される変数
| 変数 | プライマリ・データベース | スタンバイ・データベース |
|---|---|---|
|
データベース名 |
|
|
|
SOAデータベースのホスト名 |
|
|
|
データベースの一意の名前 |
|
|
|
インスタンス名 |
|
|
|
サービス名 |
|
|
Data Guardの構成手順
Data Guardの構成には、いくつかのステップがあります: 推奨パラメータを使用してプライマリ・データベースを準備する、プライマリ環境とスタンバイ環境でTNS別名を準備する、プライマリ・データベースの複製としてフィジカル・スタンバイ・データベースを作成する、Data Guard Brokerを構成する、などです。
Oracleには、これらのアクションのほとんどを自動化するために使用できる一連のサンプル・スクリプトが用意されています。これらのスクリプトは、https://github.com/oracle-samples/maa/raw/main/dg_setup_scripts/dg_setup_scripts.zipから入手できます。これらのスクリプトは、サービスからのリストア機能およびData Guard Brokerを使用して、既存のプライマリ・データベースのスタンバイ・データベースを設定するように設計されています。カスタマイズが可能です(OSユーザー名とOracleホームは構成可能な値です)。TDE暗号化の有無にかかわらずデータベースをサポートし、読取り専用Oracleホーム(ROOH)または通常のOracleホームを使用した環境で動作します。スクリプトは、12c (12.2)、18c、19cおよび21cのRDBMSバージョンで検証されます。ファイルをダウンロードし、README.mdに記載されている手順に従って、スタンバイ・データベースを構成します。
スクリプトが特定の環境で実行できない場合は、次のいずれかのドキュメントに従ってData Guardを手動で構成できます:
- Creating a Physical Standby database using RMAN restore database from service (ドキュメントID 2283978.1)
- RMAN複製を使用した物理スタンバイの作成(RACまたはRAC以外) (ドキュメントID 1617946.1)
ノート:
前述のドキュメントは、My Oracle Supportにあります。Data Guard Broker構成の検証
次のステップを実行して、Data Guard Broker構成が正常に作成されたことを確認します。
例3-1 Data Guard Broker構成の検証
[oracle@dbhost1 ~]$ dgmgrl sys/'<password>' DGMGRL for Linux: Release 19.0.0.0.0 - Production on Tue Feb 1 09:00:16 2022 Version 19.6.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected to "soa_pri" Connected as SYSDBA. DGMGRL> show configuration Configuration - dg_config Protection Mode: MaxPerformance Databases: soa_pri - Primary database soa_stby - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
データベースのスイッチオーバーおよびスイッチバックのテスト
データベースのスイッチオーバーおよびスイッチバックを実行できます。
Oracle Data Guard Brokerを使用したスイッチオーバー操作の実行
Oracle Data Guard Brokerを使用してスイッチオーバー操作を実行するには、次のタスクを完了します。
-
次のコマンドを実行して、Oracle Data Guard Broker構成を確認します:
DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Databases: soa_pri - Primary database soa_stby - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
-
SWITCHOVERコマンドを実行して、プライマリおよびスタンバイ・データベースのロールをスワップします。例3-1に、Data Guard Brokerが、古いプライマリ・データベースの停止および再起動を、スイッチオーバー操作の一部として自動的に実行する方法を示します。DGMGRL> switchover to 'soa_stby' Performing switchover NOW, please wait... Operation requires a connection to database "soa_stby" Connecting ... Connected to "soa_stby" Connected as SYSDBA. New primary database "soa_stby" is opening... Oracle Clusterware is restarting database "soa_pri" ... Connected to "soa_pri" Connected to "soa_pri" Switchover succeeded, new primary is "soa_stby"
-
スイッチオーバーの完了後、
SHOW CONFIGURATIONコマンドを使用して、スイッチオーバー操作が正常終了したかどうかを検証します。DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Databases: soa_stby - Primary database soa_pri - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
ノート:
Oracle Data Guard Brokerのスイッチオーバーおよびフェイルオーバー操作の詳細は、『Oracle Data Guard Broker』のスイッチオーバーおよびフェイルオーバー操作に関する項を参照してください。
Oracle SOAエンタープライズ・トポロジでの本番サイトの作成
Oracle SOAエンタープライズ・デプロイメント・トポロジで本番サイトを作成する方法を学習します。
本番サイトを作成する前に:
-
「ホスト名の計画」の説明に従って、中間層ホストのホスト名別名を設定します。
-
「ディレクトリ構造とボリュームの設計」の説明に従って、本番サイトの共有ストレージに必要なボリュームを作成します。
-
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定します。
この項には次のトピックが含まれます:
- 本番サイトの作成
この項では、Oracle SOA Suiteトポロジの本番サイトの作成方法について説明します。 - Oracle Fusion Middlewareアクティブ-パッシブ・デプロイメントのデータ・ソースの構成
Oracle Fusion Middlewareがアクティブ・パッシブ型障害時リカバリに使用するデータ・ソースを構成します。
親トピック: 障害時リカバリ・サイトの設定と管理
本番サイトの作成
この項では、Oracle SOA Suiteトポロジの本番サイトの作成方法について説明します。
異なるトポロジの本番サイトを作成する場合は、Install a Production Environment: Plan, Install & Configure an Enterprise Deploymentカテゴリに記載されている適切なOracle Fusion Middlewareのエンタープライズ・デプロイメント・ガイドを参照してください。
『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従って、本番サイトをインストールおよび構成します。
次の項で、本番サイトのインストールおよび構成を実行する方法について説明します。
- ボリュームおよびコンシステンシー・グループの作成
共有ストレージ・デバイスでボリュームおよびコンシステンシー・グループを作成します。 - 物理ホスト名およびホスト名別名の設定
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。 - Oracle SOA Suiteのインストールおよび構成
Oracle SOA Suiteをインストールおよび構成します。
ボリュームおよびコンシステンシー・グループの作成
共有ストレージ・デバイスでボリュームおよびコンシステンシー・グループを作成します。
共有ストレージ・デバイスにボリュームおよびコンシステンシー・グループを作成するには、 「Oracle SOA Suiteに推奨されるボリューム設計」を参照してください。
親トピック: 本番サイトの作成
物理ホスト名およびホスト名別名の設定
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。
本番サイトおよびスタンバイ・サイトのホスト名の計画の詳細は、「ホスト名の計画」を参照してください。
親トピック: 本番サイトの作成
Oracle SOA Suiteのインストールおよび構成
Oracle SOA Suiteをインストールおよび構成します。
Oracle SOA Suiteをインストールおよび構成するには、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照し、次の変更を適用してください。
- 共有ストレージ・デバイス上に作成したボリュームにOracle SOA Suiteコンポーネントをインストールします。
- 物理および仮想ホスト名の別名を使用して、本番およびスタンバイ・サイトを設定します。
- ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
親トピック: 本番サイトの作成
Oracle Fusion Middlewareアクティブ-パッシブ・デプロイメントのデータ・ソースの構成
Oracle Fusion Middlewareがアクティブ-パッシブ型障害時リカバリに使用するデータ・ソースを構成します。
「中間層のデータソースの設定」で説明されているように、各サイトのローカル・データベースにアクセスするために、データ・ソースでTNS別名を使用することをお薦めします。TNS別名の名前は、本番とスタンバイで同じです。したがって、データ・ソースは同じdb接続文字列を使用します。TNS別名は、WebLogicドメイン構成とは別に格納されているtnsnames.oraファイルで解決され、サイト間でレプリケートされません。したがって、tnsnames.oraの内容はサイトごとに異なる可能性があります。各サイトでは、ローカル・データベースのみを指す、サイトごとに適切な接続文字列を使用して、TNS別名を解決します。
アクティブ-パッシブ・デプロイメント・アプローチのもう1つの利点は、WebLogicサーバーを再起動したりWebLogicサーバーのデータ・ソースを再起動しなくても、tnsnames.oraファイルの変更(再試行やタイムアウトなど)を実行できることです。同時に、このアプローチでは、通常は多くのデータ・ソース間で共有されるアドレスと設定の繰返しが減るため、構成の作成および保守のフットプリントが減少します。
本番システムでこのアプローチをまだ使用していない場合は、次のステップを使用して構成できます。ドメインで使用されているすべてのデータソース(JDBC永続性ストアで使用されているデータ・ソース、リース・データ・ソースおよびカスタム・データ・ソースを含む)、およびOPSSセキュリティ・ストアのJDBC URLで、tns別名を構成します。
-
すべての中間層ホストに
tnsフォルダを作成します。このフォルダは、Oracleユーザーが読取り可能で、サイト間でレプリケートされないファイル・システムに配置する必要があります。
たとえば:mkdir -p /home/oracle/tnsnames_dirtnsフォルダが構成の一部である場合は、すべてのサーバーで共有されるconfigフォルダの下に作成することもできます。ただし、その場合は、ドメイン構成をプライマリからスタンバイにコピーするとき、またはスタンバイ・システムのtnsnames.oraを更新するときに、必ずtnsフォルダを除外して、フェイルオーバーまたはスイッチオーバー後にセカンダリ・データベースを指すようにしてください。ノート:
このフォルダは、本番とスタンバイの両方の中間層ホストに作成します。 -
データ・ソースで使用される
tns別名を使用して、tnsフォルダにtnsnames.oraファイルを作成します。本番の中間層ホストでは、別名は本番データベースを指している必要があります。たとえば:
SOAEDG= (DESCRIPTION= (ADDRESS_LIST= (LOAD_BALANCE=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)) ) (CONNECT_DATA=(SERVICE_NAME=soaedg.example.com)) )スタンバイ中間層ホストでは、別名は同じ名前ですが、スタンバイ・データベースを指しています。
たとえば:
SOAEDG= (DESCRIPTION= (ADDRESS_LIST= (LOAD_BALANCE=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)) ) (CONNECT_DATA=(SERVICE_NAME=soaedg.example.com)) )追加のデータベースまたはサービスに接続する場合は、適切な
tns別名も追加してください。 -
tnsnames.oraファイルのディレクトリの場所を指すoracle.net.tns_adminプロパティを指定します。次のいずれかの方法を使用します。ノート:
これらの方法を混在させないでください。予期しない動作が発生する可能性があります。オプション1: プロパティをデータ・ソース接続プロパティとして設定します。この方法をお薦めします。
データ・ソース構成で
oracle.net.tns_admin=tns_directoryプロパティを指定します。このプロパティをWebLogic管理コンソールで指定するには、「サービス」に移動し、「データ・ソース」をクリックしてリストからデータ・ソースを選択し、「接続プール」をクリックして「プロパティ」テキスト・ボックスにそれを追加します。データ・ソースごとにこのステップを繰り返します。たとえば:
次のプロパティを「プロパティ」テキスト・ボックスに追加します:oracle.net.tns_admin=/home/oracle/tnsnames_dirこのプロパティは、
$ASERVER_HOME/config/fmwconfigフォルダで使用可能なOPSSセキュリティ・ストア・ファイルjps-config-jse.xmlおよびjps-config.xmにも指定する必要があります。これらのjpsファイルを変更するには、ファイルを編集し、jdbc.urlプロパティの後にoracle.net.tns_adminプロパティを追加します。たとえば:… <property name="jdbc.url" value="jdbc:oracle:thin:@soaedg"/> <property name="oracle.net.tns_admin" value="tns_directory"/> …ノート:
このプロパティは、それが指定されている特定のファイル(データ・ソース、jpsファイル)に適用されます。オプション2: プロパティをjavaシステム・プロパティとして設定します。
-Doracle.net.tns_admin=tns_directoryシステム・プロパティを指定します。ここで、tns_directoryは、tnsnames.oraファイルのディレクトリの場所です。これをサーバーのjavaプロパティとして設定するには、次のファイルを編集します:$ASERVER_HOME/bin/setUserOverrides.sh$MSERVER_HOME/bin/setUserOverrides.sh(このファイルは共有されません。したがって、すべてのSOA中間層ホストのファイルを編集する必要があります。)
これらのファイルに次の内容を追加します:# For using tns alias in the datasources export EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Doracle.net.tns_admin=/home/oracle/tnsnames_dirノート:
- このプロパティは、WebLogic Server内のすべてのデータ・ソースおよび
jpsファイルに適用されます。 - このアプローチでは、一部のWLSTコマンドおよび構成ウィザードを実行する前に、環境内にプロパティを設定する必要があります。WLSTを実行する前に、WLST_PROPERTIES環境変数にプロパティを設定する必要があります。構成ウィザードを実行する前に、
config_internal.shスクリプトのJVM_ARGS環境変数にプロパティを追加する必要があります。
オプション3:
jdbcURLにプロパティを設定します。データ・ソースおよびjpsファイル内で接続文字列の一部として、tnsnames.oraファイルの場所を指定します:jdbc:oracle:thin:@alias?TNS_ADMIN=tns_directoryノート:
- このプロパティは、それが指定されている特定のファイル(データ・ソース、
jpsファイル)に適用されます。 - この方法は、JDBCドライバ18.3以降で使用できます。これは、(JDBCドライバ19.3を使用する) Fusion Middleware 12.2.1.4以降のバージョンに適用されます。
-
接続文字列を別名に置き換えることで、データソースに定義されているURLを変更します。次に、
tnsaliasjdbc:oracle:thin:@soaedgを使用したJDBC URLの例を示します。この変更を実行するには、WebLogic管理コンソールを使用できます。または、ここで説明するように、ファイルで直接変更を実行することもできます:APPHOST1にサインインします。- データ・ソース構成ファイルを含む
$ASERVER_HOME/config/jdbcのバックアップを取ります。 - 以前のデータベース接続文字列を、
tns別名を使用する新しい文字列に置き換えるコマンドを実行します。たとえば:cp -rf $ASERVER_HOME/config/jdbc $ASERVER_HOME/config/jdbc_bck export PREV_STRING='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com)))' export NEW_STRING='soaedg' cd $ASERVER_HOME/config/jdbc find . -name '*.xml' | xargs sed -I 's|'${PREV_STRING}'|'${NEW_STRING}'|gI'
- 次のステップを使用して、OPSSセキュリティ・ストアのJDBC URLも更新します:
APPHOST1にサインインし、$ASERVER_HOME/config/fmwconfigフォルダに移動します。-
jps-config-jse.xmlおよびjps-config.xmlファイルのバックアップを取ります。 - 両方のファイルを編集して、
property name="jdbc.url"の値を、データ・ソースで使用される適切なJDBC URLで更新します。たとえば:cp -rf $ASERVER_HOME/config/fmwconfig $ASERVER_HOME/config/fmwconfig_bck cd $ASERVER_HOME/config/fmwconfig export PREV_STRING='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com)))' export NEW_STRING='soaedg' find . -name '*.xml' | xargs sed -i 's|'${PREV_STRING}'|'${NEW_STRING}'|gI'
-
変更を有効にするために、ドメイン内のすべてのWebLogic Serverを再起動します。
- ドメイン内のすべてのWebLogic Server (管理サーバーおよび管理対象サーバー)を停止します。
- ドメインの管理サーバーを起動します。
- 管理対象サーバーを起動します。
-
データベースとのデータ・ソース接続が正しく確立されていることを確認します。
OPSSストアでJDBC URLが正しく更新されていることを確認します。これを検証するには:- Enterprise Managerコンソールに移動します。
- 「WebLogicドメイン」に移動して「セキュリティ」を選択し、「セキュリティ・プロバイダ構成」をクリックします。
- 「セキュリティ・ストア」を展開し、「データベースURL」が更新されていることを確認します。
ノート:
データ・ソースのONSホストおよびポートの構成については、Oracle Database 12c以降を使用している場合、ONSリストはクライアント・ドライバによってデータベースから自動的に取得されるため、これらの値は必要ありません。
このガイドのOracleの一貫した推奨事項に従って、各データ・ソースのONS構成でスキャン・アドレスまたはRACノードのリストを指定するかわりに、この機能を使用してください。
高速アプリケーション通知(FAN)が有効になっていること、および各データ・ソースで「ONSノード」プロパティが空になっていることを確認します。WebLogic管理コンソールでこのプロパティを確認するには、「サービス」に移動し、「データ・ソース」をクリックして「構成」を選択し、「ONS」をクリックします。
スタンバイ・サイトの作成
スタンバイ・サイトを作成する方法を学習します。
スタンバイ・サイトを作成するために、Oracle SOAエンタープライズ・デプロイメント・トポロジを例として使用します。
この項には次のトピックが含まれます:
- スタンバイ・サイトの準備
スタンバイ・サイトで操作できるように準備します。 - スタンバイ・サイトの設定の検証
スタンバイ・サイトを検証します。
親トピック: 障害時リカバリ・サイトの設定と管理
スタンバイ・サイトの準備
スタンバイ・サイトで操作できるように準備します。
スタンバイ・サイトで操作できるように準備するには、次のようにします。
-
「ホスト名の計画」の手順に従って、ホスト名別名および物理ホスト名を正しく設定します。
スタンバイ・サイトの各ホストに、本番サイトのピア・ホストの物理ホスト名と同じホスト名別名が設定されていることを確認してください。
-
共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します
-
本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。ただしシンボリック・リンクが必要なのは、複数のボリュームにわたって、一貫したレプリケーションがストレージ・システムで保証されていない場合のみです。
シンボリック・リンクの詳細は、「ストレージの設定」を参照してください。
- 中間層のホストの設定
スタンバイ・サイトの中間層ホストでは、Oracle Fusion MiddlewareやOracle WebLogic Serverソフトウェアのインストールや構成を行う必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトにインストールされているソフトウェアがスタンバイ・サイトにレプリケートされます。 - スタンバイ・サイトの自己署名証明書およびキーについて
証明書およびキーストアについて学習します。
親トピック: スタンバイ・サイトの作成
中間層のホストの設定
スタンバイ・サイトの中間層ホストでは、Oracle Fusion MiddlewareやOracle WebLogic Serverソフトウェアのインストールや構成を行う必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトにインストールされているソフトウェアがスタンバイ・サイトにレプリケートされます。
スタンバイ・サイトの中間層ホストを設定するには:
- 本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、ストレージ・デバイス間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。
- 本番サイトの共有ストレージをスタンバイ・サイトの共有ストレージと同期します。これによって、本番サイトからスタンバイ・サイトに初期のベースライン・スナップショットが転送されます。
- スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。
- ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。
親トピック: スタンバイ・サイトの準備
スタンバイ・サイトの自己署名証明書およびキーについて
証明書およびキーストアについて学習します。
「ホスト名の計画」で推奨されているように、FMWコンポーネントは、各サイトの適切なシステムのIPアドレスに解決可能なホスト名別名を使用します。これらのホスト名を使用してプライマリ自己署名証明書を作成する場合、証明書は本番システムとスタンバイ・システムの両方で有効です。
プライマリ自己署名証明書の作成の詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のエンタープライズ・デプロイメントの共通の構成および管理タスクに関する項を参照してください。
証明書およびキーストアは構成とともにスタンバイにレプリケートされるため、スタンバイ・サイト用に特定の自己署名証明書またはキーストアを作成する必要はありません。
親トピック: スタンバイ・サイトの準備
スタンバイ・サイトの設定の検証
スタンバイ・サイトを検証します。
スタンバイ・サイトを検証するには:
- 本番サイトで実行中のプロセスを停止します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。
- 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。
- スイッチバック操作を実行します。スイッチバックは、スイッチオーバー操作の後にデータベースのロールを元の状態に戻す操作です。
- スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これらには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。
- ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。
親トピック: スタンバイ・サイトの作成
サイトの操作および管理の実行
Oracle Fusion Middleware障害時リカバリ・トポロジを操作および管理する方法を学習します。
この項には次のトピックが含まれます:
- 本番サイトおよびスタンバイ・サイトの同期化
本番サイトで中間層の変更を導入した場合に、本番サイトとスタンバイ・サイトの同期化を強制的に実行する方法を確認します。 - スイッチオーバーの実行
スイッチオーバー操作は、スタンバイ・サイトを本番ロールとして設定します。 - スイッチバックの実行
スイッチバック操作は、現在の本番サイトとスタンバイ・サイトのロールを元に戻します。 - フェイルオーバーの実行
フェイルオーバー操作は、本番サイトが使用できなくなった場合に、スタンバイ・サイトを本番ロールとして設定します。 - スタンバイ・サイトのテスト
読取り専用のスタンバイ・サイト共有ストレージのクローンを作成し、これを使用してデータベースsecondary_db_unqnameをスナップショット・スタンバイに変換する方法を学習します。 - ピアツーピア・ファイル・コピーの使用
rsyncユーティリティ(ピアツーピア・ファイル・コピーを使用)は、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイト・ホストからスタンバイ・サイト・ピア・ホストに中間層のファイル・システム・データをレプリケートするために使用できます。rsyncユーティリティの使用は、対称トポロジのコンテキストで説明されています。
親トピック: 障害時リカバリ・サイトの設定と管理
本番サイトおよびスタンバイ・サイトの同期化
本番サイトで中間層の変更を導入した場合に、本番サイトとスタンバイ・サイトの同期化を強制的に実行する方法を学習します。
通常の操作では、スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。
本番サイトで中間層の変更を導入した場合(本番サイトに新しいアプリケーションをデプロイした場合など)、同期化を強制的に実行します。ストレージ・レプリケーション・テクノロジを使用して同期化を強制的に実行するには、ベンダー固有の手順に従ってください。
Oracle Fusion Middleware障害時リカバリ・トポロジでのデータベースの同期化は、Oracle Data Guardによって管理されます。
親トピック: サイトの操作および管理の実行
スイッチオーバーの実行
スイッチオーバー操作は、スタンバイ・サイトを本番ロールとして設定します。
本番サイトを停止したり(メンテナンスを実行する場合など)、現在のスタンバイ・サイトを本番サイトにすることを計画している場合に、この操作が必要になります。
スイッチオーバー操作を実行するには:
これで、前のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトでメンテナンスを実行できるようになりました。元の本番サイトでメンテナンスを実行した後、将来、そのサイトを本番サイトとしてもスタンバイ・サイトとしても使用できます。
ノート:
このノートはBI固有のシステムにのみ適用されます。
スイッチオーバー操作後、CDSでEssbaseキューブを作成すると、次のようなエラーで失敗する可能性があります。
oracle.essbase.cds.util.CDSException: oracle.essbase.cds.util.CDSException: java.sql.SQLException: ORA-25153:
-
次のようなselect文を使用して一時表領域を指定します(ここで、
BIS17V1はOracle Business Intelligence RCU接頭辞です)。select username,temporary_tablespace from dba_users where username like 'BIS17V1%'前述のコマンドを実行すると、次のような一時表領域のリストが返されます。
USERNAME.....TEMPORARY_TABLESPACEBIS17V1_IAU_VIEWER.....BIS17V1_IAS_TEMPBIS17V1_STB.....BIS17V1_IAS_TEMPBIS17V1_IAU_APPEND.....BIS17V1_IAS_TEMPBIS17V1_MDS.....BIS17V1_IAS_TEMPBIS17V1_IAU.....BIS17V1_IAS_TEMPBIS17V1_BIPLATFORM......BIS17V1_IAS_TEMPBIS17V1_OPSS.....BIS17V1_IAS_TEMP -
スイッチオーバー後、内容およびデータファイルも含め、表領域
BIS17V1_IAS_TEMPが削除されます。 -
一時表領域
BIS17V1_IAS_TEMPを一時ファイルとして、(たとえば)/work/primy/oradata/stnby/BIS17V1_IAS_TEMP.dbfの場所に250MBのサイズで作成します。 -
次のように、(一時表領域のリストを使用する場所で)alterコマンドを発行します。
alter user BIS17V1_OPSS temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_BIPLATFORM temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_IAU temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_MDS temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_IAU_APPEND temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_STB temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_IAU_VIEWER temporary tablespace BIS17V1_IAS_TEMP ;
元の本番サイトを本番サイトとして使用するには、「スイッチバックの実行」の説明に従って、スイッチバックを実行します。
親トピック: サイトの操作および管理の実行
フェイルオーバーの実行
フェイルオーバー操作は、本番サイトが使用できなくなった場合に、スタンバイ・サイトを本番ロールとして設定します。
フェイルオーバー操作を実行するには:
ノート:
フェイルオーバー操作後、CDSでEssbaseキューブを作成すると、次のようなエラーで失敗する可能性があります。oracle.essbase.cds.util.CDSException: oracle.essbase.cds.util.CDSException: java.sql.SQLException: ORA-25153:
-
次のようなselect文を使用して一時表領域を指定します(ここで、
BIS17V1はOracle Business Intelligence RCU接頭辞です)。select username,temporary_tablespace from dba_users where username like 'BIS17V1%'前述のコマンドを実行すると、次のような一時表領域のリストが返されます。
USERNAME.....TEMPORARY_TABLESPACEBIS17V1_IAU_VIEWER.....BIS17V1_IAS_TEMPBIS17V1_STB.....BIS17V1_IAS_TEMPBIS17V1_IAU_APPEND.....BIS17V1_IAS_TEMPBIS17V1_MDS.....BIS17V1_IAS_TEMPBIS17V1_IAU.....BIS17V1_IAS_TEMPBIS17V1_BIPLATFORM......BIS17V1_IAS_TEMPBIS17V1_OPSS.....BIS17V1_IAS_TEMP -
フェイルオーバー後、内容およびデータファイルも含め、表領域
BIS17V1_IAS_TEMPが削除されます。 -
場所内の一時ファイルとして、一時表領域
BIS17V1_IAS_TEMPを作成します。たとえば、サイズ250 mで/work/primy/oradata/stnby/BIS17V1_IAS_TEMP.dbfです。 -
次のように、(一時表領域のリストを使用する場所で)alterコマンドを発行します。
alter user BIS17V1_OPSS temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_BIPLATFORM temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_IAU temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_MDS temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_IAU_APPEND temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_STB temporary tablespace BIS17V1_IAS_TEMP ;alter user BIS17V1_IAU_VIEWER temporary tablespace BIS17V1_IAS_TEMP ;
元の本番サイトを本番サイトとして再度使用するには、「スイッチバックの実行」の説明に従って、スイッチバックを実行します。
親トピック: サイトの操作および管理の実行
スタンバイ・サイトのテスト
読取り専用のスタンバイ・サイト共有ストレージのクローンを作成し、これを使用してデータベースsecondary_db_unqnameをスナップショット・スタンバイに変換する方法を学習します。
通常のOracle Fusion Middleware障害時リカバリ構成では、次のものを使用します。
-
ストレージ・レプリケーション。これを使用して、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージにOracle Fusion Middlewareの中間層のファイル・システムおよびデータをコピーします。通常の操作時には、本番サイトはアクティブで、スタンバイ・サイトはパッシブです。本番サイトがアクティブな場合、スタンバイ・サイトはパッシブで、スタンバイ・サイトの共有ストレージは読取り専用モードです。スタンバイ・サイトの共有ストレージに対して行われる書込み操作は、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージへのストレージ・レプリケーション操作のみです。
-
Oracle Data Guard。これを使用して本番サイトのOracle Databaseのデータベース・データをスタンバイ・サイトのスタンバイ・データベースにコピーします。デフォルトでは、本番サイトのデータベースはアクティブで、スタンバイ・サイトのスタンバイ・データベースはパッシブです。スタンバイ・サイトがスタンバイ・ロールの間(パッシブである間)、スタンバイ・サイトのスタンバイ・データベースは管理リカバリ・モードです。本番サイトがアクティブな場合、スタンバイ・データベースに対して行われる書込み操作は、Oracle Data Guardによって実行されるデータベースの同期操作のみです。
-
スタンバイ・サイト。本番サイトが使用できなくなった場合に、これを本番ロールとして使用します。現在の本番サイトが予期せず使用できなくなった場合は、フェイルオーバー操作(「フェイルオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。また、現在の本番サイトを意図的に停止する場合は(予定したメンテナンスの場合など)、スイッチオーバー操作(「スイッチオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。
通常の方法でスタンバイ・サイトをテストする場合は、現在の本番サイトを停止し、スイッチオーバー操作を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。
ただし、企業では、現在の本番サイトおよび完全なスイッチオーバー操作を停止することなく、障害時リカバリのスタンバイ・サイトの定期テストを実行することもできます。これは、スタンバイ・データベースをスナップショット・スタンバイに変換することで可能になります。これにより、スタンバイ・サーバーをスタンバイ・サイトで起動し、セカンダリ・システムを検証できます。スナップショット・スタンバイ・モード中にスタンバイ・サイト・データベースで実行された変更は、再度フィジカル・スタンバイに変換されると破棄されるため、プライマリ・データはセカンダリ・サイトの検証の影響を受けません。
このテスト方法を使用するには:
-
共有ストレージ・ベンダーが提供しているクローニング・テクノロジを使用して、スタンバイ・サイトの共有ストレージでスタンバイ・サイトの読取り専用ボリュームのクローンを作成します。クローニングされたスタンバイ・サイトのボリュームが書込み可能であることを確認します。スタンバイ・サイトを1回のみテストする場合、これは1回かぎりのクローン操作にできます。ただし、スタンバイ・サイトを定期的にテストする場合は、スタンバイ・サイトの読取り専用ボリュームの、スタンバイ・サイトの読取り/書込みクローン・ボリュームへの定期的クローニングを設定できます。
-
次のステップで、スタンバイ・データベースをスナップショット・スタンバイに変換します:
-
プライマリ・データベース・ホストでData Guard Brokerを使用して、セカンダリ・データベースをスナップショット・スタンバイに変換します。
例:
[oracle@primarydbhost~]$dgmgrl sys/your_sys_password@primary_db_unqname DGMGRL> convert database “secondary_db_unqname” to snapshot standby -
show configurationコマンドを使用して、変換が正しく実行されたことを確認します。
-
-
スタンバイ・サイトのコンピュータで、次のステップに従って、スタンバイ・サイトのクローニングされた読取り/書込み共有ストレージ・ボリュームを指すようにmountコマンドを変更します。
-
読取り専用の共有ストレージ・ボリュームをアンマウントします。
-
クローニングされた読取り/書込みボリュームを同じマウント・ポイントでマウントします。
-
-
スタンバイ・サイトをテストする前に、ホスト名が本番サイトのコンピュータではなくスタンバイ・サイトのコンピュータを指すように、テストの実行に使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、スタンバイ・サイトのロード・バランサの仮想IPを指すように
/etc/hostsファイルを変更します。 -
スタンバイ・サイトのテストを実行します。
ノート:
この操作は、SOA環境では注意して実行する必要があります: スナップショットに変換された時点でデータベースに保留中のメッセージまたはコンポジットがある場合、スタンバイ・サイトのSOAサーバーは起動時にそれらを処理します。スナップショット・スタンバイに変換する際に、プライマリ・データベースに保留中のアクションがないことを確認します。そうでない場合は、スナップショット・スタンバイ・データベースへの変換後、セカンダリ・サイトのSOAサーバーの起動前に、スタンバイ・データベースのランタイムSOA表からレコードを削除します。表削除なしでの実行時表からのレコードの削除に関する項を参照してください。スタンバイ・サイトのテストが完了したら、次のステップに従って、元の本番サイトを本番サイトとして再度使用します。
-
スタンバイ・サイトの読取り専用共有ストレージ上のボリュームを指すようにスタンバイ・サイト・コンピュータのmountコマンドを変更します。つまり、mountコマンドを、テストを実行する前の状態にリセットします。
-
クローニングされた共有ストレージの読取り/書込みボリュームをアンマウントします。
-
読取り専用の共有ストレージ・ボリュームをマウントします。
これで、mountコマンドがスタンバイ・サイトのテストを実行する前の状態にリセットされました。
-
-
次のステップで、スタンバイ・データベースをスナップショット・スタンバイに変換します:
-
プライマリ・データベース・ホストでData Guard Brokerを使用して、セカンダリ・データベースをフィジカル・スタンバイに再度変換します。
例:
[oracle@primarydbhost~]$dgmgrl sys/your_sys_password@primary_db_unqname DGMGRL> convert database “secondary_db_unqname” to physical standby -
show configurationコマンドを使用して、変換が正しく実行されたことを確認します。
-
-
元の本番サイトを再度使用する前に、ホスト名がスタンバイ・サイトのコンピュータではなく本番サイトのコンピュータを指すように、本番サイトへのアクセスに使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、本番サイトのロード・バランサの仮想IPを指すように
/etc/hostsファイルを変更します。
親トピック: サイトの操作および管理の実行
ピアツーピア・ファイル・コピーの使用
rsyncユーティリティ(ピアツーピア・ファイル・コピーを使用)は、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイト・ホストからスタンバイ・サイト・ピア・ホストに中間層のファイル・システム・データをレプリケートするために使用できます。rsyncユーティリティの使用は、対称トポロジのコンテキストで説明されています。
障害時リカバリ環境でrsyncを使用するための条件については、このドキュメントの「ストレージ・レプリケーションの設定」のポイント「rsync」を参照してください。
Oracle Fusion Middlewareコンポーネントの障害保護と障害時リカバリの場合、ストレージ・レプリケーションの使用とrsyncユーティリティの使用には多数の類似点があるため、Oracle Fusion Middleware障害時リカバリ・トポロジにおけるOracle Data Guardでのストレージ・レプリケーションを確認してください。
ストレージ・レプリケーション・テクノロジの使用とrsyncユーティリティの使用の次の重要な相違点に注意して、中間層のファイル・システムをレプリケートしてください。
-
ストレージ・レプリケーションの使用時は、本番サイトで前のスナップショットが作成された時点まで変更をロールバックできます。
rsyncユーティリティの使用時は、レプリケートされた本番サイトのデータによってスタンバイ・サイトのデータが上書きされるため、レプリケーションをロールバックすることはできません。 -
ストレージ・レプリケーションの使用時は、共有ストレージ・システムで各ホスト・クラスタについて設定したボリュームによって、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間でそのホスト・クラスタのデータの整合性が保証されます。
rsyncユーティリティの使用時は、データの整合性は保証されません。
この項には次のトピックが含まれます:
- Oracle Fusion Middleware障害時リカバリ・トポロジでのrsyncとOracle Data Guardの使用
Oracle Fusion Middleware障害時リカバリにおいてUNIXrsyncユーティリティおよびOracle Data Guardを使用する方法を確認します。
親トピック: サイトの操作および管理の実行
Oracle Fusion Middleware障害時リカバリ・トポロジでのrsyncとOracle Data Guardの使用
Oracle Fusion Middleware障害時リカバリにおいてUNIX rsyncユーティリティおよびOracle Data Guardを使用する方法を学習します。
ノート:
Oracle Database用のOracle Data Guardの設定方法の詳細は、「データベースに関する考慮事項」を参照してください。
次の項では、rsyncユーティリティおよびOracle Data Guardを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジで本番サイトとスタンバイ・サイト間で保護および強制的に同期化を実行する方法について説明します。
- Oracle Fusion Middleware中間層コンポーネントでのrsyncの使用
UNIXrsyncユーティリティを使用して、Oracle Fusion Middleware中間層コンポーネントを保護およびリカバリします。 - フェイルオーバー操作およびスイッチオーバー操作の実行
rsyncユーティリティの使用時にフェイルオーバーまたはスイッチオーバー操作を実行する方法を確認します。
親トピック: ピアツーピア・ファイル・コピーの使用
Oracle Fusion Middleware中間層コンポーネントでのrsyncの使用
UNIX rsyncユーティリティを使用して、Oracle Fusion Middlewareの中間層コンポーネントを保護およびリカバリします。
rsyncユーティリティを使用するには:
障害時リカバリのためのOracle Site Guardの使用
Oracle Site Guardは障害時リカバリ・ソリューションで、管理者は、サイトの完全なスイッチオーバーやフェイルオーバーを自動化できるようになります。Oracle Fusion Middleware、Oracle Fusion ApplicationsおよびOracleデータベースの調整されたフェイルオーバーを編成します。
Oracle Site Guardには次のような利点があります:
- 障害時リカバリの操作を完全に自動化し、1回のクリックで起動
- 障害時リカバリ時間の最小化
- ヒューマン・エラーの削減
- 柔軟かつカスタマイズ可能
- 特別なスキルが不要
- 単一画面で障害時リカバリを管理
- オンデマンドまたはスケジュール済の障害時リカバリのドリルを使用した、障害時リカバリの準備状況の保証
Oracle Site Guardの使用方法の詳細は、Oracle Site Guard管理者ガイドを参照してください。
親トピック: 障害時リカバリ・サイトの設定と管理
Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用
Oracle Fusion Middlewareパッチ・セットを適用して、Oracle Fusion Middleware障害時リカバリ・サイトに含まれるOracleホームをアップグレードします。
パッチを適用するOracle Fusion MiddlewareインスタンスのOracle中央インベントリが本番サイトの共有ストレージに配置されていて、パッチが適用されたインスタンスのOracle中央インベントリをスタンバイ・サイトにレプリケートできるようになっていることを前提としています。
Oracle Fusion Middlewareのパッチを適用するには:
- 開始時の状態が保持されるように、本番サイトのバックアップを実行します。
- パッチ・セットを適用して、本番サイトのインスタンスをアップグレードします。
- パッチ・セットを適用したら、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージを手動で強制的に同期させます。これによって、本番サイトのパッチが適用されたインスタンスとOracle中央インベントリがスタンバイ・サイトの共有ストレージにレプリケートされます。
- パッチ・セットを適用したら、Oracle Data Guardを使用して、本番サイトとスタンバイ・サイトのOracle Databaseを手動で強制的に同期させます。Oracle Fusion Middlewareの一部のパッチ・セットでは、リポジトリが更新される場合があるため、このステップを必ず実行して、本番サイトのデータベースの変更をスタンバイ・サイトのデータベースに同期させます。
- これでアップグレードは完了です。障害時リカバリ・トポロジで処理を再開できます。
ノート:
パッチは、Oracle Fusion Middleware 12c障害時リカバリ・トポロジの本番サイトでのみ適用する必要があります。Oracle Fusion MiddlewareインスタンスまたはOracle中央インベントリのパッチの場合、本番サイトの共有ストレージがスタンバイ・サイトの共有ストレージにレプリケートされるときに、パッチがコピーされます。本番サイトでパッチをインストールした場合は、同期操作を実行する必要があります。データベースにパッチを適用する場合は、Data Guardトポロジでパッチを適用する方法について、特定のパッチのドキュメントを確認してください。
親トピック: 障害時リカバリ・サイトの設定と管理
DRのシナリオにおけるT3/T3s外部クライアントへのアクセスおよび管理
この項では、ディザスタ・リカバリのシナリオのコンテキストにおいて、外部T3/T3sクライアントにアクセスする方法や管理する方法をいくつか説明します。
ノート:
この項は、T3/T3sサーバーと同じドメインで実行される内部T3/T3sクライアントには適用されません。同じドメイン内のクラスタに接続する場合、内部クライアントは、cluster:t3://cluster_nameなどのT3/T3sクラスタ構文を使用できます。クラスタが同じドメイン内にある場合にのみ、このクラスタ構文を使用できます。
WebLogicでは、Remote Method Invocation (RMI)にT3/T3sプロトコルが使用されます。JMS、EJB、JTA、JNDI、JMX、WLSTなど、複数のWebLogicサービスで使用されます。外部T3/T3sクライアント(T3/T3sサーバーと同じドメインで実行されないクライアント)は、様々な方法でWebLogicクラスタに接続できます。詳細は、WebLogic RMIでのT3プロトコルの使用方法に関する項を参照してください。
外部T3/T3sクライアントは、T3/T3sリクエストをリスニングするWebLogic Serverのチャネル(デフォルトまたはカスタム)に直接接続できます。クライアントのプロバイダ・プロパティに構成された接続URLには、クラスタのすべてのサーバーおよびポートのリストが含まれます。
たとえば:
t3://host1.example.com:9073,host2.example.com:9073外部T3/T3sクライアントは、TCPロード・バランサ(LBR)からもT3/T3sサービスにアクセスできます。このシナリオでは、クライアントのプロバイダURLがロード・バランサのサービスとポートを指し、リクエストはWebLogic ServerのT3/T3sポートにロード・バランシングされます。JNDIコンテキストを取得するために初めて接続する場合、外部クライアントはロード・バランサを介してWebLogic Serverに接続し、スタブをダウンロードします。これらのスタブには、今後のリクエストに使用する接続情報が含まれています。
一般的に、WebLogic T3/T3sはTCP/IPベースであるため、JMSやEJBなど、サービスが同種である場合には、TCPロード・バランシングがサポートされます。たとえば、JMSフロントエンドは、リモートJMSクライアントが任意のクラスタ・メンバーに接続できるWebLogicクラスタに構成できます。これに対して、JTAサブシステムは、複数のWebLogicドメインにまたがるトランザクションで、TCPロード・バランシングを安全に使用することができません。JTAトランザクション・コーディネータは、トランザクションのコミット時またはロールバック時に、トランザクションのサブコーディネータとして機能するサーバー・インスタンスに直接、RMI接続を確立する必要があります。このため、ロード・バランサは通常、JNDI initialContextの作成にのみ使用されます。WebLogic Serverのロード・バランシング・システムは、その後のT3/T3sリクエストを制御しますが、これは、初期コンテキストの入手時に取得したスタブに示されているWebLogic管理対象サーバーのアドレスおよびポート(デフォルトまたはカスタム・チャネル)に接続します。
この項では、すべての通信(最初とその後のリクエストの両方)にロード・バランサを使用する方法も説明します(該当するのは、JTAが使用されていない場合です)。
ノート:
外部クライアントは、HTTP経由のT3トンネリングを使用してT3サービスにアクセスできます。ただし、この方法については、このドキュメントでは説明していません。この方法では、RMIセッションごとにHTTPセッションが作成され、標準のHTTPプロトコルを使用してクライアントとサーバーの間でセッションIDが転送されます。このため、多少のオーバーヘッドが発生するので、あまり使用されません。- T3/T3sサービスにアクセスするための様々な方法
ディザスタ・リカバリのシナリオには、外部T3/T3sクライアントの構成に影響する特殊な側面があります。このトピックでは、外部クライアントからT3/T3sサービスにアクセスする際に利用できるいくつかの方法と、ディザスタ・リカバリのシナリオでそれらを管理する方法を説明します。 - T3/T3sクライアントのDNSキャッシュについて
T3/T3sサービスにアクセスするどの方法でも、通常はDNSの更新が必要です。DNSの更新が必要なため、DNSサーバーとクライアントの特定のキャッシュに存在するDNSキャッシュのTTL (存続時間)制限を設定する必要があります。
親トピック: 障害時リカバリ・サイトの設定と管理
T3/T3sサービスにアクセスするための様々なアプローチ
ディザスタ・リカバリのシナリオには、外部T3/T3sクライアントの構成に影響する特殊な側面があります。このトピックでは、外部クライアントからT3/T3sサービスにアクセスする際に利用できるいくつかの方法と、ディザスタ・リカバリのシナリオでそれらを管理する方法を説明します。
ノート:
これらの方法は、Fusion MiddlewareやPaaSのDRを対象としたMAAガイドラインに準拠するDRのシナリオに適用されるため、セカンダリ・ドメインの構成はプライマリ・システムのミラー・レプリカになります。- デフォルト・チャネルを使用した直接T3/T3s
この方法では、外部T3/T3sクライアントは、WebLogic管理対象サーバーのデフォルト・チャネルに直接接続します。これらのデフォルト・チャネルは、各WebLogic管理対象サーバーの一般的な構成に指定されたリスニング・アドレスおよびリスニング・ポートをリスニングします。 - カスタム・チャネルを使用した直接T3/T3s
この方法では、外部T3/T3sクライアントは、クラスタのWebLogic Serverに定義されているカスタム・チャネルに直接接続します。カスタム・チャネルでは、リスニング・アドレス、外部リスニング・アドレス、外部ポートの値をカスタマイズできます。これらの値は、WebLogic Serverのデフォルトのリスニング値と違っていてもかまいません。 - 最初の参照でのロード・バランサの使用
このシナリオでは、クライアントのプロバイダURLは、ロード・バランサ・サービスを指しています。 - すべてのトラフィックでのロード・バランサの使用
この方法では、最初にコンテキストを参照するときだけでなく、その後の接続でもロード・バランサが使用されます。外部T3/T3sクライアントは、サーバーに直接接続しません。
デフォルト・チャネルを使用した直接T3/T3s
この方法では、外部T3/T3sクライアントは、WebLogic管理対象サーバーのデフォルト・チャネルに直接接続します。これらのデフォルト・チャネルは、各WebLogic管理対象サーバーの一般的な構成に指定されたリスニング・アドレスおよびリスニング・ポートをリスニングします。
図3-5 デフォルト・チャネルを使用した直接T3/T3s
構成
-
T3クライアントのプロバイダURLは、WebLogic Serverのデフォルトのリスニング・アドレスとポートのリストを使用します。
例: 次のDRの例では、WebLogic Serverのリスナー・アドレスはプライマリ・ホスト名です:
t3://soahost1.example.com:8001,soahost2.example.com:8001T3sプロトコルを使用する場合、ポートはサーバーの
SSLリスニング・ポートに設定する必要があります。例:t3s://soahost1.example.com:8002,soahost2.example.com:8002 -
外部クライアントは、これらのホスト名をプライマリホストのIPで解決する必要があります。これらのIPには、クライアントからアクセスできる必要があります。各サーバーにNAT IPアドレスがある場合は、ネットワーク・アドレス変換(NAT)を使用できます。その場合、クライアントは、各サーバーの名前をそのサーバーの適切なNAT IPで解決します。
例: 外部クライアント側でのネーミング解決
これは、
local /etc/hostsまたは正式なDNSサーバー解決でも行うことができます。172.11.2.113 soahost1.example.com 172.11.2.114 soahost2.example.com
スイッチオーバー
スイッチオーバーのシナリオでは、クライアントのプロバイダURLを更新する必要はありません。かわりに、クライアントのDNS (またはクライアントの/etc/hosts)にあるエントリを更新する必要があります。スイッチオーバー後、サーバーへの接続に使用される名前は、セカンダリ・サーバーのIPで解決する必要があります。
172.22.2.113 soahost1.example.com
172.22.2.114 soahost2.example.comメリット
-
サーバー側でもフロントエンド層でも追加の構成は必要ありません。必要なのは、クライアントへのポートを開くことだけです。
デメリット
- スイッチオーバーが発生したら、
DNS (またはクライアントの/etc/hosts)を更新して、外部クライアントが管理対象サーバーへの接続に使用するすべてのホスト名の解決を変更する必要があります。クライアントのキャッシュへの影響の詳細は、「T3/T3sクライアントのDNSキャッシュについて」を参照してください。 - クライアントは、WebLogicの
リスニング・アドレスに設定されているホスト名を解決し、アクセスできる必要があります。デフォルト・チャネルではWebLogic Serverのデフォルトのリスニング・アドレスが使用されるため、代替名は使用できません。 - WebLogicのデフォルト・チャネルは、T3(s)リクエストだけでなく、HTTP(s)もリスニングします。この設定を無効にすることはできません。クライアントのデフォルトのポートを開くと、サーバーにHTTP(s)で直接アクセスすることもできるようになるため、セキュリティの問題が発生する可能性があります。
- WebLogicクラスタのWebLogic Serverノードを追加または削除する必要がある場合は、クライアントのプロバイダURLを変更する必要があります。最初の接続で使用されるのは、クライアントのプロバイダURLのみです。リカバリされたスタブにすべてのメンバーがリストされるため、リストを更新しなくても、その後のリクエストはクラスタの任意のサーバーに接続することが可能です。ただし、クライアントのプロバイダURLがサーバーの実際のリストと一致するため、最初の接続でのフェイルオーバーを目的とする場合には、よい方法です。
親トピック: T3/T3sサービスにアクセスするための様々なアプローチ
カスタム・チャネルを使用した直接T3/T3s
この方法では、外部T3/T3sクライアントは、クラスタのWebLogic Serverに定義されているカスタム・チャネルに直接接続します。カスタム・チャネルでは、リスニング・アドレス、外部リスニング・アドレス、外部ポートの値をカスタマイズできます。これらの値は、WebLogic Serverのデフォルトのリスニング値と違っていてもかまいません。
図3-6 カスタム・チャネルを使用した直接T3/T3s
最初のコンテキストの取得時にT3/T3s外部クライアントがサーバーに接続すると、その後のT3コールは、カスタム・チャネルに外部リスニング・アドレスおよび外部ポートとして構成されたいずれかのリスニング・アドレスとポートに直接接続します。これらのリクエストは、WebLogicに定義された接続ファクトリに指定され、クライアントで使用されているメカニズムによってロード・バランシングされます。
この方法は、デフォルト・チャネルを使用した直接T3/T3sと似ていますが、WebLogicカスタム・チャネルを使用すると、T3/T3sコールで使用するアドレスとポートをカスタマイズできる点が異なります。
構成
-
各WebLogicサーバーには適切なカスタム・チャネルが構成されており、これらのカスタム・チャネルでは、そのサーバー・ノードを指す一意の
外部リスニング・アドレスが使用されます。表3-4および表3-5に、サーバー1とサーバー2のカスタム・チャネルの例を示します。表3-4 サーバー1のカスタム・チャネル
名前 プロトコル 有効 リスニング・アドレス リスニング・ポート パブリック・アドレス パブリック・ポート t3_external_channelt3 はい soahost1.example.com8111 soahost1-t3ext.example.com8111 表3-5 サーバー2のカスタム・チャネル
名前 プロトコル 有効 リスニング・アドレス リスニング・ポート パブリック・アドレス パブリック・ポート t3_external_channelt3 はい soahost2.example.com8111 soahost2-t3ext.example.com8111 -
外部T3クライアントのプロバイダURLには、カスタム・チャネルの外部アドレスおよびポートのリストが含まれます。
例:
t3://soahost1-t3ext.example.com:8111,soahost2-t3ext.example.com:8111T3sプロトコルを使用している場合は、T3sプロトコルを使用してカスタム・チャネルを作成する必要があります。その後、クライアントはT3sプロトコルと適切なポートを使用して接続します。
例:
t3s://soahost1-t3ext.example.com:8112,soahost2-t3ext.example.com:8112T3sチャネルでは、
外部リスニング・アドレスとして使用される名前の特定のSSL証明書を追加できます。 -
外部T3/T3sクライアントは、カスタム・チャネルの外部ホスト名をプライマリ・ホストのIPで解決する必要があります。これらのホスト名には、クライアントからアクセスできる必要があります。各サーバーにNATアドレスがある場合は、NATを使用できます。その場合、クライアントは、各サーバーの名前をそのサーバーの適切なNAT IPで解決します。
例: 外部クライアント側でのネーミング解決
172.11.2.113 soahost1-t3ext.example.com 172.11.2.114 soahost2-t3ext.example.comこの方法では、外部クライアントからのすべてのリクエストが
soahost1-t3ext.example.comおよびsoahost2-t3ext.example.comに接続され、最初のコンテキストの取得とその後のコールの両方に使用されます。これらのリクエストは、WebLogic Serverのロード・バランシング・メカニズムで制御できます。
スイッチオーバー
スイッチオーバーを実行した場合は、クライアントのプロバイダURLを更新する必要はありません。かわりに、クライアントのDNS (または/etc/hosts)にあるエントリを更新する必要があります。スイッチオーバー後、サーバーへの接続に使用される名前は、セカンダリ・サーバーのIPで解決する必要があります。
172.22.2.113 soahost1-t3ext.example.com
172.22.2.114 soahost2-t3ext.example.comメリット
-
この方法では、サーバーのデフォルトのリスニング・アドレスとは異なる特定のホスト名を外部T3/T3s通信に使用できます。これは、セキュリティ上の理由で、デフォルト・サーバーの
リスニング・アドレスを外部クライアントに公開しない場合に便利です。 -
この方法は、NAT IPを使用していて、内部でも外部でも、IPが異なるサーバーのデフォルトのリスニング・アドレスを解決しない場合にも便利です。
-
この方法は、組織の目的にのみ、外部T3/T3sアクセスに異なる名前を使用する場合にも便利です。この方法では、様々なインタフェースまたはネットワーク・ルートで、プロトコルを分離することも可能です。
-
カスタム・チャネルのプロトコルは、T3/T3sに限定して制限できます。カスタム・チャネルでは、HTTPプロトコルを無効にすることが可能です。
デメリット
- スイッチオーバーが発生したら、管理対象サーバーへの接続に使用されるすべてのホスト名について、外部クライアント側で
DNS (またはクライアントの/etc/hosts)を更新する必要があります。クライアントのキャッシュへの影響の詳細は、「T3/T3sクライアントのDNSキャッシュについて」を参照してください。 - T3sを使用している場合は、クライアントでSSLホスト名の検証エラーが発生しないよう、カスタム・チャネルの外部名の特定のSSL証明書を作成して構成する必要があります。
- WebLogicクラスタのWebLogic Serverノードを追加または削除した場合は、クライアントのプロバイダURLを変更する必要があります。最初の接続で使用されるのは、クライアントのプロバイダURLのみです。リカバリされたスタブにすべてのメンバーがリストされるため、リストを更新しなくても、その後のリクエストはクラスタの任意のサーバーに接続することが可能です。ただし、どの場合でも、クライアントのプロバイダURLがサーバーの実際のリストと一致するため、最初の接続でのフェイルオーバーを目的とする場合には、よい方法です。
親トピック: T3/T3sサービスにアクセスするための様々なアプローチ
最初の参照でのロード・バランサの使用
このシナリオでは、クライアントのプロバイダURLは、ロード・バランサ・サービスを指しています。
デフォルト・チャネルを使用した直接T3/T3s、およびカスタム・チャネルを使用した直接T3/T3sの方法では、最初にコンテキストを参照する際に、ロード・バランサを使用することもできます。
ただし、その後のT3/T3sコールは、WebLogic Serverに直接接続します。デフォルト・チャネルを使用する場合、リクエストはデフォルト・チャネルのリスニング・アドレスおよびポートに接続します。同様に、カスタム・チャネルを使用する場合、後続のリクエストは、カスタム・チャネルに定義されている外部リスニング・アドレスおよびポートに接続します。
図3-7 最初の参照でのロード・バランサの使用
構成
-
WebLogic ServerのT3/T3sポート(デフォルト・チャネル、または使用している場合はカスタム・チャネル)にリクエストをロード・バランシングするために、ロード・バランサ内にTCPサービスが必要です。
-
外部T3/T3sクライアントのプロバイダは、ロード・バランサのフロントエンド名とポートを接続先として使用します。
例:
t3://t3lbr.example.com:8111 -
「デフォルト・チャネルを使用した直接T3/T3s」および「カスタム・チャネルを使用した直接T3/T3s」のシナリオの説明に従って、デフォルト・チャネルまたはカスタム・チャネルを使用できます。外部T3/T3sクライアントは、カスタム・チャネルの外部ホスト名(またはデフォルト・チャネルを使用している場合は、デフォルト・サーバーのリスナー・ホスト名)をプライマリ・ホストのIPで解決する必要があります。クライアントがそれらにアクセスできる必要があります。各サーバーにNATアドレスがある場合は、NATを使用できます。その場合、クライアントは、各サーバーの名前をそのサーバーの適切なNAT IPで解決します。
例: 外部クライアント側でのネーミング解決111.111.111.111 t3lbr.example.com 172.11.2.113 soahost1-t3ext.example.com 172.11.2.114 soahost2-t3ext.example.com
スイッチオーバー
完全なスイッチオーバーの場合は、クライアントのプロバイダURLを更新する必要はありません。かわりに、クライアントで使用されるDNS (または/etc/hosts)にあるエントリを更新して、セカンダリ・サイトのIPで解決されるようにする必要があります。ロード・バランサへの接続に使用される名前は、セカンダリ・ロード・バランサのIPで解決し、その後のリクエストで使用されるサーバー名は、セカンダリ・サーバーのIPを指している必要があります。
222.222.222.222 t3lbr.example.com
172.22.2.113 soahost1-t3ext.example.com
172.22.2.113 soahost2-t3ext.example.comメリット
WebLogicクラスタのWebLogic Serverノードを追加または削除した場合に、クライアントのプロバイダURLを変更する必要がありません。
デメリット
-
ロード・バランサを前面に使用しているにもかかわらず、クライアントはサーバーに直接アクセスする必要があります。
-
スイッチオーバーが発生したら、外部クライアント側で、サーバーのアドレスの
DNS (または/etc/hosts)を更新する必要があります。クライアントのキャッシュへの影響の詳細は、「T3/T3sクライアントのDNSキャッシュについて」を参照してください。 -
T3sの場合、この方法はさらに複雑になります。クライアントは、フロントエンドのLBR経由と、セキュアなプロトコルを使用して直接の両方でサーバーに接続します。この場合、クライアント側のホスト名検証をスキップするか、フロント・アドレスとバック・アドレス(ワイルドカードやSAN証明書など)に有効なSSL証明書を使用する必要があります。
親トピック: T3/T3sサービスにアクセスするための様々なアプローチ
すべてのトラフィックでのロード・バランサの使用
この方法では、最初にコンテキストを参照するときだけでなく、その後の接続でもロード・バランサが使用されます。外部T3/T3sクライアントは、サーバーに直接接続しません。
すべてのタイプのT3/T3s通信のロード・バランシングにLBRを使用することはお薦めしません。推奨されるのは、最初にコンテキストを参照するときのみです。詳細は、ロード・バランサとのWebLogic RMIの統合に関する項を参照してください。ただし、すべてのT3/T3s通信フローにロード・バランサを使用できるT3/T3sのユース・ケースがあります。WebLogic T3/T3sはTCP/IPベースのプロトコルであるため、JMSやEJBなど、サービスが同種である場合には、TCPロード・バランシングがサポートされます。たとえば、WebLogicクラスタ内にLBRが前面にあるJMSサブシステムを構成すれば、そのシステムでは、リモートJMSクライアントが任意のクラスタ・メンバーに接続することができます。
ただし、この方法は、JTA接続を使用する外部クライアントでは機能しません。JTAサブシステムは、複数のWebLogicドメインにまたがるトランザクションで、TCPロード・バランシングを安全に使用することができません。トランザクションがコミットまたはロールバックされると、JTAトランザクション・コーディネータは、トランザクションのサブ・コーディネータとして選択されたサーバー・インスタンスに、RMI直接接続を確立する必要があります。
この方法は、特定のサーバーのみに接続する場合に、JMXやWLSTなどの特定サーバーに直接接続する必要がある場合にも適していません。
図3-8 すべてのトラフィックでのロード・バランサの使用
構成
-
ロード・バランサには、カスタム・チャネルに定義されているWebLogic ServerのT3/T3sポートにリクエストをロード・バランシングするためのTCPサービスが必要です。
-
外部T3/T3sクライアントのプロバイダURLは、ロード・バランサのフロントエンド名とポートを接続先として使用します。
例:t3://t3lbr.example.com:8111 -
外部クライアントは、プライマリ・サイトのロード・バランサのIPを使用して、ロード・バランサ・アドレスを解決する必要があります。
例:111.111.111.111 t3lbr.example.com -
WebLogic Serverには、カスタム・チャネルが必要です。ロード・バランサのアドレスとポートを使用して、これらのカスタム・チャネルの外部リスニング・アドレスとポートを構成します。表3-6および表3-7に、サーバー1とサーバー2のカスタム・チャネルの例を示します。
表3-6 サーバー1のカスタム・チャネル
名前 プロトコル 有効 リスニング・アドレス リスニング・ポート パブリック・アドレス パブリック・ポート t3_external_channelt3 はい soahost1.example.com8111 t3blr.example.com8111 表3-7 サーバー2のカスタム・チャネル
名前 プロトコル 有効 リスニング・アドレス リスニング・ポート パブリック・アドレス パブリック・ポート t3_external_channelt3 はい soahost2.example.com8111 t3lbr.example.com8111
スイッチオーバー
スイッチオーバーの場合は、クライアントのプロバイダURLを更新する必要はありません。かわりに、クライアントのDNS (または/etc/hosts)にあるエントリを更新する必要があります。スイッチオーバー後、サーバーへの接続に使用される名前は、セカンダリLBRサービスのIPで解決されます。
222.222.222.222 t3lbr.example.comメリット
-
すべての通信がロード・バランサを経由します。クライアントは、ロード・バランサのサービスを認識してアクセスするだけでかまいません。
-
WebLogicクラスタのWebLogic Serverノードを追加または削除する必要がある場合に、クライアントのプロバイダURLを変更する必要がありません。
-
スイッチオーバーの場合に実行する必要があるのは、
DNS (または/etc/hosts)にあるロード・バランサのフロントエンド名の更新のみです。ノート:
更新されるDNS名が1つのみであっても、クライアントのDNSキャッシュをリフレッシュする必要があります。詳細は、「T3/T3sクライアントのDNSキャッシュについて」を参照してください。 -
T3sの場合、ロード・バランサ・サービスのフロントエンド名に関連付けられているすべてのカスタム・チャネルで、同じSSL証明書を使用できます。
デメリット
-
この方法が、すべてのT3/T3sのユース・ケースに適しているわけではありません。JTAは、トランザクションのサブ・コーディネータとして機能するサーバー・インスタンスに明示的に接続する必要があるため、JTAを使用するシナリオではこの方法を採用できません。
親トピック: T3/T3sサービスにアクセスするための様々なアプローチ
T3/T3sクライアントのDNSキャッシュについて
T3/T3sサービスにアクセスするどの方法でも、通常はDNSの更新が必要です。DNSの更新が必要なため、DNSサーバーとクライアントの特定のキャッシュに存在するDNSキャッシュのTTL (存続時間)制限を設定する必要があります。
DNSサービスのTTL制限の設定で、新しい問合せをリクエストするまでに、DNSリゾルバで問合せをキャッシュする期間が決まります。DNSエントリのTTL値が、スイッチオーバーの有効なRTOに影響することに注意してください。TTLの値が大きい(20分など)と、DNSの変更がクライアントで有効になるのに、それと同じ時間がかかります。TTLの値を小さくすると、スイッチオーバーは短時間で行われますが、クライアントがDNSをチェックする頻度が高くなるため、オーバーヘッドの原因になる可能性があります。DNSを変更する前に、TTLを一時的に小さい値(1分など)に設定することをお薦めします。その後、変更を行い、スイッチオーバーの手順が完了したら、TTLを通常の値に設定しなおします。
DNSサーバーのTTLに加えて、networkaddress.cache.ttl Javaプロパティも、JavaクライアントのキャッシュTTLを制御します。このJavaプロパティは、名前サービスからの名前の検索に成功した場合のキャッシング・ポリシーを示します。正常な参照をキャッシュする秒数を示す値を整数で指定します。クライアントのJavaキャッシュがDNSエントリをキャッシュし続けないよう、networkaddress.cache.ttl Javaプロパティに必ず制限を設定してください。そうしない場合、スイッチオーバーの度に、クライアントの再起動が必要になります。