クラスタシステム
【課題】既存のアプリケーションを変更することなく、ホットスタンバイを簡便に実現する。
【解決手段】アプリケーションを実行するＡＰ実行部１３、２３と、クライアント端末ＣとＡＰ実行部との間のデータの転送を制御する転送部１２、２２と、ＡＰ実行部と記憶装置Ｄとの間のデータのＩ／Ｏを制御するＩ／Ｏ部１４、２４と、各部のステータスを制御する制御部１１、２１とを備え、正常動作時に、制御部１１は、ＡＰ実行部１３、転送部１２およびＩ／Ｏ部１３のステータスを全てアクティブに設定し、制御部２１は、ＡＰ実行部２３のステータスをアクティブに、転送部２２およびＩ／Ｏ部２４のステータスをスタンバイに設定し、障害発生時に、制御部１１は、転送部１２およびＩ／Ｏ部１４のステータスをスタンバイに切り替え、制御部２１は、転送部２２およびＩ／Ｏ部２４のステータスをアクティブに切り替える。
【解決手段】アプリケーションを実行するＡＰ実行部１３、２３と、クライアント端末ＣとＡＰ実行部との間のデータの転送を制御する転送部１２、２２と、ＡＰ実行部と記憶装置Ｄとの間のデータのＩ／Ｏを制御するＩ／Ｏ部１４、２４と、各部のステータスを制御する制御部１１、２１とを備え、正常動作時に、制御部１１は、ＡＰ実行部１３、転送部１２およびＩ／Ｏ部１３のステータスを全てアクティブに設定し、制御部２１は、ＡＰ実行部２３のステータスをアクティブに、転送部２２およびＩ／Ｏ部２４のステータスをスタンバイに設定し、障害発生時に、制御部１１は、転送部１２およびＩ／Ｏ部１４のステータスをスタンバイに切り替え、制御部２１は、転送部２２およびＩ／Ｏ部２４のステータスをアクティブに切り替える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスタシステムに関する。
【背景技術】
【０００２】
従来のクラスタシステムは、障害発生時にサーバを切り替える（フェイルオーバ）場合、それまで稼働系であったサーバでリソースを順次停止させ、待機系であったサーバでサービスを起動させてから、フェイルオーバするのが一般的である。リソースとは、サービスの提供に必要なハードウェアエンティティや、ソフトウェアエンティティのことをいう。このようなクラスタシステムでは、アプリケーションの停止・起動や外部装置（主に、ストレージ）の切り替えに多くの時間を費やすため、フェイルオーバに要する時間が長くなり、その結果、サービスの可用性が低下してしまう。
【０００３】
下記特許文献１には、電文処理を通信プロセス、トランザクションプロセスおよびファイルプロセスに分割し、プロセスごとに稼働系用プロセスと待機系プロセスとを設けることで、障害発生時のサーバの切り替え時間を短縮する技術が開示されている。下記特許文献２には、ユーザ端末からの信号を処理するホットスタンバイの技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平０８−６９１０号公報
【特許文献２】特開２００７−１８８１１９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した特許文献１および特許文献２では、稼働系と待機系とのアプリケーション間の同期については何も考慮されていない。したがって、これらの従来技術では、クラスタシステムに既存のアプリケーションを適用する場合、アプリケーションに変更を加える必要があり、システム構築に手間がかかる。
【０００６】
本発明は、上述した課題を解決するためになされたものであり、既存のアプリケーションを変更することなく、ホットスタンバイを簡便に実現することができるクラスタシステムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明のクラスタシステムは、クライアント端末と記憶装置との間のデータのやり取りを制御する第１サーバ装置および第２サーバ装置を有するクラスタシステムであって、前記第１サーバ装置および前記第２サーバ装置は、アプリケーションを実行するアプリケーション実行部と、前記クライアント端末と前記アプリケーション実行部との間のデータの転送を制御する転送制御部と、前記アプリケーション実行部と前記記憶装置との間のデータの入出力を制御する入出力制御部と、前記アプリケーション実行部、前記転送制御部および前記入出力制御部におけるアクティブ／スタンバイのいずれかのステータスをそれぞれ制御するステータス制御部と、をそれぞれ備え、
前記転送制御部は、前記ステータスがアクティブであり、かつ、前記クライアント端末から処理要求を受信した場合には、当該処理要求を、同一サーバ装置の前記アプリケーション実行部、および前記ステータスがスタンバイである前記転送制御部に、それぞれ転送し、前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から処理結果を受信した場合には、当該処理結果を前記クライアント端末に転送し、
前記入出力制御部は、前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から前記記憶装置への入出力要求を受信した場合には、当該入出力要求に基づいて前記記憶装置への入出力を実行し、当該入出力の実行結果を、前記入出力要求の送信元である前記アプリケーション実行部、および前記ステータスがスタンバイである前記入出力制御部に、それぞれ送信し、
前記ステータス制御部は、クラスタシステムを動作させる場合には、前記第１サーバ装置および前記第２サーバ装置のいずれか一方のサーバ装置の前記アプリケーション実行部、前記転送制御部および前記入出力制御部の前記ステータスを全てアクティブに設定し、他方のサーバ装置の前記アプリケーション実行部の前記ステータスをアクティブに、前記転送制御部および前記入出力制御部の前記ステータスをスタンバイに設定し、障害が検知された場合には、前記第１サーバ装置および前記第２サーバ装置の前記転送制御部および前記入出力制御部の前記ステータスを、アクティブからスタンバイに、またはスタンバイからアクティブにそれぞれ切り替える。
【発明の効果】
【０００８】
本発明によれば、既存のアプリケーションを変更することなく、ホットスタンバイを簡便に実現することができる。
【図面の簡単な説明】
【０００９】
【図１】各実施形態におけるクラスタシステムの構成を例示するブロック図である。
【図２】クラスタシステムの動作を説明するための模式図である。
【図３】転送部が処理要求を受信した際の動作を説明するためのフローチャートである。
【図４】Ｉ／Ｏ部がＩ／Ｏ要求を受信した際の動作を説明するためのフローチャートである。
【図５】転送部が処理結果を受信した際の動作を説明するためのフローチャートである。
【図６】障害発生時の稼働系サーバ装置の動作を説明するためのフローチャートである。
【図７】障害検知時の待機系サーバ装置の動作を説明するためのフローチャートである。
【図８】第２実施形態におけるクラスタシステムでＡＰ障害が発生した際の動作を説明するためのフローチャートである。
【発明を実施するための形態】
【００１０】
以下、添付図面を参照して、本発明に係るクラスタシステムの好適な実施形態について説明する。
【００１１】
[第１実施形態]
まず、図１を参照して、第１実施形態におけるクラスタシステムの構成について説明する。図１に示すように、クラスタシステム１は、クライアント端末Ｃによるオンライントランザクション処理を制御するサーバ装置１０、２０を、クラスタ化して構成する。オンライントランザクション処理は、クライアント端末Ｃからの処理要求に基づき、ストレージ等の記憶装置Ｄにアクセスしながらデータを処理し、処理結果をクライアント端末Ｃに送り返す処理である。
【００１２】
サーバ装置１０、２０は、それぞれ同一の構成要素を有し、いずれか一方が稼働系として動作し、他方が待機系として動作する。稼働系／待機系の初期設定は、例えば、クラスタシステム内のネットワークインターフェースの状態を監視し、仮想ＩＰアドレスが割り振られているサーバ装置を稼働系に設定し、他方のサーバ装置を待機系に設定することで実現できる。本実施形態では、原則としてサーバ装置１０を稼働系とし、サーバ装置２０を待機系として説明する。
【００１３】
ここで、サーバ装置１０、２０は、物理的には、例えば、ＣＰＵ（Central Processing Unit）と、メモリと、入出力インターフェースと、をそれぞれ含んで構成される。メモリには、例えば、ＣＰＵで処理されるプログラムやデータを記憶するＲＯＭ（Read Only Memory）やＨＤＤ（Hard Disk Drive）と、主として制御処理のための各種作業領域として使用されるＲＡＭ（Random Access Memory）とが含まれる。これらの要素は、互いにバスを介して接続されている。ＣＰＵが、ＲＯＭに記憶されたプログラムを実行し、入出力インターフェースを介して受信されたメッセージや、ＲＡＭに展開されたデータを処理することで、後述するサーバ装置１０、２０における各部の機能を実現することができる。
【００１４】
サーバ装置１０、２０は、機能的には、例えば、制御部１１、２１と、転送部１２、２２と、ＡＰ（Application）実行部１３、２３と、Ｉ／Ｏ（Input/Output）部１４、２４と、をそれぞれ有する。
【００１５】
制御部１１、２１は、サーバ装置１０、２０全体を統括制御する。以下に、制御部１１、２１による統括制御の一例を説明する。
【００１６】
制御部１１、２１は、転送部１２、２２、ＡＰ実行部１３、２３およびＩ／Ｏ部１４、２４のステータスをそれぞれ制御する。本実施形態では、ステータスとして、“アクティブ”または“スタンバイ”を設定した場合について説明する。“アクティブ”ステータスは、実処理を行うステータスである。“スタンバイ”ステータスは、実処理を行わずに、ダミーとして動作するステータスである。
【００１７】
制御部１１、２１は、クラスタシステム１が正常に動作している間は、サーバ装置１０の転送部１２、ＡＰ実行部１３およびＩ／Ｏ部１４の各ステータスを全てアクティブに設定し、サーバ装置２０の転送部２２およびＩ／Ｏ部２４の各ステータスをそれぞれスタンバイに設定し、サーバ装置２０のＡＰ実行部２３のステータスをアクティブに設定する。
【００１８】
制御部１１、２１は、クラスタシステム１において障害が検知された場合には、サーバ装置１０の転送部１２およびＩ／Ｏ部１４の各ステータスをそれぞれアクティブからスタンバイに切り替え、サーバ装置２０の転送部２２およびＩ／Ｏ部２４の各ステータスをそれぞれスタンバイからアクティブに切り替える。これにより、サーバ装置２０が稼働系となり、サーバ装置１０が待機系となる。
【００１９】
転送部１２、２２は、クライアント端末ＣからＡＰ実行部１３、２３への処理要求の転送と、ＡＰ実行部１３、２３からクライアント端末Ｃへの処理結果の転送と、をそれぞれ行う。
【００２０】
転送部１２、２２は、ステータスがアクティブであり、かつ、クライアント端末Ｃから処理要求を受信した場合には、この処理要求を、同一サーバ装置内のＡＰ実行部と、ステータスがスタンバイである他方のサーバ装置内の転送部と、にそれぞれ転送する。
【００２１】
転送部１２、２２は、ステータスがスタンバイであり、かつ、他方のサーバ装置内のＡＰ実行部から処理要求を受信した場合には、この処理要求を、同一サーバ装置内のＡＰ実行部に転送する。
【００２２】
転送部１２、２２は、ステータスがアクティブであり、かつ、ＡＰ実行部１３、２３から処理結果を受信した場合には、この処理結果をクライアント端末Ｃに転送する。
【００２３】
転送部１２、２２は、ステータスがスタンバイであり、かつ、ＡＰ実行部１３、２３から処理結果を受信した場合には、この処理結果をクライアント端末Ｃに転送せずに、保持する。
【００２４】
転送部１２、２２は、ステータスがアクティブであり、かつ、自サーバ装置とクライアント端末Ｃとの間のパスで障害が発生した場合には、ステータスがスタンバイである他方のサーバ装置内の転送部が保持している処理結果をクライアント端末Ｃに転送するように依頼する処理結果転送依頼を、他方のサーバ装置内の転送部に送信する。転送部１２、２２は、処理結果転送依頼を受信した場合には、保持中の処理結果をクライアント端末Ｃに転送する。
【００２５】
ＡＰ実行部１３、２３は、サービスを提供するアプリケーションを実行する。
【００２６】
Ｉ／Ｏ部１４、２４は、ＡＰ実行部１３、２３による記憶装置Ｄからのデータの読み込みと、ＡＰ実行部１３、２３による記憶装置Ｄへのデータの書き込みと、をそれぞれ行う。
【００２７】
Ｉ／Ｏ部１４、２４は、ステータスがアクティブであり、かつ、ＡＰ実行部１３、２３から記憶装置ＤへのＩ／Ｏ要求を受信した場合には、このＩ／Ｏ要求に基づいて記憶装置ＤへのＩ／Ｏを実行し、このＩ／Ｏの実行結果を、Ｉ／Ｏ要求の送信元である同一サーバ装置内のＡＰ実行部と、ステータスがスタンバイである他方のサーバ装置内のＩ／Ｏ部とに、それぞれ送信する。
【００２８】
Ｉ／Ｏ部１４、２４は、ステータスがスタンバイであり、かつ、ＡＰ実行部１３、２３から記憶装置ＤへのＩ／Ｏ要求を受信した場合には、このＩ／Ｏ要求を実行せずに、保持する。
【００２９】
Ｉ／Ｏ部１４、２４は、ステータスがアクティブであり、かつ、自サーバ装置と記憶装置Ｄとの間のパスで障害が発生した場合には、ステータスがスタンバイである他方のサーバ装置内のＩ／Ｏ部が保持しているＩ／Ｏ要求を実行するように依頼するＩ／Ｏ実行依頼を、他方のサーバ装置内のＩ／Ｏ部に送信する。
【００３０】
Ｉ／Ｏ部１４、２４は、Ｉ／Ｏ実行依頼を受信した場合には、保持中のＩ／Ｏ要求を実行し、このＩ／Ｏの実行結果を、同一サーバ装置内のＡＰ実行部に返信する。
【００３１】
このように、サーバ装置１０、２０を構成することで、稼働系のサーバ装置と待機系のサーバ装置とにおいてアプリケーションを同期させながら動作させることができる。これにより、アプリケーションを変更することなく、ホットスタンバイのクラスタシステムを実現することができる。
【００３２】
次に、図２〜図７を参照して、第１実施形態におけるクラスタシステムの動作について説明する。以下においては、サーバ装置１０が稼働系として動作し、サーバ装置２０が待機系として動作している場合について説明する。この場合、図２に示すように、稼働系サーバ装置１０の転送部１２、ＡＰ実行部１３およびＩ／Ｏ部１４の各ステータスは全てアクティブとなり、待機系サーバ装置２０の転送部２２およびＩ／Ｏ部２４の各ステータスはそれぞれスタンバイとなり、待機系サーバ装置２０のＡＰ実行部２３のステータスはアクティブとなる。
【００３３】
まず、図２および図３を参照して、転送部１２、２２が処理要求を受信した際の動作について説明する。
【００３４】
最初に、稼働系サーバ装置１０の転送部１２がクライアント端末Ｃから処理要求を受信する（ステップＳ１０１）。
【００３５】
続いて、転送部１２は、ステータスがアクティブである（ステップＳ１０２；ＹＥＳ）ため、受信した処理要求を、ステータスがスタンバイである待機系サーバ装置２０の転送部２２に転送する（ステップＳ１０３）。
【００３６】
続いて、稼働系サーバ装置１０の転送部１２は、自サーバ装置１０のＡＰ実行部１３のステータスがアクティブである（ステップＳ１０４；ＹＥＳ）ため、受信した処理要求を、ＡＰ実行部１３に転送する（ステップＳ１０５）。
【００３７】
一方、待機系サーバ装置２０の転送部２２がクライアント端末Ｃから処理要求を受信した場合（ステップＳ１０１）に、転送部２２は、ステータスがスタンバイであり（ステップＳ１０２；ＮＯ）、自サーバ装置２０のＡＰ実行部２３のステータスがアクティブである（ステップＳ１０４；ＹＥＳ）ため、上記ステップＳ１０３で稼働系サーバ装置１０の転送部１２から転送された処理要求を、ＡＰ実行部２３に転送する（ステップＳ１０５）。
【００３８】
次に、図２および図４を参照して、Ｉ／Ｏ部１４、２２がＩ／Ｏ要求を受信した際の動作について説明する。
【００３９】
最初に、稼働系サーバ装置１０のＩ／Ｏ部１４が自サーバ装置１０のＡＰ実行部１３からＩ／Ｏ要求を受信する（ステップＳ２０１）。
【００４０】
続いて、Ｉ／Ｏ部１４は、ステータスがアクティブである（ステップＳ２０２；ＹＥＳ）ため、受信したＩ／Ｏ要求を実行する（ステップＳ２０４）。
【００４１】
続いて、Ｉ／Ｏ部１４は、上記ステップＳ２０４におけるＩ／Ｏ実行結果をＡＰ実行部１３に返信する（ステップＳ２０５）とともに、このＩ／Ｏ実行結果をステータスがスタンバイである待機系サーバ装置２０のＩ／Ｏ部２４に転送する（ステップＳ２０６）。
【００４２】
一方、待機系サーバ装置２０のＩ／Ｏ部２４が自サーバ装置２０のＡＰ実行部２３からＩ／Ｏ要求を受信した場合（ステップＳ２０１）に、Ｉ／Ｏ部２４は、ステータスがスタンバイである（ステップＳ２０２；ＮＯ）ため、受信したＩ／Ｏ要求を実行せずに保持する（ステップＳ２０３）。
【００４３】
続いて、Ｉ／Ｏ部２４は、稼働系サーバ装置１０のＩ／Ｏ部１４から受信（ステップＳ２０７）したＩ／Ｏ実行結果を、自サーバ装置２０のＡＰ実行部２３に返信する（ステップＳ２０８）。
【００４４】
次に、図２および図５を参照して、転送部１２、２２が処理結果を受信した際の動作について説明する。
【００４５】
最初に、稼働系サーバ装置１０の転送部１２が自サーバ装置１０のＡＰ実行部１３から処理結果を受信する（ステップＳ３０１）。
【００４６】
続いて、転送部１２は、ステータスがアクティブである（ステップＳ３０２；ＹＥＳ）ため、受信した処理結果をクライアント端末Ｃに転送する（ステップＳ３０３）。
【００４７】
一方、待機系サーバ装置２０の転送部２２が自サーバ装置２０のＡＰ実行部２３から処理結果を受信した場合（ステップＳ３０１）に、転送部２２は、ステータスがスタンバイである（ステップＳ３０２；ＮＯ）ため、受信した処理結果を転送せずに保持する（ステップＳ３０４）。
【００４８】
次に、図６および図７を参照して、パス障害が発生した際の動作について説明する。図６は、障害発生時の稼働系サーバ装置の動作を説明するためのフローチャートであり、図７は、障害発生時の待機系サーバ装置の動作を説明するためのフローチャートである。
【００４９】
最初に、稼働系サーバ装置１０の制御部１１が自サーバ装置１０と記憶装置Ｄとの間のパス障害を検知した場合（ステップＳ４０１）に、自サーバ装置１０のＩ／Ｏ部１４は、ステータスがスタンバイである待機系サーバ装置２０のＩ／Ｏ部２４が保持しているＩ／Ｏ要求を実行するように依頼するＩ／Ｏ実行依頼を、当該Ｉ／Ｏ部２４に送信する（ステップＳ４０２）。
【００５０】
続いて、稼働系サーバ装置１０の制御部１１は、自サーバ装置１０のＩ／Ｏ部１４および転送部１２のステータスをアクティブからスタンバイに切り替える（ステップＳ４０３）。これにより、サーバ装置１０は、稼働系から待機系となる。
【００５１】
一方、待機系サーバ装置２０のＩ／Ｏ部２４が、上記ステップＳ４０２で送信されたＩ／Ｏ実行依頼を受信した場合（ステップＳ５０１）に、Ｉ／Ｏ部２４は、保持中のＩ／Ｏ要求を実行する（ステップＳ５０２）。
【００５２】
続いて、待機系サーバ装置２０の制御部２１は、自サーバ装置２０のＩ／Ｏ部２４および転送部２２のステータスをスタンバイからアクティブに切り替える（ステップＳ５０３）。これにより、サーバ装置２０は、待機系から稼働系となる。
【００５３】
続いて、上記ステップＳ５０２で保持中のＩ／Ｏ要求を実行したＩ／Ｏ部２４は、そのＩ／Ｏ実行結果を自サーバ装置２０のＡＰ実行部２３に返信する（ステップＳ５０４）。この後、図５のステップＳ３０１以降の処理が実行され、ＡＰ実行部２３での処理結果が転送部２２からクライアント端末Ｃに転送される（ステップＳ３０３）。
【００５４】
なお、この動作例では、サーバ装置１０と記憶装置Ｄとの間でパス障害が発生した場合について説明しているが、サーバ装置１０とクライアント端末Ｃとの間でパス障害が発生した場合についても同様の概念に基づいてサーバ装置を切り替えることができる。この場合には、待機系サーバ装置２０の転送部２２が保持している処理結果を転送するように依頼する処理結果転送依頼を、当該転送部２２に送信し、処理結果転送依頼を受信した転送部２２がクライアント端末Ｃに処理結果を転送することとすればよい。
【００５５】
上述したように、第１実施形態におけるクラスタシステムによれば、転送部１２、２２、ＡＰ実行部１３、２３およびＩ／Ｏ部１４、２４のステータスをそれぞれ制御することで、アプリケーション間の同期をとることができるため、既存のアプリケーションを変更することなく、簡便にホットスタンバイのクラスタシステムを実現することができる。
【００５６】
また、各ステータスを制御することでパスを切り替えることができるため、障害発生時にリソースの再起動やサーバの切り替え時間に要する時間を削減できる。これにより、サービスの可用性を向上させることが可能となる。
【００５７】
[第２実施形態]
本発明の第２実施形態について説明する。第２実施形態におけるクラスタシステムが、上述した第１実施形態におけるクラスタシステムと相違する点は、第２実施形態におけるクラスタシステムが、アプリケーション障害（以下、「ＡＰ障害」という。）発生時の回復機能をさらに備えている点である。それ以外の構成については、第１実施形態におけるシステムの各構成と同様であるため、各構成要素には同一の符合を付し、その説明は省略するとともに、以下においては、主に第１実施形態との相違点について説明する。
【００５８】
制御部１１、２１は、ＡＰ実行部１３、２３でのＡＰ障害を検知した場合に、ＡＰ障害を発生させたＡＰ実行部１３、２３に対してアプリケーションを再起動させるとともに、ＡＰ障害を発生させたＡＰ実行部のステータスをアクティブからスタンバイに切り替える。
【００５９】
制御部１１、２１は、回復時期テーブルに設定された回復時期に基づいて、スタンバイに切り替えたＡＰ実行部のステータスをアクティブに切り替える。
【００６０】
ここで、回復時期テーブルは、ＡＰ障害発生後のＡＰ実行部の回復時期を設定するテーブルである。本実施形態では、回復時期として、“ホット”または“コールド”を予め設定した場合について説明する。
【００６１】
“ホット”は、アプリケーションの実行がメモリ内に保持されている情報に依存しない場合に設定される回復時期である。この場合には、他のサーバ装置でのアプリケーションの実行を継続したまま、障害により再起動させたアプリケーションの実行を再開させてもアプリケーション間の同期をとることができる。したがって、回復時期が“ホット”である場合には、制御部１１、２１は、即座に、スタンバイに切り替えたＡＰ実行部のステータスをスタンバイからアクティブに切り替え直し、アプリケーションの同期を再開させる。
【００６２】
“コールド”は、アプリケーションの実行がメモリ内に保持されている情報に依存する場合に設定される回復時期である。この場合には、全てのサーバ装置でアプリケーションの実行を停止させてから、アプリケーションの実行を再開させなければアプリケーション間の同期をとることができない。したがって、回復時期が“コールド”である場合に、制御部１１、２１は、全てのＡＰ実行部がスタンバイに切り替わった後に、全てのＡＰ実行部のステータスをスタンバイからアクティブに切り替え直し、アプリケーションの同期を再開させる。
【００６３】
次に、図８を参照して、第２実施形態におけるクラスタシステムでＡＰ障害が発生した際の動作について説明する。この動作例では、サーバ装置１０のアプリケーションでＡＰ障害が発生した場合について説明する。
【００６４】
最初に、サーバ装置１０の制御部１１が、ＡＰ実行部１３でのＡＰ障害を検知した場合（ステップＳ６０１）に、ＡＰ実行部１３は、アプリケーションを再起動する（ステップＳ６０２）。
【００６５】
続いて、サーバ装置１０の制御部１１は、ＡＰ実行部１３のステータスをアクティブからスタンバイに切り替える（ステップＳ６０３）。
【００６６】
続いて、サーバ装置１０の制御部１１は、回復時期テーブルを参照し、回復時期が“ホット”であるか否かを判定する（ステップＳ６０４）。この判定がＹＥＳである場合（ステップＳ６０４；ＹＥＳ）に、制御部１１は、ＡＰ実行部１３のステータスをスタンバイからアクティブに切り替える（ステップＳ６０５）。
【００６７】
一方、上記ステップＳ６０４の判定で回復時期が“コールド”であると判定された場合（ステップＳ６０４；ＮＯ）に、制御部１１は、他サーバ装置１０のＡＰ実行部２３のステータスがスタンバイであるか否かを判定する（ステップＳ６０６）。この判定がＮＯである場合（ステップＳ６０６；ＮＯ）に、制御部１１は、この判定がＹＥＳになるまで判定を繰り返す。
【００６８】
一方、上記ステップＳ６０６の判定で他サーバ装置１０のＡＰ実行部２３のステータスがスタンバイであると判定された場合（ステップＳ６０６；ＹＥＳ）に、制御部１１、２１は、ＡＰ実行部１３、２３のステータスをそれぞれスタンバイからアクティブに切り替える（ステップＳ６０７）。
【００６９】
上述したように、第２実施形態におけるクラスタシステムによれば、再同期のタイミングを設定することができるため、ＡＰ障害が発生した場合であっても、ＡＰ実行部１３とＡＰ実行部２３とのアプリケーション間の同期を保持しつつ、アプリケーションの回復を図ることができる。
【００７０】
なお、上述した各実施形態は、単なる例示に過ぎず、各実施形態に明示していない種々の変形や技術の適用を排除するものではない。すなわち、本発明は、その趣旨を逸脱しない範囲で様々な形態に変形して実施することができる。
【００７１】
例えば、上記の各実施形態の一部または全部は、以下の付記のようにも記載され得る。ただし、本発明を以下に限定するものではない。
【００７２】
（付記１） クライアント端末と記憶装置との間のデータのやり取りを制御する第１サーバ装置および第２サーバ装置を有するクラスタシステムであって、前記第１サーバ装置および前記第２サーバ装置は、アプリケーションを実行するアプリケーション実行部と、前記クライアント端末と前記アプリケーション実行部との間のデータの転送を制御する転送制御部と、前記アプリケーション実行部と前記記憶装置との間のデータの入出力を制御する入出力制御部と、前記アプリケーション実行部、前記転送制御部および前記入出力制御部におけるアクティブ／スタンバイのいずれかのステータスをそれぞれ制御するステータス制御部と、をそれぞれ備え、
前記転送制御部は、前記ステータスがアクティブであり、かつ、前記クライアント端末から処理要求を受信した場合には、当該処理要求を、同一サーバ装置の前記アプリケーション実行部、および前記ステータスがスタンバイである前記転送制御部に、それぞれ転送し、前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から処理結果を受信した場合には、当該処理結果を前記クライアント端末に転送し、
前記入出力制御部は、前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から前記記憶装置への入出力要求を受信した場合には、当該入出力要求に基づいて前記記憶装置への入出力を実行し、当該入出力の実行結果を、前記入出力要求の送信元である前記アプリケーション実行部、および前記ステータスがスタンバイである前記入出力制御部に、それぞれ送信し、
前記ステータス制御部は、クラスタシステムを動作させる場合には、前記第１サーバ装置および前記第２サーバ装置のいずれか一方のサーバ装置の前記アプリケーション実行部、前記転送制御部および前記入出力制御部の前記ステータスを全てアクティブに設定し、他方のサーバ装置の前記アプリケーション実行部の前記ステータスをアクティブに、前記転送制御部および前記入出力制御部の前記ステータスをスタンバイに設定し、障害が検知された場合には、前記第１サーバ装置および前記第２サーバ装置の前記転送制御部および前記入出力制御部の前記ステータスを、アクティブからスタンバイに、またはスタンバイからアクティブにそれぞれ切り替える、ことを特徴とするクラスタシステム。
【００７３】
（付記２） 前記転送制御部は、前記ステータスがスタンバイであり、かつ、他方のサーバ装置の前記アプリケーション実行部から処理要求を受信した場合には、当該処理要求を、同一サーバ装置の前記アプリケーション実行部に転送することを特徴とする付記１記載のクラスタシステム。
【００７４】
（付記３） 前記転送制御部は、前記ステータスがスタンバイであり、かつ、前記アプリケーション実行部から処理結果を受信した場合には、当該処理結果を前記クライアント端末に転送せずに、保持することを特徴とする付記１または２記載のクラスタシステム。
【００７５】
（付記４） 前記転送制御部は、前記ステータスがアクティブであり、かつ、前記クライアント端末との間のパスで障害が発生した場合には、前記ステータスがスタンバイである他方のサーバ装置の前記転送制御部が保持している前記処理結果を前記クライアント端末に転送するように依頼する処理結果転送依頼を、他方のサーバ装置の前記転送制御部に送信し、前記処理結果転送依頼を受信した場合には、保持中の前記処理結果を前記クライアント端末に転送する、ことを特徴とする付記３記載のクラスタシステム。
【００７６】
（付記５） 前記入出力制御部は、前記ステータスがスタンバイであり、かつ、前記アプリケーション実行部から前記記憶装置への入出力要求を受信した場合には、当該入出力要求を実行せずに、保持することを特徴とする付記１〜４のいずれか１項に記載のクラスタシステム。
【００７７】
（付記６） 前記入出力制御部は、前記ステータスがアクティブであり、かつ、前記記憶装置との間のパスで障害が発生した場合には、前記ステータスがスタンバイである他方のサーバ装置の前記入出力制御部が保持している前記入出力要求を実行するように依頼する入出力実行依頼を、他方のサーバ装置の前記入出力制御部に送信し、前記入出力実行依頼を受信した場合には、保持中の前記入出力要求を実行し、当該入出力の実行結果を、同一サーバ装置の前記アプリケーション実行部に返信する、ことを特徴とする付記５記載のクラスタシステム。
【００７８】
（付記７） 前記アプリケーション実行部は、アプリケーション障害が発生した場合に、前記アプリケーションを再起動し、前記ステータス制御部は、前記アプリケーション障害を発生させた前記アプリケーション実行部の前記ステータスをアクティブからスタンバイに切り替え、予め設定された回復時期に応じて、スタンバイに切り替えた前記アプリケーション実行部のステータスをアクティブに切り替え直す、ことを特徴とする付記１〜６のいずれか１項に記載のクラスタシステム。
【符号の説明】
【００７９】
１…クラスタシステム、１０、２０…サーバ装置、１１、２１…制御部、１２、２２…転送部、１３、２３…ＡＰ実行部、１４、２４…Ｉ／Ｏ部、Ｃ…クライアント端末、Ｄ…記憶装置。
【技術分野】
【０００１】
本発明は、クラスタシステムに関する。
【背景技術】
【０００２】
従来のクラスタシステムは、障害発生時にサーバを切り替える（フェイルオーバ）場合、それまで稼働系であったサーバでリソースを順次停止させ、待機系であったサーバでサービスを起動させてから、フェイルオーバするのが一般的である。リソースとは、サービスの提供に必要なハードウェアエンティティや、ソフトウェアエンティティのことをいう。このようなクラスタシステムでは、アプリケーションの停止・起動や外部装置（主に、ストレージ）の切り替えに多くの時間を費やすため、フェイルオーバに要する時間が長くなり、その結果、サービスの可用性が低下してしまう。
【０００３】
下記特許文献１には、電文処理を通信プロセス、トランザクションプロセスおよびファイルプロセスに分割し、プロセスごとに稼働系用プロセスと待機系プロセスとを設けることで、障害発生時のサーバの切り替え時間を短縮する技術が開示されている。下記特許文献２には、ユーザ端末からの信号を処理するホットスタンバイの技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平０８−６９１０号公報
【特許文献２】特開２００７−１８８１１９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述した特許文献１および特許文献２では、稼働系と待機系とのアプリケーション間の同期については何も考慮されていない。したがって、これらの従来技術では、クラスタシステムに既存のアプリケーションを適用する場合、アプリケーションに変更を加える必要があり、システム構築に手間がかかる。
【０００６】
本発明は、上述した課題を解決するためになされたものであり、既存のアプリケーションを変更することなく、ホットスタンバイを簡便に実現することができるクラスタシステムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明のクラスタシステムは、クライアント端末と記憶装置との間のデータのやり取りを制御する第１サーバ装置および第２サーバ装置を有するクラスタシステムであって、前記第１サーバ装置および前記第２サーバ装置は、アプリケーションを実行するアプリケーション実行部と、前記クライアント端末と前記アプリケーション実行部との間のデータの転送を制御する転送制御部と、前記アプリケーション実行部と前記記憶装置との間のデータの入出力を制御する入出力制御部と、前記アプリケーション実行部、前記転送制御部および前記入出力制御部におけるアクティブ／スタンバイのいずれかのステータスをそれぞれ制御するステータス制御部と、をそれぞれ備え、
前記転送制御部は、前記ステータスがアクティブであり、かつ、前記クライアント端末から処理要求を受信した場合には、当該処理要求を、同一サーバ装置の前記アプリケーション実行部、および前記ステータスがスタンバイである前記転送制御部に、それぞれ転送し、前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から処理結果を受信した場合には、当該処理結果を前記クライアント端末に転送し、
前記入出力制御部は、前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から前記記憶装置への入出力要求を受信した場合には、当該入出力要求に基づいて前記記憶装置への入出力を実行し、当該入出力の実行結果を、前記入出力要求の送信元である前記アプリケーション実行部、および前記ステータスがスタンバイである前記入出力制御部に、それぞれ送信し、
前記ステータス制御部は、クラスタシステムを動作させる場合には、前記第１サーバ装置および前記第２サーバ装置のいずれか一方のサーバ装置の前記アプリケーション実行部、前記転送制御部および前記入出力制御部の前記ステータスを全てアクティブに設定し、他方のサーバ装置の前記アプリケーション実行部の前記ステータスをアクティブに、前記転送制御部および前記入出力制御部の前記ステータスをスタンバイに設定し、障害が検知された場合には、前記第１サーバ装置および前記第２サーバ装置の前記転送制御部および前記入出力制御部の前記ステータスを、アクティブからスタンバイに、またはスタンバイからアクティブにそれぞれ切り替える。
【発明の効果】
【０００８】
本発明によれば、既存のアプリケーションを変更することなく、ホットスタンバイを簡便に実現することができる。
【図面の簡単な説明】
【０００９】
【図１】各実施形態におけるクラスタシステムの構成を例示するブロック図である。
【図２】クラスタシステムの動作を説明するための模式図である。
【図３】転送部が処理要求を受信した際の動作を説明するためのフローチャートである。
【図４】Ｉ／Ｏ部がＩ／Ｏ要求を受信した際の動作を説明するためのフローチャートである。
【図５】転送部が処理結果を受信した際の動作を説明するためのフローチャートである。
【図６】障害発生時の稼働系サーバ装置の動作を説明するためのフローチャートである。
【図７】障害検知時の待機系サーバ装置の動作を説明するためのフローチャートである。
【図８】第２実施形態におけるクラスタシステムでＡＰ障害が発生した際の動作を説明するためのフローチャートである。
【発明を実施するための形態】
【００１０】
以下、添付図面を参照して、本発明に係るクラスタシステムの好適な実施形態について説明する。
【００１１】
[第１実施形態]
まず、図１を参照して、第１実施形態におけるクラスタシステムの構成について説明する。図１に示すように、クラスタシステム１は、クライアント端末Ｃによるオンライントランザクション処理を制御するサーバ装置１０、２０を、クラスタ化して構成する。オンライントランザクション処理は、クライアント端末Ｃからの処理要求に基づき、ストレージ等の記憶装置Ｄにアクセスしながらデータを処理し、処理結果をクライアント端末Ｃに送り返す処理である。
【００１２】
サーバ装置１０、２０は、それぞれ同一の構成要素を有し、いずれか一方が稼働系として動作し、他方が待機系として動作する。稼働系／待機系の初期設定は、例えば、クラスタシステム内のネットワークインターフェースの状態を監視し、仮想ＩＰアドレスが割り振られているサーバ装置を稼働系に設定し、他方のサーバ装置を待機系に設定することで実現できる。本実施形態では、原則としてサーバ装置１０を稼働系とし、サーバ装置２０を待機系として説明する。
【００１３】
ここで、サーバ装置１０、２０は、物理的には、例えば、ＣＰＵ（Central Processing Unit）と、メモリと、入出力インターフェースと、をそれぞれ含んで構成される。メモリには、例えば、ＣＰＵで処理されるプログラムやデータを記憶するＲＯＭ（Read Only Memory）やＨＤＤ（Hard Disk Drive）と、主として制御処理のための各種作業領域として使用されるＲＡＭ（Random Access Memory）とが含まれる。これらの要素は、互いにバスを介して接続されている。ＣＰＵが、ＲＯＭに記憶されたプログラムを実行し、入出力インターフェースを介して受信されたメッセージや、ＲＡＭに展開されたデータを処理することで、後述するサーバ装置１０、２０における各部の機能を実現することができる。
【００１４】
サーバ装置１０、２０は、機能的には、例えば、制御部１１、２１と、転送部１２、２２と、ＡＰ（Application）実行部１３、２３と、Ｉ／Ｏ（Input/Output）部１４、２４と、をそれぞれ有する。
【００１５】
制御部１１、２１は、サーバ装置１０、２０全体を統括制御する。以下に、制御部１１、２１による統括制御の一例を説明する。
【００１６】
制御部１１、２１は、転送部１２、２２、ＡＰ実行部１３、２３およびＩ／Ｏ部１４、２４のステータスをそれぞれ制御する。本実施形態では、ステータスとして、“アクティブ”または“スタンバイ”を設定した場合について説明する。“アクティブ”ステータスは、実処理を行うステータスである。“スタンバイ”ステータスは、実処理を行わずに、ダミーとして動作するステータスである。
【００１７】
制御部１１、２１は、クラスタシステム１が正常に動作している間は、サーバ装置１０の転送部１２、ＡＰ実行部１３およびＩ／Ｏ部１４の各ステータスを全てアクティブに設定し、サーバ装置２０の転送部２２およびＩ／Ｏ部２４の各ステータスをそれぞれスタンバイに設定し、サーバ装置２０のＡＰ実行部２３のステータスをアクティブに設定する。
【００１８】
制御部１１、２１は、クラスタシステム１において障害が検知された場合には、サーバ装置１０の転送部１２およびＩ／Ｏ部１４の各ステータスをそれぞれアクティブからスタンバイに切り替え、サーバ装置２０の転送部２２およびＩ／Ｏ部２４の各ステータスをそれぞれスタンバイからアクティブに切り替える。これにより、サーバ装置２０が稼働系となり、サーバ装置１０が待機系となる。
【００１９】
転送部１２、２２は、クライアント端末ＣからＡＰ実行部１３、２３への処理要求の転送と、ＡＰ実行部１３、２３からクライアント端末Ｃへの処理結果の転送と、をそれぞれ行う。
【００２０】
転送部１２、２２は、ステータスがアクティブであり、かつ、クライアント端末Ｃから処理要求を受信した場合には、この処理要求を、同一サーバ装置内のＡＰ実行部と、ステータスがスタンバイである他方のサーバ装置内の転送部と、にそれぞれ転送する。
【００２１】
転送部１２、２２は、ステータスがスタンバイであり、かつ、他方のサーバ装置内のＡＰ実行部から処理要求を受信した場合には、この処理要求を、同一サーバ装置内のＡＰ実行部に転送する。
【００２２】
転送部１２、２２は、ステータスがアクティブであり、かつ、ＡＰ実行部１３、２３から処理結果を受信した場合には、この処理結果をクライアント端末Ｃに転送する。
【００２３】
転送部１２、２２は、ステータスがスタンバイであり、かつ、ＡＰ実行部１３、２３から処理結果を受信した場合には、この処理結果をクライアント端末Ｃに転送せずに、保持する。
【００２４】
転送部１２、２２は、ステータスがアクティブであり、かつ、自サーバ装置とクライアント端末Ｃとの間のパスで障害が発生した場合には、ステータスがスタンバイである他方のサーバ装置内の転送部が保持している処理結果をクライアント端末Ｃに転送するように依頼する処理結果転送依頼を、他方のサーバ装置内の転送部に送信する。転送部１２、２２は、処理結果転送依頼を受信した場合には、保持中の処理結果をクライアント端末Ｃに転送する。
【００２５】
ＡＰ実行部１３、２３は、サービスを提供するアプリケーションを実行する。
【００２６】
Ｉ／Ｏ部１４、２４は、ＡＰ実行部１３、２３による記憶装置Ｄからのデータの読み込みと、ＡＰ実行部１３、２３による記憶装置Ｄへのデータの書き込みと、をそれぞれ行う。
【００２７】
Ｉ／Ｏ部１４、２４は、ステータスがアクティブであり、かつ、ＡＰ実行部１３、２３から記憶装置ＤへのＩ／Ｏ要求を受信した場合には、このＩ／Ｏ要求に基づいて記憶装置ＤへのＩ／Ｏを実行し、このＩ／Ｏの実行結果を、Ｉ／Ｏ要求の送信元である同一サーバ装置内のＡＰ実行部と、ステータスがスタンバイである他方のサーバ装置内のＩ／Ｏ部とに、それぞれ送信する。
【００２８】
Ｉ／Ｏ部１４、２４は、ステータスがスタンバイであり、かつ、ＡＰ実行部１３、２３から記憶装置ＤへのＩ／Ｏ要求を受信した場合には、このＩ／Ｏ要求を実行せずに、保持する。
【００２９】
Ｉ／Ｏ部１４、２４は、ステータスがアクティブであり、かつ、自サーバ装置と記憶装置Ｄとの間のパスで障害が発生した場合には、ステータスがスタンバイである他方のサーバ装置内のＩ／Ｏ部が保持しているＩ／Ｏ要求を実行するように依頼するＩ／Ｏ実行依頼を、他方のサーバ装置内のＩ／Ｏ部に送信する。
【００３０】
Ｉ／Ｏ部１４、２４は、Ｉ／Ｏ実行依頼を受信した場合には、保持中のＩ／Ｏ要求を実行し、このＩ／Ｏの実行結果を、同一サーバ装置内のＡＰ実行部に返信する。
【００３１】
このように、サーバ装置１０、２０を構成することで、稼働系のサーバ装置と待機系のサーバ装置とにおいてアプリケーションを同期させながら動作させることができる。これにより、アプリケーションを変更することなく、ホットスタンバイのクラスタシステムを実現することができる。
【００３２】
次に、図２〜図７を参照して、第１実施形態におけるクラスタシステムの動作について説明する。以下においては、サーバ装置１０が稼働系として動作し、サーバ装置２０が待機系として動作している場合について説明する。この場合、図２に示すように、稼働系サーバ装置１０の転送部１２、ＡＰ実行部１３およびＩ／Ｏ部１４の各ステータスは全てアクティブとなり、待機系サーバ装置２０の転送部２２およびＩ／Ｏ部２４の各ステータスはそれぞれスタンバイとなり、待機系サーバ装置２０のＡＰ実行部２３のステータスはアクティブとなる。
【００３３】
まず、図２および図３を参照して、転送部１２、２２が処理要求を受信した際の動作について説明する。
【００３４】
最初に、稼働系サーバ装置１０の転送部１２がクライアント端末Ｃから処理要求を受信する（ステップＳ１０１）。
【００３５】
続いて、転送部１２は、ステータスがアクティブである（ステップＳ１０２；ＹＥＳ）ため、受信した処理要求を、ステータスがスタンバイである待機系サーバ装置２０の転送部２２に転送する（ステップＳ１０３）。
【００３６】
続いて、稼働系サーバ装置１０の転送部１２は、自サーバ装置１０のＡＰ実行部１３のステータスがアクティブである（ステップＳ１０４；ＹＥＳ）ため、受信した処理要求を、ＡＰ実行部１３に転送する（ステップＳ１０５）。
【００３７】
一方、待機系サーバ装置２０の転送部２２がクライアント端末Ｃから処理要求を受信した場合（ステップＳ１０１）に、転送部２２は、ステータスがスタンバイであり（ステップＳ１０２；ＮＯ）、自サーバ装置２０のＡＰ実行部２３のステータスがアクティブである（ステップＳ１０４；ＹＥＳ）ため、上記ステップＳ１０３で稼働系サーバ装置１０の転送部１２から転送された処理要求を、ＡＰ実行部２３に転送する（ステップＳ１０５）。
【００３８】
次に、図２および図４を参照して、Ｉ／Ｏ部１４、２２がＩ／Ｏ要求を受信した際の動作について説明する。
【００３９】
最初に、稼働系サーバ装置１０のＩ／Ｏ部１４が自サーバ装置１０のＡＰ実行部１３からＩ／Ｏ要求を受信する（ステップＳ２０１）。
【００４０】
続いて、Ｉ／Ｏ部１４は、ステータスがアクティブである（ステップＳ２０２；ＹＥＳ）ため、受信したＩ／Ｏ要求を実行する（ステップＳ２０４）。
【００４１】
続いて、Ｉ／Ｏ部１４は、上記ステップＳ２０４におけるＩ／Ｏ実行結果をＡＰ実行部１３に返信する（ステップＳ２０５）とともに、このＩ／Ｏ実行結果をステータスがスタンバイである待機系サーバ装置２０のＩ／Ｏ部２４に転送する（ステップＳ２０６）。
【００４２】
一方、待機系サーバ装置２０のＩ／Ｏ部２４が自サーバ装置２０のＡＰ実行部２３からＩ／Ｏ要求を受信した場合（ステップＳ２０１）に、Ｉ／Ｏ部２４は、ステータスがスタンバイである（ステップＳ２０２；ＮＯ）ため、受信したＩ／Ｏ要求を実行せずに保持する（ステップＳ２０３）。
【００４３】
続いて、Ｉ／Ｏ部２４は、稼働系サーバ装置１０のＩ／Ｏ部１４から受信（ステップＳ２０７）したＩ／Ｏ実行結果を、自サーバ装置２０のＡＰ実行部２３に返信する（ステップＳ２０８）。
【００４４】
次に、図２および図５を参照して、転送部１２、２２が処理結果を受信した際の動作について説明する。
【００４５】
最初に、稼働系サーバ装置１０の転送部１２が自サーバ装置１０のＡＰ実行部１３から処理結果を受信する（ステップＳ３０１）。
【００４６】
続いて、転送部１２は、ステータスがアクティブである（ステップＳ３０２；ＹＥＳ）ため、受信した処理結果をクライアント端末Ｃに転送する（ステップＳ３０３）。
【００４７】
一方、待機系サーバ装置２０の転送部２２が自サーバ装置２０のＡＰ実行部２３から処理結果を受信した場合（ステップＳ３０１）に、転送部２２は、ステータスがスタンバイである（ステップＳ３０２；ＮＯ）ため、受信した処理結果を転送せずに保持する（ステップＳ３０４）。
【００４８】
次に、図６および図７を参照して、パス障害が発生した際の動作について説明する。図６は、障害発生時の稼働系サーバ装置の動作を説明するためのフローチャートであり、図７は、障害発生時の待機系サーバ装置の動作を説明するためのフローチャートである。
【００４９】
最初に、稼働系サーバ装置１０の制御部１１が自サーバ装置１０と記憶装置Ｄとの間のパス障害を検知した場合（ステップＳ４０１）に、自サーバ装置１０のＩ／Ｏ部１４は、ステータスがスタンバイである待機系サーバ装置２０のＩ／Ｏ部２４が保持しているＩ／Ｏ要求を実行するように依頼するＩ／Ｏ実行依頼を、当該Ｉ／Ｏ部２４に送信する（ステップＳ４０２）。
【００５０】
続いて、稼働系サーバ装置１０の制御部１１は、自サーバ装置１０のＩ／Ｏ部１４および転送部１２のステータスをアクティブからスタンバイに切り替える（ステップＳ４０３）。これにより、サーバ装置１０は、稼働系から待機系となる。
【００５１】
一方、待機系サーバ装置２０のＩ／Ｏ部２４が、上記ステップＳ４０２で送信されたＩ／Ｏ実行依頼を受信した場合（ステップＳ５０１）に、Ｉ／Ｏ部２４は、保持中のＩ／Ｏ要求を実行する（ステップＳ５０２）。
【００５２】
続いて、待機系サーバ装置２０の制御部２１は、自サーバ装置２０のＩ／Ｏ部２４および転送部２２のステータスをスタンバイからアクティブに切り替える（ステップＳ５０３）。これにより、サーバ装置２０は、待機系から稼働系となる。
【００５３】
続いて、上記ステップＳ５０２で保持中のＩ／Ｏ要求を実行したＩ／Ｏ部２４は、そのＩ／Ｏ実行結果を自サーバ装置２０のＡＰ実行部２３に返信する（ステップＳ５０４）。この後、図５のステップＳ３０１以降の処理が実行され、ＡＰ実行部２３での処理結果が転送部２２からクライアント端末Ｃに転送される（ステップＳ３０３）。
【００５４】
なお、この動作例では、サーバ装置１０と記憶装置Ｄとの間でパス障害が発生した場合について説明しているが、サーバ装置１０とクライアント端末Ｃとの間でパス障害が発生した場合についても同様の概念に基づいてサーバ装置を切り替えることができる。この場合には、待機系サーバ装置２０の転送部２２が保持している処理結果を転送するように依頼する処理結果転送依頼を、当該転送部２２に送信し、処理結果転送依頼を受信した転送部２２がクライアント端末Ｃに処理結果を転送することとすればよい。
【００５５】
上述したように、第１実施形態におけるクラスタシステムによれば、転送部１２、２２、ＡＰ実行部１３、２３およびＩ／Ｏ部１４、２４のステータスをそれぞれ制御することで、アプリケーション間の同期をとることができるため、既存のアプリケーションを変更することなく、簡便にホットスタンバイのクラスタシステムを実現することができる。
【００５６】
また、各ステータスを制御することでパスを切り替えることができるため、障害発生時にリソースの再起動やサーバの切り替え時間に要する時間を削減できる。これにより、サービスの可用性を向上させることが可能となる。
【００５７】
[第２実施形態]
本発明の第２実施形態について説明する。第２実施形態におけるクラスタシステムが、上述した第１実施形態におけるクラスタシステムと相違する点は、第２実施形態におけるクラスタシステムが、アプリケーション障害（以下、「ＡＰ障害」という。）発生時の回復機能をさらに備えている点である。それ以外の構成については、第１実施形態におけるシステムの各構成と同様であるため、各構成要素には同一の符合を付し、その説明は省略するとともに、以下においては、主に第１実施形態との相違点について説明する。
【００５８】
制御部１１、２１は、ＡＰ実行部１３、２３でのＡＰ障害を検知した場合に、ＡＰ障害を発生させたＡＰ実行部１３、２３に対してアプリケーションを再起動させるとともに、ＡＰ障害を発生させたＡＰ実行部のステータスをアクティブからスタンバイに切り替える。
【００５９】
制御部１１、２１は、回復時期テーブルに設定された回復時期に基づいて、スタンバイに切り替えたＡＰ実行部のステータスをアクティブに切り替える。
【００６０】
ここで、回復時期テーブルは、ＡＰ障害発生後のＡＰ実行部の回復時期を設定するテーブルである。本実施形態では、回復時期として、“ホット”または“コールド”を予め設定した場合について説明する。
【００６１】
“ホット”は、アプリケーションの実行がメモリ内に保持されている情報に依存しない場合に設定される回復時期である。この場合には、他のサーバ装置でのアプリケーションの実行を継続したまま、障害により再起動させたアプリケーションの実行を再開させてもアプリケーション間の同期をとることができる。したがって、回復時期が“ホット”である場合には、制御部１１、２１は、即座に、スタンバイに切り替えたＡＰ実行部のステータスをスタンバイからアクティブに切り替え直し、アプリケーションの同期を再開させる。
【００６２】
“コールド”は、アプリケーションの実行がメモリ内に保持されている情報に依存する場合に設定される回復時期である。この場合には、全てのサーバ装置でアプリケーションの実行を停止させてから、アプリケーションの実行を再開させなければアプリケーション間の同期をとることができない。したがって、回復時期が“コールド”である場合に、制御部１１、２１は、全てのＡＰ実行部がスタンバイに切り替わった後に、全てのＡＰ実行部のステータスをスタンバイからアクティブに切り替え直し、アプリケーションの同期を再開させる。
【００６３】
次に、図８を参照して、第２実施形態におけるクラスタシステムでＡＰ障害が発生した際の動作について説明する。この動作例では、サーバ装置１０のアプリケーションでＡＰ障害が発生した場合について説明する。
【００６４】
最初に、サーバ装置１０の制御部１１が、ＡＰ実行部１３でのＡＰ障害を検知した場合（ステップＳ６０１）に、ＡＰ実行部１３は、アプリケーションを再起動する（ステップＳ６０２）。
【００６５】
続いて、サーバ装置１０の制御部１１は、ＡＰ実行部１３のステータスをアクティブからスタンバイに切り替える（ステップＳ６０３）。
【００６６】
続いて、サーバ装置１０の制御部１１は、回復時期テーブルを参照し、回復時期が“ホット”であるか否かを判定する（ステップＳ６０４）。この判定がＹＥＳである場合（ステップＳ６０４；ＹＥＳ）に、制御部１１は、ＡＰ実行部１３のステータスをスタンバイからアクティブに切り替える（ステップＳ６０５）。
【００６７】
一方、上記ステップＳ６０４の判定で回復時期が“コールド”であると判定された場合（ステップＳ６０４；ＮＯ）に、制御部１１は、他サーバ装置１０のＡＰ実行部２３のステータスがスタンバイであるか否かを判定する（ステップＳ６０６）。この判定がＮＯである場合（ステップＳ６０６；ＮＯ）に、制御部１１は、この判定がＹＥＳになるまで判定を繰り返す。
【００６８】
一方、上記ステップＳ６０６の判定で他サーバ装置１０のＡＰ実行部２３のステータスがスタンバイであると判定された場合（ステップＳ６０６；ＹＥＳ）に、制御部１１、２１は、ＡＰ実行部１３、２３のステータスをそれぞれスタンバイからアクティブに切り替える（ステップＳ６０７）。
【００６９】
上述したように、第２実施形態におけるクラスタシステムによれば、再同期のタイミングを設定することができるため、ＡＰ障害が発生した場合であっても、ＡＰ実行部１３とＡＰ実行部２３とのアプリケーション間の同期を保持しつつ、アプリケーションの回復を図ることができる。
【００７０】
なお、上述した各実施形態は、単なる例示に過ぎず、各実施形態に明示していない種々の変形や技術の適用を排除するものではない。すなわち、本発明は、その趣旨を逸脱しない範囲で様々な形態に変形して実施することができる。
【００７１】
例えば、上記の各実施形態の一部または全部は、以下の付記のようにも記載され得る。ただし、本発明を以下に限定するものではない。
【００７２】
（付記１） クライアント端末と記憶装置との間のデータのやり取りを制御する第１サーバ装置および第２サーバ装置を有するクラスタシステムであって、前記第１サーバ装置および前記第２サーバ装置は、アプリケーションを実行するアプリケーション実行部と、前記クライアント端末と前記アプリケーション実行部との間のデータの転送を制御する転送制御部と、前記アプリケーション実行部と前記記憶装置との間のデータの入出力を制御する入出力制御部と、前記アプリケーション実行部、前記転送制御部および前記入出力制御部におけるアクティブ／スタンバイのいずれかのステータスをそれぞれ制御するステータス制御部と、をそれぞれ備え、
前記転送制御部は、前記ステータスがアクティブであり、かつ、前記クライアント端末から処理要求を受信した場合には、当該処理要求を、同一サーバ装置の前記アプリケーション実行部、および前記ステータスがスタンバイである前記転送制御部に、それぞれ転送し、前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から処理結果を受信した場合には、当該処理結果を前記クライアント端末に転送し、
前記入出力制御部は、前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から前記記憶装置への入出力要求を受信した場合には、当該入出力要求に基づいて前記記憶装置への入出力を実行し、当該入出力の実行結果を、前記入出力要求の送信元である前記アプリケーション実行部、および前記ステータスがスタンバイである前記入出力制御部に、それぞれ送信し、
前記ステータス制御部は、クラスタシステムを動作させる場合には、前記第１サーバ装置および前記第２サーバ装置のいずれか一方のサーバ装置の前記アプリケーション実行部、前記転送制御部および前記入出力制御部の前記ステータスを全てアクティブに設定し、他方のサーバ装置の前記アプリケーション実行部の前記ステータスをアクティブに、前記転送制御部および前記入出力制御部の前記ステータスをスタンバイに設定し、障害が検知された場合には、前記第１サーバ装置および前記第２サーバ装置の前記転送制御部および前記入出力制御部の前記ステータスを、アクティブからスタンバイに、またはスタンバイからアクティブにそれぞれ切り替える、ことを特徴とするクラスタシステム。
【００７３】
（付記２） 前記転送制御部は、前記ステータスがスタンバイであり、かつ、他方のサーバ装置の前記アプリケーション実行部から処理要求を受信した場合には、当該処理要求を、同一サーバ装置の前記アプリケーション実行部に転送することを特徴とする付記１記載のクラスタシステム。
【００７４】
（付記３） 前記転送制御部は、前記ステータスがスタンバイであり、かつ、前記アプリケーション実行部から処理結果を受信した場合には、当該処理結果を前記クライアント端末に転送せずに、保持することを特徴とする付記１または２記載のクラスタシステム。
【００７５】
（付記４） 前記転送制御部は、前記ステータスがアクティブであり、かつ、前記クライアント端末との間のパスで障害が発生した場合には、前記ステータスがスタンバイである他方のサーバ装置の前記転送制御部が保持している前記処理結果を前記クライアント端末に転送するように依頼する処理結果転送依頼を、他方のサーバ装置の前記転送制御部に送信し、前記処理結果転送依頼を受信した場合には、保持中の前記処理結果を前記クライアント端末に転送する、ことを特徴とする付記３記載のクラスタシステム。
【００７６】
（付記５） 前記入出力制御部は、前記ステータスがスタンバイであり、かつ、前記アプリケーション実行部から前記記憶装置への入出力要求を受信した場合には、当該入出力要求を実行せずに、保持することを特徴とする付記１〜４のいずれか１項に記載のクラスタシステム。
【００７７】
（付記６） 前記入出力制御部は、前記ステータスがアクティブであり、かつ、前記記憶装置との間のパスで障害が発生した場合には、前記ステータスがスタンバイである他方のサーバ装置の前記入出力制御部が保持している前記入出力要求を実行するように依頼する入出力実行依頼を、他方のサーバ装置の前記入出力制御部に送信し、前記入出力実行依頼を受信した場合には、保持中の前記入出力要求を実行し、当該入出力の実行結果を、同一サーバ装置の前記アプリケーション実行部に返信する、ことを特徴とする付記５記載のクラスタシステム。
【００７８】
（付記７） 前記アプリケーション実行部は、アプリケーション障害が発生した場合に、前記アプリケーションを再起動し、前記ステータス制御部は、前記アプリケーション障害を発生させた前記アプリケーション実行部の前記ステータスをアクティブからスタンバイに切り替え、予め設定された回復時期に応じて、スタンバイに切り替えた前記アプリケーション実行部のステータスをアクティブに切り替え直す、ことを特徴とする付記１〜６のいずれか１項に記載のクラスタシステム。
【符号の説明】
【００７９】
１…クラスタシステム、１０、２０…サーバ装置、１１、２１…制御部、１２、２２…転送部、１３、２３…ＡＰ実行部、１４、２４…Ｉ／Ｏ部、Ｃ…クライアント端末、Ｄ…記憶装置。
【特許請求の範囲】
【請求項１】
クライアント端末と記憶装置との間のデータのやり取りを制御する第１サーバ装置および第２サーバ装置を有するクラスタシステムであって、
前記第１サーバ装置および前記第２サーバ装置は、
アプリケーションを実行するアプリケーション実行部と、
前記クライアント端末と前記アプリケーション実行部との間のデータの転送を制御する転送制御部と、
前記アプリケーション実行部と前記記憶装置との間のデータの入出力を制御する入出力制御部と、
前記アプリケーション実行部、前記転送制御部および前記入出力制御部におけるアクティブ／スタンバイのいずれかのステータスをそれぞれ制御するステータス制御部と、をそれぞれ備え、
前記転送制御部は、
前記ステータスがアクティブであり、かつ、前記クライアント端末から処理要求を受信した場合には、当該処理要求を、同一サーバ装置の前記アプリケーション実行部、および前記ステータスがスタンバイである前記転送制御部に、それぞれ転送し、
前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から処理結果を受信した場合には、当該処理結果を前記クライアント端末に転送し、
前記入出力制御部は、前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から前記記憶装置への入出力要求を受信した場合には、当該入出力要求に基づいて前記記憶装置への入出力を実行し、当該入出力の実行結果を、前記入出力要求の送信元である前記アプリケーション実行部、および前記ステータスがスタンバイである前記入出力制御部に、それぞれ送信し、
前記ステータス制御部は、
クラスタシステムを動作させる場合には、前記第１サーバ装置および前記第２サーバ装置のいずれか一方のサーバ装置の前記アプリケーション実行部、前記転送制御部および前記入出力制御部の前記ステータスを全てアクティブに設定し、他方のサーバ装置の前記アプリケーション実行部の前記ステータスをアクティブに、前記転送制御部および前記入出力制御部の前記ステータスをスタンバイに設定し、
障害が検知された場合には、前記第１サーバ装置および前記第２サーバ装置の前記転送制御部および前記入出力制御部の前記ステータスを、アクティブからスタンバイに、またはスタンバイからアクティブにそれぞれ切り替える、
ことを特徴とするクラスタシステム。
【請求項２】
前記転送制御部は、前記ステータスがスタンバイであり、かつ、他方のサーバ装置の前記アプリケーション実行部から処理要求を受信した場合には、当該処理要求を、同一サーバ装置の前記アプリケーション実行部に転送することを特徴とする請求項１記載のクラスタシステム。
【請求項３】
前記転送制御部は、前記ステータスがスタンバイであり、かつ、前記アプリケーション実行部から処理結果を受信した場合には、当該処理結果を前記クライアント端末に転送せずに、保持することを特徴とする請求項１または２記載のクラスタシステム。
【請求項４】
前記転送制御部は、
前記ステータスがアクティブであり、かつ、前記クライアント端末との間のパスで障害が発生した場合には、前記ステータスがスタンバイである他方のサーバ装置の前記転送制御部が保持している前記処理結果を前記クライアント端末に転送するように依頼する処理結果転送依頼を、他方のサーバ装置の前記転送制御部に送信し、
前記処理結果転送依頼を受信した場合には、保持中の前記処理結果を前記クライアント端末に転送する、
ことを特徴とする請求項３記載のクラスタシステム。
【請求項５】
前記入出力制御部は、前記ステータスがスタンバイであり、かつ、前記アプリケーション実行部から前記記憶装置への入出力要求を受信した場合には、当該入出力要求を実行せずに、保持することを特徴とする請求項１〜４のいずれか１項に記載のクラスタシステム。
【請求項６】
前記入出力制御部は、
前記ステータスがアクティブであり、かつ、前記記憶装置との間のパスで障害が発生した場合には、前記ステータスがスタンバイである他方のサーバ装置の前記入出力制御部が保持している前記入出力要求を実行するように依頼する入出力実行依頼を、他方のサーバ装置の前記入出力制御部に送信し、
前記入出力実行依頼を受信した場合には、保持中の前記入出力要求を実行し、当該入出力の実行結果を、同一サーバ装置の前記アプリケーション実行部に返信する、
ことを特徴とする請求項５記載のクラスタシステム。
【請求項７】
前記アプリケーション実行部は、アプリケーション障害が発生した場合に、前記アプリケーションを再起動し、
前記ステータス制御部は、前記アプリケーション障害を発生させた前記アプリケーション実行部の前記ステータスをアクティブからスタンバイに切り替え、予め設定された回復時期に応じて、スタンバイに切り替えた前記アプリケーション実行部のステータスをアクティブに切り替え直す、
ことを特徴とする請求項１〜６のいずれか１項に記載のクラスタシステム。
【請求項１】
クライアント端末と記憶装置との間のデータのやり取りを制御する第１サーバ装置および第２サーバ装置を有するクラスタシステムであって、
前記第１サーバ装置および前記第２サーバ装置は、
アプリケーションを実行するアプリケーション実行部と、
前記クライアント端末と前記アプリケーション実行部との間のデータの転送を制御する転送制御部と、
前記アプリケーション実行部と前記記憶装置との間のデータの入出力を制御する入出力制御部と、
前記アプリケーション実行部、前記転送制御部および前記入出力制御部におけるアクティブ／スタンバイのいずれかのステータスをそれぞれ制御するステータス制御部と、をそれぞれ備え、
前記転送制御部は、
前記ステータスがアクティブであり、かつ、前記クライアント端末から処理要求を受信した場合には、当該処理要求を、同一サーバ装置の前記アプリケーション実行部、および前記ステータスがスタンバイである前記転送制御部に、それぞれ転送し、
前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から処理結果を受信した場合には、当該処理結果を前記クライアント端末に転送し、
前記入出力制御部は、前記ステータスがアクティブであり、かつ、前記アプリケーション実行部から前記記憶装置への入出力要求を受信した場合には、当該入出力要求に基づいて前記記憶装置への入出力を実行し、当該入出力の実行結果を、前記入出力要求の送信元である前記アプリケーション実行部、および前記ステータスがスタンバイである前記入出力制御部に、それぞれ送信し、
前記ステータス制御部は、
クラスタシステムを動作させる場合には、前記第１サーバ装置および前記第２サーバ装置のいずれか一方のサーバ装置の前記アプリケーション実行部、前記転送制御部および前記入出力制御部の前記ステータスを全てアクティブに設定し、他方のサーバ装置の前記アプリケーション実行部の前記ステータスをアクティブに、前記転送制御部および前記入出力制御部の前記ステータスをスタンバイに設定し、
障害が検知された場合には、前記第１サーバ装置および前記第２サーバ装置の前記転送制御部および前記入出力制御部の前記ステータスを、アクティブからスタンバイに、またはスタンバイからアクティブにそれぞれ切り替える、
ことを特徴とするクラスタシステム。
【請求項２】
前記転送制御部は、前記ステータスがスタンバイであり、かつ、他方のサーバ装置の前記アプリケーション実行部から処理要求を受信した場合には、当該処理要求を、同一サーバ装置の前記アプリケーション実行部に転送することを特徴とする請求項１記載のクラスタシステム。
【請求項３】
前記転送制御部は、前記ステータスがスタンバイであり、かつ、前記アプリケーション実行部から処理結果を受信した場合には、当該処理結果を前記クライアント端末に転送せずに、保持することを特徴とする請求項１または２記載のクラスタシステム。
【請求項４】
前記転送制御部は、
前記ステータスがアクティブであり、かつ、前記クライアント端末との間のパスで障害が発生した場合には、前記ステータスがスタンバイである他方のサーバ装置の前記転送制御部が保持している前記処理結果を前記クライアント端末に転送するように依頼する処理結果転送依頼を、他方のサーバ装置の前記転送制御部に送信し、
前記処理結果転送依頼を受信した場合には、保持中の前記処理結果を前記クライアント端末に転送する、
ことを特徴とする請求項３記載のクラスタシステム。
【請求項５】
前記入出力制御部は、前記ステータスがスタンバイであり、かつ、前記アプリケーション実行部から前記記憶装置への入出力要求を受信した場合には、当該入出力要求を実行せずに、保持することを特徴とする請求項１〜４のいずれか１項に記載のクラスタシステム。
【請求項６】
前記入出力制御部は、
前記ステータスがアクティブであり、かつ、前記記憶装置との間のパスで障害が発生した場合には、前記ステータスがスタンバイである他方のサーバ装置の前記入出力制御部が保持している前記入出力要求を実行するように依頼する入出力実行依頼を、他方のサーバ装置の前記入出力制御部に送信し、
前記入出力実行依頼を受信した場合には、保持中の前記入出力要求を実行し、当該入出力の実行結果を、同一サーバ装置の前記アプリケーション実行部に返信する、
ことを特徴とする請求項５記載のクラスタシステム。
【請求項７】
前記アプリケーション実行部は、アプリケーション障害が発生した場合に、前記アプリケーションを再起動し、
前記ステータス制御部は、前記アプリケーション障害を発生させた前記アプリケーション実行部の前記ステータスをアクティブからスタンバイに切り替え、予め設定された回復時期に応じて、スタンバイに切り替えた前記アプリケーション実行部のステータスをアクティブに切り替え直す、
ことを特徴とする請求項１〜６のいずれか１項に記載のクラスタシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１２−１５５５４０（Ｐ２０１２−１５５５４０Ａ）
【公開日】平成２４年８月１６日（２０１２．８．１６）
【国際特許分類】
【出願番号】特願２０１１−１４１６３（Ｐ２０１１−１４１６３）
【出願日】平成２３年１月２６日（２０１１．１．２６）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年８月１６日（２０１２．８．１６）
【国際特許分類】
【出願日】平成２３年１月２６日（２０１１．１．２６）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]