[go: up one dir, main page]

JP5140633B2 - 仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラム - Google Patents

仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラム Download PDF

Info

Publication number
JP5140633B2
JP5140633B2 JP2009135441A JP2009135441A JP5140633B2 JP 5140633 B2 JP5140633 B2 JP 5140633B2 JP 2009135441 A JP2009135441 A JP 2009135441A JP 2009135441 A JP2009135441 A JP 2009135441A JP 5140633 B2 JP5140633 B2 JP 5140633B2
Authority
JP
Japan
Prior art keywords
server
event
failure
history
virtual server
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
Application number
JP2009135441A
Other languages
English (en)
Other versions
JP2010086516A (ja
Inventor
利博 南松
安彰 齋藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2009135441A priority Critical patent/JP5140633B2/ja
Priority to US12/551,962 priority patent/US8006134B2/en
Publication of JP2010086516A publication Critical patent/JP2010086516A/ja
Application granted granted Critical
Publication of JP5140633B2 publication Critical patent/JP5140633B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/079—Root cause analysis, i.e. error or fault diagnosis
    • 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/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H04L41/065—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis involving logical or physical relationship, e.g. grouping and hierarchies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0677—Localisation of faults
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • 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/0793—Remedial or corrective actions
    • 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/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Debugging And Monitoring (AREA)

Description

本発明は、物理サーバで動作する仮想化機構によって仮想サーバが実現される仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラムに関し、とくに仮想化環境における障害の原因箇所の特定を容易かつ迅速に行う技術に関する。
昨今、情報処理システムの性能向上に伴うハードウエア資源の有効活用や負荷分散、可用性の確保等を目的として、いわゆる仮想化技術が注目されている。情報処理システムにおける障害対応においては、業務への影響を防ぐべく、迅速かつ確実な対応が求められる。しかしながら上記仮想化技術が適用された環境では、障害の発生箇所を特定することが必ずしも容易ではない。
例えば、仮想サーバで動作する業務プロセスから障害が報告された場合には、障害の原因が業務プロセスにあるのか、仮想サーバにあるのか、又は物理サーバにあるのかを特定するために、業務プロセス、仮想サーバ、及び物理サーバの夫々に蓄積されているログ情報を分析し、その分析結果に基づいて障害箇所を特定する必要があり、多大な労力が必要になる。
障害の原因を特定する技術として、例えば、特許文献１には、仮想サーバ環境において、仮想サーバに何らかの障害が発生した場合にシステム管理者が仮想サーバのログを迅速に参照できるようにするために、仮想サーバが他の物理サーバに移動する毎に、その移動履歴を生成／記録し、一元管理することが記載されている。また特許文献２には、仮想計算機システムの配下における障害情報の処理において、異常な周辺機器の早期確認、早期対処を実現すべく、仮想計算機システムの稼働中に周辺装置に障害が発生すると、ゲスト仮想計算機の配下にあるオペレーティングシステムが検出したロギング情報やホストシステムが検出したロギング情報を、各ゲスト仮想計算機の配下にある異常通報システムが分析／分類し、実機番号で保守センタに自動通知することが記載されている。
特開２００７−３２３２４４号公報 特開平４−２５７０３５号公報
上記特許文献１及び特許文献２に記載されている技術は、いずれもログ情報の解析を保守員等の人手によって行うことを前提としており、仮想化環境における障害発生時における解析に必要な労力が必ずしも軽減されるわけではない。即ちこれらの技術によっては障害原因の特定やその対処を必ずしも容易かつ迅速に行えるわけではない。
この発明はこのような背景に鑑みてなされたもので、仮想化環境における障害の原因箇所の特定を容易かつ迅速に行うことを可能とする仮想化環境における障害の解析方法及び管理サーバを提供することを目的とする。
上記目的を達成するための本発明のうちの一つは、物理サーバで動作する仮想化機構によって仮想サーバが実現される仮想化環境において生じる障害の解析方法であって、前記物理サーバと通信可能に接続される管理サーバが、前記仮想サーバと当該仮想サーバが実現されている前記物理サーバとの対応が登録されたマッピングテーブルを記憶し、前記物理サーバで生じたイベントの履歴である第２のイベント履歴と、前記仮想サーバで生じたイベントの履歴である第１のイベント履歴とを蓄積記憶し、前記仮想サーバで動作している業務プロセスの障害に関する前記イベントを受信すると、前記第１のイベント履歴のうち、当該イベントを発した仮想サーバに関するイベント履歴と、前記第２のイベント履歴のうち、前記マッピングテーブルから取得される、当該イベントを発した前記仮想サーバを実現している前記物理サーバに関するイベント履歴とを、前記蓄積記憶している前記イベント履歴から検索し、その検索結果に基づき障害の原因を特定し、前記第１のイベント履歴の検索に用いる第１の検索条件と第１の障害箇所とを対応づけた仮想サーバイベント解析ポリシーテーブル、及び前記第２のイベント履歴の検索に用いる第２の検索条件と第２の障害箇所とを対応づけた物理サーバイベント解析ポリシーテーブルを記憶し、蓄積記憶している前記イベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができない場合には、障害の原因が前記業務プロセスにあると特定し、前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができたが、前記第２のイベント履歴を検索することができなかった場合には、障害の原因が前記仮想サーバにあると特定し、前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴及び前記第２のイベント履歴を検索することができ、かつ、検索された前記第１のイベント履歴の検索に用いた前記第１の検索条件に対応づけられている前記第１の障害箇所と検索された前記第２のイベント履歴の検索に用いた前記第２の検索条件に対応づけられている前記第２の障害箇所とが一致しない場合には、障害の原因が前記仮想サーバにあると特定し、一致する場合には、障害の原因が前記物理サーバにあると特定することとする。
その他、本願が開示する課題、およびその解決手段は、発明を実施するための最良の形態の欄、及び図面により明らかにされる。
本発明によれば、仮想化環境における障害の原因箇所の特定を容易かつ迅速に行うことができる。
仮想化システム１を実現するために用いられるハードウエア環境を示す図である。 管理サーバ１０又は物理サーバ２０として用いられるコンピュータの一例である。 管理サーバ１０の機能及び管理サーバ１０において管理されるデータを示す図である。 物理サーバ２０の機能及び物理サーバ２０において管理されるデータを示す図である。 イベント履歴テーブル１２１の一例である。 稼働サーバマッピングテーブル１２２の一例である。 仮想サーバイベント解析ポリシーテーブル１２４の一例である。 物理サーバイベント解析ポリシーテーブル１２５の一例である。 解析履歴テーブル１２３の一例である。 対処テーブル１２６の一例である。 アプリケーション管理テーブル１２７の一例である。 ＳＬＡ定義テーブル１２８の一例である。 リソース管理テーブル１２９の一例である。 依存関係管理テーブル１３０の一例である。 サーバ管理テーブル１３１の一例である。 パッチ管理テーブル１３２の一例である。 障害監視部１１０によって行われる処理を説明するフローチャートである。 解析処理（Ｓ４１３）の詳細を説明するフローチャートである。 対処実行部１１８が備える主な機能を示す図である。 障害対処処理Ｓ４１５の全体的な流れを説明するフローチャートである。 仮想サーバ移動処理Ｓ６２１を説明するフローチャートである。 ロールバック処理Ｓ６４３を説明するフローチャートである。 アプリケーション移動処理Ｓ６４４を説明するフローチャートである。
図１Ａに実施形態として説明する仮想化システムを実現するために用いられるハードウエア環境を示している。同図に示すように、このハードウエア環境は、管理サーバ１０と、通信ネットワーク５を介して管理サーバ１０と通信可能に接続し管理サーバ１０によって監視される一台以上の物理サーバ２０と、物理サーバ２０がアクセス可能な記憶装置３０とを含んで構成されている。
管理サーバ１０と物理サーバ２０とを結ぶ通信ネットワーク５は、例えばＬＡＮ（Local Area Network）である。物理サーバ２０及び記憶装置３０は、例えばＬＡＮやＳＡＮ（Storage Area Network）を介して通信可能に接続される。記憶装置３０は、例えばディスクアレイ装置やＮＡＳ（Network Attached Storage）である。
管理サーバ１０又は物理サーバ２０は、例えばパーソナルコンピュータ、ブレードサーバに装着されたブレード、ワークステーション、メインフレーム等のコンピュータ（情報処理装置）である。図１Ｂに管理サーバ１０又は物理サーバ２０として用いられるコンピュータの一例を示す。同図に示すコンピュータ１００は、中央処理装置１０１（例えばＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit））、主記憶装置１０２（例えばＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory））、補助記憶装置１０３（例えばハードディスク）、ユーザの操作入力を受け付ける入力装置１０４（例えばキーボードやマウス）、出力装置１０５（例えば液晶モニタ）、通信ネットワーク５を介して他の装置との間の通信を実現する通信インタフェース１０６（例えばＮＩＣ（Network Interface Card））を備えている。
＜管理サーバ１０＞
図２Ａに管理サーバ１０において実現される機能、及び管理サーバ１０によって管理されるデータを示す。尚、同図における各機能は、管理サーバ１０の中央処理装置１０１が主記憶装置１０２又は補助記憶装置１０３に格納されているプログラムを読み出して実行することにより、もしくは管理サーバ１０のハードウエア自体の機能によって実現される。
同図に示すように、管理サーバ１０では、物理サーバ２０において発生した障害の原因を特定する機能（以下、障害監視部１１０と称する。）を実現するためのプログラムが実行されている。障害監視部１１０は、イベント履歴管理部１１１、マッピングテーブル管理部１１２、ユーザインタフェース部１１３、障害解析部１１４、ポリシーテーブル管理部１１５、解析履歴テーブル管理部１１６、対処テーブル管理部１１７、及び対処実行部１１８を備える。また管理サーバ１０は、イベント履歴テーブル１２１、稼働サーバマッピングテーブル１２２、解析履歴テーブル１２３、仮想サーバイベント解析ポリシーテーブル１２４、物理サーバイベント解析ポリシーテーブル１２５、対処テーブル１２６、アプリケーション管理テーブル１２７、ＳＬＡ定義テーブル１２８、リソース管理テーブル１２９、依存関係管理テーブル１３０、サーバ管理テーブル１３１、及びパッチ管理テーブル１３２を管理している。
図２Ａに示した機能のうち、イベント履歴管理部１１１は、物理イベント通知部２１３から送信されてくる情報に基づく物理サーバ２０に関するイベントの履歴（第２のイベント履歴）をイベント履歴テーブル１２１に登録する。またイベント履歴管理部１１１は、仮想イベント通知部２１２３から送信されてくる情報に基づく仮想サーバ２１２に関するイベントの履歴（第１のイベント履歴）をイベント履歴テーブル１２１に登録する。
図３Ａにイベント履歴テーブル１２１の一例を示す。同図における各レコードは、夫々、物理サーバ２０又は仮想サーバ２１２において発生した１つのイベントについてのイベント履歴である。各イベント履歴は、イベントが発生したサーバ（物理サーバ２０又は仮想サーバ２１２）を特定する情報が設定されるサーバ名３１１、イベントが発生した日時が設定される発生日時３１２、イベントが発生したプロセスを特定する情報が設定されるプロセス名３１３、エラーメッセージ等が設定されるメッセージ３１４、及び発生したイベントの種別（エラー（Error）、警告（Warning）、一般情報（Information））を示す情報が設定されるイベント種別３１５の各項目を有する。
尚、同図において、サーバ名３１１に先頭が「ｐ」で始まる名称が設定されているイベント履歴は、物理サーバ２０の物理イベント通知部２１３から送られてきたイベント履歴である。またサーバ名３１１に先頭が「ｖ」で始まる名称が設定されているイベント履歴は、仮想イベント通知部２１２３から送られてきたイベント履歴である。
このように、図３Ａのイベント履歴テーブル１２１には、物理イベント通知部２１３から通知されるイベント履歴と、仮想イベント通知部２１２３から通知されるイベント履歴の双方が含まれているが、これらは別のテーブルで管理されていても構わない。
図２Ａにおけるマッピングテーブル管理部１１２は、稼働サーバマッピングテーブル１２２を管理する。マッピングテーブル管理部１１２は、仮想化機構２１１に対して能動的又は受動的に稼働サーバマッピングテーブル１２２に登録すべき情報を取得し、取得した情報を稼働サーバマッピングテーブル１２２に反映する。
図３Ｂに稼働サーバマッピングテーブル１２２の一例を示す。稼働サーバマッピングテーブル１２２には、業務プロセス２１２２を特定する情報が設定されるプロセス名３２１、業務プロセス２１２２が実行されている仮想サーバ２１２を特定する情報が設定される仮想サーバ名３２２、仮想サーバ２１２を実現している物理サーバ２０を特定する情報が設定される物理サーバ名３２３、及び仮想サーバ２１２が稼働を開始した日時が設定される仮想サーバ稼働開始日時３２４が対応づけて登録されている。尚、稼働サーバマッピングテーブル１２２の内容は、例えば仮想サーバ２１２の移動（後述）があった際に更新される。
図２Ａのユーザインタフェース部１１３は、プログラムの起動や終了を指示する操作入力等、ユーザが入力装置１０４に対して行った操作入力を受け付ける。
図２Ａの障害解析部１１４は、業務プロセス２１２２に何らかの障害が発生するとイベント履歴テーブル１２１に登録されているイベント履歴を解析し、その解析結果を解析履歴テーブル１２３に登録する。
図２Ａにおけるポリシーテーブル管理部１１５は、仮想サーバイベント解析ポリシーテーブル１２４及び物理サーバイベント解析ポリシーテーブル１２５を管理する。これらのテーブルには、障害解析部１１４が障害の解析に際しイベント履歴テーブル１２１を検索する際に用いる検索条件（第１の検索条件、第２の検索条件）が登録されている。
図３Ｃに仮想サーバイベント解析ポリシーテーブル１２４の一例を示す。同図に示すように、仮想サーバイベント解析ポリシーテーブル１２４には、イベント履歴をイベント履歴テーブル１２１から検索する際の検索条件３３１、及び検索条件による検索結果に応じて設定される情報である原因箇所３３２を含んだ一つ以上のレコードが登録されている。ここで同図の１行目のレコードの検索条件３３１の内容は、イベント履歴テーブル１２１から、その仮想サーバ名３１１に特定のサーバ名（＄仮想サーバ＄）が設定され、かつ、メッセージ３１４に「connect error」（通信エラーを意味する。）という文字列を含むイベント履歴を検索するというものである。また２行目のレコードの検索条件３３１の内容は、イベント履歴テーブル１２１から、その仮想サーバ名３１１に特定のサーバ名（＄仮想サーバ＄）が設定され、かつ、プロセス名３１３に「aa」が設定され、かつ、メッセージ３１４に「エラー」という文字列を含むイベント履歴を検索するというものである。また３行目のレコードの検索条件３３１の内容は、イベント履歴テーブル１２１から、その仮想サーバ名３１１に特定のサーバ名（＄仮想サーバ＄）が設定され、かつ、プロセス名３１３に「bb」が設定され、かつ、メッセージ３１４に「fault」という文字列を含むイベント履歴を検索するというものである。また４行目のレコードの検索条件３３１の内容は、イベント履歴テーブル１２１から、その仮想サーバ名３１１に特定のサーバ名（＄仮想サーバ＄）が設定され、かつ、イベント種別３１５に「Error」が設定されているかもしくはメッセージ３１４に「エラー」という文字列を含むイベント履歴を検索するというものである。
図３Ｄは物理サーバイベント解析ポリシーテーブル１２５の一例である。このテーブルには、イベント履歴テーブル１２１からイベント履歴を検索する際の検索条件３４１、検索条件による検索結果に応じて設定される情報である原因箇所３４２、及びエラーレベルが設定されるエラーレベル３４３を含んだ一つ以上のレコードが登録されている。ここで同図の１行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１から、その物理サーバ名３１１に特定のサーバ名（＄物理サーバ＄）が設定され、かつ、プロセス名３１３に「bb」が設定され、かつ、イベント種別３１５に「Error」という文字列を含むイベント履歴を検索するというものである。また２行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１から、その物理サーバ名３１１に特定のサーバ名（＄物理サーバ＄）が設定され、かつ、プロセス名３１３に「aa」が設定され、かつ、メッセージ３１４に「error」という文字列を含むイベント履歴を検索するというものである。また３行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１から、その物理サーバ名３１１に特定のサーバ名（＄物理サーバ＄）が設定され、かつ、メッセージ３１４に「memory fault」という文字列を含むイベント履歴を検索するというものである。また４行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１から、その物理サーバ名３１１に特定のサーバ名（＄物理サーバ＄）が設定され、かつ、プロセス名３１３に「ee」が設定されているイベント履歴を検索するというものである。また５行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１から、その物理サーバ名３１１に特定のサーバ名（＄物理サーバ＄）が設定され、かつ、プロセス名３１３に「bb」が設定され、かつ、メッセージ３１４に「warning」という文字列を含むイベント履歴を検索するというものである。また６行目のレコードの検索条件３４１の内容は、イベント履歴テーブル１２１に特定の物理サーバ名（＄物理サーバ＄）が一つも含まれていなかった場合に「真」とするというものである。
図２Ａに示した解析履歴テーブル管理部１１６は、ユーザインタフェース部１１３から受け付けたユーザの操作入力に従い解析履歴テーブル１２３の内容を管理する。図３Ｅは解析履歴テーブル１２３の一例である。解析履歴テーブル１２３の各レコードは、障害解析部１１４がイベント履歴テーブル１２１から検索した仮想サーバに関する情報が記載される仮想サーバイベント３５１、障害解析部１１４がイベント履歴テーブル１２１から検索した物理サーバに関する情報が記載される物理サーバイベント３５２、及び仮想サーバイベント３５１又は物理サーバイベント３５２の内容に応じてその内容が設定される解析結果３５３の各項目が含まれる。
図２Ａに示した対処テーブル管理部１１７は、ユーザインタフェース部１１３から受け付けたユーザの操作入力に従って対処テーブル１２６の内容を管理する。図３Ｆは対処テーブル１２６の一例である。同図に示すように、対処テーブル１２６の各レコードは、エラーレベルが設定されるエラーレベル３６１、及びエラーレベル３６１に対応して設定された、障害に対する対処の内容が記述される対処３６２を含む複数のレコードからなる。
図２Ａにおける対処実行部１１８は、障害解析部１１４において解析された障害内容に応じた処理を実行する。尚、アプリケーション管理テーブル１２７、ＳＬＡ定義テーブル１２８、リソース管理テーブル１２９、依存関係管理テーブル１３０、サーバ管理テーブル１３１、及びパッチ管理テーブル１３２の詳細については後述する。
＜物理サーバ２０＞
図２Ｂに物理サーバ２０において実現される機能、及び物理サーバ２０によって管理されるデータを示している。尚、同図における各機能は、物理サーバ２０の中央処理装置１０１が主記憶装置１０２又は補助記憶装置１０３に格納されているプログラムを読み出して実行することにより、もしくは物理サーバ２０のハードウエア自体の機能によって実現される。
同図に示すように、物理サーバ２０は、仮想化機構２１１、仮想化機構２１１によって実現される一つ以上の仮想サーバ２１２、及び物理イベント通知部２１３を備える。また各仮想サーバ２１２ではオペレーティングシステム２１２１が動作し、オペレーティングシステム２１２１の制御下で業務プロセス２１２２及び仮想イベント通知部２１２３が実現されている。
同図に示す仮想化機構２１１は、物理サーバ２０によって提供されるリソースを仮想化（Virtualization）し、物理サーバ２０によって提供される物理資源（リソース）を、エンドユーザやアプリケーション、オペレーティングシステム等に対し、一つ以上の論理的な資源に見せかける機能を実現する。同図に示す複数の仮想サーバ２１２は、夫々が仮想化機構２１１によって実現される論理的な資源（仮想的なコンピュータ）であって、互いに他の仮想サーバから独立して動作することができる。
尚、仮想サーバ２１２は、物理サーバ２０の物理資源（ハードウエア）をベースとして動作するオペレーティングシステム（ホストＯＳ）でハードウエアのエミュレーション環境を実現し、その環境下で仮想サーバ２１２のオペレーティングシステム２１２１（ゲストＯＳ）を動作させる、いわゆるホストＯＳ方式によって実現してもよいし、ホストＯＳを介在せずに物理資源に直接エミュレーション環境を設け、その環境下でゲストＯＳを動作させる、いわゆる仮想マシンモニタ方式によって実現するようにしてもよい。また物理資源のエミュレート方式としては、物理資源を完全にエミュレートする完全仮想化方式を選択してもよいし、一部の物理資源のみをエミュレートする準仮想化方式を選択してもよい。
各仮想サーバ２１２に対応するメモリイメージ（仮想サーバイメージ）は、記憶装置３０に格納されている。仮想サーバ２１２を移動（仮想サーバ２１２と物理サーバ２０との対応関係の変更）する場合には、仮想サーバイメージを該当の物理サーバ２０に割当てられている記憶装置３０の記憶領域に展開することによって行うことができる。尚、上記移動は、例えば仮想化機構２１１の機能によって、もしくは管理サーバ１０からの指示に応じて行われる。
各仮想サーバ２１２ではオペレーティングシステム２１２１が動作し、業務プロセス２１２２や仮想イベント通知部２１２３は、オペレーティングシステム２１２１において動作する。
各仮想サーバ２１２において動作する仮想イベント通知部２１２３は、各仮想サーバ２１２でイベントが発生すると、これに対応したイベント履歴を、通信ネットワーク５を介して管理サーバ１０に通知する。
各物理サーバ２０で動作する物理イベント通知部２１３は、物理サーバ２０において発生したイベントに対応するイベント履歴を、通信ネットワーク５を介して管理サーバ１０に通知する。また物理イベント通知部２１３は、管理サーバ１０の対処実行部１１８から通信ネットワーク５を介して送られてくる（発生した障害に対する）対処処理の実行指示を受け付け、受け付けた実行指示に対応する対処処理を実行する。
＜処理説明＞
障害監視部１１０によって行われる処理を図４Ａに示すフローチャートとともに説明する。尚、以下の説明において、符号の前に付した「Ｓ」の文字はステップを意味する。
障害監視部１１０は、ユーザインタフェース部１１３がユーザから終了操作を受け付けたか否かをリアルタイムに監視する（Ｓ４１１）。ユーザから終了操作を受け付けた場合は（Ｓ４１１：ＹＥＳ）処理を終了する。終了操作を受け付けない場合は（Ｓ４１１：ＮＯ）Ｓ４１２に進む。
Ｓ４１２において、障害監視部１１０は、仮想サーバ２１２の業務プロセス２１２２における障害発生の有無を判断する。例えば仮想イベント通知部２１２３から業務プロセス２１２２の障害（エラー）に関する新たなイベント履歴を受信した場合に障害が発生したと判断する。また業務プロセス２１２２のエラーに関するイベント履歴がイベント履歴テーブル１２１に新たに登録された場合に障害が発生したと判断する。障害が発生したと判断した場合には（Ｓ４１２：ＹＥＳ）Ｓ４１３に進み、障害が発生していない場合は（Ｓ４１２：ＮＯ）Ｓ４１１に戻る。
Ｓ４１３において、障害解析部１１４は、障害の原因を特定するとともに発生した障害にエラーレベルを付与する処理（以下、解析処理と称する）を行う。図４Ｂに解析処理（Ｓ４１３）の詳細を示している。まず障害解析部１１４は、障害が発生している業務プロセス２１２２が実行されている仮想サーバ２１２に関するイベント履歴を、イベント履歴テーブル１２１から検索する（Ｓ４１３１）。ここでの検索は仮想サーバイベント解析ポリシーテーブル１２４に登録されている検索条件３３１(第１の検索条件）を用いて行われる。即ち上記検索は、障害発生と判断した契機となったイベント履歴に記述されている仮想サーバ名（例えば「vserver1」）を図３Ｃに示した検索条件３３１に記述されている変数「＄仮想サーバ＄」に設定することにより行われる。
尚、上記検索はＳ４１２において障害が発生したと判断する契機となったイベント履歴に記述されている、仮想サーバ２１２のサーバ名（仮想サーバ名）をキーとして行ってもよい。
例えばイベント履歴テーブル１２１の内容が図３Ａに示す内容であり、キーとなる仮想サーバ名が「vserver1」である場合には、同図の２行目及び５行目のイベント履歴が検索される。またキーとなる物理サーバ名が「pserver1」である場合には、これに対応する仮想サーバ名「vserver1」を稼働サーバマッピングテーブル１２２から取得し、取得した仮想サーバ名「vserver1」をキーとして２行目及び５行目のイベント履歴が検索される。尚、障害発生と判断した契機となったイベント履歴は検索対象から除外されるものとする。
ここでイベント履歴テーブル１２１に長期間分のイベント履歴が管理されている場合（例えばイベント履歴の削除周期が長い場合）には、障害発生と判断した契機となったイベント履歴のイベントの発生日時３１２を起点とする所定期間内（例えばイベント発生日時３１２の前後所定期間内）に発生したイベントのイベント履歴のみを検索対象とするようにしてもよい。また（障害発生と判断した契機となったイベント履歴から取得される）仮想サーバ名３２２や物理サーバ名３２３をキーとして稼働サーバマッピングテーブル１２２から取得できる仮想サーバ稼働開始日時３２４に設定されている日時を起点とする所定期間内（例えば仮想サーバ稼働開始日時３２４に設定されている日時からイベントの発生日時３１２に設定されている日時までの間）に発生したイベントのイベント履歴のみを検索対象とするようにしてもよい。このように、障害発生時の近傍のみに検索対象を絞ることで、解析の精度を向上することができる。
Ｓ４１３２では、障害解析部１１４はＳ４１３１の検索において仮想サーバ２１２に関するイベント履歴を一つ以上検索することができたか否かを判断する（Ｓ４１３２）。検索することができなかった場合は（Ｓ４１３２：ＮＯ）Ｓ４１３３に進み、検索することができた場合は（Ｓ４１３２：ＹＥＳ）Ｓ４１３４に進む。
Ｓ４１３３では、障害解析部１１４は、Ｓ４１２において障害発生と判断したイベント履歴の内容を、解析履歴テーブル１２３の仮想サーバイベント３５１として登録し、これに対応する解析結果３５３の原因箇所３５３１に「業務プロセス」を、またエラーレベル３５３２に「１」を登録する。その後は図４ＡのＳ４１４に進む。つまり障害解析部１１４は、Ｓ４１３１において仮想サーバ２１２のイベント履歴を検索することができなかったことをもって、障害の原因が業務プロセス２１２２にあると判断する。
Ｓ４１３４では、障害解析部１１４は、障害が発生している業務プロセス２１２２が実行されている物理サーバ２０に関するイベント履歴をイベント履歴テーブル１２１から検索する。
尚、上記イベント履歴が仮想サーバ２１２の仮想イベント通知部２１２３から通知されたものである場合には、当該イベント履歴に記述されているサーバ名（仮想サーバ名）に対応する物理サーバ名を稼働サーバマッピングテーブル１２２から取得し、取得したその物理サーバ名をキーとしてイベント履歴をイベント履歴テーブル１２１から検索する。例えば、イベント履歴テーブル１２１の内容が図３Ａに示す内容であり(同図では障害発生と判断した契機となったイベント履歴は省略している。）、キーとなる物理サーバ名が「pserver1」である場合には、１行目のイベント履歴が検索される。またキーとなるサーバ名が仮想サーバ「vserver1」である場合には、これに対応する物理サーバ名「pserver1」を稼働サーバマッピングテーブル１２２から取得し、取得した物理サーバ名「pserver1」をキーとして１行目のイベント履歴が検索される。
尚、サーバ名をキーとするのではなく、物理サーバイベント解析ポリシーテーブル１２５に登録されている検索条件（第２の検索条件）によって物理サーバ２０に関するイベント履歴を検索するようにしてもよい。この場合には、障害発生と判断した契機となったイベント履歴に記述されている物理サーバ名（例えば「pserver1」）を図３Ｄに示した検索条件に記述されている変数「＄物理サーバ＄」に設定して検索を行う。
前述と同様、イベント履歴テーブル１２１に長期間分のイベント履歴が管理されている場合（例えばイベント履歴の削除周期が長い場合）には、障害発生と判断した契機となったイベント履歴のイベントの発生日時３１２を起点とする所定期間内（例えばイベント発生日時３１２の前後所定期間内）に発生したイベントのイベント履歴のみを検索対象とするようにしてもよい。また（障害発生と判断した契機となったイベント履歴から取得される）仮想サーバ名３２２や物理サーバ名３２３をキーとして稼働サーバマッピングテーブル１２２から取得できる仮想サーバ稼働開始日時３２４に設定されている日時を起点とする所定期間内（例えば仮想サーバ稼働開始日時３２４に設定されている日時からイベントの発生日時３１２に設定されている日時までの間）に発生したイベントのイベント履歴のみを検索対象とするようにしてもよい。
Ｓ４１３５では、障害解析部１１４は、Ｓ４１３４の検索において物理サーバ２０に関するイベント履歴を一つ以上検索することができたか否かを判断する（Ｓ４１３５）。検索することができなかった場合は（Ｓ４１３５：ＮＯ）、Ｓ４１３６に進み、検索することができた場合は（Ｓ４１３５：ＹＥＳ）、Ｓ４１４７に進む。
Ｓ４１３６において、障害解析部１１４は、Ｓ４１２において障害発生と判断したイベント履歴の内容を、解析履歴テーブル１２３の物理サーバイベント３５２として登録し、これに対応する解析結果３５３の原因箇所３５３１に「仮想サーバ」を、エラーレベル３５３２に「２」を登録する。その後は図４ＡのＳ４１４に進む。つまり障害解析部１１４は、Ｓ４１３１において仮想サーバ２１２のイベント履歴を検索することはできたが、Ｓ４１３４において物理サーバ２０のイベント履歴を検索することができなかったので、障害の原因が仮想サーバ２１２にあると判断する。
Ｓ４１３７では、障害解析部１１４は、Ｓ４１３１において（第１の検索条件により）検索された仮想サーバ２１２のイベント履歴に対応する障害の原因箇所（第１の障害箇所）と、Ｓ４１３４において（第２の検索条件により）検索された物理サーバ２０のイベント履歴に対応する障害の原因箇所（第２の障害箇所）とが一致するか否かを判断する。ここで検索条件として仮想サーバイベント解析ポリシーテーブル１２４又は物理サーバイベント解析ポリシーテーブル１２５に登録されている検索条件を用いた場合には、イベント履歴に対応する上記障害の原因箇所は、仮想サーバイベント解析ポリシーテーブル１２４又は物理サーバイベント解析ポリシーテーブル１２５において、検索されたイベント履歴を検索した際に用いた検索条件に対応づけられている原因箇所３３２，３４２である。またイベント履歴に記述されている、仮想サーバ名や物理サーバ名をキーとしてイベント履歴を検索した場合、障害解析部１１４は、検索されたイベント履歴に記述されているメッセージ３１４やイベント種別３１５等に基づき、障害の原因箇所を特定する。原因箇所が一致する場合は（Ｓ４１３７：ＹＥＳ）Ｓ４１３８に進み、原因箇所が一致しない場合は（Ｓ４１３７：ＮＯ）Ｓ４１３６に進む。つまり障害解析部１１４は、Ｓ４１３１において仮想サーバ２１２のイベント履歴を、またＳ４１３４において物理サーバ２０のイベント履歴を検索することができたが、各イベント履歴の原因箇所が一致しなかったので、障害の原因が仮想サーバ２１２にあると判断する。
Ｓ４１３８では、障害解析部１１４は、Ｓ４１２において障害発生と判断したイベント履歴の内容を、解析履歴テーブル１２３の仮想サーバイベント３５１及び物理サーバイベント３５２として登録し、これらに対応する解析結果３５３の原因箇所３５３１に「物理サーバ」を、エラーレベル３５３２に「３」を登録する。その後は図４ＡのＳ４１４に進む。つまり障害解析部１１４は、Ｓ４１３１において仮想サーバ２１２のイベント履歴を検索することができ、Ｓ４１３４において物理サーバ２０のイベント履歴を検索することができ、しかもＳ４１３７の判断において各イベント履歴の原因箇所が一致したので、障害の原因が物理サーバ２０にある可能性が高いと判断する。
以上に説明した障害解析処理Ｓ４１３によれば、障害の原因が業務プロセス２１２２にあるのか、仮想サーバ２１２にあるのか、もしくは物理サーバ２０にあるのかを高い精度で容易かつ迅速に特定することができる。またリアルタイムに内容が更新されるイベント履歴テーブル１２１の内容に基づいて解析がなされるので障害が発生してから短期間に障害の原因を特定することができる。従って、緊急性を要する障害に対して有効に対応することができる。
図４ＡのＳ４１４では、ユーザインタフェース部１１３が、解析履歴テーブル１２３の内容を管理サーバ１０の出力装置１０５に出力する。ユーザインタフェース部１１３は、出力される解析履歴テーブル１２３の内容のうち解析結果３５３の編集環境を提供する。解析履歴テーブル管理部１１６は、編集された解析結果３５３の内容を解析履歴テーブル１２３に反映する。また解析履歴テーブル管理部１１６は、解析履歴テーブル１２３の編集内容を、仮想サーバイベント解析ポリシーテーブル１２４、又は物理サーバイベント解析ポリシーテーブル１２５に反映する。これにより仮想サーバイベント解析ポリシーテーブル１２４における検索条件３３１と原因箇所３３２の対応精度、又は物理サーバイベント解析ポリシーテーブル１２５における検索条件３４１、原因箇所３４２、及びエラーレベル３４３の対応精度が向上し、障害原因の解析精度を向上することができる。
＝障害対処＝
図４ＡのＳ４１５では、対処実行部１１８が、障害の原因に応じた処理（以下、障害対処処理Ｓ４１５と称する。）を行う。対処実行部１１８は、障害対処処理Ｓ４１５に際し、図２Ａに示したアプリケーション管理テーブル１２７、ＳＬＡ定義テーブル１２８、リソース管理テーブル１２９、依存関係管理テーブル１３０、サーバ管理テーブル１３１、及びパッチ管理テーブル１３２を用いる。まずこれらのテーブルの内容について説明する。
図３Ｇは上記テーブルのうちアプリケーション管理テーブル１２７の一例である。アプリケーション管理テーブル１２７には、仮想サーバ２１２において実行されるアプリケーションに関する情報が管理される。同図に示すように、アプリケーション管理テーブル１２７は、アプリケーション名が設定されるＡＰ名１２７１、ＡＰ名１２７１によって設定されているアプリケーションに対応するプロセスの名称が設定されるプロセス名１２７２、プロセス名１２７２に設定されているプロセス名１２７２に対応するプロセスの識別子が設定されるプロセスＩＤ１２７３、ＡＰ名１２７１に設定されているアプリケーションが動作している仮想サーバ２１２の名称が設定される仮想サーバ名１２７４、及び仮想サーバ名１２７４に設定されている仮想サーバ２１２のＳＬＡ（Service Level Agreement）の名称が設定される関連ＳＬＡ１２７５、の各項目を含む一つ以上のレコードで構成されている。
図３ＨはＳＬＡ定義テーブル１２８の一例である。ＳＬＡ定義テーブル１２８には個々のＳＬＡに関する情報が管理される。同図に示すように、ＳＬＡ定義テーブル１２８は、ＳＬＡの名称が設定されるＳＬＡ名１２８１、及びＳＬＡ名１２８１に設定されているＳＬＡの内容が設定されるＳＬＡ内容１２８２、の各項目を含む一つ以上のレコードで構成されている。
図３Ｉはリソース管理テーブル１２９の一例である。リソース管理テーブル１２９には、仮想サーバ２１２で実行されるソフトウエアが使用するリソースの量が管理される。同図に示すように、リソース管理テーブル１２９は、ソフトウエアの名称が設定されるＡＰ名１２９１、ＡＰ名１２９１に設定されているソフトウエアのプロセスの名称が設定されるプロセス名１２９２、プロセス名１２９２に設定されているプロセスが使用するメモリの容量が設定される使用メモリ量１２９３、及びプロセス名１２９２に設定されているプロセスが使用するディスクの容量が設定される使用ディスク量１２９４、の各項目を含む一つ以上のレコードで構成されている。
図３Ｊは依存関係管理テーブル１３０の一例である。依存関係管理テーブル１３０には、仮想サーバ２１２で動作する（インストールされている）、アプリケーション、ミドルウエア、ドライバ、オペレーティングシステム（ＯＳ）などのソフトウエアの種類間の依存関係（レイヤー構成）が管理される。同図に示すように、依存関係管理テーブル１３０は、仮想サーバ２１２の名称が設定される仮想サーバ名１３０１、及び仮想サーバ名１３０１に設定されている仮想サーバ名に対応する仮想サーバ２１２における依存関係が設定される構成情報１３０２、の各項目を含む一つ以上のレコードで構成されている。また同図に示すように、構成情報１３０２は、アプリケーション１３０２１、ミドルウエア１３０２２、ドライバ１３０２３、及びオペレーティングシステム１３０２４などのソフトウエアの種類間の依存関係を示す、階層化されたサブレコードを含む。
図３Ｋはサーバ管理テーブル１３１の一例である。サーバ管理テーブル１３１には、物理サーバ２０又は仮想サーバ２１２が保有している(提供可能な）リソースが管理される。同図に示すように、サーバ管理テーブル１３１は、物理サーバ２０及び仮想サーバ２１２の名称が設定されるサーバ名１３１１、サーバ名１３１１に設定されているサーバ名に対応する物理サーバ２０又は仮想サーバ２１２が保有しているプロセッサ（中央処理装置１０１）に関する情報（例えば、プロセッサの形式、種類（Ｘｅｏｎ（登録商標））、動作クロックや内部キャッシュ等の処理性能）が設定されるＣＰＵ１３１２、サーバ名１３１１に設定されているサーバ名に対応する物理サーバ２０又は仮想サーバ２１２が保有しているメモリ（主記憶装置１０２）に関する情報（容量、応答速度等）が設定されるメモリ１３１３、サーバ名１３１１に設定されているサーバ名に対応する物理サーバ２０又は仮想サーバ２１２が保有しているハードディスクドライブ（補助記憶装置１０３）に関する情報（容量、応答速度等）が設定されるＨＤＤ１３１４、及び物理サーバ２０又は仮想サーバ２１２が保有しているその他のリソースに関する情報１３１５、の各項目を含む一つ以上のレコードで構成されている。
図３Ｌはパッチ管理テーブル１３２の一例である。パッチ管理テーブル１３２には、仮想サーバ２１２にインストールされているソフトウエアのバージョンに関する情報が管理される。同図に示すように、パッチ管理テーブル１３２は、ソフトウエアの名称が設定されるソフトウエア名１３２１、ソフトウエア名１３２１が示すソフトウエアがインストールされている仮想サーバの名称を示す仮想サーバ名１３２２、ソフトウエア名１３２１が示すソフトウエアが更新された日付を示す更新日時１３２５、現在のバージョン（更新後のバージョン）の一つ前のバージョンが設定される更新前バージョン１３２３、更新後のバージョンが設定される更新後バージョン１３２４、の各項目を含む一つ以上のレコードで構成されている。
＜対処実行部＞
図５に図２Ａに示した対処実行部１１８が備える主な機能を示している。同図に示すように、対処実行部１１８は、障害対処処理Ｓ４１５に関する主な機能として、仮想サーバ２１２で実行されているソフトウエアを仮想サーバ２１２単位で他の仮想サーバに移動させる仮想サーバ移動処理部１１８１、仮想サーバ２１２で実行されているソフトウエアをアプリケーション単位で移動させるアプリケーション移動処理部１１８２、仮想サーバ２１２にインストールされているソフトウエアのバージョンをロールバックする（バージョン更新前の状態に戻す）ロールバック処理部１１８３、及び障害の原因がリソース不足であるか否かを判定するリソース不足判定部１１８４を備える。
＜障害対処処理＞
図６は障害対処処理Ｓ４１５の全体的な流れを説明するフローチャートである。以下、同図とともに障害対処処理Ｓ４１５について説明する。尚、以下の説明において、障害が発生している仮想サーバ２１２のことを障害仮想サーバ２１２と称し、障害仮想サーバ２１２を実現している物理サーバ２０のことを障害物理サーバ２０と称する。また障害仮想サーバ２１２において実行されている業務プロセス２１２２のことを障害業務プロセス２１２２と称する。障害仮想サーバ２１２と障害物理サーバ２０の対応は稼働サーバマッピングテーブル１２２から取得することができる。
まず対処実行部１１８は、解析履歴テーブル１２３（図３Ｅ）を参照し、障害仮想サーバ２１２に生じている障害の原因が、その障害仮想サーバ２１２を実現している障害物理サーバ２０のハードウエア障害であるか否かを判断する（Ｓ６１１）。ハードウエア障害である場合の例として、物理サーバ２０が備えるハードディスクドライブ１７１のディスクアクセスエラーがある。
対処実行部１１８は、障害の原因が障害物理サーバ２０のハードウエア障害である場合（Ｓ６１１：ＹＥＳ）、障害仮想サーバ２１２を障害物理サーバ２０から他の物理サーバ２０に移動させる処理（障害仮想サーバ２１２を実現する物理サーバ２０を変更する処理。以下、仮想サーバ移動処理Ｓ６２１と称する。）を行う。一方、障害の原因が障害物理サーバ２０のハードウエア障害でないと判断した場合には（Ｓ６１１：ＮＯ）、Ｓ６３１に進む。
＜仮想サーバ移動処理＞
図７は、仮想サーバ移動処理Ｓ６２１を説明するフローチャートである。仮想サーバ移動処理Ｓ６２１では、障害仮想サーバ２１２で実行されているソフトウエアを他の仮想サーバ２１２に移動させる（障害仮想サーバ２１２を実現している物理サーバ２０を変更する。）。以下、同図とともに仮想サーバ移動処理Ｓ６２１について説明する。
まず対処実行部１１８は、管理サーバ１０の管理対象である各仮想サーバ２１２で動作しているソフトウエアを依存関係管理テーブル１３０から取得し、リソース管理テーブル１２９から、各ソフトウエアが使用するリソース量を取得し、取得したリソース量を合計して各仮想サーバ２１２が使用するリソース量を求める（Ｓ７１１）。
次に対処実行部１１８は、サーバ管理テーブル１３１から、各仮想サーバ２１２が保有しているリソース量を取得し、これとＳ７１１で求めた管理対象である各仮想サーバ２１２が使用するリソース量から、各仮想サーバ２１２の空きリソース量を求める（Ｓ７１２）。
そして対処実行部１１８は、障害仮想サーバ２１２が使用するリソース量と、各仮想サーバ２１２の空きリソース量を比較することにより、障害仮想サーバ２１２を移動させることが可能な他の仮想サーバ２１２を検索する（Ｓ７１３）。移動先の仮想サーバ２１２が存在すれば（Ｓ７１３：ＹＥＳ）、対処実行部１１８は、障害仮想サーバ２１２のソフトウエアをその仮想サーバ２１２に移動させる（Ｓ７１４）。尚、移動先候補の仮想サーバ２１２が複数存在する場合には、例えばそのうちリソース量に最も余裕のある仮想サーバ２１２を選択する。一方、移動させることが可能な仮想サーバ２１２が存在しない場合には（Ｓ７１３：ＮＯ）、Ｓ７２１に進む。
Ｓ７２１では、対処実行部１１８は、仮想サーバ２１２を新規に作成可能か否か判断する（Ｓ７２１）。この判断は、例えばサーバ管理テーブル１３１やリソース管理テーブル１２９から取得できる、管理サーバ１０の管理対象である各物理サーバ２０が保有しているリソース量や各物理サーバ２０の空きリソース量に基づき判断する。
仮想サーバ２１２を新規に作成可能であれば（Ｓ７２１：ＹＥＳ）、仮想サーバ２１２を新規に作成し（Ｓ７２２）、障害仮想サーバ２１２のソフトウエアをその仮想サーバ２１２に移動させる（Ｓ７１４）。一方、そのような物理サーバ２０が存在しない場合には（Ｓ７２１：ＮＯ）、出力装置１０５にメッセージを表示するなどして障害仮想サーバ２１２を移動できない旨をユーザに通知する（Ｓ７２３）。
以上のように、管理サーバ１０は、障害の原因が物理サーバ２０のハードウエア障害であると判断すると、管理サーバ１０の管理対象である仮想サーバ２１２の夫々の空きリソース量を求め、求めた空きリソース量と障害仮想サーバ２１２で実行されているソフトウエアが使用するリソース量とを比較して、障害仮想サーバ２１２で実行されているソフトウエアを移動させることが可能な他の仮想サーバ２１２が存在するか否かを判断し、移動させることが可能な場合は、ソフトウエアを仮想サーバ２１２単位で他の仮想サーバ２１２に移動させる。
このように、以上の仕組みによれば、障害の原因が物理サーバ２０である場合は他の障害仮想サーバ２１２以外の仮想サーバ２１２にソフトウエアが自動的に移動させるので、障害発生時にスムーズに障害仮想サーバ２１２が行っていた処理を復旧させることができる。また空きリソースを有する他の仮想サーバ２１２（物理サーバ２０）を探して移動先とするので、仮想化システムが保有するリソースを有効に利用することができる。
また空きリソースを有する仮想サーバ２１２が見つからない場合には、新たな仮想サーバ２１２を作成可能か否か判断し、可能な場合は仮想サーバ２１２を新規に作成してそこに障害仮想サーバ２１２のソフトウエアを移動させるので、障害からの自動復旧をより確実に行うことができる。
再び図６に戻って説明を続ける。図６のＳ６１１において、障害の原因が障害物理サーバ２０のハードウエア障害でないと判断した場合（Ｓ６１１：ＮＯ）、対処実行部１１８は、イベント履歴テーブル１２１（図３Ａ）に、障害業務プロセス２１２２と同じ業務プロセス２１２２（プロセス名３１３が同じ業務プロセス２１２２）の履歴のうち、処理が正常終了している履歴（例えば、イベント種別３１５に「Information」が設定されている履歴）が存在するか否かを判断する（Ｓ６３１）。正常終了している履歴が存在する場合には（Ｓ６３１：ＹＥＳ）、Ｓ６４１に進む。一方、正常終了している履歴が存在しない場合には（Ｓ６３１：ＮＯ）、Ｓ６５１に進む。
Ｓ６４１では、対処実行部１１８は、パッチ管理テーブル１３２（図３Ｌ）に、その更新日時１３２５が、Ｓ６３１で検索された正常終了している履歴の発生日時３１２の後である、障害仮想サーバ２１２の更新履歴（以下、バージョン更新履歴と称する。）が存在するか否かを判断する。そのようなバージョン更新履歴が存在すれば（Ｓ６４１：ＹＥＳ）、Ｓ６４２に進み、存在しなければ（Ｓ６４１：ＮＯ）、Ｓ６５１に進む。
Ｓ６４２では、対処実行部１１８は、障害仮想サーバ２１２以外の仮想サーバ２１２において、障害業務プロセス２１２２と同じ業務プロセス２１２２の履歴のうち、Ｓ６３１で検索された正常終了している履歴の発生日時３１２の後に行われたバージョン更新履歴の後に正常終了している履歴（例えばイベント種別３１５に「Information」が設定されている履歴）が存在するか否かを判断する（Ｓ６４２）。そのような履歴が存在しない場合には（Ｓ６４１：ＮＯ）、Ｓ６４３に進んでバージョンを元に戻す処理（バージョンダウン処理。以下、ロールバック処理Ｓ６４３と称する。）を行う。即ち、この場合は最近行われたバージョン更新が原因で障害が発生したと推定されるので、対処実行部１１８は、バージョンを元に戻すための処理を行う。
図８はロールバック処理Ｓ６４３を説明するフローチャートである。まず対処実行部１１８は、依存関係管理テーブル１３０（図３Ｊ）から、障害業務プロセス２１２２が実現しているアプリケーションと依存関係のあるソフトウエア（図３Ｊの依存関係管理テーブル１３０では、ミドルウエア、ドライバ、オペレーティングシステム（ＯＳ））を取得する（Ｓ８１１）。
次に対処実行部１１８は、パッチ管理テーブル１３２（図３Ｌ）から、Ｓ８１１で取得した各ソフトウエアの障害発生時より前のバージョン（更新前バージョン６６３）を取得する（Ｓ８１２）。そして対処実行部１１８は、各ソフトウエアのバージョンを取得した更新前バージョン６３３にロールバックする（Ｓ８１３）。
一方、Ｓ６４２において、そのような履歴が存在する場合には（Ｓ６４２：ＹＥＳ）、Ｓ６４４に進み、対処実行部１１８は、障害仮想サーバ２１２で動作しているアプリケーションを他の仮想サーバ２１２に移動させる処理（以下、アプリケーション移動処理Ｓ６４４と称する。）を行う。即ち、この場合は最近行われたバージョン更新は必ずしも障害の原因ではないと推定されるので、ロールバックは行わないが、対処実行部１１８はアプリケーションを他の仮想サーバ２１２に移動させる。
図９はアプリケーション移動処理Ｓ６４４を説明するフローチャートである。まず対処実行部１１８は、依存関係管理テーブル１３０（図３Ｊ）から、障害業務プロセス２１２２が実現しているアプリケーションと依存関係のあるソフトウエア（図３Ｊの依存関係管理テーブル１３０では、ミドルウエア、ドライバ、オペレーティングシステム（ＯＳ））を取得する（Ｓ９１１）。尚、障害業務プロセス２１２２が実現しているアプリケーションは、障害業務プロセス２１２２のプロセス名３１３をキーとしてアプリケーション管理テーブル１２７を検索することにより特定する。
次にＳ９１１で取得した依存関係、アプリケーション管理テーブル１２７、依存関係管理テーブル１３０（図３Ｊ）、及びＳＬＡ定義テーブル１２８に基づき、アプリケーションの移動先となりうる仮想サーバ２１２の候補を検索する（Ｓ９１２）。
例えば障害業務プロセス２１２２のプロセス名が「ａａ」である場合、図３Ｇに示したアプリケーション管理テーブル１２７では、アプリケーション（ＡＰ０１）を移動することになる。この場合、図３Ｊの依存関係管理テーブル１３０では、アプリケーション（ＡＰ０１）は、ミドルウエア（ミドルウエア１）、ドライバ（ドライバ１）、及びオペレーティングシステム（ＯＳ１）という環境で動作するので、移動先の仮想サーバ２１２もそのような環境を備えている必要がある。またアプリケーション（ＡＰ０１）の関連ＳＬＡ１２７５には「ｓｌａ００１，ｓｌａ００３」が設定されているので、移動先の仮想サーバ２１２のミドルウエアもこれらのＳＬＡを満たしている必要がある。
次に対処実行部１１８は、Ｓ９１１で取得した各ソフトウエアが使用するリソース量をリソース管理テーブル１２９から取得する（Ｓ９１３）。
次に対処実行部１１８は、Ｓ９１２で検索した候補の仮想サーバ２１２の空きリソース量を、サーバ管理テーブル１３１から求める（Ｓ９１４）。尚、空きリソース量は例えば図７のＳ７１１で説明したのと同様の方法で取得する。
次に対処実行部１１８は、Ｓ９１３で取得した、Ｓ９１１で取得した各ソフトウエアが使用するリソース量と、Ｓ９１４で求めた、候補の仮想サーバ２１２の空きリソース量とを比較し、アプリケーションを移動させることが可能な仮想サーバ２１２が存在するか否かを判断する（Ｓ９１５）。
移動させることが可能な仮想サーバ２１２が存在する場合には（Ｓ９１５：ＹＥＳ）、障害仮想サーバ２１２のアプリケーションを移動させることが可能と判断した仮想サーバ２１２に移動する（Ｓ９１６）。移動させることが可能な仮想サーバ２１２が存在しない場合には（Ｓ９１５：ＮＯ）、障害仮想サーバ２１２のアプリケーションを移動することができない旨を、出力装置１０５を介してユーザに通知する（Ｓ９１７）。
以上のように、対処実行部１１８は、障害の原因が物理サーバ２０のハードウエア障害でないと判断した場合には、障害業務プロセス２１２２の実行履歴、及び障害業務プロセス２１２２を実現しているソフトウエアの更新履歴に基づき、当該ソフトウエアの更新が行われた後に障害業務プロセス２１２２が正常終了している実行履歴が存在するか否かを判断し、そのような実行履歴が存在しない場合は、ソフトウエアのバージョンをロールバックする。このように、本実施形態の管理サーバ１０は、障害の原因をより正確に特定して適切な対処を行うので、障害からの復旧を確実に行うことができる。
一方、正常終了している実行履歴が存在する場合には、障害業務プロセス２１２２（アプリケーション）を他の仮想サーバ２１２に移動させる。このように、本実施形態の管理サーバ１０は、障害の原因をより正確に特定してアプリケーション単位で移動を行うので、障害からの復旧を迅速かつ確実に行うことができる。
図６のＳ６５１について説明する。Ｓ６５１では、対処実行部１１８は、障害の原因がリソース不足であるか否かを判断する。リソース不足が原因であれば（Ｓ６５１：ＹＥＳ）、Ｓ６４４に進む。リソース不足が原因でなければ（Ｓ６５１：ＮＯ）、Ｓ６８１に進む。
ここでリソース不足が原因か否かの判断は、例えばリソース管理テーブル１２９及び依存関係管理テーブル１３０から、障害業務プロセス２１２２が使用するリソース量を求め、求めたリソース量と、例えばＳ７１１で説明した方法により求まる、障害物理サーバ２０の空きのリソース量とを比較することにより行う。
また正常終了した後に障害業務プロセス２１２２の更新履歴が存在しない場合には（Ｓ６４１：ＮＯ）、例えば次のようにしてリソース不足か否かを判断する。まず対処実行部１１８は、障害発生時点における障害仮想サーバ２１２での業務プロセス２１２２の実行多重度を取得する。一方、対処実行部１１８は、上記正常終了時における業務プロセス２１２２の実行多重度をイベント履歴テーブル１２１から取得する。そして対処実行部１１８は、例えば障害発生時の実行多重度が正常終了時の実行多重度よりも大であればリソース不足であると判断し、障害発生時の実行多重度が正常終了時の実行多重度以下であればリソース不足でないと判断する。
このように、対処実行部１１８は、リソース不足が障害の原因か否かを判断し、リソース不足が原因であると判断した場合には（Ｓ６５１：ＹＥＳ）、障害業務プロセス２１２２（アプリケーション）を他の仮想サーバ２１２に移動させる。このように、本実施形態の管理サーバ１０は、リソース不足が障害の原因であることを迅速に判断してアプリケーション単位で移動を行うので、障害からの復旧を迅速かつ確実に行うことができる。また対処実行部１１８は、リソース不足か否かの判断を、状況（（Ｓ６３１：ＮＯ）の場合か、（Ｓ６５１：ＮＯ）の場合か）に応じて最適な方法で行うので、障害からの復旧を迅速かつ確実に行うことができる。
図６のＳ６６１では、対処実行部１１８は、障害業務プロセス２１２２を再実行する。Ｓ６６２では、対処実行部１１８は、再実行の結果が正常終了か否かを判断する。正常終了であれば（Ｓ６６２：ＹＥＳ）、処理が終了する。正常終了でなければ（Ｓ６６２：ＮＯ）、対処実行部１１８は、対処が正常に終了しなかった旨を、出力装置１０５を介してユーザに通知する（Ｓ６８１）。尚、この通知に際し、例えば障害対処処理Ｓ４１５において行われた処理の経過情報（ログ情報）をユーザに通知するようにしてもよい。
尚、以上の実施形態の説明は本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明はその趣旨を逸脱することなく、変更、改良され得ると共に本発明にはその等価物が含まれることは勿論である。例えば、障害の原因に応じて設定されるエラーレベルは必ずしも以上に説明したものに限定される訳ではなく、ユーザがエラーレベルを任意に設定できるようにしてもよい。
１０ 管理サーバ
２０ 物理サーバ
３０ 記憶装置
１００ コンピュータ
１１１ イベント履歴管理部
１１２ マッピングテーブル管理部
１１３ ユーザインタフェース部
１１４ 障害解析部
１１５ ポリシーテーブル管理部
１１６ 解析履歴テーブル管理部
１１７ 対処テーブル管理部
１１８ 対処実行部
１２１ イベント履歴テーブル
１２２ 稼働サーバマッピングテーブル
１２３ 解析履歴テーブル
１２４ 仮想サーバイベント解析ポリシーテーブル
１２５ 物理サーバイベント解析ポリシーテーブル
１２６ 対処テーブル
１２７ アプリケーション管理テーブル
１２８ ＳＬＡ定義テーブル
１２９ リソース管理テーブル
１３０ 依存関係管理テーブル
１３１ サーバ管理テーブル
１３２ パッチ管理テーブル
２１１ 仮想化機構
２１２ 仮想サーバ
２１２１ オペレーティングシステム
２１２２ 業務プロセス
２１２３ 仮想イベント通知部
２１３ 物理イベント通知部

Claims (21)

  1. 物理サーバで動作する仮想化機構によって仮想サーバが実現される仮想化環境において生じる障害の解析方法であって、
    前記物理サーバと通信可能に接続される管理サーバが、
    前記仮想サーバと当該仮想サーバが実現されている前記物理サーバとの対応が登録されたマッピングテーブルを記憶し、
    前記物理サーバで生じたイベントの履歴である第２のイベント履歴と、前記仮想サーバで生じたイベントの履歴である第１のイベント履歴とを蓄積記憶し、
    前記仮想サーバで動作している業務プロセスの障害に関する前記イベントを受信すると、前記第１のイベント履歴のうち、当該イベントを発した仮想サーバに関するイベント履歴と、前記第２のイベント履歴のうち、前記マッピングテーブルから取得される、当該イベントを発した前記仮想サーバを実現している前記物理サーバに関するイベント履歴とを、前記蓄積記憶している前記イベント履歴から検索し、その検索結果に基づき障害の原因を特定し、
    前記第１のイベント履歴の検索に用いる第１の検索条件と第１の障害箇所とを対応づけた仮想サーバイベント解析ポリシーテーブル、及び前記第２のイベント履歴の検索に用いる第２の検索条件と第２の障害箇所とを対応づけた物理サーバイベント解析ポリシーテーブルを記憶し、
    蓄積記憶している前記イベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができない場合には、障害の原因が前記業務プロセスにあると特定し、
    前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができたが、前記第２のイベント履歴を検索することができなかった場合には、障害の原因が前記仮想サーバにあると特定し、
    前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴及び前記第２のイベント履歴を検索することができ、かつ、検索された前記第１のイベント履歴の検索に用いた前記第１の検索条件に対応づけられている前記第１の障害箇所と検索された前記第２のイベント履歴の検索に用いた前記第２の検索条件に対応づけられている前記第２の障害箇所とが一致しない場合には、障害の原因が前記仮想サーバにあると特定し、一致する場合には、障害の原因が前記物理サーバにあると特定すること
    を特徴とする障害の解析方法。
  2. 請求項１に記載の障害の解析方法であって、
    前記管理サーバは、
    特定した前記障害の原因と、当該特定に至る過程で該当する前記第１のイベント履歴を検索することができた前記第１の検索条件又は前記第２のイベント履歴を検索することができた前記第２の検索条件とを対応づけて記載した解析結果を出力し、
    前記解析結果の変更要求を受け付けて、受け付けた前記変更要求に基づき前記仮想サーバイベント解析ポリシーテーブルにおいて前記第１の検索条件に対応づけられている前記第１の障害箇所、又は物理サーバイベント解析ポリシーテーブルにおいて前記第２の検索条件に対応づけられている前記第２の障害箇所を変更すること
    を特徴とする障害の解析方法。
  3. 請求項１に記載の障害の解析方法であって、
    前記管理サーバは、前記蓄積記憶している前記イベント履歴のうち、前記業務プロセスについての前記イベント履歴の障害が発生した日時を起点とする所定期間内に発生したイベントについての前記イベント履歴のみを対象として前記検索を行うこと
    を特徴とする障害の解析方法。
  4. 請求項１に記載の障害の解析方法であって、
    前記管理サーバは、前記仮想化環境において前記仮想サーバの移動が行われた直近の日時を記憶し、
    前記管理サーバは、前記蓄積記憶している前記イベント履歴のうち、障害が発生した前記業務プロセスが動作している前記仮想サーバの移動が行われた日時を起点とする所定期間内に発生したイベントについての前記イベント履歴のみを対象として、前記検索を行うこと
    を特徴とする障害の解析方法。
  5. 請求項１に記載の障害の解析方法であって、
    前記管理サーバが、
    前記障害の原因が前記物理サーバのハードウエア障害であると判断した場合に、
    前記管理サーバの管理対象である前記仮想サーバの夫々の空きリソース量を求め、
    求めた前記空きリソース量と、前記マッピングテーブルから取得される、前記障害の原因となっている前記物理サーバが実現している前記仮想サーバである障害仮想サーバで実行されているソフトウエアが使用するリソース量とを比較して、前記障害仮想サーバで実行されているソフトウエアを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、移動させることが可能であると判断した場合に、前記ソフトウエアを、前記他の仮想サーバに移動させる
    ことを特徴とする障害の解析方法。
  6. 請求項５に記載の障害の解析方法であって、
    前記管理サーバは、
    前記判断において前記障害仮想サーバで実行されているソフトウエアを移動させることが可能な他の前記仮想サーバが存在しないと判断した場合に、
    前記管理サーバの管理対象である前記物理サーバの空きリソース量から、新規に仮想サーバを作成可能か否か判断し、
    作成可能と判断した場合は新規に仮想サーバを作成し、前記ソフトウエアを新規に作成した前記仮想サーバに移動させる
    ことを特徴とする障害の解析方法。
  7. 請求項１に記載の障害の解析方法であって、
    前記管理サーバが、
    前記仮想サーバの夫々で実行される前記業務プロセスの実行履歴、及び前記業務プロセスを実現するソフトウエアの更新履歴を管理し、
    前記障害の原因が前記物理サーバのハードウエア障害でないと判断した場合に、
    前記実行履歴及び前記更新履歴に基づき、受信した前記障害に関するイベントに拘わる前記業務プロセスが動作している前記仮想サーバである障害仮想サーバの業務プロセスについて、前記ソフトウエアの更新が行われた後に正常終了している実行履歴が存在するか否かを判断し、
    そのような実行履歴が存在しない場合は前記ソフトウエアのバージョンをロールバックして再起動する
    ことを特徴とする障害の解析方法。
  8. 請求項７に記載の障害の解析方法であって、
    前記管理サーバは、
    前記ソフトウエアの更新が行われた後に正常終了している実行履歴が存在するか否かの前記判断において、そのような実行履歴が存在する場合には、前記業務プロセスに対応するアプリケーションを実現するのに必要なリソース量と前記管理サーバの管理対象である前記仮想サーバの空きリソース量とを比較して、前記アプリケーションを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、存在する場合には、前記アプリケーションを前記他の仮想サーバに移動させる
    ことを特徴とする障害の解析方法。
  9. 請求項１に記載の障害の解析方法であって、
    前記管理サーバが、
    前記仮想サーバで実行される前記業務プロセスの実行履歴を管理し、
    前記障害の発生時点の後に前記業務プロセスについて正常終了した前記実行履歴が存在するか否かを判断し、
    前記正常終了した実行履歴が存在しない場合に、前記障害の原因がリソース不足であるか否かを判断し、
    リソース不足が原因である場合、前記業務プロセスに対応するアプリケーションを実現するのに必要なリソース量と前記管理サーバの管理対象である前記仮想サーバの空きリソース量とを比較して、前記アプリケーションを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、存在する場合に、前記アプリケーションを前記他の仮想サーバに移動させる
    ことを特徴とする障害の解析方法。
  10. 請求項９に記載の障害の解析方法であって、
    前記管理サーバは、
    前記障害の発生時点における前記業務プロセスの実行多重度と前記業務プロセスの正常実行時における実行多重度とを比較することにより前記障害の原因がリソース不足であるか否かを判断する
    ことを特徴とする障害の解析方法。
  11. 物理サーバで動作する仮想化機構によって仮想サーバが実現される仮想化環境において生じる障害の解析に用いられ、前記物理サーバの夫々と通信可能に接続される管理サーバであって、
    前記仮想サーバと当該仮想サーバが実現されている前記物理サーバとの対応が登録されたマッピングテーブルを記憶し、
    前記物理サーバで生じたイベントの履歴である第２のイベント履歴と、前記仮想サーバで生じたイベントの履歴である第１のイベント履歴とを蓄積記憶し、
    前記仮想サーバで動作している業務プロセスの障害に関する前記イベントを受信すると、前記第１のイベント履歴のうち、当該イベントを発した仮想サーバに関するイベント履歴と、前記第２のイベント履歴のうち、前記マッピングテーブルから取得される、当該イベントを発した前記仮想サーバを実現している前記物理サーバに関するイベント履歴とを、前記蓄積記憶している前記イベント履歴から検索し、その検索結果に基づき障害の原因を特定し、
    前記第１のイベント履歴の検索に用いる第１の検索条件と第１の障害箇所とを対応づけた仮想サーバイベント解析ポリシーテーブル、及び前記第２のイベント履歴の検索に用いる第２の検索条件と第２の障害箇所とを対応づけた物理サーバイベント解析ポリシーテーブルを記憶し、
    蓄積記憶している前記イベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができない場合には、障害の原因が前記業務プロセスにあると特定し、
    前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができたが、前記第２のイベント履歴を検索することができなかった場合には、障害の原因が前記仮想サーバにあると特定し、
    前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴及び前記第２のイベント履歴を検索することができ、かつ、検索された前記第１のイベント履歴の検索に用いた前記第１の検索条件に対応づけられている前記第１の障害箇所と検索された前記第２のイベント履歴の検索に用いた前記第２の検索条件に対応づけられている前記第２の障害箇所とが一致しない場合には、障害の原因が前記仮想サーバにあると特定し、一致する場合には、障害の原因が前記物理サーバにあると特定する
    ことを特徴とする管理サーバ。
  12. 請求項１１に記載の管理サーバであって、
    特定した前記障害の原因と、当該特定に至る過程で該当する前記第１のイベント履歴を検索することができた前記第１の検索条件又は前記第２のイベント履歴を検索することができた前記第２の検索条件とを対応づけて記載した解析結果を出力し、
    前記解析結果の変更要求を受け付けて、受け付けた前記変更要求に基づき前記仮想サーバイベント解析ポリシーテーブルにおいて前記第１の検索条件に対応づけられている前記第１の障害箇所、又は物理サーバイベント解析ポリシーテーブルにおいて前記第２の検索条件に対応づけられている前記第２の障害箇所を変更すること
    を特徴とする管理サーバ。
  13. 請求項１１に記載の管理サーバであって、
    前記蓄積記憶している前記イベント履歴のうち、前記業務プロセスについての前記イベント履歴の障害が発生した日時を起点とする所定期間内に発生したイベントについての前記イベント履歴のみを対象として前記検索を行う
    ことを特徴とする管理サーバ。
  14. 請求項１１に記載の管理サーバであって、
    前記仮想化環境において前記仮想サーバの移動が行われた直近の日時を記憶し、
    前記蓄積記憶している前記イベント履歴のうち、障害が発生した前記業務プロセスが動作している前記仮想サーバの移動が行われた日時を起点とする所定期間内に発生したイベントについての前記イベント履歴のみを対象として、前記検索を行うこと
    を特徴とする管理サーバ。
  15. 請求項１１に記載の管理サーバであって、
    前記障害の原因が前記物理サーバのハードウエア障害であると判断した場合に、
    前記管理サーバの管理対象である前記仮想サーバの夫々の空きリソース量を求め、
    求めた前記空きリソース量と、前記マッピングテーブルから取得される前記物理サーバが実現している前記仮想サーバである障害仮想サーバで実行されているソフトウエアが使用するリソース量とを比較して、前記障害仮想サーバで実行されているソフトウエアを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、移動させることが可能であると判断した場合に、前記ソフトウエアを、前記他の仮想サーバに移動させる
    ことを特徴とする管理サーバ。
  16. 請求項１５に記載の管理サーバであって、
    前記判断において前記障害仮想サーバで実行されているソフトウエアを移動させることが可能な他の前記仮想サーバが存在しないと判断した場合に、
    前記管理サーバの管理対象である前記物理サーバの空きリソース量から、新規に仮想サーバを作成可能か否か判断し、
    作成可能と判断した場合は新規に仮想サーバを作成し、前記ソフトウエアを新規に作成した前記仮想サーバに移動させる
    ことを特徴とする管理サーバ。
  17. 請求項１１に記載の管理サーバであって、
    前記仮想サーバの夫々で実行される前記業務プロセスの実行履歴、及び前記業務プロセスを実現するソフトウエアの更新履歴を管理し、
    前記障害の原因が前記物理サーバのハードウエア障害でないと判断した場合に、
    前記実行履歴及び前記更新履歴に基づき、受信した前記障害に関するイベントに拘わる前記業務プロセスが動作している前記仮想サーバである障害仮想サーバの業務プロセスについて、前記ソフトウエアの更新が行われた後に正常終了している実行履歴が存在するか否かを判断し、
    そのような実行履歴が存在しない場合は前記ソフトウエアのバージョンをロールバックして再起動する
    ことを特徴とする管理サーバ。
  18. 請求項１７に記載の管理サーバであって、
    前記ソフトウエアの更新が行われた後に正常終了している実行履歴が存在するか否かの前記判断において、そのような実行履歴が存在する場合には、前記業務プロセスに対応するアプリケーションを実現するのに必要なリソース量と前記管理サーバの管理対象である前記仮想サーバの空きリソース量とを比較して、前記アプリケーションを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、存在する場合には、前記アプリケーションを前記他の仮想サーバに移動させる
    ことを特徴とする管理サーバ。
  19. 請求項１１に記載の管理サーバであって、
    前記仮想サーバで実行される前記業務プロセスの実行履歴を管理し、
    前記障害の発生時点の後に前記業務プロセスについて正常終了した前記実行履歴が存在するか否かを判断し、
    前記正常終了した実行履歴が存在しない場合に、前記障害の原因がリソース不足であるか否かを判断し、
    リソース不足が原因である場合、前記業務プロセスに対応するアプリケーションを実現するのに必要なリソース量と前記管理サーバの管理対象である前記仮想サーバの空きリソース量とを比較して、前記アプリケーションを移動させることが可能な他の前記仮想サーバが存在するか否かを判断し、存在する場合に、前記アプリケーションを前記他の仮想サーバに移動させる
    ことを特徴とする管理サーバ。
  20. 請求項１９に記載の管理サーバであって、
    前記障害の発生時点における前記業務プロセスの実行多重度と前記業務プロセスの正常実行時における実行多重度とを比較することにより前記障害の原因がリソース不足であるか否かを判断する
    ことを特徴とする管理サーバ。
  21. 物理サーバで動作する仮想化機構によって仮想サーバが実現される仮想化環境において生じる障害の解析に用いられ、前記物理サーバの夫々と通信可能に接続される管理サーバに、
    前記仮想サーバと当該仮想サーバが実現されている前記物理サーバとの対応が登録されたマッピングテーブルを記憶する機能と、
    前記物理サーバで生じたイベントの履歴である第２のイベント履歴と、前記仮想サーバで生じたイベントの履歴である第１のイベント履歴とを蓄積記憶する機能と、
    前記仮想サーバで動作している業務プロセスの障害に関する前記イベントを受信すると、前記第１のイベント履歴のうち、当該イベントを発した仮想サーバに関するイベント履歴と、前記第２のイベント履歴のうち、前記マッピングテーブルから取得される、当該イベントを発した前記仮想サーバを実現している前記物理サーバに関するイベント履歴とを、前記蓄積記憶している前記イベント履歴から検索し、その検索結果に基づき障害の原因を特定する機能と、
    前記第１のイベント履歴の検索に用いる第１の検索条件と第１の障害箇所とを対応づけた仮想サーバイベント解析ポリシーテーブル、及び前記第２のイベント履歴の検索に用いる第２の検索条件と第２の障害箇所とを対応づけた物理サーバイベント解析ポリシーテーブルを記憶する機能と、
    蓄積記憶している前記イベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができない場合には、障害の原因が前記業務プロセスにあると特定する機能と、
    前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴を検索することができたが、前記第２のイベント履歴を検索することができなかった場合には、障害の原因が前記仮想サーバにあると特定する機能と、
    前記蓄積記憶しているイベント履歴から、前記仮想サーバイベント解析ポリシーテーブルに登録されている前記第１の検索条件に該当する前記第１のイベント履歴を検索するとともに、前記物理サーバイベント解析ポリシーテーブルに登録されている前記第２の検索条件に該当する前記第２のイベント履歴を検索し、その結果、該当する前記第１のイベント履歴及び前記第２のイベント履歴を検索することができ、かつ、検索された前記第１のイベント履歴の検索に用いた前記第１の検索条件に対応づけられている前記第１の障害箇所と検索された前記第２のイベント履歴の検索に用いた前記第２の検索条件に対応づけられている前記第２の障害箇所とが一致しない場合には、障害の原因が前記仮想サーバにあると特定し、一致する場合には、障害の原因が前記物理サーバにあると特定する機能と
    を実現するためのプログラム。
JP2009135441A 2008-09-04 2009-06-04 仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラム Expired - Fee Related JP5140633B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2009135441A JP5140633B2 (ja) 2008-09-04 2009-06-04 仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラム
US12/551,962 US8006134B2 (en) 2008-09-04 2009-09-01 Method for analyzing fault caused in virtualized environment, and management server

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2008227401 2008-09-04
JP2008227401 2008-09-04
JP2009135441A JP5140633B2 (ja) 2008-09-04 2009-06-04 仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラム

Publications (2)

Publication Number Publication Date
JP2010086516A JP2010086516A (ja) 2010-04-15
JP5140633B2 true JP5140633B2 (ja) 2013-02-06

Family

ID=41727069

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009135441A Expired - Fee Related JP5140633B2 (ja) 2008-09-04 2009-06-04 仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラム

Country Status (2)

Country Link
US (1) US8006134B2 (ja)
JP (1) JP5140633B2 (ja)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7962798B2 (en) * 2006-04-17 2011-06-14 The Trustees Of Columbia University In The City Of New York Methods, systems and media for software self-healing
US8924782B2 (en) * 2007-01-26 2014-12-30 The Trustees Of Columbia University In The City Of New York Systems, methods, and media for recovering an application from a fault or attack
US8635318B1 (en) * 2009-09-15 2014-01-21 Symantec Corporation Message broadcast protocol which handles configuration changes in a cluster of virtual servers
US8392760B2 (en) * 2009-10-14 2013-03-05 Microsoft Corporation Diagnosing abnormalities without application-specific knowledge
US8381033B2 (en) * 2009-10-30 2013-02-19 International Business Machines Corporation Fault management in virtual computing environments
US8245083B2 (en) * 2009-12-24 2012-08-14 At&T Intellectual Property I, L.P. Systems, methods, and apparatus to debug a network application
US8352799B2 (en) * 2010-02-12 2013-01-08 Symantec Corporation Data corruption prevention during application restart and recovery
JP5417264B2 (ja) * 2010-06-21 2014-02-12 株式会社日立製作所 分析情報提供方法
WO2012066640A1 (ja) * 2010-11-16 2012-05-24 株式会社日立製作所 計算機システム、マイグレーション方法及び管理サーバ
US9189308B2 (en) 2010-12-27 2015-11-17 Microsoft Technology Licensing, Llc Predicting, diagnosing, and recovering from application failures based on resource access patterns
FR2977691B1 (fr) * 2011-07-08 2013-07-12 Bull Sas Procede et programme d'ordinateur de gestion dynamique de services dans un cluster d'administration
US9026837B2 (en) * 2011-09-09 2015-05-05 Microsoft Technology Licensing, Llc Resource aware placement of applications in clusters
US8819490B2 (en) * 2011-12-30 2014-08-26 Microsoft Corporation Test execution spanning cloud and local devices
WO2013171807A1 (en) * 2012-05-18 2013-11-21 Hitachi, Ltd. Management system and management method
CN102902599B (zh) 2012-09-17 2016-08-24 华为技术有限公司 虚拟机内部故障处理方法、装置及系统
WO2014073046A1 (ja) * 2012-11-07 2014-05-15 富士通株式会社 情報処理装置、プログラムおよび仮想マシン移動方法
US9608933B2 (en) * 2013-01-24 2017-03-28 Hitachi, Ltd. Method and system for managing cloud computing environment
BR112016006902B1 (pt) * 2013-09-30 2022-10-04 Huawei Technologies Co.,Ltd Método de gerenciamento de falhas e gerenciador de funções de rede virtualizada
WO2015072004A1 (ja) * 2013-11-15 2015-05-21 株式会社日立製作所 計算機、計算機制御方法、および計算機制御プログラム
JP6207357B2 (ja) * 2013-11-20 2017-10-04 三菱電機株式会社 情報処理装置及びプログラム
US9519513B2 (en) * 2013-12-03 2016-12-13 Vmware, Inc. Methods and apparatus to automatically configure monitoring of a virtual machine
US9678731B2 (en) 2014-02-26 2017-06-13 Vmware, Inc. Methods and apparatus to generate a customized application blueprint
JP6233107B2 (ja) * 2014-03-10 2017-11-22 富士通株式会社 情報蓄積プログラム、情報蓄積方法、情報蓄積装置、および情報蓄積システム
JP6528381B2 (ja) * 2014-10-06 2019-06-12 富士通株式会社 ログ管理装置，ログ管理プログラム，及びログ管理方法
JP6418255B2 (ja) * 2015-02-06 2018-11-07 日本電気株式会社 障害監視装置、仮想ネットワークシステム、障害監視方法およびプログラム
JP5982513B2 (ja) * 2015-02-17 2016-08-31 株式会社日立製作所 監視計算機及び方法
JP6493017B2 (ja) * 2015-06-26 2019-04-03 セイコーエプソン株式会社 ネットワークシステム、サーバー、及び、ネットワークシステムの制御方法
JP6748411B2 (ja) * 2015-08-31 2020-09-02 キヤノン株式会社 情報処理装置、情報処理装置の制御方法、及び、プログラム
CN107203451B (zh) * 2016-03-18 2020-09-18 伊姆西Ip控股有限责任公司 用于在存储系统中处理故障的方法及设备
JP6801267B2 (ja) 2016-07-04 2020-12-16 富士通株式会社 評価プログラム、評価方法、評価装置および情報処理装置
JP6655497B2 (ja) * 2016-07-29 2020-02-26 株式会社日立製作所 運用管理装置及び運用管理方法、並びに運用管理システム
EP3632086B1 (en) * 2017-05-23 2023-08-09 Constructive Labs Server system for processing a virtual space
CN111125164A (zh) * 2018-10-30 2020-05-08 千寻位置网络有限公司 参考站故障排查的方法及系统、排障终端
EP3767464B1 (en) * 2019-07-19 2024-04-17 Ricoh Company, Ltd. Information processing system, information processing apparatus, information processing method, and program
US11789802B2 (en) * 2019-07-31 2023-10-17 Jio Platforms Limited System and method of mapping and diagnostics of data center resources
US11281522B2 (en) * 2019-08-30 2022-03-22 Microsoft Technology Licensing, Llc Automated detection and classification of dynamic service outages
US11175947B2 (en) 2019-12-03 2021-11-16 International Business Machines Corporation Microservices change management and analytics
JP7216767B2 (ja) * 2021-05-06 2023-02-01 楽天グループ株式会社 アクセス方法、通信システム、及びプログラム
US20230088318A1 (en) * 2021-09-20 2023-03-23 International Business Machines Corporation Remotely healing crashed processes

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH041834A (ja) * 1990-04-19 1992-01-07 Nec Corp 入出力装置のエラー情報収集方法およびその装置
JPH04257035A (ja) 1991-02-12 1992-09-11 Fujitsu Ltd 仮想計算機システム配下における障害情報処理方式
JP2000181759A (ja) * 1998-12-15 2000-06-30 Hitachi Information Systems Ltd 時系列データ検索システムと検索方法およびそのプログラムを記録した記録媒体
JP2002073361A (ja) * 2000-08-28 2002-03-12 Ando Electric Co Ltd 遠隔ソフトウエア更新可能な電子機器及び遠隔ソフトウエア更新方法。
JP2003085003A (ja) * 2001-09-06 2003-03-20 Matsushita Electric Ind Co Ltd 障害復旧援助方法、及び、障害復旧援助システム
US7409583B2 (en) * 2002-10-07 2008-08-05 Hitachi, Ltd. Volume and failure management method on a network having a storage device
JP4130615B2 (ja) * 2003-07-02 2008-08-06 株式会社日立製作所 ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ
JP4202709B2 (ja) * 2002-10-07 2008-12-24 株式会社日立製作所 ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法
JP4294353B2 (ja) * 2003-03-28 2009-07-08 株式会社日立製作所 ジョブ管理機能を有するストレージ系障害管理方法及び装置
JP2004355265A (ja) * 2003-05-28 2004-12-16 Ntt Docomo Inc 処理統括装置、及び、処理判定方法
DE102004005128B3 (de) * 2004-02-02 2005-01-05 Fujitsu Siemens Computers Gmbh Anordnung mehrerer Rechner und Verfahren zum Betreiben einer Anordnung mehrerer Rechner bei einem Rechnerausfall
JP4570527B2 (ja) * 2005-07-20 2010-10-27 富士通株式会社 システム性能監視プログラム及びシステム性能監視方法
JP4736783B2 (ja) * 2005-12-19 2011-07-27 株式会社日立製作所 ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法
JP4609380B2 (ja) * 2006-05-31 2011-01-12 日本電気株式会社 仮想サーバ管理システムおよびその方法ならびに管理サーバ装置
US7814364B2 (en) * 2006-08-31 2010-10-12 Dell Products, Lp On-demand provisioning of computer resources in physical/virtual cluster environments
JP4172807B2 (ja) * 2006-09-08 2008-10-29 インターナショナル・ビジネス・マシーンズ・コーポレーション 障害発生の原因箇所の発見を支援する技術
JP4923990B2 (ja) * 2006-12-04 2012-04-25 株式会社日立製作所 フェイルオーバ方法、およびその計算機システム。
JP4744480B2 (ja) * 2007-05-30 2011-08-10 株式会社日立製作所 仮想計算機システム
JP2008059599A (ja) * 2007-09-28 2008-03-13 Hitachi Ltd 仮想化されたリソースの割当て方法及びその実施システム
US7840839B2 (en) * 2007-11-06 2010-11-23 Vmware, Inc. Storage handling for fault tolerance in virtual machines
JP4958739B2 (ja) * 2007-11-09 2012-06-20 株式会社日立製作所 障害の発生した記憶装置に記憶されているデータを修復するストレージシステム
JP5091704B2 (ja) * 2008-02-06 2012-12-05 株式会社日立製作所 ストレージ構成回復方法及びストレージ管理システム

Also Published As

Publication number Publication date
US20100058108A1 (en) 2010-03-04
US8006134B2 (en) 2011-08-23
JP2010086516A (ja) 2010-04-15

Similar Documents

Publication Publication Date Title
JP5140633B2 (ja) 仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラム
CN104272266B (zh) 对具有多个监视对象器件的计算机系统进行管理的管理系统
JP5440273B2 (ja) スナップショット管理方法、スナップショット管理装置、及びプログラム
JP5427011B2 (ja) 仮想ハードディスクの管理サーバおよび管理方法、管理プログラム
US10191879B2 (en) System and method for creating snapshots in openflame environment
US9652326B1 (en) Instance migration for rapid recovery from correlated failures
JP4980792B2 (ja) 仮想計算機の性能監視方法及びその方法を用いた装置
JP5032191B2 (ja) サーバ仮想化環境におけるクラスタシステム構成方法及びクラスタシステム
US10909000B2 (en) Tagging data for automatic transfer during backups
US11256576B2 (en) Intelligent scheduling of backups
JP2011128967A (ja) 仮想計算機の移動方法、仮想計算機システム及びプログラム
JP6190468B2 (ja) 管理システム、プラン生成方法、およびプラン生成プログラム
US11675674B2 (en) Instant recovery of databases
US11874851B2 (en) Contextual replication profile creation based on data criticality
US20210224121A1 (en) Virtual machine-initiated workload management
JP5597293B2 (ja) 計算機システム及びプログラム
US20180287914A1 (en) System and method for management of services in a cloud environment
JP5684640B2 (ja) 仮想環境管理システム
US11799963B1 (en) Method and system for identifying user behavior based on metadata
EP3382555A1 (en) System and method for management of services in a cloud environment
JP5390651B2 (ja) 計算機システム及びプログラム
US11714701B2 (en) Troubleshooting for a distributed storage system by cluster wide correlation analysis
US20230161733A1 (en) Change block tracking for transfer of data for backups
US20240248762A1 (en) Method and system for identifying a holistic profile of a user based on metadata
JP5993052B2 (ja) 複数の監視対象デバイスを有する計算機システムの管理を行う管理システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110216

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120516

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120522

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120705

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120814

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120821

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121012

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: 20121030

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: 20121119

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151122

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees