(57)【要約】【課題】一実施形態は、保守に伴う業務を低減することができる。【解決手段】一実施形態に係る保守方法は、判定する工程と、変更する工程と、送信する工程とを含む。判定する工程は、サーバー内の複数のハードウェア構成要素のうちの第１のハードウェア構成要素が故障したことを検出した場合に、第１のハードウェア構成要素の故障を第１のエラーレベルと判定する。変更する工程は、第１のハードウェア構成要素の故障により、サーバー上で稼働するゲストドメインに割り当てられているハードウェア構成要素が減らないと判定した場合、第１のエラーレベルを、第１のエラーレベルよりも低い第２のエラーレベルへと変更する。送信する工程は、変更する工程により変更された第２のエラーレベルに対応するエラー情報を生成し、エラー情報をセンター装置に送信する。【選択図】図１２
2017033261.tif 000002
【特許請求の範囲】
【請求項１】
サーバー内の複数のハードウェア構成要素のうちの第１のハードウェア構成要素が故障したことを検出した場合に、前記第１のハードウェア構成要素の故障を第１のエラーレベルと判定する工程と、
前記第１のハードウェア構成要素の故障により、前記サーバー上で稼働するゲストドメインに割り当てられているハードウェア構成要素が減るか否かを判定し、前記割り当てられているハードウェア構成要素が減らないと判定した場合、前記第１のエラーレベルを、前記第１のエラーレベルよりも低い第２のエラーレベルへと変更する工程と、
前記変更する工程により変更された前記第２のエラーレベルに対応するエラー情報を生成し、前記エラー情報をセンター装置に送信する工程と、
を含む、サーバーが実行する保守方法。
【請求項２】
前記変更する工程は、前記故障が検出された前記第１のハードウェア構成要素が、前記ゲストドメインに割り当てられていない場合に、前記割り当てられているハードウェア構成要素が減らないと判定する、ことを特徴とする請求項１に記載の保守方法。
【請求項３】
前記変更する工程は、
前記故障が検出された前記第１のハードウェア構成要素が、前記ゲストドメインに割り当てられている場合に、前記故障が検出された前記第１のハードウェア構成要素の代替として用いることが可能な第２のハードウェア構成要素を検索する工程と、
前記検索する工程において、前記第２のハードウェア構成要素が見つかった場合に、前記割り当てられているハードウェア構成要素が減らないと判定する工程と、
を含む、ことを特徴とする請求項１又は２に記載の保守方法。
【請求項４】
前記検索する工程は、前記複数のハードウェア構成要素のそれぞれについての縮退を実行する予定であるか否かを示す縮退予約情報と、交換を実行する予定であるか否かを示す交換予約情報とを含む構成情報において、前記縮退予約情報が縮退を実行する予定でなく、且つ、前記交換予約情報が交換を実行する予定でないハードウェア構成要素のうちから、前記第２のハードウェア構成要素を決定する工程、を含む、
ことを特徴とする請求項３に記載の保守方法。
【請求項５】
前記構成情報は、更に、前記複数のハードウェア構成要素に対して設定されている監視通報モードを含み、
前記変更する工程は、更に、前記構成情報において、前記故障が検出された前記第１のハードウェア構成要素の前記監視通報モードが、前記監視通報モードによるエラーレベルの変更を実行する変更モードに設定されている場合に、前記第２のエラーレベルを、前記第２のエラーレベルよりも低い第３のエラーレベルへと変更する工程を含む、ことを特徴とする請求項４に記載の保守方法。
【請求項６】
サーバー内の複数のハードウェア構成要素のうちの第１のハードウェア構成要素が故障したことを検出した場合に、前記第１のハードウェア構成要素の故障を第１のエラーレベルと判定する判定部と、
前記第１のハードウェア構成要素の故障により、前記サーバー上で稼働するゲストドメインに割り当てられているハードウェア構成要素が減るか否かを判定し、前記割り当てられているハードウェア構成要素が減らないと判定した場合、前記第１のエラーレベルを、前記第１のエラーレベルよりも低い第２のエラーレベルへと変更する変更部と、
前記変更部により変更された前記第２のエラーレベルに対応するエラー情報を生成し、前記エラー情報をセンター装置に送信する送信部と、
を含む、サーバー。
【請求項７】
サーバー内の複数のハードウェア構成要素のうちの第１のハードウェア構成要素が故障したことを検出した場合に、前記第１のハードウェア構成要素の故障を第１のエラーレベルと判定し、
前記第１のハードウェア構成要素の故障により、前記サーバー上で稼働するゲストドメインに割り当てられているハードウェア構成要素が減るか否かを判定し、前記割り当てられているハードウェア構成要素が減らないと判定した場合、前記第１のエラーレベルを、前記第１のエラーレベルよりも低い第２のエラーレベルへと変更し、
変更された前記第２のエラーレベルに対応するエラー情報を生成し、前記エラー情報をセンター装置に送信する、
処理をサーバーに実行させる保守プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、保守方法、サーバー、及び保守プログラムに関する。
【背景技術】
【０００２】
サーバーは、サーバーが含むハードウェア構成要素に故障等のエラーが発生しても、サーバーシステム群の中で冗長構成を取ることで、サーバー内での故障箇所の切り離しにより運用を継続することができるように構成されることが多い。そのため、サーバー自体が停止してしまう故障が発生した場合にサーバーをシステム群から切り離すなどし、その後、故障したサーバーを丸ごと交換する、又は故障した部品をまとめて交換するというように、即時の保守を実行しない保守形態が存在する。
【０００３】
一方で、基幹業務向けのサーバーでは、２４時間３６５日の業務の継続が重視される。そのため、重大なシステムダウンにつながる可能性があれば、予防的に保守する傾向がある。例えば、サーバーが含むハードウェア構成要素の故障によりエラーが発生した場合、予防保守的に全てのエラーをサービスセンター装置に通知して、保守作業を要求することが行われている。
【０００４】
基幹業務向けのサーバーを監視する仕組みの１つに、サーバーがサービスの提供に用いるＣＰＵ（Central Processing Unit）とは異なる監視装置上で稼働するファームウェアでサーバーシステムの監視と制御を行うものがある。この仕組みでは、例えば、サーバーのハードウェア構成要素の故障によりエラーが発生した場合、ファームウェアはサーバーのエラーについての情報を、保守管理を提供するセンター装置に通知する。
【０００５】
これに関し、仮想ボリュームを構成する物理リソースに障害が発生した場合、ユーザが必要とする情報を管理サーバ装置に通知するための技術が知られている（例えば、特許文献１）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特表２０１４−５１０３１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
サーバーに対する保守の要件は、サーバー上で稼働するシステムによって異なることがある。例えば、上述のように、基幹業務向けのサーバーは業務の継続が重視されるため、サーバー上で稼働するシステムのダウンにつながる可能性があればエラーを通知して故障部品の交換等の保守作業を即時に実行することが望ましい。一方で、基幹業務以外の用途向けのサーバーは冗長構成により、一部のハードウェア構成要素に故障が発生したとしても、業務の継続に支障をきたさなければ、システムの運用を継続してもよいことがある。この場合、例えば、故障した一部のハードウェア構成要素に保守作業を即時に実行しなくてもよい。そして、しばらくたった後に、サーバー内で故障した複数のハードウェア構成要素をまとめて交換するといった保守作業が可能である。しかしながら、例えば、保守サービスを提供する場合に、サーバーに対する保守の要件はシステムによって異なっているにもかかわらず、一律に同じ条件で保守を提供することがある。この場合、例えば、サーバー上で稼働するシステムの運用に支障をきたさず、業務に影響を与えない場合にも即時の保守作業を要求するなどしてしまい、保守作業の増加や、費用の増加を招くことがある。本発明の一つの態様の目的は、保守に伴う業務を低減することである。
【課題を解決するための手段】
【０００８】
本発明の一つの態様の保守方法は、判定する工程と、変更する工程と、送信する工程とを含む。判定する工程は、サーバー内の複数のハードウェア構成要素のうちの第１のハードウェア構成要素が故障したことを検出した場合に、第１のハードウェア構成要素の故障を第１のエラーレベルと判定する。変更する工程は、第１のハードウェア構成要素の故障により、サーバー上で稼働するゲストドメインに割り当てられているハードウェア構成要素が減るか否かを判定する。そして、変更する工程は、割り当てられているハードウェア構成要素が減らないと判定した場合、第１のエラーレベルを、第１のエラーレベルよりも低い第２のエラーレベルへと変更する。送信する工程は、変更する工程により変更された第２のエラーレベルに対応するエラー情報を生成し、エラー情報をセンター装置に送信する。
【発明の効果】
【０００９】
一つの側面によれば、保守に伴う業務を低減することができる。
【図面の簡単な説明】
【００１０】
【図１】例示的な保守システムのシステム構成を示す図である。
【図２】保守システムの監視装置が実行するエラー情報の送信処理の動作フローを例示する図である。
【図３】通知内容情報を例示する図である。
【図４】保守システムのセンター装置が実行するエラー情報の受信処理の動作フローを例示する図である。
【図５】実施形態に係る保守システムを例示する図である。
【図６】実施形態に係るサーバーの機能ブロック構成を例示する図である。
【図７】サーバー上で稼働するゲストドメインを例示する図である。
【図８】実施形態に係るエラー情報の送信処理を例示する図である。
【図９】リソース使用状況情報を例示する図である。
【図１０】構成情報を例示する図である。
【図１１】故障情報を例示する図である。
【図１２】エラーレベル決定処理の動作フローを例示する図である。
【図１３】実施形態に係るサーバーを実現するためのコンピュータのハードウェア構成を例示する図である。
【発明を実施するための形態】
【００１１】
以下、図面を参照しながら、本発明のいくつかの実施形態について詳細に説明する。なお、複数の図面において対応する要素には同一の符号を付す。
【００１２】
図１は、例示的な保守システム１００のシステム構成を示す図である。保守システム１００は、保守サービスを受けるサーバー１０１と、保守サービスを提供する業者の装置であるセンター装置１０２とを含む。サーバー１０１は、例えば、監視装置１１１と、システムボード１１２とを含む。システムボード１１２は、例えば、ＣＰＵ、メモリ、電源装置（ＰＳＵ）、ファン、センサなどのハードウェア構成要素１２０を含む。監視装置１１１は、ＸＳＣＦ（eXtended System Control Facility）などのサービスプロセッサであってよく、例えば、サーバー１０１内のハードウェア構成要素１２０の監視と制御とを行う機能を備える。センター装置１０２は、例えば、保守サービスを提供する業者が管理するコンピュータである。サーバー１０１は、例えば、ネットワーク１０５を介してセンター装置１０２と接続されてよい。
【００１３】
続いて、保守システム１００によるサーバー１０１の保守処理の流れについて説明する。
【００１４】
図２は、保守システム１００の監視装置１１１が実行するエラー情報の送信処理の動作フローを例示する図である。なお、監視装置１１１が、サーバー１０１内のハードウェア構成要素１２０の監視を開始すると、本動作フローは開始してよい。
【００１５】
ステップ２０１（以降、ステップを“Ｓ”と記載し、例えば、Ｓ２０１と表記する）において、監視装置１１１は、例えば、或るハードウェア構成要素１２０に故障が発生したことを検出する。Ｓ２０２において監視装置１１１は、検出したハードウェア構成要素１２０の故障についてのエラーレベルを決定する。エラーレベルは、例えば、ハードウェア構成要素の故障が与えるシステムへの影響等に基づいた所定の基準に従って決定されてよい。Ｓ２０３において監視装置１１１は、エラーレベルに応じた故障通報レベルを特定し、また、エラー情報に含める情報を特定し、それらの情報を用いてエラー情報を生成する。
【００１６】
図３は、通知内容情報３００を例示する図である。図３の例では、通知内容情報３００の各エントリは、例えば、エラーレベル、説明、故障通報レベル、ＳＮＭＰトラップ通報、エラーログ、交換有無を含む。なお、ＳＮＭＰは、Simple Network Management Protocolの略称である。エラーレベルは、例えば、ハードウェア構成要素１２０に発生した故障の深刻度を表す情報である。説明は、例えば、同じエントリ内のエラーレベルに対する説明である。故障通報レベルは、例えば、同じエントリ内のエラーレベルでの保守作業を行う担当者への通報のレベルを示す情報である。ＳＮＭＰトラップ通報は、ＳＮＭＰトラップにより通報を行うか否かを示す情報である。エラーログは、エラーのログをエラー情報に含めるか否かを示す情報である。交換有無は、エラー情報で故障を通知するハードウェア構成要素１２０の交換作業を行うか否かを示す情報である。なお、図３の通知内容情報３００では、エラーレベルは、より上段のエントリが下段のエントリよりも高い深刻度となるように配置されている。即ち、エラーレベルは、「Ａ→Ｗ→Ｎ」の順でエラーの深刻度が低くなる例が示されている。以下では、例として、図３に示すエラーの深刻度の順序を用いて説明を行う。
【００１７】
そして、監視装置１１１は、Ｓ２０３において、通知内容情報３００を参照し、エラーレベルに応じた故障通報レベルを特定し、また、エラー情報に含める情報を特定し、それらの情報を用いてエラー情報を生成してよい。例えば、エラーレベルがＡ：アラームであれば、監視装置１１１は、センター装置１０２に保守作業の担当者への通報を行わせるようにエラー情報に故障通報レベル：有を設定する。故障通報レベルは、例えば、保守業務を行う担当者に、表示装置等を介してリモート通報でエラーメッセージの表示等を行って通報するか否かを示す情報であってよい。保守業務を行う担当者は、通報を受けると、エラー情報を通知してきたサーバー１０１の保守を実行してよい。また、監視装置１１１は、例えば、エラーレベルがＡ：アラームであれば、エラー情報において、ＳＮＭＰトラップ通報を有りに設定し、また、エラーログが有りであるため、エラーログをエラー情報に含め、更に交換有無を有に設定してよい。
【００１８】
Ｓ２０４において監視装置１１１は、生成したエラー情報をセンター装置１０２に送信する。なお、監視装置１１１は、更に、故障の検出されたハードウェア構成要素１２０の縮退などのリカバリ処理を実行してよい。
【００１９】
図４は、保守システム１００のセンター装置１０２が実行するエラー情報の受信処理の動作フローを例示する図である。例えば、センター装置１０２がエラー情報をサーバー１０１から受信すると、本動作フローは開始してよい。
【００２０】
Ｓ４０１においてセンター装置１０２は受信したエラー情報を分析する。Ｓ４０２においてセンター装置１０２は、分析結果に基づいて、エラー情報を通知してきたサーバー１０１の保守を実行するか否かを判定する。センター装置１０２は、例えば、エラー情報において故障通報レベル：有に設定されている場合に、保守ありと判定してよい。保守を実行しない場合（Ｓ４０２がＮｏ）、本動作フローは終了する。一方、保守を実行する場合（Ｓ４０２がＹｅｓ）、フローはＳ４０３へと進む。Ｓ４０３においてセンター装置１０２は、例えば、保守作業の担当者に保守作業の実行を指示する通報を行う。通報は、例えば、センター装置１０２に接続された表示装置等を介して保守作業の実行を指示するエラーメッセージを表示させる等を行うことで実行されてよい。保守業務を行う担当者は、保守作業の実行を指示する通報を受けると、エラー情報を通知してきたサーバー１０１の保守を実行してよい。
【００２１】
以上の例では、検出されたハードウェア構成要素１２０の故障に応じて決定されるエラーレベルにより保守の要否が決定され、保守作業が行われる。
【００２２】
しかし、サーバー１０１に対する保守の要件は、サーバー１０１上で稼働するシステムによって異なることがある。例えば、上述のように、基幹業務向けのサーバーは業務の継続が重視されるため、サーバー１０１上で稼働するシステムのダウンにつながる可能性があればエラーを通知して故障部品の交換等の保守作業を即時に実行することが望ましい。一方で、基幹業務以外の用途向けのサーバーは冗長構成により、一部のハードウェア構成要素１２０に故障が発生したとしても、業務の継続に支障をきたさなければ、システムの運用を継続してもよいことがある。この場合、例えば、故障した一部のハードウェア構成要素１２０に保守作業を即時に実行しなくてもよい。そして、例えば、しばらくたった後に、故障したサーバーを丸ごと交換する、或いは、サーバー内で故障した複数のハードウェア構成要素１２０をまとめて交換するといった保守作業が可能である。
【００２３】
しかし、上記の例では、保守サービスを提供する場合に、サーバー１０１に対する保守の要件はシステムによって異なり得るにもかかわらず、検出された故障に応じて一律に同じエラーレベルが決定される。そのため、異なる保守の要件が望まれる複数の保守システム１００に対して、同じ条件で保守を提供する。そして、例えば、基幹業務以外の用途向けのサーバーで、システムの運用に支障をきたさず、業務に影響を与えない場合にも即時の保守作業を要求するなどしてしまい、保守作業の増加や、費用の増加を招くことがある。
そのため、保守に伴う業務を低減することのできる技術が望まれている。
【００２４】
図５は、実施形態に係る保守システム５００を例示する図である。保守システム５００は、例えば、保守サービスを受けるサーバー５０１と、センター装置５０２とを含む。サーバー５０１は、例えば、ネットワーク５０５を介してセンター装置５０２と接続されてよい。センター装置５０２は、例えば、保守サービスを提供する業者のコンピュータである。
【００２５】
図６は、実施形態に係るサーバー５０１の機能ブロック構成を例示する図である。サーバー５０１は、例えば、監視装置６００、及び監視対象装置６１１を含む。監視対象装置６１１は、例えば、システムボードであってよく、ＣＰＵ、メモリ、電源装置（ＰＳＵ）、ファンなどのハードウェア構成要素６２０を含む。また、監視対象装置６１１は、例えば、ハードウェア構成要素６２０の故障を検出するセンサ６３０を含む。監視装置６００は、例えば、ＸＳＣＦ（eXtended System Control Facility）などであってよく、サーバー５０１内のハードウェア構成要素６２０の監視と制御とを行う機能を備える。監視装置６００は、例えば、制御部６０１及び記憶部６１０を含む。制御部６０１は、例えば、判定部６０３、変更部６０４、送信部６０５を含む。記憶部６１０は、例えば、上述の通知内容情報３００、並びに後述するリソース使用状況情報９００、構成情報１０００、故障情報１１００及びプログラムを記憶してよい。これらの機能部及び記憶部６１０に格納されている情報の更なる詳細については後述する。なお、制御部６０１は、例えば、センサ６３０から入力される故障に関する情報などの監視対象装置６１１から通知される情報に基づいて、ハードウェア構成要素６２０の故障を検出してよい。
【００２６】
また、監視装置６００の制御部６０１は、監視対象装置６１１に含まれるハードウェア構成要素６２０をシステムに組み込むか否かを決定する。そして、監視対象装置６１１に含まれるハードウェア構成要素６２０のうちで、監視装置６００の制御部６０１によってシステムに組み込まれたハードウェア構成要素６２０を用いてゲストドメインが稼働する。図７は、サーバー５０１上で稼働するゲストドメイン７００を例示する図である。図７に示されるように、サーバー５０１上では、複数のゲストドメイン７００が稼働していてよい。ゲストドメイン７００には、例えば、システムに組み込まれたハードウェア構成要素６２０がリソースとして割り当てられており、割り当てられたハードウェア構成要素６２０は、ゲストドメイン７００を運用するために使用される。また、ゲストドメイン７００は、例えば、サーバー５０１に接続するクライアントに、サービスを提供する仮想マシンであってよい。ゲストドメイン７００上では、オペレーティングシステム（ＯＳ）が稼働していてよく、また、ＯＳ上でアプリケーションが実行されてよい。
【００２７】
続いて、実施形態に係る監視通報モードについて説明する。実施形態に係る保守システム５００では、サーバー５０１上で稼働するシステムの要件に応じて、サーバー５０１のハードウェア構成要素６２０に、複数のモードから選択可能な監視通報モードが設定される。以下では、監視通報モードの例として、監視通報モードによるエラーレベルの軽減を実行せずに維持する維持モードと、監視通報モードによりエラーレベルを軽減する変更を行う変更モードとを用いる場合を例に説明を行う。維持モードは、例えば、基幹業務向けのサーバーなどの業務の継続に高い信頼性が要求されるサーバーなどに適用される。変更モードは、例えば、基幹業務以外の用途向けのサーバーなどに適用される。そして、監視通報モードが、維持モードではなく、変更モードに設定されている場合、監視装置６００の制御部６０１は、例えば、エラーレベルの見直しを実行し、エラーレベルをより低いレベルへと変更してよい。
【００２８】
また、例えば、エラーレベルの変更は、以下のように、ハードウェア構成要素６２０の故障により、サーバー５０１上で稼働するゲストドメイン７００によって使用されているリソースが減らないと判定できる場合に実行されてよい。
【００２９】
（１）故障の検出されたハードウェア構成要素６２０が、ゲストドメイン７００に割り当てられていない未使用のリソース（未使用リソース）である。
【００３０】
（２）故障の検出されたハードウェア構成要素６２０は、ゲストドメイン７００に割り当てられているリソース（使用リソース）であるが、縮退及び交換を実行することで代替リソースに交換できる。
【００３１】
例えば、上記の条件のいずれかを満たす場合、制御部６０１は、検出されたハードウェア構成要素６２０の故障により、ゲストドメイン７００に割り当てられているリソース（ハードウェア構成要素６２０）が減らないと判定してよい。この場合、システムの運用の継続に支障をきたさないことが推定される。そのため、エラーレベルを軽減する変更を実行してよい。
【００３２】
以上で述べたように、実施形態において制御部６０１は、例えば、所定の基準に従って決定されたエラーレベルを軽減する場合があり、それにより保守が実行される頻度などが軽減され得る。
【００３３】
図８は、実施形態に係るエラー情報の送信処理を例示する図である。図８のエラー情報の送信処理の動作フローは、一実施形態においては、サーバー５０１の起動時など、監視装置６００の制御部６０１がハードウェア構成要素６２０の監視を開始すると、開始してよい。
【００３４】
Ｓ８０１において、監視装置６００の制御部６０１は、監視対象装置６１１から通知された情報を基にリソース使用状況情報９００を生成する。
【００３５】
図９は、監視装置６００の制御部６０１が生成するリソース使用状況情報９００を例示する図である。図９に示すリソース使用状況情報９００において、各エントリは、識別情報と、使用状況とを含む。識別情報は、サーバー５０１に含まれる複数のハードウェア構成要素６２０のそれぞれを識別するための情報である。識別情報は、例えば、ハードウェア構成要素６２０の部品名であってよい。また、使用状況は、識別情報で識別されるハードウェア構成要素６２０の使用の状況を示す情報である。使用状況は、システムの使用状況と、ゲストドメイン７００の使用状況とを含む。システムの使用状況は、例えば、監視装置６００が、識別情報で識別されるハードウェア構成要素６２０をシステムに組み込んでいるか否かを示す情報であってよい。例えば、図９では、システム：使用はハードウェア構成要素６２０がシステムに組み込まれており、システムに使用されている状態を示す。システム：未使用はハードウェア構成要素６２０がシステムに組み込まれておらず、システムに使用されていない状態を示す。また、ゲストドメイン７００の使用状況は、例えば、いずれかのゲストドメイン７００に、識別情報で識別されるハードウェア構成要素６２０が割り当てられているか否かを示す情報であってよい。例えば、図９では、ゲストドメイン：使用は、識別情報で識別されるハードウェア構成要素６２０がゲストドメイン７００に割り当てられており、ゲストドメイン７００に使用されている状態を示す。ゲストドメイン：未使用は、識別情報で識別されるハードウェア構成要素６２０がゲストドメイン７００に割り当てられておらず、ゲストドメイン７００に使用されていない状態を示す。
【００３６】
続いて、図８のＳ８０２において監視装置６００の制御部６０１は、ハードウェア構成要素６２０に対して監視通報モードを設定する。監視通報モードの設定は、例えば、サーバー５０１を運用するユーザが、サーバー５０１が備える入力装置などを介して、監視通報モードを指定する情報を制御部６０１に入力することで実行されてよい。或いは、例えば、ハードウェア構成要素６２０に対して適用する監視通報モードが予め登録されているデータを記憶部６１０から読み出すことで、監視通報モードの設定が実行されてもよい。なお、監視通報モードは、例えば、サーバー５０１単位で、サーバー５０１に含まれるハードウェア構成要素６２０に一括して設定されてもよい。
【００３７】
Ｓ８０３において監視装置６００の制御部６０１は、例えば、Ｓ８０１で生成したリソース使用状況情報９００と、Ｓ８０２で設定された監視通報モードとに基づいて、構成情報１０００を生成する。
【００３８】
図１０は、構成情報１０００を例示する図である。図１０は、ハードウェア構成要素６２０のうちのＣＰＵに対して生成された構成情報１０００を例示しているが、メモリや、ファンなどその他のハードウェア構成要素６２０についても構成情報１０００が生成されてよい。或いは、これらの複数種類のハードウェア構成要素６２０をまとめて含む１つの構成情報１０００が生成されてもよい。図１０に示す構成情報１０００において、各エントリは、識別情報と、使用状況と、監視通報モード、縮退予約、及び交換予約を含み、これらの情報はエントリにおいて対応付けられている。識別情報及び使用状況（システム及びゲストドメイン７００）は、例えば、リソース使用状況情報９００に登録されている識別情報及び使用状況（システム及びゲストドメイン７００）と同様の情報であってよい。また、監視通報モードには、Ｓ８０２で設定された監視通報モードが登録されてよい。なお、図１０においては、各エントリに維持モード及び変更モードが示されているが、実際にはエントリに対して維持モード又は変更モードのいずれかのモードが設定されていてよい。縮退予約は、縮退可能なハードウェア構成要素６２０に故障が発生した場合に、そのハードウェア構成要素６２０が縮退動作を予約済みであるか否かを示す情報であってよい。また、交換予約は、発生した縮退可能なハードウェア構成要素６２０における故障に対して、ハードウェア構成要素６２０が代替対象として予約済みであるか否かを示す情報であってよい。なお、制御部６０１は、例えば、サーバーの稼働開始時などのサーバーの内部のハードウェア構成要素６２０に故障が発生していない状況では、縮退予約及び交換予約をいずれも無に設定してよい。
【００３９】
Ｓ８０４において監視装置６００の制御部６０１は、監視対象装置６１１内のハードウェア構成要素６２０に故障が検出されたか否かを判定する。故障が検出されていない場合（Ｓ８０４がＮｏ）、フローはＳ８０４の処理を繰り返し、故障の発生を監視する。一方、故障が検出された場合（Ｓ８０４がＹｅｓ）、制御部６０１は、検出された故障についての情報を故障情報１１００に登録する。
【００４０】
図１１は、故障情報１１００を例示する図である。図１１に示す故障情報１１００において、各エントリは、故障が検出されたハードウェア構成要素６２０の識別情報と、その故障に関する情報とを含み、これらの情報は互いに対応付けられている。故障情報１１００の識別情報は、図９のリソース使用状況情報９００及び図１０の構成情報１０００の識別情報と対応していてよい。即ち、例えば、サーバー５０１の監視対象装置６１１に含まれるハードウェア構成要素６２０に対して同じ識別情報がリソース使用状況情報９００、構成情報１０００、及ぶ故障情報１１００において設定されてよい。また、図１１の例では、識別情報で識別されるハードウェア構成要素６２０の故障に関する情報として発生頻度と、波及範囲とが示されている。発生頻度は、例えば、識別情報で識別されるハードウェア構成要素６２０において故障が発生する頻度を表す情報であってよい。波及範囲は、例えば、識別情報で識別されるハードウェア構成要素６２０に発生した故障が他のハードウェア構成要素６２０に影響を与える場合に、その影響を与えるハードウェア構成要素６２０の範囲を示す情報であってよい。監視装置６００の制御部６０１は、例えば、或るハードウェア構成要素６２０に故障を検出した場合に、故障が検出されたハードウェア構成要素６２０についての情報を故障情報１１００に登録してよい。そして、制御部６０１は、例えば、故障情報１１００に登録した情報を参照することで、故障が検出されたハードウェア構成要素６２０についての情報を取得してよい。Ｓ８０４において故障が検出された場合（Ｓ８０４がＹｅｓ）、監視装置６００の制御部６０１が、故障情報１１００に、故障についての情報を登録すると、フローはＳ８０５へと進む。
【００４１】
Ｓ８０５において監視装置６００の制御部６０１は、検出したハードウェア構成要素６２０の故障についてのエラーレベルを判定する。エラーレベルの判定は、上述のＳ２０２の処理と同様にして判定されてよく、例えば、所定の基準に従って判定されてよい。Ｓ８０６において、監視装置６００の制御部６０１は、エラーレベル決定処理を実行する。エラーレベル決定処理では、監視装置６００の制御部６０１は、故障が検出されたハードウェア構成要素６２０の使用状況、交換の可否、監視通報モードなどに基づいて可能な場合にはエラーレベルの軽減を実行し、エラーレベルを決定する。なお、エラーレベル決定処理の詳細については、図１２を参照して後述する。
【００４２】
Ｓ８０７において監視装置６００の制御部６０１は、Ｓ８０６で決定されたエラーレベルに応じた故障通報レベルと、エラー情報に含める情報とを特定し、それらの情報を用いてエラー情報を生成する。例えば、Ｓ８０７において制御部６０１は、Ｓ８０６で決定されたエラーレベルに対応する通知内容情報３００のエントリから、故障通報レベル、ＳＮＭＰトラップ通報、エラーログ、保守の実行の有無を特定し、有に設定されている情報に従ってエラー情報を生成してよい。
【００４３】
続いて、Ｓ８０８において監視装置６００の制御部６０１は、エラー情報をセンター装置５０２に送信し、フローはＳ８０４に戻る。
【００４４】
以上の図８の動作フローにおいて、Ｓ８０５の処理では、監視装置６００の制御部６０１は、例えば、判定部６０３として機能する。また、Ｓ８０６の処理では、監視装置６００の制御部６０１は、例えば、変更部６０４として機能する。Ｓ８０７〜Ｓ８０８の処理では、監視装置６００の制御部６０１は、例えば、送信部６０５として機能する。
【００４５】
図１２は、図８のＳ８０６で実行されるエラーレベル決定処理の動作フローを例示する図である。なお、以下の説明は、Ｓ８０５において制御部６０１がエラーレベルをＡ：アラームと判定した場合を例に説明する。しかしながら、実施形態はこれに限定されるものではなく、その他のレベルに決定されたエラーレベルに対してもエラーレベル決定処理を実行することでエラーレベルの軽減が実行されてよい。
【００４６】
Ｓ１２０１において監視装置６００の制御部６０１は、代替リソースの検索が完了しているか否かを判定する。例えば、Ｓ１２０１において監視装置６００の制御部６０１は、Ｓ８０４で故障が検出されたハードウェア構成要素６２０の代替として利用できる可能性のあるハードウェア構成要素６２０のエントリを構成情報１０００から特定する。代替として利用できる可能性のあるハードウェア構成要素６２０は、例えば、同じ種類のハードウェア構成要素６２０であってよい。例えば、故障したハードウェア構成要素６２０がＣＰＵであれば、代替として利用できる可能性のあるハードウェア構成要素６２０は、サーバー５０１の監視対象装置６１１に含まれるＣＰＵであってよい。また、故障したハードウェア構成要素６２０がメモリであれば、代替として利用できる可能性のあるハードウェア構成要素６２０は、サーバー５０１の監視対象装置６１１に含まれるメモリであってよい。そして、監視装置６００の制御部６０１は、例えば、特定された構成情報１０００のエントリに、未選択のエントリがある場合には、Ｓ１２０１をＮｏと判定し、未選択のエントリのうちから１つのエントリを選択する。一方、全てのエントリを選択し終わっている場合には、監視装置６００の制御部６０１は、Ｓ１２０１においてＹｅｓと判定する。
【００４７】
Ｓ１２０２において制御部６０１は、選択したエントリの識別情報が、Ｓ８０４で故障が検出されたハードウェア構成要素６２０の識別情報と同じか否かを判定する。故障が検出されたハードウェア構成要素６２０の識別情報は、例えば、故障情報１１００から取得することができる。選択したエントリの識別情報が、故障が検出されたハードウェア構成要素６２０の識別情報と異なる場合（Ｓ１２０２がＮｏ）、選択したエントリの識別情報で識別されるハードウェア構成要素６２０は、故障が検出されたハードウェア構成要素６２０ではない。この場合、選択したエントリの識別情報で識別されるハードウェア構成要素６２０は、故障が検出されたハードウェア構成要素６２０の代替として利用できる可能性がある。そのため、以降のＳ１２０３〜Ｓ１２０７において、制御部６０１は、選択したエントリの識別情報で識別されるハードウェア構成要素６２０が代替リソースとして利用できるか否かを確認する処理を実行する。
【００４８】
まず、Ｓ１２０３において、制御部６０１は、故障したハードウェア構成要素６２０の代替として利用できるハードウェア構成要素６２０が既に見つかっているか否かを判定する。既に見つかっている場合（Ｓ１２０３がＹｅｓ）、フローはＳ１２０１へと戻る。一方、故障したハードウェア構成要素６２０の代替として利用できるハードウェア構成要素６２０が見つかっていない場合（Ｓ１２０３がＮｏ）、フローはＳ１２０４へと進む。なお、Ｓ１２０３において制御部６０１は、例えば、後述する代替リソース検索済フラグがオンに設定されている場合にＹｅｓと判定し、代替リソース検索済フラグがオフに設定されている場合にＮｏと判定してよい。
【００４９】
Ｓ１２０４において制御部６０１は、Ｓ１２０１で選択したエントリの識別情報で識別されるハードウェア構成要素６２０が、構成情報１０００においてシステムで使用であるか否かを確認する。システムで未使用であれば（Ｓ１２０４がＮｏ）、そのハードウェア構成要素６２０は、例えば、システムに組み込まれておらず、代替として利用できないため、フローはＳ１２０１へと戻る。一方、Ｓ１２０１で選択したエントリの識別情報で識別されるハードウェア構成要素６２０が、構成情報１０００においてシステムで使用であれば（Ｓ１２０４がＹｅｓ）、フローはＳ１２０５へと進む。
【００５０】
Ｓ１２０５において制御部６０１は、Ｓ１２０１で選択したエントリの識別情報で識別されるハードウェア構成要素６２０が、構成情報１０００においてゲストドメイン７００で使用中であるか否かを確認する。ゲストドメイン７００で使用中であれば（Ｓ１２０５がＹｅｓ）、そのハードウェア構成要素６２０は既にゲストドメイン７００に割り当てられて使用されており、代替として利用できないため、フローはＳ１２０１へと戻る。一方、Ｓ１２０１で選択したエントリの識別情報で識別されるハードウェア構成要素６２０が、構成情報１０００においてゲストドメイン７００で未使用であれば（Ｓ１２０５がＮｏ）、フローはＳ１２０６へと進む。
【００５１】
Ｓ１２０６において制御部６０１は、Ｓ１２０１で選択したエントリの識別情報で識別されるハードウェア構成要素６２０が、構成情報１０００において縮退予約：有りであるか否かを判定する。縮退予約が有りである場合（Ｓ１２０６がＹｅｓ）、そのハードウェア構成要素６２０は、例えば、縮退によりシステムから切り離される予定であるため、故障が検出されたハードウェア構成要素６２０の代替とはならない。そのため、フローはＳ１２０１へと戻り、別のハードウェア構成要素６２０に対して処理を繰り返す。一方、Ｓ１２０１で選択したエントリの識別情報で識別されるハードウェア構成要素６２０が、構成情報１０００において縮退予約：無である場合（Ｓ１２０６がＮｏ）、フローはＳ１２０７へと進む。
【００５２】
Ｓ１２０７において制御部６０１は、Ｓ１２０１で選択したエントリの識別情報で識別されるハードウェア構成要素６２０が、構成情報１０００において交換予約：有であるか否かを判定する。交換予約が有りである場合（Ｓ１２０７がＹｅｓ）、そのハードウェア構成要素６２０は、例えば、交換により他のハードウェア構成要素６２０の代替として用いられることが決まっているため、故障が検出されたハードウェア構成要素６２０の代替とはならない。そのため、フローはＳ１２０１へと戻り、別のハードウェア構成要素６２０に対して処理を繰り返す。一方、Ｓ１２０１で選択したエントリの識別情報で識別されるハードウェア構成要素６２０が、構成情報１０００において交換予約：無である場合（Ｓ１２０７がＮｏ）、フローはＳ１２０８へと進む。Ｓ１２０８において制御部６０１は、選択したハードウェア構成要素６２０を故障が検出されたハードウェア構成要素６２０の代替リソースとして決定し、また、代替リソース検索済フラグをオンに設定し、フローはＳ１２０１へと戻る。代替リソース検索済フラグは、例えば、記憶部６１０に記憶されていてよい。
【００５３】
また、Ｓ１２０２において、Ｓ１２０１で選択したエントリの識別情報が、故障が検出されたハードウェア構成要素６２０の識別情報と同じである場合（Ｓ１２０２がＹｅｓ）、フローはＳ１２０９へと進む。この場合、Ｓ１２０１で選択したエントリの識別情報で識別されるハードウェア構成要素６２０は、故障が検出されたハードウェア構成要素６２０である。そのため、制御部６０１は、Ｓ１２０９〜Ｓ１２１２において故障が検出されたハードウェア構成要素６２０を縮退する処理を実行する。
【００５４】
まず、Ｓ１２０９で制御部６０１は、構成情報１０００において、Ｓ１２０１で選択したエントリの縮退予約を有に設定することで縮退を予約する。続いて、Ｓ１２１０において制御部６０１は、縮退予約を行ったハードウェア構成要素６２０の縮退を実行し、その縮退予約されたハードウェア構成要素６２０をサーバー５０１上で稼働するシステムから切り離す。Ｓ１２１１において制御部６０１は、縮退が完了したハードウェア構成要素６２０についての構成情報１０００の縮退予約を無に変更する。Ｓ１２１２において制御部６０１は、ハードウェア構成要素６２０から取得した情報を基に、各ハードウェア構成要素６２０の使用状況を、リソース使用状況情報９００及び構成情報１０００において更新する。例えば、Ｓ１２１０で縮退されたハードウェア構成要素６２０の使用状況は、縮退前はシステムで使用されているためシステム：有であるが、縮退後はシステムから切り離されているため、システム：無となる。また、システムで未使用のハードウェア構成要素６２０は、ゲストドメイン７００でも利用されないため、縮退後はゲストドメインの使用状況も無となる。
【００５５】
Ｓ１２１３において制御部６０１は、Ｓ１２１０の縮退処理の実行前に、故障が検出されたハードウェア構成要素６２０がゲストドメイン７００で使用中であったか否かを判定する。ゲストドメイン７００で使用中であった場合（Ｓ１２１３がＹｅｓ）、フローはＳ１２０１へと戻り、代替のハードウェア構成要素６２０の検索を継続する。一方、Ｓ１２１３において、故障が検出されたハードウェア構成要素６２０がゲストドメイン７００で未使用であった場合（Ｓ１２１３がＮｏ）、故障したハードウェア構成要素６２０を縮退してもサーバー５０１がゲストドメイン７００に割り当てているリソースは減らない。そのため、制御部６０１は、リソースは減らないと判定してよく、また、交換のハードウェア構成要素６２０を探さなくてもよい。この場合、フローはＳ１２１４へと進み、制御部６０１は、エラーレベルを変更してよい。例えば、図１２は、Ｓ８０５においてエラーレベルがＡ：アラートと判定された場合を例示しており、制御部６０１は、Ｓ１２１４においてエラーレベルをＡ：アラートからＷ：ワーニングに軽減する。
【００５６】
Ｓ１２１５において制御部６０１は、構成情報１０００を参照し、故障が検出されたハードウェア構成要素６２０の監視通報モードが、維持モードであるか、それとも、変更モードであるかを判定する。維持モードである場合、制御部６０１は、エラーレベルを変更せずに維持し、フローはＳ１２１７へと進む。この場合、Ｓ１２１７において制御部６０１は、エラーレベルをＳ１２１４で設定したＷ：ワーニングに決定する。
【００５７】
一方、Ｓ１２１５において監視通報モードが変更モードである場合、フローはＳ１２１６へと進む。Ｓ１２１６において制御部６０１は、エラーレベルの見直しを行う。例えば、制御部６０１は、Ｓ１２１４で設定されたエラーレベルをＷ：ワーニングからＮ：ノーティスに軽減する変更を行う。この場合、Ｓ１２１７において制御部６０１は、エラーレベルをＳ１２１６で監視通報モードに応じて軽減したＮ：ノーティスに決定する。
【００５８】
また、Ｓ１２０１において、ハードウェア構成要素６２０の代替として利用できる可能性のあるハードウェア構成要素６２０として特定されたエントリの全てに、Ｓ１２０２以降の処理を実行している場合（Ｓ１２０１がＹｅｓ）、フローはＳ１２１８へと進む。
【００５９】
Ｓ１２１８において制御部６０１は、故障したハードウェア構成要素６２０の代替となる代替リソースが見つかっているか否かを判定する。この判定は、例えば、代替リソース検索済フラグがオンになっているか否かにより判定されてよい。代替リソースが見つかっている場合（Ｓ１２１８がＹｅｓ）、制御部６０１は、ゲストドメイン７００に割り当てているリソースは減らないと判定してよく、フローはＳ１２１９へと進む。Ｓ１２１９において制御部６０１は、代替リソースとして決定されているハードウェア構成要素６２０について、構成情報１０００の交換予約を有に設定して、交換を予約する。続いて、Ｓ１２２０において制御部６０１は、交換予約を行ったハードウェア構成要素６２０の交換を実行する。Ｓ１２２１において制御部６０１は、ハードウェア構成要素６２０から取得した情報を基に、各ハードウェア構成要素６２０の使用状況を、リソース使用状況情報９００及び構成情報１０００において更新する。例えば、Ｓ１２２０で交換されたハードウェア構成要素６２０は、交換前はシステムで使用であり、また、ゲストドメイン７００で未使用であるため、使用状況がシステム：有及びゲストドメイン：無に設定されている。一方、交換後は故障したハードウェア構成要素６２０の代わりにゲストドメイン７００に使用されることになるため、システムとゲストドメイン７００はいずれも有となる。Ｓ１２２２において制御部６０１は、交換が完了したハードウェア構成要素６２０についての構成情報１０００の交換予約を無に変更する。
【００６０】
なお、例えば、Ｓ１２１８において故障したハードウェア構成要素６２０の代替リソースが見つかっており、交換できる場合、制御部６０１は、サーバー５０１がゲストドメイン７００に割り当てているリソースは減らないと判定してよい。この場合、Ｓ１２２３において制御部６０１は、エラーレベルを変更してよい。例えば、制御部６０１は、Ｓ１２２３においてエラーレベルをＡ：アラートからＷ：ワーニングに軽減し、フローはＳ１２１５へと進む。
【００６１】
一方、Ｓ１２１８において故障したハードウェア構成要素６２０の代替となる代替リソースが見つかっていない場合（Ｓ１２１８がＮｏ）、制御部６０１はリソースが減ると判定してよい。この場合、制御部６０１はエラーレベルの変更をせずに、フローはＳ１２２４へと進む。Ｓ１２２４において制御部６０１は、構成情報１０００を参照し、故障が検出されたハードウェア構成要素６２０の監視通報モードが、維持モードであるか、それとも、変更モードであるかを判定する。
【００６２】
Ｓ１２２４において、監視通報モードが維持モードである場合、制御部６０１は、エラーレベルの見直しを実行せず、フローはＳ１２１７に進む。この場合、Ｓ１２１７において制御部６０１は、エラーレベルをＡ：アラームに決定する。一方、Ｓ１２２４において、監視通報モードが変更モードである場合、フローはＳ１２２５へと進む。Ｓ１２２５において制御部６０１は、エラーレベルの見直しを行う。
【００６３】
なお、エラーレベルの見直しにおいて、制御部６０１は、例えば、Ｓ１２１６で例示したように、エラーレベルを軽減する変更を行ってよい。即ち、例えば、監視通報モードが変更モードであれば、エラーレベルを軽減するというように、制御部６０１はエラーレベルの見直しを実行してよい。しかしながら、実施形態はこれに限定されるものではない。例えば、別の例としては、制御部６０１は、所定の条件を満たす場合にエラーレベルを軽減するというように、エラーレベルの見直しを実行してよい。所定の条件は、例えば、故障情報１１００に基づいて、検出された故障が所定の頻度以上で多発していれば、エラーレベルを軽減せず、所定の頻度未満であればエラーレベルを軽減するといった条件であってよい。或いは別の例では、制御部６０１は、故障情報１１００の波及範囲、又はその他の情報に基づいてエラーレベルを低減するか否かを判定してよい。なお、図１２のＳ１２２５では、エラーレベルの見直しの結果、制御部６０１がエラーレベルをＡ：アラームのまま維持し、軽減しなかった場合を例示しており、この場合、Ｓ１２１７において制御部６０１は、エラーレベルをＡ：アラームに決定する。Ｓ１２１７において制御部６０１がエラーレベルを決定すると、本動作フローは終了し、フローはＳ８０７へと進む。
【００６４】
なお、図１２の動作フローにおいて、監視装置６００の制御部６０１は、例えば、変更部６０４として機能する。
【００６５】
以上で述べた様に、実施形態によれば、例えば、ハードウェア構成要素６２０に発生した故障に対して所定の基準に従って判定されたエラーレベルがより低いエラーレベルへと軽減される。そして、例えば、軽減されたエラーレベルに応じて、センター装置５０２を介した保守担当者への通報回数が削減される。そのため、保守に伴う業務を低減することができる。その結果、例えば、保守作業に伴う費用の増加や、保守作業を頻繁に実行することに伴うサーバー５０１の稼働率の低下を抑えることができる。
【００６６】
また、このエラーレベルの低減は、例えば、故障によりゲストドメイン７００に割り当てられているリソースが減らないと判定された場合に実行している。これは、故障によりゲストドメイン７００に割り当てられているリソースが減らなければ、サーバー５０１のゲストドメイン７００によるサービスの提供に支障をきたさないことが推定できるためである。この様な場合には、システムの運用を継続しても支障がでず、その結果、エラーレベルを軽減して保守に伴う業務を減らすことができる。
【００６７】
例えば、制御部６０１は、故障が検出されたハードウェア構成要素６２０が、ゲストドメイン７００により使用されていない場合にリソースが減らないと判定できる。或いは、故障が検出されたハードウェア構成要素６２０がゲストドメイン７００により使用されていても、その故障したハードウェア構成要素６２０の代替が見つかり、交換できる場合には、リソースが減らないと判定できる。この様な判定を実行して、リソースが減るか否かを判定することで、システムの運用を継続しても支障がでない状況で、適切にエラーレベルを軽減することができる。
【００６８】
また、上述の実施形態では、故障したハードウェア構成要素６２０の代替を検索する際に、ハードウェア構成要素の縮退予約及び交換予約の情報を確認している。そのため、縮退や交換が予定されていないハードウェア構成要素６２０のうちから代替となるハードウェア構成要素６２０を検索することができる。
【００６９】
また、上記の実施形態では、監視通報モードを用いてエラーレベルの見直しを実行し、エラーレベルの軽減を行っている。監視通報モードは、例えば、保守サービスを受けるサーバー５０１上で稼働するシステムの要件に応じて設定できる。そのため、システムの要件に合わせたサーバーの保守を提供することができる。
【００７０】
また、上記の実施形態において、例えば、Ｓ８０５におけるエラーレベルの判定は、既存のエラーレベルを決定する仕組みを用いて実行してもよい。例えば、既存のエラーレベルを決定する仕組みを利用することで、本実施形態を適用するためのコストを低減することができる。
【００７１】
以上において、実施形態を例示したが、実施形態はこれらに限定されるものではない。例えば、上述の動作フローは例示であり、実施形態はこれに限定されるものではない。可能な場合には、動作フローは、処理の順番を変更して実行されてもよく、別に更なる処理を含んでもよく、又は、一部の処理が省略されてもよい。例えば、別の実施形態においては、Ｓ８０１の処理とＳ８０２の処理とは順序を入れ替えて実行されてもよい。また同様に、Ｓ１２０６の処理とＳ１２０７の処理とは順序を入れ替えて実行されてもよい。
【００７２】
また、上述のリソース使用状況情報９００及び構成情報１０００の更新は、例えば、システム起動時の他にも、それぞれのゲストドメイン７００によるサービスの提供の開始時などその他のタイミングで実行されてもよい。また、縮退や交換の実行は、システムの再起動時に行われてもよい。
【００７３】
図１３は、実施形態に係るサーバー５０１を実現するためのコンピュータ１３００のハードウェア構成を例示する図である。コンピュータ１３００は、例えば、監視装置１３０１と、システムボード１３５０とを含む。監視装置１３０１は、例えば、ＸＳＣＦなどのサービスプロセッサであってよい。監視装置１３０１は、例えば、ＣＰＵ１３１１、メモリ１３１２、記憶装置１３１３、通信インタフェース１３１４、及びＦＰＧＡ（field-programmable gate array）１３１５を備える。ＣＰＵ１３１１、メモリ１３１２、記憶装置１３１３、通信インタフェース１３１４、ＦＰＧＡ１３１５は、例えば、バス１３０８を介して互いに接続されている。また、システムボード１３５０は、例えば、ＣＰＵ、メモリ、電源装置（ＰＳＵ）、ファン、通信インタフェースなどのハードウェア構成要素６２０と、センサ６３０を含む。システムボード１３５０は、例えば、上述の監視対象装置６１１であってよい。システムボード１３５０上では、ハードウェア構成要素６２０を用いてゲストドメイン７００が稼働してよい。
【００７４】
監視装置１３０１のＣＰＵ１３１１は、メモリ１３１２を利用して例えば上述の動作フローの手順を記述したプログラムを実行することにより、上述した監視装置６００の各機能部の一部または全部の機能を提供する。例えば、監視装置６００の制御部６０１は、ＣＰＵ１３１１がプログラムを実行することで実装されてよく、また、記憶部６１０は、例えばメモリ１３１２、及び記憶装置１３１３を含んでいてよい。監視装置６００のＣＰＵ１３１１は、例えば、メモリ１３１２にプログラムを読み出して実行することで、判定部６０３、変更部６０４、送信部６０５として機能する。監視装置６００の記憶装置１３１３には、例えば、リソース使用状況情報９００、構成情報１０００、故障情報１１００が記憶されてよい。
【００７５】
メモリ１３１２は、例えば半導体メモリであり、ＲＡＭ領域及びＲＯＭ領域を含んでいてよい。記憶装置１３１３は、例えばハードディスク、フラッシュメモリ等の半導体メモリ、又は外部記憶装置である。
【００７６】
通信インタフェース１３１４は、ＣＰＵ１３１１の指示に従ってネットワークにアクセスする。ＦＰＧＡ１３１５は、例えば、システムボード１３５０内のハードウェア構成要素６２０及び他のサーバー１３８０と、ＣＰＵ１３１１との間の通信を仲介する。
【００７７】
なお、例えば、システムボード１３５０に含まれるセンサ６３０は、システムボード１３５０内のハードウェア構成要素６２０を監視し、ハードウェア構成要素６２０の故障を検出してよい。そして、センサ６３０は、検出したハードウェア構成要素６２０の故障を、ＦＰＧＡ１３１５を介してＣＰＵ１３１１に通知してよい。監視装置６００のＣＰＵ１３１１は、例えば、センサ６３０からの通知に基づいて、システムボード１３５０内のハードウェア構成要素６２０の故障を検出してよい。また、例えば、ＡＳＩＣ（application specific integrated circuit）上に複数のハードウェア構成要素６２０が実装されている場合、ＡＳＩＣは、ＡＳＩＣ内のハードウェア構成要素６２０の故障を検出すると、ＣＰＵ１３１１に割り込み通知を通知してよい。ＣＰＵ１３１１は、割り込み通知に基づいてＡＳＩＣ内のハードウェア構成要素６２０の故障を検出してよい。また、ハードウェア構成要素６２０に含まれる通信インタフェースは、ゲストドメイン７００がクライアントにサービスを提供する際の通信で使用されてよい。
【００７８】
実施形態に係る各プログラムは、例えば、下記の形態で監視装置１３０１に提供される。
（１）記憶装置１３１３に予めインストールされている。
（２）プログラムサーバーなどのサーバーから提供される。
【００７９】
上述の実施形態を含むいくつかの実施形態は、上述の実施形態の各種変形形態及び代替形態を包含するものとして当業者には理解される。例えば、各種実施形態は、構成要素を変形して具体化されてよい。また、上述した実施形態に開示されている複数の構成要素を適宜組み合わせることにより、種々の実施形態が実施されてよい。更には、実施形態に示される全構成要素からいくつかの構成要素を削除して又は置換して、或いは実施形態に示される構成要素にいくつかの構成要素を追加して種々の実施形態が実施されてよい。
【符号の説明】
【００８０】
５００      保守システム
５０１      サーバー
５０２      センター装置
５０５      ネットワーク
６００      監視装置
６０１      制御部
６０３      判定部
６０４      変更部
６０５      送信部
６１０      記憶部
６１１      監視対象装置
６２０      ハードウェア構成要素
６３０      センサ
１３００    コンピュータ
１３０１    監視装置
１３０８    バス
１３１１    ＣＰＵ
１３１２    メモリ
１３１３    記憶装置
１３１４    通信インタフェース
１３１５    ＦＰＧＡ
１３５０    システムボード
【図１】
2017033261.tif 000003
【図２】
2017033261.tif 000004
【図３】
2017033261.tif 000005
【図４】
2017033261.tif 000006
【図５】
2017033261.tif 000007
【図６】
2017033261.tif 000008
【図７】
2017033261.tif 000009
【図８】
2017033261.tif 000010
【図９】
2017033261.tif 000011
【図１０】
2017033261.tif 000012
【図１１】
2017033261.tif 000013
【図１２】
2017033261.tif 000014
【図１３】
2017033261.tif 000015