| Oracle® Fusion Middleware Oracle Enterprise Schedulerの管理 12c (12.1.3) E59386-02 |
|
 前 |
 次 |
可用性の高い環境を実現するには、少なくとも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ロード・バランサ。HTTPロード·バランサは、Oracle Enterprise SchedulerのWebサービスへのリクエストを適切に分散するように構成する必要があります。Oracle Enterprise Schedulerには、特定のURLを持つ、次のWebサービスがあります。
ESSWebService
http://essHost:essPort/ess/esswebservice
ESSAsyncCallback Webサービス
http://essHost:essPort/ess-async/essasynccallback
WebServiceJobCallback
http://essHost:essPort/ess-wsjob/async/callback
高可用性アーキテクチャの詳細は、『Oracle Fusion Middleware高可用性ガイド』の「Oracle Fusion Middleware SOA Suiteの高可用性の構成」を参照してください。
エンタープライズ・デプロイメントでは、フロントエンドのhost.portの使用に依存しないように、Oracle Fusion Applicationsのフロントエンドのhost.port設定が削除され、すべてのミドルウェア·コンポーネントにチェックリストが追加されています。このEDG要件を有効にするため、ESSAPPにより、Webサービスのフロントエンドのホストとポートの明示的な設定がサポートされています。
ESSAPPは、次の2つの新しい構成プロパティをサポートしています。
ServerURL
このプロパティの値は、次の形式の文字列です。
http://host:port
これは、実行時にESSWebServiceのエンドポイント・アドレスの決定に使用され、具象WSDLESSWebServiceの一部として公開されます。
CallbackServerURL
このプロパティの値は、次の形式の文字列です。
http://host:port
これは、実行時にOracle Enterprise SchedulerのWebサービスのコールバック(EssAsyncCallbackServiceおよびEssWsJobAsyncCallbackServiceを含む)のエンドポイント・アドレスの決定に使用されます。このエンドポイント・アドレスは、それぞれのWSDLの一部として公開されます。
これらのESSAPPプロパティが構成されていない場合、ESSAPPは、Oracle WebLogic Serverクラスタへの問合せにより、実行時にフロントエンドのホストとポートの設定を参照します。このクラスタのフロントエンドのホストとポートも構成されていない場合は、ローカルのess_serverのホスト名とポートを使用します。
ESSAPPは、そのホームページの下にWebサービスのWSDLのURL(前述の優先順位を使用して計算)を次のように通知します: http://essHost:essPort/ess。
このセクションで説明したESSAPPのServerURLおよびCallbackServerURLプロパティは、Oracle Enterprise SchedulerのHA/Cluster管理者が構成することをお薦めします。「障害検出と再起動」で説明されているクラスタのフロントエンドのホストとポートの構成は、優先順位の低い、第2のプリファレンスとして行うことができます。
Oracle Enterprise SchedulerのWebサービスのエンド・ユーザーは、通知された個々のOracle Enterprise SchedulerのWebサービスのWSDLのURLを検索し、Oracle Enterprise SchedulerのWebサービスへのアクセスに使用することをお薦めします。
2つ以上のOracle Enterprise Schedulerインスタンスを含むOracle Enterprise Schedulerクラスタを設定するには、次のように、WebLogic Server管理コンソールでクラスタのフロントエンドのホストおよびポートを構成する必要があります。
ess_server1_host:port、ess_server2_host:portなど)。HTTPロード・バランサは、ノードに障害が発生した場合にリクエストを再ルーティングするためのロード・バランシング機能を提供します。コンポーネントで永続接続が使用されていれば、ロード・バランサまたはファイアウォールのタイムアウトについて課される要件はありません。同様に、セッション状態複製およびフェイルオーバーも必要ありません。
ロード・バランシングは、Oracle Enterprise SchedulerのWebサービス・インタフェースを使用してジョブを送信し、そのジョブのステータスを問い合せたりするなどの処理で使用されます。ロード・バランシングはジョブの実行される場所に関係なく発生します。
Oracle Enterprise SchedulerではJMSを使用しないため、JMSフェイルオーバーは不要です。ESSクラスタへのリモートEJB呼び出しには、サーバーのアフィニティを有効にする必要があります。このために、weblogic.jndi.enableServerAffinityプロパティをtrueに設定する必要があります。oracle.as.scheduler.request.RemoteConnectorを使用する場合は、サーバーのアフィニティは自動的に設定されます。
この項では、次の項目について説明します。
Oracle Enterprise Schedulerにはリクエスト・プロセッサ・コンポーネントが含まれており、これがOracle Enterprise Schedulerクラスタの1つの管理対象サーバーを表しています。ジョブ実行が1つ以上のリクエスト・プロセッサに接続される形で、ジョブ・リクエストがリクエスト・プロセッサで処理されます。
すべてのジョブが複数のリクエスト・プロセッサにターゲット設定されている場合、ジョブは特定のリクエスト・プロセッサに依存しません。ジョブが特定のリクエスト・プロセッサにターゲット設定されている場合、そのリクエスト・プロセッサに関連付けられているジョブが、管理対象サーバーが使用可能で、そのジョブのアクティブな稼働シフトが存在している場合にかぎって実行されます。
Oracle Enterprise Schedulerは、Oracle Fusion Middlewareのほか、Oracle SOA SuiteやOracle ADFビジネス・コンポーネントなどのコンポーネントと対話します。これらの外部コンポーネントのいずれかに障害が発生した場合、実行中のジョブでエラーが発生する可能性があります。
適切な構成を行うことで、外部コンポーネントの障害がジョブに影響しないようにすることができます。表A-1に、障害が発生する可能性のある外部コンポーネントと、Oracle Enterprise Schedulerジョブでのエラー発生を回避するための手順を示します。
表A-1 Oracle Enterprise Scheduler外部コンポーネントのフェイルオーバー
| 外部コンポーネント | 障害を回避する手順 |
|---|---|
Oracle WebCenter Portal |
ロード・バランサをとおして、Oracle WebCenter Portalサービスのクラスタと統合します。 |
Oracle RACデータベース |
Oracle RACデータベース統合で複数DSを使用します。 |
Oracle SOA Suite、Oracle ADF、その他 |
これらのコンポーネントに依存するジョブに再試行を構成します。 |
一般に、垂直方向(同じマシンに管理対象サーバーを追加)のスケーラビリティよりも、水平方向のスケーラビリティ(別のマシンに管理対象サーバーを追加)のほうがパフォーマンス向上を期待できます。
水平方向のスケーリングには、Oracle WebLogic Serverクラスタの標準のスケーリング手法を使用します。Oracle WebLogic Serverのクラスタ化の詳細は、『Oracle Fusion Middleware高可用性ガイド』の「WebLogic Serverの高可用性」の章を参照してください。作業割当て内のジョブの同時処理を増やすには、リクエスト・プロセッサのスレッド割当てを増やす(リクエスト・プロセッサの稼働シフトを編集する)か、作業割当てを複数のリクエスト・プロセッサにバインドします。詳細は、「稼働シフトの作成または編集」および「作業割当ての作成または編集」を参照してください。
次に、様々なコンポーネントのバックアップおよびリカバリに関するガイドラインを示します。
ファイル・システムに格納されるコンポーネント: 製品バイナリ、デプロイされたアプリケーションEARファイルおよびドメイン・ルート内の標準のOracle WebLogic Serverファイル。
ファイル・システムに対する変更: 新しいEARファイルがデプロイされたとき、または、製品にパッチが適用されたときに発生するファイル・システム・アーティファクト変更。
データベースに保存されているデータ: データベースにはすべてのメタデータおよびランタイム・データが保存されています。
データベース・アーティファクトへの変更: メタデータが作成されOracle JDeveloperまたはFusion Middleware Controlからデプロイされたときに発生するメタデータ変更。ランタイム・データは、ジョブの送信時や状態変更時などに変更されます。
ファイル・システムに保存されているアーティファクトとデータベースに保存されるアーティファクトの整合性についての要件はありません。ファイル・システムにはEARファイルのほか、一時的にスケジュール済ジョブの出力とログ・ファイルも保存されます。
