この章では、Oracle SOA Suiteのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用して、本番サイトおよびスタンバイ・サイトの設定に必要な手順を説明します。
この章では、次の項目について説明します。
注意: Oracle Site Guardを使用してスイッチオーバーやフェイルオーバーなどの障害回復操作を自動化することができます。詳細は、Oracle Enterprise Managerライフサイクル管理ガイドのOracle Site Guardの使用に関する項を参照してください。 |
この項では、本番サイトを作成する手順を説明します。Oracle SOAのエンタープライズ・デプロイメント・トポロジとOracle Identity Managementのエンタープライズ・デプロイメント・トポロジを例として使用します。
次のトピックが含まれます:
本番サイトの作成を開始する前に、次の事前準備が完了したことを確認してください。
第3.1.1項で説明されているように、中間層ホストのホスト名別名を設定します。
本番サイトの共有ストレージに必要なボリュームを作成します。第4.1.1項を参照してください。
マウント・ポイントおよびシンボリック・リンク(必要な場合)を作成します。第3.2.3項を参照して、本番サイトにシンボリック・リンクを作成する必要があるかどうかを確認してください。
使用するOracle Data Guard構成は、データベースのデータ損失要件に加えて、REDO生成と比較した場合の使用可能な帯域幅や待機時間など、ネットワークに関する考慮事項に基づいて決定します。
詳細は、『Oracle Data Guard概念および管理』、および関連事項として次のURLにある最大可用性アーキテクチャに関する情報を参照してください。
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
次の項では、お薦めするディレクトリ構造について詳しく説明します。エンド・ユーザーは他のディレクトリ・レイアウトを選択してもかまいませんが、ここで採用されているモデルを使用すると、コンポーネントが最適に分離され、構成における対称性が保たれるとともに、バックアップと障害時リカバリが容易になり、最大限の可用性が実現されます。
次の一覧では、ディレクトリとディレクトリ環境変数について説明します。
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インスタンスのディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなど、更新可能なファイルが格納されます。
詳細は、次の各項を参照してください。
Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のSOA管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリ・ファイルをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMiddlewareホーム(それぞれに、各製品スイートのWL_HOME
とORACLE_HOME
がある)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムへの配置もサポートされていますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-1は、Oracle SOA Suiteのディレクトリ構造のレイアウトを示しています。
このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』およびOracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドを参照してください。
表4-1では、図4-1で色分けされている要素の意味を説明します。図4-1のディレクトリ構造には、oracle_common
やjrockit
など、その他の必要な内部ディレクトリは示されていません。
表4-1 ディレクトリ構造の要素
要素 | 説明 |
---|---|
管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとT-Logおよび |
|
固定名 |
|
インストール依存名 |
図4-2および図4-3は、Oracle SOA Suiteのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle SOA Suiteトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』を参照してください。
この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 |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
アプリケーション |
|
|
|
管理サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
トランザクション・ログおよび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のコンシステンシー・グループ
層 | グループ名 | メンバー | コメント |
---|---|---|---|
アプリケーション |
|
|
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
アプリケーション |
|
|
JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ |
アプリケーション |
|
|
Middlewareホーム用のコンシステンシー・グループ |
Web |
|
|
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
Web |
|
|
Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のOracle WebCenter Portal管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリ・ファイルをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMiddlewareホーム(それぞれに、各製品スイートのWL_HOME
とORACLE_HOME
がある)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムへの配置もサポートされていますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-1は、Oracle WebCenter Portalのディレクトリ構造のレイアウトを示しています(Oracle SOA SuiteとOracle WebCenter Portalの両方に同じディレクトリ構造のレイアウトが使用されます)。
図4-4は、Oracle WebCenter Portalのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle WebCenter Portalトポロジのものです。このトポロジのインストールおよび構成の手順は、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドを参照してください。
図4-4 Oracle Access Managerを使用したOracle WebCenter Portalトポロジ
この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ファイル・ストアおよびJava Transaction API (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 |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
アプリケーション |
|
|
|
管理サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
SOAの管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
SOAの管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
Oracle WebCenter Portalの管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
Oracle WebCenter Portalの管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
トランザクション・ログおよびJMSデータ用のボリューム |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
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のコンシステンシー・グループ
層 | グループ名 | メンバー | コメント |
---|---|---|---|
アプリケーション |
|
|
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
アプリケーション |
|
|
JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ |
アプリケーション |
|
|
Middlewareホーム用のコンシステンシー・グループ |
Web |
|
|
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
Web |
|
|
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-5に、Oracle Identity Managementのディレクトリ構造のレイアウトを示します。
次の表では、図4-5で使用される要素を説明します。
表4-6 ディレクトリ構造の要素
要素 | 説明 |
---|---|
管理サーバー・ドメインのディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ・コントロール・ディレクトリ、JMSとT-LogおよびMW_HOME全体は共有ディスク上にあります。 |
|
管理対象サーバー・ドメインのディレクトリは、共有ディスクに配置する必要があります。また、管理対象サーバー・ドメインのディレクトリを複数のノード上で共有する場合、ノード間で同じ共有ディスクの場所をマウントする必要があります。Web層の |
|
固定名 |
|
インストール依存名 |
このディレクトリ構造の設定の詳細は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。図4-5のディレクトリ構造には、oracle_common
やjrockit
など、その他の必要な内部ディレクトリは示されていません。
図4-6、図4-7および図4-8は、Oracle Identity Managementのトポロジを示しています。この項で説明するボリューム設計は、これらのOracle Identity Managementトポロジのものです。トポロジのインストールおよび構成の手順は、『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』を参照してください。
図4-6 Oracle Access Managerを使用したOracle Identity Managementトポロジ
図4-7 Oracle Access ManagerおよびOracle Identity Managerを使用したOracle Identity Managementトポロジ
図4-8 Oracle Adaptive Access Managerを使用したOracle Identity Managementトポロジ
図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 |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
アプリケーション |
|
|
|
Identity ManagementのMiddlewareホーム用のボリューム |
アプリケーション |
|
|
|
Identity ManagementのMiddlewareホーム用のボリューム |
アプリケーション |
|
|
|
Oracleインスタンス用のボリューム |
アプリケーション |
|
|
|
Oracleインスタンス用のボリューム |
ディレクトリ |
|
|
|
Oracle Internet DirectoryのOracleホーム用のボリューム |
ディレクトリ |
|
|
|
Oracle Internet DirectoryのOracleホーム用のボリューム |
ディレクトリ |
|
|
|
Oracle Internet DirectoryのOracleインスタンス用のボリューム |
ディレクトリ |
|
|
|
Oracle Internet DirectoryのOracleインスタンス用のボリューム |
ディレクトリ |
|
|
|
Oracle Virtual DirectoryのOracleホーム用のボリューム |
ディレクトリ |
|
|
|
Oracle Virtual DirectoryのOracleホーム用のボリューム |
ディレクトリ |
|
|
|
Oracle Virtual DirectoryのOracleインスタンス用のボリューム |
ディレクトリ |
|
|
|
Oracle Virtual DirectoryのOracleインスタンス用のボリューム |
アプリケーション |
|
|
|
トランザクション・ログおよびJMSデータ用のボリューム |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
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のコンシステンシー・グループ
層 | グループ名 | メンバー | コメント |
---|---|---|---|
ディレクトリ |
|
|
Oracle Internet DirectoryのOracleホーム用のコンシステンシー・グループ |
ディレクトリ |
|
|
Oracle Internet DirectoryのOracleインスタンス用のコンシステンシー・グループ |
ディレクトリ |
|
|
Oracle Virtual DirectoryのOracleホーム用のコンシステンシー・グループ |
ディレクトリ |
|
|
Oracle Virtual DirectoryのOracleインスタンス用のコンシステンシー・グループ |
アプリケーション |
|
|
Middlewareホーム用のコンシステンシー・グループ |
アプリケーション |
|
|
Oracle Identity Managementインスタンス用のコンシステンシー・グループ |
アプリケーション |
|
|
Oracle Access Managementインスタンス用のコンシステンシー・グループ |
データベース |
|
|
データベース・インスタンス用のコンシステンシー・グループ |
Web |
|
|
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
Web |
|
|
Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
図4-9は、Oracle Portalのエンタープライズ・デプロイメント・トポロジ・ダイアグラムです。第4.1.1.4.1項および第4.1.1.4.2項で説明されているボリューム設計とコンシステンシー・グループは、このOracle Portalトポロジを含む障害時リカバリ・サイトのために使用できます。
図4-9のOracle Portalエンタープライズ・トポロジの詳細は、11.1.1.2 Oracle Portalエンタープライズ・デプロイメント・ガイドに記載されています。マニュアルの取得の詳細は、My Oracle Supportで記事ID 952068.1「Oracle Fusion Middleware 11g (11.1.1.2) Enterprise Deployment Guides for Portal, Forms, Reports, and Discoverer」を参照してください。My Oracle SupportのURLは次のとおりです。
図4-10は、Oracle Forms、ReportsおよびDiscovererのエンタープライズ・トポロジ・ダイアグラムです。第4.1.1.4.1項および第4.1.1.4.2項で説明されているボリューム設計とコンシステンシー・グループは、このトポロジを含む障害時リカバリ・サイトのために使用できます。
図4-10のOracle Forms、ReportsおよびDiscovererエンタープライズ・トポロジの詳細は、11.1.1.2 Oracle Forms、ReportsおよびDiscovererエンタープライズ・デプロイメント・ガイドに記載されています。マニュアルの取得の詳細は、My Oracle Supportで記事ID 952068.1「Oracle Fusion Middleware 11g (11.1.1.2) Enterprise Deployment Guides for Portal, Forms, Reports, and Discoverer」を参照してください。My Oracle SupportのURLは次のとおりです。
図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-9のVOLREPOUT
です。
表4-9に、図4-9に示されているOracle Portalトポロジと図4-10に示されているOracle Forms、ReportsおよびDiscovererトポロジの両方を含む障害時リカバリ・サイトのボリューム設計に関する推奨事項の概要を示します。
表4-9 Oracle Portal、Reports、FormsおよびDiscovererのボリューム設計に関する推奨事項
層 | ボリューム名 | マウントされるホスト | マウント・ポイント | コメント |
---|---|---|---|---|
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
アプリケーション |
|
|
|
WebLogic Server、およびOracle Portal、Forms、ReportsおよびDiscovererバイナリ・ファイル用のボリューム |
アプリケーション |
|
|
|
WebLogic Server、およびOracle Portal、Forms、ReportsおよびDiscovererバイナリ・ファイル用のボリューム |
アプリケーション |
|
|
|
Oracleインスタンス用のボリューム |
アプリケーション |
|
|
|
Oracleインスタンス用のボリューム |
アプリケーション |
|
|
|
レポート出力用のボリューム |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
図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のコンシステンシー・グループ
層 | グループ名 | メンバー | コメント |
---|---|---|---|
アプリケーション |
|
|
Middlewareホーム用のコンシステンシー・グループ |
アプリケーション |
|
|
インスタンス・ホーム用のコンシステンシー・グループ |
アプリケーション |
|
|
Oracle Reportsの出力ディレクトリ用のコンシステンシー・グループ |
Web |
|
|
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
Web |
|
|
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つのMiddlewareホーム(それぞれに、各製品スイートのWL_HOME
とORACLE_HOME
がある)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムへの配置もサポートされていますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-11は、Oracle WebCenter Content Suiteのディレクトリ構造のレイアウトを示しています。
図4-11のディレクトリ構造には、oracle_common
やjrockit
など、その他の必要な内部ディレクトリは示されていません。
表4-11では、図4-11で色分けされている要素の意味を説明します。
表4-11 ディレクトリ構造の要素
要素 | 説明 |
---|---|
管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとT-Logおよび |
|
固定名です。 |
|
インストール依存名です。 |
このディレクトリ構造の設定の詳細は、Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドを参照してください。
図4-12は、Oracle WebCenter Contentのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle WebCenter Contentトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドを参照してください。
図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 |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle SOA Suiteバイナリ・ファイルのためのボリューム |
アプリケーション |
|
|
|
管理サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
トランザクション・ログおよびJMSデータ用のボリューム UCM関連の他のディレクトリのためのボリュームは、ドメインの外部に構成されます。 UCMファイル(VaultおよびWebレイアウト)のためのボリュームは、ドメインの外部に構成されます。 |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
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のコンシステンシー・グループ
層 | グループ名 | メンバー | コメント |
---|---|---|---|
アプリケーション |
|
|
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
アプリケーション |
|
|
JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ |
アプリケーション |
|
|
Middlewareホーム用のコンシステンシー・グループ |
Web |
|
|
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
Web |
|
|
Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle Fusion Middleware 11gでは、1つのバイナリ・インストールから複数のOracle Business Intelligence管理対象サーバーを作成できます。そのため、共有ストレージの1箇所にバイナリ・ファイルをインストールして、異なるノードのサーバーでそのインストールを再利用できます。ただし、最大限の可用性を確保するには、冗長バイナリ・インストールを使用することをお薦めします。このモデルでは、2つのMiddlewareホーム(それぞれに、各製品スイートのWL_HOME
とORACLE_HOME
がある)が共有ストレージにインストールされます。同じタイプのサーバーを追加する場合(スケール・アウトまたはスケール・アップする場合)は、これらのいずれかの場所を、追加でインストールすることなくそのまま使用できます。冗長バイナリの場所では、ユーザーは2つの異なるボリュームを使用して、可能なかぎり障害を各ボリュームで分離することが理想的です。さらに保護を強化するために、これらのボリュームでストレージ・レプリケーションを使用することをお薦めします。複数のボリュームが利用できない場合は、マウント・ポイントを使用して、共有ストレージの異なるディレクトリで同じマウント場所をシミュレートすることをお薦めします。これによって、複数のボリュームでの保護が保証されるわけではありませんが、ユーザーによる削除や個々のファイルの破損からの保護が可能になります。
また、管理サーバーと管理対象サーバーで別々のドメイン・ディレクトリが使用されるようにすることをお薦めします。これによって、管理対象サーバーで使用されるドメイン・ディレクトリの対称構成が実現し、管理サーバーのフェイルオーバーが分離されます。管理サーバーのドメイン・ディレクトリは、同じ構成の別のノードにフェイルオーバーできるように、共有ストレージに配置する必要があります。また、管理対象サーバーのドメイン・ディレクトリは、ローカル・ファイル・システムへの配置もサポートされていますが、共有ストレージに配置することをお薦めします。このことは、障害時リカバリ・サイトを念頭に置いて本番サイトを設計するような場合には特に重要です。図4-13は、Oracle Business Intelligence Suiteのディレクトリ構造のレイアウトを示しています。
図4-13のディレクトリ構造には、oracle_common
やjrockit
など、その他の必要な内部ディレクトリは示されていません。
表4-14では、図4-13で色分けされている要素の意味を説明します。
表4-14 ディレクトリ構造の要素
要素 | 説明 |
---|---|
管理サーバーのドメイン・ディレクトリ、管理対象サーバーのドメイン・ディレクトリ、アプリケーション、デプロイメント・プラン、ファイル・アダプタ制御ディレクトリ、JMSとT-LogおよびMW_HOME全体が共有ディスクに配置されます。 |
|
固定名 |
|
インストール依存名 |
このディレクトリ構造の設定の詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドを参照してください。
図4-14は、Oracle Business Intelligenceのトポロジ・ダイアグラムです。この項で説明するボリューム設計は、このOracle Business Intelligenceトポロジのものです。このトポロジをインストールおよび構成する手順の詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドを参照してください。
図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(Oracle BI 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 |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインストール用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
Oracle HTTP Serverインスタンス用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
Web |
|
|
|
静的HTMLコンテンツ用のボリューム |
アプリケーション |
|
|
|
Oracle Business Intelligenceのインスタンス用のボリューム |
アプリケーション |
|
|
|
Oracle Business Intelligenceのインスタンス用のボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle Business Intelligenceのバイナリ・ファイル用のボリューム |
アプリケーション |
|
|
|
WebLogic ServerおよびOracle Business Intelligenceのバイナリ・ファイル用のボリューム |
アプリケーション |
|
|
|
管理サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
管理対象サーバーのドメイン・ディレクトリ用のボリューム |
アプリケーション |
|
|
|
トランザクション・ログおよびJMSデータ用のボリューム |
アプリケーション |
|
|
|
Oracle BIリポジトリ(RPDファイル)、Oracle BI Presentation Catalog、グローバル・キャッシュおよびOracle BI Schedulerの共有スクリプト用のボリューム |
アプリケーション |
|
|
|
Oracle Business Intelligence Publisherの構成ファイル用のボリューム |
アプリケーション |
|
|
|
Oracle Business Intelligence Publisherを使用して作成するオブジェクト(レポート、データ・モデル、スタイル・テンプレートなど)用のボリューム |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
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のコンシステンシー・グループ
層 | グループ名 | メンバー | コメント |
---|---|---|---|
アプリケーション |
|
|
管理サーバー、管理対象サーバーのドメイン・ディレクトリ用のコンシステンシー・グループ |
アプリケーション |
|
|
JMSファイル・ストアおよびトランザクション・ログ・データ用のコンシステンシー・グループ |
アプリケーション |
|
|
Oracle Business Intelligenceの共有ファイルとディレクトリ、およびOracle Business Intelligence Publisher構成用のコンシステンシー・グループ |
アプリケーション |
|
|
Middlewareホーム用のコンシステンシー・グループ |
アプリケーション |
|
|
Oracle Business IntelligenceのOracleインスタンス用のコンシステンシー・グループ |
Web |
|
|
Oracle HTTP ServerのOracleホーム用のコンシステンシー・グループ |
Web |
|
|
Oracle HTTP ServerのOracleインスタンス用のコンシステンシー・グループ |
脚注1 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注2 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注3 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
脚注4 静的HTMLデータ用のこのボリュームはオプションです。Oracle Fusion Middlewareは通常、これなしで動作します。
Oracle Fusion Middleware障害時リカバリ・トポロジで使用するストレージ・レプリケーションを設定するには、次の手順を実行します。
スタンバイ・サイトで、本番サイトのピア・ホストに使用されている物理ホスト名と同じホスト名別名が作成されていることを確認します。
スタンバイ・サイトの共有ストレージに、本番サイトの共有ストレージで作成したものと同じボリュームを作成します。
スタンバイ・サイトで、本番サイトで作成したものと同じマウント・ポイントおよびシンボリック・リンクを作成します(スタンバイ・サイトでシンボリック・リンクを設定する必要があるのは、本番サイトでシンボリック・リンクを設定した場合のみです)。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項を参照してください。
本番サイトにインストールしたものと同じOracle Fusion Middlewareインスタンスをスタンバイ・サイトにインストールする必要はありません。本番サイトのストレージがスタンバイ・サイトのストレージにレプリケートされる際に、本番サイトのボリュームにインストールされているOracleソフトウェアがスタンバイ・サイトのボリュームにレプリケートされます。
共有ストレージ・ベンダーが規定しているその他の必要な構成を実行して、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージ間のストレージ・レプリケーションを有効にします。
本番サイトの共有ストレージのベースライン・スナップショット・コピーを作成します。これによって、本番サイトとスタンバイ・サイトの共有ストレージ間のレプリケーションが設定されます。初期のベースライン・コピーおよび以降のスナップショット・コピーを作成する際には、非同期レプリケーション・モードを使用してください。ベースライン・スナップショット・コピーを実行した後、スタンバイ・サイトのボリューム内のすべてのディレクトリの内容が本番サイトのボリューム内のディレクトリと同じであることを検証します。
スタンバイ・サイトにレプリケートされる、本番サイトの共有ストレージの以降のコピーの頻度を設定します。非同期レプリケーション・モードを使用している場合、要求した頻度で、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づきます)が新しいスナップショット・コピーとなり、そのスナップショット・コピーがスタンバイ・サイトの共有ストレージに転送されます。
Oracle Fusion Middleware障害時リカバリの本番サイトに含まれているデータベースの障害保護機能がOracle Data Guardによって提供されていることを確認します。Oracle Databaseの障害保護にストレージ・レプリケーション・テクノロジは使用しないでください。
スタンバイ・サイトの共有ストレージは、本番サイトの共有ストレージから定期的に転送されるスナップショットを受け取ります。スナップショットが適用されると、フェイルオーバーまたはスイッチオーバーの前に本番サイトから最後に転送されたスナップショットに含まれていたデータまでのすべてのデータがスタンバイ・サイトの共有ストレージに復元されます。
本番サイトの中間層に対して変更が加えられた場合(本番サイトで新しいアプリケーションがデプロイされた場合など)は必ず、同期操作を手動で強制的に実行することを強くお薦めします。ストレージ・レプリケーション・テクノロジを使用して同期を強制的に実行するには、ベンダー固有の手順に従ってください。
Oracle Fusion Middleware障害時リカバリ・トポロジで使用するOracle Databaseの設定に関する推奨事項および考慮事項の詳細は、第3.3項を参照してください。
Oracle Data Guardは、プライマリ・サイトとスタンバイ・サイトのOracle Fusion Middlewareリポジトリ・データベース間に設定する必要があります。スタンバイ・サイトのデータベースは、フィジカル・スタンバイ・データベースとして設定する必要があります。この項では、スタンバイ・サイトのデータ層の設定と構成について説明します。
Oracle Data Guardの詳細は、Oracle Databaseのドキュメント・セットの『Oracle Data Guard概要および管理』を参照してください。
後述のOracle Data Guardの設定および構成手順は、次の条件を満たしていることを前提としています。
スタンバイ・サイトのOracle RACクラスタおよび自動ストレージ管理(ASM)インスタンスが作成済です。
スタンバイ・サイトおよび本番サイトのOracle RACデータベースでフラッシュ・リカバリ領域を使用しています。
スタンバイ・サイトのデータベース・ホストにOracleソフトウェアがすでにインストールされています。
スタンバイ・サイトのデータベース・ホームの物理パスが本番サイトのものと一致しています。
Oracle Data Guardの手順では、表4-17に記載されている環境変数を本番サイトのSOAデータベースに使用します。
表4-17 本番サイトのSOAデータベースに使用する環境変数
変数 | 値 |
---|---|
SOAデータベースのホスト名 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Oracle Data Guardの手順では、表4-18に記載されている環境変数をスタンバイ・サイトのSOAデータベースに使用します。
表4-18 スタンバイ・サイトのSOAデータベースに使用する環境変数
変数 | 値 |
---|---|
SOAデータベースのホスト名 |
|
|
|
|
|
|
|
|
|
|
|
|
|
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=password
スタンバイ・サイトのSOADBHOST2
の場合
$ cd $ORACLE_HOME
/dbs
$ orapwd file=orapwpsoa2 password=password
スタンバイ・サイトのSOADBHOST1
上のステージング領域から$ORACLE_HOME
/dbs
ディレクトリにpfileをコピーし、名前を変更します。例:
$ cp /u01/app/stage/psoa/initpsoa.ora $ORACLE_HOME
/dbs/initsoa1.ora
プライマリ・ノードからコピーしたスタンバイの初期化パラメータ・ファイルを、表4-19に記載されているパラメータを含むように変更します。
表4-19 スタンバイの初期化パラメータ・ファイルで指定するパラメータ
パラメータ | 値 |
---|---|
RACパラメータ |
|
Data Guardパラメータ |
|
その他のパラメータ |
|
スタンバイ・サイトの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/initsoa1.ora';
スタンバイ・サイトの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
スタンバイの初期化パラメータ・ファイルで参照されているすべてのスタンバイ・ホストでダンプ・ディレクトリを作成します。例:
$ 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 / auxiliary sys/oracle@ssoa 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 soa1 -n soadbhost1 $ srvctl add instance -d psoa -i soa2 -n soadbhost2
データベースと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
ステージング・ディレクトリ(/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'
プライマリ・サイトのSOADBHOST1
上のプライマリ・データベースに接続し(プライマリ・データベースはIDLE状態です)、プライマリDATAディスク・グループにSPFILEを作成します。例:
SQL> CREATE SPFILE='+DATA/PSOA/spfilepsoa.ora' FROM PFILE='/u01/app/stage/psoa/initpsoa.ora';
プライマリ・サイトの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
パラメータを変更したら、プライマリ・データベースを再開します。
スタンバイ・ロールをサポートするために、プライマリ・データベースでスタンバイ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#;
新しく作成したフィジカル・スタンバイ・データベースとプライマリOracle RACデータベース間でデータベースのスイッチオーバー操作およびスイッチバック操作が正しく機能することをテストする手順は、次のとおりです。
プライマリ・サイトのOracle RACデータベース(PSOA)の、1つを除くすべてのインスタンスを停止します。たとえば、本番サイトのSOADBHOST1
で次のコマンドを実行します。
$ srvctl stop instance -d psoa -i soa2
現在のプライマリ・データベースでフィジカル・スタンバイへのロール移行を開始します。たとえば、本番サイトの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
ツールを実行して、Oracle WebLogic Serverがインストールされているアプリケーション層ホストの証明書を作成します。構文は次のとおりです。
Syntax: java utils.CertGen key_passphrase cert_file_name key_file_name> [export|domestic] [hostname]
たとえば、次のコマンドを入力します。
java utils.CertGen password soahost1_cert soahost1_key domestic soahost1 java utils.CertGen password soahost2_cert soahost2_key domestic soahost2
次の手順に従って、utils.ImportPrivateKey
ユーティリティを使用してIDキーストアを作成します。
utils.ImportPrivateKey
ユーティリティを使用して、appIdentityKeyStore
というIDキーストアを新しく作成します。
このキーストアは、証明書と同じディレクトリに作成します。たとえば次のとおりです。
$MW_HOME
/user_projects/domains/j2eeDomain/certs
utils.ImportPrivateKey
ユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートするときに、アイデンティティ・ストアが存在しなければ新しく作成されます。
Oracle 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 password appIdentity1 password$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 password appIdentity2 password$MW_HOME
/user_projects/domains/SOADomain/certs/soahost2_cert.pem$MW_HOME
/user_projects/domains/SOADomain/certs/soahost2_key.pem
次の手順に従って、信頼キーストアを作成します。
keytool
ユーティリティを使用して、appTrustKeyStore
という信頼キーストアを新しく作成します。
新しい信頼キーストアを作成するには、標準のJavaキーストアを使用します。これは、必要なほとんどのルート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 OriginalPassword
たとえば、次のコマンドを入力します。
keytool -storepasswd -new password -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 KeyStorePassword
たとえば、次のコマンドを入力します。
keytool -import -v -noprompt -trustcacerts -alias clientCACert -file
$WL_HOME
/server/lib/CertGenCA.der -keystore appTrust.jks -storepass password
$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=password CustomIdentityAlias=appIdentity1 CustomIdentityPrivateKeyPassPhrase=password CustomTrustKeyStoreFileName=$MW_HOME
/user_projects/domains/SOADomain/certs /appTrust.jks CustomTrustKeyStorePassPhrase=password
たとえば、SOAHOST2のnodemanager.properties
ファイルで次のように編集します。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=$MW_HOME
/user_projects/domains/SOADomain/certs /appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=password CustomIdentityAlias=appIdentity2 CustomIdentityPrivateKeyPassPhrase=password CustomTrustKeyStoreFileName=$MW_HOME
/user_projects/domains/SOADomain/certs /appTrust.jks CustomTrustKeyStorePassPhrase=password
この項では、本番サイトを作成する手順を説明します。Oracle SOA Suiteのエンタープライズ・デプロイメント・トポロジと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 Portalエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。本番サイトのインストールおよび構成は、示された手順に従ってください。
第4.1.1.2.1項の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項を参照してください。
Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle WebCenter Portalをインストールおよび構成しますが、次の点が異なります。
共有ストレージ・デバイス上に作成したボリュームにOracle WebCenter Portalコンポーネントをインストールします。
WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。
本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドのOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーに対するホスト名検証の無効化に関する説明を参照してください。
ホスト名の検証をオフにしない場合は、第4.1.4項に記載されている手順に従って、ノード・マネージャの通信を構成します。
ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
本番サイトは、『Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド』の説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。示された順序で次の手順を実行し、本番サイトをインストールして構成します。
第4.1.1.5.1項の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項を参照してください。
Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle Enterprise Content Managementをインストールおよび構成しますが、次の点が異なります。
共有ストレージ・デバイス上に作成したボリュームにOracle Enterprise Content Managementコンポーネントをインストールします。
WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。
本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーのホスト名の検証をオフにする手順の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド』の管理サーバーに対するホスト名検証の無効化に関する項を参照してください。
ホスト名の検証をオフにしない場合は、第4.1.4項に記載されている手順に従って、ノード・マネージャの通信を構成します。
ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
本番サイトは、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要がありますが、次のような違いがあります。示された順序で次の手順を実行し、本番サイトをインストールして構成します。
第4.1.1.6.1項の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項を参照してください。
Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドの説明に従って、Oracle Business Intelligenceをインストールおよび構成しますが、次の点が異なります。
共有ストレージ・デバイス上に作成したボリュームにOracle WebCenter Contentコンポーネントをインストールします。
WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。
本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイドのbi_server1管理対象サーバーに対するホスト名検証の無効化に関する説明およびbi_server2管理対象サーバーに対するホスト名検証の無効化に関する説明を参照してください。
ホスト名の検証をオフにしない場合は、第4.1.4項に記載されている手順に従って、ノード・マネージャの通信を構成します。
ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
本番サイトは、次の製品のエンタープライズ・デプロイメント・ガイドの説明に従ってインストールおよび構成する必要があります。
Oracle Portal
図4-9に示されている、Oracle Portalエンタープライズ・トポロジを使用する本番サイトを設定および構成する手順の詳細は、11.1.1.2 Oracle Portalエンタープライズ・デプロイメント・ガイドに記載されています。マニュアルの取得の詳細は、My Oracle Supportで記事ID 952068.1「Oracle Fusion Middleware 11g (11.1.1.2) Enterprise Deployment Guides for Portal, Forms, Reports, and 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) Enterprise Deployment Guides for Portal, Forms, Reports, and Discover」を参照してください。My Oracle SupportのURLは次のとおりです。
前述のマニュアルの説明に従ってインストールおよび構成を行う必要がありますが、次のような違いがあります。示された手順に従ってください。
第4.1.1.4.1項の説明に従って、共有ストレージ・デバイスにボリュームとコンシステンシー・グループを作成します。
本番サイトの物理ホスト名、およびスタンバイ・サイトの物理ホスト名とホスト名別名を設定します。本番サイトおよびスタンバイ・サイトのホスト名を計画する方法の詳細は、第3.1.1項を参照してください。
前述のリンク先のホワイト・ペーパーの説明に従って、Oracle Portal、Forms、ReportsおよびDiscovererをインストールおよび構成します。ただし、次の点が異なります。
共有ストレージ・デバイス上に作成したボリュームにOracle Portal、Forms、ReportsおよびDiscovererコンポーネントをインストールします。
WebLogicドメインをインストールおよび構成する際、物理ホスト名を使用します。
本番サイトのインストールおよび構成後、ホスト名の検証をオフにします。管理サーバーと管理対象サーバーのホスト名の検証をオフにする手順の詳細は、Oracle Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイドのOracle WebLogic管理サーバーとWLS_WSM1管理対象サーバーに対するホスト名検証の無効化に関する説明を参照してください。
ホスト名の検証をオフにしない場合は、第4.1.4項に記載されている手順に従って、ノード・マネージャの通信を構成します。
ノード・マネージャの通信が正しく機能するように、すべてのOracle Fusion Middlewareホストでホスト名別名を使用してSSL証明書を作成します。
Oracle SOA Suiteエンタープライズ・トポロジの本番サイトの設定を検証するには、『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の次の項に記載されている検証手順を実行します。
「Oracle HTTP Serverのインストール」の次の項に記載されている検証手順
HTTPリクエストをルーティングするためのロード・バランサの構成
「ドメインの作成」の次の項に記載されている検証手順
管理サーバーの検証に関する項
WLS_WSM1管理対象サーバーの起動と検証に関する項
WLS_WSM2管理対象サーバーの起動と検証に関する項
Oracle HTTP Serverを介したアクセスの検証に関する項
Oracle HTTP Serverを介したSOAHOST2へのアクセスの検証に関する項
「SOAコンポーネントを使用するためのドメインの拡張」の次の項に記載されている検証手順
WLS_SOA1管理対象サーバーの起動と検証に関する項
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項を参照してください。
また、スタンバイ・サイトでメタデータ・リポジトリを実行するデータベースが管理リカバリ・モードであることを確認してください。管理リカバリ・モードでスタンバイ・データベースを有効にするには、次のSQLコマンドを実行します。
SQL> ALTER DATABASE RECOVERY MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
DISCONNECT
オプションは、コマンドが正常に完了した後にSQLセッションを終了します。
Oracle Data Guard Brokerを設定するには、次の手順を完了します。
ステップ1: Oracle Data Guard Brokerの構成ファイルの設定
Oracle Data Guard Brokerの構成ファイルの設定の詳細は、Oracle Data Guard BrokerガイドのBrokerの構成ファイルの設定に関する項を参照してください。
ステップ2: Oracle Data Guard Brokerの構成の作成
Oracle Data Guard Brokerの構成の作成の詳細は、Oracle Data Guard Brokerガイドのシナリオ1: 構成の作成に関する項を参照してください。
ステップ3: Oracle Data Guard Brokerの構成の有効化
次を行って、Oracle Data Guard Brokerの構成を有効にします。
プライマリ・データベースとスタンバイ・データベース用のData Guard環境が正常に設定されていることを確認します。
enable configuration
コマンドを実行することで、Oracle Data Brokerの構成を開始します。
show configuration
コマンドを実行することで、構成を確認します。次のイメージで示されているように、結果が表示されます。
詳細は、Oracle Data Guard BrokerガイドのBrokerの構成の有効化に関する項を参照してください。
ステップ4: Oracle Data Guard Brokerの構成のテスト
Oracle Data Guard Brokerを使用してプライマリ・データベースとスタンバイ・データベースの間でロールを切り替えることで、Oracle Data Guard Brokerの構成をテストします。次の手順を実行します。
switchover
コマンドを実行します。次のイメージで示されているように、結果が表示されます。
show configuration
コマンドを実行することで、スイッチオーバーが正常に完了したことを確認します。次のイメージで示されているように、結果が表示されます。
この時点で、各データベースに接続して、ロール・スイッチオーバーを確認するためのいくつかの問合せを発行することもできます。
switchover
コマンドを再度実行することで、Oracle Data Guard環境を元のデータベース・ロールに戻します。次のイメージで示されているように、結果が表示されます。
show configuration
コマンドを実行することで、2番目のスイッチオーバーが完了したことを確認します。次のイメージで示されているように、結果が表示されます。
Data Guard Brokerの構成のテストの詳細は、Oracle Data Guard Brokerガイドの構成ステータスに関する項を参照してください。
スタンバイ・サイトの中間層ホストでは、Oracle Fusion MiddlewareやOracle 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 Fusion Middlewareインスタンスに対して、Oracle中央インベントリ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項を参照してください。Oracle中央インベントリ・ディレクトリの詳細は、第3.2.2項を参照してください。
本番サイトの共有ストレージ・システムのボリュームにインストールされるOracle HTTP Serverインスタンスに対して、静的HTMLページ・ディレクトリへのマウント・ポイントとシンボリック・リンクを本番サイトのホスト上に作成します(該当する場合)。シンボリック・リンクは、ストレージ・システムによって複数のボリューム間で一貫性のあるレプリケーションが保証されない場合にのみ必要です。シンボリック・リンクの詳細は、第3.2.3項を参照してください。
本番サイトの共有ストレージ・システムのボリュームに、本番サイト用のOracle Fusion Middlewareインスタンスをインストールします。詳細は、第4.2.1項を参照してください。
スタンバイ・サイトの共有ストレージ・システムでも、本番サイトの共有ストレージ・システムで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-15に、図4-2に示されている本番サイトの非対称スタンバイ・サイトを示します。
図4-15に示されているOracle SOA Suiteの非対称スタンバイ・サイトのホストおよびインスタンスの数は、図4-2に示されているOracle SOA Suiteの本番サイトより少なくなっています。
図4-2の本番サイトには、ホストWEBHOST2およびSOAHOST2とこれらのホスト上のインスタンスが存在しますが、図4-15の非対称スタンバイ・サイトには、これらのホストとそのインスタンスが存在しません。そのため、スタンバイ・サイトのホストおよびインスタンスの数は、本番サイトより少なくなっています。
この非対称スタンバイ・サイトには、本番ロールを引き継いだときに適切なパフォーマンスを提供できるように、十分なリソースを確保することが重要です。
第4.4.1項に記載されている手順に従って、この非対称スタンバイ・サイトを設定すれば、スタンバイ・サイトは本番ロールを引き継ぐように適切に構成されます。
非対称スタンバイ・サイトを正しく設定するには、本番サイトの共有ストレージで作成したものと同じボリュームおよびコンシステンシー・グループをスタンバイ・サイトの共有ストレージで作成します。たとえば、Oracle SOA Suiteデプロイメントについて、表4-2のボリューム設計に関する推奨事項と表4-3のコンシステンシー・グループに関する推奨事項を使用して、本番サイトの共有ストレージを設定したとします。その場合、本番サイトの共有ストレージに使用したものと同じボリューム設計に関する推奨事項とコンシステンシー・グループに関する推奨事項を使用して、非対称スタンバイ・サイトの共有ストレージを設定します。
非対称スタンバイ・サイトでは、本番サイトに存在する一部のホストがスタンバイ・サイトに存在しません。たとえば、図4-15に示されている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 Databaseのデータベース・データをスタンバイ・サイトのスタンバイ・データベースにコピーします。デフォルトでは、本番サイトのデータベースはアクティブで、スタンバイ・サイトのスタンバイ・データベースはパッシブです。スタンバイ・サイトがスタンバイ・ロールの間(パッシブである間)、スタンバイ・サイトのスタンバイ・データベースは管理リカバリ・モードです。本番サイトがアクティブな場合、スタンバイ・データベースに対して行われる書込み操作は、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;
Oracle Database 11gについては、『Oracle Data Guard概要および管理』のスナップショット・スタンバイ・データベースの管理に関する項に記載されている手順に従って、スナップショット・スタンバイ・データベースを確立します。
Oracle Data Guardのデータベース・リカバリ手順に従って、スタンバイ・データベースをオンラインにします。
スタンバイ・サイトのコンピュータで、次の手順に従って、スタンバイ・サイトのクローニングされた読取り/書込み共有ストレージ・ボリュームを指すようにmountコマンドを変更します。
読取り専用の共有ストレージ・ボリュームをアンマウントします。
クローニングされた読取り/書込みボリュームを同じマウント・ポイントでマウントします。
スタンバイ・サイトをテストする前に、ホスト名が本番サイトのコンピュータではなくスタンバイ・サイトのコンピュータを指すように、テストの実行に使用するコンピュータのホスト名解決方法を変更します。たとえば、Linuxコンピュータの場合、スタンバイ・サイトのロード・バランサの仮想IPを指すように/etc/hosts
ファイルを変更します。
スタンバイ・サイトのテストを実行します。
スタンバイ・サイトのテストが完了したら、次の手順に従って、元の本番サイトを本番サイトとして再度使用します。
スタンバイ・サイトのコンピュータで、スタンバイ・サイトの読取り専用共有ストレージ・ボリュームを指すようにmountコマンドを変更します。つまり、mountコマンドを、テストを実行する前の状態に戻します。
クローニングされた共有ストレージの読取り/書込みボリュームをアンマウントします。
読取り専用の共有ストレージ・ボリュームをマウントします。
これで、mountコマンドがスタンバイ・サイトのテストを実行する前の状態にリセットされました。
本番サイトのデータベースとスタンバイ・サイトのスタンバイ・データベース間のレプリケーションを実行するように、Oracle Data Guardを構成します。この構成を実行すると、スタンバイ・データベースは再度、管理リカバリ・モードに設定されます。
Oracle Database 10.1については、Oracle Data Guard 10.1のドキュメントに記載されている手順に従って、データベースを再インスタンス化します。
Oracle Database 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;
Oracle Database 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 Databaseの障害保護には、Oracle Data Guardを使用します。Oracle Databaseの障害時リカバリを実現するように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 Databaseを手動で強制的に同期させる方法の詳細は、第3.3.2項を参照してください。
rsyncを使用している場合、本番サイトからスタンバイ・サイトへのフェイルオーバーまたはスイッチオーバーを実行する手順は次のとおりです。
本番サイトで実行中のプロセスを停止します(該当する場合)。
本番サイトのホストとスタンバイ・サイトのピア・ホスト間のrsyncジョブを停止します。
Oracle Data Guardを使用して、本番サイトのデータベースをスタンバイ・サイトにフェイルオーバーします。
スタンバイ・サイトで、Oracle Fusion Middlewareサーバー・インスタンスのプロセスを手動で開始します。
グローバルDNSプッシュ、またはそれに類似する機能(グローバル・ロード・バランサの更新など)を実行して、すべてのユーザー・リクエストをスタンバイ・サイトにルーティングします。
ブラウザ・クライアントを使用してフェイルオーバー後またはスイッチオーバー後のテストを実行し、スタンバイ・サイト(現在の本番サイト)でリクエストが解決されていることを確認します。
これで、スタンバイ・サイトが新しい本番サイトになり、本番サイトが新しいスタンバイ・サイトになりました。
2つのサイト間のrsyncレプリケーションを再確立します。ただし、逆方向に(現在の本番サイトから現在のスタンバイ・サイトへ)レプリケートされるようにレプリケーションを構成してください。
元の本番サイトを新しい本番サイトとして使用するには、前述の手順をもう一度実行します。ただし、元の方向で(元の本番サイトから元のスタンバイ・サイトへ)レプリケートされるようにrsyncレプリケーションを構成してください。
Oracle Site Guardは、主に、2つの障害回復サイト間のスイッチオーバーおよびフェイルオーバーを編成します。これには、次の機能があります。
企業データの高可用性、データ保護および障害時リカバリを保証します。
スイッチオーバーやフェイルオーバーなどのOracle Site Guard操作を実行します。プライマリ・サイトが計画停止または計画外停止のため使用不可となった場合、スイッチオーバーまたはフェイルオーバー・プロセスはOracle Site Guardを使用して開始する必要があります。
Oracle Site Guardの使用方法の詳細は、Oracle Enterprise Managerライフサイクル管理者ガイドのOracle Site Guardの使用に関する項を参照してください。
この項では、11g Oracle Fusion Middlewareパッチ・セットを適用して、Oracle Fusion Middleware障害時リカバリ・サイトに含まれるOracleホームをアップグレードする方法を説明します。
この項の一覧では、Oracle Fusion Middleware障害時リカバリの本番サイトでパッチ・セットを適用して、Oracle Fusion Middleware 11gホームをアップグレードする手順について説明します。
次の手順は、パッチを適用するOracle Fusion MiddlewareインスタンスのOracle中央インベントリが本番サイトの共有ストレージに配置されていて、パッチが適用されたインスタンスのOracle中央インベントリをスタンバイ・サイトにレプリケートできるようになっていることを前提としています。
Oracle Fusion Middleware 11gのパッチ・バージョンをアップグレードする手順は、次のとおりです。
開始時の状態が保持されるように、本番サイトのバックアップを実行します。
パッチ・セットを適用して、本番サイトのインスタンスをアップグレードします。
パッチ・セットを適用したら、本番サイトの共有ストレージとスタンバイ・サイトの共有ストレージを手動で強制的に同期させます。これによって、本番サイトのパッチが適用されたインスタンスとOracle中央インベントリがスタンバイ・サイトの共有ストレージにレプリケートされます。
パッチ・セットを適用したら、Oracle Data Guardを使用して、本番サイトとスタンバイ・サイトのOracle Databaseを手動で強制的に同期させます。Oracle Fusion Middlewareの一部のパッチ・セットでは、リポジトリが更新される場合があるため、この手順を必ず実行して、本番サイトのデータベースの変更をスタンバイ・サイトのデータベースに同期させます。
これでアップグレードは完了です。障害時リカバリ・トポロジで処理を再開できます。
注意: パッチは、Oracle Fusion Middleware 11g障害時リカバリ・トポロジの本番サイトでのみ適用する必要があります。Oracle Fusion MiddlewareインスタンスまたはOracle中央インベントリのパッチの場合、本番サイトの共有ストレージがスタンバイ・サイトの共有ストレージにレプリケートされるときに、パッチがコピーされます。本番サイトでパッチをインストールした場合は、同期操作を実行する必要があります。 同様に、本番サイトのデータベースのパッチをインストールした場合、同期を実行すると、Oracle Data Guardによってスタンバイ・サイトのスタンバイ・データベースにパッチがコピーされます。 |