ヘッダーをスキップ
Oracle® Fusion Middlewareディザスタ・リカバリ・ガイド
11g リリース1(11.1.1)
B61394-04
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

4 障害時リカバリ・サイトの設定と管理

この章では、Oracle SOA Suiteのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用して、本番サイトおよびスタンバイ・サイトの設定に必要な手順を説明します。

次のトピックが含まれます:


注意:

Oracle Site Guardを使用してスイッチオーバーやフェイルオーバーなどの障害回復操作を自動化することができます。詳細は、第5章「Oracle Site Guardの使用方法」を参照してください。

4.1 サイトの設定

この項では、本番サイトを作成する手順を説明します。Oracle SOAのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用します。

次のトピックが含まれます:

本番サイトの作成を開始する前に、次の事前準備が完了していることを確認してください。

4.1.1 ディレクトリ構造とボリューム設計

次の項では、お薦めするディレクトリ構造について詳しく説明します。エンド・ユーザーは他のディレクトリ・レイアウトを選択してもかまいませんが、ここで採用されているモデルを使用すると、コンポーネントが最適に分離され、構成における対称性が保たれるとともに、バックアップと障害時リカバリが容易になり、最大限の可用性が実現されます。

次の一覧では、ディレクトリとディレクトリ環境変数について説明します。

  • ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを表します。

  • MW_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが配置されている場所を表します。

  • WL_HOME: この環境変数および関連するディレクトリ・パスには、Oracle WebLogic Serverをホストするために必要なファイルがインストールされて格納されます。

  • ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、製品スイート(Oracle SOA Suite、Oracle WebCenter Portal、Oracle Identity Managementなど)がインストールされている場所を表します。

  • DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogic Domain情報(構成アーティファクト)が保存されている場所を表します。後述のように同じノード内にある場合でも、個々のWebLogic Serverで異なるドメイン・ディレクトリを使用できます。

  • ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなど、1つ以上のシステム・コンポーネントが格納されます。Oracleインスタンスのディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されます。

詳細は、次を参照してください。

4.1.1.1 Oracle SOA Suiteのディレクトリ構造に関する推奨事項

Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のSOA管理対象サーバーを作成できます。これにより、共有ストレージの1つの場所にバイナリをインストールし、異なるノードのサーバーでそのインストールを再利用することが可能です。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-1は、Oracle SOA Suiteのディレクトリ構造のレイアウトを示しています。

図4-1 SOAのディレクトリ構造

図4-1の説明が続きます
「図4-1 SOAのディレクトリ構造」の説明

このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』およびOracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドを参照してください。

表4-1では、図4-1で色分けされている要素の意味を説明します。図4-1のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-1 ディレクトリ構造の要素

要素 説明
管理サーバー要素

管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体が共有ディスクに配置されます。
固定名要素

固定名です。
インストール依存名

インストール依存名です。

4.1.1.1.1 Oracle SOA Suiteのボリューム設計

図4-2および図4-3は、Oracle SOA Suiteのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle SOA Suiteトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。

図4-2 Oracle Access Managerを使用したMySOACompanyトポロジ

図4-2の説明が続きます
「図4-2 Oracle Access Managerを使用したMySOACompanyトポロジ」の説明

図4-3 Oracle Access ManagerおよびBPMを使用したMySOACompanyトポロジ

図4-3については周囲のテキストで説明しています。

この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は通常、これなしで動作します。

4.1.1.1.2 Oracle SOA Suiteのコンシステンシー・グループに関する推奨事項

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は通常、これなしで動作します。

4.1.1.2 Oracle WebCenter Portalのディレクトリ構造に関する推奨事項

Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のOracle WebCenter Portal管理対象サーバーを作成できます。これにより、共有ストレージの1つの場所にバイナリをインストールし、異なるノードのサーバーでそのインストールを再利用することが可能です。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-1は、Oracle WebCenter Portalのディレクトリ構造のレイアウトを示しています(Oracle SOA SuiteとOracle WebCenter Portalの両方に同じディレクトリ構造のレイアウトが使用されます)。

4.1.1.2.1 Oracle WebCenter Portalのボリューム設計

図4-4は、Oracle WebCenter Portalのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle WebCenter Portalトポロジのものです。このトポロジのインストールおよび構成の手順は、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドを参照してください。

図4-4 Oracle Access Managerを使用したMyWCPCompanyトポロジ

図4-4の説明が続きます
「図4-4 Oracle Access Managerを使用したMyWCPCompanyトポロジ」の説明

このOracle WebCenter Portalトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。

  • 製品の冗長バイナリを格納する2つのMiddlewareホーム用にボリュームを2つプロビジョニングします(表4-4のVOLFMW1およびVOLFMW2)。

  • 管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-4のVOLADMIN)。

  • SOAの管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-4のVOLSOA1およびVOLSOA2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。

  • Oracle WebCenter Portalの管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-4のVOLWCP1およびVOLWCP2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。

  • 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 Portalトポロジのボリューム設計に関する推奨事項の概要を示します。

表4-4 Oracle WebCenter Portalのボリューム設計に関する推奨事項

層 ボリューム名 マウントされるホスト マウント・ポイント コメント

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

WCPHOST1

/u01/app/oracle/admin/wcpDomain/mng1

Oracle WebCenter Portalの管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLWC2

WCPHOST2

/u01/app/oracle/admin/wcpDomain/mng2

Oracle WebCenter Portalの管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLDATA

SOAHOST1、SOAHOST2、WCPHOST1、WCPHOST2

/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は通常、これなしで動作します。

4.1.1.2.2 Oracle WebCenter Portalのコンシステンシー・グループに関する推奨事項

Oracle WebCenter Portalトポロジについては、次のコンシステンシー・グループをお薦めします。

  • 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを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 Portalトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-5 Oracle WebCenter Portalのコンシステンシー・グループ

層 グループ名 メンバー コメント

アプリケーション

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は通常、これなしで動作します。

4.1.1.3 Oracle Identity Managementのディレクトリ構造に関する推奨事項

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のディレクトリ構造のレイアウトを紹介します。

図4-5 Oracle Identity Managementのディレクトリ構造

次の図4-5の説明が続きます
「図4-5 Oracle Identity Managementのディレクトリ構造」の説明

表4-6 ディレクトリ構造の要素

要素 説明
共有ストレージ

管理サーバー・ドメインのディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ・コントロール・ディレクトリ、JMSログ、TXログ、およびMW_HOME全体は共有ディスク上にあります。
固定名

管理対象サーバー・ドメインのディレクトリは、共有ディスクに配置する必要があります。また、管理対象サーバー・ドメインのディレクトリを複数のノード上で共有する場合、ノード間で同じ共有ディスクの場所をマウントする必要があります。Web層のinstance_nameディレクトリは、共有ディスクに配置する必要があります。
固定名

固定名です。
インストール依存名

インストール依存名です。

このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。図4-5のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

4.1.1.3.1 Oracle Identity Managementのボリューム設計

図4-6、図4-7および図4-8は、Oracle Identity Managementのトポロジを示しています。この項で説明するボリューム設計は、これらのOracle Identity Managementトポロジのものです。このトポロジのインストールおよび構成の手順は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

図4-6 Oracle Access Managerを使用したMyIMCompanyトポロジ

図4-6の説明が続きます
「図4-6 Oracle Access Managerを使用したMyIMCompanyトポロジ」の説明

図4-7 Oracle Access ManagerおよびOracle Identity Managerを使用したMyIMCompanyトポロジ

図4-7については周囲のテキストで説明しています。

図4-8 Oracle Adaptive Access Managerを使用したMyIMCompanyトポロジ

図4-8については周囲のテキストで説明しています。

図4-6、図4-7および図4-8に示されているOracle Identity Managementのエンタープライズ・デプロイメントを設定する方法の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。

Oracle Identity Managementについては、次のボリューム設計をお薦めします。

  • Middlewareホーム用に各Identity Managementノードでボリュームを1つプロビジョニングします。このボリュームには、WebLogic Serverホーム、Identity ManagementのOracleホーム、そのホストで実行される管理サーバーおよび管理対象サーバーのドメイン・ディレクトリも格納されます。これらは、表4-7のVOLIDM1およびVOLIDM2です。

  • ディレクトリ層およびWeb層のOracleホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-7のVOLWEB1、VOLWEB2、VOLOID1、VOLOID2、VOLOVD1およびVOLOVD2です。

  • ディレクトリ層およびWeb層のOracleインスタンス・ホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-7のVOLWEBINST1、VOLWEBINST2、VOLOIDINST1、VOLOIDINST2、VOLOVDINST1およびVOLIOVDINST2です。

  • Identity Management Oracleインスタンス、管理サーバーおよびアプリケーション層の管理対象サーバーのインスタンス用に各ノードでボリュームを1つずつプロビジョニングします。このボリュームは、管理サーバーおよび管理対象サーバーのインスタンスで共有されます。これらは、表4-7のVOLIDMINST1およびVOLIDMINST2です。

  • JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-7のVOLDATA)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。

表4-7に、図4-6に示されているOracle Identity Managementトポロジのボリューム設計に関する推奨事項の概要を示します。

表4-7 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、OIMHOST1およびOAAMHOST1

/u01/app/oracle/admin

Oracleインスタンス用のボリューム

アプリケーション

VOLIDMINST2

IDMHOST2、OIMHOST2およびOAAMHOST2

/u01/app/oracle/admin

Oracleインスタンス用のボリューム

ディレクトリ

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インスタンス用のボリューム

アプリケーション

VOLDATA

OIMHOST1、OIMHOST2

/u01/app/oracle/admin/oimDomain/soaCluster/jms

/u01/app/oracle/admin/oimDomain/soaCluster/tlogs

トランザクション・ログおよびJMSデータ用のボリューム

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.3.2 Oracle Identity Managementのコンシステンシー・グループに関する推奨事項

Oracle Identity Managementトポロジについては、次のコンシステンシー・グループをお薦めします。

  • アプリケーション層のMiddlewareホーム・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のIDMMWGROUPグループです。

  • アプリケーション層のOracleインスタンス・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のIDMINSTGROUPグループです。

  • Oracle Internet DirectoryのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のOIDHOMEGROUPグループです。

  • Oracle Internet DirectoryのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のOIDINSTGROUPグループです。

  • Oracle Virtual DirectoryのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のOVDHOMEGROUPグループです。

  • Oracle Virtual DirectoryのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のOVDINSTGROUPグループです。

  • Oracle Access Managerのアイデンティティ・サーバーおよびアクセス・サーバー・コンポーネント用のOracle Access ManagerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のOAMGROUPグループです。

  • Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のWEBHOMEGROUPグループです。

  • Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のWEBINSTGROUPグループです。

  • JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-8のDATAGROUPです。

表4-8に、図4-6に示されているOracle Identity Managementトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-8 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インスタンス用のコンシステンシー・グループ

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.1.1.4 Oracle Portal、Forms、ReportsおよびDiscovererのディレクトリ構造に関する推奨事項

図4-9は、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-9の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は次のとおりです。

http://support.oracle.com

図4-9 Oracle Portalのトポロジ・ダイアグラム

図4-9の説明が続きます
「図4-9 Oracle Portalのトポロジ・ダイアグラム」の説明

図4-10は、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-10の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は次のとおりです。

http://support.oracle.com

図4-10 Oracle Forms、ReportsおよびDiscovererのトポロジ

図4-10の説明が続きます
「図4-10 Oracle Forms、ReportsおよびDiscovererのトポロジ」の説明

4.1.1.4.1 Oracle Portal、Forms、ReportsおよびDiscoverのボリューム設計

図4-9に示されているOracle Portalトポロジと図4-10に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトについては、次のボリューム設計をお薦めします。

  • Middlewareホーム用に各アプリケーション層ホストでボリュームを1つプロビジョニングします。このボリュームには、WebLogic Serverホーム、Oracle Portal、Reports、FormsおよびDiscovererコンポーネントのOracleホーム、そのホストで実行される管理サーバーおよび管理対象サーバーのドメイン・ディレクトリも格納されます。これらは、表4-9のVOLPFRD1およびVOLPFRD2です。

  • Web層のOracleホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-9のVOLWEB1およびVOLWEB2です。

  • ディレクトリWeb層のOracleインスタンス・ホーム用に各ノードでボリュームを1つプロビジョニングします。これらは、表4-9のVOLWEBINST1およびVOLWEBINST2です。

  • アプリケーション層のOracleインスタンス・ホーム用に各ノードでボリュームを1つプロビジョニングします。このボリュームは、管理サーバーおよび管理対象サーバーのインスタンスで共有されます。これらは、表4-9のVOLPFRDINST1およびVOLPFRDINST2です。

  • アプリケーション層のOracle Reports出力ディレクトリ用にボリュームを1つプロビジョニングします。このボリュームは、Oracle Reportsサーバーを実行するすべてのノードでマウントされます。これは、表4-7のVOLREPOUTです。

表4-9に、図4-9に示されているOracle Portalトポロジと図4-10に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトのボリューム設計に関する推奨事項の概要を示します。

表4-9 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.1.1.4.2 Oracle Portal、Forms、ReportsおよびDiscovererのコンシステンシー・グループに関する推奨事項

図4-9に示されているOracle Portalトポロジと図4-10に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトについては、次のコンシステンシー・グループをお薦めします。

  • Web層のOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-10のWEBHOMEGROUPです。

  • Web層のOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-10のWEBINSTGROUPです。

  • アプリケーション層のMiddlewareホームを含むボリュームから成るコンシステンシー・グループを1つ作成します。これは、表4-10のPFRDMWGROUPです。

  • アプリケーション層のOracleインスタンス・ホームを含むボリュームから成るコンシステンシー・グループを1つ作成します。これは、表4-10のPFRDINSTGROUPです。

  • Oracle Reportsの出力ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します。これは、表4-10のREPOUTGROUPです。

表4-10に、図4-9に示されているOracle Portalトポロジと図4-10に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-10 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は通常、これなしで動作します。

4.1.1.5 Oracle WebCenter Contentのディレクトリ構造に関する推奨事項

Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のOracle Enterprise Content Management管理対象サーバーを作成できます。これにより、共有ストレージの1つの場所にバイナリをインストールし、異なるノードのサーバーでそのインストールを再利用することが可能です。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-11は、Oracle WebCenter Content Suiteのディレクトリ構造のレイアウトを示しています。

図4-11 Oracle WebCenter Contentのディレクトリ構造

図4-11の説明が続きます
「図4-11 Oracle WebCenter Contentのディレクトリ構造」の説明

図4-11のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-11では、図4-11で色分けされている要素の意味を説明します。図4-11のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-11 ディレクトリ構造の要素

要素 説明
管理サーバー要素

管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体が共有ディスクに配置されます。
固定名要素

固定名です。
インストール依存名

インストール依存名です。

このディレクトリ構造の設定の詳細は、Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドを参照してください。

4.1.1.5.1 Oracle WebCenter Contentのボリューム設計

図4-12は、Oracle WebCenter Contentのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle WebCenter Contentトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドを参照してください。

図4-12 Oracle WebCenter Contentエンタープライズ・デプロイメントの参照トポロジ

図4-12の説明が続きます
「図4-12 Oracle WebCenter Contentエンタープライズ・デプロイメントの参照トポロジ」の説明

このOracle WebCenter Contentトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。

  • 製品の冗長バイナリを格納する2つのMiddlewareホーム用にボリュームを2つプロビジョニングします(表4-12のVOLFMW1およびVOLFMW2)。

  • 管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-12のVOLADMIN)。

  • 管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-12のVOLWCC1およびVOLWCC2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。

  • JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-12のVOLDATA)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。

  • Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-12のVOLWEB1およびVOLWEB2)。

  • Oracle HTTP ServerのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-12のVOLWEBINST1およびVOLWEBINST2)。

表4-12に、図4-12に示されているOracle Enterprise Content Management Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。

表4-12 Oracle WebCenter Contentのボリューム設計に関する推奨事項

層 ボリューム名 マウントされるホスト マウント・ポイント コメント

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

WCCHOST1

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム

アプリケーション

VOLFMW2

WCCHOST2

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle SOA Suiteバイナリ用のボリューム

アプリケーション

VOLADMIN

WCCHOST1

/u01/app/oracle/admin/wccDomain/admin

管理サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLWCC1

WCCHOST1

/u01/app/oracle/admin/wccDomain/mng1

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLWCC2

WCCHOST2

/u01/app/oracle/admin/wccDomain/mng2

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLDATA

WCCHOST1、WCCHOST2

/u01/app/oracle/admin/wccDomain/soaCluster/jms

/u01/app/oracle/admin/wccDomain/soaCluster/tlogs

トランザクション・ログおよびJMSデータ用のボリューム

UCM関連の他のディレクトリは、ドメインの外部に構成されます。

UCMファイル(VaultおよびWeblayout)のボリュームはドメインの外部に作成されます。

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.5.2 Oracle WebCenter Contentのコンシステンシー・グループに関する推奨事項

Oracle WebCenter Contentトポロジについては、次のコンシステンシー・グループをお薦めします。

  • 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-13のDOMAINGROUP)。

  • JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-13のDATAGROUP)。

  • Middlewareホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-13のFMWHOMEGROUP)。

  • Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-13のWEBHOMEGROUP)。

  • Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-13のWEBINSTANCEGROUP)。

表4-13に、図4-12に示されているOracle WebCenter Contentトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-13 Oracle WebCenter Contentのコンシステンシー・グループ

層 グループ名 メンバー コメント

アプリケーション

DOMAINGROUP

VOLADMIN

VOLWCC1

VOLWCC2

管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ

アプリケーション

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は通常、これなしで動作します。

4.1.1.6 Oracle Business Intelligenceのディレクトリ構造に関する推奨事項

Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のOracle Business Intelligence管理対象サーバーを作成できます。これにより、共有ストレージの1つの場所にバイナリをインストールし、異なるノードのサーバーでそのインストールを再利用することが可能です。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMW HOME(それぞれに、各製品スイートのWL_HOMEとORACLE_HOMEがあります)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。

また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムに配置することもできますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-13は、Oracle Business Intelligence Suiteのディレクトリ構造のレイアウトを示しています。

図4-13 Oracle Business Intelligenceのディレクトリ構造

図4-13の説明が続きます
「図4-13 Oracle Business Intelligenceのディレクトリ構造」の説明

図4-13のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-14では、図4-13で色分けされている要素の意味を説明します。図4-13のディレクトリ構造には、oracle_commonやjrockitなど、その他の必要な内部ディレクトリは示されていません。

表4-14 ディレクトリ構造の要素

要素 説明
管理サーバー要素

管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとTXのログ、およびMW_HOME全体が共有ディスクに配置されます。
固定名要素

固定名です。
インストール依存名

インストール依存名です。

このディレクトリ構造の設定の詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドを参照してください。

4.1.1.6.1 Oracle Business Intelligenceのボリューム設計

図4-14は、Oracle Business Intelligenceのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle Business Intelligenceトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドを参照してください。

図4-14 Oracle Business Intelligenceエンタープライズ・デプロイメントの参照トポロジ

図4-14の説明が続きます
「図4-14 Oracle Business Intelligenceエンタープライズ・デプロイメントの参照トポロジ」の説明

このOracle Business Intelligenceトポロジの障害時リカバリについては、次のボリューム設計をお薦めします。

  • 製品の冗長バイナリを格納する2つのMiddlewareホーム用にボリュームを2つプロビジョニングします(表4-15のVOLFMW1およびVOLFMW2)。

  • 管理サーバーのドメイン・ディレクトリ用にボリュームを1つプロビジョニングします(表4-15のVOLADMIN)。

  • 管理対象サーバーのドメイン・ディレクトリ用に各ノードでボリュームを1つプロビジョニングします(表4-15のVOLBI1およびVOLBI2)。このディレクトリは、そのノード上のすべての管理対象サーバー間で共有されます。

  • JMSファイル・ストアおよびJTAトランザクション・ログ用にボリュームを1つプロビジョニングします(表4-15のVOLDATA1)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。

  • Oracle Business Intelligence Enterprise Edition(EE)の共有ファイルおよびディレクトリ用にボリュームを1つプロビジョニングします(表4-15のVOLDATA2)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。このボリュームには、Oracle BIリポジトリ(RPDファイル)、Oracle BI Presentation Catalog、グローバル・キャッシュおよびOracle BI Schedulerの共有スクリプトが含まれます。

  • Oracle Business Intelligence Publisherの共有構成ファイルおよびディレクトリ用にボリュームを1つプロビジョニングします(表4-15のVOLDATA3)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。このボリュームには、Oracle Business Intelligence Publisherの構成ファイルが格納されます。

  • Oracle Business Intelligence Publisherカタログ用にボリュームを1つプロビジョニングします(表4-15のVOLDATA4)。ドメイン全体で1つのボリュームが使用され、ドメインのすべてのノードでマウントされます。このボリュームには、Oracle Business Intelligence Publisherを使用して作成するオブジェクト(レポート、データ・モデル、スタイル・テンプレートなど)を格納するOracle Business Intelligence Publisherカタログが格納されます。

  • Oracle HTTP ServerのOracleホーム用に各ノードでボリュームを1つプロビジョニングします(表4-15のVOLWEB1およびVOLWEB2)。

  • Oracle HTTP ServerのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-15のVOLWEBINST1およびVOLWEBINST2)。

  • Oracle Business IntelligenceのOracleインスタンス用に各ノードでボリュームを1つプロビジョニングします(表4-15のVOLBIINST1およびVOLBIINST2)。

表4-15に、図4-14に示されているOracle Business Intelligence Suiteトポロジのボリューム設計に関する推奨事項の概要を示します。

表4-15 Oracle Business Intelligenceのボリューム設計に関する推奨事項

層 ボリューム名 マウントされるホスト マウント・ポイント コメント

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コンテンツ用のボリューム

アプリケーション

VOLBIINST1

HOST1

/u01/app/oracle/admin/bi_instance

Oracle Business Intelligenceのインスタンス用のボリューム

アプリケーション

VOLBIINST2

HOST2

/u01/app/oracle/admin/bi_instance

Oracle Business Intelligenceのインスタンス用のボリューム

アプリケーション

VOLFMW1

HOST1

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle Business Intelligenceのバイナリ用のボリューム

アプリケーション

VOLFMW2

BIHOST2

/u01/app/oracle/product/fmw

WebLogic ServerおよびOracle Business Intelligenceのバイナリ用のボリューム

アプリケーション

VOLADMIN

BIHOST1

/u01/app/oracle/admin/biDomain/admin

管理サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLBI1

BIHOST1

/u01/app/oracle/admin/biDomain/mng1

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLBI2

BIHOST2

/u01/app/oracle/admin/biDomain/mng1

管理対象サーバーのドメイン・ディレクトリ用のボリューム

アプリケーション

VOLDATA1

BIHOST1、BIHOST2

/u01/app/oracle/admin/biDomain/biCluster/jms

/u01/app/oracle/admin/biDomain/biCluster/tlogs

トランザクション・ログおよびJMSデータ用のボリューム

アプリケーション

VOLDATA2

BIHOST1、BIHOST2

/u01/app/oracle/admin/biDomain/biCluster/repository

Oracle BIリポジトリ(RPDファイル)、Oracle BI Presentation Catalog、グローバル・キャッシュおよびOracle BI Schedulerの共有スクリプト用のボリューム

アプリケーション

VOLDATA3

BIHOST1、BIHOST2

/u01/app/oracle/admin/biDomain/biCluster/bipublisher/config

Oracle Business Intelligence Publisherの構成ファイル用のボリューム

アプリケーション

VOLDATA4

BIHOST1、BIHOST2

/u01/app/oracle/admin/biDomain/biCluster/bipublisher/reports

Oracle Business Intelligence Publisherを使用して作成するオブジェクト(レポート、データ・モデル、スタイル・テンプレートなど)用のボリューム

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.1.6.2 Oracle Business Intelligenceのコンシステンシー・グループに関する推奨事項

Oracle Business Intelligenceトポロジについては、次のコンシステンシー・グループをお薦めします。

  • 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のDOMAINGROUP)。

  • JMSファイル・ストアおよびトランザクション・ログ・データを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のDATAGROUP1)。

  • Oracle Business Intelligenceの共有ファイルとディレクトリ、およびOracle Business Intelligence Publisherの構成フォルダを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のDATAGROUP2)。

  • Middlewareホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のFMWHOMEGROUP)。

  • Oracle HTTP ServerのOracleホームを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のWEBHOMEGROUP)。

  • Oracle HTTP ServerのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のWEBINSTANCEGROUP)。

  • Oracle Business IntelligenceのOracleインスタンスを含むボリュームをメンバーとするコンシステンシー・グループを1つ作成します(表4-16のBIINSTANCEGROUP)。

表4-16に、図4-14に示されているOracle Business Intelligenceトポロジのコンシステンシー・グループに関する推奨事項の概要を示します。

表4-16 Oracle Business Intelligenceのコンシステンシー・グループ

層 グループ名 メンバー コメント

アプリケーション

DOMAINGROUP

VOLADMIN

VOLBI1

VOLBI2

管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ

アプリケーション

DATAGROUP1

VOLDATA1

JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ

アプリケーション

DATAGROUP2

VOLDATA2

VOLDATA3

VOLDATA4

Oracle Business Intelligenceの共有ファイルとディレクトリ、およびOracle Business Intelligence Publisher構成用のコンシステンシー・グループ

アプリケーション

FMWHOMEGROUP

VOLFMW1

VOLFMW2

Middlewareホーム用のコンシステンシー・グループ

アプリケーション

BIINSTANCEGROUP

VOLBIINST1

VOLBIINST2

VOLSTATIC1脚注 1 

VOLSTATIC2脚注 2 

Oracle Business IntelligenceのOracleインスタンス用のコンシステンシー・グループ

Web

WEBHOMEGROUP

VOLWEB1

VOLWEB2

Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ

Web

WEBINSTANCEGROUP

VOLWEBINST1

VOLWEBINST2

VOLSTATIC1脚注 3 

VOLSTATIC2脚注 4 

Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ

脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注3 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

脚注4 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。

4.1.2 ストレージ・レプリケーション

Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定するには、次の手順を実行します。

  1. スタンバイ・サイトで、本番サイトのピア・ホストに使用されている物理ホスト名と同じホスト名別名が作成されていることを確認します。

  2. スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。

  3. スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンクを作成します(スタンバイ・サイトでシンボリック・リンクを設定する必要があるのは、本番サイトでシンボリック・リンクを設定した場合のみです)。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

  4. 本番サイトにインストールしたものと同じOracle Fusion Middlewareインスタンスをスタンバイ・サイトにインストールする必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているOracleソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。

  5. 共有ストレージ・ベンダーが規定しているその他の必要な構成を実行して、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のストレージ・レプリケーションを有効にします。

  6. 本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、本番サイトとスタンバイ・サイトの共有ストレージ間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。

  7. スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。

  8. Oracle Fusion Middleware障害時リカバリの本番サイトに含まれているデータベースの障害保護機能がOracle Data Guardによって提供されていることを確認します。Oracle Databaseの障害保護にストレージ・レプリケーション・テクノロジは使用しないでください。

  9. スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。

  10. 本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行することを強くお薦めします。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。

4.1.3 データベース

Oracle Fusion Middleware障害時リカバリ・トポロジで使用するOracle Databaseの設定に関する推奨事項および考慮事項の詳細は、第3.3項「データベースに関する考慮事項」を参照してください。

4.1.3.1 Oracle Data Guardの設定

Oracle Data Guardは、プライマリ・サイトとスタンバイ・サイトのOracle Fusion Middlewareリポジトリ・データベース間に設定する必要があります。スタンバイ・サイトのデータベースは、フィジカル・スタンバイ・データベースとして設定する必要があります。この項では、スタンバイ・サイトのデータ層の設定と構成について説明します。

Oracle Data Guardの詳細は、Oracle Databaseのドキュメント・セットの『Oracle Data Guard概要および管理』を参照してください。

4.1.3.1.1 前提条件

後述のOracle Data Guardの設定および構成手順は、次の条件を満たしていることを前提としています。

  • スタンバイ・サイトのRACクラスタおよびASMインスタンスが作成されています。

  • スタンバイ・サイトおよび本番サイトのRACデータベースでフラッシュ・リカバリ領域を使用しています。

  • スタンバイ・サイトのデータベース・ホストにOracleソフトウェアがすでにインストールされています。

  • スタンバイ・サイトのDB_HOMEの物理パスが本番サイトのものと一致しています。

4.1.3.1.2 Oracle Data Guard環境の説明

Oracle Data Guardの手順では、表4-17に記載されている環境変数を本番サイトのSOAデータベースに使用します。

表4-17 本番サイトの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

SOA1、SOA2

SOA_SERVICE_NAMES

PSOA、SSOA

ORACLE_SID

SOA1、SOA2

Oracle Data Guardの手順では、表4-18に記載されている環境変数をスタンバイ・サイトのSOAデータベースに使用します。

表4-18 スタンバイ・サイトの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

SOA1、SOA2

SOA_SERVICE_NAMES

PSOA、SSOA

ORACLE_SID

SOA1、SOA2

Oracle Data Guardの設定手順は、次の項で詳しく説明します。

4.1.3.1.3 ファイルの収集とバックアップの実行

ファイルを収集し、データベースのバックアップを実行する手順は、次のとおりです。

  1. プライマリ・サイトのSOADBHOST1で、ステージング用のディレクトリを作成します。例:

    $ mkdir -p /u01/app/stage/psoa

  2. スタンバイ・サイトのSOADBHOST1で、同じパスを作成します。ステップ1に記載されている例に従ってください。

  3. プライマリ・サイトのSOADBHOST1でデータベース・インスタンスpsoa1に接続し、spfileからpfileを作成します。例:

    SQL > create pfile='/u01/app/stage/psoa/initpsoa.ora' from spfile;

  4. プライマリ・サイトの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;

  5. 次の手順に従って、RMANによって作成されたバックアップが有効であることを検証します。

  6. プライマリ・サイトのSOADBHOST1でRMANに接続し、バックアップ・サマリを表示します。

  7. ステップ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

  8. プライマリ・サイトのSOADBHOST1で、listener.ora、sqlnet.oraおよびtnsnames.oraファイルを$ORACLE_HOME/network/adminディレクトリからステージング・ディレクトリにコピーします。

  9. オペレーティング・システムのユーティリティを使用して、プライマリ・サイトのSOADBHOST1上のステージング・ディレクトリの内容をスタンバイ・サイトのSOADBHOST1上のステージング・ディレクトリにコピーします。

4.1.3.1.4 スタンバイ・サイトでのOracle Net Servicesの構成

スタンバイ・サイトでOracle Net Servicesを構成する手順は、次のとおりです。

  1. listener.ora、sqlnet.oraおよびtnsnames.oraファイルを、プライマリ・サイトのSOADBHOST1上のステージング・ディレクトリからスタンバイ・サイトのすべてのノード上の$ORACLE_HOME/network/adminディレクトリにコピーします。

  2. 各スタンバイ・ホストのlistener.oraファイルを、そのホストの仮想IPを含むように変更します。

  3. プライマリRACノードやスタンバイRACノードなど各ノードのtnsnames.oraファイルを、プライマリおよびスタンバイのすべてのネット・サービス名を含むように変更します。

  4. 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)
)
)

  5. スタンバイ・データベース・ホストでリスナーを開始します。

4.1.3.1.5 スタンバイ・サイトでのインスタンスおよびデータベースの作成

スタンバイ・サイトでインスタンスおよびデータベースを作成する手順は、次のとおりです。

  1. REDOデータを安全に送信するために、プライマリ・サイトとスタンバイ・サイトのデータベースでパスワード・ファイルを使用していることを確認するとともに、SYSユーザーのパスワードがすべてのシステムで同じであることを確認します。スタンバイ・データベースの両方のノードでパスワード・ファイルを作成してください。例:

    スタンバイ・サイトのSOADBHOST1の場合

    $ cd $ORACLE_HOME/dbs
$ orapwd file=orapwpsoa1 password=welcome1

    スタンバイ・サイトのSOADBHOST2の場合

    $ cd $ORACLE_HOME/dbs
$ orapwd file=orapwpsoa2 password=welcome1

  2. スタンバイ・サイトのSOADBHOST1上のステージング領域から$ORACLE_HOME/dbsディレクトリにpfileをコピーし、名前を変更します。例:

    $ cp /u01/app/stage/psoa/initpsoa.ora $ORACLE_HOME/dbs/initsoa1.ora

  3. プライマリ・ノードからコピーしたスタンバイの初期化パラメータ・ファイルを、表4-19に記載されているパラメータを含むように変更します。

    表4-19 スタンバイの初期化パラメータ・ファイルで指定するパラメータ

    パラメータ 値

    RACパラメータ

    *.cluster_database=true

    PSOA1.instance_name=SOA1

    PSOA2.instance_name=SOA2

    PSOA1.instance_number=1

    PSOA2.instance_number=2

    PSOA1.thread=1

    PSOA2.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_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'

    *.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_file_dest='+RECO'

    *.dispatchers=PSOAXDB

  4. スタンバイ・サイトのSOADBHOST1上のASMインスタンスに接続し、スタンバイ・データベースのDB_UNIQUE_NAMEと同じ名前のディレクトリをDATAディスク・グループ内に作成します。例:

    SQL> alter diskgroup data add directory '+DATA/SSOA';

  5. スタンバイ・サイトのSOADBHOST1上のスタンバイ・データベースに接続し(スタンバイ・データベースはIDLE状態です)、スタンバイDATAディスク・グループにSPFILEを作成します。例:

    SQL> CREATE SPFILE='+DATA/SSOA/spfilepsoa.ora' FROM 
PFILE='?/dbs/initsoa1.ora';

  6. スタンバイ・サイトのSOADBHOST1およびSOADBHOST2上の$ORACLE_HOME/dbsディレクトリで、SPFILEへのポインタを含むPFILEを作成します。PFILEは、init<OracleSID>.oraというネーミング規則に従う必要があります。例:

    SOADBHOST1の場合

    $ cd $ORACLE_HOME/dbs
$ echo "SPFILE='+DATA/SSOA/spfilepsoa.ora'" > initsoa1.ora

    SOADBHOST2の場合

    $ cd $ORACLE_HOME/dbs
$ echo "SPFILE='+DATA/SSOA/spfilepsoa.ora'" > initsoa2.ora

  7. スタンバイの初期化パラメータ・ファイルで参照されているすべてのスタンバイ・ホストでダンプ・ディレクトリを作成します。例:

    $ 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

  8. スタンバイ・サイトのSOADBHOST1で、ORACLE_HOME、PATHおよびORACLE_SIDを設定し、制御ファイルをマウントせずにスタンバイ・データベースを起動します。このホストにはステージング・ディレクトリが必要です。例:

    SQL > startup nomount

  9. プライマリ・サイトのSOADBHOST1から、RMANを使用して、プライマリ・データベースをスタンバイとしてASMディスク・グループに複製します。例:

    $ rman target / auxiliary sys/oracle@ssoa
RMAN> duplicate target database for standby;

  10. SQL*Plusを使用して、新しく作成したデータベースにログインし、正しく作成されていることを検証します。例:

    $ sqlplus '/as sysdba'

  11. スタンバイ・サイトの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;

  12. スタンバイ・サイトのSOADBHOST1で、スタンバイ・データベースでの管理リカバリおよびリアルタイム適用を開始します。例:

    SQL> ALTER DATABASE recover managed standby database using current logfile 
disconnect;

  13. スタンバイ・サイトの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 soa1 -n soadbhost1
$ srvctl add instance -d psoa -i soa2 -n soadbhost2

  14. データベースとASMインスタンス間に依存関係を確立します。例:

    $ srvctl modify instance -d psoa -i soa1 -s +ASM1 
$ srvctl modify instance -d psoa -i soa2 -s +ASM2
$ srvctl enable asm -n stbdd03 -i +ASM1
$ srvctl enable asm -n stbdd04 -i +ASM2

  15. ステージング・ディレクトリ(/u01/app/stage/psoa/initpsoa.ora)にあるプライマリの初期化ファイルのData Guardパラメータを次の値に変更および追加して、Oracle Data Guardを使用するようにプライマリ・データベースを構成します。

    *.log_archive_config='dg_config=(SSOA,PSOA)'
*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'

*.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='SSOA'

*.fal_client='PSOA'

  16. プライマリ・サイトのSOADBHOST1上のプライマリ・データベースに接続し(プライマリ・データベースはIDLE状態です)、プライマリDATAディスク・グループにSPFILEを作成します。例:

    SQL> CREATE SPFILE='+DATA/PSOA/spfilepsoa.ora' FROM 
PFILE='/u01/app/stage/psoa/initpsoa.ora';

  17. プライマリ・サイトのSOADBHOST1およびSOADBHOST2上のORACLE_HOME/dbsディレクトリで、SPFILEへのポインタを含むPFILEを作成します。PFILEは、init<OracleSID>.oraというネーミング規則に従う必要があります。例:

    SOADBHOST1の場合

    $ cd $ORACLE_HOME/dbs
$ echo "SPFILE='+DATA/PSOA/spfilepsoa.ora'" > initsoa1.ora

    SOADBHOST2の場合

    $ cd $ORACLE_HOME/dbs
$ echo "SPFILE='+DATA/PSOA/spfilepsoa.ora'" > initsoa2.ora

  18. パラメータを変更したら、プライマリ・データベースを再開します。

  19. スタンバイ・ロールをサポートするために、プライマリ・データベースでスタンバイ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;

  20. V$ARCHIVED_LOGビューへの問合せを実行して、アーカイブされたREDOログ内の既存のファイルを特定し、Oracle Data Guardの構成を確認します。例:

    SQL> select sequence#, first_time, next_time from v$archived_log order by sequence#;

  21. プライマリ・データベースで、次のSQL文を発行してログ切替えを強制し、現在のオンラインREDOログ・ファイル・グループをアーカイブします。

    SQL> alter system archive log current;

  22. スタンバイ・データベースでV$ARCHIVED_LOGビューへの問合せを実行して、REDOデータがスタンバイ・データベースで受信およびアーカイブされていることを確認します。

    SQL> select sequence#, first_time, next_time from v$archived_log order by sequence#;
4.1.3.1.6 データベースのスイッチオーバーおよびスイッチバックのテスト

