JP3291931B2 - サービス障害復旧方法 - Google Patents
サービス障害復旧方法Info
- Publication number
- JP3291931B2 JP3291931B2 JP20757194A JP20757194A JP3291931B2 JP 3291931 B2 JP3291931 B2 JP 3291931B2 JP 20757194 A JP20757194 A JP 20757194A JP 20757194 A JP20757194 A JP 20757194A JP 3291931 B2 JP3291931 B2 JP 3291931B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- processing
- abnormality
- gom
- substitute
- 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.)
- Expired - Fee Related
Links
Landscapes
- Multi Processors (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【産業上の利用分野】本発明は、オブジェクト指向ソフ
トウェアを搭載した処理装置上で動作するオブジェクト
インスタンスを単位としたサービス障害復旧方法に関す
るもので、通信サービス、計算サービスを代表とする、
コンピュータを利用するすべてのサービスに利用できる
サービス障害復旧方法に関するものである。
トウェアを搭載した処理装置上で動作するオブジェクト
インスタンスを単位としたサービス障害復旧方法に関す
るもので、通信サービス、計算サービスを代表とする、
コンピュータを利用するすべてのサービスに利用できる
サービス障害復旧方法に関するものである。
【０００２】
【従来の技術】従来、サービスの運用管理は、処理装置
ハードウェアの障害／性能管理で実現されている。即
ち、多くのサービス処理機能を内包したサービス実行制
御装置を単位とした監視、障害復旧を行なっている。
ハードウェアの障害／性能管理で実現されている。即
ち、多くのサービス処理機能を内包したサービス実行制
御装置を単位とした監視、障害復旧を行なっている。
【０００３】図２に従来例のサービスの監視及び障害復
旧方法の概略を示す。図２の(a) に示すように、各サー
ビス処理ノード１には通信サービスの実行を司る主系の
サービス実行制御装置２ａが実装されている。各々のサ
ービス実行制御装置２ａに対応して、バックアップ用と
しての予備系サービス実行制御装置２ｂが同一のサービ
ス処理ノード１に設けられている。
旧方法の概略を示す。図２の(a) に示すように、各サー
ビス処理ノード１には通信サービスの実行を司る主系の
サービス実行制御装置２ａが実装されている。各々のサ
ービス実行制御装置２ａに対応して、バックアップ用と
しての予備系サービス実行制御装置２ｂが同一のサービ
ス処理ノード１に設けられている。
【０００４】また、各サービス処理ノード１には、主系
及び予備系のサービス実行制御装置２ａ，２ｂを監視す
る監視装置３が備えられている。監視装置３は、主系の
サービス実行制御装置２ａが障害を起こした場合に、コ
ールドスタンバイ、ホットスタンバイなどの技術を用い
て予備系のサービス実行制御装置２ｂへの切り替え操作
を実行する。
及び予備系のサービス実行制御装置２ａ，２ｂを監視す
る監視装置３が備えられている。監視装置３は、主系の
サービス実行制御装置２ａが障害を起こした場合に、コ
ールドスタンバイ、ホットスタンバイなどの技術を用い
て予備系のサービス実行制御装置２ｂへの切り替え操作
を実行する。
【０００５】また、図２の(b) に示すように、主系と予
備系双方のサービス実行制御装置２ａ，２ｂが同時に運
用不可能となった場合に、そのサービス処理ノード１が
サービスの提供を継続できなくなったことを通信網管理
ノード４内の通信網管理システム５に通知する。
備系双方のサービス実行制御装置２ａ，２ｂが同時に運
用不可能となった場合に、そのサービス処理ノード１が
サービスの提供を継続できなくなったことを通信網管理
ノード４内の通信網管理システム５に通知する。
【０００６】通信網管理システム５は、サービス処理ノ
ード１内の監視装置３から通知を受けると、障害を起こ
したサービス実行制御装置２ａ，２ｂから他のサービス
処理ノード６内のサービス実行制御装置７ａ，７ｂへの
切り替えによる復旧措置を実行する。ここで、サービス
処理ノード６にも、前述と同様に主系及び予備系のサー
ビス実行制御装置７ａ，７ｂを監視する監視装置８が備
えられ、監視装置８は、主系のサービス実行制御装置７
ａが障害を起こした場合に、コールドスタンバイ、ホッ
トスタンバイなどの技術を用いて予備系のサービス実行
制御装置７ｂへの切り替え操作を実行する。
ード１内の監視装置３から通知を受けると、障害を起こ
したサービス実行制御装置２ａ，２ｂから他のサービス
処理ノード６内のサービス実行制御装置７ａ，７ｂへの
切り替えによる復旧措置を実行する。ここで、サービス
処理ノード６にも、前述と同様に主系及び予備系のサー
ビス実行制御装置７ａ，７ｂを監視する監視装置８が備
えられ、監視装置８は、主系のサービス実行制御装置７
ａが障害を起こした場合に、コールドスタンバイ、ホッ
トスタンバイなどの技術を用いて予備系のサービス実行
制御装置７ｂへの切り替え操作を実行する。
【０００７】
【発明が解決しようとする課題】しかしながら、前述し
た従来のサービス障害復旧方法では、サービス実行制御
装置２ａ，２ｂ，７ａ，７ｂ内で動作する個々のサービ
ス処理機能単位の監視には着目していないため、この方
法に従ってサービス実行制御装置２ａ，２ｂ，７ａ，７
ｂの切り替え処理を実行すると、そのサービス実行制御
装置２ａ，２ｂ，７ａ，７ｂ内で動作している他の正常
なオブジェクトインスタンス（以下、ＯＩと称する）ま
でも停止させてしまう。
た従来のサービス障害復旧方法では、サービス実行制御
装置２ａ，２ｂ，７ａ，７ｂ内で動作する個々のサービ
ス処理機能単位の監視には着目していないため、この方
法に従ってサービス実行制御装置２ａ，２ｂ，７ａ，７
ｂの切り替え処理を実行すると、そのサービス実行制御
装置２ａ，２ｂ，７ａ，７ｂ内で動作している他の正常
なオブジェクトインスタンス（以下、ＯＩと称する）ま
でも停止させてしまう。
【０００８】従って、該サービス制御装置２ａ，２ｂ，
７ａ，７ｂが複数のサービスに関わっている場合、サー
ビス制御装置２ａ，２ｂ，７ａ，７ｂを切り替えること
により、本来継続して提供すべきサービスまで一時的に
停止させてしまうという問題点があった。
７ａ，７ｂが複数のサービスに関わっている場合、サー
ビス制御装置２ａ，２ｂ，７ａ，７ｂを切り替えること
により、本来継続して提供すべきサービスまで一時的に
停止させてしまうという問題点があった。
【０００９】本発明の目的は、サービス処理機能を搭載
した装置上で動作する、サービス処理機能の構成要素と
してのＯＩ単位で障害復旧を実現し、当該ＯＩの異常に
よるサービス全体への影響度を最小化したサービス障害
復旧方法を提供することにある。
した装置上で動作する、サービス処理機能の構成要素と
してのＯＩ単位で障害復旧を実現し、当該ＯＩの異常に
よるサービス全体への影響度を最小化したサービス障害
復旧方法を提供することにある。
【００１０】
【課題を解決するための手段】本発明は上記の目的を達
成するために、請求項１では、自己試験機能を有する全
てのオブジェクトインスタンス（ＯＩ）を管理する総合
オブジェクトマネージャ（ＧＯＭ）と、ＯＩ間の通信処
理を管理する通信処理管理部とを備え、互いに独立して
動作するＯＩが、メッセージを交信し合い、依頼された
処理の一部を必要に応じてサーバＯＩに依頼して、ＯＩ
群全体として所望の処理機能を実現するオブジェクト指
向ソフトウェアを用いて、計算／通信サービスを実現す
るサービス処理装置におけるサービス障害復旧方法にお
いて、各ＯＩは、自分自身及び自分自身が処理を依頼し
ているサーバＯＩ並びに通信処理機能のそれぞれの異常
を検出したときに前記ＧＯＭに通知し、前記ＧＯＭは、
ＯＩから自己の異常発生の申告通知を受けたときに、前
記通知された異常の内容に基づいて、該申告したＯＩを
消去するか或いはそのまま動作させるかを決定し、前記
申告したＯＩを消去するときは、負荷バランスが偏らな
いように代用ＯＩを他のＯＩの中から選択するか又は新
規に作成し、ＯＩから該ＯＩが使用しているサーバＯＩ
（ＯＩ S ）の異常発生を申告する通知を受けたときに、
該申告されたサーバＯＩ（ＯＩ S ）及び該申告されたサ
ーバＯＩ（ＯＩ S ）が依頼された処理を行う他のサーバ
ＯＩ（ＯＩ SS ）に対して順次正常性の確認処理を行い、
異常を来しているＯＩ及び異常を来しているＯＩ間通信
処理機能を特定し、異常を来しているＯＩを代用ＯＩに
切り替える処理を実行し、通信処理障害の復旧を前記通
信処理管理部に依頼し、以後、異常を来したＯＩの代わ
りに前記代用ＯＩを前記サービスで用い、サービスを継
続的に提供させるサービス障害復旧方法を提案する。
成するために、請求項１では、自己試験機能を有する全
てのオブジェクトインスタンス（ＯＩ）を管理する総合
オブジェクトマネージャ（ＧＯＭ）と、ＯＩ間の通信処
理を管理する通信処理管理部とを備え、互いに独立して
動作するＯＩが、メッセージを交信し合い、依頼された
処理の一部を必要に応じてサーバＯＩに依頼して、ＯＩ
群全体として所望の処理機能を実現するオブジェクト指
向ソフトウェアを用いて、計算／通信サービスを実現す
るサービス処理装置におけるサービス障害復旧方法にお
いて、各ＯＩは、自分自身及び自分自身が処理を依頼し
ているサーバＯＩ並びに通信処理機能のそれぞれの異常
を検出したときに前記ＧＯＭに通知し、前記ＧＯＭは、
ＯＩから自己の異常発生の申告通知を受けたときに、前
記通知された異常の内容に基づいて、該申告したＯＩを
消去するか或いはそのまま動作させるかを決定し、前記
申告したＯＩを消去するときは、負荷バランスが偏らな
いように代用ＯＩを他のＯＩの中から選択するか又は新
規に作成し、ＯＩから該ＯＩが使用しているサーバＯＩ
（ＯＩ S ）の異常発生を申告する通知を受けたときに、
該申告されたサーバＯＩ（ＯＩ S ）及び該申告されたサ
ーバＯＩ（ＯＩ S ）が依頼された処理を行う他のサーバ
ＯＩ（ＯＩ SS ）に対して順次正常性の確認処理を行い、
異常を来しているＯＩ及び異常を来しているＯＩ間通信
処理機能を特定し、異常を来しているＯＩを代用ＯＩに
切り替える処理を実行し、通信処理障害の復旧を前記通
信処理管理部に依頼し、以後、異常を来したＯＩの代わ
りに前記代用ＯＩを前記サービスで用い、サービスを継
続的に提供させるサービス障害復旧方法を提案する。
【００１１】また、請求項２では、請求項１記載のサー
ビス障害復旧方法において、前記ＧＯＭは各ＯＩに対し
て定期的に試験を要求することによりＯＩの動作異常を
検出するサービス障害復旧方法を提案する。
ビス障害復旧方法において、前記ＧＯＭは各ＯＩに対し
て定期的に試験を要求することによりＯＩの動作異常を
検出するサービス障害復旧方法を提案する。
【００１２】
【作用】本発明の請求項１によれば、ＯＩの動作異常が
発生した時に、ＧＯＭによって該ＯＩの代用となる代用
ＯＩが自動的に他のＯＩの中から選択されるか又は前記
代用ＯＩが自動的に新規に作成され、以後、異常を来し
たＯＩの代わりに前記代用ＯＩが前記サービスで用いら
れ、サービスが継続的に提供される。
発生した時に、ＧＯＭによって該ＯＩの代用となる代用
ＯＩが自動的に他のＯＩの中から選択されるか又は前記
代用ＯＩが自動的に新規に作成され、以後、異常を来し
たＯＩの代わりに前記代用ＯＩが前記サービスで用いら
れ、サービスが継続的に提供される。
【００１３】また、請求項２によれば、前記ＧＯＭによ
って各ＯＩに対して定期的に試験が要求され、これによ
りＯＩの動作異常が検出される。
って各ＯＩに対して定期的に試験が要求され、これによ
りＯＩの動作異常が検出される。
【００１４】
【実施例】以下、図面に基づいて本発明の一実施例を説
明する。図１は本発明の一実施例を説明する図である。
図において、ＯＩA は着目している処理を進行させてい
るＯＩ、ＯＩC はＯＩA に処理を依頼しているクライア
ントＯＩ、ＯＩS はＯＩC から依頼された処理を実行す
るためにＯＩA が必要に応じて処理を依頼しているサー
バＯＩをそれぞれ表す（以後、これらの略式表記を用い
る）。これらの構成は、従来例において説明したサービ
ス実行制御装置内に設けられている。
明する。図１は本発明の一実施例を説明する図である。
図において、ＯＩA は着目している処理を進行させてい
るＯＩ、ＯＩC はＯＩA に処理を依頼しているクライア
ントＯＩ、ＯＩS はＯＩC から依頼された処理を実行す
るためにＯＩA が必要に応じて処理を依頼しているサー
バＯＩをそれぞれ表す（以後、これらの略式表記を用い
る）。これらの構成は、従来例において説明したサービ
ス実行制御装置内に設けられている。
【００１５】また、本実施例におけるサービスは、サー
ビス実行制御装置上で動作するサービス処理機能、或い
はその構成要素であるＯＩ同士が規定の手順に従いメッ
セージを交信（処理を依頼）した結果として提供され
る。
ビス実行制御装置上で動作するサービス処理機能、或い
はその構成要素であるＯＩ同士が規定の手順に従いメッ
セージを交信（処理を依頼）した結果として提供され
る。
【００１６】ここで本実施例では、以下の機能を保持す
る総合オブジェクトマネージャ（以下、ＧＯＭと称す
る）を設けることにより、ＯＩ単位での試験／切り替え
処理を実現し、ＯＩの異常（障害／性能低下）の迅速な
検出／復旧措置を可能とすると共に、動作異常を起こし
たＯＩに代えて代用ＯＩを用いるところに特徴がある。
る総合オブジェクトマネージャ（以下、ＧＯＭと称す
る）を設けることにより、ＯＩ単位での試験／切り替え
処理を実現し、ＯＩの異常（障害／性能低下）の迅速な
検出／復旧措置を可能とすると共に、動作異常を起こし
たＯＩに代えて代用ＯＩを用いるところに特徴がある。
【００１７】ＧＯＭが保持する機能としては、 ・ＯＩから異常の通知を受けたときに、異常を起こした
ＯＩを特定する機能 ・異常と見られるＯＩを代用のＯＩへ切り替える機能 ・ＯＩの自己試験機能の正常性を確認するため、各ＯＩ
に自己試験を行なうように要求する機能 があり、また各ＯＩは、ＯＩ自身、ＯＩが現時点で処理
を依頼しているサーバＯＩ、及び通信処理機能の異常
（障害／性能低下）の可能性を検出し、ＧＯＭに通知す
る機能を有している。さらに、ＧＯＭは、各ＯＩの動作
正常性、負荷、配置位置などをもとに、ＯＩ間の処理依
頼の関係を適宜変更させる。このとき、ＧＯＭは必要に
応じて以下の各マネージャと協調動作する。
ＯＩを特定する機能 ・異常と見られるＯＩを代用のＯＩへ切り替える機能 ・ＯＩの自己試験機能の正常性を確認するため、各ＯＩ
に自己試験を行なうように要求する機能 があり、また各ＯＩは、ＯＩ自身、ＯＩが現時点で処理
を依頼しているサーバＯＩ、及び通信処理機能の異常
（障害／性能低下）の可能性を検出し、ＧＯＭに通知す
る機能を有している。さらに、ＧＯＭは、各ＯＩの動作
正常性、負荷、配置位置などをもとに、ＯＩ間の処理依
頼の関係を適宜変更させる。このとき、ＧＯＭは必要に
応じて以下の各マネージャと協調動作する。
【００１８】ＧＯＭがＯＩの異常に対処するために協調
動作するマネージャとしては、 ・ＯＩを生成／消去する働きをするＯＩ生成／消去マネ
ージャ（以下、ＯＩＲと称する） ・各ＯＩが正常終了させた処理に関する情報を保持する
処理ログマネージャ（以下、ＰＬＭと称する） ・各ＯＩの運用状態やＯＩ間の処理依頼関係の情報を保
持するＯＩデータベース（以下、ＯＩＤＢと称する）が
設けられている。
動作するマネージャとしては、 ・ＯＩを生成／消去する働きをするＯＩ生成／消去マネ
ージャ（以下、ＯＩＲと称する） ・各ＯＩが正常終了させた処理に関する情報を保持する
処理ログマネージャ（以下、ＰＬＭと称する） ・各ＯＩの運用状態やＯＩ間の処理依頼関係の情報を保
持するＯＩデータベース（以下、ＯＩＤＢと称する）が
設けられている。
【００１９】一方、ＯＩＤＢは、ＯＩの運用及び障害復
旧に必要な情報として、図３に示すように、運用中の各
ＯＩについて以下の各項目の情報を保持している。 （１）網内で一意に認識できるＯＩ名 （２）実行処理名（ＯＩが保持し、実行する処理名） （３）代用となりうる（運用中の）ＯＩ名のリスト（Su
b OI List ） このリストは、ＯＩに異常が発生したときに、それ以後
代わりに用いるＯＩ（代用ＯＩ）を決定するときに用い
られる。 （４）ＯＩをＯＩS として用いるＯＩ名のリスト（ＯＩ
C Ｌｉｓｔ） このリストは、ＯＩに異常が発生したときに、それをＯ
ＩS として使用する全てのＯＩに対して、以後その異常
となったＯＩを用いないように通知するために用いられ
る。
旧に必要な情報として、図３に示すように、運用中の各
ＯＩについて以下の各項目の情報を保持している。 （１）網内で一意に認識できるＯＩ名 （２）実行処理名（ＯＩが保持し、実行する処理名） （３）代用となりうる（運用中の）ＯＩ名のリスト（Su
b OI List ） このリストは、ＯＩに異常が発生したときに、それ以後
代わりに用いるＯＩ（代用ＯＩ）を決定するときに用い
られる。 （４）ＯＩをＯＩS として用いるＯＩ名のリスト（ＯＩ
C Ｌｉｓｔ） このリストは、ＯＩに異常が発生したときに、それをＯ
ＩS として使用する全てのＯＩに対して、以後その異常
となったＯＩを用いないように通知するために用いられ
る。
【００２０】（５）使用可／不可 これは、ＯＩに処理の依頼ができるかできないかを記し
たもので、各ＯＩの状態管理に用いられる。ＯＩに異常
が発生したとき、そのＯＩに関するこの項目を「不可」
とすることにより、そのＯＩがＧＯＭにより他のＯＩの
代用として割り当てられたり、動的結合機能（以下、Ｄ
ＢＦと称する）によりそのＯＩに処理要求が受け渡され
ることがなくなる。従って、それ以後その異常となった
ＯＩに起因するサービス障害を防止することができる。
たもので、各ＯＩの状態管理に用いられる。ＯＩに異常
が発生したとき、そのＯＩに関するこの項目を「不可」
とすることにより、そのＯＩがＧＯＭにより他のＯＩの
代用として割り当てられたり、動的結合機能（以下、Ｄ
ＢＦと称する）によりそのＯＩに処理要求が受け渡され
ることがなくなる。従って、それ以後その異常となった
ＯＩに起因するサービス障害を防止することができる。
【００２１】ＤＢＦは、実際のメッセージの交信の発生
時に処理依頼先を決定する動的結合を実行する。この機
能は周知の分散処理の技術（ディレクトリ、トレーダー
等）で実現されうるものである。
時に処理依頼先を決定する動的結合を実行する。この機
能は周知の分散処理の技術（ディレクトリ、トレーダー
等）で実現されうるものである。
【００２２】ＤＢＦが行なう動的結合の実行手順を以下
に示す。 ・各ＯＩから、ＯＩS に依頼する処理名及びオブジェク
ト名を受ける。 ・ＯＩＤＢ内のＯＩS についての使用可／不可の項目を
調べる。 （ａ）使用可のとき 依頼された処理を実行するようにＯＩS に依頼する。 （ｂ）使用不可のとき ・ＯＩＤＢに依頼処理を実行できるＯＩ名（ＯＩS 候
補）のリストを要求する。 ・ 任意に、あるいは各々のＯＩの不可レベル（次項目）
をもとに、新しい処理依頼先（ＯＩS ）を決定する。 ・ＤＢＦがＯＩS に処理を依頼する（このときＯＩS に
とってのＯＩC は、ＤＢＦではなく処理依頼元のＯＩで
ある）。
に示す。 ・各ＯＩから、ＯＩS に依頼する処理名及びオブジェク
ト名を受ける。 ・ＯＩＤＢ内のＯＩS についての使用可／不可の項目を
調べる。 （ａ）使用可のとき 依頼された処理を実行するようにＯＩS に依頼する。 （ｂ）使用不可のとき ・ＯＩＤＢに依頼処理を実行できるＯＩ名（ＯＩS 候
補）のリストを要求する。 ・ 任意に、あるいは各々のＯＩの不可レベル（次項目）
をもとに、新しい処理依頼先（ＯＩS ）を決定する。 ・ＤＢＦがＯＩS に処理を依頼する（このときＯＩS に
とってのＯＩC は、ＤＢＦではなく処理依頼元のＯＩで
ある）。
【００２３】（６）負荷レベル これは、ある計測時間内での、ＯＩに依頼される単位時
間当たりの処理数、及び最多／最小処理キュー数で決ま
る値であり、一定時間毎に新しい値に変更され、ＯＩ間
の処理の負荷バランスをとるために用いられる。
間当たりの処理数、及び最多／最小処理キュー数で決ま
る値であり、一定時間毎に新しい値に変更され、ＯＩ間
の処理の負荷バランスをとるために用いられる。
【００２４】ＯＩＲは、ＯＩを配備（ノード内のプロセ
スとして生成）すると、そのＯＩ名Ｓｕｂ ＯＩ Ｌｉｓ
ｔ，及びＯＩC ＬｉｓｔをＯＩＤＢに登録する。
スとして生成）すると、そのＯＩ名Ｓｕｂ ＯＩ Ｌｉｓ
ｔ，及びＯＩC ＬｉｓｔをＯＩＤＢに登録する。
【００２５】ＯＩが検出した異常の内容がそのＯＩから
ＧＯＭに対して通知されると、ＧＯＭはその通知内容と
各ＯＩの運用状況を調べることにより異常箇所の決定及
び復旧措置を実行する。なお、各ＯＩは、自らがＯＩS
に依頼した処理が正常に終了しなかったことを検出する
ことで、ＯＩS または通信処理機能に障害が発生したと
判断する。
ＧＯＭに対して通知されると、ＧＯＭはその通知内容と
各ＯＩの運用状況を調べることにより異常箇所の決定及
び復旧措置を実行する。なお、各ＯＩは、自らがＯＩS
に依頼した処理が正常に終了しなかったことを検出する
ことで、ＯＩS または通信処理機能に障害が発生したと
判断する。
【００２６】次に、ＯＩが検出した異常別にその対処方
法を説明する。 ＜ＯＩが自身の異常を検出したとき＞ＯＩが自身の異常
を検出したときの障害復旧の手順を図４乃至図６に基づ
いて説明する。このケースでは、ＧＯＭは以下の手続き
を実行する。
法を説明する。 ＜ＯＩが自身の異常を検出したとき＞ＯＩが自身の異常
を検出したときの障害復旧の手順を図４乃至図６に基づ
いて説明する。このケースでは、ＧＯＭは以下の手続き
を実行する。
【００２７】ＯＩからそのＯＩ自身の異常の通知を受け
た（図４(0) ）場合（ＳＡ１）、ＧＯＭは以下の手順で
ＯＩの切り替え手続きを実行する。
た（図４(0) ）場合（ＳＡ１）、ＧＯＭは以下の手順で
ＯＩの切り替え手続きを実行する。
【００２８】（１）ＯＩＤＢが保持する情報のうち、異
常と申告されたＯＩに関する使用可／不可の項目を「不
可」に変更するように要求する（図４(1) ）（ＳＡ
２）。これにより、異常と申告されたＯＩがＧＯＭによ
り他のＯＩの代用として割り当てられたり、ＤＢＦによ
り異常と申告されたＯＩに処理要求が受け渡されること
がなくなる。
常と申告されたＯＩに関する使用可／不可の項目を「不
可」に変更するように要求する（図４(1) ）（ＳＡ
２）。これにより、異常と申告されたＯＩがＧＯＭによ
り他のＯＩの代用として割り当てられたり、ＤＢＦによ
り異常と申告されたＯＩに処理要求が受け渡されること
がなくなる。
【００２９】（２）通知された異常の内容（エラー種
別、サービス種別など）の項目の内容から、異常と申告
されたＯＩを即時に消去するか、一連のＯＩ切り替え処
理実行後に消去するか、そのまま動作させるかを決定す
る（図４(2-1))。即時消去の場合は、ＧＯＭがこの時点
でＯＩＲに異常と申告されたＯＩの消去の実行を要求す
る（図４(2-2) ）。ＯＩＲは異常と申告されたＯＩを消
去した後に、異常と申告されたＯＩに関するＯＩＤＢ内
の情報を消去するように要求する（図４(2-3) ）（ＳＡ
３）。
別、サービス種別など）の項目の内容から、異常と申告
されたＯＩを即時に消去するか、一連のＯＩ切り替え処
理実行後に消去するか、そのまま動作させるかを決定す
る（図４(2-1))。即時消去の場合は、ＧＯＭがこの時点
でＯＩＲに異常と申告されたＯＩの消去の実行を要求す
る（図４(2-2) ）。ＯＩＲは異常と申告されたＯＩを消
去した後に、異常と申告されたＯＩに関するＯＩＤＢ内
の情報を消去するように要求する（図４(2-3) ）（ＳＡ
３）。
【００３０】この後、ＧＯＭは、異常と申告されたＯＩ
をそのまま動作させるか否かを判定し（ＳＡ４）、異常
と申告されたＯＩをそのまま動作させる場合は、ＯＩＲ
は、ＯＩＤＢが保持する情報のうち、異常と申告された
ＯＩに関する使用可／不可の項目を「可」にするように
要求する（図４(2-4))（ＳＡ５）。
をそのまま動作させるか否かを判定し（ＳＡ４）、異常
と申告されたＯＩをそのまま動作させる場合は、ＯＩＲ
は、ＯＩＤＢが保持する情報のうち、異常と申告された
ＯＩに関する使用可／不可の項目を「可」にするように
要求する（図４(2-4))（ＳＡ５）。
【００３１】（３）ＯＩＤＢに対し、異常と申告された
ＯＩをＯＩS として用いるすべてのＯＩ名のリスト（Ｏ
ＩC Ｌｉｓｔ）を要求する（図４(3) ）（ＳＡ６）。
ＯＩをＯＩS として用いるすべてのＯＩ名のリスト（Ｏ
ＩC Ｌｉｓｔ）を要求する（図４(3) ）（ＳＡ６）。
【００３２】（４）ＯＩC Ｌｉｓｔ 中のすべてのＯＩ
に対し、異常と申告されたＯＩに対する直接の処理依頼
を全て停止し、以後指示があるまで、ＤＢＦを通して処
理をＯＩS に依頼するように指示する（図４(4-1) ）。
ＤＢＦは、代用ＯＩ名を処理要求元にも知らせる。以
後、処理要求元ＯＩが同一の内容の処理を依頼するとき
は、後に正式な代用ＯＩをＧＯＭから知らされるまで、
ＤＢＦから指定された仮の代用ＯＩを一時的に用いる
（図４(4-2) ）（ＳＡ７）。
に対し、異常と申告されたＯＩに対する直接の処理依頼
を全て停止し、以後指示があるまで、ＤＢＦを通して処
理をＯＩS に依頼するように指示する（図４(4-1) ）。
ＤＢＦは、代用ＯＩ名を処理要求元にも知らせる。以
後、処理要求元ＯＩが同一の内容の処理を依頼するとき
は、後に正式な代用ＯＩをＧＯＭから知らされるまで、
ＤＢＦから指定された仮の代用ＯＩを一時的に用いる
（図４(4-2) ）（ＳＡ７）。
【００３３】（５）ＯＩＤＢに対し、その異常と申告さ
れたＯＩの代用として用いることのできるＯＩ名のリス
トを要求し（図５(5-1) ）（ＳＡ８）、得られたリスト
から、代用として用いるＯＩ（代用ＯＩ）名を決定する
（図４(5-2) ）。代用ＯＩを一つとするとＯＩ間の負荷
（これはＧＯＭが定期的に収集している）のバランスが
偏る場合は、代用ＯＩを複数設定し、ＯＩC Ｌｉｓｔ中
のＯＩ単位で代用ＯＩを割り当てる。またこのとき、異
常と申告されたＯＩとの配備位置関係（サービス実行制
御装置に異常が見られない場合はその装置上のＯＩを、
ＯＩが動作するノードに障害が見られる場合はその近傍
のノードのサービス実行制御装置上のＯＩを優先的に選
択）についても考慮する（ＳＡ９，ＳＡ１０）。
れたＯＩの代用として用いることのできるＯＩ名のリス
トを要求し（図５(5-1) ）（ＳＡ８）、得られたリスト
から、代用として用いるＯＩ（代用ＯＩ）名を決定する
（図４(5-2) ）。代用ＯＩを一つとするとＯＩ間の負荷
（これはＧＯＭが定期的に収集している）のバランスが
偏る場合は、代用ＯＩを複数設定し、ＯＩC Ｌｉｓｔ中
のＯＩ単位で代用ＯＩを割り当てる。またこのとき、異
常と申告されたＯＩとの配備位置関係（サービス実行制
御装置に異常が見られない場合はその装置上のＯＩを、
ＯＩが動作するノードに障害が見られる場合はその近傍
のノードのサービス実行制御装置上のＯＩを優先的に選
択）についても考慮する（ＳＡ９，ＳＡ１０）。
【００３４】（６）適当な代用ＯＩが存在しない場合、
あるいはＯＩの切り替えにより各々の代用ＯＩの負荷
（代用ＯＩに処理の実行を要求するＯＩC 数）が大きく
なる場合は、新規に代用ＯＩを生成するようにＯＩＲに
要求する（図４(6) ）（ＳＡ１５）。
あるいはＯＩの切り替えにより各々の代用ＯＩの負荷
（代用ＯＩに処理の実行を要求するＯＩC 数）が大きく
なる場合は、新規に代用ＯＩを生成するようにＯＩＲに
要求する（図４(6) ）（ＳＡ１５）。
【００３５】（７）ＯＩC Ｌｉｓｔ中のすべてのＯＩに
対し、前記（５）までのステップで決定した代用ＯＩに
処理を依頼するように要求する（図４(7-1) ）（ＳＡ１
２，ＳＡ１６）。このとき、ＯＩC Ｌｉｓｔ中の各ＯＩ
に対し、その各々のＯＩが保持している情報のうち、そ
のＯＩのＯＩS として異常と申告されたＯＩの名前が登
録されている全ての箇所について、その名前を代用ＯＩ
の名前に変更するように要求する（ＯＩ切り替え処
理）。これにより、ＯＩC Ｌｉｓｔ中のＯＩは、全て異
常ＯＩの代わりに代用ＯＩに処理を依頼するようにな
る。
対し、前記（５）までのステップで決定した代用ＯＩに
処理を依頼するように要求する（図４(7-1) ）（ＳＡ１
２，ＳＡ１６）。このとき、ＯＩC Ｌｉｓｔ中の各ＯＩ
に対し、その各々のＯＩが保持している情報のうち、そ
のＯＩのＯＩS として異常と申告されたＯＩの名前が登
録されている全ての箇所について、その名前を代用ＯＩ
の名前に変更するように要求する（ＯＩ切り替え処
理）。これにより、ＯＩC Ｌｉｓｔ中のＯＩは、全て異
常ＯＩの代わりに代用ＯＩに処理を依頼するようにな
る。
【００３６】要求先ＯＩから了承の返答をうけると、Ｇ
ＯＭはさらに、代用ＯＩが異常となった際にＯＩ切り替
え処理が実行できるように、ＯＩＤＢ内の代用ＯＩのＯ
ＩCＬｉｓｔの項目に、新たに代用ＯＩのクライアント
となったＯＩ名を追加するようにＯＩＤＢに対して要求
する（図４(7-2) ）。
ＯＭはさらに、代用ＯＩが異常となった際にＯＩ切り替
え処理が実行できるように、ＯＩＤＢ内の代用ＯＩのＯ
ＩCＬｉｓｔの項目に、新たに代用ＯＩのクライアント
となったＯＩ名を追加するようにＯＩＤＢに対して要求
する（図４(7-2) ）。
【００３７】（８）前記（２）の時点で、切り替え処理
後に異常と申告されたＯＩを消去するように指定された
場合は、この時点で異常と申告されたＯＩの消去の実行
をＯＩＲに要求する（図４(8-1) ）。ＯＩＲは異常と申
告されたＯＩを消去した後にＯＩＤＢ内の異常と申告さ
れたＯＩに関する情報を消去するように要求する（図４
(8-2) ）（ＳＡ１４，ＳＡ１８）。
後に異常と申告されたＯＩを消去するように指定された
場合は、この時点で異常と申告されたＯＩの消去の実行
をＯＩＲに要求する（図４(8-1) ）。ＯＩＲは異常と申
告されたＯＩを消去した後にＯＩＤＢ内の異常と申告さ
れたＯＩに関する情報を消去するように要求する（図４
(8-2) ）（ＳＡ１４，ＳＡ１８）。
【００３８】＜ＯＩがＯＩS の異常を検出したとき＞次
に、ＯＩがＯＩS の異常を検出したときの障害復旧の手
順を図７乃至図９に基づいて説明する。なお、このとき
ＯＩからＧＯＭへはＯＩS の異常という内容の通知が届
く（図７(0) ）（ＳＢ１）が、このとき、後述するよう
にＧＯＭはＯＩS だけでなく同時に通信処理の異常も同
時にチェックする。このケースでは、ＧＯＭは以下の手
続きを実行する。
に、ＯＩがＯＩS の異常を検出したときの障害復旧の手
順を図７乃至図９に基づいて説明する。なお、このとき
ＯＩからＧＯＭへはＯＩS の異常という内容の通知が届
く（図７(0) ）（ＳＢ１）が、このとき、後述するよう
にＧＯＭはＯＩS だけでなく同時に通信処理の異常も同
時にチェックする。このケースでは、ＧＯＭは以下の手
続きを実行する。
【００３９】（１）ＯＩＤＢが保持する情報のうち、異
常と申告されたＯＩS に関する使用可／不可の項目を
「不可」に変更するように要求する（図７(1) ）（ＳＢ
２）。これにより、そのＯＩがＧＯＭにより他のＯＩの
代用として割り当てられたり、ＤＢＦによりそのＯＩに
処理要求が受け渡されることがなくなる。
常と申告されたＯＩS に関する使用可／不可の項目を
「不可」に変更するように要求する（図７(1) ）（ＳＢ
２）。これにより、そのＯＩがＧＯＭにより他のＯＩの
代用として割り当てられたり、ＤＢＦによりそのＯＩに
処理要求が受け渡されることがなくなる。
【００４０】（２）ＯＩＤＢに対し、異常と申告された
ＯＩS をＯＩS として用いる全てのＯＩ名のリスト（Ｏ
ＩC Ｌｉｓｔ）を要求する（図７(2) ）（ＳＢ３）。
ＯＩS をＯＩS として用いる全てのＯＩ名のリスト（Ｏ
ＩC Ｌｉｓｔ）を要求する（図７(2) ）（ＳＢ３）。
【００４１】（３）ＯＩC Ｌｉｓｔ中のすべてのＯＩに
対し、異常と申告されたＯＩS に対する直後の処理依頼
を全て停止し、以後指示があるまで、ＤＢＦを通して処
理をＯＩS に依頼するように指示する（図７(3-1) ）
（ＳＢ４）。
対し、異常と申告されたＯＩS に対する直後の処理依頼
を全て停止し、以後指示があるまで、ＤＢＦを通して処
理をＯＩS に依頼するように指示する（図７(3-1) ）
（ＳＢ４）。
【００４２】ＤＢＦは、代用ＯＩS 名を処理要求元にも
知らせる。以後、処理要求元のＯＩが同一の内容の処理
を依頼するときは、後に正式な代用ＯＩS の名前をＧＯ
Ｍまら知らされるまで、ＤＢＦから指定された仮の代用
ＯＩS を一時的に用いる（図７(3-2) ）。
知らせる。以後、処理要求元のＯＩが同一の内容の処理
を依頼するときは、後に正式な代用ＯＩS の名前をＧＯ
Ｍまら知らされるまで、ＤＢＦから指定された仮の代用
ＯＩS を一時的に用いる（図７(3-2) ）。
【００４３】（４）この時点では、通知された異常が、
ＯＩS の異常によるものか、あるいは処理の要求時／応
答時の通信機能の障害によるものかが判別できない。そ
こでＧＯＭは、異常と申告されたＯＩS に対して、自身
の試験を要求する（図７(4)）（ＳＢ５）。その返答の
内容（試験結果）により、以下のような手続きが実行さ
れる。
ＯＩS の異常によるものか、あるいは処理の要求時／応
答時の通信機能の障害によるものかが判別できない。そ
こでＧＯＭは、異常と申告されたＯＩS に対して、自身
の試験を要求する（図７(4)）（ＳＢ５）。その返答の
内容（試験結果）により、以下のような手続きが実行さ
れる。
【００４４】（Ａ）応答の内容が「正常」のとき 異常と申告されたＯＩS に対し、異常を申告したＯＩが
ＯＩS に依頼した処理を実行中であるかを問い合わせる
（図７(4-1-1) ）（ＳＢ８）。
ＯＩS に依頼した処理を実行中であるかを問い合わせる
（図７(4-1-1) ）（ＳＢ８）。
【００４５】（ａ）応答が「実行中」のとき ＧＯＭは、異常と申告されたＯＩS がさらに他のＯＩ
（ＯＩSS）に処理を依頼しているかを異常と申告された
ＯＩS に問い合わせる（図７(4-1-2) ）（ＳＢ９）。そ
の応答内容に対応して、以下の手順を実行する。
（ＯＩSS）に処理を依頼しているかを異常と申告された
ＯＩS に問い合わせる（図７(4-1-2) ）（ＳＢ９）。そ
の応答内容に対応して、以下の手順を実行する。
【００４６】・異常と申告されたＯＩS が他のＯＩ（Ｏ
ＩSS）に処理を依頼しているとき ＯＩSSの正常性を確認する（ＳＢ１１）。ＯＩSSが異常
であれば、そのＯＩSS及びＯＩS のＯＩSSに対する異常
検出機能が異常を来しているものとみなし、ＯＩS とＯ
ＩSS双方の切り替え処理を実行する（図７(4-1-3) ）
（切り替え時に、それまで仮に割り当てられていたＯＩ
S は、正規の代用ＯＩS に切り替えられる（図７(4-1-
4) ）（ＳＢ１３）。切り替え処理の手順は前の実施例
の場合と同じであるため説明を省略する）。
ＩSS）に処理を依頼しているとき ＯＩSSの正常性を確認する（ＳＢ１１）。ＯＩSSが異常
であれば、そのＯＩSS及びＯＩS のＯＩSSに対する異常
検出機能が異常を来しているものとみなし、ＯＩS とＯ
ＩSS双方の切り替え処理を実行する（図７(4-1-3) ）
（切り替え時に、それまで仮に割り当てられていたＯＩ
S は、正規の代用ＯＩS に切り替えられる（図７(4-1-
4) ）（ＳＢ１３）。切り替え処理の手順は前の実施例
の場合と同じであるため説明を省略する）。
【００４７】また、ＯＩSSが正常であれば、以降繰り返
しＯＩSSが依頼している処理について調べ、その結果、
最終的に異常を来しているＯＩが判明した時点で、その
ＯＩとそのＯＩのＯＩC の切り替え処理を実行する（Ｓ
Ｂ１２）。
しＯＩSSが依頼している処理について調べ、その結果、
最終的に異常を来しているＯＩが判明した時点で、その
ＯＩとそのＯＩのＯＩC の切り替え処理を実行する（Ｓ
Ｂ１２）。
【００４８】・異常と申告されたＯＩS が他のＯＩ（Ｏ
ＩSS) に処理を依頼していないとき 試験では検出できない異常がＯＩS に発生しているとみ
なし、異常と申告されたＯＩS の切り替え処理を実行す
る（図７(4-1-5) ）（ＳＢ１０）。
ＩSS) に処理を依頼していないとき 試験では検出できない異常がＯＩS に発生しているとみ
なし、異常と申告されたＯＩS の切り替え処理を実行す
る（図７(4-1-5) ）（ＳＢ１０）。
【００４９】（ｂ）応答が「非実行中」のとき 各ノードに配備（信頼性向上のために複数個設けてもよ
い）されているＰＬＭに、異常を申告したＯＩが異常Ｏ
ＩS に依頼した処理が登録されているかを問い合わせる
（図７(4-1-6) ）（ＳＢ１４）。
い）されているＰＬＭに、異常を申告したＯＩが異常Ｏ
ＩS に依頼した処理が登録されているかを問い合わせる
（図７(4-1-6) ）（ＳＢ１４）。
【００５０】各ＯＩ（ＯＩS ）は、自身に依頼された処
理を終了する際に、同一ノード内に存在するＰＬＭに処
理名、該ＯＩ名、ＯＩC 名、処理終了時間を登録してい
る（図７(4-1-7) ）。
理を終了する際に、同一ノード内に存在するＰＬＭに処
理名、該ＯＩ名、ＯＩC 名、処理終了時間を登録してい
る（図７(4-1-7) ）。
【００５１】従って、問い合わせ時にＰＬＭに異常と申
告されたＯＩS が実行した処理名が登録されていれば、
該処理は既に終了しているため、応答時に（ＯＩS と異
常申告したＯＩとの間の）通信処理障害が起きたものと
みなし、通信処理管理部に障害復旧を依頼する（図７(4
-1-8) ）（ＳＢ１５）。
告されたＯＩS が実行した処理名が登録されていれば、
該処理は既に終了しているため、応答時に（ＯＩS と異
常申告したＯＩとの間の）通信処理障害が起きたものと
みなし、通信処理管理部に障害復旧を依頼する（図７(4
-1-8) ）（ＳＢ１５）。
【００５２】また、問い合わせ時にＰＬＭに異常と申告
されたＯＩS が実行した処理名が登録されていなけれ
ば、該処理の依頼が異常と申告されたＯＩS に届いてい
ないため、処理要求時に（異常申告したＯＩとＯＩS と
の間の）通信処理障害が起きたものとみなし、通信処理
管理部に障害復旧を依頼する（図７(4-1-9) ）（ＳＢ１
６）。
されたＯＩS が実行した処理名が登録されていなけれ
ば、該処理の依頼が異常と申告されたＯＩS に届いてい
ないため、処理要求時に（異常申告したＯＩとＯＩS と
の間の）通信処理障害が起きたものとみなし、通信処理
管理部に障害復旧を依頼する（図７(4-1-9) ）（ＳＢ１
６）。
【００５３】なお、サービス障害の原因が通信処理障害
と判定されたときは、ＧＯＭは、それまで仮の代用ＯＩ
S を用いていたＯＩC Ｌｉｓｔ中の各ＯＩに対し、それ
以後、当初用いられていたＯＩS を用いるようにＯＩの
切り戻し処理を実行する。
と判定されたときは、ＧＯＭは、それまで仮の代用ＯＩ
S を用いていたＯＩC Ｌｉｓｔ中の各ＯＩに対し、それ
以後、当初用いられていたＯＩS を用いるようにＯＩの
切り戻し処理を実行する。
【００５４】（２）応答の内容が「異常」、あるいは応
答がないとき その異常と申告されたＯＩS の切り替え処理を実行する
（切り替え処理手続きは前ケースの内容と同じであるた
め説明を省略する）（ＳＢ７）。
答がないとき その異常と申告されたＯＩS の切り替え処理を実行する
（切り替え処理手続きは前ケースの内容と同じであるた
め説明を省略する）（ＳＢ７）。
【００５５】以上の手続きにより、異常の検出及び復旧
が行なわれる。
が行なわれる。
【００５６】前述したように、通信網のノード上に分散
配備されているＯＩが互いにメッセージを交信すること
によりサービスが提供される環境において、ＯＩから異
常の通知を受けたときに代用ＯＩへの切り替え処理を行
なう機能、及び各ＯＩの運用情報を調べる機能を保持す
るＧＯＭを設けることにより、ＯＩの異常を未然に防ぐ
ようなＯＩ間の負荷のバランス調整やＯＩ異常時のＯＩ
単位での切り替え処理を実現できるため、従来の方法よ
り確実にサービス全体の継続的な提供を確保することが
できる。
配備されているＯＩが互いにメッセージを交信すること
によりサービスが提供される環境において、ＯＩから異
常の通知を受けたときに代用ＯＩへの切り替え処理を行
なう機能、及び各ＯＩの運用情報を調べる機能を保持す
るＧＯＭを設けることにより、ＯＩの異常を未然に防ぐ
ようなＯＩ間の負荷のバランス調整やＯＩ異常時のＯＩ
単位での切り替え処理を実現できるため、従来の方法よ
り確実にサービス全体の継続的な提供を確保することが
できる。
【００５７】また、ＧＯＭに各ＯＩを定期的に試験する
ことを要求する機能を設けることで、各々のＯＩの試験
機能の正常性が確保でき、従ってＯＩの障害発生時の確
実な障害復旧を実現できる。
ことを要求する機能を設けることで、各々のＯＩの試験
機能の正常性が確保でき、従ってＯＩの障害発生時の確
実な障害復旧を実現できる。
【００５８】
【発明の効果】以上説明したように本発明の請求項１に
よれば、通信網のノード上に分散配備されているＯＩが
互いにメッセージを交信することによりサービスが提供
される環境において、ＯＩから異常の通知を受けたとき
に代用ＯＩへの切り替え処理を行なうことにより、ＯＩ
の異常を未然に防ぐようなＯＩ間の負荷のバランス調整
やＯＩ異常時のＯＩ単位での切り替え処理を実現できる
ため、従来の方法より確実にサービス全体の継続的な提
供を確保することができる。
よれば、通信網のノード上に分散配備されているＯＩが
互いにメッセージを交信することによりサービスが提供
される環境において、ＯＩから異常の通知を受けたとき
に代用ＯＩへの切り替え処理を行なうことにより、ＯＩ
の異常を未然に防ぐようなＯＩ間の負荷のバランス調整
やＯＩ異常時のＯＩ単位での切り替え処理を実現できる
ため、従来の方法より確実にサービス全体の継続的な提
供を確保することができる。
【００５９】また、請求項２によれば、上記の効果に加
えて、ＧＯＭに各ＯＩを定期的に試験することを要求す
る機能を設けているので、各々のＯＩの試験機能の正常
性が確保でき、従ってＯＩの障害発生時の確実な障害復
旧を実現できる。
えて、ＧＯＭに各ＯＩを定期的に試験することを要求す
る機能を設けているので、各々のＯＩの試験機能の正常
性が確保でき、従ってＯＩの障害発生時の確実な障害復
旧を実現できる。
【図１】本発明の一実施例の構成を説明する図
【図２】従来のサービス実行制御装置の監視によるサー
ビス障害復旧方法を説明する図
ビス障害復旧方法を説明する図
【図３】本発明の一実施例におけるＯＩＤＢが保持する
情報を説明する図
情報を説明する図
【図４】本発明の一実施例におけるＯＩが自身の障害を
検出したときの障害復旧手順を説明する図
検出したときの障害復旧手順を説明する図
【図５】本発明の一実施例におけるＯＩが自身の障害を
検出した場合のＧＯＭを用いた障害復旧処理手順を示す
フローチャート
検出した場合のＧＯＭを用いた障害復旧処理手順を示す
フローチャート
【図６】本発明の一実施例におけるＯＩが自身の障害を
検出した場合のＧＯＭを用いた障害復旧処理手順を示す
フローチャート
検出した場合のＧＯＭを用いた障害復旧処理手順を示す
フローチャート
【図７】本発明の一実施例におけるＯＩがＯＩS の障害
を検出したときの障害復旧手順を説明する図
を検出したときの障害復旧手順を説明する図
【図８】本発明の一実施例におけるＯＩがＯＩS の障害
を検出した場合のＧＯＭを用いた障害復旧処理手順を示
すフローチャート
を検出した場合のＧＯＭを用いた障害復旧処理手順を示
すフローチャート
【図９】本発明の一実施例におけるＯＩがＯＩS の障害
を検出した場合のＧＯＭを用いた障害復旧処理手順を示
すフローチャート
を検出した場合のＧＯＭを用いた障害復旧処理手順を示
すフローチャート
１…サービス処理ノード、２ａ…サービス実行制御装置
（主系）、２ｂ…サービス実行制御装置（予備系）、３
…監視装置、４…通信網管理ノード、５…通信網管理シ
ステム、６…サービス処理ノード、７ａ…サービス実行
制御装置（主系）、７ｂ…サービス実行制御装置（予備
系）、８…監視装置、ＯＩ…オブジェクトインスタン
ス、ＧＯＭ…総合オブジェクトマネージャ、ＯＩＲ…Ｏ
Ｉ生成／消去マネージャ、ＰＬＭ…処理ログマネージ
ャ、ＯＩＤＢ…ＯＩデータベース、。
（主系）、２ｂ…サービス実行制御装置（予備系）、３
…監視装置、４…通信網管理ノード、５…通信網管理シ
ステム、６…サービス処理ノード、７ａ…サービス実行
制御装置（主系）、７ｂ…サービス実行制御装置（予備
系）、８…監視装置、ＯＩ…オブジェクトインスタン
ス、ＧＯＭ…総合オブジェクトマネージャ、ＯＩＲ…Ｏ
Ｉ生成／消去マネージャ、ＰＬＭ…処理ログマネージ
ャ、ＯＩＤＢ…ＯＩデータベース、。
フロントページの続き (56)参考文献 特開 平５−46572（ＪＰ，Ａ) Ｃｏａｎ，Ｂ．Ａ．，Ｈｉｃｋｅｙ, Ｔ．Ｍ．，Ｒｅｓｏｕｒｃｅ Ｒｅｃｏ ｖｅｒｙ ｉｎ ａ Ｄｉｓｔｒｉｂｕ ｔｅｄ Ｐｒｏｃｅｓｓｉｎｇ Ｅｎｖ ｉｒｏｎｍｅｎｔ，Ｐｒｏｃ．ｏｆ Ｇ ＬＯＢＥＣＯＭ ’92，ｐ．604−609 島田、横山、齋藤，オブジェクト指向 分散処理環境ｎＯＲの開発，電気学会研 究会資料，社団法人電気学会，1994年 ２月16日，ＩＰ−94，Ｐ．11−19 (58)調査した分野(Int.Cl.7，ＤＢ名) G06F 13/00 G06F 15/16 - 15/177 H04L 12/24
Claims (2)
- 【請求項１】 自己試験機能を有する全てのオブジェク
トインスタンス（ＯＩ）を管理する総合オブジェクトマ
ネージャ（ＧＯＭ）と、ＯＩ間の通信処理を管理する通
信処理管理部とを備え、互いに独立して動作するＯＩ
が、メッセージを交信し合い、依頼された処理の一部を
必要に応じてサーバＯＩに依頼して、ＯＩ群全体として
所望の処理機能を実現するオブジェクト指向ソフトウェ
アを用いて、計算／通信サービスを実現するサービス処
理装置におけるサービス障害復旧方法において、各ＯＩは、自分自身及び自分自身が処理を依頼している
サーバＯＩ並びに通信処理機能のそれぞれの異常を検出
したときに前記ＧＯＭに通知し、 前記ＧＯＭは、 ＯＩから自己の異常発生の申告通知を受けたときに、前
記通知された異常の内容に基づいて、該申告したＯＩを
消去するか或いはそのまま動作させるかを決定し、前記
申告したＯＩを消去するときは、負荷バランスが偏らな
いように代用ＯＩを 他のＯＩの中から選択するか又は新
規に作成し、ＯＩから該ＯＩが使用しているサーバＯＩ（ＯＩ S ）の
異常発生を申告する通知を受けたときに、該申告された
サーバＯＩ（ＯＩ S ）と該申告されたサーバＯＩ（ＯＩ
S ）が依頼された処理を行う他のサーバＯＩ（ＯＩ SS ）
に対して順次正常性の確認処理を行い、異常を来してい
るＯＩ及び異常を来しているＯＩ間通信処理機能を特定
して、異常を来しているＯＩを代用ＯＩに切り替える処
理を実行し、通信処理障害の復旧を前記通信処理管理部
に依頼し、 以後、異常を来したＯＩの代わりに前記代用ＯＩを前記
サービスで用い、サービスを継続的に提供させることを
特徴とするサービス障害復旧方法。 - 【請求項２】 前記ＧＯＭは各ＯＩに対して定期的に試
験を要求することによりＯＩの動作異常を検出すること
を特徴とする請求項１記載のサービス障害復旧方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20757194A JP3291931B2 (ja) | 1994-08-31 | 1994-08-31 | サービス障害復旧方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP20757194A JP3291931B2 (ja) | 1994-08-31 | 1994-08-31 | サービス障害復旧方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH0877120A JPH0877120A (ja) | 1996-03-22 |
| JP3291931B2 true JP3291931B2 (ja) | 2002-06-17 |
Family
ID=16541963
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP20757194A Expired - Fee Related JP3291931B2 (ja) | 1994-08-31 | 1994-08-31 | サービス障害復旧方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3291931B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7647523B2 (en) | 2002-06-12 | 2010-01-12 | International Business Machines Corporation | Dynamic binding and fail-over of comparable web service instances in a services grid |
| JP4876438B2 (ja) | 2005-05-31 | 2012-02-15 | 株式会社日立製作所 | コンポーネントソフトウェアの運用方法および運用基盤 |
-
1994
- 1994-08-31 JP JP20757194A patent/JP3291931B2/ja not_active Expired - Fee Related
Non-Patent Citations (2)
| Title |
|---|
| Ｃｏａｎ，Ｂ．Ａ．，Ｈｉｃｋｅｙ，Ｔ．Ｍ．，Ｒｅｓｏｕｒｃｅ Ｒｅｃｏｖｅｒｙ ｉｎ ａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｐｒｏｃｅｓｓｉｎｇ Ｅｎｖｉｒｏｎｍｅｎｔ，Ｐｒｏｃ．ｏｆ ＧＬＯＢＥＣＯＭ ’９２，ｐ．６０４−６０９ |
| 島田、横山、齋藤，オブジェクト指向分散処理環境ｎＯＲの開発，電気学会研究会資料，社団法人電気学会，１９９４年 ２月１６日，ＩＰ−９４，Ｐ．１１−１９ |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH0877120A (ja) | 1996-03-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4215384B2 (ja) | 分散コンピューティング環境で複数の関係する障害を表す障害情報を参照する技法 | |
| KR100734818B1 (ko) | 컴퓨팅 서비스 그리드 | |
| US7114094B2 (en) | Information processing system for judging if backup at secondary site is necessary upon failover | |
| JP3345626B2 (ja) | マルチプロセッサシステムにおけるプロセッサ異常対策装置およびマルチプロセッサシステムにおけるプロセッサ異常対策方法 | |
| US8661297B2 (en) | System monitoring | |
| US7941810B2 (en) | Extensible and flexible firmware architecture for reliability, availability, serviceability features | |
| WO2004031979A2 (en) | Method of solving a split-brain condition | |
| US8347142B2 (en) | Non-disruptive I/O adapter diagnostic testing | |
| US7370101B1 (en) | Automated testing of cluster data services | |
| JPH07334436A (ja) | ソフトウエア自動配布方式 | |
| JP3872412B2 (ja) | 総合サービス管理システム及び方法 | |
| JP3291931B2 (ja) | サービス障害復旧方法 | |
| AU2001241700B2 (en) | Multiple network fault tolerance via redundant network control | |
| CN114153668A (zh) | 自动化测试方法、装置、电子设备及存储介质 | |
| US20100251029A1 (en) | Implementing self-optimizing ipl diagnostic mode | |
| JP4102592B2 (ja) | 集約機能付障害情報通知システム及びマシンを集約機能付障害情報通知手段として機能させるためのプログラム | |
| US20070271486A1 (en) | Method and system to detect software faults | |
| EP1107118A2 (en) | Multiprocessor system and fault recovery method thereof | |
| JP3291930B2 (ja) | サービス処理機能監視方法及びその装置 | |
| CN111475320B (zh) | 一种计算平台的高可用性检测方法、计算平台及存储介质 | |
| CN114168390A (zh) | 一种基于重试机制的分布式一致性事务执行方法 | |
| US6601184B1 (en) | System crash network access | |
| CN112540771A (zh) | 自动化运维方法、系统、设备和计算机可读存储介质 | |
| JPH10171735A (ja) | ネットワークサービス管理方法 | |
| US8949403B1 (en) | Infrastructure for maintaining cognizance of available and unavailable software components |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090329 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |