JP5655612B2 - 情報処理システム、情報処理方法、及び制御プログラム - Google Patents

Description

本発明は、情報処理システム、情報処理方法、及び制御プログラムに関する。

サーバの仮想化が知られている。サーバの仮想化とは、サーバが仮想化ソフトウェアを実行することで、１台のサーバで複数のＯＳ（Operating System）の実行を可能にする技術である。サーバの仮想化は、複数のＯＳのそれぞれに１台のサーバのハードウェアリソースを割り当てることで実現され、このようにして実行されるＯＳを「ゲストＯＳ」と呼ぶ。また、サーバの仮想化のために、サーバが実行する仮想化プログラムの基盤となるＯＳを「ホストＯＳ」と呼ぶ。

ハードウェアリソースの割り当ては、ゲストＯＳ毎のＣＰＵ（Central Processing Unit）使用率の割り当て、又は、ゲストＯＳ毎のメモリ又はディスク装置への入出力の割り当てがある。ゲストＯＳ実行用に割り当てられたハードウェアリソースは、仮想マシン（ＶＭ：Virtual Machine）と呼ぶ。「仮想マシン」との対比として、仮想化ソフトウェアを実行するとともにハードウェアリソースを提供するサーバを、「物理サーバ」と呼ぶ。

ゲストＯＳは、物理サーバで実行されるＯＳと同じＯＳを実行することができる。そのため、ゲストＯＳに対して、パッチプログラムを適用する場合も、物理サーバが実行するＯＳに対してパッチプログラムが適用される場合と同様の処理がなされる。なお、パッチプログラムとは、プログラムの一部分を更新してバグの修正や機能変更を行うためのプログラムであり、以下「パッチ」と呼ぶ。

パッチ適用法としては、ＷＳＵＳ（Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｅｒ Ｕｐｄａｔｅ Ｓｅｒｖｉｃｅｓ）が知られている。ＷＳＵＳは、パッチ管理サーバ上にパッチを格納し、システム管理者が選択したパッチを、パッチ管理サーバから他のサーバに適用したり、他のサーバへの適用状況を、パッチ管理サーバで管理したりするシステムである。

特開２００６−９９３０７号公報

パッチは、サーバ１つずつに分けて適用される。パッチを１つずつ割り当てる場合、パッチ未適用サーバが増えると、全ての対象サーバに対するパッチ適用までに多くの時間がかかる。

さらに、業務システムの様に各サーバが互いに関係性を持っている場合には、関係性を持ったサーバ全てに対して同じＯＳのバージョンを適用する必要がある。その場合、一方のサーバにパッチがあたっているが、もう一方のサーバにはパッチが当たっていない状態が生じ、パッチ未適用の全サーバに対してパッチの適用が終了するまで、業務システムが正常に動作しないといったことが発生する。

１つの側面では、本発明は、パッチを適用すべきプログラムを実行する仮想サーバを備えた複数のサーバに関して、パッチ適用を行なうことを目的とする。

一実施形態によれば、パッチデータを記憶するリポジトリサーバに接続される、複数のサーバを備える情報処理システムであって、前記複数のサーバの各々は、記憶部と、パッチ管理部と、を有する情報処理システムが提供される。

前記記憶部は、前記複数のサーバについて、それぞれのサーバ上で起動される仮想マシンと、前記仮想マシンで実行されるプログラムとの対応関係を記憶する。前記パッチ管理部は、前記プログラムに適用されていない未適用パッチデータを、前記リポジトリサーバに問合せる。

前記複数のサーバのうち１つのサーバの第１パッチ管理部は、前記リポジトリサーバから未適用パッチデータを受信した場合に、前記対応関係に基づいて、他のサーバの仮想マシンであって、前記未適用パッチデータの適用対象となる適用対象プログラムを実行する仮想マシンに対して、前記未適用パッチデータの適用を要求する。前記他のサーバの第２パッチ管理部は、前記要求に応じて、未適用のパッチデータを前記適用対象プログラムに適用する。

パッチを適用すべきプログラムを実行する仮想サーバを備えた複数のサーバに関して、パッチ適用を行なうことができる。

図１は、パッチ管理サーバをシステム外部に配置する例を説明する図である。 図２は、情報処理システムの一例を説明するシステム構成図である。 図３は、情報処理システムに含まれる物理サーバのハードウェア構成の一例を示す図である。 図４は、記憶部のメモリマップの一例を示す図である。 図５は、物理サーバと仮想マシンの機能構成の一例を示す図である。 図６は、ソフト管理データの一例を示す図である。 図７は、グループ管理データの一例を示す図である。 図８は、ＶＭ管理データの一例を示す図である。 図９Ａは、マスタ管理部が、リポジトリサーバに未適用パッチの問合せる処理の一例を示すフローチャートである。 図９Ｂは、パッチ管理部が、リポジトリサーバ５０にマスタパッチ管理部の宣言を行う処理の一例を示すフローチャートである。 図９Ｃは、パッチ管理部が、スナップショットを作成する処理の一例を示すフローチャートである。 図９Ｄは、パッチ適用処理の一例を示すフローチャートである。 図９Ｅは、パッチ適用処理の一例を示すフローチャートである。 図９Ｆは、再起動処理の一例を示すフローチャートである。 図９Ｇは、再起動処理の一例を示すフローチャートである。

図１は、パッチ管理サーバをシステム外部に配置する例を説明する図である。パッチ対象を管理する場合は、図１に示すように、管理対象ゲストＯＳの外部に、パッチ管理サーバ２０００Ａ及び２０００Ｂを置く構成がある。パッチ管理サーバ２０００Ａ及び２０００Ｂは、物理サーバ２２００Ａ又は２２００Ｂ上で実行する仮想マシン２３００Ａ〜２３００Ｆを管理する。この場合、パッチ管理サーバ２０００Ａ及び２０００Ｂは、パッチ管理用の専用サーバである。また、一台だけでは、この一台がダウンしてしまうと、管理できなくなるため、パッチ管理サーバ２０００Ａ及び２０００Ｂは、クラスタ化するなどして、管理を継続できるような構成をとる。このように、パッチ管理サーバをシステム外部に配置する場合、複数台のサーバ資源を必要としていた。

以下に示す、情報処理システムは、物理サーバ内に、パッチ管理部を設けることで、情報処理システムにパッチ管理用の専用サーバを設けない構成を有する。さらに、物理サーバ上で実行する複数のゲストＯＳへのパッチ適用を一斉に行うことが出来る。

以下、図面を参照して、〔１〕情報処理システムのシステム構成、〔２〕情報処理システムのハードウェア構成、〔３〕データ構造、及び〔４〕情報処理システムが実行するパッチ制御処理のフローを順に説明する。

〔１〕情報処理システムの機能構成
図２は、情報処理システムの一例を説明するシステム構成図である。図２に示される情報処理システム１００は、物理サーバ２００Ａ及び２００Ｂを有する。物理サーバ２００Ａ及び２００Ｂは、ホストＯＳ４００Ａ及び４００Ｂをそれぞれ実行する。ホストＯＳは、ゲストＯＳを管理する特権を有するゲスト管理用のＯＳである。ホストＯＳは、物理サーバのハードウェア資源に直接アクセスするためのデバイスドライバ等を有する。物理サーバは、図５を用いて後述する仮想化プログラムを実行することで、ホストＯＳ、及びゲストＯＳを、実行する。

さらに、物理サーバ２００Ａ及び２００Ｂは、ホストＯＳ４００Ａ及び４００Ｂ上で、後述する制御プログラムを実行することで、パッチ管理部４２０Ａ及び４２０Ｂとして機能する。また、物理サーバ２００Ａは、仮想マシン５００Ａ及び５００Ｂで制御プログラムを実行することで、パッチ適用部５３０Ａ及び５３０Ｂとして機能する。

情報処理システム１００は、インターネットやＬＡＮ（Local Area Network）等であるネットワーク５を介して、リポジトリサーバ５０と接続する。リポジトリサーバ５０は、パッチや修正が適用されたソフトウェアが登録されているサーバである。リポジトリサーバ５０には、パッチが、そのバージョンとともに、体系立てて登録されている。

物理サーバ２００Ａ及び２００Ｂは、ゲストＯＳと、ゲストＯＳ上で実行されるプログラムとの対応関係を規定するソフト管理データ、グループ毎にゲストＯＳと仮想マシンとの対応関係を規定するグループ管理データ、仮想マシンと物理サーバとの対応関係を規定するＶＭ管理データを、ホストＯＳに割り当てられた記憶部に記憶する。ソフト管理データは、グループ管理データ、及びＶＭ管理データは、総称して「管理データ」と呼ぶ。ソフト管理データ、グループ管理データ、及びＶＭ管理データの詳細は、それぞれ図６、図７、及び図８を用いて後述する。

情報処理システム１００は、ソフト管理データ４３０でゲストＯＳ毎に対応付けて規定されるソフトウェアのパッチの適用の有無を、リポジトリサーバ５０に問合せる。リポジトリサーバ５０は、ゲストＯＳ毎に新たに適用すべきパッチを情報処理システム１００に通知する。この問合せは、情報処理システム１００が、アプリケーションの識別情報及びゲストＯＳの識別情報を、リポジトリサーバ５０に送信することで、行なわれる。このように、情報処理システム１００は、リポジトリサーバ５０に、パッチの適用について問合せることで、仮想マシン５００Ａ〜５００Ｄに適用すべきパッチを、確認することができる。

以下、パッチ管理部４２０Ａ及び４２０Ｂの機能を、説明する。

Ａ．リポジトリサーバへ定期的に問合せするパッチ管理部の機能
各パッチ管理部は、ソフト管理データ４３０を参照して、リポジトリサーバ５０に定期的に、ソフト管理データ４３０に登録されるソフトウェア名をそのバージョンとともに問合せることで、未適用パッチの有無に関する問合せを行う。問合せの単位は、グループ毎に行なう。図２において、グループは、１１０で示される。グループとは、関係性のあるゲストＯＳ又は物理サーバ群をまとめたものである。例えば、業務システムを構成するゲストＯＳ群をグループとする。１１０に示すように、複数の物理サーバを跨いでゲストＯＳをグループ化することができる。なお、１１０に示すように、ゲストＯＳとグループとの対応関係は、図７を用いて後述するグループ管理データ４４０に登録される。

ソフト管理データ４３０及びグループ管理データ４４０は、各パッチ管理部が同期を取ることで、各パッチ管理部が同じソフト管理データ４３０及び同じグループ管理データ４４０にアクセスする。または、ソフト管理データ４３０及びグループ管理データ４４０を、図２に図示されない共用ディスク上に置くことで、各パッチ管理部が、同じ管理データでパッチ管理ができるものとする。

問合せを行なったパッチ管理部は、リポジトリサーバ５０から、未適用パッチの情報に関する応答を受信する。問合せをした結果、最初に未適用パッチの確認をしたパッチ管理部を、以降、マスタパッチ管理部と呼ぶ。そして、他のパッチ管理部を、以降、サブパッチ管理部と呼ぶ。

Ｂ．パッチ適用を待ち合わせるパッチ管理部の機能
マスタパッチ管理部は、リポジトリサーバ５０から応答を受信すると、ソフト管理データ４３０を参照して、未適用パッチに対応するソフトウェアが実行されるゲストＯＳを特定することで、パッチ未適用のゲストＯＳを特定する。また、マスタパッチ管理部は、パッチ未適用のゲストＯＳを含むグループを、グループ管理データ４４０を参照して特定する。マスタパッチ管理部は、ＶＭ管理データ４５０を参照して、該当グループに属するゲストＯＳを実行する物理サーバ上を特定する。ＶＭ管理データ４５０は、物理サーバと、仮想マシンとの対応関係を規定する情報であり、図８を用いて後述される。

このようにして、マスタパッチ管理部は、リポジトリサーバ５０から未適用パッチの応答を受信すると、パッチ未適用のゲストＯＳ、パッチ未適用のゲストＯＳを含むグループ、及びパッチ未適用のゲストＯＳを実行する仮想マシン及び物理サーバを特定する。マスタパッチ管理部は、グループに属しているパッチ未適用のゲストＯＳを管理しているサブパッチ管理部を特定し、各サブパッチ管理部に、パッチ未適用のゲストＯＳを特定する未適用ゲストＯＳ情報を送信する。また、マスタパッチ管理部は、パッチ未適用のゲストＯＳを含むグループと、グループに属している自物理サーバ上のパッチ未適用のゲストＯＳを特定する。

未適用ゲストＯＳ情報を受信したサブパッチ管理部は、マスタパッチ管理部と同様に、パッチ未適用のゲストＯＳを含むグループと、グループに属している自物理サーバ上のパッチ未適用のゲストＯＳを特定する。ゲストＯＳを特定後、サブパッチ管理部は、マスタパッチ管理部にレスポンスを返すことで、パッチ適用の待ち合わせを行う。

各サブパッチ管理部からレスポンスがあり、パッチ適用の待ち合わせが完了した場合、マスタパッチ管理部は、サブパッチ管理部にパッチ適用リクエストを送信する。パッチ適用リクエストは、未適用パッチを含む。その後、マスタパッチ管理部は、自物理サーバ上のグループ内の全パッチ未適用のゲストＯＳに対してパッチ適用リクエストを送信する。

パッチ適用リクエストを受けたサブパッチ管理部も、マスタパッチ管理部と同様に、自物理サーバ上のグループ内の全ゲストＯＳに対してパッチ適用リクエストを送信する。リクエストを受信した各パッチ未適用のゲストＯＳは、パッチ適用リクエストに含まれる未適用パッチを適用する。

Ｃ．再起動を待ち合わせるためのパッチ管理部の機能
各ゲストＯＳは、パッチ適用後の再起動の有無を示す再起動情報を、自サブパッチ管理部に返す。サブパッチ管理部は、全てのパッチを適用したゲストＯＳから、再起動情報を受けた後にマスタパッチ管理部に全ゲストＯＳの再起動情報を返す。マスタパッチ管理部は、全てのサブパッチ管理部から再起動情報の返信があるまで待ち合わせを行なうことで、再起動の待ち合わせ処理を行う。なお、再起動情報は、パッチ完了後、ゲストＯＳがパッチの種類に応じて決まる再起動が必要かどうかを監視することで判断される。

マスタパッチ管理部が、サブパッチ管理部から再起動情報を受信することで、待ち合わせ処理を完了したら、サブパッチ管理部から自物理サーバ上のゲストＯＳへ、及び、マスタパッチ管理部から自物理サーバ上のゲストＯＳへ再起動リクエストを送信する。このようにすることで、情報処理システム１００は、パッチ適用および、再起動を一斉に実行できるようになる。

次に、上述した機能を説明するフローを、図２に示すＳ１〜Ｓ１９に基づいて、説明する。

Ｓ１．パッチ管理部４２０Ｂが、ソフト管理データ４３０を参照する。

Ｓ２．パッチ管理部４２０Ｂは、ソフト管理データ４３０を元にリポジトリサーバ５０へ、ソフト管理データ４３０に登録されるソフトウェア名をそのバージョンとともに送信して、未適用パッチの有無を問合せする。

Ｓ３．未適用パッチがあった場合は、パッチ管理部４２０Ｂは、ソフト管理データ４３０を参照して、その未適用パッチがどのゲストＯＳが対象か特定する。パッチ管理部４２０Ｂは、パッチ未適用のゲストＯＳを特定すると、グループ管理データ４４０を参照して、パッチ未適用のゲストＯＳがどのグループに属するかを判断する。パッチ管理部４２０Ｂは、ＶＭ管理データ４５０を参照して、他の物理サーバにある該当グループに属するパッチ未適用のゲストＯＳを特定する。

Ｓ４．他の物理サーバ上にゲストＯＳが存在する場合、その各物理サーバ上のパッチ管理部４２０Ａに該当グループ及びゲストＯＳ情報を通知する。この通知の送信元と送信先の関係がマスタパッチ管理部とサブパッチ管理部との関係となる。Ｓ４では、マスタパッチ管理部が、例えば、ＨＴＴＰ（Hypertext Transfer Protocol）メソッドのＰＵＴを用いて、パスに“／ｇｕｅｓｔ”、引数に、“Ｉｎｆｏ＝＜ゲストＯＳ情報＞”、“ｇｒｏｕｐ＝＜グループ情報＞”を指定することで、パッチ管理部４２０Ａに該当グループ及びゲストＯＳ情報を通知する。

Ｓ５．マスタパッチ管理部４２０ＢからのゲストＯＳ情報を元にサブパッチ管理部が管理するパッチ未適用のゲストＯＳを特定する。サブパッチ管理部４２０Ａは、マスタパッチ管理部４２０Ｂにレスポンスを返す。

Ｓ６．マスタパッチ管理部４２０Ｂは、各サブパッチ管理部からのレスポンスを待ち合わせる。

Ｓ７．マスタパッチ管理部４２０Ｂは、サブパッチ管理部４２０Ａにスナップショット作成のリクエストを送信する。スナップショットとは、パッチ適用対象のプログラムを、後述する補助記憶部にバックアップすることである。パッチを適用する前に、パッチ適用対象プログラムのスナップショットをとることで、パッチ適用失敗時には、パッチ適用前にもどすことが可能になる。Ｓ７では、マスタパッチ管理部は、例えば、ＨＴＴＰメソッドのＰＯＳＴを用いて、パスに“／ｓｎａｐｓｈｏｔ”、引数に、“ｇｕｅｓｔ＝＜ｓｎａｐｓｈｏｔ対象ゲストＯＳ＞”を指定することで、スナップショット作成のリクエストを送信する。

Ｓ８．サブパッチ管理部４２０ＡはゲストＯＳのスナップショットを作成し、完了後、マスタパッチ管理部４２０Ｂにレスポンスを返す。スナップショットは、例えば、仮想化ソフトウェアのコマンドを用いて行うことができる。マスタパッチ管理部４２０Ｂは、Ｓ７を実施後、サブパッチ管理部４２０Ａと同様にスナップショットを作成する。

Ｓ９．マスタパッチ管理部４２０Ｂは、各サブパッチ管理部からのレスポンスを待ち合わせる。

Ｓ１０．マスタパッチ管理部４２０Ｂは、サブパッチ管理部４２０Ａにパッチ適用のリクエストを送信する。Ｓ１０では、マスタパッチ管理部４２０Ｂが、例えば、ＨＴＴＰメソッドのＰＯＳＴを用いて、パスに“／ｓｕｂｍａｎａｇｅｒ／ｐａｔｃｈ”を指定することで、パスで指定されるフォルダにパッチが格納される。

Ｓ１１．サブパッチ管理部４２０Ａは、自物理サーバである物理サーバ２００Ａ内のゲストＯＳにパッチ適用のリクエストを送信する。マスタパッチ管理部４２０Ｂも、同様に、自物理サーバである物理サーバ２００Ｂ内のゲストＯＳにパッチ適用リクエストを送信する。パッチ管理部からゲストＯＳへのパッチ適用リクエストは、ＨＴＴＰメソッドのＰＯＳＴを用いて、パスに“／＜対象ｇｕｅｓｔＯＳ（Ｄｏｍａｉｎ名）＞／ｐａｔｃｈ”を指定することで、パスで指定されるフォルダにパッチが格納される。

Ｓ１２．ゲストＯＳは、パッチを適用する。各パッチ適用部は、パッチ適用後の再起動の有無を監視する。

Ｓ１３．パッチ適用部は、再起動の有無を特定する再起動情報を、サブパッチ管理部４２０Ａ、及びマスタパッチ管理部４２０Ｂにそれぞれ通知する。

Ｓ１４．マスタパッチ管理部４２０Ｂは、各サブパッチ管理部からの再起動情報の送信を待つ。

Ｓ１５．各サブパッチ管理部及び自物理サーバのパッチ適用部から再起動情報を受信すると、マスタパッチ管理部４２０Ｂは、サブパッチ管理部４２０Ａに再起動のリクエストを送信する。マスタパッチ管理部４２０Ｂからサブパッチ管理部４２０Ａへの再起動リクエストの送信は、ＨＴＴＰメソッドのＰＵＴを用いて、パスに“／ｓｕｂｍａｎａｇｅｒ／ｒｅｂｏｏｔ”を指定することで、行なわれる。

Ｓ１６．サブパッチ管理部４２０Ａは、自物理サーバである物理サーバ２００Ａ上のゲストＯＳに再起動のリクエストを送信する。マスタパッチ管理部４２０Ｂも、自物理サーバである物理サーバ２００Ｂ上のゲストＯＳに再起動のリクエストを送信する。パッチ管理部からゲストＯＳへの再起動リクエストは、ＨＴＴＰメソッドのＰＯＳＴを用いて、パスに“／＜対象ｇｕｅｓｔＯＳ（Ｄｏｍａｉｎ名）＞／ｒｅｂｏｏｔ”を指定することで、行なわれる。

Ｓ１７．物理サーバ２００Ａ及び２００Ｂは、再起動を実施する。

Ｓ１８．物理サーバ２００Ａ及び２００Ｂの再起動後、パッチ適用部はそれぞれ、サブパッチ管理部４２０Ａまたは、マスタパッチ管理部４２０Ｂに再起動完了レスポンスを返す。

Ｓ１９．マスタパッチ管理部４２０Ｂはサブパッチ管理部４２０Ａから再起動完了レスポンスを受け取り、再度Ｓ１に戻り処理を継続する。

上記のように、情報処理システム１００は、グループ毎に、複数ＯＳへのパッチ適用を一斉に行なうとともに、物理サーバの再起動を一斉に実施できる。

また、情報処理システム１００は、パッチ適用部の数が多くなればなるほど、Ｓ２における問合せ頻度が上がるので、リポジトリサーバ５０への問合せがリアルタイムに近くなる。また、情報処理システム１００では、どの物理サーバのパッチ管理部もマスタパッチ管理部になり得る。リポジトリサーバ５０への問合せが１０秒間隔で物理サーバ１台とした場合は１０秒間隔だが、物理サーバを１０台とした場合、１秒間隔でリポジトリサーバに問合せすることができ、物理サーバが増えるほど、ゲストＯＳへの最新のパッチ適用を迅速化できる。

さらに、情報処理システム１００は、ゲストＯＳにパッチを適用する前に、ゲストＯＳのスナップショットをとっているため、失敗時には、パッチ適用前の状態にもどすことが可能である。

また、情報処理システム１００は、どのパッチ管理部もマスタパッチ管理部となることができるため、１つのマスタパッチ管理部の負荷が高くなるということがなくなる。

さらに、情報処理システム１００は、物理サーバ２００Ａ及び２００Ｂ以外に、パッチ管理部を外側の専用サーバに置くことがないため、物理サーバを余計に準備することはない。

〔２〕情報処理システムのハードウェア構成
次に、情報処理システムのハードウェア構成について説明する。図３は、情報処理システムに含まれる物理サーバのハードウェア構成の一例を示す図である。図３に示すように、物理サーバ２００は、処理部２１０、記憶部２２０、通信部２３０、補助記憶部２４０、ドライブ部２５０、及びＩ／Ｏコントローラ２６０を有する。図３に示す物理サーバ２００は、図２に示す物理サーバ２００Ａ及び２００Ｂに相当する。

処理部２１０は、Ｉ／Ｏコントローラ２６０を介して、通信部２３０、補助記憶部２４０、及びドライブ部２５０に接続する。処理部２１０は、記憶部２２０に記憶されたプログラムを実行することで、記憶部２２０からデータをロードし、ロードしたデータを演算して、記憶部２２０に演算結果をストアする。処理部２１０は、例えば、ＣＰＵである。

Ｉ／Ｏコントローラ２６０は、処理部２１０と、他の接続装置との接続を制御する装置である。Ｉ／Ｏコントローラ２６０は、例えば、ＰＣＩ Ｅｘｐｒｅｓｓ（Peripheral Component Interconnect Express）などの規格に従って動作する。

記憶部２２０は、データやプログラムを記憶する装置である。記憶部２２０は、例えば、ＤＲＡＭ（Dynamic Random Access Memory）である。記憶部２２０に記憶される各データについては、図４を用いて後述する。

通信部２３０は、ネットワーク５に接続された他の物理サーバとの間でデータを送受信する装置である。通信部２３０は、例えば、ＮＩＣ（Network Interface Controller）である。

補助記憶部２４０は、記憶部２２０に格納されるプログラム及びデータを記憶する非揮発性の装置である。補助記憶部２４０は、磁気ディスクを用いたディスクアレイ、又は、フラッシュメモリを用いたＳＳＤ（Solid State Drive）等である。

ドライブ部２５０は、例えば、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＤＶＤ（Digital Versatile Disc）などの記憶媒体２９０を読み書きする装置である。ドライブ部２５０は、記憶媒体２９０を回転させるモータや記憶媒体２９０上でデータを読み書きするヘッド等を含む。なお、記憶媒体２９０は、制御プログラムを格納することができる。ドライブ部２５０は、ドライブ部２５０にセットされた記憶媒体２９０から制御プログラムを読み出す。処理部２１０は、ドライブ部２５０により読み出された制御プログラムを、記憶部２２０又は補助記憶部２４０に格納する。

図４は、記憶部のメモリマップの一例を示す図である。図４に示すように、記憶部２２０は、ソフト管理データ４３０、グループ管理データ４４０、ＶＭ管理データ４５０、仮想化ソフトウェア９１０、制御プログラム９２０、ＯＳ９３０Ａ及び９３０Ｂ、プログラム９９０Ａ及び９９０Ｂを格納する。

制御プログラム９２０は、物理サーバ２００Ａ及び２００Ｂを、ホストＯＳ４００Ａ及び４００Ｂ上のパッチ管理部４２０Ａ及び４２０Ｂとして機能させるためのプログラムである。また、制御プログラム９２０は、仮想マシン５００Ａ及び５００Ｂを、パッチ適用部５３０Ａ及び５３０Ｂとして機能させるためのプログラムである。

ソフト管理データ４３０は、ゲストＯＳ及びそのゲストＯＳ上で実行されるアプリケーション等のプログラムと、そのプログラムに対して適用すべきパッチとの対応関係を規定するデータである。ソフト管理データ４３０の詳細は、図６を用いて後述する。

グループ管理データ４４０は、ゲストＯＳとグループとの対応関係を規定する情報である。グループ管理データ４４０の詳細は、図７を用いて後述する。

ＶＭ管理データ４５０は、物理サーバと、仮想マシンとの対応関係を規定する情報である。ＶＭ管理データ４５０の詳細は、図８を用いて後述する。

仮想化ソフトウェア９１０は、１台の物理サーバ２００により複数のＯＳの実行を可能にするソフトウェアである。仮想化ソフトウェア９１０は、コンピュータのハードウェア資源であるＣＰＵ、メモリ、ディスク装置に対するＩ／Ｏ（Input/Output）を、各ゲストＯＳに割り当てる。仮想化ソフトウェア９１０は、記憶部２２０の記憶領域を、各ゲストＯＳに割り当て、又は、処理部２１０の処理時間を各ゲストＯＳに割り当て、又は、補助記憶部２４０のＩ／Ｏを各ゲストＯＳに割り当てる。

また、仮想化ソフトウェア９１０は、ゲストＯＳからハードウェア資源に対するデータの入出力を受け取り、他のゲストＯＳとの競合を調停する処理を実行してから、受け取った情報を用いてハードウェア資源を使用する。

ＯＳ９３０Ａ及び９３０Ｂは、ゲストＯＳとして実行されるＯＳである。通常、ＯＳとは、キーボード入力や画面出力といった入出力機能やディスクやメモリの管理など、多くのアプリケーションから共通して利用される基本的な機能を提供し、ハードウェア資源全体を管理するソフトウェアである。しかしながら、仮想化ソフトウェア９１０は、物理サーバ２００のハードウェア資源に対する制御を管理し、ゲストＯＳであるＯＳ９３０Ａ及び９３０Ｂにハードウェア資源を割り当てる。よって、ＯＳ９３０Ａ及び９３０Ｂは、仮想化ソフトウェア９１０によって割り当てられたハードウェア資源を管理するように動作する。ＯＳ９３０Ａ及び９３０Ｂは、例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｅｒである。ＯＳ９３０Ａ及び９３０Ｂは、パッチデータの適用対象となるプログラムであってもよい。

プログラム９９０Ａ及び９９０Ｂは、ＯＳ９３０Ａ及び９３０Ｂとともにそれぞれ実行されるプログラムであり、パッチデータの適用対象となるプログラムである。プログラム９９０Ａ及び９９０Ｂは、文書の作成、数値計算等、ある特定の目的のために設計されたアプリケーションソフトウェア、又は物理サーバの各種ハードウェアとデータの入出力を行うプログラムであるデバイスドライバである。例えば、プログラム９９０Ａは、ドライブ部２５０とデータの入出力を行うデバイスドライバであり、プログラム９９０Ｂは、通信部２３０とデータの入出力を行うデバイスドライバである。

なお、ゲストＯＳ上で実行されるアプリケーションプログラムと、ゲストＯＳとの対応関係は、ソフト管理データ４３０に登録されている。

図５は、物理サーバとゲストＯＳとホストＯＳとの機能構成の一例を示す図である。仮想化ソフトウェアは、各ゲストＯＳのディスパッチ、各ゲストＯＳが実行する特権命令のエミュレーション、ＣＰＵに関するハードウェア制御等を行う。ＶＭシステムのブート時に最初に動作し、ホストＯＳの起動を行う。仮想化ソフトウェアを実行することで、物理サーバ上に仮想計算機モニタ９１５が実現する。

ホストＯＳ４００Ａは、ＶＭシステム全体の操作、管理を行う。ＶＭシステムのブート時に仮想計算機モニタ９１５により自動で起動され、ゲストＯＳの制御（起動・停止等全て）の制御を行う。ゲストＯＳに割り当てる資源（ＣＰＵ、メモリ、ＩＯ）を管理する。ゲストＯＳ５２０Ａ又は５２０Ｂが実行したＩＯもホストＯＳ４００Ａを介して物理サーバ２００に送られる。

ゲストＯＳ５２０Ａ及び５２０Ｂは、通常のＯＳである。ホストＯＳにより起動される。物理サーバ２００へのＩＯはホストＯＳ４００Ａを介して実行されるため、ゲストＯＳ５２０Ａ及び５２０Ｂは、実のＩＯは持たず、仮想的なＩＯのみが割当てられている。

〔３〕データ構造
以下に、記憶部２２０に記憶されるソフト管理データ４３０、グループ管理データ４４０、ＶＭ管理データ４５０を説明する。

図６は、ソフト管理データの一例を示す図である。図６に示すソフト管理データ４３０は、ゲストＯＳが依存するグループ毎に複数用意される。図６では、ソフト管理データ４３０として、グループＡのソフト管理データ４３０Ａ〜グループＮのソフト管理データ４３０Ｎが示される。グループＡのソフト管理データ４３０Ａについて説明するが、他のグループのソフト管理データもソフト管理データ４３０Ａと同じデータ構造を有する。ソフト管理データ４３０Ａは、ソフトＩＤが登録されるソフトＩＤ列４３１、ソフトウェア名が登録されるソフト名列４３２、ソフト名列４３２に登録されるソフトウェアがインストールされているか否かを登録するゲストＯＳＩＤ列４３３を有する。グループは、複数のゲストＯＳを関係付けるため、ゲストＯＳＩＤ列は、複数個ある。ソフト管理データ４３０において、同じエントリ（行）で、それぞれの列に登録されたデータは、互いに対応付けられるデータである。ソフト名列４３２には、ソフトウェア名がそのバージョンとともに登録される。ゲストＯＳＩＤ列４３３には、対応するソフトウェアがインストールされているか否かを示す「Ｔｒｕｅ」又は「Ｆａｌｓｅ」が登録される。

パッチ管理部は、リポジトリサーバ５０に問合せる時は、ソフト管理データ４３０に登録されるソフトウェア名をそのバージョンとともに問合せる。問合せたソフトウェアのパッチがあった場合は、パッチ管理部は、ソフト管理データ４３０を参照して、該当ソフトウェア名からゲストＯＳＩＤを取得する。パッチ管理部は、ゲストＯＳへのパッチ適用後は、バージョンを含むソフトウェア名を更新する。

図７は、グループ管理データの一例を示す図である。図７に示すグループ管理データ４４０は、ゲストＯＳが依存するグループ毎に複数用意される。図７では、グループＡのグループ管理データ４４０Ａ〜グループＮのグループ管理データ４４０Ｎが示される。グループＡのグループ管理データ４４０Ａについて説明するが、他のグループのグループ管理データも同じグループ管理データ４４０Ａとデータ構造を有する。グループ管理データ４４０は、グループ名が登録されるグループ名列４４１、ゲストＯＳが登録されるゲストＯＳＩＤ列４４２、仮想マシンを識別するドメイン名が登録されるドメイン名列４４３、ＯＳ種別が登録されるＯＳ種別列４４４を有する。ドメイン名は、仮想マシンの名称であり、例えば、仮想マシンと、仮想マシンの仮想ＭＡＣアドレスとを組み合わせた名称である。グループは、複数のゲストＯＳを関係付けるため、ゲストＯＳＩＤ列は、複数個ある。グループ管理データ４４０において、同じエントリ（行）で、それぞれの列に登録されたデータは、互いに対応付けられるデータである。図７では、ＯＳ種別列４４４には、「Ｗｉｎｄｏｗｓ（登録商標）」、「Ｌｉｎｕｘ（登録商標）」などの名称が入力されるが、ＯＳ種別列４４４には、ＯＳのバージョンもＯＳ名称とともに登録される。