新しく作成したフィジカル・スタンバイ・データベースとプライマリRACデータベース間でデータベースのスイッチオーバー操作およびスイッチバック操作が正しく機能することをテストする手順は、次のとおりです。

  1. プライマリ・サイトでRACデータベースの1つのインスタンス(PSOA)以外をすべて停止します。たとえば、本番サイトのSOADBHOST1で次のコマンドを実行します。

    $ srvctl stop instance -d psoa -i soa2

  2. 現在のプライマリ・データベースでフィジカル・スタンバイへのロール移行を開始します。たとえば、本番サイトのSOADBHOST1で次のコマンドを実行します。

    SQL > ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

  3. プライマリ・インスタンスを停止し、プライマリ・インスタンスをマウントします。たとえば、本番サイトのSOADBHOST1で次のコマンドを実行します。

    SQL > shutdown immediate
SQL > startup mount

  4. これで、両方のデータベースがフィジカル・スタンバイ・モードになりました。両方のデータベースがフィジカル・スタンバイ・モードであることを確認するには、両方のデータベースで次のSQL問合せを実行します。

    SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PHYSICAL_STANDBY

  5. フィジカル・スタンバイ・データベース・ロールをプライマリ・ロールに切り替えます。たとえば、スタンバイ・サイトのSOADBHOST1で次のコマンドを実行します。

    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

  6. これで、フィジカル・スタンバイ・データベースが新しいプライマリになりました。

  7. 新しいプライマリ・データベースを停止し、srvctlを使用して、両方のRACノードを起動します。たとえば、スタンバイ・サイトのSOADBHOST1で次のコマンドを実行します。

    srvctl start database -d psoa

  8. 新しいフィジカル・スタンバイ・データベース(元のプライマリ)で、データベースの管理リカバリを開始します。たとえば、プライマリ・サイトのSOADBHOST1で次のコマンドを実行します。

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

  9. 新しいフィジカル・スタンバイ・データベースへのREDOデータの送信を開始します。たとえば、スタンバイ・サイトのSOADBHOST1で次のコマンドを実行します。

    SQL> ALTER SYSTEM SWITCH LOGFILE;

  10. V$ARCHIVED_LOGビューへの問合せを実行して、新しいフィジカル・スタンバイ・データベースでアーカイブ・ログ・ファイルが受信されているかどうかを確認します。

4.1.4 ノード・マネージャ

ノード・マネージャは、SSLを使用して管理サーバーと通信します。スタンバイ・サイトでこの通信が正しく機能するには、物理ホスト名を使用してSSL証明書を作成する必要があります。この項の項目は次のとおりです。

これらの項の例では、図4-2に示されているOracle SOA Suiteエンタープライズ・トポロジに対してこれらのタスクを実行する方法を紹介します。


注意:

図4-2に示されているOracle SOA Suiteエンタープライズ・トポロジを障害時リカバリ・トポロジの本番サイトとして設定する場合は、図4-2に示されているホスト名の代わりに、表3-1に示されている物理ホスト名を本番サイトに使用する必要があります。

この項の手順は、WebLogic Serverがインストールされているアプリケーション層ホストで実行する必要があります。

4.1.4.1 自己署名証明書の生成

次の手順に従って、自己署名証明書を生成します。

  1. $WL_HOME/server/binディレクトリにあるsetWLSenvスクリプトを使用して、環境を設定します。

  2. 証明書用のユーザー定義ディレクトリを作成します。たとえば、$MW_HOME/user_projects/domains/SOADomainディレクトリ下にcertsディレクトリを作成します。

  3. ユーザー定義ディレクトリから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

4.1.4.2 IDキーストアの作成

次の手順に従って、utils.ImportPrivateKeyユーティリティを使用してIDキーストアを作成します。

  1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreというIDキーストアを新しく作成します。

  2. このキーストアは、証明書と同じディレクトリに作成します。たとえば次のとおりです。

    $MW_HOME/user_projects/domains/j2eeDomain/certs

  3. utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートするときに、アイデンティティ・ストアが存在しなければ作成されます。

  4. 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

4.1.4.3 信頼キーストアの作成

次の手順に従って、信頼キーストアを作成します。

  1. keytoolユーティリティを使用して、appTrustKeyStoreという信頼キーストアを新しく作成します。

  2. 新しい信頼キーストアを作成するには、必要なルートCA証明書のほとんどがすでに含まれている、標準Javaキーストアを使用します。標準Java信頼キーストアは、直接変更しないようにすることをお薦めします。

  3. $WL_HOME/server/libディレクトリにある標準Javaキーストアcacertsを証明書と同じディレクトリにコピーします。例:

    cp $WL_HOME/server/lib/cacerts 
$MW_HOME/user_projects/domains/SOADomain/certs/appTrustKeyStore.jks

  4. 標準Javaキーストアのデフォルト・パスワードはchangeitです。デフォルト・パスワードは、keytoolユーティリティを使用して、必ず変更するようにしてください。構文は次のとおりです。

    keytool -storepasswd -new <NewPassword> -keystore <TrustKeyStore> -storepass 
<Original Password>

    たとえば、次のコマンドを入力します。

    keytool -storepasswd -new welcome1 -keystore appTrustKeyStore.jks -storepass 
changeit

  5. 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

4.1.4.4 カスタム・キーストアを使用するためのノード・マネージャの構成

$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

4.2 本番サイトの作成

この項では、本番サイトを作成する手順を説明します。Oracle SOAのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用します。

本番サイトの作成を開始する前に、次の事前準備が完了していることを確認してください。

詳細は、次を参照してください。

4.2.1 Oracle SOA Suiteトポロジの本番サイトの作成

本番サイトは、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。

  1. 第4.1.1.1.1項「Oracle SOA Suiteのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

  2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

  3. 『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の説明に従って、Oracle SOA Suiteをインストールおよび構成します。ただし、次の点が異なります。

    1. 共有ストレージ・デバイス上に作成したボリュームにOracle SOA Suiteコンポーネントをインストールします。

    2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

    3. JMSストアおよびトランザクション・ログ用に各サイトで別個のボリュームを作成します。

    4. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーのホスト名検証の無効化に関する項を参照してください。

    5. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

    6. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.2 Oracle Identity Managementトポロジの本番サイトの作成

本番サイトは、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。

  1. 第4.1.1.3.1項「Oracle Identity Managementのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

  2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

  3. 『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』の説明に従って、Oracle Identity Managementをインストールおよび構成します。ただし、次の点が異なります。

    1. 共有ストレージ・デバイス上に作成したボリュームにOracle Identity Managementコンポーネントをインストールします。

    2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

    3. JMSストアおよびトランザクション・ログ用に各サイトで別個のボリュームを作成します。

    4. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーのホスト名検証の無効化に関する項を参照してください。

    5. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

    6. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.3 Oracle WebCenter Portalトポロジの本番サイトの作成

本番サイトは、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。

  1. 第4.1.1.2.1項「Oracle WebCenter Portalのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

  2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

  3. Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle WebCenter Portalをインストールおよび構成しますが、次の点が異なります。

    1. 共有ストレージ・デバイス上に作成したボリュームにOracle WebCenter Portalコンポーネントをインストールします。

    2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

    3. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドのOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーに対するホスト名検証の無効化に関する説明を参照してください。

    4. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

    5. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.4 Oracle WebCenter Contentトポロジの本番サイトの作成

本番サイトは、Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。

  1. 第4.1.1.5.1項「Oracle WebCenter Contentのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

  2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

  3. Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle Enterprise Content Managementをインストールおよび構成しますが、次の点が異なります。

    1. 共有ストレージ・デバイス上に作成したボリュームにOracle Enterprise Content Managementコンポーネントをインストールします。

    2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

    3. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドの管理サーバーに対するホスト名検証の無効化に関する説明を参照してください。

    4. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

    5. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.5 Oracle Business Intelligenceトポロジの本番サイトの作成

本番サイトは、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。

  1. 第4.1.1.6.1項「Oracle Business Intelligenceのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

  2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

  3. Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle Business Intelligenceをインストールおよび構成しますが、次の点が異なります。

    1. 共有ストレージ・デバイス上に作成したボリュームにOracle Business Intelligenceコンポーネントをインストールします。

    2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

    3. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのbi_server1管理対象サーバーに対するホスト名検証の無効化に関する説明およびbi_server2管理対象サーバーに対するホスト名検証の無効化に関する説明を参照してください。

    4. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

    5. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.6 Oracle Portal、Forms、ReportsおよびDiscovererトポロジの本番サイトの構成

本番サイトは、次の製品のエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要があります。

  • Oracle Portal

    図4-9に示されている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は次のとおりです。

    http://support.oracle.com

  • Oracle Forms、ReportsおよびDiscoverer

    図4-10に示されている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は次のとおりです。

    http://support.oracle.com

前述のマニュアルの説明に従ってインストールおよび構成を行う必要がありますが、次のような違いがあります。示された手順に従ってください。

  1. 第4.1.1.4.1項「Oracle Portal、Forms、ReportsおよびDiscoverのボリューム設計」の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。

  2. 本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項「ホスト名の計画」を参照してください。

  3. 前述のリンク先のホワイト・ペーパーの説明に従って、Oracle Portal、Forms、ReportsおよびDiscovererをインストールおよび構成します。ただし、次の点が異なります。

    1. 共有ストレージ・デバイス上に作成したボリュームにOracle Portal、Forms、ReportsおよびDiscovererコンポーネントをインストールします。

    2. WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。

    3. 本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドのOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーに対するホスト名検証の無効化に関する説明を参照してください。

    4. ホスト名の検証をオフにしない場合は、第4.1.4項「ノード・マネージャ」に記載されている手順に従って、ノード・マネージャの通信を構成します。

    5. ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。

4.2.7 本番サイトの設定の検証

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を介したアクセスの検証に関する項

4.3 スタンバイ・サイトの作成

この項では、スタンバイ・サイトを作成する手順を説明します。Oracle SOAのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用します。

次のトピックが含まれます:

4.3.1 スタンバイ・サイトの作成

スタンバイ・サイトの作成を開始する前に、次の事前準備が完了していることを確認してください。

  • スタンバイ・サイトで、第3.1.1項「ホスト名の計画」の手順に従って、ホスト名別名および物理ホスト名が正しく設定されていることを確認します。

    スタンバイ・サイトの各ホストに、本番サイトのピア・ホストの物理ホスト名と同じホスト名別名が設定されていることを確認してください。

  • スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。

  • スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

4.3.1.1 データベースの設定

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;

4.3.1.2 中間層の設定

スタンバイ・サイトの中間層ホストでは、Oracle Fusion MiddlewareおよびWebLogic Serverソフトウェアのインストールや構成を行う必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。

スタンバイ・サイトの中間層ホストを設定する手順は、次のとおりです。

  1. 本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、ストレージ・デバイス間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。

  2. 本番サイトの共有ストレージをスタンバイ・サイトの共有ストレージと同期します。これによって、本番サイトからスタンバイ・サイトに初期のベースライン・スナップショットが転送されます。

  3. スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。

  4. ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。

4.3.2 スタンバイ・サイトの設定の検証

次の手順に従って、スタンバイ・サイトを検証します。

  1. 本番サイトで実行中のプロセスを停止します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

  2. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

  3. Oracle Data Guardを使用して、データベースをフェイルオーバーします。

  4. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

  5. ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。

4.4 非対称スタンバイ・サイトの作成

この項の手順では、Oracle Fusion Middleware障害時リカバリの非対称トポロジを設定する方法を説明します。

非対称トポロジは、本番サイトとスタンバイ・サイトの層で異なる障害時リカバリ構成です。Oracle Fusion Middleware障害時リカバリのほとんどの非対称トポロジでは、スタンバイ・サイトのリソースの数が本番サイトより少なくなっています。

この項を読む前に必ず、このマニュアルで前述した対称トポロジの設定に関する概念と情報に目を通し、理解しておいてください。対称トポロジの設定に関する概念の多くは、非対称トポロジを設定する際にも有効です。

第4.4.1項「非対称スタンバイ・サイトの作成」では、非対称トポロジを作成する際の基本的な手順を説明します。この章の前半で対称トポロジについてすでに説明した、非対称トポロジの設定に適用される概念については、詳しく説明しません。

4.4.1 非対称スタンバイ・サイトの作成

この項では、Oracle Fusion Middleware障害時リカバリのあらゆるタイプの非対称トポロジを作成する際の大まかな手順を説明します。本番サイトは、図4-2に示されているOracle SOA Suiteのエンタープライズ・デプロイメントです。スタンバイ・サイトは本番サイトと異なるものになります。

非対称トポロジを作成する手順は次のとおりです。

  1. 本番サイトとスタンバイ・サイトを設計します。スタンバイ・サイトが本番ロールを引き継いだときに許容されるパフォーマンスを確保できるように、スタンバイ・サイトで必要となるリソースを特定してください。


    注意:

    スタンバイ・サイト・インスタンスのポートでは、本番サイトのピア・インスタンスと同じポート番号を使用する必要があります。そのため、スタンバイ・サイトで必要となるすべてのポート番号が使用可能である(スタンバイ・サイトで使用中でない)ことを確認してください。

  2. 次の操作を実行して、Oracle Fusion Middleware障害時リカバリの本番サイトを作成します。

    1. 本番サイトの共有ストレージ・システムで、本番サイト用にインストールするOracle Fusion Middlewareインスタンスのボリュームを作成します。詳細は、第4.1.1項「ディレクトリ構造とボリューム設計」を参照してください。

    2. 本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。ボリューム設計の詳細は、第4.1.1.1.1項「Oracle SOA Suiteのボリューム設計」を参照してください。

    3. 本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。Oracle中央インベントリ・ディレクトリの詳細は、第3.2.2項「OracleホームとOracleインベントリ」を参照してください。

    4. 本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle HTTP Serverインスタンスに対して、静的HTMLページ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します(該当する場合)。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。

    5. 本番サイトの共有ストレージ・システムのボリュームに、本番サイト用のOracle Fusion Middlewareインスタンスをインストールします。詳細は、第4.2.1項「Oracle SOA Suiteトポロジの本番サイトの作成」を参照してください。

  3. スタンバイ・サイトの共有ストレージ・システムでも、本番サイトの共有ストレージ・システムでOracle Fusion Middlewareインスタンスに対して作成したのと同じボリュームを、同じファイル権限とディレクトリ権限で作成します。この手順は重要です。これにより、後からストレージ・レプリケーションを使用してスタンバイ・サイト用にOracle Fusion Middlewareのピア・インスタンスのインストールを作成できるようになり、Oracle Universal Installerを使用したインストールが不要になるからです。


    注意:

    ストレージ・レプリケーションを構成する際には、本番サイトの共有ストレージ・システムで設定したすべてのボリュームがスタンバイ・サイトの共有ストレージ・システム上の同じボリュームにレプリケートされるようにしてください。

    本番サイトの一部のインスタンスやホストがスタンバイ・サイトに存在しない場合でも、本番サイトのOracle Fusion Middlewareインスタンスに対して設定したすべてのボリュームでストレージ・レプリケーションを構成する必要があります。

  4. 共有ストレージ・ベンダーが規定しているその他の必要な構成を実行して、本番サイトの共有ストレージ・システムとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にします。本番サイトの共有ストレージ・システムのボリュームをスタンバイ・サイトの共有ストレージ・システムに非同期でコピーするように、ストレージ・レプリケーションを構成してください。

  5. 本番サイトの共有ストレージ・システムの初期のベースライン・スナップショット・コピーを作成して、本番サイトとスタンバイ・サイトの共有ストレージ・システム間のレプリケーションを設定します。初期のベースライン・スナップショット・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリュームのすべてのディレクトリの内容が本番サイトのボリュームのディレクトリと同じであることを検証します。初期のスナップショットを作成する方法、および本番サイトとスタンバイ・サイトの共有ストレージ・システム間のストレージ・レプリケーションを有効にする方法の詳細は、共有ストレージ・ベンダーのドキュメントを参照してください。

  6. ベースライン・スナップショットを作成したら、スタンバイ・サイトのホストでOracle Fusion Middlewareインスタンスについて次の手順を実行します。

    1. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。

    2. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracleホーム・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。

    3. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。

    4. スタンバイ・サイトの共有ストレージ・システム上のOracle Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのシンボリック・リンクをスタンバイ・サイトのホスト上に設定します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項「ストレージ・レプリケーション」を参照してください。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するシンボリック・リンクは、そのインスタンスに対して本番サイトのホスト上に設定したシンボリック・リンクと同じである必要があります。

    5. スタンバイ・サイトの共有ストレージ・システム上のOracle HTTP Serverインスタンスに対して、Oracle HTTP Serverの静的HTMLページ・ディレクトリへのマウント・ポイント・ディレクトリをスタンバイ・サイトのホスト上に設定します。スタンバイ・サイトのホスト上のピア・インスタンスに対して設定するマウント・ポイント・ディレクトリは、そのインスタンスに対して本番サイトのホスト上に設定したマウント・ポイント・ディレクトリと同じである必要があります。

    6. スタンバイ・サイトの共有ストレージ・システム上の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インスタンスには、本番サイトの同じインスタンスに使用されているものと同じポートが使用されています。

4.4.1.1 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイトの作成

この項では、ホストおよびOracle Fusion Middlewareインスタンスの数が本番サイトより少ない非対称スタンバイ・サイトを作成する方法を説明します。

このOracle Fusion Middleware障害時リカバリ・トポロジの本番サイトは、図4-2に示されているOracle SOA Suiteのエンタープライズ・デプロイメントです。この本番サイトとその共有ストレージ・システムのボリュームを設定する方法、および必要なマウント・ポイントを作成する方法は、第4.1項「サイトの設定」から第4.1.1項「ディレクトリ構造とボリューム設計」に記載されています。

図4-15に、図4-2に示されている本番サイトの非対称スタンバイ・サイトを示します。

図4-15 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイト

図4-15の説明が続きます
「図4-15 ホストおよびインスタンスの数が少ない非対称スタンバイ・サイト」の説明

図4-15に示されているOracle SOA Suiteの非対称スタンバイ・サイトのホストおよびインスタンスの数は、図4-2に示されているOracle SOA Suiteの本番サイトより少なくなっています。

図4-2の本番サイトには、ホストWEBHOST2およびSOAHOST2とこれらのホスト上のインスタンスが存在しますが、図4-15の非対称スタンバイ・サイトには、これらのホストとそのインスタンスが存在しません。そのため、スタンバイ・サイトのホストおよびインスタンスの数は、本番サイトより少なくなっています。

この非対称スタンバイ・サイトには、本番ロールを引き継いだときに適切なパフォーマンスを提供できるように、十分なリソースを確保することが重要です。

第4.4.1項「非対称スタンバイ・サイトの作成」に記載されている手順に従って、この非対称スタンバイ・サイトを設定すれば、スタンバイ・サイトは本番ロールを引き継ぐように適切に構成されます。

非対称スタンバイ・サイトを正しく設定するには、本番サイトの共有ストレージで作成したものと同じボリュームおよびコンシステンシー・グループをスタンバイ・サイトの共有ストレージで作成します。たとえば、Oracle SOA Suiteデプロイメントについて、表4-4のボリューム設計に関する推奨事項と表4-5のコンシステンシー・グループに関する推奨事項を使用して、本番サイトの共有ストレージを設定したとします。その場合、本番サイトの共有ストレージに使用したものと同じボリューム設計に関する推奨事項とコンシステンシー・グループに関する推奨事項を使用して、非対称スタンバイ・サイトの共有ストレージを設定します。

