JP6285906B2 - ミドルウェアマシン環境内で仮想マシン移行用のスケーラブルなシグナリングメカニズムを提供するシステムおよび方法 - Google Patents

Description

発明の分野
本発明は、一般にコンピュータシステムに関し、特に、コンピュータシステムの仮想化をサポートすることに関する。

背景
より大きなクラウド・コンピューティング・アーキテクチャが導入されることに連れて、従来のネットワークおよび記憶装置に関連した性能および管理上のボトルネックは、深刻な問題となっている。インフィニバンド（ＩＢ）（登録商標）技術は、クラウド・コンピューティング骨組みの基礎としてその展開が増加しつつである。本発明の実施形態は、このような一般的な領域を対処しようとするものである。

概要：
本明細書は、仮想環境内でシグナリング方法をサポートすることができるシステムおよび方法を記載している。１つ以上の物理サーバ上の管理ドメインは、マッピングテーブルを備えることができる。管理ドメインは、サブネット管理者からのメッセージを受信するように稼働する。そのメッセージは、ネットワーク内のパス記録変更イベント、たとえばネットワーク内の仮想マシン（ＶＭ）移行イベントを表わす。次に、管理ドメインは、マッピングテーブルに基づいて、管理ドメインに関連付けられた１つ以上の仮想マシンに受信したメッセージを転送することができる。

本発明の実施形態に係る、仮想環境内で仮想マシンをライブ移行する例を示す図である。 本発明の実施形態に係る、仮想環境内でシグナリング方法をサポートする例を示す図である。 本発明の実施形態に係る、仮想環境内でシグナリング方法を実行する例を示す図である。 本発明の実施形態に係る、仮想環境内で仮想マシンのライブ移行をサポートするフローチャート例を示す図である。

詳細の説明
本発明は、例として示され、限定とはならない。添付図面の図において、同様の参照符号は、同様の要素を示している。注意すべきことは、本開示において、「ある」または「１つ」または「いくつか」の実施形態を言及するときに、必ずしも同じ実施形態に限定されることがなく、少なくとも１つの実施形態を意味することである。

以下の本発明の説明において、インフィニバンド（ＩＢ）ネットワークを高性能ネットワークの一例とする。他の種類の高性能ネットワークが制限なく使用できることは、当業者にとって明らかであろう。また、以下の本発明の説明において、Ｘｅｎ仮想モデルを用いて仮想モデルの一例とする。なお、他の種類の仮想モデルが制限なく使用できることは、当業者にとって明らかであろう。

本明細書は、ネットワーク内で仮想マシン（ＶＭ）のライブ移行をサポートできるシステムおよび方法を記載している。

本発明の実施形態によれば、仮想化は、クラウド・コンピューティング時にリソースの有効利用および弾性割当てに有益であり得る。ライブ移行は、アプリケーション透過方法で物理サーバの間に仮想マシン（ＶＭ）を移動させることにより、リソースの使用を最適化することができる。したがって、仮想化は、ライブ移行を通じて、リソースをオンデマンドで、安定的にかつ弾性的に提供することができる。

インフィニバンド（ＩＢ）アーキテクチャ
ＩＢアーキテクチャは、シリアルポイントツーポイント全二重技術である。ＩＢネットワークは、スイッチとポイントツーポイントリンクとを用いて相互接続される一連のホストからなるサブネットとも呼ばれる。ＩＢサブネットは、少なくとも１つのサブネットマネージャ（ＳＭ）を含むことができる。このサブネットマネージャは、ネットワークの初期化および起動に関与し、サブネット内のすべてのスイッチ、ルータおよびホスト側チャネルアダプタ（ＨＣＡ）の構成を有する。

ＩＢは、リモートダイレクトメモリアクセス（ＲＤＭＡ）および従来の送受信動作の両方を提供するために、多くの転送サービスをサポートしている。使用された転送サービスとは独立して、ＩＢのＨＣＡは、キューペア（ＱＰ）を用いて通信する。ＱＰは、通信の確立時に作成され、ＱＰ番号、ＨＣＡポート、宛先ＬＩＤ、キューサイズおよび転送サービスなどの一連の与えられた初期属性を有してもよい。ＨＣＡは、多くのＱＰを処理することができる。各々のＱＰは、送信キュー（ＳＱ）および受信キュー（ＲＱ）を含むキューペアからなる。このようなキューペアは、通信に関与する各エンドノードに存在する。受信キューは、リモートノードから受信したデータをどのように処理するかに関する情報を保存するが、送信キューは、リモートノードに転送される作業要求を保存する。ＱＰに加えて、各ＨＣＡは、一連の送受信キューに関連付けられた１つ以上の完了キュー（ＣＱ）を有する。ＣＱは、送受信キューに転送された作業要求の完了通知を保有する。複雑な通信は、ユーザに見られないが、ＱＰ状態情報は、ＨＣＡに保存される。

入力／出力（Ｉ／Ｏ）の仮想化
Ｉ／Ｏの仮想化（ＩＯＶ）は、基盤となる物理リソースにＶＭがアクセスできるようにすることで、Ｉ／Ｏの可用性を提供することができる。トラフィックの記憶およびサーバ間の通信が同時に行うと、単一のサーバに与える負荷が大きくなり、サーバのＩ／Ｏリソースを溢れさせる可能性があり、その結果、プロセッサがデータを待っているようにバックログおよび待機状態を引起す。ＩＯＶは、Ｉ／Ｏ要求数の増加に伴う可用性を提供することができ、最新のＣＰＵの仮想化で見られる性能のレベルに匹敵するように、（仮想化された）Ｉ／Ｏリソースの性能、拡張性および柔軟性を向上させることができる。

さまざまな種類のＩＯＶ技術、たとえば、エミュレーション、準仮想化、直接割当て（ＤＡ）および単一のルート−Ｌ／Ｏ仮想化（ＳＲ−ＩＯＶ）が存在し得る。これらのＩＯＶ技術の中では、ＳＲ−ＩＯＶは、固有性能に近い性能に維持しながら、複数のＶＭから単一の物理デバイスに直接アクセスすることを可能にする手段を、ＰＣＩエクスプレス（ＰＣＩｅ）仕様に拡張することができる。このため、ＳＲ−ＩＯＶは、優れた性能および拡張性を提供することができる。

ＳＲ−ＩＯＶは、ＰＣＩｅデバイスに複数の仮想デバイスを公開させ、各ゲストに１つの仮想デバイスを割当てることによって、複数のゲストに共有されることができる。各ＳＲ−ＩＯＶデバイスは、少なくとも１つの物理機能（ＰＦ）と、それに関連付けられた１つ以上の仮想機能（ＶＦ）を有する。ＰＦは、仮想マシンモニタ（ＶＭＭ）またはハイパーバイザによって制御される標準ＰＣＩｅ機能であり、ＶＦは、軽量化したＰＣＩｅ機能である。各ＶＦは、独自のベースアドレス（ＢＡＲ）を有し、特異リクエスタＩＤが割当てられている。このリクエスタＩＤは、Ｉ／Ｏメモリ管理ユニット（ＩＯＭＭＵ）に異なるＶＦに行くトラフィック流れ／異なるＶＦからのトラフィック流れを識別させることを可能にする。ＩＯＭＭＵはまた、メモリを適用したり、ＰＦとＶＦとの間の転換を中断したりする。

ＳＲ−ＩＯＶモデルは、たとえば、ポート共有モデルおよび仮想スイッチモデルなどの異なる種類のモデルを有する。ポート共有モデルにおいて、すべてのＶＦが単一のポートアドレスおよび単一のＱＰ名前空間を共有し、単一のＨＣＡポートのみがネットワークに公開される。仮想スイッチモデルにおいて、各ＶＦが唯一のポートアドレスおよび唯一のＱＰ名前空間を有する仮想ＨＣＡであり、デバイス上の各ＶＦのＨＣＡがネットワークに公開される。したがって、仮想スイッチモデルは、より複雑なハードウェアを有するＩＯＶを簡素化することができる。

ＳＲ−ＩＯＶ可能なデバイスを使用すれば、固有性能に近い性能をもたらすことができ、拡張性を向上させることができる。一方、ＳＲ−ＩＯＶは、ライブ移行およびチェックポイント／再起動メカニズムとは完全な互換性がない可能性がある。

ハードウェアアドレスの割当ておよび仮想マシン（ＶＭ）のライブ移行
本発明の実施形態によれば、各物理ＩＢデバイスは、ローカル識別子（ＬＩＤ）とグローバル唯一の識別子（ＧＵＩＤ）との２つのアドレスを割当てることができる。ＬＩＤは、サブネット内でＩＢパケットのルーティングに使用することができる。ＧＵＩＤは、異なるサブネットの間にＩＢパケットのルーティングに使用することができる。さらに、ＧＵＩＤは、ＩＢネットワーク内で物理ＩＢデバイスを唯一に表わすことのできるハードウェアアドレスである。

ＳＲ−ＩＯＶをＩＢネットワークに実装するために使用されるポート共有モデルにおいて、各ＶＦは、独自の仮想ＧＵＩＤ（ｖＧＵＩＤ）を有してもよく、物理サーバ上でＰＦとＬＩＤを共有してもよい。本明細書においては、各仮想のＧＵＩＤ（ｖＧＵＩＤ）は、ＶＦを唯一に表わすことのできるハードウェアアドレスである。

図１は、本発明の実施形態に係る、仮想環境内で仮想マシンのライブ移行例を示す図である。図１に示すように、ＩＢネットワーク１００は、サブネットマネージャ（ＳＭ）１１０と、ホストＡ１０１およびホストＢ１０２などの複数のホストを含むことができる。

各ホストは、ＨＣＡを使用し、ユーザドメイン内で１つ以上の仮想マシン（ＶＭ）を管理する管理ドメイン（または特権ドメイン）をサポートするＶＭＭを含むことができる。図１に示すように、ホストＡ１０１は、ＨＣＡ１１７を使用するＶＭＭ Ａ １１５を含む。ＶＭＭ Ａ １１５は、ＤｏｍＵ１１３を管理するＤｏｍ０ １１１をサポートすることができる。同様に、ホストＢ１０２は、ＨＣＡ１１８を使用するＶＭＭ Ｂ １１６を含む。ＶＭＭ Ｂ １１６は、ＤｏｍＵ１１４を管理するＤｏｍ０ １１２をサポートすることができる。

本発明の実施形態によれば、たとえばＸｅｎモデルのような仮想モデル内でＶＭとゲストドメイン（すなわちＤｏｍＵ）との間に一対一の関係が存在することができる。さらに、ＶＭＭ／Ｄｏｍ０の制御下でＶＭをホストする物理サーバ上のリソースコンテナとしてのＤｏｍＵは、ＶＭのＸｅｎ概念を表わすのに使用することができる。その上に、一対多または多対一の関係は、ＶＭと他の仮想モデル内のゲストドメインとの間に制限なく存在してもよい。たとえば、一ゲストドメインは、異なるＶＭをホストすることが可能である。

たとえばＶＭａ１０３のようなＶＭは、１つのホストたとえばホストＡ１０１から別のホストたとえばホストＢ１０２に（ＶＭａ１０４として）移行することができる。移行前に、ＶＭａ１０３には、ＶＦ１１５のようなＶＦを加えることができる。ＶＦ１１５は、たとえばＱＰＡ１０７のようなキューペアに接続されている。さらに、ＶＭａ１０３は、ＶＭｃ１０５と通信することができる。ＶＭｃ１０５は、ＱＰｃ１０９に関連している。移行後、ＶＭａ１０４には、たとえばＶＦ１１６のような新しいＶＦを加えることができる。ＶＦ１１６は、ＱＰｃ１０９との通信を再構築することができるＱＰａ′１０８のようなキューペアに関連付けられる。

本発明の実施形態によれば、異なるハードウェアアドレス割当てモデルは、たとえばＶＦ１１５のようなＶＦにｖＧＵＩＤを割当てるために使用することができる。

一例では、サブネットマネージャ（ＳＭ）１１０は、Ｄｏｍ０ １１１上のＰＦにＬＩＤおよびＧＵＩＤを割当てることに加えて、ＶＦ１１５にｖＧＵＩＤを割当てるために、動的割当てモデルを使用することができる。動的割当てモデルは、固有ＩＢにアドレスを割当てることと同様である。

