| Oracle® Fusion Middleware Oracle Enterprise Schedulerの管理 12c (12.1.3) E59386-02 |
|
 前 |
 次 |
Oracle Enterprise Schedulerは単一のインスタンスまたはサーバーのクラスタとして実行できます。各Oracle Enterprise Schedulerサーバーには、必ず構成する必要があるリクエスト・プロセッサとディスパッチャが含まれています。
次に、Oracle Enterprise Schedulerを構成するための主な手順を示します。
クラスタを構成します。オプションで、Oracle Enterprise Schedulerサーバーのクラスタを構成します。
リクエスト・プロセッサを構成します。ジョブ・リクエストを受信および管理するOracle Enterprise Schedulerコンポーネントを構成します。
リクエスト・ディスパッチャを構成します。リクエスト・プロセッサに対してジョブ・リクエストのポーリングを行い、ジョブをディスパッチするOracle Enterprise Schedulerコンポーネントを構成します。
この項では、次の項目について説明します。
Oracle Enterprise SchedulerクラスタはWebLogicドメインの作成時に作成されます。このクラスタを拡張してより大きな負荷に対応できるようにできます。Oracle WebLogic Serverコンソールから、新しいクラスタ・ノードをOracle Enterprise Schedulerクラスタに追加できます。
管理対象サーバーを追加してOracle Enterprise Schedulerクラスタをスケール・アウトした場合、追加したサーバーでデフォルトの作業割当てを使用して、すぐにリクエスト処理を開始するのは望ましくない場合があります。これは、その他のすべてのサーバーに作業割当てが標準モードでバインドされている場合です。しかし、1つ以上の実行中サーバーがデフォルトの作業割当てを使用している場合、現在の作業割当ては、デフォルトの作業割当てを使用するサーバーと互換性を持ちます。
既存のクラスタに新規の管理対象サーバーを追加した場合、追加したサーバーでデフォルトの作業割当てを使用して、すぐにリクエスト処理を開始するのは望ましくない場合があります。これは、その他のすべてのサーバーに作業割当てが標準モードでバインドされている場合です。実行中サーバーの少なくとも1つがデフォルトの作業割当てを使用しているなら、現在の作業割当てが、デフォルトの作業割当てを使用しているサーバーと適合していることを意味します。
Oracle Enterprise Schedulerには新規サーバーに対する保護機能があるため、ユーザーはサーバーがジョブの処理を開始する前に作業割当てを実行できます。新規に作成されたサーバーを初めて起動すると、Oracle Enterprise Schedulerは、デフォルトの作業割当てを使用すると問題があるかどうかを決定し、問題がある場合は、ヘルス・チェック・ジョブが含まれている事前シードの内部作業割当て(ESSInternalWA)をバインドします。ユーザーはヘルス・チェック・ジョブを使用してサーバーを調査し、必要に応じて、内部作業割当てをアンバインドして自身で作成した作業割当てをバインドできます。
デフォルトの作業割当てを使用できるかどうかを判断する際、Oracle Enterprise Schedulerは、グループ内のすべての実行中サーバーを考慮し、そのサーバーにどんなアプリケーションがデプロイされているかは関係ないことに注意してください。ダウンしているサーバーは考慮されません。
作業割当ての詳細は、「作業割当ての管理」を参照してください。
Oracle WebLogic Serverコンソールを使用したクラスタの拡張の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプを参照してください。
リクエスト・プロセッサに作業割当てがバインドされていない場合は、デフォルトの作業割当てでジョブ・リクエストが処理されます。作業割当てのバインディングは、どのようなジョブを、いつ、どのようなリソースで実行するかを制御します。バインディングには、標準(デフォルト)と排他的の2つのモードがあります。
標準バインディング・モードでは、アクティブな稼働シフトが定義されている場合に、リクエスト・プロセッサが特殊化ルールで定義されているとおりにジョブ・リクエストを処理できます。ジョブ・リクエストが2つの異なる作業割当てに特殊化されている場合、いずれか一方の作業割当てまたはデフォルトの作業割当てでそのジョブ・リクエストを処理できます。
排他的バインディング・モードを使用している場合、その作業割当てに特殊化されているジョブ・リクエストは、その作業割当てがアクティブであればその作業割当てによって排他的に処理されます。これらのジョブ・リクエストは、デフォルトの作業割当てを含む、その他すべての作業割当てから除外されます。作業割当てにアクティブな稼働シフトがない場合、そのジョブ・リクエストは他の作業割当てで処理できます。
例として、次の作業割当てを考えてみます。
LongWAの特殊化は、(definition = 'JobDefinition://mypackage/LongRunningJob')
SamWAの特殊化は、(definition = 'JobDefinition://mypackage/LongRunningJob' AND user = 'sam')
LongWAおよびSamWAの両方とも、標準モードでバインドされているものとします。SamがLongRunningJobを発行すると、LongWAまたはSamWAのいずれかが、そのリクエストを処理できます。
LongWAが標準モードでバインドされ、SamWAは排他モードでバインドされているものとします。SamがLongRunningJobを発行すると、SamWAのみが、そのリクエストを処理できます。排他バインディングは、次のように機能するようにLongWAを特殊化します。
(definition = 'JobDefinition://mypackage/LongRunningJob') AND NOT (definition 'JobDefinition://mypackage/LongRunningJob' AND user = 'sam')
これは実質的には次と同じです。
(definition = 'JobDefinition://mypackage/LongRunningJob') AND NOT (user = 'sam')
注意:
特殊化がオーバーラップする場合、排他的バインド・モードの使用には注意してください。たとえば、LongWAおよびSamWAの両方を排他モードでバインドすると、SamWAはLongRunningJobをまったく実行できません。この場合、SamWAの特殊化は次のようになります。
(definition = 'JobDefinition://mypackage/LongRunningJob' AND user = 'sam') AND NOT (definition = 'JobDefinition://mypackage/LongRunningJob')
作業割当てのバインドの要件は次のとおりです。
作業割当てが有効になっている必要があります。つまり、アクティブ・フラグが設定されている必要があります。
作業割当てには少なくとも1つの稼働シフトが必要です。
作業割当て内の各稼働シフトには、少なくとも1つのスレッド割当てが必要です。
稼働シフトにスケジュールが含まれている場合、次を満たしている必要があります。
スケジュールはアクティブである必要があります。つまり、失効していない必要があります。
稼働シフトの期間が少なくとも1である必要があります。
作業割当てを特定のサーバーにバインドできるのは最大で1回です。
作業割当てはグループ内の任意の数のサーバーにバインドできますが、すべて同じモードでバインドする必要があります。グループ内のあるサーバーに作業割当てを標準モードでバインドし、他のサーバーに作業割当てを排他的モードでバインドすることはできません。
作業割当ての詳細は、「作業割当ての管理」を参照してください。
リクエスト・プロセッサを構成するには:
「リクエスト・ディスパッチャの構成」ページを使用して、ジョブ・リクエスト・ディスパッチャを有効または無効にします。リクエスト・ディスパッチャのポーリング間隔も構成できます。
Oracle Enterprise Schedulerリポジトリに対してディスパッチャが実行準備の整ったリクエストをポーリングするまで、リクエストは待機の状態のままです。リポジトリへのポーリング後、ディスパッチャはすべてのリクエストを準備完了に設定します。準備完了状態になった後、ジョブ・リクエストの管理はリクエスト・プロセッサに引き継がれます。
デフォルトの最大ポーリング間隔は15秒です。
リクエスト・ディスパッチャを構成するには:
