JP5930942B2

JP5930942B2 - クラウドコンピューティングサブシステムの方法および装置

Info

Publication number: JP5930942B2
Application number: JP2012243226A
Authority: JP
Inventors: 俊雄大谷
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2012-07-18
Filing date: 2012-11-05
Publication date: 2016-06-08
Anticipated expiration: 2032-11-05
Also published as: US8990374B2; US20140025816A1; JP2014023142A

Description

０１本発明は、全般的に、サービスコンソールを介してコンピューティングリソースを提供するＩＴプラットフォームサブシステムに関し（ＩＴ：ｉｎｆｏｒｍａｔｉｏｎｔｅｃｈｎｏｌｏｇｙ）、特に、特定のネットワーク分離エリア（ｎｅｔｗｏｒｋｉｓｏｌａｔｅｄａｒｅａ）における、様々なサービスレベルを有するコンピューティングリソースプロビジョニングに関する。

０２関連技術では、様々なタイプのクラウドコンピューティングが、インフラストラクチャアズアサービス（ＩａａＳ：ＩｎｆｒａｓｔｒｕｃｔｕｒｅａｓａＳｅｒｖｉｃｅ）タイプのクラウドを使用可能とするサブシステムのために生み出されてきた。ＩａａＳは、コンピューティングリソースイメージをエンドユーザに提供し、その結果エンドユーザは、物理的な機器を購入してコンピューティングリソースを作成することなく、クラウドホスティングサービス経由でコンピューティングリソースを調達することができる。エンドユーザは、ＩａａＳのコンピューティングリソースを直ちに使用して、所望のオペレーティングシステムおよびアプリケーションソフトウェアをインストールすることができる。コンピューティングリソースは、物理リソース（例えば、物理マシン、ベアメタルサーバなど）および仮想リソース（例えば、仮想マシンなど）から構成可能である。

０３関連技術には、クラウドコンピューティングを可能にする様々なソリューションがある。こうした現在のソリューションは、仮想化されたコンピューティングリソースイメージを、サービスコンソール経由でエンドユーザに提供する。サービスコンソールは、ホストリソース、ネットワーク機器、ストレージアレイ、ハイパーバイザソフトウェア、カーネルベースの仮想リソース（ＫＶＭ）および管理ソフトウェアを含み得る。

２７関連技術のソリューションでは、いくつかの問題が生じ得る。１つの問題は、提供されるコンピューティングリソースのサービスレベルの多様性が限られることがあるということである。関連技術は、ホストリソース上で実行されているハイパーバイザソフトウェアを介して、仮想化されたコンピューティングリソースイメージを提供する。仮想リソースは、ウェブフロントエンドなどの特定のアプリケーションに使用されるが、データセンターでは、データベースなどのバックエンドコンピューティングリソースに関する他のサービスレベル要件がある。

２８もう１つの問題は、複数のデータセンターおよびサブシステムにわたるネットワーク分離テナント管理機能の提供である。複数のサブシステムにわたってネットワーク分離テナントを作成するためには、各サブシステムを接続するバックボーンネットワークが、仮想ローカルエリアネットワーク識別子（ＶＬＡＮＩＤ：ｖｉｒｔｕａｌｌｏｃａｌａｒｅａｎｅｔｗｏｒｋｉｄｅｎｔｉｆｉｅｒ）などのセッティングのため、再構成される必要がある。いくつかの関連技術ソリューションは、自動化された再構成方法を提供するが、そのような方法は、バックボーンネットワークのネットワーク運用ポリシーに合わないこともある。

０４実施形態として、コンピュータシステムは、ホストコンピュータと、複数のテナントを管理する管理コンピュータと、１以上のスイッチを含み、管理コンピュータは、複数のテナントの中で少なくとも１つはホストコンピュータ上の１以上の仮想リソースおよび１以上の物理リソースの中で少なくとも１つを含み、スイッチは、１以上の仮想リソースおよび１以上の物理リソースの中の少なくとも１つのアドレス情報を使用することによって、複数のテナントそれぞれのアクセスを、管理コンピュータからのフロー情報に基づき制御するものである。

０５また、実施形態として、管理コンピュータは、複数のテナントの中で少なくとも１つがホストコンピュータ上の１以上の仮想リソースおよび１以上の物理リソースの中で少なくとも１つを含む、複数のテナントを管理し、複数のテナントそれぞれのアクセスを制御するために１以上のスイッチによって使用され１以上の仮想リソースおよび１以上の物理リソースの中で少なくとも１つのアドレス情報に関連するフロー情報を、複数のテナントそれぞれに関して管理するように構成されている、中央処理ユニット（ＣＰＵ）を含むものである。

０６さらに、実施形態として、管理コンピュータ用の命令を格納するコンピュータ可読ストレージ媒体は、複数のテナントの中で少なくとも１つが、ホストコンピュータ上の１以上の仮想リソースおよび１以上の物理リソースの中で少なくとも１つを含むように、複数のテナントを管理するための命令、ならびに、複数のテナントそれぞれのアクセスを制御するために１以上のスイッチによって使用され、１以上の仮想リソースおよび１以上の物理リソースの中の該少なくとも１つのアドレス情報に関連するフロー情報を、複数のテナントそれぞれに関して管理するための命令、を含むものである。

本発明のクラウドコンピューティングサブシステムによれば、特定のネットワーク分離エリアにおける、様々なサービスレベルを有するコンピューティングリソースプロビジョニングを提供できる。

０７本発明の実施形態によるシステムの構成例を示す。０８本発明の実施形態によるホストの構成例を示す。０９本発明の実施形態によるスイッチの構成例を示す。１０本発明の実施形態によるストレージアレイの構成例を示す。１１本発明の実施形態による管理ノードの構成例を示す。１２本発明の実施形態によるコンピューティングリソースの構成例を示す。１３本発明の実施形態によるテナントの構成例を示す。１４本発明の実施形態によるクラウドコンピューティングサブシステムのフローチャートを示す。１５本発明の実施形態による、新たなテナントおよび／または新たなリソースを作成するフローチャートを示す。１６本発明の実施形態によるグラフィカルユーザインターフェイス（ＧＵＩ：ｇｒａｐｈｉｃａｌｕｓｅｒｉｎｔｅｒｆａｃｅ）を示す。１６本発明の実施形態によるグラフィカルユーザインターフェイス（ＧＵＩ）を示す。１６本発明の実施形態によるグラフィカルユーザインターフェイス（ＧＵＩ）を示す。１６本発明の実施形態によるグラフィカルユーザインターフェイス（ＧＵＩ）を示す。１６本発明の実施形態によるグラフィカルユーザインターフェイス（ＧＵＩ）を示す。１６本発明の実施形態によるグラフィカルユーザインターフェイス（ＧＵＩ）を示す。１６本発明の実施形態によるグラフィカルユーザインターフェイス（ＧＵＩ）を示す。１７本発明の実施形態によるホスト管理テーブルを示す。１８本発明の実施形態によるストレージ管理テーブルを示す。１９本発明の実施形態によるテナント管理テーブルを示す。２０本発明の実施形態によるアドレス管理テーブルの例を示す。２１本発明の実施形態によるアドレス解決のフローダイアグラムを示す。２２本発明の実施形態による、アドレス管理テーブルを作成するためのアドレス収集のフローチャートを示す。２３本発明の実施形態によるＯｐｅｎＦｌｏｗのフローテーブルの例を示す。２４本発明の実施形態によるＯｐｅｎＦｌｏｗのフローテーブルの例を示す。２４本発明の実施形態によるＯｐｅｎＦｌｏｗのフローテーブルの例を示す。２４本発明の実施形態によるＯｐｅｎＦｌｏｗのフローテーブルの例を示す。２５本発明の実施形態によるスイッチ管理テーブルの例を示す。２５本発明の実施形態によるスイッチ管理テーブルの例を示す。

２６以下、本発明の実施形態における詳細な説明では、添付の図面が参照される。添付の図面では、同一の機能要素は同じ数字で示されている。前述の添付の図面は、限定としてではなく本発明の例示として、例示の実施形態および実装を示す。これらの実装は、当業者が実施可能なように十分詳細に記載されており、当然のことながら、他の実装が利用されてもよく、様々な構成要素の構造上の変更および／または代用が、本発明の実施形態の範囲および意図から逸脱することなく行われ得る。したがって、以下の詳細な記載は、限定的な意味で解釈されてはならない。

２９本発明の一実施形態では、クラウドコンピューティングサブシステムは、１以上のホストリソース、ストレージアレイ、ネットワークスイッチおよび管理ノードを含む。クラウドコンピューティングサブシステムのネットワークスイッチは、クラウドコンピューティングサブシステムとは別に管理されるバックボーンネットワークに接続する。さらに、管理ノードは、各ホストのホストＩＤおよびホストステータス情報を有するホスト管理テーブルを使用することで、物理コンピューティングリソースまたはハイパーバイザソフトウェア上の仮想コンピューティングリソースのいずれかとしてホストリソースを展開する。管理ノードはさらに、ＶＬＡＮＩＤおよび／または媒体アクセスコントローラ（ＭＡＣ：ｍｅｄｉａａｃｃｅｓｓｃｏｎｔｒｏｌｌｅｒ）アドレスなどのネットワークアドレスによって特定可能な１以上のホストリソース、ストレージアレイ、および／または仮想リソースを提供するネットワーク分離ドメインを、テナントＩＤおよびテナントメンバー情報を有するテナント管理テーブルを使用して構成する。クラウドコンピューティングサブシステムは、サービスコンソールを介して、コンピューティングリソースイメージを提供することを可能にし、サービスコンソールは、テナントユーザがコンピューティングリソースイメージのサービスレベルを定義できるようにし、テナントユーザがネットワークドメインを定義できるようにもする。各コンピューティングリソースイメージは、中央処理ユニット（ＣＰＵ：ｃｅｎｔｒａｌｐｒｏｃｅｓｓｉｎｇｕｎｉｔ）、メモリ、Ｉ／Ｏデバイスおよび外部ストレージボリュームを含み得る。

３０もう１つの実施形態では、第１のクラウドコンピューティングサブシステムは、ホストリソース、ストレージアレイ、ネットワークスイッチおよび管理ノードを含む。第２のクラウドコンピューティングサブシステムは、ホストリソース、ストレージアレイ、ネットワークスイッチおよび管理ノードを含む。第１および第２のクラウドコンピューティングサブシステムのネットワークスイッチは、第１および第２のクラウドコンピューティングサブシステムとは別に管理されるバックボーンネットワークに接続する。管理ノードは、各ホストのホストＩＤおよびホストステータス情報を有するホスト管理テーブルを使用することで、物理コンピューティングリソースまたはハイパーバイザソフトウェア上の仮想コンピューティングリソースのいずれかとしてホストリソースを展開する。管理ノードはさらに、ＶＬＡＮＩＤおよび／またはＭＡＣアドレスなどのネットワークアドレスによって特定可能な１つ以上のホストリソース、ストレージアレイ、および／または仮想リソースを提供するネットワーク分離ドメインを、テナントＩＤおよびテナントメンバー情報を有するテナント管理テーブルを使用して構成する。ネットワーク分離ドメインは、第１および／または第２のクラウドコンピューティングサブシステムを介して作成されるとよく、バックボーンネットワーク構成なしで作成される。クラウドコンピューティングサブシステムは、サービスコンソールを介して、コンピューティングリソースイメージを提供することを可能にし、サービスコンソールは、テナントユーザがコンピューティングリソースイメージのサービスレベルを定義できるようにし、テナントユーザがネットワークドメインを定義できるようにもする。各コンピューティングリソースイメージは、中央処理ユニット（ＣＰＵ）、メモリ、Ｉ／Ｏデバイスおよび外部ストレージボリュームを含み得る。ＣＰＵによって実装または実行される機能は、ＲＡＭ、フラッシュメモリ、ハードディスクドライブなどの有形のデバイスを含むコンピュータ可読ストレージ媒体に記憶されてもよい。機能はさらに、搬送波などの一時的な媒体を含む、コンピュータ可読信号媒体に格納されてもよい。

３１図１は、本発明の実施形態によるシステムの構成例を示す。システムは、１以上のクラウドコンピューティングサブシステムを有する。図１の例では、２つのクラウドコンピューティングサブシステム１０および１１がある。各クラウドコンピューティングサブシステムは、１以上のホスト１００、ネットワークスイッチ２００、ストレージアレイ３００および管理ノード４００を含む。ネットワークスイッチ２００は、クラウドコンピューティングサブシステムを外部インターネット、データベースなどの他のシステムに接続するバックボーンネットワーク５００に接続する。図１の例に示されているように、バックボーンネットワーク５００はさらに、複数のクラウドコンピューティングサブシステム１０および１１を接続する。さらに、１以上のホスト１００は、仮想スイッチ２０１に接続されている。

３２図２は、本発明の実施形態によるホストの構成例を示す。ホストは、ペリフェラルコントローラインターフェイス（ＰＣＩ：ｐｅｒｉｐｈｅｒａｌｃｏｎｔｒｏｌｌｅｒｉｎｔｅｒｆａｃｅ）エクスプレス（登録商標）などの内部バスによって接続されている中央処理ユニット（ＣＰＵ）１００ａ、ランダムアクセスメモリ（ＲＡＭ）１００ｂおよび１以上のポート（すなわち、１０ギガビットイーサネット（登録商標））１００ｃを含む。ホスト１００はさらに、オペレーティングシステム１００ｂ−１、仮想リソースを実行するハイパーバイザ１００ｂ−２およびクラウドコンピューティング動作のためのホスト管理機能１００ｂ−３などのソフトウェアを含む。ホストは、ｘ８６コンピューティングノードとして展開されてもよい。

３３図３は、本発明の実施形態によるスイッチの構成例を示す。スイッチ２００は、ＰＣＩエクスプレスなどの内部バスによって接続されているＣＰＵ２００ａ、ＲＡＭ２００ｂ、１以上のポート２００ｅ（すなわち、１０ギガビットイーサネット）、ＯｐｅｎＦｌｏｗフレームフォワーダ２００ｃ、およびイーサネットフレームフォワーダ２００ｄを含む。スイッチはさらに、オペレーティングシステム２００ｂ−１、管理ノード４００上のＯｐｅｎＦｌｏｗコントローラからのフローテーブルを適用するＯｐｅｎＦｌｏｗエージェント２００ｂ−２、およびスイッチ管理機能２００ｂ−３などのソフトウェアを有する。

３４図４は、本発明の実施形態によるストレージアレイの構成例を示す。ストレージアレイ３００は、ＰＣＩエクスプレスなどの内部バスによって接続されている１以上の中央処理ユニット（ＣＰＵ）３００ａ、ランダムアクセスメモリ（ＲＡＭ）３００ｂ、１以上のポート３００ｃ（すなわち、１０ギガビットイーサネット）およびＲＡＩＤ（ＲｅｄｕｎｄａｎｔＡｒｒａｙｏｆＩｎｄｅｐｅｎｄｅｎｔＤｉｓｋｓ）コントローラ３００ｄを含む。ＲＡＩＤコントローラ３００ｄは、ＨＤＤ（ｈａｒｄｄｉｓｋｄｒｉｖｅ）および／またはＳＳＤ（ｓｏｌｉｄｓｔａｔｅｄｒｉｖｅ）などの１以上のディスクを統合し、論理ユニット（ＬＵ：ｌｏｇｉｃａｌｕｎｉｔ）として構成された１以上のストレージボリュームをホスト１００に提供する。ストレージアレイ３００はさらに、オペレーティングシステム３００ｂ−１、小型コンピュータシステムインターフェイス（ＳＣＳＩ：ｓｍａｌｌｃｏｍｐｕｔｅｒｓｙｓｔｅｍｓｉｎｔｅｒｆａｃｅ）、インターネットＳＣＳＩ（ｉＳＣＳＩ：ｉｎｔｅｒｎｅｔＳＣＳＩ）、ネットワークファイルシステム（ＮＦＳ：ｎｅｔｗｏｒｋｆｉｌｅｓｙｓｔｅｍ）、共通インターネットファイルシステム（ＣＩＦＳ：ｃｏｍｍｏｎｉｎｔｅｒｎｅｔｆｉｌｅｓｙｓｔｅｍ）、ファイバチャネル、ファイバチャネルオーバーイーサネット（ＦＣｏＥ：ＦｉｂｒｅＣｈａｎｎｅｌｏｖｅｒＥｔｈｅｒｎｅｔ）などのストレージＩ／Ｏプロトコルを処理するＩ／Ｏ制御３００ｂ−２などのソフトウェアを有する。ストレージアレイ３００はさらに、公開する論理ユニットをフィルタリングするための論理ユニット番号（ＬＵＮ：ｌｏｇｉｃａｌｕｎｉｔｎｕｍｂｅｒ）マスキング機能３００ｂ−３およびストレージ管理機能３００ｂ−４を有する。

３５図５は、本発明の実施形態による管理ノードの構成例を示す。管理ノード４００は、ＰＣＩエクスプレスなどの内部バスによって接続されているＣＰＵ４００ａ、ＲＡＭ４００ｂ、および１以上のポート４００ｃ（すなわち、１０ギガビットイーサネット）を含む。各コンポーネント（ホスト１００、スイッチ２００、ストレージアレイ３００）は、管理ポート４００ｃから到達可能である。管理ノード４００はさらに、オペレーティングシステム４００ｂ−１などのソフトウェア、ならびにクラウドコンピューティング環境を動作させるためのいくつかのソフトウェア機能セットおよび管理情報を有する。

３６リソースプロビジョニング機能４００ｂ−２は、テナントユーザが、テナントを作成して、テナント管理テーブルのテナント情報を管理することができるようにする。リソースプロビジョニング機能は、テナントユーザに対して、ホストを物理リソースまたは仮想リソースとして展開する機能を含む。

３７トポロジ収集機能４００ｂ−３は、ホスト管理テーブル、スイッチ管理テーブルおよびストレージ管理テーブルを構成するために、ホスト１００、スイッチ２００、ストレージアレイ３００、ホスト１００上のハイパーバイザソフトウェアの構成を取得する。

３８アドレス解決機能４００ｂ−４は、ＭＡＣアドレスとインターネットプロトコル（ＩＰ：ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ）アドレスとの間のアドレス解決を行う。アドレス解決情報は、アドレス管理テーブルにおいて管理される。

３９デバイス構成機能４００ｂ−５は、ホスト１００、ネットワークスイッチ２００、ストレージアレイ３００、およびホスト１００上のハイパーバイザソフトウェアを構成する。

４０プリブート実行環境（ＰＸＥ：ｐｒｅｂｏｏｔｅｘｅｃｕｔｉｏｎｅｎｖｉｒｏｎｍｅｎｔ）／トリビアル・ファイル転送プロトコル（ＴＦＴＰ：ｔｒｉｖｉａｌｆｉｌｅｔｒａｎｓｆｅｒｐｒｏｔｏｃｏｌ）、動的ホスト構成プロトコル（ＤＨＣＰ：ｄｙｎａｍｉｃｈｏｓｔｃｏｎｆｉｇｕｒａｔｉｏｎｐｒｏｔｏｃｏｌ）ブート機能４００ｂ−６は、ネットワークを介して物理リソース（ベアメタルまたはハイパーバイザ対応リソース）としてホスト１００が起動することを可能にする。アドレス管理テーブルはさらに、各リソースの適用されたリソースイメージを管理する。

４１図６は、本発明の実施形態によるコンピューティングリソース構成を示す。クラウドコンピューティングサブシステムは、テナントユーザに対して物理および仮想コンピューティングリソースを提供する。６０１−１、６０１−２、６０１−１１、６０１−３、６０１−１２、６０１−４および６０１−１３に示されているように、仮想リソースは、物理ホスト１００において実行されているハイパーバイザソフトウェア上に展開される。６００−４にて示されているように、物理リソースは、ベアメタルサーバとして物理ホスト１００上に展開される。これらの物理および仮想コンピューティングリソースは、テナントユーザによって使用可能なクラウドコンピューティングリソースである。テナントユーザは、これらのコンピューティングリソース上に、ゲストオペレーティングシステム、アプリケーションプログラムなどをインストールすることができる。

４２クラウドコンピューティングサブシステムはさらに、ネットワーク機能を提供する。ネットワーク機能は、６０２−０１および６０２−０２に示されている物理ネットワークスイッチと、６０３−０１、６０３−０２および６０３−０３に示されているハイパーバイザソフトウェア上の仮想ネットワークスイッチとを含むことができる。物理スイッチは、６０４−０１および６０４−０２に示されている管理ノードによって管理される。物理ネットワークスイッチおよび仮想ネットワークスイッチは、物理および仮想リソースを接続し、ネットワークフィルタリング機能を利用して、テナントと呼ばれる分離ネットワークドメインを作成する。テナントは、同じクラウドコンピューティングサブシステム内に定義すること、およびバックボーンネットワーク６０５を介して種々のクラウドコンピューティングサブシステム内に定義することが可能である。

４３クラウドコンピューティングサブシステムはさらに、ストレージ機能を提供することができる。例えば、１以上の論理ユニット（ストレージボリューム）を備えるストレージアレイ６０６が提供されることが可能であり、これはその結果、物理および仮想スイッチ経由で物理および仮想リソース（例えば、物理マシン、仮想マシンなど）に割り当てられることが可能である。

４４図７は、本発明の実施形態によるテナントの構成例を示す。各テナント７００−１、７００−２は、ＶＬＡＮＩＤ、ＭＰ＊／ＭＶ＊のネットワークアドレス（ＭＡＣアドレスのような）、ストレージアレイ上の論理ボリュームなど、ネットワーク識別子ベースのフィルタリング技術によって実行される、実質的に分離されたネットワークドメインである。ネットワーク識別子ベースのフィルタリングは、ＶＬＡＮ分離、ＭＡＣアドレスベースのフィルタリング、ＯｐｅｎＦｌｏｗフローテーブル、または当業者に既知の他のフィルタリングとすることができる。図７の例では、テナント内に仮想ネットワークがある（例えば、テナントＡ７００−１内の仮想ネットワーク０１）。クラウドコンピューティングサブシステムは、ユーザが、異なるＶＬＡＮ間の通信を制限するＯｐｅｎＦｌｏｗフロー制御を使用することで、テナント内に仮想ネットワークを作成することを可能にする。ＶＬＡＮＩＤを有するイーサネットフレームは、テナント内の特定の仮想ネットワーク（例えば、テナントＡ７００−１内に仮想ネットワーク０１および０２として示されている）に属するものと見なすことが可能である。それについて、図１７で詳細に説明する。

４５図８は、本発明の実施形態によるクラウドコンピューティングサブシステムのフローチャートを示す。クラウドコンピューティングサブシステムは、構成済のハードウェア（例えば、２４個の物理ホスト、２つの物理スイッチ、１つのストレージアレイおよび２つの管理ノード）でデータセンターに送られる。各コンポーネントは、物理スイッチに配線済みである。管理ノードのソフトウェア構成も、前述のように構成済みである。このプロセスでは、管理ノード４００は、以下のようにいくつかの管理テーブルを作成する。

４６８００にて、トポロジ収集機能４００ｂ−３が、プロトコル（例えば、インテリジェントプラットフォーム管理インターフェイス（ＩＰＭＩ：ＩｎｔｅｌｌｉｇｅｎｔＰｌａｔｆｏｒｍＭａｎａｇｅｍｅｎｔＩｎｔｅｒｆａｃｅ）、ベースボード管理コントローラ（ＢＭＣ：ＢａｓｅｂｏａｒｄＭａｎａｇｅｍｅｎｔＣｏｎｔｒｏｌｌｅｒ）、カスタマイズされたプロプライエタリプロトコルなど）を介して各ホストからホスト情報（例えば、ＣＰＵ、メモリ、Ｉ／Ｏの数、ディスクの数など）を取得することによって、ホスト管理テーブルを作成する。

４７８０１にて、トポロジ収集機能４００ｂ−３は、スイッチ２００とホスト１００／ストレージアレイ３００との間のトポロジマッピング／接続情報を取得することによって、スイッチ管理テーブルを作成する。トポロジマッピング／接続情報は、インストール前に手動でセットアップされること、または自動的に集められることが可能である（例えば、リンクレイヤディスカバリプロトコル（ＬＬＤＰ：ＬｉｎｋＬａｙｅｒＤｉｓｃｏｖｅｒｙＰｒｏｔｏｃｏｌ）、ポートリンクアップ／リンクダウン検出などによって）。本発明の実装例では、スイッチ管理テーブルは、物理スイッチからの情報のみを取り入れるが、他の本発明の実装例は、必要であれば仮想スイッチ情報を含むことができる。

４８８０２にて、トポロジ収集機能４００ｂ−３は、プロトコル（例えば、ストレージ管理イニシアチブ仕様（ＳＭＩ−Ｓ：ｓｔｏｒａｇｅｍａｎａｇｅｍｅｎｔｉｎｉｔｉａｔｉｖｅｓｐｅｃｉｆｉｃａｔｉｏｎ）、カスタマイズされたプロプライエタリプロトコルなど）を使用することで、各ストレージアレイ３００からストレージ情報（例えば、ストレージプール構成、論理ユニットに到達するためのポートなど）を集めることにより、ストレージ管理テーブルを作成する。

４９８０３にて、トポロジ収集機能４００ｂ−３は、各ホスト１００のＭＡＣアドレス情報、各ＭＡＣアドレスのＩＰアドレス、および各ホスト１００のリソースイメージ情報（例えば、ハイパーバイザバージョン、ベアメタルリソースインストールのＯＳのバージョンおよびタイプなど）を記憶することによって、アドレス管理テーブルを作成する。リソースイメージは、ハイパーバイザの特定のバージョン、ベアメタルリソースインストール用ＯＳにおける特定のバージョンおよび種類などである。初期のプロセスでは、アドレス管理テーブルは、ホスト管理テーブルによってもたらされるＭＡＣアドレス記録のみを有する。本発明の実装例では、アドレス管理テーブルは、物理ホストのみからの情報を取り入れるが、他の本発明の実装例は、必要であれば仮想ホストを含むことができる。

５０図９は、本発明の実施形態による、新たなテナントおよび／または新たなリソースを作成するフローチャートを示す。図１０（ａ）〜１０（ｇ）は、本発明の実施形態によるグラフィカルユーザインターフェイス（ＧＵＩ）を示す。図９の構成要素について、図４、図１０（ａ）〜１０（ｇ）、および図１１〜図１５を参照して説明する。

５１９００にて、テナントユーザは、図１０（ａ）に示されているＧＵＩを介してテナント名を入力することができる。リソースプロビジョニング機能４００ｂ−２は、テナント名およびテナントメンバーを管理するためのテナント管理テーブルを作成する。本発明の実施形態によるテナント管理テーブルは、図１３に示される。これは、テナントＩＤ、テナントに関連するＶＬＡＮＩＤ、および各テナントに関連する物理／仮想リソースのエントリを含むことができる。リソースプロビジョニング機能４００ｂ−２は、テナント管理テーブルを作成するときに、新たに作成されたテナントのＶＬＡＮＩＤも追加する。

５２リソースプロビジョニング機能４００ｂ−２は、新たなテナントを作成するのに加えて、新たなリソースを作成することもできる。例えば、９０１にて、テナントユーザは、図１０（ｂ）に示されているグラフィカルユーザインターフェイス（ＧＵＩ）を使用して、プロビジョニングの必要情報を入力することができる。リソースプロビジョニング機能４００ｂ−２は、ＧＵＩを介して必要な情報を収集し、続いてホスト１００、スイッチ２００、ハイパーバイザ１００ｂ−２およびストレージアレイ３００などのリソースを構成する。

５３図１０（ｂ）に示されているように、テナントユーザは、物理または仮想コンピューティングリソースの展開を選ぶ。リソースプロビジョニング機能４００ｂ−２は、展開の選択に応じて進行する。

５４物理リソースの展開

５５物理リソースが展開される場合、リソースプロビジョニング機能４００ｂ−２は、９０２−１に進む。９０２−１にて、リソースプロビジョニング機能４００ｂ−２は、ホスト管理テーブルによって示される、使用されていないホストを特定する。９０２−２にて、図１０（ｃ）に示されている、識別子としてのリソース名、使用するプロセッサの数、メモリサイズ、および配置するテナントを入力するためのＧＵＩが提供される。プロセッサの数およびメモリサイズに関する情報は、図１１に示されているホスト管理テーブルから取得される。ホスト管理テーブルからの情報に基づき、リソースプロビジョニング機能４００ｂ−２は、使用されていないホストを特定する。

５６図１１に示されているように、ホスト管理テーブルは、クラウドコンピューティングサブシステム上のすべての物理ホスト１００の情報を管理し、さらに、ホストＩＤ、ＣＰＵの数、メモリサイズ、Ｉ／Ｏデバイス（例えば、ネットワークインターフェイスコントローラ（ＮＩＣ：ｎｅｔｗｏｒｋｉｎｔｅｒｆａｃｅｃｏｎｔｒｏｌｌｅｒ））のＭＡＣアドレス、利用されるディスク、およびステータス（例えば、予約されている、展開されている、使用されていないなど）などの情報を含む。ステータス情報は、各ホストがどのように展開されているかを表す（例えば、ベアメタルサーバ、ハイパーバイザ対応ホストなど）。図１０（ｃ）に示されているＧＵＩでは、テナントユーザが、例えば、「使用されていない」ステータスのホストを物理リソース展開のために選択することができる。テナントユーザがこれらのパラメータを選択すると、管理テーブル上の行に対応するホストが予約されることを可能にする。

５７図１０（ｃ）のＧＵＩを介して構成が行われた後、テナントユーザは、図１０（ｄ）のＧＵＩで、テナントにおける仮想ネットワーク構成の入力を要求される。リソース上の各ＮＩＣは、仮想ネットワークに接続されることが可能である（例えば、データ管理区域（ＤＭＺ：ｄａｔａｍａｎａｇｅｍｅｎｔｚｏｎｅ）、プライベートなど）。

５８仮想ネットワーク構成の後、テナントユーザは、図１０（ｅ）のＧＵＩで、ストレージ構成の入力を要求される。テナントユーザは、内部ディスク（存在すれば）および／または外部ボリューム（例えば、ｉＳＣＳＩ、ネットワークアタッチトストレージ（ＮＡＳ：ＮｅｔｗｏｒｋＡｔｔａｃｈｅｄＳｔｏｒａｇｅ）、ファイバチャネル（ＦＣ：ＦｉｂｒｅＣｈａｎｎｅｌ）、ＦＣオーバーイーサネット（ＦＣｏＥ）など）からストレージリソースをアタッチすることができる。本発明のインターフェイスでは、テナントユーザが物理リソースを展開しようとする場合、「仮想ボリューム」のチェックボックスは省略されてもよい。

５９図１０（ｅ）の例では、ＭｙＰｏｏｌ１が、図１２に示されているストレージ管理テーブルによって管理される、ストレージアレイ内の論理ボリュームを得るためのストレージリソースプールとして使用されることを可能にする。ストレージ管理テーブルは、ストレージＩＤ、プール、ＬＵＮおよびステータスの情報を有するエントリを含む。例えば、ＭｙＰｏｏｌ１は、１以上のＲＡＩＤグループを含むシンプロビジョニングされたストレージリソースプールとすることができる。ＭｙＰｏｏｌ１は、複数のストレージサービスレベル（ティア；層）を提供するように複数のストレージプールを有することもできる。テナントユーザがＭｙＰｏｏｌ１のパラメータを選ぶと、ストレージ管理テーブル上の行（単数または複数）に対応するストレージＩＤおよび論理ユニット番号を予約することが可能である。

６０ストレージ管理テーブル情報を取得／作成した後、リソースプロビジョニング機能４００ｂ−２は、テナントユーザに対してホスト１００を利用可能にする。リソースプロビジョニング機能４００ｂ−２は、９０２−３に進み、ＭＡＣアドレスを取得することにより、ホストとテナントを接続するように関連するスイッチ２００を構成する。関連するスイッチを構成するために、リソースプロビジョニング機能４００ｂ−２は、ホストからの、ＶＬＡＮＩＤを有する受信イーサネットフレームを許可するように、ホストが接続するスイッチ２００上の物理ポートにＶＬＡＮＩＤを追加する。

６１フローは、９０２−４に進み、ストレージおよびホスト管理テーブルを更新する。テーブルの更新は、ホストの関連するリソースを、「使用されている」に特定する。続いて、テナントユーザに対してホストの管理ＩＰアドレスが示される。

６２任意選択で、テナントユーザが、物理ホストのネットブート実行を可能にするＰＸＥを介してＯＳをインストールすることができるように、インターフェイスを提供することが可能である。例えば、ＰＸＥブートのためのソフトウェアイメージパスを追加することで、ホストが、規定のソフトウェアイメージを使用して起動できるようになる。この例では、リソースプロビジョニング機能４００ｂ−２は、ホストのＭＡＣアドレスの行にソフトウェアイメージパスを追加し、これが、ＰＸＥブートの実行前にＰＸＥ／ＤＨＣＰサーバに送信される。クラウドコンピューティングサブシステムのシステム管理者は、ＰＸＥインターフェイスを使用して、ハイパーバイザソフトウェアを物理ホスト上に展開し、必要に応じてテナントユーザの仮想リソース環境を作成することができる。

６３テナントユーザが物理リソースの展開を削除すると、ホストのステータスは、次の利用のために「使用されていない」に変わる。

６４仮想リソースの展開

６５テナントユーザが仮想リソースを展開することを選択すると、リソースプロビジョニング機能は、９０３−１に進み、展開されたホストをホスト管理テーブルから検索する（例えば、図１１の例の「ＥＳＸｉ」）。すでに展開済みでハイパーバイザを実行しているホストがあれば、リソースプロビジョニング機能は、９０３−２に進み、テナントユーザは、識別子としてのリソース名、使用するプロセッサの数、メモリサイズ、および仮想リソースを配置するテナントを入力するための、図１０（ｃ）のＧＵＩを見ることになる。テナントユーザは、プロセッサの数およびメモリサイズを、クラウドコンピューティングサブシステム上でハイパーバイザを実行しているホストが当該リソースを提供できる限り、必要に応じて入力することができる。

６６図１０（ｃ）のＧＵＩを介して構成が行われた後、テナントユーザは、図１０（ｄ）のＧＵＩで、テナントにおける仮想ネットワーク構成の入力を要求される。リソース上の各ＮＩＣは、仮想ネットワークに接続されることが可能である（例えば、ＤＭＺ、プライベートなど）。

６７仮想ネットワーク構成の後、テナントユーザは、図１０（ｅ）のＧＵＩで、ストレージ構成の入力を要求される。テナントユーザは、仮想ディスク、および／またはｒａｗデバイスマッピングとして外部ボリューム（例えば、ｉＳＣＳＩ、ＮＡＳ、ＦＣ、ＦＣｏＥ）のストレージリソースをアタッチできる。

６８仮想ネットワークの構成後、リソースプロビジョニング機能４００ｂ−２は、９０３−３に進み、ハイパーバイザソフトウェアを呼び出して、ハイパーバイザを実行しているホスト上に仮想リソースを展開し、続いて９０３−４に進み、仮想リソースをテナントに提供するように関連する仮想スイッチを構成する。関連する仮想スイッチを構成するために、リソースプロビジョニング機能４００ｂ−２は、仮想リソースからの、ＶＬＡＮＩＤを有するるイーサネットフレームを許可するよう、仮想リソースが接続する仮想スイッチ上の仮想ポートにＶＬＡＮＩＤを追加する。リソースプロビジョニング機能４００ｂ−２はさらに、ハイパーバイザにアクセスすることによって、仮想リソースと仮想スイッチとの間の接続マッピングテーブルを取得することができ、当該マッピング情報をスイッチ管理テーブルに追加することができる。スイッチ管理テーブルが更新されると、続いて、テナントユーザの仮想ホストの管理ＩＰアドレスが示される。

６９任意選択で、テナントユーザが、物理ホストのネットブート実行を可能にするＰＸＥを介して仮想リソース上にＯＳをインストールすることができるように、インターフェイスを提供することが可能である。例えば、ＰＸＥブートのためのソフトウェアイメージパスを追加することで、ホストが、規定のソフトウェアイメージを使用して起動できるようになる。この例では、リソースプロビジョニング機能４００ｂ−２は、ホストのＭＡＣアドレスの行にソフトウェアイメージパスを追加し、これが、ＰＸＥブートの実行前にＰＸＥ／ＤＨＣＰサーバに送信される。

７０テナントユーザが仮想リソースの展開を削除すると、ホストのステータスは、次の利用のために「使用されていない」に変わる。

７１図１０（ｆ）および１０（ｇ）は、仮想リソースを選択するためのさらなるインターフェイスを示す。図１０（ｆ）からの仮想ボリュームの選択から、図１０（ｇ）に示されているように、仮想リソースを置く論理ボリュームを指定するためのデータストアが提供される。ユーザが物理リソースを選択するか仮想リソースを選択するかにかかわらず、所望のストレージプールをユーザが選択できるようなインターフェイスが提供されてもよい。例えば、ユーザが物理リソースの作成を選ぶと、システムは、ユーザが選択するストレージプールから新たな論理ボリュームを作成する。ユーザが仮想リソースを選択すると、システムは、ユーザが選択するストレージプールに由来する特定の論理ボリューム（データストア）上に、例えば、仮想ボリューム（ＶＭＤＫ）を作成する。図１０（ｇ）の例では、ユーザが仮想リソースを選択すると、仮想リソースを作成するデータストアをユーザが選択できるインターフェイスが提供される。

７２テナントの作成のためのＯｐｅｎＦｌｏｗ使用

７３上記の例では、クラウドコンピューティングサブシステムは、ＶＬＡＮを使用して、ネットワーク分離テナントを作成する。ＶＬＡＮＩＤの使用については、いくつかの考慮すべき点がある。例えば、ＶＬＡＮＩＤは、限られたリソース（例えば、最大４０９６バイトのサイズ）であると考えられ、クラウドコンピューティングサブシステムは、ＶＬＡＮＩＤの制限を超えてテナントを作成できないかもしれない。複数のクラウドコンピューティングサブシステム中「すべてでＶＬＡＮＩＤを許可」と、バックボーンネットワークを構成済みとすることが可能であるが、この構成は、バックボーンネットワークのネットワークセキュリティポリシーが理由で機能しないかもしれない。

７４ＯｐｅｎＦｌｏｗは、物理および仮想スイッチが、フローベースのネットワークフレーム配信を実行できるようにする。フローは、ソースアドレス、宛先アドレス、プロトコルなどを使用することで定義される。以下は、ＶＬＡＮＩＤの使用に関する検討事項を考慮した上での、複数のクラウドコンピューティングサブシステムによりネットワーク分離テナントを提供する例である。

７５アドレス解決

７６テナントを管理するために、クラウドコンピューティングサブシステムは、別々のテナント上に配置されたコンピューティングリソース間のアクセスを防ぐことができるネットワークを必要とする。ネットワークは、異なるテナントからのイーサネット／ＩＰフレームの送受信を制限し、さらに、同じテナント内のコンピューティングリソース間の転送イーサネット／ＩＰフレームを許可する。

７７イーサネット／ＩＰ通信は、ＭＡＣアドレスの解決を必要とする。ノードがＩＰパケットを送信しようとする場合、ネットワークは、ＩＰアドレスのＭＡＣアドレスを利用する。このアドレス解決メカニズムは、ＡＲＰ（ＡｄｄｒｅｓｓＲｅｓｏｌｕｔｉｏｎＰｒｏｔｏｃｏｌ：アドレス解決プロトコル）として知られている。通信はさらに、ユニキャストパケットを他のノードに送信することを必要とする。ユニキャストパケットは、イーサネットヘッダと、ＩＰヘッダおよびＩＰペイロードを含むイーサネットペイロードとを含む情報を有する。

７８図１４は、本発明の実施形態によるアドレス管理テーブルの例を示す。アドレス管理テーブルは、各ホストのＭＡＣアドレス、各ＭＡＣアドレスに対して割り当てられるＩＰアドレス、および任意選択で、ＰＸＥブートに適用されるリソースイメージ情報、などの情報を含む。ＶＬＡＮＩＤがなければ、ブロードキャストフレームは、クラウドコンピューティングシステム（単数または複数）内のリソースすべてに配信されることになり、種々のテナントに伝達されることもある。ブロードキャストフレームを適切なテナントへ送信するために、クラウドコンピューティングサブシステムは、管理ノード４００のＯｐｅｎＦｌｏｗコントローラへブロードキャストフレームを転送し、その後ＯｐｅｎＦｌｏｗコントローラは、テナント管理テーブルを確認して、種々のテナントへのブロードキャストフレームの伝播を制限する。

７９テナント内のリソースが、テナント内でＩＰアドレスを用いて他のリソースと通信しようとする場合、リソースは、ＡＲＰを使用することでＩＰアドレスのＭＡＣアドレスを取得する。通常、ＡＲＰは、クエリメッセージ（例えば、「このＩＰアドレスＡは誰のものですか」）を伴うブロードキャストを同じブロードキャストドメインに送信することにより行われ、そのＩＰアドレスを有するノードが、メッセージ（例えば、「そのアドレスは私（ＭＡＣアドレスＡ）のものです」）を用いてノードに応答する。

８０図１５は、本発明の実施形態によるアドレス解決のフローダイアグラムを示す。上記のように、このクラウドコンピューティングサブシステムは、ブロードキャストＡＲＰを使用する以外の方法を使用して、複数のクラウドコンピューティングシステムにわたるマルチテナントネットワークを提供する。１５００にて、アドレス解決機能４００ｂ−４は、ＡＲＰブロードキャストを取得する。仮想／物理スイッチがＡＲＰのブロードキャストフレーム（例えば、ＥＴＨ＿Ｐ＿ＡＲＰ（０ｘ０８０６）を示すイーサネットヘッダのイーサタイプにより特定される）をリソースから受信すると、スイッチは、このブロードキャストフレームを、管理ノード内のＯｐｅｎＦｌｏｗコントローラに転送する。

８１１５０１にて、アドレス解決機能は、ブロードキャスト内のＭＡＣアドレスに対するＩＰアドレスを判断しようと試みる。ＯｐｅｎＦｌｏｗコントローラは、ソースＭＡＣアドレスを確認してテナントを判断し、ＡＲＰフレームを確認して返答するＩＰアドレスを特定し、ＩＰアドレスが発見されれば、１５０２に進んで、ＡＲＰ応答フレームを返答とともにリソースへ送信する。例えば、リソースＭＸ０１が、例として「ＩＰアドレス１０．１．１．２は誰ですか」と質問すると、ＯｐｅｎＦｌｏｗコントローラは、テナント管理テーブルおよびアドレス管理テーブルの両方を確認することにより、「ＭＸ０２が１０．１．１．２を有します」と返答することができる。ＯｐｅｎＦｌｏｗコントローラは、複数のクラウドコンピューティングサブシステムにわたるブロードキャストフレームの伝播をなくす。ＩＰアドレスが発見されなければ、アドレス解決機能は、ＩＰアドレスが発見されなかったことを示すメッセージを転送することができる。

８２図１６は、本発明の実施形態による、アドレス管理テーブルを作成するためのアドレス収集のフローチャートを示す。アドレス管理テーブルの各レコードは、ＯｐｅｎＦｌｏｗＡＲＰ手順より前に作成される。１６００にて、ＮＩＣ上でＩＰアドレスが設定されると、物理リソースおよび仮想リソースの各管理エージェントが、そのＭＡＣアドレスおよびＩＰアドレス情報を送信する。アドレス解決機能４００ｂ−４は、情報を取得して、アドレス管理テーブルの追加または更新を行う。

８３ＯｐｅｎＦｌｏｗのフロー制御

８４様々な本発明の実施形態において、管理コンピュータが、フロー情報の管理により複数のテナントを管理するように構成されることを可能にする。フロー情報は、ＯｐｅｎＦｌｏｗテーブルなどのフローテーブルを含むことができる。管理コンピュータは、１以上の中央処理ユニット（ＣＰＵ）を利用して複数のテナントを管理することができ、テナントのうちの１つ以上は、１以上の仮想リソース、１つ以上の物理リソース、またはその何らかの組み合わせのいずれかを利用する。管理コンピュータは、フローテーブルを管理することによって、仮想および物理スイッチのアクションを、間接的に（例えば、スイッチによって管理されているテナントそれぞれから来るフレームまたはそれぞれへのフレームに関して、仮想および物理スイッチが、フロー情報を参照して一連のアクションを判断する）、または直接、フローテーブル情報を転送してそれに応じて動作するようにスイッチに命令することによって制御できる。その結果、管理コンピュータは、テナントそれぞれのフレームのフローを制御するために切り替わるスイッチによる使用のために、複数のテナントそれぞれを定義するためのフロー情報を利用することができる。

８５ＯｐｅｎＦｌｏｗフローテーブルにおいて利用されるフロー情報は、仮想または物理リソースそれぞれのアドレス情報（例えば、ＭＡＣアドレス、ＩＰアドレスなど）、ならびにアクション情報（例えば、フレームを転送するポート、フレームのヘッダに対して行うアクションなどを示す）を含むことができる。そのようなフロー情報はさらに、各テナントの各仮想／物理リソースのアドレス情報と、各テナントへのアクセスを制御する物理スイッチまたはテナント内および／またはテナント間のフローを制御する仮想スイッチとの関連付けを提供することができる。さらに、管理コンピュータは、ＡＲＰブロードキャストにおいて解決されるべきアドレスを特定すること、および解決されるべきアドレスの解決をＡＲＰブロードキャストに関連するソースアドレスに対応する１以上のスイッチに転送することによって、アドレス解決プロトコル（ＡＲＰ）ブロードキャストを処理するようさらに構成されてもよい。さらなる詳細な内容を、下記に記載する図１７および図１８（ａ）〜１８（ｃ）の中で説明する。

８６図１７は、本発明の実施形態によるＯｐｅｎＦｌｏｗのフローテーブルの例を示す。ＯｐｅｎＦｌｏｗフレームは、スイッチポート、ＭＡＣソース、ＭＡＣ宛先、イーサネットタイプ、ＶＬＡＮＩＤ、ＩＰソース、ＩＰ宛先、ＩＰプロトコル、伝送制御プロトコル（ＴＣＰ：ｔｒａｎｓｍｉｓｓｉｏｎｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ）ソースポート、ＴＣＰ宛先ポート、および使用されるアクションについての情報を含む。ＯｐｅｎＦｌｏｗ対応スイッチ（仮想／物理）は、フローテーブルに定義されているとおりにフレームを転送する。フローテーブルは、管理ノード４００上のＯｐｅｎＦｌｏｗコントローラによって適用される。リソースが展開されてテナントに追加されると、フローテーブルは、ＯｐｅｎＦｌｏｗコントローラによって更新され、各スイッチに適用される（図９に記載のように）。図７に関連する図１７の例では、ＡＲＰブロードキャストフレームはＯｐｅｎＦｌｏｗコントローラに移送され、テナントＡ７００−１内のオブジェクト間のイーサネットフレーム移送は許可され、テナントＢ７００−２内のオブジェクト間のイーサネットフレーム移送は許可され、他のイーサネットフレームは破棄される。

