このトピックでは、さまざまな Compute Grid 環境、それらの環境について意思決定を行う上で検討する必要のある要因、 およびニーズに最も適した環境を設計する上での考慮事項について説明します。
Compute Grid 環境を構築する前に、最適な意思決定を行うために何を構築するか、入念に検討する必要があります。例えば、 既存の WebSphere セルに Compute Grid を構築したり、Compute Grid 環境をホストする新しい WebSphere セルを構築したりすることができます。 また、Compute Grid 環境を構築して、WebSphere バッチ・ジョブまたはネイティブ実行ジョブ、 あるいはその両方を実行することもできます。さらに、使用するリレーショナル・データベース、必要なセキュリティー、 および可用性要件を決定する必要があります。Tivoli Workload Scheduler (TWS) などの外部ワークロード・スケジューラーを使用して、 Compute Grid ワークロードを制御する場合は、 JMS および WSGridNotification SPI 構成を計画する必要があります。以下のセクションで、それぞれの考慮事項について説明します。
新しいセルを構築したり、 既存のセルを使用したりするのに基本的な理由はありません。このような選択は、 新規の環境を既存の WebSphere 環境から分離するかどうか、 または Compute Grid 機能を既存の WebSphere 環境に追加するかどうかによって異なります。Compute Grid を既存の WebSphere セルに追加する場合、WebSphere Extended Deployment Compute Grid V6.1 では、 WebSphere Application Server V6.1 が必要になります。 したがって、Compute Grid を追加する前に、既存のセルを V6.1 に移行する必要が生じることがあります。コンポーネントごとの前提条件については、WebSphere Extended Deployment detailed system requirements を参照してください。
必要なことは、ジョブ・スケジューラーまたはバッチ・コンテナー機能をアクティブにする WebSphere ノードに Compute Grid をインストールすることだけです。これらのノードは、WebSphere V6.1 レベルにする必要があります。
Compute Grid 環境を新規の WebSphere セルに構築する手順は、ほとんど同じです。唯一の違いは、WebSphere セルを構成する WebSphere ノードを最初に構築する必要がある点です。 これを行うには、WebSphere をインストールし、WebSphere セルの構築に必要なプロファイルを作成します。
Java で開発されているトランザクション・バッチ・アプリケーションを実行し、WebSphere プログラミング・モデルを実装します。 これらのアプリケーションは、Enterprise Archive (EAR) ファイルとしてパッケージ化され、WebSphere Application Server またはクラスターでホストされているバッチ・コンテナーにデプロイされます。
トランザクション・バッチのプログラミング・モデルは、 計画または計画外の停止によって中断された場合に、 最後のチェックポイントから Compute Grid ジョブを再始動できるようにする コンテナー管理のチェックポイント/再始動機能を提供します。
Java で開発された数値計算のアプリケーションを実行し、WebSphere プログラミング・モデルを実装します。 これらのアプリケーションは、Enterprise Archive (EAR) ファイルとしてパッケージ化され、WebSphere Application Server またはクラスターでホストされているバッチ・コンテナーにデプロイされます。
数値計算のプログラミング・モデルは、 共通フレームワークに基づいた単純な実行モデルを提供します。
アプリケーションのデプロイ先であるターゲット・ノードによってサポートされている 任意の言語およびプログラミング・モデルで開発できるネイティブ実行アプリケーションを実行します。このようなアプリケーションの パッケージ化およびデプロイメント手法は、どちらも WebSphere 管理の対象から外れます。
ネイティブ実行モデルは、 既存の非対話式プログラムをバッチ・ジョブとして実行および制御する手段を提供します。
すべての Compute Grid 環境では、 WebSphere サーバーまたはクラスターにジョブ・スケジューラーをデプロイする必要があります。トランザクション・バッチ または数値計算のジョブ・タイプをホストするための環境では、少なくとも 1 つの WebSphere サーバーまたはクラスターに バッチ・コンテナーをデプロイする必要があります。トランザクション・バッチ・アプリケーションまたは数値計算のアプリケーション、 あるいはその両方は、同じ WebSphere サーバーまたはクラスターにインストールします。ネイティブ実行ジョブ・タイプをホストする場合は、 各ノードでノード・エージェントを使用してターゲット・セル内の WebSphere ノード上で行ってください。ただし、 ネイティブ実行ジョブを実行する追加ノードを用意する場合に、これらのノードで WebSphere を必要としないときは、 このターゲット・ノードにミドルウェア・エージェントをインストールして構成する必要があります。
Compute Grid ジョブ・スケジューラー およびバッチ・コンテナーは、いずれもリレーショナル・データベースへのアクセスを必要とします。使用される リレーショナル・データベースは JDBC で接続されます。Compute Grid のアクセスは、基盤となる WebSphere Application Server 接続管理機能に依存します。 サポートされているリレーショナル・データベースは、 DB2、Oracle など、WebSphere Application Server によってサポートされているものと同じです。
Compute Grid は、 単純なファイル・ベースの Derby データベースをデフォルトで自動構成して、Compute Grid 環境を素早く稼働状態にします。ただし、 Derby データベースは実動用には推奨しません。また、デフォルトの Derby データベースは、 クラスター・ジョブ・スケジューラーもクラスター・バッチ・コンテナーもサポートしていません。
高可用性の Compute Grid 環境は、 クラスター・ジョブ・スケジューラー、および 1 つ以上のクラスター・バッチ・コンテナーの両方を備えています。クラスタリングは、 ネットワーク・データベースを必要とします。この用途には、DB2 など実動クラスのデータベースを推奨します。Network Derby または Cloudscape も 使用できますが、実動用に必要な堅固さに欠けるため推奨しません。
制限: 同じセル内の すべてのバッチ・コンテナーでは、同じタイプのリレーショナル・データベースを使用する必要があります。
Compute Grid のロールは、WebSphere 管理コンソールのジョブ・スケジューラー構成ページで割り当てます。
Compute Grid コンポーネントの高可用性には、 クラスタリングを使用します。高可用性を得るには、ジョブ・スケジューラーおよび バッチ・コンテナーをクラスターにデプロイして作動させる必要があります。
可用性を高めるには、標準的な アプリケーション・クラスタリング手法をジョブ・スケジューラーとともに使用する必要があります。ジョブ・スケジューラーは、 API へのアクセス方式をいくつかサポートしています。これらの方式としては、Web アプリケーション、コマンド行、Web サービス、 および Enterprise JavaBean (EJB) があります。クラスター・ジョブ・スケジューラーへのネットワーク・アクセスの高可用性を確保する方法は、 ジョブ・スケジューラー API アクセス方式によって異なります。これらの選択肢としては、WebSphere プラグイン、 または WebSphere Extended Deployment Operations Optimization 機能のオンデマンド・ルーターの使用があります。バッチ・コンテナーは、 クラスターにデプロイすると、可用性が向上します。ジョブ・スケジューラーは、バッチ・コンテナーが クラスター化されていることを自動的に認識し、それを利用して、そこで実行されるバッチ・ジョブの実行環境 の高可用性を確保します。