JPWO2014128948A1 - 仮想サーバおよび非仮想サーバ混在環境におけるテナントネットワーク構成の管理方法 - Google Patents

仮想サーバおよび非仮想サーバ混在環境におけるテナントネットワーク構成の管理方法 Download PDF

Info

Publication number
JPWO2014128948A1
JPWO2014128948A1 JP2015501211A JP2015501211A JPWO2014128948A1 JP WO2014128948 A1 JPWO2014128948 A1 JP WO2014128948A1 JP 2015501211 A JP2015501211 A JP 2015501211A JP 2015501211 A JP2015501211 A JP 2015501211A JP WO2014128948 A1 JPWO2014128948 A1 JP WO2014128948A1
Authority
JP
Japan
Prior art keywords
virtual
physical
instance
network
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2015501211A
Other languages
English (en)
Other versions
JP5953421B2 (ja
Inventor
充実 寺山
充実 寺山
俊雄 大谷
俊雄 大谷
永見　明久
明久 永見
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Application granted granted Critical
Publication of JP5953421B2 publication Critical patent/JP5953421B2/ja
Publication of JPWO2014128948A1 publication Critical patent/JPWO2014128948A1/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Abstract

サーバ仮想化により一つの物理サーバを複数の計算機環境に分割して利用する仮想サーバと、サーバ仮想化を用いず一つの物理サーバを直接的に計算機環境とした非仮想サーバとが混在する環境において、非仮想サーバと仮想サーバを同じテナントとなるよう運用する。管理コンピュータにより、複数の仮想サーバのそれぞれについて当該仮想サーバが接続する内部ネットワークとの対応関係を示す仮想スイッチ管理情報と、非仮想サーバと当該非仮想サーバが接続する内部ネットワークとの対応関係を示す物理スイッチ管理情報とを備える。管理コンピュータは物理インスタンスと同じテナントに属する仮想サーバの作成要求を受信すると、物理スイッチ管理情報を参照して、当該非仮想サーバが接続する第1の内部ネットワークを特定し、当該仮想サーバが第1の内部ネットワークに接続されるように設定する。

Description

本発明は一般的には計算機システムに関連し、より具体的には仮想サーバおよび物理サーバが混在する計算機システムにおいて、ネットワークを始めとしたリソースの構成を管理する方法および装置に関連する。
サーバ仮想化技術が普及し、企業情報システムを構築するための複数の仮想サーバを単一のハードウェア上（単一の物理サーバ）に統合することが一般的となった。サーバ仮想化技術によれば、従来物理サーバに一対一に関連付けられていた物理サーバの物理リソース（ＣＰＵ、メモリなど）を、複数サーバリソースに分割し、各サーバリソースに仮想サーバを独立して動作させるなどして、有効活用できる。さらには、物理リソースの仮想サーバへの割り当て量を柔軟に変更したり、仮想サーバを別の物理サーバ（仮想化機能を融資、複数の仮想サーバを動作させることのできる物理サーバ、以降このような物理サーバを「仮想サーバホスト」という）へと移動させることで、仮想サーバ上のアプリケーションが提供するサービスの需要に応じたリソース配分とすることができる。しかし、仮想サーバは単一の仮想サーバホストが提供するリソースを共有しているために、同じ仮想サーバホスト上の他の仮想サーバから性能上の影響を受ける。
そこで、仮想サーバが存在する環境であっても、ハイパバイザ（複数の仮想サーバを単一の物理サーバ上で動作させる機能を有するソフトウェア）を有さない物理サーバをそのまま処理環境として利用する運用方法が考えられる。ハイパバイザを有さない物理サーバは一つのハードウェア装置（物理サーバ）が持つ物理リソースを占有するので、処理性能を全て活用することができ、さらに他のサーバから影響を受けることなく安定稼働させることができる。ここでは、それら物理サーバを非仮想サーバ、あるいはベアメタルサーバと呼ぶ。非仮想サーバは、前述のように性能面における利点があるものの、複数の仮想サーバを動作させることのできる仮想サーバホストと比較しシステム構築の柔軟性に欠く。 一方、近年の傾向として、クラウドコンピューティングの隆盛がある。クラウドでは多数のサーバを仮想化によりプラットフォームに集約、統合管理することで運用管理コストを削減し、情報システムへの依存度の高まりに応えている。そのようなクラウドの特長として、ユーザのマルチテナント管理を強化している点が挙げられる。
テナントは、特定のユーザグループや組織ごとに、クラウドが提供するリソースやサービスメニューを関連付けるものである。複数のテナントが一つのクラウド基盤を共有することで、プラットフォーム全体の利用効率を高めることができる。このとき、他のテナントが自身のテナントのリソースに不正にアクセスできないよう、セキュリティを保護する仕組みが必要不可欠である。一般的なクラウドシステムでは、ユーザ認証やネットワークの分割により、テナントごとにセキュリティが確保される。ネットワーク上にはネットワークポリシを設定する管理装置が配置されており、テナントやユーザ、仮想サーバの用途に応じてサーバ間の通信の許可・不許可を制御する。このようなネットワーク構成管理装置は、テナントや仮想サーバの需要に応じて柔軟に作成・変更可能である必要があり、ネットワークアプライアンスと呼ばれる仮想サーバとして実現される。
また、性能の観点においても、他のテナントで稼働する業務システムの稼働状態に影響されず、安定的に稼働する仕組みが必要である。仮想サーバ環境においては、仮想サーバのオンライン移行を利用した負荷分散や、仮想サーバごとの通信の優先度制御などにより、安定稼働を実現する動きが一般的である。
前述の通り、多数のテナントを一つのプラットフォームに集約した環境では、リソース利用効率が高まる一方、処理性能の確保が課題となる。非仮想サーバの活用は、安定的な計算処理性能を得るための一つの解決策であるが、ディスクＩＯ性能やネットワーク性能についても同様に性能を高める工夫が必要不可欠である。その上、それら多岐の項目にわたるリソース構成は、時々刻々と変化するプラットフォーム全体の利用状況に合わせて適切に変更されなければならない。
例えば、特許文献１はネットワーク上の通信負荷を分散するルータの構成方法およびシステムを開示している。同システムにより、複数のネットワーク経路を並行して利用でき、ネットワークリソースを有効に活用することができる。また、特許文献２は、マルチテナント環境において効率的に構成を管理する方法を開示している。
特開２００３−２３４４４号公報 特開２０１２−１８２６０５号広報
従来技術、同一テナントに非仮想サーバと仮想サーバホスト上で動作する仮想サーバとを混在させた場合のネットワークリソース管理方法を提供する技術は開示されていない。これは、従来、一部のワークロードに対して性能の安定化を実現する目的で、非仮想サーバを仮想サーバが構成しているものと同じテナントネットワークに接続して活用するという発想そのものがなかったためである。
本発明の目的は、非仮想サーバと仮想サーバを同じテナントで運用し、セキュリティ面および性能面での独立性を確保しながら、ユーザの要求に応じて性能とコストが最適化された情報システムを構築することである。
管理コンピュータは、複数の仮想インスタンス（仮想サーバ）および当該仮想インスタンス間のネットワークを制御する仮想スイッチが動作する第1の物理サーバと、物理インスタンスが動作する第2の物理サーバと、第1の物理サーバと第2の物理サーバと接続され、第1の物理サーバおよび第2の物理サーバ間のネットワークを制御する物理スイッチと、に接続される。そして、管理コンピュータは、複数の仮想インスタンスのそれぞれについて当該仮想インスタンスが接続する内部ネットワークとの対応関係を示す仮想スイッチ管理情報と、物理インスタンスと当該物理インスタンスが接続する内部ネットワークとの対応関係を示す物理スイッチ管理情報とを備える。そして管理コンピュータは前記物理インスタンスと同じ内部ネットワークに接続する第1の仮想インスタンスを作成するための第1のインスタンス作成要求を受信すると、第1の物理サーバ上に前記第1の仮想インスタンスを作成し、物理スイッチ管理情報を参照して、前記物理インスタンスが接続する第1の内部ネットワークを特定し、前記第１の仮想インスタンスが前記第1の内部ネットワークに接続されるように前記仮想スイッチと前記物理スイッチを設定する。
本発明によれば、ユーザにそれぞれセキュリティが確保されたテナントが提供されながらも、複数のテナントを同じ物理ハードウェア上で稼働させることができる。そして、非仮想サーバと仮想サーバとを同じテナントで運用し、セキュリティ面および性能面での独立性を確保しながら、ユーザの要求に応じて性能とコストが最適化された情報システムを構築できることができる。非仮想サーバを仮想サーバと同じテナントとして活用することにより、他のテナントからセキュリティを確保しながら、ユーザが利用する多数の業務システムに対して、その時々の処理要求に応じて、性能要求の低い処理をサーバ仮想化により少数の物理装置に集約したり、性能要求が高い処理を非仮想サーバで安定的に稼働させたりするといった使い分けが可能となる。つまり、サーバ上に稼動させるアプリケーションのライフサイクルに応じてリソース構成を変更し、全体最適な情報システムを構築することができる。例えば、需要が予測できないサービス開始時には仮想サーバを利用して柔軟にリソースを増減させ、徐々に需要がある程度に定まってきた時には非仮想サーバでサービス安定稼働させ、さらに次期システムへの移行が近くなれば仮想サーバへ集約してリソース利用効率の高める、といった運用が実現できる。
本発明の実施例における計算機システムの全体構成を示す。 本発明の実施例における計算機システムの物理構成を示す。 本発明の実施例における計算機システムの論理構成を示す。 本発明の第一の実施例における計算機システムのネットワーク構成を示す。 本発明の第一の実施例におけるＶＬＡＮ ＩＤ管理テーブルを示す。 本発明の第一の実施例におけるＶＬＡＮ ＩＤ管理テーブルを示す。 本発明の第一の実施例における処理フローを示す。 本発明の第二の実施例における計算機システムのネットワーク構成を示す。 本発明の第二の実施例におけるＤＨＣＰサーバによるネットワーク経路設定の概念を示す。 本発明の第二の実施例におけるネットワークアドレス管理テーブルを示す。 本発明の第二の実施例における管理コンピュータの詳細を示す。 本発明の第二の実施例における処理フローを示す。 本発明の第二の実施例におけるエレメント管理テーブル群を示す。 本発明の第二の実施例におけるＶＬＡＮ ＩＤ管理に関わる管理テーブルの関係を示す。 本発明の第三の実施例におけるＯＳイメージ管理によるネットワーク経路設定の概念を示す。 本発明の第四の実施例における外部アクセスの負荷分散方法の概念を示す。 本発明の第一の実施例におけるＶＬＡＮ ＩＤ管理テーブルを示す。
本実施例によれば、仮想サーバから構成されるクラウド環境において、非仮想サーバを混在させて利用するために、共通のネットワークを動的に構成するシステムが提供される。特に、仮想サーバおよび非仮想サーバの作成手順と、その構成手順の一部として行われるネットワークの構成手順を、以下に説明する。
＜物理構成および論理構成＞
図１は、本実施例における計算機システムの全体像を示す。
同図において、サーバ上のアプリケーションによるサービスを受けるユーザは、クライアントコンピュータ７０を利用する。一つ以上のクライアントコンピュータ７０は、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）３０２、およびＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）３００を介して一つ以上の物理サーバ１０および２０と通信できるよう、物理的に接続される。
本実施例では、主に物理サーバ１０が接続される（サービス用の）ＬＡＮ３００などと、クライアントコンピュータ７０が接続されるＷＡＮ３０２などとを区別し、説明のため前者を内部ネットワーク、後者を外部ネットワークと呼ぶ。
内部ネットワークと外部ネットワークとの境界には物理ゲートウェイ５００が介在し、同物理ゲートウェイ５００に流れる通信データに対して様々な処理を行い、通信を制御する。ゲートウェイの構成およびゲートウェイが有する機能についての詳細は後述する。説明を簡略化するため、図１は単純な構成をとるが、必要に応じてゲートウェイが多段であってもよいし、ＷＡＮ３０２が別のＬＡＮであってもよい。さらには、ＷＡＮやＬＡＮが複数のネットワークに物理分割または論理分割されていてもよい。
また、管理用のＬＡＮ３０１を介して、管理コンピュータと、その他各装置（例えば物理サーバ１０、およびストレージ装置１００）の管理インタフェースが相互に接続される。
一つ以上の物理サーバ１０および２０は、それぞれＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）５１を介してストレージ装置１００に接続される。
図２は、内部ネットワークに接続される各装置の、より詳細な物理構成および論理構成を示す。図１における内部ネットワーク３００は、図２においてネットワーク６１として表現される。ネットワーク６１には、少なくとも一つ以上の第一の物理サーバ１０、第二の物理サーバ２０、ストレージ装置１００、管理コンピュータ２００が物理的に接続される。さらに、一つ以上のゲートウェイ５００がネットワーク６１およびネットワーク６６の境界に接続される。このとき、図２におけるネットワーク６６は、図１における外部ネットワーク３０２にあたる。
第一の物理サーバ１０は、ＣＰＵ１１、メモリ１２、ファイバチャネルインタフェース（ＦＣ ＩＦ）１５、およびイーサネット（以下登録商標）インタゲース（Ｅｔｈｅｒ ＩＦ）１６を備える。メモリ１２には少なくともＯＳ１３ａが格納され、ＣＰＵ１１の演算処理によって物理サーバ１０で稼働するアプリケーション１３ｂに対し処理リソースを提供する。移行、特に仮想化プログラムが稼働せず、ＯＳ１３ａが物理サーバ１０上で直接的に稼働するという意味で、物理サーバ１０を非仮想サーバまたはベアメタルサーバと呼ぶこともある。
ＦＣ ＩＦ１５は、ネットワーク５１を介して他の装置と通信を行うためのものであり、主にストレージ資源を接続する目的で使用される。同じ目的を達成する相互接続の手段であれば、ファイバチャネル以外の通信規格を使用してもよく、また、用途によって物理的に複数設けられても、論理的に複数に分割されてもよい。Ｅｔｈｅｒ ＩＦ１６は、ネットワーク６０を介して他の装置と通信を行うためのものであり、他の物理サーバ１０、２０、および管理コンピュータ２００と通信する目的で使用される。同じ目的を達成する相互接続の手段であれば、イーサネット以外の通信規格に準拠するものであってもよく、また、用途によって物理的に複数設けられても、論理的に複数に分割されてもよい。
第二の物理サーバ２０は、ＣＰＵ２１、メモリ２２、ＦＣ ＩＦ２５、およびＥｔｈｅｒ ＩＦ２６を備える。メモリ２２には少なくともＯＳ２３ａおよび仮想化プログラム２３ｂが格納され、ＣＰＵ２１の演算処理によって、物理サーバ２０が有する物理リソースを一つ以上の仮想的なリソース領域に分割してその他のＯＳまたはアプリケーション２３ｃへ提供する。仮想化プログラム２３ｂは必ずしもＯＳ２３ａと分離される必要はなく、物理サーバ２０を仮想的なリソース領域に分割する機能を備える限りにおいて、ＯＳ２３ａ内部の一つのモジュールとして実装されてもよいし、またはＯＳ２３ａそのものとして実装されてもよい。仮想化プログラム２３ｂは一般にＶＭＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｍｏｎｉｔｏｒ）、ハイパバイザと呼ばれることもあり、以降の説明では、これらは同じものを指す。仮想化プログラム２３ｂの機能により、物理サーバ２０のハードウェアの一部が、閉じたリソース領域として切り出される。このリソース領域は、仮想マシンと呼ばれる一つの論理的なサーバのハードウェアを構成しており、第二の物理サーバ２０を仮想マシンホストと呼ぶこともある。ＦＣ ＩＦ２５、およびＥｔｈｅｒ ＩＦ２６についての詳細は、第一の物理サーバ１０の場合と同様である。
ネットワーク５１は、一つ以上の物理サーバ１０および２０と、一つ以上のストレージ装置１００を相互に接続するためのものである。これにより、物理サーバ１０、２０がストレージ装置１００と通信し、アプリケーション１３ｂ、２３ｃなどが稼働する際に必要なストレージ資源を利用可能とする。ネットワーク５１上には、一つ以上のガイバチャネルスイッチ（ＦＣ ＳＷ）５０が介在してもよい。ＦＣ ＳＷ５０の構成は、Ｅｔｈｅｒ ＩＦ５６が接続されたネットワーク６１を介して、管理コンピュータ２００により設定される。
ネットワーク６１は、主に以下三つの目的のために使用される。
第一の目的は、クライアントコンピュータ７０と、物理サーバ１０および２０との間のサービス通信を提供することである。例えば、物理サーバ１０は、クライアントコンピュータ７０から処理要求や処理対象のデータを受信し、アプリケーション１３ｂより加工または生成されたデータを再度クライアントコンピュータ７０に向け送信する。
第二の目的は、サービス通信に関わる物理サーバ１０および２０の構成変更を行うことである。例えば、物理サーバ２０上に新たなアプリケーション２３ｃを導入したり、仮想化プログラム２３ｂ上に仮想サーバと呼ばれるリソース領域を作成したりといったことが行われる。
第三の目的は、物理サーバ１０、２０とストレージ装置１００との間のデータネットワーク５１について構成を変更することである、例えば、ストレージ装置１００のストレージ制御部１５０を通じて、ボリュームと呼ばれるストレージ資源の単位を作成し、物理サーバとの論理的な通信路を設定することで、ストレージ資源を利用可能とする。
ストレージ装置１００は、複数の物理ストレージデバイス１０１を集積したものであり、装置を集中的に制御するストレージ制御部１５０を備え、物理サーバなど他の装置に対してデータ格納用のストレージ資源を提供する。図２に示すように、物理ストレージデバイス１０１は、例えばハードディスクドライブ（ＨＤＤ）や、ソリッドステートドライブと呼ばれる不揮発性の記憶デバイスが用いられる。
ストレージ制御部１５０は、ＣＰＵ１５１、メモリ１５２、キャッシュ１５４、ＦＣ ＩＦ１５５、Ｅｔｈｅｒ ＩＦ１５６、Ｓｅｒｉａｌ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔインタフェース（ＳＡＴＡ ＩＦ）１５７を備える。メモリ１５２には、少なくとも読み書き要求に応答する応答プログラム１５３ａ、および装置の論理構成を制御するストレージ制御プログラム１５３ｂ含むプログラムが格納され、ＣＰＵ１５１における演算処理によりストレージ装置１００の機能を実現する。キャッシュ１５４は、主に物理サーバの読み書き要求に対するストレージ資源の応答性能を向上されるために用いられる。ＦＣ ＩＦはネットワーク５１を介して他の装置と通信を行うためのものであり、主に物理サーバ１０、２０と接続する目的で使用される。同じ目的を達成する相互接続の手段であればファイバチャネル以外の通信規格を使用してもよく、また物理サーバの台数などに応じて複数あってもよい。Ｅｔｈｅｒ ＩＦ１６は、ネットワーク６０を介して他の装置と通信を行うためのものであり、主に管理コンピュータ２００と接続する目的で使用される。
管理コンピュータ２００は、ＣＰＵ２０１、メモリ２０２、Ｅｔｈｅｒ ＩＦ２０６を備え、主に他の装置の構成を変更する機能を有する。メモリ２０２には、少なくとも管理コンピュータのハードウェアを制御するＯＳ２０３ａ、および管理プログラム２０３ｂが格納され、ＣＰＵ２０１の演算処理により管理コンピュータ２００の機能を実現する。管理プログラム２０３ｂは、管理コンピュータ２００が許容する処理能力を超えない限り、用途に応じて複数稼働してもよい。管理プログラム２０３ｂの詳細については後述する。Ｅｔｈｅｒ ＩＦ２０６は、ネットワーク６０を介して他の装置と通信を行うためのものである。
物理ゲートウェイ５００は、内部ネットワーク６１および外部ネットワーク６６の境界に一つ以上存在し、同ゲートウェイを通過する通信データや内部ネットワーク内に流れる通信データに対して特定のポリシを適用する機能を有する。本実施例におけるゲートウェイとは、一般にはルータと呼ばれるものであり、例えばレイヤ３ルータ、ファイヤウォール、ネットワークアドレス変換（ＮＡＴ）、プロキシ、リバースプロキシ、ＶＰＮルータ、ポートフォワーディングといった機能の一つまたは複数を実装するものである。物理ゲートウェイ５００は、物理サーバ１０や２０、管理コンピュータ２００と同様に、ＣＰＵ５０１、メモリ５０２、Ｅｔｈｅｒ ＩＦ５０６を有する。メモリ５０２上にはＯＳ５０３ａや一つまたは複数のネットワーク制御プログラム５０３ｂを有し、ＣＰＵ５０１の演算処理により物理ゲートウェイ５００の機能を実現する。また、少なくとも複数のＥｔｈｅｒ ＩＦ５０６を持ち、論理的に内部ネットワーク６１側のインタフェース５０６ａと、外部ネットワーク６６側のインタフェース５０６ｂとに分類できる。ネットワーク制御プログラム５０３ｂが実現する機能の詳細については後述する。
ネットワーク６６は、物理サーバ１０および２０や管理コンピュータ２００、ストレージ装置１００から見て外部ネットワークである。図２には示していないが、ネットワーク６６から見てさらに外部にゲートウェイがあってもよい。また、ネットワーク６６は、Ｅｔｈｅｒ ＳＷ６５を介して構成されてもよい。
＜インスタンスの構成方法＞
本実施例における計算機システムは、仮想サーバおよび非仮想サーバのリソース構成を管理する機能を提供する。以下、仮想サーバおよび非仮想サーバを生成する際の構成手順を例に、システムの構成および機能を説明する。なお、ここでは、ユーザの要求に応じて生成され、クライアントに情報サービスを提供するサーバをインスタンスと呼び、仮想サーバを仮想インスタンス、非仮想サーバを物理インスタンスと呼ぶ。
図３に、本実施例においてインスタンスに割り当てるリソースを制御するためのシステム構成を示す。所望のインスタンスを作成するとき、エンドユーザはクライアントコンピュータ７０上の管理クライアント７３ｂを使用して管理コンピュータ２００にアクセスする。管理コンピュータ２００は、管理ネットワーク３０２ｂを介してクライアントコンピュータ７０と接続されており、管理プログラム２０３ｂの一種（または構成要素）である統合サービス管理部２０４ａにおいて、管理クライアント７３ｂが発信したインスタンス作成要求を受け付ける。統合サービス管理部２０４ａは、各装置の構成を管理する装置管理部（サーバ管理部２０４ｂ、ネットワーク管理部２０４ｃ、およびストレージ管理部２０４ｂ）を協調的に制御し、インスタンスを生成する働きを担う。
より具体的には、次のような手順でインスタンスを生成する。
統合サービス管理部２０４ａは、ストレージ管理部２０４ｄにボリュームの作成要求を発行する。このとき、ストレージ管理部２０４ｄはストレージ装置１００内部に、ボリュームと呼ばれる論理的な単位でストレージ資源を確保する。適切なボリュームが既に存在している場合は、このボリューム作成手順は省略される。後述の手順を経ることで、ボリュームはサーバ装置により、例えばディスクドライブなどの不揮発性の記憶デバイスとして認識される。ボリュームが作成されると、ストレージ管理部２０４ｄは、統合サービス管理部２０４ａに対して、ボリュームの状態や、当該ボリュームが利用可能なＦＣ ＩＦ１５５の識別子などを応答する。その後、統合サービス管理部２０４ａは、ボリューム作成手順と合わせて、インスタンスを作成するための物理サーバを選定する。仮想インスタンスが要求される場合には、ハイパバイザの構成要件に合致した物理サーバ２０が選択され、物理インスタンスが要求される場合には、インスタンスの構成要件に合致した物理サーバ１０が選択される。次に、統合サービス管理部２０４ａはネットワーク管理部２０４ｃを利用して、ＦＣ ＳＷ５０において通信経路の設定を行う。ＦＣ ＳＷ５０は、ゾーニングと呼ばれる技術により通信可能なファイバチャネルポートを制御しており、このような設定が必要となる。これにより、選定された物理サーバ１０または２０が有するポート５２が、ストレージ装置１００上のポート５２と通信可能となる。統合サービス管理部２０４ａは、ストレージ管理部２０４ｄを利用して、Ｈｏｓｔ Ｓｔｏｒａｇｅ ＤｏｍａｉｎやＬＵＮ Ｓｅｃｕｒｉｔｙなどのアクセス制御機能の設定を行う。物理サーバからボリュームがディスクデバイス認識サーバ管理部を通じてＯＳ１３ｄまたは２３ｄのインストーラを起動し、ディスクドライブに永続的なＯＳ環境１３ａを導入する。インストーラの転送には、例えばＰＸＥサーバやＴＦＴＰサーバを用いた一般的なネットワークインストール技術が適用できる。ユーザから要求があれば、ミドルウェアやアプリケーション２３ｃをインストールする。このように、記憶デバイスにＯＳ環境を新たに導入する方法の他には、既にセットアップ済みのＯＳ環境を複製する方法があるが、詳細は後述する。
図３に示す例では、物理インスタンス１４の場合は、ストレージ装置１００内のボリューム１６０をＯＳ１３ａに接続し、アプリケーション１３ｂが利用するデータを格納できるよう構成される。仮想インスタンスの場合には、サーバ管理部２０４ｂがハイパバイザ２３ｂを利用して、ボリューム１６０内に仮想ディスク１６１と呼ばれるファイルを作成し、仮想インスタンス２４のゲストＯＳ２３ｄに接続する。仮想インスタンス２４のゲストＯＳ２３ｄからは、仮想ディスク１６１が提供する仮想的なディスクドライブ１６２が接続されたかのように認識される。これら仮想ディスク１６１や仮想インスタンス２４の構成は、直接的にはハイパバイザ２３ｂにより制御される。
その他、ネットワーク管理部２０４ｃを利用して、内部ネットワーク３００に接続するための、Ｅｔｈｅｒ ＳＷ６１やＥｔｈｅｒ ＩＦの設定を行い、さらには外部ネットワーク３０２ａに接続するためのゲートウェイ５００の設定を行う。詳細についてはテナントネットワークの構成方法と合わせて後述する。
インスタンスの状態についての情報は、統合サービス管理部２０４ａにより管理クライアント７３ｂに提供され、ユーザに提示される。ユーザは、所望のサービスクライアント７３ａにより、サービスネットワーク３０２ａを経由して各インスタンスの情報サービスを利用する。さらにユーザは、必要に応じて、管理クライアント７３ｂを利用し、インスタンスの構成を変更することができる。インスタンスの構成を変更する機能は、統合サービス管理部２０４ａおよび各装置管理部により実現される点において、上述したインスタンス作成の場合と同様である。言い換えれば、統合サービス管理部２０４ａは、各装置管理部が備える構成変更機能を組み合わせて利用し、ユーザが必要とするインスタンスの構成変更を実施する。
＜レイヤ２ネットワークの構成方法＞
本発明の目的の一つは、仮想インスタンスおよび物理インスタンスをアプリケーションの要件やユーザの要求に応じて使い分けることである。そのためには、仮想インスタンスおよび物理インスタンスにまたがるプライベートネットワークを構成し、相互に通信可能でなければならない。
ネットワーク装置の互換性、およびハイパバイザの仕様を考慮すると、（レイヤ２）ＶＬＡＮおよび（レイヤ３）ルータを利用してプライベートネットワークを構成する方法が最も一般的である。
ネットワーク通信可能な範囲の制御は、レイヤ２、またはレイヤ３ネットワークの設定のみ、さらには他のレイヤでも実現可能であるが、セキュリティを確保しつつユーザの要求に応じて柔軟にプライベートネットワークを構築する方法として、本項に示す方法が広く用いられている。すなわち、性能が求められる反面、セキュリティ強度を高める必要のない内部ネットワークには、レイヤ２の接続性が確保されたネットワークを一つのレイヤ３セグメントとして構成し、アプリケーションと連携した高度なセキュリティ管理が必要な他セグメントとの外部ネットワーク通信にはレイヤ３の経路制御を利用する方法である。一つのプライベートネットワークには一つのＶＬＡＮ ＩＤが付与され、別のプライベーットネットワークとはレイヤ２のレベルで独立する。異なるプライベートネットワーク間を接続するには、レイヤ３ルータを介してＩＰアドレスを用いた通信が行われる。
この方法によれば、仮想インスタンスおよび物理インスタンスにまたがるプライベートネットワークがレイヤ２透過となり、例えばＤＨＣＰなどブロードキャストを用いた構成管理が利用できる。本項では、各イーサネットスイッチにおいてレイヤ２ネットワークを構成する方法について述べる。
図４に、プライベートネットワークの構成例を示す。同図を用いて、以下レイヤ２ネットワークの構成方法を説明する。ＶＬＡＮはＬＡＮを構成する物理的に単一のネットワーク装置を、パケットに付与したＶＬＡＮ ＩＤと呼ばれる識別子に応じて論理的に多重化する技術である。ＶＬＡＮ ＩＤは、スイッチ装置およびホスト上のイーサインタフェースにおいて設定・解除が可能であるが、本発明が対象とするような複数のホストが任意のタイミングで生成される環境においては、スイッチのみで制御が行われると考えてよい。イーサインタフェースで制御する方法を利用しない理由は、同方法によればＯＳの起動を待たなければイーサインタフェースのＶＬＡＮ設定が出来ない可能性があり、ＯＳ起動以前の挙動が一時的に制御不能になるためである。
すべての装置、すなわち物理サーバ１０および２０、イーサスイッチ６０ｂの構成は、管理コンピュータ２００により管理される。各物理スイッチ６０ｂおよび仮想マシンホスト４００および４０１上のハイパバイザによって実装される仮想スイッチ４０６および４１２はＶＬＡＮに準拠しており、同じＶＬＡＮ ＩＤを付与することにより複数のスイッチにまたがってレイヤ２（データリンク層）の接続性を提供する。他方、異なるＶＬＡＮ ＩＤを付与することにより、レイヤ２ネットワークが分割される。例えば仮想インスタンス４０３の仮想Ｅｔｈｅｒ ＩＦ４０５はＶＬＡＮ ＩＤ＝１０のネットワークに接続されており、同じＶＬＡＮ ＩＤ＝１０のネットワークに接続される（別の仮想マシンホスト上の）仮想インスタンス４１０と通信可能である。一方で、同仮想インスタンス４０３とは別のＶＬＡＮ ＩＤ＝１のネットワークに接続される（同じ仮想マシンホスト上の）仮想インスタンス４０２とは通信不可能である。従来の仮想インスタンスのみの環境であれば、物理スイッチ６０ｂの設定は全てのポートについて全てのＶＬＡＮ ＩＤを許可する設定（トランクオール）であればよかった。この場合、仮想インスタンス間の通信許可／不許可は仮想スイッチの設定のみで完結するため、これらの設定はハイパバイザを管理するサーバ管理部２０４ｃによって実施される。したがって、既存の仮想サーバ環境管理基盤は、物理スイッチの設定機能を持たないのが一般的である。
ベアメタルホスト１０の場合、内部ネットワークをポートＶＬＡＮにより構成する。より具体的には、物理スイッチ６０ｂにおいて、当該ベアメタルホストが接続されているポート４１５にポートＶＬＡＮ属性（アクセスモード）を付与する。これにより、同じＶＬＡＮ ＩＤを持つポート同士のみが通信可能となる。これらポートＶＬＡＮの設定はネットワーク管理部２０４ｂによって実施される。
本発明が目的とするように、仮想インスタンスと物理インスタンスとの間で通信を行うには、同じＶＬＡＮに両者を接続する必要がある。ＶＬＡＮ ＩＤが同じであればレイヤ２の接続性が確保され、同図４の例では物理インスタンスのＥｔｈｅｒ ＩＦ１６ａ、仮想インスタンスのＥｔｈｅｒ ＩＦ４０４がＶＬＡＮ ＩＤ＝１の内部ネットワーク４１３で疎通する。このとき、ポート４１５はポートＶＬＡＮ属性が付与されるが、ポート４１６にはタグＶＬＡＮ属性が付与され、しかもＶＬＡＮ ＩＤ＝１およびＩＤ＝１０のみが許可されなければならない。これは、仮想マシンホスト４００に接続されるポート４１６において仮想インスタンス４０２および４０３両方のデータ送受信が多重化されるためである。このように、従来はトランクオールであればよかった物理スイッチの設定が、インスタンスの所在に応じて適切に制御されなければならない。さらには、物理スイッチの設定および仮想スイッチの設定は、それぞれネットワーク管理部２０４ｂおよびサーバ管理部２０４ｃのそれぞれ別の管理体系のもとに実施されるため、これらの間の整合をとる工夫が新たに必要となる。
本発明において、統合サービス管理部２０４ａが、仮想スイッチおよび物理スイッチにおけるＶＬＡＮ設定を不整合なく行う構成管理方式を提供する。より具体的には、物理スイッチのＶＬＡＮ構成を管理する物理スイッチＶＬＡＮ ＩＤ管理テーブル２１８を有するネットワーク管理部２０４ｂと、仮想スイッチのＶＬＡＮ構成を管理する仮想スイッチＶＬＡＮ ＩＤ管理テーブル２１９を有するサーバ管理部２０４ｃの両方の構成情報を参照・設定する。
物理スイッチＶＬＡＮ ＩＤ管理テーブル２１８を図５（ａ）に示す。同テーブルは、ホストＩＤ２１８ａ、スイッチＩＤ２１８ｂ、ポートＩＤ２１８ｃ、ポート属性２１８ｄ、ＶＬＡＮ ＩＤ２１８ｅを格納する。これにより、物理スイッチのポート属性設定を保持する。例えば第二のレコードは、スイッチＳＷ０１上のポート＃０３が、ＶＬＡＮ ＩＤ＝１およびＩＤ＝１０に接続されるトランクポートであることを示す。複数の物理スイッチがカスケード接続されている場合には、ホストの代わりにスイッチＩＤがホストＩＤフィールド２１８ａに保持される。
仮想スイッチＶＬＡＮ ＩＤ管理テーブル２１９を図５（ｂ）に示す。同テーブルは、インスタンスＩＤ２１９ｃ、スイッチＩＤ２１９ｄ、ポートＩＤ２１９ｅ、ＶＬＡＮ ＩＤ２１９ｂを格納する。これにより、物理スイッチＶＬＡＮ ＩＤ管理テーブル２１８と同様に、仮想スイッチのポート属性設定を保持する。
これらのＶＬＡＮ ＩＤ管理テーブルは管理コンピュータ２００上にあり、各管理プログラムの設定に従って、各物理スイッチ装置および仮想マシンホスト上の仮想スイッチに適用される。
＜処理フロー＞
本発明に特徴的なネットワーク構成方法を、図６に示す処理フローにおいて説明する。統合サービス管理部の詳細については後述することにし、ここでは、ＶＬＡＮを用いたネットワーク構成の詳細手順について述べる。本処理フローの目的は、新たなインスタンスの作成を契機として、仮想インスタンスおよび物理インスタンスが混在する環境においてインスタンス間を相互に接続するプライベートネットワークを構成することである。
さらに、本実施例における処理フローはインスタンスの追加手順を対象とし、同一ＶＬＡＮ内にいずれか一つ以上の既存インスタンスが稼働しているものとする。なお、新たにＶＬＡＮを構成してインスタンスを新規に作成するには、いずれのＶＬＡＮ ＩＤ管理テーブルにもないＶＬＡＮ ＩＤを確保して以下同様の設定を実施すればよい。
ユーザが管理クライアント７３ｂを用いてインスタンス追加要求を発信すると、統合サービス管理部２０４ａがユーザ権限を認証し、前述のインスタンスを既存のプライベートネットワーク上に作成する手順が開始される。ユーザは、または相互に接続したい既存のインスタンスを指定して、新規インスタンスの追加要求を行う。ステップ６００において、前述のインスタンスを作成する手順を完了すると、ステップ６０１で一旦当該インスタンスをシャットダウンし、プライベートネットワークの構成手順に移る。
ステップ６０２の条件判定において、インスタンスの種別によって処理が分岐する。
物理インスタンスを新たにデプロイする場合はステップ６０３に進み、指定された既存のプライベートネットワークに仮想インスタンスが接続されているか、あるいは物理インスタンスが接続されているかにより、さらに処理を分岐させる。
ステップ６０３において仮想インスタンスが当該プライベートネットワークに接続されていると判定された場合はステップ６０４に進む。同ステップにおいて、統合サービス管理部２０４ａは仮想スイッチＶＬＡＮ ＩＤ管理テーブル２１９を参照し、指定された仮想インスタンスＩＤから仮想スイッチのＶＬＡＮ ＩＤを特定する。
一方、既存の物理インスタンスが指定された場合には、処理がステップ６０３からステップ６０５へと分岐する。このとき、統合サービス管理部２０４ａは物理スイッチＶＬＡＮ ＩＤ管理テーブル２１８を参照し、指定された物理インスタンスＩＤ（ホストＩＤ）から物理スイッチのＶＬＡＮ ＩＤを特定する。複数の物理スイッチがカスケード接続されている場合、ホストＩＤフィールド２１８ａに保持されているスイッチＩＤを辿って全ての必要なＶＬＡＮ設定が実施される。
前ステップにおいて特定されたＶＬＡＮ ＩＤは、ステップ６０６において物理スイッチの当該ポートに設定される。なお、このとき当該ポートは新たに追加されたベアメタルホストに接続されるため、ポートＶＬＡＮ属性が設定される。
以上ステップ６０２からステップ６０６までの処理フローは、例えば図４では仮想インスタンス４０２と相互に接続すべく物理インスタンス１４を新たに作成する場合にあたる。このとき、統合サービス管理部２０４ａは、仮想インスタンス４０２のインスタンスＩＤをもとに、仮想スイッチＶＬＡＮ ＩＤ管理テーブル２１９を参照し、同インスタンス４０２が接続されている仮想スイッチ４０６のＶＬＡＮ ＩＤ４０７を特定する。さらに統合サービス管理部２０４ａは、新たに作成された物理インスタンス１４が接続されるポート４１５に対して、同じＶＬＡＮ ＩＤ４１８を付与する。これにより、ＶＬＡＮ ＩＤ＝１のもと、既存の仮想インスタンス４０２と新たな物理インスタンス１４との接続性が確立される。
ユーザが仮想インスタンスの追加を要求した場合には、ステップ６０２からステップ６０７へと分岐する。先の例（ステップ６０３）と同様に、既存の物理インスタンスとの相互接続が指定された場合にはステップ６０８において物理スイッチのＶＬＡＮ ＩＤ設定を参照する。あるいは既存仮想インスタンスとの相互接続が指定された場合にはステップ６０９に進み、当該仮想インスタンスが接続されている仮想スイッチのＶＬＡＮ ＩＤを特定する。
仮想インスタンスを追加する場合には、前ステップにおいて特定されたＶＬＡＮ ＩＤを、仮想スイッチに設定するステップ６１０および物理スイッチに設定するステップ６１１を経て、所望の既存インスタンスとの相互接続が実現される。なお、ステップ６１１においては、物理スイッチの当該ポートに接続されるのは仮想マシンホストであるため、タグＶＬＡＮ属性が設定される。
以上ステップ６０２からステップ６１１までの処理フローは、例えば図４では仮想インスタンス４１０と相互に接続すべく仮想インスタンス４０３を新たに作成する場合にあたる。このとき、統合サービス管理部２０４ａは、仮想インスタンス４１０のインスタンスＩＤをもとに、仮想スイッチＶＬＡＮ ＩＤ管理テーブル２１９を参照し、同インスタンス４０３が接続されている仮想スイッチ４０６のＶＬＡＮ ＩＤ４０８を特定する。さらに統合サービス管理部２０４ａは、新たに作成された仮想インスタンス４０３が接続される仮想スイッチ４０６、および物理スイッチ６０ｂのポート４１６および４１７に対して、同じＶＬＡＮ ＩＤ４０８および４１９を付与する。これにより、ＶＬＡＮ ＩＤ＝１０のもと、既存の仮想インスタンス４１０と新たな仮想インスタンス４０３との接続性が確立される。
ステップ６１２においてインスタンスを再起動すると、当該インスタンスは前述のプライベートネットワーク設定のもとで再稼働する。そのネットワーク設定は続くステップ６１３において、例えば同一ＶＬＡＮ ＩＤが付与されたプライベートネットワーク内の他のインスタンスによるＩＣＭＰ受信により、疎通が確認される。
正常にインスタンスの追加が完了すると、ユーザへ当該インスタンスの利用開始が通知される。このとき、インスタンスにアクセスするためのユーザアカウント情報や、ネットワークアドレスを合わせてユーザへ通知してもよい。
本実施例によれば、複数の物理スイッチおよび仮想スイッチを跨って同じＶＬＡＮが定義され、物理インスタンスおよび仮想インスタンスが混在するプライベートネットワークが構成される。それらプライベートネットワークはレイヤ２のレベルで論理的に分割され、別のプライベートネットワークからのセキュリティが確保される。さらに、図４におけるネットワーク管理部２０４ｂおよびサーバ管理部２０４ｃのように、全く独立して論理ネットワークＩＤが管理されている場合において、これらの管理テーブルに変更を施すことなく上記の構成が実現される。
本実施例によれば、クラウド環境において、仮想サーバおよび非仮想サーバが混在するテナントネットワークを動的に構成するシステムが提供される。特に、仮想・非仮想サーバの使い分けにより各インスタンスに要求される性能を確保した上で、テナントごとに設定されたネットワーク制御ポリシのもとで運用することができる。
＜ゲートウェイの機能＞
本実施例に述べる計算機システムの目的の一つは、ユーザの役割や所属する組織などの権限に応じて、処理を行うリソースやアプリケーションへのアクセスの可否を制御することである。これにより、例えば他の組織・ユーザから自身のデータに不正にアクセスされたり、性能上の影響を受けたりすることなく、所望の業務システムを稼働させることができる。
したがって、サーバ間、あるいはクライアントとサーバを接続するネットワークにおいて、ユーザ権限に応じたアクセス制御を実現する技術が重要となる。本実施例においては、ゲートウェイがネットワーク上を流れる通信に対して通信ポリシを適用する機能を有し、それらのアクセス制御を実現する。
一般的に、ゲートウェイという用語は、レイヤ４以上のネットワークプロトコル変換機のことを指すこともあれば、レイヤ３ルータのことを指すこともある。しかしながら、本明細書においては、後述するレイヤ３以上のプロトコル変換およびポリシ制御を行う機能のうち、一つまたは複数を有するネットワークアプライアンスをゲートウェイと呼ぶことにする。
以上の説明ではゲートウェイを物理的なコンピュータの一種としてきた。より正確には、ゲートウェイは、ネットワークアプライアンスと呼ばれるネットワーク制御用のコンピュータである。例えば図２に示すように、その構成は実質的には他の物理サーバや管理サーバとほぼ同じであり、Ｅｔｈｅｒ ＩＦ５０６の数や、メモリ５０２上のプログラムが異なるのみである。したがって、ゲートウェイは必ずしも物理的なコンピュータとして設置される必要はなく、仮想サーバの一種として実現されてもよい。しかしながら、一部の実装においては、本実施例ではソフトウェアを用いている処理を、同じ処理を実行する専用のハードウェアにより実現してもよい。
以下に、本実施例において物理ゲートウェイおよび仮想ゲートウェイにて提供される代表的な機能の具体例を示す。なお、いずれの機能についてもネットワーク技術分野において一般的な技術、国際標準、およびデファクトスタンダードに準ずるものである。
（１）ルータ／レイヤ３スイッチ
ＯＳＩ参照モデルにおけるネットワーク層における経路制御や、プロトコル変換を行う機能である。実装としては、近隣のルータやホストのＩＰアドレスを宛先表に記憶し、受信した通信パケットの宛先アドレスに応じて、該当する装置へと送信する仕組みをとる。したがって、受信したパケットの宛先情報を参照する処理や、参照した情報に応じて宛先を決定する処理、あるいは定期的に宛先表を更新する処理を行っており、通信データ量や接続されるホスト数の増加に応じて処理負荷が増大する。加えて、異なるデータリンク層（例えばイーサネットとＦＤＤＩ）を接続する機能が合わせて実装されることもあり、ホスト側で行われる処理と比較して処理コストが無視できない機能であるため、専用の装置が用意される場合が多い。
また、可用性を高めるためＶＲＲＰ（Ｖｉｒｔｕａｌ Ｒｏｕｔｅｒ Ｒｅｄｕｎｄａｎｃｙ Ｐｒｏｔｏｃｏｌ）を実装するものもあり、原理的に複数のルータが存在してもよい。なお、ＶＲＲＰに関して“仮想ルータ”という用語が用いられることがあるが、本実施例における仮想ゲートウェイとは別のものを指す。
（２）ネットワークアドレス変換
あるネットワークにおいて、外側と通信するためのアドレスと、内側で通信するためのアドレスを変換する機能であり、一般にＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）と呼ばれる。例えば、ＩＰｖ４のグローバルアドレスは全てのローカルコンピュータに付与できるほどには潤沢に用意されていないという事情から広く用いられている。このとき、ローカルコンピュータ側のアドレスを変更せずに、中継点にあるＮＡＴゲートウェイでアドレスを変換し、インターネット上の機器との透過的な通信を可能とする。ＴＣＰ／ＩＰでは、ローカルアドレスとポート番号の組を用いて通信の一貫性を保証する実装がある。
また、ＮＡＴはＩＰアドレスの変換を行うが、ＩＰアドレスは同一としてＭＡＣアドレスの変換を行う機能（ＭＡＴ、ＭＡＣ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）を有していてもよい。
（３）ファイヤウォール
ゲートウェイを経由する通信のレイヤ３の制御情報（宛先ポート番号）やレイヤ４プロトコルに応じて通過／破棄／拒否を行う機能である。外部ネットワークから内部ネットワークへの不正侵入を防ぎ、セキュリティを高める目的で利用されることが多く、内部ネットワークに接続するホストの用途やユーザの特性に応じて、柔軟に設定できることが重要である。
実装によっては、ＴＣＰ／ＵＤＰのセッション状態を監視して不正な通信パケットを遮断するものもある。
（４）プロキシ
主に内部ネットワークから外部への通信を、アプリケーション層のプロトコル（例えばＨＴＴＰやＦＴＰ）を解釈できるプロキシサーバに代替させ、選択的に通信を行う機能である。セキュリティ強化、負荷分散、キャッシュなどの目的で導入される。指定した相手とは別のサーバが代理で応答するため、通信要求を行うホストとは別のアドレスとなる点においてＮＡＴと異なり透過的でない。
アプリケーション層における制御を提供しているため、例えば特定ＵＲＬの閲覧をリダイレクトするなど高い機能を備えるが、一方で単にポート番号や宛先ＩＰアドレスを監視しているファイヤウォールに比べて処理コストが大きい。
逆方向のもの、すなわち外部ネットワークから内部ネットワークへの通信に対して、特定のサーバを経由するよう制御する機能を、特にリバースプロキシと呼ぶことがあり、本実施例においては本機能に含める。
その他、本実施例に述べるゲートウェイは、ＶＰＮ（仮想プライベートネットワーク）の中継点／終端となるＶＰＮルータや、外部ネットワーク上から遠隔操作可能なユーザインタフェースを提供するリモートコンソールゲートウェイ、特定ポート番号宛の通信セッションを中継するポートフォワーディングなどの機能を想定する。
必要であれば、ネットワーク構成を制御するための機能をさらに備える。例えば、インスタンスに対して動的にＩＰアドレスを設定するために、ＤＨＣＰサーバ機能を有してもよい。
＜テナントネットワークの構成方法＞
これを説明するために、まず一般的なテナントネットワークの構成方法を述べ、次に本発明に特長的な構成方法を述べることとする。
テナントネットワークは、ユーザやユーザグループから構成されるテナントごとに、リソースのセキュリティ、および処理性能を確保するために利用される。現時点におけるネットワーク装置の互換性、およびハイパバイザ製品の仕様を考慮すると、（レイヤ２）ＶＬＡＮおよび（レイヤ３）ルータを利用してプライベートネットワークを構成する方法が最も一般的である。
ネットワーク通信可能な範囲の制御は、レイヤ２、またはレイヤ３ネットワークの設定のみ、さらには他のレイヤでも実現可能であるが、セキュリティを確保しつつユーザの要求に応じて柔軟にプライベートネットワークを構築する方法として、本項に示す方法が広く用いられている。すなわち、セキュリティ強度を高める必要のない内部ネットワークには、レイヤ２の接続性が確保されたネットワークを一つのレイヤ３セグメントとして構成し、アプリケーションと連携した高度なセキュリティ管理が必要な他セグメントとの外部ネットワーク通信にはレイヤ３の経路制御を利用する方法である。この方法によれば、テナントネットワークがレイヤ２透過となり、例えばＤＨＣＰなどブロードキャストを用いた構成管理が利用できる。そこで、本項ではまず、各イーサネットスイッチにおいてレイヤ２ネットワークを構築した後、レイヤ３ネットワークにおける経路設定を行い、一般的なテナントネットワークを構成する方法について述べる。
図７に、テナントネットワークの構成例を示す。同図を用いて、以下レイヤ２ネットワークの構成方法を説明する。
すべての装置、すなわち物理サーバ１０および２０、物理ゲートウェイ５００、イーサスイッチ６０ａおよび６０ｂの構成は、管理コンピュータ２００により管理される。これらの装置について、各物理イーサネットインタフェースが管理ネットワーク３０１に接続され、相互に通信可能である。各物理スイッチ６０ａ、６０ｂおよび仮想マシンホスト２０上のハイパバイザによって実装される仮想スイッチ２７は、ＶＬＡＮに準拠しており、同じＶＬＡＮ ＩＤを付与することによりレイヤ２（データリンク層）の接続性を提供する。
ベアメタルホスト１０および物理ゲートウェイ５００の場合、サービス用の内部ネットワークをポートＶＬＡＮにより構成する。より具体的には、物理スイッチ６０ｂにおいて、当該ベアメタルホストが接続されているポート６２ｂ、６２ｃ、６２ｄにポートＶＬＡＮ属性（アクセスモード）を付与する。これにより、同じＶＬＡＮ ＩＤを持つポート同士のみが通信可能となり、ホスト間が相互に通信するための内部ネットワーク６３ａと、ゲートウェイを経由して外部と通信するための外部ネットワーク６３ｂとを分ける。内部ネットワーク６３ａ、およびゲートウェイ５００の内部ネットワーク側インタフェース５０６ａは、テナントごとに用意され、原則的には当該テナントに所属するユーザおよびリソースのみが利用可能である。言い換えれば、他のテナントに所属する物理インスタンス１４からは、レイヤ２ネットワークのレベルで分離される。
仮想サーバ２４ａおよび２４ｂにより内部ネットワークと外部ネットワークをレイヤ２ネットワークで分割する場合、仮想スイッチ２７および物理スイッチ６０ｂにおいてタグＶＬＡＮを設定する。より具体的には、ハイパバイザが提供する仮想スイッチ２７において、内部ネットワーク６３ａと外部ネットワーク６３ｂに異なるＶＬＡＮ ＩＤを付与する。また、物理スイッチの仮想ホスト側ポート６２ａには、仮想スイッチで設定した前記のＶＬＡＮ ＩＤタグを持つパケットを疎通させるようタグＶＬＡＮ属性（トランクモード、またはタギングモード）を設定する。
特に、従来通り仮想インスタンスのみで運用する場合は、物理スイッチについて、全てのタグＶＬＡＮを疎通させるようトランクモードを設定しておく。これによって、ハイパバイザ上の仮想スイッチ２７の設定のみでプライベートネットワークが作成可能となり、物理スイッチの設定を都度切り替える必要はない。したがって、既存の仮想サーバ環境管理基盤は、物理スイッチの設定機能を持たないのが一般的である。
ＶＬＡＮ ＩＤが同じであればレイヤ２の接続性が確保され、同図７の例では物理インスタンスのイーサインタフェース１６ａ、仮想インスタンスのイーサインタフェース２９がＶＬＡＮ ＩＤ＝１のレイヤ２の内部ネットワーク６３ａで疎通する。このとき、例えばブロードキャストは物理インスタンス１４、仮想インスタンス２４ａ、物理ゲートウェイ５００、および仮想ゲートウェイ２４ｂに到達する。
さらに、従来技術によれば、ゲートウェイを設置し、外部ネットワーク６３ｂとの接続性を確保する。ゲートウェイとの接続はレイヤ３ネットワーク設定において制御される。例えば、各インスタンスにネットワークアドレスを設定する際のデフォルトゲートウェイとして、ゲートウェイが指定可能である。仕様上、一つのインスタンスに設定するデフォルトゲートウェイ（のＩＰアドレス）は一つでなければならない。したがって、一般的なクラウド環境においては、テナントごとに仮想ゲートウェイ２４ｂを作成しておき、外部ネットワークとの全ての通信について、ゲートウェイ２４ｂを経由するよう設定する。また、通常は、ゲートウェイ２４ｂの制御下の同一ＶＬＡＮ ＩＤの空間内でサブネットを作成する。各インスタンスを稼働させるＯＳは、自身のネットワーク設定情報として経路表を有し、経路表にない（ネットワーク上の位置を知らない、近隣のホストでない）アドレス宛の通信を全てデフォルトゲートウェイへ向けて送信する。
クラウド環境における性能安定を求めて物理インスタンスを利用する場合、既存の仮想インスタンス環境とレイヤ２ネットワークにより接続し、既存の仮想ゲートウェイを経由するよう設定すれば所望のテナントネットワークが構築できる。
＜本発明に特徴的なテナントネットワークの構成方法＞
従来技術によるテナントネットワークの構成方法として、仮想ゲートウェイが性能上のボトルネックになることが挙げられる。
前述の通り、物理インスタンスの場合も仮想インスタンスと同じく仮想ゲートウェイを利用する場合、柔軟に構成を変更できることが利点であるものの、仮想ゲートウェイが他の仮想サーバから性能影響を受ける可能性は排除できない。物理インスタンスを利用するユーザは、安定した性能を期待しており、他のワークロード次第でネットワーク性能が変動するゲートウェイを受容することは非常に困難である。
一方で、仮想インスタンスを含む全てのインスタンスについて物理ゲートウェイを指定する方法では、物理インスタンスにおける性能安定を提供できるものの、仮想インスタンスにおいて利用するには非効率的である。仮想インスタンスを利用するユーザは、リソース利用効率を高めたい、あるいはリソース利用量に比例するコストを削減したいと考えている可能性はあっても、その分性能安定は必須ではないと考えており、潤沢な性能を持つ物理ゲートウェイを必要としていない。
複数のゲートウェイを単一のゲートウェイとして構成し、負荷に応じて共通のポリシ設定を適用したゲートウェイの実体を使い分ける従来技術も存在するが、ゲートウェイに負荷監視機能や無停止での経路切り替え機能など、複雑な機能を実装しなければならない上に、あくまでも最善策であり性能を保証するものではないという課題がある。
本実施例によれば、以上の課題を解決するためのテナントネットワークの構成方法が提供される。すなわち、図７に示した構成において、仮想インスタンスは仮想ゲートウェイを、物理インスタンスは物理ゲートウェイを経由するよう、レイヤ３の経路制御を行う方法である。本構成方法の概念図を図８に示す。
図８に示す通り、本実施例では仮想インスタンス２４ａと物理インスタンス１４を相互に内部ネットワーク（ＬＡＮ）３００へ接続し、さらにゲートウェイを介して外部ネットワーク（ＷＡＮ）３０２ａへ接続し、クライアントコンピュータ７０へサービスを提供する。このとき、仮想インスタンス２４ａと物理インスタンス１４の相互通信８０８はレイヤ２で接続された同一サブネット内で行われるが、仮想インスタンス２４ａとの外部通信８０１は仮想ゲートウェイ２４ｂを介して、物理インスタンス１４との外部通信８００は物理ゲートウェイ５００を介して行われる。
それぞれのゲートウェイの設定には、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ８０２を用いる。ＤＨＣＰサアーバ８０２は、いずれかのゲートウェイのＬＡＮ３００側に設置される。
仮想インスタンス２４ａが生成され、ＬＡＮ３００に接続してＩＰアドレス割り当て要求８０３をブロードキャストすると、ＤＨＣＰサーバ８０２は、仮想インスタンス２４ａ用のＩＰアドレスの払い出しとともに仮想ゲートウェイ２４ｂのアドレス（図では１９２．１６８．１１．１）をデフォルトゲートウェイとして応答する。
一方、物理インスタンス１４が生成された際には、同様にＩＰアドレス割り当て要求８０７に対して物理ゲートウェイ５００のアドレス（図では１９２．１６８．１１．２）をデフォルトゲートウェイとして応答する。
本実施例におけるＤＨＣＰサーバ８０２は、図９に示すネットワークアドレス管理テーブル８１５を有する。標準的なＤＨＣＰサーバの実装では、ＤＨＣＰクライアント（本実施例では仮想インスタンスおよび物理インスタンス）をＭＡＣアドレスにより識別し、要求に応じてプール管理されたＩＰアドレスと、サブネットマスク、ＤＮＳサーバ、デフォルトゲートウェイを応答する。図９においても同様に、インスタンス８１５ａに対してＭＡＣアドレス８１５ｄ、割り当てるＩＰアドレス８１５ｅの組を管理している。本実施例においてはさらに、インスタンス種別８１５ｂに応じて、異なるゲートウェイ８１５ｆを指定する。これらの各ネットワーク設定情報は、当該インスタンスのＯＳにて、より正確にはネットワークインタフェース管理領域にて保持される。インスタンス種別８１５ｂとゲートウェイ８１５ｆの選別方法は後述する。
＜処理フロー＞
以下、管理コンピュータの構成と本実施例の処理フローについて説明する。
図１０に管理コンピュータ２００の管理プログラム２０３ｂの詳細な構成を示す。前述の統合サービス管理部２０４ａはさらに、管理クライアント７３ｂから要求を受け付けるユーザ要求管理部２１１、インスタンスの構成情報を管理するインスタンス管理テーブル２１２、インスタンスに導入するＯＳイメージを保持するＯＳイメージライブラリ２１３、システム内の装置群の構成を管理するエレメント管理部２１４、ゲートウェイの構成を管理するゲートウェイ管理部２１７、およびそれらを協調的に作用させるサービスオーケストレータ２１０から構成される。統合サービス管理部２０４ａの下位に位置する各装置管理部（サーバ管理部２０４ｂ、ネットワーク管理部２０４ｃ、ストレージ管理部２０４ｄ）は、主にエレメント管理部２１４のもとで制御される。エレメント管理部には、全ての装置構成を集約したエレメント管理テーブル群２１５、およびネットワークスイッチに設定するＶＬＡＮ ＩＤを集約した総合ＶＬＡＮ ＩＤ管理テーブル２１６を備える。
図１１に、本実施例においてインスタンス作成に伴ってテナントネットワークを構成する処理フローを示す。
ユーザが管理クライアント７３ｂを用いてインスタンス作成要求を発信すると、統合サービス管理部２０４ａのユーザ要求管理部２１１がユーザ権限を認証し、前述のインスタンスを作成する手順が開始される。装置構成は図１２に示すエレメント管理テーブル群２１５において管理されている。エレメント管理テーブル群２１５は、装置管理部から複製された管理テーブル、例えばサーバ装置の構成を管理するサーバ管理テーブル８２０や、物理スイッチ管理テーブル８２１などから構成される。エレメント管理テーブル群２１５を調べることで、装置の使用状況や接続関係などの構成が把握できる。例えば、サーバ管理テーブル８２０のハイパバイザフィールド８２０ｂを調べることで、ハイパバイザが導入済みか否かを判別できる。さらに、エレメント管理テーブル群２１５には、装置を管理コンピュータに登録した際に生成される関連付け情報２１５ａが含まれており、例えばどのサーバ８２０ａのどのインタフェース８２０ｄが、どのスイッチ８２１ａの物理ポート８２１ｃに接続されているか、を知ることができる。インスタンス作成時には、このエレメント管理テーブル群２１５をもとに各装置管理部からリソース空き容量を取得し、作成先装置の決定が行われる。
ステップ９００において、前述のインスタンスを作成する手順を完了すると、ステップ９０１で一旦当該インスタンスをシャットダウンし、テナントネットワークの構成手順に移る。
ステップ９０２において、ユーザの要求に従い、ＶＬＡＮ ＩＤを決定する。本実施例においてテナントとＶＬＡＮ ＩＤの対応付けは、総合ＶＬＡＮ ＩＤ管理テーブル２１６において管理されている。図１３に当該テーブルの詳細を示す。ネットワーク管理部２０４ｃは、物理スイッチＶＬＡＮ ＩＤ管理テーブル２１８、および仮想スイッチＶＬＡＮ ＩＤ管理テーブル２１９の情報を不整合なく集約したものである。第一の実施例に示したように、仮想／物理スイッチについての管理テーブルのみをそれぞれ保持する方法もあるが、総合ＶＬＡＮ ＩＤ管理テーブルのように集約した管理テーブルを別に持つ方法によっても、ＶＬＡＮによる論理ネットワーク分割が適切に構成可能である。物理スイッチの管理情報がネットワーク管理部２０４ｃに保持される一方、仮想スイッチはハイパバイザが実装する一つの機能であり、その管理情報はサーバ管理部２０４ｂに保持される。ユーザが既存のテナントネットワークにインスタンスを追加する要求を実行している場合は、ユーザが指定した当該テナントＩＤ２１６ａのＶＬＡＮ ＩＤ２１６ｂを参照する。ユーザが新規にテナントネットワークの作成を要求している場合は、新たなテナントＩＤ２１６ａとＶＬＡＮ ＩＤ２１６ｂを確保し、総合ＶＬＡＮ ＩＤ管理テーブル２１６に追加する。
ステップ９０３において、ユーザの要求が物理インスタンスであるか、または仮想インスタンスであるかに応じて処理を分岐させる。
ユーザが物理インスタンスの追加を要求している場合、ステップ９０４において物理スイッチのＶＬＡＮ設定を行う。より具体的には、物理スイッチＶＬＡＮ ＩＤ管理テーブル２１８において、当該ＶＬＡＮ ＩＤ２１８ｅが設定可能か否か（他のＩＤと重複しないか、あるいは装置仕様上設定可能な範囲か）を判別し、当該物理サーバ（ホスト）ＩＤ２１８ａに対応するポート属性２１８ｄをアクセスモード（ポートＶＬＡＮ属性）に設定する。さらに、ステップ９０５において、当該インスタンスのゲートウェイを指定するゲートウェイ管理部２１７から、利用可能な物理ゲートウェイ情報を取得する。ここでゲートウェイ管理部２１７は、物理ゲートウェイ５００を指定するために少なくとも当該ゲートウェイの内部ネットワーク側ＩＰアドレスを保持する。物理的な接続関係を構築している適切な物理ゲートウェイが存在しない場合は処理を中止するか、物理インスタンスの作成方法と同様の方法により、新たに物理ゲートウェイを作成する。本実施例においては、さらにＤＨＣＰサーバに対して同物理ゲートウェイの設定を行う。より具体的には、ネットワークアドレス管理テーブル８１５において、作成したインスタンス情報と、その ＭＡＣアドレス８１５ｄ、およびゲートウェイのＩＰアドレスを登録する。
ユーザが仮想インスタンスの追加を要求している場合、ステップ９０６においてまず仮想スイッチのＶＬＡＮ設定を行う。より具体的には、仮想スイッチＶＬＡＮ ＩＤ管理テーブル２１９において、当該ＶＬＡＮ ＩＤ２１９ｂが設定可能か否かを判別し、当該テナントＩＤ２１９ａおよびインスタンスＩＤ２１９ｃに対応させてＶＬＡＮ ＩＤ２１９ｂを設定する。次に、ステップ９０７において、対応する物理スイッチＶＬＡＮ ＩＤ管理テーブル２１８を編集する。より具体的には、物理スイッチＶＬＡＮ ＩＤ管理テーブル２１８において、当該ＶＬＡＮ ＩＤ２１８ｅが設定可能か否かを判別し、当該仮想サーバホストＩＤ２１８ａに対応するポート属性２１８ｄをトランクモード（タグＶＬＡＮ属性）に設定する。さらに、ステップ９０５において、当該インスタンスのゲートウェイを指定するゲートウェイ管理部２１７から、利用可能な仮想ゲートウェイ情報を取得する。ここでゲートウェイ管理部２１７は、仮想ゲートウェイ２４ｂを指定するために少なくとも当該ゲートウェイの内部ネットワーク側ＩＰアドレスを保持する。物理的な接続関係を構築している適切な仮想ゲートウェイを作成しえない場合には処理を中止するか、仮想インスタンスの作成方法と同様の方法により、新たに仮想ゲートウェイを作成する。本実施例においては、さらにＤＨＣＰサーバに対して同仮想ゲートウェイの設定を行う。より具体的には、ネットワークアドレス管理テーブル８１５において、作成したインスタンス情報と、そのＭＡＣアドレス８１５ｄ、およびゲートウェイのＩＰアドレスを登録する。
ステップ９０９においてインスタンスを再起動すると、当該インスタンスはＤＨＣＰサーバからネットワーク設定の割り当てを受けて稼働する。そのネットワーク設定は続くステップ９１０において、例えば同一テナントネットワーク内の他のインスタンスによるＩＣＭＰ受信により、疎通が確認される。
正常にインスタンスの追加が完了すると、ユーザ要求管理部２１１により、ユーザへ当該インスタンスの利用開始が通知される。このとき、インスタンスにアクセスするためのユーザアカウント情報や、ネットワークアドレスを合わせて通知してもよい。
本実施例により、ユーザが要求するサービスレベルに応じて物理インスタンスおよび仮想インスタンスが追加された際に、テナントネットワークが構成される。さらに、性能安定が求められる物理インスタンスは性能安定な物理ゲートウェイを、リソース利用効率の高い仮想インスタンスは高効率な仮想ゲートウェイを利用して稼働する。すなわち、仮想／非仮想サーバ混在により計算処理リソースやストレージリソースの全体最適が実現されるとともに、仮想／物理ゲートウェイの使い分けによりネットワークリソースの全体最適も実現することができる。外部ネットワークとの通信における振り分け比率は、ユーザが要求するインスタンス種別に応じて静的に決定される。したがって、従来技術が提供する、通信負荷を監視して負荷分散方法を変化させる方式のように、適正な負荷分散が実現されるまでに長い時間を要することもなく、また複雑な機能の実装や処理コストも不要である。
以上の説明では、インスタンスを作成する際にテナントネットワークを構成する例を対象としたが、本発明の対象はこれにとどまらない。例えば、新たにテナントネットワークのみを作成する場合や、仮想インスタンスと物理インスタンスを相互に移行する場合にも同様のシステム構成により本機能が実現される。
また、本実施例においてはＶＬＡＮとレイヤ３経路制御により上述のテナントネットワーク構成を実現したが、本発明の構成はこれらの技術に依存するものではない。したがって、例えばＶＸＬＡＮなど、レイヤ２通信をレイヤ３通信によりカプセル化してレイヤ２ＶＬＡＮ空間を延伸する技術を用いる場合においても、同様のシステム構成により本機能が実現される。
第一の実施例では、ＤＨＣＰサーバを用いて仮想および物理ゲートウェイの使い分けを実現した。しかしながら、一般的な環境においては、障害時に備え静的アドレスを利用したいという要件から、ＤＨＣＰサーバを利用しない運用も行われる。ＤＨＣＰによるネットワーク設定によれば、効率的にＩＰアドレスのプール管理を行える一方、アドレスのリース期間が終わるごとにネットワーク設定の更新を行わなければならない。このとき、ＤＨＣＰサーバに障害が発生しただけで、テナント内のインスタンスが通信不能に陥る危険性がある。
静的ＩＰアドレスを利用する場合、管理ネットワークを経由して手動設定する方法があるが、手作業によるアドレス重複や利用状態管理の煩雑化のリスクが伴う。そこで、本実施例では、インスタンスを作成するもととなるマスタＯＳイメージ管理との連携により、ＤＨＣＰに依存しないネットワーク設定方法を提供する。
図１４に示すように、本実施例においては、ＤＨＣＰサーバを利用しない点を除き、第一の実施例と同様のシステム構成を有する。特に、ＯＳイメージライブラリ２１３において仮想／物理インスタンスの種別に応じてカスタマイズされたネットワーク設定を持つという特徴を有する。ＯＳイメージライブラリ２１３に登録されるマスタイメージの実態は、ストレージ装置１００内部に格納される。物理インスタンス１４のマスタイメージ８３０はボリュームであり、物理インスタンス作成時にストレージ制御プログラム１５３ｂのコピー機能により起動用のディスクデバイス８３１が作成される。一方、仮想インスタンスのマスタイメージ８３２は仮想ディスクの形式をとり、ハイパバイザのコピー機能により起動用の仮想ディスク８３３が作成される。
本実施例では、ゲートウェイ管理部２１７において、ネットワークアドレス管理テーブル８１５を持ち、仮想／物理インスタンスの種別により対応するネットワーク設定をマスタイメージに含める。より具体的には、ネットワーク設定をカスタマイズしたＯＳイメージを使ってマスタイメージを作成する、あるいは図１１ステップ９０９においてインスタンスを再起動した際に当該ネットワーク設定が読み込まれるようＯＳ初期化ファイルを構成しておく。
本実施例によれば、作成されるインスタンスに対して静的にＩＰアドレスが付与され、仮想／非仮想サーバの種別に応じて仮想／物理ゲートウェイが静的に設定される。このネットワーク設定を実施するとき、ネットワークを疎通させる必要はなく、またＤＨＣＰサーバを設置する必要も生じない。さらに、ＤＨＣＰサーバなどネットワークアドレスの集中管理を行う装置に障害が生じた場合でも、当該インスタンスとクライアントコンピュータとのの接続性、および同一テナントに接続されたインスタンス間の接続性が保持される。加えて、ストレージ装置１００の高速なコピー機能を活用することで、ネットワークインストールのように通信帯域に負荷をかけることがないという利点を有する。
本実施例によれば、外部ネットワークから内部ネットワークへのアクセスについて、仮想／物理インスタンスを考慮して振り分ける機能が提供される。前述の実施例では、おもに内部ネットワークから外部ネットワークへのアクセスについて、インスタンスの種別に応じたゲートウェイを経由させる方法について述べた。一方で、クライアントコンピュータ７０側からのアクセス要求についても、物理インスタンスと仮想インスタンスの特性に応じてゲートウェイに振り分けたい。
本発明が対象とするような仮想／非仮想混在環境では、ユーザが求める性能要件が、物理インスタンスと仮想インスタンスの数などとして現れる。したがって、予測のできないアクセス要求の変動に対応するために複雑な監視機能と負荷分散機能を実装するよりも、まずテナント内の仮想／物理インスタンスの規模に応じて静的にゲートウェイを指定する方法で、より簡潔かつ効果的な性能改善が実現できると考えられる。
本実施例において、外部ネットワークからのアクセスを物理ゲートウェイおよび仮想ゲートウェイに振り分ける構成を図１５（ａ）および（ｂ）の二通りを考える。
第一の方法は、ＤＮＳを利用する方法である。クライアントコンピュータ７０がＤＮＳサーバ８１０に問い合わせ、アクセス先ドメイン名をＩＰアドレスへ解決する場合を考える。このとき、物理ゲートウェイ（または物理インスタンス）のＩＰアドレスを宛先として通知するか、仮想ゲートウェイ（または仮想インスタンス）のＩＰアドレスを通知するか、の割合をＤＮＳサーバの設定により調整する。より具体的には、仮想および物理ゲートウェイまたはインスタンスの性能比をある一定値で評価し、応答するＩＰアドレスの発生確率とする。
第二の方法はゲートウェイの手前にロードバランサ８１１を配置する方法である。一般的なロードバランサにおける負荷分散アルゴリズムとして、物理ゲートウェイ（または物理インスタンス）を宛先とするか、仮想ゲートウェイ（または仮想インスタンス）を宛先とするか、の割合をゲートウェイまたはインスタンスの性能比と比例させる。プロキシとして動作させるか、またはＮＡＴにより透過的なアクセスを提供する。
本実施例によれば、外部ネットワークからのアクセスを物理ゲートウェイと仮想ゲートウェイとに振り分けられる。外部アクセスの振り分け比率は、ユーザが要求するインスタンス種別に応じて静的に決定される。したがって、従来技術が提供する、通信負荷を監視して負荷分散方法を変化させる方式のように、クライアント要求の適正な負荷分散が実現されるまでに長い時間を要することもなく、また複雑な機能の実装や処理コストも不要である。
１０…第一の物理サーバ、１１…ＣＰＵ、１２…メモリ、１３a…オペレーティングシステム、１３b…アプリケーションプログラム、１４…物理インスタンス、１５…ファイバチャネルインタフェース、１６…イーサネットインタフェース、２０…第二の物理サーバ、２３ｂ…仮想化プログラム、２４ａ…仮想インスタンス、２４ｂ…仮想ゲートウェイ、２７…仮想ネットワークスイッチ、５０…ファイバチャネルスイッチ、 ５１…ストレージエリアネットワーク、６０…物理ネットワークスイッチ、６１…内部イーサネットワーク、７０…クライアントコンピュータ
７３ａ…サービスクライアント、７３ｂ…管理クライアント、１００…ストレージ装置、１５０…ストレージ制御部、１５３ａ…応答プログラム、１５３ｂ…ストレージ制御プログラム、１５４…キャッシュ、２００…管理コンピュータ、２０３ｂ…管理プログラム、２０４ａ…統合サービス管理部、２０４ｂ…サーバ装置管理部
２０４ｃ…ネットワーク装置管理部、２０４ｄ…ストレージ装置管理部、３００…内部ネットワーク、３０１…管理ネットワーク、３０２…外部ネットワーク、５００…物理ゲートウェイ、８０２…ＤＨＣＰサーバ
ネットワーク５１は、一つ以上の物理サーバ１０および２０と、一つ以上のストレージ装置１００を相互に接続するためのものである。これにより、物理サーバ１０、２０がストレージ装置１００と通信し、アプリケーション１３ｂ、２３ｃなどが稼働する際に必要なストレージ資源を利用可能とする。ネットワーク５１上には、一つ以上のファイバチャネルスイッチ（ＦＣ ＳＷ）５０が介在してもよい。ＦＣ ＳＷ５０の構成は、Ｅｔｈｅｒ ＩＦ５６が接続されたネットワーク６１を介して、管理コンピュータ２００により設定される。
ネットワーク通信可能な範囲の制御は、レイヤ２、またはレイヤ３ネットワークの設定のみ、さらには他のレイヤでも実現可能であるが、セキュリティを確保しつつユーザの要求に応じて柔軟にプライベートネットワークを構築する方法として、本項に示す方法が広く用いられている。すなわち、性能が求められる反面、セキュリティ強度を高める必要のない内部ネットワークには、レイヤ２の接続性が確保されたネットワークを一つのレイヤ３セグメントとして構成し、アプリケーションと連携した高度なセキュリティ管理が必要な他セグメントとの外部ネットワーク通信にはレイヤ３の経路制御を利用する方法である。一つのプライベートネットワークには一つのＶＬＡＮＩＤが付与され、別のプライベートネットワークとはレイヤ２のレベルで独立する。異なるプライベートネットワーク間を接続するには、レイヤ３ルータを介してＩＰアドレスを用いた通信が行われる。

Claims (15)

  1. 複数の仮想インスタンスおよび当該仮想インスタンス間のネットワークを制御する仮想スイッチが動作する第1の物理サーバと、
    物理インスタンスが動作する第2の物理サーバと、
    前記第1の物理サーバと前記第2の物理サーバと接続され、当該前記第1の物理サーバおよび前記第2の物理サーバ間のネットワークを制御する物理スイッチと、
    に接続される管理コンピュータであって、
    前記複数の仮想インスタンスのそれぞれについて、当該仮想インスタンスが接続する内部ネットワークとの対応関係を示す仮想スイッチ管理情報と、
    前記物理インスタンスと、当該物理インスタンスが接続する内部ネットワークとの対応関係を示す物理スイッチ管理情報と、
    前記第1の物理サーバと、前記第2の物理サーバと、前記物理スイッチの構成を管理する統合管理部を備え、
    前記統合管理部は、
    前記物理インスタンスと同じ内部ネットワークに接続する第1の仮想インスタンスを作成するための第1のインスタンス作成要求を受信すると、
    前記第1の物理サーバ上に前記第1の仮想インスタンスを作成し、
    前記物理スイッチ管理情報を参照して、前記物理インスタンスが接続する第1の内部ネットワークを特定し、
    前記第１の仮想インスタンスが前記第1の内部ネットワークに接続されるように前記仮想スイッチと前記物理スイッチを設定する
    ことを特徴とする管理コンピュータ。
  2. 請求項１に記載の管理コンピュータであって、
    前記第２の物理サーバは、当該第２の物理サーバの物理リソース論理的に分割して複数の仮想マシンとして管理する仮想化機能を有し、前記仮想スイッチおよび前記複数の仮想インスタンスの各々は前記複数の仮想マシンのいずれかで動作する
    ことを特徴とする管理コンピュータ。
  3. 請求項２に記載の管理コンピュータであって、
    前記統合管理部は、前記複数の仮想インスタンスのうちの第２の仮想インスタンスと同じ内部ネットワークに接続する第１の物理インスタンスを作成するための第２インスタンス作成要求を受信すると、
    前記物理スイッチに接続される第３の物理サーバ上に前記第１の物理インスタンスを作成し、
    前記仮想スイッチ管理情報を参照して、前記第２の仮想インスタンスが接続する第２の内部ネットワークを特定し、
    前記第１の物理インスタンスが前記第２の内部ネットワークに接続されるように前記物理スイッチを設定する
    ことを特徴とする管理コンピュータ。
  4. 請求項２に記載の管理コンピュータであって、
    前記第２の物理サーバは、前記複数の仮想マシンのうちの第１の仮想マシン上で動作し、前記仮想スイッチと前記物理スイッチの制御によって前記第１の内部ネットワークおよび外部ネットワークに接続されている仮想ゲートウェイを有し、
    前記管理コンピュータは、前記物理スイッチの制御によって前記第１の内部ネットワークおよび前記外部ネットワークに接続されている物理ゲートウェイと、さらに接続されており、
    前記第１のインスタンス作成要求に応じて、
    前記第１の仮想インスタンスが前記仮想ゲートウェイを経由して前記第１の内部ネットワークから前記外部ネットワークに接続するように、前記第１の仮想インスタンスを設定することを特徴とする管理コンピュータ。
  5. 請求項４に記載の管理コンピュータであって、
    前記物理インスタンスが前記物理ゲートウェイを経由して前記第１の内部ネットワークから前記第２のネットワークに接続するように、前記物理インスタンスを設定する
    ことを特徴とする管理コンピュータ。
  6. 請求項５に記載の管理コンピュータであって、
    前記物理ゲートウェイのネットワークアドレス情報と、
    前記仮想ゲートウェイのネットワークアドレス情報と、管理し、
    ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバを介して、当該ネットワークアドレス情報を前記物理インスタンス、前記第１の仮想インスタンスに通知することで、前記第１の仮想インスタンスが前記仮想ゲートウェイを経由して前記第１の内部ネットワークから前記外部ネットワークに接続するように、前記第１の仮想インスタンスを設定する
    ことを特徴とする管理コンピュータ。
  7. 請求項５に記載の管理コンピュータであって、
    前記物理ゲートウェイのネットワークアドレス情報と、
    前記仮想ゲートウェイのネットワークアドレス情報と、管理し、
    前記第１の物理サーバおよび前記第２の物理サーバに接続されるストレージ装置と更に接続され、
    前記第１の仮想インスタンスによって読み込まれるＯＳ（Ｏｐｅｒａｔｉｏｎ ｓｙｓｔｅｍ）のマスタイメージとともに前記仮想ゲートウェイのアドレス情報を格納することで、前記第１の仮想インスタンスが前記仮想ゲートウェイを経由して前記第１の内部ネットワークから前記外部ネットワークに接続するように、前記第１の仮想インスタンスを設定する
    ことを特徴とする管理コンピュータ。
  8. 複数の仮想インスタンスおよび当該仮想インスタンス間のネットワークを制御する仮想スイッチが動作する第1の物理サーバと、物理インスタンスが動作する第2の物理サーバと、前記第1の物理サーバと前記第2の物理サーバと接続され、当該前記第1の物理サーバおよび前記第2の物理サーバ間のネットワークを制御する物理スイッチと、
    に接続される管理コンピュータによるネットワーク構成方法であって、
    前記複数の仮想インスタンスのそれぞれについて、当該仮想インスタンスが接続する内部ネットワークとの対応関係を示す仮想スイッチ管理情報を管理し、
    さらに、前記物理インスタンスと、当該物理インスタンスが接続する内部ネットワークとの対応関係を示す物理スイッチ管理情報を管理し、
    前記物理インスタンスと同じ内部ネットワークに接続する第1の仮想インスタンスを作成するための第1のインスタンス作成要求を受信すると、
    前記第1の物理サーバ上に前記第1の仮想インスタンスを作成し、
    前記物理スイッチ管理情報を参照して、前記物理インスタンスが接続する第1の内部ネットワークを特定し、
    前記第１の仮想インスタンスが前記第1の内部ネットワークに接続されるように前記仮想スイッチと前記物理スイッチを設定する
    ことを特徴とするネットワーク構成方法。
  9. 請求項８に記載のネットワーク構成方法であって、
    前記第２の物理サーバは、当該第２の物理サーバの物理リソース論理的に分割して複数の仮想マシンとして管理する仮想化機能を有し、前記仮想スイッチおよび前記複数の仮想インスタンスの各々は前記複数の仮想マシンのいずれかで動作する
    ことを特徴とするネットワーク構成方法。
  10. 請求項９に記載のネットワーク構成方法であって、
    前記複数の仮想インスタンスのうちの第２の仮想インスタンスと同じ内部ネットワークに接続する第１の物理インスタンスを作成するための第２インスタンス作成要求を受信すると、
    前記物理スイッチに接続される第３の物理サーバ上に前記第１の物理インスタンスを作成し、
    前記仮想スイッチ管理情報を参照して、前記第２の仮想インスタンスが接続する第２の内部ネットワークを特定し、
    前記第１の物理インスタンスが前記第２の内部ネットワークに接続されるように前記物理スイッチを設定する
    ことを特徴とするネットワーク構成方法。
  11. 請求項９に記載のネットワーク構成方法であって、
    前記第２の物理サーバは、前記複数の仮想マシンのうちの第１の仮想マシン上で動作し、前記仮想スイッチと前記物理スイッチの制御によって前記第１の内部ネットワークおよび外部ネットワークに接続されている仮想ゲートウェイを有し、
    前記管理コンピュータは、前記物理スイッチの制御によって前記第１の内部ネットワークおよび前記外部ネットワークに接続されている物理ゲートウェイと、さらに接続されており、
    前記第１のインスタンス作成要求に応じて、
    前記第１の仮想インスタンスが前記仮想ゲートウェイを経由して前記第１の内部ネットワークから前記外部ネットワークに接続するように、前記第１の仮想インスタンスを設定することを特徴とするネットワーク構成方法。
  12. 請求項１１に記載のネットワーク構成方法であって、
    前記物理インスタンスが前記物理ゲートウェイを経由して前記第１の内部ネットワークから前記第２のネットワークに接続するように、前記物理インスタンスを設定する
    ことを特徴とするネットワーク構成方法。
  13. 請求項１１に記載の管理コンピュータであって、
    前記物理ゲートウェイのネットワークアドレス情報と、
    前記仮想ゲートウェイのネットワークアドレス情報と、管理し、
    ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバを介して、当該ネットワークアドレス情報を前記物理インスタンス、前記第１の仮想インスタンスに通知することで、前記第１の仮想インスタンスが前記仮想ゲートウェイを経由して前記第１の内部ネットワークから前記外部ネットワークに接続するように、前記第１の仮想インスタンスを設定する
    ことを特徴とするネットワーク構成方法。
  14. 請求項１２に記載のネットワーク構成方法であって、
    前記管理コンピュータは、第１の物理サーバおよび前記第２の物理サーバに接続されるストレージ装置と更に接続され、
    前記物理ゲートウェイのネットワークアドレス情報と、前記仮想ゲートウェイのネットワークアドレス情報と、を管理し、
    前記第１の仮想インスタンスによって読み込まれるＯＳ（Ｏｐｅｒａｔｉｏｎ ｓｙｓｔｅｍ）のマスタイメージとともに前記仮想ゲートウェイのアドレス情報を格納することで、前記第１の仮想インスタンスが前記仮想ゲートウェイを経由して前記第１の内部ネットワークから前記外部ネットワークに接続するように、前記第１の仮想インスタンスを設定する
    ことを特徴とする管理コンピュータ。
  15. 請求項１３に記載のネットワーク構成方法であって、
    前記外部ネットワークに接続されるクライアントが前記物理ゲートウェイもしくは前記仮想ゲートウェイを経由して前記第１の内部ネットワークに接続する前記仮想インスタンスもしくは前記物理インスタンスにアクセスについて、
    前記第１の内部ネットワークに接続する前記物理インスタンスの数と前記仮想インスタンスの数の比率に基づき、前記物理ゲートウェイもしくは前記仮想ゲートウェイのいずれを経由するかを設定する
    ことを特徴とするネットワーク構成方法。
JP2015501211A 2013-02-25 2013-02-25 仮想サーバおよび非仮想サーバ混在環境におけるテナントネットワーク構成の管理方法 Expired - Fee Related JP5953421B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/054655 WO2014128948A1 (ja) 2013-02-25 2013-02-25 仮想サーバおよび非仮想サーバ混在環境におけるテナントネットワーク構成の管理方法

Publications (2)

Publication Number Publication Date
JP5953421B2 JP5953421B2 (ja) 2016-07-20
JPWO2014128948A1 true JPWO2014128948A1 (ja) 2017-02-02

Family

ID=51390771

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015501211A Expired - Fee Related JP5953421B2 (ja) 2013-02-25 2013-02-25 仮想サーバおよび非仮想サーバ混在環境におけるテナントネットワーク構成の管理方法

Country Status (3)

Country Link
US (1) US9575798B2 (ja)
JP (1) JP5953421B2 (ja)
WO (1) WO2014128948A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9444704B2 (en) * 2013-05-20 2016-09-13 Hitachi, Ltd. Method for controlling monitoring items, management computer, and computer system in cloud system where virtual environment and non-virtual environment are mixed

Families Citing this family (135)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6020273B2 (ja) * 2013-03-19 2016-11-02 富士通株式会社 監視装置，情報処理システム，監視方法および監視プログラム
US10454714B2 (en) 2013-07-10 2019-10-22 Nicira, Inc. Method and system of overlay flow control
US9887960B2 (en) 2013-08-14 2018-02-06 Nicira, Inc. Providing services for logical networks
US10614047B1 (en) 2013-09-24 2020-04-07 EMC IP Holding Company LLC Proxy-based backup and restore of hyper-V cluster shared volumes (CSV)
WO2015048921A1 (en) * 2013-10-02 2015-04-09 Telefonaktiebolaget L M Ericsson(Publ) A movable gateway, a dhcp server and respective methods performed thereby for enabling the gateway to move from a first access point to a second access point
US10200239B2 (en) * 2013-12-27 2019-02-05 Red Hat Israel, Ltd. Normalized management network
US9602308B2 (en) * 2014-06-23 2017-03-21 International Business Machines Corporation Servicing packets in a virtual network and a software-defined network (SDN)
US10048974B1 (en) 2014-09-30 2018-08-14 Amazon Technologies, Inc. Message-based computation request scheduling
US9146764B1 (en) 2014-09-30 2015-09-29 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US9715402B2 (en) 2014-09-30 2017-07-25 Amazon Technologies, Inc. Dynamic code deployment and versioning
US9323556B2 (en) 2014-09-30 2016-04-26 Amazon Technologies, Inc. Programmatic event detection and message generation for requests to execute program code
US9830193B1 (en) 2014-09-30 2017-11-28 Amazon Technologies, Inc. Automatic management of low latency computational capacity
US9600312B2 (en) 2014-09-30 2017-03-21 Amazon Technologies, Inc. Threading as a service
US9678773B1 (en) 2014-09-30 2017-06-13 Amazon Technologies, Inc. Low latency computational capacity provisioning
US9537788B2 (en) 2014-12-05 2017-01-03 Amazon Technologies, Inc. Automatic determination of resource sizing
JP6467906B2 (ja) * 2014-12-19 2019-02-13 富士通株式会社 情報処理システム、情報処理方法、情報処理プログラム、及び情報処理装置
JP2016134721A (ja) * 2015-01-19 2016-07-25 富士通株式会社 情報処理システム、情報処理システムの制御方法及び管理装置の制御プログラム
US10341188B2 (en) * 2015-01-27 2019-07-02 Huawei Technologies Co., Ltd. Network virtualization for network infrastructure
US9733967B2 (en) 2015-02-04 2017-08-15 Amazon Technologies, Inc. Security protocols for low latency execution of program code
US9588790B1 (en) 2015-02-04 2017-03-07 Amazon Technologies, Inc. Stateful virtual compute system
WO2016146494A1 (en) * 2015-03-13 2016-09-22 Koninklijke Kpn N.V. Method and control system for controlling provisioning of a service in a network
US9785476B2 (en) 2015-04-08 2017-10-10 Amazon Technologies, Inc. Endpoint management system and virtual compute system
US9930103B2 (en) 2015-04-08 2018-03-27 Amazon Technologies, Inc. Endpoint management system providing an application programming interface proxy service
US10498652B2 (en) 2015-04-13 2019-12-03 Nicira, Inc. Method and system of application-aware routing with crowdsourcing
US10135789B2 (en) 2015-04-13 2018-11-20 Nicira, Inc. Method and system of establishing a virtual private network in a cloud service for branch networking
US10425382B2 (en) 2015-04-13 2019-09-24 Nicira, Inc. Method and system of a cloud-based multipath routing protocol
US10419365B2 (en) * 2015-04-20 2019-09-17 Hillstone Networks Corp. Service insertion in basic virtual network environment
US20170063627A1 (en) * 2015-08-25 2017-03-02 Bluedata Software, Inc. Allocation of virtual clusters in a large-scale processing environment
US9811434B1 (en) 2015-12-16 2017-11-07 Amazon Technologies, Inc. Predictive management of on-demand code execution
US10754701B1 (en) 2015-12-16 2020-08-25 Amazon Technologies, Inc. Executing user-defined code in response to determining that resources expected to be utilized comply with resource restrictions
US10067801B1 (en) 2015-12-21 2018-09-04 Amazon Technologies, Inc. Acquisition and maintenance of compute capacity
US9910713B2 (en) 2015-12-21 2018-03-06 Amazon Technologies, Inc. Code execution request routing
US10491427B2 (en) * 2016-03-10 2019-11-26 Hitachi, Ltd. Computer system, gateway apparatus control method and storage medium
US9990222B2 (en) 2016-03-18 2018-06-05 Airwatch Llc Enforcing compliance rules against hypervisor and virtual machine using host management component
US10411362B2 (en) * 2016-03-29 2019-09-10 Space Systems/Loral, Llc Synchronization for satellite system
US10891145B2 (en) 2016-03-30 2021-01-12 Amazon Technologies, Inc. Processing pre-existing data sets at an on demand code execution environment
US11132213B1 (en) 2016-03-30 2021-09-28 Amazon Technologies, Inc. Dependency-based process of pre-existing data sets at an on demand code execution environment
US10841273B2 (en) * 2016-04-29 2020-11-17 Nicira, Inc. Implementing logical DHCP servers in logical networks
US10282229B2 (en) 2016-06-28 2019-05-07 Amazon Technologies, Inc. Asynchronous task management in an on-demand network code execution environment
US10102040B2 (en) 2016-06-29 2018-10-16 Amazon Technologies, Inc Adjusting variable limit on concurrent code executions
US10277708B2 (en) 2016-06-30 2019-04-30 Amazon Technologies, Inc. On-demand network code execution with cross-account aliases
US10061613B1 (en) 2016-09-23 2018-08-28 Amazon Technologies, Inc. Idempotent task execution in on-demand network code execution systems
US10884787B1 (en) 2016-09-23 2021-01-05 Amazon Technologies, Inc. Execution guarantees in an on-demand network code execution system
US11119813B1 (en) 2016-09-30 2021-09-14 Amazon Technologies, Inc. Mapreduce implementation using an on-demand network code execution system
US10348813B2 (en) * 2016-10-28 2019-07-09 International Business Machines Corporation Provisioning a bare-metal server
US20200036624A1 (en) * 2017-01-31 2020-01-30 The Mode Group High performance software-defined core network
US10992568B2 (en) 2017-01-31 2021-04-27 Vmware, Inc. High performance software-defined core network
US11706127B2 (en) 2017-01-31 2023-07-18 Vmware, Inc. High performance software-defined core network
US20180219765A1 (en) 2017-01-31 2018-08-02 Waltz Networks Method and Apparatus for Network Traffic Control Optimization
US10778528B2 (en) 2017-02-11 2020-09-15 Nicira, Inc. Method and system of connecting to a multipath hub in a cluster
CN110447208B (zh) * 2017-03-19 2020-12-08 华为技术有限公司 一种网络切片的管理方法、单元和系统
US10523539B2 (en) 2017-06-22 2019-12-31 Nicira, Inc. Method and system of resiliency in cloud-delivered SD-WAN
JP2019029946A (ja) * 2017-08-03 2019-02-21 富士通株式会社 通信制御装置、通信制御システム、及び通信制御方法
US10999100B2 (en) 2017-10-02 2021-05-04 Vmware, Inc. Identifying multiple nodes in a virtual network defined over a set of public clouds to connect to an external SAAS provider
US10666460B2 (en) 2017-10-02 2020-05-26 Vmware, Inc. Measurement based routing through multiple public clouds
US11115480B2 (en) 2017-10-02 2021-09-07 Vmware, Inc. Layer four optimization for a virtual network defined over public cloud
US11223514B2 (en) 2017-11-09 2022-01-11 Nicira, Inc. Method and system of a dynamic high-availability mode based on current wide area network connectivity
US10564946B1 (en) 2017-12-13 2020-02-18 Amazon Technologies, Inc. Dependency handling in an on-demand network code execution system
US10831898B1 (en) 2018-02-05 2020-11-10 Amazon Technologies, Inc. Detecting privilege escalations in code including cross-service calls
US10353678B1 (en) 2018-02-05 2019-07-16 Amazon Technologies, Inc. Detecting code characteristic alterations due to cross-service calls
US10733085B1 (en) 2018-02-05 2020-08-04 Amazon Technologies, Inc. Detecting impedance mismatches due to cross-service calls
US10725752B1 (en) 2018-02-13 2020-07-28 Amazon Technologies, Inc. Dependency handling in an on-demand network code execution system
US10776091B1 (en) 2018-02-26 2020-09-15 Amazon Technologies, Inc. Logging endpoint in an on-demand code execution system
US10853115B2 (en) 2018-06-25 2020-12-01 Amazon Technologies, Inc. Execution of auxiliary functions in an on-demand network code execution system
US10649749B1 (en) 2018-06-26 2020-05-12 Amazon Technologies, Inc. Cross-environment application of tracing information for improved code execution
US11146569B1 (en) 2018-06-28 2021-10-12 Amazon Technologies, Inc. Escalation-resistant secure network services using request-scoped authentication information
US10949237B2 (en) 2018-06-29 2021-03-16 Amazon Technologies, Inc. Operating system customization in an on-demand network code execution system
US11099870B1 (en) 2018-07-25 2021-08-24 Amazon Technologies, Inc. Reducing execution times in an on-demand network code execution system using saved machine states
US11099917B2 (en) 2018-09-27 2021-08-24 Amazon Technologies, Inc. Efficient state maintenance for execution environments in an on-demand code execution system
US11243953B2 (en) 2018-09-27 2022-02-08 Amazon Technologies, Inc. Mapreduce implementation in an on-demand network code execution system and stream data processing system
US20200106669A1 (en) * 2018-09-27 2020-04-02 Nutanix, Inc. Computing node clusters supporting network segmentation
CN113542128B (zh) * 2018-10-12 2023-03-31 华为技术有限公司 一种发送路由信息的方法和装置
US11943093B1 (en) 2018-11-20 2024-03-26 Amazon Technologies, Inc. Network connection recovery after virtual machine transition in an on-demand network code execution system
US10884812B2 (en) 2018-12-13 2021-01-05 Amazon Technologies, Inc. Performance-based hardware emulation in an on-demand network code execution system
US10958720B2 (en) 2018-12-18 2021-03-23 Storage Engine, Inc. Methods, apparatuses and systems for cloud based disaster recovery
US10983886B2 (en) 2018-12-18 2021-04-20 Storage Engine, Inc. Methods, apparatuses and systems for cloud-based disaster recovery
US11489730B2 (en) 2018-12-18 2022-11-01 Storage Engine, Inc. Methods, apparatuses and systems for configuring a network environment for a server
US11252019B2 (en) 2018-12-18 2022-02-15 Storage Engine, Inc. Methods, apparatuses and systems for cloud-based disaster recovery
US11176002B2 (en) 2018-12-18 2021-11-16 Storage Engine, Inc. Methods, apparatuses and systems for cloud-based disaster recovery
US10887382B2 (en) 2018-12-18 2021-01-05 Storage Engine, Inc. Methods, apparatuses and systems for cloud-based disaster recovery
US11178221B2 (en) 2018-12-18 2021-11-16 Storage Engine, Inc. Methods, apparatuses and systems for cloud-based disaster recovery
US11240160B2 (en) * 2018-12-28 2022-02-01 Alibaba Group Holding Limited Method, apparatus, and computer-readable storage medium for network control
US11010188B1 (en) 2019-02-05 2021-05-18 Amazon Technologies, Inc. Simulated data object storage using on-demand computation of data objects
WO2020180761A1 (en) * 2019-03-04 2020-09-10 Airgap Networks Inc. Systems and methods of creating network singularities
US11861386B1 (en) 2019-03-22 2024-01-02 Amazon Technologies, Inc. Application gateways in an on-demand network code execution system
US11216297B2 (en) * 2019-04-29 2022-01-04 Hewlett Packard Enterprise Development Lp Associating virtual network interfaces with a virtual machine during provisioning in a cloud system
US11119809B1 (en) 2019-06-20 2021-09-14 Amazon Technologies, Inc. Virtualization-based transaction handling in an on-demand network code execution system
US11190508B2 (en) * 2019-06-27 2021-11-30 Vmware, Inc. Location-aware service request handling
US11115404B2 (en) 2019-06-28 2021-09-07 Amazon Technologies, Inc. Facilitating service connections in serverless code executions
US11190609B2 (en) 2019-06-28 2021-11-30 Amazon Technologies, Inc. Connection pooling for scalable network services
US11159528B2 (en) 2019-06-28 2021-10-26 Amazon Technologies, Inc. Authentication to network-services using hosted authentication information
US11057348B2 (en) 2019-08-22 2021-07-06 Saudi Arabian Oil Company Method for data center network segmentation
US11252105B2 (en) 2019-08-27 2022-02-15 Vmware, Inc. Identifying different SaaS optimal egress nodes for virtual networks of different entities
US10996961B2 (en) 2019-09-27 2021-05-04 Amazon Technologies, Inc. On-demand indexing of data in input path of object storage service
US11550944B2 (en) 2019-09-27 2023-01-10 Amazon Technologies, Inc. Code execution environment customization system for object storage service
US11263220B2 (en) 2019-09-27 2022-03-01 Amazon Technologies, Inc. On-demand execution of object transformation code in output path of object storage service
US11106477B2 (en) 2019-09-27 2021-08-31 Amazon Technologies, Inc. Execution of owner-specified code during input/output path to object storage service
US11360948B2 (en) 2019-09-27 2022-06-14 Amazon Technologies, Inc. Inserting owner-specified data processing pipelines into input/output path of object storage service
US10908927B1 (en) 2019-09-27 2021-02-02 Amazon Technologies, Inc. On-demand execution of object filter code in output path of object storage service
US11023416B2 (en) 2019-09-27 2021-06-01 Amazon Technologies, Inc. Data access control system for object storage service based on owner-defined code
US11416628B2 (en) 2019-09-27 2022-08-16 Amazon Technologies, Inc. User-specific data manipulation system for object storage service based on user-submitted code
US11055112B2 (en) 2019-09-27 2021-07-06 Amazon Technologies, Inc. Inserting executions of owner-specified code into input/output path of object storage service
US11023311B2 (en) 2019-09-27 2021-06-01 Amazon Technologies, Inc. On-demand code execution in input path of data uploaded to storage service in multiple data portions
US11394761B1 (en) 2019-09-27 2022-07-19 Amazon Technologies, Inc. Execution of user-submitted code on a stream of data
US11656892B1 (en) 2019-09-27 2023-05-23 Amazon Technologies, Inc. Sequential execution of user-submitted code and native functions
US11386230B2 (en) 2019-09-27 2022-07-12 Amazon Technologies, Inc. On-demand code obfuscation of data in input path of object storage service
US11250007B1 (en) 2019-09-27 2022-02-15 Amazon Technologies, Inc. On-demand execution of object combination code in output path of object storage service
US11044190B2 (en) 2019-10-28 2021-06-22 Vmware, Inc. Managing forwarding elements at edge nodes connected to a virtual network
US11119826B2 (en) 2019-11-27 2021-09-14 Amazon Technologies, Inc. Serverless call distribution to implement spillover while avoiding cold starts
US10942795B1 (en) 2019-11-27 2021-03-09 Amazon Technologies, Inc. Serverless call distribution to utilize reserved capacity without inhibiting scaling
US11394640B2 (en) 2019-12-12 2022-07-19 Vmware, Inc. Collecting and analyzing data regarding flows associated with DPI parameters
US11489783B2 (en) 2019-12-12 2022-11-01 Vmware, Inc. Performing deep packet inspection in a software defined wide area network
US11722925B2 (en) 2020-01-24 2023-08-08 Vmware, Inc. Performing service class aware load balancing to distribute packets of a flow among multiple network links
US11714682B1 (en) 2020-03-03 2023-08-01 Amazon Technologies, Inc. Reclaiming computing resources in an on-demand code execution system
US11188391B1 (en) 2020-03-11 2021-11-30 Amazon Technologies, Inc. Allocating resources to on-demand code executions under scarcity conditions
US11775640B1 (en) 2020-03-30 2023-10-03 Amazon Technologies, Inc. Resource utilization-based malicious task detection in an on-demand code execution system
US11245641B2 (en) 2020-07-02 2022-02-08 Vmware, Inc. Methods and apparatus for application aware hub clustering techniques for a hyper scale SD-WAN
US11709710B2 (en) 2020-07-30 2023-07-25 Vmware, Inc. Memory allocator for I/O operations
CN111901177B (zh) * 2020-08-06 2022-08-30 鹏城实验室 一种裸金属服务器网络配置方法、系统及相关设备
US11575591B2 (en) 2020-11-17 2023-02-07 Vmware, Inc. Autonomous distributed forwarding plane traceability based anomaly detection in application traffic for hyper-scale SD-WAN
US11575600B2 (en) 2020-11-24 2023-02-07 Vmware, Inc. Tunnel-less SD-WAN
US11550713B1 (en) 2020-11-25 2023-01-10 Amazon Technologies, Inc. Garbage collection in distributed systems using life cycled storage roots
US11593270B1 (en) 2020-11-25 2023-02-28 Amazon Technologies, Inc. Fast distributed caching using erasure coded object parts
CN112653608B (zh) * 2020-12-14 2023-01-20 聚好看科技股份有限公司 一种显示设备、移动终端及跨网数据传输的方法
US11929903B2 (en) 2020-12-29 2024-03-12 VMware LLC Emulating packet flows to assess network links for SD-WAN
CN116783874A (zh) 2021-01-18 2023-09-19 Vm维尔股份有限公司 网络感知的负载平衡
US11979325B2 (en) 2021-01-28 2024-05-07 VMware LLC Dynamic SD-WAN hub cluster scaling with machine learning
US11388086B1 (en) 2021-05-03 2022-07-12 Vmware, Inc. On demand routing mesh for dynamically adjusting SD-WAN edge forwarding node roles to facilitate routing through an SD-WAN
US11729065B2 (en) 2021-05-06 2023-08-15 Vmware, Inc. Methods for application defined virtual network service among multiple transport in SD-WAN
US11489720B1 (en) 2021-06-18 2022-11-01 Vmware, Inc. Method and apparatus to evaluate resource elements and public clouds for deploying tenant deployable elements based on harvested performance metrics
US11388210B1 (en) 2021-06-30 2022-07-12 Amazon Technologies, Inc. Streaming analytics using a serverless compute system
US11375005B1 (en) 2021-07-24 2022-06-28 Vmware, Inc. High availability solutions for a secure access service edge application
US11880791B2 (en) * 2021-08-27 2024-01-23 Oracle International Corporation Attachment and detachment of compute instances owned by different tenancies
US11943146B2 (en) 2021-10-01 2024-03-26 VMware LLC Traffic prioritization in SD-WAN
US11909815B2 (en) 2022-06-06 2024-02-20 VMware LLC Routing based on geolocation costs

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003023444A (ja) 2001-07-06 2003-01-24 Fujitsu Ltd 仮想ルータを利用した動的な負荷分散システム
US20050198303A1 (en) * 2004-01-02 2005-09-08 Robert Knauerhase Dynamic virtual machine service provider allocation
GB2459433B (en) * 2008-03-07 2012-06-06 Hewlett Packard Development Co Distributed network connection policy management
JP5164628B2 (ja) * 2008-03-24 2013-03-21 株式会社日立製作所 ネットワークスイッチ装置、サーバシステム及びサーバシステムにおけるサーバ移送方法
CN102334112B (zh) * 2009-02-27 2014-06-11 美国博通公司 用于虚拟机网络的方法和系统
JP4780237B2 (ja) * 2010-04-26 2011-09-28 株式会社日立製作所 障害回復方法
US8407366B2 (en) * 2010-05-14 2013-03-26 Microsoft Corporation Interconnecting members of a virtual network
JP2012182605A (ja) 2011-03-01 2012-09-20 Hitachi Ltd ネットワーク制御システム及び管理サーバ
EP2568672A1 (en) * 2011-08-24 2013-03-13 Alcatel Lucent Method for managing network resources within a plurality of datacenters

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9444704B2 (en) * 2013-05-20 2016-09-13 Hitachi, Ltd. Method for controlling monitoring items, management computer, and computer system in cloud system where virtual environment and non-virtual environment are mixed

Also Published As

Publication number Publication date
JP5953421B2 (ja) 2016-07-20
US20150363221A1 (en) 2015-12-17
US9575798B2 (en) 2017-02-21
WO2014128948A1 (ja) 2014-08-28

Similar Documents

Publication Publication Date Title
JP5953421B2 (ja) 仮想サーバおよび非仮想サーバ混在環境におけるテナントネットワーク構成の管理方法
US11438194B2 (en) Scalable tenant networks
US11218420B2 (en) Virtual network interface objects
US10680946B2 (en) Adding multi-tenant awareness to a network packet processing device on a software defined network (SDN)
US10412157B2 (en) Adaptive load balancing
US8331362B2 (en) Methods and apparatus for distributed dynamic network provisioning
US8565118B2 (en) Methods and apparatus for distributed dynamic network provisioning
US9614748B1 (en) Multitenant data center providing virtual computing services
EP3782333A1 (en) Cross-regional virtual network peering
WO2021173318A1 (en) Vrf segregation for shared services in multi-fabric cloud networks
Qutait Using Software defined Network and virtualization to implement NAT and backup functionality and resulting business benefits of implementation in ISPs
Shen et al. S-fabric: towards scalable and incremental SDN deployment in data centers
KR20230055836A (ko) 베어메탈 서비스 시스템

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160418

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160517

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160613

R151 Written notification of patent or utility model registration

Ref document number: 5953421

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

LAPS Cancellation because of no payment of annual fees