| Oracle Fusion Middleware Oracle Business Intelligence Publisher管理者および開発者ガイド リリース11g(11.1.1) 部品番号: B63037-01 | 目次 | 前 | 次 |
この章では、次のトピックについて説明します。
11g BI Publisherスケジューラの最新のアーキテクチャでは、Java Messaging Service(JMS)キュー技術を使用しています。このアーキテクチャを使用すると、複数のBI Publisherサーバーをクラスタに追加し、各サーバーを特定の機能(レポート生成、ドキュメント生成、特定の配信チャネル)専用にすることができます。これにより柔軟性が増し、大量のスケジュールされたジョブに対応できるようにパブリッシャをスケールアップすることができます。トピックの内容は次のとおりです。
BI Publisherスケジューラについて
設定に関する考慮事項
BIプラットフォーム・インストーラによって実行されたスケジューラ構成について
プロセッサおよびプロセッサ・スレッドの構成
管理対象サーバーの追加
スケジューラ診断
BI Publisherスケジューラのアーキテクチャでは、JMSキューおよびトピックを使用して、高スケーラブルかつ高性能で強固なレポート・スケジューリングおよび配信システムを提供します。次の図は、スケジューラ・アーキテクチャを示しています。

ジョブの発行時にスケジューラによって実行されるタスクは、次のとおりです。
ジョブの発行
クォーツ・テーブルにジョブ情報とトリガーを格納します
ジョブ・プロセッサ
クォーツ・トリガーが発動したときに、スケジューラ・ジョブ・キューにジョブ情報を配置します
バースティング・エンジン/バッチ・ジョブ・プロセス
バースティング・エンジン・リスナー
キューからスケジュールされたジョブ情報を取得します
データソースからデータを抽出します
定義によりバースティング分割どおりにデータを分割します
一時フォルダにデータを一時的に格納します
レポート・キューにレポート・メタデータを配置します
バッチ・ジョブ・プロセス
キューからスケジュールされたジョブ情報を取得します
データソースからデータを抽出します
一時フォルダにデータを一時的に格納します
レポート・キューにレポート・メタデータを配置します
FOレポート・プロセッサ
レポートQをリスニングします
メタデータに基づいてレポートを生成します
共有された一時ディレクトリにレポートを格納します
配信キューにレポート配信情報を配置します
配信(電子メール、ファイル、FTP)プロセッサ
配信キューをリスニングします
配信APIを呼び出して異なるチャネルに配信します
BI Publisher(BIP)システム・トピック
BIPシステム・トピックは、スケジューリング・エンジンの実行時間のステータスと状態を公開します。このトピックは、すべてのインスタンスのステータス、JMSキュー内のメッセージのスレッド・ステータス、すべてのスケジューラ構成(データベース構成、JMSキューのJNDI構成など)のステータスを公開します。
BI Publisherクラスタリング・サポートを利用すると、要求に応じてサーバー・インスタンスを追加し、処理および配信の負荷に対処することができます。次の図は、Oracle WebLogic Serverのクラスタリングを示しています。レポート・リポジトリとスケジューラ・データベースが複数のインスタンス間で共有されていることに注意してください。また、JNDIサービスを介してJMSキューとトピックを登録することにより、スケジューリングのためのJMSキューおよび診断情報を公開するためのJMSトピックが、サーバー間で共有されていることにも注意してください。

