ヘッダーをスキップ
Oracle® Fusion Middleware高可用性ガイド
11gリリース1（11.1.1）
B55898-02
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

6 Oracle ADFおよびWebCenterアプリケーションの高可用性の構成

この章では、Oracle Application Development Framework（Oracle ADF）とOracle WebCenterの高可用性の概要と構成手順について説明します。

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

6.1 Oracle ADFと高可用性の概要

Oracle ADFは、JavaPlatform, Enterprise Edition（Java EE）の標準およびオープンソース・テクノロジに基づいて作成されたエンドツーエンド・アプリケーション・フレームワークで、サービス指向アプリケーションの実装を簡素化および迅速化します。Oracle ADFは、Web、無線、デスクトップ、またはWebサービスのインタフェースを使用してデータの検索、表示、作成、変更および検証を行うアプリケーションを作成するエンタープライズ開発者に適しています。Oracle JDeveloper 11gとOracle ADFを連携させると、ドラッグ・アンド・ドロップでのデータ・バインディング、視覚的なUI設計およびチーム開発の各機能を組み込んで、設計からデプロイまでの完全な開発ライフサイクルに対応する環境を作成できます。

6.1.1 Oracle ADFの理解

コミュニティのベスト・プラクティスに従い、Fusion Webテクノロジ・スタックを使用して作成したアプリケーションでは、次のレイヤーによってサポートされているモデル・ビュー・コントローラ（MVC: Model-View-Controller）アーキテクチャに準拠することで、ビジネス・ロジック、ページ・ナビゲーションおよびユーザー・インタフェースが明確に分離されます。

図6-1に示すように、MVCアーキテクチャでは次のような構成になります。

  • モデル・レイヤーは、現行ページに関連するデータ値を表します。

  • ビュー・レイヤーには、その関連データの表示や変更に使用するUIページが保持されます。

  • コントローラ・レイヤーは、ユーザー入力を処理し、ページ・ナビゲーションを決定します。

  • ビジネス・サービス・レイヤーは、データ・アクセスを処理し、ビジネス・ロジックをカプセル化します。

図6-1 Oracle ADFアーキテクチャの概要

Oracle ADFアーキテクチャの概要
「図6-1 Oracle ADFアーキテクチャの概要」の説明

6.1.1.1 Oracle ADFコンポーネント

フレームワークの中核モジュールは、JSR-227仕様を実装する宣言的なデータ・バインディング機能であるOracle ADF Modelです。この仕様は、宣言的なデータ・バインディング・メタデータへアクセスするためのAPIを提供します。Oracle ADF Modelレイヤーでは、統一されたアプローチを使用して、任意のユーザー・インタフェースとビジネス・サービスをコードを記述することなくバインドすることが可能です。

Fusion Webアプリケーション・テクノロジ・スタックを構成する他のモジュールは次のとおりです。

  • Oracle ADF Business Componentsは、ビジネス・サービスの構築を簡素化します。

  • Oracle ADF Facesは、JavaServer Faces（JSF）で構築されたWebアプリケーションに対し、AJAX対応のUIコンポーネントのリッチ・ライブラリを提供します。

  • Oracle ADF Controllerは、JSFをOracle ADF Modelに統合します。ADF Controllerは、追加機能を提供することにより標準のJSFコントローラを拡張します。この追加機能には、JSFページ間だけでなく他のアクティビティ（メソッドのコールや他のタスク・フローなど）間の制御も渡す再使用可能なタスク・フローなどがあります。

図6-2は、Fusion Webアプリケーション・アーキテクチャにおける各Oracle ADFモジュールの適合を示しています。

図6-2 シンプルなOracle ADFアーキテクチャ

シンプルなOracle ADFアーキテクチャ
「図6-2 シンプルなOracle ADFアーキテクチャ」の説明

6.1.1.1.1 ADF Business Components

ADF Business Componentsは、ビルトイン・アプリケーション・オブジェクトであり、高性能で機能の豊富なデータベース中心のサービスの提供と維持を迅速化します。サービス指向のJava EEアプリケーションを作成するとき、開発者はコア・ビジネス・ロジックを1つ以上のビジネス・サービスとして実装します。これらのバックエンド・サービスは、適切なビジネス・ルールを施行し、かつ必要に応じてビジネス・データの問合せ、挿入、更新および削除を行う手段をクライアントに提供します。ADF Business Componentsは、Java EEの設計パターンとベスト・プラクティスを即座に実装できるようにします。

Oracle ADF Business Componentsは、データベース中心のビジネス・サービスの作成を簡略化するために次の主要なコンポーネントを提供しています。

  • エンティティ・オブジェクト

    エンティティ・オブジェクトは、データベース表内の1行を表し、すべてのデータ操作言語（DML）操作を処理することでデータ変更を簡略化します。また、ビジネス・ロジックをカプセル化し、ビジネス・ルールが一貫して適用されることを保証します。開発者は、エンティティ・オブジェクトを他のエンティティ・オブジェクトと関連付け、基盤となるデータベース・スキーマの関係を反映することで、複数のアプリケーションで再使用できるビジネス・ドメイン・オブジェクトのレイヤーを作成します。

  • ビュー・オブジェクト

    ビュー・オブジェクトはSQL問合せを表し、その結果の操作を簡略化します。開発者は、SQL言語を使用し、ユーザー・インタフェースで表されるエンド・ユーザーのタスクが必要とする形に、データを結合、計画、フィルタ、ソートおよび集約します。これには、ビュー・オブジェクトを他のエンティティ・オブジェクトにリンクし、複雑度に関係なくマスター/ディテール階層を作成する機能が含まれます。エンド・ユーザーがユーザー・インタフェースでデータを変更すると、ビュー・オブジェクトはエンティティ・オブジェクトと連携し、変更内容が一貫して検証され、保存されます。

  • アプリケーション・モジュール

    アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション（サービス・メソッド）を定義します。

Oracle ADF Business Componentsの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

6.1.1.1.2 ADF Modelレイヤー

モデル・レイヤーでは、Oracle ADF Modelによって、データ・コントロールと呼ばれるJSR-227サービス抽象化が実装されます。データ・コントロールは標準のメタデータ・インタフェースを使用して、関係のあるプロパティ、メソッドおよびタイプに関する情報など、サービスの操作とデータ・コレクションを記述することで、ビジネス・サービスの実装テクノロジを抽象化します。Oracle JDeveloperでは、開発者はその情報をアイコンとして表示し、ページに簡単にドラッグ・アンド・ドロップできます。開発者がサービス表現をページにドラッグすると、Oracle JDeveloperによって、そのページからサービスへのバインディングが自動的に作成されます。実行時にADF Modelレイヤーによって、アプリケーションのデータ・コントロールおよびデータ・バインディングを記述した情報が該当するXMLファイルから読み取られ、ユーザー・インタフェースとアプリケーションのビジネス・サービス間の双方向接続が実装されます。

Oracle ADFは、最も一般的なビジネス・サービス・テクノロジに対し、すぐに実装可能なデータ・コントロールを提供します。ユーザー・インタフェースの構築にOracle JDeveloperとOracle ADFを併用すると、ドラッグ・アンド・ドロップを使用した宣言的なデータ・バインディングが可能になります。ADF Business Componentsアプリケーション・モジュールのサポートのほかに、ADF Modelは次のサービス・テクノロジに対するサポートも提供します。

  • Enterprise JavaBeans（EJB）のセッションBeanとJPAエンティティ

  • JavaBeans

  • Webサービス

  • XML

  • CSVファイル

Oracle ADF Modelの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

6.1.1.1.3 ADF Controller

Webアプリケーションのページ・フロー処理が主な課題となるコントローラ・レイヤーでは、ADF Controllerは、拡張されたナビゲーションおよび状態管理モデルをJSFに追加する形で提供しています。JDeveloperは、ページ、マネージドBean上のメソッド、宣言的なcase文、他のタスク・フローへのコールなど、様々なタイプのアクティビティの間でアプリケーション制御を管理できるタスク・フローの宣言的な作成をサポートします。

Oracle ADF Controllerの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

6.1.1.1.4 ADF Faces Rich Client

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ユーザー・インタフェース開発者ガイド』を参照してください。

6.1.1.2 Oracle ADFの単一ノード・アーキテクチャ

Oracle ADFランタイムは、Oracle JDeveloperインストーラとOracle Fusion Middleware Application Developerインストーラのいずれかを使用してOracle WebLogic Serverにインストールできます。Application Developerインストーラを使用した場合は、Fusion Middleware Controlをオプションでインストールし、ドメイン内の全管理対象サーバーにWebベースの管理サポートを提供することもできます。Oracle JDeveloperインストーラを使用した場合は、Fusion Middleware Controlはインストールされません。これらのオプションは両方とも、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のデプロイメントの章で説明されています。

Application Developerインストーラを使用してOracle ADFランタイムをインストールすると、Middlewareホームの下にOracle Application Developerホーム・ディレクトリ（デフォルトではOracle_APPDEV1）が作成されます。管理者は、ドメイン構成ウィザードを使用し、JRFドメイン・テンプレートに基づいてApplication Developerドメイン（base_domain）を作成すると、サーバーのトポロジを構成できるようになります。通常の設定では、ドメインには、WLS管理コンソールとFusion Middleware Controlを含む管理サーバーが含まれています。通常は、ユーザー向けのカスタムFusion Webアプリケーションのほかに、Oracle ADFランタイムのライブラリ（Javaの必須ファイルの一部）が管理対象サーバーにデプロイされます。カスタマイズ機能およびパーソナライズ機能を提供するために、オプションのMDSリポジトリをインストールすることもできます。これは個別に構成する必要があります。図6-3は、Oracle ADFの基本的な単一ノード・アーキテクチャを示しています。

図6-3 Oracle ADFの基本的な単一ノード・アーキテクチャ

図6-3の説明は次にあります。
「図6-3 Oracle ADFの基本的な単一ノード・アーキテクチャ」の説明

ドメインとサーバーの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

6.1.1.3 Oracle ADFの外部依存性

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管理者ガイド』を参照してください。

6.1.1.4 Oracle ADFのログ・ファイル

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管理者ガイド』を参照してください。

6.1.2 Oracle ADFの高可用性に関する考慮事項

Oracle ADFテクノロジ・スタック上に構築されるFusion Webアプリケーションは、Java EEアプリケーション（およびJ2EEアプリケーション）です。Fusion Webアプリケーションに対しても、高可用性環境にある他のJava EEアプリケーションと同じようなベスト・プラクティスを実践する必要があります。

6.1.2.1 Oracle ADFのスコープとセッションの状態

バインディング・コンテナやマネージド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のページ・ライフサイクルに関する章を参照してください。

6.1.2.2 Oracle ADFのフェイルオーバーおよび予想される動作

Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内でほかに利用可能なメンバーがリクエストを処理できます。

セッションのフェイルオーバー要件

Fusion Webアプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。

  • アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できる。

  • ステートフル・アプリケーションに対し、第6.1.3項「高可用性のためのOracle ADFの構成」の説明に従って、状態のレプリケーションが正しく構成されている。

  • Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されている。

  • ハードウェア・ロード・バランサを使用する場合には、ロード・バランサが次のようになっていること。

    • 利用可能なインスタンスすべてに対してトラフィックをルーティングしている

    • 利用できないインスタンスをマークするように、状態モニターで正しく構成されている

    • セッションの状態の永続性をサポートするように構成されている

アプリケーションのフェイルオーバーで予想される動作

環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気がつきません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。

  1. ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。

  2. ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。

  3. ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。

  4. ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。

  5. インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。

  6. インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。

6.1.2.3 Oracle ADFのアクティブ・データ・サービス

Fusionテクノロジ・スタックにはアクティブ・データ・サービス（ADS）が含まれています。このADSによって、ADF Modelレイヤーを使用してADF Facesコンポーネントをアクティブ・データ・ソースにバインドできます。JDeveloperでは、JSFページ内で個々のコンポーネントを構成し、アクティブ・データを表示します。アクティブ・データを使用するようにコンポーネントを構成すると、データ・ソースによって変更イベントが発生するたびにデータがクライアントにプッシュされます。データはサーバーからクライアントにプッシュされ、ブラウザで表示されます。

アクティブ・データを表示するように構成されているページに対してフェイルオーバーをサポートするには、ADF Business Componentsアプリケーション・モジュールのフェイルオーバーを有効にし、ADF ControllerがADFメモリー・スコープへの変更を追跡できるようにする必要があります。これらのADF設定を構成すると、フェイルオーバーの発生時にADFサーバーがフェイルオーバーを検出し、アクティブ・データを表示するように構成されているすべてのページに対し、ページをリフレッシュするように要求します。その後でADSが再起動し、データがクライアントにプッシュされます。

Fusion Webアプリケーションのフェイルオーバーを有効にする方法の詳細は、第6.1.3項「高可用性のためのOracle ADFの構成」を参照してください。

Oracle ADF Facesコンポーネントでのアクティブ・データ・サービスの使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のADSに関する章を参照してください。

6.1.2.4 Oracle RAC用ADFアプリケーション・モジュールの構成

冗長なデータベースやバックエンドとしてのOracle Real Application Clusters（Oracle RAC）など、可用性の高いデータベース・システムにアクセスするようにADFアプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、マルチ・データ・ソースを使用する必要があります。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースと非マルチ・データ・ソースでネーミング規則は同じになります。これによって、正しいデータ・ソースが実行時に使用されるようになります。高可用性アプリケーションに対するマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの構成」を参照してください。

6.1.3 高可用性のためのOracle ADFの構成

クラスタ環境内のWebアプリケーションに対して自動的なレプリケーションとフェイルオーバーをサポートするために、Oracle WebLogic Serverは、クラスタ間でHTTPセッションの状態をレプリケートするメカニズムをサポートしています。Fusion Webアプリケーションの状態をクラスタ内のどのサーバーからでもリストアできるようにOracle ADFを構成できます。

6.1.3.1 アプリケーション・モジュールの構成

アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション（サービス・メソッド）を定義します。アプリケーション・モジュールは、そのトランザクション状態を非アクティブ化する、またはスナップショットとしてデータベースに格納することをサポートしています。また、これらの保存済スナップショットのいずれかからトランザクション状態をアクティブ化する逆の操作もサポートしています。

アプリケーション・モジュール状態の管理の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のFusion Webアプリケーションの状態管理の概要に関する項を参照してください。

ADF Business Componentsのフェイルオーバーのサポートを有効にするには、jbo.dofailoverパラメータをtrueに設定し、アプリケーション・モジュールの状態が解放時に保存されるようにします。これによって、Oracle ADFは、前のチェックインで保存されたスナップショットからアプリケーション・モジュールの状態をリストアできるようになります。一方、フェイルオーバー機能がデフォルトにより無効のままになっている場合は、アプリケーションが後続のユーザー・セッションで再利用されたときと、アプリケーション・モジュール・プールが未使用のアプリケーション・モジュールを見つけられないときにのみ、アプリケーション・モジュールの状態が保存されます。

アプリケーション・モジュールの構成でこのパラメータを設定するには、「ビジネス・コンポーネント構成の編集」ダイアログの「プーリングおよびスケーラビリティ」タブを使用します。

高可用性のためのアプリケーション・モジュールを構成する手順は次のとおりです。

  1. JDeveloperを起動してアプリケーションを開きます。

  2. アプリケーション・ナビゲータで、データ・モデルを含むプロジェクトを展開し、アプリケーション・モジュールを探します。

  3. アプリケーション・モジュールを右クリックし、「構成」を選択します。

  4. 「編集」をクリックします。

  5. 「プーリングおよびスケーラビリティ」タブをクリックします。

  6. 「管理された解放時にトランザクションの状態をフェイルオーバー」チェック・ボックスを選択します。

  7. 「OK」をクリックして「ビジネス・コンポーネント構成の編集」ダイアログを閉じます。

  8. 「OK」をクリックして「構成の管理」ダイアログを閉じます。

Oracle ADFの状態管理機能とその使用方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーションの状態管理に関する章を参照してください。

6.1.3.2 weblogic.xmlの構成

HTTPセッションの状態のレプリケートをサポートできるようにするには、Oracle WLS weblogic.xmlファイルのpersistent-store-type要素に値を割り当てる必要があります。replicated_if_clusteredの値により、有効な永続ストアのタイプがレプリケートされ、このサーバーの属するサーバーのクラスタに対して設定された値に従って、クラスタ環境のセッションが格納されるようになります。

高可用性を実現するためにweblogic.xmlファイルを構成する手順は次のとおりです。

  1. JDeveloperを起動してアプリケーションを開きます。

  2. アプリケーション・ナビゲータで、Webアプリケーションを含むプロジェクトを展開し、WEB-INFフォルダを展開します。

  3. weblogic.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。

  4. ファイル内で、persistent-store-typeの定義をsession-descriptor要素に追加します。

    <weblogic-web-app>
    <session-descriptor>
    <persistent-store-type>
    replicated_if_clustered
    </persistent-store-type>
    </session-descriptor>
</weblogic-web-app>

6.1.3.3 adf-config.xmlの構成

クラスタ環境で実行するアプリケーションを設計している場合は、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ファイルを構成する手順は次のとおりです。

  1. JDeveloperを起動してアプリケーションを開きます。

  2. アプリケーション・ナビゲータで、「アプリケーション・リソース」を展開します。

  3. 「ディスクリプタ」を選択し、「ADF META-INF」ノードを選択します。

  4. adf-config.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。

  5. このファイルに次の行を追加します。

    <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開発者ガイド』の複雑なタスク・フローの作成に関する章を参照してください。

6.1.3.4 org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONの構成

高可用性環境で実行する場合、org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONパラメータをtrueに設定しないでください。このコンテキスト・パラメータをtrueに設定すると、フェイルオーバーの発生後にエラーを引き起こす可能性があります。

6.1.4 Oracle ADFの高可用性のトラブルシューティング

この項では、Oracle ADFで発生する可能性のある問題のトラブルシューティング手順について説明します。

6.1.4.1 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」を選択して監査をトリガーすることもできます。

6.1.4.2 Oracle ADFのデプロイメントに関する問題のトラブルシューティング

Fusion Webアプリケーションは、管理対象サーバーが最初に起動したときにデプロイされます。最初にOracle WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメントがすべて成功したことを確認します。

左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。

アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME/servers/server_name/logsディレクトリに格納されています。一般的な問題には、次のようなものがあります。

  • データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。

  • 適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。

6.1.4.3 Oracle ADFのレプリケーションおよびフェイルオーバーに関する問題のトラブルシューティング

フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります。

  • ウィンドウが閉じたか、または状態がリセットされた可能性がある。

  • 画面のリセットが必要になった可能性がある。

  • アプリケーションがログオン画面にリダイレクトしている可能性がある。

次の手順は、状態のレプリケーションに関する問題のトラブルシューティングおよび診断を行う際のガイダンスです。

  1. これがレプリケーションに関する既知の問題でないことを確認します。

    予想される動作については、第6.1.2.2項「Oracle ADFのフェイルオーバーおよび予想される動作」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。

  2. ロード・バランサの設定を確認します。

    レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverのハードウェア・ロード・バランサの構成の詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。

  3. クラスタのステータスを確認します。

    クラスタのコンテキスト内でレプリケーションが発生します。フェイルオーバーが成功するには、クラスタの正常なメンバーが、ほかに少なくとも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

  4. クラスタ通信を確認します。

    クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。

    • ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。

      個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。

    • マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTestを実行して、マルチキャストが正しく構成されていることを確認します。次に例を示します。

      $ java utils.MulticastTest -H

  5. 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で行うことができます。

  6. Oracle ADF Business Componentsの構成を確認します。

    Oracle ADFは、デフォルトではフェイルオーバーするように構成されていません。フェイルオーバーは、ADF Business Componentsの構成ファイル（bc4j.xcfg）に次の適切な設定が含まれている場合にのみサポートされます。

    <AppModuleConfig ...
 <AM-Pooling jbo.dofailover="true"/>
</AppModuleConfig>

    この設定は、第6.1.3.1項「アプリケーション・モジュールの構成」で説明されているように、JDeveloperの「ビジネス・コンポーネント構成の編集」ダイアログで行います。

  7. 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のソース・エディタで行います。

  8. デフォルトのログ出力メッセージを確認します。

    デフォルトでは、ADFのログには上位レベルのメッセージ（INFOレベル）が表示されます。デフォルトのログ出力では、さらに詳細なログ・メッセージを有効にする必要なしに、シリアライズやレプリケーションに関する問題を報告することがよくあります。ログの詳細は、第6.1.1.4項「Oracle ADFのログ・ファイル」を参照してください。

  9. 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のログ・ファイル」を参照してください。

  10. デバッグを有効にします。

    サーバー・ログを調べて、管理対象サーバーの起動時に異常なメッセージがないか確認します。この確認は、管理対象サーバーがクラスタの他のメンバーを見つけられない場合に、特に必要です。サーバー・ログは、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

  11. コンポーネントの状態のシリアライズ・チェックを有効にします。

    サーバーのチェックを有効にして、セッション属性でシリアライズ不能な状態コンテンツが検出されないようにします。このチェックは、デフォルトでは、実行時のオーバーヘッドを軽減するために無効になっています。シリアライズ・チェックは、Javaサーバーのシステム・プロパティorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATIONによってサポートされます。

    高可用性をテストするには、まず次のシステム・プロパティを使用してアプリケーション・サーバーを起動し、セッションおよびJSFの状態がシリアライズ可能であることを確認します。

    -Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree

    JSFの状態がシリアライズ不能であることが検出された場合は、次のシステム・プロパティを使用してアプリケーション・サーバーを再起動し、コンポーネントとプロパティのフラグを有効にしてからテストを再実行します。

    -Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all

    これらはJavaシステム・プロパティであるため、アプリケーション・サーバーの起動時に指定する必要があります。

6.2 Oracle ADFの高可用性デプロイメントの構成

この項では、サンプルとして示したOracle ADFの高可用性デプロイメントを構成する方法について説明します。


注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。

6.2.1 ディレクトリおよびディレクトリ環境変数の用語

次のリストは、この項で使用するディレクトリと変数について説明しています。

  • 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

6.2.2 RCUを使用したデータベースへのFusion Middlewareスキーマのロード

この手順は、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

6.2.2.1 RCUの実行

RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。

  1. 次のコマンドを使用してRCUを起動します。

    RCU_HOME/bin/rcu &

  2. 「ようこそ」画面で「次へ」をクリックします。

  3. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。

  4. 「データベース接続の詳細」画面で、データベースの接続情報を入力します。

    • データベース・タイプ: Oracle Databaseを選択します。

    • ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します: ADFDBHOST1VIRTUAL

    • ポート: データベースのポート番号: 1521

    • サービス名: データベースのサービス名を入力します: adfha.mycompany.com

    • ユーザー名: SYS

    • パスワード: SYSユーザーのパスワードを入力します。

    • ロール: SYSDBA

    「次へ」をクリックします。

  5. 次のメッセージを受信した場合は、「無視」または「停止」をクリックします。

    接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。

  6. 「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、ADFHAのように、データベース・スキーマに使用する接頭辞を入力します。

    後の手順で利用できるように、このスキーマ名を書き留めておきます。

    次のスキーマを選択します。

    • AS共通スキーマ

    • Metadata Services

    「次へ」をクリックします。

  7. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加（補助）のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。

  8. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

  9. 「サマリー」画面で「作成」をクリックします。

  10. 「完了サマリー」画面で「閉じる」をクリックします。

RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

6.2.3 WEBHOST1へのOracle HTTP Serverのインストール

WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。

  1. サーバーが次の要件を満たしていることを確認します。

    • システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』で指定されている要件を満たしています。

    • この例ではポート7777を使用します。ポート7777を選択する場合には、ノード上のいずれのサービスでもこのポートが使用されていないことを確認します。このことを確認するには、次のコマンドを実行します。

      UNIX:
netstat -an | grep LISTEN | grep ":7777"

Windows:
netstat -an | findstr "LISTEN" | findstr ":7777"

  2. ポート7777が使用中の場合には、別のポートを選択するか、またはこのポートを使用可能にします。

  3. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

    /etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

  4. Oracle Fusion Middleware 11g Webtier Utilities CDインストールのOracle Universal Installerを、次のように開始します。

    UNIXでは、コマンド./runInstallerを実行します。

    Windowsでは、setup.exeをダブルクリックします。

  5. 「インベントリ・ディレクトリの指定」画面で、インベントリおよびユーザー・グループの場所を入力して「OK」をクリックします。

  6. ダイアログに従ってrootの特権アクションを実行し、「OK」をクリックします。

  7. 「ようこそ」画面で「次へ」をクリックします。

  8. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

  9. 「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。

  10. 「インストール場所の指定」画面で、場所を次のように設定します。

    /u01/app/oracle/product/11.1.1/ohs_1

    「次へ」をクリックします。

  11. 「コンポーネントの構成」画面で、次の操作を行います。

    • 「Oracle HTTP Server」を選択します。

    • 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

    「次へ」をクリックします。

  12. コンポーネント詳細の指定画面で、次の値を入力します。

    • インスタンス・ホームの場所:

      /u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1

    • インスタンス名: ohs_instance1

    • OHSコンポーネント名: ohs1

    「次へ」をクリックします。

  13. 「Web Tierポートの詳細の指定」画面で、次の操作を行います。

    • 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

    • Oracle HTTP Serverのポート番号を入力します。たとえば、7777と入力します。

    「次へ」をクリックします。


    注意:

    ポートの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suite and Oracle Business Process Management Suiteインストレーション・ガイド』を参照してください。

  14. 「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。

  15. 「インストールの進行状況」画面で、次の操作を行います。

    UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

    「次へ」をクリックします。

  16. 「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。

  17. 「構成が完了しました」画面で、「終了」をクリックして終了します。

6.2.3.1 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、Webブラウザで次のURLを入力し、サーバーのルートURLコンテキストにアクセスします。

WebHost1:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザに「Hello World」ページが表示されます。

6.2.4 Oracle Fusion Middlewareホームのインストール

次の各項に記載されている情報を使用して、Oracle Fusion Middlewareコンポーネントをインストールします。

6.2.4.1 Oracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンについては、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。

  1. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

    /etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

  2. Oracle WebLogic Serverインストーラを起動します。

  3. 「ようこそ」画面で「次へ」をクリックします。

  4. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

    • 「新しいミドルウェア・ホームを作成する」を選択します。

    • 「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。

      ORACLE_BASE/product/fmw

    「次へ」をクリックします。

  5. 「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。

  6. 「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。

  7. 「JDKの選択」画面で、「Oracle JRockit 1.6.0_14 SDK」のみを選択して「次へ」をクリックします。

  8. 「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。

    ORACLE_BASE/product/fmw/wlserver_10.3

    「次へ」をクリックします。

  9. 「インストールの概要」画面で「次へ」をクリックします。

  10. 「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。

6.2.4.2 Oracle ADFアプリケーション用Oracle Fusion Middlewareのインストール

Oracle Fusion MiddlewareのOracle ADFをインストールするには、Application Developerインストーラを使用し、アプリケーション層にあるすべてのノードで次の操作を行います。

  1. 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

  2. 「ようこそ」画面で「次へ」をクリックします。

  3. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

  4. 「インストール場所の指定」画面で、次の操作を行います。

    • 「ミドルウェア・ホーム」には、ORACLE_BASE/product/fmwと入力します。

    • 「Oracleホーム・ディレクトリ」には、たとえばadfのように、使用するディレクトリを入力します。

    「次へ」をクリックします。

  5. 「インストール・サマリー」画面で「インストール」をクリックします。

  6. 「インストール 完了」画面で「終了」をクリックします。


注意:

第6.2.6項「WebLogic ServerのADFドメインを作成するためのAPPHOST1での構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareの最新のパッチ・セットなどの既知のパッチをMiddlewareホームに適用して、Oracle Fusion Middlewareを最新バージョンにしておいてください。

最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

6.2.5 管理サーバーの高可用性

Oracle WebLogic Server管理サーバーの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。

6.2.6 WebLogic ServerのADFドメインを作成するためのAPPHOST1での構成ウィザードの実行

MiddlewareホームのadfディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracleコンポーネントが格納されるドメインを作成します。

  1. 次のコマンドを使用して、MW_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。

    APPHOST1> ./config.sh

  2. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

  3. 「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。

    • Oracle Enterprise Manager - 11.1.1.0

    • Oracle JRF - 11.1.1.0

    「次へ」をクリックします。

  4. 「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。

  5. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。

  6. 「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。

    • WebLogicドメインの起動モード: 「本番モード」を選択

    • JDKの選択: 「Oracle JRockit 1.6.0_14 SDK」を選択

    「次へ」をクリックします。

  7. 「オプションの構成を選択」画面で、次を選択します。

    • 管理サーバー

    • 管理対象サーバー、クラスタ、およびマシン

    「次へ」をクリックします。

  8. 「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。

  9. 「管理サーバーの構成」画面で、次の値を入力します。

    • 名前: AdminServer

    • リスニング・アドレス: APPHOST1

    • リスニング・ポート: 7001

    • SSLリスニング・ポート: NA

    • SSL有効: 選択を解除

    「次へ」をクリックします。

  10. 「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。

    管理対象サーバー名 リスニング・アドレス リスニング・ポート SSLリスニング・ポート SSL有効
    WLS_ADF1 APPHOST1のホスト名 8889 NA 選択を解除
    WLS_ADF2 APPHOST2のホスト名 8889 NA 選択を解除

    「次へ」をクリックします。

  11. 「クラスタの構成」画面で、次のクラスタを追加します。

    • 名前: ADF_CLUSTER

    • クラスタ・メッセージング・モード: unicast

    • クラスタ・アドレス有効化: 空白のまま

    「次へ」をクリックします。

  12. 「サーバーのクラスタへの割当」画面で、クラスタに次のサーバーを割り当てます。

    • ADF_CLUSTER:

      • WLS_ADF1

      • WLS_ADF2

    「次へ」をクリックします。

  13. 「マシンの構成」画面で、次の操作を行います。

    • デフォルトで表示されるLocalMachineを削除します。

    • 「UNIXマシン」タブをクリックし、次のマシンを追加します。

      名前 ノード・マネージャのリスニング・アドレス
      APPHOST1 APPHOST1のホスト名
      APPHOST2 APPHOST2のホスト名

    「次へ」をクリックします。

  14. 「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

    • APPHOST1: AdminServer、WLS_ADF1

    • APPHOST2: WLS_ADF2

  15. 「構成のサマリ」画面で「作成」をクリックします。

  16. ドメインの作成中画面で「完了」をクリックします。

