JP2008186359A - サービス管理装置、サービス管理方法、およびサービス管理プログラム - Google Patents

Abstract

【課題】障害発生時や負荷増大時に予備サーバを起動するよりも効率的に障害対応あるいは負荷分散を行うことのできるサービス管理方法を提供する。
【解決手段】稼動状況監視手段１２は、サーバ２の障害状況、負荷状況を監視する。アプリ管理制御手段１４は、サーバ２の稼動状況に応じて他のサーバ２上でのアプリケーションプログラム起動の必要性を判断し、アプリ管理テーブル記憶部２２に記憶されたアプリ管理テーブルに登録された情報に基づいて運用可能なサーバ２を選択する。運用サーバ通知手段１６は、サーバ２に何らかの変更が必要な場合に変更内容を通知する。追加サーバ通知手段１８は、新たに起動された追加サーバに、ＩＰアドレスや起動すべきアプリケーションプログラムの情報を通知する。アプリ管理テーブル記憶部２２に記憶されるアプリ管理テーブルには、各サーバ２におけるアプリケーションプログラムの搭載状況や運用状況が登録されている。
【選択図】図３

Description

本発明は、アプリケーションプログラムを搭載したサーバによって提供されるサービスを管理する装置に係り、特に、サーバの稼動状況に応じてアプリケーションプログラムを起動する方法に関する。

各種サービスを提供するサーバに障害が発生した場合、あるいは負荷が増大した場合、何らかの対処を行って速やかにサービスを再開あるいは継続する必要がある。このために、従来は、たとえば図８に示すように、サービスごとに予備サーバを用意しておき、障害発生時には予備サーバを起動してサーバを交替し、負荷増大時には負荷分散のための予備サーバを追加起動することが行われている（たとえば特許文献１）。
特開２００４−１０４７３２号公報

しかしながら、障害はそれほど頻繁には発生しないため、代替サーバとして予備サーバを用意することは非効率であり、予備サーバによらない代替方法が望まれる。また、負荷増大時に予備サーバを追加起動したあと、負荷が低下すれば実質的に予備サーバは必要なくなるため、安易に予備サーバを追加起動することも非効率であり、予備サーバによらない負荷分散方法が望まれる。

本発明は、障害発生時や負荷増大時に予備サーバを起動するよりも効率的に障害対応あるいは負荷分散を行うことのできるサービス管理方法を提供することを目的とする。

本発明にかかるサービス管理装置は、アプリケーションプログラムを搭載した複数のサーバと通信可能なサービス管理装置であって、複数のサーバに搭載されているアプリケーションプログラムの運用状況を含む情報を登録したアプリ管理テーブルを記憶する記憶部と、アプリケーションプログラムを起動している第１のサーバの稼動状況を監視する手段と、第１のサーバの稼動状況に基づいてアプリケーションプログラムを他のサーバ上で起動することを決定する手段と、当該アプリケーションプログラムを搭載し、かつ当該アプリケーションプログラムを起動していない第２のサーバを、アプリ管理テーブルに登録された情報に基づいて検出する手段と、第２のサーバに当該アプリケーションプログラムの起動を指示する手段とを備えたことを特徴とする。

本発明にかかるサービス管理装置は、さらに、第１のサーバをネットワーク上で識別するためのアドレスを、第２のサーバのアドレスとして設定するように第２のサーバに指示する手段を備えてもよい。

本発明によれば、１台のサーバに複数のアプリケーションプログラムを搭載し、必要に応じて適切なアプリケーションプログラムを起動することにより、効率的に障害対応あるいは負荷分散を行うことのできるサービス管理方法を提供することが可能となる。

以下、図面に基づいて実施例を説明する。

図１は、本発明の概念を説明する図である。図１には、第１サービスと第２サービスの２つのサービスを提供する場合の例を示してある。第１サービスおよび第２サービスの具体的な内容は何でもよいが、たとえば、メールサーバとしてのサービス、ｗｅｂサーバとしてのサービス、ファイルサーバとしてのサービス、チャットサーバとしてのサービスなどである。第１サービスは１台のサーバ２（第１サービス用窓口サーバ）が提供している。第２サービスは２台のサーバ２（第２サービス用窓口サーバ、第２サービス用補助サーバ）が提供しており、第２サービス用窓口サーバが第２サービス用補助サーバとの間で負荷分散を行っている。クライアント６からは各窓口サーバが各サービスのホストサーバと見えている。すなわち、クライアント６は、第１サービスを利用するために第１サービス用窓口サーバのＩＰアドレスにアクセスし、第２サービスを利用するために第２サービス用窓口サーバのＩＰアドレスにアクセスする。第１サービス用窓口サーバでは第１サービス用のアプリケーションプログラムである第１アプリが起動されているが、第１サービス用窓口サーバには第２サービス用のアプリケーションプログラムである第２アプリも搭載されている。同様に第２サービス用窓口サーバおよび第２サービス用補助サーバでは第２サービス用のアプリケーションプログラムである第２アプリが起動されているが、第２サービス用窓口サーバおよび第２サービス用補助サーバには第１サービス用のアプリケーションプログラムである第１アプリも搭載されている。

