JP2016151965A - 冗長構成システム及び冗長構成制御方法 - Google Patents

Abstract

【課題】冗長構成を実現するための複数のサーバを接続するネットワークにおいて異常が発生したことを検出する。
【解決手段】冗長構成システムは、第１サーバＡ１及び第２サーバＢ１を含む第１情報処理システム＃１（拠点＃１）と、第１情報処理システムにネットワークで接続され、かつ、第３サーバＡ２及び第４サーバＢ２を含む第２情報処理システム＃２（拠点＃２）とを有する。第１のサーバＡ１は、状態通知を、ネットワークを介して第３サーバＡ２と交換する第１通知部を有する。第２サーバＢ１は、状態通知を、ネットワークを介して第４サーバＢ２と交換する第２通知部と、第２通知部が第４サーバＢ２と状態通知を交換できないことを検出した場合、第１通知部が状態通知を第３サーバＡ２と交換できているか否かを示す情報を第１通知部から取得し、第１通知部が状態通知を第３サーバＡ２と交換できているか判定する判定部とを有する。
【選択図】図１

Description

本発明は、冗長化技術に関する。

可用性を高めるためサーバを冗長化したシステムにおいては、処理を実行中のサーバが何らかの原因で停止した場合に、別のサーバが処理を実行する（すなわち、フェイルオーバーの処理を行う）ことで、常に処理が実行される状態が維持される。ここで、処理を実行中のサーバは稼働系のサーバと呼ばれ、処理を実行せずに待機するサーバは待機系のサーバと呼ばれる。

或る文献は、ネットワークに接続された複数のサーバからなるクラスタシステムを開示する。各サーバは、ハートビートパケットによって他のサーバが正常であるか否かを確認し、稼働系のサーバにおいて実行中のアプリケーションに異常が発生した場合、待機系のサーバにおいてアプリケーションを代わりに実行する。

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

冗長構成を実現するための複数のサーバは１つの拠点に設置されるとは限らず、複数の拠点に分散して設置される場合がある。このような場合、拠点と拠点とを接続するネットワークに異常が発生すると、サーバはハートビットパケットを交換することができなくなる。しかし、待機系のサーバは、ハートビートパケットを交換できない原因がネットワークと稼働系のサーバのいずれであるかを特定できず、フェイルオーバーの処理を実行すべきかわからない。上記の従来技術においては、このような問題には着目されていない。

従って、本発明の目的は、１つの側面では、冗長構成を実現するための複数のサーバを接続するネットワークにおいて異常が発生したことを検出するための技術を提供することである。

本発明に係る冗長構成システムは、第１の情報処理装置及び第２の情報処理装置を含む第１の情報処理システムと、第１の情報処理システムにネットワークを介して接続され且つ第３の情報処理装置及び第４の情報処理装置を含む第２の情報処理システムとを有する。そして、上で述べた第１の情報処理装置は、情報処理装置の状態を通知するためのパケットである状態通知を、ネットワークを介して第３の情報処理装置と交換する第１の通知部を有する。そして、第２の情報処理装置は、状態通知を、ネットワークを介して第４の情報処理装置と交換する第２の通知部と、第２の通知部が第４の情報処理装置と状態通知を交換できないことを検出した場合、第１の通知部が状態通知を第３情報処理装置と交換できているか否かを示す情報を第１の通知部から取得し、第１の通知部が状態通知を第３の情報処理装置と交換できているか判定する判定部とを有する。

１つの側面では、冗長構成を実現するための複数のサーバを接続するネットワークにおいて異常が発生したことを検出できるようになる。

図１は、本実施の形態におけるシステムの概要を示す図である。 図２は、サーバの機能ブロック図である。 図３は、状態テーブル格納部に格納される状態テーブルの一例を示す図である。 図４は、状態に関するデータを対向サーバと交換する処理の処理フローを示す図である。 図５は、サーバのアプリケーション状態特定部が実行する処理の処理フローを示す図である。 図６は、状態に関するデータを同一拠点内におけるサーバ間で交換する処理の処理フローを示す図である。 図７は、アプリケーション状態及びサーバ状態を監視する処理の処理フローを示す図である。 図８は、状態テーブルに格納されるデータの一例を示す図である。 図９は、状態テーブルに格納されるデータの一例を示す図である。 図１０は、アプリケーション状態及びサーバ状態を監視する処理の処理フローを示す図である。 図１１は、状態テーブルに格納されるデータの一例を示す図である。 図１２は、コンピュータの機能ブロック図である。

図１に、本実施の形態におけるシステムの概要を示す。図１の例では、ＷＡＮ（Wide Area Network）であるネットワーク５には、拠点＃１の中継装置１００と拠点＃２の中継装置２００とが接続される。中継装置１００及び２００は、例えば１台のネットワークスイッチ又はルータ等であるが、複数台のネットワークスイッチ又はルータを集約した中継装置であってもよい。

中継装置１００には、物理サーバであるサーバＡ１とサーバＢ１とサーバＣ１とが接続され、中継装置２００には、物理サーバであるサーバＡ２とサーバＢ２とサーバＣ２とが接続される。サーバＡ１及びＡ２はサーバグループＡに属し、一方が稼働系サーバになり、他方が待機系サーバになる。同様に、サーバＢ１及びＢ２はサーバグループＢに属し、一方が稼働系サーバになり、他方が待機系サーバになる。同様に、サーバＣ１及びＣ２はサーバグループＣに属し、一方が稼働系サーバになり、他方が待機系サーバになる。

図１における破線はハートビートパケットを表す。サーバＡ１は対向サーバであるサーバＡ２にハートビートパケットを送信し、サーバＡ２からハートビートパケットの応答を受信する。サーバＡ２も対向サーバであるサーバＡ１にハートビートパケットを送信し、サーバＡ１からハートビートパケットの応答を受信する。サーバＢ１は対向サーバであるサーバＢ２にハートビートパケットを送信し、サーバＢ２からハートビートパケットの応答を受信する。サーバＢ２も対向サーバであるサーバＢ１にハートビートパケットを送信し、サーバＢ１からハートビートパケットの応答を受信する。サーバＣ１は対向サーバであるサーバＣ２にハートビートパケットを送信し、サーバＣ２からハートビートパケットの応答を受信する。サーバＣ２も対向サーバであるサーバＣ１にハートビートパケットを送信し、サーバＣ１からハートビートパケットの応答を受信する。なお、対向サーバとは、同じグループに属する他のサーバである。

図２に、図１に示したサーバの機能ブロック図を示す。サーバは、ハートビート制御部３０１と、アプリケーション状態特定部３０３と、状態管理部３０５と、状態テーブル格納部３０７と、アプリケーション３０９とを含む。

ハートビート制御部３０１は、ハートビートパケットの送信及びハートビートパケットの応答の受信を行い、ハートビートパケットの応答を状態管理部３０５に出力する。アプリケーション状態特定部３０３は、アプリケーション３０９の状態を特定し、アプリケーション３０９の状態を示すデータを状態管理部３０５に出力する。状態管理部３０５は、ハートビート制御部３０１が受信した応答及びアプリケーション状態特定部３０３からの通知に基づき、状態テーブルを更新する。アプリケーション３０９は、サーバが提供するサービスに関連する処理を実行する。

図３に、状態テーブル格納部３０７における状態テーブルに格納されるデータの一例を示す。図３の例では、エントリの番号と、サーバの識別情報と、アプリケーション状態を示すデータと、ハートビート状態を示すデータと、更新時刻とが格納される。本実施の形態においては、アプリケーション状態は「ＡＣＴ」、「ＳＢＹ」、「ＵＮＫＮＯＷＮ」、「ＦＬＴ」又は「ＯＵＳ」のいずれかである。ＡＣＴは「稼働」を表し、ＳＢＹは「待機」を表し、ＵＮＫＮＯＷＮは「不明」を表し、ＦＬＴは「異常」を表し、ＯＵＳは「停止」を表す。ハートビート状態は「ＯＫ」、「ＮＧ」、「ＵＮＫＮＯＷＮ」又は「ＯＵＳ」のいずれかである。ＯＫは「正常」を表し、ＮＧは「失敗」を表し、ＵＮＫＮＯＷＮは「不明」を表し、ＯＵＳは「停止」を表す。

次に、図４乃至図１１を用いて、本実施の形態におけるサーバが実行する処理について説明する。はじめに、状態に関するデータを対向サーバと交換する処理について説明する。

まず、サーバのハートビート制御部３０１は、前回ハートビートパケットを送信してから所定時間（例えば数秒）が経過したか判断する（図４：ステップＳ１）。前回ハートビートパケットを送信してから所定時間が経過していない場合（ステップＳ１：Ｎｏルート）、ハートビートパケットを送信すべきタイミングではないので、ステップＳ１７の処理に移行する。

一方、前回ハートビートパケットを送信してから所定時間が経過した場合（ステップＳ１：Ｙｅｓルート）、ハートビート制御部３０１は、ハートビートパケットを対向サーバに送信し（ステップＳ３）、送信時刻をメモリに保存しておく。

ハートビート制御部３０１は、一定時間待機し（ステップＳ５）、ステップＳ３において送信したハートビートパケットに対する応答を対向サーバから受信したか判断する（ステップＳ７）。ハートビートパケットに対する応答は、対向サーバのアプリケーション状態を示すデータ及びハートビート状態を示すデータを含む。

ハートビートパケットに対する応答を受信した場合（ステップＳ７：Ｙｅｓルート）、ハートビート制御部３０１は、ハートビートパケットに対する応答を状態管理部３０５に出力する。これに応じ、状態管理部３０５は、応答の内容に従い、状態テーブルに格納された、対向サーバのアプリケーション状態を示すデータ及びハートビート状態を示すデータを更新する（ステップＳ９）。また、状態管理部３０５は、状態テーブルに格納された、自サーバのハートビート状態を示すデータを「ＯＫ」に設定する（ステップＳ１１）。そしてステップＳ１７の処理に移行する。

一方、ハートビートパケットに対する応答を受信していない場合（ステップＳ７：Ｎｏルート）、ハートビート制御部３０１は、ハートビートパケットに対する応答を受信していない旨を状態管理部３０５に通知する。これに応じ、状態管理部３０５は、状態テーブルに格納された、対向サーバのアプリケーション状態を示すデータ及び対向サーバのハートビート状態を示すデータを「ＵＮＫＮＯＷＮ」に設定する（ステップＳ１３）。また、状態管理部３０５は、状態テーブルに格納された、自サーバのハートビート状態を示すデータを「ＮＧ」に設定する（ステップＳ１５）。

ハートビート制御部３０１は、対向サーバからハートビートパケットを受信したか判断する（ステップＳ１７）。ハートビートパケットを受信していない場合（ステップＳ１７：Ｎｏルート）、ステップＳ１の処理に戻る。一方、ハートビートパケットを受信した場合（ステップＳ１７：Ｙｅｓルート）、状態管理部３０５は、状態テーブルに基づき、自サーバのアプリケーション状態及びハートビート状態を特定し（ステップＳ１９）、ハートビート制御部３０１に通知する。

ハートビート制御部３０１は、自サーバのアプリケーション状態を示すデータ及びハートビート状態を示すデータを含む応答を生成し、対向サーバに送信する（ステップＳ２１）。そしてステップＳ１の処理に戻る。

以上のような処理を実行すれば、各サーバは対向サーバのアプリケーション状態及びハートビート状態を確認できるようになる。

次に、図５を用いて、サーバのアプリケーション状態特定部３０３が実行する処理について説明する。

まず、サーバのアプリケーション状態特定部３０３は、前回アプリケーション状態を特定してから所定時間（例えば数秒）が経過したか判断する（図５：ステップＳ３１）。前回アプリケーション状態を特定してから所定時間が経過していない場合（ステップＳ３１：Ｎｏルート）、アプリケーション状態特定部３０３は、一定時間待機し（ステップＳ３７）、ステップＳ３１の処理に戻る。

一方、前回アプリケーション状態を特定してから所定時間が経過した場合（ステップＳ３１：Ｙｅｓルート）、アプリケーション状態特定部３０３は、自サーバのアプリケーション３０９の状態を特定し（ステップＳ３３）、特定時刻をメモリに保存しておく。

アプリケーション状態特定部３０３は、状態テーブルに格納された、自サーバのアプリケーション状態を示すデータを、ステップＳ３３の処理結果に基づき更新する（ステップＳ３５）。そしてステップＳ３１の処理に戻る。

以上のような処理を実行すれば、自サーバのアプリケーション状態を確認できるようになる。

次に、図６を用いて、状態に関するデータを同一拠点内におけるサーバ間で交換する処理について説明する。

まず、サーバの状態管理部３０５は、前回状態確認要求を送信してから所定時間（例えば数秒）が経過したか判断する（図６：ステップＳ４１）。前回状態確認要求を送信してから所定時間が経過していない場合（ステップＳ４１：Ｎｏルート）、ステップＳ４７の処理に移行する。

一方、前回状態確認要求を送信してから所定時間が経過した場合（ステップＳ４１：Ｙｅｓルート）、状態管理部３０５は、状態に関するデータを取得することを要求する状態確認要求を同一拠点内の他サーバに送信し（ステップＳ４３）、送信時刻をメモリに保存しておく。ここで、他サーバとは、同一拠点内におけるサーバのうち自サーバ以外の全サーバのことである。

状態管理部３０５は、ステップＳ４３において送信した状態確認要求に対する応答を、同一拠点内における他サーバの各々から受信し、応答の内容に従い状態テーブルを更新する（ステップＳ４５）。

状態管理部３０５は、同一拠点内における他サーバから状態確認要求を受信したか判断する（ステップＳ４７）。同一拠点内における他サーバから状態確認要求を受信していない場合（ステップＳ４７：Ｎｏルート）、ステップＳ４１の処理に戻る。

一方、同一拠点内における他サーバから状態確認要求を受信した場合（ステップＳ４７：Ｙｅｓルート）、状態管理部３０５は、状態テーブルから自サーバ及び対向サーバのプリケーション状態を示すデータ及びハートビート状態を示すデータを読み出し、読み出したデータを含む応答を生成する（ステップＳ４９）。

状態管理部３０５は、ステップＳ４９において生成した応答を、受信した状態確認要求の送信元のサーバに送信する（ステップＳ５１）。そしてステップＳ４１の処理に戻る。

以上のような処理を実行すれば、同一拠点内における他サーバ及び他サーバの対向サーバについて、アプリケーション状態及びハートビート状態を確認できるようになる。

次に、図７乃至図１１を用いて、アプリケーション状態及びハートビート状態を監視する処理について説明する。

まず、サーバの状態管理部３０５は、状態テーブルに基づき、自サーバのハートビート状態が「ＯＫ」であるか判断する（図７：ステップＳ６１）。自サーバのハートビート状態が「ＯＫ」である場合（ステップＳ６１：Ｙｅｓルート）、状態管理部３０５は一定時間待機し、ステップＳ６１の処理に戻る。

一方、自サーバのハートビート状態が「ＯＫ」ではない（すなわち「ＮＧ」である）場合（ステップＳ６１：Ｎｏルート）、状態管理部３０５は、同一拠点内の他サーバから、他サーバのハートビート状態を示すデータを取得する（ステップＳ６３）。ここで、他サーバとは、同一拠点内におけるサーバのうち自サーバ以外の全サーバのことである。なお、ステップＳ６３においては、他サーバの状態を示すデータを状態テーブルから取得してもよい。

状態管理部３０５は、同一拠点内の全サーバのハートビート状態が「ＯＫ」ではないか判断する（ステップＳ６５）。同一拠点内の全サーバのハートビート状態が「ＯＫ」ではない場合（ステップＳ６５：Ｙｅｓルート）、状態管理部３０５は、拠点間ネットワークであるネットワーク５の異常であると判定する（ステップＳ６７）。処理は端子Ａを介して図１０のステップＳ７７に移行する。

図８に、ステップＳ６７の時点においてサーバＡ１の状態テーブルに格納されるデータの一例を示す。サーバＡ１、サーバＢ１、及びサーバＣ１については、対向サーバからハートビートパケットを取得できないので、ハートビート状態が「ＮＧ」に設定されている。また、サーバＡ２、サーバＢ２、及びサーバＣ２については、アプリケーション状態及びハートビート状態が「ＵＮＫＮＯＷＮ」に設定されている。

図７の説明に戻り、同一拠点内のいずれかのサーバのハートビート状態が「ＯＫ」である場合（ステップＳ６５：Ｎｏルート）、状態管理部３０５は、状態テーブルに基づき、自サーバのアプリケーション状態が「ＡＣＴ」であるか判断する（ステップＳ６９）。自サーバのアプリケーション状態が「ＡＣＴ」である場合（ステップＳ６９：Ｙｅｓルート）、切替処理を行わなくてもよいので、ステップＳ６１の処理に戻る。