各管理対象サーバー・インスタンスは、同じレポート・リポジトリをポイントします。各管理対象サーバー・インスタンスで、すべてのプロセス(ジョブ・プロセッサ、レポート・プロセッサ、電子メール・プロセッサ、FTPプロセッサ、Faxプロセッサ、ファイル・プロセッサ、印刷プロセッサおよびWeb Davプロセッサ)が構成されます。このため、同じリポジトリをポイントするサーバー・インスタンスがデプロイされるとただちに、クラスタに追加され、このインスタンス内のすべてのプロセッサの実行準備が整います。
任意のサーバー・インスタンスで有効にしたいプロセスを選択することにより、リソースを最適利用することができます。さらに、大量のジョブの処理が要求される場合には、レポート処理用のインスタンスを追加できます。同様に、電子メールの配信が最優先の配信チャネルの場合、インスタンスを追加して、電子メール配信をスケールアップできます。
クラスタリングおよび高可用性の詳細は、Oracle Fusion Middleware高可用性ガイド11gリリース1 (11.1.1)を参照してください。
BI Publisherは強固なフェイルオーバー・メカニズムを備えているので、サーバーを使用できないことが原因でレポートが配信できなくなることはありません。このメカニズムを実現するには、クラスタ内の2つ以上のノードを使用してスケジューラの各プロセスのバランスを調整します。これにより、いずれかのノードで障害が発生しても、2つ目のノードでバックアップされます。たとえば、ジョブ・プロセッサを2つのノードで有効にすることにより、1つのノードで障害が発生しても、2つ目のノードでジョブを処理できます。
重要: 1つのノードが停止しても、他のノードはそのキューへのサービス提供を続行します。ただし、レポート・ジョブが、データ取得、データの書式設定またはレポートの配信のいずれかの実行の段階にある場合、そのジョブは失敗としてマークされ、それを手動で再送信する必要があります。
スケジューラを設定する前に考慮すべきトピックは次のとおりです。
デフォルトでは、BIプラットフォーム・インストーラによりWebLogic JNDI接続URLが構成されます。JDBCは、本番用途には推奨されません。JDBCは、ローカルの低容量テストに対してのみ使用してください。
BI Publisherをインストールすると、WebLogic JMSを使用するようにスケジューラが自動的に構成されます。かわりにActiveMQを使用するようにBI Publisherを構成するには、「ActiveMQ用のBI Publisherの構成」を参照してください。
BIプラットフォーム・インストーラを使用してBI Publisherをインストールし、サーバーを起動した後、BI Publisherスケジューラが実行され、次の構成が行われます。
インストール前の手順としてリポジトリ作成ユーティリティによって、スケジュール・スキーマがデータベースにインストールされます。
JMSが、サーバー内でBI Publisher用に構成されます。
WebLogic JNDI URLが構成されます。
デフォルトでは、1つのプロセッサ当たりのスレッド数が5に設定されています。
Oracle BIプラットフォーム・インストーラによって実行される構成の詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。
この構成は、「スケジューラ構成」ページ(「管理」ページの「システム・メンテナンス」で、「スケジューラ構成」をクリック)で参照できます。次のスクリーンショットは、「スケジューラ構成」ページの「データベース接続」および「JMS構成」リージョンを示しています。

共有ディレクトリは、ジョブの実行中に、スケジューラで使用されるデータやファイルを一時的に保存するのに使用されます。ジョブが完了すると、ジョブの一時データは削除されます。BI Publisherスケジューラが様々なノードやマシンで実行されるように構成されている場合は、このディレクトリを定義する必要があります。このディレクトリは、BI Publisherの全ノードの間でデータやドキュメント情報の交換に使用されるため、すべてのBI Publisherのノードからアクセスできる必要があります。
ディレクトリのサイズは、ジョブ・データの合計サイズ、出力ドキュメントおよび現在のジョブ数に依存します。このディレクトリは、パラレルで実行されるすべてのジョブのすべてのXMLデータおよびドキュメントを格納するのに十分なサイズにする必要があります。このディレクトリが構成されずにBI Publisherが様々なマシンで実行される場合は、スケジューラが失敗する可能性があります。
BI Publisherが単一のマシンで実行される場合は、このディレクトリの設定は任意です。BI Publisherはアプリケーション・サーバーの一時ディレクトリを使用してこのデータを保存します。
設定したクラスタ・インスタンスごとに、プロセッサ構成表が表示されます。この表を使用して、プロセッサの有効化と無効化を行い、プロセッサごとにスレッドを指定します。
各プロセッサに対するデフォルトのスレッド数は、(上図に示す)「JMS構成」の「JMSプロセッサ当たりのスレッド」プロパティによって設定されます。「クラスタ・インスタンス」リージョンで特定のプロセッサのスレッドを編集するには、「スレッド数」設定を更新します。デフォルト設定を使用するプロセッサでは、表内にエントリが表示されないことに注意してください。特定のプロセッサに対してデフォルト値と異なるスレッド数を設定する場合にのみ、「スレッド数」の値を入力します。

1つのプロセッサ当たりの最適なスレッド数は、システムの要件に依存します。「スケジューラ診断」ページを使用して、システムの負荷を評価することができます。「スケジューラ診断」を参照してください。
システムに管理対象サーバーを追加するには、「管理対象サーバーの追加」を参照してください。
Oracle WebLogic管理コンソールで管理対象サーバーを追加して、BI Publisherの「管理」ページでクラスタ・インスタンスを構成します。
Oracle WebLogic管理コンソールの使用方法の詳細は、Oracle WebLogic Server管理コンソールのヘルプシステムを参照してください。Fusion Middleware Controlおよびその使用方法の詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。
次の方法のいずれかを使用してOracle WebLogic管理コンソールにアクセスします。
「ロックして編集」をクリックします。
「ドメイン構造」で、「環境」を開いて、「サーバー」をクリックします。

「サーバー」表で、「新規」をクリックします。
「 新しいサーバーの作成: サーバーのプロパティ 」ページで、次の手順を実行します。

