ヘッダーをスキップ
Oracle® Fusion Middleware高可用性ガイド
11g リリース1 (11.1.1)
B55898-07
  目次へ移動
目次
前
前 		 次
次		  

14 Oracle Portal、Forms、ReportsおよびDiscovererの高可用性の構成

この章では、Oracle Portals、Forms、ReportsおよびDiscovererの高可用性の概要と構成手順について説明します。この章の項目は次のとおりです。

14.1 Oracle Portal、Forms、ReportsおよびDiscovererの概要

Oracle Portalにより、Oracle Fusion Middlewareと緊密に統合されたポータルを構築、デプロイおよび管理するための完全なポータル・フレームワークが実現されます。

Oracle Portalを使用すると、Oracle WebCenter Contentによるエンタープライズ・コンテンツ管理機能によりデプロイメントを拡張できます。さらに、Oracle WebCenterポータル・サービスを使用して既存のポータルにEnterprise 2.0機能を追加できます。Oracle Portalでは、これらの補完的なソリューションの両方との相互運用性と、Oracleエンタープライズ・アプリケーションおよび他のOracle Fusion Middlewareコンポーネントとの相互運用性が確認されています。

Oracle Portalを実装すると、多くの場合、それが組織のインターネットまたはイントラネットのエントリ・ポイントとなるため、できるかぎり高い可用性を持たせることが不可欠です。

Oracle Formsは、エンタープライズ・アプリケーションを迅速で効率的に設計し構築するために、オラクル社で長い歴史において確立されているテクノロジです。

Oracle Reportsサービスは、Oracle Fusion Middlewareのレポート・パブリッシング・コンポーネントです。これは、高品質の稼働レポートを生成するためのエンタープライズ・レポート作成サービスです。これによって、任意のデータを動的に取得し、任意の形式で書式設定し、任意の場所で配布します。Oracle Reportsサービスを使用して、Webベースと非Webベースの両方の環境で公開できます。

Oracle Discovererは、データ分析用のビジネス・インテリジェンス・ツールです。これは、Oracle Fusion Middlewareの重要なコンポーネントです。Discovererは、直感的な非定型問合せ、レポート作成、分析およびWebパブリッシングの各機能を備えた統合ビジネス・インテリジェンス・ソリューションです。これらのツールにより、技術的な知識のないユーザーが、データ・マート、データ・ウェアハウス、マルチディメンショナル(OLAP)データ・ソースおよびオンライン・トランザクション処理システムの情報に直接アクセスできるようになります。Discovererは、Oracle PortalおよびOracle WebCenterポータルとシームレスに統合されるため、Discovererのワークブックおよびワークシートを各Webポータルに迅速にデプロイできます。

Oracle Portal、Forms、ReportsおよびDiscovererは、個別にインストールすることも、まとめてインストールすることもできます。

14.1.1 Oracle Portal、Forms、ReportsおよびDiscovererのアーキテクチャ

図14-1は、単一インスタンスのOracle Portal、Forms、ReportsおよびDiscovererのデプロイメントを示しています。

図14-1 Oracle Portal、Forms、ReportsおよびDiscovererのアーキテクチャ

Oracle Portal、Forms、ReportsおよびDiscovererのアーキテクチャ
「図14-1 Oracle Portal、Forms、ReportsおよびDiscovererのアーキテクチャ」の説明

Oracle Portal、Forms、ReportsおよびDiscovererの一般的なコンポーネント

図14-1には、次の一般的なコンポーネントが含まれています。

  • Oracle Web Cacheは2つの機能を実行します。そのプライマリ機能により、そのキャッシュから静的Webコンテンツが、Oracle HTTP Server単体の場合よりも高速に渡されます。Oracle Web Cacheのキャッシュにキャッシュ可能ページがない場合、つまりそのページが最新のページではない場合は、接続されたOracle HTTP Serverにそのページへのリクエストが実行されます。

    Oracle Web Cacheの2番目の機能は、高可用性環境で使用されます。これはリクエストを受け取り、それ自体のキャッシュからそのリクエストに対応できない場合、複数のOracle HTTP Serverの間でロード・バランシングできます。

    Oracle Web Cacheはオプションですが、Oracle Forms、ReportsおよびDiscovererとともに使用できます。

  • Oracle HTTP Serverはリクエストされたページのアセンブルを行います。ページ・アセンブリは常に直接的に実行されるとはかぎりません。ページの構成方法に応じて、Oracle HTTP Serverでは次のいずれかが実行されます。

    • ページが単純なHTMLドキュメントである場合、Web層によってドキュメントが検索されて返されます。

    • Java EEアプリケーションを実行してアセンブルすることが必要なWebページである場合、Oracle Web TierによってリクエストがOracle WebLogic Serverにルーティングされ、リクエストはそこで処理された後、その結果がOracle Web Tierを経由してユーザーに返されます。

    • PLSQLやCGIなど他のアプリケーションを実行してアセンブルすることが必要なWebページである場合は、リクエストはOracle Web Tierによって適切なアプリケーションにルーティングされ、そのアプリケーションによって処理された後、その結果がOracle Web Tier経由でユーザーに返されます。

    • リクエストされたページがセキュリティで制御されている場合、Oracle Web ServerによってOracle Identity Managementが呼び出され、そのページを表示する権限がユーザーにあるかどうかが確認されます。

    Oracle HTTP Serverは、スタンドアロンで使用することもOracle Web Cacheとともに使用することもできます。

    Oracle Portal、Forms、ReportsおよびDiscovererのデプロイメントでは、Oracle HTTP Serverはmod_wl_ohsと呼ばれるApacheモジュールを使用して、リクエストをOracle WebLogic管理対象サーバーにルーティングします。WebLogic管理対象サーバーがまとめてクラスタ化されている場合、mod_wl_ohsではそのクラスタにあるすべての管理サーバー間でリクエストがロード・バランシングされます。

  • Oracle WebLogic管理対象サーバーはOracle Portal、Forms、ReportsおよびDiscovererアプリケーション用のJava EEランタイム・コンテナです。

  • Oracle Process Manager and Notification Server(OPMN)はOracle Web CacheやOracle HTTP Serverの起動、停止および監視を行うために使用されます。これによってOracle Web CacheおよびOracle HTTP Serverが定期的にポーリングされ、それらが機能していることが確認されます。それらが機能していない場合、OPMNによって適切なアクションが実行され、障害が発生したコンポーネントが再起動されます。これによって、サービスが確実に維持されます。

  • Oracle Node ManagerはOracle WebLogic管理対象サーバー(管理サーバーを含む)を起動、停止および監視するために使用されます。これによってWebLogic管理対象サーバーが定期的にポーリングされ、それらが機能していることが確認されます。それらが機能していない場合、Oracle Node Managerによって適切なアクションが実行され、障害が発生したコンポーネントが再起動されます。これによって、サービスが確実に維持されます。

  • Oracle WebLogic管理サーバーはWebLogic管理コンソールとOracle Fusion Middleware Enterprise Managerの両方が含まれます。これは、WebLogicドメイン内で1回のみアクティブになります。この管理サーバーをホストしているサーバーに障害が発生した場合は、これを他の場所で手動で再起動する必要があります。

  • Oracle Single Sign-Onはオラクル社のエンタープライズ認証メカニズムです。Oracle Single Sign-Onは製品コンポーネントごとにOracle HTTP Serverに統合されます。認証が必要なリクエストがOracle HTTP Serverに着信すると、そのユーザーがOracle Single Sign-Onサーバーによって認証済かどうかが判別されます。ユーザーが認証済である場合、リクエストが処理されます。ユーザーが認証されていない場合は、Oracle Single Sign-Onサーバーと通信して認可を受けます。

14.1.2 共通ログ・ファイル

次の表に、Oracle Portal、Forms、ReportsおよびDiscovererによって使用される一般的ログ・ファイルのリストと説明、およびファイルの場所を示します。

ファイル 場所 説明

access_log

ORACLE_INSTANCE/diagnostics/logs/OHS/ohs1

Oracle HTTP Serverへの各アクセスとHTTPリターン・コードのリスト

ohs1.log

ORACLE_INSTANCE/diagnostics/logs/OHS/ohs1

HTTPサーバーのエラー・ログ

access_log

ORACLE_INSTANCE/diagnostics/logs/WebCache/web1

Oracle WebCacheへの各アクセスとHTTPリターン・コードのリスト

access_log

DOMAIN_HOME/servers/WLS_PORTAL/logs

WebLogic管理対象サーバーが受信するアクセス・リクエストのリスト

opmn.log

ORACLE_INSTANCE/diagnostics/logs/OPMN

OPMNログ・ファイル

14.1.3 一般的なコンポーネント障害および予想される動作

この項では、Oracle Portal、Forms、ReportsおよびDiscovererに適用される高可用性の概要について説明します。

14.1.3.1 Oracle Web CacheおよびOracle HTTP Serverのプロセス障害

Oracle HTTP Server、Oracle Web CacheおよびOracle Discovererのプリファレンス・サーバー・プロセスは、Oracle Process Manager and Notification(OPMN)システムによって保護されます。これらのプロセスのいずれかに障害が発生すると、OPMNによって自動的にそのプロセスが再起動されます。

Oracle WebLogic管理対象サーバーは、Oracle Node Managerによって起動され監視されます。Oracle WebLogic管理対象サーバーに障害が発生した場合、Oracle Node Managerによってそのプロセスが再起動されます。

14.1.3.2 一般的なコンポーネント・ノード障害

Oracle Web Cacheが前面に配置されていないノードに障害が発生した場合、正常に動作しているノードにリクエストがロード・バランサによって自動的に再ルーティングされます。

Oracle Web Cacheに障害が発生した場合、正常に動作しているWebキャッシュ・ノードにリクエストがロード・バランサによって自動的に再ルーティングされます。

Oracle Web Cacheが前面に配置されているOracle HTTP Serverのノードに障害が発生した場合、正常に動作しているOracle HTTP ServerにリクエストがOracle Web Cacheによって再ルーティングされます。

Oracle WebLogic Serverに障害が発生した場合、リクエストはOracle HTTP Serverによって別のWebLogicクラスタ・メンバーに再ルーティングされます。

Oracle Portal、Forms、ReportsおよびDiscovererリクエストが障害発生ノードで処理されていた場合、リクエストを再開する必要があります。

14.1.3.3 一般的なコンポーネントのWebLogic管理対象サーバーの障害

高可用性構成では、Oracle WebLogic管理対象サーバーはまとめてクラスタ化されます。管理対象サーバーのいずれかに障害が発生した場合、正常に動作しているクラスタ・メンバーのいずれかにリクエストがmod_wl_ohsによってリダイレクトされます。アプリケーションに状態が格納されている場合、状態のレプリケーションがクラスタ内で使用可能になり、これにより、リダイレクトされたリクエストが、同じ状態情報にアクセスできます。

14.1.3.4 一般的なコンポーネントのデータベースの障害

データベースは、Oracle Real Application Clustersなどの高可用性テクノロジを使用して実装することをお薦めします。データベース・ノードのいずれかに障害が発生した場合でも、そのデータベース全体は使用可能な状態に維持されます。場合によっては、リクエストの再送信が必要です。

マルチ・データベース・ノード環境では、障害が発生したデータベース・ノードにユーザー・セッションが接続されている場合、次のようになります。

  • Oracle Portal: ユーザーは、リクエストを再送信する必要があります。

  • Oracle Forms: ユーザーは、リクエストを再送信する必要があります。

  • Oracle Reports: Oracle Transparent Application Failoverを使用してデータベース接続文字列が構成されている場合、アクションは必要ありません(レポートがその実行中にデータベースに書き込まれていない場合)。

    レポート・キューを含むデータベースでノードが失われた場合、ユーザーはレポート・リクエストを再送信する必要があります。

  • Oracle Discoverer: ユーザーは、リクエストを再送信する必要があります。

14.1.4 Oracle Portal、Forms、ReportsおよびDiscovererのクラスタワイドの構成変更

Oracle Web Cacheインスタンスはクラスタ化されます。Oracle Fusion MiddlewareコンソールやOracle Web Cache管理ユーティリティから構成変更が行われた場合、これらの変更は他のクラスタ・メンバーに伝播されます。伝播は、これらのツールを使用して手動で行います。

Oracle HTTP Serverはクラスタ化されません。Oracle HTTP Serverの構成はファイル・ベースです。その結果、いずれかのOracle HTTP Serverに対して行われた変更は、その構成において他のOracle HTTP Serverに手動でコピーする必要があります。これは、htdocsディレクトリに格納されている静的HTMLファイルにも適用されます。

一連の構成ファイルを使用して、Oracle Portal、Forms、ReportsおよびDiscovererを構成します。これらのファイルに対する変更はすべて、アーキテクチャにあるすべてのメンバーに手動で適用する必要があります。

WebLogic管理対象サーバーはクラスタ化され、クラスタ・レベルでリソースを共有します。これらのリソースに対する変更は一括して実行できるため、伝播する必要はありません。これらのリソースは、次のとおりです。

  • データ・ソース

  • アプリケーションの再デプロイメント

  • 状態のレプリケーション

14.1.5 一般的なコンポーネント・ログ・ファイル情報

クラスタワイドでログを統合する機能は、Oracle Web Cache、Oracle HTTP Server、OPMNおよびWebLogic管理対象サーバーに対しては提供されていません。Oracle HTTP Serverアプリケーションの状態の詳細は、各Oracle HTTP Serverノードのログ・ファイルを参照してください。障害が発生したアプリケーションの状態の詳細は、各サーバー・ノードのログ・ファイルを参照してください。

14.2 Oracle Portalと高可用性の概要

この項では、Oracle Portalに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Portalデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。

14.2.1 Oracle Portalの単一インスタンスの特性

Oracle Portalの単一インスタンス・アーキテクチャの詳細は、『Oracle Fusion Middleware Oracle Portal管理者ガイド』の次に示す項を参照してください。

  • Oracle Portalコンポーネントの理解に関する項: Oracle Fusion Middlewareのコンポーネントを紹介します。ここでは、これらのコンポーネントがOracle Portalとどのように連動するのかを説明します。

  • Oracle Portalアーキテクチャの理解に関する項: Portalアーキテクチャについて説明します。この項の次に示すトピックをお読みください。

    • Oracle Portalと他のコンポーネントとの連動方法に関する項

    • Oracle Portalにおいてページがアセンブルされる方法に関する項

    • Oracle Portalにおいて通信が行われる方法に関する項

  • Oracle Portalにおけるキャッシュの理解に関する項: この項では、中規模から大規模のデプロイメントの可用性およびスケーラビリティを高めるために実装できるキャッシュ構成について説明します。

  • WSRPおよびJPSの理解に関する項: Web Services for Remote Portlets (WSRP)規格およびJava Portlet Specification (JPS)の概要を示します。これらの2つの規格により、異なるポータル製品で相互運用するポートレットの開発が可能になり、組織内におけるポートレットの可用性が高まります。

14.2.1.1 Oracle Portalのリクエスト・フロー

Oracle Portalのリクエスト・フローの詳細は、『Oracle Fusion Middleware Administrator's Guide for Oracle Portal』で次に示す各項を参照してください。

  • Oracle Portalにおいてページがアセンブルされる方法に関する項

  • Oracle Portalにおいて通信が行われる方法に関する項

14.2.1.2 Oracle Portalコンポーネントの特性

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

  • Oracle Portalアプリケーションは、WebLogicコンテナ(WLS_PORTAL)の内部で実行されます。

  • Oracle Portalのリポジトリには、メタデータ、ドキュメント、カスタマイズおよびパーソナライズが格納されます。

  • Oracle Portalは、コンテンツを処理してキャッシュするためにOracle Web Cacheに強く依存しています。

  • Oracle Portalは、Oracle HTTP Serverに依存して、トラフィックをWebLogic Serverにルーティングし、製品イメージのサービス処理を行い、URLをリライトします。

14.2.1.3 Oracle Portalのプロセスの起動と停止およびライフサイクル

Oracle Portalには、固有のプロセスはありません。標準のOracleツールおよびユーティリティに依存して、Oracle Web Cache、Oracle HTTP Server、WebLogic管理対象サーバーのWLS_PORTAL、およびデータベースを管理します。

Oracle Portalコンポーネントの構成と監視を行うインタフェースは次のとおりです。

  • Enterprise Manager: Oracle Web Cache、Oracle HTTP Server、Oracle PortalおよびWLS_PORTALを管理するためにあります。

  • Oracle WebLogic管理コンソール: WLS_PORTALを管理するためにあります。

  • Oracle WebLogic Scripting Tool(WLST): Portal固有の構成パラメータの追加や編集を行うためにあります。

  • opmnctlコマンド・ライン・インタフェース: Oracle Web CacheやOracle HTTP Serverを管理するためにあります。

14.2.1.4 Oracle Portalのデプロイメント・アーティファクト

Portalアプリケーションは、ステージング済アプリケーション(portal.ear)としてWebLogic Server(WLS_PORTAL)にデプロイされます。構成ファイルはDOMAIN_HOME/servers/WLS_PORTAL/stage/portal/portal/configurationにあります。

14.2.1.5 Oracle Portalの構成情報

Portal構成のいくつかは、Portalリポジトリに格納されます。この情報には、サイトの詳細(サイトのホストとポート)、Web Cacheの詳細(webcacheのホスト、無効化ポートおよび無効化パスワード)およびOracle Internet Directoryの詳細(Oracle Internet Directoryのホストおよびポート)が含まれています。このような情報は、Enterprise Managerにアクセスすることや、コンテナに対してWLSTコマンドを使用することにより変更できます。

残りのPortal構成は、Portalアプリケーションのステージング済場所内に配置される構成ファイルにあります。その構成ファイルはDOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/にあります。HA環境では、構成ファイルを変更した場合、各ノードに対してアクションを繰り返すか、あるノードから別のノードに構成ファイルをコピーすることで、同じ変更を各WLS_PORTALインスタンスで繰り返す必要があります。

表14-1 Portalの構成ファイル

構成ファイル 説明

appConfig.xml

Portal Page Engine構成

portal_dads.conf

ポータル・データベース・アクセス記述子(DAD)構成

このファイルには、高可用性(HA)に関するプロパティが含まれています。これには、データベースへの接続文字列情報が含まれています。Oracle RACノードが追加または削除された場合、ノードの最終的なセットを反映するようにこのファイルを更新する必要があります。このファイルには、構成プロパティが含まれています。これにより、プールされたデータベース接続を使用前にテストできます。このプロパティを有効にすると、データベース・ノードが停止した場合に、最小限のコストでより適切な結果を実現できます。

portal_cache.conf

ポータル・キャッシュ構成

portal_plsql.conf

ポータルのグローバル設定

14.2.1.6 Oracle Portalのロギングおよびログ構成

Portalのログ・ファイルは、DOMAIN_HOME/servers/WLS_PORTAL/logsディレクトリに生成されます。ログ・ファイルの名前は、WLS_PORTAL-diagnostic.logです。ログ・ローテーションにより、古いログは類似した名前でアーカイブされます。Portalのログ・ファイルの構成は、logging.xmlファイルによって制御されます。このファイルはDOMAIN_HOME/config/fmwconfig/servers/WLS_PORTALに配置されます。

14.2.1.6.1 Oracle Portalのログ・ファイル

次の表に、Oracle Portalによって使用されるログ・ファイルのリストと説明を示します。

ファイル 場所 説明

WLS_PORTAL.log

DOMAIN_HOME/servers/WLS_PORTAL/logs

WebLogic管理対象サーバーのログ・ファイル

WLS_PORTAL.out

DOMAIN_HOME/servers/WLS_PORTAL/logs

WebLogic管理対象サーバーのサプリメンタル・ログ・ファイル:これは、一般的にWebLogicの問題について最初に検索される場所です。

14.2.1.7 Oracle Portalの外部依存性

Oracle Portalでは、リクエストに対応するためにOracle HTTP Serverが必要になります。オプションで、これらのリクエストをOracle Web Cacheによってキャッシュできます。その場合、それはロード・バランサとしても機能します。

Oracle Portalには、情報を格納するためのデータベースが必要です。このデータベースは、Oracle Repository Creation Assistantを使用してスキーマで事前にシードされます。

14.2.2 Oracle Portalの障害からの保護および予想される動作

図14-2は、Oracle Portalの高可用性構成を示しています。

図14-2 Oracle Portalの高可用性デプロイメント

Oracle Portalの高可用性デプロイメント
「図14-2 Oracle Portalの高可用性デプロイメント」の説明

Oracle Portalの高可用性設定には、複数のOracle Web Cacheインスタンスが含まれます。これらのOracle Web Cacheインスタンスはまとめてクラスタ化され、キャッシュの整合性とフェイルオーバーが実現されます。複数のOracle HTTP Serverにトラフィックをルーティングするように、各Oracle Web Cacheは構成され、これらのサーバーでは、着信リクエストがロード・バランシングされます。

Oracle Portalアプリケーションをホストする複数のOracle WebLogic管理対象サーバーにOracle Portalリクエストをルーティングするように各Oracle HTTP Serverは構成されます。Oracle HTTP Serverは、Oracle Fusion Middlewareによって用意されているWebサーバーです。これには、Secure Sockets Layer(SSL)およびHTTP Secure Sockets Layer(HTTPS)をサポートするためのOpenSSLモジュールが組み込まれています。JavaサーブレットおよびJ2EEアプリケーションを実行しているOracle WebLogic Serverにトラフィックをルーティングするためのモジュール・コネクタもOracle HTTP Serverに用意されています。Oracle PortalはOracle HTTP Serverに依存して、いくつかのシナリオで、製品イメージのサービス処理を行い、URLをリライトします。

WLS_PORTALは、Oracle Portalアプリケーションを実行するWebLogic Serverです。WebLogic Serverでは、JSPトランスレータ、JSPサーブレット・エンジン(OJSP)およびEnterprise JavaBeans(EJB)コンテナを含む完全なJava EE環境が実現されます。これにより、高速で軽量でありながら高度にスケーラブルで使いやすく完全なJava EE環境が実現されます。これは、すべてJavaで記述されており、標準のJava Development Kit(JDK)仮想マシン(JVM)上で実行されます。

WLS_PORTAL内で実行されているPortalアプリケーションでは、Oracle Web Cacheと緊密に連携し、そのEdge Side Include(ESI)処理を使用して、セキュアな形式で動的Portalページを提供します。Oracle PortalではESIを使用し、様々なメタデータやコンテンツをOracle Web Cacheにセキュアにキャッシュします。コンテンツが変更されると、Oracle Web CacheにキャッシュされたコピーはOracle Portalによって無効化されます。そのようなコンテンツは、後続のリクエストで再生成されます。ESIにより、コンテンツを詳細なレベルでキャッシュでき、これによって、キャッシュ・ヒット率が向上し、Portalコンテンツをより詳細に無効化できます。大部分のコンテンツやメタデータについては、Oracle Portalによって、Web Cacheのメモリー内コンテンツがファイル・システムに基づいたポータル・キャッシュにバックアップされます。

Oracle Portalでは、そのコンテンツおよびメタデータ情報はデータベースに格納されます。データベースがシングル・ポイント障害とならないようにするため、そのデータベースはOracle Real Application Clustersを使用して構築します。

最後に、Oracle Web Cacheインスタンスの前にロード・バランサをフロントエンドとして配置し、Oracle Portalへの単一仮想アクセス・ポイントとします。ロード・バランサは、ブラウザから着信する外部トラフィックをロード・バランシングする以外に、Oracle Portalによって生成される内部トラフィックもロード・バランシングします(ポータル・ループバック・リクエストと呼ばれる)。また、Portalメタデータ・リポジトリから生成される無効化メッセージのロード・バランシングも実現します。そのような無効化リクエストは、Oracle Web Cacheに送信され、Oracle Web Cacheにキャッシュされている失効コンテンツを無効化します。Oracle Web Cacheのクラスタリング機能により、Oracle Web Cacheインスタンス全体のキャッシュ整合性が確保されます。


注意:

独自のプロデューサをデプロイする場合、プロデューサに冗長性を持たせ、ロード・バランサをフロントエンドとして配置してください。この手順により、システム内のシングル・ポイント障害がなくなります。

14.2.2.1 Oracle Portalプロセスの障害

特定のプロセスが停止した場合でも、各コンポーネントの冗長性により、Oracle Portalは継続的に機能します。Oracle Portalによってリクエストが再試行されないことに注意してください。したがって、特定のリクエストの処理中に障害が発生した場合、そのリクエストは失敗します。

14.2.2.2 Oracle Portalノードの障害

Oracle Portalノードの障害の詳細は、第14.1.3.2項「一般的なコンポーネント・ノード障害」を参照してください。

14.2.2.3 Oracle Portal WebLogic管理対象サーバーの障害

Oracle Portal WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。

14.2.2.4 データベース障害からのOracle Portalの保護

Oracle Portalのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。

14.3 Oracle Reportsと高可用性の概要

この項では、Oracle Reportsに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Reportsデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。


注意:

Oracle Fusion Middleware 11g リリース1 (11.1.1)は、Reports管理対象サーバーのクローニングをサポートしません。


注意:

アクティブ/アクティブ構成では、Webクライアントのみがサポートされます。コマンドライン・クライアント(rwclient)はサポートされていません。rwclientは名前により特定のReports Serverに接続され、特定のReports Serverの指定可能なインスタンスは1つのみです。

14.3.1 Oracle Reportsの単一インスタンスの特性

Oracle Reportsサービスは、Oracle Fusion Middlewareのレポート公開コンポーネントです。それは、形式と場所を問わずどのようなデータでも動的に取得、書式設定および配布する高品質な本番レポートを作成するためのエンタープライズ・レポート・サービスです。Oracle Reportsサービスを使用して、Webベースと非Webベースの両方の環境で公開できます。

次の表は、Oracle Reports固有のコンポーネントを示しています。

表14-2 Oracle Reportsコンポーネント

コンポーネント 説明

Oracle Reports Server

Reports Server (rwserver)は、クライアント・リクエストを処理します。これには、認証と認可の確認、スケジューリング、キャッシング、配布(カスタムやプラガブルな出力宛先への配布を含む)などの様々なサービスにリクエストを送り出すことも含まれます。また、Reports Serverによって、リクエストされたレポートを生成するためのランタイム・エンジンが作成され、Reports Serverキャッシュから完成レポートがフェッチされ、ジョブの準備が完了したことがクライアントに通知されます。Reports Serverは、スタンドアロンでもインプロセスでも実行できます。

Oracle Reports Engine

SQLベースとプラガブル・データ・ソースベースのレポートを実行するためのコンポーネントが組み込まれています。これによって、データ・ソースにおけるリクエスト・データのフェッチ、レポートの書式設定、キャッシュへの出力の送信、およびReports Serverへのジョブ完了通知が行われます。

Oracle Reports Engine

Reports Engineは、SQLベースとプラガブル・データ・ソースベースのレポートを実行するためのコンポーネントが組み込まれています。これによって、データ・ソースにおけるリクエスト・データのフェッチ、レポートの書式設定、キャッシュへの出力の送信、およびReports Serverへのジョブ完了通知が行われます。

Oracle Reports Cache

正常に実行されたレポートの出力を格納するために、使用します。これを行うことによって、同じレポートを繰り返して実行する必要がありません。

Oracle Reports Queue

レポート・リクエストのリスト。処理能力が利用可能になったときに、キュー内の次のレポートが実行されます。

Oracle Reports Customer Databases

通常、様々なデータベース(カスタマ・データベースと呼ばれます)に格納された情報を使用してレポートはコンパイルされます。

Oracle Single Sign On

Oracle Single Sign-On (SSO)を使用して、Oracle Reportsへのアクセスを制限することをお薦めします。

14.3.1.1 Oracle Reportsの状態情報

Oracle Reportsの状態情報は、ジョブ・メタデータのみです。たとえば、実行対象レポートに関する情報や実行時のパラメータなどがあります。これは多くの場合、レポート・キューと呼ばれます。この情報は、オペレーティング・システム・ファイルのservername.datまたはデータベースに格納されます。

14.3.1.2 Oracle Reportsの外部依存性

Oracle Reportsでは、Oracle HTTP Serverによるリクエストの処理が必要です。オプションで、これらのリクエストをOracle Web Cacheによってキャッシュできます。その場合、それはロード・バランサとしても機能します。

14.3.1.3 Oracle Reports固有の構成ファイル

次の表に、Oracle Reportsによって使用される構成ファイルのリストと場所を示します。

ファイル APPHOST1の場所 APPPHOST2の場所

rwserver.conf

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configuration/

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configuration/

reports_ohs.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

14.3.1.4 Oracle Reportsの接続の再試行

この項では、次に示す接続の再試行について説明します。

  • Oracle Portalデータベース接続の再試行:

    Reports ServerからOracle Portalデータベース・スキーマへの接続が切断された場合、Reports Serverは、エラー生成前に接続の再確立を試行します。再接続に成功した場合、Reports Serverを再起動する必要はありません。

  • Oracle Internet Directory接続の再試行:

    Oracle Internet Directory接続が失効した場合、ReportsサーブレットとReports Serverは、エラー生成前に接続の再確立を試行します。再接続に成功した場合、Reports Serverを再起動する必要はありません。

  • Oracle Metadata RepositoryおよびOracle Identity Managementの停止:

    Oracle Metadata Repository(セキュリティ・メタデータ格納場所)の停止によってReports Serverは停止しません。Oracle Metadata Repositoryが使用できない場合、Reports Serverでは、コンポーネントが使用できなくなるとその結果として新しいリクエストが拒否されます。Oracle Metadata Repositoryが復帰してオンラインになると、Reports Serverはリカバリし、新しいリクエストの受信と処理を開始します。

    Oracle Identity Managementコンポーネントが使用できなくなった場合、Oracle Metadata Repositoryの停止の場合と同様に、Reports Serverでは新しいリクエストが拒否されます。

  • Reports Serverのタイムアウト:

    Reports Serverでは、リクエストがデータベースから返されるまでの待機時間のタイムアウトを構成できます。このタイムアウトは、有効なレポートを実行するために十分な長さの時間にする必要があるだけでなく、長すぎない値に設定する必要もあります。

14.3.1.5 Oracle Reportsのプロセス・フロー

レポートの実行プロセスには、次のようにOracle Reportsサービスのコンポーネントが関連しています。

  1. クライアントは、URL(Web)を経由してサーバーと通信することでレポートをリクエストします。

  2. Reports Serverは、リクエストを次のように処理します。

    リクエストにTOLERANCEオプションが含まれている場合、Reports Serverではそのキャッシュにそのリクエストを処理するための出力が存在しているかどうかが確認されます。そのキャッシュに適切な出力がある場合、レポートは再実行されず、その出力が即座に返されます。

    そのリクエストが現在実行中のジョブと同じ場合、レポートは再実行されず、現在のジョブの出力が再利用されます。

    これらの条件のどちらも満たされない場合:

    • Oracle Reportsサーブレット(rwservlet)でSSOが有効になっている場合、認証について確認されます。その後、セキュアなReports Serverによって、Oracle Internet Directoryが使用されてユーザーが認可されます。Oracle Reportsサーブレット(rwservlet)でSSOが無効になっている場合、セキュアなReports Serverによってユーザーの認証と認可が行われます。

    • レポートがスケジュール済である場合、Reports Serverによって、スケジュール済ジョブ・キューにリクエストが格納され、レポートはスケジュールに従って実行されます。レポートがスケジュールされていない場合、それは現行ジョブ・キューに格納され、Reports Engineが使用可能になったときに実行されます。

  3. 実行時に、Reports ServerによってReports Engineが作成され、そのエンジンにリクエストが送信され、実行されます。

  4. Reports Engineによってデータが取り出され、書式設定されます。

  5. Reports EngineによりReports Serverキャッシュに移入されます。

  6. Reports Engineにより、レポートの準備完了がReports Serverに通知されます。

  7. Reports Serverによって、キャッシュがアクセスされ、レポートが送信されます。そして、URL、コマンドライン、またはcgicmd.datファイルのキーワード・セクション(URLリクエストのみ)で指定されたランタイム・パラメータに従ってレポートが出力されます。

リクエストの実行中にレポート・サーバーが停止した場合、そのリクエストを再送信する必要があります。再送信すると、障害が発生していないレポート・サーバーのいずれかによってそのリクエストが処理されます。

14.3.1.6 Oracle Reportsのログ・ファイル

次の表に、Oracle Reportsによって使用されるログ・ファイルを示します。

ファイル 場所 説明

WLS_REPORTS.log

DOMAIN_HOME/servers/WLS_REPORTS/logs

WebLogic管理対象サーバーのログ・ファイル

WLS_REPORTS.out

DOMAIN_HOME/servers/WLS_REPORTS/logs

WebLogic管理対象サーバーのサプリメンタル・ログ・ファイル:これは、一般的にWebLogicの問題について最初に検索される場所です。

rwservlet_diagnostic.log

DOMAIN_HOME/servers/WLS_REPORTS/logs

Reportsサーブレットに関するログ情報

rwserver_diagnostic.log

DOMAIN_HOME/servers/WLS_REPORTS/logs

Reports Serverに関するログ情報

14.3.2 障害からのOracle Reportsの保護および必要な対応

図14-3は、Oracle Reportsの高可用性デプロイメントの例を示しています。

図14-3 Oracle Reportsの高可用性デプロイメント

Oracle Reportsの高可用性デプロイメント
「図14-3 Oracle Reportsの高可用性デプロイメント」の説明

図14-3に示すように、Oracle Real Application Clustersデータベースにより、レポート・キュー用の高可用性リポジトリが実現されます。高可用性構成では、各Reports Serverは同じレポート・キューにアクセスします。共有レポート・キューによって、リクエストはどれも1回のみ処理されますが、デプロイメント内のどのReports Serverでも処理できます。

通常、様々なデータベースに格納された情報を使用してレポートはコンパイルされ、前述の図では、これらのデータベースをカスタマ・データベースと記載しています。

Reportsキャッシュを十分に活用するには、実装内のどのReports Serverからでもキャッシュを使用できるようにする必要があります。このようにして、いずれかのReports Serverによって生成されたレポートは、どのReports Serverからでも再利用や処理ができます。図14-3では、共有ディレクトリを使用してReportsキャッシュを使用可能にしています。

Oracle Reportsへのアクセスを制限するためのシングル・サインオン(SSO)の使用は必須ではありませんが、多くの組織ではOracle Single Sign-onを使用してOracle Reportsへのアクセスを制限しています。この章では、Oracle Single Sign Onを使用してデプロイメントを保護するために必要な手順についても説明します。

Reportsの高可用性デプロイメントには、インプロセスReports Serverをお薦めします。インプロセスReports ServerはOracle WebLogic Server内部で実行され、Reports Server自体をクラスタ化して、高可用性を確実に保持できます。

高可用性分散構成でWeb Cacheを使用する場合、すべての分散キャッシュのコンテンツに整合性があることが重要です。たとえば、あるレポートについて、どのOracle Web Cacheインスタンスからでも同じキャッシュ・コピーが使用できます。キャッシュされたコンテンツが無効になった場合、Webキャッシュのすべてで無効になることが不可欠です。これを実現するために、Webキャッシュ・クラスタリングが使用されます。

前述の図には、Web Logic管理サーバーが含まれており、それをAPPHOST2に配置する方法を示しています。配置方法を決定するには、このマニュアルで該当する章を参照してください。

14.3.2.1 Oracle Reportsプロセスの障害

Reports Serverがハングしたり応答に失敗したが、WebLogic管理対象サーバーではハングや応答失敗が発生していない場合、WebLogic管理対象サーバーを手動で再起動する必要があります。

14.3.2.2 Oracle Reportsノードの障害

Oracle Reportsノードの障害の詳細は、第14.1.3.2項「一般的なコンポーネント・ノード障害」を参照してください。

14.3.2.3 Oracle Reports WebLogic管理対象サーバーの障害

Oracle Reports WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。

14.3.2.4 Oracle Reportsデータベースの障害

Oracle Reportsのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。

14.4 Oracle Formsと高可用性の概要

この項では、Oracle Formsに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Formsデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。

14.4.1 Oracle Formsの単一インスタンス・コンポーネントの特性

Oracle Fusion Middleware Forms Servicesアーキテクチャでは、Webベースのアプリケーションと同様にクライアントとHTTPリスナーとの間の接続は1つのみです。HTTPリスナーによって、リクエストがFormsリスナー・サーブレットにルーティングされ、そこでFormsクライアントからFormsランタイムへのリクエストのルーティングが制御されます。

FormsクライアントとFormsランタイムとの間の通信は、常にHTTPリスナーを経由し、ネットワークに開いているポートは1つのみになります。

クライアントはHTTPリクエストを送信し、HTTPリスナー・プロセスからHTTPレスポンスを受信します。HTTPリスナーがクライアントに対してネットワーク・エンドポイントとして機能し、他のサーバー・マシンおよびポートはファイアウォールで公開されません。

14.4.1.1 Oracle Formsの状態情報

Oracle Formsは、ステートフル・アーキテクチャを採用しています。各ランタイム・プロセスでは、サービスの提供先となるクライアントのために状態が作業メモリーに保持されます。状態は複数のランタイム・プロセス間でシリアライズや共有されませんし、そのようにできません。

14.4.1.2 Oracle Formsデータベースの要件

Oracle Formsでは、相互作用の対象となるデータベースとのアクセスのみを必要です。Oracle Forms自体には特別な要件はありません。

14.4.1.3 Oracle Formsのリクエスト・フロー

Oracle Formsのリクエスト・フローは次のようになります。

  1. ユーザーがWebページからリンクを選択するか、ブラウザでURLを直接入力します。

  2. 渡されたURLがHTTPリスナーによって解釈され、ブラウザにForms Javaクライアントを示す<EMBED>タグまたは<OBJECT>タグ(使用されているブラウザによって異なる)を含むHTMLページが表示されます。渡されたURLでは、Formsサーブレットをコールし、Webサーバー上にあるbase.htmlファイルに基づいてHTMLページを動的に作成します。

  3. クライアントは、HTTPリスナーによって処理されたHTMLファイルを受信します。HTMLファイル内のタグには、Forms Javaクライアントを構成するJavaクラス・ファイルを探すために必要な情報があります。HTMLファイルのタグ内で、実行するFormに関する情報、およびログイン情報などFormsセッションに渡す他のすべてのパラメータに関する情報を指定します。タグ定義には、実行するForms Servicesに関する指示、およびJavaクライアントの外観(ルック・アンド・フィールや色のスキームなど)のカスタマイズに役立つパラメータも多数含まれています。

    HTMLファイルには、他のHTML属性が含まれることもあります。クライアント上でJREの特定のバージョンを使用する特定アプレットを実行するようにブラウザに指示する属性などです。

  4. その後、HTMLファイルに指定されている場所のJavaクラス・ファイルをブラウザはHTTPリスナーに対して要求します。これを定義するためにHTMLファイルのCODEBASEパラメータが使用されます。このファイルは個別にダウンロードできますし、アーカイブにもできます。このアーカイブには、.JAR拡張子が付きますが、アプレットに必要な個別クラス・ファイルすべてを含むZIPファイルと考えることもできます。JARファイルを使用すると、Javaクライアントのダウンロードが高速になり、後続のコールのためにクライアント上でキャッシングが可能になります。ARCHIVEパラメータにより、どの.JARファイルを使用するのかが定義されます(存在する場合)。JREプラグインにより、HTTPリスナー上で使用可能なFormsクライアント用Javaコードのバージョンを確認する追加手順が実行され、現在そのプラグインでキャッシュされているバージョンよりも新しいバージョンであることが判明した場合にのみダウンロードされます。

  5. クラス・ファイルやJARファイルはブラウザにダウンロードされ(存在していない場合)、Javaアプレットが起動します。

  6. Javaクライアント・アプレットからリクエストが送信され、HTTPリスナーを経由してFormsリスナー・サーブレットへのFormsセッションが開始します。Formsリスナー・サーブレットは、HTMLファイルのタグ内のserverURLパラメータによって定義されます。

  7. Javaクライアントから接続リクエストを受信すると、Formsリスナー・サーブレットはこのクライアントのために新しいFormsランタイム・プロセスを開始します。formsweb.cfg構成ファイルのサーブレット初期化用envFileパラメータを特定の環境ファイルに設定することで、各ランタイム・プロセスに対してユーザー固有の環境を定義できます。

  8. このクライアントに割り当てられたFormsランタイム・プロセスにより、HTMLファイルで指定されているモジュール、それらのフォームに必要なライブラリおよびメニューすべてがロードされます。FormsクライアントとFormsランタイム・プロセスとの間におけるすべての通信は、Formsリスナー・サーブレットを経由します。

  9. ユーザーがデータベース・ログイン情報を入力していない場合は、その入力を求められ、データベース・サーバーへの接続が確立されます。

  10. これでユーザーの作業の準備が完了しました。

14.4.1.4 Oracle Forms構成の永続性

Oracle Formsでは、起動構成のために次のいくつかのファイルを使用します。

  • formsweb.cfgには、ランタイム・プロセスのForms固有起動パラメータ(以前はコマンドラインで指定)が保持されます。特定のセクションが利用されていない場合に使用されるデフォルト・セクションと、1つ以上のユーザー・セクション(ユーザー・セクション固有のパラメータを保持)で構成されます。これらのセクションは、アプリケーションと呼ばれるもの(同じ論理ユニットに属する一連のフォーム)に対応しています。

    formsweb.cfgは、次のディレクトリにあります。

    DOMAIN_HOME/config/fmwconfig/servers/<FORMS_MANAGED_SERVER>/applications/formsapp_11.1.1/config

  • default.envには、以前は環境変数で指定されていた起動パラメータが保持されます。Windowsでは、これらの変数はシステム・レジストリでも指定できます。

    このファイルは、formsweb.cfgと同じディレクトリにあります。

    DOMAIN_HOME/config/fmwconfig/servers/<FORMS_MANAGED_SERVER>/applications/formsapp_11.1.1/config

    別の名前でカスタマイズ済envファイルも作成できます。そのようなファイルが存在する場合は、formsweb.cfgで指定すると検出されます。

  • base.htmlおよびbasejpi.htm、またはそれらのカスタマイズ・バージョンには、Formsクライアント・アプレットを起動するHTMLコードのテンプレート構造が保持されます。

    これらのファイルは次のディレクトリにあります。

    ORACLE_INSTANCE/config/FormsComponent/forms/server

  • Registry.datには、フォント、アイコンおよびイメージのデフォルトの場所および検索パスが保持されます。このファイルは、次の場所にあります。

    DOMAIN_HOME/config/fmwconfig/servers/<FORMS_MANAGED_SERVER>/applications/formsapp_11.1.1/config/forms/registry/oracle/forms/registry

  • frmweb.resには、Formsクライアントのキー・バインド定義が保持されます。このバインドは、キーボード・キーと、それによってトリガーできる内部Forms関数との間の関係を定義します。UNIXの場合、このバインド・ファイルは次の場所にあります。

    ORACLE_INSTANCE/config/FormsComponent/forms/admin/resource/<language>

    ここで、<language>は、2文字の言語デノミネータですWindowsの場合、このファイルは次の場所にあります。

    ORACLE_INSTANCE/config/FormsComponent/forms

    Windowsの場合、言語はその略語をファイル名の最後に追加することで定義されます。たとえば、フランス語の場合はfrmwebf.resになります。

  • jvmcontroller.cfgは、JVMコントローラを構成するためのファイルです。システムに対して構成されるコントローラは、すべてこのファイルで定義されます。このファイルは、次のディレクトリにあります。

    ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/

14.4.1.5 Oracle Formsランタイムの考慮事項

Oracle Fusion Middleware Forms Servicesは、3つのコンポーネントで構成されています。それらは、エンド・ユーザーのクライアント・マシンに自動的にダウンロードされてキャッシュされるFormsクライアント、中間層のFormsリスナー・サーブレット、およびFormsランタイムです。

Oracle Formsクライアント(Javaアプレット)

ユーザーがFormsセッションを実行すると、Thin 100パーセントJavaアプレットであるFormsクライアントがOracle Fusion Middlewareアプリケーション・サーバーから動的にダウンロードされます。この汎用Javaアプレットは、中間層の関連付けられたFormsランタイム・プロセスに対してユーザー・インタフェースをレンダリングするためのクラスを提供し、ユーザーの相互作用や視覚的なフィードバックを処理します。それらの例には、複数のアイテム間のナビゲートやチェック・ボックスの選択によって生成されることなどがあります。すべてのFormsアプリケーションに同じJavaアプレットが使用されるため、それは1回のみダウンロードされてクライアントにキャッシュされ、後続のFormsアプリケーションに対して使用可能になります。

ブラウザでJavaアプレットを実行するためには、Java Runtime Engine(JRE)がインストールされている必要があります。JREはクライアントにインストールされ、プラットフォーム依存です。

Oracle Formsランタイム・プロセス

Formsランタイム・プロセスは、Formsクライアントのかわりにデータベースへの接続を維持するプロセスです。Formsアプリケーションを含むページにユーザーがアクセスしたときに、このプロセスは作成されます。ユーザーがFormsアプリケーションを閉じるかブラウザ・ウィンドウを終了すると即座に、このプロセスは自動的に停止します。

Oracle Formsリスナー・サーブレット

Formsリスナー・サーブレットによって管理される処理は、次のとおりです。

  • ユーザーがFormsアプリケーションの実行をリクエストした際、クライアントごとにFormsランタイム・プロセスが作成される処理。

  • ユーザーがFormsアプリケーションを閉じるかブラウザ・ウィンドウを終了したときに、Formsリスナー・サーブレットではランタイム・プロセスの停止も行います。

  • クライアントとそれに関連付けられたFormsランタイム・プロセスとの間のネットワーク通信処理。

14.4.1.6 Oracle Formsのプロセス・フロー

Oracle Formsの実行プロセスには、次のようにOracle Forms Servicesの様々なコンポーネントが関連しています。

  1. クライアントは、URLを経由してサーバーと通信することでフォームをリクエストします。

  2. Oracle HTTP Serverは、リクエストをOracle WebLogic Serverにルーティングします。

  3. Oracle WebLogic Serverは、フォームを実行するためのFormsランタイム・プロセスを作成します。

中間層のサーバーで障害が発生したりサーブレット・セッションが中断した場合、アプリケーションを再起動することで、どちらの障害からでもリカバリします。それにより、新しいFormsランタイムが作成され、保存されていないデータを再入力できます。保存されていないデータによってデータベースは破損しません。それは、Formsではアトミック・トランザクションが使用され、それにより定義済で整然とした方法でデータベースの保存が実行されるためです。

14.4.1.7 Oracle Forms構成ファイル

次の表に、Oracle Formsによって使用される構成ファイルを示します。

ファイル APPHOST1の場所 APPHOST2の場所

formsweb.cfg

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config

default.env

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config

base(jpi).htm

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config

Registry.dat

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config/forms/registry/oracle/forms/registry

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS2/applications/formsapp_11.1.1/config/forms/registry/oracle/forms/registry

frmweb.res

UNIX:

ORACLE_INSTANCE/config/FormsComponent/forms/admin/resource/<language>

Windows:

ORACLE_INSTANCE/config/FormsComponent/forms

UNIX:

ORACLE_INSTANCE/config/FormsComponent/forms/admin/resource/<language>

Windows:

ORACLE_INSTANCE/config/FormsComponent/forms

jvmcontroller.cfg

ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/

ORACLE_INSTANCE/config/FRComponent/frcommon/tools/jvm/

forms.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

14.4.1.8 Oracle Formsの外部依存性

Oracle Formsでは、リクエストに対応するためにOracle HTTP Serverが必要です。オプションで、これらのリクエストをOracle Web Cacheによってキャッシュできます。その場合、それはロード・バランサとしても機能します。

Oracle Formsは、クライアント上でSun社のJavaプラグイン(JRE)を使用し、Forms Javaクライアントを実行します。

14.4.1.9 Oracle Formsのログ・ファイル

次の表に、Oracle Formsによって使用されるログ・ファイルを示します。

ファイル 場所 説明

WLS_FORMS.log

DOMAIN_HOME/servers/WLS_FORMS/logs

WebLogic管理対象サーバーのログ・ファイル

WLS_FORMS.out

DOMAIN_HOME/servers/WLS_FORMS/logs

WebLogic管理対象サーバーのサプリメンタル・ログ・ファイル:これは、一般的にWebLogicの問題について最初に検索される場所です。

各種ファイル

ORACLE_INSTANCE/FormsComponent/forms/trace

Formsトレース・ファイル: Formsランタイム・プロセスが失敗すると生成されます。

このファイル名の形式は次のとおりです。

<forms_runtime_process>_dump_<process_id>

Formsランタイム・プロセスでは、正常な動作の場合はログ・ファイルに書込みを行いません。

各種ファイル

DOMAIN_HOME/servers/WLS_FORMS/logs

リスナー・サーブレットのログ

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

Oracle Formsには、シリアライズ可能な状態がありません。これは、透過的フェイルオーバーが可能でないことを意味します。ランタイム・プロセスが失敗した場合、そのサーバー・プロセスによって処理されているクライアント・プロセスも失敗します。Oracle Formsは、アトミック・データベース・トランザクションを採用しています。アトミック・トランザクションでは、一連のデータ、レコードまたは一連のレコードは、完全に保存されるか、まったく保存されないかのいずれかです。その結果、障害が発生すると、保存されていないデータは、定義済の正確な方法により失われます。そのデータはアプリケーションが再起動したときに、ユーザーによって再入力する必要があります。実行マシンに障害が発生したためにプロセスが失敗すると、ユーザー・ベースにサービスを提供する既存の処理能力の大部分またはすべてが、使用できなくなる場合があります。このシナリオでは、アプリケーション全体が使用できなくなる可能性があります。継続的に使用できるようにするためのオプションとしては、アクティブ/アクティブ構成またはアクティブ/パッシブ構成のいずれかで処理能力に冗長性を持たせることがあります。

図14-4 Oracle Formsの高可用性デプロイメント

Oracle Formsの高可用性デプロイメント
「図14-4 Oracle Formsの高可用性デプロイメント」の説明

14.4.2.1 Oracle Forms N+1の冗長性

N+1とは、処理能力に冗長性を持たせる手法のことです。その手法は、ハードウェアではグループ単位よりもユニット単位で破損する傾向があるという考えに基づいています。つまり、コンピュータ・ネットワークでは、複数のコンポーネントを同時に失う場合より、1つのコンポーネントを失う場合が多いことを意味します。N+1の原則では、ロードのピーク時にユーザー・ベース全体にサービスを処理するために必要なマシンの台数に加えて、そのセット内で最大の処理能力を有するマシンと同じ処理能力の追加ユニットを設置するようにします。これは、フェイルオーバーがマシン・レベルで行われるため、通常、アクティブ/パッシブ・フェイルオーバーと呼ばれます。

デプロイメント内にユーザー・ベース全体を処理可能なサーバーが6台ある場合に、それらが理想的に構成されていると、それらにはすべて、HTTP Server、JavaランタイムおよびFormsランタイムがインストールされています。どのサーバーも負荷が過剰にならないようにハードウェア(またはソフトウェア)型ロード・バランサがあります。ロード・バランサには、スタンバイというラベルが付いた1台のマシンが認識されます。そのマシンは、そのセット内の残りのマシンの中で最大の処理能力を有するマシンと同じ処理能力を持ち、残りのマシンすべてに対して理想的に構成されていますが、そのマシンにはルーティングされません。アクティブ/パッシブ・シナリオでは、スタンバイ・マシンは稼働している必要はありません。アクティブ/アクティブ・シナリオでは、それはセットのアクティブ部分の場合があり、継続的に余剰の処理能力が確保されます。

ここで、マシンのいずれかに障害が発生したと仮定します。

マシンのいずれかに障害が発生した場合、スタンバイ・マシンがオンラインになり、ロード・バランサでは新しいリクエストをそのマシンにもルーティングし、障害が発生したマシンを無視するように再構成されます(いくつかのハードウェア・ロード・バランサでは、これらの2つの手順が自動的に実行されます)。アクティブ/アクティブ・デプロイメントでスタンバイ・マシンがすでに実行中で、ユーザー・ベースにサービスを処理している場合、クライアント上のブラウザを再起動するために要する時間と同程度に停止時間が短くなる場合があります。アクティブ/パッシブ・デプロイメントでスタンバイ・マシンが実行中ではないときに、起動が必要であるだけでなく、ロード・バランサを手動で再構成する必要もある場合、停止時間はさらに長くなります。

14.4.2.2 Oracle Forms N+Mの冗長性

フェイルオーバー処理能力を強化するために、複数のスタンバイ・マシンを使用できます。これは通常、N+Mと呼ばれます。複数のマシンに同時に(またはほぼ同時に)障害が発生する確率はかなり低くなりますが、そのような状況に対処できる必要がある場合、N+M設定が可能でありますが、おそらくその設定が必要になります。

デプロイメント内のすべてのマシンに影響する状況(1箇所にあるマシンがすべて破壊される自然災害など)において冗長性を実現するには、このデプロイメントを地理的に別々の場所に複製できます。

14.4.2.3 Oracle Formsの仮想マシン

仮想マシンを使用するデータセンターでは、スペア・ハードウェアを使用してスタンバイ・マシンをオンラインにできるので、大変低いコストで実装できます。

14.4.2.4 Oracle Forms構成のクローニング

環境のクローニングの重要性は、前述の項で説明したシナリオから明白です。1台のマシンの環境に行われたすべての変更は、スタンバイ・マシンも含めて他のすべてのマシンにも適用する必要があります。これにより、特にスペア・マシンが仮想である場合、問題が発生します。仮想マシンのイメージは、他のマシンに行われた変更と同期している必要があります。

14.4.2.5 Oracle Formsプロセスの障害

Oracle Formsプロセスの障害の詳細は、第14.1.3.1項「Oracle Web CacheおよびOracle HTTP Serverのプロセス障害」を参照してください。

14.4.2.6 Oracle Formsノードの障害

Oracle Formsノードの障害の詳細は、第14.1.3.2項「一般的なコンポーネント・ノード障害」を参照してください。

14.4.2.7 Oracle Forms WebLogic管理対象サーバーの障害

Oracle Forms WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。

14.4.2.8 Oracle Formsデータベースの障害

Oracle Formsのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。

14.5 Oracle Discovererと高可用性の概要

この項では、Oracle Discovererに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Discovererデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。

14.5.1 Oracle Discovererの単一インスタンスの特性

Discovererをインストールする場合、図14-5に示すように、単一インスタンス内にDiscovererトポロジを作成します。インストール後、Discoverer用に他のタイプのトポロジを構成できます。

図14-5 単一インスタンスのDiscovererトポロジ

図14-5の説明が続きます
「図14-5 単一インスタンスのDiscovererトポロジ」の説明

14.5.1.1 Oracle Discovererランタイムの考慮事項

図14-6は、複数のDiscovererコンポーネント間において実行時に行われる相互作用を表しています。

図14-6 複数のDiscovererコンポーネント間において実行時に行われる相互作用

図14-6の説明が続きます
「図14-6 複数のDiscovererコンポーネント間において実行時に行われる相互作用」の説明

Discoverer Servletは、管理対象サーバー上にデプロイされるJava EEアプリケーションであり、管理コンソールやOracle Enterprise Manager Fusion Middleware Controlを使用して、起動と停止ができます。Discoverer Servletは、ステートレス・プロセスです。

Discoverer Session Serverは、OPMN管理CORBAコンポーネントであり、データベースへの接続やワークブックのオープンなどのDiscoverer操作を実行します。このセッション・サーバーは、Discoverer Servletとデータベースとの間のリンクを提供します。アクティブなユーザー・ログイン・セッションごとに1つのセッション・サーバー・コンポーネントがあります。Discoverer Session Serverはステートフル・プロセスであり、状態はメモリーにのみ格納されます。

Discoverer Preference Serverは、OPMN管理コンポーネントであり、すべてのDiscovererユーザーにプリファレンス設定(デフォルトとユーザー定義の両方)を提供します。これらのプリファレンスにより、Discovererの動作が制御されます。Preference Serverの起動および停止の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドを参照してください。

Discoverer Services Statusは、OPMNによって管理されるダミー・プロセスです。セッション・サーバーを作成するには、このプロセスが実行中である必要があります。


注意:

Discoverer Servletおよびセッション サーバーは、同じマシン上で実行する必要があります。

Oracle Discovererの外部依存性

Discovererには、Oracle HTTP ServerおよびEnterprise Manager Fusion Middleware Controlが必要です。

リポジトリ作成ユーティリティ(RCU)を使用して、Discovererのデータベース・スキーマおよびポートレット・スキーマを(Discovererをインストールする前に)ロードする必要があります。

Discovererは、DiscovererワークブックおよびDiscoverer End User Layerを含むカスタマ・データベースおよびその他のデータ・ソースと相互作用します。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererデータベース層に関する項を参照してください。

Oracle Web Cacheを使用して、Discoverer用にロード・バランシングを構成できます。

DiscovererのPortlet Providerコンポーネントは、Oracle PortalおよびOracle Web Centerにポートレットを提供できます。

DiscovererのWebサービス・コンポーネントは、外部クライアント(Oracle BI PublisherやOracle BI Enterprise Editionなど)がDiscoverer接続とワークブックを取得するために使用できます。