一方、自サーバのアプリケーション状態が「ＡＣＴ」ではない場合（ステップＳ６９：Ｎｏルート）、状態管理部３０５は、同一拠点内の他サーバのうちハートビート状態が「ＯＫ」である１台のサーバに、自サーバ（ここでは、便宜上「サーバＸ」と呼ぶ）の対向サーバのアプリケーション状態を示すデータを取得することを指示する。これに応じ、同一拠点内の他サーバのうちハートビート状態が「ＯＫ」である１台のサーバが、対向サーバから、サーバＸのアプリケーション状態を示すデータを取得する。そして、サーバＸの状態管理部３０５は、対向サーバのアプリケーション状態を示すデータを取得する（ステップＳ７１）。

状態管理部３０５は、対向サーバのアプリケーション状態が異常状態であるか判断する（ステップＳ７３）。例えば、アプリケーション状態が「ＦＬＴ」である場合に異常状態であると判断される。対向サーバのアプリケーション状態が異常状態ではない場合（ステップＳ７３：Ｎｏルート）、ステップＳ６１の処理に戻る。一方、対向サーバのアプリケーション状態が異常状態である場合（ステップＳ７３：Ｙｅｓルート）、状態管理部３０５は、自サーバを稼働系サーバに切り替えるための切替処理（すなわち、フェイルオーバーの処理）を実行する（ステップＳ７５）。そしてステップＳ６１の処理に戻る。切替処理とは、例えば、自サーバに稼働系サーバの論理アドレスを割り当て、対向サーバに割り当てた論理ドレスを無効にする処理である。切替処理は一般的な処理であるので、詳細な説明は省略する。

図９に、サーバＡ１に異常が発生した場合にサーバＡ２の状態テーブルに格納されるデータの一例を示す。図９の例では、サーバＡ１については、アプリケーション状態及びハートビート状態が「ＵＮＫＮＯＷＮ」に設定されている。また、サーバＡ２については、ハートビート状態が「ＮＧ」に設定され、アプリケーション状態が「ＳＢＹ」から「ＡＣＴ」に切り替えられている。

図１０のステップＳ７７の処理に移行し、状態管理部３０５は、状態テーブルに基づき、自サーバのハートビート状態が「ＯＫ」であるか判断する（ステップＳ７７）。自サーバのハートビート状態が「ＯＫ」である場合（ステップＳ７７：Ｙｅｓルート）、ネットワーク５の異常は解消したので、処理は端子Ｂを介してステップＳ６１の処理に戻る。

一方、自サーバのハートビート状態が「ＯＫ」ではない（すなわち「ＮＧ」である）場合（ステップＳ７７：Ｎｏルート）、状態管理部３０５は、同一拠点内の他サーバから、他サーバのハートビート状態を示すデータを取得する（ステップＳ７９）。ここで、他サーバとは、同一拠点内におけるサーバのうち自サーバ以外の全サーバのことである。

状態管理部３０５は、同一拠点内の全サーバのハートビート状態が「ＯＫ」ではないか判断する（ステップＳ８１）。同一拠点内の全サーバのハートビート状態が「ＯＫ」ではない場合（ステップＳ８１：Ｙｅｓルート）、ネットワーク５の障害が解消していないので、ステップＳ７７の処理に戻る。

一方、同一拠点内のいずれかのサーバのハートビート状態が「ＯＫ」である場合（ステップＳ８１：Ｎｏルート）、状態管理部３０５は、状態テーブルに基づき、自サーバのアプリケーション状態が「ＡＣＴ」であるか判断する（ステップＳ８３）。

自サーバのアプリケーション状態が「ＡＣＴ」である場合（ステップＳ８３：Ｙｅｓルート）、切替処理を行わなくてもよいので、処理は端子Ｂを介してステップＳ６１の処理に戻る。

一方、自サーバのアプリケーション状態が「ＡＣＴ」ではない場合（ステップＳ８３：Ｎｏルート）、状態管理部３０５は、同一拠点内の他サーバのうちハートビート状態が「ＯＫ」である１台のサーバに、自サーバ（ここでは、便宜上「サーバＸ」と呼ぶ）の対向サーバのアプリケーション状態を示すデータを取得することを指示する。これに応じ、同一拠点内の他サーバのうちハートビート状態が「ＯＫ」である１台のサーバが、対向サーバから、サーバＸのアプリケーション状態を示すデータを取得する。そして、サーバＸの状態管理部３０５は、対向サーバのアプリケーション状態を示すデータを取得する（ステップＳ８５）。

状態管理部３０５は、対向サーバのアプリケーション状態が異常状態であるか判断する（ステップＳ８７）。例えば、アプリケーション状態が「ＦＬＴ」である場合に異常状態であると判断される。対向サーバのアプリケーション状態が異常状態ではない場合（ステップＳ８７：Ｎｏルート）、切替処理を行わなくてもよいので、ステップＳ６１の処理に戻る。

一方、対向サーバのアプリケーション状態が異常状態である場合（ステップＳ８７：Ｙｅｓルート）、状態管理部３０５は、自サーバを稼働系サーバに切り替えるための切替処理（すなわち、フェイルオーバーの処理）を実行する（ステップＳ８９）。そしてステップＳ７７の処理に戻る。

図１１に、ネットワーク５の異常が解消した直後におけるサーバＡ１の状態テーブルに格納されるデータの一例を示す。サーバＡ１については、ハートビートパケットを交換できるようになったので、ハートビート状態が「ＯＫ」に設定されている。また、サーバＡ２については、ハートビート状態が「ＯＫ」に設定され、アプリケーション状態は「ＳＢＹ」に設定されている。

以上のような処理を実行すれば、ネットワーク５の異常と対向サーバの異常とを切り分けることができるようになる。これにより、ネットワーク５の異常が発生した際に切替処理を行うことがなくなるので、スプリットブレインシンドロームの発生を防げるようになる。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明したサーバの機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。

また、上で説明したテーブルの構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

なお、上で述べたサーバは、コンピュータ装置であって、図１２に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態の第１の態様に係る冗長構成システムは、第１の情報処理装置及び第２の情報処理装置を含む第１の情報処理システムと、第１の情報処理システムにネットワークを介して接続され且つ第３の情報処理装置及び第４の情報処理装置を含む第２の情報処理システムとを有する。そして、上で述べた第１の情報処理装置は、（Ａ）情報処理装置の状態を通知するためのパケットである状態通知を、ネットワークを介して第３の情報処理装置と交換する第１の通知部を有する。そして、第２の情報処理装置は、（Ｂ）状態通知を、ネットワークを介して第４の情報処理装置と交換する第２の通知部と、（Ｃ）第２の通知部が第４の情報処理装置と状態通知を交換できないことを検出した場合、第１の通知部が状態通知を第３情報処理装置と交換できているか否かを示す情報を第１の通知部から取得し、第１の通知部が状態通知を第３の情報処理装置と交換できているか判定する判定部とを有する。

第１の通知部が状態通知を第３の情報処理装置と交換できていない場合には、ネットワークに異常が発生した可能性が高い。従って、上で述べたようにすれば、第１の情報処理システムと第２の情報処理システムとを接続するネットワークにおいて異常が発生したことを検出できるようになる。

また、上で述べた判定部は、（ｃ１）第１の通知部が状態通知を第３情報処理装置と交換できている場合、第２の情報処理装置が待機系であるか判定し、（ｃ２）第２の情報処理装置が待機系である場合、第２の情報処理装置を待機系から稼働系に切り替えるための処理を実行してもよい。第１の通知部が状態通知を第３の情報処理装置と交換できている場合には、ネットワークに異常が発生したのではなく、第４の情報処理装置に異常が発生した可能性がある。そこで、上で述べたようにすれば、稼働系である第４の情報処理装置によるサービスの提供が停止することを防止できるようになる。

また、上で述べた判定部は、（ｃ３）第１の通知部が状態通知を第３情報処理装置と交換できている場合、第４の情報処理装置の状態を示す情報を取得した第３の情報処理装置から当該第４の情報処理装置の状態を示す情報を取得することを指示する取得指示を、第１の通知部に送信し、（ｃ４）第１の通知部から第４の情報処理装置の状態を示す情報を取得し、第４の情報処理装置が異常状態であるか判定し、（ｃ５）第４の情報処理装置が異常状態である場合、第２の情報処理装置が待機系であるか判定し、（ｃ６）第２の情報処理装置が待機系である場合、第２の情報処理装置を待機系から稼働系に切り替えるための処理を実行してもよい。上で述べたようにすれば、稼働系である第４の情報処理装置が異常状態であることを確認できるので、第２の情報処理装置および第４の情報処理装置が両方稼働系になることを回避できるようになる。

