JP6213053B2 - プログラム、情報処理装置およびスケジュール決定方法 - Google Patents

Description

本発明はプログラム、情報処理装置およびスケジュール決定方法に関する。

情報処理の分野では、物理的なコンピュータ（物理マシンや物理ホストと呼ぶことがある）上で、複数の仮想的なコンピュータ（仮想マシンや論理ホストと呼ぶことがある）を動作させる仮想化技術が利用されている。各仮想マシン上では、ＯＳ（Operating System）などのソフトウェアを実行できる。仮想化技術を利用する物理マシンは、複数の仮想マシンを管理するためのソフトウェアを実行する。例えば、ハイパーバイザと呼ばれるソフトウェアが、ＣＰＵ（Central Processing Unit）の処理能力やＲＡＭ（Random Access Memory）の記憶領域を、演算のリソースとして複数の仮想マシンに割り振ることがある。

ソフトウェアに対して更新プログラム（パッチと呼ばれることもある）が提供されることがある。例えば、更新プログラムは、セキュリティの問題を解消するためのプログラムや機能を追加するためのプログラムなどを含む。

例えば、パッチの適用対象マシンに対するパッチ適用を管理するシステムの提案がある。この提案では、適用パッチが緊急に適用すべきものであった場合には、すぐに当該パッチを適用するように適用時期を決定する。パッチが緊急に適用しなくてよく、かつ、適用対象マシンの負荷状況が高い場合は、所定時間後に当該パッチを適用するように適用時期を決定する。

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

物理マシン上の複数の仮想マシンに対して複数の更新プログラムを適用することがある。その場合、複数の仮想マシンに対する更新プログラムの適用を並列に行うことで、適用を迅速に完了させることが考えられる。例えば、通常業務などへの影響の小さい所定の時間帯の中で更新プログラムの適用を完了させたいということがあるからである。

一方、更新プログラムを適用するために物理マシンのリソースを利用することになる。更新プログラムを複数の仮想マシンに並列に適用すると物理マシンの負荷が増大し得る。すると、更新プログラムの適用以外の他の処理（例えば、更新プログラムの適用対象でない仮想マシン上の処理）に利用可能なリソースが低減する。このため、他の処理に遅延などの悪影響を及ぼすおそれがある。そこで、他の処理への影響を考慮して、複数の更新プログラムを適用するためのスケジュールをどのように効率的に決定するかが問題となる。

一側面によれば、本発明は、更新プログラムの適用順序を効率的に決定できるプログラム、情報処理装置およびスケジュール決定方法を提供することを目的とする。

一実施態様によれば、第１の仮想マシンおよび第２の仮想マシンが動作可能な情報処理装置と通信するコンピュータによって実行されるプログラムが提供される。このプログラムは、コンピュータに、更新プログラムを第１の仮想マシンに適用するときの情報処理装置の負荷を示す第１の情報と更新プログラムを第２の仮想マシンに適用するときの情報処理装置の負荷を示す第２の情報とを、複数の更新プログラムそれぞれに対して取得し、第１の情報と第２の情報と情報処理装置で許容される負荷の上限とに基づいて、所定期間内に複数の更新プログラムを第１の仮想マシンに適用するときの第１の適用順序と、所定期間内に複数の更新プログラムを第２の仮想マシンに適用するときの第２の適用順序であって、第１の適用順序とは異なる第２の適用順序とを決定する、処理を実行させる。

また、一実施態様によれば、第１の仮想マシンおよび第２の仮想マシンが動作可能な他の情報処理装置と通信する情報処理装置が提供される。この情報処理装置は、記憶部と演算部とを有する。記憶部は、更新プログラムを第１の仮想マシンに適用するときの他の情報処理装置の負荷を示す第１の情報と更新プログラムを第２の仮想マシンに適用するときの他の情報処理装置の負荷を示す第２の情報とを、複数の更新プログラムそれぞれに対して記憶する。演算部は、記憶部から第１の情報と第２の情報とを取得し、第１の情報と第２の情報と他の情報処理装置で許容される負荷の上限とに基づいて、所定期間内に複数の更新プログラムを第１の仮想マシンに適用するときの第１の適用順序と、所定期間内に複数の更新プログラムを第２の仮想マシンに適用するときの第２の適用順序であって、第１の適用順序とは異なる第２の適用順序とを決定する。

また、一実施態様によれば、第１の仮想マシンおよび第２の仮想マシンが動作可能な情報処理装置と通信するコンピュータで実行されるスケジュール決定方法が提供される。このスケジュール決定方法では、コンピュータが、更新プログラムを第１の仮想マシンに適用するときの情報処理装置の負荷を示す第１の情報と更新プログラムを第２の仮想マシンに適用するときの情報処理装置の負荷を示す第２の情報とを、複数の更新プログラムそれぞれに対して取得し、第１の情報と第２の情報と情報処理装置で許容される負荷の上限とに基づいて、所定期間内に複数の更新プログラムを第１の仮想マシンに適用するときの第１の適用順序と、所定期間内に複数の更新プログラムを第２の仮想マシンに適用するときの第２の適用順序であって、第１の適用順序とは異なる第２の適用順序とを決定する。

一実施態様によれば、更新プログラムの適用順序を効率的に決定できる。

第１の実施の形態の情報処理システムを示す図である。 第２の実施の形態の情報処理システムを示す図である。 第２の実施の形態の管理サーバのハードウェア例を示す図である。 第２の実施の形態のソフトウェア例を示す図である。 第２の実施の形態の仮想マシン管理テーブルの例を示す図である。 第２の実施の形態のパッチ管理テーブルの例を示す図である。 第２の実施の形態のスケジュールテーブルの例（その１）を示す図である。 第２の実施の形態のスケジュールテーブルの例（その２）を示す図である。 第２の実施の形態の処理を示すフローチャートである。 第２の実施の形態の検証処理を示すフローチャートである。 第２の実施の形態のスケジューリングを示すフローチャートである。 第２の実施の形態のパッチ適用順序の設定を示すフローチャートである。 第２の実施の形態のパッチ適用順序の設定例を示す図である。 第２の実施の形態のパッチ適用順序の調整を示すフローチャートである。 第２の実施の形態のスケジュールの組み替え例を示す図である。 第２の実施の形態のスケジュールの組み替え例（続き）を示す図である。 第２の実施の形態のパッチグループの調整を示すフローチャートである。 第２の実施の形態のパッチグループの調整例を示す図である。 第２の実施の形態のパッチグループの調整例（続き）を示す図である。 第２の実施の形態の確定されたスケジュールの例を示す図である。 第２の実施の形態のスケジュールの補正例を示すフローチャートである。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理システムを示す図である。第１の実施の形態の情報処理システムは、情報処理装置１，２を含む。情報処理装置１は、情報処理装置２で動作する複数の仮想マシンに対する更新プログラムの適用状況を管理する。情報処理装置２は、複数の仮想マシンが動作可能である。当該複数の仮想マシンは仮想マシン２ａ，２ｂを含む。例えば、情報処理装置２で実行されるハイパーバイザが、情報処理装置２が有するＣＰＵやメモリなどのリソースを仮想マシン２ａ，２ｂに割当てる。仮想マシン２ａ，２ｂは、割当てられたリソースを演算のリソースとして利用可能である。

情報処理装置１は、記憶部１ａおよび演算部１ｂを有する。記憶部１ａは、例えばＲＡＭなどのメモリである。演算部１ｂは、例えばＣＰＵなどのプロセッサである。例えば、第１の実施の形態の情報処理は、演算部１ｂが記憶部１ａに記憶されたプログラムを実行することで実現できる。

記憶部１ａは、複数の更新プログラムそれぞれを仮想マシン２ａ，２ｂそれぞれに適用するときの情報処理装置２の負荷を示す負荷情報を記憶する。記憶部１ａは、複数の更新プログラムそれぞれを仮想マシン２ａ，２ｂに適用するための所要時間を示す情報を記憶してもよい。

例えば、情報処理装置１と通信可能な検証用の情報処理装置を設ける。そして、検証用の情報処理装置上で検証用の仮想マシンを動作させる。例えば、情報処理装置１は、検証用の仮想マシンに対して各更新プログラムを個別に適用させることで、各更新プログラムを適用するときの検証用の情報処理装置の負荷を示す情報や各更新プログラムの適用のための所要時間を事前に取得しておくことができる。例えば、検証用の情報処理装置に情報処理装置２と同等のリソースを設けておき、検証用の仮想マシンに仮想マシン２ａ，２ｂと同等のリソースを割当可能としておく。そうすれば、検証用の情報処理装置を用いて取得した負荷や所要時間の情報を、情報処理装置２で仮想マシン２ａ，２ｂそれぞれに同じパッチを適用したときの情報として扱える。

演算部１ｂは、複数の更新プログラムそれぞれを適用するときの情報処理装置２の負荷を示す負荷情報を記憶部１ａから取得し、複数の更新プログラムそれぞれについて、仮想マシン２ａあるいは仮想マシン２ｂに適用するときの情報処理装置２の負荷を算定する。例えば、演算部１ｂは、記憶部１ａに記憶された情報を参照して、複数の更新プログラムの少なくとも何れかを仮想マシン２ａ，２ｂに同じタイミングで並列に適用するときの情報処理装置２の負荷を評価する。演算部１ｂは、評価された負荷と情報処理装置２で許容される負荷の上限との比較結果に基づいて、複数の更新プログラムを複数の仮想マシンに適用するためのスケジュール（適用順序）を決定する。ここで、仮想マシン２ａ，２ｂに対して更新プログラムの適用を開始できる時間は、予め定められている。例えば、仮想マシン２ａ，２ｂの負荷が比較的低い時間帯を、更新プログラムを適用するための時間帯として利用することが考えられる。また、情報処理装置２で許容される負荷の上限とは、情報処理装置２において更新プログラムの適用のために許容される負荷の上限を意味する。

例えば、複数の更新プログラムは更新プログラムａ，ｂ，ｃ，ｄ，ｅ，ｆを含む。更新プログラムａ，ｂ，ｃ，ｄ，ｅ，ｆの適用順序は、デフォルトではこの順番である。更新プログラムのデフォルトの適用順序は、提供された日時や更新プログラムごとの所定の優先度などに応じて決めることができる。例えば、提供された日時が早いものから先に適用するような順序でもよい。また、例えば、重要度の高いものほど優先度を高く設定し、優先度の高いものから先に適用するような順序でもよい。また、例えば、適用するときの負荷が大きくなるものほど優先度を高く設定し、優先度の高いものから先に適用するような順序でもよい。

