JP2015503781A - エネルギー効率の良い分散型でエラスティックなロードバランシングのための方法および装置 - Google Patents

Abstract

様々な実施形態は、エネルギー効率およびスケーラビリティを向上させるために負荷全体に適応し、負荷に伴う電力消費量をスケーリングするロードバランシング構成を提供する方法および装置を提供する。エネルギー効率の良い分散型でエラスティックなロードバランシングアーキテクチャは、ツリー構成として構造化された多層サーバの集合を含む。着信するサービス要求の取扱いは、複数のサーバの間で分散される。仮想負荷分散ツリー内の各サーバは、それ自体の負荷に基づいて着信するサービス要求を受け入れ、取り扱う。一旦、受信側サーバ上で所定のローディングに達すると、受信側サーバは、それ自体の子サーバのうちの１つまたは複数に着信する要求を渡す。

Description

本発明は、全体としてサーバロードバランシングを提供するための方法および装置に関する。

この項では、本発明をより良く理解することを手助けする際に役立つことがある態様を紹介する。したがって、この項の記述は、この観点から読まれるべきであり、何が従来技術にあるかまたは何が従来技術にないかに関する承認された事実として理解されるべきではない。

いくつかの知られたロードバランシングシステムでは、サービスは、高スループットおよび短い応答時間などの高い品質のサービスを提供するために複数のサーバをホストとすることがある。典型的なアーキテクチャは、フロントエンドロードバランサおよび一定数のバックエンドサーバを含むことができる。フロントエンドロードバランサは：ランダム、ラウンドロビン、または負荷に基づく分配、などの従来型の分配ポリシを使用して異なるサーバへ着信する要求を分散させる専用のハードウェアボックスであり得る。このモデルにおいては、全サーバノードはアクティブであり、サービス要求に対してサービスを返す準備ができている。

他の知られたロードバランシングシステムでは、フロントエンドロードバランサは、サーバが低エネルギー状態にとどまるようなより多くの機会を作り出すために、負荷が最も高いサーバがパフォーマンス制約を満足することができる限りその負荷が最も高いサーバに新しい要求を送る。しかしながら、多数の異種のサーバの負荷を追跡するには、高度で高価なフロントエンドロードバランサが必要となるので、この解決策はスケーラブルではない。

様々な実施形態は、エネルギー効率およびスケーラビリティを向上させるために負荷全体に適応し、負荷に伴う電力消費量をスケーリングするロードバランシング構成を提供する方法および装置を提供する。エネルギー効率の良い分散型でエラスティックなロードバランシングアーキテクチャは、ツリー構成として構造化された多層サーバの集合を含む。着信するサービス要求の取扱いは、多数のサーバの間で分散される。仮想負荷分散ツリー内の各サーバは、それ自体の負荷に基づいて着信するサービス要求を受け入れる。一旦、受信側サーバ上で所定のローディングに達すると、受信側サーバは、それ自体の子サーバのうちの１つまたは複数に着信する要求を渡す。

一実施形態では、親サーバにおいてエネルギー効率が良くかつエラスティックなロードバランシングを提供するための方法が提供される。本方法は：１つまたは複数のクライアントによってインスタンス化された複数のサービス要求を受信するステップと、サービス要求に基づいて複数のサービス要求の少なくとも一部に対応する複数のサービス取扱い判断を決定するステップと、サービス取扱い判断のうち第１の判断に基づいて子サーバを選択し、第１のサービス取扱い判断に対応する第１のサービス要求に基づいて第１の伝達されたサービス要求を送信するステップと、サービス取扱い判断のうち第２の判断に基づいて親サーバを選択し、第２のサービス取扱い判断に対応する第２のサービス要求を取り扱うステップとを含む。

いくつかの実施形態では、第２のサービス要求を取り扱うステップの行為は、第２のサービス要求のインスタンス化側クライアントに直接応答するステップを含む。

いくつかの実施形態では、本方法は：複数のサービス要求のうちの少なくとも１つに基づいて親サーバのローディングを示す親負荷を決定するステップと、親負荷およびサーバ負荷しきい値に基づいて親サーバの少なくとも１つの子サーバを起動させるステップとをも含む。

いくつかの実施形態では、本方法は：複数のサービス要求のうちの少なくとも１つに基づいて親サーバのローディングを示す親負荷を決定するステップと、親サーバの親である親−親サーバのローディングを示す親−親負荷を受信するステップと、親負荷、親−親負荷および親−親負荷しきい値に基づいて親サーバの動作をスリープモードに切り換えるステップとをさらに含む。

いくつかの実施形態では、本方法は：子サーバおよび第１のサービス要求に基づく少なくとも１つの関係する選択パラメータを登録するステップと、複数のサービス要求のうちの第３のサービス要求および少なくとも１つの登録した関係する選択パラメータに基づいて子サーバを選択するステップと、第３のサービス要求に基づいて第３の伝達されたサービス要求を送信するステップとをさらに含む。

第２の実施形態では、親サーバにおいてエネルギー効率が良くかつエラスティックなロードバランシングを提供するための装置が提供される。本装置は、データストレージと、データストレージに通信可能につなげられたプロセッサとを含む。プロセッサは：１つまたは複数のクライアントによってインスタンス化された複数のサービス要求を受信し、サービス要求に基づいて複数のサービス要求の少なくとも一部に対応する複数のサービス取扱い判断を決定し、サービス取扱い判断のうち第１の判断に基づいて子サーバを選択し、かつ第１のサービス取扱い判断に対応する第１のサービス要求に基づいて第１の伝達されたサービス要求を送信し、サービス取扱い判断のうち第２の判断に基づいて親サーバを選択し、かつ第２のサービス取扱い判断に対応する第２のサービス要求を取り扱うように構成される。

いくつかの実施形態では、第２のサービス要求を取り扱うことは、プロセッサに：第２のサービス要求のインスタンス化側クライアントに直接応答させるようにさらに構成されることを含む。

