JP2012203625A - 論理サーバ運用システム、及び論理サーバ運用方法 - Google Patents

Abstract

【課題】移動先の物理サーバを意識することなく、性能的に過不足のない物理サーバを自動的に選択する論理サーバ運用システムを提供する。
【解決手段】ＶＭの移動指示を受けたＥＭ９、１０、１１は、自身のエンクロージャ内にあるＬ２スイッチ３２、３３、３４のＡＲＰテーブル、ＦＤＢを参照し、ＶＭが動作しているホストサーバ（移動元ホストサーバ）の検索を行う。次に、移動元ホストサーバが実装してあるエンクロージャのＥＭが、移動元ホストサーバからＳＡＮストレージ３５までのネットワークコストの算出を行う。最後に、移動元ホストサーバが実装してあるエンクロージャのＥＭが、他エンクロージャのＥＭに対して、各サーバからＳＡＮストレージ３５までのネットワークコストを問い合わせ、問い合わせ結果からＶＭの移動先に最適なサーバを選出する。
【選択図】図１

Description

本発明は、論理サーバ運用システム、及び論理サーバ運用方法に関する。

近年、多くのデータセンターでは、消費電力の削減や、運用コストの削減などを目的として、サーバ仮想化技術を用い、一台の物理サーバ上に複数の論理サーバ（ＶＭ：Virtual Machine）を構築して運用する傾向にある。このことを、一般的に「物理サーバのマイグレーション」と呼ぶ。物理サーバのマイグレーションは、物理サーバの運用コストが削減できる反面、運用中のＶＭが物理的に見えないために、ＶＭの管理が煩雑になるという問題が新たに発生する。

特に、ＣＰＵ（Central Processing Unit）資源とストレージ資源とを分離してコンピュータシステムを構築しているケースにおいては、サーバ／スイッチ／ストレージが複雑なトポロジで接続されており、ＣＰＵ資源の障害やＶＭのマイグレーションによるＶＭの移動を行う際に、移動先の物理サーバの選択が新たな課題となる。

例えば、特許文献１には、１つ、または複数の物理サーバ上で動作する複数のＶＭに、第１の計算処理を構成する複数の第２の計算処理を分散配置する技術が記載されている。該技術では、複数の第２の計算処理を複数のＶＭに分散配置する各種の配置パターンごとのコストを計算し、当該コストが最小となる配置パターンに従って複数の第２の計算処理を複数の仮想マシンに分散配置することを特徴としている。但し、該技術では、ＶＭ自体の移動については何ら議論されていない。

つまり、ＶＭを移動させる際には、移動前にＶＭが動作していた物理サーバと同じ性能条件の物理サーバを移動先に選択することが必要である。しかしながら、ネットワーク（または、ファブリック）を介してＣＰＵ資源とストレージ資源とが分離されている場合、管理者は、ネットワーク（または、ファブリック）のトポロジを把握した上で、最適となる物理サーバにＶＭを移動させなければならない。

図９は、ＶＭ移動にまつわる問題点を説明するためのブロック図である。図９において、６９、７０、７１、７２、７３は、ＶＭが動作しているサーバを示し、７４、７５、７６、７７は、ＳＡＮ（Storage Area Network）ストレージ−サーバ間を接続するスイッチを示し、７８は、ＳＡＮストレージを示す。

現在の多くのデータセンターでは、高可用性や増設容易性のため、サーバ６９、７０、７１、７２、７３とストレージとを分離したコンピュータシステム構成が主流であり、また、度重なる増設のため、図９に示すように、サーバ６９、７０、７１、７２、７３とＳＡＮストレージ７８との間を、様々なＳＡＮスイッチ７４、７５、７６、７７を介して接続している。

このようなコンピュータシステムの上でＶＭを動作させることで、ＶＭを動作させる物理サーバを自由に選択することができるようになり、システムの高可用性や耐障害性を高めている。特に、動作中の物理サーバに障害の予兆が発生した際には、動作中のＶＭを無停止のまま、他の物理サーバ上で移動させることで、ＭＴＢＦ（Mean Time Between Failure：平均故障間隔）の長いシステムを構築することができる。

特開２０１０−２１８３０７号公報

しかしながら、上述したＶＭの移動においては、次のような課題がある。
つまり、ＳＡＮストレージを使用したコンピュータシステムでは、ＳＡＮトポロジの複雑性ため、ＶＭの移動元となる物理サーバと同程度の（もしくはより高い）ストレージ間の性能を有する物理サーバがどれなのか、容易に把握できないという問題がある。

本発明は、上述の課題を解決することのできる論理サーバ運用システム、及び論理サーバ運用方法を提供することにある。

上述した課題を解決するために、本発明は、ネットワーク上のストレージに格納されている論理サーバを起動し、複数の物理サーバ上のいずれかで動作させている論理サーバを、他の物理サーバに移動させる論理サーバ運用システムあって、前記複数の物理サーバは、各々、論理サーバの移動指示を契機として、各物理サーバから前記ストレージまでのネットワークコストを集計し、前記各物理サーバから前記ストレージまでのネットワークコストに基づいて、前記論理サーバの移動対象として好適な物理サーバを選択する論理サーバ運用管理手段を備えていることを特徴とする論理サーバ運用システムである。

また、上述した課題を解決するために、本発明は、ネットワーク上のストレージに格納されている論理サーバを起動し、複数の物理サーバ上のいずれかで動作させている論理サーバを、他の物理サーバに移動させる論理サーバ運用方法あって、前記論理サーバが動作している移動元ホスト物理サーバが、論理サーバの移動指示を契機として、自サーバから前記ストレージまでのネットワークコストを算出するステップと、他の物理サーバから前記ストレージまでのネットワークコストを取得するステップと、前記自サーバから前記ストレージまでのネットワークコストと、前記他の物理サーバから前記ストレージまでのネットワークコストとに基づいて、前記論理サーバの移動先に最適な物理サーバを選択するステップとを含むことを特徴とする論理サーバ運用方法である。

この発明によれば、管理者が論理サーバの移動を実行する際に、移動先の物理サーバを意識することなく性能的に過不足のない物理サーバを自動的に選択することができる。

本発明の第１実施形態によるコンピュータシステムの構成を示すブロック図である。 本第１実施形態による、ＶＭ移動指示からＶＭ移動までの動作を説明するための概念図である。 本第１実施形態でのコストテーブルの一例を示す概念図である。 本第１実施形態による、ＳＥＭ４０によるＶＭ移動の問い合わせ動作を説明するためのフローチャートである。 本第１実施形態による、ＳＥＭ４０によるＶＭ移動の問い合わせ動作を説明するためのシーケンス図である。 リプライパケットの構造を示す概念図である。 本第２実施形態によるコンピュータシステムの構成を示すブロック図である。 本第２実施形態でのコストテーブルの一例を示す概念図である。 ＶＭ移動にまつわる問題点を説明するためのブロック図である。

以下、本発明の一実施形態を、図面を参照して説明する。
本発明は、ブレードサーバを利用したコンピュータシステムにおいて、ブレードサーバが格納される筐体（エンクロージャ）を管理するエンクロージャマネージャ（ＥＭ：Enclosure Manager）が、ＶＭの移動指示を契機として互いに通信し、ＶＭの移動先として最適な物理サーバ、すなわち、互いのエンクロージャからターゲットとなるストレージまでのネットワークコストを計算し、移動対象の仮想マシンに最適なＩ／Ｏ性能を有する物理サーバを自動的に選択する手段、及び仮想マシンを移動する手段を提供すること特徴としている。

ブレードサーバのエンクロージャには、ＣＰＵ資源であるサーバの他に、ネットワークスイッチ、ＳＡＮスイッチ等が実装されており、ＥＭは、これらを含めたコンピュータシステムとしてのトポロジを把握することができる。ＶＭの移動指示を受けたＥＭは、他のＥＭに対して、対象となるストレージまでのネットワークコストの報告を要求し、報告を受け取ったＥＭは、移動対象のＶＭが動作している物理サーバのネットワークコストと、他のＥＭから報告されたネットワークコストとを比較した後、ネットワーク的に最適な位置にある物理サーバを選択し、この物理サーバのＩＰアドレスを移動先の物理サーバとしてＶＭ管理ソフトに通知する。