例えば、更新プログラムａ，ｂ，ｃ，ｄ，ｅ，ｆの適用順序を決定するとき、演算部１ｂは次のような手順を実行する。演算部１ｂは、記憶部１ａに記憶された情報に基づいて、時間に応じた仮想マシン２ａ，２ｂの負荷の遷移を得る（ステップＳ１）。

棒グラフ３は、更新プログラムａ，ｂ，ｃ，ｄ，ｅ，ｆをこの順序で仮想マシン２ａに適用する場合の情報処理装置２の負荷の遷移を示す。棒グラフ４は、同じ順序で仮想マシン２ｂに適用する場合の情報処理装置２の負荷の遷移を示す。棒グラフ３，４の横軸は時間、縦軸は負荷である。バー（Bar）３ａ，４ａは更新プログラムａを適用するときの情報処理装置２の負荷を示す。負荷は、適用開始から完了までの所要時間で平均化されたものである（以下、同様）。あるいは、適用中に検出された負荷のうちで最高のものを当該パッチ適用時の負荷として採用してもよい。バー３ｂ，４ｂは更新プログラムｂを適用するときの負荷を示す。バー３ｃ，４ｃは更新プログラムｃを適用するときの負荷を示す。バー３ｄ，４ｄは更新プログラムｄを適用するときの負荷を示す。バー３ｅ，４ｅは更新プログラムｅを適用するときの負荷を示す。バー３ｆ，４ｆは更新プログラムｆを適用するときの負荷を示す。

演算部１ｂは、棒グラフ３で示される負荷と棒グラフ４で示される負荷とを積算する（ステップＳ２）。これは、仮想マシン２ａ，２ｂに対して同じタイミングで並列に何れかの更新プログラムを適用したときの情報処理装置２の負荷を評価することに相当する。

演算部１ｂは、情報処理装置２で許容される負荷の上限Ｌ０と、評価された負荷との比較結果に基づいて、仮想マシン２ａ，２ｂに対する更新プログラムａ，ｂ，ｃ，ｄ，ｅ，ｆの適用順序を変更する（ステップＳ３）。例えば、負荷の上限Ｌ０は、情報処理装置２において業務処理などを実行するためのリソースが確保されるように決定することが考えられる。例えば、演算部１ｂは仮想マシン２ａに対する更新プログラムの適用順序を基準にして、仮想マシン２ｂに対する更新プログラムの適用順序を変更する。より具体的には、更新プログラムの適用に伴う仮想マシン２ａ，２ｂの各タイミングの負荷が、負荷の上限Ｌ０よりも大きくならないように、更新プログラムａ，ｂ，ｃ，ｄ，ｅ，ｆの適用順序を組み替える。

その結果、演算部１ｂは仮想マシン２ａに対する適用順序として更新プログラムａ，ｂ，ｃ，ｄ，ｅ，ｆを得る。演算部１ｂは仮想マシン２ｂに対する適用順序として更新プログラムｅ，ｆ，ｃ，ａ，ｄ，ｂを得る（ステップＳ４）。棒グラフ５は、仮想マシン２ｂに対して更新プログラムｅ，ｆ，ｃ，ａ，ｄ，ｂの順序で適用したときの情報処理装置２の負荷の遷移を示す。

情報処理装置１によれば、演算部１ｂにより、更新プログラムａ，ｂ，ｃ，ｄ，ｅ，ｆそれぞれを仮想マシン２ａ，２ｂそれぞれに適用するときの情報処理装置２の負荷を示す負荷情報が取得される。演算部１ｂにより、負荷情報と情報処理装置２で許容される負荷の上限Ｌ０とに基づいて、所定期間内に更新プログラムａ，ｂ，ｃ，ｄ，ｅ，ｆを仮想マシンに適用するときの適用順序が、仮想マシン２ａ，２ｂそれぞれについて決定される。

これにより、更新プログラムの適用順序を効率的に決定できる。具体的には次の通りである。例えば、更新プログラムａ，ｂ，ｃ，ｄ，ｅ，ｆの中には、適用時の情報処理装置２の負荷が比較的高くなるもの（例えば、棒グラフ３，４によれば更新プログラムｂの適用処理は負荷が最大である）もある。適用時の負荷が高くなる更新プログラム同士を同じタイミングで並列に仮想マシン２ａ，２ｂに適用すると、情報処理装置２の負荷が増大し得る。すると、情報処理装置２で実行される他の処理（例えば、仮想マシン２ａ，２ｂや仮想マシン２ａ，２ｂ以外の他の仮想マシンの業務処理）で利用できるリソースが低減し、当該他の処理に遅延などの悪影響を及ぼすおそれがある。

そこで、各更新プログラム適用時の情報処理装置２の負荷を示す情報に基づいて、更新プログラムの組を仮想マシン２ａ，２ｂに並列に適用する時の情報処理装置２の負荷を事前に評価する。評価された負荷と情報処理装置２で更新プログラムの適用のために許容される負荷の上限との比較結果に基づいて適用順序を決定する。

例えば、評価された負荷が上限以下である場合は、対応する更新プログラムの組の並列適用を許容する。より具体的には、仮想マシン２ａ，２ｂに対して更新プログラムａ，ｅの組を並列に適用しても、情報処理装置２の負荷は上限Ｌ０以下である（バー３ａ，４ｅを積み上げても負荷は上限Ｌ０以下である）。よって、仮想マシン２ａ，２ｂに対して更新プログラムａ，ｅの組を並列に適用することは許容される。また、評価された負荷が上限を超える場合は、対応する更新プログラムの組の並列適用を許容しない。より具体的には、仮想マシン２ａ，２ｂに対して更新プログラムａ，ａの組を並列に適用すると、情報処理装置２の負荷は上限Ｌ０より大きくなる（バー３ａ，４ａを積み上げると負荷は上限Ｌ０を超える）。よって、仮想マシン２ａ，２ｂに対して更新プログラムａ，ａの組を並列に適用することは許容されない。このようにして、情報処理装置２で所定のリソースを確保するように、更新プログラムの適用順序を効率的に決定することができる。

［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、管理サーバ１００、実行サーバ２００、検証サーバ３００および配信サーバ４００を有する。第２の実施の形態の情報処理システムは、例えば、実行サーバ２００で実行される仮想マシンを、ユーザにより利用可能とするシステムである。

管理サーバ１００、実行サーバ２００および検証サーバ３００は、ネットワーク１０を介して接続されている。配信サーバ４００は、ネットワーク２０に接続されている。ネットワーク１０，２０はネットワーク間の通信を中継する中継装置（図示を省略）を介して接続されている。例えば、ネットワーク１０はＬＡＮ（Local Area Network）である。例えば、ネットワーク２０はインターネットやＷＡＮ（Wide Area Network）などの広域ネットワークである。

管理サーバ１００は、実行サーバ２００で実行される仮想マシン上のＯＳやアプリケーションのソフトウェアに対して提供される更新プログラム（以下、パッチと称することがある）の適用を管理するサーバコンピュータである。

実行サーバ２００は、複数の仮想マシンが動作可能なサーバコンピュータである。ネットワーク１０（または、ネットワーク２０）に接続されたクライアントコンピュータ（図示を省略）から仮想マシンにアクセス可能である。仮想マシンは、クライアントコンピュータからのリクエストに応じて、ユーザの業務に応じた処理を実行する。

検証サーバ３００は、実行サーバ２００上の各仮想マシンにパッチを適用する前に、当該パッチに関する情報を取得するためのサーバコンピュータである。検証サーバ３００でも、仮想マシンを動作させる。検証サーバ３００は、管理サーバ１００の指示に基づいて、当該仮想マシンにパッチを適用する。検証サーバ３００は、パッチ適用時の負荷やパッチ適用の所要時間などの情報を取得する。

図３は、第２の実施の形態の管理サーバのハードウェア例を示す図である。管理サーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ（Hard Disk Drive）１０３、通信部１０４、画像信号処理部１０５、入力信号処理部１０６、ディスクドライブ１０７および機器接続部１０８を有する。各ユニットが管理サーバ１００のバスに接続されている。実行サーバ２００、検証サーバ３００および配信サーバ４００も管理サーバ１００と同様のユニットを用いて実現できる。

プロセッサ１０１は、管理サーバ１００の情報処理を制御する。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）またはＰＬＤ（Programmable Logic Device）などである。プロセッサ１０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、管理サーバ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１の処理に用いられる各種データを記憶する。

ＨＤＤ１０３は、管理サーバ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。管理サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。

通信部１０４は、ネットワーク１０を介して他のコンピュータと通信を行えるインタフェースである。通信部１０４は、有線インタフェースでもよいし、無線インタフェースでもよい。

画像信号処理部１０５は、プロセッサ１０１からの命令に従って、管理サーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。

入力信号処理部１０６は、管理サーバ１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。

ディスクドライブ１０７は、レーザ光などを利用して、光ディスク１３に記録されたプログラムやデータを読み取る駆動装置である。光ディスク１３として、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などを使用できる。ディスクドライブ１０７は、例えば、プロセッサ１０１からの命令に従って、光ディスク１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

機器接続部１０８は、管理サーバ１００に周辺機器を接続するための通信インタフェースである。例えば、機器接続部１０８にはメモリ装置１４やリーダライタ装置１５を接続できる。メモリ装置１４は、機器接続部１０８との通信機能を搭載した記録媒体である。リーダライタ装置１５は、メモリカード１６へのデータの書き込み、またはメモリカード１６からのデータの読み出しを行う装置である。メモリカード１６は、カード型の記録媒体である。機器接続部１０８は、例えば、プロセッサ１０１からの命令に従って、メモリ装置１４またはメモリカード１６から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

図４は、第２の実施の形態のソフトウェア例を示す図である。図４に示す各ユニットの一部または全部は、管理サーバ１００、実行サーバ２００および検証サーバ３００が備えるプロセッサが実行するプログラムのモジュールであってもよい。また、図４に示す各ユニットの一部または全部は、管理サーバ１００、実行サーバ２００および検証サーバ３００が備えるＦＰＧＡやＡＳＩＣなどの電子回路であってもよい。

