(57)【要約】【課題】仮想マシンの移動終了を迅速に検出できるようにする。【解決手段】管理マシン１０Ｃによる設定に応じて、移動対象の仮想マシン１１Ａの移動先となる物理マシン１０Ｂが、前記移動対象の仮想マシン１１Ａの前記物理マシン１０Ｂへの移動終了に伴って前記移動対象の仮想マシン１１Ａから送出される信号の検出を行ない、前記検出に応じて、前記移動対象の仮想マシン１１Ａの移動終了を管理マシン１０Ｃに通知する。【選択図】図２
2014182596.tif 000002
【特許請求の範囲】
【請求項１】
管理マシンによる設定に応じて、移動対象の仮想マシンの移動先となる物理マシンが、前記移動対象の仮想マシンの前記物理マシンへの移動終了に伴って前記移動対象の仮想マシンから送出される信号の検出を行なう手段と、
前記検出に応じて、前記移動対象の仮想マシンの移動終了を前記管理マシンに通知する手段と、を備えた
仮想マシンの移動終了を検出する装置。
【請求項２】
前記検出を行なう検出器プロセスは、前記移動終了を示す通知を前記管理マシンにおける検出レシーバへ送信した後、消滅する、請求項１に記載の仮想マシンの移動終了を検出する装置。
【請求項３】
前記検出器プロセスは、前記仮想マシンが前記クライアント網へ送出する信号数をカウントし、カウント結果が１以上である場合に、前記通知を生成する、請求項２に記載の仮想マシンの移動終了を検出する装置。
【請求項４】
前記検出器プロセスは、前記信号の検出に失敗すると消滅する、請求項２又は３に記載の仮想マシンの移動終了を検出する装置。
【請求項５】
前記検出器プロセスは、所定時間内に前記信号を検出できない場合、消滅する、請求項２又は３に記載に仮想マシンの移動終了を検出する装置。
【請求項６】
前記検出器プロセスは、前記管理マシンから前記仮想マシンの移動失敗を示す信号を受信すると、消滅する、請求項２又は３に記載の仮想マシンの移動終了を検出する装置。
【請求項７】
前記検出レシーバは、前記通知を受信すると、所定の後処理を実施する、請求項２〜６のいずれか１項に記載の仮想マシンの移動終了を検出する装置。
【請求項８】
前記移動終了を示す通知は、ＧＡＲＰ（Gratuitous Address Resolution Protocol）パケットである、請求項２〜７のいずれか１項に記載の仮想マシンの移動終了を検出する装置。
【請求項９】
管理マシンによる設定に応じて、移動対象の仮想マシンの移動先となる物理マシンが、前記移動対象の仮想マシンの前記物理マシンへの移動終了に伴って前記移動対象の仮想マシンから送出される信号の検出を行ない、
前記検出に応じて、前記移動対象の仮想マシンの移動終了を前記管理マシンに通知する、仮想マシンの移動終了を検出する方法。
【請求項１０】
管理マシンによる設定に応じて、移動対象の仮想マシンの移動先となる物理マシンが、前記移動対象の仮想マシンの前記物理マシンへの移動終了に伴って前記移動対象の仮想マシンから送出される信号の検出を行ない、
前記検出に応じて、前記移動対象の仮想マシンの移動終了を前記管理マシンに通知する、
処理をコンピュータに実行させる、仮想マシンの移動終了を検出するプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想マシンの移動終了を検出する装置、方法、及びプログラムに関する。
【背景技術】
【０００２】
Infrastructure as a Service（ＩａａＳ）システムでは、メンテナンスやネットワークコンポーネントの配置最適化のために仮想マシン（Virtual Machine：ＶＭ）を動作させたまま或る物理マシンから他の物理マシンへ移動させる「ライブマイグレーション」（Live Migration：以下「ＬＭ」と略記することがある。）が行なわれることがある。
【０００３】
ＬＭは、例示的に、ＩａａＳ管理ソフトウェア（例えば、OpenStack（登録商標）等）が、物理マシンの仮想化基盤（例えば、Ｘｅｎ（登録商標）、ＶＭｗａｒｅ（登録商標）等）に実施を指示することによって実行される。ＬＭ終了後には、ネットワークやストレージ網の関連する設定の変更を行なう（後処理）。
【０００４】
なお、ＬＭに関連する技術として、下記の特許文献１及び２に記載された技術がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１１−７０５４９号公報
【特許文献２】特開２０１０−１１４６６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＬＭ処理において、制御が移動先の仮想マシンに切り替わるタイミングは仮想化基盤からＩａａＳ管理ソフトウェアへは現状において通知されない。そのため、ＩａａＳ管理ソフトウェアは、例えば数十秒単位のポーリングで完了を確認している。
【０００７】
このタイムラグの間、セキュリティフィルタリング設定で不要なパケットを通過させてしまったり、資源の回収が遅れてしまったりすることがある。例えば、ネットワークのテナント分離をトンネル技術で実現している場合、構成方法によってはパケットループ回避のために、移動元と移動先の両方に同時にネットワーク到達性を確保できない場合があり、タイムラグの間、通信不能時間が発生する。
【０００８】
１つの側面では、本発明は、仮想マシンの移動終了を迅速に検出できるようにする。
【課題を解決するための手段】
【０００９】
１つの側面では、本発明は、管理マシンによる設定に応じて、移動対象の仮想マシンの移動先となる物理マシンが、前記移動対象の仮想マシンの前記物理マシンへの移動終了に伴って前記移動対象の仮想マシンから送出される信号の検出を行ない、前記検出に応じて、前記移動対象の仮想マシンの移動終了を前記管理マシンに通知する。
【発明の効果】
【００１０】
上述した装置の一態様によれば、仮想マシンの移動終了を迅速に検出することができる。
【図面の簡単な説明】
【００１１】
【図１】実施形態に係るコンピュータシステムの一例であるＩａａＳシステムの構成例を示すブロック図である。
【図２】図１に例示するＩａａＳシステムにおけるＬＭ終了検出動作を説明する図である。
【図３】図１に例示するＩａａＳシステムにおけるＬＭ終了検出動作を説明する図である。
【図４】図１に例示するＩａａＳシステムにおけるＬＭ終了検出動作を説明する図である。
【図５】図１に例示するＩａａＳシステムにおけるＬＭ終了検出動作を説明する図である。
【図６】図１に例示するＩａａＳシステムにおけるＬＭ検出器起動処理を説明するフローチャートである。
【図７】図１に例示するＩａａＳシステムにおけるＬＭ検出器処理を説明するフローチャートである。
【図８】図１に例示するＩａａＳシステムにおけるＬＭ検出レシーバ処理を説明するフローチャートである。
【図９】図１に例示するＩａａＳシステムにおけるＬＭ終了検出動作を説明するシーケンス図である。
【図１０】図４に例示する通知信号（検出信号）のフォーマット例を示す図である。
【図１１】図１〜図５及び図８に例示する処理データベース（ＤＢ）のレコード項目の一例を示す図である。
【図１２】セキュリティ問題を説明する図である。
【図１３】図９との比較例を示すシーケンス図である。
【発明を実施するための形態】
【００１２】
以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。
【００１３】
図１は、実施形態に係るコンピュータシステムの一例であるＩａａＳシステムの構成例を示すブロック図である。
【００１４】
図１に示すＩａａＳシステムは、例示的に、複数の物理マシン（コンピュータやサーバ等）１０を備える。各物理マシン１０は、管理網２０にそれぞれ接続されており、相互通信可能である。管理網２０は、非限定的な一例としてイーサネット（登録商標）網である。なお、図１においては、３台の物理マシン１０Ａ〜１０Ｃを例示しているが、２台や４台以上の物理マシンが備えられる場合もある。
【００１５】
物理マシン１０は、いずれも、図示しないＣＰＵ、メモリ、及び、ハードディスク装置等の記憶装置を備えている。ＣＰＵがメモリや記憶装置から所定のプログラムを読み取って動作することにより、必要な機能部が具現される。例示的に、プログラムには、仮想マシンや仮想化基盤を具現するプログラムや、後述する管理部、検出器（プロセス）、検出レシーバ等を具現するプログラム（仮想マシンの移動終了を検出するプログラム）が含まれる。
【００１６】
或る物理マシン１０Ａでは、当該物理マシン１０Ａにおいて動作する仮想マシン（ＶＭ）１１Ａが仮想インタフェース（ｖｉｆ）によりテナントＡ網２１に接続されている。ＶＭ１１Ａは、テナントＡ網２１に接続されているコンピュータ等の機器を管理することができる。
【００１７】
同様に、或る物理マシン１０Ｂでは、当該物理マシン１０Ｂにおいて動作するＶＭ１１ＢがｖｉｆによりテナントＢ網２２に接続されている。ＶＭ１１Ｂは、テナントＢ網２２に接続されているコンピュータ等の機器を管理することができる。
【００１８】
なお、１つの物理マシン１０に複数のＶＭ１１が存在し、当該ＶＭのそれぞれが異なるテナント網に接続される場合もある（例えば図２の符号１０Ａ参照）。テナント網２１及び２２は、いずれも、ＬＡＮ（Local Area Network）等の、クライアントが利用するネットワーク（クライアント網）の一例である。
【００１９】
物理マシン１０Ｃは、管理部の一例であるＩａａＳ管理ソフトウェア３１が動作する管理マシンである。管理マシン１０Ｃは、管理網２０を通じて、例えば、各物理マシン１０において動作するＶＭ１１に対して指示や設定等を実施できる。当該指示や設定の一例としては、動作中のいずれかのＶＭ１０をいずれかの物理マシン１１Ａや１１Ｂに対して仮想マシン１１のライブマイグレーション（ＬＭ）を実行させる指示や、後述する検出器（プロセス）１２の設定、起動等が挙げられる。
【００２０】
検出器１２Ａ及び１２Ｂは、ソフトウェアで定義された実行プロセスの一例であり、ＬＭ先の物理マシン１０に対して選択的かつ時限的に設定、起動される。別言すると、検出器１２は、すべての物理マシン１０において恒常的に起動されるものではなく、複数の物理マシン１０のうちＬＭ先の物理マシン１０に対して選択的かつ時限的に設定、起動される。
【００２１】
検出器１２は、ＶＭ１１のｖｉｆに対する監視（パケットキャプチャ）を実施し、ＶＭ１１からｖｉｆを通じて送信されるＧＡＲＰ（Gratuitous Address Resolution Protocol）パケットを検出する。また、検出器１２は、監視対象のｖｉｆに対応した送信パケットカウンタ１２１を備えている。送信パケットカウンタ１２１は、ｖｉｆを通じてテナント網２１（２２）へ送信されるパケット数をカウントする。
【００２２】
ＡＲＰパケットは、ＩＰアドレスに対するＭＡＣアドレスを解決するために用いられるパケットであり、機器の移動、切り替え等を同一ネットワークの他の機器に通知する。また、ＡＲＰパケットは、ＶＲＲＰ（Virtual Router Redundancy Protocol）やモバイルＩＰにおいては、他の機器のＡＲＰテーブル更新や、イーサネットスイッチにおける経路の変更を実施するために用いられる。ＬＭ終了時には、ＬＭ先のＶＭ１１は、例えば、ネットワークやストレージ網の関連する設定の変更を行なうために、ＧＡＲＰパケットが対応するテナントＡ網２１やテナントＢ網２２にブロードキャスト送信される。
【００２３】
検出器１２は、ＧＡＲＰパケットを検出すると、ＬＭが終了したと判定する。ＬＭが終了したと判定すると、検出器１２は、ＬＭ終了を示す信号（以下、「通知信号」あるいは「検出信号」と称することがある。）を生成し、管理網２０を通じて当該信号を管理マシン１０Ｃ宛に送信する。検出器１２は、ＶＭ１１のＬＭ毎に起動され、ＬＭ終了判定後にはパケットキャプチャ動作を含めてすべての動作を停止する。別言すると、検出器１２としての実行プロセスが消滅する。
【００２４】
検出器１２が管理網２０へ送信した通知信号は、物理マシン１０Ｃにおいて例えば管理マシン１０Ｃのシステム起動時に起動された検出レシーバ３２にて受信、検出される。なお、検出レシーバ３２の起動は、検出器１２の設定、起動に伴って実施してもよい。
【００２５】
検出レシーバ３２は、ソフトウェアで定義された実行プロセスの一例であり、通知信号を受信、検出すると、ＩａａＳ管理ソフトウェア３１による設定に従って後処理（プロセス）を起動、実施する。後処理の非限定的な一例としては、ネットワークやストレージ網の関連する設定の変更等（トンネル仮想網の変更、セキュリティ設定の移動、ストレージ切り替え等）が挙げられる。
【００２６】
以下、本実施形態の動作例について図２〜図５を参照して説明する。なお、図２〜図５は、或る物理マシン（ＬＭ元物理マシン）１０Ａにおいて動作しているＶＭ１１Ａ及び１１Ｂのうち、ＶＭ１１Ａを別の物理マシン（ＬＭ先物理マシン）１０ＢにＬＭする様子を例示している。
【００２７】
（処理Ｐ１）まず、図２に例示するように、ＬＭを実施するにあたって、管理マシン１０ＣのＩａａＳ管理ソフトウェア３１が、ＬＭ元物理マシン１０Ａの仮想化基盤１３（例えば、Ｘｅｎ等）に対して、ＬＭを指示する。
【００２８】
（処理Ｐ２）次いで、ＩａａＳ管理ソフトウェア３１は、検出レシーバ３２を起動し、検出レシーバ３２に、検出予定のＶＭ１１ＡのＵＵＩＤ（Universally Unique Identifier）、ＬＭ先物理マシン１０ＢのＵＵＩＤ、及び、成功時と失敗時との後処理（プロセス）内容（後処理（プロセス）へのポインタ）を設定する。
【００２９】
（処理Ｐ３）その後、ＩａａＳ管理ソフトウェア３１は、ＬＭ先物理マシン１０Ｂにおいて検出器１２Ｂを起動させ、検出器１２Ｂに、ＬＭ対象のＶＭ１１ＡのＵＵＩＤ、監視すべき仮想インタフェース（ｖｉｆ）の情報を設定する。
【００３０】
（処理Ｐ４）次いで、図３に例示するように、検出器１２Ｂは、ＬＭ対象のｖｉｆに対する監視（パケットキャプチャ）を、ＧＡＲＰパケットを検出するまで実施する。ＧＡＲＰパケットが検出されると、検出器１２Ｂは、ＬＭが終了したと判定する。このとき、ｖｉｆの送信パケットカウンタ１２１（図１参照）が１以上になっていることを検査してもよい。当該検査により、ＬＭ先ＶＭ１１ＢからＧＡＲＰパケットが送出されたことを確実に確認することができる。
【００３１】
（処理Ｐ５）ＬＭが終了したと判定すると、図４に例示するように、検出器１２Ｂは、ｖｉｆの監視を停止する。
【００３２】
（処理Ｐ６）また、検出器１２Ｂは、ＬＭが終了したことを示す通知信号（あるいは検出信号といってもよい）を生成し、管理網２０を通じて当該信号を管理マシン１０Ｃの検出レシーバ３２宛に送信する。このとき、ＬＭされたＶＭ１１ＢのＵＵＩＤを信号に含めてもよい。その場合、複数のＶＭ１１の移動を並行して実施することが可能になる。
【００３３】
（処理Ｐ７）図５に例示するように、検出器１２Ｂは、検出レシーバ３２との通信に成功すると終了し、これにより、検出器１２Ｂとしての実行プロセスが消滅する。
【００３４】
（処理Ｐ８）一方、検出レシーバ３２は、検出器１２Ｂが送信した通知信号を受信すると、例えば、受信した通知信号に含まれるＵＵＩＤに対応する後処理（プロセス）を起動する。
【００３５】
次に、以下では上述した動作例における、検出器１２の起動処理（ＬＭ検出器起動処理）、検出器１２での処理（ＬＭ検出器処理）、及び、検出レシーバ３２での処理（ＬＭ検出レシーバ処理）について、それぞれ図６、図７及び図８を参照して説明する。
【００３６】
（ＬＭ検出器起動処理）
図６に例示するように、ＬＭが開始されると、ＩａａＳ管理ソフトウェア３１は、ＬＭ対象のＶＭ１１及び当該ＶＭのＬＭ先物理マシン１０を決定する（処理Ｐ１０）。次いで、ＩａａＳ管理ソフトウェア３１は、ＬＭ対象のＶＭ１１が動作するＬＭ元物理マシン１０の仮想化基盤１３に対してＬＭ指示を発行する。
【００３７】
また、ＩａａＳ管理ソフトウェア３１は、検出レシーバ３２を起動し、検出レシーバ３２に、検出予定の仮想マシン１１のＵＵＩＤ、ＬＭ先物理マシン１０のＵＵＩＤ、及び、成功時と失敗時との後処理内容（後処理（プロセス）へのポインタ）を設定、登録する（処理Ｐ２０）。
【００３８】
一方、ＬＭ指示を受信したＬＭ元物理マシン１０の仮想化基盤１３は、ＬＭ先物理マシン１０との間でＬＭの準備処理を実施する。準備処理の一例としては、ＬＭ元物理マシン１０からＬＭ先物理マシン１０に対する準備開始通知、ＬＭ先物理マシン１０でのストレージアタッチ、仮想インタフェース（ｖｉｆ）の作成等が挙げられる（処理Ｐ３０及びＰ４０）。準備処理が完了して移動先ＶＭ１１の起動準備が整うと、ＬＭ先物理マシン１０で作成されたｖｉｆの識別情報（ＩＤ）が管理網２０を通じてＩａａＳ管理ソフトウェア３１に通知される（処理Ｐ５０）。
【００３９】
ＩａａＳ管理ソフトウェア３１は、上記処理Ｐ２０の後、ＬＭ先物理マシン１０からのｖｉｆの識別情報の受信待ち状態となっており（処理Ｐ６０）、ｖｉｆの識別情報が受信されると、当該識別情報によって識別されるｖｉｆが存在するＬＭ先物理マシン１０において検出器１２を起動させる（処理Ｐ７０）。
【００４０】
（ＬＭ検出器処理）
検出器１２は、起動されると、図７に例示するように、ｖｉｆに対する監視が失敗したか否かを監視し（処理Ｐ１００）、失敗していなければ（処理Ｐ１００でｎｏの場合）、該当ＶＭ１１を送信元アドレスとするＧＡＲＰパケットを検出するまで（処理Ｐ１１０でｙｅｓと判定されるまで）、ｖｉｆの監視を継続する（処理Ｐ１１０のｎｏルート）。
【００４１】
該当ＶＭ１１を送信元アドレスとするＧＡＲＰパケットが検出されると、検出器１２は、監視対象のｖｉｆの送信パケットカウンタ１２１が１以上の値にカウントアップしているか否かをチェックする（処理Ｐ１１０のｙｅｓルートから処理Ｐ１２０）。
【００４２】
当該チェックの結果、監視対象のｖｉｆの送信パケットカウンタ１２１が１以上の値にカウントアップしていなければ、検出器１２は、処理Ｐ１００以降に戻って監視を継続する（処理Ｐ１２０のｎｏルート）。なお、送信パケットカウンタ１２１の確認処理は省略してもよい。
【００４３】
一方、監視対象のｖｉｆの送信パケットカウンタ１２１が１以上の値にカウントアップしていれば、検出器１２は、検出レシーバ３２宛の通知信号を生成し、管理網２０を通じて当該通知信号を検出レシーバ３２へ送信する（処理Ｐ１２０のｙｅｓルートから処理Ｐ１３０）。通知信号を送信すると、検出器１２は、動作を停止し、消滅する（処理Ｐ１５０）。検出器１２の動作停止、消滅は、ＩａａＳ管理ソフトウェア３１からの終了通知信号の受信を待って実施してもよい。
【００４４】
なお、処理Ｐ１００において、ｖｉｆの監視に失敗している場合、検出器１２は、例えば、動作を停止して消滅する前に、監視の失敗（エラー）を検出レシーバ３２に通知するようにしてもよい（処理Ｐ１００のｙｅｓルートから処理Ｐ１４０）。
【００４５】
ＬＭ失敗の場合、ＧＡＲＰパケットが送信されないため、エラー処理がなければ検出器１２が残存することになる。検出器１２が残存してしまうと、物理マシン１０のメモリやプロセステーブルの枯渇を招くおそれがある。
【００４６】
そこで、検出器１２は、ＬＭ失敗により、仮想化基盤１３がｖｉｆを回収した結果、検出器１２の実施する監視におけるエラー（read error）発生を契機にＬＭ失敗を検出レシーバ３２に伝え、停止、消滅する。これにより、物理マシン１０のメモリやプロセステーブルの枯渇を防止することができる。また、エラー時に検出器１２を消滅させるので、検出器１２に対する攻撃時間を制限でき、セキュリティ面の向上を図ることもできる。
【００４７】
なお、上記の例では、ＬＭ失敗の判断は、ｖｉｆの監視が失敗する場合を例としているが、これに限られない。例えば、妥当な終了時間を予め設定しておき、当該終了時間を超過（タイムアウト）してもＧＡＲＰパケットが検出されない場合に、ＬＭ失敗と判断してもよい。
【００４８】
また、ＩａａＳ管理ソフトウェア３１がＬＭ失敗を検知した後、検出器１２を外部から終了させるようにしてもよい。例えば、ＩａａＳ管理ソフトウェア３１は、ハングアップシグナルを検出器１２へ送信し、検出器１２は、ハングアップシグナルを受信すると失敗終了処理を開始し、消滅する。ハングアップシグナルは、ＶＭ１１の移動失敗を示す信号の一例である。
【００４９】
次に、既述の通知信号のフォーマット例を図１０に示す。図１０に例示するように、通知信号は、ＩＰヘッダ４１、ＴＣＰヘッダ４２、ＶＭ  ＵＵＩＤフィールド４３、ＬＭ先物理マシンＵＵＩＤフィールド４４、終了コードフィールド４５、及び、エラーオプションフィールド４６を有する。
【００５０】
ＶＭ  ＵＵＩＤフィールド４３は、非限定的な一例としてＩＳＯ／ＩＥＣ１１５７８規格に準拠した１６バイトのフィールドである。当該フィールド４３には、ＬＭ対象のＶＭのＵＵＩＤが設定される。
【００５１】
ＬＭ先物理マシンＵＵＩＤフィールド４４も、非限定的な一例としてＩＳＯ／ＩＥＣ１１５７８規格に準拠した１６バイトのフィールドである。当該フィールド４４には、ＬＭ先物理マシン１０のＵＵＩＤが設定される。
【００５２】
終了コードフィールド４５は、非限定的な一例として２バイトのフィールドであり、終了コードの一例として、エラーを示す値（例えば、０）及び正常終了を示す値（例えば、１）のいずれかが当該フィールド４５に設定される。なお、２バイトで表せる他の値（２〜６５５３５）はリザーブ値である。
【００５３】
エラーオプションフィールド４６は、オプションフィールドであり、通知信号の１フレーム分に格納できるだけの長さのエラー情報を当該フィールド４６に設定することができる。
【００５４】
検出レシーバ３２は、上述の各フィールド４３〜４６に設定された情報に基づいて、ＬＭ対象のＶＭや、ＬＭ先物理マシン１０、検出器１２による監視の正常／異常終了、異常終了時の情報等を識別することができる。
【００５５】
（ＬＭ検出レシーバ処理）
検出レシーバ３２は、図８に例示するように、管理マシン１０Ｃのシステム起動によって起動されると（処理Ｐ２００）、ＩａａＳ管理ソフトウェア３１からＬＭ対象のＶＭ１１の情報を受信したか否かを監視する（処理Ｐ２１０）。
【００５６】
監視中に、ＩａａＳ管理ソフトウェア３１からＬＭ対象のＶＭ１１の情報を受信すると（処理Ｐ２１０でｙｅｓの場合）、検出レシーバ３２は、受信した情報に基づいて、図１１に例示するように、処理データベース（ＤＢ）３３に、ＶＭのＵＵＩＤ、ＬＭ先物理マシン１０のＵＵＩＤ、及び、後処理（プロセス）のポインタを登録する（処理Ｐ２２０）。
【００５７】
処理ＤＢ３３に対する情報登録後、あるいは、ＩａａＳ管理ソフトウェア３１からＬＭ対象のＶＭ１１の情報が受信されない場合（処理Ｐ２１０でｎｏの場合）、検出レシーバ３２は、検出器１２からＬＭ終了を示す通知信号を受信したか否かを監視する（処理Ｐ２３０）。
【００５８】
通知信号が受信されていなければ、検出レシーバ３２は、上記処理Ｐ２１０に戻って監視を継続する（処理Ｐ２３０のｎｏルート）。一方、通知信号が受信されていれば（処理Ｐ２３０でｙｅｓの場合）、検出レシーバ３２は、受信した信号（例えば図１０参照）に含まれる、ＬＭ対象のＶＭ１０のＵＵＩＤ及びＬＭ先物理マシン１０のＵＵＩＤを抽出する（処理Ｐ２４０）。
【００５９】
そして、検出レシーバ３２は、抽出した各ＵＵＩＤをキーにして処理ＤＢ３３のエントリを検索し（処理Ｐ２５０）、また、受信した通知信号の例えば終了コードフィールド４５において示される情報を基に、ＬＭの成功／失敗を判断する（処理Ｐ２６０）。
【００６０】
ＬＭが成功していれば（処理Ｐ２６０でｙｅｓの場合）、検出レシーバ３２は、処理ＤＢ３３（図１１参照）におけるＬＭ成功時の後処理（プロセス）へのポインタを参照して、当該後処理プロセスを起動する（処理Ｐ２７０）。
【００６１】
一方、ＬＭが失敗していれば（処理Ｐ２６０でｎｏの場合）、検出レシーバ３２は、処理ＤＢ（図１１参照）におけるＬＭ失敗時の後処理（プロセス）へのポインタを参照して、当該後処理プロセスを起動する（処理Ｐ２８０）。
【００６２】
次に、上述した各処理に基づくシーケンス例について図９を参照して説明する。
まず、ＩａａＳ管理ソフトウェア３１がＬＭ元物理マシン１０の仮想化基盤１３に対してＬＭ指示を送信する（Ｓ３０１）。また、検出レシーバ３２は、ＩａａＳ管理ソフトウェア３１から受信した情報に基づいて、処理ＤＢ３３（図１１参照）に、ＶＭのＵＵＩＤ、ＬＭ先物理マシン１０のＵＵＩＤ、及び、後処理（プロセス）のポインタを登録する（Ｓ３０２）
【００６３】
ＬＭ元物理マシン１０の仮想化基盤１３は、ＬＭ先物理マシン１０との間で既述のＬＭの準備処理（ＬＭ先物理マシン１０でのストレージアタッチ、仮想インタフェース（ｖｉｆ）の作成等）を実施する（Ｓ３０３）。
【００６４】
一方、ＩａａＳ管理ソフトウェア３１は、処理ＤＢ３３への情報登録が終了すると、ＬＭ先物理マシン１０に対して、検出器１２の起動指示、ＬＭ対象のＶＭ１１ＡのＵＵＩＤ、監視対象のｖｉｆの情報を送信する（Ｓ３０４）。
【００６５】
ＬＭ先物理マシン１０では、検出器１２を起動し、ＬＭ対象のｖｉｆに対する監視（パケットキャプチャ）を、ＧＡＲＰパケットを検出するまで実施する（Ｓ３０５）。その間、ＬＭ元物理マシン１０とＬＭ先物理マシン１０との間では、メモリコピー等のＬＭ処理が実施される（Ｓ３０６）。
【００６６】
その後、検出器１２にてＧＡＲＰパケットの送出が検出されると（Ｓ３０７）、検出器１２は通知信号（図１０参照）を生成し、当該通知信号を検出レシーバ３２へ送信し、動作コンテクストがＩａａＳ管理ソフトウェア３１に移行する（Ｓ３０８）。
【００６７】
ＩａａＳ管理ソフトウェア３１は、動作コンテクストが移行されると、終了通知信号をＬＭ先物理マシン１０の検出器１２へ送信する（Ｓ３０９）。当該終了通知信号を受信すると、検出器１２は、動作を停止し消滅する（Ｓ３１０）。
【００６８】
一方、検出器１２からの通知信号を受信した検出レシーバ３２は、通知信号に含まれる情報を基に処理ＤＢ３３を検索し、該当する後処理（プロセス）を起動、実行する（Ｓ３１１及びＳ３１２）。
【００６９】
以上詳述した実施形態によれば、ＩａａＳ管理ソフトウェア３１は、制御をＬＭ先ＶＭに切り替えるタイミングを検出器１２からの通知信号により把握することができる。したがって、例えば図１３に図９との比較例として例示するような、数十秒単位のポーリングによってＬＭ完了を確認する必要がない。
【００７０】
よって、ＬＭの終了を迅速に検出でき、不要なタイムラグが生じて、セキュリティフィルタリング設定で不要なパケットを通過させてしまったり、資源の回収が遅れてしまったりすることを回避することができる。その結果、タイムラグの間に通信不能時間が発生することを防止できる。
【００７１】
また、上述した実施形態によれば、以下に例示するいずれかの効果ないし利点も得られる。
【００７２】
・悪意のある顧客からの攻撃への対策
検出器１２は、ＬＭを行なっている期間に時限的に存在するので、攻撃可能時間が限定される。
【００７３】
検出器１２は、ＬＭ先の物理マシン１０に対して選択的に設定されるので、攻撃側は攻撃対象とする場所の特定が困難である。
【００７４】
検出器１２は、ＬＭを行なっている顧客のテナント網と管理網２０とにしか接続されず、ＬＭを行なっていない顧客のテナント網には接続されない。そのため、仮に、検出器１２が攻撃を受けてセキュリティが破られた場合でも、その影響はセキュリティの破られた物理マシン１０を共用しているテナント網に限定される。
【００７５】
検出器１２は、ＬＭ先のＶＭ１１から送出されるＡＲＰパケット以外はフィルタリングできるので、他のＶＭ１１からの攻撃パケットを容易に排除可能である。
【００７６】
検出レシーバ３２に、検出器１２が生成する通知信号を送るので、攻撃側がＧＡＲＰパケットに細工をした場合でも、ＩａａＳ管理ソフトウェア３１へは細工されたＧＡＲＰパケットは到達しない。また、クライアント網２１や２２で利用されるＩＰアドレスやＭＡＣアドレスの情報が管理網２０には送出されないので、不要な情報漏えい等を防止でき、セキュリティを向上できる。
【００７７】
・オペレータの誤操作、悪意のある操作への対策
オペレータが通常操作する管理マシン１０Ｃは、テナント網２１や２２に接続されず、テナント網２１及び２２から分離しているので、テナントのセキュリティを確保できる。別言すると、ＧＡＲＰパケットはテナント網２１や２２に出力され、クラウド運営側からは観測させない。
【００７８】
仮に、図１２に例示するように、ＩａａＳ管理ソフトウェア３１を動作させる物理マシン１０Ｃを各テナント網２１及び２２に接続し、テナント網２１又は２２に送出されるＧＡＲＰパケットを観測できるようにすると、以下のようなセキュリティ問題が生じうる。
【００７９】
管理マシン１０Ｃが悪意のある顧客によって攻撃されセキュリティが破られた場合、他のテナント網や、管理網２０へ攻撃が可能になる。また、オペレータがテナント網２１や２２へアクセスする事故が発生しうる。
【００８０】
例えば、ＩａａＳ管理ソフトウェア３１を動作させる物理マシン１０Ｃには、運営側の人間がログインする機会が多いので、要員教育や、事故等に備えた証跡の管理が必要になる（比較対象：物理マシンのＯＳ）。
【００８１】
また、複数のクライアント網が一般的なＯＳ（例えばＬｉｎｕｘ（登録商標）等）に接続されるので、障害や攻撃に対して非常に脆弱になる。さらに、ＬＭ終了以外の他の要因によるＧＡＲＰパケットの送出（インタフェースのアップ／ダウンでもＧＡＲＰパケットが送出される）によって、ＬＭ終了を誤検出するおそれもある。
【００８２】
これに対し、上述した実施形態では、ＩａａＳ管理ソフトウェア３１でＧＡＲＰパケットを直接検出せずに、ＬＭ先物理マシン１０にＬＭ対象のＶＭ１１に対応した検出器１２を時限的に設置し、検出器１２は１つのテナント網にしか接続させない。別言すると、セキュリティ的に弱い箇所にならないよう、場所的及び時間的に限定して検出器１２を設置し、当該検出器１２でＧＡＲＰパケットを検出するので、上述したようなセキュリティ問題を解消できる。
【００８３】
また、上述した実施形態は、ハイパーバイザや仮想化基盤とは独立に適用することが可能である。別言すると、ハイパーバイザ等に改造は不要であり、ハイパーバイザ等の製造元以外がバージョンアップやセキュリティパッチに対して追従する必要もない。また、上述した実施形態は、複数種類のハイパーバイザ等に対して適用可能である。
【００８４】
さらに、ＩａａＳ管理ソフトウェア３１に対してＬＭ終了を通知するので、ストレージや、マシン等、ネットワーク以外の装置や、上位層の後処理を行なえる。ネットワーク装置の設定でも、同一イーサネットに接続していない機器への設定変更も可能である。
【００８５】
なお、上述した実施形態では、検出器１２による検出対象の信号の一例としてＧＡＲＰパケットを挙げたが、これに限られない。ＶＭ１１の移動終了を示す信号（合図）としての機能を果たす信号を検出器１２による検出対象としてもよい。
【符号の説明】
【００８６】
１０Ａ，１０Ｂ  物理マシン
１０Ｃ  管理マシン
１１Ａ，１１Ｂ  仮想マシン（ＶＭ）
１２Ａ，１２Ｂ  検出器（プロセス）
３１  ＩａａＳソフトウェア（管理部）
３２  検出レシーバ
３３  処理データベース（ＤＢ）
４１  ＩＰヘッダ
４２  ＴＣＰヘッダ
４３  ＶＭ  ＵＵＩＤフィールド
４４  ＬＭ先物理マシンＵＵＩＤフィールド
４５  終了コードフィールド
４６  エラーオプションフィールド
【図１】
2014182596.tif 000003
【図２】
2014182596.tif 000004
【図３】
2014182596.tif 000005
【図４】
2014182596.tif 000006
【図５】
2014182596.tif 000007
【図６】
2014182596.tif 000008
【図７】
2014182596.tif 000009
【図８】
2014182596.tif 000010
【図９】
2014182596.tif 000011
【図１０】
2014182596.tif 000012
【図１１】
2014182596.tif 000013
【図１２】
2014182596.tif 000014
【図１３】
2014182596.tif 000015