JP2001155003A - サービス復旧システムおよびその記録媒体 - Google Patents
サービス復旧システムおよびその記録媒体Info
- Publication number
- JP2001155003A JP2001155003A JP34141599A JP34141599A JP2001155003A JP 2001155003 A JP2001155003 A JP 2001155003A JP 34141599 A JP34141599 A JP 34141599A JP 34141599 A JP34141599 A JP 34141599A JP 2001155003 A JP2001155003 A JP 2001155003A
- Authority
- JP
- Japan
- Prior art keywords
- service
- computer
- machine
- failure
- program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Hardware Redundancy (AREA)
- Multi Processors (AREA)
Abstract
(57)【要約】
【課題】 複数のサービスアプリケーションの復旧に対
応でき、サービスアプリケーションが稼働するコンピュ
ータに依存せずにサービスを復旧させることができるお
よびその記録媒体を提供すること。 【解決手段】 監視マネージャ１２は、サービス稼働マ
シン１３−１〜１３−４のいずれかで障害が発生する
と、障害が発生していないマシンに対して負荷情報を要
求すると共に、サービスホルダ１１から、障害が発生し
たマシンが提供していたサービスのリソース条件を読み
出す。そして、このリソース条件と、障害が発生してい
ない各マシンの負荷情報とに基づいて、障害が発生した
マシンが提供していたサービスを代わりに実行するマシ
ンを決定する。
応でき、サービスアプリケーションが稼働するコンピュ
ータに依存せずにサービスを復旧させることができるお
よびその記録媒体を提供すること。 【解決手段】 監視マネージャ１２は、サービス稼働マ
シン１３−１〜１３−４のいずれかで障害が発生する
と、障害が発生していないマシンに対して負荷情報を要
求すると共に、サービスホルダ１１から、障害が発生し
たマシンが提供していたサービスのリソース条件を読み
出す。そして、このリソース条件と、障害が発生してい
ない各マシンの負荷情報とに基づいて、障害が発生した
マシンが提供していたサービスを代わりに実行するマシ
ンを決定する。
Description
【０００１】
【発明の属する技術分野】本発明は、各々所定のサービ
スを提供する複数のコンピュータのいずれかで障害が発
生した場合、そのコンピュータが提供していたサービス
を復旧するサービス復旧システムおよびその記録媒体に
関する。
スを提供する複数のコンピュータのいずれかで障害が発
生した場合、そのコンピュータが提供していたサービス
を復旧するサービス復旧システムおよびその記録媒体に
関する。
【０００２】
【従来の技術】従来より、ネットワーク上に接続された
クライアントに対してサービスを提供するコンピュータ
において、サービスアプリケーションの実行中に何らか
の障害が発生したり、マシン本体に障害が発生した場
合、提供しているサービスを速やかに復旧する方式とし
て、多重並列処理方式、ホットスタンバイ方式、コール
ドスタンバイ方式等がある。
クライアントに対してサービスを提供するコンピュータ
において、サービスアプリケーションの実行中に何らか
の障害が発生したり、マシン本体に障害が発生した場
合、提供しているサービスを速やかに復旧する方式とし
て、多重並列処理方式、ホットスタンバイ方式、コール
ドスタンバイ方式等がある。
【０００３】ここで、多重並列処理方式は、同じサービ
スアプリケーションを複数台のコンピュータで稼働させ
て、１つのサービスを複数台のコンピュータによって提
供する方式である。この方式によれば、複数台のコンピ
ュータによって１つのサービスを提供しているので、そ
の中の１台のコンピュータに障害が発生してダウンして
しまった場合でも、残りのコンピュータによってサービ
スを提供し続けることができる。
スアプリケーションを複数台のコンピュータで稼働させ
て、１つのサービスを複数台のコンピュータによって提
供する方式である。この方式によれば、複数台のコンピ
ュータによって１つのサービスを提供しているので、そ
の中の１台のコンピュータに障害が発生してダウンして
しまった場合でも、残りのコンピュータによってサービ
スを提供し続けることができる。
【０００４】また、ホットスタンバイ方式は、同じサー
ビスアプリケーションがインストールされた複数台のコ
ンピュータと、これらコンピュータで発生した障害を監
視するマネージャとからなる方式である。この方式で
は、正常時は上記コンピュータのうち１台のコンピュー
タがサービスアプリケーションを実行してサービスを提
供し、それ以外のコンピュータは、電源を立ち上げた状
態のまま待機している。ここで、以下、正常時に稼働す
るコンピュータを正常系マシンと呼び、正常時に待機し
ているコンピュータを待機系マシンと呼ぶ。
ビスアプリケーションがインストールされた複数台のコ
ンピュータと、これらコンピュータで発生した障害を監
視するマネージャとからなる方式である。この方式で
は、正常時は上記コンピュータのうち１台のコンピュー
タがサービスアプリケーションを実行してサービスを提
供し、それ以外のコンピュータは、電源を立ち上げた状
態のまま待機している。ここで、以下、正常時に稼働す
るコンピュータを正常系マシンと呼び、正常時に待機し
ているコンピュータを待機系マシンと呼ぶ。
【０００５】そして、マネージャが正常系マシンの障害
を検知すると、マネージャは、待機系マシンに対してサ
ービスアプリケーションの実行を指示し、また、指示さ
れた待機系マシンがインストールされているサービスア
プリケーションを実行することで、クライアントに提供
するサービスが復旧する。
を検知すると、マネージャは、待機系マシンに対してサ
ービスアプリケーションの実行を指示し、また、指示さ
れた待機系マシンがインストールされているサービスア
プリケーションを実行することで、クライアントに提供
するサービスが復旧する。
【０００６】また、コールドスタンバイ方式は、同じサ
ービスアプリケーションがインストールされた複数台の
コンピュータと、これらコンピュータで発生する障害を
監視するマネージャとからなり、正常時はそれらコンピ
ュータのうち１台のコンピュータによりサービスを提供
する点は、ホットスタンバイ方式と同様であるが、待機
系マシンは、正常時には電源がＯＦＦになった状態で待
機している点が異なっている。
ービスアプリケーションがインストールされた複数台の
コンピュータと、これらコンピュータで発生する障害を
監視するマネージャとからなり、正常時はそれらコンピ
ュータのうち１台のコンピュータによりサービスを提供
する点は、ホットスタンバイ方式と同様であるが、待機
系マシンは、正常時には電源がＯＦＦになった状態で待
機している点が異なっている。
【０００７】この方式において、正常系マシンに障害が
発生した場合、マネージャは、待機系マシンを起動した
後、その待機系マシンに対してサービスアプリケーショ
ンの実行を指示する。そして、指示を受けた待機系マシ
ンがインストールされているサービスアプリケーション
を実行することで、クライアントに提供するサービスが
復旧する。
発生した場合、マネージャは、待機系マシンを起動した
後、その待機系マシンに対してサービスアプリケーショ
ンの実行を指示する。そして、指示を受けた待機系マシ
ンがインストールされているサービスアプリケーション
を実行することで、クライアントに提供するサービスが
復旧する。
【０００８】
【発明が解決しようとする課題】ところで、上述したサ
ービス復旧方式においては、各種マシンが一旦起動して
しまうと、途中で復旧の対象となるサービスアプリケー
ションの種類を変更することができなかった。このた
め、復旧の対象とするサービスアプリケーション毎に待
機系マシンを用意しなければならないので、復旧対象と
するサービスの種類に応じて設備が大規模になると共
に、コストも増大してしまうという問題があった。
ービス復旧方式においては、各種マシンが一旦起動して
しまうと、途中で復旧の対象となるサービスアプリケー
ションの種類を変更することができなかった。このた
め、復旧の対象とするサービスアプリケーション毎に待
機系マシンを用意しなければならないので、復旧対象と
するサービスの種類に応じて設備が大規模になると共
に、コストも増大してしまうという問題があった。
【０００９】さらに、正常系マシンと待機系マシンは、
その機能を変更するのが容易ではなく、また、同一機種
のものを使用しなければならいという制限があるため、
サービス提供するための全体的なシステム構成が制限さ
れてしまうという問題があった。
その機能を変更するのが容易ではなく、また、同一機種
のものを使用しなければならいという制限があるため、
サービス提供するための全体的なシステム構成が制限さ
れてしまうという問題があった。
【００１０】本発明は、上述した事情に鑑みてなされた
ものであり、複数のサービスアプリケーションの復旧に
対応でき、サービスアプリケーションが稼働するコンピ
ュータに依存せずにサービスを復旧させることができる
サービス復旧システムおよびその記録媒体を提供するこ
とを目的とする。
ものであり、複数のサービスアプリケーションの復旧に
対応でき、サービスアプリケーションが稼働するコンピ
ュータに依存せずにサービスを復旧させることができる
サービス復旧システムおよびその記録媒体を提供するこ
とを目的とする。
【００１１】
【課題を解決するための手段】請求項１に記載の発明
は、各々所定のサービスを提供する複数のコンピュータ
と、該複数のコンピュータで発生する障害を監視する障
害監視装置とからなり、該複数のコンピュータのいずれ
かで障害が発生した場合、そのコンピュータが提供して
いたサービスを復旧するサービス復旧システムにおい
て、前記障害監視装置は、前記各サービスを実行するた
めの複数のプログラムと、該複数のプログラムを実行す
るのに要するリソース条件を記憶したサービス情報記憶
手段と、前記複数のコンピュータのうち、いずれかのコ
ンピュータで障害が発生した場合、障害が発生していな
いコンピュータに対して現在の負荷状態を要求して、当
該各コンピュータの負荷状態を収集する負荷状態収集手
段と、前記サービス情報記憶手段から前記障害が発生し
たコンピュータが実行していたサービスのリソース条件
を読み出し、該リソース条件と、前記収集した負荷状態
とに基づいて、前記障害が発生したコンピュータが実行
していたサービスを実行するコンピュータを決定するコ
ンピュータ決定手段と、前記障害が発生したコンピュー
タが実行していたサービスを実行するためのプログラム
を、前記サービス情報記憶手段から読み出し、前記コン
ピュータ決定手段により決定されたコンピュータに送信
するプログラム送信手段とを有することを特徴としてい
る。
は、各々所定のサービスを提供する複数のコンピュータ
と、該複数のコンピュータで発生する障害を監視する障
害監視装置とからなり、該複数のコンピュータのいずれ
かで障害が発生した場合、そのコンピュータが提供して
いたサービスを復旧するサービス復旧システムにおい
て、前記障害監視装置は、前記各サービスを実行するた
めの複数のプログラムと、該複数のプログラムを実行す
るのに要するリソース条件を記憶したサービス情報記憶
手段と、前記複数のコンピュータのうち、いずれかのコ
ンピュータで障害が発生した場合、障害が発生していな
いコンピュータに対して現在の負荷状態を要求して、当
該各コンピュータの負荷状態を収集する負荷状態収集手
段と、前記サービス情報記憶手段から前記障害が発生し
たコンピュータが実行していたサービスのリソース条件
を読み出し、該リソース条件と、前記収集した負荷状態
とに基づいて、前記障害が発生したコンピュータが実行
していたサービスを実行するコンピュータを決定するコ
ンピュータ決定手段と、前記障害が発生したコンピュー
タが実行していたサービスを実行するためのプログラム
を、前記サービス情報記憶手段から読み出し、前記コン
ピュータ決定手段により決定されたコンピュータに送信
するプログラム送信手段とを有することを特徴としてい
る。
【００１２】請求項２に記載の発明は、請求項１に記載
のサービス復旧システムにおいて、前記コンピュータ決
定手段は、前記負荷状態収集手段によって収集された負
荷状態から、障害が発生していない各コンピュータにお
けるリソースの余裕度を求め、該求めた各コンピュータ
の余裕度と前記読み出したリソース条件とを比較し、該
リソース条件を満足する余裕度のコンピュータを、前記
障害が発生したコンピュータが実行していたサービスを
実行するコンピュータとして決定することを特徴として
いる。
のサービス復旧システムにおいて、前記コンピュータ決
定手段は、前記負荷状態収集手段によって収集された負
荷状態から、障害が発生していない各コンピュータにお
けるリソースの余裕度を求め、該求めた各コンピュータ
の余裕度と前記読み出したリソース条件とを比較し、該
リソース条件を満足する余裕度のコンピュータを、前記
障害が発生したコンピュータが実行していたサービスを
実行するコンピュータとして決定することを特徴として
いる。
【００１３】請求項３に記載の発明は、請求項２に記載
のサービス復旧システムにおいて、前記コンピュータ決
定手段は、前記負荷状態収集手段によって収集された負
荷状態から、障害が発生していない各コンピュータにお
けるリソースの余裕度を求め、該求めた各コンピュータ
の余裕度と前記読み出したリソース条件とを比較し、該
リソース条件を満足する余裕度のコンピュータがない場
合、前記リソース条件のうち、最も優先されるべき項目
について最も余裕度が大きいコンピュータを、前記障害
が発生したコンピュータが実行していたサービスを実行
するコンピュータとして決定することを特徴としてい
る。
のサービス復旧システムにおいて、前記コンピュータ決
定手段は、前記負荷状態収集手段によって収集された負
荷状態から、障害が発生していない各コンピュータにお
けるリソースの余裕度を求め、該求めた各コンピュータ
の余裕度と前記読み出したリソース条件とを比較し、該
リソース条件を満足する余裕度のコンピュータがない場
合、前記リソース条件のうち、最も優先されるべき項目
について最も余裕度が大きいコンピュータを、前記障害
が発生したコンピュータが実行していたサービスを実行
するコンピュータとして決定することを特徴としてい
る。
【００１４】請求項４に記載の発明は、請求項１から３
に記載のサービス復旧システムにおいて、前記コンピュ
ータは、各々、前記障害監視装置からの要求に応じて現
在の負荷状態を前記障害監視装置へ通知する負荷状態通
知手段と、前記障害監視装置からプログラムが送信され
てきた場合、該プログラムを実行してサービスを提供す
るプログラム実行手段とを有することを特徴としてい
る。
に記載のサービス復旧システムにおいて、前記コンピュ
ータは、各々、前記障害監視装置からの要求に応じて現
在の負荷状態を前記障害監視装置へ通知する負荷状態通
知手段と、前記障害監視装置からプログラムが送信され
てきた場合、該プログラムを実行してサービスを提供す
るプログラム実行手段とを有することを特徴としてい
る。
【００１５】請求項５に記載の発明は、各々所定のサー
ビスを提供する複数のコンピュータのいずれかで障害が
発生した場合、そのコンピュータが提供していたサービ
スを復旧するサービス復旧プログラムを記録したコンピ
ュータ読み取り可能な記録媒体であって、前記複数のコ
ンピュータのうち、いずれかのコンピュータで障害が発
生した場合、障害が発生していないコンピュータに対し
て現在の負荷状態を要求するステップと、前記各サービ
スを実行するための複数のプログラムと、該複数のプロ
グラムを実行するのに要するリソース条件を記憶した記
憶手段から、前記障害が発生したコンピュータが実行し
ていたサービスのリソース条件を読み出すステップと、
前記要求に応じて各コンピュータから送信されてきた負
荷状態と前記記憶手段から読み出したリソース条件とに
基づいて、前記障害が発生したコンピュータが実行して
いたサービスを実行するコンピュータを決定するステッ
プと、前記サービス情報記憶手段から、前記障害が発生
したコンピュータが実行していたサービスを実行するた
めのプログラムを読み出すステップと、前記読み出した
プログラムを、前記決定したコンピュータに対して送信
するステップとをコンピュータに実行させるサービス復
旧プログラムを記録したコンピュータ読み取り可能な記
録媒体である。
ビスを提供する複数のコンピュータのいずれかで障害が
発生した場合、そのコンピュータが提供していたサービ
スを復旧するサービス復旧プログラムを記録したコンピ
ュータ読み取り可能な記録媒体であって、前記複数のコ
ンピュータのうち、いずれかのコンピュータで障害が発
生した場合、障害が発生していないコンピュータに対し
て現在の負荷状態を要求するステップと、前記各サービ
スを実行するための複数のプログラムと、該複数のプロ
グラムを実行するのに要するリソース条件を記憶した記
憶手段から、前記障害が発生したコンピュータが実行し
ていたサービスのリソース条件を読み出すステップと、
前記要求に応じて各コンピュータから送信されてきた負
荷状態と前記記憶手段から読み出したリソース条件とに
基づいて、前記障害が発生したコンピュータが実行して
いたサービスを実行するコンピュータを決定するステッ
プと、前記サービス情報記憶手段から、前記障害が発生
したコンピュータが実行していたサービスを実行するた
めのプログラムを読み出すステップと、前記読み出した
プログラムを、前記決定したコンピュータに対して送信
するステップとをコンピュータに実行させるサービス復
旧プログラムを記録したコンピュータ読み取り可能な記
録媒体である。
【００１６】
【発明の実施の形態】以下、図面を参照して、本発明に
係るサービス復旧システムの一実施形態について説明す
る。図１は、本実施形態におけるサービス復旧システム
の概略構成を示すブロック図である。この図において、
１はサービス復旧システムであり、ＬＡＮ（Local Area
Network）２を介してクライアント３に対して各種サー
ビスを提供すると共に、提供しているサービスに障害が
生じた場合、そのサービスを復旧させる。このサービス
復旧システムは、以下の構成からなっている。
係るサービス復旧システムの一実施形態について説明す
る。図１は、本実施形態におけるサービス復旧システム
の概略構成を示すブロック図である。この図において、
１はサービス復旧システムであり、ＬＡＮ（Local Area
Network）２を介してクライアント３に対して各種サー
ビスを提供すると共に、提供しているサービスに障害が
生じた場合、そのサービスを復旧させる。このサービス
復旧システムは、以下の構成からなっている。
【００１７】まず、１０はサービスロケータであり、図
２に示すように、クライアント３に対して各種サービス
を提供するサービス稼働マシン１３−１，１３−２，１
３−３，１３−４（後述する）の、ＬＡＮ２内における
ＩＰアドレスと、各サービス稼働マシンが提供している
サービスの種類とを対応づけて記憶している。そして、
クライアント３から所望するサービスがどのサービス稼
働マシンで提供されているか問い合わせがあった場合、
その所望するサービスを提供してるサービス稼働マシン
のＩＰアドレスをクライアント３へ送信する。
２に示すように、クライアント３に対して各種サービス
を提供するサービス稼働マシン１３−１，１３−２，１
３−３，１３−４（後述する）の、ＬＡＮ２内における
ＩＰアドレスと、各サービス稼働マシンが提供している
サービスの種類とを対応づけて記憶している。そして、
クライアント３から所望するサービスがどのサービス稼
働マシンで提供されているか問い合わせがあった場合、
その所望するサービスを提供してるサービス稼働マシン
のＩＰアドレスをクライアント３へ送信する。
【００１８】また、後述する監視マネージャ１２から、
あるサービス稼働マシンのＩＰアドレスが送信されてき
た場合、そのＩＰアドレスのマシンが提供しているサー
ビスの種類を監視マネージャ１２に返信する。
あるサービス稼働マシンのＩＰアドレスが送信されてき
た場合、そのＩＰアドレスのマシンが提供しているサー
ビスの種類を監視マネージャ１２に返信する。
【００１９】ここで、上述したサービス稼働マシン１３
−１，１３−２，１３−３，１３−４の各ＩＰアドレス
は、それぞれ、192.168.0.aaa，192.168.0.bbb，192.16
8.0.ccc，192.168.0.dddとする。ここで、各ＩＰアドレ
ス内のaaa，bbb，ccc，ddd，の値は、それぞれ固有の整
数値とする。
−１，１３−２，１３−３，１３−４の各ＩＰアドレス
は、それぞれ、192.168.0.aaa，192.168.0.bbb，192.16
8.0.ccc，192.168.0.dddとする。ここで、各ＩＰアドレ
ス内のaaa，bbb，ccc，ddd，の値は、それぞれ固有の整
数値とする。
【００２０】１１はサービスホルダ（サービス情報記憶
手段）であり、本サービス復旧システムで提供している
各サービスを実行するためのプログラム（ここではソー
スコードとする）を記憶している。また、図３に示すよ
うに、サービス復旧システムで提供している各サービス
の名称と、各サービスを実行するためのプログラム名
（ここではソースコードのファイル名とする）と、各プ
ログラムを実行するために、サービス稼働マシンに要求
されるリソース条件とを対応づけて記憶している。
手段）であり、本サービス復旧システムで提供している
各サービスを実行するためのプログラム（ここではソー
スコードとする）を記憶している。また、図３に示すよ
うに、サービス復旧システムで提供している各サービス
の名称と、各サービスを実行するためのプログラム名
（ここではソースコードのファイル名とする）と、各プ
ログラムを実行するために、サービス稼働マシンに要求
されるリソース条件とを対応づけて記憶している。
【００２１】ここで、サービスＡのソースコードのファ
イル名をＳＡ．ｃ、サービスＢのソースコードのファイ
ル名をＳＢ．ｃ、サービスＣのソースコードのファイル
名をＳＣ．ｃ、サービスＤのソースコードのファイル名
をＳＤ．ｃとする。また、各サービスを実行する上での
リソース条件として、例えば、ＣＰＵの能力（ＭＩＰＳ
値）、メモリ容量、ハードディスクドライブ（ＨＤＤ）
の容量が規定されているものとする。また、図３に示す
リソース条件において、リソース条件の各項目毎に付記
されている（１）〜（３）の数値は、各サービスを提供
するためのプログラムを実行する上で、重要視される項
目の順序を示している。
イル名をＳＡ．ｃ、サービスＢのソースコードのファイ
ル名をＳＢ．ｃ、サービスＣのソースコードのファイル
名をＳＣ．ｃ、サービスＤのソースコードのファイル名
をＳＤ．ｃとする。また、各サービスを実行する上での
リソース条件として、例えば、ＣＰＵの能力（ＭＩＰＳ
値）、メモリ容量、ハードディスクドライブ（ＨＤＤ）
の容量が規定されているものとする。また、図３に示す
リソース条件において、リソース条件の各項目毎に付記
されている（１）〜（３）の数値は、各サービスを提供
するためのプログラムを実行する上で、重要視される項
目の順序を示している。
【００２２】１２は監視マネージャであり、後述するサ
ービス稼働マシン１３−１，１３−２，１３−３，１３
−４で発生する障害を監視すると共に、あるサービス稼
働マシンにおいて障害が発生した場合、そのマシンが提
供していたサービスを、他のマシンに実行させる。ここ
で、監視マネージャ１２の構成を図４に示す。この図に
示すように、監視マネージャ１２は、送受信部１２０
と、監視部１２１（負荷情報収集手段）と、マシン決定
部（コンピュータ決定手段）１２２と、プログラム送信
部（プログラム送信手段）１２３とからなっている。
ービス稼働マシン１３−１，１３−２，１３−３，１３
−４で発生する障害を監視すると共に、あるサービス稼
働マシンにおいて障害が発生した場合、そのマシンが提
供していたサービスを、他のマシンに実行させる。ここ
で、監視マネージャ１２の構成を図４に示す。この図に
示すように、監視マネージャ１２は、送受信部１２０
と、監視部１２１（負荷情報収集手段）と、マシン決定
部（コンピュータ決定手段）１２２と、プログラム送信
部（プログラム送信手段）１２３とからなっている。
【００２３】送受信部１２０は、ＬＡＮ２に接続され、
各サービス稼働マシン，サービスロケータ１０，サービ
スホルダ１１，クライアント３と通信を行う。監視部１
２１は、サービス稼働マシン１３−１，１３−２，１３
−３，１３−４のいずれかから、障害が発生したことを
通知する障害情報が送信されてきた場合、その障害情報
を送信したマシン以外のサービス稼働マシンに対し、そ
れぞれの負荷状態を問い合わせる。
各サービス稼働マシン，サービスロケータ１０，サービ
スホルダ１１，クライアント３と通信を行う。監視部１
２１は、サービス稼働マシン１３−１，１３−２，１３
−３，１３−４のいずれかから、障害が発生したことを
通知する障害情報が送信されてきた場合、その障害情報
を送信したマシン以外のサービス稼働マシンに対し、そ
れぞれの負荷状態を問い合わせる。
【００２４】ここで、各マシンに問い合わせる負荷状態
は、例えば、そのマシンが搭載しているＣＰＵのＭＩＰ
Ｓ値、メモリ容量、ＣＰＵ使用率、メモリ使用率、ハー
ドディスクの残量とする。そして、各マシンから負荷状
態の情報（負荷情報）が送り返されてくると、それら負
荷情報と、障害が発生したマシンを識別する情報（例え
ばＩＰアドレス）をマシン決定部１２２へ渡す。
は、例えば、そのマシンが搭載しているＣＰＵのＭＩＰ
Ｓ値、メモリ容量、ＣＰＵ使用率、メモリ使用率、ハー
ドディスクの残量とする。そして、各マシンから負荷状
態の情報（負荷情報）が送り返されてくると、それら負
荷情報と、障害が発生したマシンを識別する情報（例え
ばＩＰアドレス）をマシン決定部１２２へ渡す。
【００２５】マシン決定部１２２は、障害が発生したマ
シンが実行していたサービスのリソース条件を、サービ
スホルダ１１から読み出し、このリソース条件と、監視
部１２１が収集した各マシンの負荷情報とに基づいて、
障害が発生したマシンにより実行されていたサービスを
代わりに実行するマシン（以下、サービス代行マシンと
いう）を決定する。プログラム送信部１２３は、障害が
発生したサービスを実行するためのソースコードを、サ
ービスホルダ１１から読み出して、マシン決定部１２２
が決定した代行マシンに送信する。
シンが実行していたサービスのリソース条件を、サービ
スホルダ１１から読み出し、このリソース条件と、監視
部１２１が収集した各マシンの負荷情報とに基づいて、
障害が発生したマシンにより実行されていたサービスを
代わりに実行するマシン（以下、サービス代行マシンと
いう）を決定する。プログラム送信部１２３は、障害が
発生したサービスを実行するためのソースコードを、サ
ービスホルダ１１から読み出して、マシン決定部１２２
が決定した代行マシンに送信する。
【００２６】図１に戻り、サービス稼働マシン１３−
１，１３−２，１３−３，１３−４は、各々所定のプロ
グラム（サービスアプリケーション）を実行し、クライ
アント３からの要求に応じて種々のサービスを提供す
る。図１においては、サービス稼働マシン１３−１，１
３−２，１３−３，１３−４は、それぞれ、サービス
Ａ，サービスＢ，サービスＣ，サービスＤという名称の
サービスを提供していることを表している。
１，１３−２，１３−３，１３−４は、各々所定のプロ
グラム（サービスアプリケーション）を実行し、クライ
アント３からの要求に応じて種々のサービスを提供す
る。図１においては、サービス稼働マシン１３−１，１
３−２，１３−３，１３−４は、それぞれ、サービス
Ａ，サービスＢ，サービスＣ，サービスＤという名称の
サービスを提供していることを表している。
【００２７】ここで、図５を参照してサービス稼働マシ
ン１３−１，１３−２，１３−３，１３−４の構成につ
いて説明する。まず、１３０は送受信部であり、ＬＡＮ
２に接続され、サービスロケータ１０，サービスホルダ
１１，監視マネージャ１２，クライアント３と通信を行
う。１３１はエージェント部であり、自機のＯＳ（Oper
ating System）やサービスアプリケーションに障害が発
生した場合、障害情報を監視マネージャ１２に送信す
る。
ン１３−１，１３−２，１３−３，１３−４の構成につ
いて説明する。まず、１３０は送受信部であり、ＬＡＮ
２に接続され、サービスロケータ１０，サービスホルダ
１１，監視マネージャ１２，クライアント３と通信を行
う。１３１はエージェント部であり、自機のＯＳ（Oper
ating System）やサービスアプリケーションに障害が発
生した場合、障害情報を監視マネージャ１２に送信す
る。
【００２８】また、監視マネージャ１２から自機の負荷
状態に関する問い合わせがあった場合は、自機の負荷状
態（ここでは、ＣＰＵ使用率、メモリ使用率、および、
ハードディスクの残量とする）をチェックし、自機のＣ
ＰＵ能力（ＭＩＰＳ値）および搭載しているメモリ容量
と共に、負荷情報として監視マネージャ１２へ送信す
る。
状態に関する問い合わせがあった場合は、自機の負荷状
態（ここでは、ＣＰＵ使用率、メモリ使用率、および、
ハードディスクの残量とする）をチェックし、自機のＣ
ＰＵ能力（ＭＩＰＳ値）および搭載しているメモリ容量
と共に、負荷情報として監視マネージャ１２へ送信す
る。
【００２９】１３２はコンパイラ部であり、監視マネー
ジャ１２からソースコードが送信されてきた場合、その
ソースコードをコンパイルして実行ファイルを生成す
る。なお、コンパイル時は、ソースコード内において、
自機で稼働しているＯＳに依存したコードをコンパイル
の対象とする。１３３は処理部であり、所定のサービス
アプリケーションを実行してクライアント３に対してサ
ービスを提供する。また、コンパイラ部１３２において
実行ファイルが生成された場合は、上記サービスアプリ
ケーションに加え、生成された実行ファイルをも実行し
てさらなるサービスを提供する。
ジャ１２からソースコードが送信されてきた場合、その
ソースコードをコンパイルして実行ファイルを生成す
る。なお、コンパイル時は、ソースコード内において、
自機で稼働しているＯＳに依存したコードをコンパイル
の対象とする。１３３は処理部であり、所定のサービス
アプリケーションを実行してクライアント３に対してサ
ービスを提供する。また、コンパイラ部１３２において
実行ファイルが生成された場合は、上記サービスアプリ
ケーションに加え、生成された実行ファイルをも実行し
てさらなるサービスを提供する。
【００３０】次に、図６〜図８を参照して、上述したサ
ービス復旧システムの動作について説明する。ここで、
図６は、監視マネージャ１２の動作を示すフローチャー
トであり、図７は、監視マネージャ１２内のマシン決定
部１２２が、サービス代行マシンを決定する際の動作を
示すフローチャートである。また、図８は、各サービス
稼働マシンにおける動作を示すフローチャートである。
ービス復旧システムの動作について説明する。ここで、
図６は、監視マネージャ１２の動作を示すフローチャー
トであり、図７は、監視マネージャ１２内のマシン決定
部１２２が、サービス代行マシンを決定する際の動作を
示すフローチャートである。また、図８は、各サービス
稼働マシンにおける動作を示すフローチャートである。
【００３１】まず、図６および図７を参照して監視マネ
ージャ１２の動作について説明する。まず図６のステッ
プＳａ１において、監視部１２１は、サービス稼働マシ
ン１３−１〜１３−ｎのいずれかから障害情報を受信し
たか否かを判断する。ここで、いずれのマシンからも障
害情報を受信していなければ、判断結果がＮＯとなって
ステップＳａ１に戻り、障害情報を受信するまで待機す
る。そして障害情報を受信すると、判断結果がＹＥＳと
なり、ステップＳａ２へ進み、障害情報を送信してきた
サービス稼働マシン（すなわち、障害が発生したマシ
ン）以外のマシンに対して負荷情報の送信を要求する。
ージャ１２の動作について説明する。まず図６のステッ
プＳａ１において、監視部１２１は、サービス稼働マシ
ン１３−１〜１３−ｎのいずれかから障害情報を受信し
たか否かを判断する。ここで、いずれのマシンからも障
害情報を受信していなければ、判断結果がＮＯとなって
ステップＳａ１に戻り、障害情報を受信するまで待機す
る。そして障害情報を受信すると、判断結果がＹＥＳと
なり、ステップＳａ２へ進み、障害情報を送信してきた
サービス稼働マシン（すなわち、障害が発生したマシ
ン）以外のマシンに対して負荷情報の送信を要求する。
【００３２】そして、負荷情報の送信要求に応じて、各
マシンから送信された負荷情報を受信（収集）すると、
ステップＳａ３に進み、監視部１２１は、障害情報の送
信元のＩＰアドレスをサービスロケータ１０に送信し
て、障害が発生したマシンが提供していたサービスの種
類を問い合わせる。これにより、認識されたサービスに
対応するリソース条件をサービスホルダ１１から読み出
し、収集した各マシンの負荷情報と共にマシン決定部１
２２に渡す。
マシンから送信された負荷情報を受信（収集）すると、
ステップＳａ３に進み、監視部１２１は、障害情報の送
信元のＩＰアドレスをサービスロケータ１０に送信し
て、障害が発生したマシンが提供していたサービスの種
類を問い合わせる。これにより、認識されたサービスに
対応するリソース条件をサービスホルダ１１から読み出
し、収集した各マシンの負荷情報と共にマシン決定部１
２２に渡す。
【００３３】次にステップＳａ４へ進み、マシン決定部
１２２は、監視部１２１が収集した負荷情報と、サービ
スホルダ１１から読み出したリソース条件とに基づい
て、そのサービスのサービス代行マシンを決定する。こ
こで、マシン決定部１２２によるサービス代行マシンの
決定手順について、図７のフローチャートを参照して説
明する。また、以下の説明では、サービスＡを実行して
いたサービス稼働マシン１３−１に障害が発生し、監視
部１２１が収集したサービス稼働マシン１３−２，１３
−３，１３−４の負荷情報が、それぞれ以下の［表１］
に示す内容であった場合を例に説明する。
１２２は、監視部１２１が収集した負荷情報と、サービ
スホルダ１１から読み出したリソース条件とに基づい
て、そのサービスのサービス代行マシンを決定する。こ
こで、マシン決定部１２２によるサービス代行マシンの
決定手順について、図７のフローチャートを参照して説
明する。また、以下の説明では、サービスＡを実行して
いたサービス稼働マシン１３−１に障害が発生し、監視
部１２１が収集したサービス稼働マシン１３−２，１３
−３，１３−４の負荷情報が、それぞれ以下の［表１］
に示す内容であった場合を例に説明する。
【００３４】
【表１】
【００３５】まず、マシン決定部１２２は、監視部１２
１が収集した負荷情報に基づいて、障害が発生していな
いサービス稼働マシンの各リソースの余裕度を求める。
すなわち、まず、ＣＰＵの余裕度は、サービス稼働マシ
ン１３−２のＣＰＵの余裕度は、２００（ＭＩＰＳ）×
７０％＝１４０ＭＩＰＳ、サービス稼働マシン１３−３
のＣＰＵの余裕度は、１５０（ＭＩＰＳ）×８０％＝１
２０ＭＩＰＳ、サービス稼働マシン１３−３のＣＰＵの
余裕度は、１００（ＭＩＰＳ）×６０％＝６０ＭＩＰＳ
となる。
１が収集した負荷情報に基づいて、障害が発生していな
いサービス稼働マシンの各リソースの余裕度を求める。
すなわち、まず、ＣＰＵの余裕度は、サービス稼働マシ
ン１３−２のＣＰＵの余裕度は、２００（ＭＩＰＳ）×
７０％＝１４０ＭＩＰＳ、サービス稼働マシン１３−３
のＣＰＵの余裕度は、１５０（ＭＩＰＳ）×８０％＝１
２０ＭＩＰＳ、サービス稼働マシン１３−３のＣＰＵの
余裕度は、１００（ＭＩＰＳ）×６０％＝６０ＭＩＰＳ
となる。
【００３６】次に、マシン決定部１２２は、メモリの余
裕度（すなわちメモリ残量）を求める。すなわち、サー
ビス稼働マシン１３−２のメモリ残量は、６４（ＭＢ）
×５０％＝３２ＭＢ、サービス稼働マシン１３−３のメ
モリ残量は、３２（ＭＢ）×３０％＝９．６ＭＢ、サー
ビス稼働マシン１３−４のメモリ残量は、１２８（Ｍ
Ｂ）×４０％＝５１．２ＭＢとなる。また、ハードディ
スクの残量は、［表１］に示すように、サービス稼働マ
シン１３−２が２００ＭＢ、サービス稼働マシン１３−
３が３００ＭＢ、サービス稼働マシン１３−４が５００
ＭＢである。
裕度（すなわちメモリ残量）を求める。すなわち、サー
ビス稼働マシン１３−２のメモリ残量は、６４（ＭＢ）
×５０％＝３２ＭＢ、サービス稼働マシン１３−３のメ
モリ残量は、３２（ＭＢ）×３０％＝９．６ＭＢ、サー
ビス稼働マシン１３−４のメモリ残量は、１２８（Ｍ
Ｂ）×４０％＝５１．２ＭＢとなる。また、ハードディ
スクの残量は、［表１］に示すように、サービス稼働マ
シン１３−２が２００ＭＢ、サービス稼働マシン１３−
３が３００ＭＢ、サービス稼働マシン１３−４が５００
ＭＢである。
【００３７】次に、ステップＳｂ２へ進み、マシン決定
部１２２は、サービスＡのリソース条件を満たすサービ
ス稼働マシンがあるか否かを判断する。ここで、サービ
スＡのリソース条件は、図３に示す通り、ＣＰＵが１０
０ＭＩＰＳ以上、メモリが３２ＭＢ以上、ＨＤＤの容量
が２０ＭＢ以上なので、この条件を満足するのは、サー
ビス稼働マシン１３−２である。よって、ステップＳｂ
２の判断結果はＹＥＳとなり、ステップＳｂ３へ進む。
部１２２は、サービスＡのリソース条件を満たすサービ
ス稼働マシンがあるか否かを判断する。ここで、サービ
スＡのリソース条件は、図３に示す通り、ＣＰＵが１０
０ＭＩＰＳ以上、メモリが３２ＭＢ以上、ＨＤＤの容量
が２０ＭＢ以上なので、この条件を満足するのは、サー
ビス稼働マシン１３−２である。よって、ステップＳｂ
２の判断結果はＹＥＳとなり、ステップＳｂ３へ進む。
【００３８】ステップＳｂ３では、リソース条件を満た
すマシンが複数台あるか否かを判断する。ここでは、サ
ービス稼働マシン１３−２のみが、サービスＡのリソー
ス条件を満たしているので、判断結果はＮＯとなり、ス
テップＳｂ４へ進む。ステップＳｂ４へ進むと、マシン
決定部１２２は、唯一リソース条件を満たしているサー
ビス稼働マシン（ここではサービス稼働マシン１３−
２）をサービス代行マシンとして、プログラム送信部１
２３へ通知する。
すマシンが複数台あるか否かを判断する。ここでは、サ
ービス稼働マシン１３−２のみが、サービスＡのリソー
ス条件を満たしているので、判断結果はＮＯとなり、ス
テップＳｂ４へ進む。ステップＳｂ４へ進むと、マシン
決定部１２２は、唯一リソース条件を満たしているサー
ビス稼働マシン（ここではサービス稼働マシン１３−
２）をサービス代行マシンとして、プログラム送信部１
２３へ通知する。
【００３９】なお、リソース条件を満たすサービス稼働
マシンがない場合、ステップＳｂ２の判断結果がＮＯと
なり、ステップＳｂ５へ進む。そして、ステップＳｂ５
において、ステップＳｂ１で求めた各マシンのリソース
の余裕度を参照し、障害が発生したサービスのリソース
条件のうち最も重要視される項目について、最も余裕度
が高いサービス稼働マシンをサービス代行マシンとし
て、プログラム送信部１２３へ通知する。例えば、サー
ビスＡのリソース条件において、最も重要視されるのは
ＣＰＵの能力であるから、障害が発生していないサービ
ス稼働マシンの中で、最もＣＰＵの余裕度が高いマシン
がサービス代行マシンとして決定される。
マシンがない場合、ステップＳｂ２の判断結果がＮＯと
なり、ステップＳｂ５へ進む。そして、ステップＳｂ５
において、ステップＳｂ１で求めた各マシンのリソース
の余裕度を参照し、障害が発生したサービスのリソース
条件のうち最も重要視される項目について、最も余裕度
が高いサービス稼働マシンをサービス代行マシンとし
て、プログラム送信部１２３へ通知する。例えば、サー
ビスＡのリソース条件において、最も重要視されるのは
ＣＰＵの能力であるから、障害が発生していないサービ
ス稼働マシンの中で、最もＣＰＵの余裕度が高いマシン
がサービス代行マシンとして決定される。
【００４０】一方、リソース条件を満たすサービス稼働
マシンが複数あった場合は、ステップＳｂ３の判断結果
がＮＯとなり、ステップＳｂ６へ進む。そして、ステッ
プＳｂ６において、リソース条件を満たすサービス稼働
マシンの中で、最も重要視されるリソース条件の項目に
ついて、最も余裕度が高いサービス稼働マシンをサービ
ス代行マシンとして、プログラム送信部１２３へ通知す
る。
マシンが複数あった場合は、ステップＳｂ３の判断結果
がＮＯとなり、ステップＳｂ６へ進む。そして、ステッ
プＳｂ６において、リソース条件を満たすサービス稼働
マシンの中で、最も重要視されるリソース条件の項目に
ついて、最も余裕度が高いサービス稼働マシンをサービ
ス代行マシンとして、プログラム送信部１２３へ通知す
る。
【００４１】以上のようにしてサービス代行マシンが決
定されると、監視マネージャ１２の処理は、図６のステ
ップＳａ５に進む。そして、ステップＳａ５では、プロ
グラム送信部１２３が、まず、サービスホルダ１１か
ら、障害が発生したサービス稼働マシンが実行していた
サービスアプリケーションのソースコード（ここでは、
ファイル名ＳＡ．ｃ）を読み出す。そして、マシン決定
部１２２が決定したサービス代行マシン（ここでは、サ
ービス稼働マシン１３−２）に対して、読み出したソー
スコードファイルを送信する。
定されると、監視マネージャ１２の処理は、図６のステ
ップＳａ５に進む。そして、ステップＳａ５では、プロ
グラム送信部１２３が、まず、サービスホルダ１１か
ら、障害が発生したサービス稼働マシンが実行していた
サービスアプリケーションのソースコード（ここでは、
ファイル名ＳＡ．ｃ）を読み出す。そして、マシン決定
部１２２が決定したサービス代行マシン（ここでは、サ
ービス稼働マシン１３−２）に対して、読み出したソー
スコードファイルを送信する。
【００４２】そして、ステップＳａ６に進み、サービス
ロケータ１０に記憶されている、各サービス名と各サー
ビスを実行しているサービス稼働マシンのＩＰアドレス
との対応を更新する。ここでは、サービスＡというサー
ビスが、サービス稼働マシン１３−１から１３−２に移
行したので、ＩＰアドレス欄の内容を192.168.0.aaaか
ら192.168.0.bbb に変更する。その後、ステップＳａ１
に戻り、再度、サービス稼働マシンから障害情報を受信
するまで待機状態となる。
ロケータ１０に記憶されている、各サービス名と各サー
ビスを実行しているサービス稼働マシンのＩＰアドレス
との対応を更新する。ここでは、サービスＡというサー
ビスが、サービス稼働マシン１３−１から１３−２に移
行したので、ＩＰアドレス欄の内容を192.168.0.aaaか
ら192.168.0.bbb に変更する。その後、ステップＳａ１
に戻り、再度、サービス稼働マシンから障害情報を受信
するまで待機状態となる。
【００４３】次に、図８のフローチャートを参照して、
図５に示した構成のサービス稼働マシンのうち、主にエ
ージェント部１３１とコンパイラ部１３２の動作につい
て説明する。まず、エージェント部１３１はステップＳ
ｃ１において、自機のＯＳおよびサービスアプリケーシ
ョンに障害が発生したか否かをチェックする。そして、
障害が発生していると判断した場合は、ステップＳｃ２
へ進み、障害が発生したことを示す障害情報を、監視マ
ネージャ１２へ送信する。そして、障害情報の送信が完
了すると、全ての処理を終了する。
図５に示した構成のサービス稼働マシンのうち、主にエ
ージェント部１３１とコンパイラ部１３２の動作につい
て説明する。まず、エージェント部１３１はステップＳ
ｃ１において、自機のＯＳおよびサービスアプリケーシ
ョンに障害が発生したか否かをチェックする。そして、
障害が発生していると判断した場合は、ステップＳｃ２
へ進み、障害が発生したことを示す障害情報を、監視マ
ネージャ１２へ送信する。そして、障害情報の送信が完
了すると、全ての処理を終了する。
【００４４】一方、ステップＳｃ１で障害が認められな
かった場合、判断結果がＮＯとなり、ステップＳｃ３へ
進む。そして、ステップＳｃ３において、監視マネージ
ャ１２から負荷情報の送信要求があったか否かを判断す
る。ここで、監視マネージャ１２から負荷情報の送信要
求があった場合は、判断結果がＹＥＳとなってステップ
Ｓｃ４へ進み、エージェント部１３１は、自機のＣＰＵ
使用率、メモリ使用率、および、ハードディスクの使用
率をチェックする。そして、それらの情報を自機のＣＰ
Ｕ能力と搭載メモリ容量の情報と共に、負荷情報として
監視マネージャ１２へ送信し、ステップＳｃ５へ進む。
また、監視マネージャ１２から負荷情報の送信要求がな
かった場合は、判断結果がＮＯとなって直接ステップＳ
ｃ５へ進む。
かった場合、判断結果がＮＯとなり、ステップＳｃ３へ
進む。そして、ステップＳｃ３において、監視マネージ
ャ１２から負荷情報の送信要求があったか否かを判断す
る。ここで、監視マネージャ１２から負荷情報の送信要
求があった場合は、判断結果がＹＥＳとなってステップ
Ｓｃ４へ進み、エージェント部１３１は、自機のＣＰＵ
使用率、メモリ使用率、および、ハードディスクの使用
率をチェックする。そして、それらの情報を自機のＣＰ
Ｕ能力と搭載メモリ容量の情報と共に、負荷情報として
監視マネージャ１２へ送信し、ステップＳｃ５へ進む。
また、監視マネージャ１２から負荷情報の送信要求がな
かった場合は、判断結果がＮＯとなって直接ステップＳ
ｃ５へ進む。
【００４５】ステップＳｃ５に進むと、エージェント部
１３１は、監視マネージャ１２からソースコードが送信
されてきたか否かを判断する。ここで、監視マネージャ
１２からソースコードが送信されてきていないと判断し
た場合は、判断結果がＮＯとなってステップＳｃ１に戻
り、再度、自機のＯＳおよびサービスアプリケーション
に障害が発生したか否かをチェックする。一方、監視マ
ネージャ１２からソースコードが送信されてきたと判断
した場合は、判断結果がＹＥＳとなってステップＳｃ６
へ進む。
１３１は、監視マネージャ１２からソースコードが送信
されてきたか否かを判断する。ここで、監視マネージャ
１２からソースコードが送信されてきていないと判断し
た場合は、判断結果がＮＯとなってステップＳｃ１に戻
り、再度、自機のＯＳおよびサービスアプリケーション
に障害が発生したか否かをチェックする。一方、監視マ
ネージャ１２からソースコードが送信されてきたと判断
した場合は、判断結果がＹＥＳとなってステップＳｃ６
へ進む。
【００４６】ステップＳｃ６において、エージェント部
１３１は、監視マネージャ１２から送信されてきたソー
スコードをコンパイラ部１３２へ渡す。これにより、コ
ンパイラ部１３２は、渡されたソースコードをコンパイ
ルして実行ファイルを生成する。この時、コンパイラ部
１３２は、エージェント部１３１から受け取ったソース
コード内において、自機で稼働しているＯＳに依存した
コードをコンパイルの対象とする。
１３１は、監視マネージャ１２から送信されてきたソー
スコードをコンパイラ部１３２へ渡す。これにより、コ
ンパイラ部１３２は、渡されたソースコードをコンパイ
ルして実行ファイルを生成する。この時、コンパイラ部
１３２は、エージェント部１３１から受け取ったソース
コード内において、自機で稼働しているＯＳに依存した
コードをコンパイルの対象とする。
【００４７】そして、コンパイラ部１３２によって、実
行ファイルが生成されると、処理部１３３は、現在実行
しているサービスアプリケーションに加え、生成された
実行ファイルも実行する。これにより、当該サービス稼
働マシンにおいて、現在提供しているサービスに加え、
監視マネージャ１２から送信されてきたソースコードに
対応するサービスも提供することになる。
行ファイルが生成されると、処理部１３３は、現在実行
しているサービスアプリケーションに加え、生成された
実行ファイルも実行する。これにより、当該サービス稼
働マシンにおいて、現在提供しているサービスに加え、
監視マネージャ１２から送信されてきたソースコードに
対応するサービスも提供することになる。
【００４８】例えば、前述したように、サービスＡを実
行していたサービス稼働マシン１３−１に障害が発生
し、サービス稼働マシン１３−２，１３−３，１３−４
の各負荷状態がそれぞれ［表１］に示す内容であったと
する。この場合、サービス稼働マシン１３−２の動作
は、まず、監視マネージャ１２の要求に応じて、ステッ
プＳｃ４でエージェント部１３１から、ＣＰＵ能力：２
００ＭＩＰＳ，ＣＰＵ使用率：３０％，メモリ容量：６
４ＭＢ，メモリ使用率：５０％，ＨＤＤ残量：２００Ｍ
Ｂという負荷情報が、監視マネージャ１２へ送信され
る。
行していたサービス稼働マシン１３−１に障害が発生
し、サービス稼働マシン１３−２，１３−３，１３−４
の各負荷状態がそれぞれ［表１］に示す内容であったと
する。この場合、サービス稼働マシン１３−２の動作
は、まず、監視マネージャ１２の要求に応じて、ステッ
プＳｃ４でエージェント部１３１から、ＣＰＵ能力：２
００ＭＩＰＳ，ＣＰＵ使用率：３０％，メモリ容量：６
４ＭＢ，メモリ使用率：５０％，ＨＤＤ残量：２００Ｍ
Ｂという負荷情報が、監視マネージャ１２へ送信され
る。
【００４９】次に、監視マネージャ１２からサービスＡ
のソースコードファイル（ＳＡ．ｃ）が送信されてくる
と、ステップＳｃ６で、コンパイラ部１３２によりその
ソースコードがコンパイルされて、実行ファイルが生成
される。そして生成された実行ファイルが処理部１３３
で実行されることにより、サービス稼働マシン１３−２
において、サービスＢとサービスＡという２種類のサー
ビスが稼働することになる。
のソースコードファイル（ＳＡ．ｃ）が送信されてくる
と、ステップＳｃ６で、コンパイラ部１３２によりその
ソースコードがコンパイルされて、実行ファイルが生成
される。そして生成された実行ファイルが処理部１３３
で実行されることにより、サービス稼働マシン１３−２
において、サービスＢとサービスＡという２種類のサー
ビスが稼働することになる。
【００５０】このように、上述した実施形態において
は、複数のサービス稼働マシンのうち、いずれかのマシ
ンで障害が発生した場合、障害が発生していないマシン
の中から、それらの負荷状態と、障害が発生したマシン
実行していたサービスのリソース条件とに応じて、サー
ビス代行マシンを決定するので、サービスを代行するコ
ンピュータを動的に決定することができる。また、サー
ビスホルダ１１内に、各サービスを実行するプログラム
としてソースコードを格納しておき、監視マネージャ１
２からサービス代行マシンに対してソースコードが送信
された場合、そのサービス代行マシン内のコンパイラ部
１３２が、送信されてきたソースコード内において、自
機で稼働しているＯＳに依存したコードをコンパイルの
対象とするので、サービスが稼働するプラットフォーム
に依存することなく、サービスの復旧が可能となる。
は、複数のサービス稼働マシンのうち、いずれかのマシ
ンで障害が発生した場合、障害が発生していないマシン
の中から、それらの負荷状態と、障害が発生したマシン
実行していたサービスのリソース条件とに応じて、サー
ビス代行マシンを決定するので、サービスを代行するコ
ンピュータを動的に決定することができる。また、サー
ビスホルダ１１内に、各サービスを実行するプログラム
としてソースコードを格納しておき、監視マネージャ１
２からサービス代行マシンに対してソースコードが送信
された場合、そのサービス代行マシン内のコンパイラ部
１３２が、送信されてきたソースコード内において、自
機で稼働しているＯＳに依存したコードをコンパイルの
対象とするので、サービスが稼働するプラットフォーム
に依存することなく、サービスの復旧が可能となる。
【００５１】なお、上述した実施形態では説明を簡略化
するため、サービス稼働マシンの台数を４台としたが、
任意の台数を設けてもよい。また、上述した実施形態の
サービスホルダ１１において、各サービスを実行するた
めのプログラムとしてソースコードを記憶していたが、
これに限らず実行ファイルの形態で記憶させておいても
よい。この場合、各サービス稼働マシン内のコンパイラ
部１３２は不要となる。
するため、サービス稼働マシンの台数を４台としたが、
任意の台数を設けてもよい。また、上述した実施形態の
サービスホルダ１１において、各サービスを実行するた
めのプログラムとしてソースコードを記憶していたが、
これに限らず実行ファイルの形態で記憶させておいても
よい。この場合、各サービス稼働マシン内のコンパイラ
部１３２は不要となる。
【００５２】さらに、図４に示した監視マネージャ１２
の機能を実現するためのプログラムを、コンピュータ読
み取り可能な記録媒体に記録し、この記録媒体に記録さ
れたプログラムをコンピュータシステムに読み込ませ、
実行することにより、各サービス稼働マシンの監視、サ
ービス代行マシンの決定、および、決定したサービス代
行マシンに実行させるサービスのプログラムの送信処理
を行うようにしてもよい。
の機能を実現するためのプログラムを、コンピュータ読
み取り可能な記録媒体に記録し、この記録媒体に記録さ
れたプログラムをコンピュータシステムに読み込ませ、
実行することにより、各サービス稼働マシンの監視、サ
ービス代行マシンの決定、および、決定したサービス代
行マシンに実行させるサービスのプログラムの送信処理
を行うようにしてもよい。
【００５３】ここで、上記「コンピュータシステム」と
は、ＯＳや周辺機器等のハードウェアを含み、さらにＷ
ＷＷシステムを利用している場合であれば、ホームペー
ジ提供環境（あるいは表示環境）も含むものとする。ま
た、「コンピュータ読み取り可能な記録媒体」とは、フ
ロッピーディスク、光磁気ディスク、ＲＯＭ、ＣＤ−Ｒ
ＯＭ等の可搬媒体、コンピュータシステムに内蔵される
ハードディスク等の記憶装置のことをいう。さらに「コ
ンピュータ読み取り可能な記録媒体」とは、インターネ
ット等のネットワークや電話回線等の通信回線を介して
プログラムを送信する場合の通信線のように、短時間の
間、動的にプログラムを保持するもの、その場合のサー
バやクライアントとなるコンピュータシステム内部の揮
発性メモリのように、一定時間プログラムを保持してい
るものも含むものとする。
は、ＯＳや周辺機器等のハードウェアを含み、さらにＷ
ＷＷシステムを利用している場合であれば、ホームペー
ジ提供環境（あるいは表示環境）も含むものとする。ま
た、「コンピュータ読み取り可能な記録媒体」とは、フ
ロッピーディスク、光磁気ディスク、ＲＯＭ、ＣＤ−Ｒ
ＯＭ等の可搬媒体、コンピュータシステムに内蔵される
ハードディスク等の記憶装置のことをいう。さらに「コ
ンピュータ読み取り可能な記録媒体」とは、インターネ
ット等のネットワークや電話回線等の通信回線を介して
プログラムを送信する場合の通信線のように、短時間の
間、動的にプログラムを保持するもの、その場合のサー
バやクライアントとなるコンピュータシステム内部の揮
発性メモリのように、一定時間プログラムを保持してい
るものも含むものとする。
【００５４】また、上記プログラムは、前述した機能の
一部を実現するためのものであっても良く、さらに前述
した機能をコンピュータシステムに既に記録されている
プログラムとの組み合わせで実現できるものであっても
良い。
一部を実現するためのものであっても良く、さらに前述
した機能をコンピュータシステムに既に記録されている
プログラムとの組み合わせで実現できるものであっても
良い。
【００５５】
【発明の効果】以上説明したように、本発明によれば、
各々所定のサービスを提供する複数のコンピュータのう
ち、いずれかのコンピュータで障害が発生した場合、障
害が発生していないコンピュータの中から、それらの負
荷状態と、障害が発生したコンピュータが実行していた
サービスのリソース条件とに応じて、障害が発生したコ
ンピュータが提供していたサービスを代行するコンピュ
ータを決定するので、サービスを代行するコンピュータ
を動的に決定することができる。このため、あるサービ
スに対応した特定の待機系マシンを設置する必要が無
く、複数種類のサービスの復旧が可能となる。さらに、
待機系マシンを動的に追加することができ、また、新規
サービスを追加する場合も、サービス情報記憶手段に新
規サービスを実行するためのプログラムと、そのプログ
ラムを実行するのに要するリソース条件を記憶するだけ
でよいので、新規サービスの追加作業が大幅に軽減され
る。
各々所定のサービスを提供する複数のコンピュータのう
ち、いずれかのコンピュータで障害が発生した場合、障
害が発生していないコンピュータの中から、それらの負
荷状態と、障害が発生したコンピュータが実行していた
サービスのリソース条件とに応じて、障害が発生したコ
ンピュータが提供していたサービスを代行するコンピュ
ータを決定するので、サービスを代行するコンピュータ
を動的に決定することができる。このため、あるサービ
スに対応した特定の待機系マシンを設置する必要が無
く、複数種類のサービスの復旧が可能となる。さらに、
待機系マシンを動的に追加することができ、また、新規
サービスを追加する場合も、サービス情報記憶手段に新
規サービスを実行するためのプログラムと、そのプログ
ラムを実行するのに要するリソース条件を記憶するだけ
でよいので、新規サービスの追加作業が大幅に軽減され
る。
【図１】 本発明に係るサービス復旧システムの一実施
形態の概略構成を示すブロック図である。
形態の概略構成を示すブロック図である。
【図２】 同サービス復旧システム内のサービスロケー
タに記憶されている情報の内容を説明するための説明図
である。
タに記憶されている情報の内容を説明するための説明図
である。
【図３】 同サービス復旧システム内のサービスホルダ
に記憶されている情報の内容を説明するための説明図で
ある。
に記憶されている情報の内容を説明するための説明図で
ある。
【図４】 同サービス復旧システム内の監視マネージャ
の概略構成を示すブロック図である。
の概略構成を示すブロック図である。
【図５】 同サービス復旧システム内のサービス稼働マ
シンの概略構成を示すブロック図である。
シンの概略構成を示すブロック図である。
【図６】 同サービス復旧システム内の監視マネージャ
の動作を示すフローチャートである。
の動作を示すフローチャートである。
【図７】 同監視マネージャ内のマシン決定部の動作を
示すフローチャートである。
示すフローチャートである。
【図８】 本発明に係るサービス復旧システム内のサー
ビス稼働マシンの動作を示すフローチャートである。
ビス稼働マシンの動作を示すフローチャートである。
１ サービス復旧システム ２ ＬＡＮ ３ クライアント １０ サービスロケータ １１ サービスホルダ １２ 監視マネージャ １３−１，１３−２，１３−３，１３−４ サービス
稼働マシン １２０，１３０ 送受信部 １２１ 監視部 １２２ マシン決定部 １２３ プログラム送信部 １３１ エージェント部 １３２ コンパイラ部 １３３ 処理部
稼働マシン １２０，１３０ 送受信部 １２１ 監視部 １２２ マシン決定部 １２３ プログラム送信部 １３１ エージェント部 １３２ コンパイラ部 １３３ 処理部
フロントページの続き (72)発明者 津守 友美 東京都港区港南一丁目９番１号 エヌ・テ ィ・ティ・コミュニケーションウェア株式 会社内 (72)発明者 長岡 亨 東京都港区港南一丁目９番１号 エヌ・テ ィ・ティ・コミュニケーションウェア株式 会社内 Ｆターム(参考） 5B045 GG04 HH02 JJ08 JJ44
Claims (5)
- 【請求項１】 各々所定のサービスを提供する複数のコ
ンピュータと、該複数のコンピュータで発生する障害を
監視する障害監視装置とからなり、該複数のコンピュー
タのいずれかで障害が発生した場合、そのコンピュータ
が提供していたサービスを復旧するサービス復旧システ
ムにおいて、 前記障害監視装置は、 前記各サービスを実行するための複数のプログラムと、
該複数のプログラムを実行するのに要するリソース条件
を記憶したサービス情報記憶手段と、 前記複数のコンピュータのうち、いずれかのコンピュー
タで障害が発生した場合、障害が発生していないコンピ
ュータに対して現在の負荷状態を要求して、当該各コン
ピュータの負荷状態を収集する負荷状態収集手段と、 前記サービス情報記憶手段から前記障害が発生したコン
ピュータが実行していたサービスのリソース条件を読み
出し、該リソース条件と、前記収集した負荷状態とに基
づいて、前記障害が発生したコンピュータが実行してい
たサービスを実行するコンピュータを決定するコンピュ
ータ決定手段と、 前記障害が発生したコンピュータが実行していたサービ
スを実行するためのプログラムを、前記サービス情報記
憶手段から読み出し、前記コンピュータ決定手段により
決定されたコンピュータに送信するプログラム送信手段
とを有することを特徴とするサービス復旧システム。 - 【請求項２】 前記コンピュータ決定手段は、 前記負荷状態収集手段によって収集された負荷状態か
ら、障害が発生していない各コンピュータにおけるリソ
ースの余裕度を求め、 該求めた各コンピュータの余裕度と前記読み出したリソ
ース条件とを比較し、該リソース条件を満足する余裕度
のコンピュータを、前記障害が発生したコンピュータが
実行していたサービスを実行するコンピュータとして決
定することを特徴とする請求項１に記載のサービス復旧
システム。 - 【請求項３】 前記コンピュータ決定手段は、 前記負荷状態収集手段によって収集された負荷状態か
ら、障害が発生していない各コンピュータにおけるリソ
ースの余裕度を求め、 該求めた各コンピュータの余裕度と前記読み出したリソ
ース条件とを比較し、該リソース条件を満足する余裕度
のコンピュータがない場合、前記リソース条件のうち、
最も優先されるべき項目について最も余裕度が大きいコ
ンピュータを、前記障害が発生したコンピュータが実行
していたサービスを実行するコンピュータとして決定す
ることを特徴とする請求項２に記載のサービス復旧シス
テム。 - 【請求項４】 前記コンピュータは、各々、 前記障害監視装置からの要求に応じて現在の負荷状態を
前記障害監視装置へ通知する負荷状態通知手段と、 前記障害監視装置からプログラムが送信されてきた場
合、該プログラムを実行してサービスを提供するプログ
ラム実行手段とを有することを特徴とする請求項１から
３に記載のサービス復旧システム。 - 【請求項５】 各々所定のサービスを提供する複数のコ
ンピュータのいずれかで障害が発生した場合、そのコン
ピュータが提供していたサービスを復旧するサービス復
旧プログラムを記録したコンピュータ読み取り可能な記
録媒体であって、 前記複数のコンピュータのうち、いずれかのコンピュー
タで障害が発生した場合、障害が発生していないコンピ
ュータに対して現在の負荷状態を要求するステップと、 前記各サービスを実行するための複数のプログラムと、
該複数のプログラムを実行するのに要するリソース条件
を記憶した記憶手段から、前記障害が発生したコンピュ
ータが実行していたサービスのリソース条件を読み出す
ステップと、 前記要求に応じて各コンピュータから送信されてきた負
荷状態と前記記憶手段から読み出したリソース条件とに
基づいて、前記障害が発生したコンピュータが実行して
いたサービスを実行するコンピュータを決定するステッ
プと、 前記サービス情報記憶手段から、前記障害が発生したコ
ンピュータが実行していたサービスを実行するためのプ
ログラムを読み出すステップと、 前記読み出したプログラムを、前記決定したコンピュー
タに対して送信するステップとをコンピュータに実行さ
せるサービス復旧プログラムを記録したコンピュータ読
み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP34141599A JP2001155003A (ja) | 1999-11-30 | 1999-11-30 | サービス復旧システムおよびその記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP34141599A JP2001155003A (ja) | 1999-11-30 | 1999-11-30 | サービス復旧システムおよびその記録媒体 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2001155003A true JP2001155003A (ja) | 2001-06-08 |
Family
ID=18345904
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP34141599A Pending JP2001155003A (ja) | 1999-11-30 | 1999-11-30 | サービス復旧システムおよびその記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2001155003A (ja) |
Cited By (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003281007A (ja) * | 2002-03-20 | 2003-10-03 | Fujitsu Ltd | 動的構成制御装置および動的構成制御方法 |
| JP2005031892A (ja) * | 2003-07-10 | 2005-02-03 | Hitachi Ltd | ジョブ実行システム及び実行制御方法 |
| JP2005250840A (ja) * | 2004-03-04 | 2005-09-15 | Nomura Research Institute Ltd | 耐障害システムのための情報処理装置 |
| JP2006285532A (ja) * | 2005-03-31 | 2006-10-19 | Fujitsu Frontech Ltd | サービス提供方法、及びデータ処理装置 |
| JP2007500908A (ja) * | 2003-05-15 | 2007-01-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | オートノミック・フェイルオーバのための方法、装置、およびプログラム |
| JP2007041953A (ja) * | 2005-08-04 | 2007-02-15 | Mitsubishi Heavy Ind Ltd | 制御装置のバックアップ方法及びコンピュータプログラム、並びに制御システム |
| JP2007265013A (ja) * | 2006-03-28 | 2007-10-11 | Fujitsu Ltd | クラスタ制御プログラム、クラスタ制御方法およびクラスタ制御装置 |
| JP2007529067A (ja) * | 2004-03-12 | 2007-10-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 自己修復複合ウェブ・サービスのための方法及び装置 |
| JP2008015950A (ja) * | 2006-07-10 | 2008-01-24 | Mitsubishi Electric Corp | 計算機システム、制御装置、計算機システムの計算機制御方法、制御装置のプロセス制御方法、計算機制御プログラムおよびプロセス制御プログラム |
| JP2009026182A (ja) * | 2007-07-23 | 2009-02-05 | Toshiba Corp | プログラム実行システム及び実行装置 |
| JP2009059084A (ja) * | 2007-08-30 | 2009-03-19 | Denso Corp | 制御システム，電子機器およびプログラム |
| JP2009123238A (ja) * | 2009-03-06 | 2009-06-04 | Mitsubishi Electric Corp | 制御装置、計算機システム、制御装置のプロセス制御方法、計算機システムの計算機制御方法、計算機制御プログラムおよびプロセス制御プログラム |
| JP2009245455A (ja) * | 2009-07-27 | 2009-10-22 | Hitachi Ltd | ディスク引き継ぎによるフェイルオーバ方法 |
| US8069368B2 (en) | 2004-12-09 | 2011-11-29 | Hitachi, Ltd. | Failover method through disk takeover and computer system having failover function |
| CN110300024A (zh) * | 2019-06-28 | 2019-10-01 | 中天宽带技术有限公司 | 一种服务器任务处理方法、装置及其相关设备 |
| JP2021071824A (ja) * | 2019-10-30 | 2021-05-06 | 三菱電機株式会社 | 制御通信システム |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS575162A (en) * | 1980-06-13 | 1982-01-11 | Tokyo Electric Power Co Inc:The | Redundant system controller |
| JPH0793262A (ja) * | 1993-09-27 | 1995-04-07 | Nec Corp | アプリケーションツール実行管理システム |
| JPH09212467A (ja) * | 1996-01-30 | 1997-08-15 | Fujitsu Ltd | 負荷分散制御システム |
| JPH10333917A (ja) * | 1997-05-28 | 1998-12-18 | Nec Software Ltd | 分散コンパイル方式 |
| JPH11184825A (ja) * | 1997-12-19 | 1999-07-09 | Mitsubishi Electric Corp | クラスタシステム |
-
1999
- 1999-11-30 JP JP34141599A patent/JP2001155003A/ja active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS575162A (en) * | 1980-06-13 | 1982-01-11 | Tokyo Electric Power Co Inc:The | Redundant system controller |
| JPH0793262A (ja) * | 1993-09-27 | 1995-04-07 | Nec Corp | アプリケーションツール実行管理システム |
| JPH09212467A (ja) * | 1996-01-30 | 1997-08-15 | Fujitsu Ltd | 負荷分散制御システム |
| JPH10333917A (ja) * | 1997-05-28 | 1998-12-18 | Nec Software Ltd | 分散コンパイル方式 |
| JPH11184825A (ja) * | 1997-12-19 | 1999-07-09 | Mitsubishi Electric Corp | クラスタシステム |
Cited By (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003281007A (ja) * | 2002-03-20 | 2003-10-03 | Fujitsu Ltd | 動的構成制御装置および動的構成制御方法 |
| JP2007500908A (ja) * | 2003-05-15 | 2007-01-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | オートノミック・フェイルオーバのための方法、装置、およびプログラム |
| JP4916881B2 (ja) * | 2003-05-15 | 2012-04-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | オートノミック・フェイルオーバのための方法、装置、およびプログラム |
| JP2005031892A (ja) * | 2003-07-10 | 2005-02-03 | Hitachi Ltd | ジョブ実行システム及び実行制御方法 |
| JP2005250840A (ja) * | 2004-03-04 | 2005-09-15 | Nomura Research Institute Ltd | 耐障害システムのための情報処理装置 |
| JP2007529067A (ja) * | 2004-03-12 | 2007-10-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 自己修復複合ウェブ・サービスのための方法及び装置 |
| US8069368B2 (en) | 2004-12-09 | 2011-11-29 | Hitachi, Ltd. | Failover method through disk takeover and computer system having failover function |
| US8601314B2 (en) | 2004-12-09 | 2013-12-03 | Hitachi, Ltd. | Failover method through disk take over and computer system having failover function |
| US8312319B2 (en) | 2004-12-09 | 2012-11-13 | Hitachi, Ltd. | Failover method through disk takeover and computer system having failover function |
| JP2006285532A (ja) * | 2005-03-31 | 2006-10-19 | Fujitsu Frontech Ltd | サービス提供方法、及びデータ処理装置 |
| JP2007041953A (ja) * | 2005-08-04 | 2007-02-15 | Mitsubishi Heavy Ind Ltd | 制御装置のバックアップ方法及びコンピュータプログラム、並びに制御システム |
| JP4611922B2 (ja) * | 2006-03-28 | 2011-01-12 | 富士通株式会社 | 制御プログラム、制御方法および制御装置 |
| US8281007B2 (en) | 2006-03-28 | 2012-10-02 | Fujitsu Limited | Cluster control apparatus, cluster control method, and computer product |
| JP2007265013A (ja) * | 2006-03-28 | 2007-10-11 | Fujitsu Ltd | クラスタ制御プログラム、クラスタ制御方法およびクラスタ制御装置 |
| JP2008015950A (ja) * | 2006-07-10 | 2008-01-24 | Mitsubishi Electric Corp | 計算機システム、制御装置、計算機システムの計算機制御方法、制御装置のプロセス制御方法、計算機制御プログラムおよびプロセス制御プログラム |
| JP2009026182A (ja) * | 2007-07-23 | 2009-02-05 | Toshiba Corp | プログラム実行システム及び実行装置 |
| JP2009059084A (ja) * | 2007-08-30 | 2009-03-19 | Denso Corp | 制御システム，電子機器およびプログラム |
| JP2009123238A (ja) * | 2009-03-06 | 2009-06-04 | Mitsubishi Electric Corp | 制御装置、計算機システム、制御装置のプロセス制御方法、計算機システムの計算機制御方法、計算機制御プログラムおよびプロセス制御プログラム |
| JP4485592B2 (ja) * | 2009-03-06 | 2010-06-23 | 三菱電機株式会社 | 計算機システムおよび計算機システムの計算機制御方法 |
| JP2009245455A (ja) * | 2009-07-27 | 2009-10-22 | Hitachi Ltd | ディスク引き継ぎによるフェイルオーバ方法 |
| CN110300024A (zh) * | 2019-06-28 | 2019-10-01 | 中天宽带技术有限公司 | 一种服务器任务处理方法、装置及其相关设备 |
| JP2021071824A (ja) * | 2019-10-30 | 2021-05-06 | 三菱電機株式会社 | 制御通信システム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2001155003A (ja) | サービス復旧システムおよびその記録媒体 | |
| EP1974529B1 (en) | Method and apparatus for collecting data for characterizing http session workloads | |
| JP4215384B2 (ja) | 分散コンピューティング環境で複数の関係する障害を表す障害情報を参照する技法 | |
| JP5102901B2 (ja) | データセンタにわたる複数データサーバ間のデータ完全性を保持する方法およびシステム | |
| US5993038A (en) | Distributed application load distribution aid tool | |
| US20080082863A1 (en) | System and Method for Maintaining Functionality During Component Failures | |
| WO2002091204A2 (en) | Data center providing geographic redundancy | |
| JP2011237950A (ja) | 情報処理装置、バックアップサーバ、バックアッププログラム、バックアップ方法及びバックアップシステム | |
| CN106911802B (zh) | 分布式块存储系统的管理平台的部署方法和装置 | |
| EP2240858A1 (en) | Method for using dynamically scheduled synthetic transactions to monitor performance and availability of e-business systems | |
| US6862732B1 (en) | Method and apparatus for event-driven processing of data | |
| CN100559790C (zh) | 维护高可用性处理环境的方法和系统 | |
| JP2009151509A (ja) | 計算機装置 | |
| JP4881760B2 (ja) | ログ管理装置、ログ管理方法、プログラム、及び記録媒体 | |
| JPH07168778A (ja) | ネットワーク装置およびマルチプロセッサ装置 | |
| US8036105B2 (en) | Monitoring a problem condition in a communications system | |
| JP2001147839A (ja) | 情報収集装置、情報生成装置、情報収集プログラムを記録したコンピュータ読み取り可能な記録媒体および情報生成プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| CN113626139B (zh) | 一种高可用的虚拟机存储方法及装置 | |
| JP2000047912A (ja) | ネットワークサービス監視方法および装置とネットワークサービス監視プログラムを記録した記録媒体 | |
| JP2019153055A (ja) | クラスタシステム、情報処理装置、クラスタ監視方法及びクラスタ監視プログラム | |
| JP2008250427A (ja) | 情報処理システムに用いられるバージョンアップ装置及び該装置を備えた情報処理システム並びに情報処理システムをバージョンアップするためのプログラム | |
| JP4856949B2 (ja) | フェイルオーバ方法、フェイルオーバプログラム、および、クラスタシステム | |
| JP3860385B2 (ja) | 動的連携情報引継ぎ方法，連携プロセス制御装置およびそのプログラム記録媒体 | |
| JP2003006018A (ja) | 処理要求復旧方式及び処理要求復旧方法及びクライアント装置及びサーバ装置 | |
| JP2004062470A (ja) | マルチプロセッサの切り替え方式 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040224 |