JPH08287021A - 共用メモリに結合される複数の計算機システム及び共用メモリに結合される複数の計算機システムの制御方法 - Google Patents

Abstract

(57)【要約】 【課題】 本発明の目的は、複数のクラスタにより負荷
分散をして処理しなければならない大規模システムを、
仮想計算機により運用されている複数のゲストを有する
複数のクラスタ間で通信を行うことが可能な共用メモリ
に結合される複数の計算機システムを提供することであ
る。 【解決手段】 本発明は、実計算機制御手段４４０を有
する少なくとも１つの第１の実計算機４００（以下、第
１のクラスタ）または／及び、少なくとも１つの仮想計
算機を含み、実計算機制御手段２４０、仮想計算機を制
御する仮想計算機用制御手段２１０とを有する複数の第
２の実計算機（以下、第２のクラスタ）が共用メモリ１
００に接続される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、共用メモリに結合
される複数の計算機システム及び共用メモリに結合され
る複数の計算機システムの制御方法に係り、特に、共用
メモリに結合された複数の計算機間で種々の制御を行う
ための、共用メモリに結合される複数の計算機システ
ム、及び共用メモリに結合される複数の計算機システム
の制御方法に関する。

【０００２】近年のコンピュータシステムでは、単一プ
ロセッサの能力の伸びの鈍化、信頼性向上の強いニーズ
等の理由から共用メモリを介した複数の計算機システム
により構築されたシステムが一般的になりつつある。ま
た、共用メモリを介して１つの計算機システムを複数の
仮想計算機システムとして利用することが要求されてい
る。

【０００３】さらには、仮想計算機システムを制御する
ＯＳであるＡＶＭで運用された計算機の異常によるダウ
ンを検出し、ホットスタンバイが可能なシステムが要求
されている。

【０００４】

【従来の技術】

（１） 従来の計算機システム−１ 最初に従来の第１の計算機システムを説明する。図４７
は、従来の第１の計算機システムの構成例を示す。

【０００５】同図の例は、１つの実計算機（以下、クラ
スタと記す）１０を複数の仮想計算機１１-1〜１１-n
（以下、ゲストクラスタと記す）で運用する例である。
クラスタ１０は、仮想計算機であるゲストクラスタ１１
-1〜１１-n制御用の制御オペレーティングシステム（以
下、ＡＶＭと記す）１２を有し、当該ＡＶＭが複数のゲ
ストクラスタ１１-1〜１１-nを制御する。

【０００６】（２） 従来の計算機システム−２ 第２に、計算機システムが外部記憶装置と接続されてい
る場合について説明する。図４８は、従来の第２の計算
機システムの構成例を示す。

【０００７】同図の例は、上記に示した１つの第１の計
算機システム（クラスタ）１０が外部記憶装置（以下、
ＳＳＵと記す）５０に接続されている例を示している。
クラスタ１０とＳＳＵ５０は、１台のＳＳＵ５０が有す
る実アクセスパス６０により接続され、クラスタ１０は
ＳＳＵ５０に対して情報の読出し／書き出しの処理を実
行する。

【０００８】また、クラスタ１０は、ＡＶＭ１２と複数
のゲストクラスタ１１−１〜１１−ｎを有する。ＡＶＭ
１２とゲストクラスタ１１の間には、各々論理（仮想）
アクセスパス７１が介在している。ゲストクラスタ１１
−１から１１−ｎは、このアクセスパス７１、及びＡＶ
Ｍ１２を介してＳＳＵ５０より情報の読出しや書込みを
行う。

【０００９】図４９は、従来の第２の計算機システムを
説明するための図である。同図に示すシステムは、従来
の第２の計算機システムにおいて、ＳＳＵ５１にアクセ
スパス６１を介してクラスタ１０が接続され、アクセス
パス６２を介してクラスタ２０が接続されている。ＳＳ
Ｕ５２には、アクセスパス６３を介してクラスタ３０が
接続され、アクセスパス６４を介してクラスタ４０が接
続されている。

【００１０】このうち、ＳＳＵ５１に接続されるクラス
タ１０がＳＳＵ５１に対して処理を実行中であり、クラ
スタ２０は、１つのゲストクラスタがＡＶＭの制御によ
り処理待ち状態であり、クラスタ２０内の他のゲストク
ラスタは開発に使用されている。また、ＳＳＵ５２に接
続されるクラスタ３０は、ＳＳＵ５２に対して処理を実
行中であり、クラスタ４０は、処理待機中となってい
る。このように、図４９に示すシステムは、ホットスタ
ンバイにおいて、１つのＳＳＵ５１（５２）に対して１
つのクラスタ１０（３０）が実行している時は、他のク
ラスタ２０（４０）は、待機中とすることにより排他制
御を行っている。

【００１１】（３） 従来の計算機システム−３ 第３に１つのＳＳＵに複数のクラスタが接続されている
場合について説明する。図５０は、従来の第３の計算機
システムの構成例を示す。

【００１２】同図に示す計算機システムは、１つのＳＳ
Ｕ５０に複数のクラスタ１０、２０、３０、４０が接続
されている例である。ＡＶＭ運用のクラスタ３０、４０
内のゲストクラスタは、各々クラスタ内で相対的な計算
機番号（以下、相対計算機番号と言う）を有している。
例えば、クラスタ３０の各ゲストクラスタの相対計算機
番号は、ゲストクラスタ３１-1＝“１”、ゲストクラス
タ３１-2＝“２”、ゲストクラスタ３１-3＝“３”、ゲ
ストクラスタ３１-4＝“４”のように付与されている。
また、クラスタ４０についても同様に、ゲストクラスタ
４１-1＝“１”、ゲストクラスタ４１-2＝“２”、ゲス
トクラスタ４１-3＝“３”、ゲストクラスタ４１-4＝
“４”のように相対計算機番号が付与されている。ま
た、クラスタ１０、２０についてもクラスタ１０＝０、
クラスタ２０＝１、クラスタ３０＝２、クラスタ４０＝
３のように予め実計算機番号が設定されている。

【００１３】ここで、仮想計算機により運用されている
クラスタ３０のゲストクラスタ３１-1をオペレータ８０
が指定する場合について述べる。オペレータ８０は、ク
ラスタ３０の実計算機番号“２”を指定すると、実計算
機番号“２”のクラスタ上のＡＶＭ３２が設定される。
この場合、ＡＶＭ３２は、予め定められた順序または、
配列順にクラスタ３０内のゲストクラスタ３１-1を示す
相対計算機番号（例えば、“１”）を指定したことにな
る。即ち、ＳＳＵを介した複数の計算機システムにおい
て、ＡＶＭ運用された計算機内では、１つのゲストクラ
スタのみ、他の計算機と結合することができる。従っ
て、実計算機番号と仮想計算機番号が１対１の関係であ
るため、実計算機番号を指定しても、その指定番号から
仮想計算機を特定することが可能である。つまり、オペ
レータが実計算機番号“２”を指定するということは、
ゲストクラスタ“３１−１”を指定するのと同義であ
る。

【００１４】（４） 従来の計算機システムの通信方式 第４に従来の計算機システムにおいて、クラスタ間で通
信を行う場合について説明する。図５１は、従来の第３
の計算機システムにおける通信システムを説明するため
の図（その１）である。同図に示すように、１つのＳＳ
Ｕ５０を複数のクラスタ２０、３０、４０で共用してい
るとき、クラスタ間でＳＳＵ５０を介して他計算機と通
信する場合には、クラスタ同士が相手先のクラスタの実
計算機番号を指定して通信する。例えば、同図におい
て、クラスタ１０がクラスタ２０を指定する場合には、
クラスタ１０の実計算機番号が“０”であり、クラスタ
２０の実計算機番号が“１”であるとき、クラスタ１０
は、クラスタ２０の実計算機番号“１”を指定すること
により、通信を行う。また、クラスタ４０は、複数のゲ
ストクラスタ４１−１〜４１−ｎを有している。このと
き、クラスタ４０のゲストクラスタ４１−３は、クラス
タ２０の実計算機番号“１”を指定して、ＡＶＭ４２と
ＳＳＵ５０を介してクラスタ２０と通信することが可能
である。また、クラスタ１０、クラスタ２０、または、
クラスタ４０に対して通信を行う場合には、実計算機番
号“２”を指定することで、ＳＳＵ５０を介して通信す
ることが可能である。

【００１５】（５） 従来の通信時における割り込み処
理 次に、従来の通信における割り込み時の処理について説
明する。前述の１つのＳＳＵを複数のクラスタで共用し
ている複合システムにおいて、ＧＳＩＧＰ命令によりシ
ステム間の通信を行うことが可能であり、割り込みの保
留状態や反映状態を正確に把握するには、割り込みの保
留状態を利用して、図５２に示すような通信処理を行
う。なお、ＧＳＩＧＰ命令の機能には、クラスタ間の通
信機能と他クラスタの制御機能がある。他クラスタの制
御機能とは、ダウンクラスタを制御する際に用いるもの
であり、ＣＰＵ停止、Ｉ／Ｏリセット、ダンプ採取等を
行うものである。

【００１６】図５２は、従来の通信時における割り込み
処理を説明するためのシーケンスチャートである。クラ
スタＡとクラスタＢが通信を行うものとして説明する。 ステップ１） クラスタＡは、通信要求としてＧＳＩＧ
Ｐ命令をＳＳＵを介してクラスタＢに発行する。

【００１７】ステップ２） クラスタＢは、割り込みが
反映状態でないため、ハードウェアで割り込みを保留し
ておく。 ステップ３） クラスタＡは、次の通信要求が発生した
場合、ＧＳＩＧＰ命令をＳＳＵを介して発行する。

【００１８】ステップ４） ＳＳＵは、クラスタＢが割
り込み保留状態であると判定された場合に、その割り込
みがいずれ確実にクラスタＢに反映されることを前提と
して、クラスタＡからのＧＳＩＧＰ命令を受け取り、Ｓ
ＳＵ上にキューイングする。 ステップ５） クラスタＢは、割り込みが反映可能とな
った時点で、ハードウェアが保留状態を解除し、割り込
みを反映する。

【００１９】ステップ６） クラスタＢは、割り込まれ
た通信要求と共にＳＳＵ上にキューイングされていた通
信要求も処理する。なお、ＳＳＵ上に通信要求をキュー
イングし、１回の割り込みで複数の通信要求を処理する
ことができる。

【００２０】（６） 従来のシステム制御 従来の実計算機で運用されるクラスタ同士でＳＳＵを共
用した複合システムの場合、ＧＳＩＧＰ命令（リセッ
ト）により、ダウンしたシステムを他のクラスタシステ
ムからリセットするようなシステム制御を行うことがで
き、このリセット完了に基づいて、ホットスタンバイに
よるシステムの切り替えを行う。

【００２１】図５３は、従来のシステム制御のリセット
処理を説明するためのシーケンスチャートである。以下
の説明では、クラスタＡがクラスタＢをリセット制御す
る場合について述べる。

【００２２】ステップ１０） クラスタＡは、クラスタ
Ｂをリセットするため、ＧＳＩＧＰ命令（リセット）を
発行する。 ステップ１１） クラスタＢは、ＳＳＵを介してハード
ウェアでシステムのリセットを開始する。

【００２３】ステップ１２） クラスタＡがリセット完
了／リセット中をＧＳＩＧＰ命令（センス）を発行する
ことで認識できる。 ステップ１３） クラスタＡは、ＧＳＩＧＰ命令（セン
ス）の結果によりリセット中を認識する通知する。

【００２４】ステップ１４） クラスタＢは、ハードウ
ェアでのリセットを完了する。 ステップ１５） クラスタＡが、ＧＳＩＧＰ命令（セン
ス）を発行する。 ステップ１６） クラスタＡは、クラスタＢがリセット
を完了したことをＧＳＩＧＰ命令（センス）の結果によ
り認識する。

【００２５】（７） 従来のダウン時における処理 従来、ＯＳがダウンを検出すると、ＧＳＩＧＰ命令（Ｃ
ＰＵ停止）やＧＳＩＧＰ命令（リセット）等により、ダ
ウンクラスタの制御を行う。なお、ＧＳＩＧＰ命令は、
各クラスタ毎に配置されているサービスプロセッサが受
け付け、実行する。また、サービスプロセッサは、ＧＳ
ＩＧＰ命令（ペンディング）が永久に続く場合を想定
し、タイマ監視を行い、タイムアウトになった場合に強
制リセットを行う。

【００２６】また、ゲストクラスタがセッション閉塞
（ＤＥＡＣＴＩＶＡＴＥ）した場合には、ＡＶＭがゲス
トクラスタのセッション閉塞を認識し、ゲストクラスタ
とＡＶＭ間の論理パスを切断することにより、ゲストク
ラスタを切り離す処理を行う。

【００２７】

【発明が解決しようとする課題】しかしながら、上記の
従来の（１）〜（７）の各システムには、以下のような
問題がある。 上記図４７から図４９に示すシステムは、クラスタ
単独または、ＳＳＵとクラスタが直接接続されている構
成であり、他のクラスタ間との情報の授受を行うことは
可能であるが、ＡＶＭ運用した場合に１クラスタのみし
か行うことができないという問題がある。

【００２８】 複数のクラスタが同時にＩＰＬ操作に
より初期化を行うような場合に、同時に共用メモリに対
する初期化が行われる可能性があり、データの整合性が
とれなくなるという問題がある。さらに、ＩＰＬ操作を
介したＯＳが停止して、再度起動した場合には、システ
ムの誤動作に繋がる可能性もある。

【００２９】 また、図５０に示すシステムは、オペ
レータから指定されたゲストクラスタをＡＶＭで所定の
順序で指定することは可能であるが、図５４に示すよう
なシステムのように、クラスタ内の複数のゲストクラス
タに、予め指定順序が決定されていない場合や、同時に
動作するような場合には、実計算機番号だけでは仮想計
算機を特定することができない。図５４において、オペ
レータ８０がクラスタ３０の実計算機番号“２”を指定
すると、実計算機番号“２”の計算機上のＡＶＭ３２に
制御が渡る。しかし、ＡＶＭ３２は、このクラスタ３０
に組み込まれているどのゲストクラスタを指定すればよ
いのか判断できないため、ある特定のゲストクラスタを
対象した通信等の処理ができないという問題がある。

【００３０】 また、従来は、ＳＳＵを複数のクラス
タが使用する場合、あるクラスタを仮想計算機運用して
も１つのゲストクラスタしかＳＳＵを使用することがで
きないという制限がある。つまり、１台のクラスタを複
数のゲストクラスタで運用し、さらにそれらの構成のク
ラスタを何台もＳＳＵを介して接続された複合システム
を構築しようとしても、実計算機番号のみ管理している
ため、配下のゲストクラスタを特定することができな
い。

【００３１】 また、あるクラスタから他のＡＶＭ運
用の第１のクラスタに対して通信（ＧＳＩＧＰ命令）を
発行したとき、第２のクラスタにおいて受け付けられな
い状態である場合に保留となる。このとき、第１のクラ
スタが他のＡＶＭの第２のクラスタ宛に通信を発行した
場合、保留状態であるため、この通信はキューイングさ
れる。しかし、他のＡＶＭの第１のクラスタが受け付け
可能となったときに、ＳＳＵ上にキューイングされてい
る要求は第２のクラスタ宛であるため、一緒に処理され
ない。このため、ＡＶＭで要求を保留しない方法が考え
られる。しかし、計算機間のＳＳＵを共用する通信時に
おいて割り込みがある場合には、クラスタＡから発行さ
れたＧＳＩＧＰ命令がＡＶＭに反映する前に、送信側の
プログラムに割り込みが反映されてしまうため、ハード
ウェア内には割り込みが保留されない。このような場合
に、他系のクラスタからは、割り込みが反映されたよう
に見えてしまうため、仮にＡＶＭに割り込みが反映され
ない状態であっても、クラスタＡからクラスタＢのＡＶ
Ｍの状態を正確に把握できない。そのため、ＡＶＭが割
り込み保留状態の場合でも送信側のプログラムにＡＶＭ
宛の通信要求が次々に発生するが、制御プログラムは割
り込みを棄却してしまい、ＡＶＭの通信が正しく行われ
ないという問題がある。また、保留状態によりＳＳＵ上
に通信要求をキューイングしても、その保留となった割
り込みが他のＡＶＭ宛である場合、シーケンシャルにキ
ューイングされている要求が、該当するＡＶＭに対して
いつまでも反映されないため、ＳＳＵ上の通信要求が該
当するＡＶＭに通知できないという問題がある。

【００３２】 また、ＳＳＵを共用するシステムが複
数の仮想計算機で運用されるクラスタであった場合、実
計算機で運用されるクラスタ同士の時と同じようにＧＳ
ＩＧＰ命令（ＣＰＵ宛）を発行すると、ＡＶＭが動作す
るクラスタシステムのＣＰＵが停止してしまう。また、
特開平５−３２４３６２号「計算機システム間の通信割
り込み制御方式」を適用しても複数の仮想計算機により
運用されているクラスタでＳＳＵを共用すると、ＧＳＩ
ＧＰ命令（リセット）発行元でリセット完了契機が正し
く認識できなくなるという問題がある。これは、ある仮
想計算機により運用されているクラスタの１つのゲスト
クラスタ（例えば、ゲストクラスタａ）が他のクラスタ
（例えば、クラスタＡ）からのＧＳＩＧＰ命令（リセッ
ト）によりリセット処理中である場合には、別のクラス
タ（例えば、クラスタＢ）からゲストクラスタａと同じ
制御プログラム下にあるゲストクラスタｂのリセット要
求や通信要求ができなくなるからである。このような状
況を解決するために、プログラムがＡＶＭのリセットを
起動する段階でプログラムからハードウェア（実計算機
制御機能）に対してリセット処理中解除を指示した場合
であっても、ＧＳＩＧＰ命令（リセット）発行元でリセ
ットの完了（リセット処理中が解除）が正しく認識でき
なくなるという問題がある。図５５は、従来の問題点を
説明するための図（その２）である。同図に付されてい
る○内の番号と以下の番号は一致するものとする。

【００３３】 クラスタＡから仮想計算機により運用
されているクラスタＶのゲストクラスタａをリセットす
るためにＧＳＩＧＰ命令（ゲストクラスタａ宛リセッ
ト）を発行する。 クラスタＶでは、クラスタＡからのリセット要求が
一旦ハードウェアで保留される。

【００３４】 クラスタＶのＡＶＭがリセット要求を
認識すると、ＡＶＭによりゲストクラスタａのリセット
処理を行う。 クラスタＢからクラスタＶのゲストクラスタｂをリ
セットするために、ＧＳＩＧＰ命令（ゲストクラスタｂ
宛リセット）を発行する。

【００３５】 クラスタＶのハードウェアがリセット
処理中状態のため、クラスタＢからゲストクラスタｂ宛
のリセット要求が受け付けられない。 ゲストクラスタａのリセットが完了すると、ＡＶＭ
は、ハードウェアに対してリセット保留の解除を指示す
る。

【００３６】 クラスタＡは、クラスタＶのゲストク
ラスタａのリセット完了を認識する。つまり、あるクラ
スタで発行したリセット要求により、ある仮想計算機が
リセット処理中である場合には、他のクラスタから現在
リセット処理中のＡＶＭ下にある別の仮想計算機からの
リセット要求や通信要求ができなくなる。

【００３７】図５６は、従来の問題点を説明するための
図（その３）である。同図に示す○内の番号と、以下の
番号は一致するものとする。 クラスタＡから仮想計算機により運用されているク
ラスタＶのゲストクラスタａをリセットするためにＧＳ
ＩＧＰ命令（リセット）を発行する。

【００３８】 特開平５−３２４３６２『計算機シス
テム間の割込制御方式』の方法により、リセット要求
が、クラスタＶのハードウェアで保留される。 仮想計算機により運用されているクラスタＶのＡＶ
Ｍは、リセット要求を認識すると、ハードウェアに対し
てリセット保留の解除を指示する。

【００３９】 ＡＶＭがゲストクラスタａのリセット
処理を行う。 クラスタＡでクラスタＶのゲストクラスタａのリセ
ット完了を誤認する。このように、仮想計算機により運
用されているクラスタのＡＶＭがリセット処理中解除を
指示すると、ＧＳＩＧＰ命令（リセット）発行元でリセ
ットの完了（リセット処理中解除）を誤認してしまうと
いう問題がある。

【００４０】さらに、従来の共用メモリを介して複数の
クラスタが接続されているシステム構成において、ＡＶ
Ｍ運用されているクラスタのゲストクラスタがダウンし
た場合に、クラスタ毎に付設されているサービスプロセ
ッサは、リセット処理が所定時間内に完了しない場合に
行う強制リセットを行うことができない。その理由は、
サービスプロセッサの強制リセットが動作する条件は、
ペンディング状態を認識した時である。従って、ＡＶＭ
が処理中の状態を解除するために、サービスプロセッサ
のタイマ監視が終了してしまい、ペンディング状態を認
識できないために強制リセットができない。

【００４１】また、ＡＶＭ運用されているゲストクラス
タがセッション閉塞（ＤＥＡＣＴＩＶＡＴＥ）時には、
ＡＶＭとゲストクラスタ間の論理パスを切断してしまう
ため、リセット等の制御がＯＳ側よりできない。従っ
て、オペレータがリセット等の処理を行う。このため、
セッション閉塞が発生する毎に、オペレータがリセット
を行わなければならないという問題がある。

【００４２】本発明は、上記の点に鑑みなされたもの
で、複数のクラスタにより負荷分散して処理しなければ
ならない大規模システムを、仮想計算機により運用され
ている複数のゲストクラスタを有する複数のクラスタ間
で通信を行うことが可能な共用メモリに結合される複数
の計算機システムを提供することを第１の目的とする。