また、上で述べた第２の情報処理装置は、（Ｄ）第１乃至第４の情報処理装置の各々について、当該情報処理装置の状態を示す情報及び当該情報処理装置が状態通知を交換できているか否かを示す情報を格納する状態情報格納部をさらに有してもよい。これにより、判定を適切に行えるようになる。

本実施の形態の第２の態様に係る冗長構成制御方法は、第１の情報処理装置及び第２の情報処理装置を含む第１の情報処理システムと、第１の情報処理システムにネットワークを介して接続され且つ第３の情報処理装置及び第４の情報処理装置を含む第２の情報処理システムとを有する冗長構成システムにおいて実行される。そして、本冗長構成制御方法は、（Ｅ）第１の情報処理装置は、情報処理装置の状態を通知するためのパケットである状態通知を、ネットワークを介して第３の情報処理装置と交換し、（Ｆ）第２の情報処理装置は、状態通知を、ネットワークを介して第４の情報処理装置と交換し、（Ｇ）第２の情報処理装置は、第４の情報処理装置と状態通知を交換できない場合、第１の情報処理装置が状態通知を第３情報処理装置と交換できているか否かを示す情報を第１の情報処理装置から取得し、第１の情報処理装置が状態通知を第３の情報処理装置と交換できているか判定する処理を含む。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
第１の情報処理装置及び第２の情報処理装置を含む第１の情報処理システムと、
前記第１の情報処理システムにネットワークを介して接続され且つ第３の情報処理装置及び第４の情報処理装置を含む第２の情報処理システムと、
を有し、
前記第１の情報処理装置は、
情報処理装置の状態を通知するためのパケットである状態通知を、前記ネットワークを介して前記第３の情報処理装置と交換する第１の通知部
を有し、
前記第２の情報処理装置は、
前記状態通知を、前記ネットワークを介して前記第４の情報処理装置と交換する第２の通知部と、
前記第２の通知部が前記第４の情報処理装置と前記状態通知を交換できないことを検出した場合、前記第１の通知部が前記状態通知を前記第３情報処理装置と交換できているか否かを示す情報を前記第１の通知部から取得し、前記第１の通知部が前記状態通知を前記第３の情報処理装置と交換できているか判定する判定部と、
を有する冗長構成システム。

（付記２）
前記判定部は、
前記第１の通知部が前記状態通知を前記第３情報処理装置と交換できている場合、前記第２の情報処理装置が待機系であるか判定し、
前記第２の情報処理装置が待機系である場合、前記第２の情報処理装置を待機系から稼働系に切り替えるための処理を実行する、
付記１記載の冗長構成システム。

（付記３）
前記判定部は、
前記第１の通知部が前記状態通知を前記第３情報処理装置と交換できている場合、前記第４の情報処理装置の状態を示す情報を取得した前記第３の情報処理装置から当該第４の情報処理装置の状態を示す情報を取得することを指示する取得指示を、前記第１の通知部に送信し、
前記第１の通知部から前記第４の情報処理装置の状態を示す情報を取得し、前記第４の情報処理装置が異常状態であるか判定し、
前記第４の情報処理装置が異常状態である場合、前記第２の情報処理装置が待機系であるか判定し、
前記第２の情報処理装置が待機系である場合、前記第２の情報処理装置を待機系から稼働系に切り替えるための処理を実行する、
付記１記載の冗長構成システム。

（付記４）
前記第２の情報処理装置は、
前記第１乃至第４の情報処理装置の各々について、当該情報処理装置の状態を示す情報及び当該情報処理装置が前記状態通知を交換できているか否かを示す情報を格納する状態情報格納部
をさらに有する付記１乃至３のいずれか記載の冗長構成システム。

