JPWO2012070294A1 - 可用性評価装置及び可用性評価方法 - Google Patents

Abstract

ライブラリとして標準的に用意されているサーバインフラの可用性評価モデルにデータセンタ運用手順に起因する状態遷移を追加するカスタマイズを行う際の作業負荷を軽減する。システムの構成に応じた複数の状態遷移の定義を状態遷移記憶部に記憶し、複数の状態遷移とは異なる、システムを運用する際の状態遷移の定義を追加状態遷移記憶部に記憶し、システムを運用する際の状態遷移の定義を受け付けて追加状態遷移記憶部に登録し、状態遷移記憶部に記憶されている状態遷移の定義と、追加状態遷移記憶部に記憶されている状態遷移の定義とに基づいて、システムの可用性を分析し、追加状態遷移記憶部に記憶されている、システムを運用する際の複数の状態遷移の定義の中の少なくとも一部の状態遷移の定義における共通の状態遷移のパターンを分析し、共通の状態遷移のパターンの分析結果を出力する。

Description

本発明は、可用性評価装置及び可用性評価方法に関する。

近年、多数のテナント企業に対してオンラインでサーバインフラ（仮想マシンや物理サーバ）を提供するデータセンタサービスが普及しつつある。このようなサービスを提供する場合、各テナントから要求されたサービスレベルが満たされるように、システムの可用性を評価することが重要となる。システムの可用性評価にあたっては、データセンタ管理者が、あらかじめ用意されたサーバインフラのための可用性評価モデルをもとに、テナントからのサービスレベルの要件や利用特性に応じた設定変更、再起動などのデータセンタ運用手順等を加味して可用性評価モデルをカスタマイズする。そして、カスタマイズされた可用性評価モデルに基づいて可用性の算出や検証が行われる。

このように可用性を評価する際に用いられる可用性評価モデルを管理するシステムに関する技術の例が、特許文献１〜４に開示されている。例えば、特許文献１には、システムを構成する個々のコンピュータにおいて障害が発生する割合や障害の修復にかかる時間等のシステムの特性に関する情報と稼働中の障害に関する監視情報とをもとに、システム全体の稼働率を予測する方法が開示されている。また、特許文献２には、ソフトウェア及びハードウェアに係わるシステム構成情報から故障の判定を行うためのフォールトツリー（Ｆａｕｌｔ Ｔｒｅｅ）を形成し、フォールトツリーに基づいて算出される故障率が基準値を満たしているかどうか分析する方法が開示されている。また、特許文献３には、可用性をはじめとして、機能、構成、セキュリティ、性能等に関する情報をアプリケーションプログラムやアプリケーションサービスのインストール時にメタデータとして登録しておき、その後の構成管理、障害検出、診断、復旧等の分析にメタデータを用いる方法が開示されている。また、特許文献４には、故障が起こるたびに、故障が継続した時間と故障によりサービスを利用できなかった利用者数を記憶し、これらのデータを蓄積して、故障時間の割合、利用者１人あたりの故障を被った割合、稼働率などを推定する方法が開示されている。

特に、ハードウェアについては、フォールトツリーなどの数学的なモデルを用いて、システムを構成する部品の特性からシステム全体の故障の可能性を分析する方法が広く知られている。一方、ソフトウェアについては、確率的ペトリネット（Ｓｔｏｃｈａｓｔｉｃ Ｐｅｔｒｉ Ｎｅｔｗｏｒｋ）などの数学的なモデルで状態の遷移を記述し、シミュレーションで遷移を再現して可用性を分析する方法が一般的である。可用性（Ａｖａｉｌａｂｉｌｉｔｙ）は、ある一定期間のうち、利用者がサービスを利用できる割合を表す指標であり、稼働率と同義で用いられる。例えば、１日のうち平均的に１分だけ利用できない時間帯がある場合の可用性は、１−１÷（２４×６０）＝９９．９３％となる。一般に、可用性は、障害が発生する時間間隔（Ｍｅａｎ Ｔｉｍｅ Ｂｅｔｗｅｅｎ Ｆａｉｌｕｒｅ）と障害が復旧するまでの時間（Ｍｅａｎ Ｔｉｍｅ Ｔｏ Ｒｅｐａｉｒ）から決まる。

このような確率的ペトリネットの技術を用いて、可用性評価モデルから可用性の算出や検証を行う一例を説明する。図１３は、仮想マシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ：ＶＭとも表記する）の状態遷移を定義する確率的ペトリネットを示している。

確率的ペトリネットにおいて、各状態は、角の丸い長方形で表されている。ここでは、正常に運転している状態を指す「稼働中」の状態と、障害によって利用者がサービスを利用できない状態を表す「ユーザＶＭ停止中」の状態が定義されている。なお、ユーザＶＭとは、データセンタ管理者のみがアクセスできる仮想マシンの制御プログラムを指すハイパーバイザではなく、利用者に割り当てられて利用者がアクセスできる一般の仮想マシンのことである。

また、各遷移は、遷移を引き起こす事象を表す長方形と遷移の方向を表す矢印で表されている。ここでは、「障害発生」という事象によって「稼働中」から「ユーザＶＭ停止中」へ遷移が起こること、「障害復旧」という事象によって「ユーザＶＭ停止中」から「稼働中」へ遷移が起こることが定義されている。

図１３のような視覚的に分かりやすい表現は人間には理解しやすいが、コンピュータで確率的ペトリネットを分析する際には、図１４に示される表の形態で状態遷移を管理すると都合がよい。この表は状態遷移管理表と呼ばれる。状態遷移管理表には、事象ごとに、事象名、遷移元の状態名、遷移先の状態名、及び遷移確率が記載されている。例えば、０．０１５の確率で障害が発生し、仮想マシンが「稼働中」の状態にあれば、「ユーザＶＭ停止中」の状態に遷移する。

このような状態遷移管理表をもとに、シミュレーションで遷移を再現して可用性を分析することができる。その際には、図１５に示す状態表が用いられる。状態表には、状態名とトークン数が記載されている。シミュレーションでは、定義された状態にある仮想マシンが何台あるかを分析するために、各状態にある仮想マシンの数をトークンの数という概念に置き換える。例えば、仮想マシンが全部で１０台あり、全ての仮想マシンが稼動中であれば、「稼働中」の状態に１０個のトークンがあり、「ユーザＶＭ停止中」の状態に０個のトークンがあることとなる。そして、ある１台の仮想マシンにおいて状態遷移が起こると、１個のトークンが移動する。つまり、トークンの総数は不変である。例えば、シミュレーションを開始して、遷移確率にしたがって状態の遷移を起こしたところ、障害が２回発生したとする。この場合、図１５に示すように、「稼働中」の状態に８個のトークンがあり、「ユーザＶＭ停止中」の状態に２個のトークンが移動した状態となる。

そして、「ユーザＶＭ停止中」の状態に１個以上のトークンが存在する割合から可用性の値を算出することができる。なお、可用性の値は障害、または、稼動の定義に依存して変化する。例えば、半分以上の仮想マシンが稼動していれば正常に運転しているものと見なすのであれば、「ユーザＶＭ停止中」の状態に２個のトークンがある図１５の状態は、システムが正常に運転されている状態と見なすことができる。

特表２００８−５３２１７０号公報 特開２００６−１２７４６４号公報 特表２００７−５０９４０４号公報 特開２００５−０８０１０４号公報

ところで、確率的ペトリネットで表される可用性評価モデルは、システムのライブラリで標準的に用意されているサーバインフラの可用性評価モデルを、データセンタ管理者がサーバインフラの特性とそのサーバインフラに関わるデータセンタ運用手順まで加味してカスタマイズしたものである。つまり、運用手順に応じて、さまざまな可用性評価モデルを作成する必要がある。したがって、例えば、新規のテナント企業に対応する際や、新規の運用手順を定義する際には、データセンタ管理者が、サーバインフラの特性とそのサーバインフラに関わるデータセンタ運用手順まで加味して可用性評価モデルをカスタマイズする必要がある。

このようなカスタマイズ作業には、例えば、データセンタ運用手順に起因して発生しうるサーバインフラの状態遷移を漏れなくすべて抽出し、それらを仮想マシンなどの個々のサーバインフラを記述する確率的ペトリネットなどの可用性評価モデルにどのように組み込むべきか逐一設計を行うことが含まれる。そのため、データセンタ管理者は、テナント企業の追加や運用手順の追加のたびに、このような煩雑なカスタマイズ作業を繰り返し行わなければならず、作業負荷が高い。

本発明はこのような事情に鑑みてなされたものであり、ライブラリとして標準的に用意されているサーバインフラの可用性評価モデルにデータセンタ運用手順に起因する状態遷移を追加するカスタマイズを行う際の作業負荷を軽減することを目的とする。

本発明の一側面に係る可用性評価装置は、システムの構成に応じた複数の状態遷移の定義を記憶する状態遷移記憶部と、複数の状態遷移とは異なる、システムを運用する際の状態遷移の定義を記憶する追加状態遷移記憶部と、システムを運用する際の状態遷移の定義を受け付けて追加状態遷移記憶部に登録する運用登録部と、状態遷移記憶部に記憶されている状態遷移の定義と、追加状態遷移記憶部に記憶されている状態遷移の定義とに基づいて、システムの可用性を分析する可用性分析部と、追加状態遷移記憶部に記憶されている、システムを運用する際の複数の状態遷移の定義の中の少なくとも一部の状態遷移の定義における共通の状態遷移のパターンを分析する運用分析部と、運用分析部での分析結果を出力する運用分析結果出力部とを備える。

なお、本発明において、「部」とは、単に物理的手段を意味するものではなく、その「部」が有する機能をソフトウェアによって実現する場合も含む。また、１つの「部」や装置が有する機能が２つ以上の物理的手段や装置により実現されても、２つ以上の「部」や装置の機能が１つの物理的手段や装置により実現されても良い。

本発明によれば、ライブラリとして標準的に用意されているサーバインフラの可用性評価モデルにデータセンタ運用手順に起因する状態遷移を追加するカスタマイズを行う際の作業負荷を軽減することができる。

本発明の一実施形態である可用性評価装置の構成例を示す図である。 仮想マシンサーバのシステムの構成に応じた複数の状態遷移を示す可用性評価モデルの一例である。 運用登録表の一例を示す図である。 可用性評価モデルに対して追加される状態遷移の一例を示す図である。 可用性評価モデルに対して追加される状態遷移の一例を示す図である。 可用性評価モデルに対して追加される状態遷移の一例を示す図である。 追加の運用に応じた追加状態遷移登録表の一例を示す図である。 可用性評価装置の動作の一例を示すフローチャートである。 運用手順が成功した場合と失敗した場合とを考慮した可用性評価モデルの一例を示す図である。 運用手順が成功した場合と失敗した場合とを考慮した可用性評価モデルの一例を示す図である。 運用手順が成功した場合と失敗した場合とを考慮した可用性評価モデルの一例を示す図である。 追加状態遷移登録表の一例を示す図である。 仮想マシンの状態遷移を定義する確率的ペトリネットの一例を示す図である。 状態遷移管理表の一例を示す図である。 状態表の一例を示す図である。

以下、図面を参照して本発明の一実施形態について説明する。

図１は、本発明の一実施形態である可用性評価装置の構成例を示す図である。可用性評価装置１０は、仮想マシンをユーザに提供する仮想マシンサーバ２０の可用性を評価する装置である。可用性評価装置１０は、例えば、アプリケーションサーバ等の情報処理装置であり、プロセッサやメモリ、入力装置、記憶装置等を含んで構成される。

また、図１に示すように、可用性評価装置１０は、ライブラリ管理部３０、状態遷移管理表（状態遷移記憶部）３２、運用登録部３４、運用登録表３６、追加状態遷移登録表（追加状態遷移記憶部）３８、可用性分析部４０、可用性分析結果提示部４２、運用分析部４、及び運用分析結果提示部４６を含んで構成されている。なお、ライブラリ管理部３０、運用登録部３４、可用性分析部４０、可用性分析結果提示部４２、運用分析部４、及び運用分析結果提示部４６は、例えば、メモリに記憶されたプログラムをプロセッサが実行することにより実現することができる。また、状態遷移管理表３２、運用登録表３６、及び追加状態遷移登録表は、メモリや記憶装置における記憶領域を用いて実現することができる。

ライブラリ管理部３０は、仮想マシンの可用性評価モデル（確率的ペトリネット）に対応する状態遷移管理表３２を管理する。管理とは、これらの管理表を永続的に保持するための機構を備え、管理表の登録、更新、参照ができることである。

図２は、仮想マシンサーバ２０のシステムの構成に応じた複数の状態遷移を示す可用性評価モデルの一例である。この可用性評価モデルは、例えば、図１４に示されるように、状態遷移管理表３２としてライブラリ管理部３０に管理される。状態遷移管理表３２には、事象名、遷移元の状態名、遷移先の状態名、及び遷移確率が含まれている。なお、仮想マシンサーバ２０のシステムの構成としては、各仮想マシンの他、サーバハードウェア（物理サーバ）、ルータ、スイッチ、ロードバランサ等のネットワーク機器、ユーザＯＳ等の基本ソフトウェアも含まれる。ライブラリ管理部３０は、仮想マシンだけでなく、これらのシステム構成部品に対応した可用性評価モデルを表す状態遷移管理表３２を管理することができる。

図１に戻り、運用登録部３４は、仮想マシンサーバ２０の運用手順に起因して発生する状態遷移のカスタマイズを管理するための機能を提供し、運用登録表３６及び追加状態遷移登録表３８を管理する。

図３は、運用登録表３６の一例を示している。図３に示すように、運用登録表３６は、運用ごとに、運用名、運用手順、及び事象名を含んでいる。運用は、ひとまとまりの運用全体の粒度であってもよいし、一部を切り出した単位の粒度であってもよい。図３に示すように、運用登録表３６には、運用手順の具体的な内容（ワークフロー）を直接記載してもよいし、運用手順を記載したドキュメントやコマンドスクリプトの名前などを記載して参照できるようにしてもよい。

このような運用手順に応じた状態遷移は、運用手順に固有のものであり、ライブラリ管理部３０が管理する状態遷移管理表３２に含まれる仮想マシンサーバ２０のシステム構成に応じた可用性評価モデルには記載されていない。そのため、システムの構成に加えて運用手順も考慮した可用性を評価するためには、運用手順の追加に応じて可用性評価モデルをカスタマイズする必要がある。

図４〜図６は、図２に示した可用性評価モデルに対して追加される状態遷移の一例を示している。例えば、図４では、「ＶＭ再起動」の事象によって、「稼動中」から「ユーザＶＭ停止中」に遷移する運用が追加されている。また、図５では、「ゲストＯＳ起動」の事象によって、「ゲストＯＳ停止中」から「稼動中」に遷移する運用が追加されている。また、図６では、「ネットワーク設定」の事象によって、「ゲストＯＳ停止中」から「稼動中」に遷移する運用が追加されている。これらの追加の運用に応じた追加状態遷移登録表３８の一例が図７に示されている。図７に示すように、追加状態遷移登録表３８の書式は、状態遷移管理表３２の書式と類似しており、事象ごとに、可用性評価モデルにおける事象名、遷移元の状態名、遷移先の状態名、及び遷移確率を含んでいる。

なお、状態遷移管理表３２、運用登録表３６、及び追加状態遷移登録表３８において、運用、事象、状態などの名前は、重複がなく、固有の識別子として使用できるものであれば任意の文字列や記号を用いることができる。

図１に戻り、可用性分析部４０は、ライブラリ管理部３０が管理する状態遷移管理表３２と、運用登録部３４が管理する追加状態遷移追加登録表３８とに基づいて、図１５に例示した状態表を用いて可用性評価モデルのシミュレーションを行ってシステムの可用性を算出する。

