JP5166350B2

JP5166350B2 - クラスタコンピュータミドルウェアプログラム

Info

Publication number: JP5166350B2
Application number: JP2009128443A
Authority: JP
Inventors: 高木　　太郎
Original assignee: 株式会社イマジオム
Priority date: 2005-01-19
Filing date: 2009-05-28
Publication date: 2013-03-21
Anticipated expiration: 2025-12-15
Also published as: JP2009187590A

Description

本発明はクラスタコンピュータミドルウェアに関し、特にアプリケーションを容易に移植・開発することのできるクラスタコンピュータミドルウェアに関する。

複数のコンピュータをネットワークで接続し、協調動作するようにしたものを「クラスタコンピュータ」と呼ぶ。クラスタコンピュータは並列コンピュータの一種で、パーソナルコンピュータの急激な高性能化・低価格化を背景に、比較的低コストで超高速計算を実現する手段として注目されている。

特許文献１には、クラスタコンピュータの一例が記載されている。しかしクラスタコンピュータには、物理的な構成や運用形態の異なる多くの種類があり、それぞれ解決するべき課題も異なっている。この例のクラスタコンピュータは、地理的に離れたコンピュータを比較的伝送速度の遅い広域ネットワークで結合するもので、前記の公報にはシステム全体の処理性能を高めるため、広域ネットワークの中に配置されているルータの負荷を分散させる手法が提示されている。すなわち他のクラスタ装置にアプリケーションジョブを振り分ける際に、各クラスタ装置のリソース管理情報、およびネットワーク制御情報に基づき、アプリケーションジョブを振り分ける構成が示されている。なお本発明の対象とするクラスタコンピュータは、後で述べるように上記公知例のクラスタコンピュータとは物理的な構成や運用形態が異なる。したがって本発明の解決するべき課題も、システム全体の処理性能を高めるという上記公知例の課題とは異なる。

一般的なクラスタコンピュータは、「マスタコンピュータ」と呼ばれる１台のコンピュータと、「スレーブコンピュータ」と呼ばれる多数のコンピュータから構成されている。アプリケーションは普段、マスタコンピュータで動作している。並列処理が必要となる部分にさしかかると、マスタコンピュータは素材データを個々のスレーブコンピュータに分配した上、それぞれのスレーブコンピュータが担当する処理の範囲を決定し、処理の開始をそれぞれのスレーブコンピュータに指示する。処理を終えたスレーブコンピュータは、部分的な結果データをマスタコンピュータに送り、マスタコンピュータはそれらを統合して一つのまとまった結果データを得る。このように並列処理を実現するために行われる一連の動作のことを「処理手順」と呼ぶ。実際のアプリケーションでは、処理に要する時間を短縮したり、必要なメモリ容量を小さくしたりする目的で、上記のような単純な処理手順だけでなく、より複雑な処理手順が使われることも多い。

コンピュータとクラスタコンピュータは、その構成が大きく異なっているので、通常のアプリケーションを、そのままクラスタコンピュータで動作させることはできない。クラスタコンピュータで動作するアプリケーションを作成するには、あらかじめアプリケーションをクラスタコンピュータ用として設計し、データの分配・回収、処理開始の指示の送信、処理終了の通知の受信といった、基本的な機能を盛り込む必要がある。

こうした基本的な機能を集め、アプリケーションから簡単に使うことができるようにしたソフトウェアは「クラスタコンピュータミドルウェア」と呼ばれる。クラスタコンピュータミドルウェアは、アプリケーションとコンピュータの間に位置するネットワークソフトウェアであり、個々のコンピュータの接続・動作の状態を監視・変更したり、アプリケーションからの指示を個々のコンピュータに分配したり、個々のコンピュータからの通知を取りまとめてアプリケーションに伝えたりする機能を持っている。クラスタコンピュータミドルウェアを使うと、アプリケーションがコンピュータ間のデータ通信を意識する必要性が軽減され、クラスタコンピュータ用のアプリケーションを簡単に書くことができる。このようなクラスタコンピュータミドルウェアの例は、たとえば特許文献２に記載されている。

特開２００２−２５９３５３号公報特開２００４−３８２２６号公報

しかしながら前記従来技術では、並列アプリケーションを開発するために多大な費用・労力、高度な知識・技術が必要とされた。また開発する並列アプリケーションに、高い拡張性と上位互換性を与えることが難しかった。

たとえば従来の一般的なクラスタコンピュータミドルウェアでは、アプリケーションやコンピュータから送られる指示・通知を加工せず、そのまま相手先に送っていた。そのため一般的なアプリケーションは、個々のコンピュータに処理の開始を指示した後、それらからの処理終了の通知を待つループに入るように作らなければならなかった。

図２３に、クラスタコンピュータ１００において、上記の並列処理手順を実現するために、アプリケーションとクラスタコンピュータミドルウェアが行う情報交換の内容を示す。普段マスタモジュールで実行されているアプリケーションは、並列処理が必要な部分にさしかかると、個々のスレーブモジュールに、部分的な処理の開始を要求する指示３１０（３１０Ａ・３１０Ｂ・３１０Ｃ）を送る。これを受けたスレーブモジュールは、それぞれの担当する処理を行い、それが終わったら、処理の完了を知らせる通知３２０（３２０Ａ・３２０Ｂ・３２０Ｃ）をマスタモジュールに送る。スレーブモジュールが処理を行っている間、マスタモジュールは、スレーブモジュールからの通知３２０を待っている。

ここで従来のクラスタコンピュータミドルウェアの問題点を明確にするため、簡単なアプリケーションを例に取り上げ、これをクラスタコンピュータ１００に移植することを考える。並列化する前のソースコードを図２４に模式的に示す。このアプリケーションは、前処理に相当するＰｒｏｃｅｓｓＡと、本処理に相当するＰｒｏｃｅｓｓＢと、後処理に相当するＰｒｏｃｅｓｓＣを順番に実行するものである。ＰｒｏｃｅｓｓＢは繰り返し処理であり、実行するのに長い時間がかかるので、ここではＰｒｏｃｅｓｓＢを並列化することを考える。

図２４のアプリケーションを従来のクラスタコンピュータミドルウェアを使用して並列化した、新しいアプリケーションのマスタモジュールのソースコードを図２５に模式的に示す。並列化される前のソースコードと比較すると、並列化された後のソースコードはきわめて読みにくくなっていることがわかる。たとえばこのソースコードには、マスタモジュールでの特定の処理をトリガとして実行される処理ブロック４３０と、スレーブモジュールから送られる通知３２０をトリガとして実行される処理ブロック４２０が混在している。処理ブロック４３０には、スレーブモジュールの処理終了を待つためのループを置く必要がある。また処理ブロック４２０と処理ブロック４３０は、異なるトリガによって非同期的に実行されるので、これらが使用する変数は、すべてグローバル変数４１０として定義する必要がある。オブジェクト指向に基づく近代的なプログラミングにおいては、グローバル変数はなるべく使うべきではないとされており、これは望ましくないことである。また図２４では実行される順番に置かれていたＰｒｏｃｅｓｓＡとＰｒｏｃｅｓｓＣは、新しいソースコードではまったく異なる部位に記述されており、その順番も逆になっている。また図２５には書かれていないが、実際には非同期的に実行される処理ブロックの間の干渉を防ぐため、再入（処理が終わる前に、再び同じ処理が始められること）を防止するための仕組みが不可欠であり、スレーブコンピュータ１１０ｂ〜１１０ｉや、通信ネットワーク１２０の障害を想定したエラー対策も考慮すると、従来のクラスタコンピュータミドルウェアを使用したアプリケーションの並列化は非常に難しいことがわかる。

このように従来技術では、個々のコンピュータから通知が非同期的に送られることによる、アプリケーションの可読性の低下やデバッグの困難を避けることができなかった。通知が「非同期的に送られる」とは、マスタコンピュータで実行される「メイン処理」とは無関係に、スレーブコンピュータで実行される「サブ処理」をトリガとする通知が送られるということである。その結果、次のような問題が生じていた。
（１）エラーが発生した場合、そのエラーがメイン処理によって発生したのか、サブ処理によって発生したのかを特定することが困難である。そのため体系的なデバッグがしにくい。
（２）メイン処理の実行される順番と、ソースコードに記述される順番が一致しない。そのため並列化の前と後では、ソースコードの構造がまったく異なったものとなる。またメイン処理の中に、通知を待つループ処理が多く現れ、ソースコードの可読性を損なう。
（３）メイン処理がサブ処理の実行順序に依存する。そのためミドルウェアが改良されたりしてサブ処理の実行順序が変わると、それを使用しているアプリケーションも作り直さなければならない。
（４）並列処理の手順によってメイン処理が変化する。そのためライブラリのように並列化するべき処理が多くある場合、それぞれの処理がまったく異なった構造で書かれることになり、ソースコードの管理が難しくなる。
（５）独立に動作しているスレーブコンピュータの動作タイミングを模擬することが難しいので、確実に動作するアプリケーションを開発するには、実際にクラスタコンピュータを用意する必要がある。
（６）メイン処理からの指示に対し、即座にサブ処理が実行される。そのためメイン処理には、サブ処理を実行するタイミングを管理する責任が発生する。

本発明は、それぞれのコンピュータから通知が非同期的に送られることに起因する、従来のクラスタコンピュータミドルウェアが抱える問題を解決するためのものである。

本発明の第１の解決課題は、並列アプリケーションを開発するために多大な費用・労力、高度な知識・技術を必要としないクラスタコンピュータミドルウェアを提供することにある。

本発明の第２の解決課題は、開発する並列アプリケーションに、高い拡張性と上位互換性を与えることが容易なクラスタコンピュータミドルウェアを提供することにある。

本発明のその他の解決課題と新規な特徴については、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すると以下のとおりである。

（１）クラスタコンピュータの上で動作し、複数のコンピュータを協調動作させる機能をアプリケーションプログラムに提供するクラスタコンピュータミドルウェアプログラムであって、前記クラスタコンピュータが、一つのマスタコンピュータと、一つ以上のスレーブコンピュータと、前記マスタコンピュータおよび前記スレーブコンピュータを相互に接続するネットワークとを含むものにおいて、前記クラスタコンピュータミドルウェアプログラムが少なくとも、前記マスタコンピュータで動作するマスタアプリケーションプログラムとのリンクが可能なマスタモジュールと、前記スレーブコンピュータで動作するスレーブアプリケーションプログラムとのリンクが可能なスレーブモジュールとによって構成され、前記マスタモジュールが、並列処理全体の構成要素である個々のタスクに対し、前記タスクを実行させるコンピュータとタイミングとを決定する機能を持つスケジューラを備え、前記マスタモジュールに、前記スケジューラが動作を開始する前に前記マスタアプリケーションプログラムの処理を一時停止させ、前記スケジューラが前記動作を終了した後に前記マスタアプリケーションプログラムの処理を再開させる機能を実現させ、かつ前記マスタモジュールおよび前記スレーブモジュールに、前記スケジューラから受け取った指示に基づき、前記スレーブモジュールと相互に通信する機能と、前記タスクを実行するイベントハンドラをあらかじめ設定する機能と、前記スケジューラの動作の開始に伴い、前記スケジューラから受け取った指示に基づき、前記イベントハンドラを実行する機能とを実現させることを特徴とするクラスタコンピュータミドルウェアプログラム。

本発明の一つの特徴によれば、それぞれのコンピュータからの通知が非同期的に送られなくなるので、アプリケーションの可読性が向上し、デバッグも容易になる。

また本発明のもう一つの特徴によれば、クラスタコンピュータの実際の構成をアプリケーションから隠すことができる。そのためクラスタコンピュータの構成に依存する処理手順をアプリケーションに実装する必要がなくなる。また同一のアプリケーションを異なる構成のクラスタコンピュータで動作させることができるようになる。

クラスタコンピュータ１００のハードウェア構成例を示す図である。簡単な並列処理手順の一例を示す図である。本発明の一実施例になるクラスタコンピュータミドルウェア５００の構成を示す図である。本発明の一実施例になるクラスタコンピュータミドルウェア５００が規定するセッションの性質を示す図である。本発明の一実施例になるクラスタコンピュータミドルウェア５００が規定するセッションの関係を、図形を使って表記する方法を示す図である。本発明の一実施例になるクラスタコンピュータミドルウェア５００が規定するセッションの位相構造を示す図である。図６に示した各セッションで行われる処理の内容を示す図である。本発明の一実施例になるクラスタコンピュータミドルウェア５００を使用するアプリケーションの構成を示す図である。本発明の一実施例になるクラスタコンピュータミドルウェア５００のマスタモジュールと、アプリケーション５１０のマスタモジュールが行う、情報交換の内容を示す図である。本発明の一実施例になるクラスタコンピュータミドルウェア５００を使用して並列化されたアプリケーションのマスタモジュールのソースコードを模式的に示す図である。本発明の他の実施例になる天気図作成システム７００の構成を示す図である。本発明の他の実施例になる３次元画像処理システム８００の構成を示す図である。本発明の他の実施例になるクラスタコンピュータシミュレータ９００の構成を示す図である。図１３の実施例における、クラスタコンピュータシミュレータ９００の画面の一例を示す図である。図３の実施例における、コンピュータ１１０の内部の構成を模式的に示す図である。図３の実施例における、クラスタコンピュータミドルウェア１２００とアプリケーション１３００の内部の論理的構成を示す図である。処理手順１４００の例を示す図である。データ配置テーブル１２１２のデータ構造を例示する図である。ノード属性テーブル１２１３のデータ構造を例示する図である。クラスタコンピュータミドルウェア１２００とアプリケーション１３００の間で、制御が移動する様子を示す図である。クラスタコンピュータミドルウェア１２００とアプリケーション１３００の間で、制御が移動する様子を詳しく示す図である。アプリケーション１３００のマスタモジュール１３００ａのソースコードを示す図である。従来のクラスタコンピュータミドルウェアのマスタモジュールと、アプリケーションのマスタモジュールが行う、情報交換の内容を示す図である。アプリケーションのソースコードを模式的に示す図である。従来のクラスタコンピュータミドルウェアを使用して並列化されたアプリケーションのマスタモジュールのソースコードを模式的に示す図である。

以下、本発明の実施の形態について、詳細に説明する。
［クラスタコンピュータの一般論］
本発明によるクラスタコンピュータミドルウェアについて説明する前に、ここでクラスタコンピュータの一般論について簡単に述べる。一般的なクラスタコンピュータ１００のハードウェア構成例を図１に示す。クラスタコンピュータ１００は、１台のマスタコンピュータ１１０ａと、多数のスレーブコンピュータ１１０ｂ〜１１０ｉによって構成されており、これらが高速の通信ネットワーク１２０で相互に結合されている。マスタコンピュータ１１０ａは、ディスプレイ１３１と、キーボード１３２と、マウス１３３からなるコンソールを備えている。しかしスレーブコンピュータ１１０ｂ〜１１０ｉはコンソールを備えておらず、その操作はマスタコンピュータ１１０ａから通信ネットワーク１２０を経由して間接的に行われる。

クラスタコンピュータ１００では、複数のコンピュータ１１０が物理的に近接した場所に配置されていることを想定している。その場合、スイッチングハブとＬＡＮケーブルを使用してネットワーク１２０を構成することができる。ただし本発明は、複数のコンピュータ１１０が離れた場所に配置されており、ルータや光ファイバを使用してネットワーク１２０が構成されている場合にも応用可能である。

それぞれのコンピュータ１１０には、クラスタコンピュータミドルウェア５００と、それを利用するアプリケーション５１０がインストールされている。これらのクラスタコンピュータミドルウェアとアプリケーションは、それぞれが「マスタモジュール」と「スレーブモジュール」に分割されている。したがってクラスタコンピュータ１００では、以下の四種類のプログラムが動作することになる。
（１）クラスタコンピュータミドルウェア（マスタモジュール）５００Ｍ
（２）クラスタコンピュータミドルウェア（スレーブモジュール）５００Ｓ
（３）アプリケーション（マスタモジュール）５１０Ｍ
（４）アプリケーション（スレーブモジュール）５１０Ｓ
一般にアプリケーションは、マスタモジュール・スレーブモジュールとも、実行可能なプログラムとして提供される。一方クラスタコンピュータミドルウェアは通常ライブラリとして提供され、それぞれのモジュールは、アプリケーションの対応するモジュールにリンクされて動作する。

アプリケーションが並列処理を行うには、所定の手順でデータをコピー・削除したり、処理を実行したりする必要がある。そのような手順のことを「並列処理手順」と呼ぶ。図２に、簡単な並列処理手順の一例を示す。この並列処理手順は、次の四つのステップからなる。

ステップ１：マスタモジュールがスレーブモジュールに素材データ２１０をコピーしてから、処理開始を命令するステップ。

ステップ２：スレーブモジュールが素材データ２１０を処理し、結果データ２２０の断片である結果データ２２１を作成してから、マスタモジュールに処理終了を報告するステップ。

ステップ３：マスタモジュールがスレーブモジュールに結果データ２２１のコピーを命令し、スレーブモジュールから送られた結果データ２２１をマスタモジュールが統合して結果データ２２０を作成するステップ。

ステップ４：マスタモジュールがスレーブモジュールに素材データ２１０と結果データ２２１の削除を命令し、スレーブモジュールが素材データ２１０と結果データ２２１を削除するステップ。

以上のステップにより、１台のコンピュータが動作する場合と同じように、素材データ２１０から結果データ２２０が作成される。

以下では本発明の実施形態を、図面に示したいくつかの実施例を参照しながら、さらに詳細に説明する。

本発明の第１の実施例になる、クラスタコンピュータミドルウェアについて説明する。

まず、第１の実施例によるクラスタコンピュータミドルウェア５００の構成を図３に示す。クラスタコンピュータミドルウェア５００は、アプリケーションインタフェース５０１と、分配統合制御手段５０２と、コンピュータインタフェース５０３とによって構成されている。このうち分配統合制御手段５０２には、セッション保持手段５０４と、セッション更新手段５０５が含まれており、これが本発明によるクラスタコンピュータミドルウェア５００の特徴となっている。

クラスタコンピュータミドルウェア５００は、通信ネットワークで結合された複数のモジュールから成り立っている分散型のソフトウェアである。それぞれのモジュールはそれぞれ別のコンピュータ１１０ａ〜１１０ｉにインストールされ、アプリケーション５１０からの指示３５０を受けて相互に通信を行い、これらのコンピュータ１１０ａ〜１１０ｉを協調動作させる。

アプリケーションインタフェース５０１は、アプリケーション５１０とリンクするためのインタフェースで、オペレーティングシステムごとに定められているライブラリ仕様に基づく。アプリケーション５１０から指示３５０を受けたり、アプリケーション５１０に通知３６０を送ったりするために、各種のルーチンやイベントを決まった形式でアプリケーション５１０に公開する、すなわち使用を可能にするものである。

分配統合制御手段５０２は、アプリケーション５１０から受けた指示３５０をコンピュータ１１０ａ〜１１０ｉに適切に分配したり、コンピュータ１１０ａ〜１１０ｉから個別に届く通知を統合して作成した通知３６０をアプリケーション５１０に送ったりするものである。

コンピュータインタフェース５０３は、通信ネットワーク１２０で接続された複数のコンピュータ１１０ａ〜１１０ｉに指示３３０を送ったり、コンピュータ１１０ａ〜１１０ｉから通知３４０を受けたりするためのインタフェースである。それぞれのコンピュータ１１０ａ〜１１０ｉには、オペレーティングシステムがインストールされている。オペレーティングシステムは各種のファンクションを公開しており、コンピュータインタフェース５０３はそれらを呼び出すことで、コンピュータ１１０ａ〜１１０ｉにデータを伝送させたり、処理を開始させたりすることができる。

セッション保持手段５０４は、クラスタコンピュータが現在どのセッションを実行しているかを記憶・保持するものである。セッションの考え方については、後で詳しく説明する。

セッション更新手段５０５は、アプリケーション５１０からの指示３５０や、コンピュータ１１０ａ〜１１０ｉからの通知３４０をトリガとして、セッション保持手段５０４が保持しているセッションを新しい値に遷移させるものである。

ここでクラスタコンピュータミドルウェア５００が導入する「セッション」について説明する。「セッション」とは、まとまった一連の処理であり、かつ次の二つの条件を満たすもののことを指す。
ａ．セッションの開始・終了の際には、それぞれアプリケーション５１０に通知３６０が送られる。
ｂ．二つのセッションの間には、前後関係・包含関係・無関係のいずれかの関係が規定されている。

クラスタコンピュータミドルウェア５００において、上記のように定義されたセッションは、図４に示すような性質を持つものとして扱われる。セッションはクラスタコンピュータミドルウェア５００が導入する仮想的な概念であり、その実体が存在する必要はない。しかしセッションの存在を前提にアプリケーションインタフェース５０１の仕様を規定すると、後述する新規な効果が得られる。

ここからは、セッションを定義している上記の二つの条件について詳述する。まずは開始通知と終了通知について説明する。開始通知とは、セッションが開始した直後に送られる通知３６０のことであり、終了通知とは、セッションが終了する直前に送られる通知３６０のことである。これらの通知３６０は、分配統合制御手段５０２から、アプリケーション５１０に送られる。終了通知は、処理によってエラーが発生しても必ず送られることが保証されている。この性質を利用すると、アプリケーション５１０は、現在どのセッションが実行されているかを確実に知ることができる。

これらの開始通知・終了通知は、実際には「イベント」として実装されている。イベントとは、特定の事象が発生した場合に、あらかじめ設定されたルーチンが実行される、ソフトウェアの仕組みである。クラスタコンピュータミドルウェア５００の場合には、セッションの開始と終了が事象に相当する。ルーチンであるイベントは引数を取ることができ、アプリケーション５１０はその値を調べたり変更したりすることができる。つまり開始イベント・終了イベントの引数を利用することで、アプリケーション５１０はセッションが実際に行った動作の内容を調べたり、セッションが行うべき動作の内容を変更したりすることができる。

次に、セッションの満たすべきもう一つの条件である、三つの関係について説明する。セッションＡがセッションＢに先行する（セッションＢがセッションＡに後続する）とは、セッションＡの終了通知が必ずセッションＢの開始通知の前に送られることを意味する。またセッションＡがセッションＢを含む（セッションＢがセッションＡに含まれる）とは、セッションＡの開始通知が必ずセッションＢの開始通知の前に送られ、セッションＡの開始通知が必ずセッションＢの開始通知の後に送られることを意味する。そしてセッションＡとセッションＢの間に関係がないとは、それらの開始通知・終了通知の送られる順番が決まっていないことを意味する。クラスタコンピュータミドルウェア５００では、任意の二つのセッションに対し、これらの三つの関係のいずれかが規定されている。すべての規定を考慮すると、クラスタコンピュータが行うべき処理は、所定の位相関係を持つ複数のセッションの組み合わせとして表される。これを「セッションの位相構造」と呼ぶ。こうしたセッションの位相構造は、個々のクラスタコンピュータミドルウェア５００に固有のものとして規定され、アプリケーション５１０にも公開される。アプリケーション５１０の設計では、セッションの位相構造のみを利用してアルゴリズムを検討する必要がある。

セッションの関係は、図５のように図形を使って表記することもできる。この方法ではセッション６００を長方形で示し、その位置関係によってセッション６００の関係を記述する。ここでは二つのセッションを取り上げ、それぞれ「セッションＡ（６００Ａ）」・「セッションＢ（６００Ｂ）」と呼ぶ。図形を使った表記では、前後関係を持つセッションＡ（６００Ａ）とセッションＢ（６００Ｂ）を（イ）のように上下に並べて表し、包含関係を持つセッションＡ（６００Ａ）とセッションＢ（６００Ｂ）を（ロ）のように入れ子にして表し、関係のないセッションＡ（６００Ａ）とセッションＢ（６００Ｂ）を（ハ）のように上下にずらしながら横に並べて表す。ここでは二つのセッション６００を例に挙げたが、セッション６００が三つ以上の場合にも同様の考え方で表記することができる。

図形を使うセッション６００の表記では、縦軸が時間の流れ、横軸が処理の行われる場所（コンピュータ１１０、または複数のコンピュータ１１０の組み合わせ）を表すと考えると理解しやすい。セッション６００の位相構造は、クラスタコンピュータミドルウェア５００を特徴付ける重要な性質である。図形を使ってセッションを表記する方法を開発支援ツールなどに応用すると、わかりやすく誤解されにくいユーザインタフェースを提供することができる。こうした用途においては、画面レイアウトの制約などにより、縦軸と横軸を入れ替えて配置したり、関係のないセッション６００を上下にずらさずに配置したりしても差し支えない。

クラスタコンピュータミドルウェア５００が規定するセッション６００の位相構造を図６に示す。またそれぞれのセッション６００で行われる処理は、図７に示すとおりである。
（１）Ｃｏｐｙセッション６０１
ノードにある一つのデータを、他のノードにコピーする。
（２）Ｄｅｌｅｔｅセッション６０２
ノードにある一つのデータを削除する。
（３）Ｓｅｎｄセッション６０３
マスタノードにあるデータを、スレーブノードにコピーする。
（４）Ｅｘｅｃｕｔｅセッション６０４
スレーブノードにタスクを実行させる。
（５）Ｒｅｃｅｉｖｅセッション６０５
スレーブノードにあるデータを、マスタノードにコピーする。
（６）Ｗａｓｔｅセッション６０６
スレーブノードにあるデータを削除する。
（７）Ｂａｔｃｈセッション６０７
一つのスレーブノードに分散処理をさせる。
（８）Ｄｅｌｉｖｅｒセッション６０８
マスタノードにあるデータを、すべてのスレーブノードにコピーする。
（９）Ｒａｃｅセッション６０９
すべてのスレーブノードに分散処理をさせる。
（１０）Ｃｌｅａｎセッション６１０
すべてのノードにあるデータを削除する。
（１１）Ｏｐｅｒａｔｅセッション６１１
クラスタコンピュータを動作させる。

なおここでは、ディスクの上にファイルとして保存されているデータと、特定のメモリ領域に格納されているデータを総称して「データ」と呼ぶ。またクラスタコンピュータを構成するマスタコンピュータ・スレーブコンピュータを総称して「ノード」と呼ぶ。

これらのセッション６００を開始・終了させるトリガには二つの種類がある。一つはアプリケーション５１０からの指示３５０、もう一つはコンピュータ１１０ａ〜１１０ｉからの通知３４０である。どちらの種類のトリガによってセッション６００が開始・終了するのかは、セッション６００の種類や、セッション６００の実行の有無によって決まる。たとえばＤｅｌｉｖｅｒセッション６０８を開始させるトリガは指示３５０であり、Ｄｅｌｉｖｅｒセッション６０８を終了させるトリガは通知３４０である。またＲａｃｅセッションを開始させるトリガは、Ｄｅｌｉｖｅｒセッション６０８の実行の有無に依存する。Ｄｅｌｉｖｅｒセッション６０８が実行される場合には通知３４０、実行されない場合には指示３５０がトリガとなる。Ｏｐｅｒａｔｅセッション６１１を開始させるトリガも指示３５０である。すなわちアプリケーション５１０からの指示３５０がなければ、一連の処理手順は開始されない。

セッションの開始イベント・終了イベントの引数は、個々のセッション６００ごとに規定されている。たとえばＣｏｐｙセッション６０１の開始イベントでは、コピーするデータのインデックスが引数として渡される。アプリケーション５１０は、この引数を（データが存在しないことを表す）０に書き換えることにより、コピーを中断させることもできる。またＣｏｐｙセッション６０１の終了イベントでは、実際にコピーされたデータのインデックスが引数として渡される。この値が０であった場合には、エラーが発生したために実際にはデータがコピーされなかったということである。このようにしてアプリケーション５１０は、セッション６００での処理が正しく行われたことを確認することもできる。複数のデータを扱うことのできるＳｅｎｄセッション６０３・Ｅｘｅｃｕｔｅセッション６０４・Ｒｅｃｅｉｖｅセッション６０５・Ｗａｓｔｅセッション６０６・Ｄｅｌｉｖｅｒセッション６０８・Ｃｌｅａｎ６１０セッションでは、データのインデックスの代わりに、複数のインデックスを格納することのできるリストが引数として渡される。アプリケーション５１０でこのリストにデータのインデックスを追加することで、複数のデータをすべてのスレーブノードに一括してコピーしたり、複数のノードにあるデータを一括して削除したりすることが可能になる。

以上のようなセッション６００の性質を踏まえると、先に説明を省略したセッション保持手段５０４とセッション更新手段５０５の動作が理解しやすくなる。そこでここからは、それらの動作について説明していくことにする。

セッション保持手段５０４は、クラスタコンピュータが現在どのセッション６００を実行しているかを記憶・保持するものである。セッション６００は階層的な包含関係を持っているので、セッション保持手段５０４は木（ツリー）構造の変数を使い、これに現在実行されているセッション階層を記憶させる。クラスタコンピュータミドルウェア５００の初期状態では、この変数にはセッション階層が記憶されておらず、すなわちセッション６００が実行されていないことを示している。

セッション更新手段５０５は、アプリケーション５１０からの指示３５０や、コンピュータ１１０ａ〜１１０ｉからの通知３４０をトリガとして、セッション保持手段５０４が保持しているセッション６００を新しい値に遷移させるものである。セッション６００がどのように遷移するかは、現在のセッション６００と、トリガである指示３５０・通知３４０によって決まる。

たとえば現在Ｄｅｌｉｖｅｒセッション６０８が実行されており、これにいくつかのＣｏｐｙセッション６０１が含まれているものとする。そこにコンピュータ１２０から「データコピー終了」の通知が送られてきた場合、セッション更新手段５０５はこのコンピュータ１２０に対応するＣｏｐｙセッション６０１を終了させ、セッション保持手段５０４からも削除する。この動作によってＣｏｐｙセッション６０１がすべて終了した場合には、Ｄｅｌｉｖｅｒセッション６０８を終了させ、セッション保持手段５０４からも削除する。そして続くＲａｃｅセッション６０９を開始させ、セッション保持手段５０４に追加する動作を行う。セッション６００の開始・終了の際には、先に述べたとおり、開始通知や終了通知がアプリケーション５１０に送られる。なお必要に応じ、通知３６０をシリアライズする（一つの通知３６０に対する処理がアプリケーション５１０で実行されている間には、次の通知３６０を送らない）ようにしてもよい。

このようにクラスタコンピュータミドルウェア５００では、アプリケーション５１０からの指示３５０やコンピュータ１１０からの通知３４０をトリガとして、本発明で新規に導入したセッションの概念に基づき、アプリケーション５１０に通知３６０を送る。アプリケーション５１０のプログラミングは、これらの通知３６０に対する処理を記述することによって行われる。

アプリケーション５１０の構成を図８に示す。アプリケーション５１０には、開始イベントハンドラ５１１と、開始イベントハンドラ５１２と、アドレス公開手段５１３が含まれている。

「イベントハンドラ」とは、イベントによって動作し、決められた処理を行うルーチンである。イベントハンドラは実際には関数や手続きなので、その形式とアドレスがわかれば呼び出すことができる。そこでアプリケーション５１０は、クラスタコンピュータミドルウェア５００がＯｐｅｒａｔｅセッション６１１の実行を開始する前に、クラスタコンピュータミドルウェア５００にイベントハンドラのアドレスを公開する。アドレス公開手段５１３は、これらのイベントハンドラのアドレス５２０を取得し、実際には関数や手続きとして実装される指示３５０に引数として追加する。イベントハンドラの形式はあらかじめ決められているので、クラスタコンピュータミドルウェア５００は、セッション６００の開始・終了に合わせ、開始イベントハンドラ５１１と終了イベントハンドラ５１２を実行させることができるようになる。

本発明のクラスタコンピュータにおいて、アプリケーション５１０とクラスタコンピュータミドルウェア５００が行う情報交換の内容を図９に示す。セッション開始指示３５１を受けてセッション開始通知３６１が出され、それに対する返答として処理Ａ・処理Ｂ・処理Ｃの実行が指示される。この図と、図２３に示された内容を比べると、クラスタコンピュータミドルウェア５００が、スレーブモジュールが処理を実行する順番を、アプリケーション５１０から隠蔽していることがわかる。アプリケーション５１０は、スレーブモジュールが実行する処理の順番を変えたり調べたりすることができない。またそのようなことをする必要性そのものがなくなっている。セッション開始通知３６１によって開始イベントハンドラ５１１が実行され、セッション処理内容指示３５２を自動的に送るので、セッション開始指示３５１を送った後のアプリケーション５１０は、セッション６００の終了、つまりセッション終了通知３６２が送られてくるのをただ単に待っているだけでよいのである。アプリケーション５１０のこのような動作は、セッションの位相構造が複雑であっても本質的には変わらない。

本発明によるクラスタコンピュータミドルウェア５００を使用して並列化したアプリケーションの、マスタモジュールのソースコードを図１０に模式的に示す。この図と、図２５に示したソースコードを比べると、先に指摘されていた従来のクラスタコンピュータミドルウェアの問題点の多くが本発明によって解消されたことがわかる。新しいソースコードは大幅に単純化されており、図２４に示した並列化する前のソースコードとの対応もさせやすくなっている。

以上のように、クラスタコンピュータミドルウェア５００を使うことにより、次の新規な効果が得られる。

（１）エラーが発生した場合には、セッション保持手段５０４が保持している現在のセッション６００をアプリケーション５１０に通知することができる。そのためアプリケーション５１０から見ると、エラーの発生した部位を容易に推定することができるようになり、体系的なデバッグに役立つ。

（２）複数のコンピュータ１１０ａ〜１１０ｉから非同期的に発生する多数の通知３４０が統合されてアプリケーション５１０に送られる。そのためアプリケーション５１０には、それぞれのセッション６００に対して行うべき処理を記述すればよく、またセッション６００の実行される順番で書き下ろすことができる。また通知３６０を待つループを書く必要がなくなるので、ソースコードの可読性が高まる。

（３）セッションの前後関係・包含関係を変更せずに、並列処理の実行順序を見直し、ミドルウェアを改良していくことができる。アプリケーション５１０は、セッション６００の前後関係・包含関係のみを利用して設計されているので、ミドルウェアを改良しても正しく動作することが保証される。

（４）並列処理の手順が大きく変わっても、アプリケーション５１０では開始通知・終了通知に対する処理を書き換えるだけである。そのため並列化するべき処理がたくさんある場合でも、それぞれの処理を類似の構造で書くことができ、ソースコードの管理が非常に容易になる。

（５）個々のコンピュータの動作タイミングについて考慮する必要がないので、ミドルウェアと同じセッション６００の仕様を持つシミュレータを作ることができる。このシミュレータを使うことで、クラスタコンピュータを用意しなくても、並列処理を行うアプリケーションを開発することができる。

（６）メイン処理からの指示があっても、すぐにサブ処理の実行が始まるとは限らない。したがってメイン処理は、サブ処理を実行するタイミングを管理する責任から解放される。サブ処理の管理をミドルウェアに任せるようにすれば、アプリケーションがきわめて簡単なものになる。

実施例２と実施例３では、実施例１で説明したクラスタコンピュータミドルウェア５００を活用するシステムを取り上げ、具体的なアプリケーション５１０を作成する方法について説明する。実施例２では天気図作成システム７００を、実施例３では３次元画像処理システム８００を例に取り上げる。

始めに本発明を天気図作成システムに応用した実施例を説明する。

図１１に、本発明によるクラスタコンピュータミドルウェア５００を利用する、天気図作成システム７００の構成を示す。天気図作成システム７００は、天気図作成アプリケーション７０１とクラスタコンピュータ１００によって構成されており、地形データ７１１と地方別気象データ７１２ａ〜７１２ｈをもとに全国の天気図７２０を作成する機能を持つ。クラスタコンピュータ１００は、本発明によるクラスタコンピュータミドルウェア５００を使って構成されている。

天気図作成システム７００では、処理に要する時間を短縮するため、地方別に天気図７２０を作成した後、それらをつなぎ合わせて全国の天気図７２０を作成する。地方別の天気図７２０を作成するには、地形データ７１１と、その地方に対応する地方別気象データ７１２が必要である。すなわちクラスタコンピュータ７０２を構成するスレーブノードには、マスタノードからこれらのデータを分配しなければならない。

地形データ７１１と地方別気象データ７１２ａ〜７１２ｇのうち、地形データ７１１は時間とともに変化することのないデータなので、システムを立ち上げた時にそれぞれのスレーブノードに分配しておけばよい。しかし地方別気象データ７１２ａ〜７１２ｇは、時々刻々と変化するデータなので、処理のたびに最新のデータを分配する必要がある。このように一部の素材データを削除せずに残しておくような処理手順を採用することで、この素材データをスレーブノードに分配するのに必要な時間を省くことができる。

以上のような処理手順を実現するには、図６や図７に示したセッション６００の開始・終了イベントに対し、アプリケーションを次のように動作させればよい。
（１）Ｄｅｌｉｖｅｒセッションの開始イベント
すでに地形データ７１１がスレーブノードに分配されているかどうかを調べ、分配されていなければ、地形データ７１１をそれぞれのスレーブノードにコピーするように指示する。
（２）Ｂａｔｃｈセッションの開始イベント
地方別気象データ７１２ａ〜７１２ｇを、それぞれのスレーブノードにコピーするように指示する。
（３）Ｒｅｃｅｉｖｅセッションの開始イベント
地方別の天気図７２０をマスタノードにコピーするように指示する。
（４）Ｒｅｃｅｉｖｅセッションの終了イベント
マスタノードにコピーされた地方別の天気図７２０から、全国の天気図７２０を作成する。
（５）Ｗａｓｔｅセッションの開始イベント
地方別気象データ７１２と地方別の天気図７２０を削除するように指示する。

以上のようにクラスタコンピュータミドルウェア５００を使用すると、五つのイベントに対する処理を記述するだけで、簡単に上記の並列処理手順を実装することができる。

次に本発明を３次元画像処理システムに応用した例について説明する。

図１２に、本発明によるクラスタコンピュータミドルウェア５００を利用する、３次元画像処理システム８００の構成を示す。３次元画像処理システム８００は、３次元画像処理アプリケーション８０１とクラスタコンピュータ１００によって構成されており、３次元形状データ８１１にレンダリング条件８１２を適用して表示用のレンダリング画像８２０を作成する機能を持つ。クラスタコンピュータ１００は、本発明によるクラスタコンピュータミドルウェア５００を使って構成されている。

３次元画像処理システム８００では、処理に要する時間を短縮するため、表示領域を分割してレンダリングを行う。この処理には、３次元形状データ８１１とレンダリング条件８１２が必要である。すなわちクラスタコンピュータ８０２を構成するスレーブノードには、マスタノードから３次元形状データ８１１を分配してから、レンダリング条件８１２を伝え、さらにスレーブノードごとに異なる表示領域を指示して処理をさせることになる。すべてのスレーブノードの負荷を均一にするには、表示領域の分割を、スレーブノードの数に対して充分に細かくしておくことが望ましい。そのためスレーブノードで処理が終了したら、マスタノードはすぐ次の表示領域をスレーブノードに指示し、次の処理をさせるように動作しなければならない。

以上のような処理手順を実現するには、図６や図７に示したセッション６００の開始・終了イベントに対し、アプリケーションを次のように動作させればよい。
（１）Ｄｅｌｉｖｅｒセッションの開始イベント
３次元形状データ８１１をすべてのスレーブノードにコピーするように指示する。
（２）Ｅｘｅｃｕｔｅセッションの開始イベント
Ｂａｔｃｈセッションの番号に対応する表示領域を求め、レンダリング条件８１２とともにスレーブノードに伝えるよう指示する。
（３）Ｒｅｃｅｉｖｅセッションの開始イベント
分割されたレンダリング画像８２０をマスタノードにコピーするように指示する。
（４）Ｒｅｃｅｉｖｅセッションの終了イベント
マスタノードにコピーされた、分割されたレンダリング画像３２０から、一つのまとまったレンダリング画像８２０を合成する。
（５）Ｗａｓｔｅセッションの開始イベント
分割されたレンダリング画像８２０を削除するように指示する。
（６）Ｃｌｅａｎセッションの開始イベント
すべてのスレーブノードにコピーされた３次元形状データ８１１を削除するように指示する。

以上のようにクラスタコンピュータミドルウェア５００を使用すると、六つのイベントに対する処理を記述するだけで、簡単に上記の並列処理手順を実装することができる。

さらに天気図作成システム７００と３次元画像処理システム８００では、並列処理手順が異なるにもかかわらず、アプリケーション５１０はいずれも、セッションの開始・終了イベントに対する処理の集まりとして記述される。このようにソースコードの書き方が並列処理手順に依存しなくなることも、クラスタコンピュータミドルウェア５００を使用する利点である。

次に、本発明を応用したクラスタコンピュータシミュレータについて説明する。

本発明によるクラスタコンピュータシミュレータ９００の構成を図１３に示す。本発明によるクラスタコンピュータシミュレータ９００を構成する要素の多くは、クラスタコンピュータミドルウェア５００と共通するものである。しかし１台のコンピュータで動作するクラスタコンピュータシミュレータ９００では、実際のコンピュータ１１０の代わりにコンピュータシミュレータ９１０ａ、９１０ｂ〜９１０ｉが使用されている。スレーブコンピュータやスレーブモジュールに関係する要素も除去されている。またコンピュータインタフェース５０３の代わりにコンピュータシミュレータインタフェース９０３が使用され、通信ネットワーク１２０を経由して送られる指示３３０と通知３４０の代わりに、通信を伴わない模擬的な指示３７０と模擬的な通知３８０が使用されている点も異なる。しかしクラスタコンピュータシミュレータ９００とクラスタコンピュータミドルウェア５００では、セッションの位相構造とアプリケーションインタフェース５１０が同一である。したがってクラスタコンピュータシミュレータ９００とリンクして正しく動作するアプリケーション５１０は、クラスタコンピュータミドルウェア５００とリンクしても正しく動作することが保証されている。

コンピュータシミュレータ９１０は、個々のコンピュータ１１０の動作を模擬するシミュレータで、独立に動作する複数のコンピュータ１１０の動作を正確に模擬するため、それぞれ独立したスレッド（プログラムの内部で同時に実行することのできる処理の単位）として実装されている。

クラスタコンピュータシミュレータ９００の画面の一例を図１４に示す。この画面には、ＩＰアドレスが表示された複数の円形が表示されており、それぞれがコンピュータシミュレータ９１０に対応している。コマンドメニュー１００１を操作すると、円形を追加・削除したりＩＰアドレスを変えたりすることができ、実際に使用するクラスタコンピュータと同じ構成を作ることができる。

クラスタコンピュータシミュレータ９００が動作している時には、それぞれのコンピュータシミュレータ９１０の状態によって画面がリアルタイムに変化する。細い輪郭の円形１０１０は、休止中のコンピュータシミュレータ９１０を、太い輪郭の円形１０１１は、処理実行中のコンピュータシミュレータ９１０を表している。また矢線１０１２はデータのコピーを表している。

円形をマウスでクリックすると、コンピュータシミュレータ９１０が保持しているデータ（ファイル・メモリ）を表示させることができる。この機能を使うと、スレーブコンピュータが処理を開始する前に必要なデータが正しく配布されたかどうか、一連の処理が終わった時点で不要なデータが残されていないかどうかを確認することができ、信頼性の高いアプリケーション５１０の開発に役立つ。

本発明の第５の実施例になる、クラスタコンピュータミドルウェアについて説明する。

第５の実施例において、クラスタコンピュータ１００を構成している、マスタコンピュータ１１０ａとスレーブコンピュータ１１０ｂ〜１１０ｉの内部の構成を図１５に模式的に示す。マスタコンピュータ１１０ａとスレーブコンピュータ１１０ｂ〜１１０ｉには、それぞれクラスタコンピュータミドルウェア１２００とアプリケーション１３００が、マスタモジュールとスレーブモジュールに分割されてインストールされている。これらのコンピュータ１１０はそれぞれ、ネットワークインタフェース１１１と、メモリ１１２と、ディスク１１３を備えている。ディスク１１３には、クラスタコンピュータミドルウェア１２００と、アプリケーション１３００が格納されている。これらはメモリ１１２にロードされ、相互にリンクして動作する。ネットワークインタフェース１１１は、マスタコンピュータ１１０ａとスレーブコンピュータ１１０ｂ〜１１０ｉを、ネットワーク１２０を介して相互に接続する。そのため任意のコンピュータ１１０の間でデータ通信が可能である。なお以下の記述では、誤解が生じないと思われる場合に限り、「マスタ」・「スレーブ」という表記を適宜省略する。

クラスタコンピュータミドルウェア１２００とアプリケーション１３００の内部の論理的構成を図１６に示す。クラスタコンピュータミドルウェア１２００の、マスタモジュール１２００ａとスレーブモジュール１２００ｂ〜１２００ｉは、それぞれ通信手段１２２０と、データコピー手段１２３０と、データ消去手段１２４０と、イベント発生手段１２５０を共通して備えている。またマスタモジュール１２００ａに限り、スケジューラ１２１０と、割り込み受理手段１２６０を備えている。

スケジューラ１２１０は、あらかじめ決められた処理手順に従い、データコピー手段１２３０や、データ消去手段１２４０や、イベント発生手段１２５０に指示を送る機能を持つ。これによって実際に、データのコピー、データの消去、イベントの発生が行われる。

通信手段１２２０は、スケジューラ１２１０から送られてくる指示、およびメモリ１１２やディスク１１３に格納されているメモリブロックやファイルのデータを、他のコンピュータに伝送するものである。これは通常、オペレーションシステム（ＯＳ）が提供するソケット通信の仕組みによって実装される。

データコピー手段１２３０は、スケジューラ１２１０から送られてくる指示を受け、メモリブロックやファイルのデータをコピーする機能を持つ。データのコピーを他のコンピュータに行う場合、通信手段１２２０を間接的に使用してデータを伝送する。これは通常、ＯＳが提供するディスク操作やメモリ操作の仕組みによって実装される。

データ消去手段１２４０は、スケジューラ１２１０から送られてくる指示を受け、メモリブロックやファイルのデータを消去する機能を持つ。これは通常、ＯＳが提供するディスク操作やメモリ操作の仕組みによって実装される。

イベント発生手段１２５０は、スケジューラ１２１０から送られてくる指示を受け、あらかじめアプリケーション１３００が設定したルーチンを実行する機能を持つ。このルーチンは「イベントハンドラ」と呼ばれる。これは通常、ＯＳが提供するルーチンコールバック（アプリケーションの機能をライブラリから使うこと）の仕組みによって実装される。イベントハンドラでは、データの作成・変換を含む任意の処理を行うことができる。またイベントハンドラの引数に、スケジューラ１２１０が備えている操作対象データリスト１２１２を渡すことも可能である。操作対象データリスト１２１２は、クラスタコンピュータミドルウェア１２００によってコピーあるいは消去されるデータ、もしくはコピーあるいは消去されたデータのリストである。アプリケーション１３００は操作対象データリスト１２１２に対し、データを識別するためのインデックス（メモリブロックのアドレス、ファイルの名前など）を追加したり、削除したりすることができる。クラスタコンピュータミドルウェア１２００では、実際にデータのコピーや消去が行われるタイミングをアプリケーション１３００から制御することができない。つまりアプリケーション１３００でデータのコピー・消去を制御・監視するには、イベントハンドラの中で操作対象データリスト１２１２を使い、操作対象となるデータを事前に設定したり、操作対象となったデータを事後に取得したりする方法を使わなければならない。イベントの発生するタイミングは、スケジューラ１２１０に任せられているが、各種のイベントが発生する順番を体系的に整理して理解しやすくするには、たとえば第１の実施例に記載したようなセッション６００の考え方を導入し、その開始と終了の際にイベントが発生するものと規定してもよい。

割り込み受理手段１２６０は、処理完了率の取得や処理の中断など、非同期的な処理の要求を受け付け、スケジューラ１２１０に知らせる機能を持つ。

アプリケーション１３００の、マスタモジュール１３００ａとスレーブモジュール１３００ｂ〜１３００ｉは、共通してイベントハンドラ設定手段１３１０を備えている。またアプリケーション１３００のマスタモジュール１３００ａに限り、割り込み要求手段１３２０を備えている。

イベントハンドラ設定手段１３１０は、イベント発生手段１２５０の動作によって実行される、イベントハンドラを設定する機能を持つ。これは通常、ＯＳが提供するルーチンコールバックの仕組みによって実装される。

割り込み要求手段１３２０は、処理完了率の取得や処理の中断など、非同期的な処理をスケジューラ１２１０に要求する機能を持つ。これは通常、ＯＳが提供するルーチンエクスポート（ライブラリの機能をアプリケーションから使うこと）の仕組みによって実装される。処理完了率の取得は通常、ＯＳが提供するタイマによって行われる。また処理の中断は通常、ユーザの操作によって行われる。

以上の構成により、クラスタコンピュータ１００では、スケジューラ１２１０が個々のコンピュータ１１０におけるデータのコピー、データの消去、イベントの発生を集中的に制御することができる。これらの三つの操作は、さまざまな並列処理を実現する要素となるものである。あらゆる並列処理は、これらの要素的な操作の組み合わせによって実現することができる。つまりクラスタコンピュータ１００が正しく動作するかどうかは、スケジューラ１２１０がスケジューリングを正しく行うかどうかに依存する。

スケジューラ１２１０の動作（スケジューリング）を支配する処理手順１４００の例を図１７に示す。処理手順１４００は、階層的にいくつかの部分に分けられている。それぞれの部分で行われる処理は次のとおりである。
（１）Ｃｏｐｙ部分１４０１
ノードにある一つのデータを、他のノードにコピーする。
（２）Ｄｅｌｅｔｅ部分１４０２
ノードにある一つのデータを削除する。
（３）Ｓｅｎｄ部分１４０３
マスタノードにあるデータを、スレーブノードにコピーする。
（４）Ｅｘｅｃｕｔｅ部分１４０４
スレーブノードにタスクを実行させる。
（５）Ｒｅｃｅｉｖｅ部分１４０５
スレーブノードにあるデータを、マスタノードにコピーする。
（６）Ｗａｓｔｅ部分１４０６
スレーブノードにあるデータを削除する。
（７）Ｂａｔｃｈ部分１４０７
一つのスレーブノードに分散処理をさせる。
（８）Ｄｅｌｉｖｅｒ部分１４０８
マスタノードにあるデータを、すべてのスレーブノードにコピーする。
（９）Ｒａｃｅ部分１４０９
すべてのスレーブノードに分散処理をさせる。
（１０）Ｃｌｅａｎ部分１４１０
すべてのノードにあるデータを削除する。
（１１）Ｏｐｅｒａｔｅ部分１４１１
クラスタコンピュータ１００を動作させる。

なおここでは、スケジューラ１２１０が管理しているコンピュータ１１０のことを「ノード」と呼ぶ。スケジューラ１２１０は、マスタコンピュータ１１０ａで動作しながら、後述するノードリスト１５１０を使用することにより、マスタノードとスレーブノードの両方を一元的に管理している。

スケジューラ１２１０はスケジューリングを行うにあたり、データ配置テーブル１２１２とノード属性テーブル１２１３を使用する。

データ配置テーブル１２１２は、たとえば図１８に示すデータ構造により、個々のコンピュータ１１０が保持しているデータを把握・管理する機能を持つ。ノードリスト１５１０は、クラスタコンピュータ１００に含まれるコンピュータ１１０のリストであり、それぞれのコンピュータ１１０に対応する要素である、ノードを保持している。それぞれのノードはデータリスト１５２０を保持している。データリスト１５２０は、コンピュータ１１０が保持しているデータ（メモリブロック・ファイル）のリストである。

データ配置テーブル１２１２は、スケジューラ１２１０がデータをコピーさせたり、消去させたりするたびに自動的に更新される。そのためスケジューラ１２１０は、データ配置テーブル１２１２を参照することで、その時点でのデータの配置状況を知ることができる。

ノード属性テーブル１２１３は、たとえば図１９に示すデータ構造により、個々のコンピュータ１１０（ノード）に関する属性１５３０や、状態１５４０を把握・管理する機能を持つ。ノードの属性１５３０には、次のようなものが含まれる。
（１）ＩＰアドレス
（２）処理速度の計測値
またノードの状態１５４０には、次のようなものが含まれる。
（３）処理中かどうか（イベントハンドラを実行しているかどうか）
（４）通信中かどうか（ネットワークを使用しているかどうか）
（５）故障中かどうか
ノード属性テーブル１２１３に保持されるノードの状態１５４０も、スケジューラ１２１０の動作（スケジューリング）に伴って更新される。そのためスケジューラ１２１０は、ノード属性テーブル１２１３を参照することで、その時点でのノードの状態１５４０を知ることができる。

次にスケジューラ１２１０がスケジューリングを行う際、どのようにデータ配置テーブル１２１２とノード属性テーブル１２１３を使用するかを説明する。ここでは処理手順１４００を例に、次の六つの場合について説明する。
（１）データの一括配布（Ｄｅｌｉｖｅｒ部分１４０８の実行）
（２）データの一括消去（Ｃｌｅａｎ部分１４１０の実行）
（３）分散処理（Ｒａｃｅ部分１４０９の実行）
（４）処理完了率の取得
（５）処理の中断
（６）スレーブコンピュータ１１０ｂ〜１１０ｉの故障。

（１．データの一括配布）
Ｄｅｌｉｖｅｒ部分１４０８では、操作対象データリスト１２１１に含まれているデータを、マスタノードからすべてのスレーブノードにコピーする。この動作を実現するため、スケジューラ１２１０はデータ配置テーブル１２１２を参照し、そのデータを保持しているノードと保持していないノードを、それぞれ一つずつ選定する。この選定には乱数を使ってもよいし、コンピュータ１１０がネットワーク１２０に接続されているトポロジを利用してもよい。たとえば複数のハブを含む木構造のトポロジを持つネットワーク１２０では、ハブを結ぶ伝送路の通信量が他の伝送路に比べて非常に大きくなる傾向がある。そこでハブの経由数の大きい、つまり送信元のノードから位相的に離れているノードに対して優先的にデータをコピーするようにすると、ハブを結ぶ伝送路には一度だけしかデータが通さないようになるので、システムの性能が向上する。

現在の状態が処理中あるいは通信中のノードは、データの送受信を行うことができない。そこでスケジューラ１２１０は、ノード属性テーブル１２１３を参照することで、これらのノードの使用を避けるようにする。データの送信元のノードと受信先のノードが決まった時点で、スケジューラ１２１０は送信元のノードに対し、受信元のノードにデータを送るように指示する。データのコピーが始まったら、ノード属性テーブル１２１３を更新し、送信元のノードと受信先のノードの状態を通信中に変える。データのコピーが終わったら、これらのノードの状態をもとに戻す。こうしてすべてのノードがそのデータを保持するようになるまで、上記の作業を繰り返す。

（２．データの一括消去）
Ｃｌｅａｎ部分１４１０では、それぞれのノードに保持されているデータを消去する。この動作を実現するため、スケジューラ１２１０はノードを選定した上で、データ配置テーブル１２１２を参照し、そのノードが保持しているデータの一覧を取得する。その後ノードに対し、それぞれのデータを消去するように指示する。こうした作業をすべてのノードに対して行う。

（３．分散処理）
Ｒａｃｅ部分１４０９では、本来行うべき処理の全体を細かく分割した部分的な処理（タスク）を、それぞれのスレーブノードに実行させる。アプリケーション１３００のスレーブモジュール１３００ｂ〜１３００ｉでは、個々のタスクをイベントハンドラとしてあらかじめ設定しておく。そのためスケジューラ１２１０の動作は、現在の状態が処理中でも通信中でもないノードを見つけ、イベントを発生させるように指示する動作になる。ノードの状態を把握するには、ノード属性テーブル１２１３を参照する。使用可能なノードが見つかった場合、その中から一つを選定する。この選定には乱数を使ってもよいし、個々のノードの処理速度の計測値がわかっている場合には、最後近くのタスクに対し、処理速度の遅いノードを割り当てないような方法を採ってもよい。最後のタスクを遅いノードに実行させると、それがシステム全体を待たせてしまい、性能を低下させるからである。ノードがイベントハンドラを実行し始めたら、スケジューラ１２１０はノード属性テーブル１２１３を更新し、ノードの状態を処理中に変える。またイベントハンドラを実行し終えたら、ノードの状態をもとに戻す。こうして分割されたすべてのタスクが実行されるまで、上記の作業を繰り返す。

（４．処理完了率の取得）
処理完了率の取得では、個々のタスクについて完了率を求め、それらの平均を算出する。ノード属性テーブル１２１３を参照することで、現在タスクを実行しているノードを知ることができる。アプリケーション１３００のスレーブモジュール１３００ｂ〜１３００ｉでは、タスクの完了率を求めるイベントハンドラを用意し、あらかじめ設定しておくことができる。そのためタスクを実行しているノードを知ったスケジューラ１２１０は、そのノードに対してイベントを発生させるように指示し、タスクの完了率を知ることができる。こうしてすべてのタスクに対して同様の操作を行い、最終的に平均を求めて、アプリケーション１３００の割り込み要求手段１３２０に返す。

（５．処理の中断）
処理の中断では、実行中のすべてのタスクを中断させるとともに、配布された一時的なデータを消去しなければならない。タスクの中断についてスケジューラ１２１０は、ノード属性テーブル１２１３を参照することで、現在タスクを実行しているノードを知ることができる。アプリケーション１３００のスレーブモジュール１３００ｂ〜１３００ｉでは、タスクを中断させるイベントハンドラを用意しておくこともできる。すなわちスケジューラ１２１０は、タスクを実行しているすべてのノードに対し、イベントを発生させるように指示すればよい。

また一時的なデータをすべて消去するには、データ配置テーブル１２１２を参照して一時的なデータの一覧を取得した上で、そのデータを保持しているノードに対し、それらのデータを消去させるように指示すればよい。

（６．スレーブコンピュータ１１０ｂ〜１１０ｉの故障）
スレーブコンピュータ１１０ｂ〜１１０ｉのいずれかが故障した場合、ノード属性テーブル１２１３を更新し、故障したノードの状態を故障中に変える。これによってスケジューラ１２１０は、故障したノードの使用を避ける。その上で、故障したノードで実行されたタスクを、故障していない他のスレーブノードで再実行させる。タスクの再実行は、そのタスクを含むＢａｔｃｈ部分１４０７を再び実行させることで行うことができる。

クラスタコンピュータミドルウェア１２００は、アプリケーション１３００に対し、スケジューラ１２１０の動作を開始させるためのルーチンをエクスポートしている。そのためアプリケーション１３００は、任意のタイミングでスケジューラ１２１０の動作を開始させることができる。しかし、ひとたびスケジューラ１２１０が動作を開始すると、制御はスケジューラ１２１０に移るので、その動作が終了するまで制御はアプリケーション１３００に戻らない。

クラスタコンピュータミドルウェア１２００とアプリケーション１３００の間で、時間とともに制御が移動する様子を図２０に示す。ここでは「シーケンシャル」と「イベントドリブン」という語句を使用するが、これらの語句の定義については後述することにして、まずは説明を先に述べる。初期状態ではアプリケーション１３００が制御を持っている。アプリケーション１３００は、「シーケンシャル」に前処理１６１０を実行した後、並列処理１６２０も同じく「シーケンシャル」に開始させる。これによってスケジューラ１２１０の動作（スケジューリング１６４０）が開始される。並列処理１６２０の実際の処理は、スケジューラ１２１０の動作が終了するのを待ちながら、その間にイベントが発生したら、それに対応するイベントハンドリング１６４１・１６４２・１６４３を実行する処理である。すなわちイベントハンドリング１６４１・１６４２・１６４３は、スケジューリング１６４０の進行に伴い、「イベントドリブン」に実行される。最終的に処理手順が完了し、スケジューラ１２１０の動作が終了すると、制御は再びアプリケーション１３００に戻され、並列処理１６２０に続く後処理１６３０が「シーケンシャル」に実行される。

ここで「シーケンシャル」とは、プログラムに書かれたとおりのタイミングで実行される、あるいはソースコードから予測される順番で実行されることを意味する。これに対して「イベントドリブン」とは、必ずしもプログラムに書かれたとおりのタイミングで実行されない、あるいはソースコードから予測することのできない順番で実行されることを意味する。これらの区別は、アプリケーション１３００のソースコードを見るとわかりやすい。ソースコードについては後述する。

実際のクラスタコンピュータミドルウェア１２００とアプリケーション１３００は、それぞれマスタモジュールとスレーブモジュールに分割されているので、制御が移動する様子は図２０よりも実際には複雑で、図２１のようになる。ここで注意する必要があるのは、複数のコンピュータ１１０で構成されるクラスタコンピュータ１００では、イベントハンドリング１６４１〜１６４７のうちのいくつかがまったく同時に終了する可能性があるということである。そこでスケジューラ１２１０には、同時に受け取った終了通知を時系列的に並べ替える（シリアライズする）手段を設ける必要がある。これはたとえば、待ち行列（キュー）やＦＩＦＯバッファを使って実現することができる。

またスケジューリング１６４０の方法によっては、必ずしも分割されたタスクの順番でイベントハンドリング１６４１〜１６４７が実行されるとは限らない。そこでスレーブコンピュータ１１０ｂ〜１１０ｉに、それぞれが実行するべきタスクの内容を伝えるため、イベントハンドラにはタスクを識別するための番号を引数として渡すようになっている。

アプリケーション１３００のマスタモジュール１３００ａのソースコードを図２２に示す。前処理１６１０と、並列処理１６２０と、後処理１６３０は、シーケンシャルに実行される処理なので、ソースコードの上でもメインルーチン１７１０に連続して記述されている。これに対してイベントハンドリング１６４１・１６４２・１６４３は、イベント発生をトリガとして実行されるので、必ずしもソースコードの上に記述されている、イベントハンドラ１７２１・１７２２・１７２３の順番で実行されるとは限らない。イベント発生の順番は、スケジューラ１２１０が実際に動作した結果として決まってくる。それはスケジューラ１２１０の動作を支配している処理手順、コンピュータ１１０の台数や接続方法、コンピュータ１１０の性能のばらつき、割り込み処理の要求の有無、内部で使用している乱数の偶然性など、いろいろな要因によって動的に変化するものである。

このように、本実施例によるクラスタコンピュータミドルウェア１２００における並列処理は、メインルーチン１７１０をブロックして（一時停止させて）動作するスケジューリングと、メインルーチン１７１０に対して非同期的に動作する複数のイベントハンドラ１７２１・１７２２・１７２３の組み合わせとして実現されている。

このことは「アプリケーション１３００が、イベントドリブンに実行される処理（イベントハンドリング）のみで、並列処理を実装しなければならない」ことを意味する。これはアプリケーション１３００に対し、一種の制約を課すことになる。しかしこの制約を遵守することで、クラスタコンピュータ１００の実際の構成がアプリケーション１３００から隠される。その結果、アプリケーション１３００の開発者は、次の効果を享受することができる。

（１）アプリケーション１３００に、個々のコンピュータ１１０を管理したり、スケジューリングを行ったりする仕組みを実装する必要がなくなるので、アプリケーション１３００の移植・開発が容易になる。

（２）アプリケーション１３００が、コンピュータ１１０の台数やネットワーク１２０の種類に依存しなくなる。そのためアプリケーション１３００を、不特定多数のユーザに配布して使用させることができるようになる。

（３）アプリケーション１３００が行うべき並列処理を、形式の揃ったイベントハンドラの集合として記述することができるので、ソースコードが読みやすくなる。またイベントハンドラの処理内容を変えれば、さまざまな並列処理を記述することもできる。すなわちソースコードの可読性と、処理手順の自由度を両立させることができる。

（４）アプリケーション１３００がスケジューラ１２１０の処理手順に依存しなくなるので、将来の上位互換性が保証される。スケジューラ１２１０が改良されても、アプリケーション１３００を修正する必要がなくなる。

（５）現在イベントハンドリングを行っているコンピュータ１１０や、個々のコンピュータ１１０に保持されているデータを、スケジューラ１２１０が知ることができる。そのため処理完了率の取得や、処理の中断といった割り込み処理の要求に対し、スケジューラ１２１０が個々のコンピュータ１１０に対して適切な指示を自動的に割り振ることができる。そのためこのような仕組みをアプリケーション１３００に実装する必要がなくなる。

（６）クラスタコンピュータ１００と同一の処理手順のスケジューラ１２１０を持つクラスタシミュレータを用意すれば、実際にクラスタコンピュータ１００を用意しなくても、アプリケーション１３００を動作させることができる。そのためアプリケーション１３００のチーム開発・先行開発や、マスタモジュール１３００ａとスレーブモジュール１３００ｂ〜１３００ｉのクロスデバッグが可能になる。

以上のとおり、本発明の実施例５によれば、マスタモジュールとスレーブモジュールから構成されるクラスタコンピュータミドルウェアに、アプリケーションの処理を一時的にブロックして動作するスケジューラと、スケジューラからの指示を受けてアプリケーションが事前に設定したイベントハンドラを実行する手段を備えている。これにより、多大な費用・労力や高度な知識・技術を必要とせず、並列アプリケーションを開発することのできる環境を提供することができる。また高い拡張性と上位互換性を持つ並列アプリケーションを開発することのできる環境を提供することができる。

