(57)【要約】  オーケストレーション・ソリューションを使用してプロビジョニングされるサーバインスタンス（ＳＩ）に対し、ＩＰリソースをコミッションする／デコミッションするためのサーバコンピュータ（ＩＰＣＤＳ）。サーバコンピュータおよびクライアントコンピュータが、クライアント−サーバ・アーキテクチャを構成する。サーバコンピュータは、処理システムと、アプリケーションおよびデータのためのメモリとを含み、メモリは、以下の特徴を実装するように処理システムに命令するプログラムコードを含む：サーバコンピュータによって管理されるデータ（ＤＢ）へのアクセスを提供する、リモート管理のためのユーザインターフェース（ＵＩ）；サービス指向アーキテクチャ［ＳＯＡ］をサポートするウェブベースのアプリケーション・プログラミング・インターフェース（ＡＰＩ）；ＡＰＩを介した呼に基づいて、クライアント（ＣＬ）へのＩＰリソースを指定し、解除するためのロジック。ロジックは、オーバーラップするアドレス空間を有するネットワークのノードであるサーバインスタンス（ＳＩ）のための一意のＩＰリソースを作成する。一意のＩＰリソースは、それぞれのサーバインスタンスのプライベートネットワークの名前、およびそのプライベートネットワーク内のＩＰアドレスに基づく。
2015525543.tif 000002
【特許請求の範囲】
【請求項１】
オーケストレーション・ソリューションを使用してプロビジョニングされる複数のサーバインスタンスに対し、インターネットプロトコル［ＩＰ］リソースをコミッションする／デコミッションするためのサーバコンピュータ（ＩＰＣＤＳ、３−１００）であって、前記サーバコンピュータおよびいくつかのクライアントの各々が、クライアント−サーバ・アーキテクチャを構成し、前記サーバコンピュータが、
少なくとも１つの処理ユニット（ＣＰ１…ＣＰｎ）を含む処理システム（３−１１０）と、
アプリケーションおよびデータを記憶するためのメモリ（ＭＥＭ、３−１５０）と
を含み、
前記メモリが、以下の特徴である、
前記サーバコンピュータのリモート管理のためのユーザインターフェース（ＵＩ）であって、前記サーバコンピュータによって管理されるデータ（ＤＢ）へのアクセスを提供するように構成された、ユーザインターフェース（ＵＩ）と、
サービス指向アーキテクチャ［ＳＯＡ］をサポートすることが可能な、ウェブベースのアプリケーション・プログラミング・インターフェース（ＡＰＩ）と、
前記アプリケーション・プログラミング・インターフェースを介してそれぞれのクライアント（ＣＬ）から受信された１つまたは複数の呼(calls)に基づいて、いくつかのクライアントの各々へのＩＰリソースを動的に指定し(assign)、解除する(release)ように構成された第１のロジックと
を実装する(implement)ように、前記処理システム（３−１１０）に命令するためのプログラムコード命令（３−１６０）を含み、
前記第１のロジックが、２つ以上のサーバインスタンス（ＳＩ）のうちの各々のために少なくとも１つの一意のＩＰリソースを作成するためのプログラムコード命令を含み、前記２つ以上のサーバインスタンスが、オーバーラップするアドレス空間を有するネットワークのノードであり、
前記少なくとも１つの一意の(unique)ＩＰリソースが、前記２つ以上のサーバインスタンスのうちのそれぞれの１つのプライベートネットワークの名前と、そのプライベートネットワーク内のＩＰアドレスとの組合せに基づく、
サーバコンピュータ（ＩＰＣＤＳ、３−１００）。
【請求項２】
前記少なくとも１つの一意のＩＰリソースが、前記２つ以上のコンピュータのうちの前記それぞれ１つの前記プライベートネットワークの名前と、そのプライベートネットワーク内のＩＰアドレスとの組合せに基づく、請求項１に記載のサーバコンピュータ。
【請求項３】
個々のネットワークを、所与の内部および／または外部エンドユーザに関連付けるように構成された第２のロジックであって、ネットワークの１つまたは複数のリソースが完全に割り当てられている場合に、前記内部および／または外部エンドユーザに関連付けられた代替(alternate)ネットワークから、ならびに／あるいは、ＩＰリソースの予備(reserve)プールから、ＩＰリソースを自動的にプロビジョニングする(provision)ように構成された、第２のロジック
をさらに含む請求項１または２に記載のサーバコンピュータ。
【請求項４】
前記処理システムが、複数の処理ユニットと、前記複数の処理ユニットの中で処理負荷を分配するための負荷バランスユニットとを含む、請求項１、２、または３に記載のサーバコンピュータ。
【請求項５】
少なくとも１つの処理ユニットと、
アプリケーションおよびデータを記憶するためのメモリと、
を含む、インターネットプロトコル［ＩＰ］リソースをコミッションする／デコミッションすることを要求するためのクライアントコンピュータであって、
前記メモリが、以下のタスクである、
新しい仮想マシンが、オーケストレーション(orchestration)・ソリューションによってクラウドコンピューティング環境にコミッションされる(commissioned)とき、ＩＰリソースを、ＩＰコミッショニング／デコミッショニングサーバに要求すること、および
デコミッションされた仮想マシンに応答して、前記仮想マシンに指定されたＩＰリソースの解除(release)をトリガすること
を実施するように構成されたクライアントロジックを実装するように、前記少なくとも１つの処理ユニットに命令するためのプログラムコード命令
を含む、
クライアントコンピュータ。
【請求項６】
オーケストレーション・ソリューションを使用してプロビジョニングされる複数のクライアントに対し、インターネットプロトコル［ＩＰ］リソースをコミッションする／デコミッションするための、サーバコンピュータを動作させるための方法であって、前記サーバコンピュータおよび前記クライアントの各々が、クライアント−サーバ・アーキテクチャを構成し、前記方法が、
前記サーバコンピュータに、サービス指向(service oriented)アーキテクチャ［ＳＯＡ］をサポートすることが可能なアプリケーション・プログラミング・インターフェース［ＡＰＩ］を提供するステップと、
前記サーバコンピュータによって管理されるデータへのアクセスを提供するために、リモートインターフェースを構成するステップと、
前記リモートユーザインターフェースを介して前記サーバコンピュータをリモートで管理するステップと、
前記アプリケーション・プログラミング・インターフェースを介してそれぞれのクライアントから受信された１つまたは複数の呼に基づいて、いくつかのクライアントの各々へのＩＰリソースを動的に指定し、解除するステップと、
２つ以上のサーバインスタンスの各々のために少なくとも１つの一意のＩＰリソースを作成するステップであって、前記２つ以上のサーバインスタンスが、オーバーラップするアドレス空間を有するネットワークのノードである、作成するステップと
を含み、
前記少なくとも１つの一意のＩＰリソースが、前記２つ以上のサーバインスタンスのうちのそれぞれの１つのプライベートネットワークの名前と、そのプライベートネットワーク内のＩＰアドレスとの組合せに基づく、
方法。
【請求項７】
インターネットプロトコル［ＩＰ］リソースをコミッションする／デコミッションすることを要求するためのクライアントコンピュータを動作させる方法であって、
新しい仮想マシンが、オーケストレーション・ソリューションによってクラウドコンピューティング環境にコミッションされるとき、ＩＰコミッショニング／デコミッショニングサーバにＩＰリソースを要求するステップと、
デコミッションされた仮想マシンに応答して、前記仮想マシンに指定されたＩＰリソースの解除をトリガするステップと
を含む方法。
【請求項８】
プログラムコード命令を含む有形のプログラムキャリアであって、前記プログラムコード命令が、請求項１に記載のサーバコンピュータ上で実行されるとき、前記サーバコンピュータに請求項６の方法を遂行させる、有形のプログラムキャリア。
【請求項９】
プログラムコード命令を含む有形のプログラムキャリアであって、前記プログラムコード命令が、請求項５に記載のクライアントコンピュータ上で実行されるとき、前記クライアントコンピュータに請求項７の方法を遂行させる、有形のプログラムキャリア。
【発明の詳細な説明】
【技術分野】
【０００１】
親事例の情報
[0001]本出願は、２０１２年６月２０日に出願されたフィンランド特許出願第２０１２５６８０号からの優先権を主張するものである。
【０００２】
[0002]本発明は、クラウドコンピューティング環境における、ＩＰリソースのコミッショニングおよびデコミッショニングに関する。
【背景技術】
【０００３】
[0003]長い間知られてきたように、インターネットプロトコルｖ．４（ＩＰｖ４）は、利用可能なアドレス空間の点でかなり限定される。この問題に対処するために、標準ＲＦＣ１９１８は、プライベート使用向けの３つのネットワーク、すなわち、１０．０．０．０（クラスＡ）、１７２．１６．０．０（クラスＢ）、および１９２．１６８．０．０（クラスＣ）を定義している。これらのプライベートネットワークのいずれも、パブリックインターネットにはルーティングされていない。大会社およびサービスプロバイダは、一般に、自社に利用可能なアドレス空間を拡大するためにクラスＡネットワーク（１０．０．０．０）アドレス空間を有し、一方、ホームおよび小事業所で通常使用されるＡＤＳＬモデムおよびケーブルモデムは、プライベート１９２．１６８ネットワークからのＩＰアドレスを配布する。外界への接続は、ネットワークアドレス変換（ＮＡＴ）技術を利用することによって提供され、そこでは、パブリックネットワークとプライベートネットワークとの間に配置されたＮＡＴデバイスが、ブリッジとして働く。いくつかのプライベートネットワークが同じ１０．０．０．０アドレス空間を共有するので、それらのネットワークはオーバーラップする。これらのプライベートネットワークが、パブリックインターネットにルーティングされるのでなく、内部的に稼働している限り、オーバーラップは取るに足らない問題であった。
【０００４】
[0004]プライベートネットワークのオーバーラップは、クラウドコンピューティングとの、またはクラウドベースのサービスとの関連において問題となる。たとえば、ＩａａＳ（サービスとしてのインフラストラクチャ）サービスプロバイダは、いくつかのビジネスクライアントに同時にサービスを差し出すために使用される、マルチテナントコンピューティング環境をますます配備しており、特に仮想プライベートクラウドおよび／または他の同様の技術のコンテキストでは、それらのビジネスクライアントの全部が、同じ１０．０．０．０アドレス空間を使用することがある。このような使用事例では、異なるテナントによって使用されるプライベートネットワークが、一般にオーバーラップする。
【０００５】
[0005]以下の説明において、「オーケストレーション（ｏｒｃｈｅｓｔｒａｔｉｏｎ）」とは、データ処理と通信システムとの間で自動化されたワークフローを論じるときに、サービス指向アーキテクチャ（「ＳＯＡ」）領域内のその確立された意義において使用される。企業およびサービスプロバイダは、オーケストレーション・ソリューションを使用して、ビジネス要求を、アプリケーション、データ、およびインフラストラクチャと連携させる。前記ソリューションは、一般に、自動化されたワークフロー、プロビジョニング、および変更管理を通して、ポリシーおよびサービスレベルを定義するために使用される。この技術を用いて、組織は、各アプリケーションのニーズに基づいて、拡大、縮小、または横に変倍可能な、アプリケーションを連携させたインフラストラクチャを作成することができる。オーケストレーションはまた、消費についての課金、計測、およびチャージバックを含む、リソースプールの集中型管理を提供する。
【０００６】
[0006]オーケストレートされた環境でアプリケーションを実行するさまざまなサーバへのＩＰアドレス、名前、および他のネットワークパラメータの割り当ては、通常ワークロードと呼ばれ、これは、従来、前記サーバにおいてＩＰアドレスを構成することによって、ならびにサーバ名を対応するＩＰアドレスと共にドメイン名サーバ（ＤＮＳ）に手動で追加することによって、または動的ホスト構成プロトコル（ＤＨＣＰ）および動的ＤＮＳを使用してそのような割り当てを動的に実施させることによって、実現されてきた。従来のオーケストレートされたコンピューティング環境で稼働する物理サーバのＩＰアドレスおよび名前は、比較的静的であったため、それらのＳＯＡベースの自動化されたワークフロー管理プロセスは、ＩＰおよび名前のコミッショニング機構と統合されるようには拡張されていない。既存のオーケストレーション・ソリューションがクラウドベースのコンピューティング環境に拡大されるとき、上で説明されたＩＰアドレスおよび名前を管理するために使用される従来の方法は、さまざまな問題を生むことになる。たとえば、クラウドベースのコンピューティングパラダイムは、新しい仮想マシンがオンデマンドでプロビジョニングされることを必要とするので、従来のオーケストレートされたコンピューティング環境においてＩＰリソースおよび名前を割り当てるために使用される、先行技術方法に関連付けられた手動のＩＰおよび名前の指定プロセスは、クラウドベースのコンピューティング環境全体のスケーラビリティが関係する限り、急速にボトルネックとなる。加えて、クラウドベースのオンデマンド・コンピューティングパラダイムは、仮想サーバインスタンスのライフサイクルが数分から数年までのどこかであり得ることを要求するが、ＤＨＣＰサーバは、自動的に指定されたＩＰアドレスについて既定され、固定されたリース時間を提供し、それにより、ＩＰリース時間を仮想コンピューティング環境の動的性質と連携させることを不可能にする。さらに、先行技術技法は、ＤＨＣＰを用いてさえ、デコミッショニングが、発行されたＩＰアドレスの既定のリース時間に縛られるので、仮想マシンがデコミッションされるときに、ＩＰアドレスを自動的に再請求することを不可能にする。先行技術方法はこうして、ＩＰアドレスのリース時間を、クラウド内で稼働する各仮想マシンの固有のライフサイクルと連携させることを不可能にする。
【０００７】
[0007]ＤＨＣＰの限界は、クラウドコンピューティングと関連して使用してみることによって、急速に明らかにされる。ＤＨＣＰとクラウドコンピューティングとの間の乏しい互換性の理由の１つは、ＤＨＣＰが、クラウドコンピューティング用に、またはウェブベースの統合モデル用に、まったく設計されなかったことである。たとえば、ＤＨＣＰは、ＯＳＩレイヤ２（Ｌ２）で動作する。実際には、クライアントは、ブロードキャストメッセージをローカルエリアネットワーク（ＬＡＮ）に送信する。ＤＨＣＰサーバは、ＬＡＮがブロードキャストメッセージをキャプチャするということなので、ネットワークインターフェースアダプタの一意のアドレスである、クライアントのメディアアクセス制御（ＭＡＣ）アドレスを調べ、ＩＰアドレスを他のネットワークパラメータと共にＭＡＣアドレスに返す。その後、クライアントは、それ自身についてのネットワークパラメータを構成し、より高いＯＳＩレイヤで動作するＴＣＰ／ＩＰ接続を採用することができる。
【０００８】
[0008]実際には、上で説明された方法論は、クライアントとＤＨＣＰサーバとが、Ｌ２接続によって相互接続されているべきことを要する。実際には、クライアントとＤＨＣＰサーバとは、同じＬＡＮネットワークに接続されなければならない。ＬＡＮは、複数のＶＬＡＮネットワークから構成されることがあるが、これらはＬ２レイヤで相互接続されていなければならない。クライアントがオーバーラップする１０．０．０．０アドレス空間を有する場合、サービスプロバイダは、オーバーラップするアドレス空間を別個のＬＡＮネットワークの中に構成することによって、アドレス空間を互いに分離しなければならない。結果として、すべてのプライベートネットワークが互いに分離され、それにより、ネットワーク内のＩＰトラフィックを可能にする一方、クライアントが他のクライアントのネットワークにアクセスするのを防止する。
【０００９】
[0009]第１に、ＤＨＣＰがＬ２で動作し、第２に、オーバーラップするアドレス空間が別々のＬＡＮの中に分離されなければばらないという事実の帰結は、単一のＤＨＣＰが、論理的に、複数のＬＡＮに分かれて常駐できないということである。言い換えれば、複数のプライベートネットワークの場合、その各々が、専用のＤＨＣＰサーバを有さなければならない。
【００１０】
[0010]インターネットプロトコルバージョン６（ＩＰｖ６）は、動的ＩＰ割り当てのための２つの機構を提供する。これらの機構は、ステートフル自動設定およびステートレス自動設定と呼ばれる。どちらの自動設定機構も上で特定された問題を解決せず、その理由は、第１に、ステートフル自動設定（ＤＨＣＰｖ６）は、ＩＰｖ４環境で使用されるＤＨＣＰｖ４とは実際には何も違わないからである。これは、ＩＰリソースが仮想マシンに割り当てられる度に、割り当てられたＩＰリソースが固定されたリース値を取得し、そのことは、基本的に、割り当てられたＩＰリソースがその仮想マシンによって実際に利用され続けるのか否かに関わらず、ＩＰリソースは、既定の期間の間、割り当てられたままとなることを意味するからである。クラウドベースの環境内では、これは望ましいことではなく、その理由は、新しい仮想マシンが始動するときにはいつでも、ＩＰアドレスはコミッションされる（発行される）べきであり、その仮想マシンが仮想化されたコンピューティング環境から取り除かれるときにはいつでも、ＩＰアドレスはデコミッションされる（解除される）べきだからである。
【００１１】
[0011]対して、ステートレス自動設定は、クライアントが、ルータ広告に基づいて自律的にＩＰアドレスを取得することを意味する。ＳＯＡアーキテクチャおよびオーケストレーションが関係する限り、この方式が機能できない２つの理由が存在する。第１に、オーケストレーションが使用される環境では、仮想マシンが稼働することが意図される仮想ローカルエリアネットワーク（ＶＬＡＮ）に適合するネットワークから、ＩＰアドレスが取得されることが、一般的な要件である。言い換えれば、仮想マシンにたまたま利用可能になる任意のＩＰアドレスを与えるのではなくて、ＩＰアドレスは、仮想マシンが配備されることになるＶＬＡＮに対応した特定のネットワークから割り当てられなければならない（前者は、ステートレス自動設定がもたらすものである）。この使用事例でステートレス自動設定が機能できない２つ目の理由は、その環境が、一般にマルチテナント環境であることであり、そこでは、アドミニストレータが各ネットワークの割り当てレベルを能動的に監視し、ネットワークにおいてどの機器およびクライアントが稼働しているのかを判定することができなければならない。ＩＰアドレスがクライアントによって自律的に取得される場合、所与の仮想マシンが取得しているであろうＩＰアドレスを制御する方法もないし、アドミニストレータがこれらの関係を管理する、および／またはＩＰ割り当ての割り当てを追跡するのを可能にするであろう、このプロセスへのいかなる透過性も存在しない。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本願発明の一実施例は、例えば、オーケストレートされたコンピューティング環境における、ＩＰのコミッショニングおよびデコミッショニングのための方法および装置に関する。
【課題を解決するための手段】
【００１３】
[0012]本発明の目的は、したがって、上で特定された問題のうちの１つまたは複数を緩和するために、方法、機器、およびコンピュータプログラム製品を提供することである。本発明の目的は、添付の独立請求項において定義される本発明の態様によって達成される。より具体的には、本発明は、上で説明された２つの問題のうちの少なくとも１つを緩和するやり方で、ＩＰアドレスおよび名前などのＩＰリソースを、コミッションし、デコミッションするために使用され得る、方法、機器、およびコンピュータプログラム製品を提供する。従属請求項、ならびに以下の詳細な説明および図面は、追加的な問題を解決する、および／または、追加的な利益を提供する特定の実施形態に関する。
【００１４】
[0013]本発明の態様は、クライアント−サーバ・アーキテクチャの原理に従って相互動作する、サーバ機器とクライアント機器とを含む。本コンテキストにおいて、本発明のサーバは、ＩＰコミッショニング／デコミッショニング（ＩＰ  ｃｏｍｍｉｓｓｉｏｎｉｎｇ／ｄｅｃｏｍｍｉｓｓｉｏｎｉｎｇ）サーバ装置（「ＩＰＣＤサーバ」）と呼ばれる。ＩＰＣＤサーバは、ネットワークの分布および割り当て、各ネットワーク内の個々のＩＰアドレスの可用性ステータス、関連するアドミニストレイティブ・プロパティおよび属性を、リアルタイムで管理し、追跡するために使用される。一般的な実装において、ＩＰＣＤサーバは、以下の要素を含む。
−  ＩＰコミッショニング／デコミッショニングサーバにおいて管理されるデータにアクセスするのに使用され得る、ウェブベースのユーザインターフェースなどのリモートユーザインターフェース、
−  サービス指向アーキテクチャ（ＳＯＡ）サポートするウェブベースのアプリケーション・プログラミング・インターフェース（ＡＰＩ）、加えて、ＡＰＩを介して受信された呼に基づいて、ＩＰアドレス、名前、および他のネットワーク構成などのＩＰリソースを、動的に指定し、解除することが可能なロジック、
−  個々のネットワークを、所与の内部および／または外部エンドユーザに関連付けるように構成された別のロジックであって、ネットワークが完全に割り当てられている場合に、ＩＰコミッショニング／デコミッショニングサーバが、内部および／または外部エンドユーザ（クライアント）に関連付けられた代替ネットワークから、ならびに／あるいは、ＩＰリソースの予備プールから、ＩＰリソース（たとえば、ＩＰアドレス）を自動的にプロビジョニングするように構成される、
−  ＳＯＡベースのＡＰＩ上で、ＩＰコミッショニング／デコミッショニングサーバと通信する、オーケストレーション・ソリューションにおいて稼働するクライアントを含むクライアント−サーバ・アーキテクチャ。
【００１５】
[0014]一般的な実装において、ＩＰＣＤクライアント機器は、以下のタスクを実施するように構成されたクライアントロジックを含む。
−  新しい仮想マシンが、オーケストレーション・ソリューションを使用してクラウドコンピューティング環境にコミッションされるとき、ＩＰアドレスおよび／または名前などのＩＰリソースを、ＩＰコミッショニング／デコミッショニングサーバに要求すること、および
−  デコミッションされた仮想マシンのＩＰアドレスおよび／または名前などの指定されたＩＰリソースの解除をトリガすること。
【００１６】
[0015]本発明の他の態様は、本発明のＩＰＣＤサーバおよびＩＰＣＤクライアントを動作させるための方法と、適切に装備されたサーバコンピュータおよびクライアントコンピュータでの実行が、サーバコンピュータおよびクライアントコンピュータにＩＰＣＤサーバおよびＩＰＣＤクライアントの特徴を与え、したがってＩＰＣＤサーバおよびＩＰＣＤクライアントに本発明の方法を遂行させる、コンピュータプログラム製品とを含む。
【００１７】
[0016]ＤＨＣＰをオーバーラップするプライベートネットワークに結合する初期の試みとは異なり、本発明は、ＯＳＩレイヤ２（Ｌ２）でネットワークパラメータをプロビジョニングしない。代わりに、ウェブベースのＡＰＩ上で通信される、ＩＰリソースを要求し指定するための呼が、ＯＳＩモデルのより高いレイヤで動作する。これは、ＩＰリソースが単一のＬＡＮ内で管理されなければならないという制限を排除する助けとなる、一線を画した特徴である。たとえば、単一のＬＡＮの制限を克服するための技法は、ＩＰＣＤサーバが、プライベートネットワークに関する情報を記憶し、それらのプライベートネットワークを、プライベートネットワークによって使用されるＬＡＮ、ＶＬＡＮ、仮想拡張ローカルネットワーク（ＶＸＬＡＮ）、および／または他の同様のＬＡＮに関連した属性に、タグ付けすることである。言い換えれば、ＩＰＣＤサーバは、どのＬＡＮがどのプライベートネットワークによって使用されているかに関する情報を記憶する。オーバーラップするアドレス空間は、論理的には同じＶＬＡＮを使用することはできないので、すべての管理されたネットワークは、たとえネットワークそれ自体が同一のアドレス空間を使用していたとしても、固有にされる。ＶＬＡＮがネットワークに接続され、プロビジョニングに使用されるとき、アドレス空間はオーバーラップし得るが、データセンタ内のＶＬＡＮはオーバーラップし得ないことは注目に値する。
【００１８】
[0017]好ましい、しかしオプションの特徴によれば、サービスプロバイダが複数のデータセンタを有する場合、ＩＰＣＤサーバはまた、ネットワークを、ＬＡＮに関する属性に加えて、ネットワークが稼働しているデータセンタに関する情報にタグ付けすることができる。このオプションの方法は、同じＩＰＣＤサービスを共有する異なるデータセンタにおける、同一のＬＡＮ、ＶＬＡＮ、および／またはＶＸＬＡＮに接続された、オーバーラップするプライベートネットワーク同士を区別するために使用される。
【００１９】
[0018]上で特定された要素は、以下でより詳細に説明される。本発明は、第１に、ＩＰコミッショニング／デコミッショニングサーバ装置を含み、本サーバ装置は、ネットワークの分布および割り当て、各ネットワーク内の個々のＩＰアドレス、関連するアドミニストレイティブ・プロパティおよび属性を、リアルタイムで管理し、追跡するために使用される。事前構成された固定のリース時間が満了する前に発行されたＩＰアドレスを再請求できない慣例的なＤＨＣＰサーバとは異なり、本発明によるＩＰコミッショニング／デコミッショニングサーバ装置は、仮想マシンがデコミッションされるときに、ＩＰアドレスなどのＩＰリソースをデコミッションし、使用されていないＩＰリソースを再請求するように構成される。ＩＰコミッショニング／デコミッショニングサーバのデコミッショニング方式は、知られているＩＰリコンシリエーションモデルとは、以下の点で異なる。いくつかの先行技術のＩＰリコンシリエーションモデルは、割り当てられているが現在は使用されていないＩＰアドレスの再請求を許可するが、先行技術のＩＰリコンシリエーションモデルは、それらのＩＰアドレスのリース時間が満了になった後でのみ、使用されていないＩＰアドレスの再利用を許可にするにすぎない。そうしなければ、トラブルを引き起こすことになる、重複ＩＰアドレスのリスクが伴うことになる。
【００２０】
[0019]本発明の特徴の１つは、クラウドベースのコンピューティング環境で稼働する仮想マシンおよび／またはワークロードが、存在しなくなる、または別のクラウド環境に移行される状況に関する。仮想マシンはオンデマンドベースで、コミッションされ、デコミッションされるので、これは、クラウディング環境に非常によくあることである。そのような場合、ワークロードがデコミッションされようとするとき、または別のクラウド環境に移行されるときに、オーケストレーション・システムにおいて稼働中のクライアントが、ＩＰコミッショニングシステムに通知することになる。通知の結果、本発明のＩＰコミッショニング／デコミッショニングサーバは、もはや存在しないクライアントに以前指定されていたＩＰアドレスなどのリソースを、自動的に解除することになる。匹敵する機構はＤＨＣＰには存在しない。というのは、ＤＨＣＰ仕様は、取得していたＩＰアドレスをクライアントがもはや使用することなく、ＩＰアドレスが解除されてもよい、という事実についてＤＨＣＰサーバに通知することができるクライアントを定義しないからである。本発明は、前記システムがデコミッションしている、または別の環境にワークロードを移行しているときに、オーケストレーション・システムと通信することによって、この問題を解決する。クライアント−サーバ・アーキテクチャの使用は、本発明のＩＰＣＤサーバが、所与のＩＰリソースが実際に何かのために使用されているか否かに関するリアルタイムな情報を取得することができるという利益を提供する。先行技術においては、どのＩＰリソースが使用されているか、およびどれが指定されているだけで使用されていないかに関する正確な情報の欠如が、リース時間が満了するまで、使用されていないＩＰリソースを再請求することを不可能にしている。
【００２１】
[0020]本発明は、ＳＯＡベースのアーキテクチャを利用するオーケストレートされたコンピューティング環境であって、その中で、ＩＰ割り当てが、オーケストレーション・システムによって管理されるコミッショニングおよび／またはデコミッショニングプロセスの一部として遂行されるべき、オーケストレートされたコンピューティング環境に関する。ＳＯＡ環境は、システムにアプリケーションレイヤ（ＯＳＩモデルのレイヤ７）で互いに通信することを要求するオープンなウェブベースのＡＰＩ（たとえば、ＳＯＡＰ）に基づき、従来のＤＨＣＰサーバは、ＯＳＩ  ２レイヤで送信されるデータリンクレイヤ（ＯＳＩモデルのレイヤ２）を利用するので、それによって、この２つを互換性のないものにしている。
【００２２】
[0021]本発明のＩＰコミッショニング／デコミッショニングサーバは、ウェブベースのユーザインターフェースなどのリモートユーザインターフェースをさらに含み、リモートユーザインターフェースは、ＩＰコミッショニング／デコミッショニングサーバにおいて管理されるデータにアクセスするのに使用されてよい。リモートユーザインターフェースは、（ステートレス自動設定に関して）ネットワークの割り当ておよび使用レベルをリアルタイムで追跡する能力を提供する。本発明における他の望ましい特徴は、これらのレベルをリアルタイムで透過的に監視するアドミニストレータの能力、内部および／または外部エンドユーザに、彼らによって使用されるネットワークへの制限されたアクセス権／閲覧権を差し出す可能性を含む、マルチテナント環境をサポートすること、ネットワークを管理（追加する、取り除く、分割する、マージする、および／またはコンテンツを編集する）する能力、ならびに、選択属性（たとえば、所与のネットワークに関連付けられたＶＬＡＮ、ネットワークのオーナー、など）またはプロパティをネットワークにタグ付けすることによって、選択属性を、管理されたネットワークに関連付けることができることである。最後の部分が重要である理由は、たとえば、オーケストレーション・ソリューションによって知られる所与のＶＬＡＮを、ＩＰがそこから取り出されることになるネットワークに関連付けるためには、オーケストレーション・システムおよびＩＰコミッショニング／デコミッショニングサーバに等しく知られた、ＶＬＡＮタグまたは名前などの共通のデノミネータが存在する必要があることである。そして、このすべてを管理するためには、多くのアドミニストレイティブユーザにとって、ＧＵＩが望ましい。
【００２３】
[0022]本ＩＰコミッショニング／デコミッショニングサーバは、サービス指向アーキテクチャ（ＳＯＡ）サポートするアプリケーション・プログラミング・インターフェース（ＡＰＩ）、加えて、ＡＰＩを介して受信された呼に基づいて、ＩＰアドレスおよび他のネットワーク構成などのＩＰリソースを動的に指定し、解除することが可能な第１のロジックをさらに含む。
【００２４】
[0023]ＩＰコミッショニング／デコミッショニングサーバは、個々のネットワークを、所与のエンドユーザに関連付けるように構成された第２のロジックをさらに含み、ネットワークが完全に割り当てられている場合に、ＩＰコミッショニング／デコミッショニングサーバが、エンドユーザに関連付けられた代替ネットワークから、および／または、ＩＰリソースの予備プールから、ＩＰリソース（たとえば、ＩＰアドレス）を自動的にプロビジョニングするように構成される。
【００２５】
[0024]さらに、ＩＰコミッショニング／デコミッショニングサーバは、ＳＯＡベースのＡＰＩ上でＩＰコミッショニング／デコミッショニングサーバと通信する、オーケストレーション・ソリューションで稼働するクライアントを含む、クライアント−サーバ・アーキテクチャを含む。
【００２６】
[0025]クライアントに関しては、クライアントは、新しい仮想マシンがオーケストレーション・ソリューションによってクラウドコンピューティング環境にコミッションされるとき、ＩＰアドレスおよび／または名前などのＩＰリソースを、ＩＰコミッショニング／デコミッショニングサーバに要求するクライアントロジックを含む。クライアントロジックは、デコミッションされた仮想マシンのＩＰアドレスおよび／または名前などの指定されたＩＰリソースの解除をトリガする。
【００２７】
[0026]以下では、添付の図面を参照して、特定の実施形態を用いて、本発明がさらに詳細に説明される。
【図面の簡単な説明】
【００２８】
【図１】本発明の一実施形態による、クライアント−サーバ・アーキテクチャのブロックレベル図である。
【図２Ａ】本発明の一実施形態によるＩＰコミッショニング／デコミッショニングサーバ（ＩＰＣＤサーバ）の動作を示す、部分図２Ａおよび２Ｂからなるフロー図である。
【図２Ｂ】本発明の一実施形態によるＩＰコミッショニング／デコミッショニングサーバ（ＩＰＣＤサーバ）の動作を示す、部分図２Ａおよび２Ｂからなるフロー図である。
【図３】さまざまなサーバコンピュータおよび／またはクライアントコンピュータについての例示的なブロック図を概略的に示す図である。
【発明を実施するための形態】
【００２９】
[0027]図１は、本発明の一実施形態によるクライアント−サーバ・アーキテクチャのブロックレベル図である。参照符号ＩＰＣＤＳは、本実施形態によるＩＰコミッショニング／デコミッショニングサーバ（ＩＰＣＤサーバ）を表す。参照符号ＵＩは、ウェブベースのユーザインターフェースなどの、好ましくはリモートユーザインターフェースであるユーザインターフェースを表す。ユーザインターフェースは、ＩＰＣＤサーバＩＰＣＤＳにおいて管理されたデータにアクセスするために使用されてよい。参照符号ＡＰＩは、サービス指向アーキテクチャ（ＳＯＡ）をサポートするアプリケーション・プログラミング・インターフェースを表す。参照符号ＢＬは、ＡＰＩを介して受信された呼に基づいて、ＩＰアドレス、名前、および他のネットワーク構成などのＩＰリソースを、動的に指定し、解除することが可能なビジネスロジックを表す。ＩＰＣＤサーバＩＰＣＤＳの本実施形態は、２つの管理エンジンＭＥ１およびＭＥ２をさらに含み、ＭＥ１およびＭＥ２は、それぞれ第１のロジックおよび第２のロジックに対応し、第１のロジックおよび第２のロジックは、個々のネットワークを、所与のエンドユーザに関連付けるように一括して構成されており、ネットワークが完全に割り当てられている場合に、ＩＰコミッショニング／デコミッショニングサーバは、内部および／または外部エンドユーザに関連付けられた代替ネットワークから、ならびに／あるいは、ＩＰリソースの予備プールから、ＩＰリソース（たとえば、ＩＰアドレス）を自動的にプロビジョニングするように構成される。
【００３０】
[0028]参照符号ＣＬは、本発明のクライアント−サーバ・アーキテクチャのクライアントコンピュータを表す。クライアントコンピュータＣＬは、オーケストレーション・ソリューションＯＳにおいて稼働する、またはオーケストレーション・ソリューションＯＳに関連して、ＳＯＡベースのアプリケーション・プログラミング・インターフェース上でＩＰＣＤサーバＩＰＣＤＳと通信する。オーケストレーション・ソリューションＯＳは、いくつかのサーバインスタンスＳＩをサポートする。一般的な実装において、サーバインスタンスＳＩは、仮想マシンであり、仮想マシンの各々は、それぞれのワークロードを有する。
【００３１】
[0029]部分図２Ａおよび図２Ｂからなる図２は、本発明の一実施形態によるＩＰコミッショニング／デコミッショニングサーバ（ＩＰＣＤサーバ）の動作を示すフロー図である。
【００３２】
[0030]ステップ２−２で、オーケストレーション・システムは、ＩＰＣＤサーバＩＰＣＤＳに要求を送信し、この要求は、ホストが配備されることになる仮想ローカルエリアネットワークＶＬＡＮを特定する。ステップ２−４で、ＩＰＣＤサーバＩＰＣＤＳは、ＶＬＡＮが、本ＩＰＣＤシステムによって管理されるネットワークにタグ付けされているかどうかを検査する。タグ付けされていない場合、フローはステップ２−４６（図２Ｂを参照されたい）へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、エラーの原因を提示するエラーメッセージを返す。ステップ２−４の結果、タグ付けされている場合、フローはステップ２−６へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、ＩＰアドレスの発行が要求の一部であったかどうかを検査する。発行が要求の一部である場合、フローはステップ２−１４へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、空いているＩＰアドレスがＶＬＡＮに関連付けられた第１のネットワークにおいて利用可能であるかどうかを検査する。利用可能である場合、フローはステップ２−２０へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、名前の発行が要求の一部であったかどうかを検査する。名前の要求の一部であった場合、フローはステップ２−３０へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、空いているＩＰアドレスを確保し、ＶＬＡＮに関連付けられたネットワークに対し構成されたデフォルトゾーンにそれを結び付ける一意の名前を生成する。ＩＰＣＤサーバＩＰＣＤＳは次いで、一意の名前およびＩＰアドレスをオーケストレーション・システムＯＳに返し、そのＩＰアドレスに、それがそこから割り当てられたネットワークにおいて使用されるものとして印を付ける。ステップ２−２０の結果、名前の発行が要求の一部でなかった場合、フローはステップ２−３２へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、空いているＩＰアドレスを確保し、それをオーケストレーション・システムＯＳに返し、そのＩＰアドレスに、それがそこから割り当てられたネットワークにおいて使用されるものとして印を付ける。
【００３３】
[0031]ステップ２−６の結果、ＩＰアドレスの発行が要求の一部でなかった場合、フローはステップ２−８へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、名前の発行が要求の一部であったかどうかを検査する。名前の発行が要求の一部であった場合、フローはステップ２−３８へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、ＶＬＡＮに関連付けられたネットワークに対し構成されたデフォルトゾーンにそれを結び付ける自動生成された名前を返し、一意の名前をオーケストレーション・システムＯＳに返す。ステップ２−８の結果、名前の発行が要求の一部でなかった場合、フローはステップ２−１０へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、ＩＰアドレスの解除が要求の一部であったかどうかを検査する。ＩＰアドレスの解除が要求の一部であった場合、フローはステップ２−１８へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、使用されている名前の解除が要求の一部であったかどうかを検査する。名前の解除が要求の一部であった場合、フローはステップ２−４０へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、使用されている名前およびＩＰアドレスを、関連付けられたＶＬＡＮに適合したネットワークから解除し、確認をオーケストレーション・システムＯＳに返す。ステップ２−１８の結果、名前の解除が要求の一部でなかった場合、フローはステップ２−４２へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、使用されているＩＰを関連付けられたＶＬＡＮに適合したネットワークから解除し、確認をオーケストレーション・システムＯＳに返す。
【００３４】
[0032]本例で、ステップ２−１０の結果、ＩＰアドレスの解除が要求の一部でなかった場合、フローはステップ２−１２へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、要求がＩＰＣＤサーバの機能のいずれにも関係しなかったことに気づき、エラーメッセージを返す。より多くの機能を有するより大がかりな実装では、ステップ２−１２からの右への分岐が、さらなるテストおよび機能へと進むことができる。
【００３５】
[0033]ステップ２−１４の結果、空いているＩＰアドレスがＶＬＡＮに関連付けられた第１のネットワークにおいて利用可能でない場合、フローはステップ２−１６へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、同じＶＬＡＮにタグ付けされた他のネットワークがあるかどうかを検査する。他のネットワークがある場合、フローはステップ２−２２へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、他のネットワークに空いているＩＰアドレスがあるかどうかを検査する。ある場合、ステップ２−２４で、ＩＰＣＤサーバＩＰＣＤＳは、名前の発行が要求の一部であったかどうかを検査する。名前の発行が要求の一部であった場合、フローは、上で説明されたステップ２−３０へと進む。そうでない場合、フローはステップ２−３４へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、空いているＩＰアドレスをオーケストレーション・システムＯＳに返し、そのＩＰアドレスに、ＩＰがそこから割り当てられたネットワークにおいて使用されるものとして印を付ける。
【００３６】
[0034]ステップ２−１６またはステップ２−２２の結果、他のネットワークがない、または他のネットワークに空いているＩＰアドレスがない場合、フローはステップ２−３６へと進み、そこでＩＰＣＤサーバＩＰＣＤＳは、ＶＬＡＮに関連付けられたネットワークに対し構成されたデフォルトゾーンにそれを結び付ける自動生成された名前を返し、一意の名前をオーケストレーション・システムＯＳに返す。
【００３７】
[0035]図３は、さまざまな情報処理要素についての例示的なブロック図を概略的に示す。図３に示された、全体として参照番号３−１００で表されるデータ処理アーキテクチャは、本発明のサーバおよびクライアントを実装するために使用されてよい。サーバにふさわしい構成が示されており、クライアントコンピュータの構成は、より単純であってよい。２つの主要な機能ブロックは、処理システム３−１００およびストレージシステム３−１９０である。処理システム３−１００は、全体として参照番号３−１１０で表される１つまたは複数の中央処理ユニットＣＰ１…ＣＰｎを含む。処理ユニットは、ネイティブな処理ユニットまたは仮想処理ユニットであってよい。複数の処理ユニット３−１１０を含む実施形態には、好ましくは、複数の処理ユニット３−１１０の中で処理負荷のバランスを取る負荷バランスユニット３−１１５が提供される。複数の処理ユニット３−１１０は、別々のプロセッサコンポーネントとして実装されても、または単一のコンポーネントケース内の物理プロセッサコアもしくは仮想プロセッサとして実装されてもよい。処理システム３−１００は、全体として参照符号ＤＮで表されるさまざまなデータネットワークと通信するための、ネットワークインターフェース３−１２０をさらに含む。データネットワークＤＮは、イーサネット（登録商標）ワークなどのローカルエリアネットワーク、および／またはインターネットなどのワイドエリアネットワークを含むことができる。参照番号３−１２５は、処理システム３−１００がそれを通してさまざまなアクセスネットワークＡＮと通信することができる、モバイルネットワークインターフェースを表し、アクセスネットワークＡＮは、エンドユーザまたはクライアントによって使用されるモバイル端末にサービス提供する。複数の異なるネットワークをサポートする構成により、処理システム３−１００は、地上ベースの端末３−３００およびモバイル端末３−２１０などの複数のタイプのクライアントをサポートすることが可能になる。
【００３８】
[0036]本実施形態の処理システム３−１００はまた、ローカルユーザインターフェース３−１４０を含むことができる。実装に応じて、ユーザインターフェース３−１４０は、キーボード、マウス、およびディスプレイ（図示せず）などの、ローカルユーザインターフェースのためのローカル入出力回路を含むことができる。代替として、またはそれに加えて、処理システム３−１００の管理は、ネットワークインターフェース３−１２０、およびユーザインターフェースを提供する任意のインターネット対応端末を利用することによって、リモートで実装されてもよい。ユーザインターフェースの性質は、どの種類のコンピュータが処理システム３−１００の実装に使用されるかに依存する。処理システム３−１００が専用コンピュータである場合、ローカルユーザインターフェースを必要としないことがあり、処理システム３−１００は、たとえば、インターネット上でウェブブラウザなどから、リモートで管理されてもよい。そのようなリモート管理は、コンピュータがそれ自身とクライアント端末との間のトラフィックに利用する、同じネットワークインターフェース３−１２０を介して、実現されてもよい。
【００３９】
[0037]処理システム３−１００はまた、プログラム命令、動作パラメータ、および変数を記憶するためのメモリ３−１５０を含む。参照番号３−１６０は、処理システム３−１００に適したプログラムを表す。
【００４０】
[0038]処理システム３−１００はまた、さまざまなクロック、割込みなどのための回路を含み、これらは、全体として参照番号３−１３０で表される。処理システム３−１００は、ストレージシステム３−１９０へのストレージインターフェース３−１４５をさらに含む。処理システム３−１００のスイッチがオフにされるとき、ストレージシステム３−１９０は、処理機能を実装するソフトウェアを記憶することができ、起動するとき、ソフトウェアは、半導体メモリ３−１５０に読み込まれる。ストレージシステム３−１９０はまた、電源オフ期間にわたって動作および変数を保持する。大規模な実装、すなわち、単一の処理システム３−１００がそれぞれのモバイル端末ＭＴを介して多数のクライアントにサービス提供する実装では、ストレージシステム３−１９０は、クライアントおよびモバイル端末ＭＴに関連付けられた動的なダイアログ行列を記憶するために使用されてよい。当業者にはよく知られているように、さまざまな要素３−１１０から３−１５０は、アドレス信号、データ信号、および制御信号を搬送するバス３−１０５を介して相互接続される。
【００４１】
[0039]技術が進歩するにつれ、本発明の概念がさまざまなやり方で実装され得ることは、当業者には明らかであろう。本発明およびその実施形態は、上で説明された例には限定されず、特許請求の範囲内で変化してよい。
【図１】
2015525543.tif 000003
【図２Ａ】
2015525543.tif 000004
【図２Ｂ】
2015525543.tif 000005
【図３】
2015525543.tif 000006
【手続補正書】
【提出日】平成27年3月2日(2015.3.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
オーケストレーション・ソリューションを使用してプロビジョニングされる複数のサーバインスタンスに対し、インターネットプロトコル［ＩＰ］リソースをコミッションする／デコミッションするためのサーバコンピュータ（ＩＰＣＤＳ、３−１００）であって、前記サーバコンピュータおよびいくつかのクライアントの各々が、クライアント−サーバ・アーキテクチャを構成し、前記サーバコンピュータが、
少なくとも１つの処理ユニット（ＣＰ１…ＣＰｎ）を含む処理システム（３−１１０）と、
アプリケーションおよびデータを記憶するためのメモリ（ＭＥＭ、３−１５０）と
を含み、
前記メモリが、以下の特徴である、
前記サーバコンピュータのリモート管理のためのユーザインターフェース（ＵＩ）であって、前記サーバコンピュータによって管理されるデータ（ＤＢ）へのアクセスを提供するように構成された、ユーザインターフェース（ＵＩ）と、
サービス指向アーキテクチャ［ＳＯＡ］をサポートすることが可能な、ウェブベースのアプリケーション・プログラミング・インターフェース（ＡＰＩ）と、
前記アプリケーション・プログラミング・インターフェースを介してそれぞれのクライアント（ＣＬ）から受信された１つまたは複数の呼(calls)に基づいて、いくつかのクライアントの各々へのＩＰリソースを動的に指定し(assign)、解除する(release)ように構成された第１のロジックと
を実装する(implement)ように、前記処理システム（３−１１０）に命令するためのプログラムコード命令（３−１６０）を含み、
前記第１のロジックが、２つ以上のサーバインスタンス（ＳＩ）のうちの各々のために少なくとも１つの一意の(unique)ＩＰリソースを作成するためのプログラムコード命令を含み、前記２つ以上のサーバインスタンスが、オーバーラップするアドレス空間を有するネットワークのノードであり、
前記少なくとも１つの一意のＩＰリソースが、前記２つ以上のサーバインスタンスのうちのそれぞれの１つのプライベートネットワークの名前と、そのプライベートネットワーク内のＩＰアドレスとの組合せに基づき、
動的に指定され、解除されたＩＰリソースの、少なくともいくつかが、及び、少なくとも１つの一意のＩＰリソースが、それぞれＩＰアドレスを含む、
サーバコンピュータ（ＩＰＣＤＳ、３−１００）。
【請求項２】
前記少なくとも１つの一意のＩＰリソースが、前記２つ以上のコンピュータのうちの前記それぞれ１つの前記プライベートネットワークの名前と、そのプライベートネットワーク内のＩＰアドレスとの組合せに基づく、請求項１に記載のサーバコンピュータ。
【請求項３】
個々のネットワークを、所与の内部および／または外部エンドユーザに関連付けるように構成された第２のロジックであって、ネットワークの１つまたは複数のリソースが完全に割り当てられている場合に、前記内部および／または外部エンドユーザに関連付けられた代替(alternate)ネットワークから、ならびに／あるいは、ＩＰリソースの予備(reserve)プールから、ＩＰリソースを自動的にプロビジョニングする(provision)ように構成された、第２のロジック
をさらに含む請求項１に記載のサーバコンピュータ。
【請求項４】
前記処理システムが、複数の処理ユニットと、前記複数の処理ユニットの中で処理負荷を分配するための負荷バランスユニットとを含む、請求項１に記載のサーバコンピュータ。
【請求項５】
少なくとも１つの処理ユニットと、
アプリケーションおよびデータを記憶するためのメモリと、
を含む、インターネットプロトコル［ＩＰ］リソースをコミッションする／デコミッションすることを要求するためのクライアントコンピュータであって、
前記メモリが、以下のタスクである、
新しい仮想マシンが、オーケストレーション(orchestration)・ソリューションによってクラウドコンピューティング環境にコミッションされる(commissioned)とき、ＩＰリソースを、ＩＰコミッショニング／デコミッショニングサーバに要求すること、および
デコミッションされた仮想マシンに応答して、前記仮想マシンに指定されたＩＰリソースの解除(release)をトリガすること
を実施するように構成されたクライアントロジックを実装するように、前記少なくとも１つの処理ユニットに命令するためのプログラムコード命令
を含み、
前記ＩＰリソースの、少なくともいくつかが、それぞれ、ＩＰアドレスを含む、
クライアントコンピュータ。
【請求項６】
オーケストレーション・ソリューションを使用してプロビジョニングされる複数のクライアントに対し、インターネットプロトコル［ＩＰ］リソースをコミッションする／デコミッションするための、サーバコンピュータを動作させるための方法であって、前記サーバコンピュータおよび前記クライアントの各々が、クライアント−サーバ・アーキテクチャを構成し、前記方法が、
前記サーバコンピュータに、サービス指向(service oriented)アーキテクチャ［ＳＯＡ］をサポートすることが可能なアプリケーション・プログラミング・インターフェース［ＡＰＩ］を提供するステップと、
前記サーバコンピュータによって管理されるデータへのアクセスを提供するために、リモートインターフェースを構成するステップと、
前記リモートユーザインターフェースを介して前記サーバコンピュータをリモートで管理するステップと、
前記アプリケーション・プログラミング・インターフェースを介してそれぞれのクライアントから受信された１つまたは複数の呼に基づいて、いくつかのクライアントの各々へのＩＰリソースを動的に指定し、解除するステップと、
２つ以上のサーバインスタンスの各々のために少なくとも１つの一意のＩＰリソースを作成するステップであって、前記２つ以上のサーバインスタンスが、オーバーラップするアドレス空間を有するネットワークのノードである、作成するステップと
を含み、
前記少なくとも１つの一意のＩＰリソースが、前記２つ以上のサーバインスタンスのうちのそれぞれの１つのプライベートネットワークの名前と、そのプライベートネットワーク内のＩＰアドレスとの組合せに基づき、
動的に指定され、解除されたＩＰリソースの、少なくともいくつかが、及び、少なくとも１つの一意のＩＰリソースが、それぞれＩＰアドレスを含む、
方法。
【請求項７】
インターネットプロトコル［ＩＰ］リソースをコミッションする／デコミッションすることを要求するためのクライアントコンピュータを動作させる方法であって、
新しい仮想マシンが、オーケストレーション・ソリューションによってクラウドコンピューティング環境にコミッションされるとき、ＩＰコミッショニング／デコミッショニングサーバにＩＰリソースを要求するステップと、
デコミッションされた仮想マシンに応答して、前記仮想マシンに指定されたＩＰリソースの解除をトリガするステップと
を含み、
前記ＩＰリソースの、少なくともいくつかが、それぞれ、ＩＰアドレスを含む、
方法。
【請求項８】
プログラムコード命令を含む有形のプログラムキャリアであって、前記プログラムコード命令が、請求項１に記載のサーバコンピュータ上で実行されるとき、前記サーバコンピュータに請求項６の方法を遂行させる、有形のプログラムキャリア。
【請求項９】
プログラムコード命令を含む有形のプログラムキャリアであって、前記プログラムコード命令が、請求項５に記載のクライアントコンピュータ上で実行されるとき、前記クライアントコンピュータに請求項７の方法を遂行させる、有形のプログラムキャリア。
【国際調査報告】
2015525543.tif 000007
2015525543.tif 000008
2015525543.tif 000009
2015525543.tif 000010