| Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド 11g リリース1(11.1.1) B61394-01 |
|
 前 |
 次 |
この章では、Oracle SOA Suiteのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用して、本番サイトおよびスタンバイ・サイトの設定に必要な手順を説明します。
次のトピックがあります。
この項では、本番サイトを作成する手順を説明します。Oracle SOAのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用します。
次のトピックがあります。
本番サイトの作成を開始する前に、次の事前準備が完了していることを確認してください。
中間層ホストのホスト名別名を設定します。第3.1.1項「ホスト名の計画」を参照してください。
本番サイトの共有ストレージに必要なボリュームを作成します。第4.1.1項「ディレクトリ構造とボリューム設計」を参照してください。
マウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。第3.2.3項「ストレージ・レプリケーション」を参照して、本番サイトにシンボリック・リンクを作成する必要があるかどうかを確認してください。
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定する必要があります。Oracle Data Guard構成を設定する前に、こうした情報が正しく特定されていることを確認してください。
詳細は、『Oracle Data Guard概要および管理』、および次のURLにあるMaximum Availability Architectureの関連項目を参照してください。
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
次の項では、お薦めするディレクトリ構造について詳しく説明します。エンド・ユーザーは他のディレクトリ・レイアウトを選択してもかまいませんが、ここで採用されているモデルを使用すると、コンポーネントが最適に分離され、構成における対称性が保たれるとともに、バックアップと障害時リカバリが容易になり、最大限の可用性が実現されます。
次の一覧では、ディレクトリとディレクトリ環境変数について説明します。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを表します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが配置されている場所を表します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なファイルがインストールされて格納されます。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、製品スイート(Oracle Fusion Middleware SOA Suite、Oracle WebCenter、Oracle Identity Managementなど)がインストールされている場所を表します。
DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogic Domain情報(構成アーティファクト)が保存されている場所を表します。後述のように同じノード内にある場合でも、個々のWebLogic Serverで異なるドメイン・ディレクトリを使用できます。
ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなど、1つ以上のシステム・コンポーネントが格納されます。Oracleインスタンスのディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されます。
詳細は、次を参照してください。
Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のSOA管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、特に障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には、共有ストレージに配置することをお薦めします。図4-1は、Oracle SOA Suiteのディレクトリ構造のレイアウトを示しています。
このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』および『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』を参照してください。
表4-1では、図4-1で色分けされている要素の意味を説明します。図4-1のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。
表4-1 ディレクトリ構造の要素
| 要素 | 説明 |
|---|---|
 |
管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、および |
 |
固定名です。 |
 |
