JP2020031305A - マルチクラウド運用プログラム、およびマルチクラウド運用方法 - Google Patents

Abstract

【課題】仮想マシンを移動後に処理を継続できるかどうかを確認できるようにする。【解決手段】第１クラウド１の運用管理装置３は、第１クラウド１内で実行されている第１仮想マシン５が利用した第１サービス６ａのポート番号を、第１仮想マシン５の識別子に対応付けて記憶する。その後、運用管理装置３が、第１仮想マシン５の第２クラウド２への移動要求を受信したものとする。移動要求を受信した運用管理装置３は、第２クラウド２に対して、第１サービス６ａのポート番号を指定して、第２クラウド２においてそのポート番号に対応する第２サービス７ａが利用可能か否かの確認要求３ａを送信する。そして、運用管理装置３は、確認要求３ａに対して、第２クラウド２から第２サービス７ａが利用可能であるとの回答を受信すると、第１仮想マシン５を第２クラウド２へ移動させる。【選択図】図１

Description

本発明は、マルチクラウド運用プログラム、およびマルチクラウド運用方法に関する。

クラウドコンピューティングシステム（以下、単にクラウドと呼ぶこともある）を利用するユーザは、異なる企業が提供する複数のクラウドを利用する場合がある。この場合、ユーザは、複数のクラウドに跨がったシステム（マルチクラウドシステム）を構築する。

マルチクラウドシステムを利用するユーザは、複数のクラウドそれぞれで仮想マシン（ＶＭ：Virtual Machine）を運用する。ＶＭはインスタンスと呼ぶこともある。ユーザは、異なるクラウドで実行される複数のＶＭを連係動作させることで、所望の処理を実行させる。

クラウド上のＶＭの管理技術としては、例えばマルチテナントアプリケーションサーバ環境におけるパーティションマイグレーションのためのシステムがある。また、仮想マシンの仮想的な接続を管理することが可能なコンピュータネットワークシステムがある。さらに、ユーザまたは他の実体のために提供される仮想コンピュータネットワーク向けなどの管理されたコンピュータネットワークのための論理ネットワーキング機能を提供する技術もある。

特表２０１７−５１９３０９号公報 特開２０１３−１３４６５８号公報 特表２０１２−５１９４５８号公報

マルチクラウドシステムでは、クラウドを跨がってＶＭを移動させることが可能である。しかし、従来は、異動対象のＶＭが移動前に実行していた処理と同様の処理を、移動後のＶＭが実行可能かどうかを、移動前に確認する手段がない。例えば、移動前のクラウドで移動対象のＶＭが利用していたサービスが、移動先のクラウドでは利用できない場合がある。このような場合、移動対象のＶＭは、移動後に移動前と同様の処理を実行することができなくなる。

１つの側面では、本件は、移動後にＶＭが処理を継続できるかどうかを確認できるようにすることを目的とする。

１つの案では、以下の処理をコンピュータに実行させるマルチクラウド運用プログラムが提供される。
コンピュータは、第１クラウドコンピューティングシステム内で実行されている第１仮想マシンが利用した第１サービスのポート番号を、第１仮想マシンの識別子に対応付けて記憶する。次にコンピュータは、第１仮想マシンの第２クラウドコンピューティングシステムへの移動要求を受信すると、第２クラウドコンピューティングシステムに対して、第１サービスのポート番号を指定して、第２クラウドコンピューティングシステムにおいてポート番号に対応する第２サービスが利用可能か否かの確認要求を送信する。そしてコンピュータは、確認要求に対して、第２クラウドコンピューティングシステムから第２サービスが利用可能であるとの回答を受信すると、第１仮想マシンを第２クラウドコンピューティングシステムへ移動させる。

１態様によれば、移動後にＶＭが処理を継続できるかどうかを確認することができる。

マルチクラウド運用方法の第１の例を示す図である。 マルチクラウド運用方法の第２の例を示す図である。 マルチクラウド運用方法の第３の例を示す図である。 マルチクラウド運用方法の第４の例を示す図である。 第２の実施の形態のマルチクラウドシステムの一例を示す図である。 サーバのハードウェアの一構成例を示す図である。 クラウドにおける運用管理機能の一例を示すブロック図である。 メディエータＩＤの生成例を示す図である。 ＩＤ対応変換ＤＢの一例を示す図である。 位置情報変換ＤＢの一例を示す図である。 課金情報の収集例を示す図である。 依頼メッセージ送信処理の手順の一例を示すフローチャートである。 返信メッセージ受信処理の手順の一例を示すフローチャートである。 ＶＭのメディエータＩＤ管理処理の手順の一例を示すシーケンス図である。 ＶＭ移動処理の手順の一例を示すシーケンス図である。 ＣＰＵ負荷取得サービスを利用しているＶＭの移動例を示す図である。 ＶＭ間通信を行うＶＭの移動例を示す図である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず、図１〜図４を参照し、第１の実施の形態に係るマルチクラウド運用方法について説明する。

図１は、マルチクラウド運用方法の第１の例を示す図である。図１には、第１仮想マシン５をマイグレーションによって移動する前に、移動前と同様の処理を移動後も実行できるかどうかを、事前確認する処理手順が示されている。

マルチクラウドシステムは、第１クラウドコンピューティングシステム（第１クラウド）１と第２クラウドコンピューティングシステム（第２クラウド）２とを含む。
第１クラウド１と第２クラウド２とのそれぞれには、運用管理装置３，４が設けられている。運用管理装置３は、第１クラウド１内のコンピュータによって実現することができる。例えば第１クラウド１内のコンピュータ上に起動した仮想マシンを、運用管理装置３として利用することができる。運用管理装置４は、第２クラウド２内のコンピュータによって実現することができる。例えば第２クラウド２内のコンピュータ上に起動した仮想マシンを、運用管理装置４として利用することができる。

ここで、第１クラウド１内で第１仮想マシン５が実行されているものとする。第１仮想マシン５は、第１クラウド１内のサーバ６で提供されている第１サービス６ａを利用して処理を行っている（ステップＳ１）。運用管理装置３は、第１仮想マシン５が利用した第１サービス６ａのポート番号（ポートａ）を、第１仮想マシン５の識別子に対応付けて、例えば通信先リストとして記憶する（ステップＳ２）。通信先リストには、第１サービス６ａにアクセスするためのアドレス（第１アドレス）と、サービス利用時の通信ポートを示すポート番号（ポートａ）が格納される。

その後、運用管理装置３は、第１仮想マシン５の第２クラウド２への移動要求を受信する。すると運用管理装置３は、第２クラウド２に対して、第１サービス６ａのポート番号（ポートａ）を指定して、第２クラウド２においてそのポート番号（ポートａ）に対応する第２サービス７ａが利用可能か否かの確認要求３ａを送信する（ステップＳ３）。

第２クラウド内の運用管理装置４は、確認要求３ａを受信すると、確認要求３ａに示されるポート番号（ポートａ）に対応する第２サービス７ａが、第２クラウド２において利用可能か否かを確認する（ステップＳ４）。例えば運用管理装置４は、第２クラウド２内で通信可能な各装置に対して、確認要求３ａに示されるポート番号（ポートａ）による通信を試み、対応するサービスの存在の有無を確認する。図１の例では、第２クラウド２内のサーバ７において、確認要求３ａに示されるポート番号（ポートａ）に対応する第２サービス７ａが提供されている。そこで、運用管理装置４は、第１クラウド１の運用管理装置３に、該当ポートが利用可能であることを示す回答４ａを送信する（ステップＳ５）。

第１クラウド１の運用管理装置３は、確認要求３ａに対して、第２クラウド２から第２サービス７ａが利用可能であるとの回答４ａを受信すると、第１仮想マシン５を第２クラウド２へ、マイグレーション処理によって移動させる（ステップＳ６）。

このようにして、第１仮想マシン５を移動させる前に、移動後も現在と同種のサービスを利用できるか否かを確認することができる。移動後も同種のサービスを利用することができれば、移動後の第１仮想マシン５ａにより、移動前と同様の処理を実行可能となる。

図２は、マルチクラウド運用方法の第２の例を示す図である。図２には、移動された後の仮想マシンがサービスを利用するための処理手順が示されている。例えば第２クラウド２で稼働している第２仮想マシン８を第１クラウド１に移動させる場合を想定する。

第２クラウド２内では、第２仮想マシン８は、サーバ７で提供されている第２サービス７ａを利用している（ステップＳ１１）。第２クラウド２の運用管理装置４は、第２仮想マシン８の識別子に対応付けて、第２仮想マシン８の通信先である第２サービス７ａのアドレス（第２アドレス）とポート番号（ポートａ）とを示す通信先リストを記憶する（ステップＳ１２）。その後、第２仮想マシン８の第１クラウド１への移動要求を運用管理装置４が受信すると、運用管理装置４は、第２仮想マシン８を第１クラウド１に移動させる（ステップＳ１３）。

第１クラウド１の運用管理装置３は、第２クラウド２内で実行されていた第２仮想マシン８が、第１クラウド１に移動した場合、第２クラウド２から、第２仮想マシン８が利用していた第２サービス７ａへのアクセス用の第２アドレスを取得する（ステップＳ１４）。例えば運用管理装置３は、第２サービス７ａと第２アドレスとポート番号（ポートａ）とを含む利用サービス情報４ｂを、第２クラウド２の運用管理装置４から取得する。

第１クラウド１の運用管理装置３は、第１クラウド１内で第２サービス７ａと同種のサービスを提供する第１サービス６ａへのアクセス用の第１アドレスと、取得した第２アドレスとの対応関係を示す対応表を記憶する（ステップＳ１５）。

その後、運用管理装置３は、移動後の第２仮想マシン８ａから第２アドレスを指定したサービス提供要求３ｂを受信すると、対応表に基づいて、サービス提供要求３ｂの送信先を第１アドレスに変更する（ステップＳ１６）。送信先が変更されたサービス提供要求３ｃは、サーバ６に送信される。その結果、サービス提供要求３ｃに応じて、サーバ６により第１サービス６ａが実行される。

このように運用管理装置３は、移動後の第２仮想マシン８ａが出力したサービス提供要求３ｂの送信先のアドレスを変更する。これにより、第２仮想マシン８ａは、第２クラウド２内で稼働していたときと同様の送信先にサービス提供要求３ｂを送信すれば、移動前に利用していた第２サービス７ａと同種の第１サービス６ａを利用することができる。すなわち移動された第２仮想マシン８ａに変更を加えることなく、移動前と同様の処理を実行させることが可能となる。

図３は、マルチクラウド運用方法の第３の例を示す図である。図３には、クラウドを跨いだ移動後も、移動前と同様にパケットを受信できるようにするための処理手順が示されている。例えば図１と同様に、第１クラウド１で動作していた第１仮想マシン５が、第２クラウド２に移動した場合を想定する。

第１仮想マシン５の第１クラウド１でのアドレスを第３アドレスとする。第１仮想マシンの第２クラウド２への移動（ステップＳ２１）が行われると、移動後の第１仮想マシン５ａには、第２クラウド２内での第４アドレスが付与される。

第１クラウド１の運用管理装置３は、移動後の第１仮想マシン５ａの第２クラウド２内での第４アドレスを、第２クラウド２の運用管理装置４から取得する（ステップＳ２２）。運用管理装置３は、第１仮想マシン５の第１クラウド１内での第３アドレスと、移動後の第１仮想マシン５ａの第４アドレスとを対応付けて記憶する（ステップＳ２３）。

運用管理装置３は、第１仮想マシン５が第２クラウド２に移動した後は、第１クラウド１内で発生した第３アドレスを送信先とするパケット３ｄの送信先を第４アドレスに変更して、送信先変更後のパケット３ｅを第２クラウド２に転送する（ステップＳ２４）。パケット３ｅは、第２クラウド２の運用管理装置４によって、第４アドレスを有する第１仮想マシン５ａに送信される。

このように運用管理装置３は、第１仮想マシン５が移動された後は、第１仮想マシン５宛てのパケット３ｄの送信先を、移動後の第１仮想マシン５ａの第４アドレスに変更する。これにより、移動後の第１仮想マシン５ａは、移動前と同様に、パケットを受信することができる。すなわち第１仮想マシン５がクラウドを跨がって移動しても、第１仮想マシン５と通信を行っていた他の装置は、送信先の設定変更を行わずに、移動後の第１仮想マシン５ａにパケットを送信することができる。

図４は、マルチクラウド運用方法の第４の例を示す図である。図４には、クラウドを跨いだ移動後も、移動前と同様にパケットを送信できるようにするための処理手順が示されている。例えば第２クラウド２で動作していた第３仮想マシン９と第４仮想マシン１０とのうち、第３仮想マシン９が第１クラウド１に移動した後、移動後の第３仮想マシン９ａから第４仮想マシン１０へパケットを送信する場合を想定する。

第１クラウド１の運用管理装置３は、第２クラウド２内で第３仮想マシン９が生成されると、第２クラウド２の運用管理装置４から、第３仮想マシン９の第２クラウド２内での第５アドレスを取得する（ステップＳ３１）。運用管理装置４は、取得した第５アドレスを、例えばメモリに格納する。また第１クラウド１の運用管理装置３は、第２クラウド２内で第４仮想マシン１０が生成されると、第２クラウド２から、第４仮想マシン１０の第２クラウド２内での第６アドレスを取得する（ステップＳ３２）。運用管理装置４は、取得した第６アドレスを、例えばメモリに格納する。これにより、運用管理装置３は、第３仮想マシン９と第４仮想マシン１０とが第２クラウド２内に存在することを認識すると共に、それらのアドレスを記憶する。

その後、第３仮想マシン９が第１クラウド１に移動する（ステップＳ３３）。すると第１クラウド１の運用管理装置３は、移動前の第３仮想マシン９の第５アドレスに対応付けて、移動後の第３仮想マシン９ａの第１クラウド１内での第７アドレスを記憶する（ステップＳ３４）。これにより運用管理装置３は、第３仮想マシン９ａが第１クラウド１に移動したことを認識する。

ここで、移動後の第３仮想マシン９ａが、第４仮想マシン１０の第６アドレスを送信先とするパケット３ｆを出力したものとする。この場合、運用管理装置３は、出力されたパケット３ｆの送信元のアドレスを第５アドレスに変更して、送信元変更後のパケット３ｇを第２クラウド２に転送する（ステップＳ３５）。パケット３ｇは、第２クラウド２の運用管理装置４によって、第６アドレスを有する第４仮想マシン１０に送信される。

このように運用管理装置３は、移動後の第３仮想マシン９ａから、第２クラウド２内の第４仮想マシン１０宛てのパケット３ｆが出力されると、そのパケット３ｆの送信元を、移動前の第３仮想マシン９の第５アドレスに変更する。これにより、第４仮想マシン１０は、移動前の第３仮想マシン９から受信した場合と同様のパケットを、移動後の第３仮想マシン９ａから受信できる。その結果、第４仮想マシン１０は、第３仮想マシン９が移動したことを意識せずに、移動後の第３仮想マシン９ａとの間で、移動前と同様の通信が可能となる。

例えば、第４仮想マシン１０が第３仮想マシン９の移動を意識しない場合、第４仮想マシン１０から移動後の第３仮想マシン９ａに送信するパケットの送信先は、移動前の第３仮想マシン９の第５アドレスとなる。このパケットは、図３に示す処理によって送信先が第７アドレスに変更され、移動後の第３仮想マシン９ａに転送される。このとき転送されたパケットへの応答のパケットの送信元が第７アドレスのままだと、第４仮想マシン１０は、応答されたパケットを、送信したパケットの送信先（第３仮想マシン９）とは別の装置からのパケットと認識してしまう。そこで図４に示すように、運用管理装置３が、第３仮想マシン９ａが第４仮想マシン１０宛てに送信したパケットの送信元を第５アドレスに変更する。これにより、第４仮想マシン１０では、移動後の第３仮想マシン９ａから送信されたパケットを、第４仮想マシン１０が移動前の第３仮想マシン９宛てに送信したパケットに対する応答であると、正しく認識できる。

図１〜図４に示した運用管理装置３の機能と同様の機能を、運用管理装置４も有する。また図１〜図４に示した運用管理装置４の機能と同様の機能を、運用管理装置３も有する。その結果、マルチクラウドシステムにおいて、仮想マシンが異なるクラウドへ移動しても、移動した仮想マシンの通信相手の仮想マシンにおいて、移動した仮想マシンの位置情報を修正せずに、移動前と同様の通信を行うことができる。また、移動した仮想マシンは、元のクラウド上で動作しているがごとく、管理情報を取得することもできる。その結果、複数のクラウドのそれぞれの利点を活かした柔軟なシステムを容易に構築することができる。

図１〜図４以外の処理として、運用管理装置３，４は、１つのサービス提供要求を、複数のクラウドそれぞれへの複数のサービス提供要求に分割することができる。例えば第１クラウド１で実行されている第１仮想マシン５が、第１サービス６ａと第２サービス７ａとを指定した多重サービス提供要求を出力したものとする。この場合、運用管理装置３は、出力された多重サービス提供要求を、第１サービス６ａのアドレスを送信先とする第１要求と、第２サービス７ａのアドレスを送信先とする第２要求とに分割する。そして運用管理装置３は、第１要求を第１クラウド１内で第１サービス６ａ宛てに送信し、第２要求を第２クラウド２宛てに送信する。第２クラウド２内の運用管理装置４は、第２要求を第２サービス７ａに転送する。このようにして１つの多重サービス提供要求を、異なるクラウド内の複数のサービスへの要求に分割することで、例えば同種のサービスへの多重サービス提供要求が容易となる。

多重サービス提供要求を分割した場合、運用管理装置３は、分割後の複数の要求それぞれへの応答を統合して、多重サービス提供要求に対する１つの応答とすることができる。例えば運用管理装置３は、第１要求に対応する第１応答と第２要求に対する第２応答とを受信するまで、応答を待つ。そして運用管理装置３は、第１応答と第２応答とを受信すると、第１応答と第２応答とを１つにまとめて、多重サービス提供要求の送信元である第１仮想マシン５に応答する。これにより、第１仮想マシン５は、複数のクラウドに跨がったサービスに対する処理要求を、容易に行うことができる。

なお、運用管理装置３，４は、例えば図１〜図４に示す処理手順が記述されたプログラムを実行することにより、図１〜図４に示すマルチクラウド運用方法を実施することができる。運用管理装置３，４は、マルチクラウド運用方法を実施するために、記憶部と処理部とを有する。記憶部は、例えばクラウド内のコンピュータが有するメモリ、またはストレージ装置である。処理部は、例えばクラウド内のコンピュータが有するプロセッサ、または演算回路である。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ＶＭ移動後も処理を継続できることを確認するのに加え、ＶＭ移動後に、それまでＶＭで実行していた処理が実行できなくなることを抑止する機能を備えたマルチクラウドシステムである。

