| Oracle® Fusion Middleware Oracle Enterprise Scheduler管理者ガイド 11g リリース1 (11.1.1.7) B66432-04 |
|
 前 |
 次 |
この章では、可用性の高いOracle Enterprise Scheduler環境の構成および管理方法について説明します。
この付録では次の項について説明します。
ジョブのパフォーマンスを最適化するため、可用性の高いOracle Enterprise Schedulerサーバー・クラスタを使用することをお薦めします。これは特に、完了時にステータス・メッセージを返す必要のある、リモートでの非同期ジョブ実行で有用です。
たとえば、非同期ADFビジネス・コンポーネント・ジョブをリモートで実行するとします。Oracle Enterprise Schedulerでは、ジョブの完了時にWebサービス・コールバックをとおしてステータスがジョブから返されることが必要です。Oracle Enterprise Schedulerが1つのノードでしか実行されていない場合、そのノードがダウンした場合にコールバック・メッセージが到達せず、ジョブのステータスが不明になります。そのため、手動の操作介入を行って、ジョブに完了のステータスを付ける必要があります。
2ノード・クラスタの場合は、一方のサーバーがダウンしている場合でもすべてのコールバックが処理され、宛先に到達します。クラスタ化されたOracle Enterprise Scheduler環境では、コールバックが適切に配信され、ジョブの完了時には自動的に正しいステータスが付与されます。
次に、可用性の高いOracle Enterprise Scheduler環境を構成するための主な手順を示します。
構成ウィザードを使用してドメインを設定し、クラスタを構成します。
クラスタに必要に応じてノードを追加しスケーラビリティを高め、ジョブの処理能力を増やします。
クラスタ・ノードを追加するときに、場合によっては、新しいノードのプロセッサ構成を調整して適切な作業割当てを割り当てる必要があります。
詳細は、Oracle WebLogic Serverのマニュアルを参照してください。
ロード・バランサを構成します。詳細は、Oracle HTTP Serverのマニュアルを参照してください。
Oracle Enterprise Schedulerのアーキテクチャやそのコンポーネントおよびライフ・サイクルなどの概念を理解しておくと、Oracle Enterprise Scheduler環境を構成するときの参考になります。
この項には次のトピックが含まれます:
Oracle Enterprise SchedulerはOracle WebLogic Serverインスタンスにインストールされ、そこで実行されます。Oracle Enterprise Schedulerのサービス・コンポーネントはOracle JRFの上に配置され、Oracle Web Services Managerによって保護されます。Oracle Enterprise Schedulerはスケジュール済ジョブの送信とジョブ定義を管理します。
図A-1に、Oracle Fusion Middlewareコンポーネントのコンテキストにおける、Oracle Enterprise Schedulerのランタイム・アーキテクチャを示します。
次に、Oracle Enterprise Schedulerランタイム・アーキテクチャのコンポーネントを示します。
Oracle Enterprise Schedulerクライアント・アプリケーション: 様々なアプリケーションがスケジュール済ジョブの実行をリクエストできます。Oracle Fusionアプリケーション、SOAやOracle ADFビジネス・コンポーネントなどのWebサービス・クライアント、およびPL/SQLアプリケーションなどのアプリケーションが含まれます。
Oracle Enterprise Scheduler: Fusion Middleware Controlを使用してOracle Enterprise Schedulerクラスタ、サービスおよびジョブを管理できます。Oracle Enterprise SchedulerはMDSを使用してメタデータにアクセスします。スケジュール済ジョブの出力は、Oracle WebCenter Contentに保存されます。Oracle Enterprise Schedulerに含まれているインタフェースとAPIによって、アプリケーションおよび外部コンポーネントとの対話が可能になります。たとえば、PL/SQLクライアントはOracle Enterprise SchedulerのPL/SQL APIを使用してスケジュール済ジョブをリクエストします。
Oracle Enterprise Schedulerによってアクセスされるコンポーネント: Oracle Enterprise Schedulerでは、SOAコンポーネント、Oracle ADFビジネス・コンポーネント・サービスおよびOracle Business Intelligence PublisherにアクセスするJavaジョブの作成がサポートされています(各コンポーネント専用のジョブは直接的にはサポートされません)。
EJBにアクセスするクライアント・アプリケーションはRMI経由でOracle Enterprise Schedulerにアクセスし、Oracle Enterprise Scheduler Webサービスを使用するクライアント・アプリケーションはHTTPを使用します。クライアント・アプリケーションからサーバーへの接続は、永続的で存続時間の短い非同期対話であり、コールバック機能が使用されることもあります。
次に、Oracle Enterprise Schedulerコンポーネントを示します。
Oracle ADFサーバー(Oracle Enterprise Schedulerクライアント): RuntimeServiceEJBとMetadataServiceEJBが共有ライブラリとしてデプロイされます。これらのライブラリはADFクライアント・アプリケーション(ears)にインポートされます。
Oracle Enterprise Schedulerサーバー(Oracle Enterprise Schedulerランタイム): Oracle Enterprise Schedulerサービス・コンポーネントはすべてのスケジュール済ジョブを管理します。
コア・ランタイム: JCAリソース・アダプタ、複数のEJBコンポーネントおよびJRF Webサービス・モジュール(WARファイル)が含まれているOracle Enterprise SchedulerアプリケーションのEARファイルです。
ホスティング・アプリケーション: ホスティング・アプリケーションは、ESSEndpointMDB、RuntimeServiceEJBおよびMetadataServiceEJB共有ライブラリをインポートするEARファイルです。Oracle Enterprise Schedulerのホスティング・アプリケーションは、Oracle Enterprise Schedulerライブラリまたは統合ジョブ・リクエスト送信インタフェースを使用してジョブ・リクエストを送信します。
Oracle Database Scheduler: Oracle Enterprise SchedulerのPL/SQLジョブは、標準のOracle Database Schedulerを使用して実行されます。
Oracle Enterprise SchedulerはJavaプロセスAPIを使用して、ネイティブ・バイナリ・ジョブを生成します。
Oracle Enterprise Schedulerは次のデータ・ソースに依存しています。
Oracle Enterprise Schedulerランタイム(XA)
Oracle Enterprise Schedulerランタイム(非XA)
Oracle Enterprise Schedulerメタデータ・ストア(非XA)
XAトランザクションは、一般的には複数のリソースを生成するグローバル・トランザクションを指します。非XAトランザクションは常に1つのリソースに関与し、通常グローバル・トランザクションには参加できません。
ジョブの実装に含まれるコンポーネントによって異なりますが、外部依存性には、ランタイム・データベース、MDSリポジトリ、Oracle SOA Suite、Oracle ADFビジネス・コンポーネント、Oracle BIプレゼンテーション・サービス、Oracle WebCenter Contentなどが含まれます。
Oracle Enterprise Schedulerのエンジンは、Oracle WebLogic Serverによって初期化される標準J2EEアプリケーションの一部として起動されます。Oracle Enterprise Scheduler JCAアダプタはランタイム・スキーマに接続し、スケジュール済作業項目のポーリングを行います。
次に、クライアント・リクエストがOracle Enterprise Schedulerで実行されるときの過程を示します。
クライアント・アプリケーションがジョブ・リクエストを送信します。
クライアント・アプリケーションがOracle Enterprise Schedulerにジョブ・リクエストを送信します。
Oracle Enterprise Schedulerがジョブ・リクエストのメタデータを読み取ります。
Oracle Enterprise Schedulerが、ジョブ・リクエストおよびジョブ・メタデータをOracle Enterprise Schedulerランタイム・データ・ストア内のキューに置きます。
スケジュールとリクエスト・プロセッサの使用可能状況に基づいて、Oracle Enterprise Schedulerがメッセージをホスト・アプリケーションに送信します。このメッセージには、ジョブの送信時に捕捉したすべてのジョブ・リクエスト・パラメータとメタデータが含まれています。
ホスティング・アプリケーションがジョブを実行し、ステータスを返します。ジョブ出力およびログがOracle WebCenter Contentに書き込まれます。
Oracle Enterprise Schedulerによって、ジョブ・リクエストのステータスで履歴が更新されます。
図A-2に、実行されたジョブ・リクエストがそのライフ・サイクルを終えるまでにたどる状態変化を示します。
図A-3は、実行ユーザーがリクエストを取り消したときに、実行可能ジョブ・リクエストに起こる状態変化を示しています。
図A-4に、スケジュール付きのジョブ・リクエストが送信されたときの状態遷移を示します。
Oracle Enterprise SchedulerはOracle WebLogic Serverインスタンス上で実行されるため、Oracle Enterprise SchedulerはOracle Fusion MiddlewareのSOA用ノード・マネージャを使用して管理できます。
Oracle Enterprise Schedulerジョブは同じOracle WebLogic Serverインスタンス(またはリモートOracle WebLogic Serverインスタンス)、データベースおよびバイナリ・プロセスにホストできます。Oracle Enterprise SchedulerはOracle Enterprise Schedulerジョブのライフ・サイクルを管理します。Oracle Enterprise Managerを使用して、Oracle Enterprise Schedulerジョブを監視および管理します。Oracle Enterprise Schedulerジョブの管理の詳細は、第4章を参照してください。
Oracle Fusion Middlewareノード・マネージャの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』の「ノード・マネージャの使用」の章を参照してください。
可用性の高い環境を実現するには、少なくとも2つのノードで構成されるクラスタでOracle Enterprise Schedulerを実行することをお薦めします。
この項には次のトピックが含まれます:
構成ファイルは次のとおりです。
ess.xml: このファイルはOracle Enterprise SchedulerクラスタにデプロイされるOracle Enterprise SchedulerのEARファイルの一部です。
MDSリポジトリ: Oracle Metadataリポジトリには、Oracle Enterprise Schedulerのジョブ・メタデータが格納されます。Oracle Enterprise Schedulerでは、データベースとファイルベースのMDSリポジトリの両方がサポートされます。
次に、デプロイメント・アーティファクトを示します。
コア・ランタイムおよびホスティング・アプリケーションのJ2EEアプリケーション
コア・ランタイムおよび起動時にロードされるジョブに使用される、Oracle MDS内のジョブ・メタデータ
Oracle WebLogic Serverデプロイメントは非ステージングです。
Oracle Enterprise Schedulerクラスタでは、標準のOracle WebLogic Serverロギングを使用します。Oracle WebCenter Contentのログを使用してOracle Enterprise Schedulerの動作を調査します。Oracle Enterprise Schedulerロギングは、デフォルトでOracle WebLogic Server内に構成されます。
Oracle Enterprise Schedulerプロセス・ジョブのログ・ファイルのデフォルトの場所は、UNIXサーバーの場合は/tmp/ess/requestFileDirectoryです。Oracle Enterprise Schedulerの動作ログ・ファイルの場所は、Windowsの場合は、<DOMAIN_HOME>/servers/<SERVER_HOME>/logs/<server name>-diagnostic.logおよび<MW_HOME>\user_projects\domains\<DOMAIN_HOME>\servers\<SERVER_HOME>\logs\<server name>-diagnostic.logです。
図A-5は、2つのノードを使用したOracle Enterprise Schedulerクラスタのアーキテクチャ図です。
この構成には次のコンポーネントが含まれています。
ハードウェア・ロード・バランサ。
2つのサーバーで実行されるOracle WebLogic Serverクラスタ。
2つのサーバーで実行されるOracle Fusion Middlewareホーム。
Oracle Enterprise Schedulerインスタンスの2ノード・クラスタ(各インスタンスが異なるOracle Fusion Middlewareインスタンスで実行される)。
ランタイムおよびMDSスキーマの可用性確保のため、複数DS構成のOracle RACデータベース・クラスタを使用します。複数DSおよびOracle RACはデータベース障害に備えるためのものです。
共有永続ストレージ。
メタデータ・ストア。
Webサービス対話用のHTTPロード・バランサ。
高可用性アーキテクチャの詳細は、『Oracle Fusion Middleware高可用性ガイド』の「Oracle Fusion Middleware SOA Suiteの高可用性の構成」を参照してください。
HTTPロード・バランサは、ノードに障害が発生した場合にリクエストを再ルーティングするためのロード・バランシング機能を提供します。コンポーネントで永続接続が使用されていれば、ロード・バランサまたはファイアウォールのタイムアウトについて課される要件はありません。同様に、セッション状態複製およびフェイルオーバーも必要ありません。
ロード・バランシングは、Oracle Enterprise SchedulerのWebサービス・インタフェースを使用してジョブを送信し、そのジョブのステータスを問い合せたりするなどの処理で使用されます。ロード・バランシングはジョブの実行される場所に関係なく発生します。
Oracle Enterprise SchedulerではJMSを使用しないため、JMSフェイルオーバーは不要です。Oracle Enterprise Schedulerは、ステートフル・セッションBeanのかわりに、ステートレス・セッションBeanとJCA RARファイルを使用します。そのため、EJBステート・フェイルオーバーは不要です。
この項には次のトピックが含まれます:
Oracle Enterprise Schedulerにはリクエスト・プロセッサ・コンポーネントが含まれており、これがOracle Enterprise Schedulerクラスタの1つの管理対象サーバーを表しています。ジョブ実行が1つ以上のリクエスト・プロセッサに接続される形で、ジョブ・リクエストがリクエスト・プロセッサで処理されます。
すべてのジョブが複数のリクエスト・プロセッサにターゲット設定されている場合、ジョブは特定のリクエスト・プロセッサに依存しません。ジョブが特定のリクエスト・プロセッサにターゲット設定されている場合、そのリクエスト・プロセッサに関連付けられているジョブが、管理対象サーバーが使用可能で、そのジョブのアクティブな稼働シフトが存在している場合にかぎって実行されます。
Oracle Enterprise Schedulerは、Oracle Fusion Middlewareのほか、Oracle SOA SuiteやOracle ADFビジネス・コンポーネントなどのコンポーネントと対話します。これらの外部コンポーネントのいずれかに障害が発生した場合、実行中のジョブでエラーが発生する可能性があります。
適切な構成を行うことで、外部コンポーネントの障害がジョブに影響しないようにすることができます。表A-1に、障害が発生する可能性のある外部コンポーネントと、Oracle Enterprise Schedulerジョブでのエラー発生を回避するための手順を示します。
一般に、垂直方向(同じマシンに管理対象サーバーを追加)のスケーラビリティよりも、水平方向のスケーラビリティ(別のマシンに管理対象サーバーを追加)のほうがパフォーマンス向上を期待できます。
水平方向のスケーリングには、Oracle WebLogic Serverクラスタの標準のスケーリング手法を使用します。Oracle WebLogic Serverのクラスタ化の詳細は、『Oracle Fusion Middleware高可用性ガイド』の「WebLogic Serverの高可用性」の章を参照してください。作業割当て内のジョブの同時処理を増やすには、リクエスト・プロセッサのスレッド割当てを増やす(リクエスト・プロセッサの稼働シフトを編集する)か、作業割当てを複数のリクエスト・プロセッサにバインドします。詳細は、第5.3.2.1項および第5.3.1.1項を参照してください。
次に、様々なコンポーネントのバックアップおよびリカバリに関するガイドラインを示します。
ファイル・システムに格納されるコンポーネント: 製品バイナリ、デプロイされたアプリケーションEARファイルおよびドメイン・ルート内の標準のOracle WebLogic Serverファイル。
ファイル・システムに対する変更: 新しいEARファイルがデプロイされたとき、または、製品にパッチが適用されたときに発生するファイル・システム・アーティファクト変更。
データベースに保存されているデータ: データベースにはすべてのメタデータおよびランタイム・データが保存されています。
データベース・アーティファクトへの変更: メタデータが作成されOracle JDeveloperまたはFusion Middleware Controlからデプロイされたときに発生するメタデータ変更。ランタイム・データは、ジョブの送信時や状態変更時などに変更されます。
ファイル・システムに保存されているアーティファクトとデータベースに保存されるアーティファクトの整合性についての要件はありません。ファイル・システムにはEARファイルのほか、一時的にスケジュール済ジョブの出力とログ・ファイルも保存されます。
オラクル社のベスト・プラクティスに従い、ハードウェア・ロード・バランサを使用して2つ以上のOracle HTTPサーバー間で負荷分散を行い、次にクラスタ内のOracle WebLogic Server管理対象サーバー間で負荷分散を行います。
Oracle Enterprise Schedulerクラスタの管理には、クラスタの起動、クラスタ全体への構成変更の伝播、アプリケーションのデプロイおよび想定外の動作への対応が含まれます。
この項には次のトピックが含まれます:
Oracle Enterprise Schedulerは標準J2EEコンポーネントを使用しています。そのため、起動手順はOracle WebLogic Serverによって決定されます。Oracle Enterprise Schedulerでは負荷の急上昇を回避するためスロットルを実装できます。
クラスタを停止すると、Oracle Enterprise Schedulerとその他のすべてのローカルJavaジョブが終了します。また、Oracle Enterprise Schedulerは、すべてのローカル・バイナリ・ジョブの停止も試みます。ただし、SOAやPL/SQLジョブなどの非同期ジョブは継続されます。SOAまたはOracle ADFビジネス・コンポーネント・サービスからの非同期コールバックは、Oracle Enterprise Schedulerクラスタ全体がダウンしている場合は届きません。
突然停止された場合、サーバーは継続中のトランザクションのリカバリを試みます。
構成には、コンテナつまりサーバーの構成と、ジョブ・メタデータの構成の2種類があります。ジョブ・メタデータはOracle Metadata Repositoryに格納されます。サーバーは標準のOracle WebLogic Serverを構成する場合と同じプロセスで、Oracle WebLogic Server構成フレームワークで維持されるプラットフォーム構成の一部として構成されます。ジョブ・メタデータ構成の変更はOracle JDeveloperからデプロイされます。
クラスタ・レベルでは、いかなる構成変更もEARファイルまたはメタデータのデプロイによって伝播されます。構成データはデータベースまたはEARファイルに保存されます。ess-config.xmlなど、EARファイル内の構成ファイルは、Fusion Middleware ControlのMBeanブラウザを使用して変更できます。
クラスタ・メンバーは独立していて、データベースのみを共有します。クラスタのメンバー間での通信はありません。
アプリケーションは、標準のOracle WebLogic Server EARファイルを使用して、標準のJ2EE定義Oracle WebLogic Serverメカニズムを使用してクラスタにデプロイされます。EARファイルをデプロイするときにサーバーを再起動する必要はありません。
アプリケーション・デプロイメントにはEARファイルが含まれ、これにJAZNおよびMARファイルが含まれています。JAZNファイルには、スケジュール済ジョブに対するアクセス権限が格納されており、Oracle Authorization Policy Managerの管理下でLDAPに保存されます。MARファイルにはメタデータが含まれており、MDSに保存されます。Oracle WebLogic Serverは、アプリケーションEARファイルをクラスタ内のすべての管理対象サーバーにデプロイします。
障害が発生してもジョブの処理を確実に継続させる方法としては、Oracle Enterprise Schedulerクラスタを構成する方法が一般的です。サーバーに障害が発生すると、クラスタ内の別のノードが、障害が発生したサーバーで実行されているすべてのジョブの状態を、該当する状態に遷移させます。たとえば、同期ジョブがエラーで終了した場合、再試行が構成されていればジョブの再試行が実行されます。
データ層の高可用性を確立するには、Oracle RACを使用します。
この項には次のトピックが含まれます:
非同期ジョブの再試行とタイム・アウトを構成できます。ジョブの再試行とタイムアウトの構成の詳細は、第4.2.1.1項を参照してください。
障害検出とリカバリを可能にするため、Oracle Enterprise Schedulerの各クラスタ・ノードは、データベース内のレコードを1分おきに更新します。これをハートビートと呼びます。ハートビートは他のノードによって監視され、レコードが一定の時間変更されなかった場合、そのサーバーは障害が発生しているものと見なされます。サーバー障害が検出されたときに、そのサーバー上で実行されている各ジョブが処理されます。同期ジョブはエラーありの完了としてマーキングされ、非同期ジョブはリモートで実行が継続されます。再試行が構成されている場合、エラーありの完了としてマーキングされたジョブは再実行されます。障害検出には10分程度の時間がかかります。
障害検出時に、ノードの出力とログ・ファイルは別のノードからアクセスできる状態にある必要があります。そのため、ジョブ出力とログ・ファイルを格納するファイル・ディレクトリは共有ファイル・システム上に置いておく必要があります。このディレクトリはess-config.xmlファイルにリストされています。
Oracle JTAの移行は、Oracle Enterprise Schedulerでは必要ありません。
Oracle Enterprise SchedulerはOracle Java Message Service (JMS)を使用しないため、JMSリカバリは不要です。