８７図１７の例では、ＯｐｅｎＦｌｏｗテーブルのフローの確認後、イーサネットフレーム転送が通常のイーサネットフレームフォワーダ２００ｄによって実行されてもよい。バックボーンネットワークに接続する各スイッチ２００ポートは、ＭＡＣ−ＭＡＣ／ＩＰトンネリングとして構成されて、イーサネット／ＩＰフレームを、必要に応じて複数のクラウドコンピューティングサブシステムにわたって配信してもよい。

８８図１７の本発明のフローテーブルは、同じテナント内の各リソースにわたるブロードキャストフレームの送信を、ＡＲＰによるものを除いて禁じる。なお、同じテナント内でのブロードキャストフレームの送信を可能にする他の構成も可能である。

８９図１８（ａ）は、本発明の実施形態によるＯｐｅｎＦｌｏｗフローテーブルの別の例を示す。図１８（ａ）の例では、図６のスイッチＰＳｗｉｔｃｈ０１６０２−０１の構成例が提供されている。イーサネットフレームが受信されると、ＰＳｗｉｔｃｈ０１は、図１８（ａ）のＯｐｅｎＦｌｏｗフローテーブルに基づき、以下のように進行する。フレームがＰ２４（バックボーンネットワークに接続するアップリンクポート）から受信されると、ＰＳｗｉｔｃｈ０１６０２−０１は、フレームが別のクラウドコンピューティングサブシステムから来たかどうかを評価する。図１８（ａ）の例では、ＰＳｗｉｔｃｈ０１６０２−０１は、テーブルのＶＬＡＮＩＤを有するすべてのフレームを、クラウドコンピューティングサブシステム関係のフレームと見なす。フレームがＡＲＰブロードキャストであれば、ＰＳｗｉｔｃｈ０１６０２−０１は、フレームを管理ノード４００内のＯｐｅｎＦｌｏｗコントローラに送信する。ソースＭＡＣアドレスがテナントＡ７００−１のＭＡＣアドレスであれば、「テナントＡ」のフローテーブルグループ（例えば、図１８（ｂ）に示されている）が適用される。ソースＭＡＣアドレスがテナントＢのＭＡＣアドレスであれば、「テナントＢ」のフローテーブルグループが適用される。

９０図１８（ｂ）は、本発明の実施形態による、ＰＳｗｉｔｃｈ０１６０２−０１、グループ「テナントＡ」７００−１のＯｐｅｎＦｌｏｗフローテーブルの例を示す。上記のように、受信されたフレームが、テナントＡ７００−１のＭＡＣアドレスに対応するソースＭＡＣアドレスを含めば、ＰＳｗｉｔｃｈ０１６０２−０１は、図１８（ｂ）のフローテーブルに基づき、以下のように進行する。宛先ＭＡＣアドレスがブロードキャストアドレスであれば、フレームは、テナントＡ７００−１の物理リソースおよび仮想スイッチを接続するすべてのポートに送信される。宛先ＭＡＣアドレスがブロードキャストアドレスであれば、フレームはアップリンクポートに送信される（アップリンクポートが進入ポートでない場合）。特定の宛先ＭＡＣアドレスを有するイーサネットフレームは、ＰＳｗｉｔｃｈ０１上の対応するポートに送信される。図１８（ｂ）の例では、ＭＶ０１およびＭＶ０２へのフレームは、Ｐ０（ＶＳｗｉｔｃｈ０１６０３−０１）へ送信され、ＭＶ０３へのフレームは、Ｐ１（ＶＳｗｉｔｃｈ０２６０３−０２）へ送信され、ＭＰ０４へのフレームは、Ｐ２（物理ホスト）へ送信され、ＬＵ０２へのフレームは、Ｐ３（ストレージアレイ３００）へ送信される。

９１図１８（ｂ）の例では、宛先ＭＡＣアドレスが、同じテナントであるが別のクラウドコンピューティングサブシステム（例えば、サブシステムＢ）内のリソースによって所有されていれば、ＰＳｗｉｔｃｈ０１６０２−０１は、カプセル化のために、クラウドコンピューティングサブシステムおよびＶＬＡＮ１００のスイッチ２００ｙのＭＡＣ／ＩＰアドレスを有するイーサネット／ＩＰヘッダを追加して、続いてそれをＰ２４へ送信する。

９２図１８（ｃ）は、本発明の実施形態による、ＶＳｗｉｔｃｈ０１６０３−０１、グループ「テナントＡ」７００−１のＯｐｅｎＦｌｏｗテーブルの例を示す。イーサネットフレームが受信されると、ＶＳｗｉｔｃｈ０１は、図１８（ｃ）のフローテーブルに従い以下のように動作する。

９３宛先ＭＡＣアドレスがブロードキャストアドレスであれば、フレームは、テナントＡ７００−１の仮想リソースに接続するすべてのポート、さらにブロードキャストがアップリンクポートから来ていなければＰＳｗｉｔｃｈ０１６０２−０１のアップリンクポート（Ｐ５１２）に送信される。特定の宛先ＭＡＣアドレスを有するイーサネットフレームは、ＶＳｗｉｔｃｈ０１６０３−０１上の対応するポートに送信される。図１８（ｃ）の例では、ＭＶ０１へのフレームは、ポートＰ０に送信され、ＭＶ０２へのフレームは、ポートＰ１に送信される。

９４宛先ＭＡＣアドレスが、同じテナントのリソースであるが仮想スイッチ（ＶＳｗｉｔｃｈ０１６０３−０１）に接続されていないリソースによって所有されていれば、ＶＳｗｉｔｃｈ０１６０３−０１は、フレームをアップリンクポートに送信する。

９５図１９（ａ）および図１９（ｂ）は、本発明の実施形態によるスイッチ管理テーブルの例を示す。スイッチ管理テーブルは、各スイッチに関連する物理および仮想リソース、ならびに各リソースに関連する、各スイッチの対応するポートの情報を提供することによって、図１８（ａ）〜１８（ｃ）に示されているＯｐｅｎＦｌｏｗフローテーブルを作成するために使用される。スイッチ管理テーブルは、物理／仮想リソースが展開／削除、移動されるたびに、トポロジ収集機能４００ｂ−３によって更新される。図１９（ａ）および１９（ｂ）の例では、スイッチ管理テーブルは、明確にするために、物理スイッチＰＳｗｉｔｃｈ０１６０２−０１およびＰＳｗｉｔｃｈ０２６０２−０２ごとに、それらに関連する仮想スイッチとともに分けられているが、両方のテーブルを１つのスイッチ管理テーブルに組み入れることが可能である。

９６物理リソースが展開されると、トポロジ収集機能４００ｂ−３は、ホストのＭＡＣアドレスを取得し、続いて、接続されるべき物理ポートおよび物理スイッチ２００を判断する。トポロジ収集機能４００ｂ−３は、ＬＬＤＰ（リンクレイヤディスカバリプロトコル）、ＮＩＣのオン／オフに伴うＳＮＭＰトラップ（リンクアップ／ダウン）の確認などの様々な方法で物理ポートおよびスイッチを判断することができる。

９７仮想リソースが展開されると、トポロジ収集機能４００ｂ−３は、ハイパーバイザソフトウェアなどの使用によって、仮想リソースの仮想ＮＩＣ、および仮想リソースに接続された仮想スイッチ上の仮想ポートを取得する。

９８ＶＭｏｔｉｏｎ（仮想リソースの別の物理ホストへの移動）が生じると、トポロジ収集機能４００ｂ−３は、仮想スイッチ情報を調べなおして、スイッチ管理テーブルを更新する。

９９さらに、本願明細書に開示されている実施形態の明細事項および実施を考慮することで、実施形態の他の実装が当業者には明らかとなる。記載された様々な実施形態および／またはコンポーネントは、単一で、または任意の組み合わせで、クラウドコンピューティングサブシステムにおいて使用されてよい。提供された明細事項および実施例は、実施例としてのみ考慮されるものとし、実施形態の真の範囲および意図は、添付の特許請求の範囲によって示される。

１００ホスト
２００スイッチ
３００ストレージアレイ
４００管理ノード
４００ａＣＰＵ
４００ｂＲＡＭ
４００ｃポート
４００ｂ−１オペレーティングシステム
４００ｂ−２リソースプロビジョニング機能
４００ｂ−３トポロジ収集機能
４００ｂ−４アドレス解決機能
４００ｂ−５デバイス構成機能
４００ｂ−６ＰＸＥ／ＴＦＴＰ／ＤＨＣＰブート機能

Claims

ホストコンピュータと、
複数のテナントを管理する管理コンピュータであって、前記複数のテナントのうちの少なくとも１つは、前記ホストコンピュータ上の１以上の仮想リソースおよび１以上の物理リソースのうちの少なくとも１つを含む、前記管理コンピュータと、
前記１以上の仮想リソースおよび前記１以上の物理リソースのうちの前記少なくとも１つのアドレス情報を使用することによって、前記複数のテナントそれぞれのアクセスを、前記管理コンピュータからのフロー情報に基づき制御する１以上のスイッチと
を備え、
前記管理コンピュータは、前記複数のテナントそれぞれに関して前記フロー情報を管理し、
前記１以上のスイッチは、前記複数のテナントそれぞれを定義した前記フロー情報を使用して前記テナントそれぞれのフレームのフローを制御するために切り替わると共に、仮想スイッチおよび物理スイッチを含み、
前記仮想スイッチは、前記フレームの宛先アドレス情報を特定し、前記フロー情報を参照して、前記宛先アドレス情報に対応する前記アドレス情報を有する仮想リソースまたは物理リソースに前記フレームを転送することによって、前記複数のテナントのうち、前記仮想スイッチに関連する少なくとも１つのテナントに関して前記フレームの前記フローを制御するように構成されており、
前記物理スイッチは、前記フレームのソースアドレス情報を特定し、前記フロー情報を参照して、前記複数のテナントのうち、前記ソースアドレス情報に対応する前記アドレス情報を有する仮想リソースまたは物理リソースを有する対応するテナントを特定することによって、前記複数のテナントのうちの前記少なくとも１つそれぞれに対するアクセスを制御するように構成され、
さらに、前記物理スイッチは、前記フレームの宛先アドレス情報を特定し、前記複数のテナントのうちの前記対応するテナントの前記フロー情報を参照して、前記複数のテナントのうちの前記対応するテナントの中で、前記宛先アドレス情報に対応する前記アドレス情報を有する対応する仮想リソースまたは物理リソースを判断するように構成されている、コンピュータシステム。
前記管理コンピュータは、アドレス解決プロトコル（ＡＲＰ）ブロードキャストにおいて解決されるべきアドレスを特定すること、および解決されるべき前記アドレスの解決を、前記ＡＲＰブロードキャストに関連するソースアドレスに対応する前記１以上のスイッチに転送することによって、前記ＡＲＰブロードキャストを処理するように構成されている、請求項１に記載のコンピュータシステム。
複数のテナントのうちの少なくとも１つがホストコンピュータ上の１以上の仮想リソースおよび１以上の物理リソースのうちの少なくとも１つを含む、前記複数のテナントを管理し、
前記複数のテナントそれぞれのアクセスを制御するために１以上のスイッチによって使用され前記１以上の仮想リソースおよび前記１以上の物理リソースのうちの前記少なくとも１つのアドレス情報に関連するフロー情報を、前記複数のテナントそれぞれに関して管理するように構成されている、中央処理ユニット（ＣＰＵ）を備え、
前記フロー情報は、
前記テナントそれぞれのフレームのフローを制御するために切り替わる前記１以上のスイッチによって使用されるように、前記複数のテナントそれぞれを定義すると共に、
前記複数のテナントのうち、前記フレームの前記フローを制御するように構成された仮想スイッチに関連する少なくとも１つのテナントの、仮想リソースまたは物理リソースそれぞれの前記アドレス情報を含み、前記複数のテナントのうち、前記仮想スイッチに関連する前記少なくとも１つのテナントの、前記仮想リソースまたは前記物理リソースそれぞれに関して、前記フレームに対するアクション情報、および、仮想リソースまたは物理リソースそれぞれの前記アドレス情報と、前記複数のテナントのうち、前記アクセスを制御するように構成された物理スイッチに関連する各テナントとの関連付け、を含み、
さらに、前記複数のテナントのうち、前記物理スイッチに関連する少なくとも１つのテナントの、仮想リソースまたは物理リソースそれぞれの前記アドレス情報と、前記複数のテナントのうち、前記物理スイッチに関連する前記少なくとも１つのテナントの、前記仮想リソースまたは前記物理リソースそれぞれに関する、前記フレームに対するアクション情報とを含む、管理コンピュータ。
前記ＣＰＵは、アドレス解決プロトコル（ＡＲＰ）ブロードキャストにおいて解決されるべきアドレスを特定すること、および解決されるべき前記アドレスの解決を、前記ＡＲＰブロードキャストに関連するソースアドレスに対応する前記１以上のスイッチに転送することによって、前記ＡＲＰブロードキャストを処理するように構成されている、請求項３に記載の管理コンピュータ。
管理コンピュータに対する命令を記憶するコンピュータ可読ストレージ媒体であって、
前記命令は、
複数のテナントのうちの少なくとも１つがホストコンピュータ上の１以上の仮想リソースおよび１以上の物理リソースのうちの少なくとも１つを含む、前記複数のテナントを管理すること、および、
前記複数のテナントそれぞれのアクセスを制御するために１以上のスイッチによって使用され前記１以上の仮想リソースおよび前記１以上の物理リソースのうちの前記少なくとも１つのアドレス情報に関連するフロー情報を、前記複数のテナントそれぞれに関して管理すること、を実行するもので、
前記フロー情報は、
前記テナントそれぞれのフレームのフローを制御するために切り替わる前記１以上のスイッチによって使用されるように、前記複数のテナントそれぞれを定義すると共に、
前記複数のテナントのうち、前記フレームの前記フローを制御するように構成された仮想スイッチに関連する少なくとも１つのテナントの、仮想リソースまたは物理リソースそれぞれの前記アドレス情報を含み、前記複数のテナントのうち、前記仮想スイッチに関連する前記少なくとも１つのテナントの、前記仮想リソースまたは前記物理リソースそれぞれに関して、前記フレームに対するアクション情報、および、仮想リソースまたは物理リソースそれぞれの前記アドレス情報と前記複数のテナントのうち前記アクセスを制御するように構成された物理スイッチに関連する各テナントとの関連付け、を含む情報であり、
さらに、前記複数のテナントのうち、前記物理スイッチに関連する少なくとも１つのテナントの、仮想リソースまたは物理リソースそれぞれの前記アドレス情報と、前記複数のテナントのうち、前記物理スイッチに関連する前記少なくとも１つのテナントの、前記仮想リソースまたは前記物理リソースそれぞれに関する、前記フレームに対するアクション情報とを含む、コンピュータ可読ストレージ媒体。
前記命令は、
アドレス解決プロトコル（ＡＲＰ）ブロードキャストにおいて解決されるべきアドレスを特定すること、および
解決されるべき前記アドレスの解決を、前記ＡＲＰブロードキャストに関連するソースアドレスに対応する前記１以上のスイッチに転送すること、
をさらに実行するものである、請求項５に記載のコンピュータ可読ストレージ媒体。