【００４３】また、本発明の第２の目的は、共用メモリ
の初期化を開始した場合に、他のクラスタからの更新要
求を排他制御すると共に、停止したクラスタがあった場
合に、再動作等によるシステムの誤動作を防止すること
が可能な共用メモリに結合される複数の計算機システム
を提供することである。

【００４４】また、本発明の第３の目的は、仮想計算機
により運用されているクラスタのＡＶＭが各ゲストクラ
スタの計算機番号を設定し、それを各ＡＶＭのＯＳとゲ
ストクラスタ制御システムが相互に認識することが可能
な共用メモリに結合される複数の計算機システムを提供
することである。

【００４５】また、本発明の第４の目的は、ＳＳＵを介
して複数のクラスタ、仮想計算機により運用されている
クラスタが接続されるシステム間において、柔軟な通信
が可能な共用メモリに結合される複数の計算機システム
を提供することである。また、本発明の第５の目的は、
ＡＶＭへの割り込みが正しく反映されるような共用メモ
リに結合される複数の計算機システムを提供することで
ある。

【００４６】また、本発明の第６の目的は、複数の仮想
計算機システムでＳＳＵを共用した場合でも、ＧＳＩＧ
Ｐ命令（リセット）によるリセットの完了が発行元に正
しく認識可能となる共用メモリに結合される複数の計算
機システムを提供することである。

【００４７】また、本発明の第７の目的は、ＡＶＭ自身
の異常を検出し、他のクラスタに通知することが可能で
あり、ダウンしたクラスタ及び、ＡＶＭ運用しているク
ラスタの配下のゲストクラスタに対する制御を他のクラ
スタから行うことが可能な共用メモリに結合される複数
の計算機システムを提供することである。

【００４８】また、本発明の第８の目的は、自クラスタ
でダウンした状況を他の共用メモリに接続されるクラス
タに通知することが可能な共用メモリに結合される複数
の計算機システムを提供することである。また、本発明
の第９の目的は、ダウンしているクラスタがある場合
に、他のクラスタのＯＳから当該ダウンを認識すること
が可能な共用メモリに結合される複数の計算機システム
を提供することである。

【００４９】また、本発明の第１０の目的は、他のクラ
スタからダウンクラスタを認識した場合に、認識したク
ラスタからダウンクラスタの制御を行うことが可能な共
用メモリに結合される複数の計算機システムを提供する
ことである。また、本発明の第１１の目的は、ダウンし
たクラスタのＣＰＵ停止及びＩ／Ｏリセットを行い、ホ
ットスタンバイ状態にすることが可能な共用メモリに結
合される複数の計算機システムを提供することである。

【００５０】また、本発明の第１２の目的は、クラスタ
間でダウンクラスタの制御を行う場合に、ＡＶＭ運用の
クラスタのダウン時に、実クラスタと同様にハードウェ
アより強制的にリセットを指示することが可能な共用メ
モリに結合される複数の計算機システムを提供すること
である。

【００５１】また、本発明の第１３の目的は、オペレー
タ介入メッセージが表示され、オペレータが介入操作を
終了した時点で直ちに当該メッセージを消去できる共用
メモリに結合される複数の計算機システムを提供するこ
とである。

【００５２】

【課題を解決するための手段】図１は、本発明の原理構
成図である。第１の発明は、少なくとも１つの実計算機
（以下、実クラスタと記す）と外部記憶装置である共用
メモリとを結合する電子計算機システムにおいて、実ク
ラスタ４００及び仮想計算機運用された実クラスタの個
々のゲストクラスタとを制御するためのオペレーティン
グシステム（以下、ＯＳと記す）４０１を有する実クラ
スタまたは、仮想計算機システムを制御するためのＯＳ
（以下、ＡＶＭと記す）２１０を有する少なくとも１つ
の仮想計算機システム（以下、ＡＶＭ運用のクラスタと
記す）２００が共用メモリ１００に接続される。

【００５３】第２の発明は、第１の発明の実（ＮＡＴＩ
ＶＥ）クラスタ運用のＯＳまたは、仮想計算機運用され
た実クラスタ内の個々のゲストクラスタのＯＳが、共用
メモリ上の領域のロックを獲得するロック獲得手段を有
する。第３の発明は、第１及び第２の発明の実クラスタ
のＯＳ及びゲストクラスタ内のＯＳが、ロック獲得手段
によりロックを獲得しているクラスタのＯＳが停止して
いることを検出する第１の停止監視手段と、停止監視手
段により停止が検出されたクラスタと共用メモリとのア
クセスパスを切断するパス切断手段と、他のクラスタか
らのＩＰＬを契機として共用メモリの初期化を行う初期
化手段を有する。

【００５４】第４の発明は、第３の発明の実クラスタの
ＯＳ及びゲストクラスタ内のＯＳがロック獲得手段によ
りロックを獲得しているクラスタのＯＳが停止している
ことを検出する第２の停止監視手段と、第２の停止監視
手段により停止しているＯＳのクラスタが実クラスタか
ＡＶＭ運用のクラスタのいずれであるかを判定する仮想
・実計算機確認手段と、仮想・実計算機確認手段によ
り、ＡＶＭ運用のクラスタであると判定された場合に、
ＡＶＭと共用メモリに初期化処理のためのアクセスを行
ったＡＶＭ運用のクラスタの配下の仮想計算機であるゲ
ストクラスタとの間の論理パスを切断する論理パス切断
手段とを含む。

【００５５】第５の発明は、第１の発明のＡＶＭが、Ａ
ＶＭ運用のクラスタ及びゲストクラスタを識別するため
の識別子を一意に付与する識別子付与手段と、ゲストク
ラスタを含むクラスタ内のＯＳから要求があった場合
に、識別子付与手段で付与された識別子を自クラスタま
たは他のクラスタに通知する識別子通知手段とを有す
る。

【００５６】第６の発明は、第１の発明のＯＳが、送信
先のクラスタが実クラスタであるかＡＶＭ運用のクラス
タであるかを識別する識別手段と、該識別手段により、
ＡＶＭ運用のクラスタであると識別された場合には、該
ＡＶＭ運用のクラスタに対して該ＡＶＭ運用のクラスタ
の送信先となっているゲストクラスタのアドレス情報を
要求し、送信先のアドレス情報と動作中の該ゲストクラ
スタの状態情報を取得する仮想計算機情報取得手段とを
有する。

【００５７】第７の発明は、第６の発明のＡＶＭが、他
のクラスタから送信された通信要求が自クラスタ宛であ
るか他クラスタ宛であるかを通信要求のアドレス情報を
参照して判断し、他クラスタ宛であれば、該他クラスタ
に送信する通信要求振分手段と、通信要求が自クラスタ
宛である場合には、通信要求をキューイングするキュー
イング手段と、自クラスタの送信先のゲストクラスタが
通信を受け付けられる状態になった時点で、キューイン
グ手段よりキューイングされていた通信要求情報をゲス
トクラスタに反映させる反映手段とを有する。

【００５８】第８の発明は、第７の発明の共用メモリ
が、ＡＶＭが制御するゲストクラスタに対して通信要求
の新規割り込みが発生した場合に、クラスタからの通信
要求をキューイングする共用メモリキューイング手段を
有し、ゲストクラスタ内のＯＳが、ＡＶＭのキューイン
グ手段に存在している通信要求を処理した後に、共用メ
モリキューイング手段に存在する通信要求を処理する手
段を有する。

【００５９】第９の発明は、第８の発明のＡＶＭが、キ
ューイング手段よりキューが溢れた場合に、通信要求の
送信元に対してキュー溢れを通知するキュー溢れ通知手
段を有する。第１０の発明は、第１の発明のＡＶＭが、
他のクラスタまたは、他のクラスタの仮想計算機から発
行されたリセット要求を受信するリセット要求受信手段
と、リセット要求受信手段により受信したリセット要求
をリセット対象のゲストクラスタに対してリセット処理
起動するリセット手段と、リセット手段の完了後に、リ
セット要求の発行元にリセット完了を通知するリセット
完了通知手段と、リセット手段が失敗した場合に、リセ
ット要求の発行元にリセット失敗を通知するリセット失
敗通知手段とを有する。

【００６０】第１１の発明は、第１０の発明のリセット
要求受信手段が、あるクラスタからリセット要求を受信
すると共に他のクラスタから発行されたリセット要求も
受信する手段を有する。第１２の発明は、共有メモリに
接続される少なくとも１つの実クラスタ、または／及
び、仮想計算機であるゲストクラスタを仮想計算機シス
テム（ＡＶＭ）運用する少なくとも１つのＡＶＭ運用の
クラスタを有する計算機システムにおいて、ＡＶＭ自身
で回復不可能な異常によりダウンした場合に、ＡＶＭ自
身でダウンした旨を、共用メモリを介して、共用メモリ
に接続される全てのクラスタに通知する自己通知手段
と、自己通知手段によりダウンしたＡＶＭから通知され
たダウン情報を取得し、ＡＶＭのダウンを認識する第１
のダウン認識手段とを有する。

【００６１】第１３の発明は、共有メモリに接続される
少なくとも１つの実計算機、または／及び、複数の配下
の計算機を仮想運用する少なくとも１つの仮想計算機シ
ステムを有する計算機システムにおいて、ＡＶＭ運用の
クラスタの配下のゲストクラスタで発生した回復不可能
な異常によるダウン状態を、共有メモリに接続される他
の計算機のオペレーティングシステム（以下、ＯＳと記
す）により認識する第２のダウン認識手段と、第２のダ
ウン認識手段によりダウンした旨を通知するダウン通知
手段と、ダウン通知手段により通知されるダウン状態の
情報を受信するダウン状態受信手段とを有する。

【００６２】第１４の発明は、第１３の発明の第２のダ
ウン認識手段が、ゲストクラスタがダウンした際に、Ａ
ＶＭシステムからタイマ監視を行って完了通知を待機
し、所定の時間内に通知がない場合に、ＡＶＭシステム
のダウン状態を認識するタイマ監視手段を含む。

【００６３】また、第１５の発明は、第１２及び第１３
の発明において、第２のダウン認識手段が、ＡＶＭのダ
ウンを検出した場合に、ＡＶＭ運用のクラスタのダウン
していないゲストクラスタについても強制的にダウン状
態であると見做すゲストクラスタダウン制御手段を含
む。

【００６４】また、第１６の発明は、第１２及び第１３
の発明において、共用メモリ上にクラスタ毎のハードウ
ェア情報を登録するハードウェア情報登録手段と、ダウ
ンしているクラスタが、ＡＶＭ運用のクラスタである場
合に、ハードウェア情報登録手段を参照して、ハードウ
ェア機構において入出力のリセットが可能な状態情報が
登録されている場合に、他のクラスタからダウンしてい
るクラスタの入出力のリセットを行うダウンクラスタ制
御手段を有する。

【００６５】また、第１７の発明は、第１３の発明にお
いて、共用メモリ内の、ダウン状態となっているクラス
タ（以下、ダウンクラスタと記す）の制御権を取得した
クラスタの識別子を登録する制御クラスタ記憶手段と、
ＡＶＭ運用のクラスタがダウン状態となった場合に、所
定時間、制御クラスタ記憶手段に制御権を取得したクラ
スタの識別子が登録されない場合に、ダウンしたＡＶＭ
配下のゲストクラスタが制御を行う自クラスタ内ゲスト
クラスタ制御手段を有する。

【００６６】また、第１８の発明は、第１２の発明にお
いて、ＡＶＭ運用のクラスタのゲストクラスタがセッシ
ョン閉塞状態時に、ＡＶＭ運用のクラスタから他のクラ
スタに通知するセッション閉塞通知手段を含む。また、
第１９の発明は、第１２の発明において、セッション閉
塞状態の通知を受け付けたクラスタが、ダウンしたクラ
スタの制御時にＡＶＭによるリセット処理が完了してい
る場合には、共用メモリに装備されているシステム制御
機能であるＧＳＩＧＰ命令によるリセットを行わないリ
セット制御手段を含む。

【００６７】また、第２０の発明は、第１６の発明にお
いて、ダウンクラスタへの制御失敗時に表示されるオペ
レータ介入メッセージを消去する消去手段を含む。ま
た、第２１の発明は、第１９のの発明における消去手段
が、オペレータが、表示されているオペレータ介入メッ
セージに応答した場合、ダウンしたクラスタが再度ＩＰ
Ｌした場合、セッション閉塞の通知をゲストクラスタの
ＯＳが認識した場合、ＡＶＭ運用中のクラスタがダウン
した場合を契機として、オペレータ介入メッセージを消
去するものである。

【００６８】また、第２２の発明は、少なくとも１つの
実計算機（以下、実クラスタと記す）と外部記憶装置で
ある共用メモリとを結合する電子計算機システムの制御
方法において、実クラスタ及び仮想計算機運用された実
クラスタ内の個々のゲストクラスタを制御するためのオ
ペレーティングシステム（以下、ＯＳと記す）を有する
実計算機または、仮想計算機システムを制御するための
ＯＳ（以下、ＡＶＭと記す）を有する少なくとも１つの
仮想計算機（以下、ＡＶＭ運用のクラスタと記す）が共
用メモリに接続するステップと、実クラスタ間または、
仮想計算機システム間または、その両者間で共用メモリ
を介して通信処理を行うステップからなる。

【００６９】また、第２３の発明は、実クラスタのＯ
Ｓ、ＡＶＭ運用のクラスタ内の個々のゲストクラスタの
ＯＳ、または、ＡＶＭ運用のクラスタのＯＳが、共用メ
モリにアクセスするステップと、共用メモリ上の領域の
ロックを獲得するステップよりなる。

【００７０】また、第２４の発明は、実クラスタのＯＳ
または、ゲストクラスタ内のＯＳが共用メモリ上の領域
のロックを獲得した際に、ロックを獲得しているクラス
タのＯＳが停止した場合に、ＯＳの停止を検出するステ
ップと、停止が検出されたクラスタと共用メモリとのア
クセスパスを切断するステップと、他のクラスタからの
ＩＰＬを契機として共用メモリの初期化を行うステップ
よりなる。

【００７１】第２５の発明は、ロックを獲得しているク
ラスタのＯＳが停止していることを検出するステップ
と、停止しているＯＳが実クラスタか、またはＡＶＭ運
用されるクラスタのいずれのＯＳかを判定するステップ
と、ＡＶＭ運用されるクラスタであると判定された場合
に、共用メモリに初期化処理のためのアクセスを行った
仮想計算機との間の論理パスを切断するステップからな
る。

【００７２】第２６の発明は、ＡＶＭ運用されるクラス
タの配下のゲストクラスタを識別するための識別子を付
与するステップと、ゲストクラスタを含むクラスタ内の
ＯＳから要求があった場合に付与された識別子を自クラ
スタまたは他のクラスタに通知するステップよりなる。

【００７３】第２７の発明は、第２２の発明において、
送信先のクラスタが実クラスタであるかＡＶＭ運用され
るクラスタであるかを識別するステップと、ＡＶＭ運用
のクラスタであると識別された場合には、該ＡＶＭ運用
のクラスタに対して該ＡＶＭ運用のクラスタの送信先の
仮想計算機のアドレス情報を要求するステップと、送信
先のアドレス情報と動作中の該仮想計算機の状態情報を
取得するステップよりなる。

【００７４】第２８の発明は、第２７の発明において、
他のクラスタから送信された通信要求が自クラスタ宛で
あるか他クラスタ宛であるかを通信要求のアドレス情報
を参照して判断し、他クラスタ宛であれば、該他クラス
タに送信するステップと、通信要求が自クラスタ宛であ
る場合には、通信要求をキューイングするステップと、
自クラスタの送信先の仮想計算機が通信を受け付けられ
る状態になった時点で、キューイングされていた通信要
求情報を仮想計算機に反映させるステップからなる。

【００７５】第２９の発明は、第２８の発明において、
共用メモリが、ＡＶＭ運用のクラスタに対して新規割り
込みが発生した場合に、クラスタからの通信要求をキュ
ーイングするステップと、ＡＶＭ運用のクラスタがキュ
ーイングによるキュー待ち行列に存在している通信要求
を順次処理するステップよりなる。

【００７６】第３０の発明は、第２９の発明において、
ＡＶＭ運用されるクラスタにおいて、キューが溢れた場
合に、通信要求の送信元に対してキュー溢れを通知す
る。第３１の発明は、第２２の発明において、ＡＶＭ運
用されるクラスタが他の実クラスタまたは、他のＡＶＭ
運用されているクラスタの配下のゲストクラスタから発
行されたリセット要求を受信するステップと、受信した
リセット要求をリセット対象の仮想計算機に対してリセ
ット処理起動するステップと、リセット処理起動の完了
後に、リセット要求の発行元にリセット完了を通知する
ステップと、リセット処理が失敗した場合に、リセット
要求発行元にリセット失敗を通知するステップとからな
る。

【００７７】第３２の発明は、第３１の発明において、
リセット要求受信時に、あるクラスタからリセット要求
を受信すると共に、他のクラスタから発行されたリセッ
ト要求も受信する。第３３の発明は、第２２の発明にお
いて少なくとも１つの実計算機（以下、実クラスタと記
す）と外部記憶装置である共用メモリとを結合する電子
計算機システムの制御方法において、ＡＶＭ運用のクラ
スタのＡＶＭ自身で回復不可能な異常によりダウンした
場合に、該仮想計算機システム自身でダウンした旨を、
共用メモリを介して、共用メモリに接続される全ての計
算機に通知するステップと、ダウンしたＡＶＭ運用のク
ラスタから通知されたダウン情報を取得し、ダウンした
クラスタを認識する。

【００７８】第３４の発明は、第２２の発明において、
少なくとも１つの実計算機（以下、実クラスタと記す）
と外部記憶装置である共用メモリとを結合する電子計算
機システムの制御方法において、ＡＶＭ運用のクラスタ
の配下のゲストクラスタで発生した回復不可能な異常に
よるダウン状態を、共有メモリに接続される他のクラス
タのＯＳにより認識する。

【００７９】また、第３５の発明は、第３４の発明にお
いて、ＡＶＭ運用のクラスタの配下のゲストクラスタが
ダウンした際に、該ゲストクラスタからタイマ監視を行
って完了通知を待機し、所定の時間内に通知がない場合
に、ゲストクラスタのダウン状態を認識する。

【００８０】また、第３６の発明は、第３３、第３４の
発明において、ＡＶＭのダウンを検出した場合に、ＡＶ
Ｍ運用のゲストクラスタのうち、ダウンしていないゲス
トクラスタについてもダウン状態とする。第３７の発明
は、第３３及び第３４の発明において、共用メモリ上に
クラスタ毎のハードウェア情報を登録するステップと、
ダウンしているクラスタが、ＡＶＭ運用のゲストクラス
タである場合に、登録されているハードウェア情報を参
照して、ハードウェア機構において入出力のリセットが
可能な状態情報が登録されている場合に、他のクラスタ
からダウンしているクラスタの入出力のリセットを行う
ステップからなる。

【００８１】第３８の発明は、第３４の発明において、
共用メモリ内の、ダウン状態となっているクラスタ（以
下、ダウンクラスタと記す）の制御権を取得したクラス
タの識別子を登録するステップと、ＡＶＭ運用のクラス
タのゲストクラスタがダウン状態となった場合に、所定
時間内に共用メモリ内に制御権を取得したクラスタの識
別子が登録されない場合に、ダウンしたＡＶＭ配下のゲ
ストクラスタのＯＳが制御を行うステップよりなる。

【００８２】第３９の発明は、第３３の発明において、
ＡＶＭ運用のクラスタの配下のゲストクラスタがセッシ
ョン閉塞状態時に、ＡＶＭ自体で、閉塞状態のゲストク
ラスタの制御を行うステップと、配下のゲストクラスタ
のセッション閉塞状態を他のクラスタに通知するステッ
プよりなる。

【００８３】また、第４０の発明は、第３３の発明にお
いて、セッション閉塞状態の通知を受けたクラスタがダ
ウンしたクラスタの制御時に、クラスタ間の通信・制御
を行うためのＧＳＩＧＰ命令によるリセットを行わな
い。また、第４１の発明は、第３７の発明において、ダ
ウンクラスタへの制御失敗時に表示されるオペレータ介
入メッセージによる処理が終了した時点で、該オペレー
タ介入メッセージを消去する。

【００８４】また、第４２の発明は、第４１の発明にお
いて、オペレータメッセージを消去する際に、オペレー
タが表示されているオペレータ介入メッセージに応答し
た場合、ダウンしたクラスタが再度ＩＰＬし、セッショ
ン閉塞の通知をゲストクラスタのＯＳが認識した場合、
または、ＡＶＭ運用中の実クラスタのダウンを契機とし
て、オペレータ介入メッセージを消去する。

【００８５】上記の各々の発明は、各々以下に示す作用
を有する。第１及び第２２の発明は、外部記憶装置（共
用メモリ）に仮想計算機により運用される実計算機を複
数接続することが可能となり、ある実計算機に包合され
る仮想計算機と他の実計算機に包合される仮想計算機と
の通信が可能となる。

【００８６】第２、第３、第２３、及び第２４の発明
は、共用メモリに接続される仮想計算機により運用され
ている実計算機（以下、クラスタと記す）がホットスタ
ンバイ時に共用メモリをロックし、他のクラスタからの
アクセスを排他制御することが可能であると共に、ロッ
クしているクラスタが異常停止した状態を検出した場合
に、自クラスタから初期化処理を行い、異常停止したク
ラスタと共用メモリとのアクセスパスを切断するため、
共用メモリのデータ破壊を防止できる。

【００８７】第４及び第２５の発明は、仮想計算機（以
下、ゲストクラスタと記す）により運用されているクラ
スタ内のゲストクラスタの初期化処理が異常停止してい
る場合には、当該ゲストクラスタを制御するＯＳ（ＡＶ
Ｍ）と当該ゲストクラスタ間の論理パスを切断する。こ
れにより、クラスタのアクセスパスは切断しないため、
他のゲストクラスタから共用メモリにアクセスすること
が可能となる。

