JP2012133825A - プログラム配信装置及び方法 - Google Patents

Abstract

【課題】
選択的なプログラムの配信を行い得るプログラム配信装置及び方法を提案する。
【解決手段】
少なくとも１つのサーバとネットワークを介して接続され、前記サーバに対して必要に応じてプログラムを配信するプログラム配信方法において、前記サーバの状態変更を検知し、複数のサーバからなるシステムの運用ポリシーを参照し、配信するプログラムのルールに対応したサーバ走査方法を入手し、入手した前記サーバ走査方法に従って自プログラム配信装置に接続された各前記サーバの走査を実行し、前記走査で特定した新規のサーバに対して前記プログラムを配信可能か否かを判定し、新規のサーバに対して前記プログラムを配信可能なときに、当該新規のサーバに応じたプログラムを配信するようにした。
【選択図】 図１２

Description

本発明は、プログラム配信装置及び方法に関し、例えばサーバシステムにおいて物理サーバや当該物理サーバ上に設定された仮想的なサーバ（以下、これを仮想サーバと呼ぶ）を管理する管理サーバに適用して好適なものである。

従来、データセンタには、様々なベンダ製のサーバやサーバ仮想化製品が存在する。そして、これらサーバやサーバ仮想化製品を管理する方法や管理下に置く方法として、従来から種々の方法が提案されている。その１つとして、管理対象の物理サーバや当該物理サーバ上に設けられた仮想サーバに対してエージェントプログラムと呼ばれるサーバ管理用のプログラムを配信しインストールすることが広く行なわれている。

この場合、かかるプログラムを物理サーバや仮想サーバに配信するに際しては、その物理サーバや仮想サーバのプラットフォームがそのプログラムを配信可能なプラットフォームであるか否かを判断したり、複数種類存在する配信プログラムのうちのどのプログラムを配信すべきかを判断しなければならないなど、システム管理者の負担は大きい。

このような課題を解決するための手段として、従来、ネットワーク上に存在するリモートクライアントに適切なプログラムを選択的にインストールする技術や、機種の異なる複数のコンピュータに対して所望のソフトウェアをインストールする技術が提案されている（特許文献１及び特許文献２参照）。
特開２００７−５８６６４号公報 特開２０００−２７６３３２号公報

ところで、データセンタに設置されたサーバの利用者は、コスト等の関係から、サーバ管理のためのメモリ資源の使用を極力抑えたいと要望する。そしてそのような利用者の中には、例えば物理サーバ上で仮想サーバが稼動している場合に、業務に直接使用する仮想サーバに対して管理用のプログラムをインストールすることは容認するものの、直接的には業務に使用しない物理サーバにかかるプログラムをインストールすることは敬遠する利用者も存在する。従って、このような場合には、仮想サーバにのみかかるプログラムを配信し、物理サーバには当該プログラムを配信しないといった運用が必要になる。

ところが、かかる特許文献１及び特許文献２に開示された技術では、ネットワーク上に存在するすべてのリモートクライアントやコンピュータにプログラムを配信することを前提としており、上述のような選択的なプログラムの配信を行い得ない問題があった。

本発明は以上の点を考慮してなされたもので、選択的なプログラムの配信を行い得るプログラム配信装置及び方法を提案しようとするものである。

かかる課題を解決するため本発明においては、少なくとも１つのサーバとネットワークを介して接続され、前記サーバに対して必要に応じてプログラムを配信するプログラム配信装置において、前記サーバの状態変更を検知し、複数のサーバからなるシステムの運用ポリシーを参照し、配信するプログラムのルールに対応したサーバ走査方法を入手し、入手した前記サーバ走査方法に従って自プログラム配信装置に接続された各前記サーバの走査を実行するサーバ走査処理部と、前記走査で特定した新規のサーバに対して前記プログラムを配信可能か否かを判定する判定処理部と、新規のサーバに対して前記プログラムを配信可能なときに、当該新規のサーバに応じたプログラムを配信する配信実行処理部とを備えることを特徴とする。

また本発明においては、少なくとも１つのサーバとネットワークを介して接続され、前記サーバに対して必要に応じてプログラムを配信するプログラム配信方法において、前記サーバの状態変更を検知し、複数のサーバからなるシステムの運用ポリシーを参照し、配信するプログラムのルールに対応したサーバ走査方法を入手し、入手した前記サーバ走査方法に従って自プログラム配信装置に接続された各前記サーバの走査を実行する第１のステップと、前記走査で特定した新規のサーバに対して前記プログラムを配信可能か否かを判定する第２のステップと、新規のサーバに対して前記プログラムを配信可能なときに、当該新規のサーバに応じたプログラムを配信する第３のステップとを備えることを特徴とする。

本発明によれば、選択的にプログラムを配信することが可能になる。この結果、仮想サーバや、仮想化機構が稼動していない物理サーバに対してはプログラムを配信するが、プログラムが対応していない機器や、仮想化機構が稼動している物理サーバに対してはプログラムを配信しない、といった運用が可能となる。これにより利便性の高いプログラム配信装置及び方法を実現できる。

第１の実施の形態によるサーバシステムの概略構成を示すブロック図である。 管理サーバの概略構成を示すブロック図である。 物理サーバの概略構成を示すブロック図である。 物理サーバ、仮想化機構及び仮想サーバの概略構成を示すブロック図である。 第１の実施の形態によるプログラム配信処理の概要説明に供する概念図である。 サーバ管理テーブルを示す図表である。 サーバ論理情報管理テーブルを示す図表である。 サーバモデル情報管理テーブルを示す図表である。 仮想化機構管理テーブルを示す図表である。 データセンタ運用ポリシー管理テーブルを示す図表である。 プログラム管理テーブルを示す図表である。 プログラム配信処理の処理手順を示すフローチャートである。 サーバ走査処理の処理手順を示すフローチャートである。 サーバ登録処理の処理手順を示すフローチャートである。 サーバ構成取得処理の処理手順を示すフローチャートである。 仮想化機構構成生成処理の処理手順を示すフローチャートである。 管理手段判定処理の処理手順を示すフローチャートである。 配信実行処理の処理手順を示すフローチャートである。 第２の実施の形態によるサーバシステムの概略構成を示すブロック図である。 第２の実施の形態によるサーバモデル情報管理テーブルを示す図表である。 第２の実施の形態によるシャーシ、物理サーバ、仮想化機構及び仮想サーバのトポロジを示す概念図である。 第２の実施の形態によるサーバ構成取得処理の処理手順を示すフローチャートである。

以下図面について、本発明の一実施の形態を詳述する。

（１）第１の実施の形態
（１−１）本実施の形態によるサーバシステムの構成
図１において、１は全体としてデータセンタに設置された本実施の形態によるサーバシステムを示す。このサーバシステム１は、管理サーバ２が第１のネットワークスイッチ（ＮＷ−ＳＷ）３を介して１又は複数の物理サーバ４と接続されると共に、管理サーバ２及び各物理サーバ４がそれぞれ第２のネットワークスイッチ（ＮＷ−ＳＷ）５を介してストレージ装置６と接続されることにより構成されている。

管理サーバ２は、パーソナルコンピュータ又はワークステーションなどから構成され、図２に示すように、ＣＰＵ（Central Processing Unit）１０、メモリ１１、ネットワークインタフェース１２及びディスクインタフェース１３を備える。

ＣＰＵ１０は、管理サーバ２全体の動作制御を司るプロセッサであり、メモリ１１に格納された後述の制御プログラム群１３及び管理テーブル群１４に基づいて必要な処理を実行する。メモリ１１は、後述する制御プログラム群１３及び管理テーブル群１４を記憶するために用いられるほか、ＣＰＵ１０のワークメモリとしても用いられる。

ネットワークインタフェース１２は、第１のネットワークスイッチ３（図１）に対応した通信インタフェースであり、管理サーバ２が各物理サーバ４と通信する際のプロトコル制御を行う。またディスクインタフェース１３は、第２のネットワークスイッチ５に対応した通信インタフェースであり、管理サーバ２がストレージ装置６と通信する際のプロトコル制御を行う。

物理サーバ４は、管理サーバ２と同様にパーソナルコンピュータ又はワークステーションなどから構成され、図３に示すように、ＣＰＵ２０、メモリ２１、ネットワークインタフェース２２及びディスクインタフェース２３を備える。これらＣＰＵ２０、メモリ２１、ネットワークインタフェース２２及びディスクインタフェース２３は、それぞれ管理サーバ２のＣＰＵ１０、メモリ１１、ネットワークインタフェース１２及びディスクインタフェース１３と同様の機能を有するものであるため、その詳細については説明を省略する。

かかる物理サーバ４には物理サーバ４内のデバイス管理を行うＯＳ（Operating System）２４がインストールされており、物理サーバ４上ではこのＯＳ２４が起動された状態にある。なお、物理サーバ４のＯＳ２４が起動されていない場合は、ＷＯＬ（Wake up On Lan）やＢＭＣ（Basement Management Controller）経由で電源をオンにすることで当該ＯＳ２４を起動状態にすることできる。

ＯＳ２４上には、管理用のプログラム２５や、業務を提供するアプリケーション２６などが配備され、これらプログラム２５及びアプリケーション２６がＯＳ２４上で動作している。プログラム２５は、物理サーバ４や仮想サーバ３１を管理するための専用のプログラムである。このプログラムによって、ＯＳ２４や物理サーバ４に関する資産情報や性能情報、障害情報を取得することができる。また、プログラム２５によって、別のプログラムを起動又は終了させたり、ＯＳ２４自体に終了コマンドを投入することもできる。さらに、プログラム２５にアプリケーション２６の監視機能を持たせることで、アプリケーション２６の動作を管理することもできる。

図４に示すように、各物理サーバ４上では、メモリ２１に格納された制御プログラムの１つである仮想化機構３０が動作し、この仮想化機能３０が、物理サーバ４のＣＰＵ２０、メモリ２１、ネットワークインタフェース２２及びディスクインタフェース２３などのデバイスをそれぞれ仮想化した仮想ＣＰＵ３２、仮想メモリ３３、仮想ネットワークインタフェース３４及び仮想ディスクインタフェース３５などから構成される仮想サーバ３１を作成する。

各仮想サーバ３１の仮想メモリ３３にはプログラム２５、アプリケーション２６及びＯＳ２０がそれぞれ他の仮想サーバ３１とは別個に格納されており、これらプログラム２５、アプリケーション２６及びＯＳ２０に基づいて個々の仮想サーバ３１が物理サーバ３０と同様のサービスを提供し得るようになされている。

