トランザクション・バッチ・アプリケーションおよび数値計算アプリケーションの環境計画

バッチ環境を計画する際には、ニーズに最も適合するように環境を設計するために役立つ特定の要因を考慮する必要があります。

環境を構築する前に、到達目標について注意深く考える必要があります。例えば、既存のセル内でバッチ環境を構成することも、新規セルを作成することもできます。また、使用するリレーショナル・データベース、必要なセキュリティー、およびアベイラビリティー要件を決定する必要があります。以下のセクションでは、これらの考慮事項のそれぞれについて説明しています。

新しいセルまたは既存のセル

既存の WebSphere® Application Server セル内で バッチ 環境を構成することも、まったく新しいセルを作成することもできます。既存の WebSphere Application Server 環境から分離された新規の環境が必要であるか、既存の環境にバッチの機能を追加したいかによって、どちらを選択するかが決まります。

ジョブ・スケジューラーおよびバッチ・コンテナー機能を配置するアプリケーション・サーバー・ノードで、管理コンソールを使用して機能をアクティブにします。デプロイメント・マネージャー・ノードではアクションは必要ありません。

ジョブ・タイプ

ジョブ・タイプは 2 つあります。それらは、WebSphere Application Server 環境でホストされます。
  1. トランザクション・バッチ

    Java™ で開発されているトランザクション・バッチ・アプリケーションを実行し、WebSphere Application Server プログラミング・モデルを実装します。これらのアプリケーションは、Enterprise Archive (EAR) ファイルとしてパッケージ化され、アプリケーション・サーバーまたはクラスターでホストされているバッチ・コンテナーにデプロイされます。

    トランザクション・バッチ・プログラミング・モデルは、コンテナーが管理するチェックポイント/リスタート・メカニズムを提供します。これは、バッチ・ジョブが、計画された停止または計画外の停止によって中断された場合に、最後のチェックポイントから再開できるようにするものです。

  2. 計算主体

    Java で書かれ、WebSphere Application Server プログラミング・モデルを実装する数値計算アプリケーションを実行します。これらは、EAR ファイルとしてパッケージされ、アプリケーション・サーバーまたはクラスターでホストされるバッチ・コンテナーにデプロイされます。

    数値計算のプログラミング・モデルは、 共通フレームワークに基づいた単純な実行モデルを提供します。

すべてのバッチ環境で、WebSphere Application Server サーバーまたはクラスター上にジョブ・スケジューラーをデプロイする必要があります。トランザクション・バッチ・ジョブ・タイプまたは数値計算ジョブ・タイプをホストするように環境をセットアップするには、少なくとも 1 つの WebSphere Application Server サーバーまたはクラスターにバッチ・コンテナーをデプロイする必要があります。トランザクション・バッチ・アプリケーション、数値計算アプリケーション、またはその両方が、同じ WebSphere Application Server サーバーまたはクラスターにインストールされています。

リレーショナル・データベース

ジョブ・スケジューラーおよびバッチ・コンテナーは、両方ともリレーショナル・データベースへのアクセスを必要とします。 使用されるリレーショナル・データベースは、JDBC に接続されています。リレーショナル・データベースへのアクセスは、基盤となる WebSphere Application Server 接続管理機能を通じて行われます。サポートされるリレーショナル・データベースは、WebSphere Application Server がサポートするリレーショナル・データベースと同じであり、DB2®、Oracle などが含まれます。

トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): EJB タイマー/スケジューラーを構成するときには、デフォルトのスケジューラーでは、機能する環境を迅速に稼働できるように、単純なファイル・ベースの Apache Derby データベースがデフォルトで使用されることに留意してください。Derby データベースを実動用に使用しないでください。また、デフォルトの Derby データベースは、クラスター化されたジョブ・スケジューラー、およびクラスター化されたバッチ・コンテナーをサポートしません。gotcha

可用性の高い環境には、クラスター化されたジョブ・スケジューラー、および 1 つ以上のクラスター化されたバッチ・コンテナーの両方が含まれます。クラスター化には、ネットワーク・データベースが必要です。 この目的のために、DB2 などの実動グレードのデータベースを使用します。Network Derby も動作しますが、実動の目的に必要な頑強性に欠けています。実動ではネットワーク・バージョンを使用しないでください。

トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): アプリケーションの JPA 設定は常にこのページの設定をオーバーライドします。gotcha

セキュリティーに関する考慮事項

バッチ環境のセキュリティーは、次の手法に基づいています。

  1. ジョブ・スケジューラー・インターフェースにアクセスするための WebSphere 認証。アクティブな WebSphere セキュリティー・レジストリーに定義されたユーザーは、 認証を受けて、ジョブ・スケジューラーの Web、コマンド行、およびプログラムのインターフェースへのアクセス権限を取得できます。
  2. ジョブへのアクセス権用のロール・ベースのセキュリティー。認証されたユーザーが、ジョブに対してアクションを実行するには、適切なロールに割り当てられる必要があります。ロールには次の 3 種類があります。
    lrsubmitter
    lrsubmitter ロールのユーザーは、自分のジョブをサブミットして操作できますが、他のユーザーのジョブはできません。
    lradmin
    lradmin ロールのユーザーは、自分のジョブ、または他のユーザーのジョブをサブミットして操作できます。
    lrmonitor
    lrmonitor ロールが割り当てられたユーザーは、全ユーザーのジョブおよびジョブ・ログの表示のみが可能です。

    これらのロールは、管理コンソールのジョブ・スケジューラー構成ページを使用して割り当てることができます。

高可用性の考慮事項

バッチ・コンポーネントの高可用性には、クラスタリングを使用します。ジョブ・スケジューラーおよびバッチ・コンテナーを使用し、クラスターをデプロイして操作します。

ジョブ・スケジューラーを利用した標準的なアプリケーションのクラスタリングの手法を使用して、高可用性を実現します。ジョブ・スケジューラーは、 API へのアクセス方式をいくつかサポートしています。これらの方式としては、Web アプリケーション、コマンド行、Web サービス、 および Enterprise JavaBeans (EJB) があります。 クラスター化されたジョブ・スケジューラーへの可用性が高いネットワーク・アクセスの実現は、どのジョブ・スケジューラー API のアクセス方式を使用するかによって異なります。 バッチ・コンテナーは、クラスターにデプロイすることで、高可用性が確保されます。 ジョブ・スケジューラーは、バッチ・コンテナーがクラスター化されたことを自動的に認識し、そこで実行されるバッチ・ジョブに可用性の高い実行環境を保証するためにバッチ・コンテナーを利用します。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cgrid_cgplan
ファイル名:cgrid_cgplan.html