この章では、Oracle Application Development Framework(Oracle ADF)とOracle WebCenterの高可用性の概要と構成手順について説明します。
この章の項目は次のとおりです。
Oracle ADFは、JavaPlatform, Enterprise Edition(Java EE)の標準およびオープンソース・テクノロジに基づいて作成されたエンドツーエンド・アプリケーション・フレームワークで、サービス指向アプリケーションの実装を簡素化および迅速化します。Oracle ADFは、Web、無線、デスクトップ、またはWebサービスのインタフェースを使用してデータの検索、表示、作成、変更および検証を行うアプリケーションを作成するエンタープライズ開発者に適しています。Oracle JDeveloper 11gとOracle ADFを連携させると、ドラッグ・アンド・ドロップでのデータ・バインディング、視覚的なUI設計およびチーム開発の各機能を組み込んで、設計からデプロイまでの完全な開発ライフサイクルに対応する環境を作成できます。
コミュニティのベスト・プラクティスに従い、Fusion Webテクノロジ・スタックを使用して作成したアプリケーションでは、次のレイヤーによってサポートされているモデル・ビュー・コントローラ(MVC: Model-View-Controller)アーキテクチャに準拠することで、ビジネス・ロジック、ページ・ナビゲーションおよびユーザー・インタフェースが明確に分離されます。
図6-1に示すように、MVCアーキテクチャでは次のような構成になります。
モデル・レイヤーは、現行ページに関連するデータ値を表します。
ビュー・レイヤーには、その関連データの表示や変更に使用するUIページが保持されます。
コントローラ・レイヤーは、ユーザー入力を処理し、ページ・ナビゲーションを決定します。
ビジネス・サービス・レイヤーは、データ・アクセスを処理し、ビジネス・ロジックをカプセル化します。
フレームワークの中核モジュールは、JSR-227仕様を実装する宣言的なデータ・バインディング機能であるOracle ADF Modelです。この仕様は、宣言的なデータ・バインディング・メタデータへアクセスするためのAPIを提供します。Oracle ADF Modelレイヤーでは、統一されたアプローチを使用して、任意のユーザー・インタフェースとビジネス・サービスをコードを記述することなくバインドすることが可能です。
Fusion Webアプリケーション・テクノロジ・スタックを構成する他のモジュールは次のとおりです。
Oracle ADF Business Componentsは、ビジネス・サービスの構築を簡素化します。
Oracle ADF Facesは、JavaServer Faces(JSF)で構築されたWebアプリケーションに対し、AJAX対応のUIコンポーネントのリッチ・ライブラリを提供します。
Oracle ADF Controllerは、JSFをOracle ADF Modelに統合します。ADF Controllerは、追加機能を提供することにより標準のJSFコントローラを拡張します。この追加機能には、JSFページ間だけでなく他のアクティビティ(メソッドのコールや他のタスク・フローなど)間の制御も渡す再使用可能なタスク・フローなどがあります。
図6-2は、Fusion Webアプリケーション・アーキテクチャにおける各Oracle ADFモジュールの適合を示しています。
ADF Business Componentsは、ビルトイン・アプリケーション・オブジェクトであり、高性能で機能の豊富なデータベース中心のサービスの提供と維持を迅速化します。サービス指向のJava EEアプリケーションを作成するとき、開発者はコア・ビジネス・ロジックを1つ以上のビジネス・サービスとして実装します。これらのバックエンド・サービスは、適切なビジネス・ルールを施行し、かつ必要に応じてビジネス・データの問合せ、挿入、更新および削除を行う手段をクライアントに提供します。ADF Business Componentsは、Java EEの設計パターンとベスト・プラクティスを即座に実装できるようにします。
Oracle ADF Business Componentsは、データベース中心のビジネス・サービスの作成を簡略化するために次の主要なコンポーネントを提供しています。
エンティティ・オブジェクト
エンティティ・オブジェクトは、データベース表内の1行を表し、すべてのデータ操作言語(DML)操作を処理することでデータ変更を簡略化します。また、ビジネス・ロジックをカプセル化し、ビジネス・ルールが一貫して適用されることを保証します。開発者は、エンティティ・オブジェクトを他のエンティティ・オブジェクトと関連付け、基盤となるデータベース・スキーマの関係を反映することで、複数のアプリケーションで再使用できるビジネス・ドメイン・オブジェクトのレイヤーを作成します。
ビュー・オブジェクト
ビュー・オブジェクトはSQL問合せを表し、その結果の操作を簡略化します。開発者は、SQL言語を使用し、ユーザー・インタフェースで表されるエンド・ユーザーのタスクが必要とする形に、データを結合、計画、フィルタ、ソートおよび集約します。これには、ビュー・オブジェクトを他のエンティティ・オブジェクトにリンクし、複雑度に関係なくマスター/ディテール階層を作成する機能が含まれます。エンド・ユーザーがユーザー・インタフェースでデータを変更すると、ビュー・オブジェクトはエンティティ・オブジェクトと連携し、変更内容が一貫して検証され、保存されます。
アプリケーション・モジュール
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。
Oracle ADF Business Componentsの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
モデル・レイヤーでは、Oracle ADF Modelによって、データ・コントロールと呼ばれるJSR-227サービス抽象化が実装されます。データ・コントロールは標準のメタデータ・インタフェースを使用して、関係のあるプロパティ、メソッドおよびタイプに関する情報など、サービスの操作とデータ・コレクションを記述することで、ビジネス・サービスの実装テクノロジを抽象化します。Oracle JDeveloperでは、開発者はその情報をアイコンとして表示し、ページに簡単にドラッグ・アンド・ドロップできます。開発者がサービス表現をページにドラッグすると、Oracle JDeveloperによって、そのページからサービスへのバインディングが自動的に作成されます。実行時にADF Modelレイヤーによって、アプリケーションのデータ・コントロールおよびデータ・バインディングを記述した情報が該当するXMLファイルから読み取られ、ユーザー・インタフェースとアプリケーションのビジネス・サービス間の双方向接続が実装されます。
Oracle ADFは、最も一般的なビジネス・サービス・テクノロジに対し、すぐに実装可能なデータ・コントロールを提供します。ユーザー・インタフェースの構築にOracle JDeveloperとOracle ADFを併用すると、ドラッグ・アンド・ドロップを使用した宣言的なデータ・バインディングが可能になります。ADF Business Componentsアプリケーション・モジュールのサポートのほかに、ADF Modelは次のサービス・テクノロジに対するサポートも提供します。
Enterprise JavaBeans(EJB)のセッションBeanとJPAエンティティ
JavaBeans
Webサービス
XML
CSVファイル
Oracle ADF Modelの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
Webアプリケーションのページ・フロー処理が主な課題となるコントローラ・レイヤーでは、ADF Controllerは、拡張されたナビゲーションおよび状態管理モデルをJSFに追加する形で提供しています。JDeveloperは、ページ、マネージドBean上のメソッド、宣言的なcase文、他のタスク・フローへのコールなど、様々なタイプのアクティビティの間でアプリケーション制御を管理できるタスク・フローの宣言的な作成をサポートします。
Oracle ADF Controllerの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
ADF Faces Rich Client(略してADF Faces)は、AJAX機能が組み込まれた一連の標準JSFコンポーネントです。AJAXは、非同期JavaScript、動的HTML(DHTML)、XMLおよびXmlHttpRequest
通信チャネルを組み合せたものです。この組合せを使用すると、ページを全面的に再レンダリングしないでサーバーにリクエストを送信できます。AJAXでは、リッチ・クライアントのようなアプリケーションが標準のインターネット・テクノロジを使用できますが、JSFにはサーバー側のコントロールが用意されています。これにより、通常のAJAXアプリケーションで頻繁に見られる、大量のJavaScriptへの依存度が下がります。
ADF Facesには、100を超えるリッチ・コンポーネントが含まれています。これには、階層形式のデータ表、ツリー・メニュー、ページ内ダイアログ、アコーディオン、デバイダ、ソート可能な表などがあります。また、ADFデータ視覚化コンポーネントも用意されています。これはFlashやSVGに対応したコンポーネントであり、動的チャート、グラフ、ゲージなどのグラフィックをレンダリングし、基礎となるデータをリアルタイムで表示できます。各コンポーネントはカスタマイズやスキニングに加えて、国際化とアクセシビリティの機能もサポートしています。
これらのフロントエンド機能を実現するために、ADF Facesコンポーネントではレンダリング・キットが使用されます。このレンダリング・キットは、コンポーネントの表示を処理するだけでない、リッチ機能に必要なJavaScriptオブジェクトも提供します。これらは組込みでサポートされているため、開発者は、フロントエンドとバックエンドの個々のテクノロジについて豊富な知識がない場合でも、リッチ・アプリケーションの構築は可能です。
各コンポーネントのアーキテクチャと詳細情報など、ADF Facesの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』を参照してください。
Oracle ADFランタイムは、Oracle JDeveloperインストーラとOracle Fusion Middleware Application Developerインストーラのいずれかを使用してOracle WebLogic Serverにインストールできます。Application Developerインストーラを使用した場合は、Fusion Middleware Controlをオプションでインストールし、ドメイン内の全管理対象サーバーにWebベースの管理サポートを提供することもできます。Oracle JDeveloperインストーラを使用した場合は、Fusion Middleware Controlはインストールされません。これらのオプションは両方とも、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のデプロイメントの章で説明されています。
Application Developerインストーラを使用してOracle ADFランタイムをインストールすると、Middlewareホームの下にOracle Application Developerホーム・ディレクトリ(デフォルトではOracle_APPDEV1
)が作成されます。管理者は、ドメイン構成ウィザードを使用し、JRFドメイン・テンプレートに基づいてApplication Developerドメイン(base_domain
)を作成すると、サーバーのトポロジを構成できるようになります。通常の設定では、ドメインには、WLS管理コンソールとFusion Middleware Controlを含む管理サーバーが含まれています。通常は、ユーザー向けのカスタムFusion Webアプリケーションのほかに、Oracle ADFランタイムのライブラリ(Javaの必須ファイルの一部)が管理対象サーバーにデプロイされます。カスタマイズ機能およびパーソナライズ機能を提供するために、オプションのMDSリポジトリをインストールすることもできます。これは個別に構成する必要があります。図6-3は、Oracle ADFの基本的な単一ノード・アーキテクチャを示しています。
ドメインとサーバーの詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
Fusion WebアプリケーションでOracle Metadata Services(MDS)を使用したカスタマイズを行う場合は、アプリケーションをデプロイする前に、MDSリポジトリをOracle WebLogic Serverドメインに登録する必要があります。MDSの登録の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
次に、アプリケーションをデプロイすると、JDeveloperでは、ターゲット・メタデータ・リポジトリまたは共有メタデータ・リポジトリを選択するように求められます。ここでは、Oracle WebLogic管理サーバーに登録されているメタデータ・リポジトリのリストから選択できます。
メタデータ・リポジトリの選択が求められるようにするには、アプリケーションのadf-config.xml
ファイルのmds-config
セクションでcust-config
要素を定義する必要があります。この要素は、順序付けされ、名前が付けられたカスタマイズ・クラスのリストを指定します。カスタマイズ・クラスとは、ベース定義メタデータに適用するカスタマイズを定義するためにMDSが使用するインタフェースです。JDeveloperでは、adf-config.xml
ファイル用の概要エディタを使用してcust-config
要素を定義できます。
MDS用adf-config.xml
ファイルの構成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のMDSを使用したカスタマイズの章を参照してください。
MDSのアーキテクチャおよびメタデータ・リポジトリ(データベース・ベースとファイル・ベース)とアーカイブ(EAR、MAR)の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
Fusion Webアプリケーションで実行された操作は、アプリケーションが稼働しているWebLogic管理対象サーバーの次のログに直接記録されます。
DOMAIN_HOME
/servers/
server_name
/logs/
server_name
-diagnostic.log
別のWebLogic管理対象サーバーのログ・ファイルも、Oracle WebLogic Server管理コンソールで使用できます。ログを確認するには、Oracle WebLogic Server管理コンソールhttp://<admin_server_host>:<port>/console
にアクセスして、「診断-ログ・ファイル」をクリックします。
このログの粒度とロギング・プロパティは、Oracle Enterprise Manager Fusion Middleware Control(Fusion Middleware Control)を使用して変更できます。Fusion Middleware ControlはWebブラウザベースのグラフィカル・ユーザー・インタフェースで、ファームの監視および管理に使用できます。Oracle ADFに関する高可用性警告診断メッセージを受信するには、第6.1.4.3項「Oracle ADFのレプリケーションおよびフェイルオーバーに関する問題のトラブルシューティング」に説明されているように、レベルをFINE
に設定してください。
Fusion Webアプリケーションに指定できる診断レベルの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のテストとデバッグの章を参照してください。
Fusion Middleware Controlを使用したWebLogic管理対象サーバーとOracle ADFのログ設定の変更の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
Oracle ADFテクノロジ・スタック上に構築されるFusion Webアプリケーションは、Java EEアプリケーション(およびJ2EEアプリケーション)です。Fusion Webアプリケーションに対しても、高可用性環境にある他のJava EEアプリケーションと同じようなベスト・プラクティスを実践する必要があります。
バインディング・コンテナやマネージドBeanなどのADFオブジェクトは、実行時にインスタンス化されます。これらの各オブジェクトには、そのスコープ属性によって設定される存続期間が定義されています。
Fusion Webアプリケーションには次の6種類のスコープがあります。
アプリケーション・スコープ: このオブジェクトは、アプリケーションの継続期間中、利用できます。
セッション・スコープ: このオブジェクトは、セッションの継続期間中、利用できます。
ページ・フロー・スコープ: このオブジェクトは、バインド・タスク・フローの継続期間中、利用できます。
リクエスト・スコープ: このオブジェクトは、HTTPリクエストが発生してからレスポンスがクライアントに返送されるまでの間、利用できます。
バッキングBeanスコープ: ページ・フラグメントおよび宣言コンポーネントのみのマネージドBeanに使用されます。このオブジェクトは、HTTPリクエストが発生してからレスポンスがクライアントに返送されるまでの間、利用できます。
ビュー・スコープ: このオブジェクトは、現在のビュー・アクティビティのビューIDが変更されるまで利用できます。このスコープは、所定のページの値を保持するために使用できます。ただし、1つのページから次のページに必要な値を格納するために使用できるリクエスト・スコープとは異なり、ビュー・スコープに格納されたものはビューIDの変更とともに失われます。
Fusion Webアプリケーションをクラスタ環境で実行する場合は、アプリケーションの状態の一部がシリアル化され、各リクエストの終わりに別のサーバーまたはデータ・ストアにコピーされるため、クラスタ内の他のサーバーがこの状態を利用できるようになります。
クラスタ環境で実行するようにアプリケーションを設計している場合は、次の点が必要です。
1つのリクエストより存続期間が長いマネージドBeanがすべてシリアライズ可能である(つまり、java.io.Serializable
インタフェースを実装している)ことを確認します。具体的には、セッション・スコープ、ページ・フロー・スコープおよびビュー・スコープに格納されているBeanは、シリアライズ可能である必要があります。
ADFスコープ(ビュー・スコープおよびページ・フロー・スコープ)に格納されているマネージドBeanの変更をOracle ADFが認識していることを確認し、ADFメモリー・スコープに対する変更の追跡を有効にします。
ビュー・スコープとページ・フロー・スコープのいずれかで、マネージドBean内の値が変更された場合には、アプリケーションがOracle ADFに通知して、Beanの新しい値がレプリケートできるようにする必要があります。
例6-1では、ビュー・スコープ内のオブジェクトの属性が変更されます。
例6-1 viewScope内のオブジェクトを変更するコード
Map<String, Object> viewScope = AdfFacesContext.getCurrentInstance().getViewScope(); MyObject obj = (MyObject)viewScope.get("myObjectName"); Obj.setFoo("newValue");
コードを追加しないかぎり、Oracle ADFではこの変更を認識しないため、新しい値をクラスタ内でレプリケートする必要のあることがわかりません。ADFスコープ内のオブジェクトが変更されているためにレプリケーションが必要であることをOracle ADFに通知するには、例6-2に示すように、markScopeDirty()
メソッドを使用します。markScopeDirty()
メソッドは、viewScope
およびpageFlowScope
のみをパラメータとして受け入れます。
例6-2 オブジェクトの変更をOracle ADFに通知するための追加のコード
controllerContext ctx = ControllerContext.getInstance(); ctx.markScopeDirty(viewScope);
このコードは、ADFスコープのいずれかにある既存のオブジェクトを変更するリクエストに対して必要になります。スコープ自体がスコープのput()
メソッドremove()
またはclear()
メソッドによって変更された場合は、Oracle ADFに通知する必要はありません。
ADF ControllerがADFメモリー・スコープに対する変更を追跡し、サーバー・クラスタ内のページ・フロー・スコープおよびビュー・スコープをレプリケートできるようにするには、第6.1.3.3項「adf-config.xmlの構成」に説明されているように、adf-config.xml
ファイル内の<adf-scope-ha-support>
パラメータを有効にします。
ADFオブジェクト・スコープの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のFusionのページ・ライフサイクルに関する章を参照してください。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内でほかに利用可能なメンバーがリクエストを処理できます。
Fusion Webアプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。
アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できる。
ステートフル・アプリケーションに対し、第6.1.3項「高可用性のためのOracle ADFの構成」の説明に従って、状態のレプリケーションが正しく構成されている。
Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されている。
ハードウェア・ロード・バランサを使用する場合には、ロード・バランサが次のようになっていること。
利用可能なインスタンスすべてに対してトラフィックをルーティングしている
利用できないインスタンスをマークするように、状態モニターで正しく構成されている
セッションの状態の永続性をサポートするように構成されている
環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気がつきません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。
ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。
ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。
ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。
ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。
インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。
インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。
Fusionテクノロジ・スタックにはアクティブ・データ・サービス(ADS)が含まれています。このADSによって、ADF Modelレイヤーを使用してADF Facesコンポーネントをアクティブ・データ・ソースにバインドできます。JDeveloperでは、JSFページ内で個々のコンポーネントを構成し、アクティブ・データを表示します。アクティブ・データを使用するようにコンポーネントを構成すると、データ・ソースによって変更イベントが発生するたびにデータがクライアントにプッシュされます。データはサーバーからクライアントにプッシュされ、ブラウザで表示されます。
アクティブ・データを表示するように構成されているページに対してフェイルオーバーをサポートするには、ADF Business Componentsアプリケーション・モジュールのフェイルオーバーを有効にし、ADF ControllerがADFメモリー・スコープへの変更を追跡できるようにする必要があります。これらのADF設定を構成すると、フェイルオーバーの発生時にADFサーバーがフェイルオーバーを検出し、アクティブ・データを表示するように構成されているすべてのページに対し、ページをリフレッシュするように要求します。その後でADSが再起動し、データがクライアントにプッシュされます。
Fusion Webアプリケーションのフェイルオーバーを有効にする方法の詳細は、第6.1.3項「高可用性のためのOracle ADFの構成」を参照してください。
Oracle ADF Facesコンポーネントでのアクティブ・データ・サービスの使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のADSに関する章を参照してください。
冗長なデータベースやバックエンドとしてのOracle Real Application Clusters(Oracle RAC)など、可用性の高いデータベース・システムにアクセスするようにADFアプリケーション・モジュールを構成するときは、データ・ソースのコンテナが定義されている必要があります。このシナリオでは、マルチ・データ・ソースを使用する必要があります。ただし、アプリケーション・モジュールの構成の観点からは、マルチ・データ・ソースと非マルチ・データ・ソースでネーミング規則は同じになります。これによって、正しいデータ・ソースが実行時に使用されるようになります。高可用性アプリケーションに対するマルチ・データ・ソースの構成の詳細は、第4.1.3項「Oracle RACでのマルチ・データ・ソースの構成」を参照してください。
クラスタ環境内のWebアプリケーションに対して自動的なレプリケーションとフェイルオーバーをサポートするために、Oracle WebLogic Serverは、クラスタ間でHTTPセッションの状態をレプリケートするメカニズムをサポートしています。Fusion Webアプリケーションの状態をクラスタ内のどのサーバーからでもリストアできるようにOracle ADFを構成できます。
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。アプリケーション・モジュールによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。アプリケーション・モジュールは、そのトランザクション状態を非アクティブ化する、またはスナップショットとしてデータベースに格納することをサポートしています。また、これらの保存済スナップショットのいずれかからトランザクション状態をアクティブ化する逆の操作もサポートしています。
アプリケーション・モジュール状態の管理の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のFusion Webアプリケーションの状態管理の概要に関する項を参照してください。
ADF Business Componentsのフェイルオーバーのサポートを有効にするには、jbo.dofailover
パラメータをtrue
に設定し、アプリケーション・モジュールの状態が解放時に保存されるようにします。これによって、Oracle ADFは、前のチェックインで保存されたスナップショットからアプリケーション・モジュールの状態をリストアできるようになります。一方、フェイルオーバー機能がデフォルトにより無効のままになっている場合は、アプリケーションが後続のユーザー・セッションで再利用されたときと、アプリケーション・モジュール・プールが未使用のアプリケーション・モジュールを見つけられないときにのみ、アプリケーション・モジュールの状態が保存されます。
アプリケーション・モジュールの構成でこのパラメータを設定するには、「ビジネス・コンポーネント構成の編集」ダイアログの「プーリングおよびスケーラビリティ」タブを使用します。
高可用性のためのアプリケーション・モジュールを構成する手順は次のとおりです。
JDeveloperを起動してアプリケーションを開きます。
アプリケーション・ナビゲータで、データ・モデルを含むプロジェクトを展開し、アプリケーション・モジュールを探します。
アプリケーション・モジュールを右クリックし、「構成」を選択します。
「編集」をクリックします。
「プーリングおよびスケーラビリティ」タブをクリックします。
「管理された解放時にトランザクションの状態をフェイルオーバー」チェック・ボックスを選択します。
「OK」をクリックして「ビジネス・コンポーネント構成の編集」ダイアログを閉じます。
「OK」をクリックして「構成の管理」ダイアログを閉じます。
Oracle ADFの状態管理機能とその使用方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーションの状態管理に関する章を参照してください。
HTTPセッションの状態のレプリケートをサポートできるようにするには、Oracle WLS weblogic.xml
ファイルのpersistent-store-type
要素に値を割り当てる必要があります。replicated_if_clustered
の値により、有効な永続ストアのタイプがレプリケートされ、このサーバーの属するサーバーのクラスタに対して設定された値に従って、クラスタ環境のセッションが格納されるようになります。
高可用性を実現するためにweblogic.xml
ファイルを構成する手順は次のとおりです。
JDeveloperを起動してアプリケーションを開きます。
アプリケーション・ナビゲータで、Webアプリケーションを含むプロジェクトを展開し、WEB-INFフォルダを展開します。
weblogic.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。
ファイル内で、persistent-store-type
の定義をsession-descriptor
要素に追加します。
<weblogic-web-app> <session-descriptor> <persistent-store-type> replicated_if_clustered </persistent-store-type> </session-descriptor> </weblogic-web-app>
クラスタ環境で実行するアプリケーションを設計している場合は、ADFスコープ(ビュー・スコープおよびページ・フロー・スコープ)に格納されているマネージドBeanの変更をOracle ADFが認識していることを確認する必要があります。
ビュー・スコープとページ・フロー・スコープのいずれかで、マネージドBean内の値が変更された場合には、アプリケーションがOracle ADFに通知して、Beanの新しい値がレプリケートできるようにする必要があります。
ADF ControllerがADFメモリー・スコープに対する変更を追跡し、サーバー・クラスタ内のページ・フロー・スコープおよびビュー・スコープをレプリケートできるようにするには、アプリケーションのadf-config.xml
ファイル内のADF Controllerパラメータ<adf-scope-ha-support>
をtrue
に設定する必要があります。たとえば、アプリケーションにtrue
を設定した場合、そのアプリケーションがリクエスト中にページ・フロー・スコープでBeanの追加または削除を行うと、変更がクラスタ内で自動的にレプリケートされます。
adf-config.xml
は、すべてのADFコンポーネントの中核となる構成ファイルです。このファイルには、ADF ControllerなどのADFコンポーネントの実行時の動作を構成するためのセクションが含まれています。
高可用性を実現するためにadf-config.xml
ファイルを構成する手順は次のとおりです。
JDeveloperを起動してアプリケーションを開きます。
アプリケーション・ナビゲータで、「アプリケーション・リソース」を展開します。
「ディスクリプタ」を選択し、「ADF META-INF」ノードを選択します。
adf-config.xmlファイルをダブルクリックし、「ソース」タブをクリックしてファイルを編集します。
このファイルに次の行を追加します。
<adf-controller-config xmlns="http://xmlns.oracle.com/adf/controller/config"> <adf-scope-ha-support>true</adf-scope-ha-support> </adf-controller-config>
adf-config.xml
ファイルを使用したADFの構成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の複雑なタスク・フローの作成に関する章を参照してください。
この項では、Oracle ADFで発生する可能性のある問題のトラブルシューティング手順について説明します。
Fusion WebアプリケーションをOracle JDeveloperで開発する場合は、この統合開発環境によって、高可用性に関する問題を検出するためのサポートが提供されます。JDeveloperが発する警告は監査フレームワークによって生成され、JDeveloperのソース・エディタに表示するようにトリガーされます。エディタに表示される警告は、高可用性アプリケーションの監査ルールに基づきます。
JDeveloperがデフォルトにより有効にする高可用性監査ルールは次のとおりです。
「ADF Controller構成 - ADFスコープの高可用性が有効になっていません」は、adf-config.xml
ファイル内のadf-scope-ha-support
フラグがtrue
に設定されていないことを警告するのみです。この監査ルールは、<adf-controller-config>
要素がADFアプリケーションレベルの構成ファイル(adf-config.xml
)に存在する場合にのみ適用されます。
「ADFページ・フロー - スコープ・マップのBeanが変更されました」は、コードがBeanでsetterメソッドを呼び出す際、続いてControllerContext.markScopeDirty()
メソッドを呼び出さなかったことを開発者に警告します。この監査ルールは、adf-config.xml
ファイル内のadf-scope-ha-support
フラグがtrueに設定されている場合にのみ適用されます。
「ADFページ・フロー - EL Beanが変更されました」は、BeanをミューテーションするEL式をコードが評価する際、続いてControllerContext.markScopeDirty()
メソッドを呼び出さなかったことを開発者に警告します。この監査ルールは、adf-config.xml
ファイル内のadf-scope-ha-support
フラグがtrueに設定されている場合にのみ適用されます。
「ADFページ・フロー - マネージドBeanクラスはシリアライズ不可」は、マネージドBeanのviewScope
、pageFlowScope
またはsessionScope
に、シリアライズ不可のクラスが定義されていることを開発者に警告します。この監査ルールは、adf-config.xml
ファイル内のadf-scope-ha-support
フラグがtrue
に設定されている場合にのみ適用されます。
高可用性監査ルール設定は、JDeveloperの「設定」ダイアログを使用して変更できます。JDeveloperのツールバーで「ツール - 設定」を選択し、「監査 - プロファイル」の下にある「ADF Controller構成」または「ADFページ・フロー」を展開して、目的の監査ルールを選択します。
JDeveloperのツールバーで「ビルド - 監査 project.jpr」を選択して監査をトリガーすることもできます。
Fusion Webアプリケーションは、管理対象サーバーが最初に起動したときにデプロイされます。最初にOracle WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメントがすべて成功したことを確認します。
左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。
アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME
/servers/
server_name
/logs
ディレクトリに格納されています。一般的な問題には、次のようなものがあります。
データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。
適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。
フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります。
ウィンドウが閉じたか、または状態がリセットされた可能性がある。
画面のリセットが必要になった可能性がある。
アプリケーションがログオン画面にリダイレクトしている可能性がある。
次の手順は、状態のレプリケーションに関する問題のトラブルシューティングおよび診断を行う際のガイダンスです。
これがレプリケーションに関する既知の問題でないことを確認します。
予想される動作については、第6.1.2.2項「Oracle ADFのフェイルオーバーおよび予想される動作」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。
ロード・バランサの設定を確認します。
レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverのハードウェア・ロード・バランサの構成の詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。
クラスタのステータスを確認します。
クラスタのコンテキスト内でレプリケーションが発生します。フェイルオーバーが成功するには、クラスタの正常なメンバーが、ほかに少なくとも1つ使用可能である必要があります。クラスタのステータスは、次の2種類の方法のどちらかで確認できます。
Oracle WebLogic Server管理コンソールを使用してクラスタのステータスを確認します。左側のペインで「サーバー」をクリックします。クラスタ内のすべてのサーバーの状態を確認します。
weblogic.Adminユーティリティを使用してクラスタのステータスを確認します。weblogic.Adminコマンドは、特定のクラスタ内のすべてのサーバーの状態を問い合せるときに使用できます。次に例を示します。
$ java weblogic.Admin -url Adminhost:7001 -username <username> -password <password> CLUSTERSTATE -clustername Spaces_Cluster
次のようなメッセージが返されます。
There are 2 server(s) in cluster: Spaces_Cluster The alive servers and their respective states are listed below: Application Server---RUNNING Managed Server---RUNNING
クラスタ通信を確認します。
クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。
ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。
個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。
マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTest
を実行して、マルチキャストが正しく構成されていることを確認します。次に例を示します。
$ java utils.MulticastTest -H
Oracle WLSのアプリケーション構成を確認します。
Oracle WLSは、デフォルトではフェイルオーバーするように構成されていません。メモリー内のレプリケーションは、weblogic.xml
ファイルに次の適切な設定が含まれている場合にのみ行われます。
<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
replicatedのpersistent-store-typeも受け入れられます。この設定は、第6.1.3.2項「weblogic.xmlの構成」で説明されているように、JDeveloperで行うことができます。
Oracle ADF Business Componentsの構成を確認します。
Oracle ADFは、デフォルトではフェイルオーバーするように構成されていません。フェイルオーバーは、ADF Business Componentsの構成ファイル(bc4j.xcfg
)に次の適切な設定が含まれている場合にのみサポートされます。
<AppModuleConfig ... <AM-Pooling jbo.dofailover="true"/> </AppModuleConfig>
この設定は、第6.1.3.1項「アプリケーション・モジュールの構成」で説明されているように、JDeveloperの「ビジネス・コンポーネント構成の編集」ダイアログで行います。
Oracle ADF Controllerの構成を確認します。
Oracle ADFは、デフォルトでは、ADFオブジェクトに対する変更をADFメモリー・スコープ内にレプリケートするように構成されていません。ADFオブジェクトのレプリケーションは、ADFアプリケーションレベルの構成ファイル(adf-config.xml
)に次の適切な設定が含まれている場合にのみサポートされます。
<adfc:adf-controller-config> <adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support> </adfc:adf-controller-config>
この設定は、第6.1.3.1項「アプリケーション・モジュールの構成」で説明されているように、JDeveloperのソース・エディタで行います。
デフォルトのログ出力メッセージを確認します。
デフォルトでは、ADFのログには上位レベルのメッセージ(INFO
レベル)が表示されます。デフォルトのログ出力では、さらに詳細なログ・メッセージを有効にする必要なしに、シリアライズやレプリケーションに関する問題を報告することがよくあります。ログの詳細は、第6.1.1.4項「Oracle ADFのログ・ファイル」を参照してください。
ADF高可用性アプリケーションのログ・メッセージを有効にします。
ADFのログ出力を、高可用性のランタイム・メッセージを出力するように構成します。デフォルトでは、ADFのログには上位レベルのメッセージ(INFO
レベル)が表示されます。Fusion Middleware Controlでロギング・レベルをFINE
に設定して、ADF Controllerの高可用性の診断を有効にします。
有効にすると、adf-config.xml
ファイルにadfc:adf-scope-ha-support
が設定されていない場合に、ログ出力が警告を出力するようになります。ADFのログ出力の詳細は、第6.1.1.4項「Oracle ADFのログ・ファイル」を参照してください。
デバッグを有効にします。
サーバー・ログを調べて、管理対象サーバーの起動時に異常なメッセージがないか確認します。この確認は、管理対象サーバーがクラスタの他のメンバーを見つけられない場合に、特に必要です。サーバー・ログは、DOMAIN_HOME
/servers/
SERVER_NAME
/logs
ディレクトリに格納されています。
詳細な診断を行うには、DebugCluster
、DebugClusterAnnouncements
、DebugFailOver
、DebugReplication
、DebugReplicationDetails
の各フラグを有効にします。各フラグは、weblogic.Admin
ユーティリティを使用して次のように有効にできます。
$ java weblogic.Admin -url Adminhost:7001 -username <username> -password <password> SET -type ServerDebug -property DebugCluster true
コンポーネントの状態のシリアライズ・チェックを有効にします。
サーバーのチェックを有効にして、セッション属性でシリアライズ不能な状態コンテンツが検出されないようにします。このチェックは、デフォルトでは、実行時のオーバーヘッドを軽減するために無効になっています。シリアライズ・チェックは、Javaサーバーのシステム・プロパティorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION
によってサポートされます。
高可用性をテストするには、まず次のシステム・プロパティを使用してアプリケーション・サーバーを起動し、セッションおよびJSFの状態がシリアライズ可能であることを確認します。
-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=session,tree
JSFの状態がシリアライズ不能であることが検出された場合は、次のシステム・プロパティを使用してアプリケーション・サーバーを再起動し、コンポーネントとプロパティのフラグを有効にしてからテストを再実行します。
-Dorg.apache.myfaces.trinidad.CHECK_STATE_SERIALIZATION=all
これらはJavaシステム・プロパティであるため、アプリケーション・サーバーの起動時に指定する必要があります。
この項では、サンプルとして示したOracle ADFの高可用性デプロイメントを構成する方法について説明します。
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
次のリストは、この項で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middlewareが常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Fusion Middleware SOA Suiteがインストールされている場所を指します。
ORACLE_COMMON_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリ・ファイルおよびライブラリ・ファイルが含まれているOracleホームを指します。
DOMAINディレクトリ: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。
ORACLE_INSTANCE: Oracleインスタンスには、Oracle Web Cache、Oracle HTTP Server、Oracle Internet Directoryなどのシステム・コンポーネントが1つ以上含まれています。Oracleインスタンス・ディレクトリには、構成ファイル、ログ・ファイル、一時ファイルなどの更新可能ファイルが格納されています。
このディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。
ORACLE_BASE: /u01/app/oracle
MW_HOME(アプリケーション層): ORACLE_BASE
/product/fmw
WL_HOME: MW_HOME
/wlserver_10.3
ORACLE_HOME: MW_HOME
/adf
この手順は、Oracle Fusion Middlewareの一部であるスキーマのいずれかをADFアプリケーションで使用する必要がある場合にのみ必要になります。これは通常、ADFアプリケーションがMDSリポジトリを使用する場合に行います。その場合は、Oracle Fusion Middlewareをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareメタデータ・ストアをReal Application Clusters(Oracle RAC)データベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。
最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。
最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。
次のコマンドを使用してRCUを起動します。
RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
データベース・タイプ: Oracle Database
を選択します。
ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します: ADFDBHOST1VIRTUAL
ポート: データベースのポート番号: 1521
サービス名: データベースのサービス名を入力します: adfha.mycompany.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワードを入力します。
ロール: SYSDBA
「次へ」をクリックします。
次のメッセージを受信した場合は、「無視」または「停止」をクリックします。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、ADFHA
のように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。
次のスキーマを選択します。
AS共通スキーマ
Metadata Services
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
RCUのインストールの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。
サーバーが次の要件を満たしていることを確認します。
システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』で指定されている要件を満たしています。
この例ではポート7777を使用します。ポート7777を選択する場合には、ノード上のいずれのサービスでもこのポートが使用されていないことを確認します。このことを確認するには、次のコマンドを実行します。
UNIX: netstat -an | grep LISTEN | grep ":7777" Windows: netstat -an | findstr "LISTEN" | findstr ":7777"
ポート7777が使用中の場合には、別のポートを選択するか、またはこのポートを使用可能にします。
UNIXプラットフォームで、/etc/oraInst.loc
ファイルまたは/var/opt/oracle/oraInst.loc
ファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.loc
ファイルが存在していない場合には、この手順をスキップします。
Oracle Fusion Middleware 11g Webtier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンド./runInstaller
を実行します。
Windowsでは、setup.exe
をダブルクリックします。
「インベントリ・ディレクトリの指定」画面で、インベントリおよびユーザー・グループの場所を入力して「OK」をクリックします。
ダイアログに従ってroot
の特権アクションを実行し、「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、場所を次のように設定します。
/u01/app/oracle/product/11.1.1/ohs_1
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
「Oracle HTTP Server
」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。
「次へ」をクリックします。
コンポーネント詳細の指定画面で、次の値を入力します。
インスタンス・ホームの場所:
/u01/app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1
インスタンス名: ohs_instance1
OHSコンポーネント名: ohs1
「次へ」をクリックします。
「Web Tierポートの詳細の指定」画面で、次の操作を行います。
「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
Oracle HTTP Serverのポート番号を入力します。たとえば、7777
と入力します。
「次へ」をクリックします。
注意: ポートの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suite and Oracle Business Process Management Suiteインストレーション・ガイド』を参照してください。 |
「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。
「インストールの進行状況」画面で、次の操作を行います。
UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.sh
スクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。
「構成が完了しました」画面で、「終了」をクリックして終了します。
次の各項に記載されている情報を使用して、Oracle Fusion Middlewareコンポーネントをインストールします。
最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンについては、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。
アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。
UNIXプラットフォームで、/etc/oraInst.loc
ファイルまたは/var/opt/oracle/oraInst.loc
ファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.loc
ファイルが存在していない場合には、この手順をスキップします。
Oracle WebLogic Serverインストーラを起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、次のように入力します。
ORACLE_BASE
/product/fmw
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「JDKの選択」画面で、「Oracle JRockit 1.6.0_14 SDK」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
ORACLE_BASE
/product/fmw/wlserver_10.3
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。
Oracle Fusion MiddlewareのOracle ADFをインストールするには、Application Developerインストーラを使用し、アプリケーション層にあるすべてのノードで次の操作を行います。
Oracle Fusion MiddlewareのOracle Fusion Middleware 11g Application Developerインストーラを起動します。
On UNIX (Linux used in this example): APPHOST1> runInstaller On Windows: APPHOST1> setup.exe
Oracle Fusion Middleware 11g Application Developerインストーラで、JRE/JDKの場所を入力するように求められたら、第6.2.4.1項「Oracle WebLogic Serverのインストール」のOracle WebLogic Serverのインストールで作成したOracle SDKの場所を入力します。次に例を示します。
ORACLE_BASE/product/fmw/jrockit_160_14_R27.6.4-18
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
「ミドルウェア・ホーム」には、ORACLE_BASE
/product/fmw
と入力します。
「Oracleホーム・ディレクトリ」には、たとえばadf
のように、使用するディレクトリを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール 完了」画面で「終了」をクリックします。
注意: 第6.2.6項「WebLogic ServerのADFドメインを作成するためのAPPHOST1での構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareの最新のパッチ・セットなどの既知のパッチをMiddlewareホームに適用して、Oracle Fusion Middlewareを最新バージョンにしておいてください。最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。 |
Oracle WebLogic Server管理サーバーの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」を参照してください。
Middlewareホームのadf
ディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracleコンポーネントが格納されるドメインを作成します。
次のコマンドを使用して、MW_HOME
/common/bin
ディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。
APPHOST1> ./config.sh
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。
Oracle Enterprise Manager - 11.1.1.0
Oracle JRF - 11.1.1.0
「次へ」をクリックします。
「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択
JDKの選択: 「Oracle JRockit 1.6.0_14 SDK」を選択
「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「次へ」をクリックします。
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: APPHOST1
リスニング・ポート: 7001
SSLリスニング・ポート: NA
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。
管理対象サーバー名 | リスニング・アドレス | リスニング・ポート | SSLリスニング・ポート | SSL有効 |
---|---|---|---|---|
WLS_ADF1 | APPHOST1のホスト名 | 8889 | NA | 選択を解除 |
WLS_ADF2 | APPHOST2のホスト名 | 8889 | NA | 選択を解除 |
「次へ」をクリックします。
「クラスタの構成」画面で、次のクラスタを追加します。
名前: ADF_CLUSTER
クラスタ・メッセージング・モード: unicast
クラスタ・アドレス有効化: 空白のまま
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、クラスタに次のサーバーを割り当てます。
ADF_CLUSTER:
WLS_ADF1
WLS_ADF2
「次へ」をクリックします。
「マシンの構成」画面で、次の操作を行います。
デフォルトで表示されるLocalMachineを削除します。
「UNIXマシン」タブをクリックし、次のマシンを追加します。
名前 | ノード・マネージャのリスニング・アドレス |
---|---|
APPHOST1 | APPHOST1のホスト名 |
APPHOST2 | APPHOST2のホスト名 |
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。
APPHOST1: AdminServer
、WLS_ADF1
APPHOST2: WLS_ADF2
「構成のサマリ」画面で「作成」をクリックします。
ドメインの作成中画面で「完了」をクリックします。
この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーおよび管理対象サーバーに対してboot.properties
ファイルを作成します。
管理サーバーに対しては、次の手順を実行します。
次のディレクトリを作成します。
APPHOST1> mkdir -p MW_HOME
/wls/user_projects/domains/adfdomain/servers/AdminServer/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.properties
というファイルを作成し、そのファイルに次の行を入力します。
username=adminUser
password=adminUserPassword
次に例を示します。
username=weblogic password=weblogic
注意: 管理サーバーまたは管理対象サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
WLS_ADF管理対象サーバーに対しては、次の手順を実行します。
管理サーバーに対して作成したファイルをすべてのサーバーにコピーします。
APPHOST1> mkdir -p servers/WLS_ADF1 APPHOST1> mkdir -p servers/WLS_ADF1/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.properties
というファイルを作成し、そのファイルに次の行を入力します。
username=adminUser
password=adminUserPassword
次に例を示します。
username=weblogic password=weblogic
この項では、APPHOST1でシステムを起動する手順について説明します。
APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。
APPHOST1> cd ORACLE_BASE
/product/fmw/user_projects/domains/adfdomain/bin
APPHOST1> ./startWebLogic.sh
管理サーバーが適切に構成されていることを確認する手順は次のとおりです。
Webブラウザでhttp://VIP1:7001/console
にアクセスします。
管理者としてログインします。
管理対象サーバーとしてWLS_ADF1およびWLS_ADF2が表示されていることを確認します。
ADF_Clusterクラスタが表示されていることを確認します。
Enterprise Manager(http://VIP1:7001/em
)にアクセスできることを確認します。
この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。
ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。
APPHOST1でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、管理サーバー→「SSL」→「詳細」を選択します。
「ロックして編集」をクリックします。
プロンプトが表示されたら、変更内容を保存してアクティブ化します。
「ホスト名の検証」を「なし」に設定します。
「WLS_ADF1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
管理サーバーとWLS_ADF1管理対象サーバーを再起動します。
APPHOST2でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「WLS_ADF2」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
管理サーバーとWLS_ADF2管理対象サーバーを再起動します。
APPHOST1でノード・マネージャを起動するには、次の手順を実行します。
ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.sh
スクリプトを実行し、StartScriptEnabled
プロパティをtrue
に設定します。
OAHOST1> cd ORACLE_COMMON_HOME/common/bin APPHOST1> ./setNMProps.sh
注意: クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabled プロパティを使用する必要があります。 |
ノード・マネージャを起動します。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
APPHOST2に対し、WebLogic ServerとOracle ADFのインストール手順を繰り返します。第6.2.3項「WEBHOST1へのOracle HTTP Serverのインストール」の手順から始めてください。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。
次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST2に伝播します。
次のpack
コマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cd WL_HOME/common/bin
APPHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE
/product/fmw/user_projects/domains/adfdomain/
-template=adfdomaintemplate.jar
-template_name=adf_domain_template
次のscp
コマンドをAPPHOST1で実行し、前の手順で作成したテンプレート・ファイルをAPPHOST2にコピーします。
APPHOST1> scp adfdomaintemplate.jar
user
@node2:WL_HOME/common/bin
unpack
コマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。
APPHOST2> cd WL_HOME/common/bin
APPHOST2> ./unpack.sh
-domain=ORACLE_BASE
/product/fmw/user_projects/domains/adfdomain/
-template=adfdomaintemplate.jar
次の手順に従い、APPHOST2上の管理サーバーと管理対象サーバーに対してboot.properties
ファイルを作成します。
次のディレクトリを作成します。
APPHOST1> mkdir -pMW_HOME
/wls/user_projects/domains/adfdomain/servers/WLS_ADF2 APPHOST2> mkdir -pMW_HOME
/wls/user_projects/domains/adfdomain/servers/WLS_ADF2/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.properties
というファイルを作成し、そのファイルに次の行を入力します。
username=adminUser
password=adminUserPassword
次に例を示します。
username=weblogic password=weblogic
注意: 管理サーバーまたは管理対象サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
APPHOST2でノード・マネージャを起動するには、第6.2.7.4項「APPHOST1でのノード・マネージャの起動」の手順をAPPHOST2で繰り返します。
この項の手順を使用して、アプリケーションのレプリケーションを構成します。
クラスタリング要件
アプリケーションをOracle WebLogicクラスタにデプロイする必要があります。これによって、アプリケーションの複数インスタンスに、レプリケーション・チャネルが自動的に確立されます。
注意: ユニキャスト・クラスタでは、デフォルトのレプリケーション・チャネルは、各管理対象サーバーのリスニング・アドレスを使用して構成されています。そのため、リスニング・アドレスは、Any でリスニングするように構成するのではなく、特定のIPアドレスまたはホスト名となるように構成する必要があります。 |
Oracle ADFのレプリケーション
Oracle ADFが適切に構成されていることが重要です。ステートフル・アプリケーションの場合には、アプリケーション・リソースの1つであるadf-config.xml
ファイルに、次のタグが存在している必要があります。
<adfc:adf-controller-config><adfc:adf-scope-ha-support>true</adfc:adf-scope-ha-support></adfc:adf-controller-config>
アプリケーションでは、レプリケーションも有効化されている必要があります。Oracle WebLogic Serverでは、レプリケーションのために様々な種類の永続ストアを使用できます。永続ストアの詳細は、『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』を参照してください。
ADFアプリケーションのレプリケーションをデフォルトで有効にするには、weblogic.xml
ファイルで次の設定を行います。
<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
replicated_if_clustered
設定は、スタンドアロン・アプリケーション環境のレプリケーションを無効にし、クラスタ環境内のメモリー内レプリケーションを使用します。
メモリー内レプリケーションに任意のカスタム・アプリケーションが構成されていることを確認します。
クラスタを設定すると、ADFアプリケーションをデプロイできるようになります。次の点に注意してください。
管理サーバー・コンソールを使用して、ADFアプリケーションをEARファイルにデプロイします。
デプロイメントがクラスタに対して行われるようにします。
アプリケーションがMDSを使用する場合は、『Oracle Fusion Middleware管理者ガイド』のデータベース・ベースのMDSリポジトリの登録に関する項の指示に従って、MDSをドメインに登録します。
Oracle WebCenter管理対象サーバーを含む管理サーバーへのOracle HTTP Serverのルーティングを有効にするには、WebLogicCluster
パラメータをクラスタ内のノードのリストに設定します。次の手順を実行します。
OHS_HOME
/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.conf
ファイルに次の行を追加します。
# Spaces <Location /applicationMountpoint> WebLogicCluster apphost1.com:8888,apphost2.com:8889 SetHandler weblogic-handler </Location>
WEBHOST1上のOracle HTTP Serverを再起動します。
WEBHOST1> OHS_HOME
/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1
URLを検証し、HTTP ServerからOracle WebCenterクラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。次の手順を実行します。
WebLogic Server管理コンソールから、WLS_Spaces1
、WLS_Spaces2
、WLS_Services1
、WLS_Services2
、WLS_Portlet1
およびWLS_Portlet2
を次のように起動します。
次のURLの管理コンソールにアクセスします。
http://APPHOST1/console
管理対象サーバーのいずれか(例: WLS_Spaces1
)をクリックします。
「制御」タブを選択します。
「起動」を選択して管理対象サーバーを起動します。
管理対象サーバーごとに前の手順を繰り返します。
次のURLを使用して、管理対象サーバーへの直接アクセスを検証します。
apphost1:8888/applicationMountpoint apphost2:8888/applicationMountpoint apphost1:8889/applicationMountpoint apphost2:8889/applicationMountpoint
WLS_ADF2
の稼働中に、Oracle WebLogic Server管理コンソールからWLS_ADF1
を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/applicationMountpoint
WebLogic Server管理コンソールからWLS_ADF1
を起動します。
WLS_ADF2
を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost2:7777/applicationMountpoint
この項では、Oracle WebCenterの高可用性クラスタを設計するために必要な課題および考慮事項を紹介します。
Oracle WebCenterは、Java Server Faces(JSF)の標準ベースの宣言的な開発と、ポータルの柔軟性と能力、および一連の統合型Web 2.0サービスを組み合せたものです。
図6-4は、Oracle WebCenterアプリケーションとそれに関連するコンポーネント、ポートレットおよびサービスを示しています。
Oracle WebCenterのコンポーネントは次のとおりです。
Oracle WebCenter Spacesは、一連の堅牢なサービスとアプリケーションにより、ソーシャル・ネットワーキング、通信、コラボレーションおよび個人の生産性に対して、単一の統合されたWebベース環境を提供します。
WebCenter Spacesは、JSF、Oracle ADF、WebCenter Framework、WebCenterサービスおよび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管理者ガイドを参照してください。
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の基本的な単一ノード・アーキテクチャを示しています。
Oracle WebCenter SpacesはJava EEアプリケーションとして実行され、アプリケーションの状態と構成はMDSリポジトリに永続的に残ります。アプリケーション内のユーザー・セッション情報は、ローカルのメモリー内に保持されます。クラスタ環境では、この状態はクラスタの他のメンバーにレプリケートされます。
ポートレット環境またはサービス環境内のカスタマイズは、そのサービスによって永続的に残ります。Oracleポートレットおよびユーザーが構築するカスタム・ポートレット、ディスカッション・サーバーおよびWikiサーバーをすぐに利用できます。これらにはいずれも、独自のデータベース永続性メカニズムが備わっています。
表6-1は、WebCenterのコンポーネントおよびサービスそれぞれのアクセス・タイプを示しています。「構成」列には、接続を構成または初期化するためにOracle WebCenterに提供されている情報のタイプが一覧表示されています。「アクセス」列には、サービスのランタイム・アクセスで使用するプロトコルが一覧表示されています。
ディスカッション・サーバーとWiki/ブログ・サーバーも、Oracle WebCenterに対するサービス・プロバイダです。Oracleポートレットも、サービスとしてポートレット・プロデューサを公開します。
これらのサービスが使用できなくてもOracle WebCenter Spacesアプリケーションが起動できなくなることはありませんが、実行中にアプリケーション・エラーが発生する場合があります。例外は、MDSリポジトリです。WebCenter Spacesは、MDSリポジトリがないと動作しません。WebCenterデータベースがMDSリポジトリとは異なる物理データベースである場合は、WebCenterデータベースがなくてもWebCenter Spacesは部分的に動作します。
表6-1 Oracle WebCenterのアクセス・タイプ
外部サーバー/サービス | 構成 | アクセス |
---|---|---|
ディスカッション・サーバー |
ディスカッション・サーバー管理へのHTTPアクセス |
SOAP/HTTP |
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のフレームワークは、外部サービスに対して単一のアクセス・ポイントを提供します。
たとえば、HTTPサービスでは、アクセスURLをロード・バランサにダイレクトします。ロード・バランサは、バックエンドで複数のサービス・プロバイダへのアクセスを提供します。
高可用性のためにOracle WebCenterディスカッション・サーバーおよびOracle Wiki and Blogサーバーを構成する手順は、第6.4.5項「WebLogic ServerのWebCenterドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」で説明されています。
MDSリポジトリおよびスキーマに対しては、バックエンド・データベースとしてOracle Real Application Clusters(Oracle RAC)データベースを使用することをお薦めします。I
データベース・プロバイダとしてOracle RACを構成する手順は第6.4.5項「WebLogic ServerのWebCenterドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」で説明されています。
Oracle RACおよびMDSリポジトリでのマルチ・データソースの構成の詳細は、第4.1.2項「Oracle RACでのマルチ・データソースの使用」を参照してください。
WebCenterアプリケーションの主要な構成ファイルは、表6-2に一覧表示および説明されています。これらのファイルは両方とも、WebCenterアプリケーション・デプロイメントの.EARファイルに含まれています。
表6-2 Oracle WebCenterの構成ファイル
アーティファクト | 用途 |
---|---|
|
WebCenterアプリケーションがどのディスカッション・サーバーまたはメール・サーバーを現在使用しているかなど、Application Development Framework(ADF)およびWebCenterアプリケーションの設定に関する基本構成を格納します。 |
|
外部サービスへの接続に関する基本構成を格納します。 |
WebCenterアプリケーションとポートレット・プロデューサは両方とも、Oracle Metadata Services(MDS)リポジトリを使用してその構成データを格納し、MDSリポジトリにはOracle WebLogicフレームワーク内のJDBCデータソースとしてアクセスします。
MDSリポジトリには、WebCenterアプリケーションおよびポートレット・プロデューサのデプロイメント後の構成の変更が、カスタマイズとして格納されます。MDSは、元のデプロイ済バージョンのadf-config.xml
とconnection.xml
をベース・ドキュメントとして使用し、その後のカスタマイズはすべて、単一のカスタマイズ・レイヤーを使用してMDSに個別に格納します。
WebCenterアプリケーションが起動すると、MDSに格納されているカスタマイズが適切なベース・ドキュメントに適用され、WebCenterアプリケーションは、マージ済ドキュメント(カスタマイズが適用されたベース・ドキュメント)を構成プロパティの最終セットとして使用します。
サーバー・クラスタにデプロイされているWebCenterアプリケーションの場合、クラスタの全メンバーは、MDSリポジトリ内の同じ場所から読取りを行います。
通常は、adf-config.xml
やconnection.xml
などのファイルに対するベース・ドキュメント(またはMDSカスタマイズ・データ)の内容を管理者が調べたり、手動で変更する必要はありません。デプロイメント後の構成を行うための管理ツールがいくつか用意されているためです。詳細は、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(キャッシュ・データの使用)に設定します。
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
ファイルで変更できます。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内の別のメンバーがリクエストを処理できます。
Oracle WebCenterデプロイメント内の管理対象サーバーはそれぞれ、クラスタとしてデプロイでき、複数のクラスタ・メンバーは、同じノードまたは異なるノードに配置できます。図6-6では、クラスタに送信されたリクエストはすべて、クラスタのメンバーのいずれかによって同等に処理されます。
次の各項では、Oracle WebCenterクラスタのランタイムと構成の両面に関して詳細に説明します。
Oracle WebCenterのインストール時、管理対象サーバーは、システム・ライブラリおよびADFライブラリにプロビジョニングされます。表6-4は、管理対象サーバーと、それらの管理対象サーバーで稼働するアプリケーションを一覧表示しています。
管理対象サーバーが起動すると、アプリケーションとライブラリは次の順序で起動します。
Oracleシステム・ライブラリ(別名、JRFライブラリ)
Oracle ADFライブラリ
インスツルメンテーション・アプリケーション(Oracle DMSなど)
表6-1に示すWebCenterアプリケーション
起動順序は依存性の順序でもあります。依存コンポーネントが正しくデプロイされないと、その後のコンポーネントが正しく機能しない場合があります。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』を参照してください。
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の状態のレプリケーション」を参照してください。
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オブジェクト・キャッシュの構成」を参照してください。
Oracle WebLogicクラスタによって、アプリケーションの高可用性が実現します。クラスタのメンバーのいずれかが利用できなくなった場合、そのクラスタ内で他に利用可能なメンバーがリクエストを処理できます。
WebCenterアプリケーションでシームレスなフェイルオーバーを実現するために、アプリケーションは次の条件を満たす必要があります。
アプリケーションがクラスタ内にあり、アプリケーション・クラスタの少なくとも1つのメンバーが、リクエストへの対応に利用できる。
ステートフル・アプリケーションに対し、第6.4.15項「Oracle ADFのレプリケーションの構成」の説明に従って、状態のレプリケーションが正しく構成されている。
Oracle HTTP Serverを使用している場合は、WebLogicClusterディレクティブを使用して、すべての使用可能なアプリケーション・インスタンス間でバランスが取られるようにサーバーが構成されている。
ハードウェア・ロード・バランサを使用する場合には、ロード・バランサが次のようになっていること。
利用可能なインスタンスすべてに対してトラフィックをルーティングしている
利用できないインスタンスをマークするように、状態モニターで正しく構成されている
セッションの状態の永続性をサポートするように構成されている
環境が正しく構成されている場合には、クラスタ内のアプリケーション・インスタンスがいつ使用できなくなったか、アプリケーション・ユーザーは気がつきません。たとえば、アプリケーション・フェイルオーバーにおけるイベントの順序は次のようになります。
ユーザーがリクエストを行い、ハードウェア・ロード・バランサによって、アプリケーションのインスタンスAにルーティングされます。
ノード、プロセスまたはネットワークに障害が発生したため、アプリケーションのインスタンスAが使用できなくなります。
ハードウェア・ロード・バランサによって、インスタンスAが使用不可とマークされます。
ユーザーが後続のリクエストを行います。このリクエストがインスタンスBにルーティングされます。
インスタンスBがインスタンスAのレプリケーション・パートナとして構成され、ユーザーのセッションの状態が格納されます。
インスタンスBのセッションの状態を使用してアプリケーションが再開し、ユーザーは中断されることなく、引き続き操作します。
予想される動作に対する例外
Oracle WebCenterでは、これらの予想される動作に対する既知の例外は次のとおりです。
Oracle ADFのポップアップ: 開いているポップアップがフェイルオーバー時に閉じます。これは、通常は例外のない多くのコンポーネントに影響を及ぼします。影響を受けるコンポーネントは次のとおりです。
Oracle Composer(プロパティ・インスペクタのポップアップ)
リスト
リンク(リンク削除のポップアップ)
フェイルオーバーが発生した場合、ポップアップを再表示するには、そのポップアップを表示する原因となったアクションを繰り返す必要があります。これがWebCenter Spacesに表示される具体的な方法および推奨される処置は、表6-6に一覧表示されています。
表6-6 Oracle WebCenterのトラブルシューティングのシナリオ
フェイルオーバー前のアクション | フェイルオーバー後 | 推奨される処置 |
---|---|---|
任意のページにアクセスして「ページの作成」をクリックします。 |
名前を入力し、テーマを選択して「OK」をクリックします。テーマを選択すると、ページ作成ポップアップが閉じます。 |
この操作を繰り返します。 |
「ページの管理」を起動します。 |
ポップアップ内で、ポップアップを閉じること以外の操作を実行します。たとえば、「ページ・アクション」をクリックします。任意の操作を実行すると、「ページの管理」ポップアップが閉じます。 |
この操作を繰り返します。 |
「ページの管理」を起動し、ページに対して「ページ・アクション」をクリックしてから、メニュー内の「削除」オプションをクリックします。 |
確認ポップアップで「OK」をクリックします。「OK」をクリックすると、確認ポップアップが閉じるだけでなく、「ページの管理」ポップアップもリクエストの一部として閉じ、(行われた可能性のある)削除の効果はタブには表示されません。 |
「ページの管理」ポップアップを再起動し、ページが削除されているかどうかを確認します。削除されていない場合は、もう一度削除してみます。 |
「アプリケーションのパーソナライズ」ポップアップを起動します。「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。 |
「OK」をクリックすること以外の、リクエストを送信する操作を実行します。たとえば、「アプリケーション」ノードを開きます。リクエストをサーバーに送信する任意の操作を実行すると、「アプリケーションのパーソナライズ」ポップアップが閉じます。 |
この操作を繰り返します。 |
「プリファレンス」を起動します。 |
「プリファレンス」のタブ(「一般」、アカウント、「メッセージング」、「検索」)間の切替えを行います。「プリファレンス」のタブ間で切替えを行うと、「プリファレンス」ポップアップが閉じます。 |
この操作を繰り返します。 |
「お気に入りの管理」を起動します。サーバーを停止し、ポップアップを閉じること以外の操作を実行します。たとえば、フォルダを開いてお気に入り情報の編集をクリックします。 |
ポップアップを閉じること以外の操作を実行します。たとえば、フォルダを開いてお気に入り情報の編集をクリックします。任意の操作を実行すると、「お気に入りの管理」ポップアップが閉じます。 |
「お気に入りの管理」ポップアップを再起動し、操作が正常に実行されたかどうかを確認します。正常に実行されなかった場合は、この操作を再試行します。 |
アプリケーションの編集と新しいフォルダの作成を選択します。 |
MDS例外が表示されます。 |
この操作を再試行します。 |
コンポーネント固有の問題: Oracle WebCenterの各コンポーネントに固有の他の問題は、表6-7に一覧表示されています。
表6-7 Oracle WebCenterでの予想される動作に対する例外
Oracle WebCenterコンポーネント | 予想される動作に対する例外 |
---|---|
グループ・スペース・イベント |
特定のフィールド(開始または終了の日/時/分)を変更すると、フェイルオーバーの発生時にイベント・フォームが閉じます。 |
ポートレット |
障害は完全に透過的です。 |
リスト |
障害は完全に透過的です。 |
リンク |
障害は完全に透過的です。 |
検索 |
長時間実行される問合せの最中。戻される結果は保証されません(ここでは書込み操作は存在しないことに注意)。ユーザーは問合せを再発行できます。 |
タグ付け |
障害は完全に透過的です。 |
最近のアクティビティ |
ツリー・ノードのオープン/クローズ状態はレプリケートされません。フェイルオーバー後、結果のツリーによってノードがすべて閉じます。ノードは開きなおす必要があります。 |
ワークリスト |
障害は完全に透過的です。 |
ドキュメント・マネージャ |
ユーザーがドキュメントをアップロードしたときに、同じ名前のドキュメントがすでに存在している場合は、「新規バージョンの確認」画面が表示されます。その画面の表示中、ファイルは一時的なローカルの場所に格納されます。そのときにフェイルオーバーが発生すると、アップロードしたファイルは失われ、ユーザーはアップロード・プロセスを再実行する必要があります。 |
Oracle WebLogic Server管理コンソールを使用して、アプリケーション・デプロイメントのステータスを確認します。また、Oracle WebCenterプロセスの開始、停止および監視には、Oracle WebLogic ServerインフラストラクチャとEnterprise Manager Fusion Middleware Controlも使用できます。
WebCenter Spacesとポートレット・プロデューサの場合、すべての構成データはMDSリポジトリおよびポートレット・プロデューサに格納されます。アプリケーションの起動時には、追加のクラスタ・デプロイメントによって、最新の構成が自動的に読み取られます。
Oracleディスカッション・サーバーの場合、構成情報は既存のクラスタ・サーバーから移動する必要があります。これは、Oracle WebLogic Serverのpack/unpackユーティリティによって自動的に行われます。これがお薦めする手順です。
Oracle WebCenter Wiki and Blogサーバーの場合、ほとんどの構成はデータベースに格納されますが、デプロイメント・ディレクトリ内のカスタム・テンプレートに固有の構成もあります。クラスタ・インストールでは、クラスタ内のすべてのWiki and Blogサーバーがこのデプロイメント・ディレクトリを共有する必要があります。
WebCenter Spacesとポートレット・プロデューサの場合、すべての構成データはMDSリポジトリおよびポートレット・プロデューサに格納されます。クラスタ内の1つのサーバーの構成に対して行われた変更は、他のすべてのメンバーにただちに表示されます。
Oracle WebCenterディスカッション・サーバーは頻繁に変更されませんが、変更された場合は、変更をクラスタの他のメンバーに再適用する必要があります。再適用するには、ロード・バランサを使用するかわりに各ディスカッション・サーバーに直接接続し、必要な管理変更を行います。
Oracle Wiki and Blogサーバーの場合、その構成はデータベースおよびローカルのデプロイメント・ディレクトリに保持されます。構成はノードごとに適用する必要があります。
図6-6は、1つのWebLogic Serverドメイン内の2つのOracle WebLogic Serverで、2ノードのOracle WebCenterクラスタが稼働している状況を示しています。Oracle WebLogic Serverは、それらのサーバーへの受信リクエストをロード・バランシングするOracle HTTP Serverによってフロントエンド処理されます。メタデータとスキーマの格納にはOracle RACデータベースが使用されます。Oracle Wiki and Blogサーバーの共有構成には共有記憶域が使用されます。管理サーバーにはVIPが使用されます(手動フェイルオーバー用)。
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
注意: コマンド例はすべて、Kシェルまたはbashシェルに対するものです。Cシェルの例は提供されていません。 |
次の各項では、Oracle WebCenterの高可用性構成を設定する前に必要となる手順について説明します。
プラットフォーム固有のコマンドの詳細は、『Oracle Fusion Middleware Oracle WebCenterインストレーション・ガイド』を参照してください。
Oracle WebCenterでは、サポートされているデータベースおよびスキーマが存在している必要があります。
データベースが動作保証されているかどうかを確認するか、または動作保証されたデータベースをすべて表示するには、次の動作保証ドキュメントで、動作保証されたデータベースに関する項を参照してください。
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
データベースのバージョンを調べるには、次の問合せを実行します。
SQL>select version from sys.product_component_version where product like 'Oracle%';
次の項では、データベース・リポジトリをインストールおよび構成する方法について説明します。
Oracle Clusterware
10gリリース2(10.2)については、Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersのインストレーション・ガイドを参照してください。
11gリリース1(11.1)以降については、『Oracle Clusterwareインストレーション・ガイド』を参照してください。
自動ストレージ管理
10gリリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11gリリース1(11.1)以降については、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。
インストーラを実行するときは、構成の選択ページで「自動ストレージ管理の構成」オプションを選択して、個別の自動ストレージ管理ホームを作成します。
Oracle Real Application Cluster
10gリリース2(10.2)については、『Oracle Database Oracle ClusterwareおよびOracle Real Application Clustersインストレーション・ガイド』を参照してください。
11gリリース1(11.1)以降については、『Oracle Real Application Clustersインストレーション・ガイド』を参照してください。
Oracle Fusion Middlewareのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clusterデータベースにインストールする必要があります。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。RCUは、専用のMiddlewareホームにインストールします。
最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。
最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
データベースの初期化パラメータ
次の初期化パラメータが、必要な値に設定されていることを確認します。この値は、リポジトリ作成アシスタントによってチェックされます。
SQL*Plusを使用して初期化パラメータの値をチェックするには、SHOW PARAMETERコマンドを次のように使用します。
SYSユーザーとして、SHOW PARAMETERコマンドを次のように発行します。
SQL> SHOW PARAMETER processes
次のコマンドを使用して初期化パラメータを設定します。
SQL> ALTER SYSTEM SET processes=300 SCOPE=SPFILE
データベースを再起動します。
注意: パラメータの値を変更する方法は、パラメータが静的か動的かによって異なり、データベースがパラメータ・ファイルとサーバー・パラメータ・ファイルのどちらを使用しているかによっても異なります。パラメータ・ファイルとサーバー・パラメータ・ファイルの詳細、およびパラメータ値の変更方法は、『Oracle Database管理者ガイド』を参照してください。 |
本番環境では、Oracle WebCenterの高可用性トポロジに外部のLDAPポリシー・ストアが必須です。サポートされているポリシー・ストアの詳細およびLDAPの構成手順は、『Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter』を参照してください。
次のリストは、この項で使用するディレクトリと変数について説明しています。
ORACLE_BASE: この環境変数および関連するディレクトリ・パスは、Oracle製品がインストールされているベース・ディレクトリを指します。
MW_HOME: この環境変数および関連するディレクトリ・パスは、Fusion Middleware(FMW)が常駐している場所を指します。
WL_HOME: この環境変数および関連するディレクトリ・パスには、WebLogic Serverをホストするために必要なインストール済ファイルが含まれています。
ORACLE_HOME: この環境変数および関連するディレクトリ・パスは、Oracle WebCenter がインストールされている場所を指します。
ORACLE_COMMON_HOME: この環境変数および関連するディレクトリ・パスは、Oracle Enterprise Manager Fusion Middleware ControlおよびJava Required Files(JRF)に必要なバイナリ・ファイルおよびライブラリ・ファイルが含まれているOracleホームを指します。
DOMAIN_HOME: このディレクトリ・パスは、Oracle WebLogicドメイン情報(構成アーティファクト)が格納されている場所を指します。
このディレクトリで一貫性を保つために使用することをお薦めする値は、次のとおりです。
ORACLE_BASE:
/u01/app/oracle
MW HOME(アプリケーション層):
ORACLE_BASE/product/fmw
WL_HOME:
MW_HOME/wlserver_10.3
ORACLE_HOME:
MW_HOME/WC1
ORACLE_COMMON_HOME:
MW_HOME/oracle_common
Oracle Fusion Middleware WebCenterのコンポーネントをインストールする前に、11g(11.1.1)Oracle Fusion Middlewareのメタデータ・ストアとWebCenterスキーマをReal Application Clusterデータベースにインストールします。Oracle Fusion Middlewareには、既存のデータベースにコンポーネント・スキーマを作成するためのツールであるOracle Fusion Middlewareリポジトリ作成ユーティリティ(RCU)が用意されています。
最新バージョンのRCUを使用して、11g(11.1.1)Oracle Fusion MiddlewareリポジトリをReal Application Clustersデータベースにインストールします。
最新バージョンのRCUの取得および実行の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
RCUを実行して、Oracle Fusion Middleware 11gに必要なメタデータをインストールします。
次のコマンドを使用してRCUを起動します。
RCU_HOME/bin/rcu &
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で、「作成」を選択してコンポーネント・スキーマをデータベースにロードし、「次へ」をクリックします。
「データベース接続の詳細」画面で、データベースの接続情報を入力します。
データベース・タイプ: Oracle Databaseを選択します。
ホスト名: データベースを実行しているノードの名前を入力します。Oracle RACデータベースの場合は、VIP名を指定するか、またはノード名のいずれかをホスト名として指定します: WCDBHOST1VIRTUAL
ポート: データベースのポート番号: 1521
サービス名: データベースのサービス名を入力します: wcha.mycompany.com
ユーザー名: SYS
パスワード: SYSユーザーのパスワードを入力します。
ロール: SYSDBA
「次へ」をクリックします。
次の警告メッセージを受信した場合は、「無視」または「停止」をクリックします。
接続先のデータベースには非UTF8 charsetが含まれています。このデータベースを使用して複数言語のサポートを求める場合、データが失われることがあります。複数言語のサポートを求めない場合は続行できます。求める場合は、UTF-8データベースを使用することを強くお薦めします。
「コンポーネントの選択」画面で「接頭辞の新規作成」を選択し、WCHAのように、データベース・スキーマに使用する接頭辞を入力します。
後の手順で利用できるように、このスキーマ名を書き留めておきます。
次のスキーマを選択します。
AS共通スキーマ:
Metadata Services
WebCenterインフラストラクチャ:
WebCenter Suite
「次へ」をクリックします。
「スキーマ・パスワード」画面で、主要なスキーマ・ユーザーおよび追加(補助)のスキーマ・ユーザーのパスワードを入力して「次へ」をクリックします。
「表領域のマップ」画面で、選択したコンポーネントの表領域を選択して「次へ」をクリックします。
「サマリー」画面で「作成」をクリックします。
「完了サマリー」画面で「閉じる」をクリックします。
RCUの使用の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。
WEBHOST1にOracle HTTP Serverをインストールする手順は次のとおりです。
サーバーが次の要件を満たしていることを確認します。
システム、パッチ、カーネルなどの要件が、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』で指定されている要件を満たしています。
この例ではポート7777を使用します。ポート7777を選択する場合には、ノード上のいずれのサービスでもこのポートが使用されていないことを確認します。このことを確認するには、次のコマンドを実行します。
UNIX:
netstat -an | grep LISTEN | grep ":7777"
Windows:
netstat -an | findstr "LISTEN" | findstr ":7777"
ポート7777が使用中の場合には、別のポートを選択するか、またはこのポートを使用可能にします。
UNIXプラットフォームで、/etc/oraInst.loc
ファイルまたは/var/opt/oracle/oraInst.loc
ファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.loc
ファイルが存在していない場合には、この手順をスキップします。
Oracle Fusion Middleware 11g Webtier Utilities CDインストールのOracle Universal Installerを、次のように開始します。
UNIXでは、コマンド./runInstaller
を実行します。
Windowsでは、setup.exeをダブルクリックします。
「インベントリ・ディレクトリの指定」画面で、インベントリおよびユーザー・グループの場所を入力して「OK」をクリックします。
ダイアログに従ってrootの特権アクションを実行し、「OK」をクリックします。
「ようこそ」画面で「次へ」をクリックします。
「インストール・タイプの選択」画面で、「インストールと構成」を選択して「次へ」をクリックします。
「前提条件のチェック」画面で、前提条件がすべて満たされていることを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、場所を次のように設定します。
/u01/app/oracle/product/11.1.1/ohs_1
「次へ」をクリックします。
「コンポーネントの構成」画面で、次の操作を行います。
「Oracle HTTP Server」を選択します。
「選択されたコンポーネントとWebLogicドメインの関連付け」は選択しないでください。
「次へ」をクリックします。
「コンポーネントの詳細の指定」画面で、次の値を入力します。
インスタンス・ホームの場所: app/oracle/product/11.1.1/ohs_1/instances/ohs_instance1
インスタンス名: ohs_instance1
OHSコンポーネント名: ohs1
「次へ」をクリックします。
「Web Tierポートの詳細の指定」画面で、次の操作を行います。
「カスタム・ポートを指定」を選択します。カスタム・ポートを指定する場合には、「構成ファイルを使用してポートを指定」を選択してから、「参照」機能を使用してファイルを選択します。
Oracle HTTP Serverのポート番号を入力します。たとえば、7777と入力します。
「次へ」をクリックします。
注意: ポートの設定の詳細は、『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』を参照してください。 |
「次へ」をクリックします。
「構成サマリー」画面で、選択内容が正しいことを確認して「インストール」をクリックします。
「インストールの進行状況」画面で、次の操作を行います。
UNIXシステムでは、ダイアログ・ボックスが表示され、oracleRoot.sh
スクリプトを実行するように求められます。コマンド・ウィンドウを開き、表示される指示に従ってスクリプトを実行します。
「次へ」をクリックします。
「構成」画面で、いくつかの構成アシスタントが連続して開始されます。構成アシスタントが終了すると、「構成が完了しました」画面が表示されます。
「構成が完了しました」画面で、「終了」をクリックして終了します。
次の手順を使用して、Oracle Fusion Middlewareコンポーネントをインストールします。
Oracle WebLogic Server(第6.4.3.1項「Oracle WebLogic Serverのインストール」を参照)
Oracle WebCenter(第6.4.3.2項「Oracle WebCenter用Oracle Fusion Middlewareのインストール」を参照)
最新バージョンのOracle Fusion Middlewareとともに使用するOracle WebLogic Serverのバージョンについては、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。
アプリケーション層にあるすべてのノードにOracle WebLogic Serverをインストールする手順は次のとおりです。
UNIXプラットフォームで、/etc/oraInst.loc
ファイルまたは/var/opt/oracle/oraInst.loc
ファイルが存在している場合には、その内容が正しいことを確認します。具体的には、インベントリ・ディレクトリが正しいこと、またそのディレクトリに対する書込み権限が付与されていることを確認します。
/etc/oraInst.loc
ファイルが存在していない場合には、この手順をスキップします。
Oracle WebLogic Serverインストーラを起動します。
「ようこそ」画面で「次へ」をクリックします。
「ミドルウェア・ホーム・ディレクトリの選択」画面で次の操作を行います。
「新しいミドルウェア・ホームを作成する」を選択します。
「ミドルウェア・ホーム・ディレクトリ」フィールドで、MW_HOMEと入力します。
「次へ」をクリックします。
「セキュリティ更新のための登録」画面で、セキュリティ・アップデート通知の連絡先情報を入力して「次へ」をクリックします。
「インストール・タイプの選択」画面で、「カスタム」を選択して「次へ」をクリックします。
「JDKの選択」画面で、「Oracle JRockit 1.6.0_14 SDK」のみを選択して「次へ」をクリックします。
「製品インストール・ディレクトリの選択」画面で、次のディレクトリを受け入れます。
WL_HOME
「次へ」をクリックします。
「インストールの概要」画面で「次へ」をクリックします。
「インストール完了」画面で、「Quickstartの実行」の選択を解除して「完了」をクリックします。
アプリケーション層にあるすべてのノードにOracle WebCenter用Oracle Fusion Middlewareをインストールする手順は次のとおりです。
Oracle Fusion MiddlewareのOracle Fusion Middleware 11g WebCenterインストーラを起動します。
UNIXの場合(次の例はLinuxの場合):
APPHOST1> runInstaller
Windowsの場合:
APPHOST1> setup.exe
Oracle Fusion Middleware 11g WebCenterインストーラで、JRE/JDKの場所を入力するように求められたら、Oracle WebLogic Serverのインストールで作成したOracle SDKの場所を、MW_HOME/jrockit_160_14_R27.6.4-18のように入力します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、チェックが正常に完了したことを確認して「次へ」をクリックします。
「インストール場所の指定」画面で、次の操作を行います。
「MiddleWareホーム」には、MW_HOMEと入力します。
「Oracleホーム・ディレクトリ」には、たとえばwcのように、使用するディレクトリを入力します。
「次へ」をクリックします。
「インストール・サマリー」画面で「インストール」をクリックします。
「インストール 完了」画面で「終了」をクリックします。
注意: 第6.4.5項「WebLogic Server WebCenterのドメインを作成するためのAPPHOST1でのOracle Fusion Middleware構成ウィザードの実行」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareの最新のパッチ・セットなどの既知のパッチをMiddlewareホームに適用して、Oracle Fusion Middlewareを最新バージョンにしておいてください。最新バージョンのOracle Fusion Middlewareを取得するために実行する必要のある手順は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。 |
管理サーバーの仮想IPの構成の詳細は、第12章「Oracle Fusion Middleware高可用性のアクティブ/パッシブ・トポロジ」を参照してください。
MiddlewareホームのWebCenterディレクトリからOracle Fusion Middleware構成ウィザードを実行し、管理サーバーとOracle WebCenterコンポーネントが格納されるドメインを作成します。リポジトリをインストールしたデータベースが稼働していることを確認します。Oracle RACデータベースでは、すべてのインスタンスを実行することをお薦めします。
次のコマンドを使用して、ORACLE_HOME/common/binディレクトリからOracle Fusion Middlewareの構成ウィザードを起動します。
APPHOST1> ./config.sh
「ようこそ」画面で「新しいWebLogicドメインの作成」を選択し、「次へ」をクリックします。
「ドメイン・ソースの選択」画面で「以下の製品をサポートするために、自動的に構成されたドメインを生成する」を選択し、次の製品を選択します。
Webcenter Spacesを選択すると、WSMポリシー・マネージャとOracle JRFが自動的に選択されます。
Oracle WebCenter Spaces - 11.1.1.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
「次へ」をクリックします。
「ドメイン名」、「ドメインの場所」および「アプリケーションの場所」を選択して、「次へ」をクリックします。
「管理者ユーザー名およびパスワードの構成」画面で、ドメインの管理者に使用するユーザー名およびパスワードを入力して「次へ」をクリックします。
「サーバーの起動モードおよびJDKの構成」画面で、次の選択を行います。
WebLogicドメインの起動モード: 「本番モード」を選択
JDKの選択: 「Oracle JRockit 1.6.0_14 SDK」を選択
「次へ」をクリックします。
「JDBCデータ・ソースの構成」画面で、「次のパネルで選択したコンポーネント・スキーマをRACマルチ・データ・ソース・スキーマとして構成します。」を選択します。
リポジトリ作成ユーティリティによって、必要なスキーマがOracleデータベースに作成されます。これらのスキーマにはカスタム接頭辞を指定します。表6-9は、データソース、使用するスキーマ、およびスキーマが割り当てられている管理対象サーバーを一覧表示しています。
画面に次のデータソースが表示されていることを確認します。
次のパネルですべてのデータ・ソースをRACマルチ・データ・ソース・スキーマとして構成します。を選択します。
「次へ」をクリックします。
「RACマルチ・データ・ソース・コンポーネント・スキーマの構成」画面で、「追加」ボタンをクリックして、両方のOracle RACノードの「ホスト名」、「インスタンス名」および「リスニング・ポート」を追加します。
1つのスキーマを選択したまま残し、他のスキーマの選択は解除します。
「ドライバ」ドロップダウン・リストで、RACサービス・インスタンス接続用Oracleのドライバ(Thin)を選択します。
「サービス名」を入力します。
Oracle WebCenterスキーマのPrefix_Usernameを入力します。
スキーマの「パスワード」を入力します。
「追加」をクリックして、最初のOracle RACインスタンスの詳細を入力します。
一度に1つのデータ・ソースを選択し、適切な詳細を追加することで、各マルチ・データ・ソース・スキーマを更新します。
「次へ」をクリックします。
「JDBCデータ・ソースのテスト」画面で、接続が自動的にテストされます。「ステータス」列に結果が表示されます。すべての接続が正常だったことを確認します。正常でない接続があった場合には、「前へ」をクリックして前の画面に戻り、入力内容を修正します。
すべての接続が正常になったら「次へ」をクリックします。
「オプションの構成を選択」画面で、次を選択します。
管理サーバー
管理対象サーバー、クラスタ、およびマシン
「サーバーおよびクラスタ構成のカスタマイズ」画面で、「はい」を選択して「次へ」をクリックします。
「管理サーバーの構成」画面で、次の値を入力します。
名前: AdminServer
リスニング・アドレス: 第6.4.4項で使用したVIPアドレスを入力します。
リスニング・ポート: 7001
SSLリスニング・ポート: N/A
SSL有効: 選択を解除
「次へ」をクリックします。
「管理対象サーバーの構成」画面で、次の管理対象サーバーを追加します。
表6-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 |
選択を解除 |
「次へ」をクリックします。
「クラスタの構成」画面で、次のクラスタを追加します。
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
クラスタ・アドレス有効化: 空白のまま
「次へ」をクリックします。
「サーバーのクラスタへの割当」画面で、クラスタに次のサーバーを割り当てます。
Spaces_Cluster
WLS_Spaces1
WLS_Spaces2
Portlet_Cluster
WLS_Portlet1
WLS_Portlet2
Services_Cluster
WLS_Services1
WLS_Services2
「次へ」をクリックします。
「マシンの構成」画面で、次の操作を行います。
デフォルトとして表示される「LocalMachine」を削除します。
「UNIXマシン」タブをクリックし、次のマシンを追加します。
「次へ」をクリックします。
「サーバーのマシンへの割当」画面で、マシンに次のサーバーを割り当てます。
APPHOST1: WLS_Spaces1、WLS_Portlet1、WLS_Services1
APPHOST2: WLS_Spaces2、WLS_Portlet2、WLS_Services2
「次へ」をクリックします。
「構成のサマリ」画面で「作成」をクリックします。
ドメインの作成中画面で「完了」をクリックします。
この手順は省略可能で、管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーを起動できるようにします。APPHOST1上の管理サーバーおよび管理対象サーバーに対してboot.properties
ファイルを作成します。
管理サーバーに対しては、次の手順を実行します。
次のディレクトリを作成します。
APPHOST1> mkdir -p MW_HOME/user_projects/domains/wcdomain/servers/AdminServer/security
テキスト・エディタを使用して、前の手順で作成したディレクトリにboot.properties
というファイルを作成し、そのファイルに次の行を入力します。
username=adminuser password=password
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
WLS_Spaces1管理対象サーバーに対しては、次の手順を実行します。
次のディレクトリを作成します。
APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/servers/WLS_Spaces1 APPHOST1> mkdir ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/servers/WLS_Spaces1/security
テキスト・エディタを使用して、前の手順で作成したセキュリティ・ディレクトリにboot.properties
というファイルを作成し、そのファイルに次の行を入力します。
username=adminuser password=password
APPHOST1での管理対象サーバーWLS_Portlet1およびWLS_Services1に対し、手順2と3を繰り返します。
注意: 管理サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。 |
この項では、APPHOST1でシステムを起動する手順について説明します。
APPHOST1上の管理サーバーを起動するには、次のコマンドを実行します。
APPHOST1> cd ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/bin
APPHOST1> ./startWebLogic.sh
管理サーバーが適切に構成されていることを確認する手順は次のとおりです。
ブラウザでhttp://VIP1:7001/console
にアクセスします。
管理者としてログインします。
管理対象サーバーとしてWLS_Spaces1およびWLS_Spaces2が表示されていることを確認します。
Spaces_Clusterクラスタが表示されていることを確認します。
Enterprise Manager(http://VIP1:7001/em
)にアクセスできることを確認します。
この手順が必要になるのは、管理サーバーとノード・マネージャの間にSSL通信を設定していない場合です。SSLが設定されていない場合、ホスト名の検証を無効にしておかないとエラー・メッセージを受信することになります。
ホスト名の検証は、管理サーバーとノード・マネージャの間にSSL通信を設定したら、再度有効化できます。
APPHOST1でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「サーバー」→「管理サーバー」を選択します。
「SSL」→「詳細」を選択します。
「ロックして編集」をクリックします。
プロンプトが表示されたら、変更内容を保存してアクティブ化します。
「ホスト名の検証」を「なし」に設定します。
「WLS_Spaces1」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
WLS_Portlet1とWLS_Services1に対し、手順6と7を繰り返します。
管理サーバーおよびすべての管理対象サーバー(WLS_Spaces1、WLS_Portlet1、WLS_Services1など)を再起動します。
APPHOST2でホスト名の検証を無効化する手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「WLS_Spaces2」→「SSL」→「詳細」を選択します。
「ホスト名の検証」を「なし」に設定します。
WLS_Portlet2とWLS_Services2に対し、手順1と2を繰り返します。
管理サーバーおよびすべての管理対象サーバー(WLS_Spaces2、WLS_Portlet2、WLS_Services2など)を再起動します。
APPHOST1でノード・マネージャを起動するには、次の手順を実行します。
ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.sh
スクリプトを実行し、StartScriptEnabled
プロパティをtrue
に設定します。
APPHOST1> cd ORACLE_COMMON_HOME/common/bin
APPHOST1> ./setNMProps.sh
注意: クラスのロード障害などの問題が発生しないようにするには、StartScriptEnabled プロパティを使用する必要があります。 |
ノード・マネージャを起動します。
APPHOST1> cd WL_HOME/server/bin
APPHOST1> ./startNodeManager.sh
APPHOST2に対し、WebLogic ServerとOracle WebCenterのインストール手順を繰り返します。第6.4.3.1項「Oracle WebLogic Serverのインストール」の手順から始めてください。新しいノードをインストールするときに使用するバイナリ・ファイルのディレクトリ・パスとドメインは、最初のノードに使用したものと同一にする必要があります。これらのパスとドメインが最初のノードに使用したものと同一でない場合には、フェイルオーバーは行なわれません。
次の手順に従い、pack/unpackユーティリティを使用してドメイン構成をAPPHOST2に伝播します。
次のpackコマンドをAPPHOST1で実行し、テンプレート・パックを作成します。
APPHOST1> cd WL_HOME/common/bin
APPHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/
-template=wcdomaintemplate.jar
-template_name=wc_domain_template
次のコマンドをAPPHOST1で実行し、前の手順で作成したテンプレート・ファイルをAPPHOST2にコピーします。この例ではscpを使用しています。
APPHOST1> scp wcdomaintemplate.jar
APPHOST2:WL_HOME/common/bin
unpackコマンドをAPPHOST2で実行し、伝播されたテンプレートを解凍します。
APPHOST2> cd WL_HOME/common/bin APPHOST2> ./unpack.sh -domain=ORACLE_BASE/product/fmw/user_projects/domains/wcdomain/ -template=wcdomaintemplate.jar
APPHOST2でノード・マネージャを起動するには、第6.4.7.4項「APPHOST1でのノード・マネージャの起動」の手順をAPPHOST2で繰り返します。
Oracle WebCenter管理対象サーバーを含む管理サーバーへのOracle HTTP Serverのルーティングを有効にするには、WebLogicClusterパラメータをクラスタ内のノードのリストに設定します。
OHS_HOME/instances/ohs_instance1/config/OHS/ohs1/mod_wl_ohs.conf
ファイルに次の行を追加します。
# Spaces <Location /webcenter> WebLogicCluster apphost1.com:8888,apphost2.com:8888 SetHandler weblogic-handler </Location> <Location /webcenterhelp> WebLogicCluster apphost1.com:8888,apphost2.com:8888 SetHandler weblogic-handler </Location> <Location /rss> WebLogicCluster apphost1.com:8888,apphost2.com:8888 SetHandler weblogic-handler </Location> # 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>
WEBHOST1上のOracle HTTP Serverを再起動します。
WEBHOST1> OHS_HOME/instances/ohs_instance1/bin/opmnctl restartproc ias-component=OHS_COMPONENT1
URLを検証し、HTTP ServerからOracle WebCenterクラスタへのルーティングとフェイルオーバーが適切に機能していることを確認します。
WebLogic Server管理コンソールから、WLS_Spaces1、WLS_Spaces2、WLS_Portlet1およびWLS_Portlet2を次のように起動します。
次のURLの管理コンソールにアクセスします。
http://APHHOST1/console
「サーバー」をクリックします。
「制御」タブを開きます。
WLS_Spaces1、WLS_Spaces2、WLS_Portlet1およびWLS_Portlet2を選択します。
「起動」をクリックします。
次のURLを使用して、管理対象サーバーへの直接アクセスを検証します。
apphost1:8888/webcenter
apphost2:8888/webcenter
apphost1:8889/portalTools
apphost2:8889/portalTools
WLS_Spaces2とWLS_Portlet2の稼働中に、Oracle WebLogic Server管理コンソールからWLS_Spaces1とWLS_Portlet1を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/webcenter
WebHost1:7777/portalTools
WebLogic Server管理コンソールからWLS_Spaces1とWLS_Portlet1を起動します。
WLS_Spaces2とWLS_Portlet2を停止します。
次のURLにアクセスして、適切な機能を検証します。
WebHost1:7777/webcenter
WebHost1:7777/portalTools
高可用性のための管理サーバーの構成の詳細は、第12.4項「コールド・フェイルオーバー・クラスタ用の既存ドメインの管理サーバーの変換」を参照してください。
Javaオブジェクト・キャッシュ(JOC)は、WebCenter Spacesを実行しているすべてのサーバー間で構成する必要があります。このローカル・キャッシュは、Oracle WebCenter Spacesのパフォーマンスを向上させるために用意されています。
Javaオブジェクト・キャッシュは、MW_HOME/oracle_common/bin/configure-joc.py
スクリプトを使用して構成できます。これはPythonスクリプトで、管理対象サーバーでJOCを構成するために使用できます。このスクリプトは、WLSTオンライン・モードで実行され、管理サーバーが稼働中であることが求められます。
Oracle製品にJOCポートを構成する場合は、9988〜9998のポートを使用することをお薦めします。
使用方法
たとえば次のように、コマンドラインのOracle WebLogic Scripting Tool(WLST)を使用して管理サーバーに接続します。
MW_HOME/wc/common/bin/wlst.sh
$ connect()
プロンプトが表示されたら、Oracle WebLogicの管理ユーザー名とパスワードを入力します。
wlst
を使用して管理サーバーに接続したら、execfile
コマンドを次のように使用してスクリプトを起動します。
wls:/mydomain/serverConfig>execfile('FMW_HOME/oracle_common/bin/configure-joc.py')
指定したクラスタのすべての管理対象サーバーに対して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)を構成できます。
ここで説明する手順は、Oracle WebCenter Wiki and Blogサーバーのクラスタを作成する際に必要な構成手順です。Wikiサーバーには、そのローカルのデプロイメント・ディレクトリに構成の一部(すべてではありません)が格納されるため、これらの手順が必要になります。これは、単一ノードのインストールに当てはまります。ただし、クラスタ構成では、Oracle Wikiクラスタのすべてのメンバーが同じ構成情報にアクセスする必要があります。
クラスタの他のメンバーが最初のWikiサーバーの構成にアクセスできるようにするには、そのデプロイメント・ディレクトリのいくつかが共有ドライブ上で使用可能である必要があります。
WCHOST1で行う操作:
共有ドライブに、/shared/owc_wiki
という名前のディレクトリを作成します。
その下に、/attachments
および/templates
という2つのディレクトリを作成します。
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
デプロイメント・ディレクトリから共有ディレクトリへのシンボリック・リンクを作成します。
$ 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
両方のサーバーで、Wiki管理→設定の非クラスタ・モード設定をfalse
(キャッシュ・データの使用)に設定します。
WCHOST2で行う操作:
注意: WCHOST2の管理対象サーバーが少なくとも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
1つのノード上で作成されたテンプレートにいずれのノードからもアクセスできることを確認します。
両方のサーバーで、Wiki管理→設定の非クラスタ・モード設定をfalse
(キャッシュ・データの使用)に設定します。
この項の手順を使用して、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.19項「マルチキャストからユニキャストへのディスカッションの変換」の手順が実行されていることを確認します。
ディスカッション・サーバーのクラスタのすべてのメンバーが、ディスカッション・サーバー管理コンソールを使用して互いに通信できることを確認します。
次の場所にあるクラスタの各メンバーにログインします。
http://<host>:<port>/owc_discussions/admin
「キャッシュ設定」を開きます。
ページの下部にあるキャッシュ機能セクションで、「クラスタリング」が「有効」に設定されていることを確認します。
ページの上部に、クラスタのすべてのメンバーが一覧表示されます。
再度ページの下部に移動し、キャッシュ・ツールセクションで、クラスタワイドでのキャッシュのリセットおよびキャッシュのウォームアップ・タスクを実行します。クラスタのすべてのメンバーで、キャッシュのウォームアップ・タスクを繰り返します。
Oracle WebCenterトポロジは、スケール・アウトやスケール・アップができます。トポロジのスケール・アップでは、管理対象サーバーを1つ以上すでに実行しているノードに新しい管理対象サーバーを追加します。トポロジのスケール・アウトでは、新しいノードに新しい管理対象サーバーを追加します。
この場合は、WebCenterコンポーネントを使用して構成されている管理対象サーバーを実行するノードがすでに存在しています。ノードの共有記憶域には、MiddlewareホームとWebCenterディレクトリが格納されています。
新しいOracle WebCenterおよびサーバーを作成するには、既存のインストール(Middlewareホームとドメイン・ディレクトリ)を使用できます。WebCenterのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
トポロジをスケール・アップするには、次の手順を実行します。
管理コンソールを使用して、WLS_Spaces1、WLS_Portlet1またはWLS_Services1のクローンを新しい管理対象サーバーに作成します。クローン作成のソースとなる管理対象サーバーは、新しい管理対象サーバーを実行するノードにすでに存在している必要があります。
管理対象サーバーのクローンを作成する手順は次のとおりです。
管理コンソールから「環境」→「サーバー」を選択します。
クローンを作成する管理対象サーバー(WLS_Spaces1やWLS_Portlet1など)を選択します。
「クローンの作成」を選択します。
新しい管理対象サーバーにSERVER_NAMEnという名前を付けます。nは新しい管理対象サーバーを識別する番号を示します。
リスニング・アドレスに対して、この新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。
この管理対象サーバーのポート番号が、このノードで使用可能であることを確認します。
スケール・アップする管理対象サーバーがWLS_Services1の場合は、次の追加手順を実行します。
管理対象サーバーを少なくとも一度起動します。起動すると、Oracle Wikiに対して、管理対象サーバーのデプロイメント・ディレクトリが作成されます。これで管理対象サーバーを停止できるようになります。
両方のサーバーで、Wiki管理→設定の非クラスタ・モード設定をfalse(キャッシュ・データの使用)に設定します。
クラスタ内の新しいメンバーを使用して、Oracle HTTP Serverモジュールを再構成します(Oracle HTTP Serverの構成を参照)。
トポロジのスケール・アウトでは、Oracle WebCenterアプリケーションを使用して構成されている新しい管理対象サーバーを新しいノードに追加します。
この項で説明している手順を実行する前に、次の要件を満たしていることを確認してください。
トポロジ内には、WebCenterアプリケーションを使用して構成されている管理対象サーバーを実行しているノードがすでに存在しています。
新しいノードが、WebLogic ServerとOracle WebCenter用の既存のホーム・ディレクトリにアクセスできます。新しい管理対象サーバーを作成するには、共有記憶域内の既存のインストールを使用します。WebLogic ServerまたはWebCenterのバイナリを新しい場所にインストールしたり、packとunpackを実行する必要はありません。
トポロジをスケール・アウトするには、次の手順を実行します。
新しいノードで、WebCenterのインストールとドメイン・ディレクトリが格納されている既存のMiddlewareホームをマウントし、ドメイン内の他のノードと同様に、新しいノードがこのディレクトリにアクセスできることを確認します。
新しいノードに使用する新しいマシンを作成し、このマシンをドメインに追加します。
このマシンのノード・マネージャのアドレスを更新して、スケール・アウトに使用されているノードのIPをマップします。
管理コンソールを使用して、WLS_Spaces1/WLS_Portlet1/WLS_Services1のクローンを新しい管理対象サーバーに作成し、WLS_(SERVER_TYPE)nという名前を付けます。nは番号です。
この手順では、管理対象サーバーが実行されていないノードnに新しいサーバーを追加することを想定しています。
管理対象サーバーのリスニング・アドレスに対して、新しい管理対象サーバーに使用するホスト名またはホストIPを割り当てます。
スケール・アップする管理対象サーバーがWLS_Services1の場合は、次の追加手順を実行します。
管理対象サーバーを少なくとも一度起動します。起動すると、Oracle Wikiに対して、管理対象サーバーのデプロイメント・ディレクトリが作成されます。これで管理対象サーバーを停止できるようになります。
両方のサーバーで、Wiki管理→設定の非クラスタ・モード設定をfalse(キャッシュ・データの使用)に設定します。
クラスタ内の新しいメンバーを使用して、Oracle HTTP Serverモジュールを再構成します(Oracle HTTP Serverの構成を参照)。
新しいノードでノード・マネージャを起動します。すでに存在しているノードの共有記憶域にあるインストールを使用し、新しいノードのホスト名をパラメータとして渡してノード・マネージャを起動します。
NEW_NODE> WL_HOME/server/bin/startNodeManager <new_node_ip>
第6.4.3.1項「Oracle WebLogic Serverのインストール」に示すパスを使用した場合、MW_HOMEはMW_HOME
になります。
前の手順で追加した管理対象サーバーを管理コンソールから起動し、テストします。
新規に作成した管理対象サーバー上のアプリケーション(http://HOST:port/webcenter
)にアクセスします。アプリケーションが機能している必要があります。
この新しい管理対象サーバーをJavaオブジェクト・キャッシュ・クラスタに追加します(第6.4.13項「Javaオブジェクト・キャッシュの構成」を参照)。
この項では、Oracle WebCenterで発生する可能性のある問題のトラブルシューティング手順について説明します。
WebCenterアプリケーションは、管理対象サーバーが最初に起動したときにデプロイされます。最初にOracle WebLogic Server管理コンソールを使用して、アプリケーションのデプロイメントがすべて成功したことを確認します。
左側のペインで「デプロイメント」をクリックします。右側のペインに、アプリケーション・デプロイメントおよびそのステータスが表示されます。すべてのサーバーが稼働中と想定すると、すべてのアプリケーションの状態はACTIVEになっている必要があります。
アプリケーションのデプロイメントが失敗した場合には、アプリケーションが正常にデプロイされなかった理由がサーバー・ログに示されることがあります。サーバー・ログは、DOMAIN_HOME
/servers/
SERVER_NAME
/logs
ディレクトリに格納されています。一般的な問題には、次のようなものがあります。
データベース・リソースなどの外部リソースを使用できません。エラーを調べて修正し、アプリケーションを再デプロイしてみてください。
適切なアプリケーションまたはライブラリのターゲットが、目的の管理対象サーバーまたはクラスタに正しく設定されていません。
フェイルオーバーのシナリオでは、状態のレプリケーションが最も顕著です。あるサーバーで作業しているユーザーは、フェイルオーバー時に次のことを検出する場合があります。
ウィンドウが閉じたか、または状態がリセットされた可能性がある。
画面のリセットが必要になった可能性がある。
アプリケーションがログオン画面にリダイレクトしている可能性がある。
次の手順は、状態のレプリケーションに関する問題のトラブルシューティングおよび診断を行う際のガイダンスです。
これがレプリケーションに関する既知の問題でないことを確認します。
予想される動作については、第6.3.2.7項「アプリケーションのフェイルオーバーで予想される動作」を参照してください。問題の詳細な診断に進む前に、フェイルオーバーの実際の動作が、予想される動作でないことをまず確認してください。
ロード・バランサの設定を確認します。
レプリケーションとフェイルオーバーが正しく機能するようにするには、ロード・バランサの永続性の設定が適切に構成されている必要があります。Oracle WebLogic Serverのハードウェア・ロード・バランサの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』を参照してください。
クラスタのステータスを確認します。
クラスタのコンテキスト内でレプリケーションが発生します。フェイルオーバーが成功するには、クラスタの正常なメンバーが、ほかに少なくとも1つ使用可能である必要があります。クラスタのステータスは、次の2種類の方法のどちらかで確認できます。
Oracle WebLogic Server管理コンソールを使用してクラスタのステータスを確認します。左側のペインで「サーバー」をクリックします。クラスタ内のすべてのサーバーの状態を確認します。
weblogic.Adminユーティリティを使用してクラスタのステータスを確認します。weblogic.Adminコマンドは、特定のクラスタ内のすべてのサーバーの状態を問い合せるときに使用できます。次に例を示します。
$ java weblogic.Admin -url Adminhost:7001 -username <username> -password <password> CLUSTERSTATE -clustername Spaces_Cluster
次のようなメッセージが返されます。
There are 2 server(s) in cluster: Spaces_Cluster The alive servers and their respective states are listed below: WLS_Spaces---RUNNING WLS_Spaces2---RUNNING
クラスタ通信を確認します。
クラスタ・メンバーがすべて稼働していても、通信に関する問題が発生して、レプリケーション情報をメンバー間で伝達できなくなる場合があります。クラスタ通信は、次の2種類の方法で構成できます。トラブルシューティングは、クラスタ・タイプによって異なります。
ユニキャスト・クラスタ通信の確認: ユニキャスト・クラスタの場合、管理対象サーバー間で、お互いのホストおよびお互いのデフォルトのリスニング・ポートにアクセスできる必要があります。
個々の管理対象サーバーすべてで、「リスニング・アドレス」が適切に設定されていることを確認します。この設定は、管理対象サーバーごとに「構成」→「一般」を選択して調べることができます。
マルチキャスト・クラスタ通信の確認: マルチキャスト・クラスタの場合、サーバーは同じマルチキャスト・トラフィックをインターセプトできる必要があります。各マシンでWebLogicユーティリティutils.MulticastTest
を実行して、マルチキャストが正しく構成されていることを確認します。次に例を示します。
$ java utils.MulticastTest -H
アプリケーションの構成を確認します。
WebCenterアプリケーションは、デフォルトで正しく構成されています。ユーザー・アプリケーションに対するメモリー内のレプリケーションは、weblogic.xml
で適切な構成がなされている場合にのみ行われます。
<session-descriptor> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
replicatedのpersistent-store-typeも受け入れられます。
デバッグを有効にします。
サーバー・ログを調べて、管理対象サーバーの起動時に異常なメッセージがないか確認します。この確認は、管理対象サーバーがクラスタの他のメンバーを見つけられない場合に、特に必要です。サーバー・ログは、DOMAIN_HOME
/servers/
SERVER_NAME
/logs
ディレクトリに格納されています。
詳細な診断を行うには、DebugCluster
、DebugClusterAnnouncements
、DebugFailOver
、DebugReplication
、DebugReplicationDetails
の各フラグを有効にします。各フラグは、weblogic.Adminユーティリティを使用して次のように有効にできます。
$ java weblogic.Admin -url Adminhost:7001 -username <username> -password <password> SET -type ServerDebug -property DebugCluster true
ポリシーは、変数oracle.security.jps.ldap.policystore.refresh.interval
によってjps-config.xml
に定義されている間隔でリフレッシュされます。デフォルトでは、この間隔は10分です。サーバーが失われた場合、リクエストは、元のポリシーがキャッシュされている、クラスタ内の別のサーバーにルーティングされます。前回のリフレッシュ以後に発生した最近のポリシーの変更が失われたように見えることがあります。たとえば、フェイルオーバーの直前に作成されたロールは、使用不可と表示される場合があります。
このような状況でも、ポリシーは、バックエンド・ポリシー・ストアにあります。キャッシュをリフレッシュして、ポリシー情報をリストアします。数分後に再試行するか、またはアプリケーションにログインしてからログアウトして、ポリシー・キャッシュのリフレッシュを強制実行します。
OWSMやWebCenter Spaces管理対象サーバーなど、Javaオブジェクト・キャッシュを使用する管理対象サーバーを起動しようとした場合、起動に失敗し、ログに次のエラーが記録されます。
J2EE JOC-058 distributed cache initialization failure J2EE JOC-043 base exception: J2EE JOC-803 unexpected EOF during read.
別のプロセスが、JOCが取得を試みている同じポートを使用しています。この問題を解決するには、そのプロセスを停止するか、推奨ポート範囲内の別のポートを使用するように、このクラスタのJOCを再構成します。
ディスカッションをマルチキャストからユニキャストに変換する手順は次のとおりです。
手順1: 起動パラメータの追加
関連する起動パラメータの追加手順は次のとおりです。
Oracle WebLogic Server管理コンソールで、「サーバー」→「WLS_Services1」→「構成」→「サーバーの起動」を選択します。
「引数」ボックスで、次の行を追加します。
-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
を使用して、別のポート番号を指定します。
Host2はHost1に、Host1はHost2に入れ替えて、WLS_Services2に対して手順1と2を繰り返します。
WLS_Services1サーバーを再起動します。
手順2: 変更の検証
変更を検証する手順は次のとおりです。
ディスカッション・フォーラムの管理パネルにログオンします。
左ペインで「キャッシュ設定」を選択します。
画面の下部で、「クラスタリング」が「有効」に設定されていることを確認します。
クラスタのすべてのメンバーに対して、手順1〜3を繰り返します。
サーバーがクラスタに参加すると、それらのサーバーが画面の上部に表示されます。
この項では、高可用性のためにOracle ADFおよびWebCenterのカスタム・アプリケーションを構成する手順について説明します。
WebCenterアプリケーションをデプロイするためにクラスタを構成する際に必要となる手順は次のとおりです。
Oracle WebLogic Server管理コンソール(http://server_name:7001/console
)にアクセスします。
管理ユーザー名とパスワードを入力してログインします。
「ホーム」ページで、ドメイン構成セクションの「サーバー」をクリックします。
ページ・セクションの「概要」で「新規」をクリックします。
カスタム・アプリケーション・サーバーに対する独自のサーバー名とポート番号(例: 8898)を入力します。
他の選択はデフォルトのままにして、「終了」をクリックして管理対象サーバーを生成します。
作成の概要ページで、作成したばかりのサーバーをクリックします。「マシン」ドロップダウン・リストをクリックし、「LocalMachine」を選択します。
ページの下部にある「保存」をクリックします。
手順4〜8を繰り返し、必要に応じて管理対象サーバーをさらに作成します。
クラスタを作成するには、「「ホーム」」ページで「クラスタ」をクリックします。
右側のペインで、「新規」をクリックして新しいクラスタを作成します。
クラスタに名前を付け、デフォルトの「ユニキャスト」はそのままにします。
「OK」をクリックしてクラスタを作成します。
クラスタ名をクリックし、「サーバー」タブをクリックします。
「追加」ボタンをクリックしてサーバーを追加します。
ドロップダウン・リストから、前に作成した管理対象サーバーを選択し、「終了」をクリックします。
クラスタを作成したら、正しいライブラリ、アプリケーションおよびデータ・ソースを使用してプロビジョニングします。
「ドメイン構造」セクションの「デプロイメント」リンクをクリックします。
複数の共有ライブラリがデプロイされていることに注意してください。次のライブラリのターゲットが、新規作成したクラスタに設定されていることを確認します。
ライブラリ・リンクをクリックします。
上部の「ターゲット」タブをクリックします。
新規作成したクラスタのチェック・ボックスを選択します。
「保存」ボタンをクリックします。
ターゲットを設定する共有ライブラリのリストは次のとおりです。
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アプリケーション
Oracle WebLogic Server管理コンソールの左側のペインで、「サービス」→「JDBC」→「データ・ソース」をクリックします。次のデータ・ソースのターゲットが、新規作成したクラスタに設定されていることを確認します。
mds-OWSM
注意: カスタム・アプリケーション用に独自のMDSスキーマを作成した場合は、その新しいMDSスキーマを新しいクラスタに割り当て、2つの事前定義済MDSスキーマは省略します。 |
Oracle WebLogic Server管理コンソールの左側のペインで「環境」をクリックし、「起動クラスと停止クラス」をクリックします。次に一覧表示するクラスが使用可能になります。
監査ローダー起動クラス
DMS-起動
JMXフレームワーク起動クラス
JOC-起動
JPS-起動クラス
JRF起動クラス
ODL-起動
OWSM起動クラス
次のようにクリックし、これらのクラスすべてのターゲットを新しいクラスタに設定します。
各起動/停止クラスの名前→「ターゲット」タブ→「CustomManagedServer」チェック・ボックス→「保存」
これらの手順を完了すると、Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを起動し、カスタム・アプリケーションをデプロイできるようになります。カスタム・アプリケーションは、管理対象サーバーのターゲットでなく、クラスタのターゲットにデプロイします。
各起動/停止クラスの名前→「ターゲット」タブ→「CustomManagedServer」チェック・ボックスをクリックし、これらすべてのクラスのターゲットを新しいクラスタに設定します。
「保存」をクリックします。
変更をアクティブ化します。
これらの手順を完了すると、Oracle WebLogic Server管理コンソールを使用して管理対象サーバーを起動し、カスタム・アプリケーションをデプロイできるようになります。カスタム・アプリケーションは、管理対象サーバーのターゲットでなく、クラスタのターゲットにデプロイします。
引き続きWebCenterの高可用性デプロイメントを構成するには、『Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter』を参照してください。