6.2.6.1 APPHOST1での管理サーバーおよび管理対象サーバー用boot.propertiesの作成

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーおよび管理対象サーバーに対してboot.propertiesファイルを作成します。

管理サーバーに対しては、次の手順を実行します。

  1. 次のディレクトリを作成します。

    APPHOST1> mkdir -p MW_HOME/wls/user_projects/domains/adfdomain/servers/AdminServer/security

  2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

    username=adminUser
password=adminUserPassword

    次に例を示します。

    username=weblogic
password=weblogic

    注意:

    管理サーバーまたは管理対象サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

    セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

WLS_ADF管理対象サーバーに対しては、次の手順を実行します。

  1. 管理サーバーに対して作成したファイルをすべてのサーバーにコピーします。

    APPHOST1> mkdir -p servers/WLS_ADF1
APPHOST1> mkdir -p servers/WLS_ADF1/security

  2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

    username=adminUser
password=adminUserPassword

    次に例を示します。

    username=weblogic
password=weblogic

6.2.7 APPHOST1でのシステムの起動

この項では、APPHOST1でシステムを起動する手順について説明します。

6.2.7.1 APPHOST1での管理サーバーの起動

APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/bin
APPHOST1> ./startWebLogic.sh

6.2.7.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

  1. Webブラウザでhttp://VIP1:7001/consoleにアクセスします。

  2. 管理者としてログインします。

  3. 管理対象サーバーとしてWLS_ADF1およびWLS_ADF2が表示されていることを確認します。

  4. ADF_Clusterクラスタが表示されていることを確認します。

  5. Enterprise Manager（http://VIP1:7001/em）にアクセスできることを確認します。

6.2.7.3 APPHOST1およびAPPHOST2の管理サーバーおよび管理対象サーバーに対するホスト名の検証の無効化

この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。

ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。

APPHOST1でホスト名の検証を無効化する手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソールで、管理サーバー→「SSL」→「詳細」を選択します。

  2. 「ロックして編集」をクリックします。

  3. プロンプトが表示されたら、変更内容を保存してアクティブ化します。

  4. 「ホスト名の検証」を「なし」に設定します。

  5. 「WLS_ADF1」→「SSL」→「詳細」を選択します。

  6. 「ホスト名の検証」を「なし」に設定します。

  7. 管理サーバーとWLS_ADF1管理対象サーバーを再起動します。

APPHOST2でホスト名の検証を無効化する手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソールで、「WLS_ADF2」→「SSL」→「詳細」を選択します。

  2. 「ホスト名の検証」を「なし」に設定します。

  3. 管理サーバーとWLS_ADF2管理対象サーバーを再起動します。

6.2.7.4 APPHOST1でのノード・マネージャの起動

APPHOST1でノード・マネージャを起動するには、次の手順を実行します。

  1. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

    OAHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./setNMProps.sh

    注意:

    クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

  2. ノード・マネージャを起動します。

    APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

6.2.8 APPHOST2へのOracle WebLogic ServerとOracle ADFのインストール

APPHOST2に対し、WebLogic ServerとOracle ADFのインストール手順を繰り返します。第6.2.3項「WEBHOST1へのOracle HTTP Serverのインストール」の手順から始めてください。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。

6.2.9 pack/unpackユーティリティを使用したAPPHOST2へのドメイン構成の伝播

次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST2に伝播します。

  1. 次の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

  2. 次のscpコマンドをAPPHOST1で実行し、前の手順で作成したテンプレート・ファイルをAPPHOST2にコピーします。

    APPHOST1> scp adfdomaintemplate.jar
 user@node2:WL_HOME/common/bin

  3. unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。

    APPHOST2> cd WL_HOME/common/bin
APPHOST2> ./unpack.sh
 -domain=ORACLE_BASE/product/fmw/user_projects/domains/adfdomain/
 -template=adfdomaintemplate.jar

6.2.9.1 APPHOST2での管理サーバーおよび管理対象サーバー用boot.propertiesの作成

次の手順に従い、APPHOST2上の管理サーバーと管理対象サーバーに対してboot.propertiesファイルを作成します。

  1. 次のディレクトリを作成します。

    APPHOST1> mkdir -p MW_HOME/wls/user_projects/domains/adfdomain/servers/WLS_ADF2
APPHOST2> mkdir -p MW_HOME/wls/user_projects/domains/adfdomain/servers/WLS_ADF2/security

  2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

    username=adminUser
password=adminUserPassword

    次に例を示します。

    username=weblogic
password=weblogic

    注意:

    管理サーバーまたは管理対象サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

    セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

6.2.9.2 APPHOST2でのノード・マネージャの起動

APPHOST2でノード・マネージャを起動するには、第6.2.7.4項「APPHOST1でのノード・マネージャの起動」の手順をAPPHOST2で繰り返します。

6.2.9.3 ADFアプリケーションのレプリケーションの構成

この項の手順を使用して、アプリケーションのレプリケーションを構成します。

クラスタリング要件

アプリケーションをOracle WebLogicクラスタにデプロイする必要があります。これによって、アプリケーションの複数インスタンスに、レプリケーション・チャネルが自動的に確立されます。


注意:

ユニキャスト・クラスタでは、デフォルトのレプリケーション・チャネルは、各管理対象サーバーのリスニング・アドレスを使用して構成されています。そのため、リスニング・アドレスは、Anyでリスニングするように構成するのではなく、特定のIPアドレスまたはホスト名となるように構成する必要があります。

Oracle ADFのレプリケーション

Oracle ADFが適切に構成されていることが重要です。ステートフル・アプリケーションの場合には、アプリケーション・リソースの1つであるadf-config.xmlファイルに、次のタグが存在している必要があります。

<adfc:adf-controller-config><adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support></adfc:adf-controller-config>

アプリケーションでは、レプリケーションも有効化されている必要があります。Oracle WebLogic Serverでは、レプリケーションのために様々な種類の永続ストアを使用できます。永続ストアの詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。

ADFアプリケーションのレプリケーションをデフォルトで有効にするには、weblogic.xmlファイルで次の設定を行います。

<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

replicated_if_clustered設定は、スタンドアロン・アプリケーション環境のレプリケーションを無効にし、クラスタ環境内のメモリー内レプリケーションを使用します。

メモリー内レプリケーションに任意のカスタム・アプリケーションが構成されていることを確認します。

6.2.9.4 ADFアプリケーションのデプロイ

クラスタを設定すると、ADFアプリケーションをデプロイできるようになります。次の点に注意してください。

  • 管理サーバー・コンソールを使用して、ADFアプリケーションをEARファイルにデプロイします。

  • デプロイメントがクラスタに対して行われるようにします。

  • アプリケーションがMDSを使用する場合は、『Oracle Fusion Middleware管理者ガイド』のデータベース・ベースのMDSリポジトリの登録に関する項の指示に従って、MDSをドメインに登録します。

6.2.9.5 Oracle HTTP Serverの管理サーバーおよびOracle WebCenter管理対象サーバーの構成

Oracle WebCenter管理対象サーバーを含む管理サーバーへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定します。次の手順を実行します。

  1. 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>

  2. WEBHOST1上のOracle HTTP Serverを再起動します。

    WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1

6.2.9.6 Oracle HTTP Serverを使用したアクセスの検証

URLを検証し、HTTP ServerからOracle WebCenterクラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。次の手順を実行します。

  1. WebLogic Server管理コンソールから、WLS_Spaces1、WLS_Spaces2、WLS_Services1、WLS_Services2、WLS_Portlet1およびWLS_Portlet2を次のように起動します。

    1. 次のURLの管理コンソールにアクセスします。

      http://APPHOST1/console

    2. 管理対象サーバーのいずれか（例: WLS_Spaces1）をクリックします。

    3. 「制御」タブを選択します。

    4. 「起動」を選択して管理対象サーバーを起動します。

    5. 管理対象サーバーごとに前の手順を繰り返します。

    6. 次のURLを使用して、管理対象サーバーへの直接アクセスを検証します。

      apphost1:8888/applicationMountpoint

apphost2:8888/applicationMountpoint

apphost1:8889/applicationMountpoint

apphost2:8889/applicationMountpoint

  2. WLS_ADF2の稼働中に、Oracle WebLogic Server管理コンソールからWLS_ADF1を停止します。

  3. 次のURLにアクセスして、適切な機能を検証します。

    WebHost1:7777/applicationMountpoint

  4. WebLogic Server管理コンソールからWLS_ADF1を起動します。

  5. WLS_ADF2を停止します。

  6. 次のURLにアクセスして、適切な機能を検証します。

    WebHost2:7777/applicationMountpoint

6.3 Oracle WebCenterと高可用性の概要

この項では、Oracle WebCenterの高可用性クラスタを設計するために必要な課題および考慮事項を紹介します。

6.3.1 Oracle WebCenterの理解

Oracle WebCenterは、Java Server Faces（JSF）の標準ベースの宣言的な開発と、ポータルの柔軟性と能力、および一連の統合型Web 2.0サービスを組み合せたものです。

6.3.1.1 Oracle WebCenterコンポーネント

図6-4は、Oracle WebCenterアプリケーションとそれに関連するコンポーネント、ポートレットおよびサービスを示しています。

図6-4 Oracle WebCenterアプリケーションのコンポーネント

Oracle WebCenterアプリケーションのコンポーネント
「図6-4 Oracle WebCenterアプリケーションのコンポーネント」の説明

Oracle WebCenterのコンポーネントは次のとおりです。

  • Oracle WebCenter Spacesは、一連の堅牢なサービスとアプリケーションにより、ソーシャル・ネットワーキング、通信、コラボレーションおよび個人の生産性に対して、単一の統合されたWebベース環境を提供します。

    WebCenter Spacesは、JSF、Oracle ADF、WebCenter Framework、WebCenterサービスおよびOracle Composerを使用して構築されています。Oracle WebCenter Spacesは次の機能を提供します。

    • ビジネス・ユーザーをターゲットとし、コミュニティに焦点を当てたブラウザベースのアプリケーション。

    • 各ユーザーの個人用スペース。これは、個人用コンテンツの格納、メモの保存、ビジネス・プロセスの割当ての表示およびビジネス・プロセスの割当てへの応答、オンラインの友人のリストの保持、メールの送受信などを行う個人用作業領域となります。個人用スペースの目的は、個人の生産性を向上させることです。

    • 機能の豊富なチーム・コラボレーション・プラットフォームであるグループ・スペース。

    • スレッド・ディスカッション、ブログ、Wiki、ワークリスト、お知らせ、RSS、最近のアクティビティ、検索など。

  • Oracle WebCenter Portlets Frameworkは、標準ベースのポートレット（JSR 168、WSRP 1.0および2.0）と従来のOracle PDK-Javaベースのポートレット両方のデプロイメントと実行をサポートしています。Oracle WebCenterには、OmniPortlet、Webクリッピング、リッチ・テキスト・ポートレット、WSRPツールなど、すぐに使用可能なプロデューサがいくつか用意されています。

  • Oracle WebCenter Frameworkの機能は次のとおりです。

    • ランタイム・カスタマイズ（再デプロイを必要としないアプリケーションの即時変更を可能にします）

    • JSR-168標準ベースのWSRPポートレットおよびPDK-Javaポートレットのサポート

    • Oracle Content Server、Oracle Portal、ファイル・システムなどのコンテンツ・リポジトリへの、JCR（JSR170）を使用したコンテンツの統合

    • JSFページおよびOracle ADFタスク・フローを標準ベースのポートレットとして表示できるようにするJSFポートレット・ブリッジ

  • Oracle WebCenterディスカッション・サーバーは、ディスカッション・フォーラムやお知らせをアプリケーションに統合する機能を提供します。

  • Oracle WebCenter Wiki and Blogサーバーは、Wikiおよびブログをアプリケーションに統合する機能を提供します。また、アプリケーション・ユーザーが独自のWikiやブログを作成するための機能もサポートしています。

Oracle WebCenter SpacesおよびカスタムのWebCenterアプリケーションは、次のWebCenterサービスと統合することもできます。

  • お知らせ: 重要なアクティビティやイベントに関するお知らせを、特定のグループ・スペースのメンバーに投稿する手段を提供します。

  • ディスカッション: スレッド・ディスカッションの作成、質問の投稿と回答、およびグループ・スペースのコンテキスト内のすべての回答の検索を行う手段を提供します。重要なアクティビティやイベントに関して、グループが効果的に通信するためのメカニズムも提供します。

  • ドキュメント: コンテンツのアップロード、ファイルおよびフォルダの作成と管理、ファイルのチェックアウト、バージョニングなど、コンテンツ管理機能および記憶域機能を提供します。

  • イベント: WebCenter Spacesで使用可能なイベント・サービスは、広範なユーザーのグループに関連するイベントのスケジュールを作成および保持する手段を提供します。イベントは、グループ・スペースのすべてのメンバーに公開されます。

  • インスタント・メッセージおよびプレゼンス（IMP）: 他の認証済ユーザーのステータス（オンライン、オフライン、ビジー、アイドルのいずれか）を観察し、これらのユーザーにすぐ連絡する手段を提供します。

  • リンク: 関連情報の表示、アクセスおよび関連付けを行う機能を提供します。たとえば、ディスカッション・スレッドからソリューション・ドキュメントにリンクできます。

  • リスト: Oracle WebCenter Spacesで使用可能なリスト・サービスは、リストや表を作成、公開および管理する機能を提供します。ユーザーはビルトイン構造からリストを作成するか、または独自のカスタム・リストを作成できます。

  • メール: IMAPメール・サーバーやSMTPメール・サーバーと簡単に統合することで、メッセージの表示、読取り、作成および削除、ファイル添付メッセージの作成、既存のメッセージへの応答または転送などの単純なメール機能を、ユーザーが実行できるようにします。

  • メモ: Oracle WebCenter Spacesで使用可能なメモ・サービスは、個人的に関係のある情報の一部を書き留めて保持する機能を提供します。

  • ピープル・コネクション: 掲示板、フィードバック、プロファイル、アクティビティ・ストリームなどのソーシャル・ネットワーキング・アプリケーションを通じて、他のユーザーへの接続、他のユーザーとの対話、および他のユーザーの追跡を行う手段を提供します。

  • 最近のアクティビティ: ページ、ドキュメント、ディスカッション、お知らせ、リストおよびイベントに対する最近の変更のサマリー・ビューを提供します。

  • RSS: ニュース・リーダーという1つの場所から多くの異なるWebサイトのコンテンツにアクセスする機能を提供します。

  • 検索: タグ、サービス、アプリケーションまたはサイト全体を検索する手段を提供します。これには、WebCenter検索用にOracle Secure Enterprise Searchを統合することが含まれています。

  • タグ: 任意のページまたはドキュメントに、個人的に関係のある1つ以上のキーワードを割り当てる手段を提供します。

  • Wikiとブログ: アプリケーション内のブログおよびWikiページを簡単に統合できるようにします。グループ・スペース内のWikiページを提供します。個人用スペース内とグループ・スペース内の両方のブログを提供します。

  • ワークリスト: エンタープライズ内で作成されている様々なワークフローから通知を表示する手段を提供します。