非対称スタンバイ・サイトでは、本番サイトに存在する一部のホストがスタンバイ・サイトに存在しません。たとえば、図4-15に示されているOracle SOA Suiteの非対称スタンバイ・サイトの場合、WEBHOST2とSOAHOST2がスタンバイ・サイトに存在しないため、スタンバイ・サイトの共有ストレージ・ボリュームに対してこれらのホスト上にマウント・ポイントを作成することはできず、作成する必要はありません。

4.4.2 非対称スタンバイ・サイトの設定の検証

次の手順に従って、スタンバイ・サイトを検証します。

  1. 本番サイトで実行中のプロセスを停止します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

  2. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

  3. Oracle Data Guardを使用して、データベースをフェイルオーバーします。

  4. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

  5. ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。

4.5 サイトの操作および管理の実行

この項では、Oracle Fusion Middleware障害時リカバリ・トポロジで実行する操作および管理について説明します。

4.5.1 サイトの同期

スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。

本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行する必要があります。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。

Oracle Fusion Middleware障害時リカバリ・トポロジでのデータベースの同期は、Oracle Data Guardによって管理されます。

4.5.2 スイッチオーバーの実行

本番サイトを停止し(保守を行う場合など)、現在のスタンバイ・サイトを新しい本番サイトにする場合は、スタンバイ・サイトが本番ロールを引き継ぐように、スイッチオーバー操作を実行する必要があります。

スイッチオーバー操作を実行する手順は、次のとおりです。

  1. 本番サイトで実行中のプロセスを停止します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

  2. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

  3. Oracle Data Guardを使用して、データベースをスイッチオーバーします。

  4. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

  5. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがスタンバイ・サイトにルーティングされるようにします。

  6. ブラウザ・クライアントを使用してスイッチオーバー後のテストを実行し、リクエストが解決されてスタンバイ・サイトにリダイレクトされていることを確認します。

    これで、元のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトが新しいスタンバイ・サイトになりました。

  7. 2つのサイト間のレプリケーションを再確立します。ただし、スナップショット・コピーが逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。

前述の手順が完了すると、元のスタンバイ・サイトが新しい本番サイトになります。これで、元の本番サイトで保守を実行できるようになります。予定していた作業を元の本番サイトで実行した後、将来のいずれかの時点で、そのサイトを本番サイトまたはスタンバイ・サイトとして再度使用できます。

元の本番サイトを新しい本番サイトとして使用するには、第4.5.3項「スイッチバックの実行」に記載されているスイッチバック手順を実行してください。

4.5.3 スイッチバックの実行

スイッチオーバー操作を実行した後、スイッチバック操作を実行して、現在の本番サイトと現在のスタンバイ・サイトをスイッチオーバー操作前のロールに戻すことができます。

スイッチバック操作を実行する手順は、次のとおりです。

  1. 現在の本番サイトで実行中のプロセスを停止します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

  2. 現在の本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

  3. Oracle Data Guardを使用して、データベースをスイッチバックします。

  4. 新しい本番サイトのホストで、すべてのプロセスを手動で開始します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

  5. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストが新しい本番サイトにルーティングされるようにします。

  6. ブラウザ・クライアントを使用してスイッチバック後のテストを実行し、リクエストが解決されて新しい本番サイトにリダイレクトされていることを確認します。

    これで、元のスタンバイ・サイトが新しい本番サイトになり、元の本番サイトが新しいスタンバイ・サイトになりました。

  7. 2つのサイト間のレプリケーションを再確立します。ただし、スナップショット・コピーが逆方向に(新しい本番サイトから新しいスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。

4.5.4 フェイルオーバーの実行

本番サイトが予期せず使用できなくなった場合、スタンバイ・サイトが本番ロールを引き継ぐように、フェイルオーバー操作を実行する必要があります。

フェイルオーバー操作を実行する手順は、次のとおりです。

  1. 本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のレプリケーションを停止します。

  2. スタンバイ・サイトから、Oracle Data Guardを使用して、データベースをフェイルオーバーします。

  3. スタンバイ・サイトのホストで、すべてのプロセスを手動で開始します。これには、データ層のデータベース・インスタンス、Oracle Fusion Middlewareインスタンスおよびアプリケーション層とWeb層のその他のプロセスが含まれます。

  4. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストがスタンバイ・サイトにルーティングされるようにします。

  5. ブラウザ・クライアントを使用してフェイルオーバー後のテストを実行し、リクエストが解決されて本番サイトにリダイレクトされていることを確認します。

    これで、スタンバイ・サイトが新しい本番サイトになりました。元の本番サイトが使用できなくなった原因を調べることができます。

  6. 元の本番サイトを現在のスタンバイ・サイトとして使用するには、2つのサイト間のレプリケーションを再確立する必要があります。ただし、スナップショット・コピーが逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)転送されるようにレプリケーションを構成してください。スナップショット・コピーが逆方向に転送されるようにレプリケーションを構成する方法の詳細は、ご使用の共有ストレージのドキュメントを参照してください。

元の本番サイトを新しい本番サイトとして使用するには、第4.5.3項「スイッチバックの実行」に記載されているスイッチバック手順を実行してください。

4.5.5 スタンバイ・サイトの定期テストの実行

