| Oracle® Fusion Middleware高可用性ガイド 11g リリース1(11.1.1) B55898-03 |
|
 前 |
 次 |
この章では、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モデルです。この仕様は、宣言的なデータ・バインディング・メタデータへアクセスするためのAPIを提供します。Oracle ADFモデル・レイヤーでは、統一されたアプローチを使用して、任意のユーザー・インタフェースとビジネス・サービスをコードを記述することなくバインドすることが可能です。
Fusion Webアプリケーション・テクノロジ・スタックを構成する他のモジュールは次のとおりです。
Oracle ADFビジネス・コンポーネントは、ビジネス・サービスの構築を簡素化します。
Oracle ADF Facesは、JavaServer Faces(JSF)で構築されたWebアプリケーションに対し、AJAX対応のUIコンポーネントのリッチ・ライブラリを提供します。
Oracle ADF Controllerは、JSFをOracle ADFモデルに統合します。ADF Controllerは、追加機能を提供することにより標準のJSFコントローラを拡張します。この追加機能には、JSFページ間だけでなく他のアクティビティ(メソッドのコールや他のタスク・フローなど)間の制御も渡す再使用可能なタスク・フローなどがあります。
図6-2は、Fusion Webアプリケーション・アーキテクチャにおける各Oracle ADFモジュールの適合を示しています。
ADFビジネス・コンポーネントは、ビルトイン・アプリケーション・オブジェクトであり、高性能で機能の豊富なデータベース中心のサービスの提供と維持を迅速化します。サービス指向のJava EEアプリケーションを作成するとき、開発者はコア・ビジネス・ロジックを1つ以上のビジネス・サービスとして実装します。これらのバックエンド・サービスは、適切なビジネス・ルールを施行し、かつ必要に応じてビジネス・データの問合せ、挿入、更新および削除を行う手段をクライアントに提供します。ADFビジネス・コンポーネントは、Java EEの設計パターンとベスト・プラクティスを即座に実装できるようにします。
Oracle ADFビジネス・コンポーネントは、データベース中心のビジネス・サービスの作成を簡略化するために次の主要なコンポーネントを提供しています。
エンティティ・オブジェクト
エンティティ・オブジェクトは、データベース表内の1行を表し、すべてのデータ操作言語(DML)操作を処理することでデータ変更を簡略化します。また、ビジネス・ロジックをカプセル化し、ビジネス・ルールが一貫して適用されることを保証します。開発者は、エンティティ・オブジェクトを他のエンティティ・オブジェクトと関連付け、基盤となるデータベース・スキーマの関係を反映することで、複数のアプリケーションで再使用できるビジネス・ドメイン・オブジェクトのレイヤーを作成します。
ビュー・オブジェクト
ビュー・オブジェクトはSQL問合せを表し、その結果の操作を簡略化します。開発者は、SQL言語を使用し、ユーザー・インタフェースで表されるエンド・ユーザーのタスクが必要とする形に、データを結合、計画、フィルタ、ソートおよび集約します。これには、ビュー・オブジェクトを他のエンティティ・オブジェクトにリンクし、複雑度に関係なくマスター/ディテール階層を作成する機能が含まれます。エンド・ユーザーがユーザー・インタフェースでデータを変更すると、ビュー・オブジェクトはエンティティ・オブジェクトと連携し、変更内容が一貫して検証され、保存されます。
アプリケーション・モジュール
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。これによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。
Oracle ADFビジネス・コンポーネントの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
モデル・レイヤーでは、Oracle ADFモデルによって、データ・コントロールと呼ばれるJSR-227サービス抽象化が実装されます。データ・コントロールは標準のメタデータ・インタフェースを使用して、関係のあるプロパティ、メソッドおよびタイプに関する情報など、サービスの操作とデータ・コレクションを記述することで、ビジネス・サービスの実装テクノロジを抽象化します。Oracle JDeveloperでは、開発者はその情報をアイコンとして表示し、ページに簡単にドラッグ・アンド・ドロップできます。開発者がサービス表現をページにドラッグすると、Oracle JDeveloperによって、そのページからサービスへのバインディングが自動的に作成されます。実行時にADFモデル・レイヤーによって、アプリケーションのデータ・コントロールおよびデータ・バインディングを記述した情報が該当するXMLファイルから読み取られ、ユーザー・インタフェースとアプリケーションのビジネス・サービス間の双方向接続が実装されます。
Oracle ADFは、最も一般的なビジネス・サービス・テクノロジに対し、すぐに実装可能なデータ・コントロールを提供します。ユーザー・インタフェースの構築にOracle JDeveloperとOracle ADFを併用すると、ドラッグ・アンド・ドロップを使用した宣言的なデータ・バインディングが可能になります。ADFビジネス・コンポーネント・アプリケーション・モジュールのサポートのほかに、ADFモデルは次のサービス・テクノロジに対するサポートも提供します。
Enterprise JavaBeans(EJB)のセッションBeanとJPAエンティティ
JavaBeans
Webサービス
XML
CSVファイル
Oracle ADFモデルの詳細は、『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 WebLogic Serverにインストールするには、Oracle JDeveloperインストーラまたはOracle Fusion Middleware Application Developerインストーラを使用します。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モデル・レイヤーを使用してADF Facesコンポーネントをアクティブ・データ・ソースにバインドできます。JDeveloperでは、JSFページ内で個々のコンポーネントを構成し、アクティブ・データを表示します。アクティブ・データを使用するようにコンポーネントを構成すると、データ・ソースによって変更イベントが発生するたびにデータがクライアントにプッシュされます。データはサーバーからクライアントにプッシュされ、ブラウザで表示されます。
アクティブ・データを表示するように構成されているページに対してフェイルオーバーをサポートするには、ADFビジネス・コンポーネント・アプリケーション・モジュールのフェイルオーバーを有効にし、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クライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。これによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。アプリケーション・モジュールは、そのトランザクション状態を非アクティブ化する、またはスナップショットとしてデータベースに格納することをサポートしています。また、これらの保存済スナップショットのいずれかからトランザクション状態をアクティブ化する逆の操作もサポートしています。
アプリケーション・モジュールの状態管理の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のFusion Webアプリケーションの状態管理の概要に関する項を参照してください。
ADFビジネス・コンポーネントのフェイルオーバーのサポートを有効にするには、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ページ・フロー - スコープ・マップのBeanが変更されました」は、コードがBeanでsetterメソッドを呼び出す際、続いてControllerContext.markScopeDirty()メソッドを呼び出さなかったことを開発者に警告します。この監査ルールは、adf-config.xmlファイル内のadf-scope-ha-supportフラグがtrueに設定されている場合にのみ適用されます。
「ADFページ・フロー - EL Beanが変更されました」は、BeanをミューテーションするEL式をコードが評価する際、続いて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 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ビジネス・コンポーネントの構成を確認します。
Oracle ADFは、デフォルトではフェイルオーバーするように構成されていません。フェイルオーバーは、ADFビジネス・コンポーネントの構成ファイル(bc4j.xcfg)に次の適切な設定が含まれている場合にのみサポートされます。
<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.1項「アプリケーション・モジュールの構成」で説明されているように、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によってサポートされます。
表6-1は、このプロパティで使用できるオプションを示しています。オプションを区切るには、カンマを使用します。
表6-1 CHECK_STATE_SERIALIZATIONのオプション
| オプション | 説明 |
|---|---|
|
tree |
コンポーネント・ツリー全体がシリアライズ可能かどうかをチェックします。これは最も高速なコンポーネントのチェックであり、ほとんどのテストはこのフラグを有効化して実行する必要があります。 |
|
component |
シリアライズ可能性について各コンポーネントを個別にチェックします。このオプションはtreeよりも低速であり、通常、treeでエラーが報告された場合にのみオンにします。このオプションは問題のあるコンポーネントを絞り込むために使用します。 |
|
property |
シリアライズ可能性について各コンポーネント属性を個別にチェックします。これはcomponentよりも低速であり、treeまたはcomponentモードで障害が検出された後に問題のある特定のコンポーネント属性を絞り込むために使用します。 |
|
session |
シリアライズ可能とマークされているJSF Session Mapのすべての属性が実際にシリアライズ可能であることをチェックします。 |
|
application |
シリアライズ可能とマークされているJSF Application Mapのすべての属性が実際にシリアライズ可能であることをチェックします。 |
|
beans |
該当するマップのシリアライズ可能なオブジェクトのシリアライズ可能なコンテンツがリクエスト中に変更された場合に、そのオブジェクトがダーティとマークされたことをチェックします。 |
|
all |
すべてをチェックします。 |
高可用性をテストするには、まず次のシステム・プロパティを使用してアプリケーション・サーバーを起動し、セッションおよびJSFの状態がシリアライズ可能であることを確認します。
-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree
次のようにbeansオプションを追加して、該当するマップのシリアライズ可能なオブジェクトのシリアライズされたコンテンツがリクエスト中に変更された場合に、そのオブジェクトがダーティとマークされたことをチェックします。
-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree,beans
JSFの状態がシリアライズ不能であることが検出された場合は、次のシステム・プロパティを使用してアプリケーション・サーバーを再起動し、コンポーネントとプロパティのフラグを有効にしてからテストを再実行します。
-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all
これらはJavaシステム・プロパティであるため、アプリケーション・サーバーの起動時に指定する必要があります。
この項では、サンプルとして示したOracle ADFの高可用性デプロイメントを構成する方法について説明します。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
次のリストは、この項で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが配置されている場所を表します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middleware SOA Suiteがインストールされている場所を指します。
ORACLE_COMMON_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリ・ファイルおよびライブラリ・ファイルが含まれているOracleホームを指します。
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
WL_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(Oracle RAC)データベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。
最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。
最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
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 LISTEN | grep ":7777" Windows: netstat -an | findstr "LISTEN" | 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およびOracle Business Process Management Suiteインストレーション・ガイド』を参照してください。 |
「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。
「インストールの進行状況」画面で、次の操作を行います。
UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。
「構成が完了しました」画面で、「終了」をクリックして終了します。
次の各項に記載されている情報を使用して、Oracle Fusion Middlewareコンポーネントをインストールします。
最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。
アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。
UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle WebLogic Serverインストーラを起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
ORACLE_BASE/product/fmw
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「JDKの選択」画面で、「Oracle JRockit 1.6.0_14 SDK」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
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_14_R27.6.4-18
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
「ミドルウェア・ホーム」には、ORACLE_BASE/product/fmwと入力します。
「Oracleホーム・ディレクトリ」には、たとえばadfのように、使用するディレクトリを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール 完了」画面で「終了」をクリックします。
|
注意: 第6.2.6項「WebLogic ServerのADFドメインを作成するためのAPPHOST1での構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareの最新のパッチ・セットなどの既知のパッチをMiddlewareホームに適用して、Oracle Fusion Middlewareを最新バージョンにしておいてください。最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。 |
Oracle WebLogic Server管理サーバーの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。
MiddlewareホームのadfディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracleコンポーネントが格納されるドメインを作成します。
次のコマンドを使用して、MW_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。
APPHOST1> ./config.sh
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。
Oracle Enterprise Manager - 11.1.1.0
Oracle JRF - 11.1.1.0
「次へ」をクリックします。
「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択
JDKの選択: 「Oracle JRockit 1.6.0_14 SDK」を選択
「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「次へ」をクリックします。
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: 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」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
管理サーバーとWLS_ADF1管理対象サーバーを再起動します。
APPHOST2でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「WLS_ADF2」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
管理サーバーとWLS_ADF2管理対象サーバーを再起動します。
APPHOST1でノード・マネージャを起動するには、次の手順を実行します。
ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
OAHOST1> cd ORACLE_COMMON_HOME/common/bin APPHOST1> ./setNMProps.sh
|
注意: クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。 |
ノード・マネージャを起動します。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
APPHOST2に対し、WebLogic ServerとOracle ADFのインストール手順を繰り返します。第6.2.3項「WEBHOST1へのOracle HTTP Serverのインストール」の手順から始めてください。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。
次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST2に伝播します。
次のpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cd WL_HOME/common/bin
APPHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/
-template=adfdomaintemplate.jar
-template_name=adf_domain_template
前の手順で作成したテンプレート・ファイルをAPPHOST1からAPPHOST2にコピーします。たとえば、UNIXプラットフォームでは次のようにします。
APPHOST1> scp adfdomaintemplate.jar
user@node2:WL_HOME/common/bin
unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。
APPHOST2> cd WL_HOME/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 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管理コンソールから、WC_Spaces1、WC_Spaces2、WC_Collaboration1、WC_Collaboration2、WC_Portlet1およびWC_Portlet2を次のように起動します。
次のURLの管理コンソールにアクセスします。
http://APPHOST1/console
管理対象サーバーのいずれか(例: WC_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 ADFトポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。
この場合は、Oracle ADFを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードの共有記憶域には、Middlewareホームが格納されています。
新しいサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。Oracle Fusion Middlewareのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
トポロジをスケール・アップするには、次の手順を実行します。
Oracle WebLogic Server管理コンソールを使用し、WLS_ADF1のクローンを作成して新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。
管理コンソールから「環境」→「サーバー」を選択します。
クローンを作成する管理対象サーバーを選択します。
「クローンの作成」を選択します。
新しい管理対象サーバーにWLS_ADFnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。
この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。
Oracle HTTP Serverモジュールをクラスタの新しいメンバーで再構成します。第6.2.9.5項「Oracle HTTP Serverの管理サーバーおよびOracle WebCenter管理対象サーバーの構成」を参照してください。
トポロジのスケール・アウトでは、Oracle ADFアプリケーションを使用して構成されている新しい管理対象サーバーを新しいノードに追加します。
この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。
トポロジ内には、ADFアプリケーションを使用して構成されている管理対象サーバーを実行しているノードがすでに存在しています。
ADF管理対象サーバーはクラスタ化されており、新しい管理対象サーバーもそのクラスタの一部になります。
新しいノードは、WebLogic Server用の既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。packとunpackを実行して管理対象サーバー・ドメインを作成する必要がありますが、WebLogic Serverバイナリを新しい場所にインストールする必要はありません。
トポロジをスケール・アウトするには、次の手順を実行します。
新しいノードで、既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
Oracle WebLogic Server管理コンソールを使用し、WLS_ADF1のクローンを作成して新しい管理対象サーバーにします。それにWLS_ADFnという名前を付けます。nはその新しいマシンに割り当てる番号です。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。
次の手順を実行して、管理対象サーバーのリスニング・アドレスを設定します。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。その管理対象サーバーの「設定｣ページが表示されます。
「リスニング・アドレス」をAPPHOSTnに設定します。APPHOSTnは新しいマシンのDNS名です。
「保存」をクリックします。
変更を保存およびアクティブ化します。
変更内容は、管理対象サーバーが再起動されるまでは有効になりません。
次のようにpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cd ORACLE_COMMON_HOME/common/bin APPHOST1> ./pack.sh -managed=true -domain=MW_HOME/user_projects/domains/ adfdomain/ -template=adfdomaintemplateScale.jar -template_name=adf_domain_templateScale
次のコマンドをAPPHOST1で実行し、作成したテンプレート・ファイルをAPPHOSTnにコピーします。
APPHOST1> scp adfdomaintemplateScale.jar oracle@APPHOSTN:/
ORACLE_COMMON_HOME/common/bin
次のようにAPPHOSTnでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
APPHOSTn> cd ORACLE_COMMON_HOME/common/bin APPHOSTN> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/ -template=adfdomaintemplateScale.jar
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
APPHOSTn> WL_HOME/server/bin/startNodeManager <new_node_ip>
Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーをすべて停止します。
新たに作成した管理対象サーバーが実行されていることを確認します。
新たに作成した管理対象サーバー上のアプリケーションにアクセスします。アプリケーションが機能している必要があります。
この項では、Oracle WebCenterの高可用性クラスタを設計するために必要な課題および考慮事項を紹介します。
Oracle WebCenterは、Java Server Faces(JSF)の標準ベースの宣言的な開発と、ポータルの柔軟性と能力、および一連の統合型Web 2.0サービスを組み合せたものです。
Oracle WebCenterのコンポーネントは次のとおりです。
Oracle WebCenter Spacesは、一連の堅牢なサービスとアプリケーションにより、ソーシャル・ネットワーキング、通信、コラボレーションおよび個人の生産性に対して、単一の統合されたWebベース環境を提供します。
Oracle WebCenter Spacesは、JSF、Oracle ADF、Oracle WebCenter Framework、Oracle WebCenterサービスおよびOracle Composerを使用して構築されています。Oracle WebCenter Spacesは次の機能を提供します。
ビジネス・ユーザーをターゲットとし、コミュニティに焦点を当てたブラウザベースのアプリケーション。
各ユーザーの個人用スペース。これは、個人用コンテンツの格納、メモの保存、ビジネス・プロセスの割当ての表示およびビジネス・プロセスの割当てへの応答、オンラインの友人のリストの保持、メールの送受信などを行う個人用作業領域となります。個人用スペースの目的は、個人の生産性を向上させることです。
機能の豊富なチーム・コラボレーション・プラットフォームであるグループ・スペース。
スレッド・ディスカッション、ワークリスト、お知らせ、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、ファイル・システムなどのコンテンツ・リポジトリへの、JCR(JSR170)を使用したコンテンツの統合
JSFページおよびOracle ADFタスク・フローを標準ベースのポートレットとして表示できるようにするJSFポートレット・ブリッジ
Oracle WebCenterディスカッション・サーバーは、ディスカッション・フォーラムやお知らせをアプリケーションに統合する機能を提供します。
Oracle WebCenter Analyticsは、Oracle WebCenter Spacesのインスタンス内での様々なユーザー・アクティビティに関するレポートを表示する機能を提供します。レポートには次のような項目が含まれます。
ログイン
ページ・ビュー
ポートレット・ビュー
ドキュメント・ビュー
検索メトリック
レスポンス時間
これらのレポートは、ユーザー・プロパティ、グループ・スペースおよび時間などのパラメータごとに抽出できます。
Oracle WebCenterアクティビティ・グラフは、Oracle WebCenter Analyticsで収集された統計を分析する機能を提供します。Oracle WebCenterアクティビティ・グラフによる分析の出力は、オブジェクトおよびユーザーについて収集されたスコアであり、リコメンデーションを示すために使用されます。これらのスコアはOracle WebCenter Activitiesデータベースに格納されます。
Oracle WebCenterパーソナライズ・サーバーは、RESTful Webサービスを介してクライアント・アプリケーションからアクセスされる軽量サービスです。新しいJDevツールは、Oracle WebCenterパーソナライズによって使用されるプロパティ定義およびシナリオの作成をサポートします。顧客向けの拡張モデルだけでなく、他のOracle WebCenterサービス(Oracleアクティビティ・グラフ、CMIS、People Connections)との統合がすぐに可能な状態でサポートされています。Oracle WebCenterパーソナライズ・サーバーは、ユーザーおよびアプリケーションのプロパティや値を定義する機能とともに、構造化シナリオを実装する機能を提供します。これらを使用することで、任意の種類のアプリケーションまたはアプリケーション・ロジックを、ユーザー、グループ、あるいその他のスコープに対してパーソナライズできるようになります。
Oracle WebCenter SpacesおよびカスタムWebCenterアプリケーション(Oracle WebCenterポータル・アプリケーション)は、次のOracle WebCenterサービスとも統合可能です。
お知らせ: 重要なアクティビティやイベントに関するお知らせを、特定のグループ・スペースのメンバーに投稿する手段を提供します。
ディスカッション: スレッド・ディスカッションの作成、質問の投稿と回答、およびグループ・スペースのコンテキスト内のすべての回答の検索を行う手段を提供します。重要なアクティビティやイベントに関して、グループが効果的に通信するためのメカニズムも提供します。
ドキュメント: コンテンツのアップロード、ファイルおよびフォルダの作成と管理、ファイルのチェックアウト、バージョニングなど、コンテンツ管理機能および記憶域機能を提供します。
イベント: Oracle WebCenter Spacesで使用可能なイベント・サービスは、広範なユーザーのグループに関連するイベントのスケジュールを作成および保持する手段を提供します。イベントは、グループ・スペースのすべてのメンバーに公開されます。
インスタント・メッセージおよびプレゼンス(IMP): 他の認証済ユーザーのステータス(オンライン、オフライン、ビジー、アイドルのいずれか)を観察し、これらのユーザーにすぐ連絡する手段を提供します。
リンク: 関連情報の表示、アクセスおよび関連付けを行う機能を提供します。たとえば、ディスカッション・スレッドからソリューション・ドキュメントにリンクできます。
リスト: Oracle WebCenter Spacesで使用可能なリスト・サービスは、リストや表を作成、公開および管理する機能を提供します。ユーザーはビルトイン構造からリストを作成するか、または独自のカスタム・リストを作成できます。
メール: IMAPメール・サーバーやSMTPメール・サーバーと簡単に統合することで、メッセージの表示、読取り、作成および削除、ファイル添付メッセージの作成、既存のメッセージへの応答または転送などの単純なメール機能を、ユーザーが実行できるようにします。
メモ: Oracle WebCenter Spacesで使用可能なメモ・サービスは、個人的に関係のある情報の一部を書き留めて保持する機能を提供します。
ピープル・コネクション: 掲示板、フィードバック、プロファイル、アクティビティ・ストリームなどのソーシャル・ネットワーキング・アプリケーションを通じて、他のユーザーへの接続、他のユーザーとの対話、および他のユーザーの追跡を行う手段を提供します。
最近のアクティビティ: ページ、ドキュメント、ディスカッション、お知らせ、リストおよびイベントに対する最近の変更のサマリー・ビューを提供します。
RSS: ニュース・リーダーという1つの場所から多くの異なるWebサイトのコンテンツにアクセスする機能を提供します。
検索: タグ、サービス、アプリケーションまたはサイト全体を検索する手段を提供します。これには、Oracle WebCenterの検索用にOracle Secure Enterprise Searchの統合も含まれます。
タグ: 任意のページまたはドキュメントに、個人的に関係のある1つ以上のキーワードを割り当てる手段を提供します。
ワークリスト: エンタープライズ内で作成されている様々なワークフローから通知を表示する手段を提供します。
これらのOracle WebCenterサービスの構成方法の詳細は、『Oracle Fusion Middleware Oracle WebCenter管理者ガイド』を参照してください。
Oracle WebCenterをインストールすると、Middlewareホーム・ディレクトリの下にWebCenterディレクトリが作成されます。このインストールによって、WebCenterドメイン(wc_domain)が作成されます。このドメインには、管理サーバー、および4つのWebLogic管理対象サーバーであるWC_Spaces1(Oracle WebCenter Spacesをホスト)、WC_Portlets(Oracle WebCenterポートレットをホスト)、WC_Collaboration1(Oracle WebCenterディスカッション・サーバーをホスト)、WC_Utilities1(Oracle WebCenter Analytics、Oracle WebCenterアクティビティ・グラフ、Oracle WebCenterパーソナライズ・サーバー、および統合する追加のWebCenterサービスをホスト)が含まれます。
オプションの5番目の管理対象サーバー(アプリケーション・サーバー)は、カスタムWebCenterアプリケーション(Oracle WebCenterポータル・アプリケーション)を実行するために使用する必要があります。追加の管理対象サーバーを作成する場合、それらがOracle WebCenter Spacesと同じ外部リソースを利用できるように適切なライブラリがプロビジョニングされます。管理対象サーバーの詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middlewareの概念の理解に関する項を参照してください。図6-4は、基本的な単一ノードOracle WebCenterアーキテクチャを示しています。
Oracle WebCenter SpacesはJava EEアプリケーションとして実行され、アプリケーションの状態と構成はMDSリポジトリに永続的に残ります。アプリケーション内のユーザー・セッション情報は、ローカルのメモリー内に保持されます。クラスタ環境では、この状態はクラスタの他のメンバーにレプリケートされます。
追加設定をしていないOracle WebCenterポートレットでは、データベースを使用してカスタマイズが保持されます。
Oracle WebCenterディスカッション・サーバーでは、データおよびメタデータに対して独自のデータベース永続メカニズムが使用されます。
Oracle Webcenter Analyticsは、2つのコンポーネントで構成されています。タスク・フローとデータ・コントロールで構成されるOracle Webcenter AnalyticsサービスとOracle WebCenter Analyticsコレクタ・サービスです。
Oracle WebCenterコレクタに送信されたイベントは、データベースに保存するための、構成可能な受信イベントのキューに格納されます。Oracle WebCenterコレクタ・サービスに障害が発生すると、これらのイベントは失われます。ただし、通常の使用ではこのキューに多数のイベントが格納されることはありません。
Oracle WebCenter Analyticsコレクタでは、クラスタ化とフェイルオーバーがサポートされていますが、キューはコレクタ間で共有されていません。
WebCenter用のレポートUIを提供するOracle WebCenter Analyticsサービス・タスク・フローはステートレスですが、パーソナライズおよびカスタマイズ機能は例外です。これらの機能は標準Composer/ADF/MDSフレームワークに基づいており、そのフレームワークでは障害イベントで状態が管理されます。
Oracle Webcenterアクティビティ・グラフは、2つのコンポーネントで構成されています。タスク・フローとデータ・コントロールで構成されるOracle WebCenterアクティビティ・グラフ・サービスとOracle WebCenterアクティビティ・グラフ・エンジンです。
このエンジンは、バッチ・データ分析プロセスを実行し、それによりデータベースの表がトランザクションで更新されます。クラスタ化とフェイルオーバーはサポートされていませんが、障害からのリカバリは可能です。
Oracle WebCenterアクティビティ・グラフ・サービスでは、メモリー内の状態は保持されません。これは基本的に読取り専用プロセスです。
Oracle WebCenter Spacesタスク・フローは、Oracle WebCenter Activitiesデータベースに問合せを行い、結果をリコメンデーションのリストとしてレンダリングします。次の3つの場所で状態が更新されます。
パーソナライズ設定
タスク・フロー構成パラメータ
「無関心」機能
最初の2つは、状態を管理する標準Composer/ADF/MDSフレームワークに基づいています。最後の1つはユーザーが特定のリコメンデーションに興味がないことを示すことができる機能です。この入力は、Oracle WebCenterアクティビティ・グラフ・データベースで同期的に保存されます。
管理者は、Oracle WebCenterアクティビティ・グラフ・ユーザー・インタフェースを使用して毎晩のスケジュールを設定および監視しますが、ユーザー・インタフェースに分析の結果は表示されません。分析結果(リコメンデーション)は、Oracle WebCenter Spacesタスク・フローに表示されます。これらのタスク・フローによってActivitiesデータベースに問合せが行われます。Oracle WebCenterアクティビティ・グラフ・バックエンドが数日間実行できない場合、それは致命的ではなく、Oracle WebCenterアクティビティ・グラフによるリコメンデーションの導出が妨げられることはありません。ただし、Oracle WebCenterアクティビティ・グラフ・バックエンドが再び実行されるまでは、リコメンデーションのうちのいくつかは古いものになります。
Oracle WebCenterアクティビティ・グラフは、定期的に起動するバックグラウンド・スレッドを持つシングルトン・アプリケーションです。それによって、数時間続行される可能性がある毎晩のジョブを実行する時間になったかどうかがチェックされます。そのスケジュールはデータベースにも格納されています。管理対象サーバーに障害が発生した場合、ジョブはそれが復帰したときに続行されます。
Oracle WebCenterパーソナライズ・サーバーは、ステートレスなRESTfulアプリケーションです。すべての状態は、クライアント・リクエスト内で管理されます。プロパティ・サービスとシナリオを支援するJDevツールによって作成されるOracle WebCenterパーソナライズ・メタデータはMDSに格納されます。追加の構成データ(接続情報)は、ドメイン・スコープ指定マネージドBeanに格納されます。
Oracle WebCenter Spacesは、Oracle WebCenter Analytics、Oracle WebCenterアクティビティ・グラフ、およびOracle WebCenterパーソナライズ・サーバーのクライアントです。
Oracle WebCenter Analyticsでは、アクティビティ・スキーマを含むデータベースが使用されます。Oracle WebCenterアクティビティ・グラフでは、アクティビティ・スキーマに格納されているデータを使用してリコメンデーションが提供されます。Oracle WebCenterパーソナライズ・サーバーでは、パーソナライズ・スキーマおよびMDSスキーマのためのデータベースが使用されます。
クライアントからOracle WebCenterパーソナライズ・サーバーへの接続にはJDBCおよびUDPが使用されます。
Oracle WebCenterパーソナライズ・サーバーでは、REST、JDBC、ADF接続アーキテクチャおよびMDS JMXが使用されます。
Oracle WebCenterアクティビティ・グラフは、JDBCを使用してアクティビティ・スキーマ内の統計データを掘り出します。クライアント(Oracle WebCenter Spaces)もJDBCを使用してアクティビティ・スキーマに接続し、ユーザーにデータを表示します。
Oracle WebCenter Spacesは、Oracle WebCenter Analyticsとの通信にJava Client APIを使用します。このAPIはOpenUsageに基づいており、UDPによるマルチキャストを使用します。
表6-2は、Oracle WebCenterの各コンポーネントおよびサービスのアクセス・タイプを示しています。「構成」列には、接続を構成または初期化するためにOracle WebCenterに提供されている情報のタイプが一覧表示されています。「アクセス」列には、サービスのランタイム・アクセスで使用するプロトコルが一覧表示されています。
Oracleディスカッション・サーバーはOracle WebCenter Spacesに対するサービス・プロバイダです。Oracleポートレットも、サービスとしてポートレット・プロデューサを公開します。
これらのサービスを使用できなくても、Oracle WebCenter Spacesアプリケーションは起動できますが、実行時にアプリケーション・エラーが表示されることがあります。Oracle WebCenter SpacesにはMDSおよびWebCenterスキーマが必要です。
表6-2 Oracle WebCenterのアクセス・タイプ
| 外部サーバー/サービス | 構成 | アクセス |
|---|---|---|
|
Oracleディスカッション・サーバー |
ディスカッション・サーバー管理へのHTTPアクセス |
SOAP/HTTP |
|
Oracle Content Server(ドキュメント) |
管理サーバーへのソケット接続。HTTPアクセスは、コンテンツ・サーバーにOracle WebCenterの外部でアクセスする必要がある場合にのみ必要です。 |
ソケットを使用したJCR 1.0、またはHTTP |
|
インスタント・メッセージおよびプレゼンス・サーバー |
インスタント・メッセージおよびプレゼンス・サーバー管理へのHTTPアクセス |
SOAP/HTTP |
|
メール・サーバー |
IMAP/SMTPサーバー |
IMAP/SMTP |
|
個人イベント・サーバー |
カレンダ・サービスへのHTTPアクセス |
SOAP/HTTP |
|
ポートレット |
プロバイダWSDLのHTTP場所 |
SOAP/HTTP |
|
検索サーバー |
検索サーバーへのHTTPアクセス |
HTTP |
|
ワークリスト |
BPELサーバーへのHTTPアクセス |
SOAP/HTTP |
|
MDSリポジトリとスキーマ |
JDBC |
JDBC |
|
Oracle WebCenter Analytics |
Oracle WebCenter AnalyticsコレクタへのUDPアクセス |
UDP |
|
Oracle WebCenterアクティビティ・グラフ |
Oracle WebCenterアクティビティ・グラフへのHTTPアクセス |
HTTP |
|
Oracle WebCenterパーソナライズ・サーバー |
Oracle WebCenterパーソナライズ・サーバーへのJDBCアクセス |
JDBC、REST |
各外部サービスの高可用性は個別に構成します。Oracle WebCenterのフレームワークは、外部サービスに対して単一のアクセス・ポイントを提供します。
たとえば、HTTPサービスでは、アクセスURLをロード・バランサにダイレクトします。ロード・バランサは、バックエンドで複数のサービス・プロバイダへのアクセスを提供します。
高可用性のためOracle WebCenter Discussions Serverを構成する手順は、第6.4.5項「WebLogic ServerのWebCenterドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」で説明されています。
MDSリポジトリおよびスキーマについては、バックエンド・データベースとしてOracle Real Application Clusters(Oracle RAC)をお薦めします。
データベース・プロバイダとしてOracle RACを構成する手順は第6.4.5項「WebLogic ServerのWebCenterドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」で説明されています。
Oracle RACおよびMDSリポジトリでのマルチ・データ・ソースの構成の詳細は、第4.1.2項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
Oracle WebCenterアプリケーションの主な構成ファイルを表6-3に示します。これらのファイルはどちらもOracle WebCenterアプリケーション・デプロイメントEARファイル内に提供されています。
表6-3 Oracle WebCenterの構成ファイル
| アーティファクト | 用途 |
|---|---|
|
|
Oracle Application Development Framework(ADF)およびOracle WebCenterアプリケーションの設定の基本構成を格納します(WebCenterアプリケーションが現在使用しているディスカッション・サーバーやメール・サーバーなど)。 |
|
|
外部サービスへの接続に関する基本構成を格納します。 |
Oracle WebCenterアプリケーションとポートレット・プロデューサは両方とも、Oracle Metadata Services(MDS)リポジトリを使用してその構成データを格納し、MDSリポジトリにはOracle WebLogicフレームワーク内のJDBCデータ・ソースとしてアクセスします。
MDSリポジトリには、Oracle WebCenterアプリケーションおよびポートレット・プロデューサのデプロイメント後の構成の変更が、カスタマイズとして格納されます。MDSは、元のデプロイ済バージョンのadf-config.xmlおよびconnection.xmlをベース・ドキュメントとして使用し、その後のカスタマイズはすべて、単一のカスタマイズ・レイヤーを使用してMDSに個別に格納します。
Oracle WebCenterアプリケーションが起動すると、MDSに格納されているカスタマイズが適切なベース・ドキュメントに適用され、Oracle WebCenterアプリケーションは、マージ済ドキュメント(カスタマイズが適用されたベース・ドキュメント)を構成プロパティの最終セットとして使用します。
サーバー・クラスタにデプロイされているOracle WebCenterアプリケーションの場合、クラスタの全メンバーは、MDSリポジトリ内の同じ場所から読取りを行います。
デプロイメント後の構成のための管理ツールがいくつか提供されているため、通常、管理者がadf-config.xmlやconnection.xmlなどのファイルについてベース・ドキュメント(またはMDSカスタマイズ・データ)のコンテンツを調べたり、手動で変更する必要はありません。詳細は、Oracle Fusion Middleware Oracle WebCenter管理者ガイドのOracle WebCenter管理ツールに関する項を参照してください。
|
注意: 特別な指示がないかぎり、adf-config.xmlまたはconnection.xmlを手動で編集することはお薦めしません。編集すると、不適切な構成になる場合があります。 |
Oracle WebCenterアプリケーションは、デプロイメント後の構成情報をMDSに格納しますが、ポートレット・プロデューサおよびOracle WebCenter Discussions Serverの構成情報はファイル・システムに格納されます(表6-4を参照)。
表6-4 Oracle WebCenterの構成情報の格納場所
| アプリケーション | 構成情報の格納場所がMDS | 構成情報の格納場所がファイル・システム | 構成情報の格納場所がデータベース |
|---|---|---|---|
|
Oracle WebCenter Spaces |
はい |
いいえ |
いいえ |
|
Oracle WebCenterポータル・アプリケーション(カスタム・アプリケーション) |
はい |
いいえ |
いいえ |
|
ポートレット・プロデューサ |
いいえ |
はい |
いいえ |
|
ディスカッション・サーバー |
いいえ |
はい |
はい |
Oracle WebCenterディスカッション・サーバーでは、構成情報はそのデータベースに格納されます。また、起動構成情報はDOMAIN_HOME/config/fmwconfig/servers/SERVER_NAME/owc_discussions_11.1.1.4.0に格納されます。このディレクトリには、jive_startup.xmlファイル、jive.licenseファイル、およびディスカッション・サーバー・インスタンスのログ・ファイルを含む\logsディレクトリが格納されています。
Oracle WebCenter Analyticsは、クライアントに対してWLSTコマンドを使用します。JVMパラメータも指定でき、これによってWLST値がオーバーライドされます。以前のリリースのOracle WebCenterのsetDomainEnv.shでJVMパラメータを指定した場合、Oracle WebCenter Analyticsを使用するには、それらを削除する必要があります。
Oracle WebCenterアクティビティ・グラフ・エンジンによって、ディスクに一時ファイルが書き込まれます。これらが消失した場合は、再作成されます。
Oracle WebCenterパーソナライズ・サーバーには、そのプロバイダ接続のためのJMX Beanがあり、それはクラスパスに指定されたprovider-connections.xmlからブートストラップされます。WLSTコマンド・スクリプトは、JMXによるOracle WebCenterパーソナライズ・プロバイダ接続の構成をサポートしています。これらのBeanは、Oracle Enterprise ManagerまたはJConsoleからも管理できます。
Oracle WebCenterアプリケーション、ポートレット・プロデューサ、ディスカッション・サーバーなどで実行された操作は、アプリケーションが稼働しているWebLogic管理対象サーバーの次のログに直接記録されます。
WLS_DOMAIN_HOME/servers/WLS_SERVER_NAME/logs/WLS_SERVER_NAME.log
Oracle WebLogic Server管理コンソールから各WebLogic管理対象サーバーのログ・ファイルを表示できます。ログを表示するには、Oracle WebLogic Server管理コンソールhttp://<admin_server_host>:<port>/consoleにアクセスして、「診断-ログ・ファイル」をクリックします。
Oracle WebCenter Analyticsは、コレクタ内のApache Commonsロギング、およびコレクタのインストールに使用したドメイン・テンプレートのODL構成ファイルを使用することによって現在のWebLogic Serverロギング・フレームワークと統合されます。ODLロギング構成ファイルは、構成ウィザードを使用してコレクタをインストールするときにWebLogic Serverのデフォルト・ロギング構成ファイルとマージされます。ODLロギング構成ファイルがWebLogic Serverのデフォルト・ロギング構成ファイルとマージされるときに、DOMAIN_HOME/config/fmwconfig/servers/WLS_Utilitiesフォルダに生成されたlogging.xmlファイルを開くと、collector-log-handlerという名前のログ・ハンドラのロギング設定がみつかります。
また、管理対象サーバーのログ・ディレクトリに診断ログが作成されます。このログの粒度とロギング・プロパティは、DOMAIN_HOME/config/fmwconfig/servers/SERVER_NAME/logging.xmlファイルで変更できます。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内の別のメンバーがリクエストを処理できます。
Oracle WebCenterデプロイメント内の各管理対象サーバーを1つのクラスタにデプロイできます。この場合、異なるクラスタ・メンバーを同じノードにデプロイすることも、異なるノードにデプロイすることもできます。図6-5では、クラスタに送信されるすべてのリクエストはクラスタのいずれのメンバーでも処理できます。
次の各項では、Oracle WebCenterクラスタのランタイムと構成の両面に関して詳細に説明します。
Oracle WebCenterのインストール中に、管理対象サーバーにシステム・ライブラリとADFライブラリがプロビジョニングされます。表6-5に、管理対象サーバーとそれらで実行されるアプリケーションの一覧を示します。
表6-5 Oracle WebCenterの管理対象サーバーとアプリケーション
| 管理対象サーバー | アプリケーション |
|---|---|
|
WC_Spaces |
Oracle WebCenter Spaces Oracle WebCenter Spacesヘルプ |
|
WC_Portlets |
OmniPortletおよびWebClipping |
|
WC_Collaboration |
Oracle WebCenterディスカッション・サーバー |
|
WC_Utilities |
Oracle WebCenter Analytics、Oracle WebCenterアクティビティ・グラフおよびOracle WebCenterパーソナライズ・サーバー |
管理対象サーバーが起動すると、アプリケーションとライブラリは次の順序で起動します。
Oracleシステム・ライブラリ(別名、JRFライブラリ)
Oracle ADFライブラリ
インスツルメンテーション・アプリケーション(Oracle DMSなど)
Oracle WebCenterアプリケーション(表6-2)
起動順序は依存性の順序でもあります。依存コンポーネントが正しくデプロイされないと、その後のコンポーネントが正しく機能しない場合があります。Oracle WebCenterアプリケーションの起動は、Oracleディスカッション・サーバーなどの外部サービスやその他のバックエンド・サーバーの可用性に依存しません。
図6-5に示すようなOracle WebCenterクラスタ・デプロイメントでは、アプリケーション、ライブラリおよびシステム・リソースのターゲット設定に関して、次のルールに従います。
アプリケーションとライブラリのターゲットをクラスタのターゲットに設定します。たとえば、WebCenterアプリケーションのターゲットをSpacesクラスタに設定します。
JDBCリソースをクラスタのターゲットに設定します。
Oracle WebCenterアプリケーションおよびOracle WebCenterディスカッション・サーバーは、Oracle WebLogicstageアプリケーションとしてデプロイされます。各アプリケーションの初期デプロイメント中に、デプロイメント・ファイルが管理サーバーから送信され、ローカルにデプロイされます。
デフォルトでは、各Oracle WebCenterクラスタはユニキャストとして構成されます。Oracle WebCenterクラスタをマルチキャスト用に構成するには、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』を参照してください。
Oracle WebCenter Analyticsは、Oracle WebCenter SpacesなどのOracle WebCenter Analyticsクライアントからリクエストを受信する個別のコレクタで構成されています。
この項では、Oracle Analyticsコレクタ・クラスタがどのように機能するのかを説明します。
クラスタ化された環境では、プロデューサ(コレクタのクライアント)およびコレクタは、クラスタ固有のチャネル名で構成されます。各コレクタは、その場所からクラスタ固有のチャネルで定期的にハートビートをブロードキャストします。プロデューサはそのチャネルでこれらのコレクタのハートビートをリスニングし、ハートビートを受信すると、そのコレクタを既知のコレクタのリストに追加します。プロデューサがイベントを送信する必要がある場合は、ラウンドロビン・アルゴリズムを使用してそのリストからコレクタを選択し、そのコレクタにイベントを送信します。コレクタが停止すると(意図的であるか障害であるかに関係なく)、ハートビートのブロードキャストは停止します。プロデューサがハートビートの受信を停止した場合、そのコレクタをリストから削除して、そのコレクタへのイベントの送信を停止します。いずれのコレクタのハートビートも受信しない場合は、イベントを送信しません。
Oracle WebCenter Analyticsは、構成された一連のポート上でUDPおよびマルチキャストを使用してクライアントと通信します。単一ノード・セットアップでは、クライアントは、サーバー・ホストとポートの場所を持つWLSTコマンドで構成され、単にすべてのイベントをUDPを使用してその場所に送信します。複数ノード・セットアップでは、サーバーは、クラスタで実行されている様々なサーバーの場所に(UDPマルチキャストを使用して)ブロードキャストするように構成され、クライアントは同じWLSTコマンドで構成されます。したがってクライアントは、これらのサーバーの場所を受信し、使用可能なサーバーのリストを保持します(これはメモリー内に格納されます)。さらに、クライアントがサーバーから定期的なハートビートを受信せず、それが機能していない場合は、そのサーバーを既知のサーバーのリストから削除してイベントの送信を停止します。
コレクタは、Oracle WebCenter Analyticsクライアントと1対1の関係になるようにユニキャストとして構成することをお薦めします。
Oracle WebCenterは、いくつかのステートフル・コンポーネントを持つOracle ADFに依存しています。Oracle WebCenter自体もステートフル・アプリケーションです。したがって、クラスタ・シナリオでは状態レプリケーションを構成する必要があります。
Oracle WebLogic Serverの状態レプリケーションの動作の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』を参照してください。
Oracle WebLogic Serverは、次の2種類の状態のレプリケーションをサポートしています。
メモリー内レプリケーション: Oracle WebLogic Serverはメモリー内レプリケーションを使用して、1つのサーバー・インスタンスから別のインスタンスにセッション状態をコピーします。プライマリ・サーバーは、クライアントが最初に接続するサーバーにプライマリ・セッション状態を作成し、クラスタ内の別のWebLogic Serverインスタンスにセカンダリ・レプリカを作成します。このレプリカは最新状態に維持されるため、サーブレットをホストしているサーバーに障害が発生した場合に使用できます。
JDBCベースの永続性: JDBCベースの永続性では、Oracle WebLogic Serverは、ファイル・ベースまたはデータベース・ベースの永続性を使用して、サーブレットまたはJSPのHTTPセッション状態を保持します。
状態のレプリケーションを適切に構成するには、環境とアプリケーションの両方を適切に構成する必要があります。フェイルオーバーの状況における状態のレプリケーションの動作の詳細は、第6.3.2.8項「アプリケーションのフェイルオーバーで予想される動作」を参照してください。
状態のレプリケーションにおける問題の診断の詳細は、第6.3.2.5項「Oracle WebCenterの状態のレプリケーション」を参照してください。
Oracle WebCenterアプリケーションでは、パフォーマンス向上のために分散Javaオブジェクト・キャッシュが使用されています。このキャッシュはすべてのOracle WebCenterクラスタで構成し、クラスタごとに分散キャッシュを1つずつ用意します。
表6-6は、Oracle WebCenterがJavaオブジェクト・キャッシュに配置するオブジェクト・タイプの例を一覧表示しています。
表6-6 Oracle WebCenterのJavaオブジェクト・キャッシュ用のオブジェクト・タイプ
| Oracle WebCenterコンポーネント | キャッシュされるオブジェクト |
|---|---|
|
ディスカッション・サービス |
トピックとフォーラム |
|
お知らせサービス |
お知らせ |
|
インスタント・メッセージおよびプレゼンス・サービス |
プレゼンス・サブスクリプション・リスト ユーザーのプレゼンス/サブスクリプション・ステータス |
|
ワークリスト・サービス |
呼び出されたワークリスト項目(キャッシュ済データは、リフレッシュが呼び出されるまで使用されます)。 |
|
コンテンツ統合(Oracle Portal) |
JCR: リポジトリから取得したタイプ情報とメタデータ。 |
|
サービス・フレームワーク |
ユーザー・プロファイル。問合せされたユーザー名。 |
|
最近のアクティビティ |
ユーザーごとの最近のアクティビティ結果。 |
|
WebCenter Spaces |
アプリケーション内のグループ・スペースとグループ・スペース・テンプレートのグローバル・リスト。 ユーザーがアクセス可能なグループ・スペースとグループ・スペース・テンプレートのリスト。 |
|
ページ・サービス |
スコープ内のページのリスト。 |
|
WSRPサーバー |
WSRPプロデューサのプリファレンス・ストアの値。 |
|
ドキュメント・サービス |
Oracle WebCenter Spacesアプリケーション用に構成されたドキュメント・サービスのプロビジョニングと構成のチェック |
|
プロファイルの管理 |
軽量ユーザー・プロファイル・オブジェクト |
|
ナビゲーション・サービス |
アクティブなナビゲーション・モデル・オブジェクトのリスト |
|
ポートレット・コンシューマ |
ポートレット・マークアップ |
コラボレーション
コラボレーション・サービスは、ユーザー・セッションごとにオブジェクトをJavaオブジェクト・キャッシュに格納します。HTTPセッションが破棄されると、これらのキャッシュ済ユーザー・セッションも破棄されます。
ワークリスト
ワークリストは、呼び出された項目をキャッシュするため、リフレッシュ・ボタンがクリックされるか、または15分ごとにリフレッシュ・ポーリングがトリガーされないかぎり、ユーザーが設定によってソートやグループを変更する際に同じ項目が表示されます。表示もグループおよびソートの順序の設定によってキャッシュされ、変更が行われたときに更新されます。これは読取り専用データで、存在しない場合にはフェッチされてキャッシュに格納されます。
Oracle WebCenter Spaces
すべてのテンプレートおよびパブリック・スペースのリストは、Javaオブジェクト・キャッシュに保持されます。特定のユーザーがアクセスできるグループ・スペースとテンプレートのリスト以外に、このスペースもすべてのユーザーによって共有されます。これらはユーザーごとにキャッシュされます。1つのJVMで作成されるテンプレートは、テンプレート・キャッシュが別のJVMで初期化されている場合には表示されません。ただし、JOCがデータを配布するか、または2番目のJVMの管理者が明示的リフレッシュを行なってキャッシュを再構築した場合は例外です。
ドキュメント・サービス
Oracle WebCenter Spacesアプリケーションの構成と同様、ドキュメント・サービスは、Javaオブジェクト・キャッシュを使用してドキュメント・サービスのプロビジョニングと構成のチェックをキャッシュします。プロビジョニングの場合、キャッシュされたオブジェクトには分散済のフラグが付けられます。これらのオブジェクトは、正しく構成されたJavaオブジェクト・キャッシュによって高可用性環境内でレプリケートされ、構成のキャッシュ済状態はローカルで保持されます。キャッシュされたオブジェクトはすべて、1分後に期限切れとなるようにフラグが付けられます。キャッシュすることによって、UCMサーバーの状態をチェックするためにUCMコールが行われる回数が減ります。これは、Oracle WebCenter Spacesがプロビジョニングと構成を繰り返しチェックして、UIにおけるサービスのレンダリングを制御するためです。
ポートレット・コンシューマ
ポートレット・コンシューマでは、ポートレット・レスポンスのキャッシュ・ヘッダーに応じて、ポートレット・マークアップがJavaオブジェクト・キャッシュに格納されます。このキャッシュは、期限切れベースまたは検証ベースになります。
プロファイルの管理では、軽量のユーザー・プロファイル・オブジェクトがJavaオブジェクト・キャッシュに格納されます。特定のプロファイル・データが見つからない場合、バックエンドから問合せが行われ、キャッシュに格納されます。格納されるオブジェクトの数の上限は1000であり、Javaオブジェクト・キャッシュに1時間保持されます。
ナビゲーションでは、ユーザー・セッションごとにナビゲーション・モデル・オブジェクトがJavaオブジェクト・キャッシュに格納されます。HTTPセッションが破棄されると、これらのキャッシュされたオブジェクトも破棄されます。
最近のアクティビティ
最近のアクティビティのタスク・フローまたはRSSフィードが表示されるたびに結果の再問合せが行われないようにするため、最近のアクティビティ結果のリストは、ユーザーごとにキャッシュされます。キャッシュは15分ごとに自動的にリフレッシュされるか、または最近のアクティビティのタスク・フローにあるリフレッシュ・アイコンを使用して手動でリフレッシュできます。
Javaオブジェクト・キャッシュの構成手順については、第6.4.13項「Javaオブジェクト・キャッシュの構成」を参照してください。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内で他に利用可能なメンバーがリクエストを処理できます。
Oracle WebCenterアプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。
アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できます。
ステートフル・アプリケーションに対し、第6.4.15項「Oracle ADFのレプリケーションの構成」の説明に従って、状態のレプリケーションが正しく構成されています。
Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されています。
ハードウェア・ロード・バランサを使用する場合は、ロード・バランサが:
利用可能なインスタンスすべてに対してトラフィックをルーティングしています
利用できないインスタンスをマークするように、状態モニターで正しく構成されています
セッションの状態の永続性をサポートするように構成されています
環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気がつきません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。
ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。
ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。
ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。
ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。
インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。
インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。
予想される動作に対する例外
Oracle WebCenterでは、これらの予想される動作に対する既知の例外は次のとおりです。
Oracle ADFのポップアップ: 開いているポップアップがフェイルオーバー時に閉じます。これは、通常は例外のない多くのコンポーネントに影響を及ぼします。影響を受けるコンポーネントは次のとおりです。
Oracle Composer(プロパティ・インスペクタのポップアップ)
リスト
リンク(リンク削除のポップアップ)
フェイルオーバーが発生した場合、ポップアップを再表示するには、そのポップアップを表示する原因となったアクションを繰り返す必要があります。これがWebCenter Spacesに表示される具体的な方法および推奨される処置は、表6-7に一覧表示されています。
表6-7 Oracle WebCenterのトラブルシューティングのシナリオ
| フェイルオーバー前のアクション | フェイルオーバー後 | 推奨される処置 |
|---|---|---|
|
任意のページにアクセスして「ページの作成」をクリックします。 |
名前を入力し、テーマを選択して「OK」をクリックします。テーマを選択すると、ページ作成ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「ページの管理」を起動します。 |
ポップアップ内で、ポップアップを閉じること以外の操作を実行します。たとえば、「ページ・アクション」をクリックします。任意の操作を実行すると、「ページの管理」ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「ページの管理」を起動し、ページに対して「ページ・アクション」をクリックしてから、メニュー内の「削除」オプションをクリックします。 |
確認ポップアップで「OK」をクリックします。「OK」をクリックすると、確認ポップアップが閉じるだけでなく、「ページの管理」ポップアップもリクエストの一部として閉じ、(行われた可能性のある)削除の効果はタブには表示されません。 |
「ページの管理」ポップアップを再起動し、ページが削除されているかどうかを確認します。削除されていない場合は、もう一度削除してみます。 |
|
「アプリケーションのパーソナライズ」ポップアップを起動します。「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。 |
「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。リクエストをサーバーに送信する任意の操作を実行すると、「アプリケーションのパーソナライズ」ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「プリファレンス」を起動します。 |
「プリファレンス」のタブ(「一般」、アカウント、「メッセージング」、「検索」)間の切替えを行います。「プリファレンス」のタブ間で切替えを行うと、「プリファレンス」ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「お気に入りの管理」を起動します。サーバーを停止し、ポップアップを閉じること以外の操作を実行します。たとえば、フォルダを開いてお気に入り情報の編集をクリックします。 |
ポップアップを閉じること以外の操作を実行します。たとえば、フォルダを開いてお気に入り情報の編集をクリックします。任意の操作を実行すると、「お気に入りの管理」ポップアップが閉じます。 |
「お気に入りの管理」ポップアップを再起動し、操作が正常に実行されたかどうかを確認します。正常に実行されなかった場合は、この操作を再試行します。 |
|
アプリケーションの編集と新しいフォルダの作成を選択します。 |
MDS例外が表示されます。 |
この操作を再試行します。 |
コンポーネント固有の問題: Oracle WebCenterの各コンポーネントに固有の他の問題は、表6-8に一覧表示されています。
表6-8 Oracle WebCenterでの予想される動作に対する例外
| Oracle WebCenterコンポーネント | 予想される動作に対する例外 |
|---|---|
|
グループ・スペース・イベント |
特定のフィールド(開始または終了の日/時/分)を変更すると、フェイルオーバーの発生時にイベント・フォームが閉じます。 |
|
ポートレット |
障害は完全に透過的です。 |
|
リスト |
障害は完全に透過的です。 |
|
リンク |
障害は完全に透過的です。 |
|
検索 |
長時間実行される問合せの最中。戻される結果は保証されません(ここでは書込み操作は存在しないことに注意)。ユーザーは問合せを再発行できます。 |
|
タグ付け |
障害は完全に透過的です。 |
|
最近のアクティビティ |
ツリー・ノードのオープン/クローズ状態はレプリケートされません。フェイルオーバー後、結果のツリーによってノードがすべて閉じます。ノードは開きなおす必要があります。 |
|
ワークリスト |
障害は完全に透過的です。 |
|
ドキュメント・マネージャ |
ユーザーがドキュメントをアップロードしたときに、同じ名前のドキュメントがすでに存在している場合は、「新規バージョンの確認」画面が表示されます。その画面の表示中、ファイルは一時的なローカルの場所に格納されます。そのときにフェイルオーバーが発生すると、アップロードしたファイルは失われ、ユーザーはアップロード・プロセスを再実行する必要があります。 |
Oracle WebLogic Server管理コンソールを使用して、アプリケーション・デプロイメントのステータスを確認します。また、Oracle WebCenterプロセスの開始、停止および監視には、Oracle WebLogic ServerインフラストラクチャとEnterprise Manager Fusion Middleware Controlも使用できます。
Oracle WebCenter Spacesとポートレット・プロデューサの場合、すべての構成データはMDSリポジトリおよびポートレット・プロデューサに格納されます。アプリケーションの起動時には、追加のクラスタ・デプロイメントによって、最新の構成が自動的に読み取られます。
Oracleディスカッション・サーバーの場合、構成情報は既存のクラスタ・サーバーから移動する必要があります。これは、Oracle WebLogic Serverのpack/unpackユーティリティによって自動的に行われます。これがお薦めする手順です。
図6-5は、1つのWebLogic Serverドメイン内の2つのOracle WebLogic Serverで、2ノードのOracle WebCenterクラスタが稼働している状況を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。メタデータとスキーマの格納にはOracle RACデータベースが使用されます。管理サーバーにはVIPが使用されます(手動フェイルオーバー用)。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
|
注意: コマンド例はすべて、Kシェルまたはbashシェルに対するものです。Cシェルの例は提供されていません。 |
次の各項では、Oracle WebCenterの高可用性構成を設定する前に必要となる手順について説明します。
プラットフォーム固有のコマンドの詳細は、Oracle Fusion Middleware Oracle WebCenterインストレーション・ガイドを参照してください。
Oracle WebCenterでは、サポートされているデータベースおよびスキーマが存在している必要があります。
データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
データベースのバージョンを調べるには、次の問合せを実行します。
SQL>select version from sys.product_component_version where product like 'Oracle%';
次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。
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は、専用のMiddlewareホームにインストールします。
最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。
最新バージョンの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 Oracle WebCenter管理者ガイドを参照してください。
次のリストは、この項で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware(FMW)が常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle WebCenter がインストールされている場所を指します。
ORACLE_COMMON_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリ・ファイルおよびライブラリ・ファイルが含まれているOracleホームを指します。
DOMAIN_HOME: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。
このディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。
ORACLE_BASE:
/u01/app/oracle
MW HOME(アプリケーション層):
ORACLE_BASE/product/fmw
WL_HOME:
MW_HOME/wlserver_10.3
ORACLE_HOME:
MW_HOME/WC1
ORACLE_COMMON_HOME:
MW_HOME/oracle_common
Oracle Fusion Middleware WebCenterのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとWebCenterスキーマをReal Application Clusterデータベースにインストールします。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。
最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。
最新バージョンの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インストレーションの概念およびリポジトリ作成ユーティリティ・ユーザーズ・ガイドを参照してください。
WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。
サーバーが次の要件を満たしていることを確認します。
システム、パッチ、カーネルおよびその他の要件が、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』に指定されている要件を満たしている必要があります。
この例ではポート7777を使用します。ポート7777を選択する場合には、ノード上のいずれのサービスでもこのポートが使用されていないことを確認します。このことを確認するには、次のコマンドを実行します。
UNIX:
netstat -an | grep LISTEN | grep ":7777"
Windows:
netstat -an | findstr "LISTEN" | 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 Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。
アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。
UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。
Oracle WebLogic Serverインストーラを起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、MW_HOMEと入力します。
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「JDKの選択」画面で、「Oracle JRockit 1.6.0_14 SDK」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
WL_HOME
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「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の場所を、MW_HOME/jrockit_160_14_R27.6.4-18のように入力します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
「MiddleWareホーム」には、MW_HOMEと入力します。
「Oracleホーム・ディレクトリ」には、たとえばwcのように、使用するディレクトリを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール 完了」画面で「終了」をクリックします。
|
注意: 第6.4.5項「WebLogic Server WebCenterのドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareの最新のパッチ・セットなどの既知のパッチをMiddlewareホームに適用して、Oracle Fusion Middlewareを最新バージョンにしておいてください。最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。 |
管理サーバーの仮想IPの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のアクティブ/パッシブ・トポロジ」を参照してください。
MiddlewareホームのWebCenterディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracle WebCenterコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースでは、すべてのインスタンスを実行することをお薦めします。
次のコマンドを使用して、ORACLE_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。
APPHOST1> ./config.sh
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。
Webcenter Spacesを選択すると、WSMポリシー・マネージャとOracle JRFが自動的に選択されます。
Oracle WebCenter Spaces - 11.1.1.0
Oracleポートレット・プロデューサ - 11.1.1.0
Oracle WebCenterディスカッション・サーバー - 11.1.1.0
Oracle WebCenterアクティビティ・グラフ・エンジン - 11.1.1.0
Oracle WebCenterパーソナライズ - 11.1.1.0
Oracle WebCenter Analyticsコレクタ - 11.1.1.0
Oracle WebCenterページレット・プロデューサ - 11.1.1.0
Oracle JRF - 11.1.1.0
「次へ」をクリックします。
「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択
JDKの選択: 「Oracle JRockit 1.6.0_14 SDK」を選択
「次へ」をクリックします。
「JDBCデータ・ソースの構成」画面で、「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。
リポジトリ作成ユーティリティによって、必要なスキーマがOracleデータベースに作成されます。これらのスキーマにはカスタム接頭辞を指定します。表6-10は、データ・ソース、使用するスキーマ、およびスキーマが割り当てられている管理対象サーバーを一覧表示しています。
画面に次のデータ・ソースが表示されていることを確認します。
次のパネルですべてのデータ・ソースをRACマルチ・データ・ソース・スキーマとして構成します。を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、「追加」ボタンをクリックして、両方のOracle RACノードの「ホスト名」、「インスタンス名」および「リスニング・ポート」を追加します。
1つのスキーマを選択したまま残し、他のスキーマの選択は解除します。
「ドライバ」ドロップダウン・リストで、RACサービス・インスタンス接続用Oracleのドライバ(Thin)を選択します。
「サービス名」を入力します。
Oracle WebCenterスキーマのPrefix_Usernameを入力します。
スキーマの「パスワード」を入力します。
「追加」をクリックして、最初のOracle RACインスタンスの詳細を入力します。
一度に1つのデータ・ソースを選択し、適切な詳細を追加することで、各マルチ・データ・ソース・スキーマを更新します。
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常だったことを確認します。正常でない接続があった場合には、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続が正常になったら「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: 第6.4.4項で使用したVIPアドレスを入力します。
リスニング・ポート: 7001
SSLリスニング・ポート: N/A
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。
表6-11 管理対象サーバーの構成
| 名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
|
WC_Portlet |
APPHOST1のホスト名 |
8889 |
n/a |
選択を解除 |
|
WC_Portlet2 |
APPHOST2のホスト名 |
8889 |
n/a |
選択を解除 |
|
WC_Spaces1 |
APPHOST1のホスト名 |
8888 |
n/a |
選択を解除 |
|
WC_Spaces2 |
APPHOST2のホスト名 |
8888 |
n/a |
選択を解除 |
|
WC_Collaboration1 |
APPHOST1のホスト名 |
8890 |
n/a |
選択を解除 |
|
WC_Collaboration2 |
APPHOST2のホスト名 |
8890 |
n/a |
選択を解除 |
|
WC_Utilities1 |
APPHOST1のホスト名 |
8891 |
n/a |
選択を解除 |
|
WC_Utilities2 |
APPHOST2のホスト名 |
8891 |
n/a |
選択を解除 |
「次へ」をクリックします。
「クラスタの構成」画面で、次のクラスタを追加します。
Portlet_Cluster
名前: Portlet_Cluster
クラスタ・メッセージング・モード: unicast
クラスタ・アドレス有効化: 空白のまま
Spaces_Cluster
名前: Spaces_Cluster
クラスタ・メッセージング・モード: unicast
|
注意: デフォルトでは、各Oracle WebCenterクラスタはユニキャストとして構成されます。Oracle WebCenterクラスタをマルチキャスト用に構成するには、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』を参照してください。 |
クラスタ・アドレス有効化: 空白のまま
Collaboration_Cluster
名前: Collaboration_Cluster
クラスタ・メッセージング・モード: unicast
クラスタ・アドレス有効化: 空白のまま
Utilities_Cluster
名前: Utilities_Cluster
クラスタ・メッセージング・モード: unicast
クラスタ・アドレス有効化: 空白のまま
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、クラスタに次のサーバーを割り当てます。
Spaces_Cluster
WC_Spaces1
WC_Spaces2
Portlet_Cluster
WC_Portlet1
WC_Portlet2
Collaboration_Cluster
WC_Collaboration1
WC_Collaboration2
Utilities_Cluster
WC_Utilities1
WC_Utilities2
「次へ」をクリックします。
「マシンの構成」画面で、次の操作を行います。
デフォルトとして表示される「LocalMachine」を削除します。
「UNIXマシン」タブをクリックし、次のマシンを追加します。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。
APPHOST1: WC_Spaces1、WC_Portlet1、WC_Collaboration1、WC_Utilities1
APPHOST2: WC_Spaces2、WC_Portlet2、WC_Collaboration2、WC_Utilities2
「次へ」をクリックします。
「構成のサマリ」画面で「作成」をクリックします。
ドメインの作成中画面で「完了」をクリックします。
この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーおよび管理対象サーバーに対してboot.propertiesファイルを作成します。
管理サーバーに対しては、次の手順を実行します。
次のディレクトリを作成します。
APPHOST1> mkdir -p MW_HOME/user_projects/domains/wcdomain/servers/AdminServer/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。
username=adminuser password=password
|
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
WC_Spaces1管理対象サーバーに対して、次の手順を実行します。
次のディレクトリを作成します。
APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/servers/WC_Spaces1 APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/servers/WC_Spaces1/security
テキスト・エディタを使用して、前の手順で作成したセキュリティ・ディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。
username=adminuser password=password
APPHOST1上のWC_Portlet1およびWC_Collaboration1管理対象サーバーに対してステップ2および3を繰り返します。
|
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
この項では、APPHOST1でシステムを起動する手順について説明します。
APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。
APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/bin
APPHOST1> ./startWebLogic.sh
管理サーバーが適切に構成されていることを確認する手順は次のとおりです。
ブラウザでhttp://VIP1:7001/consoleにアクセスします。
管理者としてログインします。
すべての管理対象サーバー(WC_Spaces1、WC_Spaces2など)が表示されていることを確認します。
すべてのクラスタが表示されていることを確認します。
Enterprise Manager(http://VIP1:7001/em)にアクセスできることを確認します。
この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。
ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。
ホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「サーバー」→「管理サーバー」を選択します。
「SSL」→「詳細」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
プロンプトが表示されたら、変更内容を保存してアクティブ化します。
「ホスト名の検証」を「なし」に設定します。
「WC_Spaces1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
すべての管理対象サーバーに対してステップ6と7を繰り返します。
管理サーバーとすべての管理対象サーバーを再起動します。
APPHOST1でノード・マネージャを起動するには、次の手順を実行します。
ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。
APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./setNMProps.sh
|
注意: クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。 |
ノード・マネージャを起動します。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
APPHOST2に対し、WebLogic ServerとOracle WebCenterのインストール手順を繰り返します。第6.4.3.1項「Oracle WebLogic Serverのインストール」の手順から始めてください。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。
次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST2に伝播します。
次のpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cd WL_HOME/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:WL_HOME/common/bin
unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。
APPHOST2> cd WL_HOME/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:8888
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>
<Location /rest>
WebLogicCluster apphost1.com:8888,apphost2.com:8888
SetHandler weblogic-handler
</Location>
<Location /wcsdocs>
WebLogicCluster apphost1.com:8888,apphost2.com:8888
SetHandler weblogic-handler
</Location>
# Pagelet Producer
<Location /pageletadmin>
WebLogicCluster apphost1.com:8889,apphost2.com:8889
SetHandler weblogic-handler
</Location>
# Activity Graph
# The WebLogicHost below should be set to the Host on which ActivityGraph is running
<Location /activitygraph-engines>
WebLogicCluster apphost1.com:8891
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
<Location /owc_discussions>
WebLogicCluster apphost1.com:8890,apphost2.com:8890
SetHandler weblogic-handler
</Location>
#AdminServer and EM
<Location /console>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
</Location>
<Location /consolehelp>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
</Location>
<Location /em>
SetHandler weblogic-handler
WebLogicHost VIP1
WeblogicPort 7001
</Location>
WEBHOST1上のOracle HTTP Serverを再起動します。
WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1
WebCenter Suiteには、/をWebコンテキスト・ルートとして使用する次の2つのアプリケーションが含まれています。
Sharepointルート(WC_Spaces上にデプロイされる)
ページレット・プロデューサ・ルート(WC_Portlet上にデプロイされる)
仮想ホストを使用しないSharepointルートおよびページレット・プロデューサ・ルート・アプリケーションをOracle HTTP Server(OHS)を使用してルーティングするには、次のエントリを追加します。
<Location />
SetHandler weblogic-handler
WebLogicHost webcenter.example.com
WebLogicPort 8889
</Location>
このエントリによって、明示的に定義されていないすべてのコンテキスト・ルートが捕捉されます。また、Sharepointおよびページレット・プロデューサには/マッピングを必要としますが、これは1つのOHSでは実行できません。そのため、仮想ホスト構成が必要となります。仮想ホスト構成は、www.company1.comおよびwww.company2.comなどの複数のWebサイトを実行する単一システムです。仮想ホストは、IPベース(Webサイトごとに一意のIPアドレス)または名前ベース(各IPアドレス上で実行される複数の名前)です。それらが同じ物理サーバー上で実行されていることはエンド・ユーザーにはわかりません。仮想ホストの詳細は、Apache HTTPサーバーのドキュメントを参照してください。
Oracle HTTP Serverの構成
次のエントリは、Sharepointルート用とページレット・プロデューサ・ルート用の2つの名前ベースのホストを追加します。
$WEBTIER_INSTANCE_HOME/config/OHS/<ohs>でOHS httpd.confをみつけます。
サンプルVirtualHost構成をみつけ、次のエントリを追加します。
NameVirtualHost *:7777
<VirtualHost *:7777>
ServerName webhost.example.com
</VirtualHost>
<VirtualHost *:7777>
ServerName webtier-pageletproducer.example.com
<Location />
SetHandler weblogic-handler
WebLogicCluster apphost1:8889,apphost2:8889
</Location>
</VirtualHost>
<VirtualHost *:7777>
ServerName webtier-spaces.example.com
<Location />
SetHandler weblogic-handler
WebLogicCluster apphost1:8888,apphost2:8888
</Location>
<Location /webcenter>
Deny from all
</Location>
<Location /webcenterhelp>
Deny from all
</Location>
<Location /rest>
Deny from all
</Location>
</VirtualHost>
新しい仮想ホストwebtier-pageletproducerおよびwebtier-spacesがDNSに追加されたことを確認します。
仮想ホスト・セットアップの場合は、仮想ホスト経由でルーティングされたアプリケーションを使用するための追加のプロパティを構成する必要があります。
Sharepoint
Oracle Access Manager 10gまたはOracle Access Manager 11gとの統合を含むシングル・サインオン・セットアップは、Oracle® Fusion Middleware Oracle WebCenter管理者ガイドを参照してください。
Oracleページレット・プロデューサ
Oracleページレット・プロデューサにアクセスするには、webtier-pageletproducer.example.comを使用します。たとえば、WebCenter Spacesまたはカスタム・アプリケーションでOracleページレット・プロデューサを登録する場合は、Oracleページレット・プロデューサに対して仮想ホストを使用する必要があります。
同様に、Oracleページレット・プロデューサおよびページレット・プロデューサ・リソースへのアクセスは、仮想ホストを使用する必要があります。詳細は、Oracleページレット・プロデューサのドキュメントを参照してください。
URLを検証し、HTTP ServerからOracle WebCenterクラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。
WebLogic Server管理コンソールから、WC_Spaces1、WC_Spaces2、WC_Portlet1およびWC_Portlet2を次のように起動します。
次のURLの管理コンソールにアクセスします。
http://APHHOST1/console
「サーバー」をクリックします。
「制御」タブを開きます。
WC_Spaces1、WC_Spaces2、WC_Portlet1およびWC_Portlet2を選択します。
「起動」をクリックします。
次のURLを使用して、管理対象サーバーへの直接アクセスを検証します。
apphost1:8888/webcenter
apphost2:8888/webcenter
apphost1:8889/portalTools
apphost2:8889/portalTools
WC_Spaces2とWC_Portlet2の稼働中に、Oracle WebLogic Server管理コンソールからWC_Spaces1とWC_Portlet1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/webcenter
WebHost1:7777/portalTools
WebLogic Server管理コンソールからWC_Spaces1とWC_Portlet1を起動します。
WC_Spaces2とWC_Portlet2を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/webcenter
WebHost1:7777/portalTools
高可用性のための管理サーバーの構成の詳細は、第12.4項「コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換」を参照してください。
Javaオブジェクト・キャッシュ(JOC)は、WebCenter Spacesを実行しているすべてのサーバー間で構成する必要があります。このローカル・キャッシュは、Oracle WebCenter Spacesのパフォーマンスを向上させるために用意されています。
Oracle WebCenter Spacesを実行するすべてのサーバー間でのJavaオブジェクト・キャッシュの構成の説明は、第F.1項「Javaオブジェクト・キャッシュの構成」を参照してください。
高可用性環境では、MDSリポジトリに対して分散通知を構成することをお薦めします。
MDSリポジトリに対する分散通知の構成の詳細は、付録G「MDSに対する分散通知の構成」を参照してください。
この項の手順を使用して、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>
WebCenterアプリケーションでは、これはデフォルトですでに有効になっています。
アプリケーションのレプリケーション
アプリケーションでレプリケーションが有効化されていることも必要です。Oracle WebLogic Serverでは、レプリケーションのために数種類の永続ストアを使用できます。永続ストアの詳細は、『Oracle Fusion Middleware 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ポータル・アプリケーションがメモリー内レプリケーション用に構成されていることを確認します。
Analyticsコレクタを、WebCenter Spacesと通信するように構成する必要があります。各コレクタは、ローカルのWebCenter Spacesと1対1の関係でのみ通信するように構成します。コレクタはデフォルトで構成されているため、必要な操作はWebCenter Spacesを構成することのみです。
次のように、WLSTシェルを開きます。
ORACLE_HOME/common/bin/wlst.sh
次のように、WLSサーバーに接続します。
connect('weblogic_admin_username', 'weblogic_admin_pwd', 'APPHOST1:8888')
ホストに接続し、Spaces Serverのポートに接続していることに注意してください。
次のように、Analyticsコレクタ接続を作成し、それをデフォルトの接続にします。
createAnalyticsCollectorConnection('webcenter','HAConn1',isUnicast=1,
collectorHost='localhost',collectorPort=31314,isEnabled=1,timeout=30,default=1)
次のように、行った変更をリストします。
listDefaultAnalyticsCollectorConnection('webcenter')
アクティビティ・グラフ・エンジン・アプリケーションは、シングルトンとして実行する必要があります。クラスタ環境では、アクティビティ・グラフ・エンジン・アプリケーションのインスタンスは1つを除いてすべて無効化する必要があります。
アクティビティ・グラフ・エンジン・アプリケーションを無効化する手順は次のとおりです。
Oracle WebLogic管理コンソールにログインします。
「デプロイメント」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
activitygraph-engines(11.1.1.4.0)デプロイメントのターゲットを次のように変更します。
デプロイメントを選択します。
「 ターゲット 」タブを選択します。
「ターゲットの変更」をクリックします。
デプロイメントのターゲットが、クラスタの一部/管理対象サーバーの1つのみになっていることを確認します。
「OK」をクリックして変更を保存します。
すべての変更をアクティブ化をクリックします。
アクティビティ・グラフは1つのノード上でのみ実行されているため、このノードが失われるかその管理対象サーバーが使用不可になった場合、アクティビティ・グラフは使用できなくなります。
この場合、アクティビティ・グラフは、アクティブな管理対象サーバー上にデプロイする必要があります。このプロセスは、サービス移行を構成することによって自動化することもできます。SOA管理対象サーバーのサーバー移行の構成例は、第5.13.21項「WLS_SOAサーバーのサーバー移行の構成」を参照してください。
ユニキャスト・クラスタの場合は、まず、第6.4.21項「マルチキャストからユニキャストへのディスカッションの変換」の手順が実行されていることを確認します。
ディスカッション・サーバーのクラスタのすべてのメンバーが、ディスカッション・サーバー管理コンソールを使用して互いに通信できることを確認します。
次の場所にあるクラスタの各メンバーにログインします。
http://<host>:<port>/owc_discussions/admin
「キャッシュ設定」を開きます。
ページの下部にあるキャッシュ機能セクションで、「クラスタリング」が「有効」に設定されていることを確認します。
ページの上部に、クラスタのすべてのメンバーが一覧表示されます。
再度ページの下部に移動し、キャッシュ・ツールセクションで、クラスタワイドでのキャッシュのリセットおよびキャッシュのウォームアップ・タスクを実行します。クラスタのすべてのメンバーで、キャッシュのウォームアップ・タスクを繰り返します。
Oracle WebCenterトポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。
この場合は、WebCenterコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードの共有記憶域には、MiddlewareホームとWebCenterディレクトリが格納されています。
新しいOracle WebCenter管理対象サーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。WebCenterのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。1つのノード上における複数の管理対象サーバーの実行は、WC_SpacesサーバーおよびWC_Portletサーバーに対してのみサポートされています。
トポロジをスケール・アップするには、次の手順を実行します。
管理コンソールを使用して、WC_Spaces1またはWC_Portlet1のクローンを作成し、新しい管理対象サーバーにします。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。
管理コンソールから「環境」→「サーバー」を選択します。
クローンを作成する管理対象サーバー(WC_Spaces1またはWC_Portlet1など)を選択します。
「クローンの作成」を選択します。
新しい管理対象サーバーにSERVER_NAMEnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。
この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。
この新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します(第6.4.13項「Javaオブジェクト・キャッシュの構成」を参照)。
Oracle HTTP Serverモジュールをクラスタの新しいメンバーで再構成します。第6.4.11項「Oracle HTTP Serverの管理サーバーおよびOracle WebCenter管理対象サーバーの構成」を参照してください。
トポロジのスケール・アウトでは、Oracle WebCenterアプリケーションを使用して構成されている新しい管理対象サーバーを新しいノードに追加します。
この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。
トポロジ内には、WebCenterアプリケーションを使用して構成されている管理対象サーバーを実行しているノードがすでに存在しています。
新しいノードは、WebLogic ServerおよびOracle WebCenter用の既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。packとunpackを実行して管理対象サーバー・ドメインを作成する必要がありますが、WebLogic ServerやWebCenterバイナリを新しい場所にインストールする必要はありません。
トポロジをスケール・アウトするには、次の手順を実行します。
新しいノードで、WebCenterのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
共有記憶域内のORACLE_HOMEをローカルのOracleインベントリに追加するには、次のコマンドを実行します。
WCHOSTn> cd ORACLE_BASE/product/fmw/wc/ WCHOSTn> ./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_20_D1.0.1-2124
Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
Oracle WebLogic Server管理コンソールを使用し、WC_Spaces1、WC_Portlet1、WC_Collaboration1またはWC_Utilities1のクローンを作成して新しい管理対象サーバーにします。それにWLS_XXXnという名前を付けます。nはその新しいマシンに割り当てる番号です。
リスニング・アドレスについては、新しい管理対象サーバーに使用するホスト名またはIPを割り当てます。管理対象サーバー・リスニング・アドレスを設定する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウで、「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、リスニング・アドレスを更新する管理対象サーバーを選択します。その管理対象サーバーの「設定｣ページが表示されます。
リスニング・アドレスをWCHOSTnに設定します。WCHOSTnは、新しいマシンのDNS名です。
「保存」をクリックします。
変更を保存およびアクティブ化します。
変更内容は、管理対象サーバーが再起動されるまでは有効になりません。
次のようにpackコマンドをWCHOST1で実行し、テンプレート・パックを作成します。
WCHOST1> cd ORACLE_COMMON_HOME/common/bin WCHOST1> ./pack.sh -managed=true -domain=MW_HOME/user_projects/ domains/wcdomain/ -template=webcenterdomaintemplateScale.jar -template_name=webcenter_domain_templateScale
次のコマンドをWCHOST1で実行し、作成したテンプレート・ファイルをWCHOSTnにコピーします。
WCHOST1> scp wcdomaintemplateScale.jar oracle@WCHOSTn:/ ORACLE_BASE/product/
fmw/wc/common/bin
次のようにWCHOSTnでunpackコマンドを実行して、管理対象サーバー・ドメイン・ディレクトリ内のテンプレートを解凍します。
WCHOSTn> cd ORACLE_BASE/product/fmw/wc/common/bin WCHOSTn> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/ wcdomain/ -template=wcdomaintemplateScale.jar
新しいノードでノード・マネージャを起動します。ノード・マネージャを起動するには、すでに存在しているノードの共有記憶域にあるインストールを使用し、次のように新しいノードのホスト名をパラメータとして渡します。
WCHOSTn> WL_HOME/server/bin/startNodeManager <new_node_ip>
これが新しいコラボレーション管理対象サーバーである場合は、第6.4.18項「ディスカッション・サーバーのクラスタリングの構成」の手順に従って新しいディスカッション・サーバーに対してクラスタ化が構成済であることを確認します。また、第6.4.21項「マルチキャストからユニキャストへのディスカッションの変換」の手順を、coherence.localhostパラメータに新しいホストのホスト名を使用して実行済であることも確認します。
これが新しいユーティリティ管理対象サーバーである場合は、第6.4.17項「アクティビティ・グラフの構成」の手順に従ってアクティビティ・グラフを無効化済であることを確認します。第6.4.16項「Analyticsコレクタの構成」の新しいAnalyticsコレクタの構成手順に従っていることも確認します。
Oracle WebLogic Server管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーをすべて停止します。
新たに作成した管理対象サーバーが実行されていることを確認します。
新たに作成した管理対象サーバー上のアプリケーションにアクセスします。アプリケーションが機能している必要があります。
この項では、Oracle WebCenterで発生する可能性のある問題のトラブルシューティング手順について説明します。
WebCenterアプリケーションは、管理対象サーバーが最初に起動したときにデプロイされます。最初にOracle WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメントがすべて成功したことを確認します。
左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。
アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME/servers/SERVER_NAME/logsディレクトリに格納されています。一般的な問題には、次のようなものがあります。
データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。
適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。
フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります。
ウィンドウが閉じたか、または状態がリセットされた可能性がある。
画面のリセットが必要になった可能性がある。
アプリケーションがログオン画面にリダイレクトしている可能性がある。
次の手順は、状態のレプリケーションに関する問題のトラブルシューティングおよび診断を行う際のガイダンスです。
これがレプリケーションに関する既知の問題でないことを確認します。
予想される動作については、第6.3.2.8項「アプリケーションのフェイルオーバーで予想される動作」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。
ロード・バランサの設定を確認します。
レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverのハードウェア・ロード・バランサの構成の詳細は、『Oracle Fusion Middleware 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: WC_Spaces---RUNNING WC_Spaces2---RUNNING
クラスタ通信を確認します。
クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。
ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。
個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。
マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTestを実行して、マルチキャストが正しく構成されていることを確認します。例:
$ java utils.MulticastTest -H
アプリケーションの構成を確認します。
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分です。サーバーが失われた場合、リクエストは、元のポリシーがキャッシュされている、クラスタ内の別のサーバーにルーティングされます。前回のリフレッシュ以後に発生した最近のポリシーの変更が失われたように見えることがあります。たとえば、フェイルオーバーの直前に作成されたロールは、使用不可と表示される場合があります。
このような状況でも、ポリシーは、バックエンド・ポリシー・ストアにあります。キャッシュをリフレッシュして、ポリシー情報をリストアします。数分後に再試行するか、またはアプリケーションにログインしてからログアウトして、ポリシー・キャッシュのリフレッシュを強制実行します。
OWSMやWebCenter Spaces管理対象サーバーなど、Javaオブジェクト・キャッシュを使用する管理対象サーバーを起動しようとした場合、起動に失敗し、ログに次のエラーが記録されます。
J2EE JOC-058 distributed cache initialization failure J2EE JOC-043 base exception: J2EE JOC-803 unexpected EOF during read.
別のプロセスが、JOCが取得を試みている同じポートを使用しています。この問題を解決するには、そのプロセスを停止するか、推奨ポート範囲内の別のポートを使用するように、このクラスタのJOCを再構成します。
ディスカッションをマルチキャストからユニキャストに変換する手順は次のとおりです。
ステップ1: 起動パラメータの追加
関連する起動パラメータの追加手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「サーバー」→「WC_Collaboration1」→「構成」→「サーバーの起動」を選択します。
「引数」ボックスで、次の行を追加します。
-Dtangosol.coherence.wka1=Host1 -Dtangosol.coherence.wka2=Host2 -Dtangosol.coherence.localhost=Host1 -Dtangosol.coherence.wka1.port=8088 -Dtangosol.coherence.wka2.port=8088
Host1は、WC_Collaboration1が実行されている場所です。
WebCenter Coherenceの通信に8088以外のポートを使用するには、前述の例の引数-Dtangosol.coherence.wka1.portおよび-Dtangosol.coherence.wka2.portを使用して、別のポート番号を指定します。
WC_Collaboration2に対してステップ1と2を繰り返します。ただし、ローカルホスト・パラメータにはHost2に設定します。
WC_Collaboration1サーバーを再起動します。
ステップ2: 変更の検証
変更を検証する手順は次のとおりです。
ディスカッション・フォーラムの管理パネルにログオンします。
左ペインで「キャッシュ設定」を選択します。
画面の下部で、「クラスタリング」が「有効」に設定されていることを確認します。
クラスタのすべてのメンバーに対して、ステップ1から3を繰り返します。
サーバーがクラスタに参加すると、それらのサーバーが画面の上部に表示されます。
Oracle WebCenterポータル・アプリケーションは、必須ライブラリをプロビジョニング済のサーバーおよびクラスタにデプロイされます。このプロビジョニングは、既存のWebCenterドメインにドメイン・テンプレートを適用することによって行われます。
拡張は、ドメインごとに一度のみ実行できます。したがって、どのOracle WebCenterポータル・アプリケーション・サーバーも、一度に作成するか、既存のOracle WebCenterポータル・アプリケーション・サーバーのクローンとして作成する必要があります。
Oracle WebCenterポータル・アプリケーションをデプロイするためにクラスタを構成する際に必要となる手順は次のとおりです。
次のコマンドを使用して、ORACLE_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。
APPHOST1> ./config.sh
「ようこそ」画面で、「既存のWebLogicドメインの拡張」を選択し、「次へ」をクリックします。
次の画面で、Weblogicドメイン・ディレクトリを選択します。
次の画面で、「既存の拡張テンプレートを使用してドメインを拡張する」を選択します。
カスタム・アプリケーションを作成するのか、カスタム・プロデューサを作成するのかに応じて、次の2つのテンプレートのいずれかを選択します。
カスタム・アプリケーションの場合
$WC_ORACLE_HOME/common/templates/applications/oracle.wc_custom_portal_
template_11.1.1.jar
カスタム・プロデューサの場合
$WC_ORACLE_HOME/common/templates/applications/oracle.wc_custom_services_ producer_template_11.1.1.jar
すべてのデータ・ソースを選択し、RACデータソース」チェック・ボックスを選択することで、新しいデータ・ソース(カスタム・ポータル・アクティビティ、カスタム・ポータルWebcenter、カスタム・ポータルMDS)をOracle RACとして構成します。カスタムAppsは既存のスキーマを使用します。
データベース接続情報を入力し、続いて、データ・ソースのステータスをチェックします。
オプション構成画面で、「管理対象サーバー、クラスタ、およびマシン」を選択します。
「管理対象サーバー」画面で、次のように実行します。
WC_CustomPortalという名前の管理対象サーバーが表示されます。このサーバーの名前をWC_CustomPortal1に変更します。
「追加」をクリックして新しい管理対象サーバーを作成し、WC_CustomPortal2という名前を付けます。リスニング・ポートをWC_CustomPortal1と同一に設定します。
「クラスタの構成」画面で、WC_CustomPortalClusterという名前のクラスタを追加します。
「サーバーのクラスタへの割当」画面で、新しく作成した2つのサーバーをクラスタに追加します。
「サーバーのマシンへの割当」画面で、2つのサーバーをそれぞれ別のマシンに配置します。
「拡張」→「完了」をクリックし、ドメインを拡張します。
これらの手順を完了すると、Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを起動し、Oracle WebCenterポータル・アプリケーションをデプロイできるようになります。これらのOracle WebCenterポータル・アプリケーションは、管理対象サーバーのターゲットでなく、クラスタのターゲットにデプロイします。
新しいサーバーは、既存のサーバーのクローンを作成することによってすでに拡張されているドメインにのみ追加できます。
Oracle WebLogic Server管理コンソール(http://APPHOST1:7001/console)にアクセスし、ログインします。
「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択し、「サーバーのサマリー」ページに既存の管理対象サーバーをすべて表示します。
カスタム・アプリケーション・サーバーの1つを選択し、「クローンの作成」ボタンをクリックします。
新しいサーバーに名前(WC_CustomPortal3など)を付け、新しいサーバーを配置するリスニング・アドレスとポートを設定します。
サーバーが作成され、自動的にカスタム・ポータル・クラスタのメンバーになります。
高可用性Oracle WebCenterポータル・アプリケーションの場合は、MDSリポジトリに対して分散通知を構成することをお薦めします。
MDSリポジトリに対する分散通知の構成の詳細は、付録G「MDSに対する分散通知の構成」を参照してください。