これらのWebCenterサービスの構成の詳細は、Oracle Fusion Middleware Oracle WebCenter管理者ガイドを参照してください。

6.3.1.2 Oracle WebCenterの単一ノード・アーキテクチャ

Oracle WebCenterをインストールすると、Middlewareホーム・ディレクトリの下にWebCenterディレクトリが作成されます。このインストールによって、WebCenterドメイン（wc_domain）が作成されます。このドメインには、管理サーバー、および3つのWebLogic管理対象サーバーである、WLS_Spaces1（Oracle WebCenter Spacesをホスト）、WLS_Portlets（Oracle WebCenter Portletsをホスト）およびWLS_Services1（Oracle WebCenterディスカッション・サーバー、Oracle WebCenter Wiki and Blogサーバー、および統合する追加のWebCenterサービスをホスト）が格納されます。

オプションの4番目の管理対象サーバー（アプリケーション・サーバー）は、WebCenterのカスタム・アプリケーションを実行するために使用できます。通常は、Webcenterカスタム・アプリケーションにカスタム管理対象サーバーが1つずつ存在します。追加の管理対象サーバーを作成すると、適切なライブラリがプロビジョニングされ、Oracle WebCenter Spacesと同じ外部リソースを利用できるようになります。管理対象サーバーの詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middlewareの概要の理解に関する項を参照してください。図6-5は、Oracle WebCenterの基本的な単一ノード・アーキテクチャを示しています。

図6-5 Oracle WebCenterの基本的な単一ノード・アーキテクチャ

Oracle WebCenterの基本的な単一ノード・アーキテクチャ
「図6-5 Oracle WebCenterの基本的な単一ノード・アーキテクチャ」の説明

6.3.1.3 Oracle WebCenterの状態と構成の永続性

Oracle WebCenter SpacesはJava EEアプリケーションとして実行され、アプリケーションの状態と構成はMDSリポジトリに永続的に残ります。アプリケーション内のユーザー・セッション情報は、ローカルのメモリー内に保持されます。クラスタ環境では、この状態はクラスタの他のメンバーにレプリケートされます。

ポートレット環境またはサービス環境内のカスタマイズは、そのサービスによって永続的に残ります。Oracleポートレットおよびユーザーが構築するカスタム・ポートレット、ディスカッション・サーバーおよびWikiサーバーをすぐに利用できます。これらにはいずれも、独自のデータベース永続性メカニズムが備わっています。

6.3.1.4 Oracle WebCenterの外部依存性

表6-1は、WebCenterのコンポーネントおよびサービスそれぞれのアクセス・タイプを示しています。「構成」列には、接続を構成または初期化するためにOracle WebCenterに提供されている情報のタイプが一覧表示されています。「アクセス」列には、サービスのランタイム・アクセスで使用するプロトコルが一覧表示されています。

ディスカッション・サーバーとWiki/ブログ・サーバーも、Oracle WebCenterに対するサービス・プロバイダです。Oracleポートレットも、サービスとしてポートレット・プロデューサを公開します。

これらのサービスが使用できなくてもOracle WebCenter Spacesアプリケーションが起動できなくなることはありませんが、実行中にアプリケーション・エラーが発生する場合があります。例外は、MDSリポジトリです。WebCenter Spacesは、MDSリポジトリがないと動作しません。WebCenterデータベースがMDSリポジトリとは異なる物理データベースである場合は、WebCenterデータベースがなくてもWebCenter Spacesは部分的に動作します。

表6-1 Oracle WebCenterのアクセス・タイプ

外部サーバー/サービス 構成 アクセス

ディスカッション・サーバー

ディスカッション・サーバー管理へのHTTPアクセス

SOAP/HTTP

Oracle Content Server（ドキュメント）

管理サーバーへのソケット接続。HTTPアクセスが必要になるのは、WebCenterの外にあるコンテンツ・サーバーにアクセスする必要がある場合のみです。

ソケットを使用したJCR 1.0、またはHTTP

インスタント・メッセージおよびプレゼンス・サーバー

インスタント・メッセージおよびプレゼンス・サーバー管理へのHTTPアクセス

SOAP/HTTP

メール・サーバー

IMAP/SMTPサーバー

IMAP/SMTP

個人イベント・サーバー

カレンダ・サービスへのHTTPアクセス

SOAP/HTTP

ポートレット

プロバイダWSDLのHTTP場所

SOAP/HTTP

検索サーバー

検索サーバーへのHTTPアクセス

HTTP

Wiki and Blogサーバー

Wikiサーバー管理へのHTTPアクセス

SOAP/HTTP

ワークリスト

BPELサーバーへのHTTPアクセス

SOAP/HTTP

MDSリポジトリとスキーマ

JDBC

JDBC

各外部サービスの高可用性は個別に構成します。Oracle WebCenterのフレームワークは、外部サービスに対して単一のアクセス・ポイントを提供します。

Oracle RACおよびMDSリポジトリでのマルチ・データソースの構成の詳細は、第4.1.2項「Oracle RACでのマルチ・データソースの使用」を参照してください。

6.3.1.5 Oracle WebCenter構成の考慮事項

WebCenterアプリケーションの主要な構成ファイルは、表6-2に一覧表示および説明されています。これらのファイルは両方とも、WebCenterアプリケーション・デプロイメントの.EARファイルに含まれています。

表6-2 Oracle WebCenterの構成ファイル

アーティファクト 用途

adf-config.xml

WebCenterアプリケーションがどのディスカッション・サーバーまたはメール・サーバーを現在使用しているかなど、Application Development Framework（ADF）およびWebCenterアプリケーションの設定に関する基本構成を格納します。

connections.xml

外部サービスへの接続に関する基本構成を格納します。

WebCenterアプリケーションとポートレット・プロデューサは両方とも、Oracle Metadata Services（MDS）リポジトリを使用してその構成データを格納し、MDSリポジトリにはOracle WebLogicフレームワーク内のJDBCデータソースとしてアクセスします。

MDSリポジトリには、WebCenterアプリケーションおよびポートレット・プロデューサのデプロイメント後の構成の変更が、カスタマイズとして格納されます。MDSは、元のデプロイ済バージョンのadf-config.xmlとconnection.xmlをベース・ドキュメントとして使用し、その後のカスタマイズはすべて、単一のカスタマイズ・レイヤーを使用してMDSに個別に格納します。

WebCenterアプリケーションが起動すると、MDSに格納されているカスタマイズが適切なベース・ドキュメントに適用され、WebCenterアプリケーションは、マージ済ドキュメント（カスタマイズが適用されたベース・ドキュメント）を構成プロパティの最終セットとして使用します。

サーバー・クラスタにデプロイされているWebCenterアプリケーションの場合、クラスタの全メンバーは、MDSリポジトリ内の同じ場所から読取りを行います。

通常は、adf-config.xmlやconnection.xmlなどのファイルに対するベース・ドキュメント（またはMDSカスタマイズ・データ）の内容を管理者が調べたり、手動で変更する必要はありません。デプロイメント後の構成を行うための管理ツールがいくつか用意されているためです。詳細は、Oracle Fusion Middleware Oracle WebCenter管理者ガイドのOracle WebCenter管理ツールに関する項を参照してください。


注意:

特別な指示がないかぎり、adf-config.xmlまたはconnection.xmlを手動で編集することはお薦めしません。編集すると、不適切な構成になる場合があります。

WebCenterアプリケーションは、デプロイメント後の構成情報をMDSに格納しますが、ポートレット・プロデューサ、Oracle WebCenterディスカッション・サーバーおよびOracle WebCenter Wiki and Blogサーバーの構成情報は、ファイル・システムに格納されます（表6-3を参照）。

表6-3 Oracle WebCenterの構成情報の格納場所

アプリケーション 構成情報の格納場所がMDS 構成情報の格納場所がファイル・システム 構成情報の格納場所がデータベース

WebCenter Spaces

はい

いいえ

いいえ

カスタムWebCenterアプリケーション

はい

いいえ

いいえ

ポートレット・プロデューサ

いいえ

はい

いいえ

ディスカッション・サーバー

いいえ

はい

はい

Wiki and Blogサーバー

いいえ

はい

いいえ

Oracle WebCenterディスカッション・サーバーでは、構成情報はそのデータベースに格納されます。また、起動構成情報はDOMAIN_HOME/config/fmwconfig/servers/SERVER_NAME/owc_discussions_11.1.1.2.0に格納されます。このディレクトリには、jive_startup.xmlファイル、jive.licenseファイル、およびディスカッション・サーバー・インスタンスのログ・ファイルを含む\logsディレクトリが格納されています。

Oracle WebCenter Wiki and Blogサーバーは、構成情報をサーバーのデプロイ・ディレクトリに格納します。たとえば、$DOMAIN_HOME/servers/SERVER_NAMEなどです。その構成ファイルであるapplication_config.scriptは、$APPLICATIONS_DIRECTORY/WEB-INF/classesに格納されています。たとえば、DOMAIN_HOME/servers/WLS_Services/stage/owc_wiki/11.1.1.2.0/owc_wiki/WEB-INF/classesなどです。

両方のサーバーで、Wiki管理→設定の非クラスタ・モード設定をfalse（キャッシュ・データの使用）に設定します。

6.3.1.6 Oracle WebCenterのログ・ファイルの場所

WebCenterアプリケーション、ポートレット・プロデューサ、ディスカッション・サーバー、Wiki and Blogサーバーなどで実行された操作は、アプリケーションが稼働している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にアクセスして、「診断-ログ・ファイル」をクリックします。

また、管理対象サーバーのログ・ディレクトリに診断ログが作成されます。このログの粒度とロギング・プロパティは、DOMAIN_HOME/config/fmwconfig/servers/SERVER_NAME/logging.xmlファイルで変更できます。

6.3.2 WebCenterの高可用性アーキテクチャとフェイルオーバーに関する考慮事項

Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内の別のメンバーがリクエストを処理できます。

Oracle WebCenterデプロイメント内の管理対象サーバーはそれぞれ、クラスタとしてデプロイでき、複数のクラスタ・メンバーは、同じノードまたは異なるノードに配置できます。図6-6では、クラスタに送信されたリクエストはすべて、クラスタのメンバーのいずれかによって同等に処理されます。

次の各項では、Oracle WebCenterクラスタのランタイムと構成の両面に関して詳細に説明します。

図6-6 Oracle WebCenterの2ノードの高可用性アーキテクチャ

Oracle WebCenterの2ノードの高可用性アーキテクチャ
「図6-6 Oracle WebCenterの2ノードの高可用性アーキテクチャ」の説明

6.3.2.1 Oracle WebCenterアプリケーション

Oracle WebCenterのインストール時、管理対象サーバーは、システム・ライブラリおよびADFライブラリにプロビジョニングされます。表6-4は、管理対象サーバーと、それらの管理対象サーバーで稼働するアプリケーションを一覧表示しています。

表6-4 Oracle WebCenterの管理対象サーバーとアプリケーション

管理対象サーバー アプリケーション

WLS_Spaces

webcenter

webcenter-help

WLS_Portlets

portalTools

wsrp-tools

WLS_Services

owc_discussions Oracle WebCenterディスカッション・サーバー

owc_wiki Oracle WebCenter Wiki and Blogサーバー

6.3.2.2 Oracle WebCenterの起動順序

管理対象サーバーが起動すると、アプリケーションとライブラリは次の順序で起動します。

  1. Oracleシステム・ライブラリ（別名、JRFライブラリ）

  2. Oracle ADFライブラリ

  3. インスツルメンテーション・アプリケーション（Oracle DMSなど）

  4. 表6-1に示すWebCenterアプリケーション

起動順序は依存性の順序でもあります。依存コンポーネントが正しくデプロイされないと、その後のコンポーネントが正しく機能しない場合があります。WebCenterアプリケーションの起動は、ディスカッション・サーバーなどの外部サービスやその他のバックエンド・サーバーの可用性に依存しません。

6.3.2.3 WebCenterアプリケーションのクラスタへのデプロイ

図6-6に示すようなOracle WebCenterクラスタ・デプロイメントでは、アプリケーション、ライブラリおよびシステム・リソースのターゲット設定に関して、次のルールに従います。

  • アプリケーションとライブラリのターゲットをクラスタのターゲットに設定します。たとえば、WebCenterアプリケーションのターゲットをSpacesクラスタに設定します。

  • JDBCリソースをクラスタのターゲットに設定します。

WebCenterアプリケーションおよびWebCenterディスカッション・サーバーは、Oracle WebLogicstageアプリケーションとしてデプロイされます。各アプリケーションの初期デプロイメント中に、デプロイメント・ファイルが管理サーバーから送信され、ローカルにデプロイされます。例外はOracle WebCenter Wiki and Blogサーバー・アプリケーションで、これはnostageアプリケーションとしてデプロイされます。

クラスタ通信

デフォルトでは、各Oracle WebCenterクラスタはユニキャストとして構成されています。使用するOracle WebCenterクラスタをマルチキャストとして構成するには、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。

6.3.2.4 Oracle WebCenterの状態のレプリケーション

Oracle WebCenterは、複数のステートフル・コンポーネントで構成されているOracle ADFに依存しています。WebCenter自体もステートフル・アプリケーションです。そのため、クラスタのシナリオで状態のレプリケーションを構成する必要があります。

Oracle WebLogic Serverでの状態のレプリケーションの動作の詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。

Oracle WebLogic Serverは、次の2種類の状態のレプリケーションをサポートしています。

  • メモリー内レプリケーション: Oracle WebLogic Serverはメモリー内レプリケーションを使用して、1つのサーバー・インスタンスから別のインスタンスにセッション状態をコピーします。プライマリ・サーバーは、クライアントが最初に接続するサーバーにプライマリ・セッション状態を作成し、クラスタ内の別のWebLogic Serverインスタンスにセカンダリ・レプリカを作成します。このレプリカは最新状態に維持されるため、サーブレットをホストしているサーバーに障害が発生した場合に使用できます。

  • JDBCベースの永続性: JDBCベースの永続性では、Oracle WebLogic Serverは、ファイル・ベースまたはデータベース・ベースの永続性を使用して、サーブレットまたはJSPのHTTPセッション状態を保持します。