Oracle Single Sign-On(SSO)を使用してOracle Discovererへのアクセスを制限することをお薦めします(ただし、必須ではありません)。

Discovererのプロセス・フロー

Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererの動作に関する項参照してください。

接続プロトコル

クライアント・ブラウザは、HTTPリクエストをDiscoverer Java EEアプリケーションに送信します。

Discoverer Java EEアプリケーションは、WebLogic Serverデータ・ソースを使用してデータベース・スキーマにアクセスします。

Discoverer Session Server(非Java EEコンポーネント)は、OCIレイヤーを使用してデータ・ソースに接続します。

Discoverer Java EEアプリケーションおよびDiscoverer Session Serverプロセスは、CORBAを使用して通信します。

14.5.1.2 Oracle Discoverer ViewerおよびWeb Cache

Discoverer Viewerのパフォーマンスと可用性はOracle Web Cacheを使用して向上できます。Web Cacheをいつ、どのように使用するのかについては、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドの「Oracle Web CacheとのDiscoverer Viewerの使用方法」を参照してください。

14.5.1.3 Oracle Discoverer構成の考慮事項

Oracle Discovererの環境と動作は、Discovererプリファレンスおよび構成パラメータで制御します。

  • プリファレンスの一覧とプリファレンス設定の変更手順の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererのプリファレンスの管理に関する項を参照してください。

  • 構成パラメータは、configuration.xmlファイルに格納されています。構成パラメータおよびそれらのパラメータの設定の定義方法の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererの管理および構成に関する項を参照してください。

プリファレンスおよび構成パラメータが格納されているファイルの場所の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererの構成ファイルに関する項を参照してください。

14.5.1.4 Oracle Discovererデプロイメントの考慮事項

Discoverer Java EEアプリケーションは、基本的なデプロイメント・ディスクリプタを含んでいます。

  • discoverer.earファイルは、application.xml、jazn-data.xmlおよびweblogic-application.xmlのファイルで構成されています。

    これらのファイルは、DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/ディレクトリにあります。ここでDOMAIN_HOMEは、ドメイン・ディレクトリの名前です。

  • discoverer.warファイルには、custom-laf.xml、plus_versions.properties、uix-config.xml、portlet.xml、weblogic.xml、struts-config.xmlおよびweb.xmlのファイルが含まれています。

    これらのファイルは、DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/ディレクトリにあります。ここでDOMAIN_HOMEは、ドメイン・ディレクトリの名前です。

14.5.1.5 Oracle Discovererのログ・ファイルの場所

Discovererのログ・ファイルは、Enterprise Manager Fusion Middleware Controlで検索と表示ができます。

詳細は、Enterprise Manager Fusion Middleware Controlのオンライン・ヘルプを参照してください。

14.5.1.6 Discovererのログ・ファイル

次の表に、Oracle Discovererに使用されるログ・ファイルを示します。

ファイル 場所 説明

WLS_DISCO.log

DOMAIN_HOME/servers/WLS_DISCO/logs

WebLogic管理対象サーバーのログ・ファイル

WLS_DISCO.out

DOMAIN_HOME/servers/WLS_DISCO/logs

WebLogic管理対象サーバーのサプリメンタル・ログ・ファイル:これは、一般的にWebLogicの問題について最初に検索される場所です。

各種ファイル

ORACLE_INSTANCE/diagnostics/logs/Discoverer/Discoverer_Instance

プリファレンス・ストアを含むサプリメンタルDiscovererログ・ファイル

14.5.2 Oracle Discovererの障害からの保護および予想される動作

図14-7は、2つのDiscovererインスタンスで構成されるDiscovererトポロジを示しています。

各管理対象サーバーのDiscoverer Java EEアプリケーションは、1台のプリファレンス・サーバーと通信します。したがって、同じプリファレンスが両方のDiscovererインスタンスに適用されます。Discovererインスタンスは、同じマシン上にも異なるマシン上にも配置できます。

図14-7 複数インスタンスのDiscovererトポロジ

図14-7の説明が続きます
「図14-7 複数インスタンスのDiscovererトポロジ」の説明

次の各項では、Discovererに関連して特定の高可用性の考慮事項について説明します。高可用性を実現するために構成変更を行った後は、Oracle HTTP ServerおよびDiscoverer Java EEアプリケーションがデプロイされている管理対象サーバーを再起動する必要があります。

14.5.2.1 プリファレンス・サーバーのフェイルオーバー

クラスタ内のDiscoverer Java EEアプリケーションの障害検出および再起動は、WebLogic Serverによって管理されます。

プリファレンス・サーバーは、シングルトン・プロセスであり、クラスタ全体で1つのインスタンスのみが実行されます。

プリファレンス・サーバーのプロセスが停止した場合、OPMNによって自動的に再開されます。OPMNも停止した場合、管理者はプリファレンス・サーバーを手動で起動するか、プリファレンス・サーバーが構成されている別マシンにプリファレンスのあるファイル(reg_key.dcとpref.txt)を移動し、そのマシン上でプリファレンス・サーバーを起動する必要があります。

プリファレンス・サーバーをクラスタ内の別のノードで起動する場合、その新しいプリファレンス・サーバーを認識するようにDiscoverer Java EEアプリケーションを構成する必要があります。

14.5.2.2 セッション状態レプリケーションとフェイルオーバー

特定のDiscoverer HTTPセッションに関するリクエストを処理しているサーバーまたはマシンが停止した場合、後続のリクエストはクラスタ内の他の管理対象サーバーに転送されます。そのセッション状態は、新しいサーバーでレプリケートできます。このレプリケーションを実現するために必要な情報は、HTTPリクエスト(GET/POST)で入手できます。


注意:

リクエストを完了するためには、Discovererではセッション・サーバー(C++プロセス)が使用可能である必要があります。したがって、フェイルオーバーが発生すると、C++プロセスを作成してから必要な状態にする必要があるため、レスポンス時間がわずかに長くなります。

14.5.2.3 パフォーマンス上の推奨事項

Discoverer Java EE Servletは、受信したHTTPリクエストごとにセッション・サーバーのプロセスを作成します。複数のDiscovererインスタンス(管理対象サーバーおよび関連するoracleインスタンス)が1台のマシンに存在していると、すべてのDiscovererインスタンスでC++プロセスを同時に作成する場合があるためにCPUの負荷が非常に高くなることがあります。別のマシン上にDiscovererインスタンスを追加すると、同じマシン上に追加するよりもパフォーマンスが向上します。

14.5.2.4 クラスタ間の構成変更の伝播

どのような構成変更も、クラスタ内の各管理対象サーバーで個別に実装する必要があります。これは、configuration.xmlファイルをすべての管理対象サーバーにコピーすることにより実現できます。

構成ファイルの場所の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererの構成ファイルに関する項を参照してください。

14.5.2.5 クラスタワイドのアプリケーションのデプロイメント

各Discoverer Java EEアプリケーション・インスタンス(管理対象サーバー)は、Discovererコンポーネントを含むOracleインスタンスと関連付けられている必要があります。これらのコンポーネントは、インストール・プロセスの構成段階で作成されます。そのため、WebLogic Server管理コンソールから、管理対象サーバーをクラスタに追加したりDiscoverer Java EEアプリケーションをデプロイすることは、サポートされていません。

クラスタ内で定義されたすべての管理対象サーバーは、Discoverer Java EEアプリケーションのデプロイメントのターゲットとなります。

14.5.2.6 オンライン・アプリケーションのデプロイメント

Discoverer Java EEアプリケーション依存のjarファイルの大部分は、共有ライブラリを介して使用できます。これらの共有ライブラリにパッチを適用しても、Discoverer Java EEアプリケーションを再起動する必要はありません。

システム・クラスパスを介して実行できる次のjarファイルに対して変更を行った場合、Discoverer Java EEアプリケーションを再起動する必要があります。


WL_HOME/server/lib/weblogic.jar
ORACLE_HOME/modules/oracle.jrf_11.1.1/jrf.jar
ORACLE_HOME/opmn/lib/nonj2eembeans.jar
ORACLE_HOME/server/lib/ojdbc6.jar
ORACLE_HOME/opmn/lib/optic.jar
ORACLE_HOME/opmn/lib/iasprovision.jar
ORACLE_HOME/opmn/lib/ons.jar
ORACLE_HOME/modules/oracle.adf.share_11.1.1/oracle-el.jar
ORACLE_HOME/jlib/share.jar
ORACLE_HOME/jlib/jewt4.jar

14.5.2.7 Oracle Discovererプロセスの障害

Discoverer Java EEアプリケーションがデータベースにアクセスするためには、各データベースのエントリが、ORACLE_INSTANCE/config/tnsnames.oraファイル内に作成されている必要があります。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのtnsnames.oraファイルの構成に関する項を参照してください。

14.5.2.8 Oracle Discovererノードの障害

Oracle Discovererノードの障害の詳細は、第14.1.3.2項「一般的なコンポーネント・ノード障害」を参照してください。

14.5.2.9 Oracle Discoverer WebLogic管理対象サーバーの障害

Oracle Discoverer WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。

14.5.2.10 Oracle Discovererデータベースの障害

Oracle Discovererのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。

14.6 高可用性のためのOracle Portal、Forms、ReportsおよびDiscovererの構成

この項では、高可用性デプロイメントのためのOracle Portal、Forms、ReportsおよびDiscovererの構成手順について説明します。この項の項目は次のとおりです。


注意:

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


注意:

これらの項においてリストされるホスト名とポートは、このデプロイメント例を示すために使用しています。実際のデプロイメントを構成するときは、独自のホスト名とポートを指定できます。

14.6.1 前提条件

Oracle Portal、Forms、ReportsおよびDiscovererをインストールする前に、この項で説明する前提条件を確認してください。

14.6.1.1 依存関係

Oracle Single Sign-Onを使用している場合、高可用性アイデンティティ管理フレームワークが使用できることが前提になります。Oracle Portal、Forms、ReportsおよびDiscovererでは、シングル・サインオンを使用します。これはOracle Identity Management 10gで入手可能です。

14.6.1.2 ネットワークの要件

この項では、ネットワーク要件について説明します。

14.6.1.2.1 ロード・バランサ

複数のOracle Webサーバー間でリクエストを分散させるには、ロード・バランサが必要です。この外部ロード・バランサには、次の機能が必要です。

  • 仮想サーバー名とポートを構成する機能

  • プロセス障害を検出する機能

  • Oracle HTTPおよびHTTPSのためにポート(HTTP、HTTPS)を監視する機能

  • SSL変換機能(必要な場合)

14.6.1.2.2 ロード・バランサの構成: 仮想サーバー名とポート

ロード・バランシング・ルーターを使用する場合、次のものが使用可能になるように構成する必要があります。

ロード・バランサが終着点となるSSLトラフィックを使用している場合

ポート443(HTTPSリスニング・ポート)上でmysite.mycompany.comに対するリクエストをリスニングする仮想IPアドレス(VIP1): それらをアプリケーション層のOracle Web Cache(WEBHOST1およびWEBHOST2、ポート7777(HTTPリスニング・ポート)上で稼働)にバランシングします。プロトコル変換を実行するようにロード・バランシング・ルーターを構成する必要があります。

サイトSSLを使用している場合

ポート443(HTTPSリスニング・ポート)上でmysite.mycompany.comに対するリクエストをリスニングする仮想IPアドレス(VIP1): それらをアプリケーション層のOracle Web Cache(WEBHOST1およびWEBHOST2、ポート443(HTTPSリスニング・ポート)上で稼働)にバランシングします。

ロード・バランサが終着点となるHTTPトラフィックを使用している場合

ポート80(HTTPリスニング・ポート)上でmysite.mycompany.comに対するリクエストをリスニングする仮想IPアドレス(VIP1): それらをアプリケーション層のOracle Web Cache(WEBHOST1およびWEBHOST2、ポート7777(HTTPリスニング・ポート)上で稼働)にバランシングします。

Web Cache

  • ポート9401(HTTPリスニング・ポート)上でmysite.mycompany.comに対するリクエストをリスニングする仮想IPアドレス(VIP1): WEBHOST1およびWEBHOST2、ポート9401(HTTPリスニング・ポート)上でそれらをアプリケーション層のOracle Web Cacheにバランシングします。


    注意:

    セキュリティ上の理由から、ロード・バランシング・ルーター上のポート9401、9402および9403は、外部ユーザーから参照できないようにする必要があります。

  • Oracle Web CacheのHTTP/HTTPS監視: ロード・バランシング・ルーターでは、動作していないコンピュータを検出し、それが再度動作するまでそのコンピュータへのリクエストのルーティングを停止するように構成する必要があります。HTTPリクエスト・ポートと無効化ポートの2つのOracle Web Cacheポートを監視する必要があります。

    ポート7777を監視するには、ロード・バランシング・ルーター構成で次のURLを使用します。

    hostname:port/_oracle_http_server_webcache_static_.html

    例:

    http://webhost1.mycompany.com:7777/_oracle_http_server_webcache_static_.html

    ロード・バランシング・ルーターがこのURLからのレスポンスを受信した場合、Oracle Web Cacheインスタンスが稼働しています。レスポンスを受信しない場合、プロセスまたはサーバーが停止しており、ロード・バランシング・ルーターはすべてのリクエストをアクティブなコンピュータに転送します。

    ポート9401を監視するには、ロード・バランシング・ルーター構成で次のURLを使用します。

    http://hostname.domain.com:9401/x-oracle-cache-invalidate-ping

    例:

    http://apphost1.mycompany.com:9401/x-oracle-cache-invalidate-ping

    ロード・バランシング・ルーターは、このURLにHTTPリクエストを送信し、レスポンス・ヘッダーは次にようなヘッダーになります。

    HTTP/1.0

    ロード・バランシング・ルーターは、レスポンス・ヘッダーの最初の行にあるHTTP文字列を検出するように構成する必要があります。したがって、ロード・バランシング・ルーターがレスポンス・ヘッダーの最初の行でHTTPを検出した場合、無効化ポートが使用可能になります。検出しない場合、すべての無効化リクエストはアクティブなコンピュータにルーティングされます。


    注意:

    sqlnet.oraファイルは、ロード・バランシング・ルーターおよびファイアウォールに関連する接続タイムアウトを防止するように更新する必要があります。

    要約すると、ロード・バランサには次の構成が必要です。

    仮想ホスト 仮想ポート サーバー・プール サーバー ポート コメント

    mysite.mycompany.com

    443/80

    UserRequest

    WEBHOST1

    7777

    SSLの終着点がロード・バランサの場合、プロトコル変換が必要です。

    mysite.mycompany.com

    443/80

    UserRequest

    WEBHOST2

    7777

    SSLの終着点がロード・バランサの場合、プロトコル変換が必要です。

    mysite.mycompany.com

    キャッシュの無効化

    WEBHOST1

    9401

    外部クライアントからは参照できません。

    mysite.mycompany.com

    キャッシュの無効化

    WEBHOST2

    9401

    外部クライアントからは参照できません。

14.6.1.3 データベース

製品が異なると、データベースの使用方法が異なります。次に、Oracle Portal、Forms、ReportsおよびDiscovererのデータベース要件の要約を示します。

Oracle Portal

Oracle Portalは、それ自体のメタデータとユーザー・コンテンツの両方をデータベースに格納します。Portalアプリケーション・ロジックの大部分もPLSQLの形式でこのデータベースに配置されます。メタデータ、ユーザー・コンテンツおよびPLSQLの組合せを使用することで、Portalにより、Webページが生成されます。

Oracle Portalには、高可用性データベースが必要です。これはPortalアプリケーションによって必要とされるデータベース・オブジェクトで事前にシードされます。メタデータ・リポジトリの作成の詳細は、第14.6.3項「メタデータ・リポジトリの作成」を参照してください。

Oracle Forms

Oracle Formsは、データベースと相互作用するため、データベースへのアクセスが必要です。Oracle Forms自体には特別なデータベース要件はありません。

Oracle Reports

Oracle Reportsには、レポート・キューを備えた高可用性データベースが必要です。また、様々なカスタマ・データベースへのアクセスも必要であり、それを使用してレポート・コンテンツをコンパイルします。

Oracle Discoverer

Oracle Discovererには、ポートレット用のデータベースが必要です。これは、高可用性データベースにする必要があり、Oracleリポジトリ作成ユーティリティ(RCU)を使用してシードされている必要があります。

また、Oracle Discovererは、いくつかのカスタマ・データベースと相互作用します。これらのデータベースは、レポートするデータに加えて、Discoverer End User Layerおよびワークブックも格納します。

14.6.1.4 共有ディレクトリ

共有ディレクトリの要件は、製品ごとに異なります。次の表に、これらの要件を示します。

製品 共有ディレクトリ要件

Oracle Portal

なし

Oracle Forms

必須ではありませんが、Oracle Forms実行可能ファイル用に共有ディレクトリがあると便利です。

Oracle Reports

レポート・キャッシュ

Oracle Discoverer

ポートレットのプリファレンス・ストア

14.6.1.5 管理対象ポートの番号

多数のOracle Fusion Middlewareコンポーネントおよびサービスではポートが使用されます。管理者として、これらのサービスに使用されるポート番号を把握してから、同じホスト上の2つのサービスが同じポート番号を使用しないようにすることが重要です。

ポート番号は、インストール時に自動的に割り当てることも手動で割り当てることもできます。

14.6.1.6 サイト名

Webサイトを構成するには、サイト名が必要です。このサイト名(たとえばmysite.mycompany.com)はDNSで定義し、ロード・バランサに割り当てられた仮想IPアドレスと関連付ける必要があります。

サイト名は、シングル・サインオン・サーバーにも必要です。これは、高可用性シングル・サインオン・インストールの一部として設定します。

14.6.2 前提

この章で説明する高可用性構成の例のために、次の前提事項について説明します。

14.6.2.1 ポート

次の表に、Oracle Portal、Forms、ReportsおよびDiscovererの実装に必要な一般的ポートを示します。

用途 ホスト ポート コメント

mysite.mycompany.com

ロード・バランサ

80

ロード・バランサ上のHTTPポート

Web CacheのHTTP

APPHOST1

APPHOST2

7777

Web CacheのHTTPポート

Web CacheのHTTPS

APPHOST1

APPHOST2

4443

Web CacheのHTTPSポート

Web Cacheの無効化

APPHOST1

APPHOST2

9401

Web Cacheの無効化ポート

Web Cacheの管理

APPHOST1

APPHOST2

9400

Web Cacheの管理ポート

HTTPサーバー(OHS)のHTTP

APPHOST1

APPHOST2

7778

OHSのHTTPリスニング・ポート

HTTPサーバー(OHS)のHTTPS

APPHOST1

APPHOST2

4444

OHSのHTTPSリスニング・ポート

WebLogicの管理ポート

APPHOST1

7001

WebLogic管理サーバー・ポート

WLS_PORTAL

APPHOST1

7050

WebLogic管理対象サーバー・ポート

WLS_PORTAL1

APPHOST2

7050

WebLogic管理対象サーバー・ポート

WLS_REPORTS

APPHOST1

7051

WebLogic管理対象サーバー・ポート

WLS_REPORTS1

APPHOST2

7051

WebLogic管理対象サーバー・ポート

WLS_DISCO

APPHOST1

7052

WebLogic管理対象サーバー・ポート

WLS_DISCO1

APPHOST2

7052

WebLogic管理対象サーバー・ポート

WLS_FORMS1

APPHOST1

7053

WebLogic管理対象サーバー・ポート

WLS_FORMS2

APPHOST2

7053

WebLogic管理対象サーバー・ポート

インターネット・ディレクトリ

SSOHOST

389

Oracle Internet DirectoryのHTTPポート

シングル・サインオン

SSOHOST

7777

シングル・サインオンのリスニング・ポート

14.6.3 メタデータ・リポジトリの作成

Oracle PortalおよびOracle Discovererをインストールする前に、リポジトリ作成ユーティリティ(RCU)を実行して、これらのアプリケーションが機能するために必要なメタデータを含むリポジトリを作成してからシードします。


注意:

Oracle FormsおよびReportsには、メタデータ・リポジトリは必要ありません。

14.6.3.1 リポジトリ作成ユーティリティ(RCU)のインストール

リポジトリ作成ユーティリティの最新バージョンを、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』の説明に従ってインストールします。

14.6.3.2 リポジトリ作成ユーティリティの実行

RCUをインストールしたら、それを使用してデータベースに移入します。次のコマンドを使用してリポジトリ作成ユーティリティを起動します。

UNIXの場合:

rcu

Windowsの場合:

rcu.exe

これらのコマンドは、RCUのORACLE_HOME/binディレクトリにあります。

  1. 「リポジトリの作成」画面で、「作成」を選択し、「次へ」をクリックします。

  2. 「データベース接続の詳細」画面で、次の値を指定します。

    • データベース・タイプ: Oracle Database

    • ホスト名: Oracle RACを使用している場合、Oracle RACノードの1つ(VIP名を使用)を入力します。

    • ポート: リスナー・ポートを入力します。

    • サービス名: Oracle Real Application Clustersデータベースのサービス名を入力します。

    • ユーザー名: sysと入力します。

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

    • ロール: SYSDBAを選択します。

  3. 「前提条件の確認」画面で、前提条件を検証したら「OK」をクリックします。

  4. 「コンポーネントの選択」画面で、次の値を指定します。

    • 接頭辞の新規作成: データベース・スキーマに追加する接頭辞を入力します(例: MYS)。

    • コンポーネント: Portal and BI > Portal and Discoverer

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

  5. 「前提条件の確認」画面で、前提条件を検証したら「OK」をクリックします。

  6. 「スキーマ・パスワード」画面で、各ポータル・スキーマのパスワードを入力するか、すべてのスキーマに同じパスワードを使用します。

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

  7. 「表領域のマップ」画面で「次へ」をクリックし、デフォルトを受け入れます。

  8. 「表領域の作成」画面で、「はい」をクリックし、欠落している表領域をRCUで作成できるようにします。

  9. 「表領域の作成」画面で、「OK」をクリックし、表領域の作成を承認します。

  10. 「サマリー」画面で、「作成」をクリックし、作成プロセスを開始します。

14.6.4 APPHOST1におけるアプリケーション層のインストールと構成

次の手順は、Oracle Portal、Forms、ReportsおよびDiscovererのインストールに適用されます。

14.6.4.1 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverのバイナリをインストールするには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

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

14.6.4.2 Oracle Portal、Forms、ReportsおよびDiscovererのインストール

Oracle Portal、Forms、Reports、およびDiscovererのバイナリをインストールするには、Oracle Fusion Middleware Oracle Portal, Forms, ReportsおよびDiscovererのインストレーション・ガイドを参照してください。


注意:

第14.6.4.3項「Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成」の説明に従って構成ウィザードを実行する前に、Oracle Fusion Middlewareが最新バージョンになるように、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチがMiddlewareホームに適用されていることを確認してください。

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

14.6.4.3 Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成

Oracle Fusion Middleware構成ウィザードを起動するには、次のコマンドを実行します。

ORACLE_HOME/bin/config.sh


注意:

構成を開始する前に、次の環境変数(UNIX)が設定されていないことを確認してください。

  • LD_ASSUME_KERNEL

  • ORACLE_BASE

  • LD_LIBRARY_PATH

次の手順を続行します。

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

  2. 「前提条件のチェック」画面で、すべての前提条件を検証したら、「次へ」をクリックします。

  3. ドメインの作成画面で新しいドメインの作成を選択し、次の値を入力します。

    • ユーザー名: WebLogicドメインにログインするユーザーの名前です。

    • ユーザー・パスワード: ドメインのパスワードです。

    • パスワードの確認: 同じパスワードを再度入力します。

    • ドメイン名: ドメインの名前です(例: MyDomain)。

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

  4. セキュリティ・アップデートの指定画面で、必要に応じて、OracleサポートのOracleセキュリティ・アップデートを受け取るためのユーザー名およびパスワードを入力します。

  5. 「インストール場所の指定」画面で、次の値を入力します。

    • WebLogicサーバーの場所: Oracle WebLogic Serverのインストール・ディレクトリを入力します。このディレクトリはMW_HOME/wlserver_10.3です。例:

      /u01/app/oracle/product/FMW/wlserver_10.3

    • Oracleインスタンスの場所: Oracle構成ファイルを配置するディレクトリを入力します。これは、Oracleホーム・ディレクトリの外部にする必要があります。このディレクトリは、ORACLE_INSTANCEとも呼ばれます。例:

      /u01/app/oracle/admin/fmw1

    • Oracleインスタンス名: fmw1

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

  6. 「コンポーネントの構成」画面で、インストールと構成を行う製品を選択します。

    管理コンポーネント - Enterprise Managerも選択されていることを確認します。

    クラスタを選択します。

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

  7. 高可用性の実装では、様々なコンポーネントで使用されるポートのすべてを複数のホスト間で同期することは必須ではありませんが、強くお薦めします。使用するポートをファイルに指定することで、自動ポート構成をバイパスできます。

    ファイル名を選択してから表示/編集をクリックして、割り当てるポートを含むファイルを作成します。

    サンプルのstaticports.iniファイルは、インストールのDisk1のstage/Responseディレクトリにあります。

    このファイルには、次のエントリがあります。

    [Domain Port No = 7001
Oracle HTTP Server Port No = 7778
WebCache Port No = 7777
WebCache Administration Port No = 9400
WebCache Statistics Port No = 9402
Web Cache Invalidation Port = 9401
Portal Managed Server Port = 7050
Reports Managed Server Port = 7051
Discoverer Managed Server Port = 7052
Forms Managed Server Port = 7053]

    ファイルを保存し、「次へ」をクリックします。

  8. プロキシ詳細の指定画面(Reportsのみ)で、プロキシ・サーバーを使用している場合は、この画面に詳細を入力します。

    それ以外の場合は、「次へ」をクリックします。

  9. スキーマの指定画面(PortalとDiscovererのみ)で、次の値を指定します。

    • データベース接続文字列: 次の形式で入力します。

      Oracle RACデータベースの場合:

      racnode1-vip:ListenerPort:racnode2-vip:ListenerPort@mydb.mycompany.com

      その他のデータベースの場合:

      host:port:mydb.mycompany.com

    • Portalスキーマ名: MYS_PORTAL

    • Portalスキーマ・パスワード: RCUで入力したパスワードを入力します。

    • Discovererスキーマ名: MYS_DISCOVERER

    • Discovererスキーマ・パスワード: RCUで入力したパスワードを入力します。

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

  10. ポートレット・スキーマの指定画面(PortalとDiscovererのみ)で、次の値を指定します。

    • ポートレット・スキーマ名: MYS_PORTLET

    • ポートレット・スキーマ・パスワード: RCUで入力したパスワードを入力します。

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

  11. アプリケーション・アイデンティティ・ストアの指定画面で、次の値を指定します。

    • ホスト名: Oracle Internet Directoryサーバーの名前です(例: myoid.mycompany.com)。

    • ポート: Oracle Internet Directoryポートです(例: 389)。

    • ユーザー名: cn=orcladmin

    • パスワード: Oracle Internet Directoryのorcladminアカウントのパスワードです。

  12. 「サマリー」画面で、「インストール」をクリックし、作成プロセスを開始します。

14.6.4.4 検証

次のテストを実行して、初期インストールを検証します。

テスト URL 結果

Portal

http://apphost1.mycompany.com:7777/portal/pls/portal

Portalのホーム・ページが開きます。

Forms

http://apphost1.mycompany.com:7777/forms/frmservlet

Formsサーブレットのホーム・ページが開きます。

レポート

http://apphost1.mycompany.com:7777/reports/rwservlet/showjobs

「ジョブ・キュー」が開きます。

Discoverer

http://apphost1.mycompany.com:7777/discoverer/viewer

Discoverer Viewerのホーム・ページが開きます。

14.6.4.5 汎用構成

次の手順は、構成する製品に関係なく必要です。

14.6.4.5.1 管理サーバーのリスニング・アドレスの設定

複数のネットワーク・カードが存在するサーバーでは、使用するネットワーク・カードに管理サーバーをバインドすることが重要になります。

そのための手順は次のとおりです。

  1. 次のURLを使用して、WebLogicコンソールにログインします。

    http://apphost1.mycompany.com:7001/console

  2. 「ドメイン構造」メニューで、「環境」、「サーバー」の順に選択します。

  3. 「AdminServer (admin)」をクリックします。

  4. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  5. 使用するネットワーク・カードを参照するDNS名にリスニング・アドレスを設定します。これは一般的にパブリック・サーバー名を指定します。

  6. 「保存」をクリックします。

  7. 「チェンジ・センター」で「変更のアクティブ化」をクリックします。

  8. DOMAIN_HOME/binディレクトリにあるstopWebLogic.shスクリプトを使用して、管理サーバーを停止します。同じDOMAIN_HOME/binディレクトリにあるstartWebLogic.shスクリプトを使用して、管理サーバーを起動します。

14.6.4.5.2 仮想ホストの構成

サイトをロード・バランサで適切に機能させるには、2つの仮想ホストを追加する必要があります。Oracle Enterprise Manager Fusion Middleware Controlを使用して仮想ホストを構成するか、ORACLE_INSTANCE/config/OHS/ohs1/httpd.confファイルを編集するか、ORACLE_INSTANCE/config/OHS/ohs1/moduleconfディレクトリにvirtual_hosts.confというファイルを作成できます。

2つの仮想ホストをvirtual_hosts.confファイルに追加するには、テキスト・エディタで次のエントリをファイルに追加します。

NameVirtualHost *:7778
<VirtualHost *:7778>
    ServerName http://mysite.mycompany.com:80
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>
 
<VirtualHost *:7778>
    ServerName apphost1.mycompany.com:7777
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>

注意:

説明:

7778は、Oracle HTTP Serverのリスニング・ポートです。

80は、ロード・バランサのリスニング・ポートです。

7777は、Web Cacheのリスニング・ポートです。

Oracle HTTP Serverが存在するサーバーの名前: apphost1

サイトがhttpプロトコルでのみ動作する場合は、ServerName HTTPを使用します。

次のコマンドを使用してWeb層を再起動します。

opmnctl stopall
opmnctl startall
14.6.4.5.3 boot.propertiesファイルの作成

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

テキスト・エディタで、DOM_HOME/servers/AdminServer/securityディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminuser
password=password

管理サーバーを再起動すると、このファイルの値が暗号化されます。このため、管理サーバーはそれをホストできる各ノードで再起動することをお薦めします。

DOMAIN_HOME/binにあるstopWebLogic.shスクリプトを使用して、管理サーバーを停止します。または、同じDOMAIN_HOME/binにあるstartWebLogic.shスクリプトを使用します。

14.6.4.5.4 sqlnet.oraの構成

ORACLE_INSTANCE/config/ディレクトリにsqlnet.oraというファイルを作成し、そのファイルに次のエントリを追加します。

TCP.CONNECT_TIMEOUT=10

これにより、妥当な長さの時間が経過すると、データベース接続がタイムアウトします。

14.6.4.5.5 Web Cacheの構成

Web Cacheは、Oracle Forms、ReportsおよびDiscovererの場合はオプションですが、Oracle Portalの場合は必須です。構成する環境でWeb Cacheを使用しない場合、次のWeb Cache構成手順は無視してください。

Enterprise Managerコンソールへのログイン

次のURLを使用して、Oracle Fusion MiddlewareのEnterprise Managerコンソールにログインします。

http://apphost1.mycompany.com:7001/em

デフォルトの「ユーザー名」および「パスワード」は、インストール中に入力されたWebLogicドメイン・ユーザー名およびパスワードと同じです。

サイトの作成

  1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

  2. wc1コンポーネントをクリックします。

  3. ページの最上部にあるリストから「管理 - サイト」を選択します。

  4. 「サイトの作成」を選択します。

  5. 次の情報を入力し、サイトを追加します。

    フィールド 値

    ホスト名

    mysite.mycompany.com

    ポート

    リクエストを受信するロード・バランサ上のポート番号を指定します。たとえば、HTTPリクエストの場合は80、HTTPSリクエストの場合は443です。

    ロード・バランサを使用している場合、これはロード・バランサ上のリスニング・ポートです。

    デフォルト・サイト

    はい

    サイト全体の圧縮

    はい

    サイト別名 - ホスト名

    mysite.mycompany.com

    サイト別名 - ポート

    7777

    サイト別名 - ホスト名

    mysite.mycompany.com

    サイト別名 - ポート

    80 脚注 1 

    脚注 1 ロード・バランサがリクエストをポート80およびポート443に送信可能な場合に必要です。

  6. その他のデフォルトは変更しないでください。

  7. 「発行」を選択します。

  8. 「OK」を選択し、各エントリを保存します。

サイトとサーバーとの間におけるマッピングの作成

  1. 同じページで、「サイト・サーバー間マッピング」セクションの「作成」を選択します。

  2. 次の情報を入力し、サイトを追加します。

    フィールド 値

    ホスト・パターン

    mysite.mycompany.com

    ポート・パターン

    80

    選択したオリジナル・サーバー

    apphost1.mycompany.com:7778

  3. 「OK」をクリックしてサイトを保存します。

  4. mysite.mycompany.com:443/80のサイトが、サイトとサーバーとの間におけるマッピングのリストにあることを確認します。

  5. 「適用」をクリックして変更を保存します。

セッション・バインディングの有効化

Oracle Web Cacheのセッション・バインディング機能は、ユーザー・セッションを特定のオリジナル・サーバーにバインドし、一定の期間、状態を維持するために使用します。デフォルトのOracle Fusion Middleware中間層で実行されているコンポーネントはほとんどすべてステートレスですが、Oracle Portalにはセッション・バインディングが必要です。

セッション・バインディングを有効化すると、すべてのユーザー・リクエストが特定のOracle Portal中間層に送信されます。その結果、ポータル・キャッシュのキャッシュ・ヒット率が高くなります。

次の手順に従って、セッション・バインディングを有効化します。

  1. ページの上部にある「管理 - セッション構成」を選択します。

  2. ドロップダウン・リストからmysite.mycompany.com:443/80のサイトを選択します。

  3. 「セッション・バインディング」セクションで、「Set-Cookieを使用したCookieに基づくセッション・バインディング」を選択します。

  4. 「適用」をクリックして変更を保存します。

14.6.4.5.6 Web Cacheパスワードの変更

Web Cacheパスワードはランダムに生成されますが、後の段階で必要になります。したがって、Web Cacheパスワードをデフォルト値から新しい既知の値に変更することをお薦めします。

デフォルトのパスワードを変更する手順は、次のとおりです。

  1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

  2. wc1コンポーネントをクリックします。

  3. ページの最上部にあるドロップダウン・リストから「管理 - パスワード」を選択します。

  4. 新しい無効化パスワードと管理パスワードを入力してからそれらを確認し、「適用」をクリックします。

14.6.4.5.7 Web層(Oracle HTTP ServerおよびWeb Cache)の再起動

前述の変更を行った後、次のコマンドを使用してWeb層コンポーネントを再起動します。

opmnctl stopall 
opmnctl startall
14.6.4.5.8 シングル・サインオン・サーバーでの登録

シングル・サインオン・サーバーから次の手順を実行します。

  1. ORACLE_HOME変数をシングル・サインオン・サーバーのORACLE_HOMEの場所に設定します。

  2. 次のパラメータを指定して、ORACLE_HOME/sso/bin/ssoreg.sh(Windowsの場合はssoreg.bat)を実行します。

    -site_name mysite.mycompany.com
-mod_osso_url http://mysite.mycompany.com
-config_mod_osso TRUE
-oracle_home_path ORACLE_HOME
-config_file /tmp/osso.conf
-admin_info cn=orcladmin
-virtualhost
-remote_midtier

  3. /tmp/osso.confを中間層のホームの場所にコピーします。それは次の場所です。

    ORACLE_INSTANCE/config/OHS/ohs1

  4. 次のコマンドを使用してAPPHOST1上のOracle HTTP Serverを再起動します。

    opmnctl restartproc process-type=OHS

  5. 次のURLを使用してシングル・サインオン・サーバーにログインします。

    http://login.mycompany.com/pls/orasso

  6. 「管理」ページに移動してから、「パートナ・アプリケーション管理」ページに移動します。apphost1.mycompany.comのエントリを削除します。

14.6.4.5.9 WebLogicプラグインの有効化

セキュリティのために、ドメインに対してWebLogicプラグイン有効化フラグをオンにします。そのためには、次の手順に従ってください。

Oracle Web TierはOracle WebLogic Serverの前面に配置され、Oracle HTTP ServerからOracle WebLogic管理対象サーバーにリクエストをルーティングします。このシナリオでは、Oracle WebLogicプラグインが使用されていることをWebLogicが認識する必要があります。そのための手順は次のとおりです。

  1. 管理コンソールにログインします。

  2. 「ドメイン構造」ウィンドウで、ドメイン名をクリックします。

  3. 「Webアプリケーション」タブをクリックします。

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

  5. 「WebLogicプラグインの有効化」ボックスを選択します。

  6. 変更を保存およびアクティブ化します。

  7. 管理サーバーを再起動します。

14.6.4.5.10 WebLogicにおけるホスト・アサーションの変更

Oracle HTTP Serverは、WebLogicのプロキシとして機能するため、デフォルトでは、特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。

  1. 次のURLを使用して、管理コンソールにログインします。

    http://apphost1.mycompany.com:7001/console

  2. ホーム・ページから「クラスタ」を選択するか、「ドメイン構造」メニューから「環境」→「クラスタ」を選択します。

  3. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  4. クラスタ名(cluster_portal、cluster_forms、cluster_reports、cluster_disco)をクリックします。

  5. 「HTTP」を選択し、次の値を入力します。

    パラメータ 値

    フロントエンド・ホスト

    mysite.mycompany.com

    フロントエンドHTTPポート

    80

    フロントエンドHTTPSポート

    443

    これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート443または80に送られます。

  6. 「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックし、変更を保存します。

  7. 次の手順を使用して、WLS_PORTAL、WLS_FORMS、WLS_REPORTS、WLS_DISCOの管理対象サーバーを再起動します。

    1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

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

    3. 各管理対象サーバーの横にあるボックスを選択します。

    4. 「停止」→「ただちに強制停止」を選択します。

    5. 「はい」をクリックし、管理対象サーバーを停止します。

    6. 管理対象サーバーが停止したら、その管理対象サーバーの横にあるボックスを選択します。

    7. 「起動」をクリックします。

    8. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.6 高可用性のためのOracle Portalの構成