このマニュアルでは、Oracle Fusion Middlewareの本番サイトとスタンバイ・サイトの障害時リカバリを設定する方法を説明します。Oracle Fusion Middleware障害時リカバリの通常の構成は、次のようになっています。

  • ストレージ・レプリケーションを使用して、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージにOracle Fusion Middlewareの中間層のファイル・システムおよびデータをコピーします。通常の操作時には、本番サイトはアクティブで、スタンバイ・サイトはパッシブです。本番サイトがアクティブな場合、スタンバイ・サイトはパッシブで、スタンバイ・サイトの共有ストレージは読取り専用モードです。スタンバイ・サイトの共有ストレージに対して行われる書込み操作は、本番サイトの共有ストレージからスタンバイ・サイトの共有ストレージへのストレージ・レプリケーション操作のみです。

  • Oracle Data Guardを使用して、本番サイトのOracle Databaseのデータベース・データをスタンバイ・サイトのスタンバイ・データベースにコピーします。デフォルトでは、本番サイトのデータベースはアクティブで、スタンバイ・サイトのスタンバイ・データベースはパッシブです。スタンバイ・サイトがスタンバイ・ロールの間(パッシブである間)、スタンバイ・サイトのスタンバイ・データベースは管理リカバリ・モードです。本番サイトがアクティブな場合、スタンバイ・データベースに対して行われる書込み操作は、Oracle Data Guardによって実行されるデータベースの同期操作のみです。

  • 本番サイトが使用できなくなったときには、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。現在の本番サイトが予期せず使用できなくなった場合は、フェイルオーバー操作(第4.5.4項「フェイルオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。また、現在の本番サイトを意図的に停止する場合は(予定した保守の場合など)、スイッチオーバー操作(第4.5.2項「スイッチオーバーの実行」を参照)を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。

通常の方法でスタンバイ・サイトをテストする場合は、現在の本番サイトを停止し、スイッチオーバー操作を実行して、本番ロールを引き継ぐようにスタンバイ・サイトを有効にします。ただし、企業では、現在の本番サイトを停止してスイッチオーバー操作を実行することなく、障害時リカバリのスタンバイ・サイトの定期テストを実行することもできます。

現在の本番サイトを停止せずにスタンバイ・サイトをテストする代替方法では、スタンバイ・サイトの読取り専用共有ストレージのクローンを作成し、クローニングされたスタンバイ・サイトの共有ストレージをテストで使用します。この代替テスト方法を使用する手順は、次のとおりです。

  1. 共有ストレージ・ベンダーが提供しているクローニング・テクノロジを使用して、スタンバイ・サイトの共有ストレージでスタンバイ・サイトの読取り専用ボリュームのクローンを作成します。クローニングされたスタンバイ・サイトのボリュームが書込み可能であることを確認します。スタンバイ・サイトを1回だけテストする場合は、1回のみのクローン操作とすることができます。ただし、スタンバイ・サイトを定期的にテストする場合は、スタンバイ・サイトのクローニングされた読取り/書込みボリュームへのスタンバイ・サイトの読取り専用ボリュームの定期クローニングを設定できます。

  2. スタンバイ・サイトのデータベースのバックアップを実行し、本番サイトとスタンバイ・サイトのデータベース間のOracle Data Guardレプリケーションを変更します。

    • 10.1のデータベースについては、10.1 Oracle Data Guardのドキュメントに記載されている手順に従って、レプリケーションを中断します。

    • 10.2以降のデータベースについては、次の手順に従って、スナップショット・スタンバイ・データベースを確立します。

      1. フラッシュ・リカバリ領域がない場合は、設定します。

      2. REDO Applyを取り消します。

        SQL> ALTER DATABASE RECOVER MANAGED STANDBY
     DATABASE CANCEL;

      3. 保証付きリストア・ポイントを作成します。

        SQL> CREATE RESTORE POINT standbytest
     GUARANTEE FLASHBACK DATABASE;

      4. プライマリ(本番)サイトで現在のログをアーカイブします。

        SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

      5. アクティブ化するスタンバイ・サイト接続先を遅延させます。

        SQL> ALTER SYSTEM SET
     LOG_ARCHIVE_DEST_STATE_2=DEFER;

      6. ターゲット・スタンバイ・データベースをアクティブ化します。

        SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

      7. データベースが読取り専用で開いている場合、Forceオプションを指定してデータベースをマウントします。

        SQL> STARTUP MOUNT FORCE;

      8. 保護モードを下げて、データベースを開きます。

        SQL> ALTER DATABASE SET STANDBY DATABASE TO 
     MAXIMIZE PERFORMANCE;
SQL> ALTER DATABASE OPEN;

    • 11gのデータベースについては、『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースの管理に関する項に記載されている手順に従って、スナップショット・スタンバイ・データベースを確立します。

  3. Oracle Data Guardのデータベース・リカバリ手順に従って、スタンバイ・データベースをオンラインにします。

  4. スタンバイ・サイトのコンピュータで、次の手順に従って、スタンバイ・サイトのクローニングされた読取り/書込み共有ストレージ・ボリュームを指すようにmountコマンドを変更します。

    1. 読取り専用の共有ストレージ・ボリュームをアンマウントします。

    2. クローニングされた読取り/書込みボリュームを同じマウント・ポイントでマウントします。

  5. スタンバイ・サイトのテストを実行する前に、ホスト名が本番サイトのコンピュータではなくスタンバイ・サイトのコンピュータを指すように、テストの実行に使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、スタンバイ・サイトのロード・バランサの仮想IPを指すように/etc/hostsファイルを変更します。

  6. スタンバイ・サイトのテストを実行します。

スタンバイ・サイトのテストが完了したら、次の手順に従って、元の本番サイトを本番サイトとして再度使用します。

  1. スタンバイ・サイトのコンピュータで、スタンバイ・サイトの読取り専用共有ストレージ・ボリュームを指すようにmountコマンドを変更します。つまり、mountコマンドを、テストを実行する前の状態に戻します。

    1. クローニングされた共有ストレージの読取り/書込みボリュームをアンマウントします。

    2. 読取り専用の共有ストレージ・ボリュームをマウントします。

    これで、mountコマンドがスタンバイ・サイトのテストを実行する前の状態にリセットされました。

  2. 本番サイトのデータベースとスタンバイ・サイトのスタンバイ・データベース間のレプリケーションを実行するように、Oracle Data Guardを構成します。この構成を実行すると、スタンバイ・データベースは再度、管理リカバリ・モードに設定されます。

    • 10.1のデータベースについては、10.1 Oracle Data Guardのドキュメントに記載されている手順に従って、データベースを再インスタンス化します。

    • 10.2以降のデータベースについては、次の手順に従います。

      1. アクティブ化したデータベースをフィジカル・スタンバイ・データベースに戻します。

        SQL> STARTUP MOUNT FORCE;
SQL> FLASHBACK DATABASE TO POINT standbytest;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> STARTUP MOUNT FORCE;

      2. 管理リカバリを再開します。

        SQL> ALTER DATABASE RECOVER MANAGED STANDBY
     DATABASE USING CURRENT LOGFILE DISCONNECT;

      3. スタンバイ接続先を再度有効にし、ログを切り替えます。

        SQL> ALTER SYSTEM SET
     LOG ARCHIVE DEST STATE 2=ENABLE;

    • 11gのデータベースについては、『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースの管理に関する項に記載されている手順に従って、レプリケーションを再度設定します。

  3. 元の本番サイトを再度使用する前に、ホスト名がスタンバイ・サイトのコンピュータではなく本番サイトのコンピュータを指すように、本番サイトへのアクセスに使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、本番サイトのロード・バランサの仮想IPを指すように/etc/hostsファイルを変更します。

4.5.6 テストでのpeer-to-peerファイル・コピーの使用

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では、データの整合性は保証されません。

ストレージ・レプリケーションと比較すると、このような短所があるため、実際の本番環境では、障害時リカバリにrsyncを使用することはできません。

4.5.6.1 Oracle Fusion Middleware障害時リカバリ・トポロジでのrsyncとOracle Data Guardの使用

rsyncとOracle Data Guardを使用して、Oracle Fusion Middleware障害時リカバリ・トポロジの障害保護および障害時リカバリを実現するときには、次の2つの基本原則が適用されます。

  1. Oracle Fusion Middleware中間層コンポーネントの障害保護には、rsyncを使用します。

  2. Oracle Fusion Middlewareトポロジで使用されるOracle Databaseの障害保護には、Oracle Data Guardを使用します。Oracle Databaseの障害時リカバリを実現するようにOracle Data Guardを設定する方法の詳細は、第3.3項「データベースに関する考慮事項」を参照してください。

4.5.6.1.1 Oracle Fusion Middleware中間層コンポーネントでのrsyncの使用

rsyncを使用してOracle Fusion Middleware中間層コンポーネントの障害保護および障害時リカバリを実現する手順は、次のとおりです。

  1. 本番サイトのホストからスタンバイ・サイトのピア・ホストへのファイルのレプリケーションが有効になるように、rsyncを設定します。rsyncをインストールおよび設定する手順、および構文と使用方法の詳細は、rsyncのマニュアル・ページを参照してください。rsyncに関する情報は、http://rsync.samba.orgで入手できます。

  2. 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キーを設定します。

  3. 前の手順でrsyncを設定した本番サイトのホストについて、cronジョブなどのスケジュール済ジョブを設定します。これらのスケジュール済ジョブを使用すると、rsyncによって、本番サイトのホストからスタンバイ・サイトのホストへのこれらのファイルのレプリケーションを定期的に自動実行できます。Oracle Fusion Middlewareの構成がそれほど頻繁に変更されない本番サイトについては、1日1回の間隔をお薦めします。

  4. 本番サイトのホストでOracle Fusion Middlewareの中間層の構成が変更された場合(新しいアプリケーションがデプロイされた場合など)は必ず、rsyncを使用して、スタンバイ・サイトのピア・ホストとそのホストの手動同期を実行する必要があります。

  5. 本番サイトのホスト上にあるOracle Fusion Middlewareの中間層インスタンスを、rsyncを使用して手動でスタンバイ・サイトのピア・ホストと同期させた場合は、関連する本番サイトのOracle Fusion Middlewareインスタンスのデータベース・リポジトリも、Oracle Data Guardを使用して手動で強制的にスタンバイ・サイトと同期させる必要があります。Oracle Data Guardを使用してOracle Databaseを手動で強制的に同期させる方法の詳細は、第3.3.2項「Oracle Data Guardでのデータベース同期の手動強制」を参照してください。

4.5.6.1.2 フェイルオーバー操作およびスイッチオーバー操作の実行

rsyncを使用している場合、本番サイトからスタンバイ・サイトへのフェイルオーバーまたはスイッチオーバーを実行する手順は次のとおりです。

  1. 本番サイトで実行中のプロセスを停止します(該当する場合)。

  2. 本番サイトのホストとスタンバイ・サイトのピア・ホスト間のrsyncジョブを停止します。

  3. Oracle Data Guardを使用して、本番サイトのデータベースをスタンバイ・サイトにフェイルオーバーします。

  4. スタンバイ・サイトで、Oracle Fusion Middlewareサーバー・インスタンスのプロセスを手動で開始します。

  5. グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストをスタンバイ・サイトにルーティングします。

  6. ブラウザ・クライアントを使用してフェイルオーバー後またはスイッチオーバー後のテストを実行し、スタンバイ・サイト(現在の本番サイト)でリクエストが解決されていることを確認します。

    これで、スタンバイ・サイトが新しい本番サイトになり、本番サイトが新しいスタンバイ・サイトになりました。

  7. 2つのサイト間のrsyncレプリケーションを再確立します。ただし、逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)レプリケートされるようにレプリケーションを構成してください。

元の本番サイトを新しい本番サイトとして使用するには、前述の手順をもう一度実行します。ただし、元の方向で(元の本番サイトから元のスタンバイ・サイトへ)レプリケートされるようにrsyncレプリケーションを構成してください。

4.6 Oracle Fusion Middleware障害時リカバリ・サイトへのパッチの適用

この項では、11g Oracle Fusion Middlewareパッチ・セットを適用して、Oracle Fusion Middleware障害時リカバリ・サイトに含まれるOracleホームをアップグレードする方法を説明します。

この項の一覧では、Oracle Fusion Middleware障害時リカバリの本番サイトでパッチ・セットを適用して、11g Oracle Fusion Middlewareホームをアップグレードする手順について説明します。

次の手順は、パッチを適用するOracle Fusion MiddlewareインスタンスのOracle中央インベントリが本番サイトの共有ストレージに配置されていて、パッチが適用されたインスタンスのOracle中央インベントリをスタンバイ・サイトにレプリケートできるようになっていることを前提としています。

11g Oracle Fusion Middlewareのパッチ・バージョンをアップグレードする手順は、次のとおりです。

  1. 開始時の状態が保持されるように、本番サイトのバックアップを実行します。

  2. パッチ・セットを適用して、本番サイトのインスタンスをアップグレードします。

  3. パッチ・セットを適用したら、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージを手動で強制的に同期させます。これによって、本番サイトのパッチが適用されたインスタンスとOracle中央インベントリがスタンバイ・サイトの共有ストレージにレプリケートされます。

  4. パッチ・セットを適用したら、Oracle Data Guardを使用して、本番サイトとスタンバイ・サイトのOracle Databaseを手動で強制的に同期させます。Oracle Fusion Middlewareの一部のパッチ・セットでは、リポジトリが更新される場合があります。そのため、この手順を必ず実行して、本番サイトのデータベースの変更をスタンバイ・サイトのデータベースに同期させます。

  5. これでアップグレードは完了です。障害時リカバリ・トポロジで処理を再開できます。


注意:

パッチは、11g Oracle Fusion Middleware障害時リカバリ・トポロジの本番サイトでのみ適用する必要があります。Oracle Fusion MiddlewareインスタンスまたはOracle中央インベントリのパッチの場合、本番サイトの共有ストレージがスタンバイ・サイトの共有ストレージにレプリケートされるときに、パッチがコピーされます。本番サイトでパッチをインストールした場合は、同期操作を実行する必要があります。

同様に、本番サイトのデータベースのパッチをインストールした場合、同期を実行すると、Oracle Data Guardによってスタンバイ・サイトのスタンバイ・データベースにパッチがコピーされます。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引