状態のレプリケーションを適切に構成するには、環境とアプリケーションの両方を適切に構成する必要があります。フェイルオーバーの状況における状態のレプリケーションの動作の詳細は、第6.3.2.7項「アプリケーションのフェイルオーバーで予想される動作」を参照してください。

状態のレプリケーションの問題の診断の詳細は、第6.3.2.4項「Oracle WebCenterの状態のレプリケーション」を参照してください。

6.3.2.5 分散Javaオブジェクト・キャッシュの理解

WebCenterアプリケーションでは、パフォーマンス向上のために分散Javaオブジェクト・キャッシュが使用されています。このキャッシュはすべてのOracle WebCenterクラスタ間で構成し、クラスタごとに分散キャッシュを1つずつ用意します。

表6-5は、Oracle WebCenterがJavaオブジェクト・キャッシュに配置するオブジェクト・タイプの例を一覧表示しています。

表6-5 Oracle WebCenterのJavaオブジェクト・キャッシュ用のオブジェクト・タイプ

Oracle WebCenterコンポーネント キャッシュされるオブジェクト

ディスカッション・サービス

トピックとフォーラム

お知らせサービス

お知らせ

インスタント・メッセージおよびプレゼンス・サービス

プレゼンス・サブスクリプション・リスト

ユーザーのプレゼンス/サブスクリプション・ステータス

ワークリスト・サービス

呼び出されたワークリスト項目（キャッシュ済データは、リフレッシュが呼び出されるまで使用される）。

コンテンツ統合（Oracle Portal）

JCR: リポジトリから取得したタイプ情報とメタデータ。

サービス・フレームワーク

ユーザー・プロファイル。問合せされたユーザー名。

最近のアクティビティ

ユーザーごとの最近のアクティビティ結果。

WebCenter Spaces

アプリケーション内のグループ・スペースとグループ・スペース・テンプレートのグローバル・リスト。

ユーザーがアクセス可能なグループ・スペースとグループ・スペース・テンプレートのリスト。

ページ・サービス

スコープ内のページのリスト。

WSRPサーバー

WSRPプロデューサのプリファレンス・ストアの値。

ドキュメント・サービス

WebCenter Spacesアプリケーション用に構成されたドキュメント・サービスのプロビジョニングと構成のチェック。

コラボレーション

コラボレーション・サービスは、ユーザー・セッションごとにオブジェクトをJavaオブジェクト・キャッシュに格納します。HTTPセッションが破棄されると、これらのキャッシュ済ユーザー・セッションも破棄されます。

ワークリスト

ワークリストは、呼び出された項目をキャッシュするため、リフレッシュ・ボタンがクリックされるか、または15分ごとにリフレッシュ・ポーリングがトリガーされないかぎり、ユーザーが設定によってソートやグループを変更する際に同じ項目が表示されます。表示もグループおよびソートの順序の設定によってキャッシュされ、変更が行われたときに更新されます。これは読取り専用データで、存在しない場合にはフェッチされてキャッシュに格納されます。

WebCenter Spaces

すべてのテンプレートおよびパブリック・スペースのリストは、Javaオブジェクト・キャッシュに保持されます。特定のユーザーがアクセスできるグループ・スペースとテンプレートのリスト以外に、このスペースもすべてのユーザーによって共有されます。これらはユーザーごとにキャッシュされます。1つのJVMで作成されるテンプレートは、テンプレート・キャッシュが別のJVMで初期化されている場合には表示されません。ただし、JOCがデータを配布するか、または2番目のJVMの管理者が明示的リフレッシュを行なってキャッシュを再構築した場合は例外です。

ドキュメント・サービス

WebCenter Spacesアプリケーションの構成と同様、ドキュメント・サービスは、Javaオブジェクト・キャッシュを使用して、ドキュメント・サービスのプロビジョニングと構成のチェックをキャッシュします。プロビジョニングの場合には、キャッシュされたオブジェクトには分散完了のフラグが付けられます。これらのオブジェクトは、正しく構成されたJavaオブジェクト・キャッシュによって高可用性環境内でレプリケートされ、構成のキャッシュ済状態はローカルで保持されます。キャッシュされたオブジェクトはすべて、1分後に期限切れとなるようにフラグが付けられます。キャッシュすることによって、UCMサーバーの状態をチェックするためにUCMコールが行われる回数が減ります。これは、WebCenter Spacesがプロビジョニングと構成を繰り返しチェックして、UIにおけるサービスのレンダリングを制御するためです。

最近のアクティビティ

最近のアクティビティのタスク・フローまたはRSSフィードが表示されるたびに結果の再問合せが行われないようにするため、最近のアクティビティ結果のリストは、ユーザーごとにキャッシュされます。キャッシュは15分ごとに自動的にリフレッシュされるか、または最近のアクティビティのタスク・フローにあるリフレッシュ・アイコンを使用して手動でリフレッシュできます。

Javaオブジェクト・キャッシュの構成手順については、第6.4.13項「Javaオブジェクト・キャッシュの構成」を参照してください。

6.3.2.6 Oracle WebCenterのフェイルオーバーによる保護および予想される動作

Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内で他に利用可能なメンバーがリクエストを処理できます。

セッションのフェイルオーバー要件

WebCenterアプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。

  • アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できる。

  • ステートフル・アプリケーションに対し、第6.4.15項「Oracle ADFのレプリケーションの構成」の説明に従って、状態のレプリケーションが正しく構成されている。

  • Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されている。

  • ハードウェア・ロード・バランサを使用する場合には、ロード・バランサが次のようになっていること。

    • 利用可能なインスタンスすべてに対してトラフィックをルーティングしている

    • 利用できないインスタンスをマークするように、状態モニターで正しく構成されている

    • セッションの状態の永続性をサポートするように構成されている

6.3.2.7 アプリケーションのフェイルオーバーで予想される動作

環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気がつきません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。

  1. ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。

  2. ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。

  3. ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。

  4. ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。

  5. インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。

  6. インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。

予想される動作に対する例外

Oracle WebCenterでは、これらの予想される動作に対する既知の例外は次のとおりです。

  • Oracle ADFのポップアップ: 開いているポップアップがフェイルオーバー時に閉じます。これは、通常は例外のない多くのコンポーネントに影響を及ぼします。影響を受けるコンポーネントは次のとおりです。

    • Oracle Composer（プロパティ・インスペクタのポップアップ）

    • リスト

    • リンク（リンク削除のポップアップ）

    フェイルオーバーが発生した場合、ポップアップを再表示するには、そのポップアップを表示する原因となったアクションを繰り返す必要があります。これがWebCenter Spacesに表示される具体的な方法および推奨される処置は、表6-6に一覧表示されています。

    表6-6 Oracle WebCenterのトラブルシューティングのシナリオ

    フェイルオーバー前のアクション フェイルオーバー後 推奨される処置

    任意のページにアクセスして「ページの作成」をクリックします。

    名前を入力し、テーマを選択して「OK」をクリックします。テーマを選択すると、ページ作成ポップアップが閉じます。

    この操作を繰り返します。

    「ページの管理」を起動します。

    ポップアップ内で、ポップアップを閉じること以外の操作を実行します。たとえば、「ページ・アクション」をクリックします。任意の操作を実行すると、「ページの管理」ポップアップが閉じます。

    この操作を繰り返します。

    「ページの管理」を起動し、ページに対して「ページ・アクション」をクリックしてから、メニュー内の「削除」オプションをクリックします。

    確認ポップアップで「OK」をクリックします。「OK」をクリックすると、確認ポップアップが閉じるだけでなく、「ページの管理」ポップアップもリクエストの一部として閉じ、（行われた可能性のある）削除の効果はタブには表示されません。

    「ページの管理」ポップアップを再起動し、ページが削除されているかどうかを確認します。削除されていない場合は、もう一度削除してみます。

    「アプリケーションのパーソナライズ」ポップアップを起動します。「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。

    「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。リクエストをサーバーに送信する任意の操作を実行すると、「アプリケーションのパーソナライズ」ポップアップが閉じます。

    この操作を繰り返します。

    「プリファレンス」を起動します。

    「プリファレンス」のタブ（「一般」、アカウント、「メッセージング」、「検索」）間の切替えを行います。「プリファレンス」のタブ間で切替えを行うと、「プリファレンス」ポップアップが閉じます。

    この操作を繰り返します。

    「お気に入りの管理」を起動します。サーバーを停止し、ポップアップを閉じること以外の操作を実行します。たとえば、フォルダを開いてお気に入り情報の編集をクリックします。

    ポップアップを閉じること以外の操作を実行します。たとえば、フォルダを開いてお気に入り情報の編集をクリックします。任意の操作を実行すると、「お気に入りの管理」ポップアップが閉じます。

    「お気に入りの管理」ポップアップを再起動し、操作が正常に実行されたかどうかを確認します。正常に実行されなかった場合は、この操作を再試行します。

    アプリケーションの編集と新しいフォルダの作成を選択します。

    MDS例外が表示されます。

    この操作を再試行します。

  • コンポーネント固有の問題: Oracle WebCenterの各コンポーネントに固有の他の問題は、表6-7に一覧表示されています。

    表6-7 Oracle WebCenterでの予想される動作に対する例外

    Oracle WebCenterコンポーネント 予想される動作に対する例外

    グループ・スペース・イベント

    特定のフィールド（開始または終了の日/時/分）を変更すると、フェイルオーバーの発生時にイベント・フォームが閉じます。

    ポートレット

    障害は完全に透過的です。

    リスト

    障害は完全に透過的です。

    リンク

    障害は完全に透過的です。

    検索

    長時間実行される問合せの最中。戻される結果は保証されません（ここでは書込み操作は存在しないことに注意）。ユーザーは問合せを再発行できます。

    タグ付け

    障害は完全に透過的です。

    最近のアクティビティ

    ツリー・ノードのオープン/クローズ状態はレプリケートされません。フェイルオーバー後、結果のツリーによってノードがすべて閉じます。ノードは開きなおす必要があります。

    ワークリスト

    障害は完全に透過的です。

    ドキュメント・マネージャ

    ユーザーがドキュメントをアップロードしたときに、同じ名前のドキュメントがすでに存在している場合は、「新規バージョンの確認」画面が表示されます。その画面の表示中、ファイルは一時的なローカルの場所に格納されます。そのときにフェイルオーバーが発生すると、アップロードしたファイルは失われ、ユーザーはアップロード・プロセスを再実行する必要があります。

6.3.2.8 アプリケーション・デプロイメントのロギングの監視

Oracle WebLogic Server管理コンソールを使用して、アプリケーション・デプロイメントのステータスを確認します。また、Oracle WebCenterプロセスの開始、停止および監視には、Oracle WebLogic ServerインフラストラクチャとEnterprise Manager Fusion Middleware Controlも使用できます。

6.3.2.9 Oracle WebCenterクラスタ全体の構成の変更

WebCenter Spacesとポートレット・プロデューサの場合、すべての構成データはMDSリポジトリおよびポートレット・プロデューサに格納されます。アプリケーションの起動時には、追加のクラスタ・デプロイメントによって、最新の構成が自動的に読み取られます。

Oracleディスカッション・サーバーの場合、構成情報は既存のクラスタ・サーバーから移動する必要があります。これは、Oracle WebLogic Serverのpack/unpackユーティリティによって自動的に行われます。これがお薦めする手順です。

Oracle WebCenter Wiki and Blogサーバーの場合、ほとんどの構成はデータベースに格納されますが、デプロイメント・ディレクトリ内のカスタム・テンプレートに固有の構成もあります。クラスタ・インストールでは、クラスタ内のすべてのWiki and Blogサーバーがこのデプロイメント・ディレクトリを共有する必要があります。

6.3.2.10 クラスタ環境での構成の保持

WebCenter Spacesとポートレット・プロデューサの場合、すべての構成データはMDSリポジトリおよびポートレット・プロデューサに格納されます。クラスタ内の1つのサーバーの構成に対して行われた変更は、他のすべてのメンバーにただちに表示されます。

Oracle WebCenterディスカッション・サーバーは頻繁に変更されませんが、変更された場合は、変更をクラスタの他のメンバーに再適用する必要があります。再適用するには、ロード・バランサを使用するかわりに各ディスカッション・サーバーに直接接続し、必要な管理変更を行います。

Oracle Wiki and Blogサーバーの場合、その構成はデータベースおよびローカルのデプロイメント・ディレクトリに保持されます。構成はノードごとに適用する必要があります。

6.4 Oracle WebCenterの高可用性の構成

図6-6は、1つのWebLogic Serverドメイン内の2つのOracle WebLogic Serverで、2ノードのOracle WebCenterクラスタが稼働している状況を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。メタデータとスキーマの格納にはOracle RACデータベースが使用されます。Oracle Wiki and Blogサーバーの共有構成には共有記憶域が使用されます。管理サーバーにはVIPが使用されます（手動フェイルオーバー用）。


注意:

設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。


注意:

コマンド例はすべて、Kシェルまたはbashシェルに対するものです。Cシェルの例は提供されていません。

6.4.1 環境の準備: Oracle WebCenterの高可用性構成の設定前に必要な手順

次の各項では、Oracle WebCenterの高可用性構成を設定する前に必要となる手順について説明します。

プラットフォーム固有のコマンドの詳細は、『Oracle Fusion Middleware Oracle WebCenterインストレーション・ガイド』を参照してください。

6.4.1.1 データベースに関する前提条件

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%';

6.4.1.2 VIPとIPの前提条件

管理サーバーの仮想IPを構成するには、第12.2.2.3項「コールド・フェイルオーバー・クラスタ用の管理サーバーの変換」を参照してください。

6.4.1.3 データベース・リポジトリのインストールと構成

次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。

Oracle Clusterware

  • 10gリリース2（10.2）については、Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersのインストレーション・ガイドを参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Clusterwareインストレーション・ガイド』を参照してください。

自動ストレージ管理

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • インストーラを実行するときは、構成の選択ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。

Oracle Real Application Cluster

  • 10gリリース2（10.2）については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。

  • 11gリリース1（11.1）以降については、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。

Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g（11.1.1）Oracle Fusion MiddlewareリポジトリをReal Application Clusterデータベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ（RCU）が用意されています。RCUは、専用のMiddlewareホームにインストールします。

最新バージョンのRCUを使用して、11g（11.1.1）Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。

最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

データベースの初期化パラメータ

次の初期化パラメータが、必要な値に設定されていることを確認します。この値は、リポジトリ作成アシスタントによってチェックされます。

表6-8 必要な初期化パラメータ

パラメータ 必要な値 パラメータ・クラス

PROCESSES

300以上

静的

SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。

SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。

SQL> SHOW PARAMETER processes

次のコマンドを使用して初期化パラメータを設定します。

SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE

データベースを再起動します。


注意:

パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイルとサーバー・パラメータ・ファイルの詳細、およびパラメータ値の変更方法は、『Oracle Database管理者ガイド』を参照してください。

6.4.1.4 LDAPプロバイダのインストールと構成

本番環境では、Oracle WebCenterの高可用性トポロジに外部のLDAPポリシー・ストアが必須です。サポートされているポリシー・ストアの詳細およびLDAPの構成手順は、『Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter』を参照してください。

6.4.1.5 ディレクトリおよびディレクトリ環境変数の用語

次のリストは、この項で使用するディレクトリと変数について説明しています。

  • 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

6.4.1.6 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用したデータベースへのFusion Middlewareスキーマのロード

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ユーザーズ・ガイド』を参照してください。

6.4.1.6.1 RCUの実行

RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。

  1. 次のコマンドを使用してRCUを起動します。

    RCU_HOME/bin/rcu &

  2. 「ようこそ」画面で「次へ」をクリックします。

  3. 「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。

  4. 「データベース接続の詳細」画面で、データベースの接続情報を入力します。

    • データベース・タイプ: Oracle Databaseを選択します。

    • ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します: WCDBHOST1VIRTUAL

    • ポート: データベースのポート番号: 1521

    • サービス名: データベースのサービス名を入力します: wcha.mycompany.com

    • ユーザー名: SYS

    • パスワード: SYSユーザーのパスワードを入力します。

    • ロール: SYSDBA

  5. 「次へ」をクリックします。

  6. 次の警告メッセージを受信した場合は、「無視」または「停止」をクリックします。

    接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。

  7. 「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、WCHAのように、データベース・スキーマに使用する接頭辞を入力します。

    後の手順で利用できるように、このスキーマ名を書き留めておきます。

    • 次のスキーマを選択します。

      • AS共通スキーマ:

        Metadata Services

      • WebCenterインフラストラクチャ:

        WebCenter Suite

  8. 「次へ」をクリックします。

  9. 「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加（補助）のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。

  10. 「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。

  11. 「サマリー」画面で「作成」をクリックします。

  12. 「完了サマリー」画面で「閉じる」をクリックします。

RCUの使用の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

6.4.2 WebHost1へのOracle HTTP Serverのインストール

WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。

  1. サーバーが次の要件を満たしていることを確認します。

    • システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』で指定されている要件を満たしています。

    • この例ではポート7777を使用します。ポート7777を選択する場合には、ノード上のいずれのサービスでもこのポートが使用されていないことを確認します。このことを確認するには、次のコマンドを実行します。

      UNIX:

      netstat -an | grep LISTEN | grep ":7777"

      Windows:

      netstat -an | findstr "LISTEN" | findstr ":7777"

    ポート7777が使用中の場合には、別のポートを選択するか、またはこのポートを使用可能にします。

  2. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

    /etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

  3. Oracle Fusion Middleware 11g Webtier Utilities CDインストールのOracle Universal Installerを、次のように開始します。

    UNIXでは、コマンド./runInstallerを実行します。

    Windowsでは、setup.exeをダブルクリックします。

  4. 「インベントリ・ディレクトリの指定」画面で、インベントリおよびユーザー・グループの場所を入力して「OK」をクリックします。

  5. ダイアログに従ってrootの特権アクションを実行し、「OK」をクリックします。

  6. 「ようこそ」画面で「次へ」をクリックします。

  7. 「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。

  8. 「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。

  9. 「インストール場所の指定」画面で、場所を次のように設定します。

    /u01/app/oracle/product/11.1.1/ohs_1

  10. 「次へ」をクリックします。

  11. 「コンポーネントの構成」画面で、次の操作を行います。

    • 「Oracle HTTP Server」を選択します。

    • 「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。

    • 「次へ」をクリックします。

  12. 「コンポーネントの詳細の指定」画面で、次の値を入力します。

    • インスタンス・ホームの場所: app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1

    • インスタンス名: ohs_instance1

    • OHSコンポーネント名: ohs1

  13. 「次へ」をクリックします。

  14. 「Web Tierポートの詳細の指定」画面で、次の操作を行います。

    • 「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。

    • Oracle HTTP Serverのポート番号を入力します。たとえば、7777と入力します。

    「次へ」をクリックします。


    注意:

    ポートの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』を参照してください。

  15. 「次へ」をクリックします。

  16. 「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。

  17. 「インストールの進行状況」画面で、次の操作を行います。

    UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.shスクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。

    「次へ」をクリックします。

  18. 「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。

  19. 「構成が完了しました」画面で、「終了」をクリックして終了します。

6.4.2.1 Oracle HTTP Serverの検証

Oracle HTTP Serverが正しく設定されていることを確認するには、Webブラウザで次のURLを使用し、サーバーのルートURLコンテキストにアクセスします。

WebHost1:7777/

Oracle HTTP Serverが正しく設定されている場合は、ブラウザに「Hello World」ページが表示されます。

6.4.3 Oracle Fusion Middlewareホームのインストール

次の手順を使用して、Oracle Fusion Middlewareコンポーネントをインストールします。

6.4.3.1 Oracle WebLogic Serverのインストール

最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンについては、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。

  1. UNIXプラットフォームで、/etc/oraInst.locファイルまたは/var/opt/oracle/oraInst.locファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。

    /etc/oraInst.locファイルが存在していない場合には、この手順をスキップします。

  2. Oracle WebLogic Serverインストーラを起動します。

  3. 「ようこそ」画面で「次へ」をクリックします。

  4. 「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。

    • 「新しいミドルウェア・ホームを作成する」を選択します。

    • 「ミドルウェア・ホーム・ディレクトリ」フィールドで、MW_HOMEと入力します。

    • 「次へ」をクリックします。

  5. 「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。

  6. 「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。

  7. 「JDKの選択」画面で、「Oracle JRockit 1.6.0_14 SDK」のみを選択して「次へ」をクリックします。

  8. 「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。

    WL_HOME

    「次へ」をクリックします。

  9. 「インストールの概要」画面で「次へ」をクリックします。

  10. 「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。

6.4.3.2 Oracle WebCenter用Oracle Fusion Middlewareのインストール

アプリケーション層にあるすべてのノードにOracle WebCenter用Oracle Fusion Middlewareをインストールする手順は次のとおりです。

  1. 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のように入力します。

  2. 「ようこそ」画面で「次へ」をクリックします。

  3. 「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。

  4. 「インストール場所の指定」画面で、次の操作を行います。

    • 「MiddleWareホーム」には、MW_HOMEと入力します。

    • 「Oracleホーム・ディレクトリ」には、たとえばwcのように、使用するディレクトリを入力します。

    「次へ」をクリックします。

  5. 「インストール・サマリー」画面で「インストール」をクリックします。

  6. 「インストール 完了」画面で「終了」をクリックします。


注意:

第6.4.5項「WebLogic Server WebCenterのドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareの最新のパッチ・セットなどの既知のパッチをMiddlewareホームに適用して、Oracle Fusion Middlewareを最新バージョンにしておいてください。

最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。

6.4.4 管理サーバーのVIPの有効化

管理サーバーの仮想IPの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のアクティブ/パッシブ・トポロジ」を参照してください。

6.4.5 WebLogic Server WebCenterのドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行

MiddlewareホームのWebCenterディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracle WebCenterコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースでは、すべてのインスタンスを実行することをお薦めします。

  1. 次のコマンドを使用して、ORACLE_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。

    APPHOST1> ./config.sh

  2. 「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。

  3. 「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。

    Webcenter Spacesを選択すると、WSMポリシー・マネージャとOracle JRFが自動的に選択されます。

    • Oracle WebCenter Spaces - 11.1.1.2.0

    • Oracle Enterprise Manager - 11.1.1.2.0

    • Oracleポートレット・プロデューサ - 11.1.1.2.0

    • Oracle Wiki and Blogサーバー - 11.1.1.2.0

    • Oracle WebCenterディスカッション・サーバー - 11.1.1.2.0

    • Oracle JRF - 11.1.1.2.0

    「次へ」をクリックします。

  4. 「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。

  5. 「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。

  6. 「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。

    • WebLogicドメインの起動モード: 「本番モード」を選択

    • JDKの選択: 「Oracle JRockit 1.6.0_14 SDK」を選択

    「次へ」をクリックします。

  7. 「JDBCデータ・ソースの構成」画面で、「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。

    リポジトリ作成ユーティリティによって、必要なスキーマがOracleデータベースに作成されます。これらのスキーマにはカスタム接頭辞を指定します。表6-9は、データソース、使用するスキーマ、およびスキーマが割り当てられている管理対象サーバーを一覧表示しています。

    1. 画面に次のデータソースが表示されていることを確認します。

      表6-9 Oracle WebCenterのデータ・ソース

      データ・ソース スキーマ名

      OWCWikiDS

      Prefix_wiki

      DiscussionsDS

      Prefix_discussions

      PortletDS

      Prefix_portlet

      WebCenterDS

      Prefix_webcenter

      mds-SpacesDS

      Prefix_mds

      OWSM MDS

      Prefix_mds

    2. 次のパネルですべてのデータ・ソースをRACマルチ・データ・ソース・スキーマとして構成します。を選択します。

    3. 「次へ」をクリックします。

  8. 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、「追加」ボタンをクリックして、両方のOracle RACノードの「ホスト名」、「インスタンス名」および「リスニング・ポート」を追加します。

    図6-7 「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

    「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面

    1つのスキーマを選択したまま残し、他のスキーマの選択は解除します。

    1. 「ドライバ」ドロップダウン・リストで、RACサービス・インスタンス接続用Oracleのドライバ（Thin）を選択します。

    2. 「サービス名」を入力します。

    3. Oracle WebCenterスキーマのPrefix_Usernameを入力します。

    4. スキーマの「パスワード」を入力します。

    5. 「追加」をクリックして、最初のOracle RACインスタンスの詳細を入力します。

    6. 一度に1つのデータ・ソースを選択し、適切な詳細を追加することで、各マルチ・データ・ソース・スキーマを更新します。

    「次へ」をクリックします。

  9. 「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常だったことを確認します。正常でない接続があった場合には、「前へ」をクリックして前の画面に戻り、入力内容を修正します。

    すべての接続が正常になったら「次へ」をクリックします。

  10. 「オプションの構成を選択」画面で、次を選択します。

    • 管理サーバー

    • 管理対象サーバー、クラスタ、およびマシン

  11. 「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。

  12. 「管理サーバーの構成」画面で、次の値を入力します。

    • 名前: AdminServer

    • リスニング・アドレス: 第6.4.4項で使用したVIPアドレスを入力します。

    • リスニング・ポート: 7001

    • SSLリスニング・ポート: N/A

    • SSL有効: 選択を解除

    「次へ」をクリックします。

  13. 「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。

    表6-10 管理対象サーバーの構成

    名前 リスニング・アドレス リスニング・ポート SSLリスニング・ポート SSL有効

    WLS_Portlet

    APPHOST1のホスト名

    8889

    n/a

    選択を解除

    WLS_Portlet2

    APPHOST2のホスト名

    8889

    n/a

    選択を解除

    WLS_Spaces1

    APPHOST1のホスト名

    8888

    n/a

    選択を解除

    WLS_Spaces2

    APPHOST2のホスト名

    8888

    n/a

    選択を解除

    WLS_Services1

    APPHOST1のホスト名

    8890

    n/a

    選択を解除

    WLS_Services2

    APPHOST2のホスト名

    8890

    n/a

    選択を解除

    「次へ」をクリックします。

  14. 「クラスタの構成」画面で、次のクラスタを追加します。

    Portlet_Cluster

    • 名前: Portlet_Cluster

    • クラスタ・メッセージング・モード: unicast

    • クラスタ・アドレス有効化: 空白のまま

    Spaces_Cluster

    • 名前: Spaces_Cluster

    • クラスタ・メッセージング・モード: unicast


      注意:

      デフォルトでは、各Oracle WebCenterクラスタはユニキャストとして構成されています。使用するOracle WebCenterクラスタをマルチキャストとして構成するには、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』を参照してください。

    • クラスタ・アドレス有効化: 空白のまま

    Services_Cluster

    • 名前: Services_Cluster

    • クラスタ・メッセージング・モード: unicast

    • クラスタ・アドレス有効化: 空白のまま

    「次へ」をクリックします。

  15. 「サーバーのクラスタへの割当」画面で、クラスタに次のサーバーを割り当てます。

    • Spaces_Cluster

      WLS_Spaces1

      WLS_Spaces2

    • Portlet_Cluster

      WLS_Portlet1

      WLS_Portlet2

    • Services_Cluster

      WLS_Services1

      WLS_Services2

    「次へ」をクリックします。

  16. 「マシンの構成」画面で、次の操作を行います。

    • デフォルトとして表示される「LocalMachine」を削除します。

    • 「UNIXマシン」タブをクリックし、次のマシンを追加します。

    表6-11 マシンの構成

    名前 ノード・マネージャのリスニング・アドレス

    APPHOST1

    APPHOST1のホスト名

    APPHOST2

    APPHOST2のホスト名

    「次へ」をクリックします。

  17. 「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。

    図6-8 「サーバーのマシンへの割当」画面

    「サーバーのマシンへの割当」画面

    • APPHOST1: WLS_Spaces1、WLS_Portlet1、WLS_Services1

    • APPHOST2: WLS_Spaces2、WLS_Portlet2、WLS_Services2

    「次へ」をクリックします。

  18. 「構成のサマリ」画面で「作成」をクリックします。

  19. ドメインの作成中画面で「完了」をクリックします。

6.4.6 APPHOST1での管理サーバーおよび管理対象サーバー用boot.propertiesの作成

この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーおよび管理対象サーバーに対してboot.propertiesファイルを作成します。

管理サーバーに対しては、次の手順を実行します。

  1. 次のディレクトリを作成します。

    APPHOST1> mkdir -p MW_HOME/user_projects/domains/wcdomain/servers/AdminServer/security

  2. テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

    username=adminuser
password=password

    注意:

    管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

    セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

WLS_Spaces1管理対象サーバーに対しては、次の手順を実行します。

  1. 次のディレクトリを作成します。

    APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/servers/WLS_Spaces1

APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/servers/WLS_Spaces1/security

  2. テキスト・エディタを使用して、前の手順で作成したセキュリティ・ディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

    username=adminuser
password=password

  3. APPHOST1での管理対象サーバーWLS_Portlet1およびWLS_Services1に対し、手順2と3を繰り返します。


注意:

管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。

セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

6.4.7 APPHOST1でのシステムの起動

この項では、APPHOST1でシステムを起動する手順について説明します。

6.4.7.1 APPHOST1での管理サーバーの起動

APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。

APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/bin

APPHOST1> ./startWebLogic.sh

6.4.7.2 管理サーバーの検証

管理サーバーが適切に構成されていることを確認する手順は次のとおりです。

  1. ブラウザでhttp://VIP1:7001/consoleにアクセスします。

  2. 管理者としてログインします。

  3. 管理対象サーバーとしてWLS_Spaces1およびWLS_Spaces2が表示されていることを確認します。

  4. Spaces_Clusterクラスタが表示されていることを確認します。

  5. Enterprise Manager（http://VIP1:7001/em）にアクセスできることを確認します。

6.4.7.3 APPHOST1およびAPPHOST2の管理サーバーおよび管理対象サーバーに対するホスト名の検証の無効化

この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。

ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。

APPHOST1でホスト名の検証を無効化する手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソールで、「サーバー」→「管理サーバー」を選択します。

  2. 「SSL」→「詳細」を選択します。

  3. 「ロックして編集」をクリックします。

  4. プロンプトが表示されたら、変更内容を保存してアクティブ化します。

  5. 「ホスト名の検証」を「なし」に設定します。

  6. 「WLS_Spaces1」→「SSL」→「詳細」を選択します。

  7. 「ホスト名の検証」を「なし」に設定します。

  8. WLS_Portlet1とWLS_Services1に対し、手順6と7を繰り返します。

  9. 管理サーバーおよびすべての管理対象サーバー（WLS_Spaces1、WLS_Portlet1、WLS_Services1など）を再起動します。

APPHOST2でホスト名の検証を無効化する手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソールで、「WLS_Spaces2」→「SSL」→「詳細」を選択します。

  2. 「ホスト名の検証」を「なし」に設定します。

  3. WLS_Portlet2とWLS_Services2に対し、手順1と2を繰り返します。

  4. 管理サーバーおよびすべての管理対象サーバー（WLS_Spaces2、WLS_Portlet2、WLS_Services2など）を再起動します。

6.4.7.4 APPHOST1でのノード・マネージャの起動

APPHOST1でノード・マネージャを起動するには、次の手順を実行します。

  1. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

    APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./setNMProps.sh

    注意:

    クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabledプロパティを使用する必要があります。

  2. ノード・マネージャを起動します。

    APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh

6.4.8 APPHOST2へのWebLogic ServerとOracle WebCenterのインストール

APPHOST2に対し、WebLogic ServerとOracle WebCenterのインストール手順を繰り返します。第6.4.3.1項「Oracle WebLogic Serverのインストール」の手順から始めてください。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。

6.4.9 pack/unpackユーティリティを使用したAPPHOST2へのドメイン構成の伝播

次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST2に伝播します。

  1. 次の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

  2. 次のコマンドをAPPHOST1で実行し、前の手順で作成したテンプレート・ファイルをAPPHOST2にコピーします。この例ではscpを使用しています。

    APPHOST1> scp wcdomaintemplate.jar
 APPHOST2:WL_HOME/common/bin

  3. unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。

    APPHOST2> cd WL_HOME/common/bin
APPHOST2> ./unpack.sh
 -domain=ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/
 -template=wcdomaintemplate.jar

6.4.10 APPHOST2でのノード・マネージャの起動

APPHOST2でノード・マネージャを起動するには、第6.4.7.4項「APPHOST1でのノード・マネージャの起動」の手順をAPPHOST2で繰り返します。

6.4.11 Oracle HTTP Serverの管理サーバーおよびOracle WebCenter管理対象サーバーの構成

Oracle WebCenter管理対象サーバーを含む管理サーバーへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定します。

  1. 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>
 
# Portlet
<Location /portalTools>
    WebLogicCluster apphost1.com:8889,apphost2.com:8889
    SetHandler weblogic-handler
</Location>
 
<Location /wsrp-tools>
    WebLogicCluster apphost1.com:8889,apphost2.com:8889
    SetHandler weblogic-handler
</Location>
 
# Discussions and Wiki
<Location /owc_discussions>
    WebLogicCluster apphost1.com:8890,apphost2.com:8890
    SetHandler weblogic-handler
</Location>
 
<Location /owc_wiki>
    WebLogicCluster apphost1.com:8890,apphost2.com:8890
    SetHandler weblogic-handler
</Location>

#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>

  2. WEBHOST1上のOracle HTTP Serverを再起動します。

    WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1

6.4.11.1 Oracle HTTP Serverを使用したアクセスの検証

URLを検証し、HTTP ServerからOracle WebCenterクラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。

  1. WebLogic Server管理コンソールから、WLS_Spaces1、WLS_Spaces2、WLS_Portlet1およびWLS_Portlet2を次のように起動します。

    1. 次のURLの管理コンソールにアクセスします。

      http://APHHOST1/console

    2. 「サーバー」をクリックします。

    3. 「制御」タブを開きます。

    4. WLS_Spaces1、WLS_Spaces2、WLS_Portlet1およびWLS_Portlet2を選択します。

    5. 「起動」をクリックします。

    6. 次のURLを使用して、管理対象サーバーへの直接アクセスを検証します。

      apphost1:8888/webcenter

      apphost2:8888/webcenter

      apphost1:8889/portalTools

      apphost2:8889/portalTools

  2. WLS_Spaces2とWLS_Portlet2の稼働中に、Oracle WebLogic Server管理コンソールからWLS_Spaces1とWLS_Portlet1を停止します。

  3. 次のURLにアクセスして、適切な機能を検証します。

    • WebHost1:7777/webcenter

    • WebHost1:7777/portalTools

  4. WebLogic Server管理コンソールからWLS_Spaces1とWLS_Portlet1を起動します。

  5. WLS_Spaces2とWLS_Portlet2を停止します。

  6. 次のURLにアクセスして、適切な機能を検証します。

    • WebHost1:7777/webcenter

    • WebHost1:7777/portalTools

6.4.12 APPHOST2への管理サーバーの手動フェイルオーバーの構成

高可用性のための管理サーバーの構成の詳細は、第12.4項「コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換」を参照してください。

6.4.13 Javaオブジェクト・キャッシュの構成

Javaオブジェクト・キャッシュ（JOC）は、WebCenter Spacesを実行しているすべてのサーバー間で構成する必要があります。このローカル・キャッシュは、Oracle WebCenter Spacesのパフォーマンスを向上させるために用意されています。

Javaオブジェクト・キャッシュは、MW_HOME/oracle_common/bin/configure-joc.pyスクリプトを使用して構成できます。これはPythonスクリプトで、管理対象サーバーでJOCを構成するために使用できます。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが稼働中であることが求められます。

Oracle製品にJOCポートを構成する場合は、9988〜9998のポートを使用することをお薦めします。


注意:

wlstコマンドまたはconfigure-joc.pyスクリプトを使用してJavaオブジェクト・キャッシュを構成した後で、構成を有効にするために、影響を受ける管理対象サーバーをすべて再起動する必要があります。

使用方法

  1. たとえば次のように、コマンドラインのOracle WebLogic Scripting Tool（WLST）を使用して管理サーバーに接続します。

    MW_HOME/wc/common/bin/wlst.sh
$ connect()

    プロンプトが表示されたら、Oracle WebLogicの管理ユーザー名とパスワードを入力します。

  2. wlstを使用して管理サーバーに接続したら、execfileコマンドを次のように使用してスクリプトを起動します。

    wls:/mydomain/serverConfig>execfile('FMW_HOME/oracle_common/bin/configure-joc.py')

  3. 指定したクラスタのすべての管理対象サーバーに対してJOCを構成します。

    クラスタ名を指定するかどうかが尋ねられたらyを入力し、プロンプトが表示されたらクラスタ名と検出ポートを指定します。これによって、指定したクラスタの管理対象サーバーがすべて検出され、JOCが構成されます。検出ポートはクラスタ内の全JOC構成に対して共通です。次に例を示します。

    Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : Spaces_Cluster
Enter Discover Port : 9988

    次に示すのは、高可用性環境でconfigure-joc.pyを使用する際の手順です。

    execfile('MW_HOME/oracle_common/bin/configure-joc.py')
.
Enter Hostnames (eg host1,host2) : APPHOST1, APPHOST2
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : Spaces_Cluster
.
Enter Discover Port : 9988
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n

このスクリプトは、次のJOC構成の実行にも使用できます。

  • 指定したすべての管理対象サーバーに対してJOCを構成します。

    クラスタ名を指定するかどうかが尋ねられたらnを入力し、プロンプトが表示されたら管理対象サーバーと検出ポートを指定します。次に例を示します。

    Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WLS_Spaces1:9988, WLS_Spaces2:9988) : WLS_Spaces1:9988,WLS_Spaces2:9988

  • 一部の管理対象サーバーに対してJOC構成を除外します。

    スクリプトでは、JOC構成のDistributeModeがfalseに設定される管理対象サーバーのリストを指定できます。一部のサーバーをJOC構成から除外するかどうかが尋ねられたらyを入力し、プロンプトが表示されたら除外する管理対象サーバーの名前を入力します。次に例を示します。

    Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
Exclude Managed Server List (eg Server1,Server2) : WLS_Spaces1,WLS_Spaces3

  • すべての管理対象サーバーに対して、分散モードを無効にします。

    スクリプトでは、指定したクラスタの管理対象サーバーすべてに対して分散を無効にできます。分散モードを指定するように求められたら、falseを指定します。デフォルトでは、分散モードはtrueに設定されています。

JOC構成を検証するには、CacheWatcherユーティリティを使用します。付録F「CacheWatcherの実行によるJavaオブジェクト・キャッシュの検証」を参照してください。

第16章「HAパワー・ツールの使用」の説明に従って、Oracle WebLogic管理コンソールを使用してJavaオブジェクト・キャッシュ（JOC）を構成できます。

6.4.14 Oracle Wiki and Blogサーバーの構成

ここで説明する手順は、Oracle WebCenter Wiki and Blogサーバーのクラスタを作成する際に必要な構成手順です。Wikiサーバーには、そのローカルのデプロイメント・ディレクトリに構成の一部（すべてではありません）が格納されるため、これらの手順が必要になります。これは、単一ノードのインストールに当てはまります。ただし、クラスタ構成では、Oracle Wikiクラスタのすべてのメンバーが同じ構成情報にアクセスする必要があります。

クラスタの他のメンバーが最初のWikiサーバーの構成にアクセスできるようにするには、そのデプロイメント・ディレクトリのいくつかが共有ドライブ上で使用可能である必要があります。