すなわち第２の実施の形態のマルチクラウドシステムは、クラウドを跨がってＶＭを移動する場合、移動先のクラウドに、ＶＭを実行するための資源の空きがあるかを、ＶＭの移動前に確認する。ただし、移動先のクラウドに十分な資源の空きがあったとしても、ＶＭの移動に伴いＩＰアドレスなどの環境設定が変更されることにより、何らかの対策を採らなければ、マルチクラウドシステム内で行われていた処理を継続できなくなる場合がある。継続できなくなる処理として、例えばＶＭ間の通信や、メトリック情報（ＶＭの使用に応じた課金情報、ＶＭの負荷情報など）へのアクセスがある。

ＶＭの移動に伴いＶＭ間の通信ができなくなる原因として、ＩＰアドレスの変更がある。例えば、マルチクラウドシステムでは、複数のＶＭが動的かつ柔軟に配備される。そのため、同じクラウド内に配備された複数のＶＭの一部が、他のクラウドに移動される場合もあり得る。ＶＭがクラウドを跨がって移動する場合、移動先のクラウドでそのＶＭを運用できるように、移動したＶＭのＩＰアドレスが変更される。移動したＶＭのＩＰアドレスの変更に伴い、移動したＶＭと通信していた他のＶＭは、従来であれば、移動したＶＭ宛てのパケットの送信先のＩＰアドレスを変更しなければ、移動したＶＭと通信することができない。しかもクラウド内のＶＭに割り当てられるＩＰアドレスは、そのクラウド内の通信用のローカルなＩＰアドレスであり、複数のクラウドを跨がった通信に利用可能なグローバルなＩＰアドレスではないことが多い。移動したＶＭにローカルなＩＰアドレスが割り当てられると、移動したＶＭと通信していた他のＶＭは、単に宛先のＩＰアドレスの変更だけでは移動したＶＭと通信することはできない。

ＶＭ移動に伴いメトリック情報へのアクセスができなくなる場合もある。メトリック情報とは、ＣＰＵ負荷など、コンピュータの監視結果として得られる情報である。例えば移動元のクラウドと移動先のクラウドとで、ＶＭについてクラウドが管理しているメトリック情報の入手方法が異なる場合がある。この場合、ＶＭがクラウドを跨がって移動すると、そのＶＭのメトリック情報を取得したくても、移動前と同じ手順ではメトリック情報にアクセスできない。しかも各クラウドのメトリック情報へのアクセス用のＩＰアドレスは、クラウドの外部からのアクセスを制限している場合が多い。例えば、クラウド内に起動されたＶＭのユーザに対する課金情報への、そのクラウドの外部からのアクセスは制限される。その結果、ＶＭがクラウドを跨がって移動すると、そのＶＭに関するメトリック情報を取得するのが困難になる。

第２の実施の形態のマルチクラウドシステムでは、複数のクラウド間で共通する識別子をＶＭに付与し、その識別子を介して、ＶＭがクラウドを跨がって移動しても通信可能とする。以下、複数のクラウド間で共通する識別子を、メディエータＩＤと呼ぶ。

図５は、第２の実施の形態のマルチクラウドシステムの一例を示す図である。ユーザが使用する端末装置３１，３２，・・・は、ネットワーク２０を介して複数のクラウド１００，２００に接続されている。クラウド１００は、複数のサーバ１００ａ，１００ｂ，・・・によって実現されている。クラウド２００も、複数のサーバ２００ａ，２００ｂ，・・・によって実現されている。

端末装置３１，３２，・・・のユーザは、２つのクラウド１００，２００それぞれからＶＭの利用環境の提供を受けることができる。そしてユーザは、異なるクラウドから提供されたＶＭを連係動作させることで、目的の処理を実現する。

図６は、サーバのハードウェアの一構成例を示す図である。サーバ１００ａは、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、サーバ１００ａの主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、サーバ１００ａに周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

サーバ１００ａは、以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。他のサーバ１００ｂ，・・・，２００ａ，２００ｂ，・・・もサーバ１００ａと同様のハードウェアにより実現することができる。また、第１の実施の形態に示した運用管理装置３，４も、図６に示したサーバ１００ａと同様のハードウェアにより実現することができる。

サーバ１００ａは、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。サーバ１００ａに実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、サーバ１００ａに実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またサーバ１００ａに実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

１つのクラウド１００では、複数のサーバ１００ａ，１００ｂ，・・・が連係動作し、１つのコンピュータシステムとして機能する。例えばクラウド１００では、複数のサーバ１００ａ，１００ｂ，・・・により、運用管理機能が実現される。クラウド１００，２００間のＶＭの移動は、ＶＭのマイグレーションによって実現されるが、運用管理機能は、ＶＭが移動先で処理を継続できるかどうかの判断や、移動後でも移動前と同様の通信が可能なように、移動したＶＭの通信の中継処理を行う。

図７は、クラウドにおける運用管理機能の一例を示すブロック図である。クラウド１００は、運用管理機能としてメディエータ１２０，１２０ａ，・・・を有する。メディエータ１２０，１２０ａ，・・・は、クラウドＯＳ１１０上で実行される。メディエータ１２０，１２０ａ，・・・は、例えばクラウド１００を利用しているテナントごとに設けられる。例えばメディエータ１２０を使用しているテナントは、クラウド１００内にＶＭ１３１を起動し、ＶＭ１３１を用いて「テナントシステムＡ」を実現する。

クラウドＯＳ１１０は、クラウド１００内のＶＭ１３１およびメディエータ１２０，１２０ａ，・・・を管理する。例えばクラウドＯＳ１１０は、ＶＭ１３１の生成要求に応じてＶＭ１３１を生成する。またクラウドＯＳ１１０は、ＶＭ１３１を利用しているユーザからのＶＭ１３１の移動指示が入力されると、そのＶＭ１３１の移動要求を、メディエータ１２０に送信する。

メディエータ１２０は、ＶＭ１３１の移動要求に応じて、ＶＭ１３１を別のクラウド２００へ移動させる。またメディエータ１２０は、ＶＭ１３１と他のＶＭとの通信を中継することで、ＶＭ１３１または他のＶＭが別のクラウド２００へ移動しても、ＶＭ間の通信を可能とする。またメディエータ１２０は、ＶＭ１３１をクラウド２００に移動させる際には、移動先のクラウド２００内に設けられたメディエータと連係し、ＶＭ１３１が実行している処理が移動先のクラウド２００においても同様に実行可能か否かを判断する。

ＶＭの運用管理のため、メディエータ１２０は、ＩＤ対応変換ＤＢ（Data Base）１２１、位置情報変換ＤＢ１２２、プロトコル変換部１２３、要求メッセージ解析部１２４、管理情報変換部１２５、宛先／メッセージＩＤ管理部１２６、メッセージ返信統合部１２７、メディエータＩＤ生成部１２８、およびＶＭ移動部１２９を有する。

ＩＤ対応変換ＤＢ１２１は、ＶＭの識別子（インスタンスＩＤ）またはメトリック情報提供サービスをクラウド内で識別するメトリックＩＤと、ＶＭをマルチクラウドシステム内で一意に識別するメディエータＩＤとの対応関係を記憶する。

位置情報変換ＤＢ１２２は、ＶＭが現在どのクラウドに配備されているか、ＶＭが過去にどのクラウドに配置されていたのかなどの、ＶＭの位置情報を記憶する。
プロトコル変換部１２３は、外部とのデータの送受信やデータをフックする際、適切に通信できるように通信プロトコルの変換を行う。例えばプロトコル変換部１２３は、ＨＴＴＰ（HyperText Transfer Protocol）、ＲＰＣ（Remote Procedure Call）、ＡＭＱＰ（Advanced Message Queuing Protocol）などの各種プロトコル間で、データフォーマットを相互に変換できる。

要求メッセージ解析部１２４は、ＶＭからの課金情報やＣＰＵ、メモリの監視観測値取得要求に応じ、送信先に応じた要求メッセージへの形式変換を行う。形式変換では、例えば、命令名、引数などが変換される。

管理情報変換部１２５は、独自に表現される各クラウドの管理情報（例えば、インスタンスＩＤやメトリック名など）を管理し、表現形式を相互に変換する。
宛先／メッセージＩＤ管理部１２６は、メッセージの問い合わせ先などをインスタンスＩＤなどから検索し、変換されたメッセージの送信依頼を行う。

メッセージ返信統合部１２７は、要求したメッセージに対する返信メッセージの統合処理を行う。例えばメッセージ返信統合部１２７は、複数のメディエータから送られた返信を１つの返信メッセージに統合する。またメッセージ返信統合部１２７は、同期／非同期処理や、返信メッセージの形式変換処理も行う。

メディエータＩＤ生成部１２８は、ＶＭまたはメトリック情報提供サービスのメディエータＩＤを生成する。例えばメディエータＩＤ生成部１２８は、メディエータ１２０に対応するテナントで使用するＶＭが生成されるごとに、そのＶＭのメディエータＩＤを生成する。メディエータＩＤ生成部１２８は、生成したメディエータＩＤを、ＩＤ対応変換ＤＢ１２１に登録する。またメディエータＩＤ生成部１２８は、生成したメディエータＩＤに関する情報設定用のレコードを、位置情報変換ＤＢ１２２に登録する。

