JP4485763B2 - 運用管理方法及び装置 - Google Patents
運用管理方法及び装置 Download PDFInfo
- Publication number
- JP4485763B2 JP4485763B2 JP2003194994A JP2003194994A JP4485763B2 JP 4485763 B2 JP4485763 B2 JP 4485763B2 JP 2003194994 A JP2003194994 A JP 2003194994A JP 2003194994 A JP2003194994 A JP 2003194994A JP 4485763 B2 JP4485763 B2 JP 4485763B2
- Authority
- JP
- Japan
- Prior art keywords
- business
- importance
- management unit
- work
- event
- 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
- 238000007726 management method Methods 0.000 title claims description 150
- 238000011156 evaluation Methods 0.000 claims description 53
- 238000004364 calculation method Methods 0.000 claims description 19
- 238000012545 processing Methods 0.000 claims description 6
- 238000012544 monitoring process Methods 0.000 description 30
- 238000010586 diagram Methods 0.000 description 24
- 238000013523 data management Methods 0.000 description 12
- 238000000034 method Methods 0.000 description 9
- 230000004044 response Effects 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 5
- 238000007796 conventional method Methods 0.000 description 4
- 239000000725 suspension Substances 0.000 description 3
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0775—Content or structure details of the error report, e.g. specific table structure, specific error fields
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3017—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/324—Display of status information
- G06F11/327—Alarm or error message display
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Computer Hardware Design (AREA)
- Debugging And Monitoring (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Multi Processors (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、分散コンピュータシステムの運用管理方法及び装置に係り、特に、業務の重要度をシステムの運用管理に活用することを可能とした分散コンピュータシステムの運用管理技術に関する。
【０００２】
【従来の技術】
近年、インターネットの急速な普及やコンピュータの処理性能の飛躍的な向上等により、コンピュータやその周辺機器が企業等に大きく浸透し、多数の重要な業務がこれらコンピュータシステム上で行われるようになってきている。これに伴い、コンピュータシステム上で発生する障害は、企業の業務、ビジネスに大きな影響をもたらすものとなり、企業全体に散らばった分散コンピュータシステム（以下、分散システムという）を効率良く安全に運用することが企業にとって大きな関心事になっている。
【０００３】
従来、前述したような分散システムの管理は、一般に、統合システム運用管理（以下、運用管理という）製品を利用して行われている。この従来技術は、分散システム上に配置された業務サーバ等の監視対象に対して、エージェントと呼ばれる監視ソフトウェアを配備し、このエージェントを通じて障害や異常発生の情報（以下、イベントという）を中央のイベント監視コンソールに表示して監視するようにしたものである。
【０００４】
図１０は従来技術によるイベント監視コンソールの表示画面の表示例を説明する図、図１１は従来技術によるイベント毎の重要度の算出基準の定義について説明する図である。
【０００５】
従来技術によるイベント監視コンソールには、図１０に示すような情報が表示される。ここで表示される情報は、イベントの発生毎に、障害の重要度１０００、障害の発生時刻１００１、イベントメッセージ１００２を組としたレコードにより構成される。障害の重要度１０００は、イベントである障害の重要度を表す指標、発生時刻１００１は、イベントが発生した時刻、イベントメッセージ１００２は、イベントの内容をそれぞれ示している。例えば、図１０の２行目のレコードは、サーバ０８のメモリ使用率が９５％を超えたというイベント１０２２が２００３年１月１７日の１０時２６分に発生（１０２１）し、その障害の重要度が“緊急”（１０２０）であることを示している。
【０００６】
障害の重要度１０００は、通常、“注意”、“警告”、“緊急”等の多段階に分けられており、図１１に示すようにイベント毎に予め定義されている。ここに示している定義例は、イベント項目１１００、注意１１０１、警告１１０２、緊急１１０３からなり、イベント項目１１００には、ＣＰＵ使用率、メモリ使用率、ディスク使用率、サーバ、アプリケーション等の項目があり、これらの各項目の状態に対して、注意１１０１、警告１１０２、緊急１１０３の障害の重要度が定義されている。例えば、イベント項目のディスク使用率１１３０を見ると、ディスク使用率が７５％を超えたら“注意”、８５％を超えたら“警告”、９０％を超えたら“緊急”のように定義されている。これらは、言い換えれば個々のシステムリソースにおける障害の重大度を表すものであり、運用管理者が監視対象の状態を把握するための指標として利用される。前述した図１０に示すような表示を行うタイプのイベント監視コンソールを「基本タイプ」と定義することとする。
【０００７】
しかし、前述したような「基本タイプ」により表示される障害の重要度は、分散システムの管理という視点で運用管理者が分散システムを管理しやすいように定義したものであり、企業にとっての重要業務への影響を示唆するものではない。従って、複数の障害が同時に発生した場合、前述のように表示される重要度に基づいて管理者が障害に対処したとしても、業務上の損失を最小限に抑えることにはならない恐れがある。
【０００８】
また、近年、分散システムの運用管理にビジネスの視点を取り入れようとする試みがある。この分散システムの運用管理は、分散システム上で実施している業務と、それを構成するサーバ、ストレージ機器、ネットワーク機器、業務アプリケーション、データベース等のコンピュータ機器（以下、リソース）との関係を予め定義しておき、あるリソースに障害が発生した場合、その障害がどの業務に影響を及ぼす可能性があるかをイベント監視コンソールに表示するというものである。
【０００９】
図１２は前述したような従来技術による業務とリソースとの関係を定義した例を説明する図、図１３はリソースの障害がどの業務に影響を及ぼすかをイベント監視コンソールに表示した例を説明する図である。
【００１０】
図１２に示す業務とリソースとの関係を定義した例は、業務Ａ１２００が、サーバ１２０１、１２０２、データベースＡ１２０３、ストレージ１２０４、１２０５、アプリケーション１２０６〜１２０８、ルータ１２０９、１２１０等の合計１０個のリソースによって構成されているシステムにより実行されることを表している。このような定義は、業務毎に行われて備えられている。また、図１３に示す表示例は、図１２に示すリソースの障害がどの業務に影響を及ぼす可能性があるかを表示しており、図示例では、アプリケーションＢ１２０７に障害が発生した場合に、このアプリケーションを構成要素として持つ業務Ａ１２００、業務Ｂ１３００、業務Ｃ１３１０に支障を来たす恐れがあることを示している。前述した図１３に示すような表示を行うタイプのイベント監視コンソールを「障害影響表示タイプ」と定義することとする。
【００１１】
図１３に示す「障害影響表示タイプ」の例は、「基本タイプ」をよりビジネスに近い観点で捉えたものであり、あるリソースにおける障害がどの業務に影響を及ぼすかを把握することは可能であるが、どの業務が企業にとって重要であるかまでは把握することはできない。通常、運用管理者は、分散システム上で行われている個々の業務の重要性までは精通していない。従って、運用管理者は、前記したような「障害影響表示タイプ」のイベント監視コンソールを使用したとしても、複数の障害が同時に発生した場合に、影響の及ぶ可能性のある業務を調べた上で、現在、どの業務が重要であるのかを経営者や各業務の担当者に確認しなければ、障害対処の優先順位を自ら決定することができない。その結果、障害対処に余計な時間を浪費し、ビジネス上の損失を拡大してしまうことになる。
【００１２】
なお、分散システムの利用者から見た業務の重要度への取り組みに関する従来技術として、例えば、特許文献１等に記載された技術が知られている。この従来技術は、システムの運用保守という発想で、業務を構成する構成要素の将来的な動向を予測し、障害発生前にメモリやディスクの増設をする等の対策を打つことを目的としており、分散システム上で今、実際に発生している障害に対する対処を行うという点について考慮されていないものである。
【００１３】
また、他の従来技術として、例えば、特許文献２等に記載された技術が知られている。この従来技術は、時々刻々、大量に発生するイベントに対し、その重要度や内容に応じて自動的に分類・ランク付けを行い発生した障害への対処時間の短縮を試みるというものである。しかし、この従来技術は、考慮される重要度が前述したシステムリソースの障害の重大度を表す重要度であって、その障害によって影響を受ける可能性のある業務がどれであるか、また、その業務の持つ意味やその業務の停止が企業のビジネスへもたらす影響の度合いを考慮したものではない。
【００１４】
【特許文献１】
特開平１０−８３３８２号公報
【００１５】
【特許文献２】
特開平１０−６３５３９号公報
【００１６】
【発明が解決しようとする課題】
前述したように、従来の分散システムに対する運用管理の技術は、そのシステム上で実現されているどの業務がどれほど重要であるかという業務そのものの重要性を考慮して障害対処の優先順位を示唆するまでには至っていない。
【００１７】
このため、従来技術による分散システムの運用管理技術は、複数の障害が発生した場合、図１０により説明したようなイベント監視コンソールが提供する重要度に従って、重要とされるものから順に対処しても、この重要度がビジネス上の重要性を考慮したものではないため、ビジネス上の損失を最小限に抑えることができないという問題点を有している。
【００１８】
本発明の目的は、前述した従来技術の問題点を解決し、どの障害がどの業務に影響を及ぼすかという影響範囲を特定するだけでなく、その業務がどの程度重要な業務であるかをリアルタイムに運用管理者に提示し、熟練しかつビジネスへの理解度の高い運用管理者でなくても、迅速に、かつ、ビジネス上の損失を最小限に抑えた分散システムの運用管理を行うことを可能にした分散システムの運用管理方法及び装置を提供することにある。
【００１９】
【課題を解決するための手段】
本発明によれば前記目的は、複数の業務サーバを有する分散コンピュータシステムの運用管理装置における運用管理方法において、前記運用管理装置は、前記システムのリソースの障害の発生時に、前記業務サーバの障害に関するイベント情報と障害に関するリソース情報とを前記業務サーバから受信し、前記受信したリソース情報と、予め保持している業務とその業務を構成するリソースとの関係から影響業務を特定し、前記特定された影響のある業務について、その業務が重要となる期間、業務の事業規模、信頼損失度を含む業務に対応した複数の評価項目から業務に関する重要度を算出するために、業務の種別毎に前記評価項目の種別が対応付けられ、業務毎にその業務の種別に対応する評価項目の値を記憶している記憶手段から前記影響のある業務に対応する業務種別の評価項目の値を取得し、複数の前記評価項目からなる業務に対応した複数種の重要度算出式のうち、前記取得した評価項目の値と前記業務に対応した重要度算出式とにより前記業務に関する重要度を算出し、前記業務に関する算出された重要度と、前記業務に対応する前記イベント情報とを表示することことにより達成される。
【００２０】
また、前記目的は、複数の業務サーバを有する分散コンピュータシステムの運用管理装置において、統合管理部と、業務とリソースとの関係を定義して管理する業務影響管理部と、業務の重要度を作成して管理する重要度管理部とを有し、前記統合管理部は、前記複数の業務サーバのそれぞれが有し自業務サーバを監視するエージェント部から障害の発生に伴うイベント情報とリソース情報とを受信し、受信したリソース情報を前記業務影響管理部に送信して、影響業務の照会を行い、前記業務影響管理部は、受信したリソース情報と、予め保持している業務とその業務を構成するリソースとの関係から影響業務を特定し、受信したリソースを構成要素に持つ業務名称のリストを、影響業務情報として前記統合管理部に返し、前記統合管理部は、前記業務影響管理部から受信した特定された影響業務について、その業務の重要度を、前記重要度管理部に問い合わせ、前記重要度管理部は、前記統合管理部からの前記問い合わせに対して、前記特定された影響のある業務について、その業務が重要となる期間、業務の事業規模、信頼損失度を含む業務に対応した複数の評価項目から業務に関する重要度を算出するために、業務の種別毎に前記評価項目の種別が対応付けられ、業務毎にその業務の種別に対応する評価項目の値を記憶している記憶手段から前記影響のある業務に対応する業務種別の評価項目の値を取得し、複数の前記評価項目からなる業務に対応した複数種の重要度算出式のうち、前記取得した評価項目の値と前記業務に対応した重要度算出式とにより前記業務に関する重要度を算出し、算出した業務の重要度データを前記統合管理部に返送し、前記統合管理部は、前記重要度管理部から受け取った業務の重要度と、該業務に対応する前記イベント情報とを表示することにより達成される。
【００２１】
【発明の実施の形態】
以下、本発明による分散システムの運用管理方法及び装置の実施形態を図面により詳細に説明する。
【００２２】
図１は本発明の一実施形態による分散システムの運用管理方法によりイベント監視コンソールに表示された表示画面の例を説明する図である。
【００２３】
なお、以下に説明する本発明の実施形態は、図１に示すようなイベントメッセージを表示するタイプのイベント監視コンソールを例としているが、本発明は、それ以外のタイプ、例えば、業務やリソースをアイコンによりツリー構造で表示し、システム全体の障害をＧＵＩ（Graphical User Interface）上で監視するタイプの監視コンソールであってもよい。
【００２４】
本発明の実施形態は、図１０により説明した従来技術によるイベント監視コンソール画面の代わりに、図１に示すような表示を提供することを可能にしたものであり、図１は、図１０に示している監視状態をそのまま用いて、本発明で提供する業務の重要度を付与したイベント監視コンソールでの表示例である。ここで表示される情報は、イベントの発生毎に、業務の重要度１００、イベントとしての障害の発生時刻１０１、発生したイベントの内容を示すイベントメッセージ１０２を組としたレコードにより構成される。業務の重要度１００は、Ａ、Ｂ、Ｃ、……等として表され、Ａ＞Ｂ＞Ｃ＞……のように重要度がランク付けされる。なお、この表示には、対応する障害により影響を受ける業務の名称を示していないが、必要に応じて障害の影響を受ける可能性のある業務の名称を併せて表示してもよい。
【００２５】
同一の内容を持つイベントについて、図１０に示しているものと図１に示しているものとを比較すると明らかなように、図１０の例で“緊急”１０２０と表示される「サーバ０８のメモリ使用率が９５％を超えた」というイベント１０２２は、図１に示す本発明の実施形態の場合、業務の重要度が“Ｃ”と評価されている。これは、イベント１０２２として発生した「サーバ０８」の障害は、リソースの障害としては重大な障害であっても、重要な業務には使われていないサーバの障害であることを意味している。従って、業務への影響を最小限に抑えるという観点から捉えれば、このイベント１０２２は、図１０に示すような緊急に対処すべき障害では必ずしもないものである。
【００２６】
同様に、図１０に示す“注意”１０３０のレベルでしかなかったイベント「アプリケーション０３のレスポンスの低下」１０３２は、業務への影響を考慮した図１に示す例では、“Ａ”ランクの極めて重要なイベントとして表示されている。このことは、イベント１０３２でレスポンスが低下していると通知された「アプリケーション０３」が重要な業務で使われており、リソースの障害としては重大な障害でなくても、業務への影響を考慮した場合には看過すことができない重要なイベントであることを示している。もし、分散システムを管理する運用管理者が、図１０に示すイベント監視コンソールが示す重要度に従って、“注意”と表示されたイベント１０３２ではなく“緊急”と表示されたイベント１０２２から対処した場合、ビジネス上の損失を拡大させることになり得る。
【００２７】
前述したように、本発明の実施形態による分散システムの運用管理方法によるイベント監視コンソールの表示は、従来技術によるイベント監視コンソールが示す情報からでは見抜くことができないビジネス上の重要な障害を、的確に運用管理者に提示することができる。これにより、運用管理者は、イベントメッセージと共に提供される業務の重要度を判断基準として障害に対処して行くことにより、障害による業務停止で発生する損失を最小限に抑えることが可能となる。
【００２８】
図２は本発明の一実施形態による分散システムの運用管理方法を適用した分散システムの構成を示すブロック図である。図２において、２００は統合管理部、２０１はイベント表示部、２０２はイベント管理部、２０３はイベントデータベース、２１０は業務影響管理部、２１１は関係定義部、２１２は業務定義データベース、２２０は重要度管理部、２２１は重要度データ管理部、２２２はルールテーブル管理部、２２３はテーブルデータ取得部、２２４は業務重要度データベース、２５０、２６０、２７０は業務サーバＡ〜Ｃ、２５１、２６１、２７１はエージェント部、２５２、２６２、２７２はデータベースである。
【００２９】
図２に示す分散システムは、統合管理部２００と、業務影響管理部２１０と、重要度管理部２２０と、監視対象であり業務を実行する複数の業務サーバによる業務サーバ群とが、図示しないネットワークを介して接続されて構成される。業務サーバ群は、業務サーバＡ２５０、業務サーバＢ２６０、業務サーバＣ２７０等の複数の業務サーバからなる。前述の業務サーバは、業務毎に１つのコンピュータ（計算機）が用いられてもよいし、複数の業務が１つのコンピュータ内に構成されてもよい。また、統合管理部２００、業務影響管理部２１０、重要度管理部２２０は、それぞれが１つのコンピュータ（計算機）内に構成されてもよいが、これらは、１つのコンピュータ内に構成されていてもよい。さらに、図２には示していないが、図示していないネットワークに各種の周辺機器が接続されていてもよい。
【００３０】
なお、前述した従来技術における「基本タイプ」のイベント監視コンソールは、業務サーバ群と統合管理部２００とにより構成され、「障害影響表示タイプ」のイベント監視コンソールは、「基本タイプ」の構成に業務影響管理部２１０を追加して構成されることになる。
【００３１】
監視対象となる業務サーバ群を構成する各業務サーバ２５０、２６０、２７０は、各業務サーバを監視するためのエージェント２５１、２６１、２７１が配置され、また、各業務サーバが作成したデータを格納するデータベース２５２、２６２、２７２を備えている。
【００３２】
統合管理部２００は、イベント表示部２０１、イベント管理部２０２、イベントデータベース２０３からなる。イベント表示部２０１は、イベント管理部２０２が保有する情報を図示しないイベント監視コンソールに表示する。イベント管理部２０２は、業務サーバ２５０、２６０、２７０等のエージェント部２５１、２６１、２７１から送信されるイベントを受信し、不要なイベントのフィルタリングや関連イベントを集約する等の必要な処理を実施すると共に、必要に応じて、イベントデータベース２０３に格納する。なお、イベント表示部２０１とイベント管理部２０２とは、別のコンピュータ上に構成し、ネットワークにより接続されていてもよい。
【００３３】
業務影響管理部２１０は、関係定義部２１１と業務定義データベース２１２とからなる。関係定義部２１１は、図１２に示して前述で説明したように、分散システム上で実施される業務とそれを構成するリソースとの関係を定義情報として管理し、業務定義データベース２１２に保管する。また、関係定義部２１１は、統合管理部２００のイベント管理部２０２からの問い合わせに対し、受信したイベントが発生したリソースを構成要素に持つ業務名称のリストをイベント管理部２０２へ返す役割を担う。
【００３４】
重要度管理部２２０は、業務影響管理部２１０で定義されている業務の重要度を作成し、管理する役割を持ち、重要度データ管理部２２１、ルールテーブル管理部２２２、テーブルデータ取得部２２３及び業務重要度データベース２２４から構成される。重要度データ管理部２２１は、統合管理部２００のイベント管理部２０２からの要求に対し、当該イベントにより影響を受ける可能性のある業務について、業務重要度データベース２２４を参照し、業務の重要度を提供する。なお、影響を受ける業務が複数ある場合、それぞれの業務の重要度を比較し、一番重要度の高いものをイベント管理部２０２へ返す。
【００３５】
また、重要度データ管理部２２１は、業務重要度データを作成し、業務重要度データベース２２４に格納する役割も担い、業務重要度が時間や日付等の要因によって変化する場合、所定の間隔で業務重要度データの更新を繰り返し実施し、業務重要度データベース２２４のデータを最新状態に保つ。ルールテーブル管理部２２２は、後述する業務重要度作成のためのルール及び評価式を管理し、実際に業務重要度を算出する役割を持つ。テーブルデータ取得部２２３は、ルールテーブル管理部２２２が業務重要度データを算出する際に、必要に応じて入力パラメータとなるデータを業務サーバ２５０、２６０、２７０などが保持するデータベース２５２、２６２、２７２等から取得する。
【００３６】
次に、重要度管理部２２０が業務重要度データを算出するプロセスについて具体的に説明する。
【００３７】
図３は業務重要度データベース２２４に格納されている業務重要度データの例を示す図、図４はルールテーブル定義表の構成を示す図、図５はルールテーブルの構成を示す図、図６は変数データの最新のものが格納されている場所を示す所在テーブルの構成を示す図、図７は業務の重要度を算出する定義式を示す図である。
【００３８】
業務重要度データベース２２４には、図３に示すような業務重要度データが格納されている。業務重要度データベース２２４は、業務名称３００と業務重要度３０１とにより構成される。業務名称３００は、分散システム上で実施される業務の名称を示し、具体的な項目として、「インターネット販売サイトＡ」３１０、「製品Ａ生産管理システム」３２５等が格納される。これらは、業務影響管理部２１０の業務定義データベース２１２で管理している業務名称と同一でなければならない。図３では、１０種の業務がある場合を例としているが、業務の数は幾つあってもよい。業務重要度３０１は、対応する業務の重要度を示し、Ａ、Ｂ、Ｃ、……等として表され、Ａ＞Ｂ＞Ｃ＞……のように重要度がランク付けされている。図３に示す例では、「インターネット販売サイトＡ」３１０の業務重要度は「Ａ」３１１となっており、重要な業務であることを意味している。
【００３９】
前述の業務重要度３０１は、以下に説明する手順で評価され、算出された結果を格納したものである。
【００４０】
業務重要度３０１の算出は、図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて行われる。図４に示すルールテーブル管理表は、図５に示す１つまたは複数存在するルールテーブルを管理するためのデータを保持するものである。図４において、業務名称４００は、業務の名称であり、テーブルＮｏ．４０１は、図５に示す複数のルールテーブルのうち該当する業務が含まれるルールテーブルの番号を示し、評価項目数４０２は、該当する業務の重要度を算出する上で必要な評価項目の数を規定している。例えば、「インターネット販売サイトＡ」３１０という業務は、「１」番目（４１１）のルールテーブルに規定されており、その評価項目が「３」つ（４１２）あることが表されている。
【００４１】
図５に示す各ルールテーブルは、各業務の重要度を決める上で必要な評価項目のリストとなっている。なお、ルールテーブルは、通常、全ての業務を同じ評価項目で規定できるわけではないため、同じ項目で規定することができる業務をグループとし、各業務グループ毎に設けられる。図５には、テーブル名称として、＜テーブル１＞４１１、＜テーブル２＞４２１、＜テーブル３＞４３１を持つ３つのテーブルを示している。
【００４２】
＜テーブル１＞４１１における業務名称５００は、テーブル１で規定される業務の名称を表す項目である。「月平均売上（円）＜Ｐ１１＞」５０１、「キャンペーン期間＜Ｐ１２＞」５０２、「期間中売上率（％）＜Ｐ１３＞」５０３は、テーブル１に含まれる業務の重要度を左右する項目名であり、Ｐ１１、Ｐ１２、Ｐ１３は、表中に与えられたデータを値とする業務重要度の変数である。業務名称「インターネット販売サイトＡ」３１０は、「月平均売上」５０１、「キャンペーン期間」５０２、「期間中売上率」５０３の３つの評価項目で重要度が規定され、その値は、それぞれ「50,000,000」５１１、「12/1〜12/24」５１２、「３０」５１３である。これらの値は、事前に分散システムのユーザから提供された値である。
【００４３】
また、＜テーブル２＞４２１に記述されるれる業務は、「在庫数（個）＜Ｐ２１＞」５４１、「最低在庫数（個）＜Ｐ２２＞」５４２の２つの項目で業務の重要度が規定される。業務名「製品Ａ生産管理システム」３２５は、「在庫数」５４１が 「var_1」５５１、「最低在庫数」５４２が「１０」５５２となっている。ここで、 「var_1」５５１は、固定値ではなく変数として与えられており、後述する図６で最新データの格納場所が提供されている。 「var_2」５６１、 「var_3」５７１も同様に変数として与えられている。このように、ルールテーブルは、変数の使用が認められており、該当項目が時間や日付で変化するような場合に使用することができる。
【００４４】
前述したようなルールテーブルで変数を使用する場合、図６に示すように最新データの格納場所を予め規定しておかなければならない。図６において、変数名６００は、図５に示すルールテーブルで用いられた変数の名称であり、データ所在６０１は、分散システム上にあるデータの格納場所をパス等により指定したものである。図６に示す例では、 「var_1」５５１の値が、「server_K\seisan\seihin_A.db」 ６１１というパスで指定される場所にあるデータベースに格納されていることを示している。
【００４５】
業務の重要度は、図７に示す定義式（１）〜（３）を使用して算出することができる。例えば、図５に示すテーブル１に含まれる業務についての業務の重要度Ｆ１は、図５に示すテーブル１の中のデータＰ１１、Ｐ１２、Ｐ１３から図７の式（１）より算出することができる。同様に、図５に示すテーブル２に含まれる業務の重要度Ｆ２は、データＰ２１、Ｐ２２と式（２）とから算出することができ、テーブル３に含まれる業務の重要度Ｆ３は、データＰ３１、Ｐ３２と式（３）とから算出することができる。図３に示した各業務の重要度は、図５において、日付が２月２０日（木）で、 var_1, var_2, var_3の値がそれぞれ13、18、30の場合を想定し、図７の評価式に適用して得られた結果である。
【００４６】
なお、図５に示すルールテーブル１、３に含まれる業務は、日付や曜日が業務の重要度の算出に関係するため、日付が変わる度に業務の重要度データの更新が必要であり、日付が変わる度に重要度の算出が行われる。
【００４７】
図８は前述した本発明の実施形態における業務サーバでのイベント発生から業務の重要度と共に発生したイベントを表示するまでの処理をシーケンスとして示した図であり、次に、これについて説明する。
【００４８】
（１）業務サーバ２５０、２６０、２７０のエージェント部２５１、２６１、２７１は、自業務サーバ内でリソース不足等のイベントが発生すると、そのイベントの情報と、リソースの情報とを統合管理部２００に送り、統合管理部２００のイベント管理部２０２がこれらの情報を受信する（シーケンス▲１▼）。
【００４９】
（２）統合管理部２００のイベント管理部２０２は、業務とリソースとの関係を管理している業務影響管理部２１０の関係定義部２１１にリソース情報を送信して影響業務の照会を行う（シーケンス▲２▼）。
【００５０】
（３）業務影響管理部２１０の関係定義部２１１は、シーケンス▲２▼での影響業務の照会に対して、受信したイベントが発生したリソースを構成要素に持つ業務名称のリストを、影響業務情報としてイベント管理部２０２へ返し、イベント管理部２０２がこの情報を受信する（シーケンス▲３▼）。
【００５１】
（４）統合管理部２００のイベント管理部２０２は、シーケンス▲３▼で受信した業務について、その業務の重要度を、重要度管理部２２０の重要度データ管理部２２１に問い合わせる（シーケンス▲４▼）。
【００５２】
（５）重要度管理部２２０の重要度データ管理部２２１は、シーケンス▲４▼での問い合わせに対して、業務の重要度データを統合管理部２００のイベント管理部２０２に返送し、統合管理部２００のイベント管理部２０２は、このデータを受信する（シーケンス▲５▼）。
【００５３】
（６）その後、統合管理部２００は、イベント表示部２０１に、シーケンス▲５▼で受信した業務の重要度と対応するイベントとを表示させる。
【００５４】
図９は重要度管理部２２０の重要度データ管理部２２１が業務重要度データベース２２４のデータを更新する処理を説明するフローチャートであり、次に、これについて説明する。
【００５５】
（１）重要度管理部２２０の重要度データ管理部２２１が、業務の重要度データの更新を開始する場合、まず、ルールテーブル管理部２２２が、重要度算出に使用するテーブルデータの更新を開始する（ステップ９０１、９０２）。
【００５６】
（２）テーブルデータ取得部２２３は、重要度を算出するために必要なルールテーブル内の変数データの所在情報を参照して指定の業務サーバのデータベースにアクセスする（ステップ９０３）。
【００５７】
（３）ステップ９０３のアクセスに対して、業務サーバのデータベースが変数のデータを応答として返してくるので、テーブルデータ取得部２２３は、その応答のデータを取得する（ステップ９０４、９０５）。
【００５８】
（４）ルールテーブル管理部２２２は、ステップ９０５で、テーブルデータ取得部２２３が取得した変数データを使用して、テーブルデータを更新する（ステップ９０６）。
【００５９】
（５）ルールテーブル管理部２２２は、更新されたテーブルデータを用いて業務重要度を算出する（ステップ９０７）。
【００６０】
（６）重要度データ管理部２２１は、ステップ９０７の処理でルールテーブル管理部２２２が算出した業務重要度データを、業務重要度データベースへ格納する（ステップ９０８、９０９）。
【００６１】
前述した本発明の実施形態における各処理は、処理プログラムとして構成することができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができる。
【００６２】
前述した本発明の実施形態は、図３に示す業務の重要度を図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて算出するものとして説明したが、業務の重要度が算出するまでもなく明白な場合や、ルールテーブルに変数データを含まず、かつ、業務重要度評価式において日時等の変数を含まない場合、本発明は、図３に示す各業務に対応するその業務の重要度を所定のデータとして保持することも可能である。
【００６３】
この場合、例えば、図３に示す業務「インターネット販売サイトＡ」３１０の重要度は算出するまでもなく「Ａ」３１１であるとしてしまってよく、業務重要度算出のプロセスを必要としない。図３で扱う全ての業務に対し、事前に業務重要度を提供することができる場合、図３を所定のデータとして保持し、イベント管理部２０２からの要求に応じて業務重要度を返すだけでよい。この場合、図２に示すルールテーブル管理部２２２とテーブルデータ取得部２２３とは不要である。
【００６４】
また、本発明は、図３に示す各業務の一部の重要度について図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて算出し、他の一部の業務に対応する、その業務の重要度を所定のデータとして保持することも可能である。
【００６５】
この場合、例えば、図５に示すルールテーブルにおいて、テーブル３（４３１）の重点期間５８１は、値に日付や曜日といった変数データを含んでいるため、テーブル３で規定される業務の重要度を所定のデータとして提供することができない。しかし、仮にテーブル３に含まれる業務が重点期間５８１に関係なく、信頼喪失度５８２だけで業務の重要度が決まるような業務であるならば、テーブル３で規定される４種類の業務については、その重要度を所定のデータとして提供することができることになる。このような場合、図３に示す業務「顧客向けＷｅｂサイト」３４０、「従業員向けＷｅｂサイト」３４５、「勤休管理システム」３５０、「給与計算システム」３５５については、その重要度を所定のデータとして図３に保持しておき、残りの６種類の業務の重要度が必要になった場合に、図４〜図７に示すテーブル及び評価式から重要度を算出するようにすればよい。
【００６６】
さらに、本発明は、前述で説明した図３に示す業務の重要度を図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて算出する本発明の実施形態による分散システムの運用管理方法を、サービス、例えば、分散システムの運用管理サービスを提供するサービスプロバイダに適用することができる。
【００６７】
そして、そのサービスの１つとして、業務重要度に基づいた障害への優先対処をユーザに対して約束し、業務の重要度の高い業務を実施しているユーザに対して、より多くの対価を要求する料金体系を採用するサービスがある。また、本発明を用いて、業務の重要度毎に要した障害対処時間を毎月レポートし、業務の重要度Ａの業務に関する一月当たりの障害対処時間を１時間以内とするなど、業務重要度をＳＬＡ（サービスレベルアグリーメント）の評価項目として利用するサービスを提供することもできる。
【００６８】
前述した本発明の実施形態によれば、従来のイベント監視コンソールが提示するシステム管理上の障害の重要度と異なり、その障害によって影響を受ける可能性のある業務がどれほど重要なものであるかを指標とする業務の重要度を提供することができ、これにより、運用管理者が、イベントメッセージと共に表示される業務重要度を判断基準として障害に対処して行くことができ、分散システムの障害による業務停止で発生する損失を最小限に抑えることが可能となる。
【００６９】
【発明の効果】
以上説明したように本発明によれば、分散システムにおける業務がどの程度重要な業務であるかを運用管理者に提示することにより、運用管理者は、それぞれのシステム障害による業務への影響を考慮した運用管理を実現できる。
【図面の簡単な説明】
【図１】本発明の一実施形態による分散システムの運用管理方法によりイベント監視コンソールに表示された表示画面の例を説明する図である。
【図２】本発明の一実施形態による分散システムの運用管理方法適用した分散システムの構成を示すブロック図である。
【図３】業務重要度データベースに格納されている業務重要度データの例を示す図である。
【図４】ルールテーブル定義表の構成を示す図である。
【図５】ルールテーブルの構成を示す図である。
【図６】変数データの最新のものが格納されている場所を示す所在テーブルの構成を示す図である。
【図７】業務の重要度を算出する定義式を示す図である。
【図８】本発明の実施形態における業務サーバでのイベント発生から業務の重要度と共に発生したイベントを表示するまでの処理をシーケンスとして示した図である。
【図９】重要度管理部の重要度データ管理部が業務重要度データベースのデータを更新する処理を説明するフローチャートである。
【図１０】従来技術によるイベント監視コンソールの表示画面の表示例を説明する図である。
【図１１】従来技術によるイベント毎の重要度の算出基準の定義について説明する図である。
【図１２】前述したような従来技術による業務とリソースとの関係を定義した例を説明する図である。
【図１３】リソースの障害がどの業務に影響を及ぼすかをイベント監視コンソールに表示した例を説明する図である。
【符号の説明】
２００ 統合管理部
２０１ イベント表示部
２０２ イベント管理部
２０３ イベントデータベース
２１０ 業務影響管理部
２１１ 関係定義部
２１２ 業務定義データベース
２２０ 重要度管理部
２２１ 重要度データ管理部
２２２ ルールテーブル管理部
２２３ テーブルデータ取得部
２２４ 業務重要度データベース
２５０、２６０、２７０ 業務サーバＡ〜Ｃ
２５１、２６１、２７１ エージェント部
２５２、２６２、２７２ データベース
【発明の属する技術分野】
本発明は、分散コンピュータシステムの運用管理方法及び装置に係り、特に、業務の重要度をシステムの運用管理に活用することを可能とした分散コンピュータシステムの運用管理技術に関する。
【０００２】
【従来の技術】
近年、インターネットの急速な普及やコンピュータの処理性能の飛躍的な向上等により、コンピュータやその周辺機器が企業等に大きく浸透し、多数の重要な業務がこれらコンピュータシステム上で行われるようになってきている。これに伴い、コンピュータシステム上で発生する障害は、企業の業務、ビジネスに大きな影響をもたらすものとなり、企業全体に散らばった分散コンピュータシステム（以下、分散システムという）を効率良く安全に運用することが企業にとって大きな関心事になっている。
【０００３】
従来、前述したような分散システムの管理は、一般に、統合システム運用管理（以下、運用管理という）製品を利用して行われている。この従来技術は、分散システム上に配置された業務サーバ等の監視対象に対して、エージェントと呼ばれる監視ソフトウェアを配備し、このエージェントを通じて障害や異常発生の情報（以下、イベントという）を中央のイベント監視コンソールに表示して監視するようにしたものである。
【０００４】
図１０は従来技術によるイベント監視コンソールの表示画面の表示例を説明する図、図１１は従来技術によるイベント毎の重要度の算出基準の定義について説明する図である。
【０００５】
従来技術によるイベント監視コンソールには、図１０に示すような情報が表示される。ここで表示される情報は、イベントの発生毎に、障害の重要度１０００、障害の発生時刻１００１、イベントメッセージ１００２を組としたレコードにより構成される。障害の重要度１０００は、イベントである障害の重要度を表す指標、発生時刻１００１は、イベントが発生した時刻、イベントメッセージ１００２は、イベントの内容をそれぞれ示している。例えば、図１０の２行目のレコードは、サーバ０８のメモリ使用率が９５％を超えたというイベント１０２２が２００３年１月１７日の１０時２６分に発生（１０２１）し、その障害の重要度が“緊急”（１０２０）であることを示している。
【０００６】
障害の重要度１０００は、通常、“注意”、“警告”、“緊急”等の多段階に分けられており、図１１に示すようにイベント毎に予め定義されている。ここに示している定義例は、イベント項目１１００、注意１１０１、警告１１０２、緊急１１０３からなり、イベント項目１１００には、ＣＰＵ使用率、メモリ使用率、ディスク使用率、サーバ、アプリケーション等の項目があり、これらの各項目の状態に対して、注意１１０１、警告１１０２、緊急１１０３の障害の重要度が定義されている。例えば、イベント項目のディスク使用率１１３０を見ると、ディスク使用率が７５％を超えたら“注意”、８５％を超えたら“警告”、９０％を超えたら“緊急”のように定義されている。これらは、言い換えれば個々のシステムリソースにおける障害の重大度を表すものであり、運用管理者が監視対象の状態を把握するための指標として利用される。前述した図１０に示すような表示を行うタイプのイベント監視コンソールを「基本タイプ」と定義することとする。
【０００７】
しかし、前述したような「基本タイプ」により表示される障害の重要度は、分散システムの管理という視点で運用管理者が分散システムを管理しやすいように定義したものであり、企業にとっての重要業務への影響を示唆するものではない。従って、複数の障害が同時に発生した場合、前述のように表示される重要度に基づいて管理者が障害に対処したとしても、業務上の損失を最小限に抑えることにはならない恐れがある。
【０００８】
また、近年、分散システムの運用管理にビジネスの視点を取り入れようとする試みがある。この分散システムの運用管理は、分散システム上で実施している業務と、それを構成するサーバ、ストレージ機器、ネットワーク機器、業務アプリケーション、データベース等のコンピュータ機器（以下、リソース）との関係を予め定義しておき、あるリソースに障害が発生した場合、その障害がどの業務に影響を及ぼす可能性があるかをイベント監視コンソールに表示するというものである。
【０００９】
図１２は前述したような従来技術による業務とリソースとの関係を定義した例を説明する図、図１３はリソースの障害がどの業務に影響を及ぼすかをイベント監視コンソールに表示した例を説明する図である。
【００１０】
図１２に示す業務とリソースとの関係を定義した例は、業務Ａ１２００が、サーバ１２０１、１２０２、データベースＡ１２０３、ストレージ１２０４、１２０５、アプリケーション１２０６〜１２０８、ルータ１２０９、１２１０等の合計１０個のリソースによって構成されているシステムにより実行されることを表している。このような定義は、業務毎に行われて備えられている。また、図１３に示す表示例は、図１２に示すリソースの障害がどの業務に影響を及ぼす可能性があるかを表示しており、図示例では、アプリケーションＢ１２０７に障害が発生した場合に、このアプリケーションを構成要素として持つ業務Ａ１２００、業務Ｂ１３００、業務Ｃ１３１０に支障を来たす恐れがあることを示している。前述した図１３に示すような表示を行うタイプのイベント監視コンソールを「障害影響表示タイプ」と定義することとする。
【００１１】
図１３に示す「障害影響表示タイプ」の例は、「基本タイプ」をよりビジネスに近い観点で捉えたものであり、あるリソースにおける障害がどの業務に影響を及ぼすかを把握することは可能であるが、どの業務が企業にとって重要であるかまでは把握することはできない。通常、運用管理者は、分散システム上で行われている個々の業務の重要性までは精通していない。従って、運用管理者は、前記したような「障害影響表示タイプ」のイベント監視コンソールを使用したとしても、複数の障害が同時に発生した場合に、影響の及ぶ可能性のある業務を調べた上で、現在、どの業務が重要であるのかを経営者や各業務の担当者に確認しなければ、障害対処の優先順位を自ら決定することができない。その結果、障害対処に余計な時間を浪費し、ビジネス上の損失を拡大してしまうことになる。
【００１２】
なお、分散システムの利用者から見た業務の重要度への取り組みに関する従来技術として、例えば、特許文献１等に記載された技術が知られている。この従来技術は、システムの運用保守という発想で、業務を構成する構成要素の将来的な動向を予測し、障害発生前にメモリやディスクの増設をする等の対策を打つことを目的としており、分散システム上で今、実際に発生している障害に対する対処を行うという点について考慮されていないものである。
【００１３】
また、他の従来技術として、例えば、特許文献２等に記載された技術が知られている。この従来技術は、時々刻々、大量に発生するイベントに対し、その重要度や内容に応じて自動的に分類・ランク付けを行い発生した障害への対処時間の短縮を試みるというものである。しかし、この従来技術は、考慮される重要度が前述したシステムリソースの障害の重大度を表す重要度であって、その障害によって影響を受ける可能性のある業務がどれであるか、また、その業務の持つ意味やその業務の停止が企業のビジネスへもたらす影響の度合いを考慮したものではない。
【００１４】
【特許文献１】
特開平１０−８３３８２号公報
【００１５】
【特許文献２】
特開平１０−６３５３９号公報
【００１６】
【発明が解決しようとする課題】
前述したように、従来の分散システムに対する運用管理の技術は、そのシステム上で実現されているどの業務がどれほど重要であるかという業務そのものの重要性を考慮して障害対処の優先順位を示唆するまでには至っていない。
【００１７】
このため、従来技術による分散システムの運用管理技術は、複数の障害が発生した場合、図１０により説明したようなイベント監視コンソールが提供する重要度に従って、重要とされるものから順に対処しても、この重要度がビジネス上の重要性を考慮したものではないため、ビジネス上の損失を最小限に抑えることができないという問題点を有している。
【００１８】
本発明の目的は、前述した従来技術の問題点を解決し、どの障害がどの業務に影響を及ぼすかという影響範囲を特定するだけでなく、その業務がどの程度重要な業務であるかをリアルタイムに運用管理者に提示し、熟練しかつビジネスへの理解度の高い運用管理者でなくても、迅速に、かつ、ビジネス上の損失を最小限に抑えた分散システムの運用管理を行うことを可能にした分散システムの運用管理方法及び装置を提供することにある。
【００１９】
【課題を解決するための手段】
本発明によれば前記目的は、複数の業務サーバを有する分散コンピュータシステムの運用管理装置における運用管理方法において、前記運用管理装置は、前記システムのリソースの障害の発生時に、前記業務サーバの障害に関するイベント情報と障害に関するリソース情報とを前記業務サーバから受信し、前記受信したリソース情報と、予め保持している業務とその業務を構成するリソースとの関係から影響業務を特定し、前記特定された影響のある業務について、その業務が重要となる期間、業務の事業規模、信頼損失度を含む業務に対応した複数の評価項目から業務に関する重要度を算出するために、業務の種別毎に前記評価項目の種別が対応付けられ、業務毎にその業務の種別に対応する評価項目の値を記憶している記憶手段から前記影響のある業務に対応する業務種別の評価項目の値を取得し、複数の前記評価項目からなる業務に対応した複数種の重要度算出式のうち、前記取得した評価項目の値と前記業務に対応した重要度算出式とにより前記業務に関する重要度を算出し、前記業務に関する算出された重要度と、前記業務に対応する前記イベント情報とを表示することことにより達成される。
【００２０】
また、前記目的は、複数の業務サーバを有する分散コンピュータシステムの運用管理装置において、統合管理部と、業務とリソースとの関係を定義して管理する業務影響管理部と、業務の重要度を作成して管理する重要度管理部とを有し、前記統合管理部は、前記複数の業務サーバのそれぞれが有し自業務サーバを監視するエージェント部から障害の発生に伴うイベント情報とリソース情報とを受信し、受信したリソース情報を前記業務影響管理部に送信して、影響業務の照会を行い、前記業務影響管理部は、受信したリソース情報と、予め保持している業務とその業務を構成するリソースとの関係から影響業務を特定し、受信したリソースを構成要素に持つ業務名称のリストを、影響業務情報として前記統合管理部に返し、前記統合管理部は、前記業務影響管理部から受信した特定された影響業務について、その業務の重要度を、前記重要度管理部に問い合わせ、前記重要度管理部は、前記統合管理部からの前記問い合わせに対して、前記特定された影響のある業務について、その業務が重要となる期間、業務の事業規模、信頼損失度を含む業務に対応した複数の評価項目から業務に関する重要度を算出するために、業務の種別毎に前記評価項目の種別が対応付けられ、業務毎にその業務の種別に対応する評価項目の値を記憶している記憶手段から前記影響のある業務に対応する業務種別の評価項目の値を取得し、複数の前記評価項目からなる業務に対応した複数種の重要度算出式のうち、前記取得した評価項目の値と前記業務に対応した重要度算出式とにより前記業務に関する重要度を算出し、算出した業務の重要度データを前記統合管理部に返送し、前記統合管理部は、前記重要度管理部から受け取った業務の重要度と、該業務に対応する前記イベント情報とを表示することにより達成される。
【００２１】
【発明の実施の形態】
以下、本発明による分散システムの運用管理方法及び装置の実施形態を図面により詳細に説明する。
【００２２】
図１は本発明の一実施形態による分散システムの運用管理方法によりイベント監視コンソールに表示された表示画面の例を説明する図である。
【００２３】
なお、以下に説明する本発明の実施形態は、図１に示すようなイベントメッセージを表示するタイプのイベント監視コンソールを例としているが、本発明は、それ以外のタイプ、例えば、業務やリソースをアイコンによりツリー構造で表示し、システム全体の障害をＧＵＩ（Graphical User Interface）上で監視するタイプの監視コンソールであってもよい。
【００２４】
本発明の実施形態は、図１０により説明した従来技術によるイベント監視コンソール画面の代わりに、図１に示すような表示を提供することを可能にしたものであり、図１は、図１０に示している監視状態をそのまま用いて、本発明で提供する業務の重要度を付与したイベント監視コンソールでの表示例である。ここで表示される情報は、イベントの発生毎に、業務の重要度１００、イベントとしての障害の発生時刻１０１、発生したイベントの内容を示すイベントメッセージ１０２を組としたレコードにより構成される。業務の重要度１００は、Ａ、Ｂ、Ｃ、……等として表され、Ａ＞Ｂ＞Ｃ＞……のように重要度がランク付けされる。なお、この表示には、対応する障害により影響を受ける業務の名称を示していないが、必要に応じて障害の影響を受ける可能性のある業務の名称を併せて表示してもよい。
【００２５】
同一の内容を持つイベントについて、図１０に示しているものと図１に示しているものとを比較すると明らかなように、図１０の例で“緊急”１０２０と表示される「サーバ０８のメモリ使用率が９５％を超えた」というイベント１０２２は、図１に示す本発明の実施形態の場合、業務の重要度が“Ｃ”と評価されている。これは、イベント１０２２として発生した「サーバ０８」の障害は、リソースの障害としては重大な障害であっても、重要な業務には使われていないサーバの障害であることを意味している。従って、業務への影響を最小限に抑えるという観点から捉えれば、このイベント１０２２は、図１０に示すような緊急に対処すべき障害では必ずしもないものである。
【００２６】
同様に、図１０に示す“注意”１０３０のレベルでしかなかったイベント「アプリケーション０３のレスポンスの低下」１０３２は、業務への影響を考慮した図１に示す例では、“Ａ”ランクの極めて重要なイベントとして表示されている。このことは、イベント１０３２でレスポンスが低下していると通知された「アプリケーション０３」が重要な業務で使われており、リソースの障害としては重大な障害でなくても、業務への影響を考慮した場合には看過すことができない重要なイベントであることを示している。もし、分散システムを管理する運用管理者が、図１０に示すイベント監視コンソールが示す重要度に従って、“注意”と表示されたイベント１０３２ではなく“緊急”と表示されたイベント１０２２から対処した場合、ビジネス上の損失を拡大させることになり得る。
【００２７】
前述したように、本発明の実施形態による分散システムの運用管理方法によるイベント監視コンソールの表示は、従来技術によるイベント監視コンソールが示す情報からでは見抜くことができないビジネス上の重要な障害を、的確に運用管理者に提示することができる。これにより、運用管理者は、イベントメッセージと共に提供される業務の重要度を判断基準として障害に対処して行くことにより、障害による業務停止で発生する損失を最小限に抑えることが可能となる。
【００２８】
図２は本発明の一実施形態による分散システムの運用管理方法を適用した分散システムの構成を示すブロック図である。図２において、２００は統合管理部、２０１はイベント表示部、２０２はイベント管理部、２０３はイベントデータベース、２１０は業務影響管理部、２１１は関係定義部、２１２は業務定義データベース、２２０は重要度管理部、２２１は重要度データ管理部、２２２はルールテーブル管理部、２２３はテーブルデータ取得部、２２４は業務重要度データベース、２５０、２６０、２７０は業務サーバＡ〜Ｃ、２５１、２６１、２７１はエージェント部、２５２、２６２、２７２はデータベースである。
【００２９】
図２に示す分散システムは、統合管理部２００と、業務影響管理部２１０と、重要度管理部２２０と、監視対象であり業務を実行する複数の業務サーバによる業務サーバ群とが、図示しないネットワークを介して接続されて構成される。業務サーバ群は、業務サーバＡ２５０、業務サーバＢ２６０、業務サーバＣ２７０等の複数の業務サーバからなる。前述の業務サーバは、業務毎に１つのコンピュータ（計算機）が用いられてもよいし、複数の業務が１つのコンピュータ内に構成されてもよい。また、統合管理部２００、業務影響管理部２１０、重要度管理部２２０は、それぞれが１つのコンピュータ（計算機）内に構成されてもよいが、これらは、１つのコンピュータ内に構成されていてもよい。さらに、図２には示していないが、図示していないネットワークに各種の周辺機器が接続されていてもよい。
【００３０】
なお、前述した従来技術における「基本タイプ」のイベント監視コンソールは、業務サーバ群と統合管理部２００とにより構成され、「障害影響表示タイプ」のイベント監視コンソールは、「基本タイプ」の構成に業務影響管理部２１０を追加して構成されることになる。
【００３１】
監視対象となる業務サーバ群を構成する各業務サーバ２５０、２６０、２７０は、各業務サーバを監視するためのエージェント２５１、２６１、２７１が配置され、また、各業務サーバが作成したデータを格納するデータベース２５２、２６２、２７２を備えている。
【００３２】
統合管理部２００は、イベント表示部２０１、イベント管理部２０２、イベントデータベース２０３からなる。イベント表示部２０１は、イベント管理部２０２が保有する情報を図示しないイベント監視コンソールに表示する。イベント管理部２０２は、業務サーバ２５０、２６０、２７０等のエージェント部２５１、２６１、２７１から送信されるイベントを受信し、不要なイベントのフィルタリングや関連イベントを集約する等の必要な処理を実施すると共に、必要に応じて、イベントデータベース２０３に格納する。なお、イベント表示部２０１とイベント管理部２０２とは、別のコンピュータ上に構成し、ネットワークにより接続されていてもよい。
【００３３】
業務影響管理部２１０は、関係定義部２１１と業務定義データベース２１２とからなる。関係定義部２１１は、図１２に示して前述で説明したように、分散システム上で実施される業務とそれを構成するリソースとの関係を定義情報として管理し、業務定義データベース２１２に保管する。また、関係定義部２１１は、統合管理部２００のイベント管理部２０２からの問い合わせに対し、受信したイベントが発生したリソースを構成要素に持つ業務名称のリストをイベント管理部２０２へ返す役割を担う。
【００３４】
重要度管理部２２０は、業務影響管理部２１０で定義されている業務の重要度を作成し、管理する役割を持ち、重要度データ管理部２２１、ルールテーブル管理部２２２、テーブルデータ取得部２２３及び業務重要度データベース２２４から構成される。重要度データ管理部２２１は、統合管理部２００のイベント管理部２０２からの要求に対し、当該イベントにより影響を受ける可能性のある業務について、業務重要度データベース２２４を参照し、業務の重要度を提供する。なお、影響を受ける業務が複数ある場合、それぞれの業務の重要度を比較し、一番重要度の高いものをイベント管理部２０２へ返す。
【００３５】
また、重要度データ管理部２２１は、業務重要度データを作成し、業務重要度データベース２２４に格納する役割も担い、業務重要度が時間や日付等の要因によって変化する場合、所定の間隔で業務重要度データの更新を繰り返し実施し、業務重要度データベース２２４のデータを最新状態に保つ。ルールテーブル管理部２２２は、後述する業務重要度作成のためのルール及び評価式を管理し、実際に業務重要度を算出する役割を持つ。テーブルデータ取得部２２３は、ルールテーブル管理部２２２が業務重要度データを算出する際に、必要に応じて入力パラメータとなるデータを業務サーバ２５０、２６０、２７０などが保持するデータベース２５２、２６２、２７２等から取得する。
【００３６】
次に、重要度管理部２２０が業務重要度データを算出するプロセスについて具体的に説明する。
【００３７】
図３は業務重要度データベース２２４に格納されている業務重要度データの例を示す図、図４はルールテーブル定義表の構成を示す図、図５はルールテーブルの構成を示す図、図６は変数データの最新のものが格納されている場所を示す所在テーブルの構成を示す図、図７は業務の重要度を算出する定義式を示す図である。
【００３８】
業務重要度データベース２２４には、図３に示すような業務重要度データが格納されている。業務重要度データベース２２４は、業務名称３００と業務重要度３０１とにより構成される。業務名称３００は、分散システム上で実施される業務の名称を示し、具体的な項目として、「インターネット販売サイトＡ」３１０、「製品Ａ生産管理システム」３２５等が格納される。これらは、業務影響管理部２１０の業務定義データベース２１２で管理している業務名称と同一でなければならない。図３では、１０種の業務がある場合を例としているが、業務の数は幾つあってもよい。業務重要度３０１は、対応する業務の重要度を示し、Ａ、Ｂ、Ｃ、……等として表され、Ａ＞Ｂ＞Ｃ＞……のように重要度がランク付けされている。図３に示す例では、「インターネット販売サイトＡ」３１０の業務重要度は「Ａ」３１１となっており、重要な業務であることを意味している。
【００３９】
前述の業務重要度３０１は、以下に説明する手順で評価され、算出された結果を格納したものである。
【００４０】
業務重要度３０１の算出は、図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて行われる。図４に示すルールテーブル管理表は、図５に示す１つまたは複数存在するルールテーブルを管理するためのデータを保持するものである。図４において、業務名称４００は、業務の名称であり、テーブルＮｏ．４０１は、図５に示す複数のルールテーブルのうち該当する業務が含まれるルールテーブルの番号を示し、評価項目数４０２は、該当する業務の重要度を算出する上で必要な評価項目の数を規定している。例えば、「インターネット販売サイトＡ」３１０という業務は、「１」番目（４１１）のルールテーブルに規定されており、その評価項目が「３」つ（４１２）あることが表されている。
【００４１】
図５に示す各ルールテーブルは、各業務の重要度を決める上で必要な評価項目のリストとなっている。なお、ルールテーブルは、通常、全ての業務を同じ評価項目で規定できるわけではないため、同じ項目で規定することができる業務をグループとし、各業務グループ毎に設けられる。図５には、テーブル名称として、＜テーブル１＞４１１、＜テーブル２＞４２１、＜テーブル３＞４３１を持つ３つのテーブルを示している。
【００４２】
＜テーブル１＞４１１における業務名称５００は、テーブル１で規定される業務の名称を表す項目である。「月平均売上（円）＜Ｐ１１＞」５０１、「キャンペーン期間＜Ｐ１２＞」５０２、「期間中売上率（％）＜Ｐ１３＞」５０３は、テーブル１に含まれる業務の重要度を左右する項目名であり、Ｐ１１、Ｐ１２、Ｐ１３は、表中に与えられたデータを値とする業務重要度の変数である。業務名称「インターネット販売サイトＡ」３１０は、「月平均売上」５０１、「キャンペーン期間」５０２、「期間中売上率」５０３の３つの評価項目で重要度が規定され、その値は、それぞれ「50,000,000」５１１、「12/1〜12/24」５１２、「３０」５１３である。これらの値は、事前に分散システムのユーザから提供された値である。
【００４３】
また、＜テーブル２＞４２１に記述されるれる業務は、「在庫数（個）＜Ｐ２１＞」５４１、「最低在庫数（個）＜Ｐ２２＞」５４２の２つの項目で業務の重要度が規定される。業務名「製品Ａ生産管理システム」３２５は、「在庫数」５４１が 「var_1」５５１、「最低在庫数」５４２が「１０」５５２となっている。ここで、 「var_1」５５１は、固定値ではなく変数として与えられており、後述する図６で最新データの格納場所が提供されている。 「var_2」５６１、 「var_3」５７１も同様に変数として与えられている。このように、ルールテーブルは、変数の使用が認められており、該当項目が時間や日付で変化するような場合に使用することができる。
【００４４】
前述したようなルールテーブルで変数を使用する場合、図６に示すように最新データの格納場所を予め規定しておかなければならない。図６において、変数名６００は、図５に示すルールテーブルで用いられた変数の名称であり、データ所在６０１は、分散システム上にあるデータの格納場所をパス等により指定したものである。図６に示す例では、 「var_1」５５１の値が、「server_K\seisan\seihin_A.db」 ６１１というパスで指定される場所にあるデータベースに格納されていることを示している。
【００４５】
業務の重要度は、図７に示す定義式（１）〜（３）を使用して算出することができる。例えば、図５に示すテーブル１に含まれる業務についての業務の重要度Ｆ１は、図５に示すテーブル１の中のデータＰ１１、Ｐ１２、Ｐ１３から図７の式（１）より算出することができる。同様に、図５に示すテーブル２に含まれる業務の重要度Ｆ２は、データＰ２１、Ｐ２２と式（２）とから算出することができ、テーブル３に含まれる業務の重要度Ｆ３は、データＰ３１、Ｐ３２と式（３）とから算出することができる。図３に示した各業務の重要度は、図５において、日付が２月２０日（木）で、 var_1, var_2, var_3の値がそれぞれ13、18、30の場合を想定し、図７の評価式に適用して得られた結果である。
【００４６】
なお、図５に示すルールテーブル１、３に含まれる業務は、日付や曜日が業務の重要度の算出に関係するため、日付が変わる度に業務の重要度データの更新が必要であり、日付が変わる度に重要度の算出が行われる。
【００４７】
図８は前述した本発明の実施形態における業務サーバでのイベント発生から業務の重要度と共に発生したイベントを表示するまでの処理をシーケンスとして示した図であり、次に、これについて説明する。
【００４８】
（１）業務サーバ２５０、２６０、２７０のエージェント部２５１、２６１、２７１は、自業務サーバ内でリソース不足等のイベントが発生すると、そのイベントの情報と、リソースの情報とを統合管理部２００に送り、統合管理部２００のイベント管理部２０２がこれらの情報を受信する（シーケンス▲１▼）。
【００４９】
（２）統合管理部２００のイベント管理部２０２は、業務とリソースとの関係を管理している業務影響管理部２１０の関係定義部２１１にリソース情報を送信して影響業務の照会を行う（シーケンス▲２▼）。
【００５０】
（３）業務影響管理部２１０の関係定義部２１１は、シーケンス▲２▼での影響業務の照会に対して、受信したイベントが発生したリソースを構成要素に持つ業務名称のリストを、影響業務情報としてイベント管理部２０２へ返し、イベント管理部２０２がこの情報を受信する（シーケンス▲３▼）。
【００５１】
（４）統合管理部２００のイベント管理部２０２は、シーケンス▲３▼で受信した業務について、その業務の重要度を、重要度管理部２２０の重要度データ管理部２２１に問い合わせる（シーケンス▲４▼）。
【００５２】
（５）重要度管理部２２０の重要度データ管理部２２１は、シーケンス▲４▼での問い合わせに対して、業務の重要度データを統合管理部２００のイベント管理部２０２に返送し、統合管理部２００のイベント管理部２０２は、このデータを受信する（シーケンス▲５▼）。
【００５３】
（６）その後、統合管理部２００は、イベント表示部２０１に、シーケンス▲５▼で受信した業務の重要度と対応するイベントとを表示させる。
【００５４】
図９は重要度管理部２２０の重要度データ管理部２２１が業務重要度データベース２２４のデータを更新する処理を説明するフローチャートであり、次に、これについて説明する。
【００５５】
（１）重要度管理部２２０の重要度データ管理部２２１が、業務の重要度データの更新を開始する場合、まず、ルールテーブル管理部２２２が、重要度算出に使用するテーブルデータの更新を開始する（ステップ９０１、９０２）。
【００５６】
（２）テーブルデータ取得部２２３は、重要度を算出するために必要なルールテーブル内の変数データの所在情報を参照して指定の業務サーバのデータベースにアクセスする（ステップ９０３）。
【００５７】
（３）ステップ９０３のアクセスに対して、業務サーバのデータベースが変数のデータを応答として返してくるので、テーブルデータ取得部２２３は、その応答のデータを取得する（ステップ９０４、９０５）。
【００５８】
（４）ルールテーブル管理部２２２は、ステップ９０５で、テーブルデータ取得部２２３が取得した変数データを使用して、テーブルデータを更新する（ステップ９０６）。
【００５９】
（５）ルールテーブル管理部２２２は、更新されたテーブルデータを用いて業務重要度を算出する（ステップ９０７）。
【００６０】
（６）重要度データ管理部２２１は、ステップ９０７の処理でルールテーブル管理部２２２が算出した業務重要度データを、業務重要度データベースへ格納する（ステップ９０８、９０９）。
【００６１】
前述した本発明の実施形態における各処理は、処理プログラムとして構成することができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができる。
【００６２】
前述した本発明の実施形態は、図３に示す業務の重要度を図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて算出するものとして説明したが、業務の重要度が算出するまでもなく明白な場合や、ルールテーブルに変数データを含まず、かつ、業務重要度評価式において日時等の変数を含まない場合、本発明は、図３に示す各業務に対応するその業務の重要度を所定のデータとして保持することも可能である。
【００６３】
この場合、例えば、図３に示す業務「インターネット販売サイトＡ」３１０の重要度は算出するまでもなく「Ａ」３１１であるとしてしまってよく、業務重要度算出のプロセスを必要としない。図３で扱う全ての業務に対し、事前に業務重要度を提供することができる場合、図３を所定のデータとして保持し、イベント管理部２０２からの要求に応じて業務重要度を返すだけでよい。この場合、図２に示すルールテーブル管理部２２２とテーブルデータ取得部２２３とは不要である。
【００６４】
また、本発明は、図３に示す各業務の一部の重要度について図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて算出し、他の一部の業務に対応する、その業務の重要度を所定のデータとして保持することも可能である。
【００６５】
この場合、例えば、図５に示すルールテーブルにおいて、テーブル３（４３１）の重点期間５８１は、値に日付や曜日といった変数データを含んでいるため、テーブル３で規定される業務の重要度を所定のデータとして提供することができない。しかし、仮にテーブル３に含まれる業務が重点期間５８１に関係なく、信頼喪失度５８２だけで業務の重要度が決まるような業務であるならば、テーブル３で規定される４種類の業務については、その重要度を所定のデータとして提供することができることになる。このような場合、図３に示す業務「顧客向けＷｅｂサイト」３４０、「従業員向けＷｅｂサイト」３４５、「勤休管理システム」３５０、「給与計算システム」３５５については、その重要度を所定のデータとして図３に保持しておき、残りの６種類の業務の重要度が必要になった場合に、図４〜図７に示すテーブル及び評価式から重要度を算出するようにすればよい。
【００６６】
さらに、本発明は、前述で説明した図３に示す業務の重要度を図４〜図６に示す複数のテーブル及び図７に示す業務重要度評価式を用いて算出する本発明の実施形態による分散システムの運用管理方法を、サービス、例えば、分散システムの運用管理サービスを提供するサービスプロバイダに適用することができる。
【００６７】
そして、そのサービスの１つとして、業務重要度に基づいた障害への優先対処をユーザに対して約束し、業務の重要度の高い業務を実施しているユーザに対して、より多くの対価を要求する料金体系を採用するサービスがある。また、本発明を用いて、業務の重要度毎に要した障害対処時間を毎月レポートし、業務の重要度Ａの業務に関する一月当たりの障害対処時間を１時間以内とするなど、業務重要度をＳＬＡ（サービスレベルアグリーメント）の評価項目として利用するサービスを提供することもできる。
【００６８】
前述した本発明の実施形態によれば、従来のイベント監視コンソールが提示するシステム管理上の障害の重要度と異なり、その障害によって影響を受ける可能性のある業務がどれほど重要なものであるかを指標とする業務の重要度を提供することができ、これにより、運用管理者が、イベントメッセージと共に表示される業務重要度を判断基準として障害に対処して行くことができ、分散システムの障害による業務停止で発生する損失を最小限に抑えることが可能となる。
【００６９】
【発明の効果】
以上説明したように本発明によれば、分散システムにおける業務がどの程度重要な業務であるかを運用管理者に提示することにより、運用管理者は、それぞれのシステム障害による業務への影響を考慮した運用管理を実現できる。
【図面の簡単な説明】
【図１】本発明の一実施形態による分散システムの運用管理方法によりイベント監視コンソールに表示された表示画面の例を説明する図である。
【図２】本発明の一実施形態による分散システムの運用管理方法適用した分散システムの構成を示すブロック図である。
【図３】業務重要度データベースに格納されている業務重要度データの例を示す図である。
【図４】ルールテーブル定義表の構成を示す図である。
【図５】ルールテーブルの構成を示す図である。
【図６】変数データの最新のものが格納されている場所を示す所在テーブルの構成を示す図である。
【図７】業務の重要度を算出する定義式を示す図である。
【図８】本発明の実施形態における業務サーバでのイベント発生から業務の重要度と共に発生したイベントを表示するまでの処理をシーケンスとして示した図である。
【図９】重要度管理部の重要度データ管理部が業務重要度データベースのデータを更新する処理を説明するフローチャートである。
【図１０】従来技術によるイベント監視コンソールの表示画面の表示例を説明する図である。
【図１１】従来技術によるイベント毎の重要度の算出基準の定義について説明する図である。
【図１２】前述したような従来技術による業務とリソースとの関係を定義した例を説明する図である。
【図１３】リソースの障害がどの業務に影響を及ぼすかをイベント監視コンソールに表示した例を説明する図である。
【符号の説明】
２００ 統合管理部
２０１ イベント表示部
２０２ イベント管理部
２０３ イベントデータベース
２１０ 業務影響管理部
２１１ 関係定義部
２１２ 業務定義データベース
２２０ 重要度管理部
２２１ 重要度データ管理部
２２２ ルールテーブル管理部
２２３ テーブルデータ取得部
２２４ 業務重要度データベース
２５０、２６０、２７０ 業務サーバＡ〜Ｃ
２５１、２６１、２７１ エージェント部
２５２、２６２、２７２ データベース
Claims (6)
- 複数の業務サーバを有する分散コンピュータシステムの運用管理装置における運用管理方法において、
前記運用管理装置は、
前記システムのリソースの障害の発生時に、前記業務サーバの障害に関するイベント情報と障害に関するリソース情報とを前記業務サーバから受信し、
前記受信したリソース情報と、予め保持している業務とその業務を構成するリソースとの関係から影響業務を特定し、
前記特定された影響のある業務について、その業務が重要となる期間、業務の事業規模、信頼損失度を含む業務に対応した複数の評価項目から業務に関する重要度を算出するために、
業務の種別毎に前記評価項目の種別が対応付けられ、業務毎にその業務の種別に対応する評価項目の値を記憶している記憶手段から前記影響のある業務に対応する業務種別の評価項目の値を取得し、
複数の前記評価項目からなる業務に対応した複数種の重要度算出式のうち、前記取得した評価項目の値と前記業務に対応した重要度算出式とにより前記業務に関する重要度を算出し、
前記業務に関する算出された重要度と、前記業務に対応する前記イベント情報とを表示することを特徴とする運用管理方法。 - 複数の業務サーバを有する分散コンピュータシステムの運用管理装置における運用管理方法において、
前記運用管理装置は、
統合管理部と、業務とリソースとの関係を定義して管理する業務影響管理部と、業務の重要度を作成して管理する重要度管理部とを有し、
前記統合管理部は、前記複数の業務サーバのそれぞれが有し自業務サーバを監視するエージェント部から障害の発生に伴うイベント情報とリソース情報とを受信し、受信したリソース情報を前記業務影響管理部に送信して、影響業務の照会を行い、
前記業務影響管理部は、受信したリソース情報と、予め保持している業務とその業務を構成するリソースとの関係から影響業務を特定し、受信したリソースを構成要素に持つ業務名称のリストを、影響業務情報として前記統合管理部に返し、
前記統合管理部は、前記業務影響管理部から受信した特定された影響業務について、その業務の重要度を、前記重要度管理部に問い合わせ、
前記重要度管理部は、前記統合管理部からの前記問い合わせに対して、前記特定された影響のある業務について、その業務が重要となる期間、業務の事業規模、信頼損失度を含む業務に対応した複数の評価項目から業務に関する重要度を算出するために、
業務の種別毎に前記評価項目の種別が対応付けられ、業務毎にその業務の種別に対応する評価項目の値を記憶している記憶手段から前記影響のある業務に対応する業務種別の評価項目の値を取得し、
複数の前記評価項目からなる業務に対応した複数種の重要度算出式のうち、前記取得した評価項目の値と前記業務に対応した重要度算出式とにより前記業務に関する重要度を算出し、算出した業務の重要度データを前記統合管理部に返送し、
前記統合管理部は、前記重要度管理部から受け取った業務の重要度と、該業務に対応する前記イベント情報とを表示することを特徴とする運用管理方法。 - 前記業務の重要度は、業務名称と、該業務名称を持つ業務の重要度を決める複数の評価項目とを対応付けて構成される業務グループ毎に備えられたルールテーブルの前記複数の評価項目から所定の定義式に従って算出されることを特徴とする請求項１または２記載の運用管理方法。
- 前記業務の重要度は、前記評価項目に変数が含まれる場合、前記変数の更新の度に算出されることを特徴とする請求項３記載の運用管理方法。
- 複数の業務サーバを有する分散コンピュータシステムの運用管理装置において、
統合管理部と、業務とリソースとの関係を定義して管理する業務影響管理部と、業務の重要度を作成して管理する重要度管理部とを有し、
前記統合管理部は、前記複数の業務サーバのそれぞれが有し自業務サーバを監視するエージェント部から障害の発生に伴うイベント情報とリソース情報とを受信し、受信したリソース情報を前記業務影響管理部に送信して、影響業務の照会を行い、
前記業務影響管理部は、受信したリソース情報と、予め保持している業務とその業務を構成するリソースとの関係から影響業務を特定し、受信したリソースを構成要素に持つ業務名称のリストを、影響業務情報として前記統合管理部に返し、
前記統合管理部は、前記業務影響管理部から受信した特定された影響業務について、その業務の重要度を、前記重要度管理部に問い合わせ、
前記重要度管理部は、前記統合管理部からの前記問い合わせに対して、前記特定された影響のある業務について、その業務が重要となる期間、業務の事業規模、信頼損失度を含む業務に対応した複数の評価項目から業務に関する重要度を算出するために、
業務の種別毎に前記評価項目の種別が対応付けられ、業務毎にその業務の種別に対応する評価項目の値を記憶している記憶手段から前記影響のある業務に対応する業務種別の評価項目の値を取得し、
複数の前記評価項目からなる業務に対応した複数種の重要度算出式のうち、前記取得した評価項目の値と前記業務に対応した重要度算出式とにより前記業務に関する重要度を算出し、算出した業務の重要度データを前記統合管理部に返送し、
前記統合管理部は、前記重要度管理部から受け取った業務の重要度と、該業務に対応する前記イベント情報とを表示することを特徴とする運用管理装置。 - 複数の業務サーバを有する分散コンピュータシステムの運用管理を行うプログラムであって、
前記複数の業務サーバのそれぞれが有し自業務サーバを監視するエージェント部から障害の発生に伴うイベント情報とリソース情報とを受信するステップと、受信したリソース情報と、予め保持している業務とその業務を構成するリソースとの関係から影響業務を特定するステップと、前記特定された影響のある業務について、その業務が重要となる期間、業務の事業規模、信頼損失度を含む業務に対応した複数の評価項目から業務に関する重要度を算出するために、業務の種別毎に前記評価項目の種別が対応付けられ、業務毎にその業務の種別に対応する評価項目の値を記憶している記憶手段から前記影響のある業務に対応する業務種別の評価項目の値を取得し、複数の前記評価項目からなる業務に対応した複数種の重要度算出式のうち、前記取得した評価項目の値と前記業務に対応した重要度算出式とにより前記業務に関する重要度を算出するステップとを有し、前記各処理ステップを運用管理装置が備えるＣＰＵに実行させることにより、分散コンピュータシステムの運用管理を行うことを特徴とするプログラム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003194994A JP4485763B2 (ja) | 2003-07-10 | 2003-07-10 | 運用管理方法及び装置 |
| US10/838,232 US7350100B2 (en) | 2003-07-10 | 2004-05-05 | Method and apparatus for monitoring data-processing system |
| US12/045,379 US8250400B2 (en) | 2003-07-10 | 2008-03-10 | Method and apparatus for monitoring data-processing system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003194994A JP4485763B2 (ja) | 2003-07-10 | 2003-07-10 | 運用管理方法及び装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005031893A JP2005031893A (ja) | 2005-02-03 |
| JP4485763B2 true JP4485763B2 (ja) | 2010-06-23 |
Family
ID=34074331
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003194994A Expired - Fee Related JP4485763B2 (ja) | 2003-07-10 | 2003-07-10 | 運用管理方法及び装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (2) | US7350100B2 (ja) |
| JP (1) | JP4485763B2 (ja) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070168201A1 (en) * | 2006-01-06 | 2007-07-19 | Chellam Sudhakar V | Formula for automatic prioritization of the business impact based on a failure on a service in a loosely coupled application |
| US20070240126A1 (en) * | 2006-02-01 | 2007-10-11 | International Business Machines Corporation | System and method for event based resource selection |
| JP2007226526A (ja) * | 2006-02-23 | 2007-09-06 | Ns Solutions Corp | 情報処理装置、情報処理方法、プログラム及び記憶媒体 |
| US20100287010A1 (en) * | 2006-09-19 | 2010-11-11 | International Business Machines Corporation | System, method and program for managing disaster recovery |
| JP2008102672A (ja) | 2006-10-18 | 2008-05-01 | Hitachi Ltd | 計算機システム、管理計算機、操作制御情報の設定方法 |
| JP4865511B2 (ja) * | 2006-11-24 | 2012-02-01 | 株式会社野村総合研究所 | サービス管理装置 |
| JP2008276687A (ja) * | 2007-05-07 | 2008-11-13 | Mitsubishi Electric Corp | 監視装置及びこれを用いた監視システム |
| JP2009003543A (ja) * | 2007-06-19 | 2009-01-08 | Nec Corp | データ処理装置、そのコンピュータプログラムおよびデータ処理方法 |
| JP2009217587A (ja) * | 2008-03-11 | 2009-09-24 | Hitachi Ltd | バッチ処理装置及び方法 |
| JP5544929B2 (ja) * | 2010-03-01 | 2014-07-09 | 日本電気株式会社 | 運用管理装置、運用管理方法、運用管理プログラム |
| JP6306499B2 (ja) * | 2014-12-25 | 2018-04-04 | クラリオン株式会社 | 障害情報提供サーバ、障害情報提供方法 |
| CN107220162A (zh) * | 2017-07-04 | 2017-09-29 | 鹏元征信有限公司 | 一种业务告警方法、存储介质及装置 |
| JP2020123043A (ja) * | 2019-01-29 | 2020-08-13 | 日本電信電話株式会社 | 推定方法、推定装置および推定プログラム |
| CN112199394A (zh) * | 2020-09-25 | 2021-01-08 | 同程网络科技股份有限公司 | 告警信息推送方法、系统、智能终端及存储介质 |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0895916A (ja) * | 1994-09-27 | 1996-04-12 | Hitachi Software Eng Co Ltd | ジョブ実行監視方法 |
| JPH1063539A (ja) | 1996-08-26 | 1998-03-06 | Hitachi Inf Syst Ltd | 運行監視通報システム |
| JPH1083382A (ja) * | 1996-09-09 | 1998-03-31 | Toshiba Corp | 分散システム運用保守支援装置および運用保守支援方法 |
| JPH1091467A (ja) * | 1996-09-17 | 1998-04-10 | Hitachi Ltd | 多重系計算機およびそのバックアップ方法 |
| US6112243A (en) * | 1996-12-30 | 2000-08-29 | Intel Corporation | Method and apparatus for allocating tasks to remote networked processors |
| US5878302A (en) * | 1997-03-12 | 1999-03-02 | Minolta Co., Ltd. | Image forming apparatus informing internal abnormality |
| JPH11313130A (ja) * | 1998-04-30 | 1999-11-09 | Nippon Telegr & Teleph Corp <Ntt> | 故障処理の優先順位決定方法および装置および優先順位決定プログラムを記録した記録媒体 |
| JP3537356B2 (ja) * | 1998-12-09 | 2004-06-14 | 株式会社日立製作所 | ジョブシステムにおける遅延要因解析方法 |
| JP2000194627A (ja) * | 1998-12-25 | 2000-07-14 | Ntt Data Corp | ネットワ―クシステムの運用方法、運用状況監視装置及び情報通信装置 |
| JP2001195267A (ja) * | 2000-01-07 | 2001-07-19 | Hitachi Ltd | 制御計算機システム及びタスク実行制御方法 |
| JP2001282752A (ja) * | 2000-03-29 | 2001-10-12 | Ntt Comware Corp | 複合システム管理装置および複合システム管理方法 |
| JP2002049493A (ja) * | 2000-08-04 | 2002-02-15 | Hitachi Ltd | プログラム制御情報生成方法およびシステム並びにその処理プログラムを格納した記録媒体 |
| US6941514B2 (en) * | 2001-04-30 | 2005-09-06 | Bellsouth Intellectual Property Corporation | System and method for priority-based work order scheduling |
| JP2003256222A (ja) * | 2002-03-04 | 2003-09-10 | Matsushita Electric Ind Co Ltd | 分散処理システム、ジョブ分散処理方法およびプログラム |
| US20040001215A1 (en) * | 2002-06-26 | 2004-01-01 | Canon Kabushiki Kaisha | Print control apparatus, print control method, program product, and print system |
| JP3951835B2 (ja) * | 2002-07-03 | 2007-08-01 | 株式会社日立製作所 | 業務管理方法及び業務処理システム |
| US6895292B2 (en) * | 2003-04-28 | 2005-05-17 | Palo Alto Research Center Inc. | Predictive and preemptive planning and scheduling for different job priorities system and method |
| US7139629B2 (en) * | 2003-04-28 | 2006-11-21 | Palo Alto Research Center Incorporated | Planning and scheduling for failure recovery system and method |
| JP4255317B2 (ja) * | 2003-06-03 | 2009-04-15 | 株式会社日立製作所 | 運用監視方法及び実施システム並びに処理プログラム |
| JP2005031771A (ja) * | 2003-07-08 | 2005-02-03 | Hitachi Ltd | ジョブスケジューリング管理方法及びシステム並びにプログラム |
| US20050096957A1 (en) * | 2003-10-31 | 2005-05-05 | Bayoumi Deia S. | System and method for manufacturing job rescheduling |
| JP4874140B2 (ja) * | 2007-03-20 | 2012-02-15 | 京セラミタ株式会社 | ジョブスケジューラ、ジョブスケジュール方法、及び、ジョブ制御プログラム |
| US8151272B2 (en) * | 2008-04-07 | 2012-04-03 | At&T Intellectual Property I, Lp | Optimized usage of collector resources for performance data collection through even task assignment |
| US8296590B2 (en) * | 2008-06-09 | 2012-10-23 | International Business Machines Corporation | Budget-based power consumption for application execution on a plurality of compute nodes |
| US8356304B2 (en) * | 2009-06-30 | 2013-01-15 | International Business Machines Corporation | Method and system for job scheduling |
-
2003
- 2003-07-10 JP JP2003194994A patent/JP4485763B2/ja not_active Expired - Fee Related
-
2004
- 2004-05-05 US US10/838,232 patent/US7350100B2/en not_active Expired - Fee Related
-
2008
- 2008-03-10 US US12/045,379 patent/US8250400B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2005031893A (ja) | 2005-02-03 |
| US8250400B2 (en) | 2012-08-21 |
| US20050022190A1 (en) | 2005-01-27 |
| US20080168442A1 (en) | 2008-07-10 |
| US7350100B2 (en) | 2008-03-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8250400B2 (en) | Method and apparatus for monitoring data-processing system | |
| CN103548009B (zh) | 用于跨云管理和故障查找的方法和系统 | |
| US10225208B1 (en) | Resource configuration service | |
| US10699237B2 (en) | Graphical user interfaces for dynamic information technology performance analytics and recommendations | |
| US6732118B2 (en) | Method, computer system, and computer program product for monitoring objects of an information technology environment | |
| CN103547994B (zh) | 用于容量管理和灾难恢复的跨云计算的方法和系统 | |
| US7568019B1 (en) | Enterprise management system for normalization, integration and correlation of business measurements with application and infrastructure measurements | |
| US8041807B2 (en) | Method, system and program product for determining a number of concurrent users accessing a system | |
| US6876993B2 (en) | Method and system for generating management solutions | |
| US8099379B2 (en) | Performance evaluating apparatus, performance evaluating method, and program | |
| US7343459B2 (en) | Systems and methods for detecting & mitigating storage risks | |
| US8024214B2 (en) | System and method of visualization for aggregation of change tracking information | |
| US20090158189A1 (en) | Predictive monitoring dashboard | |
| US20080295100A1 (en) | System and method for diagnosing and managing information technology resources | |
| US20050144025A1 (en) | Using technical performance metrics for business and usage analysis and cost allocation | |
| US20080222098A1 (en) | Methods, systems, and computer program products for providing consolidated order information | |
| US20200228396A1 (en) | Self-monitoring | |
| US7099938B2 (en) | Method, computer system, and computer program product for monitoring services of an information technology environment | |
| US10417712B2 (en) | Enterprise application high availability scoring and prioritization system | |
| US8046770B2 (en) | Methods, systems, and computer program products for managing productivity | |
| US8291059B2 (en) | Method for determining a business calendar across a shared computing infrastructure | |
| JP4865511B2 (ja) | サービス管理装置 | |
| Keller et al. | Implementing a service desk: A practitioner's perspective | |
| US8352310B1 (en) | Web-enabled metrics and automation | |
| Chowdhary et al. | Enterprise integration and monitoring solution using active shared space |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050812 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080325 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081118 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090116 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090512 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090713 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20091201 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100126 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100302 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100325 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4485763 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130402 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140402 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |