(57)【特許請求の範囲】
【請求項１】
誤り訂正機能を有するメモリ及び少なくとも１つのプロセッサを含む複数のノードを相互結合網によって互いに結合し、各ノードのメモリ上に自ノード固有エリアと前記複数のノード間で論理的に共有される共有通信エリアとを設定したクラスタ計算機において、
各ノードは、自ノード固有エリアに対して自ノード内で発生したメモリアクセス要求を出した時に訂正不可能なメモリ障害が発生したときはシステム障害停止通知をメモリアクセス元に通知して自ノードの動作を停止し、他ノードに実装されたメモリの共有通信エリアに対して自ノード内で発生したメモリアクセス要求を相互結合網を通じて出した時に訂正不可能なメモリ障害が発生したときは共有通信エリア障害通知をメモリアクセス元に通知し前記他ノードはメモリ縮退処理を行った後、処理を継続して実行することを特徴とするクラスタ計算機におけるメモリ障害処理方法。
【請求項２】
各ノードは、自ノードのメモリの共有通信エリアに対して自ノード内で発生したメモリアクセス要求を出した時に訂正不可能なメモリ障害が発生したときは共有通信エリア障害通知をメモリアクセス元に通知することを特徴とする請求項１記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項３】
自ノード内で発生したメモリアクセス要求が他ノードのメモリに対するアクセス要求である場合に相互結合網を通じて他ノードに転送する制御を行う各ノード内のシステム制御装置が、メモリアクセス要求に対する応答として訂正不可能な異常終了を相互結合網を通じて他ノードから受け取ったときに共有通信エリア障害通知をメモリアクセス元に通知することを特徴とする請求項１または２記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項４】
他ノードからのメモリアクセス要求時に自ノードのメモリで訂正不可能な異常終了が発生した場合、自ノードのシステム制御装置が、訂正不可能な異常終了を、相互結合網を介してアクセス要求元のノードに通知すると共に、自ノードのプロセッサに共有通信エリア障害通知を出すことを特徴とする請求項３記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項５】
メモリアクセス要求に対する応答として訂正不可能な異常終了の転送を要求された相互結合網が、全てのノードに当該訂正不可能な異常終了をブロードキャストすることを特徴とする請求項３記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項６】
メモリアクセス要求に対する応答として訂正不可能な異常終了の転送を要求された相互結合網が、訂正不可能な異常終了に代えて共有通信エリア障害通知を転送先のノードに送ることを特徴とする請求項１または２記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項７】
相互結合網が全てのノードに共有通信エリア障害通知をブロードキャストすることを特徴とする請求項６記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項８】
相互結合網を通じて他ノードから送られてきたメモリアクセス要求を自ノードのメモリに送り、そのアクセス結果を相互結合網を通じてアクセス元のノードに返却する制御を行うシステム制御装置が、他ノードからのメモリアクセス要求時に自ノードのメモリから訂正不可能な異常終了を受けたとき、訂正不可能な異常終了に代えて共有通信エリア障害通知を相互結合網を通じてアクセス元のノードに送ることを特徴とする請求項１または２記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項９】
前記システム制御装置が自ノードのプロセッサにも共有通信エリア障害通知を通知することを特徴とする請求項８記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項１０】
相互結合網は全てのノードに共有通信エリア障害通知をブロードキャストすることを特徴とする請求項８記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項１１】
各々のノードからの障害報告を受けて障害ログを取るサービスプロセッサが、ノードから訂正不可能なメモリ障害報告を受けたときに、その障害が共有通信エリアで発生したか否かを判別し、共有通信エリアで発生していた場合はアクセス元のノードに対して共有通信エリア障害通知を通知することを特徴とする請求項１または２記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項１２】
前記サービスプロセッサが、アクセス元のノードを含め全てのノードに対して共有通信エリア障害通知を通知することを特徴とする請求項１１記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項１３】
共有通信エリア障害通知時、障害の発生した共有通信エリアをバッファ単位で縮退する処理を行うことを特徴とする請求項１，２，３，４，５，６，７，８，９，１０，１１または１２記載のクラスタ計算機におけるメモリ障害処理方法。
【請求項１４】
誤り訂正機能を有するメモリ及び少なくとも１つのプロセッサを含む複数のノードを相互結合網によって互いに結合し、各ノードのメモリ上に自ノード固有エリアと前記複数のノード間で論理的に共有される共有通信エリアとを設定したクラスタ計算機において、
各ノードは、自ノード固有エリアに対して自ノード内で発生したメモリアクセス要求を出した時に訂正不可能なメモリ障害が発生したときはシステム障害停止通知をメモリアクセス元に通知することにより自ノードの動作を停止させ、他ノードに実装されたメモリの共有通信エリアに対して自ノード内で発生したメモリアクセス要求を相互結合網を通じて出した時に訂正不可能なメモリ障害が発生したときは共有通信エリア障害通知をメモリアクセス元に通知するシステム制御装置を備えることを特徴とするクラスタ計算機。
【請求項１５】
前記各ノードのシステム制御装置は、自ノードのメモリの共有通信エリアに対して自ノード内で発生したメモリアクセス要求を出した時に訂正不可能なメモリ障害が発生したときは共有通信エリア障害通知をメモリアクセス元に通知することを特徴とする請求項１４記載のクラスタ計算機。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は並列計算機における障害処理技術に関し、特にクラスタ計算機におけるメモリ障害処理技術に関する。
【０００２】
【従来の技術】
並列計算機の一種に、少なくとも１つのプロセッサ及びメモリを含む複数のノードを、クロスバ網などの高速な相互結合網によって互いに接続したクラスタ計算機がある。クラスタ計算機の利点の１つは価格性能比に優れていることである。例えば個々のノードとして廉価だが処理能力の高いワークステーションを使用した場合、大型計算機をはるかに凌ぐ価格性能比が得られる。また他の利点は、共有メモリを物理的に１箇所に集中配置する集中共有メモリ型の並列計算機に比べ、システム規模の拡大が容易なことである。更に他の利点は、各々のノードはそれ専用のオペレーティングシステムの制御の下に１つの計算機として独立している為、異なるジョブをクラスタ計算機を構成する別々のノードで実行させたり、１つのジョブを並列プログラムとして同時に複数のノードで実行させたりするなど、多用なジョブ処理形態を取り得ることである。なお、このようなクラスタ計算機に関する文献としては、例えば特開平８−３０５６７７号公報がある。
【０００３】
またクラスタ計算機は、共有メモリを物理的に１箇所に集中配置するのではなくノード単位ごとにローカルメモリとして分散配置した分散共有メモリ型並列計算機ではあるが、共有メモリ型計算機の一種であるため、プロセッサ間通信モデルは共有メモリモデルに従う。つまり、各ノードのプロセッサは通常のメモリアクセス操作によりアドレス指定で直接的に共有メモリをアクセスすることで、ノード間の通信を実現する。具体的には、自ノードで発生したメモリアクセス要求が自ノードに実装されたメモリに対するアクセスであるときは、自ノードのメモリにメモリアクセス要求が転送され、アクセス結果がメモリアクセス元に通知される。他方、自ノードで発生したメモリアクセス要求が他ノードに実装されたメモリに対するアクセスであるときは、相互結合網を通じて他ノードにメモリアクセス要求が転送されて他ノードにおいてメモリがアクセスされ、そのアクセス結果が相互結合網を通じて要求元のノードに戻され、そして、メモリアクセス元に通知される。
【０００４】
【発明が解決しようとする課題】
クラスタ計算機を構成する各ノード内のメモリには、そのノードで実行されるオペレーティングシステムや各種アプリケーションプログラムなど破壊されてはならない重要な情報が格納される。そのため、信頼性を高めるためにＥＣＣ（Ｅｒｒｏｒ  Ｃｈｅｃｋｉｎｇ  ａｎｄ  Ｃｏｒｒｅｃｔｉｏｎ）機能を搭載したメモリが使われる。例えば３２ｂｉｔにつき７ｂｉｔの修正用ビットを付加したハミング（Ｈａｍｍｉｎｇ）符号では、１ｂｉｔの誤りを修正できる。
【０００５】
このような誤り訂正機能を搭載したメモリに対して或るノードがメモリアクセスを行った際、１ｂｉｔ誤りであれば自動的に修正されてメモリアクセスは正常終了するが、２ビット誤りであれば訂正不可能な誤りとしてメモリアクセスは異常終了し、訂正不可能な異常終了がメモリアクセス結果として返却される。計算機を構成する主記憶であるメモリに訂正不可能な誤りが発生したというハードウェア障害は、極めて重度の高い障害であるため、従来のクラスタ計算機では一般の計算機と同様に、メモリアクセス結果として訂正不可能な異常終了を受け取ったノードにおいて、システム停止障害通知を発生し、そのノードで実行中の全てのプログラムを終了し、システムを停止していた。
【０００６】
従って、各ノード間の通信のために各ノードのメモリ上に設定されている共有通信エリアに訂正不可能な誤りが発生すると、その共有通信エリアをアクセスしたノードは、たとえアクセス先が他ノードに実装されているメモリであってもシステムダウンしてしまう。各ノードは本来独立して動作可能なことがクラスタ計算機の特徴の１つであるため、自ノードに実装されていないメモリに訂正不可能な障害が発生した場合に、その箇所をアクセスしただけで自ノードがシステムダウンしてしまう事態は、クラスタ計算機の可用性（ａｖａｉｌａｂｉｌｉｔｙ）を著しく低下させる要因となる。
【０００７】
そこで本発明の第１の目的は、他ノードに実装されたメモリの共有通信エリアで発生した訂正不可能な障害によって、その共有通信エリアをアクセスしたノードがシステムダウンするのを防止し、クラスタ計算機の可用性を高めることにある。
【０００８】
また、オペレーティングシステムのカーネル部分などノードが動作し続ける上で必要不可欠な情報を記憶している自ノード固有エリアで訂正不可能な障害が発生した場合にそのノードがシステムダウンするのは致し方ないが、自ノードに実装された共有通信エリアに訂正不可能な障害が発生した場合に、自ノードが即システムダウンしてしまう事態も、クラスタ計算機の可用性を低下させる大きな要因となる。
【０００９】
そこで本発明の第２の目的は、自ノードに実装されたメモリの共有通信エリアで発生した訂正不可能な障害によって自ノードがシステムダウンするのを防止し、クラスタ計算機の可用性を高めることにある。
【００１０】
【課題を解決するための手段】
上記第１の目的を達成するために、本発明のクラスタ計算機における各ノードは、自ノード固有エリアに対して自ノード内で発生したメモリアクセス要求を出した時に訂正不可能な障害が発生したときはシステム障害停止通知をメモリアクセス元に通知して自ノードの動作を停止し、他ノードに実装されたメモリの共有通信エリアに対して自ノード内で発生したメモリアクセス要求を相互結合網を通じて出した時に訂正不可能な障害が発生したときは共有通信エリア障害通知をメモリアクセス元に通知する。
【００１１】
このように、メモリアクセス時に訂正不可能な障害が発生したときの通知として、致命的な障害が発生したためにシステムを即停止すべきことを示す従来のシステム障害停止通知とは別に、システム停止に結び付かない軽度な障害が発生したことを示す共有通信エリア障害通知を定義し、自ノード内で発生したメモリアクセス要求時に訂正不可能な障害が発生した場合にそのアクセス先が自ノード固有エリアであれば重度の障害が発生したことを示すシステム障害停止通知を出して自ノードの動作を停止するが、アクセス先が他ノードに実装されたメモリの共有通信エリアであれば、システム障害停止通知ではなく、より軽度の障害が発生したことを示す共有通信エリア障害通知を出すことにより、他ノードに実装されたメモリの共有通信エリアで発生した訂正不可能な障害によって、その共有通信エリアをアクセスしたノードがシステムダウンするのを防止でき、クラスタ計算機の可用性を高めることができる。
【００１２】
或るノードから出されたメモリアクセス要求によって他ノードのメモリで訂正不可能な障害が発生した場合、最終的には要求元のノードのプロセッサ等のメモリアクセス元に共有通信エリア障害通知が出されるわけであるが、この共有通信エリア障害通知をどこで発生させるかについては以下のような各種の方法が採用できる。
【００１３】
１つの方法は、自ノード内で発生したメモリアクセス要求が他ノードのメモリに対するアクセス要求である場合に相互結合網を通じて他ノードに転送する制御を行う各ノード内のシステム制御装置が、メモリアクセス要求に対する応答として訂正不可能な異常終了を相互結合網を通じて他ノードから受け取ったときに共有通信エリア障害通知を発生し、メモリアクセス元に通知する方法である。
【００１４】
他の方法は、メモリアクセス要求に対する応答として訂正不可能な異常終了の転送を要求された相互結合網が、それに代えて共有通信エリア障害通知を発生し、転送先のノード、つまりアクセス要求元のノードに送る方法である。
【００１５】
他の方法は、実際にメモリアクセスが行われたノードにおいて発生する方法である。つまり、相互結合網を通じて他ノードから送られてきたメモリアクセス要求を自ノードのメモリに送り、そのアクセス結果を相互結合網を通じてアクセス元のノードに返却する制御を行うシステム制御装置が、他ノードからのメモリアクセス要求時に自ノードのメモリから訂正不可能な異常終了を受けたとき、それに代えて共有通信エリア障害通知を発生し、相互結合網を通じてアクセス元のノードに返却する方法である。
【００１６】
他の方法は、各々のノードからの障害報告を受けて障害ログを取るサービスプロセッサにおいて発生する方法である。つまり、サービスプロセッサが、ノードから訂正不可能なメモリ障害報告を受けたときに、その障害が共有通信エリアで発生したか否かを判別し、共有通信エリアで発生していた場合はアクセス元のノードに対して共有通信エリア障害通知を送出する方法である。
【００１７】
また上記第２の目的をも達成するために、本発明のクラスタ計算機における各ノードは、自ノードのメモリの共有通信エリアに対して自ノード内で発生したメモリアクセス要求を出した時に訂正不可能な障害が発生したときは共有通信エリア障害通知をメモリアクセス元に通知する。
【００１８】
このように、自ノードのメモリの共有通信エリアに対して自ノード内で発生したメモリアクセス要求を出した時に訂正不可能な障害が発生したとき、システム障害停止通知ではなく、より軽度の障害が発生したことを示す共有通信エリア障害通知を出すことにより、自ノードに実装されたメモリの共有通信エリアで発生した訂正不可能な障害によって、自ノードがシステムダウンするのを防止でき、クラスタ計算機の可用性を高めることができる。
【００１９】
共有通信エリア障害通知時の処理は、軽度の障害であるためシステムダウンを伴わない範囲内で実行される。例えば、共有通信エリアを複数バッファに分割定義し、障害時にバッファ単位での縮退が可能になっている場合、障害の発生した共有通信エリアのバッファを縮退する処理が行われる。また、バッファ単位での縮退が行えない構成になっているか、可能でも正常なバッファが１つも存在しなくなった場合には、当該共有通信エリアを使用したノード間通信を閉塞する処理が行われる。これにより、その共有通信エリアを介して通信しているノード間の通信は不可能になるが、そのこと自体はクラスタ計算機の運用に致命的ではない。何故なら、クラスタ計算機の個々のノードはそれ単独で１つのコンピュータとしても動作できるため、他ノードとの通信が必要ないジョブなら実行を継続でき、また、１つのジョブを並列プログラムとして同時に複数のノードで実行している場合でも、通信できなくなったノードを除く残りの複数ノードで並列プログラムを実行できるからである。さらに、相互結合網を経由した共有メモリモデルによるノード間通信とは別にイーサネット等のグローバルネットワーク経由によるメッセージ交換モデルによるノード間通信もサポートされているクラスタ計算機では、メッセージ交換モデルによるノード間通信で代替できるからである。
【００２０】
共有通信エリアはノード間で論理的に共有されているため、或る共有通信エリアで訂正不可能な障害が発生したとき、そのアクセス元のノードだけでなく他のノードもその事実を認識し、バッファ単位の縮退などの措置を取る必要がある。他ノードに共有通信エリアの障害を認識させる典型的な方法は、アクセス元のノードが相互結合網やグローバルネットワークを通じて他のノードに共有通信エリア障害通知を転送する方法であるが、それ以外に、他ノードのメモリアクセス時に訂正不可能な障害が発生した場合には以下のような効率的な方法を採用することができる。
【００２１】
１つの方法は、他ノードからのメモリアクセス要求時に自ノードのメモリで訂正不可能な異常終了が発生した場合、訂正不可能な異常終了を、相互結合網を介してアクセス要求元のノードに通知すると共に、自ノードのプロセッサにも通知する方法である。
【００２２】
他の方法は、メモリアクセス要求に対する応答として訂正不可能な異常終了の転送を要求された相互結合網が、全てのノードに当該訂正不可能な異常終了をブロードキャストする方法である。
【００２３】
他の方法は、メモリアクセス要求に対する応答として訂正不可能な異常終了の転送を要求された相互結合網が、それに代えて共有通信エリア障害通知を転送先のノードを含め全てのノードにブロードキャストする方法である。
【００２４】
他の方法は、他ノードからのメモリアクセス要求時に自ノードのメモリで訂正不可能な異常終了が発生した場合、訂正不可能な異常終了に代えて共有通信エリア障害通知を相互結合網を通じてアクセス元のノードと自ノードのプロセッサに通知する方法である。
【００２５】
他の方法は、他ノードからのメモリアクセス要求時に自ノードのメモリで訂正不可能な異常終了が発生した場合、訂正不可能な異常終了に代えて共有通信エリア障害通知を相互結合網を通じてアクセス元のノードに通知する際、相互結合網が全てのノードに当該共有通信エリア障害通知をブロードキャストする方法である。
【００２６】
他の方法は、サービスプロセッサが、アクセス元のノードを含め全てのノードに対して共有通信エリア障害通知を出す方法である。
【００２７】
【発明の実施の形態】
次に本発明の実施の形態の例について図面を参照して詳細に説明する。
【００２８】
○第１の実施形態
図１を参照すると、本発明の第１の実施形態にかかるクラスタ計算機１は、４つのノード１０，２０，３０，４０を備えている。ノード数は本例では、４つであるが、本発明は２つ以上のノードを備えるクラスタ計算機に対して適用可能である。
【００２９】
それぞれのノード１０，２０，３０，４０は、本例の場合、全て同じ構成であり、プロセッサを構成する２つの演算処理装置（Micro Processing Unit 。以下、ＭＰＵと称す）１１，１２、２１，２２、３１，３２、４１，４２と、入出力制御装置（Input-Output Controller 。以下、ＩＯＣと称す）１３、２３、３３、４３と、メモリ（Main Memory Unit。以下、ＭＭＵと称す）１４、２４、３４、４４と、メモリアクセスを含むシステム制御を行うシステム制御装置（System Control Subsystem。以下、ＳＣＳと称す）１５、２５、３５、４５と、各ノード内におけるＭＰＵ間およびＭＰＵとＳＣＳとをつなぐシステムバス１６、２６、３６、４６とを備え、それぞれ別個独立なオペレーティングシステムが搭載されている。なお、各ノードに含まれるＭＰＵの数は任意であり、少なくとも１つのＭＰＵを含むノードであれば良く、また全てのノードでＭＰＵの数が同じである必要はない。
【００３０】
ＭＭＵは誤り訂正機能を有するメモリであり、例えば前述したハミング符号により１ｂｉｔの誤りは自動修正でき、２ｂｉｔ誤りは完全に検出できる。なお、本例におけるＭＭＵは、ライトしたデータを再度リードしてＥＣＣチェックを行うことによりリード時だけでなくライト時にも訂正不可能な障害を検出できるようにしている。
【００３１】
クラスタ計算機１における各ノード１０，２０，３０，４０は、ＳＣＳ１５，２５，３５，４５において信号線１７，２７，３７，４７を介してクロスバ網（Cross Bar Controller。以下、ＸＢＣと称す）５０に接続されている。ＸＢＣは相互結合網の一種であり、クロスポイントスイッチのオン，オフにより、任意のノード間を単一段で結合でき、通信遅延が非常に小さいという特徴をもつ。各ノードは、ＸＢＣ５０を通じて他ノードのＭＭＵをアクセスすることで、共有メモリモデルによるノード間通信を行う。ＸＢＣの代わりに、オメガ網などの多段網（multi-stage network)やその他の相互結合網を使用することができる。なお、各ノード内におけるＭＰＵ間の通信はシステムバス経由で行われる。
【００３２】
さらにクラスタ計算機１における各ノード１０，２０，３０，４０は、ＩＯＣ１３，２３，３３，４３において信号線１８，２８，３８，４８を介してグローバルネットワーク６０に接続されている。グローバルネットワーク６０としては、例えばイーサネット（Ｅｔｈｅｒｎｅｔ）が使用される。勿論、他の形式のＬＡＮ（Local Area Network) であっても良い。各ノードは、このグローバルネットワーク６０を介してメッセージの交換という形式でノード間通信を行うことができる。即ち、クラスタ計算機１は、ＸＢＣ５０経由の共有メモリモデルによる高速なノード間通信と、それよりは低速であるがグローバルネットワーク６０経由のメッセージ交換モデルによるノード間通信との双方が行える。
【００３３】
また、グローバルネットワーク６０には信号線７１を介してクラスタサーバ７０が接続されている。クラスタサーバ７０は、グローバルネットワーク６０を介して各ノード１０，２０，３０，４０と適宜通信することにより、各ノードの負荷状況を含む運用状態管理やジョブ管理などを司る。
【００３４】
図２はクラスタ計算機１のメモリ構成の一例を示すメモリマップである。図２において、Ｍ１０〜Ｍ１３，Ｍ２０〜Ｍ２３，Ｍ３０〜Ｍ３３，Ｍ４０〜Ｍ４３は、各ノードのＭＭＵに物理的に搭載されたメモリモジュールを示し、その中に括弧書きで記述された０，１，２，３の数値は各々のノード内において当該メモリモジュールを他のメモリモジュールと区別するための識別番号である。この例では各々のノードに４つのメモリモジュールが搭載されているが、メモリモジュールの数は一般に複数であれば良く、また全てのノードで同じである必要はない。また図２の縦軸はそれぞれのノードから見たメモリアドレスを示し、全ノードとも０番地から始まるメモリ空間を持つと仮定している。
【００３５】
図２のメモリ構成では、各ノードのメモリアドレスｘ０からｘ２ＦＦＦＦは、それぞれのノードに実装されたメモリモジュールＭ１０〜Ｍ１２，Ｍ２０〜Ｍ２２，Ｍ３０〜Ｍ３２，Ｍ４０〜Ｍ４２にマップされ、それぞれ自ノード専用のノード固有エリアとして使用される。他方、メモリアドレスｘ３００００からｘ６ＦＦＦＦは、各ノードのメモリモジュールＭ１３，Ｍ２３，Ｍ３３，Ｍ４３をアドレスが異なるように組み合わされ、共通のアドレスによる相互アクセスが可能な共有通信エリアとして使用される。
【００３６】
ここで本例においては、ノード間の独立性を高め、エラー伝搬を防止するために、他ノードの共有通信エリアに対するアクセスはリードアクセスのみ許可し、ライトアクセスは許可しない。つまり、ノード１０に実装されたメモリモジュールＭ１３にマップされたメモリアドレスｘ３００００からｘ３ＦＦＦＦは、ノード１０内のＭＰＵ及びＩＯＰからはリード及びライトの双方のアクセスを許可するが、他のノード２０，３０，４０内のＭＰＵ及びＩＯＰからはリードアクセスのみを許可する。ノード２０，３０，４０に実装されたメモリモジュールＭ２３，Ｍ３３，Ｍ４３についても同様であり、他ノードからはリードアクセスのみを許可する。従って、例えばノード１０と他のノード２０，３０，４０の共有メモリモデルによる通信は、ノード１０がメモリモジュールＭ１３にデータをライトし、ノード２０，３０，４０がそのデータをリードすることで実現される。
【００３７】
なお、例えばノード１０からノード２０へメモリモジュールＭ１３の或る領域を通じてデータを送る場合、ノード１０がその領域にデータをライトした時点でグローバルネットワーク６０経由でノード２０に対し、データをその領域にライトした旨を通知する。他方、ノード２０はその領域のデータをリードし終えると、その旨をグローバルネットワーク６０経由でノード１０に対し通知する。
【００３８】
図２のようなメモリ構成を採る場合、各ノードのＭＰＵおよびＩＯＰからメモリアクセスが出された場合、そのノードのＳＣＳは、アクセスにかかるメモリアドレスに基づき、自ノードに実装されたメモリモジュールに対するローカルなアクセスか、他ノードに実装されたメモリモジュールに対するリモートなアクセスかを判断し、リモートアクセスの場合には要求をＸＢＣ５０を通じてアクセス先のノードに転送する。そのために各ノードのＳＣＳは、図２のメモリ構成に対応して、図３に示すようなメモリ管理用テーブルを内蔵している。
【００３９】
図３において、１５ａはノード１０用、２５ａはノード２０用、３５ａはノード３０用、４５ａはノード４０用のメモリ管理用テーブルである。各々のメモリ管理用テーブルは、自ノードのみで使用するノード固有エリアの割り当て情報を記述した部分Ａと、ノード間通信用に使用する共有通信エリアの割り当て情報を記載した部分Ｂとに分けられ、それぞれの部分Ａ，Ｂは更に各メモリモジュール毎のエントリに分けられている。そして、各エントリには、当該メモリモジュールに割り当てられたメモリアドレスの開始アドレス１５２及びサイズ（メモリ長）１５３と、当該メモリモジュールの実装位置１５４と、当該メモリモジュールがノード固有エリアか、共有通信エリアかを示す共有／固有ビット１５１とが設定される。実装位置１５４としては、例えば、当該メモリモジュールが実装されているノードの識別番号１５５とそのノード内における当該メモリモジュールの識別番号１５６とが使われる。また、共有／固有ビット１５１は、例えば、当該メモリモジュールが共有通信エリアとしてノード間で共有される場合には値１が設定され、ノード固有エリアとして使用される場合には値０が設定される。
【００４０】
また本例においては、共有通信エリアとして使用するメモリモジュールＭ１３，Ｍ２３，Ｍ３３，Ｍ４３のメモリ領域を各メモリモジュール毎に複数に分割し、各々の分割領域単位での縮退を可能にしている。個々の分割領域のことをバッファと呼び、バッファの管理のために個々のノード内に備えられているテーブルをバッファ管理テーブルと呼ぶ。
【００４１】
図４にバッファの構成例とバッファ管理テーブルの一例を示す。ここでは、メモリモジュールＭ１３，Ｍ２３，Ｍ３３，Ｍ４３の各メモリ領域を同じサイズの２つのバッファに分割し、合計８つのバッファＢ１０，Ｂ１１，Ｂ２０，Ｂ２１，Ｂ３０，Ｂ３１，Ｂ４０，Ｂ４１を定義した例を示す。バッファ管理テーブル１５ｂは、各バッファに１対１に対応するエントリＥ１０，Ｅ１１，Ｅ２０，Ｅ２１，Ｅ３０，Ｅ３１，Ｅ４０，Ｅ４１を有し、各エントリに、当該バッファが使用可能か否かを示すバリッド（ｖａｌｉｄ）ビット１５７、当該バッファの開始アドレス１５８及びサイズ（バッファ長）１５９と、当該バッファを含むメモリモジュールが実装されているノードの識別子１６０とが設定されている。バリッドビット１５７は、例えば、使用可能の場合は値１、使用不可能な場合は値０に設定される。バッファ管理テーブル１５ｂは、例えば各ノードのノード固有エリア内に格納される。また、クラスタサーバ７０内にも同様のバッファ管理テーブル１５ｂが格納されている。
【００４２】
図５および図６は、各ノードにおけるＳＣＳのメモリアクセス関連の処理例を示すフローチャートであり、図５は自ノードのＭＰＵまたはＩＯＣからメモリアクセス要求を受けた際の処理例を、図６は他ノードからメモリアクセス要求を受けた際の処理例を、それぞれ示す。また図７は、或るノード内のＭＰＵまたはＩＯＣからメモリアクセス要求が出された際のメモリアクセスに関連する信号の流れを示す図である。
【００４３】
以下、各図を参照して本実施形態のクラスタ計算機１におけるメモリアクセス時の処理を説明する。なお、各ノード１０，２０，３０，４０ともメモリアクセス時の処理は同じであるため、以下では、ノード１０内で発生したメモリアクセス要求を例にする。
【００４４】
ノード１０内のＭＰＵ１１，１２またはＩＯＣ１３は、メモリアクセスを行う場合、アクセス先メモリが自ノード内メモリか、他ノード内メモリかにかかわらず、通常のリード／ライト命令によりアドレス指定でメモリアクセス要求を行う。メモリアクセス要求を行ったＭＰＵ１１，１２またはＩＯＣ１３をメモリアクセス元と言う。メモリアクセス元からのメモリアクセス要求は、図７のａ１に示されるように、自ノード１０のＳＣＳ１５に渡る。
【００４５】
ＳＣＳ１５は、まず、図３のメモリ管理用テーブル１５ａを用いて、メモリアクセス要求ａ１が自ノード内メモリに対するアクセス要求か、他ノード内メモリに対するアクセス要求かをチェックする（図５のステップＳ１）。具体的には、メモリアクセス要求ａ１で指定されたメモリアドレスを、開始アドレス１５２からサイズ１５３までの範囲内に含むエントリにおけるノード識別番号１５５の値を調べ、その値が自ノード１０の識別番号であれば自ノード内メモリに対するアクセス要求と判断し（ステップＳ２でＹＥＳ）、その値が他ノード２０，３０，４０の何れかの識別番号であれば、当該他ノード内のメモリに対するアクセス要求と判断する（ステップＳ２でＮＯ）。以下、各々の場合にわけて説明する。
【００４６】
（１）他ノード内メモリアクセスの場合
ＳＣＳ１５は、メモリアクセス要求ａ１がリード要求か否かを調べ（ステップＳ３）、ライト要求であれば、メモリアクセス元にアクセス例外を通知する（ステップＳ４。図７のｂ１）。他方、リード要求であれば、当該メモリアクセス要求ａ１をＸＢＣ５０経由で、アクセス先のノードに転送する（ステップＳ５。図７のｂ２，ｄ１）。そして、アクセス先のノードからの応答を待つ。以下、説明の便宜上、メモリアクセス元がノード２０からの通信データをリードするために、図４のバッファＢ２０をリード先としたメモリアクセス要求を送出した場合を仮定する。この場合、当該メモリアクセス要求は、ＸＢＣ５０経由でノード２０のＳＣＳ２５に渡される。
【００４７】
ノード２０のＳＣＳ２５は、ＸＢＣ５０経由でノード１０からメモリアクセス要求ｄ１を受信すると、図３のメモリ管理用テーブル２５ａを用いて、メモリアクセス要求ｄ１が自ノードに実装された共有通信エリアに対するものか否かをチェックする（図６のステップＳ３１）。具体的には、メモリアクセス要求ｄ１で指定されたメモリアドレスを、開始アドレス１５２からサイズ１５３までの範囲内に含むエントリにおける共有／固有ビット１５１及びノード識別番号１５５の値を調べ、共有／固有ビット１５１の値が１で且つノード識別番号１５５の値が自ノード２０の識別番号であれば、自ノードに実装された共有通信エリアに対するアクセス要求であると判断し、それ以外はそうでないと判断する。そして、メモリアクセス要求ｄ１が自ノードに実装された共有通信エリアに対するものでない場合は（ステップＳ３２でＮＯ）、アドレスエラーをＸＢＣ５０経由で、ノード１０に通知する（ステップＳ３３。図７のｆ１，ｄ２）。ノード１０のＳＣＳ１５は、アドレスエラーｄ２を受け取ると（図５のステップＳ６）、エラー処理へと進む（Ｓ７，Ｓ８）。このようなアドレスエラーが生じる原因としては、メモリ管理用テーブルのデータ化け、ＸＢＣ５０の故障等が考えられるため、エラー処理において適切な処理が実施される。なお、この点は本発明においては重要ではないので、その詳細な説明は省略する。
【００４８】
他方、メモリアクセス要求ｄ１が自ノードに実装された共有通信エリアに対するものであった場合（ステップＳ３２でＹＥＳ）、ノード２０のＳＣＳ２５は、ＭＭＵ２４に当該メモリアクセス要求、つまりリード要求を渡す（ステップＳ３４。図７のｆ２）。そして、ＭＭＵ２４からの終了通知を待つ。
【００４９】
ＭＭＵ２４は当該リード要求に応答して、自ノードに実装された該当するメモリモジュールのエリア（今の仮定では、メモリモジュールＭ２３のバッファＢ２０内のエリア）からデータを読み出し、ＥＣＣをチェックして、誤りが無ければ前記読み出したデータそのものを、誤りがあっても訂正可能であれば訂正後のデータを、それぞれ正常終了としてＳＣＳ２５に返却し（図７のｅ１）、前記読み出したデータに訂正不可能な誤りがあれば、訂正不可能な異常終了をＳＣＳ２５に返却する（図７のｅ２）。訂正不可能な異常終了には、障害の発生したメモリアドレスが含まれる。
【００５０】
ＳＣＳ２５は、ＭＭＵ２４から正常終了ｅ１を受け取ると（ステップＳ３５，Ｓ３６）、ＸＢＣ５０経由で正常終了をノード１０に通知する（ステップＳ３７。図７のｆ３，ｄ３）。ノード１０では、この正常終了をＳＣＳ１５が受信し（図５のステップＳ６，Ｓ７）、メモリアクセス元に通知する（ステップＳ９。図７のｂ５）。
【００５１】
他方、ＳＣＳ２５は、ＭＭＵ２４から訂正不可能な異常終了を受け取った場合（ステップＳ３５，Ｓ３６）、ＸＢＣ５０経由でノード１０に訂正不可能な異常終了を通知する（ステップＳ３８。図７のｆ４，ｄ４）。ノード１０では、この訂正不可能な異常終了の通知をＳＣＳ１５が受信すると（図５のステップＳ６，Ｓ７）、メモリアクセス元に共有通信エリア障害通知を出す（図５のステップＳ１０。図７のｂ６）。共有通信エリア障害通知には、訂正不可能な異常終了に含まれていた障害メモリアドレスが含められる。
【００５２】
以上のＳＣＳ１５の処理が従来と大きく相違する点である。つまり、従来は、自ノード１０内のメモリアクセス元からのメモリアクセス要求を他ノードに転送したときに他ノードから訂正不可能な異常終了の通知を受けた場合、ＳＣＳ１５はシステム停止障害通知をメモリアクセス元に出していたのに対し、本実施形態では、システム停止障害が発生したときの障害程度よりも軽度の障害が発生した旨を示す共有通信エリア障害通知をメモリアクセス元に出す。これにより、メモリアクセス元においてメモリ障害処理を切りわけることができる。
【００５３】
以下、共有通信エリアで訂正不可能な障害が発生した場合のクラスタ計算機１の処理例を説明する。
【００５４】
共有通信エリア障害通知を受けたメモリアクセス元がノード１０のＭＰＵ１１または１２であった場合、ＭＰＵ１１または１２は、ＳＣＳ１５，ＩＯＣ１３およびグローバルネットワーク６０経由で当該共有通信エリア障害通知をクラスタサーバ７０と他の全てのノード２０，３０，４０に転送した後、バッファ縮退プログラムを起動して障害にかかるバッファを縮退する処理を開始する。また、メモリアクセス元がＩＯＣ１３であった場合は、ＩＯＣではノード内資源を管理，構成変更する処理は行えないため、共有通信エリア障害通知をＭＰＵ１１またはＭＰＵ１２に通知し、共有通信エリア障害通知のクラスタサーバ７０と他の全てのノード２０，３０，４０への通知処理、および障害にかかるバッファを縮退する処理とをＭＰＵに任せる。
【００５５】
バッファ縮退プログラムでは、まず、自ノード１０が保有する図４のバッファ管理テーブル１５ｂを、共有通信エリア障害通知で通知された障害アドレスで検索して、障害バッファを特定する。今の仮定では、バッファＢ２０が障害バッファに特定される。次に、障害バッファに対応するエントリＥ２０のバリッドビット１５７を値０にする。これにより、以後、自ノード１０において、ノード２０と通信する際、バッファＢ２０は使用されなくなる。
【００５６】
グローバルネットワーク６０経由で共有通信エリア障害通知を受けたノード２０，３０，４０では、その通知がＩＯＣ，ＳＣＳを通じて何れかのＭＰＵに伝達されてバッファ縮退プログラムが起動され、自ノードの保有する図４のバッファ管理テーブル１５ｂが更新され、ノード１０と同様に障害バッファＢ２０が縮退される。これにより、ノード２０においては、ノード１０，３０，４０と通信する際にバッファＢ２０は使用されなくなり、ノード３０においてはノード２０と通信する際にバッファＢ２０は使用されなくなり、ノード４０においてはノード２０と通信する際にバッファＢ２０は使用されなくなる。
【００５７】
グローバルネットワーク６０経由で共有通信エリア障害通知を受けたクラスタサーバ７０でも、自ら保有する図４のバッファ管理テーブル１５ｂを同様に更新することにより、バッファの状態を管理する。
【００５８】
以上のように各ノードでバッファＢ２０が縮退されると、ノード２０から他のノード１０，３０，４０への共有メモリモデルに従う送信は、以後、バッファＢ２１だけを使用して実施される。従って、縮退されたバッファＢ２０を使って行われたノード間通信が正常終了していなかった場合、バッファＢ２１を使って当該ノード間通信のリトライが行われる。
【００５９】
また、バッファＢ２０だけでなくバッファＢ２１にも訂正不可能な障害が発生して縮退されたとすると、バッファ管理テーブル１５ｂにおいて、ノード識別子１６０がノード２０を示す１となっている全エントリＥ２０，Ｅ２１のバリッドビット１５７が０となり、ノード２０から他のノード１０，３０，４０へ共有メモリモデルに従って通信するためのバッファが１つもなくなる。このような事態になると、ノード２０では他ノード１０，３０，４０との間の共有メモリモデルに従う通信を閉塞し、ノード１０，３０，４０ではノード２０との間の共有メモリモデルに従う通信を閉塞する。また、クラスタサーバ７０では、ノード２０と他ノード１０，３０，４０との間で共有メモリモデルに従う通信が行えなくなったことを管理する。しかしながら、本実施形態のクラスタ計算機１には、グローバルネットワーク６０経由でメッセージ交換モデルによる通信が可能であるため、ノード２０と他のノード１０，３０，４０との通信をメッセージ交換モデルによる通信で代替することにより、クラスタ構成中のノード状態管理上、ノード２０をノードダウンの状態にすることは回避できる。
【００６０】
（２）自ノード内メモリアクセスの場合
ＳＣＳ１５は、メモリアクセス元から渡されたメモリアクセス要求ａ１が自ノード内メモリに対するアクセス要求であれば、そのメモリアクセス要求を自ノード１０のＭＭＵ１４に渡す（図５のステップＳ１１。図７のｂ３）。そして、ＭＭＵ１４からの応答を待つ。ＭＭＵ１４は当該アクセス要求に応答して、自ノードに実装された該当するメモリモジュールのエリアをアクセスし、アクセス結果をＳＣＳ１５に返す。アクセス結果には、正常終了と訂正不可能な異常終了との２種類がある（図７のｃ１，ｃ２）。また訂正不可能な異常終了には、異常終了した障害メモリアドレスが含まれる。
【００６１】
ＳＣＳ１５は、ＭＭＵ１４から正常終了ｃ１を受け取ると（ステップＳ１２，Ｓ１３）、それをメモリアクセス元に通知する（ステップＳ１４。図７のｂ７）。他方、ＭＭＵ１４から訂正不可能な異常終了を受け取った場合（ステップＳ１２，Ｓ１３）、図３のメモリ管理用テーブル１５ａを用いて、訂正不可能な異常終了で通知された障害メモリアドレスが自ノードに実装された共有通信エリア内のアドレスか否かをチェックする（図５のステップＳ１５）。具体的には、障害メモリアドレスを、開始アドレス１５２からサイズ１５３までの範囲内に含むエントリにおける共有／固有ビット１５１及びノード識別番号１５５の値を調べ、共有／固有ビット１５１の値が１で且つノード識別番号１５５の値が自ノード１０の識別番号であれば、自ノードに実装された共有通信エリア内のアドレスであると判断し、それ以外はそうでないと判断する。そして、障害メモリアドレスが自ノードに実装された共有通信エリア内のアドレスであれば、メモリアクセス元に共有通信エリア障害通知を出し（ステップＳ１８。図７のｂ８）、共有通信エリア外のアドレス、つまりノード固有エリア内のアドレスであれば、メモリアクセス元にシステム停止障害通知を出す（ステップＳ１７。図７のｂ９）。
【００６２】
以上のＳＣＳ１５の処理が従来と大きく相違する点である。つまり、従来は、自ノード１０内のメモリアクセス元からの要求を自ノード１０内のＭＭＵ１４に対して送出したときに訂正不可能な異常終了の通知を受けた場合、ＳＣＳ１５は常にシステム停止障害通知をメモリアクセス元に出していたのに対し、本実施形態では、障害箇所が共有通信エリアの場合には、システム停止障害が発生したときの障害程度よりも軽度の障害が発生した旨を示す共有通信エリア障害通知をメモリアクセス元に出す。これにより、メモリアクセス元はメモリ障害処理を切りわけることができる。
【００６３】
共有通信エリア障害通知を受けたメモリアクセス元の動作は、前記（１）のときと同じであり、メモリアクセス元がノード１０のＭＰＵ１１または１２であったときは、ＳＣＳ１５，ＩＯＣ１３およびグローバルネットワーク６０経由で当該共有通信エリア障害通知をクラスタサーバ７０と他の全てのノード２０，３０，４０に転送した後、バッファ縮退プログラムを起動して障害にかかるバッファを縮退する処理を開始する。また、メモリアクセス元がＩＯＣ１３であった場合は、グローバルネットワーク６０経由で当該共有通信エリア障害通知をクラスタサーバ７０と他の全てのノード２０，３０，４０に送出した後、共有通信エリア障害通知をＭＰＵ１１またはＭＰＵ１２に通知し、障害にかかるバッファを縮退する処理をＭＰＵに任せる。
【００６４】
またバッファ縮退プログラムでは、自ノード１０が保有する図４のバッファ管理テーブル１５ｂを、共有通信エリア障害通知で通知された障害アドレスで検索して、障害バッファを特定する。そして、障害バッファが例えばバッファＢ１０に特定されたとすると、障害バッファＢ１０に対応するエントリＥ１０のバリッドビット１５７を値０にする。これにより、以後、自ノード１０において、他ノード２０，３０，４０と通信する際、バッファＢ１０は使用されなくなる。
【００６５】
グローバルネットワーク６０経由で共有通信エリア障害通知を受けたノード２０，３０，４０では、その通知がＩＯＣ，ＳＣＳを通じて何れかのＭＰＵに伝達されてバッファ縮退プログラムが起動され、自ノードの保有する図４のバッファ管理テーブル１５ｂが更新され、ノード１０と同様に障害バッファＢ１０が縮退される。また、グローバルネットワーク６０経由で共有通信エリア障害通知が転送されてきたクラスタサーバ７０でも、自ら保有する図４のバッファ管理テーブル１５ｂを同様に更新することにより、バッファの状態を管理する。
【００６６】
以上のように各ノードでバッファＢ１０が縮退されると、ノード１０から他のノード２０，３０，４０への共有メモリモデルに従う送信は、以後、バッファＢ１１だけを使用して実施される。
【００６７】
また、バッファＢ１０だけでなくバッファＢ１１にも訂正不可能な障害が発生して縮退されたとすると、バッファ管理テーブル１５ｂにおいて、ノード識別子１６０がノード１０を示す０となっている全エントリＥ１０，Ｅ１１のバリッドビット１５７が０となり、ノード１０から他のノード２０，３０，４０へ共有メモリモデルに従って送信するためのバッファが１つもなくなる。このような事態になると、ノード１０では他ノード２０，３０，４０との間の共有メモリモデルに従う通信を閉塞し、ノード２０，３０，４０ではノード１０との間の共有メモリモデルに従う通信を閉塞する。また、クラスタサーバ７０では、ノード１０と他ノード２０，３０，４０との間で共有メモリモデルに従う通信が行えなくなったことを管理する。しかしながら、本実施形態のクラスタ計算機１には、グローバルネットワーク６０経由でメッセージ交換モデルによる通信が可能であるため、ノード１０と他のノード２０，３０，４０との通信をメッセージ交換モデルによる通信で代替することにより、クラスタ構成中のノード状態管理上、ノード１０をノードダウンの状態にすることは回避できる。
【００６８】
他方、システム停止障害通知を受けた場合、当該ノード１０は、そのノードで実行中の全てのプログラムを終了させ、システムを停止する。つまり、ノードダウンとなる。クラスタサーバ７０はグローバルネットワーク６０経由で各ノードに対して一定周期でヘルスチェック信号を送っており、ノード１０からヘルスチェック信号に対する応答が来ないことで、ノード１０がシステムダウンしたことを検出し、クラスタ構成中のノード状態管理上、ノード１０をノードダウンの状態として管理する。また、グローバルネットワーク６０を通じて他のノード２０，３０，４０にノード１０がダウンしたことを通知し、各ノード２０，３０，４０はノード１０との間の一切の通信を停止する。
【００６９】
以上説明した本発明の第１の実施形態では、以下のような効果が得られる。
【００７０】
（ａ）各ノードにおいて、他ノードに実装された共有通信エリアをアクセスした際に訂正不可能な誤りが発生した場合、その応答として、システム停止障害通知ではなく、より軽度の障害が発生した旨の共有通信エリア障害をメモリアクセス元に返すことができる。これにより、或るノードに実装されたメモリモジュール中の共有通信エリアの障害によって、そのエリアをアクセスした他ノードがシステムダウンする事態を回避できる。
【００７１】
（ｂ）各ノードにおいて、自ノード内で発生したメモリアクセス要求に従って自ノードに実装された共有通信エリアをアクセスした際に訂正不可能な誤りが発生した場合、その応答として、システム停止障害通知ではなく、より軽度の障害が発生した旨の共有通信エリア障害をメモリアクセス元に返すことができる。これにより、自ノードに実装されたメモリモジュール中の共有通信エリアの障害によって自ノードがシステムダウンする事態を回避できる。
【００７２】
（ｃ）共有通信エリアを複数のバッファに分割し、バッファ単位での縮退を可能としたので、何れかのバッファに訂正不可能な障害が発生しても健全なバッファを使って共有メモリモデルに従うノード間通信を継続できる。
【００７３】
（ｄ）ＸＢＣ５０経由の共有メモリモデルに従うノード間通信以外に、グローバルネットワーク６０経由のメッセージ交換モデルに従うノード間通信もサポートされているため、他ノードとの通信に使用する全バッファが縮退された場合であっても、メッセージ交換モデルに従うノード間通信によりノード間の通信が確保できる。
【００７４】
○第２実施形態
本発明の第２の実施形態は、他ノードから自ノードに実装されている共有通信エリアに対するメモリアクセス要求があった場合に訂正不可能な障害が発生したとき、自ノードのＳＣＳが要求元の他ノードに訂正不可能な異常終了を返すと同時に、自ノードのＭＰＵに対して共有通信エリア障害通知を出すようにした点で、第１の実施形態と相違し、それ以外は第１の実施形態と同じである。
【００７５】
本実施形態においては、各ノードのＳＣＳにおける図６のステップＳ３８の処理が、要求元のノードに訂正不可能を示す異常終了をＸＢＣ５０経由で通知すると共に、図８に示すように自ノードのＭＰＵに共有通信エリア障害通知ｆ５を出すように変更されている。これにより、アクセス要求元のノードからグローバルネットワーク６０経由で共有通信エリア障害通知が届く前に自ノードにおけるバッファ縮退処理を開始することができる。なお、その後にグローバルネットワーク６０経由で届く共有通信エリア障害通知は自ノードに関しては無視される。
【００７６】
○第３実施形態
本発明の第３の実施形態は、何れかのノードからメモリアクセスに対する応答として訂正不可能な異常終了の転送が要求されたとき、ＸＢＣ５０が、その宛先のノードだけでなく全ノードに当該訂正不可能な異常終了をブロードキャストし、この訂正不可能な異常終了を受信したノードのＳＣＳが自ノードのＭＰＵに共有通信エリア障害通知を出すようにした点で、第１の実施形態と相違し、それ以外は第１の実施形態と同じである。
【００７７】
本実施形態においては、図９に示すように、他ノードからのメモリアクセスに対する応答として或るノードのＳＣＳから訂正不可能な異常終了ｆ４がＸＢＣに出されると、ＸＢＣは当該訂正不可能な異常終了を全ノードにブロードキャストする（ｄ４〜ｄ７）。アクセス要求元では図５のステップＳ１０により自ノードのメモリアクセス元に共有通信エリア障害通知を出し、以後、第１の実施形態で説明した処理が実施される。他方、アクセス要求元以外のノードのＳＣＳでは、ブロードキャストにて訂正不可能な異常終了を受信すると、共有通信エリア障害通知を自ノードの何れかのＭＰＵに出す（図９のｆ６）。これにより、アクセス要求元のノードからグローバルネットワーク６０経由で共有通信エリア障害通知が届く前に自ノードにおけるバッファ縮退処理を開始することができる。なお、その後にグローバルネットワーク６０経由で届く共有通信エリア障害通知は自ノードに関しては無視される。勿論、アクセス要求元のノードは共有通信エリア障害通知をグローバルネットワーク６０経由で他ノードには送らず、クラスタサーバ７０だけに送るようにしても良い。
【００７８】
○第４実施形態
本発明の第４の実施形態は、何れかのノードからメモリアクセスに対する応答として訂正不可能な異常終了の転送が要求されたとき、ＸＢＣ５０が、訂正不可能な異常終了を共有通信エリア障害通知に変換して転送し、アクセス要求元のノードにおけるＳＣＳは受信した共有通信エリア障害通知をメモリアクセス元に通知するようにした点で、第１の実施形態と相違し、それ以外は第１の実施形態と同じである。
【００７９】
本実施形態においては、図１０に示すように、他ノードからのメモリアクセスに対する応答として或るノードのＳＣＳから訂正不可能な異常終了ｆ４がＸＢＣに出されると、ＸＢＣは当該訂正不可能な異常終了を共有通信エリア障害通知ｄ８に変換し、アクセス要求元のノードに転送する。アクセス要求元では図５のステップＳ７において、終了通知の結果がアドレスエラーか、正常終了か、共有通信エリア障害通知かを判別し、共有通信エリア障害通知であれば、ステップＳ１０でメモリアクセス元にそれを通知する。これにより、アクセス要求元ノードにおけるＳＣＳの処理は、アドレスエラーが返却されたとき以外は単に受信した内容をメモリアクセス元に通知するという通常の処理に簡便化できる。
【００８０】
○第５実施形態
本発明の第５の実施形態は、何れかのノードからメモリアクセスに対する応答として訂正不可能な異常終了の転送が要求されたとき、ＸＢＣ５０が、共有通信エリア障害通知に変換して、宛先のノードだけでなく全ノードに共有通信エリア障害通知をブロードキャストし、アクセス要求元のノードにおけるＳＣＳは受信した共有通信エリア障害通知をメモリアクセス元に通知し、他方、ブロードキャストにて共有通信エリア障害通知を受信したノードのＳＣＳは自ノードのＭＰＵにその共有通信エリア障害通知を出すようにした点で、第１の実施形態と相違し、それ以外は第１の実施形態と同じである。
【００８１】
本実施形態においては、図１１に示すように、他ノードからのメモリアクセスに対する応答として或るノードのＳＣＳから訂正不可能な異常終了ｆ４がＸＢＣに出されると、ＸＢＣは当該訂正不可能な異常終了を共有通信エリア障害通知に変換し、全ノードにブロードキャストする（ｄ８〜ｄ１１）。アクセス要求元のノードでは図５のステップＳ７において、終了通知の結果がアドレスエラーか、正常終了か、共有通信エリア障害通知かを判別し、共有通信エリア障害通知であれば、ステップＳ１０でメモリアクセス元にそれを通知する。これにより、アクセス要求元ノードにおけるＳＣＳの処理は、アドレスエラーが返却されたとき以外は単に受信した内容をメモリアクセス元に通知するという通常の処理に簡便化できる。また、ブロードキャストにて共有通信エリア障害通知を受信した他ノードのＳＣＳは、それを自ノード内の何れかのＭＰＵに通知する（図１１のｆ７）。これにより、アクセス要求元のノードからグローバルネットワーク６０経由で共有通信エリア障害通知が届く前に自ノードにおけるバッファ縮退処理を開始することができる。なお、その後にグローバルネットワーク６０経由で届く共有通信エリア障害通知は自ノードに関しては無視される。勿論、アクセス要求元のノードは共有通信エリア障害通知をグローバルネットワーク６０経由で他ノードには送らず、クラスタサーバ７０だけに送るようにしても良い。
【００８２】
○第６実施形態
本発明の第６の実施形態は、他ノードから自ノードに実装されている共有通信エリアに対するメモリアクセス要求があった場合に訂正不可能な障害が発生したとき、図１２に示すように、自ノードのＳＣＳが当該メモリアクセスの応答として共有通信エリア障害通知をＸＢＣ経由で要求元のノードに出すようにした点（ｆ８，ｄ１２）で、第１の実施形態と相違し、それ以外は第１の実施形態と同じである。
【００８３】
本実施形態においては、各ノードのＳＣＳにおける図６のステップＳ３８の処理が、要求元のノードに対して共有通信エリア障害通知をＸＢＣ５０経由で通知する処理に変更される。また、アクセス要求元では図５のステップＳ７において、終了通知の結果がアドレスエラーか、正常終了か、共有通信エリア障害通知かを判別し、共有通信エリア障害通知であれば、ステップＳ１０でメモリアクセス元にそれを通知する処理となる。
【００８４】
○第７実施形態
本発明の第７の実施形態は、他ノードから自ノードに実装されている共有通信エリアに対するメモリアクセス要求があった場合に訂正不可能な障害が発生したとき、図１３に示すように、自ノードのＳＣＳが当該メモリアクセスの応答として共有通信エリア障害通知をＸＢＣ経由で要求元のノードに出すと共に自ノードの何れかのＭＰＵに当該共有通信エリア障害通知を出すようにした点（ｆ８，ｄ１２，ｆ９）で、第１の実施形態と相違し、それ以外は第１の実施形態と同じである。
【００８５】
本実施形態においては、各ノードのＳＣＳは、図６のステップＳ３８において、要求元のノードに対して共有通信エリア障害通知をＸＢＣ５０経由で通知すると共に自ノードの何れかのＭＰＵに当該共有通信エリア障害通知を出す。また、アクセス要求元では図５のステップＳ７において、終了通知の結果がアドレスエラーか、正常終了か、共有通信エリア障害通知かを判別し、共有通信エリア障害通知であれば、ステップＳ１０でメモリアクセス元にそれを通知する。これにより、アクセス要求元のノードからグローバルネットワーク６０経由で共有通信エリア障害通知が届く前に自ノードにおけるバッファ縮退処理を開始することができる。なお、その後にグローバルネットワーク６０経由で届く共有通信エリア障害通知は自ノードに関しては無視される。
【００８６】
○第８実施形態
本発明の第８の実施形態は、他ノードから自ノードに実装されている共有通信エリアに対するメモリアクセス要求があった場合に訂正不可能な障害が発生したとき、図１４に示すように、自ノードのＳＣＳが当該メモリアクセスの応答として共有通信エリア障害通知ｆ８を出し、ＸＢＣは、この共有通信エリア障害通知をアクセス要求元のノードを含めて全ノードにブロードキャストするようにした点（ｄ１２〜ｄ１５）で、第１の実施形態と相違し、それ以外は第１の実施形態と同じである。
【００８７】
本実施形態においては、各ノードのＳＣＳは、図６のステップＳ３８において、ＸＢＣ５０に対して共有通信エリア障害通知の転送を要求する。また、アクセス要求元では図５のステップＳ７において、終了通知の結果がアドレスエラーか、正常終了か、共有通信エリア障害通知かを判別し、共有通信エリア障害通知であれば、ステップＳ１０でメモリアクセス元にそれを通知する。さらに、ブロードキャストにて共有通信エリア障害通知を受信したノードのＳＣＳは、それを自ノード内の何れかのＭＰＵに通知する。これにより、アクセス要求元のノードからグローバルネットワーク６０経由で共有通信エリア障害通知が届く前に自ノードにおけるバッファ縮退処理を開始することができる。なお、その後にグローバルネットワーク６０経由で届く共有通信エリア障害通知は自ノードに関しては無視される。勿論、アクセス要求元のノードは共有通信エリア障害通知をグローバルネットワーク６０経由で他ノードには送らず、クラスタサーバ７０だけに送るようにしても良い。
【００８８】
○第９実施形態
本発明の第９の実施形態は、サービスプロセッサ（以下、ＳＰと称す）を有するクラスタ計算機に本発明を適用し、訂正不可能なメモリ障害が共有通信エリアで発生したか否かの判断と共有通信エリア障害などの通知をＳＰに行わせるようにしたものである。本実施形態のクラスタ計算機２の全体構成例を図１５に示す。図１の構成と相違し、各々のノード１０，２０，３０，４０が、ＩＯＣ１３，２３，３３，４３において、信号線１９，２９，３９，４９を通じてＳＰ８０に接続されている。
【００８９】
本例のクラスタ計算機２では、何れかのノードにおけるＭＭＵにおいて訂正可能な障害および訂正不可能な障害が発生した場合、そのＭＭＵは自ノードのＳＣＳ経由でＳＰ８０に対し、障害報告を出す。この障害報告では、障害メモリアドレス、訂正可能な障害か訂正不可能な障害かの区別、アクセス要求元のノード等の情報が含まれる。ＳＰ８０はこの障害報告の受信時に図１６に示す処理を実行する。
【００９０】
ＳＰ８０は先ず、受信した障害報告の内容を障害ログとして保存する（ステップＳ４１）。次いで、今回の報告が訂正不可能なメモリ障害か否かを判別し（ステップＳ４２）、訂正可能なメモリ障害であった場合には図１６の処理を終える。他方、訂正不可能なメモリ障害であった場合には、その障害が共有通信エリアで生じたか、ノード固有エリアで生じたかを以下のようにしてチェックする（ステップＳ４３）。
【００９１】
ＳＰ８０は、各ノードが保有する図３に示したメモリ管理用テーブル１５ａ，２５ａ，３５ａ，４５ａを自身も保持している。障害報告を出したノードに対応するメモリ管理用テーブルを障害メモリアドレスで検索し、障害メモリアドレスを開始アドレス１５２からメモリ長１５３のアドレス範囲内に含むエントリの共有／固有フラグ１５１の値を調べ、０であれば、そのノードのノード固有エリアで訂正不可能なメモリ障害が発生したと判断し、１であれば、共有通信エリアで訂正不可能なメモリ障害が発生したと判断する（ステップＳ４４）。
【００９２】
次にＳＰ８０は、訂正不可能なメモリ障害がノード固有エリアで発生していたときは、アクセス要求元のノードに対して、システム停止障害通知を出す（ステップＳ４５）。他方、共有通信エリアで訂正不可能なメモリ障害が発生していたときは、アクセス要求元のノードに対して障害メモリアドレスを含む共有通信エリア障害通知を出す（ステップＳ４６）。
【００９３】
図１７に本実施形態において或るノード内のＭＰＵまたはＩＯＣからメモリアクセス要求が出された際のメモリアクセスに関連する信号の流れを示す。以下、図１７を参照して本実施形態の動作を図７に示した第１の実施形態の動作との相違点を中心に説明する。
【００９４】
他ノードからのメモリアクセス要求ｄ１を受けたノードにおいて、自ノードのＭＭＵに対してメモリアクセス要求ｆ２が出された際、訂正可能な障害および訂正不可能な障害が発生した場合、そのＭＭＵからＳＣＳ経由でＳＰ８０に対して障害報告ｅ３が出される。また、障害が訂正不可能なときには第１の実施形態と同様に訂正不可能な異常終了ｅ２がＳＣＳに出され、ＳＣＳはこれをＸＢＣ５０を通じてアクセス要求元のノードのＳＣＳに通知する（ｆ４，ｄ４）。
【００９５】
障害報告ｅ３を受信したＳＰ５０は図１６に示した処理により、障害情報のログを取り、訂正不可能な障害の場合にはその障害発生箇所に応じた処理を行う。他ノードからのメモリアクセス要求ｄ１は共有通信エリアに対するアクセスなので、ここでは共有通信エリアで訂正不可能な障害が発生したと判断され、アクセス要求元のノードのＳＣＳに対して共有通信エリア障害通知が出される（ｇ１）。アクセス要求元のノードのＳＣＳは、この共有通信エリア障害通知ｇ１を受信することにより、共有通信エリア障害通知ｂ１１をメモリアクセスに対する応答としてメモリアクセス元に通知し、メモリアクセス元は第１の実施形態で説明したと同様の動作を開始する。
【００９６】
一方、自ノード内で発生したノード固有エリアに対するメモリアクセス要求ｂ３の処理でＭＭＵにおいて訂正可能な障害および訂正不可能な障害が発生した場合、そのＭＭＵからＳＣＳ経由（図１７では省略）でＳＰ８０に対して障害報告ｃ３が出される。また、障害が訂正不可能なときには第１の実施形態と同様に訂正不可能な異常終了ｃ２がＳＣＳに出される。
【００９７】
障害報告ｃ３を受信したＳＰ８０は図１６に示した処理により、障害情報のログを取り、訂正不可能な障害の場合にはその障害発生箇所に応じた処理を行う。自ノード内でのメモリアクセスはノード固有エリアに対するアクセスと、共有通信エリアに対するアクセスとの双方があるため、ＳＰ８０は、当該ノードのノード固有エリアで訂正不可能な障害が発生していた場合には、当該ノードのＳＣＳに対してシステム停止障害通知ｇ２を出す。当該ノードのＳＣＳは、このシステム停止障害通知ｇ２を受信することにより、システム停止障害通知ｂ１２をメモリアクセスに対する応答としてメモリアクセス元に通知し、メモリアクセス元は第１の実施形態で説明したと同様の動作を開始する。他方、共有通信エリアで訂正不可能な障害が発生していた場合、ＳＰ８０は、当該ノードのＳＣＳに対して共有通信エリア障害通知ｇ３を出す。当該ノードのＳＣＳは、この共有通信エリア障害通知ｇ３を受信することにより、共有通信エリア障害通知ｂ１３をメモリアクセスに対する応答としてメモリアクセス元に通知する。
【００９８】
本実施形態では、メモリアクセス時に訂正不可能な誤りが発生した際に、ＳＰ８０で生成された共有通信エリア障害通知やシステム停止障害通知をメモリアクセス元に通知するため、第１の実施形態に比べて、メモリアクセス元がメモリアクセス要求を出してから上記通知を受けるまでに時間がかかる。そのため、場合によってはタイムアウトが生じる可能性がある。そこで、本実施形態では、他ノードに対してメモリアクセス要求を転送したノードのＳＣＳは、相手ノードから訂正不可能な異常終了ｄ４を受けたとき、メモリアクセス元に対してウエイト通知ｂ１４を出す。また、自ノードからのメモリアクセス要求を自ノードのＭＭＵに対して出したときにＭＭＵから訂正不可能な異常終了ｃ２が通知されたとき、メモリアクセス元に対してウエイト通知ｂ１５を出す。これらのウエイト通知ｂ１４，ｂ１５は、タイムアウトを回避するための疑似的な通知であり、メモリアクセス元はウエイト通知を受信するとタイムアウトの監視を停止し、システム停止障害通知または共有通信エリア障害通知が届くのを待つ。
【００９９】
本実施形態において、訂正不可能なメモリ障害が共有通信エリア，メモリ固有エリアの何れで発生したか否かの判断や共有通信エリア障害通知などの通知をＳＰ８０が実施しているため、各ノードのＳＣＳは図５のアドレスチェック（Ｓ１５）関連の処理を実施する必要がなく、図１８に示されるように各ノードのＳＣＳの処理が簡便化される。
【０１００】
○第１０の実施形態
本発明の第１０の実施形態は、ＳＰ８０が共有通信エリアにおいて訂正不可能な障害が発生したと判断したとき、図１９のｇ１，ｇ４〜ｇ６、ｇ２，ｇ７〜ｇ９に示すように、アクセス要求元だけでなく他の全てのノードに共有通信エリア障害通知を出すようにした点で第９の実施形態と相違し、その他は第９の実施形態と同じである。共有通信エリア障害通知を受信した各ノードのＳＣＳは、それを自ノード内のＭＰＵに通知する（ｆ１１，ｆ１２）。これにより、各ノードにおけるバッファ縮退処理を速やかに開始することができる。
【０１０１】
以上本発明の実施形態について説明したが、本発明は以上の実施形態にのみ限定されず、その他各種の付加変更が可能である。例えば、以下のように構成することができる。
【０１０２】
共有通信エリアがバッファ単位での縮退が行えない構成。この場合、共有通信エリアで訂正不可能な障害が発生したときは、前述した実施形態において、有効なバッファが１つも存在しなくなった場合の処理が直ちに実施される。
【０１０３】
ＸＢＣ経由の共有メモリモデルに従ったノード間通信だけがサポートされており、グローバルネットワーク経由のメッセージ交換モデルに従ったノード間通信がサポートされていない構成。この場合、自ノードに実装された共有通信エリアが訂正不可能な障害により使用できなくなったノードは、クラスタ構成上はノードダウンとなる。しかし、自ノードに閉じて実行されるジョブはなおも継続して実行可能である。
【０１０４】
専用のクラスタサーバ７０を有しない構成。この場合、何れかのノードがクラスタサーバ７０の機能を合わせ持つ構成となる。
【０１０５】
【発明の効果】
以上説明したように本発明によれば、メモリアクセス時に訂正不可能な障害が発生したときの通知として、システム障害停止通知と共有通信エリア障害通知との２種類を定義し、訂正不可能な障害が発生した箇所がノード固有エリアであればシステム障害停止通知を出すが、共有通信エリアであればシステム障害停止通知ではなく、より軽度の障害が発生したことを示す共有通信エリア障害通知を出すことにより、他ノードに実装されたメモリの共有通信エリアで発生した訂正不可能な障害によって、その共有通信エリアをアクセスしたノードがシステムダウンするのを防止でき、また、自ノードに実装されたメモリの共有通信エリアで発生した訂正不可能な障害によって、自ノードがシステムダウンするのを防止でき、クラスタ計算機の可用性を高めることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態にかかるクラスタ計算機の構成例を示すブロック図である。
【図２】クラスタ計算機のメモリ構成の説明図である。
【図３】メモリ管理用テーブルの説明図である。
【図４】共有通信エリア内のバッファの構成例とバッファ管理テーブルの一例を示す図である。
【図５】自ノードのＭＰＵまたはＩＯＣからメモリアクセス要求を受けた際のＳＣＳの処理例を示すフローチャートである。
【図６】他ノードからメモリアクセス要求を受けた際のＳＣＳの処理例を示すフローチャートである。
【図７】本発明の第１の実施の形態におけるメモリアクセスの処理の流れを示す図である。
【図８】本発明の第２の実施の形態におけるメモリアクセスの処理の流れを示す図である。
【図９】本発明の第３の実施の形態におけるメモリアクセスの処理の流れを示す図である。
【図１０】本発明の第４の実施の形態におけるメモリアクセスの処理の流れを示す図である。
【図１１】本発明の第５の実施の形態におけるメモリアクセスの処理の流れを示す図である。
【図１２】本発明の第６の実施の形態におけるメモリアクセスの処理の流れを示す図である。
【図１３】本発明の第７の実施の形態におけるメモリアクセスの処理の流れを示す図である。
【図１４】本発明の第８の実施の形態におけるメモリアクセスの処理の流れを示す図である。
【図１５】本発明を適用したクラスタ計算機の別の例を示すブロック図である。
【図１６】サービスプロセッサの処理例を示すフローチャートである。
【図１７】本発明の第９の実施の形態におけるメモリアクセスの処理の流れを示す図である。
【図１８】自ノードのＭＰＵまたはＩＯＣからメモリアクセス要求を受けた際のＳＣＳの他の処理例を示すフローチャートである。
【図１９】本発明の第１０の実施の形態におけるメモリアクセスの処理の流れを示す図である。
【符号の説明】
１，２…クラスタ計算機
１０，２０，３０，４０…ノード
１１，１２，２１，２２，３１，３２，４１，４２…ＭＰＵ
１３，２３，３３，４３…ＩＯＣ
１４，２４，３４，４４…ＭＭＵ
１５，２５，３５，４５…ＳＣＳ
１６，２６，３６，４６…システムバス
１７，１８，１９，２７，２８，２９，３７，３８，３９，４７，４８，４９，７１…信号線
５０…ＸＢＣ
６０…グローバルネットワーク
７０…クラスタサーバ
８０…ＳＰ
【図１】
0003866426.tif 000002
【図２】
0003866426.tif 000003
【図３】
0003866426.tif 000004
【図４】
0003866426.tif 000005
【図５】
0003866426.tif 000006
【図６】
0003866426.tif 000007
【図７】
0003866426.tif 000008
【図８】
0003866426.tif 000009
【図９】
0003866426.tif 000010
【図１０】
0003866426.tif 000011
【図１１】
0003866426.tif 000012
【図１２】
0003866426.tif 000013
【図１３】
0003866426.tif 000014
【図１４】
0003866426.tif 000015
【図１５】
0003866426.tif 000016
【図１６】
0003866426.tif 000017
【図１７】
0003866426.tif 000018
【図１８】
0003866426.tif 000019
【図１９】
0003866426.tif 000020