| Oracle® Fusion Middleware Oracle Enterprise Schedulerの管理 12c (12.2.1) E72705-01 |
|
 前 |
 次 |
この章では、Oracle Enterprise Schedulerを実行するインフラストラクチャの作成および構成方法について説明します。Oracle Enterprise Schedulerは、スケジューリング・サービスの提供先となるアプリケーションとともにインストールされます。ただし、Oracle Enterprise Schedulerを使用する前に、インフラストラクチャの構成が必要になることがあります。
この章の内容は次のとおりです。
Oracle Enterprise Schedulerを組み込むことで製品のジョブ・スケジューリング・サービスを提供する製品の場合、その製品によってOracle Enterprise Schedulerがインストールされます。ただし、ドメインの作成時にOracle Enterprise Schedulerのデプロイを明示的に選択することや、サービスを最大限利用するためOracle Enterprise Schedulerの側面を構成することが必要になる場合があります。
必要になる場合がある基本的な管理タスクには次のものがあります。
Oracle Enterprise SchedulerをインストールしてOracle Enterprise Schedulerコンポーネントを含めるドメインを作成します。
クラスタ、リクエスト・プロセッサおよびリクエスト・ディスパッチャを構成して、Oracle Enterprise Schedulerを構成します。クラスタはオプションですが(Oracle Enterprise Schedulerはシングル・ノードで実行できます)、Oracle Enterprise Schedulerを機能させるためにはプロセッサとディスパッチャは必須です。
サービス・インスタンス、そのリクエスト・プロセッサまたはリクエスト・ディスパッチャを起動および停止します。
アプリケーションおよびロール・ポリシーの管理またはWebサービスを提供します。
Oracle Enterprise Schedulerには独自のインストーラはありませんが、Oracle SOA Suiteなどのそれを組み込む製品のインストーラによりインストールされます。詳細は、組込み製品のインストール・ドキュメントを参照してください。
IDEは、組込み製品の設計時インストーラによってインストールされます(たとえば、Oracle SOA Suiteの設計時インストーラ)。このインストーラによりIDEがインストールされ、自動的にOracle JDeveloperのために構成されます。JDeveloperを実行する前に、必ず変数MW_HOMEをIDEが必要とするミドルウェア・ホームの場所に設定します。
Oracle Enterprise Schedulerのランタイム・コンポーネントは、組込み製品(たとえば、Oracle SOA suite)の設計時または製品インストーラによってインストールされます。組込み製品により自動的にOracle Enterprise Schedulerがデプロイされますが、デプロイされない場合は、「Oracle Enterprise Scheduler Service Basic」テンプレートを使用して、サーバーまたはクラスタにデプロイできます。「Oracle Enterprise Manager Fusion Middleware Control Plugin for ESS」テンプレートがデプロイされ、Oracle Enterprise Manager Fusion Middleware ControlでOracle Enterprise Schedulerの機能を有効にするように選択されます。
Oracle Enterprise Schedulerが自動的に組込み製品のターゲットとして設定されていない場合は、ドメインの作成時にOracle Enterprise Schedulerの基本テンプレートを選択する必要があります。デフォルトでは、Oracle Enterprise Schedulerは、ess_server1と呼ばれるデフォルトのサーバーをターゲットとします。異なるサーバー(たとえば、SOAサーバー)をターゲットにするには、次の手順を使用します。
Oracle Enterprise SchedulerでSOAを拡張する場合、ess-server1が作成され、デフォルトでESS-MGD-SVRSサーバー・グループがess_server1をターゲットとします。Oracle Enterprise Schedulerのターゲットをsoa_server1にするには、次の手順を使用します。
soa_server1のESS-MGD-SVRSを選択します。
ess-server1のESS-MGD-SVRSの選択を解除します。
ess_server1を削除します。
OWSM-PMは、ドメイン内の1つのサーバーのターゲットとなることを想定しています。この要件を簡易にするため、Oracle Enterprise SchedulerのテンプレートはOWSM-PMをターゲットにしません。ドメイン内の他の製品が自動的にOWSM-PMをターゲットにしている場合は、何もすることはありません。しかし、そのドメインにOracle Enterprise Scheduler以外の管理対象サーバーが存在しない場合、またはいずれのサーバーにもOWSM-PMがない場合は、OWSM-PMを手動でターゲットにする必要があります。
図3-1に示すように、Fusion Middleware構成ウィザードで、管理対象サーバー、クラスタおよびコヒーレンス・チェック・ボックスを選択します。
図3-1 Fusion Middleware構成ウィザード
「管理対象サーバー」画面で、ess_server1用に「WSMPM-MAN-SVR」サーバー・グループを選択します。「ESS-MGD-SVRS」がすでに選択されているはずです。
ドメインの設定を完了するには、プロセス・ジョブをサポートするためのPerlの構成が必要になる場合があります。Oracle Enterprise Schedulerでは、プロセス・ジョブをサポートするため、オプションでPerlを使用します。詳細は、『Oracle Fusion Middleware Oracle Enterprise Scheduler開発者ガイド』の「プロセス・タイプのジョブ定義を作成および格納する方法」を参照してください。
Enterprise Managerで次を実行します。
Enterprise Managerの「スケジューリング・サービス」メニューから、「構成」→「アプリケーション・プロパティ」を選択します。
PerlCommandというESSAPP内のESSレベルのプロパティをPerlの実行可能ファイルの場所に設定します。たとえば、PerlCommand = c:\Perl\bin\perl.exeのようにします。
Perlのバージョンは5.10以上です。
ESSはPerlを次の順序で検出します。
前述の構成から。
WL_HOMEが定義されている場合、$WL_HOME.../../webtier_mwhome/webtier/perl/bin/perlから。
それ以外の場合は、コンテナのパスから。
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秒です。
リクエスト・ディスパッチャを構成するには:
Cloud Controlの検索ページを使用して、構成に対して行われた変更を検索できます。
Cloud ControlにおいてOracle Enterprise Schedulerへの構成変更を検索するには:
Oracle Enterprise SchedulerのインスタンスはFusion Middleware Controlから起動および停止できます。
次のコンポーネントを起動および停止できます。
Oracle Enterprise Schedulerインスタンス
ジョブ・リクエスト・プロセッサおよびディスパッチャ
注意:
Oracle Enterprise Schedulerインスタンスまたはコンポーネントを停止することはお薦めしません。Oracle Enterprise Schedulerコンポーネントを停止した後も、ジョブ・リクエストはキューに蓄積されます。
この項では、次の項目について説明します。
スケジューリング・サービスの「コントロール」メニューで、Oracle Enterprise Schedulerインスタンスを起動し、スケジュール済のジョブ・リクエストを管理できます。
注意:
Oracle Enterprise Schedulerインスタンスまたはコンポーネントを停止することはお薦めしません。
Oracle Enterprise Schedulerのインスタンスを起動するには:
「スケジューリング・サービス」メニューから、「コントロール」を選択します。
「起動」を選択します。
Oracle Enterprise Schedulerのインスタンスを停止するには:
「スケジューリング・サービス」メニューから、構成済リクエスト・プロセッサまたはディスパッチャを起動または停止できます。
注意:
Oracle Enterprise Schedulerインスタンスまたはコンポーネントを停止することはお薦めしません。
リクエスト・プロセッサまたはディスパッチャを開始または停止する手順は、次のとおりです。
ナビゲーション・ペインで、「スケジューリング・サービス」フォルダを展開し、Oracle Enterprise Schedulerアプリケーションを選択します。
リクエスト・プロセッサまたはリクエストディスパッチャを、次の手順で起動します。
「スケジューリング・サービス」メニューから、「リクエスト・プロセッサ」→「起動」を選択するか、または「ホーム」ページから、「スケジューラ・コンポーネント」領域でリクエスト・プロセッサを選択し、「開始」ボタンをクリックします。
「スケジューリング・サービス」メニューから、「リクエスト・ディスパッチャ」→「起動」を選択するか、または「ホーム」ページから、「スケジューラ・コンポーネント」領域でリクエスト・ディスパッチャを選択し、「開始」ボタンをクリックします。
リクエスト・プロセッサまたはリクエストディスパッチャを、次の手順で停止します。
「スケジューリング・サービス」メニューから、「リクエスト・プロセッサ」→「停止」を選択するか、または「ホーム」ページから、「スケジューラ・コンポーネント」領域でリクエスト・プロセッサを選択し、「停止」ボタンをクリックします。
「スケジューリング・サービス」メニューから、「リクエスト・ディスパッチャ」→「停止」を選択するか、または「ホーム」ページから、「スケジューラ・コンポーネント」領域でリクエスト・ディスパッチャを選択し、「停止」ボタンをクリックします。
プロセッサまたはディスパッチャを停止するかどうかを尋ねられたら、「OK」をクリックします。
アプリケーション・プロパティを設定することで、Oracle Enterprise Schedulerとアプリケーションの相互作用を構成できます。Fusion Middleware Controlの「アプリケーション・プロパティ」ページでは、Oracle Enterprise Schedulerで定義されるプロパティの値を設定したり、デプロイされている構成の中でアプリケーションに設定されるプロパティの値を設定できます。
Oracle Enterprise Schedulerで定義される次のプロパティを、「アプリケーション・プロパティ」ページで構成できます。
RequestFileDirectory: リクエストとログ出力のディレクトリを指定します。デフォルトは、"{ESS_ENV:jrfServerLogPath}/ess_request/"です。
RequestFileDirectoryShared: リクエスト・ファイル・ディレクトリを共有するかどうかを示すフラグを指定します。デフォルトは"false"です。
PerlCommand: デフォルトで、Oracle Enterprise Schedulerは標準および拡張モードでのリクエスト用にJavaのエージェント・ハンドラを使用します。Fusionモードでのリクエストには、常時、Perlのエージェント・ハンドラを使用します。標準および拡張リクエスト・モードでPerlのエージェント・ハンドラを使用するには、プロセスのジョブを実行しているホスティング・アプリケーションに関連付けられたess-config.xmlファイルに、次の例に示すようにPerlCommandプロパティを追加する必要があります。
<EssProperties>
<EssProperty key="RequestFileDirectory" value="/tmp/ess/requestFileDirectory"/>
<EssProperty key="RequestFileDirectoryShared" value="false"/>
...
<EssProperty key="PerlCommand" value="/usr/bin/perl"/>
</EssProperties>
ディレクトリ名などの環境に依存する値を指定するため、トークンの置換を使用できます。
Oracle Enterprise SchedulerのPerlエージェントには、Oracle Perlバージョン5.10以上が必要です。プロセスのジョブをサポートするようにPerlをインストールする手順は、『Oracle Fusion Middleware Oracle Enterprise Scheduler管理者ガイド』の「プロセス・ジョブをサポートするためのPerlの構成」を参照してください。
EssCallbackClientSecurityPolicyURI: Webサービスのコールバック時に、Oracle Enterprise SchedulerからWebサービスを起動する際にWS-Securityヘッダーで使用されるセキュリティ・ポリシーURIを指定します。デフォルトは、nullです。
ClusterMode: サーバー・インスタンスがスタンドアロン・モードか拡張モードかを指定します。これは読取り専用で、変更できないプロパティです。
HostingAppPolicyStripe: Oracle Enterprise Schedulerの構成プロパティで、事前デプロイ済のネイティブ・ホスティング・アプリケーションにのみ適用可能です。このプロパティは、SOAおよびOSBアプリケーションで使用できる複数のセキュリティ・ストライプをサポートするために、事前デプロイのネイティブ・ホスティング・アプリケーションで事前構成済です。事前デプロイ済のネイティブ・ホスティング・アプリケーションのejb-jar.xmlファイルには、ポリシー・ストライプの静的な定義はありません。ストライプのリスト(追加コンポーネント用)は、ランタイム構成のMBean、Fusion Middleware ControlまたはWLSTのスクリプトを使用して動的に拡張できます。
ServerURL: このプロパティの値は、次の形式の文字列です。
http://host:port
これは、実行時にESSWebServiceのエンドポイント・アドレスの決定に使用され、具象WSDLESSWebServiceの一部として公開されます。
CallbackServerURL: このプロパティの値は、次の形式の文字列です。
http://host:port
これは、実行時にOracle Enterprise SchedulerのWebサービスのコールバック(EssAsyncCallbackServiceおよびEssWsJobAsyncCallbackServiceを含む)のエンドポイント・アドレスの決定に使用されます。このエンドポイント・アドレスは、それぞれのWSDLの一部として公開されます。
アプリケーション・プロパティを編集するには:
Oracle Enterprise Schedulerでは、EJBおよびWebサービスのジョブに名前付きの抽象的なジョブの場所を定義できる手段が提供されています。ジョブの場所は、Oracle Enterprise SchedulerのSYS_logicalClusterNameシステム・プロパティで指定し、論理クラスタ名(LCN)を指定します。EJBまたはWebサービス・ジョブのジョブ定義でLCNの値を指定した場合、Oracle Enterprise Manager Fusion Middleware Controlを使用して、ジョブ定義ではなく、ホスティング・アプリケーションのレベルで特定の環境固有のプロパティが指定されます。同じLCNを持つすべてのジョブ定義は、Oracle Enterprise Manager Fusion Middleware Controlを使用してホスティング・アプリケーションの構成プロパティに入力されたプロパティの値を共有します。
注意:
「論理クラスタ」および「ジョブの場所」という用語は、同じ意味で使用できます。
ジョブの場所の機能を使用する手順は、次のとおりです。
注意:
ジョブの場所およびプロパティを表から選択し、「ジョブの場所の削除」または「プロパティの削除」をクリックして削除することもできます。
Oracle Enterprise Schedulerのデータとメタデータへのアクセスを制御するには、ユーザーとユーザー・グループを表現するアプリケーション・ロールを作成し、これに特定のアプリケーション・リソースへのアクセス権を付与します。
この項では、アプリケーション・ロールの作成方法について説明します。次の項も参考になります。
メタデータに対するアクセス権の付与の詳細は、「Oracle Enterprise Schedulerジョブの作業の管理」の「ジョブのメタデータ・セキュリティの管理」を参照してください。
データに対するアクセス権の付与の詳細は、「Oracle Enterprise Schedulerリクエストの管理」の「ジョブ・リクエストのためのシンプル・データ・セキュリティの構成」を参照してください。
Oracle Enterprise SchedulerのWebサービスは、Oracle Infrastructure Web Servicesです。Webサービスの管理の詳細は、『Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイド』の「Oracle WSMポリシー・フレームワークについて」の章を参照してください。
注意:
Oracle Enterprise Scheduler Webサービスは、Webブラウザから起動することはできません。
Oracle Enterprise SchedulerのWebサービスおよびOracle Enterprise Schedulerの非同期コールバックWebサービスのOWSMポリシーを構成するには、グローバルにアタッチされたポリシーまたは直接アタッチされたポリシーのいずれかを使用できます。
注意:
Oracle Enterprise SchedulerのWebサービスおよび非同期コールバックWebサービスは、両方ともOracle Infrastructure Web Servicesです。
グローバルおよび直接アタッチでOWSMポリシーをアタッチする手順は、『Oracle Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシーの追加に関する項を参照してください。
次に示すOracle Web Services ManagerによるWebサービスの保護およびポリシー管理のセクションは、Oracle Enterprise SchedulerのWebサービスのためのグローバルまたは直接アタッチされたポリシーの構成に特に役立ちます。
4.3.1Fusion Middleware Controlを使用したポリシーを直接アタッチする
4.3.2Fusion Middleware Controlを使用したポリシーをグローバルにアタッチする
4.4.3 WLSTを使用したポリシーをRESTfulなOracle Infrastructure Webサービスやクライアントへ直接アタッチする
4.4.4WLSTを使用したポリシーをグローバルにアタッチする