いくつかの実施形態では、プロセッサは：複数のサービス要求のうちの少なくとも１つに基づいて親サーバのローディングを示す親負荷を決定し、かつ親負荷およびサーバ負荷しきい値に基づいて親サーバの少なくとも１つの子サーバを起動させるようにさらに構成される。

いくつかの実施形態では、プロセッサは：複数のサービス要求のうちの少なくとも１つに基づいて親サーバのローディングを示す親負荷を決定し、親サーバの親である親−親サーバのローディングを示す親−親負荷を受信し、親負荷、親−親負荷および親−親負荷しきい値に基づいて親サーバの動作をスリープモードに切り換えるようにさらに構成される。

いくつかの実施形態では、１０プロセッサは：子サーバおよび第１のサービス要求に基づく少なくとも１つの関係する選択パラメータを登録し、複数のサービス要求のうちの第３のサービス要求および少なくとも１つの登録した関係する選択パラメータに基づいて子サーバを選択し、第３のサービス要求に基づいて第３の伝達されたサービス要求を送信するようにさらに構成される。

いくつかの実施形態では、子サーバの選択は、子サーバの子サーバ負荷の割合および親サーバの少なくとも１つの他の子サーバに対応する少なくとも１つの他の子サーバ負荷に基づく。

第３の実施形態では、エネルギー効率が良くかつエラスティックなロードバランシングを提供するためのシステムが提供される。本システムは、ネットワークを介して通信可能につなげられ、仮想負荷分散ツリー内に論理的に配置された複数のサーバと、複数のサーバに通信可能につなげられたサービス要求ハンドラとを含む。サービス要求ハンドラは：１つまたは複数のクライアントによってインスタンス化された複数のサービス要求を受信し、サービス要求に基づいて複数のサービス要求の少なくとも一部に対応する複数のサービス取扱い判断を決定し、サービス取扱い判断の第１のものに基づいて子サーバを選択しかつ第１のサービス取扱い判断に対応する第１のサービス要求に基づいて第１の伝達されたサービス要求を送信し、サービス取扱い判断の第２のものに基づいて親サーバを選択しかつ第２のサービス取扱い判断に対応する第２のサービス要求を取り扱う、ように構成される。

いくつかの実施形態では、仮想負荷分散ツリーは、ルートサーバおよび少なくとも２つのレベルのサーバを含む。

いくつかの実施形態では、仮想負荷分散ツリーは、初期遅延の値および複数のサーバの少なくとも一部に関する省エネルギーポテンシャルに基づく。

いくつかの実施形態では、仮想負荷分散ツリーは、予測したシステム負荷に基づく。

いくつかの実施形態では、１つまたは複数のサーバは、仮想マシーンである。

いくつかの実施形態では、本システムは：複数のサーバに通信可能につなげられたサービス要求マネージャも含む。サービス要求マネージャは、仮想負荷分散ツリーを動的にスケーリングするように構成される。

いくつかの実施形態では、１８サービス要求マネージャは：故障したサーバを回復させるようにさらに構成され、複数のサーバが、故障したサーバを含み、故障したサーバの回復が：故障したサーバの役割を引き受けるために選択されるサーバを選択し、複数のサーバが選択されるサーバを含み、故障したサーバの役割を引き受けるために新しいサーバをインスタンス化し、複数のサーバが新しいサーバを含み、１つまたは複数の回復サーバに故障したサーバの負荷を分散させ、複数のサーバが回復サーバを含む、ことのうちの少なくとも１つを含む。

いくつかの実施形態では、本システムは、サービス要求マネージャに通信可能につなげられた共有リソースプールも含む。

いくつかの実施形態では、サービス要求マネージャは、負荷に基づいて共有リソースプールと仮想負荷分散ツリーとの間でサーバを動的に割り当てる。

様々な実施形態が、添付した図面に図示される。

エネルギー効率の良い分散型でエラスティックなロードバランシングアーキテクチャ１１０の実施形態を含むロードバランシングシステム１００の図である。 図１のエネルギー効率の良い分散型でエラスティックなロードバランシングアーキテクチャ１１０の実施形態の図である。 図１の中間バックアップ（ｂａｃｋｕｐ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ）フォワーダ１２０を使用して主バックアップサービスを提供するための方法の実施形態を図示する流れ図である。 図１のサーバ１２０のうちの１つを使用してサービス要求を取り扱うための方法の実施形態を図示する流れ図である。 図１のサーバ１２０のうちの１つの一実施形態のブロックを模式的に図示した図である。

理解を容易にするために、同一の参照番号が、実質的に同じもしくは類似の構造および／または実質的に同じもしくは類似の機能を有する要素を明示するために使用されてきている。

様々な実施形態は、エネルギー効率およびスケーラビリティを向上させるために負荷全体に適応し、負荷に伴う電力消費量をスケーリングするロードバランシング構成を提供する方法および装置を提供する。エネルギー効率の良い分散型でエラスティックなロードバランシングアーキテクチャは、ツリー構成として構造化された多層サーバの集合を含む。着信するサービス要求の取扱いは、多数のサーバの間で分散される。仮想負荷分散ツリー内の各サーバは、それ自体の負荷に基づいて着信するサービス要求を受け入れる。一旦、受信側サーバ上で所定のローディングに達すると、受信側サーバは、１つまたは複数のそれ自体の子サーバに着信する要求を渡す。

都合の良いことに、このエラスティックなロードバランシングアーキテクチャは、システムが変動するシステム負荷を補正することを可能にする。第１に、サーバが所定の負荷に達するまで、サーバはそれ自体の子サーバに着信する要求を渡さないので、子サーバは、エネルギー使用量を削減するために低アクティビティの期間の間スリープ状態にされることがある、または共有リソースプールに再割り当てされることがある。第２に、このエラスティックなロードバランシングアーキテクチャは、不十分なサーバ能力に起因するサービスの拒絶インスタンスを減少させるために、高負荷期間の間には共有リソースプールからサーバへとシステムが子サーバを割り当てることを可能にする。第３に、サーバの間で着信するサービス要求の取扱いを分散させることは、高度化され高価なフロントエンドロードバランサの必要性をなくす。

図１は、エネルギー効率の良い分散型でエラスティックなロードバランシングアーキテクチャ１１０の実施形態を含むロードバランシングシステム１００を図示する。エネルギー効率の良い分散型でエラスティックなロードバランシングアーキテクチャ１１０は、多層サーバ１２０−ａ−１２０−ｇ（包括的に、サーバ１２０）の集合を含む。サーバ１２０は、１つまたは複数のクライアント１５０−ａ−１５０−ｃ（包括的に、クライアント１５０）からサービス要求を受信し、応答する。クライアント１５０からのサービス要求は、ネットワーク接続１３０を介してネットワーク１４０をわたってサーバ１２０に配信される。

サーバ１２０は、要求を取り扱うであろうサーバ１２０へクライアントサービス要求をルーティングするためのインテリジェンスならびにクライアントサーバ要求に応答するためのリソースおよびロジックを含む。サーバ１２０は、少なくとも１つの親サーバ（例えば、サーバ１２０−ａ）および少なくとも１つの子サーバ（例えば、サーバ１２０−ｂと１２０−ｃはサーバ１２０−ａの子サーバである）を有する仮想負荷分散ツリーに構築される。アーキテクチャは、任意の数のツリーレベルを有することができ、各ツリーレベルにおいてツリーの次数（すなわち、サーバのファンアウト）を変えることができる。ツリーは、アンバランスであってもよい。例えば、いくつかの親サーバは、２つの子サーバを有することができるが、他のものは、２つより多いことも少ないこともある子サーバを有することができ、および／またはツリーのいくつかのブランチは、より多くのまたは少ないツリーレベルを有することができる。

本明細書において規定するように、ルートサーバは、仮想負荷分散ツリーの最上位レベルのところのサーバ（例えば、サーバ１２０−ａ）であり、親サーバは、少なくとも１つの子サーバにサービス要求を分配するサーバ（例えば、サーバ１２０−ａ、１２０−ｂおよび１２０−ｃ）であり、子サーバは、親サーバからサービス要求を受信するサーバ（例えば、サーバ１２０−ｂ−１２０−ｇ）であり、リーフサーバは、いかなる子サーバをも持たないサーバ（例えば、サーバ１２０−ｄ−１２０−ｇ）である。

サーバが、親サーバおよび子サーバの両方であり得ることが認識されるはずである。例えば、サーバ１２０−ｂは、サーバ１２０−ａに対して子サーバであり、サーバ１２−ｄおよび１２０−ｅに対して親サーバである。その上、サーバがリーフサーバおよび子サーバの両方であり得ることが認識されるはずである。

ネットワーク接続１３０は：ワイアレス通信（例えば、ＬＴＥ、ＧＳＭ（登録商標）、ＣＤＭＡ、ブルートゥース）、フェムトセル通信（例えば、ＷｉＦｉ）、パケットネットワーク通信（例えば、ＩＰ）、ブロードバンド通信（例えば、ＤＯＣＳＩＳおよびＤＳＬ）、等、などの１つまたは複数の通信チャネルをわたってサービス要求を検索することまたは応答することをサポートすることができる。１つの接続として描かれているが、ネットワーク接続１３０は、サーバ１２０とネットワーク１４０との間の通信をサポートする任意の数の通信チャネルまたは通信チャネルの組合せであってもよいことが認識されるはずである。

ネットワーク１４０は、サーバ１２０からクライアント１５０への通信を容易にするための任意の適切なネットワークであり得る。例えば、ネットワーク１４０は：（１つまたは複数の）ローカルエリアネットワーク（ＬＡＮ）、（１つまたは複数の）ワイアレスローカルエリアネットワーク（ＷＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、等のいずれかの組合せであってもよい。

クライアント１５０は、エネルギー効率の良い分散型でエラスティックなロードバランシングアーキテクチャ１１０に宛てられた（１つまたは複数の）サービス要求を開始する（１つまたは複数の）クライアントマシーンの類型または多数のクライアントマシーンであり得る。例えば、クライアントは：サーバ、携帯電話機、タブレット、コンピュータ、携帯情報端末（ＰＤＡ）、ｅ−リーダ、ネットワークデバイス（例えば、スイッチまたはルータ）、等、であってもよい。

いくつかの実施形態では、サーバ１２０は、初期遅延および省エネルギーポテンシャルなどのパラメータにしたがって仮想負荷分散ツリーに配置される。サーバ１２０の特定の仮想負荷分散ツリー配置の初期遅延および省エネルギーポテンシャルは、仮想負荷分散ツリーの配置および個々のサーバ能力などの多数の要因に基づいて制御されることがある。一般に、多数のサーバ「ｎ」の仮想負荷分散ツリー設計に関して、レベルの数が増加するにつれて、サービス要求をルーティングすることは、複雑でなくなり、エネルギー効率が向上し、初期遅延が大きくなる。例えば、多数のサーバ「ｎ」に関して、１つのルートノードおよび（ｎ−１）個のリーフノードを有する平坦なツリーは、要求中継に起因する最小の遅延を有するが、最も大きな複雑さおよび最悪のエネルギー効率を有する。正反対に、サーバがチェーン（すなわち、各ツリーレベルが１の次数を有する状態の仮想負荷分散ツリー）として構築される場合には、ツリーは、単純でありかつエネルギー効率がよいが、最大の遅延を有する。サーバ１２０が異なるリソース能力を有する場合には、個々のサーバ能力は、ツリー設計に影響を及ぼすことがある。特に、サーバが取り扱うことができるサービス要求の能力に基づいて、サーバは、仮想負荷分散ツリー内に配置されることがある。

いくつかの実施形態では、仮想負荷分散ツリーは、ルートサーバの下に少なくとも２つのレベルを含む。さらなる実施形態では、仮想負荷分散ツリーのあるレベル内のサーバの次数は、予測した負荷に基づいて設計されることがある。図２を参照すると、予測した負荷の日中の推移の例示的なプロットが示される。分かるように、９：００ＡＭと８：００ＰＭとの間の負荷は、１２０個までであると予測される一方で、９：００ＰＭと８：００ＡＭとの間の負荷は、３０個よりも少ないと予測される。この例では、仮想負荷分散ツリーは、ツリーがルートサーバの下に２つのレベルを有するように配置されてもよい。第１のレベルは、３０個よりも少ない負荷を取り扱うように設計されてもよい一方で、第２のレベルは、１２０個までの負荷を取り扱うように設計されてもよい。これは、仮想負荷分散ツリーの第２のレベル用により高い能力を有する個々のサーバを選択することによっておよび／または仮想負荷分散ツリーの第２のレベル用により高い次数（より多くのサーバ）を使用することによって行われてもよい。

いくつかの実施形態では、サーバ１２０は、同種であってもよく、別の実施形態では、サーバ１２０は、異種であってもよい。サーバの複雑さを低く保つことによって、特別なハードウェアが必ずしも必要とされなくてもよいことが認識されるはずである。

いくつかの実施形態では、サーバ１２０は、コスト効率の良いシステムを作り出すために完全に低コスト商品サーバから構成されることがある。サーバ１２０へクライアントサービス要求をルーティングするためのインテリジェンスが複数のサーバ１２０に分散されるので、中央負荷ディストリビュータとして作用する特別のハードウェアボックスについての必要性がないことが認識されるはずである。

いくつかの実施形態では、２つ以上のサーバ１２０が、ＬＡＮを介して相互接続されることがある。いくつかの実施形態では、２つ以上のサーバ１２０が、インターネットなどのＷＡＮをわたって接続されることがある。サーバ１２０の各々が同じ方法でまたは同じタイプの通信チャネルおよび／もしくはプロトコルを介してさえ接続されなければならないことはないことが認識されるはずである。

いくつかの実施形態では、２つ以上のサーバ１２０は、仮想マシーンであってもよい。さらなる実施形態では、仮想マシーンサーバの一部は、同じ物理ハードウェア上に存在することができる。いくつかの実施形態では、１つまたは複数の仮想マシーンサーバは、異なるハードウェアリソースにわたって分散されたリソースを含むことができる。さらなる実施形態では、これらのハードウェアリソースの少なくとも第１の部分は、これらのハードウェアリソースの少なくとも第２の部分とは異なる地理的な場所に設置されることがある。

いくつかの実施形態では、仮想負荷分散ツリーは、負荷に基づいて仮想負荷分散ツリーの配置を動的に大きくするもしくは縮小する（すなわち、サーバを追加するおよび削除する）ためにならびに／または修正するためにスケーリング可能であってもよい。負荷決定は、仮想負荷分散ツリーのシステムローディングおよび／または負荷分散ツリー内の１つまたは複数のサーバのローディングに基づくことがある。例えば、負荷決定は、親サーバで始まる仮想負荷分散ツリーのブランチに基づく、または仮想負荷分散ツリー内の１つのサーバのローディングに基づくことがある。

さらなる実施形態では、仮想負荷分散ツリーに動的に追加されたおよびこれから削除されたサーバの少なくとも一部は、共有リソースプールに追加されるおよびこれから削除されることがある。共有リソースプールは、多数のアプリケーション／サービスの間で共有されるリソースおよび／またはサーバの集合であってもよい。別々の共有リソースプールマネージャは、従来型のリソース管理方法を使用してリソース／サーバの割り当てを管理することができる。さらなる実施形態では、リソースプールマネージャは、クラウドリソースに関するハイパーバイザ管理要求である。ハイパーバイザは、サーバ１２０のうちの１つからの要求に応じてリソースの集合（例えば、仮想マシーン）へのアクセスを提供することができる。

いくつかの実施形態では、サーバ１２０は、エネルギー効率の良い分散型でエラスティックなロードバランシングアーキテクチャ１１０サービス要求マネージャ（図示せず）を使用して仮想負荷分散ツリー内に配置される。サービス要求マネージャは、１つもしくは複数のサーバ１２０（例えば、ルートサーバ１２０−ａ）上におよび／またはサーバ１２０の外部の１つもしくは複数の別々のサーバ上に存在することができる。サービス要求マネージャは、サーバ間の関係を作り出すためにサーバ１２０へと仮想負荷分散ツリーパラメータを伝達することができる。仮想負荷分散ツリーパラメータは：サーバがいつ要求を取り扱うべきであるかを特定するために役立つパラメータ、サーバがそれ自体の子サーバの１つに要求をいつ送信すべきかを特定するために役立つパラメータ、（例えば、スケーリング可能な仮想負荷分散ツリー内で）新しい子サーバをいつ増やすかを特定するために役立つパラメータ、低エネルギーモードにある子サーバがいつ起動させられるべきかを特定するために役立つパラメータ、等、などの任意の適切なパラメータを含むことができる。

いくつかの実施形態では、サービス要求マネージャは、仮想ダイナミック負荷ツリーを動的に管理する。特に、サービス要求マネージャは、本明細書において説明したように仮想負荷分散ツリーのスケーリングを管理するまたはサーバの故障回復を管理することができる。例えば、サーバ１２０の１つが故障した場合には、その故障したサーバは、ネットワークから除外されてもよい。さらにその上、もう１つのサーバが、故障したサーバの役割を引き受けるように選ばれる／インスタンス化されることがある、または故障したサーバの負荷が、生き残っているサーバに分配されることがある。このようなアーキテクチャは、リンクおよびノードボトルネックを回避することが可能であり、ネットワーク欠陥からの回復が早いことがあることが認識されるはずである。サービス要求マネージャが従来型のネットワーク（例えば、ネットワーク３６０）をわたってサーバ１２０と通信することができることも認識されるはずである。

