| Oracle Fusion Middleware高可用性ガイド 11gリリース1（11.1.1） B55898-01 |
|
 戻る |
 次へ |
この章では、Oracle Application Development Framework（Oracle ADF）とOracle WebCenterの高可用性の概要と構成手順について説明します。
この章の項目は次のとおりです。
Oracle ADFは、JavaPlatform, Enterprise Edition（Java EE）の標準およびオープンソース・テクノロジに基づいて作成されたエンドツーエンド・アプリケーション・フレームワークで、サービス指向アプリケーションの実装を簡素化および迅速化します。Oracle ADFは、Web、無線、デスクトップ、またはWebサービスのインタフェースを使用してデータの検索、表示、作成、変更および検証を行うアプリケーションを作成するエンタープライズ開発者に適しています。Oracle JDeveloper 11gとOracle ADFを連携させると、ドラッグ・アンド・ドロップでのデータ・バインディング、視覚的なUI設計およびチーム開発の各機能を組み込んで、設計からデプロイまでの完全な開発ライフサイクルに対応する環境を作成できます。
コミュニティのベスト・プラクティスに従い、Fusion Webテクノロジ・スタックを使用して作成したアプリケーションでは、次のレイヤーによってサポートされているモデル・ビュー・コントローラ（MVC: Model-View-Controller）アーキテクチャに準拠することで、ビジネス・ロジック、ページ・ナビゲーションおよびユーザー・インタフェースが明確に分離されます。
図6-1に示すように、MVCアーキテクチャでは次のような構成になります。
モデル・レイヤーは、現行ページに関連するデータ値を表します。
ビュー・レイヤーには、その関連データの表示や変更に使用するUIページが保持されます。
コントローラ・レイヤーは、ユーザー入力を処理し、ページ・ナビゲーションを決定します。
ビジネス・サービス・レイヤーは、データ・アクセスを処理し、ビジネス・ロジックをカプセル化します。
フレームワークの中核モジュールは、JSR-227仕様を実装する宣言的なデータ・バインディング機能であるOracle ADF Modelです。この仕様は、宣言的なデータ・バインディング・メタデータへアクセスするためのAPIを提供します。Oracle ADF Modelレイヤーでは、統一されたアプローチを使用して、任意のユーザー・インタフェースとビジネス・サービスをコードを記述することなくバインドすることが可能です。
Fusion Webアプリケーション・テクノロジ・スタックを構成する他のモジュールは次のとおりです。
Oracle ADF Business Componentsは、ビジネス・サービスの構築を簡素化します。
Oracle ADF Facesは、JavaServer Faces（JSF）で構築されたWebアプリケーションに対し、AJAX対応のUIコンポーネントのリッチ・ライブラリを提供します。
Oracle ADF Controllerは、JSFをOracle ADF Modelに統合します。ADF Controllerは、追加機能を提供することにより標準のJSFコントローラを拡張します。この追加機能には、JSFページ間だけでなく他のアクティビティ（メソッドのコールや他のタスク・フローなど）間の制御も渡す再使用可能なタスク・フローなどがあります。
図6-2は、Fusion Webアプリケーション・アーキテクチャにおける各Oracle ADFモジュールの適合を示しています。
ADF Business Componentsは、ビルトイン・アプリケーション・オブジェクトであり、高性能で機能の豊富なデータベース中心のサービスの提供と維持を迅速化します。サービス指向のJava EEアプリケーションを作成するとき、開発者はコア・ビジネス・ロジックを1つ以上のビジネス・サービスとして実装します。これらのバックエンド・サービスは、適切なビジネス・ルールを施行し、かつ必要に応じてビジネス・データの問合せ、挿入、更新および削除を行う手段をクライアントに提供します。ADF Business Componentsは、Java EEの設計パターンとベスト・プラクティスを即座に実装できるようにします。
Oracle ADF Business Componentsは、データベース中心のビジネス・サービスの作成を簡略化するために次の主要なコンポーネントを提供しています。
エンティティ・オブジェクト
エンティティ・オブジェクトは、データベース表内の1行を表し、すべてのデータ操作言語（DML）操作を処理することでデータ変更を簡略化します。また、ビジネス・ロジックをカプセル化し、ビジネス・ルールが一貫して適用されることを保証します。開発者は、エンティティ・オブジェクトを他のエンティティ・オブジェクトと関連付け、基盤となるデータベース・スキーマの関係を反映することで、複数のアプリケーションで再使用できるビジネス・ドメイン・オブジェクトのレイヤーを作成します。
ビュー・オブジェクト
ビュー・オブジェクトはSQL問合せを表し、その結果の操作を簡略化します。開発者は、SQL言語を使用し、ユーザー・インタフェースで表されるエンド・ユーザーのタスクが必要とする形に、データを結合、計画、フィルタ、ソートおよび集約します。これには、ビュー・オブジェクトを他のエンティティ・オブジェクトにリンクし、複雑度に関係なくマスター/ディテール階層を作成する機能が含まれます。エンド・ユーザーがユーザー・インタフェースでデータを変更すると、ビュー・オブジェクトはエンティティ・オブジェクトと連携し、変更内容が一貫して検証され、保存されます。
アプリケーション・モジュール
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション（サービス・メソッド）を定義します。
Oracle ADF Business Componentsの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
モデル・レイヤーでは、Oracle ADF Modelによって、データ・コントロールと呼ばれるJSR-227サービス抽象化が実装されます。データ・コントロールは標準のメタデータ・インタフェースを使用して、関係のあるプロパティ、メソッドおよびタイプに関する情報など、サービスの操作とデータ・コレクションを記述することで、ビジネス・サービスの実装テクノロジを抽象化します。Oracle JDeveloperでは、開発者はその情報をアイコンとして表示し、ページに簡単にドラッグ・アンド・ドロップできます。開発者がサービス表現をページにドラッグすると、Oracle JDeveloperによって、そのページからサービスへのバインディングが自動的に作成されます。実行時にADF Modelレイヤーによって、アプリケーションのデータ・コントロールおよびデータ・バインディングを記述した情報が該当するXMLファイルから読み取られ、ユーザー・インタフェースとアプリケーションのビジネス・サービス間の双方向接続が実装されます。
Oracle ADFは、最も一般的なビジネス・サービス・テクノロジに対し、すぐに実装可能なデータ・コントロールを提供します。ユーザー・インタフェースの構築にOracle JDeveloperとOracle ADFを併用すると、ドラッグ・アンド・ドロップを使用した宣言的なデータ・バインディングが可能になります。ADF Business Componentsアプリケーション・モジュールのサポートのほかに、ADF Modelは次のサービス・テクノロジに対するサポートも提供します。
Enterprise JavaBeans（EJB）のセッションBeanとJPAエンティティ
JavaBeans
Webサービス
XML
CSVファイル
Oracle ADF Modelの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
Webアプリケーションのページ・フロー処理が主な課題となるコントローラ・レイヤーでは、ADF Controllerは、拡張されたナビゲーションおよび状態管理モデルをJSFに追加する形で提供しています。JDeveloperは、ページ、マネージドBean上のメソッド、宣言的なcase文、他のタスク・フローへのコールなど、様々なタイプのアクティビティの間でアプリケーション制御を管理できるタスク・フローの宣言的な作成をサポートします。
Oracle ADF Controllerの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
ADF Faces Rich Client（略してADF Faces）は、AJAX機能が組み込まれた一連の標準JSFコンポーネントです。AJAXは、非同期JavaScript、動的HTML（DHTML）、XMLおよびXmlHttpRequest通信チャネルを組み合せたものです。この組合せを使用すると、ページを全面的に再レンダリングしないでサーバーにリクエストを送信できます。AJAXでは、リッチ・クライアントのようなアプリケーションが標準のインターネット・テクノロジを使用できますが、JSFにはサーバー側のコントロールが用意されています。これにより、通常のAJAXアプリケーションで頻繁に見られる、大量のJavaScriptへの依存度が下がります。
ADF Facesには、100を超えるリッチ・コンポーネントが含まれています。これには、階層形式のデータ表、ツリー・メニュー、ページ内ダイアログ、アコーディオン、デバイダ、ソート可能な表などがあります。また、ADFデータ視覚化コンポーネントも用意されています。これはFlashやSVGに対応したコンポーネントであり、動的チャート、グラフ、ゲージなどのグラフィックをレンダリングし、基礎となるデータをリアルタイムで表示できます。各コンポーネントはカスタマイズやスキニングに加えて、国際化とアクセシビリティの機能もサポートしています。
これらのフロントエンド機能を実現するために、ADF Facesコンポーネントではレンダリング・キットが使用されます。このレンダリング・キットは、コンポーネントの表示を処理するだけでない、リッチ機能に必要なJavaScriptオブジェクトも提供します。これらは組込みでサポートされているため、開発者は、フロントエンドとバックエンドの個々のテクノロジについて豊富な知識がない場合でも、リッチ・アプリケーションの構築は可能です。
各コンポーネントのアーキテクチャと詳細情報など、ADF Facesの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』を参照してください。
Oracle ADFランタイムは、Oracle JDeveloperインストーラとOracle Fusion Middleware Application Developerインストーラのいずれかを使用してOracle WebLogic Serverにインストールできます。Application Developerインストーラを使用した場合は、Fusion Middleware Controlをオプションでインストールし、ドメイン内の全管理対象サーバーにWebベースの管理サポートを提供することもできます。Oracle JDeveloperインストーラを使用した場合は、Fusion Middleware Controlはインストールされません。これらのオプションは両方とも、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のデプロイメントの章で説明されています。
Application Developerインストーラを使用してOracle ADFランタイムをインストールすると、Middlewareホームの下にOracle Application Developerホーム・ディレクトリ（デフォルトではOracle_APPDEV1）が作成されます。管理者は、ドメイン構成ウィザードを使用し、JRFドメイン・テンプレートに基づいてApplication Developerドメイン（base_domain）を作成すると、サーバーのトポロジを構成できるようになります。通常の設定では、ドメインには、WLS管理コンソールとFusion Middleware Controlを含む管理サーバーが含まれています。通常は、ユーザー向けのカスタムFusion Webアプリケーションのほかに、Oracle ADFランタイムのライブラリ（Javaの必須ファイルの一部）が管理対象サーバーにデプロイされます。カスタマイズ機能およびパーソナライズ機能を提供するために、オプションのMDSリポジトリをインストールすることもできます。これは個別に構成する必要があります。図6-3は、Oracle ADFの基本的な単一ノード・アーキテクチャを示しています。
ドメインとサーバーの詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。
Fusion WebアプリケーションでOracle Metadata Services（MDS）を使用したカスタマイズを行う場合は、アプリケーションをデプロイする前に、MDSリポジトリをOracle WebLogic Serverドメインに登録する必要があります。MDSの登録の詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。
次に、アプリケーションをデプロイすると、JDeveloperでは、ターゲット・メタデータ・リポジトリまたは共有メタデータ・リポジトリを選択するように求められます。ここでは、Oracle WebLogic管理サーバーに登録されているメタデータ・リポジトリのリストから選択できます。
メタデータ・リポジトリの選択が求められるようにするには、アプリケーションのadf-config.xmlファイルのmds-configセクションでcust-config要素を定義する必要があります。この要素は、順序付けされ、名前が付けられたカスタマイズ・クラスのリストを指定します。カスタマイズ・クラスとは、ベース定義メタデータに適用するカスタマイズを定義するためにMDSが使用するインタフェースです。JDeveloperでは、adf-config.xmlファイル用の概要エディタを使用してcust-config要素を定義できます。
MDS用adf-config.xmlファイルの構成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のMDSを使用したカスタマイズの章を参照してください。
MDSのアーキテクチャおよびメタデータ・リポジトリ（データベース・ベースとファイル・ベース）とアーカイブ（EAR、MAR）の詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。
Fusion Webアプリケーションで実行された操作は、アプリケーションが稼働しているWebLogic管理対象サーバーの次のログに直接記録されます。
DOMAIN_HOME/servers/server_name/logs/server_name-diagnostic.log
別のWebLogic管理対象サーバーのログ・ファイルも、Oracle WebLogic Server管理コンソールで使用できます。ログを確認するには、Oracle WebLogic Server管理コンソールhttp://<admin_server_host>:<port>/consoleにアクセスして、「診断-ログ・ファイル」をクリックします。
このログの粒度とロギング・プロパティは、Oracle Enterprise Manager Fusion Middleware Control（Fusion Middleware Control）を使用して変更できます。Fusion Middleware ControlはWebブラウザベースのグラフィカル・ユーザー・インタフェースで、ファームの監視および管理に使用できます。Oracle ADFに関する高可用性警告診断メッセージを受信するには、第6.1.4.3項「Oracle ADFのレプリケーションおよびフェイルオーバーに関する問題のトラブルシューティング」に説明されているように、レベルをFINEに設定してください。
Fusion Webアプリケーションに指定できる診断レベルの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のテストとデバッグの章を参照してください。
Fusion Middleware Controlを使用したWebLogic管理対象サーバーとOracle ADFのログ設定の変更の詳細は、Oracle Fusion Middlewareの管理者ガイドを参照してください。
Oracle ADFテクノロジ・スタック上に構築されるFusion Webアプリケーションは、Java EEアプリケーション（およびJ2EEアプリケーション）です。Fusion Webアプリケーションに対しても、高可用性環境にある他のJava EEアプリケーションと同じようなベスト・プラクティスを実践する必要があります。
バインディング・コンテナやマネージドBeanなどのADFオブジェクトは、実行時にインスタンス化されます。これらの各オブジェクトには、そのスコープ属性によって設定される存続期間が定義されています。
Fusion Webアプリケーションには次の6種類のスコープがあります。
アプリケーション・スコープ: このオブジェクトは、アプリケーションの継続期間中、利用できます。
セッション・スコープ: このオブジェクトは、セッションの継続期間中、利用できます。
ページ・フロー・スコープ: このオブジェクトは、バインド・タスク・フローの継続期間中、利用できます。
リクエスト・スコープ: このオブジェクトは、HTTPリクエストが発生してからレスポンスがクライアントに返送されるまでの間、利用できます。
バッキングBeanスコープ: ページ・フラグメントおよび宣言コンポーネントのみのマネージドBeanに使用されます。このオブジェクトは、HTTPリクエストが発生してからレスポンスがクライアントに返送されるまでの間、利用できます。
ビュー・スコープ: このオブジェクトは、現在のビュー・アクティビティのビューIDが変更されるまで利用できます。このスコープは、所定のページの値を保持するために使用できます。ただし、1つのページから次のページに必要な値を格納するために使用できるリクエスト・スコープとは異なり、ビュー・スコープに格納されたものはビューIDの変更とともに失われます。
Fusion Webアプリケーションをクラスタ環境で実行する場合は、アプリケーションの状態の一部がシリアル化され、各リクエストの終わりに別のサーバーまたはデータ・ストアにコピーされるため、クラスタ内の他のサーバーがこの状態を利用できるようになります。
クラスタ環境で実行するようにアプリケーションを設計している場合は、次の点が必要です。
1つのリクエストより存続期間が長いマネージドBeanがすべてシリアライズ可能である（つまり、java.io.Serializableインタフェースを実装している）ことを確認します。具体的には、セッション・スコープ、ページ・フロー・スコープおよびビュー・スコープに格納されているBeanは、シリアライズ可能である必要があります。
ADFスコープ（ビュー・スコープおよびページ・フロー・スコープ）に格納されているマネージドBeanの変更をOracle ADFが認識していることを確認し、ADFメモリー・スコープに対する変更の追跡を有効にします。
ビュー・スコープとページ・フロー・スコープのいずれかで、マネージドBean内の値が変更された場合には、アプリケーションがOracle ADFに通知して、Beanの新しい値がレプリケートできるようにする必要があります。
例6-1では、ビュー・スコープ内のオブジェクトの属性が変更されます。
例6-1 viewScope内のオブジェクトを変更するコード
Map<String, Object> viewScope =
AdfFacesContext.getCurrentInstance().getViewScope();
MyObject obj = (MyObject)viewScope.get("myObjectName");
Obj.setFoo("newValue");
コードを追加しないかぎり、Oracle ADFではこの変更を認識しないため、新しい値をクラスタ内でレプリケートする必要のあることがわかりません。ADFスコープ内のオブジェクトが変更されているためにレプリケーションが必要であることをOracle ADFに通知するには、例6-2に示すように、markScopeDirty()メソッドを使用します。markScopeDirty()メソッドは、viewScopeおよびpageFlowScopeのみをパラメータとして受け入れます。
例6-2 オブジェクトの変更をOracle ADFに通知するための追加のコード
controllerContext ctx = ControllerContext.getInstance(); ctx.markScopeDirty(viewScope);
このコードは、ADFスコープのいずれかにある既存のオブジェクトを変更するリクエストに対して必要になります。スコープ自体がスコープのput()メソッドremove()またはclear()メソッドによって変更された場合は、Oracle ADFに通知する必要はありません。
ADF ControllerがADFメモリー・スコープに対する変更を追跡し、サーバー・クラスタ内のページ・フロー・スコープおよびビュー・スコープをレプリケートできるようにするには、第6.1.3.3項「adf-config.xmlの構成」に説明されているように、adf-config.xmlファイル内の<adf-scope-ha-support>パラメータを有効にします。
ADFオブジェクト・スコープの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のFusionのページ・ライフサイクルに関する章を参照してください。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内でほかに利用可能なメンバーがリクエストを処理できます。
Fusion Webアプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。
アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できる。
ステートフル・アプリケーションに対し、第6.1.3項「高可用性のためのOracle ADFの構成」の説明に従って、状態のレプリケーションが正しく構成されている。
Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されている。
ハードウェア・ロード・バランサを使用する場合には、ロード・バランサが次のようになっていること。
利用可能なインスタンスすべてに対してトラフィックをルーティングしている
利用できないインスタンスをマークするように、状態モニターで正しく構成されている
セッションの状態の永続性をサポートするように構成されている
環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気がつきません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。
ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。
ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。
ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。
ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。
インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。
インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。
Fusionテクノロジ・スタックにはアクティブ・データ・サービス（ADS）が含まれています。このADSによって、ADF Modelレイヤーを使用してADF Facesコンポーネントをアクティブ・データソースにバインドできます。JDeveloperでは、JSFページ内で個々のコンポーネントを構成し、アクティブ・データを表示します。アクティブ・データを使用するようにコンポーネントを構成すると、データソースによって変更イベントが発生するたびにデータがクライアントにプッシュされます。データはサーバーからクライアントにプッシュされ、ブラウザで表示されます。
アクティブ・データを表示するように構成されているページに対してフェイルオーバーをサポートするには、ADF Business Componentsアプリケーション・モジュールのフェイルオーバーを有効にし、ADF ControllerがADFメモリー・スコープへの変更を追跡できるようにする必要があります。これらのADF設定を構成すると、フェイルオーバーの発生時にADFサーバーがフェイルオーバーを検出し、アクティブ・データを表示するように構成されているすべてのページに対し、ページをリフレッシュするように要求します。その後でADSが再起動し、データがクライアントにプッシュされます。
Fusion Webアプリケーションのフェイルオーバーを有効にする方法の詳細は、第6.1.3項「高可用性のためのOracle ADFの構成」を参照してください。
Oracle ADF Facesコンポーネントでのアクティブ・データ・サービスの使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のADSに関する章を参照してください。
冗長なデータベースやバックエンドとしてのOracle Real Application Clusters（Oracle RAC）など、可用性の高いデータベース・システムにアクセスするようにADFアプリケーション・モジュールを構成するときは、データソースのコンテナが定義されている必要があります。このシナリオでは、マルチ・データソースを使用する必要があります。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データソースと非マルチ・データソースでネーミング規則は同じになります。これによって、正しいデータソースが実行時に使用されるようになります。高可用性アプリケーションに対するマルチ・データソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データソースの構成」を参照してください。
クラスタ環境内のWebアプリケーションに対して自動的なレプリケーションとフェイルオーバーをサポートするために、Oracle WebLogic Serverは、クラスタ間でHTTPセッションの状態をレプリケートするメカニズムをサポートしています。Fusion Webアプリケーションの状態をクラスタ内のどのサーバーからでもリストアできるようにOracle ADFを構成できます。
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション（サービス・メソッド）を定義します。アプリケーション・モジュールは、そのトランザクション状態をスナップショットとしてデータベースに格納することをサポートしています。また、これらの保存済スナップショットのいずれかからトランザクション状態をアクティブ化する逆の操作もサポートしています。
ADF Business Componentsのフェイルオーバーのサポートを有効にするには、jbo.dofailoverパラメータをtrueに設定し、アプリケーション・モジュールの状態が解放時に保存されるようにします。これによって、Oracle ADFは、前のチェックインで保存されたスナップショットからアプリケーション・モジュールの状態をリストアできるようになります。一方、フェイルオーバー機能がデフォルトにより無効のままになっている場合は、アプリケーションが後続のユーザー・セッションで再利用されたときと、アプリケーション・モジュール・プールが未使用のアプリケーション・モジュールを見つけられないときにのみ、アプリケーション・モジュールの状態が保存されます。
アプリケーション・モジュールの構成でこのパラメータを設定するには、「ビジネス・コンポーネント構成の編集」ダイアログの「プーリングおよびスケーラビリティ」タブを使用します。
高可用性のためのアプリケーション・モジュールを構成する手順は次のとおりです。
JDeveloperを起動してアプリケーションを開きます。
アプリケーション・ナビゲータで、データ・モデルを含むプロジェクトを展開し、アプリケーション・モジュールを探します。
アプリケーション・モジュールを右クリックし、「構成」を選択します。
「編集」をクリックします。
「プーリングおよびスケーラビリティ」タブをクリックします。
「管理された解放時にトランザクションの状態をフェイルオーバー」チェック・ボックスを選択します。
「OK」をクリックして「ビジネス・コンポーネント構成の編集」ダイアログを閉じます。
「OK」をクリックして「構成の管理」ダイアログを閉じます。
Oracle ADFの状態管理機能とその使用方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーションの状態管理に関する章を参照してください。
HTTPセッションの状態のレプリケートをサポートできるようにするには、Oracle WLS weblogic.xmlファイルのpersistent-store-type要素に値を割り当てる必要があります。replicated_if_clusteredの値により、有効な永続ストアのタイプがレプリケートされ、このサーバーの属するサーバーのクラスタに対して設定された値に従って、クラスタ環境のセッションが格納されるようになります。
高可用性を実現するためにweblogic.xmlファイルを構成する手順は次のとおりです。
JDeveloperを起動してアプリケーションを開きます。
アプリケーション・ナビゲータで、Webアプリケーションを含むプロジェクトを展開し、WEB-INFフォルダを展開します。
weblogic.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。
ファイル内で、persistent-store-typeの定義をsession-descriptor要素に追加します。
<weblogic-web-app>
<session-descriptor>
<persistent-store-type>
replicated_if_clustered
</persistent-store-type>
</session-descriptor>
</weblogic-web-app>
クラスタ環境で実行するアプリケーションを設計している場合は、ADFスコープ（ビュー・スコープおよびページ・フロー・スコープ）に格納されているマネージドBeanの変更をOracle ADFが認識していることを確認する必要があります。
ビュー・スコープとページ・フロー・スコープのいずれかで、マネージドBean内の値が変更された場合には、アプリケーションがOracle ADFに通知して、Beanの新しい値がレプリケートできるようにする必要があります。
ADF ControllerがADFメモリー・スコープに対する変更を追跡し、サーバー・クラスタ内のページ・フロー・スコープおよびビュー・スコープをレプリケートできるようにするには、アプリケーションのadf-config.xmlファイル内のADF Controllerパラメータ<adf-scope-ha-support>をtrueに設定する必要があります。たとえば、アプリケーションにtrueを設定した場合、そのアプリケーションがリクエスト中にページ・フロー・スコープでBeanの追加または削除を行うと、変更がクラスタ内で自動的にレプリケートされます。
adf-config.xmlは、すべてのADFコンポーネントの中核となる構成ファイルです。このファイルには、ADF ControllerなどのADFコンポーネントの実行時の動作を構成するためのセクションが含まれています。
高可用性を実現するためにadf-config.xmlファイルを構成する手順は次のとおりです。
JDeveloperを起動してアプリケーションを開きます。
アプリケーション・ナビゲータで、「アプリケーション・リソース」を展開します。
「ディスクリプタ」を選択し、「ADF META-INF」ノードを選択します。
adf-config.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。
このファイルに次の行を追加します。
<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config"> <adf-scope-ha-support>true</adf-scope-ha-support> </adf-controller-config>
adf-config.xmlファイルを使用したADFの構成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の複雑なタスク・フローの作成に関する章を参照してください。
この項では、Oracle ADFで発生する可能性のある問題のトラブルシューティング手順について説明します。
Fusion WebアプリケーションをOracle JDeveloperで開発する場合は、この統合開発環境によって、高可用性に関する問題を検出するためのサポートが提供されます。JDeveloperが発する警告は監査フレームワークによって生成され、JDeveloperのソース・エディタに表示するようにトリガーされます。エディタに表示される警告は、高可用性アプリケーションの監査ルールに基づきます。
JDeveloperがデフォルトにより有効にする高可用性監査ルールは次のとおりです。
「ADF Controller構成 - ADFスコープの高可用性が有効になっていません」は、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されていないことを警告するのみです。この監査ルールは、<adf-controller-config>要素がADFアプリケーションレベルの構成ファイル（adf-config.xml）に存在する場合にのみ適用されます。
「ADFページ・フロー - EL Beanが変更されました」は、クラスがBeanでsetterメソッドを呼び出して、（ControllerContext.markScopeDirty()メソッドを使用して）スコープを使用済としてマークする必要があることを示すときに開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。
「ADFページ・フロー - マネージドBeanクラスはシリアライズ不可」は、マネージドBeanのviewScope、pageFlowScopeまたはsessionScopeに、シリアライズ不可のクラスが定義されていることを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。
高可用性監査ルール設定は、JDeveloperの「設定」ダイアログを使用して変更できます。JDeveloperのツールバーで「ツール - 設定」を選択し、「監査 - プロファイル」の下にある「ADF Controller構成」または「ADFページ・フロー」を展開して、目的の監査ルールを選択します。
JDeveloperのツールバーで「ビルド - 監査 project.jpr」を選択して監査をトリガーすることもできます。
Fusion Webアプリケーションは、管理対象サーバーが最初に起動したときにデプロイされます。最初にOracle WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメントがすべて成功したことを確認します。
左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。
アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME/servers/server_name/logsディレクトリに格納されています。一般的な問題には、次のようなものがあります。
データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。
適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。
フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります。
ウィンドウが閉じたか、または状態がリセットされた可能性がある。
画面のリセットが必要になった可能性がある。
アプリケーションがログオン画面にリダイレクトしている可能性がある。
次の手順は、状態のレプリケーションに関する問題のトラブルシューティングおよび診断を行う際のガイダンスです。
これがレプリケーションに関する既知の問題でないことを確認します。
予想される動作については、第6.1.2.2項「Oracle ADFのフェイルオーバーおよび予想される動作」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。
ロード・バランサの設定を確認します。
レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverのハードウェア・ロード・バランサの構成の詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。
クラスタのステータスを確認します。
クラスタのコンテキスト内でレプリケーションが発生します。フェイルオーバーが成功するには、クラスタの正常なメンバーが、ほかに少なくとも1つ使用可能である必要があります。クラスタのステータスは、次の2種類の方法のどちらかで確認できます。
Oracle WebLogic Server管理コンソールを使用してクラスタのステータスを確認します。左側のペインで「サーバー」をクリックします。クラスタ内のすべてのサーバーの状態を確認します。
weblogic.Adminユーティリティを使用してクラスタのステータスを確認します。weblogic.Adminコマンドは、特定のクラスタ内のすべてのサーバーの状態を問い合せるときに使用できます。次に例を示します。
$ java weblogic.Admin -url Adminhost:7001 -username <username> -password <password> CLUSTERSTATE -clustername Spaces_Cluster
次のようなメッセージが返されます。
There are 2 server(s) in cluster: Spaces_Cluster The alive servers and their respective states are listed below: Application Server---RUNNING Managed Server---RUNNING
クラスタ通信を確認します。
クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。
ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。
個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。
マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTestを実行して、マルチキャストが正しく構成されていることを確認します。次に例を示します。
$ java utils.MulticastTest -H
Oracle WLSのアプリケーション構成を確認します。
Oracle WLSは、デフォルトではフェイルオーバーするように構成されていません。メモリー内のレプリケーションは、weblogic.xmlファイルに次の適切な設定が含まれている場合にのみ行われます。
<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
replicatedのpersistent-store-typeも受け入れられます。この設定は、第6.1.3.2項「weblogic.xmlの構成」で説明されているように、JDeveloperで行うことができます。
Oracle ADF Business Componentsの構成を確認します。
Oracle ADFは、デフォルトではフェイルオーバーするように構成されていません。フェイルオーバーは、ADF Business Componentsの構成ファイル（bc4j.xml）に次の適切な設定が含まれている場合にのみサポートされます。
<AppModuleConfig ... <AM-Pooling jbo.dofailover="true"/> </AppModuleConfig>
この設定は、第6.1.3.1項「アプリケーション・モジュールの構成」で説明されているように、JDeveloperの「ビジネス・コンポーネント構成の編集」ダイアログで行います。
Oracle ADF Controllerの構成を確認します。
Oracle ADFは、デフォルトでは、ADFオブジェクトに対する変更をADFメモリー・スコープ内にレプリケートするように構成されていません。ADFオブジェクトのレプリケーションは、ADFアプリケーション・レベルの構成ファイル（adf-config.xml）に次の適切な設定が含まれている場合にのみサポートされます。
<adfc:adf-controller-config> <adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support> </adfc:adf-controller-config>
この設定は、第6.1.3.3項「adf-config.xmlの構成」で説明されているように、JDeveloperのソース・エディタで行います。
デフォルトのログ出力メッセージを確認します。
デフォルトでは、ADFのログには上位レベルのメッセージ（INFOレベル）が表示されます。デフォルトのログ出力では、さらに詳細なログ・メッセージを有効にする必要なしに、シリアライズやレプリケーションに関する問題を報告することがよくあります。ログの詳細は、第6.1.1.4項「Oracle ADFのログ・ファイル」を参照してください。
ADF高可用性アプリケーションのログ・メッセージを有効にします。
ADFのログ出力を、高可用性のランタイム・メッセージを出力するように構成します。デフォルトでは、ADFのログには上位レベルのメッセージ（INFOレベル）が表示されます。Fusion Middleware Controlでロギング・レベルをFINEに設定して、ADF Controllerの高可用性の診断を有効にします。
有効にすると、adf-config.xmlファイルにadfc:adf-scope-ha-supportが設定されていない場合に、ログ出力が警告を出力するようになります。ADFのログ出力の詳細は、第6.1.1.4項「Oracle ADFのログ・ファイル」を参照してください。
デバッグを有効にします。
サーバー・ログを調べて、管理対象サーバーの起動時に異常なメッセージがないか確認します。この確認は、管理対象サーバーがクラスタの他のメンバーを見つけられない場合に、特に必要です。サーバー・ログは、DOMAIN_HOME/servers/{SERVER_NAME}/logsディレクトリに格納されています。
詳細な診断を行うには、DebugCluster、DebugClusterAnnouncements、DebugFailOver、DebugReplication、DebugReplicationDetailsの各フラグを有効にします。各フラグは、weblogic.Adminユーティリティを使用して次のように有効にできます。
$ java weblogic.Admin -url Adminhost:7001 -username <username> -password <password> SET -type ServerDebug -property DebugCluster true
コンポーネントの状態のシリアライズ・チェックを有効にします。
サーバーのチェックを有効にして、セッション属性でシリアライズ不能な状態コンテンツが検出されないようにします。このチェックは、デフォルトでは、実行時のオーバーヘッドを軽減するために無効になっています。シリアライズ・チェックは、Javaサーバーのシステム・プロパティorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATIONによってサポートされます。
高可用性をテストするには、まず次のシステム・プロパティを使用してアプリケーション・サーバーを起動し、セッションおよびJSFの状態がシリアライズ可能であることを確認します。
-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree
JSFの状態がシリアライズ不能であることが検出された場合は、次のシステム・プロパティを使用してアプリケーション・サーバーを再起動し、コンポーネントとプロパティのフラグを有効にしてからテストを再実行します。
-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all
この項では、サンプルとして示したOracle ADFの高可用性デプロイメントを構成する方法について説明します。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
次のリストは、この項で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middleware SOA Suiteがインストールされている場所を指します。
DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報（構成アーティファクト）が格納されている場所を指します。
ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどのシステム・コンポーネントが1つ以上含まれています。Oracleインスタンス・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルが格納されています。
このディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。
ORACLE_BASE: /u01/app/oracle
MW_HOME（アプリケーション層）: ORACLE_BASE/product/fmw
WLS_HOME: MW_HOME/wlserver_10.3
ORACLE_HOME: MW_HOME/adf
この手順は、Oracle Fusion Middlewareの一部であるスキーマのいずれかをADFアプリケーションで使用する必要がある場合にのみ必要になります。 これは通常、ADFアプリケーションがMDSリポジトリを使用する場合に行います。その場合は、Oracle Fusion Middlewareをインストールする前に、11g（11.1.1）Oracle Fusion Middlewareメタデータ・ストアをReal Application Clusters（RAC）データベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ（RCU）が用意されています。RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。
次のコマンドを使用してRCUを起動します。
RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
データベース・タイプ: Oracle Databaseを選択します。
ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します: ADFDBHOST1VIRTUAL
ポート: データベースのポート番号: 1521
サービス名: データベースのサービス名を入力します: adfha.mycompany.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワードを入力します。
ロール: SYSDBA
「次へ」をクリックします。
次のメッセージを受信した場合は、「無視」または「停止」をクリックします。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、ADFHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。
次のスキーマを選択します。
AS共通スキーマ
Metadata Services
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加（補助）のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。
サーバーが次の要件を満たしていることを確認します。
システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』で指定されている要件を満たしています。
この例ではポート7777を使用します。ポート7777を選択する場合には、ノード上のいずれのサービスでもこのポートが使用されていないことを確認します。このことを確認するには、次のコマンドを実行します。
UNIX: netstat -an | grep 7777 Windows: netstat -an | findstr 7777
ポート7777が使用中の場合には、別のポートを選択するか、またはこのポートを使用可能にします。
UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle Fusion Middleware 11g Webtier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンド./runInstallerを実行します。
Windowsでは、setup.exeをダブルクリックします。
「インベントリ・ディレクトリの指定」画面で、インベントリおよびユーザー・グループの場所を入力して「OK」をクリックします。
ダイアログに従ってrootの特権アクションを実行し、「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、場所を次のように設定します。
/u01/app/oracle/product/11.1.1/ohs_1
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。
「次へ」をクリックします。
「コンポーネント詳細の指定」画面で、次の値を入力します。
インスタンス・ホームの場所:
/u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1
インスタンス名: ohs_instance1
OHSコンポーネント名: ohs1
「次へ」をクリックします。
「Web Tierポートの詳細の指定」画面で、次の操作を行います。
「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
Oracle HTTP Serverのポート番号を入力します。たとえば、7777と入力します。
「次へ」をクリックします。
|
注意: ポートの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』を参照してください。 |
「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。
「インストールの進行状況」画面で、次の操作を行います。
UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。
「構成が完了しました」画面で、「終了」をクリックして終了します。
次の各項に記載されている情報を使用して、Oracle Fusion Middlewareコンポーネントをインストールします。
アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。
UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle WebLogic Serverインストーラを起動します。
On UNIX (Linux used in this example): APPHOST1> server103_linux32.bin On Windows: APPHOST1> server103_win32.exe
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
ORACLE_BASE/product/fmw
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「JDKの選択」画面で、「JROCKIT SDK1.6.0_05」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
ORACLE_BASE/product/fmw/wlserver_10.3
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。
Oracle Fusion MiddlewareのOracle ADFをインストールするには、Application Developerインストーラを使用し、アプリケーション層にあるすべてのノードで次の操作を行います。
Oracle Fusion MiddlewareのOracle Fusion Middleware 11g Application Developerインストーラを起動します。
On UNIX (Linux used in this example): APPHOST1> runInstaller On Windows: APPHOST1> setup.exe
Oracle Fusion Middleware 11g Application Developerインストーラで、JRE/JDKの場所を入力するように求められたら、第6.2.4.1項「Oracle WebLogic Serverのインストール」のOracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します。次に例を示します。
ORACLE_BASE/product/fmw/jrockit_160_05_R27.6.2-20
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
「ミドルウェア・ホーム」には、ORACLE_BASE/product/fmwと入力します。
「Oracleホーム・ディレクトリ」には、たとえばadfのように、使用するディレクトリを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール 完了」画面で「終了」をクリックします。
Oracle WebLogic Server管理サーバーの構成の詳細は、第10章「Oracle Fusion Middleware高可用性のアクティブ/パッシブ・トポロジ」を参照してください。
MiddlewareホームのadfディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracleコンポーネントが格納されるドメインを作成します。
次のコマンドを使用して、MW_HOME/common/binディレクトリからOracle WebLogic Serverの構成ウィザードを起動します。
APPHOST1> ./config.sh
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。
Oracle Enterprise Manager - 11.1.1.0
Oracle JRF - 11.1.1.0
「次へ」をクリックします。
「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択
JDKの選択: 「JROCKIT SDK1.6.0_05」を選択
「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「次へ」をクリックします。
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: APPHOST1
リスニング・ポート: 7001
SSLリスニング・ポート: NA
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。
| 管理対象サーバー名 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
| WLS_ADF1 | APPHOST1のホスト名 | 8889 | NA | 選択を解除 |
| WLS_ADF2 | APPHOST2のホスト名 | 8889 | NA | 選択を解除 |
「次へ」をクリックします。
「クラスタの構成」画面で、次のクラスタを追加します。
名前: ADF_CLUSTER
クラスタ・メッセージング・モード: unicast
クラスタ・アドレス有効化: 空白のまま
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、クラスタに次のサーバーを割り当てます。
ADF_CLUSTER:
WLS_ADF1
WLS_ADF2
「次へ」をクリックします。
「マシンの構成」画面で、次の操作を行います。
デフォルトで表示されるLocalMachineを削除します。
「UNIXマシン」タブをクリックし、次のマシンを追加します。
| 名前 | ノード・マネージャのリスニング・アドレス |
|---|---|
| APPHOST1 | APPHOST1のホスト名 |
| APPHOST2 | APPHOST2のホスト名 |
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。
APPHOST1: AdminServer、WLS_ADF1
APPHOST2: WLS_ADF2
「構成のサマリ」画面で「作成」をクリックします。
「ドメインの作成中」画面で「完了」をクリックします。
この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーおよび管理対象サーバーに対してboot.propertiesファイルを作成します。
管理サーバーに対しては、次の手順を実行します。
次のディレクトリを作成します。
APPHOST1> mkdir -p MW_HOME/wls/user_projects/domains/adfdomain/servers/AdminServer/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。
username=adminUserpassword=adminUserPassword
次に例を示します。
username=weblogic password=weblogic
|
注意: 管理サーバーまたは管理対象サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
WLS_ADF管理対象サーバーに対しては、次の手順を実行します。
管理サーバーに対して作成したファイルをすべてのサーバーにコピーします。
APPHOST1> mkdir -p servers/WLS_ADF1 APPHOST1> mkdir -p servers/WLS_ADF1/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。
username=adminUserpassword=adminUserPassword
次に例を示します。
username=weblogic password=weblogic
この項では、APPHOST1でシステムを起動する手順について説明します。
APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。
APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/bin
APPHOST1> ./startWebLogic.sh
管理サーバーが適切に構成されていることを確認する手順は次のとおりです。
Webブラウザでhttp://VIP1:7001/consoleにアクセスします。
管理者としてログインします。
管理対象サーバーとしてWLS_ADF1およびWLS_ADF2が表示されていることを確認します。
ADF_Clusterクラスタが表示されていることを確認します。
Enterprise Manager（http://VIP1:7001/em）にアクセスできることを確認します。
この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。
ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。
APPHOST1でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「管理サーバー」→「SSL」→「詳細」を選択します。
「ロックして編集」をクリックします。
プロンプトが表示されたら、変更内容を保存してアクティブ化します。
「ホスト名の検証」を「なし」に設定します。
「WLS_ADF1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
APPHOST2でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「WLS_ADF2」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
APPHOST1でノード・マネージャを起動するには、次の手順を実行します。
ノード・マネージャを起動する前に、ORACLE_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
OAHOST1> cd ORACLE_HOME/common/bin SOAHOST1> ./setNMProps.sh
|
注意: クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。 |
ノード・マネージャを起動します。
APPHOST1> cd ORACLE_BASE/product/fmw/wlserver_10.3/server/bin
APPHOST1> ./startNodeManager.sh
APPHOST2に対し、WebLogic ServerとOracle ADFのインストール手順を繰り返します。第6.2.3項「WEBHOST1へのOracle HTTP Serverのインストール」の手順から始めてください。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。
次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST2に伝播します。
次のpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cdORACLE_BASE/product/fmw/wlserver_10.3/common/bin APPHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/ -template=adfdomaintemplate.jar -template_name=adf_domain_template
次のscpコマンドをAPPHOST1で実行し、前の手順で作成したテンプレート・ファイルをAPPHOST2にコピーします。
APPHOST1> scp adfdomaintemplate.jaruser@node2:ORACLE_BASE/product/fmw/wlserver_10.3/common/bin
unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。
APPHOST2> cdORACLE_BASE/product/fmw/wlserver_10.3/common/bin APPHOST2> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/ -template=adfdomaintemplate.jar
次の手順に従い、APPHOST2上の管理サーバーと管理対象サーバーに対してboot.propertiesファイルを作成します。
次のディレクトリを作成します。
APPHOST1> mkdir -pMW_HOME/wls/user_projects/domains/adfdomain/servers/WLS_ADF2 APPHOST2> mkdir -pMW_HOME/wls/user_projects/domains/adfdomain/servers/WLS_ADF2/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。
username=adminUserpassword=adminUserPassword
次に例を示します。
username=weblogic password=weblogic
|
注意: 管理サーバーまたは管理対象サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
APPHOST2でノード・マネージャを起動するには、第6.2.7.4項「APPHOST1でのノード・マネージャの起動」の手順をAPPHOST2で繰り返します。
この項の手順を使用して、アプリケーションのレプリケーションを構成します。
クラスタリング要件
アプリケーションをOracle WebLogicクラスタにデプロイする必要があります。これによって、アプリケーションの複数インスタンスに、レプリケーション・チャネルが自動的に確立されます。
|
注意: ユニキャスト・クラスタでは、デフォルトのレプリケーション・チャネルは、各管理対象サーバーのリスニング・アドレスを使用して構成されています。そのため、リスニング・アドレスは、Anyでリスニングするように構成するのではなく、特定のIPアドレスまたはホスト名となるように構成する必要があります。 |
Oracle ADFのレプリケーション
Oracle ADFが適切に構成されていることが重要です。ステートフル・アプリケーションの場合には、アプリケーション・リソースの1つであるadf-config.xmlファイルに、次のタグが存在している必要があります。
<adfc:adf-controller-config><adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support></adfc:adf-controller-config>
アプリケーションでは、レプリケーションも有効化されている必要があります。Oracle WebLogic Serverでは、レプリケーションのために様々な種類の永続ストアを使用できます。永続ストアの詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。
ADFアプリケーションのレプリケーションをデフォルトで有効にするには、weblogic.xmlファイルで次の設定を行います。
<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
replicated_if_clustered設定は、スタンドアロン・アプリケーション環境のレプリケーションを無効にし、クラスタ環境内のメモリー内レプリケーションを使用します。
メモリー内レプリケーションに任意のカスタム・アプリケーションが構成されていることを確認します。
クラスタを設定すると、ADFアプリケーションをデプロイできるようになります。次の点に注意してください。
管理サーバー・コンソールを使用して、ADFアプリケーションをEARファイルにデプロイします。
デプロイメントがクラスタに対して行われるようにします。
アプリケーションがMDSを使用する場合は、Oracle Fusion Middlewareの管理者ガイドのデータベース・ベースのMDSリポジトリの登録に関する項の指示に従って、MDSをドメインに登録します。
Oracle WebCenter管理対象サーバーを含む管理サーバーへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定します。次の手順を実行します。
OHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。
# Spaces
<Location /applicationMountpoint>
WebLogicCluster apphost1.com:8888,apphost2.com:8889
SetHandler weblogic-handler
</Location>
WEBHOST1上のOracle HTTP Serverを再起動します。
WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1
URLを検証し、HTTP ServerからOracle WebCenterクラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。次の手順を実行します。
WebLogic Server管理コンソールから、WLS_Spaces1、WLS_Spaces2、WLS_Portlet1およびWLS_Portlet2を次のように起動します。
次のURLの管理コンソールにアクセスします。
http://APPHOST1/console
管理対象サーバーのいずれか（例: WLS_Spaces1）をクリックします。
「制御」タブを選択します。
「起動」を選択して管理対象サーバーを起動します。
管理対象サーバーごとに前の手順を繰り返します。
次のURLを使用して、管理対象サーバーへの直接アクセスを検証します。
apphost1:8888/applicationMountpoint apphost2:8888/applicationMountpoint apphost1:8889/applicationMountpoint apphost2:8889/applicationMountpoint
WLS_ADF2の稼働中に、Oracle WebLogic Server管理コンソールからWLS_ADF1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/applicationMountpoint
WebLogic Server管理コンソールからWLS_ADF1を起動します。
WLS_ADF2を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost2:7777/applicationMountpoint
この項では、Oracle WebCenterの高可用性クラスタを設計するために必要な課題および考慮事項を紹介します。
Oracle WebCenterは、Java Server Faces（JSF）の標準ベースの宣言的な開発と、ポータルの柔軟性と能力、および一連の統合型Web 2.0サービスを組み合せたものです。
図6-4は、Oracle WebCenterアプリケーションとそれに関連するコンポーネント、ポートレットおよびサービスを示しています。
Oracle WebCenterのコンポーネントは次のとおりです。
Oracle WebCenter Spacesは、一連の堅牢なサービスとアプリケーションにより、ソーシャル・ネットワーキング、通信、コラボレーションおよび個人の生産性に対して、単一の統合されたWebベース環境を提供します。
WebCenter Spacesは、JSF、Oracle ADF、WebCenter Framework、WebCenter Web 2.0サービスおよびコンポーザを使用して構築されています。Oracle WebCenter Spacesは次の機能を提供します。
ビジネス・ユーザーをターゲットとし、コミュニティに焦点を当てたブラウザベースのアプリケーション
電子メールやメモなど、個人の生産性ツールを提供する環境である個人用スペース
機能の豊富なチーム・コラボレーション・プラットフォームであるグループ・スペース
スレッド・ディスカッション、ブログ、Wiki、ワークリスト、お知らせ、RSS、最近のアクティビティ、および検索
Oracle WebCenter Portlets Frameworkは、標準ベースのポートレット（JSR 168、WSRP 1.0および2.0）と従来のOracle PDK-Javaベースのポートレット両方のデプロイメントと実行をサポートしています。Oracle WebCenterには、OmniPortlet、Webクリッピング、リッチ・テキスト・ポートレット、WSRPツールなど、すぐに使用可能なプロデューサがいくつか用意されています。
Oracle WebCenter Frameworkの機能は次のとおりです。
再デプロイを必要としないアプリケーションの即時変更を可能にするランタイム・カスタマイズ
JSR-168標準ベースのWSRPポートレットおよびPDK-Javaポートレットのサポート
Oracle Content Server、ファイル・システム、Oracle Portal、Documentum、Sharepoint、Lotusなど、JCR（JSR170）を使用したコンテンツの統合
JSFページおよびOracle ADFタスク・フローを標準ベースのポートレットとして表示できるようにするJSFポートレット・ブリッジ
Oracle WebCenterディスカッション・サーバーは、ディスカッション・フォーラムやお知らせをアプリケーションに統合する機能を提供します。
Oracle WebCenter Wiki and Blogサーバーは、Wikiおよびブログをアプリケーションに統合する機能を提供します。また、アプリケーション・ユーザーが独自のWikiやブログを作成するための機能もサポートしています。
Oracle WebCenter SpacesおよびWebCenterカスタム・アプリケーションは、次のWebCenter Web 2.0ソーシャル・ネットワーキング・サービスおよび個人の生産性サービスと統合することもできます。
インスタント・メッセージおよびプレゼンス（IMP）: 他の認証済ユーザーのステータス（オンライン、オフライン、ビジー、アイドルのいずれか）を観察し、これらのユーザーにすぐ連絡する機能を提供します。
お知らせ: 重要なアクティビティやイベントに関するお知らせを、認証済ユーザー全員に投稿する機能を提供します。
Wiki: 地理的に分散したチームがWebドキュメントを作成して共同作業する機能を提供します。
ブログ: 重要なアクティビティやイベントに関するお知らせを、認証済ユーザー全員に投稿する機能を提供します。
ディスカッション: スレッド・ディスカッションの作成、質問の投稿と回答、および回答の検索を行う機能を提供します。重要なアクティビティやイベントに関して、グループが効果的に通信するためのメカニズムも提供します。
メール: IMAPメール・サーバーやSMTPメール・サーバーと簡単に統合することで、メッセージの表示、読取り、作成および削除、ファイル添付メッセージの作成、既存のメッセージへの応答または転送などの単純なメール機能を、ユーザーが実行できるようにします。
ワークリスト: 注意を喚起する必要のあるビジネス・プロセスが一目でわかる個人的なビューを提供します。これらのプロセスには、ドキュメント・レビューのリクエストなど、エンタープライズ・アプリケーションから直接もたらされる種類のビジネス・プロセスが含まれます。
最近のアクティビティ:- ドキュメント、ディスカッションおよびお知らせに対する最近の変更のサマリー・ビューを提供します。
メモ: Oracle WebCenter Spacesで使用可能なメモ・サービスは、個人的に関係のある情報の一部を書き留めて保持する機能を提供します。
検索: タグ、サービス、アプリケーションまたはサイト全体を検索する機能を提供します。これには、WebCenter検索用にOracle Secure Enterprise Searchを統合することが含まれています。
RSS: ニュース・リーダーという1つの場所から多くの異なるWebサイトのコンテンツにアクセスする機能を提供します。
タグ: 任意のページまたはドキュメントに、個人的に関係のある1つ以上のキーワードを割り当てる機能を提供します。
ドキュメント: コンテンツのアップロード、ファイルおよびフォルダの作成と管理、ファイルのチェックアウト、バージョニングなど、コンテンツ管理機能および記憶域機能を提供します。
リスト: Oracle WebCenter Spacesで使用可能なリスト・サービスは、リストや表を作成、公開および管理する機能を提供します。ユーザーはビルトイン構造からリストを作成するか、または独自のカスタム・リストを作成できます。
リンク: 関連情報の表示、アクセスおよび関連付けを行なう機能を提供します。たとえば、ディスカッション・スレッドからソリューション・ドキュメントにリンクできます。
イベント: WebCenter Spacesで使用可能なイベント・サービスは、広範なユーザーのグループに関連するイベントのスケジュールを作成および保持する機能を提供します。イベントは、認証済ユーザー全員に公開されます。
これらのWebCenter Web 2.0のソーシャル・ネットワーキング・サービスおよび個人の生産性サービスの構成方法の詳細は、『Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter』を参照してください。
Oracle WebCenterをインストールすると、Middlewareホーム・ディレクトリの下にWebCenterディレクトリが作成されます。このインストールによって、WebCenterドメイン（wc_domain）が作成されます。このドメインには、管理サーバー、および3つのWebLogic管理対象サーバーである、WLS_Spaces（Oracle WebCenter Spacesをホスト）、WLS_Portlets（Oracle WebCenter Portletsをホスト）およびWLS_Services（Oracle WebCenterディスカッション・サーバー、Oracle WebCenter Wiki and Blogサーバー、および統合する追加のWebCenter Web 2.0サービスをホスト）が格納されます。
オプションの4番目の管理対象サーバー（アプリケーション・サーバー）は、WebCenterのカスタム・アプリケーションを実行するために使用できます。通常は、Webcenterカスタム・アプリケーションにカスタム管理対象サーバーが1つずつ存在します。追加の管理対象サーバーを作成すると、適切なライブラリがプロビジョニングされ、Oracle WebCenter Spacesと同じ外部リソースを利用できるようになります。管理対象サーバーの詳細は、Oracle Fusion Middlewareの管理者ガイドのOracle Fusion Middlewareの概要の理解に関する項を参照してください。図6-5は、Oracle WebCenterの基本的な単一ノード・アーキテクチャを示しています。
Oracle WebCenter SpacesはJava EEアプリケーションとして実行され、アプリケーションの状態と構成はMDSリポジトリに永続的に残ります。アプリケーション内のユーザー・セッション情報は、ローカルのメモリー内に保持されます。クラスタ環境では、この状態はクラスタの他のメンバーにレプリケートされます。
ポートレット環境またはサービス環境内のカスタマイズは、そのサービスによって永続的に残ります。Oracleポートレットおよびユーザーが構築するカスタム・ポートレット、ディスカッション・サーバーおよびWikiサーバーをすぐに利用できます。これらにはいずれも、独自のデータベース永続性メカニズムが備わっています。
表6-1は、WebCenterのコンポーネントおよびサービスそれぞれのアクセス・タイプを示しています。「構成」列には、接続を構成または初期化するためにOracle WebCenterに提供されている情報のタイプが一覧表示されています。「アクセス」列には、サービスのランタイム・アクセスで使用するプロトコルが一覧表示されています。
ディスカッション・サーバーとWiki/ブログ・サーバーも、Oracle WebCenterに対するサービス・プロバイダです。Oracleポートレットも、サービスとしてポートレット・プロデューサを公開します。
これらのサービスが使用できなくてもOracle WebCenter Spacesアプリケーションが起動できなくなることはありませんが、実行中にアプリケーション・エラーが発生する場合があります。例外は、MDSリポジトリです。WebCenter Spacesは、MDSリポジトリがないと動作しません。WebCenterデータベースがMDSリポジトリとは異なる物理データベースである場合は、WebCenterデータベースがなくてもWebCenter Spacesは部分的に動作します。
表6-1 Oracle WebCenterのアクセス・タイプ
| サービス | 構成 | アクセス |
|---|---|---|
|
ディスカッション・サーバー |
ディスカッション・サーバー管理へのHTTPアクセス |
SOAP/HTTP |
|
Wiki/ブログ・サーバー |
Wikiサーバー管理へのHTTPアクセス |
SOAP/HTTP |
|
プレゼンス・サーバー |
プレゼンス・サーバーへのHTTPアクセス |
SOAP/HTTP |
|
Oracle Content Server |
管理サーバーへのソケット接続。HTTPアクセスが必要になるのは、WebCenterの外にあるコンテンツ・サーバーにアクセスする必要がある場合のみです。 |
ソケットを使用したJCR 1.0、またはHTTP |
|
MDSリポジトリとスキーマ |
JDBC |
JDBC |
|
検索 |
検索サーバーへのHTTPアクセス |
HTTP |
|
メール・サーバー |
IMAP/SMTPサーバー |
IMAP/SMTP |
|
ワークリスト |
BPELサーバーへのHTTPアクセス |
SOAP/HTTP |
|
ポートレット |
プロバイダWSDLのHTTP場所 |
SOAP/HTTP |
各外部サービスの高可用性は個別に構成します。Oracle WebCenterのフレームワークは、外部サービスに対してアクセス・ポイントを1つのみ提供します。
たとえば、HTTPサービスに対するアクセスURLは、ロード・バランサにダイレクトする必要があります。ロード・バランサは、バックエンドで複数のサービス・プロバイダへのアクセスを提供します。
高可用性のためにOracle WebCenterディスカッション・サーバーとWikiサーバーを構成する手順は、第6.4.5項「WebLogic ServerのWebCenterドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」で説明されています。
MDSリポジトリおよびスキーマに対しては、バックエンド・データベースとしてOracle Real Application Clusters（RAC）データベースを使用することをお薦めします。データベース・プロバイダとしてOracle RACを構成する手順は第6.4.5項「WebLogic ServerのWebCenterドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」で説明されています。
RACおよびMDSリポジトリでのマルチ・データソースの構成の詳細は、第4.1.2項「Oracle RACでのマルチ・データソースの使用」を参照してください。
WebCenterアプリケーションの主要な構成ファイルは、表6-2に一覧表示および説明されています。これらのファイルは両方とも、WebCenterアプリケーション・デプロイメントの.EARファイルに含まれています。
表6-2 Oracle WebCenterの構成ファイル
| アーティファクト | 用途 |
|---|---|
|
|
WebCenterアプリケーションがどのディスカッション・サーバーまたはメール・サーバーを現在使用しているかなど、Application Development Framework（ADF）およびWebCenterアプリケーションの設定に関する基本構成を格納します。 |
|
|
外部サービスへの接続に関する基本構成を格納します。 |
WebCenterアプリケーションとポートレット・プロデューサは両方とも、Oracle Metadata Services（MDS）リポジトリを使用してその構成データを格納し、MDSリポジトリにはOracle WebLogicフレームワーク内のJDBCデータソースとしてアクセスします。
MDSリポジトリには、WebCenterアプリケーションおよびポートレット・プロデューサのデプロイメント後の構成の変更が、カスタマイズとして格納されます。MDSは、元のデプロイ済バージョンのadf-config.xmlとconnection.xmlをベース・ドキュメントとして使用し、その後のカスタマイズはすべて、単一のカスタマイズ・レイヤーを使用してMDSに個別に格納します。
WebCenterアプリケーションが起動すると、MDSに格納されているカスタマイズが適切なベース・ドキュメントに適用され、WebCenterアプリケーションは、マージ済ドキュメント（カスタマイズが適用されたベース・ドキュメント）を構成プロパティの最終セットとして使用します。
サーバー・クラスタにデプロイされているWebCenterアプリケーションの場合、クラスタの全メンバーは、MDSリポジトリ内の同じ場所から読取りを行います。
通常は、adf-config.xmlやconnection.xmlなどのファイルに対するベース・ドキュメント（またはMDSカスタマイズ・データ）の内容を管理者が調べたり、手動で変更する必要はありません。デプロイメント後の構成を行うための管理ツールがいくつか用意されているためです。
|
注意: 特別な指示がないかぎり、adf-config.xmlまたはconnection.xmlを手動で編集することはお薦めしません。編集すると、不適切な構成になる場合があります。 |
WebCenterアプリケーションおよびポートレット・プロデューサは、デプロイメント後の構成情報をMDSに格納しますが、Oracle WebCenterディスカッション・サーバーとOracle WebCenter Wiki and Blogサーバーの構成情報は、ファイル・システムに格納されます（表6-3を参照）。
表6-3 Oracle WebCenterの構成情報の格納場所
| アプリケーション | 構成情報の格納場所がMDS | 構成情報の格納場所がファイル・システム |
|---|---|---|
|
WebCenter Spaces |
はい |
いいえ |
|
カスタムWebCenterアプリケーション |
はい |
いいえ |
|
ポートレット・プロデューサ |
はい |
いいえ |
|
ディスカッション・サーバー |
いいえ |
はい |
|
Wiki and Blogサーバー |
いいえ |
はい |
Oracle WebCenterディスカッション・サーバーは、構成情報をDOMAIN_DIR/config/fmwconfig/servers/SERVER_NAME/owc_discussions_11.1.1.1.0/jive_startup.xmlに格納します。この構成情報は、ディスカッション・サーバーの特定のインスタンスに固有のものです。
Oracle WebCenter Wiki and Blogサーバーは、構成情報をサーバーのデプロイ・ディレクトリに格納します。たとえば$DOMAIN_HOME/servers/SERVER_NAMEなどです。その構成ファイルであるapplication_config.scriptは、$WIKI_HOME/WEB-INF/classesに格納されています。たとえばDOMAIN_HOME/servers/WLS_Services/stage/owc_wiki/11.1.1.1.0/owc_wiki/WEB-INF/classesなどです。
Oracle WebCenter、ポートレット・プロデューサ、ディスカッション・サーバーおよびWikiサーバーで実行された操作は、アプリケーションが稼働しているWebLogic管理対象サーバーの次のログに直接記録されます。
DOMAIN_HOME/servers/SERVER_NAME/logs/SERVER_NAME.log
別のWebLogic管理対象サーバーのログ・ファイルも、Oracle WebLogic Server管理コンソールで使用できます。ログを確認するには、Oracle WebLogic Server管理コンソールhttp://<admin_server_host>:<port>/consoleにアクセスして、「診断-ログ・ファイル」をクリックします。
また、管理対象サーバーのログ・ディレクトリに診断ログが作成されます。このログの粒度とロギング・プロパティは、DOMAIN_HOME/config/fmwconfig/servers/SERVER_NAME/logging.xmlファイルで変更できます。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内の別のメンバーがリクエストを処理できます。
Oracle WebCenterデプロイメント内の管理対象サーバーはそれぞれ、クラスタとしてデプロイでき、複数のクラスタ・メンバーは、同じノードまたは異なるノードに配置できます。図6-6では、クラスタに送信されたリクエストはすべて、クラスタのメンバーのいずれかによって同等に処理されます。
次の各項では、Oracle WebCenterクラスタのランタイムと構成の両面に関して詳細に説明します。
Oracle WebCenterの管理対象サーバーはすべて、システム・ライブラリとOracle ADFライブラリの両方にプロビジョニングされます。また、表6-4は、各管理対象サーバーで稼働するアプリケーションを一覧表示しています。
管理対象サーバーが起動すると、アプリケーションとライブラリは次の順序で起動します。
Oracleシステム・ライブラリ（別名、JRFライブラリ）
Oracle ADFライブラリ
インスツルメンテーション・アプリケーション（Oracle DMSなど）
表6-1に示すOracle WebCenterアプリケーション
起動順序は依存性の順序でもあります。依存コンポーネントが正しくデプロイされないと、その後のコンポーネントが正しく機能しない場合があります。Oracle WebCenterアプリケーションの適切な起動自体は、依存サービスの可用性とは関係がありません。
図6-6に示すようなOracle WebCenterクラスタ・デプロイメントでは、アプリケーション、ライブラリおよびシステム・リソースのターゲット設定に関して、次のルールに従います。
アプリケーションとライブラリのターゲットをクラスタのターゲットに設定します。たとえば、Oracle WebCenterアプリケーションのターゲットをSpacesクラスタに設定します。
JDBCリソースをクラスタのターゲットに設定します。
Oracle WebCenterアプリケーションとWikiサーバーは、Oracle WebLogicstageアプリケーションとしてデプロイされます。各アプリケーションの初期デプロイメント中に、デプロイメント・ファイルが管理サーバーから送信され、ローカルにデプロイされます。例外はOracle WebCenter Wiki and Blogサーバー・アプリケーションで、これはnostageアプリケーションとしてデプロイされます。
デフォルトでは、各Oracle WebCenterクラスタはユニキャストとして構成されています。使用するOracle WebCenterクラスタをマルチキャストとして構成するには、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。
Oracle WebCenterは、複数のステートフル・コンポーネントで構成されているOracle ADFに依存しています。WebCenter自体もステートフル・アプリケーションです。そのため、クラスタのシナリオで状態のレプリケーションを構成する必要があります。
Oracle WebLogic Serverでの状態のレプリケーションの動作の詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。
Oracle WebLogic Serverは、次の2種類の状態のレプリケーションをサポートしています。
メモリー内レプリケーション: Oracle WebLogic Serverはメモリー内レプリケーションを使用して、1つのサーバー・インスタンスから別のインスタンスにセッション状態をコピーします。プライマリ・サーバーは、クライアントが最初に接続するサーバーにプライマリ・セッション状態を作成し、クラスタ内の別のWebLogic Serverインスタンスにセカンダリ・レプリカを作成します。このレプリカは最新状態に維持されるため、サーブレットをホストしているサーバーに障害が発生した場合に使用できます。
JDBCベースの永続性: JDBCベースの永続性では、Oracle WebLogic Serverは、ファイル・ベースまたはデータベース・ベースの永続性を使用して、サーブレットまたはJSPのHTTPセッション状態を保持します。
状態のレプリケーションを適切に構成するには、環境とアプリケーションの両方を適切に構成する必要があります。フェイルオーバーの状況における状態のレプリケーションの動作の詳細は、第6.3.2.7項「アプリケーションのフェイルオーバーで予想される動作」を参照してください。
状態のレプリケーションの問題の診断の詳細は、第6.3.2.4項「Oracle WebCenterの状態のレプリケーション」を参照してください。
Oracle WebCenterアプリケーションでは、パフォーマンス向上のために分散Javaオブジェクト・キャッシュが使用されています。このキャッシュはすべてのOracle WebCenterクラスタ間で構成し、クラスタごとに分散キャッシュを1つずつ用意します。
表6-5は、Oracle WebCenterがJavaオブジェクト・キャッシュに配置するオブジェクト・タイプの例を一覧表示しています。
表6-5 Oracle WebCenterのJavaオブジェクト・キャッシュ用のオブジェクト・タイプ
| Oracle WebCenterコンポーネント | キャッシュされるオブジェクト |
|---|---|
|
ディスカッション・フォーラム |
トピックとフォーラム。 |
|
お知らせ |
お知らせ。 |
|
プレゼンス |
プレゼンス・サブスクリプション・リスト。 |
|
ワークリスト |
呼び出されたワークリスト項目（キャッシュ済データは、リフレッシュが呼び出されるまで使用される）。 |
|
コンテンツ統合（DocLib） |
isProvisoned状態およびisConfigured状態。 |
|
コンテンツ統合（ポータル・アダプタ） |
JCR: リポジトリから取得したタイプ情報とメタデータ。 |
|
サービス・フレームワーク |
ユーザー・プロファイル。問合せされたユーザー名。 |
|
最近のアクティビティ |
ユーザーごとの最近のアクティビティ結果。 |
|
Spacesアプリケーション |
インスタンス内のすべてのスペース名とテンプレート名のグローバル・リスト。 ユーザーがアクセス可能なスペースとテンプレートすべてのリスト。 |
|
ページ・サービス |
スコープ内のページのリスト。 |
|
WSRPサーバー |
WSRPプロデューサのプリファレンス・ストアの値。 |
|
IMPサービス |
ユーザーのプレゼンス/サブスクリプション・ステータス |
|
DocLib |
Spacesアプリケーション構成用DocLibサービスのプロビジョニングと構成のチェック。 |
コラボレーション
コラボレーション・サービスは、ユーザー・セッションごとにオブジェクトをJavaオブジェクト・キャッシュに格納します。HTTPセッションが破棄されると、これらのキャッシュ済ユーザー・セッションも破棄されます。
ワークリスト
ワークリストは、呼び出された項目をキャッシュするため、リフレッシュ・ボタンがクリックされるか、または15分ごとにリフレッシュ・ポーリングがトリガーされないかぎり、ユーザーが設定によってソートやグループを変更する際に同じ項目が表示されます。表示もグループおよびソートの順序の設定によってキャッシュされ、変更が行われたときに更新されます。これは読取り専用データで、存在しない場合にはフェッチされてキャッシュに格納されます。
スペース
すべてのテンプレートおよびパブリック・スペースのリストは、Javaオブジェクト・キャッシュに保持されます。特定のユーザーがアクセスできるスペースとテンプレートのリスト以外に、このスペースもすべてのユーザーによって共有されます。これらはユーザーごとにキャッシュされます。1つのJVMで作成されるテンプレートは、テンプレート・キャッシュが別のJVMで初期化されている場合には表示されません。ただし、JOCがデータを配布するか、または2番目のJVMの管理者が明示的リフレッシュを行なってキャッシュを再構築した場合は例外です。
DocLib
Spacesアプリケーションの構成と同様、DocLibはJavaオブジェクト・キャッシュを使用して、DocLibサービスのプロビジョニングと構成のチェックをキャッシュします。プロビジョニングの場合には、キャッシュされたオブジェクトには分散完了のフラグが付けられます。これらのオブジェクトは、正しく構成されたJavaオブジェクト・キャッシュによって高可用性環境内でレプリケートされ、構成のキャッシュ済状態はローカルで保持されます。キャッシュされたオブジェクトはすべて、1分後に期限切れとなるようにフラグが付けられます。キャッシュすることによって、UCMサーバーの状態をチェックするためにUCMコールが行われる回数が減ります。これは、Spacesアプリケーションがプロビジョニングと構成を繰り返しチェックして、UIにおけるサービスのレンダリングを制御するためです。
最近のアクティビティ
最近のアクティビティのタスク・フローまたはRSSフィードが表示されるたびに結果の再問合せが行われないようにするため、最近のアクティビティ結果のリストは、ユーザーごとにキャッシュされます。キャッシュは15分ごとに自動的にリフレッシュされるか、または最近のアクティビティのタスク・フローにあるリフレッシュ・アイコンを使用して手動でリフレッシュできます。
Javaオブジェクト・キャッシュの構成手順については、第6.4.13項「Javaオブジェクト・キャッシュの構成」を参照してください。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内でほかに利用可能なメンバーがリクエストを処理できます。
Oracle WebCenterアプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。
アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できる。
ステートフル・アプリケーションに対し、第6.4.1.5項「Oracle ADFのレプリケーションの構成」の説明に従って、状態のレプリケーションが正しく構成されている。
Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されている。
ハードウェア・ロード・バランサを使用する場合には、ロード・バランサが次のようになっていること。
利用可能なインスタンスすべてに対してトラフィックをルーティングしている
利用できないインスタンスをマークするように、状態モニターで正しく構成されている
セッションの状態の永続性をサポートするように構成されている
環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気がつきません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。
ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。
ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。
ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。
ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。
インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。
インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。
予想される動作に対する例外
Oracle WebCenterでは、これらの予想される動作に対する既知の例外は次のとおりです。
Oracle ADFのポップアップ: 開いているポップアップがフェイルオーバー時に閉じます。これは、通常は例外のない多くのコンポーネントに影響を及ぼします。影響を受けるコンポーネントは次のとおりです。
コンポーザ（プロパティ・インスペクタのポップアップ）
リスト
リンク（リンク削除のポップアップ）
フェイルオーバーが発生した場合、ポップアップを再表示するには、そのポップアップを表示する原因となったアクションを繰り返す必要があります。これがOracle WebCenter Spacesに表示される具体的な方法および推奨される処置は、表6-6に一覧表示されています。
表6-6 Oracle WebCenterのトラブルシューティングのシナリオ
| フェイルオーバー前のアクション | フェイルオーバー後 | 推奨される処置 |
|---|---|---|
|
任意のページにアクセスして「ページの作成」をクリックします。 |
名前を入力し、テーマを選択して「OK」をクリックします。テーマを選択すると、ページ作成ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「ページの管理」を起動します。 |
ポップアップ内で、ポップアップを閉じること以外の操作を実行します。たとえば、「ページ・アクション」をクリックします。任意の操作を実行すると、「ページの管理」ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「ページの管理」を起動し、ページに対して「ページ・アクション」をクリックしてから、メニュー内の「削除」オプションをクリックします。 |
確認ポップアップで「OK」をクリックします。「OK」をクリックすると、確認ポップアップが閉じるだけでなく、「ページの管理」ポップアップもリクエストの一部として閉じ、（行われた可能性のある）削除の効果はタブには表示されません。 |
「ページの管理」ポップアップを再起動し、ページが削除されているかどうかを確認します。削除されていない場合は、もう一度削除してみます。 |
|
「アプリケーションのパーソナライズ」ポップアップを起動します。「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。 |
「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。リクエストをサーバーに送信する任意の操作を実行すると、「アプリケーションのパーソナライズ」ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「プリファレンス」を起動します。 |
手順iiで、「プリファレンス」のタブ（「一般」、「アカウント」、「メッセージング」、「検索」）間の切替えを行います。「プリファレンス」のタブ間で切替えを行うと、「プリファレンス」ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「お気に入りの管理」を起動します（ii）。サーバーを停止し、ポップアップを閉じること以外の操作を実行します。たとえば、フォルダを開いて「お気に入り情報の編集」をクリックします。 |
ポップアップを閉じること以外の操作を実行します。たとえば、フォルダを開いて「お気に入り情報の編集」をクリックします。任意の操作を実行すると、「お気に入りの管理」ポップアップが閉じます。 |
「お気に入りの管理」ポップアップを再起動し、操作が正常に実行されたかどうかを確認します。正常に実行されなかった場合は、この操作を再試行します。 |
コンポーネント固有の問題: Oracle WebCenterの各コンポーネントに固有の他の問題は、表6-7に一覧表示されています。
表6-7 Oracle WebCenterでの予想される動作に対する例外
| Oracle WebCenterコンポーネント | 予想される動作に対する例外 |
|---|---|
|
コミュニティ・イベント |
特定のフィールド（開始または終了の日/時/分）を変更すると、フェイルオーバーの発生時にイベント・フォームが閉じます。 |
|
ポートレット |
障害は完全に透過的です。 |
|
リスト |
障害は完全に透過的です。 |
|
リンク |
障害は完全に透過的です。 |
|
検索 |
長時間実行される問合せの最中。 戻される結果は保証されません（ここでは書込み操作は存在しないことに注意）。ユーザーは問合せを再発行できます。 |
|
タグ付け |
障害は完全に透過的です。 |
|
最近のアクティビティ |
ツリー・ノードのオープン/クローズ状態はレプリケートされません。フェイルオーバー後、結果のツリーによってノードがすべて閉じます。ノードは開きなおす必要があります。 |
|
ワークリスト |
障害は完全に透過的です。 |
|
DocLib |
ユーザーがドキュメントをアップロードしたときに、同じ名前のドキュメントがすでに存在している場合は、「新規バージョンの確認」画面が表示されます。その画面の表示中、ファイルは一時的なローカルの場所に格納されます。そのときにフェイルオーバーが発生すると、アップロードしたファイルは失われ、ユーザーはアップロード・プロセスを再実行する必要があります。 |
Oracle WebLogic Server管理コンソールを使用して、アプリケーション・デプロイメントのステータスを確認します。また、Oracle WebCenterプロセスの開始、停止および監視には、Oracle WebLogic ServerインフラストラクチャとEnterprise Manager Fusion Middleware Controlも使用できます。
Oracle WebCenter Spacesとポートレット・プロデューサの場合、すべての構成データはMDSリポジトリに格納されます。アプリケーションの起動時には、追加のクラスタ・デプロイメントによって、最新の構成が自動的に読み取られます。
Oracleディスカッション・サーバーの場合、構成情報は既存のクラスタ・サーバーから移動する必要があります。これは、Oracle WebLogic Serverのpack/unpackユーティリティによって自動的に行われます。これがお薦めする手順です。
Oracle WebCenter Wiki and Blogサーバーの場合、ほとんどの構成はデータベースに格納されますが、デプロイメント・ディレクトリ内のカスタム・テンプレートに固有の構成もあります。クラスタ・インストールでは、クラスタ内のすべてのWikiサーバーがこのデプロイメント・ディレクトリを共有する必要があります。
Oracle WebCenter Spacesとポートレット・プロデューサの場合、その構成はMDSリポジトリに格納されます。クラスタ内の1つのサーバーの構成に対して行われた変更は、他のすべてのメンバーにただちに表示されます。
Oracle WebCenterディスカッション・サーバーは頻繁に変更されませんが、変更された場合は、変更をクラスタの他のメンバーに再適用する必要があります。再適用するには、ロード・バランサを使用するかわりに各ディスカッション・サーバーに直接接続し、必要な管理変更を行います。
Oracle Wikiサーバーの場合、その構成はデータベースおよびローカルのデプロイメント・ディレクトリに保持されます。構成はノードごとに適用する必要があります。
図6-6は、1つのWebLogic Serverドメイン内の2つのOracle WebLogic Serverで、2ノードのOracle WebCenterクラスタが稼働している状況を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。メタデータとスキーマの格納にはOracle RACデータベースが使用されます。Oracle Wiki and Blogサーバーの共有構成には共有記憶域が使用されます。管理サーバーにはVIPが使用されます（手動フェイルオーバー用）。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
|
注意: コマンド例はすべて、Kシェルまたはbashシェルに対するものです。Cシェルの例は提供されていません。 |
次の各項では、Oracle WebCenterの高可用性構成を設定する前に必要となる手順について説明します。
プラットフォーム固有のコマンドの詳細は、『Oracle Fusion Middleware Oracle WebCenterインストレーション・ガイド』を参照してください。
Oracle WebCenterでサポートしているデータベースのバージョンは次のとおりです。
Oracle Database 10g（10.2.0.4以上）
Oracle Database 11g（11.1.0.7以上）
データベースのバージョンを調べるには、次の問合せを実行します。
SQL>select version from sys.product_component_version where product like 'Oracle%';
管理サーバーの仮想IPを構成するには、第10.2.2.3項「コールド・フェイルオーバー・クラスタへの管理サーバーの変換」を参照してください。
次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。
Oracle Clusterware
10gリリース2（10.2）については、Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersのインストレーション・ガイドを参照してください。
11gリリース1（11.1）については、Oracle Clusterwareのインストレーション・ガイドを参照してください。
自動ストレージ管理
10gリリース2（10.2）については、Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersのインストレーション・ガイドを参照してください。
11gリリース1（11.1）については、Oracle Real Application Clustersのインストレーション・ガイドを参照してください。
インストーラを実行するときは、「構成の選択」ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。
Oracle Real Application Cluster
10gリリース2（10.2）については、Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersのインストレーション・ガイドを参照してください。
11gリリース1（11.1）については、Oracle Real Application Clustersのインストレーション・ガイドを参照してください。
Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g（11.1.1）Oracle Fusion MiddlewareリポジトリをReal Application Clusterデータベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ（RCU）が用意されています。RCUは、RCU専用のOracleホームにインストールします。
RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
データベースの初期化パラメータ
次の初期化パラメータが、必要な値に設定されていることを確認します。この値は、リポジトリ作成アシスタントによってチェックされます。
SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。
SYSユーザーとして、SHOW PARAMETERを次のように発行します。
SQL> SHOW PARAMETER processes
次のコマンドを使用して初期化パラメータを設定します。
SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE
データベースを再起動します。
|
注意: パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイルとサーバー・パラメータ・ファイルの詳細、およびパラメータ値の変更方法は、『Oracle Database管理者ガイド』を参照してください。 |
本番環境では、Oracle WebCenterの高可用性トポロジに外部のLDAPポリシー・ストアが必須です。サポートされているポリシー・ストアの詳細およびLDAPの構成手順は、『Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter』を参照してください。
次のリストは、この項で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware（FMW）が常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle WebCenter がインストールされている場所を指します。
DOMAIN_HOME: このディレクトリ・パスは、Oracle WebLogicドメイン情報（構成アーティファクト）が格納されている場所を指します。
このディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。
ORACLE_BASE:
/u01/app/oracle
MW HOME（アプリケーション層）:
ORACLE_BASE/product/fmw
WLS_HOME:
MW_HOME/wlserver_10.3
ORACLE_HOME:
MW_HOME/WC1
Oracle Fusion Middleware WebCenterのコンポーネントをインストールする前に、11g（11.1.1）Oracle Fusion Middlewareのメタデータ・ストアとWebCenterスキーマをReal Application Clusterデータベースにインストールします。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ（RCU）が用意されています。RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。
次のコマンドを使用してRCUを起動します。
RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
データベース・タイプ: Oracle Databaseを選択します。
ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します: WCDBHOST1VIRTUAL
ポート: データベースのポート番号: 1521
サービス名: データベースのサービス名を入力します: wcha.mycompany.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワードを入力します。
ロール: SYSDBA
「次へ」をクリックします。
次の警告メッセージを受信した場合は、「無視」または「停止」をクリックします。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、WCHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。
次のスキーマを選択します。
AS共通スキーマ:
Metadata Services
WebCenterインフラストラクチャ:
WebCenter Suite
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加（補助）のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
RCUの使用の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。
サーバーが次の要件を満たしていることを確認します。
システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』で指定されている要件を満たしています。
この例ではポート7777を使用します。ポート7777を選択する場合には、ノード上のいずれのサービスでもこのポートが使用されていないことを確認します。このことを確認するには、次のコマンドを実行します。
UNIX:
netstat -an | grep 7777
Windows:
netstat -an | findstr 7777
ポート7777が使用中の場合には、別のポートを選択するか、またはこのポートを使用可能にします。
UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle Fusion Middleware 11g Webtier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンド./runInstallerを実行します。
Windowsでは、setup.exeをダブルクリックします。
「インベントリ・ディレクトリの指定」画面で、インベントリおよびユーザー・グループの場所を入力して「OK」をクリックします。
ダイアログに従ってrootの特権アクションを実行し、「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、場所を次のように設定します。
/u01/app/oracle/product/11.1.1/ohs_1
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。
「次へ」をクリックします。
「コンポーネント詳細の指定」画面で、次の値を入力します。
インスタンス・ホームの場所: app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1
インスタンス名: ohs_instance1
OHSコンポーネント名: ohs1
「次へ」をクリックします。
「Web Tierポートの詳細の指定」画面で、次の操作を行います。
「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
Oracle HTTP Serverのポート番号を入力します。たとえば、7777と入力します。
「次へ」をクリックします。
|
注意: ポートの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』を参照してください。 |
「次へ」をクリックします。
「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。
「インストールの進行状況」画面で、次の操作を行います。
UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。
「構成が完了しました」画面で、「終了」をクリックして終了します。
次の手順を使用して、Oracle Fusion Middlewareコンポーネントをインストールします。
Oracle WebLogic Server（第6.4.3.1項「Oracle WebLogic Serverのインストール」を参照）
Oracle WebCenter（第6.4.3.2項「Oracle WebCenter用Oracle Fusion Middlewareのインストール」を参照）
アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。
UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle WebLogic Serverインストーラを起動します。
UNIXの場合（次の例はLinuxの場合）:
APPHOST1> server103_linux32.bin
Windowsの場合:
APPHOST1> server103_win32.exe
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、ORACLE_BASE/product/fmwと入力します。
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「JDKの選択」画面で、「JROCKIT SDK1.6.0_05」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
ORACLE_BASE/product/fmw/wlserver_10.3
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。
アプリケーション層にあるすべてのノードにOracle WebCenter用Oracle Fusion Middlewareをインストールする手順は次のとおりです。
Oracle Fusion MiddlewareのOracle Fusion Middleware 11g WebCenterインストーラを起動します。
UNIXの場合（次の例はLinuxの場合）:
APPHOST1> runInstaller
Windowsの場合:
APPHOST1> setup.exe
Oracle Fusion Middleware 11g WebCenterインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、ORACLE_BASE/product/fmw/jrockit_160_05_R27.6.2-20のように入力します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
「ミドルウェア・ホーム」には、ORACLE_BASE/product/fmwと入力します。
「Oracleホーム・ディレクトリ」には、たとえばwcのように、使用するディレクトリを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール 完了」画面で「終了」をクリックします。
管理サーバーの仮想IPの構成の詳細は、第10章「Oracle Fusion Middleware高可用性のアクティブ/パッシブ・トポロジ」を参照してください。
MiddlewareホームのWebCenterディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracle WebCenterコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースでは、すべてのインスタンスを実行することをお薦めします。
次のコマンドを使用して、ORACLE_HOME/common/binディレクトリからOracle WebLogic Serverの構成ウィザードを起動します。
APPHOST1> ./config.sh
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。
Webcenter Spacesを選択すると、WSMポリシー・マネージャとOracle JRFが自動的に選択されます。
Oracle WebCenter Spaces - 11.1.1.0
Oracle Enterprise Manager - 11.1.1.0
Oracleポートレット・プロデューサ - 11.1.1.0
Oracle Wiki and Blogサーバー - 11.1.1.0
Oracle WebCenterディスカッション・サーバー - 11.1.1.0
Oracle JRF - 11.1.1.0
「次へ」をクリックします。
「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択
JDKの選択: 「JROCKIT SDK1.6.0_05」を選択
「次へ」をクリックします。
「JDBCデータ・ソースの構成」画面で、「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。
リポジトリ作成ユーティリティによって、必要なスキーマがOracleデータベースに作成されます。これらのスキーマにはカスタム接頭辞を指定します。表6-9は、データソース、使用するスキーマ、およびスキーマが割り当てられている管理対象サーバーを一覧表示しています。
画面に次のデータソースが表示されていることを確認します。
「次のパネルですべてのデータ・ソースをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、「追加」ボタンをクリックして、両方のRACノードの「ホスト名」、「インスタンス名」および「リスニング・ポート」を追加します。
1つのスキーマを選択したまま残し、他のスキーマの選択は解除します。
「ドライバ」ドロップダウン・リストで、「RACサービス・インスタンス接続用Oracleのドライバ（Thin）」を選択します。
「サービス名」を入力します。
Oracle WebCenterスキーマのPrefix_Usernameを入力します。
スキーマの「パスワード」を入力します。
「追加」をクリックして、最初のRACインスタンスの詳細を入力します。
一度に1つのデータソースを選択し、適切な詳細を追加することで、各マルチ・データソース・スキーマを更新します。
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常だったことを確認します。正常でない接続があった場合には、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続が正常になったら「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: 第6.4.4項で使用したVIPアドレスを入力します。
リスニング・ポート: 7001
SSLリスニング・ポート: N/A
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。
表6-10 管理対象サーバーの構成
| 名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
|
WLS_Portlet |
APPHOST1のホスト名 |
8889 |
n/a |
選択を解除 |
|
WLS_Portlet2 |
APPHOST2のホスト名 |
8889 |
n/a |
選択を解除 |
|
WLS_Spaces |
APPHOST1のホスト名 |
8888 |
n/a |
選択を解除 |
|
WLS_Spaces2 |
APPHOST2のホスト名 |
8888 |
n/a |
選択を解除 |
|
WLS_Services |
APPHOST1のホスト名 |
8890 |
n/a |
選択を解除 |
|
WLS_Services2 |
APPHOST2のホスト名 |
8890 |
n/a |
選択を解除 |
「次へ」をクリックします。
「クラスタの構成」画面で、次のクラスタを追加します。
名前: Portlet_Cluster
クラスタ・メッセージング・モード: unicast
クラスタ・アドレス有効化: 空白のまま
名前: Spaces_Cluster
クラスタ・メッセージング・モード: unicast
|
注意: デフォルトでは、各Oracle WebCenterクラスタはユニキャストとして構成されています。使用するOracle WebCenterクラスタをマルチキャストとして構成するには、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。 |
クラスタ・アドレス有効化: 空白のまま
名前: Services_Cluster
クラスタ・メッセージング・モード: unicast
クラスタ・アドレス有効化: 空白のまま
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、クラスタに次のサーバーを割り当てます。
Spaces_Cluster
WLS_Spaces
WLS_Spaces2
Portlet_Cluster
WLS_Portlet
WLS_Portlet2
Services_Cluster
WLS_Services
WLS_Services2
「次へ」をクリックします。
「マシンの構成」画面で、次の操作を行います。
デフォルトとして表示される「LocalMachine」を削除します。
「UNIXマシン」タブをクリックし、次のマシンを追加します。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。
APPHOST1: WLS_Spaces1、WLS_Porlet1、WLS_Services1
APPHOST2: WLS_Spaces2、WLS_Porlet2、WLS_Services2
「次へ」をクリックします。
「構成のサマリ」画面で「作成」をクリックします。
「ドメインの作成中」画面で「完了」をクリックします。
この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーおよび管理対象サーバーに対してboot.propertiesファイルを作成します。
管理サーバーに対しては、次の手順を実行します。
次のディレクトリを作成します。
APPHOST1> mkdir -p MW_HOME/wls/user_projects/domains/wcdomain/servers/AdminServer/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。
username=adminuser password=password
|
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
WLS_Spaces1管理対象サーバーに対しては、次の手順を実行します。
次のディレクトリを作成します。
APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/servers/WLS_Spaces1 APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/servers/WLS_Spaces1/security
テキスト・エディタを使用して、前の手順で作成したセキュリティ・ディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。
username=adminuser password=password
APPHOST1での管理対象サーバーWLS_Portlet1およびWLS_Services1に対し、手順2と3を繰り返します。
|
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
この項では、APPHOST1でシステムを起動する手順について説明します。
APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。
APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/bin
APPHOST1> ./startWebLogic.sh
管理サーバーが適切に構成されていることを確認する手順は次のとおりです。
ブラウザでhttp://VIP1:7001/consoleにアクセスします。
管理者としてログインします。
管理対象サーバーとしてWLS_Spaces1およびWLS_Spaces2が表示されていることを確認します。
Spaces_Clusterクラスタが表示されていることを確認します。
Enterprise Manager（http://VIP1:7001/em）にアクセスできることを確認します。
この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。
ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。
APPHOST1でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「管理サーバー」→「SSL」→「詳細」を選択します。
「ロックして編集」をクリックします。
プロンプトが表示されたら、変更内容を保存してアクティブ化します。
「ホスト名の検証」を「なし」に設定します。
「WLS_Spaces1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
WLS_Portlet1とWLS_Services1に対し、手順3を繰り返します。
APPHOST2でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「WLS_Spaces2」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
WLS_Portlet2とWLS_Services2に対し、手順1と2を繰り返します。
APPHOST1でノード・マネージャを起動するには、次の手順を実行します。
ノード・マネージャを起動する前に、JAVA_OPTIONS環境変数を設定してStartScriptEnabledプロパティを定義します。APPHOST1で、次のコマンドを実行します。
APPHOST1> export JAVA_OPTIONS=-DStartScriptEnabled=true
|
注意: クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。 |
ノード・マネージャを起動します。
APPHOST1> cd ORACLE_BASE/admin/DOMAIN_NAME/mserver/DOMAIN_NAME/servers APPHOST1> ./startNodeManager.sh
ノード・マネージャを初めて起動した後で、nodemanager.propertiesファイルを編集してStartScriptEnabledプロパティを定義できます。nodemanager.propertiesファイルは、ノード・マネージャを初めて起動するまでは存在していません。
nodemanager.propertiesファイルでStartScriptEnabledプロパティを設定する手順は次のとおりです。
ORACLE_BASE/wls/wlserver_10.3/common/nodemanager/nodemanager.propertiesファイルに次の行を追加します。
StartScriptEnabled=true
このプロパティがnodemanager.propertiesファイルで設定されている場合には、同じプロパティをJAVA_OPTIONS環境変数で定義する必要はなくなります。
APPHOST2に対し、WebLogic ServerとOracle WebCenterのインストール手順を繰り返します。第6.4.2項「WebHost1へのOracle HTTP Serverのインストール」の手順から始めてください。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。
次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST2に伝播します。
次のpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cd ORACLE_BASE/product/fmw/wlserver_10.3/common/bin
APPHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/
-template=wcdomaintemplate.jar
-template_name=wc_domain_template
次のコマンドをAPPHOST1で実行し、前の手順で作成したテンプレート・ファイルをAPPHOST2にコピーします。この例ではscpを使用しています。
APPHOST1> scp wcdomaintemplate.jar
APPHOST2:ORACLE_BASE/product/fmw/wlserver_10.3/common/bin
unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。
APPHOST2> cd ORACLE_BASE/product/fmw/wlserver_10.3/common/bin APPHOST2> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/ -template=wcdomaintemplate.jar
APPHOST2でノード・マネージャを起動するには、第6.4.7.4項「APPHOST1でのノード・マネージャの起動」の手順をAPPHOST2で繰り返します。
Oracle WebCenter管理対象サーバーを含む管理サーバーへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定します。
OHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.confファイルに次の行を追加します。
# Spaces
<Location /webcenter>
WebLogicCluster apphost1.com:8888,apphost2.com:8889
SetHandler weblogic-handler
</Location>
<Location /webcenterhelp>
WebLogicCluster apphost1.com:8888,apphost2.com:8888
SetHandler weblogic-handler
</Location>
<Location /rss>
WebLogicCluster apphost1.com:8888,apphost2.com:8888
SetHandler weblogic-handler
</Location>
# Portlet
<Location /portalTools>
WebLogicCluster apphost1.com:8889,apphost2.com:8889
SetHandler weblogic-handler
</Location>
<Location /wsrp-tools>
WebLogicCluster apphost1.com:8889,apphost2.com:8889
SetHandler weblogic-handler
</Location>
# Discussions and Wiki
<Location /owc_discussions>
WebLogicCluster apphost1.com:8890,apphost2.com:8890
SetHandler weblogic-handler
</Location>
<Location /owc_wiki>
WebLogicCluster apphost1.com:8890,apphost2.com:8890
SetHandler weblogic-handler
</Location>
WEBHOST1上のOracle HTTP Serverを再起動します。
WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1
URLを検証し、HTTP ServerからOracle WebCenterクラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。
WebLogic Server管理コンソールから、WLS_Spaces1、WLS_Spaces2、WLS_Portlet1およびWLS_Portlet2を次のように起動します。
次のURLの管理コンソールにアクセスします。
http://APHHOST1/console
「サーバー」をクリックします。
「制御」タブを開きます。
WLS_Spaces1、WLS_Spaces2、WLS_Portlet1およびWLS_Portlet2を選択します。
「起動」をクリックします。
次のURLを使用して、管理対象サーバーへの直接アクセスを検証します。
apphost1:8888/webcenter
apphost2:8888/webcenter
apphost1:8889/portaltools
apphost2:8889/portaltools
WLS_Spaces2とWLS_Portlet2の稼働中に、Oracle WebLogic Server管理コンソールからWLS_Spaces1とWLS_Portlet1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/webcenter
WebHost1:7777/portalTools
WebLogic Server管理コンソールからWLS_Spaces1とWLS_Portlet1を起動します。
WLS_Spaces2とWLS_Portlet2を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/webcenter
WebHost1:7777/portalTools
高可用性のための管理サーバーの構成の詳細は、第10.2.2.3項「コールド・フェイルオーバー・クラスタへの管理サーバーの変換」を参照してください。
Javaオブジェクト・キャッシュ（JOC）は、WebCenter Spacesを実行しているすべてのサーバー間で構成する必要があります。このローカル・キャッシュは、Oracle WebCenter Spacesのパフォーマンスを向上させるために用意されています。
Javaオブジェクト・キャッシュは、MW_HOME/webcenter/scripts/configure-joc.pyスクリプトを使用して構成できます。これはPythonスクリプトで、管理対象サーバーでJOCを構成するために使用できます。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが稼働中であることが求められます。
使用方法
たとえば次のように、コマンドラインのOracle Weblogic Scripting Tool（WLST）を使用して管理サーバーに接続します。
MW_HOME/wc/common/bin/wlst.sh
$ connect()
プロンプトが表示されたら、Oracle Weblogicの管理ユーザー名とパスワードを入力します。
wlstを使用して管理サーバーに接続したら、execfileコマンドを次のように使用してスクリプトを起動します。
wls:/mydomain/serverConfig>execfile('MW_HOME/webcenter/scripts/configure-joc.py')
このスクリプトによって、入力パラメータをすべて入力するように求められます。このスクリプトは、次のJOC構成を実行するために使用できます。
指定したクラスタのすべての管理対象サーバーに対してJOCを構成します。
クラスタ名を指定するかどうかが尋ねられたらyを入力し、プロンプトが表示されたらクラスタ名と検出ポートを指定します。これによって、指定したクラスタの管理対象サーバーがすべて検出され、JOCが構成されます。検出ポートはクラスタ内の全JOC構成に対して共通です。次に例を示します。
Do you want to specify a cluster name (y/n) <y> Enter Cluster Name : Spaces_Cluster Enter Discover Port : 9999
指定したすべての管理対象サーバーに対してJOCを構成します。
クラスタ名を指定するかどうかが尋ねられたらyを入力し、プロンプトが表示されたら管理対象サーバーと検出ポートを指定します。次に例を示します。
Do you want to specify a cluster name (y/n) <y>n Enter Managed Server and Discover Port (eg WLS_Spaces1:9999, WLS_Spaces2:9999) : WLS_Spaces1:9999,WLS_Spaces2:9999
この例では、指定した管理対象サーバー（つまりWLS_Spaces1とWLS_Spaces2）に対してのみJOCを構成します。検出ポートは、管理対象サーバーとともに指定します（例: WLS_Spaces1:2222）。
一部の管理対象サーバーに対してJOC構成を除外します。
スクリプトでは、JOC構成のDistributeModeがfalseに設定される管理対象サーバーのリストを指定できます。一部のサーバーをJOC構成から除外するかどうかが尋ねられたらyを入力し、プロンプトが表示されたら除外する管理対象サーバーの名前を入力します。次に例を示します。
Do you want to exclude any server(s) from JOC configuration (y/n) <n>y Exclude Managed Server List (eg Server1,Server2) : WLS_Spaces1,WLS_Spaces3
すべての管理対象サーバーに対して、分散モードを無効にします。
スクリプトでは、指定したクラスタの管理対象サーバーすべてに対して分散を無効にできます。分散モードを指定するように求められたら、falseを指定します。デフォルトでは、分散モードはtrueに設定されています。
CacheWatcherというユーティリティを実行すると、Javaオブジェクト・キャッシュの構成を検証できます。CachWatcherを実行する手順は次のとおりです。
次のMW_ORA_HOMEには、Oracle WebCenterがインストールされている場所（FMW_HOME/Oracle_WC1）を使用します。
MW_ORA_HOMEには、Oracle WebCenterがインストールされている場所（例: MW_HOME/Oracle_WC1）を使用します。
DOMAIN_HOMEには、MW_HOME/user_projects/domainsの下にあるドメインの場所のフルパスを使用します。Server_Nameは、管理対象サーバー名（例: WLS_Portlet1）を指します。
任意のマシン（例: APPHOST1）で次のコマンドを実行します。
"java -classpath WLS_HOME/WebCenter_oracle_home/modules/ oracle.javacache_11.1.1/cache.jar:WLS_HOME/WebCenter_oracle_home/modules/oracle.odl_11.1.1/ojdl.jar oracle.ias.cache.CacheUtil watch -config=DOMAIN_HOME/config/fmwconfig/servers/Server_Name/javacache.xml"
APPHOST2で次のコマンドを実行します。
"java -classpath MW_HOME/modules/oracle.javacache_11.1.1/ cache.jar:MW_HOME/modules/oracle.odl_11.1.1/ojdl.jar oracle.ias.cache.CacheUtil watch -config=absolute_path_of_your_config_file"
CacheWatcherのプロンプトで、lcと入力して［Enter］を押します。
グループ・ビューが表示されます。
グループ・ビューは、キャッシュ・メンバーの数を示します。CacheWatcherの実行例を次に示します。
java -classpath MW_HOME/modules/oracle.javacache_11.1.1/ cache.jar:MW_HOME/modules/oracle.odl_11.1.1/ojdl.jar oracle.ias.cache.CacheUtil watch -config=DOMAIN_HOME /config/fmwconfig/servers/WLS_Spaces_Server/javacache.xml" cache> lc VID: 2 Size: 2 Column: 0123456789 CL: JJ GRP0: 11 ... Member Table: #1. J57161:145.87.9.15:86AAC2E:11B28D57BE4:-7FFE, 0 #2. J35578:145.87.9.14:-9E92850:11B28D5F7E0:-7FFF, 1
CacheWatcherを各ホストで起動した後、ビューから2つのメンバーを検索します。
|
注意: CacheWatcher自体は分散キャッシュ・インスタンスと見なされます。CacheWatcherシェルを終了するには、exitと入力して［Enter］を押します。 |
この項の手順を使用して、Oracle WebCenterのレプリケーションを構成します。
クラスタリング要件
アプリケーションをOracle WebLogicクラスタにデプロイする必要があります。これによって、アプリケーションの複数インスタンスに、レプリケーション・チャネルが自動的に確立されます。
|
注意: ユニキャスト・クラスタでは、デフォルトのレプリケーション・チャネルは、各管理対象サーバーのリスニング・アドレスを使用して構成されています。そのため、リスニング・アドレスは、Anyでリスニングするように構成するのではなく、特定のIPアドレスまたはホスト名となるように構成する必要があります。 |
Oracle ADFのレプリケーション
Oracle WebCenterはOracle ADFコンポーネントに依存しているため、Oracle ADFが適切に構成されていることが重要です。ステートフル・アプリケーションの場合には、アプリケーション・リソースの1つであるadf-config.xmlファイルに、次のタグが存在している必要があります。
<adfc:adf-controller-config><adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support></adfc:adf-controller-config>
Oracle WebCenterアプリケーションでは、これはデフォルトですでに有効になっています。
アプリケーションのレプリケーション
アプリケーションでは、レプリケーションも有効化されている必要があります。Oracle WebLogic Serverでは、レプリケーションのために様々な種類の永続ストアを使用できます。永続ストアの詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。
Oracle WebCenterの場合、アプリケーションは、デフォルトでweblogic.xmlファイルの次の設定で有効になっています。
<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
replicated_if_clustered設定は、スタンドアロン・アプリケーション環境のレプリケーションを無効にし、クラスタ環境内のメモリー内レプリケーションを使用します。
メモリー内レプリケーションに任意のカスタム・アプリケーションが構成されていることを確認します。
Oracle WebCenterトポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。
この場合は、WebCenterコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードの共有記憶域には、MiddlewareホームとWebCenterディレクトリが格納されています。
新しいOracle WebCenterおよびサーバーを作成するには、既存のインストール（Middlewareホームとドメイン・ディレクトリ）を使用できます。WebCenterのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
トポロジをスケール・アップするには、次の手順を実行します。
管理コンソールを使用して、WLS_Spaces1、WLS_Portlet1またはWLS_Services1のクローンを新しい管理対象サーバーに作成します。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。
管理コンソールから「環境」→「サーバー」を選択します。
クローンを作成する管理対象サーバー（WLS_Spaces1やWLS_Portlet1など）を選択します。
「クローンの作成」を選択します。
新しい管理対象サーバーにSERVER_NAMEnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。
この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。
スケール・アップする管理対象サーバーがWLS_Servicesの場合は、次の追加手順を実行します。
管理対象サーバーを少なくとも一度起動します。起動すると、Oracle Wikiに対して、管理対象サーバーのデプロイメント・ディレクトリが作成されます。これで管理対象サーバーを停止できるようになります。
この新しい管理対象サーバーのconfigディレクトリからWikiサーバーの共有ディレクトリへのソフト・リンクを作成します。
$ ln -s DOMAIN_HOME/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments/ /shared/owc_wiki/attachments $ ln -s DOMAIN_HOME/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates/ /shared/owc_wiki/templates
クラスタ内の新しいメンバーを使用して、Oracle HTTP Serverモジュールを再構成します（Oracle HTTP Serverの構成を参照）。
トポロジのスケール・アウトでは、Oracle WebCenterアプリケーションを使用して構成されている新しい管理対象サーバーを新しいノードに追加します。
この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。
トポロジ内には、Oracle WebCenterアプリケーションを使用して構成されている管理対象サーバーを実行しているノードがすでに存在しています。
新しいノードが、WebLogic ServerとOracle WebCenter用の既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerまたはWebCenterのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
トポロジをスケール・アウトするには、次の手順を実行します。
新しいノードで、WebCenterのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
管理コンソールを使用して、WLS_Spaces1/WLS_Portlet1/WLS_Services1のクローンを新しい管理対象サーバーに作成し、WLS_(SERVER_TYPE)nという名前を付けます。nは番号です。
この手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。
管理対象サーバーのリスニング・アドレスに対して、新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。
スケール・アウトする管理対象サーバーがWLS_Servicesの場合は、次の追加手順を実行します。
管理対象サーバーを少なくとも一度起動します。起動すると、Oracle Wikiに対して、管理対象サーバーのデプロイメント・ディレクトリが作成されます。これで管理対象サーバーを停止できるようになります。
この新しい管理対象サーバーのconfigディレクトリからWikiサーバーの共有ディレクトリへのソフト・リンクを作成します。
$ ln -s DOMAIN_HOME/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/attachments/ /shared/owc_wiki/attachments $ ln -s DOMAIN_HOME/servers/WLS_ServicesN/stage/owc_wiki/11.1.1.1.0/owc_wiki/templates/ /shared/owc_wiki/templates
クラスタ内の新しいメンバーを使用して、Oracle HTTP Serverモジュールを再構成します（Oracle HTTP Serverの構成を参照）。
新しいノードでノード・マネージャを起動します。すでに存在しているノードの共有記憶域にあるインストールを使用し、新しいノードのホスト名をパラメータとして渡してノード・マネージャを起動します。
NEW_NODE> MW_HOME/wlserver_10.3/server/bin/startNodeManager <new_node_ip>
第6.4.3.1項「Oracle WebLogic Serverのインストール」に示すパスを使用した場合、MW_HOMEはORACLE_BASE/product/fmwになります。
前の手順で追加した管理対象サーバーを管理コンソールから起動し、テストします。
新規に作成した管理対象サーバー上のアプリケーション（http://HOST:port/webcenter）にアクセスします。アプリケーションが機能している必要があります。
この新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します（第6.4.13項「Javaオブジェクト・キャッシュの構成」を参照）。
この項では、Oracle WebCenterで発生する可能性のある問題のトラブルシューティング手順について説明します。
Oracle WebCenterアプリケーションは、管理対象サーバーが最初に起動したときにデプロイされます。最初にOracle WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメントがすべて成功したことを確認します。
左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。
アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME/servers/{SERVER_NAME}/logsディレクトリに格納されています。一般的な問題には、次のようなものがあります。
データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。
適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。
フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります。
ウィンドウが閉じたか、または状態がリセットされた可能性がある。
画面のリセットが必要になった可能性がある。
アプリケーションがログオン画面にリダイレクトしている可能性がある。
次の手順は、状態のレプリケーションに関する問題のトラブルシューティングおよび診断を行う際のガイダンスです。
これがレプリケーションに関する既知の問題でないことを確認します。
予想される動作については、第6.3.2.7項「アプリケーションのフェイルオーバーで予想される動作」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。
ロード・バランサの設定を確認します。
レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverのハードウェア・ロード・バランサの構成の詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。
クラスタのステータスを確認します。
クラスタのコンテキスト内でレプリケーションが発生します。フェイルオーバーが成功するには、クラスタの正常なメンバーが、ほかに少なくとも1つ使用可能である必要があります。クラスタのステータスは、次の2種類の方法のどちらかで確認できます。
Oracle WebLogic Server管理コンソールを使用してクラスタのステータスを確認します。左側のペインで「サーバー」をクリックします。クラスタ内のすべてのサーバーの状態を確認します。
weblogic.Adminユーティリティを使用してクラスタのステータスを確認します。weblogic.Adminコマンドは、特定のクラスタ内のすべてのサーバーの状態を問い合せるときに使用できます。次に例を示します。
$ java weblogic.Admin -url Adminhost:7001 -username <username> -password <password> CLUSTERSTATE -clustername Spaces_Cluster
次のようなメッセージが返されます。
There are 2 server(s) in cluster: Spaces_Cluster The alive servers and their respective states are listed below: WLS_Spaces---RUNNING WLS_Spaces2---RUNNING
クラスタ通信を確認します。
クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。
ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。
個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。
マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTestを実行して、マルチキャストが正しく構成されていることを確認します。次に例を示します。
$ java utils.MulticastTest -H
アプリケーションの構成を確認します。
Oracle WebCenterアプリケーションは、デフォルトで正しく構成されています。ユーザー・アプリケーションに対するメモリー内のレプリケーションは、weblogic.xmlで適切な構成がなされている場合にのみ行われます。
<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
replicatedのpersistent-store-typeも受け入れられます。
デバッグを有効にします。
サーバー・ログを調べて、管理対象サーバーの起動時に異常なメッセージがないか確認します。この確認は、管理対象サーバーがクラスタの他のメンバーを見つけられない場合に、特に必要です。サーバー・ログは、DOMAIN_HOME/servers/{SERVER_NAME}/logsディレクトリに格納されています。
詳細な診断を行うには、DebugCluster、DebugClusterAnnouncements、DebugFailOver、DebugReplication、DebugReplicationDetailsの各フラグを有効にします。各フラグは、weblogic.Adminユーティリティを使用して次のように有効にできます。
$ java weblogic.Admin -url Adminhost:7001 -username <username> -password <password> SET -type ServerDebug -property DebugCluster true
問題: ポリシーは、変数oracle.security.jps.ldap.policystore.refresh.intervalによってjps-config.xmlに定義されている間隔でリフレッシュされます。デフォルトでは、この間隔は10分です。サーバーが失われた場合、前回のリフレッシュ以後に発生した最近のポリシーの変更が失われたように見えることがあります。たとえば、フェイルオーバーの直前に作成されたロールは、使用不可と表示される場合があります。
ソリューション: ポリシーはまだバックエンド・ポリシー・ストアに含まれていますが、ポリシー情報をリストアするにはキャッシュをリフレッシュする必要があります。数分後に再試行するか、またはアプリケーションにログインしてからログアウトして、ポリシー・キャッシュのリフレッシュを強制実行します。
この項では、高可用性のためにOracle ADFおよびWebCenterのカスタム・アプリケーションを構成する手順について説明します。
Oracle WebCenterのカスタム・アプリケーションをデプロイするためにクラスタを構成する際に必要となる手順は次のとおりです。
Oracle WebLogic Server管理コンソール（http://server_name:7001/console）にアクセスします。
管理ユーザー名とパスワードを入力してログインします。
「ホーム」ページで、「ドメイン構成」セクションの「サーバー」をクリックします。
ページ・セクションの「概要」で「新規」をクリックします。
カスタム・アプリケーション・サーバーに対する独自のサーバー名とポート番号（例: 8898）を入力します。
他の選択はデフォルトのままにして、「終了」をクリックして管理対象サーバーを生成します。
「作成の概要」ページで、作成したばかりのサーバーをクリックします。「マシン」ドロップダウン・リストをクリックし、「LocalMachine」を選択します。
ページの下部にある「保存」をクリックします。
手順4〜8を繰り返し、必要に応じて管理対象サーバーをさらに作成します。
クラスタを作成するには、「「ホーム」」ページで「クラスタ」をクリックします。
右側のペインで、「新規」をクリックして新しいクラスタを作成します。
クラスタに名前を付け、デフォルトの「ユニキャスト」はそのままにします。
「OK」をクリックしてクラスタを作成します。
クラスタ名をクリックし、「サーバー」タブをクリックします。
「追加」ボタンをクリックしてサーバーを追加します。
ドロップダウン・リストから、前に作成した管理対象サーバーを選択し、「終了」をクリックします。
クラスタを作成したら、正しいライブラリ、アプリケーションおよびデータソースを使用してプロビジョニングします。
「ドメイン構造」セクションの「デプロイメント」リンクをクリックします。
複数の共有ライブラリがデプロイされていることに注意してください。次のライブラリのターゲットが、新規作成したクラスタに設定されていることを確認します。
ライブラリ・リンクをクリックします。
上部の「ターゲット」タブをクリックします。
新規作成したクラスタのチェック・ボックスを選択します。
「保存」ボタンをクリックします。
ターゲットを設定する共有ライブラリのリストは次のとおりです。
adf.oracle.domain(1.0,11.1.1.0.0)
adf.oracle.domain.webapp(1.0,11.1.1.1.0)
jsf(1.2,1.2.9.1)
jstl(1.2,1.2.0.1)
ohw-rcf(5,5.0)
ohw-uix(5,5.0)
UIX(11,11.1.1.1.0)
oracle.adf.dconfigbeans(1.0,11.1.1.0.0)
oracle.dconfig-infra
oracle.jrf.system.filter
oracle.jsp.next(11.1.1,11.1.1)
oracle.sdp.client(11.1.1,11.1.1)
oracle.soa.workflow.wc(11.1.1,11.1.1)
oracle.webcenter.framework(11.1.1,11.1.1)
oracle.webcenter.framework.view(11.1.1,11.1.1)
oracle.webcenter.skin(11.1.1,11.1.1)
oracle.wsm.seedpolicies(11.1.1,11.1.1)
oracle.portlet-producer.jpdk(11.1.1,11.1.1)
oracle.portlet-producer.wsrp(11.1.1,11.1.1)
これらのライブラリそれぞれのターゲットを新しい管理対象サーバーに設定します。また、次のアプリケーションをデプロイするためのターゲットとなるクラスタを設定します。
DMSアプリケーション
Oracle WebLogic Server管理コンソールの左側のペインで、「サービス」→「JDBC」→「データ・ソース」をクリックします。次のデータソースのターゲットが、新規作成したクラスタに設定されていることを確認します。
mds-OWSM
|
注意: カスタム・アプリケーション用に独自のMDSスキーマを作成した場合は、その新しいMDSスキーマを新しいクラスタに割り当て、2つの事前定義済MDSスキーマは省略します。 |
Oracle WebLogic Server管理コンソールの左側のペインで「環境」をクリックし、「起動クラスと停止クラス」をクリックします。次に一覧表示するクラスが使用可能になります。
監査ローダー起動クラス
DMS-起動
JMXフレームワーク起動クラス
JOC-起動
JPS-起動クラス
JRF起動クラス
ODL-起動
OWSM起動クラス
次のようにクリックし、これらのクラスすべてのターゲットを新しいクラスタに設定します。
各起動/停止クラスの名前→「ターゲット」タブ→「CustomManagedServer」チェック・ボックス→「保存」
これらの手順を完了すると、Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを起動し、カスタム・アプリケーションをデプロイできるようになります。カスタム・アプリケーションは、管理対象サーバーのターゲットでなく、クラスタのターゲットにデプロイします。
各起動/停止クラスの名前→「ターゲット」タブ→「CustomManagedServer」チェック・ボックスをクリックし、これらすべてのクラスのターゲットを新しいクラスタに設定します。
「保存」をクリックします。
変更をアクティブ化します。
これらの手順を完了すると、Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを起動し、カスタム・アプリケーションをデプロイできるようになります。カスタム・アプリケーションは、管理対象サーバーのターゲットでなく、クラスタのターゲットにデプロイします。
引き続きWebCenterの高可用性デプロイメントを構成するには、『Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter』を参照してください。