可用性分析結果提示部４２は、可用性分析部４０が算出した可用性をデータセンタ管理者に提示するためのインタフェースを提供する。なお、分析結果の提示は、例えば、画面への表示や、プリンタへの出力、所定形式のデータ出力等によって行うことができる。

運用分析部４４は、運用登録部３４が管理する追加状態遷移登録表３８を解析して、運用に応じた状態遷移の定義の特徴を分析する。例えば、運用分析部４４は、追加状態遷移登録表３８に登録された状態遷移の定義の中から、頻繁に出現するカスタマイズパターン（遷移元の状態と遷移先の状態との組）を抽出する。図７に示す追加状態遷移登録表３８の場合であれば、「稼動中」と「ユーザＶＭ停止中」の組が１回、「ゲストＯＳ停止中」と「稼動中」の組が２回現れている。この２つの組では、後者の方が出現回数が多いため、運用分析部４４は、「ゲストＯＳ停止中」と「稼動中」の組のパターンを最頻出のカスタマイズパターンとして選択する。運用分析部４４は、定義された状態から起こりうるすべての組について出現回数を集計することにより、最頻出のカスタマイズパターンを抽出することができる。

運用分析結果提示部４６は、運用分析部４４の分析結果を提示する。例えば、運用分析提示部４６は、運用分析部４４によって抽出されたカスタマイズパターンをデータセンタ管理者に提示するためのインタフェースを提供する。なお、分析結果の提示は、例えば、画面への表示や、プリンタへの出力、所定形式のデータ出力等によって行うことができる。例えば、運用分析結果提示部４６は、運用分析部４４によって抽出された頻出カスタマイズパターンを画面に表示することにより、分析結果をデータセンタ管理者に提示することができる。なお、運用分析結果提示部４６は、「ゲストＯＳ停止中」と「稼働中」の組を表示するだけでなく、この組に対応する確率的ペトリネットの事象名である「ゲストＯＳ起動」と「ネットワーク設定」をさらに表示してもよい。

このようにしてデータセンタ管理者に提示される分析結果は、データセンタ管理者が新たに追加状態遷移登録表３８に運用を追加する際に参考情報とすることが可能である。例えば、追加状態遷移登録表３８の登録画面において、抽出されたカスタマイズパターンを表示したり、遷移元及び遷移先の状態名の入力フィールドにおいて、抽出されたカスタマイズパターンを選択可能にしたりすることができる。したがって、テナント企業の追加や運用手順の追加のたびに、データセンタ管理者が行うカスタマイズ作業の負荷を軽減することが可能となる。

図８のフローチャートを参照して、可用性評価装置１０の動作の一例について説明する。まず、新規のテナント企業に対応したり、新規の運用手順を定義したりする際に、運用登録部３４は、追加される運用における状態遷移の定義をデータセンタ管理者から受け付けて、運用登録表３６に登録する（Ｓ８０１）。これにより、運用登録表３６に、運用名、運用手順、及び対応する確率的ペトリネットの事象名が登録される。さらに、運用登録部３４は、新規に作成された運用に対応する確率的ペトリネットの事象名、遷移元の状態名、遷移先の状態名、及び遷移確率をデータセンタ管理者から受け付けて、追加状態遷移登録表３８に登録する（Ｓ８０２）。

次に、可用性分析部４０は、ライブラリ管理部３０によって管理される状態遷移管理表３２と、運用登録部３４によって新規の登録が行われた追加状態遷移登録表３８とを参照して、仮想マシンサーバ２０の運用手順を含むシステムの可用性を算出する（Ｓ８０３）。可用性分析結果提示部４２は、例えば、可用性分析部４０が算出した可用性の値を画面に表示することにより、可用性の分析結果をデータセンタ管理者に提示する（Ｓ８０４）。

運用分析部４４は、運用登録部３４によって登録された運用登録表３６の運用の件数が１００件に達したかどうか、件数を数えて判定する（Ｓ８０５）。なお、運用分析部４４は、運用登録表３６ではなく、追加状態遷移登録表３８を参照することにより、追加で登録された運用の件数を判定することもできる。追加で登録された運用の件数が１００件未満であれば（Ｓ８０５：ＮＯ）、はじめに戻り、運用登録表３６及び追加状態遷移登録表３８への登録処理（Ｓ８０１，Ｓ８０２）及び可用性の評価処理（Ｓ８０３，Ｓ８０４）が繰り返される。