（付記５）
第１の情報処理装置及び第２の情報処理装置を含む第１の情報処理システムと、前記第１の情報処理システムにネットワークを介して接続され且つ第３の情報処理装置及び第４の情報処理装置を含む第２の情報処理システムとを有する冗長構成システムにおいて実行される冗長構成制御方法であって、
前記第１の情報処理装置は、情報処理装置の状態を通知するためのパケットである状態通知を、前記ネットワークを介して前記第３の情報処理装置と交換し、
前記第２の情報処理装置は、前記状態通知を、前記ネットワークを介して前記第４の情報処理装置と交換し、
前記第２の情報処理装置は、前記第４の情報処理装置と前記状態通知を交換できない場合、前記第１の情報処理装置が前記状態通知を前記第３情報処理装置と交換できているか否かを示す情報を前記第１の情報処理装置から取得し、前記第１の情報処理装置が前記状態通知を前記第３の情報処理装置と交換できているか判定する、
処理を含む冗長構成制御方法。

１００，２００ 中継装置 Ａ１，Ａ２，Ｂ１，Ｂ２，Ｃ１，Ｃ２ サーバ
３０１ ハートビート制御部 ３０３ アプリケーション状態特定部
３０５ 状態管理部 ３０７ 状態テーブル格納部
３０９ アプリケーション

Claims (5)

1. 第１の情報処理装置及び第２の情報処理装置を含む第１の情報処理システムと、
   前記第１の情報処理システムにネットワークを介して接続され且つ第３の情報処理装置及び第４の情報処理装置を含む第２の情報処理システムと、
   を有し、
   前記第１の情報処理装置は、
   情報処理装置の状態を通知するためのパケットである状態通知を、前記ネットワークを介して前記第３の情報処理装置と交換する第１の通知部
   を有し、
   前記第２の情報処理装置は、
   前記状態通知を、前記ネットワークを介して前記第４の情報処理装置と交換する第２の通知部と、
   前記第２の通知部が前記第４の情報処理装置と前記状態通知を交換できないことを検出した場合、前記第１の通知部が前記状態通知を前記第３情報処理装置と交換できているか否かを示す情報を前記第１の通知部から取得し、前記第１の通知部が前記状態通知を前記第３の情報処理装置と交換できているか判定する判定部と、
   を有する冗長構成システム。
2. 前記判定部は、
   前記第１の通知部が前記状態通知を前記第３情報処理装置と交換できている場合、前記第２の情報処理装置が待機系であるか判定し、
   前記第２の情報処理装置が待機系である場合、前記第２の情報処理装置を待機系から稼働系に切り替えるための処理を実行する、
   請求項１記載の冗長構成システム。
3. 前記判定部は、
   前記第１の通知部が前記状態通知を前記第３情報処理装置と交換できている場合、前記第４の情報処理装置の状態を示す情報を取得した前記第３の情報処理装置から当該第４の情報処理装置の状態を示す情報を取得することを指示する取得指示を、前記第１の通知部に送信し、
   前記第１の通知部から前記第４の情報処理装置の状態を示す情報を取得し、前記第４の情報処理装置が異常状態であるか判定し、
   前記第４の情報処理装置が異常状態である場合、前記第２の情報処理装置が待機系であるか判定し、
   前記第２の情報処理装置が待機系である場合、前記第２の情報処理装置を待機系から稼働系に切り替えるための処理を実行する、
   請求項１記載の冗長構成システム。
4. 前記第２の情報処理装置は、
   前記第１乃至第４の情報処理装置の各々について、当該情報処理装置の状態を示す情報及び当該情報処理装置が前記状態通知を交換できているか否かを示す情報を格納する状態情報格納部
   をさらに有する請求項１乃至３のいずれか１つ記載の冗長構成システム。
5. 第１の情報処理装置及び第２の情報処理装置を含む第１の情報処理システムと、前記第１の情報処理システムにネットワークを介して接続され且つ第３の情報処理装置及び第４の情報処理装置を含む第２の情報処理システムとを有する冗長構成システムにおいて実行される冗長構成制御方法であって、
   前記第１の情報処理装置は、情報処理装置の状態を通知するためのパケットである状態通知を、前記ネットワークを介して前記第３の情報処理装置と交換し、
   前記第２の情報処理装置は、前記状態通知を、前記ネットワークを介して前記第４の情報処理装置と交換し、
   前記第２の情報処理装置は、前記第４の情報処理装置と前記状態通知を交換できない場合、前記第１の情報処理装置が前記状態通知を前記第３情報処理装置と交換できているか否かを示す情報を前記第１の情報処理装置から取得し、前記第１の情報処理装置が前記状態通知を前記第３の情報処理装置と交換できているか判定する、
   処理を含む冗長構成制御方法。

Images