図４は、サーバ１２０の１つを使用してサービス要求を取り扱うための方法の実施形態を図示する流れ図を描く。図１を参照すると、サーバは、親サーバからまたは直接クライアント１５０の１つからのいずれかでサービス要求を受信する（例えば、方法４００のステップ４１０）。子が要求を取り扱うべきであると受信側サーバが決定する場合には（例えば、方法４００のステップ４２０）、受信側サーバは、要求を取り扱う子を選択し（例えば、方法４００のステップ４３０）、選択した子へ要求を送信し（例えば、方法４００のステップ４４０）、そして任意選択で、将来の要求を容易にするために要求を登録する（例えば、方法４００のステップ４５０）。受信側サーバがそれ自身で要求を取り扱うべきであると決定する場合には（例えば、方法４００のステップ４２０）、受信側サーバは、要求を取り扱い（例えば、方法４００のステップ４６０）、任意選択で、将来の要求を容易にするために要求を登録し（例えば、方法４００のステップ４７０）、そして次に、任意選択で、将来のサービス要求を子サーバが取り扱うように準備するために子サーバを起動させるかどうかを決定する（方法４００のステップ４８０および４９０）。

方法４００において、ステップ４１０は、親サーバからまたは直接クライアント１５０の１つからのいずれかでサービス要求を受信する受信側サーバを含む。図１を参照すると、クライアント１５０の１つからのサービス要求は、最初にルートサーバによって受信される。ルートサーバは、次に伝達決定に基づいて仮想負荷分散ツリーを介してサービス要求を伝達する。ルートサーバおよび伝達されたサービス要求を受信する仮想負荷分散ツリー内の各親サーバは、同じく振る舞うことが認識されるはずである。

方法４００において、ステップ４２０は、受信側サーバが子サーバにサービス要求を伝達すべきかまたはそれ自体でサービス要求を取り扱うべきかどうかを決定するステップを含む。

方法４００において、ステップ４３０は、サービス要求を取り扱う子サーバを選択するステップを含む。子サーバは、従来型の分配ポリシを使用して選択される、前もって登録した選択に基づいて選択される、および／または子サーバの能力にサービス要求の必要条件をマッピングすることに基づいて選択されることがある。

方法４００において、ステップ４４０は、選択した子サーバに要求を送信するステップを含む。選択した子サーバに伝達される要求は、受信した要求と同一であってもよいしまたは受信側サーバによって修正されてもよいことが認識されるはずである。

方法４００は、任意選択で、ステップ４５０を含む。ステップ４５０は、将来の要求を容易にするために要求を登録するステップを含む。特に、複数の連続するパケットを含有するサービス要求に関して、選択したサーバのパケットの流れが、登録されてもよい。いくつかのタイプのサービス要求に関して、特定のサーバが、同じサービス要求に属するパケットのすべてを取り扱うことが好まれるまたは要求されることがあることが認識されるはずである。

方法４００において、ステップ４６０は、サービス要求を取り扱うステップを含む。例えば、従来型のネットワークロードバランシングは、ウェブなどのＴＣＰ／ＩＰに基づくサービス要求、端末サービス、仮想プライベートネットワーキング、およびストリーミングメディアサーバを分散させることができる。

方法４００は、任意選択で、ステップ４７０を含む。ステップ４７０は、ステップ４５０において上に説明したように将来の要求を容易にするために要求を登録するステップを含む。

方法４００は、任意選択で、ステップ４８０および４９０を含む。ステップ４８０および４９０は、将来のサービス要求を子サーバが取り扱うように準備するために子サーバを起動させるかどうかを決定するステップを含む。サーバは、エネルギー消費をゼロにするために電源オフ状態またはある別の深いスリープモードにとどまる必要があることが認識されるはずである。「ウェイクオンＬＡＮ（ｗａｋｅ−ｏｎ−ＬＡＮ）」などの従来型の技術は、サービス要求が選択したサーバに送信されるときに（例えば、ステップ４４０）子サーバを起動させるために使用されることがある：しかしながら、サーバを起動させることは、多くの場合にある程度の延長期間がかかり、この移行期間中に、サービス要求が配信可能でないことがある。それはそうとして、親サーバは、１つまたは複数の子サーバを先行して起動させるためにステップ４８０を含むことができる。特に、サーバは、親サーバの負荷および／または将来の負荷の過去の事実に基づく予測（例えば、図２および付帯する説明）に基づいて子サーバを先行して起動させることを決定することができる。都合の良いことに、１つまたは複数の子サーバを先行して起動させることは、親サーバがオーバーフロー状態を回避することを助けることができる。

方法４００のいくつかの実施形態では、ステップ４２０は、受信側サーバが、それ自体の能力に達することおよびさらなる要求を今後取り扱うことができないことを決定するステップを含む。別の実施形態では、ステップ４２０は、受信側サーバがある所定の負荷または負荷の割合に達したことを決定するステップを含む。

方法４００のいくつかの実施形態では、ステップ４３０は：ランダム、ラウンドロビン、または負荷に基づく分配、などの分配ポリシを使用するステップを含む。方法４００のいくつかの実施形態では、ステップ４３０は、サーバが低エネルギー状態にとどまるようなより多くの機会を作り出すために、パフォーマンス制約を満足させることができる負荷が最も高い子を選択するステップを含む。方法４００のいくつかの実施形態では、ステップ４３０は、各子の負荷能力に比例して子サーバを選択するステップを含む。

方法４００のいくつかの実施形態では、ステップ４３０は、子サーバの能力のマッピングおよびサービス要求の必要条件に基づいて子サーバを選択するステップを含む。例えば、親サーバの第１の子サーバは、第２の子サーバよりももっと効率的にストリーミングメディア要求を取り扱うように構成されることがある。

方法４００のいくつかの実施形態では、ステップ４３０は、サービス要求をインスタンス化するクライアント（例えば、図１のクライアント１５０）に基づいて子サーバを選択するステップを含む。例えば、いくつかの構成では、１つまたは複数のサーバ（例えば、図１のサーバ１２０）は、１つまたは複数のクライアントに専用であってもよい。

方法４００のいくつかの実施形態では、ステップ４５０および／または４７０は、引き続くパケットが選択したサーバに直接配信されてもよいようにルートサーバとともにパケットの流れを登録するステップを含む。都合の良いことに、パケットの流れを登録することによって、遅延および選択エラーが低くされることがある。

方法４００のいくつかの応答実施形態では、ステップ４６０は、要求側クライアント（例えば、図１のクライアント１５０−ａ）に直接返信するステップを含む。

これらの応答実施形態の第１の実施形態では、宛先アドレスは、応答では修正される。都合の良いことに、宛先アドレスを応答側サーバのアドレスに修正することによって、要求側クライアントは、仮想負荷分散ツリーパスにしたがわずに応答側サーバに直接将来のパケットを宛てることが可能である。

これらの応答実施形態の第２の実施形態では、サービス要求の宛先アドレスは、要求側クライアントへの応答では修正されない。都合の良いことに、未修正の宛先アドレスを用いて応答することによって、将来のサービス要求は、依然としてルートサーバに宛てられるであろう。さらなる実施形態では、サーバ１２０は各々、固有のプライマリアドレスおよび仮想負荷分散ツリー内のサーバ１２０の間で共有されるセカンダリ仮想アドレスを保有する。

方法４００のいくつかの実施形態では、本方法は、親サーバをスリープモードに変えるように決定するステップをさらに含むことができる。さらなる実施形態では、親サーバは、それ自体のローディングおよびそのサーバの親のローディングに基づいてスリープモードに入るように決定することができる。特に、サーバがスケジュールされたジョブ（例えば、サービス要求タスク）を持たず、そのサーバの親サーバがしきい値レベルよりも低い負荷を有するときには、サーバは、エネルギー効率の良いスリープモードに入る。親サーバおよび子サーバは、従来型のネットワーク（例えば、図３のネットワーク３６０）をわたって従来型の通信プロトコルおよび接続を介してローディングパラメータを通信することができることが認識されるはずである。

ステップ４５０および４９０の後で、方法４００は、ステップ４１０に戻って、サービス要求を受信するステップおよび処理するステップのプロセスを繰り返す。

特定のシーケンスで主に描き、説明したが、方法４００に示したステップは、任意の適切なシーケンスで実行されてもよいことが認識されるはずである。その上、１つのボックスによって特定したステップは、シーケンス内の１つよりも多くの場所でも実行されてもよい。

例えば、任意選択のステップ４８０および４９０は、プロセス内の任意の場所で実行されてもよい。その上、これらは、サービス要求が受信される前にプロセスの外部で実行されることさえある。

図１のエネルギー効率の良い分散型でエラスティックなロードバランシングアーキテクチャ１１０のいくつかの実施形態では、サーバ１２０のうちの１つまたは複数は、方法４００のステップを実行するサービス要求ハンドラを含む。さらなる実施形態では、サーバ１２０の各々は、サービス要求ハンドラを含む。サービス要求ハンドラは、サーバ１２０のうちの１つもしくは複数（例えば、サーバ１２０の各々）におよび／またはサーバ１２０の外部の１つもしくは複数の別々のサーバに存在することができることが認識されるはずである。

様々な上記の方法のステップがプログラムされたコンピュータによって実行され得ることが認識されるはずである。ここでは、いくつかの実施形態はまた、機械またはコンピュータ可読であり、命令の機械実行可能なプログラムまたはコンピュータ実行可能なプログラムをエンコードするプログラムストレージデバイス、例えば、データストレージ媒体をカバーするものとし、ここでは、前記命令は、前記上記の方法の一部またはすべてのステップを実行する。プログラムストレージデバイスは、例えば、ディジタルメモリ、磁気ディスクおよび磁気テープなどの磁気ストレージ媒体、ハードドライブ、または光学式可読データストレージ媒体であってもよい。実施形態はまた、上記の方法の前記ステップを実行するようにプログラムされたコンピュータをカバーするものとする。

図５は、図１のサーバ１２０のうちの１つの一実施形態を模式的に図示する。サーバ１２０は、例えば、方法４００使用して本明細書において説明した機能を実行することができる。サーバ１２０は、プロセッサ５１０、データストレージ５１１、およびＩ／Ｏインターフェース５３０を含む。

プロセッサ５１０は、サーバ１２０の動作を制御する。プロセッサ５１０は、データストレージ５１１と協働する。

データストレージ５１１は、ローディングパラメータを格納することができ（例えば、図４のステップ４２０、４３０、４５０、４７０および４８０）、受信したサービス要求および送信したサービス要求ならびにサーバ間通信をバッファすることができる（例えば、図４のステップ４１０、４４０、４５０、４６０および４７０）。データストレージ５１１は、プロセッサ５１０によって実行可能プログラム５２０も格納する。

プロセッサ実行可能プログラム５１０は、Ｉ／Ｏインターフェースプログラム５２１、サービス要求ハンドラプログラム５２３および／またはサービス要求マネージャプログラム５２５を含むことができる。プロセッサ５１０は、プロセッサ実行可能プログラム５２０と協働して、図１−図４に記述した機能を実装するおよび／または方法４００のステップを実行する。

Ｉ／Ｏインターフェース５３０は、任意の適切な数の（１つまたは複数の）セッション（例えば、任意の適切な数のＩＰフロー）をサポートする任意の適切な数のチャネルをサポートするために構成され、セッションは、特定のサーバ１２０と、１つまたは複数のクライアント（例えば、図１のクライアント１５０−ａ−１５０−ｃ）およびサーバのうちの１つまたは複数（例えば、図１のサーバ１２０）との間に向けられることがある。Ｉ／Ｏインターフェース５３０は、任意の適切な（１つまたは複数の）タイプの通信パスおよび通信プロトコルをサポートすることができる。例えば、通信パスは、ワイアレス通信（例えば、ＧＳＭおよびＣＤＭＡ）、有線通信、パケットネットワーク通信（例えば、ＩＰ）、ブロードバンド通信（例えば、ＤＳＬ）、等、ならびにこれらの様々な組合せを含むことができる。

いくつかの実施形態では、サーバ１２０は、特別に設計されたネットワークインターフェースカード（ＮＩＣ）である。さらなる実施形態では、ＮＩＣは、サービス要求取扱いを提供する。都合の良いことに、ＮＩＣが着信するサービス要求を取り扱うので、サーバホストは、それ自体のコア機能に集中することが可能であり、サービスを提供するためにそれ自体のリソースを専用にすることが可能である。サーバホストがＮＩＣへ負荷の指示および他の適切なパラメータを提供することができることが認識されるはずである。

いくつかの実施形態では、ホストサーバは、ホストがビジーであり、これ以上新しい要求を受け入れられないことを指示するためにＮＩＣ上にビジービット（ｂｕｓｙ ｂｉｔ）を設定することができる。この実施形態では、ＮＩＣは、仮想負荷分散ツリーに基づいて、新しいサービス要求を適切なサーバに自動的に転送することができる。都合の良いことに、このＮＩＣハードウェア加速は、サービス遅延をさらに減少させることができる。

プロセッサ実行可能プログラム５２０がプロセッサ５１０上に実装されると、プログラムコードセグメントは、特定の論理回路と類似したように動作する固有のデバイスを提供するためにプロセッサと組み合わさる。

プログラムおよび論理がデータストレージ内に格納され、メモリがプロセッサに通信可能に接続される実施形態に関して本明細書において描き、説明したが、このような情報が、任意の適切な配置のデバイスに通信可能につなげられた任意の適切な配置のメモリ、ストレージもしくはデータベースを使用して、（１つもしくは複数の）メモリ、（１つもしくは複数の）ストレージおよび／もしくは（１つもしくは複数の）内部もしくは外部データベースの任意の適切な組合せ内に情報を格納して、または任意の適切な数のアクセス可能な外部メモリ、ストレージもしくはデータベースを使用して、任意の他の適切な方式で（例えば、任意の適切な数のメモリ、ストレージもしくはデータベースを使用して）格納されてもよいことが認識されるはずである。それはそうとして、本明細書において呼ばれるデータストレージという用語は、（１つまたは複数の）メモリ、（１つまたは複数の）ストレージ、および（１つまたは複数の）データベースのすべての適切な組合せを含むことを意味する。

説明および図面は、単に本発明の原理を図示する。本明細書において明示的に記述されていないまたは示されていないが、本発明の原理を具体化し、かつ本発明の精神および範囲内に含まれる様々な配置を、当業者なら考案できるであろうことが、したがって認識されるであろう。さらにその上、本明細書において引用したすべての例は、本技術を推し進めるために（１人または複数の）発明者によって提案された本発明の原理および概念を理解する際に読者を助けるために、明確に教育的な目的のためだけであるように原理的に意図され、このような具体的に引用した例および条件に限定されないとして解釈されるべきである。その上、本発明の原理、態様および実施形態ならびにこれらの具体的な例を説明する本明細書中のすべての記述は、これらの等価物を含むものとする。

「プロセッサ」として名付けた任意の機能ブロックを含む図に示した様々な要素の機能は、専用のハードウェアならびに適切なソフトウェアと協働してソフトウェアを実行することが可能なハードウェアの使用を通して提供されてもよい。プロセッサによって与えられるときには、機能は、１つの専用プロセッサによって、１つの共有プロセッサによって、またはプロセッサのいくつかが共有されてもよい複数の個別のプロセッサによって与えられてもよい。その上、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行することが可能なハードウェアを限定的に呼ぶように解釈されるべきではなく、限定ではなく、ディジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性ストレージを暗に含むことができる。他のハードウェア、従来型および／またはカスタムも、含まれてもよい。同様に、図に示したいずれかのスイッチは、単に概念的なものである。これらの機能は、プログラムロジックの動作を介して、専用ロジックを介して、プログラム制御および専用ロジックの相互作用を介して、または手作業さえで実行されることがあり、特定の技術が、コンテキストからより具体的に理解されるように実施者によって選択可能である。

本明細書内のいずれかのブロック図は、本発明の原理を具体化する例示的な回路の概念的な図を表すことが認識されるはずである。同様に、いずれかのフローチャート、フローダイアグラム、状態遷移図、疑似コード、等が、コンピュータ可読媒体内に実質的に表現されることがあり、コンピュータまたはプロセッサが明示的に示されているか否かに拘わらず、コンピュータまたはプロセッサによってそのように実行されることがあり得る様々なプロセッサを表すことが認識されるはずである。

Claims (15)

1. 親サーバにおいてエネルギー効率が良くかつエラスティックなロードバランシングを提供するための方法であって、
   データストレージに通信可能につなげられたプロセッサにおいて、１つまたは複数のクライアントによってインスタンス化された複数のサービス要求を受信するステップと、
   データストレージと協働するプロセッサによって、サービス要求に基づいて、複数のサービス要求の少なくとも一部に対応する複数のサービス取扱い判断を決定するステップと、
   データストレージと協働するプロセッサによって、サービス取扱い判断のうち第１の判断に基づいて子サーバを選択し、第１のサービス取扱い判断に対応する第１のサービス要求に基づいて第１の伝達されたサービス要求を送信するステップと、
   データストレージと協働するプロセッサによって、サービス取扱い判断のうち第２の判断に基づいて親サーバを選択し、第２のサービス取扱い判断に対応する第２のサービス要求を取り扱うステップと
   を含む、方法。
2. 第２のサービス要求を取り扱うステップの行為が、第２のサービス要求のインスタンス化側クライアントに直接応答するステップを含む、請求項１に記載の方法。
3. データストレージと協働するプロセッサによって、複数のサービス要求のうちの少なくとも１つに基づいて、親サーバのローディングを示す親負荷を決定するステップと、
   データストレージと協働するプロセッサによって、親負荷およびサーバ負荷しきい値に基づいて親サーバの少なくとも１つの子サーバを起動させるステップと
   をさらに含む、請求項１に記載の方法。
4. データストレージと協働するプロセッサによって、複数のサービス要求のうちの少なくとも１つに基づいて、親サーバのローディングを示す親負荷を決定するステップと、
   データストレージと協働するプロセッサによって、親サーバの親である親−親サーバのローディングを示す親−親負荷を受信するステップと、
   データストレージと協働するプロセッサによって、親負荷、親−親負荷および親−親負荷しきい値に基づいて親サーバの動作をスリープモードに切り換えるステップと
   をさらに含む、請求項１に記載の方法。
5. データストレージと協働するプロセッサによって、子サーバおよび第１のサービス要求に基づく少なくとも１つの関係する選択パラメータを登録するステップと、
   データストレージと協働するプロセッサによって、複数のサービス要求のうちの第３のサービス要求および少なくとも１つの登録した関係する選択パラメータに基づいて子サーバを選択するステップと、
   第３のサービス要求に基づいて第３の伝達されたサービス要求を送信するステップと
   をさらに含む、請求項１に記載の方法。
6. データストレージと、
   データストレージに通信可能につなげられたプロセッサであって、
   １つまたは複数のクライアントによってインスタンス化された複数のサービス要求を受信し、
   サービス要求に基づいて、複数のサービス要求の少なくとも一部に対応する複数のサービス取扱い判断を決定し、
   サービス取扱い判断のうち第１の判断に基づいて子サーバを選択し、第１のサービス取扱い判断に対応する第１のサービス要求に基づいて第１の伝達されたサービス要求を送信し、
   サービス取扱い判断のうち第２の判断に基づいて親サーバを選択し、第２のサービス取扱い判断に対応する第２のサービス要求を取り扱う、
   ように構成された、プロセッサと
   を備えた、エネルギー効率が良くかつエラスティックなロードバランシング装置。
7. プロセッサが、
   複数のサービス要求のうちの少なくとも１つに基づいて親サーバのローディングを示す親負荷を決定し、
   親サーバの親である親−親サーバのローディングを示す親−親負荷を受信し、
   親負荷、親−親負荷および親−親負荷しきい値に基づいて親サーバの動作をスリープモードに切り換える、
   ようにさらに構成される、請求項６に記載の装置。
8. プロセッサが、
   子サーバおよび第１のサービス要求に基づく少なくとも１つの関係する選択パラメータを登録し、
   複数のサービス要求のうちの第３のサービス要求および少なくとも１つの登録した関係する選択パラメータに基づいて子サーバを選択し、
   第３のサービス要求に基づいて第３の伝達されたサービス要求を送信する、
   ようにさらに構成される、請求項６に記載の装置。
9. 子サーバの選択が、子サーバの子サーバ負荷の割合および親サーバの少なくとも１つの他の子サーバに対応する少なくとも１つの他の子サーバ負荷に基づく、請求項６に記載の装置。
10. エネルギー効率が良くかつエラスティックなロードバランシングを提供するためのシステムであって、
    ネットワークを介して通信可能につなげられ、仮想負荷分散ツリー内に論理的に配置された複数のサーバと、
    複数のサーバに通信可能につなげられたサービス要求ハンドラであり、
    １つまたは複数のクライアントによってインスタンス化された複数のサービス要求を受信し、
    サービス要求に基づいて、複数のサービス要求の少なくとも一部に対応する複数のサービス取扱い判断を決定し、
    サービス取扱い判断のうち第１の判断に基づいて子サーバを選択し、第１のサービス取扱い判断に対応する第１のサービス要求に基づいて第１の伝達されたサービス要求を送信し、
    サービス取扱い判断のうち第２の判断に基づいて親サーバを選択し、第２のサービス取扱い判断に対応する第２のサービス要求を取り扱う、
    ように構成された、サービス要求ハンドラと
    を備えた、システム。
11. 仮想負荷分散ツリーが、ルートサーバおよび少なくとも２つのレベルのサーバを含む、請求項１０に記載のシステム。
12. 仮想負荷分散ツリーが、初期遅延の値および複数のサーバの少なくとも一部に関する省エネルギーポテンシャルに基づく、請求項１１に記載のシステム。
13. 仮想負荷分散ツリーが、予測したシステム負荷に基づく、請求項１１に記載のシステム。
14. 複数のサーバに通信可能につなげられたサービス要求マネージャであって、
    仮想負荷分散ツリーを動的にスケーリングする、
    ように構成される、サービス要求マネージャ
    をさらに備える、請求項１１に記載のシステム。
15. サービス要求マネージャが、
    故障したサーバを回復させるようにさらに構成され、
    複数のサーバが、故障したサーバを含み、
    故障したサーバの回復が、
    故障したサーバの役割を引き受けるために選択されるサーバを選択し、複数のサーバが選択されるサーバを含み、
    故障したサーバの役割を引き受けるために新しいサーバをインスタンス化し、複数のサーバが新しいサーバを含み、
    より多くの回復サーバのうちの一つに故障したサーバの負荷を分散させ、複数のサーバが回復サーバを含む、
    ことのうちの少なくとも１つを含む、請求項１４に記載のシステム。

Images