次の手順は、Oracle Portalの構成にのみ必要です。

14.6.4.6.1 Portalリポジトリのリワイヤ

次の手順に従って、Oracle Portalリポジトリをリワイヤします。

  1. Oracle Fusion Middleware Enterprise Managerで次のURLを使用してドメインにログインします。

    http://apphost1.example.com:7001/em

  2. 左側にある「Fusion Middleware」メニューを開きます。

  3. 「Portal」メニューを開きます(「Fusion Middleware」メニューの下にあります)。

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

  5. 「Portal」を右クリックして、「設定」、「ワイヤ構成」を選択します。

  6. Portal中間層に次の情報を入力します。

    パラメータ 値

    ホスト

    ロード・バランサのDNS名を入力します。たとえば、mysite.mycompany.comとします。

    ポート

    ロード・バランサがリスニングするポートを入力します。たとえば、SSLターミネーションまたはSSL有効化サイトの場合は443、HTTPの場合は80です。

    SSLプロトコル

    SSLターミネーションまたはSSL有効化サイトを使用している場合、これを選択します。

  7. Web Cacheについて次の情報を入力します。

    パラメータ 値

    ホスト

    ロード・バランサのDNS名を入力します。たとえば、mysite.mycompany.comとします。

    無効化ポート

    ロード・バランサで構成されているとおりにPortal無効化ポートを入力します(例: 9401)。

    無効化ユーザー名

    Portal無効化に使用されるユーザー名を入力します(例: invalidator)。

    無効化パスワード

    前述のアカウントのパスワードです。

    このパスワードの値が不明な場合、前述のようにEnterprise Managerで変更できます。

  8. 「適用」をクリックし、リワイヤを開始します。

  9. リワイヤが完了したら、「Portal」メニューのオプションを再度クリックします。

  10. 次のようにPortalのURLが表示されていることを確認します。

    http://mysite.mycompany.com:80/portal/pls/portal
14.6.4.6.2 ロード・バランサでのParallel Page Engineループバックの構成

Parallel Page Engine(PPE Servlet)の目的は、ユーザーによってリクエストされたページを構成することです。これは、ユーザーからページ・リクエストを受信し、ページの各部分すべてを並行してフェッチするように独自の新しいリクエストを実行し、これらの部分を1つのページ・ファイルにアセンブルし、ページ・コンテンツをエンド・ユーザーに送り返す(またはクライアント・ブラウザに送り返す)ことにより行います。

これらの内部リクエストは、組織内部に保持され、HTTPプロトコルを使用してサービスが処理されます。

次の手順は、ロード・バランサを使用している場合にのみ必要です。

  1. 次のURLを使用してOracle Fusion Middleware Enterprise Managerにログインします。

    http://apphost1.example.com:7001/em

  2. 左側にあるオブジェクト・ブラウザから「Fusion Middleware」→「Classic」→「Portal」を選択します。

  3. 「Portal」を右クリックして、「設定」→「ページ・エンジン」を選択します。

  4. 「拡張プロパティ」セクションで、次の情報を追加します。

    パラメータ 値

    ポートの使用

    内部ループバックのポート番号を選択します(例: 7777)このポートは、内部リクエスト用にロード・バランサで構成されます。

    スキームの使用

    HTTPの値に変更します。

  5. 「適用」をクリックして設定を保存します。

  6. 次のようにOracle WebLogic管理コンソールからWebLogic管理対象サーバーを再起動します。

    1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

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

    3. WLS_PORTAL管理対象サーバーの横にあるボックスを選択します。

    4. 「停止」→「ただちに強制停止」を選択します。

    5. 「はい」をクリックし、管理対象サーバーを停止します。

    6. 管理対象サーバーが停止したら、その管理対象サーバーの横にあるボックスを選択します。

    7. 「起動」をクリックします。

    8. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.6.3 データベース・ウォレットとポータル

SSLを使用している場合、Oracle Portalでは、ポータル・スキーマが配置されているデータベースにウォレットが存在している必要があります。このウォレットには、ロード・バランサまたはサイトの証明書が格納されます。ウォレットを作成したら、Oracle Portalにその場所を認識させる必要があります。


注意:

この手順は、SSLターミネーションまたはサイトSSLを使用している場合にのみ必要です。

データベース・ウォレットの作成

このプロセスを開始する前に、証明書をデータベース・サーバーにコピーします。

この方法は、ブラウザによってわずかに異なります。Firefoxブラウザの場合は次のようになります。

  1. ブラウザを使用してhttps://mysite.mycompany.comのURLにアクセスします。

  2. Firefox→「プリファレンス」→「拡張」→「暗号化」→「証明書の表示」に移動します。

  3. mysite.mycompany.comの証明書を選択してから、エクスポートを選択してファイルの名前を指定します。

  4. このファイルをデータベース・サーバーにコピーします。

  5. 必要に応じて証明書を保存します。

  6. 証明書のコピーを取得したら、各データベース・サーバーでウォレットを作成し、この証明書をデータベース・サーバーからOracle Wallet Managerを使用してインポートします。これは、すべてのOracle RACノードに対して次の手順に従って実行する必要があります。

    1. owmと入力し、Oracle Wallet Managerを起動します。

    2. 「ウォレット」→「新規」を選択します。

    3. デフォルトの場所にウォレットを作成しないので、「いいえ」を選択します。

    4. ウォレットのパスワードを入力します(このパスワードは後で必要になるので覚えておいてください)。

    5. ウォレットのタイプを「標準」に設定します。

    6. この時点で証明書を作成するかどうかという質問に対して「いいえ」を選択します。

    7. Oracle Wallet Managerで、「操作」→「信頼できる証明書のインポート」を選択します。

    8. 「証明書を含むファイルを選択」を選択し、「OK」をクリックします。

    9. 前の手順で選択した証明書ファイルを選択し、「インポート」をクリックします。

    10. 「ウォレット」および「別名保存」を選択します。

    11. ウォレットの場所を選択します。例:

      ORACLE_BASE/admin/DB_NAME/wallet

    12. 他のOracle RACデータベース・ノードに対してもこの手順を繰り返します。

      すべてのデータベース・ノードで同じディレクトリ・パスを使用する必要があります。

ポータルに対するウォレットの識別

データベース・ウォレット内に証明書を格納したら、次の手順に従ってポータル・リポジトリ内にウォレットの場所を格納します。

  1. SQL*Plusスクリプトのsecwc.sqlを実行します。これは次のディレクトリにあります。

    ORACLE_HOME/portal/admin/plsql/wwc

    ORACLE_HOME/network/adminにあるtnsnames.oraファイルにデータベース・エントリを作成することが必要な場合もあります。

    SQL> @secwc 'file:$ORACLE_BASE/admin/DB_NAME/wallet' 'walletpassword'

    前述のコマンドでは、次のようにします。

    • ウォレットへの絶対パスを使用します。環境変数は使用しません。

    • walletpasswordは、ウォレットのパスワードです。

    • ウォレット・ファイル自体ではなくウォレット・ディレクトリへのパスを使用します。キーワード・ファイルが必要です。

14.6.4.6.4 すべてのコンポーネントの再起動

前の項の変更を行った後、Web層コンポーネントを再起動する必要があります。この項では、コンポーネントを再起動する手順について説明します。

Webコンポーネントの再起動

次のコマンドを使用してOracle HTTP Serverを再起動します。

opmnctl stopall 
opmnctl startall

WLS_Portalの再起動

WebLogic管理コンソールにログインし、次の手順に従って管理対象サーバーのWLS_PORTALを再起動します。

  1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

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

  3. WLS_PORTAL管理対象サーバーの横にあるボックスを選択します。

  4. 「停止」→「ただちに強制停止」を選択します。

  5. 「はい」をクリックし、管理対象サーバーを停止します。

  6. 管理対象サーバーが停止したら、そのWLS_PORTAL管理対象サーバーの横にあるボックスを選択します。

  7. 「起動」をクリックします。

  8. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.6.5 Oracle RACでのポータルのインストールに対するインストール後の手順

ポータルおよびポートレット・コンポーネントに対して作成される個々のデータ・ソースの初期容量を0に設定することをお薦めします。管理コンソールを使用してこれらのデータ・ソースの初期容量を0に設定してください。

14.6.4.6.6 構成の検証

構成を検証するには、次のテストを実行します。

テスト URL 結果

ロード・バランサを使用したPortalのテスト

http://mysite.mycompany.com/portal/pls/portal

Portalのホーム・ページが開きます。

シングル・サインオンのエラーのトラブルシューティング

構成のこの段階でシングル・サインオンのエラー・メッセージがPortalフロント画面に表示された場合、データベースのウォレットが適切に作成されていないか、その正しい場所がOracle Portalに認識されていない可能性があります。

このエラーが表示された場合、データベースのウォレットを作成する手順とその後にポータルで識別する手順を繰り返します。

14.6.4.7 高可用性のためのOracle Formsの構成

次の手順は、Oracle Formsの構成にのみ使用します。

14.6.4.7.1 カスタマ・データベースのTNSNAMESエントリの作成

アプリケーションで1つ以上のデータベースにアクセスする場合、アクセスされる各データベースのエントリをtnsnames.oraファイルに配置する必要があります。

各データベースのエントリをファイルに配置する手順は次のとおりです。

  1. ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

    mydb.mycompany.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mydb.mycompany.com)
    )
  )

    注意:

    これは、Oracle RACデータベース接続文字列です。

  2. ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。

    tnsping mydb.mycompany.com

    注意:

    前述のtnspingコマンドを発行する前に、TNS_ADMIN環境変数を設定してください。

14.6.4.7.2 WLS_FORMSの再起動

WebLogic管理コンソールにログインし、次の手順に従って管理対象サーバーのWLS_FORMSを再起動します。

  1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

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

  3. WLS_FORMS管理対象サーバーの横にあるボックスを選択します。

  4. 「停止」→「ただちに強制停止」を選択します。

  5. 「はい」をクリックし、管理対象サーバーを停止します。

  6. 管理対象サーバーの停止後に、WLS_FORMS管理対象サーバーの横のボックスを選択します。「起動」をクリックします。

  7. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.7.3 構成の検証

構成を検証するには、次のテストを実行します。

テスト URL 結果

ロード・バランサのテスト

http://mysite.mycompany.com/

ホーム・ページが開きます。

Forms

http://mysite.mycompany.com/forms/frmservlet

Formsサーブレットのホーム・ページが開きます。

14.6.4.8 高可用性のためのOracle Reportsの構成

次の手順は、Oracle Reportsの構成にのみ必要です。

14.6.4.8.1 データベースにおけるレポート・キューの作成

複数のReports Serverインスタンス間で整合性のあるレポート・キューを保持し、レポート・サーバーの障害に対するリジリエンスを持たせるには、高可用性のReal Application Clustersデータベースにレポート・キューを作成します。

レポート・キューを作成するには、SQL*Plusスクリプトのrw_server.sqlをデータベースに対して実行します。

このスクリプトは、次のディレクトリにあります。

ORACLE_HOME/reports/admin/sql

次の手順を実行します。

  1. 次のコマンドを使用して、データベース内にレポート・キューを保持するユーザーを作成します。

    sql> create user report_queue identified by MYSpassword;
sql> grant connect, resource,create view to report_queue;

  2. そのレポート・ユーザーに接続し、次のスクリプトを実行します。

    cd ORACLE_HOME/reports/admin/sql
sqlplus reports_queue/MYpasswd@rw_server.sql
14.6.4.8.2 レポート・キューのTNSNAMESエントリの作成

Oracle Reportsでは、tnsnames.oraファイルのエントリを使用して、データベース接続情報を判別します。次の手順に従って、レポート・キュー・データベースのエントリをこのファイルに配置します。

  1. ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

    myrepq.mycompany.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = myrepq.mycompany.com)
    )
  )

    注意:

    これは、Oracle RACデータベース接続文字列です。

  2. ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。

    tnsping myrepq.mycompany.com

    注意:

    tnspingコマンドを使用する前に、TNS_ADMIN環境変数を設定してください。

14.6.4.8.3 レポート・キューのセキュリティ・キーの作成

Oracle Reportsのセキュリティは、間接的モデルを使用して実行されます。データベース・レポート・キューを使用するようにレポート・サーバーを構成する前に、次の手順に従ってレポート・キューのパスワードを保持するエントリをWebLogicに作成します。

  1. 次のURLを使用してOracle Fusion Middleware Enterprise Managerにログインし、求められたらWebLogic管理者ユーザーおよびパスワードを入力します。

    http://apphost1.mycompany.com:7001/em

  2. 左側にあるナビゲーション・ツリーで、WebLogicDomainを開き、ドメインの名前(たとえばReportsDomain)をクリックします。

    ReportsDomain概要ページが表示されます。

  3. ページの最上部にあるドロップダウン・メニューから「セキュリティ」→「資格証明」を選択します。

  4. 「キーの作成」をクリックします。

  5. 次の情報を入力します。

    パラメータ 値

    マップの選択

    reports

    キー

    queuePassword

    タイプ

    パスワード

    ユーザー名

    report_queue

    パスワード

    レポート・キュー・アカウントのパスワード

    説明

    レポート・キュー・アカウントの説明

  6. 終了したら、「OK」をクリックします。

14.6.4.8.4 インプロセスReports Serverのデータベース・ジョブ・リポジトリの構成

レポート・キューをデータベースに配置したら、それにアクセスする方法をレポート・サーバーに認識させる必要があります。

そのためには、rwserver.confファイルを編集します。

このファイルは、次のディレクトリにあります。

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configuration/

サーバー構成ファイルではエントリの順序は固定しています。rwserver.confファイルの<jobStatusRepository>要素の直後に次の要素を追加します。

<jobRepository>
 <property name="dbuser" value="dbuser"/>
 <property name="dbpassword" value="csf:reports:dbpasswdKey"/>
 <property name="dbconn" value="dbconn"/>
</jobRepository>

説明:

  • dbuserは、レポート・キューが配置するスキーマの名前です。

  • dbconnは、ORACLE_INSTANCE/configディレクトリにあるtnsnames.oraファイルのデータベース・エントリを参照します。

例:

<jobRepository>
 <property name="dbuser" value="report_queue"/>
 <property name="dbpassword" value="csf:reports:queuePassword"/>
 <property name="dbconn" value="myrepq.mycompany.com"/>
</jobRepository>
14.6.4.8.5 共有出力ディレクトリにアクセスするためのReports Serverの構成

次のディレクトリにあるrwserver.confファイルの<cache>要素にCacheDirプロパティまたはJOCCacheDirプロパティを追加します。

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configuration/

例:

<property name="JOCCacheDir" value="folder_name"/>
<property name="CacheDir" value="folder_name"/>

UNIXの場合:

<cache class="oracle.reports.cache.RWCache">
 <property name="cacheSize" value="50"/>
 <!--property name="cacheDir" value="your cache directory"/-->
 <!--property name="maxCacheFileNumber" value="max number of cache files"/-->
 <property name="JOCCacheDir" value="/share/reports"/>
 <property name="CacheDir" value="/share/reports"/>
</cache>
14.6.4.8.6 WLS_REPORTSの再起動

管理対象サーバーのWLS_REPORTSを再起動するには、WebLogic管理コンソールにログインし、次の手順に従います。

  1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

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

  3. WLS_REPORTS管理対象サーバーの横にあるボックスを選択します。

  4. 「停止」→「ただちに強制停止」を選択します。

  5. 「はい」をクリックし、管理対象サーバーを停止します。

  6. 管理対象サーバーが停止したら、そのWLS_REPORTS管理対象サーバーの横にあるボックスを選択します。

  7. 「起動」をクリックします。

  8. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.8.7 構成の検証

次のテストを実行して、初期Reports構成を検証します。

テスト URL 結果

レポート・キュー

http://mysite.mycompany.com/reports/rwservlet/showjobs

「シングル・サインオン」画面と、その後にレポート・キューが開きます。

代替テストのために、Oracle Technology Networkからサンプル・レポートをダウンロードし、それを実行します。Oracle Technology NetworkのURLは、次のとおりです。

http://www.oracle.com/technology/index.html

14.6.4.9 高可用性のためのOracle Discovererの構成

Oracle Discovererの高可用性を構成する場合にのみ、次の手順に従います。

14.6.4.9.1 カスタマ・データベースのTNSNAMESエントリの作成

アプリケーションで1つ以上のデータベースにアクセスする場合、次の手順に従って、アクセスされる各データベースのエントリをtnsnames.oraファイルに配置します。

  1. ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

    mydb.mycompany.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mydb.mycompany.com)
    )
  )

    注意:

    これは、Oracle RACデータベース接続文字列です。

  2. ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。

    tnsping mydb.mycompany.com

    注意:

    tnspingコマンドを発行する前に、TNS_ADMIN環境変数を設定してください。

14.6.4.9.2 configuration.xmlの更新

configuration.xmlには、Discovererの構成の情報が格納されています。このファイルは、次のディレクトリにあります。

DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/

applicationURL=で始まる行を更新し、そのURLを次のように変更します。

http://mysite.mycompany.com/discoverer

例:

applicationURL="http://mysite.mycompany.com/discoverer">
14.6.4.9.3 Discoverer ViewerおよびWeb Cache

デフォルトでは、Discoverer Viewerは、Oracle Web Cacheを十分に活用するように構成されていません。これを有効にすると、パフォーマンスを大幅に向上させることができます。ただし、この機能を有効にすることが適切でない場合もあります。

Discoverer ViewerをOracle Web Cacheとともに使用可能にする場合とその方法の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscoverer ViewerをOracle Web Cacheとともに使用する方法に関する項を参照してください。

14.6.4.9.4 シングル・サインオンの有効化

デフォルトでは、Discovererはシングル・サインオンで保護されていません。Discoverer PlusおよびViewerを保護するには、次の手順を実行します。

  1. mod_osso.confファイルを編集します。これは、次のディレクトリにあります。

    ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

  2. ファイルにおいて</IfModule>で始まる行の前に次の行を追加します。

    <Location /discoverer/plus>
 require valid-user
 AuthType Osso
</Location>
 
<Location /discoverer/viewer>        
 require valid-user
 AuthType Osso
</Location>
 
<Location /discoverer/app>
 require valid-user
 AuthType Osso
</Location>
14.6.4.9.5 すべてのコンポーネントの再起動

前の項の変更を行った後、この項で説明する手順を使用してWeb層コンポーネントを再起動します。

Webコンポーネントの再起動

次のコマンドを使用して、Oracle HTTP Serverを再起動します。

opmnctl stopall 
opmnctl startall

WLS_DISCOの再起動

WebLogic管理コンソールにログインし、次の手順に従って管理対象サーバーのWLS_DISCOを再起動します。

  1. ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

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

  3. WLS_DISCO管理対象サーバーの横にあるボックスを選択します。

  4. 「停止」→「ただちに強制停止」を選択します。

  5. 「はい」をクリックし、管理対象サーバーを停止します。

  6. 管理対象サーバーが停止したら、そのWLS_DISCO管理対象サーバーの横にあるボックスを選択します。

  7. 「起動」をクリックします。

  8. 「はい」をクリックして管理対象サーバーを起動します。

14.6.4.9.6 構成の検証

次のテストを実行して、初期Discoverer構成を検証します。

テスト URL 結果

ロード・バランサのテスト

http://mysite.mycompany.com/

ホーム・ページが開きます。

Discoverer

http://mysite.mycompany.com/discoverer/viewer

「シングル・サインオン」画面と、その後にDiscoverer Viewerが開きます。

14.6.5 APPHOST2におけるアプリケーション層のインストールと構成

次の項では、APPHOST2にアプリケーション層をインストールおよび構成する方法について説明します。

14.6.5.1 Oracle WebLogic Serverのインストール

Oracle WebLogic Serverのバイナリをインストールするには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。

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

14.6.5.2 Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアのインストール

Oracle Portal、Forms、Reports、およびDiscovererのバイナリをインストールするには、Oracle Fusion Middleware Oracle Portal, Forms, ReportsおよびDiscovererのインストレーション・ガイドを参照してください。


注意:

第14.6.5.3項「Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成」の説明に従って構成ウィザードを実行する前に、最新のOracle Fusion Middlewareパッチ・セットおよびその他の既知のパッチがMiddlewareホームに適用されていることを確認してください。

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

14.6.5.3 Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成

次のコマンドを実行してOracle Fusion Middleware構成ウィザードを起動します。

ORACLE_HOME/bin/config.sh


注意:

構成を開始する前に、次の環境変数(UNIX)が設定されていないことを確認してください。

  • LD_ASSUME_KERNEL

  • ORACLE_BASE

  • LD_LIBRARY_PATH

次の手順を続行します。

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

  2. 「前提条件のチェック」画面で、すべての前提条件を検証したら、「次へ」をクリックします。

  3. ドメインの作成画面で「クラスタを開く」を選択し、次の値を入力します。

    • ホスト名: WebLogic管理サーバーを実行しているホストの名前です(例: APPHOST1.mycompany.com)。

    • ポート: 管理サーバーのポートです。たとえば、7001とします。

    • ユーザー名: 管理サーバーの管理者アカウント名です。

    • User Password: 管理サーバーの管理者アカウント用パスワードです。

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

  4. セキュリティ・アップデートの指定画面で、必要に応じて、OracleサポートのOracleセキュリティ・アップデートを受け取るためのユーザー名およびパスワードを入力します。

  5. 「インストール場所の指定」画面で、次の値を入力します。

    • WebLogicサーバーの場所: Oracle WebLogic Serverのインストール・ディレクトリを入力します。これはMW_HOME/wlserver_10.3です。例:

      /u01/app/oracle/product/FMW/wlserver_10.3

    • Oracleインスタンスの場所: Oracle構成ファイルを配置するディレクトリを入力します。これは、Oracleホーム・ディレクトリの外部にする必要があります。このディレクトリは、ORACLE_INSTANCEとも呼ばれます。例:

      /u01/app/oracle/admin/fmw2

    • Oracleインスタンス名: fmw2

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

  6. 「コンポーネントの構成」画面で、インストールと構成を行う製品を選択します。Oracle Web CacheやOracle HTTP Serverをこのノードに配置する場合、選択されていることを確認します。


    注意:

    これは、APPHOST1で選択したものと同じリストにする必要があります。

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

  7. APPHOST1に使用されたものと同じstaticports.iniファイルを選択します。

  8. アプリケーション・アイデンティティ・ストアの指定画面で、次の値を指定します。

    • ホスト名: Oracle Internet Directoryサーバーの名前です(例: login.myoid.com)。

    • ポート: Oracle Internet Directoryポートです(例: 389)。

    • ユーザー名: cn=orcladmin

    • パスワード: Oracle Internet Directoryのorcladminアカウントのパスワードです。

  9. 「サマリー」画面で、「インストール」をクリックし、作成プロセスを開始します。

14.6.5.4 汎用構成

次の手順は、構成するコンポーネントに関係なく必要です。

14.6.5.4.1 APPHOST1からの構成情報のコピー

クラスタを開く操作により新しいWebLogic管理対象サーバーおよび関連付けられたマシンが作成されたら、APPHOST1からAPPHOST2にいくつかの構成情報をコピーする必要があります。

APPHOST1上にある次のファイルを、次の表に示すAPPHOST2の場所にコピーします。

ファイル APPHOST1の場所 APPHOST2の場所

mod_oradav.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

mod_osso.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

plsql.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

portal.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

forms.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

reports_ohs.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

module_disco.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

virtual_hosts.conf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

osso.conf

ORACLE_INSTANCE/config/OHS/ohs1/

ORACLE_INSTANCE/config/OHS/ohs1/

sqlnet.ora

ORACLE_INSTANCE/config

ORACLE_INSTANCE/config

tnsnames.ora

ORACLE_INSTANCE/config

ORACLE_INSTANCE/config

14.6.5.4.2 仮想ホストの構成

サイトをロード・バランサで適切に機能させるには、2つの仮想ホストを追加する必要があります。Oracle Enterprise Manager Fusion Middleware Controlを使用して仮想ホストを構成するか、ORACLE_INSTANCE/config/OHS/ohs1/httpd.confファイルを編集するか、ORACLE_INSTANCE/config/OHS/ohs1/moduleconfディレクトリにあるvirtual_hosts.confファイル(APPHOST1からコピー)を編集できます。

テキスト・エディタでファイルを更新し、APPHOST1をAPPHOST2に変更します。

NameVirtualHost *:7778
<VirtualHost *:7778>
     ServerName http://mysite.mycompany.com:80
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>

<VirtualHost *:7778>
    ServerName apphost2.mycompany.com:7777
    RewriteEngine On
    RewriteOptions inherit
    UseCanonicalName On
</VirtualHost>
14.6.5.4.3 クラスタ対応にするためのOracle HTTP Server構成の更新

インストールが最初に作成されると、APPHOST1に配置されるように最初に作成された管理対象サーバーにすべてのWeb Logicリクエストが転送されるように構成されていました。ここではAPPHOST2が存在するので、APPHOST1とAPPHOST2の両方のOracle HTTP Serverを、すべてのOracle WebLogic管理対象サーバーで認識させる必要があります。

Oracle HTTP ServerにAPPHOST2を認識させるには、次のディレクトリにあるファイルを編集します。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

次の表に示すように、Portal、Forms、ReportsおよびDiscovererのそれぞれに対して異なるファイルを編集します。

製品 ファイル

Portal

portal.conf

Forms

forms.conf

レポート

reports_ohs.conf

Discoverer

module_disco.conf

次のようにファイルを編集します。

  1. WebLogicHostやWebLogicPortで始まる行を削除し、次の行を追加します。

    WebLogicCluster apphost1:9001,apphost2:9001

  2. WebLogicClusterで始まる行をすべて、次のような行に変更します。

    WebLogicCluster apphost1:9001,apphost2:9001

    たとえば、次のような行を探して変更します。

    <Location /portal>
    SetHandler weblogic-handler
    WebLogicHost apphost1.mycompany.com
    WebLogicPort PORT
</Location>

    前述の行を次のように変更します。

    <Location /portal>
    SetHandler weblogic-handler
    WebLogicCluster apphost1.mycompany.com:PORT,apphost2.mycompany.com:PORT
</Location>

    次のような行を探して変更します。

    <Location /Forms>
    SetHandler weblogic-handler
    WebLogicCluster apphost1.mycompany.com:PORT
</Location>

    前述の行を次のように変更します。

    <Location /Forms>
    SetHandler weblogic-handler
    WebLogicCluster apphost1.mycompany.com:PORT,apphost2.mycompany.com:PORT
</Location>

これらの手順をAPPHOST2上で繰り返します。

14.6.5.4.4 Web Cacheパスワードの変更

Web Cacheパスワードはランダムに生成されますが、後の段階で必要になります。したがって、Web Cacheパスワードをデフォルト値から新しい既知の値に変更することをお薦めします。

デフォルトのパスワードを変更する手順は、次のとおりです。

  1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

  2. wc1コンポーネントをクリックします。

  3. ページの最上部にあるドロップダウン・リストから「管理 - パスワード」を選択します。

  4. 新しい無効化パスワードと管理パスワードを入力してからそれらを確認し、「適用」をクリックします。


注意:

この手順で使用するパスワードは、APPHOST1で使用するパスワードと同一である必要があります。これは、後の手順でWebキャッシュをまとめてクラスタ化するために必要です。

14.6.5.4.5 Web Cacheの構成

Web Cacheは、Oracle Forms、ReportsおよびDiscovererの場合はオプションですが、Oracle Portalの場合は必須です。APPHOST1でWeb Cacheを構成しなかった場合、次のWeb Cache構成手順は無視してください。

Enterprise Managerコンソールへのログイン

次のURLを使用して、Enterprise Managerコンソールにログインします。

http://apphost1.mycompany.com:7001/em

デフォルトの「ユーザー名」および「パスワード」は、インストール中に入力されたWebLogicドメイン・ユーザー名およびパスワードと同じです。

オリジナル・サーバーの作成

オリジナル・サーバーを作成する手順は次のとおりです。

  1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

  2. wc1コンポーネントをクリックします(これがAPPHOST1と関連付けられているものであることを確認します)。

  3. ページの最上部にあるドロップダウン・リストから「管理 - オリジナル・サーバー」を選択します。

  4. 「作成」をクリックします。

  5. 次の情報を入力し、オリジナル・サーバーを追加します。

    フィールド 値

    ホスト

    APPHOST2.mycompany.com

    ポート

    7778

    許容量

    100

    プロトコル

    HTTP

    フェイルオーバーのしきい値

    5

    pingのURL

    /

    pingの間隔

    10

  6. 「OK」をクリックして変更を保存します。

  7. 「適用」をクリックして変更を保存します。

既存のサイトからサーバーへのマッピングへのオリジナル・サーバーの追加

サイトからサーバーへのマッピングにオリジナル・サーバーを追加する手順は次のとおりです。

  1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

  2. wc1コンポーネントをクリックします(これがAPPHOST1と関連付けられているものであることを確認します)。

  3. ページの最上部にあるドロップダウン・リストから「管理 - サイト」を選択します。

  4. 「サイトからサーバーへのマッピング」セクションで<ホスト:ポート>をクリックします。例:

    mysite.mycompany.com:80

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

  6. オリジナル・サーバーのAPPHOST2.mycompany.com:7778を選択してから、選択したオリジナル・サーバー・リストに移動します。

  7. 「OK」をクリックして変更を保存します。

  8. 「適用」をクリックして変更を保存します。

APPHOST1およびAPPHOST2におけるWeb Cacheのクラスタ化

APPHOST1およびAPPHOST2上でOracle Web Cacheをクラスタ化する手順は次のとおりです。


注意:

Oracle Web Cacheのクラスタリングを適切に機能させるには、まとめてクラスタ化されたWeb Cacheそれぞれの管理パスワードが同一である必要があります。

  1. 「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。

  2. wc1コンポーネントをクリックします(これがAPPHOST1と関連付けられているものであることを確認します)。

  3. ページの最上部にあるドロップダウン・リストから「管理 - クラスタ」を選択します。

  4. 「追加」をクリックします。

    APPHOST2のWeb Cacheが自動的に追加されます。

  5. 「適用」をクリックして変更を適用します。

  6. 新しく作成されたWeb Cacheエントリをクリックします(エントリのURL部分をクリックしないようにしてください)。

  7. 「同期化」をクリックし、構成をAPPHOST2上のWeb Cacheにコピーします。

  8. 操作を実行することの確認を求められたら「はい」をクリックします。

  9. 「適用」をクリックして新しい構成を適用します。

14.6.5.4.6 APPHOST1およびAPPHOST2上のWebプロセスの再開

前述の変更を行った後、各サーバー上で次のコマンドを使用して、APPHOST1およびAPPHOST2上のWeb層コンポーネントを再起動します。

opmnctl stopall 
opmnctl startall

14.6.5.5 高可用性のためのOracle Portalの構成

この項で説明する手順は、高可用性のためのOracle Portalの構成にのみ使用します。

14.6.5.5.1 APPHOST1からの構成情報のコピー

クラスタを開く操作により、新しいWebLogic管理対象サーバーおよび関連付けられたマシンが作成されますが、APPHOST1からAPPHOST2にいくつかの構成情報をコピーする必要があります。

APPHOST1上にある次のファイルを、次の表に示すAPPHOST2の場所にコピーします。

ファイルまたはディレクトリ APPHOST1の場所 APPHOST2の場所

ORACLE_HOME/portal

ORACLE_HOME/portal

ORACLE_HOME/portal

appConfig.xml

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/

portal_cache.conf

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/

portal_dads.conf

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/

portal_plsql.conf

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL/applications/portal/configuration/

DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configuration/

14.6.5.5.2 Portalディレクトリの作成

APPHOST2上に次のディレクトリを作成するとOracle Portal Cacheの記憶域にできます。

ORACLE_INSTANCE/portal/cache
ORACLE_INSTANCE/diagnostics/logs/portal
14.6.5.5.3 インスタンス・パスの更新

次の2つのコピー・ファイルにおいて、ハードコードされたエントリを編集し、前述のパスを反映するようにします。

  • portal_cache.confファイルで、PlsqlCacheDirectoryを変更します。

  • portal_plsql.confファイルで、PlsqlLogDirectoryを変更します。

これらのファイルは、DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configurationディレクトリにあります。

14.6.5.5.4 Webプロセスの再開

各サーバー上で次のコマンドを使用し、APPHOST2上のWeb層コンポーネントを再起動します。

opmnctl stopall
opmnctl startall
14.6.5.5.5 WLS_PORTAL1の起動

これで、アプリケーション・ファイルが全体にコピーされました。次の手順で、管理対象サーバーのWLS_PORTAL1を起動します。

  1. 次のURLを使用してAPPHOST1上の管理サーバーにログインします。

    http://APPHOST1.mycompany.com:7001/console

  2. WebLogic管理コンソールのログイン資格証明を入力します。

  3. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

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

  5. 管理対象サーバーWLS_PORTAL1の横にあるボックスを選択し、「停止 - ただちに強制停止」をクリックします。

  6. 「はい」をクリックして操作を確認します。

    これにより、サーバーの状態がリセットされます。

14.6.5.5.6 構成の検証

構成を検証する手順は次のとおりです。

テスト URL 結果

ロード・バランサを経由したPortalのテスト

http://mysite.mycompany.com/portal/pls/portal

Portalのホーム・ページが開きます。

ロード・バランサを経由したPortalログインのテスト

http://mysite.mycompany.com/portal/pls/portal

orcladminアカウントを使用してログインできる必要があります。

14.6.5.5.7 ベスト・プラクティス

デフォルトでは、構成情報はすべてのサーバー・インスタンスに自動的に伝播されません。1台のポータル・サーバー上で構成ファイルが変更された場合、その構成をすべてのサーバーに伝播するようにしてください。

14.6.5.6 高可用性のためのOracle Formsの構成

この項で説明する手順は、高可用性のためのOracle Formsの構成にのみ使用します。

14.6.5.6.1 カスタマ・データベースのTNSNAMESエントリの作成

アプリケーションで1つ以上のデータベースにアクセスする場合、アクセスされる各データベースのエントリをtnsnames.oraファイルに配置します。

ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

mydb.mycompany.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mydb.mycompany.com)
    )
  )

これは、Oracle RACデータベース接続文字列です。

14.6.5.6.2 Forms構成ファイルのコピー

クラスタを開く操作により、新しいWebLogic管理対象サーバーおよび関連付けられたマシンが作成されますが、APPHOST1からAPPHOST2にいくつかの構成情報をコピーする必要があります。

APPHOST1上の次のファイルをコピーします。

ファイル APPHOST1の場所 APPHOST2の場所

すべて

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config

DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/config

すべて

ORACLE_INSTANCE/config/FormsComponent/forms

ORACLE_INSTANCE/config/FormsComponent/forms

すべて

ORACLE_INSTANCE/config/FRComponent/frcommon

ORACLE_INSTANCE/config/FRComponent/frcommon

14.6.5.6.3 default.envの更新

前述のファイルをコピーしたら、DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS1/applications/formsapp_11.1.1/configディレクトリのdefault.envファイルを、APPHOST2に適した値に更新します。特に、次のエントリを変更する必要があります。

  • ORACLE_INSTANCE

  • TNS_ADMIN

  • FORMS_PATH

  • WEBUTIL_CONFIG

通常、これらのエントリは次の値になっています。

ORACLE_INSTANCE=/u01/app/oracle/admin/Forms1
TNS_ADMIN=/u01/app/oracle/admin/Forms1/config
FORMS_PATH=/u01/app/oracle/product/FMW/Forms/forms:/u01/app/oracle/admin/Forms1/FormsComponent/forms
WEBUTIL_CONFIG=/u01/app/oracle/admin/Forms1/config/FormsComponent/forms/server/webutil.cfg

前述の値を、次のように変更する必要があります。

ORACLE_INSTANCE=/u01/app/oracle/admin/Forms2
TNS_ADMIN=/u01/app/oracle/admin/Forms2/config
FORMS_PATH=/u01/app/oracle/product/FMW/Forms/forms:/u01/app/oracle/admin/Forms2/FormsComponent/forms
WEBUTIL_CONFIG=/u01/app/oracle/admin/Forms2/config/FormsComponent/forms/server/webutil.cfg
14.6.5.6.4 WLS_FORMS1の再起動

前の項で述べた変更を行った後、次のURLを使用してOracle WebLogic管理コンソールにログインし、WebLogic管理対象サーバーのWLS_FORMSとWLS_FORMS1を再起動します。

http://apphost1.mycompany.com:7001/console

  1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

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

  3. WLS_FORMS1サーバーの横にあるボックスを選択します。

  4. 「停止」→「ただちに強制停止」を選択します。

  5. 確認ダイアログが開いたら、「はい」を選択します。

  6. サーバーを停止したら、WLS_FORMS1サーバーの横にあるボックスを選択して再起動します。

  7. 「起動」をクリックします。

14.6.5.6.5 構成の検証

構成を検証するには、次のテストを実行します。

テスト URL 結果

ロード・バランサのテスト

http://mysite.mycompany.com/

ASのホーム・ページが開きます。

Forms

http://mysite.mycompany.com/forms/frmservlet

Formsサーブレットのホーム・ページが開きます。

14.6.5.6.6 ベスト・プラクティス

WebLogicアプリケーション・サーバーでは、構成情報は複数のノード間で自動的にレプリケートされません。次のいずれに行われた変更もすべて、デプロイメント内の他のサーバーに手動で伝播することが重要です。

  • ORACLE_INSTANCE

  • DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.1/config

14.6.5.7 高可用性のためのOracle Reportsの構成

この項で説明する手順は、高可用性のためのOracle Reportsの構成にのみ使用します。

14.6.5.7.1 カスタマ・データベースのTNSNAMESエントリの作成

Oracle Reportsでは、tnsnames.oraファイルのエントリを使用して、データベース接続情報を判別します。Oracle Reportsキュー・データベースのエントリをこのファイルに配置します。

ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

mydb.mycompany.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mydb.mycompany.com)
    )
  )

ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。

tnsping myreportq.mycompany.com
14.6.5.7.2 共有出力ディレクトリにアクセスするためのReports Serverの構成