仮想化機構３０及び各仮想サーバ３１もまた、仮想化機構３０の仮想化機構管理用インタフェース３６を介して管理サーバ２と接続されている。そして管理サーバ２は、仮想化機構管理用インタフェース３６経由で、仮想化機構３０や各仮想サーバ３１の情報を収集及び設定することができ、また各仮想サーバ３１の電源制御をすることができるようになされている。

ストレージ装置６（図１）は、例えばＲＡＩＤ（Redundant Array of Inexpensive Disks）方式で運用される複数のディスク装置（図示せず）を備えて構成される。図１に示すように、これら複数のディスク装置が提供する記憶領域上には複数のボリューム３７が定義される。なお、これらボリューム３７の属性としては、システムボリューム及びデータボリュームなどがある。システムボリュームは、ＯＳ等のシステム情報を格納するために使用され、データボリュームは、ユーザデータを格納するために使用される。

またストレージ装置６内には、管理サーバ２に接続された１又は複数のボリューム３７も存在し、このボリューム３７内に後述のように物理サーバ４や仮想サーバ３１に配信される１種類以上のプログラム２５が格納されて保持される。

（１−２）サーバシステムにおけるプログラム配布方法
（１−２−１）プログラム配布方法の概要
上述した本実施の形態によるサーバシステム１において、管理サーバ２は、物理サーバ４及び仮想サーバ３１を管理することを目的として、新規導入された物理サーバ４及び仮想サーバ３１に対して管理用のプログラム２５を配信し、そのプログラム２５を利用して、物理サーバ４及び仮想サーバ３１を管理する。また管理サーバ２は、仮想化機構３０については、管理用のプログラム２５を用いない管理方法（例えばＯＳ標準インタフェースや標準化されたインタフェースを用いた管理方法）により管理する。

ただし、サーバ利用者の要望や、プログラム２５とサーバとの相性の問題から、かかるプログラム２５を物理サーバ４や仮想サーバ３１に配信できない場合もある。

そこで、本実施の形態によるサーバシステム１は、新規導入された物理サーバ４や仮想サーバ３１について、そのサーバが管理用のプログラム２５を配信可能なサーバであるか否かを判定し、配信可能な物理サーバ４や仮想サーバ３１に対してのみ選択的にかかるプログラム２５を配信する点を特徴の１つとしている。

図５は、このような本実施の形態による管理用のプログラム配信方法の概略を示している。本実施の形態によるサーバシステム１において、管理サーバ２は、定期監視又はイベントを契機として、第１のネットワークスイッチ３に接続されたノード（ここでは物理ノード４、仮想化機構３０及び仮想サーバ３１）を走査し（ＳＰ１）、第１のネットワークスイッチ３に接続されたノードを検索する（ＳＰ１）。

そして管理サーバ２は、かかる走査により第１のネットワークスイッチ３に新規に接続されたノード（以下、これを新規ノードと呼ぶ）を検出すると（ＳＰ２）、その新規ノードに対する情報収集を実施する（ＳＰ３）。この情報収集の方法としては、情報収集プログラムを用いた情報収集方法や、ＯＳ標準インタフェース又は標準化されたプロトコルを利用した情報収集方法などを適用することができる。

なお、データセンタの運用ポリシーに沿って情報収集を行うことで、詳細に渡って情報を集めることが可能である。データセンタの運用ポリシーの例として、物理サーバ４や、仮想化機構３０及び仮想サーバ３１に付与するＩＰアドレスの範囲を規定することが挙げられる。この運用ポリシーによれば、例えば「ping」により新規ノードを検出する際に、時間の効率が良く、また無駄なパケットによりネットワークに負荷をかけることを抑制することができる。また、情報収集を実施する際には、後述するホスト名の命名規則やユーザＩＤ及びパスワードの生成規則が役に立つ。これらの規則を用いることで、サーバに接続し情報を収集することが可能になる。接続方法を指定した運用をしている場合、それをデータセンタの運用ポリシーとして定義することで、さらに確実に効率良く情報収集を実施することが可能である。

続いて管理サーバ２は、ステップＳＰ３において収集した情報に基づいて、各新規ノードが物理サーバ４、仮想化機構３０及び仮想サーバ３１のうちのいずれであるかを判定し、これら新規ノード間の親子関係（新たに検出した物理サーバ４、仮想化機構３０及び仮想サーバ３１のトポロジ）を明らかにする（ＳＰ４）。この親子関係を明らかにすることで、例えば仮想サーバ３１が稼動する物理サーバ４や、仮想化機構３０に対してはプログラム２５を配信しないといった運用を行うことができる。

続いて管理サーバ２は、ステップＳＰ２において検出した新規ノードに対するプログラム２５の配信の可否を判定する（ＳＰ５）。これは、その新規ノードに対する管理方法の決定を意味する。

そして、管理サーバ２は、この判定において肯定結果を得た場合、その新規ノードにプログラム２５を配信後、当該プログラム２５を用いた管理を開始する（ＳＰ６）。対象は、物理サーバ４及び仮想サーバ３１である。物理サーバ４については、データセンタの運用ポリシーによっては配信しないこともある。本実施の形態においては、仮想サーバ３１が稼動する物理サーバ４に対してはプログラム２５を配信しない。一方、プログラム２５を配信するケースは、その物理サーバ４上で仮想化機構３０が稼動していない場合や、仮想化機構３０が一般的に利用されるホストＯＳを利用している場合などである。プログラム２５を配信した場合、その物理サーバ４や仮想サーバ３１に対する情報収集や監視、設定及び制御はその後そのプログラム２５を通じて行う。

また管理サーバ２は、ステップＳＰ５の判定において否定結果を得た場合、その新規ノードにプログラム２５を配信せず、当該新規ノードに対して例えばＯＳ標準インタフェースや標準化されたインタフェースを用いた管理を開始する（ＳＰ７）。対象は、仮想化機構３０や、プログラム２５が対応していない物理サーバ５０２などである。このようにして、仮想化機構３０に対してサーバ管理用のプログラム２５が配信されることを抑止することができる。

（１−２−２）各種プログラム及び各種テーブルの構成
以上のような本実施の形態によるプログラム配布方法を実現するための手段として、管理サーバ２のメモリ１１には、図２に示すように、サーバ走査プログラム４０、サーバ登録プログラム４１、サーバ構成取得プログラム４２、仮想化機構構成生成プログラム４３、管理手段判別プログラム４４及び配信実行プログラム４５からなるプログラム群１３と、サーバ管理テーブル４６、サーバ論理情報管理テーブル４７、サーバモデル情報管理テーブル４８、仮想化機構管理テーブル４９、データセンタ運用ポリシー管理テーブル５０及びプログラム管理テーブル５１からなる管理テーブル群１４とが格納されている。

このうち、サーバ走査プログラム４０は、第１のネットワークスイッチ３（図１）を介して管理サーバ２に接続されたノード（物理サーバ４、仮想化機構３０及び仮想サーバ３１）を走査するためのプログラムであり、サーバ登録プログラム４１は、かかる走査により検出した新規ノードをサーバ管理テーブル４６に登録するプログラムである。

またサーバ構成取得プログラム４２は、サーバ登録プログラム４１によりサーバ管理テーブル４６に登録された各新規ノードの構成情報を取得するプログラムであり、仮想化機構構成生成プログラム４３は、かかる新規ノード間のトポロジを検出するためのプログラムである。

さらに管理手段判定プログラム４４は、サーバ管理テーブル４６に登録された新規ノードに対してプログラム２５を配信するか否かを判定するプログラムであり、配信実行プログラム４５は、プログラム２５を配信すると判定された新規ノードに対してプログラム２５を配信するプログラムである。

なお、以下においては、各種処理の処理主体をサーバ走査プログラム４０、サーバ登録プログラム４１、サーバ構成取得プログラム４２、仮想化機構構成生成プログラム４３、管理手段判別プログラム４４又は配信実行プログラム４５として説明するが、実際は、そのプログラムに基づいて管理サーバ２のＣＰＵ１０が対応する処理を実行することはいうまでもない。

一方、サーバ管理テーブル４６は、管理サーバ２が当該管理サーバ２に接続されたノードを管理するためのテーブルであり、ノード識別子欄４６Ａ、ＣＰＵアーキテクチャ欄４６Ｂ、ＵＵＩＤ欄４６Ｃ、Ｉ／Ｏデバイス欄４６Ｄ、ボリューム欄４６Ｅ、電源ステータス欄４６Ｆ、サーバモデル欄４６Ｇ、仮想レイヤ欄４６Ｈ及び仮想化種別欄４６Ｉから構成される。

そしてノード識別欄４６Ａには、サーバ走査プログラム４０により検出された管理サーバ２に接続された各ノード（物理サーバ４、仮想化機構３０及び仮想サーバ３１）にそれぞれ付与された識別子（以下、これをノード識別子と呼ぶ）が格納される。またＣＰＵアーキテクチャ欄４６Ｂには、対応するノードに搭載されたＣＰＵのアーキテクチャが格納される。ＣＰＵアーキテクチャは、プログラム２５の種別を選択する際に必要な情報である。異なるＣＰＵアーキテクチャ用に作成されたプログラム２５では、例え動作したとしても十分に役割を果たすことができない可能性が高い。

ＵＵＩＤ欄４６Ｃには、対応するノードに付与されたＵＵＩＤ（Universal Unique Identifier）が格納される。ＵＵＩＤは、本来、全宇宙規模で識別子が重複しないように形式が規定された、確実なユニーク性を保証する識別子となり得る識別子である。従って、ノード識別子欄４６Ａに格納されるノード識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、ノード識別子欄４６Ａに格納するノード識別子としては、システム管理者が所望するノード識別子を使用しても良い。実際上、ノード識別子はノード間で重複することがなければ問題ないため、ＵＵＩＤを使うことが望ましいものの、それが必須とはならない。例えば、ホスト名やＩＰアドレス、ＭＡＣ（Media Access Control）アドレス、ＷＷＮ（World Wide Name）などがノード識別子の候補として挙げることができる。

Ｉ／Ｏデバイス欄４６Ｄは、デバイス欄４６Ｊ、枚数欄４６Ｋ、ＷＷＮ欄４６Ｌ及びドライバ種別欄４６Ｍから構成される。そしてデバイス欄４６Ｊには、対応するノードが管理サーバ２と通信を行うために利用するＩ／Ｏ（Input/Output）デバイスのデバイス種別が格納される。かかるデバイス種別としては、ＨＢＡ（Host Bus Adaptor）やＮＩＣ（Network Interface Card）などが挙げられる。