追加された運用の件数が１００件に達すると（Ｓ８０５：ＹＥＳ）、運用分析部４４は、追加状態遷移登録表３８のなかで最も頻繁に出現する状態遷移のパターンを探し出し、これを頻出するカスタマイズパターンとして選択する（Ｓ８０６）。そして、運用分析結果提示部４６は、例えば、選択された頻出カスタマイズパターンを画面に表示することにより、システムを運用する際の状態遷移の特徴の分析結果をデータセンタ管理者に提示する（Ｓ８０７）。

なお、１００件という件数は一例であり、例えば、データセンタの運営方針に基づいて他の件数をしきい値として設定してもよい。また、件数ではなく、所定間隔ごと（例えば３０日ごと）に運用分析部４４が分析処理を行うようにすることもできる。また、頻出カスタマイズパターンとしては、単に最も頻繁に出現する状態遷移のパターンだけでなく、遷移元がある特定の状態という条件のもとで最も頻繁に出現する状態遷移のパターンや、遷移確率がある特定の値以上という条件のもとで最も頻繁に出現する状態遷移のパターン等を選択することもできる。

以上、本実施形態について説明した。本実施形態の可用性評価装置１０によれば、追加状態遷移登録表３８に登録された状態遷移の分析結果がデータセンタ管理者に提示される。したがって、ライブラリとして標準的に用意されている仮想マシンサーバ２０の可用性評価モデルに仮想マシンサーバ２０の運用手順に起因する状態遷移を追加するカスタマイズを行う際の作業負荷を軽減することができる。

なお、本実施形態は、本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更／改良され得るととともに、本発明にはその等価物も含まれる。

例えば、図９〜図１１に示すように、運用手順が成功した場合と失敗した場合とを考慮して可用性評価モデルをカスタマイズする場合にも対応することができる。例えば、図９に示す例は、「ＶＭ再起動」が成功すると「稼動中」の状態から「稼動中」の状態に遷移する（変化しない）可能性があり、失敗すると「稼動中」の状態から「ユーザＶＭ停止中」の状態へ遷移する可能性があることを示している。また、図１０は、「ゲストＯＳ起動」についてのデータセンタ運用手順が成功した場合と失敗した場合それぞれに起因する状態遷移を追加してカスタマイズした可用性評価モデルを示している。また、図１１は、「ネットワーク設定」についてのデータセンタ運用手順が成功した場合と失敗した場合それぞれに起因する状態遷移を追加してカスタマイズした可用性評価モデルを示している。

この場合、運用登録部３４は、これらの確率的ペトリネットの事象名、遷移元の状態名、成功時の遷移先の状態名、失敗時の遷移先の状態名、及び成功確率をデータセンタ管理者から受け付けて、追加状態遷移登録表３８に登録する。図１２は、この場合における追加状態遷移登録表３８の一例を示している。図７に示した追加状態遷移登録表３８とは異なり、成功時の遷移先の状態名、失敗時の遷移先の状態名、及び成功確率を登録する書式となっている。

図１２の例では、「稼働中」と「稼働中」と「ユーザＶＭ停止中」の組が１回、「ゲストＯＳ停止中」と「稼働中」と「ネットワーク停止中」の組が２回現れている。この２つのパターンでは、後者の方が出現回数が多い。したがって、運用分析部４４は、「ゲストＯＳ停止中」と「稼働中」と「ネットワーク停止中」の組を最頻出のカスタマイズパターンとして選択することができる。

この出願は、２０１０年１１月２６日に出願された日本出願特願２０１０−２６３４９８を基礎とする優先権を主張し、その開示の全てをここに取り込む。

以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