【００８８】第５及び第２６の発明は、共用メモリに接
続できる仮想計算機により運用されているクラスタを複
数接続したことにより、各クラスタの複数のゲストクラ
スタを一意に識別するための識別子を付与する。これに
より、ゲストクラスタのＯＳは、起動すると同時に、ゲ
ストクラスタを制御するＯＳ（ＡＶＭ）に必要に応じて
問い合わせることにより、識別子を取得できるため、ゲ
ストクラスタを含むクラスタ間の通信を行う際に、送信
先及び送信元のゲストクラスタを識別することが可能と
なる。

【００８９】第６及び第２７の発明は、通信相手が実計
算機のクラスタであるか、仮想計算機により運用されて
いるクラスタであるかを判別し、さらに、各クラスタの
運用状態を把握するため、複数の計算機間で通信を行う
場合に必要な情報の授受を行い、共用メモリを介した複
数の実計算機のクラスタや仮想計算機により運用されて
いるクラスタ等の混在したシステム間であっても通信相
手及び通信相手の状況を正確に把握した上での通信を行
うことが可能となる。

【００９０】第７及び第２８の発明は、仮想計算機によ
り運用されているクラスタが受信側の計算機である場合
に、他のクラスタから受信した通信要求を受信して、自
クラスタ宛か他クラスタ宛かの判断を行い、自クラスタ
の場合には、通信対象の自クラスタのゲストクラスタが
処理可能な状態になるまで、ゲストクラスタを制御する
ＯＳでキューイングしておき、ゲストクラスタが処理可
能となった時、通信要求を反映させる。

【００９１】第８及び第２９の発明は、複数のクラスタ
の通信をキューイングし、ゲストクラスタが通信を受け
られる状態になった時点で通知し、通知を受けたゲスト
クラスタ内のＯＳは他にキューイングされた通信要求が
あるかを認識すると同時に、ある場合にはそれらの通信
要求も合わせて処理するため、新規割り込み等がある場
合でも、ゲストクラスタを制御するＯＳが存在するクラ
スタと複数のゲストクラスタとの間で通信の割り込み状
態が各々異なっていても、通信要求を確実に反映させる
ことが可能である。

【００９２】第９及び第３０の発明は、第８の発明にお
いて、キューが溢れた場合には、ゲストクラスタを制御
するＯＳにより通信要求発行元に対して、キュー溢れを
通知することにより、新たな通信要求の発行を停止させ
ることが可能となる。第１０及び第３１の発明は、他の
クラスタからリセット要求を仮想計算機により運用され
ているクラスタが受信した場合に、ゲストクラスタを制
御するＯＳが制御対象のゲストクラスタを特定し、その
ゲストクラスタの制御が完了した時点で、リセット要求
の発行元に対して完了通知を送信することにより、リセ
ット要求元では、ホットスタンバイによる切り替えが可
能となる。

【００９３】第１１及び第３２の発明は、第１０及び第
３１の発明において、クラスタ内の仮想計算機のリセッ
ト制御が完了するまでの間に他のクラスタからの通信を
ゲストクラスタを制御するＯＳが受け付けることが可能
である。第１２及び第３３の発明は、前提として、第１
及び第２２の発明により共用メモリに接続され、複数の
計算機システム間での通信が可能であるため、ＡＶＭが
回復不可能な異常によりダウンした場合に、該仮想計算
機システム自身でダウンした旨を、共用メモリを介し
て、共用メモリに接続される全ての計算機に通知するこ
とができる。これにより、ダウン通知を受け取った他の
共用メモリに接続される他の計算機がダウンクラスタに
対して入出力のリセットやＣＰＵの停止等の制御を行う
ことが可能となる。従って、ダウン通知を受信したクラ
スタとダウンしたクラスタ間で通信中にダウン状態の発
生時にそのまま続行すれば、エラー発生の要因となると
ころであるが、ダウン通知を受け取ることにより、シス
テムから論理的にダウンクラスタを外すことが可能であ
る。

【００９４】第１３及び第３４の発明は、第１２及び第
３３の発明と同様に、前提として、複数の計算機システ
ム間で通信が可能であるため、あるクラスタがダウンし
た状況を認識することができる。これにより、ダウンし
たクラスタと通信中に障害が発生しても、ダウンした状
況を認識することができるため、ダウンクラスタの入出
力のリセットやＣＰＵ停止等の制御が可能となり、第１
２の発明と同様に、ダウンクラスタをシステムから外す
ことが可能である。

【００９５】第１４及び第３５の発明は、ＡＶＭ運用さ
れるクラスタのゲストクラスタがダウンした時に、ＡＶ
Ｍから完了通知をタイマ監視して待機し、所定時間内に
ＡＶＭから完了または、失敗の通知がない場合には、ダ
ウンしたものとしてＯＳが検出することができる。

【００９６】第１５及び第３６の発明は、ＡＶＭ運用の
クラスタがダウンした場合に、ＡＶＭ運用のクラスタの
ダウンしていないゲストクラスタについてもダウン状態
であると見做すことにより、ＡＶＭ運用のクラスタの配
下のゲストクラスタ全てを複数のクラスタで共用メモリ
を共用する複合システムであるＳＣＭＰシステムから切
り離す。これにより、ゲストクラスタ個々に処理を行う
よりも、実クラスタ自体に制御を行うことにより、高速
なホットスタンバイ処理が可能となる。

【００９７】第１６及び第３７の発明は、ＡＶＭ運用の
クラスタのＣＰＵの停止及び入出力のリセットを行うこ
とにより、従来、ハードウェアの構成がネイティブ運用
（非ＡＶＭ運用）のクラスタにしか、Ｉ／Ｏリセットの
制御ができなかったが、ＡＶＭ運用のクラスタに対して
もこれらの制御が可能となる。

【００９８】また、第１７及び第３８の発明は、第１４
の発明において、ＯＳがＡＶＭのダウンを検出すると、
ダウンしたＡＶＭ配下のゲストクラスタ以外に、クラス
タが存在する場合、即ち、他に実クラスタ（ＡＶＭ運用
でもよい）が存在する場合には、他のクラスタがダウン
クラスタ制御権を取得するか、他に１つも存在しない場
合には、ダウンしたＡＶＭ配下のゲストクラスタが制御
を行う。

【００９９】第１８及び第３９の発明は、ＡＶＭ運用の
クラスタのゲストクラスタがセッション閉塞状態時に、
ＡＶＭ運用のクラスタから他のクラスタに通知すること
により、セッション閉塞の通知を受けたクラスタ（Ｏ
Ｓ）が、ダウンしたクラスタの制御を行っているか、ま
たは、ＡＶＭによるリセット処理が完了しているため、
ＧＳＩＧＰ命令による制御を行う必要がない。従って、
セッション閉塞したゲストクラスタについてもＩ／Ｏリ
セットやＣＰＵの停止等の制御が可能となる。

【０１００】第１９及び第４０の発明は、他のクラスタ
でセッション閉塞の通知を受け付けることが可能であ
る。また、第２０、２１、４０、４１及び４２の発明
は、ダウンクラスタへの制御失敗時に表示されるオペレ
ータ介入メッセージを消去することにより、オペレータ
の介入を軽減することが可能であり、オペレータの介入
を要せずに、ホットスタンバイが実現できる。

【０１０１】

【発明の実施の形態】図２は、本発明の計算機システム
（ＳＣＭＰシステム）の構成を示す。同図に示す構成
は、本発明のＳＣＭＰシステムの基本的な構成であり、
複数の仮想計算機で運用される複数の実計算機（以下、
クラスタと記す）２００、３００が共用メモリ（以下、
ＳＳＵと記す）１００を共用する複合システム（以下、
ＳＣＭＰシステム）である。クラスタ２００は、ｎ個の
仮想計算機（以下、ゲストクラスタと記す）２２０-1，
…，２２０-n及び、クラスタ２００のＣＰＵに含まれる
仮想計算機制御機構（以下、ＡＶＭと記す）２１０によ
り構成され、各ゲストクラスタとＡＶＭ２１０は、論理
パス７１により接続されている。クラスタ３００は３つ
のゲストクラスタ３２０-1，３２０-2，３２０-3及び、
ＡＶＭ３１０）より構成され、ゲストクラスタとＡＶＭ
３１０は論理パス７２により接続されている。

【０１０２】上記の示すシステムにおいてクラスタ間の
通信、制御、ダウン時の処理について以下に説明する。

【０１０３】

【実施例】以下、本発明の実施例を図面を用いて詳細に
説明する。最初に第１の実施例として、共用メモリを用
いた複合システムにおける計算機システムの制御を説明
し、次に、第２の実施例として共用メモリを用いた複合
システムにおけるダウンクラスタの制御について説明す
る。

【０１０４】［第１の実施例］また、図３に示す構成
は、図２の構成に実計算機により運用されているクラス
タ４００を付加した構成である。以下、図２、図３に示
すような構成を用いて、以下の順に説明する。

【０１０５】i ． 共用メモリの初期化処理 ii． 通信時の識別子付与処理 iii. 運用状態確認処理 iv. クラスタ間の通信処理 v. 通信割り込み処理 vi. 完了確認 ［ｉ．共用メモリの初期化処理］まず、共用メモリの初
期化処理の第１の例を説明する。

【０１０６】ＳＳＵ１００の初期化において、ＳＣＭＰ
システム内で最初に立ち上がるクラスタの（ＩＰＬを実
行する）オペレーティングシステム（ＯＳ）ａがＳＳＵ
１００とのアクセスパスを接続することにより、ＳＳＵ
１００上のロックを獲得する。これにより、他のクラス
タ２００のＯＳがＩＰＬを実行しようとしても、ロック
により他のクラスタからのＩＰＬ操作が排他され、ＳＳ
Ｕ１００に格納されているデータを保証する。例えば、
図３の例では、クラスタ３００のＯＳからＳＳＵ１００
にＩＰＬ操作を行うと、クラスタ３００のＯＳがＳＳＵ
１００にアクセスする。これにより、クラスタ３００ま
たはクラスタ４００内のＯＳがその後にＩＰＬ操作を行
ったとしても、そのＩＰＬ要求は排他される。

【０１０７】また、上記のＯＳａがＳＳＵ１００のロッ
クを保持したまま、停止した場合には、他のＯＳのＩＰ
Ｌを契機として、ＳＳＵ１００の初期化処理を行う。例
えば、クラスタ３００のＯＳがＳＳＵ１００を獲得した
状態で異常発生等により停止した場合には、他のクラス
タがクラスタ３００のＯＳの停止を発見して自クラスタ
からＳＳＵ１００にＩＰＬ操作を行うことが可能であ
る。なお、他のクラスタの停止を監視する方法及び他の
クラスタからのＩＰＬ操作の方法については、後述す
る。

【０１０８】図４は、本発明の第１の実施例の初期化の
概要を説明するための図（その１）である。クラスタ４
００、５００は、実計算機により運用されているクラス
タであり、ＳＳＵ１００のアクセスパス６１、６２によ
りそれぞれ接続されている。最初にクラスタ４００のＯ
Ｓ４０１がＳＳＵ１００にアクセスパス６２を介してＩ
ＰＬを実行すると、クラスタ４００のＯＳ４０１がＳＳ
Ｕ１００をロックしてＳＳＵ１００の初期化の権利を獲
得する。クラスタ４００のＯＳ４０１によるＳＳＵ１０
０のロック後、ＩＰＬを実行したクラスタ４００のＯＳ
４０１がＳＳＵ１００のロックを保持したまま停止した
場合に、クラスタ５００のＯＳ５０１が、クラスタ４０
０の停止を検出し、ＩＰＬを実行する。これにより、Ｓ
ＳＵ１００に対するアクセスパスがロックに関係なくＩ
ＰＬを行うことで接続され、クラスタ５００のＯＳ５０
１は、クラスタ４００とＳＳＵ１００間に接続されてい
るアクセスパス６１を物理的に切断し、自クラスタ５０
０とＳＳＵ１００間のアクセスパス６２を接続する。

【０１０９】これにより、停止と認識されたＯＳの誤動
作によりＳＳＵ１００データの破壊を防ぎ、データを保
証するものである。上記のアクセスパスの切断について
は、特開平４−６０７５０号『クラスタ停止装置』、及
び特開平４−２３１４９『二重化データ保全装置』に詳
述されている。

【０１１０】次に、ＡＶＭ運用されているクラスタのＯ
Ｓにより他のクラスタの停止を検出した場合の動作を説
明する。図５は、本発明の第１の実施例の初期化の概要
を説明するため図（その２）である。同図において、ク
ラスタ３００のゲストクラスタ３２０-2が、後述する停
止監視機能によりクラスタ２００のゲストクラスタ２２
０-2が停止したと見做した場合、上記の第１の例のよう
に、物理的にＳＳＵ１００とクラスタ２００間のアクセ
スパス６１を切断するのでは、ＡＶＭ運用されているク
ラスタ２００の配下の他のゲストクラスタの接続も同時
に切断されてしまうため、ゲストクラスタ３２０−２内
のＯＳが通信を発行し、ＡＶＭ３１０経由でＡＶＭ２１
０との間で通信を行い、ＡＶＭ２１０がゲストクラスタ
２２０-2と接続するための論理パス７１を切断する。

【０１１１】図６は、本発明の第１の実施例の初期化処
理におけるシステム構成を示す。同図に示すシステム
は、図３に示す実計算機運用されるクラスタ４００と、
仮想計算機運用されるクラスタ２００がＳＳＵ１００に
接続されている構成であり、他のクラスタの接続は説明
の簡略化のため省略する。

【０１１２】図６において、実計算機運用されるクラス
タ４００の実計算機制御部４４０は、ＯＳとしてＳＳＵ
１００上の特定のメモリ領域を更新するメモリ更新部４
４１、他のクラスタがＳＳＵ１００を初期化中であるか
否かを監視する初期化監視部４４２、初期化中の他のク
ラスタが停止（ダウン）していないかを監視する停止監
視部４４３、停止監視部４４３において、停止している
クラスタ（ダウンクラスタ）を検出した際に、当該ダウ
ンクラスタが実計算機か仮想計算機かを判断する仮想・
実計算機判定部４４４、クラスタとＳＳＵ１００とを接
続するアクセスパスを切断するパス切断部４４５、自ク
ラスタがＳＳＵ１００に対して初期化する場合にＩＰＬ
操作を行う初期化部４４６及び上記の各部を制御する制
御部４４７より構成される。なお、メモリ更新部４４
１、初期化監視部４４２、停止監視部４４３、仮想・実
計算機判定部４４４、パス切断部４４５、初期化部４４
６及び制御部４４７は各々ＯＳである。

【０１１３】仮想計算機運用されるクラスタ２００は、
ハードウェアである実計算機制御部２４０、ゲストクラ
スタ２２０と論理パス７１で接続され、各ゲストクラス
タを制御するＡＶＭ２１０及び複数のゲストクラスタ２
２０-1、２２０-2、２２０-3より構成される。なお、各
ゲストクラスタ２２０−１，２２０−２，２２０−３の
ＯＳ詳細は、クラスタ４００の実計算機制御部４４０の
ＯＳ４５０の構成と同様であるので、図面上の記載を省
略する。

【０１１４】なお、仮想計算機により運用されている複
数のクラスタがＳＳＵ１００を分割して利用することが
ある。上記の各部の動作を以下に示す。図７は、本発明
の第１の実施例の初期化処理のフローチャートである。

【０１１５】初期化処理は、ＯＳ単位に行われ、同図の
例では、ゲストクラスタが初期化の単位である。 ステップ１００） ゲストクラスタのＯＳが初期化のた
めのＳＳＵ１００のロックを獲得する。

【０１１６】ステップ１０１） 初期化監視部は、既に
別のクラスタがロックを獲得している場合には、ステッ
プ１０３に移行し、自クラスタでロックを獲得できたな
らばステップ１０２に移行する。 ステップ１０２） 初期化部は、自クラスタの初期化処
理を行う。

【０１１７】ステップ１０３） 停止監視部は、ロック
を獲得しているクラスタが生存しているかを確認する。
確認は、ＯＳ間（クラスタ間）の通信により行うものと
する（図８−種別１）。通信対象のクラスタアドレスは
ロックワード上に格納されているので、当該クラスタア
ドレスを取得して通信を行う。通信を行った結果、応答
が有る場合には、クラスタが生存中であるので、ステッ
プ１０４に移行し、応答がない場合にはステップ１０５
に移行する。

【０１１８】ステップ１０４） 制御部は、生存中の他
のクラスタの初期化処理が完了するまで待機し、完了し
たらステップ１０８に移行する。 ステップ１０５） 仮想・実計算機判定部は、ロックワ
ード上に格納されたクラスタアドレスに基づいて相手ク
ラスタがＡＶＭ運用中か否かを判定し、ＡＶＭ運用中で
あればステップ１０６に移行し、実（Native）クラスタ
として運用されている場合にはステップ１０７に移行す
る。

【０１１９】ステップ１０６） パス切断部は、相手ク
ラスタ（ダウンしたクラスタ）がＡＶＭ運用中であれ
ば、論理パスを切断して、ステップ１０８に移行する。 ステップ１０７） パス切断部は、相手クラスタが実ク
ラスタ運用中であれば、アクセスパスを切断する。

【０１２０】ステップ１０８） 初期化部は、初期化処
理を実行する。上記の処理において各判定処理は図８の
内容に基づいて行うものとする。なお、上記において、
ダウンクラスタの制御方法については、第２の実施例で
詳細に説明する。

【０１２１】［ii．通信時の識別子付与処理］次に本発
明の通信時の識別子付与処理について説明する。本実施
例は、例えば、図２におけるクラスタ２００内のＡＶＭ
２１０が、複数のゲストクラスタ２２０-1〜２２０-nに
対して、クラスタ２００内の資源の割り当て等を行う際
に、ゲストクラスタ固有の仮想計算機番号を付与するも
のである。これにより、ＡＶＭ２１０は全てシステム内
ではユニークな番号を有する。

【０１２２】図９は、本発明の第１の実施例のゲストク
ラスタに対する識別子付与処理を説明するための図であ
る。同図（Ａ）は、各クラスタ毎に付与されている実計
算機番号と、クラスタが仮想計算機により運用されてい
る各クラスタに含まれるゲストクラスタに付与される相
対計算機番号を示す。同図（Ｂ）は、実計算機番号と相
対計算機番号より生成される仮想計算機番号を示す。

【０１２３】各クラスタのＡＶＭ３１０、４１０は、相
対番号をＯＳから依頼があった時に通知する。仮想番号
は、ＯＳにより実計算機番号と相対計算機番号により生
成される。同図において、“×”で表されているゲスト
クラスタは、停止しているものとし、停止しているゲス
トクラスタには、仮想計算機番号は付与しない。

【０１２４】例えば、クラスタ３００において、ＡＶＭ
３１０のＯＳは、自クラスタ３００内に保持する自クラ
スタの実計算機番号“０１”と仮想計算機番号を付与し
ようとするゲストクラスタの相対計算機番号を読出す。
例えば、ゲストクラスタ３２０-3に付与する場合には、
“０１”＋“３”により、“０１３”という仮想計算機
番号が生成される。

【０１２５】図１０は、本発明の第１の実施例のゲスト
クラスタに対して仮想計算機番号を付与する処理を説明
するためのシーケンスチャートである。以下の説明で
は、図９のクラスタ３００の相対計算機番号“３”を有
するゲストクラスタ３００-3に仮想計算機番号を付与す
る例を用いて説明する。

【０１２６】ステップ２０１） ＡＶＭ３１０は、クラ
スタ３００内にＡＶＭ３１０のゲストクラスタを設定す
る。図９の例では、ゲストクラスタ３２０-1，３２０-
3，３２０-4，３２０-5の４つのゲストクラスタを設定
する。 ステップ２０２） クラスタ３００のＯＳは、メモリ
（図示せず）より実計算機番号と相対計算機番号を取得
し、その２つの番号を合成して仮想計算機番号を生成す
る。

【０１２７】ステップ２０３） ステップ２０２で生成
された仮想計算機番号は、ＡＶＭ３１０内のメモリ（図
示せず）に格納する。 ステップ２０４） ゲストクラスタ３２０-3のＯＳがＡ
ＶＭ３１０に仮想計算機番号の問い合わせを行う。

【０１２８】ステップ２０５） ＡＶＭ３１０は、相対
計算機番号をメモリより読み出して、ゲストクラスタ３
２０-3に転送する。 ステップ２０６） また、ＯＳは、メモリに格納されて
いる自クラスタ３００内の全てのゲストクラスタの仮想
計算機番号をＳＳＵ１００の計算機番号用領域１１０に
転送する。

【０１２９】ステップ２０７） ＳＳＵ１００に接続さ
れている他のクラスタがある場合には、自クラスタ３０
０内の各ゲストクラスタの仮想計算機番号、実計算機番
号を他のクラスタに転送する。図１１は、本発明の第１
の実施例の仮想計算機番号の参照動作を説明するための
図である。同図中の番号（Ｓｘｘｘ）と以下のステップ
番号は対応するものとする。

【０１３０】ステップ３０１） クラスタ３００の相対
計算機番号“４”を有するゲストクラスタ３００-4より
自クラスタ３００内のＡＶＭ３１０に対して自ゲストク
ラスタ３２０-4の相対計算機番号を問い合わせる。 ステップ３０２） クラスタ３００のＡＶＭ３１０はゲ
ストクラスタ３２０-4に対して相対計算機番号“０１
４”を通知する。

