4
中間層の高可用性の管理と操作

この章では、Oracle Application Server中間層の構成変更および継続的なメンテナンスを行う方法について説明します。

この章の項目は次のとおりです。

• 第4.1項「中間層の高可用性構成の概要」

• 第4.2項「DCM-Managed OracleAS Clusterの使用」

• 第4.3項「DCM構成リポジトリの可用性に関する考慮事項」

• 第4.4項「Oracle Application Server Cluster（OC4J）の使用」

• 第4.5項「OracleAS Cold Failover Cluster（中間層）の管理」

• 第4.6項「Oracle Application Server中間層のアップグレードの管理」

• 第4.7項「OracleAS Cluster（中間層）でのOracleAS Single Sign-Onの使用」

4.1 中間層の高可用性構成の概要

Oracle Application Serverでは、Oracle Application Server中間層における高可用性をサポートするために、様々な構成オプションが用意されています。

この項の項目は次のとおりです。

• 第4.1.1項「DCM-Managed OracleAS Cluster」

4.1.1 DCM-Managed OracleAS Cluster

DCM-Managed OracleAS Clusterを管理する場合、Application Server Controlコンソールまたはdcmctlコマンドのいずれかを使用して、1つのOracle Application Serverインスタンスの共通の構成情報を管理および構成します。その後、DCMがDCM-Managed OracleAS Cluster内のすべてのOracle Application Serverインスタンスに共通する構成情報を伝播およびレプリケートします。そのクラスタで共通の構成情報はクラスタレベルの構成といいます。

注意 クラスタ内にあるOracle Application Serverインスタンスごとに、個別に構成可能な構成情報もあります（このような構成オプションは、インスタンス固有のパラメータともいいます）。

DCM-Managed OracleAS Cluster内の各Oracle Application Serverインスタンスの基本構成は同じです。基本構成には、クラスタレベルの構成は含まれていますが、インスタンス固有のパラメータは含まれていません。

関連項目 第3.2.1項「DCMを使用して管理されるOracleAS Cluster」 第4.2.7項「DCM-Managed OracleAS Clusterのメンバーシップについて」

4.2 DCM-Managed OracleAS Clusterの使用

この項では、DCM-Managed OracleAS Clusterを作成および使用する方法について説明します。この項の項目は次のとおりです。

• 第4.2.1項「DCM-Managed OracleAS Clusterの作成」

• 第4.2.2項「DCM-Managed OracleAS Clusterへのインスタンスの追加」

• 第4.2.3項「DCM-Managed OracleAS Clusterからのインスタンスの削除」

• 第4.2.4項「DCM-Managed OracleAS Clusterの起動、停止および削除」

• 第4.2.5項「ステートフルなJ2EEアプリケーションのローリング・アップグレード」

• 第4.2.6項「DCM-Managed OracleAS Clusterに対するOracle HTTP Serverのオプションの構成」

• 第4.2.7項「DCM-Managed OracleAS Clusterのメンバーシップについて」

  関連項目 dcmctlコマンドについては、『Distributed Configuration Management管理者ガイド』を参照してください。

4.2.1 DCM-Managed OracleAS Clusterの作成

OracleAS Farmとは、Oracle Application Serverインスタンスの集合です。OracleAS Farmの中では、Application Server Controlコンソールを起動すると、全アプリケーション・サーバー・インスタンスのリストが表示されます。Application Server Controlコンソールのファーム・ホーム・ページの「スタンドアロン・インスタンス」領域に表示されるアプリケーション・サーバー・インスタンスは、DCM-Managed OracleAS Clusterに追加できます。

各Oracle Application Server Farmでは、ファイルベース・リポジトリまたはデータベースベース・リポジトリのいずれかが使用されます。アプリケーション・サーバー・インスタンスをOracleAS Farmに関連付ける手順は、リポジトリのタイプによって異なります。

この項の項目は次のとおりです。

• 第4.2.1.1項「インスタンスとOracleAS Database-based Farmの関連付け」

• 第4.2.1.2項「インスタンスとOracleAS File-based Farmの関連付け」

• 第4.2.1.3項「Application Server Controlコンソールの「クラスタの作成」ページの使用」

  注意 この項で取り上げるのは、OracleAS Farmの一部である、クラスタリング可能な中間層インスタンスに関する手順です。この項の説明では、クラスタリング可能なインスタンスとは、dcmctl isclusterableコマンドを実行したときに値TRUEが返される中間層インスタンスを指します。

4.2.1.1 インスタンスとOracleAS Database-based Farmの関連付け

Oracle Application Serverのインストール時に関連付けを行っていない場合は、ここで説明する手順に従って、アプリケーション・サーバー・インスタンスをOracleAS Database-based Farmに関連付けることができます。

OracleAS Database-based Farmの場合は、次の手順に従ってOracle Application ServerインスタンスをOracleAS Farmに追加します。

1. Application Server Controlコンソールのインスタンス・ホーム・ページにナビゲートします。

2. 「ホーム」領域で、「インフラストラクチャ」リンクを選択し、指示に従ってアプリケーション・サーバー・インスタンスをOracle Application Server Infrastructureに関連付けます。

   関連項目 『Oracle Application Server管理者ガイド』

4.2.1.2 インスタンスとOracleAS File-based Farmの関連付け

この項の項目は次のとおりです。

• 第4.2.1.2.1項「OracleAS File-based Farmリポジトリ・ホストの作成」

• 第4.2.1.2.2項「OracleAS File-based Farmへのインスタンスの追加」

4.2.1.2.1 OracleAS File-based Farmリポジトリ・ホストの作成

Oracle Application Serverインストーラを実行してOracle Application Serverをインストールするときに、OracleAS File-based Farmを作成することができます。インストール時にOracleAS File-based Farmを作成しなかった場合は、次の手順でOracleAS File-based Farmを作成します。

1. リポジトリ・ホストとして使用するインスタンスのApplication Server Controlコンソールを使用し、「インフラストラクチャ」リンクを選択して「インフラストラクチャ」ページにナビゲートします。リポジトリが構成されていない場合は、「ファーム・リポジトリ」フィールドに「未構成」が表示されます（図4-1を参照）。

   図4-1    Application Server Controlコンソールでのファーム・リポジトリの管理

   
   

   画像の説明

2. 「インフラストラクチャ」ページの「OracleASファーム・リポジトリ管理」領域の「構成」ボタンを選択すると、OracleASファーム・リポジトリの構成ウィザードが開始します。「OracleASファーム・リポジトリの構成: ソース」の下に、ホスト名が表示されます。

3. 図4-2に示すように、「新しいファイルベース・リポジトリ」オプションを選択して「次へ」を選択します。

   図4-2    Application Server Controlコンソール: リポジトリの構成ウィザード - ステップ1

   
   

   画像の説明

4. ウィザードはステップ4/4の「検証」に進みます（図4-3を参照）。

   図4-3    Application Server Controlコンソール: リポジトリの構成ウィザード - ステップ4

   
   

   画像の説明

5. 「終了」を選択すると、OracleAS File-based Farmが作成されます。

6. ウィザードの処理が完了したら、「インフラストラクチャ」ページの「OracleASファーム・リポジトリ管理」領域に表示されるリポジトリIDを確認してください。リポジトリIDは、OracleAS File-based Farmにインスタンスを追加するときに必要になります。

Application Server Controlコンソールのホーム・ページを開くと、OC4JインスタンスとOracle HTTP Serverが停止していることが表示され、ホーム・ページの「一般」領域には「ファーム」リンクが表示されています。

4.2.1.2.2 OracleAS File-based Farmへのインスタンスの追加

スタンドアロンのアプリケーション・サーバー・インスタンスをOracleAS File-based Farmに追加するには、次の手順を実行します。

1. 追加先のOracleAS File-based FarmのリポジトリIDを確認します。リポジトリIDを確認するには、OracleAS File-based Farmを使用するOracle Application Serverインスタンスのいずれかで「インフラストラクチャ」リンクをクリックし、「OracleASファーム・リポジトリ管理」領域の「ファイルベース・リポジトリのID」フィールドの値を調べます。

2. OracleAS File-based Farmに追加するスタンドアロン・インスタンスのApplication Server Controlコンソールに切り換えて、「インフラストラクチャ」リンクをクリックします。リポジトリが構成されていない場合は、「ファーム・リポジトリ」フィールドに「未構成」が表示されます（図4-1を参照）。

3. 「構成」をクリックすると、OracleASファーム・リポジトリの構成ウィザードが開始します。リポジトリ作成ウィザードが表示されます（図4-2を参照）。「OracleASファーム・リポジトリの構成: ソース」領域の下の「OracleASインスタンス」フィールドに、ホスト名が表示されます。

4. 「既存のファイルベース・リポジトリ」ボタンを選択して「次へ」をクリックします。リポジトリ作成ウィザードのステップ3/4の「ロケーション」ページが表示されます（図4-4を参照）。

   図4-4    Application Server Controlコンソールでのファームへのインスタンスの追加

   
   

   画像の説明

5. リポジトリ・ホストのリポジトリIDを入力して、「次へ」をクリックします。

6. ステップ4/4の「OracleAS Farmリポジトリの構成: 検証」ページで、「終了」をクリックします。ウィザードが完了すると、スタンドアロンのインスタンスがOracleAS File-based Farmに追加されます。

   ウィザードが完了すると、Application Server Controlコンソールの「インフラストラクチャ」ページが再び表示されます。

4.2.1.3 Application Server Controlコンソールの「クラスタの作成」ページの使用

Application Server Controlコンソールのファーム・ホーム・ページを使用して、新しいDCM-Managed OracleAS Clusterを作成できます。

ファーム・ホーム・ページから、次の手順を実行して、新規のDCM-Managed OracleAS Clusterを作成します。

1. 「ファーム」リンクをクリックしてファーム・ホーム・ページにナビゲートします。

   注意 Application Server Controlコンソールにファーム・ホーム・ページが表示されるのは、Oracle Application Serverインスタンスがファームの一部である場合です。

2. 「クラスタの作成」をクリックして「クラスタの作成」ページを表示します（図4-5を参照）。

   図4-5    「クラスタの作成」ページ

   
   

   画像の説明

3. 新規クラスタの名前を入力して「作成」をクリックします。ファーム内のクラスタ名は、一意である必要があります。

   確認のページが表示されます。

4. 「OK」をクリックして、ファーム・ホーム・ページに戻ります。

   ファーム・ホーム・ページの「クラスタ」領域にクラスタが表示されます。新規のクラスタは空であり、Oracle Application Serverのインスタンスを含んでいません。ファーム・ホーム・ページの「クラスタへの結合」ボタンを使用して、インスタンスをクラスタに追加します。

   関連項目 第4.2.2項「DCM-Managed OracleAS Clusterへのインスタンスの追加」

4.2.2 DCM-Managed OracleAS Clusterへのインスタンスの追加

DCM-Managed OracleAS ClusterにOracle Application Serverインスタンスを追加するには、次の手順を実行します。

1. ファーム・ホーム・ページにナビゲートします。Oracle Application Serverインスタンスのホーム・ページからファーム・ホーム・ページにナビゲートするには、ホーム・ページの「一般」領域の「ファーム」フィールドの横にあるリンクをクリックします。

   注意 「ファーム」フィールドが表示されない場合は、そのインスタンスはファームの一部ではありません。スタンドアロン・インスタンスをファームに関連付ける必要があります。

2. 「スタンドアロン・インスタンス」セクションで、クラスタに追加するOracle Application Serverインスタンスのラジオ・ボタンを選択します。

3. 「クラスタへの結合」をクリックします。

   図4-6に、「クラスタへの結合」ページを示します。

   図4-6    「クラスタへの結合」ページ

   
   

   画像の説明

4. Oracle Application Serverインスタンスの結合先クラスタのラジオ・ボタンを選択します。

5. 「結合」をクリックします。選択したクラスタにインスタンスが追加され、確認のページが表示されます。

6. 「OK」をクリックして、ファーム・ホーム・ページに戻ります。

クラスタに追加する他のスタンドアロンのインスタンスについても、それぞれこの手順を繰り返します。

DCM-Managed OracleAS ClusterにOracle Application Serverインスタンスを追加するときは、次の点に注意してください。

• Oracle Application ServerインスタンスをDCM-Managed OracleAS Clusterに追加する順番は重要です。DCM-Managed OracleAS Clusterに最初に結合されるインスタンスは、それより後に結合されるすべてのインスタンスの基本構成として使用されます。基本構成には、クラスタレベルの構成情報がすべて含まれます。インスタンス固有のパラメータは含まれません。

• Oracle Application ServerインスタンスをDCM-Managed OracleAS Clusterに結合すると、既存のクラスタレベルの構成情報がこの基本構成で上書きされ、それ以降クラスタに結合されるOracle Application Serverインスタンスに使用されます。最初のOracle Application Serverインスタンスの後にクラスタに結合されたOracle Application Serverインスタンスはそれぞれ、クラスタに最初に結合されたOracle Application Serverインスタンスに指定されている基本構成を継承します。

• Oracle Application ServerインスタンスをDCM-Managed OracleAS Clusterに追加する前に、Application Server Controlコンソールによりそのインスタンスは停止されます。Oracle Application Serverインスタンスを再起動するには、クラスタ・リンクを選択し、そのクラスタ内で該当するインスタンスを選択して、「起動」ボタンをクリックします。

• DCM-Managed OracleAS Clusterに結合されたOracle Application Serverインスタンスは、「スタンドアロン・インスタンス」領域から削除されます。

• 1回の操作で、1つのDCM-Managed OracleAS ClusterにスタンドアロンのOracle Application Serverインスタンスを複数追加するには、dcmctl joinClusterコマンドを使用します。

• 特定のOracle Application Serverコンポーネントを含むOracle Application Serverインスタンスはクラスタリングできません。インスタンスがクラスタリング可能かどうかをテストするには、dcmctl isClusterableコマンドを使用します。クラスタリングできないインスタンスをDCM-Managed OracleAS Clusterに追加しようとすると、Application Server Controlコンソールからエラーが返されます。

• DCM-Managed OracleAS ClusterのメンバーとなるすべてのOracle Application Serverインスタンスを、同じ種類のオペレーティング・システム上にインストールする必要があります。たとえば、異なるシステムでもUNIX系である場合などはクラスタリング可能ですが、UNIXシステムとWindowsシステムの組合せではクラスタリングはできません。

  注意 インスタンスをOracleAS File-based Farmに追加する場合に、インスタンスはDCM-Managed OracleAS Clusterに追加されますが、インスタンス数の物理的な上限は判明していません。ただし、12個のインスタンスからなるDCM-Managed OracleAS Clusterのテストは成功しています。

4.2.3 DCM-Managed OracleAS Clusterからのインスタンスの削除

クラスタからOracle Application Serverインスタンスを削除するには、次の手順を実行します。

1. ファーム・ホーム・ページで目的のクラスタを選択します。クラスタ・ページが表示されます。

2. クラスタから削除するOracle Application Serverインスタンスのラジオ・ボタンを選択し、「削除」をクリックします。

削除するOracle Application Serverインスタンスごとに、この手順を繰り返します。

DCM-Managed OracleAS ClusterからOracle Application Serverインスタンスを削除するときは、次の点に注意してください。

• Application Server Controlコンソールでは、Oracle Application Serverインスタンスをクラスタから削除する前に、インスタンスが停止されます。操作が完了したら、ファーム・ホーム・ページの「スタンドアロン・インスタンス」領域からOracle Application Serverインスタンスを再起動します。

• dcmctl leaveClusterコマンドを起動するたびに、Oracle Application Serverインスタンスが1つずつクラスタから削除されます。

• 最後のOracle Application Serverインスタンスをクラスタから削除すると、クラスタに関連付けられているクラスタレベルの構成情報も削除されます。クラスタは空になり、基本構成は設定されていない状態になります。以降、Oracle Application Serverでは、クラスタに最初に結合されたOracle Application Serverインスタンスが、後からクラスタに結合されるすべてのOracle Application Serverインスタンスの基本構成として使用されます。

• Oracle Application Serverインスタンスは、クラスタからいつでも削除できます。クラスタに最初に結合されるインスタンスには、特別なプロパティはありません。基本構成はクラスタに最初に結合されるインスタンスから作成されますが、このインスタンスは、他のインスタンスと同様にクラスタから削除できます。

4.2.4 DCM-Managed OracleAS Clusterの起動、停止および削除

図4-7に、cluster1とcluster2の2つのクラスタが表示されたApplication Server Controlコンソールのファーム・ホーム・ページを示します。

図4-7    Oracle Application Server 10gの「ファーム」ページ

画像の説明

表4-1は、ファーム・ホーム・ページで使用可能なクラスタ制御オプションのリストです。

表4-1     Oracle Application Serverの「ファーム」ページのオプション 

目的	操作
DCM-Managed OracleAS Cluster内のすべてのOracle Application Serverインスタンスの起動	クラスタの横にあるラジオ・ボタンを選択し、「起動」をクリックします。
DCM-Managed OracleAS Cluster内のすべてのOracle Application Serverインスタンスの再起動	クラスタの横にあるラジオ・ボタンを選択し、「再起動」をクリックします。
DCM-Managed OracleAS Cluster内のすべてのOracle Application Serverインスタンスの停止	クラスタの横にあるラジオ・ボタンを選択し、「停止」をクリックします。
DCM-Managed OracleAS Clusterの削除 クラスタ内のOracle Application Serverインスタンスがクラスタから削除され、ファーム内のスタンドアロン・インスタンスとなります。	クラスタの横にあるラジオ・ボタンを選択し、「削除」をクリックします。

4.2.5 ステートフルなJ2EEアプリケーションのローリング・アップグレード

HttpSessionレプリケーション機能は、Oracle Application Serverユーザーの間では一般的となっています。OracleAS Cluster（OC4J）が、クラスタ内のインスタンスにHttpSession情報をレプリケートし、アプリケーション・ユーザーに透過的にノード間でリクエストをフェイルオーバーします。ただし、この高可用性機能は、アプリケーションの通常のライフサイクルの影響を受けます。アプリケーションを再デプロイするたびに、デプロイ処理によってクラスタ内のインスタンスでアプリケーション・クラスがリロードされ、HttpSessionが失われます。最新バージョンのアプリケーションに含まれているロジックによっては、複数のデプロイ間のセッション情報に一貫性がなくなる場合があります。アプリケーション内のコードによっては、セッション情報が以前のデプロイとは異なる方法で処理される場合があります。ただし、多くの場合、アプリケーションのコードに変更があっても、ビジネス・ロジック内でのセッション情報の処理方法には影響しません。これに加え、また情報が重大である場合もあるため、複数のデプロイを使用するユーザー間でセッションに追加されたデータを保守した方がよい場合があります。

この項では、OracleAS Clusterを使用して、新規バージョンのアプリケーションをデプロイしてもHttpSession情報が失われないようにする方法について説明します。この手順では、クラスタを構成する異なるインスタンス内のアプリケーションを連続して（「ローリング」）更新します。

4.2.5.1 構成およびHttpSessionレプリケーション

ファイルベースまたはデータベースベースのリポジトリを使用して管理されているOracleAS Cluster（DCM管理のクラスタともいう）を使用するメリットの1つは、DCMを使用してクラスタを作成すると、クラスタ内のすべてのインスタンスに構成が自動的に伝播されることです。これにより、単一の手順でクラスタ内のすべてのOracle Application Serverインスタンスにアプリケーションをデプロイできます。DCMは、EARファイルまたはWARファイルを伝播し、クラスタ内のすべてのノードに構成をレプリケートします。

この構成レプリケーション機能は、しばしばクラスタの「実行時の状態」のレプリケーションと取り違えられています。構成のレプリケーションはDCMを使用して実現されます。J2EEデプロイ内のHttpSession状態のレプリケーションは、OracleAS Cluster（OC4J）のIPマルチキャストおよびシリアライズのメカニズムを使用して実現されます。

Application Server Controlを使用してOracleAS Clusterを作成すると、DCMを使用した構成のレプリケーションと、クラスタ内のOracle Application Serverインスタンスに「常駐」するOC4Jコンテナの間のHttpSessionレプリケーションの、両方のメカニズムが実行されます。ただし、セッションのレプリケーションは、構成のレプリケーションとは全く別のものです。複数のOC4Jインスタンスの間でHttpSessionオブジェクトのレプリケーションを有効にするために必要な構成パラメータは次の3つだけです。

• マルチキャスト・アドレスおよびポート

• アイランド定義

• アプリケーションのweb.xmlデプロイメント・ディスクリプタのdistributableタグ

これに基づいて、同じ構成グループに所属することなく、「HttpSessionレプリケーション・グループ」に参加できます。（OracleAS Clusterにアプリケーションを再デプロイしたときに状態を維持することを目的とする）この項で説明する手順は、これら2つの概念を分離することに基づいています。この手順は、手動で構成されているOracleAS Cluster（OC4J）には該当しません。このタイプのクラスタでは、デプロイはノードごとに行われます。これらの場合、レプリケーションを実行する十分な時間（クラスタ内の各インスタンスのデプロイ間隔）があるかぎり、セッションは自動的に維持されます。

4.2.5.2 使用例

この項で説明する手順は、次の場合を想定しています。

1つのOracleAS Farmに、1つのクラスタ（クラスタ1）として構成されている2つのOracle Application Serverインスタンス（I1とI2）があり、これらのインスタンスの状態は同じ（つまり、同じOC4Jアイランド内で構成されている）です。このクラスタは、ファイルベースまたはデータベースベースのいずれかのリポジトリを使用して管理されています。

1つのアプリケーションがこのクラスタにデプロイされています。このアプリケーションは1つのOC4Jインスタンス（OC4J_Clustered）にデプロイされています。アプリケーションはすでにデプロイ済で、バージョンは0です。なんらかの状態がHttpSessionに格納されています。目標は、状態を維持しつつ、新規バージョンのアプリケーション（バージョン1）をデプロイすることです。Oracle Application Serverインスタンス内の2つのOracle HTTP Serverは、外部のロード・バランサ（通常はOracleAS Web Cacheまたはサード・パーティのハードウェアのロード・バランサ）でロード・バランスされています。

図4-8に、この使用例の最初の状態を示します。

図4-8    最初の状態

画像の説明

4.2.5.3 手順

1. Application Server Controlコンソールを使用して、クラスタ内の1つのインスタンス（I2など）のOC4JとOracle HTTP Serverを停止します。これにより、すべてのリクエストが単一のノードにルーティングされ、状態は維持されます。

2. Application Server Controlコンソールを使用して、停止したインスタンス（I2）をクラスタから削除します。
   1. Application Server Controlコンソールで、「クラスタ1」をクリックします。

   2. 「I2」インスタンスを選択します。

   3. 「削除」をクリックします。

   クラスタからI2を削除し、I2のOC4J_Clusteredコンポーネントを停止しましたが、この時点ではレプリケーションの構成は同じままで、2つのインスタンスは同じIPマルチキャスト・グループ内に引き続き存在します。

   図4-9に、この時点での構成を示します。

   図4-9    インスタンスI2を停止し、クラスタ1から削除

   
   

   画像の説明

3. Application Server Controlコンソールを使用して、新規バージョンのアプリケーションを、クラスタから削除されているI2インスタンスにデプロイします。図4-10を参照してください。

   図4-10    新規バージョンのアプリケーションがデプロイされたインスタンスI2

   
   

   画像の説明

4. 別のクラスタ（クラスタ2）を作成して、スタンドアロンのインスタンス（I2）を追加します。図4-11を参照してください。

   図4-11    新規クラスタCluster2へのインスタンスI2の追加

   
   

   画像の説明

5. 2つ目のクラスタ（クラスタ2）でI2インスタンスを起動します。この時点で、2つのインスタンスは依然同じIPマルチキャスト・グループ内にあり、OC4Jインスタンスのアイランド定義が同じであるため、2つの異なるクラスタ間で引き続きレプリケーションが行われます。図4-12を参照してください。

   図4-12    インスタンスI2の起動

   
   

   画像の説明

6. 最初のクラスタ（クラスタ1）でI1インスタンスを停止します。

7. 最初のクラスタ（クラスタ1）からI1インスタンスを削除します。

   図4-13に、この時点での状態を示します。

   図4-13    インスタンスI1を停止し、クラスタ1から削除

   
   

   画像の説明

8. 停止したインスタンスI1を2つ目のクラスタ（クラスタ2）に結合します。DCMが新規バージョンのアプリケーション（バージョン1）を、結合されたインスタンス（I1）に自動的にデプロイします。

   図4-14    インスタンスI1をクラスタ2に追加し、アプリケーションがバージョン1になった状態

   
   

   画像の説明

9. 最初のインスタンスI1を起動します。

   図4-15    両方のインスタンスで新規バージョンのアプリケーションを実行および使用

   
   

   画像の説明

これで、2つのノードに新規バージョンのアプリケーションがデプロイされました。HttpSession情報は、両方のデプロイで維持されています。この処理で失われた状態はありません。

4.2.5.4 DCMスクリプトを使用した手順の自動化

前述の手順を自動化するには、関係する各インスタンスにDCMスクリプトを使用します。次のスクリプトは実装例であり、次のパラメータを使用してカスタマイズできます。

appname: デプロイおよび更新対象のアプリケーション名

app.ear: デプロイする新規EARファイルのフルパス

instance_n: 最初に更新されるOracle Application Serverインスタンスの名前

last_instance: 最後に更新されるOracle Application Serverインスタンスの名前

cluster1: アプリケーションがもともとデプロイされていたクラスタの名前

cluster2: セッションの移行に使用されるクラスタの名前

dcmscript_instance_n

stop -i instance_n -ct OC4J
stop -i instance_n -co HTTP_Server -ct HTTP_Server
leaveCluster -i instance_n
undeployApplication -a appname
deployApplication -f app.ear -a appname
joinCluster -cl cluster2 -i instance_n
start -i instance_n

dcmscript_last_instance

stop -i last_instance
leaveCluster -i last_instance
joinCluster -cl cluster2 -i last_instance
start -i instance_1

この手順では、最後のインスタンスより前に更新されるクラスタ内のインスタンスに、まずdcmscript_instance_nを実行します。最後のインスタンスを除くすべてのインスタンスにこれを実行した後に、最後のインスタンスからdcmscript_last_instanceを実行します。これらのスクリプトの実行方法は次のとおりです。

> cd ORACLE_HOME/dcm/bin
> dcmctl shell -f filename

ここでは、filenameは、DCMスクリプトの名前（dcmscript_instance_nまたはdcmscript_last_instance）です。

今後ステートフルにデプロイするには、元のクラスタとセッション所有者のクラスタの間でロールを切り替える必要があります。これを行うには、スクリプトをさらに作成します。

dcmscript_instance_n_odd_run