本実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１）システムの構成に応じた複数の状態遷移の定義を記憶する状態遷移記憶部と、前記複数の状態遷移とは異なる、前記システムを運用する際の状態遷移の定義を記憶する追加状態遷移記憶部と、前記システムを運用する際の状態遷移の定義を受け付けて前記追加状態遷移記憶部に登録する運用登録部と、前記状態遷移記憶部に記憶されている状態遷移の定義と、前記追加状態遷移記憶部に記憶されている状態遷移の定義とに基づいて、前記システムの可用性を分析する可用性分析部と、前記追加状態遷移記憶部に記憶されている、前記システムを運用する際の複数の状態遷移の定義の中の少なくとも一部の状態遷移の定義における共通の状態遷移のパターンを分析する運用分析部と、前記運用分析部での分析結果を出力する運用分析結果出力部とを備える可用性評価装置。

（付記２）付記１に記載の可用性評価装置であって、前記運用分析部は、前記システムを運用する際の状態遷移の定義が前記追加状態遷移記憶部に所定件数登録されるごとに、前記共通の状態遷移のパターンを分析することを特徴とする可用性評価装置。

（付記３）付記１に記載の可用性評価装置であって、前記運用分析部は、前記共通の状態遷移のパターンを、所定間隔ごとに分析することを特徴とする可用性評価装置。

（付記４）付記１〜３の何れか一項に記載の可用性評価装置であって、前記運用分析部は、前記共通の状態遷移のパターンのうち、最も頻度の高い状態遷移のパターンを抽出し、前記運用分析結果出力部は、前記最も頻度の高い状態遷移のパターンを示す情報を出力することを特徴とする可用性評価装置。

（付記５）付記４に記載の可用性評価装置であって、前記運用分析部は、前記共通の状態遷移のパターンのうち、所定の遷移元の状態に対して最も頻度の高い状態遷移のパターンを抽出することを特徴とする可用性評価装置。

（付記６）付記４に記載の可用性評価装置であって、前記システムを運用する際の状態遷移の定義には、各状態遷移の遷移確率を示す情報が含まれ、前記運用分析部は、前記共通の状態遷移のパターンのうち、遷移確率が所定値以上の状態遷移のパターンを抽出することを特徴とする可用性評価装置。

（付記７）システムの構成に応じた複数の状態遷移の定義を状態遷移記憶部に記憶し、前記複数の状態遷移とは異なる、前記システムを運用する際の状態遷移の定義を追加状態遷移記憶部に記憶し、前記システムを運用する際の状態遷移の定義を受け付けて前記追加状態遷移記憶部に登録し、前記状態遷移記憶部に記憶されている状態遷移の定義と、前記追加状態遷移記憶部に記憶されている状態遷移の定義とに基づいて、前記システムの可用性を分析し、前記追加状態遷移記憶部に記憶されている、前記システムを運用する際の複数の状態遷移の定義の中の少なくとも一部の状態遷移の定義における共通の状態遷移のパターンを分析し、前記共通の状態遷移のパターンの分析結果を出力する、可用性評価方法。

（付記８）システムの構成に応じた複数の状態遷移の定義を記憶する状態遷移記憶部と、前記複数の状態遷移とは異なる、前記システムを運用する際の状態遷移の定義を記憶する追加状態遷移記憶部とを備えるコンピュータに、前記システムを運用する際の状態遷移の定義を受け付けて前記追加状態遷移記憶部に登録する機能と、前記状態遷移記憶部に記憶されている状態遷移の定義と、前記追加状態遷移記憶部に記憶されている状態遷移の定義とに基づいて、前記システムの可用性を分析する機能と、前記追加状態遷移記憶部に記憶されている、前記システムを運用する際の複数の状態遷移の定義の中の少なくとも一部の状態遷移の定義における共通の状態遷移のパターンを分析する機能と、前記共通の状態遷移のパターンの分析結果を出力する機能と、を実現させるプログラム。

１０ 可用性評価装置
２０ 仮想マシンサーバ
３０ ライブラリ管理部
３２ 状態遷移管理表
３４ 運用登録部
３６ 運用登録表
３８ 追加状態遷移登録表
４０ 可用性分析部
４２ 可用性分析結果提示部
４４ 運用分析部
４６ 運用分析結果提示部