サービス管理装置１は、各サーバ２に搭載されているアプリケーションプログラムの情報や各サーバ２の運用状況を登録したアプリ管理テーブルを保持している。いずれかのサーバ２に障害が発生した場合、あるいは、特定のサーバ２の負荷が増大した場合に、サービス管理装置１は、それらのサーバ２で運用していたサービスを提供するためのアプリケーションプログラムを他のサーバ２で起動して、代替あるいは負荷分散を図る。

図２は、本発明の実施例におけるアプリ管理テーブルの例を示す図である。アプリ管理テーブル中の各レコードが各サーバ２に対応しており、各レコードには、各サーバ２を特定するための情報であるサーバＩＤ１０２、各サーバ２に割り振られたＩＰアドレスであるサーバアドレス１０４、各サービスを提供するためのアプリケーションプログラムの搭載／運用状況を示すコードが登録されている。搭載／運用状況を示すコードとしては「窓口」「補助」「Ｏ」「−」の４種類がある。「窓口」はアプリケーションプログラムが起動されており、このサーバ２がこのサービスの窓口サーバとして運用されていることを示す。すなわち、このサービスのホストサーバのアドレスとして周知されているＩＰアドレスがサーバアドレス１０４欄に登録されている。「補助」はアプリケーションプログラムが起動されており、このサーバがこのサービスの補助サーバとして運用されていることを示す。すなわち、窓口サーバとはなっていないが、窓口サーバとの負荷分散によってサービスを提供していることを示す。「Ｏ」はアプリケーションプログラムが搭載されているが起動されていないことを示す。「−」はアプリケーションプログラムが搭載されていないことを示す。

図２に示したアプリ管理テーブルの例を見ると、サーバＳ００１およびサーバＳ００６には第１サービスから第４サービスまでのすべてのアプリケーションプログラムが搭載されているが、いずれも運用されておらず、予備サーバとして存在していることがわかる。サーバＳ００２には第３サービスおよび第４サービスのアプリケーションプログラムが搭載されており、第３サービスの窓口サーバとして運用されているが、第４サービスは提供していない。サーバＳ００３には第１サービスから第４サービスまでのすべてのアプリケーションプログラムが搭載されており、第１サービスの窓口サーバとして運用されているほか、第３サービスの補助サーバとしても運用されているが、第２サービスおよび第４サービスは提供していない。サーバＳ００４には第２サービスおよび第４サービスのアプリケーションプログラムが搭載されており、第２サービスの窓口サーバとして運用されているが、第４サービスは提供していない。サーバＳ００５には第１サービスから第４サービスまでのすべてのアプリケーションプログラムが搭載されており、第４サービスの窓口サーバとして運用されているほか、第２サービスの補助サーバとしても運用されているが、第１サービスおよび第３サービスは提供していない。サーバ２がいずれかのサービスの窓口サーバとして運用されている場合には、サーバアドレス１０４欄にはそのサービスのホストサーバのアドレスとして周知されているＩＰアドレスが登録されている。したがって、ホストサーバのＩＰアドレスが異なる複数のサービスの窓口サーバとして、１台のサーバ２が兼用されることはない。

図３は、本発明の実施例にかかるサービス管理装置１のシステム構成を示す図である。本実施例にかかるサービス管理装置１は、窓口サーバあるいは補助サーバとして既に運用されているサーバ２（運用サーバと呼ぶ）の稼動状況を監視する稼動状況監視手段１２と、運用サーバの稼動状況に応じて他のサーバ２におけるアプリケーションプログラムの起動を決定するアプリ管理制御手段１４と、運用サーバに対して何らかの変更を通知する運用サーバ通知手段１６と、新たに起動されたサーバ２（追加サーバと呼ぶ）に指示情報を通知する追加サーバ通知手段１８と、オペレータの入出力を処理するオペレータ入出力手段２０と、サーバ２の運用状況を管理するためのアプリ管理テーブルを記憶するアプリ管理テーブル記憶部２２と、サーバ２との通信を行う通信手段２４とを含む。

稼動状況監視手段１２は、運用サーバと通信することにより、運用サーバの障害状況、負荷状況を監視する。

アプリ管理制御手段１４は、運用サーバの稼動状況に応じて他のサーバ２上でのアプリケーションプログラム起動の必要性を判断し、アプリ管理テーブル記憶部２２に記憶されたアプリ管理テーブルに登録された情報に基づいて運用可能なサーバ２を選択し、アプリ管理テーブルの内容を更新する。また、サービス管理装置１内で実行される処理のうち、他の手段によって実行される処理以外はすべてアプリ管理制御手段１４が実行するものとする。

運用サーバ通知手段１６は、運用サーバに何らかの変更が必要な場合に変更内容を通知する。

追加サーバ通知手段１８は、新たに起動された追加サーバに、ＩＰアドレスや起動すべきアプリケーションプログラムの情報を通知する。

オペレータ入出力手段２０は、オペレータからの入力を受付け、オペレータに対して情報を出力する。

アプリ管理テーブル記憶部２２に記憶されるアプリ管理テーブルには、各サーバ２に搭載されているアプリケーションプログラムの情報や、各サーバ２が現在どのサービスにどのような役割で運用されているかという情報が登録されている。

通信手段２４は、稼動状況監視手段１２と運用サーバとの通信、運用サーバ通知手段１６と運用サーバとの通信、および追加サーバ通知手段１８と追加サーバとの通信を実行する。