サブネットの初期化中、Ｄｏｍ０ １１１上のＰＦは、ＶＦ１１５などのＶＦに割当てられる可能性のあるｖＧＵＩＤをＳＭ１１０から照会することができる。それに従い、ＳＭ１１０は、対応するｖＧＵＩＤを生成し、要求元のＰＦに応答して送信することができる。その後、ＰＦは、受信したｖＧＵＩＤをＤｏｍ０ １１１内のＧＵＩＤ管理インデックステーブル１２１に保存することができる。ＧＵＩＤ管理インデックステーブル１２１において、各ＶＦは、指定されたインデックスと関連付けられる。

動的割当てモデルを使用するとき、割当てられたＶＦとＶＭとの関係は一定ではない。図１に示すように、ＶＭａ１０３がホストＡ１０１からホストＢ１０２に移行した後、宛先サーバすなわちホストＢ１０２から新しいＶＦ１１６をＶＭａ１０４に割当てることができる。その結果、ＶＭａ１０４に関連付けられているｖＧＵＩＤは、ホストＢ１０２のＤｏｍ０ １１２内のＧＵＩＤ管理インデックステーブル１２２から取得されたため、変更する。

動的割当てモデルは、ＳＭ１１０を用いてＶＦおよびＰＦの両方にアドレスを割当てるため、単純である。一方、ＶＭａ１０３に関連付けられたｖＧＵＩＤは、ＶＭ移行後に保存されない場合がある。よって、ＶＭ移行後、（たとえば、サブネットマネージャ（ＳＭ）１１０上の）サブネット管理者（ＳＡ）に照会を送り、新ｖＧＵＩＤのためにパス情報を取得する必要がある。また、ｖＧＵＩＤがＶＭに固定されていない場合、パス情報がＳＡから得られる前に、リモートＶＭに現在使用されているｖＧＵＩＤを再検出する必要がある。このようなマッピングは、ＩＰアドレスに関連付けられたハードウェアアドレスを決定することができるアドレス解決プロトコル（ＡＲＰ）演算を使用することを含んでもよい。これらの演算は、ＩＢ、ＶＦを見出すときに追加的遅延を導入する場合がある。特に、ライブ移行が実行されるとき、この遅延は、サービスダウンの総時間を増加させる可能性がある。

別の例では、サブネットマネージャ（ＳＭ）１１０は、静的割当てモデルを用いて、ＶＦ１１５にｖＧＵＩＤを割当てることができる。この静的割当てモデルは、場所に関係なくＶＭに割当てられたｖＧＵＩＤを保存することができるが、より複雑であり、固有ＩＢアドレスの割当てとは異なる。ＶＭのライフサイクルに亘って静的ｖＧＵＩＤを持たせるために、静的割当てモデルは、ＳＭ１１０に、またはＳＭおよび特権ドメイン（Ｄｏｍ０）の組み合わせに依存することができる（ＳＭおよびＤｏｍ０を組み合わせる手法は、好ましい解決策である。その理由は、ＳＭのみを使用して静的ｖＧＵＩＤを維持する場合、過剰な管理メッセージが生成される可能性があるからのである）。

静的割当てモデルを使用する場合、たとえばＶＭａ１０３のようなＶＭがインスタンス化されると、ＶＭ構成の一部として保存されているｖＧＵＩＤがＶＭに割当てられる。たとえばＶＦ１１５のようなＶＦがＶＭａ１０３に加えられると、Ｄｏｍ０ １１３は、ＶＭの構成からｖＧＵＩＤを読取り、読取ったｖＧＵＩＤをＧＵＩＤ管理インデックステーブル１２１に書込むことができる。同時に、このイベントは、最新のｖＧＵＩＤをＬＩＤマッピング１２０に書込むことによってＳＭ１１０を更新するための管理メッセージをトリガーする。

ＶＭａ１０３をホストＡ１０１からホストＢ１０２に移行した後、ＶＭａ１０４に加えられたＶＦ１１６は、ＶＭａ１０３に加えられたＶＦ１１５に関連付けられているｖＧＵＩＤを保存することができる。

本発明の実施形態によれば、静的割当てモデルは、ＶＭのライブ移行をサポートするために、さらなる拡張を必要とする場合がある。図１に示すように、移行されるＶＭａ１０３の通信ピアであるＶＭｃ１０５は、ＬＩＤ−ｖＧＵＩＤマッピングにおける変化を察知していない場合がある。よって、ＶＭｃ１０５は、キャッシュされた古いパス情報を用いて移行されたＶＭａ１０３との通信を継続する可能性がある。その結果、ピア同士は、新しい場所に移動されたＶＭａ１０４と連絡取れなくなる可能性がある。

その原因は、移行されたＶＭａ１０４に関連付けられたｖＧＵＩＤがそのままに維持されているにもかかわらず、宛先サーバから異なるＬＩＤをもらった新しいＶＦ１１６が移行されたＶＭａ１０４に加えられたからである。さらに、ＳＭ１１０および移行されたＶＭａ１０４は、最新のＬＩＤ−ｖＧＵＩＤペアを持っているにもかかわらず、ＶＭｃ１０５は、最新のパス情報を通知されない場合がある。したがって、移行されるＶＭピア内にキャッシュされ、以前に確立されたＬＩＤ−ｖＧＵＩＤペアは、無効になったため、移行されたＶＭのピア同士は、移行されたＶＭと連絡取れなくなる可能性がある。

シグナリングメカニズム
本発明の実施形態によれば、ＶＭ移行後ネットワーク接続性を維持するシグナリングメカニズムを実現することができる。さらに、シグナリング方法は、管理メッセージのオーバーヘッドを低減するために、ホストされるＶＭにかかわらず、同一のイベントを物理サーバに一回のみ転送することができるように、最適化されることができる。

本発明の実施形態に係る、仮想環境内でシグナリング方法をサポートする例を示す図である。図２に示すように、ＩＢネットワーク２００は、サブネットマネージャ（ＳＭ）２１０と、ホストＡ２０１およびホストＢ２０２などの複数のホストを含むことができる。ピア同士のＶＭｂ２１２と通信しているＶＭａ２１１のようなＶＭは、１つのホストたとえばホストＡ２０１から別のホストたとえばホストＢ２０２に（ＶＭａ′２１３として）移行することができる。

図２に示すように、ライブ移行の前に、ＶＭａ２１１は、ｖＧＵＩＤ Ａ ２３１に割当てられ、ホストＡ２０１上の他のＶＭとＬＩＤ Ａ ２２１を共有することができる。ＳＭ２１０は、このような関係をエントリとしてＬＩＤ−ｖＧＵＩＤマッピングテーブル２２０に保存することができる。

静的割当てモデルを使用する場合、ＶＭａ２１１のライブ移行の後に、ＶＭａ′２１３は、ｖＧＵＩＤ Ａ ２３１を保存することができ、ホストＢ２０２上の他のＶＭと異なるＬＩＤ Ｂ ２２２を共有することができる。パス再設定／不設定通知は、ＳＭ２１０たとえばＳＡエージェントキャッシュでＬＩＤ／ｖＧＵＩＤマッピング２２０を更新するために使用されることができる。ＳＭ２１０は、ＩＢネットワーク２００内でこのような変更またはイベントを検出することができ、それに応じてＬＩＤ−ｖＧＵＩＤマッピングテーブルを更新することができる。

さらに、ＳＭ２１０は、最新のパス情報を通信ピア同士に通知することができる。たとえば、ＳＭ２１０は、パス再設定／不設定通知を用いて、ＶＭａ２１１の移行およびＬＩＤ−ｖＧＵＩＤマッピング２２０の変更をホストＢ上のＶＭｂ２１２に通知することができる。

図３は、本発明の実施形態による、仮想環境内でシグナリング方法を実施する例を示す図である。図３に示すように、ＩＢネットワーク３００は、サブネットマネージャ（ＳＭ）３１０と、ホスト３０１とを含むことができる。ホスト３０１は、仮想マシンモニタ（ＶＭＭ）３１５およびホスト側チャネルアダプタ（ＨＣＡ）３１７を含む。ＶＭＭ３１５は、ユーザドメインＤｏｍＵ３１３内で１つ以上の仮想マシン（ＶＭ）を管理する管理ドメイン（または特権ドメイン）Ｄｏｍ０ ３１１をサポートする。

さらに、システムは、すべてのＭＡＤトラフィックを、管理ドメインに関連付けられた物理機能（ＰＦ）を介してトンネルされるように、設定することができる。図３に示すように、たとえばＰＦ３０６を含むホストＡ３０１上の権限ドメインＤｏｍ０ ３１１は、たとえばＶＭａ３０３などの複数の仮想マシン（ＶＭ）をサポートすることができる。また、ＶＭａ３０３には、ＱＰａ３０７に関連付けられているＶＦ３０５を加えることができる。さらに、ＶＭａ３０３は、ＩＢネットワーク３００内で（ＶＭ移行イベント３１４として示された）ライブ移行を実行することができるＶＭピア（図示せず）と通信することができる。

本発明の実施形態によれば、シグナリング方法は、イベント登録段階とイベント転送段階との２つの段階を含むことができる。

イベント登録段階では、各物理サーバは、パス再設定イベント通知を得るために、登録することができる。図３に示すように、ホストＡ３０１は、ＰＦ３０６に関連付けられた物理ポートのＧＵＩＤを用いて、サブネットマネージャ（ＳＭ）３１０またはサブネット管理者（ＳＡ）に登録できる。物理ポートのＧＵＩＤがＳＭ３１０に正常に登録された後、サブネットマネージャ（ＳＭ）３１０は、物理サーバすなわちホスト３０１を承認（ＡＣＫ）する。

イベント転送段階は、ＶＭ移行イベント３１４が発生時に実行されることができる。ＳＭ３１０は、ＬＩＤ−ｖＧＵＩＤマッピング３２０の変更を検出し、すべての登録されたサーバに通知することができる。たとえば、ＳＭ３１０は、最新のＬＩＤ−ｖＧＵＩＤマッピングを持つパス再設定トラップをホストＡ３０１を含むすべての登録されたサーバに送信することができる。そして、ホストＡ３０１上の管理ドメインＤｏｍ０ ３１１は、マッピングテーブル３１６に登録されたＧＵＩＤに基づいて、受信された通知を関与するＶＭに転送することができる。

新しいＶＭの作成イベントまたはＶＭの再起動イベント（ＶＭが同一のサーバでシャットダウンされおよび再起動されるとき）にパス再設定トラップがトリガーされないようにするため、ＳＭ３１０は、以下のアルゴリズム１を使用してＬＩＤ−ｖＧＵＩＤマッピング３２０の変更を確認することができる。

ＶＭのシャットダウンまたはＶＭの移行によってｖＧＵＩＤがＳＭ３１０から削除される場合、パス情報がＶＭ作成イベントおよびＶＭ移行イベントを識別するために使用することのできる一時的な記憶であるパス再設定トラップテーブルに追加されることができる。ｖＧＵＩＤがＳＭ３１０に追加されたときに既にパス再設定トラップテーブルに存在している場合、関連付けられたパス情報がパス再設定トラップテーブル内のエントリと比較される。ＬＩＤが異なると、ＶＭ移行が起こったことを示している。そして、この新たに追加されたｖＧＵＩＤおよびその関連パス情報は、パス再設定トラップテーブルにカプセル化され、ホストＡ３０１を含むすべての登録されたサーバに送信されることができる。その後、パス再設定トラップテーブルからｖＧＵＩＤエントリを削除することができる。

ＳＭ３１０にボトルネックが発生しないようにするために、物理ポートのＧＵＩＤ（すなわち、ＶＦ３０５のｖＧＵＩＤの代わりにＤｏｍ０ ３１１のＧＵＩＤ）をＳＭ３１０にイベント登録を申込むために使用されることができる。そして、Ｄｏｍ０ ３１１は、ホストしているＶＭに受信された通知を配布する。

以下は、Ｄｏｍ０３１１に実装され、受信されたパス再設定トラップ通知を稼働しているＶＭに転送するアルゴリズム２を示している。

イベント登録を申込むために物理ポートＧＵＩＤを使用するだけで、生成された管理メッセージ（ＭＭＯ）を低減することができる。

さらに、Ｄｏｍ０ ３１１によって転送された通知がホスト内の各ＶＭによって受信されると、以下のアルゴリズム３は、キャッシュされたパス情報を再設定するために実行されることができる。

たとえば、ホストＡ３０１は、キャッシュされたパス情報を抽出することができ、抽出したパス情報をパス再設定トラップにカプセル化されたパス記録と比較することができる。マッチしたｖＧＵＩＤエントリが存在しても異なるＬＩＤを持つ場合、ホストスタック内にキャッシュされたパス情報を更新してもよい。

このようにして、サブネットマネージャ（ＳＭ）３０１は、関連付けられたｖＧＵＩＤに基づき、ＶＭの全ライフサイクルを追跡することができる。たとえば、サブネットマネージャ（ＳＭ）３０１は、オーバーヘッドを低減するかつ拡張性を向上させる最適階層アルゴリズムを用いて、各ＶＭの現在位置を追跡することができ、ＶＭが移行される度に新しいアドレス情報を関連する通信ピア同士に通知することができる。

さらに、ＶＭ／ｖＨＣＡの他の特徴、たとえば中断状態および移行状態は、ｖＧＵＩＤが現在任意のファブリックエンドポイントに関連付けられているか否かに係らず、関係するものに反映されることができる。

図４は、本発明の実施形態に係る、仮想環境内で仮想マシンのライブ移行をサポートするフローチャート例を示す図である。図４に示すように、ステップ４０１で、システムは、１つ以上の物理サーバ上の管理ドメインにマッピングテーブルを提供することができる。次いで、ステップ４０２で、管理ドメインは、サブネット管理者からの、ネットワーク内に仮想マシン（ＶＭ）移行などのパス記録変更イベントを表わすメッセージを受信することができる。さらに、ステップ４０３で、管理ドメインは、マッピングテーブルに基づいて、受信したメッセージを管理ドメインに関連付けられた１つ以上の仮想マシンに転送することができる。

本発明は、１つ以上のプロセッサとメモリおよび／または本開示の教示に従ってプログラムされたコンピュータ読取り可能な記録媒体とを含む１つ以上の従来の汎用または専用デジタルコンピュータ、コンピューティングデバイスまたはマシンまたはマイクロプロセッサを用いて、好都合的に実施されることができる。ソフトウェアの当業者にとって明らかであろうように、ソフトウェアの適切なコーディングは、本開示の教示に基づいて熟練したプログラマによって容易に準備することができる。

いくつかの実施形態では、本発明は、コンピュータプログラム製品を含む。このコンピュータプログラム製品は、本発明のいずれかのプロセスを実行するようにコンピュータをプログラムさせるために使用することのできる指令を、その上に／中に記憶させる記録媒体またはコンピュータ読取可能な媒体である。この記録媒体は、フロッピーディスク（登録商標）、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブおよび光磁気ディスクを含む任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気または光カード、（分子メモリＩＣを含む）ナノシステム、または指令および／またはデータの格納に適した任意の種類の媒体またはデバイスを含むことができるが、これらに限定されない。

本発明の上記説明は、例示および説明のために提供されている。本発明を網羅的であることにまたは開示された形態に厳密に限定することを意図するものではない。多くの修正および変更は、当業者にとって明らかであろう。実施形態は、本発明の原理およびその実際の応用を説明するために選択され説明された。よって、当業者がさまざまな実施形態により本発明を理解し、考えられる特定の用途に適したさまざまな修正をできるようになる。なお、本発明の範囲が添付の特許請求の範囲およびその等価物によって定義されることが意図される。

Claims (9)

1. 仮想環境内でシグナリング方法をサポートするための方法であって、
   １つ以上の物理サーバ上の管理ドメインにマッピングテーブルを提供するステップと、
   ネットワークにおける複数のホストの各々にＬＩＤを関連付けるステップと、
   前記複数のホスト内で実行される仮想マシンとｖＧＵＩＤとを関連付けるステップと、
   前記ネットワーク内において、第１のＬＩＤを有する第１のホストから、第２のＬＩＤを有する第２のホストへの前記仮想マシンの移行を示すパス記録変更イベントを表わすメッセージを前記管理ドメインで受信するステップと、
   前記仮想マシンに対するＬＩＤ−ｖＧＵＩＤマッピングの変化を示すために、前記受信されたメッセージに基づいて、前記マッピングテーブルを更新するステップと、
   前記メッセージを受信するためにサブネットマネージャに物理ポートＧＵＩＤを登録するステップと、
   前記仮想マシンの移行時において、前記登録された物理ポートＧＵＩＤに対応する物理サーバにより前記メッセージが受信された場合に、前記マッピングテーブルに基づいて、受信した前記メッセージを前記管理ドメインを介して前記管理ドメインに関連付けられた１つ以上の他の仮想マシンに転送するステップとを含む、方法。