CacheDirプロパティまたはJOCCacheDirプロパティを各rwserver.confファイルの<cache>要素に追加します。このファイルはDOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configuration/ディレクトリにあります。

例:

<property name="JOCCacheDir" value="folder_name"/>
<property name="CacheDir" value="folder_name"/>

UNIXの場合:

<cache class="oracle.reports.cache.RWCache">
      <property name="cacheSize" value="50"/>
      <!--property name="cacheDir" value="your cache directory"/-->
      <!--property name="maxCacheFileNumber" value="max number of cache files"/-->
      <property name="JOCCacheDir" value="/share/reports"/>
      <property name="CacheDir" value="/share/reports"/>
   </cache>
14.6.5.7.3 インプロセスReports Serverのデータベース・ジョブ・リポジトリの構成

レポート・キューがデータベースに配置されたら、rwserver.confファイルを編集して、それにアクセスする方法をReports Serverに認識させます。そのファイルは、DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configurationディレクトリにあります。

ファイルを編集する場合、サーバー構成ファイル内の様々なエントリの順序は固定されています。したがって、次の要素は、サーバー構成ファイルの<jobStatusRepository>要素の直後に追加する必要があります。

 <jobRepository>
        <property name="dbuser" value="dbuser"/>
        <property name="dbpassword" value="csf:reports:dbpasswdKey"/>
        <property name="dbconn" value="dbconn"/>
      </jobRepository>

ここで、dbuserはレポート・キューが配置されているスキーマの名前です。

また、dbconnは、ORACLE_INSTANCE/configディレクトリにあるtnsnames.oraファイルのデータベース・エントリを参照します。dbpasswdKeyは、作成されたエントリの名前です。

例:

<jobRepository>
        <property name="dbuser" value="reports_queue"/>
        <property name="dbpassword" value="csf:reports:queuePassword"/>
        <property name="dbconn" value="myrepq.mycompany.com"/>
</jobRepository>

クラスタ・ノードの値は、APPHOST1上のrwservlet.propertiesファイルの<server>タグに記述されている値です。

クラスタ・ノードのパラメータでは、ローカル・レポート・サーバーを除いてクラスタ内のすべてのレポート・サーバーを(カンマ区切りで)リストする必要があります。

14.6.5.7.4 Oracle Reports Serverクラスタの作成

データベース・レポート・キューでReportsクラスタを作成すると、すべてのReports Serverを同じキューにリンクすることができます。この処理の利点は、サーバーの処理能力に余裕があるときに、このキューで次のレポートを実行し、負荷を分散させることができるということです。また、クラスタ・メンバーが使用できなくなったときに、別のReports Serverがこれを検出して、障害が発生したサーバーが処理していたレポートを実行するするようにすることもできます。

Reportsクラスタを作成するには、APPHOST1およびAPPHOST2の両方のrwservlet.propertiesファイルにクラスタ・エントリを追加します。

クラスタAPPHOST1

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_11.1.1.2.0/configurationディレクトリにあるrwservlet.propertiesファイルを編集します。

次の行を追加します。

<cluster clustername="cluster_reports" clusternodes="rep_wls_reports1_APPHOST2_reports2"/>

注意:

clusternodesの値は、APPHOST2にあるrwservlet.propertiesファイルの<server>タグの中の値です。


注意:

clusternodesパラメータでは、ローカルReports Serverを除いてクラスタ内のすべてのReports Serverを(カンマ区切りで)リストする必要があります。

クラスタAPPHOST2

DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS1/applications/reports_11.1.1.2.0/configurationディレクトリにあるrwservlet.propertiesファイルを編集します。

次の行を追加します。

<cluster clustername="cluster_reports" clusternodes="rep_wls_reports_APPHOST1_reports1"/>

注意:

clusternodesの値は、APPHOST1にあるrwservlet.propertiesファイルの<server>タグの中の値です。


注意:

clusternodesパラメータでは、ローカルReports Serverを除いてクラスタ内のすべてのReports Serverを(カンマ区切りで)リストする必要があります。

14.6.5.7.5 WLS_REPORTSとWLS_REPORTS1の再起動

次のURLを使用してWebLogic管理コンソールにログインし、Web Logic管理対象サーバーのWLS_REPORTSとWLS_REPORTS1を再起動します。

http://apphost1.mycompany.com:7001/console

  1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

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

  3. WLS_REPORTSサーバーとWLS_REPORTS1サーバーの横にあるボックスを選択します。

  4. 「停止」→「ただちに強制停止」を選択します。

  5. 確認ダイアログが開いたら、「はい」を選択します。

  6. サーバーを停止したら、WLS_REPORTSサーバーとWLS_REPORTS1サーバーの横にあるボックスを選択して再起動します。

  7. 「起動」をクリックします。

14.6.5.7.6 構成の検証

構成を検証するには、次のテストを実行します。

テスト URL 結果

ロード・バランサのテスト

http://mysite.mycompany.com/

ASのホーム・ページが開きます。

レポート・キューのテスト

http://mysite.mycompany.com/reports/rwservlet/showjobs

「シングル・サインオン」ページおよびレポート・キュー・ページが開きます。

14.6.5.7.7 Oracle Reportsサービスの接続可用性の管理

ロード・バランシング・ルーター、ファイアウォール、Oracle HTTP ServerおよびWebLogic Serverに対するアイドル接続を管理するタイムアウト設定を、それらのOracle Reportsサービス・アプリケーション要件に従って調整する必要があります。たとえば、ロード・バランシング・ルーターおよびファイアウォール接続タイムアウトが10分に設定されている場合に、レポートの実行時間が10分を超えると、ブラウザ接続は、ロード・バランシング・ルーターによってタイムアウトになり、Oracle Reportsサービスの出力はブラウザに出力されなくなります。Oracle Reportsサービス・クライアントとOracle Reports Serverとの間における接続のタイムアウト値は、Oracle Reportsサービス・サーバー構成ファイルのrwserver.confにある接続要素のidleTimeout属性によって制御されます。

14.6.5.8 高可用性のためのOracle Discovererの構成

この項で説明する手順は、高可用性のためのOracle Discovererの構成にのみ使用します。

14.6.5.8.1 カスタマ・データベースのTNSNAMESエントリの作成

アプリケーションで1つ以上のデータベースにアクセスする場合、アクセスされる各データベースのエントリをtnsnames.oraファイルに配置します。

ORACLE_INSTANCE/config/tnsnames.oraファイルを編集し、次のようなエントリを追加します。

mydb.mycompany.com =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = mydbnode2-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mydb.mycompany.com)
    )
  )

これは、Oracle RACデータベース接続文字列です。

ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。

tnsping myreportq.mycompany.com
14.6.5.8.2 Discoverer構成ファイルのコピー

クラスタを開く操作により、新しいWebLogic管理対象サーバーおよび関連付けられたマシンが作成されました。ただし、APPHOST1からAPPHOST2にいくつかの構成情報をコピーする必要があります。

この手順を実行する前に、DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/ディレクトリのconfiguration.xmlファイルをコピーします。

このファイルをAPPHOST1から、APPHOST2の同じディレクトリにコピーします。

14.6.5.8.3 configuration.xmlの更新

コピーしたconfiguration.xmlファイルを更新し、次の値をconfiguration.xml.origファイルの値で置換します。

<oracleInstance>
<discovererComponentName>
14.6.5.8.4 プリファレンス・ストアの変更

エンタープライズ・デプロイメントでは、一度にアクティブになるDiscovererプリファレンス・ストアは1つのみです。プリファレンス・ストアを変更するには、APPHOST2上のOracle DiscovererがAPPHOST1上のプリファレンス・ストアを指すように変更します。

プリファレンス・ストアのホスト名とポートの識別

この例で指定するプリファレンス・サーバーは、APPHOST1上で実行するように構成されています。サーバーにインストールすると、プリファレンス・サーバーはポートを割り当てられます。次の手順に進む前にこの値を探します。

  1. APPHOST1上で、ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるopmn.xmlファイルを開きます。

  2. ファイルにおいてPREFERENCE_PORTエントリを探します。「value=」は、プリファレンス・サーバーに割り当てられたポートを示します。

他のマシン上のDiscovererプリファレンス・サーバーの指定

プリファレンス・コンポーネント(Discovererプリファレンス・サーバー・マシン)を実行するマシンのホスト名とポート番号を特定したら、他のマシンがDiscovererプリファレンス・サーバー・マシン上のプリファレンス・コンポーネントを使用するように確認する必要があります。

他のマシンのopmn.xmlファイルを変更してDiscovererプリファレンス・サーバー・マシンを使用するには、インストールの他のすべてのマシンで次の手順を実行します。

  1. プリファレンス・サーバー・マシン以外のすべての各マシンで、テキスト・エディタ(またはXMLエディタ)でopmn.xmlファイルを開きます。

  2. PREFERENCE_HOST変数を探してから、その値を次のようにDiscovererプリファレンス・サーバー・マシンのホスト名に変更します。

    <variable id="PREFERENCE_HOST" value="hostname">

  3. PREFERENCE_PORT変数を探してから、その値を次のようにDiscovererプリファレンス・サーバー・マシンのポート番号に変更します。

    <variable id="PREFERENCE_PORT" value="port">

  4. PreferenceServerプロセス・タイプを探してから、次のようにその状態をdisabledに変更します。

    <process-type id="PreferenceServer" module-id="Disco_PreferenceServer"
working-dir="$DC_LOG_DIR" status="disabled">

  5. opmn.xmlファイルを保存します。

14.6.5.8.5 WLS_DISCOおよびWLS_DISCO1の再起動

次のURLを使用してWebLogic管理コンソールにログインし、Web Logic管理対象サーバーのWLS_DISCOおよびWLS_DISCO1を再起動します。

http://apphost1.mycompany.com:7001/console

  1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

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

  3. WLS_DISCOサーバーとWLS_DISCO1サーバーの横にあるボックスを選択します。

  4. 「停止」→「ただちに強制停止」を選択します。

  5. 確認ダイアログが開いたら、「はい」を選択します。

  6. サーバーを停止したら、WLS_DISCOサーバーとWLS_DISCO1サーバーの横にあるボックスを選択して再起動します。

  7. 「起動」をクリックします。

14.6.5.8.6 構成の検証

構成を検証するには、次のテストを使用します。

テスト URL 結果

ロード・バランサのテスト

http://mysite.mycompany.com/

ASのホーム・ページが開きます。

Discoverer

http://mysite.mycompany.com /discoverer/viewer

Discoverer Servletのホーム・ページが開きます。

14.6.5.8.7 プリファレンス・サーバーのフェイルオーバー

プリファレンス・サーバーをホストしているサーバーに障害が発生した場合、障害が発生していないノードのいずれかで次の手順を使用してプリファレンス・サーバーを起動する必要があります。

プリファレンス・ストアのホスト名とポートの識別

この例で指定するプリファレンス・サーバーは、APPHOST1上で実行するように構成されています。サーバーにインストールすると、プリファレンス・サーバーはポートを割り当てられます。次の手順を使用してこの値を探します。

  1. APPHOST1上で、ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるopmn.xmlファイルを開きます。

  2. ファイルにおいてPREFERENCE_PORTエントリを探します。「value=」は、プリファレンス・サーバーに割り当てられたポートを示します。

APPHOST2上でのプリファレンス・ストアの有効化

APPHOST2がAPPHOST1上のプリファレンス・ストアを使用するようになったら、ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるopmn.xmlファイルを編集して、APPHOST2上のプリファレンス・ストアを無効化します。

次の行を探します。

<process-type id="PreferenceServer" module-id="Disco_PreferenceServer" working-dir="$DC_LOG_DIR" status="disabled">

status=disabledをstatus=enabledに変更します。

例:

<process-type id="PreferenceServer" module-id="Disco_PreferenceServer" working-dir="$DC_LOG_DIR" status="enabled">

APPHOST2上のプリファレンス・サーバーの起動

次のコマンドを使用してAPPHOST2上のプリファレンス・サーバーを起動します。

opmnctl startproc process-type=PreferenceServer

障害の発生していないサーバーがAPPHOST2上のプリファレンス・ストアを使用するための変更

プリファレンス・サーバーがAPPHOST2上で起動したら、APPHOST2を含めてすべてのDiscovererインスタンスがこのプリファレンス・サーバーを使用するように修正します。

使用されるプリファレンス・ストアは、WebLogic管理対象サーバーであるWLS_DISCO1の起動時に決まります。WLS_DISCO1が別のプリファレンス・ストアを使用するようにするには、次のURLを使用してWebLogic管理コンソールにログインして、起動パラメータを変更する必要があります。

http://apphost1.mycompany.com:7001/console

次の手順を続行します。

  1. 「ドメイン構造」メニューから「環境」→「サーバー」を選択します。

  2. 「チェンジ・センター」で、「ロックして編集」をクリックします。

  3. WLS_DISCO1サーバーをクリックします。

  4. 「構成」タブ、「サーバーの起動」サブタブの順にクリックします。

  5. 引数フィールドで、次の行を追加します。

    -Doracle.disco.activation.preferencePort=<portno>
-Doracle.disco.activation.preferenceHost=<hostname>

    ポート番号は、前に定義したPREFERENCE_PORTの値です。

    ホスト名は、プリファレンス・サーバーが起動されたホストの名前です(例: APPHOST2)。

14.6.5.8.8 クラスタ環境でのDiscoverer WSRPポートレット・プロデューサの設定

ポートレット・プリファレンス・ストアは、コンシューマ登録ハンドルおよびポートレット・プリファレンス・データを永続的に保持するために使用されます。

Discoverer WSRPポートレット・プロデューサでは、ファイルベースのプリファレンス・ストアを使用します。プリファレンス・ストアの場所は、Discovererデプロイメント・プラン(XMLファイル)のdiscoWsrpPrefStoreSharedPath変数の値で定義されます。discoWsrpPrefStoreSharedPath変数のデフォルト値は、portletDataです。

デプロイメント・プランおよびその内容の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・プランの内容の理解に関する項を参照してください。

クラスタ環境では、ファイルベースのプリファレンス・ストアに対して、同じOracle WebLogic Server内で稼働するすべてのDiscoverer WSRPポートレット・プロデューサはデプロイメント・プランのdiscoWsrpPrefStoreSharedPath変数に同じパスを使用する必要があります。そのため、「プリファレンス・ストアの設定」の項で説明されているように、discoWsrpPrefStoreSharedPath変数の値はデプロイメント・プランの共有パスに変更する必要があります。

discoWsrpPrefStoreSharedPath変数を変更してプリファレンス・ストアのコンテンツを既存のプリファレンス・ストアから共有パスに移行する場合、「移行ユーティリティを使用したプリファレンス・ストア・コンテンツの転送」の項で説明されているように、移行ユーティリティを実行してプリファレンス・データを移行元パスから移行先パスに転送する必要があります。

プリファレンス・ストアの設定

Discovererのデプロイメント・プランを表示および編集するには、次の手順に従います。

  1. 管理コンソールにログインします。

  2. 左側のペインで、「デプロイメント」をクリックします。

  3. 右側のペインで、デプロイメント・プランを更新するDiscovererアプリケーションを選択します。「Discoverer: 概要」ページが表示されます。

「概要」ページの「デプロイメント・プラン」フィールドには、Discovererアプリケーション・デプロイメント・プラン(XMLファイル)のパスが表示されます。次の手順に示すように、デプロイメント・プランを変更します。

  1. XMLエディタで、「Discoverer: 概要」ページに表示されている場所からデプロイメント・プランを開きます。

  2. variable-definitionセクションへ移動します。

    ...
      <variable-definition>
        <variable>
          <name>discoWsrpPrefStoreSharedPath</name>
          <value>portletData</value>
        </variable>
      <variable-definition>
...

    注意:

    discoWsrpPrefStoreSharedPath変数は、デプロイメント・プランのvariable-definitionおよびvariable-assignmentセクションで定義されます。variable-definitionセクションで定義されているdiscoWsrpPrefStoreSharedPath変数のみを変更してください。

  3. discoWsrpPrefStoreSharedPath変数のvalueを、すべての管理対象サーバーがアクセスできるSharedPathに変更します。

    ...
      <variable-definition>
        <variable>
          <name>discoWsrpPrefStoreSharedPath</name>
          <value>SharedPath</value>
        </variable>
      <variable-definition>
...

    注意:

    valueの絶対パスを指定する必要があります。valueの相対パスは、ORACLE_HOME/portalディレクトリを基準に解釈されます。

  4. 変更を保存してXMLファイルを閉じます。

デプロイメント・プランをdiscoWsrpPrefStoreSharedPath変数の新しい値で更新したら、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプのエンタープライズ・アプリケーションの更新(再デプロイ)に関する項で説明されているように、Discovererアプリケーションを更新する必要があります。

移行ユーティリティを使用したプリファレンス・ストア・コンテンツの転送

WSRPコンテナ・プリファレンス・ストア移行ユーティリティPersistenceMigrationToolを使用すると、異なるプリファレンス・ストア間で既存のデータを移行できます。

PersistenceMigrationToolの構文は次のとおりです。

java oracle.portlet.server.containerimpl.PersistenceMigrationTool
-sourceType file -destType file -sourcePath dir -destPath dir

sourceTypeは、移行元ストアがファイル内にあることを示します。

destTypeは、移行先ストアがファイル内にあることを示します。


注意:

Discoverer WSRPプロデューサでは、ファイルベースのプリファレンス・ストアを使用します。そのため、sourceTypeおよびdestType引数にfileを指定する必要があります。

sourcePathおよびdestPathは、ファイルベースのプリファレンス・ストアの場所です。


注意:

このツールを実行して、wsrp-container.jar、oracle.portlet-api.jar、およびojdbc6.jarを組み込む場合は、クラスパスを設定する必要があります。例:

java -classpath $ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/oracle-portlet-api.jar:$ORACLE_HOME/webcenter/modules/oracle.portlet.server_11.1.1/wsrp-container.jar:$WL_HOME/server/lib/ojdbc6.jar

14.6.5.8.9 ベスト・プラクティス

Oracle WebLogic Serverでは、構成情報は複数のノード間で自動的にレプリケートされません。したがって、次のいずれに行われた変更もすべて、デプロイメント内の他のサーバーに手動で伝播することが重要です。

  • ORACLE_INSTANCE

  • DOMAIN_HOME/servers/WLS_DISCO1/applications/discoverer_version/configuration/configuration.xml

プリファレンス・サーバー

プリファレンス・サーバーには、ユーザー・プリファレンスに関する詳細が含まれています。これは頻繁に更新される場合があります。Oracle Discovererプリファレンス・サーバーに障害が発生した場合は、そのプリファレンス・サーバーを別のサーバー上で起動する必要がありますプリファレンス情報を、これらの代替として使用される場合があるホストに定期的にコピーする必要があります。

プリファレンス・サーバーをホストする場合がある他のサーバーに定期的に次のファイルを伝播する必要があります。

ORACLE_INSTANCE/config/PreferenceServer/Discoverer_Instance/.reg_key.dc

14.6.6 デプロイメントのスケール・アウト

デプロイメントを追加のノードにスケール・アウトするには、第14.6.5項「APPHOST2でのアプリケーション層のインストールと構成」の手順に従います。以前のノードに使用したディレクトリ構造と同じものを使用します。

  前
前 		 次
次
  目次へ移動
目次