このように本発明では、ＥＭが自身の管理するトポロジを交換することによって、管理者にコンピュータのシステムトポロジを意識させることなく、ＶＭの移動先を自動的に選択することが可能となる。

Ａ．第１実施形態
図１は、本発明の第１実施形態によるコンピュータシステムの構成を示すブロック図である。図１には、３台のブレードエンクロージャからなるコンピュータシステムが示されている。図１において、１、２、３は、本発明を適用するコンピュータシステムの構成要素であるブレードサーバのエンクロージャを示す。また、４、５、６、７、８は、各エンクロージャに実装されているブレードサーバを示し、９、１０、１１は、各エンクロージャのＥＭを示す。１２、１３、１４は、各エンクロージャ１、２、３に実装されるＦＣ（Fibre Channel）スイッチを示し、１５、１６、１７、１８は、それぞれブレードサーバ４、６、７、８に実装されているＦＣ ＨＢＡ（Host Bus Adapter）を示す。

次に、１９、２０、２１、２２は、それぞれ、ＦＣ ＨＢＡ１５、１６、１７、１８のＦＲＵ（Field Replaceable Unit） ＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）を示す。同様に、２３、２４、２５は、ＦＣスイッチ１２、１３、１４のＦＲＵ ＥＥＰＲＯＭを示す。通常、ＦＲＵには、その装置固有の情報（製品名、製造年月日等）が書き込まれている。

次に、２６、２７、２８は、エンクロージャ１、２、３内のＩ２Ｃ（Inter-Integrated Circuit）バスを示し、各エンクロージャ１、２、３のＥＭ９、１０、１１は、各々、このＩ２Ｃバス２６、２７、２８を使用してエンクロージャ１、２、３内にあるＦＲＵ ＥＥＰＲＯＭの内容を読み出すことができる。また、各ＥＭ９、１０、１１は、エンクロージャ１、２、３内部のトポロジを、エンクロージャ内管理ＬＡＮ２９、３０、３１、及びＩ２Ｃバス２６、２７、２８を通じて把握することができる。また、ＥＭ９、１０、１１は、エンクロージャ外管理ＬＡＮ３６を通じて、エンクロージャ１、２、３外にある装置（本第１実施形態では、ＳＡＮストレージ３５）のＭＩＢ（Management Information Base）情報を採取することができる。

また、３２、３３、３４は、各エンクロージャ１、２、３に実装されるＬ２スイッチを示す。エンクロージャ１、２、３のＥＭ９、１０、１１は、各々、この管理ＬＡＮ２９、３０、３１を使用してエンクロージャ１、２、３内に実装されているＦＣスイッチ１２、１３、１４、及びＬ２スイッチ３２、３３、３４と通信し、情報の収集・設定等の管理を行うことができる。

次に、３５は、各ブレードサーバ４、５、６、７、８のＶＭ、及びホストＯＳが格納されているＳＡＮストレージを示す。各ブレードサーバ４、５、６、７、８のＶＭ（またはＯＳ）は、本ストレージ３５から起動するものとする。ＳＡＮストレージ３５と各ＥＭ９、１０、１１とは、エンクロージャ外管理ＬＡＮ３６を通じて互いに接続されている。なお、管理ＬＡＮを通じて装置を管理する方法は、一般的であり、本発明とは関係ない。

次に、３６は、エンクロージャ外管理ＬＡＮを示し、ＥＭ９、１０、１１は、このネットワーク網３６を使用して、互いに通信することができる。また、ＳＡＮストレージ３５の管理ＬＡＮも、同様に、このネットワーク網３６に接続されている。３７は、管理コンソール端末を示す。本管理コンソール端末３７には、一般的なＶＭの管理ソフト（ＶＭ管理クライアント）がインストールされている。また本管理コンソール端末３７からＥＭ９、１０、１１へＶＭ移動の通知を行うものとする。

