この章では、Oracle Portals、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は、単一インスタンスの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によってリクエストが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.conf
と呼ばれるApacheモジュールを使用して、リクエストをOracle WebLogic管理対象サーバーにルーティングします。WebLogic管理対象サーバーがまとめてクラスタ化されている場合、mod_wl_ohs.conf
では、そのクラスタにあるすべての管理サーバー間でリクエストがロード・バランシングされます。
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サーバーと通信して認可を受けます。
次の表に、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ログ・ファイル |
この項では、Oracle Portal、Forms、ReportsおよびDiscovererに適用される高可用性の概要について説明します。
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によってそのプロセスが再起動されます。
Oracle Web Cacheが前面に配置されていないノードに障害が発生した場合、正常に動作しているノードにリクエストがロード・バランサによって自動的に再ルーティングされます。
Oracle Web Cacheに障害が発生した場合、正常に動作しているWebキャッシュ・ノードにリクエストがロード・バランサによって自動的に再ルーティングされます。
Oracle Web Cacheが前面に配置されているOracle HTTP Serverのノードに障害が発生した場合、正常に動作しているOracle HTTP ServerにリクエストがOracle Web Cacheによって再ルーティングされます。
WebLogic Serverに障害が発生した場合、リクエストはOracle HTTP Serverによって別のWebLogicクラスタ・メンバーに再ルーティングされます。
Oracle Portal、Forms、ReportsおよびDiscovererリクエストが障害発生ノードで処理されていた場合、リクエストを再開する必要があります。
高可用性構成では、Oracle WebLogic管理対象サーバーはまとめてクラスタ化されます。管理対象サーバーのいずれかに障害が発生した場合、正常に動作しているクラスタ・メンバーのいずれかにリクエストがmod_wl_ohs.conf
によってリダイレクトされます。アプリケーションに状態が格納されている場合、状態のレプリケーションがクラスタ内で使用可能になり、これにより、リダイレクトされたリクエストが、同じ状態情報にアクセスできます。
データベースは、Oracle Real Application Clustersなどの高可用性テクノロジを使用して実装することをお薦めします。データベース・ノードのいずれかに障害が発生した場合でも、そのデータベース全体は使用可能な状態に維持されます。場合によっては、リクエストの再送信が必要です。
マルチ・データベース・ノード環境では、障害が発生したデータベース・ノードにユーザー・セッションが接続されている場合、次のようになります。
Oracle Portal: ユーザーは、リクエストを再送信する必要があります。
Oracle Forms: ユーザーは、リクエストを再送信する必要があります。
Oracle Reports: Oracle Transparent Application Failoverを使用してデータベース接続文字列が構成されている場合、アクションは必要ありません(レポートがその実行中にデータベースに書き込まれていない場合)。
レポート・キューを含むデータベースでノードが失われた場合、ユーザーはレポート・リクエストを再送信する必要があります。
Oracle 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管理対象サーバーはクラスタ化され、クラスタ・レベルでリソースを共有します。これらのリソースに対する変更は一括して実行できるため、伝播する必要はありません。これらのリソースは、次のとおりです。
データ・ソース
アプリケーションの再デプロイメント
状態のレプリケーション
この項では、Oracle Portalに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高い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つの規格により、異なるポータル製品で相互運用するポートレットの開発が可能になり、組織内におけるポートレットの可用性が高まります。
Oracle Portalのリクエスト・フローの詳細は、『Oracle Fusion Middleware Administrator's Guide for Oracle Portal』で次に示す各項を参照してください。
Oracle Portalにおいてページがアセンブルされる方法に関する項
Oracle Portalにおいて通信が行われる方法に関する項
Oracle Portalコンポーネントの特性は次のとおりです。
Oracle Portalアプリケーションは、WebLogicコンテナ(WLS_PORTAL)の内部で実行されます。
Oracle Portalのリポジトリには、メタデータ、ドキュメント、カスタマイズおよびパーソナライズが格納されます。
Oracle Portalは、コンテンツを処理してキャッシュするためにOracle Web Cacheに強く依存しています。
Oracle Portalは、Oracle HTTP Serverに依存して、トラフィックをWebLogic Serverにルーティングし、製品イメージのサービス処理を行い、URLをリライトします。
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を管理するためにあります。
Portalアプリケーションは、ステージング済アプリケーション(portal.ear
)としてWebLogic Server(WLS_PORTAL)にデプロイされます。構成ファイルはDOMAIN_HOME/servers/WLS_PORTAL/stage/portal/portal/configurationにあります。
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の構成ファイル
構成ファイル | 説明 |
---|---|
|
Portal Page Engine構成 |
|
ポータル・データベース・アクセス記述子(DAD)構成 このファイルには、高可用性(HA)に関するプロパティが含まれています。これには、データベースへの接続文字列情報が含まれています。Oracle RACノードが追加または削除された場合、ノードの最終的なセットを反映するようにこのファイルを更新する必要があります。このファイルには、構成プロパティが含まれています。これにより、プールされたデータベース接続を使用前にテストできます。このプロパティを有効にすると、データベース・ノードが停止した場合に、最小限のコストでより適切な結果を実現できます。 |
|
ポータル・キャッシュ構成 |
|
ポータルのグローバル設定 |
Portalのログ・ファイルは、DOMAIN_HOME
/servers/WLS_PORTAL/logs
ディレクトリに生成されます。ログ・ファイルの名前は、WLS_PORTAL-diagnostic.log
です。ログ・ローテーションにより、古いログは類似した名前でアーカイブされます。Portalのログ・ファイルの構成は、logging.xml
ファイルによって制御されます。このファイルはDOMAIN_HOME
/config/fmwconfig/servers/WLS_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モジュールが組み込まれています。Oracle HTTP Serverでは、JavaサーブレットおよびJ2EEアプリケーションを実行しているWebLogic 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のメモリー内コンテンツがファイル・システムに基づいたポータル・キャッシュにバックアップされます。
管理サーバーは、ノード1のみに単一のオブジェクトとして残ります。可用性の高いセットアップはOracle Portal、Reports、FormsおよびDiscovererではサポートされません。第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」で説明するコールド・フェイルオーバー・クラスタの変換プロセスも、Oracle Portal、Reports、FormsおよびDiscovererではサポートされません。
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インスタンス全体のキャッシュ整合性が確保されます。
注意: 独自のプロデューサをデプロイする場合、プロデューサに冗長性を持たせ、ロード・バランサをフロントエンドとして配置してください。この手順により、システム内のシングル・ポイント障害がなくなります。 |
特定のプロセスが停止した場合でも、各コンポーネントの冗長性により、Oracle Portalは継続的に機能します。Oracle Portalによってリクエストが再試行されないことに注意してください。したがって、特定のリクエストの処理中に障害が発生した場合、そのリクエストは失敗します。
Oracle Portal WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。
Oracle Portalのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。
この項では、Oracle Reportsに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Reportsデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。
注意: Oracle Fusion Middleware 11gリリース2 (11.1.2)では、Reports管理対象サーバーはサポートされません。 |
注意: アクティブ/アクティブ構成では、Webクライアントのみがサポートされます。コマンドライン・クライアント( |
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へのアクセスを制限することをお薦めします。
Oracle Reportsの状態情報は、ジョブ・メタデータのみです。たとえば、実行対象レポートに関する情報や実行時のパラメータなどがあります。これは多くの場合、レポート・キューと呼ばれます。この情報は、オペレーティング・システム・ファイルのservername.dat
またはデータベースに格納されます。
Oracle Reportsでは、Oracle HTTP Serverによるリクエストの処理が必要です。オプションで、これらのリクエストをOracle Web Cacheによってキャッシュできます。その場合、それはロード・バランサとしても機能します。
次の表に、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 |
この項では、次に示す接続の再試行について説明します。
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では、リクエストがデータベースから返されるまでの待機時間のタイムアウトを構成できます。このタイムアウトは、有効なレポートを実行するために十分な長さの時間にする必要があるだけでなく、長すぎない値に設定する必要もあります。
レポートの実行プロセスには、次のようにOracle Reportsサービスのコンポーネントが関連しています。
クライアントは、URL(Web)を経由してサーバーと通信することでレポートをリクエストします。
Reports Serverは、リクエストを次のように処理します。
リクエストにTOLERANCEオプションが含まれている場合、Reports Serverではそのキャッシュにそのリクエストを処理するための出力が存在しているかどうかが確認されます。そのキャッシュに適切な出力がある場合、レポートは再実行されず、その出力が即座に返されます。
そのリクエストが現在実行中のジョブと同じ場合、レポートは再実行されず、現在のジョブの出力が再利用されます。
これらの条件のどちらも満たされない場合:
Oracle Reportsサーブレット(rwservlet)でSSOが有効になっている場合、認証について確認されます。その後、セキュアなReports Serverによって、Oracle Internet Directoryが使用されてユーザーが認可されます。Oracle Reportsサーブレット(rwservlet)でSSOが無効になっている場合、セキュアなReports Serverによってユーザーの認証と認可が行われます。
レポートがスケジュール済である場合、Reports Serverによって、スケジュール済ジョブ・キューにリクエストが格納され、レポートはスケジュールに従って実行されます。レポートがスケジュールされていない場合、それは現行ジョブ・キューに格納され、Reports Engineが使用可能になったときに実行されます。
実行時に、Reports ServerによってReports Engineが作成され、そのエンジンにリクエストが送信され、実行されます。
Reports Engineによってデータが取り出され、書式設定されます。
Reports EngineによりReports Serverキャッシュに移入されます。
Reports Engineにより、レポートの準備完了がReports Serverに通知されます。
Reports Serverによって、キャッシュがアクセスされ、レポートが送信されます。そして、URL、コマンドライン、またはcgicmd.dat
ファイルのキーワード・セクション(URLリクエストのみ)で指定されたランタイム・パラメータに従ってレポートが出力されます。
リクエストの実行中にレポート・サーバーが停止した場合、そのリクエストを再送信する必要があります。再送信すると、障害が発生していないレポート・サーバーのいずれかによってそのリクエストが処理されます。
次の表に、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は、Oracle Reportsの高可用性デプロイメントの例を示しています。
図14-3では、Oracle Real Application Clustersデータベースにより、レポート・キュー用の高可用性リポジトリが実現されます。高可用性構成では、各Reports Serverは同じレポート・キューにアクセスします。共有レポート・キューによって、リクエストはどれも1回のみ処理されますが、デプロイメント内のどのReports Serverでもリクエストを処理できます。
管理サーバーは、ノード1のみに単一のオブジェクトとして残ります。可用性の高いセットアップはOracle Portal、Reports、FormsおよびDiscovererではサポートされません。第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」で説明するコールド・フェイルオーバー・クラスタの変換プロセスも、Oracle Portal、Reports、FormsおよびDiscovererではサポートされません。
通常、様々なデータベースに格納された情報を使用してレポートはコンパイルされます。図14-3では、これらのデータベースをカスタマ・データベースと呼びます。
Reportsキャッシュを十分に活用するには、1つの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はWebLogic Server内部で実行され、Reports Server自体をクラスタ化して、高可用性を確実に保持できます。
高可用性分散構成でWeb Cacheを使用する場合、すべての分散キャッシュのコンテンツに整合性があることが重要です。たとえば、あるレポートについて、どのOracle Web Cacheインスタンスからでも同じキャッシュ・コピーが使用できます。キャッシュされたコンテンツが無効になった場合、Webキャッシュのすべてで無効になることが不可欠です。これを実現するために、Webキャッシュ・クラスタリングが使用されます。
図14-3には、Web Logic管理サーバーが含まれており、それをAPPHOST2に配置する方法を示しています。
Reports Serverがハングしたり応答に失敗したが、WebLogic管理対象サーバーではハングや応答失敗が発生していない場合、WebLogic管理対象サーバーを手動で再起動する必要があります。
Oracle Reports WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。
Oracle Reportsのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。
この項では、Oracle Formsに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Formsデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。
Oracle Fusion Middleware Forms Servicesアーキテクチャでは、Webベースのアプリケーションと同様にクライアントとHTTPリスナーとの間の接続は1つのみです。HTTPリスナーによって、リクエストがFormsリスナー・サーブレットにルーティングされ、そこでFormsクライアントからFormsランタイムへのリクエストのルーティングが制御されます。
FormsクライアントとFormsランタイムとの間の通信は、常にHTTPリスナーを経由し、ネットワークに開いているポートは1つのみになります。
クライアントはHTTPリクエストを送信し、HTTPリスナー・プロセスからHTTPレスポンスを受信します。HTTPリスナーがクライアントに対してネットワーク・エンドポイントとして機能し、他のサーバー・マシンおよびポートはファイアウォールで公開されません。
Oracle Formsは、ステートフル・アーキテクチャを採用しています。各ランタイム・プロセスでは、サービスの提供先となるクライアントのために状態が作業メモリーに保持されます。状態は複数のランタイム・プロセス間でシリアライズや共有されませんし、そのようにできません。
Oracle Formsでは、相互作用の対象となるデータベースとのアクセスのみを必要です。Oracle Forms自体には特別な要件はありません。
Oracle Formsのリクエスト・フローは次のようになります。
ユーザーがWebページからリンクを選択するか、ブラウザでURLを直接入力します。
渡されたURLがHTTPリスナーによって解釈され、ブラウザにForms Javaクライアントを示す<EMBED>
タグまたは<OBJECT>
タグ(使用されているブラウザによって異なる)を含むHTMLページが表示されます。渡されたURLでは、Formsサーブレットをコールし、Webサーバー上にあるbase.htmlファイルに基づいてHTMLページを動的に作成します。
クライアントは、HTTPリスナーによって処理されたHTMLファイルを受信します。HTMLファイル内のタグには、Forms Javaクライアントを構成するJavaクラス・ファイルを探すために必要な情報があります。HTMLファイルのタグ内で、実行するFormに関する情報、およびログイン情報などFormsセッションに渡す他のすべてのパラメータに関する情報を指定します。タグ定義には、実行するForms Servicesに関する指示、およびJavaクライアントの外観(ルック・アンド・フィールや色のスキームなど)のカスタマイズに役立つパラメータも多数含まれています。
HTMLファイルには、他のHTML属性が含まれることもあります。クライアント上でJREの特定のバージョンを使用する特定アプレットを実行するようにブラウザに指示する属性などです。
その後、HTMLファイルに指定されている場所のJavaクラス・ファイルをブラウザはHTTPリスナーに対して要求します。これを定義するためにHTMLファイルのCODEBASEパラメータが使用されます。このファイルは個別にダウンロードできますし、アーカイブにもできます。このアーカイブには、.JAR拡張子が付きますが、アプレットに必要な個別クラス・ファイルすべてを含むZIPファイルと考えることもできます。JARファイルを使用すると、Javaクライアントのダウンロードが高速になり、後続のコールのためにクライアント上でキャッシングが可能になります。ARCHIVEパラメータにより、どの.JARファイルを使用するのかが定義されます(存在する場合)。JREプラグインにより、HTTPリスナー上で使用可能なFormsクライアント用Javaコードのバージョンを確認する追加手順が実行され、現在そのプラグインでキャッシュされているバージョンよりも新しいバージョンであることが判明した場合にのみダウンロードされます。
クラス・ファイルやJARファイルはブラウザにダウンロードされ(存在していない場合)、Javaアプレットが起動します。
Javaクライアント・アプレットからリクエストが送信され、HTTPリスナーを経由してFormsリスナー・サーブレットへのFormsセッションが開始します。Formsリスナー・サーブレットは、HTMLファイルのタグ内のserverURLパラメータによって定義されます。
Javaクライアントから接続リクエストを受信すると、Formsリスナー・サーブレットはこのクライアントのために新しいFormsランタイム・プロセスを開始します。formsweb.cfg
構成ファイルのサーブレット初期化用envFileパラメータを特定の環境ファイルに設定することで、各ランタイム・プロセスに対してユーザー固有の環境を定義できます。
このクライアントに割り当てられたFormsランタイム・プロセスにより、HTMLファイルで指定されているモジュール、それらのフォームに必要なライブラリおよびメニューすべてがロードされます。FormsクライアントとFormsランタイム・プロセスとの間におけるすべての通信は、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/
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ランタイム・プロセスとの間のネットワーク通信処理。
Oracle Formsの実行プロセスには、次のようにOracle Forms Servicesの様々なコンポーネントが関連しています。
クライアントは、URLを経由してサーバーと通信することでフォームをリクエストします。
Oracle HTTP Serverは、リクエストをWebLogic Serverにルーティングします。
WebLogic Serverは、フォームを実行するためのFormsランタイム・プロセスを作成します。
中間層のサーバーで障害が発生したりサーブレット・セッションが中断した場合、アプリケーションを再起動することで、どちらの障害からでもリカバリします。それにより、新しいFormsランタイムが作成され、保存されていないデータを再入力できます。保存されていないデータによってデータベースは破損しません。それは、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 |
Oracle Formsでは、リクエストに対応するためにOracle HTTP Serverが必要です。オプションで、これらのリクエストをOracle Web Cacheによってキャッシュできます。その場合、それはロード・バランサとしても機能します。
Oracle Formsは、クライアント上でSun社のJavaプラグイン(JRE)を使用し、Forms Javaクライアントを実行します。
次の表に、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 |
リスナー・サーブレットのログ |
Oracle Formsでは透過的フェイルオーバーは行えません。ランタイム・プロセスが失敗した場合、そのサーバー・プロセスによって処理されているクライアント・プロセスも失敗します。Oracle Formsは、アトミック・データベース・トランザクションを採用しています。アトミック・トランザクションでは、一連のデータ、レコードまたは一連のレコードは、完全に保存されるか、まったく保存されないかのいずれかです。その結果、障害が発生すると、保存されていないデータは、定義済の正確な方法により失われます。そのデータはアプリケーションが再起動したときに、ユーザーによって再入力する必要があります。実行マシンに障害が発生したためにプロセスが失敗すると、ユーザー・ベースにサービスを提供する既存の処理能力の大部分またはすべてが、使用できなくなる場合があります。このシナリオでは、アプリケーション全体が使用できなくなる可能性があります。継続的に使用できるようにするためのオプションとしては、アクティブ/アクティブ構成またはアクティブ/パッシブ構成のいずれかで処理能力に冗長性を持たせることがあります。
管理サーバーは、ノード1のみに単一のオブジェクトとして残ります。可用性の高いセットアップはOracle Portal、Reports、FormsおよびDiscovererではサポートされません。第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」で説明するコールド・フェイルオーバー・クラスタの変換プロセスも、Oracle Portal、Reports、FormsおよびDiscovererではサポートされません。
この項の内容は次のとおりです。
N+1とは、処理能力に冗長性を持たせる手法のことです。その手法は、ハードウェアではグループ単位よりもユニット単位で破損する傾向があるという考えに基づいています。つまり、コンピュータ・ネットワークでは、複数のコンポーネントを同時に失う場合より、1つのコンポーネントを失う場合が多いことを意味します。N+1の原則では、ロードのピーク時にユーザー・ベース全体にサービスを処理するために必要なマシンの台数に加えて、そのセット内で最大の処理能力を有するマシンと同じ処理能力の追加ユニットを設置するようにします。これは、フェイルオーバーがマシン・レベルで行われるため、通常、アクティブ/パッシブ・フェイルオーバーと呼ばれます。
デプロイメント内にユーザー・ベース全体を処理可能なサーバーが6台ある場合に、それらが理想的に構成されていると、それらにはすべて、HTTP Server、JavaランタイムおよびFormsランタイムがインストールされています。どのサーバーも負荷が過剰にならないようにハードウェア(またはソフトウェア)型ロード・バランサがあります。ロード・バランサには、スタンバイというラベルが付いた1台のマシンが認識されます。そのマシンは、そのセット内の残りのマシンの中で最大の処理能力を有するマシンと同じ処理能力を持ち、残りのマシンすべてに対して理想的に構成されていますが、そのマシンにはルーティングされません。アクティブ/パッシブ・シナリオでは、スタンバイ・マシンは稼働している必要はありません。アクティブ/アクティブ・シナリオでは、それはセットのアクティブ部分の場合があり、継続的に余剰の処理能力が確保されます。
ここで、マシンのいずれかに障害が発生したと仮定します。
マシンのいずれかに障害が発生した場合、スタンバイ・マシンがオンラインになり、ロード・バランサでは新しいリクエストをそのマシンにもルーティングし、障害が発生したマシンを無視するように再構成されます(いくつかのハードウェア・ロード・バランサでは、これらの2つの手順が自動的に実行されます)。アクティブ/アクティブ・デプロイメントでスタンバイ・マシンがすでに実行中で、ユーザー・ベースにサービスを処理している場合、クライアント上のブラウザを再起動するために要する時間と同程度に停止時間が短くなる場合があります。アクティブ/パッシブ・デプロイメントでスタンバイ・マシンが実行中ではないときに、起動が必要であるだけでなく、ロード・バランサを手動で再構成する必要もある場合、停止時間はさらに長くなります。
フェイルオーバー処理能力を強化するために、複数のスタンバイ・マシンを使用できます。これは通常、N+Mと呼ばれます。複数のマシンに同時に(またはほぼ同時に)障害が発生する確率はかなり低くなりますが、そのような状況に対処できる必要がある場合、N+M設定が可能でありますが、おそらくその設定が必要になります。
デプロイメント内のすべてのマシンに影響する状況(1箇所にあるマシンがすべて破壊される自然災害など)において冗長性を実現するには、このデプロイメントを地理的に別々の場所に複製できます。
仮想マシンを使用するデータセンターでは、スペア・ハードウェアを使用してスタンバイ・マシンをオンラインにできるので、大変低いコストで実装できます。
環境のクローニングの重要性は、前述の項で説明したシナリオから明白です。1台のマシンの環境に行われたすべての変更は、スタンバイ・マシンも含めて他のすべてのマシンにも適用する必要があります。これにより、特にスペア・マシンが仮想である場合、問題が発生します。仮想マシンのイメージは、他のマシンに行われた変更と同期している必要があります。
Oracle Formsプロセスの障害の詳細は、第14.1.3.1項「Oracle Web CacheおよびOracle HTTP Serverのプロセス障害」を参照してください。
Oracle Formsノードの障害の詳細は、第14.1.3.2項「一般的なコンポーネント・ノード障害」を参照してください。
Oracle Forms WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。
Oracle Formsのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。
この項では、Oracle Discovererに固有の単一インスタンス情報および高可用性の概要について説明します。可用性の高いOracle Discovererデプロイメントを正常に作成するために必要な概要および考慮事項を紹介します。
Discovererをインストールする場合、図14-5に示すように、単一インスタンス内にDiscovererトポロジを作成します。インストール後、Discoverer用に他のタイプのトポロジを構成できます。
図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構成ガイドのOracle BI Discovererの動作に関する説明参照してください。
接続プロトコル
クライアント・ブラウザは、HTTPリクエストをDiscoverer Java EEアプリケーションに送信します。
Discoverer Java EEアプリケーションは、WebLogic Serverデータ・ソースを使用してデータベース・スキーマにアクセスします。
Discoverer Session Server(非Java EEコンポーネント)は、OCIレイヤーを使用してデータ・ソースに接続します。
Discoverer Java EEアプリケーションおよびDiscoverer Session Serverプロセスは、CORBAを使用して通信します。
Discoverer Viewerのパフォーマンスと可用性はOracle Web Cacheを使用して向上できます。Web Cacheをいつ、どのように使用するのかについては、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドの「Oracle Web CacheとのDiscoverer Viewerの使用方法」を参照してください。
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の構成ファイルに関する項を参照してください。
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
は、ドメイン・ディレクトリの名前です。
Discovererのログ・ファイルは、Enterprise Manager Fusion Middleware Controlで検索と表示ができます。
詳細は、Enterprise Manager Fusion Middleware Controlのオンライン・ヘルプを参照してください。
次の表に、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-7は、2つのDiscovererインスタンスで構成されるDiscovererトポロジを示しています。
各管理対象サーバーのDiscoverer Java EEアプリケーションは、1台のプリファレンス・サーバーと通信します。したがって、同じプリファレンスが両方のDiscovererインスタンスに適用されます。Discovererインスタンスは、同じマシン上にも異なるマシン上にも配置できます。
管理サーバーは、ノード1のみに単一のオブジェクトとして残ります。可用性の高いセットアップはOracle Portal、Reports、FormsおよびDiscovererではサポートされません。第12章「Oracle Fusion Middleware高可用性のためのアクティブ/パッシブ・トポロジ」で説明するコールド・フェイルオーバー・クラスタの変換プロセスも、Oracle Portal、Reports、FormsおよびDiscovererではサポートされません。
このトピックの内容は次のとおりです。
クラスタ内のDiscoverer Java EEアプリケーションの障害検出および再起動は、WebLogic Serverによって管理されます。
プリファレンス・サーバーは、シングルトン・プロセスであり、クラスタ全体で1つのインスタンスのみが実行されます。
プリファレンス・サーバーのプロセスが停止した場合、OPMNによって自動的に再開されます。OPMNも停止した場合、管理者はプリファレンス・サーバーを手動で起動するか、プリファレンス・サーバーが構成されている別マシンにプリファレンスのあるファイル(reg_key.dc
とpref.txt
)を移動し、そのマシン上でプリファレンス・サーバーを起動する必要があります。
プリファレンス・サーバーをクラスタ内の別のノードで起動する場合、その新しいプリファレンス・サーバーを認識するようにDiscoverer Java EEアプリケーションを構成する必要があります。
特定のDiscoverer HTTPセッションに関するリクエストを処理しているサーバーまたはマシンが停止した場合、後続のリクエストはクラスタ内の他の管理対象サーバーに転送されます。そのセッション状態は、新しいサーバーでレプリケートできます。このレプリケーションを実現するために必要な情報は、HTTPリクエスト(GET/POST)で入手できます。
注意: リクエストを完了するためには、Discovererではセッション・サーバー(C++プロセス)が使用可能である必要があります。したがって、フェイルオーバーが発生すると、C++プロセスを作成してから必要な状態にする必要があるため、レスポンス時間がわずかに長くなります。 |
Discoverer Java EE Servletは、受信したHTTPリクエストごとにセッション・サーバーのプロセスを作成します。複数のDiscovererインスタンス(管理対象サーバーおよび関連するoracleインスタンス)が1台のマシンに存在していると、すべてのDiscovererインスタンスでC++プロセスを同時に作成する場合があるためにCPUの負荷が非常に高くなることがあります。別のマシン上にDiscovererインスタンスを追加すると、同じマシン上に追加するよりもパフォーマンスが向上します。
どのような構成変更も、クラスタ内の各管理対象サーバーで個別に実装する必要があります。これは、configuration.xml
ファイルをすべての管理対象サーバーにコピーすることにより実現できます。
構成ファイルの場所の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscovererの構成ファイルに関する項を参照してください。
各Discoverer Java EEアプリケーション・インスタンス(管理対象サーバー)は、Discovererコンポーネントを含むOracleインスタンスと関連付けられている必要があります。これらのコンポーネントは、インストール・プロセスの構成段階で作成されます。そのため、WebLogic Server管理コンソールから、管理対象サーバーをクラスタに追加したりDiscoverer Java EEアプリケーションをデプロイすることは、サポートされていません。
クラスタ内で定義されたすべての管理対象サーバーは、Discoverer Java EEアプリケーションのデプロイメントのターゲットとなります。
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
Discoverer Java EEアプリケーションがデータベースにアクセスするためには、各データベースのエントリが、ORACLE_INSTANCE
/config/tnsnames.ora
ファイル内に作成されている必要があります。詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのtnsnames.oraファイルの構成に関する項を参照してください。
Oracle Discovererノードの障害の詳細は、第14.1.3.2項「一般的なコンポーネント・ノード障害」を参照してください。
Oracle Discoverer WebLogic管理対象サーバーの障害の詳細は、第14.1.3.3項「一般的なコンポーネントのWebLogic管理対象サーバーの障害」を参照してください。
Oracle Discovererのデータベース障害の詳細は、第14.1.3.4項「一般的なコンポーネントのデータベースの障害」を参照してください。
この項では、高可用性デプロイメントのためのOracle Portal、Forms、ReportsおよびDiscovererの構成手順について説明します。この項の項目は次のとおりです。
注意: 設定プロセスを開始する前に、リリース・ノートを読んで、インストールとデプロイメントに関して追加の考慮事項がないか確認することを強くお薦めします。 |
注意: これらの項においてリストされるホスト名とポートは、このデプロイメント例を示すために使用しています。実際のデプロイメントを構成するときは、独自のホスト名とポートを指定できます。 |
Oracle Portal、Forms、ReportsおよびDiscovererをインストールする前に、この項で説明する前提条件を確認してください。
Oracle Single Sign-Onを使用している場合、高可用性アイデンティティ管理フレームワークが使用できることが前提になります。Oracle Portal、Forms、ReportsおよびDiscovererでは、シングル・サインオンを使用します。これはOracle Identity Management 10gで入手可能です。
この項では、ネットワーク要件について説明します。
複数のOracle Webサーバー間でリクエストを分散させるには、ロード・バランサが必要です。この外部ロード・バランサには、次の機能が必要です。
仮想サーバー名とポートを構成する機能
プロセス障害を検出する機能
Oracle HTTPおよびHTTPSのためにポート(HTTP、HTTPS)を監視する機能
SSL変換機能(必要な場合)
ロード・バランシング・ルーターを使用する場合、次のものが使用可能になるように構成する必要があります。
ロード・バランサが終着点となる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を検出した場合、無効化ポートが使用可能になります。検出しない場合、すべての無効化リクエストはアクティブなコンピュータにルーティングされます。
注意:
|
要約すると、ロード・バランサには次の構成が必要です。
仮想ホスト | 仮想ポート | サーバー・プール | サーバー | ポート | コメント |
---|---|---|---|---|---|
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 |
外部クライアントからは参照できません。 |
製品が異なると、データベースの使用方法が異なります。次に、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およびワークブックを、レポートのデータとともに格納するためにも使用されます。
共有ディレクトリの要件は、製品ごとに異なります。次の表に、これらの要件を示します。
製品 | 共有ディレクトリ要件 |
---|---|
Oracle Portal |
なし |
Oracle Forms |
必須ではありませんが、Oracle Forms実行可能ファイル用に共有ディレクトリがあると便利です。 |
Oracle Reports |
レポート・キャッシュ |
Oracle Discoverer |
ポートレットのプリファレンス・ストア |
多数のOracle Fusion Middlewareコンポーネントおよびサービスではポートが使用されます。管理者として、これらのサービスに使用されるポート番号を把握してから、同じホスト上の2つのサービスが同じポート番号を使用しないようにすることが重要です。
ポート番号は、インストール時に自動的に割り当てることも手動で割り当てることもできます。
この章で説明する高可用性構成の例のために、次の前提事項について説明します。
次の表に、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 |
シングル・サインオンのリスニング・ポート |
Oracle PortalおよびOracle Discovererをインストールする前に、リポジトリ作成ユーティリティ(RCU)を実行して、これらのアプリケーションが機能するために必要なメタデータを含むリポジトリを作成してからシードします。
注意: Oracle FormsおよびReportsには、メタデータ・リポジトリは必要ありません。 |
リポジトリ作成ユーティリティの最新バージョンを、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』の説明に従ってインストールします。
RCUをインストールしたら、それを使用してデータベースに移入します。次のコマンドを使用してリポジトリ作成ユーティリティを起動します。
UNIXの場合:
rcu
Windowsの場合:
rcu.exe
これらのコマンドは、RCUのORACLE_HOME/bin
ディレクトリにあります。
「リポジトリの作成」画面で、「作成」を選択し、「次へ」をクリックします。
「データベース接続の詳細」画面で、次の値を指定します。
データベース・タイプ: Oracle Database
ホスト名: Oracle RACを使用している場合、Oracle RACノードの1つ(VIP名を使用)を入力します。
ポート: リスナー・ポートを入力します。
サービス名: Oracle Real Application Clustersデータベースのサービス名を入力します。
ユーザー名: sys
と入力します。
パスワード: sys
ユーザーのパスワードを入力します。
ロール: SYSDBA
を選択します。
「前提条件の確認」画面で、前提条件を検証したら「OK」をクリックします。
「コンポーネントの選択」画面で、次の値を指定します。
接頭辞の新規作成: データベース・スキーマに追加する接頭辞を入力します(例: MYS
)。
コンポーネント: Portal and BI > Portal and Discoverer
「次へ」をクリックします。
「前提条件の確認」画面で、前提条件を検証したら「OK」をクリックします。
「スキーマ・パスワード」画面で、各ポータル・スキーマのパスワードを入力するか、すべてのスキーマに同じパスワードを使用します。
「次へ」をクリックします。
「表領域のマップ」画面で「次へ」をクリックし、デフォルトを受け入れます。
「表領域の作成」画面で、「はい」をクリックし、欠落している表領域をRCUで作成できるようにします。
「表領域の作成」画面で、「OK」をクリックし、表領域の作成を承認します。
「サマリー」画面で、「作成」をクリックし、作成プロセスを開始します。
次の手順は、Oracle Portal、Forms、ReportsおよびDiscovererのインストールに適用されます。
Oracle WebLogic Serverのバイナリをインストールするには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
最新バージョンのOracle Fusion Middlewareとともに使用するWebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する説明を参照してください。
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インストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。 |
Oracle Fusion Middleware構成ウィザードを起動するには、次のコマンドを実行します。
ORACLE_HOME/bin/config.sh
注意: 構成を開始する前に、次の環境変数(UNIX)が設定されていないことを確認してください。
|
次の手順を続行します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、すべての前提条件を検証したら、「次へ」をクリックします。
ドメインの作成画面で新しいドメインの作成を選択し、次の値を入力します。
ユーザー名: WebLogicドメインにログインするユーザーの名前です。
ユーザー・パスワード: ドメインのパスワードです。
パスワードの確認: 同じパスワードを再度入力します。
ドメイン名: ドメインの名前です(例: MyDomain
)。
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、必要に応じて、OracleサポートのOracleセキュリティ・アップデートを受け取るためのユーザー名およびパスワードを入力します。
「インストール場所の指定」画面で、次の値を入力します。
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
「次へ」をクリックします。
「コンポーネントの構成」画面で、インストールと構成を行う製品を選択します。
管理コンポーネント - Enterprise Managerも選択されていることを確認します。
クラスタを選択します。
「次へ」をクリックします。
高可用性の実装では、様々なコンポーネントで使用されるポートのすべてを複数のホスト間で同期することは必須ではありませんが、強くお薦めします。使用するポートをファイルに指定することで、自動ポート構成をバイパスできます。
ファイル名を選択してから表示/編集をクリックして、割り当てるポートを含むファイルを作成します。
サンプルの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]
ファイルを保存し、「次へ」をクリックします。
プロキシ詳細の指定画面(Reportsのみ)で、プロキシ・サーバーを使用している場合は、この画面に詳細を入力します。
それ以外の場合は、「次へ」をクリックします。
スキーマの指定画面(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で入力したパスワードを入力します。
「次へ」をクリックします。
ポートレット・スキーマの指定画面(PortalとDiscovererのみ)で、次の値を指定します。
ポートレット・スキーマ名: MYS_PORTLET
ポートレット・スキーマ・パスワード: RCUで入力したパスワードを入力します。
「次へ」をクリックします。
アプリケーション・アイデンティティ・ストアの指定画面で、次の値を指定します。
ホスト名: Oracle Internet Directoryサーバーの名前です(例: myoid.mycompany.com
)。
ポート: Oracle Internet Directoryポートです(例: 389
)。
ユーザー名: cn=orcladmin
パスワード: Oracle Internet Directoryのorcladmin
アカウントのパスワードです。
「サマリー」画面で、「インストール」をクリックし、作成プロセスを開始します。
次のテストを実行して、初期インストールを検証します。
テスト | 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のホーム・ページが開きます。 |
次の手順は、構成する製品に関係なく必要です。
複数のネットワーク・カードが存在するサーバーでは、使用するネットワーク・カードに管理サーバーをバインドすることが重要になります。
そのための手順は次のとおりです。
次のURLを使用して、WebLogicコンソールにログインします。
http://apphost1.mycompany.com:7001/console
「ドメイン構造」メニューで、「環境」、「サーバー」の順に選択します。
「AdminServer (admin)」をクリックします。
「チェンジ・センター」で、「ロックして編集」をクリックします。
使用するネットワーク・カードを参照するDNS名にリスニング・アドレスを設定します。これは一般的にパブリック・サーバー名を指定します。
「保存」をクリックします。
「チェンジ・センター」で「変更のアクティブ化」をクリックします。
DOMAIN_HOME/binディレクトリにあるstopWebLogic.sh
スクリプトを使用して、管理サーバーを停止します。同じDOMAIN_HOME/binディレクトリにあるstartWebLogic.sh
スクリプトを使用して、管理サーバーを起動します。
サイトをロード・バランサで適切に機能させるには、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
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
スクリプトを使用します。
ORACLE_INSTANCE/config/
ディレクトリにsqlnet.ora
というファイルを作成し、そのファイルに次のエントリを追加します。
TCP.CONNECT_TIMEOUT=10
これにより、妥当な長さの時間が経過すると、データベース接続がタイムアウトします。
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ドメイン・ユーザー名およびパスワードと同じです。
サイトの作成
「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。
wc1
コンポーネントをクリックします。
ページの最上部にあるリストから「管理 - サイト」を選択します。
「サイトの作成」を選択します。
次の情報を入力し、サイトを追加します。
フィールド | 値 |
---|---|
ホスト名 |
mysite.mycompany.com |
ポート |
リクエストを受信するロード・バランサ上のポート番号を指定します。たとえば、HTTPリクエストの場合は80、HTTPSリクエストの場合は443です。 ロード・バランサを使用している場合、これはロード・バランサ上のリスニング・ポートです。 |
デフォルト・サイト |
はい |
サイト全体の圧縮 |
はい |
サイト別名 - ホスト名 |
mysite.mycompany.com |
サイト別名 - ポート |
7777 |
サイト別名 - ホスト名 |
mysite.mycompany.com |
サイト別名 - ポート |
80 脚注 1 |
脚注 1 ロード・バランサがリクエストをポート443だけでなくポート80にも送信できる場合に必要です。
その他のデフォルトは変更しないでください。
「発行」を選択します。
「OK」を選択し、各エントリを保存します。
サイトとサーバーとの間におけるマッピングの作成
同じページで、「サイト・サーバー間マッピング」セクションの「作成」を選択します。
次の情報を入力し、サイトを追加します。
フィールド | 値 |
---|---|
ホスト・パターン |
mysite.mycompany.com |
ポート・パターン |
80 |
選択したオリジナル・サーバー |
apphost1.mycompany.com:7778 |
「OK」をクリックしてサイトを保存します。
mysite.mycompany.com:443/80のサイトが、サイトとサーバーとの間におけるマッピングのリストにあることを確認します。
「適用」をクリックして変更を保存します。
セッション・バインディングの有効化
Oracle Web Cacheのセッション・バインディング機能は、ユーザー・セッションを特定のオリジナル・サーバーにバインドし、一定の期間、状態を維持するために使用します。デフォルトのOracle Fusion Middleware中間層で実行されているコンポーネントはほとんどすべてステートレスですが、Oracle Portalにはセッション・バインディングが必要です。
セッション・バインディングを有効化すると、すべてのユーザー・リクエストが特定のOracle Portal中間層に送信されます。その結果、ポータル・キャッシュのキャッシュ・ヒット率が高くなります。
次の手順に従って、セッション・バインディングを有効化します。
ページの上部にある「管理 - セッション構成」を選択します。
ドロップダウン・リストからmysite.mycompany.com:443/80
のサイトを選択します。
「セッション・バインディング」セクションで、「Set-Cookieを使用したCookieに基づくセッション・バインディング」を選択します。
「適用」をクリックして変更を保存します。
Web Cacheパスワードはランダムに生成されますが、後の段階で必要になります。したがって、Web Cacheパスワードをデフォルト値から新しい既知の値に変更することをお薦めします。
デフォルトのパスワードを変更する手順は、次のとおりです。
「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。
wc1
コンポーネントをクリックします。
ページの最上部にあるドロップダウン・リストから「管理 - パスワード」を選択します。
新しい無効化パスワードと管理パスワードを入力してからそれらを確認し、「適用」をクリックします。
前述の変更を行った後、次のコマンドを使用してWeb層コンポーネントを再起動します。
opmnctl stopall opmnctl startall
シングル・サインオン・サーバーから次の手順を実行します。
ORACLE_HOME変数をシングル・サインオン・サーバーのORACLE_HOMEの場所に設定します。
次のパラメータを指定して、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
/tmp/osso.conf
を中間層のホームの場所にコピーします。それは次の場所です。
ORACLE_INSTANCE/config/OHS/ohs1
次のコマンドを使用してAPPHOST1上のOracle HTTP Serverを再起動します。
opmnctl restartproc process-type=OHS
次のURLを使用してシングル・サインオン・サーバーにログインします。
http://login.mycompany.com/pls/orasso
「管理」ページに移動してから、「パートナ・アプリケーション管理」ページに移動します。apphost1.mycompany.com
のエントリを削除します。
セキュリティのために、ドメインに対してWebLogicプラグイン有効化フラグをオンにします。そのためには、次の手順に従ってください。
Oracle Web TierはWebLogic Serverの前面に配置され、Oracle HTTP ServerからOracle WebLogic管理対象サーバーにリクエストをルーティングします。このシナリオでは、Oracle WebLogicプラグインが使用されていることをWebLogicが認識する必要があります。そのための手順は次のとおりです。
管理コンソールにログインします。
「ドメイン構造」ウィンドウで、ドメイン名をクリックします。
「Webアプリケーション」タブをクリックします。
「ロックして編集」をクリックします。
「WebLogicプラグインの有効化」ボックスを選択します。
変更を保存およびアクティブ化します。
管理サーバーを再起動します。
Oracle HTTP Serverは、WebLogicのプロキシとして機能するため、デフォルトでは、特定のCGI環境変数はWebLogicに渡されません。これらには、ホストとポートが含まれます。WebLogicには、内部URLを適切に生成できるように仮想サイト名およびポートを使用していることを指示する必要があります。
次のURLを使用して、管理コンソールにログインします。
http://apphost1.mycompany.com:7001/console
ホーム・ページから「クラスタ」を選択するか、「ドメイン構造
」メニューから「環境」→「クラスタ」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
クラスタ名(cluster_portal
、cluster_forms
、cluster_reports
、cluster_disco
)をクリックします。
「HTTP」を選択し、次の値を入力します。
パラメータ | 値 |
---|---|
フロントエンド・ホスト |
mysite.mycompany.com |
フロントエンドHTTPポート |
80 |
フロントエンドHTTPSポート |
443 |
これにより、WebLogic内で作成されたHTTPS URLはすべて、ロード・バランサ上のポート443または80に送られます。
「チェンジ・センター」ウィンドウで「変更のアクティブ化」をクリックし、変更を保存します。
次の手順を使用して、WLS_PORTAL、WLS_FORMS、WLS_REPORTS、WLS_DISCOの管理対象サーバーを再起動します。
ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブを選択します。
各管理対象サーバーの横にあるボックスを選択します。
「停止」→「ただちに強制停止」を選択します。
「はい」をクリックし、管理対象サーバーを停止します。
管理対象サーバーが停止したら、その管理対象サーバーの横にあるボックスを選択します。
「起動」をクリックします。
「はい」をクリックして管理対象サーバーを起動します。
次の手順は、Oracle Portalの構成にのみ必要です。
次の手順に従って、Oracle Portalリポジトリをリワイヤします。
Oracle Fusion Middleware Enterprise Managerで次のURLを使用してドメインにログインします。
http://apphost1.example.com:7001/em
左側にある「Fusion Middleware」メニューを開きます。
「Portal」メニューを開きます(「Fusion Middleware」メニューの下にあります)。
「Portal」をクリックします。
「Portal」を右クリックして、「設定」、「ワイヤ構成」を選択します。
Portal中間層に次の情報を入力します。
パラメータ | 値 |
---|---|
ホスト |
ロード・バランサのDNS名を入力します。たとえば、mysite.mycompany.comとします。 |
ポート |
ロード・バランサがリスニングするポートを入力します。たとえば、SSLターミネーションまたはSSL有効化サイトの場合は443、HTTPの場合は80です。 |
SSLプロトコル |
SSLターミネーションまたはSSL有効化サイトを使用している場合、これを選択します。 |
Web Cacheについて次の情報を入力します。
パラメータ | 値 |
---|---|
ホスト |
ロード・バランサのDNS名を入力します。たとえば、mysite.mycompany.comとします。 |
無効化ポート |
ロード・バランサで構成されているとおりにPortal無効化ポートを入力します(例: 9401)。 |
無効化ユーザー名 |
Portal無効化に使用されるユーザー名を入力します(例: invalidator)。 |
無効化パスワード |
前述のアカウントのパスワードです。 このパスワードの値が不明な場合、前述のようにEnterprise Managerで変更できます。 |
「適用」をクリックし、リワイヤを開始します。
リワイヤが完了したら、「Portal」メニューのオプションを再度クリックします。
次のようにPortalのURLが表示されていることを確認します。
http://mysite.mycompany.com:80/portal/pls/portal
Parallel Page Engine(PPE Servlet)の目的は、ユーザーによってリクエストされたページを構成することです。これは、ユーザーからページ・リクエストを受信し、ページの各部分すべてを並行してフェッチするように独自の新しいリクエストを実行し、これらの部分を1つのページ・ファイルにアセンブルし、ページ・コンテンツをエンド・ユーザーに送り返す(またはクライアント・ブラウザに送り返す)ことにより行います。
これらの内部リクエストは、組織内部に保持され、HTTPプロトコルを使用してサービスが処理されます。
次の手順は、ロード・バランサを使用している場合にのみ必要です。
次のURLを使用してOracle Fusion Middleware Enterprise Managerにログインします。
http://apphost1.example.com:7001/em
左側にあるオブジェクト・ブラウザから「Fusion Middleware」→「Classic」→「Portal」を選択します。
「Portal」を右クリックして、「設定」→「ページ・エンジン」を選択します。
「拡張プロパティ」セクションで、次の情報を追加します。
パラメータ | 値 |
---|---|
ポートの使用 |
内部ループバックのポート番号を選択します(例: 7777)このポートは、内部リクエスト用にロード・バランサで構成されます。 |
スキームの使用 |
HTTPの値に変更します。 |
「適用」をクリックして設定を保存します。
次のようにOracle WebLogic管理コンソールからWebLogic管理対象サーバーを再起動します。
ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブを選択します。
WLS_PORTAL管理対象サーバーの横にあるボックスを選択します。
「停止」→「ただちに強制停止」を選択します。
「はい」をクリックし、管理対象サーバーを停止します。
管理対象サーバーが停止したら、その管理対象サーバーの横にあるボックスを選択します。
「起動」をクリックします。
「はい」をクリックして管理対象サーバーを起動します。
SSLを使用している場合、Oracle Portalでは、ポータル・スキーマが配置されているデータベースにウォレットが存在している必要があります。このウォレットには、ロード・バランサまたはサイトの証明書が格納されます。ウォレットを作成したら、Oracle Portalにその場所を認識させる必要があります。
注意: この手順は、SSLターミネーションまたはサイトSSLを使用している場合にのみ必要です。 |
データベース・ウォレットの作成
このプロセスを開始する前に、証明書をデータベース・サーバーにコピーします。
この方法は、ブラウザによってわずかに異なります。Firefoxブラウザの場合は次のようになります。
ブラウザを使用してhttps://mysite.mycompany.com
のURLにアクセスします。
Firefox→「プリファレンス」→「拡張」→「暗号化」→「証明書の表示」に移動します。
mysite.mycompany.com
の証明書を選択してから、エクスポートを選択してファイルの名前を指定します。
このファイルをデータベース・サーバーにコピーします。
必要に応じて証明書を保存します。
証明書のコピーを取得したら、各データベース・サーバーでウォレットを作成し、この証明書をデータベース・サーバーからOracle Wallet Managerを使用してインポートします。これは、すべてのOracle RACノードに対して次の手順に従って実行する必要があります。
owmと入力し、Oracle Wallet Managerを起動します。
「ウォレット」→「新規」を選択します。
デフォルトの場所にウォレットを作成しないので、「いいえ」を選択します。
ウォレットのパスワードを入力します(このパスワードは後で必要になるので覚えておいてください)。
ウォレットのタイプを「標準」に設定します。
この時点で証明書を作成するかどうかという質問に対して「いいえ」を選択します。
Oracle Wallet Managerで、「操作」→「信頼できる証明書のインポート」を選択します。
「証明書を含むファイルを選択」を選択して「OK」をクリックします。
前の手順で選択した証明書ファイルを選択し、「インポート」をクリックします。
「ウォレット」および「別名保存」を選択します。
ウォレットの場所を選択します。例:
ORACLE_BASE/admin/DB_NAME/wallet
他のOracle RACデータベース・ノードに対してもこの手順を繰り返します。
すべてのデータベース・ノードで同じディレクトリ・パスを使用する必要があります。
ポータルに対するウォレットの識別
データベース・ウォレット内に証明書を格納したら、次の手順に従ってポータル・リポジトリ内にウォレットの場所を格納します。
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は、ウォレットのパスワードです。
ウォレット・ファイル自体ではなくウォレット・ディレクトリへのパスを使用します。キーワード・ファイルが必要です。
前の項の変更を行った後、Web層コンポーネントを再起動する必要があります。この項では、コンポーネントを再起動する手順について説明します。
Webコンポーネントの再起動
次のコマンドを使用してOracle HTTP Serverを再起動します。
opmnctl stopall opmnctl startall
WLS_Portalの再起動
WebLogic管理コンソールにログインし、次の手順に従って管理対象サーバーのWLS_PORTALを再起動します。
ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブを選択します。
WLS_PORTAL
管理対象サーバーの横にあるボックスを選択します。
「停止」→「ただちに強制停止」を選択します。
「はい」をクリックし、管理対象サーバーを停止します。
管理対象サーバーが停止したら、そのWLS_PORTAL
管理対象サーバーの横にあるボックスを選択します。
「起動」をクリックします。
「はい」をクリックして管理対象サーバーを起動します。
ポータルおよびポートレット・コンポーネントに対して作成される個々のデータ・ソースの初期容量を0に設定することをお薦めします。管理コンソールを使用してこれらのデータ・ソースの初期容量を0に設定してください。
構成を検証するには、次のテストを実行します。
テスト | URL | 結果 |
---|---|---|
ロード・バランサを使用したPortalのテスト |
http://mysite.mycompany.com/portal/pls/portal |
Portalのホーム・ページが開きます。 |
シングル・サインオンのエラーのトラブルシューティング
構成のこの段階でシングル・サインオンのエラー・メッセージがPortalフロント画面に表示された場合、データベースのウォレットが適切に作成されていないか、その正しい場所がOracle Portalに認識されていない可能性があります。
このエラーが表示された場合、データベースのウォレットを作成する手順とその後にポータルで識別する手順を繰り返します。
次の手順は、Oracle Formsの構成にのみ使用します。
アプリケーションで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 mydb.mycompany.com
注意: 前述のtnspingコマンドを発行する前に、TNS_ADMIN環境変数を設定してください。 |
WebLogic管理コンソールにログインし、次の手順に従って管理対象サーバーのWLS_FORMSを再起動します。
ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブを選択します。
WLS_FORMS
管理対象サーバーの横にあるボックスを選択します。
「停止」→「ただちに強制停止」を選択します。
「はい」をクリックし、管理対象サーバーを停止します。
管理対象サーバーの停止後に、WLS_FORMS
管理対象サーバーの横のボックスを選択します。「起動」をクリックします。
「はい」をクリックして管理対象サーバーを起動します。
次の手順は、Oracle Reportsの構成にのみ必要です。
複数のReports Serverインスタンス間で整合性のあるレポート・キューを保持し、レポート・サーバーの障害に対するリジリエンスを持たせるには、高可用性のReal Application Clustersデータベースにレポート・キューを作成します。
レポート・キューを作成するには、SQL*Plusスクリプトのrw_server.sql
をデータベースに対して実行します。
このスクリプトは、次のディレクトリにあります。
ORACLE_HOME/reports/admin/sql
次の手順を実行します。
次のコマンドを使用して、データベース内にレポート・キューを保持するユーザーを作成します。
sql> create user report_queue identified by MYSpassword; sql> grant connect, resource,create view to report_queue;
そのレポート・ユーザーに接続し、次のスクリプトを実行します。
cd ORACLE_HOME/reports/admin/sql
sqlplus reports_queue/MYpasswd@rw_server.sql
Oracle Reportsでは、tnsnames.ora
ファイルのエントリを使用して、データベース接続情報を判別します。次の手順に従って、レポート・キュー・データベースのエントリをこのファイルに配置します。
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データベース接続文字列です。 |
ファイルを保存し、次のコマンドを使用してデータベース接続が適切に構成されていることをテストします。
tnsping myrepq.mycompany.com
注意: tnspingコマンドを使用する前に、TNS_ADMIN環境変数を設定してください。 |
Oracle Reportsのセキュリティは、間接的モデルを使用して実行されます。データベース・レポート・キューを使用するようにレポート・サーバーを構成する前に、次の手順に従ってレポート・キューのパスワードを保持するエントリをWebLogicに作成します。
次のURLを使用してOracle Fusion Middleware Enterprise Managerにログインし、求められたらWebLogic管理者ユーザーおよびパスワードを入力します。
http://apphost1.mycompany.com:7001/em
左側にあるナビゲーション・ツリーで、WebLogicDomainを開き、ドメインの名前(たとえばReportsDomain
)をクリックします。
ReportsDomain概要ページが表示されます。
ページの最上部にあるドロップダウン・メニューから「セキュリティ」→「資格証明」を選択します。
「キーの作成」をクリックします。
次の情報を入力します。
パラメータ | 値 |
---|---|
マップの選択 |
reports |
キー |
queuePassword |
タイプ |
パスワード |
ユーザー名 |
report_queue |
パスワード |
レポート・キュー・アカウントのパスワード |
説明 |
レポート・キュー・アカウントの説明 |
終了したら、「OK」をクリックします。
レポート・キューをデータベースに配置したら、それにアクセスする方法をレポート・サーバーに認識させる必要があります。
そのためには、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>
次のディレクトリにある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>
管理対象サーバーのWLS_REPORTSを再起動するには、WebLogic管理コンソールにログインし、次の手順に従います。
ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブを選択します。
WLS_REPORTS
管理対象サーバーの横にあるボックスを選択します。
「停止」→「ただちに強制停止」を選択します。
「はい」をクリックし、管理対象サーバーを停止します。
管理対象サーバーが停止したら、そのWLS_REPORTS
管理対象サーバーの横にあるボックスを選択します。
「起動」をクリックします。
「はい」をクリックして管理対象サーバーを起動します。
Oracle Discovererの高可用性を構成する場合にのみ、次の手順に従います。
アプリケーションで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 mydb.mycompany.com
注意: tnspingコマンドを発行する前に、TNS_ADMIN環境変数を設定してください。 |
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">
デフォルトでは、Discoverer Viewerは、Oracle Web Cacheを十分に活用するように構成されていません。これを有効にすると、パフォーマンスを大幅に向上させることができます。ただし、この機能を有効にすることが適切でない場合もあります。
Discoverer ViewerをOracle Web Cacheとともに使用可能にする場合とその方法の詳細は、Oracle Fusion Middleware Oracle Business Intelligence Discoverer構成ガイドのDiscoverer ViewerをOracle Web Cacheとともに使用する方法に関する項を参照してください。
デフォルトでは、Discovererはシングル・サインオンで保護されていません。Discoverer PlusおよびViewerを保護するには、次の手順を実行します。
mod_osso.conf
ファイルを編集します。これは、次のディレクトリにあります。
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
ファイルにおいて</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>
前の項の変更を行った後、この項で説明する手順を使用してWeb層コンポーネントを再起動します。
Webコンポーネントの再起動
次のコマンドを使用して、Oracle HTTP Serverを再起動します。
opmnctl stopall opmnctl startall
WLS_DISCOの再起動
WebLogic管理コンソールにログインし、次の手順に従って管理対象サーバーのWLS_DISCOを再起動します。
ホーム・ページから「サーバー」を選択するか、「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブを選択します。
WLS_DISCO
管理対象サーバーの横にあるボックスを選択します。
「停止」→「ただちに強制停止」を選択します。
「はい」をクリックし、管理対象サーバーを停止します。
管理対象サーバーが停止したら、そのWLS_DISCO
管理対象サーバーの横にあるボックスを選択します。
「起動」をクリックします。
「はい」をクリックして管理対象サーバーを起動します。
次の項では、APPHOST2にアプリケーション層をインストールおよび構成する方法について説明します。
第14.6.5.2項「Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアのインストール」
第14.6.5.3項「Oracle Portal、Forms、ReportsおよびDiscovererソフトウェアの構成」
Oracle WebLogic Serverのバイナリをインストールするには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・ガイド』を参照してください。
最新バージョンのOracle Fusion Middlewareとともに使用するWebLogic Serverのバージョンは、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のインストール開始点の概要に関する説明を参照してください。
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インストレーション・プランニング・ガイド』のインストール開始点の概要に関する項を参照してください。 |
次のコマンドを実行してOracle Fusion Middleware構成ウィザードを起動します。
ORACLE_HOME/bin/config.sh
注意: 構成を開始する前に、次の環境変数(UNIX)が設定されていないことを確認してください。
|
次の手順を続行します。
「ようこそ」画面で「次へ」をクリックします。
「前提条件のチェック」画面で、すべての前提条件を検証したら、「次へ」をクリックします。
ドメインの作成画面で「クラスタを開く」を選択し、次の値を入力します。
ホスト名: WebLogic管理サーバーを実行しているホストの名前です(例: APPHOST1.mycompany.com)。
ポート: 管理サーバーのポートです。たとえば、7001とします。
ユーザー名: 管理サーバーの管理者アカウント名です。
User Password: 管理サーバーの管理者アカウント用パスワードです。
「次へ」をクリックします。
セキュリティ・アップデートの指定画面で、必要に応じて、OracleサポートのOracleセキュリティ・アップデートを受け取るためのユーザー名およびパスワードを入力します。
「インストール場所の指定」画面で、次の値を入力します。
WebLogicサーバーの場所: 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
「次へ」をクリックします。
「コンポーネントの構成」画面で、インストールと構成を行う製品を選択します。Oracle Web CacheやOracle HTTP Serverをこのノードに配置する場合、選択されていることを確認します。
注意: これは、APPHOST1で選択したものと同じリストにする必要があります。 |
「次へ」をクリックします。
APPHOST1に使用されたものと同じstaticports.ini
ファイルを選択します。
アプリケーション・アイデンティティ・ストアの指定画面で、次の値を指定します。
ホスト名: Oracle Internet Directoryサーバーの名前です(例: login.myoid.com
)。
ポート: Oracle Internet Directoryポートです(例: 389
)。
ユーザー名: cn=orcladmin
パスワード: Oracle Internet Directoryのorcladmin
アカウントのパスワードです。
「サマリー」画面で、「インストール」をクリックし、作成プロセスを開始します。
次の手順は、構成するコンポーネントに関係なく必要です。
クラスタを開く操作により新しい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 |
サイトをロード・バランサで適切に機能させるには、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>
インストールが最初に作成されると、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 |
次のようにファイルを編集します。
WebLogicHost
やWebLogicPort
で始まる行を削除し、次の行を追加します。
WebLogicCluster apphost1:9001,apphost2:9001
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上で繰り返します。
Web Cacheパスワードはランダムに生成されますが、後の段階で必要になります。したがって、Web Cacheパスワードをデフォルト値から新しい既知の値に変更することをお薦めします。
デフォルトのパスワードを変更する手順は、次のとおりです。
「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。
wc1
コンポーネントをクリックします。
ページの最上部にあるドロップダウン・リストから「管理 - パスワード」を選択します。
新しい無効化パスワードと管理パスワードを入力してからそれらを確認し、「適用」をクリックします。
注意: この手順で使用するパスワードは、APPHOST1で使用するパスワードと同一である必要があります。これは、後の手順でWebキャッシュをまとめてクラスタ化するために必要です。 |
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ドメイン・ユーザー名およびパスワードと同じです。
オリジナル・サーバーの作成
オリジナル・サーバーを作成する手順は次のとおりです。
「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。
wc1
コンポーネントをクリックします(これがAPPHOST1と関連付けられているものであることを確認します)。
ページの最上部にあるドロップダウン・リストから「管理 - オリジナル・サーバー」を選択します。
「作成」をクリックします。
次の情報を入力し、オリジナル・サーバーを追加します。
フィールド | 値 |
---|---|
ホスト |
APPHOST2.mycompany.com |
ポート |
7778 |
許容量 |
100 |
プロトコル |
HTTP |
フェイルオーバーのしきい値 |
5 |
pingのURL |
/ |
pingの間隔 |
10 |
「OK」をクリックして変更を保存します。
「適用」をクリックして変更を保存します。
既存のサイトからサーバーへのマッピングへのオリジナル・サーバーの追加
サイトからサーバーへのマッピングにオリジナル・サーバーを追加する手順は次のとおりです。
「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。
wc1
コンポーネントをクリックします(これがAPPHOST1と関連付けられているものであることを確認します)。
ページの最上部にあるドロップダウン・リストから「管理 - サイト」を選択します。
「サイトからサーバーへのマッピング」セクションで<ホスト:ポート>をクリックします。例:
mysite.mycompany.com:80
「編集」をクリックします。
オリジナル・サーバーのAPPHOST2.mycompany.com:7778
を選択してから、選択したオリジナル・サーバー・リストに移動します。
「OK」をクリックして変更を保存します。
「適用」をクリックして変更を保存します。
APPHOST1およびAPPHOST2におけるWeb Cacheのクラスタ化
APPHOST1およびAPPHOST2上でOracle Web Cacheをクラスタ化する手順は次のとおりです。
注意: Oracle Web Cacheのクラスタリングを適切に機能させるには、まとめてクラスタ化されたWeb Cacheそれぞれの管理パスワードが同一である必要があります。 |
「ナビゲータ」ウィンドウで「Web層」ツリーを開きます。
wc1
コンポーネントをクリックします(これがAPPHOST1と関連付けられているものであることを確認します)。
ページの最上部にあるドロップダウン・リストから「管理 - クラスタ」を選択します。
「追加」をクリックします。
APPHOST2のWeb Cacheが自動的に追加されます。
「適用」をクリックして変更を適用します。
新しく作成されたWeb Cacheエントリをクリックします(エントリのURL部分をクリックしないようにしてください)。
「同期化」をクリックし、構成をAPPHOST2上のWeb Cacheにコピーします。
操作を実行することの確認を求められたら「はい」をクリックします。
「適用」をクリックして新しい構成を適用します。
この項で説明する手順は、高可用性のためのOracle Portalの構成にのみ使用します。
クラスタを開く操作により、新しい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/ |
APPHOST2上に次のディレクトリを作成するとOracle Portal Cacheの記憶域にできます。
ORACLE_INSTANCE/portal/cache ORACLE_INSTANCE/diagnostics/logs/portal
次の2つのコピー・ファイルにおいて、ハードコードされたエントリを編集し、前述のパスを反映するようにします。
portal_cache.conf
ファイルで、PlsqlCacheDirectory
を変更します。
portal_plsql.conf
ファイルで、PlsqlLogDirectory
を変更します。
これらのファイルは、DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTAL1/applications/portal/configurationディレクトリにあります。
各サーバー上で次のコマンドを使用し、APPHOST2上のWeb層コンポーネントを再起動します。
opmnctl stopall opmnctl startall
これで、アプリケーション・ファイルが全体にコピーされました。次の手順で、管理対象サーバーのWLS_PORTAL1を起動します。
次のURLを使用してAPPHOST1上の管理サーバーにログインします。
http://APPHOST1.mycompany.com:7001/console
WebLogic管理コンソールのログイン資格証明を入力します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブを選択します。
管理対象サーバーWLS_PORTAL1の横にあるボックスを選択し、「停止 - ただちに強制停止」をクリックします。
「はい」をクリックして操作を確認します。
これにより、サーバーの状態がリセットされます。
構成を検証する手順は次のとおりです。
テスト | URL | 結果 |
---|---|---|
ロード・バランサを経由したPortalのテスト |
http://mysite.mycompany.com/portal/pls/portal |
Portalのホーム・ページが開きます。 |
ロード・バランサを経由したPortalログインのテスト |
http://mysite.mycompany.com/portal/pls/portal |
orcladminアカウントを使用してログインできる必要があります。 |
この項で説明する手順は、高可用性のためのOracle Formsの構成にのみ使用します。
アプリケーションで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データベース接続文字列です。
クラスタを開く操作により、新しい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 |
前述のファイルをコピーしたら、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
前の項で述べた変更を行った後、次のURLを使用してOracle WebLogic管理コンソールにログインし、WebLogic管理対象サーバーのWLS_FORMSとWLS_FORMS1を再起動します。
http://apphost1.mycompany.com:7001/console
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブを選択します。
WLS_FORMS1サーバーの横にあるボックスを選択します。
「停止」→「ただちに強制停止」を選択します。
確認ダイアログが開いたら、「はい」を選択します。
サーバーを停止したら、WLS_FORMS1サーバーの横にあるボックスを選択して再起動します。
「起動」をクリックします。
構成を検証するには、次のテストを実行します。
テスト | URL | 結果 |
---|---|---|
ロード・バランサのテスト |
http://mysite.mycompany.com/ |
ASのホーム・ページが開きます。 |
Forms |
http://mysite.mycompany.com/forms/frmservlet |
Formsサーブレットのホーム・ページが開きます。 |
この項で説明する手順は、高可用性のためのOracle Reportsの構成にのみ使用します。
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
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>
レポート・キューがデータベースに配置されたら、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>タグに記述されている値です。
クラスタ・ノードのパラメータでは、ローカル・レポート・サーバーを除いてクラスタ内のすべてのレポート・サーバーを(カンマ区切りで)リストする必要があります。
データベース・レポート・キューで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"/>
注意:
|
注意:
|
クラスタ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"/>
注意:
|
注意:
|
次のURLを使用してWebLogic管理コンソールにログインし、Web Logic管理対象サーバーのWLS_REPORTSとWLS_REPORTS1を再起動します。
http://apphost1.mycompany.com:7001/console
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブを選択します。
WLS_REPORTSサーバーとWLS_REPORTS1サーバーの横にあるボックスを選択します。
「停止」→「ただちに強制停止」を選択します。
確認ダイアログが開いたら、「はい」を選択します。
サーバーを停止したら、WLS_REPORTSサーバーとWLS_REPORTS1サーバーの横にあるボックスを選択して再起動します。
「起動」をクリックします。
構成を検証するには、次のテストを実行します。
テスト | URL | 結果 |
---|---|---|
ロード・バランサのテスト |
http://mysite.mycompany.com/ |
ASのホーム・ページが開きます。 |
レポート・キューのテスト |
http://mysite.mycompany.com/reports/rwservlet/showjobs |
「シングル・サインオン」ページおよびレポート・キュー・ページが開きます。 |
ロード・バランシング・ルーター、ファイアウォール、Oracle HTTP ServerおよびWebLogic Serverに対するアイドル接続を管理するタイムアウト設定を、それらのOracle Reportsサービス・アプリケーション要件に従って調整する必要があります。たとえば、ロード・バランシング・ルーターおよびファイアウォール接続タイムアウトが10分に設定されている場合に、レポートの実行時間が10分を超えると、ブラウザ接続は、ロード・バランシング・ルーターによってタイムアウトになり、Oracle Reportsサービスの出力はブラウザに出力されなくなります。Oracle Reportsサービス・クライアントとOracle Reports Serverとの間における接続のタイムアウト値は、Oracle Reportsサービス・サーバー構成ファイルのrwserver.conf
にある接続要素のidleTimeout属性によって制御されます。
この項で説明する手順は、高可用性のためのOracle Discovererの構成にのみ使用します。
アプリケーションで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
クラスタを開く操作により、新しいWebLogic管理対象サーバーおよび関連付けられたマシンが作成されました。ただし、APPHOST1からAPPHOST2にいくつかの構成情報をコピーする必要があります。
この手順を実行する前に、DOMAIN_HOME/config/fmwconfig/servers/WLS_DISCO/applications/discoverer_version/configuration/ディレクトリのconfiguration.xml
ファイルをコピーします。
このファイルをAPPHOST1から、APPHOST2の同じディレクトリにコピーします。
コピーしたconfiguration.xml
ファイルを更新し、次の値をconfiguration.xml.orig
ファイルの値で置換します。
<oracleInstance> <discovererComponentName>
エンタープライズ・デプロイメントでは、一度にアクティブになるDiscovererプリファレンス・ストアは1つのみです。プリファレンス・ストアを変更するには、APPHOST2上のOracle DiscovererがAPPHOST1上のプリファレンス・ストアを指すように変更します。
プリファレンス・ストアのホスト名とポートの識別
この例で指定するプリファレンス・サーバーは、APPHOST1上で実行するように構成されています。サーバーにインストールすると、プリファレンス・サーバーはポートを割り当てられます。次の手順に進む前にこの値を探します。
APPHOST1上で、ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるopmn.xmlファイルを開きます。
ファイルにおいてPREFERENCE_PORTエントリを探します。「value=」は、プリファレンス・サーバーに割り当てられたポートを示します。
他のマシン上のDiscovererプリファレンス・サーバーの指定
プリファレンス・コンポーネント(Discovererプリファレンス・サーバー・マシン)を実行するマシンのホスト名とポート番号を特定したら、他のマシンがDiscovererプリファレンス・サーバー・マシン上のプリファレンス・コンポーネントを使用するように確認する必要があります。
他のマシンのopmn.xml
ファイルを変更してDiscovererプリファレンス・サーバー・マシンを使用するには、インストールの他のすべてのマシンで次の手順を実行します。
プリファレンス・サーバー・マシン以外のすべての各マシンで、テキスト・エディタ(またはXMLエディタ)でopmn.xml
ファイルを開きます。
PREFERENCE_HOST変数を探してから、その値を次のようにDiscovererプリファレンス・サーバー・マシンのホスト名に変更します。
<variable id="PREFERENCE_HOST" value="hostname">
PREFERENCE_PORT変数を探してから、その値を次のようにDiscovererプリファレンス・サーバー・マシンのポート番号に変更します。
<variable id="PREFERENCE_PORT" value="port">
PreferenceServerプロセス・タイプを探してから、次のようにその状態をdisabledに変更します。
<process-type id="PreferenceServer" module-id="Disco_PreferenceServer" working-dir="$DC_LOG_DIR" status="disabled">
opmn.xml
ファイルを保存します。
次のURLを使用してWebLogic管理コンソールにログインし、Web Logic管理対象サーバーのWLS_DISCOおよびWLS_DISCO1を再起動します。
http://apphost1.mycompany.com:7001/console
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「制御」タブを選択します。
WLS_DISCOサーバーとWLS_DISCO1サーバーの横にあるボックスを選択します。
「停止」→「ただちに強制停止」を選択します。
確認ダイアログが開いたら、「はい」を選択します。
サーバーを停止したら、WLS_DISCOサーバーとWLS_DISCO1サーバーの横にあるボックスを選択して再起動します。
「起動」をクリックします。
構成を検証するには、次のテストを使用します。
テスト | URL | 結果 |
---|---|---|
ロード・バランサのテスト |
http://mysite.mycompany.com/ |
ASのホーム・ページが開きます。 |
Discoverer |
http://mysite.mycompany.com /discoverer/viewer |
Discoverer Servletのホーム・ページが開きます。 |
プリファレンス・サーバーをホストしているサーバーに障害が発生した場合、障害が発生していないノードのいずれかで次の手順を使用してプリファレンス・サーバーを起動する必要があります。
プリファレンス・ストアのホスト名とポートの識別
この例で指定するプリファレンス・サーバーは、APPHOST1上で実行するように構成されています。サーバーにインストールすると、プリファレンス・サーバーはポートを割り当てられます。次の手順を使用してこの値を探します。
APPHOST1上で、ORACLE_INSTANCE/config/OPMN/opmnディレクトリにあるopmn.xmlファイルを開きます。
ファイルにおいて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
次の手順を続行します。
「ドメイン構造」メニューから「環境」→「サーバー」を選択します。
「チェンジ・センター」で、「ロックして編集」をクリックします。
WLS_DISCO1サーバーをクリックします。
「構成」タブ、「サーバーの起動」サブタブの順にクリックします。
引数フィールドで、次の行を追加します。
-Doracle.disco.activation.preferencePort=<portno> -Doracle.disco.activation.preferenceHost=<hostname>
ポート番号は、前に定義したPREFERENCE_PORTの値です。
ホスト名は、プリファレンス・サーバーが起動されたホストの名前です(例: APPHOST2)。
ポートレット・プリファレンス・ストアは、コンシューマ登録ハンドルおよびポートレット・プリファレンス・データを永続的に保持するために使用されます。
Discoverer WSRPポートレット・プロデューサでは、ファイルベースのプリファレンス・ストアを使用します。プリファレンス・ストアの場所は、Discovererデプロイメント・プラン(XMLファイル)のdiscoWsrpPrefStoreSharedPath
変数の値で定義されます。discoWsrpPrefStoreSharedPath
変数のデフォルト値は、portletData
です。
デプロイメント・プランおよびその内容の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・プランの内容の理解に関する項を参照してください。
クラスタ環境では、ファイルベースのプリファレンス・ストアに対して、同じWebLogic Server内で動作するすべてのDiscoverer WSRPポートレット・プロデューサは、デプロイメント・プランのdiscoWsrpPrefStoreSharedPath
変数に同じパスを使用する必要があります。そのため、「プリファレンス・ストアの設定」の項で説明されているように、discoWsrpPrefStoreSharedPath
変数の値はデプロイメント・プランの共有パスに変更する必要があります。
discoWsrpPrefStoreSharedPath
変数を変更してプリファレンス・ストアのコンテンツを既存のプリファレンス・ストアから共有パスに移行する場合、「移行ユーティリティを使用したプリファレンス・ストア・コンテンツの転送」の項で説明されているように、移行ユーティリティを実行してプリファレンス・データを移行元パスから移行先パスに転送する必要があります。
プリファレンス・ストアの設定
Discovererのデプロイメント・プランを表示および編集するには、次の手順に従います。
管理コンソールにログインします。
左側のペインで、「デプロイメント」をクリックします。
右側のペインで、デプロイメント・プランを更新するDiscovererアプリケーションを選択します。「Discoverer: 概要」ページが表示されます。
「概要」ページの「デプロイメント・プラン」フィールドには、Discovererアプリケーション・デプロイメント・プラン(XMLファイル)のパスが表示されます。次の手順に示すように、デプロイメント・プランを変更します。
XMLエディタで、「Discoverer: 概要」ページに表示されている場所からデプロイメント・プランを開きます。
variable-definition
セクションへ移動します。
... <variable-definition> <variable> <name>discoWsrpPrefStoreSharedPath</name> <value>portletData</value> </variable> <variable-definition> ...
注意:
|
discoWsrpPrefStoreSharedPath
変数のvalue
を、すべての管理対象サーバーがアクセスできるSharedPath
に変更します。
...
<variable-definition>
<variable>
<name>discoWsrpPrefStoreSharedPath</name>
<value>SharedPath
</value>
</variable>
<variable-definition>
...
注意:
|
変更を保存してXMLファイルを閉じます。
デプロイメント・プランをdiscoWsrpPrefStoreSharedPath
変数の新しい値で更新したら、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプのエンタープライズ・アプリケーションの更新(再デプロイ)に関する項で説明されているように、Discovererアプリケーションを更新する必要があります。
移行ユーティリティを使用したプリファレンス・ストア・コンテンツの転送
WSRPコンテナ・プリファレンス・ストア移行ユーティリティPersistenceMigrationTool
を使用すると、異なるプリファレンス・ストア間で既存のデータを移行できます。
PersistenceMigrationTool
の構文は次のとおりです。
java oracle.portlet.server.containerimpl.PersistenceMigrationTool -sourceType file -destType file -sourcePathdir
-destPathdir
sourceType
は、移行元ストアがファイル内にあることを示します。
destType
は、移行先ストアがファイル内にあることを示します。
注意: Discoverer WSRPプロデューサでは、ファイルベースのプリファレンス・ストアを使用します。そのため、 |
sourcePath
およびdestPath
は、ファイルベースのプリファレンス・ストアの場所です。
注意: このツールを実行して、 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 |
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.5項「APPHOST2におけるアプリケーション層のインストールと構成」の手順に従います。以前のノードに使用したディレクトリ構造と同じものを使用します。