(57)【特許請求の範囲】
【請求項１】
コンピュータに、
情報処理装置上で動作する仮想マシンの所定の期間における動作状況に関する動作情報を、前記動作情報の取得と前記仮想マシンの起動制御とを行なう管理マシンを通じて取得し、
前記所定の期間に前記仮想マシンの動作情報の取得されなかった第１の期間が含まれる場合、前記第１の期間における前記管理マシンの動作情報と、前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報とに基づく、前記第１の期間における前記仮想マシンの動作実績を出力する、
処理を実行させることを特徴とする、出力プログラム。
【請求項２】
前記第１の期間に前記管理マシンの動作情報が取得されなかった第２の期間が含まれる場合、前記第１の期間のうちの前記第２の期間に含まれない期間における前記仮想マシンの動作状態を停止状態と推定する、
処理を前記コンピュータに実行させることを特徴とする、請求項１記載の出力プログラム。
【請求項３】
前記管理マシンの動作情報が取得されなかった第２の期間における前記仮想マシンの動作状態を、前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報に基づいて推定する、
処理を前記コンピュータに実行させることを特徴とする、請求項１又は請求項２記載の出力プログラム。
【請求項４】
前記第２の期間における前記仮想マシンの動作状態が起動状態と推定された場合、前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報に基づいて、前記第２の期間における前記仮想マシンの動作状態を処理実行状態及びアイドル状態のいずれから判別する、
処理を前記コンピュータに実行させることを特徴とする、請求項３記載の出力プログラム。
【請求項５】
前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報が閾値を下回っていた時間に基づき、前記仮想マシンの動作状態を処理実行状態及びアイドル状態のいずれから判別する、
処理を前記コンピュータに実行させることを特徴とする、請求項４記載の出力プログラム。
【請求項６】
前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報に基づき、前記所定の期間のうちの前記第１の期間の前記第１の期間の前後少なくとも一方の期間における前記仮想マシンの動作状態を判別し、
判別した動作状態と、推定された前記第１の期間における前記仮想マシンの動作状態とに基づいて、前記所定の期間における前記仮想マシンの動作状態を推定し、
推定した動作状態を前記第１の期間を含む前記所定の期間における前記仮想マシンの動作実績に含めて出力する、
処理を前記コンピュータに実行させることを特徴とする、請求項１〜５のいずれか１項記載の出力プログラム。
【請求項７】
情報処理装置上で動作する仮想マシンの所定の期間における動作状況に関する動作情報を、前記動作情報の取得と前記仮想マシンの起動制御とを行なう管理マシンを通じて取得する取得部と、
前記所定の期間に前記仮想マシンの動作情報の取得されなかった第１の期間が含まれる場合、前記第１の期間における前記管理マシンの動作情報と、前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報とに基づき、前記第１の期間における前記仮想マシンの動作実績を推定する推定部と、
推定した前記第１の期間における前記仮想マシンの動作実績を出力する出力部と、をそなえる
ことを特徴とする、出力装置。
【請求項８】
情報処理装置上で動作する仮想マシンの所定の期間における動作状況に関する動作情報を、前記動作情報の取得と前記仮想マシンの起動制御とを行なう管理マシンを通じて取得し、
前記所定の期間に前記仮想マシンの動作情報の取得されなかった第１の期間が含まれる場合、前記第１の期間における前記管理マシンの動作情報と、前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報とに基づく、前記第１の期間における前記仮想マシンの動作実績を出力する、
ことを特徴とする、出力方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、出力プログラム，出力装置，及び出力方法に関する。
【背景技術】
【０００２】
サーバやＰＣ（Personal Computer）等の情報処理装置のリソースを用いて、仮想化環境で複数のＶＭ（Virtual Machine；仮想マシン）を設定し、利用者にＶＭを提供するクラウドシステムが知られている。
【０００３】
また、クラウドシステムにおいて、利用者に提供されるＶＭの動作管理を支援するために、情報処理装置上で動作するＶＭの稼働情報をモニタし、モニタ結果を出力する技術が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−２７７２０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
クラウドシステムでは、複数のＶＭによってリソース資源である情報処理装置が共用されることが多い。このため、処理の実行に利用されていないにもかかわらず立ち上げられている（起動されている）ＶＭ（以下、アイドル状態のＶＭ又はアイドルＶＭともいう）は、情報処理装置のリソースを無駄に利用することになる。
【０００６】
アイドル状態のＶＭによるリソースの無駄な利用を抑止するために、例えばクラウドシステムの管理者は、ＶＭの稼働情報（リソースの使用率，使用量等）のモニタ結果を用いて、ＶＭの利用者に対してアイドル状態のＶＭの停止を促すことが考えられる。
【０００７】
管理者は、通常、ＶＭが動作している場合には当該ＶＭの稼働情報のモニタ結果を取得することができる。しかし、提供するＶＭの稼働情報（動作情報）がモニタ結果に存在しない（取得されない）場合もある。モニタ結果に少なくとも一部のＶＭの稼働情報が含まれないこととしては、当該ＶＭが停止していた，モニタリングを行なうマシン（例えばＶＭの管理を行なう管理ＶＭ）が停止又は障害発生により動作できていなかった等、複数の要因が考えられる。
【０００８】
このため、ＶＭの利用者は、稼働情報のモニタ結果（動作実績）を提供されても、そもそもＶＭが稼働していたのか否かも含め、稼働情報の存在しない期間におけるＶＭの実際の稼働状況を特定することが困難である。
【０００９】
このように、管理者は、モニタ結果の信頼性が低いために、利用者にＶＭの停止の必要性を意識させることが難しく、アイドル状態のＶＭによるリソースの無駄な利用の抑制を実現することが困難になる場合があるという課題がある。
【００１０】
１つの側面では、本発明は、動作情報の取得されなかった期間における仮想マシンの動作情報を補った動作実績を出力することを目的とする。
【００１１】
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。
【課題を解決するための手段】
【００１２】
１つの態様では、コンピュータに以下の処理を実行させる。この処理には、情報処理装置上で動作する仮想マシンの所定の期間における動作状況に関する動作情報を、前記動作情報の取得と前記仮想マシンの起動制御とを行なう管理マシンを通じて取得する処理が含まれる。また、この処理には、前記所定の期間に前記仮想マシンの動作情報の取得されなかった第１の期間が含まれる場合、前記第１の期間における前記管理マシンの動作情報と、前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報とに基づく、前記第１の期間における前記仮想マシンの動作実績を出力する処理が含まれる。
【発明の効果】
【００１３】
１つの側面では、動作情報の取得されなかった期間における仮想マシンの動作情報を補った動作実績を出力することができる。
【図面の簡単な説明】
【００１４】
【図１】クラウドシステムにおけるＶＭの稼働状況の例を示す図である。
【図２】動作データのデータ補完に用いられる各ＶＭの稼働情報の近似線を示す図である。
【図３】動作データのデータ補完に用いられる各ＶＭの稼働情報の近似線を示す図である。
【図４】動作データのデータ補完に用いられる各ＶＭの稼働情報の近似線を示す図である。
【図５】各ＶＭの１時間ごとの稼働状態の判別結果例を示す図である。
【図６】一実施形態に係るシステムの構成例を示す図である。
【図７】図６に示す動作データの一例を示す図である。
【図８】図６に示す動作データリストの一例を示す図である。
【図９】図６に示す動作判別リストの一例を示す図である。
【図１０】図６に示す第１統合リストの一例を示す図である。
【図１１】図６に示す第２統合リストの一例を示す図である。
【図１２】図６に示すＶＭ管理情報の一例を示す図である。
【図１３】図６に示す動作実績レポートの一例を示す図である。
【図１４】動作実績レポートの提供サイトの表示例を示す図である。
【図１５】動作実績レポートの詳細例を示す図である。
【図１６】動作実績レポートの対比例の詳細を示す図である。
【図１７】一実施形態に係る出力サーバにおける全体の処理の一例を説明するフローチャートである。
【図１８】一実施形態に係る動作データリストの作成処理の一例を説明するフローチャートである。
【図１９】一実施形態に係る動作判別リストの作成処理の一例を説明するフローチャートである。
【図２０】一実施形態に係る１時間単位の統合処理の一例を説明するフローチャートである。
【図２１】一実施形態に係るアイドル判別処理の一例を説明するフローチャートである。
【図２２】一実施形態に係る１日単位の統合処理の一例を説明するフローチャートである。
【図２３】一実施形態に関連する各ＶＭの稼働情報の近似線を示す図である。
【図２４】一実施形態に関連する各ＶＭの稼働情報の近似線を示す図である。
【図２５】一実施形態に関連する各ＶＭの稼働情報の近似線を示す図である。
【図２６】他の例による各ＶＭの１時間ごとの稼働状態の判別結果を示す図である。
【図２７】第１変形例に係るシステムの構成を示す図である。
【図２８】第１変形例に係るデータ補完処理後の動作判別リストを示す図である。
【図２９】図２７に示す第１統合リストの一例を示す図である。
【図３０】第１変形例に係る出力サーバにおける全体の処理を説明するフローチャートである。
【図３１】第１変形例に係る動作判別リストの補完処理を説明するフローチャートである。
【図３２】第１変形例に係る１時間単位の統合処理を説明するフローチャートである。
【図３３】第２変形例に係るデータ補完処理後の動作データリストを示す図である。
【図３４】第２変形例に係る第１統合リストを示す図である。
【図３５】第２変形例に係る１時間単位の統合処理を説明するフローチャートである。
【図３６】図６又は図２７に示す出力サーバのハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。
【００１６】
〔１〕稼働情報の収集について
クラウドシステムでは、ＶＭが配備されるとき、ＣＰＵ（Central Processing Unit）資源はＶＭ間で共用されるが、メモリ資源はＶＭに割り当てられた記憶領域が占有されてしまう。従って、クラウドシステムでは、情報処理装置のリソース資源、特にメモリ資源の管理が重要である。
【００１７】
図１は、クラウドシステムにおけるＶＭの稼働状況つまり利用者によるＶＭの利用（運用）状況の例を示す図である。クラウドシステム内には、メモリを占有したまま何の処理もせずに放置されているＶＭ（アイドルＶＭ）が存在し得る。図１に示す例では、３割近いＶＭが常にアイドルとして放置されていることがわかる。図１では、メモリ使用率が８０％近い日もあるが、使用されているメモリのうち、３割程度がアイドルＶＭとして放置されたＶＭに割り当てられたメモリである。
【００１８】
上述のように、アイドルＶＭのメモリを解放するにはアイドルＶＭを停止させればよい。ただし、各ＶＭの使用用途の分からない管理者はＶＭを勝手に停止できないため、ＶＭの利用者に停止を促すことが考えられる。しかし、特に、企業等の組織内で提供されるプライベートクラウドシステムの利用者は、割当リソースや消費エネルギーの無駄、或いはＶＭ利用の課金に関する意識が低く、ＶＭを常時起動させたまま放置させることが多い。
【００１９】
利用者は利用したいときにＶＭを起動させ、使わない間は自由にＶＭを停止させることができる。従って、リソース使用量を削減するために、利用者に自発的にアイドルＶＭを停止させるには、クラウドシステムは、稼働した時間帯だけでなく、停止した時間帯についてもＶＭの稼働状況を可視化（見える化）することが好ましい。ＶＭの停止した時間帯を利用者に把握させることで、利用者に各ＶＭの稼働状況（利用状況）を正しく認識させ、効率良くＶＭを利用するという意識を持たせることができるからである。
【００２０】
従来、サーバは常に稼動していることが前提であったため、利用者にＶＭの稼働状況を認識させる際には、ＶＭの稼働した時間帯の情報を見せることが主であった。例えば、クラウドシステムは、ＶＭの稼働した時間帯については、ＶＭから収集された稼働情報から、処理を実行していた或いはアイドル状態であったかを判別して、利用者が閲覧可能なＷｅｂサイト等に表示することができる。なお、以下、ＶＭの稼働状況を示す稼働情報を収集する管理ＶＭから稼働情報を取得して、加工や集計等を行ない利用者へ出力するサーバを出力サーバという。
【００２１】
一方、利用者によりＶＭが電源ＯＦＦにされた場合やシステムトラブル等による管理ＶＭの障害により稼働情報が採取されていない場合、データの抜けが生じる。このように稼働情報にデータの抜けが生じた場合でも、リソース使用量の削減の観点から、出力サーバは、抜けの生じたデータを判別して補完することが重要である。
【００２２】
しかし、管理ＶＭは、一度採取された稼働情報を再採取したり過去に遡った採取をすることが難しく、稼働情報にデータの抜けがある場合、再集計を行なうことは困難である。
【００２３】
利用者においては、運用側（管理者）から提示される稼働情報以外から過去のＶＭの稼働状況を確認することは難しい。従って、管理者は、管理ＶＭの障害によって稼働情報が欠如している期間があるとき、出力サーバにより、稼働情報の欠如期間の判断を助けるための情報を含めて、利用者に稼働情報のレポートを提示することが好ましい。
【００２４】
〔２〕対比例
次に、一実施形態の対比例を説明する。稼働情報において欠如したデータの判別手法として、管理ＶＭの障害によるデータ欠如部分について、出力サーバが最小二乗法等の各種近似法を用いてデータ補完を行なうことが考えられる。しかし、出力サーバが、稼働情報においてデータの無い時間帯を全てデータ欠損の時間帯としてデータ補完を行なうと、実態とは違った状況を表してしまうことがある。
【００２５】
例えば、出力サーバが管理ＶＭから図７に示す複数の稼働情報を含む動作データを取得した場合を想定する。なお、便宜上、本対比例では、図７に示す動作データを並び替えた図８のリスト（動作データリスト）を用いて動作データを説明する。なお、図７及び図８では、稼働情報として管理ＶＭ，ＶＭ１，ＶＭ２，及びＶＭ３のＣＰＵ使用率（％），ディスクＩ／Ｏ（Input/Output），及びネットワークＩ／Ｏのデータ量（Kbyte/秒）が１０分ごとに設定されている。また、図７及び図８において、“(null)”が設定された時間帯は該当ＶＭの電源ＯＦＦ又は管理ＶＭの障害により稼働情報が含まれていない（採取されていない）。
【００２６】
出力サーバは、図８に示す動作データリストのうちの稼働情報のある時間帯のデータを用いて、図２〜図４に例示する近似線を算出する。図２〜図４は、動作データのデータ補完に用いられる各ＶＭの稼働情報の近似線を示す図である。出力サーバは、図２〜図４に示すように、稼働情報が無い全ての時間帯（図８におけるＶＭ１，ＶＭ２，及びＶＭ３の（１）及び（３）（８時台及び１０時台）並びにＶＭ２の（４）（１１時台）参照）をデータ欠損の時間帯と判断する。
【００２７】
そして、出力サーバは、図２〜図４のそれぞれの近似線上の値を用いてデータの無い時間帯（ＶＭ１，ＶＭ２，及びＶＭ３の８時台及び１０時台，並びにＶＭ２の１１時台）の補完後のデータを算出する。また、出力サーバは、補完後のデータに基づいて各ＶＭの１時間ごとの稼働状況を判断し、図５に示すような１時間ごとの稼働状態の判別結果を得る。なお、図５において、黒丸は処理実行中，白丸はアイドル状態を示す。図５に示す例では、ＶＭ１が８時台から１１時台まで全てアイドル状態であり、ＶＭ２及びＶＭ３が８時台から１１時台まで全て処理実行中である。
【００２８】
しかし、図８において、ＶＭ１，ＶＭ２，及びＶＭ３の（１）（８時台），並びにＶＭ２の（４）（１１時台）は、利用者によりＶＭの電源がＯＦＦにされていた時間帯である。すなわち、図５の結果のうち、ＶＭ１，ＶＭ２，及びＶＭ３の８時台，並びにＶＭ２の１１時台は、本来はＶＭが電源ＯＦＦの状態であるにもかかわらず、管理ＶＭの障害によるデータ欠損として、不要な補完データが加えられたものであるといえる。このように、出力サーバが図５に基づき稼働情報のレポートを出力しても、当該レポートはＶＭの稼働状況を正しく可視化したものとは言い難く、信頼性の低いものとなってしまう。
【００２９】
〔３〕一実施形態
図２〜図５を参照して説明したように、対比例では、動作データにおける稼働情報の無い全ての時間帯を補完してしまうため、稼働情報のレポートの信頼性が低下する。また、稼働状況の判別結果において、ＶＭの電源ＯＦＦの時間帯が処理実行中として示される場合、かえって利用者にＶＭの継続的な稼働の必要性を意識させてしまい、アイドル状態のＶＭによるリソースの無駄な利用の抑制を実現することが困難になる場合がある。
【００３０】
これに対し、一実施形態に係るシステムでは、出力サーバが、動作データにおける稼働情報の無い時間帯について、「利用者によるＶＭの電源ＯＦＦ」であるのか「管理ＶＭの障害によるデータ欠損」であるのかを判別することができる。従って、出力サーバは、動作データにおける「管理ＶＭの障害によるデータ欠損」が生じた時間帯について、適切に補完を行なうことができ、稼働情報のレポートの信頼性を高めることができる。以下、本実施形態に係るシステムの詳細を説明する。
【００３１】
〔３−１〕一実施形態に係るシステムについて
図６は、一実施形態に係るシステムの構成例を示す図である。一実施形態に係るシステムは、ハードウェアとして、例示的にハードウェア資源１，出力サーバ２，ＶＭ管理情報格納サーバ３，及びＷｅｂサーバ４をそなえることができる。なお、本システムにそなえられるハードウェアは、例えばデータセンタ等に設置されてよく、或いはこれらのハードウェアの少なくとも一部が他の施設等に設置され、システム内でネットワークを介して通信してもよい。
【００３２】
ハードウェア資源１は、ｍ（ｍは１以上の整数）台のサーバ１−１〜１−ｍをそなえ、仮想化技術によりこれらのサーバ１−１〜１−ｍの資源（リソース）を用いて仮想化環境１０を実現する。サーバ１−１〜１−ｍは、仮想化環境１０で用いるリソースとして、例えばＣＰＵ等のプロセッサ，メモリ等の記憶装置，ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）等の補助記憶装置，ネットワークカード等のインタフェース等をそなえることができる。なお、サーバ１−１〜１−ｍは、情報処理装置の一例である。
【００３３】
仮想化環境１０は、ハードウェア資源１を用いてクラウドシステムの管理者により管理される環境である。仮想化環境１０には、例示的に、ｎ（ｎは１以上の整数）台のＶＭ１１−１〜１１−ｎ（以下の説明において、ＶＭ１１−１〜１１−ｎを区別しない場合には単にＶＭ１１という），及び１以上（図６では１台）の管理ＶＭ１５が配備される。すなわち、ハードウェア資源１により実現される仮想化環境１０は、利用者に１以上のＶＭ１１を提供するクラウドシステムを構成する。
【００３４】
ＶＭ１１は、クラウドシステムの管理者により、例えばネットワーク５を介して利用者端末６−１〜６−ｉ（ｉは１以上の整数）に提供される。なお、利用者へのＶＭ１１の提供手法は、既知の種々の手法を用いることができる。一例として、Ｗｅｂサーバ４がＶＭ１１の制御（利用）を行なうためのアプリケーションをそなえ、利用者が当該アプリケーションを介してＶＭ１１を利用することによって、利用者にＶＭ１１が提供される。なお、ネットワーク５は、インターネット若しくはイントラネット、又はこれらの組み合わせを含んでよい。
【００３５】
ＶＭ１１の各々は、例示的に、図示しないハイパーバイザ上で実行される仮想ＯＳ（Operating System）１２，利用者が実行する所定のアプリケーション１４，及び仮想ＯＳ１２上でアプリケーション１４を実行するためのミドルウェア１３をそなえる。
【００３６】
管理ＶＭ１５は、クラウドシステムの管理者によりＶＭ１１の動作管理等のクラウドシステムの管理に用いられるＶＭであり、例えばＶＭ１１の電源管理，各ＶＭ１１からの稼働情報（動作情報）の採取，及び動作データの生成等を行なうことができる。
【００３７】
例示的に、管理ＶＭ１５は、ハイパーバイザ上で実行される仮想ＯＳ１６，電源操作部１７，稼働情報収集部１８，及び記憶部１９をそなえることができる。
【００３８】
電源操作部１７は、仮想ＯＳ１６及びハイパーバイザを介して、各ＶＭ１１の電源制御を行なう。例えば、電源操作部１７は、利用者によるＶＭ１１の電源ＯＮ／ＯＦＦの制御指示に応じて、対応するＶＭ１１の電源をＯＮ制御又はＯＦＦ制御する。このように、一実施形態に係るＶＭ１１では、利用者によるＶＭ１１の電源ＯＮ／ＯＦＦ制御は、管理ＶＭ１５の電源操作部１７を経由して実行される。例えば、利用者がＷｅｂサーバ４等により提供されるＶＭ１１管理用のサイトからＶＭ１１の電源ＯＮ／ＯＦＦの制御指示を行なうことにより、Ｗｅｂサーバ４等から電源操作部１７に当該制御指示が通知されるようにしてもよい。
【００３９】
なお、ＶＭ１１の電源ＯＦＦ制御には、例えばＶＭ１１の情報を補助記憶装置等に退避させ、ＶＭ１１に割り当てられているＣＰＵ資源，メモリ資源，及びネットワーク資源等のリソースを解放する制御が含まれてよい。また、ＶＭ１１の電源ＯＮ制御には、補助記憶装置等に退避してある電源ＯＦＦ前のＶＭ１１の状態或いはテンプレート等からＶＭ１１を生成し、生成したＶＭ１１にＣＰＵ資源，メモリ資源，及びネットワーク資源等のリソースを割り当てる制御が含まれてよい。
【００４０】
稼働情報収集部１８は、仮想ＯＳ１６及びハイパーバイザを介して、各ＶＭ１１の稼働情報を定期的に収集し、図７に例示する動作データ１９ａとして記憶部１９に格納する。本実施形態では、稼働情報収集部１８は、１０分単位で稼働情報を各ＶＭ１１から取得する。稼働情報収集部１８としては、例えばパフォーマンス分析やキャパシティ管理を行なう製品であるＳＱＣ（SystemwalkerService Quality Coodinator）等、仮想ＯＳ１６上で実行されるアプリケーションが挙げられる。
【００４１】
一例として、稼働情報収集部１８は、１０分ごとに、管理ＶＭ１５及びＶＭ１１の各々から、各ＶＭでのＣＰＵ使用率，ディスクＩ／Ｏのデータ量，及びネットワークＩ／Ｏのデータ量等のリソース利用状況（稼働状況）を示す稼働情報を収集する。なお、稼働情報（動作情報）としては、例えばクラウドシステムの課金に関係する資源の利用情報である運用ログが挙げられる。運用ログには、上記の他にディスク使用率等も含まれてよい。
【００４２】
図７には、管理ＶＭ１５及び３つのＶＭ１１（ＶＭ１，ＶＭ２，ＶＭ３と表記）から、8:00及び8:10に動作状況が収集された様子を示す（（ａ）及び（ｂ）参照）。なお、稼働情報収集部１８は、収集時点でのＶＭ１１のＣＰＵ使用率、又は最後に収集してから収集時点までのＣＰＵ使用率の平均若しくは最大値等を、ＣＰＵ使用率として収集してよい。また、稼働情報収集部１８は、最後に収集してから収集時点までの各Ｉ／Ｏのデータ量の合計値等を、ディスクＩ／Ｏ及びネットワークＩ／Ｏのデータ量として収集してよい。
【００４３】
記憶部１９は、稼働情報収集部１８が収集した動作データ１９ａを記憶する記憶領域であり、ハードウェア資源１のうちのメモリ等の記憶装置やＨＤＤ等の補助記憶装置により実現される。
【００４４】
このように、管理ＶＭ１５は、サーバ１−１〜１−ｍ上で動作するＶＭ１１の所定の期間における動作状況に関する動作情報の取得と、ＶＭ１１の起動制御とを行なう管理マシンの一例であるといえる。
【００４５】
出力サーバ２は、図６に示すように、管理ＶＭ１５（稼働情報収集部１８）が取得した動作データ１９ａをコピーし、各ＶＭの稼働情報から各ＶＭの状態を分類し、ＶＭごとに時系列で稼働状態をまとめたレポートを出力する。出力サーバ２が出力するレポートには、少なくとも、動作情報の取得されなかった期間における当該ＶＭの動作情報を補った動作実績が含まれる。なお、動作実績には、ＶＭ１１が所定の期間に稼働していたか否か（電源ＯＮか電源ＯＦＦか）、稼働していた場合（電源ＯＮ）は処理実行中かアイドルか、を示す動作状態が含まれ得る。出力サーバ２は、この動作状態の判別に動作情報を用いることができる。
【００４６】
本実施形態では、出力サーバ２は、動作情報の取得されなかった期間における当該ＶＭの動作情報を考慮した、１日単位での動作実績レポート２１ｂを生成して出力するものとして説明する。出力サーバ２は、ハードウェアとしての情報処理装置により実現されてもよいし、ハードウェア資源１又は他のハードウェア資源を用いて動作するＶＭであってもよい。出力サーバ２の詳細は後述する。
【００４７】
ＶＭ管理情報格納サーバ３は、クラウドシステムに配備されているＶＭ１１の管理情報（ＶＭ管理情報３１ａ；図１２参照）を格納する。ＶＭ管理情報３１ａには、各ＶＭ１１を所持（利用）する職制名（所属名），プロジェクト名，管理者氏名，ＶＭ名，利用者の氏名，メールアドレス等が含まれてよい。本実施形態では、図１２に例示するように、ＶＭ管理情報３１ａには職制名，プロジェクト名，及びＶＭ名が設定されるものとする。
【００４８】
ＶＭ管理情報格納サーバ３は、ＶＭ管理情報３１ａを記憶する記憶部３１をそなえることができる。記憶部３１は、ＶＭ管理情報３１ａを記憶する記憶領域であり、ＨＤＤ等の補助記憶装置により実現される。
【００４９】
Ｗｅｂサーバ４は、出力サーバ２が作成した動作実績レポート２１ｂを公開するためのサーバである。Ｗｅｂサーバ４は、利用者（端末６−１〜６−ｉ）にＶＭ１１管理用のレポート提供サイトを提供することができ、利用者は、Ｗｅｂサーバ４にアクセスして動作実績レポート２１ｂを閲覧，ダウンロードすることができる。
【００５０】
〔３−２〕出力サーバの構成例
次に、出力サーバ２の詳細な構成について説明する。出力サーバ２は、例示的に、記憶部２１，保持部２２，動作データ取得部２３，動作データリスト作成部２４，動作判別部２５，第１統合部２７，第２統合部２８，ＶＭ管理情報追加部２９，及びレポート転送部３０をそなえることができる。
【００５１】
記憶部２１は、種々のデータやプログラムを記憶可能な記憶装置である。本実施形態において、記憶部２１は、動作データ２１ａ及び動作実績レポート２１ｂ等のファイルを格納することができる。なお、記憶部２１は、ＨＤＤやＳＳＤ等の補助記憶装置により実現される。
【００５２】
保持部２２は、種々のデータやプログラムを記憶可能な記憶装置である。本実施形態において、保持部２２は、動作データリスト２２ａ，動作判別リスト２２ｂ，第１統合リスト２２ｃ，及び第２統合リスト２２ｄ等のデータを格納することができる。なお、保持部２２は、メモリ等の記憶装置により実現される。
【００５３】
動作データ取得部２３は、管理ＶＭ１５（稼働情報収集部１８）が収集するＳＱＣ等の動作データ１９ａを取得し、出力サーバ２内の記憶部２１に格納（コピー）する。すなわち、動作データ取得部２３は、動作情報を管理ＶＭ１５から取得する取得部の一例であるといえる。動作データ取得部２３による動作データ１９ａの取得は、例えばＦＴＰ（File Transport Protocol）等の既知の種々の手法により行なうことが可能であり、その詳細な説明は省略する。なお、動作データ取得部２３が記憶部２１に格納する動作データ２１ａは、動作データ１９ａと同一又は略同一である（図７参照）。
【００５４】
動作データリスト作成部２４は、記憶部２１に格納された動作データ２１ａを、ＶＭごとに時系列に並べたリストを作成し、図８に例示する動作データリスト２２ａとして保持部２２に格納する。
【００５５】
動作判別部２５は、動作データリスト２２ａに設定された管理ＶＭ１５及びＶＭ１１の情報から、各時間帯でのＶＭごとの稼働状態（動作状態）を判別し、判別結果を図９に例示する動作判別リスト２２ｂとして保持部２２に格納する。動作判別部２５が判別可能な稼働状態には、例えばＶＭ１１が電源ＯＮ状態であること，利用者によりＶＭ１１が電源ＯＦＦ状態であること，並びに管理ＶＭ１５に障害が発生していた状態であること、が含まれる。動作判別部２５は、例えば動作データリスト２２ａのＣＰＵ使用率の設定値（設定状態）に基づいて、ＶＭごとの稼働状態を判別することができる。
【００５６】
一例として、動作判別部２５は、動作データリスト２２ａにＶＭ１１のＣＰＵ使用率が設定されている場合には、ＶＭ１１が処理実行中又はアイドル状態である電源ＯＮ状態であると判断する。なお、図８の例では、9:00〜9:50のＶＭ１，ＶＭ２，及びＶＭ３，11:00〜11:50のＶＭ１及びＶＭ３が該当する。そして、動作判別部２５は、図９に示すように、電源ＯＮ状態であると判別したＶＭ１１については、動作判別リスト２２ｂの対応する時間帯の対応するＶＭ１１に“pon”を設定する。
【００５７】
また、動作判別部２５は、動作データリスト２２ａに管理ＶＭ１５のＣＰＵ使用率は設定されているが、ＶＭ１１のＣＰＵ使用率が設定されていない場合には、ＶＭ１１が利用者による電源ＯＦＦ状態であると判断する。なお、図８の例では、8:00〜8:50のＶＭ１，ＶＭ２，及びＶＭ３，11:00〜11:50のＶＭ２が該当する。そして、動作判別部２５は、電源ＯＦＦ状態であると判別したＶＭ１１については、動作判別リスト２２ｂの対応する時間帯の対応するＶＭ１１に“poff”を設定する。
【００５８】
さらに、動作判別部２５は、動作データリスト２２ａに管理ＶＭ１５のＣＰＵ使用率が設定されていない場合には、管理ＶＭ１５に障害が発生していた状態であると判断する。なお、この時間帯は、ＶＭ１１の稼働情報を収集する管理ＶＭ１５に障害が発生していたため、ＶＭ１１のＣＰＵ使用率も設定されていない（図８の10:00〜10:50のＶＭ１，ＶＭ２，及びＶＭ３参照）。そして、動作判別部２５は、動作判別リスト２２ｂの対応する時間帯の全てのＶＭ１１に“down”を設定する。
【００５９】
このように、動作判別部２５は、稼働情報が収集できていない時間帯に着目し、当該時間帯で、管理ＶＭ１５を含む全てのＶＭで同時期に稼働情報が収集できていない場合、管理ＶＭ１５の障害によってデータ欠損が生じたと判断することができる。
【００６０】
また、動作判別部２５は、あるＶＭ１１ではデータ収集ができておらず、他のＶＭ１１ではできていた場合、データ収集できていないＶＭ１１が利用者により電源ＯＦＦにされていたと判断することができる。換言すれば、動作判別部２５は、ＶＭ１１の動作情報の無い第１の期間に管理ＶＭ１５の動作情報が取得されなかった第２の期間が含まれる場合、第１の期間のうちの第２の期間に含まれない期間におけるＶＭ１１の動作状態を停止状態と推定することができる。
【００６１】
すなわち、動作判別部２５は、ＶＭ１１及び運用中は常に稼動し続ける管理ＶＭ１５の稼働情報ログの有無（組み合わせを含む）に基づいて、ＶＭ１１の稼働情報が欠如する時間帯に、ＶＭ１１が電源ＯＦＦであったか、管理ＶＭ１５の障害によるデータ欠損があったかを判別できる。従って、動作データリスト２２ａにおいてＶＭ１１の稼働情報が欠如している場合でも、利用者の自発的なＶＭ１１の電源停止による電源ＯＦＦ状態を識別することができ、動作実績レポート２１ｂの信頼性を向上させることができる。
【００６２】
第１統合部２７は、動作判別部２５によって生成された動作判別リスト２２ｂについて、各ＶＭ１１の複数の時間帯での稼働状態を統合する処理を行ない、図１０に例示する第１統合リスト２２ｃを作成して保持部２２に格納する。本実施形態では、第１統合部２７は、動作実績レポート２１ｂでの集計単位である１日よりも短い１時間を統合単位として、動作判別リスト２２ｂの統合処理を行なうものとする。
【００６３】
例えば、第１統合部２７は、各ＶＭ１１について、動作判別リスト２２ｂから統合単位（１時間単位）で複数（この場合６つ）の稼働状態を読み出し、以下の条件によって、統合した時間帯の稼働状態を判別する。
【００６４】
（Ｉ）読み出した複数の稼働状態に１つでも“down”がある場合：統合した時間帯をデータ欠損（判別不能）と判定する。
【００６５】
（II）読み出した複数の稼働状態に１つも“down”が無く、且つ、１つでも“pon”がある場合：“pon”が設定されている時間帯（１０分単位）における稼働情報を用いて、後述するアイドル判別処理を行なう。
【００６６】
（III）上記（Ｉ）及び（II）に該当しない場合：統合した時間帯を電源ＯＦＦ状態と判定する。
【００６７】
一例として、第１統合部２７が、図９に示す動作判別リスト２２ｂについて１時間ごと（８時台，９時台，１０時台，１１時台）に稼働状態の統合を行なう場合を説明する。なお、稼働情報の各要素の閾値として、第１統合部２７にはＣＰＵ使用率の閾値：7.5％，ディスクＩ／Ｏ量の閾値：400 Kbyte/秒，及びネットワークＩ／Ｏ量の閾値：20 Kbyte/秒が設定されているものとする。また、動作処理中かアイドル状態かを判断するための所定の閾値として、統合単位の時間に対するアイドル時間の比率：80.2％が設定されているものとする。
【００６８】
例えば、第１統合部２７は、ＶＭ１〜ＶＭ３の１０時台の各々について、６つ全ての時間帯（１０分単位）に“down”が設定されているため、上記（Ｉ）に基づき、データ欠損と判定する。そして、第１統合部２７は、図１０に示すように、ＶＭ１〜ＶＭ３の１０時台については、データ欠損を示すバツ（×）を設定する。
【００６９】
また、第１統合部２７は、ＶＭ１，ＶＭ２，及びＶＭ３の９時台，並びにＶＭ１及びＶＭ３の１１時台について、全ての時間帯（１０分単位）に“pon”が設定されているため、上記（II）に基づき、アイドル判別処理を行なう。アイドル判別処理では、第１統合部２７は、統合した時間帯の稼働状態が電源ＯＮ状態のうちの処理実行中であるのかアイドル状態であるのかを判断する。
【００７０】
例えば、第１統合部２７は、“pon”が設定されている時間帯の稼働情報の少なくとも１つの要素（ＣＰＵ使用率，ディスクＩ／Ｏ量，ネットワークＩ／Ｏ量）が閾値を下回るか否かを、動作データリスト２２ａを参照して判断する。次いで、第１統合部２７は、判断を行なった時間帯を含む統合単位の時間帯において、全ての要素が閾値を下回った時間の合計を算出する。そして、第１統合部２７は、統合単位の時間帯に対する算出した時間の合計の比率が、所定の閾値を超える場合はアイドル状態，所定の閾値以下の場合は処理実行中と判別する。
【００７１】
図８及び図９に示す例では、第１統合部２７は、ＶＭ１の９時台及び１１時台の各々について、６つ全ての時間帯で、全ての要素が閾値を下回っていると判断する。次いで、第１統合部２７は、統合単位の時間帯（１時間）に対する閾値を下回った時間の合計の比率がアイドル時間の比率（所定の閾値）を超えると判定し、これらの時間帯はアイドル状態と判断する。そして、第１統合部２７は、図１０に示すように、ＶＭ１の９時台及び１１時台について、アイドル状態を示す白丸（○）を設定する。
【００７２】
さらに、第１統合部２７は、ＶＭ２の９時台，並びにＶＭ３の９時台及び１１時台の各々について、６つ全ての時間帯で、少なくとも１つの要素が閾値以上であると判断する。次いで、第１統合部２７は、統合単位の時間帯（１時間）に対する閾値以上である時間の合計の比率がアイドル時間の比率（所定の閾値）以下であると判定し、これらの時間帯は処理実行中と判断する。そして、第１統合部２７は、図１０に示すように、ＶＭ２の９時台，並びにＶＭ３の９時台及び１１時台について、処理実行中を示す黒丸（●）を設定する。
【００７３】
また、第１統合部２７は、ＶＭ１及びＶＭ３の８時台，並びにＶＭ２の８時台及び１１時台について、いずれも１つも“down”及び“pon”が設定されていない（上記（Ｉ）及び（II）に該当しない）と判断する。なお、これは、６つ全ての時間帯（１０分単位）に“poff”が設定されていることを意味する。次いで、第１統合部２７は、上記（III）に基づき、これらの時間帯は電源ＯＦＦ状態と判定する。そして、第１統合部２７は、図１０に示すように、ＶＭ１及びＶＭ３の８時台，並びにＶＭ２の８時台及び１１時台について、電源ＯＦＦ状態を示すハイフン（−）を設定する。
【００７４】
なお、第１統合リスト２２ｃに設定される稼働状態を示す黒丸（●），白丸（○），ハイフン（−），バツ（×）の記号は例示であり、これらに限定されるものではない。これらの稼働状態は、例えば２ビットの２進数等、種々の手法で表現することができる。
【００７５】
このように、第１統合部２７は、動作データリスト２２ａ及び動作判別リスト２２ｂに基づいて、動作実績レポート２１ｂを作成するための１時間ごとの状態判別を行なう。このとき、第１統合部２７は、統合処理において、動作データリスト２２ａで電源ＯＮ状態の時間帯については、処理実行中かアイドル状態かを判別することができる。これにより、電源ＯＮ状態の時間帯を、処理実行中の状態及びアイドル状態のいずれかに特定することができ、動作実績レポート２１ｂの信頼性を高めることができる。
【００７６】
第２統合部２８は、第１統合部２７により統合処理が行なわれた第１統合リスト２２ｃについて、各ＶＭ１１の複数の統合単位の時間帯での稼働状態を、動作実績レポート２１ｂでの集計単位に統合する処理を行なう。そして、第２統合部２８は、図１１に例示する第２統合リスト２２ｄを作成して保持部２２に格納する。本実施形態では、第２統合部２８は、動作実績レポート２１ｂでの集計単位である１日を統合単位として、第１統合リスト２２ｃの１時間単位の稼働状態の統合処理を行なうものとする。
【００７７】
なお、以下の説明において、管理ＶＭ１５は、障害が発生しても２４時間以内に復旧することを前提とし、２４時間全ての時間帯がデータ欠損（判別不能）である場合は対象外とする。これは、管理ＶＭ１５が障害により停止する場合、６時間程度で復旧されることが多く、管理ＶＭ１５の障害が２４時間続けて発生することは稀であるからである。また、管理ＶＭ１５が２４時間以上ダウンするような障害が発生した場合、このときの稼働状態はアイドルＶＭ削減の訴求力とはならないためである。
【００７８】
第２統合部２８は、例えば、各ＶＭ１１について、第１統合リスト２２ｃから統合単位（１日単位）で複数（この場合２４個）の稼働状態を読み出し、以下の条件によって、統合した時間帯（１日）の稼働状態を判別する。
【００７９】
（１）読み出した複数の稼働状態に１つでも処理実行中（黒丸：●）がある場合：処理を実行していた実績があるため、統合した時間帯を処理実行中と判定する。
【００８０】
（２）読み出した複数の稼働状態に１つも処理実行中が無く、１つでもデータ欠損（バツ：×）がある場合：
（２−１）データ欠損の直前の時間帯がアイドル状態（白丸：○）である場合：管理ＶＭ１５の障害時以外はアイドル状態と判断できるため、統合した時間帯をほぼアイドル状態と判定する。
（２−２）データ欠損の直前の時間帯が電源ＯＦＦ状態（ハイフン：−）である場合：
（２−２−１）データ欠損を除く全ての時間帯が電源ＯＦＦ状態の場合：統合した時間帯を電源ＯＦＦ状態と判定する。
（２−２−２）データ欠損を除く時間帯に１つでもアイドル状態がある場合：統合した時間帯をアイドル状態と判定する。
【００８１】
（３）読み出した複数の稼働状態に１つも処理実行中及びデータ欠損が無い場合：
（３−１）全ての時間帯が電源ＯＦＦ状態である場合：統合した時間帯を電源ＯＦＦ状態と判定する。
（３−２）１つでもアイドル状態がある場合：統合した時間帯をアイドル状態と判定する。
【００８２】
なお、上記（２−１）において、「ほぼアイドル状態」と判断された日は、データ欠損の時間帯の稼働状態は不明である。しかし、データの存在する時間が常にアイドル状態であり、且つ直前のデータもアイドル状態を示すことから、当該ＶＭ１１は、当日、長時間アイドル状態として放置されていた可能性がある。このため、上記（２−１）に該当する場合は、その日を「ほぼアイドル状態」とすることで、利用者に対してアイドル状態と判別された日と同様に不要なＶＭ１１の削減や電源ＯＦＦを訴えることができ、リソースの無駄な利用の抑制を図ることができる。
【００８３】
一例として、第２統合部２８が、図１０に示す第１統合リスト２２ｃについて１日分の稼働状態に統合する場合を説明する。なお、第２統合部２８は２４時間分の稼働状態を用いるが、図１０では４時間分の稼働状態のみを示している。以下の説明では、説明の簡略化のため、第２統合部２８が４時間分の稼働状態を１日分の稼働状態に統合するものとする。
【００８４】
例えば、第２統合部２８は、ＶＭ１について、１つも処理実行中が無く、且つ、データ欠損（１０時台）の直前はアイドル状態（９時台）であると判断する。従って、第２統合部２８は、上記（２−１）に基づき、高確率でデータ欠損した箇所もアイドル状態であったと推測して、図１１に示すように、ＶＭ１については、ほぼアイドル状態を示す網掛けの丸を設定する。
【００８５】
また、第２統合部２８は、ＶＭ２について、９時台に処理実行中があると判断する。従って、第２統合部２８は、上記（１）に基づき、図１１に示すように、ＶＭ２については、処理実行中を示す黒丸（●）を設定する。
【００８６】
さらに、第２統合部２８は、ＶＭ３についてもＶＭ２と同様に、９時台及び１１時台に処理実行中があると判断する。従って、第２統合部２８は、上記（１）に基づき、図１１に示すように、ＶＭ３についても、処理実行中を示す黒丸（●）を設定する。
【００８７】
このように、第２統合部２８は、稼働情報が存在しない第１の期間における推定されたＶＭ１１の動作状態と、第１の期間の前後少なくとも一方の期間におけるＶＭ１１の動作状態とに基づいて、所定の期間におけるＶＭ１１の動作状態を推定するのである。
【００８８】
以上のように、第２統合部２８によれば、例えば管理ＶＭ１５で６時間に亘って障害が発生していたとしても、残りの１８時間から１日の稼働状態を判別することができる。従って、処理実行中又は電源ＯＦＦ状態のＶＭ１１の稼働状態を正しく判別でき、仮にデータ欠損の時間帯でＶＭ１１が処理を実行していたとしても、アイドル状態であると誤判別せずに実態に則した判定結果を得ることができる。
【００８９】
ＶＭ管理情報追加部２９は、ＶＭ管理情報格納サーバ３から各ＶＭ１１のＶＭ管理情報３１ａを抽出する（図１２参照）。そして、ＶＭ管理情報追加部２９は、抽出した情報を第２統合部２８が作成した第２統合リスト２２ｄの情報とマージし、図１３に例示するように動作実績レポート２１ｂを作成して記憶部２１に格納する。なお、ＶＭ管理情報３１ａの取得方法は、既知の種々の手法により行なうことが可能である。本実施形態では、ＶＭ管理情報追加部２９は、ＶＭ管理情報３１ａのデータベース（Database）である記憶部３１へのアクセス及び参照によってＶＭ管理情報３１ａを取得する。
【００９０】
レポート転送部３０は、記憶部２１に格納された動作実績レポート２１ｂを例えばＦＴＰ等の手法によりＷｅｂサーバ４に転送する。
【００９１】
以上のように、出力サーバ２は、第１の期間における管理ＶＭ１５の動作情報と、第１の期間の前後少なくとも一方において取得されているＶＭ１１の動作情報とに基づき、第１の期間におけるＶＭ１１の動作実績を推定する推定部としての機能をそなえる。例えば、一実施形態において、動作判別部２５，第１統合部２７，及び第２統合部２８が推定部の一例であるといえる。また、レポート転送部３０は、動作情報の取得されなかった期間（第１の期間）におけるＶＭ１１の動作実績を出力する出力部の一例であるといえる。
【００９２】
〔３−３〕動作実績レポートの表示例
出力サーバ２からＷｅｂサーバ４に転送された動作実績レポート２１ｂは、例えばＷｅｂサーバ４により動作実績レポート４１ｂとして記憶部４１に格納される。そして、この動作実績レポート４１ｂは、図１４に例示するように、クラウドシステムの利用者に向けたレポート提供サイトからダウンロード可能となる。
【００９３】
なお、動作実績レポート４１ｂは、例えばＸＬＳ，ＣＳＶ，ＴＳＶ等のデータ形式とすることができる。動作実績レポート４１ｂをこれらの形式にするために、出力サーバ２（第２統合部２８，ＶＭ管理情報追加部２９若しくはレポート転送部３０等），又はＷｅｂサーバ４等においてデータ変換が行なわれてもよい。
【００９４】
利用者は、図１４に示すように、端末６−１〜６−ｉの画面上に表示される「アイドルＶＭ検出レポートのダウンロード」から任意の月度をクリックすることで、該当月度の動作実績レポート４１ｂをダウンロードすることができる。
【００９５】
図１５は、Ｗｅｂサーバ４が提供する３０台のサーバ１−１〜１−ｎ，約１５００台のＶＭ１１，及び１台の管理ＶＭ１５をそなえるクラウドシステムの動作実績レポート４１ｂの一例である。この図１５では、９月度（８月２１日から９月２０日まで）のＶＭ１１の稼働状態をレポート化したものが一部抜粋されている。なお、動作実績レポート４１ｂには、図１５に示すように「期間内全てアイドル」，「７日以上連続でアイドル」，「アイドル状態だった日数」等の項目が適宜追加されてもよい。
【００９６】
図１５の例では、８月３０日にデータ欠損が生じている。従来は、データ欠損部分を含む１日単位での判別が行なわれないため、図１６に示すように、８月３０日についてはデータ欠損（レポート中、“？”と表記）と表示されてしまう。
【００９７】
これに対し、本実施形態では、８月３０日についてデータ欠損部分を含む１日単位の稼働状態の判別手法が用いられる。これにより、利用者は、図１５に示すように、アイドル状態であったＶＭ１１と、データ欠損時の稼働状態は不明であるがその他の時間帯の稼働状態の判別結果から「ほぼアイドル状態」であると判定されたＶＭ１１とを容易に把握することができる。従って、クラウドシステムの管理者は、不要と推測されるＶＭ１１の利用者に対し、ＶＭ１１の電源ＯＦＦを促すことができ、リソースの無駄な利用の抑制を実現することができる。
【００９８】
〔３−４〕出力サーバの動作例
次に、上述の如く構成された出力サーバ２の動作例を、図１７〜図２２を参照して説明する。
【００９９】
はじめに、図１７に示すフローチャートを参照して、出力サーバ２における動作実績レポート２１ｂの作成処理の動作例について説明する。なお、前提として、クラウドシステムの管理ＶＭ１５が各ＶＭ１１から稼働情報を１０分ごとに収集し、記憶部１９に動作データ１９ａとして格納しているものとする。また、動作実績レポート２１ｂは月次集計されるものとし、出力サーバ２は、１週間ごとに動作実績レポート２１ｂの作成処理を行ない、作成した７日分のレポートをＷｅｂサーバ４の動作実績レポート２１ｂ（当月次内のファイル）に追加するものとする。
【０１００】
まず、図１７に示すように、出力サーバ２の動作データ取得部２３が管理ＶＭ１５から動作データ１９ａを取得し、動作データ２１ａとして記憶部２１にコピーする（ステップＳ１）。次いで、動作データリスト作成部２４が動作データ２１ａに基づき動作データリスト２２ａを作成し（ステップＳ２）、保持部２２に格納する。
【０１０１】
次に、動作判別部２５が、保持部２２の動作データリスト２２ａに基づき、各稼働状態について電源ＯＮ，電源ＯＦＦ，及び管理ＶＭ１５での障害発生（データ欠損有）を判別して動作判別リスト２２ｂを作成する（ステップＳ３）。この動作判別リスト２２ｂは、保持部２２に格納される。
【０１０２】
そして、第１統合部２７が、動作判別リスト２２ｂの稼働状態を１時間単位で統合して第１統合リスト２２ｃを作成し、保持部２２に格納する。このとき、第１統合部２７は、各ＶＭ１１の稼働状態をアイドル，処理実行中，電源ＯＦＦ，及びデータ欠損（判別不能）に分類する（ステップＳ４）。次いで、第２統合部２８が第１統合リスト２２ｃの稼働状態を１日単位で統合して第２統合リスト２２ｄを作成し（ステップＳ５）、保持部２２に格納する。
【０１０３】
ＶＭ管理情報追加部２９は、ＶＭ管理情報格納サーバ３からＶＭ管理情報３１ａを取得し、第２統合リスト２２ｄとマージして動作実績レポート２１ｂを作成し、記憶部２１に格納する（ステップＳ６）。そして、レポート転送部３０が動作実績レポート２１ｂをＷｅｂサーバ４に転送し格納させ（ステップＳ７）、出力サーバ２の処理が終了する。なお、ステップＳ２〜Ｓ５の各処理の詳細は後述する。
【０１０４】
〔３−４−１〕動作データリスト作成処理の一例
次に、図１８に示すフローチャートに従って、動作データリスト作成部２４の動作例（図１７のステップＳ２の詳細例）を説明する。
【０１０５】
図１８に示すように、動作データリスト作成部２４が、記憶部２１の動作データ２１ａをファイルの先頭から終端まで読み込み、動作データ２１ａに設定された日時（収集日時）及びＶＭ名を記憶する（ステップＳ１１）。記憶した日時及びＶＭ名は、動作データリスト作成部２４により、動作データリスト２２ａのテーブルのカラム及びレコード数等を把握し、動作データリスト２２ａを作成するために用いられる。
【０１０６】
次いで、動作データリスト作成部２４が、読み込み位置を動作データ２１ａの先頭に戻し（ステップＳ１２）、動作データ２１ａを１行読み込む（ステップＳ１３）。また、動作データリスト作成部２４が、読み込んだ行の日時及びＶＭ名に対応するテーブルの位置に、ＣＰＵ使用率，ディスクＩ／Ｏ量，及びネットワークＩ／Ｏ量の値を挿入する（ステップＳ１４）。
【０１０７】
そして、動作データリスト２２ａが、現在の読み込み位置が動作データ２１ａのファイルの終端であるか否かを判断する（ステップＳ１５）。ファイルの終端でなければ（ステップＳ１５のＮｏルート）、処理がステップＳ１３に移行する一方、ファイルの終端であれば（ステップＳ１５のＹｅｓルート）、処理が終了する。以上により、動作データリスト作成部２４の処理が終了する。
【０１０８】
〔３−４−２〕動作判別リスト作成処理の一例
次に、図１９に示すフローチャートに従って、動作判別部２５の動作例（図１７のステップＳ３の詳細例）を説明する。
【０１０９】
図１９に示すように、動作判別部２５が、保持部２２の動作データリスト２２ａを１行読み込み（ステップＳ２１）、ＶＭ１１識別用の変数ｎを定義する（ｎ＝１；ステップＳ２２）。次いで、動作判別部２５が、読み込んだ情報に管理ＶＭ１５のＣＰＵ使用率のデータがあるか否かを判断する（ステップＳ２３）。管理ＶＭ１５のＣＰＵ使用率のデータがある場合（ステップＳ２３のＹｅｓルート）、動作判別部２５が、読み込んだ情報にＶＭｎのＣＰＵ使用率のデータがあるか否かを判断する（ステップＳ２４）。
【０１１０】
読み込んだ情報にＶＭｎのＣＰＵ使用率のデータがある場合（ステップＳ２４のＹｅｓルート）、動作判別部２５が、動作判別リスト２２ｂの対象日時におけるＶＭｎ欄に“pon”を設定し（ステップＳ２５）、ｎをインクリメントする（ステップＳ２６）。そして、動作判別部２５が、ｎが利用者のＶＭ数を上回ったか否かを判断し（ステップＳ２７）、上回っていない場合（ステップＳ２７のＮｏルート）、処理がステップＳ２４に移行する。
【０１１１】
一方、ｎが利用者のＶＭ数を上回った場合（ステップＳ２７のＹｅｓルート）、動作判別部２５が、現在の読み込み位置が動作データリスト２２ａの終端であるか否かを判断する（ステップＳ２８）。終端ではない場合（ステップＳ２８のＮｏルート）、処理がステップＳ２１に移行する一方、終端である場合（ステップＳ２８のＹｅｓルート）、処理が終了する。
【０１１２】
また、ステップＳ２４において、読み込んだ情報にＶＭｎのＣＰＵ使用率のデータが無い場合（ステップＳ２４のＮｏルート）、動作判別部２５が、動作判別リスト２２ｂの対象日時におけるＶＭｎ欄に“poff”を設定し（ステップＳ２９）、処理がステップＳ２６に移行する。
【０１１３】
さらに、ステップＳ２３において、読み込んだ情報に管理ＶＭ１５のＣＰＵ使用率のデータが無い場合（ステップＳ２３のＮｏルート）、動作判別部２５が、動作判別リスト２２ｂの対象日時における全てのＶＭ欄に“down”を設定し（ステップＳ３０）、処理がステップＳ２８に移行する。以上により、動作判別部２５の処理が終了する。
【０１１４】
〔３−４−３〕第１統合部の統合処理の一例
次に、図２０及び図２１に示すフローチャートに従って、第１統合部２７の動作例（図１７のステップＳ４の詳細例）を説明する。
【０１１５】
図２０に示すように、第１統合部２７が、ＶＭ１１識別用の変数ｎを定義し（ｎ＝１；ステップＳ５１）、動作判別リスト２２ｂのＶＭｎ欄の１時間分（６つ）の稼働状態を読み込む（ステップＳ５２）。そして、第１統合部２７は、読み込んだ複数の稼働状態について、“down”及び“pon”の順に該当する稼働状態があるか否かを判断する（ステップＳ５３及びＳ５４）。
【０１１６】
読み込んだ複数の稼働状態に１つも“down”及び“pon”が無い場合（Ｓ５３及びＳ５４のＮｏルート）、第１統合部２７が、全て“poff”であると判断し、その時間帯を電源ＯＦＦ（−）と判断する（ステップＳ５５）。そして、第１統合部２７が、現在の行が動作判別リスト２２ｂの終端であるか否かを判断し（ステップＳ５６）。終端でない場合（ステップＳ５６のＮｏルート）、処理がステップＳ５２に移行する。
【０１１７】
一方、終端の場合（ステップＳ５６のＹｅｓルート）、第１統合部２７がｎをインクリメントして（ｎ＝ｎ＋１；ステップＳ５７）、ｎが利用者のＶＭ数を上回ったか否かを判断する（ステップＳ５８）。ｎが利用者のＶＭ数を上回っていない場合（ステップＳ５８のＮｏルート）、処理がステップＳ５２に移行する。一方、ｎが利用者のＶＭ数を上回った場合（ステップＳ５８のＹｅｓルート）、処理が終了する。
【０１１８】
また、ステップＳ５４において、読み込んだ複数の稼働状態に１つも“down”は無いが、１つでも“pon”がある場合（ステップＳ５３のＮｏルート且つステップＳ５４のＹｅｓルート）、処理がステップＳ５９に移行する。ステップＳ５９では、第１統合部２７が、１時間分のデータのうち“pon”が存在するデータでアイドル判別処理を行ない、処理がステップＳ５６に移行する。なお、ステップＳ５９の詳細は後述する。
【０１１９】
さらに、ステップＳ５３において、読み込んだ複数の稼働状態に１つでも“down”がある場合（ステップＳ５３のＹｅｓルート）、第１統合部２７が、その時間帯をデータ欠損（判別不能）（×）と判断し（ステップＳ６０）、処理がステップＳ５６に移行する。以上により、第１統合部２７の処理が終了する。なお、第１統合部２７は、上記処理の過程で、第１統合リスト２２ｃを新たに生成若しくは更新する。または、第１統合部２７は、動作判別リスト２２ｂを加工（一部のデータを削除等）することで第１統合リスト２２ｃを生成してもよい。
【０１２０】
次に、ステップＳ５９のアイドル判別処理について説明する。
【０１２１】
図２１に示すように、まず、第１統合部２７が、各閾値を設定し（ステップＳ７１）、図２０のステップＳ５５で“pon”と判断された稼働情報の各値を動作データリスト２２ａから取得する。そして、第１統合部２７が、取得した動作情報の各要素の値と対応する閾値とを比較する（ステップＳ７２）。なお、ステップＳ７１の処理は、例えば管理者等が予め記憶部２１又は保持部２２等に各閾値を設定し、第１統合部２７がその閾値を読み出すことにより実行されてよい。
【０１２２】
次いで、第１統合部２７が、１時間ごとに、全ての要素が閾値を下回っていた時間の合計を算出する（ステップＳ７３）。そして、第１統合部２７が、１時間に対する算出した合計時間の比率がアイドル時間の比率（所定の閾値；ここでは80.2％）よりも大きいか否かを判断する（ステップＳ７４）。
【０１２３】
合計時間の比率がアイドル時間の比率よりも大きい場合（ステップＳ７４のＹｅｓルート）、第１統合部２７が、その時間帯をアイドル（○）と判別し（ステップＳ７５）、処理が終了する。一方、合計時間の比率がアイドル時間の比率以下の場合（ステップＳ７４のＮｏルート）、第１統合部２７が、その時間帯を処理実行中（●）と判別し（ステップＳ７６）、処理が終了する。以上により、第１統合部２７によるアイドル判別処理が終了する。
【０１２４】
〔３−４−４〕第２統合部の統合処理の一例
次に、図２２に示すフローチャートに従って、第２統合部２８の動作例（図１７のステップＳ５の詳細例）を説明する。なお、図２２の処理は、ＶＭ１１ごとに実行されるものとする。
【０１２５】
図２２に示すように、第２統合部２８が、保持部２２の第１統合リスト２２ｃについて、１日分の稼働状態の中に処理実行中が１つでもあるか否かを判断する（ステップＳ８１）。処理実行中がある場合（ステップＳ８１のＹｅｓルート）、第２統合部２８が、その１日を処理実行中と判別し（ステップＳ８２）、全ての日について判別が終わったか否かを判断する（ステップＳ８３）。全ての日で判別が終わっていない場合（ステップＳ８３のＮｏルート）、処理がステップＳ８１に移行する。一方、全ての日で判別が終わった場合（ステップＳ８３のＹｅｓルート）、処理が終了する。
【０１２６】
また、ステップＳ８１において、１日分の稼働状態の中に処理実行中が１つも無い場合（ステップＳ８１のＮｏルート）、第２統合部２８が、１日分の稼働状態の中にデータ欠損が１つでもあるか否かを判断する（ステップＳ８４）。１日分の稼働状態の中にデータ欠損がある場合（ステップＳ８４のＹｅｓルート）、第２統合部２８がデータ欠損の直前の時間帯がアイドル（○）であるか否かを判断する（ステップＳ８５）。
【０１２７】
データ欠損の直前の時間帯がアイドルの場合（ステップＳ８５のＹｅｓルート）、第２統合部２８がその１日をほぼアイドルと判別し（ステップＳ８６）、処理がステップＳ８３に移行する。
【０１２８】
また、ステップＳ８５において、データ欠損の直前の時間帯がアイドルではない場合（ステップＳ８５のＮｏルート）、第２統合部２８がその日の動作状況についてデータ欠損以外の時間帯が全て電源ＯＦＦであるか否かを判断する（ステップＳ８７）。データ欠損以外の時間帯が全て電源ＯＦＦの場合（ステップＳ８７のＹｅｓルート）、第２統合部２８がその１日を電源ＯＦＦと判別し（ステップＳ８８）、処理がステップＳ８３に移行する。
【０１２９】
一方、データ欠損以外の時間帯が全て電源ＯＦＦではない場合（ステップＳ８７のＮｏルート）、第２統合部２８がその１日をアイドルと判別し（ステップＳ８９）、処理がステップＳ８３に移行する。
【０１３０】
また、ステップＳ８４において、１日分の稼働状態の中にデータ欠損が無い場合（ステップＳ８４のＮｏルート）、第２統合部２８がその１日における各時間帯の判別結果が全て電源ＯＦＦであるか否かを判断する（ステップＳ９０）。全て電源ＯＦＦの場合（ステップＳ９０のＹｅｓルート）、第２統合部２８がその１日を電源ＯＦＦと判別し（ステップＳ９１）、処理がステップＳ８３に移行する。
【０１３１】
一方、その１日における各時間帯の判別結果に電源ＯＦＦ以外がある場合（ステップＳ９０のＮｏルート）、第２統合部２８がその１日をアイドルと判別し（ステップＳ９２）、処理がステップＳ８３に移行する。以上により、第２統合部２８の処理が終了する。
【０１３２】
〔３−５〕本実施形態の効果
上述した一実施形態に係る出力サーバ２によれば、所定の期間にＶＭ１１の動作情報の取得されなかった第１の期間が含まれる場合でも、第１の期間におけるＶＭ１１の動作実績が推定され、出力される。すなわち、出力サーバ２は、第１の期間における管理ＶＭ１５の動作情報と、第１の期間の前後少なくとも一方において取得されているＶＭ１１の動作情報とに基づき、第１の期間におけるＶＭ１１の動作実績を推定することができる。従って、動作情報の取得されなかった期間におけるＶＭ１１の動作実績を出力することができる。
【０１３３】
クラウドシステムに関する分野では、稼働情報を用いてＶＭの稼働状態を分類することがあるが、稼働情報の無い部分には、どういった経緯で稼働情報が無いのか（利用者によるものか、管理ＶＭ１５の障害によるものか）が情報として存在しない。従って、従来、出力サーバは、ＶＭが稼働していた時間についてのみ、稼働状態を判定して表示し、稼働情報の無い部分に関しては考慮せずに済んでいた。
【０１３４】
しかし、利用者に対してＶＭの電源ＯＦＦ状態についても稼働実績として可視化することを試みる場合、従来はあまり認識されていなかったが、上述したように、稼働情報の無い部分について要因を特定（稼働状態を分類）することが重要であることがわかる。例えば、稼働情報の欠如について、利用者による電源ＯＦＦと管理ＶＭの障害との区別や、欠如箇所の前後の時間帯のデータからの欠如箇所の稼働状態の分類をしない場合、データの無い時間帯が全てデータ欠損とみなされてしまう（図２〜図４参照）。
【０１３５】
なお、稼働情報の欠如について、利用者によるＶＭの電源ＯＦＦ制御と管理ＶＭの障害との区別をせず、データの無い時間帯を全てＶＭの電源ＯＦＦによるものと見做した場合、１時間ごとの各ＶＭの稼働状態の判別結果は、図２６に例示する結果となる。図２６では、管理ＶＭの障害により利用者のＶＭの稼働情報も取得できていないが、利用者のＶＭ自体は起動していた場合でも、電源ＯＦＦによるものと見做され（１０時台参照）、実態とは違った状況を示すものとなってしまう。
【０１３６】
また、過去の時点でのＶＭの電源ＯＮ／ＯＦＦの状態を把握するには、仮想化のホストサーバのシステムログを参照することも考えられる。しかし、図１５の説明で想定したクラウドシステムを例に挙げると、３０台のホストサーバにそれぞれ存在するシステムログの中から、１５００ものＶＭの生死確認を行なうことになり、動作データ２１ａを用いるよりも処理量が大きく、処理に時間もかかる。
【０１３７】
さらに、ＳＮＭＰ（Simple Network Management Protocol）の拡張トラップ信号に電源ＯＮ／ＯＦＦ状態の定義を行ない、Ｐｉｎｇ応答によって電源ＯＮ，電源ＯＦＦ，障害発生の判別をすることも考えられる。しかし、この場合、ＶＭ上でセキュリティ向上を目的としてＰｉｎｇ応答を制限することも可能であるため、Ｐｉｎｇ応答を制限設定しているＶＭについては、稼働状態の判別を行なうことができない。
【０１３８】
これらの手法に対し、出力サーバ２によれば、利用者によるＶＭ１１の電源ＯＦＦ状態を容易に判別できるため、例えば図２３〜図２５に示すように、８時台のＶＭ１，ＶＭ２及びＶＭ３，並びに１１時台のＶＭ２について、稼働情報の近似線の算出を抑止できる。このように、出力サーバ２によれば、処理負荷を抑えつつ、動作実績のレポートの信頼性を向上させることができる。
【０１３９】
〔４〕変形例
一実施形態では、出力サーバ２が、第１統合部２７により１時間単位でＶＭ１１の稼働状態を判別し、その結果を用いて第２統合部２８が１日単位でＶＭ１１の稼働状態を判別するものとして説明したが、これに限定されるものではない。
【０１４０】
〔４−１〕第１変形例
例えば、動作実績レポート２１ｂが１時間単位でＶＭ１１の稼働状態を判別した動作実績レポート２１ｂを出力する場合、出力サーバ２は、図２７に例示する構成とすることができる。
【０１４１】
図２７に示すように、第１変形例に係るシステムにおいて出力サーバ２は、新たに補完処理部２６の機能をそなえるとともに、第２統合部２８の機能を省略することができる。
【０１４２】
補完処理部２６は、動作判別部２５によって、管理ＶＭ１５の障害によるデータ欠損であると判断された箇所（動作判別リスト２２ｂの“down”が設定されている箇所）のうち、データ補完が可能な箇所の補完処理を行なうことができる。例えば、補完処理部２６は、動作判別リスト２２ｂの“down”が設定された前後の時間帯のデータに基づき、データ補完が可能な箇所（稼働状態）に補完処理を行ない、図２８に示すように動作判別リスト２２ｂを更新する。なお、補完処理部２６は、データ補完が不可能な箇所については、補完処理を行なわず、判断不能とする（“unknown”を設定する）。
【０１４３】
例えば、補完処理部２６は、動作判別リスト２２ｂを参照して、ＶＭ１１ごとに１行ずつ読み込み、“down”が設定された箇所を以下の４つのケースに分類して、動作判別リスト２２ｂを更新する。
【０１４４】
（ｉ）“down”が設定された箇所の前後の時間帯が電源ＯＮ状態の場合：
管理ＶＭ１５の操作が不可能であるため、データ欠損の時間帯にはＶＭ１１の電源操作ができないことから、補完処理部２６は、“down”の設定された箇所が電源ＯＮ状態であったと判別する。そして、補完処理部２６は、“down”の設定された箇所に電源ＯＮ状態と推定したことを示す“pon_nodata”を設定して書き換える。
【０１４５】
（ii）“down”が設定された箇所の前後の時間帯が電源ＯＦＦ状態の場合：
管理ＶＭ１５の操作が不可能であるため、データ欠損の時間帯にはＶＭ１１の電源操作ができないことから、補完処理部２６は、“down”の設定された箇所が電源ＯＦＦ状態であったと判別する。そして、補完処理部２６は、“down”の設定された箇所に電源ＯＦＦ状態と推定したことを示す“poff”を設定して書き換える。
【０１４６】
（iii）“down”が設定された箇所の前の時間帯が電源ＯＮ状態、“down”が設定された箇所の後の時間帯が電源ＯＦＦ状態の場合：
データ欠損の時間帯での管理ＶＭ１５による電源操作が不可能であるにもかかわらず、データ欠損の時間帯のどこかのタイミングでＶＭ１１が電源ＯＦＦにされている。この場合、補完処理部２６は、“down”の設定された箇所の稼働状態（電源ＯＮ状態／電源ＯＦＦ状態）の判断をしない。そして、補完処理部２６は、“down”の設定された箇所に稼働状態を判断しなかったことを示す“unknown”を設定して書き換える。
【０１４７】
（iv）“down”の設定された箇所の前の時間帯が電源ＯＦＦ状態、“down”の設定された箇所の後の時間帯が電源ＯＮ状態の場合：
データ欠損の時間帯での管理ＶＭ１５による電源操作が不可能であるにもかかわらず、データ欠損の時間帯のどこかのタイミングでＶＭ１１が電源ＯＮにされている。この場合においても、補完処理部２６は、“down”の設定された箇所の稼働状態（電源ＯＮ状態／電源ＯＦＦ状態）の判断をしない。そして、補完処理部２６は、“down”の設定された箇所に稼働状態を判断しなかったことを示す“unknown”を設定して書き換える。
【０１４８】
一例として、補完処理部２６が図９に示す動作判別リスト２２ｂのＶＭ１の補完処理を行なう場合について説明する。補完処理部２６は、動作判別リスト２２ｂのＶＭ１の欄を１行読み込む。8:00は“poff”であるため、補完処理部２６は、“Before = poff”として、“down”が書き込まれている行まで一行ずつ順に読み進む。10:00は“down”であるため、補完処理部２６は、“Before = pon”と判断して、“down”以外が書き込まれている行まで読み進む。11:00は“pon”であるため、補完処理部２６は、“After = pon”と判断する。
【０１４９】
補完処理部２６は、10:00から10:50までの“down”であった時間について、“Before = pon”、且つ“After = pon”であるため、上記（ｉ）に従い10:00から10:50までを“pon_nodata”に書き換える。なお、補完処理部２６は、同様に11:10から11:50まで一行ずつ読み進めるが、“Down”が無いままリストの終端まで達するため、ＶＭ１のデータ欠損箇所の補完処理を終了する。また、補完処理部２６は、図９の例について、ＶＭ１と同様にＶＭ２及びＶＭ３についても、“down”の前後の時間帯に設定された稼働状態に基づいて、“down”の時間帯の稼働状態の補完の要否の判定及び分類を行なう。
【０１５０】
上記（ｉ）〜（iv）に示すような判断基準により、補完処理部２６は、図２８に示すように動作判別リスト２２ｂの更新を行なう。例えば、補完処理部２６は、図２８の太枠で示す時間帯（10:00〜10:50）について、ＶＭ１及びＶＭ３に対し、“down”の時間帯の前後が“pon”であるため、電源ＯＮ状態と推定し“pon_nodata”を設定する。また、補完処理部２６は、当該時間帯のＶＭ２に対し、“down”の時間帯の前は“pon”であるが後は“poff”であるため、稼働状態を判断せず“unknown”を設定する。
【０１５１】
上述した補完処理部２６による分類により、上記（ｉ）のケースに該当する箇所は、本来は稼働状況が取得できていないにもかかわらず、電源ＯＮ状態であると判別されてデータの補完が行なわれることになる。なお、上記（ii）のケースに該当する箇所は電源ＯＦＦ状態であると判別されるためデータの補完が不要であり、上記（iii），（iv）のケースに該当する箇所は電源ＯＮ／ＯＦＦが判別されないため、データの補完が不要である。
【０１５２】
このように、補完処理部２６は、クラウドシステムにおいて、電源ＯＮ／ＯＦＦの操作が管理ＶＭ１５を経由して行なわれることに着目し、管理ＶＭ１５の障害と判断された時間帯について前後の時間帯の稼働状態を評価する。そして、補完処理部２６は、動作判別リスト２２ｂ内の、“データの無い時間帯”の稼働状態を補完する時間帯及び補完しない時間帯をそれぞれ特定（推定）することができる。これにより、補完処理部２６では、稼働状態の補完を行なうか否かを適切に判別することができ、稼働状態の分類を正確に行なうことができる。
【０１５３】
なお、第１変形例に係る補完処理部２６は、“down”の前後の時間帯の稼働状態に基づき上述した処理を行なうものとして説明したが、これに限定されるものではない。補完処理部２６は、少なくとも“down”の前後少なくとも一方の時間帯の稼働状態に基づき上述した処理を行なってもよい。
【０１５４】
すなわち、補完処理部２６は、管理ＶＭ１５の動作情報が取得されなかった第２の期間におけるＶＭ１１の動作状態を、第２の期間の前後少なくとも一方において取得されたＶＭ１１の動作情報に基づいて推定するといえる。
【０１５５】
第１実施例に係る第１統合部２７は、補完処理部２６により補完処理が行なわれた動作判別リスト２２ｂについて、各ＶＭ１１の複数の時間帯での稼働状態を統合する処理を行ない、図２９に例示する第１統合リスト２２ｃを作成して保持部２２に格納する。
【０１５６】
例えば、第１統合部２７は、各ＶＭ１１について、動作判別リスト２２ｂから統合単位（１時間単位）で複数（この場合６つ）の稼働状態を読み出し、一実施形態とは異なる以下の条件によって、統合した時間帯の稼働状態を判別する。
【０１５７】
（Ｉ’）読み出した複数の稼働状態に１つでも“unknown”がある場合：統合した時間帯を判断不能と判定する。
【０１５８】
（II’）読み出した複数の稼働状態に１つも“unknown”が無く、且つ、１つでも“pon_nodata”がある場合：統合した時間帯を電源ＯＮ状態と判定する。
【０１５９】
（III’）読み出した複数の稼働状態に１つも“unknown”及び“pon_nodata”が無く、且つ、１つでも“pon”がある場合：“pon”が設定されている時間帯（１０分単位）における稼働情報を用いて、アイドル判別処理を行なう。
【０１６０】
（IV’）上記（Ｉ’）〜（III’）に該当しない場合：統合した時間帯を電源ＯＦＦ状態と判定する。
【０１６１】
以下、重複した説明を避けるため、第１統合部２７が、図２８に示す動作判別リスト２２ｂについて、１０時台の稼働状態の統合を行なう場合を説明する。なお、実際には、第１統合部２７は、一実施形態と同様に１時間ごと（８時台，９時台，１０時台，１１時台）に稼働状態の統合を行なう。
【０１６２】
例えば、第１統合部２７は、ＶＭ２の１０時台について、６つ全ての時間帯（１０分単位）に“unknown”が設定されているため、上記（Ｉ’）に基づき、判断不能と判定する。そして、第１統合部２７は、図２９に示すように、ＶＭ２の１０時台については、判断不能を示すバツ（×）を設定する。
【０１６３】
また、第１統合部２７は、ＶＭ１及びＶＭ３の１０時台の各々について、いずれも１つも“unknown”が設定されていないが、６つ全ての時間帯（１０分単位）に“pon_nodata”が設定されていると判定する。従って、第１統合部２７は、上記（II’）に基づき、ＶＭ１及びＶＭ３の１０時台の各々は電源ＯＮ状態と判定し、図２９に示すように、ＶＭ１及びＶＭ３の１０時台について、電源ＯＮ状態を示す三角（△）を設定する。
【０１６４】
なお、図２９の第１統合リスト２２ｃに設定される稼働状態を示す黒丸（●），白丸（○），ハイフン（−），三角（△），バツ（×）の記号は例示であり、これらに限定されるものではない。これらの稼働状態は、例えば３ビットの２進数等、種々の手法で表現することができる。
【０１６５】
ＶＭ管理情報追加部２９は、以上のようにして生成された第１統合リスト２２ｃの情報とＶＭ管理情報３１ａとをマージし、１時間単位の動作実績レポート２１ｂを作成して記憶部２１に格納する。そして、１時間単位の動作実績レポート２１ｂは、レポート転送部３０によりＷｅｂサーバ４に転送され、Ｗｅｂサーバ４により、動作実績レポート４１ａとして端末６−１〜６−ｉに提供される。なお、動作実績レポート４１ｂは、出力サーバ２（第１統合部２７，ＶＭ管理情報追加部２９若しくはレポート転送部３０等），又はＷｅｂサーバ４等においてデータ変換が行なわれてもよい。
【０１６６】
以上のように、第１変形例において、動作判別部２５，補完処理部２６，及び第１統合部２７は、推定部の一例であるといえる。
【０１６７】
次に、上述の如く構成された第１変形例に係る出力サーバ２の動作例を、図３０〜図３２を参照して説明する。なお、以下の説明において、既述の処理と同一又は略同一の処理についての重複した説明を省略する。
【０１６８】
はじめに、図３０に示すフローチャートを参照して、第１変形例に係る出力サーバ２における動作実績レポート２１ｂの作成処理の動作について説明する。
【０１６９】
図３０に示すように、第１変形例では、図１７に示すステップＳ４〜Ｓ６に代えて、ステップＳ８〜Ｓ１０の処理が実行される。ステップＳ８では、補完処理部２６が動作判別リスト２２ｂに対してデータ補完を行なうか否かを判断し、行なうと判断した稼働状態についてデータの補完処理を行なう。
【０１７０】
そして、第１統合部２７が、動作判別リスト２２ｂの稼働状態を１時間単位で統合して第１統合リスト２２ｃを作成し、保持部２２に格納する。このとき、第１統合部２７は、各ＶＭ１１の稼働状態をアイドル，処理実行中，電源ＯＮ，電源ＯＦＦ，及び判別不能に分類する（ステップＳ９）。
【０１７１】
次いで、ＶＭ管理情報追加部２９は、ＶＭ管理情報格納サーバ３からＶＭ管理情報３１ａを取得する。そして、ＶＭ管理情報追加部２９は、第１統合リスト２２ｃとマージして１時間単位の動作実績レポート２１ｂを作成し、記憶部２１に格納して（ステップＳ１０）、処理がステップＳ７に移行する。
【０１７２】
次に、図３１に示すフローチャートに従って、補完処理部２６の動作例（図３０のステップＳ８の詳細例）を説明する。
【０１７３】
図３１に示すように、補完処理部２６が、ＶＭ１１識別用の変数ｎを定義し（ｎ＝１；ステップＳ３１）、読み込む行の前及び後の時間帯の稼働状態の値を格納する変数“Before”及び“After”を定義する（Before=null，After=null；ステップＳ３２）。次いで、補完処理部２６が、動作判別リスト２２ｂのＶＭｎの行を１行読み込み（ステップＳ３３）、稼働状態の値が“down”であるか否かを判断する（ステップＳ３４）。
【０１７４】
稼働状態の値が“down”である場合（ステップＳ３４のＹｅｓルート）、補完処理部２６が“down”でない行まで動作判別リスト２２ｂのＶＭｎを読み進める（ステップＳ３５）。“down”でない行を見つける前に動作判別リスト２２ｂの終端に達した場合（ステップＳ３６，Ｓ３６のＹｅｓルート）、又は“down”でない行を見つけたがそのとき“Before=null”の場合（ステップＳ３７，Ｓ３７のＹｅｓルート）、処理がステップＳ４９に移行する。
【０１７５】
一方、“down”でない行を見つけた場合（ステップＳ３６のＮｏルート）、且つそのとき“Before=null”ではない場合（ステップＳ３７のＮｏルート）、補完処理部２６が“After”にそのとき読み込んだ行の値を設定する（ステップＳ３８）。
【０１７６】
次いで、補完処理部２６が、“Before=pon”であるか否かを判断し（ステップＳ３９）、“Before=pon”の場合（ステップＳ３９のＹｅｓルート）、“After=pon”であるか否かを判断する（ステップＳ４０）。“After=pon”の場合（ステップＳ４０のＹｅｓルート）、“down”の前後の時間帯が“pon”であるため、補完処理部２６が動作判別リスト２２ｂのこれまで読み進めた“down”の位置の値を“pon_nodata”に書き換える（ステップＳ４１）。
【０１７７】
そして、補完処理部２６が、“Before”に“After”の値を設定し（ステップＳ４２）、現在の行が動作判別リスト２２ｂの終端であるか否かを判断する（ステップＳ４３）。終端でない場合（ステップＳ４３のＮｏルート）、処理がステップＳ３３に移行する。一方、終端の場合（ステップＳ４３のＹｅｓルート）、補完処理部２６がｎをインクリメントして（ｎ＝ｎ＋１；ステップＳ４４）、ｎが利用者のＶＭ数を上回ったか否かを判断する（ステップＳ４５）。
【０１７８】
ｎが利用者のＶＭ数を上回っていない場合（ステップＳ４５のＮｏルート）、処理がステップＳ３２に移行する。一方、ｎが利用者のＶＭ数を上回った場合（ステップＳ４５のＹｅｓルート）、処理が終了する。
【０１７９】
また、ステップＳ４０において、“After=pon”でない場合（ステップＳ４０のＮｏルート）、“down”の前後の時間帯でＶＭｎの稼働状態が異なっている（“down”の時間帯に電源がＯＮからＯＦＦに切り替えられている）。このため、補完処理部２６が動作判別リスト２２ｂのこれまで読み進めた“down”の位置の値を“unknown”に書き換え（ステップＳ４７）、処理がステップＳ４２に移行する。
【０１８０】
さらに、ステップＳ３９において、“Before=pon”でない場合（ステップＳ３９のＮｏルート）、補完処理部２６が“After=pon”であるか否かを判断する（ステップＳ４６）。“After=pon”の場合（ステップＳ４６のＹｅｓルート）、“down”の前後の時間帯でＶＭｎの稼働状態が異なっている（“down”の時間帯に電源がＯＦＦからＯＮに切り替えられている）。この場合も、処理がステップＳ４７経由でステップＳ４２に移行する。
【０１８１】
また、ステップＳ４６において、“After=pon”でない場合（ステップＳ４６のＮｏルート）、“down”の前後の時間帯が“poff”である。従って、補完処理部２６が動作判別リスト２２ｂのこれまで読み進めた“down”の位置の値を“poff”に書き換え（ステップＳ４８）、処理がステップＳ４２に移行する。
【０１８２】
なお、ステップＳ４９では、ステップＳ４７と同様に、補完処理部２６が動作判別リスト２２ｂのこれまで読み進めた“down”の位置の値を“unknown”に書き換え、処理がステップＳ４２に移行する。ここで、ステップＳ４９の処理は、上述のように、ステップＳ３６又はＳ３７でＹｅｓルートとなった場合に実行される。ステップＳ４９で“down”の位置の値が“unknown”に書き換えられるのは、ステップＳ３６でＹｅｓルートとなった場合、動作判別リスト２２ｂの終端まで“down”が設定されており、“down”の時間帯の後の稼働状態が不明なためである。また、ステップＳ３７でＹｅｓルートとなった場合、動作判別リスト２２ｂの開始から“down”が設定されており、“down”の時間帯の前の稼働状態が不明なためである。
【０１８３】
また、ステップＳ３４において、稼働状態の値が“down”ではない場合（ステップＳ３４のＮｏルート）、補完処理部２６が“Before”にそのとき読み込んだ行の値を設定し（ステップＳ５０）、処理がステップＳ４３に移行する。以上により、補完処理部２６の処理が終了する。
【０１８４】
次に、図３２に示すフローチャートに従って、第１変形例に係る第１統合部２７の動作例（図３０のステップＳ９の詳細例）を説明する。
【０１８５】
図３２に示すように、第１変形例では、図２０に示すステップＳ５３及びＳ６０に代えて、ステップＳ６１及びＳ６２並びにＳ６３及びＳ６４の処理が実行される。第１統合部２７は、ステップＳ５２で読み込んだ複数の稼働状態について、“unknown”，“pon_nodata”，及び“pon”の順に該当する稼働状態があるか否かを判断する（ステップＳ６１，Ｓ６２，Ｓ５４）。
【０１８６】
読み込んだ複数の稼働状態に１つも“unknown”，“pon_nodata”，及び“pon”が無い場合（Ｓ６１，Ｓ６２，Ｓ５４のＮｏルート）、処理がステップＳ５５に移行する。また、ステップＳ５４において、読み込んだ複数の稼働状態に１つも“unknown”及び“pon_nodata”は無いが、１つでも“pon”がある場合（ステップＳ６１及びＳ６２のＮｏルート且つステップＳ５４のＹｅｓルート）、処理がステップＳ５９に移行する。
【０１８７】
ステップＳ６２において、読み込んだ複数の稼働状態に１つも“unknown”は無いが、１つでも“pon_nodata”がある場合（ステップＳ６１のＮｏルート且つステップＳ６２のＹｅｓルート）、処理がステップＳ６３に移行する。ステップＳ６３では、第１統合部２７が、その時間帯を電源ＯＮ（△）と判断し、処理がステップＳ５６に移行する。
【０１８８】
また、ステップＳ６１において、読み込んだ複数の稼働状態に１つでも“unknown”がある場合（ステップＳ６１のＹｅｓルート）、第１統合部２７が、その時間帯を判別不能（×）と判断し（ステップＳ６４）、処理がステップＳ５６に移行する。
【０１８９】
第１変形例によれば、動作実績レポート２１ｂの集計単位が動作データ２１ａ（稼働情報）の収集単位の所定倍（例えば１０倍等；上記説明では６倍）以下である場合に、第２統合部２８の機能を省略することができる。従って、出力サーバ２の処理負荷を抑制することができ、動作実績レポート２１ｂを容易に生成することができる。
【０１９０】
また、第１統合部２７は、補完処理部２６により補完されたより詳細な動作データリスト２２ａに基づいて稼働状態を判別することができるため、動作実績レポート２１ｂをより精度の高いものとすることができる。
【０１９１】
〔４−２〕第２変形例
第１変形例に係る第１統合部２７は、上記（III’）において、読み出した複数の稼働状態に１つでも“pon”がある（電源ＯＮ状態）場合に、アイドル判別処理を行ない、統合した時間帯の稼働状態を処理実行中かアイドル状態か判断するものとして説明した。
【０１９２】
第２変形例では、第１統合部（統合部）２７が、上記（II’）において、読み出した複数の稼働状態に１つでも“pon_nodata”がある（電源ＯＮ状態）場合にも、アイドル判別処理を行なってよい。
【０１９３】
しかし、アイドル判別処理は、当該処理を行なう時間帯の動作データリスト２２ａ（稼働情報）を用いるが、“pon_nodata”の箇所（時間帯）ではそもそも稼働情報が欠如している。そこで、第２変形例に係る補完処理部２６は、動作データリスト２２ａに基づいて、図２３〜図２５に示す近似線を算出し、“pon_nodata”の箇所の稼働情報を推定（補完）することができる。なお、補完処理部２６による近似線の算出手法は、最小二乗法等の既知の種々の手法を用いることができるため、その詳細な説明は省略する。
【０１９４】
そして、補完処理部２６は、図３３に太枠で示すように、１０時台（図３３の（３）参照）のＶＭ１及びＶＭ３について、その前後少なくとも一方の時間帯の稼働情報に基づき、管理ＶＭ１５の障害によるデータ欠損箇所の補完を行なう。なお、図３３に破線で示すように、１０時台のＶＭ２については、動作判断部２５により判断不能と判断されているため、補完処理部２６は当該時間帯のデータ欠損箇所の補完を行なわなくてよい。
【０１９５】
第２変形例に係る第１統合部２７は、以上のようにして補完処理部２６により稼働情報が補完された動作データリスト２２ａを用いて、“pon_nodata”の時間帯のアイドル判別処理を行なうことができる。
【０１９６】
これにより、第１統合部２７は、図３４に示すように、図２９では処理実行中かアイドル状態かが不明である１０時台のＶＭ１及びＶＭ３の稼働状態について、ＶＭ１はアイドル状態であり、ＶＭ３は処理実行中であると判別することができる。
【０１９７】
なお、第２変形例に係る第１統合部２７は、“pon_nodata”の時間帯のアイドル判別処理を行なわずに、以下のようにして処理実行中かアイドル状態かを判定してもよい。例えば、第１統合部２７は、処理実行中かアイドル状態かが不明である時間帯の前後１時間の稼働状態に基づいて“pon_nodata”の時間帯の稼働状態を判別してもよい。なお、この場合、上述した第２変形例に係る補完処理部２６の機能は省略することができる。図３４の例では、第１統合部２７は、ＶＭ１の９時台及び１１時台がともにアイドル状態であるため、データ欠損した１０時台についてもアイドル状態と判別してよい。また、第１統合部２７は、ＶＭ３の９時台及び１１時台がともに処理実行中であるため、データ欠損した１０時台についても処理実行中と判別してよい。
【０１９８】
次に、図３５に示すフローチャートに従って、上述の如く構成された第２変形例に係る第１統合部２７の動作例（図３０のステップＳ９の詳細例）を説明する。なお、以下の説明において、既述の処理と同一又は略同一の処理についての重複した説明を省略する。
【０１９９】
図３５に示すように、第２変形例では、図３２に示すステップＳ６３が省略され、ステップＳ５９に代えて、ステップＳ６５の処理が実行される。ステップＳ５４において、読み込んだ複数の稼働状態に１つも“unknown”及び“pon_nodata”は無いが、１つでも“pon”がある場合（ステップＳ６１及びＳ６２のＮｏルート且つステップＳ５４のＹｅｓルート）、処理がステップＳ６５に移行する。
【０２００】
また、ステップＳ６２において、読み込んだ複数の稼働状態に１つも“unknown”は無いが、１つでも“pon_nodata”がある場合にも（ステップＳ６１のＮｏルート且つステップＳ６２のＹｅｓルート）、処理がステップＳ６５に移行する。ステップＳ６５では、第１統合部２７が、１時間分のデータのうち“pon_nodata”又は“pon”が存在するデータでアイドル判別処理を行ない、処理がステップＳ５６に移行する。
【０２０１】
なお、ステップＳ６５のアイドル判別処理では、基本的に、図２１に示すものと同様の処理が行なわれてよい。ただし、図２１のステップＳ７２では、第１統合部２７は、図３５のステップＳ６２又はＳ５４で“pon_nodata”又は“pon”と判断された稼働情報の各値を動作データリスト２２ａから取得する。そして、第１統合部２７が、取得した動作情報の各要素の値と対応する閾値とを比較する。
【０２０２】
以上のように、第２変形例によれば、第１変形例と同様の効果を奏することができるほか、１時間単位の動作実績レポート２１ｂに含まれる各ＶＭ１１の動作状態を、図３４に示すように、第１変形例よりも正確に判別することができる。
【０２０３】
〔５〕ハードウェア構成例
図３６に示すように、一実施形態並びに第１及び第２変形例に係る出力サーバ２は、ＣＰＵ２ａ，メモリ２ｂ，記憶部２ｃ，インタフェース部２ｄ，入出力部２ｅ，記録媒体２ｆ，及び読取部２ｇをそなえることができる。
【０２０４】
ＣＰＵ２ａは、種々の制御や演算を行なう演算処理装置（プロセッサ）の一例である。ＣＰＵ２ａは、対応する各ブロック２ｂ〜２ｇと接続され、メモリ２ｂ，記憶部２ｃ，記録媒体２ｆや２ｈ，又は図示しないＲＯＭ（Read Only Memory）等に格納されたプログラムを実行することにより、種々の機能を実現することができる。例えばＣＰＵ２ａは、メモリ２ｂに格納された出力プログラムを実行することにより、出力サーバ２の各ブロック２３〜３０（図６及び図２７参照）の機能を実現することができる。
【０２０５】
メモリ２ｂは、種々のデータやプログラムを格納する記憶装置である。ＣＰＵ２ａは、プログラムを実行する際に、メモリ２ｂにデータやプログラムを格納し展開する。メモリ２ｂは、上記出力プログラムを保存することができる。なお、メモリ２ｂとしては、例えばＲＡＭ（Random Access Memory）等の揮発性メモリが挙げられる。記憶部２ｃは、種々のデータやプログラム等を格納するハードウェアである。記憶部２ｃとしては、例えばＨＤＤ等の磁気ディスク装置，ＳＳＤ等の半導体ドライブ装置，フラッシュメモリ等の不揮発性メモリ等の各種装置が挙げられる。なお、図６及び図２７に示す記憶部２１及び保持部２２は、それぞれ記憶部２ｃ及びメモリ２ｂにより実現されてよい。
【０２０６】
インタフェース部２ｄは、有線又は無線による、ネットワーク（図示省略）や他の情報処理装置との間の接続及び通信の制御等を行なうものである。インタフェース部２ｄとしては、例えば、ＬＡＮ（Local Area Network），ファイバチャネル（Fibre Channel；ＦＣ），インフィニバンド（InfiniBand）等に準拠したアダプタが挙げられる。入出力部２ｅは、マウスやキーボード等の入力装置及びディスプレイやプリンタ等の出力装置の少なくとも一方を含むことができる。例えば、入力装置は管理者等による出力サーバ２への各種設定やデータの入力等の作業に用いられてよく、出力装置は出力サーバ２による動作状態や処理結果（動作実績レポート２１ｂ）等の出力に用いられてよい。
【０２０７】
記録媒体２ｆは、例えばフラッシュメモリやＲＯＭ等の記憶装置であり、種々のデータやプログラムを記録することができる。読取部２ｇは、コンピュータ読取可能な記録媒体２ｈに記録されたデータやプログラムを読み出す装置である。記録媒体２ｆ及び２ｈの少なくとも一方には、本実施形態に係る出力サーバ２の各種機能の全部もしくは一部を実現する出力プログラムが格納されてもよい。例えば、ＣＰＵ２ａは、記録媒体２ｆから読み出した出力プログラム、又は、読取部２ｇを介して記録媒体２ｈから読み出した出力プログラムを、メモリ２ｂ等の記憶装置に展開して実行してもよい。
【０２０８】
なお、記録媒体２ｈとしては、例えばフレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク等の光ディスクや、ＵＳＢ（Universal Serial Bus）メモリやＳＤカード等のフラッシュメモリが挙げられる。なお、ＣＤとしては、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（CD-Recordable）、ＣＤ−ＲＷ（CD-Rewritable）等が挙げられる。また、ＤＶＤとしては、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等が挙げられる。
【０２０９】
上述した各ブロック２ａ〜２ｇ間はバスで相互に通信可能に接続される。また、出力サーバ２の上述したハードウェア構成は例示である。従って、出力サーバ２内でのハードウェアの増減（例えば任意のブロックの追加や省略），分割，任意の組み合わせでの統合，バスの追加又は省略等は適宜行なわれてもよい。
【０２１０】
〔６〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
【０２１１】
例えば、図６及び図２７に示す出力サーバ２の各機能ブロックは、任意の組み合わせで併合してもよく、分割してもよい。
【０２１２】
また、一実施形態に係る出力サーバ２は、第１統合部２７による第１統合リスト２２ｃを、利用者に提供すべく出力してもよい。同様に、第１又は第２変形例に係る出力サーバ２は、補完処理部２６による補完された動作データリスト２２ａ又は動作判別リスト２２ｂを利用者に提供すべく出力してもよい。
【０２１３】
一実施形態並びに第１及び第２変形例では、動作実績レポート２１ｂはＷｅｂサーバ４におけるＷｅｂサイト上で提供されるものとして説明したが、動作実績レポート２１ｂの利用者への提供手法は、上述したものに限定されるものではない。例えば、出力サーバ２がＶＭ管理情報３１ａとして利用者のメールアドレスを取得し、メールに動作実績レポート２１ｂの内容を記載して利用者へ送信してもよい。また、長期的にアイドル状態（例えば７日以上或いは所定時間以上連続してアイドル状態）であったＶＭ１１について、利用者がＶＭ１１の電源ＯＮ制御又は電源ＯＦＦ制御を実行するタイミングで、出力サーバ２がポップアップ等により動作実績のレポートを利用者に通知してもよい。
【０２１４】
また、一実施形態では月次で、第１及び第２変形例では１時間ごとに、動作データ１９ａを集計した結果を利用者に提示するものとして説明したが、これに限定されるものではない。動作実績のレポートを提供するタイミングとしては、出力サーバ２が稼働状態の判別を実行した直後に行なうこともできる。例えば、管理ＶＭ１５の稼働情報収集部１８が取得する動作データ１９ａは１０分単位で更新されているため、出力サーバ２は、毎日又は１時間（若しくは数時間）ごとに新しくなった動作データ１９ａを採取して稼働状態の判別を実行し、判別結果が得られた段階で利用者へ通知してもよい。これにより、前日又は１時間（若しくは数時間）前の判別結果も含めた、現状により近い動作実績レポート２１ｂを利用者に提供することが可能となる。
【０２１５】
さらに、一実施形態では、動作実績レポート２１ｂの集計する範囲（期間）を月次として説明したが、利用者の要望等によって月次集計ではなく週次，日次といった期間で動作状況の提供を行なってもよい。その際、第１統合部２７及び第２統合部２８の機能は、上述した第１及び第２変形例に基づき、適宜組み合わせ又は省略してもよい。
【０２１６】
〔７〕付記
以上の実施形態に関し、更に以下の付記を開示する。
【０２１７】
（付記１）
コンピュータに、
情報処理装置上で動作する仮想マシンの所定の期間における動作状況に関する動作情報を、前記動作情報の取得と前記仮想マシンの起動制御とを行なう管理マシンを通じて取得し、
前記所定の期間に前記仮想マシンの動作情報の取得されなかった第１の期間が含まれる場合、前記第１の期間における前記管理マシンの動作情報と、前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報とに基づく、前記第１の期間における前記仮想マシンの動作実績を出力する、
処理を実行させることを特徴とする、出力プログラム。
【０２１８】
（付記２）
前記第１の期間に前記管理マシンの動作情報が取得されなかった第２の期間が含まれる場合、前記第１の期間のうちの前記第２の期間に含まれない期間における前記仮想マシンの動作状態を停止状態と推定する、
処理を前記コンピュータに実行させることを特徴とする、付記１記載の出力プログラム。
【０２１９】
（付記３）
前記管理マシンの動作情報が取得されなかった第２の期間における前記仮想マシンの動作状態を、前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報に基づいて推定する、
処理を前記コンピュータに実行させることを特徴とする、付記１又は付記２記載の出力プログラム。
【０２２０】
（付記４）
前記第２の期間における前記仮想マシンの動作状態が起動状態と推定された場合、前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報に基づいて、前記第２の期間における前記仮想マシンの動作状態を処理実行状態及びアイドル状態のいずれから判別する、
処理を前記コンピュータに実行させることを特徴とする、付記３記載の出力プログラム。
【０２２１】
（付記５）
前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報が閾値を下回っていた時間に基づき、前記仮想マシンの動作状態を処理実行状態及びアイドル状態のいずれから判別する、
処理を前記コンピュータに実行させることを特徴とする、付記４記載の出力プログラム。
【０２２２】
（付記６）
前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報に基づき、前記所定の期間のうちの前記第１の期間の前記第１の期間の前後少なくとも一方の期間における前記仮想マシンの動作状態を判別し、
判別した動作状態と、推定された前記第１の期間における前記仮想マシンの動作状態とに基づいて、前記所定の期間における前記仮想マシンの動作状態を推定し、
推定した動作状態を前記第１の期間を含む前記所定の期間における前記仮想マシンの動作実績に含めて出力する、
処理を前記コンピュータに実行させることを特徴とする、付記１〜５のいずれか１項記載の出力プログラム。
【０２２３】
（付記７）
情報処理装置上で動作する仮想マシンの所定の期間における動作状況に関する動作情報を、前記動作情報の取得と前記仮想マシンの起動制御とを行なう管理マシンを通じて取得する取得部と、
前記所定の期間に前記仮想マシンの動作情報の取得されなかった第１の期間が含まれる場合、前記第１の期間における前記管理マシンの動作情報と、前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報とに基づき、前記第１の期間における前記仮想マシンの動作実績を推定する推定部と、
推定した前記第１の期間における前記仮想マシンの動作実績を出力する出力部と、をそなえる
ことを特徴とする、出力装置。
【０２２４】
（付記８）
前記推定部は、前記第１の期間に前記管理マシンの動作情報が取得されなかった第２の期間が含まれる場合、前記第１の期間のうちの前記第２の期間に含まれない期間における前記仮想マシンの動作状態を停止状態と推定する、
ことを特徴とする、付記７記載の出力装置。
【０２２５】
（付記９）
前記推定部は、前記管理マシンの動作情報が取得されなかった第２の期間における前記仮想マシンの動作状態を、前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報に基づいて推定する、
ことを特徴とする、付記７又は付記８記載の出力装置。
【０２２６】
（付記１０）
前記推定部は、前記第２の期間における前記仮想マシンの動作状態が起動状態と推定した場合、前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報に基づいて、前記第２の期間における前記仮想マシンの動作状態を処理実行状態及びアイドル状態のいずれから判別する、
ことを特徴とする、付記９記載の出力装置。
【０２２７】
（付記１１）
前記推定部は、前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報が閾値を下回っていた時間に基づき、前記仮想マシンの動作状態を処理実行状態及びアイドル状態のいずれから判別する
ことを特徴とする、付記１０記載の出力装置。
【０２２８】
（付記１２）
前記推定部は、
前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報に基づき、前記所定の期間のうちの前記第１の期間の前記第１の期間の前後少なくとも一方の期間における前記仮想マシンの動作状態を判別し、
判別した動作状態と、推定された前記第１の期間における前記仮想マシンの動作状態とに基づいて、前記所定の期間における前記仮想マシンの動作状態を推定し、
前記出力部は、
推定した動作状態を前記第１の期間を含む前記所定の期間における前記仮想マシンの動作実績に含めて出力する、
ことを特徴とする、付記７〜１１のいずれか１項記載の出力装置。
【０２２９】
（付記１３）
情報処理装置上で動作する仮想マシンの所定の期間における動作状況に関する動作情報を、前記動作情報の取得と前記仮想マシンの起動制御とを行なう管理マシンを通じて取得し、
前記所定の期間に前記仮想マシンの動作情報の取得されなかった第１の期間が含まれる場合、前記第１の期間における前記管理マシンの動作情報と、前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報とに基づく、前記第１の期間における前記仮想マシンの動作実績を出力する、
ことを特徴とする、出力方法。
【０２３０】
（付記１４）
前記第１の期間に前記管理マシンの動作情報が取得されなかった第２の期間が含まれる場合、前記第１の期間のうちの前記第２の期間に含まれない期間における前記仮想マシンの動作状態を停止状態と推定する、
ことを特徴とする、付記１３記載の出力方法。
【０２３１】
（付記１５）
前記管理マシンの動作情報が取得されなかった第２の期間における前記仮想マシンの動作状態を、前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報に基づいて推定する、
ことを特徴とする、付記１３又は付記１４記載の出力方法。
【０２３２】
（付記１６）
前記第２の期間における前記仮想マシンの動作状態が起動状態と推定された場合、前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報に基づいて、前記第２の期間における前記仮想マシンの動作状態を処理実行状態及びアイドル状態のいずれから判別する、
ことを特徴とする、付記１５記載の出力方法。
【０２３３】
（付記１７）
前記第２の期間の前後少なくとも一方において取得された前記仮想マシンの動作情報が閾値を下回っていた時間に基づき、前記仮想マシンの動作状態を処理実行状態及びアイドル状態のいずれから判別する、
ことを特徴とする、付記１６記載の出力方法。
【０２３４】
（付記１８）
前記第１の期間の前後少なくとも一方において取得されている前記仮想マシンの動作情報に基づき、前記所定の期間のうちの前記第１の期間の前記第１の期間の前後少なくとも一方の期間における前記仮想マシンの動作状態を判別し、
判別した動作状態と、推定された前記第１の期間における前記仮想マシンの動作状態とに基づいて、前記所定の期間における前記仮想マシンの動作状態を推定し、
推定した動作状態を前記第１の期間を含む前記所定の期間における前記仮想マシンの動作実績に含めて出力する、
ことを特徴とする、付記１３〜１７のいずれか１項記載の出力方法。
【符号の説明】
【０２３５】
１    ハードウェア資源
１−１〜１−ｍ    サーバ（情報処理装置）
２    出力サーバ（出力装置）
３    ＶＭ管理情報格納サーバ
４    Ｗｅｂサーバ
５    ネットワーク
６−１〜６−ｉ    端末
１１，１１−１〜１１−ｎ    ＶＭ（仮想マシン）
１２，１６    仮想ＯＳ
１３    ミドルウェア
１４    アプリケーション
１５    管理ＶＭ（管理マシン）
１７    電源操作部
１８    稼働情報収集部
１９，２１，３１，４１    記憶部
２２    保持部
２３    動作データ取得部
２４    動作データリスト作成部
２５    動作判別部
２６    補完処理部
２７    第１統合部
２８    第２統合部
２９    ＶＭ管理情報追加部
３０    レポート転送部
【図１】
0006303857.tif 000002
【図２】
0006303857.tif 000003
【図３】
0006303857.tif 000004
【図４】
0006303857.tif 000005
【図５】
0006303857.tif 000006
【図６】
0006303857.tif 000007
【図７】
0006303857.tif 000008
【図８】
0006303857.tif 000009
【図９】
0006303857.tif 000010
【図１０】
0006303857.tif 000011
【図１１】
0006303857.tif 000012
【図１２】
0006303857.tif 000013
【図１３】
0006303857.tif 000014
【図１４】
0006303857.tif 000015
【図１５】
0006303857.tif 000016
【図１６】
0006303857.tif 000017
【図１７】
0006303857.tif 000018
【図１８】
0006303857.tif 000019
【図１９】
0006303857.tif 000020
【図２０】
0006303857.tif 000021
【図２１】
0006303857.tif 000022
【図２２】
0006303857.tif 000023
【図２３】
0006303857.tif 000024
【図２４】
0006303857.tif 000025
【図２５】
0006303857.tif 000026
【図２６】
0006303857.tif 000027
【図２７】
0006303857.tif 000028
【図２８】
0006303857.tif 000029
【図２９】
0006303857.tif 000030
【図３０】
0006303857.tif 000031
【図３１】
0006303857.tif 000032
【図３２】
0006303857.tif 000033
【図３３】
0006303857.tif 000034
【図３４】
0006303857.tif 000035
【図３５】
0006303857.tif 000036
【図３６】
0006303857.tif 000037