Claims (8)

1. システムの構成に応じた複数の状態遷移の定義を記憶する状態遷移記憶部と、
   前記複数の状態遷移とは異なる、前記システムを運用する際の状態遷移の定義を記憶する追加状態遷移記憶部と、
   前記システムを運用する際の状態遷移の定義を受け付けて前記追加状態遷移記憶部に登録する運用登録部と、
   前記状態遷移記憶部に記憶されている状態遷移の定義と、前記追加状態遷移記憶部に記憶されている状態遷移の定義とに基づいて、前記システムの可用性を分析する可用性分析部と、
   前記追加状態遷移記憶部に記憶されている、前記システムを運用する際の複数の状態遷移の定義の中の少なくとも一部の状態遷移の定義における共通の状態遷移のパターンを分析する運用分析部と、
   前記運用分析部での分析結果を出力する運用分析結果出力部と
   を備える可用性評価装置。
2. 請求項１に記載の可用性評価装置であって、
   前記運用分析部は、
   前記システムを運用する際の状態遷移の定義が前記追加状態遷移記憶部に所定件数登録されるごとに、前記共通の状態遷移のパターンを分析することを特徴とする可用性評価装置。
3. 請求項１に記載の可用性評価装置であって、
   前記運用分析部は、
   前記共通の状態遷移のパターンを、所定間隔ごとに分析することを特徴とする可用性評価装置。
4. 請求項１〜３の何れか一項に記載の可用性評価装置であって、
   前記運用分析部は、前記共通の状態遷移のパターンのうち、最も頻度の高い状態遷移のパターンを抽出し、
   前記運用分析結果出力部は、前記最も頻度の高い状態遷移のパターンを示す情報を出力することを特徴とする可用性評価装置。
5. 請求項４に記載の可用性評価装置であって、
   前記運用分析部は、前記共通の状態遷移のパターンのうち、所定の遷移元の状態に対して最も頻度の高い状態遷移のパターンを抽出することを特徴とする可用性評価装置。
6. 請求項４に記載の可用性評価装置であって、
   前記システムを運用する際の状態遷移の定義には、各状態遷移の遷移確率を示す情報が含まれ、
   前記運用分析部は、前記共通の状態遷移のパターンのうち、遷移確率が所定値以上の状態遷移のパターンを抽出することを特徴とする可用性評価装置。
7. システムの構成に応じた複数の状態遷移の定義を状態遷移記憶部に記憶し、
   前記複数の状態遷移とは異なる、前記システムを運用する際の状態遷移の定義を追加状態遷移記憶部に記憶し、
   前記システムを運用する際の状態遷移の定義を受け付けて前記追加状態遷移記憶部に登録し、
   前記状態遷移記憶部に記憶されている状態遷移の定義と、前記追加状態遷移記憶部に記憶されている状態遷移の定義とに基づいて、前記システムの可用性を分析し、
   前記追加状態遷移記憶部に記憶されている、前記システムを運用する際の複数の状態遷移の定義の中の少なくとも一部の状態遷移の定義における共通の状態遷移のパターンを分析し、
   前記共通の状態遷移のパターンの分析結果を出力する、
   可用性評価方法。
8. システムの構成に応じた複数の状態遷移の定義を記憶する状態遷移記憶部と、前記複数の状態遷移とは異なる、前記システムを運用する際の状態遷移の定義を記憶する追加状態遷移記憶部とを備えるコンピュータに、
   前記システムを運用する際の状態遷移の定義を受け付けて前記追加状態遷移記憶部に登録する機能と、
   前記状態遷移記憶部に記憶されている状態遷移の定義と、前記追加状態遷移記憶部に記憶されている状態遷移の定義とに基づいて、前記システムの可用性を分析する機能と、
   前記追加状態遷移記憶部に記憶されている、前記システムを運用する際の複数の状態遷移の定義の中の少なくとも一部の状態遷移の定義における共通の状態遷移のパターンを分析する機能と、
   前記共通の状態遷移のパターンの分析結果を出力する機能と、
   を実現させるプログラム。

Images