ＶＭ移動部１２９は、クラウドを跨がってＶＭ１３１を移動させる際に、ＶＭ１３１の移動に先立って、移動先のクラウドにおいて移動対象のＶＭ１３１が現在の処理を継続できるか否かを判断する。例えばＶＭ移動部１２９は、クラウドＯＳ１１０からＶＭ１３１の移動要求を取得すると、移動先のクラウドのメディエータと連係して、ＶＭ１３１が現在実行している処理を移動先のクラウドで継続できるか否かを判断する。そしてＶＭ移動部１２９は、移動先のクラウドで処理を継続できることが確認できた場合、ＶＭ１３１の移動（マイグレーション）を実施する。

なお、図７に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図７に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。図７には、クラウド１００における運用管理機能を示したが、他のクラウド２００もクラウド１００と同様の機能を有している。

次にＶＭまたはメトリック情報提供サービスをマルチクラウドシステム内で一意に識別するメディエータＩＤの生成方法について説明する。
図８は、メディエータＩＤの生成例を示す図である。メディエータＩＤは、全世界でユニークなＩＤとする。例えばメディエータの外部アクセス用のＩＰアドレス（メディエータＩＰアドレス）、テナントＩＤ、管理対象種別ＩＤ、および管理対象ＩＤを組み合わせて、全世界でユニークなメディエータＩＤを生成することができる。

メディエータＩＰアドレスは、ＶＭまたはメトリック情報提供サービスを管理しているメディエータのＩＰアドレスである。メディエータＩＰアドレスは、世界規模でのメディエータのユニーク性を保証するアドレスである。

テナントＩＤは、メディエータＩＤの管理対象のＶＭまたはメトリック情報提供サービスを管理するメディエータが属するテナントの識別子である。テナントＩＤは、マルチクラウドシステム内でのメディエータに対応するテナントのユニーク性を保証する識別子である。テナントＩＤは、１つのメディエータで複数のテナントを取り扱う場合に有用となる。

管理対象種別ＩＤは、管理対象（ＶＭまたはメトリック情報提供サービス）の種別を示す識別子である。例えば管理対象がＶＭであれば、管理対象種別ＩＤに「インスタンス」と設定される。また管理対象がメトリック情報提供サービスであれば、管理対象種別ＩＤに、そのメトリック情報提供サービスの名称（例えばＶＭの監視ソフトウェアの名称「モニタ」など）が設定される。

管理対象ＩＤは、同一の管理対象種別の管理対象間でのユニーク性を保証する識別子（ＣＰＵ負荷など）である。
例えばメディエータＩＤは、メディエータＩＰアドレス、テナントＩＤ、管理対象種別ＩＤ、および管理対象ＩＤを組み合わせた値をハッシュ関数で演算して得られるハッシュ値である。ハッシュ関数としては、ＭＤ５（Message Digest Algorithm 5）やＳＨＡ（Secure Hash Algorithm）−１、ＳＨＡ−２などを利用することができる。

例えばメトリック「ＣＰＵ負荷（CPUload）」のメディエータＩＤを算出する場合を想定する。ここでメディエータＩＰアドレスは「221.12.121.129」、テナントＩＤは「fujiLab」、管理対象種別ＩＤは「Ceilometer」、管理対象ＩＤは「CPUload」であるものとする。この場合、「２２１．１２．１２１．１２９＋ｆｕｊｉＬａｂ＋Ｃｅｉｌｏｍｅｔｅｒ＋ＣＰＵｌｏａｄ」を入力として、以下のようにして算出される。
メディエータＩＤ（ＳＨＡ−１［２２１．１２．１２１．１２９＋ｆｕｊｉＬａｂ＋Ｃｅｉｌｏｍｅｔｅｒ＋ＣＰＵｌｏａｄ］）＝ｂ９１ｆ５７ａｂ５ｄ２ｆｄ０６８３ｃ０８７１４ｄ１８２１６９９５
メディエータＩＤを管理対象のＶＭやＶＭのメトリック情報提供サービスごとに生成することで、広域のネットワーク２０全体にわたってユニーク性を保証した識別子を、管理対象に設定することができる。管理対象ごとのメディエータＩＤと、そのメディエータＩＤの生成に用いる情報とは、ＩＤ対応変換ＤＢ１２１で管理される。

図９は、ＩＤ対応変換ＤＢの一例を示す図である。ＩＤ対応変換ＤＢ１２１には、例えばＩＤ対応変換テーブル１２１ａが格納されている。ＩＤ対応変換テーブル１２１ａには、ＶＭまたはメトリック情報提供サービスのメディエータＩＤに対応付けて、メディエータＩＰアドレス、テナントＩＤ、管理対象種別ＩＤ、初期登録時管理対象ＩＤ、および移動先管理対象ＩＤが登録されている。メディエータＩＤ、メディエータＩＰアドレス、テナントＩＤ、管理対象種別ＩＤは、図８を参照して説明した通りである。初期登録時管理対象ＩＤは、ＶＭまたはＶＭのメトリック情報提供サービスを管理対象として最初に登録したときの、その管理対象の管理対象ＩＤである。メディエータＩＤの生成には、初期登録時管理対象ＩＤが使用される。移動先管理対象ＩＤは、管理対象のＶＭなどがクラウドを跨がって移動した場合の移動先における、その管理対象の管理対象ＩＤである。

管理対象のＶＭまたはＶＭのメトリック情報提供サービスが属するクラウドでのアクセス環境に関する情報は、位置情報変換ＤＢ１２２で管理される。
図１０は、位置情報変換ＤＢの一例を示す図である。位置情報変換ＤＢ１２２には、インスタンス管理テーブル１２２ａ、メトリック管理テーブル１２２ｂ、通信環境管理テーブル１２２ｃ、および利用サービスＩＤ対応テーブル１２２ｄが格納されている。

インスタンス管理テーブル１２２ａには、ＶＭのメディエータＩＤに対応付けて、そのＶＭが配備されたことのあるクラウドごとに、そのクラウドにおけるＶＭのインスタンスＩＤと、配備されたクラウドのクラウドＩＤとが設定されている。インスタンスＩＤとクラウドＩＤとの組は、クラウドを跨いでＶＭが移動するごとに、インスタンス管理テーブル１２２ａの下位のレコードとして追加される。

メトリック管理テーブル１２２ｂには、メトリック情報提供サービスのメディエータＩＤに対応付けて、そのメトリック情報提供サービスを管理したことのあるクラウドごとに、そのクラウドにおけるメトリック情報提供サービスのメトリックＩＤと、管理したクラウドのクラウドＩＤとが設定されている。メトリックＩＤとクラウドＩＤとの組は、メトリック情報提供サービスを管理するクラウドが変更されるごとに、メトリック管理テーブル１２２ｂの下位のレコードとして追加される。

通信環境管理テーブル１２２ｃには、管理対象（ＶＭまたはメトリック情報提供サービス）のメディエータＩＤに対応付けて、管理対象のＩＰアドレス・ポート番号、通信のタイプ、管理対象が属するクラウドのクラウドＩＤが設定される。管理対象がＶＭの場合、ＩＰアドレス・ポート番号は、そのＶＭのＩＰアドレスと通信用のポート番号である。また管理対象がメトリック情報提供サービスの場合、ＩＰアドレス・ポート番号は、そのメトリック情報提供サービスにアクセスするためのＩＰアドレスと通信用のポート番号である。タイプは、管理対象にアクセスする際に用いる通信プロトコルである。ＩＰアドレス・ポート番号とタイプとクラウドＩＤとの組は、管理対象を管理するクラウドが変更されるごとに、通信環境管理テーブル１２２ｃの下位のレコードとして追加される。

利用サービスＩＤ対応テーブル１２２ｄには、ＶＭのメディエータＩＤに対応付けて、移動元ＩＰアドレス・ポート番号と移動先ＩＰアドレス・ポート番号とが設定される。移動元ＩＰアドレス・ポート番号は、ＶＭが移動前に利用していたサービスのＩＰアドレスとポート番号である。移動先ＩＰアドレス・ポート番号は、移動後のクラウドにおける同種のサービスのＩＰアドレスとポート番号である。

なお、ＩＤ対応変換ＤＢ１２１と位置情報変換ＤＢ１２２とに格納された情報は、他のメディエータと同期され、複数のクラウド１００，２００内のすべてのメディエータにおいて同じ情報が共有されている。

図７に示した運用管理機能を各クラウド１００，２００が有していることで、ＶＭがクラウド１００，２００を跨がって移動しても、メディエータＩＤに基づいて、マルチクラウドシステム内での情報通信を、問題なく実行することができる。例えばＶＭのメトリック情報として、ＶＭを使用したユーザに対するＶＭの使用量に応じた課金情報がある。マルチクラウドシステムのユーザは、自身が使用したＶＭの総課金額を知りたい場合、任意のＶＭを用いて、各クラウドにおいて課金情報を提供するメトリック情報提供サービスからＶＭの課金情報を収集することとなる。

図１１は、課金情報の収集例を示す図である。例えばマルチクラウドシステムのユーザは、ＶＭ１３１に対して、課金情報の収集を指示する。するとＶＭ１３１は、マルチクラウドシステムを構成するＶＭごとの課金情報取得依頼を、例えばＨＴＴＰで発行する。

ＶＭ１３１が発行した課金情報取得依頼は、メディエータ１２０に送信される。メディエータ１２０では、プロトコル変換部１２３が課金情報取得依頼を、ＨＴＴＰにより受信する。プロトコル変換部１２３は、受信した課金情報取得依頼を、要求メッセージ解析部１２４に送信する。

要求メッセージ解析部１２４は、課金情報取得依頼を解析して、受信したのが課金情報取得依頼であると認識する。そして要求メッセージ解析部１２４は、複数あるメッセージ変換処理のうち、ＶＭごとの課金情報取得処理ルーチンへ入る。要求メッセージ解析部１２４は、課金情報取得処理として、まずＶＭ１３１と同じテナントシステムとして登録された管理対象のインスタンスＩＤとその場所の情報（クラウドＩＤ）の取得要求を、管理情報変換部１２５に送信する。

管理情報変換部１２５は、例えばＩＤ対応変換ＤＢ１２１を参照し、ＶＭ１３１が属するテナントと同じテナントＩＤのＶＭ（管理対象種別ＩＤ「インスタンス」）のメディエータＩＤを取得する。次に管理情報変換部１２５は、位置情報変換ＤＢ１２２のインスタンス管理テーブル１２２ａを参照し、取得したメディエータＩＤで対応するＶＭの現在の位置（クラウドＩＤ）を取得する。管理情報変換部１２５は、取得したインスタンスＩＤと、そのインスタンスＩＤに対応するクラウドＩＤとの組を、要求メッセージ解析部１２４に送信する。

要求メッセージ解析部１２４は、ＶＭごとのインスタンスＩＤとクラウドＩＤとの組を取得すると、取得した情報を指定して、宛先／メッセージＩＤ管理部１２６へ、各クラウドへの課金取得依頼のメッセージ送信を要求する。

宛先／メッセージＩＤ管理部１２６は、課金取得依頼のメッセージを、各クラウドにあったプロトコルやメッセージ形式に変換する。また宛先／メッセージＩＤ管理部１２６は、メッセージが複数になる場合、各メッセージにＩＤを付与する。そして宛先／メッセージＩＤ管理部１２６は、プロトコル変換部１２３へ課金情報取得依頼のメッセージ送信を要求する。

プロトコル変換部１２３は、指定されたプロトコルで各クラウド１００，２００に、課金情報取得要求のメッセージを送信する。例えばプロトコル変換部１２３は、自身が属するクラウド１００のクラウドＯＳ１１０へ、課金情報取得依頼のメッセージを送信する。またプロトコル変換部１２３は、ネットワーク２０を介して接続されたクラウド２００へ、課金情報取得依頼のメッセージを送信する。課金情報取得依頼のメッセージを受信したクラウド２００では、例えばクラウド２００内のメディエータ２２０を介して、クラウドＯＳ２１０がメッセージを取得する。

クラウド１００のクラウドＯＳ１１０は、クラウド１００内のＶＭ１３１を管理しており、ＶＭ１３１の使用状況に応じた課金情報を有している。そしてクラウドＯＳ１１０は、課金情報取得依頼のメッセージをメディエータ１２０から受信すると、ＶＭ１３１の課金情報をメディエータ１２０に返信する。メディエータ１２０は、クラウドＯＳ１１０からの返信を、メッセージ返信統合部１２７に送信する。

クラウド２００のクラウドＯＳ２１０は、クラウド２００内のＶＭ２３１を管理しており、ＶＭ２３１の使用状況に応じた課金情報を有している。そしてクラウドＯＳ２１０は、課金情報取得依頼のメッセージをメディエータ２２０から受信すると、ＶＭ２３１の課金情報を、メディエータ２２０を介してクラウド１００に返信する。クラウドＯＳ２１０からの返信は、メディエータ１２０内のプロトコル変換部１２３を介して、メッセージ返信統合部１２７に送られる。

メッセージ返信統合部１２７は、返信メッセージの同期処理を行う場合、各クラウドＯＳ１１０，２１０からの返信を待ち合わせる。そしてメッセージ返信統合部１２７は、すべてのクラウドＯＳ１１０，２１０からの返信を受信すると、クラウドＯＳ１１０，２１０からの返信メッセージを統合し、統合した課金情報をプロトコル変換部１２３へ出力する。プロトコル変換部１２３は、出力された課金情報を、課金情報取得依頼への返信としてＶＭ１３１に送信する。

メッセージ返信統合部１２７は、返信メッセージを非同期で処理することもできる。返信メッセージを非同期で処理する場合、メッセージ返信統合部１２７は、クラウドＯＳ１１０，２１０それぞれから返信を受信するごとに、課金情報をプロトコル変換部１２３へ出力する。プロトコル変換部１２３は、メッセージ返信統合部１２７から課金情報が出力されるごとに、その課金情報を課金情報取得依頼への返信としてＶＭ１３１に送信する。

このようにして、マルチクラウドシステム内でＶＭを一意に識別可能なメディエータＩＤによってＶＭを指定することで、ＶＭがどのクラウドで稼働していても、そのＶＭのメトリック情報を取得することができる。

以下、メトリック情報の取得依頼に応じたメディエータ１２０の各クラウドＯＳ１１０，２１０への依頼メッセージ送信処理と返信メッセージ受信処理とについて詳細に説明する。

図１２は、依頼メッセージ送信処理の手順の一例を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］メディエータ１２０は、ＶＭ１３１からメトリック情報の取得依頼を示す依頼メッセージを受信する。依頼メッセージには、例えばＶＭ１３１が属するテナントのテナントＩＤと取得するメトリック情報提供サービスの管理対象ＩＤ（ＣＰＵ負荷など）が示される。依頼メッセージは、プロトコル変換部１２３を介して要求メッセージ解析部１２４に送信される。要求メッセージ解析部１２４は、依頼メッセージに示される依頼内容を解析する。

［ステップＳ１０２］要求メッセージ解析部１２４は、依頼内容に応じた処理ルーチンを起動する。そして要求メッセージ解析部１２４は、依頼内容に応じたメトリック情報提供サービスを有するクラウドのクラウドＩＤの取得要求を、管理情報変換部１２５に送信する。

［ステップＳ１０３］管理情報変換部１２５は、メトリック情報提供サービスのメディエータＩＤに基づいて、依頼先のクラウドのクラウドＩＤを取得する。例えば管理情報変換部１２５は、ＩＤ対応変換テーブル１２１ａを参照し、取得するメトリック情報に応じたメトリック情報提供サービスのメディエータＩＤを取得する。取得するメトリック情報が複数のクラウドで管理されている場合、クラウドごとのメディエータＩＤが取得される。例えば依頼メッセージが、ＶＭ１３１が属するテナントのすべてのＶＭのＣＰＵ負荷の取得依頼であれば、該当テナントのテナントＩＤと、ＣＰＵ負荷を示す管理対象ＩＤとを有する各レコードのメディエータＩＤが、ＩＤ対応変換テーブル１２１ａから取得される。管理情報変換部１２５は、メトリック管理テーブル１２２ｂを参照して、取得したメディエータＩＤに対応するメトリック情報提供サービスの最新の位置を示すクラウドＩＤとそのクラウドＩＤに対応するメトリックＩＤとを取得する。最新の位置を示すクラウドＩＤとは、該当メディエータＩＤに対応付けて最後に登録されたクラウドＩＤである。管理情報変換部１２５は、取得したクラウドＩＤとメトリックＩＤとを、要求メッセージ解析部１２４に送信する。要求メッセージ解析部１２４は、クラウドＩＤとメトリックＩＤとを依頼先として指定して、宛先／メッセージＩＤ管理部１２６に依頼メッセージを送信する。

［ステップＳ１０４］宛先／メッセージＩＤ管理部１２６は、依頼先のクラウドが複数あるか否かを判断する。宛先／メッセージＩＤ管理部１２６は、依頼先のクラウドが複数ある場合、処理をステップＳ１０５に進める。また宛先／メッセージＩＤ管理部１２６は、依頼先のクラウドが１つだけであれば、処理をステップＳ１０８に進める。

［ステップＳ１０５］宛先／メッセージＩＤ管理部１２６は、依頼先のクラウドごとに依頼メッセージを分割する。この際、宛先／メッセージＩＤ管理部１２６は、分割したメッセージを、依頼先のクラウドに応じたメッセージ形式に変換する。クラウドごとの依頼メッセージには、例えば該当クラウドにおけるメトリック情報提供サービスのメトリックＩＤが示される。依頼メッセージを受信したクラウドのメディエータは、メトリックＩＤに基づいて依頼先のメトリック情報提供サービスを特定し、そのメトリック情報提供サービスに依頼メッセージを送信する。

［ステップＳ１０６］宛先／メッセージＩＤ管理部１２６は、依頼メッセージに、同期処理である旨の指定があるか否かを判断する。宛先／メッセージＩＤ管理部１２６は、同期処理であれば、処理をステップＳ１０７に進める。また宛先／メッセージＩＤ管理部１２６は、同期処理でなければ処理をステップＳ１０８に進める。

［ステップＳ１０７］宛先／メッセージＩＤ管理部１２６は、分割によって生成された複数のメッセージそれぞれにメッセージＩＤを付与し、同期処理である旨をメッセージ返信統合部１２７に通知する。その後、宛先／メッセージＩＤ管理部１２６は、処理をステップＳ１０９に進める。

［ステップＳ１０８］宛先／メッセージＩＤ管理部１２６は、１または複数の依頼メッセージにメッセージＩＤを付与する。
［ステップＳ１０９］宛先／メッセージＩＤ管理部１２６は、プロトコル変換部１２３へ依頼メッセージ送信を要求する。プロトコル変換部１２３は、プロトコル変換部１２３を介して、依頼先に応じたプロトコルにより、依頼先のクラウドへ依頼メッセージを送信する。

依頼先のクラウドに依頼メッセージを送信すると、依頼メッセージを受信したクラウドから返信メッセージが応答される。
図１３は、返信メッセージ受信処理の手順の一例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。

［ステップＳ１１１］メッセージ返信統合部１２７は、プロトコル変換部１２３を介して、返信メッセージを受信する。
［ステップＳ１１２］メッセージ返信統合部１２７は、返信メッセージの同期処理を行うか否かを判断する。例えばメッセージ返信統合部１２７は、宛先／メッセージＩＤ管理部１２６から同期処理である旨の通知を受け取っている場合、同期処理であると判断する。メッセージ返信統合部１２７は、同期処理であれば、処理をステップＳ１１３に進める。またメッセージ返信統合部１２７は、同期処理でなければ、処理をステップＳ１１５に進める。

［ステップＳ１１３］メッセージ返信統合部１２７は、依頼メッセージを送信したすべてのクラウドからの返信メッセージを受信したか否かを判断する。メッセージ返信統合部１２７は、受信していない返信メッセージがある場合、ステップＳ１１３を繰り返す。またメッセージ返信統合部１２７は、すべての返信メッセージを受信した場合、処理をステップＳ１１４に進める。

［ステップＳ１１４］メッセージ返信統合部１２７は、受信したすべての返信メッセージを１つの返信メッセージに統合する。例えばメッセージ返信統合部１２７は、受信したメッセージそれぞれに含まれるデータすべてをペイロードに含む、１つの返信メッセージを生成する。

［ステップＳ１１５］メッセージ返信統合部１２７は、返信メッセージのＩＤを、依頼メッセージのＩＤに変換する。
［ステップＳ１１６］メッセージ返信統合部１２７は、依頼メッセージの送信元へ返信メッセージを送信する。

このようにしてメディエータＩＤによって、マルチクラウドシステム内でＶＭが移動しても、任意のメトリック情報を取得できる。
次に、ＶＭのメディエータＩＤの管理処理について説明する。

例えばメディエータ１２０は、メディエータＩＤを生成すると、そのメディエータＩＤを他のメディエータに通知し、追加された管理対象のメディエータＩＤをメディエータ間で共有する。またメディエータ１２０は、ＶＭ１３１の通信内容を監視して、ＶＭ１３１の通信先リストを作成する。メディエータ１２０では、ＶＭ１３１の通信先リストを、ＶＭ１３１を他のクラウドに移動させる際に、移動先のクラウドでＶＭ１３１が処理を継続できるか否かの確認要求に利用する。

図１４は、ＶＭのメディエータＩＤ管理処理の手順の一例を示すシーケンス図である。図１４の例には、クラウド１００内にＶＭ１３１が新たに生成されたときの、クラウド１００内のメディエータ１２０と他のクラウド２００内のメディエータ２２０との処理を示している。

ＶＭ１３１が生成されるとメディエータ１２０のメディエータＩＤ生成部１２８が、ＶＭ１３１のメディエータＩＤを生成する（ステップＳ１２１）。メディエータＩＤ生成部１２８は、クラウド２００内のメディエータ２２０に対してメディエータＩＤ共有依頼を送信する（ステップＳ１２２）。メディエータＩＤ共有依頼には、ＶＭ１３１のメディエータＩＤと、そのメディエータＩＤの生成に用いた情報が含まれる。メディエータ２２０では、メディエータＩＤ共有依頼に応じて、メディエータ２２０が有するＩＤ対応変換ＤＢに、ＶＭ１３１のメディエータＩＤと、そのメディエータＩＤの生成に用いた情報とを登録する（ステップＳ１２３）。

クラウド１００内のメディエータ１２０は、生成したＶＭ１３１の通信先リストを作成する（ステップＳ１２４）。通信先リストは、例えばＶＭ１３１の識別子（メディエータＩＤ）に対応付けて、メモリ１０２またはストレージ装置１０３に格納される。例えばメディエータ１２０内のＶＭ移動部１２９が、通信先リストに、ＶＭ１３１が属するテナント内におけるＶＭ１３１の通信相手の、ＩＰアドレスとポート番号（ＶＭ１３１自身のＩＰアドレス・ポート番号を含む）を登録する。またＶＭ移動部１２９は、通信先リストに、ＶＭ１３１が属するテナント外でクラウド１００内に属する、ＶＭ１３１の通信相手の、ＩＰアドレスとポート番号を登録する。さらにＶＭ移動部１２９は、通信先リストに、ＶＭ１３１が属するテナント外でクラウド１００外に属する、ＶＭ１３１の通信相手の、ＩＰアドレスとポート番号を登録する。

ＶＭ移動部１２９は、ＶＭが新たな通信相手と通信したか否かを判断する（ステップＳ１２５）。例えばＶＭ移動部１２９は、通信先リストに登録されていないＩＰアドレスとポート番号との組を通信相手としたパケットの送受信をＶＭ１３１が行った場合、新たな通信相手と通信したと判断する。ＶＭ移動部１２９は、ＶＭ１３１が新たな通信相手と通信した場合、処理をステップＳ１２４に進め、新たな通信相手のＩＰアドレスとポート番号との組を、通信先リストに追加する。

ＶＭ１３１が新たな通信相手と通信していなければ、ＶＭ移動部１２９は、ＶＭ１３１が存在しなくなったか否かを判断する（ステップＳ１２６）。例えばＶＭ移動部１２９は、クラウドＯＳ１１０によってＶＭ１３１が削除された場合、ＶＭ１３１は存在しなくなったと判断する。ＶＭ移動部１２９は、ＶＭ１３１がまだ存在していれば、処理をステップＳ１２５に進め、ＶＭ１３１が新たな通信相手と通信するか否かを監視する。またＶＭ移動部１２９は、ＶＭ１３１が存在しなくなったら処理を終了する。

このようにして、ＶＭ１３１が生成された際に、ＶＭ１３１を一意に識別可能なメディエータＩＤが生成されると共に、そのメディエータＩＤがマルチクラウドシステム内のすべてのメディエータで保持される。さらにＶＭ１３１の通信相手が通信先リストで管理される。クラウドを跨がってＶＭ１３１が移動する際、通信先リストに基づいて、ＶＭ１３１の通信相手との通信が移動先のクラウドでも同様に可能かどうかを確認することができる。

図１５は、ＶＭ移動処理の手順の一例を示すシーケンス図である。図１５の例では、ＶＭ１３１のクラウド２００への移動要求が、クラウドＯＳ１１０からメディエータ１２０に送信された場合を想定している。メディエータ１２０では、ＶＭ移動部１２９が、ＶＭ１３１を移動した後に、現在と同等の性能が確保できることの確認依頼（性能充足確認依頼４１）を、クラウド２００内のメディエータ２２０に送信する（ステップＳ１３１）。性能充足確認依頼４１には、例えば確認リストが含まれる。確認リストには、ＶＭ１３１の通信相手（ＶＭまたはメトリック情報提供サービス）のＩＰアドレスと通信ポート、ＶＭ１３１の性能情報などが含まれる。例えばテナント内のサービスを継続して利用可能なことが分かっている場合、図１４のステップＳ１２４で作成した通信先リストのうち、テナント外の送信先のＩＰアドレスとポート番号が、確認リストに含められる。ＶＭ１３１の性能情報には、例えばＶＭ１３１の実行に使用するＣＰＵコア数、メモリ容量、ストレージ容量などの使用する資源量に関する情報が含まれる。

性能充足確認依頼４１を受信したメディエータ２２０では、メディエータ２２０内のＶＭ移動部が性能充足確認処理を行う（ステップＳ１３２）。性能充足確認処理では、例えば確認リストに示されている通信ポートで提供されているサービスにアクセスできるか否か、性能情報で示される性能と同等以上の性能を確保できるか否かなどが判断される。

メディエータ２２０内のＶＭ移動部は、性能充足確認処理による確認結果４２をメディエータ１２０に送信する（ステップＳ１３３）。確認結果４２には、確認リストに示されている通信ポートで提供されているサービスにアクセスできるか否か、性能情報で示される性能と同等以上の性能を確保できるか否かなどが示される。

メディエータ１２０のＶＭ移動部１２９は、確認結果４２に基づいて、ＶＭ１３１がクラウド１００内で使用していたサービスが、クラウド２００にも存在するか否かを判断する（ステップＳ１３４）。例えばＶＭ移動部１２９は、クラウド２００においても、ＶＭ１３１がクラウド１００内で利用しているサービス用のポート番号を介して、同種のサービスにアクセス可能であれば、該当サービスが存在すると判断する。ＶＭ移動部１２９は、ＶＭ１３１がクラウド１００で利用しているすべてのサービスがクラウド２００にも存在する場合、処理をステップＳ１３５に進める。またＶＭ移動部１２９は、ＶＭ１３１がクラウド１００で使用しているサービスのうちの少なくとも１つが、クラウド２００に存在しない場合、ＶＭ１３１を移動させずに処理を終了する。

移動先のクラウド２００においてもすべてのサービスが提供可能であれば、ＶＭ移動部１２９は、移動先のクラウド２００においてＶＭ１３１が十分な性能を得ることができるか否かを判断する（ステップＳ１３５）。例えばＶＭ移動部１２９は、確認結果４２においてＶＭ性能の確認の結果、十分な性能があると示されていれば、十分な性能を得ることができると判断する。ＶＭ移動部１２９は、移動先のクラウド２００において、ＶＭ１３１が十分な性能を得ることができる場合、処理をステップＳ１３６に進める。またＶＭ移動部１２９は、ＶＭ１３１をクラウド２００に移動させると十分な性能を得ることができない場合、ＶＭ１３１を移動させずに処理を終了する。