パッチ管理部は、グループ管理データ４４０を参照することで、リポジトリサーバ５０から取得したゲストＯＳＩＤから、当該ゲストＯＳＩＤに対応するグループ及びドメイン名を特定することができる。

図８は、ＶＭ管理データの一例を示す図である。図８に示されるＶＭ管理データ４５０は、仮想マシンがどの物理サーバ上にあるか否かを特定する情報である。ＶＭ管理データ４５０は、物理サーバを特定する物理サーバ列４５１と、同じエントリ上の物理サーバ上にある仮想マシンを特定するドメイン名列４５２Ａ〜４５２Ｈとを有する。

パッチ管理部は、ＶＭ管理データ４５０を参照することで、グループ管理データ４４０で特定したドメイン名を元に、パッチ未適用の仮想マシンが、どの物理サーバ上にあるかを特定することができる。

以上のように、ソフト管理データ４３０を用いて、ゲストＯＳ上で実行されるプログラムを特定し、プログラムが特定できれば、グループ管理データ４４０を用いて、特定されたプログラムに対応する仮想マシンを特定できる。そのため、パッチ管理部は、ソフト管理データ４３０に規定されるプログラムに適用されていない未適用パッチデータを、リポジトリサーバ５０に問合せ、グループ管理データ４４０を参照して、未適用パッチデータの適用対象となる適用対象プログラムを実行する仮想マシンを特定することができる。

〔４〕パッチ制御処理のフロー
図９Ａ〜図９Ｇは、パッチ制御処理の一例を示すフローチャートである。図９Ａは、マスタ管理部が、リポジトリサーバに未適用パッチの問合せる処理の一例を示すフローチャートである。

パッチ管理部は、管理データを記憶部から取得する（Ｓ１００１）。パッチ管理部は、ソフト管理データ４３０に登録されるソフトウェアをそのバージョンとともに送信することで、リポジトリサーバ５０に未適用パッチを問合せる（Ｓ１００２）。パッチ管理部は、リポジトリサーバ５０から未適用パッチがあるか否かを判断する（Ｓ１００３）。リポジトリサーバ５０に未適用パッチがある場合（Ｓ１００３ Ｎｏ）、パッチ管理部は、一定時間のインターバル後に（Ｓ１００４）、Ｓ１００１の処理を再度行う。

リポジトリサーバ５０に未適用パッチがある場合（Ｓ１００３ Ｎｏ）、パッチ管理部は、ソフト管理データ４３０を参照して、パッチ未適用のゲストＯＳを特定する（Ｓ１００５）。パッチ管理部は、グループ管理データ４４０を参照して、パッチ未適用のゲストＯＳを含むグループ及び仮想マシンを特定する（Ｓ１００６）。パッチ管理部は、ＶＭ管理データ４５０を参照して、物理サーバを特定する（Ｓ１００７）。パッチ管理部は、他物理サーバ上にパッチ未適用ゲストＯＳがあるか否か判断する（Ｓ１００８）。他物理サーバ上にパッチ未適用ゲストＯＳがある場合（Ｓ１００８ Ｙｅｓ）、パッチ管理部は、図９Ｂに示すＳ１１０１を実行する。他物理サーバ上にパッチ未適用ゲストＯＳが無い場合（Ｓ１００８ Ｎｏ）、パッチ管理部は、図９Ｃに示すＳ１２０３を実行する。

図９Ｂは、パッチ管理部が、リポジトリサーバ５０にマスタパッチ管理部の宣言を行う処理の一例を示すフローチャートである。パッチ管理部は、記憶部に保持されるマスタフラグ情報のマスタフラグを「ｔｒｕｅ」にセットする（Ｓ１１０１）。マスタパッチ管理部は、他物理サーバのパッチ管理部に、パッチ未適用ゲストＯＳを含むグループ、未適用ゲストＯＳ情報および、送信元のパッチ管理部がマスタパッチ管理部であることを特定するマスタ情報を通知する（Ｓ１１０２）。他物理サーバのパッチ管理部であるサブパッチ管理部は、リポジトリサーバの問合せ処理中か否か判断する（Ｓ１１０３）。問合せ処理中の場合（Ｓ１１０３ Ｙｅｓ）、サブパッチ管理部は、リポジトリサーバへの問合せ処理を中止する（Ｓ１１０４）。このように、あるソフトウェアのパッチデータの問合せは、最初に問合せを行なったパッチ管理部のある物理サーバ１台となるように制御される。Ｓ１１０４の後、又は、問合せ処理中では無い場合（Ｓ１１０３ Ｎｏ）、サブパッチ管理部は、記憶部に保持されるマスタフラグ情報のマスタフラグを「ｆａｌｓｅ」にセットする（Ｓ１１０５）。

サブパッチ管理部は、自物理サーバで実行されるパッチ未適用ゲストＯＳを特定する（Ｓ１１０６）。サブパッチ管理部は、自物理サーバ上のパッチ未適用ゲストＯＳの特定完了と、マスタフラグの設定終了を、マスタパッチ管理部に通知する（Ｓ１１０７）。

図９Ｃは、パッチ管理部が、スナップショットを作成する処理の一例を示すフローチャートである。マスタパッチ管理部は、全てのサブパッチ管理部から応答を受け取ると（Ｓ１２０１）、サブパッチ管理部にスナップショット作成の指示を行なう（Ｓ１２０２）。Ｓ１２０２の後、又は、図９Ａに示すＳ１００８で他物理サーバ上にパッチ未適用ゲストＯＳが無い場合、マスタパッチ管理部は、自物理サーバのスナップショットを作成する（Ｓ１２０３）。サブパッチ管理部も、自物理サーバ内のゲストＯＳのスナップショットを作成する（Ｓ１２０４）。サブパッチ管理部は、スナップショットの完了を、マスタパッチ管理部に通知する（Ｓ１２０５）。マスタパッチ管理部は、全てのサブパッチ管理部からスナップショットの完了を示す応答を待つ（Ｓ１２０６）。

図９Ｄ及び図９Ｅは、パッチ適用処理の一例を示すフローチャートである。マスタパッチ管理部は、サブマスタ管理部へパッチ適用を指示する（Ｓ１３０１）。マスタパッチ管理部は、マスタパッチ管理部内のゲストＯＳにパッチ適用を指示する（Ｓ１３０２）。サブマスタ管理部は、サブパッチ管理部内のゲストＯＳにパッチ適用を指示する（Ｓ１３０３）。ゲストＯＳ上のパッチ適用部が、パッチを適用する（Ｓ１３０４）。パッチ適用部は、パッチ適用が成功したか否かを判断する（Ｓ１３０５）。パッチの適用に失敗した場合（Ｓ１３０５ Ｎｏ）、パッチ適用失敗をサプパッチ管理部へ通知する（Ｓ１３０６）。