管理者が、管理コンソール端末３７からＶＭの移動を指示すると、移動指示を受けたＥＭ９、１０、１１は、自身のエンクロージャ内にあるＬ２スイッチ３２、３３、３４のＡＲＰ（Address Resolution Protocol）テーブル、ＦＤＢ（Forwarding DataBase）を参照し、移動を指示されたＶＭが動作しているホストサーバ（移動元ホストサーバ）の検索を行う。次に、移動元ホストサーバが実装してあるエンクロージャのＥＭが、移動元ホストサーバからＳＡＮストレージ３５までのネットワークコストの算出を行う。最後に、移動元ホストサーバが実装してあるエンクロージャのＥＭが、他エンクロージャのＥＭに対して、各サーバからＳＡＮストレージ３５までのネットワークコストを問い合わせ、問い合わせ結果からＶＭの移動先に最適なサーバを選出する。

このようにして、本第１実施形態では、各エンクロージャ１、２、３のＥＭ９、１０、１１が、自立的に移動元ホストサーバの位置と、サーバが使用しているＳＡＮストレージ３５までのネットワークコストを算出し、複数のＥＭ間で通信を行うことによって、移動先ホストサーバを自動選出しているので、管理者がコンピュータシステムトポロジを意識することなく、性能的に最適な物理サーバへのＶＭの移動を実現できる。

図２は、本第１実施形態による、ＶＭ移動指示からＶＭ移動までの動作を説明するための概念図である。
なお、図２には、図１に、コマンドやデータの流れを追加したものである。始めに、ＶＭの移動指示が管理者３８からＶＭ管理クライアント３９に与えられると、管理コンソール端末３７内に備わる処理部であるＶＭ管理クライアント３９は、ＶＭが動作しているホストサーバ（以後、移動元ホストサーバという）のＩＰアドレスを自身のデータベースから検索する。一般に、ＶＭ管理クライアント３９は、各ＶＭとＶＭが動作している複数のホストサーバのＩＰアドレスとを管理しており、移動指示を受けたＶＭが動作しているホストサーバのＩＰアドレスを認識することは容易である。

ホストサーバのＩＰアドレスが判明したＶＭ管理クライアント３９は、各エンクロージャのＥＭ４０、４１、４２に対して、ＶＭ移動要求パケット４３を送付する。ＶＭ移動要求パケット４３には、移動元ホストサーバのＩＰアドレスが含まれる。ＶＭ移動要求パケット４３を受け取ったＥＭ４０、４１、４２は、エンクロージャ内管理ＬＡＮ４４、４５、４６を通じて、Ｌ２スイッチからＦＤＢ、及びＡＲＰテーブルを入手する。一般に、ＡＲＰテーブルは、ＩＰアドレス対ＭＡＣアドレスの関係性を示すテーブルであり、ＦＤＢは、ＭＡＣアドレス対ポートの関連性を示すテーブルである。

また、一般に、ブレードエンクロージャ内のＬ２スイッチは、ブレードサーバが接続する最初のネットワークスイッチであり、このＬ２スイッチのいずれかのポートに移動元ホストサーバが接続されている。各ＥＭ４０、４１、４２は、入手したＡＲＰテーブル、及びＦＤＢを参照し、受信したＶＭ移動要求パケットに含まれる移動元ホストサーバのＩＰアドレスが、これらのテーブルに含まれているかどうかを検証する。つまり、このＬ２スイッチのＡＲＰテーブルとＦＤＢとを参照することで、移動元ホストサーバのＭＡＣアドレスと実装位置が判明する。

次に、移動元ホストサーバ４７のＭＡＣアドレスを検出したＥＭ４０は、自らをＳＥＭ（Ｓｏｕｒｃｅ ＥＭ）としてＳＮＭＰ（Simple Network Management Protocol）を使用し、ブレードエンクロージャ外にあるスイッチ、ストレージ装置のＭＩＢ情報を入手する。一般に、標準的なＭＩＢ情報には、装置のインターフェース情報を含まれている。

例えば、Ｌ２スイッチであれば、ＡＲＰテーブルとＦＤＢ情報相当、及びポート速度情報が含まれ、ＦＣスイッチであれば、ポート対ＷＷＰＮ（World Wide Port Name）、及びポート速度情報が含まれている。このため、スイッチ、及びストレージ装置のＭＩＢ情報を入手することで、スイッチストレージ間のトポロジ及び性能を把握することができる。