「 名前 」フィールドに、サーバーの名前を入力します。
「リスニング・ポート」で、サーバー・インスタンスにアクセスするポート番号を入力します。
「はい、このサーバーを既存のクラスタのメンバーにします。」を選択します。
リストからbi_clusterを選択します。
「次」をクリックします。
選択した構成オプションを確認します。
「終了」をクリックします。
「サーバー」表に新しいサーバーが表示されます。

サーバー名をクリックして、「設定」ページを開きます。

新しいサーバーに対して「マシン」を選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
新しいサーバーを起動します。
新しい管理対象サーバーが起動されると、次の図に示すように、そのサーバーに対するプロセッサのセットがBI Publisherに表示されます。

これで、システムの負荷に合せてスレッドを構成できるようになりました。
「スケジューラ診断」ページはスケジューラの実行時のステータスを提供します。また、そのJMS構成、JMSキュー、クラスタ・インスタンス・ステータス、スケジューラ・データベース・ステータス、Toplinkステータスおよびスケジューラ(クォーツ)ステータスを提供します。
診断ページには、JMSキューが受け取ったスケジュール済のレポート要求の数、その内の失敗した要求の数およびまだ実行されている要求の数が表示されます。JMSステータスはクラスタインスタンス・レベルで表示できます。これにより、インスタンスを追加して、これらの1つ以上のJMSプロセッサによってスケールアップするかどうかを決定できるようになります。
たとえば、キューに待機している電子メール・プロセッサに対する要求数が1つのインスタンスでは多すぎる場合、電子メールの処理に対処できるようにするためにもう1つのインスタンスを追加することを検討できます。同様に、非常に多くのレポートが処理中になっており、レポート・プロセス・キューで実行中ステータスで表示されている場合、もう1つのインスタンスを追加してレポート・プロセス機能をスケールアップできます。
また、「スケジューラ診断」ページには各コンポーネントのステータスが反映され、ダウンしたコンポーネントがあるかどうかが示されます。データベースへの接続文字列またはJNDI名、どのクラスタ・インスタンスがどの管理対象サーバー・インスタンスに関連付けられているか、Toplink接続プール構成などを確認できます。
あるインスタンスが、失敗したステータスを示している場合、そのインスタンスを復元できます。クラスタにはJMSのフェイルオーバー・メカニズムが設定されているので、発行されたジョブが失われることはありません。サーバー・インスタンスが復元されると、ただちにサービス用のクラスタで使用可能になります。インスタンスの削除と追加は、診断ページに動的に反映されます。
クラスタにインスタンスを追加すると、「スケジューラ診断」ページではただちにその新しいインスタンスが認識され、新しいインスタンスのステータスとそのインスタンス上で実行されているすべてのスレッドが表示されます。これは、管理者に強力な監視機能を提供し、いずれかのインスタンスまたはスケジューラのコンポーネントで問題が発生した場合にその問題を追跡して解決することができます。
「スケジューラ診断」ページには、次のコンポーネントに関する情報が表示されます。
JMS
クラスタ
データベース
スケジューラ・エンジン

「JMS」セクションは、次に項目に関する情報を提供します。
JMSクラスタ構成: このセクションは、JMS設定の構成情報を提供します。
プロバイダ・タイプ(Weblogic / ActiveMQ)
Weblogicバージョン
Weblogic JNDIファクトリ
JMS用のJNDI URL
キュー名
一時ディレクトリ
JMSランタイム: これは、すべてのJMSキューとトピックの実行時ステータスを提供します。

「クラスタ」セクションは、クラスタ・インスタンスに関する詳細情報を提供します。この情報を使用して、各プロセッサの負荷を把握します。

JMSインスタンス構成
JMS Wrapper
JMS Client – System - BIP Systemトピックのステータスを提供します。「スケジューラ診断」ページは、このトピックに対するサブスクライバです。
JMS Client_producer - このリリースでは使用されません。
JMS Client_schedule - ジョブ・プロセッサとレポート・プロセッサのステータス、アクティブなスレッド数を示す各プロセッサ、受信したメッセージ数、失敗したメッセージ数および実行中のメッセージ数を提供します。
JMS Client_delivery - リスナーとしての様々な配信プロセッサのステータス、アクティブなスレッド数を示す各配信プロセッサ、受信したメッセージ数、失敗したメッセージ数および実行中のメッセージ数を提供します。
「データベース」セクションは、次の項目に関する情報を提供します。
データベース構成 - 接続タイプ、JNDI名、または接続文字列
Toplink構成 - 接続プーリング、ロギング・レベル
データベース・スキーマ

「Quartz」セクションでは、次の項目に関する情報を提供します。
Quartz構成
Quartz初期化

![]()
Copyright © 2010, 2011, Oracle and/or its affiliates. All rights reserved.