(57)【特許請求の範囲】
【請求項１】
複数のサービスのそれぞれについて、前記サービスを利用するクライアント装置に対する影響の度合いと、前記サービスの重要度に基づき、前記サービスに関する調査の優先度を算出する算出部であって、前記サービスは、複数のデータセンタを用いて提供されるものであり、前記データセンタのうちの１つに含まれるノードによって第１の系が形成されるものであり、前記データセンタのうちの他の１つに含まれるノードによって第２の系が形成されるものであり、前記第１の系と前記第２の系によりクラスタ構成が形成されるものであり、前記影響の度合いは、前記サービスを前記第１の系から前記第２の系に引き継ぐ場合における、前記サービスを利用する前記クライアント装置に対する影響の度合いを示すものである、前記算出部と、
前記算出部により算出された優先度を出力する出力部と、
を有することを特徴とする情報処理装置。 
【請求項２】
前記クライアント装置からみた前記データセンタのうちの１つにおける前記第１の系の前記ノードの応答時間である第１の応答時間と、前記クライアント装置からみた前記データセンタのうちの他の１つにおける前記第２の系の前記ノードの応答時間である第２の応答時間を示す第１の情報と、前記データセンタのうちの１つにおける前記第１の系の前記ノードと前記データセンタのうちの他の１つにおける前記第２の系の前記ノードの間の通信時間を示す第２の情報を取得する取得部をさらに有し、
前記算出部は、前記サービスごとに、前記第１の情報が示す前記第１の応答時間と前記第２の応答時間から、応答性能の変化率を算出すると共に、前記第２の情報が示す前記通信時間から、前記サービスのダウンタイムを算出し、前記応答性能の変化率および前記サービスの前記ダウンタイムを用いて、前記サービスの前記クライアント装置に対する前記影響の度合いを算出する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記算出部は、前記複数のサービスごとに、当該サービスに対して定められた優先レベルと、当該サービスの提供先に対して定められた優先レベルから当該サービスの重要度を算出する
ことを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記出力部は、前記優先度に対応付けて、前記影響の度合いと前記重要度を出力する
ことを特徴とする請求項１から３の何れか１つに記載の情報処理装置。
【請求項５】
コンピュータに、
複数のサービスのそれぞれについて、前記サービスを利用するクライアント装置に対する影響の度合いと、前記サービスの重要度に基づき、前記サービスに関する調査の優先度を算出することであって、前記サービスは、複数のデータセンタを用いて提供されるものであり、前記データセンタのうちの１つに含まれるノードによって第１の系が形成されるものであり、前記データセンタのうちの他の１つに含まれるノードによって第２の系が形成されるものであり、前記第１の系と前記第２の系によりクラスタ構成が形成されるものであり、前記影響の度合いは、前記サービスを前記第１の系から前記第２の系に引き継ぐ場合における、前記サービスを利用する前記クライアント装置に対する影響の度合いを示すものである、前記算出することと、
算出された前記優先度を出力すること
からなる処理を実行させるための優先度算出プログラム。
【請求項６】
サービスを提供するための複数のノードであって、前記ノードのそれぞれは、複数のデータセンタのいずれかに含まれるものであり、前記サービスのそれぞれは、複数の前記データセンタを用いて提供されるものであり、前記データセンタのうちの１つに含まれるノードによって第１の系が形成されるものであり、前記データセンタのうちの他の１つに含まれるノードによって第２の系が形成されるものであり、前記第１の系と前記第２の系によりクラスタ構成が形成されるものである、前記複数のノードと、
算出部と出力部を有する情報処理装置であって、前記算出部は、複数のサービスのそれぞれについて、前記サービスを利用するクライアント装置に対する影響の度合いと、前記サービスの重要度に基づき、前記サービスに関する調査の優先度を算出するものであり、前記影響の度合いは、前記サービスを前記第１の系から前記第２の系に引き継ぐ場合における、前記サービスを利用する前記クライアント装置に対する影響の度合いを示すものであり、前記出力部は、前記算出部により算出された前記優先度を出力するものである、前記情報処理装置と、
を備えたデータセンタシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、優先度算出プログラムおよびデータセンタシステムに関する。
【背景技術】
【０００２】
近年、クラウドコンピューティングの普及に伴い、クラウドを提供するクラウドベンダは、異なる国や都市など、地理的に離れた複数のリージョンにデータセンタを展開している。各データセンタには、多数の物理サーバや各物理サーバ上で稼働する多数の仮想マシンが設けられ、物理サーバまたは仮想サーバ上で、クラウドを利用してサービスを提供するクラウド利用者のサービスに係るシステムが動作する。また、クラウド利用者には、事業継続性の観点から災害対策等を目的として、リージョンが異なる複数のデータセンタ間でシステムをＨＡ（High  Availability）クラスタ構成とする場合がある。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−３８９６号公報
【特許文献２】特開２００９−１８１５３６号公報
【特許文献３】特開２００３−２４１９９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
クラウドベンダでは、複数のデータセンタを効率的に管理・運用するため、単一のコントロールセンタを設け、当該コントロールセンタにより各データセンタを統合的に管理・運用することが考えられる。
【０００５】
しかしながら、単一のコントロールセンタにより各データセンタを管理・運用する場合、次のような問題がある。例えば、データセンタでトラブルが発生すると、トラブルが発生した物理サーバまたは仮想サーバ上でシステムを運用する多数のクラウド利用者の調査依頼がコントロールセンタへ送られる。コントロールセンタの担当者は、多数の調査依頼が受けた場合、優先度の高い順にトラブルの調査を行うが、トラブルの調査の優先度を効率的に判断できない場合がある。特に、ＨＡクラスタ構成を取るクラウド利用者の場合、システムが複数のデータセンタに跨るため、コントロールセンタの担当者は、トラブルの調査の優先度が判断し難い場合がある。このため、コントロールセンタの担当者は、どのクラウド利用者への対応を優先するか判断できず、対応を効率的に行えない場合がある。
【０００６】
本発明は、一側面では、対応の効率化を支援できる情報処理装置、優先度算出プログラムおよびデータセンタシステムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
１つの態様では、情報処理装置は、算出部と、出力部とを有する。算出部は、複数のデータセンタのノードに分かれ、クラスタ構成により第１の系と第２の系が運用される複数のサービスを第１の系から第２の系へ引き継ぐ場合の複数のサービスをそれぞれ利用するクライアント装置への影響の度合いと、複数のサービスそれぞれの重要度とに基づき、複数のサービスごとの調査の優先度を算出する。出力部は、算出部により算出された優先度を出力する。
【発明の効果】
【０００８】
本発明の一側面によれば、対応の効率化を支援できる。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施例に係るデータセンタシステムのハードウェア構成を示す図である。
【図２】図２は、実施例に係るデータセンタの機能構成を示す図である。
【図３】図３は、実施例に係るコントロールセンタの機能構成を示す図である。
【図４】図４は、運用ポリシー格納領域に記憶される運用ポリシーテーブルのデータ構成の一例を示す図である。
【図５】図５は、顧客管理情報格納領域に記憶される顧客管理テーブルのデータ構成の一例を示す図である。
【図６】図６は、運用状況情報格納領域に記憶される運用状況テーブルのデータ構成の一例を示す図である。
【図７】図７は、優先度情報格納領域に記憶される優先度情報テーブルのデータ構成の一例を示す図である。
【図８】図８は、優先度を算出する流れの一例を示す図である。
【図９】図９は、優先度算出処理の手順の一例を示すフローチャートである。
【図１０】図１０は、優先度算出プログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【００１０】
以下に、本願の開示する情報処理装置、優先度算出プログラムおよびデータセンタシステムの実施例を図面に基づいて詳細に説明する。本実施例では、仮想マシンを提供する複数のデータセンタを含むデータセンタシステムに適用するものとする。なお、本実施例によりこの発明が限定されるものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【実施例１】
【００１１】
［実施例に係るデータセンタシステムの構成］
図１は、実施例に係るデータセンタシステムのハードウェア構成を示す図である。図１に示すように、データセンタシステム１０は、複数のデータセンタ１１と、コントロールセンタ１２とを有する。複数のデータセンタ１１とコントロールセンタ１２とは、それぞれネットワークＮ１で接続される。ネットワークＮ１は、専用回線であっても良いし、専用回線でなくても良い。なお、図１の例では、２つのデータセンタ１１（１１Ａ、１１Ｂ）を図示したが、データセンタ１１の数は２つ以上であれば任意の数とすることができる。
【００１２】
各データセンタ１１は、何れかで災害等による異常が発生した場合でも、他のデータセンタ１１が異常の影響を受けないように、地理的に離れた位置に配置されている。本実施例では、各データセンタ１１は、例えば、異なる国や都市など、異なる地域に配置されているものとする。例えば、データセンタ１１Ａは、エリアＡに配置されている。データセンタ１１Ｂは、エリアＢに配置されている。エリアＡ、Ｂは、例えば、Ａ国、Ｂ国など国であってもよい。また、エリアＡ、Ｂは、例えば、東アジア、北米など各国を地理的に分けたエリアであってもよい。
【００１３】
データセンタシステム１０は、各データセンタ１１に多数の物理サーバや各物理サーバ上で稼働する多数の仮想マシン（ＶＭ：Virtual  Machine）がノードとして設けられている。そして、データセンタシステム１０は、複数のデータセンタ１１のノードに分かれ、ＨＡクラスタ構成により複数のサービスが運用される。ＨＡクラスタ構成では、複数のデータセンタ１１のノードにそれぞれサービスに関して同じプログラムおよびデータが配置され、サービスに係るシステムの冗長化が図られる。ＨＡクラスタ構成では、複数のデータセンタ１１のノードが第１の系と第２の系に分けて運用される。第１の系のノードは、ユーザの要求に応じてサービスを提供し、サービスが稼働する運用系のノードである。第２の系のノードは、第１の系のノードが正常に運用されている間は待機状態にあり、第１の系のノードに障害などのトラブルが発生した場合に、処理を引き継いで行う待機系のノードである。データセンタシステム１０では、サービスごとに、何れのデータセンタ１１のノードが運用系のノードとされ、他のデータセンタ１１のノードが待機系のノードとされて運用される。例えば、エリアＡのデータセンタ１１のノードは、運用系とされる。エリアＢのデータセンタ１１のノードは、待機系とされる。待機系のノードは、運用系のノードとサービスに関するプログラムやデータの同期が行われ、サービスに関して同じプログラムおよびデータが記憶される。データの同期の方法は、何れの方式であってもよい。例えば、待機系のノードが、運用系のノードとミラーリングを行って、運用系のノードと同じプログラムおよび同じデータを記憶してもよい。また、運用系のノードが処理を行う各種の要求やデータを待機系のノードに転送し、待機系のノードが、運用系のノードと同じ処理を実行することで、運用系のノードと同じプログラムおよび同じデータを記憶してもよい。なお、３以上のデータセンタ１１がある場合は、例えば、何れか１つのデータセンタ１１のノードが運用系とされ、他のデータセンタ１１のノードが待機系とされる。運用系のノードにトラブルが発生した場合は、サービスごとに、予め定めた引き継ぎのポリシーに従い、何れかの待機系のノードに処理を引き継ぐ。
【００１４】
ネットワークＮ１には、データセンタシステム１０で運用されるサービスをそれぞれ利用するユーザのユーザ端末１３が接続されている。なお、図１の例では、ユーザ端末１３を１つ図示したが、ユーザ端末１３の数は任意の数とすることができる。
【００１５】
ユーザ端末１３は、各データセンタ１１が提供する各種のサービスを利用するクライアント装置である。ユーザ端末１３は、測定エージェント１３Ａのプログラムがインストールされて実行され、測定エージェント１３Ａが動作する。測定エージェント１３Ａは、所定のタイミングで、ユーザ端末１３が使用するサービスの運用系および待機系の各ノードと通信を行い、応答が得られるまでの通信時間をそれぞれ測定する。例えば、測定エージェント１３Ａは、運用系および待機系の各ノードに対して、例えば、ＰＩＮＧ（Packet  Internet  Groper）などによりテストパケットをそれぞれ送信して応答が得られるまでの時間を測定する。所定のタイミングは、例えば、１０分毎など一定の時間毎のタイミングや、特定の時刻となったタイミング、システムが運用系から待機系へ引き継がれたタイミングなど何れのタイミングであってもよい。測定エージェント１３Ａは、運用系および待機系の各ノードにテストパケットを送信して応答が得られるまでの時間を応答時間として、応答時間情報をコントロールセンタ１２へ送信する。
【００１６】
コントロールセンタ１２は、複数のデータセンタ１１を統合的に管理・運用する。例えば、コントロールセンタ１２は、各データセンタ１１で稼働するノードの状態を把握する。また、コントロールセンタ１２は、トラブルが発生した場合、サービスを提供するクラウド利用者からの調査依頼により、トラブルの調査、対応を行う。なお、コントロールセンタ１２は、いずれかのデータセンタ１１と統合されてもよい。
【００１７】
［データセンタのハードウェア構成］
次に、データセンタ１１の機能構成を、図２を参照して説明する。図２は、実施例に係るデータセンタの機能構成を示す図である。なお、データセンタ１１Ａ、１１Ｂの機能構成は、略同一であるので、以下では、データセンタ１１Ａの構成を例に説明する。
【００１８】
データセンタ１１は、複数のサーバ装置２０と、運用管理サーバ２１とを有する。複数のサーバ装置２０と運用管理サーバ２１は、ネットワークＮ２で接続され、通信可能とされている。このネットワークＮ２は、ネットワークＮ１と通信可能に接続され、ネットワークＮ１を介して他のデータセンタ１１と通信可能とされている。なお、図２の例では、サーバ装置２０を３つ図示したが、サーバ装置２０は任意の台数とすることができる。また、図２の例では、運用管理サーバ２１を１つ図示したが、運用管理サーバ２１が２つ以上であってもよい。
【００１９】
サーバ装置２０は、コンピュータを仮想化した仮想マシンを動作させて、ユーザに対して各種のサービスを提供する物理サーバであり、例えば、サーバコンピュータである。サーバ装置２０は、サーバ仮想化プログラムを実行することによって、ハイパーバイザー上で複数の仮想マシンを動作させ、仮想マシン上でクラウド利用者が提供するサービスに応じたアプリケーションプログラムを動作させることにより、サービスに係るシステムを動作させる。本実施例では、クラウド利用者のシステムとして、企業など顧客のシステムが動作している。図２の例では、クラウド利用者のシステムとして、顧客Ａ、顧客Ｂ、顧客Ｃのシステムが動作している。この顧客Ａ、顧客Ｂ、顧客Ｃのシステムは、データセンタ１１ＢとＨＡクラスタが構成されてシステムの冗長化が図られている。本実施例では、図２に示すデータセンタ１１Ａの顧客Ａ、顧客Ｂ、顧客Ｃのシステムが運用系とし、データセンタ１１Ｂの顧客Ａ、顧客Ｂ、顧客Ｃのシステムが待機系とする。データセンタ１１Ａの顧客Ａ、顧客Ｂ、顧客Ｃのシステムは、トラブルが発生した場合、データセンタ１１Ｂの顧客Ａ、顧客Ｂ、顧客Ｃのシステムに処理が移行する。これにより、顧客Ａ、顧客Ｂ、顧客Ｃのシステムやデータセンタ１１Ａにトラブルが発生した場合でも、ユーザ端末１３に対して、顧客Ａ、顧客Ｂ、顧客Ｃのシステムによるサービスを継続できる。
【００２０】
運用管理サーバ２１は、データセンタ１１の運用、管理を行う物理サーバであり、例えば、サーバコンピュータである。例えば、運用管理サーバ２１は、データセンタ１１内の各サーバ装置２０および各サーバ装置２０で動作する各仮想マシンから情報を収集して動作状況を管理しており、各サーバ装置２０や各仮想マシンの動作状況をコントロールセンタ１２へ通知する。また、運用管理サーバ２１は、コントロールセンタ１２からの各種の指示に応じて、各サーバ装置２０や各仮想マシンへ各種の指示を出力する。ＨＡクラスタ構成では、運用系のノードと待機系のノードは互いに生存や動作状況を確認するため、定期的にパケットを送受信する。例えば、運用系のノードと待機系のノードは、インターコネクトにより接続され、定期的にパケットを送受信する。運用系のノードまたは待機系のノードでは、相手のノードにパケットを送信して応答が得られるまでの時間を測定する。運用管理サーバ２１は、クラウド利用者のシステムごとに、運用系のノードまたは待機系のノードから、測定された時間を運用系と待機系のノード間の通信時間として収集して通信時間情報をコントロールセンタ１２へ送信する。なお、データセンタシステム１０では、何れかのデータセンタ１１の運用管理サーバ２１を、データセンタシステム１０全体を管理する管理サーバとして運用してもよい。この場合、他データセンタ１１の運用管理サーバ２１は、データセンタシステム１０全体を管理する管理サーバとされた運用管理サーバ２１へデータセンタ１１内の状況を通知する。
【００２１】
［コントロールセンタのハードウェア構成］
次に、コントロールセンタ１２の機能構成を、図３を参照して説明する。図３は、実施例に係るコントロールセンタの機能構成を示す図である。
【００２２】
コントロールセンタ１２は、管理サーバ１００と、担当者端末２００とを有する。管理サーバ１００及び担当者端末２００は、例えばコントロールセンタ１２内のネットワークで接続され、通信可能とされている。コントロールセンタ１２内のネットワークは、ネットワークＮ１と通信可能に接続され、ネットワークＮ１を介して各データセンタ１１と通信可能とされている。また、図３の例では、管理サーバ１００を１つ図示したが、管理サーバ１００が２つ以上であってもよい。
【００２３】
管理サーバ１００は、各データセンタ１１の運用管理サーバ２１から通知される情報に基づき、各データセンタ１１を統合的に管理・運用する情報処理装置であり、例えば、サーバコンピュータである。管理サーバ１００は、何れかのデータセンタ１１で障害などのトラブルが発生した場合、状況を分析し、トラブルの影響を受けるサービスを特定する。また、管理サーバ１００は、担当者端末２００からの要求に応じて、トラブルの影響を受けるサービスごとに対応の優先度を算出して担当者端末２００へ出力する。
【００２４】
また、担当者端末２００は、例えば、デスクトップＰＣ（Personal  Computer）や、ノート型ＰＣや、タブレット型端末や、携帯電話機、ＰＤＡ（Personal  Digital  Assistant）等により実現される。例えば、担当者端末２００は、トラブル対応業務を行う担当者に使用される。
【００２５】
［管理サーバ（情報処理装置）の構成］
次に、実施例１に係る管理サーバ１００の構成について説明する。図３に示すように、管理サーバ１００は、通信部１０１と、記憶部１０２と、制御部１０３とを有する。なお、管理サーバ１００は、図３に示した機能部以外にも既知のコンピュータが有する各種の機能部を有することとしてもかまわない。例えば、管理サーバ１００は、各種の情報を表示する表示部や、各種の情報を入力する入力部を有してもよい。
【００２６】
通信部１０１は、例えば、ＮＩＣ（Network  Interface  Card）によって実現される。通信部１０１は、例えばネットワークＮ１と有線又は無線で接続される。そして、通信部１０１は、ネットワークＮ１を介して、データセンタ１１との間で情報の送受信を行う。また、通信部１０１は、例えばコントロールセンタ１２内のネットワークを介して、担当者端末２００との間で情報の送受信を行う。
【００２７】
記憶部１０２は、ハードディスク、ＳＳＤ（Solid  State  Drive）、光ディスクなどの記憶装置である。なお、記憶部１０２は、ＲＡＭ（Random  Access  Memory）、フラッシュメモリ、ＮＶＳＲＡＭ（Non  Volatile  Static  Random  Access  Memory）などのデータを書き換え可能な半導体メモリであってもよい。
【００２８】
記憶部１０２は、制御部１０３で実行されるＯＳ（Operating  System）や各種プログラムを記憶する。例えば、記憶部１０２は、後述する優先度算出処理を実行するプログラムを含む各種のプログラムを記憶する。さらに、記憶部１０２は、制御部１０３で実行されるプログラムで用いられる各種データを記憶する記憶領域を有する。本実施例における記憶部１０２は、運用ポリシー格納領域１１０と、顧客管理情報格納領域１１１と、運用状況情報格納領域１１２と、優先度情報格納領域１１３とを有する。
【００２９】
運用ポリシー格納領域１１０は、データセンタシステム１０の運用に関する各種のポリシーを定めた運用ポリシーテーブルを記憶する記憶領域である。例えば、運用ポリシー格納領域１１０には、クラウドを利用してサービスを提供するクラウド利用者ごとのトラブル発生時の対応に関するポリシーが記憶される。運用ポリシーテーブルの各情報は、例えば、コントロールセンタ１２の担当者等により予め設定される。なお、以下では、データセンタシステム１０の運用者にとってクラウド利用者は、データセンタシステム１０を利用する顧客であるため、クラウド利用者を「顧客」とも称する。また、クラウド利用者が提供するサービスを利用するユーザを「エンドユーザ」とも称する。
【００３０】
図４は、運用ポリシー格納領域に記憶される運用ポリシーテーブルのデータ構成の一例を示す図である。図４に示すように、運用ポリシーテーブルは、「要因」、「分類」、「重み」の各項目を有する。
【００３１】
要因の項目は、運用ポリシーを定める要因を記憶する領域である。分類の項目は、運用ポリシーを定める要因の分類を記憶する領域である。本実施例では、要因を、予め定まる静的な要因と、データセンタシステム１０の状況によって動的に変化する動的な要因に分類している。要因の項目には、静的な要因の場合、「静的」が格納され、動的な要因の場合、「動的」が格納される。重みの項目は、要因ごとに定められた重み値を記憶する領域である。
【００３２】
図４の例では、「重要顧客指数」の要因は、静的な要因であり、重み値が「５」であることを示す。また、「業務継続要件レベル」の要因は、静的な要因であり、重み値が「７」であることを示す。また、「フェールオーバ前後応答性能比」の要因は、動的な要因であり、重み値が「２０」であることを示す。また、「ダウンタイム見積もり」の要因は、動的な要因であり、重み値が「２」であることを示す。
【００３３】
図３に戻り、顧客管理情報格納領域１１１は、各顧客の運用、管理に関する各種の情報を記憶した顧客管理テーブルを記憶する記憶領域である。例えば、顧客管理情報格納領域１１１には、顧客ごとに、システムの状況、トラブル発生時の運用ポリシーのレベルが記憶される。顧客管理テーブルの各情報は、例えば、コントロールセンタ１２の担当者等により予め設定される。
【００３４】
図５は、顧客管理情報格納領域に記憶される顧客管理テーブルのデータ構成の一例を示す図である。図５に示すように、顧客管理テーブルは、「顧客名」、「ＶＭホスト名」、「業務継続要件レベル」、「重要顧客指数」の各項目を有する。顧客管理テーブルには静的優先度の各要因の値がすべて定義されている。  
【００３５】
顧客名の項目は、顧客を識別する識別情報を記憶する領域である。ＶＭホスト名の項目は、顧客の運用系のシステムが動作する仮想マシンの識別情報を記憶する領域である。各仮想マシンには、識別情報として一意の仮想マシン名が定められる。ＶＭホスト名の項目には、顧客の運用系のシステムが動作する仮想マシンの仮想マシン名が記憶される。業務継続要件レベルの項目は、トラブル発生時に、顧客のシステムに対して定めた優先レベルを記憶する領域である。重要顧客指数の項目は、顧客に対して定めた優先レベルを記憶する領域である。優先レベルは、数値が大きいほど優先させる度合いが高いものとする。
【００３６】
図５の例では、クラウド利用者「顧客Ａ」は、運用系のシステムが仮想マシン名「ＶＭ１」の仮想マシンで動作しており、業務継続要件レベルが「８」、重要顧客指数が「５」であることを示す。また、クラウド利用者「顧客Ｂ」は、運用系のシステムが仮想マシン名「ＶＭ２」の仮想マシンで動作しており、業務継続要件レベルが「５」、重要顧客指数が「６」であることを示す。また、クラウド利用者「顧客Ｃ」は、運用系のシステムが仮想マシン名「ＶＭ３」の仮想マシンで動作しており、業務継続要件レベルが「５」、重要顧客指数が「２」であることを示す。
【００３７】
図３に戻り、運用状況情報格納領域１１２は、トラブルが発生してシステムを運用系から待機系に引き継ぐフェールオーバが発生した場合の運用状況に関する各種の情報を記憶した運用状況テーブルを記憶する記憶領域である。例えば、運用状況情報格納領域１１２には、フェールオーバによりシステムが引き継がれた仮想マシンに関する情報と、システムが引き継がれたことによる性能の変化に関する情報が記憶される。運用状況テーブルの各情報は、後述する算出部１２１により設定される。運用状況テーブルには動的優先度の各要因の値がすべて定義されていることが求められる。
【００３８】
図６は、運用状況情報格納領域に記憶される運用状況テーブルのデータ構成の一例を示す図である。図６に示すように、運用状況テーブルは、「フェールオーバ元ホスト名」、「フェールオーバ先ホスト名」、「フェールオーバ前後応答性能比」、「ダウンタイム見積もり」の各項目を有する。
【００３９】
フェールオーバ元ホスト名の項目は、フェールオーバの際に運用系であった仮想マシンの仮想マシン名を記憶する領域である。フェールオーバ先ホスト名の項目は、フェールオーバの際に待機系であった仮想マシンの仮想マシン名を記憶する領域である。フェールオーバ前後応答性能比の項目は、フェールオーバによるシステムの応答性能の変化度合いを記憶する領域である。本実施例では、フェールオーバ前後応答性能比を、フェールオーバ前のシステムの応答性能に対して、フェールオーバ後のシステムの応答性能がどの程度変化したかの割合をパーセンテージ（％）で示している。ダウンタイム見積もりの項目は、フェールオーバによりシステムが応答できない時間を秒単位［ｓｅｃ］で記憶する領域である。
【００４０】
図６の例では、仮想マシン名「ＶＭ１」から仮想マシン名「ＶＭ４」へのフェールオーバでは、性能が４０％ダウンし、システムが応答できないダウンタイムが「１０」秒であることを示す。また、仮想マシン名「ＶＭ２」から仮想マシン名「ＶＭ５」へのフェールオーバでは、性能が７０％ダウンし、システムが応答できないダウンタイムが「２」秒であることを示す。また、仮想マシン名「ＶＭ３」から仮想マシン名「ＶＭ６」へのフェールオーバでは、性能が２０％アップし、システムが応答できないダウンタイムが「８」秒であることを示す。
【００４１】
図３に戻り、優先度情報格納領域１１３は、トラブルが発生した場合の各顧客の対応の優先度合いに関する各種の情報を記憶した優先度情報テーブルを記憶する記憶領域である。例えば、優先度情報格納領域１１３には、顧客ごとに、算出された各種の優先度が記憶される。優先度情報テーブルの各情報は、後述する算出部１２１により設定される。
【００４２】
図７は、優先度情報格納領域に記憶される優先度情報テーブルのデータ構成の一例を示す図である。図７に示すように、優先度情報テーブルは、「顧客名」、「静的優先度」、「動的優先度」、「調査優先度」の各項目を有する。
【００４３】
顧客名の項目は、顧客を識別する識別情報を記憶する領域である。静的優先度の項目は、クラウド利用者に対して予め定めた情報から算出される静的な優先度を記憶する領域である。この静的な優先度は、顧客のサービスの重要度を表す。動的優先度の項目は、フェールオーバによるシステムの性能の変化に関する情報から算出される動的な優先度を記憶する領域である。この動的な優先度は、フェールオーバにより顧客が提供するサービスを運用系から待機系へ引き継ぐ場合のユーザ端末１３に対する影響の度合いを表す。調査優先度の項目は、システムごとの調査、対応の優先度を記憶する領域である。
【００４４】
図７の例では、クラウド利用者「顧客Ａ」は、静的優先度が「８１」であり、動的優先度が「５４」であり、調査優先度が「１３５」であることを示す。クラウド利用者「顧客Ｂ」は、静的優先度が「６５」であり、動的優先度が「７２」であり、調査優先度が「１３７」であることを示す。クラウド利用者「顧客Ｃ」は、静的優先度が「４５」であり、動的優先度が「３２」であり、調査優先度が「７７」であることを示す。
【００４５】
図３に戻り、制御部１０３は、管理サーバ１００を制御するデバイスである。制御部１０３としては、ＣＰＵ（Central  Processing  Unit）、ＭＰＵ（Micro  Processing  Unit）等の電子回路や、ＡＳＩＣ（Application  Specific  Integrated  Circuit）、ＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路を採用できる。制御部１０３は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１０３は、各種のプログラムが動作することにより各種の処理部として機能する。例えば、制御部１０３は、取得部１２０と、算出部１２１と、出力部１２２とを有する。
【００４６】
取得部１２０は、各種のデータの取得を行う。例えば、取得部１２０は、ユーザ端末１３から応答時間情報を取得する。応答時間情報は、取得部１２０がユーザ端末１３へ要求を送信して、送信させてもよく、また、ユーザ端末１３が応答時間を測定したタイミングなど定期的なタイミングで送信してもよい。また、取得部１２０は、各データセンタ１１の運用管理サーバ２１から通信時間情報を取得する。通信時間情報も、取得部１２０が各データセンタ１１の運用管理サーバ２１へ要求を送信して、送信させてもよく、また、各データセンタ１１の運用管理サーバ２１が通信時間を測定したタイミングなど定期的なタイミングで送信してもよい。
【００４７】
算出部１２１は、各種の算出を行う。例えば、算出部１２１は、トラブルの発生などにより、クラスタ構成により運用されているサービスに係るシステムの運用系から待機系への引き継ぎが発生した場合、トラブルの影響を受けたサービスごとに、ユーザ端末１３への影響の度合いと、サービスの重要度を求める。そして、算出部１２１は、サービスごとに、ユーザ端末１３への影響の度合いと、サービスの重要度から、対応の優先度を算出する。
【００４８】
最初に、サービスの重要度の算出方法を説明する。算出部１２１は、サービスごとに、顧客管理テーブルの各指数を運用ポリシテーブルの静的要素の重み値で重み付け加算して、サービスの重要度を算出する。例えば、図５に示す顧客Ａのサービスについて、図６に示すように仮想マシン名「ＶＭ１」から仮想マシン名「ＶＭ４」へサービスに係るシステムのフェールオーバが発生した場合、算出部１２１は、以下のようにサービスの重要度を算出する。算出部１２１は、以下のように業務継続要件レベルの値「８」に業務継続要件レベルの重み値「７」を乗算して重み付けする。また、算出部１２１は、重要顧客指数「５」に重要顧客指数の重み値「５」を乗算して重み付けする。そして、算出部１２１は、重み付けした値を加算してサービスの重要度を算出する。
【００４９】
サービスの重要度＝８×７＋５×５
＝８１
【００５０】
このサービスの重要度は、予め定められた業務継続要件レベル、重要顧客指数から算出されるため、システムの状況により変化せず、静的な値である。
【００５１】
次に、ユーザ端末１３への影響の度合いの算出方法を説明する。算出部１２１は、運用系から待機系へ引き継ぎが発生したサービスごとに、取得部１２０により取得された応答時間情報からユーザ端末１３と運用系のノードの応答時間と、ユーザ端末１３と待機系のノードとの応答時間を特定する。そして、算出部１２１は、システムを運用系から待機系に引継いだ場合のユーザ端末１３での応答時間の変化率を算出する。例えば、算出部１２１は、以下の式（１）の演算により応答時間の変化率を算出する。
【００５２】
応答時間の変化率［％］＝［（Ｔ１／Ｔ２）−１］×１００      （１）
【００５３】
ここで、Ｔ１は、ユーザ端末１３と運用系のノードの応答時間である。Ｔ２は、ユーザ端末１３と待機系のノードの応答時間である。
【００５４】
この応答時間の変化率は、サービスを行うシステムを運用系のノードから待機系のノードへ移行させた場合、ユーザ端末１３に対するシステムの応答性能の変化度合いを示す。
【００５５】
また、算出部１２１は、運用系から待機系へ引き継ぎが発生したサービスごとに、取得部１２０により取得された通信時間情報からシステムを運用系のノードから待機系のノードへ引き継ぐ際のダウンタイムを特定する。ここで、待機系のノードは、運用系のノードとサービスに関するプログラムやデータの同期が行われ、サービスに関して同じプログラムおよびデータが記憶される。この場合、運用系のノードから待機系のノードへの引き継ぎは、運用系のノードと待機系のノードとの引き継ぎに関する通信により行え、引き継ぎに関する通信を行っている間が運用系および待機系のノードの何れもサービスに係るシステムが応答できないダウンタイムとなる。本実施例では、運用系のノードと待機系のノードの通信時間をダウンタイムと見積もる。算出部１２１は、サービスごとに、通信時間情報から、運用系のノードと待機系のノードの通信時間を特定する。
【００５６】
算出部１２１は、運用系から待機系へ引き継ぎが発生したサービスごとに、運用系のノード、待機系のノード、応答時間の変化率、運用系のノードと待機系のノードの通信時間を格納した運用状況テーブルを生成して、記憶部１０２に記憶させる。図６の例では、仮想マシン名「ＶＭ１」から仮想マシン名「ＶＭ４」へサービスに係るシステムのフェールオーバでは、ユーザ端末１３の応答性能が４０％ダウンし、ダウンタイムが１０秒であると記憶されている。
【００５７】
算出部１２１は、運用系から待機系へ引き継ぎが発生したサービスごとに、応答時間の変化率およびサービスのダウンタイムを用いて、当該サービスのユーザ端末１３に対する影響の度合いを算出する。例えば、算出部１２１は、以下の式（２）の演算によりフェールオーバ前後応答性能比の補正値を算出する。
【００５８】
フェールオーバ前後応答性能比の補正値＝１÷［（ＲＣ＋１００）÷１００］    （２）
【００５９】
ここで、ＲＣは、応答時間の変化率（フェールオーバ前後応答性能比）である。
【００６０】
フェールオーバ前後応答性能比の補正値は、性能が劣化しているほど優先度が高くするため、応答時間の変化率の逆数をとっている。
【００６１】
算出部１２１は、フェールオーバ前後応答性能比の補正値およびダウンタイムを、それぞれ運用ポリシテーブルの動的要素の重み値で重み付け加算して、ユーザ端末１３に対する影響の度合いを算出する。
【００６２】
例えば、図６に示すよう、仮想マシン名「ＶＭ１」から仮想マシン名「ＶＭ４」へサービスに係るシステムのフェールオーバが発生した場合、応答時間の変化率が「−４０％」である。この場合、フェールオーバ前後応答性能比の補正値は、上記の式（２）から以下のように算出される。
【００６３】
１÷［（−４０＋１００）÷１００］＝１．６６６・・≒１．６７
【００６４】
算出部１２１は、以下のようにフェールオーバ前後応答性能比の補正値「１．６７」にフェールオーバ前後応答性能比の重み値「２０」を乗算して重み付けする。また、算出部１２１は、ダウンタイム「１０」にダウンタイム見積の重み値「２」を乗算して重み付けする。そして、算出部１２１は、重み付けした値を加算してユーザ端末１３に対する影響の度合いを算出する。
【００６５】
ユーザ端末１３に対する影響の度合い＝１．６７×２０＋１０×２
＝５４
【００６６】
このユーザ端末１３に対する影響の度合いは、ユーザ端末１３での応答時間の変化率とダウンタイムから算出される。ユーザ端末１３での応答時間の変化率とダウンタイムは、システムの状況により動的に変化する。このため、ユーザ端末１３に対する影響の度合いは、システムの状況により動的に変化する。
【００６７】
算出部１２１は、算出の結果を優先度情報テーブルに格納する。例えば、算出部１２１は、サービスの顧客名に対応付けて、サービスの重要度を静的優先度とし、ユーザ端末１３に対する影響の度合いを動的優先度として、優先度情報テーブルに格納する。また、算出部１２１は、静的優先度と動的優先度を加算した値を調査優先度として、優先度情報テーブルに格納する。これにより、図７に示すように、クラウド利用者「顧客Ａ」は、静的優先度が「８１」、動的優先度が「５４」、調査優先度が「１３５」と格納される。
【００６８】
出力部１２２は、各種の出力を行う。例えば、出力部１２２は、顧客ごとに、算出部１２１により算出された優先度と、影響の度合いと、サービスの重要度を担当者端末２００に出力する。例えば、出力部１２２は、優先度情報格納領域１１３に記憶された、図７に示す優先度情報テーブルの情報を表示した画面を担当者端末２００に表示させる。図７の例では、静的優先度のみの判断では顧客Ａの優先度が高いが、動的優先度を加味することで顧客Ｂの調査優先度が高くなり、顧客Ｂ、顧客Ａ、顧客Ｃの順に優先すべきという結果となる。このように、動的優先度を加味した優先度を出力することで、サービスが複数のデータセンタに跨り、ユーザ端末１３への影響の大きいサービスに対して高い値でトラブルの調査の優先度を出力できる。
【００６９】
ここで、優先度を算出する流れの一例を説明する。図８は、優先度を算出する流れの一例を示す図である。図８の例では、東アジアリージョンのデータセンタ１１Ａと、北米リージョンのデータセンタ１１Ｂの間で、顧客Ａおよび顧客Ｂのサービスに係るシステムが仮想マシン（ＶＭ）によりＨＡクラスタが構成されている。顧客Ａの各エンドユーザのユーザ端末１３は、顧客Ａのシステムの運用系および待機系の仮想マシンとの応答時間を測定し、コントロールセンタ１２の管理サーバ１００へ送信する。図８の例では、データセンタ１１Ａの仮想マシンとの応答時間が１０秒であり、データセンタ１１Ｂの仮想マシンとの応答時間が８秒であるものとする。顧客Ｂの各エンドユーザのユーザ端末１３も、顧客Ｂのシステムの運用系および待機系の仮想マシンとの応答時間を測定し、コントロールセンタ１２の管理サーバ１００へ送信する。図８の例では、データセンタ１１Ａの仮想マシンとの応答時間が２秒であり、データセンタ１１Ｂの仮想マシンとの応答時間が３８秒であるものとする。管理サーバ１００は、顧客のシステムごとに、ユーザ端末１３と各データセンタ１１との応答時間を記憶する。
【００７０】
データセンタ１１Ａにトラブルが発生した場合、顧客Ａおよび顧客Ｂのシステムは、運用系から待機系へ移行する。各データセンタ１１は、多数の顧客のシステムが稼働しているため、データセンタ１１でトラブルが発生すると、多数の顧客から調査依頼がコントロールセンタ１２へ送られる。
【００７１】
管理サーバ１００では、優先度算出処理を行って、顧客のシステムごとに、対応の優先度を算出する。例えば、管理サーバ１００では、顧客のシステムごとに、ユーザ端末１３と各データセンタ１１との応答時間から応答時間の変化率を算出する。例えば、管理サーバ１００は、データセンタ１１ごとに、ユーザ端末１３との最も新しい応答時間を合計する。そして、管理サーバ１００は、運用系のノードの応答時間の合計をＴ１、待機系のノードの応答時間の合計をＴ２として、上述の式（１）から応答時間の変化率を算出する。図８の例では、顧客Ａの応答時間の変化率が＋１４３％（＝［（７３／３０）−１］×１００）と算出される。顧客Ｂの応答時間の変化率が−３７％（＝［（５６／９０）−１］×１００）と算出される。図８の例では、フェールオーバ前後応答性能比として、顧客Ａの応答時間の変化率が１４３％、顧客Ｂの応答時間の変化率が−３７％と示されている。なお、応答時間の変化率は、何れかの１つのユーザ端末１３での各データセンタ１１との応答時間から求めてもよい。また、応答時間の変化率は、例えば、直近３０分間など直近所定期間に測定された、ユーザ端末１３での各データセンタ１１との応答時間から求めてもよい。
【００７２】
管理サーバ１００では、顧客のシステムごとに、応答時間の変化率から式（２）によりフェールオーバ前後応答性能比の補正値を求める。そして、管理サーバ１００では、顧客のシステムごとに、フェールオーバ前後応答性能比の補正値と、不図示のダウンタイムとを重み付け加算して、ユーザ端末１３に対する影響の度合いを算出する。また、管理サーバ１００では、顧客のシステムごとに、不図示の業務継続要件レベルの値と、重要顧客指数の値を重み付け加算して、サービスの重要度を算出する。そして、管理サーバ１００では、ユーザ端末１３への影響の度合いと、サービスの重要度から、対応の優先度を算出する。図８の例では、静的優先度として、顧客Ａのサービスの重要度が５５、顧客Ｂのサービスの重要度が４０と示されている。また、動的優先度として、顧客Ａのユーザ端末１３への影響の度合いが８、顧客Ｂのユーザ端末１３への影響の度合いが２４と示されている。また、調査優先度として、顧客Ａの優先度が６３、顧客Ｂの優先度が６４と示されている。トラブル対応業務を行う担当者は、表示された優先度から何れの顧客のサービスから優先して調査、対応を行うか判断できる。
【００７３】
［処理の流れ］
次に、実施例１に係る管理サーバ１００が優先度を算出する優先度算出処理の流れについて説明する。図９は、優先度算出処理の手順の一例を示すフローチャートである。この優先度算出処理は、所定のタイミング、例えば、担当者端末２００から優先度の表示を指示する要求を受け付けたタイミングで実行される。
【００７４】
算出部１２１は、サービスごとに、業務継続要件レベルの値に業務継続要件レベルの重み値を乗算した値と、重要顧客指数の値に重要顧客指数の重み値を乗算した値を加算してサービスの重要度を算出する（Ｓ１０）。
【００７５】
算出部１２１は、サービスごとに、運用系のノードの応答時間と、待機系のノードとの応答時間から応答時間の変化率を算出する（Ｓ１１）。算出部１２１は、サービスごとに、応答時間の変化率およびサービスのダウンタイムを用いて、当該サービスのユーザ端末１３に対する影響の度合いを算出する（Ｓ１２）。
【００７６】
算出部１２１は、サービスごとに、サービスの重要度の値とユーザ端末１３に対する影響の度合いの値を加算して、サービスごとの優先度を算出する（Ｓ１３）。算出部１２１は、算出の結果を優先度情報テーブルに格納する（Ｓ１４）。出力部１２２は、優先度情報テーブルの情報を表示した画面を担当者端末２００に表示させ（Ｓ１５）、処理を終了する。
【００７７】
［効果］
上述してきたように、管理サーバ１００は、複数のデータセンタ１１のノードに分かれ、クラスタ構成により運用される複数のサービスを運用系から待機系へ引き継ぐ場合の複数のサービスをそれぞれ利用するユーザ端末１３の影響の度合いを算出する。また、管理サーバ１００は、複数のサービスそれぞれの重要度を算出する。管理サーバ１００は、ユーザ端末１３への影響の度合いと、複数のサービスそれぞれの重要度とに基づき、サービスごとの優先度を算出する。管理サーバ１００は、算出された優先度を出力する。これにより、管理サーバ１００は、対応の効率化を支援できる。
【００７８】
また、管理サーバ１００は、ユーザ端末１３と複数のデータセンタ１１のノードとの応答時間を示す応答時間情報と、複数のデータセンタのノード間の通信時間を示す通信時間情報を取得する。管理サーバ１００は、複数のサービスごとに、応答時間情報が示すユーザ端末１３と運用系のノードおよび待機系のノードとの応答時間から応答時間の変化率を算出する。管理サーバ１００は、運用系と待機系のノード間の通信時間から当該サービスのダウンタイムを算出する。管理サーバ１００は、応答時間の変化率およびサービスのダウンタイムを用いて、サービスのユーザ端末１３に対する影響の度合いを算出する。これにより、管理サーバ１００は、サービスに係るシステムが複数のデータセンタ１１間で移行する場合のサービスのユーザ端末１３に対する影響の度合いを算出できる。
【００７９】
また、本実施例に係る管理サーバ１００は、複数のサービスごとに、当該サービスに対して定められた優先レベルと、当該サービスの提供元（クラウド利用者）に対して定められた優先レベルから当該サービスの重要度を算出する。これにより、管理サーバ１００は、対応を優先するクラウド利用者やサービスの優先レベルを高くすることで、サービスの重要度を高くできる。
【００８０】
また、本実施例に係る管理サーバ１００は、優先度に対応付けて、影響の度合いと重要度を出力する。トラブル対応業務を行う担当者は、表示されたユーザ端末１３に対する影響の度合いとサービスの重要度から、ユーザ端末１３に対する影響やサービスの重要度を判別して、調査、対応を行うことができる。これにより、管理サーバ１００は、対応の効率化を支援できる。
【実施例２】
【００８１】
さて、これまで開示の装置に関する実施例について説明したが、開示の技術は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【００８２】
例えば、上記の実施例では、ユーザ端末１３と運用系のノードおよび待機系のノードとの応答時間およびダウンタイムからユーザ端末１３への影響の度合いを算出する場合について説明したが、開示の装置はこれに限定されない。例えば、運用系のノードおよび待機系のノードのネットワークトラフィック、サーバのアクセス数、データベースのトランザクション数といった処理数の変化率をさらに重み付け加算してユーザ端末１３への影響の度合いを算出してもよい。
【００８３】
また、上記の実施例では、サービスごとに、ユーザ端末１３への影響の度合いの値と、サービスの重要度の値を加算して優先度を算出する場合について説明したが、開示の装置はこれに限定されない。例えば、ユーザ端末１３への影響の度合いの値と、サービスの重要度の値の重み付け加算など、所定の演算により優先度を算出してもよい。
【００８４】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的状態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、取得部１２０、算出部１２１および出力部１２２の各処理部が適宜統合されてもよい。また、各処理部の処理が適宜複数の処理部の処理に分離されてもよい。さらに、各処理部にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【００８５】
［優先度算出プログラム］
また、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することもできる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。図１０は、優先度算出プログラムを実行するコンピュータを示す図である。
【００８６】
図１０に示すように、コンピュータ３００は、ＣＰＵ（Central  Processing  Unit）３１０、ＨＤＤなどの記憶装置３２０、ＲＡＭなどのメモリ３４０を有する。これら３００〜３４０の各部は、バス４００を介して接続される。
【００８７】
記憶装置３２０には上記の取得部１２０、算出部１２１および出力部１２２と同様の機能を発揮する優先度算出プログラム３２０ａが予め記憶される。なお、優先度算出プログラム３２０ａについては、適宜分離しても良い。
【００８８】
また、記憶装置３２０は、各種情報を記憶する。例えば、記憶装置３２０は、運用ポリシー格納領域３２０ｂと、顧客管理情報格納領域３２０ｃと、運用状況情報格納領域３２０ｄと、優先度情報格納領域３２０ｅを有する。運用ポリシー格納領域３２０ｂ、顧客管理情報格納領域３２０ｃ、運用状況情報格納領域３２０ｄおよび優先度情報格納領域３２０ｅは、上述の運用ポリシー格納領域１１０、顧客管理情報格納領域１１１、運用状況情報格納領域１１２、優先度情報格納領域１１３と同様のデータを記憶する。
【００８９】
そして、ＣＰＵ３１０が、優先度算出プログラム３２０ａを記憶装置３２０から読み出してメモリ３４０上で実行することで、優先度算出プロセス３４０ａとして機能する。この優先度算出プロセス３４０ａは、記憶装置３２０から適宜各種データを読み出して処理を実行することで、実施例の各処理部と同様の動作を実行する。すなわち、優先度算出プロセス３４０ａは、取得部１２０、算出部１２１および出力部１２２と同様の動作を実行する。
【００９０】
なお、上記した優先度算出プログラム３２０ａについては、必ずしも最初から記憶装置３２０に記憶させることを要しない。
【００９１】
例えば、コンピュータ３００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」にプログラムを記憶させておく。そして、コンピュータ３００がこれらからプログラムを読み出して実行するようにしてもよい。
【００９２】
さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ３００に接続される「他のコンピュータ（またはサーバ）」などにプログラムを記憶させておく。そして、コンピュータ３００がこれらからプログラムを読み出して実行するようにしてもよい。
【符号の説明】
【００９３】
１０  データセンタシステム
１１  データセンタ
１２  コントロールセンタ
１３  ユーザ端末
１３Ａ  測定エージェント
２０  サーバ装置
２１  運用管理サーバ
１００  管理サーバ
１０１  通信部
１０２  記憶部
１０３  制御部
１１０  運用ポリシー格納領域
１１１  顧客管理情報格納領域
１１２  運用状況情報格納領域
１１３  優先度情報格納領域
１２０  取得部
１２１  算出部
１２２  出力部
２００  担当者端末
【図１】
0006520512.tif 000002
【図２】
0006520512.tif 000003
【図３】
0006520512.tif 000004
【図４】
0006520512.tif 000005
【図５】
0006520512.tif 000006
【図６】
0006520512.tif 000007
【図７】
0006520512.tif 000008
【図８】
0006520512.tif 000009
【図９】
0006520512.tif 000010
【図１０】
0006520512.tif 000011