stop -i instance_n -ct OC4J
stop -i instance_n -co HTTP_Server -ct HTTP_Server
leaveCluster -i instance_n
undeployApplication -a appname
deployApplication -f app.ear -a appname
joinCluster -cl cluster1 -i instance_n
start -i instance_n

dcmscript_last_instance_odd_run

stop -i last_instance
leaveCluster -i last_instance
joinCluster -cl cluster1 -i last_instance
start -i instance_1

次回の状態を含めたデプロイでは、最初のスクリプト・セットを実行する必要があり、その次のデプロイではodd_runスクリプトを使用し、以下同様になります。

4.2.5.5 その他の考慮事項

クラスタに3つ以上のインスタンスが含まれている場合は、前述の例でI1を移動した場合と同じ方法で、2つのクラスタ間でインスタンスを移動する必要があります（クラスタ内のインスタンスごとに、手順6〜9を実行する必要があります）。

後続のデプロイでは、クラスタ1とクラスタ2のロールは切り替わります。手順に従って最後のインスタンスを移動した後は、今後使用するために空のクラスタを残してください。

新規バージョンのアプリケーションによって、セッションに追加されるオブジェクトの署名が変更される場合（オブジェクトに新規の属性が追加されるなど）は、クラスタに関連しているクラスの新規バージョンがコンテナに自動的にロードされます。つまり、署名が変更された場合、セッションは失われます。再デプロイに含まれる、サーブレット、JSPおよびクラスに対するその他の変更は、インスタンスに取り入れられ、HttpSessionの状態は失われません。

4.2.6 DCM-Managed OracleAS Clusterに対するOracle HTTP Serverのオプションの構成

この項では、DCM-Managed Oracle Application Server Clusterに対するOracle HTTP Serverのオプションについて説明します。

この項の項目は次のとおりです。

• 第4.2.6.1項「mod_oc4jロード・バランシングの使用と構成」

• 第4.2.6.2項「Oracle HTTP Serverインスタンス固有のパラメータの構成」

• 第4.2.6.3項「Real Application Clustersを使用したmod_plsqlの構成」

4.2.6.1 mod_oc4jロード・バランシングの使用と構成

DCM-Managed OracleAS Clusterを使用するときは、Oracle HTTP Serverのモジュールmod_oc4jによって、OC4Jプロセスに対するリクエストのロード・バランシングが行われます。Oracle HTTP Serverでは、mod_oc4j構成オプションを使用して、様々なロード・バランシング・ポリシーがサポートされています。ロード・バランシング・ポリシーを指定することにより、ネットワーク・トポロジやホスト・マシンの性能に応じて、DCM-Managed OracleAS Clusterのパフォーマンス上のメリットだけでなく、フェイルオーバーや高可用性も実現します。

デフォルトでは、mod_oc4jは、重みを使用してリクエストの転送先ノードを選択します。各ノードのデフォルトの重みは1です。ノードの重みは、使用可能な他のノードの重みに対する比率として扱われ、これによって、DCM-Managed OracleAS Cluster内の他のノードと比較してそのノードが処理するリクエストの数が定義されます。特定のリクエストを処理するノードが選択されると、デフォルトでは、mod_oc4jはroundrobinポリシーを使用してノード上のOC4Jプロセスを選択します。受信リクエストが、確立済のセッションに属する場合、そのリクエストは、そのセッションを開始したのと同じノードおよび同じOC4Jプロセスに転送されます。

mod_oc4jのロード・バランシング・ポリシーでは、リクエストの送信先ノードを計算するときに、ノード上で実行されているOC4Jプロセスの数は考慮されません。ノードの選択は、ノードに対して構成済の重みと、その可用性に基づいて行われます。

mod_oc4jロード・バランシング・ポリシーを変更するには、mod_oc4j.confファイル内のOc4jSelectMethodおよびOc4jRoutingWeight構成ディレクティブを使用します。

次に示す手順に従い、Application Server Controlコンソールを使用してmod_oc4j.confファイルを構成します。

1. インスタンスのホーム・ページにある「システム・コンポーネント」領域で、HTTP_Serverコンポーネントを選択します。

2. HTTP_Serverページの「管理」リンクをクリックします。

3. 「管理」ページの「拡張サーバー・プロパティ」リンクをクリックします。

4. 「拡張サーバー・プロパティ」ページの「構成ファイル」領域にある「mod_oc4j.conf」リンクを選択します。

5. 「mod_oc4j.confの編集」ページの「<IfModule mod_oc4j.c>」セクションで、Oc4jSelectMethodディレクティブおよびOc4jRoutingWeightディレクティブを追加または編集して、目的のロード・バランシング・オプションを選択します。

   注意 Application Server Controlコンソールを使用しない場合は、次に示すとおりにmod_oc4j.confを編集し、dcmctl updateConfigコマンドを使用してDCM-Managed OracleAS Cluster内にある他のすべてのmod_oc4j.confファイルに変更内容を伝播します。 > dcmctl updateconfig -ct ohs > opmnctl @cluster:<cluster_name> restartproc ias-component=HTTP_Server process-type=HTTP_Server cluster_nameはクラスタの名前です。 opmnctl restartprocコマンドは、クラスタ内のすべてのインスタンスに対して変更を有効にするために必要です。

   関連項目 第4.4.3項「OC4Jインスタンス固有のパラメータの構成」 mod_oc4jのロード・バランシング・ディレクティブの使用方法は、『Oracle HTTP Server管理者ガイド』を参照してください。 『Oracle Application Serverパフォーマンス・ガイド』

4.2.6.2 Oracle HTTP Serverインスタンス固有のパラメータの構成

Oracle HTTP Serverのポートおよびリスニング・アドレスは、Oracle HTTP Serverホーム・ページからアクセス可能な「サーバー・プロパティ」ページで変更できます。仮想ホスト情報を変更するには、Oracle HTTP Serverホーム・ページの「仮想ホスト」セクションで仮想ホストを選択します。

表4-3に、Oracle HTTP Serverインスタンス固有のパラメータを示します。

4.2.6.3 Real Application Clustersを使用したmod_plsqlの構成

この項の項目は次のとおりです。

• 第4.2.6.3.1項「デッド接続の検出とクリーンアップの構成」

• 第4.2.6.3.2項「検索時のOracleディレクトリの使用」

4.2.6.3.1 デッド接続の検出とクリーンアップの構成

Oracle HTTP Serverをmod_plsqlモジュールと組み合せて使用する場合は、データベースが使用不可能になったときに、そのデータベースへの接続を検出してクリーンアップする必要があります。この項では、デッド接続を検出してクリーンアップするようにmod_plsqlを構成する方法を説明します。

mod_plsqlは、データベースへの複数の接続のプールを維持し、確立済の接続を以降のリクエストに再利用します。あるデータベース接続からレスポンスがないと、mod_plsqlはこの状態を検出し、デッド接続を破棄して新しいデータベース接続を作成し、以降のリクエストに使用します。

デフォルトでは、Real Application Clustersのノードまたはデータベース・インスタンスへの接続がmod_plsqlによって事前にプールされている場合に、そのノードまたはインスタンスが停止すると、プール内のデッド接続を使用する最初のmod_plsqlリクエストの結果として障害レスポンスHTTP-503がエンドユーザーに返されます。mod_plsqlモジュールはこの障害を処理し、これをトリガとして接続プール内のデッド接続をすべて検出し、削除します。mod_plsqlモジュールは、障害レスポンスより前に作成されたすべての接続プールに対してpingを実行します。このpingは、プールされた接続を使用する次のリクエストを処理する時点で実行されます。pingに失敗した場合は、データベース接続は廃棄され、新しい接続が作成されて処理されます。

PlsqlConnectionValidationパラメータがAutomaticに設定されている場合は、リクエストのエラーが発生する前に作成された、プールされたデータベース接続のすべてがmod_plsqlモジュールによってテストされます。これはデフォルトの構成です。

PlsqlConnectionValidationパラメータがAlwaysValidateに設定されている場合は、mod_plsqlはリクエストを発行する前に必ず、すべてのプールされたデータベース接続をテストします。構成オプションAlwaysValidateを使用すれば可用性は高まりますが、パフォーマンスのオーバーヘッドも増えます。

mod_plsqlによる接続プール内の不良データベース接続のテストに対してタイムアウト時間を指定することもできます。PlsqlConnectionTimeoutパラメータで指定された最大時間が経過してもテスト・リクエストが完了しなければ、mod_plsqlはその接続が使用不可能であると見なします。

関連項目 『Oracle Application Server mod_plsqlユーザーズ・ガイド』

4.2.6.3.2 検索時のOracleディレクトリの使用

Oracle Netクライアントは、接続記述子の検索時にディレクトリ・サーバーを使用できます。リクエストの開始時に、クライアントが接続識別子を使用してディレクトリ・サーバーにアクセスすると、接続識別子が解決されて接続記述子が取得されます。

ディレクトリ・サーバーを使用する利点は、サーバーの接続情報を集中管理できることです。ポートの変更またはホストの変更が理由で接続情報を変更する必要が生じた場合も、新しい接続情報を更新するのは一度だけです。ディレクトリ・サーバーで更新を行うだけで、その接続方式を使用するすべてのOracle Netクライアントが新しいホストに接続できるようになります。

関連項目 ディレクトリ・ネーミングの構成方法は、『Oracle Database Net Services管理者ガイド』を参照してください。

4.2.7 DCM-Managed OracleAS Clusterのメンバーシップについて

DCM-Managed OracleAS Clusterの作成後は、Oracle Application Serverインスタンスの追加が可能です。この項では、DCM-Managed OracleAS Clusterの構成と、クラスタリング可能なOracle Application Serverインスタンスの特徴について説明します。

この項の項目は次のとおりです。

• 第4.2.7.1項「共通構成の構築方法」

• 第4.2.7.2項「共通構成から除外されるパラメータ: インスタンス固有のパラメータ」

4.2.7.1 共通構成の構築方法

Oracle Application ServerインスタンスをDCM-Managed OracleAS Clusterに追加する順番は重要です。DCM-Managed OracleAS Cluster全体でレプリケートされる共通構成は、クラスタに最初に追加されるOracle Application Serverインスタンスによって確立されます。最初に追加されたOracle Application Serverインスタンスの構成は、その後にDCM-Managed OracleAS Clusterに結合されるすべてのOracle Application Serverインスタンスに継承されます。

共通構成には、クラスタレベルのすべての構成情報が含まれます。具体的には、DCM-Managed OracleAS ClusterおよびOracle Application Serverインスタンスの属性のことで、構成対象のコンポーネントはその一例です。たとえば、クラスタに最初に追加されるOracle Application Serverインスタンスに4つのOC4Jインスタンスがある場合は、この4つのOC4Jインスタンスと、これらのOC4Jインスタンス上にデプロイされるアプリケーションが共通構成に含まれます。その後にDCM-Managed OracleAS Clusterに結合されるOC4Jインスタンスは、これらのインスタンスおよびデプロイされるアプリケーションをレプリケートします（さらに、Oracle Application ServerインスタンスがDCM-Managed OracleAS Clusterに結合されるときに、共通構成に一致しないOC4Jコンポーネントがある場合は、DCMによってそのコンポーネントが削除されます）。また、DCM-Managed OracleAS Cluster内のOracle Application Serverインスタンスのいずれかに、OC4Jインスタンスの追加や削除などの変更を加えると、その変更はDCM-Managed OracleAS Cluster全体でレプリケートされます。構成対象のコンポーネントは、クラスタレベルでレプリケートされる共通構成の一部です。

DCM-Managed OracleAS Clusterの最後のOracle Application Serverインスタンスが削除されると、DCM-Managed OracleAS Clusterは空のDCM-Managed OracleAS Clusterとなり、次回Oracle Application Serverインスタンスが結合されるときに、DCM-Managed OracleAS Clusterの新しい共通構成が確立します。

4.2.7.2 共通構成から除外されるパラメータ: インスタンス固有のパラメータ

パラメータの中には、特定のOracle Application Serverインスタンスまたは特定のコンピュータのみに適用されるものがありますが、このようなパラメータはインスタンス固有のパラメータです。インスタンス固有のパラメータは、DCMによってDCM-Managed OracleAS Cluster内の他のOracle Application Serverインスタンスに伝播されることはありません。インスタンス固有のパラメータを変更するときに、その変更をDCM-Managed OracleAS Cluster全体に適用するには、該当するOracle Application Serverインスタンスに、それぞれ変更を適用する必要があります。

表4-2    OC4Jインスタンス固有のパラメータ 

パラメータ	説明
アイランド定義	Oracle Application Serverインスタンス固有。ステートフルOC4Jアプリケーションの状態をレプリケートするには、各OC4Jインスタンス内のアイランドの名前がすべて、DCM-Managed OracleAS Cluster全体で同じである必要があります。
プロセスの数	コンピュータ固有。コンピュータの性能に応じて、このパラメータを調整します。
コマンドライン・オプション 注意: コマンドライン・オプションをインスタンス固有にする場合は、追加の構成を実行する必要があります。詳細は、第4.2.7.3項「インスタンス固有のコマンドライン・オプションの構成」を参照してください。	コンピュータ固有。
RMI、JMSおよびAJP通信用のポート番号	コンピュータ固有。

表4-3    Oracle HTTP Serverインスタンス固有のパラメータ 

パラメータ	説明
ApacheVirtualHost	コンピュータ固有。
Listen	コンピュータ固有。このディレクティブは、サーバーを特定のアドレスまたはポートにバインドします。
OpmnHostPort	コンピュータ固有。
Port	コンピュータ固有。このディレクティブは、スタンドアロン・サーバーがリスニングするポートを指定します。
User	コンピュータ固有。
Group	コンピュータ固有。
NameVirtualHost	コンピュータ固有。このディレクティブは、名前ベースの仮想ホストへのリクエストを、サーバーがどのIPアドレスで受信するかを指定します。このディレクティブでは、ポートを指定することもできます。
ServerName	コンピュータ固有。リダイレクションURLの作成時にサーバーが返すホスト名を指定します。このディレクティブは、ローカル・ホスト上でgethostbynameが機能しない場合に使用されます。サーバーがDNS別名をホスト名（たとえばwww.mydomain.com）として返すように設定する場合にも使用できます。
PerlBlob	コンピュータ固有。

表4-4    OPMNインスタンス固有のパラメータ 

opmn.xmlファイル内のパラメータ	説明
通知サーバーの全構成: opmn/notification-server	コンピュータ固有。
process-managerの要素: log-file process-module	Oracle Application Serverインスタンス固有。
ias_instanceの属性: id ORACLE_HOME ORACLE_CONFIG_HOME	Oracle Application Serverインスタンス固有。
opmn/process-manager/ias-instance /ias-component/process-typeの次の要素と属性 port.range start stop ping restart process-set	Oracle Application Serverインスタンス固有。これらの要素および属性はインスタンス固有ですが、デフォルトの構成があります（構成は伝播されませんが、リポジトリから取得されます）。MissingLocalValuePolicyフラグは、その要素または属性にデフォルト値があることを示します。 MissingLocalValuePolicy="UseRepositoryValue"
次のopmn/process-manager/ias-instanceの属性および要素: module-data/category/data[id='config-file'] ias-component/module-data/category/data[id='config-file'] ias-component/process-type/ module-data/category/data[id='config-file'] ias-component/process-type/ process-set/module-data/category/data[id='config-file'] 環境 ias-component/environment ias-component/process-type/ environment ias-component/process-type/ process-set/environment opmn/process-manager/ias-instance/ ias-component内のIDがHTTP_ServerとOC4Jのどちらでもない他のすべてのコンポーネント: [id='dcm-daemon'] [id='WebCache'] [id='OID'] [id='IASPT'] [id='wireless'] [id='Discoverer'] [id='LogLoader'] [id='Custom']	HTTP_ServerおよびOC4Jのほとんどのパラメータはクラスタレベルのパラメータです。ここでは、インスタンス固有のパラメータのみを示します。 全般的な規則: IDがconfig-fileであるデータ要素はインスタンス固有です。 環境要素はインスタンス固有です。 関連項目: opmn.xmlファイル全体の説明は、『Distributed Configuration Management管理者ガイド』の付録B「DCMのトラブルシューティング」を参照してください。ここには、これらの要素および属性の階層が記載されています。

4.2.7.3 インスタンス固有のコマンドライン・オプションの構成

コマンドライン・オプションをインスタンス固有にするには（つまり、他のインスタンスにオプションを伝播させないようにするには）、ORACLE_HOME/opmn/conf/instspec.xmlファイルを次のように編集する必要があります。

1. ORACLE_HOME/opmn/conf/instspec.xmlファイルの次の行を削除（またはコメント・アウト）します。この作業は、クラスタ内のすべてのノードに対して行う必要があります。

   <!-- for HTTP_Server and OC4J, only this is instance specific -->
   <InstanceScopeItem target="/opmn/process-manager/ias-instance/ias-component/
                       process-type/module-data/category/data[id='config-file']"/>
   
   

2. 次の行をinstspec.xmlファイルに追加します。この作業は、クラスタ内のすべてのノードに対して行う必要があります。

   <!-- for HTTP_Server and OC4J, only this is instance specific --> 
   <InstanceScopeItem target="/opmn/process-manager/ias-instance/ias-component/
                                         process-type/module-data/category/data"/>
   
   <InstanceScopeItem target="/opmn/process-manager/ias-instance/ias-component/
                      process-type/module-data/category/data[id='java-options']"/>
   
   <InstanceScopeItem target="/opmn/process-manager/ias-instance/ias-component/
                      process-type/module-data/category/data[id='oc4j-options']"/>
   
   <InstanceScopeItem target="/opmn/process-manager/ias-instance/ias-component/
                          process-type/module-data/category/data[id='java-bin']"/>
   
   

3. Oracle Application Serverインスタンスがデータベース・リポジトリを使用するOracle Application Serverファームにある場合、次のコマンドを実行してinstspec.xmlに行った変更をデータベースに反映させます。Oracle Application Serverインスタンスがファイルベース・リポジトリにある場合は、このコマンドを実行する必要はありません。

   このコマンドは、クラスタ内のすべてのノードに対して実行する必要があります。

   java -jar ORACLE_HOME/dcm/lib/dcm.jar registerplugin
                    -f ORACLE_HOME/opmn/conf/register.xml -o ORACLE_HOME
   
   

4. OPMNを再ロードします。

   ORACLE_HOME/opmn/bin/opmnctl reload
   
   

   このコマンドは、クラスタ内のすべてのノードに対して実行する必要があります。

4.3 DCM構成リポジトリの可用性に関する考慮事項

この項では、DCM構成リポジトリの可用性に関する考慮事項を説明します。この項の項目は次のとおりです。

• 第4.3.1項「DCM-Managed OracleAS Cluster（データベース）の可用性に関する考慮事項」

• 第4.3.2項「DCM-Managed OracleAS Cluster（ファイルベース）の可用性に関する考慮事項」

  注意 構成リポジトリの可用性の影響を受けるのは、Oracle Application Serverの構成および管理のサービスのみです。リクエストを処理するシステムの可用性や、DCM-Managed OracleAS Cluster内で実行されるアプリケーションの可用性には影響しません。

4.3.1 DCM-Managed OracleAS Cluster（データベース）の可用性に関する考慮事項

この項では、DCM-Managed OracleAS ClusterをOracleAS Database-based Farmとともに使用する場合のDCM構成リポジトリの可用性に関する考慮事項を説明します。

Real Application Clustersデータベースやその他のデータベースの高可用性ソリューションとともにOracleAS Database-based Farmを使用すると、DCM構成リポジトリ・データベースに障害が発生した場合にも、高可用性、スケーラビリティ、冗長性により、システムが保護されます。

関連項目 Oracle Databaseの高可用性ソリューションの説明は、『Oracle高可用性アーキテクチャおよびベスト・プラクティス』を参照してください。

4.3.2 DCM-Managed OracleAS Cluster（ファイルベース）の可用性に関する考慮事項

OracleAS File-based Farmを使用する場合は、DCM構成リポジトリは常に1つのOracle Application Serverインスタンス上に存在することになります。DCM構成リポジトリを保持するホストに障害が発生した場合は、手動フェイルオーバー（リポジトリ・ホストを別のホストに移行する）を行う必要があります。

この項では、DCM-Managed OracleAS ClusterをOracleAS File-based Farmとともに使用する場合のDCM構成リポジトリの可用性に関する考慮事項を説明します。

• 第4.3.2.1項「OracleAS File-based Farmリポジトリ・ホストに使用するインスタンスの選択」

• 第4.3.2.2項「リポジトリ・ホストの損失の防止」

• 第4.3.2.3項「リポジトリ・ホストが使用不可能になることの影響」

• 第4.3.2.4項「リポジトリ・ホスト以外が使用不可能になることの影響」

• 第4.3.2.5項「ローカル構成の状態の更新およびチェック」

• 第4.3.2.6項「DCM-Managed OracleAS Clusterの管理の実行」

• 第4.3.2.7項「リポジトリ・バックアップに関するベスト・プラクティス」

• 第4.3.2.8項「OracleAS File-based Farmのインスタンスの管理に関するベスト・プラクティス」

  注意 この項に示す情報は、OracleAS Database-based Farm（リポジトリ・タイプがデータベース）を使用するDCM-Managed Oracle Application Server Clusterには当てはまりません。

4.3.2.1 OracleAS File-based Farmリポジトリ・ホストに使用するインスタンスの選択

DCM-Managed OracleAS ClusterをOracleAS File-based Farmとともに使用する場合の重要な考慮事項の1つに、どのOracle Application Serverインスタンスをリポジトリ・ホストにするかという判断があります。

OracleAS File-based Farmのリポジトリ・ホストを選択するときは、次の点を考慮してください。

• リポジトリ・ホスト・インスタンスが一時的に使用不可能になったとき、OracleAS File-based Farmを使用するDCM-Managed OracleAS Clusterは引き続き正常に動作可能ですが、構成情報を更新することはできません。

• リポジトリ・ホスト・インスタンスであるOracle Application Serverインスタンスのファイル・システムにDCM-Managed OracleAS Clusterの構成情報が格納されて管理されるため、リポジトリ・ホスト・インスタンスではミラー化ディスクまたはRAIDディスクを使用する必要があります。ディスクのミラー化を使用すると、DCM-Managed OracleAS Clusterの可用性が向上します。

• リポジトリ・ホスト・インスタンスが使用不可能になったときも、実行中のOracle Application Serverインスタンスでの読取り専用の構成操作は影響を受けません。OracleAS Farmのクラスタレベルの構成情報は、ローカルのJava Object Cacheを通して分散および管理されます。

• リポジトリ・ホスト・インスタンスが使用できない場合、ファイルベース・リポジトリ内の構成情報を変更しようとするとエラーが生成されます。このような操作は、リポジトリ・ホスト・インスタンスが使用可能になった後で、またはリポジトリ・ホスト・インスタンスがOracleAS File-based Farm内の別のアプリケーション・サーバー・インスタンスに移動された後で実行する必要があります。

4.3.2.2 リポジトリ・ホストの損失の防止

OracleAS File-based Farmを使用するときは、ファーム内のインスタンスの1つをリポジトリ・ホストとして指定します。このリポジトリ・ホストは、OracleAS File-based Farm内のすべてのインスタンスの構成情報を保持します。OracleAS File-based Farm内のインスタンスの構成情報を変更するときは、リポジトリ・ホストへのアクセス（書込み操作）が必要です。ただし、構成を変更しない読取り操作は、インスタンスのローカル構成キャッシュを使用して実行されます。

リポジトリ・ホストの損失時も、OracleAS File-based Farm内の他のインスタンスを新しいリポジトリ・ホストとして引き継がせることができますが、古いリポジトリ・ホストのエクスポート・コピーが必要です。リポジトリ・ホストのバックアップを定期的に取得し、バックアップを別のシステムに保存しておくことをお薦めします。

関連項目 『Distributed Configuration Management管理者ガイド』

4.3.2.3 リポジトリ・ホストが使用不可能になることの影響

リポジトリ・ホストが使用不可能になったときは、実行できるのは読取り専用操作のみとなります。構成の変更を行うことはできません。updateConfigコマンドの実行など、リポジトリ・ホストに対する更新を必要とする操作を試みると、次に示すようなエラー・メッセージがdcmctlから返されます。

ADMN-100205
Base Exception:
The DCM repository is not currently available. The OracleAS 10g instance,
"myserver.mydomain.com", is using a cached copy of the repository information.
This operation will update the repository, therefore the repository must be available.

リポジトリ・ホストが完全に停止した、つまり長期間使用不可能となる場合は、リポジトリ・ホストを移動する必要があります。リストアされたリポジトリが最新の状態でない場合は、ローカル・インスタンス・アーカイブを適用して各インスタンスの状態を更新することができます。

関連項目 第4.3.2.6項「DCM-Managed OracleAS Clusterの管理の実行」

4.3.2.4 リポジトリ・ホスト以外が使用不可能になることの影響

DCM-Managed OracleAS Cluster内の、リポジトリ・ホストではないインスタンスが停止した場合でも、他のインスタンスはすべて正常に機能します。あるインスタンスが短期間停止する場合は、そのインスタンスが再び使用可能になったときにインスタンスの構成情報が自動的に更新されます。

あるインスタンスが完全に失われてしまった場合も、OracleAS File-based Farm内の他のインスタンスへの影響はありません。ただし、整合性を維持するには、損失したインスタンスに関係するレコードをすべて削除する必要があります。

損失したインスタンスの構成情報を削除するには、次のコマンドを使用します。

> dcmctl destroyInstance

4.3.2.5 ローカル構成の状態の更新およびチェック

構成の変更がすべて正常に終了することと、クラスタ内の全インスタンスの同期がとれていることが重要です。ローカルの構成情報は、リポジトリに格納されている情報と一致する必要があります。DCMは構成ファイルが手動で変更されたことを認識せず、そのような変更が行われると、クラスタ内のインスタンスの同期ステータスはFALSEとなります。

次のdcmctlコマンドを実行すると、管理対象の全コンポーネントのリストと各コンポーネントの同期ステータスが返されます。

> dcmctl getState -cl cluster_name

同期ステータスがTRUEの場合は、コンポーネントのローカルの構成情報が、リポジトリに格納されている情報と同じであることを示します。

変更されたローカルの情報によってファイルベース・リポジトリを更新する必要がある場合は、次のようにdcmctlコマンドのupdateConfigを使用します。

> dcmctl updateconfig
> dcmctl getstate -cl cluster_name

リポジトリからの情報でローカルの情報を更新するには、resyncInstanceコマンドを使用します。たとえば、次のように入力します。

> dcmctl resyncinstance

デフォルトでは、このコマンドを実行すると、同期ステータスがFALSEであるコンポーネントの構成情報のみが更新されます。-forceオプションを使用すると、同期ステータスとは無関係にすべてのコンポーネントが更新されます。

4.3.2.6 DCM-Managed OracleAS Clusterの管理の実行

管理のための計画停止中は、OracleAS File-based Farmを使用するDCM-Managed OracleAS Clusterが複数のホスト上で稼動していてリソースも十分であれば、リクエスト処理を続行しながら管理タスクを実行できます。この項では、リクエスト処理を中断せずにDCM-Managed OracleAS Cluster内のリポジトリ・ホストを移動する方法を説明します。

この手順は、DCM-Managed OracleAS Clusterに対して次のような管理タスクを実行するときに便利です。

• リポジトリ・ホスト・ノードの使用を中止するためリポジトリを移動する。

• 必要なパッチをDCM-Managed OracleAS Clusterに適用する。

• DCM-Managed OracleAS Cluster内のホストのシステム再起動を必要とするようなシステム・アップグレード、変更またはパッチを適用する。

  注意 ここで説明する手順を使用すれば、計画停止中に利用できなくなるのは管理機能のみです。

DCM-Managed OracleAS Cluster内のリポジトリ・ホストを移動するには、次の手順を実行します。

1. 次のDCMコマンドを実行します。UNIXシステムの場合:

   > cd $ORACLE_HOME/dcm/bin
   > dcmctl exportRepository -f file
   
   

   Windowsシステムの場合:

   > cd %ORACLE_HOME%¥dcm¥bin
   > dcmctl exportRepository -f file
   
   

   注意 この手順の実行後は、構成を変更するような構成コマンドや管理コマンドは実行しないでください。そうでない場合、リポジトリ・ファイルが新しいリポジトリ・ホストにインポートされるときに、変更はコピーされません。

2. OracleAS File-based Farmの各インスタンス（新しいリポジトリ・ホストとなるインスタンスを除く）内のEnterprise ManagerおよびDCMデーモンなどの管理システムを停止します。

   UNIXシステムでは、クラスタ内の各インスタンスで次のコマンドを使用します。

   > $ORACLE_HOME/bin/emctl stop iasconsole
   > $ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=dcm-daemon
   
   

   Windowsシステムでは、クラスタ内の各インスタンスで次のコマンドを使用します。

   > %ORACLE_HOME%¥bin¥emctl stop iasconsole
   > %ORACLE_HOME%¥opmn¥bin¥opmnctl stopproc ias-component=dcm-daemon
   

   この時点でも、DCM-Managed OracleAS Clusterによるリクエストの処理は引き続き可能です。

3. リポジトリ・ホスト・インスタンスとなるホスト上で、保存済のリポジトリをインポートします。

   UNIXシステムでは、次のコマンドを使用します。

   > cd $ORACLE_HOME/dcm/bin/
   > dcmctl importRepository -file filename
   
   

   Windowsシステムでは、次のコマンドを使用します。

   > cd %ORACLE_HOME%¥dcm¥bin¥
   > dcmctl importRepository -file filename
   
   

   filenameは、exportRepositoryコマンドで指定したファイルの名前です。

   importRepositoryがアクティブである間も、DCM-Managed OracleAS Clusterによるリクエストの処理は引き続き可能です。

   注意 importRepositoryコマンドを実行すると、現在リポジトリをホスティングしているシステムの停止が必要であることを示すプロンプトが表示されます。ただし、停止が必要なのは、システム全体ではなく、現在リポジトリをホスティングしているシステム上のdcm-daemonのみです。

4. 新しいリポジトリ・ホスト上で、次のコマンドを実行してすべてのコンポーネントを起動します。この時点では、管理機能は実行しないでください。

   UNIXシステムの場合:

   > $ORACLE_HOME/opmn/bin/opmnctl startall
   
   

   Windowsシステムの場合:

   > %ORACLE_HOME%¥opmn¥bin¥opmnctl startall
   
   

5. 以前リポジトリ・ホストであったシステム上で、そのインスタンスがホストではなくなったことを示すために次のコマンドを実行します。

   > dcmctl repositoryRelocated
   
   

6. 新しいリポジトリ・ホスト・インスタンス上で、Application Server Controlコンソールを起動します。リポジトリの移動は完了しており、新しいリポジトリ・インスタンスがリクエストを処理するようになっています。

   UNIXシステムでは、クラスタ内の各インスタンスで次のコマンドを使用します。

   > $ORACLE_HOME/bin/emctl start iasconsole
   
   

   Windowsシステムでは、クラスタ内の各インスタンスで次のコマンドを使用します。

   > %ORACLE_HOME%¥bin¥emctl start iasconsole
   
   

7. 次のコマンドを使用して、以前のリポジトリ・ホストに関連付けられているOracle Application Serverインスタンスを停止します。

   UNIXシステムの場合:

   > $ORACLE_HOME/opmn/bin/opmnctl stopall
   
   

   Windowsシステムの場合:

   > %ORACLE_HOME%¥opmn¥bin¥opmnctl startall
   
   

これで、次に示すような管理タスクを以前のリポジトリ・ホスト・システム上で実行できるようになりました。

• DCM-Managed OracleAS Cluster内のリポジトリ・ホスト・システムに必要なパッチを適用する。

• ノードの使用を停止する。

• DCM-Managed OracleAS Clusterのシステム再起動を必要とするようなシステム・アップグレード、変更またはパッチを適用する。

以前リポジトリ・ホストであったシステム上の管理タスクが完了した後で、リポジトリ・ホストを元に戻す場合は、これらの手順をもう一度実行する必要があります。

4.3.2.7 リポジトリ・バックアップに関するベスト・プラクティス

リポジトリのファイルおよびアーカイブをエクスポートするときに、ファイルを既知の場所に保存し、エクスポートしたファイルおよびアーカイブのバックアップを定期的に取得します。また、エクスポートしたリポジトリをリポジトリでないインスタンスから利用できるようにしておくことも、バックアップだけではなく可用性の点でお薦めします。リポジトリ・インスタンスが使用不可能になったときも、エクスポートされたリポジトリ・ファイルが使用可能である場合にかぎり、新しいインスタンスを新しいリポジトリ・ホストとすることができます。

Oracle Application Serverには、リポジトリのバックアップを自動的に行う手順は用意されていません。ただし、構成データを損失しても確実にリカバリできるようにするには、リポジトリ・バックアップの計画を立てておく必要があります。リポジトリ・バックアップは定期的かつ頻繁に実行します。また、構成が変更された後や、インスタンスの追加や削除を伴うトポロジの変更が行われた後にも、リポジトリ・バックアップを実行します。

リポジトリ・バックアップを、OracleAS File-based Farm内の他のノードからアクセス可能な様々なノードに保存します。

関連項目 『Distributed Configuration Management管理者ガイド』

4.3.2.8 OracleAS File-based Farmのインスタンスの管理に関するベスト・プラクティス

OracleAS File-based Farmからインスタンスを追加または削除すると、そのインスタンスで管理されているすべてのプロセスが停止されます。そのインスタンスを使用可能にするには、ファームへの追加または削除の実行後にインスタンスを再起動します。

OracleAS File-based Farmに追加や削除を行う前に、ローカル構成をバックアップすることをお薦めします。たとえば、次のコマンドを使用してアーカイブを作成およびエクスポートします。

> dcmctl createarchive -arch myarchive -comment "Archive before leaving farm"
> dcmctl exportarchive -arch myarchive -f /archives/myarchive

アーカイブは、OracleAS File-based Farm間で移植可能です。インスタンスを新しいファームに追加するときに、前のファームで作成されたアーカイブを適用することができます。

関連項目 『Distributed Configuration Management管理者ガイド』

4.4 Oracle Application Server Cluster（OC4J）の使用

この項では、OracleAS Cluster（OC4J）の構成、およびDCM-Managed OracleAS Clusterとともに使用するOracleAS Cluster（OC4J）について説明します。

OracleAS Cluster（OC4J）を使用すると、Webアプリケーションでの状態のレプリケートが可能となり、OC4Jの下で実行されるアプリケーションの高可用性とフェイルオーバーが実現します。この機能は、DCM-Managed OracleAS Clusterを使用しなくても構成できます。ただし、Oracle Application Serverのこれらの機能を併用すれば、管理がしやすくなり、管理性と高可用性が向上します。この項の説明は、Oracle Application Server Cluster（OC4J）とDCM-Managed OracleAS Clusterの両方を使用することを前提とします。

この項の項目は次のとおりです。

• OracleAS Cluster（OC4J）構成の概要

• クラスタレベルの構成の変更およびOC4Jインスタンスの変更

• OC4Jインスタンス固有のパラメータの構成

  関連項目 OC4Jインスタンスの構成の詳細は、『Oracle Application Server Containers for J2EEユーザーズ・ガイド』を参照してください。

4.4.1 OracleAS Cluster（OC4J）構成の概要

OracleAS Cluster（OC4J）を使用すると、Webアプリケーションでの状態のレプリケートが可能となり、OC4Jの下で実行されるアプリケーションの高可用性とフェイルオーバーが実現します。DCM-Managed OracleAS Cluster内のOracle Application ServerインスタンスおよびOC4Jインスタンスには次のプロパティがあります。

• 各Oracle Application Serverインスタンスの構成は、クラスタレベルで同じです。Application Server Controlコンソールまたはdcmctlを使用してOC4Jのクラスタレベルのパラメータを変更すると、変更内容はクラスタ内のすべてのOracle Application Serverインスタンスに伝播されます。クラスタレベルのOC4J構成を変更するには、1つのOracle Application Serverインスタンス上だけで構成パラメータを変更します。Oracle Application Serverによってクラスタ内の他のすべてのOracle Application Serverインスタンスに変更内容が伝播されます。

• DCM-Managed OracleAS Clusterの一部であるOC4Jインスタンスでインスタンス固有のパラメータを変更しても、その変更がDCM-Managed OracleAS Cluster全体に伝播されることはありません。インスタンス固有のパラメータの変更は、変更が行われた特定のOracle Application Serverインスタンスにのみ適用されます。Oracle Application Serverインスタンスを実行しているホストの性能（システム・メモリーの合計など）はホストごとに異なる可能性があるため、OC4Jインスタンス内でOC4Jプロセスを実行する際は、必要に応じて構成オプションを変えたほうがよい場合もあります。

表4-5は、OC4Jインスタンス固有のパラメータの要約です。OC4Jのこれ以外のパラメータはクラスタレベルのパラメータであり、DCM-Managed OracleAS Cluster全体でレプリケートされます。

表4-5     DCM-Managed OracleAS ClusterでのOC4Jインスタンス固有のパラメータの要約 

OC4Jパラメータ	説明
アイランド定義	アプリケーション・サーバー・インスタンス間でアイランド名の一貫性を保つ必要がありますが、アイランドの定義および各アイランドに関連付けられるOC4Jプロセスの数はインスタンスごとに構成されます。Oracle Application Server構成管理システムがDCM-Managed OracleAS Cluster全体に構成をレプリケートすることはありません。 注意: 同じ名前のOC4Jアイランド内での状態のレプリケートは、アプリケーション境界を越えて、かつクラスタ全体で行われます。したがって、ステートフル・アプリケーションで高可用性を確保するには、クラスタ全体で、各OC4JインスタンスのOC4Jアイランド名が同一になるようにする必要があります。
OC4Jプロセスの数	アプリケーション・サーバー・インスタンス間でアイランド名の一貫性を保つ必要がありますが、アイランドの定義および各アイランドに関連付けられるOC4Jプロセスの数はインスタンスごとに構成されます。DCMがDCM-Managed OracleAS Cluster全体に構成をレプリケートすることはありません。 ホストの性能に応じて、アイランドごとに実行するOC4Jプロセスの数を調整することができます。
ポート番号	RMI、JMSおよびAJPのポート番号は、ホストごとに別々のものを使用できます。
コマンドライン・オプション	コマンドライン・オプションは、ホストごとに別々のものを使用できます。

4.4.2 クラスタレベルの構成の変更およびOC4Jインスタンスの変更

この項の項目は次のとおりです。

• 第4.4.2.1項「OracleAS Cluster（OC4J）内のOC4Jインスタンスの作成と削除」

• 第4.4.2.2項「OracleAS Cluster（OC4J）でのアプリケーションのデプロイ」

• 第4.4.2.3項「OracleAS Cluster（OC4J）を使用したWebアプリケーションの状態レプリケーションの構成」

• 第4.4.2.4項「OracleAS Cluster（OC4J-EJB）を使用したEJBアプリケーションの状態レプリケーションの構成」

• 第4.4.2.5項「OracleAS Cluster（OC4J-EJB）用のステートフルSession Beanレプリケーションの構成」

  関連項目 OC4Jの構成およびアプリケーションのデプロイの詳細は、『Oracle Application Server Containers for J2EEユーザーズ・ガイド』を参照してください。

4.4.2.1 OracleAS Cluster（OC4J）内のOC4Jインスタンスの作成と削除

DCM-Managed OracleAS Cluster内のOracle Application Serverインスタンスのいずれかで新しいOC4Jインスタンスが作成されると、そのOC4Jインスタンスはクラスタ内のすべてのOracle Application Serverインスタンスに伝播されます。

OC4Jインスタンスを作成するには、次の手順を実行します。

1. DCM-Managed Oracle Application Server Cluster内の任意のアプリケーション・サーバー・インスタンスにナビゲートします。

2. 「システム・コンポーネント」領域の「OC4Jインスタンスの作成」を選択します。「OC4Jインスタンスの作成」ページが表示されます。

3. 「OC4Jインスタンス名」フィールドに名前を入力します。

4. 「作成」を選択します。

   Oracle Application Serverによってインスタンスが作成され、新しいOC4JインスタンスがDCMによってDCM-Managed OracleAS Cluster全体に伝播されます。

新しいOC4Jインスタンスは、指定した名前で作成されます。このOC4Jインスタンスは、クラスタ内の各アプリケーション・サーバー・インスタンスの「システム・コンポーネント」セクションに表示されます。

OC4Jインスタンスを削除するには、削除するOC4Jインスタンスの横のチェック・ボックスを選択して、「OC4Jインスタンスの削除」を選択します。DCMによって、OC4Jの削除がクラスタ全体に伝播されます。

4.4.2.2 OracleAS Cluster（OC4J）でのアプリケーションのデプロイ

DCM-Managed OracleAS Clusterでは、アプリケーションを1つのアプリケーション・サーバー・インスタンスにデプロイすると、クラスタ内のすべてのアプリケーション・サーバー・インスタンスにそのアプリケーションが伝播されます。

アプリケーションをクラスタ間でデプロイするには、次の手順を実行します。

1. アプリケーションのデプロイ先のクラスタを選択します。

2. クラスタ内から任意のアプリケーション・サーバー・インスタンスを選択します。

3. アプリケーションのデプロイ先のアプリケーション・サーバー・インスタンス上で、OC4Jインスタンスを選択します。

4. Application Server Controlコンソールまたはdcmctlコマンドを使用して、アプリケーションをOC4Jインスタンスにデプロイします。

   DCMによって、DCM-Managed Oracle Application Server Cluster全体にアプリケーションが伝播されます。

   関連項目 OC4Jインスタンスへのアプリケーションのデプロイの詳細は、『Oracle Application Server Containers for J2EEユーザーズ・ガイド』を参照してください。

4.4.2.3 OracleAS Cluster（OC4J）を使用したWebアプリケーションの状態レプリケーションの構成

Oracle Application Serverで、DCM-Managed OracleAS Cluster全体のステートフルWebアプリケーションの状態を確実に維持できるようにするには、Webアプリケーションの状態レプリケーションを構成する必要があります。

ステートフルWebアプリケーションの状態レプリケーションを構成するには、次の手順を実行します。

1. OC4Jホーム・ページの「管理」リンクを選択します。

2. 「インスタンス・プロパティ」領域の「レプリケーション・プロパティ」リンクを選択します。

3. 下にスクロールして「Webアプリケーション」セクションを表示します。図4-16に、このセクションを示します。

   図4-16    Web状態レプリケーションの構成

   
   

   画像の説明

4. 「セッション状態レプリケーション」チェック・ボックスを選択します。

   オプションで、マルチキャスト・ホストのIPアドレスとポート番号を指定できます。マルチキャスト・アドレスのホストおよびポートを指定しない場合は、ホストIPアドレス230.0.0.1とポート番号9127がデフォルトで使用されます。ホストIPアドレスは、224.0.0.2〜239.255.255.255の間である必要があります。HTTP用とEJB用のマルチキャスト・アドレスには、それぞれ異なるマルチキャスト・アドレスを使用してください。

   注意 マルチキャスト・アドレスを選択する場合は、次のサイトにあるアドレスと重複しないよう注意してください。 http://www.iana.org/assignments/multicast-addresses アドレスの下位23ビットがローカル・ネットワーク制御ブロック（224.0.0.0〜224.0.0.255）と同じである場合、重複が発生する可能性があります。この問題を避けるには、アドレスの下位23ビットにこの範囲内のアドレスと同じビットを持つアドレスを使用しないでください。

5. すべてのWebアプリケーション内のすべてのweb.xmlファイルに<distributable/>タグを追加します。Webアプリケーションがシリアライズ可能な場合、このタグをweb.xmlファイルに追加する必要があります。

   このタグをweb.xmlに追加する場合の例は、次のようになります。

   <web-app>
     <distributable/>
     <servlet>
     ...
     </servlet>
   </web-app>
   

   注意 実行中のクラスタに追加されるインスタンスの起動直後にセッションをレプリケートするには（たとえば、インスタンス間のセッションのレプリケートがすでに開始されている場合）、セッションを維持するアプリケーション内のWebモジュールの構成時に、load-on-startupフラグをTRUEに設定する必要があります。これは、クラスタレベルの構成パラメータです。このフラグの設定方法は、図4-17を参照してください。