インストール依存名です。 |
図4-2および図4-3は、Oracle SOA Suiteのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle SOA Suiteトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
図4-2 Oracle Access Managerを使用したMySOACompanyトポロジ
このOracle SOA Suiteトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。
製品の冗長バイナリを格納する2つのMiddlewareホーム用にボリュームを2つプロビジョニングします(表4-2のVOLFMW1およびVOLFMW2)。
管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-2のVOLADMIN)。
管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-2のVOLSOA1およびVOLSOA2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。
JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-2のVOLDATA)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。
Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-2のVOLWEB1およびVOLWEB2)。
Oracle HTTP ServerのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-2のVOLWEBINST1およびVOLWEBINST2)。
表4-2に、図4-2および図4-3に示されているOracle SOA Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。
表4-2 Oracle SOA Suiteのボリューム設計に関する推奨事項
| 層 | ボリューム名 | マウントされるホスト | マウント・ポイント | コメント |
|---|---|---|---|---|
|
Web |
VOLWEB1 |
WEBHOST1 |
/u01/app/oracle/product/fmw/web |
Oracle HTTP Serverインストール用のボリューム |
|
Web |
VOLWEB2 |
WEBHOST2 |
/u01/app/oracle/product/fmw/web |
Oracle HTTP Serverインストール用のボリューム |
|
Web |
VOLWEBINST1 |
WEBHOST1 |
/u01/app/oracle/admin/ohs_instance |
Oracle HTTP Serverインスタンス用のボリューム |
|
Web |
VOLWEBINST2 |
WEBHOST2 |
/u01/app/oracle/admin/ohs_instance |
Oracle HTTP Serverインスタンス用のボリューム |
|
Web |
VOLSTATIC1脚注1 |
WEBHOST1 |
/u01/app/oracle/admin/ohs_instance/config/static |
静的HTMLコンテンツ用のボリューム |
|
Web |
VOLSTATIC2脚注2 |
WEBHOST2 |
/u01/app/oracle/admin/ohs_instance/config/static |
静的HTMLコンテンツ用のボリューム |
|
アプリケーション |
VOLFMW1 |
SOAHOST1 |
/u01/app/oracle/product/fmw |
WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム |
|
アプリケーション |
VOLFMW2 |
SOAHOST2 |
/u01/app/oracle/product/fmw |
WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム |
|
アプリケーション |
VOLADMIN |
SOAHOST1 |
/u01/app/oracle/admin/soaDomain/admin |
管理サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLSOA1 |
SOAHOST1 |
/u01/app/oracle/admin/soaDomain/mng1 |
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLSOA2 |
SOAHOST2 |
/u01/app/oracle/admin/soaDomain/mng2 |
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLDATA |
SOAHOST1、SOAHOST2 |
/u01/app/oracle/admin/soaDomain/soaCluster/jms /u01/app/oracle/admin/soaDomain/soaCluster/tlogs |
トランザクション・ログおよびJMSデータ用のボリューム |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle SOA Suiteトポロジについては、次のコンシステンシー・グループをお薦めします。
管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-3のDOMAINGROUP)。
JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-3のDATAGROUP)。
Middlewareホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-3のFMWHOMEGROUP)。
Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-3のWEBHOMEGROUP)。
Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-3のWEBINSTANCEGROUP)。
表4-3に、図4-2に示されているOracle SOA Suiteトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。
表4-3 Oracle SOA Suiteのコンシステンシー・グループ
| 層 | グループ名 | メンバー | コメント |
|---|---|---|---|
|
アプリケーション |
DOMAINGROUP |
VOLADMIN VOLSOA1 VOLSOA2 |
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
|
アプリケーション |
DATAGROUP |
VOLDATA |
JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ |
|
アプリケーション |
FMWHOMEGROUP |
VOLFMW1 VOLFMW2 |
Middlewareホーム用のコンシステンシー・グループ |
|
Web |
WEBHOMEGROUP |
VOLWEB1 VOLWEB2 |
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
|
Web |
WEBINSTANCEGROUP |
VOLWEBINST1 VOLWEBINST2 VOLSTATIC1脚注1 VOLSTATIC2脚注2 |
Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のWebCenter管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、特に障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には、共有ストレージに配置することをお薦めします。図4-1は、Oracle WebCenterのディレクトリ構造のレイアウトを示しています(Oracle SOA SuiteとOracle WebCenterの両方に同じディレクトリ構造のレイアウトが使用されます)。
図4-4は、Oracle WebCenterのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle WebCenterトポロジのものです。このトポロジのインストールおよび構成の手順は、『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』を参照してください。
このOracle WebCenterトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。
製品の冗長バイナリを格納する2つのMiddlewareホーム用にボリュームを2つプロビジョニングします(表4-4のVOLFMW1およびVOLFMW2)。
管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-4のVOLADMIN)。
SOAの管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-4のVOLSOA1およびVOLSOA2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。
WebCenterの管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-4のVOLWC1およびVOLWC2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。
JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-4のVOLDATA)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。
Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-4のVOLWEB1およびVOLWEB2)。
Oracle HTTP ServerのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-4のVOLWEBINST1およびVOLWEBINST2)。
表4-4に、図4-4に示されているOracle WebCenterトポロジのボリューム設計に関する推奨事項の概要を示します。
表4-4 Oracle WebCenterのボリューム設計に関する推奨事項
| 層 | ボリューム名 | マウントされるホスト | マウント・ポイント | コメント |
|---|---|---|---|---|
|
Web |
VOLWEB1 |
WEBHOST1 |
/u01/app/oracle/product/fmw/web |
Oracle HTTP Serverインストール用のボリューム |
|
Web |
VOLWEB2 |
WEBHOST2 |
/u01/app/oracle/product/fmw/web |
Oracle HTTP Serverインストール用のボリューム |
|
Web |
VOLWEBINST1 |
WEBHOST1 |
/u01/app/oracle/admin/ohs_instance |
Oracle HTTP Serverインスタンス用のボリューム |
|
Web |
VOLWEBINST2 |
WEBHOST2 |
/u01/app/oracle/admin/ohs_instance |
Oracle HTTP Serverインスタンス用のボリューム |
|
Web |
VOLSTATIC1脚注1 |
WEBHOST1 |
/u01/app/oracle/admin/ohs_instance/config/static |
静的HTMLコンテンツ用のボリューム |
|
Web |
VOLSTATIC2脚注2 |
WEBHOST2 |
/u01/app/oracle/admin/ohs_instance/config/static |
静的HTMLコンテンツ用のボリューム |
|
アプリケーション |
VOLFMW1 |
SOAHOST1 |
/u01/app/oracle/product/fmw |
WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム |
|
アプリケーション |
VOLFMW2 |
SOAHOST2 |
/u01/app/oracle/product/fmw |
WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム |
|
アプリケーション |
VOLADMIN |
SOAHOST1 |
/u01/app/oracle/admin/soaDomain/admin |
管理サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLSOA1 |
SOAHOST1 |
/u01/app/oracle/admin/soaDomain/mng1 |
SOAの管理対象サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLSOA2 |
SOAHOST2 |
/u01/app/oracle/admin/soaDomain/mng2 |
SOAの管理対象サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLWC1 |
WCHOST1 |
/u01/app/oracle/admin/wcDomain/mng1 |
WebCenterの管理対象サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLWC2 |
WCHOST2 |
/u01/app/oracle/admin/wcDomain/mng2 |
WebCenterの管理対象サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLDATA |
SOAHOST1、SOAHOST2、WCHOST1、WCHOST2 |
/u01/app/oracle/admin/soaDomain/soaCluster/jms /u01/app/oracle/admin/soaDomain/soaCluster/tlogs |
トランザクション・ログおよびJMSデータ用のボリューム |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle WebCenterトポロジについては、次のコンシステンシー・グループをお薦めします。
管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-5のDOMAINGROUP)。
JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-5のDATAGROUP)。
Middlewareホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-5のFMWHOMEGROUP)。
Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-5のWEBHOMEGROUP)。
Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-5のWEBINSTANCEGROUP)。
表4-5に、図4-4に示されているOracle WebCenterトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。
表4-5 Oracle WebCenterのコンシステンシー・グループ
| 層 | グループ名 | メンバー | コメント |
|---|---|---|---|
|
アプリケーション |
DOMAINGROUP |
VOLADMIN VOLSOA1 VOLSOA2 |
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
|
アプリケーション |
DATAGROUP |
VOLDATA |
JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ |
|
アプリケーション |
FMWHOMEGROUP |
VOLFMW1 VOLFMW2 |
Middlewareホーム用のコンシステンシー・グループ |
|
Web |
WEBHOMEGROUP |
VOLWEB1 VOLWEB2 |
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
|
Web |
WEBINSTANCEGROUP |
VOLWEBINST1 VOLWEBINST2 VOLSTATIC1脚注1 VOLSTATIC2脚注2 |
Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle Fusion Middleware 11gでは、Oracle Identity Managementコンポーネントの製品バイナリと実行時アーティファクトを別々にすることができます。製品バイナリはORACLE_HOMEディレクトリに配置され、実行時アーティファクトはORACLE_INSTANCEディレクトリに配置されます。
このモデルでは、Web層およびデータ層については、ホストごとに(製品バイナリ用の)ORACLE_HOMEを1つと、インスタンスごとにORACLE_INSTANCEを1つ共有ストレージにインストールすることをお薦めします。ORACLE_HOMEは、ホストで実行されるすべてのインスタンス間で共有されますが、ORACLE_INSTANCEには、各インスタンスで独自の場所が使用されます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。
アプリケーション層については、ホストごとにMiddlewareホーム(MW HOME)を1つ(それぞれに、各製品スイートのWLS HOMEとORACLE_HOMEがあります)共有ストレージにインストールすることをお薦めします。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、この場所を、追加でインストールすることなくそのまま使用できます。
ドメイン・ディレクトリとMW_HOMEを別々にすることはできません。ドメイン・ディレクトリはMW_HOMEに配置され、ホストで実行されるすべての管理サーバーおよび管理対象サーバー間で共有されます。第4.1.1.3項「Oracle Identity Managementのディレクトリ構造」では、Oracle Identity Managementのディレクトリ構造のレイアウトを紹介します。
このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。図4-5のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。
図4-6は、Oracle Identity Managementのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle Identity Managementトポロジのものです。このトポロジのインストールおよび構成の手順は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。
図4-6に示されているOracle Identity Managementのエンタープライズ・デプロイメントを設定する方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。
Oracle Identity Managementについては、次のボリューム設計をお薦めします。
Middlewareホーム用に各Identity Managementノードでボリュームを1つプロビジョニングします。このボリュームには、WebLogic Serverホーム、Identity ManagementのOracleホーム、そのホストで実行される管理サーバーおよび管理対象サーバーのドメイン・ディレクトリも格納されます。これらは、表4-6のVOLIDM1およびVOLIDM2です。
ディレクトリ層およびWeb層のOracleホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-6のVOLWEB1、VOLWEB2、VOLOID1、VOLOID2、VOLOVD1およびVOLOVD2です。
ディレクトリ層およびWeb層のOracleインスタンス・ホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-6のVOLWEBINST1、VOLWEBINST2、VOLOIDINST1、VOLOIDINST2、VOLOVDINST1およびVOLIOVDINST2です。
アプリケーション層のIdentity ManagementのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします。このボリュームは、管理サーバーおよび管理対象サーバーのインスタンスで共有されます。これらは、表4-6のVOLIDMINST1およびVOLIDMINST2です。
Oracle Access Managerホーム用に各Oracle Access Managerノードでボリュームを1つプロビジョニングします。このボリュームには、アイデンティティ・サーバーおよびアクセス・サーバーのホームが格納されます。これらは、表4-6のVOLOAM1およびVOLOAM2です。
Oracle HTTP ServerのOracleホーム、Oracle HTTP ServerのOracleインスタンス、Webゲート、Webパスおよびポリシー・マネージャーのホーム用にOAMADMINHOSTでボリュームを1つプロビジョニングします。これは、表4-6のVOLOAMADMINです。
表4-6に、図4-6に示されているOracle Identity Managementトポロジのボリューム設計に関する推奨事項の概要を示します。
表4-6 Oracle Identity Managementのボリュームに関する推奨事項
| 層 | ボリューム名 | マウントされるノード | マウント・ポイント | コメント |
|---|---|---|---|---|
|
Web |
VOLWEB1 |
WEBHOST1 |
/u01/app/oracle/product/fmw/web |
Oracle HTTP Serverインストール用のボリューム |
|
Web |
VOLWEB2 |
WEBHOST2 |
/u01/app/oracle/product/fmw/web |
Oracle HTTP Serverインストール用のボリューム |
|
Web |
VOLWEBINST1 |
WEBHOST1 |
/u01/app/oracle/admin/ohs_instance |
Oracle HTTP Serverインスタンス用のボリューム |
|
Web |
VOLWEBINST2 |
WEBHOST2 |
/u01/app/oracle/admin/ohs_instance |
Oracle HTTP Serverインスタンス用のボリューム |
|
Web |
VOLSTATIC1脚注1 |
WEBHOST1 |
/u01/app/oracle/admin/ohs_instance/config/static |
静的HTMLコンテンツ用のボリューム |
|
Web |
VOLSTATIC2脚注2 |
WEBHOST2 |
/u01/app/oracle/admin/ohs_instance/config/static |
静的HTMLコンテンツ用のボリューム |
|
アプリケーション |
VOLIDM1 |
IDMHOST1 |
/u01/app/oracle/product/fmw |
Identity ManagementのMiddlewareホーム用のボリューム |
|
アプリケーション |
VOLIDM2 |
IDMHOST2 |
/u01/app/oracle/product/fmw |
Identity ManagementのMiddlewareホーム用のボリューム |
|
アプリケーション |
VOLIDMINST1 |
IDMHOST1 |
/u01/app/oracle/admin |
Oracleインスタンス用のボリューム |
|
アプリケーション |
VOLIDMINST2 |
IDMHOST2 |
/u01/app/oracle/admin |
Oracleインスタンス用のボリューム |
|
アプリケーション |
VOLOAM1 |
OAMHOST1 |
/u01/app/oracle/product/fmw/oam |
Oracle Access Managerのアイデンティティ・サーバーおよびアクセス・サーバー・ホーム用のボリューム |
|
アプリケーション |
VOLOAM2 |
OAMHOST2 |
/u01/app/oracle/product/fmw/oam |
Oracle Access Managerのアイデンティティ・サーバーおよびアクセス・サーバー・ホーム用のボリューム |
|
アプリケーション |
VOLOAMADMIN |
OAMADMINHOST |
/u01/app/oracle |
Oracle Access Managerの管理コンポーネント用のボリューム |
|
ディレクトリ |
VOLOID1 |
OIDHOST1 |
/u01/app/oracle/product/fmw/idm |
Oracle Internet DirectoryのOracleホーム用のボリューム |
|
ディレクトリ |
VOLOID2 |
OIDHOST2 |
/u01/app/oracle/product/fmw/idm |
Oracle Internet DirectoryのOracleホーム用のボリューム |
|
ディレクトリ |
VOLOIDINST1 |
OIDHOST1 |
/u01/app/oracle/admin |
Oracle Internet DirectoryのOracleインスタンス用のボリューム |
|
ディレクトリ |
VOLOIDINST2 |
OIDHOST2 |
/u01/app/oracle/admin |
Oracle Internet DirectoryのOracleインスタンス用のボリューム |
|
ディレクトリ |
VOLOVD1 |
OVDHOST1 |
/u01/app/oracle/product/fmw/idm |
Oracle Virtual DirectoryのOracleホーム用のボリューム |
|
ディレクトリ |
VOLOVD2 |
OVDHOST2 |
/u01/app/oracle/product/fmw/idm |
Oracle Virtual DirectoryのOracleホーム用のボリューム |
|
ディレクトリ |
VOLOVDINST1 |
OVDHOST1 |
/u01/app/oracle/admin |
Oracle Virtual DirectoryのOracleインスタンス用のボリューム |
|
ディレクトリ |
VOLOVDINST2 |
OVDHOST2 |
/u01/app/oracle/admin |
Oracle Virtual DirectoryのOracleインスタンス用のボリューム |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle Identity Managementトポロジについては、次のコンシステンシー・グループをお薦めします。
アプリケーション層のMiddlewareホーム・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-7のIDMMWGROUPグループです。
アプリケーション層のOracleインスタンス・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-7のIDMINSTGROUPグループです。
Oracle Internet DirectoryのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-7のOIDHOMEGROUPグループです。
Oracle Internet DirectoryのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-7のOIDINSTGROUPグループです。
Oracle Virtual DirectoryのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-7のOVDHOMEGROUPグループです。
Oracle Virtual DirectoryのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-7のOVDINSTGROUPグループです。
Oracle Access Managerの管理コンポーネント用のOracle Access ManagerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-7のOAMADMINGROUPグループです。
Oracle Access Managerのアイデンティティ・サーバーおよびアクセス・サーバー・コンポーネント用のOracle Access ManagerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-7のOAMGROUPグループです。
Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-7のWEBHOMEGROUPグループです。
Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-7のWEBINSTGROUPグループです。
表4-7に、図4-6に示されているOracle Identity Managementトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。
表4-7 Oracle Identity Managementのコンシステンシー・グループ
| 層 | グループ名 | メンバー | コメント |
|---|---|---|---|
|
ディレクトリ |
OIDHOMEGROUP |
VOLOID1 VOLOID2 |
Oracle Internet DirectoryのOracleホーム用のコンシステンシー・グループ |
|
ディレクトリ |
OIDINSTGROUP |
VOLOIDINST1 VOLOIDINST2 |
Oracle Internet DirectoryのOracleインスタンス用のコンシステンシー・グループ |
|
ディレクトリ |
OVDHOMEGROUP |
VOLOVD1 VOLOVD2 |
Oracle Virtual DirectoryのOracleホーム用のコンシステンシー・グループ |
|
ディレクトリ |
OVDINSTGROUP |
VOLOVDINST1 VOLOVDINST2 |
Oracle Virtual DirectoryのOracleインスタンス用のコンシステンシー・グループ |
|
アプリケーション |
IDMMWGROUP |
VOLIDM1 VOLIDM2 |
Middlewareホーム用のコンシステンシー・グループ |
|
アプリケーション |
IDMINSTGROUP |
VOLIDMINST1 VOLIDMINST2 |
Identity Managementインスタンス用のコンシステンシー・グループ |
|
アプリケーション |
OAMGROUP |
VOLOAM1 VOLOAM2 |
Oracle Access Managerのアイデンティティ・サーバーおよびアクセス・サーバー・ホーム用のコンシステンシー・グループ |
|
アプリケーション |
OAMADMINGROUP |
VOLOAMADMIN |
Oracle Access Managerの管理ホスト・コンポーネント用のコンシステンシー・グループ |
|
Web |
WEBHOMEGROUP |
VOLWEB1 VOLWEB2 |
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
|
Web |
WEBINSTGROUP |
VOLWEBINST1 VOLWEBINST2 VOLSTATIC1脚注1 VOLSTATIC2脚注2 |
Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
図4-7は、Oracle Portalのエンタープライズ・デプロイメント・トポロジ・ダイアグラムです。このOracle Portalトポロジを含む障害時リカバリ・サイトには、第4.1.1.4.1項「Oracle Portal、Forms、ReportsおよびDiscoverのボリューム設計」と第4.1.1.4.2項「Oracle Portal、Forms、ReportsおよびDiscovererのコンシステンシー・グループに関する推奨事項」に記載されているボリューム設計とコンシステンシー・グループを使用できます。
図4-7のOracle Portalエンタープライズ・トポロジの詳細は、11.1.1.2 Oracle Portalエンタープライズ・デプロイメント・ガイドに記載されています。このマニュアルの入手方法は、My Oracle Support(以前のOracle MetaLink)にある記事ID 952068.1「Oracle Fusion Middleware 11g(11.1.1.2)Portal、Forms、ReportsおよびDiscoverエンタープライズ・デプロイメント・ガイド」を参照してください。My Oracle SupportのURLは次のとおりです。
図4-8は、Oracle Forms、ReportsおよびDiscovererのエンタープライズ・トポロジ・ダイアグラムです。このトポロジを含む障害時リカバリ・サイトには、第4.1.1.4.1項「Oracle Portal、Forms、ReportsおよびDiscoverのボリューム設計」と第4.1.1.4.2項「Oracle Portal、Forms、ReportsおよびDiscovererのコンシステンシー・グループに関する推奨事項」に記載されているボリューム設計とコンシステンシー・グループを使用できます。
図4-8のOracle Forms、ReportsおよびDiscovererエンタープライズ・トポロジの詳細は、11.1.1.2 Oracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメント・ガイドに記載されています。このマニュアルの入手方法は、My Oracle Support(以前のOracle MetaLink)にある記事ID 952068.1「Oracle Fusion Middleware 11g(11.1.1.2)Portal、Forms、ReportsおよびDiscoverエンタープライズ・デプロイメント・ガイド」を参照してください。My Oracle SupportのURLは次のとおりです。
図4-7に示されているOracle Portalトポロジと図4-8に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトについては、次のボリューム設計をお薦めします。
Middlewareホーム用に各アプリケーション層ホストでボリュームを1つプロビジョニングします。このボリュームには、WebLogic Serverホーム、Oracle Portal、Reports、FormsおよびDiscovererコンポーネントのOracleホーム、そのホストで実行される管理サーバーおよび管理対象サーバーのドメイン・ディレクトリも格納されます。これらは、表4-8のVOLPFRD1およびVOLPFRD2です。
Web層のOracleホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-8のVOLWEB1およびVOLWEB2です。
ディレクトリWeb層のOracleインスタンス・ホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-8のVOLWEBINST1およびVOLWEBINST2です。
アプリケーション層のOracleインスタンス・ホーム用に各ノードでボリュームを1つプロビジョニングします。このボリュームは、管理サーバーおよび管理対象サーバーのインスタンスで共有されます。これらは、表4-8のVOLPFRDINST1およびVOLPFRDINST2です。
アプリケーション層のOracle Reports出力ディレクトリ用にボリュームを1つプロビジョニングします。このボリュームは、Oracle Reportsサーバーを実行するすべてのノードでマウントされます。これは、表4-6のVOLREPOUTです。
表4-8に、図4-7に示されているOracle Portalトポロジと図4-8に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトのボリューム設計に関する推奨事項の概要を示します。
表4-8 Oracle Portal、Reports、FormsおよびDiscovererのボリューム設計に関する推奨事項
| 層 | ボリューム名 | マウントされるホスト | マウント・ポイント | コメント |
|---|---|---|---|---|
|
Web |
VOLWEB1 |
WEBHOST1 |
/u01/app/oracle/product/fmw/web |
Oracle HTTP Serverインストール用のボリューム |
|
Web |
VOLWEB2 |
WEBHOST2 |
/u01/app/oracle/product/fmw/web |
Oracle HTTP Serverインストール用のボリューム |
|
Web |
VOLWEBINST1 |
WEBHOST1 |
/u01/app/oracle/admin/ohs_instance |
Oracle HTTP Serverインスタンス用のボリューム |
|
Web |
VOLWEBINST2 |
WEBHOST2 |
/u01/app/oracle/admin/ohs_instance |
Oracle HTTP Serverインスタンス用のボリューム |
|
Web |
VOLSTATIC1脚注1 |
WEBHOST1 |
/u01/app/oracle/admin/ohs_instance/config/static |
静的HTMLコンテンツ用のボリューム |
|
Web |
VOLSTATIC2脚注2 |
WEBHOST2 |
/u01/app/oracle/admin/ohs_instance/config/static |
静的HTMLコンテンツ用のボリューム |
|
アプリケーション |
VOLPFRD1 |
APPHOST1 |
/u01/app/oracle/product/fmw |
WebLogic Server、およびOracle Portal、Forms、ReportsおよびDiscovererバイナリ用のボリューム |
|
アプリケーション |
VOLPFRD2 |
APPHOST2 |
/u01/app/oracle/product/fmw |
WebLogic Server、およびOracle Portal、Forms、ReportsおよびDiscovererバイナリ用のボリューム |
|
アプリケーション |
VOLPFRDINST1 |
APPHOST1 |
/u01/app/oracle/admin |
Oracleインスタンス用のボリューム |
|
アプリケーション |
VOLPFRDINST2 |
APPHOST2 |
/u01/app/oracle/admin |
Oracleインスタンス用のボリューム |
|
アプリケーション |
VOLREPOUT |
APPHOST1、APPHOST2 |
/u01/app/oracle/admin |
レポート出力用のボリューム |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
図4-7に示されているOracle Portalトポロジと図4-8に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトについては、次のコンシステンシー・グループをお薦めします。
Web層のOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-9のWEBHOMEGROUPです。
Web層のOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-9のWEBINSTGROUPです。
アプリケーション層のMiddlewareホームを含むボリュームから成るコンシステンシー・グループを1つ作成します。これは、表4-9のPFRDMWGROUPです。
アプリケーション層のOracleインスタンス・ホームを含むボリュームから成るコンシステンシー・グループを1つ作成します。これは、表4-9のPFRDINSTGROUPです。
Oracle Reportsの出力ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-9のREPOUTGROUPです。
表4-9に、図4-7に示されているOracle Portalトポロジと図4-8に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトのコンシステンシー・グループに関する推奨事項の概要を示します。
表4-9 Oracle Portal、Forms、ReportsおよびDiscovererのコンシステンシー・グループ
| 層 | ボリューム名 | メンバー | コメント |
|---|---|---|---|
|
アプリケーション |
PFRDMWGROUP |
VOLPFRD2 VOLPFRD2 |
Middlewareホーム用のコンシステンシー・グループ |
|
アプリケーション |
PFRDINSTGROUP |
VOLPFRDINST1 VOLPFRDINST2 |
インスタンス・ホーム用のコンシステンシー・グループ |
|
アプリケーション |
REPOUTGROUP |
VOLREPOUT |
Reportsの出力ディレクトリ用のコンシステンシー・グループ |
|
Web |
WEBHOMEGROUP |
VOLWEB1 VOLWEB2 |
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
|
Web |
WEBINSTGROUP |
VOLWEBINST1 VOLWEBINST2 VOLSTATIC1脚注1 VOLSTATIC2脚注2 |
Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のOracle Enterprise Content Management管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、特に障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には、共有ストレージに配置することをお薦めします。図4-9は、Oracle Enterprise Content Management Suiteのディレクトリ構造のレイアウトを示しています。
図4-9 Oracle Enterprise Content Managementのディレクトリ構造
図4-9のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。
表4-10では、図4-9で色分けされている要素の意味を説明します。図4-9のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。
表4-10 ディレクトリ構造の要素
| 要素 | 説明 |
|---|---|
|
管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、および |
|
固定名です。 |
|
インストール依存名です。 |
このディレクトリ構造の設定の詳細は、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteエンタープライズ・デプロイメント・ガイドを参照してください。
図4-10は、Oracle Enterprise Content Managementのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle Enterprise Content Managementトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteエンタープライズ・デプロイメント・ガイドを参照してください。
このOracle Enterprise Content Managementトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。
製品の冗長バイナリを格納する2つのMiddlewareホーム用にボリュームを2つプロビジョニングします(表4-11のVOLFMW1およびVOLFMW2)。
管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-11のVOLADMIN)。
管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-11のVOLECM1およびVOLECM2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。
JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-11のVOLDATA)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。
Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-11のVOLWEB1およびVOLWEB2)。
Oracle HTTP ServerのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-11のVOLWEBINST1およびVOLWEBINST2)。
表4-11に、図4-10に示されているOracle Enterprise Content Management Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。
表4-11 Oracle Enterprise Content Managementのボリューム設計に関する推奨事項
| 層 | ボリューム名 | マウントされるホスト | マウント・ポイント | コメント |
|---|---|---|---|---|
|
Web |
VOLWEB1 |
WEBHOST1 |
/u01/app/oracle/product/fmw/web |
Oracle HTTP Serverインストール用のボリューム |
|
Web |
VOLWEB2 |
WEBHOST2 |
/u01/app/oracle/product/fmw/web |
Oracle HTTP Serverインストール用のボリューム |
|
Web |
VOLWEBINST1 |
WEBHOST1 |
/u01/app/oracle/admin/ohs_instance |
Oracle HTTP Serverインスタンス用のボリューム |
|
Web |
VOLWEBINST2 |
WEBHOST2 |
/u01/app/oracle/admin/ohs_instance |
Oracle HTTP Serverインスタンス用のボリューム |
|
Web |
VOLSTATIC1脚注1 |
WEBHOST1 |
/u01/app/oracle/admin/ohs_instance/config/static |
静的HTMLコンテンツ用のボリューム |
|
Web |
VOLSTATIC2脚注2 |
WEBHOST2 |
/u01/app/oracle/admin/ohs_instance/config/static |
静的HTMLコンテンツ用のボリューム |
|
アプリケーション |
VOLFMW1 |
ECMHOST1 |
/u01/app/oracle/product/fmw |
WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム |
|
アプリケーション |
VOLFMW2 |
ECMHOST2 |
/u01/app/oracle/product/fmw |
WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム |
|
アプリケーション |
VOLADMIN |
ECMHOST1 |
/u01/app/oracle/admin/ecmDomain/admin |
管理サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLECM1 |
ECMHOST1 |
/u01/app/oracle/admin/ecmDomain/mng1 |
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLECM2 |
ECMHOST2 |
/u01/app/oracle/admin/ecmDomain/mng2 |
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
|
アプリケーション |
VOLDATA |
ECMHOST1、ECMHOST2 |
/u01/app/oracle/admin/ecmDomain/soaCluster/jms /u01/app/oracle/admin/ecmDomain/soaCluster/tlogs |
トランザクション・ログおよびJMSデータ用のボリューム UCM関連の他のディレクトリは、ドメインの外部に構成されます。 UCMファイル(VaultおよびWeblayout)のボリュームはドメインの外部に作成されます。 |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle Enterprise Content Managementトポロジについては、次のコンシステンシー・グループをお薦めします。
管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-12のDOMAINGROUP)。
JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-12のDATAGROUP)。
Middlewareホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-12のFMWHOMEGROUP)。
Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-12のWEBHOMEGROUP)。
Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-12のWEBINSTANCEGROUP)。
表4-12に、図4-10に示されているOracle Enterprise Content Managementトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。
表4-12 Oracle Enterprise Content Managementのコンシステンシー・グループ
| 層 | グループ名 | メンバー | コメント |
|---|---|---|---|
|
アプリケーション |
DOMAINGROUP |
VOLADMIN VOLECM1 VOLECM2 |
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
|
アプリケーション |
DATAGROUP |
VOLDATA |
JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ |
|
アプリケーション |
FMWHOMEGROUP |
VOLFMW1 VOLFMW2 |
Middlewareホーム用のコンシステンシー・グループ |
|
Web |
WEBHOMEGROUP |
VOLWEB1 VOLWEB2 |
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
|
Web |
WEBINSTANCEGROUP |
VOLWEBINST1 VOLWEBINST2 VOLSTATIC1脚注1 VOLSTATIC2脚注2 |
Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定するには、次の手順を実行します。
スタンバイ・サイトで、本番サイトのピア・ホストに使用されている物理ホスト名と同じホスト名別名が作成されていることを確認します。
スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。
スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンクを作成します(スタンバイ・サイトでシンボリック・リンクを設定する必要があるのは、本番サイトでシンボリック・リンクを設定した場合のみです)。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。
本番サイトにインストールしたものと同じOracle Fusion Middlewareインスタンスをスタンバイ・サイトにインストールする必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているOracleソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。
共有ストレージ・ベンダーが規定しているその他の必要な構成を実行して、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のストレージ・レプリケーションを有効にします。
本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、本番サイトとスタンバイ・サイトの共有ストレージ間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。
スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。
Oracle Fusion Middleware障害時リカバリの本番サイトに含まれているデータベースの障害保護機能がOracle Data Guardによって提供されていることを確認します。Oracleデータベースの障害保護にストレージ・レプリケーション・テクノロジは使用しないでください。
スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。
本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行することを強くお薦めします。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。
Oracle Fusion Middleware障害時リカバリ・トポロジで使用するOracleデータベースの設定に関する推奨事項および考慮事項の詳細は、第3.3項「データベースに関する考慮事項」を参照してください。
Oracle Data Guardは、プライマリ・サイトとスタンバイ・サイトのOracle Fusion Middlewareリポジトリ・データベース間に設定する必要があります。スタンバイ・サイトのデータベースは、フィジカル・スタンバイ・データベースとして設定する必要があります。この項では、スタンバイ・サイトのデータ層の設定と構成について説明します。
Oracle Data Guardの詳細は、Oracle Databaseのドキュメント・セットの『Oracle Data Guard概要および管理』を参照してください。
後述のOracle Data Guardの設定および構成手順は、次の条件を満たしていることを前提としています。
スタンバイ・サイトのRACクラスタおよびASMインスタンスが作成されています。
スタンバイ・サイトおよび本番サイトのRACデータベースでフラッシュ・リカバリ領域を使用しています。
スタンバイ・サイトのデータベース・ホストにOracleソフトウェアがすでにインストールされています。
スタンバイ・サイトのDB_HOMEの物理パスが本番サイトのものと一致しています。
Oracle Data Guardの手順では、表4-13に記載されている環境変数を本番サイトのSOAデータベースに使用します。
表4-13 本番サイトのSOAデータベースに使用する環境変数
| 変数 | 値 |
|---|---|
|
SOAデータベースのホスト名 |
soadbhost1.mycompany.com soadbhost2.mycompany.com |
|
ORACLE_HOME |
/u01/app/oracle/product/db_1 |
|
SOA_DBNAME |
PSOA |
|
SOA_DB_UNIQUE_NAME |
PSOA |
|
SOA_DB_INSTANCE_NAMES |
PSOA1、PSOA2 |
Oracle Data Guardの手順では、表4-14に記載されている環境変数をスタンバイ・サイトのSOAデータベースに使用します。
表4-14 スタンバイ・サイトのSOAデータベースに使用する環境変数
| 変数 | 値 |
|---|---|
|
SOAデータベースのホスト名 |
soadbhost1.mycompany.com soadbhost2.mycompany.com |
|
ORACLE_HOME |
/u01/app/oracle/product/db_1 |
|
SOA_DBNAME |
PSOA |
|
SOA_DB_UNIQUE_NAME |
SSOA |
|
SOA_DB_INSTANCE_NAMES |
SSOA1、SSOA2 |
Oracle Data Guardの設定手順は、次の項で詳しく説明します。
ファイルを収集し、データベースのバックアップを実行する手順は、次のとおりです。
プライマリ・サイトのSOADBHOST1で、ステージング用のディレクトリを作成します。例:
$ mkdir -p /u01/app/stage/psoa
スタンバイ・サイトのSOADBHOST1で、同じパスを作成します。ステップ1に記載されている例に従ってください。
プライマリ・サイトのSOADBHOST1でデータベース・インスタンスpsoa1に接続し、spfileからpfileを作成します。例:
SQL > create pfile='/u01/app/stage/psoa/initpsoa.ora' from spfile;
プライマリ・サイトのSOADBHOST1でRMANに接続し、データベースのバックアップを実行して、ステージング・ディレクトリにバックアップ・ファイルを配置します。例:
$ $ORACLE_HOME/bin/rman target / RMAN> backup device type disk format '/u01/app/stage/psoa/%U' database plus archivelog; RMAN> backup device type disk format '/u01/app/stage/psoa/%U' current controlfile for standby;
次の手順に従って、RMANによって作成されたバックアップが有効であることを検証します。
プライマリ・サイトのSOADBHOST1でRMANに接続し、バックアップ・サマリを表示します。
ステップ4でRMANによって作成されたバックアップ・セットを検証します。
RMAN> list backup summary; using target database control file instead of recovery catalog List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 93 B A A DISK 14-MAY-07 1 1 NO TAG20070514T122312 94 B F A DISK 14-MAY-07 1 1 NO TAG20070514T122315 95 B F A DISK 14-MAY-07 1 1 NO TAG20070514T122315 96 B A A DISK 14-MAY-07 1 1 NO TAG20070514T122629 97 B F A DISK 14-MAY-07 1 1 NO TAG20070514T123220 RMAN> validate backupset 93; allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=451 instance=psoa1 devtype=DISK channel ORA_DISK_1: starting validation of archive log backupset channel ORA_DISK_1: reading from backup piece /u01/app/stage/psoa/34ihmtdg_1_1 channel ORA_DISK_1: restored backup piece 1 piece handle=/u01/app/stage/psoa/34ihmtdg_1_1 tag=TAG20070514T122312 channel ORA_DISK_1: validation complete, elapsed time: 00:00:02
プライマリ・サイトのSOADBHOST1で、listener.ora、sqlnet.oraおよびtnsnames.oraファイルを$ORACLE_HOME/network/adminディレクトリからステージング・ディレクトリにコピーします。
オペレーティング・システムのユーティリティを使用して、プライマリ・サイトのSOADBHOST1上のステージング・ディレクトリの内容をスタンバイ・サイトのSOADBHOST1上のステージング・ディレクトリにコピーします。
スタンバイ・サイトでOracle Net Servicesを構成する手順は、次のとおりです。
listener.ora、sqlnet.oraおよびtnsnames.oraファイルを、プライマリ・サイトのSOADBHOST1上のステージング・ディレクトリからスタンバイ・サイトのすべてのノード上の$ORACLE_HOME/network/adminディレクトリにコピーします。
各スタンバイ・ホストのlistener.oraファイルを、そのホストの仮想IPを含むように変更します。
プライマリRACノードやスタンバイRACノードなど各ノードのtnsnames.oraファイルを、プライマリおよびスタンバイのすべてのネット・サービス名を含むように変更します。
local_listenerおよびremote_listenerパラメータに使用されているOracle Netの別名を、各スタンバイ・ホストのリスナーを指すように変更します。次の例は、tnsnames.oraファイルの抜粋です。
#local_listener PSOA = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = soadbhost1-vip) (HOST = soadbhost2-vip) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = psoa) ) ) #remote_listener SSOA = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = soadbhost1-vip) (HOST = soadbhost2-vip) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ssoa) ) )
スタンバイ・データベース・ホストでリスナーを開始します。
スタンバイ・サイトでインスタンスおよびデータベースを作成する手順は、次のとおりです。
REDOデータを安全に送信するために、プライマリ・サイトとスタンバイ・サイトのデータベースでパスワード・ファイルを使用していることを確認するとともに、SYSユーザーのパスワードがすべてのシステムで同じであることを確認します。スタンバイ・データベースの両方のノードでパスワード・ファイルを作成してください。例:
スタンバイ・サイトのSOADBHOST1の場合
$ cd $ORACLE_HOME/dbs
$ orapwd file=orapwpsoa1 password=welcome1
スタンバイ・サイトのSOADBHOST2の場合
$ cd $ORACLE_HOME/dbs
$ orapwd file=orapwpsoa2 password=welcome1
スタンバイ・サイトのSOADBHOST1上のステージング領域から$ORACLE_HOME/dbsディレクトリにpfileをコピーし、名前を変更します。例:
$ cp /u01/app/stage/psoa/initpsoa.ora $ORACLE_HOME/dbs/initpsoa1.ora
プライマリ・ノードからコピーしたスタンバイの初期化パラメータ・ファイルを、表4-15に記載されているパラメータを含むように変更します。
表4-15 スタンバイの初期化パラメータ・ファイルで指定するパラメータ
| パラメータ | 値 |
|---|---|
|
RACパラメータ |
*.cluster_database=true PSOA1.instance_name=PSOA1 PSOA2.instance_name=PSOA2 PSOA1.instance_number=1 PSOA2.instance_number=2 PSOA1.thread=1 PSOA1.thread=2 PSOA1.undo_tablespace=UNDOTBS1 PSOA2.undo_tablespace=UNDOTBS2 *.remote_listener=LISTENERS_PSOA |
|
Data Guardパラメータ |
*.db_unique_name=SSOA *.log_archive_config='dg_config=(SSOA,PSOA)' *.log_archive_dest_2='service=PSOA valid_for=(online_logfiles,primary_role) db_unique_name=PSOA' *.db_file_name_convert='+DATA/PSOA/','+DATA/SSOA/','+RECO/PSOA','+RECO/SSOA' *.log_file_name_convert='+DATA/PSOA/','+DATA/SSOA/','+RECO/PSOA','+RECO/SSOA' *.standby_file_management=auto *.fal_server='PSOA' *.fal_client='SSOA' |
|
その他のパラメータ |
*.background_dump_dest=/u01/app/admin/PSOA/bdump *.core_dump_dest=/u01/app/admin/PSOA/cdump *.user_dump_dest=/u01/app/admin/PSOA/udump *.audit_file_dest=/u01/app/admin/PSOA/adump *.db_recovery_dest='+RECO' *.log_archive_dest_3='LOCATION=USE_DB_RECOVERY_FILE_DEST' *.dispatchers=PSOAXDB |
スタンバイ・サイトのSOADBHOST1上のASMインスタンスに接続し、スタンバイ・データベースのDB_UNIQUE_NAMEと同じ名前のディレクトリをDATAディスク・グループ内に作成します。例:
SQL> alter diskgroup data add directory '+DATA/SSOA';
スタンバイ・サイトのSOADBHOST1上のスタンバイ・データベースに接続し(スタンバイ・データベースはIDLE状態です)、スタンバイDATAディスク・グループにSPFILEを作成します。例:
SQL> CREATE SPFILE='+DATA/SSOA/spfilepsoa.ora' FROM PFILE='?/dbs/initpsoa1.ora';
スタンバイ・サイトのSOADBHOST1およびSOADBHOST2上の$ORACLE_HOME/dbsディレクトリで、SPFILEへのポインタを含むPFILEを作成します。PFILEは、init<OracleSID>.oraというネーミング規則に従う必要があります。例:
SOADBHOST1の場合
$ cd $ORACLE_HOME/dbs
$ echo "SPFILE='+DATA/SSOA/spfilepsoa.ora'" > initpsoa1.ora
SOADBHOST2の場合
$ cd $ORACLE_HOME/dbs
$ echo "SPFILE='+DATA/SSOA/spfilepsoa.ora'" > initpsoa2.ora
スタンバイの初期化パラメータ・ファイルで参照されているすべてのスタンバイ・ホストでダンプ・ディレクトリを作成します。例:
$ mkdir -p$ORACLE_BASE/admin/psoa/bdump $ mkdir -p$ORACLE_BASE/admin/psoa/cdump $ mkdir -p$ORACLE_BASE/admin/psoa/udump $ mkdir -p$ORACLE_BASE/admin/psoa/adump
スタンバイ・サイトのSOADBHOST1で、ORACLE_HOME、PATHおよびORACLE_SIDを設定し、制御ファイルをマウントせずにスタンバイ・データベースを開始します。このホストにはステージング・ディレクトリが必要です。例:
SQL > startup nomount
スタンバイ・インスタンスを開始したプライマリ・サイトのSOADBHOST1から、RMANを使用して、プライマリ・データベースをスタンバイとしてASMディスク・グループに複製します。例:
$ rman target sys/oracle@psoa auxiliary / RMAN> duplicate target database for standby;
SQL*Plusを使用して、新しく作成したデータベースにログインし、正しく作成されていることを検証します。例:
$ sqlplus '/as sysdba'
スタンバイ・サイトのSOADBHOST1上のスタンバイ・データベースに接続し、スタンバイ・ロールをサポートするためにスタンバイREDOログを作成します。例:
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 5 SIZE 300M, GROUP 6 SIZE 300M, GROUP 7 SIZE 300M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 8 SIZE 300M, GROUP 9 SIZE 300M, GROUP 10 SIZE 300M;
スタンバイ・サイトのSOADBHOST1で、スタンバイ・データベースでの管理リカバリおよびリアルタイム適用を開始します。例:
SQL> ALTER DATABASE recover managed standby database using current logfile disconnect;
スタンバイ・サイトのSOADBHOST1およびSOADBHOST2で、Server Control(SRVCTL)ユーティリティを使用して、スタンバイ・データベースとデータベース・インスタンスをOracle Cluster Registry(OCR)に登録します。例:
$ srvctl add database -d psoa -o /u01/app/oracle/product/10.2.0/db_1 $ srvctl add instance -d psoa -i psoa1 -n soadbhost1 $ srvctl add instance -d psoa -i psoa2 -n soadbhost2
データベースとASMインスタンス間に依存関係を確立します。例:
$ srvctl modify instance -d psoa -i psoa1 -s +ASM1 $ srvctl modify instance -d psoa -i psoa2 -s +ASM2 $ srvctl enable asm -n stbdd03 -i +ASM1 $ srvctl enable asm -n stbdd04 -i +ASM2
プライマリの初期化ファイルのData Guardパラメータを次の値に変更および追加して、Oracle Data Guardを使用するようにプライマリ・データベースを構成します。
*.log_archive_config='dg_config=(SSOA,PSOA)' *.log_archive_dest_2='service=SSOA valid_for=(online_logfiles,primary_role) db_unique_name=SSOA' *.db_file_name_convert='+DATA/SSOA/','+DATA/PSOA/','+RECO/SSOA','+RECO/PSOA' *.log_file_name_convert='+DATA/SSOA/','+DATA/PSOA/','+RECO/SSOA','+RECO/PSOA' *.standby_file_management=auto *.fal_server='PSOA' *.fal_client='PSOA'
パラメータを変更したら、プライマリ・データベースを再開します。
スタンバイ・ロールをサポートするために、プライマリ・データベースでスタンバイREDOログを作成します。例:
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 5 SIZE 300M, GROUP 6 SIZE 300M, GROUP 7 SIZE 300M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 8 SIZE 300M, GROUP 9 SIZE 300M, GROUP 10 SIZE 300M;
V$ARCHIVED_LOGビューへの問合せを実行して、アーカイブされたREDOログ内の既存のファイルを特定し、Oracle Data Guardの構成を確認します。例:
SQL> select sequence#, first_time, next_time from v$archived_log order by sequence#;
プライマリ・データベースで、次のSQL文を発行してログ切替えを強制し、現在のオンラインREDOログ・ファイル・グループをアーカイブします。
SQL> alter system archive log current;
スタンバイ・データベースでV$ARCHIVED_LOGビューへの問合せを実行して、REDOデータがスタンバイ・データベースで受信およびアーカイブされていることを確認します。
SQL> select sequence#, first_time, next_time from v$archived_log order by sequence#;
新しく作成したフィジカル・スタンバイ・データベースとプライマリRACデータベース間でデータベースのスイッチオーバー操作およびスイッチバック操作が正しく機能することをテストする手順は、次のとおりです。
プライマリ・サイトでRACデータベースの1つのインスタンス(PSOA)以外をすべて停止します。たとえば、本番サイトのSOADBHOST1で次のコマンドを実行します。
$ srvctl stop instance -d psoa -i psoa2
現在のプライマリ・データベースでフィジカル・スタンバイへのロール移行を開始します。たとえば、本番サイトのSOADBHOST1で次のコマンドを実行します。
SQL > ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
プライマリ・インスタンスを停止し、プライマリ・インスタンスをマウントします。たとえば、本番サイトのSOADBHOST1で次のコマンドを実行します。
SQL > shutdown immediate SQL > startup mount
これで、両方のデータベースがフィジカル・スタンバイ・モードになりました。両方のデータベースがフィジカル・スタンバイ・モードであることを確認するには、両方のデータベースで次のSQL問合せを実行します。
SQL> select database_role from v$database; DATABASE_ROLE ---------------- PHYSICAL_STANDBY
フィジカル・スタンバイ・データベース・ロールをプライマリ・ロールに切り替えます。たとえば、スタンバイ・サイトのSOADBHOST1で次のコマンドを実行します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
これで、フィジカル・スタンバイ・データベースが新しいプライマリになりました。
新しいプライマリ・データベースを停止し、srvctlを使用して、両方のRACノードを起動します。たとえば、スタンバイ・サイトのSOADBHOST1で次のコマンドを実行します。
srvctl start database -d psoa
新しいフィジカル・スタンバイ・データベース(元のプライマリ)で、データベースの管理リカバリを開始します。たとえば、プライマリ・サイトのSOADBHOST1で次のコマンドを実行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
新しいフィジカル・スタンバイ・データベースへのREDOデータの送信を開始します。たとえば、スタンバイ・サイトのSOADBHOST1で次のコマンドを実行します。
SQL> ALTER SYSTEM SWITCH LOGFILE;
V$ARCHIVED_LOGビューへの問合せを実行して、新しいフィジカル・スタンバイ・データベースでアーカイブ・ログ・ファイルが受信されているかどうかを確認します。
ノード・マネージャは、SSLを使用して管理サーバーと通信します。スタンバイ・サイトでこの通信が正しく機能するには、物理ホスト名を使用してSSL証明書を作成する必要があります。この項の項目は次のとおりです。
これらの項の例では、図4-2に示されているOracle SOA Suiteエンタープライズ・トポロジに対してこれらのタスクを実行する方法を紹介します。
次の手順に従って、自己署名証明書を生成します。
$WL_HOME/server/binディレクトリにあるsetWLSenvスクリプトを使用して、環境を設定します。
証明書用のユーザー定義ディレクトリを作成します。たとえば、$MW_HOME/user_projects/domains/SOADomainディレクトリ下にcertsディレクトリを作成します。
ユーザー定義ディレクトリからutils.CertGenツールを実行して、WebLogic Serverがインストールされているアプリケーション層ホストの証明書を作成します。構文は次のとおりです。
Syntax: java utils.CertGen <key_passphrase> <cert_file_name> <key_file_name> [export|domestic] [hostname]
たとえば、次のコマンドを入力します。
java utils.CertGen welcome1 soahost1_cert soahost1_key domestic soahost1 java utils.CertGen welcome1 soahost2_cert soahost2_key domestic soahost2
次の手順に従って、utils.ImportPrivateKeyユーティリティを使用してIDキーストアを作成します。
utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreというIDキーストアを新しく作成します。
このキーストアは、証明書と同じディレクトリに作成します。たとえば次のとおりです。
$MW_HOME/user_projects/domains/j2eeDomain/certs
utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートするときに、アイデンティティ・ストアが存在しなければ作成されます。
WebLogic Serverがインストールされているアプリケーション層ホストの証明書と秘密鍵をアイデンティティ・ストアにインポートします。必ず、インポートする証明書と鍵のペアごとに異なる別名を使用してください。
Syntax: java utils.ImportPrivateKey <keystore_file> <keystore_password> <certificate_alias_to_use> <private_key_passphrase> <certificate_file> <private_key_file> [<keystore_type>]
たとえば、次のコマンドを入力します。
java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 appIdentity1 welcome1$MW_HOME/user_projects/domains/SOADomain/certs/soahost1_cert.pem$MW_HOME/user_projects/domains/SOADomain/certs/soahost1_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 appIdentity2 welcome1$MW_HOME/user_projects/domains/SOADomain/certs/soahost2_cert.pem$MW_HOME/user_projects/domains/SOADomain/certs/soahost2_key.pem
次の手順に従って、信頼キーストアを作成します。
keytoolユーティリティを使用して、appTrustKeyStoreという信頼キーストアを新しく作成します。
新しい信頼キーストアを作成するには、必要なルートCA証明書のほとんどがすでに含まれている、標準Javaキーストアを使用します。標準Java信頼キーストアは、直接変更しないようにすることをお奨めします。
$WL_HOME/server/libディレクトリにある標準Javaキーストアcacertsを証明書と同じディレクトリにコピーします。例:
cp $WL_HOME/server/lib/cacerts
$MW_HOME/user_projects/domains/SOADomain/certs/appTrustKeyStore.jks
標準Javaキーストアのデフォルト・パスワードはchangeitです。デフォルト・パスワードは、keytoolユーティリティを使用して、必ず変更するようにしてください。構文は次のとおりです。
keytool -storepasswd -new <NewPassword> -keystore <TrustKeyStore> -storepass <Original Password>
たとえば、次のコマンドを入力します。
keytool -storepasswd -new welcome1 -keystore appTrustKeyStore.jks -storepass changeit
CA証明書CertGenCA.derは、utils.CertGenツールによって生成されたすべての証明書への署名に使用され、$WL_HOME/server/libディレクトリにあります。keytoolユーティリティを使用して、このCA証明書をappTrustKeyStoreにインポートする必要があります。構文は次のとおりです。
keytool -import -v -noprompt -trustcacerts -alias <AliasName> -file <CAFileLocation> -keystore <KeyStoreLocation> -storepass <KeyStore Password>
たとえば、次のコマンドを入力します。
keytool -import -v -noprompt -trustcacerts -alias clientCACert -file
$WL_HOME/server/lib/CertGenCA.der -keystore appTrust.jks -storepass welcome1
$WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後にある次の行を編集して、新しく作成したカスタム・キーストアを使用するように各ノードのノード・マネージャを構成します。これらの行とその意味は次のとおりです。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=<Identity KeyStore> CustomIdentityKeyStorePassPhrase=<Identity KeyStore Password> CustomIdentityAlias=<Identity Key Store Alias> CustomIdentityPrivateKeyPassPhrase=<Private Key used when creating Certificate> CustomTrustKeyStoreFileName=<Trust KeyStore> CustomTrustKeyStorePassPhrase=<Trust KeyStore Password>
たとえば、SOAHOST1のnodemanager.propertiesファイルで次のように編集します。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=$MW_HOME/user_projects/domains/SOADomain/certs /appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=welcome1 CustomIdentityAlias=appIdentity1 CustomIdentityPrivateKeyPassPhrase=welcome1 CustomTrustKeyStoreFileName=$MW_HOME/user_projects/domains/SOADomain/certs /appTrust.jks CustomTrustKeyStorePassPhrase=welcome1
たとえば、SOAHOST2のnodemanager.propertiesファイルで次のように編集します。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=$MW_HOME/user_projects/domains/SOADomain/certs /appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=welcome1 CustomIdentityAlias=appIdentity2 CustomIdentityPrivateKeyPassPhrase=welcome1 CustomTrustKeyStoreFileName=$MW_HOME/user_projects/domains/SOADomain/certs /appTrust.jks CustomTrustKeyStorePassPhrase=welcome1
この項では、本番サイトを作成する手順を説明します。Oracle SOAのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用します。
本番サイトの作成を開始する前に、次の事前準備が完了していることを確認してください。
中間層ホストのホスト名別名を設定します。第3.1.1項「ホスト名の計画」を参照してください。
本番サイトの共有ストレージに必要なボリュームを作成します。第4.1.1項「ディレクトリ構造とボリューム設計」を参照してください。
マウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。第3.2.3項「ストレージ・レプリケーション」を参照して、本番サイトにシンボリック・リンクを作成する必要があるかどうかを確認してください。
詳細は、次を参照してください。
本番サイトは、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。
第4.1.1.1.1項「Oracle SOA Suiteのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。
『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従って、Oracle SOA Suiteをインストールおよび構成します。ただし、次の点が異なります。
共有ストレージ・デバイス上に作成したボリュームにOracle SOA Suiteコンポーネントをインストールします。
WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。
JMSストアおよびトランザクション・ログ用に各サイトで別個のボリュームを作成します。
本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーのホスト名検証の無効化に関する項を参照してください。
ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。
ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
本番サイトは、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。
第4.1.1.3.1項「Oracle Identity Managementのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。
『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の説明に従って、Oracle Identity Managementをインストールおよび構成します。ただし、次の点が異なります。
共有ストレージ・デバイス上に作成したボリュームにOracle Identity Managementコンポーネントをインストールします。
WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。
JMSストアおよびトランザクション・ログ用に各サイトで別個のボリュームを作成します。
本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーのホスト名検証の無効化に関する項を参照してください。
ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。
ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
本番サイトは、『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』の説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。
第4.1.1.2.1項「Oracle WebCenterのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。
『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』の説明に従って、Oracle WebCenterをインストールおよび構成します。ただし、次の点が異なります。
共有ストレージ・デバイス上に作成したボリュームにOracle WebCenterコンポーネントをインストールします。
WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。
本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』のOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーのホスト名検証の無効化に関する項を参照してください。
ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。
ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
本番サイトは、Oracle Fusion Middleware Oracle Enterprise Content Management Suiteエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。
第4.1.1.5.1項「Oracle Enterprise Content Managementのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。
Oracle Fusion Middleware Oracle Enterprise Content Management Suiteエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle Enterprise Content Managementをインストールおよび構成します。ただし、次の点が異なります。
共有ストレージ・デバイス上に作成したボリュームにOracle Enterprise Content Managementコンポーネントをインストールします。
WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。
本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle Enterprise Content Management Suitエンタープライズ・デプロイメント・ガイドの管理サーバーのホスト名検証の無効化に関する項を参照してください。
ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。
ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
本番サイトは、次の製品のエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要があります。
Oracle Portal
図4-7に示されているOracle Portalエンタープライズ・トポロジを使用する本番サイトを設定および構成する手順の詳細は、11.1.1.2 Oracle Portalエンタープライズ・デプロイメント・ガイドに記載されています。このマニュアルの入手方法は、My Oracle Support(以前のOracle MetaLink)にある記事ID 952068.1「Oracle Fusion Middleware 11g(11.1.1.2)Portal、Forms、ReportsおよびDiscoverエンタープライズ・デプロイメント・ガイド」を参照してください。My Oracle SupportのURLは次のとおりです。
Oracle Forms、ReportsおよびDiscoverer
図4-8に示されているOracle Forms、ReportsおよびDiscovererエンタープライズ・トポロジを使用する本番サイトを設定および構成する手順の詳細は、11.1.1.2 Oracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメント・ガイドに記載されています。このマニュアルの入手方法は、My Oracle Support(以前のOracle MetaLink)にある記事ID 952068.1「Oracle Fusion Middleware 11g(11.1.1.2)Portal、Forms、ReportsおよびDiscoverエンタープライズ・デプロイメント・ガイド」を参照してください。My Oracle SupportのURLは次のとおりです。
前述のマニュアルの説明に従ってインストールおよび構成を行う必要がありますが、次のような違いがあります。示された手順に従ってください。
第4.1.1.4.1項「Oracle Portal、Forms、ReportsおよびDiscoverのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。
前述のリンク先のホワイト・ペーパーの説明に従って、Oracle Portal、Forms、ReportsおよびDiscovererをインストールおよび構成します。ただし、次の点が異なります。
共有ストレージ・デバイス上に作成したボリュームにOracle Portal、Forms、ReportsおよびDiscovererコンポーネントをインストールします。
WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。
本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、『Oracle Fusion Middleware Oracle WebCenterエンタープライズ・デプロイメント・ガイド』のOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーのホスト名検証の無効化に関する項を参照してください。
ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。
ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
Oracle SOA Suiteエンタープライズ・トポロジの本番サイトの設定を検証するには、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の次の項に記載されている検証手順を実行します。
「Oracle HTTP Serverのインストール」の次の項に記載されている検証手順
ロード・バランサを使用したOracle HTTP Serverの検証に関する項
「ドメインの作成」の次の項に記載されている検証手順
管理サーバーの検証に関する項
WLS_WSM1管理対象サーバーの起動と検証に関する項
WLS_WSM2管理対象サーバーの起動と検証に関する項
Oracle HTTP Serverを介したアクセスの検証に関する項
Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証に関する項
「SOAコンポーネントを使用するためのドメインの拡張」の次の項に記載されている検証手順
WLS_SOA1およびWLS_WSM1管理対象サーバーの検証に関する項
WLS_SOA2管理対象サーバーの起動と検証に関する項
Oracle HTTP Serverを介したアクセスの検証に関する項
「BAMを追加するためのドメインの拡張」の次の項に記載されている検証手順
Oracle HTTP Serverを介したアクセスの検証に関する項
この項では、スタンバイ・サイトを作成する手順を説明します。Oracle SOAのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用します。
次のトピックがあります。
スタンバイ・サイトの作成を開始する前に、次の事前準備が完了していることを確認してください。
スタンバイ・サイトで、第3.1.1項「ホスト名の計画」の手順に従って、ホスト名別名および物理ホスト名が正しく設定されていることを確認します。
スタンバイ・サイトの各ホストに、本番サイトのピア・ホストの物理ホスト名と同じホスト名別名が設定されていることを確認してください。
スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。
スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。
Oracle Data Guardは、プライマリ・サイトとスタンバイ・サイトのOracle Fusion Middlewareリポジトリ・データベース間に設定する必要があります。スタンバイ・サイトのデータベースは、フィジカル・スタンバイ・データベースとして設定する必要があります。プライマリ・サイトおよびスタンバイ・サイトでメタデータ・リポジトリを実行するデータベース間にOracle Data Guardを設定する手順は、第4.1.3.1項「Oracle Data Guardの設定」を参照してください。
また、スタンバイ・サイトでメタデータ・リポジトリを実行するデータベースが管理リカバリ・モードであることを確認してください。スタンバイ・データベースを管理リカバリ・モードにするには、次のSQLコマンドを実行します(disconnectオプションを指定すると、コマンドが正常に完了した後、SQLセッションが終了します)。
SQL> ALTER DATABASE RECOVERY MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
スタンバイ・サイトの中間層ホストでは、Oracle Fusion MiddlewareおよびWebLogic Serverソフトウェアのインストールや構成を行う必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。
スタンバイ・サイトの中間層ホストを設定する手順は、次のとおりです。
本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、ストレージ・デバイス間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。
本番サイトの共有ストレージをスタンバイ・サイトの共有ストレージと同期します。これによって、本番サイトからスタンバイ・サイトに初期のベースライン・スナップショットが転送されます。
スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。
ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。
次の手順に従って、スタンバイ・サイトを検証します。
本番サイトで実行中のすべてのプロセス(データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンス、およびアプリケーション層とWeb層のその他のプロセス)を停止します。
本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。
Oracle Data Guardを使用して、データベースをフェイルオーバーします。
スタンバイ・サイトのホストで、すべてのプロセス(データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンス、およびアプリケーション層とWeb層のその他のプロセス)を手動で開始します。
ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。
この項の手順では、Oracle Fusion Middleware障害時リカバリの非対称トポロジを設定する方法を説明します。
非対称トポロジは、本番サイトとスタンバイ・サイトの層で異なる障害時リカバリ構成です。Oracle Fusion Middleware障害時リカバリのほとんどの非対称トポロジでは、スタンバイ・サイトのリソースの数が本番サイトより少なくなっています。
この項を読む前に必ず、このマニュアルで前述した対称トポロジの設定に関する概念と情報に目を通し、理解しておいてください。対称トポロジの設定に関する概念の多くは、非対称トポロジを設定する際にも有効です。
第4.4.1項「非対称スタンバイ・サイトの作成」では、非対称トポロジを作成する際の基本的な手順を説明します。この章の前半で対称トポロジについてすでに説明した、非対称トポロジの設定に適用される概念については、詳しく説明しません。
この項では、Oracle Fusion Middleware障害時リカバリのあらゆるタイプの非対称トポロジを作成する際の大まかな手順を説明します。本番サイトは、図4-2に示されているOracle SOA Suiteのエンタープライズ・デプロイメントです。スタンバイ・サイトは本番サイトと異なるものになります。
非対称トポロジを作成する手順は次のとおりです。
本番サイトとスタンバイ・サイトを設計します。スタンバイ・サイトが本番ロールを引き継いだときに許容されるパフォーマンスを確保できるように、スタンバイ・サイトで必要となるリソースを特定してください。
|
注意: スタンバイ・サイト・インスタンスのポートでは、本番サイトのピア・インスタンスと同じポート番号を使用する必要があります。そのため、スタンバイ・サイトで必要となるすべてのポート番号が使用可能である(スタンバイ・サイトで使用中でない)ことを確認してください。 |
次の操作を実行して、Oracle Fusion Middleware障害時リカバリの本番サイトを作成します。
本番サイトの共有ストレージ・システムで、本番サイト用にインストールするOracle Fusion Middlewareインスタンスのボリュームを作成します。詳細は、第4.1.1項「ディレクトリ構造とボリューム設計」を参照してください。
本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。ボリューム設計の詳細は、第4.1.1.1.1項「Oracle SOA Suiteのボリューム設計」を参照してください。
本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。Oracle中央インベントリ・ディレクトリの詳細は、第3.2.2項「OracleホームとOracleインベントリ」を参照してください。
本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle HTTP Serverインスタンスに対して、静的HTMLページ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します(該当する場合)。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。
本番サイトの共有ストレージ・システムのボリュームに、本番サイト用のOracle Fusion Middlewareインスタンスをインストールします。詳細は、第4.2.1項「Oracle SOA Suiteトポロジの本番サイトの作成」を参照してください。
スタンバイ・サイトの共有ストレージ・システムでも、本番サイトの共有ストレージ・システムでOracle Fusion Middlewareインスタンスに対して作成したのと同じボリュームを、同じファイル権限とディレクトリ権限で作成します。この手順は重要です。これにより、後からストレージ・レプリケーションを使用してスタンバイ・サイト用にOracle Fusion Middlewareのピア・インスタンスのインストールを作成できるようになり、Oracle Universal Installerを使用したインストールが不要になるからです。
|
注意: ストレージ・レプリケーションを構成する際には、本番サイトの共有ストレージ・システムで設定したすべてのボリュームがスタンバイ・サイトの共有ストレージ・システム上の同じボリュームにレプリケートされるようにしてください。本番サイトの一部のインスタンスやホストがスタンバイ・サイトに存在しない場合でも、本番サイトのOracle Fusion Middlewareインスタンスに対して設定したすべてのボリュームでストレージ・レプリケーションを構成する必要があります。 |
共有ストレージ・ベンダーが規定しているその他の必要な構成を実行して、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にします。本番サイトの共有ストレージ・システムのボリュームをスタンバイ・サイトの共有ストレージ・システムに非同期でコピーするように、ストレージ・レプリケーションを構成してください。
本番サイトの共有ストレージ・システムの初期のベースライン・スナップショット・コピーを作成して、本番サイトとスタンバイ・サイトの共有ストレージ・システム間のレプリケーションを設定します。初期のベースライン・スナップショット・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリュームのすべてのディレクトリの内容が本番サイトのボリュームのディレクトリと同じであることを検証します。初期のスナップショットを作成する方法、および本番サイトとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にする方法の詳細は、共有ストレージ・ベンダーのドキュメントを参照してください。
ベースライン・スナップショットを作成したら、スタンバイ・サイトのホストでOracle Fusion Middlewareインスタンスについて次の手順を実行します。
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。
スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。
スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。
スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。
前述の手順が完了すると、本番サイトのOracle Fusion Middlewareインスタンスのインストールがスタンバイ・サイトにレプリケートされます。スタンバイ・サイトは、次のすべての項目に該当する状態となります。
Oracle Fusion Middlewareインスタンスは、本番サイトと同じボリューム上の同じOracleホーム・ディレクトリにインストールされています。また、ホストでは、Oracleホーム・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。
Oracle中央インベントリ・ディレクトリは、本番サイトと同じボリューム上の同じディレクトリにあります。また、ホストでは、Oracle中央インベントリ・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。
Oracle HTTP Serverの静的HTMLページ・ディレクトリは、本番サイトと同じボリューム上の同じディレクトリにあります。また、ホストでは、Oracle HTTP Serverの静的HTMLページ・ディレクトリに対して本番サイトと同じマウント・ポイント・ディレクトリおよびシンボリック・リンクが使用されています。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。
スタンバイ・サイトのOracle Fusion Middlewareインスタンスには、本番サイトの同じインスタンスに使用されているものと同じポートが使用されています。
この項では、ホストおよびOracle Fusion Middlewareインスタンスの数が本番サイトより少ない非対称スタンバイ・サイトを作成する方法を説明します。
このOracle Fusion Middleware障害時リカバリ・トポロジの本番サイトは、図4-2に示されているOracle SOA Suiteのエンタープライズ・デプロイメントです。この本番サイトとその共有ストレージ・システムのボリュームを設定する方法、および必要なマウント・ポイントを作成する方法は、第4.1項「サイトの設定」から第4.1.1項「ディレクトリ構造とボリューム設計」に記載されています。
図4-11に、図4-2に示されている本番サイトの非対称スタンバイ・サイトを示します。
図4-11に示されているOracle SOA Suiteの非対称スタンバイ・サイトのホストおよびインスタンスの数は、図4-2に示されているOracle SOA Suiteの本番サイトより少なくなっています。
図4-2の本番サイトには、ホストWEBHOST2およびSOAHOST2とこれらのホスト上のインスタンスが存在しますが、図4-11の非対称スタンバイ・サイトには、これらのホストとそのインスタンスが存在しません。そのため、スタンバイ・サイトのホストおよびインスタンスの数は、本番サイトより少なくなっています。
この非対称スタンバイ・サイトには、本番ロールを引き継いだときに適切なパフォーマンスを提供できるように、十分なリソースを確保することが重要です。
第4.4.1項「非対称スタンバイ・サイトの作成」に記載されている手順に従って、この非対称スタンバイ・サイトを設定すれば、スタンバイ・サイトは本番ロールを引き継ぐように適切に構成されます。
非対称スタンバイ・サイトを正しく設定するには、本番サイトの共有ストレージで作成したものと同じボリュームおよびコンシステンシー・グループをスタンバイ・サイトの共有ストレージで作成します。たとえば、Oracle SOA Suiteデプロイメントについて、表4-4のボリューム設計に関する推奨事項と表4-5のコンシステンシー・グループに関する推奨事項を使用して、本番サイトの共有ストレージを設定したとします。その場合、本番サイトの共有ストレージに使用したものと同じボリューム設計に関する推奨事項とコンシステンシー・グループに関する推奨事項を使用して、非対称スタンバイ・サイトの共有ストレージを設定します。
非対称スタンバイ・サイトでは、本番サイトに存在する一部のホストがスタンバイ・サイトに存在しません。たとえば、図4-11に示されているOracle SOA Suiteの非対称スタンバイ・サイトの場合、WEBHOST2とSOAHOST2がスタンバイ・サイトに存在しません。そのため、スタンバイ・サイトの共有ストレージ・ボリュームに対してこれらのホスト上にマウント・ポイントを作成することはできず、作成する必要はありません。
次の手順に従って、スタンバイ・サイトを検証します。
本番サイトで実行中のすべてのプロセス(データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンス、およびアプリケーション層とWeb層のその他のプロセス)を停止します。
本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。
Oracle Data Guardを使用して、データベースをフェイルオーバーします。
スタンバイ・サイトのホストで、すべてのプロセス(データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンス、およびアプリケーション層とWeb層のその他のプロセス)を手動で開始します。
ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。
この項では、Oracle Fusion Middleware障害時リカバリ・トポロジで実行する操作および管理について説明します。
スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。
本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行する必要があります。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。
Oracle Fusion Middleware障害時リカバリ・トポロジでのデータベースの同期は、Oracle Data Guardによって管理されます。
本番サイトを停止し(保守を行う場合など)、現在のスタンバイ・サイトを新しい本番サイトにする場合は、スタンバイ・サイトが本番ロールを引き継ぐように、スイッチオーバー操作を実行する必要があります。
本番サイトで実行中のすべてのプロセス(データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンス、およびアプリケーション層とWeb層のその他のプロセス)を停止します。
本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。
Oracle Data Guardを使用して、データベースをスイッチオーバーします。
スタンバイ・サイトのホストで、すべてのプロセス(データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンス、およびアプリケーション層とWeb層のその他のプロセス)を手動で開始します。
グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがスタンバイ・サイトにルーティングされるようにします。
ブラウザ・クライアントを使用してスイッチオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。
これで、元のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトが新しいスタンバイ・サイトになりました。
2つのサイト間のレプリケーションを再確立します。ただし、スナップショット・コピーが逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。
前述の手順が完了すると、元のスタンバイ・サイトが新しい本番サイトになります。これで、元の本番サイトで保守を実行できるようになります。予定していた作業を元の本番サイトで実行した後、将来のいずれかの時点で、そのサイトを本番サイトまたはスタンバイ・サイトとして再度使用できます。
元の本番サイトを新しい本番サイトとして使用するには、第4.5.3項「スイッチバックの実行」に記載されているスイッチバック手順を実行してください。
スイッチオーバー操作を実行した後、スイッチバック操作を実行して、現在の本番サイトと現在のスタンバイ・サイトをスイッチオーバー操作前のロールに戻すことができます。
現在の本番サイトで実行中のすべてのプロセス(データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンス、およびアプリケーション層とWeb層のその他のプロセス)を停止します。
現在の本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。
Oracle Data Guardを使用して、データベースをスイッチバックします。
新しい本番サイトのホストで、すべてのプロセス(データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンス、およびアプリケーション層とWeb層のその他のプロセス)を手動で開始します。
グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストが新しい本番サイトにルーティングされるようにします。
ブラウザ・クライアントを使用してスイッチバック後のテストを実行し、リクエストが解決されて新しい本番サイトにリダイレクトされていることを確認します。
これで、元のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトが新しいスタンバイ・サイトになりました。
2つのサイト間のレプリケーションを再確立します。ただし、スナップショット・コピーが逆方向に(新しい本番サイトから新しいスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。
本番サイトが予期せず使用できなくなった場合、スタンバイ・サイトが本番ロールを引き継ぐように、フェイルオーバー操作を実行する必要があります。
本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。
スタンバイ・サイトから、Oracle Data Guardを使用して、データベースをフェイルオーバーします。
スタンバイ・サイトのホストで、すべてのプロセス(データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンス、およびアプリケーション層とWeb層のその他のプロセス)を手動で開始します。
グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがスタンバイ・サイトにルーティングされるようにします。
ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されて本番サイトにリダイレクトされていることを確認します。
これで、スタンバイ・サイトが新しい本番サイトになりました。元の本番サイトが使用できなくなった原因を調べることができます。
元の本番サイトを現在のスタンバイ・サイトとして使用するには、2つのサイト間のレプリケーションを再確立する必要があります。ただし、スナップショット・コピーが逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージ・システムのドキュメントを参照してください。
元の本番サイトを新しい本番サイトとして使用するには、第4.5.3項「スイッチバックの実行」に記載されているスイッチバック手順を実行してください。
このマニュアルでは、Oracle Fusion Middlewareの本番サイトとスタンバイ・サイトの障害時リカバリを設定する方法を説明します。Oracle Fusion Middleware障害時リカバリの通常の構成は、次のようになっています。
ストレージ・レプリケーションを使用して、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージにOracle Fusion Middlewareの中間層のファイル・システムおよびデータをコピーします。通常の操作時には、本番サイトはアクティブで、スタンバイ・サイトはパッシブです。本番サイトがアクティブな場合、スタンバイ・サイトはパッシブで、スタンバイ・サイトの共有ストレージは読取り専用モードです。スタンバイ・サイトの共有ストレージに対して行われる書込み操作は、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージへのストレージ・レプリケーション操作のみです。
Oracle Data Guardを使用して、本番サイトのOracleデータベースのデータベース・データをスタンバイ・サイトのスタンバイ・データベースにコピーします。デフォルトでは、本番サイトのデータベースはアクティブで、スタンバイ・サイトのスタンバイ・データベースはパッシブです。スタンバイ・サイトがスタンバイ・ロールの間(パッシブである間)、スタンバイ・サイトのスタンバイ・データベースは管理リカバリ・モードです。本番サイトがアクティブな場合、スタンバイ・データベースに対して行われる書込み操作は、Oracle Data Guardによって実行されるデータベースの同期操作のみです。
本番サイトが使用できなくなったときには、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。現在の本番サイトが予期せず使用できなくなった場合は、フェイルオーバー操作(第4.5.4項「フェイルオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。また、現在の本番サイトを意図的に停止する場合は(予定した保守の場合など)、スイッチオーバー操作(第4.5.2項「スイッチオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。
通常の方法でスタンバイ・サイトをテストする場合は、現在の本番サイトを停止し、スイッチオーバー操作を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。ただし、企業では、現在の本番サイトを停止してスイッチオーバー操作を実行することなく、障害時リカバリのスタンバイ・サイトの定期テストを実行することもできます。
現在の本番サイトを停止せずにスタンバイ・サイトをテストする代替方法では、スタンバイ・サイトの読取り専用共有ストレージのクローンを作成し、クローニングされたスタンバイ・サイトの共有ストレージをテストで使用します。この代替テスト方法を使用する手順は、次のとおりです。
共有ストレージ・ベンダーが提供しているクローニング・テクノロジを使用して、スタンバイ・サイトの共有ストレージでスタンバイ・サイトの読取り専用ボリュームのクローンを作成します。クローニングされたスタンバイ・サイトのボリュームが書込み可能であることを確認します。スタンバイ・サイトを1回だけテストする場合は、1回のみのクローン操作とすることができます。ただし、スタンバイ・サイトを定期的にテストする場合は、スタンバイ・サイトのクローニングされた読取り/書込みボリュームへのスタンバイ・サイトの読取り専用ボリュームの定期クローニングを設定できます。
スタンバイ・サイトのデータベースのバックアップを実行し、本番サイトとスタンバイ・サイトのデータベース間のOracle Data Guardレプリケーションを変更します。
10.1のデータベースについては、10.1 Oracle Data Guardのドキュメントに記載されている手順に従って、レプリケーションを中断します。
10.2以降のデータベースについては、次の手順に従って、スナップショット・スタンバイ・データベースを確立します。
フラッシュ・リカバリ領域がない場合は、設定します。
REDO Applyを取り消します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE CANCEL;
保証付きリストア・ポイントを作成します。
SQL> CREATE RESTORE POINT standbytest
GUARANTEE FLASHBACK DATABASE;
プライマリ(本番)サイトで現在のログをアーカイブします。
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
アクティブ化するスタンバイ・サイト接続先を遅延させます。
SQL> ALTER SYSTEM SET
LOG_ARCHIVE_DEST_STATE_2=DEFER;
ターゲット・スタンバイ・データベースをアクティブ化します。
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
データベースが読取り専用で開いている場合、Forceオプションを指定してデータベースをマウントします。
SQL> STARTUP MOUNT FORCE;
保護モードを下げて、データベースを開きます。
SQL> ALTER DATABASE SET STANDBY DATABASE TO
MAXIMIZE PERFORMANCE;
SQL> ALTER DATABASE OPEN;
11gのデータベースについては、『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースの管理に関する項に記載されている手順に従って、スナップショット・スタンバイ・データベースを確立します。
Oracle Data Guardのデータベース・リカバリ手順に従って、スタンバイ・データベースをオンラインにします。
スタンバイ・サイトのコンピュータで、次の手順に従って、スタンバイ・サイトのクローニングされた読取り/書込み共有ストレージ・ボリュームを指すようにmountコマンドを変更します。
読取り専用の共有ストレージ・ボリュームをアンマウントします。
クローニングされた読取り/書込みボリュームを同じマウント・ポイントでマウントします。
スタンバイ・サイトのテストを実行する前に、ホスト名が本番サイトのコンピュータではなくスタンバイ・サイトのコンピュータを指すように、テストの実行に使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、スタンバイ・サイトのロード・バランサの仮想IPを指すように/etc/hostsファイルを変更します。
スタンバイ・サイトのテストを実行します。
スタンバイ・サイトのテストが完了したら、次の手順に従って、元の本番サイトを本番サイトとして再度使用します。
スタンバイ・サイトのコンピュータで、スタンバイ・サイトの読取り専用共有ストレージ・ボリュームを指すようにmountコマンドを変更します。つまり、mountコマンドを、テストを実行する前の状態に戻します。
クローニングされた共有ストレージの読取り/書込みボリュームをアンマウントします。
読取り専用の共有ストレージ・ボリュームをマウントします。
これで、mountコマンドがスタンバイ・サイトのテストを実行する前の状態にリセットされました。
本番サイトのデータベースとスタンバイ・サイトのスタンバイ・データベース間のレプリケーションを実行するように、Oracle Data Guardを構成します。この構成を実行すると、スタンバイ・データベースは再度、管理リカバリ・モードに設定されます。
10.1のデータベースについては、10.1 Oracle Data Guardのドキュメントに記載されている手順に従って、データベースを再インスタンス化します。
10.2以降のデータベースについては、次の手順に従います。
アクティブ化したデータベースをフィジカル・スタンバイ・データベースに戻します。
SQL> STARTUP MOUNT FORCE; SQL> FLASHBACK DATABASE TO POINT standbytest; SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> STARTUP MOUNT FORCE;
管理リカバリを再開します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE USING CURRENT LOGFILE DISCONNECT;
スタンバイ接続先を再度有効にし、ログを切り替えます。
SQL> ALTER SYSTEM SET
LOG ARCHIVE DEST STATE 2=ENABLE;
11gのデータベースについては、『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースの管理に関する項に記載されている手順に従って、レプリケーションを再度設定します。
元の本番サイトを再度使用する前に、ホスト名がスタンバイ・サイトのコンピュータではなく本番サイトのコンピュータを指すように、本番サイトへのアクセスに使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、本番サイトのロード・バランサの仮想IPを指すように/etc/hostsファイルを変更します。
Oracle Fusion Middleware中間層コンポーネントの障害保護および障害時リカバリにストレージ・レプリケーション・テクノロジを使用する代わりに、テスト環境でpeer-to-peerファイル・コピー・メカニズムを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトのホストからスタンバイ・サイトのピア・ホストに中間層のファイル・システム・データをレプリケートできます。peer-to-peerファイル・コピー・メカニズムの例として、rsync(UNIXシステムのオープン・ソース・ユーティリティ)があります。
この項では、Oracle Fusion Middleware障害時リカバリ・トポロジでストレージ・レプリケーションの代わりにrsyncを使用する方法を説明します。ここでは、対称トポロジのコンテキストにおけるrsyncについて説明します。対称トポロジの詳細は、第4.4項「非対称スタンバイ・サイトの作成」を参照してください。この項でrsyncについて記載されている情報は、他のpeer-to-peerファイル・コピー・メカニズムにも適用されます。
この項を読む前に、このマニュアルの他の部分にも目を通し、Oracle Fusion Middleware障害時リカバリ・トポロジでストレージ・レプリケーションとOracle Data Guardを使用する方法を理解しておいてください。Oracle Fusion Middlewareコンポーネントの障害保護および障害時リカバリでのストレージ・レプリケーションとrsyncの使用には、多くの類似点があります。
|
注意: ストレージ・レプリケーション・テクノロジの代わりにrsyncを使用して、本番サイトからスタンバイ・サイトに中間層のファイル・システム・データをレプリケートできます。ただし、rsyncを使用した場合、次のようなストレージ・レプリケーションの便利な機能を使用することはできません。
ストレージ・レプリケーションと比較すると、このような短所があるため、実際の本番環境では、障害時リカバリにrsyncを使用することはできません。 |
rsyncとOracle Data Guardを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの障害保護および障害時リカバリを実現するときには、次の2つの基本原則が適用されます。
Oracle Fusion Middleware中間層コンポーネントの障害保護には、rsyncを使用します。
Oracle Fusion Middlewareトポロジで使用されるOracleデータベースの障害保護には、Oracle Data Guardを使用します。Oracleデータベースの障害時リカバリを実現するようにOracle Data Guardを設定する方法の詳細は、第3.3項「データベースに関する考慮事項」を参照してください。
rsyncを使用してOracle Fusion Middleware中間層コンポーネントの障害保護および障害時リカバリを実現する手順は、次のとおりです。
本番サイトのホストからスタンバイ・サイトのピア・ホストへのファイルのレプリケーションが有効になるように、rsyncを設定します。rsyncをインストールおよび設定する手順、および構文と使用方法の詳細は、rsyncのマニュアル・ページを参照してください。rsyncに関する情報は、http://rsync.samba.orgで入手できます。
1つ以上のOracle Fusion Middlewareコンポーネントがインストールされている本番サイトの各ホストについて、次のディレクトリおよびファイルを、スタンバイ・サイトのピア・ホスト上の同じディレクトリおよびファイルにコピーするように、rsyncを設定します。
Oracle Fusion Middlewareのホーム・ディレクトリおよびサブディレクトリと、それらのディレクトリ内のすべてのファイル
ホストのOracle中央インベントリ・ディレクトリおよびファイル(Oracle Fusion Middlewareインストール用のOracle Universal Installerエントリを含む)
ホスト上のOracle HTTP Serverインストール用のOracle Fusion Middlewareの静的HTMLページ・ディレクトリ(該当する場合)
Oracle Formsによってホスト上に作成された.fmbおよび.fmxデプロイメント・アーティファクト・ファイルと、Oracle Reportsによってホスト上に作成された.rdfデプロイメント・アーティファクト・ファイル(該当する場合)
|
注意: rsyncをルートとして実行してください。ユーザーにパスワードの入力を求めるプロンプトを表示せずにrsyncが機能するようにするには、SSHによってパスワードの入力を求めるプロンプトが表示されないように、本番サイトのホストとスタンバイ・サイトのホスト間にSSHキーを設定します。 |
前の手順でrsyncを設定した本番サイトのホストについて、cronジョブなどのスケジュール済ジョブを設定します。これらのスケジュール済ジョブを使用すると、rsyncによって、本番サイトのホストからスタンバイ・サイトのホストへのこれらのファイルのレプリケーションを定期的に自動実行できます。Oracle Fusion Middlewareの構成がそれほど頻繁に変更されない本番サイトについては、1日1回の間隔をお薦めします。
本番サイトのホストでOracle Fusion Middlewareの中間層の構成が変更された場合(新しいアプリケーションがデプロイされた場合など)は必ず、rsyncを使用して、スタンバイ・サイトのピア・ホストとそのホストの手動同期を実行する必要があります。
本番サイトのホスト上にあるOracle Fusion Middlewareの中間層インスタンスを、rsyncを使用して手動でスタンバイ・サイトのピア・ホストと同期させた場合は、関連する本番サイトのOracle Fusion Middlewareインスタンスのデータベース・リポジトリも、Oracle Data Guardを使用して手動で強制的にスタンバイ・サイトと同期させる必要があります。Oracle Data Guardを使用してOracleデータベースを手動で強制的に同期させる方法の詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動強制」を参照してください。
rsyncを使用している場合、本番サイトからスタンバイ・サイトへのフェイルオーバーまたはスイッチオーバーを実行する手順は次のとおりです。
本番サイトで実行中のプロセスを停止します(該当する場合)。
本番サイトのホストとスタンバイ・サイトのピア・ホスト間のrsyncジョブを停止します。
Oracle Data Guardを使用して、本番サイトのデータベースをスタンバイ・サイトにフェイルオーバーします。
スタンバイ・サイトで、Oracle Fusion Middlewareサーバー・インスタンスのプロセスを手動で開始します。
グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストをスタンバイ・サイトにルーティングします。
ブラウザ・クライアントを使用してフェイルオーバー後またはスイッチオーバー後のテストを実行し、スタンバイ・サイト(現在の本番サイト)でリクエストが解決されていることを確認します。
これで、スタンバイ・サイトが新しい本番サイトになり、本番サイトが新しいスタンバイ・サイトになりました。
2つのサイト間のrsyncレプリケーションを再確立します。ただし、逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)レプリケートされるようにレプリケーションを構成してください。
元の本番サイトを新しい本番サイトとして使用するには、前述の手順をもう一度実行します。ただし、元の方向で(元の本番サイトから元のスタンバイ・サイトへ)レプリケートされるようにrsyncレプリケーションを構成してください。
この項では、11g Oracle Fusion Middlewareパッチ・セットを適用して、Oracle Fusion Middleware障害時リカバリ・サイトに含まれるOracleホームをアップグレードする方法を説明します。
この項の一覧では、Oracle Fusion Middleware障害時リカバリの本番サイトでパッチ・セットを適用して、11g Oracle Fusion Middlewareホームをアップグレードする手順について説明します。
次の手順は、パッチを適用するOracle Fusion MiddlewareインスタンスのOracle中央インベントリが本番サイトの共有ストレージに配置されていて、パッチが適用されたインスタンスのOracle中央インベントリをスタンバイ・サイトにレプリケートできるようになっていることを前提としています。
11g Oracle Fusion Middlewareのパッチ・バージョンをアップグレードする手順は、次のとおりです。
開始時の状態が保持されるように、本番サイトのバックアップを実行します。
パッチ・セットを適用して、本番サイトのインスタンスをアップグレードします。
パッチ・セットを適用したら、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージを手動で強制的に同期させます。これによって、本番サイトのパッチが適用されたインスタンスとOracle中央インベントリがスタンバイ・サイトの共有ストレージにレプリケートされます。
パッチ・セットを適用したら、Oracle Data Guardを使用して、本番サイトとスタンバイ・サイトのOracleデータベースを手動で強制的に同期させます。Oracle Fusion Middlewareの一部のパッチ・セットでは、リポジトリが更新される場合があります。そのため、この手順を必ず実行して、本番サイトのデータベースの変更をスタンバイ・サイトのデータベースに同期させます。
これでアップグレードは完了です。障害時リカバリ・トポロジで処理を再開できます。
|
注意: パッチは、11g Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトでのみ適用する必要があります。Oracle Fusion MiddlewareインスタンスまたはOracle中央インベントリのパッチの場合、本番サイトの共有ストレージがスタンバイ・サイトの共有ストレージにレプリケートされるときに、パッチがコピーされます。本番サイトでパッチをインストールした場合は、同期操作を実行する必要があります。同様に、本番サイトのデータベースのパッチをインストールした場合、同期を実行すると、Oracle Data Guardによってスタンバイ・サイトのスタンバイ・データベースにパッチがコピーされます。 |