【０１３１】ステップ３０３） ゲストクラスタ３２０
−４内のＯＳは、ＳＳＵ１００の計算機番号用領域１１
０にゲストクラスタ３２０-4の仮想計算機番号“０１
４”を書き込む。 ステップ３０４） 他のクラスタ２００やクラスタ４０
０は、クラスタ３００のゲストクラスタ３２０-4の仮想
計算機番号を知りたい場合には、ＳＳＵ１００の計算機
番号用領域１１０に問い合わせを行ってＳＳＵ１００か
ら情報の読み込みを行う。これにより、クラスタは、Ｓ
ＳＵ１００に登録されている、他のクラスタに属するゲ
ストクラスタの仮想計算機番号を参照することが可能と
なるため、複数のクラスタに属するゲストクラスタ間の
通信時に送信元・送信先のゲストクラスタを識別するこ
とが可能となる。

【０１３２】また、あるクラスタから他のクラスタのゲ
ストクラスタの仮想計算機番号を参照する他の例を示
す。図１２は、本発明の第１の実施例の他のクラスタに
仮想計算機番号を通知する他の例を示す。

【０１３３】ステップ４０１） クラスタ３００のＡＶ
Ｍ３１０は、他のクラスタ２００が実計算機として運用
されている場合には、直接当該クラスタ２００に対して
ゲストクラスタ３００-4の仮想計算機番号“０１４”を
通知する。 ステップ４０２） クラスタ３００のＡＶＭ３１０は、
他のクラスタ４００が仮想計算機として運用されている
場合には、クラスタ４００のＡＶＭ４１０に対してパラ
メータで存在する配下のゲストクラスタを指定して転送
する。

【０１３４】ステップ４０３） 受信したクラスタ４０
０のＡＶＭ４１０は、配下の全ゲストクラスタに受信し
た仮想計算機番号“０１４”を通知する。 ［ iii． 運用状態確認処理］次に、本発明の第１の実
施例の運用状態確認処理について説明する。

【０１３５】以下に、クラスタ内の各ゲストクラスタと
ＳＳＵを接続する論理パスの状態を取得する例を説明す
る。ＳＳＵ１００を介して複数の計算機システム間で通
信を行う場合、通信先のクラスタが実計算機として運用
中であるか否か、仮想計算機として運用されているか否
かを知る必要がある。

【０１３６】相手計算機が実計算機で運用されているの
か、仮想計算機で運用されているかは他クラスタからの
応答により把握する。相手計算機が実計算機で運用され
ている場合には、「アクセスパス／クラスタ番号／接続
・ハード情報収集命令（ＤＩＡＧＮＯＳＥ命令（ＳＴＧ
ＣＮやＳＴＧＣＦ）」により把握できるが、相手計算機
が仮想計算機で運用されている場合には、対象クラスタ
のＡＶＭに対して、問い合わせ要求を発信する。この問
い合わせ要求を受信したクラスタのＡＶＭは、自クラス
タ内のゲストクラスタ毎に、運用中か否かを示す情報と
各ゲストクラスタとＳＳＵを接続する論理パスが有効か
否かをパラメータ域に設定し、問い合わせ元のクラスタ
に回答を返信する。

【０１３７】本実施例では、ＳＳＵ１００に状態情報は
格納されていないことを前提に、直接情報を必要とする
ＡＶＭから他のクラスタに運用状態情報を問い合わせ
る。図１３は、本発明の第１の実施例の運用状態情報取
得の概念を示す。クラスタ２００とＳＳＵ１００、クラ
スタ３００とＳＳＵ１００、クラスタ４００とＳＳＵ１
００を接続するパスはそれぞれアクセスパス（物理パ
ス）６１、６２、６０であり、各ゲストクラスタ２２０
とＡＶＭ２１０間を接続するパスは論理パス（仮想パ
ス）２４１である。同図に示す例において、クラスタ２
００のゲストクラスタ２２０-1が運用状態情報の問い合
わせ元であり、クラスタ１００，３００が問い合わせ先
である。また、相手がＡＶＭの場合、全ゲストクラスタ
の情報を問い合わせる。

【０１３８】図１４は、本発明の第１の実施例の運用状
態情報取得時のシステム構成を示す。同図に示すシステ
ムは、クラスタ２００，３００は仮想計算機により運用
されているものとし、以下では、クラスタ２００からク
ラスタ３００に運用状態情報の問い合わせを行うものと
して説明する。

【０１３９】クラスタ２００は、ハードウェアで構成さ
れる実計算機制御部２４０、ＡＶＭ２１０、及び複数の
ゲストクラスタ２２０-1〜２２０-3により構成される。
クラスタ２００の配下の複数のゲストクラスタ２２０
は、各々図１５に示すように、パラメータ解析部２２１
１と仮想計算機間通信依頼部２２１２を有する計算機間
通信制御部２２１、送信元・送信先の実計算機番号と仮
想計算機番号を有するパラメータ域２２２、情報収集依
頼を行うタスク２２３より構成される。パラメータ域２
２２には、送信元の実計算機番号（０）、相対計算機番
号（２）、送信先の実計算機番号（１）、相対計算機番
号（２）が設定されている。

【０１４０】また、図１４に示すクラスタ３００の実計
算機制御部３４０内に、図１６に示すようなパラメータ
域３４１が設けられ、パラメータとして、自クラスタ３
００内のゲストクラスタ（仮想計算機）の情報が設定さ
れている。パラメータは、ゲストクラスタの数（４）、
各ゲストクラスタの状態（ＯＫ，ＮＯ等）が設定され
る。

【０１４１】図１４に基づいて運用状態情報の問い合わ
せの動作を説明する。図１７は、本発明の第１の実施例
の運用状態情報の問い合わせ動作を説明するためのシー
ケンスチャートである。 ステップ５０１） まず、クラスタ２００のゲストクラ
スタ２２０-2において、タスク２２３から情報収集依頼
が発行される。

【０１４２】ステップ５０２） ゲストクラスタ２２０
−２の計算機間通信制御部２２１は、パラメータ解析部
２２１１にパラメータ域２２２の内容を解析するよう制
御する。計算機制御部２２１のパラメータ解析部２２１
１は、パラメータ域２２２を参照して、問い合わせを行
う送信先の実計算機番号“０”と仮想計算機番号“２”
及び送信元である自クラスタ２００の実計算機番号
“１”、仮計算機番号“２”を取得して、計算機制御部
２２１の仮想計算機間通信依頼部２２１２に転送する。

【０１４３】ステップ５０３） 仮想計算機間通信依頼
部２２１２は、取得した問い合わせ先の実計算機番号と
相対計算機番号に対応するクラスタにＡＶＭ２１０を介
して発信する。図１４の例では、クラスタ３００のゲス
トクラスタ３２０-2に問い合わせを行うものとする。

【０１４４】ステップ５０４） クラスタ３００の実計
算機制御部３４０は、クラスタ２００から送信された問
い合わせ情報を解析する。 ステップ５０５） クラスタ３００の実計算機制御部３
４０は、図１６に示す内容のパラメータ域３４１を有
し、パラメータをＡＶＭに渡し、ＡＶＭの返答と共に当
該パラメータが依頼元に通知される。クラスタ２００か
らの問い合わせに応答する。このとき、実計算機制御部
３４０は、自クラスタ３００の構成情報を収集し、パラ
メータ域３４１に編集する。実計算機制御部３４０は、
ＡＶＭ３１０に対してゲストクラスタ間に論理パスが接
続されているゲストクラスタ識別子（仮想計算機番
号）、及び運用中であるか否かの動作状態を問い合わせ
る。ＡＶＭ３１０は、実計算機制御部３４０からの問い
合わせにより、ゲストクラスタ間の論理パスを調査し、
論理パスに接続されているゲストクラスタの動作状態を
認識し、実計算機制御部３４０のパラメータ域３４１に
渡されたパラメータ域３４１に情報を設定する。

【０１４５】ステップ５０６） ＡＶＭがパラメータ域
３４１の内容を返却する。クラスタ２００は、問い合わ
せの対象であったクラスタ３００のゲストクラスタ３２
０-2の内容を取得して、当該ゲストクラスタ３２０-2が
動作中であれば（上記のステップ５０６において“Ｏ
Ｋ”が返却された場合）、当該ゲストクラスタとの間の
通信を行う。これらの処理は、図８−種別５で依頼し、
種別６でＡＶＭに返答するものである。

【０１４６】上記の実施例により、複数の計算機システ
ム間で通信を行う場合、通信先のクラスタが運用中であ
るか否か、クラスタ自体が運用中か、ゲストクラスタが
運用中であるか等の情報を知ることが可能である。 ［iv. クラスタ間の通信処理］次に、本発明のクラスタ
間の通信処理について説明する。計算機間の通信処理に
は、クラスタ上のＯＳとゲストクラスタを制御するＡＶ
Ｍ間の通信（ＯＳ対ＡＶＭ）、あるクラスタと他のクラ
スタ間の通信（ＯＳ対ＯＳ）がある。ＯＳ間で通信を行
う必要が生じた時、通信を実現させる上で、送信元のク
ラスタ内のゲストクラスタ及び送信先のクラスタ内のゲ
ストクラスタを特定することが必要となる。また、ＡＶ
Ｍ配下のゲストクラスタ内のＯＳ間で通信を行う場合に
は、必然的にＡＶＭが間に介在する。

【０１４７】図１８は、本発明の第１の実施例のクラス
タ間の通信処理を説明するための図である。図１４と同
一構成部分には同一符号を付している。クラスタ２００
はゲストクラスタ２２０-1〜２２０-3を有し、クラスタ
３００はゲストクラスタ３２０-1〜３２０-3を有し、ク
ラスタ４００はゲストクラスタを持たない実計算機とし
て運用される。

【０１４８】以下の説明では、クラスタ２００のゲスト
クラスタ２２０-2を送信元とし、クラスタ３００のゲス
トクラスタ３２０-3を送信先として、ＳＳＵ１００を介
して通信するものとする。送信元のクラスタ２００のゲ
ストクラスタ２２０-2は、計算機間通信制御部２２１と
タスク２２３を有し、タスク２２３は、計算機間通信依
頼を計算機間通信制御部２２１に依頼する。このとき、
タスク２２３は、パラメータ域２２２を参照して送信先
の実計算機番号と相対計算機番号を取得する。

【０１４９】クラスタ２００のＡＶＭ２１０は、送信先
計算機（クラスタ３００）が他の実クラスタであるかを
見極め、他のクラスタであれば通信要求を発行し、自ク
ラスタ内であれば、配下のゲストクラスタ内のＯＳに対
して割り込みを発生させる。クラスタ３００の実計算機
制御部３４０は、ＳＳＵ１００を介して通信要求を受け
付け、送信元（クラスタ２００）から送信された情報よ
り相対計算機番号を取り出し、ＡＶＭ３１０に割り込み
を発生させる。

【０１５０】クラスタ３００のＡＶＭ３１０は、実計算
機制御部３４０から転送された相対計算機番号に基づい
て、自クラスタ内のいずれのゲストクラスタに送信され
ているのかを判断し、対象のゲストクラスタ（ゲストク
ラスタ３２０-3）をディスパッチする。そして、対象の
ゲストクラスタ３２０-3内の計算機間通信制御部３２１
に割り込みを発生させる。

【０１５１】ゲストクラスタ３２０-3内の計算機間通信
制御部３２１は、送信元のクラスタ２００より送信され
た情報の全てを受け取り、タスク３２３の通信の内容毎
に用意された受信出口を起動する。以下、一連の動作を
図１９に基づいて説明する。図１９は、本発明の第１の
実施例の計算機間の第１の通信処理動作のシーケンスチ
ャートである。

【０１５２】ステップ６０１） 送信元のクラスタ２０
０のゲストクラスタ２２０-2が有するタスク２２３は、
送信先の実計算機番号と相対計算機番号を計算機間通信
制御部２２１に転送し、当該番号を送信先として、通信
依頼を行う。タスク２２３は、自ゲストクラスタ２２０
内のパラメータ域２２２より送信先及び送信元（自クラ
スタ・ゲストクラスタ）の実計算機番号及び相対計算機
番号を取得して転送する。また、通信依頼の内容は、通
信命令、要求コード、送信先及び送信元（自クラスタ・
ゲストクラスタ）の実計算機番号及び相対計算機番号よ
りなる。

【０１５３】なお、この例では、タスク２２３が計算機
間通信制御部２２１に実計算機番号と相対計算機番号を
渡しているが、前述の実施例のように、ＳＳＵ１００に
問い合わせを行い、ＳＳＵ１００より取得する方法もあ
る。 ステップ６０２） ゲストクラスタ２２０-2の計算機間
通信制御部２２１は、クラスタ２００のＡＶＭ２１０に
対して、実計算機番号と相対計算機番号を渡す。ＡＶＭ
２１０は、実計算機番号と相対計算機番号に基づいて、
送信先の実計算機（クラスタ３００）を特定する。

【０１５４】ステップ６０３） ＡＶＭ２１０は、実計
算機番号により、通信相手が自クラスタであるか、他ク
ラスタであるかを判断する。 ステップ６０４） 自クラスタ２００である場合には、
ＡＶＭ２１０は、自クラスタ２００の相対計算機番号に
対応するゲストクラスタに対して割り込み処理を行う。

【０１５５】ステップ６０５） 他クラスタである場合
には、ＡＶＭ２１０は、送信先をクラスタ３００とし、
実計算機制御部２４０に制御を渡す。 ステップ６０６） 実計算機制御部２４０は、ＳＳＵ１
００を介してクラスタ３００に通信要求を発行する。

【０１５６】ステップ６０７） クラスタ３００の実計
算機制御部３４０は、通信要求を受け付け、実計算機番
号を参照して自クラスタに対する通信であるかを確認
し、自クラスタ３００宛の通信要求であれば、クラスタ
２００から送信された情報より仮想計算機番号を取り出
し、ＡＶＭ３１０に渡す。ＡＶＭ３１０は、実計算機制
御部３４０から相対計算機番号が割り込みを契機として
渡されると、割り込みを発生させる。

【０１５７】ステップ６０８） ＡＶＭ３１０は、相対
計算機番号に対応するゲストクラスタ３２０-3をディス
パッチする。 ステップ６０９） ＡＶＭ３１０は、対象のゲストクラ
スタ３２０-3内の計算機間通信制御部３２１に割り込み
を発生させる。

【０１５８】ステップ６１０） ゲストクラスタ３２０
-3内の計算機間通信制御部３２１は、送信元のクラスタ
２００より送信された全情報を受け取り、タスク３２３
の通信の内容毎に用意された受信出口を起動する。上記
の受信側のＡＶＭ３１０は、ゲストクラスタ３２０-3に
通信するまでの間は、送信元に対して受信状態とならな
いように制御している。

【０１５９】これは、ＳＳＵ１００を介した計算機間
（ＯＳ間）の通信を行う場合には、ハードウェアで装備
される通信命令（ＧＳＩＧＰ命令）を使用する。この通
信は、ハードウェアがＳＳＵ１００の特定領域に通信テ
キストを書き込むことで、送信は完了する。送信元は相
手が受信したか否かをテキストの全てを受け取った（Ｓ
ＳＵ１００からロードした）時点で完了と見做す。従っ
て、受信状態とは、ＳＳＵ１００上からテキストの全て
を取り出してしまうと、実際にゲストクラスタＯＳが受
信していなくても、送信元は受信状態と認識してしまう
が、ＡＶＭ３１０は、テキストの全てを取り出していな
いため、ＡＶＭ３１０が当該処理を行っても送信元では
受信したと認識されない。従って、クラスタ間の通信の
送信元では、渡した情報が全てＳＳＵ１００より送信先
により読み込まれたか否かの情報により対象計算機（ク
ラスタ、ゲストクラスタ）が通信要求内容を受信したか
を判断する。詳細は、後述するｖ．の項で詳述する。

【０１６０】なお、上記の例では、あるクラスタの１つ
のゲストクラスタに対する例を示したが、あるクラスタ
の複数のゲストクラスタまたは全ゲストクラスタに対す
る通信要求を発行することも可能である。この場合に
は、送信元のクラスタのゲストクラスタのタスクにおい
て、送信先の仮想計算機番号を必要数だけ通信要求に定
義すればよい。

【０１６１】次に、あるクラスタのゲストクラスタから
他のクラスタに通信要求を発行する場合について説明す
る。図２０は、本発明の第１の実施例の計算機間の第２
の通信動作のシーケンスチャートである。以下の説明で
は、送信元をクラスタ２００とし、送信先をクラスタ４
００として説明する。

【０１６２】ステップ７０１） 送信元のクラスタ２０
０のゲストクラスタ２２０-2が有するタスク２２３は、
送信先の実計算機番号及び相対計算機番号を計算機間通
信制御部２２１に転送し、当該番号を送信先として通信
依頼を行う。タスク２２３は、自ゲストクラスタ２２０
内のパラメータ域２２２より送信先及び送信元（自クラ
スタ・ゲストクラスタ）の実計算機番号及び相対計算機
番号を取得して転送するものとする。

【０１６３】ステップ７０２） ゲストクラスタ２２０
-2の計算機間通信制御部２２１は、クラスタ２００のＡ
ＶＭ２１０に対して、実計算機番号及び相対計算機番号
を渡す。ＡＶＭ２１０は、実計算機番号に基づいて、送
信先の計算機（クラスタ４００）を特定する。

【０１６４】ステップ７０３） ＡＶＭ２１０は、実計
算機番号により、通信相手が自クラスタであるか、他実
クラスタであるかを判断し、自クラスタ２００である場
合には、処理を終了する。 ステップ７０４） 通信相手が他実クラスタである場合
には、実計算機制御部２４０は、通信要求をＳＳＵ１０
０を介して送信先のクラスタ４００に送信する。

【０１６５】ステップ７０５） クラスタ４００の実計
算機制御部４４０は、通信要求より実計算機番号を取り
出し、自クラスタ４００に対する通信であるかを確認す
る。 ステップ７０６） 実計算機制御部４４０は、計算機間
通信制御部４３１に通信要求を転送する。

【０１６６】ステップ７０７） 計算機間通信制御部４
３１は、タスク４２３の通信用受信出口を起動させる。
これらの一連の処理により、クラスタのゲストクラスタ
と他クラスタのゲストクラスタ間の通信及びクラスタの
ゲストクラスタと他のクラスタ間の通信が可能となる。

【０１６７】なお、上記の例に限定されることなく、送
信元・送信先共にクラスタであったり、送信元がクラス
タ（実計算機）であり、送信先が他のクラスタのゲスト
クラスタであっても通信が可能である。 ［v. 通信割り込み処理］次に、本発明の第１の実施例
の割り込み処理について説明する。

【０１６８】本実施例は、クラスタまたは、他のクラス
タ上の仮想計算機制御部より発行されたシステム間の通
信割り込み（ＧＳＩＧＰ命令割り込み）がＡＶＭに対し
て発行された場合、または、ＡＶＭ内に他のクラスタか
ら通信要求が発行された場合に、当該要求を受け付けキ
ューイングするものである。

【０１６９】第１の例は、受信側のクラスタのＡＶＭ内
に通信要求をキューイングする機能を付与し、当該キュ
ーイングのキューの数が溢れた場合には、全てのクラス
タに通信要求の送信先となっているゲストクラスタを通
知し、送信元からの通信要求を停止させる機能を付与す
る。

【０１７０】図２１は、本発明の第１の実施例の割り込
み処理の第１の例を説明するための図であり、図２２
は、本発明の第１の実施例の割り込み処理の第１の例の
動作のシーケンスチャートである。 ステップ８０１） 送信元のクラスタ４００から送信先
をクラスタ２００のゲストクラスタ２２０-2とした通信
要求として、ＧＳＩＧＰ命令（ａ）がＳＳＵ１００を介
して発行される。

【０１７１】ステップ８０２） 送信先のクラスタ２０
０は、実計算機制御部２４０において、割り込みが反映
状態ではないので、割り込みを保留する。 ステップ８０３） ＡＶＭ２１０が割り込み可能な状態
になると、実計算機制御部２４０は、ＡＶＭ２１０に割
り込みを反映する。この時点で、割り込み保留が解除さ
れるため、他のクラスタからは、割り込みが反映された
ように見える。

【０１７２】ステップ８０４） ＡＶＭ２１０はＧＳＩ
ＧＰ命令（ａ）を取得し、相対計算機番号により送信先
のゲストクラスタを特定し、送信先のゲストクラスタ毎
にキューイングする（この状態では、ゲストクラスタが
割り込み反映不可状態であるとする）。

【０１７３】ステップ８０５） ここで、クラスタ４０
０から、２回目のＧＳＩＧＰ命令（ｂ）がＳＳＵ１００
を介してクラスタ２００のゲストクラスタ２２０-2を送
信先として発行される。 ステップ８０６） 送信先のクラスタ２００は、上記ス
テップ８０２と同様に、実計算機制御部２４０におい
て、割り込みを保留する。

【０１７４】ステップ８０７） ＡＶＭ２１０にＧＳＩ
ＧＰ命令（ｂ）の割り込み要求を要求キューにキューイ
ングする。 ステップ８０８） ＡＶＭ２１０は、キューイングされ
ている先頭の通信要求をゲストクラスタ２２０-2に反映
する。以下順次、キュー待ち行列からキューを取り出
し、ゲストクラスタに反映する。

【０１７５】ステップ８０９） ３回目の通信要求がク
ラスタ４００から送信先をクラスタ２００のゲストクラ
スタ２２０-2としたＧＳＩＧＰ命令（ｃ）が発行され
る。 ステップ８１０） クラスタ２００の実計算機制御部２
４０は、当該ＧＳＩＧＰ命令（ｃ）を保留する。

【０１７６】ステップ８１１） ＡＶＭ２１０は上記通
信要求ＧＳＩＧＰ命令（ｃ）を要求キューにキューイン
グする。 ステップ８１２） ＡＶＭ２１０は、ステップ８１１に
おいてキューイングを行うが、ここで、キュー溢れが発
生したものとする。