パッチの適用に成功した場合（Ｓ１３０５ Ｙｅｓ）、パッチ適用部は、パッチの適用に際し、再起動が必要か否かを判断する（Ｓ１３０７）。再起動が必要な場合は（Ｓ１３０７ Ｙｅｓ）、パッチ適用部は、再起動するか否かを示すリブート情報である「ｒｅｂｏｏｔ」を「ｔｒｕｅ」に設定し（Ｓ１３０９）する。再起動が不要な場合は（Ｓ１３０７ Ｙｅｓ）、パッチ適用部は、再起動するか否かを示す情報である「ｒｅｂｏｏｔ」を「ｔｒｕｅ」に設定する（Ｓ１３０８）。パッチ適用部は、リブート情報をパッチ管理部に通知する（Ｓ１３１０）。

サブパッチ管理部は、リブート情報をマスタパッチ管理部に通知する（Ｓ１４０１）。また、パッチ適用失敗を通知されたサプパッチ管理部（Ｓ１３０６）、パッチ適用失敗をマスタパッチ管理部に通知する（Ｓ１４０３）。Ｓ１４０１又はＳ１４０３の処理の後、マスタパッチ管理部は、全てのサブパッチ管理部からの応答を待つ（Ｓ１４０２）。

図９Ｆ及び図９Ｇは、再起動処理の一例を示すフローチャートである。マスタパッチ管理部は、自物理サーバ内のパッチ未適用サーバのパッチ適用が成功したか否か判断する（Ｓ１５０１）。パッチ適用が成功した場合（Ｓ１５０１ Ｙｅｓ）、マスタパッチ管理部は、サブパッチ管理部から受信したリブート情報が「ｔｒｕｅ」か否かを、判断する（Ｓ１５０２）。リブート情報が「ｔｒｕｅ」の場合（Ｓ１５０２ Ｙｅｓ）、マスタパッチ管理部は、サブパッチ管理部に再起動を指示する（Ｓ１５０３）。マスタパッチ管理部は、自物理サーバ上のパッチ未適用ゲストＯＳに再起動を指示する（Ｓ１５０４）。サブパッチ管理部は、自物理サーバ上のパッチ未適用ゲストＯＳに再起動を指示する（Ｓ１５０５）。各パッチ適用部が再起動を実施する（Ｓ１５０６）。再起動後、パッチ適用部は、パッチ管理部に官僚を通知する（Ｓ１５０７）。サブパッチ管理部は、再起動完了をマスタパッチ管理部に通知する（Ｓ１５０８）。全てのサブパッチ管理部から再起動完了を通知される場合（Ｓ１６０１）、又は、サブパッチ管理部から受信したリブート情報が「ｆａｌｓｅ」の場合（Ｓ１５０２ Ｎｏ）、マスタパッチ管理部は、処理を完了する。

パッチ適用に失敗した場合（Ｓ１５０１ Ｎｏ）、マスタパッチ管理部は、サブパッチ管理部にロールバック処理を指示する（Ｓ１５１０）。マスタパッチ管理部は、自物理サーバ上のゲストＯＳを、スナップショットを用いて元に戻す（Ｓ１５１１）。サブパッチ管理部は、自物理サーバ上のゲストＯＳを、スナップショットを用いてゲストＯＳを元に戻す（Ｓ１５１２）。サブパッチ管理部は、ゲストＯＳを元に戻したことをマスタパッチ管理部に通知する（Ｓ１５１３）。パッチの適用に失敗し、スナップショットでゲストＯＳを元に戻した後は、パッチ適用前の状態に戻るため、Ｓ１２０６に戻り、再度パッチの適用を試みる。

以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
パッチデータを記憶するリポジトリサーバに接続される、複数のサーバを備える情報処理システムであって、
前記複数のサーバの各々は、
前記複数のサーバについて、それぞれのサーバ上で起動される仮想マシンと、前記仮想マシンで実行されるプログラムとの対応関係を記憶する記憶部と、
前記プログラムに適用されていない未適用パッチデータを、前記リポジトリサーバに問合せるパッチ管理部と、を有し、
前記複数のサーバのうち１つのサーバの第１パッチ管理部が、前記リポジトリサーバから未適用パッチデータを受信した場合に、前記対応関係に基づいて、他のサーバの仮想マシンであって、前記未適用パッチデータの適用対象となる適用対象プログラムを実行する仮想マシンに対して、前記未適用パッチデータの適用を要求し、
前記他のサーバの第２パッチ管理部は、前記要求に応じて、未適用のパッチデータを前記適用対象プログラムに適用する、
ことを特徴とする情報処理システム。

（付記２）
前記第２パッチ管理部が、前記第１パッチ管理部より後に、前記管理データに規定されるプログラムに適用されていない未適用パッチデータを前記リポジトリサーバに問合せた場合に、前記第１パッチ管理部は、前記第２パッチ管理部に、前記未適用パッチデータと同じパッチデータに対するパッチの問合せを止めさせることを特徴とする付記１に記載の情報処理システム。

（付記３）
前記複数のサーバの各々は、補助記憶部を備え、
前記第１パッチ管理部又は前記第２パッチ管理部は、前記仮想マシンが未適用パッチデータを前記適用対象プログラムに対して適用する前に、前記適用対象プログラムを前記補助記憶部に記憶することを特徴とする付記１又は２に記載の情報処理システム。

（付記４）
前記第１パッチ管理部は、前記未適用パッチデータが前記仮想マシンの再起動を要する場合に、前記適用対象プログラムを実行する前記仮想マシンにおいて、前記未適用パッチデータを前記適用対象プログラムに適用したことを確認した後で、前記適用対象プログラムを実行する前記仮想マシンに対して、再起動を要求することを特徴とする付記１〜３の何れか１項に記載の情報処理システム。

（付記５）
パッチデータを記憶するリポジトリサーバに接続される、複数のサーバを備える情報処理システムを制御する制御プログラムであって、
前記複数のサーバについて、それぞれのサーバ上で起動される仮想マシンと、前記仮想マシンで実行されるプログラムとの対応関係を参照する処理と、
前記プログラムに適用されていない未適用パッチデータを、前記リポジトリサーバに問合せる処理と、
前記リポジトリサーバから未適用パッチデータを受信した場合に、前記対応関係に基づいて、他のサーバの仮想マシンであって、前記未適用パッチデータの適用対象となる適用対象プログラムを実行する仮想マシンに対して、前記未適用パッチデータの適用を要求する処理と、
前記要求に応じて、未適用のパッチデータを前記適用対象プログラムに適用する処理と、
を前記情報処理システムに実行させることを特徴とする制御プログラム。

