(57)【要約】【課題】ハートビート処理を行っている通信が不通となるスプリットブレーン状態の場合に、システム情報管理テーブルを用いず、障害の発生した業務アプリケーションを検出することができるクラスタシステム、クラスタサーバ及びクラスタ方法を提供する。【解決手段】本発明は、ネットワークにて接続された複数のサーバからなり、各アプリケーションを稼働系のサーバにおいて処理し、アプリケーションが異常となった場合に、異常となったアプリケーションを待機系のサーバで処理するクラスタシステムであり、各サーバが、他のサーバが正常か否かを検出するハートビート監視部と、他のサーバとの間のハートビートが異常である場合、他のサーバで稼働しているアプリケーションを起動するアプリケーション制御部と、ルータのアプリケーションのＩＰアドレスに対応するＭＡＣアドレスを、自身のＭＡＣアドレスに変更するアプリケーション切り替え部とを有する。【選択図】図１
2010103695.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークにて接続された複数のサーバからなり、各アプリケーションを稼働系のサーバにおいて処理し、アプリケーションが異常となった場合に、異常となったアプリケーションを待機系のサーバにて処理するクラスタシステムであり、
前記各サーバが、
他のサーバとの間におけるハートビートが正常に動作しているか否かを検出するハートビート監視部と、
該ハートビート監視部が他のサーバとの間のハートビートが異常であることを検出した場合、前記他のサーバにて稼働しているアプリケーションを起動するアプリケーション制御部と、
ルータにおける当該アプリケーションのＩＰアドレスに対応するＭＡＣアドレスを、自身のＭＡＣアドレスに変更するアプリケーション切り替え部と
を有することを特徴とするクラスタシステム。
【請求項２】
前記アプリケーション制御部が、
前記ハートビートに異常が発生した際、前記ネットワークを介してエコーパケットを各他のサーバに送信し、前記エコーパケットに対する返信の無いサーバに対応するアプリケーションを、現在実行しているアプリケーションに加えて実行することを特徴とする請求項１に記載のクラスタシステム。
【請求項３】
前記アプリケーション制御部が、前記エコーパケットに対して返信があった場合、当該エコーパケットを返信した他のサーバへ仮想端末ソフトウェアを用いて前記ネットワークを介してログインし、前記エコーパケットを返信したサーバで稼働している各アプリケーションの動作状態をチェックし、正常であるか否かの検出を行うことを特徴とする請求項２記載のクラスタシステム。
【請求項４】
ネットワークにて接続された複数のサーバからなり、各アプリケーションを稼働系のサーバにおいて処理し、アプリケーションが異常となった場合に、異常となったアプリケーションを待機系のサーバにて処理するクラスタシステムで用いられるクラスタサーバであり、
他のサーバとの間におけるハートビートが正常に動作しているか否かを検出するハートビート監視部と、
該ハートビート監視部が他のサーバとの間のハートビートが異常であることを検出した場合、前記他のサーバにて稼働しているアプリケーションを起動するアプリケーション制御部と、
ルータにおける当該アプリケーションのＩＰアドレスに対応するＭＡＣアドレスを、自身のＭＡＣアドレスに変更するアプリケーション切り替え部と
を有することを特徴とするクラスタサーバ。
【請求項５】
ネットワークにて接続された複数のサーバからなり、各アプリケーションを稼働系のサーバにおいて処理し、アプリケーションが異常となった場合に、異常となったアプリケーションを待機系のサーバにて処理するクラスタシステムにおいて用いられるクラスタ制御方法であり、
前記各サーバにおいて、
ハートビート監視部が他のサーバとの間におけるハートビートが正常に動作しているか否かを検出するハートビート監視過程と、
前記ハートビート監視部により他のサーバとの間のハートビートが異常であることが検出された場合、アプリケーション制御部が、前記他のサーバにて稼働しているアプリケーションを起動するアプリケーション制御過程と、
アプリケーション切り替え部が、ルータにおける当該アプリケーションのＩＰアドレスに対応するＭＡＣアドレスを、自身のＭＡＣアドレスに変更するアプリケーション切り替え過程と
を有することを特徴とするクラスタ制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサーバを有し、ある稼働系のサーバで稼働している業務アプリケーションに障害が発生した際に、他のサーバである待機系のサーバで同様の業務アプリケーションを稼働させ、常にその業務アプリケーションを稼働状態とするクラスタシステム、ならびに、そのクラスタシステムの制御方法に関する。
【背景技術】
【０００２】
近年、クラスタシステムは、システムの大規模化によりデータ量が増大しているため、複数のサーバにより負荷分散を行い、かつ稼働させる業務アプリケーションに対して稼働系及び待機系を設け、所定の業務アプリケーションが稼働しないダウンタイムを低減して信頼性を向上させている。
すなわち、クラスタシステムは、複数のサーバにより、それぞれ異なる所定の業務アプリケーションが稼働しており、各サーバが他のサーバと通信を行い相互監視を行い（ハートビート処理）、いずれかのコンピュータの業務アプリケーションに障害が発生した場合、他のサーバにおいて、その業務アプリケーションを稼働させ、その業務アプリケーションを継続して実行させる構成となっている（例えば、引用文献１参照）。
【特許文献１】特開２００５−６９８７２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上述したクラスタシステムは、ハートビート処理を行っている通信が不通となった場合、相互監視が行えなくなるスプリットブレーン状態となるため、各サーバが共通にアクセス可能なシステム情報管理テーブルを有している。
すなわち、各サーバの監視ソフトが、このシステム情報管理テーブルの各サーバの業務アプリケーション毎（あるいは複数のグループからなる業務アプリケーショングループ毎）に動作主体となっているサーバの識別子を書き込む欄があり、その欄に周期的にアクセス結果を書き込んでいる。
【０００４】
したがって、他サーバの業務アプリケーションに対応する上記欄を確認し、設定された時間以上の間隔を置いて、新たな時間が書き込まれなかった場合、その業務アプリケーションに障害が発生していることを検出し、他のサーバがその障害のあった業務アプリケーションを自身が行う切り替え処理を行う。
ところが、上述したシステム情報管理テーブルを設ける場合、新たにディスクをシステムに配設することとなり、システム全体の価格が高くなってしまうという問題がある。
また、クラスタシステムのアプリケーションが提供するサービスの種類によっては、データを外部のディスクに蓄積する必要の無いものもあり、スプリットブレーンに対応することだけの目的で、ディスクを設けることはシステム全体の価格を高くすることとなる。
【０００５】
本発明は、このような事情に鑑みてなされたもので、ハートビート処理を行っている通信が不通となるスプリットブレーン状態となった場合に、上述したシステム情報管理テーブルを用いずとも、障害の発生した業務アプリケーションを検出することができるクラスタシステム、クラスタサーバ及びクラスタ方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明のクラスタシステムは、ネットワークにて接続された複数のサーバからなり、各アプリケーションを稼働系のサーバにおいて処理し、アプリケーションが異常となった場合に、異常となったアプリケーションを待機系のサーバにて処理するクラスタシステムであり、前記各サーバが、他のサーバとの間におけるハートビートが正常に動作しているか否かを検出するハートビート監視部と、該ハートビート監視部が他のサーバとの間のハートビートが異常であることを検出した場合、前記他のサーバにて稼働しているアプリケーションを起動するアプリケーション制御部と、ルータにおける当該アプリケーションのＩＰアドレスに対応するＭＡＣアドレスを、自身のＭＡＣアドレスに変更するアプリケーション切り替え部とを有することを特徴とする。
【０００７】
本発明のクラスタシステムは、前記アプリケーション制御部が、前記ハートビートに異常が発生した際、前記ネットワークを介してエコーパケットを各他のサーバに送信し、前記エコーパケットに対する返信の無いサーバに対応するアプリケーションを、現在実行しているアプリケーションに加えて実行することを特徴とする。
【０００８】
本発明のクラスタシステムは、前記アプリケーション制御部が、前記エコーパケットに対して返信があった場合、当該エコーパケットを返信した他のサーバへ仮想端末ソフトウェアを用いて前記ネットワークを介してログインし、前記エコーパケットを返信したサーバで稼働している各アプリケーションの動作状態をチェックし、正常であるか否かの検出を行うことを特徴とする。
【０００９】
本発明のクラスタサーバは、ネットワークにて接続された複数のサーバからなり、各アプリケーションを稼働系のサーバにおいて処理し、アプリケーションが異常となった場合に、異常となったアプリケーションを待機系のサーバにて処理するクラスタシステムで用いるクラスタサーバであり、他のサーバとの間におけるハートビートが正常に動作しているか否かを検出するハートビート監視部と、該ハートビート監視部が他のサーバとの間のハートビートが異常であることを検出した場合、前記他のサーバにて稼働しているアプリケーションを起動するアプリケーション制御部と、ルータにおける当該アプリケーションのＩＰアドレスに対応するＭＡＣアドレスを、自身のＭＡＣアドレスに変更するアプリケーション切り替え部とを有することを特徴とする。
【００１０】
本発明のクラスタ制御方法は、ネットワークにて接続された複数のサーバからなり、各アプリケーションを稼働系のサーバにおいて処理し、アプリケーションが異常となった場合に、異常となったアプリケーションを待機系のサーバにて処理するクラスタシステムにおいて用いられるクラスタ制御方法であり、前記各サーバにおいて、ハートビート監視部が他のサーバとの間におけるハートビートが正常に動作しているか否かを検出するハートビート監視過程と、前記ハートビート監視部により他のサーバとの間のハートビートが異常であることが検出された場合、アプリケーション制御部が、前記他のサーバにて稼働しているアプリケーションを起動するアプリケーション制御過程と、アプリケーション切り替え部が、ルータにおける当該アプリケーションのＩＰアドレスに対応するＭＡＣアドレスを、自身のＭＡＣアドレスに変更するアプリケーション切り替え過程とを有することを特徴とする。
【発明の効果】
【００１１】
以上説明したように、本発明によれば、監視専用接続が不通あるいは稼働しているサーバが異常となることで、通信ハートビート処理（以下、ハートビート）が行えなくなり、スプリットブレーン状態となった場合でも、従来のように高価なシステム情報管理テーブル共有ディスクを設けなくとも、各アプリケーションに対するＩＣＭＰ（Control Message Protocol）のエコーパケット（エコーリクエストパケット）、例えばＰＩＮＧ（Packet INternet Groper）の送信、及び他のサーバに対してネットワークからのログインによるアプリケーションのチェックにより、障害のあるアプリケーションを容易に検出することが可能であり、従来例に比較して安価なクラスタシステムを構成することができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の一実施形態によるクラスタシステムの構成を図面を参照して説明する。図１は同実施形態によるクラスタシステムの構成例を示すブロック図である。
この図において、本実施形態のクラスタシステムは、サーバ１、サーバ２、…の複数のサーバと、ルータ３０と、により構成されている。
サーバ１、サーバ２、…は、ネットワーク１００に接続されており、ルータ３０を介して外部システム、すなわちクライアント端末等に接続されている。また、外部システムとの接続は、ルータ３０の代わりにスイッチングハブでもよく、ネットワークにおいて、ＶＩＰ（仮想ＩＰ）アドレスとＭＡＣ（Media Access Control address）アドレスとの対応を示すＡＲＰ（Address Resolution Protocol）テーブルを有している経路制御を行うネットワーク機器であれば何でも良い。
【００１３】
このＶＩＰアドレスは、ネットワーク１００を介して、あるいはルータ３０を介して接続されるクライアント端末が業務アプリケーションにアクセスする際に用いられる。
すなわち、上記ＶＩＰアドレスは、図３のテーブルにより各業務アプリケーションに対応するネットワークセグメントに設定される。
上記サーバ１、サーバ２、…各々は、それぞれにて稼働している業務アプリケーションにて、各業務アプリケーションにアクセスするクライアント端末に対してサービスを提供する。上述した各サーバにおいて、あるサーバは稼働系として用いて、業務用アプリケーションを処理し、あるサーバは待機系として、処理が異常となった業務用アプリケーションが検出された場合、その業務アプリケーションが稼働していた稼働系のサーバから、業務アプリケーションが稼働していない待機系のサーバに移行する処理が行われる。以下説明を簡単とするため、本実施形態においては、サーバが２台であって、サーバ１（稼働系）及びサーバ２（待機系）がネットワーク１００に接続されているとして説明する。
【００１４】
サーバ１は、ハートビート監視部１１、業務アプリケーション制御部１２、業務アプリケーション切り替え部１３、インターフェース１４及び記憶部１５を有している。
同様に、サーバ２は、ハートビート監視部２１、業務アプリケーション制御部２２、業務アプリケーション切り替え部２３、インターフェース２４及び記憶部２５を有している。
上記業務アプリケーション制御部１２は、監視部１２１と制御部１２２とを有する。
同様に、上記業務アプリケーション制御部２２は、監視部２２１と制御部２２２とを有する。
記憶部１５及び記憶部２５には、アプリケーションＩＤと、そのアプリケーションＩＤに対応して業務アプリケーション（実行ファイル）とが記憶されている。
ハートビート監視部１１は、ハートビート監視部２１に対し、あらかじめ設定した周期毎に、監視信号を出力し、その応答の有無により、ハートビート監視部１１との間のハートビートが正常に動作しているか否かの検出を行う。
同様に、ハートビート監視部２１は、ハートビート監視部１１に対し、あらかじめ設定した周期毎に、監視信号を出力し、その応答の有無により、ハートビート監視部１１との間のハートビートが正常に動作しているか否かの検出を行う。
ここで、ハートビート監視部１１とハートビート監視部２１とは、ハートビートのデータの送受信を行うネットワークを、ルータ３０に接続されているネットワーク１００と異なるネットワークセグメントを用いて行っている。
【００１５】
業務アプリケーション制御部１２は、監視部１２１と制御部１２２とを有している。
ここで、監視部１２１は、サーバ１において稼働されている業務アプリケーションの監視、すなわち、あらかじめ設定した周期毎に、自身の属するサーバ１で稼働している業務アプリケーションの動作における障害の有無を検出する。この障害の検出において、監視部１２１は、各業務アプリケーションに動作確認の確認信号を送信し、業務アプリケーションからの応答信号の有無により、自身の属するサーバ１で稼働しているアプリケーションの障害の有無を検出している。ここで、監視部１２１は、内部の記憶部に各業務アプリケーションの識別情報であるアプリケーションＩＤに対応付けて動作状態を書き込んで記録する。
制御部１２２は、業務アプリケーションの起動及び停止を行い、上記監視部１２１が障害を検出すると、対応する業務アプリケーションを停止し、停止させた業務アプリケーションのアプリケーションＩＤを、ハートビート監視部１１を介し、ハートビート監視部２１へ送信する。また、制御部１２２は、ハートビート監視部１１から通知されるアプリケーションＩＤに対応する業務アプリケーションを、記憶部１５のテーブルから読み込んで実行する。
【００１６】
また、業務アプリケーション制御部２２は、監視部２２１と制御部２２２とを有している。
ここで、監視部２２１は、サーバ２において稼働されている業務アプリケーションの監視、すなわち、あらかじめ設定した周期毎に、自身の属するサーバ２で稼働している業務アプリケーションの動作における障害の有無を検出する。この障害の検出において、監視部２２１は、各業務アプリケーションに動作確認の確認信号を送信し、業務アプリケーションからの応答信号の有無により、自身の属するサーバ２で稼働している障害の有無を検出している。ここで、監視部２２１は、内部の記憶部に各業務アプリケーションのアプリケーションＩＤに対応付けて動作状態を書き込んで記録する。
制御部２２２は、業務アプリケーションの起動及び停止を行い、上記監視部２２１が障害を検出すると、対応する業務アプリケーションを停止し、停止させた業務アプリケーションのアプリケーションＩＤを、ハートビート監視部２１を介し、ハートビート監視部１１へ送信する。また、制御部２２２は、ハートビート監視部２１から通知されるアプリケーションＩＤに対応する業務アプリケーションを、記憶部２５のテーブルから読み込んで実行する。
【００１７】
業務アプリケーション切り替え部１３は、ルータ３０に記憶されているＡＲＰテーブルを書き換えるため、ハートビート監視部１１から通知されるアプリケーションＩＤに対応したＶＩＰアドレスと、ＭＡＣアドレスとを含むＡＲＰパケットを、ルータ３０に送信する。
インターフェース１４は、ネットワーク１００を介してルータ３０に接続されたＭＡＣアドレス＃１を有し、ＬＡＮアダプタを有するインターフェースである。このＬＡＮアダプタは、同一のＭＡＣアドレス＃１に対して複数のＶＩＰアドレスを対応付け、複数のアプリケーション毎に異なるＶＩＰアドレスを用いた通信処理を行う。
このＬＡＮアダプタは、同一のＭＡＣアドレス＃１に対して複数のＶＩＰアドレスを対応付け、複数のアプリケーション毎に異なるＶＩＰアドレスを用いた通信処理を行う。
【００１８】
業務アプリケーション切り替え部２３は、ルータ３０に記憶されているＡＲＰテーブルを書き換えるため、ハートビート監視部２１から通知される業務アプリケーションＩＤに対応したＶＩＰアドレス及びＭＡＣアドレス含むＡＲＰパケットを、ルータ３０に送信する。
インターフェース２４は、ネットワーク１００を介してルータ３０に接続されたＭＡＣアドレス＃２を有し、ＬＡＮアダプタを有するインターフェースである。このＬＡＮアダプタは、同一のＭＡＣアドレス＃２に対して複数のＶＩＰアドレスを対応付け、複数の業務アプリケーション毎に異なるＶＩＰアドレスを用いた通信処理を行う。
このＬＡＮアダプタは、同一のＭＡＣアドレス＃２に対して複数のＶＩＰアドレスを対応付け、複数の業務アプリケーション毎に異なるＶＩＰアドレスを用いた通信処理を行う。
【００１９】
ルータ３０には、サーバ１，２，…のＭＡＣアドレス（Media Access Control address）と、それぞれのサーバが業務アプリケーションに対応して有しているＶＩＰアドレスとが対応付けられた、図２に示すＡＲＰテーブルが記憶されている。ここで、＃１がサーバ１のＭＡＣアドレスであり、＃２がサーバ２のＭＡＣアドレスである。ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ１がアプリケーションＡＰ１に対応して設けられたＶＩＰアドレスであり、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ２がアプリケーションＡＰ２に対応して設けられたＶＩＰアドレスであり、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ３がアプリケーションＡＰ３に対応して設けられたＶＩＰアドレスであり、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ４がアプリケーションＡＰ４に対応して設けられたＶＩＰアドレスである。
【００２０】
また、記憶部１５及び記憶部２５各々には、上記ＶＩＰアドレスと、当該ＶＩＰアドレスに対応した業務アプリケーションを示す識別情報であるアプリケーションＩＤとが対応付けられた、図３に示す対応テーブルが記憶されている。この図３において、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ１はアプリケーションＩＤであるアプリケーションＡＰ１に対応付けられており、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ２はアプリケーションＩＤであるアプリケーションＡＰ２に対応付けられ、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ３はアプリケーションＩＤであるアプリケーションＡＰ３に対応付けられ、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ４はアプリケーションＩＤであるアプリケーションＡＰ４に対応付けられている。
【００２１】
また、ルータ３０は、ＶＩＰアドレスを含む上記ＡＲＰパケットをサーバから受信すると、ＡＲＰパケットに付加されたＶＩＰアドレスに対応するＭＡＣアドレスを、当該ＡＲＰパケットを送信したサーバのＭＡＣアドレスに変更する。
ここで、上記ＶＩＰアドレスは、すでに述べたように、テーブルにて対応する各業務アプリケーションに対するパケットのネットワークセグメントヘッダーやＵＤＰデータグラムヘッダー中の宛先ポート番号に対応している。すなわち、上記ＶＩＰアドレスは、各業務アプリケーションに対して１つのＩＰアドレスを割り当てるために設定されている。
【００２２】
次に、図１及び図４を参照して本実施形態によるクラスタシステムの動作を説明する。図４は、図１のクラスタシステムにおける、ハートビートが正常な場合、すなわちスプリットブレーンではない状態でのアプリケーションの切り替えの動作例を示すフローチャートである。以下、説明を簡単とするため、クラスタシステムが、サーバ１及びサーバ２の２つにより構成され、サーバ１の動作を中心に説明する。しかしながら、サーバ２においても同様の動作が行われている。
以下、図２及び図３の各テーブルに示すように、図１のクラスタシステムにおいて、初期状態において、稼働系のサーバ１でアプリケーションＡＰ１、ＡＰ２、ＡＰ３及びＡＰ４が稼働しており、待機系のサーバ２ではいずれの業務アプリケーションも稼働していない。
【００２３】
監視部１２１は、サーバ１において稼働している業務アプリケーションＡＰ１、ＡＰ２、ＡＰ３及びＡＰ４の動作状態の監視を、予め設定された周期において行う（ステップＳ１）。
そして、監視部１２１は、各業務アプリケーションに対して確認信号を送信し、応答信号の有無を確認することによって、正常であるか否かの判定を行い（ステップＳ２）、正常である旨の応答があった場合、処理を繰り返し、一方、応答がない場合、または異常である旨の応答があった場合には、異常の検出されたアプリケーションＩＤを、例えばアプリケーションＡＰ３を制御部１２２へ送信して処理をＳ３へ進める。
上記アプリケーションＩＤが入力されると、制御部１２２は、このアプリケーションＡＰ３に対応する業務アプリケーションを記憶部１５のテーブルにより特定し（ステップＳ３）、特定された業務アプリケーションの稼働を停止させる（ステップＳ４）。
このとき、業務アプリケーション切り替え部１３は、このアプリケーションＡＰ３に付与されたＶＩＰに対するネットワークセグメントの対応関係の記述を記憶部１５から削除する。
【００２４】
次に、制御部１２２は、停止させた業務アプリケーションのアプリケーションＩＤを、異常検出信号とともに、ハートビート監視部１１を介して、サーバ２へ送信する（ステップＳ５）。
上記異常検出信号及びアプリケーションＩＤがサーバ１のハートビート監視部１１から送信されると、サーバ２のハートビート監視部２１は、このアプリケーションＩＤ及び異常検出信号を受信する（ステップＳ６）。
これにより、サーバ２の制御部２２２は、ハートビート監視部２１が受信した上記アプリケーションＩＤ及び異常検出信号に基づいて業務アプリケーションの起動処理、すなわち、入力されたアプリケーションＡＰ３に対応する業務アプリケーションを、記憶部２５のテーブルから読み出し、この業務アプリケーションを起動する。
そして、業務アプリケーション切り替え部２３は、この起動したアプリケーションＡＰ３に対応するＶＩＰアドレスを、図３のテーブルより読み出し、このＶＩＰアドレスに対するネットワークセグメントを生成し、起動した業務アプリケーションのアプリケーションＩＤとＶＩＰアドレスの対応付けを行い、記憶部２５に書き込む（ステップＳ７）。
この後、サーバ２において、制御部２２２は、アプリケーションＡＰ３に対する稼働の確認処理を行う。
【００２５】
また、業務アプリケーション切り替え部２３は、アプリケーションＩＤがアプリケーションＡＰ３のＶＩＰアドレスであるＸ．Ｘ．Ｘ．Ｘ３と、サーバ２のＭＡＣアドレス＃２を付加したＡＲＰパケットをルータ３０に送信する。
ＡＲＰパケットが入力されると、ルータ３０は、ＡＲＰテーブルにおいて、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ３に対応したＭＡＣアドレスをサーバ１のＭＡＣアドレス＃１からサーバ１の＃２へ書き換える。
これにより、以降の外部システムのクライアント端末からのアプリケーションＡＰ３に対するアクセスは、待機系から稼働系となったサーバ２において実行されているプリケーションＡＰ３に対して行われることになる。
【００２６】
以下、スプリットブレーンが発生した際に、異常とされたサーバから、正常な他のサーバへ業務アプリケーションを切り替える２つの異なる切り替え処理について説明する。
＜スプリットブレーン発生時の第１の業務アプリケーション切り替え処理＞
次に、ハートビートが異常、すなわちサーバ１及びサーバ２においてスプリットブレーンが発生した場合の業務アプリケーションの切り替え処理について説明する。図５は、サーバ２を主体として、アプリケーション切り替え処理の動作を説明するフローチャートである。
ハートビート監視部１１及びハートビート監視部２１のそれぞれは、互いの属するサーバの稼働状態をハートビート（上述したサーバの稼働状態を示す通知の送受信処理）にて監視するとともに、監視用専用接続であるネットワークの通信状況を確認している。ここでは、サーバ２のハートビート監視部２１がサーバ１を監視している（ステップＳ１１）。
ここで、ハートビート監視部１１及びハートビート監視部２１は、それぞれルータ３０と接続されたインターフェース１４、１５のネットワーク１００と異なるネットワークセグメントにより、それぞれの間に監視用専用接続を形成している。
【００２７】
ハートビート監視部１１及びハートビート監視部２１のそれぞれは、接続されている相手から予め設定された一定周期毎に、返信の有無によりハートビートが有効に行われているか否か、すなわちスプリットブレーンの状態であるか否かを判定する。ここでは、サーバ２のハートビート監視部２１は、サーバ１との間のハートビートが有効に行われているか否かを判定する（ステップＳ１２）。この場合も、図１のクラスタシステムにおいて、初期状態において、稼働系のサーバ１でアプリケーションＡＰ１、ＡＰ２、ＡＰ３及びＡＰ４が稼働しており、待機系のサーバ２ではいずれの業務アプリケーションも稼働していないものとして説明する。
ここで、ハートビート監視部２１は、ハートビート監視部１１に対して送信した監視信号に対する応答信号を受信した場合、サーバ１が正常に動作しているとして、処理をステップＳ１３へ進め、すでに説明したハートビートが正常な場合の監視処理となり、一方、監視信号に対する応答信号が受信されない場合、サーバ１自体が異常あるいは監視用専用接続が異常である（スプリットブレーンの状態である）として、処理をステップＳ１４へ進める。
【００２８】
次に、サーバ２の制御部２２２は、クラスタシステムにて稼働している業務アプリケーションのアプリケーションＩＤを記憶部２５において抽出し、自身にて稼働しているアプリケーションが無いため、抽出した全てのアプリケーションＩＤに対応する業務アプリケーションが、稼働系であるサーバ１において稼働している業務アプリケーションであると特定する（ステップＳ１４）。
そして、制御部２２２は、特定した上記アプリケーションＩＤ、すなわちアプリケーションＡＰ１、ＡＰ２、ＡＰ３及びＡＰ４を起動する。
そして、業務アプリケーション切り替え部２３は、起動した各アプリケーションＡＰ１、ＡＰ２、ＡＰ３、ＡＰ４各々に対応するＶＩＰアドレスを、図３のテーブルより読み出し、このＶＩＰアドレスに対するネットワークセグメントをそれぞれ生成し、起動した業務アプリケーションにそれぞれ対応付け、記憶部２５に記憶させる（ステップＳ１５）。
【００２９】
この後、制御部２２２は、アプリケーションＡＰ１、ＡＰ２、ＡＰ３及びＡＰ４に対する稼働の確認処理を行う。
また、業務アプリケーション切り替え部２３は、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ１とＭＡＣアドレス＃２とを付加したＡＲＰパケット、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ２とＭＡＣアドレス＃２とを付加したＡＲＰパケット、Ｘ．Ｘ．Ｘ．Ｘ３とＭＡＣアドレス＃２とを付加したＡＲＰパケット、及びＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ４とＭＡＣアドレス＃２とを付加したＡＲＰパケットの４つのＡＲＰパケットをルータ３０に送信する（ステップＳ１６）。
ＡＲＰパケットが入力されると、ルータ３０は、ＡＲＰテーブルにおいて、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ１、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ２、Ｘ．Ｘ．Ｘ．Ｘ３及びＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ４それぞれとに対応したＭＡＣアドレスをサーバ１のＭＡＣアドレス＃１からサーバ２の＃２へ書き換える。
これにより、以降の外部システムのクライアント端末からのアプリケーションＡＰ１、ＡＰ２、ＡＰ３及びＡＰ４に対するアクセスは、サーバ１において実行されているプリケーションＡＰ１、ＡＰ２、ＡＰ３及びＡＰ４に対して行われることになる。
【００３０】
上述したように、本実形態における書き換えは、サーバ２における業務アプリケーションの稼働状態によらず、スプリットブレーンとなると強制的に業務アプリケーションの切り替えが行われることになる。
これにより、本実施形態によれば、従来のように高価なシステム情報管理テーブル共有ディスクを設けなくとも、スプリットブレーンとなったことが検出されると、ハートビートを行っていた相手のサーバで稼働している業務アプリケーションを、容易に自身のサーバにて行うように切り替えることが可能となり、従来例に比較して安価なクラスタシステムを構成することができる。
【００３１】
＜スプリットブレーン発生時の第２の業務アプリケーション切り替え処理＞
次に、図６を用いて、ハートビートが異常、すなわちサーバ１及びサーバ２においてスプリットブレーンが発生した際に、すでに述べた第１の実施形態と異なる業務アプリケーションの切り替え処理について説明する。図６は、サーバ２を主体として、アプリケーション切り替え処理の動作を説明するフローチャートである。
ハートビート監視部１１及びハートビート監視部２１のそれぞれは、属するサーバの稼働状態を互いにハートビート（上述したサーバの稼働状態を示す通知の送受信処理）にて監視するとともに、監視用専用接続であるネットワークの通信状況を確認している。ここでは、サーバ２のハートビート監視部２１がサーバ１を監視している（ステップＳ２１）。
ここで、ハートビート監視部１１及びハートビート監視部２１は、それぞれルータ３０と接続されたインターフェース１４、１５のネットワーク１００と異なるセグメントにより、それぞれの間に監視用専用接続を形成している。
【００３２】
ハートビート監視部１１及びハートビート監視部２１のそれぞれは、接続されている相手から予め設定された一定周期毎に、返信の有無によりハートビートが有効に行われているか否か（スプリットブレーンの状態であるか否か）を判定する。ここでは、サーバ２のハートビート監視部２１は、サーバ１との間のハートビートが有効に行われているか否かを判定する（ステップＳ２２）。この場合も、図１のクラスタシステムにおいて、初期状態において、稼働系のサーバ１でアプリケーションＡＰ１、ＡＰ２、ＡＰ３及びＡＰ４が稼働しており、待機系のサーバ２ではいずれの業務アプリケーションも稼働していない場合について説明する。
ここで、ハートビート監視部２１は、ハートビート監視部１１に対して送信した監視信号に対する応答を受信した場合、サーバ１が正常に動作しているとして、処理をステップＳ２３へ進め、すでに説明したハートビートが正常な場合の監視処理となり、一方、監視信号に対する応答信号が受信されない場合、サーバ１自体が異常あるいは監視用専用接続が異常であるとして、処理をステップＳ２４へ進める。
【００３３】
次に、サーバ２において、制御部２２２は、サーバ１に対してインターフェース２４から、ネットワーク１００を介してエコーパケットを送信し（ステップＳ２４）、このエコーパケットに対する応答信号の有無を確認する（ステップＳ２５）。
このとき、制御部２２２は、応答信号が無い場合、サーバ１自体が動作していないと判定し、処理をステップＳ２６へ進め、このステップＳ２６において第１の実施形態におけるステップＳ１４からＳ１６までの処理を行い、サーバ１で稼働していた業務アプリケーションをサーバ２にて起動する。
一方、応答信号が入力された場合、制御部２２２は、処理をステップＳ２７へ進める。
【００３４】
ここで、エコーパケットに対する応答が入力されたが、エコーパケットの応答のみではＬ３（レイヤー３）までの動作状態しか検出できないため、制御部２２２は各業務アプリケーションの動作の状態を検出する処理を行う。
すなわち、制御部２２２は、ネットワークの上位のレイヤーにおける動作を確認するため、ＯＳ、例えばＷＩＮＤＯＷＳ（登録商標）やＵＮＩＸ（登録商標）における仮想端末ソフトウェアの機能として設けられているＴｅｌｎｅｔあるいはＳＳＨ（Ｓｅｃｕｒｅ  Ｓｈｅｌｌ）により、他のサーバ、すなわちインターフェース２４及びネットワーク１００を介してサーバ１にリモートでログインし（遠隔操作により）、サーバ１の監視部１２１における業務アプリケーションの監視処理を起動させて、各業務アプリケーションの稼働状態をチェックし（ステップＳ２８）、チェック結果に基づいて、サーバ１のアプリケーションが正常に稼働しているか否かを判定する（ステップＳ２９）。
サーバ１のアプリケーションが正常に稼働していない場合、サーバ２の制御部２２２は、ステップＳ２６と同様に、第１の実施形態におけるステップＳ１４からＳ１６までの処理を行い、サーバ１で稼働していない業務アプリケーションを起動する（ステップＳ３０）。
一方、ステップＳ２９において、業務アプリケーションの全てが正常に動作しており、サーバ１の監視部１２１が業務アプリケーションの障害を検出しなかった場合、スプリットブレーン状態ではあるものの、稼働系サーバ自体には障害がないと判断できるため、サーバ１にリモートログインしている制御部２２２は、制御部１２２に業務アプリケーションを停止させる処理、及びルータ３０に対するＡＲＰパケットの送信を行わず、すなわち業務アプリケーションの稼働を強制的に待機系のサーバ２へ移行する処理であるステップＳ３０を行わずに処理を終了する。
【００３５】
次に、サーバ１において、制御部１２２は、上記ステップＳ２８において、障害が発生した異常な業務アプリケーションが検出されると、その業務アプリケーションのアプリケーションＩＤ、例えばアプリケーションＡＰ４を読み出し、制御部１２２により、アプリケーションＡＰ４に対応する業務アプリケーションを停止させる。これにより、業務アプリケーション切り替え部２３は、アプリケーションＡＰ４に対応するＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ４のネットワークセグメントを削除する。
そして、サーバ２において、制御部２２２は、上記アプリケーションＩＤ、すなわちアプリケーションＡＰ４を起動する。
次に、業務アプリケーション切り替え部２３は、起動したアプリケーションＡＰ４に対応するＶＩＰを、図３のテーブルより読み出し、このＶＩＰアドレスに対するネットワークセグメントを生成し、起動した業務アプリケーションにそれぞれ対応付け、記憶部２５に記憶する（ステップＳ３０）。
なお、スプリットブレーン発生と同時に、稼働系のサーバ１の業務用アプリケーションの動作を監視する監視部１２１に異常が発生していることも考えられる。その場合には、制御部１２２により業務アプリケーションを停止させるという上述の処理に代えて、リモートにてログインしている制御部２２２がサーバ１の業務アプリケーションの停止処理を行うこととしても良い。
【００３６】
この後、制御部２２２は、アプリケーションＡＰ４に対する稼働の確認処理を行う。
また、業務アプリケーション切り替え部２３は、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ４及びＭＡＣアドレス＃２を付加したＡＲＰパケットをルータ３０に送信する。
ＡＲＰパケットが入力されると、ルータ３０は、ＡＲＰテーブルにおいて、ＶＩＰアドレスＸ．Ｘ．Ｘ．Ｘ４に対応したＭＡＣアドレスをサーバ１のＭＡＣアドレス＃１からサーバ２のＭＡＣアドレス＃２へ書き換える。
これにより、以降の外部システムのクライアント端末からのアプリケーションＡＰ４に対するアクセスは、サーバ２において実行されているプリケーションＡＰ４に対して行われることになる。
上述したように、本実形態における書き換えは、稼働系のサーバ１が正常に動作していない場合、このサーバ１における業務アプリケーションの稼働状態によらず、スプリットブレーンとなると強制的に業務アプリケーションの切り替えを行い、サーバ１が正常に動作している場合、サーバ１において障害のある業務アプリケーションのみ、待機系のサーバ２への切り替えが行われることになる。
【００３７】
すなわち、本実施形態によれば、従来のように高価なシステム情報管理テーブル共有ディスクを設けなくとも、各アプリケーションに対するＩＣＭＰのエコーパケットの送信、及び他のサーバに対してネットワークからのログインによるアプリケーションのチェックにより、スプリットブレーンとなった場合に、ハートビートを行う監視用専用接続のネットワークの通信障害により、ハートビートが行えなくなった他のサーバにおいて、障害のある業務アプリケーションを容易に検出することが可能となり、従来例に比較して安価なクラスタシステムを構成することができる。
【００３８】
なお、図１におけるサーバ１（あるいはサーバ２）それぞれの各部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより障害の発生しているアプリケーションの検出処理及びアプリケーションの切り替え処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータシステム」は、ホームページ提供環境（あるいは表示環境）を備えたＷＷＷシステムも含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。
【００３９】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【図面の簡単な説明】
【００４０】
【図１】本発明の一実施形態によるクラスタシステムの構成例を示すブロックズである。
【図２】図１のルータ３０に記憶されているＡＲＰテーブルの構成例を示す概念図である。
【図３】図１の記憶部１５（あるいは記憶部２５）に記憶されている対応テーブルの構成例を示す概念図である。
【図４】図１のクラスタシステムにおけるアプリケーションの切り替えの動作例を説明するフローチャートである。
【図５】図１のクラスタシステムにおけるアプリケーションの切り替えの動作例を説明するフローチャートである。
【図６】図１のクラスタシステムにおけるアプリケーションの切り替えの動作例を説明するフローチャートである。
【符号の説明】
【００４１】
１１，２１…ハートビート監視部
１２，２２…業務アプリケーション制御部
１３，２３…業務アプリケーション切り替え部
１４，２４…インターフェース
１５，２５…記憶部
３０…ルータ
１００…ネットワーク
１２１，２２１…監視部
１２２，２２２…制御部
【図１】
2010103695.tif 000003
【図２】
2010103695.tif 000004
【図３】
2010103695.tif 000005
【図４】
2010103695.tif 000006
【図５】
2010103695.tif 000007
【図６】
2010103695.tif 000008