【０１７７】ステップ８１３） このとき、ＡＶＭ２１
０は、送信元のクラスタ４００に対して通信要求を停止
するよう指示する。なお、本ステップでは送信元のクラ
スタ４００に通信要求停止指示を行っているが、他のク
ラスタから送信されている場合も同様に、送信元のクラ
スタの実計算機番号を取得し、通信要求停止指示を発行
する。また、他のクラスタのゲストクラスタが送信元で
ある場合には、実計算機番号以外に、相対計算機番号も
取得して、送信元のクラスタのゲストクラスタ宛に通信
要求停止指示を発行するものとする。

【０１７８】次に、通信割り込み処理の第２の例を説明
する。図２３は、本発明の第１の実施例の通信割り込み
処理の第２の例を説明するための図である。上記第１の
例では、送信先のゲストクラスタのキューイング中にキ
ューが要求キューより溢れた場合には、異常発生として
通信要求送信元に通信要求発行停止指示を送出する例を
示したが、第２の例では、送信された通信要求の送信先
のゲストクラスタに異常が発生した場合に、同一クラス
タの他のゲストクラスタに割り込みを行う例である。

【０１７９】図２４は、本発明の第１の実施例の通信割
り込み処理の第２の例の動作シーケンスチャートであ
る。図２２のステップ８１０までは同一であるため、説
明を省略する。 ステップ９０１） 送信先のクラスタ２００のＡＶＭ２
１０において、送信元のクラスタ４００から指定されて
いる送信先以外のゲストクラスタやクラスタに割り込み
を行う。同図の例では、クラスタ４００で指定されたゲ
ストクラスタ２２０-1に対応する要求キューからキュー
が溢れている、または、他の異常が発生したため、他の
ゲストクラスタ２２０-2、２２０-3に割り込みを行う。

【０１８０】ステップ９０２） 送信元のクラスタ４０
０で指定された送信先のゲストクラスタに異常が発生し
た旨を、ＡＶＭとゲストクラスタ内の計算機間通信制御
部（ＯＳ）とハンドシェイクして、ＧＳＩＧＰ命令によ
る通信割り込みによりクラスタ４００に送信する。これ
により、ゲストクラスタ２２０-1に異常が発生した場合
に、当該ゲストクラスタ２２０-1に対する通信を停止す
るようにクラスタ４００に対して通知することができ
る。

【０１８１】ステップ９０３） 送信元のクラスタ４０
０及び他のクラスタ（ＯＳ）では、ＧＳＩＧＰ命令によ
り送信先のゲストクラスタに異常が発生したことを認識
する。次に、通信割り込み処理の第３の例を説明する。

【０１８２】第３の例は、新規割り込みが発生した場合
に、ＳＳＵ１００上にキューイングしている通信要求が
存在するかを確認し、存在する場合にはＳＳＵ１００上
にキューイングされている通信要求も処理する方法であ
る。図２５は、本発明の第１の実施例の通信割り込み処
理の第３の例を説明するための図である。同図に示す構
成は、クラスタ４００、ゲストクラスタ２２０-1
（ａ）、２２０-2（ｂ）により運用されているクラスタ
２００、クラスタ５００より構成される。クラスタ４０
０は、クラスタ２００内のゲストクラスタ２２０-1宛に
ＧＳＩＧＰ命令を発行し、クラスタ５００は、クラスタ
２００内のゲストクラスタ２２０-2（ｂ）に対してＧＳ
ＩＧＰ命令を発行するものとして以下で説明する。

【０１８３】図２６、２７は、本発明の第１の実施例の
通信割り込み処理の第３の通信動作のシーケンスチャー
トである。 ステップ１５０１） 送信元のクラスタ４００は、クラ
スタ２００のゲストクラスタ２２０-1（ａ）に対して通
信を行うため、ＧＳＩＧＰ命令を発行する。

【０１８４】ステップ１５０２） クラスタ２００は、
割り込みが反映状態でないため、実計算機制御部２４０
で割り込みを保留する。 ステップ１５０３） 送信元のクラスタ５００は、クラ
スタ２００のゲストクラスタ２２０-2（ｂ）に対して通
信を行うため、ＧＳＩＧＰ命令を発行する。

【０１８５】ステップ１５０４） 既にクラスタ２００
では、割り込みが保留中であるので、クラスタ５００は
保留を認識する。 ステップ１５０５） クラスタ５００は、クラスタ２２
０−２に対する通信要求をＳＳＵ１００にキューイング
する。

【０１８６】ステップ１５０６） クラスタ４００は、
クラスタ２００のゲストクラスタ２００-1にＧＳＩＧＰ
命令を発行する。 ステップ１５０７） この時点で、クラスタ２００の実
計算機制御部２４０では、まだ割り込みが保留中である
ので、クラスタ４００は保留を認識する。

【０１８７】ステップ１５０８） クラスタ４００は、
クラスタ２００のゲストクラスタ２２０-1（ａ）宛の通
信要求をＳＳＵ１００にキューイングする。 ステップ１５０９） ここで、ゲストクラスタ２２０-1
（ａ）の割り込み反映が可能となったとする。

【０１８８】ステップ１５１０） 実計算機制御部２４
０がＡＶＭ２１０に割り込みを反映する。この時点で割
り込み保留が解除されるため、他のクラスタからは、割
り込みが反映されたように見える。 ステップ１５１１） クラスタ２００のＡＶＭ２１０
は、ゲストクラスタ２２０-1（ａ）の割り込み要求をＡ
ＶＭ２１０内の割り込み要求キューにキューイングす
る。但し、この段階ではゲストクラスタ２２０-1（ａ）
が割り込み不可の状態であるものとする。

【０１８９】ステップ１５１２） 上記のステップ１５
１１と同時に、割り込み反映を行うゲストクラスタ以外
のＳＳＵ１００を共有する全てのゲストクラスタに対す
る新規割り込みを各ゲストクラスタ毎にキューイングす
る。 ステップ１５１３） ＡＶＭ２１０は、ゲストクラスタ
２２０-1（ａ）の割り込み反映が可能となると、ＡＶＭ
２１０内のゲストクラスタ２２０-1（ａ）用の割り込み
要求キューの先頭から順次反映する。

【０１９０】ステップ１５１４） ＡＶＭ２１０は、ゲ
ストクラスタ２２０-2（ｂ）の割り込み反映が可能とな
ると、ＡＶＭ２１０内のゲストクラスタ２２０-2（ｂ）
用の割り込み要求キューの先頭から新規割り込みによる
通信要求を順次反映する。 ステップ１５１５） クラスタ２００のゲストクラスタ
２２０-1（ａ）のＯＳは、ＳＳＵ１００にキューイング
されているゲストクラスタ２２０-1への通信要求が存在
しているかを確認し、存在していれば、当該通信要求を
取得し、ゲストクラスタ２２０-1に反映する。

【０１９１】ステップ１５１６） クラスタ２００のゲ
ストクラスタ２２０-2のＯＳは、ＳＳＵ１００に、新規
割り込みのためにキューイングされているゲストクラス
タ２２０-2（ｂ）への通信要求が存在しているかを確認
し、存在していれば、当該通信要求を取得し、ゲストク
ラスタ２２０-2（ｂ）に反映する。

【０１９２】上記のように、種々割り込みの形態が異な
っていても通信要求を確実に送ることが可能である。上
記のシーケンスチャートを各割り込み発生事象でみた場
合の例を図２８に示す。

【０１９３】ＧＳＩＧＰ命令を発行するクラスタはクラ
スタ４００とクラスタ５００の２つのクラスタである。
ＧＳＩＧＰ命令を受信するクラスタは、クラスタ２００
とする。クラスタ４００で発行されたクラスタ２００の
ゲストクラスタ２２０-1宛の通信要求が発生すると、Ｇ
ＳＩＧＰ命令が発行され、割り込み反映処理側であるク
ラスタ２００に送信される。

【０１９４】ここで、クラスタ２００が割り込みを保留
しているものとする。その間にクラスタ４００で再度、
別の通信要求が発生した場合に、ＧＳＩＧＰ命令を発行
して、クラスタ２００に送信するが、まだ割り込みを保
留しているので、この通信要求は、ＳＳＵ１００上のゲ
ストクラスタ２２０-1宛の要求キューにキューイングさ
れる。

【０１９５】一方、クラスタ５００において、クラスタ
２００のゲストクラスタ２２０-2（ｂ）に対する通信要
求が発生し、ＧＳＩＧＰ命令が発行され、クラスタ２０
０に送信されるが、まだ、割り込みを保留しているた
め、この通信要求もＳＳＵ１００上のゲストクラスタ２
２０-2（ｂ）宛の要求キューにキューイングされる。

【０１９６】ここで、クラスタ２００のＡＶＭ２１０に
割り込みが可能となり、割り込みを受け付けると、ＡＴ
Ｍ２１０がゲストクラスタ２２０-1宛の割り込み要求を
自ＡＶＭ内の待ちキュー行列にキューイングする。そこ
で、ゲストクラスタ２２０-1のＯＳは、キューイングさ
れている通信要求を順次処理していき、ＡＶＭ２１０に
より反映される。

【０１９７】ＡＶＭ２１０が同時に他のゲストクラスタ
２２０-2（ｂ）宛の割り込み要求をキューイングし、ゲ
ストクラスタ２２０-2（ｂ）に反映させる。そこで、ゲ
ストクラスタ２２０-2（ｂ）のＯＳは、ＳＳＵ１００上
にキューイングされている通信要求がなくなるまで、順
次当該通信要求を処理していく。

【０１９８】このように、ゲストクラスタで運用してい
るクラスタ（仮想計算機運用実計算機）のＡＶＭと、各
ゲストクラスタとの間の通信割り込みの状態を各々異な
っていても通信要求を確実に送信することが可能とな
る。 ［vi. 完了処理（リセット処理）］以下に説明するリ
セット処理は、あるクラスタ内のゲストクラスタが他の
クラスタとＳＳＵ１００を共有し、ＳＳＵ１００に具備
されたシステム制御機能（以下、ＧＳＩＧＰ命令（リセ
ット））を使用して制御する場合において、システム制
御の完了を認識する際に、クラスタまたは他のクラスタ
のゲストクラスタからＧＳＩＧＰ命令（リセット）で特
定のゲストクラスタを指定し、リセットを依頼するもの
である。このとき、クラスタ内のＡＶＭは、指定された
リセットを行うゲストクラスタを認識してリセットの制
御を行う。なお、異常が発生したダウンクラスタの制御
時におけるＩ／Ｏのリセットについては第２の実施例で
後述する。

【０１９９】図２９は、本発明の第１の実施例のリセッ
ト処理を説明するための図である。同図において、クラ
スタ４００がゲストクラスタ２２０-1、２２０-2により
運用されているクラスタ２００のゲストクラスタ２２０
-1にリセット依頼（ＧＳＩＧＰ命令）を発行し、クラス
タ４００において、リセットの完了を認識する処理であ
る。また、クラスタ２００がゲストクラスタ２２０−１
をリセット中に、他のクラスタ５００よりクラスタ２０
０のゲストクラスタ２２０-2（ｂ）にリセット依頼を発
行すると、同図の例では、クラスタ４００からのリセッ
ト依頼がクラスタ２００上で起動されているため、クラ
スタ５００からのリセット依頼はクラスタ２００の実計
算機制御部２４０上で保留され、ゲストクラスタ２２０
-1のリセット処理が完了した段階でクラスタ５００から
のリセット依頼が起動される。

【０２００】さらに、リセットが完了した場合には、Ａ
ＶＭ２１０と依頼元クラスタ（ＯＳ）とがハンドシェイ
クして、リセットの依頼元のクラスタ４００、５００に
対して、図８の種別８に示される内容が送信される。こ
れにより、依頼元のクラスタ４００、５００は、リセッ
トの完了を正しく認識できる。

【０２０１】図３０は、本発明の第１の実施例のリセッ
ト処理動作のシーケンスチャートである。動作の順序
は、上記の図２９に対応するものとする。 ステップ１６０１） クラスタ４００の計算機間通信制
御部（ＯＳ）は、クラスタ２００のゲストクラスタ２２
０-1に対して、ＧＳＩＧＰ命令（リセット依頼）を発行
する。

【０２０２】ステップ１６０２） クラスタ２００は、
クラスタ４００から送信されたＧＳＩＧＰ命令（リセッ
ト依頼）を受信し、実計算機制御部（ハードウェア）２
４０で要求を保留する。 ステップ１６０３） クラスタ２００のＡＶＭ２１０
は、リセット要求を認識すると、実計算機制御部２４０
に対してリセット保留の解除を指示する。

【０２０３】ステップ１６０４） ここで、クラスタ５
００よりクラスタ２００のゲストクラスタ２２０-2に対
するＧＳＩＧＰ命令（リセット）依頼が発行される。 ステップ１６０５） クラスタ２００では、クラスタ５
００から発行されたＧＳＩＧＰ命令を実計算機制御部２
４０上にリセット保留としておく。

【０２０４】ステップ１６０６） クラスタ２００のＡ
ＶＭ２１０は、ゲストクラスタ２２０-1のリセットが完
了すると、ＡＶＭ２１０が完了通知をクラスタ４００に
送信する。 ステップ１６０７） ＡＶＭ２１０は、実計算機制御部
２４０にリセット保留となっているクラスタ５００から
のリセット依頼を認識すると、実計算機制御部２４０に
対してリセット保留を解除して、クラスタ２００のゲス
トクラスタ２２０-2（ｂ）のリセット処理を起動する。

【０２０５】ステップ１６０８） クラスタ２００のＡ
ＶＭ２１０は、ゲストクラスタ２２０-2（ｂ）のリセッ
ト処理が終了すると、ＡＶＭ２１０が完了通知をクラス
タ５００に送信する。図３１は、本発明の第１の実施例
のリセット処理の発生事象でみた場合の例を示す。同図
において、最初にクラスタ４００からクラスタ２００の
ゲストクラスタ２２０-1に対してＧＳＩＧＰ命令（リセ
ット依頼）を発行すると、クラスタ２００のＡＶＭ２１
０は、リセットを保留する。クラスタ４００は、クラス
タ２００に受信された時点でＧＳＩＧＰ命令が成功した
ものと判定し、リセット完了報告の通知を待機する。ク
ラスタ２００のＡＶＭ２１０は、ＧＳＩＧＰ命令を受信
したことを認識すると、実計算機制御部のリセット保留
状態を解除して、ゲストクラスタ２２０-1のリセット処
理を起動して、リセット処理を行う。

【０２０６】ここで、他のクラスタ５００がクラスタ２
００の他のゲストクラスタ２２０-2（ｂ）に対してＧＳ
ＩＧＰ命令（リセット依頼）を発行する。クラスタ５０
０は、このＧＳＩＧＰ命令がクラスタ２００に受信され
たことを認識すると、ＧＳＩＧＰ命令が成功したものと
判断して、完了通知を待機する。

【０２０７】先に依頼を発行したクラスタ４００のリセ
ットが完了すると、クラスタ２００のＡＶＭ２１０は、
ＧＳＩＧＰ命令（通信：ハンドシェイク）により所定の
要求コード（図８−種別８）によるリセット完了通知を
発行する。その後、クラスタ５００のリセット依頼に対
するリセット処理が完了すると、クラスタ４００に発行
した方法と同様にリセット完了通知を発行する。

【０２０８】［第２の実施例］本実施例では、複数のク
ラスタがＳＳＵにより結合するＳＣＭＰシステムにおい
て、クラスタに異常が発生した場合の処理について説明
する。本実施例では、以下の順序で説明するものとす
る。

【０２０９】i. ＡＶＭによるダウン通知処理 ii. ＡＶＭ運用クラスタのダウン検出処理 iii. ＡＶＭ運用実クラスタ制御処理 iv. ＡＶＭ運用クラスタのＩ／Ｏリセット処理 v. 自実クラスタ制御時の待機処理 vi. ゲストクラスタのセッションの閉塞時の処理 vii. オペレータ介入の軽減処理 ［ｉ．ＡＶＭによるダウン通知処理］図３２は、本発明
の第２の実施例の処理概要を示す。

【０２１０】同図では、ＳＳＵ１００に３つのクラスタ
２００、３００、４００が接続されている構成である。
クラスタ２００、３００は、ＡＶＭ運用され、各々ＯＳ
を有する３つずつのゲストクラスタを有するものとす
る。クラスタ４００は、実クラスタでありＯＳにより運
用される。ＡＶＭ運用されるクラスタ３００においてＡ
ＶＭ３１０が回復不能な異常によりダウンしている状態
を示す。このとき、ＡＶＭ３１０は、自己のダウンをＳ
ＳＵ１００を介して、全クラスタに対して通知する。

【０２１１】上記の状態を詳細に説明する。図３３は、
本発明の第２の実施例のダウン通知時における各クラス
タの処理を示す。同図は、図３２に示すクラスタ配置と
同様である。本来ＡＶＭ運用されているＡＶＭ構成は同
一であるが、説明の明瞭化のため、個々のクラスタ毎に
説明する。

【０２１２】ＳＳＵ１００は、各クラスタ毎に、クラス
タ制御を獲得状況を記憶するクラスタ制御獲得フィール
ド１２０と、ダウンしたクラスタを記憶するダウンクラ
スタ管理フィールド１３０より構成される。クラスタ制
御獲得フィールド１２０は、図３４に示すように、各ク
ラスタ毎にＳＳＵ１００内に具備され、制御クラスタア
ドレス格納域１１１、ＩＰＬ世代域１１２、制御状態情
報１１３より構成される。

【０２１３】制御クラスタアドレス格納域１１１には、
あるクラスタのダウンを他の動作中のクラスタが検出し
た場合に、検出したクラスタのアドレスを書き込む。つ
まり、この制御クラスタアドレス格納域１１１に書き込
んだクラスタが、本クラスタ制御獲得フィールドのクラ
スタを制御する権利を取得したことになる。図３４の例
において、例えば、クラスタ３００のアドレスを“ＡＡ
ＡＡＢＢＢＢ”とした場合、クラクタ３００がクラスタ
２００の制御権を取得したことになる。

【０２１４】ＩＰＬ世代域１１２は、ダウンを誤認しな
いようにするため、ＩＰＬを行った世代番号が設定され
る。制御状態情報１１３は、ダウンクラスタの制御クラ
スタを取得できなかったクラスタで、制御が完了した時
点で行う回収処理のためのタイミングを通知するための
情報が設定される。

【０２１５】ダウンクラスタ管理フィールド１３０は、
ダウンしたクラスタに関する情報を格納するフィールド
であり、格納される主な情報として、 ・ハードウェア監視機能が有効であるか否か； ・自クラスタがＡＶＭ運用中のゲストクラスタであるか
実クラスタであるか； ・自クラスタを制御する際の時間； ・ＣＰＵモデル がある。これらの情報は、ＩＰＬ時に予め登録してお
き、自クラスタがダウンした時に、この情報に基づい
て、他のクラスタより制御を行う。

【０２１６】図３３において、クラスタ２００とクラス
タ４００は、クラスタ３００のＡＶＭ３１０から障害発
生の通知を受信するクラスタであるとする。クラスタ２
００は、ＡＶＭ２１０と複数のゲストクラスタ２２０−
１、２２０−２、２２０−３より構成される。ＡＶＭ２
１０は、通信受信部２１１を有し、自クラスタ２００内
の各ゲストクラスタ内のゲストクラスタＯＳ（オペレー
ティングシステム）に対して、他のクラスタから受信し
たダウン通知を通知する。クラスタ２００の配下の各ゲ
ストクラスタ２２０−１、２２０−２、２２０−３は、
各々、ゲストクラスタＯＳ２５０を有し、各ＯＳ２５０
は、ダウン通知受信部２５１、ダウン認識部２５２、ダ
ウンクラスタ制御部２５３、資源回収処理部２５４及び
ホットスタンバイ処理部２５５より構成される。

【０２１７】ダウン通知受信部２５１は、他のクラスタ
からのダウン通知をＡＶＭ２１０の通信送受信部２１１
を介して受信し、通信のパラメータ解析を行う。ダウン
認識部２５２は、ダウンクラスタの認識を行うと共に、
ダウン理由の認識を行う。

【０２１８】ダウンクラスタ制御部２５３は、以下に示
す処理を行う。詳細な動作は後述する。 ・ダウンクラスタの運用形態の認識 ・ダウンが発生した時点においてＡＶＭが実行中か否か
の検査 ・配下のゲストクラスタがダウンしているか否かの検査 ・ダウンクラスタの制御権を獲得 ・ダウンクラスタのＣＰＵを停止 ・リセットが有効な状態であるかの検査（ハードウェア
監視機能が有効であるかの検査） ・ダウンクラスタの入出力のリセット ・ダウンクラスタのダンプ採取 ホットスタンバイ処理部２５５は、ダウンクラスタ制御
部２５３において、ダンクラスタの制御の完了、また
は、オペレータ介入によるダウンクラスタの制御の完了
を以てホットスタンバイを行う。

【０２１９】ホットスタンバイの具体的な処理として、
ホットスタンバイを行うクラスタを特定し、回収処理を
行う。回収処理として、ＤＡＳＤ上の資源、ＳＳＵ上の
資源、システムが有する情報（ゲストクラスタがダウン
しているか否か等）等をリセットする等の処理がある。

【０２２０】次に、クラスタ３００は、ＡＶＭ３１０に
おいてダウンが発生すると、当該ダウンを検出するダウ
ン認識処理部３１１０と、ダウンの発生をＳＳＵ１００
を介して他のクラスタに通知するダウン通知処理部３１
２０をＡＶＭ３１０内に有する。

