障害によるリブートを考慮した処理部間の不整合検出方法並びに共有装置及びクラスタシステム
【課題】ホストにおいて電文識別子を管理させることなく、且つ、各処理毎に電文識別子を変化させる必要がない方法で、リブートに伴う処理部間での不整合を検出する。
【解決手段】第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置において、前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを前記第１の処理部のブート及びリブートの回数を照らし合わせることにより判断する。
【解決手段】第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置において、前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを前記第１の処理部のブート及びリブートの回数を照らし合わせることにより判断する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の処理部を含む装置における処理部間の不整合検出に関する。
【背景技術】
【０００２】
メインフレーム等の大型コンピュータシステムにおいて、スケーラビリティや可用性の向上のために複数のホストを互いに結合したクラスタシステムが用いられている。
【０００３】
クラスタシステムではホスト同士がデータをやり取りしながら処理を行うが、このためのホスト間通信を複数のホストとインタフェースを持つ共有装置を介してホスト同士がメッセージ通信を行うことによって実現する方法がある。
【０００４】
この際に使用される共有装置は内部に複数の処理部と、処理部が共有する記憶部を備えている。そして、ここでのメッセージ通信機能とは、ホストからメッセージ送信要求を受け取った処理部が他方の処理部にリクエストを出し、リクエストを受け取った処理部がホストにメッセージを送信。送信に成功すると、元の処理部にリプライを返し、リプライを受け取った処理部が要求元のホストにリプライを返すというものである。
【０００５】
ここで、ホストから要求を受け取った処理部が他方の処理部にリクエストを出した直後に障害でリブートし、リブート後にホストから異なる送信要求を受け取った場合について考える。この場合、他方の処理部に本要求に対するリクエストを出した後に、すれ違いで、他方の処理部から前のリクエストに対するリプライが返されると、本リプライを後のリクエストに対するリプライと誤認するという問題があった。
【０００６】
このような問題を解消する方法として、例えば特許文献１に記載の技術を用いることが考えられる。特許文献１に記載に記載の技術では、処理要求毎に電文識別子を加え、この電文識別子を参照することにより、各処理を識別することが可能である。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００３−０８５０６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述したように、特許文献１に記載の技術等を用いることにより各処理を識別することが可能となる。
【０００９】
しかしながら、特許文献１に記載の技術等では、各処理毎に電文識別子を変化させる必要があり、電文識別子の付与及び確認に伴う処理が煩雑になるという問題があった。
【００１０】
また、特許文献１に記載の技術等は、ホストたる各サーバが電文識別子を管理する必要があるという問題があった。加えて、特許文献１に記載の技術等は、共有装置の処理部のリブートを考慮したものではなく、リブートが生じたタイミングによっては処理部間ですれ違いによる不整合が発生してしまうという課題を直接解決するものではなかった。
【００１１】
そこで、本実施形態では、ホストにおいて電文識別子を管理させることなく、且つ、各処理毎に電文識別子を変化させる必要がない方法で、リブートに伴う処理部間での不整合を検出することが可能な、障害によるリブートを考慮した処理部間の不整合検出方法並びに共有装置及びクラスタシステムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の第１の観点によれば、第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置において、前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする共有装置が提供される。
【００１３】
本発明の第２の観点によれば、第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置が行う不整合検出方法において、前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする不整合検出方法が提供される。
【発明の効果】
【００１４】
本発明によれば、共有装置内のブートカウンタエリアの値を要因とすることによりリブートが発生してもリクエストとリプライの対応づけをすることが出来ることから、ホストにおいて電文識別子を管理させることなく、且つ、各処理毎に電文識別子を変化させる必要がない方法で、リブートに伴う処理部間での不整合を検出することが可能となる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施形態の基本的構成を表す図である。
【図２】本発明の実施形態におけるブート回数登録部の基本的動作を表すフローチャートである。
【図３】本発明の実施形態におけるホスト要求処理部の基本的動作を表すフローチャートである。
【図４】本発明の実施形態における他処理部要求部の基本的動作を表すフローチャートである。
【図５】本発明の実施形態における他処理部リプライ処理部の基本的動作を表すフローチャートである。
【発明を実施するための形態】
【００１６】
次に、本発明の実施形態について図面を用いて詳細に説明する。
【００１７】
図１を参照すると、本実施形態は、共有装置１０００と第１のホスト２０００と第２のホスト３０００とを有している。
【００１８】
そして、本実施形態においては、第１のホスト２０００と第２のホスト３０００が、共有装置１０００を介して相互にデータをやり取りしながら処理を行う。なお、やり取りされるデータはどのような規格やプロトコルに準拠したものであってもよい。本実施形態は、任意の通信方式に準拠して実装することが可能である。
【００１９】
共有装置１０００は、記憶部１１０と第１の処理部１２０と第２の処理部１３０とを有している。
【００２０】
また、第１の処理部１２０は、第１のホスト２０００とは直接接続されているが第２のホスト３０００とは直接接続されていない。同様に、第２の処理部１３０は、第２のホスト３０００とは直接接続されているが第１のホスト２０００とは直接接続されていない。なお、各ホストとの接続は任意の方式により行うことが可能であり、接続方式に特に制限は無い。
【００２１】
記憶部１１０は、記憶装置であり、その用途に応じて複数の領域を有している。具体的には、記憶部１１０は、ブートカウンタ領域、リクエスト領域、リプライ領域及び通信データ領域を有している。そして、これらの各領域は処理部毎に１つずつ用意されている。そのため、本実施形態では、第１の処理部１２０用の領域として、第１のブートカウンタ領域１１１、第１のリクエスト領域１１３、第１のリプライ領域１１５及び第１の通信データ領域１１７を有している。加えて、第２の処理部１３０用の領域として、第２のブートカウンタ領域１１２、第２のリクエスト領域１１４、第２のリプライ領域１１６、及び第２の通信データ領域１１８を有している。
【００２２】
これらの各領域の具体的用途に関しては後述する。
【００２３】
第１の処理部１２０及び第２の処理部１３０は、ローカルメモリ（以下の説明及び図中においては、適宜「ＬＭ」と呼ぶ。）１２１及び１３１を有している。
【００２４】
また、第１の処理部１２０及び第２の処理部１３０は、それぞれ、ブート回数登録部１２２及び１３２と、ホスト要求処理部１２３及び１３３と、他処理部要求処理部１２４及び１３４と、他処理部リプライ処理部１２５及び１３５を有する。
【００２５】
ブート回数登録部１２２及び１３２は、第１の処理部１２０及び第２の処理部１３０のブート時と、リブート時に記憶部１１０のブートカウンタ領域にインクリメントしたブート回数を登録する機能を有する。
【００２６】
ホスト要求処理部１２３及び１３３は、自身が接続されているホストから送信要求を受け取った際に、他の処理部に要求を出す機能を有する。
【００２７】
他処理部要求処理部１２４及び１３４は、他処理部のホスト要求処理部から要求を受け取った際に、自身が接続されているホストにメッセージを送信し、送信成功後に要求元のホスト要求処理部に応答（以下、適宜「リプライ」と呼ぶ）を返す機能を有する。
【００２８】
他処理部リプライ処理部１２５及び１３５は、他処理部の他処理部要求処理部からリプライを受け取った際に自身が接続されているホストにリプライを返す機能を有する。
【００２９】
次に、図２乃至図５のフローチャートを参照して本実施形態の有する各部の動作について詳細に説明する。
【００３０】
図２は、ブート回数登録部１２２及び１３２の動作を表すフローチャートである。ブート回数登録部１２２及び１３２は自身が含まれている処理部がブートする際及びリブートする際に動作を行う。
【００３１】
図２を参照すると、ブート時及びリブート時に、ブート回数登録部１２２及び１３２は、記憶部１１０内の自処理部に割り当てられているブートカウンタ領域の値を読み出す（ステップＡ１）。
【００３２】
次に、読み出した値とブートカウンタが取り得る最大値を比較する（ステップＡ２）。ステップＡ２における比較の結果、両値が等しければ（ステップＡ２においてＹｅｓ）ブートカウンタ領域に１を登録する（ステップＡ３）。すなわち、処理後のブートカウンタ値は「１」となる。
【００３３】
一方、ステップＡ２における比較の結果、両値が等しくなければ（ステップＡ２においてＮｏ）、現在のブートカウンタ領域の値に１を加算する（ステップＡ４）。すなわち、処理後のブートカウンタ値は「現在のブートカウンタ値＋１」となる。
【００３４】
以上で、ブート回数登録部１２２及び１３２の動作は終了する。
【００３５】
図３は、ホスト要求処理部１２３及び１３３の動作を表すフローチャートである。
【００３６】
図３を参照すると、ホスト要求処理部１２３及び１３３は、ホストからの通信要求を受信するまで待機をする（ステップＢ１においてＮｏ）。
【００３７】
通信要求を受信すると（ステップＢ１においてＹｅｓ）、受信した通信要求に付随する通信メッセージを、通信先ホストが接続されている処理部に割り当てられている通信データ領域に格納する（ステップＢ２）。
【００３８】
次に、記憶部１１０の自処理部に割り当てられているブートカウンタ領域の値を読み出し（ステップＢ３）、読み出した値を記憶部１１０の通信先ホストが接続されている処理部に割り当てられているリクエスト領域に格納する（ステップＢ４）。その後、再び、ステップＢ１に戻り、ホストからの通信要求を受信するまで待機をする。
【００３９】
図４は、他処理部要求処理部１２４及び１３４の動作を表すフローチャートである。
【００４０】
図４を参照すると、他処理部要求処理部１２４及び１３４は、記憶部１１０の自処理部に割り当てられているリクエスト領域の値の監視をする（ステップＣ１）。
【００４１】
そして、記憶部１１０の自処理部に割り当てられているリクエスト領域に０以外の値が書き込まれるまで待機をする（ステップＣ２においてＮｏ）。
【００４２】
０以外の値が書き込まれると（ステップＣ２においてＹｅｓ）、書き込まれた値を自処理部内のＬＭに一時保存する。また、ＬＭに書き込まれた値を一時保存するに伴いリクエスト領域を０でクリアする（ステップＣ３）。
【００４３】
次に、記憶部１１０の自処理部に割り当てられた通信データ領域に格納されている通信メッセージを読み出す（ステップＣ４）。
【００４４】
そして、自身に接続されているホストにステップＣ４において読み出した通信メッセージを送信し（ステップＣ５）、ホストからの応答（リプライ）を受信するまで待機をする（ステップＣ６においてＮｏ）。
【００４５】
そして、ホストからの応答を受信すると（ステップＣ６においてＹｅｓ）、リクエスト領域からＬＭに一時保存していた値を、リクエストの要求元の処理部に割り当てられている記憶部１１０のリプライ領域に格納する（ステップＣ７）その後、再びステップＣ１に戻り、リクエスト領域の値の監視をする。
【００４６】
図５は、他処理部リプライ処理部１２５及び１３５の動作を表すフローチャートである。
【００４７】
図５を参照すると、他処理部リプライ処理部１２５及び１３５は、記憶部１１０の自処理部に割り当てられているリプライ領域の値の監視をする（ステップＤ１）。
【００４８】
記憶部１１０の自処理部に割り当てられているリプライ領域に０以外の値が書き込まれるまで待機をする（ステップＤ２においてＮｏ）。
【００４９】
０以外の値が書き込まれると（ステップＣ２においてＹｅｓ）、書き込まれた値を自処理部内のＬＭに一時保存する。また、ＬＭに書き込まれた値を一時保存するに伴いリプライ領域を０でクリアする（ステップＤ３）。
【００５０】
次に、一時保存した値と記憶部１１０の自処理部に割り当てられているブートカウンタ領域の値を比較する（ステップＤ４）。ステップＤ４における比較の結果、両値が等しければ（ステップＤ４においてＹｅｓ）、自身に接続されているホストに通信完了を報告する（ステップＤ５）。そして、ステップＤ１に戻る。
【００５１】
一方、ステップＤ４における比較の結果、両値が等しくなければ（ステップＤ４においてＮｏ）、何もせずにステップＤ１に戻る。すなわち、この場合には自身に接続されているホストに通信完了は報告されないこととなる。
【００５２】
以上が本実施形態における各部の動作である。
【００５３】
次に、本実施形態の動作について、具体的な例を挙げて詳細に説明する。
【００５４】
今回の具体例では、第１のホスト２０００から第２のホスト３０００へのメッセージ通信を行う際に、処理の途中で、第１の処理部１２０が障害でリブートする、というケースを例に取って説明する。説明の為、このときの第１のブートカウンタ領域１１１の値は１であったと仮定する（ステップＳ４）。
【００５５】
第１のホスト２０００が第１の処理部１２０にメッセージ通信を要求する。すると、ホストからの通信要求を監視している第１の処理部１２０のホスト要求処理部１２３が要求の受信を認識する（ステップＢ１においてＹｅｓ）。
【００５６】
ホスト要求処理部１２３は受信した通信要求に付随する通信メッセージを通信先ホストに接続された処理部である第２の処理部１３０に割り当てられている、第２の通信データ領域１１８に格納する（ステップＢ２）。
【００５７】
次に、第２の処理部１３０にリクエストを出すために、第１のブートカウンタ領域１１１の値を読み出す（ステップＢ３）。そして、ステップＢ３において読み出した値を第２のリクエスト領域１１４に格納する（ステップＢ４）。
【００５８】
次に、自身に割り当てられている第２のリクエスト領域１１４を監視している第２の処理部１３０の他処理部要求部１３４は、第２のリクエスト領域１１４に０以外の値が書き込まれたことを確認する（ステップＣ２においてＹｅｓ）。
【００５９】
他処理部要求部１３４は、書き込まれた値をＬＭ１３１に一時保存し、第２のリクエスト領域１１４を０でクリアする（ステップＣ３）。
【００６０】
次に、第２の通信データ領域１１８に格納されている通信メッセージを読み出し（ステップＣ４）、第２のホスト３０００に当該通信メッセージを送信し（ステップＣ５）、第２のホスト３０００からの応答を待つ（ステップＣ６）。
【００６１】
そして、第２のホスト３０００からの応答を受信すると（ステップＣ６においてＹｅｓ）、第２のリクエスト領域１１４からＬＭ１３１に一時保存していた値を、第１のリプライ領域１１５に格納する（ステップＣ７）。
【００６２】
次に、自身に割り当てられている第１のリプライ領域１１５を監視している第１の処理部１２０の他処理部リプライ処理部１２５は第１のリプライ領域１１５に０以外の値が書き込まれたことを認識すると（ステップＤ２においてＹｅｓ）、書き込まれた値をＬＭ１２１に一時保存し、第１のリプライ領域１１５を０でクリアする（ステップＤ３）。
【００６３】
次に、ＬＭ１２１に一時保存した値と第１のブートカウンタ領域１１１の値を比較する（ステップＤ４）。ここで、通常は２つの値は等しくなるため（ステップＤ４においてＹｅｓ）、第１のホスト２０００に対して通信完了の応答を返す（ステップＤ５）。
【００６４】
ここで、第１の処理部１２０が、第２の処理部１３０にリクエストを出した直後にリブートしたとする。このとき、第１の処理部１２０は、リブート直後にブート回数登録部１２２によって、第１のブートカウンタ領域１１１の値が２に更新される（ステップＡ１、Ａ２においてＹｅｓ、Ａ３）。
【００６５】
この状態で、第２の処理部１３０からリプライを受け取ると、先の、ＬＭ１２１に一時保存した値と第１のブートカウンタ領域１１１の値を比較する処理（ステップＤ４）において、一時保存した値はリブート前の値の１だが、第１のブートカウンタ領域１１１の値はリブート後の２になっているため、比較は不一致となり（ステップＤ４においてＮｏ）、第１のホスト２０００に対して通信完了の応答は行われない。
【００６６】
以上説明した本発明の実施形態は、以下に示すような多くの効果を奏する。
【００６７】
第１の効果は、確実に処理部間の通信正常終了を確認出来ることである。
【００６８】
その理由はブートカウンタ領域の値を要因とすることによりリブートが発生してもリクエストとリプライの対応づけをすることが出来る為である。リクエストとリプライの対応にずれが生じるのはリブートが発生したときのみである。
【００６９】
第２の効果は、処理が軽いことである。
【００７０】
その理由はブート処理（リブート処理含む）で一度リクエスト要因であるブートカウンタ領域の値をインクリメントしたらその後、リブートが発生するまで値をインクリメントせずともよい為である。通信発行毎にリクエスト要因をインクリメントする方法と比較し、少ない処理で同等の効果を得ることが出来る。
【００７１】
なお、本発明の実施形態である共有装置は、ハードウェアにより実現することもできるが、コンピュータをその共有装置として機能させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００７２】
また、本発明の実施形態による不整合検出方法は、ハードウェアにより実現することもできるが、コンピュータにその方法を実行させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００７３】
また、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。
【００７４】
加えて、本実施形態は、一般的な技術と比べ下記の点で有利な効果を奏している。
【００７５】
一般的な技術では、処理要求毎に電文識別子を変化させている。しかし、本実施形態では識別子(ブート回数)を処理要求毎に変化させておらず異なる。すなわち、本実施形態では装置が(リ)ブートしたときのみインクリメントしており、識別子の更新を最小限に留めることで負荷を軽減させることが可能となるという効果を奏する。
【００７６】
また、一般的な技術では、例えば各ブートデバイスのブート回数に制限をかける為、ブート回数を利用している。それに対し、本実施形態では処理部間の通信のすれ違いを防止する為、ブート回数を利用できるという効果を奏する。
【００７７】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【００７８】
（付記１） 第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置において、
前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、
前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする共有装置。
【００７９】
（付記２） 付記１に記載の共有装置において、
前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第１のホストに対してリプライ処理を行い一致しなかった場合は当該リプライが正当なものでないと判断して当該リプライを廃棄することを特徴とする共有装置。
【００８０】
（付記３） 付記１又は２に記載の共有装置において、
前記第１の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第２の処理部は前記リクエストを受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第２の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記第１の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第２の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする共有装置。
【００８１】
（付記４） 付記１乃至３の何れか１に記載の共有装置において、
前記第１の処理部が第２の処理部としても動作し、前記第２の処理部が第１の処理部としても動作することを特徴とする共有装置。
【００８２】
（付記５） 第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第１のホスト及び前記第２のホストを含んだクラスタシステムにおいて、
前記第１のホスト及び前記第２のホストは前記共有装置を介して通信を行い、
前記共有装置は付記１乃至４の何れか１項に記載の共有装置であることを特徴とするクラスタシステム。
【００８３】
（付記６） 第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置が行う不整合検出方法において、
前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、
前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする不整合検出方法。
【００８４】
（付記７） 付記６に記載の不整合検出方法において、
前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第１のホストに対してリプライ処理を行い一致しなかった場合は当該リプライ正当なものでないと判断して当該リプライを廃棄することを特徴とする不整合検出方法。
【００８５】
（付記８） 付記６又は７に記載の不整合検出方法において、
前記第１の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第２の処理部は前記リクエスト受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第２の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記１の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第２の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする不整合検出方法。
【００８６】
（付記９） 付記６乃至８の何れか１に記載の不整合検出方法において、
前記第１の処理部が第２の処理部としても動作し、前記第２の処理部が第１の処理部としても動作することを特徴とする不整合検出方法。
【００８７】
（付記１０） 第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第１のホスト及び前記第２のホストを含んだクラスタシステムが行う不整合検出において、
前記第１のホスト及び前記第２のホストは前記共有装置を介して通信を行い、
前記共有装置は付記６乃至８の何れか１に記載の不整合検出方法を行うことを特徴とする不整合検出方法。
【産業上の利用可能性】
【００８８】
本発明は、メインフレーム等の大型コンピュータシステムにおける、複数のホストを接続したクラスタシステムでホスト間の通信に好適である。
【符号の説明】
【００８９】
１１０ 記憶部
１１１ 第１のブートカウンタ領域
１１２ 第２のブートカウンタ領域
１１３ 第１のリクエスト領域
１１４ 第２のリクエスト領域
１１５ 第１のリプライ領域
１１６ 第２のリプライ領域
１１７ 第１の通信データ領域
１１８ 第２の通信データ領域
１２０ 第１の処理部
１２１、１３１ ローカルメモリ
１２２、１３２ ブート回数登録部
１２３、１３３ ホスト要求処理部
１２４、１３４ 他処理部要求処理部
１２５、１３５ 他処理部リプライ処理部
１３０ 第２の処理部
１０００ 共有装置
２０００ 第１のホスト
３０００ 第２のホスト
【技術分野】
【０００１】
本発明は、複数の処理部を含む装置における処理部間の不整合検出に関する。
【背景技術】
【０００２】
メインフレーム等の大型コンピュータシステムにおいて、スケーラビリティや可用性の向上のために複数のホストを互いに結合したクラスタシステムが用いられている。
【０００３】
クラスタシステムではホスト同士がデータをやり取りしながら処理を行うが、このためのホスト間通信を複数のホストとインタフェースを持つ共有装置を介してホスト同士がメッセージ通信を行うことによって実現する方法がある。
【０００４】
この際に使用される共有装置は内部に複数の処理部と、処理部が共有する記憶部を備えている。そして、ここでのメッセージ通信機能とは、ホストからメッセージ送信要求を受け取った処理部が他方の処理部にリクエストを出し、リクエストを受け取った処理部がホストにメッセージを送信。送信に成功すると、元の処理部にリプライを返し、リプライを受け取った処理部が要求元のホストにリプライを返すというものである。
【０００５】
ここで、ホストから要求を受け取った処理部が他方の処理部にリクエストを出した直後に障害でリブートし、リブート後にホストから異なる送信要求を受け取った場合について考える。この場合、他方の処理部に本要求に対するリクエストを出した後に、すれ違いで、他方の処理部から前のリクエストに対するリプライが返されると、本リプライを後のリクエストに対するリプライと誤認するという問題があった。
【０００６】
このような問題を解消する方法として、例えば特許文献１に記載の技術を用いることが考えられる。特許文献１に記載に記載の技術では、処理要求毎に電文識別子を加え、この電文識別子を参照することにより、各処理を識別することが可能である。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００３−０８５０６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述したように、特許文献１に記載の技術等を用いることにより各処理を識別することが可能となる。
【０００９】
しかしながら、特許文献１に記載の技術等では、各処理毎に電文識別子を変化させる必要があり、電文識別子の付与及び確認に伴う処理が煩雑になるという問題があった。
【００１０】
また、特許文献１に記載の技術等は、ホストたる各サーバが電文識別子を管理する必要があるという問題があった。加えて、特許文献１に記載の技術等は、共有装置の処理部のリブートを考慮したものではなく、リブートが生じたタイミングによっては処理部間ですれ違いによる不整合が発生してしまうという課題を直接解決するものではなかった。
【００１１】
そこで、本実施形態では、ホストにおいて電文識別子を管理させることなく、且つ、各処理毎に電文識別子を変化させる必要がない方法で、リブートに伴う処理部間での不整合を検出することが可能な、障害によるリブートを考慮した処理部間の不整合検出方法並びに共有装置及びクラスタシステムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の第１の観点によれば、第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置において、前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする共有装置が提供される。
【００１３】
本発明の第２の観点によれば、第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置が行う不整合検出方法において、前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする不整合検出方法が提供される。
【発明の効果】
【００１４】
本発明によれば、共有装置内のブートカウンタエリアの値を要因とすることによりリブートが発生してもリクエストとリプライの対応づけをすることが出来ることから、ホストにおいて電文識別子を管理させることなく、且つ、各処理毎に電文識別子を変化させる必要がない方法で、リブートに伴う処理部間での不整合を検出することが可能となる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施形態の基本的構成を表す図である。
【図２】本発明の実施形態におけるブート回数登録部の基本的動作を表すフローチャートである。
【図３】本発明の実施形態におけるホスト要求処理部の基本的動作を表すフローチャートである。
【図４】本発明の実施形態における他処理部要求部の基本的動作を表すフローチャートである。
【図５】本発明の実施形態における他処理部リプライ処理部の基本的動作を表すフローチャートである。
【発明を実施するための形態】
【００１６】
次に、本発明の実施形態について図面を用いて詳細に説明する。
【００１７】
図１を参照すると、本実施形態は、共有装置１０００と第１のホスト２０００と第２のホスト３０００とを有している。
【００１８】
そして、本実施形態においては、第１のホスト２０００と第２のホスト３０００が、共有装置１０００を介して相互にデータをやり取りしながら処理を行う。なお、やり取りされるデータはどのような規格やプロトコルに準拠したものであってもよい。本実施形態は、任意の通信方式に準拠して実装することが可能である。
【００１９】
共有装置１０００は、記憶部１１０と第１の処理部１２０と第２の処理部１３０とを有している。
【００２０】
また、第１の処理部１２０は、第１のホスト２０００とは直接接続されているが第２のホスト３０００とは直接接続されていない。同様に、第２の処理部１３０は、第２のホスト３０００とは直接接続されているが第１のホスト２０００とは直接接続されていない。なお、各ホストとの接続は任意の方式により行うことが可能であり、接続方式に特に制限は無い。
【００２１】
記憶部１１０は、記憶装置であり、その用途に応じて複数の領域を有している。具体的には、記憶部１１０は、ブートカウンタ領域、リクエスト領域、リプライ領域及び通信データ領域を有している。そして、これらの各領域は処理部毎に１つずつ用意されている。そのため、本実施形態では、第１の処理部１２０用の領域として、第１のブートカウンタ領域１１１、第１のリクエスト領域１１３、第１のリプライ領域１１５及び第１の通信データ領域１１７を有している。加えて、第２の処理部１３０用の領域として、第２のブートカウンタ領域１１２、第２のリクエスト領域１１４、第２のリプライ領域１１６、及び第２の通信データ領域１１８を有している。
【００２２】
これらの各領域の具体的用途に関しては後述する。
【００２３】
第１の処理部１２０及び第２の処理部１３０は、ローカルメモリ（以下の説明及び図中においては、適宜「ＬＭ」と呼ぶ。）１２１及び１３１を有している。
【００２４】
また、第１の処理部１２０及び第２の処理部１３０は、それぞれ、ブート回数登録部１２２及び１３２と、ホスト要求処理部１２３及び１３３と、他処理部要求処理部１２４及び１３４と、他処理部リプライ処理部１２５及び１３５を有する。
【００２５】
ブート回数登録部１２２及び１３２は、第１の処理部１２０及び第２の処理部１３０のブート時と、リブート時に記憶部１１０のブートカウンタ領域にインクリメントしたブート回数を登録する機能を有する。
【００２６】
ホスト要求処理部１２３及び１３３は、自身が接続されているホストから送信要求を受け取った際に、他の処理部に要求を出す機能を有する。
【００２７】
他処理部要求処理部１２４及び１３４は、他処理部のホスト要求処理部から要求を受け取った際に、自身が接続されているホストにメッセージを送信し、送信成功後に要求元のホスト要求処理部に応答（以下、適宜「リプライ」と呼ぶ）を返す機能を有する。
【００２８】
他処理部リプライ処理部１２５及び１３５は、他処理部の他処理部要求処理部からリプライを受け取った際に自身が接続されているホストにリプライを返す機能を有する。
【００２９】
次に、図２乃至図５のフローチャートを参照して本実施形態の有する各部の動作について詳細に説明する。
【００３０】
図２は、ブート回数登録部１２２及び１３２の動作を表すフローチャートである。ブート回数登録部１２２及び１３２は自身が含まれている処理部がブートする際及びリブートする際に動作を行う。
【００３１】
図２を参照すると、ブート時及びリブート時に、ブート回数登録部１２２及び１３２は、記憶部１１０内の自処理部に割り当てられているブートカウンタ領域の値を読み出す（ステップＡ１）。
【００３２】
次に、読み出した値とブートカウンタが取り得る最大値を比較する（ステップＡ２）。ステップＡ２における比較の結果、両値が等しければ（ステップＡ２においてＹｅｓ）ブートカウンタ領域に１を登録する（ステップＡ３）。すなわち、処理後のブートカウンタ値は「１」となる。
【００３３】
一方、ステップＡ２における比較の結果、両値が等しくなければ（ステップＡ２においてＮｏ）、現在のブートカウンタ領域の値に１を加算する（ステップＡ４）。すなわち、処理後のブートカウンタ値は「現在のブートカウンタ値＋１」となる。
【００３４】
以上で、ブート回数登録部１２２及び１３２の動作は終了する。
【００３５】
図３は、ホスト要求処理部１２３及び１３３の動作を表すフローチャートである。
【００３６】
図３を参照すると、ホスト要求処理部１２３及び１３３は、ホストからの通信要求を受信するまで待機をする（ステップＢ１においてＮｏ）。
【００３７】
通信要求を受信すると（ステップＢ１においてＹｅｓ）、受信した通信要求に付随する通信メッセージを、通信先ホストが接続されている処理部に割り当てられている通信データ領域に格納する（ステップＢ２）。
【００３８】
次に、記憶部１１０の自処理部に割り当てられているブートカウンタ領域の値を読み出し（ステップＢ３）、読み出した値を記憶部１１０の通信先ホストが接続されている処理部に割り当てられているリクエスト領域に格納する（ステップＢ４）。その後、再び、ステップＢ１に戻り、ホストからの通信要求を受信するまで待機をする。
【００３９】
図４は、他処理部要求処理部１２４及び１３４の動作を表すフローチャートである。
【００４０】
図４を参照すると、他処理部要求処理部１２４及び１３４は、記憶部１１０の自処理部に割り当てられているリクエスト領域の値の監視をする（ステップＣ１）。
【００４１】
そして、記憶部１１０の自処理部に割り当てられているリクエスト領域に０以外の値が書き込まれるまで待機をする（ステップＣ２においてＮｏ）。
【００４２】
０以外の値が書き込まれると（ステップＣ２においてＹｅｓ）、書き込まれた値を自処理部内のＬＭに一時保存する。また、ＬＭに書き込まれた値を一時保存するに伴いリクエスト領域を０でクリアする（ステップＣ３）。
【００４３】
次に、記憶部１１０の自処理部に割り当てられた通信データ領域に格納されている通信メッセージを読み出す（ステップＣ４）。
【００４４】
そして、自身に接続されているホストにステップＣ４において読み出した通信メッセージを送信し（ステップＣ５）、ホストからの応答（リプライ）を受信するまで待機をする（ステップＣ６においてＮｏ）。
【００４５】
そして、ホストからの応答を受信すると（ステップＣ６においてＹｅｓ）、リクエスト領域からＬＭに一時保存していた値を、リクエストの要求元の処理部に割り当てられている記憶部１１０のリプライ領域に格納する（ステップＣ７）その後、再びステップＣ１に戻り、リクエスト領域の値の監視をする。
【００４６】
図５は、他処理部リプライ処理部１２５及び１３５の動作を表すフローチャートである。
【００４７】
図５を参照すると、他処理部リプライ処理部１２５及び１３５は、記憶部１１０の自処理部に割り当てられているリプライ領域の値の監視をする（ステップＤ１）。
【００４８】
記憶部１１０の自処理部に割り当てられているリプライ領域に０以外の値が書き込まれるまで待機をする（ステップＤ２においてＮｏ）。
【００４９】
０以外の値が書き込まれると（ステップＣ２においてＹｅｓ）、書き込まれた値を自処理部内のＬＭに一時保存する。また、ＬＭに書き込まれた値を一時保存するに伴いリプライ領域を０でクリアする（ステップＤ３）。
【００５０】
次に、一時保存した値と記憶部１１０の自処理部に割り当てられているブートカウンタ領域の値を比較する（ステップＤ４）。ステップＤ４における比較の結果、両値が等しければ（ステップＤ４においてＹｅｓ）、自身に接続されているホストに通信完了を報告する（ステップＤ５）。そして、ステップＤ１に戻る。
【００５１】
一方、ステップＤ４における比較の結果、両値が等しくなければ（ステップＤ４においてＮｏ）、何もせずにステップＤ１に戻る。すなわち、この場合には自身に接続されているホストに通信完了は報告されないこととなる。
【００５２】
以上が本実施形態における各部の動作である。
【００５３】
次に、本実施形態の動作について、具体的な例を挙げて詳細に説明する。
【００５４】
今回の具体例では、第１のホスト２０００から第２のホスト３０００へのメッセージ通信を行う際に、処理の途中で、第１の処理部１２０が障害でリブートする、というケースを例に取って説明する。説明の為、このときの第１のブートカウンタ領域１１１の値は１であったと仮定する（ステップＳ４）。
【００５５】
第１のホスト２０００が第１の処理部１２０にメッセージ通信を要求する。すると、ホストからの通信要求を監視している第１の処理部１２０のホスト要求処理部１２３が要求の受信を認識する（ステップＢ１においてＹｅｓ）。
【００５６】
ホスト要求処理部１２３は受信した通信要求に付随する通信メッセージを通信先ホストに接続された処理部である第２の処理部１３０に割り当てられている、第２の通信データ領域１１８に格納する（ステップＢ２）。
【００５７】
次に、第２の処理部１３０にリクエストを出すために、第１のブートカウンタ領域１１１の値を読み出す（ステップＢ３）。そして、ステップＢ３において読み出した値を第２のリクエスト領域１１４に格納する（ステップＢ４）。
【００５８】
次に、自身に割り当てられている第２のリクエスト領域１１４を監視している第２の処理部１３０の他処理部要求部１３４は、第２のリクエスト領域１１４に０以外の値が書き込まれたことを確認する（ステップＣ２においてＹｅｓ）。
【００５９】
他処理部要求部１３４は、書き込まれた値をＬＭ１３１に一時保存し、第２のリクエスト領域１１４を０でクリアする（ステップＣ３）。
【００６０】
次に、第２の通信データ領域１１８に格納されている通信メッセージを読み出し（ステップＣ４）、第２のホスト３０００に当該通信メッセージを送信し（ステップＣ５）、第２のホスト３０００からの応答を待つ（ステップＣ６）。
【００６１】
そして、第２のホスト３０００からの応答を受信すると（ステップＣ６においてＹｅｓ）、第２のリクエスト領域１１４からＬＭ１３１に一時保存していた値を、第１のリプライ領域１１５に格納する（ステップＣ７）。
【００６２】
次に、自身に割り当てられている第１のリプライ領域１１５を監視している第１の処理部１２０の他処理部リプライ処理部１２５は第１のリプライ領域１１５に０以外の値が書き込まれたことを認識すると（ステップＤ２においてＹｅｓ）、書き込まれた値をＬＭ１２１に一時保存し、第１のリプライ領域１１５を０でクリアする（ステップＤ３）。
【００６３】
次に、ＬＭ１２１に一時保存した値と第１のブートカウンタ領域１１１の値を比較する（ステップＤ４）。ここで、通常は２つの値は等しくなるため（ステップＤ４においてＹｅｓ）、第１のホスト２０００に対して通信完了の応答を返す（ステップＤ５）。
【００６４】
ここで、第１の処理部１２０が、第２の処理部１３０にリクエストを出した直後にリブートしたとする。このとき、第１の処理部１２０は、リブート直後にブート回数登録部１２２によって、第１のブートカウンタ領域１１１の値が２に更新される（ステップＡ１、Ａ２においてＹｅｓ、Ａ３）。
【００６５】
この状態で、第２の処理部１３０からリプライを受け取ると、先の、ＬＭ１２１に一時保存した値と第１のブートカウンタ領域１１１の値を比較する処理（ステップＤ４）において、一時保存した値はリブート前の値の１だが、第１のブートカウンタ領域１１１の値はリブート後の２になっているため、比較は不一致となり（ステップＤ４においてＮｏ）、第１のホスト２０００に対して通信完了の応答は行われない。
【００６６】
以上説明した本発明の実施形態は、以下に示すような多くの効果を奏する。
【００６７】
第１の効果は、確実に処理部間の通信正常終了を確認出来ることである。
【００６８】
その理由はブートカウンタ領域の値を要因とすることによりリブートが発生してもリクエストとリプライの対応づけをすることが出来る為である。リクエストとリプライの対応にずれが生じるのはリブートが発生したときのみである。
【００６９】
第２の効果は、処理が軽いことである。
【００７０】
その理由はブート処理（リブート処理含む）で一度リクエスト要因であるブートカウンタ領域の値をインクリメントしたらその後、リブートが発生するまで値をインクリメントせずともよい為である。通信発行毎にリクエスト要因をインクリメントする方法と比較し、少ない処理で同等の効果を得ることが出来る。
【００７１】
なお、本発明の実施形態である共有装置は、ハードウェアにより実現することもできるが、コンピュータをその共有装置として機能させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００７２】
また、本発明の実施形態による不整合検出方法は、ハードウェアにより実現することもできるが、コンピュータにその方法を実行させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００７３】
また、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。
【００７４】
加えて、本実施形態は、一般的な技術と比べ下記の点で有利な効果を奏している。
【００７５】
一般的な技術では、処理要求毎に電文識別子を変化させている。しかし、本実施形態では識別子(ブート回数)を処理要求毎に変化させておらず異なる。すなわち、本実施形態では装置が(リ)ブートしたときのみインクリメントしており、識別子の更新を最小限に留めることで負荷を軽減させることが可能となるという効果を奏する。
【００７６】
また、一般的な技術では、例えば各ブートデバイスのブート回数に制限をかける為、ブート回数を利用している。それに対し、本実施形態では処理部間の通信のすれ違いを防止する為、ブート回数を利用できるという効果を奏する。
【００７７】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【００７８】
（付記１） 第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置において、
前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、
前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする共有装置。
【００７９】
（付記２） 付記１に記載の共有装置において、
前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第１のホストに対してリプライ処理を行い一致しなかった場合は当該リプライが正当なものでないと判断して当該リプライを廃棄することを特徴とする共有装置。
【００８０】
（付記３） 付記１又は２に記載の共有装置において、
前記第１の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第２の処理部は前記リクエストを受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第２の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記第１の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第２の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする共有装置。
【００８１】
（付記４） 付記１乃至３の何れか１に記載の共有装置において、
前記第１の処理部が第２の処理部としても動作し、前記第２の処理部が第１の処理部としても動作することを特徴とする共有装置。
【００８２】
（付記５） 第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第１のホスト及び前記第２のホストを含んだクラスタシステムにおいて、
前記第１のホスト及び前記第２のホストは前記共有装置を介して通信を行い、
前記共有装置は付記１乃至４の何れか１項に記載の共有装置であることを特徴とするクラスタシステム。
【００８３】
（付記６） 第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置が行う不整合検出方法において、
前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、
前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする不整合検出方法。
【００８４】
（付記７） 付記６に記載の不整合検出方法において、
前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第１のホストに対してリプライ処理を行い一致しなかった場合は当該リプライ正当なものでないと判断して当該リプライを廃棄することを特徴とする不整合検出方法。
【００８５】
（付記８） 付記６又は７に記載の不整合検出方法において、
前記第１の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第２の処理部は前記リクエスト受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第２の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記１の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第２の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする不整合検出方法。
【００８６】
（付記９） 付記６乃至８の何れか１に記載の不整合検出方法において、
前記第１の処理部が第２の処理部としても動作し、前記第２の処理部が第１の処理部としても動作することを特徴とする不整合検出方法。
【００８７】
（付記１０） 第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第１のホスト及び前記第２のホストを含んだクラスタシステムが行う不整合検出において、
前記第１のホスト及び前記第２のホストは前記共有装置を介して通信を行い、
前記共有装置は付記６乃至８の何れか１に記載の不整合検出方法を行うことを特徴とする不整合検出方法。
【産業上の利用可能性】
【００８８】
本発明は、メインフレーム等の大型コンピュータシステムにおける、複数のホストを接続したクラスタシステムでホスト間の通信に好適である。
【符号の説明】
【００８９】
１１０ 記憶部
１１１ 第１のブートカウンタ領域
１１２ 第２のブートカウンタ領域
１１３ 第１のリクエスト領域
１１４ 第２のリクエスト領域
１１５ 第１のリプライ領域
１１６ 第２のリプライ領域
１１７ 第１の通信データ領域
１１８ 第２の通信データ領域
１２０ 第１の処理部
１２１、１３１ ローカルメモリ
１２２、１３２ ブート回数登録部
１２３、１３３ ホスト要求処理部
１２４、１３４ 他処理部要求処理部
１２５、１３５ 他処理部リプライ処理部
１３０ 第２の処理部
１０００ 共有装置
２０００ 第１のホスト
３０００ 第２のホスト
【特許請求の範囲】
【請求項１】
第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置において、
前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、
前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする共有装置。
【請求項２】
請求項１に記載の共有装置において、
前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第１のホストに対してリプライ処理を行い一致しなかった場合は当該リプライが正当なものでないと判断して当該リプライを廃棄することを特徴とする共有装置。
【請求項３】
請求項１又は２に記載の共有装置において、
前記第１の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第２の処理部は前記リクエストを受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第２の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記第１の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第２の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする共有装置。
【請求項４】
請求項１乃至３の何れか１項に記載の共有装置において、
前記第１の処理部が第２の処理部としても動作し、前記第２の処理部が第１の処理部としても動作することを特徴とする共有装置。
【請求項５】
第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第１のホスト及び前記第２のホストを含んだクラスタシステムにおいて、
前記第１のホスト及び前記第２のホストは前記共有装置を介して通信を行い、
前記共有装置は請求項１乃至４の何れか１項に記載の共有装置であることを特徴とするクラスタシステム。
【請求項６】
第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置が行う不整合検出方法において、
前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、
前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする不整合検出方法。
【請求項７】
請求項６に記載の不整合検出方法において、
前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第１のホストに対してリプライ処理を行い一致しなかった場合は当該リプライが正当なものでないと判断して当該リプライを廃棄することを特徴とする不整合検出方法。
【請求項８】
請求項６又は７に記載の不整合検出方法において、
前記第１の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第２の処理部は前記リクエストを受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第２の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記第１の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第２の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする不整合検出方法。
【請求項９】
請求項６乃至８の何れか１項に記載の不整合検出方法において、
前記第１の処理部が第２の処理部としても動作し、前記第２の処理部が第１の処理部としても動作することを特徴とする不整合検出方法。
【請求項１０】
第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第１のホスト及び前記第２のホストを含んだクラスタシステムが行う不整合検出において、
前記第１のホスト及び前記第２のホストは前記共有装置を介して通信を行い、
前記共有装置は請求項６乃至８の何れか１項に記載の不整合検出方法を行うことを特徴とする不整合検出方法。
【請求項１】
第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置において、
前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、
前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする共有装置。
【請求項２】
請求項１に記載の共有装置において、
前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第１のホストに対してリプライ処理を行い一致しなかった場合は当該リプライが正当なものでないと判断して当該リプライを廃棄することを特徴とする共有装置。
【請求項３】
請求項１又は２に記載の共有装置において、
前記第１の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第２の処理部は前記リクエストを受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第２の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記第１の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第２の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする共有装置。
【請求項４】
請求項１乃至３の何れか１項に記載の共有装置において、
前記第１の処理部が第２の処理部としても動作し、前記第２の処理部が第１の処理部としても動作することを特徴とする共有装置。
【請求項５】
第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第１のホスト及び前記第２のホストを含んだクラスタシステムにおいて、
前記第１のホスト及び前記第２のホストは前記共有装置を介して通信を行い、
前記共有装置は請求項１乃至４の何れか１項に記載の共有装置であることを特徴とするクラスタシステム。
【請求項６】
第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置が行う不整合検出方法において、
前記第１の処理部が前記第１のホストからの第１のメッセージの送信要求を受け取ると、前記第２の処理部に対してリクエストを送信し、当該リクエストを受信した前記第２の処理部が前記メッセージを前記第２のホストに送信すると共にリプライを前記第１の処理部に送信し、前記リプライを受け取った第１の処理部は当該リプライが前記第１のメッセージの送信要求に応じたリプライであるか否かを判断し、
前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする不整合検出方法。
【請求項７】
請求項６に記載の不整合検出方法において、
前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第１の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第１のホストに対してリプライ処理を行い一致しなかった場合は当該リプライが正当なものでないと判断して当該リプライを廃棄することを特徴とする不整合検出方法。
【請求項８】
請求項６又は７に記載の不整合検出方法において、
前記第１の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第２の処理部は前記リクエストを受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第２の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記第１の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第２の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする不整合検出方法。
【請求項９】
請求項６乃至８の何れか１項に記載の不整合検出方法において、
前記第１の処理部が第２の処理部としても動作し、前記第２の処理部が第１の処理部としても動作することを特徴とする不整合検出方法。
【請求項１０】
第１のホストに接続される第１の処理部と、第２のホストに接続される第２の処理部と、前記第１の処理部及び第２の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第１のホスト及び前記第２のホストを含んだクラスタシステムが行う不整合検出において、
前記第１のホスト及び前記第２のホストは前記共有装置を介して通信を行い、
前記共有装置は請求項６乃至８の何れか１項に記載の不整合検出方法を行うことを特徴とする不整合検出方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１２−２２１１０１（Ｐ２０１２−２２１１０１Ａ）
【公開日】平成２４年１１月１２日（２０１２．１１．１２）
【国際特許分類】
【出願番号】特願２０１１−８４５５０（Ｐ２０１１−８４５５０）
【出願日】平成２３年４月６日（２０１１．４．６）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年１１月１２日（２０１２．１１．１２）
【国際特許分類】
【出願日】平成２３年４月６日（２０１１．４．６）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]