JP2013506908A - 企業ネットワーク内の割り当てられたクラウドリソースの動的な負荷分散およびスケーリング - Google Patents

Abstract

様々な例示的な実施形態は、クラウドネットワーク（１０２）にまで拡張された企業ネットワーク（１０１）のための作業負荷分配システムおよび関連する方法に関する。企業ネットワーク（１０１）は、プライベート企業ネットワーク内の一連のサーバおよびクラウドネットワーク（１０２）におけるスケーラブルな一連のサーバを含むことができる。企業ネットワーク（１０１）は、プライベート企業ネットワーク（１０１）とクラウドネットワーク（１０２）の両方において、それぞれの一連のサーバに接続されて、全体的なシステムパフォーマンスおよびコストなどの基準に基づいて両ネットワーク内のサーバの間で作業を分配する、１つまたは複数の負荷分散装置（１０３）を利用することができる。また、企業ネットワーク（１０１）は、１つまたは複数の制御装置（１０７）を利用して、システム作業負荷および、作業要求毎に生じた収益などの他のユーザ定義の基準に基づいて、企業ネットワーク（１０１）に割り当てられるクラウドサーバ（１１４ａ、．．．、１１４ｅ）の数を増減することができる。

Description

本明細書に開示される様々な例示的な実施形態は、一般に、ネットワーク通信およびインターネットアーキテクチャに関する。

クラウドコンピューティングネットワークは、クラウドコンピューティングプロバイダがインターネットを介して顧客にリソースを提供することを可能にする、非常にスケーラブルで動的なサービスである。クラウドインフラは、要求されたリソースを提供するクラウド内の特定のインフラに関する知識を顧客が必要としないように、抽象化の層を提供する。顧客は、日常的な使用にはプライベート企業ネットワーク内に既に存在しているインフラを使用しながら、重い負荷に対してはクラウド内の余分のリソースを使用することができるので、そのようなサービスは、消費者がピーク時に使用するための余分のハードウェアへの資本支出を回避するのに役立つ。

そのようなシステムはリソースのスケーラブルな配備を可能にし、顧客は仮想マシンすなわちサーバインスタンスを作成して、自分で選んだソフトウェアを実行する。顧客は、必要に応じてこれらの仮想マシンを作成し、使用し、破棄することができ、プロバイダは通常、使用されたアクティブなサーバに対して課金する。

現在、クラウドサービスプロバイダは、クラウドリソースの使用に対して課金する際に異なる価格体系を使用する、ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ ｓｅｒｖｉｃｅ(ＩａａＳ）などのプログラムを提供している。したがって、ユーザは、ピーク使用のために内部ネットワークインフラに対する初期投資を少なくすることができる。これは特に、ユーザがピーク時間帯に、簡単に料金を払ってクラウドリソースを借りて使用することができる、高いピーク対平均比使用率に当てはまる。しかし、実装に応じて、特にその処理に特定のロケーションを必要とするアプリケーションの場合に、クラウドネットワークに合わせてスケーリングし、新たに割り当てられた仮想マシンにシームレスに作業を割り当てることは複雑なものとなる場合がある。

上記に鑑みて、内部ネットワークおよびクラウドネットワーク内のサーバに課された負荷を動的に制御することが望ましい。より具体的には、制御装置に、システム要求に基づいてクラウドリソースの使用を自動的にスケーリングさせ、クラウドネットワーク内の内部サーバおよび割り当てられた仮想マシンの間で要求の割当てを平衡化させることが望ましい。他の望ましい態様は、本明細書を読み、理解すれば、当業者に明らかとなろう。

プライベート企業ネットワークに割り当てられたクラウドネットワーク内のサーバの作業負荷を動的に制御するという現在の必要性に鑑みて、様々な例示的な実施形態の簡潔な概要が提示される。以下の概要において、いくつかの簡略化および省略が行われる場合があり、このことは、様々な例示的な実施形態のいくつかの態様を強調し、紹介することを意図しており、本発明の範囲を限定することを意図するものではない。当業者が本発明の概念を作成し、使用することを可能にするのに十分な、好ましい例示的な実施形態の詳細な説明は、後段で述べることにする。

様々な例示的な実施形態は、プライベート企業ネットワークに割り当てられたクラウドネットワーク内のリソースを管理するためのシステムであって、プライベート企業ネットワークに割り当てられたクラウドネットワーク内の仮想マシンを含む第１の一連のサーバと、プライベート企業ネットワーク内のコンピューティングリソースを含む第２の一連のサーバと、第１および第２の一連のサーバのパフォーマンスデータに基づいて第１および第２の一連のサーバにおけるメンバ間で作業を分配するための、プライベート企業ネットワーク内の負荷分散装置と、第１および第２の一連のサーバのパフォーマンスデータを収集するためのパフォーマンス監視装置を備える、プライベート企業ネットワーク内の制御装置とを備えるシステムに関する。

様々な例示的な実施形態は、企業ネットワーク内の作業負荷を管理するための負荷分散装置であって、プライベート企業ネットワークに割り当てられたクラウドネットワーク内の第１の一連のサーバおよびプライベート企業ネットワーク内の第２の一連のサーバの間で作業要求を送るための負荷分散モジュールと、第１および第２の一連のサーバからパフォーマンスデータを収集することによって、企業ネットワークを構成するサーバのパフォーマンスを追跡するための監視モジュールとを備える負荷分散装置にも関する。

様々な例示的な実施形態は、企業ネットワーク内のリソースを管理するための制御装置であって、プライベート企業ネットワークに割り当てられたクラウドネットワーク内の第１の一連のサーバおよびプライベート企業ネットワーク内の第２の一連のサーバの中で何台のサーバがアクティブであるべきかを判定するためのスケーリング管理装置であって、判定が第１および第２の一連のサーバのパフォーマンスに基づく、スケーリング管理装置と、スケーリング管理装置の決定に基づいて、第１の一連のサーバに少なくとも１つのサーバを追加し、第１の一連のサーバから少なくとも１つのサーバを削除するためのインスタンス管理装置とを備える制御装置にも関し得る。

様々な例示的な実施形態は、企業ネットワーク内のサーバに作業要求を送信する方法であって、負荷分散装置によってホスティングされている負荷分散モジュールが、ユーザによって指定された基準に基づいて要求決定規則を策定するステップと、負荷分散モジュールが、決定規則の実行によって、負荷分散装置によってホスティングされているサーバリストから選択された宛先サーバを選択するステップと、負荷分散モジュールが、作業要求を宛先サーバに送るステップとを備える方法にも関し得る。

様々な例示的な実施形態は、少なくとも１つのサーバを企業ネットワークに追加する方法であって、制御装置が、プライベート企業ネットワークを備える企業ネットワーク内でアプリケーションが動作しており、クラウドネットワークの割り当てられた部分が閾値パフォーマンスメトリック未満で動作していることを判定するステップと、制御装置が、閾値を上回ってアプリケーションのパフォーマンスメトリックを上昇させるプライベート企業ネットワークに割り当てられたクラウドネットワーク内の一連のサーバに追加すべき、クラウドネットワーク内のサーバの数を判定するステップと、制御装置が、追加されるべきサーバの決定された数に従って少なくとも１つの新規のサーバを開始するステップと、制御装置が、チョークポイントについてクラウドネットワーク内の一連のサーバを確認するステップと、制御装置が、企業ネットワークを監視してクラウドネットワーク内の一連のサーバにサーバを追加するかクラウドネットワーク内の一連のサーバからサーバを削除するかを判定するステップとを備える方法にも関する。

様々な例示的な実施形態は、企業ネットワークからサーバを削除する方法であって、制御装置が、企業ネットワークに割り当てられたクラウドネットワーク内の第１の一連のサーバおよびプライベート企業ネットワーク内の第２の一連のサーバを備える企業ネットワークの作業負荷を企業ネットワークの合計スループットと比較するステップと、制御装置が、合計システム作業負荷が企業ネットワークの合計スループットの閾値を下回るときに、第１の一連のサーバにおける少なくとも１つのサーバに終了の印を付けるステップと、制御装置が、第１の一連のサーバから印を付けたサーバを削除するステップとを備える方法にも関し得る。

上記によれば、様々な例示的な実施形態は、クラウドリソースの使用を動的に最適化する。また、様々な例示的な実施形態は、プライベート企業ネットワーク内のサーバに課された内部負荷および企業に割り当てられたクラウドネットワーク内のリソースに課された負荷を動的に分散する。

様々な例示的な実施形態のよりよい理解を容易にするために、添付の図面を参照する。

プライベート企業ネットワークとクラウドネットワークとの間の負荷分散および自動的なスケーリングのための例示的なネットワークの概略図である。 プライベート企業とクラウドネットワークとの間の負荷分散および自動的なスケーリングのための代替ネットワークの概略図である。 要求をサーバに送る例示的な方法の流れ図である。 クラウドネットワーク内のリソースの使用量をスケールアップさせる例示的な方法の流れ図である。 クラウドネットワーク内のリソースの使用量をスケールダウンさせる例示的な方法の流れ図である。

次に図面を参照すると、様々な例示的な実施形態の開示された広範な態様があり、図面において、同様の数字は同様の構成要素またはステップを指す。

図１は、企業ネットワーク内で負荷分散装置１０３およびオートスケーラ（ａｕｔｏｍａｔｉｃ ｓｃａｌｅｒ）を実装する企業拡張ネットワーク１００の例示的な実施形態を示す。企業拡張ネットワーク１００は、少なくとも１つのプライベート企業ネットワーク１０１およびクラウドネットワーク１０３を含むことができる。プライベート企業ネットワーク１０１は、負荷分散装置１０３、制御装置１０７、および一連のサーバ１１１ａ−ｃを含むことができる。負荷分散装置１０３は、サーバリスト１０５および負荷分散モジュール１０６を含むことができる。制御装置１０７は、パフォーマンス監視装置１０８、スケーリング管理装置１０９、およびインスタンス管理装置１１０を含むことができる。クラウドネットワーク１０２は、一連のサーバ１１４ａ−ｅを含むことができる。一連のサーバ１１１ａ−ｃ、１１４ａ−ｅにおけるそれぞれのサーバは、少なくとも１つの仮想マシン１１２ａ、１１２ｂおよびハイパーバイザ１１３を含むことができる。負荷分散装置１０３は、セキュアなプレーン接続１０４ａ、１０４ｂを介して一連のクラウドサーバ１１４ａ−ｅにおけるそれぞれのサーバと接続することができる。インスタンス管理装置１１０は、セキュアなプレーン接続１１５ａ、１１５ｂを介して一連のクラウドサーバ１１４ａ−ｅに接続することができる。

上述したように、企業拡張ネットワーク１００は、少なくとも１つのプライベート企業ネットワーク１０１およびクラウドネットワーク１０２を含むことができる。例示された環境は直接接続された構成要素を示しているが、他の実施形態はサービスプロバイダネットワークを介してプライベート企業ネットワーク１０１とクラウドネットワーク１０２とを接続してもよい。様々な代替実施形態は、プライベート企業ネットワーク１０１内に、複数のサイトにわたって分割され、サービスプロバイダネットワークを介して接続されるリソース（以下、「内部リソース」と称する）を有することができる。また、様々な代替実施形態は、相互に関連していなくてもよい複数のクラウドネットワーク１０２に接続するプライベート企業ネットワーク１０１を有することができる。

プライベート企業ネットワーク１０１は、一連のサーバ１１１ａ−ｃを含むことができ、クラウドネットワーク１０２は、一連の「クラウド」サーバ１１４ａ−ｅを含むことができる。クラウドサーバ１１４ａ−ｅは、仮想マシン１１２ａ、１１２ｂのインスタンスをホスティングすることができる。仮想マシン１１２ａは、顧客によって制御されるクラウドサーバ１１４ｄ上のインスタンスであってもよい。顧客は、任意の数の仮想マシン１１２ａ、１１２ｂを自由に作成し、使用し、終了する能力を有することができる。顧客に割り当てられた仮想マシン１１２ａ、１１２ｂは、クラウドネットワーク１０３内で互いに論理的に接続されてもよい。

ハイパーバイザ１１３は、クラウドネットワーク１０３におけるそれぞれの仮想マシン１１２ａ、１１２ｂをホスティングすることができる。それぞれのサーバは、１つのハイパーバイザ１１３および少なくとも１つの仮想マシン１１２ａをホスティングすることができる。したがって、ハイパーバイザ１１３は、２つ以上の仮想マシン１１２ａ、１１２ｂをホスティングすることができる。ハイパーバイザ１１３は、ハイパーバイザ１１３が管理する仮想マシン１１２ａ、１１２ｂから来るトラフィックおよびハイパーバイザ１１３が管理する仮想マシン１１２ａ、１１２ｂに向けられるトラフィックを管理することができる。

サーバ１１１ａ−ｃ、１１４ａ−ｅのいずれの組も、企業拡張ネットワーク１００の利用可能なコンピューティングリソースを含むことができる。これらのコンピューティングリソースは、例えば、処理容量、帯域幅、および記憶容量を表し得る。図１は、一連の１１１ａ−ｃ、１１４ａ−ｅにおけるそれぞれのサーバを互いに直接接続されるものとして示しているが、代替実施形態は、他のデバイスを介して接続されたサーバ１１１ａ−ｃ、１１４ａ−ｅの少なくともいくつかを有することもできる。これらのデバイスとして、スイッチおよびルータなどのネットワーキングデバイスを挙げることができる。プライベート企業ネットワーク１０１における一連のサーバ１１１ａ−ｃは、負荷分散装置１０３に動作可能に接続されてもよい。

例示の実施形態では、負荷分散装置１０３は、機械可読媒体上に格納されたハードウェアおよび／または機械実行可能命令を含むモジュールであってもよい。負荷分散装置１０３は、プライベート企業ネットワーク１０１における一連のサーバ１１１ａ−ｃと接続することができ、セキュアなデータプレーン接続１０４ａ、１０４ｂを介してクラウドネットワーク１０２における一連のサーバ１１４ａ−ｅに接続することができる。負荷分散装置１０３は、少なくとも１つのサーバリスト１０５および負荷分散モジュール１０６を含むことができる。サーバリスト１０５は、プライベート企業ネットワーク１０１における一連の１１１ａ−ｃおよびクラウドネットワーク１０２における一連の１１４ａ−ｅの中の、いつでもアクティブである全てのサーバのリストであってもよい。

負荷分散モジュール１０６は、内部サーバ１１１ａ−ｃおよび／または一連のクラウドサーバ１１４ａ−ｅの間で、要求の形で作業を分配することができる。負荷分散モジュール１０６は、例えば、加重ラウンドロビン、最小接続、または最速処理などの、作業を分配するいくつかの方法のうちの１つまたは複数を使用することができる。例えば、「加重ラウンドロビン」方法は、収集されたパフォーマンスメトリックを使用して、それぞれのアクティブなサーバ１１１ａ−ｃ、１１４ａ−ｅに加重を割り当てることができ、より大きい負荷を処理することができるこれらのサーバに余分の作業を割り当てながら、交代制で作業を分配する。「最小接続」は、収集されたパフォーマンスメトリックを使用して、最小の未処理の接続および／または要求を有するサーバ１１４ａを選択することができ、「最速処理」手順は、収集されたパフォーマンスメトリックを使用して、最も遅い応答時間を有するサーバ１１４ａを選択することができる。要求は、例えば、ＨＴＴＰ要求であってもよく、負荷分散装置１０３が要求を転送した際のサーバ１１４ａの作業負荷を表し得る。全ての要求は、負荷分散装置１０３を通過することができる。

全ての要求は負荷分散装置１０３を通過することができるので、負荷分散装置１０３はシステムパフォーマンスパラメータを追跡することもできる。これらのパラメータとして、例えば、未処理の要求の数、１秒毎の完了した要求の平均数、および応答時間を挙げることができる。応答時間は、負荷分散装置１０３がクライアントデバイスから要求を受信してから、負荷分散装置１０３がサーバ１１４ａから対応する応答の最終パケットを受信するまでに経過した時間として定義され得る。また、代替の応答時間測定値は、クライアントデバイスが要求を送信してから、クライアントデバイスがサーバ１１４ａから応答の最終パケットを受信するまでに経過した時間として定義され得る。

図１の例示の実施形態では、制御装置１０７は、負荷分散装置１０３とは別にスケーリング機能を実行するモジュールである。一実施形態では、そのような分離により、単一スレッドの負荷分散装置が過負荷になるのを防止することができる。制御装置１０７は、少なくとも３つのモジュール、すなわち、パフォーマンス監視装置１０８、スケーリング管理装置１０９、およびインスタンス管理装置１１０を含むことができ、これらのモジュールは、制御装置１０７内で直列に接続され得る。また、制御装置１０７は、例えば、定義された閾値を越えるサーバの応答時間などのトリガが起動されたときに、コールバック機能を登録することができる。

パフォーマンス監視装置１０８は、ハードウェアおよび／または機械可読媒体上に格納された機械実行可能命令を含むモジュールであってもよく、負荷分散装置１０７によって転送されたパフォーマンスデータを収集し、引き続いて、転送されたパフォーマンスメトリックに基づいてシステムパフォーマンスを計算して、１秒毎の完了した要求の平均数、応答時間などの計算されたメトリックを生成する。パフォーマンス監視装置１０８は、ネットワーク特有のメトリック（例えば、内部応答時間、クラウド応答時間など）の追跡に加えて、個々のサーバ１１４ａ−ｅおよびＶＭ１１２ａ、１１２ｂのパフォーマンスを追跡することができる。

インスタンス管理装置１１０は、ハードウェアおよび／または機械可読媒体上に格納された機械実行可能命令を含むモジュールであってもよく、クラウドネットワーク１０２に配置された一連のサーバ１１４ａ−ｅにおけるＶＭインスタンス１１２ａ、１１２ｂを管理する。インスタンス管理装置は、クラウドネットワーク１０３に配置された一連のサーバ１１４ａ−ｅに直接接続されてもよい。インスタンス管理装置は、セキュアな制御プレーン接続１１５ａ、１１５ｂを介してクラウドネットワーク１０３に配置された一連のサーバ１１４ａ−ｅに直接接続されてもよい。インスタンス管理装置１１０がクラウドにおけるサーバ１１４ｄに対して、例えば、新規のＶＭ１１２ｂを開始するまたはサーバ１１４ｂを終了するなどの任意の構成変更を行う場合、インスタンス管理装置１１０は負荷分散装置１０３におけるサーバリスト１０５を直接更新することができる。

スケーリング管理装置１０９は、ハードウェアおよび／または機械可読媒体上に格納された機械実行可能命令を含むモジュールであってもよく、いつでも使用されているクラウドリソースを調整すべきかどうかを評価する。スケーリング管理装置１０９は、弾性的な要求または非弾性的な要求に応答することができる。弾性的な要求は、一定の時間内で満足させる必要がない要求として定義され得る。弾性的な要求に応答する際、制御装置１０７は、未処理の要求の数を監視し、スケーリング管理装置１０９を使用して、使用される仮想マシン１１２ａ、１１２ｂの数を未処理の要求の数に基づいて増加させるか減少させることができる。

非弾性的な要求は、一定の時間内で満足させる必要がある要求とすることができる。非弾性的な要求に応答する際、制御装置１０７は、スケーリング管理装置１０９を介して、例えば、現在のサーバ負荷、平均応答時間、および定義された閾値を越える応答時間を有する要求の数を含む複数の要素のうちの少なくとも１つを使用することができる。そのような要素に基づいて、スケーリング管理装置１０９は、現在アクティブなサーバ１１１ａ−ｃ、１１４ａ−ｅ上の仮想マシン１１２ａ、１１２ｂを使用するアプリケーションパフォーマンスが目標値を満たすことができないときに、アクティブなインスタンスの数を増加させることを決定することができる。あるいは、スケーリング手順は、合計システム負荷が目標の閾値の一部分を下回ったときに、インスタンスの数を減少させることができる。

図２は、企業拡張システムの例示の代替実施形態である。この代替実施形態では、プライベート企業ネットワーク１０１における負荷分散装置１０３（企業負荷分散装置）に加えて、クラウドネットワーク１０２における第２の負荷分散装置２０３（クラウド負荷分散装置）がある。例示された実施形態では、クラウド負荷分散装置２０３は、負荷分散モジュール２０６、スケーリング管理装置２０９、およびインスタンス管理装置２１０をホスティングする。

例示の実施形態では、プライベート企業ネットワーク１０１は、制御装置１０７をホスティングすることもでき、制御装置１０７は、全てのＶＭインスタンス１１２ａ、１１２ｂが任意の時点で必要ではないと判定したときに、クラウド負荷分散装置２０３を自動的に終了することができる。企業負荷分散装置１０３は、セキュアなプレーン接続２０４を介して、クラウド負荷分散装置２０３と接続することができる。図２では、一連のサーバ１１４ａ−ｃおよびクラウド負荷分散装置２０３を含むクラウドネットワーク１０２のクラウドリソースは、企業負荷分散装置１０３にとっては、単一のサーバであるように見える。企業負荷分散装置１０３は、サーバリスト１０５および負荷分散モジュール１０６を維持し、例示の実施形態では、企業負荷分散装置１０３は、内部サーバ１１１ａ−ｃの負荷を分散するが、クラウド負荷分散装置２０３は、クラウドサーバ１１４ａ−ｅ上でホスティングされているＶＭ１１２ａ、１１２ｂの負荷を分散することができる。

図３は、要求をサーバに送る例示的な方法３００の流れ図である。様々な例示的な実施形態では、図３の処理は負荷分散モジュール１０６によって実行され得る。方法３００を実行するための他の適切な構成要素は、当業者には明らかであろう。

ステップ３０１では、一組の基準を負荷分散モジュール１０６によって使用して、意思決定のための規則を策定することができる。そのような基準として、企業ネットワーク１０１（内部）におけるサーバ１１１ａ−ｃおよびクラウドネットワーク１０２（クラウド）におけるサーバ１１４ａ−ｅの両方について、例えば、１秒毎のサーバ１１４ｂによって完了された要求の平均数、およびサーバ１１４ｂに対する応答時間などの上述のパフォーマンスメトリックを挙げることができる。決定のための他の基準として、エネルギー使用量および／または内部サーバ負荷に由来し得る内部コストを挙げることができる。決定のための基準として、クラウドサービスプロバイダによって課される料金に由来し得るクラウドコストを挙げることもできる。クラウドサービスプロバイダによって課されるこれらの料金は、帯域幅、プロセッサ、および記憶装置の使用ならびに接続されたアクティブな時間に由来し得る。

このことから、顧客は、負荷分散モジュール１０６のための規則を策定して、どのネットワークサーバ１１１ａ−ｃ、１１４ａ−ｅが要求を受信するべきかを決定することができる。いくつかの実施形態では、顧客は、負荷分散モジュール１０６のための規則を策定して、どの特定のサーバ１１１ａまたは仮想マシン１１２ａが要求を受信するべきかを決定することができる。一例として、顧客は好みに基づく決定を行って、内部応答時間が定義された閾値を越えたときなど、サーバ１１１ａ−ｃがこれ以上負荷を処理することができなくなるまで、要求を常に内部サーバ１１１ａに送信するように決定することができる。他の規則として、全体的なシステムパフォーマンス（最小の相対応答時間を有する、ネットワーク内のサーバを選択する）、１ドル当たりのシステムパフォーマンス（最も低いコストで除算した応答時間を有する、ネットワーク内のサーバを選択する）、および要求毎に生じた収益（サービス提供された要求毎に発生した最大の純収益を有する、ネットワーク内のサーバを選択する）を挙げることもできる。

ステップ３０２では、負荷分散モジュール１０６は、負荷分散機能を使用して、どの特定のサーバ１１１ａ−ｃ、１１４ａ−ｅが要求を受信するべきかを判定する。例を用いて続けると、顧客が、要求は利用可能な場合は常に内部リソースを使用するべきであると規定する決定規則を使用する場合、負荷分散モジュール１０６はこの規則を参照して、過負荷または最適以下のシステムパフォーマンスを示し得る閾値に達するまで、入ってくる要求を内部サーバ１１１ａに送信する。

ステップ３０３では、負荷分散モジュール１０６は、ステップ３０２で判定された決定に基づいて、要求を判定されたネットワーク１０１、１０２におけるサーバ１１１ａ−ｃ、１１４ａ−ｅに送る。例えば、決定規則が内部サーバ１１１ａ−ｃが要求を処理すべきであると判定した場合、負荷分散モジュール１０６は、要求をプライベート企業ネットワーク１０１におけるサーバ１１１ａに送ることができる。負荷分散モジュール１０６は、負荷分散方法を使用して、特定のネットワーク１０１内のサーバ１１１ａ−ｃの間で作業を分配することができる。負荷分散モジュール１０６は、例えば、上述した加重ラウンドロビン、最小接続、および最速処理などの、いくつかの分配方法のうちの少なくとも１つまたは組合せを使用することができる。

方法３００の一例として、負荷分散モジュール１０６は、内部サーバ１１１ａ−ｃを最初に使用する決定規則および最速処理の負荷分散方法を組み込むことができる。負荷分散モジュール１０６は最初に、意思決定規則を作成するための基準をユーザから受信する。決定規則は、応答時間が閾値に等しいときにのみ、負荷分散モジュール１０６が要求をクラウドサーバ１１４ａ−ｅに送信するように、閾値に達するまで内部サーバを使用するためのものであってもよい。

負荷分散モジュール１０６が決定規則を設定した後、負荷分散モジュール１０６は、要求を受信する際に、決定規則を参照して内部サーバ１１１ａ−ｃおよびクラウドサーバ１１４ａ−ｅの中から特定のサーバを選択し、要求を受信する。この例では、応答時間が閾値を越えているので、決定規則は、負荷分散モジュール１０６は要求をクラウドサーバ１１４ａ−ｅに転送すべきであると判定する。その後、負荷分散モジュール１０６は「最速処理」の負荷分散方法を使用して、クラウドネットワーク１０２におけるどのサーバ１１４ａ−ｅが要求を受信するべきかを決定することができる。「最速処理」負荷分散方法は、パフォーマンス監視装置１０８によって収集されたパフォーマンスデータを使用して、クラウドサーバ１１４ｄが最も少ない応答時間で要求に応答すると判定する。したがって、負荷分散モジュール１０６は、要求をクラウドサーバ１１４ｄに転送する。

図４は、少なくとも１つのサーバを追加することによって企業拡張ネットワークを拡大する例示的な方法４００の流れ図である。様々な例示的な実施形態では、図４の処理は、制御装置１０７内部の様々な構成要素によって実行され得る。方法４００を実行するための他の適切な構成要素は、当業者には明らかであろう。拡大の決定は、企業ネットワーク１００内のアプリケーションパフォーマンスが所定の目標を満たさないときに行われ得る。

目標は、応答時間が時間閾値を越える要求の数（または一部分）などのパフォーマンス目標であってもよい。別の目標は、例えば、平均応答時間または定義された閾値を越えるサーバ負荷であってもよく、その場合、平均応答時間は、経時的に平均された、１秒毎の処理された要求の数として測定され得る。これらの目標定量化が特定の閾値に達したとき、ステップ４０１が生じる場合があり、このとき、スケーリング管理装置１０９はパフォーマンスを不適切とみなし得る。例えば、スケーリング管理装置１０９は、システム全体の平均応答時間（指数関数的な移動平均）が閾値を越えたとき、または過度の応答時間の割合が定義された閾値数を越えたときにのみ、拡大することを決定することができる。

ステップ４０２では、パフォーマンス監視装置１０８は、任意の新規のサーバ１１１ａ−ｃ、１１４ａ−ｅがシステムに追加される前に、現在アクティブであるそれぞれのサーバ上の負荷を記録する。以下により詳細に説明されるように、この記録は、別の時点でインスタンス管理装置１１０によって使用されて、企業ネットワークを縮小する間に、無関係なサーバ１１１ａ−ｃ、１１４ａ−ｅを排除することができる。

ステップ４０３では、スケーリング管理装置１１０は、必要となる追加のサーバの数（Ｎ）を推定することができる。新規のサーバ１１１ｂ、１１１ｃは、プライベート企業ネットワーク１０１またはクラウドネットワーク１０２に由来し得る。スケーリング管理装置１０９は、必要な追加スループットの量をクラウドネットワーク１０２における使用中のサーバ１１４ａ、１１４ｂ上の仮想マシン（ＶＭ）１１２ａ、１１２ｂの平均スループット

で除算することによって、必要となるサーバ１１１ａ−ｃ、１１４ａ−ｅの数を推定することができる。サーバのスループットは、応答時間を閾値Ｔ_ｈ未満に維持しながらサーバが処理することができる最大負荷である。

は、現在アクティブなクラウドサーバの数で除算した、アクティブなクラウドサーバ１１４ａ、１１４ｂのスループットの合計に等しくてもよい。

ステップ４０４では、スケーリング管理装置１０９は、Ｎ回実行するループを開始することができ、ここで、Ｎは必要な追加のサーバの数である。したがって、この処理を開始するために、スケーリング管理装置１０９は変数ｊを１に初期化することができる。ステップ４０４では、スケーリング管理装置１０９は最初に、ｊが必要なサーバの数Ｎ未満であるか、必要なサーバの数Ｎに等しいかを判定することができる。ｊがＮより大きいとき、ステップ４０５が続いて生じ、ここで、スケーリング管理装置１０９はサーバの合計数をＮだけ増分することができる。

あるいは、ｊがＮ未満またはＮに等しいとき、ステップ４０６に続くことができる。ステップ４０６では、インスタンス管理装置１１０は、追加されるべきｊ番目の仮想マシンがチョークポイントであるかどうかを判定するよう試行することができる。チョークポイントは、ボトルネックを体験しているサーバ、またはパフォーマンス（例えば、アプリケーション処理）もしくはネットワーク全体の能力を制限している一構成要素もしくは構成要素のグループであってもよい。新規のサーバが企業ネットワーク内のチョークポイントであるかどうかを判定するために、負荷分散装置は、要求の小さいセットを新規のサーバ１１４ｄに送信することができる。次いで、負荷分散装置１０３はサーバ１１４ｄの応答時間を監視する。

新規のサーバからの応答時間が現在使用中の仮想マシン１１６ａ−ｄの平均最小応答時間より大きいか、これに等しいとき、スケーリング管理装置１０９は、新規のサーバを追加することはほとんど利点をもたらさないと判定することができる。また、スケーリング管理装置１０９は、システムの合計スループットが新規のサーバの追加に応答して増加しないとき、またはスループットの増加が実質的に

よりも少ない場合、この判定を行うことができる。これらの状況のそれぞれにおいて、スケーリング管理装置１０９は、（サーバ自体またはシステムの他の部分のいずれかにおいて）新規のサーバに関連するチョーキングポイントがあると判定することができる。

ステップ４０６で、新規の見込みサーバ１１４ｄに課された新規の負荷によってサーバ１１４ｄがチョークポイントになる場合、ステップ４１０では、ｃｈｏｋｅ＿ｖｍカウンタが増加し、サーバは追加されない。ステップ４１１で、ｃｈｏｋｅ＿ｖｍカウンタが所定の閾値を越えたとき、スケーリング管理装置１０９は、企業ネットワークがチョークしていると判定し、ステップ４１２では、インスタンス管理装置１１０が負荷分散装置１０３に信号を送って、システムが再びシステム負荷を処理できる程度に至るまで、要求をドロップする。そうでなければ、スケーリング管理装置１０９がステップ４１１においてチョーク閾値を越えなかったと判定するとき、スケーリング管理装置はステップ４０９において１だけｊを増分し、ステップ４０４に戻る。

ステップ４１０において説明したように、ｃｈｏｋｅ＿ｖｍカウンタは、一部のサーバのみが応答しないとき、それによってスケールアップを可能にすることができる。言い換えれば、チョークしているＶＭの数をカウンタに追跡させ続けることによって、制御装置１０７が単に単一のＶＭ１１２ｂの挙動に基づいてシステム全体をチョークしているとしてラベル付けするのを防止することができる。

ステップ４０６に戻ると、チョークポイントが検出されない場合、方法はステップ４０７に進み、ここで、インスタンス管理装置１１０は新規のサーバ１１４ｄを追加することができる。あるいは、試験されている特定のサーバが以前に（例えば、スケールダウン操作に基づいて）削除の印を付けられた場合、インスタンス管理装置１１０はそのサーバを復活させることができる。ステップ４０８では、負荷分散装置１０３は、新規のサーバ１１４ｄに毎秒

の要求を転送する。次いで、方法４００は、ｊを１だけ増分してステップ４０４に戻ることによって、ステップ４０９へのループをたどって進み、追加のサーバが処理を必要とするかどうかを判定する。

図５は、企業ネットワークを縮小する例示的な方法５００の流れ図である。様々な例示的な実施形態では、図３の処理は、制御装置１０７内部の様々な構成要素によって実行され得る。方法３００を実行するための他の適切な構成要素は、当業者には明らかであろう。

ステップ５０１では、パフォーマンス監視装置１０８は、合計システム負荷を、それぞれのアクティブなサーバ１１１ａ−ｃ、１１４ａ−ｅのスループットの合計であってもよい合計スループット

と比較する。応答時間の９８％が閾値未満であるときなど、合計負荷が閾値未満である場合、ステップ５０２で、インスタンス管理装置１１０によってサーバ１１４ｄまたはＶＭ１１２ｂに終了の印を付けることができる。任意の時点で、インスタンス管理装置１１０によって２つ以上のＶＭ１１２ａ、１１２ｂまたはサーバ１１４ｄ、１１４ｅに終了の印を付けることができる。

インスタンス管理装置１１０は、印を付けられたデバイスでの全ての未処理の処理が終了するのを待ってから、ＶＭ１１２ｂまたはサーバ１１４ｄをシャットダウンすることができる。インスタンス管理装置１１０は、選択を行うときに所定の基準を使用することができる。例えば、クラウドサービスプロバイダがその時間だけＶＭ使用に課金する場合、ユーザはインスタンス管理装置１１０のための基準を設定して、その時間の残りの時間内でその負荷を終了する最大確率を有するＶＭ１１２ｂを選択することができる。

ステップ５０３では、負荷分散モジュール１０６は、残りのアクティブなサーバの間でトラフィックを再分配する。負荷分散モジュール１０６は、現在のサーバ負荷、平均応答時間、および定義された閾値を越える応答時間を有する要求の数などのパフォーマンスメトリック、ならびに加重ラウンドロビン、最小接続、および最速処理などの負荷分散方法を使用して、内部ネットワーク１０１およびクラウドネットワーク１０２における残りのサーバ１１１ａ−ｃ、１１４ａ−ｅの間で、残りの負荷を分散することができる。

上記によれば、様々な例示的な実施形態は、企業拡張ネットワーク内のサーバ間で、要求の動的でシームレスな負荷分散を提供する。また、そのような負荷分散は、プライベート企業ネットワーク内のサーバとクラウドネットワーク内のサーバの両方を効率的に使用しながら、サーバを使用するコストを含む複数の要素に基づいて、クラウドネットワークのサーバの使用を最適化することができる。クラウドサーバの効率的な使用に関連して、諸実施形態は、システムの拡大ニーズまたは縮小ニーズに基づいて、クラウドネットワーク内の仮想マシンの動的な追加および終了を実現する動的なオートスケーラを提供することもできる。負荷分散装置およびオートスケーラにより、ユーザは、パフォーマンスの観点およびコストの観点の両方において、クラウドリソースを効率的に消費することができる。

本発明の様々な例示的な実施形態がハードウェアおよび／またはファームウェアにおいて実施され得ることは、前述の説明から明らかであるはずである。さらに、様々な例示的な実施形態は、少なくとも１つのプロセッサによって読み取られ実行されて、本明細書において詳細に説明した動作を実行することができる、機械可読記憶媒体上に格納された命令として実施され得る。機械可読記憶媒体は、機械によって読取り可能な形で情報を格納するための任意の機構を含むことができる。したがって、機械可読記憶媒体として、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、および類似の記憶媒体を挙げることができる。

様々な例示的な実施形態について、その特定の例示的な態様を特に参照しながら詳細に説明してきたが、本発明は他の実施形態を受け入れる余地があり、その詳細は様々な明白な点における修正を受け入れる余地があることを理解されたい。当業者には容易に明らかとなるように、本発明の精神および範囲内に維持しながら、変形および修正に影響を及ぼすことができる。したがって、前述の開示、説明、および図は、例示のみを目的とするものであり、いかなる方法によっても本発明を限定せず、本発明は、特許請求の範囲によってのみ定義される。

Claims (10)

1. プライベート企業ネットワークに割り当てられたクラウドネットワーク内のリソースを管理するためのシステムであって、
   プライベート企業ネットワークに割り当てられたクラウドネットワーク内の仮想マシンを含む第１の一連のサーバと、
   プライベート企業ネットワーク内のコンピューティングリソースを含む第２の一連のサーバと、
   第１および第２の一連のサーバのパフォーマンスデータに基づいて第１および第２の一連のサーバにおけるメンバ間で作業を分配するための、プライベート企業ネットワーク内の負荷分散装置と、
   第１および第２の一連のサーバのパフォーマンスデータを収集するためのパフォーマンス監視装置を備える、プライベート企業ネットワーク内の制御装置と
   を備える、システム。
2. 第１の一連のサーバのメンバ間で作業を分配するための、クラウドネットワーク内の第２の負荷分散装置であって、プライベート企業ネットワーク内の第１の負荷分散装置が、第２の負荷分散装置をクラウドネットワーク内の単一のサーバとして識別し、第２の負荷分散装置に作業を分配する、第２の負荷分散装置
   をさらに備える、請求項１に記載のシステム。
3. 制御装置が、
   第１の一連のサーバにサーバを追加するまたは第１の一連のサーバからサーバを削除するときを決定するためのスケーリング管理装置であって、スケーリング管理装置による決定がユーザ指定の基準に基づく、スケーリング管理装置と、
   スケーリング管理装置の決定に基づいて、第１の一連のサーバにサーバを追加するまたは第１の一連のサーバからサーバを削除するためのインスタンス管理装置と
   をさらに備える、請求項１に記載のシステム。
4. 企業ネットワーク内の作業負荷を管理するための負荷分散装置であって、
   プライベート企業ネットワークに割り当てられたクラウドネットワーク内の第１の一連のサーバおよびプライベート企業ネットワーク内の第２の一連のサーバの間で作業要求を送るための負荷分散モジュールと、
   第１および第２の一連のサーバからパフォーマンスデータを収集することによって、企業ネットワークを備えるサーバのパフォーマンスを追跡するための監視モジュールと、
   第１の一連のサーバおよび第２の一連のサーバにおけるそれぞれのサーバのエントリを備えるサーバリストであって、負荷分散装置が、少なくとも１つのデータプレーン接続を介して第１の一連のサーバに接続する、サーバリストと
   を備える、負荷分散装置。
5. 企業ネットワーク内のリソースを管理するための制御装置であって、
   プライベート企業ネットワークに割り当てられたクラウドネットワーク内の第１の一連のサーバおよびプライベート企業ネットワーク内の第２の一連のサーバの中でアクティブであるべきサーバの数を判定するためのスケーリング管理装置であって、判定が第１および第２の一連のサーバのパフォーマンスに基づく、スケーリング管理装置と、
   スケーリング管理装置の決定に基づいて、第１の一連のサーバに少なくとも１つのサーバを追加するまたは第１の一連のサーバから少なくとも１つのサーバを削除するためのインスタンス管理装置と
   を備える、制御装置。
6. 第１および第２の一連のサーバのパフォーマンスデータを収集し、収集されたパフォーマンスデータに基づいて計算されたパフォーマンスメトリックをスケーリング管理装置に提供するためのパフォーマンス監視装置
   をさらに備える、請求項５に記載の制御装置。
7. インスタンス管理装置が、少なくとも１つの制御プレーン接続を介して第１の一連のサーバに接続する、請求項５に記載の制御装置。
8. 企業ネットワーク内のサーバに作業要求を送信する方法であって、
   負荷分散装置によってホスティングされている負荷分散モジュールによって、ユーザによって指定された基準に基づいて要求決定規則を策定するステップと、
   負荷分散モジュールによって、宛先サーバを選択するステップであって、宛先サーバが、負荷分散モジュールによる決定規則の実行によって、負荷分散装置によってホスティングされているサーバリストから選択される、ステップと、
   負荷分散モジュールによって、作業要求を宛先サーバに送るステップと
   を備える、方法。
9. 少なくとも１つのサーバを企業ネットワークに追加する方法であって、
   制御装置によって、プライベート企業ネットワークを備える企業ネットワーク内でアプリケーションが動作しており、クラウドネットワークの割り当てられた部分が閾値パフォーマンスメトリック未満で動作していることを判定するステップと、
   制御装置によって、閾値を上回ってアプリケーションのパフォーマンスメトリックを上昇させるプライベート企業ネットワークに割り当てられたクラウドネットワーク内の一連のサーバに追加すべき、クラウドネットワーク内のサーバの数を判定するステップと、
   制御装置によって、少なくとも１つの新規のサーバを開始するステップであって、制御装置が、開始されるサーバの数を判定する、ステップと、
   制御装置によって、チョークポイントについてクラウドネットワーク内の一連のサーバを確認するステップと、
   制御装置によって、企業ネットワークを監視してクラウドネットワーク内の一連のサーバにサーバを追加するかクラウドネットワーク内の一連のサーバからサーバを削除するかを判定するステップと
   を備える、方法。
10. 企業ネットワークからサーバを削除する方法であって、
    制御装置によって、企業ネットワークに割り当てられたクラウドネットワーク内の第１の一連のサーバおよびプライベート企業ネットワーク内の第２の一連のサーバを備える企業ネットワークの作業負荷を企業ネットワークの合計スループットと比較するステップと、
    制御装置によって、合計システム作業負荷が企業ネットワークの合計スループットの閾値を下回るときに、第１の一連のサーバにおける少なくとも１つのサーバに終了の印を付けるステップと、
    制御装置によって、第１の一連のサーバから印を付けたサーバを削除するステップと、
    負荷分散装置モジュールによって、制御装置によって終了されなかった第１および第２の一連のサーバの間で一連の作業要求を送るステップと
    を備える、方法。

Images