| Oracle® Fusion Middleware高可用性ガイド 11g リリース1 (11.1.1) B55898-08 |
|
 前 |
 次 |
この章では、Oracle Application Development Framework(Oracle ADF)とOracle WebCenterポータルの高可用性の概要と構成手順について説明します。
この章の項目は次のとおりです。
Oracle ADFは、Java Platform, Enterprise Edition(Java EE)の標準およびオープンソース・テクノロジに基づいて作成されたエンドツーエンド・アプリケーション・フレームワークで、サービス指向アプリケーションの実装を簡素化および迅速化します。Oracle ADFは、Web、無線、デスクトップ、またはWebサービスのインタフェースを使用してデータの検索、表示、作成、変更および検証を行うアプリケーションを作成するエンタープライズ開発者に適しています。Oracle JDeveloper 11gとOracle ADFを連携させると、ドラッグ・アンド・ドロップでのデータ・バインディング、視覚的なUI設計およびチーム開発の各機能を組み込んで、設計からデプロイまでの完全な開発ライフサイクルに対応する環境を作成できます。
コミュニティのベスト・プラクティスに従い、Fusion Webテクノロジ・スタックを使用して作成したアプリケーションでは、次のレイヤーによってサポートされているモデル・ビュー・コントローラ(MVC: Model-View-Controller)アーキテクチャに準拠することで、ビジネス・ロジック、ページ・ナビゲーションおよびユーザー・インタフェースが明確に分離されます。
図6-1に示すように、MVCアーキテクチャでは次のような構成になります。
モデル・レイヤーは、現行ページに関連するデータ値を表します。
ビュー・レイヤーには、その関連データの表示や変更に使用するUIページが保持されます。
コントローラ・レイヤーは、ユーザー入力を処理し、ページ・ナビゲーションを決定します。
ビジネス・サービス・レイヤーは、データ・アクセスを処理し、ビジネス・ロジックをカプセル化します。
フレームワークにおけるコア・モジュールは、Oracle ADFモデルです。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モデルによって、ビジネス・サービスの実装テクノロジを抽象化するデータ・コントロールが実装されます。標準のメタデータ・インタフェースにより、サービスの操作やデータ・コレクション、関連するプロパティ、メソッド、タイプに関する情報などが記述されます。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 Facesでは、動的チャート、グラフ、ゲージ、および基礎となるデータをリアルタイムで表示するその他のグラフィックをレンダリングできるFlashおよびSVG対応のコンポーネントである、ADFデータ視覚化のコンポーネントも提供します。各コンポーネントはカスタマイズやスキニングに加えて、国際化とアクセシビリティの機能もサポートしています。
これらのフロントエンド機能を実現するために、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アプリケーション)です。この項の項目は次のとおりです。
バインディング・コンテナやマネージド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ではこの変更を認識しないため、新しい値をクラスタ内でレプリケートする必要があることがわかりません。変更およびレプリケーションの必要性を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アプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、GridLinkデータ・ソースまたはマルチ・データ・ソースを使用する必要があります。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースまたはGridLinkデータ・ソースのネーミング規則は、非マルチ・データ・ソースまたはGridLinkデータ・ソースのネーミング規則と同じになります。このネーミング規則によって、正しいデータ・ソースが実行時に使用されるようになります。高可用性アプリケーションに対するGridLinkデータ・ソースの構成の詳細は、第4.1.4項「Oracle RACでのGridLinkデータ・ソースの構成」を参照してください。マルチ・データ・ソースの詳細は、第4.1.5項「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 WebLogic Server weblogic.xmlファイルのpersistent-store-type要素に値を割り当てる必要があります。replicated_if_clusteredの値により、有効な永続ストアのタイプがレプリケートされ、このサーバーの属するサーバーのクラスタに対して設定された値に従って、クラスタ環境のセッションが格納されるようになります。
|
注意: Oracle WebCenterポータルSuiteなどのOracle ADFアプリケーションは事前に構成されており、追加構成は不要です。 |
高可用性を実現するために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コンポーネントの実行時の動作を構成するためのセクションが含まれています。
|
注意: アプリケーションでMDSを使用しており、フェイルオーバーをサポートするOracle Databaseを使用する場合は、フェイルオーバー時におけるMDSの再試行を有効化しておくことをお薦めします。これを行うには、次の
<persistence-config>
<metadata-namespaces>...
<metadata-store-usages>...
<external-change-detection enabled="false" polling-interval-secs="30"/>
<read-only-mode enabled="true"/>
<retry-connection enabled="true"/>
</persistence-config>
|
高可用性を実現するために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 WebLogic Serverアプリケーションの構成を確認します。
Oracle WebLogic Serverは、デフォルトではフェイルオーバーするように構成されていません。メモリー内のレプリケーションは、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 WebLogic Serverの接続プール・パラメータを確認します。
weblogic-application.xmlデプロイメント・ディスクリプタの要素<connection-check-params> pool-paramsにあるパラメータinactive-connection-timeout-secondsに適切な値を設定します。
アプリケーション・モジュール状態の非アクティブ化を有効にしている場合は、接続を強制的にプールに復帰させるようにOracle WebLogic Serverを構成していると障害が発生することがあります。この障害によって、例外Connection has already been closedが生成されます。この例外は、サーバー・ログに保存されます。ユーザー・インタフェースには、この例外は表示されません。
inactive-connection-timeout-secondsは、数分に設定します。多くの場合は、この設定値によって、非アクティブ接続の強制的なタイムアウトと、非アクティブ化障害を回避できます。ご使用の環境に合せて、この設定値を調整してください。
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>
この設定は、JDeveloperのソース・エディタを使用して行います。第6.1.3.1項「アプリケーション・モジュールの構成」を参照してください。
デフォルトのログ出力メッセージを確認します。
デフォルトでは、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 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
Oracle Fusion Middleware 11gに必要なメタデータをインストールする手順は次のとおりです。
次のコマンドを使用してRCUを起動します。
RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
データベース・タイプ: Oracle Databaseを選択します。
ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合、ホスト名としてVIP名またはノード名の1つを指定します: 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_<バージョン> SDK」のみを選択します。「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
ORACLE_BASE/product/fmw/wlserver_10.3
「次へ」をクリックします。
「アプリケーション・サーバー」画面で、「WebLogic」を選択します。「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「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_<version>
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
「ミドルウェア・ホーム」には、ORACLE_BASE/product/fmwと入力します。
「Oracleホーム・ディレクトリ」には、たとえばadfのように、使用するディレクトリを入力します。
「次へ」をクリックします。
「アプリケーション・サーバー」画面で、「WebLogic」を選択します。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール完了」画面で「終了」をクリックします。
|
注意: 第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_<バージョン>」を選択
「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
デプロイメントとサービス
管理対象サーバー、クラスタ、およびマシン
管理サーバー
「次へ」をクリックします。
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: 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でシステムを起動する手順について説明します。
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
|
注意: クラスのロード失敗などの問題を回避するために、 |
ノード・マネージャを起動します。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
WebLogic ServerおよびOracle ADFをAPPHOST2にインストールするには、第6.2.3項「WEBHOST1へのOracle HTTP Serverのインストール」以降の手順を繰り返します。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行われません。
pack/unpackユーティリティを使用して、ドメイン構成をAPPHOST2に伝播する手順は次のとおりです。
次のpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cd ORACLE_COMMON_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:ORACLE_COMMON_HOME/common/bin
unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。
APPHOST2> cd ORACLE_COMMON_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クラスタにデプロイする必要があります。これによって、アプリケーションの複数インスタンスに、レプリケーション・チャネルが自動的に確立されます。
|
注意: ユニキャスト・クラスタでは、デフォルトのレプリケーション・チャネルは、各管理対象サーバーのリスニング・アドレスを使用して構成されています。そのため、リスニング・アドレスは、 |
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をドメインに登録します。
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からWebCenterポータル・クラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。次の手順を実行します。
WebLogic Server管理コンソールから、WC_Spaces1、WC_Spaces2、WC_Collaboration1、WC_Collaboration2、WC_Utilities1、WC_Utilities2、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の管理サーバーおよび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管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーをすべて停止します。
新たに作成した管理対象サーバーが実行されていることを確認します。
新たに作成した管理対象サーバー上のアプリケーションにアクセスします。アプリケーションが機能している必要があります。
この項では、WebCenterポータルの高可用性クラスタを設計するために必要な課題および考慮事項を紹介します。
WebCenterポータルは、Java Server Faces(JSF)の標準ベースの宣言型開発と、ポータルの柔軟性とパワー、および一連の統合されたWeb 2.0サービスを組み合せたものです。
WebCenterポータルのコンポーネントは次のとおりです。
Oracle WebCenterポータル: Spacesは、一連の堅牢なサービスとアプリケーションにより、ソーシャル・ネットワーキング、通信、コラボレーションおよび個人の生産性に対して、単一の統合されたWebベース環境を提供します。
Spacesアプリケーションは、JSF、Oracle ADF、Oracle WebCenterポータル: Framework、Oracle WebCenterポータル・サービスおよびComposerを使用して構築されています。Spacesアプリケーションには、次の機能が備えられています。
企業ポータルおよび複数のサイトやコミュニティを作成するためのブラウザベースのプラットフォーム。
個人用コンテンツの格納、メモの保存、ビジネス・プロセスの割当ての表示およびビジネス・プロセスの割当てへの応答、メールの送受信などを行う個人用作業領域である、各ユーザーのホーム・スペース。
スレッド・ディスカッション、ブログ、Wiki、ワークリスト、お知らせ、RSS、最近のアクティビティ、検索など。
Oracle WebCenter Portlets Frameworkは、標準ベースのポートレット(JSR 168、WSRP 1.0および2.0)と従来のOracle PDK-Javaベースのポートレット両方のデプロイメントと実行をサポートしています。WebCenterポータルには、OmniPortlet、Webクリッピング、WSRPツールなど、すぐに使用可能なプロデューサがいくつか用意されています。
Oracle WebCenterポータル: Frameworkの機能は次のとおりです。
ランタイム・アプリケーションのカスタマイズ(アプリケーションを再デプロイせずに、Composerを使用してWebCenterポータル・アプリケーションを即時変更できます)
JSR-168およびJSR-286標準ベースのWSRPポートレットおよびPDK-Javaポートレットのサポート
Oracle WebCenter Content Server、Oracle Portal、ファイル・システムなどのコンテンツ・リポジトリへの、JCR(JSR170)を使用したコンテンツの統合
JSFページおよびOracle ADFタスク・フローを標準ベースのポートレットとして表示できるようにするOracle JSF Portlet Bridge
Oracle WebCenterポータルのディスカッション・サーバーは、ディスカッション・フォーラムやお知らせをアプリケーションに統合する機能を提供します。
Oracle WebCenterポータルのAnalyticsコレクタは、WebCenterポータル・アプリケーション内での様々なユーザー・アクティビティに関するレポートを表示する、次のような機能を提供します。
ログイン
ページ・ビュー
ポートレット・ビュー
ドキュメント・ビュー
検索メトリック
レスポンス時間
Oracle WebCenterポータルのアクティビティ・グラフ・サービスは、Oracle WebCenterポータルのAnalyticsで収集された統計を分析する機能を提供します。アクティビティ・グラフによる分析の出力は、オブジェクトおよびユーザーについて収集されたスコアであり、推奨事項を示すために使用されます。これらのスコアはアクティビティ・データベースに格納されます。
Oracle WebCenterポータルのパーソナライズ・サーバーは、RESTful Webサービスを介してクライアント・アプリケーションからアクセスされる軽量サービスです。パーソナライズ・サーバーを使用すると、ユーザーは選択した基準に基づいて対象ユーザーにアプリケーション・コンテンツを配信できます。
WebCenterポータル・アプリケーションは、WebCenterポータル: サービスと統合することもできます。Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイドのサービス・データ・リポジトリに関する表を参照してください。このガイドでは、WebCenterポータル・サービスを構成する方法についても説明しています。
WebCenterポータルをインストールすると、Middlewareホーム・ディレクトリの下にWebCenterディレクトリが作成されます。このインストールによって作成されるWebCenterドメイン(wc_domain)には、管理サーバーと4つのWebLogic管理対象サーバーであるWC_Spaces1(Spacesアプリケーションをホスト)、WC_Portlet(すぐに使用可能ないくつかのポートレット・プロデューサをホスト)、WC_Collaboration1(ディスカッション・サーバーをホスト)、WC_Utilities1(Analytics、アクティビティ・グラフおよびパーソナライズ・サーバーをホスト)が含まれ、さらに統合用に選択したその他のWebCenterポータル・サービスが含まれます。
WebCenterポータル: Frameworkを使用して構築したWebCenterポータル・アプリケーションは、Frameworkアプリケーションと呼ばれます。追加のカスタム管理対象サーバーを作成すると、適切なライブラリによってこれらのサーバーがプロビジョニングされ、WebCenterポータル: Spacesと同じ外部リソースを利用できるようになります。管理対象サーバーの詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middlewareの概念の理解に関する項を参照してください。図6-4は、WebCenterポータルの基本的な単一ノード・アーキテクチャを示しています。
Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイドのWebCenterポータルの状態と構成の永続性に関する説明を参照してください。
Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイドのWebCenterポータルのログ・ファイルの場所に関する説明を参照してください。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内の別のメンバーがリクエストを処理できます。
WebCenterポータル・デプロイメント内の管理対象サーバーは、それぞれクラスタとしてデプロイでき、異なるクラスタ・メンバーを同じノードまたは異なるノードに配置できます。図6-5では、クラスタに送信されるすべてのリクエストが、クラスタのいずれかのメンバーによって同等に処理されます。
次の各項では、WebCenterポータル・クラスタのランタイムと構成に関して詳細に説明します。
WebCenterポータルのインストール中に、管理対象サーバーにシステム・ライブラリとADFライブラリがプロビジョニングされます。表6-2に、管理対象サーバーとそれらで実行されるアプリケーションの一覧を示します。
管理対象サーバーを起動すると、アプリケーションとライブラリは次の順序で起動します。
Oracleシステム・ライブラリ(別名、JRFライブラリ)
Oracle ADFライブラリ
インスツルメンテーション・アプリケーション(Oracle DMSなど)
WebCenterポータル・アプリケーション
起動順序は依存性の順序でもあります。依存コンポーネントが正しくデプロイされないと、その後のコンポーネントが正しく機能しない場合があります。WebCenterポータル・アプリケーションの起動は、ディスカッション・サーバーなどの外部サービスやその他のバックエンド・サーバーの可用性に依存しません。
図6-5に示すようなWebCenterポータルのクラスタ・デプロイメントでは、アプリケーション、ライブラリおよびシステム・リソースのターゲット設定に関して、次のルールに従います。
アプリケーションとライブラリのターゲットをクラスタのターゲットに設定します。たとえば、SpacesアプリケーションのターゲットをSpacesクラスタに設定します。
JDBCリソースのターゲットをクラスタのターゲットに設定します。
WebCenterポータル・アプリケーションおよびWebCenterポータル・ディスカッション・サーバーは、Oracle WebLogicstageアプリケーションとしてデプロイされます。各アプリケーションの初期デプロイメント中に、デプロイメント・ファイルが管理サーバーから送信され、ローカルにデプロイされます。
クラスタ通信
デフォルトでは、各WebCenterポータル・クラスタはユニキャストとして構成されています。WebCenterポータル・クラスタをマルチキャスト用に構成するには、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。
WebCenterポータルのAnalyticsは、SpacesアプリケーションなどのAnalyticsクライアントからリクエストを受信する、個別のAnalyticsコレクタで構成されています。
この項では、Analyticsコレクタ・クラスタがどのように機能するのかを説明します。
クラスタ化された環境では、プロデューサ(コレクタのクライアント)およびコレクタは、クラスタ固有のチャネル名で構成されます。各コレクタは、その場所からクラスタ固有のチャネルで定期的にハートビートをブロードキャストします。プロデューサはそのチャネルでこれらのコレクタのハートビートをリスニングし、ハートビートを受信すると、そのコレクタを既知のコレクタのリストに追加します。プロデューサがイベントを送信する必要がある場合は、ラウンドロビン・アルゴリズムを使用してそのリストからコレクタを選択し、そのコレクタにイベントを送信します。(意図的に、または障害によって)コレクタが停止すると、ハートビートのブロードキャストは停止します。プロデューサがハートビートの受信を停止した場合、そのコレクタをリストから削除して、そのコレクタへのイベントの送信を停止します。いずれのコレクタのハートビートも受信しない場合は、イベントを送信しません。
WebCenterポータルAnalyticsは、構成された一連のポート上でUDPおよびマルチキャストを使用してクライアントと通信します。単一ノード・セットアップでは、クライアントは、サーバー・ホストとポートの場所を持つWLSTコマンドで構成され、すべてのイベントをUDPを使用してその場所に送信します。複数ノード・セットアップの場合、サーバーはクラスタで実行中の様々なサーバーの場所に(UDPマルチキャストを使用して)ブロードキャストするよう構成され、クライアントは同じWLSTコマンドで構成されるため、クライアントはサーバーの場所を受信し、使用可能なサーバーのリストを保持します(これはメモリー内に格納されます)。クライアントでサーバーからの定期的なハートビートが受信されない場合、クライアントはそのサーバーを既知のサーバーのリストから削除してイベントの送信を停止します。
WebCenterポータル・アプリケーション・クライアントと1対1の関係になるよう、Analyticsコレクタをユニキャストとして構成することをお薦めします。
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項「WebCenterポータルの状態のレプリケーション」を参照してください。
WebCenterポータル・アプリケーションでは、パフォーマンス向上のために分散Javaオブジェクト・キャッシュが使用されています。このキャッシュはすべてのWebCenterポータル・クラスタで構成し、クラスタごとに分散キャッシュを1つずつ用意します。
表6-3は、WebCenterポータルがJavaオブジェクト・キャッシュに配置するオブジェクト・タイプの例を一覧表示しています。
表6-3 WebCenterポータルのJavaオブジェクト・キャッシュ用のオブジェクト・タイプ
| WebCenterポータル・コンポーネント | キャッシュされるオブジェクト |
|---|---|
|
ディスカッション・サービス |
トピックとフォーラム |
|
お知らせサービス |
お知らせ |
|
インスタント・メッセージおよびプレゼンス・サービス |
プレゼンス・サブスクリプション・リスト ユーザーのプレゼンス/サブスクリプション・ステータス |
|
ワークリスト・サービス |
呼び出されたワークリスト項目(キャッシュ済データは、リフレッシュが呼び出されるまで使用されます)。 |
|
コンテンツ統合(Oracle Portal) |
JCR: リポジトリから取得したタイプ情報とメタデータ。 |
|
サービス・フレームワーク |
ユーザー・プロファイル。問合せされたユーザー名。 |
|
最近のアクティビティ・サービス |
ユーザーごとの最近のアクティビティ結果。 |
|
Spacesアプリケーション |
アプリケーション内のスペースとスペース・テンプレートのグローバル・リスト。 ユーザーがアクセス可能なスペースとスペース・テンプレートのリスト。 |
|
ページ・サービス |
スコープ内のページのリスト。 |
|
WSRPサーバー |
WSRPプロデューサのプリファレンス・ストアの値。 |
|
ドキュメント・サービス |
Spacesアプリケーション用に構成されたドキュメント・サービスのプロビジョニングと構成のチェック。 |
|
プロファイルの管理 |
軽量ユーザー・プロファイル・オブジェクト |
|
ナビゲーション・サービス |
アクティブなナビゲーション・モデル・オブジェクトのリスト |
|
ポートレット・コンシューマ |
ポートレット・マークアップ |
コラボレーション
コラボレーション・サービスは、ユーザー・セッションごとにオブジェクトをJavaオブジェクト・キャッシュに格納します。HTTPセッションが破棄されると、これらのキャッシュ済ユーザー・セッションも破棄されます。
ワークリスト
ワークリストは呼び出された項目をキャッシュするため、リフレッシュをクリックするか、または15分間隔のリフレッシュ・ポーリングをトリガーしないかぎり、ユーザーが設定によってソートやグループを変更する際に同じ項目が表示されます。グループおよびソートの順序の設定により表示もキャッシュされ、変更が行われたときに更新されます。これは読取り専用データで、存在しない場合にはフェッチされてキャッシュに格納されます。
Spacesアプリケーション
すべてのテンプレートおよびパブリック・スペースのリストは、Javaオブジェクト・キャッシュに保持されます。すべてのユーザーは、特定のユーザーがアクセスできるスペースとテンプレートのリストに加えて、このリストを共有します。これらはユーザーごとにキャッシュされます。1つのJVMで作成されるテンプレートは、JOCがデータを配布するか、または2番目のJVMの管理者が明示的リフレッシュを行ってキャッシュを再構築しないかぎり、テンプレート・キャッシュが別のJVMで初期化されている場合には表示されません。
ドキュメント・サービス
Spacesアプリケーションの構成と同様、ドキュメント・サービスは、Javaオブジェクト・キャッシュを使用して、ドキュメント・サービスのプロビジョニングと構成のチェックをキャッシュします。プロビジョニングの場合、キャッシュされたオブジェクトには分散済のフラグが付けられます。これらのオブジェクトは、正しく構成されたJavaオブジェクト・キャッシュによって高可用性環境内でレプリケートされ、構成のキャッシュ済状態はローカルで保持されます。キャッシュされたオブジェクトはすべて、1分後に期限切れとなるようにフラグが付けられます。Spacesアプリケーションがプロビジョニングと構成を繰り返しチェックしてUIにおけるサービスのレンダリングを制御するため、キャッシュすることによって、Oracle WebCenter Content Serverの状態をチェックする目的でOracle WebCenter Contentコールが行われる回数が減ります。
ポートレット・コンシューマ
ポートレット・コンシューマでは、ポートレット・レスポンスのキャッシュ・ヘッダーに応じて、ポートレット・マークアップがJavaオブジェクト・キャッシュに格納されます。このキャッシュは、期限切れベースまたは検証ベースになります。
プロファイルの管理では、軽量のユーザー・プロファイル・オブジェクトがJavaオブジェクト・キャッシュに格納されます。特定のプロファイル・データが見つからない場合、バックエンドから問合せが行われ、キャッシュに格納されます。格納されるオブジェクトの数の上限は1000であり、Javaオブジェクト・キャッシュに1時間保持されます。
ナビゲーションでは、ユーザー・セッションごとにナビゲーション・モデル・オブジェクトがJavaオブジェクト・キャッシュに格納されます。HTTPセッションが破棄されると、これらのキャッシュされたオブジェクトも破棄されます。
最近のアクティビティ
最近のアクティビティのタスク・フローまたはRSSフィードが表示されるたびに結果の再問合せが行われないようにするため、最近のアクティビティ結果のリストは、ユーザーごとにキャッシュされます。キャッシュは15分ごとに自動的にリフレッシュされるか、または最近のアクティビティのタスク・フローにあるリフレッシュ・アイコンを使用して手動でリフレッシュできます。
Javaオブジェクト・キャッシュの構成手順については、第6.4.13項「Javaオブジェクト・キャッシュの構成」を参照してください。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内で他に利用可能なメンバーがリクエストを処理できます。
セッションのフェイルオーバー要件
WebCenterポータル・アプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。
クラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できる必要があります。
ステートフルな場合、第6.4.15項「WebCenterポータルのレプリケーションの構成」の説明に従って、状態のレプリケーションが正しく構成されています。
Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されています。
ハードウェア・ロード・バランサを使用する場合は、ロード・バランサが:
利用可能なインスタンスすべてに対してトラフィックをルーティングしています
利用できないインスタンスをマークするように、状態モニターで正しく構成されています
セッションの状態の永続性をサポートするように構成されています
環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気が付きません。アプリケーション・フェイルオーバーにおけるイベントの順序の例は次のようになります。
ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。
ノード、プロセスまたはネットワークに障害が発生したため、インスタンスAが使用できなくなります。
ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。
ユーザーが後続のリクエストを行い、このリクエストがインスタンスBにルーティングされます。
インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。
インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。
予想される動作に対する例外
WebCenterポータルについて、既知の例外は次のとおりです。
Oracle ADFのポップアップ: 開いているポップアップがフェイルオーバー時に閉じられ、次のコンポーネントに影響を与えます(それ以外の場合は、例外はありません)。
Composer(プロパティ・インスペクタ、ELビルダー、タスク・フローのパラメータ選択リスト、リソース文字列エディタ)
保存(確認ダイアログ・ボックス)
リスト
リンク(リンク削除のポップアップ)
フェイルオーバーの発生時には、ポップアップが表示される操作を再実行して、そのポップアップを再表示する必要があります。これがSpacesに表示される具体的な方法および推奨される処置は、表6-4に一覧表示されています。
表6-4 WebCenterポータルのトラブルシューティングのシナリオ
| フェイルオーバー前のアクション | フェイルオーバー後 | 推奨される処置 |
|---|---|---|
|
任意のページにアクセスして「ページの作成」をクリックします。 |
名前を入力し、テーマを選択して「OK」をクリックします。テーマを選択すると、「ページ作成」ポップアップが閉じられます。 |
この操作を繰り返します。 |
|
「ページの管理」を起動します。 |
ポップアップ内で、ポップアップを閉じる以外の操作を実行します。たとえば、「ページ・アクション」をクリックします。任意の操作を実行すると、「ページの管理」ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「ページの管理」を起動し、ページに対して「ページ・アクション」をクリックしてから、メニュー内の「削除」オプションをクリックします。 |
確認ポップアップで「OK」をクリックします。「OK」をクリックすると、確認ポップアップと「ページの管理」ポップアップが閉じます。削除(完了済の可能性がある)の結果は、タブ間で表示されません。 |
「ページの管理」ポップアップを再起動し、ページが削除されたかどうかを確認します。削除されていない場合は、もう一度削除してみます。 |
|
「アプリケーションのパーソナライズ」ポップアップを起動します。「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。 |
「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。リクエストをサーバーに送信する任意の操作を実行すると、「アプリケーションのパーソナライズ」ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「プリファレンス」を起動します。 |
「プリファレンス」のタブ(「一般」、アカウント、「メッセージング」、「検索」)間の切替えを行います。「プリファレンス」のタブ間で切替えを行うと、「プリファレンス」ポップアップが閉じます。 |
この操作を繰り返します。 |
|
「お気に入りの管理」を起動します。サーバーを停止して、ポップアップを閉じる以外の操作を実行します。たとえば、フォルダを開いてお気に入り情報の編集をクリックします。 |
ポップアップを閉じる以外の操作を実行します。たとえば、フォルダを開いてお気に入り情報の編集をクリックします。任意の操作を実行すると、「お気に入りの管理」ポップアップが閉じます。 |
「お気に入りの管理」ポップアップを再起動し、操作が正常に実行されたかどうかを確認します。正常に実行されなかった場合は、この操作を再試行します。 |
|
アプリケーションの編集と新しいフォルダの作成を選択します。 |
MDSの例外が開きます。 |
この操作を再試行します。 |
|
ComposerのCustomization Managerで作業します。 |
Oracle Composerは、Customization Managerに関連する状態を失います。 |
Customization Managerを再起動します。 |
|
Oracle Composerのソース・ビューでコンポーネントを選択します。 |
Oracle Composerは、コンポーネントを見失います。 |
この操作を繰り返します。 |
|
「スペース管理」を開いてスペースを選択してから、「保守のためにオフライン」を「編集」メニューから選択します。 |
「OK」をクリックして、スペースをオフラインにします。 次のエラーが表示されます: 不明なエラーのため、選択したスペースへの操作を実行できません一部の必須リソースが使用中です。後で再試行してください。 「OK」をエラー・ポップアップでクリックして、スペースをオフラインにしません。 |
この操作を繰り返します。 |
コンポーネント固有の問題 - WebCenterポータルの各コンポーネントに固有の他の問題は、表6-5に一覧表示されています。
表6-5 WebCenterポータルでの予想される動作に対する例外
| WebCenterポータル・コンポーネント | 予想される動作に対する例外 |
|---|---|
|
ページレット・プロデューサ |
フェイルオーバー時には、未保存または保留中の変更は保持されません。フェイルオーバーが発生すると、管理者は 管理セッションを再確立する必要があり、特定の状態を保持するためにプロキシが必要なときには、ユーザーもセッションを再確立する必要がある場合があります。SSOが構成されている場合、資格証明が自動的に提供され、セッションが再確立されます。 |
|
スペース・イベント |
特定のフィールド(開始または終了の日/時/分)を変更すると、フェイルオーバーの発生時にイベント・フォームが閉じます。 |
|
ポートレット |
障害は完全に透過的です。 |
|
リスト |
障害は完全に透過的です。 |
|
リンク |
障害は完全に透過的です。 |
|
検索 |
長時間実行される問合せの最中。戻される結果は保証されません(ここでは書込み操作は存在しないことに注意)。ユーザーは問合せを再発行できます。 |
|
タグ付け |
障害は完全に透過的です。 |
|
最近のアクティビティ |
ツリー・ノードのオープン/クローズ状態はレプリケートされません。フェイルオーバー後、結果のツリーによってノードがすべて閉じます。ノードは開きなおす必要があります。 |
|
ワークリスト |
障害は完全に透過的です。 |
|
ドキュメント・マネージャ |
ユーザーがドキュメントをアップロードしたときに、同じ名前のドキュメントがすでに存在している場合は、「新規バージョンの確認」画面が表示されます。その画面の表示中、ファイルは一時的なローカルの場所に格納されます。そのときにフェイルオーバーが発生すると、アップロードしたファイルは失われ、ユーザーはアップロード・プロセスを再実行する必要があります。 |
Oracle WebLogic Server管理コンソールを使用して、アプリケーション・デプロイメントのステータスを確認します。また、WebCenterポータル・プロセスの開始、停止および監視には、Oracle WebLogic ServerインフラストラクチャとEnterprise Manager Fusion Middleware Controlも使用できます。
Spacesアプリケーションとポートレット・プロデューサの場合、すべての構成データはMDSリポジトリおよびポートレット・プロデューサに格納されます。アプリケーションの起動時には、追加のクラスタ・デプロイメントによって、最新の構成が自動的に読み取られます。
ディスカッション・サーバーの場合、構成情報は既存のクラスタ・サーバーから移動する必要があります。これは、Oracle WebLogic Serverのpack/unpackユーティリティによって自動的に行われます。これがお薦めする手順です。
図6-5は、1つのWebLogic Serverドメイン内の2つのOracle WebLogic Serverで、2ノードのWebCenterポータル・クラスタが稼働している状況を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。Oracle RACデータベースには、メタデータとスキーマが格納されます。管理サーバーにはVIPが使用されます(手動フェイルオーバー用)。
|
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
|
注意: コマンド例はすべて、Kシェルまたはbashシェルに対するものです。Cシェルの例は提供されていません。 |
WebCenterポータルの高可用性の構成手順は次のとおりです。
第6.4.5項「WebLogic Server WebCenterのドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」
第6.4.11項「Oracle HTTP Serverの管理サーバーおよびWebCenterポータル管理対象サーバーの構成」
次の各項では、WebCenterポータルの高可用性構成を設定する前に必要となる手順について説明します。
プラットフォーム固有のコマンドの詳細は、Oracle Fusion Middleware Oracle WebCenterインストレーション・ガイドを参照してください。
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管理者ガイドを参照してください。 |
本番環境では、WebCenterポータルの高可用性トポロジには外部LDAPポリシー・ストアが必要です。サポートされるポリシー・ストアおよびLDAPの構成手順の詳細は、Oracle Fusion Middleware Oracle WebCenterポータル管理者ガイドを参照してください。
次のリストは、この項で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware(FMW)が常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、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
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名またはノード名の1つを指定します: WCDBHOST1VIRTUAL
ポート: データベースのポート番号: 1521
サービス名: データベースのサービス名を入力します: wcha.mycompany.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワードを入力します。
ロール: SYSDBA
「次へ」をクリックします。
次の警告メッセージを受信した場合は、「無視」または「停止」をクリックします。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、WCHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。
次のスキーマを選択します。
AS共通スキーマ:
Metadata Services
WebCenterインフラストラクチャ:
WebCenterポータル
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力します。「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択します。「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
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のインストール」を参照)
WebCenterポータル(第6.4.3.2項「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_<バージョン> SDK」のみを選択して、「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
WL_HOME
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。
アプリケーション層にあるすべてのノードにWebCenterポータル用のOracle Fusion Middlewareをインストールする手順は次のとおりです。
WebCenterポータル用のOracle Fusion Middlewareのインストーラを起動します。
UNIXの場合(次の例はLinuxの場合):
APPHOST1> runInstaller
Windowsの場合:
APPHOST1> setup.exe
Oracle Fusion Middleware 11g WebCenterインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_<バージョン>のように入力します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
「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構成ウィザードを実行し、管理サーバーとWebCenterポータル・コンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースでは、すべてのインスタンスを実行することをお薦めします。
次のコマンドを使用して、ORACLE_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。
APPHOST1> ./config.sh
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で、「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択します。次の製品を選択します。
WebCenter Spacesを選択すると、Oracle WSMポリシー・マネージャが自動的に選択されます。
Oracle WebCenter Spaces - 11.1.1.0
Oracle WebCenterサービス・ポートレット - 11.1.1.0
Oracle WebCenterページレット・プロデューサ - 11.1.1.0
Oracle Enterprise Manager - 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 WSM Policy Manager
Oracle JRF - 11.1.1.1
「次へ」をクリックします。
「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者が使用するユーザー名とパスワードを入力します。「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で次を選択します。
WebLogicドメインの起動モード: 「本番モード」を選択
JDKの選択: 「Oracle JRockit 1.6.0_<バージョン>」を選択します。
「次へ」をクリックします。
「JDBCデータ・ソースの構成」画面で、次の手順を実行します。
画面の下部にある表で、すべてのコンポーネント・スキーマを選択します。
「コンポーネント・スキーマのRAC構成」については、「GridLinkへ変換」または「RACマルチ・データ・ソースへ変換」を選択します。単一のデータベース構成の場合は、「変換しない」を選択します。
画面に次のデータ・ソースが表示されていることを確認します。これらのスキーマにはカスタム接頭辞を指定します。表6-7は、データ・ソース、使用するスキーマ、およびスキーマが割り当てられている管理対象サーバーを一覧表示しています。
Oracle RACおよびMDSリポジトリでのGridLinkデータ・ソースの構成の詳細は、第4.1.2項「GridLinkデータ・ソースおよびOracle RAC」を参照し、マルチ・データ・ソースの場合は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。
表6-7 Oracle WebCenterポータルのデータ・ソース
| データ・ソース | ユーザー名 |
|---|---|
|
WebCenterDS |
wcha_webcenter |
|
ActivitiesDS |
wcha_activities |
|
DiscussionsDS |
wcha_discussions |
|
PersonalizationDS |
wcha_webcenter |
|
PortletDS |
wcha_portlet |
|
Portlet-ServicesProducerDS |
wcha_portlet |
|
WC-ServicesProducerDS |
wcha_webcenter |
|
WebCenterMDS |
wcha_mds |
|
PersonalizationMDS |
wcha_mds |
|
mds-PageletProducerDS |
wcha_mds |
|
mds-ServicesProducerDS |
wcha_mds |
「次へ」をクリックします。
「JDBCコンポーネント・スキーマの構成」画面で、次のフィールドに値を入力して、RCUでシードされたOracle RACデータベースの接続情報を指定します。
マルチ・データ・ソースの場合は、次のフィールドに値を入力します。
GridLinkデータ・ソースの場合は、次のフィールドに値を入力します。
ドライバとして、RACの場合には、OracleのRACサービス・インスタンス接続用ドライバ(Thin)、バージョン:10、11を選択します。GridLinkの場合は、OracleのGridLink接続用ドライバ(Thin)、バージョン:10以降を選択します。
データベースの「サービス名」を入力します。GridLinkデータ・ソースの場合は、RACサービス名を小文字で入力し、その後にドメイン名example.comを入力する必要があります。たとえば、<mydbservice>.example.comと入力します。
|
注意: Oracle RACサービス名はデータベースで定義されており、固定名ではありません。データベース・ドメイン名( |
WebCenterポータル・スキーマのPrefix_Usernameを入力します。
スキーマの「パスワード」を入力します。
GridLinkデータ・ソースの場合は、SCANアドレスをリスナー・アドレス・フィールドに入力し、「ポート」フィールドにSCANポートを入力します。「ONSホスト」と「ポート」の各フィールドに、ONSホストおよびポート情報を入力します。
|
注意: WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、SCANアドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、御社のネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。 |
マルチ・データ・ソースの場合は、「追加」をクリックします。Oracle RACインスタンスの詳細を入力します。
一度に1つのデータ・ソースを選択し、適切な詳細を追加することで、各マルチ・データ・ソース・スキーマを更新します。
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。(GridLinkデータ・ソースの場合は、ONS接続もテストされます。)「ステータス」列に結果が表示されます。すべての接続が成功したことを確認します。正常でない接続があった場合には、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続が正常になったら「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: 第6.4.4項で使用したVIPアドレスを入力します。
リスニング・ポート: 7001
SSLリスニング・ポート: N/A
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。
表6-8 管理対象サーバーの構成
| 名前 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
|---|---|---|---|---|
|
WC_Portlet1 |
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
|
注意: デフォルトでは、各WebCenterポータル・クラスタはユニキャストとして構成されています。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/wc_domain/servers/AdminServer/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。
username=adminuser password=password
|
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。 セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
WC_Spaces1管理対象サーバーに対して、次の手順を実行します。
次のディレクトリを作成します。
APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wc_domain/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/wc_domain/bin
APPHOST1> ./startWebLogic.sh
管理サーバーが適切に構成されていることを確認する手順は次のとおりです。
ブラウザでhttp://VIP1:7001/consoleにアクセスします。
管理者としてログインします。
すべての管理対象サーバー(WC_Spaces1、WC_Spaces2など)がリストされていることを確認します。
すべてのクラスタがリストされていることを確認します。
Enterprise Manager(http://VIP1:7001/em)にアクセスできることを確認します。
EMコンソールに、手順2で使用したユーザー名とパスワードを使用してログインします。
この手順が必要になるのは、管理サーバーとノード・マネージャの間に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
|
注意: クラスのロード障害などの問題が発生しないようにするには、 |
ノード・マネージャを起動します。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
APPHOST2に対し、WebLogic Serverと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/wc_domain/
-template=wc_domaintemplate.jar
-template_name=wc_domain_template
次のコマンドをAPPHOST1で実行し、前の手順で作成したテンプレート・ファイルをAPPHOST2にコピーします。この例ではscpを使用しています。
APPHOST1> scp wc_domaintemplate.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/wc_domain/ -template=wc_domaintemplate.jar
APPHOST2でノード・マネージャを起動するには、第6.4.7.4項「APPHOST1でのノード・マネージャの起動」の手順をAPPHOST2で繰り返します。
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>
# Pagelet Producer
<Location /pagelets>
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>
# SES Search
<Location /rsscrawl>
SetHandler weblogic-handler
WeblogicHost ses.example.com
WeblogicPort 7777
</Location>
<Location /sesUserAuth>
SetHandler weblogic-handler
WeblogicHost ses.example.com
WeblogicPort 7777
</Location>
# Personalization
<Location /wcps>
SetHandler weblogic-handle
WeblogicHost webcenter.example.com
WeblogicPort 8889
</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にはマッピングが必要ですが、単一の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-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に追加されたことを確認します。
URLを検証し、HTTP Serverから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を実行しているすべてのサーバー間で構成する必要があります。このローカル・キャッシュは、Spacesアプリケーションのパフォーマンスを向上させるために提供されています。
Spacesアプリケーションを実行するすべてのサーバー間でのJavaオブジェクト・キャッシュの構成の説明は、第F.1項「Javaオブジェクト・キャッシュの構成」を参照してください。
高可用性環境では、MDSリポジトリに対して分散通知を構成することをお薦めします。
MDSリポジトリに対する分散通知の構成の詳細は、付録G「MDSに対する分散通知の構成」を参照してください。
この項の手順を使用して、WebCenterポータルのレプリケーションを構成します。
クラスタリング要件
アプリケーションをOracle WebLogicクラスタにデプロイする必要があります。これによって、アプリケーションの複数インスタンスに、レプリケーション・チャネルが自動的に確立されます。
|
注意: ユニキャスト・クラスタでは、デフォルトのレプリケーション・チャネルは、各管理対象サーバーのリスニング・アドレスを使用して構成されています。そのため、リスニング・アドレスは、 |
Oracle ADFのレプリケーション
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クラスタの使用』を参照してください。
WebCenterポータル・アプリケーションは、weblogic.xmlファイルの次の設定により、デフォルトで有効になっています。
<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
replicated_if_clustered設定は、スタンドアロン・アプリケーション環境のレプリケーションを無効にし、クラスタ環境内のメモリー内レプリケーションを使用します。
すべてのWebCenterポータル・アプリケーションがメモリー内レプリケーション用に構成されていることを確認します。
Analyticsコレクタはすぐに使用できるよう構成されているため、必要な操作は、SpacesアプリケーションとAnalyticsコレクタ間の接続を構成することのみです。
次のように、WLSTシェルを開きます。
ORACLE_HOME/common/bin/wlst.sh
次のように、WLSサーバーに接続します。
connect('weblogic_admin_username', 'weblogic_admin_pwd', 'APPHOST1:8888')
ホストに接続し、Spaces Serverのポートに接続していることに注意してください。
次のように、Analyticsコレクタ接続を作成し、それをデフォルトの接続にします。
createAnalyticsCollectorConnection(appName='webcenter', connectionName='HAConn1', isUnicast=1, collectorHost='localhost', collectorPort=31314, isEnabled=1, timeout=30, default=1)
次のように、行った変更をリストします。
listDefaultAnalyticsCollectorConnection(appName='webcenter')
アクティビティ・グラフ・エンジン・アプリケーションは、シングルトンとして実行する必要があります。クラスタ環境では、アクティビティ・グラフ・エンジン・アプリケーションのインスタンスは1つを除いてすべて無効化する必要があります。
アクティビティ・グラフ・エンジン・アプリケーションを無効化する手順は次のとおりです。
Oracle WebLogic管理コンソールにログインします。
WC_Spaces、WC_PortletおよびWC_Utilitiesを停止します。「デプロイメント」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
次の各デプロイメントのターゲットを変更します。
activitygraph-engines(11.1.1.6.0)
oracle.webcenter.activitygraph.enginelib(11.1.1,11.1.1)
oracle.webcenter.activitygraph.lib(11.1.1,11.1.1)
デプロイメントを選択します。
「 ターゲット 」タブを選択します。「ターゲットの変更」をクリックします。
デプロイメントのターゲットが、クラスタの一部/管理対象サーバーの1つのみになっていることを確認します。「OK」をクリックして変更を保存します。
すべての変更をアクティブ化をクリックします。
アクティビティ・グラフは1つのノードでのみ実行されているため、このノードが失われたり、管理対象サーバーが使用不可になると、アクティビティ・グラフは使用できなくなります。この場合、アクティビティ・グラフをアクティブな管理対象サーバー上にデプロイすることをお薦めします。このプロセスは、サービスの移行を構成することによって自動化できます。例については、第5.13.20項「WLS_SOAサーバーのサーバー移行の構成」を参照してください。
この手順にはユニキャスト・クラスタが必要です。
この手順を実行する前に、第6.4.21項「マルチキャストからユニキャストへのディスカッションの変換」の次の操作に関する説明を参照してください。
マルチキャスト・クラスからユニキャスト・クラスタへの変換(必要に応じて)
既存のユニキャスト・クラスタが正しく設定されていることの確認
ディスカッション・サーバー管理コンソールを使用して、ディスカッション・サーバー・クラスタのすべてのメンバーが相互に通信できることを確認します。
次の場所にあるクラスタの各メンバーにログインします。
http://<host>:<port>/owc_discussions/admin
「キャッシュ設定」を開きます。
ページの下部にある「キャッシュ機能」セクションで、「クラスタリング」が「有効」に設定されていることを確認します。
ページの上部に、クラスタのすべてのメンバーが一覧表示されます。
再度ページの下部に移動し、「キャッシュ・ツール」セクションで、クラスタワイドでのキャッシュのリセットおよびキャッシュのウォームアップ・タスクを実行します。クラスタのすべてのメンバーで、キャッシュのウォームアップ・タスクを繰り返します。
WebCenterポータル・トポロジは、スケール・アウトまたはスケール・アップが可能です。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。
この場合は、WebCenterポータル・コンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードの共有記憶域には、MiddlewareホームとWebCenterディレクトリが格納されています。
新しい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の管理サーバーおよびWebCenterポータル管理対象サーバーの構成」を参照してください。
トポロジのスケール・アウトでは、WebCenterポータル・アプリケーションを使用して構成されている新しい管理対象サーバーを新しいノードに追加します。
この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。
トポロジ内には、WebCenterポータル・アプリケーションを使用して構成されている管理対象サーバーを実行しているノードがすでに存在しています。
新しいノードは、WebLogic Serverおよび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_<version>
Middlewareホーム・リストを更新するには、MW_HOME/bea/beahomelistファイルを作成し(別のWebLogicインストールがノード内に存在する場合はそれを編集)、それにORACLE_BASE/product/fmwを追加します。
Oracle WebLogic管理コンソールにログインします。
新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
Oracle WebLogic Server管理コンソールを使用し、WC_Spaces1、WC_Portlet1、WC_Collaboration1またはWC_Utilities1のクローンを作成して新しい管理対象サーバーにします。それにWC_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/wc_domain/ -template=webcenterdomaintemplateScale.jar -template_name=webcenter_domain_templateScale
次のコマンドをWCHOST1で実行し、作成したテンプレート・ファイルをWCHOSTnにコピーします。
WCHOST1> scp wc_domaintemplateScale.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/ wc_domain/ -template=wc_domaintemplateScale.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管理コンソールから新しい管理対象サーバーを起動して、テストします。
クラスタ内の既存の管理対象サーバーをすべて停止します。
新たに作成した管理対象サーバーが実行されていることを確認します。
新たに作成した管理対象サーバー上のアプリケーションにアクセスします。アプリケーションが機能している必要があります。
この項では、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_Spaces1---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や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=WCPHOST1 -Dtangosol.coherence.wka2=WCPHOST2 -Dtangosol.coherence.localhost=WCPHOST1 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.localport=8089
Host1は、WC_Collaboration1が実行されている場所です。
WebCenter Coherenceの通信に8088以外のポートを使用するには、前述の例の引数-Dtangosol.coherence.wka1.portおよび-Dtangosol.coherence.wka2.portを使用して、別のポート番号を指定します。
WC_Collaboration2に対してステップ1と2を繰り返します。ただし、ローカルホスト・パラメータにはHost2に設定します。
WC_Collaborationサーバーを再起動します。
ステップ2: 変更の検証
変更を検証する手順は次のとおりです。
ディスカッション・フォーラムの管理コンソール(http://<ホスト>:<ポート>/owc_discussions/admin.)にログインします。
左ペインで「キャッシュ設定」を選択します。
画面の下部で、「クラスタリング」が「有効」に設定されていることを確認します。
クラスタのすべてのメンバーに対して、ステップ1から3を繰り返します。
サーバーがクラスタに参加すると、それらのサーバーが画面の上部に表示されます。
WebCenterポータル・アプリケーションは、必須ライブラリをプロビジョニング済のサーバーおよびクラスタにデプロイされます。このプロビジョニングは、既存のWebCenterポータル・ドメインにドメイン・テンプレートを適用することによって行われます。
拡張は、ドメインごとに一度のみ実行できます。したがって、どのWebCenterポータル・アプリケーション・サーバーも、一度に作成するか、または既存のWebCenterポータル・アプリケーション・サーバーのクローンとして作成する必要があります。
WebCenterポータル・アプリケーションをデプロイするためにクラスタを構成する手順は、次のとおりです。
次のコマンドを使用して、ORACLE_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。
APPHOST1> ./config.sh
「ようこそ」画面で「既存のWebLogicドメインの拡張」を選択します。「次へ」をクリックします。
次の画面で、Weblogicドメイン・ディレクトリを選択します。
次の画面で、「既存の拡張テンプレートを使用してドメインを拡張する」を選択します。
独自のFrameworkアプリケーションを作成するのか、ポートレット・プロデューサ・アプリケーションを作成するのかに応じて、次の2つのテンプレートのいずれかを選択します。
Frameworkアプリケーションの場合:
$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として構成します。アプリケーションでは既存のスキーマを使用します。
データベース接続情報を入力し、次に、データ・ソースのステータスをチェックします。
オプション構成画面で、「管理対象サーバー、クラスタ、およびマシン」を選択します。
「管理対象サーバー」画面で、次のように実行します。
手順5で、custom_portalテンプレートを選択した場合は、管理対象サーバーの名前をWC_CustomPortalからWC_CustomPortal_Cluster1に変更します。custom_services_producer_templateを選択した場合は、管理対象サーバーの名前をWC_CustomServicesProducerからWC_CustomServicesProducer_Cluster1に変更します。
「追加」をクリックして新しい管理対象サーバーを作成し、そのサーバーにWC_CustomPortal_Cluster2と名前を付けます。リスニング・ポートをWC_CustomPortal_Cluster1のリスニング・ポートと同じになるよう設定します。
「クラスタの構成」画面で、クラスタWC_CustomServicesProducer_Cluster1を追加します。
「サーバーのクラスタへの割当」画面で、新しく作成した2つのサーバーをクラスタに追加します。
「サーバーのマシンへの割当」画面で、2つのサーバーをそれぞれ別のマシンに配置します。
「拡張」→「完了」をクリックし、ドメインを拡張します。
Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを起動し、WebCenterポータル・アプリケーションをデプロイできるようになりました。これらのWebCenterポータル・アプリケーションは、管理対象サーバーのターゲットではなく、クラスタのターゲットにデプロイします。
新しいサーバーは、既存のサーバーのクローニングによって拡張されているドメインにのみ追加できます。
Oracle WebLogic Server管理コンソール(http://APPHOST1:7001/console)にアクセスし、ログインします。
「ドメイン構造」ウィンドウで、「環境」→「サーバー」を選択し、「サーバーのサマリー」ページに既存の管理対象サーバーをすべて表示します。
いずれかのカスタム管理対象サーバーを選択します。「クローンの作成」をクリックします。
サービス名(WC_CustomPortal3など)を入力します。この新しいサーバーを配置するリスニング・アドレスとポートを設定します。
サーバーが自動的にクラスタ(WC_CustomPortalClusterなど)のメンバーになります。
高可用性WebCenterポータル・アプリケーションの場合は、MDSリポジトリに対して分散通知を構成することをお薦めします。MDSリポジトリに対する分散通知の構成の詳細は、付録G「MDSに対する分散通知の構成」を参照してください。