WCHOST1で行う操作:

  1. 共有ドライブに、/shared/owc_wikiという名前のディレクトリを作成します。

  2. その下に、/attachmentsおよび/templatesという2つのディレクトリを作成します。

  3. Wikiデプロイメント・ディレクトリを共有ディレクトリにコピーします。

    $ cp -r $ORACLE_BASE/admin/<DOMAIN_NAME>/apps/<DOMAIN_NAME>/owc_wiki/attachments/* /shared/owc_wiki/attachments
$ cp -r $ORACLE_BASE/admin/<DOMAIN_NAME>/apps/<DOMAIN_NAME>/owc_wiki/templates/* /shared/owc_wiki/templates

  4. デプロイメント・ディレクトリから共有ディレクトリへのシンボリック・リンクを作成します。

    $ rm -rf $ORACLE_BASE/admin/<DOMAIN_NAME>/apps/<DOMAIN_NAME>/owc_wiki/attachments
$ rm -rf $ORACLE_BASE/admin/<DOMAIN_NAME>/apps/<DOMAIN_NAME>/owc_wiki/templates
$ ln -s /shared/owc_wiki/attachments $ORACLE_BASE/admin/<DOMAIN_NAME>/apps/<DOMAIN_NAME>/owc_wiki/attachments
$ ln -s /shared/owc_wiki/templates $ORACLE_BASE/admin/<DOMAIN_NAME>/apps/<DOMAIN_NAME>/owc_wiki/templates

  5. 両方のサーバーで、Wiki管理→設定の非クラスタ・モード設定をfalse（キャッシュ・データの使用）に設定します。

WCHOST2で行う操作:


注意:

WCHOST2の管理対象サーバーが少なくとも1回は起動されており、初期のデプロイメント・ディレクトリが作成されていることを確認してください。ただし、管理対象サーバーは、次の手順に進む前に停止しておく必要があります。

  1. テンプレートおよび添付ファイル・ディレクトリから共有ディレクトリへのシンボリック・リンクを作成します。

    $ rm -rf $ORACLE_BASE/admin/<DOMAIN_NAME>/apps/<DOMAIN_NAME>/owc_wiki/ attachments
$ rm -rf $ORACLE_BASE/admin/<DOMAIN_NAME>/apps/<DOMAIN_NAME>/owc_wiki/ templates
$ ln -s /shared/owc_wiki/attachments $ORACLE_BASE/admin/<DOMAIN_NAME>/apps/<DOMAIN_NAME>/owc_wiki/attachments
$ ln -s /shared/owc_wiki/templates $ORACLE_BASE/admin/<DOMAIN_NAME>/apps/<DOMAIN_NAME>/owc_wiki/templates

  2. 1つのノード上で作成されたテンプレートにいずれのノードからもアクセスできることを確認します。

  3. 両方のサーバーで、Wiki管理→設定の非クラスタ・モード設定をfalse（キャッシュ・データの使用）に設定します。

6.4.15 Oracle WebCenterのレプリケーションの構成

この項の手順を使用して、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設定は、スタンドアロン・アプリケーション環境のレプリケーションを無効にし、クラスタ環境内のメモリー内レプリケーションを使用します。

メモリー内レプリケーションに任意のカスタム・アプリケーションが構成されていることを確認します。

6.4.16 ディスカッション・サーバーのクラスタリングの構成

ユニキャスト・クラスタの場合は、まず、第6.4.19項「マルチキャストからユニキャストへのディスカッションの変換」の手順が実行されていることを確認します。

ディスカッション・サーバーのクラスタのすべてのメンバーが、ディスカッション・サーバー管理コンソールを使用して互いに通信できることを確認します。

  1. 次の場所にあるクラスタの各メンバーにログインします。

    http://<host>:<port>/owc_discussions/admin

  2. 「キャッシュ設定」を開きます。

  3. ページの下部にあるキャッシュ機能セクションで、「クラスタリング」が「有効」に設定されていることを確認します。

    ページの上部に、クラスタのすべてのメンバーが一覧表示されます。

  4. 再度ページの下部に移動し、キャッシュ・ツールセクションで、クラスタワイドでのキャッシュのリセットおよびキャッシュのウォームアップ・タスクを実行します。クラスタのすべてのメンバーで、キャッシュのウォームアップ・タスクを繰り返します。

6.4.17 トポロジのスケーリング

Oracle WebCenterトポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。

6.4.17.1 トポロジのスケール・アップ（既存のノードへの管理対象サーバーの追加）

この場合は、WebCenterコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードの共有記憶域には、MiddlewareホームとWebCenterディレクトリが格納されています。

新しいOracle WebCenterおよびサーバーを作成するには、既存のインストール（Middlewareホームとドメイン・ディレクトリ）を使用できます。WebCenterのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。

トポロジをスケール・アップするには、次の手順を実行します。

  1. 管理コンソールを使用して、WLS_Spaces1、WLS_Portlet1またはWLS_Services1のクローンを新しい管理対象サーバーに作成します。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。

    管理対象サーバーのクローンを作成する手順は次のとおりです。

    1. 管理コンソールから「環境」→「サーバー」を選択します。

    2. クローンを作成する管理対象サーバー（WLS_Spaces1やWLS_Portlet1など）を選択します。

    3. 「クローンの作成」を選択します。

    新しい管理対象サーバーにSERVER_NAMEnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。

  2. リスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。

    この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。

  3. スケール・アップする管理対象サーバーがWLS_Services1の場合は、次の追加手順を実行します。

    1. 管理対象サーバーを少なくとも一度起動します。起動すると、Oracle Wikiに対して、管理対象サーバーのデプロイメント・ディレクトリが作成されます。これで管理対象サーバーを停止できるようになります。

    2. 両方のサーバーで、Wiki管理→設定の非クラスタ・モード設定をfalse（キャッシュ・データの使用）に設定します。

  4. クラスタ内の新しいメンバーを使用して、Oracle HTTP Serverモジュールを再構成します（Oracle HTTP Serverの構成を参照）。

6.4.17.2 トポロジのスケール・アウト（新しいノードへの管理対象サーバーの追加）

トポロジのスケール・アウトでは、Oracle WebCenterアプリケーションを使用して構成されている新しい管理対象サーバーを新しいノードに追加します。

この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。

  • トポロジ内には、WebCenterアプリケーションを使用して構成されている管理対象サーバーを実行しているノードがすでに存在しています。

  • 新しいノードが、WebLogic ServerとOracle WebCenter用の既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerまたはWebCenterのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。

トポロジをスケール・アウトするには、次の手順を実行します。

  1. 新しいノードで、WebCenterのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。

  2. 新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。

  3. このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。

  4. 管理コンソールを使用して、WLS_Spaces1/WLS_Portlet1/WLS_Services1のクローンを新しい管理対象サーバーに作成し、WLS_(SERVER_TYPE)nという名前を付けます。nは番号です。

    この手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。

  5. 管理対象サーバーのリスニング・アドレスに対して、新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。

  6. スケール・アップする管理対象サーバーがWLS_Services1の場合は、次の追加手順を実行します。

    1. 管理対象サーバーを少なくとも一度起動します。起動すると、Oracle Wikiに対して、管理対象サーバーのデプロイメント・ディレクトリが作成されます。これで管理対象サーバーを停止できるようになります。

    2. 両方のサーバーで、Wiki管理→設定の非クラスタ・モード設定をfalse（キャッシュ・データの使用）に設定します。

  7. クラスタ内の新しいメンバーを使用して、Oracle HTTP Serverモジュールを再構成します（Oracle HTTP Serverの構成を参照）。

  8. 新しいノードでノード・マネージャを起動します。すでに存在しているノードの共有記憶域にあるインストールを使用し、新しいノードのホスト名をパラメータとして渡してノード・マネージャを起動します。

    NEW_NODE> WL_HOME/server/bin/startNodeManager <new_node_ip>

    第6.4.3.1項「Oracle WebLogic Serverのインストール」に示すパスを使用した場合、MW_HOMEはMW_HOMEになります。

  9. 前の手順で追加した管理対象サーバーを管理コンソールから起動し、テストします。

    新規に作成した管理対象サーバー上のアプリケーション（http://HOST:port/webcenter）にアクセスします。アプリケーションが機能している必要があります。

  10. この新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します（第6.4.13項「Javaオブジェクト・キャッシュの構成」を参照）。

6.4.18 Oracle WebCenterの高可用性のトラブルシューティング

この項では、Oracle WebCenterで発生する可能性のある問題のトラブルシューティング手順について説明します。

6.4.18.1 Oracle WebCenterのデプロイメントに関する問題のトラブルシューティング

WebCenterアプリケーションは、管理対象サーバーが最初に起動したときにデプロイされます。最初にOracle WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメントがすべて成功したことを確認します。

左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。

アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME/servers/SERVER_NAME/logsディレクトリに格納されています。一般的な問題には、次のようなものがあります。

  • データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。

  • 適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。

6.4.18.2 Oracle WebCenterのレプリケーションおよびフェイルオーバーに関する問題のトラブルシューティング

フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります。

  • ウィンドウが閉じたか、または状態がリセットされた可能性がある。

  • 画面のリセットが必要になった可能性がある。

  • アプリケーションがログオン画面にリダイレクトしている可能性がある。

次の手順は、状態のレプリケーションに関する問題のトラブルシューティングおよび診断を行う際のガイダンスです。

  1. これがレプリケーションに関する既知の問題でないことを確認します。

    予想される動作については、第6.3.2.7項「アプリケーションのフェイルオーバーで予想される動作」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。

  2. ロード・バランサの設定を確認します。

    レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverのハードウェア・ロード・バランサの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』を参照してください。

  3. クラスタのステータスを確認します。

    クラスタのコンテキスト内でレプリケーションが発生します。フェイルオーバーが成功するには、クラスタの正常なメンバーが、ほかに少なくとも1つ使用可能である必要があります。クラスタのステータスは、次の2種類の方法のどちらかで確認できます。

    • Oracle WebLogic Server管理コンソールを使用してクラスタのステータスを確認します。左側のペインで「サーバー」をクリックします。クラスタ内のすべてのサーバーの状態を確認します。

    • weblogic.Adminユーティリティを使用してクラスタのステータスを確認します。weblogic.Adminコマンドは、特定のクラスタ内のすべてのサーバーの状態を問い合せるときに使用できます。次に例を示します。

      $ java weblogic.Admin -url Adminhost:7001 -username <username> -password
 <password>  CLUSTERSTATE -clustername Spaces_Cluster

      次のようなメッセージが返されます。

      There are 2 server(s) in cluster: Spaces_Cluster
The alive servers and their respective states are listed below:
WLS_Spaces---RUNNING
WLS_Spaces2---RUNNING

  4. クラスタ通信を確認します。

    クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。

    • ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。

      個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。

    • マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTestを実行して、マルチキャストが正しく構成されていることを確認します。次に例を示します。

      $ java utils.MulticastTest -H

  5. アプリケーションの構成を確認します。

    WebCenterアプリケーションは、デフォルトで正しく構成されています。ユーザー・アプリケーションに対するメモリー内のレプリケーションは、weblogic.xmlで適切な構成がなされている場合にのみ行われます。

    <session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>

    replicatedのpersistent-store-typeも受け入れられます。

  6. デバッグを有効にします。

    サーバー・ログを調べて、管理対象サーバーの起動時に異常なメッセージがないか確認します。この確認は、管理対象サーバーがクラスタの他のメンバーを見つけられない場合に、特に必要です。サーバー・ログは、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

6.4.18.3 ポリシーの変更が失われた場合のトラブルシューティング

ポリシーは、変数oracle.security.jps.ldap.policystore.refresh.intervalによってjps-config.xmlに定義されている間隔でリフレッシュされます。デフォルトでは、この間隔は10分です。サーバーが失われた場合、リクエストは、元のポリシーがキャッシュされている、クラスタ内の別のサーバーにルーティングされます。前回のリフレッシュ以後に発生した最近のポリシーの変更が失われたように見えることがあります。たとえば、フェイルオーバーの直前に作成されたロールは、使用不可と表示される場合があります。

このような状況でも、ポリシーは、バックエンド・ポリシー・ストアにあります。キャッシュをリフレッシュして、ポリシー情報をリストアします。数分後に再試行するか、またはアプリケーションにログインしてからログアウトして、ポリシー・キャッシュのリフレッシュを強制実行します。

6.4.18.4 JOC構成のトラブルシューティング

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を再構成します。

6.4.19 マルチキャストからユニキャストへのディスカッションの変換

ディスカッションをマルチキャストからユニキャストに変換する手順は次のとおりです。

手順1: 起動パラメータの追加

関連する起動パラメータの追加手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソールで、「サーバー」→「WLS_Services1」→「構成」→「サーバーの起動」を選択します。

  2. 「引数」ボックスで、次の行を追加します。

    -Dtangosol.coherence.wka1=Host1  -Dtangosol.coherence.wka2=Host2
-Dtangosol.coherence.localhost=Host1 -Dtangosol.coherence.wka1.port=8088
-Dtangosol.coherence.wka2.port=8088

    Host1は、WLS_Services1が実行されているホスト名です。

    WebCenter Coherenceの通信に8088以外のポートを使用するには、前述の例の引数-Dtangosol.coherence.wka1.portおよび-Dtangosol.coherence.wka2.portを使用して、別のポート番号を指定します。

  3. Host2はHost1に、Host1はHost2に入れ替えて、WLS_Services2に対して手順1と2を繰り返します。

  4. WLS_Services1サーバーを再起動します。

手順2: 変更の検証

変更を検証する手順は次のとおりです。

  1. ディスカッション・フォーラムの管理パネルにログオンします。

  2. 左ペインで「キャッシュ設定」を選択します。

  3. 画面の下部で、「クラスタリング」が「有効」に設定されていることを確認します。

  4. クラスタのすべてのメンバーに対して、手順1〜3を繰り返します。

    サーバーがクラスタに参加すると、それらのサーバーが画面の上部に表示されます。

6.5 Oracle ADFおよびWebCenterのカスタム・アプリケーションに対する高可用性の構成

この項では、高可用性のためにOracle ADFおよびWebCenterのカスタム・アプリケーションを構成する手順について説明します。

6.5.1 カスタム・アプリケーション・クラスタの構成

WebCenterアプリケーションをデプロイするためにクラスタを構成する際に必要となる手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソール（http://server_name:7001/console）にアクセスします。

  2. 管理ユーザー名とパスワードを入力してログインします。

  3. 「ホーム」ページで、ドメイン構成セクションの「サーバー」をクリックします。

  4. ページ・セクションの「概要」で「新規」をクリックします。

  5. カスタム・アプリケーション・サーバーに対する独自のサーバー名とポート番号（例: 8898）を入力します。

  6. 他の選択はデフォルトのままにして、「終了」をクリックして管理対象サーバーを生成します。

  7. 作成の概要ページで、作成したばかりのサーバーをクリックします。「マシン」ドロップダウン・リストをクリックし、「LocalMachine」を選択します。

  8. ページの下部にある「保存」をクリックします。

  9. 手順4〜8を繰り返し、必要に応じて管理対象サーバーをさらに作成します。

  10. クラスタを作成するには、「「ホーム」」ページで「クラスタ」をクリックします。

  11. 右側のペインで、「新規」をクリックして新しいクラスタを作成します。

  12. クラスタに名前を付け、デフォルトの「ユニキャスト」はそのままにします。

  13. 「OK」をクリックしてクラスタを作成します。

  14. クラスタ名をクリックし、「サーバー」タブをクリックします。

  15. 「追加」ボタンをクリックしてサーバーを追加します。

  16. ドロップダウン・リストから、前に作成した管理対象サーバーを選択し、「終了」をクリックします。

6.5.2 カスタム・アプリケーション・クラスタのプロビジョニング

クラスタを作成したら、正しいライブラリ、アプリケーションおよびデータ・ソースを使用してプロビジョニングします。

  1. 「ドメイン構造」セクションの「デプロイメント」リンクをクリックします。

  2. 複数の共有ライブラリがデプロイされていることに注意してください。次のライブラリのターゲットが、新規作成したクラスタに設定されていることを確認します。

    1. ライブラリ・リンクをクリックします。

    2. 上部の「ターゲット」タブをクリックします。

    3. 新規作成したクラスタのチェック・ボックスを選択します。

    4. 「保存」ボタンをクリックします。

    ターゲットを設定する共有ライブラリのリストは次のとおりです。

    • adf.oracle.domain(1.0,11.1.1.2.0)

    • adf.oracle.domain.webapp(1.0,11.1.1.2.0)

    • jsf(1.2,1.2.9.0)

    • jstl(1.2,1.2.0.1)

    • ohw-rcf(5,5.0)

    • ohw-uix(5,5.0)

    • UIX(11,11.1.1.1.0)

    • oracle.adf.dconfigbeans(1.0,11.1.1.2.0)

    • oracle.dconfig-infra(11,11.1.1.1.0)

    • oracle.jrf.system.filter

    • oracle.jsp.next(11.1.1,11.1.1)

    • oracle.sdp.client(11.1.1,11.1.1)

    • oracle.soa.workflow.wc(11.1.1,11.1.1)

    • oracle.webcenter.framework(11.1.1,11.1.1)

    • oracle.webcenter.framework.view(11.1.1,11.1.1)

    • oracle.webcenter.skin(11.1.1,11.1.1)

    • oracle.wsm.seedpolicies(11.1.1,11.1.1)

    • oracle.portlet-producer.jpdk(11.1.1,11.1.1)

    • oracle.portlet-producer.wsrp(11.1.1,11.1.1)

    これらのライブラリそれぞれのターゲットを新しい管理対象サーバーに設定します。また、次のアプリケーションをデプロイするためのターゲットとなるクラスタを設定します。

    • DMSアプリケーション

  3. Oracle WebLogic Server管理コンソールの左側のペインで、「サービス」→「JDBC」→「データ・ソース」をクリックします。次のデータ・ソースのターゲットが、新規作成したクラスタに設定されていることを確認します。

    • mds-OWSM


      注意:

      カスタム・アプリケーション用に独自のMDSスキーマを作成した場合は、その新しいMDSスキーマを新しいクラスタに割り当て、2つの事前定義済MDSスキーマは省略します。

  4. Oracle WebLogic Server管理コンソールの左側のペインで「環境」をクリックし、「起動クラスと停止クラス」をクリックします。次に一覧表示するクラスが使用可能になります。

    • 監査ローダー起動クラス

    • DMS-起動

    • JMXフレームワーク起動クラス

    • JOC-起動

    • JPS-起動クラス

    • JRF起動クラス

    • ODL-起動

    • OWSM起動クラス

    次のようにクリックし、これらのクラスすべてのターゲットを新しいクラスタに設定します。

    各起動/停止クラスの名前→「ターゲット」タブ→「CustomManagedServer」チェック・ボックス→「保存」

    これらの手順を完了すると、Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを起動し、カスタム・アプリケーションをデプロイできるようになります。カスタム・アプリケーションは、管理対象サーバーのターゲットでなく、クラスタのターゲットにデプロイします。

  5. 各起動/停止クラスの名前→「ターゲット」タブ→「CustomManagedServer」チェック・ボックスをクリックし、これらすべてのクラスのターゲットを新しいクラスタに設定します。

  6. 「保存」をクリックします。

  7. 変更をアクティブ化します。

これらの手順を完了すると、Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを起動し、カスタム・アプリケーションをデプロイできるようになります。カスタム・アプリケーションは、管理対象サーバーのターゲットでなく、クラスタのターゲットにデプロイします。

引き続きWebCenterの高可用性デプロイメントを構成するには、『Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter』を参照してください。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引