管理サーバ１００は記憶部１１０、パッチ収集部１２０および制御部１３０を有する。
記憶部１１０は、パッチ収集部１２０により収集されたパッチを記憶する。記憶部１１０は、パッチに関する情報（パッチ適用時における実行サーバ２００の負荷やパッチ適用の所要時間など）を記憶する。記憶部１１０は、仮想マシンに対するパッチ適用のスケジュールを示す情報を記憶する。記憶部１１０は、パッチ適用対象の仮想マシンごとにスケジュールを示す情報を記憶する。記憶部１１０は、ＲＡＭ１０２やＨＤＤ１０３の記憶領域を用いて実装できる。記憶部１１０は、第１の実施の形態の記憶部１ａの一例である。

パッチ収集部１２０は、配信サーバ４００により配信されるパッチを収集する。例えば、パッチ収集部１２０は、配信サーバ４００が新たなパッチの配信を開始すると、当該新たなパッチを収集して記憶部１１０に格納する。パッチ収集部１２０は、配信サーバ４００を含む複数の配信サーバからパッチを収集してもよい。

制御部１３０は、記憶部１１０に記憶された各パッチの仮想マシンへの適用を検証サーバ３００に事前に実行させ、パッチに関する情報を取得させる。制御部１３０は検証サーバ３００からパッチに関する情報を取得し、記憶部１１０に格納する。制御部１３０は、記憶部１１０に記憶されたパッチに関する情報に基づいて、実行サーバ２００上の仮想マシンに対するパッチ適用のスケジュールを示す情報を生成する。制御部１３０は、当該スケジュールに基づいて、記憶部１１０に記憶された各パッチを、各仮想マシンに適用するように実行サーバ２００に指示する。制御部１３０は、実行サーバ２００に対するパッチの適用状況を示す情報を取得し、記憶部１１０に格納する。

なお、各仮想マシンに対するパッチの適用は、例えば所定の周期（例えば、１日、１週間、１ヶ月など）で行われる。制御部１３０は、パッチ適用の開始時点よりも前に検証サーバ３００を用いてパッチに関する情報を取得し、パッチ適用のスケジュールを作成しておくことになる。

実行サーバ２００は実行部２１０および仮想マシン２２０，２３０，２４０，２５０を有する。
実行部２１０は、制御部１３０の指示に基づいて、仮想マシン２２０，２３０，２４０，２５０に対するパッチの適用を実行する。実行部２１０は、パッチの適用状況（パッチごとの適用の完了など）を制御部１３０に通知する。

ここで、以下の説明においては、あるタイミングにおいて個々の仮想マシンに適用されるパッチの数は１つであるものとする。例えば、仮想マシン２２０に第１のパッチが適用されているとき、当該仮想マシン２２０に対して第２のパッチが同時に適用されることはないものとする（他の仮想マシンでも同様）。複数のパッチによって仮想マシン２２０のＯＳなどに関わる同一の情報を更新することも考えられ、そのような場合に適用処理で競合が発生してしまうのを避けるためである。

一方、仮想マシン２２０に第１のパッチを適用しているときに、仮想マシン２３０に第２のパッチを並列に適用するというように、別個の仮想マシンに対してはパッチを並列に適用できる。上述のような競合が生ずるおそれがないからである。

仮想マシン２２０，２３０，２４０，２５０は、実行サーバ２００上で動作する仮想的なコンピュータである。例えば、実行サーバ２００はハイパーバイザ（図示を省略）を実行する。ハイパーバイザは、仮想マシン２２０，２３０，２４０，２５０に対して、実行サーバ２００が備えるＣＰＵやＲＡＭのリソースを仮想マシン２２０，２３０，２４０，２５０に割り振る。仮想マシン２２０，２３０，２４０，２５０には次のようにＩＤ（IDentifier）が設定されているものとする。仮想マシン２２０のＩＤは“ＶＭ（Virtual Machine）１”である。仮想マシン２３０のＩＤは“ＶＭ２”である。仮想マシン２４０のＩＤは“ＶＭ３”である。仮想マシン２５０のＩＤは“ＶＭ４”である。

ここで、仮想マシン２５０には、仮想マシン２２０，２３０，２４０と同じ時間帯にはパッチ適用を行わないものとする。当該時間帯において、仮想マシン２５０の負荷が他の業務処理によって増大する可能性が高いからである。以下の説明では、専ら仮想マシン２２０，２３０，２４０にパッチ適用を行う場合を例示する。このため、仮想マシン２５０をパッチの適用対象外の仮想マシンとして扱う。なお、仮想マシン２５０のようなパッチの適用対象外の仮想マシンは複数存在していてもよい。

検証サーバ３００は検証部３１０および仮想マシン３２０を有する。
検証部３１０は、制御部１３０の指示に基づいて、仮想マシン３２０に対するパッチの適用を実行する。検証部３１０は、パッチの適用に伴う仮想マシン３２０の負荷や適用の所要時間をパッチごとに取得する（この処理をパッチの検証ということがある）。検証部３１０は、取得したパッチに関する情報を制御部１３０に提供する。

ここで、検証部３１０は仮想マシン３２０の負荷を検証サーバ３００の負荷に換算して、制御部１３０に提供する。例えば、仮想マシン３２０に検証サーバ３００のＣＰＵ全体のＸ％のリソースが割かれており、仮想マシン３２０にあるパッチを適用したときの負荷が仮想マシン３２０に割かれたリソースのＹ％であったとする。この場合、検証サーバ３００のＣＰＵ全体に対する負荷は、（Ｘ×Ｙ×０．０１）％である。これは、パッチ適用の処理による、実行サーバ２００のリソースの利用率ということができる。ＲＡＭの負荷についても同様に換算できる。

また、検証部３１０が取得する負荷は、例えば、対象のパッチの適用開始から完了までの所要時間で平均化されたものである。あるいは、検証部３１０は、適用中に検出された負荷のうちで最高のものを当該パッチ適用時の負荷として採用してもよい。

仮想マシン３２０は、検証サーバ３００上で動作する仮想的なコンピュータである。例えば、検証サーバ３００が実行するハイパーバイザ（図示を省略）が、検証サーバ３００が備えるＣＰＵやＲＡＭのリソースを仮想マシン３２０に割り振る。

ここで、検証サーバ３００は、実行サーバ２００と同等の性能のプロセッサやＲＡＭを備えている。そして、仮想マシン３２０に割当可能なリソースは、仮想マシン２２０，２３０，２４０と同等であるものとする。よって、仮想マシン３２０を用いて取得されたパッチに関する情報は、仮想マシン２２０，２３０，２４０に当該パッチを適用したときの実行サーバ２００の負荷や適用のための所要時間の情報と考えることができる。例えば、上記のように、あるパッチを仮想マシン３２０に適用するときの負荷は、検証サーバ３００の負荷に換算して取得される。このため、当該パッチについて取得された当該負荷の情報は、仮想マシン２２０に当該パッチを適用するときの実行サーバ２００の負荷と考えることができるし、仮想マシン２３０に当該パッチを適用するときの実行サーバ２００の負荷と考えることもできる。仮想マシン２４０についても同様である。あるパッチのある仮想マシンへの適用に伴う実行サーバ２００の物理的なＣＰＵなどの負荷は、仮想マシンに割当てられたリソース量に関わらず同程度と考えられるからである。

図５は、第２の実施の形態の仮想マシン管理テーブルの例を示す図である。仮想マシン管理テーブル１１１は、記憶部１１０に格納される。仮想マシン管理テーブル１１１は、仮想マシン、割当可能最大リソース、現割当リソースおよび優先度の項目を含む。

仮想マシンの項目には、仮想マシンのＩＤが登録される。割当可能最大リソースの項目には、当該仮想マシンに対して割当可能な最大リソースを示す情報が登録される。ここで、割当可能な最大リソースは、実行サーバ２００が割当可能なリソースを１００％としたときの割合で表される。なお、リソースという場合、ＣＰＵやメモリなど複数の種類が考え得る。仮想マシン管理テーブル１１１では、何れか１つの種類のリソースに関する情報を用いる。例えば、ＣＰＵである。現割当リソースの項目には、当該仮想マシンに対して現在割当てられているリソースを示す情報が登録される。

優先度の項目には、仮想マシンごとの優先度が登録される。例えば、優先度は数値で表される。数値が小さいほど、優先度が高い。例えば、優先度は仮想マシンごとに実行される業務処理の重要度などに応じて予め定められる。例えば、重要度の高い仮想マシンほど優先度も高くする。

例えば、仮想マシン管理テーブル１１１には、仮想マシンが“ＶＭ１”、割当可能最大リソースが“５０％”、現割当リソースが“２０％”、優先度が“１”という情報が登録されている。優先度“１”は最高の優先度であり、仮想マシン２２０に対するパッチ適用の優先度が、仮想マシン２３０，２４０，２５０よりも高いことを示す。また、仮想マシン２２０に対して割当可能な最大リソース（例えば、ＣＰＵ）の割合が５０％であり、現在の割当リソースが２０％であることを示している。

図６は、第２の実施の形態のパッチ管理テーブルの例を示す図である。パッチ管理テーブル１１２は、制御部１３０により生成され、記憶部１１０に格納される。パッチ管理テーブル１１２は、第１の実施の形態の負荷情報の一例である。パッチ管理テーブル１１２は、パッチ名、ＣＰＵ使用率、メモリ使用率、所要時間、再起動フラグ、再起動時ＣＰＵ使用率、再起動時メモリ使用率、再起動所要時間および前提パッチの項目を含む。

パッチ名の項目には、パッチの名称を示す情報が登録される。ＣＰＵ使用率の項目には、当該パッチ適用時のＣＰＵの負荷を示す情報が登録される。当該ＣＰＵの負荷は、検証サーバ３００が備えるＣＰＵの全リソースに対して、パッチ適用処理に用いられるリソース分の割合である。メモリ使用率の項目には、当該パッチ適用時のメモリの負荷を示す情報が登録される。当該メモリの負荷は、検証サーバ３００が備えるＲＡＭの全リソースに対して、パッチ適用処理に用いられるリソース分の割合である。所要時間の項目には、パッチ適用の所要時間を示す情報が登録される。なお、前述のように、検証サーバ３００と実行サーバ２００とは同等のハードウェア性能を有するため、検証サーバ３００に対して取得された負荷の情報は、実行サーバ２００の負荷の情報として扱える。

再起動フラグの項目には、パッチ適用後の再起動の有無を示すフラグが登録される。再起動有りの場合は“ｔｒｕｅ”である。再起動無しの場合は“ｆａｌｓｅ”である。再起動時ＣＰＵ使用率の項目には、再起動時のＣＰＵの負荷を示す情報が登録される。再起動時メモリ使用率の項目には、再起動時のメモリの負荷を示す情報が登録される。再起動所要時間の項目には、再起動の所要時間を示す情報が登録される。前提パッチの項目には、当該パッチが適用される前に、適用されているべき他のパッチ（前提パッチと称することがある）が存在する場合、当該他のパッチの名称が登録される。

ここで、再起動時ＣＰＵ使用率、再起動時メモリ使用率および再起動所要時間の項目には、パッチ適用後の再起動が有りの場合にのみ情報が登録される。パッチ適用後の再起動が無しの場合は設定無し“−”（ハイフン）となる。

例えば、パッチ管理テーブル１１２には、パッチ名が“Ｐ−００１”、ＣＰＵ使用率が“３０％”、メモリ使用率が“２０％”、所要時間が“３分”、再起動が“ｆａｌｓｅ”、再起動時ＣＰＵ使用率が“−”、再起動時メモリ使用率が“−”、再起動所要時間が“−”、前提パッチが“−”（設定無し）という情報が登録されている。

これは、Ｐ−００１の名称で識別されるパッチを適用している時の検証サーバ３００のＣＰＵ使用率が３０％、メモリ使用率が２０％であり、パッチ適用の所要時間が３分、パッチ適用後の再起動がなく、前提パッチが存在しないことを示している。

また、例えばパッチ管理テーブル１１２には、パッチ名が“Ｐ−００３”、ＣＰＵ使用率が“１０％”、メモリ使用率が“１０％”、所要時間が“７分”、再起動が“ｔｒｕｅ”、再起動時ＣＰＵ使用率が“４０％”、再起動時メモリ使用率が“３０％”、再起動所要時間が“３分”、前提パッチが“Ｐ−００１，Ｐ−００２”という情報が登録されている。

これは、Ｐ−００３の名称で識別されるパッチを適用しているときの検証サーバ３００のＣＰＵ使用率が１０％、メモリ使用率が１０％であり、パッチ適用の所要時間が７分、パッチ適用後の再起動が有りであることを示す。また、再起動時のＣＰＵ使用率が４０％、再起動時のメモリ使用率が３０％、再起動の所要時間が３分であり、前提パッチとして、Ｐ−００１およびＰ−００２のパッチが存在することを示す。なお、パッチ適用の所要時間の７分の内訳には、再起動の所要時間３分を含む。

図７は、第２の実施の形態のスケジュールテーブルの例（その１）を示す図である。スケジュールテーブル１１３は、仮想マシン２２０に対するパッチ適用のスケジュールを示す情報である。スケジュールテーブル１１３は、制御部１３０により生成され、記憶部１１０に格納される。スケジュールテーブル１１３は、パッチ名、適用順番、所要時間、実所要時間、完了フラグ、遅延時間、開始予定時刻、実開始時刻および実終了時刻の項目を含む。

パッチ名の項目には、パッチの名称を示す情報が登録される。適用順番の項目には、パッチ適用の順番を示す情報が登録される。例えば、順番は番号の昇順で表される。所要時間の項目には、パッチ適用の所要時間が登録される。実所要時間の項目には、パッチ適用の実際の所要時間が登録される。完了フラグの項目には、当該パッチの適用が完了したか否かを示すフラグが登録される。完了している場合は“ｔｒｕｅ”である。完了していない場合は“ｆａｌｓｅ”である。

遅延時間の項目には、遅延時間の累積が登録される。適用順番が最初であるパッチからの現パッチまでの遅延時間の累積である。１つのパッチにおける遅延時間は実所要時間と所要時間との差である。開始予定時刻の項目には、対応するパッチの適用を開始する予定時刻が登録される。実開始時刻の項目には、実際の開始時刻が登録される。実終了時刻の項目には、パッチ適用を完了した実際の時刻が登録される。

ここで、実開始時刻の項目はパッチ適用が開始されたパッチについてのみ情報が登録される。また、実所要時間および実終了時刻の項目はパッチ適用が完了したパッチについてのみ情報が登録される。更に、遅延時間のデフォルトの設定は“０分”である。１つのパッチの適用が完了すると、当該パッチにおける遅延時間が当該パッチおよびそれ以降のパッチの遅延時間に累積されていく。

例えば、スケジュールテーブル１１３には、パッチ名が“Ｐ−００１”、適用順番が“１”、所要時間が“３分”、実所要時間が“３分”、完了フラグが“ｔｒｕｅ”、遅延時間が“０分”、開始予定時刻が“００：００：００”、実開始時刻が“００：００：００”、実終了時刻が“００：０３：００”という情報が登録されている。

これは、Ｐ−００１の名称で識別されるパッチの適用を最初に行うこと、パッチ適用の所要時間が３分であること、パッチ適用が完了しており、実際の所要時間が３分であったこと、遅延時間が０分であることを示す。また、パッチ適用の開始予定時刻が０時０分０秒であり、実際の開始時刻が０時０分０秒であったこと、実際の終了時刻が０時３分０秒であったことを示す。

また、例えば、スケジュールテーブル１１３には、パッチ名が“Ｐ−００３”、適用順番が“３”、所要時間が“７分”、実所要時間が“８分”、完了フラグが“ｔｒｕｅ”、遅延時間が“２分”、開始予定時刻が“００：０５：００”、実開始時刻が“００：０６：００”、実終了時刻が“００：１４：００”という情報が登録されている。

これは、Ｐ−００３の名称で識別されるパッチの適用を３番目に行うこと、パッチ適用の所要時間（再起動の時間も含めて）が７分であること、パッチ適用が完了しており、実際の所要時間が８分であったこと、遅延時間が２分であることを示す。また、パッチ適用の開始予定時刻が０時５分０秒であり、実際の開始時刻が０時６分０秒であったこと、実際の終了時刻が０時１４分０秒であったことを示す。

更に、例えば、スケジュールテーブル１１３では、パッチ名が“Ｐ−００５”のレコードについて、実開始時刻の項目への登録はあるが、実所要時間および実終了時刻の項目への登録がない。当該Ｐ−００５の名称で識別されるパッチは、現在適用されている最中だからである。

なお、パッチ適用を週次や月次などで行う場合には、開始予定時刻、実開始時刻および実終了時刻に、年月日などの情報を含めてもよい。
図８は、第２の実施の形態のスケジュールテーブルの例（その２）を示す図である。スケジュールテーブル１１３ａは、仮想マシン２３０に対するパッチ適用のスケジュールを示す情報である。スケジュールテーブル１１３ａは、制御部１３０により生成され、記憶部１１０に格納される。スケジュールテーブル１１３ａは、パッチ名、適用順番、所要時間、実所要時間、完了フラグ、遅延時間、開始予定時刻、実開始時刻および実終了時刻の項目を含む。各項目に登録される情報は、図７で説明した内容と同様である。記憶部１１０は、仮想マシン２４０に対しても、スケジュールテーブル１１３，１１３ａと同様のデータ構造のスケジュールテーブルを記憶する。なお、仮想マシン２５０については、パッチの適用対象外であるためにスケジュールテーブルは作成されない。

このように制御部１３０は、仮想マシン２２０，２３０，２４０それぞれについて、パッチ適用のスケジュールを生成し、記憶部１１０に格納する。また、制御部１３０は、仮想マシンごとのスケジュールテーブルを用いて、仮想マシンごとのパッチの適用状況を管理する。次に、管理サーバ１００による処理の手順を説明する。

図９は、第２の実施の形態の処理を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。
（ステップＳ１１）パッチ収集部１２０は、配信サーバ４００によって新たに配信されたパッチを収集し、記憶部１１０に格納する。

（ステップＳ１２）制御部１３０は、記憶部１１０に記憶されたパッチを検証サーバ３００に順次送信して、各パッチの検証を検証サーバ３００に依頼する。制御部１３０は、新たなパッチが収集されたタイミングで検証の依頼を行ってもよいし、日次や週次などでのパッチ適用の開始前（例えば、１日前や１２時間前など）に、新たに収集された複数のパッチについて検証の依頼を行ってもよい。検証部３１０は、制御部１３０から受けた依頼に応じて、１つずつ順番に仮想マシン３２０に適用し、パッチの検証を行う。検証部３１０は、検証により取得したパッチに関する情報を管理サーバ１００に送信する。制御部１３０は、当該パッチに関する情報を受信し、記憶部１１０に記憶されたパッチ管理テーブル１１２に登録する。

（ステップＳ１３）制御部１３０は、パッチ管理テーブル１１２に基づいて、仮想マシンごとにスケジュールテーブルを生成し、記憶部１１０に格納する。ここで、前述のように、パッチ管理テーブル１１２は、複数のパッチそれぞれを仮想マシン２２０，２３０，２４０それぞれに適用するときの実行サーバ２００の負荷を示す負荷情報である。制御部１３０は、パッチ管理テーブル１１２と実行サーバ２００で許容される負荷の上限とに基づいて、所定期間内に複数のパッチを仮想マシンに適用するときの適用順序を、仮想マシン２２０，２３０，２４０それぞれについて決定する。決定手順の詳細は後述する。
（ステップＳ１４）制御部１３０は、仮想マシンごとのスケジュールテーブルに基づいて、記憶部１１０に記憶されたパッチを実行サーバ２００に順次送信し、各仮想マシンに適用するように実行サーバ２００に指示する。実行部２１０は、管理サーバ１００の指示に応じて、各仮想マシンにパッチを適用する。実行部２１０は、パッチの適用状況を管理サーバ１００に提供する。制御部１３０は、パッチの適用状況に基づいて、それ以降に実行されるパッチ適用のスケジュールの変更を行うこともある。

