ヘッダーをスキップ

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 Publisherスケジューラのアーキテクチャでは、JMSキューおよびトピックを使用して、高スケーラブルかつ高性能で強固なレポート・スケジューリングおよび配信システムを提供します。次の図は、スケジューラ・アーキテクチャを示しています。

この図についてはドキュメントのテキストで説明しています

ジョブの発行時にスケジューラによって実行されるタスクは、次のとおりです。

  1. ジョブの発行

  2. ジョブ・プロセッサ

  3. バースティング・エンジン/バッチ・ジョブ・プロセス

  4. FOレポート・プロセッサ

  5. 配信(電子メール、ファイル、FTP)プロセッサ

クラスタリングについて

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つのノードが停止しても、他のノードはそのキューへのサービス提供を続行します。ただし、レポート・ジョブが、データ取得、データの書式設定またはレポートの配信のいずれかの実行の段階にある場合、そのジョブは失敗としてマークされ、それを手動で再送信する必要があります。

設定に関する考慮事項

スケジューラを設定する前に考慮すべきトピックは次のとおりです。

JNDIまたはJDBC接続の選択

デフォルトでは、BIプラットフォーム・インストーラによりWebLogic JNDI接続URLが構成されます。JDBCは、本番用途には推奨されません。JDBCは、ローカルの低容量テストに対してのみ使用してください。

サポートされているJMSプロバイダ

BI Publisherをインストールすると、WebLogic JMSを使用するようにスケジューラが自動的に構成されます。かわりにActiveMQを使用するようにBI Publisherを構成するには、「ActiveMQ用のBI Publisherの構成」を参照してください。

スケジューラの構成について

BIプラットフォーム・インストーラを使用してBI Publisherをインストールし、サーバーを起動した後、BI Publisherスケジューラが実行され、次の構成が行われます。

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

  1. 次の方法のいずれかを使用してOracle WebLogic管理コンソールにアクセスします。

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

  3. ドメイン構造」で、「環境」を開いて、「サーバー」をクリックします。

    この図についてはドキュメントのテキストで説明しています

  4. サーバー」表で、「新規」をクリックします。

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

    この図についてはドキュメントのテキストで説明しています

  6. 選択した構成オプションを確認します。

  7. 終了」をクリックします。

  8. サーバー」表に新しいサーバーが表示されます。

    この図についてはドキュメントのテキストで説明しています

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

    この図についてはドキュメントのテキストで説明しています

  10. 新しいサーバーに対して「マシン」を選択します。

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

  12. 変更のアクティブ化」をクリックします。

  13. 新しいサーバーを起動します。

BI Publisherでのプロセッサの構成

新しい管理対象サーバーが起動されると、次の図に示すように、そのサーバーに対するプロセッサのセットがBI Publisherに表示されます。

この図についてはドキュメントのテキストで説明しています

これで、システムの負荷に合せてスレッドを構成できるようになりました。

スケジューラ診断

「スケジューラ診断」ページはスケジューラの実行時のステータスを提供します。また、そのJMS構成、JMSキュー、クラスタ・インスタンス・ステータス、スケジューラ・データベース・ステータス、Toplinkステータスおよびスケジューラ(クォーツ)ステータスを提供します。

診断ページには、JMSキューが受け取ったスケジュール済のレポート要求の数、その内の失敗した要求の数およびまだ実行されている要求の数が表示されます。JMSステータスはクラスタインスタンス・レベルで表示できます。これにより、インスタンスを追加して、これらの1つ以上のJMSプロセッサによってスケールアップするかどうかを決定できるようになります。

たとえば、キューに待機している電子メール・プロセッサに対する要求数が1つのインスタンスでは多すぎる場合、電子メールの処理に対処できるようにするためにもう1つのインスタンスを追加することを検討できます。同様に、非常に多くのレポートが処理中になっており、レポート・プロセス・キューで実行中ステータスで表示されている場合、もう1つのインスタンスを追加してレポート・プロセス機能をスケールアップできます。

また、「スケジューラ診断」ページには各コンポーネントのステータスが反映され、ダウンしたコンポーネントがあるかどうかが示されます。データベースへの接続文字列またはJNDI名、どのクラスタ・インスタンスがどの管理対象サーバー・インスタンスに関連付けられているか、Toplink接続プール構成などを確認できます。

あるインスタンスが、失敗したステータスを示している場合、そのインスタンスを復元できます。クラスタにはJMSのフェイルオーバー・メカニズムが設定されているので、発行されたジョブが失われることはありません。サーバー・インスタンスが復元されると、ただちにサービス用のクラスタで使用可能になります。インスタンスの削除と追加は、診断ページに動的に反映されます。

クラスタにインスタンスを追加すると、「スケジューラ診断」ページではただちにその新しいインスタンスが認識され、新しいインスタンスのステータスとそのインスタンス上で実行されているすべてのスレッドが表示されます。これは、管理者に強力な監視機能を提供し、いずれかのインスタンスまたはスケジューラのコンポーネントで問題が発生した場合にその問題を追跡して解決することができます。

「スケジューラ診断」ページには、次のコンポーネントに関する情報が表示されます。

この図についてはドキュメントのテキストで説明しています

JMS」セクションは、次に項目に関する情報を提供します。

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

この図についてはドキュメントのテキストで説明しています

データベース」セクションは、次の項目に関する情報を提供します。

この図についてはドキュメントのテキストで説明しています

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

この図についてはドキュメントのテキストで説明しています