（付記６）
前記複数のサーバの各々は、補助記憶部を備え、
前記仮想マシンが未適用パッチデータを前記適用対象プログラムに対して適用する前に、前記適用対象プログラムを前記補助記憶部に記憶する処理を、前記情報処理システムに実行させることを特徴とする付記５に記載の制御プログラム。

（付記７）
前記未適用パッチデータが前記仮想マシンの再起動を要する場合に、前記適用対象プログラムを実行する前記仮想マシンにおいて、前記未適用パッチデータを前記適用対象プログラムに適用したことを確認した後で、前記適用対象プログラムを実行する前記仮想マシンに対して、再起動を要求する処理を、前記情報処理システムに実行させることを特徴とする付記５又は６に記載の制御プログラム。

（付記８）
パッチデータを記憶するリポジトリサーバに接続される、複数のサーバを備える情報処理システムを制御する制御方法であって、
前記複数のサーバについて、それぞれのサーバ上で起動される仮想マシンと、前記仮想マシンで実行されるプログラムとの対応関係を参照し、
前記プログラムに適用されていない未適用パッチデータを、前記リポジトリサーバに問合せ、
前記リポジトリサーバから未適用パッチデータを受信した場合に、前記対応関係に基づいて、他のサーバの仮想マシンであって、前記未適用パッチデータの適用対象となる適用対象プログラムを実行する仮想マシンに対して、前記未適用パッチデータの適用を要求し、
前記要求に応じて、未適用のパッチデータを前記適用対象プログラムに適用する、
ことを特徴とする制御方法。

（付記９）
前記複数のサーバの各々は、補助記憶部を備え、
前記仮想マシンが未適用パッチデータを前記適用対象プログラムに対して適用する前に、前記適用対象プログラムを前記補助記憶部に記憶する、ことを特徴とする付記８に記載の制御方法。

（付記１０）
前記未適用パッチデータが前記仮想マシンの再起動を要する場合に、前記適用対象プログラムを実行する前記仮想マシンにおいて、前記未適用パッチデータを前記適用対象プログラムに適用したことを確認した後で、前記適用対象プログラムを実行する前記仮想マシンに対して、再起動を要求する、ことを特徴とする付記８又は９に記載の制御方法。

５０ リポジトリサーバ
１００ 情報処理システム
２００、２００Ａ、２００Ｂ 物理サーバ
２１０ 処理部
２２０ 記憶部
２３０ 通信部
２４０ 補助記憶部
２５０ ドライブ部
２６０ Ｉ／Ｏコントローラ
２９０ 記憶媒体
４３０ ソフト管理データ
４４０ グループ管理データ
４５０ ＶＭ管理データ
５００Ａ〜５００Ｄ 仮想マシン
９１０ 仮想化ソフトウェア
９１５ 仮想計算機モニタ
９２０ 制御プログラム

Claims (6)

1. パッチデータを記憶するリポジトリサーバに接続される、複数のサーバを備える情報処理システムであって、
   前記複数のサーバの各々は、
   前記複数のサーバについて、それぞれのサーバ上で起動される仮想マシンと、前記仮想マシンで実行されるプログラムとの対応関係を記憶する記憶部と、
   前記プログラムに適用されていない未適用パッチデータを、前記リポジトリサーバに問合せるパッチ管理部と、を有し、
   前記複数のサーバのうち１つのサーバの第１パッチ管理部が、前記リポジトリサーバから未適用パッチデータを受信した場合に、前記対応関係に基づいて、他のサーバの仮想マシンであって、前記未適用パッチデータの適用対象となる適用対象プログラムを実行する仮想マシンに対して、前記未適用パッチデータの適用を要求し、
   前記他のサーバの第２パッチ管理部は、前記要求に応じて、未適用のパッチデータを前記適用対象プログラムに適用する、
   ことを特徴とする情報処理システム。
2. 前記第２パッチ管理部が、前記第１パッチ管理部より後に、前記プログラムに適用されていない未適用パッチデータを前記リポジトリサーバに問合せた場合に、前記第１パッチ管理部は、前記第２パッチ管理部に、前記未適用パッチデータと同じパッチデータに対するパッチの問合せを止めさせることを特徴とする請求項１に記載の情報処理システム。
3. 前記複数のサーバの各々は、補助記憶部を備え、
   前記第１パッチ管理部又は前記第２パッチ管理部は、前記仮想マシンが未適用パッチデータを前記適用対象プログラムに対して適用する前に、前記適用対象プログラムを前記補助記憶部に記憶することを特徴とする請求項１又は２に記載の情報処理システム。
4. 前記第１パッチ管理部は、前記未適用パッチデータが前記仮想マシンの再起動を要する場合に、前記適用対象プログラムを実行する前記仮想マシンにおいて、前記未適用パッチデータを前記適用対象プログラムに適用したことを確認した後で、前記適用対象プログラムを実行する前記仮想マシンに対して、再起動を要求することを特徴とする請求項１〜３の何れか１項に記載の情報処理システム。
5. パッチデータを記憶するリポジトリサーバに接続される、複数のサーバを備える情報処理システムを制御する制御プログラムであって、
   前記複数のサーバについて、それぞれのサーバ上で起動される仮想マシンと、前記仮想マシンで実行されるプログラムとの対応関係を参照する処理と、
   前記プログラムに適用されていない未適用パッチデータを、前記リポジトリサーバに問合せる処理と、
   前記リポジトリサーバから未適用パッチデータを受信した場合に、前記対応関係に基づいて、他のサーバの仮想マシンであって、前記未適用パッチデータの適用対象となる適用対象プログラムを実行する仮想マシンに対して、前記未適用パッチデータの適用を要求する処理と、
   前記要求に応じて、未適用のパッチデータを前記適用対象プログラムに適用する処理と、
   を前記情報処理システムに実行させることを特徴とする制御プログラム。
6. パッチデータを記憶するリポジトリサーバに接続される、複数のサーバを備える情報処理システムを制御する制御方法であって、
   前記複数のサーバについて、それぞれのサーバ上で起動される仮想マシンと、前記仮想マシンで実行されるプログラムとの対応関係を参照し、
   前記プログラムに適用されていない未適用パッチデータを、前記リポジトリサーバに問合せ、
   前記リポジトリサーバから未適用パッチデータを受信した場合に、前記対応関係に基づいて、他のサーバの仮想マシンであって、前記未適用パッチデータの適用対象となる適用対象プログラムを実行する仮想マシンに対して、前記未適用パッチデータの適用を要求し、
   前記要求に応じて、未適用のパッチデータを前記適用対象プログラムに適用する、
   ことを特徴とする制御方法。

Images