【０２２１】クラスタ４００は、ゲストクラスタを持た
ない実クラスタであり、当該クラスタのＯＳ４５０は、
上記のクラスタ２００と同様の構成のダウン通知受信部
４５１、ダウン認識部４５２、ダウンクラスタ制御部４
５３、資源回収処理部４５４、ホットスタンバイ処理部
４５５を有する。これらの各部は、クラスタ２００の各
部と同様の処理を行うため、説明を省略する。

【０２２２】図３５は、本発明の第２の実施例のダウン
の発生を通知・認識動作を示すシーケンスチャートであ
る。同図において、ＳＳＵ１００の記載は省略する。 ステップ１７１０） クラスタ３００のＡＶＭ３１０に
おいて何等かの回復不能な異常が発生したとする。

【０２２３】ステップ１７２０） クラスタ３００（以
下ダウンクラスタという）のダウン認識処理部３１１０
は、ダウンが発生したことを認識して、ダウン通知処理
部３１２０に通知する。 ステップ１７３０） ダウンクラスタ３００のＡＶＭ３
１０のダウン通知処理部３１２０は、ＳＳＵ１００を介
してクラスタ２００及びクラスタ４００に通知する。通
知の方法は、第１の実施例で説明したようにクラスタ間
の通信機能を用いて通知する。なお、ダウンを他のクラ
スタに通知する際に、他のクラスタがＡＶＭ運用中であ
る場合には、当該他のクラスタのＡＶＭの配下のゲスト
クラスタに通知するものとする。

【０２２４】ステップ１７４０） クラスタ２００のＡ
ＶＭ２１０の通信受信部２１１は、ダウンクラスタ３０
０からダウンの通知を受信すると、ＡＶＭ運用している
配下のゲストクラスタ２２０−１、２２０−２、２２０
−３のダウン通知受信部２５１に通知する。

【０２２５】ステップ１７５０） ダウン通知受信部２
５１は、ダウン通知時に渡されるパラメータを解析す
る。 ステップ１７６０） ダウン認識部２５２は、パラメー
タ解析の結果によりダウンしたクラスタ及びダウンした
理由を特定する。

【０２２６】ステップ１７７０） クラスタ制御部２５
３は、ダウンクラスタ３００に対する制御を行う。詳細
は、図３６で詳細に説明する。 ステップ１７８０） クラスタ２００のホットスタンバ
イ処理部２５５は、クラスタ制御部２５３の処理により
ダウンクラスタの制御が完了した場合、または、オペレ
ータの介入によりダウンクラスタ３００の制御が完了し
た場合に、ホットスタンバイを実現する。

【０２２７】ステップ１７９０） 本ステップからステ
ップ１８２０に関しては、実クラスタ４００がステップ
１７３０において、ダウンクラスタ３００からダウン通
知を受信した以降は、上記のステップ１７５０〜ステッ
プ１７８０の処理と同様であるので説明を省略する。

【０２２８】図３６は、本発明の第２の実施例のダウン
クラスタの制御処理のフローチャートである。以下に示
す処理は、上記のステップ１７７０及びステップ１８１
０に対応する処理であり、クラスタ２００内のゲストク
ラスタ２２０ががダウンクラスタ３００に対して行う例
を示す。ステップ１８１０の処理ではクラスタ４００が
行うことになるが、クラスタ４００では、ＧＳＩＧＰ命
令を発行せず、クラスタ２００（クラスタ２００内のゲ
ストクラスタ内の１つ）が行う制御の完了を待つ。

【０２２９】ステップ１７７１） まず、ダウンクラス
タ制御部２５３は、ダウンクラスタ３００のＡＶＭ３１
０が運用中であるか否かを判定し、運用中である場合に
はステップ１７７２に移行する。運用中でない場合に
は、当該ダウンクラスタの制御処理を終了する。

【０２３０】ステップ１７７２） ＡＶＭ３１０が運用
中である場合には、ダウン通知がＡＶＭ３１０自身の自
己申告ダウンであるか否かを判定し、ＡＶＭ３１０の自
己申告ダウンである場合にはステップ１７７３に移行
し、そうでないならば、運用中の実クラスタに対する制
御を行う。

【０２３１】ステップ１７７３） ダウンクラスタ３０
０のＡＶＭ３１０が運用中であり、かつ、自己申告ダウ
ンである場合には、ダウンクラスタ３００の配下のゲス
トクラスタを特定し、当該ゲストクラスタ内で生存中の
ものをダウン状態とする。 ステップ１７７４） ダウンクラスタ制御部２５３は、
ダウンクラスタ３００のＣＰＵの停止や、Ｉ／Ｏリセッ
ト、ダンプ採取のためにダウンクラスタ３００の制御権
を取得する。ダウンクラスタ３００の制御権の取得は、
ＳＳＵ１００上のクラスタ制御獲得フィールド１１０に
前述のパラメータ解析により取得したダウンクラスタの
アドレスを書き込むことにより獲得できる。なお、ダウ
ンクラスタ制御権を取得するクラスタは、ＧＳＩＧＰ命
令を発行するクラスタであり、ＳＣＭＰシステム内で１
クラスタのみである。他のクラスタは、制御権を有する
クラスタの制御が完了するのを待機することになる。

【０２３２】ステップ１７７５） ダウンクラスタ制御
権を獲得したクラスタ２００は、対象となるダウンクラ
スタ３００のＣＰＵを停止した後、ＳＳＵ１００を参照
してダウンクラスタ３００のリセット機能が有効か否か
の判定を行う。ハードウェア（サービスプロセッサ）
は、各クラスタが初期化時において、ハードウェア（Ｓ
ＶＰ）監視機能が有効か無効であるかをＳＳＵ１００上
に記録しておく。

【０２３３】ステップ１７７６） ダウンクラスタ制御
部２５３は、ダウンクラスタ３００用のダウンクラスタ
管理フィールド１２０を参照して、ダウンクラスタ３０
０のリセット機能が有効である場合には、ステップ１７
７７に移行し、無効の場合には、ステップ１７７８に移
行する。

【０２３４】ステップ１７７７） リセット機能が有効
である場合には、ダウンクラスタ３００が、ＡＶＭ運用
中の実クラスタであっても有効な強制リセットをハード
ウェアに対してＳＶＰに指示し、ステップ１７７９に移
行する。なお、一般的には、ＳＶＰ監視機能は“有効”
に設定しておくものとする。

【０２３５】ステップ１７７８） また、リセット機能
が無効である場合には、ハードウェアによる強制リセッ
トは行わず、オペレータ介入によりＩ／Ｏリセットを行
い、処理を終了する。この場合、オペレータ用にディス
プレイ装置（図示せず）に介入要求を表示する等してオ
ペレータに介入操作を依頼する。

【０２３６】ステップ１７７９） ダウンクラスタ３０
０のダンプを採取し、障害箇所の検出作業を行う。 ［ii. ＡＶＭ運用クラスタのダウン検出処理］次に、Ａ
ＶＭ運用中のクラスタにおけるダウンを他のクラスタで
認識する処理を説明する。

【０２３７】図３７は、本発明の第２の実施例の他のク
ラスタからダウンクラスタを認識する処理概要を説明す
るための図である。同図に示す例は、ＳＳＵ１００に接
続されるクラスタ２００、３００、４００のうち、クラ
スタ３００のゲストクラスタ３２０−２がダウンした場
合の例である。ゲストクラスタ３２０−２のダウンは、
クラスタ２００の各ゲストクラスタ２２０−１、２２０
−２、２２０−３及びクラスタ３００のゲストクラスタ
３２０−１、３２０−３、クラスタ４００で検出され
る。

【０２３８】このとき、ダウンしたクラスタ３００のゲ
ストクラスタ３２０−２に対する制御権は、ダウンを認
識した全クラスタが、ＳＳＵ１００のクラス制御獲得フ
ィールド１１０にシリアライズすることで、獲得可能で
ある。図３７の例では、クラスタ２００のゲストクラス
タ２２０−２がクラスタ３００のゲストクラスタ３２０
−２の制御権を獲得したものとする。

【０２３９】図３８は、本発明の第２の実施例の他のク
ラスタのゲストクラスタのダウン認識動作のシーケンス
チャートである。ＡＶＭ運用のクラスタ３００のゲスト
クラスタ３２０−２でダウンが発生し、当該クラスタの
制御権をクラスタ２００内のゲストクラスタ２２０−２
が獲得した場合について説明する。

【０２４０】ステップ２０１０） クラスタ３００のゲ
ストクラスタ３２０−２にダウンが発生する。 ステップ２０２０） ゲストクラスタ３２０−２は、ダ
ウン通知を各クラスタに通知する。なお、ダウン通知
は、互いに監視している場合には不要である。

【０２４１】ステップ２０３０） ゲストクラスタ２２
０−２のダウン通知受信部２５１は、パラメータを生成
する。 ステップ２０４０） ゲストクラスタ２２０−２のダウ
ン通知受信部２５１は、ダウンクラスタとそのダウン理
由を特定する。

【０２４２】ステップ２０５０） ゲストクラスタ２２
０−２に対応するＡＶＭ２１０は、ダウン通知をＳＳＵ
１００を介して、クラスタ３００のＡＶＭ３１０とクラ
スタ４００のＯＳ４５０に通知すると共に、自クラスタ
２００のＡＶＭ２１０を介して自クラスタ２００の他の
ゲストクラスタ２２０−１、２２０−３にも通知する。

【０２４３】ステップ２０６０） ゲストクラスタ２２
０−２のダウンクラスタ制御部２５３は、ダウンクラス
タ３２０−２が実計算機（Native）運用であるかＡＶＭ
運用であるかを判断する。 ステップ２０７０） ダウンクラスタ３２０２がＡＶＭ
運用であるとき、ゲストクラスタ２２０−２がダウンク
ラスタ３２０−２の制御権を獲得する。

【０２４４】なお、上記の図３８に示す動作は、クラス
タ２００のゲストクラスタ２２０−２について述べてい
るが、他のクラスタでも同様の処理を行うものとする。
次に、ダウン通知を受信したクラスタ２００内のゲスト
クラスタ220-2 の動作を説明する。

【０２４５】図３９は、本発明の第２の実施例のダウン
通知を受信した際のダウンクラスタの制御動作を示すシ
ーケンスチャートである。以下の説明では、クラスタ３
００のゲストクラスタ３２０−２がダウンし、その通知
をクラスタ２００内のゲストクラスタ２２０−２が受信
した場合を例として説明する。

【０２４６】ステップ２０８０） クラスタ２００のゲ
ストクラスタ２２０−２のダウンクラスタ制御部２５３
は、ＡＶＭ２１０の通信受信部２１１に対して、ダウン
クラスタのＣＰＵ停止並びにＩ／Ｏリセットを依頼す
る。 ステップ２０９０） これにより、ＡＶＭ２１０の通信
送受信部２１１は、クラスタ３００のＡＶＭ３１０に対
してゲストクラスタ３２０−２に対するＣＰＵ停止並び
にＩ／Ｏリセットを依頼する。これは、ＣＰＵ停止のＧ
ＳＩＧＰ命令を発行すると、実クラスタ３００のＣＰＵ
が停止してしまうため、相手のクラスタのＡＶＭ３１０
に依頼するものである。

【０２４７】ステップ２１００） クラスタ３００のＡ
ＶＭ３１０は、ダウンゲストクラスタ３２０−２に対し
てＣＰＵ停止を行う。 ステップ２１１０） この間、クラスタ２００では、タ
イマ監視を行う。タイマ監視が必要な理由は、相手のＡ
ＶＭが行うＣＰＵ停止の処理時間を考慮しても、ＡＶＭ
システムに異常が発生した場合には、応答が通知されな
い場合があるためである。タイマ監視により、タイムオ
ーバとなった場合には、相手のクラスタのＡＶＭ３１０
がダウンしたものと認識し、ＡＶＭ運用クラスタ配下の
ゲストクラスタを全てＳＣＭＰシステムから切り離す。
なお、配下のゲストクラスタ個々に処理を行うと、制御
完了までに時間がかかるため、実クラスタ３００への制
御を行うようにする。

【０２４８】ステップ２１２０） ＣＰＵ停止後、クラ
スタ２００のゲストクラスタ２２０−２に対してクラス
タ間通信機能を用いて完了の通知を行う。なお、クラス
タ間通信機能については、前述の第１の実施例で説明し
ている。 ステップ２１３０） リセット完了通知がない場合に
は、クラスタ２００のダウンクラスタ制御部２５３は、
ＳＳＵ１００のダウンクラスタ管理フィールド１２０に
対して、ハードウェアによる強制的な制御が可能である
かを示すリセットが有効であるか無効であるかを検査す
る。

【０２４９】ステップ２１４０） 有効である場合に
は、ＡＶＭ３１０の通信受信部３１１にＩ／Ｏリセット
を依頼する。これにより、通信受信部３１１は、クラス
タ３００のＡＶＭ３１０に対してＩ／Ｏリセット要求を
依頼する。 ステップ２１５０） クラスタ３００のＡＶＭ３１０
は、ダウンクラスタ３２０−２のＩ／Ｏをリセットす
る。

【０２５０】ステップ２１６０） この間クラスタ２０
０では、上記のステップ２１１０と同様にタイマ監視を
行う。 ステップ２１７０） クラスタ３００のＡＶＭ３１０が
ダウンクラスタ３２０−２のＩ／Ｏリセットが完了する
と、完了通知をクラスタ２００に通知する。

【０２５１】ステップ２１８０） クラスタ２００のダ
ウンクラスタ制御部２５３は、ダウンクラスタ３２０−
２のダンプを採取する。ＯＳが検出するＡＶＭのダウン
は、以下に示す動作により検出される。 ゲストクラスタがダウンする。

【０２５２】 ゲストクラスタに対して停止及びリセ
ットをダウンゲストクラスタを管理するＡＶＭのＯＳに
依頼する。 ＡＶＭのＯＳから停止及びリセットの完了／失敗の
通知が時間内に無かった場合にＯＳがＡＶＭのダウンを
検出する。

【０２５３】なお、においてＡＶＭがゲストクラスタ
に対して行う制御は、ＣＰＵ停止とＩ／Ｏリセットを一
緒にＡＶＭに依頼し、ＡＶＭがＣＰＵ停止、Ｉ／Ｏリセ
ットと共に完了／失敗した時点で通知する。 ［iii. ＡＶＭ運用実クラスタ制御処理］ＡＶＭ運用実
クラスタの制御として、ＡＶＭがダウン（正常停止を含
む）した場合、当該クラスタの配下のゲストクラスタを
ダウンとして処理（前述のステップ１０７３の処理）す
る場合について説明する。

【０２５４】ＡＶＭ運用中の実クラスタをダウンと認識
すると、配下の生存中のゲストクラスタの数、クラスタ
アドレスを認識し、対象ゲストクラスタを管理する情報
（共用メモリ上及び主記憶上に保持）をダウン状態に書
き換える。その後、ＡＶＭ運用中の実クラスタに対し
て、ＣＰＵ停止及びＩ／Ｏリセットを行い、ダウンした
実クラスタの制御を行う。

【０２５５】さらに、ホットスタンバイのため、ダウン
した実クラスタへの制御が完了した後、配下のゲストク
ラスタが保持する資源（共用ＤＡＳＤや共用メモリ上に
保持する資源）の解放を行う。図４０は、本発明の第２
の実施例のＡＶＭ運用クラスタにおいて、ＡＶＭがダウ
ンした場合の処理を説明するための図である。同図にお
いて、クラスタ３００のＡＶＭ３１０自体にダウンが発
生すると、クラスタ２００内のゲストクラスタ２２０−
１〜２２０−３の何れかが上記のii. の項目の処理によ
り、クラスタ３００のＡＶＭダウンを認識し、ＡＶＭ３
１０配下のゲストクラスタ３２０−１，３２０−２，３
２０−３が生存中であっても、強制的にダウン状態にす
る。即ち、ＡＶＭ３１０がダウンすると、配下のゲスト
クラスタ３２０−１，３２０−２，３２０−３がダウン
していなくとも、ＡＶＭのＯＳがダウンするため、配下
のゲストクラスタは動作することができないため、ダウ
ン状態とする。これにより、他のクラスタ２００では、
個々のゲストクラスタに対して制御する必要がないた
め、ホットスタンバイの高速化が図れる。また、個々
に、ＣＰＵ停止やＩ／Ｏリセット等の制御を行わなくと
も実ＣＰＵの停止、実クラスタのＩ／Ｏリセットを行う
ため、個々の制御が不要となる。

【０２５６】［iv. ＡＶＭ運用クラスタのＩ／Ｏリセッ
ト処理］ＡＶＭ運用中のクラスタがダウンし、そのクラ
スタのＣＰＵ停止やリセットを行う場合について説明す
る。従来は、ＯＳからＧＳＩＧＰ命令を発行すると、Ａ
ＶＭ運用のクラスタ受け付けのゲストクラスタに対して
制御しているため、ＧＳＩＧＰ命令のＩ／Ｏリセット要
求は、ゲストクラスタに対してＣＰＵ停止とＩ／Ｏリセ
ットを行うための命令として用いられている。従って、
ハードウェアは、ＡＶＭ運用されたクラスタに対し、Ｇ
ＳＩＧＰ命令のＩ／Ｏリセット要求が発行されると、Ａ
ＶＭのＯＳが制御するものと認識し、ハードウェアは実
質的にＩ／Ｏリセットを行わない。

【０２５７】そこで、本発明では、ＡＶＭ運用のクラス
タ自身のダウンをＯＳが認識し、実クラスタに対しての
ＣＰＵ停止、Ｉ／Ｏリセットを行うように構成する。こ
の結果、従来のＧＳＩＧＰ命令のＩ／Ｏリセット要求に
ＡＶＭシステム自身（実クラスタ）のリセットを行う要
求が追加され、ハードウェア（ＳＶＰ）も、これを認識
した場合には、ＡＶＭが行うのではなく、ハードウェア
が実クラスタのリセットを行う。

【０２５８】図４１は、本発明の第２の実施例のＡＶＭ
運用の実クラスタのＩ／Ｏリセット処理を説明するため
の図である。各クラスタ２００、３００毎に、サービス
プロセッサ２９０、３９０を有する。サービスプロセッ
サ２９０、３９０は、ハードウェアからのリセットを行
う機能や回線異常等をサポートする機能を有し、一般に
メンテナンスサポートを行うプロセッサである。共用メ
モリ１００上には、ハードウェア管理情報領域１３０を
有し、各クラスタ毎に、ハードウェアの状態情報をＩＰ
Ｌ時に登録しておく。ハードウェアの状態情報の内容と
しては、各サービスプロセッサ２９０、３９０による監
視機能が有効であるか無効であるかが登録される。ここ
で、有効が指定されている場合には、他のクラスタから
の制御により強制的にクラスタをリセットすることがで
きるが、無効が指定されている場合には、他のクラスタ
からの制御要求が入力されても、リセットを行わない。

【０２５９】図４１において、クラスタ３００のＡＶＭ
３１０においてダウンが発生している場合に、クラスタ
２００内のゲストクラスタ２２０−１〜２２０−３のい
ずれかが、そのダウンを認識したとする。このとき、ク
ラスタ２００内のゲストクラスタ２２０−１〜２２０−
３は、ＳＳＵ１００上のハードウェア管理情報領域１３
０にアクセスし、クラスタ３００の監視機能が有効であ
るか否かを参照する。ここで、監視機能が有効である場
合には、ＯＳがまず、ＣＰＵ停止の依頼をサービスプロ
セッサ３９０に行い、サービスプロセッサ３９０による
ＣＰＵ停止が完了した後、強制リセットを指示する。サ
ービスプロセッサ３９０は、Ｉ／Ｏ要求が発行されない
ことを保証してからＩ／Ｏリセットを行う。

【０２６０】なお、監視機能の有効／無効は、ＯＳがＳ
ＳＵ１００上に記録する。図４１の例において、クラス
タ３００の中で最初にＯＳのＩＰＬを行うクラスタ（例
えばクラスタ３２０−１）が自実クラスタのサービスプ
ロセッサ監視機能が有効か無効かをＳＳＵ１００上に記
録する。つまり、ＡＶＭ運用された実クラスタ内で最初
にＩＰＬされるゲストクラスタのみがＳＳＵ１００上に
記録する。

【０２６１】［v.自実クラスタ制御時の待機処理］本制
御処理は、ＯＳがＡＶＭのダウンを検出した場合の制御
方法に関する。ＯＳが検出するＡＶＭのダウンは、ゲス
トクラスタのダウンがあり、そのゲストクラスタへの制
御を行い、ＡＶＭから停止ならびにリセットの完了／失
敗通知が行われない場合に検出される。

【０２６２】図４２は、本発明の第２の実施例の自実ク
ラスタ制御時の待ち制御処理を説明するための図であ
る。 まず、ゲストクラスタ２２０−２がダウンしたとす
る。 ＡＶＭからゲストクラスタ２２０−２に対する停止
及びリセットの完了／失敗通知がないため、実クラスタ
２００のＡＶＭがダウンしたとＯＳが認識する。ここで
言うＯＳとは、クラスタ２００のゲストクラスタ２２０
−１、２２０−３とクラスタ３００内のゲストクラスタ
３２０−１〜３２０−３の５つのクラスタのＯＳを指
す。

【０２６３】 一般に、ダウンクラスタへの制御は、
ＳＣＭＰシステム内のどれか１クラスタでのみ行うた
め、ダウンを認識したクラスタ（ＯＳ）からＳＳＵ上の
ダウンクラスタ制御権獲得フィールドをシリアライズ
（更新）する。 最初にクラスタ２００のＡＶＭのダウンをゲストク
ラスタ２２０−１や２２０−３が認識した場合、ダウン
クラスタ制御権獲得を待機する。

