(57)【要約】【課題】  同期制御のためにアプリケーションに機能を求めることなく、データのロスを抑えて運用系／待機系アプリケーションのデータ同期を保つことを目的とする。【解決手段】クラスタシステム内のサーバは、他のサーバから受信したデータを格納する第１のデータキューと、前記第１のデータキューに格納されたデータから、運用系アプリケーションが処理するデータを格納する第２のデータキューと、を備え、運用系アプリケーションが処理するデータを前記第２のデータキューからデキューする時に、前記運用系アプリケーションを稼動させるサーバと待機系アプリケーションを稼動させるサーバ間でデータ同期をし、前記運用系アプリケーションがデータの処理をしている間、前記待機系アプリケーションを稼動させるサーバにおいて、前記第１のデータキューに同じデータを保持する。【選択図】  図２
2012064109.tif 000002
【特許請求の範囲】
【請求項１】
１または複数のアプリケーションを稼動させるサーバと、該サーバを複数個接続したクラスタシステムにおいて、
前記サーバは、
他のサーバから受信したデータを格納する第１のデータキューと、
前記第１のデータキューに格納されたデータから、運用系アプリケーションが処理するデータを格納する第２のデータキューと、を備え、
運用系アプリケーションが処理するデータを前記第２のデータキューからデキューする時に、前記運用系アプリケーションを稼動させるサーバと、前記運用系アプリケーションに対応する待機系アプリケーションを稼動させるサーバ間でデータ同期をし、
前記運用系アプリケーションがデータの処理をしている間、前記待機系アプリケーションを稼動させるサーバにおいて、前記第１のデータキューに該データと同じデータを保持することを特徴とするサーバ。
【請求項２】
前記待機系アプリケーションを稼動させるサーバにおいて、前記第１のデータキューは、前記データ同期時に、前記運用系アプリケーションが処理するデータと同じデータを先頭データにする請求項１に記載のサーバ。
【請求項３】
請求項１または２のいずれか１つに記載のサーバが複数個接続されるクラスタシステム。
【請求項４】
請求項３に記載のクラスタシステムは、クラスタシステムの構成を制御する機能を有する構成制御サーバを有し、
前記構成制御サーバは、アプリケーションが運用系または待機系のいずれで稼動しているかの情報を有し、前記クラスタシステム内のサーバは前記情報を前記データ同期前に取得するクラスタシステム。
【請求項５】
前記構成制御サーバは、稼動させるアプリケーションの優先度情報と、アプリケーションの稼動によるサーバの負荷情報に基づき、サーバで稼動するアプリケーションの配置を決定する請求項４に記載のクラスタシステム。
【請求項６】
前記構成制御サーバは、アプリケーションが運用系または待機系のいずれで稼動しているかの情報に基づき、運用系アプリケーションの処理結果の送信先となるサーバの情報を更新し、前記クラスタシステム内のサーバは該更新された情報を前記データ同期前に取得する請求項４または５のいずれか１つに記載のクラスタシステム。
【請求項７】
１または複数のアプリケーションを稼動させるサーバと、該サーバを複数個接続したクラスタシステムにおいて、
運用系アプリケーションが処理するデータを第２のデータキューからデキューする時に、前記運用系アプリケーションを稼動させるサーバと、前記運用系アプリケーションに対応する待機系アプリケーションを稼動させるサーバ間でデータ同期をし、
前記運用系アプリケーションがデータの処理をしている間、前記待機系アプリケーションを稼動させるサーバにおいて、第１のデータキューに該データと同じデータを保持することを特徴とするデータ同期方法。
【請求項８】
前記待機系アプリケーションを稼動させるサーバにおいて、前記第１のデータキューは、前記データ同期時に、前記運用系アプリケーションが処理するデータと同じデータを先頭データにする請求項７に記載のデータ同期方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバを複数接続したクラスタシステムに関し、特に、サーバ間のデータ同期方法に関する。
【背景技術】
【０００２】
運用系アプリケーション（運用系として稼動しているアプリケーション）を稼動させるサーバと、待機系アプリケーション（待機系として稼動しているアプリケーション）を稼動させるサーバとの間でデータ同期させておくことにより、運用系アプリケーションを稼動させるサーバに障害等が発生したときは、待機系アプリケーションを運用系に短時間で切り替えることができる。このようにしてシステムの信頼性を高めるクラスタシステムが提案されている。
【０００３】
上述のクラスタシステムには、システムの障害発生、機能追加または規模拡張などによりサーバ構成が変化するとき、各サーバで稼動するアプリケーションの運用系／待機系の切替えを効率的に行うことが必要である。また、サーバ構成変化後におけるシステムのリソースを有効活用するため、アプリケーションによる処理の負荷、継続稼動の優先度などを基に最適なアプリケーションによる処理の配置を計算し、アプリケーションの動作に影響を与えない形でクラスタシステムを再構成することが求められる。更に、アプリケーションで処理された処理結果データをサーバ間で送受信するような場合には、アプリケーションによる処理の再配置に追従して、アプリケーション間のデータ送受信設定も動的にかつデータロスの無いようにクラスタシステムの再構成を行うことが求められる。
【０００４】
処理側と独立しデータ同期・構成制御を行うことに関する従来技術として、予め定められた運用系サーバと待機系サーバの間でメモリの同期化を行い、運用系サーバで障害が発生した時には待機系サーバで同期されたメモリの内容を用いて処理を継続する方法が開示されている（例えば、下記特許文献１参照。）。また、アプリケーションによる処理を再配置することに関する従来技術として、アプリケーションの負荷情報及びサーバ構成情報からアプリケーションによる処理の配置を最適なものに変更する方法が開示されている（例えば、下記特許文献２参照）。また、アプリケーションで処理されたデータの送信先の変更については、各サーバの稼動状態等の監視情報に基づいて動的に決定する機構と、それにより決定された送信先サーバへデータを送信する方法が開示されている（例えば、下記特許文献３参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−５８９６０号公報
【特許文献２】特開２００８−１３５０５６号公報
【特許文献３】特開２０１０−３１２１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記の従来技術を組み合わせても、アプリケーション間で通信するデータのロスを抑えつつ、運用系／待機系アプリケーションのデータ同期を保つことが困難となるという問題点があった。例えば、待機系アプリケーションが受信したデータを処理し、その処理結果データを自系が運用系アプリケーションでないために破棄してしまい、待機系アプリケーションが運用系アプリケーションに切り替わる際にデータロストが発生するという問題点があった。また、データ同期するタイミングを決定するために、アプリケーションによる処理状況をサーバの機能が監視する方式では、アプリケーションが、サーバの機能によって監視できるように動作するものでなければならず、サーバで稼動可能なアプリケーションが制限されるという問題点があった。例えば、上記の特許文献１に記載の従来技術においては、サーバで稼動するアプリケーションがサーバ間の同期制御を行うレプリケーション機能部を介してメモリにデータを書き込むことで、レプリケーション機能部がメモリの更新状況を把握し、サーバ間のデータ同期を行っている。このため、アプリケーションには、サーバの特定の機能を介してメモリを更新するという特殊な動作をしなければならないという問題点があった。
【０００７】
本発明では、上記の課題を解決するために、サーバが受信したデータを格納する受信データキューと、アプリケーションが処理するデータを格納する未処理データキューとを設ける。運用系アプリケーションが稼動するサーバでは、受信データキューにエンキューした受信データを、未処理データキューにエンキューし、運用系アプリケーションがそのデータを処理するためにデキューする。一方、この運用系アプリケーションに対応する待機系アプリケーションが稼動するサーバでは、運用系アプリケーションが処理を開始してから、処理を完了して次の受信データの処理に取り掛かるまで、当該受信データを受信データキュー内に保持し続ける構成をとる。これにより、待機系アプリケーションが運用系アプリケーションに切り替わる際にデータロストが発生することを防止する。
【０００８】
また、運用系アプリケーションが処理するデータを未処理データキューからデキューするタイミングで運用系／待機系アプリケーションのデータ同期を行い、待機系から運用系に切り替わったアプリケーションがデータ同期した点をデータ処理再開ポイントとして把握する構成とする。これにより、待機系アプリケーションがそのデータ同期点の状態から運用系アプリケーションとして機能することが可能となる。
【課題を解決するための手段】
【０００９】
本発明にかかるサーバは、１または複数のアプリケーションを稼動させるサーバと、該サーバを複数個接続したクラスタシステムにおいて、前記サーバは、他のサーバから受信したデータを格納する第１のデータキューと、前記第１のデータキューに格納されたデータから、運用系アプリケーションが処理するデータを格納する第２のデータキューと、を備え、運用系アプリケーションが処理するデータを前記第２のデータキューからデキューする時に、前記運用系アプリケーションを稼動させるサーバと、前記運用系アプリケーションに対応する待機系アプリケーションを稼動させるサーバ間でデータ同期をし、前記運用系アプリケーションがデータの処理をしている間、前記待機系アプリケーションを稼動させるサーバにおいて、前記第１のデータキューに該データと同じデータを保持することを特徴とするものである。
【発明の効果】
【００１０】
同期制御のためにアプリケーションに機能を求めることなく、データのロスを抑えて運用系／待機系アプリケーションのデータ同期を保つことができる。
【図面の簡単な説明】
【００１１】
【図１】この発明の実施の形態１にかかるクラスタシステムの全体構成例を示す図である。
【図２】この発明の実施の形態１にかかるサーバの構成例を示す図である。
【図３】この発明の実施の形態１にかかる構成制御サーバの構成例を示す図である。
【図４】この発明の実施の形態１にかかるクラスタ構成テーブルの一例を示す図である。
【図５】この発明の実施の形態１にかかる処理結果送信先テーブルの一例を示す図である。
【図６】この発明の実施の形態１にかかるデータ受信時におけるクラスタシステムの動作例を示す図である。
【図７】この発明の実施の形態１にかかる受信データ処理時におけるクラスタシステムの動作例を示す図である。
【図８】この発明の実施の形態１にかかるサーバ間のデータ同期時におけるクラスタシステムの動作例を示す図である。
【図９】この発明の実施の形態１にかかる処理結果データ送信時におけるクラスタシステムの動作例を示す図である。
【図１０】この発明の実施の形態１にかかるデータ受信から処理結果データ送信までのクラスタシステムの動作例を示すフローチャートである。
【図１１】この発明の実施の形態２にかかるクラスタシステムのサーバ増設時の構成例を示す図である。
【図１２】この発明の実施の形態２にかかるアプリケーション情報テーブルの一例を示す図である。
【図１３】この発明の実施の形態２にかかるクラスタ構成テーブルの一例を示す図である。
【図１４】この発明の実施の形態２にかかる処理結果送信先テーブルの一例を示す図である。
【図１５】この発明の実施の形態２にかかるテーブル更新後の受信データ処理時におけるクラスタシステムの動作例を示す図である。
【図１６】この発明の実施の形態２にかかるサーバ間のデータ同期時におけるクラスタシステムの動作例を示す図である。
【図１７】この発明の実施の形態２にかかる処理結果送信時におけるクラスタシステムの動作例を示す図である。
【図１８】この発明の実施の形態２にかかるサーバ追加検知から、切替制御の実行までのクラスタシステムの動作例を示すフローチャートである。
【図１９】この発明の実施の形態２にかかるデータ受信から処理結果データ送信までのクラスタシステムの動作例を示すフローチャートである。
【図２０】この発明の実施の形態３にかかるクラスタシステムの障害発生時の動作例を示す図である。
【図２１】この発明の実施の形態３にかかるテーブル更新後の受信データ処理時におけるクラスタシステムの動作例を示す図である。
【図２２】この発明の実施の形態３にかかるクラスタ構成テーブルの一例を示す図である。
【図２３】この発明の実施の形態３にかかるデータ受信から処理結果データ送信までのクラスタシステムの動作例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
実施の形態１．
以下に、本実施の形態を図面に基づいて詳細に説明する。なお、以下に説明する実施の形態は、それぞれが本発明を具体化する際の一形態であって、本発明をその範囲内に限定するためのものではない。
【００１３】
本実施の形態では平常時、すなわち、サーバの増設または障害等が発生していない状態における運用系／待機系のデータ受信から、データ同期をして処理結果データが送信されるまでのクラスタシステムの動作について図を用いて説明する。
【００１４】
図１は、本実施の形態にかかるクラスタシステムの全体構成例を示す図である。複数台のサーバ１（サーバの数は任意に増減することができる。）と構成制御を行う構成制御サーバ２が、ネットワークを介して接続されている。尚、構成制御サーバを独立に設ける構成でなくともよい。すなわち、任意のサーバ内に構成制御サーバとしての機能を持つ構成があってもよく、図１のサーバはアプリケーションを稼動させる通常のサーバと構成制御サーバを兼ねることとなる。
【００１５】
図２は、本実施の形態にかかるサーバの構成例を示す図である。アプリケーションａ〜ｃを稼動させる場合を例として説明する。稼動させるアプリケーションの数は、例えば、サーバの処理能力に応じ増減できる。サーバ１は、アプリケーションを稼動させるアプリケーション稼動部１０１〜１０３と、同期データ送信部１１１、同期データ受信部１１２、処理結果送信部１１３、処理結果受信部１１４、受信データキュー管理部１１５、処理結果送信用キュー管理部１１６、クラスタ構成テーブル１１７、処理結果送信先テーブル１１８を有する構成制御手段１１と、各アプリケーションにデータ領域１２１〜１２３を割り当てる共有メモリ１２と、アプリケーションに対して設けられる未処理データキュー（１３１、１３２、１３３）、受信データキュー（１４１、１４２、１４３）、処理結果送信用キュー（１５１、１５２、１５３）、によって構成されている。尚、受信データキューが第１のデータキュー、未処理データキューが第２のデータキューに対応する。また、各アプリケーションにデータ領域を割り当てるメモリを共有メモリとしているが、各アプリケーションが独立したメモリを持っているとしても良い。
【００１６】
図３は、本実施の形態にかかる構成制御サーバの構成例を示す図である。構成制御サーバ２は、サーバで稼動するアプリケーションが運用系または待機系のいずれで稼動しているかの情報を格納するクラスタ構成テーブル２５０と、運用系アプリケーションの処理結果の送信先となるサーバや後続処理をするアプリケーションの情報を格納する処理結果送信先テーブル２６０を有する。また、クラスタシステムの再構成によって、クラスタ構成テーブル２５０と処理結果送信先テーブル２６０の内容が再構成された場合に、その再構成されたテーブルの情報を各サーバに配布する切替制御部２１０、サーバの増設、故障等のクラスタシステムの構成の変化を監視する状態監視部２２０、クラスタシステムの再構成に合わせてクラスタ構成テーブル２５０を再構成するクラスタ構成テーブル再構成部２３０、クラスタシステムの再構成によってアプリケーションで処理された処理結果の送信先が変わる場合に、処理結果送信先テーブル２６０を再構成する処理結果送信先テーブル再構成部２４０を有する。
【００１７】
図４に本実施の形態にかかるサーバ１のクラスタ構成テーブル２５０の構成例を示す。テーブルは、それぞれのサーバ上の各アプリケーション稼動部で稼動しているアプリケーションが、運用系または待機系のいずれで稼動しているかを示している。例えば、サーバＢではアプリケーションａが待機系、アプリケーションｂが運用系にて稼動していることを示している。
【００１８】
図５に本実施の形態にかかるサーバ１の処理結果送信先テーブル２６０の構成例を示す。テーブルは、アプリケーションによって処理された処理結果データの送信先となるサーバと、そのデータを後続処理するアプリケーションを示している。例えば、サーバＡで稼動するアプリケーションａで処理されたデータは次にサーバＣに送信され、サーバＣで稼動するアプリケーションｃによって処理される。
【００１９】
次に、本実施の形態におけるクラスタシステムによるデータ処理の動作例について説明する。ここでは、サーバがデータを受信してから、データを運用系アプリケーションが処理して、処理結果データを次に処理するサーバに送信するまでのクラスタシステムの一連の動作を説明する。図６はデータ受信時、図７は受信データキューおよび未処理データキュー上での受信データ処理時、図８はデータ同期時、図９は処理結果データ送信時のクラスタシステムの動作例をそれぞれ示している。また、図１０はデータ受信時から処理結果データ送信時までのクラスタシステムの動作の一例を示すフローチャートである。尚、本実施の形態では、サーバＡの運用系アプリケーションａと、それに対応するサーバＢの待機系アプリケーションａに着目して説明しているが、１つのサーバ内にアプリケーション稼動部を複数設け、アプリケーションａ以外に他のアプリケーションを複数同時に稼動させていてもよい。
【００２０】
まず、図６を用いて、データ受信時におけるクラスタシステムの動作例を説明する。アプリケーションａを運用系として稼動させるサーバＡ、運用系アプリケーションａに対応して、アプリケーションａを待機系として稼動させるサーバＢのそれぞれが、図示していない他のサーバから同じデータｘを受信する。データｘはサーバＡの処理結果受信部１１４ＡとサーバＢの処理結果受信部１１４Ｂによって受信される（ステップＳ１００１）。サーバＡの処理結果受信部１１４Ａはデータｘをアプリケーションａの受信データキュー１４１Ａにエンキューする。同様に、サーバＢの処理結果受信部１１４Ｂはデータｘをアプリケーションａの受信データキュー１４１Ｂにエンキューする（ステップＳ１００２）。尚、符号の末尾につける英字はサーバの末尾の英字と対応する。以降の説明においても同様である。
【００２１】
次に、図７を用いて、受信データ処理時におけるクラスタシステムの動作例について説明する。サーバＡの受信データキュー管理部１１５Ａはアプリケーションａが運用系で稼動しているかどうかを、クラスタ構成テーブル１１７Ａを参照して確認する。サーバＢでも同様の確認を行う（ステップＳ１００３）。運用系でアプリケーションａを稼動しているサーバＡでは受信データキュー１４１Ａの先頭データ、ここではデータｘを未処理データキュー１３１Ａにエンキューする（ステップＳ１０Ａ４）。一方、待機系でアプリケーションａを稼動しているサーバＢでは受信データキュー１４１Ｂをそのままの状態に維持する（ステップＳ１０Ｂ４）。
【００２２】
次に、図８を用いてアプリケーション間のデータ同期時におけるクラスタシステムの動作例について説明する。ここで、各サーバ上で稼動しているアプリケーションは構成制御を意識することなく、未処理データキューのデータをデキューして処理するものとする。サーバＡでは、アプリケーションａが未処理データキュー１３１Ａのデータｘをデキューする（ステップＳ１０Ａ５）。このデキューを受信データキュー管理部１１５Ａが検知したところで、待機系としてアプリケーションａを稼動させているサーバとのデータ同期を行う。本実施の形態ではサーバＢがデータ同期先となる。まず、同期データ送信部１１１Ａが、共有メモリ１２のアプリケーションａ用データ領域１２１Ａに格納されているデータＳ１とデキューされたデータｘを同期データとして、サーバＢへ送信する（ステップＳ１０Ａ６）。サーバＡから送信された同期データはサーバＢの同期データ受信部１１２Ｂによって受信される（ステップＳ１０Ｂ５）。但し、サーバＢの受信データキュー１４１Ｂはすでに運用系アプリケーションで処理するデータと同じデータｘを格納しているので、送信されたデータｘを受信データキュー１４１Ｂに二重に格納しない。次に、サーバＢでは、データｘがサーバＢの受信データキュー１４１Ｂで先頭になるように、それより先に格納されているデータをデキューする（ステップＳ１０Ｂ６）。本実施の形態においてはデータｘの前にエンキューされて保持されているデータｗをデキューして削除し、データｘが先頭データとなるようにする。続いてアプリケーションａ用データ領域１２１Ｂに格納されているデータＳ０をサーバＡのアプリケーションａ用データ領域１２１Ａと同じＳ１に書き換える（ステップＳ１０Ｂ７）。以上で運用系／待機系のデータ同期は完了となり、待機系としてアプリケーションａが稼動しているサーバＢが同期の完了を、運用系としてアプリケーションａが稼動しているサーバＡの同期データ送信部１１１Ａに通知する（ステップＳ１０Ｂ８）。
【００２３】
次に、図９を用いて処理結果データ送信時におけるクラスタシステムの動作例について説明する。サーバＡの同期データ送信部１１１Ａが同期完了の通知を受けた（ステップＳ１０Ａ７）後、アプリケーション稼動部１０１Ａではデータｘが処理される（ステップＳ１０Ａ８）。データｘを処理した結果、アプリケーションａ用データ領域１２１ＡのデータがＳ２に書き換わり、処理結果データとしてｘ’が出力される。このとき処理結果データｘ’は処理結果送信用キュー１５１Ａにエンキューされる（ステップＳ１０Ａ９）。次に、処理結果送信用キュー管理部１１６Ａはキューの先頭データｘ’をデキューし、処理結果送信先テーブル１１８Ａに記された処理結果データｘ’を後続処理するアプリケーションｃが運用系で稼動しているサーバＣへ送信する（ステップＳ１０Ａ１０）。以上が平常時のデータ受信から結果送信までの一連の動作である。
【００２４】
以上のように、サーバに受信データキューおよび未処理データキューを設ける構成とし、運用系アプリケーションを稼動するサーバが、未処理データキューから受信データをデキューする時に待機系アプリケーションを稼動するサーバとデータ同期をとることによって、受信データ１ワード毎のタイミングで運用系／待機系のデータ同期がなされる。この同期タイミングはアプリケーションの動作とは独立し、アプリケーションに依存しないため、アプリケーションに対してサーバの同期制御機能に適合する機能を求める必要がない。このため、アプリケーション開発の負荷を軽減できるとともに、クラスタシステムで稼動できるアプリケーションの自由度が増すこととなる。また、運用系アプリケーションが受信データの処理を開始して、次のデータの処理に取り掛かるまでの間、待機系アプリケーションが当該データと同じ受信データを未処理データキューにエンキューせずに、受信データキュー内に保持し続ける構成とすることで、待機系アプリケーションが受信データを処理し、誤ってそれを破棄してしまうことにより、待機系アプリケーションが運用系に切り替わった際のデータロストを防止することができる。
【００２５】
実施の形態２．
本実施の形態ではクラスタシステム内にサーバが増設されたときのクラスタシステムの再構成の動作について示す。
【００２６】
図１１はサーバ群Ａ、Ｂ、Ｃに新たにサーバＤが増設されたクラスタシステムの全体構成例である。以降の説明において、図面において実施の形態１と同一の機能と内容である構成は、実施の形態１と同一の符号を付して説明を省略する。
【００２７】
次に、本実施の形態におけるクラスタシステムによるデータ処理の動作例について説明する。ここではサーバＤの増設によってクラスタ構成テーブルおよび処理結果送信先テーブルが更新されてからのデータ同期時、処理結果データ送信時の一連の動作について説明する。図１２はクラスタシステムの再構成に利用されるアプリケーション情報テーブル、図１３は更新されたクラスタ構成テーブル、図１４は更新された処理結果送信先テーブルの一例をそれぞれ示している。また、図１５はテーブル更新後の受信データ処理時、図１６はデータ同期時、図１７は処理結果データ送信時それぞれのクラスタシステムの動作例を示す。図１８は構成制御サーバのサーバ追加検知から、切替制御の実行までのクラスタシステムの動作の一例を示すフローチャート、図１９は構成制御サーバからクラスタ構成テーブルおよび処理結果送信先テーブルの情報がサーバ群に配布されてからのクラスタシステムの動作の一例を示すフローチャートである。尚、説明において増設するサーバは１つだけであるが、複数のサーバを増設させる場合も本実施の形態を適用することができる。
【００２８】
まず、図１１に示すように、アプリケーションａによって処理されるデータｘがサーバＡとサーバＢに送信される。実施の形態１と同様にサーバＡの処理結果受信部１１４Ａ、サーバＢの処理結果受信部１１４Ｂにおいてそれぞれ受信された後（ステップＳ１８Ａ１）、各サーバで受信された受信データｘはそれぞれサーバ内の受信データキュー１４１Ａ、１４１Ｂにエンキューされる（ステップＳ１８Ａ２）。この時点でクラスタ内に追加されたサーバＤを構成制御サーバ２中の状態監視部２２０が検知したものとして以降の処理について示す。
【００２９】
サーバＤがサーバ群に追加されると（ステップＳ１８Ｄ１）、状態監視部２２０はサーバＤの追加を検知する（ステップＳ１８２１）。次に、状態監視部２２０はクラスタ構成テーブル２５０に対して新たにサーバＤの列が追加するように、クラスタ構成テーブル再構成部２３０にテーブルの再構成を指示する。クラスタ構成テーブル再構成部２３０は、クラスタ構成テーブルをアプリケーションやサーバに関する情報を基にクラスタ構成テーブルを再構成する（ステップＳ１８２２）。本実施の形態では一例として、以下の４つの条件下でクラスタ構成テーブルの再構成を行うものとする。第１の条件としてサーバＡ、Ｂ、Ｃ、Ｄは全て同じ処理スペックとする。第２の条件として各アプリケーションについて運用系／待機系（三重系以降も含む）の稼動優先順位が定められており、優先度情報はテーブルに記されているものとする。第３の条件として各アプリケーションの運用系／待機系として動作するときのサーバのＣＰＵ使用率が負荷情報として与えられるとする。第４の条件としてクラスタ構成テーブルの再構成は、稼動優先度の高いアプリケーションから調べ、稼動していないアプリケーションを各サーバの使用率が１００％に達しない範囲で配置するとする。図１２に一例を示すように、各アプリケーションについて運用系／待機系の稼動優先順位を格納する稼動優先度情報テーブル２０１、各アプリケーションを運用系／待機系で稼動させたときのサーバのＣＰＵ使用率を示すアプリケーション負荷情報テーブル２０２がアプリケーション情報テーブルとして構成制御サーバ２内に格納されている。
【００３０】
図１３はサーバＤの増設を検知したことにより再構成されたクラスタ構成テーブル例を示す図である。本実施の形態においては、サーバＤが追加される前は、各サーバに対して図４のクラスタ構成テーブルに示されるアプリケーションが稼動している。すわなち、アプリケーション優先度情報テーブル２０１中では優先度１のアプリケーションａ運用系から優先度５のアプリケーションｂ待機系までが稼動しているということになる。図１２に示すアプリケーション優先度情報テーブル２０１およびアプリケーション負荷情報テーブル２０２に基づけば、サーバＤで稼動可能となるのは、優先度６のアプリケーションｃ待機系と優先度７のアプリケーションａ待機系である。以上から、サーバＤの追加が検知され、クラスタ構成テーブル再構成部２３０に対して再構成が指示されると、クラスタ構成テーブル２５０が図１３に示すクラスタ構成テーブル２５１に再構成される。この再構成が完了すると次は、処理結果送信先テーブルの再構成を実施する。
【００３１】
図１４はサーバＤの増設によって再構成された処理結果送信先テーブルの例を示している。処理結果送信先テーブル再構成部２４０では、再構成されたクラスタ構成テーブル２５１の内容に沿って、処理結果送信先を再構成する（ステップＳ１８２３）。前段のクラスタ構成テーブル再構成処理の結果、サーバＤが追加されたクラスタ構成テーブル２５１が得られている。このとき、処理結果送信先テーブル２６０では、後続処理の列に記された運用系／待機系アプリケーションが稼動するサーバが送信先となるように送信先の列の内容を更新する。本実施の形態においてはサーバＤで新たにアプリケーションａ待機系、アプリケーションｃ待機系が稼動している。従って、送信先の列にサーバＤがアプリケーションａ、アプリケーションｂの後続処理として処理結果データの送信先に加わることで、処理結果送信先テーブル２６１のようになる。
【００３２】
この処理が完了すると、切替制御部２１０からクラスタ構成テーブル２５１、処理結果送信先テーブル２６１がサーバＡ、Ｂ、Ｃ、Ｄに一括して配布される（ステップＳ１８２４）。これによって、各サーバ上でクラスタ構成テーブル１１７Ａ〜１１７Ｄ、処理結果送信先テーブル１１８Ａ〜１１８Ｄが更新される（ステップＳ１９Ａ１、ステップＳ１９Ｄ１）。これによりサーバＤでは更新されたクラスタ構成テーブル１１７Ｄに基づいてアプリケーションａが起動される（ステップＳ１９Ｄ２）。
【００３３】
次に、図１５を用いてテーブル更新後の受信データ処理時のクラスタシステムの動作例を説明する。既にアプリケーションａで処理されるデータｘがサーバＡの受信データキュー１４１ＡおよびサーバＢの受信データキュー１４１Ｂに格納されているとする。このときサーバＤ上の待機系で稼動するアプリケーションａに関するデータキューは他のサーバ上の運用系アプリケーションａと同期がとれていない状態にあり、構成制御サーバ上のクラスタ構成テーブル２６１では、初回の同期が完了するまでサーバＤのアプリケーションａは待機系準備中のステータスにしておく（ステップＳ１９２１）。
【００３４】
続いて、サーバＡ上の受信データキュー管理部１１５Ａはアプリケーションａが運用系で稼動していることを確認し（ステップＳ１９Ａ２）、受信データキュー１４１Ａの先頭データｘを未処理データキュー１３１Ａにエンキューする（ステップＳ１９Ａ３）。尚、例えば、サーバＡ上でアプリケーションａが運用系で稼動しておらず、更新後にステップＳ１９Ａ２でＹＥＳとならない場合は、受信データキュー１４１Ａをそのままの状態に維持し、運用系からの同期データを待つこととなる（ステップＳ１９Ａ１０）。
【００３５】
次に、図１６を用いてデータ同期時のクラスタシステムの動作例を説明する。サーバＡ上の未処理データキュー１３１Ａからアプリケーションａによりデータｘがデキューされる（ステップＳ１９Ａ４）。サーバＡ上の未処理データキュー１３１Ａからアプリケーションａによりｘがデキューされたとき、同期データ送信部１１１Ａは、待機系アプリケーションａを稼動させるサーバに対してアプリケーションａのデータＳ１、デキューしたデータｘを同期データとして送信する（ステップＳ１９Ａ５）。同期データはサーバＢの同期データ受信部１１２Ｂ、サーバＤの同期データ受信部１１２Ｄでそれぞれ受信される（ステップＳ１９Ｄ３）。各サーバではデータｘを先頭にするように自サーバの受信データキュー内のデータをデキューする（ステップＳ１９Ｄ４）。これにより、サーバＡでのアプリケーションａの処理状況をサーバＢおよび、新たに待機系で加わったサーバＤにも反映させることが出来る。
【００３６】
続いて実施の形態１と同様にサーバＢとサーバＤのアプリケーションａのデータをＳ１に書き換える（ステップＳ１９Ｄ５）。この同期動作が完了したら、サーバＢ、Ｄのそれぞれの同期データ受信部１１２Ｂ、１１２ＤはサーバＡおよび構成制御サーバ上の状態監視部２２０に同期完了を通知する（ステップＳ１９Ｄ６）。状態監視部２２０はクラスタ構成テーブル再構成部２３０に、サーバＤ上のアプリケーションａが待機系として準備完了したことを通知し、クラスタ構成テーブル２５１ではサーバＤ上のアプリケーションａが準備中の状態でなくなり、待機系として確定する（ステップＳ１９２２）。
【００３７】
次に、図１７を用いて処理結果送信時のクラスタシステムの動作例を説明する。同期完了の通知を受けたサーバＡ（ステップＳ１９Ａ６）はアプリケーションａがデータｘを処理し（ステップＳ１９Ａ７）、処理結果データｘ’を生成する。次に、アプリケーションａは処理結果データｘ’を処理結果送信用キュー１５１Ａにエンキュー（ステップＳ１９Ａ８）。更新された処理結果送信先テーブル２６１を参照し、後続処理であるアプリケーションｃが稼動するサーバＣおよびサーバＤに処理結果データｘ’を送信する（ステップＳ１９Ａ９）。このとき、サーバ増設後にアプリケーションａおよびアプリケーションｃを待機系として稼動したサーバＤに対して、同期データの送信先および処理結果データの送信先の整合性が保たれている。
【００３８】
以上のように、本発明ではデータ同期をする前に、前記構成制御サーバがクラスタ構成テーブルの再構成を前記処理結果送信先テーブルに反映させ、これらの情報をサーバ群に配布することにより、データロストを抑制したデータ同期が可能となる効果に加え、データの送信先の整合性を保ったままクラスタシステムの再構成を行うことができる。すなわち、アプリケーションの再配置による切り替え後、新たにアプリケーションが稼動し始めたサーバに対して、データ送信先の変更が遅れることはなく、また前段処理が行われているサーバからデータが送られるべきサーバに対してデータが送信されないといったエラーを防止することができ、運用系アプリケーションと待機系アプリケーションで処理状態の整合を保ったままクラスタシステムの再構成をすることができる。また、これらの動作はアプリケーションの動作とは独立し、アプリケーションには依存しないため、実施の形態１と同様に本実施の形態を実現するためにアプリケーションに機能を求めることがない。これにより、アプリケーション開発の負荷を軽減できるとともに、クラスタシステムで稼動できるアプリケーションの自由度が増すこととなる。
【００３９】
実施の形態３．
本実施の形態ではサーバでの障害発生時の処理の流れについて示す。一例として、サーバＡで障害が発生したときのアプリケーションａの動作の引継ぎに関して説明する。サーバ、構成制御サーバの構成は実施の形態１の図２、３と同様である。また、クラスタシステムの初期状態として、サーバＡ、サーバＢ、サーバＣ上の各アプリケーションは図４のクラスタ構成テーブル２５０、図５の処理結果送信先テーブル２６０にしたがって稼動、処理結果送信を行っているものとする。以降の説明において、図面において実施の形態１、２と同一の機能を有する構成は、実施の形態１、２と同一の符号を付して説明を省略する。
【００４０】
図２０はサーバ障害発生時、図２１はクラスタ構成テーブルおよび処理結果送信先テーブルが更新された時のクラスタシステムの動作例を示す。図２２は障害発生時に再構成されたクラスタ構成テーブルを示す。図２３は障害発生からサーバＢでのアプリケーションａの動作の引継時までの動作例を示すフローチャートである。尚、アプリケーション稼動部は各サーバに複数あってもよい。また、説明において障害が発生するサーバは１つだけであるが、複数のサーバに障害が発生したとしても本実施の形態を適用することができる。
【００４１】
まず、図２０を用いて障害発生時のクラスタシステムの動作例を説明する。サーバＡの処理結果受信部１１４ＡおよびサーバＢの処理結果受信部１１４Ｂがアプリケーションａで処理するデータｘ、データｙを受信する。実施の形態１と同様に、データｘ、データｙは各サーバ上でアプリケーションａについての受信データキュー１４１Ａ、１４１Ｂにエンキューされる。続いて、サーバＡでは受信データキュー管理部１１５Ａがアプリケーションａを運用系で稼動していることを確認し、データｘがアプリケーションａの未処理データキュー１３１Ａにエンキューされる。次に、サーバＡ上のアプリケーションａが未処理データキュー１３１Ａからデータｘをデキューする（ステップＳ２３Ａ１）。このデキューを契機に同期データ送信部１１１Ａはデキューしたデータｘおよびアプリケーションａ用データ領域１２１ＡのデータＳ１を待機系に送信する（ステップＳ２３Ａ２）。同期データを受信したサーバＢの同期データ受信部１１２Ｂでは、受信データキュー１４１Ｂの先頭データをデータｘになるようにし（ステップＳ２３Ｂ１）、アプリケーションａ用データ領域１２１ＢのデータをＳ１に書き換え（ステップＳ２３Ｂ２）、同期完了を運用系に通知する（ステップＳ２３Ｂ３）。上記のデータ同期動作は実施の形態１にて示したものと同様である。ここで同期完了の通知を受けたサーバＡ（ステップＳ２３Ａ３）がアプリケーションａにてｘを処理開始（ステップＳ２３Ａ４）し、処理が完了する前にサーバＡにて障害が発生したとする（ステップＳ２３Ａ５）。
【００４２】
この場合のクラスタシステムの動作例について説明する。まず、構成制御サーバ２上の状態監視部２２０がサーバＡの障害発生を検知する（ステップＳ２３２１）。次に、クラスタ構成テーブル再構成部２３０がクラスタ構成テーブル２５０を再構成する。本実施の形態ではサーバＡが故障していること、および、サーバＢのアプリケーションａの稼動を待機系から運用系に変更したクラスタ構成テーブル２５２にする（ステップＳ２３２２）。次に、処理結果送信先テーブル再構成部２４０が処理結果送信先テーブル２６０を再構成する（ステップＳ２３２３）。本実施の形態においては処理結果データの送信先に故障が発生したサーバＡは含まれていないため、処理結果送信先テーブルの内容に更新前後で変化はない。仮に処理結果データの送信先のサーバが故障している場合には、その故障が発生したサーバは送信先から除外される。また、サーバＢの待機系アプリケーションａが運用系アプリケーションａに切り替わることによって、待機系アプリケーションａを稼動するサーバがなくなった場合は、新たに待機系アプリケーションａを稼動するサーバが割り当てられる。尚、本実施の形態ではサーバＣが待機系アプリケーションａを稼動しているため新たな割り当てをしなくてもよい。これらのクラスタ再構成がなされた後に、データ同期がされるので、データ送信先の変更が遅れることはなく、また、新たに待機系アプリケーションを立ち上げたサーバに対し、前段処理が行われているサーバから待機系に対してデータが送信されないといったエラーを防止することができ、運用系と待機系で処理状態の整合を保ったままクラスタシステムの再構成をすることができる。
【００４３】
クラスタ構成テーブル２５２および処理結果送信先テーブル２６０のデータは、構成制御サーバの切替制御部２１０からサーバＢ、Ｃに配布される（ステップＳ２３２４）。これにより、サーバＢ上のクラスタ構成テーブル１１７Ｂ、および処理結果送信先テーブル１１８Ｂを更新する（ステップＳ２３Ｂ４）。
【００４４】
次に、図２１を用いて障害発生によるテーブル更新後のクラスタシステムの動作例を説明する。受信データキュー管理部１１５Ｂはアプリケーションａが運用系であるか待機系であるかを、クラスタ構成テーブル１１７Ｂを参照してチェックする（ステップＳ２３Ｂ５）。このとき、サーバＢ上のアプリケーションａは運用系に切り替わっているため、受信データキュー１４１Ｂの先頭データｘを未処理データキュー１３１Ｂにエンキューする（ステップＳ２３Ｂ６）。次に、アプリケーションａは未処理データキュー１３１Ｂから先頭データであるデータｘをデキューし、処理を実行する（ステップＳ２３Ｂ７）。尚、例えば、サーバＢのアプリケーションａが運用系でない場合、または、アプリケーションａのプロセスが稼動していない場合は、受信データキューをそのままの状態で保持する（ステップＳ２１Ｂ８）。サーバＢ上のアプリケーションａのデータはＳ１であり、サーバＡ上のアプリケーションａが処理を開始するデータｘと同じになっている。従って、サーバＡの故障によってサーバＡ上でアプリケーションａの稼動時に処理を完了していない最後のデータｘについて、サーバＢ上のアプリケーションａが、サーバＡのアプリケーションａの処理開始前の時点から、データｘを処理開始できるようになっている。
【００４５】
以上のように、運用系アプリケーションを稼動させるサーバにて故障が発生して、運用系アプリケーションがデータの処理を中断させてしまっても、旧運用系アプリケーションがデータの処理を開始する前の状態で、待機系アプリケーションが処理再開できるようになる。これによって、待機系アプリケーションが運用系に切り替わる際のデータロストを防止しつつ、運用系／待機系アプリケーションの切り替えを実現することができる。また、これらの動作はアプリケーションの動作とは独立し、アプリケーションには依存しないため、実施の形態１と同様に本実施の形態を実現するためにアプリケーションに機能を求めることがない。これにより、アプリケーション開発の負荷を軽減できるとともに、クラスタシステムで稼動できるアプリケーションの自由度が増すこととなる。
【符号の説明】
【００４６】
１                サーバ
２                構成制御サーバ
１１              構成制御手段
１２              共有メモリ
１０１〜１０３    アプリケーション稼動部
１１１            同期データ送信部
１１２            同期データ受信部
１１３            処理結果送信部
１１４            処理結果受信部
１１５            受信データキュー管理部
１１６            処理結果送信用キュー管理部
１１７            クラスタ構成テーブル
１１８            処理結果送信先テーブル
１２１〜１２３    アプリケーション用データ領域
１３１〜１３３    未処理データキュー
１４１〜１４３    受信データキュー
１５１〜１５３    処理結果送信用キュー
２０１            アプリケーション優先度情報テーブル
２０２            アプリケーション負荷情報テーブル
２１０            切替制御部
２２０            状態監視部
２３０            クラスタ構成テーブル再構成部
２４０            処理結果送信先テーブル再構成部
２５０            クラスタ構成テーブル
２６０            処理結果送信先テーブル
【図１】
2012064109.tif 000003
【図２】
2012064109.tif 000004
【図３】
2012064109.tif 000005
【図４】
2012064109.tif 000006
【図５】
2012064109.tif 000007
【図６】
2012064109.tif 000008
【図７】
2012064109.tif 000009
【図８】
2012064109.tif 000010
【図９】
2012064109.tif 000011
【図１０】
2012064109.tif 000012
【図１１】
2012064109.tif 000013
【図１２】
2012064109.tif 000014
【図１３】
2012064109.tif 000015
【図１４】
2012064109.tif 000016
【図１５】
2012064109.tif 000017
【図１６】
2012064109.tif 000018
【図１７】
2012064109.tif 000019
【図１８】
2012064109.tif 000020
【図１９】
2012064109.tif 000021
【図２０】
2012064109.tif 000022
【図２１】
2012064109.tif 000023
【図２２】
2012064109.tif 000024
【図２３】
2012064109.tif 000025