図２に示す例では、各ブレードサーバのエンクロージャとＳＡＮストレージ４８間に外部スイッチは存在せず、エンクロージャ−ＳＡＮストレージ４８間が直結されている。従って、ＳＥＭ４０は、ＳＡＮストレージ４８のＭＩＢ情報から、各ポートの通信速度と各ポートに接続されているＷＷＰＮとを入手することとなる。

加えて、ＳＥＭ４０は、ブレードに実装されているメザニンカードのＦＲＵを読み出し、ＨＢＡ及びＮＩＣ（Network Interface Card）の製品名を入手する。さらに、ＳＥＭ４０は、エンクロージャ内管理ＬＡＮ４４を使用して、エンクロージャ内に実装されているＦＣスイッチ４９の情報を入手する。ＦＣスイッチ４９の情報とは、ＦＣスイッチ４９の各ポートの通信速度と、各ポートに接続されているＷＷＰＮとであり、通常、ＦＣスイッチの管理コンソールから、ＦＣスイッチの管理コマンドで採取することができる。

なお、本発明では、具体例として、ＳＮＭＰやＩ２Ｃバスを使用して、ポート情報やＦＲＵを採取したが、これらの情報の採取手段は、本発明と関係なく、他の手順によりポート情報とＦＲＵ情報とを採取してもよい。

ＳＥＭ４０は、入手したＦＣスイッチ、ＳＡＮストレージ４８のポート情報、及びＦＲＵ情報より、移動元ホストサーバ４７からＳＡＮストレージ４８までのネットワークコストを判断する。例として、図３にネットワークコスト算出の元になる表を示す。本第１実施形態では、ＳＥＭ４０は、移動元ホストサーバ４７からＳＡＮストレージ４８までのコストを、５＋５＝１０と算出する。

次に、ＳＥＭ４０は、ＶＭの移動先として最適なサーバを決定するため、他のエンクロージャのＥＭ（ＲＥＭ：Ｒｅｑｕｅｓｔｅｄ ＥＭ）４１、４２に対して、ＶＭ移動の問い合わせを行う。

図４は、本第１実施形態による、ＳＥＭ４０によるＶＭ移動の問い合わせ動作を説明するためのフローチャートである。また、図５は、本第１実施形態による、ＳＥＭ４０によるＶＭ移動の問い合わせ動作を説明するためのシーケンス図である。なお、図５に示すＳＥＭ５２、ＲＥＭ５３、ＲＥＭ５４は、図２に示すＥＭ４０、ＥＭ４１、ＥＭ４２を示している。

まず、図２に示すＥＭ（ＳＥＭ）４０（図５のＳＥＭ５２）は、移動元ホストサーバからＳＡＮストレージ（図１のＳＡＮストレージ３５、または図２のＳＡＮストレージ４８に相当）までのネットワークコストを算出する（ステップＳ１）。次いで、ＳＥＭ５２は、目標となるＳＡＮストレージまでのネットワークコストの算出を要求するパケット（ＤＭＲ：Distance Measurement Request）をＲＥＭ５３に対して発行する（ステップＳ２）。ＤＭＲは、ＶＭ移動要求パケット同様、目標となるＳＡＮストレージの管理ネットワーク用のＩＰアドレスを含んでいる。ＳＥＭ５２は、ＲＥＭ５３からのリプライがあったか否かを判定する（ステップＳ３）。

一方、ＤＭＲを受け取ったＲＥＭ５３は、ＳＥＭ５２と同様、スイッチ、ＳＡＮストレージのＭＩＢ情報、及びＦＲＵ情報を収集し、自身の管理するサーバから、目標となるＳＡＮストレージまでのネットワークコストを算出し、ＳＥＭ５２へリプライする。なおネットワークコストとは、エンクロージャからＳＡＮストレージ４８までの往復の通信時間の長短を表す値である。当該ネットワークコストは、エンクロージャからＳＡＮストレージ４８までの間に存在するスイッチ数や、当該スイッチの性能などによって定まる。

図６は、リプライパケットの構造を示す概念図である。リプライパケット５６には、サーバから目標となるＳＡＮストレージまでのネットワークコストを示すために、エンクロージャに実装可能なブレードサーバ分のエントリがあり、各サーバからのネットワークコストを格納する。本第１実施形態では、ＲＥＭ５３（ＥＭ４１）は、リプライパケット５７に、１５、及び２０をネットワークコストとして返却する。

リプライパケットを受信したＳＥＭ５２は（ステップＳ３のＮＯ）、他のＥＭが存在するか否かを判定し（ステップＳ５）、他のＥＭが存在する場合には（ステップＳ５のＹＥＳ）、ステップＳ２で、次のＲＥＭ５４（ＥＭ４２）に対して同様にＤＲＭを発行する。ＲＥＭ５４（ＥＭ４２）は、一台分のブレードサーバしか実装されていない。このため、この実装されていないブレードサーバは、目標となるＳＡＮストレージまでのネットワークパスが存在しない。

このように、目標となるＳＡＮストレージまでのネットワークパスが存在しない場合、ＲＥＭは、ネットワークコストの値をパスが存在しない事を明示する値“９９”としてリプライする。本第１実施形態では、ＥＭ４２は、リプライパケット５８に、１０、及び９９をネットワークコストとして返却する。

一方、ステップＳ２で、ＳＥＭ５２がＤＲＭを発行し、一定時間内にリプライが返ってこない場合には（ステップＳ３のＹＥＳ）、擬似的にＲＥＭからリプライされたネットワークコストを最大とし（ステップＳ４）、処理を継続する。

図５に示す例では、ＲＥＭ５５に対して発行したＤＲＭのリプライが、一定時間内にＳＥＭ５２に返ってこなかったため、ネットワークコスト＝９９を擬似的にＲＥＭ５５からのリプライパケットとして処理を継続している。

ＳＥＭ５２は、ＲＥＭ５３、５４、５５に対してのＤＲＭの発行、及びリプライの採取を完了すると、各ＲＥＭから報告されたネットワークコストを参考に、ＶＭの移動に最適なブレードサーバの順位付けを行う（ステップＳ６）。本第１実施形態では、ＲＥＭ５４のリプライパケットに含まれるネットワークコスト＝１０のサーバが最小となっており、これを最適と判断する。

なお、最適と判断するための基準は、ネットワークコストが最小、移動元ホストサーバと近いなどがあるが、基準の選択方法は、本発明とは直接関係がなく、いずれの基準を選んでもよい。

ＳＥＭ５２は、最適と判断するブレードサーバを管理しているＲＥＭ５４に対して、本パケットで指示するブレードにＶＭを移動してよいかどうかを問い合わせるパケットＳＳＲ（Server Select Request）を発行する（ステップＳ７）。一般に、サーバ上には、ＢＭＣと呼ばれるサーバ管理用のマイコンが実装されており、サーバの電力・温度・異常監視を行っている。

ＳＳＲを受信したＲＥＭ５４は、ブレードサーバ上のＢＭＣと通信し、指示されたブレードサーバの電力・温度・異常等を入手する。本第１実施形態では、ブレードサーバの状態を入手したＲＥＭ５４が、ＶＭを配置する上で問題があると判断しているため（ステップＳ８のＹＥＳ）、ＲＥＭ５４は、ＶＭ移動を拒否するリプライパケット（Rejected）を返している。ＶＭ移動拒否のリプライパケット（Rejected）を受け取ったＳＥＭ５２は、ステップＳ６に戻り、ステップＳ７で、二番目に低い（Next Nearest）ネットワークコスト＝１５のサーバを管理するＲＥＭ５３に対して、ＳＳＲを発行する。

ＳＳＲを受信したＲＥＭ５３は、ＲＥＭ５４と同様、対象となるブレードサーバのＢＭＣと通信し、ブレードサーバの状態を入手する。ＲＥＭ５３は、ＶＭを移動させる上で、ブレードサーバの状態に問題がないと判断すると（ステップＳ８のＮＯ）、ＶＭ移動受け入れのリプライパケット（Accepted）を、ＳＥＭ５２に返す。ＶＭ移動受け入れのパケットには、対象となるブレードサーバが使用しているＩＰアドレス（物理サーバ番号）が含まれており、ＳＥＭ５２は、これをＶＭ移動要求パケット４３のリプライとして、ＶＭ管理クライアント３９に返却する（ステップＳ９）。

上述したように、本第１実施形態によれば、外部装置のＭＩＢとエンクロージャ内部の装置情報とを用いたネットワークコストの算出方法、及びＥＭ間通信を用いたＶＭ移動先選出方法を用いることにより、コンピュータシステム管理者は、ＶＭの移動を行う際にコンピュータシステムのネットワークトポロジを確認することなく、自動的にネットワーク的に最適な位置にＶＭを再配置することができる。

ここで、管理コンソール端末３７内のＶＭ管理クライアント３９は、ＳＥＭ５２より、ＶＭ移動要求パケット４３のリプライを受信すると、当該移動先のブレードサーバが使用しているＩＰアドレスやネットワークコストなどの情報と、ＶＭの識別ＩＤなどを対応付けて記憶する。これにより、当該記憶する情報をユーザが出力指示するなどして確認することで、移動対象となるＶＭがどの物理サーバ上で動作しているか、簡単には把握できるようになる。また、このような処理により、管理者は、現在ＶＭが動作している物理サーバとＳＡＮストレージ間の性能を簡単には把握できる。

Ｂ．第２実施形態
次に、本発明の第２実施形態について説明する。
図７は、本第２実施形態によるコンピュータシステムの構成を示すブロック図である。本第２実施形態において、その基本的構成は上記の通りであるが、エンクロージャ外部に接続される装置についてさらに工夫している。なお、図１に対応する部分には同一の符号を付けて説明を省略する。

図７において、６５、６６は、外部に接続された外部ＦＣスイッチであり、本構成が図１とは異なる。各エンクロージャ１、２、３は、外部ＦＣスイッチ６５、６６を介して、ＳＡＮストレージ３５と接続されている。また、外部ＦＣスイッチ６５、６６、ＳＡＮストレージ３５の管理ＬＡＮポートは、エンクロージャ外管理ＬＡＮ３６を通じて、各ＥＭ９、１０、１１と接続されている。

図７の構成のように、ＳＡＮストレージ３５とエンクロージャ１、２、３間に外部ＦＣスイッチ６５、６６が配置されている構成においても、本発明は適用可能である。すなわち、ＳＥＭ、及びＲＥＭがネットワークコストを算出する際に、エンクロージャ外管理ＬＡＮ３６を通じて外部に接続された装置のＭＩＢが採取されるが、これがネットワークコスト算出に使用される。

図８は、本第２実施形態でのコストテーブルの一例を示す概念図である。このテーブルを元にネットワークコストを算出すると、移動元ホストサーバのネットワークコストは、５＋５＋５＝１５となる。ＥＭ１０のＤＲＭに対するリプライパケットに含まれるネットワークコストは、（２０，２５）、ＥＭ１１のＤＲＭに対するリプライパケットに含まれるネットワークコストは、（２０，９９）となる。

入手したネットワークコストを元に、ＥＭ９は、ＳＳＲをＥＭ１０に対して発行する。図１と同じ条件でブレードサーバが動作している場合、ＥＭ１０は、ＥＭ９に対して、ＶＭ移動受け入れのパケットを返却することとなる。

このように、本第２実施形態では、外部ネットワーク装置のＭＩＢ情報もネットワークコストの算出条件としているので、より大規模なコンピュータシステムに対しても、管理者は、ＶＭの移動の際に、コンピュータトポロジを意識する必要がないという効果が得られる。

上述した本第１、第２実施形態によれば、内蔵Ｌ２スイッチのＡＲＰテーブル及びＦＤＢを使用して移動元ホストサーバの物理実装位置を自動判定しているので、システム管理者は、移動対象のＶＭが動作している移動元ホストサーバが、物理的にどの位置にあるかを意識する必要がない。

また、ＥＭが外部装置のＭＩＢ、及びエンクロージャ内部構成情報を取得し、自動的にサーバ−ＳＡＮストレージ間のネットワークコストを算出しているので、システム管理者は、移動元ホストサーバからＳＡＮストレージ間のトポロジを意識する必要がない。

さらに、複数あるＥＭが互いに通信して、管理者の決めたルールに従い自動的に移動先のサーバを選出するので、システム管理者は、移動先のサーバを決めるためにシステムのトポロジを調べる必要がない。

１、２、３ エンクロージャ
４、５、６、７、８ ブレードサーバ
９、１０、１１ ＥＭ
１２、１３、１４ ＦＣスイッチ
１５、１６、１７、１８ ＦＣ ＨＢＡ
１９、２０、２１、２２ ＦＲＵ ＥＥＰＲＯＭ
２３、２４、２５ ＦＲＵ ＥＥＰＲＯＭ
２６、２７、２８ Ｉ２Ｃバス
２９、３０、３１ エンクロージャ内管理ＬＡＮ
３２、３３、３４ Ｌ２スイッチ
３５ ＳＡＮストレージ
３６ エンクロージャ外の管理ＬＡＮ
３７ 管理コンソール端末

Claims (6)

1. ネットワーク上のストレージに格納されている論理サーバを起動し、複数の物理サーバ上のいずれかで動作させている論理サーバを、他の物理サーバに移動させる論理サーバ運用システムあって、
   前記複数の物理サーバは、各々、
   論理サーバの移動指示を契機として、各物理サーバから前記ストレージまでのネットワークコストを集計し、前記各物理サーバから前記ストレージまでのネットワークコストに基づいて、前記論理サーバの移動対象として好適な物理サーバを選択する論理サーバ運用管理手段を備えていることを特徴とする論理サーバ運用システム。
2. 前記論理サーバ運用管理手段は、
   移動を指示された論理サーバが動作している移動元ホスト物理サーバを検索する検索手段と、
   前記検索手段によって検索された移動元ホスト物理サーバから前記ストレージまでのネットワークコストを算出する算出手段と、
   前記移動元ホスト物理サーバ以外の物理サーバに対して、それぞれの物理サーバから前記ストレージまでのネットワークコストを問い合わせる問い合わせ手段と、
   移動元ホスト管理サーバから前記ストレージまでのネットワークコストと、問い合わせ結果であるそれぞれの物理サーバから前記ストレージまでのネットワークコストとに基づいて、前記論理サーバの移動先に最適な物理サーバを選択する選択手段と
   を備えることを特徴とする請求項１に記載の論理サーバ運用システム。
3. 前記算出手段は、
   前記複数の物理サーバに対する外部装置のＭＩＢ情報と前記複数の物理サーバが収容されるエンクロージャ内部の装置情報とに基づいて、それぞれの物理サーバから前記ストレージまでのネットワークコストを算出する
   ことを特徴とする請求項１または２に記載の論理サーバ運用システム。
4. 前記論理サーバの移動先に最適な物理サーバに対して、前記論理サーバを移動してよいかを問い合わせる移動問い合わせ手段と、
   前記移動問い合わせに対して許可応答が得られると、前記論理サーバに対して、前記移動先の物理サーバを指定する移動先指定手段と
   を更に備えることを特徴する請求項１から３のいずれかに記載の論理サーバ運用システム。
5. 前記複数の物理サーバは、
   エンクロージャ内に装着されたブレードサーバであり、
   前記論理サーバ運用管理手段は、
   前記エンクロージャを管理するエンクロージャマネージャの一機能である
   ことを特徴とする請求項１から４のいずれかに記載の論理サーバ運用システム。
6. ネットワーク上のストレージに格納されている論理サーバを起動し、複数の物理サーバ上のいずれかで動作させている論理サーバを、他の物理サーバに移動させる論理サーバ運用方法あって、
   前記論理サーバが動作している移動元ホスト物理サーバが、論理サーバの移動指示を契機として、自サーバから前記ストレージまでのネットワークコストを算出するステップと、
   他の物理サーバから前記ストレージまでのネットワークコストを取得するステップと、
   前記自サーバから前記ストレージまでのネットワークコストと、前記他の物理サーバから前記ストレージまでのネットワークコストとに基づいて、前記論理サーバの移動先に最適な物理サーバを選択するステップと
   を含むことを特徴とする論理サーバ運用方法。

Images