図４は、本発明の実施例にかかるサービス管理装置１のフローチャートである。本実施例にかかるサービス管理装置１の処理の流れを図４のステップＳ１０２からステップＳ１３０の順を追って説明する。なお、本実施例にかかるサービス管理装置１は、ＤＨＣＰサーバ上に実現されているものとする。ＤＨＣＰサーバの詳細については、当業者にとって周知のため説明を割愛する。

（ステップＳ１０２）稼動状況監視手段１２は、運用サーバの障害状況および負荷状況を含む稼動状況を監視しており、その稼動状況の情報をアプリ管理制御手段１４に通知している。稼動状況の監視方法は如何様でもよい。たとえば、運用サーバ側から適時報告させてもよいし、稼動状況監視手段１２側からの問合せに対して運用サーバが回答する形をとってもよい。アプリ管理制御手段１４は稼動状況監視手段１２から通知された稼動状況の情報に基づいてサービス運用形態の更新（サービス管理サーバの交替、アプリの追加起動）を決定する。更新不要と判断した場合は、新たな稼動状況の報告を待ち、改めて更新必要性の判断を行う。

運用サーバのいずれかが通信不能に陥った場合、アプリ管理制御手段１４は該当する運用サーバの交替が必要と判断する。また、運用サーバのいずれかについて障害が報告された場合にもその障害の程度に応じて、アプリ管理制御手段１４は該当する運用サーバの交替が必要と判断する。どの程度の障害で運用サーバの交替が必要と判断するかの基準は任意でよい。

負荷状況は窓口サーバから報告されるものとする。あるサービスを提供している窓口サーバは、自身および補助サーバの処理能力に余裕がなくなったと判断したときに稼動状況監視手段１２に対して警告を発する。警告を発した窓口サーバを警告サーバと呼ぶ。アプリ管理制御手段１４は、警告サーバが窓口サーバとなって提供しているサービス（対象サービスと呼ぶ）の負荷を分散させるために別のサーバ２で該当するアプリケーションプログラムの追加起動が必要と判断する。どの程度の負荷で処理能力に余裕がなくなったと判断するかの基準は任意でよい。窓口サーバからは単に負荷の程度を報告させ、処理能力の余裕の有無についてはサービス管理装置１が判断するようにしてもよい。また、窓口サーバだけでなく、補助サーバも含めた各サーバ２から負荷状況をサービス管理装置１に報告するようにしてもよい。

（ステップＳ１０４）アプリケーションプログラムの追加起動が必要と判断された場合（ステップＳ１０２：追加）、アプリ管理制御手段１４はアプリ管理テーブルに登録された情報に基づいて、運用サーバ上でアプリケーションプログラムの追加起動が可能か否かを判断する。この手順を次に説明する。

アプリ管理制御手段１４は、アプリ管理テーブル中の、警告サーバに関するレコードから搭載／運用状況が「窓口」と登録されているサービスを抽出する。すなわち、対象サービスを特定する。現在運用中のサーバ２で対象サービスの搭載／運用状況が「Ｏ」となっているサーバ２があれば、このサーバ２上でアプリケーションプログラムの追加起動が可能と判断する。

（ステップＳ１０６）アプリケーションプログラムの追加起動が可能と判断された場合（ステップＳ１０４：Ｙｅｓ）、追加起動可能と判断された運用サーバ上で当該アプリケーションプログラムを追加起動する。追加起動の手順を次に説明する。

アプリ管理制御手段１４は、当該サーバ２のＩＰアドレスと当該アプリケーションプログラムを特定する情報であるアプリＩＤを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、通知されたＩＰアドレスに宛てて、通知されたアプリＩＤを通知する。この通知を受けた運用サーバは、通知されたアプリＩＤで特定されるアプリケーションプログラムを起動する。

（ステップＳ１０８）窓口サーバに対して新たな補助サーバの情報を通知する。この手順を次に説明する。

アプリ管理制御手段１４は、警告サーバのＩＰアドレスおよびアプリケーションプログラムを追加起動した運用サーバのＩＰアドレスを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、窓口サーバのＩＰアドレスに宛てて、アプリケーションプログラムを追加起動した運用サーバのＩＰアドレスを通知する。この通知を受けた窓口サーバは、以降、通知されたＩＰアドレスを持つ運用サーバにも負荷を分散する。

（ステップＳ１２０）アプリ管理制御手段１４は、アプリ管理テーブルを更新する。アプリケーションプログラム追加の場合は、アプリ管理テーブル中の、アプリケーションプログラムを追加起動した運用サーバに関するレコードにおいて、対象サービスの搭載／運用状況を「補助」に変更する。

（ステップＳ１１０）アプリケーションプログラムの追加起動が不可能と判断された場合（ステップＳ１０４：Ｎｏ）、アプリ管理制御手段１４はアプリ管理テーブルに登録された情報に基づいて、現在運用されていないサーバ２（予備サーバと呼ぶ）を起動することでアプリケーションプログラムの追加起動が可能か否かを判断する。すなわち、当該アプリケーションプログラムを搭載している予備サーバがあればこの予備サーバを起動することでアプリケーションプログラムの追加起動が可能と判断する。

（ステップＳ１１２）予備サーバを起動することでアプリケーションプログラムの追加起動が可能と判断された場合（ステップＳ１１０：Ｙｅｓ）、当該予備サーバを追加サーバとして起動する。追加サーバ起動の手順を次に説明する。

アプリ管理制御手段１４は、追加サーバのサーバＩＤ１０２をオペレータ入出力手段２０に通知する。オペレータ入出力手段２０は、追加サーバのサーバＩＤ１０２を出力する。出力されたサーバＩＤ１０２に従って、オペレータが追加サーバを起動する。起動された追加サーバはサービス管理装置１にアクセスする。

（ステップＳ１１４）追加サーバにＩＰアドレスを設定する。ＩＰアドレス設定の手順を次に説明する。

アプリ管理制御手段１４は、追加サーバのサーバＩＤ１０２および使用可能で現在使用されていないＩＰアドレスを追加サーバ通知手段１８に通知する。追加サーバ通知手段１８は、通知されたサーバＩＤ１０２を持つ追加サーバにＩＰアドレスを通知する。追加サーバは通知されたＩＰアドレスを自身のＩＰアドレスとして設定する。

（ステップＳ１１６）アプリ管理テーブルに登録された情報に基づいて、追加サーバ上でアプリケーションプログラムを起動する。アプリケーションプログラム起動の手順を次に説明する。

アプリ管理制御手段１４は、対象サービスを提供するためのアプリケーションプログラムを特定する情報であるアプリＩＤを追加サーバ通知手段１８に通知する。追加サーバ通知手段１８は、通知されたアプリＩＤを追加サーバに通知する。追加サーバは通知されたアプリＩＤで特定されるアプリケーションプログラムを起動する。

（ステップＳ１１８）窓口サーバに追加サーバを補助サーバとして通知する。補助サーバ通知の手順を次に説明する。

アプリ管理制御手段１４は、警告サーバのＩＰアドレスと追加サーバのＩＰアドレスを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、警告サーバのＩＰアドレスに宛てて追加サーバのＩＰアドレスを通知する。警告サーバは、以後、通知されたＩＰアドレスを持つサーバ２も含めて負荷分散を行う。

（ステップＳ１２０）アプリ管理制御手段１４は、アプリ管理テーブルを更新する。サーバ追加の場合は、アプリ管理テーブル中の、追加サーバに関するレコードにおいて、サーバアドレス１０４欄にＩＰアドレスを登録し、対象サービスの搭載／運用状況を「補助」に変更する。

（ステップＳ１２２）予備サーバの起動によってもアプリケーションプログラムの追加起動が不可能と判断された場合（ステップＳ１１０：Ｎｏ）、サービス管理装置１は警告を出力する。警告出力の手順を次に説明する。

アプリ管理制御手段１４は、対象サービスを特定する情報であるサービスＩＤをオペレータ入出力手段２０に通知する。オペレータ入出力手段２０は、通知されたサービスＩＤを出力し、負荷の増大をオペレータに警告する。

（ステップＳ１３０）運用サーバの交替が必要と判断された場合（ステップＳ１０２：交替）、サーバ交替処理を行う。サーバ交替処理の詳細については次に説明する。

図５は、本発明の実施例におけるサーバ交替処理のフローチャートである。本実施例におけるサーバ交替処理の流れを図５のステップＳ１３２からステップＳ１３８の順を追って説明する。なお、図５に示すサーバ交替処理は、交替すべき運用サーバ（障害サーバと呼ぶ）で運用されていた各サービスについて実行される。図５の説明においては、障害サーバで運用されていた各サービスを対象サービスと呼ぶ。

（ステップＳ１３２）障害サーバが通信不能でない場合、アプリ管理制御手段１４は、障害サーバのＩＰアドレスを稼動状況監視手段１２に通知する。稼動状況監視手段１２は、通知されたＩＰアドレスに宛てて停止指示を通知する。停止指示を受け取った障害サーバは、サービスを停止し、自身をシャットダウンする。

（ステップＳ１３４）アプリ管理制御手段１４は、対象サービスに関して交替先のサーバを決定するが、そのために、障害サーバが対象サービスの提供に際して窓口サーバとして運用されていたか、補助サーバとして運用されていたかを、アプリ管理テーブルに登録された情報に基づいて判断する。すなわち、アプリ管理テーブル中の、障害サーバに関するレコードにおいて、対象サービスの搭載／運用状況が「窓口」と登録されている場合は窓口サーバとして運用されていたと判断し、対象サービスの搭載／運用状況が「補助」と登録されている場合は補助サーバとして運用されていたと判断する。

（ステップＳ１３６）障害サーバが窓口サーバとして運用されていた場合（ステップＳ１３４：Ｙｅｓ）、窓口サーバ交替処理を行う。窓口サーバ交替処理の詳細については別途説明する。

（ステップＳ１３８）障害サーバが補助サーバとして運用されていた場合（ステップＳ１３４：Ｎｏ）、補助サーバ交替処理を行う。補助サーバ交替処理の詳細については別途説明する。

図６は、本発明の実施例における窓口サーバ交替処理のフローチャートである。本実施例における窓口サーバ交替処理の流れを図６のステップＳ２０２からステップＳ２３２の順を追って説明する。なお、図６の説明においては、図５の説明と同様、交替すべき運用サーバを障害サーバと呼び、障害サーバで運用されていた各サービスを対象サービスと呼ぶ。

（ステップＳ２０２）対象サービスを提供するにあたって補助サーバとして運用されているサーバ２が存在する場合には、その補助サーバを窓口サーバに変更できる可能性がある。補助サーバを窓口サーバに変更することを昇格と呼ぶ。アプリ管理制御手段１４は、アプリ管理テーブルに登録された情報に基づいてサーバ２の昇格が可能か否かを判断する。そのために、アプリ管理制御手段１４は、アプリ管理テーブルにおいて、対象サービスの搭載／運用状況が「補助」と登録され、他のどのサービスの搭載／運用状況にも「窓口」と登録されていないレコードを一つ抽出する。抽出できれば昇格可能であり、抽出できなければ昇格不可能である。

（ステップＳ２０４）昇格可能な場合（ステップ２０２：Ｙｅｓ）、抽出されたレコードに対応するサーバ２（昇格サーバと呼ぶ）のＩＰアドレスを変更する。ＩＰアドレス変更の手順を次に説明する。

アプリ管理制御手段１４は、昇格サーバのＩＰアドレスおよび障害サーバのＩＰアドレスを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、昇格サーバのＩＰアドレスに宛てて障害サーバのＩＰアドレスを通知する。昇格サーバは通知されたＩＰアドレスを自身のＩＰアドレスとして設定する。

（ステップＳ２０６）昇格サーバに補助サーバを通知する。補助サーバ通知の手順を次に説明する。

アプリ管理制御手段１４は、アプリ管理テーブルにおいて、昇格サーバ以外で、対象サービスの搭載／運用状況が「補助」と登録されているすべてのレコードについて、サーバアドレス１０４欄からＩＰアドレスを抽出する。抽出されたＩＰアドレスが一つでもあれば、アプリ管理制御手段１４は、抽出されたＩＰアドレスおよび昇格サーバのＩＰアドレスを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、昇格サーバのＩＰアドレスに宛てて、抽出されたＩＰアドレスを通知する。昇格サーバは、以後、通知されたＩＰアドレスを持つサーバも含めて負荷分散を行う。

（ステップＳ２３０）アプリ管理制御手段１４は、アプリ管理テーブルを更新する。サーバ昇格の場合は、アプリ管理テーブル中の、障害サーバのサーバアドレス１０４を昇格サーバのサーバアドレス１０４欄に移動し、昇格サーバにおける対象サービスの搭載／運用状況を「窓口」に変更する。その後、障害サーバに関するレコードを抹消する。

（ステップＳ２１０）昇格不可能な場合（ステップ２０２：Ｎｏ）でも、現在対象サービスが起動されていない運用サーバを窓口サーバに変更できる可能性がある。これを代行と呼ぶ。アプリ管理制御手段１４は、アプリ管理テーブルに登録された情報に基づいてサーバの代行が可能か否かを判断する。そのために、アプリ管理制御手段１４は、アプリ管理テーブルにおいて、対象サービスの搭載／運用状況が「Ｏ」と登録され、他のどのサービスの搭載／運用状況も「窓口」と登録されていない運用サーバのレコードを一つ抽出する。抽出できれば代行可能であり、抽出できなければ代行不可能である。

（ステップＳ２１２）代行可能な場合（ステップ２１０：Ｙｅｓ）、抽出されたレコードに対応するサーバ２（代行サーバと呼ぶ）において対象サービスを提供するためのアプリケーションプログラムを起動する。アプリケーションプログラム起動の手順を次に説明する。

アプリ管理制御手段１４は、代行サーバのＩＰアドレスおよび対象サービスを提供するためのアプリケーションプログラムを特定する情報であるアプリＩＤを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、通知されたＩＰアドレスに宛てて、通知されたアプリＩＤを通知し、代行サーバは通知されたアプリＩＤで特定されるアプリケーションプログラムを起動する。

（ステップＳ２１４）代行サーバのＩＰアドレスを変更する。ＩＰアドレス変更の手順を次に説明する。

アプリ管理制御手段１４は、代行サーバのＩＰアドレスおよび障害サーバのＩＰアドレスを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、代行サーバのＩＰアドレスに宛てて障害サーバのＩＰアドレスを通知する。代行サーバは通知されたＩＰアドレスを自身のＩＰアドレスとして設定する。

（ステップＳ２１６）代行サーバに補助サーバを通知する。補助サーバ通知の手順を次に説明する。

アプリ管理制御手段１４は、アプリ管理テーブルにおいて、対象サービスの搭載／運用状況が「補助」と登録されているすべてのレコードのサーバアドレス１０４欄からＩＰアドレスを抽出する。抽出されたＩＰアドレスが一つでもあれば、アプリ管理制御手段１４は、抽出されたＩＰアドレスおよび代行サーバのＩＰアドレスを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、代行サーバのＩＰアドレスに宛てて、抽出されたＩＰアドレスを通知する。代行サーバは、以後、通知されたＩＰアドレスを持つサーバも含めて負荷分散を行う。

（ステップＳ２３０）アプリ管理制御手段１４は、アプリ管理テーブルを更新する。サーバ代行の場合は、アプリ管理テーブル中の、障害サーバのサーバアドレス１０４を代行サーバのサーバアドレス１０４欄に移動し、代行サーバにおける対象サービスの搭載／運用状況を「窓口」に変更する。その後、障害サーバに関するレコードを抹消する。

（ステップＳ２２０）代行不可能な場合（ステップ２１０：Ｎｏ）でも、予備サーバを追加起動して窓口サーバにできる可能性がある。アプリ管理制御手段１４は、アプリ管理テーブルに登録された情報に基づいてサーバ２の追加起動が可能か否かを判断する。そのために、アプリ管理制御手段１４は、アプリ管理テーブルにおいて、対象サービスの搭載／運用状況が「Ｏ」と登録されている予備サーバのレコードを一つ抽出する。抽出できれば追加起動可能であり、抽出できなければ追加起動不可能である。

（ステップＳ２２２）サーバ２の追加起動が可能な場合（ステップ２２０：Ｙｅｓ）、抽出されたレコードに対応するサーバ２（追加サーバと呼ぶ）を起動する。追加サーバ起動の手順を次に説明する。

アプリ管理制御手段１４は、追加サーバのサーバＩＤ１０２をオペレータ入出力手段２０に通知する。オペレータ入出力手段２０は、追加サーバのサーバＩＤ１０２を出力する。出力されたサーバＩＤ１０２に従って、オペレータが追加サーバを起動する。起動された追加サーバはサービス管理装置１にアクセスする。

（ステップＳ２２４）追加サーバにＩＰアドレスを設定する。ＩＰアドレス設定の手順を次に説明する。

アプリ管理制御手段１４は、追加サーバのサーバＩＤ１０２および障害サーバのＩＰアドレスを追加サーバ通知手段１８に通知する。追加サーバ通知手段１８は、通知されたサーバＩＤ１０２を持つ追加サーバに障害サーバのＩＰアドレスを通知する。追加サーバは通知されたＩＰアドレスを自身のＩＰアドレスとして設定する。

（ステップＳ２２６）追加サーバにおいて対象サービスを提供するためのアプリケーションプログラムを起動する。アプリケーションプログラム起動の手順を次に説明する。

アプリ管理制御手段１４は、追加サーバのＩＰアドレスおよび対象サービスを提供するためのアプリケーションプログラムを特定する情報であるアプリＩＤを追加サーバ通知手段１８に通知する。追加サーバ通知手段１８は、通知されたＩＰアドレスに宛てて、通知されたアプリＩＤを通知し、追加サーバは通知されたアプリＩＤで特定されるアプリケーションプログラムを起動する。

（ステップＳ２２８）追加サーバに補助サーバを通知する。補助サーバ通知の手順を次に説明する。

アプリ管理制御手段１４は、アプリ管理テーブルにおいて、対象サービスの搭載／運用状況が「補助」と登録されているすべてのレコードのサーバアドレス１０４欄からＩＰアドレスを抽出する。抽出されたＩＰアドレスが一つでもあれば、アプリ管理制御手段１４は、抽出されたＩＰアドレスおよび追加サーバのＩＰアドレスを追加サーバ通知手段１８に通知する。追加サーバ通知手段１８は、追加サーバのＩＰアドレスに宛てて、抽出されたＩＰアドレスを通知する。追加サーバは、以後、通知されたＩＰアドレスを持つサーバも含めて負荷分散を行う。

（ステップＳ２３０）アプリ管理制御手段１４は、アプリ管理テーブルを更新する。サーバ追加の場合は、アプリ管理テーブルにおいて、障害サーバのサーバアドレス１０４を追加サーバのサーバアドレス１０４欄に移動し、追加サーバにおける対象サービスの搭載／運用状況を「窓口」に変更する。その後、障害サーバに関するレコードを抹消する。

（ステップＳ２３２）サーバの追加起動が不可能な場合（ステップ２２０：Ｎｏ）、サービス管理装置１は警告を出力する。警告出力の手順を次に説明する。

アプリ管理制御手段１４は、対象サービスを特定する情報であるサービスＩＤをオペレータ入出力手段２０に通知する。オペレータ入出力手段２０は、通知されたサービスＩＤを出力し、負荷の増大をオペレータに警告する。

図７は、本発明の実施例における補助サーバ交替処理のフローチャートである。本実施例における補助サーバ交替処理の流れを図７のステップＳ２４２からステップＳ２６２の順を追って説明する。なお、図７の説明においては、図５の説明と同様、交替すべき運用サーバを障害サーバと呼び、障害サーバで運用されていた各サービスを対象サービスと呼ぶ。

（ステップＳ２４２）現在対象サービスが起動されていない運用サーバを補助サーバに変更できる可能性がある。これを代行と呼ぶ。アプリ管理制御手段１４は、アプリ管理テーブルに登録された情報に基づいてサーバの代行が可能か否かを判断する。そのために、アプリ管理制御手段１４は、アプリ管理テーブルにおいて、対象サービスの搭載／運用状況が「Ｏ」と登録されている運用サーバのレコードを一つ抽出する。抽出できれば代行可能であり、抽出できなければ代行不可能である。

（ステップＳ２４４）代行可能な場合（ステップ２４２：Ｙｅｓ）、抽出されたレコードに対応するサーバ２（代行サーバと呼ぶ）において対象サービスを提供するためのアプリケーションプログラムを起動する。アプリケーションプログラム起動の手順を次に説明する。

アプリ管理制御手段１４は、代行サーバのＩＰアドレスおよび対象サービスを提供するためのアプリケーションプログラムを特定する情報であるアプリＩＤを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、通知されたＩＰアドレスに宛てて、通知されたアプリＩＤを通知し、代行サーバは通知されたアプリＩＤで特定されるアプリケーションプログラムを起動する。

（ステップＳ２４６）窓口サーバに代行サーバを補助サーバとして通知する。補助サーバ通知の手順を次に説明する。

アプリ管理制御手段１４は、アプリ管理テーブルにおいて、対象サービスの搭載／運用状況が「窓口」と登録されているレコードのサーバアドレス１０４欄からＩＰアドレスを抽出する。アプリ管理制御手段１４は、抽出された窓口サーバのＩＰアドレスおよび代行サーバのＩＰアドレスを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、窓口サーバのＩＰアドレスに宛てて、代行サーバのＩＰアドレスを通知する。窓口サーバは、以後、通知されたＩＰアドレスを持つサーバも含めて負荷分散を行う。

（ステップＳ２６０）アプリ管理制御手段１４は、アプリ管理テーブルを更新する。サーバ代行の場合は、アプリ管理テーブル中の、代行サーバに関するレコードにおいて、対象サービスの搭載／運用状況を「補助」に変更する。その後、障害サーバに関するレコードを抹消する。

（ステップＳ２５０）代行不可能な場合（ステップ２４２：Ｎｏ）でも、予備サーバを追加起動して補助サーバにできる可能性がある。アプリ管理制御手段１４は、アプリ管理テーブルに登録された情報に基づいてサーバの追加起動が可能か否かを判断する。そのために、アプリ管理制御手段１４は、アプリ管理テーブルにおいて、対象サービスの搭載／運用状況が「Ｏ」と登録されている予備サーバのレコードを一つ抽出する。抽出できれば追加起動可能であり、抽出できなければ追加起動不可能である。

（ステップＳ２５２）追加起動可能な場合（ステップ２５０：Ｙｅｓ）、抽出されたレコードに対応するサーバ２（追加サーバと呼ぶ）を起動する。追加サーバ起動の手順を次に説明する。

アプリ管理制御手段１４は、追加サーバのサーバＩＤ１０２をオペレータ入出力手段２０に通知する。オペレータ入出力手段２０は、追加サーバのサーバＩＤ１０２を出力する。出力されたサーバＩＤ１０２に従って、オペレータが追加サーバを起動する。起動された追加サーバはサービス管理装置１にアクセスする。

（ステップＳ２５４）追加サーバにＩＰアドレスを設定する。ＩＰアドレス設定の手順を次に説明する。

アプリ管理制御手段１４は、追加サーバのサーバＩＤ１０２および使用可能で現在使用されていないＩＰアドレスを追加サーバ通知手段１８に通知する。追加サーバ通知手段１８は、通知されたサーバＩＤ１０２を持つ追加サーバにＩＰアドレスを通知する。追加サーバは通知されたＩＰアドレスを自身のＩＰアドレスとして設定する。

（ステップＳ２５６）追加サーバにおいて対象サービスを提供するためのアプリケーションプログラムを起動する。アプリケーションプログラム起動の手順を次に説明する。

アプリ管理制御手段１４は、追加サーバのＩＰアドレスおよび対象サービスを提供するためのアプリケーションプログラムを特定する情報であるアプリＩＤを追加サーバ通知手段１８に通知する。追加サーバ通知手段１８は、通知されたＩＰアドレスに宛てて、通知されたアプリＩＤを通知し、追加サーバは通知されたアプリＩＤで特定されるアプリケーションプログラムを起動する。

（ステップＳ２５８）窓口サーバに追加サーバを補助サーバとして通知する。補助サーバ通知の手順を次に説明する。

アプリ管理制御手段１４は、アプリ管理テーブルにおいて、対象サービスの搭載／運用状況が「窓口」と登録されているレコードのサーバアドレス１０４欄からＩＰアドレスを抽出する。アプリ管理制御手段１４は、抽出された窓口サーバのＩＰアドレスおよび追加サーバのＩＰアドレスを運用サーバ通知手段１６に通知する。運用サーバ通知手段１６は、窓口サーバのＩＰアドレスに宛てて、追加サーバのＩＰアドレスを通知する。窓口サーバは、以後、通知されたＩＰアドレスを持つサーバも含めて負荷分散を行う。

（ステップＳ２６０）アプリ管理制御手段１４は、アプリ管理テーブルを更新する。サーバ追加の場合は、アプリ管理テーブル中の、追加サーバに関するレコードにおいて、サーバアドレス１０４欄にＩＰアドレスを登録し、対象サービスの搭載／運用状況を「補助」に変更する。その後、障害サーバに関するレコードを抹消する。

（ステップＳ２６２）サーバの追加起動が不可能な場合（ステップ２５０：Ｎｏ）、サービス管理装置１は警告を出力する。警告出力の手順を次に説明する。

アプリ管理制御手段１４は、対象サービスを特定する情報であるサービスＩＤをオペレータ入出力手段２０に通知する。オペレータ入出力手段２０は、通知されたサービスＩＤを出力し、負荷の増大をオペレータに警告する。

上記説明においては、予備サーバにはＩＰアドレスが割り振られておらず、運用される時点で初めて割り振られるように説明したが、あらかじめ何らかのＩＰアドレスが割り振られており、必要に応じてＩＰアドレスを変更するようにしてもよい。

以上のような構成をとることにより、運用サーバあるいは予備サーバを障害サーバの代替あるいは警告サーバが窓口となるサービスの追加サーバとして運用することができる。

