(57)【要約】【課題】スイッチ間の通信量を低減すること。【解決手段】記憶部１ａは、スイッチとスイッチに接続されたノードの集合であるクラスタとの対応を示すクラスタ構成情報、および、ノード毎に保持するイメージの情報およびイメージを配信可能であるか否かの情報をノードの識別情報に関連付けた配信状況テーブルを記憶する。演算部１ｂは、イメージＤ１の配備指示と配備数とを受信すると、記憶部１ａに記憶された情報を参照して、イメージＤ１を保持するノードと配備先の候補ノードとの間のスイッチの経由数に応じた距離と候補ノードの負荷とに基づいて配備先ノードを決定する。演算部１ｂは、イメージＤ１を保持するノードを含まないクラスタに属する配備先ノードへのイメージＤ１の送信後に、同一クラスタに属する配備先ノード間でのイメージ送信を実行するように各ノードへのイメージ送信指示を制御する。【選択図】図１
2018005456.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
スイッチと前記スイッチに接続されたノードの集合であるクラスタとの対応を示すクラスタ構成情報を記憶し、ノード毎に保持するイメージの情報および当該イメージを配信可能であるか否かの情報をノードの識別情報に関連付けて配信状況テーブルとして記憶し、
第１イメージの配備指示と配備数とを受信すると、前記クラスタ構成情報および前記配信状況テーブルから、前記第１イメージを保持するノードと配備先の候補ノードとの間のスイッチの経由数に応じた距離を候補ノード毎に求め、前記候補ノードに対する距離と前記候補ノードの負荷とに基づいて配備先ノードを決定し、
前記第１イメージを保持するノードを含まないクラスタに属する配備先ノードへの前記第１イメージの送信後に、同一クラスタに属する配備先ノード間でのイメージ送信を実行するように各ノードへのイメージ送信指示を制御する、
処理を実行させるイメージ配信プログラム。
【請求項２】
前記距離を求める際、前記第１イメージを保持するノードと前記候補ノードとが同じクラスタに属するか否かに応じて前記距離を求める、請求項１記載のイメージ配信プログラム。
【請求項３】
前記距離を求める際、前記第１イメージを保持する複数のノードそれぞれと配備先の候補ノードとの間のスイッチの経由数のうちの最小値を、前記候補ノードに対する前記距離とする、請求項１または２記載のイメージ配信プログラム。
【請求項４】
前記第１イメージを保持するノードを含まないクラスタに属する配備先ノードへの前記第１イメージの送信では、当該クラスタに属する複数の配備先ノードのうちの１つに、前記第１イメージを送信するように前記イメージ送信指示を制御する、請求項１乃至３の何れか１項に記載のイメージ配信プログラム。
【請求項５】
前記制御では、前記ノードと前記スイッチとの間で行われている通信に対応するテナントの数に基づいて、配信先ノードと前記第１イメージの配信元ノードとの組み合わせを決定する、請求項１乃至４の何れか１項に記載のイメージ配信プログラム。
【請求項６】
複数のノードの何れかのノードから当該ノードが備える記憶装置の容量不足の通知を受信すると、前記記憶装置に記憶された複数のイメージそれぞれを保持する他のノードと前記通知の送信元のノードとの間のスイッチの経由数に応じた距離に基づいて、削除対象のイメージを前記通知の送信元のノードに指示する、請求項１乃至５の何れか１項に記載のイメージ配信プログラム。
【請求項７】
スイッチと前記スイッチに接続されたノードの集合であるクラスタとの対応を示すクラスタ構成情報、および、ノード毎に保持するイメージの情報とイメージを配信可能であるか否かの情報とをノードの識別情報に関連付けた配信状況テーブルを記憶する記憶部と、
第１イメージの配備指示と配備数とを受信すると、前記クラスタ構成情報および前記配信状況テーブルから、前記第１イメージを保持するノードと配備先の候補ノードとの間のスイッチの経由数に応じた距離を候補ノード毎に求め、前記候補ノードに対する距離と前記候補ノードの負荷とに基づいて配備先ノードを決定し、
前記第１イメージを保持するノードを含まないクラスタに属する配備先ノードへの前記第１イメージの送信後に、同一クラスタに属する配備先ノード間でのイメージ送信を実行するように各ノードへのイメージ送信指示を制御する、演算部と、
を有するイメージ配信装置。
【請求項８】
コンピュータが、
スイッチと前記スイッチに接続されたノードの集合であるクラスタとの対応を示すクラスタ構成情報を記憶し、ノード毎に保持するイメージの情報および当該イメージを配信可能であるか否かの情報をノードの識別情報に関連付けて配信状況テーブルとして記憶し、
第１イメージの配備指示と配備数とを受信すると、前記クラスタ構成情報および前記配信状況テーブルから、前記第１イメージを保持するノードと配備先の候補ノードとの間のスイッチの経由数に応じた距離を候補ノード毎に求め、前記候補ノードに対する距離と前記候補ノードの負荷とに基づいて配備先ノードを決定し、
前記第１イメージを保持するノードを含まないクラスタに属する配備先ノードへの前記第１イメージの送信後に、同一クラスタに属する配備先ノード間でのイメージ送信を実行するように各ノードへのイメージ送信指示を制御する、
イメージ配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はイメージ配信プログラム、イメージ配信装置およびイメージ配信方法に関する。
【背景技術】
【０００２】
現在、複数の情報処理装置を含む情報処理システムが利用されている。複数の情報処理装置はネットワークに接続され、互いに通信する。情報処理システムでは、情報処理装置は、ネットワークを介して、他の情報処理装置へデータを配信することがある。そこで、データの配信方法が考えられている。
【０００３】
例えば、データベース管理機構が、ある端末からの要求を受信し、要求に応じた情報を別端末に送信するノードを選定する際、情報の送り先の端末に最も近いデータベースを選定する提案がある。この提案では、ネットワークの経路上、最も近い、あるいはデータベースと送り先の端末との設置位置の物理的な距離が最も近いデータベースを選定する。
【０００４】
また、サーバ装置が、以前に配布したプログラムと配布先の端末ＩＤ（IDentifier）との関連を示すテーブルを保持し、当該テーブルを参照して、端末ＩＤを伴うプログラム取得要求に対してプログラムを配布するか否かを判定する提案もある。
【０００５】
なお、あるノードが、処理されるべき要求を取得すると、複数のノードのうちのどのノードが要求を処理するために利用可能であるかを判断し、利用可能と判断されたノードに要求を送信して、要求を処理する仮想マシンを当該ノード上で起動する提案がある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平８−２７４８０６号公報
【特許文献２】特開２００４−５５８５号公報
【特許文献３】特表２００７−５０６１６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
複数のノードを含むシステムにおいて、あるノード上に仮想マシンを新たに配備することがある。この場合、配備先のノードは、該当の仮想マシンのイメージデータ（単にイメージと称する）を取得する。例えば、管理ノードがイメージを管理し、仮想マシン配備時に配備先のノードにイメージを送信する。この場合、複数の仮想マシンの配備が重なると、管理ノードによるイメージ送信完了まで時間がかかり、仮想マシンの配備が遅延する。
【０００８】
そこで、イメージを受信したノードにも、一定期間イメージを保持（キャッシュ）しておき、管理ノードと共に配備先のノードへのイメージ送信に利用することが考えられる。
しかし、複数のノードは複数のスイッチを介して接続される。特定のスイッチを経由して複数の配備先のノードにイメージを配信すると、特定のスイッチの負荷が増大し、通信速度が低下する。このため、仮想マシンの配備時間を十分に短縮できないおそれがある。
【０００９】
１つの側面では、本発明は、スイッチ間の通信量を低減することを目的とする。
【課題を解決するための手段】
【００１０】
１つの態様では、イメージ配信プログラムが提供される。このイメージ配信プログラムは、コンピュータに、スイッチとスイッチに接続されたノードの集合であるクラスタとの対応を示すクラスタ構成情報を記憶し、ノード毎に保持するイメージの情報およびイメージを配信可能であるか否かの情報をノードの識別情報に関連付けて配信状況テーブルとして記憶し、第１イメージの配備指示と配備数とを受信すると、クラスタ構成情報および配信状況テーブルから、第１イメージを保持するノードと配備先の候補ノードとの間のスイッチの経由数に応じた距離を候補ノード毎に求め、候補ノードに対する距離と候補ノードの負荷とに基づいて配備先ノードを決定し、第１イメージを保持するノードを含まないクラスタに属する配備先ノードへの第１イメージの送信後に、同一クラスタに属する配備先ノード間でのイメージ送信を実行するように各ノードへのイメージ送信指示を制御する、処理を実行させる。
【発明の効果】
【００１１】
１つの側面では、スイッチ間の通信量を低減できる。
【図面の簡単な説明】
【００１２】
【図１】第１の実施の形態のイメージ配信装置を示す図である。
【図２】第２の実施の形態の情報処理システムの例を示す図である。
【図３】第２の実施の形態のコントローラノードのハードウェア例を示す図である。
【図４】第２の実施の形態のソフトウェア例を示す図である。
【図５】第２の実施の形態のイメージ配置例を示す図である。
【図６】第２の実施の形態の機能例を示す図である。
【図７】第２の実施の形態のノードの状態遷移例を示す図である。
【図８】第２の実施の形態のクラスタの状態遷移例を示す図である。
【図９】第２の実施の形態のクラスタ構成テーブルの例を示す図である。
【図１０】第２の実施の形態のノード配信状況テーブルの例を示す図である。
【図１１】第２の実施の形態のクラスタ配信状況テーブルの例を示す図である。
【図１２】第２の実施の形態の距離情報の例を示す図である。
【図１３】第２の実施の形態の重みテーブルの例を示す図である。
【図１４】第２の実施の形態のデプロイ例を示すシーケンス図である。
【図１５】第２の実施の形態の他の処理例を示すシーケンス図である。
【図１６】第２の実施の形態のデプロイ例を示すフローチャートである。
【図１７】第２の実施の形態の距離計算例を示すフローチャートである。
【図１８】第２の実施の形態のスコア計算例（その１）を示す図である。
【図１９】第２の実施の形態の最終的なスコア計算結果の例を示す図である。
【図２０】第２の実施の形態のスコア計算例（その２）を示す図である。
【図２１】第２の実施の形態の配信状況の例（配信開始時）を示す図である。
【図２２】第２の実施の形態の配信指示例を示すフローチャートである。
【図２３】第２の実施の形態の配信状況の更新例を示す図である。
【図２４】第２の実施の形態の配信状況の更新例（続き）を示す図である。
【図２５】第２の実施の形態のノード配信状況の更新例を示す図である。
【図２６】第２の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図２７】第２の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図２８】第２の実施の形態のノード追加例を示すフローチャートである。
【図２９】第２の実施の形態のノード追加の具体例を示す図である。
【図３０】第２の実施の形態のノード追加後のクラスタ構成例を示す図である。
【図３１】第２の実施の形態のノード追加後のノード配信状況例を示す図である。
【図３２】第２の実施の形態のノード追加後のクラスタ配信状況例を示す図である。
【図３３】第２の実施の形態のキャッシュ管理例を示すフローチャートである。
【図３４】第２の実施の形態のイメージ削除後のテーブルの例を示す図である。
【図３５】第２の実施の形態の分散配信例を示すフローチャートである。
【図３６】第２の実施の形態のイメージ追加例を示す図である。
【図３７】第２の実施の形態のイメージ追加例（続き）を示す図である。
【図３８】第３の実施の形態の情報処理システムの例を示す図である。
【図３９】第３の実施の形態のサブネット分割の例を示す図である。
【図４０】第３の実施の形態のスイッチ／ノードの識別情報の例を示す図である。
【図４１】第３の実施の形態のノード配信状況テーブルの例を示す図である。
【図４２】第３の実施の形態の距離計算例を示すフローチャートである。
【図４３】第３の実施の形態の距離情報の例を示す図である。
【図４４】第３の実施の形態のスコア計算の具体例を示す図である。
【図４５】第３の実施の形態のノード配信状況の例（配信開始時）を示す図である。
【図４６】第３の実施の形態の配信管理例を示すフローチャートである。
【図４７】第３の実施の形態の配信指示例を示すフローチャートである。
【図４８】第３の実施の形態のキューの例（その１）を示す図である。
【図４９】第３の実施の形態のノード配信状況の更新例を示す図である。
【図５０】第３の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図５１】第３の実施の形態のキューの例（その２）を示す図である。
【図５２】第３の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図５３】第３の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図５４】第３の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図５５】第３の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図５６】第３の実施の形態のノード追加の具体例を示す図である。
【図５７】第３の実施の形態のノード追加後のノード配信状況例を示す図である。
【図５８】第３の実施の形態のキャッシュ管理例を示すフローチャートである。
【図５９】第３の実施の形態のイメージ削除後のノード配信状況例を示す図である。
【図６０】第４の実施の形態の通信テーブルの例を示す図である。
【図６１】第４の実施の形態のノード配信状況テーブルの例を示す図である。
【図６２】第４の実施の形態の配信指示例を示すフローチャートである。
【図６３】第４の実施の形態の配信指示の追加部分を示すフローチャートである。
【図６４】第４の実施の形態のスコア計算の具体例（その１）を示す図である。
【図６５】第４の実施の形態のノード配信状況の更新例を示す図である。
【図６６】第４の実施の形態のキューの例（その１）を示す図である。
【図６７】第４の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図６８】第４の実施の形態の通信テーブルの更新例（その１）を示す図である。
【図６９】第４の実施の形態のスコア計算の具体例（その２）を示す図である。
【図７０】第４の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図７１】第４の実施の形態のキューの例（その２）を示す図である。
【図７２】第４の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図７３】第４の実施の形態の通信テーブルの更新例（その２）を示す図である。
【図７４】第４の実施の形態のノード配信状況の更新例（続き）を示す図である。
【図７５】第４の実施の形態の通信テーブルの更新例（その３）を示す図である。
【図７６】第４の実施の形態のノード追加後の通信テーブルの例を示す図である。
【図７７】デプロイの比較例を示すシーケンス図である。
【図７８】イメージの同時多重送信の例を示す図である。
【図７９】スイッチにおける非効率な通信の例を示す図である。
【図８０】イメージの分散配信の例を示す図である。
【図８１】スイッチの特性の例を示す図である。
【図８２】配備先の決定に用いるスコアの比較例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態のイメージ配信装置を示す図である。イメージ配信装置１は、スイッチを介して複数のノードと通信する。複数のノードそれぞれは、仮想マシンを実行することができる。例えば、ノードは、ノードが備えるＣＰＵ（Central Processing Unit）やＲＡＭ（Random Access Memory）の記憶領域を、演算のリソースとして複数の仮想マシンに割り当て、当該ノード上で仮想マシンを動作させる。仮想マシンで実行されるＯＳ（Operating System）やアプリケーションなどのソフトウェアのプログラムは、当該プログラムを格納した補助記憶装置のイメージデータ（単にイメージと称する）として提供される。ノードは、イメージを基に仮想マシンや仮想マシン上のソフトウェアを実行できる。
【００１４】
ここで、イメージ配信装置１は、スイッチＳＷ１，ＳＷ１１，ＳＷ１２，ＳＷ１３を介してノード２，２ａ，２ｂ，２ｃ，２ｄ，２ｅ，２ｆ，２ｇ，２ｈと接続されている。スイッチＳＷ１，ＳＷ１１，ＳＷ１２，ＳＷ１３は、ノード間の通信を中継する中継装置である。スイッチＳＷ１，ＳＷ１１，ＳＷ１２，ＳＷ１３は、ＯＳＩ（Open Systems Interconnection）参照モデルの第２層（データリンク層）のプロトコル（例えば、イーサネット（登録商標））を用いてデータ転送を行うレイヤ２（Ｌ２：Layer 2）スイッチでもよい。
【００１５】
スイッチＳＷ１は、スイッチＳＷ１１，ＳＷ１２，ＳＷ１３と接続されており、スイッチ間の通信を中継する。スイッチＳＷ１１は、イメージ配信装置１およびノード２，２ａ，２ｂと接続されている。スイッチＳＷ１２は、ノード２ｃ，２ｄ，２ｅと接続されている。スイッチＳＷ１３は、ノード２ｆ，２ｇ，２ｈと接続されている。
【００１６】
第１の実施の形態では、例えば、用途に応じた種々のスペックやソフトウェアを持つ仮想マシンのイメージが予め用意される。イメージ配信装置１が、各仮想マシンのイメージを一元管理してもよい。また、イメージは、該当のイメージの配信を受けた各ノードにより保持（キャッシュ）される。例えば、イメージは、各ノードが備える補助記憶装置に記憶される。
【００１７】
ユーザは、所望の処理の実行に用いる仮想マシンを選択し、当該仮想マシンの配備と、配備する数とをイメージ配信装置１に入力する。イメージ配信装置１は、ユーザにより指定された仮想マシンについて、各ノードの負荷や各ノードによるイメージの保持状況に応じて、配備数分の配備先ノードを決定し、配備先ノードへイメージを配信する機能を提供する。
【００１８】
イメージ配信装置１は、記憶部１ａおよび演算部１ｂを有する。記憶部１ａは、ＲＡＭなどの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。演算部１ｂは、ＣＰＵ、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。演算部１ｂはプログラムを実行するプロセッサでもよい。プロセッサは、複数のプロセッサの集合（マルチプロセッサ）も含み得る。また、イメージ配信装置１は、メモリとプロセッサとを有するコンピュータでもよい。
【００１９】
記憶部１ａは、スイッチとスイッチに接続されたノードの集合であるクラスタとの対応を示すクラスタ構成情報を記憶する。上記の例では、イメージ配信装置１および各ノードは、クラスタ３，３ａ，３ｂに分けられる。クラスタ３は、スイッチＳＷ１１に接続されたノードの集合である。ノード２，２ａ，２ｂは、クラスタ３に属する。イメージ配信装置１もクラスタ３に属する（図１では図示を省略している）。クラスタ３ａは、スイッチＳＷ１２に接続されたノードの集合である。ノード２ｃ，２ｄ，２ｅは、クラスタ３ａに属する。クラスタ３ｂは、スイッチＳＷ１３に接続されたノードの集合である。ノード２ｆ，２ｇ，２ｈは、クラスタ３ｂに属する。記憶部１ａは、このようなクラスタ３，３ａ，３ｂの情報を含むクラスタ構成情報を予め記憶する。
【００２０】
記憶部１ａは、ノード毎に保持するイメージの情報および当該イメージを配信可能であるか否かの情報をノードの識別情報に関連付けた配信状況テーブルを記憶する。例えば、ノード２は、ある仮想マシンのイメージＤ１を保持する。ノード２ａ，２ｂ，２ｃ，２ｄ，２ｅ，２ｆ，２ｇ，２ｈは、イメージＤ１を保持していない。また、ノード２は、イメージＤ１を配信可能である。このため、配信状況テーブルは、イメージＤ１がノード２により保持されており、ノード２がイメージＤ１を配信可能であるという情報を含む。配信状況テーブルは、他のイメージに関する同様の情報も含んでいる。更に、記憶部１ａは、各スイッチの接続関係を示す情報を記憶する。また、記憶部１ａもイメージＤ１を記憶する。
【００２１】
演算部１ｂは、各ノードに対するイメージの配信に応じて、ノード毎に保持するイメージの情報および当該イメージを配信可能であるか否かの情報を関連付けて配信状況テーブルに記録する。
【００２２】
演算部１ｂは、第１イメージの配備指示と配備数とを受信する。イメージの配備指示および配備数は、ユーザの入力デバイスを用いた操作入力によりイメージ配信装置１に直接入力されてもよいし、ネットワークを介して接続された他の端末装置からイメージ配信装置１に対して入力されてもよい。
【００２３】
演算部１ｂは、配備指示に応じて、記憶部１ａに記憶されたクラスタ構成情報および配信状況テーブルから、第１イメージを保持するノードと配備先の候補ノードとの間のスイッチの経由数に応じた距離を候補ノード毎に求める。ここで、演算部１ｂが求める「距離」は、「距離の指標」ということもできる。配備先の候補ノードは、ノード２，２ａ，２ｂ，２ｃ，２ｄ，２ｅ，２ｆ，２ｇ，２ｈの全てのノードでもよいし、そのうちの一部のノードでもよい。
【００２４】
ここで、イメージＤ１が配備指示の対象の第１イメージに相当する場合を考える。この場合、第１イメージを保持するノードはノード２（あるいは、イメージ配信装置１）である。このため、演算部１ｂは、ノード２と候補ノードとの間のスイッチの経由数に応じた距離を候補ノード毎に求める。距離の求め方には種々の方法が考えられる。
【００２５】
例えば、演算部１ｂは、クラスタ構成情報のみから距離を求めてもよい。具体的には、候補ノードがイメージＤ１を保持している場合（スイッチの経由数“０”の場合）、距離を０とする。候補ノードがイメージＤ１を保持しておらず、かつ、候補ノードと同じクラスタに属する他のノードがイメージＤ１を保持している場合（スイッチの経由数“１”の場合）、距離を１とする。候補ノードおよび候補ノードと同じクラスタに属する他のノードがイメージＤ１を保持しておらず、かつ、候補ノードと異なるクラスタに属する他のノードがイメージＤ１を保持している場合（スイッチの経由数“２”以上の場合）、距離を２とする。より具体的には、候補ノードがノード２の場合、ノード２からの距離は“０”である。候補ノードがノード２ａ，２ｂの場合、ノード２からの距離は“１”である。候補ノードがノード２ｃ，２ｄ，２ｅ，２ｆ，２ｇ，２ｈの場合、ノード２からの距離は“２”である。
【００２６】
あるいは、演算部１ｂは、スイッチの接続関係を示す情報から距離を求めてもよい。具体的には、候補ノードとイメージＤ１を保持しているノード２との間に介在するスイッチに対するホップ数を距離とする。より具体的には、候補ノードがノード２の場合、ノード２からの距離は“０”である。候補ノードがノード２ａ，２ｂの場合、ノード２からの距離は“２”である。候補ノードがノード２ｃ，２ｄ，２ｅ，２ｆ，２ｇ，２ｈの場合、距離は“４”である。なお、第１イメージを持つノードが複数存在する場合、第１イメージを持つ複数のノードそれぞれと候補ノードとの間のスイッチの経由数の最小値を、当該候補ノードに対する距離（候補ノードの第１イメージからの距離）とする。また、演算部１ｂは、候補ノードとイメージＤ１を保持しているノード２との間に介在するスイッチの数を、候補ノードのノード２からの距離とすることも考えられる。
【００２７】
演算部１ｂは、候補ノードに対する距離と候補ノードの負荷とに基づいて、配備先ノードを決定する。例えば、演算部１ｂは、候補ノードが備える記憶装置やプロセッサの使用量を候補ノードの負荷として収集する。より具体的には、演算部１ｂは、各ノードが備えるＲＡＭやＨＤＤなどの記憶装置の空き容量および入出力による利用率を、当該記憶装置の使用量として各ノードから収集する。また、演算部１ｂは、各ノードが備えるＣＰＵなどのプロセッサの使用率を、当該プロセッサの使用量として各ノードから収集する。
【００２８】
そして、演算部１ｂは、候補ノードに対して計算した距離と、当該候補ノードに対して収集した負荷の情報とに基づいて、候補ノードのスコアを評価する。具体的には、演算部１ｂは、記憶装置の使用量やプロセッサの使用量が少ないほど良いスコアとし、また、候補ノードに対する距離が小さいほど良いスコアとする。そして、演算部１ｂは、スコアの良い順に、配備先ノードを選択していく。
【００２９】
一例として、ユーザにより指定された配備数が６の場合を考える。この場合、演算部１ｂは、候補ノードであるノード２ａ，２ｂ，２ｃ，２ｄ，２ｅ，２ｆ，２ｇ，２ｈの中から６つの配備先ノードを選択する。上記のスコア評価の結果、演算部１ｂは、配備先ノードをノード２ａ，２ｃ，２ｅ，２ｆ，２ｇ，２ｈに決定したとする。
【００３０】
演算部１ｂは、第１イメージを保持するノードを含まないクラスタに属する配備先ノードへの第１イメージの送信後に、同一クラスタに属する配備先ノード間でのイメージ送信を実行するように各ノードへのイメージ送信指示を制御する。
【００３１】
上記の例の場合、イメージＤ１を保持するノード（具体的には、ノード２およびイメージ配信装置１）が属するクラスタは、クラスタ３である。また、イメージＤ１を保持するノードを含まないクラスタは、クラスタ３ａ，３ｂである。このため、まず、演算部１ｂは、クラスタ３ａに属する１つの配備先ノードであるノード２ｃに対し、ノード２からのイメージＤ１の取得を指示する（送信指示と称してもよい）。また、演算部１ｂは、クラスタ３ｂに属する１つの配備先ノードであるノード２ｆに対し、ノード２からのイメージＤ１の取得を指示する。ノード２ｃ，２ｆは、指示に応じて、ノード２にイメージＤ１の送信を要求する。当該要求に応じて、ノード２は、ノード２ｃ，２ｆへイメージＤ１を送信する（ステップＳ１）。こうして、イメージ配信装置１の制御により、配備先ノードであるノード２ｃ，２ｆにイメージＤ１が配信される。その結果、クラスタ３ａに属するノードのうち、少なくとも１つのノード２ｃは、イメージＤ１を保持した状態になる。また、クラスタ３ｂに属するノードのうち、少なくとも１つのノード２ｆは、イメージＤ１を保持した状態になる。
【００３２】
なお、イメージＤ１の配信元をノード２としたが、ノード２に加えて、あるいは、ノード２に代えてイメージ配信装置１をイメージＤ１の配信元としてもよい。例えば、ノード２ｃへのイメージＤ１の配信をイメージ配信装置１が担当し、ノード２ｆへのイメージＤ１の配信をノード２が担当して、配信処理を分散実行してもよい。配信処理を分散実行することで、配信元の各ノードのイメージ配信に伴う負荷を軽減できる。
【００３３】
ここで、配備先ノードであるノード２，２ａは、同一のクラスタ３に属する。配備先ノードであるノード２ｃ，２ｅは、同一のクラスタ３ａに属する。配備先ノードである２ｆ，２ｇ，２ｈは、同一のクラスタ３ｂに属する。
【００３４】
このため、演算部１ｂは、ノード２ａに対し、ノード２からイメージＤ１を取得するよう指示する。また、演算部１ｂは、ノード２ｅに対し、ノード２ｃからイメージＤ１を取得するよう指示する。更に、演算部１ｂは、ノード２ｇ，２ｈに対し、ノード２ｆからイメージＤ１を取得するよう指示する。
【００３５】
ノード２ａは、指示に応じて、ノード２に対してイメージＤ１の送信を要求する。当該要求に応じて、ノード２は、ノード２ａへイメージＤ１を送信する（ステップＳ２）。ノード２ｅは、ノード２ｃに対してイメージＤ１の送信を要求する。当該要求に応じて、ノード２ｃは、ノード２ｅへイメージＤ１を送信する（ステップＳ２）。ノード２ｇ，２ｈは、ノード２ｆに対してイメージＤ１の送信を要求する。当該要求に応じて、ノード２ｆは、ノード２ｇ，２ｈへイメージＤ１を送信する（ステップＳ２）。これらステップＳ２の各処理は、並行して実行されてもよい。
【００３６】
こうして、イメージ配信装置１の制御により、配信先ノードである２ａ，２ｅ，２ｇ，２ｈにイメージＤ１が配信される。ノード２ａ，２ｅ，２ｇ，２ｈは、イメージＤ１を保持した状態になる。なお、イメージＤ１の配備先のノードに対してイメージの取得を指示するものとしたが、演算部１ｂは、イメージＤ１の送信元のノードに対して配備先のノードへのイメージＤ１の送信を指示してもよい。
【００３７】
その後、ノード２ａ，２ｃ，２ｅ，２ｆ，２ｇ，２ｈは、イメージＤ１を用いて、仮想マシンを起動する。これにより、新たな仮想マシンが各ノードに配備され、ユーザは、当該仮想マシンの利用を開始することができる。
【００３８】
ところで、上記のように、イメージ配信装置１によりイメージを保持する他、イメージ配信装置１以外のノードにもイメージをキャッシュして、イメージの分散配信を行うことが考えられる。しかし、各ノードは、上記のように複数のスイッチを介して接続される。このため、特定のスイッチを経由して複数の配備先のノードにイメージを配信すると、特定のスイッチの負荷が高まって通信速度が低下することがある。
【００３９】
例えば、イメージ配信装置１やノード２を配信元とし、配信先ノードであるノード２ｃ，２ｅ，２ｆ，２ｇ，２ｈそれぞれに対して、イメージＤ１を配信することも考えられる。ところが、この場合、配信の通信経路に存在する各スイッチは、イメージＤ１を多重に転送することになる。特に、上記の接続でイメージＤ１を多重に転送すると、スイッチＳＷ１，ＳＷ１１スイッチの負荷はスイッチＳＷ１２，ＳＷ１３に比べて高まる可能性が高い。スイッチＳＷ１，ＳＷ１１はノード２ｃ，２ｅ，２ｆ，２ｇ，２ｈそれぞれに対するイメージＤ１のスイッチ間転送を５重に実行することになる。スイッチＳＷ１２は、ノード２ｃ，２ｅに対するスイッチ間転送を２重に実行することになる。スイッチＳＷ１３は、ノード２ｆ，２ｇ，２ｈそれぞれに対するスイッチ間転送を３重に実行することになる。イメージのサイズは比較的大きいこともあり、このようにスイッチ間転送が多重に同時発生すると各スイッチの負荷が高まり易い。この場合、特にスイッチＳＷ１，ＳＷ１１による通信速度が大幅に低下し、仮想マシンの配備時間を十分に短縮できないおそれがある。
【００４０】
そこで、イメージ配信装置１は、まずはクラスタ間でイメージを配信するように各ノードを制御する（いわば横展開）。その後、イメージ配信装置１は、同一クラスタ内でイメージを配信するように各ノードを制御する（いわば縦展開）。
【００４１】
これにより、スイッチ間の通信量を低減できる。例えば、上記の例では、スイッチＳＷ１，ＳＷ１１によるイメージＤ１のスイッチ間転送を２重に抑えられる。スイッチＳＷ１２によるイメージＤ１のスイッチ間転送を１重に抑えられる。スイッチＳＷ１３によるイメージＤ１のスイッチ間転送を１重に抑えられる。このため、スイッチＳＷ１，ＳＷ１１，ＳＷ１２，ＳＷ１３の負荷が軽減され、各スイッチによる通信速度の低下を抑えることができる。その結果、仮想マシンの配備時間を短縮できる。特に、各クラスタへのイメージ配信後、同一クラスタ内で並行してイメージ配信を行えるため、仮想マシンの配備時間を一層高速化できる。
【００４２】
以下では、仮想マシンを動的に配備するクラウドコンピューティングシステムにイメージ配信装置１を適用する例を示して、イメージ配信の制御機能をより具体的に説明する。
［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムの例を示す図である。第２の実施の形態の情報処理システムは、フロアスイッチ１０、ラックスイッチ２０，２０ａ、コントローラノード１００およびコンピュートノード２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ，２００ｆ，３００，３００ａ，３００ｂ，３００ｃを含む。
【００４３】
フロアスイッチ１０およびラックスイッチ２０，２０ａは、Ｌ２スイッチである。フロアスイッチ１０は、データセンタ内のフロア単位の集約スイッチである。ラックスイッチ２０，２０ａは、フロアに配置されたラック単位の集約スイッチである。ラックスイッチ２０，２０ａは、所定のケーブルを用いてフロアスイッチ１０に接続されている。フロアスイッチ１０およびラックスイッチ２０，２０ａはＬ２ネットワークを形成している。
【００４４】
コントローラノード１００およびコンピュートノード２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ，２００ｆは、所定のケーブルを用いてラックスイッチ２０に接続されている。コンピュートノード３００，３００ａ，３００ｂ，３００ｃは、所定のケーブルを用いてラックスイッチ２０ａに接続されている。ここで、以下では、コンピュートノード２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ，２００ｆ，３００，３００ａ，３００ｂ，３００ｃそれぞれを指して、各コンピュートノードと称することがある。コントローラノード１００およびコンピュートノード２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ，２００ｆ，３００，３００ａ，３００ｂ，３００ｃそれぞれを指して、各ノードと称することがある。
【００４５】
コントローラノード１００は、仮想マシンの配備指示に応じて、各コンピュートノードに対する仮想マシンのイメージ配信を制御するサーバコンピュータである。
各コンピュートノードは、コントローラノード１００の指示に応じて、配備対象の仮想マシンのイメージを取得し、取得したイメージを用いて仮想マシンを動作させるサーバコンピュータである。
【００４６】
ここで、第２の実施の形態の情報処理システムは、各コンピュートノードに仮想マシンを動的に配備して、ユーザの業務処理を行えるクラウドコンピューティングシステムである。コンピュートノードはシステムの拡大に応じて追加されることがある。また、各コンピュートノード上に配備する仮想マシンを「インスタンス」と称することがある。
【００４７】
図３は、第２の実施の形態のコントローラノードのハードウェア例を示す図である。コントローラノード１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、画像信号処理部１０４、入力信号処理部１０５、媒体リーダ１０６および通信インタフェース１０７を有する。各ユニットはコントローラノード１００のバスに接続されている。各コンピュートノードもコントローラノード１００と同様のユニットを用いて実現できる。
【００４８】
プロセッサ１０１は、コントローラノード１００の情報処理を制御する。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組み合わせであってもよい。
【００４９】
ＲＡＭ１０２は、コントローラノード１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。
【００５０】
ＨＤＤ１０３は、コントローラノード１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３は、ＯＳのプログラム、アプリケーションプログラム、および各種データを記憶する。コントローラノード１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。
【００５１】
画像信号処理部１０４は、プロセッサ１０１からの命令に従って、コントローラノード１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。
【００５２】
入力信号処理部１０５は、コントローラノード１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。
【００５３】
媒体リーダ１０６は、記録媒体１３に記録されたプログラムやデータを読み取る装置である。記録媒体１３として、例えば、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤなどの磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）を使用できる。また、記録媒体１３として、例えば、フラッシュメモリカードなどの不揮発性の半導体メモリを使用することもできる。媒体リーダ１０６は、例えば、プロセッサ１０１からの命令に従って、記録媒体１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００５４】
通信インタフェース１０７は、ラックスイッチ２０に接続されている。通信インタフェース１０７は、ラックスイッチ２０を介して他の装置と通信を行う。通信インタフェース１０７は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。
【００５５】
図４は、第２の実施の形態のソフトウェア例を示す図である。コントローラノード１００のＯＳ上では、コンピュートサービス（ＣＴＲ（Controllerの略）と表記する）、イメージ配信サーバ、配信管理デーモンおよび他のアプリケーションのプロセス（他プロセス）が実行される。
【００５６】
ＣＴＲは、インスタンスの管理を行う。ＣＴＲは、各コンピュートノードの状態（メモリ使用率、ディスク入出力負荷およびプロセッサ使用率など）やイメージとコンピュートノードとの距離の指標を基に、何れのコンピュートノードでインスタンスを起動するかを判断する。
【００５７】
イメージ配信サーバは、インスタンスの起動に用いられるイメージを管理し、コンピュートノードからの要求に応じて、イメージを配信する。
配信管理デーモンは、システム全体でのイメージ配信処理を管理／制御する。配信管理デーモンは、コンピュートノードからイメージの一括配信要求を受け付ける。配信管理デーモンは、各コンピュートノードがイメージをどこから取得すべきかを判断し、配信指示を送信する。配信管理デーモンは、各コンピュートノードが保有するイメージのキャッシュを管理する。また、配信管理デーモンは、ＣＴＲに対して、各コンピュートノードのイメージからの距離スコアを通知する。更に、配信管理デーモンは、後述する分散配信デーモンの追加／削除を管理する。
【００５８】
なお、配信管理デーモンは、ＣＴＲに含まれるプログラムのモジュールとして実装されてもよい。
他プロセスは、他のアプリケーションのプロセスであり、ＣＴＲ、イメージ配信サーバおよび配信管理デーモンに対し、直接的な関与はしない。
【００５９】
コンピュートノード２００のＯＳ上では、コンピュートサービス（ＣＭＰ（Computeの略）と表記する）、分散配信デーモンおよび仮想マシンの複数のインスタンスが実行される。
【００６０】
ＣＭＰは、コンピュートノード２００上でのインスタンスの管理（起動／終了など）を行う。
分散配信デーモンは、コンピュートノード２００が保持するイメージを管理する。分散配信デーモンは、コントローラノード１００から指定されたノードからのイメージのダウンロードを行う。分散配信デーモンは、ディスクの空き容量の確認と、コントローラノード１００への空き容量不足の通知を行う。また、分散配信デーモンは、コントローラノード１００から指定されたイメージを削除する。更に、分散配信デーモンは、他のコンピュートノードに対するイメージの提供を行う。
【００６１】
インスタンスは、コンピュートノード２００が保持するイメージから起動された仮想マシンである。
ここで、ネットワークＮ１は、フロアスイッチ１０およびラックスイッチ２０，２０ａにより形成されるＬ２ネットワークである。また、コントローラノード１００は、コントローラノード１００が備えるＨＤＤ１０３に加えて、ネットワークＮ１に接続されたストレージ１４に、配信管理デーモン用のＤＢ（DataBase）を格納することができる。
【００６２】
図５は、第２の実施の形態のイメージ配置例を示す図である。第２の実施の形態の例では、２種類のインスタンスに対するイメージＸ，Ｙの配信を想定する。初期段階において、イメージＸは、コントローラノード１００およびコンピュートノード２００により保持されている。また、初期段階において、イメージＹは、コントローラノード１００およびコンピュートノード３００により保持されている。
【００６３】
ここで、各ノードは、接続されるスイッチに応じてクラスタと呼ばれるグループに分けられる。ラックスイッチ２０には、コントローラノード１００およびコンピュートノード２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ，２００ｆが接続されている。このため、コントローラノード１００およびコンピュートノード２００，２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ，２００ｆは、ラックスイッチ２０に対応する１つのクラスタに属する。ラックスイッチ２０に対応するクラスタのクラスタ名を“クラスタＡ”とする。また、ラックスイッチ２０ａには、コンピュートノード３００，３００ａ，３００ｂ，３００ｃが接続されている。このため、コンピュートノード３００，３００ａ，３００ｂ，３００ｃは、ラックスイッチ２０ａに対応する１つのクラスタに属する。ラックスイッチ２０ａに対応するクラスタのクラスタ名を“クラスタＢ”とする。
【００６４】
また、各ノードのノード名（識別情報）を次の通りとする。コントローラノード１００のノード名は、“クラウドコントローラ”（単に“コントローラ”と表記することもある）である。コンピュートノード２００のノード名は、“ノードＡ１”である。コンピュートノード２００ａのノード名は、“ノードＡ２”である。コンピュートノード２００ｂのノード名は、“ノードＡ３”である。コンピュートノード２００ｃのノード名は、“ノードＡ４”である。コンピュートノード２００ｄのノード名は、“ノードＡ５”である。コンピュートノード２００ｅのノード名は、“ノードＡ６”である。コンピュートノード２００ｆのノード名は、“ノードＡ７”である。コンピュートノード３００のノード名は、“ノードＢ１”である。コンピュートノード３００ａのノード名は、“ノードＢ２”である。コンピュートノード３００ｂのノード名は、“ノードＢ３”である。コンピュートノード３００ｃのノード名は、“ノードＢ４”である。
【００６５】
図６は、第２の実施の形態の機能例を示す図である。図６では、図４で例示した各ソフトウェアを各ノードの機能部として表している。コントローラノード１００は、記憶部１１０、ＣＴＲ１２０、配信管理部１３０およびイメージ配信部１４０を有する。記憶部１１０は、ＲＡＭ１０２やＨＤＤ１０３の記憶領域を用いて実現される。ＣＴＲ１２０、配信管理部１３０およびイメージ配信部１４０は、ＲＡＭ１０２に記憶されたプログラムをプロセッサ１０１が実行することで実現される。
【００６６】
記憶部１１０は、図５で例示したクラスタ構成を示す情報や、ノードおよびクラスタ単位のイメージの配信状況を管理するための情報を記憶する。
ＣＴＲ１２０は、前述のコンピュートサービス（ＣＴＲ）に相当するモジュールである。ＣＴＲ１２０は、インスタンスの管理や各コンピュートノードの状態の管理を行う。また、ＣＴＲ１２０は、インスタンスの配備先とするコンピュートノードの決定を行う。
【００６７】
配信管理部１３０は、前述の配信管理デーモンに相当するモジュールである。前述のように、配信管理部１３０は、ＣＴＲ１２０に含まれてもよい。配信管理部１３０は、配備先として決定されたコンピュートノードによるイメージの取得元のノードを決定する。配信管理部１３０は、コンピュートノードに、イメージの取得元のノードを指示し、イメージの取得を実行させる。
【００６８】
イメージ配信部１４０は、前述のイメージ配信サーバに相当するモジュールである。イメージ配信部１４０は、インスタンスの起動に用いられるイメージを管理し、コンピュートノードからの要求に応じて、イメージを配信する。例えば、イメージ配信部１４０により管理されるイメージは、記憶部１１０に格納されてもよいし、外付けのストレージ１４に格納されてもよい。
【００６９】
コンピュートノード２００は、記憶部２１０、分散配信部２２０およびＣＭＰ２３０を有する。記憶部２１０は、コンピュートノード２００が備えるＲＡＭやＨＤＤの記憶領域を用いて実現される。分散配信部２２０およびＣＭＰ２３０は、コンピュートノード２００が備えるＲＡＭに記憶されたプログラムを、コンピュートノード２００が備えるプロセッサが実行することで実現される。
【００７０】
記憶部２１０は、配信されたイメージを記憶する。
分散配信部２２０は、前述の分散配信デーモンに相当するモジュールである。分散配信部２２０は、記憶部２１０に格納されたイメージを管理する。分散配信部２２０は、他のノードからのイメージの取得や他のコンピュートノードへのイメージの提供を行う。分散配信部２２０は、ＨＤＤなどの空き容量の管理やイメージの削除を行う。
【００７１】
ＣＭＰ２３０は、前述のコンピュートサービス（ＣＭＰ）に相当するモジュールである。ＣＭＰ２３０は、コンピュートノード２００上でのインスタンスの管理（起動／終了など）を行う。
【００７２】
コンピュートノード２００以外の他のコンピュートノードも、コンピュートノード２００と同様の機能を有する。
図７は、第２の実施の形態のノードの状態遷移例を示す図である。配信管理部１３０は、各ノードの状態をイメージ毎に管理する。各ノードは、イメージ毎に、未取得、要求中、取得中、取得完了、配信可能および配信中の何れかの状態をとる。
【００７３】
未取得状態は、初期状態であり、イメージを未取得の状態である。要求中状態は、イメージの配信先（すなわち、インスタンスの配備先）として決定された状態である。取得中状態は、イメージを取得中（ダウンロード中）の状態である。取得完了状態は、イメージの取得が完了した状態である。配信可能状態は、取得したイメージの配信準備が完了し、他のコンピュートノードへの配信が可能になった状態である。配信中状態は、保持するイメージの他のコンピュートノードへの配信を実行している状態である。
【００７４】
未取得状態は要求中状態に遷移する。未取得状態から要求中状態に遷移する条件Ｔａ１は、イメージの配信先のコンピュートノードとして決定されたことである。
要求中状態は取得中状態に遷移する。要求中状態から取得中状態に遷移する条件Ｔａ２は、配信先のコンピュートノードおよび当該配信先のコンピュートノードに対するイメージの配信元ノードが決定したことである。
【００７５】
取得中状態は取得完了状態に遷移する。取得中状態から取得完了状態に遷移する条件Ｔａ３は、該当のコンピュートノードに対するイメージの配信が完了したことである。
取得完了状態は配信可能状態に遷移する。取得完了状態から配信可能状態に遷移する条件Ｔａ４は、イメージの配信を受けたコンピュートノードにおいて、他のコンピュートノードへのイメージの配信準備が完了したことである。なお、コンピュートノードによっては、配信完了状態から配信可能状態へ遷移しないこともある。
【００７６】
ここで、配信準備では、コンピュートノードは、例えば、所定のＷｅｂサーバ機能を用いてイメージ配信を行うために、該当のイメージを公開用のディレクトリにコピーしたり、コピーしたイメージに対して所定のアクセス権限を設定したりする処理を行う。
【００７７】
配信可能状態は配信中状態に遷移する。配信可能状態から配信中状態に遷移する条件Ｔａ５は、該当のイメージの配信先のコンピュートノードが決定し、配信処理が開始されたことである。
【００７８】
配信中状態は配信可能状態に遷移する。配信中状態から配信可能状態に遷移する条件Ｔａ６は、該当のイメージの配信処理が完了したことである。
また、取得完了状態は未取得状態に遷移することもある。取得完了状態から未取得状態に遷移する条件Ｔａ７は、ディスク容量が不足し、該当のイメージを削除したことである。更に、配信可能状態は未取得状態に遷移することもある。配信可能状態から未取得状態に遷移する条件Ｔａ８は、ディスク容量が不足し、該当のイメージを削除したことである。
【００７９】
図８は、第２の実施の形態のクラスタの状態遷移例を示す図である。配信管理部１３０は、各クラスタの状態をイメージ毎に管理する。各クラスタは、イメージ毎に、未取得、要求中、取得中、取得完了、配信可能および配信中の何れかの状態をとる。
【００８０】
未取得状態は、初期状態であり、所属する何れのノードも該当のイメージを未取得の状態である。要求中状態は、所属する何れかのノードがイメージの配信先として決定された状態である。取得中状態は、所属する何れかのノードがイメージを取得中（ダウンロード中）の状態である。取得完了状態は、イメージを取得中のノードがイメージの取得を完了した状態である。配信可能状態は、イメージの取得を完了したノードで、取得したイメージの配信準備が完了し、他のコンピュートノードへの配信が可能になった状態である。配信中状態は、イメージの配信が可能となった何れかのノードが、他のコンピュートノードに対するイメージの配信を実行している状態である。
【００８１】
未取得状態は要求中状態に遷移する。未取得状態から要求中状態に遷移する条件Ｔｂ１は、該当のクラスタに属するコンピュートノードがイメージの配信先として決定されたことである。
【００８２】
要求中状態は取得中状態に遷移する。要求中状態から取得中状態に遷移する条件Ｔｂ２は、該当の配信先のコンピュートノードに対するイメージの配信元ノードが決定し、配信処理が開始されたことである。
【００８３】
取得中状態は取得完了状態に遷移する。取得中状態から取得完了状態に遷移する条件Ｔｂ３は、該当のコンピュートノードに対するイメージの配信が完了したことである。
取得完了状態は配信可能状態に遷移する。取得完了状態から配信可能状態に遷移する条件Ｔｂ４は、該当のクラスタに属するイメージの配信を受けたコンピュートノードにおいて、他のコンピュートノードへのイメージの配信準備が完了したことである。
【００８４】
配信可能状態は配信中状態に遷移する。配信可能状態から配信中状態に遷移する条件Ｔｂ５は、該当のクラスタに属するコンピュートノードについて、イメージの配信先のコンピュートノードが決定し、配信処理が開始されたことである。
【００８５】
配信中状態は配信可能状態に遷移する。配信中状態から配信可能状態に遷移する条件Ｔｂ６は、該当のイメージの配信処理が完了したことである。
また、取得完了状態は未取得状態に遷移することもある。取得完了状態から未取得状態に遷移する条件Ｔｂ７は、ディスク容量が不足し、該当のクラスタに属する全てのノードから該当のイメージを削除したことである。更に、配信可能状態は未取得状態に遷移することもある。配信可能状態から未取得状態に遷移する条件Ｔｂ８は、ディスク容量が不足し、該当のクラスタに属する全てのノードから該当のイメージを削除したことである。
【００８６】
図９は、第２の実施の形態のクラスタ構成テーブルの例を示す図である。クラスタ構成テーブル１１１は、記憶部１１０に予め格納される。クラスタ構成テーブル１１１は、図５で例示したクラスタ構成を管理するための情報である。クラスタ構成テーブル１１１は、クラスタ名および所属ノードの項目を含む。
【００８７】
クラスタ名の項目には、クラスタ名が登録される。所属ノードの項目には、該当のクラスタ名で示されるクラスタに所属するノードのノード名が登録される。
例えば、クラスタ構成テーブル１１１には、クラスタ名が“クラスタＡ”、所属ノードが“クラウドコントローラ”という情報が登録される。これは、クラスタ名“クラスタＡ”のクラスタ（単に、クラスタＡと称することがある）に、ノード名“クラウドコントローラ”で識別されるコントローラノード１００が所属していることを示す。
【００８８】
また、クラスタ構成テーブル１１１には、クラスタ名が“クラスタＡ”、所属ノードが“ノードＡ１”という情報が登録される。これは、クラスタＡに、ノード名“ノードＡ１”で識別されるコンピュートノード２００が所属していることを示す。
【００８９】
更に、クラスタ構成テーブル１１１には、クラスタ名が“クラスタＢ”、所属ノードが“ノードＢ１”という情報が登録される。これは、クラスタＢに、ノード名“ノードＢ１”で識別されるコンピュートノード３００が所属していることを示す。
【００９０】
クラスタ構成テーブル１１１には、他のコンピュートノードに対しても、クラスタ名とコンピュートノードのノード名との対応関係が登録されている。
図１０は、第２の実施の形態のノード配信状況テーブルの例を示す図である。ノード配信状況テーブル１１２は、記憶部１１０に格納される。ノード配信状況テーブル１１２は、配信管理部１３０による各ノードの状態の管理に用いられる。ノード配信状況テーブル１１２は、ノード名、イメージ名、未取得、要求中、取得中、取得完了、配信可能および配信中の項目を含む。
【００９１】
ノード名の項目には、ノード名が登録される。イメージ名の項目には、イメージ名が登録される。未取得の項目には、未取得状態であるか否かを示すフラグが登録される。要求中の項目には、要求中状態であるか否かを示すフラグが登録される。取得中の項目には、取得中状態であるか否かを示すフラグが登録される。取得完了の項目には、取得完了状態であるか否かを示すフラグが登録される。配信可能の項目には、配信可能状態であるか否かを示すフラグが登録される。配信中の項目には、配信中状態であるか否かを示すフラグが登録される。
【００９２】
ここで、未取得、要求中、取得中、取得完了、配信可能および配信中の項目に設定されるフラグは、“０”（ｆａｌｓｅに相当）、または、“１”（ｔｒｕｅに相当）の何れかである。１つのレコードにおいて、未取得、要求中、取得中、取得完了、配信可能および配信中の項目の何れか１つだけが“１”であり、それ以外の項目は“０”になる（各ノードは、１つのイメージに対して１つの状態をとるため）。
【００９３】
例えば、ノード配信状況テーブル１１２には、ノード名が“コントローラ”、イメージ名が“イメージＸ”、未取得が“０”、要求中が“０”、取得中が“０”、取得完了が“０”、配信可能が“１”、配信中が“０”という情報が登録される。これは、コントローラノード１００がイメージＸを保持しており、イメージＸの配信可能状態にあることを示す。
【００９４】
また、ノード配信状況テーブル１１２には、ノード名が“ノードＡ２”、イメージ名が“イメージＸ”、未取得が“１”、要求中が“０”、取得中が“０”、取得完了が“０”、配信可能が“０”、配信中が“０”という情報が登録される。これは、コンピュートノード２００ａがイメージＸを保持していない（未取得状態である）ことを示す。
【００９５】
このように、ノード配信状況テーブル１１２には、イメージ毎に各ノードの状態が登録される。なお、図１０に示すノード配信状況テーブル１１２は、図５で例示したイメージＸ，Ｙの配置に対応している。
【００９６】
図１１は、第２の実施の形態のクラスタ配信状況テーブルの例を示す図である。クラスタ配信状況テーブル１１３は、記憶部１１０に格納される。クラスタ配信状況テーブル１１３は、配信管理部１３０による各クラスタの状態の管理に用いられる。クラスタ配信状況テーブル１１３は、クラスタ名、イメージ名、未取得、要求中、取得中、取得完了、配信可能および配信中の項目を含む。
【００９７】
クラスタ名の項目には、クラスタ名が登録される。イメージ名、未取得、要求中、取得中、取得完了、配信可能および配信中の各項目に登録される情報は、ノード配信状況テーブル１１２における同名の項目と同じである。ただし、未取得、要求中、取得中、取得完了、配信可能および配信中の各項目の情報は、該当のクラスタの状態を示している。１つのレコードにおいて、未取得、要求中、取得中、取得完了、配信可能および配信中の項目の何れか１つだけが“１”であり、それ以外の項目は“０”になる（各クラスタは、１つのイメージに対して１つの状態をとるため）。
【００９８】
例えば、クラスタ配信状況テーブル１１３には、クラスタ名が“クラスタＡ”、イメージ名が“イメージＸ”、未取得が“０”、要求中が“０”、取得中が“０”、取得完了が“０”、配信可能が“１”、配信中が“０”という情報が登録される。これは、クラスタＡに属する少なくとも１つのノード（具体的には、コントローラノード１００およびコンピュートノード２００）がイメージＸを保持していることを示す。また、当該ノード（コントローラノード１００およびコンピュートノード２００の何れか一方、または、両方）がイメージＸの配信可能状態にあることを示す。
【００９９】
また、クラスタ配信状況テーブル１１３には、クラスタ名が“クラスタＢ”、イメージ名が“イメージＸ”、未取得が“１”、要求中が“０”、取得中が“０”、取得完了が“０”、配信可能が“０”、配信中が“０”という情報が登録される。これは、クラスタＢに属するコンピュートノード３００，３００ａ，３００ｂ，３００ｃの全てが、イメージＸを保持していない（未取得状態である）ことを示す。
【０１００】
このように、クラスタ配信状況テーブル１１３には、イメージ毎に各クラスタの状態が登録される。なお、図１１に示すクラスタ配信状況テーブル１１３は、図５で例示したイメージＸ，Ｙの配置、および、当該配置を表すノード配信状況テーブル１１２の内容に対応している。
【０１０１】
なお、ノード配信状況テーブル１１２およびクラスタ配信状況テーブル１１３の例では、取り得る状態毎に、フラグを設けるものとしたが、配信管理部１３０は、各状態に相当する識別子を予め定め、ノード毎、および、クラスタ毎に当該識別子を管理してもよい。例えば、配信管理部１３０は、未取得状態を“０”、要求中状態を“１”、取得中状態を“２”、取得完了状態を“３”、配信可能状態を“４”、配信中状態を“５”のように数値で識別してもよい。この場合、配信管理部１３０は、状態遷移に応じてノード毎、および、クラスタ毎のエントリを、遷移後の状態を示す数値に変更することが考えられる。
【０１０２】
図１２は、第２の実施の形態の距離情報の例を示す図である。距離情報１１４は、記憶部１１０に格納される。距離情報１１４は、イメージＸに対する各コンピュートノードの距離の指標を示す。ここで、図１２において、距離情報の各行の左側に付した番号は、行番号である。
【０１０３】
距離情報１１４の２行目には、距離情報１１４が表す指標の名称として“距離”が記録されている。同３行目には、距離の計算の対象となったイメージのイメージ名が“イメージＸ”であることが記録されている。同４行目〜１５行目は、コンピュートノードとイメージＸを保持する他のコンピュートノードとの距離（スコア）が記録されている。
【０１０４】
ここで、配信管理部１３０は、あるコンピュートノード（配信先候補のコンピュートノード）から、配信対象のイメージを保持する他のコンピュートノード（配信元のコンピュートノード）までの距離を次のように計算する。
【０１０５】
配信管理部１３０は、配信先候補のコンピュートノードと配信元のコンピュートノードとが同一である場合、距離を“０”とする。
配信管理部１３０は、配信先候補のコンピュートノードと配信元のコンピュートノードとが異なり、かつ、両者が同一クラスタに属している場合、距離を“１”とする。
【０１０６】
配信管理部１３０は、配信先候補のコンピュートノードと配信元のコンピュートノードとが異なり、かつ、両者が異なるクラスタに属している場合、距離を“２”とする。
ここで、配信管理部１３０は、配信先候補のコンピュートノードと配信元のコンピュートノードとが同一クラスタに属しているか否かを、クラスタ構成テーブル１１１を参照して判断できる。
【０１０７】
図１３は、第２の実施の形態の重みテーブルの例を示す図である。重みテーブル１１５は、記憶部１１０に予め格納される。重みテーブル１１５は、指標および重みの項目を含む。
【０１０８】
指標の項目には、配信先のコンピュートノードを決定するためのスコア評価に用いられる指標の名称が登録される。ここで、スコアは、値が大きいほど、インスタンスの配備先として適している（良い）ことを示す。重みの項目には、該当の指標に対する重みが登録される。値が大きいほど良いと評価する指標に対して、指標の重みの符号はプラスとする。逆に、値が小さいほど悪いと評価する指標に対して、指標の重みの符号はマイナスとする。
【０１０９】
例えば、重みテーブル１１５には、指標が“メモリ空き容量”、重みが“１”という情報が登録される。これは、コンピュートノードにおけるＲＡＭ（メモリ）の空き容量の重みを“１”とすることを示す。
【０１１０】
また、重みテーブル１１５には、指標が“ディスク入出力”、重みが“−０．５”という情報が登録される。これは、コンピュートノードにおけるＨＤＤ（ディスク）の入出力負荷（例えば、単位時間当たりのＩ／Ｏ（Input / Output）待ち率やＩ／Ｏ発生率など）の重みを“−０．５”とすることを示す。
【０１１１】
また、重みテーブル１１５には、指標が“プロセッサ使用率”、重みが“−０．５”という情報が登録される。これは、コンピュートノードにおけるプロセッサの使用率の重みを“−０．５”とすることを示す。
【０１１２】
また、重みテーブル１１５には、指標が“イメージからの距離”、重みが“−１”という情報が登録される。これは、コンピュートノードにおけるイメージからの距離（配信対象のイメージを保持する他のコンピュートノードからの距離）の重みを“−１”とすることを示す。
【０１１３】
次に、第２の実施の形態の情報処理システムによる新たなインスタンスの配備（デプロイ）時の処理手順を説明する。まず、システム全体における処理の流れを説明する。
図１４は、第２の実施の形態のデプロイ例を示すシーケンス図である。以下、図１４に示す処理をステップ番号に沿って説明する。
【０１１４】
（ＳＴ１）ユーザＵ１は、入力デバイス１２を操作して、新たなインスタンスのデプロイ指示を入力する。デプロイ指示は、配備対象とするインスタンスのイメージ（配信対象のイメージと称してもよい）、および、インスタンスの配備数（イメージの配備数と称してもよい）の指定を含む。なお、ユーザＵ１は、ネットワークＮ１を介して、他のコンピュートノード、あるいは、ユーザＵ１が使用するクライアントコンピュータを操作して、コントローラノード１００にデプロイ指示を入力してもよい。ＣＴＲ１２０は、デプロイ指示を受け付ける。
【０１１５】
（ＳＴ２）ＣＴＲ１２０は、配信先候補のコンピュートノードから、イメージを保持するコンピュートノードまでの距離の情報を、配信管理部１３０に要求する（情報要求）。  （ＳＴ３）配信管理部１３０は、情報要求に応じて、配信先候補のコンピュートノードから、イメージを保持するコンピュートノードまでの距離を計算し、計算結果をＣＴＲ１２０に提供する（情報提供）。ここで、第２の実施の形態の例では、配信先候補のコンピュートノードは、システムに存在する全てのコンピュートノードである。ただし、インスタンスの配備先として除外したいコンピュートノードがある場合、当該コンピュートノードを配信先候補から予め除外してもよい。
【０１１６】
（ＳＴ４）ＣＴＲ１２０は、各コンピュートノードから負荷情報（例えば、メモリ、ディスクおよびプロセッサの負荷を示す情報）を取得する。ＣＴＲ１２０は、各コンピュートノードに対して計算された距離と、各コンピュートノードから取得した負荷情報とに基づいて、各コンピュートノードのスコアを計算する。ＣＴＲ１２０は、計算したスコアに基づいて、指定された配備数の分、配信先のコンピュートノードを選択する。ここでは、選択されたコンピュートノードは、コンピュートノード２００を含むとする。
【０１１７】
（ＳＴ５）ＣＴＲ１２０は、選択された配信先のコンピュートノード２００と、配信先のコンピュートノードがイメージの取得元とするノードとを指定する情報を含む配信指示実行要求を、配信管理部１３０に通知する。
【０１１８】
（ＳＴ６）配信管理部１３０は、ＣＴＲ１２０からの配信指示実行要求に応じて、配信指示処理を実行し、コンピュートノード２００に対して、イメージ取得指示を送信する。イメージ取得指示は、イメージの取得元のノードや配信対象のイメージの指定を含む。分散配信部２２０は、イメージ取得指示を受信する。
【０１１９】
（ＳＴ７）分散配信部２２０は、イメージ取得指示により指定されたイメージの取得元のノードから、イメージを取得する。
（ＳＴ８）分散配信部２２０は、イメージの取得が完了すると、コントローラノード１００に対し、取得完了報告を送信する。配信管理部１３０は、取得完了報告を受信する。
【０１２０】
（ＳＴ９）分散配信部２２０は、新たに取得したイメージの配信準備を行う。
（ＳＴ１０）分散配信部２２０は、新たに取得したイメージの配信準備が完了すると、コントローラノード１００に対し、配信準備完了報告を送信する。なお、配信先のコンピュートノードが複数ある場合、ステップＳＴ６〜ＳＴ１０は、配信先のコンピュートノード毎に実行されることになる。
【０１２１】
（ＳＴ１１）配信管理部１３０は、配信先の全てのコンピュートノードからイメージの取得完了報告を受信すると、ＣＴＲ１２０に配信完了報告を通知する。
（ＳＴ１２）ＣＴＲ１２０は、配信先のコンピュートノード２００に新たに配信が完了したイメージによるインスタンス起動指示を送信する。
【０１２２】
（ＳＴ１３）ＣＭＰ２３０は、インスタンス起動指示を受信すると、インスタンス起動指示に応じて、ステップＳＴ７で取得したイメージを用いて新たなインスタンスを起動する。
【０１２３】
（ＳＴ１４）ＣＭＰ２３０は、インスタンスの起動が完了すると、コントローラノード１００に対して、インスタンス起動完了報告を送信する。なお、配信先のコンピュートノードが複数ある場合、ステップＳＴ１２〜ＳＴ１４は、配信先のコンピュートノード毎に実行されることになる。
【０１２４】
（ＳＴ１５）ＣＴＲ１２０は、配信先の全てのコンピュートノードからインスタンス起動完了報告を受信すると、ユーザＵ１に対してデプロイ完了報告を通知する。通知方法としては、例えば、デプロイ指示によって指示されたインスタンスのデプロイが完了した旨をディスプレイ１１、あるいは、ユーザＵ１が使用するクライアントコンピュータに表示するなどが考えられる。
【０１２５】
このように、各ノードは、ユーザＵ１によるデプロイ指示に応じて、インスタンスを動的に配備する。次に、インスタンスの配備以外の処理の流れを説明する。インスタンスの配備以外の主な処理としては、（１）新規のコンピュートノードの追加、（２）キャッシュとして保持されたイメージの削除、および、（３）新規のイメージの登録が挙げられる。
【０１２６】
図１５は、第２の実施の形態の他の処理例を示すシーケンス図である。以下、図１５に示す処理をステップ番号に沿って説明する。図１５では、シーケンスを３段に分けて、上記の（１）、（２）、（３）それぞれに相当する処理の流れを例示する。ステップＳＴ２１〜ＳＴ２３は、上記（１）の処理に相当する。ステップＳＴ３１〜ＳＴ３３は、上記（２）の処理に相当する。ステップＳＴ４１〜ＳＴ４５は、上記（３）の処理に相当する。
【０１２７】
まず、新規のコンピュートノードの追加の流れを説明する。
（ＳＴ２１）コンピュートノード４００は、第２の実施の形態の情報処理システムに新たに追加されたコンピュートノードである。コンピュートノード４００の分散配信部４３０は、新規ノード追加報告をコントローラノード１００に送信する。新規ノード追加報告は、コンピュートノード４００のノード名やコンピュートノード４００が所属するクラスタ名の情報を含む。
【０１２８】
（ＳＴ２２）配信管理部１３０は、新規ノード追加報告を受信する。配信管理部１３０は、新規ノード追加報告に応じて、ノード追加処理を実行する。具体的には、配信管理部１３０は、クラスタ構成テーブル１１１、ノード配信状況テーブル１１２およびクラスタ配信状況テーブル１１３に、新たに追加されたコンピュートノードのレコードを追加する。
【０１２９】
（ＳＴ２３）配信管理部１３０は、追加完了報告をコンピュートノード４００に送信する。分散配信部４３０は、追加完了報告を受信する。これにより、新規のコンピュートノードの追加の手順が完了する。
【０１３０】
続いて、キャッシュとして保持されたイメージの削除の流れを説明する。
（ＳＴ３１）分散配信部２２０は、コンピュートノード２００におけるディスク（ＨＤＤ）の容量不足を検出すると、空き容量不足報告をコントローラノード１００に送信する。
【０１３１】
（ＳＴ３２）配信管理部１３０は、空き容量不足報告を受信すると、コンピュートノード２００により保持されるイメージのうち、削除対象とするイメージを決定する。具体的には、配信管理部１３０は、コンピュートノード２００により保持されるイメージのうち、同一クラスタに属する他のコンピュートノードにも保持されているイメージを優先して削除するように、削除対象とするイメージを決定する。配信管理部１３０は、決定したイメージのイメージ削除指示をコンピュートノード２００に送信する。
【０１３２】
（ＳＴ３３）分散配信部２２０は、イメージ削除指示を受信する。分散配信部２２０は、イメージ削除指示で指定されたイメージをディスクから削除する（キャッシュ削除）。これにより、キャッシュとして保持されたイメージがコンピュートノード２００から削除され、コンピュートノード２００におけるディスク容量不足が解消される。
【０１３３】
続いて、新規のイメージの登録の流れを説明する。
（ＳＴ４１）ユーザＵ１は、イメージ配信部１４０に対して、新規のイメージを入力する（イメージのアップロード）。ユーザＵ１は、入力デバイス１２を操作して、あるいは、ユーザＵ１が使用するクライアントコンピュータを操作して、新規のイメージをアップロードすることができる。ユーザＵ１は、新規のイメージとともに、当該イメージのイメージ名も入力する。イメージ配信部１４０は、新規のイメージのアップロードを受け付ける。イメージ配信部１４０は、新規のイメージを公開用のディレクトリにコピーする。
【０１３４】
（ＳＴ４２）イメージ配信部１４０は、新規のイメージの登録指示を配信管理部１３０に通知する。
（ＳＴ４３）配信管理部１３０は、新規のイメージの登録指示の通知を受け付けると、該当のイメージに関するレコードを、ノード配信状況テーブル１１２およびクラスタ配信状況テーブル１１３に登録する（イメージ登録）。
【０１３５】
（ＳＴ４４）配信管理部１３０は、イメージ登録が完了すると、イメージ配信部１４０に完了報告を通知する。
（ＳＴ４５）イメージ配信部１４０は、完了報告を受けると、イメージ登録完了報告をユーザＵ１に通知する。通知方法としては、例えば、新規のイメージの登録が完了した旨を、ディスプレイ１１、あるいは、ユーザＵ１が使用するクライアントコンピュータに表示するなどが考えられる。こうして、コントローラノード１００における新規のイメージの登録が完了する。そして、コントローラノード１００は、新規のイメージについて配信可能状態になる。
【０１３６】
続いて、図１４，図１５で例示した処理の具体的な手順を説明する。まず、図１４の処理におけるコントローラノード１００の処理手順を説明する。
図１６は、第２の実施の形態のデプロイ例を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。
【０１３７】
（Ｓ１１）ＣＴＲ１２０は、ユーザＵ１により入力されたデプロイ指示を受け付ける。デプロイ指示は、デプロイ対象のインスタンスのイメージおよび配備数の指定を含む。ＣＴＲ１２０は、配信先候補のコンピュートノード毎に、イメージを保持するコンピュートノードとの距離を計算するように配信管理部１３０に要求する。
【０１３８】
（Ｓ１２）配信管理部１３０は、配信先候補のコンピュートノード毎に、ＣＴＲ１２０により要求された距離の計算を行う。処理の詳細は後述される。
（Ｓ１３）ＣＴＲ１２０は、配信管理部１３０による距離の計算結果、および、各コンピュートノードの負荷情報を取得する。ＣＴＲ１２０は、各コンピュートノードの負荷および距離により、重みテーブル１１５に登録された指標毎の重みに基づいて、各コンピュートノードのスコアを計算する。
【０１３９】
（Ｓ１４）ＣＴＲ１２０は、計算したスコアを基に、新たなインスタンスの配備先（イメージの配信先）のコンピュートノードを決定する。ＣＴＲ１２０は、決定した配信先のコンピュートノードの情報を配信管理部１３０に通知する。
【０１４０】
（Ｓ１５）配信管理部１３０は、記憶部１１０に記憶されたノード配信状況テーブル１１２およびクラスタ配信状況テーブル１１３を更新する。具体的には、該当のイメージの配信先として選択されたコンピュートノードおよびクラスタのうち、当該イメージを未取得のものを、要求中状態に遷移させる。
【０１４１】
（Ｓ１６）配信管理部１３０は、配信指示処理を行う。配信指示処理では、配信管理部１３０は、配信先として選択されたコンピュートノードに対するイメージ取得指示を送信する。処理の詳細は後述される。
【０１４２】
図１７は、第２の実施の形態の距離計算例を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１６のステップＳ１２に相当する。
【０１４３】
（Ｓ２１）配信管理部１３０は、イメージの配信先のノードの候補から１つのノード（ノードＮとする）を選択する。
（Ｓ２２）配信管理部１３０は、クラスタ構成テーブル１１１からノードＮが属するクラスタのクラスタ名を取得する。
【０１４４】
（Ｓ２３）配信管理部１３０は、ノード配信状況テーブル１１２とクラスタ配信状況テーブル１１３とを参照し、ノードＮのイメージの保持状況を確認する。
（Ｓ２４）配信管理部１３０は、ノード配信状況テーブル１１２に基づいて、ノードＮが配信対象のイメージを持っているか否かを判定する。持っている場合、処理をステップＳ２５に進める。持っていない場合、処理をステップＳ２６に進める。なお、ノードＮが配信対象のイメージを持っている場合とは、ノード配信状況テーブル１１２に含まれるノードＮの配信対象のイメージに関するレコードにおいて、取得完了、配信可能および配信中の何れかに“１”が設定されている場合である。取得完了、配信可能および配信中の何れも“０”の場合、ノードＮは配信対象のイメージを持っていないことになる。
【０１４５】
（Ｓ２５）配信管理部１３０は、ノードＮの距離（ノードＮから該当のイメージを保持するノードまでの距離であり、該当のイメージからの距離ともいえる）を０と決定する。そして、処理をステップＳ２９に進める。
【０１４６】
（Ｓ２６）配信管理部１３０は、クラスタ配信状況テーブル１１３に基づいて、ノードＮが属する該当のクラスタが配信対象のイメージを持っているか否かを判定する。持っている場合、処理をステップＳ２７に進める。持っていない場合、処理をステップＳ２８に進める。なお、ノードＮが属する該当のクラスタが配信対象のイメージを持っている場合とは、クラスタ配信状況テーブル１１３における該当クラスタの配信対象のイメージに関するレコードにおいて、取得完了、配信可能および配信中の何れかに“１”が設定されている場合である。取得完了、配信可能および配信中の何れも“０”の場合、該当のクラスタは配信対象のイメージを持っていないことになる。
【０１４７】
（Ｓ２７）配信管理部１３０は、ノードＮの距離を１と決定する。そして、処理をステップＳ２９に進める。
（Ｓ２８）配信管理部１３０は、ノードＮの距離を２と決定する。
【０１４８】
（Ｓ２９）配信管理部１３０は、配信先候補の全てのコンピュートノードを処理済としたか（全てのコンピュートノードに対して距離を計算したか）否かを判定する。配信先候補の全てのコンピュートノードを処理済の場合、処理を終了する。配信先候補の全てのコンピュートノードを処理済でない場合、処理をステップＳ２１に進める。ステップＳ２１では、配信管理部１３０は、未処理のコンピュートノードの中から新たにノードＮを選択することになる。
【０１４９】
図１８は、第２の実施の形態のスコア計算例（その１）を示す図である。ＣＴＲ１２０は、各コンピュートノードからメモリ空き容量（単位はＧＢ（Giga Bytes））、ディスク入出力といったＲＡＭやＨＤＤなどの記憶装置の負荷情報を取得する。ここで、ディスク入出力の負荷は、前述のように、単位時間当たりのＩ／Ｏ待ち率やＩ／Ｏ発生率などである。例えば、ＣＴＲ１２０は、各コンピュートノードの負荷情報と、配信管理部１３０から取得した各コンピュートノードのイメージからの距離とを、記憶部１１０に記憶されたノード管理テーブル１１６に記録する。
【０１５０】
ここで、以下に示す具体例では、デプロイ指示において、イメージＸにより起動されるインスタンスが指定され、インスタンスの配備数“８”が指定されているものとする。
ノード管理テーブル１１６では、図５および図９で例示したクラスタ構成において、イメージＸを新たに配信する場合の距離を例示している。図１７の手順によれば、コンピュートノード２００のイメージＸからの距離は“０”である。コンピュートノード２００ａ，２００ｂ，２００ｃ，２００ｄ，２００ｅ，２００ｆのイメージＸからの距離は“１”である。コンピュートノード３００，３００ａ，３００ｂ，３００ｃのイメージＸからの距離は“２”である。
【０１５１】
ＣＴＲ１２０は、ノード管理テーブル１１６に記録されたメモリ空き容量、ディスク入出力およびイメージからの距離といった各指標の値を所定の演算によって正規化した値（スコア）を求め、スコアテーブル１１７を生成する。ＣＴＲ１２０は、重みテーブル１１５に設定された重みを用いて、スコアテーブル１１７の各スコアを重み付けした上で加算し、最終的なスコア（最終スコア）の計算結果を得る。具体的には、ＣＴＲ１２０は、重みテーブル１１５に設定された指標毎の重みを、スコアテーブル１１７の各スコアに乗じて、コンピュートノード毎に和を取った値を、コンピュートノード毎の最終スコアとする。一例を示せば、コンピュートノード２００（ノード名“ノードＡ１”）の最終スコアは、０×１＋１×（−０．５）＋０×（−１）＝−０．５である。
【０１５２】
図１９は、第２の実施の形態の最終的なスコア計算結果の例を示す図である。最終スコアテーブル１１８は、スコアテーブル１１７および重みテーブル１１５に基づいて計算された各コンピュートノードの最終スコアを示す情報である。最終スコアテーブル１１８は、記憶部１１０に記憶される。最終スコアテーブル１１８は、ノード名、最終スコアおよび順位の項目を含む。ノード名の項目には、コンピュートノードのノード名が登録される。最終スコアの項目には、最終スコアが登録される。順位の項目には、インスタンスの配備先としての優先順位が登録される。順位は、値が小さいほど優先度が高いことを示す。
【０１５３】
ＣＴＲ１２０は、各コンピュートノードのうち、順位の高いものから順に、配備数分だけインスタンスの配備先として選択する。デプロイ指示で指定された配備数は“８”である。最終スコアテーブル１１８の例では、順位の優先順に、ノード名“ノードＡ４”、“ノードＡ５”、“ノードＡ６”、“ノードＡ７”、“ノードＡ１”、“ノードＢ２”、“ノードＢ３”、“ノードＡ２”それぞれに対応するコンピュートノードが選択される。すなわち、ＣＴＲ１２０は、コンピュートノード２００ｃ，２００ｄ，２００ｅ，２００ｆ，２００，３００ａ，３００ｂ，２００ａを、インスタンスの配備先（イメージの配信先）として選択する。
【０１５４】
なお、図１８の例では、ＣＴＲ１２０が各コンピュートノードから取得する負荷情報として、メモリ空き容量やディスク入出力の負荷を取得するものとしたが、評価の対象とする負荷の指標は任意に決定することができる。
【０１５５】
図２０は、第２の実施の形態のスコア計算例（その２）を示す図である。例えば、ＣＴＲ１２０は、各コンピュートノードのメモリ空き容量とプロセッサ使用率とを負荷情報として取得してもよい。この場合、ＣＴＲ１２０は、ノード管理テーブル１１６ｘおよびスコアテーブル１１７ｘを作成し、記憶部１１０に格納する。ＣＴＲ１２０は、スコアテーブル１１７ｘを用いて、最終スコアテーブル１１８を得ることもできる。あるいは、ＣＴＲ１２０は、各コンピュートノードのメモリ空き容量、ディスク入出力の負荷およびプロセッサ使用率の３種類またはそれ以上の指標を負荷情報として取得し、各コンピュートノードのスコア評価を行ってもよい。
【０１５６】
図２１は、第２の実施の形態の配信状況の例（配信開始時）を示す図である。図２１では、図１６のステップＳ１５の具体例を示している。ＣＴＲ１２０は、イメージＸの配信先として決定したコンピュートノード２００，２００ａ，２００ｃ，２００ｄ，２００ｅ，２００ｆ，３００ａ，３００ｂを、配信指示実行要求により、配信管理部１３０に通知する。ただし、ノード配信状況テーブル１１２によれば、コンピュートノード２００は既にイメージＸを保持している。
【０１５７】
配信管理部１３０は、配信指示実行要求に応じて、ノード配信状況テーブル１１２を更新し、イメージＸについて未取得状態であるコンピュートノード２００ａ，２００ｃ，２００ｄ，２００ｅ，２００ｆ，３００ａ，３００ｂを、要求中状態に遷移させる。図２１（Ａ）は、当該遷移直後のノード配信状況テーブル１１２ａを例示している。ただし、ノード配信状況テーブル１１２ａでは、イメージＹに関するレコードの図示を省略している。
【０１５８】
また、配信管理部１３０は、クラスタ配信状況テーブル１１３を操作して、イメージＸについて未取得状態であるクラスタＢを、要求中状態に遷移させる。図２１（Ｂ）は、当該遷移直後のクラスタ配信状況テーブル１１３ａを例示している。ただし、クラスタ配信状況テーブル１１３ａでは、イメージＹに関するレコードの図示を省略している。
【０１５９】
こうして、配信先として決定されたコンピュートノードに対してイメージの配信指示を行う準備が整う。次に、配信管理部１３０による配信指示の手順を説明する。
図２２は、第２の実施の形態の配信指示例を示すフローチャートである。以下、図２２に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１６のステップＳ１６に相当する。
【０１６０】
（Ｓ３１）配信管理部１３０は、クラスタ配信状況テーブル１１３ａを参照して、要求中状態のクラスタ（要求中クラスタと称する）があるか否かを判定する。要求中クラスタがある場合、処理をステップＳ３２に進める。要求中クラスタがない場合、処理をステップＳ３６に進める。イメージＸのインスタンスを配備する場合、クラスタ配信状況テーブル１１３ａの例では、クラスタＢが要求中クラスタである。
【０１６１】
（Ｓ３２）配信管理部１３０は、クラスタ配信状況テーブル１１３ａを参照して、配信対象のイメージを配信可能なクラスタ（配信可能クラスタと称する）があるか否かを判定する。配信可能クラスタがある場合、処理をステップＳ３３に進める。配信可能クラスタがない場合、処理をステップＳ３２に進める（何れかのクラスタが該当のイメージについて配信可能状態になるまで待機する）。クラスタ配信状況テーブル１１３ａの例では、クラスタＡがイメージＸの配信可能クラスタである。
【０１６２】
（Ｓ３３）配信管理部１３０は、クラスタ構成テーブル１１１およびノード配信状況テーブル１１２ａを参照して、要求中クラスタから要求中ノードを選択する。ノード配信状況テーブル１１２ａの例では、コンピュートノード３００ａ（“ノードＢ２”）およびコンピュートノード３００ｂ（“ノードＢ３”）が、イメージＸの要求中ノードである。要求中クラスタにおいて要求中ノードが複数存在する場合、配信管理部１３０は、要求中ノードを１つ選択する。
【０１６３】
（Ｓ３４）配信管理部１３０は、クラスタ構成テーブル１１１およびノード配信状況テーブル１１２ａを参照して、配信可能クラスタから配信可能ノードを選択する。ノード配信状況テーブル１１２ａの例では、コントローラノード１００およびコンピュートノード２００が、イメージＸの配信可能ノードである。配信可能クラスタにおいて配信可能ノードが複数存在する場合、配信管理部１３０は、配信可能ノードを１つ選択する。
【０１６４】
（Ｓ３５）配信管理部１３０は、ステップＳ３４で選択した配信可能ノードから、ステップＳ３３で選択した要求中ノードへイメージを配信させる。具体的には、配信管理部１３０は、選択した配信可能ノードからイメージＸを取得するように、選択した要求中ノードに、イメージ取得指示を送信する。イメージ取得指示を受信した要求中ノードは、指定された配信可能ノードからイメージＸを取得する。ここで、配信管理部１３０は、配信状況の変更に伴って、クラスタ配信状況テーブル１１３ａにおける要求中クラスタの状態を「要求中」から「取得中」へ、「取得中」から「取得完了」へ、「取得完了」から「配信可能」へと遷移させる。同様に、配信管理部１３０は、ノード配信状況テーブル１１２ａにおける要求中ノードの状態を「要求中」から「取得中」へ、「取得中」から「取得完了」へ、「取得完了」から「配信可能」へと遷移させる。そして、処理をステップＳ３１に進める。こうして、まずは、クラスタを跨いだイメージの配信が行われる。
【０１６５】
（Ｓ３６）配信管理部１３０は、ステップＳ３７〜Ｓ４２の手順をクラスタ毎に並列して実行する。ノード配信状況テーブル１１２ａおよびクラスタ配信状況テーブル１１３ａの例では、配信管理部１３０は、ステップＳ３７〜Ｓ４２の手順をクラスタＡ，Ｂそれぞれに対して、個別に実行する。以下の説明では、処理対象の１つのクラスタを指して、「着目するクラスタ」と称する。
【０１６６】
（Ｓ３７）配信管理部１３０は、クラスタ構成テーブル１１１およびノード配信状況テーブル（具体的な内容は後述される）を参照して、着目するクラスタにおいて要求中ノードがあるか否かを判定する。要求中ノードがある場合、処理をステップＳ３８に進める。要求中ノードがない場合、処理をステップＳ４２に進める。
【０１６７】
（Ｓ３８）配信管理部１３０は、クラスタ構成テーブル１１１およびノード配信状況テーブルを参照して、着目するクラスタにおいて配信可能ノードがあるか否かを判定する。着目するクラスタにおいて配信可能ノードがある場合、処理をステップＳ３９に進める。着目するクラスタにおいて配信可能ノードがない場合、処理をステップＳ３８に進める（同クラスタにおいて配信可能ノードができるまで待機する）。
【０１６８】
（Ｓ３９）配信管理部１３０は、クラスタ構成テーブル１１１およびノード配信状況テーブルを参照して、着目するクラスタ内で要求中ノードを選択する。着目するクラスタにおいて配信可能ノードが複数存在する場合、配信管理部１３０は、ノード名などの順に、配信可能ノードを１つ選択する。
【０１６９】
（Ｓ４０）配信管理部１３０は、クラスタ構成テーブル１１１およびノード配信状況テーブルを参照して、着目するクラスタ内で配信可能ノードを選択する。着目するクラスタにおいて配信可能ノードが複数存在する場合、配信管理部１３０は、ノード名などの順に、配信可能ノードを１つ選択する。
【０１７０】
（Ｓ４１）配信管理部１３０は、ステップＳ４０で選択した配信可能ノードからステップＳ３９で選択した要求中ノードへイメージを配信させる。具体的には、配信管理部１３０は、選択した配信可能ノードからイメージＸを取得するように、選択した要求中ノードに、イメージ取得指示を送信する。イメージ取得指示を受信した要求中ノードは、指定された配信可能ノードからイメージＸを取得する。ここで、配信管理部１３０は、配信状況の変更に伴って、ノード配信状況テーブルにおける要求中ノードの状態を「要求中」から「取得中」へ、「取得中」から「取得完了」へ、「取得完了」から「配信可能」へと遷移させる。そして、処理をステップＳ３７に進める。こうして、同じクラスタに属するノード間でのイメージの配信が行われる。
【０１７１】
（Ｓ４２）配信管理部１３０は、あるクラスタについて、当該クラスタ内のノード間でのイメージの配信が完了すると、当該クラスタに関する処理を終了する。
（Ｓ４３）配信管理部１３０は、ノード配信状況テーブルを参照して、全ての要求中ノードに対するイメージ配信の処理が終わったか否かを判定する。全ての要求中ノードに対するイメージ配信の処理が終わった場合、処理をステップＳ４４に進める。全ての要求中ノードに対するイメージ配信の処理が終わっていない場合、処理をステップＳ４３に進める（全ての要求中ノードに対するイメージ配信の処理が終わるまで待機する）。
【０１７２】
（Ｓ４４）配信管理部１３０は、配信処理の完了を、ＣＴＲ１２０に通知する。
このように、配信管理部１３０は、まずは、クラスタ間でのイメージ配信を行い、次に、同一クラスタに属するノード間でのイメージ配信を行う。クラスタ間のイメージ配信では、要求中クラスタに属する複数の配信先ノードのうちの１つに、該当のイメージを送信するように配信先ノードによるイメージ取得を制御する。これにより、イメージ配信に伴うクラスタ間（すなわち、スイッチ間）の通信量を低減できる。
【０１７３】
図２３は、第２の実施の形態の配信状況の更新例を示す図である。クラスタ配信状況テーブル１１３ｂは、図２２のステップＳ３５の処理に応じた、配信状況の更新例を示している。
【０１７４】
具体的には、まず、配信管理部１３０は、イメージＸの配信元であるクラスタＡを、「配信可能」から「配信中」へ遷移させる。また、配信管理部１３０は、イメージＸの配信先であるクラスタＢを、「要求中」から「取得中」へ遷移させる。
【０１７５】
また、ノード配信状況テーブル１１２ｂは、図２２のステップＳ３５の処理に応じた、配信状況の更新例を示している。ここでは、配信管理部１３０は、クラスタＡ内のコントローラノード１００をイメージＸの配信元として選択している。このため、コントローラノード１００を「配信可能」から「配信中」へ遷移させる。更に、配信管理部１３０は、クラスタＢ内のコンピュートノード３００ａをイメージＸの配信先として選択している。このため、コンピュートノード３００ａを「要求中」から「取得中」へ遷移させる。
【０１７６】
クラスタＡからクラスタＢへのクラスタを跨いだイメージＸの配信が完了すると、配信管理部１３０は、クラスタ配信状況テーブル１１３ｃおよびノード配信状況テーブル１１２ｃへと配信状況を更新する。
【０１７７】
具体的には、クラスタ配信状況テーブル１１３ｃで示されるように、配信管理部１３０は、クラスタＡを、「配信中」から「配信可能」へ遷移させる。また、配信管理部１３０は、クラスタＢを、「取得中」から「取得完了」へ遷移させる。
【０１７８】
また、ノード配信状況テーブル１１２ｃで示されるように、配信管理部１３０は、コントローラノード１００を、「配信中」から「配信可能」へ遷移させる。また、配信管理部１３０は、コンピュートノード３００ａを、「取得中」から「取得完了」へ遷移させる。
【０１７９】
図２４は、第２の実施の形態の配信状況の更新例（続き）を示す図である。配信管理部１３０は、コンピュートノード３００ａから配信準備完了報告を受信すると、クラスタ配信状況テーブル１１３ｄおよびノード配信状況テーブル１１２ｄで示されるように、配信状況を更新する。
【０１８０】
具体的には、クラスタ配信状況テーブル１１３ｄで示されるように、配信管理部１３０は、クラスタＢを、「取得完了」から「配信可能」へ遷移させる。また、ノード配信状況テーブル１１２ｄで示されるように、配信管理部１３０は、コンピュートノード３００ａを、「取得完了」から「配信可能」へ遷移させる。
【０１８１】
こうして、コントローラノード１００は、イメージＸの配信対象のコンピュートノードを含む各クラスタに対して、イメージＸを保持するノードが少なくとも１つ存在する状況を作り出せる。続いて、コントローラノード１００は、同じクラスタに属するノード間でイメージの配信を行うよう制御する。コントローラノード１００は、クラスタＡ，Ｂ毎に並列に、イメージＸの配信を行える。
【０１８２】
図２５は、第２の実施の形態のノード配信状況の更新例を示す図である。配信管理部１３０は、コンピュートノード２００ａに対するイメージＸの配信元をコントローラノード１００とし、イメージＸの配信を開始させる。また、配信管理部１３０は、コンピュートノード２００ｃに対するイメージＸの配信元をコンピュートノード２００とし、イメージＸの配信を開始させる。また、配信管理部１３０は、コンピュートノード３００ｂに対するイメージＸの配信元をコンピュートノード３００ａとし、イメージＸの配信を開始させる。そして、配信管理部１３０は、ノード配信状況テーブル１１２ｅで示されるように、配信状況を更新する。
【０１８３】
具体的には、配信管理部１３０は、コントローラノード１００およびコンピュートノード２００，３００ａを、「配信可能」から「配信中」へ遷移させる。配信管理部１３０は、コンピュートノード２００ａ，２００ｃ，３００ｂを、「要求中」から「取得中」へ遷移させる。
【０１８４】
配信管理部１３０は、上記のノード間での配信が完了すると、ノード配信状況テーブル１１２ｆで示されるように、配信状況を更新する。具体的には、配信管理部１３０は、コントローラノード１００およびコンピュートノード２００，３００ａを、「配信中」から「配信可能」へ遷移させる。配信管理部１３０は、コンピュートノード２００ａ，２００ｃ，３００ｂを、「取得中」から「取得完了」へ遷移させる。
【０１８５】
図２６は、第２の実施の形態のノード配信状況の更新例（続き）を示す図である。続いて、配信管理部１３０は、コンピュートノード２００ｄに対するイメージＸの配信元をコントローラノード１００とし、イメージＸの配信を開始させる。また、配信管理部１３０は、コンピュートノード２００ｅに対するイメージＸの配信元をコンピュートノード２００ａとし、イメージＸの配信を開始させる。そして、配信管理部１３０は、ノード配信状況テーブル１１２ｇで示されるように、配信状況を更新する。
【０１８６】
具体的には、配信管理部１３０は、コントローラノード１００およびコンピュートノード２００を、「配信可能」から「配信中」へ遷移させる。配信管理部１３０は、コンピュートノード２００ｄ，２００ｅを、「要求中」から「取得中」へ遷移させる。更に、配信管理部１３０は、コンピュートノード２００ａ，２００ｃ，３００ｂから配信準備完了報告を受信すると、コンピュートノード２００ａ，２００ｃ，３００ｂを、「取得完了」から「配信可能」へ遷移させる。
【０１８７】
そして、配信管理部１３０は、新たに配信可能状態となったコンピュートノード２００ａを用いて、クラスタＡ内でイメージＸを要求中であるコンピュートノード２００ｆへの配信を行うと決定し、イメージＸの配信を開始させる。配信管理部１３０は、ノード配信状況テーブル１１２ｈで示されるように、配信状況を更新する。
【０１８８】
具体的には、配信管理部１３０は、コンピュートノード２００ａを、「配信可能」から「配信中」へ遷移させる。配信管理部１３０は、コンピュートノード２００ｆを、「要求中」から「取得中」へ遷移させる。
【０１８９】
図２７は、第２の実施の形態のノード配信状況の更新例（続き）を示す図である。配信管理部１３０は、図２６で示すノード間での配信が完了すると、ノード配信状況テーブル１１２ｉで示されるように、配信状況を更新する。具体的には、配信管理部１３０は、コントローラノード１００およびコンピュートノード２００，２００ａを、「配信中」から「配信可能」へ遷移させる。配信管理部１３０は、コンピュートノード２００ｄ，２００ｅ，２００ｆを、「取得中」から「取得完了」へ遷移させる。ここで、配信管理部１３０は、新たにイメージＸを配信した全てのコンピュートノードを配信可能状態にしてもよいし、一部のコンピュートノードを配信可能状態にしなくてもよい。
【０１９０】
こうして、デプロイ指示に対して、イメージＸの配信先として決定された８つのコンピュートノードにおいて、イメージＸを用いたインスタンスの起動が可能になる。
次に、コンピュートノードを追加する際のコントローラノード１００の手順を説明する。以下では、図１５で例示したコンピュートノード４００が追加される場合を例示する。
【０１９１】
図２８は、第２の実施の形態のノード追加例を示すフローチャートである。以下、図２８に示す処理をステップ番号に沿って説明する。
（Ｓ５１）配信管理部１３０は、コンピュートノード４００の分散配信部４３０から名前（クラスタ名を含む）を取得する。具体的には、配信管理部１３０は、分散配信部４３０の名前（ノード名）およびコンピュートノード４００が属するクラスタ名を取得する。
【０１９２】
（Ｓ５２）配信管理部１３０は、追加されたコンピュートノード４００が既知のクラスタに属するか否かを判定する。既知のクラスタに属する場合、処理をステップＳ５４に進める。既知のクラスタに属さない場合、処理をステップＳ５３に進める。具体的には、ステップＳ５１で取得したクラスタ名が、クラスタ構成テーブル１１１に登録されていれば、コンピュートノード４００は既知のクラスタに属する。ステップＳ５１で所得したクラスタ名が、クラスタ構成テーブル１１１に登録されていなければ、コンピュートノード４００は既知のクラスタに属さない。
【０１９３】
（Ｓ５３）配信管理部１３０は、クラスタ配信状況テーブル１１３ｄに新レコードを追加する。具体的には、配信管理部１３０は、新たなクラスタ名とイメージ名との組毎に、クラスタ配信状況テーブル１１３ｄに新レコードを追加する。
【０１９４】
（Ｓ５４）配信管理部１３０は、クラスタ構成テーブル１１１に、クラスタ名とノード名とを追加する。
（Ｓ５５）配信管理部１３０は、ノード配信状況テーブル１１２ｉに新レコードを追加する。具体的には、新たなノード名とイメージ名との組毎に、ノード配信状況テーブル１１２ｉに新レコードを追加する。
【０１９５】
図２９は、第２の実施の形態のノード追加の具体例を示す図である。例えば、フロアスイッチ１０に、ラックスイッチ２０ｂが新たに接続された場合を考える。ラックスイッチ２０ｂには、コンピュートノード４００，４００ａが接続されている。コンピュートノード４００，４００ａが属するクラスタのクラスタ名は、“クラスタＣ”である。コンピュートノード４００のノード名は、“ノードＣ１”である。コンピュートノード４００ａのノード名は、“ノードＣ２”である。この場合、配信管理部１３０は、次のように各テーブルを更新する。
【０１９６】
図３０は、第２の実施の形態のノード追加後のクラスタ構成例を示す図である。クラスタ構成テーブル１１１ａは、クラスタ構成テーブル１１１に対して、コンピュートノード４００，４００ａが追加された結果を示している。クラスタ構成テーブル１１１ａには、クラスタ名“クラスタＣ”および所属ノード“ノードＣ１”を含むレコードと、クラスタ名“クラスタＣ”および所属ノード“ノードＣ２”を含むレコードとが追加されている。
【０１９７】
図３１は、第２の実施の形態のノード追加後のノード配信状況例を示す図である。ノード配信状況テーブル１１２ｊは、ノード配信状況テーブル１１２ｉに対して、コンピュートノード４００，４００ａが追加された結果を示している。
【０１９８】
ノード配信状況テーブル１１２ｊには、ノード名“ノードＣ１”およびイメージ名“イメージＸ”のレコードと、ノード名“ノードＣ２”およびイメージ名“イメージＸ”のレコードとが追加されている。また、ノード配信状況テーブル１１２ｊには、ノード名“ノードＣ１”およびイメージ名“イメージＹ”のレコードと、ノード名“ノードＣ２”およびイメージ名“イメージＹ”のレコードとが追加されている。
【０１９９】
コンピュートノード４００，４００ａは、追加された時点で、イメージＸ，Ｙの何れも保持していないので、イメージＸ，Ｙに対して、未取得状態として管理される。
図３２は、第２の実施の形態のノード追加後のクラスタ配信状況例を示す図である。クラスタ配信状況テーブル１１３ｊは、クラスタ配信状況テーブル１１３ｄに対して、コンピュートノード４００，４００ａが追加された結果を示している。
【０２００】
クラスタ配信状況テーブル１１３ｊには、クラスタ名“クラスタＣ”およびイメージ名“イメージＸ”のレコードが追加されている。また、クラスタ配信状況テーブル１１３ｊには、クラスタ名“クラスタＣ”およびイメージ名“イメージＹ”のレコードが追加されている。
【０２０１】
クラスタＣは、追加された時点で、クラスタＣに属するコンピュートノード４００，４００ａがイメージＸ，Ｙを保持していないので、イメージＸ，Ｙに対して、未取得状態として管理される。
【０２０２】
次に、配信管理部１３０によるキャッシュ管理の手順を説明する。
図３３は、第２の実施の形態のキャッシュ管理例を示すフローチャートである。以下、図３３に示す処理をステップ番号に沿って説明する。
【０２０３】
（Ｓ６１）配信管理部１３０は、何れかのコンピュートノードからディスク空き容量不足の通知を受信する。
（Ｓ６２）配信管理部１３０は、ノード配信状況テーブル１１２ｊから、該当のコンピュートノードが保有するイメージの一覧を取得する。
【０２０４】
（Ｓ６３）配信管理部１３０は、取得した一覧に含まれる各イメージについて、該当のコンピュートノードが所属するクラスタの保有状況を、クラスタ配信状況テーブル１１３ｊから取得する。
【０２０５】
（Ｓ６４）配信管理部１３０は、ステップＳ６２で取得した一覧に、該当のコンピュートノードが属するクラスタと同一クラスタ内の他のノードが持つイメージが存在するか否かを判定する。存在する場合、処理をステップＳ６５に進める。存在しない場合、処理をステップＳ６６に進める。
【０２０６】
（Ｓ６５）配信管理部１３０は、ステップＳ６２で取得した一覧のうち、同一クラスタ内の他のノードが保持するイメージを１つ選び、該当のコンピュートノードに、選択したイメージの削除を指示する。配信管理部１３０は、削除指示に応じて、ノード配信状況テーブル１１２ｊおよびクラスタ配信状況テーブル１１３ｊを更新する。そして、処理を終了する。
【０２０７】
（Ｓ６６）配信管理部１３０は、ステップＳ６２で取得した一覧のうち、該当のノードが保持するイメージを１つ選び、該当のコンピュートノードに、選択したイメージの削除を指示する。例えば、配信管理部１３０は、一覧に含まれるイメージのうち、使用されていない期間が最も長いイメージを選択することが考えられる。配信管理部１３０は、削除指示に応じて、ノード配信状況テーブル１１２ｊおよびクラスタ配信状況テーブル１１３ｊを更新する。そして、処理を終了する。
【０２０８】
図３４は、第２の実施の形態のイメージ削除後のテーブルの例を示す図である。例えば、配信管理部１３０は、コンピュートノード３００ａからディスク空き容量不足の通知を受信する。配信管理部１３０は、通知を受信すると、ノード配信状況テーブル１１２ｊを参照して、コンピュートノード３００ａが保持するイメージを特定する。ノード配信状況テーブル１１２ｊによれば、コンピュートノード３００ａは、イメージＸ，Ｙを保持している。ここで、ノード配信状況テーブル１１２ｊによれば、コンピュートノード３００ａが属するクラスタＢにおいて、イメージＸはコンピュートノード３００ｂにより保持されている。また、イメージＹはクラスタＢに属する何れのコンピュートノードにも保持されていない。
【０２０９】
配信管理部１３０は、同一クラスタ内に存在するイメージを優先して削除するように、コンピュートノード３００ａの分散配信部に指示する。この場合、配信管理部１３０は、イメージＸの削除を、コンピュートノード３００ａの分散配信部に指示する。
【０２１０】
このとき、配信管理部１３０は、ノード配信状況テーブル１１２ｋで示されるように、イメージＸの配信状況を更新する。具体的には、配信管理部１３０は、コンピュートノード３００ａを、「配信可能」から「未取得」に遷移させる。
【０２１１】
配信管理部１３０は、クラスタ配信状況テーブル１１３ｊを更新しない（図３４では、クラスタ配信状況テーブル１１３ｋとして図示している）。コンピュートノード３００ａからイメージＸを削除しても、コンピュートノード３００ｂによりイメージＸが保持されているからである。なお、この状態から、コンピュートノード３００ｂが保持するイメージＸも削除されると、クラスタＢ内にイメージＸが存在しなくなる。この場合、配信管理部１３０は、クラスタ配信状況テーブル１１３ｋにおけるクラスタＢの状態を、「配信可能」から「未取得」へ遷移させることになる。
【０２１２】
このように、コントローラノード１００は、同一クラスタ内に存在するイメージＸを優先して削除するように、コンピュートノード３００ａに指示する。これにより、仮にコンピュートノード３００ａで再度イメージＸを利用する場合にもクラスタ間の通信なしで、イメージＸをコンピュートノード３００ａに再配信できる。
【０２１３】
次に、イメージの削除も考慮したコンピュートノード２００の分散配信部２２０の処理手順を説明する。
図３５は、第２の実施の形態の分散配信例を示すフローチャートである。以下、図３５に示す処理をステップ番号に沿って説明する。
【０２１４】
（Ｓ７１）分散配信部２２０は、コントローラノード１００からの指示を待つ。
（Ｓ７２）分散配信部２２０は、コントローラノード１００からのイメージの取得指示を受信する。イメージの取得指示は、イメージの配信元ノードの情報を含む。
【０２１５】
（Ｓ７３）分散配信部２２０は、イメージの取得指示により指定されたノードからイメージを取得する。
（Ｓ７４）分散配信部２２０は、イメージの取得が完了すると、コントローラノード１００に、イメージ取得完了を報告する。
【０２１６】
（Ｓ７５）分散配信部２２０は、今回取得したイメージの配信準備を行う。
（Ｓ７６）分散配信部２２０は、イメージの配信準備が完了すると、コントローラノード１００に、イメージ配信準備完了を報告する。
【０２１７】
（Ｓ７７）分散配信部２２０は、ディスク空き容量が十分であるか否かを判定する。ディスク空き容量が十分である場合、処理をステップＳ７１に進める。ディスク空き容量が十分でない場合、処理をステップＳ７８に進める。ここで、分散配信部２２０は、例えば、分散配信部２２０が備えるＨＤＤの空き容量が所定の閾値よりも小さくなった場合に、ディスク空き容量が十分でないと判定することが考えられる。また、当該ＨＤＤの空き容量が所定の閾値以上の場合に、ディスク容量が十分であると判定することが考えられる。
【０２１８】
（Ｓ７８）分散配信部２２０は、コントローラノード１００に空き容量不足を通知し、コントローラノード１００の応答を待つ。
（Ｓ７９）分散配信部２２０は、コントローラノード１００からイメージの削除指示を受信する。分散配信部２２０は、指定されたイメージを削除する。そして、処理をステップＳ７７に進める。
【０２１９】
このように、各コンピュートノードは、イメージの配信を受けるたびに、ディスク空き容量を確認し、空き容量不足を検出するとコントローラノード１００へ空き容量不足を通知して、イメージの削除指示を受け、イメージの削除を行う。これにより、各コンピュートノードでディスク空き容量が枯渇して、インスタンスの動作に悪影響が生じることを防げる。
【０２２０】
ここで、ユーザＵ１は、コントローラノード１００に対して、新たなインスタンスのイメージを追加することもできる。次に、コントローラノード１００に対してイメージＺを追加する例を説明する。
【０２２１】
図３６は、第２の実施の形態のイメージ追加例を示す図である。イメージ配信部１４０は、ユーザＵ１によるイメージＺのアップロードを受け付けると、イメージＺを公開用のディレクトリにコピーする。そして、イメージ配信部１４０は、配信管理部１３０に、イメージＺの登録指示を通知する。配信管理部１３０は、イメージＺの登録指示に応じて、ノード配信状況テーブル１１２ｋを、ノード配信状況テーブル１１２ｌへと更新する。
【０２２２】
具体的には、ノード名とイメージ名“イメージＺ”との組毎に、新たなレコードを作成する。この場合、コントローラノード１００はイメージＺを保持する。各コンピュートノードはイメージＺを保持していない。したがって、配信管理部１３０は、イメージＺに対して、コントローラノード１００を配信可能状態とし、各コンピュートノードを未取得状態とする。
【０２２３】
図３７は、第２の実施の形態のイメージ追加例（続き）を示す図である。更に、配信管理部１３０は、クラスタ配信状況テーブル１１３ｋを、クラスタ配信状況テーブル１１３ｌへと更新する。
【０２２４】
具体的には、クラスタ名とイメージ名“イメージＺ”との組毎に、新たなレコードを作成する。この場合、クラスタＡに属するコントローラノード１００はイメージＺを保持する。クラスタＢに属する各コンピュートノードはイメージＺを保持していない。したがって、配信管理部１３０は、イメージＺに対して、クラスタＡを配信可能状態とし、クラスタＢを未取得状態とする。
【０２２５】
こうして、コントローラノード１００は、新たなイメージＺの配信を行えるようになる。イメージＺについても、当初はコントローラノード１００に存在するのみであるが、クラスタ間での配信後に、同一クラスタ内のノード間での配信を行う。コントローラノード１００は、クラスタ間での通信量を抑えてイメージＺの配信を行える。また、イメージＺを各クラスタに配信した後は、各クラスタ内で、イメージＺを並列に分散配信できるので、イメージＺの配信を高速化できる。
【０２２６】
［第３の実施の形態］
以下、第３の実施の形態を説明する。前述の第２の実施の形態と相違する事項を主に説明し、共通する事項の説明を省略する。
【０２２７】
第２の実施の形態では、フロアスイッチ（１つ目の階層）、ラックスイッチ（２つ目の階層）およびノード（３つ目の階層）という３つの階層を例示したが、より上位に更に多段に集約スイッチを設けた４つ以上の階層でもよい。第３の実施の形態では、一例として、４つの階層を持つシステムを例示する。
【０２２８】
図３８は、第３の実施の形態の情報処理システムの例を示す図である。第３の実施の形態の情報処理システムは、コアスイッチ３０、アグリゲーションスイッチ４０，４０ａ、ラックスイッチ５０，５０ａ，５０ｂ、コントローラノード１００およびコンピュートノード２００，２００ａ，３００，４００，４００ａを有する。
【０２２９】
コアスイッチ３０、アグリゲーションスイッチ４０，４０ａおよびラックスイッチ５０，５０ａ，５０ｂは、Ｌ２スイッチである。コアスイッチ３０は、データセンタのセンタ単位の集約スイッチである。アグリゲーションスイッチ４０，４０ａは、フロア単位の集約スイッチである。ラックスイッチ５０，５０ａ，５０ｂは、ラック単位の集約スイッチである。アグリゲーションスイッチ４０，４０ａは、所定のケーブルを用いてコアスイッチ３０に接続されている。ラックスイッチ５０，５０ａは、所定のケーブルを用いてアグリゲーションスイッチ４０に接続されている。ラックスイッチ５０ｂは、所定のケーブルを用いてアグリゲーションスイッチ４０ａに接続されている。コアスイッチ３０、アグリゲーションスイッチ４０，４０ａおよびラックスイッチ５０，５０ａ，５０ｂは、Ｌ２ネットワークを形成している。
【０２３０】
コントローラノード１００およびコンピュートノード２００，２００ａは、所定のケーブルを用いてラックスイッチ５０に接続されている。コンピュートノード３００は、所定のケーブルを用いてラックスイッチ５０ａに接続されている。コンピュートノード４００，４００ａは、所定のケーブルを用いてラックスイッチ５０ｂに接続されている。ここで、以下では、コンピュートノード２００，２００ａ，３００，４００，４００ａそれぞれを指して、各コンピュートノードと称することがある。コントローラノード１００およびコンピュートノード２００，２００ａ，３００，４００，４００ａそれぞれを指して、各ノードと称することがある。
【０２３１】
コントローラノード１００およびコンピュートノード２００，２００ａ，３００，４００，４００ａは、第２の実施の形態で示した各ノードと同様のサーバコンピュータである。このように、第３の実施の形態では、コアスイッチ（１つ目の階層）、アグリゲーションスイッチ（２つ目の階層）、ラックスイッチ（３つ目の階層）およびノード（４つ目の階層）という４つの階層を備えるシステムを考える。
【０２３２】
図３９は、第３の実施の形態のサブネット分割の例を示す図である。図３８で例示した各階層に対して、最上位の階層（コアスイッチ３０の階層）からの深さ（ｄｅｐｔｈ）を考えることができる。具体的には、アグリゲーションスイッチ４０，４０ａの階層の深さは“１”（ｄｅｐｔｈ＝１）である。ラックスイッチ５０，５０ａ，５０ｂの階層の深さは“２”（ｄｅｐｔｈ＝２）である。各ノードの階層の深さは“３”（ｄｅｐｔｈ＝３）である。
【０２３３】
この場合、コアスイッチ３０配下のネットワークを「サブネット」と呼ばれる単位に分割することができる。サブネットは、ネットワークスイッチとノードとの部分木によって構成されるクラスタであるということができる。なお、ここでは「サブネット」を、Ｌ２ネットワークの物理的な一部分を表す用語として用いている。すなわち、ここでいう「サブネット」は、レイヤ３においてＩＰ（Internet Protocol）ネットワークのアドレス空間を論理的に分割する手法とは異なる。
【０２３４】
例えば、各階層に属するスイッチおよびノード毎にサブネットが定められる。サブネット内における根であるスイッチをルートスイッチと呼ぶ。より具体的には、コアスイッチ３０配下のネットワークは第１サブネットである。第１サブネットのルートスイッチは、コアスイッチ３０である。第１サブネットには、アグリゲーションスイッチ４０，４０ａ、ラックスイッチ５０，５０ａ，５０ｂ、コントローラノード１００およびコンピュートノード２００，２００ａが属する。
【０２３５】
アグリゲーションスイッチ４０配下のネットワークは第２サブネットである。第２サブネットのルートスイッチは、アグリゲーションスイッチ４０である。第２サブネットには、ラックスイッチ５０，５０ａ、コントローラノード１００およびコンピュートノード２００，２００ａ，３００が属する。
【０２３６】
アグリゲーションスイッチ４０ａ配下のネットワークは第３サブネットである。第３サブネットのルートスイッチは、アグリゲーションスイッチ４０ａである。第３サブネットには、ラックスイッチ５０ｂおよびコンピュートノード４００，４００ａが属する。
【０２３７】
ラックスイッチ５０配下のネットワークは第４サブネットである。第４サブネットのルートスイッチは、ラックスイッチ５０である。第４サブネットには、コントローラノード１００およびコンピュートノード２００，２００ａが属する。
【０２３８】
ラックスイッチ５０ａ配下のネットワークは第５サブネットである。第５サブネットのルートスイッチは、ラックスイッチ５０ａである。第５サブネットには、コンピュートノード３００が属する。
【０２３９】
ラックスイッチ５０ｂ配下のネットワークは第６サブネットである。第６サブネットのルートスイッチは、ラックスイッチ５０ｂである。第６サブネットには、コンピュートノード４００，４００ａが属する。ラックスイッチ５０，５０ａ，５０ｂに接続された各ノードも、サブネット（１つのノードのみのサブネット）を形成する。
【０２４０】
ここで、２つのサブネットのルートスイッチが親子関係にある場合、当該２つのサブネット同士も親子関係にある。例えば、第２サブネットおよび第４サブネットは親子関係にある。第２サブネットは、第４サブネットの親サブネットである。第４サブネットは、第２サブネットの子サブネットである。この場合、第２サブネットのルートスイッチであるアグリゲーションスイッチ４０および第４サブネットのルートスイッチであるラックスイッチ５０は親子関係にある。
【０２４１】
図４０は、第３の実施の形態のスイッチ／ノードの識別情報の例を示す図である。第３の実施の形態では、各スイッチおよび各ノードに対して、所属するサブネットが分かるように名前（識別情報）を付与する。具体的には、サブネットのルートスイッチに対しては、親サブネットのルートスイッチ名の末尾に追記する（ピリオド記号“．”で区切って後続させる）形式で、当該ルートスイッチの名前を設定する。各ノードには、該当のノードが接続されているスイッチ名に追記する（ピリオド記号“．”で区切って後続させる）形式で、該当のノードの名前を設定する。なお、このような形式で名前を付与すると、ＦＱＤＮ（Fully Qualified Domain Name）のような形で識別情報が設定されることになるが、ＦＱＤＮとは別のものである。
【０２４２】
例えば、コアスイッチ３０の名前を“沼津”とする。ここで、“沼津”はデータセンタの所在地の名称である。アグリゲーションスイッチ４０の名前を“沼津．３Ｆ”とする。“３Ｆ”は、データセンタの第３フロアを示す名称である。アグリゲーションスイッチ４０ａの名前を“沼津．４Ｆ”とする。“４Ｆ”は、データセンタの第４フロアを示す名称である。
【０２４３】
ラックスイッチ５０の名称を“沼津．３Ｆ．Ａ１”とする。“Ａ１”は、第３フロアに設置された１つ目のラックの識別名である。ラックスイッチ５０ａの名称を“沼津．３Ｆ．Ａ２”とする。“Ａ２”は、第３フロアに設置された２つ目のラックの識別名である。ラックスイッチ５０ｂの名称を“沼津．４Ｆ．Ｄ１”とする。“Ｄ１”は、第４フロアに設置された１つ目のラックの識別名である。
【０２４４】
コントローラノード１００の名称を“沼津．３Ｆ．Ａ１．クラウドコントローラ”とする。コンピュートノード２００の名称を“沼津．３Ｆ．Ａ１．コンピュート１”とする。コンピュートノード２００ａの名称を“沼津．３Ｆ．Ａ１．コンピュート２”とする。コンピュートノード３００の名称を“沼津．３Ｆ．Ａ２．コンピュート１”とする。コンピュートノード４００の名称を“沼津．４Ｆ．Ｄ１．コンピュート１”とする。コンピュートノード４００ａの名称を“沼津．４Ｆ．Ｄ１．コンピュート２”とする。
【０２４５】
このような方式で名前を付けることで、コントローラノード１００は、ユーザによりノード名が入力されると、当該ノード名からネットワークのサブネット構造やスイッチの名称を識別できる。なお、１つのサブネットを１つのクラスタに対応付けることもできる。コントローラノード１００は、図４０で例示したスイッチ／ノードの識別情報からサブネット構造（すなわち、クラスタ構造）を把握できるため、当該識別情報をクラスタ構成情報と呼ぶこともできる。
【０２４６】
ここで、第３の実施の形態では、初期状態として、コントローラノード１００がイメージＸ，Ｙを保持し、コンピュートノード４００がイメージＹを保持しているものとする。
上記で例示したスイッチ／ノードの識別情報は、ユーザにより作成されて、記憶部１１０に予め格納される。
【０２４７】
図４１は、第３の実施の形態のノード配信状況テーブルの例を示す図である。記憶部１１０は、第２の実施の形態で例示したノード配信状況テーブル１１２に代えて、ノード配信状況テーブル１１２ｍを記憶する。
【０２４８】
ノード配信状況テーブル１１２ｍは、ノード名、イメージ名、未取得、要求中、取得中、取得完了、配信可能および配信中の項目を含む。イメージ名、未取得、要求中、取得中、取得完了、配信可能および配信中の項目に登録される情報は、ノード配信状況テーブル１１２で説明した同名の項目に登録される情報と同様である。
【０２４９】
ただし、ノード配信状況テーブル１１２ｍでは、ノード名の項目に登録される情報が、ノード配信状況テーブル１１２と異なる。ノード配信状況テーブル１１２ｍでは、ノード名の項目には、図４０で例示した形式で各ノードの名称（識別情報）が登録される。
【０２５０】
例えば、ノード配信状況テーブル１１２ｍには、ノード名が“沼津．３Ｆ．Ａ１．クラウドコントローラ”、イメージ名が“イメージＸ”、未取得が“０”、要求中が“０”、取得中が“０”、取得完了が“０”、配信可能が“１”、配信中が“０”という情報が登録される。これは、ノード名“沼津．３Ｆ．Ａ１．クラウドコントローラ”で示されるコントローラノード１００が、イメージＸを保持しており、当該イメージＸについて配信可能状態であることを示す。
【０２５１】
ノード配信状況テーブル１１２ｍには、他のノードおよびイメージについても同様に各項目に情報が登録される。
第３の実施の形態では、ノード配信状況テーブル１１２ｍによりクラスタ（サブネット）単位のイメージ配信状況を管理できるため、コントローラノード１００は、クラスタ構成テーブル１１１およびクラスタ配信状況テーブル１１３を保持していなくてよい。
【０２５２】
次に、第３の実施の形態のコントローラノード１００の処理手順を説明する。第３の実施の形態でも、コントローラノード１００は、図１６で例示した手順により、インスタンスのデプロイを実行する。ただし、第３の実施の形態では、図１６のステップＳ１２，Ｓ１６の手順が第２の実施の形態の手順と異なる。
【０２５３】
まず、コントローラノード１００によるノード間の距離の計算手順を説明する。第３の実施の形態では、コントローラノード１００は、ノード間の通信経路においてＬ２レベルで経由するホップ数により距離を計算し、距離スコアを求める。
【０２５４】
図４２は、第３の実施の形態の距離計算例を示すフローチャートである。以下、図４２に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１６のステップＳ１２１に相当する。
【０２５５】
（Ｓ８１）配信管理部１３０は、イメージの配信先のノードの候補から１つのノード（ノードＮとする）を選択する。
（Ｓ８２）配信管理部１３０は、記憶部１１０に記憶されたノード配信状況テーブル１１２ｍから配信対象のイメージを持つノードを抽出する。
【０２５６】
（Ｓ８３）配信管理部１３０は、ノード配信状況テーブル１１２ｍを参照して、抽出した各ノードについて、ノードＮまでの距離を計算する。具体的には、配信管理部１３０は、配信対象のイメージを持つノードとノードＮとの通信経路上のスイッチを介したホップ数（スイッチの経由数ともいえる）を、配信対象のイメージを持つノード毎にカウントし、ノードＮからイメージまでの距離とする。例えば、２つのノードの間に１つのスイッチが介在する場合、両ノードの通信経路上のホップ数は２である。また、２つのノードの間に２つのスイッチが介在する場合、両ノードの通信経路上のホップ数は３である。このように、２つのノードの間にｎ個（ｎは正の整数）のスイッチが介在する場合、両ノードの通信経路上のホップ数はｎ＋１である。なお、後述するように、配信管理部１３０は、両ノードのノード名からホップ数（距離）を計算することができる。
【０２５７】
（Ｓ８４）配信管理部１３０は、計算した距離の最小値をノードＮのイメージまでの距離と決定する。具体的には、ステップＳ８３において、配信対象のイメージを持つ複数のノードそれぞれと、ノードＮとの間の複数の距離（１つのこともある）が計算されることになる。配信管理部１３０は、そのうちの最小値を、ノードＮから、該当のイメージ（あるいは、該当のイメージを持つノード）までの距離と決定する。
【０２５８】
（Ｓ８５）配信管理部１３０は、配信先候補の全てのコンピュートノードを処理済としたか（全てのコンピュートノードに対して距離を計算したか）否かを判定する。配信先候補の全てのコンピュートノードを処理済の場合、処理を終了する。配信先候補の全てのコンピュートノードを処理済でない場合、処理をステップＳ８１に進める。ステップＳ８１では、配信管理部１３０は、未処理のコンピュートノードの中から新たにノードＮを選択することになる。
【０２５９】
ここで、ステップＳ８３における距離の計算方法の具体例を説明する。一例として、コンピュートノード２００（ノード名“沼津．３Ｆ．Ａ１．コンピュート１”）とコンピュートノード３００（ノード名“沼津．３Ｆ．Ａ２．コンピュート１”）との間の距離計算方法を挙げる。
【０２６０】
（１）まず、配信管理部１３０は、両ノードの名前を比較し、共通部分と異なる部分に分離する。上記の例の場合、共通部分は“沼津．３Ｆ”である。異なる部分は、“Ａ１．コンピュート１”と“Ａ２．コンピュート２”である。
【０２６１】
（２）配信管理部１３０は、異なる部分の長さ（Ｌ２レベルでのスイッチを介したホップ数に相当）を計算する。ここで、異なる部分の長さは、区切り文字であるピリオド記号による分割数である（ピリオド記号が１つであれば分割数は２、ピリオド記号が２つであれば分割数は３など）。この例では、“Ａ１．コンピュート１”は長さ“２”である。“Ａ２．コンピュート２”は長さ“２”である。
【０２６２】
（３）配信管理部１３０は、異なる部分の長さの和を距離とする。この場合、配信管理部１３０は、コンピュートノード２００，３００の距離を、２＋２＝４と計算する。
図４３は、第３の実施の形態の距離情報の例を示す図である。距離情報１１４ａは、各コンピュートノードからイメージＸまでの距離の計算結果を記録した情報である。距離情報１１４ａは、図４２の手順により配信管理部１３０により作成され、記憶部１１０に格納される。
【０２６３】
具体的には、コンピュートノード２００からイメージＸまでの距離は“２”である。
コンピュートノード２００ａからイメージＸまでの距離は“２”である。コンピュートノード３００からイメージＸまでの距離は“４”である。コンピュートノード４００からイメージＸまでの距離は“６”である。コンピュートノード４００ａからイメージＸまでの距離は“６”である。
【０２６４】
図４４は、第３の実施の形態のスコア計算の具体例を示す図である。ＣＴＲ１２０は、各コンピュートノードの負荷情報と、配信管理部１３０から取得した各コンピュートノードのイメージからの距離とを、記憶部１１０に記憶されたノード管理テーブル１１６ａに記録する。ＣＴＲ１２０は、ノード管理テーブル１１６ａに基づいて、インスタンスを起動するコンピュートノードを決定する。
【０２６５】
ここで、以下に示す具体例では、デプロイ指示において、イメージＸにより起動されるインスタンスが指定され、インスタンスの配備数“４”が指定されているものとする。
ノード管理テーブル１１６ａでは、イメージＸを新たに配信する場合の距離を例示している。図４２の手順によれば、コンピュートノード２００，２００ａのイメージＸからの距離は“２”である。コンピュートノード３００のイメージＸからの距離は“４”である。コンピュートノード４００，４００ａのイメージＸからの距離は“６”である。
【０２６６】
ＣＴＲ１２０は、ノード管理テーブル１１６ａに記録されたメモリ空き容量、ディスク入出力およびイメージからの距離といった各指標の値を所定の演算によって正規化した値（スコア）を求め、スコアテーブル１１７ａを生成する。ＣＴＲ１２０は、重みテーブル１１５に設定された重みを用いて、スコアテーブル１１７ａの各スコアを重み付けした上で加算し、最終的なスコア（最終スコア）の計算結果を得る。具体的な計算方法は、図１８で例示した方法と同様である。
【０２６７】
最終スコアテーブル１１８ａの例では、順位の優先順に、ノード名“沼津．３Ｆ．Ａ１．コンピュート２”、“沼津．４Ｆ．Ｄ１．コンピュート１”、“沼津．４Ｆ．Ｄ１．コンピュート２”、“沼津．３Ｆ．Ａ１．コンピュート１”それぞれに対応するコンピュートノードが選択される。すなわち、ＣＴＲ１２０は、コンピュートノード２００ａ，４００，４００ａ，２００を、インスタンスの配備先（イメージの配信先）として選択する。
【０２６８】
なお、図４４の例では、ＣＴＲ１２０が各コンピュートノードから取得する負荷情報として、メモリ空き容量やディスク入出力の負荷を取得するものとしたが、評価の対象とする負荷の指標は任意に決定することができる。例えば、前述のように、負荷の指標としてプロセッサ使用率を更に加味して、最終スコアを求めてもよい。
【０２６９】
図４５は、第３の実施の形態のノード配信状況の例（配信開始時）を示す図である。図４５では、図１６のステップＳ１５の具体例を示している。ＣＴＲ１２０は、イメージＸの配信先として決定したコンピュートノード２００，２００ａ，４００，４００ａを、配信指示実行要求により、配信管理部１３０に通知する。
【０２７０】
配信管理部１３０は、配信指示実行要求に応じて、ノード配信状況テーブル１１２ｍを更新し、イメージＸについて未取得状態であるコンピュートノード２００，２００ａ，４００，４００ａを、要求中状態に遷移させる。図４５では、当該遷移直後のノード配信状況テーブル１１２ｎを例示している。ただし、ノード配信状況テーブル１１２ｎでは、イメージＹに関するレコードの図示を省略している。
【０２７１】
こうして、配信先として決定されたコンピュートノードに対してイメージの配信指示を行う準備が整う。次に、配信管理部１３０による配信制御の手順を説明する。ここで、配信管理部１３０は、複数のスレッドにより、下記の図４６，図４７それぞれの手順を並行して実行する。
【０２７２】
図４６は、第３の実施の形態の配信管理例を示すフローチャートである。以下、図４６に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１６のステップＳ１６に相当する。
【０２７３】
（Ｓ９１）配信管理部１３０は、データセンタ全体のサブネット（サブネットの名称）を記憶部１１０に格納されたキューに登録する。データセンタ全体のサブネットとは、図３９で例示したコアスイッチ３０配下のサブネット（第１サブネット）である。サブネットの名称は、該当のサブネットのルートスイッチの名称と同じである。第１サブネットの名称は“沼津”である。
【０２７４】
（Ｓ９２）配信管理部１３０は、配信対象のイメージの配信が全て完了したか否かを判定する。全て完了した場合、処理をステップＳ９３に進める。全て完了していない場合、処理をステップＳ９２に進める（配信完了を待機する）。
【０２７５】
（Ｓ９３）配信管理部１３０は、各コンピュートノードにイメージの配信完了を通知する。
図４７は、第３の実施の形態の配信指示例を示すフローチャートである。以下、図４７に示す処理をステップ番号に沿って説明する。配信管理部１３０は、図４６の手順を実行するスレッドとは異なるスレッドにより、下記の手順を図４６の手順と並行して実行する。
【０２７６】
（Ｓ１０１）配信管理部１３０は、記憶部１１０に格納されたキューからサブネット（Ｐ）を取得する。
（Ｓ１０２）配信管理部１３０は、ノード配信状況テーブル１１２ｎを参照し、サブネット（Ｐ）に含まれる要求中ノード（配信対象のイメージについて要求中状態であるコンピュートノード）を抽出する。
【０２７７】
（Ｓ１０３）配信管理部１３０は、ノード配信状況テーブル１１２ｎを参照して、抽出した要求中ノードが所属する、サブネット（Ｐ）の直下の子サブネット（要求中サブネット）を確認する。
【０２７８】
（Ｓ１０４）配信管理部１３０は、ノード配信状況テーブル１１２ｎを参照して、サブネット（Ｐ）に含まれるイメージ（配信対象のイメージ）を持つコンピュートノードを抽出する。ここで、「イメージを持つ」とは、該当のイメージについて、取得完了、配信可能または配信中の状態であることを意味する。
【０２７９】
（Ｓ１０５）配信管理部１３０は、ステップＳ１０３で確認した要求中サブネットのうち、配信対象のイメージを持つコンピュートノードを含まない要求中サブネット（Ｃ）があるか否かを判定する。配信対象のイメージを持つコンピュートノードを含まない要求中サブネット（Ｃ）がある場合、処理をステップＳ１０６に進める。配信対象のイメージを持つコンピュートノードを含まない要求中サブネット（Ｃ）がない場合、処理をステップＳ１１０に進める。
【０２８０】
（Ｓ１０６）配信管理部１３０は、サブネット（Ｐ）内に配信可能ノード（配信対象のイメージについて配信可能状態であるコントローラノードまたはコンピュートノード）があるか否かを判定する。サブネット（Ｐ）内に配信可能ノードがある場合、処理をステップＳ１０７に進める。サブネット（Ｐ）内に配信可能ノードがない場合、処理をステップＳ１０６に進める（配信可能ノードが生じるまで待機する）。
【０２８１】
（Ｓ１０７）配信管理部１３０は、サブネット（Ｃ）内で要求中ノードを選択する。
（Ｓ１０８）配信管理部１３０は、サブネット（Ｐ）内で配信可能ノードを選択する。
（Ｓ１０９）配信管理部１３０は、ステップＳ１０８で選択した配信可能ノードから、ステップＳ１０７で選択した要求中ノードへイメージを配信させる。具体的には、配信管理部１３０は、選択した配信可能ノードから該当のイメージを取得するように、選択した要求中ノードに、イメージ取得指示を送信する。イメージ取得指示を受信した要求中ノードは、指定された配信可能ノードからイメージを取得する。ここで、配信管理部１３０は、配信状況の変更に伴って、ノード配信状況テーブル１１２ｎにおける要求中ノードの状態を「要求中」から「取得中」へ、「取得中」から「取得完了」へ、「取得完了」から「配信可能」へと遷移させる。そして、処理をステップＳ１０５に進める。
【０２８２】
（Ｓ１１０）配信管理部１３０は、ノード配信状況テーブル１１２ｎを参照して、サブネット（Ｐ）に要求中ノードが残っているか否かを判定する。サブネット（Ｐ）に要求中ノードが残っている場合、処理をステップＳ１１１に進める。サブネット（Ｐ）に要求中ノードが残っていない場合、処理をステップＳ１１２に進める。
【０２８３】
（Ｓ１１１）配信管理部１３０は、サブネット（Ｐ）直下の子サブネットのうち、要求中ノードの所属先の子サブネットを、記憶部１１０に格納されたキューに登録する。そして、処理をステップＳ１０１に進める。
【０２８４】
（Ｓ１１２）配信管理部１３０は、通知待ちプロセス（図４６のステップＳ９２の配信確認に相当）に該当のサブネットについての配信完了を通知する。そして、処理をステップＳ１０１に進める。
【０２８５】
このように、配信管理部１３０は、データセンタ全体のルートスイッチ（コアスイッチ３０）から処理を開始、直下の子サブネット間（ｄｅｐｔｈ＝１の子サブネット間）でイメージを共有させる。次に、イメージを共有させたそれぞれの子サブネットで同じ処理を実行し、当該子サブネットの直下の子（コアスイッチ３０から見ると孫）サブネット間（ｄｅｐｔｈ＝２の子サブネット間）でイメージを共有させる。以後、サブネット毎に、順次処理を実行していく（ｄｅｐｔｈ＝３，４，・・・）。
【０２８６】
すなわち、配信管理部１３０は、複数のスイッチによる木構造の接続関係を示す情報に基づいて、木構造のルートに対応するスイッチ（コアスイッチ３０）から１つずつ深さ方向にスイッチを辿る。配信管理部１３０は、１つ深さを増す毎に、同じ深さにある複数のスイッチそれぞれをルートとした複数の部分木のうち、配信対象のイメージを保持するノードを含まない部分木毎に配備先ノードを１つずつ選択する。そして、配信管理部１３０は、選択した各配備先ノードに該当のイメージを送信するように配信先ノードのイメージ取得を制御する。
【０２８７】
なお、図４７に示す手順において、配信管理部１３０は、配信対象のイメージを持つノードが含まれない要求中サブネット（Ｃ）の数とサブネット（Ｐ）内の配信可能ノードの数を管理する。配信管理部１３０は、（要求中サブネットの数）＜（配信可能ノードの数）となった時点で、サブネット（Ｐ）直下で、新しく配信可能となったノードと要求中ノードとを両方含むサブネットをキューに登録できる。これによって、サブネット単位に配信指示処理の並列を図れ、配信処理を高速化できる。
【０２８８】
次に、図４６，図４７の処理の具体例を説明する。
図４８は、第３の実施の形態のキューの例（その１）を示す図である。配信管理部１３０は、記憶部１１０に格納されたキューにより、図４７の手順を制御する。まず、配信管理部１３０は、データセンタ全体のサブネットをキューｑ１に追加する。
【０２８９】
データセンタ全体のサブネット名は“沼津”である。このため、配信管理部１３０は、“沼津”を各括弧記号で括った“［沼津］”という情報をキューｑ１に登録する。ここで、以下の説明では、サブネット名“沼津”のサブネットを指して、サブネット［沼津］のように表記する。また、図面の中のキューの表記において、左側に記載された情報ほど処理の優先順が高く、右側に記載された情報ほど処理の優先順が低い。
【０２９０】
配信管理部１３０は、キューｑ１に基づいて、サブネット［沼津］に関し、図４７の手順を実行する。配信管理部１３０は、キューｑ１から“［沼津］”の情報を抽出すると、キューｑ１の“［沼津］”の情報を削除する。キューｑ２は、当該削除後のキューの状態（空の状態）を示している。
【０２９１】
配信管理部１３０は、ノード配信状況テーブル１１２ｎを参照して、サブネット［沼津］に含まれる要求中ノードを抽出する。抽出される要求中ノードは、コンピュートノード２００，２００ａ，４００，４００ａである。
【０２９２】
次に、配信管理部１３０は、ノード配信状況テーブル１１２ｎを参照して、抽出した要求中ノードのノード名を基に、サブネット［沼津］直下の要求中ノードが含まれるサブネット（要求中サブネット）を確認する。ここでは、要求中サブネットは、サブネット［沼津．３Ｆ］およびサブネット［沼津．４Ｆ］である。
【０２９３】
次に、配信管理部１３０は、ノード配信状況テーブル１１２ｎを参照して、配信対象であるイメージＸを持つノードを抽出する。ここでは、イメージＸを持つノードは、コントローラノード１００である。
【０２９４】
更に、配信管理部１３０は、全ての要求中サブネットについて、イメージを持つノードが含まれないサブネットを確認する。ここでは、サブネット［沼津．３Ｆ］は、イメージＸを持つノード（具体的には、コントローラノード１００）を含む。一方、サブネット［沼津．４Ｆ］は、イメージＸを持つノードを含まない。
【０２９５】
この場合、サブネット“［沼津．４Ｆ］”には、イメージＸが未配信であるため、配信管理部１３０は、イメージＸの配信を行うと決定する。配信管理部１３０は、サブネット［沼津．３Ｆ］から配信可能ノード（コントローラノード１００）を選択し、サブネット［沼津．４Ｆ］から要求中ノード（例えば、コンピュートノード４００）を選択し、配信可能ノードによる配信を実行させる。その際、配信管理部１３０は、ノード配信状況テーブル１１２ｎを更新する。
【０２９６】
図４９は、第３の実施の形態のノード配信状況の更新例を示す図である。配信管理部１３０は、ノード配信状況テーブル１１２ｏで示されるように、コントローラノード１００を「配信可能」から「配信中」へ遷移させる。配信管理部１３０は、コンピュートノード４００を「要求中」から「取得中」へ遷移させる。
【０２９７】
配信管理部１３０は、配信が完了した旨の通知をコンピュートノード４００から受け付けるとノード配信状況テーブル１１２ｐで示されるように配信状況を更新する。具体的には、配信管理部１３０は、コントローラノード１００を「配信中」から「配信可能」へ遷移させる。配信管理部１３０は、コンピュートノード４００を「取得中」から「取得完了」へ遷移させる。
【０２９８】
図５０は、第３の実施の形態のノード配信状況の更新例（続き）を示す図である。その後、配信管理部１３０は、コンピュートノード４００から配信準備完了報告を受信すると、ノード配信状況テーブル１１２ｑで示されるように、配信状況を更新する。具体的には、配信管理部１３０は、コンピュートノード４００を「取得完了」から「配信可能」へ遷移させる。こうして、サブネット［沼津］直下の全ての要求中サブネットが、イメージＸを持つノードを含むようになる。すなわち、この段階において、サブネット［沼津．３Ｆ］およびサブネット［沼津．４Ｆ］の両方が、イメージＸを持つノードを含む。
【０２９９】
図５１は、第３の実施の形態のキューの例（その２）を示す図である。配信管理部１３０は、サブネット［沼津］直下の子サブネットであるサブネット［沼津．３Ｆ］およびサブネット［沼津．４Ｆ］に要求中ノードが残っているため、これらのサブネット名“［沼津．３Ｆ］”および“［沼津．４Ｆ］”をキューに追加する。キューｑ３は、当該追加後のキューを例示している。
【０３００】
配信管理部１３０は、キューｑ３からサブネット名“［沼津．３Ｆ］”を抽出する。キューｑ４は、当該抽出後のキューを例示している。配信管理部１３０は、ノード配信状況テーブル１１２ｑを参照して、取得したサブネット［沼津．３Ｆ］に含まれる要求中ノードを抽出する。ここでは、要求中ノードは、コンピュートノード２００，２００ａである。
【０３０１】
次に、配信管理部１３０は、要求中ノードのノード名を基に、取得したサブネット［沼津．３Ｆ］直下の要求中ノードが含まれるサブネット（要求中サブネット）を確認する。ここでは、要求中サブネットは、サブネット［沼津．３Ｆ．Ａ１］である。
【０３０２】
配信管理部１３０は、ノード配信状況テーブル１１２ｑを参照して、イメージＸを持つノードを抽出する。ここでは、イメージＸを持つノードは、コントローラノード１００である。
【０３０３】
配信管理部１３０は、全ての要求中サブネットについて、イメージＸを持つノードが含まれないサブネットを確認する。ここでは、要求中サブネットであるサブネット［沼津．３Ｆ．Ａ１］は、イメージＸを持つノード（具体的には、コントローラノード１００）を含む。
【０３０４】
次に、配信管理部１３０は、ノード配信状況テーブル１１２ｑを参照して、サブネット［沼津．３Ｆ］に要求中ノードが残っているかを確認する。ここでは、サブネット［沼津．３Ｆ．Ａ１］に要求中ノードが残っている。このため、配信管理部１３０は、サブネット名“［沼津．３Ｆ．Ａ１］”をキューに追加する。キューｑ５は、当該追加後のキューを例示している。
【０３０５】
配信管理部１３０は、キューｑ５からサブネット名“［沼津．４Ｆ］”を抽出し、サブネット［沼津．４Ｆ］について、サブネット［沼津．３Ｆ］と同様に処理する。キューｑ６は、サブネット名“［沼津．４Ｆ］”が抽出された後のキューを例示している。また、配信管理部１３０は、サブネット［沼津．４Ｆ］に対する処理に応じて、キューｑ６にサブネット名“［沼津．４Ｆ．Ｄ１］”を追加する。キューｑ７は、当該追加後のキューを例示している。
【０３０６】
配信管理部１３０は、キューｑ７からサブネット名“［沼津．３Ｆ．Ａ１］”を抽出する。キューｑ８は、サブネット名“［沼津．３Ｆ．Ａ１］”が抽出された後のキューを例示している。
【０３０７】
配信管理部１３０は、ノード配信状況テーブル１１２ｑを参照して、サブネット［沼津．３Ｆ．Ａ１］に含まれる要求中ノードを抽出する。ここでは、要求中ノードは、コンピュートノード２００，２００ａである。
【０３０８】
次に、配信管理部１３０は、ノード配信状況テーブル１１２ｑを参照して、サブネット［沼津．３Ｆ．Ａ１］直下の要求中ノードが含まれるサブネット（要求中サブネット）を確認する。ここでは、要求中サブネットは、サブネット［沼津．３Ｆ．Ａ１．コンピュート１］およびサブネット［沼津．３Ｆ．Ａ１．コンピュート２］である。この場合、サブネット名はノード名と一致する。具体的には、サブネット［沼津．３Ｆ．Ａ１．コンピュート１］には、当該サブネットと同名のコンピュートノード２００が１つだけ含まれる。また、サブネット［沼津．３Ｆ．Ａ１．コンピュート２］には、当該サブネットと同名のコンピュートノード２００ａが１つだけ含まれる。ここで、配信管理部１３０は、前述のように、スイッチとノードとをネットワークの木構造の１つの節として平等に扱い、ノードが１つしか含まれないサブネットであっても、１つのサブネットとして管理する。
【０３０９】
配信管理部１３０は、ノード配信状況テーブル１１２ｑに基づいて、イメージＸを持つノードを抽出する。ここでは、イメージＸを持つノードは、コントローラノード１００である。
【０３１０】
配信管理部１３０は、全ての要求中サブネットについて、イメージＸを持つノードが含まれないサブネットを確認する。ここでは、サブネット［沼津．３Ｆ．Ａ１．コンピュート１］およびサブネット［沼津．３Ｆ．Ａ１．コンピュート２］の両方ともイメージＸを持つノードを含まない。
【０３１１】
この場合、サブネット［沼津．３Ｆ．Ａ１．コンピュート１］にはイメージＸが配信されていないため、配信管理部１３０は、サブネット［沼津．３Ｆ．Ａ１．コンピュート１］に対してイメージＸの配信を行うと決定する。配信管理部１３０は、サブネット［沼津．３Ｆ．Ａ１．クラウドコントローラ］から配信可能ノード（具体的には、コントローラノード１００）を、サブネット［沼津．３Ｆ．Ａ１．コンピュート１］から要求中ノード（具体的には、コンピュートノード２００）を選択する。そして、配信管理部１３０は、選択した配信可能ノード（コントローラノード１００）によるイメージＸの配信を実行させる。
【０３１２】
図５２は、第３の実施の形態のノード配信状況の更新例（続き）を示す図である。このとき、配信管理部１３０は、ノード配信状況テーブル１１２ｒで示されるように配信状況を更新する。具体的には、配信管理部１３０は、コントローラノード１００を、「配信可能」から「配信中」へ遷移させる。配信管理部１３０は、コンピュートノード２００を、「要求中」から「取得中」へ遷移させる。
【０３１３】
なお、サブネット［沼津．３Ｆ．Ａ１．コンピュート２］にも要求中ノード（コンピュートノード２００ａ）があるが、コントローラノード１００が現在配信中であるため、配信指示処理は待たされることになる。
【０３１４】
ここで、配信管理部１３０は、別スレッドにより、キューｑ８からサブネット名“［沼津．４Ｆ．Ｄ１］”を取得する。配信管理部１３０は、ノード配信状況テーブル１１２ｒを参照して、取得したサブネット［沼津．４Ｆ．Ｄ１］に含まれる要求中ノードを抽出する。ここでは、要求中ノードは、コンピュートノード４００ａである。
【０３１５】
次に、配信管理部１３０は、要求中ノードのノード名を基に、取得したサブネット［沼津．４Ｆ．Ｄ１］直下の要求中ノードが含まれるサブネット（要求中サブネット）を確認する。ここでは、要求中サブネットは、サブネット［沼津．４Ｆ．Ｄ１．コンピュート２］である。
【０３１６】
配信管理部１３０は、ノード配信状況テーブル１１２ｒを基に、取得したサブネット［沼津．４Ｆ．Ｄ１］に含まれるイメージＸを持つノードを抽出する。ここでは、イメージＸを持つノードは、コンピュートノード４００である。
【０３１７】
配信管理部１３０は、全ての要求中サブネットについて、イメージＸを持つノードが含まれないサブネットを確認する。ここでは、イメージＸを持つノードが含まれないサブネットは、サブネット［沼津．４Ｆ．Ｄ１．コンピュート２］である。
【０３１８】
この場合、サブネット［沼津．４Ｆ．Ｄ１．コンピュート２］にはイメージＸが配信されていないため、配信管理部１３０は、サブネット［沼津．４Ｆ．Ｄ１．コンピュート２］に対してイメージＸの配信を行うと決定する。配信管理部１３０は、サブネット［沼津．４Ｆ．Ｄ１．コンピュート１］から配信可能ノード（コンピュートノード４００）を、サブネット［沼津．４Ｆ．Ｄ１．コンピュート２］から要求中ノード（コンピュートノード４００ａ）を選択する。そして、配信管理部１３０は、選択した配信可能ノード（コンピュートノード４００）によるイメージＸの配信を実行させる。
【０３１９】
図５３は、第３の実施の形態のノード配信状況の更新例（続き）を示す図である。このとき、配信管理部１３０は、ノード配信状況テーブル１１２ｓで示されるように配信状況を更新する。具体的には、配信管理部１３０は、コンピュートノード４００を、「配信可能」から「配信中」へ遷移させる。配信管理部１３０は、コンピュートノード４００ａを、「要求中」から「取得中」へ遷移させる。
【０３２０】
そして、配信管理部１３０は、コンピュートノード２００からイメージＸの取得完了報告を受信すると、ノード配信状況テーブル１１２ｔで示されるように、配信状況を更新する。具体的には、配信管理部１３０は、コントローラノード１００を、「配信中」から「配信可能」へ遷移させる。配信管理部１３０は、コンピュートノード２００を「取得中」から「取得完了」へ遷移させる。
【０３２１】
図５４は、第３の実施の形態のノード配信状況の更新例（続き）を示す図である。配信管理部１３０は、コントローラノード１００が配信可能状態になったため、サブネット［沼津．３Ｆ．Ａ１．コンピュート２］の要求中ノード（コンピュートノード２００ａ）へのイメージＸの配信を開始させる。また、イメージＸの取得を完了したコンピュートノード２００では、イメージＸの配信準備が開始される。その後、配信管理部１３０は、コンピュートノード２００からイメージＸの配信準備完了報告を受信する。この段階において、配信管理部１３０は、ノード配信状況テーブル１１２ｕで示されるように、配信状況を更新する。具体的には、配信管理部１３０は、コントローラノード１００を、「配信可能」から「配信中」へ遷移させる。配信管理部１３０は、コンピュートノード２００ａを、「要求中」から「取得中」へ遷移させる。配信管理部１３０は、コンピュートノード２００を、「取得完了」から「配信可能」へ遷移させる。
【０３２２】
そして、配信管理部１３０は、コンピュートノード４００ａからイメージＸの取得完了報告を受信する。配信管理部１３０は、当該取得完了報告を受信すると、ノード配信状況テーブル１１２ｖで示されるように、配信状況を更新する。具体的には、配信管理部１３０は、コンピュートノード４００を、「配信中」から「配信可能」へ遷移させる。配信管理部１３０は、コンピュートノード４００ａを、「取得中」から「取得完了」へ遷移させる。
【０３２３】
図５５は、第３の実施の形態のノード配信状況の更新例（続き）を示す図である。その後、配信管理部１３０は、コンピュートノード２００ａからイメージＸの取得完了報告を受信する。配信管理部１３０は、当該取得完了報告を受信すると、ノード配信状況テーブル１１２ｗで示されるように、配信状況を更新する。具体的には、配信管理部１３０は、コントローラノード１００を、「配信中」から「配信可能」へ遷移させる。配信管理部１３０は、コンピュートノード２００ａを、「取得中」から「取得完了」へ遷移させる。
【０３２４】
なお、コンピュートノード２００ａ，４００ａについて、取得完了状態までの遷移としたが、配信管理部１３０は、コンピュートノード２００ａ，４００ａを配信可能状態まで遷移させるよう、コンピュートノード２００ａ，４００ａを制御してもよい。
【０３２５】
こうして、デプロイ指示に対して、イメージＸの配信先として決定された４つのコンピュートノードにおいて、イメージＸを用いたインスタンスの起動が可能になる。
このように、コントローラノード１００は、まずは同一階層のサブネット間でイメージを共有させ、その後、サブネット内で直下のサブネットに対してイメージを配信するように各ノードを制御する。
【０３２６】
これにより、第２の実施の形態と同様に、スイッチ間の通信量を低減できる。このため、コアスイッチ３０、アグリゲーションスイッチ４０，４０ａおよびラックスイッチ５０，５０ａ，５０ｂの負荷が軽減され、各スイッチによる通信速度の低下を抑えることができる。その結果、インスタンス（仮想マシン）の配備時間を短縮できる。特に、各サブネットへのイメージ配信後、同一サブネット内で並行してイメージ配信を行えるため、インスタンスの配備時間を一層高速化できる。
【０３２７】
次に、第３の実施の形態におけるノード追加時の処理を例示する。
図５６は、第３の実施の形態のノード追加の具体例を示す図である。例えば、アグリゲーションスイッチ４０ａに、ラックスイッチ５０ｃが新たに接続された場合を考える。ラックスイッチ５０ｃには、コンピュートノード５００が接続されている。ラックスイッチ５０ｃの名称は、“沼津．４Ｆ．Ｄ２”である。コンピュートノード５００の名称は、“沼津．４Ｆ．Ｄ２．コンピュート１”である。この場合、配信管理部１３０は、次のようにノード配信状況テーブル１１２ｗを更新する。
【０３２８】
図５７は、第３の実施の形態のノード追加後のノード配信状況例を示す図である。ノード配信状況テーブル１１２ｘは、ノード配信状況テーブル１１２ｗに対して、コンピュートノード５００の情報が追加された結果を示している。
【０３２９】
ノード配信状況テーブル１１２ｘには、ノード名“沼津．４Ｆ．Ｄ２．コンピュート１”およびイメージ名“イメージＸ”のレコードが追加されている。また、ノード配信状況テーブル１１２ｘには、ノード名“沼津．４Ｆ．Ｄ２．コンピュート１”およびイメージ名“イメージＹ”のレコードが追加されている。
【０３３０】
コンピュートノード５００は、追加された時点で、イメージＸ，Ｙの何れも保持していないので、イメージＸ，Ｙに対して、未取得状態として管理される。
次に、第３の実施の形態の配信管理部１３０によるキャッシュ管理の手順を説明する。
【０３３１】
図５８は、第３の実施の形態のキャッシュ管理例を示すフローチャートである。以下、図５８に示す処理をステップ番号に沿って説明する。
（Ｓ１２１）配信管理部１３０は、何れかのコンピュートノードからディスク空き容量不足の通知を受信する。
【０３３２】
（Ｓ１２２）配信管理部１３０は、ノード配信状況テーブル１１２ｘから、該当のコンピュートノードが保有するイメージの一覧（ｌｓ）を取得する。
（Ｓ１２３）配信管理部１３０は、一覧（ｌｓ）の各イメージについて（一覧（ｌｓ）から１つのイメージ（ｉ）を選択して）ステップＳ１２４〜Ｓ１２７を繰り返し実行する。
【０３３３】
（Ｓ１２４）配信管理部１３０は、イメージ（ｉ）について、ノード配信状況テーブル１１２ｘからそのイメージを保有している他のノード（Ｎｓ）を取得する。配信管理部１３０は、他のノード（Ｎｓ）を複数取得することもある。
【０３３４】
（Ｓ１２５）配信管理部１３０は、他のノード（Ｎｓ）毎に、該当のノード（ディスク空き容量不足の通知を送信したノード）からの距離（Ｓｓ）を計算する。距離の計算手順は、図４２で例示した手順と同様である。他のノード（Ｎｓ）が複数ある場合、距離（Ｓｓ）も複数計算されることになる。
【０３３５】
（Ｓ１２６）配信管理部１３０は、計算した距離（Ｓｓ）の最小値を、イメージ（ｉ）の距離スコア（ｍｉｎｓｃｏｒｅ［ｉ］）として記憶部１１０に格納し、保持する。
（Ｓ１２７）配信管理部１３０は、一覧（ｌｓ）の全てのイメージに対して、ｍｉｎｓｃｏｒｅ［ｉ］を計算すると、繰り返しを終了し、処理をステップＳ１２８に進める。
【０３３６】
（Ｓ１２８）配信管理部１３０は、一覧（ｌｓ）に含まれる各イメージの距離スコア（ｍｉｎｓｃｏｒｅ［ｉ］）のうち、最小値に対応するイメージの削除を該当ノードに指示する。配信管理部１３０は、当該削除の指示に応じて、ノード配信状況テーブル１１２ｘを更新する。
【０３３７】
図５９は、第３の実施の形態のイメージ削除後のノード配信状況例を示す図である。例えば、配信管理部１３０は、コンピュートノード４００からディスク空き容量不足の通知を受信する。配信管理部１３０は、通知に応じて、ノード配信状況テーブル１１２ｘを参照して、コンピュートノード４００が保持するイメージを特定する。ノード配信状況テーブル１１２ｘによれば、コンピュートノード４００は、イメージＸ，Ｙを保持している。
【０３３８】
ここで、ノード配信状況テーブル１１２ｘによれば、イメージＸは、コントローラノード１００およびコンピュートノード２００，２００ａ，４００ａが保持しており、コンピュートノード４００からの距離スコアの最小値は“２”である。
【０３３９】
一方、イメージＹは、コントローラノード１００が保持しており、コンピュートノード４００からの距離スコアは“６”である。
配信管理部１３０は、距離スコアが小さい方の（すなわち、より近くに存在する）イメージを優先して削除するように、コンピュートノード４００の分散配信部に指示する。この場合、配信管理部１３０は、イメージＸの削除を指示する。
【０３４０】
このとき、配信管理部１３０は、ノード配信状況テーブル１１２ｙで示されるように、イメージＸの配信状況を更新する。具体的には、配信管理部１３０は、コンピュートノード４００を、イメージＸについて、「配信可能」から「未取得」に遷移させる。
【０３４１】
このように、コントローラノード１００は、より近くに存在するイメージＸを優先して削除するように、コンピュートノード４００に指示する。これにより、仮にコンピュートノード４００で再度イメージＸを利用する場合にもスイッチ間の通信の発生をできるだけ抑えて、イメージＸをコンピュートノード４００に再配信できる。
【０３４２】
なお、各コンピュートノードにおけるイメージの分散配信の処理（イメージの削除処理を含む）や、コントローラノード１００における新規のイメージの登録処理の例は、第２の実施の形態と同様であるため、説明を省略する。
【０３４３】
［第４の実施の形態］
以下、第４の実施の形態を説明する。前述の第２，第３の実施の形態と相違する事項を主に説明し、共通する事項の説明を省略する。
【０３４４】
クラウドコンピューティングの環境では、マルチテナントが一般的であり、あるテナントのための処理と、別のテナントのための処理とは分離される。複数のテナントから同時にイメージの配信要求を受け付けた場合、最初に配信要求を送ったテナントのためにリソースがロックされてしまうと、２番目以降に配信要求を送ったテナントに対してインスタンスの配備を直ちに行えなくなるおそれがある。そこで、第４の実施の形態では、ノード配信状況テーブルに関するリソースがロックされないようにし、また、各ノード／各スイッチにおける通信状態を管理するテーブルを新しく追加することで、テナント毎のイメージ配信の権利を確保する。
【０３４５】
その際、新たに多重通信クォータ（単にクォータと称することがある）と呼ばれるパラメータを導入する。クォータは、各テナントに割り当てられた数値であり、該当のテナントに対して許容される同時通信数を表す。クォータの値は、システム管理者によって予め定められ、配信管理部１３０により保持される固定値である。第４の実施の形態では、一例として、全てのテナントのクォータを１とする。
【０３４６】
ここで、第４の実施の形態の情報処理システムに含まれるスイッチおよびノードは、図３８で例示した第３の実施の形態の情報処理システムと同様である（スイッチ名やノード名も図４０で示した名称と同様である）。ただし、第４の実施の形態では、コントローラノード１００が新たに通信テーブルを保持する点、および、ノード配信状況テーブルに登録される項目の種類が、第３の実施の形態と異なる。
【０３４７】
図６０は、第４の実施の形態の通信テーブルの例を示す図である。通信テーブル１１９は、記憶部１１０に格納される。通信テーブル１１９は、スイッチへの接続毎に、何れのテナントによる通信を行っているかを示す情報を保持する。通信テーブル１１９は、接続名および通信中テナントの項目を含む。
【０３４８】
接続名の項目には、接続名が登録される。接続名としては、スイッチ名およびノード名が用いられる。通信中テナントの項目には、該当の接続名で用いられるスイッチまたはノードを用いて通信しているテナントの名称（識別情報）が登録される。
【０３４９】
例えば、通信テーブル１１９には、接続名が“沼津”、通信中テナントが“−”（ハイフン記号であり、設定なしを示す）という情報が登録される。これは、コアスイッチ３０（接続名“沼津”に対応）を用いて通信しているテナントが存在していないことを示す。
【０３５０】
通信テーブル１１９には、他の接続名に対しても、同様に通信中テナントが登録される。ただし、図６０で示す通信テーブル１１９では、通信中テナントの設定が全て設定なし（“−”）である。これは、何れのテナントによる通信も行われていないことを示す。
【０３５１】
図６１は、第４の実施の形態のノード配信状況テーブルの例を示す図である。ノード配信状況テーブル１１２ｚは、記憶部１１０に格納される。ノード配信状況テーブル１１２ｚは、ノード名、イメージ名、未取得、要求中、取得中、取得完了、取得可能および申請元テナントの項目を含む。
【０３５２】
ここで、ノード配信状況テーブル１１２ｚでは、配信中の項目がない点、および、申請元テナントの項目がある点が、図４１で例示した第３の実施の形態のノード配信状況テーブル１１２ｍと異なる。それ以外の項目の設定内容は、ノード配信状況テーブル１１２ｍの同名の項目の設定内容と同様である。
【０３５３】
申請元テナントの項目には、配信要求の申請（あるいは、インスタンスのデプロイ指示）を行ったテナントのテナント名が登録される。
例えば、ノード配信状況テーブル１１２ｚには、ノード名が“沼津．３Ｆ．Ａ１．クラウドコントローラ”、イメージ名が“イメージＸ”、未取得が“０”、要求中が“０”、取得中が“０”、取得完了が“０”、配信可能が“１”、申請元テナントが“−”という情報が登録される。これは、ノード名“沼津．３Ｆ．Ａ１．クラウドコントローラ”で示されるコントローラノード１００が、イメージＸを保持しており、当該イメージＸについて配信可能状態であることを示す。また、現在、イメージＸの配信を申請しているテナントが存在していないことを示す。
【０３５４】
ノード配信状況テーブル１１２ｚには、他のノードおよびイメージについても同様に各項目に情報が登録される。
次に、第４の実施の形態のコントローラノード１００の処理手順を説明する。第４の実施の形態のインスタンスのデプロイの手順は、図１６で例示した第２の実施の形態のデプロイの手順と同様である。ただし、第４の実施の形態では、コントローラノード１００は、図１６のステップＳ１２の距離計算の手順として、図４２の距離計算の手順を実行する。また、第４の実施の形態では、コントローラノード１００は、図１６のステップＳ１６の配信指示の手順として、図４６，図４７の手順を実行する。ただし、第４の実施の形態では、図４７の手順のうち、下記の一部の手順が第３の実施の形態と異なる。
【０３５５】
図６２は、第４の実施の形態の配信指示例を示すフローチャートである。以下、図６２に示す処理をステップ番号に沿って説明する。ここで、図６２の手順では、配信管理部１３０が、図４７の手順におけるステップＳ１０６〜Ｓ１０９に代えて、ステップＳ１０６ａを実行する点が異なる。そこで、以下では、ステップＳ１０６ａを説明し、他のステップの説明を省略する。ここで、ステップＳ１０６ａは、ステップＳ１０５でＹｅｓの場合に実行される。
【０３５６】
（Ｓ１０６ａ）配信管理部１３０は、今回のデプロイ指示（テナントの識別情報を含む）について、各ノードと各スイッチとの間の通信中テナント数に応じた配信指示を実行する。処理の詳細は後述される。そして、配信管理部１３０は、処理をステップＳ１０５に進める。
【０３５７】
図６３は、第４の実施の形態の配信指示の追加部分を示すフローチャートである。以下、図６３に示す処理をステップ番号に沿って説明する。以下の手順は、図６２のステップＳ１０６ａに相当する。
【０３５８】
（Ｓ１３１）配信管理部１３０は、サブネット（Ｃ）内で以下の条件を満たす配信可能ノード群（Ｆｓ）を検索する。条件とは、サブネット（Ｐ）内でノード（配信可能ノード）が所属する全ての子サブネットについて、通信テーブル１１９に登録されている該当テナントの接続数が該当テナントに設定された多重通信クォータよりも少ないことである。ここで、前述のように、各テナントに対して設定されている多重通信クォータは１である。
【０３５９】
（Ｓ１３２）配信管理部１３０は、ステップＳ１３１の条件を満たす配信可能ノードが１件以上存在するか否かを判定する。配信可能ノードが１件以上存在する場合、処理をステップＳ１３３に進める。配信可能ノードが１件以上存在しない場合（すなわち、０件の場合）、処理をステップＳ１３２に進める（条件を満たす配信可能ノードが発生するまで待機する）。ここで条件を満たすと判定された配信可能ノードが、配信可能ノード群（Ｆｓ）の要素となる。
【０３６０】
（Ｓ１３３）配信管理部１３０は、サブネット（Ｃ）内で以下の条件を満たす要求中ノード群（Ｔｓ）を検索する。条件とは、サブネット（Ｐ）内でノード（要求中ノード）が所属する全ての子サブネットについて、通信テーブル１１９に登録されている該当テナントの接続数が該当テナントに設定された多重通信クォータよりも少ないことである。
【０３６１】
（Ｓ１３４）配信管理部１３０は、ステップＳ１３３の条件を満たす要求中ノードが１件以上存在するか否かを判定する。要求中ノードが１件以上存在する場合、処理をステップＳ１３５に進める。要求中ノードが１件以上存在しない場合（すなわち、０件の場合）、処理をステップＳ１３４に進める（条件を満たす要求中ノードが発生するまで待機する）。ここで条件を満たすと判定された要求中ノードが、要求中ノード群（Ｔｓ）の要素となる。
【０３６２】
（Ｓ１３５）配信管理部１３０は、配信可能ノード群（Ｆｓ）から、通信中テナント数ベースでのスコア付けを実行し、スコアに基づいて、配信可能ノード（Ｆ）を１つ選択する。ここで、通信中テナント数ベースのスコア付けでは、配信管理部１３０は、次の式（１）を用いて、ノード（ｎ）のスコアＳｃ（ｎ）を求める。
【０３６３】
【数１】
2018005456.tif 000003
【０３６４】
ここで、Ｓは、現在処理中のサブネットに所属し、ノード（ｎ）が含まれる全てのサブネットの集合である。ｃ（ｉ）は、通信テーブル１１９における、ｉに相当する接続名に対応する通信中テナントの数である。配信管理部１３０は、配信可能ノード群（Ｆｓ）に属する配信可能ノード（ｎ）のうち、スコアＳｃ（ｎ）が最も小さいノードを、配信可能ノード（Ｆ）として選択する。
【０３６５】
（Ｓ１３６）配信管理部１３０は、要求中ノード群（Ｔｓ）から、通信中テナント数ベースでのスコア付けを実行し、スコアに基づいて、要求中ノード（Ｔ）を１つ選択する。配信管理部１３０は、式（１）を用いて、ステップＳ１３６におけるスコア付けを行える。配信管理部１３０は、要求中ノード群（Ｔｓ）に属する要求中ノード（ｎ）のうち、スコアＳｃ（ｎ）が最も小さいノードを、要求中ノード（Ｔ）として選択する。
【０３６６】
（Ｓ１３７）配信管理部１３０は、配信可能ノード（Ｆ）から、要求中ノード（Ｔ）へイメージを配信させる。具体的には、配信管理部１３０は、配信可能ノード（Ｆ）から該当のイメージを取得するように、要求中ノード（Ｔ）にイメージ取得指示を送信する。イメージ取得指示を受信した要求中ノード（Ｔ）は、配信可能ノード（Ｆ）からイメージを取得する。ここで、配信状況の変更に伴って、ノード配信状況テーブル１１２ｚにおける要求中ノード（Ｔ）の状態を「要求中」から「取得中」へ、「取得中」から「取得完了」へ、「取得完了」から「配信可能」へと遷移させる。そして、処理を終了する。
【０３６７】
このように、配信管理部１３０は、コンピュートノードとスイッチとの間で行われている通信に対応するテナントの数に基づいて、配信先ノードとイメージの配信元ノードとの組み合わせを決定する。より具体的には、配信管理部１３０は、通信中テナント数ベースのスコア付けの結果、最もスコアの小さい配信可能ノードと最もスコアの小さい要求中ノードとを組み合わせてイメージの配信を行うよう制御する。これにより、通信中テナント数の少ない通信経路（すなわち、現状の負荷の小さいスイッチを介した通信経路）でのイメージ配信が可能になる。
【０３６８】
図６４は、第４の実施の形態のスコア計算の具体例（その１）を示す図である。ＣＴＲ１２０は、各コンピュートノードの負荷情報と、配信管理部１３０から取得した各コンピュートノードのイメージからの距離とを、記憶部１１０に記憶されたノード管理テーブル１１６ｂに記録する。ＣＴＲ１２０は、ノード管理テーブル１１６ｂに基づいて、インスタンスを起動するコンピュートノードを決定する。
【０３６９】
ここで、以下に示す具体例では、デプロイ指示において、イメージＸにより起動されるインスタンスが指定され、インスタンスの配備数“４”が指定されているものとする。また、当該デプロイ指示は、テナント名“テナントＡ”のテナントにより入力されたものであり、“テナントＡ”の識別情報を含む。
【０３７０】
ノード管理テーブル１１６ｂでは、イメージＸを新たに配信する場合の距離を例示している。図４２の手順によれば、コンピュートノード２００のイメージＸからの距離は“０”である。コンピュートノード２００ａのイメージＸからの距離は“２”である。コンピュートノード３００のイメージＸからの距離は“４”である。コンピュートノード４００，４００ａのイメージＸからの距離は“６”である。
【０３７１】
ＣＴＲ１２０は、ノード管理テーブル１１６ｂに記録されたメモリ空き容量、ディスク入出力およびイメージからの距離といった各指標の値を所定の演算によって正規化した値（スコア）を求め、スコアテーブル１１７ｂを生成する。ＣＴＲ１２０は、重みテーブル１１５に設定された重みを用いて、スコアテーブル１１７ｂの各スコアを重み付けした上で加算し、最終的なスコア（最終スコア）の計算結果を得る。具体的な計算方法は、図１８で例示した方法と同様である。
【０３７２】
最終スコアテーブル１１８ｂの例では、順位の優先順に、ノード名“沼津．４Ｆ．Ｄ１．コンピュート１”、“沼津．３Ｆ．Ａ１．コンピュート２”、“沼津．４Ｆ．Ｄ１．コンピュート２”、“沼津．３Ｆ．Ａ１．コンピュート１”それぞれに対応するコンピュートノードが選択される。すなわち、ＣＴＲ１２０は、コンピュートノード４００，２００ａ，４００ａ，２００を、インスタンスの配備先（イメージの配信先）として選択する。
【０３７３】
なお、図６４の例では、ＣＴＲ１２０が各コンピュートノードから取得する負荷情報として、メモリ空き容量やディスク入出力の負荷を取得するものとしたが、評価の対象とする負荷の指標は任意に決定することができる。例えば、前述のように、負荷の指標としてプロセッサ使用率を更に加味して、最終スコアを求めてもよい。
【０３７４】
配信管理部１３０は、ＣＴＲ１２０により決定されたコンピュートノード２００，２００ａ，４００，４００ａに対する配信処理を実行する。ここで、コンピュートノード２００は、イメージＸを既に保持している。このため、配信管理部１３０は、コンピュートノード２００に対してはイメージＸの配信を行わなくてよい。
【０３７５】
図６５は、第４の実施の形態のノード配信状況の更新例を示す図である。まず、配信管理部１３０は、ノード配信状況テーブル１１２ｚ１で示されるように配信状況を更新する。具体的には、配信管理部１３０は、イメージＸを未取得であるコンピュートノード２００ａ，４００，４００ａを、イメージＸについて、「未取得」から「要求中」に遷移させる。また、配信管理部１３０は、今回状態の更新を行ったレコードの申請元テナントの項目に、デプロイ指示の入力元であるテナント名“テナントＡ”を登録する。ここで、配信管理部１３０は、コンピュートノードの状態を、「要求中」に遷移させるタイミングに限り、申請元テナントの項目にテナント名の追加を行う。
【０３７６】
図６６は、第４の実施の形態のキューの例（その１）を示す図である。配信管理部１３０は、記憶部１１０に格納されたキューにより、第３の実施の形態で説明した図６２の手順を制御する。まず、配信管理部１３０は、データセンタ全体のサブネットのサブネット名およびデプロイ指示の入力元のテナント名をキューｑ１０に追加する。
【０３７７】
データセンタ全体のサブネット名は“沼津”である。また、今回のデプロイ指示の入力元のテナント名は“テナントＡ”である。このため、配信管理部１３０は、“［沼津，テナントＡ］”という情報をキューｑ１０に登録する。
【０３７８】
配信管理部１３０は、キューｑ１０に基づいて、サブネット［沼津］に関し、図６２の手順を実行する。配信管理部１３０は、キューｑ１０から“［沼津，テナントＡ］”の情報を抽出すると、キューｑ１０の“［沼津］”の情報を削除する。キューｑ１１は、当該削除後のキューの状態（空の状態）を示している。
【０３７９】
配信管理部１３０は、ノード配信状況テーブル１１２ｚ１を参照して、サブネット［沼津］に含まれるイメージＸの要求中ノードを抽出する。抽出される要求中ノードは、コンピュートノード２００，２００ａ，４００，４００ａである。
【０３８０】
次に、配信管理部１３０は、ノード配信状況テーブル１１２ｚ１を参照して、抽出した要求中ノードのノード名を基に、サブネット［沼津］直下の要求中ノードが含まれるサブネット（要求中サブネット）を確認する。ここでは、要求中サブネットは、サブネット［沼津．３Ｆ］およびサブネット［沼津．４Ｆ］である。
【０３８１】
次に、配信管理部１３０は、ノード配信状況テーブル１１２ｚ１を参照して、配信対象であるイメージＸを持つノードを抽出する。ここでは、イメージＸを持つノードは、コントローラノード１００およびコンピュートノード２００である。
【０３８２】
更に、配信管理部１３０は、全ての要求中サブネットについて、イメージを持つノードが含まれないサブネットを確認する。ここでは、サブネット［沼津．３Ｆ］は、イメージＸを持つノード（具体的には、コントローラノード１００およびコンピュートノード２００）を含む。一方、サブネット［沼津．４Ｆ］は、イメージＸを持つノードを含まない。
【０３８３】
この場合、サブネット“［沼津．４Ｆ］”には、イメージＸが未配信であるため、配信管理部１３０は、イメージＸの配信を行うと決定する。ここで、イメージＸの配信元となるサブネット［沼津．３Ｆ］には、配信元ノードの候補として、コントローラノード１００およびコンピュートノード２００の２つがある。また、イメージＸの配信先となるサブネット［沼津．４Ｆ］には、配信先ノードの候補として、コンピュートノード４００，４００ａの２つがある。第４の実施の形態では、配信管理部１３０は、各ノードと各スイッチとの間で行われている通信に対応するテナントの数に基づいて、配信元ノードおよび配信先ノードの組を決定する。
【０３８４】
まず、配信管理部１３０は、サブネット［沼津．３Ｆ］に属するサブネットの配信可能ノードについて、所属するサブネットを抽出する。具体的には、配信管理部１３０は、１つ目の配信可能ノードであるコントローラノード１００について、サブネット［沼津．３Ｆ］、［沼津．３Ｆ．Ａ１］、［沼津．３Ｆ．Ａ１．クラウドコントローラ］を抽出する。配信管理部１３０は、２つ目の配信可能ノードであるコンピュートノード２００について、サブネット［沼津．３Ｆ］、［沼津．３Ｆ．Ａ１］、［沼津．３Ｆ．Ａ１．コンピュート１］を抽出する。
【０３８５】
更に、配信管理部１３０は、サブネット［沼津．４Ｆ］に属するサブネットの要求中ノードについて、所属するサブネットを抽出する。具体的には、配信管理部１３０は、１つ目の要求中ノードであるコンピュートノード４００について、サブネット［沼津．４Ｆ］、［沼津．４Ｆ．Ｄ１］、［沼津．４Ｆ．Ｄ１．コンピュート１］を抽出する。配信管理部１３０は、２つ目の要求中ノードであるコンピュートノード４００ａについて、サブネット［沼津．４Ｆ］、［沼津．４Ｆ．Ｄ１］、［沼津．４Ｆ．Ｄ１．コンピュート２］を抽出する。
【０３８６】
配信管理部１３０は、通信テーブル１１９を参照し、上記で抽出したサブネットにおいて、デプロイ指示の入力元のテナントが通信中であるか否かを確認する。ここでは、通信テーブル１１９には、何れのテナント名も登録されていないので、配信管理部１３０は、抽出したサブネットではテナント名“テナントＡ”のテナントによる通信を行っていないと判断する。すなわち、配信管理部１３０は、当該サブネットにおいて、該当のテナントによる通信の数が、該当のテナントに対して設定された通信のクォータ“１”に達していないことを確認する。この場合、配信管理部１３０は、配信可能ノード（コントローラノード１００およびコンピュートノード２００）と、要求中ノード（コンピュートノード４００，４００ａ）との何れの組み合わせで、イメージＸの配信を行ってもよいと判断する。
【０３８７】
そして、配信管理部１３０は、配信可能ノードおよび要求中ノードそれぞれを、式（１）により、通信中テナント数ベースでスコア付けする。例えば、式（１）において、コントローラノード１００に対し、現在処理中のサブネットは、サブネット［沼津］である。サブネット［沼津］に所属し、コントローラノード１００が含まれる全てのサブネットは、サブネット［沼津．３Ｆ］、［沼津．３Ｆ．Ａ１］、［沼津．３Ｆ．Ａ１．クラウドコントローラ］である。また、通信テーブル１１９によれば、同名の接続名に対応する通信中テナントの数は何れも０である。したがって、式（１）により求まるコントローラノード１００のスコアは、（０＋１）＾２＋（０＋１）＾２＋（０＋１）＾２＝１＋１＋１＝３である。同様に、配信管理部１３０は、コンピュートノード２００のスコアを３、コンピュートノード４００のスコアを３、コンピュートノード４００ａのスコアを３と求める（この場合、これらノードのスコアは同じである）。
【０３８８】
配信管理部１３０は、最もスコアの小さい配信可能ノードと、最もスコアの小さい要求中ノードとを組み合わせてイメージＸを配信させる。今回は、スコアに違いがないため、例えば、配信管理部１３０は、ノード名に含まれる番号の小さい順に、配信可能ノードとしてコントローラノード１００を、要求中ノードとしてコンピュートノード４００を、それぞれ選択する。
【０３８９】
図６７は、第４の実施の形態のノード配信状況の更新例（続き）を示す図である。配信管理部１３０は、ノード配信状況テーブル１１２ｚ２で示されるように、選択したコンピュートノード４００を、イメージＸについて「要求中」から「取得中」に遷移させる。このとき、配信管理部１３０は、該当のレコードから申請元テナントの項目に設定されたテナント名“テナントＡ”を削除する。配信管理部１３０は、コンピュートノード４００に対して、コントローラノード１００からのイメージＸの取得を指示し、イメージＸの配信を実行させる。
【０３９０】
イメージＸの配信開始に伴って、配信管理部１３０は、現在のサブネットの子サブネットで配信元ノードと配信先ノードとが含まれる全てのサブネットについて、該当のテナント名を、通信テーブル１１９に追加する。
【０３９１】
図６８は、第４の実施の形態の通信テーブルの更新例（その１）を示す図である。現在のサブネットは、サブネット［沼津］である。サブネット［沼津］の子サブネットで、配信元ノードであるコントローラノード１００が含まれるサブネットは、サブネット［沼津．３Ｆ］、［沼津．３Ｆ．Ａ１］、［沼津．３Ｆ．Ａ１．クラウドコントローラ］である。また、サブネット［沼津］の子サブネットで、配信先ノードであるコンピュートノード４００が含まれるサブネットは、サブネット［沼津．４Ｆ］、［沼津．４Ｆ．Ｄ１］、［沼津．４Ｆ．Ｄ１．コンピュート１］である。配信管理部１３０は、これら６つの子サブネットと同名の接続名に対して、通信テーブル１１９の通信中テナントの項目にテナント名“テナントＡ”を登録する。通信テーブル１１９ａは、“テナントＡ”の登録後の通信テーブルを例示している。
【０３９２】
このタイミング（“テナントＡ”のデプロイ指示に対するイメージＸの配信途中）で、別のテナントから別のデプロイ指示が、コントローラノード１００に入力されるとする。当該別のデプロイ指示について、入力元のテナントのテナント名は“テナントＢ”である。また、デプロイ対象のインスタンスに対応するイメージはイメージＹである。配備数は１である。新たなデプロイ指示に対して、ＣＴＲ１２０は、スコア計算を行い、インスタンスの起動ノード（イメージＹの配信先ノード）を決定する。
【０３９３】
図６９は、第４の実施の形態のスコア計算の具体例（その２）を示す図である。ＣＴＲ１２０は、各コンピュートノードの負荷情報と、配信管理部１３０から取得した各コンピュートノードのイメージからの距離とを、記憶部１１０に記憶されたノード管理テーブル１１６ｃに記録する。ＣＴＲ１２０は、ノード管理テーブル１１６ｃに基づいて、インスタンスを起動するコンピュートノードを決定する。
【０３９４】
ここで、新たなデプロイ指示では、イメージＹにより起動されるインスタンスが指定され、インスタンスの配備数“１”が指定されている。また、当該デプロイ指示は、テナント名“テナントＢ”のテナントにより入力されたものであり、“テナントＢ”の識別情報を含む。
【０３９５】
ノード管理テーブル１１６ｃでは、イメージＹを新たに配信する場合の距離を例示している。図４２の手順によれば、コンピュートノード２００のイメージＹからの距離は“２”である。コンピュートノード２００ａのイメージＹからの距離は“２”である。コンピュートノード３００のイメージＹからの距離は“４”である。コンピュートノード４００，４００ａのイメージＸからの距離は“６”である。
【０３９６】
ＣＴＲ１２０は、ノード管理テーブル１１６ｃに記録されたメモリ空き容量、ディスク入出力およびイメージからの距離といった各指標の値を所定の演算によって正規化した値（スコア）を求め、スコアテーブル１１７ｃを生成する。ＣＴＲ１２０は、重みテーブル１１５に設定された重みを用いて、スコアテーブル１１７ｃの各スコアを重み付けした上で加算し、最終的なスコア（最終スコア）の計算結果を得る。具体的な計算方法は、図１８で例示した方法と同様である。
【０３９７】
最終スコアテーブル１１８ｃの例では、ＣＴＲ１２０は、ノード名“沼津．３Ｆ．Ａ２．コンピュート１”に対応するコンピュートノード３００を、イメージＹの配信先として選択する。
【０３９８】
なお、図６９の例でも、ＣＴＲ１２０が各コンピュートノードから取得する負荷情報として、メモリ空き容量やディスク入出力の負荷を取得するものとしたが、評価の対象とする負荷の指標は任意に決定することができる。例えば、前述のように、負荷の指標としてプロセッサ使用率を更に加味して、最終スコアを求めてもよい。
【０３９９】
配信管理部１３０は、ＣＴＲ１２０により決定されたコンピュートノード３００に対する配信処理を実行する。すなわち、配信管理部１３０は、“テナントＡ”のデプロイ指示に応じたイメージＸの配信に加えて、“テナントＢ”のデプロイ指示に応じたイメージＹの配信の制御を行う。
【０４００】
図７０は、第４の実施の形態のノード配信状況の更新例（続き）を示す図である。配信管理部１３０は、ノード配信状況テーブル１１２ｚ３で示されるように配信状況を更新する。具体的には、配信管理部１３０は、イメージＹを未取得であるコンピュートノード３００を、イメージＹについて、「未取得」から「要求中」に遷移させる。また、配信管理部１３０は、今回状態の更新を行ったレコードの申請元テナントの項目に、デプロイ指示の入力元であるテナント名“テナントＢ”を登録する。
【０４０１】
図７１は、第４の実施の形態のキューの例（その２）を示す図である。配信管理部１３０は、新たな配信制御を行うため、“［沼津，テナントＢ］”をキューに登録する。キューｑ１２は、“［沼津，テナントＢ］”を登録した状態を示している。
【０４０２】
配信管理部１３０は、キューｑ１２に基づいて、サブネット［沼津］に関し、図６２の手順を実行する。配信管理部１３０は、キューｑ１２から“［沼津，テナントＢ］”の情報を抽出すると、キューｑ１２の“［沼津，テナントＢ］”の情報を削除する。キューｑ１３は、当該削除後のキューの状態（空の状態）を示している。
【０４０３】
配信管理部１３０は、ノード配信状況テーブル１１２ｚ３を参照して、取得したサブネット［沼津］に含まれるイメージＹの要求中ノードを抽出する。抽出される要求中ノードは、コンピュートノード３００である。
【０４０４】
配信管理部１３０は、コンピュートノード３００の名称“沼津．３Ｆ．Ａ２．コンピュート１”を基に、取得したサブネット［沼津］直下の要求中ノードが含まれるサブネット（要求中サブネット）を確認する。ここでは、要求中サブネットは、サブネット［沼津．３Ｆ］である。
【０４０５】
配信管理部１３０は、ノード配信状況テーブル１１２ｚ３を基に、イメージＹを保持するノードを抽出する。ここでは、イメージＹを保持するノードは、コントローラノード１００である。配信管理部１３０は、全ての要求中サブネット（サブネット［沼津．３Ｆ］）について、イメージＹを持つノードが含まれないサブネットを確認する。ここでは、サブネット［沼津．３Ｆ］は、イメージＹを持つノード（具体的にはコントローラノード１００）を含む。したがって、要求中サブネットにイメージＹを持つノードが含まれないサブネットは存在していない（このため、現階層ではサブネット間のイメージＹの配信を行わなくてよい）。
【０４０６】
次に、配信管理部１３０は、サブネット［沼津］に、イメージＹの要求中ノードが残っているかを確認する。この段階では、サブネット［沼津．３Ｆ］にイメージＹの要求中ノード（具体的にはコンピュートノード３００）が残っている。したがって、配信管理部１３０は、“［沼津．３Ｆ，テナントＢ］”をキューに登録する。キューｑ１４は、“［沼津．３Ｆ，テナントＢ］”を登録した状態を示している。
【０４０７】
配信管理部１３０は、キューｑ１４からサブネット［沼津．３Ｆ］を抽出し、キューｑ１４の“［沼津．３Ｆ，テナントＢ］”の情報を削除する。キューｑ１５は、当該削除後のキューの状態（空の状態）を示している。
【０４０８】
配信管理部１３０は、ノード配信状況テーブル１１２ｚ３を参照して、サブネット［沼津．３Ｆ］に含まれるイメージＹの要求中ノードを抽出する。抽出される要求中ノードは、コンピュートノード３００である。
【０４０９】
次に、配信管理部１３０は、ノード配信状況テーブル１１２ｚ３を参照して、抽出した要求中ノードのノード名を基に、サブネット［沼津．３Ｆ］直下の要求中ノードが含まれるサブネット（要求中サブネット）を確認する。ここでは、要求中サブネットは、サブネット［沼津．３Ｆ．Ａ２］である。
【０４１０】
次に、配信管理部１３０は、ノード配信状況テーブル１１２ｚ３を参照して、配信対象であるイメージＹを持つノードを抽出する。ここでは、イメージＹを持つノードは、コントローラノード１００である。
【０４１１】
更に、配信管理部１３０は、全ての要求中サブネットについて、イメージＹを持つノードが含まれないサブネットを確認する。ここでは、サブネット［沼津．３Ｆ．Ａ２］は、イメージＹを持つノードを含まない。
【０４１２】
この場合、サブネット“［沼津．３Ｆ．Ａ２］”には、イメージＹが未配信であるため、配信管理部１３０は、イメージＹの配信を行うと決定する。ここで、イメージＹの配信元となるサブネット［沼津．３Ｆ．Ａ１］における配信元ノードの候補は、コントローラノード１００である。また、イメージＹの配信先となるサブネット［沼津．３Ｆ．Ａ２］における配信先ノードは、コンピュートノード３００である。配信管理部１３０は、通信のクォータを確認する。
【０４１３】
まず、配信管理部１３０は、サブネット［沼津．３Ｆ．Ａ１］に属するサブネットの配信可能ノードについて、所属するサブネットを抽出する。具体的には、配信管理部１３０は、配信可能ノードであるコントローラノード１００について、サブネット［沼津．３Ｆ．Ａ１］、［沼津．３Ｆ．Ａ１．クラウドコントローラ］を抽出する。
【０４１４】
更に、配信管理部１３０は、サブネット［沼津．３Ｆ．Ａ２］に属するサブネットの要求中ノードについて、所属するサブネットを抽出する。具体的には、配信管理部１３０は、要求中ノードであるコンピュートノード３００について、サブネット［沼津．３Ｆ．Ａ２］、［沼津．３Ｆ．Ａ２．コンピュート１］を抽出する。
【０４１５】
配信管理部１３０は、通信テーブル１１９ａを参照し、上記で抽出したサブネットにおいて、デプロイ指示の入力元のテナントが通信中であるか否かを確認する。ここでは、通信テーブル１１９ａには、デプロイ指示の入力元のテナント名“テナントＢ”は登録されていない。このため、配信管理部１３０は、抽出したサブネットではテナント名“テナントＢ”のテナントによる通信を行っていないと判断する。すなわち、配信管理部１３０は、当該サブネットにおいて、該当のテナントによる通信の数が、該当のテナントに対して設定された通信のクォータ“１”に達していないことを確認する。この場合、配信管理部１３０は、配信可能ノード（コントローラノード１００）と、要求中ノード（コンピュートノード３００）との組み合わせで、イメージＹの配信を行ってもよいと判断する。
【０４１６】
ここで、イメージＹについて、配信可能ノードが１つ、要求中ノードが１つであるので、配信管理部１３０は、式（１）による通信中テナント数ベースでのスコア付けを行わなくてよい。ただし、通信テーブル１１９ａによれば、サブネット［沼津．３Ｆ．Ａ１］およびサブネット［沼津．３Ｆ．Ａ１．クラウドコントローラ］それぞれに“テナントＡ”が登録されている（両サブネットの通信中テナント数はそれぞれ１である）。したがって、この時点におけるコントローラノード１００の式（１）によるスコアは、（１＋１）＾２＋（１＋１）＾２＝４＋４＝８となる。また、この時点におけるコンピュートノード３００の式（１）によるスコアは（０＋１）＾２＋（０＋１）＾２＝１＋１＝２となる。
【０４１７】
図７２は、第４の実施の形態のノード配信状況の更新例（続き）を示す図である。配信管理部１３０は、ノード配信状況テーブル１１２ｚ４で示されるように、コンピュートノード３００を、イメージＹについて「要求中」から「取得中」に遷移させる。このとき、配信管理部１３０は、該当のレコードから申請元テナントのテナント名“テナントＢ”を削除する。配信管理部１３０は、コンピュートノード３００に対して、コントローラノード１００からのイメージＹの取得を指示し、イメージＹの配信を実行させる。
【０４１８】
イメージＹの配信開始に伴って、配信管理部１３０は、現在のサブネットの子サブネットで配信元ノードと配信先ノードとが含まれる全てのサブネットについて、該当のテナント名を、通信テーブル１１９ａに追加する。
【０４１９】
図７３は、第４の実施の形態の通信テーブルの更新例（その２）を示す図である。現在のサブネットは、サブネット［沼津．３Ｆ］である。サブネット［沼津．３Ｆ］の子サブネットで、配信元ノードであるコントローラノード１００が含まれるサブネットは、サブネット［沼津．３Ｆ．Ａ１］、［沼津．３Ｆ．Ａ１．クラウドコントローラ］である。また、サブネット［沼津］の子サブネットで、配信先ノードであるコンピュートノード３００が含まれるサブネットは、サブネット［沼津．３Ｆ．Ａ２］、［沼津．３Ｆ．Ａ２．コンピュート１］である。配信管理部１３０は、これら４つの子サブネットと同名の接続名に対して、通信テーブル１１９ａの通信中テナントの項目にテナント名“テナントＢ”を登録する。通信テーブル１１９ｂは、“テナントＢ”の登録後の通信テーブルを例示している。
【０４２０】
その後、配信管理部１３０は、“テナントＡ”のデプロイ指示に伴うコンピュートノード４００へのイメージＸの配信完了報告を、コンピュートノード４００から受け付ける。
図７４は、第４の実施の形態のノード配信状況の更新例（続き）を示す図である。配信管理部１３０は、ノード配信状況テーブル１１２ｚ５で示されるように、コンピュートノード４００を、イメージＸについて「取得中」から「取得完了」に遷移させる。また、配信管理部１３０は、当該イメージＸの配信完了に伴って、通信テーブル１１９ｂを更新する。
【０４２１】
図７５は、第４の実施の形態の通信テーブルの更新例（その３）を示す図である。具体的には、配信管理部１３０は、通信テーブル１１９ｂの通信中テナントの項目について、イメージＸの配信に伴って追加した“テナントＡ”の情報を削除する。通信テーブル１１９ｃは、当該削除後の通信テーブルを示している。
【０４２２】
なお、“テナントＡ”のデプロイ指示に対して、要求中ノード（具体的にはコンピュートノード２００ａ，４００ａ）が未だ残っている。このため、配信管理部１３０は、現在のサブネット［沼津］直下のサブネットに関する“［沼津．３Ｆ，テナントＡ］”というエントリと、“［沼津．４Ｆ，テナントＡ］”というエントリとをキューに追加する。そして、配信管理部１３０は、キューに追加された情報に基づいて、図６２，図６３の手順により、新たに追加された各サブネット内で、イメージＸを未取得であるコンピュートノード２００ａ，４００ａに対し、イメージＸの配信を行う。上記の手順によれば、コントローラノード１００（またはコンピュートノード２００）からコンピュートノード２００ａへイメージＸの配信が行われる。また、コンピュートノード４００からコンピュートノード４００ａへイメージＸの配信が行われる。イメージＸ，Ｙの配信が完了すると、別の通信が生じない限り、通信テーブル１１９ｃの通信中テナントの項目は、全て設定なしの状態になる。
【０４２３】
こうして、コンピュートノード２００，２００ａ，４００，４００ａそれぞれにイメージＸが配信される。また、コンピュートノード３００にイメージＹが配信される。その結果、コンピュートノード２００，２００ａ，４００，４００ａは、イメージＸにより新たなインスタンスを起動可能になる。また、コンピュートノード３００は、イメージＹにより新たなインスタンスを起動可能になる。
【０４２４】
次に、第４の実施の形態におけるノード追加時の処理を例示する。
図７６は、第４の実施の形態のノード追加後の通信テーブルの例を示す図である。ここでは、図５６と同様に、アグリゲーションスイッチ４０ａに、ラックスイッチ５０ｃが新たに接続された場合を考える。ラックスイッチ５０ｃには、コンピュートノード５００が接続されている。ラックスイッチ５０ｃの名称は、“沼津．４Ｆ．Ｄ２”である。コンピュートノード５００の名称は、“沼津．４Ｆ．Ｄ２．コンピュート１”である。この場合、配信管理部１３０は、通信テーブル１１９を、通信テーブル１１９ｄで示されるように更新する。具体的には、接続名の項目に、“沼津．４Ｆ．Ｄ２”を含むレコードおよび“沼津．４Ｆ．Ｄ２．コンピュート１”を含むレコードを登録する。各レコードでは、何れのテナントによる通信も発生していないので、通信中テナントの項目は、設定なしになる。なお、配信管理部１３０は、ノード配信状況テーブル１１２ｚにも、該当のノード名“沼津４Ｆ．Ｄ２．コンピュート１”のレコードをイメージＸ，Ｙそれぞれについて登録する（イメージＸ，Ｙを未取得状態とし、申請元テナントを設定なしとする）。
【０４２５】
このように、コントローラノード１００は、新たなコンピュートノードが追加された場合も、ノード配信状況テーブル１１２ｚおよび通信テーブル１１９を更新することで、他のコンピュートノードと同様にイメージの配信制御を行えるようになる。
【０４２６】
なお、各コンピュートノードにおけるイメージの分散配信の処理（イメージの削除処理を含む）や、コントローラノード１００における新規のイメージの登録処理の例は、第２の実施の形態と同様であるため、説明を省略する。
【０４２７】
ここで、以下では、スコアによるインスタンス起動先ノードの決定方法の比較例を説明する。比較例では、コントローラノード６００を用いて、コンピュートノード７００を含む複数のコンピュートノードに対するイメージ配信を行うことを考える。コントローラノード６００は、イメージからの距離の指標を考慮せずに、各コンピュートノードのスコアを評価する。
【０４２８】
図７７は、デプロイの比較例を示すシーケンス図である。以下、図７７に示す処理をステップ番号に沿って説明する。
（ＳＴ１０１）ユーザＵ１は、コントローラノード６００にデプロイ指示を入力する。デプロイ指示は、デプロイ対象のインスタンスに対応するイメージを指定する情報、および、配備数の情報を含む。コントローラノード６００は、デプロイ指示を受け付ける。
【０４２９】
（ＳＴ１０２）コントローラノード６００は、複数のコンピュートノードそれぞれについて負荷情報を収集し、ディスク／メモリ使用状況によるスコア計算を行う。例えば、コントローラノード６００は、ディスクやメモリの使用率が少ないほど、良いスコア（大きな値）になるように、スコア計算を行う。
【０４３０】
（ＳＴ１０３）コントローラノード６００は、ステップＳＴ１０２で計算したスコアに応じて、スコアの大きい順に、該当のインスタンスのイメージの配信先ノードを選択する。例えば、コントローラノード６００は、配信先ノードの１つとして、コンピュートノード７００を選ぶとする。
【０４３１】
（ＳＴ１０４）コントローラノード６００は、ステップＳＴ１０３で選択したコンピュートノード７００に対し、該当のインスタンスの起動指示を送信する。コンピュートノード７００は、インスタンスの起動指示を受信する。
【０４３２】
（ＳＴ１０５）コンピュートノード７００は、該当のインスタンスのイメージを、コントローラノード６００から取得する。
（ＳＴ１０６）コンピュートノード７００は、取得したイメージを用いて、該当のインスタンスを起動する。
【０４３３】
（ＳＴ１０７）コンピュートノード７００は、インスタンス起動完了報告をコントローラノード６００に送信する。コントローラノード６００は、インスタンス起動完了報告を受信する。
【０４３４】
（ＳＴ１０８）コントローラノード６００は、指示されたインスタンスのデプロイが完了した旨をユーザＵ１に通知する。
図７７で例示したように、単にディスクやメモリなどの負荷によってイメージの配信先ノードを決定すると次のような問題が生じ得る。
【０４３５】
図７８は、イメージの同時多重送信の例を示す図である。例えば、コントローラノード６００が、イメージの配信先として、コンピュートノード７００，７００ａ，７００ｂ，７００ｃ，７００ｄ，７００ｅ，７００ｆを選択した場合を考える。この場合、コンピュートノード７００，７００ａ，７００ｂ，７００ｃ，７００ｄ，７００ｅ，７００ｆは、コントローラノード６００に対して、該当のイメージを要求する。コントローラノード６００は、コンピュートノード７００，７００ａ，７００ｂ，７００ｃ，７００ｄ，７００ｅ，７００ｆそれぞれからのイメージの要求を受け付ける。コントローラノード６００は、コンピュートノード７００，７００ａ，７００ｂ，７００ｃ，７００ｄ，７００ｅ，７００ｆそれぞれに対し、該当のイメージの同時多重送信を行う。
【０４３６】
ところが、この場合、コントローラノード６００に配信処理が集中してコントローラノード６００の負荷が高まるおそれがある。また、コントローラノード６００とコンピュートノード７００，７００ａ，７００ｂ，７００ｃ，７００ｄ，７００ｅ，７００ｆそれぞれとの間に設けられたスイッチで高負荷や輻輳が生じるおそれがある。その結果、イメージの配信が遅延し得る。
【０４３７】
図７９は、スイッチにおける非効率な通信の例を示す図である。例えば、フロアスイッチ６０にラックスイッチ７０，７０ａが接続されているとする。コントローラノード６００およびコンピュートノード７００，７００ａ，７００ｂ，７００ｃ，７００ｄは、ラックスイッチ７０に接続されている（図７９では各ノードを単にノードと表記している）。また、コンピュートノード７００ｅ，７００ｆは、ラックスイッチ７０ａに接続されている。また、配信対象のイメージは、コントローラノード６００およびコンピュートノード７００ｂにより保持されているとする。
【０４３８】
この場合、コントローラノード６００からコンピュートノード７００ｅ，７００ｆへの通信経路上には、ラックスイッチ７０、フロアスイッチ６０およびラックスイッチ７０ａが存在することになる。このとき、コントローラノード６００からコンピュートノード７００ｅ，７００ｆそれぞれに対して、該当のイメージを配信すると、同じデータがラックスイッチ７０、フロアスイッチ６０およびラックスイッチ７０ａの間で複数回転送されることになる。すなわち、スイッチ間で非効率な通信が生じてしまう。このような非効率な通信は、各スイッチの負荷増大や輻輳発生の要因になる。この問題は、１つのスイッチに接続されるノード数が増すほど深刻になる。
【０４３９】
図８０は、イメージの分散配信の例を示す図である。図７８，図７９の配信方法に対し、イメージの分散配信も考えられる。分散配信では、コントローラノード６００に加えて、イメージの配信を受けたコンピュートノードを、当該イメージの配信に利用する。具体的には、コントローラノード６００は、コンピュートノード７００，７００ａ，７００ｂ，７００ｃ，７００ｄ，７００ｅ，７００ｆそれぞれからのイメージの要求を受け付けると、コンピュートノードを用いて当該イメージを段階的に配信する。まず、第１段階（ｓｔｅｐ１）では、コントローラノード６００は、コンピュートノード７００にイメージを配信する。
【０４４０】
第２段階（ｓｔｅｐ２）では、コントローラノード６００は、コンピュートノード７００ａにイメージを配信する。また、第２段階では、コンピュートノード７００は、コンピュートノード７００ｂにイメージを配信する。
【０４４１】
第３段階（ｓｔｅｐ３）では、コントローラノード６００は、コンピュートノード７００ｃにイメージを配信する。また、第３段階では、コンピュートノード７００は、コンピュートノード７００ｄにイメージを配信する。また、第３段階では、コンピュートノード７００ａは、コンピュートノード７００ｅにイメージを配信する。更に、第３段階では、コンピュートノード７００ｂは、コンピュートノード７００ｆにイメージを配信する。
【０４４２】
図８０で例示した方法によれば、コントローラノード６００における配信処理の集中は緩和され得る。しかし、イメージの配信元ノードおよび配信先ノードの間において、図７９で例示した非効率な通信の発生を抑えることはできない。
【０４４３】
図８１は、スイッチの特性の例を示す図である。特に、クラウドコンピューティングの環境では、前述のように、ラックスイッチ７０に複数のノードが接続される。図８１の例では、ラックスイッチ７０は、通信用のポート７１，７２，７３，７４，７５，７６，７７を有する。ポート７１は、コントローラノード６００と接続される。ポート７２は、コンピュートノード７００と接続される。ポート７３は、コンピュートノード７００ａと接続される。ポート７４は、コンピュートノード７００ｂと接続される。ポート７５は、コンピュートノード７００ｃと接続される。ポート７６は、コンピュートノード７００ｄと接続される。ポート７７は、フロアスイッチ６０と接続される。
【０４４４】
例えば、ラックスイッチ７０では、異なるポート同士であれば他のポートの通信に影響を与えずに同時通信可能である。より具体的には、ラックスイッチ７０は、ポート７１，７３を介したコントローラノード６００とコンピュートノード７００ａとの通信の中継、および、ポート７２，７４を介したコンピュートノード７００，７００ｂの通信の中継を同時に行える。
【０４４５】
一方、ラックスイッチ７０では、同一のポートに対しては同時に通信できない。具体的には、ポート７５，７７を介したコンピュートノード７００ｃとフロアスイッチ６０との通信の中継、および、ポート７６，７７を介したコンピュートノード７００ｄとフロアスイッチ６０との通信の中継を同時に行えない。このため、ラックスイッチやフロアスイッチを多段階に接続した環境では、フロアスイッチを経由する通信は効率が悪い。そこで、イメージの配信の際は、通信を局所化することが望ましい。
【０４４６】
通信の局所化を実現するためには、ネットワーク上で各ノード間の距離の指標を適正に計算することが求められる。しかし、データセンタ内では、多段階に接続されたＬ２スイッチによりネットワークが構成されることが多く、Ｌ３レベルで用いられるルータのホップ数などを利用することはできない。
【０４４７】
そこで、コントローラノード１００は、クラスタ構成テーブル１１１（第２の実施の形態）や、スイッチ名を含めたノードの識別情報（第３，第４の実施の形態）に基づいて、スイッチの接続関係を考慮したスコアを求め、イメージの配信先の決定に用いる。
【０４４８】
図８２は、配備先の決定に用いるスコアの比較例を示す図である。図８２（Ａ）では、コントローラノード６００が作成するスコア表ＳＣ１を例示している。スコア表ＳＣ１は、ノード名に対して、メモリ空き容量やディスク入出力の項目が設けられている。スコア表ＳＣ１によれば、ノード名“ノードａ”のコンピュートノードが、メモリ空き容量“不足”、ディスク入出力“負荷高”である。また、スコア表ＳＣ１によれば、ノード名“ノードｂ”および“ノードｃ”のコンピュートノードが、メモリ空き容量“十分”、ディスク入出力“負荷低”である。ディスク入出力よりもメモリ空き容量を優先する場合、ノード名“ノードｂ”、“ノードｃ”の２つのノードが、イメージの配信先の候補になる。このとき、２つのうち１つを選択しようとする場合、両ノードの条件が同じであり、コントローラノード６００は、何れのノードを選択した方が効率的なイメージ配信を行えるかを判断できない。
【０４４９】
一方、図８２（Ｂ）では、コントローラノード１００が作成するスコア表ＳＣ２を例示している。スコア表ＳＣ２は、ノード名に対して、メモリ空き容量、ディスク入出力および距離の項目が設けられている。すなわち、コントローラノード１００は、スコア表ＳＣ２に対して、配信対象のイメージからの距離の指標を更に考慮する点が、上記のスコア表ＳＣ１による方法と異なる。スコア表ＳＣ２によれば、スコア表ＳＣ１の内容に加えて、ノード名“ノードａ”のコンピュートノードのイメージからの距離が“近い”ことが分かる。また、スコア表ＳＣ２によれば、ノード名“ノードｂ”のコンピュートノードのイメージからの距離が“遠い”ことが分かる。更に、スコア表ＳＣ２によれば、ノード名“ノードｃ”のコンピュートノードのイメージからの距離が“近い”ことが分かる。
【０４５０】
スコア表ＳＣ２によれば、コントローラノード１００は、イメージからの距離が“近い”方を、イメージの配信先に選択することで、イメージ配信に伴う通信を局所化することができる。例えば、コントローラノード１００は、イメージ配信に伴う通信を、できるだけ同一クラスタ（あるいは、同一サブネット内）に収めることができる。
【０４５１】
なお、図８２の例では、「不足」、「負荷高」、「近い」のように程度を表す語でスコアを表したが、前述のように、コントローラノード１００は、各指標を数値で表し、各指標を重み付けして加算した最終スコアによって、イメージの配信先を決定する。
【０４５２】
そして、コントローラノード１００は、該当のイメージを保持するノードを含まないクラスタ（あるいは、サブネット）が存在する場合、まずクラスタ内（あるいは、サブネット内）に少なくとも１つ該当のイメージを保持するノードを含むよう各ノードを制御する。コントローラノード１００は、その上で、同一クラスタ（あるいは、サブネット内）でイメージの配信を行うよう各ノードに指示する。これにより、イメージ配信に伴うスイッチ間の通信量を低減できる。その結果、コントローラノード１００や各スイッチの負荷を軽減し、イメージ配信処理を高速化できる。
【０４５３】
なお、第１の実施の形態の情報処理は、演算部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１３に記録できる。
【０４５４】
例えば、プログラムを記録した記録媒体１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
【０４５５】
以上の第１〜第３の実施の形態を含む実施形態に関し、更に以下の付記を開示する。
（付記１）  コンピュータに、
スイッチと前記スイッチに接続されたノードの集合であるクラスタとの対応を示すクラスタ構成情報を記憶し、ノード毎に保持するイメージの情報および当該イメージを配信可能であるか否かの情報をノードの識別情報に関連付けて配信状況テーブルとして記憶し、
第１イメージの配備指示と配備数とを受信すると、前記クラスタ構成情報および前記配信状況テーブルから、前記第１イメージを保持するノードと配備先の候補ノードとの間のスイッチの経由数に応じた距離を候補ノード毎に求め、前記候補ノードに対する距離と前記候補ノードの負荷とに基づいて配備先ノードを決定し、
前記第１イメージを保持するノードを含まないクラスタに属する配備先ノードへの前記第１イメージの送信後に、同一クラスタに属する配備先ノード間でのイメージ送信を実行するように各ノードへのイメージ送信指示を制御する、
処理を実行させるイメージ配信プログラム。
【０４５６】
（付記２）  前記距離を求める際、前記第１イメージを保持するノードと前記候補ノードとが同じクラスタに属するか否かに応じて前記距離を求める、付記１記載のイメージ配信プログラム。
【０４５７】
（付記３）  前記距離を求める際、前記第１イメージを保持する複数のノードそれぞれと配備先の候補ノードとの間のスイッチの経由数のうちの最小値を、前記候補ノードに対する前記距離とする、付記１または２記載のイメージ配信プログラム。
【０４５８】
（付記４）  前記第１イメージを保持するノードを含まないクラスタに属する配備先ノードへの前記第１イメージの送信では、当該クラスタに属する複数の配備先ノードのうちの１つに、前記第１イメージを送信するように前記イメージ送信指示を制御する、付記１乃至３の何れか１項に記載のイメージ配信プログラム。
【０４５９】
（付記５）  前記制御では、前記ノードと前記スイッチとの間で行われている通信に対応するテナントの数に基づいて、配信先ノードと前記第１イメージの配信元ノードとの組み合わせを決定する、付記１乃至４の何れか１項に記載のイメージ配信プログラム。
【０４６０】
（付記６）  複数のノードの何れかのノードから当該ノードが備える記憶装置の容量不足の通知を受信すると、前記記憶装置に記憶された複数のイメージそれぞれを保持する他のノードと前記通知の送信元のノードとの間のスイッチの経由数に応じた距離に基づいて、削除対象のイメージを前記通知の送信元のノードに指示する、付記１乃至５の何れか１項に記載のイメージ配信プログラム。
【０４６１】
（付記７）  前記制御では、第１のクラスタに属する配備先ノード間でのイメージ送信と並列に第２のクラスタに属する配備先ノード間でのイメージ送信を行うように前記イメージ送信指示を制御する、付記１乃至６の何れか１項に記載のイメージ配信プログラム。
【０４６２】
（付記８）  前記制御では、複数のスイッチによる木構造の接続関係を示す情報に基づいて、前記木構造のルートに対応するスイッチから１つずつ深さ方向にスイッチを辿り、１つ深さを増す毎に、同じ深さにある複数のスイッチそれぞれをルートとした複数の部分木のうち、前記第１イメージを保持するノードを含まない部分木毎に配備先ノードを１つずつ選択し、選択した各配備先ノードに前記第１イメージを送信するように前記イメージ送信指示を制御する、付記１乃至７の何れか１項に記載のイメージ配信プログラム。
【０４６３】
（付記９）  前記スイッチは、レイヤ２スイッチである、付記１乃至８の何れか１項に記載のイメージ配信プログラム。
（付記１０）  前記イメージは、前記配備先ノードによる仮想マシンの起動に用いられるデータである、付記１乃至９の何れか１項に記載のイメージ配信プログラム。
【０４６４】
（付記１１）  前記配備先ノードを決定する際に、前記負荷として、前記候補ノードの記憶装置およびプロセッサの使用量を取得する、付記１乃至１０の何れか１項に記載のイメージ配信プログラム。
【０４６５】
（付記１２）  スイッチと前記スイッチに接続されたノードの集合であるクラスタとの対応を示すクラスタ構成情報、および、ノード毎に保持するイメージの情報とイメージを配信可能であるか否かの情報とをノードの識別情報に関連付けた配信状況テーブルを記憶する記憶部と、
第１イメージの配備指示と配備数とを受信すると、前記クラスタ構成情報および前記配信状況テーブルから、前記第１イメージを保持するノードと配備先の候補ノードとの間のスイッチの経由数に応じた距離を候補ノード毎に求め、前記候補ノードに対する距離と前記候補ノードの負荷とに基づいて配備先ノードを決定し、
前記第１イメージを保持するノードを含まないクラスタに属する配備先ノードへの前記第１イメージの送信後に、同一クラスタに属する配備先ノード間でのイメージ送信を実行するように各ノードへのイメージ送信指示を制御する、演算部と、
を有するイメージ配信装置。
【０４６６】
（付記１３）  コンピュータが、
スイッチと前記スイッチに接続されたノードの集合であるクラスタとの対応を示すクラスタ構成情報を記憶し、ノード毎に保持するイメージの情報および当該イメージを配信可能であるか否かの情報をノードの識別情報に関連付けて配信状況テーブルとして記憶し、
第１イメージの配備指示と配備数とを受信すると、前記クラスタ構成情報および前記配信状況テーブルから、前記第１イメージを保持するノードと配備先の候補ノードとの間のスイッチの経由数に応じた距離を候補ノード毎に求め、前記候補ノードに対する距離と前記候補ノードの負荷とに基づいて配備先ノードを決定し、
前記第１イメージを保持するノードを含まないクラスタに属する配備先ノードへの前記第１イメージの送信後に、同一クラスタに属する配備先ノード間でのイメージ送信を実行するように各ノードへのイメージ送信指示を制御する、
イメージ配信方法。
【符号の説明】
【０４６７】
１  イメージ配信装置
１ａ  記憶部
１ｂ  演算部
２，２ａ，２ｂ，２ｃ，２ｄ，２ｅ，２ｆ，２ｇ，２ｈ  ノード
３，３ａ，３ｂ  クラスタ
ＳＷ１，ＳＷ１１，ＳＷ１２，ＳＷ１３  スイッチ
【図１】
2018005456.tif 000004
【図２】
2018005456.tif 000005
【図３】
2018005456.tif 000006
【図４】
2018005456.tif 000007
【図５】
2018005456.tif 000008
【図６】
2018005456.tif 000009
【図７】
2018005456.tif 000010
【図８】
2018005456.tif 000011
【図９】
2018005456.tif 000012
【図１０】
2018005456.tif 000013
【図１１】
2018005456.tif 000014
【図１２】
2018005456.tif 000015
【図１３】
2018005456.tif 000016
【図１４】
2018005456.tif 000017
【図１５】
2018005456.tif 000018
【図１６】
2018005456.tif 000019
【図１７】
2018005456.tif 000020
【図１８】
2018005456.tif 000021
【図１９】
2018005456.tif 000022
【図２０】
2018005456.tif 000023
【図２１】
2018005456.tif 000024
【図２２】
2018005456.tif 000025
【図２３】
2018005456.tif 000026
【図２４】
2018005456.tif 000027
【図２５】
2018005456.tif 000028
【図２６】
2018005456.tif 000029
【図２７】
2018005456.tif 000030
【図２８】
2018005456.tif 000031
【図２９】
2018005456.tif 000032
【図３０】
2018005456.tif 000033
【図３１】
2018005456.tif 000034
【図３２】
2018005456.tif 000035
【図３３】
2018005456.tif 000036
【図３４】
2018005456.tif 000037
【図３５】
2018005456.tif 000038
【図３６】
2018005456.tif 000039
【図３７】
2018005456.tif 000040
【図３８】
2018005456.tif 000041
【図３９】
2018005456.tif 000042
【図４０】
2018005456.tif 000043
【図４１】
2018005456.tif 000044
【図４２】
2018005456.tif 000045
【図４３】
2018005456.tif 000046
【図４４】
2018005456.tif 000047
【図４５】
2018005456.tif 000048
【図４６】
2018005456.tif 000049
【図４７】
2018005456.tif 000050
【図４８】
2018005456.tif 000051
【図４９】
2018005456.tif 000052
【図５０】
2018005456.tif 000053
【図５１】
2018005456.tif 000054
【図５２】
2018005456.tif 000055
【図５３】
2018005456.tif 000056
【図５４】
2018005456.tif 000057
【図５５】
2018005456.tif 000058
【図５６】
2018005456.tif 000059
【図５７】
2018005456.tif 000060
【図５８】
2018005456.tif 000061
【図５９】
2018005456.tif 000062
【図６０】
2018005456.tif 000063
【図６１】
2018005456.tif 000064
【図６２】
2018005456.tif 000065
【図６３】
2018005456.tif 000066
【図６４】
2018005456.tif 000067
【図６５】
2018005456.tif 000068
【図６６】
2018005456.tif 000069
【図６７】
2018005456.tif 000070
【図６８】
2018005456.tif 000071
【図６９】
2018005456.tif 000072
【図７０】
2018005456.tif 000073
【図７１】
2018005456.tif 000074
【図７２】
2018005456.tif 000075
【図７３】
2018005456.tif 000076
【図７４】
2018005456.tif 000077
【図７５】
2018005456.tif 000078
【図７６】
2018005456.tif 000079
【図７７】
2018005456.tif 000080
【図７８】
2018005456.tif 000081
【図７９】
2018005456.tif 000082
【図８０】
2018005456.tif 000083
【図８１】
2018005456.tif 000084
【図８２】
2018005456.tif 000085