１００クラスタコンピュータ
１１０コンピュータ
１１０ａ（マスタ）コンピュータ
１１０ｂ〜１１０ｉ（スレーブ）コンピュータ
１１１ネットワークインタフェース
１１２メモリ
１１３ディスク
１２０通信ネットワーク
１３１ディスプレイ
１３２キーボード
１３３マウス
２１０素材データ
２２０結果データ
２２１結果データ（断片）
３１０（個別に送られる、アプリケーションから分配統合制御手段への）指示
３２０（個別に送られる、分配統合制御手段からアプリケーションへの）通知
３３０（分配統合制御手段からコンピュータへの）指示
３４０（コンピュータから分配統合制御手段への）通知
３５０（アプリケーションから分配統合制御手段への）指示
３５１セッション開始指示
３５２セッション処理内容指示
３６０（分配統合制御手段からアプリケーションへの）通知
３６１セッション開始通知
３６２セッション終了通知
３７０（分配統合制御手段からコンピュータシミュレータへの）模擬的な指示
３８０（コンピュータシミュレータから分配統合制御手段への）模擬的な通知
４１０グローバル変数
４２０（通知３２０をトリガとして実行される）処理ブロック
４３０（特定の処理をトリガとして実行される）処理ブロック
５００クラスタコンピュータミドルウェア
５００Ｍクラスタコンピュータミドルウェア（マスタモジュール）
５００Ｓクラスタコンピュータミドルウェア（スレーブモジュール）
５０１アプリケーションインタフェース
５０２分配統合制御手段
５０３コンピュータインタフェース
５０４セッション保持手段
５０５セッション更新手段
５１０アプリケーション
５１０Ｍアプリケーション（マスタモジュール）
５１０Ｓアプリケーション（スレーブモジュール）
５１１開始イベントハンドラ
５１２終了イベントハンドラ
５１３アドレス公開手段
５２０アドレス
６００、６００Ａ、６００Ｂセッション
６０１Ｃｏｐｙセッション
６０２Ｄｅｌｅｔｅセッション
６０３Ｓｅｎｄセッション
６０４Ｅｘｅｃｕｔｅセッション
６０５Ｒｅｃｅｉｖｅセッション
６０６Ｗａｓｔｅセッション
６０７Ｂａｔｃｈセッション
６０８Ｄｅｌｉｖｅｒセッション
６０９Ｒａｃｅセッション
６１０Ｃｌｅａｎセッション
６１１Ｏｐｅｒａｔｅセッション
７００天気図作成システム
７０１天気図作成アプリケーション
７１１地形データ
７１２、７１２ａ〜７１２ｈ地方別気象データ
７２０天気図
８００３次元画像処理システム
８０１３次元画像処理アプリケーション
８１１３次元形状データ
８１２レンダリング条件
８２０レンダリング画像
９００クラスタコンピュータシミュレータ
９０３コンピュータシミュレータインタフェース
９１０コンピュータシミュレータ
９１０ａ（マスタ）コンピュータシミュレータ
９１０ｂ〜９１０ｉ（スレーブ）コンピュータシミュレータ
１００１コマンドメニュー
１０１０細い輪郭の円形
１０１１太い輪郭の円形
１０１２矢線
１２００クラスタコンピュータミドルウェア
１２００ａクラスタコンピュータミドルウェアのマスタモジュール
１２００ｂ〜１２００ｉクラスタコンピュータミドルウェアのスレーブモジュール
１２１０スケジューラ
１２１１操作対象データリスト
１２１２データ配置テーブル
１２１３ノード属性テーブル
１２２０通信手段
１２３０データコピー手段
１２４０データ消去手段
１２５０イベント発生手段
１２６０割り込み受理手段
１３００アプリケーション
１３００ａアプリケーションのマスタモジュール
１３００ｂ〜１３００ｉアプリケーションのスレーブモジュール
１３１０イベントハンドラ設定手段
１３２０割り込み要求手段
１４００処理手順
１４０１Ｃｏｐｙ部分
１４０２Ｄｅｌｅｔｅ部分
１４０３Ｓｅｎｄ部分
１４０４Ｅｘｅｃｕｔｅ部分
１４０５Ｒｅｃｅｉｖｅ部分
１４０６Ｗａｓｔｅ部分
１４０７Ｂａｔｃｈ部分
１４０８Ｄｅｌｉｖｅｒ部分
１４０９Ｒａｃｅ部分
１４１０Ｃｌｅａｎ部分
１４１１Ｏｐｅｒａｔｅ部分
１５１０ノードリスト
１５２０データリスト
１５３０属性
１５４０状態
１６１０前処理
１６２０並列処理
１６３０後処理
１６４０スケジューリング
１６４１〜１６４７イベントハンドリング
１７１０メインルーチン
１７２１、１７２２、１７２３イベントハンドラ。

Claims

クラスタコンピュータの上で動作し、複数のコンピュータを協調動作させる機能をアプリケーションプログラムに提供するクラスタコンピュータミドルウェアプログラムであって、前記クラスタコンピュータが、一つのマスタコンピュータと、一つ以上のスレーブコンピュータと、前記マスタコンピュータおよび前記スレーブコンピュータを相互に接続するネットワークとを含むものにおいて、
前記クラスタコンピュータミドルウェアプログラムが少なくとも、
前記マスタコンピュータで動作するマスタアプリケーションプログラムとのリンクが可能なマスタモジュールと、
前記スレーブコンピュータで動作するスレーブアプリケーションプログラムとのリンクが可能なスレーブモジュールとによって構成され、
前記マスタモジュールが、
並列処理全体の構成要素である個々のタスクに対し、前記タスクを実行させるコンピュータとタイミングとを決定する機能を持つスケジューラを備え、
前記マスタモジュールに、
前記スケジューラが動作を開始する前に前記マスタアプリケーションプログラムの処理を一時停止させ、前記スケジューラが前記動作を終了した後に前記マスタアプリケーションプログラムの処理を再開させる機能を実現させ、かつ
前記マスタモジュールおよび前記スレーブモジュールに、
前記スケジューラから受け取った指示に基づき、前記スレーブモジュールと相互に通信する機能と、
前記タスクを実行するイベントハンドラをあらかじめ設定する機能と、
前記スケジューラの動作の開始に伴い、前記スケジューラから受け取った指示に基づき、前記イベントハンドラを実行する機能とを実現させる
ことを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項１に記載のクラスタコンピュータミドルウェアプログラムであって、
前記クラスタコンピュータミドルウェアプログラムが、
前記マスタコンピュータに、
逐次的にルーチンを実行する前記マスタアプリケーションプログラムからの呼び出しによって動作し、
前記スケジューラの動作を開始させ、かつ前記スケジューラの終了を待つ機能を有する前記ルーチンを前記マスタアプリケーションプログラムに公開する機能を実現させる
ことを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項１に記載のクラスタコンピュータミドルウェアプログラムであって、
前記クラスタコンピュータミドルウェアプログラムが、
前記マスタコンピュータの前記マスタモジュール、あるいは前記スレーブモジュールに、
データのコピーを行うデータコピー機能と、
データの消去を行うデータ消去機能とを備え、かつ
前記スケジューラが、
前記データコピー機能、および前記データ消去機能を動作させる機能を備える、ことを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項３に記載のクラスタコンピュータミドルウェアプログラムであって、
前記クラスタコンピュータミドルウェアプログラムが前記マスタモジュールおよび前記スレーブモジュールに、
前記イベントハンドラの実行、前記データのコピー、前記データの消去のうち、少なくとも一つの終了を知らせる通知を前記スケジューラに送る機能を実現させ、
前記クラスタコンピュータミドルウェアプログラムが前記スケジューラに、
前記マスタモジュールおよび前記スレーブモジュールから送られる通知を時系列的に並べ替える機能を実現させる
ことを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項３に記載のクラスタコンピュータミドルウェアプログラムであって、
前記イベントハンドラが、
コピーあるいは消去の対象となる操作対象データリストに対し、データを識別するためのインデックスを追加する機能、あるいは削除する機能を備え、かつ
前記スケジューラが、前記操作対象データリストに基づいて前記データコピー機能、および前記データ消去手機能を動作させる機能を備える、
ことを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項３に記載のクラスタコンピュータミドルウェアプログラムであって、
前記マスタモジュールが、
前記マスタアプリケーションプログラムから処理中断要求を受け取る機能を備え、かつ
前記スケジューラが、
コピーあるいは消去された前記データの配置を管理する機能と、
前記処理中断要求を受け取った時に、前記データ消去機能に対し、前記データの配置に基づいて、中間的な前記データを消去させる指示を送る機能とを備える、
ことを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項１に記載のクラスタコンピュータミドルウェアプログラムであって、
前記スケジューラが、
前記マスタコンピュータおよび前記スレーブコンピュータが前記イベントハンドラを実行しているかどうかを管理する機能と、
前記イベントハンドラを実行しているかどうかに基づき、
前記マスタモジュールあるいは前記スレーブモジュールに、
前記イベントハンドラの複数回の実行を振り分ける機能とを備える、
ことを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項７に記載のクラスタコンピュータミドルウェアプログラムであって、
前記スケジューラが、
前記マスタコンピュータおよび前記スレーブコンピュータの処理速度を把握する機能と、
前記イベントハンドラの複数回の実行を、その順番に基づき、
複数の前記マスタコンピュータあるいは前記スレーブコンピュータのうち、処理速度の速いものに優先的に振り分ける機能とを、備えることを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項７に記載のクラスタコンピュータミドルウェアプログラムであって、
前記スケジューラが
前記マスタモジュールおよび前記スレーブモジュールに振り分けられた前記イベントハンドラを実行させる際、
前記マスタコンピュータおよび前記スレーブコンピュータを一意に識別する情報、もしくは前記イベントハンドラの個々の実行を一意に識別する情報を前記イベントハンドラに渡す、ことを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項１に記載のクラスタコンピュータミドルウェアプログラムであって、
前記スケジューラが、
前記スレーブコンピュータの故障を検知する機能と、
前記故障を検知した後、
故障した前記スレーブモジュールに対して送った指示の複製を他の故障していない前記スレーブモジュールに対して送り直す機能とを備える、
ことを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項３に記載のクラスタコンピュータミドルウェアプログラムであって、
前記スケジューラが、
少なくとも一つの前記スレーブモジュールの前記データコピー機能に対し、他の前記スレーブモジュールにデータをコピーさせる機能を備える、
ことを特徴とするクラスタコンピュータミドルウェアプログラム。
請求項１１に記載のクラスタコンピュータミドルウェアプログラムであって、
前記ネットワークのトポロジが複数のハブを含む木構造であり、
前記スケジューラが、
前記ネットワークの前記トポロジを把握する機能と、
コピー元になる前記マスタモジュールあるいは前記スレーブモジュールと、
コピー先になる他の前記スレーブモジュールが、異なる前記ハブに接続されているかどうかを判定し、
前記判定の結果に基づいて
前記コピー先になる他の前記スレーブモジュールを選定する機能とを、備えることを特徴とするクラスタコンピュータミドルウェアプログラム。