上述のように、本発明によれば、１台のサーバに複数のアプリケーションプログラムを搭載し、必要に応じて適切なアプリケーションプログラムを起動することにより、効率的に障害対応あるいは負荷分散を行うことのできるサービス管理方法を提供することが可能となる。

なお、上述した実施例にかかるサービス管理装置は、ハードウェアとして実施可能であるだけでなく、コンピュータのソフトウェアとしても実施可能である。例えば、図３に示した稼動状況監視手段１２、アプリ管理制御手段１４、運用サーバ通知手段１６、追加サーバ通知手段１８、オペレータ入出力手段２０、通信手段２４の機能をコンピュータに実行させるプログラムを作成し、当該プログラムをコンピュータのメモリに読み込ませて実行させれば、サービス管理装置を実現することができる。

本発明の実施例にかかるサービス管理装置を実現するプログラムは、図９に示すように、ＣＤ−ＲＯＭやＣＤ−ＲＷ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ等やフレキシブルディスク等の可搬型記録媒体３４だけでなく、通信回線３６の先に備えられた他の記憶装置３８や、コンピュータシステム３２のハードディスクやＲＡＭ等の記憶装置、記録媒体４０のいずれに記憶されるものであってもよく、プログラム実行時には、プログラムはローディングされ、主メモリ上で実行される。

本発明の概念を説明する図 本発明の実施例におけるアプリ管理テーブルの例を示す図 本発明の実施例にかかるサービス管理装置のシステム構成を示す図 本発明の実施例にかかるサービス管理装置のフローチャート 本発明の実施例におけるサーバ交替処理のフローチャート 本発明の実施例における窓口サーバ交替処理のフローチャート 本発明の実施例における補助サーバ交替処理のフローチャート 従来技術を説明する図 コンピュータ環境の例を示す図

符号の説明

１： サービス管理装置
２： サーバ
１２： 稼動状況監視手段
１４： アプリ管理制御手段
１６： 運用サーバ通知手段
１８： 追加サーバ通知手段
２０： オペレータ入出力手段
２２： アプリ管理テーブル記憶部
２４： 通信手段

Claims (6)

1. アプリケーションプログラムを搭載した複数のサーバと通信可能なサービス管理装置であって、
   前記複数のサーバに搭載されている前記アプリケーションプログラムの運用状況を含む情報を登録したアプリ管理テーブルを記憶する記憶部と、
   前記アプリケーションプログラムを起動している第１のサーバの稼動状況を監視する手段と、
   前記第１のサーバの稼動状況に基づいて前記アプリケーションプログラムを他のサーバ上で起動することを決定する手段と、
   前記アプリケーションプログラムを搭載し、かつ前記アプリケーションプログラムを起動していない第２のサーバを、前記アプリ管理テーブルに登録された情報に基づいて検出する手段と、
   前記第２のサーバに前記アプリケーションプログラムの起動を指示する手段と、
   を備えたことを特徴とするサービス管理装置。
2. 請求項１に記載したサービス管理装置であって、さらに、
   前記第１のサーバをネットワーク上で識別するためのアドレスを、前記第２のサーバのアドレスとして設定するように前記第２のサーバに指示する手段
   を備えたことを特徴とするサービス管理装置。
3. 複数のサーバに搭載されているアプリケーションプログラムの運用状況を含む情報を登録したアプリ管理テーブルを記憶する記憶部を備え、前記複数のサーバと通信可能なサービス管理装置が実行するサービス管理方法であって、
   前記アプリケーションプログラムを起動している第１のサーバの稼動状況を監視するステップと、
   前記第１のサーバの稼動状況に基づいて前記アプリケーションプログラムを他のサーバ上で起動することを決定するステップと、
   前記アプリケーションプログラムを搭載し、かつ前記アプリケーションプログラムを起動していない第２のサーバを、前記アプリ管理テーブルに登録された情報に基づいて検出するステップと、
   前記第２のサーバに前記アプリケーションプログラムの起動を指示するステップと、
   を備えたことを特徴とするサービス管理方法。
4. 請求項３に記載したサービス管理方法であって、さらに、
   前記第１のサーバをネットワーク上で識別するためのアドレスを、前記第２のサーバのアドレスとして設定するように前記第２のサーバに指示するステップ
   を備えたことを特徴とするサービス管理方法。
5. 複数のサーバに搭載されているアプリケーションプログラムの運用状況を含む情報を登録したアプリ管理テーブルを記憶する記憶部を備え、前記複数のサーバと通信可能なコンピュータにサービス管理方法を実行させるサービス管理プログラムであって、前記サービス管理方法は、
   前記アプリケーションプログラムを起動している第１のサーバの稼動状況を監視するステップと、
   前記第１のサーバの稼動状況に基づいて前記アプリケーションプログラムを他のサーバ上で起動することを決定するステップと、
   前記アプリケーションプログラムを搭載し、かつ前記アプリケーションプログラムを起動していない第２のサーバを、前記アプリ管理テーブルに登録された情報に基づいて検出するステップと、
   前記第２のサーバに前記アプリケーションプログラムの起動を指示するステップと、
   を備えたことを特徴とするサービス管理プログラム。
6. 請求項５に記載したサービス管理プログラムであって、前記サービス管理方法はさらに、
   前記第１のサーバをネットワーク上で識別するためのアドレスを、前記第２のサーバのアドレスとして設定するように前記第２のサーバに指示するステップ
   を備えたことを特徴とするサービス管理プログラム。