また枚数欄４６Ｋには、かかるＩ／Ｏデバイスの数が格納される。Ｉ／Ｏデバイスの数が少ない場合、プログラム２５がネットワーク等にかける負担が少ないことが望まれるため、対応するノードに配布するプログラム２５として負荷の軽いプログラム２５を選択することが必要となる。また、対応するノードがかかるＩ／Ｏデバイスを複数有する場合には、１つ以上のＩ／Ｏデバイスを監視するケースが存在する。その場合は、対応するノードに配布する２５として、管理サーバ２と、そのノードとの間で密な連携ができる２５を選択する必要がある。

ＷＷＮ欄４６Ｋには、対応するデバイス欄４６Ｊにデバイス種別が格納されたＩ／Ｏデバイスに付与されたネットワークアドレス（ＨＢＡのＷＷＮや、ＮＩＣのＭＡＣアドレスなど）が格納される。ネットワークアドレスは、ＳＡＮ（Storage Area Network）環境においてノードを識別する識別子となる。そのため、ＳＡＮ環境が前提のシステムにおいては、ノード識別子としての役割を担う場合もある。ＭＡＣアドレスは、一般的に一意の識別子であるため、ノード識別子としての役割を担う場合もある。

またドライバ種別欄４６Ｍには、対応するＩ／Ｏデバイスのデバイスドライバ種別が格納される。相性の良し悪しで、システムがダウンしないためにもどのようなデバイスドライバが組み込まれているかを知ることは重要である。

ボリューム欄４６Ｅは、インタフェース欄４６Ｎ、容量欄４６Ｐ及び種別欄４６Ｑから構成される。そしてインタフェース欄４６Ｎには、対応するノードが、当該ノードと接続されたボリューム３７（図１）にデータを入出力する際に用いるインタフェースの種別（ＩＤＥ（Integrated Device Environment）やＳＣＳＩ（Small Computer System Interface）など）が格納される。

また容量欄４６Ｐには、かかるボリューム３７の容量が格納される。かかるボリューム３７の合計容量が少ないケースでは、プログラム２５に関してデータベース領域を多量に消費することは許容されないため、可能な限り軽い動作が求められる。また、逆にかかるボリューム３７の合計容量が大きく、かつ大量のノードを管理する場合にはデータベースを構築した方が、情報検索や情報を蓄える上で信頼性の高いシステムを組むことが可能になる。

さらに種別欄４６Ｑには、対応するボリューム３７の属性がシステムボリューム（「boot」）及びデータボリューム（「data」）のいずれであるかを表す情報が格納される。種別欄４６Ｑについては、初期設定値を前者（「boot」）に設定し、変更しない運用も考えられるが、一般的にはシステム管理者によって設定される。また、ノード識別子欄４６Ａについては、本サーバ管理テーブル４６の各欄のいずれか、又は複数の欄を組み合わせたものを指定することで入力を省略することができる。また、昇順などで自動的に割り振っても良い。

電源ステータス欄４６Ｆには、そのノードの電源ステータスが格納される。電源ステータスとしては、起動状態（「オン」）及び未起動状態（「オフ」）の２つのステータスがある。例えばプログラム２５を配信する際に、そのノードの電源がオフの場合、電源をオンにする必要があるため、管理サーバ２は各ノードの電源ステータスをも管理する。また、電源がオフになっている仮想サーバ３１については情報を収集できないが、後述のサーバモデル情報管理テーブル４８（図８参照）に値を格納する際には適切に情報を満たす必要がある。これにより、仮想化機構３０や仮想サーバ３１が動作したり、定義されている物理サーバ４にプログラム２５を誤配信することを回避することが可能となる。

サーバモデル欄４６Ｇには、対応するノードのサーバモデル（ベンダ名やモデル名など）が格納される。この情報は、そのノードがプログラム２５を用いて管理できる対象であるか否かを判定するために用いられる。

さらに仮想レイヤ欄４６Ｈには、対応するノードの仮想化レイヤが格納される。仮想化レイヤとしては、「物理」、「仮想化機構」及び「仮想サーバ」の３種類が存在し、それぞれ物理サーバ４、仮想化機構３０又は仮想サーバ３１に対応する。管理サーバ２は、この情報に基づいて、対応するノードが物理サーバ４、仮想化機構３０及び仮想サーバ３１のいずれであるかを判別し、ノード間のトポロジを判定する。

さらに仮想化種別欄４６Ｉには、対応するノードの仮想化種別（仮想化製品を提供するベンダ名や製品名）が格納される。情報取得のインタフェースやプロトコル及びＣＩＭ（Common Information Model）に対応しているか否かなど、情報取得を進める上で必要な情報である。後述の仮想化機構識別子（図９参照）を格納しても同義である。

このサーバ管理テーブル４６は、基本的に初期時には情報が格納されておらず、サーバ走査プログラム４０（図２）により新規ノード（物理サーバ４、仮想化機構３０及び又は仮想サーバ３１）が検出されるごとに、その新規ノードに関する各種情報が収集されて、これらの情報のうちの必要な情報がサーバ管理テーブル４６に格納される。

なお、仮想化機構３０は利用者から見て、どのデバイスも使っていないように見えるため、例えば図６のノード識別子が「ノード２」や「ノード８」の行に示すように、ＣＰＵアーキテクチャ欄４６Ｂ、枚数欄４６Ｋ、ＷＷＮ欄４６Ｌ、ドライバ種別欄４６Ｍ、インタフェース欄４６Ｎ、容量欄４６Ｐ及び種別欄４６Ｑに対応する情報が格納されない（対応する情報が収集できない）可能性がある。

これは、サーバ仮想化製品を提供するベンダがどのように仮想化機構３０を見せるかにも依存する。これらの欄に情報が格納される場合、物理デバイスと情報を共有することが考えられる。これにより、情報が一致する物理サーバ４と仮想化機構３０は一組であることを推定することができる。

一方、サーバ論理情報管理テーブル４７は、管理サーバ２が自己に接続された各ノード（物理サーバ４、仮想化機構３０及び仮想サーバ３１）の論理構成を管理するためのテーブルであり、図７に示すように、ノード識別子欄４７Ａ、業務識別子欄４７Ｂ、ディスクイメージ名欄４７Ｃ、ＯＳ種別欄４７Ｄ、アーキテクチャ欄４７Ｅ、ホスト名欄４７Ｆ、ＩＤ／ＯＳパスワード欄４７Ｇ、ＩＰ情報欄４７Ｈ、プログラム名欄４７Ｉ、プログラム固有設定欄４７Ｊ及び管理手段欄４７Ｋから構成される。

そしてノード識別子欄４７Ａには、対応するノードに付与されたノード識別子が格納され、業務識別子欄４７Ｂには、そのノードが使用される業務の識別子である業務識別子が格納されている。かかる業務識別子を記述する方法としては、業務Ａの第１サーバ、第２サーバといった個々をサーバレベルまで特定する記述方法、業務Ａで共通化されたソフトウェアのインストールを示し、業務レベルまでを特定する記述方法、システムで共通化されたソフトウェアのインストールを示し、共通環境レベルを特定する記述方法などが考えられる。なお、対応するノードが使用される業務は、通常はシステム管理者が記述するが、インストールされているハードウェアやプログラムなどから管理サーバ２が推定することも可能である。

また、データセンタの運用ポリシーに基づいて、実装されているプログラムが判明した段階で、業務を特定できるケースも存在する。特定した業務と連携することで、配信するプログラム２５のバージョンを変えることが可能である。これにより、対応するノードに対する図１１について後述する管理レベルが変わり、物理サーバ４や仮想サーバ３１に負荷をかけるがＯＳやハードウェアと密な連携が可能なプログラム２５を配信したり、逆に物理サーバ４や仮想サーバ３１に負荷をかけない代わりにＯＳやハードウェアとの連携が疎なプログラム２５を配信する、といった運用が可能になる。これは、業務やアプリケーションによって、必要とされるプログラムの機能が異なることから必要となる管理方針の使い分け（ポリシー管理）である。

また、管理サーバ２が、ＯＳ起動通知や、障害通知、ハードウェア情報通知（ブレードサーバの挿入や抜去）、プログラムのインストール及びアンインストールといったソフトウェア更新情報通知（アップデートを含む）を契機として、サーバ論理情報管理テーブル４７を更新した上で、プログラム２５を選択して配信することも可能である。

ディスクイメージ名欄４７Ｃには、対応するノードが使用するボリューム３７（図１）のディスクイメージ名が格納される。ディスクイメージ名は、各ディスクイメージを特定するための識別子である。これは、物理サーバ４や仮想サーバ３１のディスクイメージを識別しており、業務とほぼ同義とみなすことができる。ただし、アプリケーションがインストールされていない状態のディスクイメージや、ＯＳやアプリケーションはインストールされているが、セットアップされていないディスクイメージが存在し、それらディスクイメージを配信することで業務回復を図ったり、業務を提供する物理サーバ４や仮想サーバ３１を増設することが容易になる。そういった情報と連携することで、最初は疎な連携のプログラム２５を配信しておいて、業務が本格稼動する際に密な連携のプログラム２５を再配信する、といった連携が可能になる。

業務が本格稼動するときに、ハードウェア特有の機能を使ってシステムの高信頼化を図ることも可能になる。また逆に、疎な連携のプログラム２５を再配信することもある。これにより、システム構築のときにだけ必要な情報収集ツールとしてプログラム２５を利用することが可能になる。また、全く別のプログラム２５を用途に応じて再配信することで、ユーザニーズに合わせて出来るだけ常駐するプログラムを排除するといった柔軟なシステム構築ならびに運用が可能になる。再配信の方法としては、ＲＣＰ（Remote Copy）やＲＳＨ（Remote Shell）を使ってプログラム２５を配信しインストーラを実行する方法でも良いし、デプロイメイト用のソフトウェアを利用しても良い。配信する手順として、複数の手段を試行することで可能な方法を選択しても良い。また、用済みとなったプログラム２５をノードから削除することも可能である。常駐するプログラムを可能な限り少なくすることで、計算機リソースを業務へ有効活用することが可能になる。再配信のトリガは、ユーザが与えても良いし、ノードからのアラート通知でも良い。ＯＳ起動やブレードサーバの挿入および抜去、ハードウェアおよびソフトウェアの障害通知および障害予兆通知、性能障害の通知および性能障害予兆通知などがある。障害や障害の予兆を検知した時点で、詳細な情報取得を目的に密連携のプログラム２５を再配信したり、高可用性を重視するHA(High Availavilty)構成へシステム構成を組むための機能を持ったプログラム２５を再配信したりすることで、障害の原因解析や対処の検討、ならびにシステムの可用性向上へ寄与することが可能になる。

ＯＳ種別欄４７Ｄには、対応するノードが使用するＯＳの種別が格納される。このＯＳ種別欄４７Ｄに格納する情報として、サービスパックやパッチなどの情報をも含めることで、当該情報に基づいてプログラム２５が対応しているか否かを判別することや、対応するプログラム２５を選択することも可能になる。また、セキュリティの観点からも、対応するノードのメンテナンスが簡単になるというメリットがある。本実施の形態においては、かかるＯＳ種別欄４７Ｄに、対応するノードが使用するＯＳの種別を記載することとしているが、その他のＯＳについても同様に記述することも可能である。

アーキテクチャ欄４７Ｅには、対応するノードのＯＳが対応可能なＣＰＵアーキテクチャが格納される。ＯＳ種別欄４７Ｄに格納されたＯＳ種別と同様に、このアーキテクチャ欄４７Ｅに格納されているＣＰＵアーキテクチャに基づいて、個々のプログラム２５がそのノードに対応しているか否かを判別することや、対応するプログラム２５を選択することも可能になる。なおサーバ論理情報管理テーブル４７内に記述されている特定のＣＰＵアーキテクチャ以外についても同様に記述することが可能である。

ホスト名欄４７Ｆには、対応するノードにアクセス可能なホスト（物理サーバ４及び仮想サーバ３１）のホスト名が格納される。データセンタの運用ポリシーによって、ホスト名を限定して接続を試みることが可能である。これにより、接続できる可能性が飛躍的に向上し、情報取得の効率化及び確実化に貢献する。接続に成功した結果（ホスト名）を、ホスト名欄４７Ｆに格納する。

ＩＤ／ＯＳパスワード欄４７Ｇには、対応するノードが使用するＯＳのパスワードが格納される。ホスト名欄４７Ｆと同様に、情報を収集する上で必要な情報であり、データセンタの運用ポリシーから得られる情報を元にする。接続に成功した結果を、ＩＤ／ＯＳパスワード欄４７Ｇに格納する。

ＩＰ情報欄４７Ｈには、対応するノードに関するＩＰアドレス、サブネットマスク、デフォルトゲートウェイなどのＩＰ情報が格納される。後述のようにデータセンタの運用ポリシーに応じて、ＩＰアドレスの範囲を指定することで、走査が可能になる。ＩＰアドレスは、システム管理者やアプリケーションによっては、そのノードを識別する識別子となる可能性がある。

プログラム欄４７Ｉには、対応するノードに実装された、業務を提供するために必要なミドルウェアやアプリケーションのプログラム名や、これらのバージョン情報などが格納される。このプログラム欄４７Ｉに格納された情報と連携することで、配信するプログラム２５のバージョンを変えることが可能となる。これにより、対応するノードに対する管理レベルが変わり、物理サーバ４や仮想サーバ３１に負荷をかけるがＯＳやハードウェアと密な連携が可能なプログラム２５を配信したり、逆に物理サーバ４や仮想サーバ３１に負荷をかけない代わりにＯＳやハードウェアとの連携が疎なプログラム２５を配信する、といった管理が可能になる。これは、業務やアプリケーションによって、必要とされるプログラムの機能が異なることから必要となる管理方針の使い分け（ポリシー管理）である。

プログラム固有設定欄４７Ｊには、対応するノードの固有情報が格納される。例えば、対応するプログラムで使用するＩＰアドレス（論理ＩＰアドレス）やポート番号などである。ポート番号は、重複するとソフトウェアが起動しなかったり、起動しても正常に動作できない場合がある。このため重複を避けるためにも各プログラムで使用するポート番号等の値を情報収集しておくことで、トラブルを回避することができる。プログラム２５を配信しインストールする際に、使用するポートを変更することも可能になる。

本情報については、ＯＳの標準インタフェースを使って、使用しているポートや提供しているサービスを取得することによって推定することが可能である。また、他のプログラムと共存する条件をデータセンタの運用ポリシーで決まっている場合には、プログラム２５を配信して良いか否かを判定することが可能になる。例えば、ＪＲＥ（Java（登録商標） Runtime Environment）といった動作環境に関する制限事項が該当する。

管理手段欄４７Ｋには、対応するノードを管理する管理手段が格納される。例えばプログラム２５を用いてそのノードを管理する場合には、そのプログラム２５の識別子が格納される。また、かかるノードをＯＳの標準インタフェースを使用して管理する場合や、標準化されたインタフェースを利用して管理する場合には、管理モデルや通信プロトコルなどが管理手段欄４７Ｋに格納される。管理手段欄４７Ｋについては、情報収集の際には値が格納されない。管理手段を決定する管理手段判定プログラム４４（図２）によって、その後に情報が格納される。

このサーバ論理情報管理テーブル４７は、基本的に初期時には情報が格納されておらず、サーバ走査プログラム４０（図２）により新規ノード（物理サーバ４、仮想化機構３０及び又は仮想サーバ３）が検出されるごとに、その新規ノードに関する各種情報が収集されて、これらの情報のうちの必要な情報がサーバ論理情報管理テーブル４７に格納される。

他方、サーバモデル情報管理テーブル４８は、サーバ管理テーブル４６（図６）に登録されたノード間の階層構造（サーバモデル）を管理するためのテーブルであり、図８に示すように、物理サーバ欄４８Ａ、仮想化機構欄４８Ｂ及び仮想サーバ欄４８Ｃから構成される。

そして物理サーバ欄４８Ａには、管理サーバ２が管理するノードのうちの各物理サーバ４のノード識別子がそれぞれ格納され、仮想化機構欄４８Ｂには、その物理サーバ４に実装された仮想化機構３０のノード識別子が、当該物理サーバ４のノード識別子と関連付けて格納される。なお、仮想化機構欄４８Ｂには、図９について後述する仮想化機構識別子も格納するようにしても良い。さらに仮想サーバ欄４８Ｃには、その仮想化機構３０上に設定された仮想サーバ３１のノード識別子が、当該仮想化機構３０のノード識別子と関連付けて格納される。

このサーバモデル情報管理テーブル４８は、基本的に初期時には情報が格納されておらず、サーバ走査プログラム４０（図２）により新規ノードが検出されるごとに、その新規ノードに関する各種情報が収集されて、そのノード識別子が関連付けてサーバモデル情報管理テーブル４８に格納される。

このサーバモデル情報管理テーブル４８により、物理サーバ４、仮想化機構３０及び仮想サーバ３１のトポロジを把握することができるため、仮想サーバ３１にはプログラム２５を配信するが物理サーバ４や仮想化機構３０にはプログラム２５を配信しない、仮想サーバ３１が存在しない物理サーバ４にプログラム２５を配信する、といった判定が可能になる。

なお、かかる判定の際には、電源がオフになっている仮想サーバ３１のノード識別子も仮想サーバ欄４８Ｃに格納されていることが重要であり、このノード識別子が登録されていない場合、配信すべきでない物理サーバ４にプログラム２５を配信してしまうミスが発生する。従って、電源がオフされた仮想サーバ３１をも考慮することで、このようなミスを回避することができる。

本サーバモデル情報管理テーブル４８が完成することで、夫々のノードの管理手段を判定することが可能になり、図７について上述したサーバ論理情報管理テーブル４７の管理手段欄４７Ｋに格納する値を決定することができる。

仮想化機構管理テーブル４９は、仮想化機構３０の種別ごとのアクセス方法やプログラムのインストールの可否を管理するために、システム管理者が作成するテーブルであり、図９に示すように、仮想化機構識別子欄４９Ａ、仮想化機構種別欄４９Ｂ、識別欄４９Ｃ及びプログラムインストール可否欄４９Ｄから構成される。

そして仮想化機構識別子欄４９Ａには、システム管理者が各仮想化機構３０に対して付与した識別子（以下、これを仮想化機構識別子と呼ぶ）が格納され、仮想化機構種別欄４９Ｂには、対応する仮想化機構３０に関する製品情報が格納される。具体的には、対応する仮想化機構３０を製造販売しているベンダのベンダ名や製品名などが格納される。

また識別欄４９Ｃは、取得先欄４９Ｅ、方法欄４９Ｆ及びプロトコル欄４９Ｇから構成される。そして取得先欄４９Ｅには、上述のサーバ管理テーブル４６（図６）やサーバモデル情報管理テーブル４８（図８）に格納する情報を取得する際の情報取得先（情報元）が格納される。例えば、仮想サーバ３１や仮想化機構管理用インタフェース３６（図４）を利用して仮想化機構３０や仮想サーバ３１の情報を取得したり、仮想化機構３０が稼動する物理サーバ４の識別子（ＵＵＩＤなど）を取得する場合には、その仮想サーバ３１のノード識別子や仮想化機構管理用インタフェース３６の識別子などが格納される。

また方法欄４９Ｆには、対応する仮想化機構３０やその仮想化機構３０が稼動する物理サーバ４の識別方法が格納される。例えば、仮想化レイヤ及び仮想化種別（図６参照）に関する情報を取得し、当該情報に基づいてそのノードが仮想化機構３０であるか否かを識別する場合には、その旨が格納される。また仮想サーバ３１から、仮想サーバ３１に対応する仮想化機構３０の種別や仮想化機構３０及び物理サーバ４の識別子（ＵＵＩＤなど）を取得して仮想化機構３０及び当該仮想化機構３０が稼動する物理サーバ４を識別する場合には、その旨が格納される。

さらにプロトコル欄４９Ｇには、取得先欄４９Ｅに格納された取得先に接続するためのプロトコルや情報収集する際のデータモデルが格納される。この運用ポリシーにより、相手及び方法を特定した情報収集が可能となる。

プログラムインストール可否欄４９Ｄは、物理サーバ欄４９Ｈ、仮想化機構欄４９Ｉ及び仮想サーバ欄４９Ｊから構成される。そして物理サーバ欄４９Ｈには、対応する仮想化機構３０が稼動する物理サーバ４に対してプログラム２５をインストールしても良いか否か（「可」又は「否」）を表す情報が格納され、仮想化機構欄４９Ｉには、対応する仮想化機構３０にプログラム２５をインストールしても良いか否かを表す情報が格納される。さらに仮想サーバ欄４９Ｊには、その仮想化機構３０上で稼動する仮想サーバ４１に対してプログラム２５をインストールしても良いか否かを表す情報が格納される。

なお、かかる物理サーバ欄４９Ｈ、仮想化機構欄４９Ｉ及び仮想サーバ欄４９Ｊに格納される情報には、それぞれ予めデフォルト値が用意されており、これら物理サーバ欄４９Ｈ、仮想化機構欄４９Ｉ及び仮想サーバ欄４９Ｊに情報が格納されていない場合には、その物理サーバ４、仮想化機構３０又は仮想サーバ３１について、対応するデフォルト値が適用される。一例として、当初の目的に沿って、物理サーバ４及び仮想化機構３０のデフォルト値は「否」、仮想サーバ３１のデフォルトは「可」とすることが考えられる。

一方、データセンタ運用ポリシー管理テーブル５０は、そのデータセンタにおける運用ポリシーに応じたルールを管理するためのテーブルであり、図１０示すように、ルール識別子欄５０Ａ、ルールパラメータ欄５０Ｂ、パラメータ固定値欄５０Ｃ、パラメータ範囲欄５０Ｄ、例外パラメータ欄５０Ｅ及び走査方法欄５０Ｆから構成される。

そしてルール識別子欄５０Ａには、そのデータセンタにおける運用ポリシーに応じた各ルールにそれぞれ付与された識別子（以下、これをルール識別子と呼ぶ）が格納され、ルールパラメータ欄５０Ｂには、対応するルールの適応対象となるパラメータが格納される。このパラメータとしては、ＩＰアドレスや、ホスト名、ＩＤ及びパスワードなどがある。

またパラメータ固有値欄５０Ｃには、そのデータセンタにおける運用ポリシーによりそのパラメータについて規定された当該パラメータの固有値が格納され、パラメータ範囲欄５０Ｄには、そのデータセンタにおける運用ポリシーによりそのパラメータについて規定されたかかるパラメータの範囲が格納される。

例えば図１０の例では、ＩＰアドレスについての運用ポリシーとして、ＩＰアドレスの範囲が「192.168.0.0」〜「192.168.255.255」及び「192.168.200.10」に規定されていることが示されている。また図１０では、ホスト名についての運用ポリシーとして、「hostname」という「固定値」及び「昇順の整数列」の組合せの命名規則に沿って、「hostname0001」、「hostname0002」、「hostname0003」、……、「hostname1000」といった具合にホスト名を命名すべきことが示されている。

さらに例外パラメータ欄５０Ｅには、パラメータ範囲欄５０Ｄにおいて規定したパラメータ範囲の例外の値が格納する。例えば図１０の例では、ホスト名として、「hostname0500」〜「hostname0550」の範囲は使用（命名）しないことが示されている。

さらに走査方法欄５０Ｆには、管理サーバ２が自己に接続されたノードからＩＰアドレスやホスト名などのパラメータの値を収集する際の収集方法（走査方法）が格納される。例えば図１０の例では、ＩＰアドレスについては、「ping」により各ノードからＩＰアドレスを収集すべきことが規定されている。

この場合において、走査方法欄５０Ｆに複数の走査方法が登録されていても構わない。接続プロトコルが複数許可されているケースがこれに該当する。例えば図１０の例では、ホスト名については、「ＳＳＨ（Secure SHell）」と、運用ポリシーの「ルール３及びルール４の組合せ」たルールとにより各ノードからホスト名を収集すべきことが規定されている。

以上のことから、図１０の例の場合、管理サーバ２は、自己に接続された各ノードのＩＰアドレスを収集する際には、「ルール１」に従って、「ping」により「192.168.0.0」〜「192.168.0.2」及び「192.168.100.1」を除く「192.168.0.0」〜「192.168.255.255」及び「192.168.200.10」の範囲を走査し、反応が返ってきたＩＰアドレスについて、ノードが存在すると判断してサーバ管理テーブル４６（図６）に登録する処理を行うことになる。

なお図１０の「ルール２」は、各ノードにそれぞれ付与する「ホスト名」に関する運用ポリシーであり、ホスト名を使ってサーバへ接続を試みる場合に活用される。また図１０の「ルール３」は、各ノードにそれぞれ登録するユーザの「ＩＤ」に関する運用ポリシーであり、これらノードにログインして情報を収集する際に、後述のパスワードと組で利用される。

さらに図１０の「ルール４」は、各ノードにそれぞれ設定するログイン用の「パスワード」に関する運用ポリシーであり、そのノードにログインして情報を収集する際に用いられる。ＳＳＨやtelnetを使ってノードに接続する際に用いられる。

さらに図１０の「ルール５」は、「ハードベンダ」に関する運用ポリシーである。ハードベンダには、物理サーバ４や仮想サーバ３１を提供するベンダやサーバ仮想化製品を提供するベンダがあるが、ベンダによって情報収集する際の接続インタフェースやプロトコルが異なる場合がある。従って、この情報は、ノードにアクセスして情報収集する際の接続インタフェースやプロトコルを認識するために活用される。

一方、図１０の「ルール６」は、各ノードが利用する「ＯＳ」に関する運用ポリシーである。ＯＳによって、標準提供されるインタフェースや情報モデルが異なる。このためこの情報は、ノードにアクセスして情報を収集する際に活用される。

また図１０の「ルール７」は、各ノードにそれぞれ実装する「ミドルウェア」や「アプリケーション」に関する運用ポリシーである。ＯＳと同様に、ミドルウェアやアプリケーションごとに情報収集の際にアクセスするポートやインタフェース、情報モデルが異なる。情報収集の際、数多存在する接続方法の中から、各ミドルウェアやアプリケーションで許可されている、又は実装されている情報取得方法を、なんの情報もない状態から見つけることは容易でない。そこで、かかる情報収集の際にこの情報が利用される。

さらに図１０の「ルール８」は、各ノードに設ける「管理用インタフェース」に関する運用ポリシーである。管理インタフェースが標準化されたインタフェースの場合、異なるベンダが提供するプラットフォームを管理することが可能である。この情報は、各プラットフォームに関する情報収集だけでなく、値の設定及び各プラットフォームの制御に用いられる。

他方、図１０の「ルール９」は、プログラム２５の一例である「エージェントプログラム」に関する運用ポリシーである。配信が許可されるエージェントプログラムのバージョンが規定されている。

また図１０の「ルール１０」は、物理サーバ４に実装される「仮想化機構」に関する運用ポリシーである。ＯＳと同様に、サーバ仮想化製品によって、提供する管理方法や管理インタフェース、プロトコルが異なる。情報収集だけでなく、値の設定や仮想化機構の制御に用いられる情報である。各仮想化機構３０で許可されている、又は実装されている情報取得方法を、なんの情報もない状態から見つけることは容易でない。そこで、本情報によって、サーバ走査プログラム４０によるサーバ走査処理において検出した仮想化機構３０を絞り込み、情報収集することが可能になる。

さらに図１０の「ルール１１」は、物理サーバ４に搭載されるサービスプロセッサのＩＰアドレスに関する運用ポリシーである。第２の実施の形態において後述するように、物理サーバ４に搭載されたサービスプロセッサを経由して情報を収集することができるプラットフォームが存在する。この場合、管理対象サーバではないが「ping」に反応する管理インタフェースが存在する。そこで本情報は、サービスプロセッサを通して各ノードの情報を収集する際に利用される。

プログラム管理テーブル５１は、ノードに配信するプログラム２５を、当該プログラム２５の配信元である管理サーバ２が管理するためのテーブルであり、図１１に示すように、プログラム識別子欄５１Ａ、配布先サーバ種別欄５１Ｂ、配布先プラットフォーム種別欄５１Ｃ、ライセンス欄５１Ｄ及び管理レベル欄５１Ｅから構成される。

そしてプログラム識別子欄５１Ａには、１又は複数種類存在するプログラム２５にそれぞれ付与された識別子（以下、これをプログラム識別子と呼ぶ）が格納され、配布先サーバ種別欄５１Ｂには、対応するプログラム２５を配信布可能なノードの種別（ベンダ名及びモデル名等）が格納される。機種によって、配信するプログラム２５を変える必要がある場合、この値を参照することで対応が可能となる。

また配布先プラットフォーム種別欄５１Ｃには、配布先のノードにおける対応可能なプラットフォームの種別が格納される。具体的には、ＣＰＵアーキテクチャやＯＳ種別がこの配布先プラットフォーム種別欄５１Ｃに格納されることになる。配布先サーバ種別欄５１Ｂに格納されるサーバ種別と同様、環境に応じて配信するプログラム２５を変える必要がある場合に、この値を参照することで対応が可能になる。

一方、ライセンス欄５１Ｄは、使用数欄５１Ｆ、残数欄５１Ｇ及び有効期限欄５１Ｈから構成される。そしてこれら使用数欄５１Ｆ、残数欄５１Ｇ及び有効期限欄５１Ｈには、それぞれ対応するプログラム２５の現在の使用数、ライセンスの残数又は有効期限が格納される。この情報により、ライセンスがオーバーしないように配布抑止をしたり、ライセンスの有効期限切れやライセンス不足などに関するアラートをシステム管理者に表示及び通知することが可能になる。管理サーバ２側に、本プログラム管理テーブル５１を更新したり参照するインタフェースをもたせることで、管理の利便性の向上を図ることができる。なおプログラム２５を配信成功した時点で、管理サーバ２が使用数欄５１Ｆや残数欄５１Ｇを更新することは可能であるが、初期設定はユーザが行う必要がある。

また管理レベル欄５１Ｅには、対応するプログラム２５と、配布先のノードのＯＳやハードウェアとの連携の度合いを表す管理レベルが格納される。プログラム２５の中には、ノードに負荷をかけるがＯＳやハードウェアと密な連携が可能なプログラム、逆にノードに負荷をかけない代わりにＯＳやハードウェアとの連携が疎なプログラムが存在する。業務やアプリケーションによって、必要とされるプログラムの機能が異なることから必要となる管理方針の使い分け（ポリシー管理）が可能になる。

本実施の形態においては、管理レベルとして「疎」及び「密」の２段階しか記載していないが、さらに多段階することで細かな使い分けが可能になる。また、１段階しか用意しないケースも許容し、その場合においても後述する本実施の形態による効果は保たれる。

（１−２−３）本実施の形態によるプログラム配信方法に関する処理
（１−２−３−１）プログラム配信処理
次に、本実施の形態によるプログラム配信方法に関する処理の流れについて説明する。このプログラム配信処理は、図１１に示す以下の手順で行なわれる。

すなわち、管理サーバ２のサーバ走査プログラム４０は、所定の監視契機が到来すると、当該管理サーバ２に接続されたノードを検出するための所定のサーバ走査処理を実施する（ＳＰ１０）。

ここで「監視契機」とは、定期的な監視、スケジュールに基づいた監視などである。ＵＩ（User Interface）を介して、ユーザが契機を与えても良い。プログラムのインストール若しくはアンイストール又はアップデートなどによりソフトウェアの構成が変更されたことを監視契機としても良い。また仮想サーバ３１及び仮想化機構３０の構成や種類又はバージョンが変更されたタイミングや、物理サーバ４のデバイス構成が変更されたタイミング、これらをユーザに通知するアラートを監視契機とすることもできる。

かかるサーバ走査処理により新たなノードが検出された場合、管理サーバ２のサーバ登録プログラム４１が、そのノードをサーバ管理テーブル４６（図２）及びサーバ論理情報管理テーブル４７（図２）に登録する（ＳＰ１１）。

続いて管理サーバ２のサーバ構成取得プログラム４２が、その新規ノードの構成情報を取得し、取得した構成情報に基づいてサーバ管理テーブル４６及びサーバ論理情報管理テーブル４７を更新する（ＳＰ１２）。

次いで、管理サーバ２の仮想化機構構成生成プログラム４３が、サーバ管理テーブル４６及びサーバ論理情報管理テーブル４７を参照して、サーバモデル情報管理テーブル４８を生成する（ＳＰ１３）。このとき生成されたサーバモデル情報管理テーブル４８により、新規ノード間のトポロジ（新たな物理サーバ４、仮想化機構１０３及び仮想サーバ１０４のトポロジ）が明らかになる。

この後、管理サーバ２の管理手段判定プログラム４４が、ステップＳＰ１０のサーバ走査処理により検出した新規ノードごとに、プログラム２５を配信するか、プログラム２５を配信せずに別の管理方法で管理を行うかを判定する（ＳＰ１４）。そしてこのステップＳＰ１４において、かかる新規ノードに対してプログラム２５を配布しないと管理手段判定プログラム４４が判定した場合には、このプログラム配信処理が終了する。

これに対してステップＳＰ１４において、かかる新規ノードに対してプログラム２５を配布すると管理手段判定プログラム４４が判定した場合には、管理サーバ２の配信実行プログラム４５が、そのプログラム２５の配布対象となる新規ノードに対して対応するプログラムを配信し（ＳＰ１５）、この後、このプログラム配信処理が終了する。

（１−２−３−２）サーバ走査処理
図１３は、かかるプログラム配信処理のステップＳＰ１０におけるサーバ走査プログラム４０の具体的な処理内容を示している。

サーバ走査プログラム４０は、管理サーバ２の起動後にこの図１３に示すサーバ走査処理を開始し、この後所定の監視契機が到来するのを待ち受ける（ＳＰ２０）。そしてサーバ走査プログラム４０は、かかる監視契機が到来すると、データセンタ運用ポリシー管理テーブル５０（図１０）を参照し（ＳＰ２１）、当該データセンタ運用ポリシー管理テーブル５０に格納されているルールに則り、指定された走査方法で自管理サーバに接続されたノードを検索する。

具体的に、サーバ走査プログラム４０は、データセンタ運用ポリシー管理テーブル５０に格納されているＩＰアドレスの範囲内のすべてのＩＰアドレスについて、そのＩＰアドレスを宛先とするpingパケットを発信し、当該pingパケットに対するノードからの返信を待ち受ける。そしてサーバ走査プログラム４０は、返信があったＩＰアドレスを記録し、そのＩＰアドレスが付与されたノードを検出したものと判定する。

また、サーバ走査プログラム４０は、データセンタ運用ポリシー管理テーブル５０の走査方法欄５０Ｆ（図１０）に格納されているプロトコル（例えば、ＳＳＨ）によって、ホスト名を指定した方法による接続を試みる。ログインが成功する必要はなく、接続を受け付ける状態であればそのホスト名を有するノードが存在することになるため、ノードを検出したものと判定する。なお、かかるノードの存在を確認する方法としては、これら以外の方法を用いても良い。

そしてサーバ走査プログラム４０は、この後、サーバ登録プログラム４１を起動したうえでこのサーバ走査処理を終了する。

（１−２−３−３）サーバ登録処理
一方、サーバ登録プログラム４１は、サーバ走査プログラム４０により起動されると、図１４に示すサーバ登録処理手順に従って、図１２について上述したプログラム配信処理のステップＳＰ１１を処理する。

すなわちサーバ登録プログラム４１は、まず、サーバ走査処理により検出された１つのノードを選択し、サーバ管理テーブル４６（図６）及びサーバ論理情報管理テーブル４７（図７）を参照して、そのノードがサーバ管理テーブル４６及びサーバ論理情報管理テーブル４７に登録されていない新規ノードであるか否かを判断する（ＳＰ３０）。

例えばそのノードをpingで発見した場合には、ＩＰアドレスが判明しているため、サーバ登録プログラム４１は、サーバ論理情報管理テーブル４７の各ＩＰ情報欄４７Ｈ（図７）にそれぞれ格納されているＩＰ情報を参照して、そのとき対象としているノードのＩＰアドレスがサーバ論理情報管理テーブル４７のいずれかのＩＰ情報欄４７Ｈに格納されているか否かを判断する。

そしてサーバ登録プログラム４１は、かかる判断において肯定結果を得たときにはステップＳＰ３２に進み、これに対して肯定結果を得たときには、図１３について上述したサーバ走査処理のステップＳＰ２２において受信したそのノードからの返信に含まれる各種情報のうちの必要な情報を、サーバ管理テーブル４６及びサーバ論理情報管理テーブル４７に新規に登録する（ＳＰ３１）。

次いでサーバ登録プログラム４１は、サーバ走査処理において検出したすべてのノードについて同様の処理を終えたか否かを判断し、否定結果を得るとステップＳＰ３０に戻る。そしてサーバ登録プログラム４１は、この後、ステップＳＰ３０において選択するノードを順次他のノードに切り換えながら、同様の処理を繰り返す（ＳＰ３０〜ＳＰ３２−ＳＰ３０）。

そしてサーバ登録プログラム４１は、やがてサーバ走査処理において検出したすべてのノードについて同様の処理を終えると、サーバ構成取得プログラム４２を起動したうえでこのサーバ登録処理を終了する。

（１−２−３−４）サーバ構成取得処理
他方、サーバ構成取得プログラム４２は、サーバ登録プログラム４１により起動されると、図１５に示すサーバ構成情報処理手順に従って、図１２について上述したプログラム配信処理のステップＳＰ１２を処理する。

すなわちサーバ構成取得プログラム４２は、まず、サーバ管理テーブル４０（図６）を参照して、当該サーバ管理テーブル４０上の１つの新規エントリを選択する。そしてサーバ構成取得部４２は、選択した新規エントリの登録済みの情報をサーバ管理テーブル４０から読み出す（ＳＰ４０）。

続いてサーバ構成取得プログラム４２は、サーバ論理情報管理テーブル４７（図７）を参照して、ステップＳＰ４０において選択した新規エントリに対応するサーバ論理情報管理テーブル４７上のエントリを検出し、そのエントリの登録済みの情報を読み出す（ＳＰ４１）。

次いでサーバ構成取得プログラム４２は、データセンタ運用ポリシー管理テーブル５０（図１０）を参照して、ステップＳＰ４０においてサーバ管理テーブル４６から読み出した情報と、ステップＳＰ４１においてサーバ論理情報管理テーブル４７から読み出した情報とに基づいて、新規のエントリに対応する新規ノードからその構成情報を取得するためのルールを読み出す（ＳＰ４２）。

この後、サーバ構成取得プログラム４２は、ステップＳＰ４２において取得したルールごとに指定された走査方法でかかる新規ノードを走査し、当該新規ノードからその構成情報を取得する（ＳＰ４３）。例えば、サーバ構成取得プログラム４２は、ＩＰアドレスを用い、データセンタ運用ポリシー管理テーブル５０から読み出したＩＤとパスワード情報を用いて、新規ノードにログインする。その後、ＷＭＩ（Windows（登録商標） Management Instrumentation）を用いて、その新規ノードやＯＳに関する情報を取得する。

続いてサーバ構成取得プログラム４２は、ステップＳＰ４３において取得した新規ノードの構成情報に基づいてサーバ管理テーブル４６及びサーバ論理情報管理テーブル４７をそれぞれ更新する（ＳＰ４４，ＳＰ４５）。この際、サーバ構成取得プログラム４２は、ステップＳＰ４３において新規ノードへの接続に成功したＩＤ及びパスワードを、サーバ論理情報管理テーブル４７の対応するエントリの管理手段欄４７Ｋ（図７）に格納する。

さらにサーバ構成取得プログラム４２は、サーバ管理テーブル４０上のすべての新規エントリに対してステップＳＰ４０〜ステップＳＰ４５の処理を終えたか否かを判断し（ＳＰ４６）、否定結果を得るとステップＳＰ４０に戻る。そしてサーバ構成取得プログラム４２は、この後、ステップＳＰ４０において選択するサーバ管理テーブル４０上の新規エントリを順次他の新規のエントリに切り換えながら、同様の処理を繰り返す（ＳＰ４０〜ＳＰ４６−ＳＰ４０）。

そしてサーバ構成取得プログラム４２は、やがてサーバ管理テーブル４０上のすべての新規エントリに対する同様の処理を終えると、仮想化機構構成生成プログラム４３を起動したうえでこのサーバ構成取得処理を終了する。

（１−２−３−５）仮想化機構構成生成処理
図１６は、図１２について上述したプログラム配信処理のステップＳＰ１３における仮想化機構構成生成プログラム４３の具体的な処理内容を示す。仮想化機構構成生成プログラム４３は、サーバ構成取得プログラム４２により起動されると、この図１６に示す仮想化機構構成生成処理手順に従って、プログラム配信処理のステップＳＰ１３を処理する。

すなわち仮想化機構構成生成プログラム４３は、まず、サーバ管理テーブル４６を参照して、当該サーバ管理テーブル４０上の新規エントリを１つ選択する。そして仮想化機構構成生成プログラム４３は、選択した新規エントリの登録済みの情報をサーバ管理テーブル４６から読み出す（ＳＰ５０）。

続いて仮想化機構構成生成プログラム４３は、データセンタ運用ポリシー管理テーブル５０を参照して、ステップＳＰ５０において選択した新規エントリに対応する仮想化機構３０の種別と走査方法をデータセンタ運用ポリシー管理テーブル５０から読み出す（ＳＰ５１）。

次いで仮想化機構構成生成プログラム４３は、仮想化機構管理テーブル４９を参照して、ステップＳＰ５１において得られた仮想化機構３０の種別と照らし合わせ、その仮想化機構３０を識別するための識別情報の取得先、取得方法及び取得時に使用するプロトコルを仮想化機構管理テーブル４９の識別欄４９Ｃ（図９）からを読み出す（ＳＰ５２）。なお、かかる識別情報の取得先としては、図９に示すように、仮想化機構管理インタフェース３６（図４）や、いずれかの仮想サーバなどが挙げられる。また識別情報の取得先として、サービスコンソールを挙げることもできる。サービスコンソールは、仮想サーバ３１のうちで管理用として特別に設けられた仮想サーバで、管理用の情報取得インタフェース及び制御インタフェースを備える。

続いて仮想化機構構成生成プログラム４３は、ステップＳＰ５０において検出した新規ノードに対する接続を試行し（ＳＰ５３）、この後、かかる接続が成功したか否かを判定する（ＳＰ５４）。

仮想化機構構成生成プログラム４３は、この判定において否定結果を得ると、この仮想化機構構成生成処理を終了し、これに対して肯定結果を得ると、接続先の新規ノードからその新規ノードの仮想化種別及び仮想レイヤに関する情報を取得する（ＳＰ５５，ＳＰ５６）。そして仮想化機構構成生成プログラム４３は、このようにして取得したこれらの情報（仮想化種別及び仮想レイヤ）をサーバ管理テーブル４６に格納する（ＳＰ５７）。

続いて仮想化機構構成生成プログラム４３は、かかる接続先の新規ノードから必要なノード識別子をそれぞれ取得する（ＳＰ５８〜ＳＰ６０）。

具体的に仮想化機構構成生成プログラム４３は、かかる接続先が物理サーバ４である場合には、その物理サーバ４のノード識別子、その物理サーバ４上で稼動する仮想化機構３０のノード識別子及びその仮想化機構３０により提供される各仮想サーバ３１のノード識別子をそれぞれその物理サーバ４から取得する。

また仮想化機構構成生成プログラム４３は、かかる接続先が仮想化機構３０である場合には、その仮想化機構３０が稼動する物理サーバ４のノード識別子、当該仮想化機構３０のノード識別子及び当該仮想化機構３０が提供する各仮想サーバ３１のノード識別子をそれぞれその仮想化機構３０から取得する。

さらに仮想機構構成生成プログラム４３は、かかる接続先が仮想サーバ３１である場合には、その仮想サーバ３１が作成された物理サーバ４のノード識別子、その仮想サーバ３１を提供する仮想化機構３０のノード識別子及び当該仮想化機構３０に提供されるその仮想サーバ３１を含むすべての仮想サーバ３１のノード識別子をそれぞれその仮想サーバ３１から取得する。

続いて仮想機構構成生成プログラム４３は、サーバ管理テーブル４０上のすべての新規エントリに対してステップＳＰ５０〜ステップＳＰ６０の処理を終えたか否かを判断し（ＳＰ６１）、否定結果を得るとステップＳＰ５０に戻る。そして仮想機構構成生成プログラム４３は、この後、ステップＳＰ５０において選択するサーバ管理テーブル４０上の新規エントリを順次他の新規のエントリに切り換えながら、同様の処理を繰り返す（ＳＰ５０〜ＳＰ６０−ＳＰ５０）。

そして仮想機構構成生成プログラム４３は、やがてサーバ管理テーブル４０上のすべての新規エントリに対する同様の処理を終えると、上述のようにして得られた各新規ノードのノード識別子を、新規ノード間の親子関係（新たな物理サーバ４、仮想化機構４０及び仮想サーバ３１のトポロジ）に応じて関連付けた状態でサーバモデル情報管理テーブル４８に格納する（ＳＰ６２）。

以上の処理により、サーバモデル情報管理テーブル４８が完成し、物理サーバ４、仮想化機構３０及び仮想サーバ３１のトポロジが明らかになる。これにより、仮想サーバ３１が稼動する仮想化機構３０や物理サーバ４に対するプログラム２５の配信を抑止することが可能になる。

そして仮想機構構成生成プログラム４３は、この後、管理手段判定プログラム４４を起動したうえで、この仮想化機構構成生成処理を終了する。

（１−２−３−６）管理手段判定処理

管理手段判定プログラム４４は、仮想化機構構成生成プログラム４３により起動されると、図１７に示す管理手段判定処理手順に従って、図１２について上述したプログラム配信処理のステップＳＰ１４を処理する。

すなわち管理手段判定プログラム４４は、まず、サーバ管理テーブル４６を参照して、当該サーバ管理テーブル４６上の新規エントリを１つ選択する。そして管理手段判定プログラム４４は、選択した新規エントリの登録済みの情報（ノード識別子、仮想化種別及び仮想化レイヤ）をサーバ管理テーブル４６から読み出す（ＳＰ７０）。

続いて管理手段判定プログラム４４は、ステップＳＰ７０において検出した各新規エントリに対応する新規ノードの仮想化レイヤをサーバモデル情報管理テーブル４８からそれぞれ読み出す（ＳＰ７１）。

次いで管理手段判定プログラム４４は、その新規ノード対するプログラム２５のインストールの可否に関する情報を仮想化機構管理テーブル４９の対応するプログラムインストール可否欄４９Ｄから読み出す（ＳＰ７２）。

さらに管理手段判定プログラム４４は、プログラム管理テーブル５１を参照して、その新規ノードのハードウェアやＯＳ情報と合致するプログラム２５が存在するか否かの判定及びそのプログラム２５のライセンス情報の確認を行う（ＳＰ７３）。

そして管理手段判定プログラム４４は、この後、かかる新規ノードにプログラム２５を配信するか否かを判定する（ＳＰ７４）。具体的には、管理手段判定プログラム４４は、その新規ノードのハードウェアやＯＳ情報と合致するプログラム２５が存在すると共に、そのプログラム２５のライセンスが残っており、かつその新規ノードに対してプログラム２５を配信可能か否かを判断することになる。そしてこれらの条件をすべて満たすときに、その新規ノードについて、このステップＳＰ７４において肯定結果が得られることになる。

そして管理手段判定プログラム４４は、ステップＳＰ７４の判断において肯定結果を得るとステップＳＰ７６に進み、これに対して否定結果を得ると、その新規ノードに対する管理手段として、プログラム２５を用いない他の管理手段を決定する（ＳＰ７６）。例えば、図１５について上述したサーバ構成取得処理のステップＳＰ４３においてサーバ構成取得プログラム４２が構成情報を収集したときに成功した接続方法がサーバ論理情報管理テーブル４７の管理手段欄４７Ｋ（図７）に格納されているため、管理手段判定プログラム４４は、その接続方法を「他の管理手段」として決定する。

続いて管理手段判定プログラム４４は、プログラム２５を配信する場合はその旨、配信しない場合はステップＳＰ７５において決定した管理手段をサーバ論理情報管理テーブル４７の対応する管理手段欄４７Ｋに格納する（ＳＰ７６）。

さらに管理手段判定プログラム４４は、サーバ管理テーブル４０上のすべての新規エントリに対してステップＳＰ７０〜ステップＳＰ７６の処理を終えたか否かを判断し（ＳＰ７７）、否定結果を得るとステップＳＰ７０に戻る。そして管理手段判定プログラム４４は、この後、ステップＳＰ７０において選択するサーバ管理テーブル４０上の新規エントリを順次他の新規のエントリに切り換えながら、同様の処理を繰り返す（ＳＰ７０〜ＳＰ７７−ＳＰ７０）。

そして管理手段判定プログラム４４は、やがてサーバ管理テーブル４０上のすべての新規エントリに対する同様の処理を終えると、配信実行プログラム４５を起動したうえでこの管理手段判定処理を終了する。

（１−２−３−７）配信実行処理
配信実行プログラム４５は、管理手段判定プログラム４４により起動されると、図１８に示す配信実行処理手順に従って、図１２について上述したプログラム配信処理のステップＳＰ１５を処理する。

すなわち配信実行プログラム４５は、管理手段判定プログラム４４により起動されると、まず、図１７について上述した管理手段判定処理のステップＳＰ７４においてプログラム２５の配信対象として決定したノードを１つ選択し、そのノードに対して当該ノードに応じたプログラム２５を配信する（ＳＰ８０）。

このときの配信方法としては、ＲＣＰ（Remote Copy）やＲＳＨ（Remote Shell）を使ってプログラム２５を配信しインストーラを実行する方法でも良いし、デプロイメイト用のソフトウェアを利用しても良い。配信する手順として、複数の手段を試行することで可能な方法を選択しても良い。

続いて配信実行プログラム４５は、ステップＳＰ８０における配信プログラムの配信結果に応じてプログラム管理テーブル５１のライセンス欄５１Ｄ（図１１）を更新する（ＳＰ８１）。

さらに配信実行プログラム４５は、管理手段判定処理（図１７）プログラム２５の配信対象として決定したすべてのノードに対してプログラム２５を配信し終えたか否かを判断し（ＳＰ８２）、否定結果を得るとステップＳＰ８０に戻る。そして配信実行プログラム４５は、この後ステップＳＰ８０において選択するノードを順次他のノードに切り換えながら、同様の処理を繰り返す（ＳＰ８０〜ＳＰ８２−ＳＰ８０）。

そして配信実行プログラム４５は、やがて対象となるすべてのノードに対する同様の処理を終えると、この配信実行処理を終了する。

（１−４）本実施の形態の効果
以上のように本実施の形態によるサーバシステム１では、管理サーバ２が、第１のネットワークスイッチ３を介して接続された各ノードの構成情報を収集し、この構成情報に基づいてプログラム２５を選択的に配信可能なノードに配信するため、仮想サーバ３１や、仮想化機構３０が稼動していない物理サーバ４に対してはプログラム２５を配信するが、プログラム２５が対応していない物理サーバ４及び仮想サーバ３１や、仮想化機構が稼動している物理サーバ４に対してはプログラム２５を配信しない、といった運用が可能となる。これによりシステム管理者の負担を軽減しながら利便性を向上させ得るサーバシステムを構築することができる。

（２）第２の実施の形態
図１との対応部分に同一符号を付した図１９は、第２の実施の形態によるサーバシステム６０を示す。このサーバシステム６０は、プログラム２５の配信対象がブレードサーバ６１である点が第１の実施の形態によるサーバシステム１（図１）と異なる。

ブレードサーバ６１には複数のシャーシ６２が設けられており、これらシャーシ６２に１又は複数の物理サーバ４が内包（挿入）されている。各シャーシ６２には、それぞれサービスプロセッサ６３が設置されており、このサービスプロセッサ６３によって同じシャーシ６２内の物理サーバ４を管理（情報取得、電源制御など）することができる。

管理サーバ６４は、サービスプロセッサ６３から同じシャーシ６１内の物理サーバ４の情報を取得することができる。また、管理サーバ６４は、かかる物理サーバ４上で稼動する仮想化機構３０や、当該仮想化機構３０により提供される仮想サーバ３１の情報を、同じシャーシ６２内のサービスプロセッサ６３と、仮想化機構３０の仮想化機構管理用インタフェース３６（図４）とを順次介して取得することができる。

図２３は、図６、図７、図９〜図１１について上述したサーバ管理テーブル４６、サーバ論理情報管理テーブル４７、仮想化機構管理テーブル４９、データセンタ運用ポリシー管理テーブル５０及びプログラム管理テーブル５１と共に管理サーバ６０の管理テーブル群６６（図１９）を構成する第２の実施の形態によるサーバモデル情報管理テーブル６７を示す。

本実施の形態においては、シャーシ６２（サービスプロセッサ６３）、物理サーバ４、仮想化機構３０及び仮想サーバ３１のトポロジが図２１のような階層構造を有するため、本実施の形態によるサーバモデル情報管理テーブル６７は、図８について上述した第１の実施の形態によるサーバモデル情報管理テーブル４８に対してサービスプロセッサ欄６７Ａを追加した構成となっている。

サービスプロセッサ６３から、物理サーバ４や仮想化機構３０の情報を取得し、サービスプロセッサ６３が仮想化機構管理用インタフェース３６（図４）から仮想サーバ３１の情報を取得することにより、このサーバモデル情報管理テーブル６７を作成することが可能である。

図２２は、図１２について上述したプログラム配信処理のステップＳＰ１２において行なわれる第２の実施の形態によるサーバ構成取得処理の流れを示している。このサーバ構成取得処理は、図２について上述したサーバ走査プログラム４０、サーバ登録プログラム４１、仮想化機構構成生成プログラム４３、管理手段判定プログラム４４及び配信実行プログラム４５と共に管理サーバ６４の制御プログラム群６５を構成する第２の実施の形態によるサーバ構成取得プログラム６８（図２）によって実行される。

すなわちサーバ構成取得プログラム６８は、サーバ登録プログラム４１により起動されると、このサーバ構成取得処理を開始し、ステップＳＰ９０〜ステップＳＰ９２を図１５について上述した第１の実施の形態によるサーバ構成取得処理のステップＳＰ４０〜ステップＳＰ４２と同様に処理する。

続いてサーバ構成取得プログラム６８は、ステップＳＰ９２において取得したルールごとに指定された走査方法でかかる新規ノードを走査し、当該新規ノードからその構成情報を取得する（ＳＰ９３）。本実施の形態においては、この際、サーバ構成取得プログラム６８が各新規ノードではなく、対応するシャーシ６２のサービスプロセッサ６３に接続することを特徴とする。

すなわちサーバ構成取得プログラム６８は、ステップＳＰ９２において取得したルールに基づき得られたサービスプロセッサ６３のＩＰアドレスとＩＤとパスワード情報を使って、サービスプロセッサ６３に接続し、実装されたＵＩを通じて情報を取得すると共に、物理サーバ４や仮想化機構３０の情報を取得する。また、サーバ構成取得プログラム６８は、サービスプロセッサ６３を介して仮想化機構管理用インタフェース３６（図４）を通じて仮想サーバ１０４の情報を取得する。ＯＳ情報は、第１の実施の形態で説明した方法により取得する。

このようにサービスプロセッサ６３を経由することで、すべてのノードへ接続を試行しなくても、同一シャーシ６２内に挿入された物理サーバ４（ブレード）の情報を確実に、かつ迅速に収集することが可能である。

そしてサーバ構成取得プログラム６８は、この後、ステップＳＰ９４〜ステップＳＰ９６を図１５について上述した第１の実施の形態によるサーバ構成取得処理のステップＳＰ４４〜ステップＳＰ４６と同様に処理し、この後このサーバ構成取得処理を終了する。

以上のように本実施の形態によるサーバシステム６０によれば、ブレードサーバ６１に対してもプログラム２５を選択的に配信することができる。

（３）他の実施の形態
なお上述の実施の形態においては、本発明を適用した管理サーバ２，６４を図１又は図１９のように構成するようにした場合について述べたが、本発明はこれに限らず、かかる管理サーバ２，６４の構成としては、この他種々の構成を広く適用することができる。

また上述の実施の形態においては、第１のネットワークスイッチ３を介して接続された、それぞれ物理サーバ４、仮想化機構３０及び仮想サーバ３１のいずれかからなる１又は複数のノードを検出する検出部を、管理サーバ２，６４のＣＰＵ１０及びサーバ走査プログラム４０により構成し、検出したノードごとに、当該ノードの仮想レイヤに関する第１の構成情報を取得する取得部を、管理サーバ２，６４のＣＰＵ１０及びサーバ構成取得プログラム４２により構成し、取得したノードごとの第１の構成情報に基づいて、プログラムを選択的に対応するノードに配信する配信部を管理サーバ２，６４のＣＰＵ１０と、仮想化機構構成生成プログラム４３、管理手段判定プログラム４４及び配信実行プログラム４５とで構成するようにした場合について述べたが、本発明はこれに限らず、これら検出部、取得部及び配信部の構成としては、この他種々の構成を広く適用することができる。

さらに上述の実施の形態においては、配信対象のプログラムが管理用のプログラム２５である場合について述べたが、本発明はこれに限らず、かかるプログラム２５以外のプログラムを配信する際にも本発明を適用することができる。

本発明は、サーバシステムの管理サーバのほか、種々の情報処理装置に広く適用することができる。

１，６０……サーバシステム、２，６４……管理サーバ、４……物理サーバ、６……ストレージ装置、１０，２０……ＣＰＵ、１１，２１……メモリ、１３，６５……制御プログラム群、１４，６６……管理テーブル群、２５……プログラム、３０……仮想化機構、３１……仮想サーバ、３６……仮想化機構管理用インタフェース、３７……ボリューム、４０……サーバ走査プログラム、４１……サーバ登録プログラム、４２，６８……サーバ構成取得プログラム、４３……仮想化機構構成生成プログラム、４４……管理手段判定プログラム、４５……配信実行プログラム、４６……サーバ管理テーブル、４７……サーバ論理情報管理テーブル、４８，６７……サーバモデル情報管理テーブル、４９……仮想化機構管理テーブル、５０……データセンタ運用ポリシー管理テーブル、５１……プログラム管理テーブル、６２……シャーシ。

Claims (8)

1. 少なくとも１つのサーバとネットワークを介して接続され、前記サーバに対して必要に応じてプログラムを配信するプログラム配信装置において、
   前記サーバの状態変更を検知し、複数のサーバからなるシステムの運用ポリシーを参照し、配信するプログラムのルールに対応したサーバ走査方法を入手し、入手した前記サーバ走査方法に従って自プログラム配信装置に接続された各前記サーバの走査を実行するサーバ走査処理部と、
   前記走査で特定した新規のサーバに対して前記プログラムを配信可能か否かを判定する判定処理部と、
   新規のサーバに対して前記プログラムを配信可能なときに、当該新規のサーバに応じたプログラムを配信する配信実行処理部と
   を備えることを特徴とするプログラム配信装置。
2. 前記新規のサーバに配信されるプログラムは、
   ＯＳ（Operating System）若しくはハードウェアと密な連携が可能なプログラム、又は、ＯＳ（Operating System）若しくはハードウェアと疎な連携が可能なプログラムである
   ことを特徴とする請求項１に記載のプログラム配信装置。
3. 前記密な連携が可能なプログラムは、
   ハードウェア特有の機能を使う、又は、詳細な情報取得をするプログラムである
   ことを特徴とする請求項２に記載のプログラム配信装置。
4. 前記新規のサーバに対して、
   最初はＯＳ（Operating System）又はハードウェアと疎な連携が可能なプログラムを配信し、その後にＯＳ（Operating System）又はハードウェアと密な連携が可能なプログラムを再配信する
   ことを特徴とする請求項１に記載のプログラム配信装置。
5. 少なくとも１つのサーバとネットワークを介して接続され、前記サーバに対して必要に応じてプログラムを配信するプログラム配信方法において、
   前記サーバの状態変更を検知し、複数のサーバからなるシステムの運用ポリシーを参照し、配信するプログラムのルールに対応したサーバ走査方法を入手し、入手した前記サーバ走査方法に従って自プログラム配信装置に接続された各前記サーバの走査を実行する第１のステップと、
   前記走査で特定した新規のサーバに対して前記プログラムを配信可能か否かを判定する第２のステップと、
   新規のサーバに対して前記プログラムを配信可能なときに、当該新規のサーバに応じたプログラムを配信する第３のステップと
   を備えることを特徴とするプログラム配信方法。
6. 前記新規のサーバに応じたプログラムは、
   ＯＳ（Operating System）若しくはハードウェアと密な連携が可能なプログラム、又は、ＯＳ（Operating System）若しくはハードウェアと疎な連携が可能なプログラムである
   ことを特徴とする請求項５に記載のプログラム配信方法。
7. 前記密な連携が可能なプログラムは、
   ハードウェア特有の機能を使う、又は、詳細な情報取得をするプログラムである
   ことを特徴とする請求項６に記載のプログラム配信方法。
8. 前記新規のサーバに対して、
   最初はＯＳ（Operating System）又はハードウェアと疎な連携が可能なプログラムを配信し、その後にＯＳ（Operating System）又はハードウェアと密な連携が可能なプログラムを再配信する
   ことを特徴とする請求項５に記載のプログラム配信方法。

Images