A.4 Oracle Enterprise Schedulerクラスタの管理

Oracle Enterprise Schedulerクラスタの管理には、クラスタの起動、クラスタ全体への構成変更の伝播、アプリケーションのデプロイおよび想定外の動作への対応が含まれます。

この項では、次の項目について説明します。

A.4.1 クラスタの起動と停止

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クラスタ全体がダウンしている場合は届きません。

突然停止された場合、サーバーは継続中のトランザクションのリカバリを試みます。

A.4.2 クラスタへの構成変更の伝播

構成には、コンテナつまりサーバーの構成と、ジョブ・メタデータの構成の2種類があります。ジョブ・メタデータはOracle Metadata Repositoryに格納されます。サーバーは標準のOracle WebLogic Serverを構成する場合と同じプロセスで、Oracle WebLogic Server構成フレームワークで維持されるプラットフォーム構成の一部として構成されます。ジョブ・メタデータ構成の変更はOracle JDeveloperからデプロイされます。

クラスタ・レベルでは、いかなる構成変更もEARファイルまたはメタデータのデプロイによって伝播されます。構成データはデータベースまたはEARファイルに保存されます。ess-config.xmlなど、EARファイル内の構成ファイルは、Fusion Middleware ControlのMBeanブラウザを使用して変更できます。

クラスタ・メンバーは独立していて、データベースのみを共有します。クラスタのメンバー間での通信はありません。

A.4.3 クラスタへのアプリケーションのデプロイ

アプリケーションは、標準のOracle WebLogic Server EARファイルを使用して、標準のJ2EE定義Oracle WebLogic Serverメカニズムを使用してクラスタにデプロイされます。EARファイルをデプロイするときにサーバーを再起動する必要はありません。

アプリケーション・デプロイメントにはEARファイルが含まれ、これにJAZNおよびMARファイルが含まれています。JAZNファイルには、スケジュール済ジョブに対するアクセス権限が格納されており、Oracle Authorization Policy Managerの管理下でLDAPに保存されます。MARファイルにはメタデータが含まれており、MDSに保存されます。Oracle WebLogic Serverは、アプリケーションEARファイルをクラスタ内のすべての管理対象サーバーにデプロイします。

A.4.4 障害および予期される動作

障害が発生してもジョブの処理を確実に継続させる方法としては、Oracle Enterprise Schedulerクラスタを構成する方法が一般的です。サーバーに障害が発生すると、クラスタ内の別のノードが、障害が発生したサーバーで実行されているすべてのジョブの状態を、該当する状態に遷移させます。たとえば、同期ジョブがエラーで終了した場合、再試行が構成されていればジョブの再試行が実行されます。

データ層の高可用性を確立するには、Oracle RACを使用します。

この項では、次の項目について説明します。

A.4.4.1 再試行

非同期ジョブの再試行とタイム・アウトを構成できます。ジョブの再試行とタイム・アウトを構成する方法の詳細は、「ジョブ・リクエストの作成」を参照してください。

A.4.4.2 障害検出と再起動

障害検出とリカバリを可能にするため、Oracle Enterprise Schedulerの各クラスタ・ノードは、データベース内のレコードを1分おきに更新します。これをハートビートと呼びます。ハートビートは他のノードによって監視され、レコードが一定の時間変更されなかった場合、そのサーバーは障害が発生しているものと見なされます。サーバー障害が検出されたときに、そのサーバー上で実行されている各ジョブが処理されます。同期ジョブはエラーありの完了としてマーキングされ、非同期ジョブはリモートで実行が継続されます。再試行が構成されている場合、エラーありの完了としてマーキングされたジョブは再実行されます。障害検出には10分程度の時間がかかります。

障害検出時に、ノードの出力とログ・ファイルは別のノードからアクセスできる状態にある必要があります。そのため、ジョブ出力とログ・ファイルを格納するファイル・ディレクトリは共有ファイル・システム上に置いておく必要があります。このディレクトリはess-config.xmlファイルにリストされています。

A.4.4.3 Oracle Java Transaction APIの移行とOracle Java Message Service

Oracle JTAの移行は、Oracle Enterprise Schedulerでは必要ありません。

Oracle Enterprise SchedulerはOracle Java Message Service(JMS)を使用しないため、JMSリカバリは不要です。