このようにして、管理サーバ１００は、各仮想マシンに対するパッチ適用を制御する。以下では、上記の各手順を詳細に説明する。まず、ステップＳ１２の検証処理の手順を説明する。

図１０は、第２の実施の形態の検証処理を示すフローチャートである。以下、図１０に示す処理をステップ番号に沿って説明する。
（ステップＳ２１）制御部１３０は、記憶部１１０に記憶されており新たに収集された各パッチを検証サーバ３００に順次（例えば、収集された順番などで）送信する。検証部３１０は、仮想マシン３２０を用いて、受信したパッチの検証を行う。具体的には、パッチごとにステップＳ２２，Ｓ２３を繰り返す。

（ステップＳ２２）検証部３１０は、パッチ適用時の仮想マシン３２０の負荷を取得する。仮想マシン３２０の負荷とは、例えば、仮想マシン３２０に割り振られたリソースを１００％としたときに、パッチ適用のために利用されるリソースの割合である。検証部３１０は、ＣＰＵおよびメモリについて、仮想マシン３２０の負荷を取得する。また、検証部３１０は、パッチ適用の所要時間を取得する。また、検証部３１０は、再起動の有無や前提パッチの存在の有無なども取得する。例えば、再起動の有無は、パッチ適用の試行後に当該パッチが仮想マシンの再起動を行うかにより判断できる。例えば、提供されたパッチに前提パッチを示す情報が登録されていることがあるため、その情報を読み取ることで前提パッチの有無や前提パッチを示す情報を把握できる。

（ステップＳ２３）検証部３１０は、パッチ適用時の仮想マシン３２０の負荷を検証サーバ３００当たりの負荷に換算する。前述したように、検証サーバ３００のＣＰＵまたはメモリのリソースうちのＸ％が仮想マシン３２０に割り振られており、ステップＳ２２で取得された仮想マシン３２０のＣＰＵまたはメモリについての負荷がＹ％であったとする。この場合、（Ｘ×Ｙ×０．０１）％が検証サーバ３００の負荷である。検証部３１０は、パッチごとに取得した情報を管理サーバ１００に提供する。制御部１３０は、記憶部１１０に記憶されたパッチ管理テーブル１１２に提供された情報を登録する。

（ステップＳ２４）制御部１３０は、新たに収集された全てのパッチについての情報を検証サーバ３００から取得すると、繰り返しを完了する。
このようにして、制御部１３０は、検証サーバ３００にパッチを送信し、当該パッチの検証結果を検証サーバ３００から取得する。

なお、制御部１３０が、ステップＳ２３で説明した換算を行ってもよい。その場合、検証サーバ３００が備えるリソースの情報や仮想マシン３２０に割当てられるリソースの情報を制御部１３０に予め与えておく。そして、検証部３１０は、パッチごとの仮想マシン３２０の負荷の情報を制御部１３０に提供する。制御部１３０は、これらの情報に基づいて、ステップＳ２３の換算を行える。

次に、図９のステップＳ１３のスケジューリングの手順を説明する。
図１１は、第２の実施の形態のスケジューリングを示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。

（ステップＳ３１）制御部１３０は、仮想マシンごとに適用するパッチを判別する。具体的には、仮想マシン２２０，２３０，２４０それぞれで実行されるＯＳまたはアプリケーションと、新たに提供されたパッチに対応するＯＳまたはアプリケーションとを対比して、仮想マシンごとに適用すべきものを判断する。制御部１３０は、仮想マシンごとの適用対象パッチを示す情報を記憶部１１０に格納する。

（ステップＳ３２）制御部１３０は、記憶部１１０に記憶された仮想マシンごとのスケジュールテーブルにパッチ適用順序を設定する。詳細は後述する。
（ステップＳ３３）制御部１３０は、ステップＳ３２で決定したパッチ適用順序を、実行サーバ２００単位の負荷を考慮して調整する。詳細は後述する。

このように、制御部１３０は仮想マシンごとにスケジューリングを行い、スケジュールテーブルに登録する。以下では、ステップＳ３２，Ｓ３３の手順を更に詳細に説明する。まず、ステップＳ３２のパッチ適用順序の設定の手順を説明する。

図１２は、第２の実施の形態のパッチ適用順序の設定を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
（ステップＳ４１）制御部１３０は、記憶部１１０に記憶された仮想マシン管理テーブル１１１を参照して、以降に示すステップＳ４２〜Ｓ４５の処理を行っていない仮想マシン（未処理の仮想マシン）のうち、最高の優先度の仮想マシンを選択する。ここで、仮想マシン２５０はパッチの適用対象外であるため、ステップＳ４１の選択の対象にならない。

（ステップＳ４２）制御部１３０は、記憶部１１０に記憶されたパッチ管理テーブル１１２を参照して、ステップＳ４１で選択された仮想マシンに対する適用対象パッチで順序未決定のもののうち、最高の負荷となるパッチを選択する。ここで、当該仮想マシンに対する適用対象パッチは、ステップＳ３１で判別済である。また、あるパッチの適用が仮想マシンに与える負荷としては、パッチ管理テーブル１１２に登録された当該パッチのＣＰＵ使用率、メモリ使用率、再起動時ＣＰＵ使用率および再起動時メモリ使用率のうち、最も高いものを採用する。パッチ管理テーブル１１２の例でいえば、パッチ“Ｐ−００１”は、上記４項目のうちＣＰＵ使用率“３０％”が最高である。よって、制御部１３０は、パッチ“Ｐ−００１”の適用が仮想マシンに与える負荷を３０％と見積もる。また、パッチ“Ｐ−００３”は、上記４項目のうち再起動時ＣＰＵ使用率“４０％”が最高である。よって、制御部１３０は、パッチ“Ｐ−００３”の適用が仮想マシンに与える負荷を４０％と見積もる。

（ステップＳ４３）制御部１３０は、ステップＳ４２で選択したパッチに依存関係のある順序設定済のパッチがあるか否かを判定する。依存関係のある順序設定済のパッチがある場合、処理をステップＳ４４に進める。依存関係のある順序設定済のパッチがない場合、処理をステップＳ４５に進める。ここで、依存関係のある順序設定済のパッチとは、次のものを指す。（１）現在選択中のパッチについて、パッチ管理テーブル１１２の前提パッチの項目に前提パッチ名の登録があり、かつ、その前提パッチが現在選択中の仮想マシンのスケジュールテーブルに登録済の場合、当該前提パッチ。（２）現在選択中の仮想マシンに対応するスケジュールテーブルに登録済であり、かつ、現在選択中のパッチを前提パッチとしてもつパッチが存在する場合、現在選択中のパッチを前提パッチとしてもつ当該パッチ。

（ステップＳ４４）制御部１３０は、パッチ同士の依存関係に基づいてスケジュールテーブルに、現在選択中のパッチの情報を登録する。例えば、ステップＳ４３で、（１）で示した前提パッチが存在することで、依存関係のある順序設定済のパッチがあると判定された場合、その前提パッチの直後に現在選択中のパッチを適用するようにスケジュールテーブルへの登録を行う。また、例えば、ステップＳ４３で、（２）で示したパッチが存在することで、依存関係のある順序設定済のパッチがあると判定された場合、当該（２）で示したパッチの直前に現在選択中のパッチを適用するようにスケジュールテーブルへの登録を行う。なお、現在選択中のパッチが挿入されることで、他のパッチのスケジュールが後ろにずれることもある。また、最初に適用するパッチの適用開始時刻は固定されているものとする（例えば、０時０分０秒に固定）。制御部１３０は、パッチ管理テーブル１１２に登録された所要時間の情報に基づいて、適用開始予定時刻などもスケジュールテーブルに設定する。そして、処理をステップＳ４６に進める。

（ステップＳ４５）制御部１３０は、順序決定済のパッチのうち、最後のパッチの次の順番を、現在選択中のパッチの順番としてスケジュールテーブルに設定する。例えば、スケジュールテーブルにおいて、適用順番“３”までが登録済であれば、現在選択中のパッチの適用順番は“４”として登録されることになる。制御部１３０は、パッチ管理テーブル１１２に登録された所要時間の情報に基づいて、適用開始予定時刻などもスケジュールテーブルに設定する。

（ステップＳ４６）制御部１３０は、ステップＳ４１で選択した仮想マシンについて、適用対象である全てのパッチの順序を決定済であるか否かを判定する。全てのパッチの順序を決定済である場合、処理をステップＳ４７に進める。全てのパッチの順序を決定済でない場合、処理をステップＳ４２に進める。例えば、ステップＳ４１で選択した仮想マシンについて、適用対象である全てのパッチが、当該仮想マシンのスケジュールテーブルに登録済であれば、全てのパッチの順序を決定済である。一方、ステップＳ４１で選択した仮想マシンについて、適用対象である全てのパッチが、当該仮想マシンのスケジュールテーブルに登録済でなければ、全てのパッチの順序を決定済ではない。

（ステップＳ４７）制御部１３０は、適用すべきパッチが存在する全ての仮想マシンについて、ステップＳ４１〜Ｓ４６の手順を処理済であるか否かを判定する。処理済である場合、処理を終了する。処理済でない場合、処理をステップＳ４１に進める。例えば、適用すべきパッチが存在する全ての仮想マシンについて、ステップＳ４１〜Ｓ４６の手順によりスケジュールテーブルが作成されていれば、処理済と判定する。一方、スケジュールテーブルが作成されていない仮想マシンがあれば、処理済でないと判定する。

このようにして、制御部１３０は仮想マシンごとのスケジュールテーブルを作成する。次に、パッチ適用順序の設定例を具体的に説明する。
図１３は、第２の実施の形態のパッチ適用順序の設定例を示す図である。図１３では、図１２の手順によって実行サーバ２００の仮想マシン２２０，２３０，２４０のパッチ適用順序が設定された結果を例示している。ここで、仮想マシン２２０，２３０，２４０に適用されるパッチは同一であるものとする。

図１３（Ａ）は仮想マシン２２０のパッチ適用順序を示す棒グラフＧ１０を例示している。図１３（Ｂ）は仮想マシン２３０のパッチ適用順序を示す棒グラフＧ２０を例示している。図１３（Ｃ）は仮想マシン２４０のパッチ適用順序を示す棒グラフＧ３０を例示している。棒グラフＧ１０，Ｇ２０，Ｇ３０の横軸は時間であり、縦軸は実行サーバ２００の負荷である。また、横軸に記入された時刻Ｔ０はパッチの適用開始予定時刻であり、時刻Ｔは適用終了予定時刻である。

仮想マシン２２０，２３０，２４０に適用されるパッチは同一であるため、ここでは棒グラフＧ１０，Ｇ２０，Ｇ３０も同一となる。
棒グラフＧ１０は、バーの集合Ｇ１１，Ｇ１４，Ｇ１５，Ｇ１６およびバーＧ１２，Ｇ１３を含む。バーの集合とは、依存関係のあるパッチの集合（以下、パッチグループと称することがある）に含まれる個々のパッチに対応するバーの一群である。

例えば、バーの集合Ｇ１１は、パッチ名“Ｐ−００１”、“Ｐ−００２”、“Ｐ−００３”の３つのパッチを含むパッチグループに対応するものであり、３つのバーを含む。パッチ管理テーブル１１２によれば、これらの３つのパッチは依存関係をもち、“Ｐ−００１”、“Ｐ−００２”、“Ｐ−００３”の順番での適用が推奨されている。よって、バーの集合Ｇ１１に含まれる３つのバーは時刻Ｔ０に近い方から、“Ｐ−００１”、“Ｐ−００２”、“Ｐ−００３”の順に並んでいる。

一方、バーＧ１２，Ｇ１３は、他のパッチとの依存関係をもたないパッチに対応するものである。ただし、以降の説明では、バーＧ１２，Ｇ１３に対応する各パッチをも含めてパッチグループと称することがある。例えば、他のパッチとの依存関係をもたないパッチは、要素が１つであるパッチの集合と考えることができる。

棒グラフＧ２０は、バーの集合Ｇ２１，Ｇ２４，Ｇ２５，Ｇ２６およびバーＧ２２，Ｇ２３を含む。また、棒グラフＧ３０は、バーの集合Ｇ３１，Ｇ３４，Ｇ３５，Ｇ３６およびバーＧ３２，Ｇ３３を含む。バーの集合Ｇ２１，Ｇ３１は、バーの集合Ｇ１１と同一のパッチグループに対応するものである。バーＧ２２，Ｇ３２は、バーＧ１２と同一のパッチに対応するものである。バーＧ２３，Ｇ３３は、バーＧ１３と同一のパッチに対応するものである。バーの集合Ｇ２４，Ｇ３４は、バーＧ１４と同一のパッチグループに対応するものである。バーの集合Ｇ２５，Ｇ３５は、バーＧ１５と同一のパッチグループに対応するものである。バーの集合Ｇ２６，Ｇ３６は、バーＧ１６と同一のパッチグループに対応するものである。

ただし、ここで作成されたスケジュールテーブルに従って、各パッチを適用しようとすると、実行サーバ２００の負荷が過大となるおそれがある。そこで、制御部１３０は、スケジュールテーブルに調整を加える。次に、図１１のステップＳ３３のパッチ適用順序の調整の手順を説明する。

図１４は、第２の実施の形態のパッチ適用順序の調整を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
（ステップＳ５１）制御部１３０は、仮想マシン管理テーブル１１１を参照して、最高の優先度の仮想マシン２２０を特定する。制御部１３０は、仮想マシン２２０に対応するスケジュールテーブル１１３に設定されたスケジュールを確定する。すなわち、スケジュールテーブル１１３の設定内容は以降の手順で変更されないことになる。

（ステップＳ５２）制御部１３０は、最高の優先度である仮想マシン２２０に対して、スケジュールテーブル１１３内の全パッチを適用するための所要時間を取得する。当該所要時間は、時刻Ｔ０から時刻Ｔまでの時間である。

（ステップＳ５３）制御部１３０は、ステップＳ５２で求めた所要時間に基づいて、各仮想マシン（最高の優先度である仮想マシン２２０を除く）のスケジュール分割点を決定する。ここで、スケジュール分割点とは、スケジュール内のある時点を示し、その時点以降のパッチ適用のスケジュール部分（複数のパッチグループの適用スケジュールを含み得る）を、その時点よりも前のパッチ適用のスケジュール部分と組み替えるための時点を示す。

（ステップＳ５４）制御部１３０は、各仮想マシンのスケジュール分割点以降の第１のスケジュール部分を適用開始時点に移行する。その結果、スケジュール分割点よりも前の第２のスケジュール部分が当該第１のスケジュール部分の直後に移行することになる。制御部１３０は、パッチグループ単位に移行する。パッチグループを分割して移行すると、依存関係に基づく適用順序が崩れるおそれがあるからである。なお、制御部１３０は最高の優先度である仮想マシン２２０以外について当該処理を行う。

（ステップＳ５５）制御部１３０は、スケジュールを未調整である仮想マシンのうち、最高の優先度の仮想マシンを選択する。スケジュールを未調整である仮想マシンとは、ステップＳ５６の処理を行っていない仮想マシンを意味する。

（ステップＳ５６）制御部１３０は、ステップＳ５５で選択された仮想マシンに対するパッチ適用時の実行サーバ２００の負荷を評価し、当該評価結果に基づいて、パッチグループ単位に開始予定時刻を調整する。詳細は後述する。

（ステップＳ５７）制御部１３０は、全ての仮想マシンについてスケジュールを調整済であるか否かを判定する。全ての仮想マシンを調整済である場合、処理を終了する。全ての仮想マシンを調整済でない場合、処理をステップＳ５５に進める。

ここで、ステップＳ５３，Ｓ５４で示した、スケジュール分割点によるスケジュールの組み替えの具体例を説明する。
図１５は、第２の実施の形態のスケジュールの組み替え例を示す図である。図１５では、図１３で例示した仮想マシン２２０，２３０，２４０のスケジュールに対して、スケジュール分割点を決定するための方法を例示している。

図１５（Ａ）は仮想マシン２２０のパッチ適用順序を示す棒グラフＧ１０を例示している。図１５（Ｂ）は仮想マシン２３０のパッチ適用順序を示す棒グラフＧ２０を例示している。図１５（Ｃ）は仮想マシン２４０のパッチ適用順序を示す棒グラフＧ３０を例示している。棒グラフＧ１０，Ｇ２０，Ｇ３０については、図１３で説明した通りである。

ここで、棒グラフＧ１０，Ｇ２０，Ｇ３０では、スケジュール分割点である時刻Ｔ１，Ｔ２が示されている。時刻Ｔ１は時刻Ｔ０，Ｔの中間の時刻である。すなわち、時刻Ｔ０〜Ｔ１の時間間隔と時刻Ｔ１〜Ｔの時間間隔は等しい。時刻Ｔ２は時刻Ｔ１，Ｔの中間の時刻である。すなわち、時刻Ｔ１〜Ｔ２の時間間隔と時刻Ｔ２〜Ｔの時間間隔は等しい。

このように、例えば、最高の優先度の仮想マシン以外にも、パッチ適用対象の仮想マシンが２つ存在する場合、スケジュール分割点も２つ（時刻Ｔ１，Ｔ２）決定する。時刻Ｔに近いスケジュール分割点ほど、高い優先度の仮想マシンに対して適用する。本例では、仮想マシン２３０のスケジュール分割点を時刻Ｔ２とする。仮想マシン２４０のスケジュール分割点を時刻Ｔ１とする。仮想マシン２３０は仮想マシン２４０よりも優先度が高いからである。

なお、最高の優先度の仮想マシン以外に、パッチ適用対象の仮想マシンが３以上存在する場合も考えられる。例えば、３つ存在するなら、時刻Ｔ２，Ｔの中間の時刻をスケジュール分割点（３つ目のスケジュール分割点）として更に取得する。同様に、４つ目のスケジュール分割点も、３つ目のスケジュール分割点の時刻と時刻Ｔの中間の時刻として求められる。それ以降のスケジュール分割点も同様にして求められる。

図１６は、第２の実施の形態のスケジュールの組み替え例（続き）を示す図である。図１６では、図１５で示したスケジュール分割点による仮想マシン２３０，２４０のスケジュール組み替え後の例を示している。図１６（Ａ）は棒グラフＧ１０を例示している。棒グラフＧ１０は、最高の優先度である仮想マシン２２０のスケジュールを示すものである。当該仮想マシン２２０のスケジュールは固定である。図１６（Ｂ）はスケジュール組み替え後の棒グラフＧ２０を例示している。図１６（Ｃ）はスケジュール組み替え後の棒グラフＧ３０を例示している。

例えば、棒グラフＧ２０では、バーの集合Ｇ２６に対応するパッチグループの適用開始予定時刻を時刻Ｔ０に移行している。当該パッチグループの適用予定時間はスケジュール分割点である時刻Ｔ２を含むからである。その他のパッチグループは、当該バーの集合Ｇ２６に対応するパッチグループの適用が完了した直後から順次適用されるように、開始予定時刻が後ろの時間にずらされる。このように、スケジュール分割点である時刻を適用予定時間の範囲に含むパッチグループ以降のパッチグループを開始予定時刻の前方に移行する。

また、例えば、棒グラフＧ３０では、バーの集合Ｇ３５に対応するパッチグループの適用開始予定時刻を時刻Ｔ０に移行している。また、バーの集合Ｇ３６に対応するパッチグループの適用開始予定時刻を、バーの集合Ｇ３５に対応するパッチグループの適用が完了した直後に移行している。その他のパッチグループは、当該バーの集合Ｇ３６に対応するパッチグループの適用が完了した直後から順次適用されるように、開始予定時刻が後の時間にずらされる。
このように、依存関係にあるパッチを順番に、かつ、連続した状態を保って（パッチグループ単位で）スケジュール調整する理由は次の通りである。すなわち、図１４で説明したように、全体スケジュールを所定の分割点で区切って、パッチの適用順序を組み替える際に、依存関係にあるパッチの適用順序を維持する（逆の順番にならないようにする）ためである。
また、全体スケジュールの終盤側に分割点を設けてスケジュール調整する理由は次の通りである。すなわち、図１３では、相対的に負荷の高いパッチから先に適用するように適用順序を決定しているため、スケジュール全体の傾向として、スケジュールの終盤程、相対的に負荷の低いパッチがスケジューリングされている可能性が高い。よって、パッチグループを組み替える場合、スケジュールのより終盤のパッチグループをスケジュールの前半へと移行させる方が、実行サーバ２００の負荷が閾値を超過する可能性は低い。これにより、負荷が閾値を超えないようにスケジューリングするための組み替えの試行回数を軽減できる。例えば、ランダムにパッチグループの組み替えを試行するよりも、適用順序の決定に伴う演算コストを軽減できる。

次に、図１４のステップＳ５６におけるパッチグループ単位の開始予定時刻の調整の手順を説明する。
図１７は、第２の実施の形態のパッチグループの調整を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。

（ステップＳ６１）制御部１３０は、現在選択中の仮想マシンに対するスケジュールテーブルを参照して、スケジュール未確定のパッチグループのうちで開始予定時刻の最も早いものを選択する。

（ステップＳ６２）制御部１３０は、各仮想マシンについて確定済のスケジュールを考慮して、選択したパッチグループに含まれる各パッチの適用時点の実行サーバ２００の負荷を算出する（個々のパッチ適用に伴う負荷を各時点において合計する）。制御部１３０は、記憶部１１０に記憶された各仮想マシンのスケジュールテーブルを参照して、ステップＳ６１で選択したパッチグループの適用予定時間と同じ時間帯に他の仮想マシンで適用されるパッチを特定できる。各パッチの適用に伴う負荷は、図１２のステップＳ４２で説明したように、パッチ管理テーブル１１２に登録されたＣＰＵ使用率、メモリ使用率、再起動時ＣＰＵ使用率および再起動時メモリ使用率のうち、最大の値とする。

（ステップＳ６３）制御部１３０は、実行サーバ２００の負荷が予め定められた閾値Ｌを超える時点（閾値Ｌよりも大きくなる時点）があるか否かを判定する。閾値Ｌを超える時点がある場合、処理をステップＳ６４に進める。閾値Ｌを超える時点がない場合、処理をステップＳ６５に進める。

（ステップＳ６４）制御部１３０は、現在選択中のパッチグループの開始予定時刻を後ろにずらす。例えば、現在選択中のパッチグループ内で最初に適用されるパッチ適用の所要時間がｔであれば、当該パッチグループの開始予定時刻をｔだけ後ろにずらすことが考えられる。ただし、制御部１３０は、ずらす時間ｔの任意の決定を許容してもよい（例えば、ｔ＝１分またはｔ＝３分など）。そして、処理をステップＳ６２に進める。

（ステップＳ６５）制御部１３０は、現在選択中のパッチグループに関するスケジュールを確定する。これによって、当該パッチグループに含まれる各パッチの適用開始予定時刻が確定される。

（ステップＳ６６）制御部１３０は、全てのパッチグループについてスケジュールを確定済であるか否かを判定する。全てのパッチグループについてスケジュールを確定済の場合、処理を終了する。全てのパッチグループについてスケジュールを確定済でない場合、処理をステップＳ６１に進める。

このようにして、実行サーバ２００の負荷が閾値Ｌを超えないように、各パッチグループのスケジュールを決定する。ここで、制御部１３０は、種々の基準に基づいて閾値Ｌを決定することができる。具体的には、次の第１，第２の方法が考えられる。

第１の方法は、各仮想マシンに割当可能な最大のリソースに応じて決める方法である。例えば、仮想マシン管理テーブル１１１で示したように各仮想マシンには、割当可能最大リソースが予め定められている。この場合、閾値Ｌ＝“実行サーバ２００で割当可能なリソース”−“パッチの適用対象外の仮想マシンに対する割当可能最大リソースの合計”とする。例えば、“実行サーバ２００で割当可能なリソース”を１００％と表す。これに対し、“パッチの適用対象外の仮想マシン”は、本例では仮想マシン２５０である。したがって、“パッチの適用対象外の仮想マシンに対する割当可能最大リソースの合計”は５０％となる。よって、閾値Ｌ＝１００％−５０％＝５０％である。

第２の方法は、各仮想マシンに現在割当てられているリソースに応じて決める方法である。この場合、閾値Ｌ＝“実行サーバ２００で割当可能なリソース”−“パッチの適用対象外の仮想マシンに現在割当てられているリソースの合計”とする。例えば、“実行サーバ２００で割当可能なリソース”を１００％と表す。これに対し、“パッチの適用対象外の仮想マシン”は、本例では仮想マシン２５０である。したがって、“パッチの適用対象外の仮想マシンに現在割当てられているリソースの合計”は、例えば、３０％である。よって、閾値Ｌ＝１００％−３０％＝７０％である。

次に、パッチグループ単位の開始予定時刻の調整の具体例を説明する。
図１８は、第２の実施の形態のパッチグループの調整例を示す図である。図１８では、仮想マシン２３０に適用するパッチについて、パッチグループ単位のスケジュール調整を行う場合を例示している。ここで、仮想マシン２３０よりも優先度の高い仮想マシン２２０のスケジュールは確定されている。仮想マシン２２０のスケジュールは棒グラフＧ１０で表されている。また、図１８では実行サーバ２００で許容される負荷の閾値Ｌも例示されている。

まず、制御部１３０は、棒グラフＧ１０にバーの集合Ｇ２６を積み上げる（各時間帯の合計の負荷を算出する）。バーの集合Ｇ２６に対応する第１のパッチグループの適用開始予定時刻は、図１６で例示した処理により時刻Ｔ０となっている。バーの集合Ｇ２６ａは、バーの集合Ｇ２６を棒グラフＧ１０に積み上げたものを示している。積み上げを行っても、第１のパッチグループの適用時間中に実行サーバ２００の負荷が閾値Ｌを超過する時点はないことが分かる。したがって、制御部１３０は第１のパッチグループの適用スケジュールを、この時間帯に確定する。

次に、制御部１３０は、棒グラフＧ１０にバーの集合Ｇ２１を積み上げる。バーの集合Ｇ２１に対応する第２のパッチグループの適用開始予定時刻は、図１６で例示した処理により、第１のパッチグループの適用が完了した直後の時刻となっている。バーの集合Ｇ２１ａは、バーの集合Ｇ２１を棒グラフＧ１０に積み上げたものを示している。この場合、当該積み上げを行うと、第２のパッチグループの適用時間中に実行サーバ２００の負荷が閾値Ｌを超過する時点があることが分かる。したがって、制御部１３０は、第２のパッチグループの適用スケジュールを後ろにずらして、同じ判定を繰り返す。このようにして、実行サーバ２００の負荷が閾値Ｌを超過しないようにスケジュール調整する。例えば、第２のパッチグループの適用開始予定時刻を時刻Ｔ１１までずらすと、実行サーバ２００の負荷が閾値Ｌを超過しないように各パッチの適用が可能であるとする。バーの集合Ｇ２１ｂは、適用開始予定時刻を時刻Ｔ１１までずらして、バーの集合Ｇ２１を棒グラフＧ１０に積み上げたものを示している。
ここで、時刻Ｔ１１が、仮想マシン２２０に対する何れかのパッチ（パッチＰとする）の適用開始予定時刻よりも後で、当該パッチＰの適用終了予定時刻よりも前の時刻である場合がある。その場合、バーの集合Ｇ２１ｂに対応するパッチグループの適用開始予定時刻Ｔ１１を、パッチＰの適用開始予定時刻に前倒しして、実行サーバ２００の負荷が閾値Ｌを超過するか否かを確認してもよい。そして、時刻Ｔ１１をパッチＰの適用開始予定時刻に前倒ししても、負荷が閾値Ｌを超過しないようであれば、当該パッチＰの適用開始予定時刻に一致するように時刻Ｔ１１を決定してもよい。仮想マシン２２０において、バーの集合Ｇ２１ｂに対応するパッチグループの適用開始予定時刻Ｔ１１を早めることで、スケジュールの短縮化を図れる。

制御部１３０は、それ以降の他のパッチグループの適用開始予定時刻も同様にして決定する。ここで、バーＧ２２ａは、バーＧ２２を棒グラフＧ１０に積み上げたものである。バーＧ２３ａは、バーＧ２３を棒グラフＧ１０に積み上げたものである。バーの集合Ｇ２４ａは、バーの集合Ｇ２４を棒グラフＧ１０に積み上げたものである。バーの集合Ｇ２５ａは、バーの集合Ｇ２５を棒グラフＧ１０に積み上げたものである。

図１９は、第２の実施の形態のパッチグループの調整例（続き）を示す図である。図１９では、仮想マシン２４０に適用するパッチについて、パッチグループ単位のスケジュール調整を行う場合を例示している。ここで、仮想マシン２４０よりも優先度の高い仮想マシン２２０，２３０のスケジュールは確定されている。これらの確定されたスケジュールは、棒グラフＧ１０ａで表されている。また、図１９では実行サーバ２００で許容される負荷の閾値Ｌも例示されている。

まず、制御部１３０は、棒グラフＧ１０ａにバーの集合Ｇ３５を積み上げる。バーの集合Ｇ３５に対応する第３のパッチグループの適用開始予定時刻は、図１６で例示した処理により時刻Ｔ０となっている。バーの集合Ｇ３５ａは、バーの集合Ｇ３５を棒グラフＧ１０ａに積み上げたものを示している。この場合、当該積み上げを行うと、第３のパッチグループの適用時間中に実行サーバ２００の負荷が閾値Ｌを超過する時点があることが分かる。したがって、制御部１３０は、第３のパッチグループの適用スケジュールを後ろにずらして、同じ判定を繰り返す。このようにして、実行サーバ２００の負荷が閾値Ｌを超過しないようにスケジュール調整する。例えば、第３のパッチグループの適用開始予定時刻を時刻Ｔ１２までずらすと、実行サーバ２００の負荷が閾値Ｌを超過しないように各パッチの適用が可能であるとする。バーの集合Ｇ３５ｂは、適用開始予定時刻を時刻Ｔ１２までずらして、バーの集合Ｇ３５を棒グラフＧ１０ａに積み上げたものを示している。

制御部１３０は、それ以降の他のパッチグループの適用開始予定時刻も同様にして決定する。ここで、バーの集合Ｇ３６ａは、対応するパッチグループの適用開始予定時刻を時刻Ｔ１３にずらして、バーの集合Ｇ３６を棒グラフＧ１０ａに積み上げたものである。バーの集合Ｇ３１ａは、バーの集合Ｇ３１を棒グラフＧ１０ａに積み上げたもの（ただし、一部のみ）である。バーＧ３２，Ｇ３３およびバーの集合Ｇ３４を棒グラフＧ１０ａに積み上げたものに関しては、図示を省略している。

図２０は、第２の実施の形態の確定されたスケジュールの例を示す図である。図２０（Ａ）は仮想マシン２２０の確定されたスケジュールを示す棒グラフＧ１０を例示している。図２０（Ｂ）は仮想マシン２３０の確定されたスケジュールを示す棒グラフＧ２０ａを例示している。図２０（Ｃ）は仮想マシン２４０の確定されたスケジュールを示す棒グラフＧ３０ａを例示している。棒グラフＧ１０，Ｇ２０ａ，Ｇ３０ａの横軸は時間であり、縦軸は実行サーバ２００の負荷である。棒グラフＧ１０は、図１３で説明したものと同一である。

棒グラフＧ２０ａは、図１８で説明した処理の結果、仮想マシン２３０の確定されたスケジュールを例示している。バーの集合Ｇ２６に対応するパッチグループは時刻Ｔ０から適用されることになる。バーの集合Ｇ２１に対応するパッチグループは時刻Ｔ１１から適用されることになる。それ以降、他のパッチグループが順次適用される。

棒グラフＧ３０ａは、図１９で説明した処理の結果、仮想マシン２４０の確定されたスケジュールを例示している。バーの集合Ｇ３５に対応するパッチグループは時刻Ｔ１２から適用されることになる。バーの集合Ｇ３６に対応するパッチグループは時刻Ｔ１３から適用されることになる。それ以降、他のパッチグループが順次適用される。

このようにして、実行サーバ２００の負荷が閾値Ｌを超過しないようにパッチ適用のスケジュールが調整される。このため、実行サーバ２００に対するパッチ適用の負荷の影響を軽減することができる。例えば、閾値Ｌが５０％であれば、パッチ適用中でも残り５０％のリソースを利用可能である。当該残りのリソースを用いて、仮想マシン２２０，２３０，２４０（あるいは、これらの仮想マシン以外の仮想マシン）で実行される他の業務処理を行える。上述したように、閾値Ｌは他の業務処理のために確保しておきたいリソースに応じた値が決定される。これによって、所定のリソースを確保しながら、仮想マシン２２０，２３０，２４０に対するパッチ適用を迅速に行えるように支援することができる。

ここで、パッチを実際に適用すると、スケジュール通りに進まないこともある。そこで、制御部１３０はパッチ適用の実際の進捗に応じて、スケジュールを補正する。次に、図９のステップＳ１４において実行されるスケジュールの補正の手順を説明する。

図２１は、第２の実施の形態のスケジュールの補正例を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。
（ステップＳ７１）実行部２１０は、何れかの仮想マシンについて、何れかのパッチの適用が完了すると、該当の仮想マシン、パッチを示す情報や適用完了時刻を示す情報を制御部１３０に通知する。制御部１３０は、該当の仮想マシンに対応するスケジュールテーブルの該当のパッチに対して、適用完了時刻を登録する。

（ステップＳ７２）制御部１３０は、スケジュールテーブルに基づいて、ステップＳ７１で通知された適用完了時刻に遅延があるか否かを判定する。遅延がある場合、処理をステップＳ７３に進める。遅延がない場合、処理を終了する。

（ステップＳ７３）制御部１３０は、仮想マシン２２０，２３０，２４０に対して適用予定の全てのパッチについて、開始予定時刻を現在の開始予定時刻よりも後ろにずらす。例えば、遅延した時間分だけ後ろにずらすことが考えられる。

このようにして、制御部１３０は、実際にパッチを適用しながら、その実績に基づいて更にスケジュールの調整を行う。個々のパッチの適用所要時間は、検証サーバ３００で検証した時間と必ずしも一致するとは限らないからである。制御部１３０は、実際のパッチの適用で遅延があれば、例えば遅延分の時間だけ、他のパッチの適用開始予定時刻を遅らせる。さもなければ、負荷の閾値Ｌを超過する組み合わせで各仮想マシンに対するパッチ適用が行われる可能性があるからである。

また、第２の実施の形態では、ある時点において、１つの仮想マシンに対し１つのパッチを適用するようにスケジューリングする場合を例示した。一方、パッチの適用処理の競合が問題とならないことが明らかであれば、ある時点において１つの仮想マシンに対し２以上のパッチを適用するようにスケジューリングしてもよい。例えば、仮想マシン２２０に対し、ある時点において、パッチ“Ｐ−００１”、“Ｐ−００４”を並列に適用するようにスケジューリングすることも考えられる。その場合も、各パッチを適用するための負荷を合計することで、仮想マシン２２０の負荷を見積もれる。例えば、同一の仮想マシンで並列に適用可能なパッチ数の上限を２つ、３つ、などと予め定めておく。そして、優先度の高い仮想マシンほど優先的に、より多くのパッチを並列適用するようにし、かつ、実行サーバ２００の負荷が閾値Ｌを超過しないように、第２の実施の形態と同様の方法でスケジューリングを行うことが考えられる。

なお、前述のように、第１の実施の形態の情報処理は、演算部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体（例えば、光ディスク１３、メモリ装置１４およびメモリカード１６など）に記録できる。

プログラムを流通させる場合、例えば、当該プログラムを記録した可搬記録媒体が提供される。また、プログラムを他のコンピュータの記憶装置に格納しておき、ネットワーク経由でプログラムを配布することもできる。コンピュータは、例えば、可搬記録媒体に記録されたプログラムまたは他のコンピュータから受信したプログラムを、記憶装置に格納し、当該記憶装置からプログラムを読み込んで実行する。ただし、可搬記録媒体から読み込んだプログラムを直接実行してもよく、他のコンピュータからネットワークを介して受信したプログラムを直接実行してもよい。

また、上記の情報処理の少なくとも一部を、ＤＳＰ、ＡＳＩＣ、ＰＬＤなどの電子回路で実現することもできる。

１，２ 情報処理装置
１ａ 記憶部
１ｂ 演算部
２ａ，２ｂ 仮想マシン
３，４，５ 棒グラフ
３ａ，３ｂ，３ｃ，３ｄ，３ｅ，３ｆ，４ａ，４ｂ，４ｃ，４ｄ，４ｅ，４ｆ バー

Claims (7)

1. 第１の仮想マシンおよび第２の仮想マシンが動作可能な情報処理装置と通信するコンピュータに、
   更新プログラムを前記第１の仮想マシンに適用するときの前記情報処理装置の負荷を示す第１の情報と前記更新プログラムを前記第２の仮想マシンに適用するときの前記情報処理装置の負荷を示す第２の情報とを、複数の更新プログラムそれぞれに対して取得し、
   前記第１の情報と前記第２の情報と前記情報処理装置で許容される負荷の上限とに基づいて、所定期間内に前記複数の更新プログラムを前記第１の仮想マシンに適用するときの第１の適用順序と、前記所定期間内に前記複数の更新プログラムを前記第２の仮想マシンに適用するときの第２の適用順序であって、前記第１の適用順序とは異なる前記第２の適用順序とを決定する、
   処理を実行させるプログラム。
2. 前記第１の仮想マシンおよび前記第２の仮想マシンに並列に適用する前記更新プログラムの組に対して評価された前記情報処理装置の負荷が前記上限以下である場合に前記更新プログラムの組を並列に適用することを許容し、前記更新プログラムの組に対して評価された前記情報処理装置の負荷が前記上限よりも大きい場合に前記更新プログラムの組を並列に適用することを許容しない、請求項１記載のプログラム。
3. 前記情報処理装置では、前記第１の仮想マシンと前記第２の仮想マシンと前記更新プログラムの適用対象でない１以上の仮想マシンとが動作しており、また、前記情報処理装置の負荷は前記更新プログラムを適用する際の前記情報処理装置のリソースの利用率であり、
   前記１以上の仮想マシンに対するリソースの割当に関する情報に基づいて前記上限を決定する、請求項１または２記載のプログラム。
4. 前記１以上の仮想マシンに対して割当可能な最大のリソースの合計に基づいて前記上限を決定する、請求項３記載のプログラム。
5. 前記１以上の仮想マシンに対して現在割当てられているリソースの合計に基づいて前記上限を決定する、請求項３記載のプログラム。
6. 第１の仮想マシンおよび第２の仮想マシンが動作可能な他の情報処理装置と通信する情報処理装置であって、
   更新プログラムを前記第１の仮想マシンに適用するときの前記他の情報処理装置の負荷を示す第１の情報と前記更新プログラムを前記第２の仮想マシンに適用するときの前記他の情報処理装置の負荷を示す第２の情報とを、複数の更新プログラムそれぞれに対して記憶する記憶部と、
   前記記憶部から前記第１の情報と前記第２の情報とを取得し、前記第１の情報と前記第２の情報と前記他の情報処理装置で許容される負荷の上限とに基づいて、所定期間内に前記複数の更新プログラムを前記第１の仮想マシンに適用するときの第１の適用順序と、前記所定期間内に前記複数の更新プログラムを前記第２の仮想マシンに適用するときの第２の適用順序であって、前記第１の適用順序とは異なる前記第２の適用順序とを決定する演算部と、
   を有する情報処理装置。
7. 第１の仮想マシンおよび第２の仮想マシンが動作可能な情報処理装置と通信するコンピュータで実行されるスケジュール決定方法であって、
   更新プログラムを前記第１の仮想マシンに適用するときの前記情報処理装置の負荷を示す第１の情報と前記更新プログラムを前記第２の仮想マシンに適用するときの前記情報処理装置の負荷を示す第２の情報とを、複数の更新プログラムそれぞれに対して取得し、
   前記第１の情報と前記第２の情報と前記情報処理装置で許容される負荷の上限とに基づいて、所定期間内に前記複数の更新プログラムを前記第１の仮想マシンに適用するときの第１の適用順序と、前記所定期間内に前記複数の更新プログラムを前記第２の仮想マシンに適用するときの第２の適用順序であって、前記第１の適用順序とは異なる前記第２の適用順序とを決定する、
   スケジュール決定方法。
   

Images