JP2014049944A - 仮想クラウドコンピュータ及びプログラム - Google Patents

Abstract

【課題】従来手法によると、複数のクラウドインフラ間で仮想マシンを移行する場合に、ＯＳ等のアドレス変更及びその検証作業が必要とされるだけでなく、移行そのものが困難である場合があった。また、移行先でのデータの秘匿性に懸念があった。
【解決手段】仮想クラウドコンピュータとして、仮想ネットワーク・インタフェースと、前記仮想ネットワーク・インタフェースよりも上位レイヤに位置し、上位レイヤからの通信データをそのアドレス情報も含めてカプセル化する一方で、前記仮想ネットワーク・インタフェースからの通信データをデカプセル化する中間レイヤとを有するものを提案する。
【選択図】図４

Description

本発明は、クラウドコンピューティング・サービス（以下「クラウドサービス」という）を提供するシステム（以下「クラウドシステム」という）を構成する仮想クラウドコンピュータ及び当該コンピュータで実行されるプログラムに関する。

現在、様々なビジネス領域において、クラウドサービスの利用が検討されている。サービスの利用に際しては、企業や団体が保持・運用しているサーバを、クラウドサービスを提供する外部事業者（以下「クラウド事業者」という）側の環境に仮想的に移行する必要がある。

この移行技術が、例えば特許文献１や非特許文献１に開示されている。特許文献１は、ネットワークを介して複数の仮想サーバを外部システムに移行する場合におけるＯＳ等のアドレス変更と動作の検証を行う際の作業量を削減する目的で、設定の正しさを確認するパケットの送受信処理を自動化する技術を開示する。非特許文献１は、クラウドインフラストラクチャ（以下「クラウドインフラ」という）上のインスタンスとネットワーク・インタフェースの設定を別々に管理し、インスタンスの起動・停止の度に、仮想ネットワーク・インタフェースを追加・削除する機能を提供し、特定のインスタンスの物理アドレスに紐付いてライセンシングを行っている商用ソフトウェアを同一のインフラ上の別インスタンスに簡単に移行する技術を開示する。

特開２０１１−１９２０９８号公報

AWS, "Virtual Private Cloudの中でネットワーク・インタフェースを自在にコントロールできるElastic Network Interfaceの発表", [平成24年8月2日検索], インターネット<URL:http://aws.typepad.com/aws_japan/2011/12/new-elastic-network-interfaces-in-the-virtual-private-cloud.html>

しかし、特許文献１に記載の技術は、動作の検証に伴う作業量の削減を目的とするものであり、ＯＳ等のアドレス変更はオペレータ自身が行う必要がある。このため、データ移行に伴う全体の作業量は、依然として高いままであるという技術的課題がある。

一方、非特許文献１に記載の技術は、クラウド事業者の仮想化インフラが定義する仮想ネットワーク・インタフェースの物理アドレスの体系が、別の組織（企業インフラ等）で保持されるサーバインスタンスの物理アドレスと異なっている。このため、同技術によれば、インスタンスのイメージデータを単純に変換することはできても、物理アドレス等のネットワークアドレスの設定については変更することができない。このため、正常動作が期待できず、結局のところ、企業等のサーバを、クラウドインフラの側に移行することができない問題がある。また、アプリケーション等のソフトウェアライセンスが特定のアドレスに紐付けられている場合、非特許文献１に記載の技術による移行後に、当該アプリケーションが使用できなくなる弊害もある。この場合において、クラウドインフラにおいてアプリケーションを使えるようにするためには、別途ライセンスを発行するか、又は、ライセンスを新規に購入しなければならない。

また一般に、仮想化インフラでは、提供サービス毎に、接続できるネットワーク・インタフェースの数が異なっている。このため、移行元のインフラと同じ数のネットワーク・インタフェース（アドレス）を、移行先のインフラで付与できない場合、仮想サーバを物理的に移行できない技術課題もある。

さらに、現状の仮想化インフラでは、ＶＰＮ（Virtual Private Network）装置で終端された後の通信は、平文の形態で行われており、秘匿性について重大な問題がある。
このように、現在のクラウドシステム及び移行技術には、未だ解決すべき課題が存在する。

そこで、発明者は、１つの発明として、仮想ネットワーク・インタフェースと、当該仮想ネットワーク・インタフェースよりも上位レイヤに位置し、上位レイヤからの通信データをそのアドレス情報も含めてカプセル化する一方で、仮想ネットワーク・インタフェースからの通信データをデカプセル化する中間レイヤとを有する仮想クラウドコンピュータを提供する。

また、発明者は、別の発明として、仮想ネットワーク・インタフェースと、当該仮想ネットワーク・インタフェースよりも上位レイヤに位置し、上位レイヤからの通信データを暗号化する一方で、仮想ネットワーク・インタフェースからの通信データを復号化する中間レイヤとを有する仮想クラウドコンピュータを提供する。

１つの発明によれば、ＯＳ等のアドレスを移行前の状態のまま使用することができ、移行に伴う作業量を低減することができる。また、１つの発明によれば、異なる物理アドレス体系を有するインフラ間でも仮想マシン等を移行することができる。また、１つの発明によれば、ネットワーク・インタフェースの数が異なるインフラ間でも仮想サーバ等を移行することができる。
また、別の発明によれば、移行先のインフラ内における通信データの秘匿性を高めることができる。
前述以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

従来型の仮想プライベート・クラウドシステムの概念構成とその技術課題の一つを説明する図。 従来型の仮想プライベート・クラウドシステムにおいて仮想マシンを移行する場合の技術課題を説明する図。 仮想プライベート・クラウドシステムの実施例を説明する図。 実施例に係るシステムによるＭＡＣアドレスの仮想化技術を説明する図。 実施例で使用するＮＩ管理テーブルの構成例を示す図。 実施例に係るシステムによるデータの転送方法を説明する図。 実施例に係るシステムによる転送データのカプセル化方法を説明する図。 仮想ＮＩＣによる通信データのカプセル化／データ転送処理手順を説明するフローチャート。 仮想ＮＩＣによるＮＩ管理テーブルの更新処理手順を説明するフローチャート。

発明の実施するための形態

以下、図面に基づいて、本発明の実施例を説明する。なお、本発明の実施の形態は、後述する実施例に限定されるものではなく、その技術思想の範囲において、種々の変形が可能である。

（従来システムの構成及び技術課題）
まず、従来のシステム構成とその技術課題を説明する。図１は、仮想プライベート・クラウドシステムの従来例である。図１は、特定組織内に構築されるインフラ（以下「特定組織インフラ」という）１が、インターネット経由で、「クラウド事業者１」のインフラ２及び「クラウド事業者２」のインフラ３に接続される場合を表している。図２は、特定組織インフラ１と「クラウド事業者１」のインフラ２の間において、仮想マシンを移行する場合の技術課題を表している。

クラウドシステムでは、クラウド事業者が巨大なコンピュータ資源を用意し、複数・多数の利用者が当該資源をあたかも自身のコンピュータ資源であるかのように利用する。伝統的に、企業等では、情報インフラを社内に保有するのが一般であった。しかし、昨今、情報インフラの保有が経営リスクの一つとして認識されるに至り、リスク軽減の観点から、クラウド事業者が提供するインフラを組織内のインフラと併用する機運が高まっている。

ただし、インターネット経由によるデータ通信には、情報漏洩等に対する対策が必要となる。一般には、ＶＰＮ（Virtual Private Network）装置１１、２１、３１を利用して仮想プライベートネットワークを構成し、インターネット上での情報漏洩等を防いでいる。因みに、仮想プライベートネットワークを通じて接続されたインフラの構成要素（以下「仮想プライベートクラウド」という）１０、２０、３０は、物理的な配置場所に関係なく、論理的に同一のネットワークで接続される。このため、外部からの想定外のアクセスを全て遮断することができ、インターネット上での通信の安全が確保される。

一般に、仮想プライベートクラウドは、１つ又は複数の仮想マシンで構成される。図１では、仮想プライベートクラウド１０を構成する仮想マシンを「ＶＭ１１」１１０、「ＶＭ１２」１２０で表し、仮想プライベートクラウド２０を構成する仮想マシンを「ＶＭ２１」２１０、「ＶＭ２２」２２０で表し、仮想プライベートクラウド３０を構成する仮想マシンを「ＶＭ３１」３１０、「ＶＭ３２」３２０で表している。もっとも、仮想マシンを一般的なコンピュータ資源に置き換えても、本発明の適用範囲に含まれる。本明細書では、ここでの仮想マシン及びコンピュータ資源を、「仮想クラウドコンピュータ」ともいう。

ところが、図１に示すように、通信の安全が確保されるのは、ＶＰＮ装置間のみであり、その外側に位置するネットワーク上では、平文データが流れることになる。このことは、クラウド事業者の内部ネットワークを平文データが流れること、すなわち、クラウド事業者のオペレータが参照できる状態にあることを意味する。しかし、この状態は、クラウドサービスの利用者にとっては、セキュリティ上の重大な問題である。

さらに、現状のクラウドシステムには、前述したように、クラウド間における仮想マシンの移行に技術的問題又は制約がある。以下、この問題等を、図２を用いて説明する。

図２は、特定組織インフラ１で稼働中の「仮想化ソフトウェア１」１３に割り当てられた「ＶＭ１１」１１０を、「クラウド事業者１」のインフラストラクチャ２で稼働する「仮想化ソフトウェア２」２３に移行する例を概念的に表したものである。

図２の例は、「ＶＭ１１」１１０の「ＯＳ１１」１１０３の上位レイヤにおいて、ＴＣＰ／ＩＰプロトコルスタック１１０２と、２つの仮想ネットワーク・インタフェース１１０４、１１０５が稼働する場合を表している。また、これら２つの仮想ネットワーク・インタフェース１１０４、１１０５に対しては、それぞれ別のＭＡＣアドレス（例えば「AA:AA:AA:A1」、「AA:AA:AA:A2」）と、別のＶＬＡＮ ＩＤ（例えば「VLAN1」、「VLAN2」）が付与されているものとする。また、仮想マシンの移行先である「クラウド事業者１」のインフラ２で稼働する「仮想化ソフトウェア２」２３には、仮想マシンに対し、仮想ネットワーク・インタフェースを１つまでしか接続できないものとする。また、「仮想化ソフトウェア２」２３では、仮想ネットワーク・インタフェース１１０４のＭＡＣアドレスが「BB:BB:BB:B1」であるものとする。

ところが、図２のように、仮想ネットワーク・インタフェースに割り当てられるＭＡＣアドレスが移行元と移行先とで異なると、仮想マシンにインストールされたソフトウェアのライセンスにＭＡＣアドレスが紐付けられている場合等において、ライセンス上の問題が発生する。例えばソフトウェアのライセンスを確認できなくなる問題が発生する。この場合、クラウドサービスの利用者には、(1) 新たにソフトウェアのライセンスを購入する・別途ライセンスを発行する、(2) アプリケーションのネットワーク構成を変更する、(3) ライセンス付きのソフトウェアを仮想マシンの移行対象から除外する、(4) 仮想マシンの移行そのものをやめる等の対応が求められる。

また、図２に示す例のように、２つのインフラ間で、仮想ネットワーク・インタフェースの接続数が異なる場合にも、特定組織インフラ１から「クラウド事業者１」のインフラ２に対しては、仮想マシンを移行することができない問題がある。

〔実施例１〕
（システム構成）
図３に、本明細書で提案する仮想プライベート・クラウドシステムの実施例を示す。図３も、特定組織インフラ１が、インターネット経由で、「クラウド事業者１」のインフラ２及び「クラウド事業者２」のインフラ３に接続される場合を表している。また、本実施例に係るシステムの場合にも、「特定組織インフラ１」と、「クラウド事業者１」のインフラ２と、「クラウド事業者２」のインフラ３にはＶＰＮ装置を配置し、インターネット上における通信のセキュリティを確保する仕組みを採用している。

本実施例に係るシステムの特徴部分は、仮想プライベートクラウド１０、２０、３０を構成する各仮想マシンに、仮想ＮＩＣ（Virtual Network Interface Card）と呼ぶ中間レイヤを配置する点である。ただし、仮想ＮＩＣは、仮想ネットワーク・インタフェースよりも上位のレイヤに配置する。本実施例では、この仮想ＮＩＣにおいて、Ｅｎｄ−Ｔｏ−Ｅｎｄでのデータの暗号化を実現する。この仕組みの採用により、クラウド事業者の内部ネットワーク上に平文データが流れなくなり、図１を用いて説明した課題の一つが解決される。

なお、本実施例の場合、仮想ＮＩＣを特定組織インフラ１とクラウド事業者のインフラストラクチャの両方に配置しているが、クラウド事業者側の内部ネットワーク上を平文データが流れることを回避する観点からは、クラウド事業者側にのみ仮想ＮＩＣを配置し、ＶＰＮ装置と仮想マシン間の通信データのみを暗号化しても良い。

続いて、仮想ＮＩＣと呼ぶ中間レイヤを用いれば、前述した２つ目と３つ目の課題も解決できることを説明する。

図４は、仮想ＮＩＣによるＭＡＣアドレスの仮想化を説明する図である。図４では、特定組織インフラ１で稼動する仮想マシン１１０の「仮想ネットワーク・インタフェース１１１」１１０４、「仮想ネットワーク・インタフェース１１２」１１０５と「ＴＣＰ／ＩＰプロトコルスタック」１１０２の中間に、「仮想ＮＩＣ１１」１１０１を配置した関係が表されている。

本実施例における仮想ＮＩＣ１１０１には、ＭＡＣアドレスを仮想化する機能が用意されている。この機能により、ＴＣＰ／ＩＰプロトコルスタック１１０２に対し、下位レイヤの仮想ネットワーク・インタフェースのＭＡＣアドレスを隠蔽することができる。すなわち、ＴＣＰ／ＩＰプロトコルスタックを利用する上位のアプリケーションからは、仮想マシンの移行後も、仮想ネットワーク・インタフェースのＭＡＣアドレスが移行前と同じであるように見える。図４の場合、仮想マシン移行前の「仮想ネットワーク・インタフェース１１１」のＭＡＣアドレスは「AA:AA:AA:A1」であり、仮想マシン移行後の「仮想ネットワーク・インタフェース１１１」のＭＡＣアドレスは「BB:BB:BB:B1」であるが、アプリケーションから見た「仮想ネットワーク・インタフェース１１１」のＭＡＣアドレスは常に「XX:XX:XX:X1」になる。このため、ソフトウェアのライセンスがＭＡＣアドレスに紐付けられている場合でも、ソフトウェアのライセンスとＭＡＣアドレスの関係が維持される。結果的に、特定組織インフラ１の仮想マシンをクラウド事業者のインフラ２に移行した後も、ライセンスの発行や新規の購入を行うことなく、ソフトウェアの使用を継続することができる。

また、このＭＡＣアドレスの隠蔽機能を用いれば、ネットワーク・インタフェース数を仮想化することもできる。すなわち、ＴＣＰ／ＩＰプロトコルスタックを利用する上位アプリケーションがどのネットワーク・インタフェースにデータを転送しようとする場合でも、仮想ＮＩＣ１１０１は、通信データをカプセル化（暗号化）し、単一のネットワーク・インタフェースを用いてデータを転送することができる。換言すると、本実施例に係るシステムは、２つのインフラ間において物理的に接続可能な仮想ネットワーク・インタフェースの数が異なる場合でも、論理的な接続を確保することができ、仮想マシンを支障なく移行することができる。

（ＮＩ管理テーブル）
続いて、前述した仮想ＮＩＣの機能（通信データの暗号化）を実現する仕組みを説明する。本実施例における仮想ＮＩＣは、内蔵するＮＩ（ネットワーク・インタフェース）管理テーブルの参照により、前述した機能を実現する。

図５に、ＮＩ管理テーブル１１０１０のデータ構造例を示す。ＮＩ管理テーブル１１０１０が管理する項目は、上位レイヤのＩＰアドレス、仮想ＮＩＣ自身のＭＡＣアドレス、仮想ネットワーク・インタフェースのＭＡＣアドレスの３つである。図５の場合、１レコード目には、ＩＰアドレス「192.168.1.10」に対し、仮想ＮＩＣのＭＡＣアドレス「XX:XX:XX:X1」と仮想ネットワーク・インタフェースのＭＡＣアドレス「AA:AA:AA:A1」とが対応付けられている。

（通信データの転送動作）
図６に、本実施例に係る仮想マシンで構成されたシステムにおいて、仮想マシンを特定組織インフラ１からクライアント事業者のインフラ２にデータを転送する場合のデータの流れを説明する。

例えば特定組織インフラ１内で稼働する仮想マシン１１０上のアプリケーションは、「ＴＣＰ／ＩＰ１１」１１０２のＩＰアドレス「192.168.1.10」を通じ、ＭＡＣアドレス「XX:XX:XX:X1」で特定されるインタフェースに対して通信データを送出する（図７のデータ４１）。ここで、通信データの宛先は、ＩＰアドレス「192.168.1.20」により特定される、クラウド事業者のインフラ２で稼働する「仮想化ソフトウェア２」２３上の「仮想マシン２１」２１０である。

仮想ＮＩＣ１１０１は、ＮＩ管理テーブル１１０１０を参照して通信データをカプセル化し、ネットワークへ送出する（図７のデータ４２）。なお、仮想ＮＩＣ１１０１は、通信データのカプセル化と共に、当該データの暗号化も行う。図７のデータ４２では、カプセル化ペイロードに暗号化されたデータ４１の全体が包含され、カプセル化ペイロードの送信元ＭＡＣアドレスとして、「仮想ネットワーク・インタフェース１１１」１１０４のＭＡＣアドレス「AA:AA:AA:A1」が書き込まれている。なお、暗号化は、データ４１のうちペイロード部分だけでもよい。

ここでの通信データの宛先であるＩＰアドレス「192.168.1.20」は、特定組織インフラ１の外部、すなわちインターネット側に存在する。このため、通信データは、特定組織インフラ１内のＶＰＮ装置１１を通じ、「クラウド事業者１」のインフラ２内にあるＶＰＮ装置２１に転送される（図７のデータ４３）。ここで、ＶＰＮ装置２１は、受信した通信データを仮想化ソフトウェア２３上に割り当てられた「ＶＭ２１」２１０に転送する。このとき、転送対象である本来のペイロードは、カプセル化ペイロード内に暗号化されて格納されている。このため、「クラウド事業者１」の内部ネットワーク上でのセキュリティが確保される。

また、インフラ２側に配置されたＶＰＮ装置２１は、カプセル化ペイロードの送信先ＭＡＣアドレスを、「仮想ネットワーク・インタフェース２１１」２１０４のＭＡＣアドレス「BB:BB:BB:B1」に変更する（図７のデータ４４）。

「仮想ネットワーク・インタフェース２１１」２１０で受信された通信データは、さらに上位のレイヤである「仮想ＮＩＣ２１」２１０１に転送される。

転送先の「仮想ＮＩＣ２１」２１０１は、転送元の「仮想ＮＩＣ１１」１１０１とは反対に、通信データのカプセル化解除（デカプセル化）とデータの復号化を行う。また、「仮想ＮＩＣ２１」２１０１は、ＮＩ管理テーブル２１０１０を参照して送信先インタフェースのＭＡＣアドレスを「YY:YY:YY:Y1」に変更する（図７のデータ４５）。

（通信データのカプセル化及びデータ転送処理）
図８に、仮想ＮＩＣによるソフトウェア処理手順を示す。まず、仮想ＮＩＣは、アプリケーションからの通信データが、ＴＣＰ／ＩＰプロトコルスタックを通じて転送されるのを待ち受ける（ステップ８００１）。

仮想ＮＩＣは、通信データをＴＣＰ／ＩＰプロトコルスタックから受信すると（ステップ８００２）、ＮＩ管理テーブル１１０１０をＩＰアドレスを用いて検索し、通信データの転送先である仮想ネットワーク・インタフェースのＭＡＣアドレスを取得する（ステップ８００３）。

その後、仮想ＮＩＣは、該当するレコードの仮想ネットワーク・インタフェースのＭＡＣアドレスを用いて通信データをカプセル化及び暗号化した後、下位の仮想ネットワーク・インタフェースに通信データを転送する（ステップ８００４）。

（ＮＩ管理テーブルの更新処理）
図９に、仮想ＮＩＣによるＮＩ管理テーブルの更新処理手順を示す。本実施例の場合、仮想ＮＩＣは、特定組織インフラ１とクラウド事業者のインフラ間で仮想マシンを移行し（ステップ９００１）、移行先のインフラで仮想マシンを起動（ステップ９００２）した時にＮＩ管理テーブルが更新される。仮想マシンを起動するたびにＮＩ管理テーブルを自動更新することにより、起動前のハードウェア構成の変更等によるＭＡＣアドレス等の変更にも自動的に対応することができる。

まず、仮想マシンの起動に連動し、仮想ＮＩＣがロードされる（ステップ９００３）。ロードされた仮想ＮＩＣは、仮想ネットワーク・インタフェースを検出する（ステップ９００４）。新たな仮想ネットワーク・インタフェースが検出されると（ステップ９００４で肯定結果）、仮想ＮＩＣは、仮想ネットワーク・インタフェースのＭＡＣアドレスを検出し（ステップ９００５）、ＮＩ管理テーブルの該当レコードの仮想ネットワーク・インタフェースのＭＡＣアドレスを、検出されたＭＡＣアドレスの値で置換する（ステップ９００６）。このステップ９００５及び９００６の処理は、ステップ９００４で新たな仮想ネットワーク・インタフェースが検出されている間、仮想ＮＩＣにおいて繰り返し実行される。

なお、新たな仮想ネットワーク・インタフェースが検出されない場合（ステップ９００４で否定結果）、仮想ＮＩＣは、仮想ネットワーク・インタフェースの更新処理を終了する。

（効果）
本実施例に係る仮想クラウドコンピュータを使用して仮想プライベート・クラウドシステムを構築すれば、例えば以下の技術的効果が達成される。

（１）仮想マシン（仮想サーバ）をネットワーク経由で外部システムに移行する場合にも、ＯＳ等のアドレスを変更することなく使用することが可能となる。

（２）物理アドレスの体系が異なるインフラ間においても、ネットワークアドレスの設定を変更することなく、インスタンスを移行することができる。このため、ネットワークアドレスの変更作業や動作検証が不要となり、従来に比して移行コストを低減することができる。また、ソフトウェアのライセンスがネットワークアドレスに紐付けられている場合にも、仮想マシンの移行後も、ソフトウェアをそのまま使用することができる。

（３）物理的に接続可能なネットワーク・インタフェースの数が異なるインフラ間でも仮想サーバを移行することができる。

（４）移行先のインフラ内では、暗号化された通信データが流れるため、クラウド事業者側における通信データの秘匿性を一段と高めることができる。

〔他の実施例〕
本明細書で提案する発明は、上述した実施例に限定されるものでなく、様々な変形が考えられる。例えば上述した実施例は、発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成・機能を備える必要は無い。また、実施例の構成に対して既知の構成を追加したり、実施例の一部の構成を削除又は置換することもできる。

また、上述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路その他のハードウェアとして実現してもよい。また、前述の実施例では、各サーバを構成するコンピュータによるプログラムの実行を通じ、各機能を実現する場合について説明したが、各機能をモジュール基板やＡＳＩＣ等のハードウェア資源を通じて実現しても良い。

１…特定組織インフラ、２…クラウド事業者１のインフラ、３…クラウド事業者２のインフラ、１０、２０、３０…仮想プライベートクラウド、１１、２１、３１…ＶＰＮ装置、１１０…ＶＭ１１、１２０…ＶＭ１２、２１０…ＶＭ２１、２２０…ＶＭ２２、３１０…ＶＭ３１、３２０…ＶＭ３２、１１０１…仮想ＮＩＣ１１、１２０１…仮想ＮＩＣ１２、２１０１…仮想ＮＩＣ２１、２２０１…仮想ＮＩＣ２２、３１０１…仮想ＮＩＣ２１、３２０１…仮想ＮＩＣ２２、１１０１０…ＮＩ管理テーブル。

Claims (6)

1. 仮想ネットワーク・インタフェースと、
   前記仮想ネットワーク・インタフェースよりも上位レイヤに位置し、上位レイヤからの通信データをそのアドレス情報も含めてカプセル化する一方で、前記仮想ネットワーク・インタフェースからの通信データをデカプセル化する中間レイヤと
   を有する仮想クラウドコンピュータ。
2. 請求項１に記載の仮想クラウドコンピュータにおいて、
   前記中間レイヤは、自身のＭＡＣアドレスと、前記仮想ネットワーク・インタフェースのＭＡＣアドレスと、上位レイヤのＩＰアドレスとを関連付けたネットワーク・インタフェース管理テーブルを参照して、カプセル化処理又はデカプセル化処理を実行する
   ことを特徴とする仮想クラウドコンピュータ。
3. 請求項２に記載の仮想クラウドコンピュータにおいて、
   前記中間レイヤは、移行時に、前記ネットワーク・インタフェース管理テーブルを自動的に更新する
   ことを特徴とする仮想クラウドコンピュータ。
4. 仮想ネットワーク・インタフェースと
   前記仮想ネットワーク・インタフェースよりも上位レイヤに位置し、上位レイヤからの通信データのうち少なくともペイロード部分を暗号化する一方で、前記仮想ネットワーク・インタフェースからの通信データを復号化する中間レイヤと
   を有する仮想クラウドコンピュータ。
5. 仮想ネットワーク・インタフェースよりも上位レイヤに位置する中間レイヤにおいて、上位レイヤからの通信データをそのアドレス情報も含めてカプセル化する一方で、前記仮想ネットワーク・インタフェースからの通信データをデカプセル化する処理をコンピュータに実行させるプログラム。
6. 仮想ネットワーク・インタフェースよりも上位レイヤに位置する中間レイヤにおいて、上位レイヤからの通信データのうち少なくともペイロード部分を暗号化する一方で、前記仮想ネットワーク・インタフェースからの通信データを復号化する処理をコンピュータに実行させるプログラム。

Images