2. 仮想環境内でシグナリング方法をサポートするためのシステムであって、
   １つ以上のマイクロプロセッサと、
   前記１つ以上のマイクロプロセッサにより実現される１つ以上の物理サーバとを含み、
   前記１つ以上の物理サーバは、マッピングテーブルを備える管理ドメインを含み、
   前記管理ドメインは、
   ネットワークにおける複数のホストの各々にＬＩＤを関連付け、
   前記複数のホスト内で実行される仮想マシンとｖＧＵＩＤとを関連付け、
   前記ネットワーク内において、第１のＬＩＤを有する第１のホストから、第２のＬＩＤを有する第２のホストへの前記仮想マシンの移行を示すパス記録変更イベントを表わすメッセージを受信し、
   前記仮想マシンに対するＬＩＤ−ｖＧＵＩＤマッピングの変化を示すために、前記受信されたメッセージに基づいて、前記マッピングテーブルを更新し、
   前記メッセージを受信するためにサブネットマネージャに物理ポートＧＵＩＤを登録し、
   前記仮想マシンの移行時において、前記登録された物理ポートＧＵＩＤに対応する物理サーバにより前記メッセージが受信された場合に、前記マッピングテーブルに基づいて、前記管理ドメインに関連付けられた１つ以上の他の仮想マシンに受信した前記メッセージを転送するように稼働する、システム。
3. 前記１つ以上の物理サーバは、ユーザドメインが追加された場合、前記管理ドメイン内の前記マッピングテーブルを更新するように稼働する、請求項２に記載のシステム。
4. パス再設定／不設定通知は、サブネットマネージャにおける前記ＬＩＤ−ｖＧＵＩＤマッピングを更新するために用いられる、請求項２または３に記載のシステム。
5. 前記１つ以上の物理サーバは、前記仮想マシンが前記第１のホストから前記第２のホストに移行された後、当該仮想マシンに関連付けられたｖＧＵＩＤを保存するように動作し、
   前記仮想マシンは、別の仮想マシンピアと通信する、請求項２〜４のいずれか１項に記載のシステム。
6. 最新のパス記録をカプセル化した前記メッセージは、前記仮想マシンピアに転送される、請求項５に記載のシステム。
7. 各物理サーバは、各々の物理ポートＧＵＩＤを用いて前記メッセージを受信する、請求項２〜６のいずれか１項に記載のシステム。
8. 前記システムは、仮想マシン作成イベントと仮想マシン移行イベントとを識別するように稼働する、請求項２〜７のいずれか１項に記載のシステム。
9. 機械読取可能なプログラムであって、
   その指令が実行されると、
   １つ以上の物理サーバ上の管理ドメインにマッピングテーブルを提供するステップと、
   ネットワークにおける複数のホストの各々にＬＩＤを関連付けるステップと、
   前記複数のホスト内で実行される仮想マシンとｖＧＵＩＤとを関連付けるステップと、
   前記ネットワーク内において、第１のＬＩＤを有する第１のホストから、第２のＬＩＤを有する第２のホストへの前記仮想マシンの移行を示すパス記録変更イベントを表わすメッセージを前記管理ドメインで受信するステップと、
   前記仮想マシンに対するＬＩＤ−ｖＧＵＩＤマッピングの変化を示すために、前記受信されたメッセージに基づいて、前記マッピングテーブルを更新するステップと、
   前記メッセージを受信するためにサブネットマネージャに物理ポートＧＵＩＤを登録するステップと、
   前記仮想マシンの移行時において、前記登録された物理ポートＧＵＩＤに対応する物理サーバにより前記メッセージが受信された場合に、前記マッピングテーブルに基づいて、受信した前記メッセージを前記管理ドメインを介して前記管理ドメインに関連された１つ以上の他の仮想マシンに転送するステップとをシステムに実行させる、機械読取可能なプログラム。