移動しても十分な性能を得ることができる場合、ＶＭ移動部１２９は、マイグレーション処理を実行し、ＶＭ１３１をクラウド２００に移動させる（ステップＳ１３６）。この際、ＶＭ移動部１２９は、クラウド２００内のメディエータ２２０に、ＶＭ１３１のメディエータＩＤと、ＶＭ１３１が利用するサービスのＩＰアドレスと通信ポートとの組を示す利用サービス情報４３を送信する。

クラウド２００のメディエータ２２０は、移動後のＶＭにクラウド２００内でのＩＰアドレスを付与する（ステップＳ１３７）。この際、メディエータ２２０は、移動後のＶＭのプロキシとして、メディエータ２２０のＩＰアドレスを設定する。さらにメディエータ２２０は、ＶＭ１３１のメディエータＩＤに対応付けて、利用サービスＩＤ対応テーブルに、利用サービス情報に示されるＩＰアドレス・ポート番号と、対応するクラウド２００内のサービスのＩＰアドレス・ポート番号とを登録する（ステップＳ１３８）。その後、メディエータ２２０は、移動したＶＭ１３１を稼働させる（ステップＳ１３９）。ＶＭ１３１の稼働が完了すると、メディエータ２２０は、稼働完了通知をクラウド１００のメディエータ１２０に送信する（ステップＳ１４０）。

クラウド１００のメディエータ１２０は、稼働完了通知を受信すると、クラウド１００でのＶＭ１３１の稼働を停止する（ステップＳ１４１）。
このようにして、移動前と同様の処理を同様の性能で実行できることを確認した上で、ＶＭ１３１を移動することができる。しかもＶＭ１３１を移動させたとき、移動先のメディエータ２２０において、利用サービスＩＤ対応テーブルに、移動元と移動先との利用サービスのＩＰアドレス・ポート番号の対応関係を登録している。これにより、ＶＭ１３１が移動後にサービスを利用する際に、サービスを指定するＩＰアドレスとポート番号を、移動先のクラウド２００に応じたＩＰアドレスとポート番号に容易に変更することができる。

以下、図１６を参照して、ＶＭ１３１がＣＰＵ負荷取得サービスを利用している場合のＶＭ１３１の移動例について説明する。
図１６は、ＣＰＵ負荷取得サービスを利用しているＶＭの移動例を示す図である。クラウド１００のメディエータ１２０は、ＶＭ１３１をクラウド２００に移動させる（ステップＳ１５１）。これにより、クラウド２００内にＶＭ１３１と同じ機能と性能とを有するＶＭ１３１ａが生成される。なおメディエータ１２０は、ＶＭ１３１を移動させる際に、利用サービス情報４３をメディエータ２２０に送信する。利用サービス情報４３には、ＣＰＵ負荷取得用のＩＰアドレスと通信ポートのポート番号とが示されている。

メディエータ２２０は、移動後のＶＭ１３１ａにクラウド２００内でのＩＰアドレス（１９２．１６９．１００．２２）を付与する（ステップＳ１５２）。この際、メディエータ２２０は、ＶＭ１３１ａのプロキシサーバとして、メディエータ２２０のＩＰアドレスを設定する。そしてメディエータ２２０は、ＶＭ１３１ａの稼働を開始させる（ステップＳ１５３）。ＶＭ１３１ａは、稼働が開始すると、稼働完了通知をメディエータ２２０に送信する（ステップＳ１５４）。

メディエータ２２０は、移動元と移動先とにおける、サービスを利用するためのアクセス先の対応関係を、ＶＭ１３１ａのメディエータＩＤに対応付けて利用サービスＩＤ対応テーブルに登録する（ステップＳ１５５）。クラウド２００内でのＣＰＵ負荷取得用のＩＰアドレスとポート番号が「１７２．２２２．０．７７：９０００」の場合、利用サービスＩＤ対応テーブルに「（１７２．１００．０．８０：８９８９）→（１７２．２２２．０．７７：９０００）」と登録される。作成された利用サービスＩＤ対応テーブルは、ＶＭ１３１ａのメディエータＩＤに対応付けて、例えばメモリに保持される。

例えばメディエータ２２０は、自身が有するＩＤ対応変換テーブル（メディエータ１２０のＩＤ対応変換テーブル１２１ａと同じ内容）を参照して、各メディエータでのＣＰＵ負荷取得のサービス（管理対象ＩＤが「ＣＰＵ負荷」）のメディエータＩＤを取得する。次に、メディエータ２２０は、自身が有する通信環境管理テーブル（メディエータ１２０の通信環境管理テーブル１２２ｃと同じ内容）を参照して、取得したメディエータＩＤに対応するＩＰアドレスとポート番号を取得する。メディエータ２２０は、メディエータ１２０におけるＣＰＵ負荷取得サービスのＩＰアドレス・ポート番号を移動元ＩＰアドレス・ポート番号とし、メディエータ２２０におけるＣＰＵ負荷取得サービスのＩＰアドレス・ポート番号を移動先ＩＰアドレス・ポート番号とする。そしてメディエータ２２０は、メディエータ２２０が有する利用サービスＩＤ対応テーブルに、移動したＶＭ１３１のメディエータＩＤに対応付けて、移動元ＩＰアドレス・ポート番号と移動先ＩＰアドレス・ポート番号との組を登録する。

メディエータ２２０は、ＶＭ１３１ａから稼働完了通知を受信すると、稼働完了通知を、移動元のクラウド１００のメディエータ１２０に送信する（ステップＳ１５６）。メディエータ１２０は、稼働完了通知を受信すると、ＶＭ１３１の稼働停止制御を行う（ステップＳ１５７）。その結果、ＶＭ１３１の稼働が停止する（ステップＳ１５８）。

その後、クラウド２００内で稼働しているＶＭ１３１ａがＣＰＵ負荷要求を出力する（ステップＳ１５９）。ＶＭ１３１ａは、クラウド１００内で稼働していたときと同じ環境設定で動作しているため、このＣＰＵ負荷要求の送信先は、クラウド１００におけるＣＰＵ負荷取得サービス宛てであり、宛先は（１７２．１００．０．８０：８９８９）である。

メディエータ２２０は、ＣＰＵ負荷要求を取得すると、利用サービスＩＤ対応テーブルに基づいて、ＣＰＵ負荷要求の宛先を（１７２．１００．０．８０：８９８９）から（１７２．２２２．０．７７：９０００）に変換する。そしてメディエータ２２０は、ＣＰＵ負荷要求をクラウドＯＳ２１０に送信することで、クラウドＯＳ２１０からＣＰＵ負荷情報４４を取得する（ステップＳ１６０）。メディエータ２２０は、クラウドＯＳ２１０から取得したＣＰＵ負荷情報４４を、ＶＭ１３１ａに送信する（ステップＳ１６１）。

このようにして、ＶＭ１３１は、クラウドを跨がった移動後においても、移動前と同様にＣＰＵ負荷情報を取得することができる。
次に、ＶＭ１３１が移動後に、移動前に通信していた他のＶＭと通信する例について説明する。

図１７は、ＶＭ間通信を行うＶＭの移動例を示す図である。クラウド１００のメディエータ１２０は、ＶＭ１３１をクラウド２００に移動させる（ステップＳ１７１）。メディエータ２２０は、移動後のＶＭ１３１ａにクラウド２００内でのＩＰアドレス（１９２．１６９．１００．２２）を付与する（ステップＳ１７２）。そしてメディエータ２２０は、ＶＭ１３１ａの稼働を開始させる（ステップＳ１７３）。ＶＭ１３１ａは、稼働が開始すると、稼働完了通知をメディエータ２２０に送信する（ステップＳ１７４）。

メディエータ２２０は、ＶＭ１３１ａから稼働完了通知を受信すると、稼働完了通知を、移動元のクラウド１００のメディエータ１２０に送信する（ステップＳ１７５）。メディエータ１２０は、稼働完了通知を受信すると、ＶＭ１３１の稼働停止制御を行う（ステップＳ１７６）。その結果、ＶＭ１３１の稼働が停止する（ステップＳ１７７）。

その後、ＶＭ１３１ａは、移動元のクラウド１００内のＶＭ１３２宛てにパケットを送信する（ステップＳ１７８）。送信されたパケットは、メディエータ２２０で受信される。

メディエータ２２０は、自身が有する通信環境管理テーブル（メディエータ１２０が有する通信環境管理テーブル１２２ｃと同じ内容）から、パケットを送信したＶＭ１３１ａのＩＰアドレスに対応するメディエータＩＤを取得する。そしてメディエータ２２０は、取得したメディエータＩＤに基づいて、ＶＭ１３１ａの移動前のＶＭ１３１が存在していたクラウド１００のＶＭ１３２へパケットを転送する（ステップＳ１７９）。この際、メディエータ２２０は、パケットの送信元のアドレスを、移動後のＶＭ１３１ａのアドレス「１９２．１６９．１００．２２」から移動前のＶＭ１３１のアドレス「１９２．１６９．０．１１」に変更する。

転送されたパケットはメディエータ１２０で受信され、メディエータ１２０がそのパケットをＶＭ１３２に転送する（ステップＳ１８０）。ＶＭ１３２は、パケットを受信し、移動前のＶＭ１３１のアドレス「１９２．１６９．０．１１」を宛先として、返信のパケットを送信する（ステップＳ１８１）。返信パケットはメディエータ１２０で受信される。