【０２６４】 ゲストクラスタ２２０−１や２２０−
３が待機することにより、クラスタ３００ないのいずれ
か１つのゲストクラスタでクラスタ２００の制御権を獲
得することが可能となる。従って、クラスタ２００の制
御が完了する。 また、クラスタ３００が存在していない場合には、
ゲストクラスタ２２０−１やゲストクラスタ２２０−３
が制御権を獲得することにより、自実クラスタ２００に
対し、ＣＰＵ停止要求のＧＳＩＧＰ命令を発行するた
め、実ＣＰＵが停止する。

【０２６５】このように、自実クラスタのＡＶＭのダウ
ンを自実クラスタ配下のゲストクラスタが認識し、制御
権の獲得を待機する理由は、この処理を実施しないと、
実クラスタ２００に対する制御（ＣＰＵ停止は完了、Ｉ
／Ｏリセットは未完了）が完了することはなく、クラス
タ３００内の各ＯＳではオペレータ介入メッセージを出
力し、オペレータの処置なしでは、ホットスタンバイが
実現できなくなってしまうからである。

【０２６６】［ｖ. ゲストクラスタのセッションの閉塞
時の処理］ＡＶＭのゲストクラスタがセッション閉塞
（ＤＥＡＣＴＩＶＥＴＥ）した場合、当該クラスタのＡ
ＶＭから他のクラスタに対して閉塞状態となった旨を通
知し、通知を受けたクラスタでは、当該通知よりどのゲ
ストクラスタが閉塞状態となっているのかを認識する。
但し、ゲストクラスタが閉塞となったクラスタのＡＶＭ
は、ダウンしていないため、当該閉塞状態のゲストクラ
スタのＣＰＵ停止及びＩ／Ｏのリセットを行う。

【０２６７】図４３は、本発明の第２の実施例のゲスト
クラスタのセッション閉塞時の処理概要を説明するため
の図である。同図において、クラスタ３００のゲストク
ラスタ３２０−２が閉塞状態となっている。ここで、ク
ラスタ３００のＡＶＭ３１０は、配下のゲストクラスタ
３２０−２が閉塞状態となった旨を認識し、配下のゲス
トクラスタ３２０−２のＣＰＵ停止及びＩ／Ｏリセット
を処理を行い、他のクラスタ２００内ＯＳ及び４００内
ＯＳ及びゲストクラスタ３２０−１、３２０−３にゲス
トクラスタ３２０−２の閉塞を通知する。なお、オペレ
ータによりログオフされた時点で閉塞状態になるが、ゲ
ストクラスタの閉塞を制御しているのは、ＡＶＭである
ので、ゲストクラスタのＯＳは、閉塞に関与していな
い。

【０２６８】図４４は、本発明の第２の実施例のゲスト
クラスタのセッション閉塞時の処理における各クラスタ
の構成図である。同図において、図４３と同一構成部分
には、同一符号を付す。図４４において、クラスタ３０
０のゲストクラスタ３２０−２が閉塞状態となってい
る。このとき、ＡＶＭ３１０のＤＥＡＣＴ（閉塞）認識
部３１５が“ＤＥＡＣＴ（閉塞）コマンド”を認識す
る。

【０２６９】ＡＶＭ３１０のＤＥＡＣＴ処理部３１６
は、ゲストクラスタ３２０−２のＣＰＵを停止し、Ｉ／
Ｏをリセットする。さらに、通信送受信部３１１を介し
て、他のクラスタ２００内のＯＳ、４００内のＯＳ並び
に３００内の他ゲストクラスタに配下のゲストクラスタ
３２０−２の閉塞状態を通知する。

【０２７０】クラスタ２００及びクラスタ４００の通信
受信部２１１、４１１は、クラスタ３００からの通知に
より、ゲストクラスタ３２０−２の閉塞状態を認識す
る。なお、閉塞状態の場合には、閉塞となったゲストク
ラスタを配下とするクラスタ３００のＡＶＭによりＣＰ
Ｕの停止及びＩ／Ｏリセットを行うため、既にゲストク
ラスタ３２０−２の制御は完了している。従って、ＧＳ
ＩＧＰ命令は発行しない。

【０２７１】従って、図４３において、ＡＶＭ３１０か
らゲストクラスタ３２０−２の閉塞の通知を、各クラス
タ２００内ＯＳ、４００内ＯＳ及び他ゲストクラスタが
受け取った時にゲストクラスタ３２０−２が閉塞状態で
あると認識する。また、リセットは、クラスタ３００の
ＡＶＭ３１０自体で、配下のゲストクラスタ３２０−２
のＣＰＵ停止やＩ／Ｏリセットを行う。つまり、ゲスト
クラスタ２２０−１〜２２０−３、３２０−１、３２０
−３、４２０−１〜４２０−３のいずれかのゲストクラ
スタが制御権を獲得しても、各々のクラスタのダウンク
ラスタ制御部ではＧＳＩＧＰ命令を発行しない。

【０２７２】［vi. オペレータ介入の軽減処理］オペレ
ータ介入の軽減処理は、クラスタへの制御処理（リセッ
ト、ＣＰＵ停止等）がハードウェアの故障等により失敗
した場合、オペレータの介入により、対象クラスタの制
御を代替実行するためのオペレータ介入メッセージを消
去する処理である。オペレータ介入の軽減の契機として
は、 ・クラスタが再度ＩＰＬ処理を行った場合； ・オペレータの処置完了による応答があった場合； ・ゲストクラスタに対するオペレータ介入メッセージの
場合、対象ゲストクラスタが閉塞である場合； ・ゲストクラスタに対するオペレータ介入メッセージの
場合、対象ゲストクラスタを含むＡＶＭ運用中、実クラ
スタがダウンした場合；があり、このような場合には、
配下のゲストクラスタが複数であっても複数個のメッセ
ージを削除する。

【０２７３】図４５は、本発明の第２の実施例のオペレ
ータ介入メッセージが出力されている状態を示す。同図
中、○内の数字は、制御順序を示す。同図において、ク
ラスタ２００とクラスタ４００は、実クラスタとして運
用されているクラスタであり、クラスタ３００は、ＡＶ
Ｍ運用されているクラスタである。

【０２７４】ダウンクラスタへの制御は、ＳＣＭＰシス
テム内で１つのクラスタのみ行う。従って、他のクラス
タ（ＯＳ）では、その制御が完了するのを待つことにな
る。制御が完了した場合、または、失敗した場合は、Ｓ
ＳＵ上に制御クラスタが表示し、制御権のないクラスタ
は、その表示情報を参照する。制御に失敗した場合は、
全クラスタでオペレータ介入メッセージをコンソールに
出力する。この処理は、各クラスタが隣接していない場
合に、最初に気づいたオペレータが応対することが可能
となる。

【０２７５】ここで、クラスタ２００のＯＳがクラスタ
３００のゲストクラスタ３２０−１の制御を失敗した場
合に、クラスタ２００に接続されている表示装置２９１
上に、ゲストクラスタ３２０−１に関するオペレータ介
入メッセージを表示する。さらに、ゲストクラスタ３２
０−２の制御も失敗すると、表示装置２９１上にゲスト
クラスタ３２０−２のオペレータ介入メッセージを表示
する。

【０２７６】図４６は、本発明の第２の実施例のオペレ
ータ介入抑止時の状態を示す。 同図において、ゲストクラスタ３２０−１、３２０
−２に対する制御が失敗している。従って、生存中のク
ラスタ（２００，３２０−３、４００）では、ゲストク
ラスタ３２０−１、３２０−２に対するオペレータ介入
メッセージが出力されている。

【０２７７】 の状態の時、クラスタ３００のＡＶ
Ｍがダウンしたものとする。 クラスタ２００やクラスタ４００、ゲストクラスタ
３２０−３でＡＶＭのダウン（）を認識する。 各クラスタ（２００、３２０−３、４００）では、
ＳＳＵ上の情報に基づいて実クラスタ３００配下のゲス
トクラスタに対するオペレータ介入メッセージを出力し
ているかを判断する。

【０２７８】 において出力されていると判定され
た場合には、オペレータ介入メッセージを消去する。ま
た、上記の例は、ゲストクラスタに対するオペレータ介
入メッセージを実クラスタを制御する際に消去している
が、同様の処理を閉塞時でも実現できる。図４６におい
て、クラスタ３００のゲストクラスタ３２０−１がダウ
ンし、何等かの理由により失敗し、ＯＳが失敗を認識し
た場合、他の生存中のクラスタでは、ゲストクラスタ３
２０−１に対するオペレータ介入メッセージが表示され
ている。この状態で、ゲストクラスタ３２０−１が閉塞
し、ＡＶＭ３１０が全クラスタに閉塞状態の旨を通知
し、通知を受けたクラスタ２００、４００、３２０−
２、３２０−３では、閉塞による制御契機であり、対象
ゲストクラスタ３２０−１に対して、オペレータメッセ
ージが表示されている場合には、当該メッセージを消去
する。

【０２７９】なお、クラスタ３００のゲストクラスタ３
２０−１に対する制御が失敗し、かつ、クラスタ４００
がＡＶＭ運用され、ゲストクラスタ４２０−１でもダウ
ンし、やはり制御が失敗した状態となった場合には、他
の生存中のクラスタ２００の表示装置には、２つのオペ
レータ介入メッセージが表示される。このとき、クラス
タ２００のＯＳは、クラスタ３００のＡＶＭにダウンが
発生した場合には、ＳＳＵ１００のダウンクラスタ管理
フィールド１３０から実クラスタ３００のゲストクラス
タの状態を管理する情報を取得する。さらに、クラスタ
３００の配下のゲストクラスタ内にオペレータ介入メッ
セージを出力しているゲストクラスタが存在するかを判
定し、存在する場合には、どのゲストクラスタに対する
オペレータ介入メッセージを表示しているかを判断す
る。ここで、オペレータ介入メッセージを表示していれ
ば、クラスタ３００の制御依頼を契機として、クラスタ
３００の配下のゲストクラスタに対して出力されている
オペレータ介入メッセージを消去する。

【０２８０】上記により、ホットスタンバイ処理部で
は、オペレータの介入を軽減してホットスタンバイ処理
が可能となる。なお、本発明は、上記の実施例に限定さ
れることなく、特許請求の範囲内で種々変更・応用が可
能である。

【０２８１】

【発明の効果】本発明は、複数のクラスタを共用メモリ
により結合するＳＣＭＰシステムにおいて、１つ以上の
クラスタが仮想計算機システムとして運用される時に、
従来は、１つの実クラスタ上の１つのゲストクラスタし
か稼働できなかったが、本発明によれば、複数のクラス
タにより負荷分散をして処理しなければならないような
大規模なシステムをより柔軟に構築することが可能とな
り、ＳＣＭＰシステムを構築することでき、複数のゲス
トクラスタが種々処理を実行することが可能となる。

【０２８２】また、本発明は、共用メモリを介して情報
交換を行うシステムにおいて、初期化状態の共用メモリ
を最初に起動させたクラスタが初期化する処理を行う場
合に、他のクラスタが同時に初期化処理を行わないよう
に排他制御することが可能であると共に、アクセスパス
の切断や再接続を与えずに、共用メモリの初期化処理の
競合による誤動作を防止する。

【０２８３】また、本発明は、１つ以上のクラスタに１
つ以上の仮想計算機により運用されているクラスタが共
用メモリに接続され、通信を行う場合に、複数のゲスト
クラスタを一意に特定できる。また、本発明は、各ゲス
トクラスタと共用メモリを接続する論理的なパスの状態
や、各クラスタ、ゲストクラスタの運用状態を知ること
が可能である。

【０２８４】また、本発明は、実計算機により運用され
るクラスタ、仮想計算機により運用されているクラスタ
間において、通信要求の送信時にどのゲストクラスタ、
どのクラスタに対して通信要求を発行するのかを特定す
ることが可能である。また、本発明は、仮想計算機によ
り運用されているクラスタのゲストクラスタの通信の割
り込み状態が各々異なっていても通信要求を確実にゲス
トクラスタに反映させることが可能である。

【０２８５】また、本発明は、複数のゲストクラスタで
共用メモリを共用した場合でもリセット要求の完了が発
行元に正しく認識できる。そのため、複数のゲストクラ
スタと実計算機のクラスタとで共用メモリを共用するシ
ステムにおいて、各ＯＳ間のホットスタンバイシステム
による切り替えが可能となる。

【０２８６】また、本発明は、ＡＶＭ運用されているク
ラスタ内で発生したダウンをＡＶＭから、共用メモリに
接続されている各クラスタに通知することにより、他の
クラスタよりダウンクラスタの制御を行うことが可能と
なる。また、本発明は、ＡＶＭ運用されているクラスタ
内で発生したダウンを他のクラスタから認識することが
できるため、自動的に認識した他のクラスタからダウン
クラスタを制御することが可能である。

【０２８７】また、本発明は、ＡＶＭ運用クラスタのＡ
ＶＭ自体がダウンした場合に、当該クラスタをリセット
しなけばならならいが、このとき、ＡＶＭ運用のクラス
タの配下の全てのゲストクラスタをダウン状態とするこ
とにより、他のクラスタからのタイマ監視による制御の
時間が短縮される。

【０２８８】また、各クラスタのハードウェアの運用情
報を登録しておき、他のＡＶＭ運用のクラスタからダウ
ンクラスタの制御を行う場合には、当該運用情報を参照
して、各々のクラスタに付設されているサービスプロセ
ッサに指示することにより、実クラスタのみならず、Ａ
ＶＭ運用されているクラスタであっても強制的なハード
ウェアによるリセットが可能となる。

【０２８９】また、配下のゲストクラスタのセッション
閉塞時にＡＶＭ自体でゲストクラスタのリセット等の制
御を行い、他のクラスタにセッション閉塞を通知するこ
とにより、他のクラスタに対する通知及びリセットのた
めの時間が短縮される。また、オペレータ介入メッセー
ジを当該介入処理が終了した時点で自動的に消去するこ
とにより、オペレータの介入を軽減し、ホットスタンバ
イを実現できる。

【０２９０】このように、本発明によれば、実計算機内
の２台以上の仮想計算機が共用メモリを介して複数計算
機システム間での通信が可能となることにより、種々の
通知やリセット等の制御が容易になる。

【図面の簡単な説明】

【図１】本発明の原理構成図である。

【図２】本発明の計算機システム（ＳＣＭＰシステム）
の構成図である。

【図３】本発明の第１の実施例の計算機システム（ＳＣ
ＭＰシステム）の構成図である。

【図４】本発明の第１の実施例の初期化の概要を説明す
るための図（その１）である。

【図５】本発明の第１の実施例の初期化の概要を説明す
るための図（その２）である。

【図６】本発明の第１の実施例の初期化処理におけるシ
ステム構成図である。

【図７】本発明の第１の実施例の初期化処理を説明する
ためのフローチャートである。

【図８】本発明の各要求コードを示す図である。

【図９】本発明の第１の実施例のＡＶＭに対する識別子
付与処理を説明するための図である。

【図１０】本発明の第１の実施例のゲストクラスタに対
して仮想計算機番号を付与する処理を説明するためのシ
ーケンスチャートである。

【図１１】本発明の第１の実施例の仮想計算機番号の参
照動作を説明するための図である。

【図１２】本発明の第１の実施例のあるクラスタから他
のクラスタへゲストクラスタの仮想計算機番号を通知す
る他の例を示す図である。

【図１３】本発明の第１の実施例の運用情報取得の概念
図である。

【図１４】本発明の第１の実施例の運用状態情報取得時
のシステム構成図である。

【図１５】本発明の第１の実施例のゲストクラスタ内の
構成を示す図である。

【図１６】本発明の第１の実施例の問い合わせ先のクラ
スタのパラメータ域の例を示す図である。

【図１７】本発明の第１の実施例の運用状態の問い合わ
せ動作を説明するためのシーケンスチャートである。

【図１８】本発明の第１の実施例のクラスタ間の通信処
理を説明するための図である。

【図１９】本発明の第１の実施例の計算機間の第１の通
信動作のシーケンスチャートである。

【図２０】本発明の第１の実施例の計算機間の第２の通
信動作のシーケンスチャートである。

【図２１】本発明の第１の実施例の通信割り込み処理の
第１の例を説明するための図である。

【図２２】本発明の第１の実施例の通信割り込み処理の
第１の例の動作シーケンスチャートである。

【図２３】本発明の第１の実施例の通信割り込み処理の
第２の例を説明するための図である。

【図２４】本発明の第１の実施例の通信割り込み処理の
第２の例の動作シーケンスチャートである。

【図２５】本発明の第１の実施例の通信割り込み処理の
第３の例を説明するための図である。

【図２６】本発明の第１の実施例の通信割り込み処理の
第３の通信動作シーケンスチャート（その１）である。

【図２７】本発明の第１の実施例の通信割り込み処理の
第３の通信動作シーケンスチャート（その２）である。

【図２８】本発明の第１の実施例の各割り込み発生事象
でみた場合の例を示す図である。

【図２９】本発明の第１の実施例のリセット処理を説明
するための図である。

【図３０】本発明の第１の実施例のリセット処理動作の
シーケンスチャートである。

【図３１】本発明の第１の実施例のリセット処理の発生
事象でみた場合の例を示す図である。

【図３２】本発明の第２の実施例のＡＶＭダウン時の処
理概要を示す図である。

【図３３】本発明の第２の実施例のダウン通知時におけ
る各クラスタの処理を示す図である。

【図３４】本発明の第２の実施例のＳＳＵのクラスタ制
御獲得フィールドの構成図である。

【図３５】本発明の第２の実施例のダウンの発生の通知
・認識動作を示すシーケンスチャートである。

【図３６】本発明の第２の実施例のダウンクラスタ制御
処理のフローチャートである。

【図３７】本発明の第２の実施例の他のクラスタからダ
ウンクラスタを認識する処理の概要を説明するための図
である。

【図３８】本発明の第２の実施例の他のクラスタのゲス
トクラスタのダウン認識動作のシーケンスチャートであ
る。

【図３９】本発明の第２の実施例のダウン通知を受信し
た際のダウンクラスタの制御動作を示すシーケンスチャ
ートである。

【図４０】本発明の第２の実施例のＡＶＭ運用クラスタ
において、ＡＶＭがダウンした場合の処理を説明するた
めの図である。

【図４１】本発明の第２の実施例のＡＶＭ運用クラスタ
のＩ／Ｏリセット処理を説明するための図である。

【図４２】本発明の第２の実施例の自実クラスタ制御時
の待ち制御処理を説明するための図である。

【図４３】本発明の第２の実施例のゲストクラスタのセ
ッション閉塞時の処理概要を説明するための図である。

【図４４】本発明の第２の実施例のゲストクラスタのセ
ッション閉塞時の処理における各クラスタの構成図であ
る。

【図４５】本発明の第２の実施例のオペレータ介入メッ
セージが出力されている状態を示す図である。

【図４６】本発明の第２の実施例のオペレータ介入抑止
時の状態を示す図である。

【図４７】従来の第１の計算機システムの構成例であ
る。

【図４８】従来の第２の計算機システムの構成例であ
る。

【図４９】従来のシステムを説明するための図である。

【図５０】従来の第３の計算機システムの構成例であ
る。

【図５１】従来の第３の計算機システムにおける通信シ
ステムを説明するための図である。

【図５２】従来の通信時における割り込み処理を説明す
るためのシーケンスチャートである。

【図５３】従来のシステム制御のリセット処理を説明す
るためのシーケンスチャートである。

【図５４】従来の問題点を説明するための図（その１）
である。

【図５５】従来の問題点を説明するための図（その２）
である。

【図５６】従来の問題点を説明するための図（その３）
である。

【符号の説明】

６０、６１、６２ アクセスパス ７１、７２ 論理パス １００ 共有メモリ（ＳＳＵ） １１０ 計算機番号用領域 １１１ 制御クラスタアドレス格納域 １１２ ＩＰＬ世代 １１３ 制御状態情報 １２０ クラスタ制御獲得フィールド １３０ ダウンクラスタ管理フィールド ２００，３００，４００，５００ クラスタ ２１０，３１０，４１０ ＡＶＭ、仮想計算機用制御手
段 ２１１，３１１，４１１ 通信送受信部 ２２０，３２０，４２０ ゲストクラスタ ２２１，４３１，５３１ 計算機間通信制御部 ２２２ パラメータ域 ２２３，３２３，４２３ タスク ２５０，４５０ ＯＳ ２５１，３５１，４５１ ダウン通知受信部 ２５２，３５２，４５２ ダウン認識部 ２５３，３５３，４５３ ダウンクラスタ制御部 ２５４，３５４，４５４ 資源回収処理部 ２５５，３５５，４５５ ホットスタンバイ処理部 ２４０，３４０，４４０，５４０ 実計算機制御部（ハ
ードウェア）、実計算機制御手段 ２９０，３９０ サービスプロセッサ ２９１，３９１，４９１ 表示装置 ３１５ 閉塞認識部（ＤＥＡＣＴ認識部） ３１６ 閉塞処理部（ＤＥＡＣＴ処理部） ３４１ パラメータ域 ４０１、５０１ ＯＳ ４２０ ＯＳ ４３０ ダウン通知部 ４４１ メモリ更新部 ４４２ 初期化監視部 ４４３ 停止監視部 ４４４ 仮想・実計算機判定部 ４４５ パス切断部 ４４６ 初期化部 ４４７ 制御部 ２２１１ パラメータ解析部 ２２１２ 仮想計算機間通信依頼部 ３１１０ ダウン認識処理部 ３１２０ ダウン通知処理部

───────────────────────────────────────────────────── フロントページの続き (72)発明者 平石 壽▲徳▼ 静岡県静岡市伝馬町16番地の３ 株式会社 富士通静岡エンジニアリング内 (72)発明者 斎藤 優 神奈川県川崎市中原区上小田中1015番地 富士通株式会社内 (72)発明者 下川 健一郎 神奈川県川崎市中原区上小田中1015番地 富士通株式会社内 (72)発明者 平岡 勝則 静岡県静岡市伝馬町16番地の３ 株式会社 富士通静岡エンジニアリング内 (72)発明者 堀崎 公史 静岡県静岡市伝馬町16番地の３ 株式会社 富士通静岡エンジニアリング内 (72)発明者 塚本 建一 静岡県静岡市伝馬町16番地の３ 株式会社 富士通静岡エンジニアリング内 (72)発明者 落合 由美 静岡県静岡市伝馬町16番地の３ 株式会社 富士通静岡エンジニアリング内

Claims (42)

【特許請求の範囲】
1. 【請求項１】 少なくとも１つの実計算機（以下、実ク
   ラスタと記す）と外部記憶装置である共用メモリとを結
   合する電子計算機システムにおいて、 実クラスタ及び仮想計算機運用された実クラスタ内の個
   々のゲストクラスタを制御するためのオペレーティング
   システム（以下、ＯＳと記す）を有する実クラスタまた
   は、仮想計算機システムを制御するためのＯＳ（以下、
   ＡＶＭと記す）を有する少なくとも１つの仮想計算機シ
   ステム（以下、ＡＶＭ運用のクラスタと記す）が前記共
   用メモリに接続されることを特徴とする共用メモリに結
   合される複数の計算機システム。
2. 【請求項２】 前記実クラスタ運用のＯＳまたは、前記
   ＡＶＭ運用されている実クラスタ内の個々のゲストクラ
   スタのＯＳは、 前記共用メモリ上の領域のロックを獲得するロック獲得
   手段を有する請求項１記載の共用メモリに結合される複
   数の計算機システム。
3. 【請求項３】 前記実クラスタのＯＳ及び前記ゲストク
   ラスタ内のＯＳは、前記ロック獲得手段によりロックを
   獲得している前記クラスタの前記ＯＳが停止しているこ
   とを検出する第１の停止監視手段と、 前記第１の停止監視手段により停止が検出されたクラス
   タと前記共用メモリとのアクセスパスを切断するパス切
   断手段と、 他のクラスタからのＩＰＬを契機として前記共用メモリ
   の初期化を行う初期化手段を有する請求項１及び２記載
   の電子計算機システム。
4. 【請求項４】 前記実クラスタのＯＳ及び前記ゲストク
   ラスタ内のＯＳは、 前記ロック獲得手段によりロックを獲得しているクラス
   タのＯＳが停止していることを検出する第２の停止監視
   手段と、 前記第２の停止監視手段により停止しているＯＳのクラ
   スタが実クラスタかＡＶＭ運用のクラスタのいずれであ
   るかを判定する仮想・実計算機確認手段と、 前記仮想・実計算機確認手段により、ＡＶＭ運用のクラ
   スタであると判定された場合に、前記ＡＶＭと前記共用
   メモリに初期化処理のためのアクセスを行ったＡＶＭ運
   用のクラスタの配下の仮想計算機であるゲストクラスタ
   との間の論理パスを切断する論理パス切断手段とを含む
   請求項３記載の共用メモリに結合される複数の計算機シ
   ステム。
5. 【請求項５】 前記ＡＶＭは、 前記ＡＶＭ運用のクラスタ及びゲストクラスタを識別す
   るための識別子を一意に付与する識別子付与手段と、 前記ゲストクラスタを含むクラスタ内のＯＳから要求が
   あった場合に、前記識別子付与手段で付与された前記識
   別子を自クラスタまたは他のクラスタに通知する識別子
   通知手段とを有する請求項１記載の共用メモリに結合さ
   れる複数の計算機システム。
6. 【請求項６】 前記ＯＳは、 送信先のクラスタが実クラスタであるかＡＶＭ運用のク
   ラスタであるかを識別する識別手段と、 前記識別手段により、ＡＶＭ運用のクラスタであると識
   別された場合には、該ＡＶＭ運用のクラスタに対して該
   ＡＶＭ運用のクラスタの送信先となっているゲストクラ
   スタのアドレス情報を要求し、送信先のアドレス情報と
   動作中の該ゲストクラスタの状態情報を取得する仮想計
   算機情報取得手段とを有する請求項１記載の共用メモリ
   に結合される複数の計算機システム。
7. 【請求項７】 前記ＡＶＭは、 他のクラスタから送信された通信要求が自クラスタ宛で
   あるか他クラスタ宛であるかを通信要求のアドレス情報
   を参照して判断し、他クラスタ宛であれば、該他クラス
   タに送信する通信要求振分手段と、 前記通信要求が自クラスタ宛である場合には、前記通信
   要求をキューイングするキューイング手段と、 自クラスタの前記送信先のゲストクラスタが通信を受け
   付けられる状態になった時点で、前記キューイング手段
   よりキューイングされていた通信要求情報を前記ゲスト
   クラスタに反映させる反映手段とを有する請求項１記載
   の共用メモリに結合される複数の計算機システム。
8. 【請求項８】 前記共用メモリは、 前記ＡＶＭが制御するゲストクラスタに対して通信要求
   の新規割り込みが発生した場合に、クラスタからの該通
   信要求をキューイングする共用メモリキューイング手段
   を有し、 前記ゲストクラスタ内のＯＳは、 前記ＡＶＭの前記キューイング手段に存在している通信
   要求を処理した後に、前記共用メモリキューイング手段
   に存在する前記通信要求を処理する手段を有する請求項
   ７記載の共用メモリに結合される複数の計算機システ
   ム。
9. 【請求項９】 前記ＡＶＭは、 前記キューイング手段より前記キューが溢れた場合に、
   前記通信要求の送信元に対してキュー溢れを通知するキ
   ュー溢れ通知手段を有する請求項７記載の電子計算機シ
   ステム。
10. 【請求項１０】 前記ＡＶＭは、 他のクラスタまたは、他のクラスタのゲストクラスタか
    ら発行されたリセット要求を受信するリセット要求受信
    手段と、 前記リセット要求受信手段により受信した前記リセット
    要求をリセット対象のゲストクラスタに対してリセット
    処理を起動するリセット手段と、 前記リセット手段の完了後に、前記リセット要求の発行
    元にリセット完了を通知するリセット完了通知手段と、 前記リセット手段が失敗した場合に、前記リセット要求
    の発行元にリセット失敗を通知するリセット失敗通知手
    段とを有する請求項１記載の共用メモリに結合される複
    数の計算機システム。
11. 【請求項１１】 前記リセット要求受信手段は、 あるクラスタからリセット要求を受信すると共に、他の
    実クラスタまたは他のＡＶＭ運用されたゲストクラスタ
    から発行されたリセット要求も受信する手段を有する請
    求項１０記載の共用メモリに結合される複数の計算機シ
    ステム。
12. 【請求項１２】 前記共有メモリに接続される少なくと
    も１つの実クラスタ、または／及び、仮想計算機である
    ゲストクラスタを仮想計算機システム（ＡＶＭ）運用す
    る少なくとも１つのＡＶＭ運用のクラスタを有する計算
    機システムにおいて、 前記ＡＶＭ自身で回復不可能な異常によりダウンした場
    合に、前記ＡＶＭ自身でダウンした旨を、前記共用メモ
    リを介して、前記共用メモリに接続される全てのクラス
    タに通知する自己通知手段と、 前記ＡＶＭの前記自己通知手段によりダウンした前記Ａ
    ＶＭから通知されたダウン情報を取得し、前記ＡＶＭの
    ダウンを認識する第１のダウン認識手段とを有する請求
    項１記載の共用メモリに結合される複数の計算機システ
    ム。
13. 【請求項１３】 前記共有メモリに接続される少なくと
    も１つの実計算機、または／及び、複数の配下の計算機
    を仮想運用する少なくとも１つの仮想計算機システムを
    有する計算機システムにおいて、 前記ＡＶＭ運用のクラスタの配下のゲストクラスタで発
    生した回復不可能な異常によるダウン状態を、前記共有
    メモリに接続される他の計算機のオペレーティングシス
    テム（以下、ＯＳと記す）により認識する第２のダウン
    認識手段と、 前記第２のダウン認識手段によりダウンした旨を通知す
    るダウン通知手段と、 前記ダウン通知手段により通知されるダウン状態の情報
    を受信するダウン状態受信手段とを有する請求項１記載
    の共用メモリに結合される複数の計算機システム。
14. 【請求項１４】 前記第２のダウン認識手段は、 前記ゲストクラスタがダウンした際に、前記ＡＶＭシス
    テムからタイマ監視を行って完了通知を待機し、所定の
    時間内に通知がない場合に、前記ＡＶＭシステムのダウ
    ン状態を認識するタイマ監視手段を含む請求項１３記載
    の共用メモリに結合される複数の計算機システム。
15. 【請求項１５】 前記第２のダウン認識手段は、 前記ＡＶＭのダウンを検出した場合に、前記ＡＶＭ運用
    のクラスタのダウンしていないゲストクラスタについて
    も強制的にダウン状態にするゲストダウン制御手段を含
    む請求項１２及び１３記載の共用メモリに結合される複
    数の計算機システム。
16. 【請求項１６】 前記共用メモリ上にクラスタ毎のハー
    ドウェア情報を登録するハードウェア情報登録手段と、 ダウンしているクラスタが、ＡＶＭ運用のクラスタであ
    る場合に、前記ハードウェア情報登録手段を参照して、
    ハードウェア機構において入出力のリセットが可能な状
    態情報が登録されている場合に、他のクラスタからダウ
    ンしているクラスタの入出力のリセットを行うダウンク
    ラスタ制御手段を有する請求項１２及び１３記載の共用
    メモリに結合される複数の計算機システム。
17. 【請求項１７】 前記共用メモリ内の、ダウン状態とな
    っているクラスタ（以下、ダウンクラスタと記す）の制
    御権を取得したクラスタの識別子を登録する制御クラス
    タ記憶手段と、 前記ＡＶＭ運用のクラスタがダウン状態となった場合
    に、所定時間、前記制御クラスタ記憶手段に前記制御権
    を取得したクラスタの識別子が登録されない場合に、ダ
    ウンしたＡＶＭ配下のゲストクラスタが制御を行う自ク
    ラスタ内ゲスト制御手段を有する請求項１３記載の共用
    メモリに結合される複数の計算機システム。
18. 【請求項１８】 前記ＡＶＭ運用のクラスタの配下のゲ
    ストクラスタがセッション閉塞状態時に、ＡＶＭ自体
    で、閉塞状態の該ゲストクラスタの制御を行うリセット
    手段と、 配下の前記ゲストクラスタのセッション閉塞状態を他の
    クラスタに通知するセッション閉塞通知手段を含む請求
    項１２記載の共用メモリに結合される複数の計算機シス
    テム。
19. 【請求項１９】 セッション閉塞状態の通知を受けたク
    ラスタが、ダウンしたクラスタの制御時にＡＶＭによる
    リセット処理が完了している場合には、前記共用メモリ
    に装備されているシステム制御機能であるＧＳＩＧＰ命
    令によるリセットを行わないリセット制御手段を含む請
    求項１２記載の共用メモリに結合される複数の計算機シ
    ステム。
20. 【請求項２０】 前記ダウンクラスタへの制御失敗時に
    表示されるオペレータ介入メッセージによる処理が終了
    した時点で、該オペレータ介入メッセージを消去する消
    去手段を含む請求項１６記載の共用メモリに結合される
    複数の計算機システム。
21. 【請求項２１】 前記消去手段は、 オペレータが、表示されている前記オペレータ介入メッ
    セージに応答した場合、ダウンしたクラスタが再度ＩＰ
    Ｌした場合、セッション閉塞の通知をゲストクラスタの
    ＯＳが認識した場合、または、ＡＶＭ運用中のクラスタ
    がダウンした場合を契機として、前記オペレータ介入メ
    ッセージを消去する請求項２０記載の共用メモリに結合
    される複数の計算機システム。
22. 【請求項２２】 少なくとも１つの実計算機（以下、実
    クラスタと記す）と外部記憶装置である共用メモリとを
    結合する電子計算機システムの制御方法において、 実クラスタ及び仮想計算機運用された実クラスタ内の個
    々のゲストクラスタを制御するためのオペレーティング
    システム（以下、ＯＳと記す）を有する実計算機また
    は、仮想計算機システムを制御するためのＯＳ（以下、
    ＡＶＭと記す）を有する少なくとも１つの仮想計算機
    （以下、ＡＶＭ運用のクラスタと記す）が前記共用メモ
    リに接続するステップと、 前記実クラスタ間または、前記仮想計算機システム間ま
    たは、その両者間で前記共用メモリを介して通信処理を
    行うステップからなることを特徴とする共用メモリに結
    合される複数の計算機システムの制御方法。
23. 【請求項２３】 前記実クラスタのＯＳ、前記ＡＶＭ運
    用のクラスタ内の個々のゲストクラスタのＯＳ、また
    は、前記ＡＶＭ運用のクラスタが、前記共用メモリにア
    クセスするステップと、 前記共用メモリ上の領域のロックを獲得するステップよ
    りなる請求項２２記載の共用メモリに結合される複数の
    計算機システムの制御方法。
24. 【請求項２４】 前記実クラスタのＯＳまたは、前記ゲ
    ストクラスタ内のＯＳが、前記共用メモリ上の領域のロ
    ックを獲得した際に、 ロックを獲得している前記クラスタの前記ＯＳが停止し
    た場合に、前記ＯＳの停止を検出するステップと、 停止が検出されたクラスタと前記共用メモリとのアクセ
    スパスを切断するステップと、 他のクラスタからのＩＰＬを契機として前記共用メモリ
    の初期化を行うステップよりなる請求項２３記載の共用
    メモリに結合される複数の計算機システムの制御方法。
25. 【請求項２５】 ロックを獲得しているクラスタの前記
    ＯＳが停止していることを検出するステップと、 停止している前記ＯＳが実クラスタか、またはＡＶＭ運
    用されるクラスタのいずれのＯＳかを判定するステップ
    と、 ＡＶＭ運用されるクラスタであると判定された場合に、
    前記共用メモリに初期化処理のためのアクセスを行った
    仮想計算機との間の論理パスを切断するステップからな
    る請求項２４記載の共用メモリに結合される複数の計算
    機システムの制御方法。
26. 【請求項２６】 前記ＡＶＭ運用されるクラスタの配下
    のゲストクラスタを識別するための識別子を付与するス
    テップと、 前記ゲストクラスタを含むクラスタ内のＯＳから要求が
    あった場合に、付与された前記識別子を自クラスタまた
    は他のクラスタに通知するステップよりなる請求項２２
    記載の共用メモリに結合される複数の計算機システムの
    制御方法。
27. 【請求項２７】 送信先のクラスタが実クラスタである
    かＡＶＭ運用されるクラスタであるかを識別するステッ
    プと、 ＡＶＭ運用のクラスタであると識別された場合には、該
    第２のクラスタに対して該ＡＶＭ運用の第２のクラスタ
    の送信先の仮想計算機のアドレス情報を要求するステッ
    プと、 送信先のアドレス情報と動作中の該仮想計算機の状態情
    報を取得するステップよりなる請求項２２記載の共用メ
    モリに結合される複数の計算機システムの制御方法。
28. 【請求項２８】 他のクラスタから送信された通信要求
    が自クラスタ宛であるか他クラスタ宛であるかを通信要
    求のアドレス情報を参照して判断し、他クラスタ宛であ
    れば、該他クラスタに送信するステップと、 前記通信要求が自クラスタ宛である場合には、前記通信
    要求をキューイングするステップと、 自クラスタの前記送信先の仮想計算機が通信を受け付け
    られる状態になった時点で、キューイングされていた通
    信要求情報を前記仮想計算機に反映させるステップから
    なる２７記載の共用メモリに結合される複数の計算機シ
    ステムの制御方法。
29. 【請求項２９】 前記共用メモリが、前記ＡＶＭ運用の
    クラスタに対して通信要求の新規割り込みが発生した場
    合に、クラスタからの通信要求をキューイングするステ
    ップと、 前記ＡＶＭ運用のクラスタがキューイングによるキュー
    待ち行列に存在している通信要求を順次処理するステッ
    プよりなる請求項２８記載の共用メモリに結合される複
    数の計算機システムの制御方法。
30. 【請求項３０】 前記ＡＶＭ運用されるクラスタにおい
    て、前記キューが溢れた場合に、前記通信要求の送信元
    に対してキュー溢れを通知する請求項２８記載の共用メ
    モリに結合される複数の計算機システムの制御方法。
31. 【請求項３１】 前記ＡＶＭ運用されるクラスタが他の
    実クラスタまたは、他のＡＶＭ運用されているクラスタ
    の配下のゲストクラスタから発行されたリセット要求を
    受信するステップと、 受信した前記リセット要求をリセット対象の仮想計算機
    に対してリセット処理起動するステップと、 前リセット処理起動の完了後に、前記リセット要求の発
    行元にリセット完了を通知するステップと、 リセット処理が失敗した場合に、前記リセット要求の発
    行元にリセット失敗を通知するステップからなる請求項
    ２２記載の共用メモリに結合される複数の計算機システ
    ムの制御方法。
32. 【請求項３２】 前記リセット要求受信時に、あるクラ
    スタからリセット要求を受信すると共に、他のクラスタ
    から発行されたリセット要求も受信する請求項３１記載
    の共用メモリに結合される複数の計算機システムの制御
    方法。
33. 【請求項３３】 少なくとも１つの実計算機（以下、実
    クラスタと記す）と外部記憶装置である共用メモリとを
    結合する電子計算機システムの制御方法において、 前記ＡＶＭ運用のクラスタのＡＶＭ自身で回復不可能な
    異常によりダウンした場合に、該ＡＶＭ自身でダウンし
    た旨を、前記共用メモリを介して、前記共用メモリに接
    続される全ての計算機に通知するステップと、 ダウンした前記ＡＶＭ運用のクラスタから通知されたダ
    ウン情報を取得し、前記ダウンしたクラスタを認識する
    請求項２２記載の共用メモリに結合される複数の計算機
    システムの制御方法。
34. 【請求項３４】 少なくとも１つの実計算機（以下、実
    クラスタと記す）と外部記憶装置である共用メモリとを
    結合する電子計算機システムの制御方法において、 前記ＡＶＭ運用のクラスタの配下のゲストクラスタで発
    生した回復不可能な異常によるダウン状態を、前記共有
    メモリに接続される他のクラスタのＯＳにより認識する
    請求項２２記載の共用メモリに結合される複数の計算機
    システムの制御方法。
35. 【請求項３５】 前記ＡＶＭ運用のクラスタの配下のゲ
    ストクラスタがダウンした際に、該ＡＶＭからタイマ監
    視を行って完了通知を待機し、所定の時間内に通知がな
    い場合に、前記ＡＶＭのダウン状態を認識する請求項３
    ４記載の共用メモリに結合される複数の計算機システム
    の制御方法。
36. 【請求項３６】 前記ＡＶＭ運用のクラスタのダウンを
    検出した場合に、前記ＡＶＭ運用のゲストクラスタのダ
    ウンしていないゲストクラスタについても強制的にダウ
    ン状態にする請求項３３及び３４記載の共用メモリに結
    合される複数の計算機システムの制御方法。
37. 【請求項３７】 前記共用メモリ上にクラスタ毎のハー
    ドウェア情報を登録するステップと、 ダウンしているクラスタが、ＡＶＭ運用のゲストクラス
    タである場合に、登録されている前記ハードウェア情報
    を参照して、ハードウェア機構において入出力のリセッ
    トが可能な状態情報が登録されている場合に、他のクラ
    スタからダウンしているクラスタの入出力のリセットを
    行うステップからなる請求項３３及び３４記載の共用メ
    モリに結合される複数の計算機システムの制御方法。
38. 【請求項３８】 前記共用メモリ内の、ダウン状態とな
    っているクラスタ（以下、ダウンクラスタと記す）の制
    御権を取得したクラスタの識別子を登録するステップ
    と、 前記ＡＶＭ運用のクラスタがダウン状態となった場合
    に、所定時間内に前記共用メモリ内に前記制御権を取得
    したクラスタの識別子が登録されない場合に、ダウンし
    たＡＶＭ配下のゲストクラスタのＯＳが制御を行うステ
    ップよりなる請求項３４記載の共用メモリに結合される
    複数の計算機システムの制御方法。
39. 【請求項３９】 前記ＡＶＭ運用のクラスタの配下のゲ
    ストクラスタがセッション閉塞状態時に、該ＡＶＭ自体
    で、閉塞状態のゲストクラスタの制御を行うステップ
    と、 前記ＡＶＭが配下のゲストクラスタのセッション閉塞状
    態を他のクラスタに通知するステップよりなる請求項３
    ３記載の共用メモリに結合される複数の計算機システム
    の制御方法。
40. 【請求項４０】 セッション閉塞状態の通知を受けたク
    ラスタがダウンしたクラスタの制御時にクラスタ間の通
    信・制御を行うためのＧＳＩＧＰ命令によるリセットを
    行わない請求項３３記載の共用メモリに結合される複数
    の計算機システムの制御方法。
41. 【請求項４１】 前記ダウンクラスタへの制御失敗時に
    表示されるオペレータ介入メッセージによる処理が終了
    した時点で、該オペレータ介入メッセージを消去する請
    求項３７記載の共用メモリに結合される複数の計算機シ
    ステムの制御方法。
42. 【請求項４２】 前記オペレータメッセージを消去する
    際に、オペレータが表示されている前記オペレータ介入
    メッセージに応答した場合、ダウンしたクラスタが再度
    ＩＰＬし、セッション閉塞の通知をゲストクラスタのＯ
    Ｓが認識した場合に、ＡＶＭ運用中の実クラスタのダウ
    ンを契機として、前記オペレータ介入メッセージを消去
    する請求項４１記載の共用メモリに結合される複数の計
    算機システムの制御方法。