| Oracle® Fusion Middleware Oracle Business Intelligence Publisher管理者ガイド リリース11g (11.1.1) B66709-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Publisher管理者ガイド リリース11g (11.1.1) B66709-03 |
|
前 |
次 |
この章では、BI Publisherスケジューラの機能、アーキテクチャ、診断および構成について説明します。
内容は次のとおりです。
11g BI Publisherスケジューラの最新のアーキテクチャでは、Java Messaging Service(JMS)キュー技術を使用しています。このアーキテクチャを使用して、複数のBI Publisherサーバーをクラスタに追加してから各サーバーを特定の機能専用のサーバーに指定することができます(レポート生成、ドキュメント生成、特定の配信チャンネルなど)。
BI Publisherスケジューラのアーキテクチャでは、JMSキューおよびトピックを使用して、高スケーラブルかつ高性能で強固なレポート・スケジューリングおよび配信システムを提供します。図7-1に、スケジューラのアーキテクチャを示します。
ジョブの発行時にスケジューラによって実行されるタスクは、次のとおりです。
ジョブの発行
クォーツ・テーブルにジョブ情報とトリガーを格納します
ジョブ・プロセッサ
クォーツ・トリガーが発動したときに、スケジューラ・ジョブ・キューにジョブ情報を配置します
バースティング・エンジン/バッチ・ジョブ・プロセス
バースティング・エンジン・リスナー
キューからスケジュールされたジョブ情報を取得します
データソースからデータを抽出します
バースティング分割の定義に従ってデータを分割します
一時フォルダにデータを一時的に格納します
レポート・キューにレポート・メタデータを配置します
バッチ・ジョブ・プロセス
キューからスケジュールされたジョブ情報を取得します
データソースからデータを抽出します
一時フォルダにデータを一時的に格納します
レポート・キューにレポート・メタデータを配置します
FOレポート・プロセッサ
レポートQをリスニングします
メタデータに基づいてレポートを生成します
共有された一時ディレクトリにレポートを格納します
配信キューにレポート配信情報を配置します
配信(電子メール、ファイル、FTP)プロセッサ
配信キューをリスニングします
配信APIを呼び出して異なるチャネルに配信します
BI Publisher(BIP)システム・トピック
BIPシステム・トピックは、スケジューリング・エンジンの実行時間のステータスと状態を公開します。このトピックは、すべてのインスタンスのステータス、JMSキュー内のメッセージのスレッド・ステータス、すべてのスケジューラ構成(データベース構成、JMSキューのJNDI構成など)のステータスを公開します。
BI Publisherクラスタリング・サポートを使用すると、サーバー・インスタンスをオンデマンドで追加して、処理と配信の負荷に対応することができます。図7-2に、Oracle WebLogic Serverのクラスタリングを示します。レポート・リポジトリとスケジューラ・データベースが複数のインスタンスで共有されることにに注意してください。また、スケジューリング用のJMSキューと診断情報公開用のJMSトピックは、JMSキューとJMSトピックをJNDIサービス経由で登録することにより、サーバー全体で共有されます。
各管理対象サーバー・インスタンスは、同じレポート・リポジトリをポイントします。管理対象サーバー・インスタンスごとに、すべてのプロセス(ジョブ・プロセッサ、レポート・プロセッサ、電子メール・プロセッサ、FTPプロセッサ、FAXプロセッサ、ファイル・プロセッサ、印刷プロセッサおよびWebDavプロセッサ)が構成されます。このため、同じリポジトリをポイントするサーバー・インスタンスがデプロイされるとただちに、クラスタに追加され、このインスタンス内のすべてのプロセッサの実行準備が整います。
有効にするプロセスを任意のサーバー・インスタンスで選択できるので、リソースを最適に使用することができます。さらに、大量のジョブの処理が要求される場合には、レポート処理用のインスタンスを追加できます。同様に、電子メールの配信が最優先の配信チャネルの場合、インスタンスを追加して、電子メール配信をスケールアップできます。
クラスタリングと高可用性の詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。
BI Publisherは強固なフェイルオーバー・メカニズムを備えているので、サーバーを使用できないことが原因でレポートが配信できなくなることはありません。これを実現するには、クラスタ内の2つ以上のノードを使用してスケジューラの各プロセスのバランスを調整します。これにより、いずれかのノードで障害が発生しても、2つ目のノードでバックアップされるため、データが失われることはありません。たとえば、ジョブ・プロセッサを2つのノードで有効にすることにより、1つのノードで障害が発生しても、2つ目のノードでジョブを処理できます。
|
重要: 1つのノードが停止した場合、他のノードがそのキューへのサービス提供を続行します。ただし、レポート・ジョブが、データ取得、データの書式設定またはレポートの配信のいずれかの実行の段階にある場合は、そのジョブは失敗としてマークされるため、手動で再発行する必要があります。 |
スケジューラを設定する前に考慮する必要のあるトピックは、次のとおりです。
デフォルトでは、BIプラットフォーム・インストーラによりWebLogic JNDI接続URLが構成されます。JDBCは、本番用途にはお薦めされません。JDBCは、ローカルの低容量テストに対してのみ使用してください。
BI Publisherをインストールすると、WebLogic JMSを使用するようにスケジューラが自動的に構成されます。かわりにActiveMQを使用するようにBI Publisherを構成するには、第B.2項「ActiveMQ用のBI Publisherの構成」を参照してください。
BIプラットフォーム・インストーラを使用してBI Publisherをインストールし、サーバーを起動すると、BI Publisherスケジューラが実行され、次の構成が行われます。
インストール前の手順として、リポジトリ作成ユーティリティによってスケジューラ・スキーマがデータベースにインストールされます。
JMSが、サーバー内でBI Publisher用に構成されます。
WebLogic JNDI URLが構成されます。
デフォルトでは、1つのプロセッサ当たりのスレッド数が5に設定されています。
Oracle BIプラットフォーム・インストーラによって実行される構成の詳細は、『Oracle Fusion Middleware Oracle Business Intelligenceインストレーション・ガイド』を参照してください。
この構成は、「スケジューラ構成」ページ(「管理」ページの「システム・メンテナンス」で、「スケジューラ構成」をクリック)で参照できます。図7-3は、「スケジューラ構成」ページの「データベース接続」および「JMS構成」リージョンを示しています。
共有ディレクトリは、ジョブの実行中にスケジューラで使用されるデータやファイルを一時的に保存する目的で使用されます。ジョブが完了すると、ジョブの一時データは削除されます。BI Publisherスケジューラが様々なノードやマシンで実行されるように構成されている場合は、このディレクトリを定義する必要があります。このディレクトリは、BI Publisherの全ノードの間でデータやドキュメント情報の交換に使用されるため、すべてのBI Publisherのノードからアクセスできる必要があります。ディレクトリのサイズは、ジョブ・データの合計サイズ、出力ドキュメントおよび現在のジョブ数に依存します。このディレクトリは、パラレルで実行されるすべてのジョブのすべてのXMLデータおよびドキュメントを格納するのに十分なサイズにする必要があります。このディレクトリが構成されずにBI Publisherが様々なマシンで実行される場合は、スケジューラが失敗する可能性があります。
BI Publisherが単一のマシンで実行される場合は、共有ディレクトリの設定は任意です。BI Publisherはアプリケーション・サーバーの一時ディレクトリを使用してこのデータを保存します。
構成したクラスタ・インスタンスごとに、プロセッサ構成表が表示されます。この表を使用して、プロセッサの有効化と無効化を行い、プロセッサごとにスレッドを指定します。
各プロセッサのデフォルトのスレッド数は、図7-3に示すように、「JMS構成」の「JMSプロセッサ当たりのスレッド」プロパティで設定されます。「クラスタ・インスタンス」リージョンで特定のプロセッサのスレッド数を編集するには、図7-4に示すように、「スレッド数」の設定を更新します。デフォルト設定を使用するプロセッサの場合は、表にエントリが表示されないことに注意してください。特定のプロセッサに対してデフォルト値と異なるスレッド数を設定する場合にのみ、「スレッド数」の値を入力します。
プロセッサ当たりの最適なスレッド数は、システムの要件によって異なります。「スケジューラ診断」ページを使用して、システムの負荷を評価できます。第7.6項「スケジューラ診断」を参照してください。
システムに管理対象サーバーを追加するには、第7.5項「管理対象サーバーの追加」を参照してください。
Oracle WebLogic管理コンソールで管理対象サーバーを追加して、BI Publisherの「管理」ページでクラスタ・インスタンスを構成します。
Oracle WebLogic管理コンソールの使用の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。Fusion Middleware Controlおよびその使用方法の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
管理対象サーバーを追加する手順は次のとおりです。
次の方法のいずれかを使用してOracle WebLogic管理コンソールにアクセスします。
「ロックして編集」をクリックします。
「ドメイン構造」で、「環境」を開いて、「サーバー」をクリックします。
「サーバー」表で、「新規」をクリックします。
「新しいサーバーの作成: サーバーのプロパティ」ページで、次の手順を実行します。
「名前」フィールドに、サーバーの名前を入力します。
「リスニング・ポート」で、サーバー・インスタンスにアクセスするポート番号を入力します。
「はい、このサーバーを既存のクラスタのメンバーにします。」を選択します。
リストからbi_clusterを選択します。
「次へ」をクリックします。
選択した構成オプションを確認します。
「終了」をクリックします。
図7-5に示すように、「サーバー」表に新しいサーバーが表示されます。
サーバー名をクリックして、「設定」ページを開きます。
新しいサーバーに対して「マシン」を選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
新しいサーバーを起動します。
新しい管理対象サーバーが起動されると、図7-6に示すように、そのサーバーのプロセッサのセットが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ランタイム: 図7-7に示すように、すべてのJMSキューとJMSトピックの実行時ステータスを提供します。
「クラスタ」セクションは、図7-8に示すように、クラスタ・インスタンスに関する詳細情報を提供します。この情報を使用して、各プロセッサの負荷を把握します。
JMSインスタンス構成
JMS Wrapper
JMS Client – System - BIPのSystemトピックのステータスを提供します。「スケジューラ診断」ページは、このトピックに対するサブスクライバです。
JMS Client_producer: このリリースでは使用されません。
JMS Client_schedule: ジョブ・プロセッサとレポート・プロセッサのステータスを示します。プロセッサごとに、アクティブなスレッド数、受信したメッセージ数、失敗したメッセージ数および実行中のメッセージ数が表示されます。
JMS Client_delivery: リスナーとしての様々な配信プロセッサのステータスを示します。配信プロセッサごとに、アクティブなスレッド数、受信したメッセージ数、失敗したメッセージ数および実行中のメッセージ数が表示されます。
「データベース」セクションは、図7-9に示すように、次のコンポーネントに関する情報を提供します。
データベース構成: 接続タイプ、JNDI名、または接続文字列
Toplink構成: 接続プーリング、ロギング・レベル
データベース・スキーマ
Quartzセクションは、図7-10に示すように、次のコンポーネントに関する情報を提供します。
Quartz構成
Quartz初期化
「スケジューラ診断」ページでよく見られるQuartz構成のエラーを次に示します。
エラーの説明と解決
BI Publisherの起動中(WebLogic管理対象サーバーまたは管理サーバーの起動時)に、jdbc/bip_datasourceとして構成されたJNDIデータソースが使用できない場合、Quartzの初期化が失敗します。「スケジューラ診断」ページには、Quartz構成のエラーが表示されます。
これが発生した場合は、次の手順を実行します。
jdbc/bip_datasourceとして構成されているデータソースが使用可能かどうかを確認します。「スケジューラ構成」ページで、「接続のテスト」をクリックして接続が機能していることを確認します。
「スケジューラ診断」ページで診断項目「データベース・スキーマ」を探し、診断に合格していることを確認します。
「スケジューラ構成」ページに戻り、「スケジューラ選択」をQuartzから「なし」に変更して「適用」をクリックします。ここで、設定をQuartzに戻し、もう一度「適用」をクリックします。
「スケジューラ診断」で、Quartzエラーが消去されていることを確認します。