メディエータ１２０は、通信環境管理テーブル１２２ｃから、返信パケットの送信先のＶＭ１３１のメディエータＩＤを取得する。そしてメディエータ１２０は、取得したメディエータＩＤに基づいて、クラウド２００上の移動後のＶＭ１３１ａへ返信パケットを転送する（ステップＳ１８２）。この際、メディエータ１２０は、返信パケットの送信先のアドレスを、移動前のＶＭ１３１のアドレス「１９２．１６９．０．１１」から移動後のＶＭ１３１ａのアドレス「１９２．１６９．１００．２２」に変更する。クラウド２００では、メディエータ２２０が返信パケットを受信し、その返信パケットを移動後のＶＭ１３１ａに転送する（ステップＳ１８３）。

以上説明したように、第２の実施の形態によれば、ＶＭやメトリック情報提供サービスなど、クラウド上で管理対象となる要素に対して、グローバルに一意に識別可能なメディエータＩＤを付与している。これによりクラウドを跨がってＶＭを移動させても、メディエータにおいて、各ＶＭを一意に識別でき、各ＶＭの複数のクラウドそれぞれでのＩＰアドレスなどを容易に管理できる。その結果、移動したＶＭによる移動前と同様の情報取得や、ＶＭ間通信が可能となっている。

なおメディエータＩＤ以外にも、グローバルなアドレスの表記方法があるが、それぞれ以下のような問題があり、マルチクラウドシステムにおいて実用的ではない。
グローバルなアドレスの第１の例として、ＦＱＤＮ（Fully Qualified Domain Name）がある。ＦＱＤＮでは、クラウド内のＶＭのＩＰアドレスまでは表現が難しい。またＦＱＤＮは、ＶＭが別のクラウドに移行した場合、その表記を修正することとなり、ＶＭがクラウドを跨がって移動した際に同一性を保持できない。

グローバルなアドレスの第２の例として、ＩＰＶ６のインタフェースＩＤがある。このインタフェースＩＤをベースにした通信はＬＡＮ（Local Area Network）内に限られる。またＩＰＶ６のインタフェースＩＤは、ＭＡＣ（Media Access Control）アドレスから生成されるため、ＶＭが別のクラウドへ移動した場合、そのＭＡＣアドレスが修正され、インタフェースＩＤが修正される場合がある。

グローバルなアドレスの第３の例として、ＭｏｂｉｌｅＩＰがある。ＭｏｂｉｌｅＩＰでは、相手のインスタンスＩＤを取得する場合において、そのＶＭが稼働しているクラウドにおけるＶＭのインスタンスＩＤ取得用のアクセスＩＰアドレスが不明の場合は、インスタンスＩＤを取得できず、通信が行えない。仮に、インスタンスＩＤ取得用のアクセスＩＰアドレスを外部に公開されたエージェントに登録しておいても、その取得アクセスＡＰＩ（Application Programming Interface）やプロトコルがクラウドごとに異なる場合がある。この場合、取得アクセスＡＰＩなどの差異をアプリケーションやエージェントで吸収するのは困難である。

なお上記の３つの例で共通の問題として、メトリック情報へアクセスするＲＥＳＴ（REpresentationalState Transfer）ＡＰＩのＩＰアドレスは外部からアクセスできず、クラウドを跨がってＲＥＳＴＡＰＩを介した情報取得ができないことがある。そのＩＰアドレスをエージェントに登録したり、ＦＱＤＮで表現したり、ＩＰＶ６で直接アクセスしたりすることはできない。

第２の実施の形態によれば、各ＶＭやメトリック情報提供サービスにグローバルな識別子としてメディエータＩＤを付与し、そのメディエータＩＤを各クラウドのメディエータが管理している。これによりＶＭがクラウドを跨がって移動しても、継続してＶＭを一意に識別でき、各ＶＭに関する情報を適切に管理することができる。

〔その他の実施の形態〕
第１・第２の実施の形態では、クラウドが２つの場合について説明しているが、第１・第２の実施の形態に示した処理は、クラウドが３つ以上のマルチクラウドシステムにも同様に適用できる。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ 第１クラウド
２ 第２クラウド
３，４ 運用管理装置
５，５ａ 第１仮想マシン
６，７ サーバ
６ａ 第１サービス
７ａ 第２サービス

Claims (7)

1. コンピュータに、
   第１クラウドコンピューティングシステム内で実行されている第１仮想マシンが利用した第１サービスのポート番号を、前記第１仮想マシンの識別子に対応付けて記憶し、
   前記第１仮想マシンの第２クラウドコンピューティングシステムへの移動要求を受信すると、前記第２クラウドコンピューティングシステムに対して、前記第１サービスの前記ポート番号を指定して、前記第２クラウドコンピューティングシステムにおいて前記ポート番号に対応する第２サービスが利用可能か否かの確認要求を送信し、
   前記確認要求に対して、前記第２クラウドコンピューティングシステムから前記第２サービスが利用可能であるとの回答を受信すると、前記第１仮想マシンを前記第２クラウドコンピューティングシステムへ移動させる、
   処理を実行させるマルチクラウド運用プログラム。
2. 前記コンピュータに、さらに、
   前記第２クラウドコンピューティングシステム内で実行されていた第２仮想マシンが、前記第１クラウドコンピューティングシステムに移動した場合、前記第２クラウドコンピューティングシステムから、前記第２仮想マシンが利用していた前記第２サービスへのアクセス用の第２アドレスを取得し、
   前記第１クラウドコンピューティングシステム内で前記第２サービスと同種のサービスを提供する前記第１サービスへのアクセス用の第１アドレスと、取得した前記第２アドレスとの対応関係を示す対応表を記憶し、
   移動後の前記第２仮想マシンから前記第２アドレスを指定したサービス提供要求を受信すると、前記対応表に基づいて、前記サービス提供要求の送信先を前記第１アドレスに変更する、
   処理を実行させる請求項１記載のマルチクラウド運用プログラム。
3. 前記コンピュータに、さらに、
   移動後の前記第１仮想マシンの前記第２クラウドコンピューティングシステム内での第４アドレスを、前記第２クラウドコンピューティングシステムから取得し、
   前記第１仮想マシンの前記第１クラウドコンピューティングシステム内での第３アドレスと前記第４アドレスとを対応付けて記憶し、
   前記第１仮想マシンが前記第２クラウドコンピューティングシステムに移動した後は、前記第１クラウドコンピューティングシステム内で発生した前記第３アドレスを送信先とするパケットの送信先を前記第４アドレスに変更して、送信先変更後のパケットを前記第２クラウドコンピューティングシステムに転送する、
   処理を実行させる請求項１または２記載のマルチクラウド運用プログラム。
4. 前記コンピュータに、さらに、
   前記第２クラウドコンピューティングシステム内で第３仮想マシンが生成されると、前記第２クラウドコンピューティングシステムから、前記第３仮想マシンの前記第２クラウドコンピューティングシステム内での第５アドレスを取得し、
   前記第２クラウドコンピューティングシステム内で第４仮想マシンが生成されると、前記第２クラウドコンピューティングシステムから、前記第４仮想マシンの前記第２クラウドコンピューティングシステム内での第６アドレスを取得し、
   前記第３仮想マシンが前記第１クラウドコンピューティングシステムに移動した場合、移動前の前記第３仮想マシンの前記第５アドレスに対応付けて、移動後の前記第３仮想マシンの前記第１クラウドコンピューティングシステム内での第７アドレスを記憶し、
   移動後の前記第３仮想マシンが、前記第４仮想マシンの前記第６アドレスを送信先とするパケットを出力した場合、出力されたパケットの送信元のアドレスを前記第６アドレスに変更して、送信元変更後のパケットを前記第２クラウドコンピューティングシステムに転送する、
   処理を実行させる請求項１ないし３のいずれかに記載のマルチクラウド運用プログラム。
5. 前記コンピュータに、さらに、
   移動前の前記第１仮想マシンが、前記第１サービスと前記第２サービスとを指定した多重サービス提供要求を出力すると、前記多重サービス提供要求を、前記第１サービスのアドレスを送信先とする第１要求と、前記第２サービスのアドレスを送信先とする第２要求とに分割し、
   前記第１要求を前記第１クラウドコンピューティングシステム内で前記第１サービス宛てに送信し、前記第２要求を前記第２クラウドコンピューティングシステムに送信する、
   処理を実行させる請求項１ないし４のいずれかに記載のマルチクラウド運用プログラム。
6. 前記コンピュータに、さらに、
   前記第１要求に対応する第１応答と前記第２要求に対する第２応答とを受信するまで、応答を待ち、
   前記第１応答と前記第２応答とを受信すると、前記第１応答と前記第２応答とを１つにまとめて、前記第１仮想マシンに応答する、
   処理を実行させる請求項５記載のマルチクラウド運用プログラム。
7. コンピュータが、
   第１クラウドコンピューティングシステム内で実行されている第１仮想マシンが利用した第１サービスのポート番号を、前記第１仮想マシンの識別子に対応付けて記憶し、
   前記第１仮想マシンの第２クラウドコンピューティングシステムへの移動要求を受信すると、前記第２クラウドコンピューティングシステムに対して、前記第１サービスの前記ポート番号を指定して、前記第２クラウドコンピューティングシステムにおいて前記ポート番号に対応する第２サービスが利用可能か否かの確認要求を送信し、
   前記確認要求に対して、前記第２クラウドコンピューティングシステムから前記第２サービスが利用可能であるとの回答を受信すると、前記第１仮想マシンを前記第２クラウドコンピューティングシステムへ移動させる、
   マルチクラウド運用方法。

Images