JP2006508445A - アプリケーション固有の冗長特性に基づく自動電力制御ポリシー - Google Patents

Abstract

【課題】 アプリケーション固有の冗長特性に基づく自動電力制御ポリシーを提供することにある。
【解決手段】 電力および冗長管理ポリシーは、高レベルのシステム可用性を維持しながら電力を削減するように、アプリケーション・サービスの複数冗長サーバの層に個別に適用される。比較的非アクティブであると判定されたサーバは自由プールに移動される。自由プールの特定のサーバはホット・スタンバイ状態に維持され、他のサーバはパワーオフされるかまたは低電力モードで動作するように設定される。高負荷時に、ホット・スタンバイ状態のサーバは、アプリケーション・サービスに入るよう素早く用意することができる。

Description

本発明は、クラスタ化コンピューティング・システムおよびその他のクラスタ化情報処理システムに関する。

負荷が大きいインターネット・アプリケーション・サービスの要求に応じるために、アプリケーション・サービスのプロバイダは、アプリケーション・サービスの応答時間を増加するために冗長性に頼っていた。冗長性とは、概して、１つまたは複数の機能的に同一のサーバをアプリケーション・サービスに追加することを指す。単一物理サーバが論理的に複数のサーバとして動作する場合、その複数のサーバは一般に仮想サーバと呼ばれる。冗長サーバ環境でサーバを追加する場合、追加するサーバは物理サーバまたは仮想サーバにすることができる。

負荷が大きいインターネット・アプリケーション・サービスに配置されたネットワークは、概して、有限数のネットワーク・ノードを含む。各ノードには、１つのサーバまたは複数のサーバが存在する。その１つのサーバまたは複数のサーバは、仮想サーバまたは物理サーバあるいは両者の任意の組合せにすることができる。

サービス・プロバイダは、概して、様々な時点でアプリケーション・サービスを提供するために複数カスタマ間に割り振ることができる多数のノードを有する。提供されるワークロードは時間の経過につれて変動する可能性があるので、設備内のノードの数がサービスを提供するために必要なノードの数を上回る場合もあるであろう。過剰サーバが電力およびその他のリソースを消費するので、これはサービス・プロバイダに対して問題を提起するものである。非アクティブであって依然としてパワーオン状態であるサーバは、より多くの電力を消費するだけでなく、全パワーオン時間に相関する信頼性コンポーネント（component）について信頼性の低減にも陥りやすい。

したがって、本発明は、コンピュータ可読プログラム・コードがそこで実行されるコンピュータ使用可能媒体を有するプログラムを提供し、前記プログラム内のコンピュータ可読プログラム・コードは、（ａ）アプリケーション・サービスを提供する複数サーバのクラスタのうちの各サーバのワークロードを決定するステップと、（ｂ）アプリケーション・サービスのトポロジを決定するステップであって、前記トポロジの決定が、アプリケーション・サービスの第１のコンポーネントと第１のコンポーネントが実行されるサーバとの通信（correspondence）を含むステップと、（ｃ）前記ワークロードの決定および前記トポロジの決定に基づいて、複数サーバのクラスタのうちの１つのサーバの電力状態（power state）を設定するステップとを実行する際に効果的である。

コスト節約を最大限にするためには、できるだけ多くのサーバをパワーオフすることが有益であると思われるであろう。しかし、サーバをパワーオフすると、サービス・プロバイダは、アプリケーション・サービスを提供するサーバのピーク負荷または障害発生時に十分素早くサーバを用意することができないというリスクに曝される。

したがって、コンピュータ上で実行されたときに、（ａ）アプリケーション・サービスを提供する複数サーバのクラスタのうちの各サーバのワークロードを決定するステップと、（ｂ）アプリケーション・サービスのトポロジを決定するステップであって、前記トポロジの決定が、アプリケーション・サービスの第１のコンポーネントと第１のコンポーネントが実行されるサーバとの通信を含むステップと、（ｃ）前記ワークロードの決定および前記トポロジの決定に基づいて、複数サーバのクラスタのうちの少なくとも１つのサーバの電力状態を設定するステップとを実行するように適合されたプログラム・コード手段を有するコンピュータ・プログラムが提供される。

好ましくは、複数冗長サーバのクラスタによって消費される電力を削減する方法が提供される。

本発明は、好ましくは、ピーク負荷またはサーバ障害発生時に十分素早くサーバを用意することができないというリスクを避けながら、同時に非アクティブ・サーバをパワーダウンしようとするインターネット・アプリケーション・サービスのプロバイダに解決策を提供するものである。一実施形態では、アプリケーション・サービスを提供する複数サーバのクラスタのうちの各サーバのワークロードが決定される。次に、アプリケーション・サービスのトポロジが決定される。このトポロジ情報は、アプリケーション・サービスのコンポーネントとそのコンポーネントが実行されるサーバとの通信を含む。次に、このワークロードおよびトポロジ情報に基づいて、１つまたは複数のサーバの電力状態が変更される。

この好ましい実施形態では、本発明の概念はコンピュータ・プログラムの形で提供される。このプログラムは、カスタマのために、フレキシブル・ディスクまたはＣＤ−ＲＯＭなどのコンピュータ可読媒体で配布され、既存の（または提供された）コンピュータ・システムにインストールされる。

他の一実施形態では、本発明の概念は、装置の形で提供され、サーバ自体を含むことができる。

さらに他の一実施形態では、本発明の概念は、装置およびプログラムまたは方法の形でならびに任意の組合せで提供され、管理されるサーバを含むことができる。

一実施形態では、設定するステップ（ｃ）は、前記ワークロードの決定が所定のしきい値より下のワークロードを決定したときに低電力状態になる。

一実施形態では、設定するステップ（ｃ）はさらに、サーバ・リソースが完全に使用される程度に基づいて行われる。

好ましくは、低電力状態は、スタンバイ状態、スリープ状態、ハイバネート（hibernate）状態、およびオフ状態からなるグループから選択された状態である。

好ましくは、トポロジの決定は、アクティブ・サーバの総数のうちの第１のカウントを含み、前記設定するステップ（ｃ）はさらに、第１のカウントに対するパワーオン非アクティブ・サーバの比率の関数であり、最小数のパワーオン非アクティブ・サーバを設定するための規定（provision）を含む。

好ましくは、設定するステップ（ｃ）は、前記ワークロードの決定がその１つのサーバが最後にリセットされてからの経過時間を示すワークロードを決定したときに低電力状態になる。

好ましくは、設定するステップ（ｃ）は、前記ワークロードの決定が所定のしきい値より上のワークロードを決定したときにパワーオン状態になる。

好ましい一実施形態によれば、コンピュータ上で実行されたときに、アプリケーション・サービスを提供する第１の層の複数スケーラブル冗長サーバのうちの各サーバのワークロードを決定するステップと、アプリケーション・サービスのトポロジを決定するステップであって、前記トポロジの決定が、アクティブな第１層サーバの総数のうちの第１のカウントと、アプリケーション・サービスの第１のコンポーネントと第１のコンポーネントが実行される第１層サーバとの通信とを含むステップと、前記ワークロードの決定に基づいて、アプリケーション・サービスと第１層サーバの自由プールとの間で第１層サーバを移行するステップと、第１の所定の電力管理ポリシーにより、前記トポロジの決定に基づいて、第１層サーバの自由プールのサーバのそれぞれに加えられた電力を制御するステップとを実行するように適合されたプログラム・コード手段を有するコンピュータ・プログラムが提供される。

好ましい一実施形態によれば、複数サーバのクラスタのうちの各サーバのワークロードを決定するステップは、アプリケーション・サービスを提供する第１の層の複数スケーラブル冗長サーバのうちの各サーバのワークロードを決定するステップを有し、トポロジの決定は、アクティブな第１層サーバの総数のうちの第１のカウントと、アプリケーション・サービスの第１のコンポーネントと第１のコンポーネントが実行される第１層サーバとの通信とを含み、コンピュータ・プログラム手段は、コンピュータ上で実行されたときに、（ｅ）前記ワークロードの決定に基づいて、アプリケーション・サービスと第１層サーバの自由プールとの間で第１層サーバを移行するステップを実行するようにさらに適合され、設定するステップ（ｃ）は、（ｆ）トポロジの決定に基づいて、ワークロードの決定に基づく第１の所定の電力管理ポリシーにより、第１層サーバの自由プールのサーバのそれぞれに加えられた電力を制御するステップを有する。

好ましくは、このプログラム手段は、コンピュータ上で実行されたときに、（ｇ）アプリケーション・サービスを提供する第２の層の複数スケーラブル冗長サーバのうちの各サーバのワークロードを決定するステップであって、第２の層の複数スケーラブル冗長サーバからの応答が第１の層の複数スケーラブル冗長サーバからの応答に依存するステップと、（ｈ）アプリケーション・サービスと第２層サーバの自由プールとの間で第２層サーバを移行するステップであって、前記トポロジの決定がアクティブな第２層サーバの総数のうちの第２のカウントをさらに含むステップと、（ｉ）第２の所定の電力管理ポリシーにより、前記トポロジの決定に基づいて、第２層サーバの自由プールのサーバのそれぞれに加えられた電力を制御するステップであって、第２の電力管理ポリシーが、第１の電力管理ポリシーおよび第１の電力管理ポリシーとは無関係のポリシーからなるグループから選択されたポリシーであるステップとを実行するようにさらに適合される。

一実施形態によれば、この移行するステップは、前記ワークロードの決定が所定のしきい値より下のワークロードを決定したときに、アプリケーション・サービスから第１層サーバの自由プールに行われる。

好ましくは、この移行するステップはさらに、移行する第１層サーバのサーバ・リソースが完全に使用される程度に基づいて行われる。

一実施形態によれば、この移行するステップは、前記ワークロードの決定が所定のしきい値より上のワークロードを決定したときに、第１層サーバの自由プールからアプリケーション・サービスに行われる。

好ましくは、第１層サーバの自由プールのサーバに適用される第１の所定の電力管理ポリシーは第１の数のサーバをパワーオン非アクティブ状態に維持し、残りのサーバは低電力状態に設定される。

好ましくは、第１層サーバの自由プールのサーバに適用される第１の所定の電力管理ポリシーは、第１のカウントに対するパワーオン非アクティブ・サーバの比率の関数であり、最小数のパワーオン非アクティブ・サーバを設定するための規定を含む。

好ましくは、低電力状態は、スタンバイ状態、スリープ状態、ハイバネート状態、およびオフ状態からなるグループから選択された状態である。

他の態様によれば、本発明は、（ａ）アプリケーション・サービスを提供する複数サーバのクラスタのうちの各サーバのワークロードを決定するステップと、（ｂ）アプリケーション・サービスのトポロジを決定するステップであって、前記トポロジの決定が、アプリケーション・サービスの第１のコンポーネントと第１のコンポーネントが実行されるサーバとの通信を含むステップと、（ｃ）前記ワークロードの決定および前記トポロジの決定に基づいて、複数サーバのクラスタのうちの少なくとも１つのサーバの電力状態を設定するステップとを有する方法を提供する。

好ましい一実施形態によれば、（ａ）アプリケーション・サービスを提供する第１の層の複数スケーラブル冗長サーバのうちの各サーバのワークロードを決定するステップと、（ｂ）アプリケーション・サービスのトポロジを決定するステップであって、前記トポロジの決定が、アクティブな第１層サーバの総数のうちの第１のカウントと、アプリケーション・サービスの第１のコンポーネントと第１のコンポーネントが実行される第１層サーバとの通信とを含むステップと、（ｃ）前記ワークロードの決定に基づいて、アプリケーション・サービスと第１層サーバの自由プールとの間で第１層サーバを移行するステップと、（ｄ）第１の所定の電力管理ポリシーにより、前記トポロジの決定に基づいて、第１層サーバの自由プールのサーバのそれぞれに加えられた電力を制御するステップとを有する方法が提供される。

他の態様によれば、アプリケーション・サービスを提供する複数サーバのクラスタのうちの各サーバのワークロードを検出するワークロード・モニターと、アプリケーション・サービスの第１のコンポーネントと第１のコンポーネントが実行されるサーバとの通信を含み、アプリケーション・サービスのトポロジを決定するトポロジ・センサと、前記ワークロード・モニターによって決定されたワークロードおよび前記トポロジ・センサによって決定されたトポロジに基づいて、複数サーバのクラスタのうちの少なくとも１つのサーバの電力状態を設定する電力コントローラとを有する装置が提供される。

好ましくは、この装置は、アプリケーション・サービスを提供する複数サーバのクラスタのうちの各サーバを有する。

好ましい一実施形態によれば、アプリケーション・サービスを提供する第１の層の複数スケーラブル冗長サーバのうちの各サーバのワークロードを検出するワークロード・モニターと、アクティブな第１層サーバの総数のうちの第１のカウントと、アプリケーション・サービスの第１のコンポーネントと第１のコンポーネントが実行される第１層サーバとの通信とを含み、アプリケーション・サービスのトポロジを決定するトポロジ・センサと、前記ワークロード・モニターによって決定されたワークロードに基づいて、アプリケーション・サービスと第１層サーバの自由プールとの間で第１層サーバを移行する移動モジュールと、第１の所定の電力管理ポリシーにより、前記トポロジ・センサによって決定されたトポロジに基づいて、第１層サーバの自由プールのサーバのそれぞれの電力状態を設定する電力コントローラとを有する装置が提供される。

好ましい一実施形態では、この装置は、アプリケーション・サービスを提供する第１の層の複数スケーラブル冗長サーバのうちの各サーバを有する。

次に、一例として、添付図面に関連して、本発明の好ましい諸実施形態について説明する。

次に、より詳細に添付図面を参照すると、図１は、本発明の省電力化概念が使用される例示的なアプリケーション・サービスのトポロジを示している。図１のアプリケーション・サービスは、Ｗｅｂサーバ１００と、ネットワーク・ディスパッチャ１０１および１０２からなる。ネットワーク・ディスパッチャ１０１および１０２は、ＷｅｂサーバにＷｅｂ要求を配布するロード・バランシング・コンポーネントとして機能する。図１には単一のホット・スタンバイ・ネットワーク・ディスパッチャ１０２が示されているが、アプリケーション・サービスは、任意の数のネットワーク・ディスパッチャを有することができ、そのうちの任意のサブセットがホット・スタンバイ状態で機能する。ネットワーク・ディスパッチャの機能については、以下により詳細に説明する。また、ホット・スタンバイという用語についても、好ましい諸実施形態の説明が進むにつれて説明することになる。複数のＷｅｂサーバ１００は、Ｗｅｂページを供給する機能を実行するものであり、機能的に同一である。ネットワーク・ディスパッチャ１０１は、インターネットからＷｅｂページに関する要求を受信し、その要求をＷｅｂサーバ１００に転送する。Ｗｅｂサーバ１００は、個々の要求を処理し、インターネット上のクライアントに個々の応答を返送する。ホット・スタンバイ・ネットワーク・ディスパッチャ１０２は、ネットワーク・ディスパッチャ１０１側の障害の場合にネットワーク・ディスパッチャ１０１の役割を引き継ぐために使用する。図１のアプリケーション・サービスは、３つのサーバと２つのネットワーク・ディスパッチャとともに示されている。しかし、一般に、アプリケーション・サービスは、任意の数のＷｅｂサーバと、任意の数のネットワーク・ディスパッチャとを含むことができる。さらに、アプリケーション・サービスは、Ｗｅｂサーバ用の層１と、ネットワーク・ディスパッチャ用の層２という２つの層のサーバを有するものとして示されている。それにもかかわらず、アプリケーション・サービスは、任意の数の層の冗長サーバを含むことができる。各層は、アプリケーション・サービス内の１つの別個の機能を実行する。たとえば、Ｗｅｂサーバ１００に情報をフィードするＷｅｂまたはデータベース・アプリケーションを実行するサーバ用として、もう１つの層を追加することができる。実際に、スケーラブル冗長アーキテクチャから恩恵を受けることができるサーバ機能は、本発明の概念からも恩恵を受けることができる。たとえば、このような機能としては、プロキシ・キャッシュ、ＦＴＰ、ＤＮＳ、Ｇｏｐｈｅｒ、ＦｒｏｎｔＰａｇｅ（商標）、および認証機能を含む。データベース・アプリケーションは、ＩＢＭのＳＱＬ（商標）などのリレーショナル・データベースを含む、任意のデータベース・アプリケーションにすることができる。

負荷（ロード）という用語は、単位時間あたりネットワーク・ディスパッチャ１０１に到着する要求の数として定義することができる。好ましい実施形態によれば、アプリケーション・サービスにかかる負荷が小さい場合、アプリケーション・サービスから特定のサーバを除去することにより、アプリケーション・サービスに使用するサーバの数が削減される。その場合、アプリケーション・サービスから除去されたサーバのサブセットによって消費される電力の量を制御することにより、電力が削減される。さらに、アプリケーション・サービスがワークロードに応じるために十分なオンライン・パワーオン容量に加え、１つまたは複数の追加のサーバの形で特定の量のスペア・オンライン・パワーオン容量を有するように、任意の所与の層のサーバに関する冗長管理ポリシーが実現される。図１に示す例の場合、アプリケーション・サービスにかかる負荷が非常に小さい場合、たとえば、複数のＷｅｂサーバのうちの１つをパワーオフすることにより、アプリケーション・サービスに使用するＷｅｂサーバ１００の数を、たとえば、３から２に削減することができる。さらに、複数のＷｅｂサーバを完全にパワーオフするのではなく、スタンバイ、スリープ、ハイバネート、およびその他の省電力化状態およびモードなどの業界標準の半（semi）パワーオン状態または超低電力状態のうちの１つに電力状態を設定することにより、電力を節約することも可能である。スタンバイ状態は、以下に説明するホット・スタンバイ状態から独立した別個の状態であることに留意されたい。

図２は、アプリケーション・サービスで同一機能を実行する複数冗長サーバの層に含まれるサーバの設備および動作状態を示している。サーバは、そのサーバが経験するワークロードに応じて、アプリケーション・サービスのアクティブ状態２０１と自由プール２０２との間で移動する。アクティブ状態２０１は、サーバがアプリケーション・サービスに従事している完全パワーオン状態である。自由プール２０２内のサーバは、考慮中の特定のアプリケーション・サービスで非アクティブになっている。前述の通り、アプリケーション・サービスのワークロード要求に応じるために十分なオンライン・パワーオン容量に加え、１つまたは複数の追加のサーバの形で特定の量のスペア・オンライン・パワーオン容量を保証する冗長管理ポリシーが実現される。このようなスペア・オンライン・パワーオン・サーバは、ホット・スタンバイ・サーバと呼ばれる。この冗長管理ポリシーにより、自由プール２０２の特定の数のサーバがホット・スタンバイ状態２０３に保持される。このようなホット・スタンバイ・サーバは、アプリケーション・サービスでは非アクティブであるが、アプリケーション・サービスに対するワークロード要求が所定のしきい値を超える場合に素早くアクティブ状態２０１に用意することができる。電力を削減するために、ホット・スタンバイ状態で保持されない自由プール２０２のサーバは、低電力状態２０５に設定することができる。

好ましい実施形態では、アクティブ状態２０１と自由プール２０２との間ならびに自由プール内のホット・スタンバイ状態２０３と低電力状態２０５との間でサーバを移行するときに、アプリケーション・サービスのトポロジも考慮に入れる。トポロジの決定は多くの形を取ることができ、本明細書では様々な例が示されることになる。しかし、これらの例は、本発明の範囲を制限するものと解釈すべきではない。第１の例としてのトポロジの決定は、アプリケーション・サービスで現在アクティブのサーバの総数を決定するという形を取ることができる。もう１つの例のトポロジの決定は、それぞれのサーバの個々の正常性（health）を決定するという形を取ることができる。正常性を決定する際に、トポロジの決定は、残りのメモリの量あるいはメモリ、ＣＰＵ、入出力（Ｉ／Ｏ）、または任意のその他のシステム・リソースが枯渇している程度に焦点を合わせることができる。正常性を決定する際に、特定のオペレーティング・システムは時々リセット（リブート／再始動）する必要があることは周知のことであり、したがって、トポロジの決定は、任意の所与のサーバがリセットされてから経過した時間の総量に焦点を合わせることができる。また、いかなる種類のシステム・ボトルネックも考慮に入れることができる。

さらに他の例では、アプリケーション・サービスは仮想サーバ環境で動作する。仮想サーバ環境では、必ずしも仮想サーバと物理サーバとの間に１対１の対応（通信）が存在するわけではない。この環境では、トポロジの決定は、物理サーバが２つ以上の機能を実行しているかどうかまたは物理サーバが２つ以上の層の冗長サーバに関係しているかどうかを考慮することになる。たとえば、１つの物理サーバは、数百もの仮想Ａｐａｃｈｅサーバを実行している可能性がある。この例では、すべてのＡｐａｃｈｅサーバが同じ層内で動作しており、冗長なものである。さらに他の例では、物理サーバは、プロキシ・キャッシュ層またはネットワーク・ディスパッチャ層などの複数の層の仮想アプリケーションを実行することができる。この仮想サーバ環境では、あるサーバを低電力状態２０５に設定する前に、任意の所与の物理サーバ内のすべての仮想サーバのトポロジを考慮に入れ、物理サーバによって実行される仮想関数のすべてが自由プール２０２内にあり、ホット・スタンバイ状態２０３になっていると判定されない限り、物理サーバをパワーダウンしない。適切なワークロードの決定およびトポロジの決定が行われ、アプリケーション・サービスの要求に応じるために十分な数のホット・スタンバイ・サーバが自由プール内に存在すると判定されると、その場合のみ、物理サーバは低電力状態に設定されるかまたは完全にパワーオフされることになる。

次に、トポロジの決定およびワークロードの決定のより具体的な例を示す。この例では、各関数型あたりホット・スタンバイ状態２０３に保持すべきサーバの数は以下のパラメータによって定義される。この場合、関数型は複数冗長サーバの層によって実行される関数を指す。
ｍｉｎＨｏｔＩｎＦｒｅｅＰｏｏｌ−このパラメータは、自由プール内のこの関数型の最小数のホット・スタンバイ・サーバを設定するための規定を提供する。
ａｄｄＯｎｌｉｎｅＲａｔｉｏ−このパラメータは、アプリケーション・サービスに積極的に関与するこの関数型のサーバの数と、ホット・スタンバイ状態２０３に保持されるであろうこの関数型の追加サーバの数との所望の比率を表す。たとえば、１００個のサーバがアプリケーション・サービスに積極的に関与しており、ａｄｄＯｎｌｉｎｅＲａｔｉｏの値が２０である場合、この特定のアプリケーション・サービスは、自由プール２０２内に１００／２０＝５個のホット・スタンバイ・サーバを必要とすることになるであろう。自由プール２０２内の全サーバが１５であった場合、残りの１５−５＝１０個のサーバはパワーオフするか、あるいは低電力動作モードに設定することができる。
ｄｅｐｌｏｙｅｄＩｎＡｌｌＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｉｃｅｓ−このパラメータは、現在、サービス・プロバイダの環境に関与しているこの関数型のサーバの総数を示す。
ｈｏｔＳｅｒｖｅｒｓＩｎＦｒｅｅＰｏｏｌ−このパラメータは、自由プール２０２内にあるべきサーバの数を表す。

次に、ホット・スタンバイ状態２０３に保持すべき特定の関数型のサーバの数は以下のように決定される。

代替実施形態では、ｈｏｔＳｅｒｖｅｒｓＩｎＦｒｅｅＰｏｏｌは以下のように計算することができる。

この例の電力管理システムは、自由プール２０２内の特定の型のホット・サーバの数をｈｏｔＳｅｒｖｅｒｓＩｎＦｒｅｅＰｏｏｌに等しくなるように維持しようと試みる。自由プール２０２内の残りのサーバは低電力状態２０５にすることができる。

本発明の好ましい実施形態では、次に図１および図２の両方を参照すると、複数冗長サーバの各層ごとに個別に冗長および電力管理ポリシーが適用される。これらの層は、図１に層１および層２として示されており、破線で囲まれている。各関数型は固有の要求を備えている可能性があるので、このポリシーは個別に適用される。たとえば、ホット・スタンバイ状態２０３に保持すべきサーバの最小数は、関数型によって変動する可能性がある。Ｗｅｂサーバ１００の最小数はほぼ任意の数にすることができるが、ホット・スタンバイ・ネットワーク・ディスパッチャ１０２の最小数はより特定のものにすることができる。ホット・スタンバイ・ネットワーク・ディスパッチャ１０２は必ずしも常に使用されるわけではないが、現行ネットワーク・ディスパッチャ１０１の障害の場合にアクティブな役割を引き継ぐ必要があるので、パワーオフすることができない。電力および冗長管理ポリシーは、ネットワーク・ディスパッチャに関して、（１）少なくとも２つのネットワーク・ディスパッチャ・サーバが常にオンラインでなければならず、（２）追加のワークロードに応じるためにネットワーク・ディスパッチャをパワーオンすることができ、（３）少なくとも２つが常にオンラインである限り、ワークロードが減衰したときにネットワーク・ディスパッチャをパワーオフすることができるように、指定することができる。代わって、１つのアプリケーション・サービスの様々な層に適用される電力および冗長管理ポリシーは同じものにすることができる。

図３は、好ましい一実施形態の教示による電力および冗長管理ポリシーの流れ図である。ステップ３０１では、複数冗長サーバの層の各サーバのワークロードが決定される。任意の所与のサーバのワークロードは、全体としてアプリケーション・サービスにかかる負荷に直接関連し、さらにサーバ固有の属性（attribute）に依存する。サーバのワークロードの決定は、当技術分野では周知のものであり、したがって、これ以上詳細に説明しない。ワークロードが決定されると、処理はステップ３０２に移行する。ステップ３０２では、トポロジの決定に関する上記の考察通りにアプリケーション・サービスのトポロジが決定される。トポロジの決定は、アプリケーション・サービスのコンポーネントと、そのコンポーネントが実行されるサーバのアカウンティング（accounting）を含む。アプリケーション・サービスが仮想サーバを使用する場合、仮想サーバおよび対応する物理サーバに関して、さらにトポロジの決定が行われる。ステップ３０１および３０２によりワークロードおよびトポロジが決定されると、処理はステップ３０４に続き、そこで任意の特定のサーバの移行が必要であるかどうかが判定される。

アプリケーション・サービスにかかる負荷が所定の高負荷しきい値および低負荷しきい値を超えるかまたはそれらに適合しない場合、サーバの移行が必要になる。いずれのしきい値にも適合しない場合、処理はステップ３０１に続く。これに対して、一方のしきい値に適合する場合、処理はステップ３０５に続き、そこで以下の基準に従ってサーバが移動する。ステップ３０５では、ステップ３０１で決定された低負荷時に、アプリケーション・サービスのサーバがアプリケーション・サービスから自由プール２０２内に移動する。逆に、ステップ３０１で決定された高負荷時に、サーバが自由プール２０２からアプリケーション・サービス内に移動して戻る。

次に、処理はステップ３０７および３０８に続き、そこで上述の電力管理ポリシーが適用される。ステップ３０７では、ステップ３０５でサーバに対して行われる１回または複数回の移行により自由プール２０２のサーバに加えられた電力に関して判断が行われる。自由プール２０２のサーバに加えられた電力の現行レベルが十分なものであり、いかなる変更も不要であると判定された場合、処理はステップ３０１に続く。これに対して、より多くのサーバをホット・スタンバイ・モードにする必要があるかまたはより少ないサーバが必要であると判定された場合、処理はステップ３０８に続き、そこで１つまたは複数のサーバの電力操作レベルが設定される。ステップ３０８では、上記で論じた電力管理ポリシーが適用される。上述の通り、これらのポリシーでは、ステップ３０１および３０２で決定されたワークロードおよびトポロジを考慮に入れる。所定のしきい値に基づいてホット・スタンバイ状態２０３になっている自由プール２０２内のサーバの数を増加することができるとこれらの電力管理ポリシーが判定した場合、低電力状態２０５の自由プール・サーバをホット・スタンバイ状態２０３に設定することができる。他の所定のしきい値に基づいてホット・スタンバイ状態２０３になっている自由プール２０２内のサーバの数を減少することができるとこの電力管理ポリシーが判定した場合、ホット・スタンバイ状態２０３の自由プール・サーバを低電力状態２０５に設定することができる。これらの電力しきい値は、同じものまたは異なるものにすることができ、互いに依存するものまたは互いに独立したものにすることができる。１つまたは複数の電力レベルが設定されると、処理はステップ３０１に続き、そこで処理が繰り返される。

図４は、ハードウェア装置４００として実現された本発明の代替実施形態を示している。装置４００は、上述した通り、また以下に詳述する通り、サーバ４０９の電力をモニターし、感知し、移動し、制御する。サーバ４０９は、これまでに述べたサーバのいずれかまたは複数サーバの層のいずれかにすることができる。装置４００は、ワークロード・モニター４０１と、トポロジ・センサ４０２と、移動モジュール４０５と、電力コントローラ４０８からなり、本明細書で上述した電力および冗長管理ポリシーを実現する。ワークロード・モニター４０１は、それぞれのサーバ４０９のワークロードを決定し、図３に関してステップ３０１で述べた機能を類似的に実行する。トポロジ・センサ４０２は、それぞれのサーバ４０９のトポロジを決定し、図３に関してステップ３０２で述べた機能を同様に実行する。移動モジュール４０５は、図３に関して述べたステップ３０４および３０５に類似してサーバ４０９に作用する。電力コントローラ４０８は、それぞれのサーバ４０９の電力設定を制御し、図３に関してステップ３０７および３０８で述べた機能を類似的に実行する。さらに、装置４００は、サーバ４０９に結合されたときに本明細書で上述した機能を実行する単一ユニットとして実現することができる。代わって、装置４００は、ユニット４０１、４０２、４０５、および４０８の分散シリーズとして実現することができる。装置４００は、ゲート・アレイ、マイクロプロセッサ、マイクロコンピュータ、カスタムＶＬＳＩモジュール、組込みネットワーク・プロセッサなど、当技術分野で知られている様々なハードウェア実現方法のいずれかで構築することができる。

本発明の好ましい一実施形態により省電力化概念が配置された例示的なアプリケーション・サービスのトポロジ図である。 アプリケーション・サービスと自由プールとの間のサーバの移動を含み、本発明の好ましい一実施形態による図１のアプリケーション・サービスのサーバの設備を示す図である。自由プールのサーバは、ホット・スタンバイ状態および低電力状態に保持されている。 本発明の好ましい一実施形態の教示による電力および冗長管理ポリシーの流れ図である。 装置の形で実現された本発明の代替実施形態のブロック図である。

Claims (14)

1. コンピュータ上で実行されたときに、
   （ａ）アプリケーション・サービスを提供する複数サーバのクラスタのうちの各サーバのワークロードを決定するステップと、
   （ｂ）前記アプリケーション・サービスのトポロジを決定するステップであって、前記トポロジの決定が、前記アプリケーション・サービスの第１のコンポーネントと前記第１のコンポーネントが実行される前記サーバとの通信を含むステップと、
   （ｃ）前記ワークロードの決定および前記トポロジの決定に基づいて、前記複数サーバのクラスタのうちの少なくとも１つのサーバの電力状態を設定するステップと、
   を実行するように適合されたプログラム・コード手段を有するコンピュータ・プログラム。
2. 前記ワークロードの決定が所定のしきい値より下のワークロードを決定したときに、前記設定するステップ（ｃ）が低電力状態になる、請求項１に記載のコンピュータ・プログラム。
3. 前記設定するステップ（ｃ）がさらに、サーバ・リソースが完全に使用される程度に基づいて行われる、請求項２に記載のコンピュータ・プログラム。
4. 前記トポロジの決定がアクティブ・サーバの総数のうちの第１のカウントを含み、前記設定するステップ（ｃ）がさらに、前記第１のカウントに対するパワーオン非アクティブ・サーバの比率の関数であり、最小数のパワーオン非アクティブ・サーバを設定するための規定を含む、請求項２に記載のコンピュータ・プログラム。
5. 前記ワークロードの決定が前記１つのサーバが最後にリセットされてからの経過時間を示すワークロードを決定したときに、前記設定するステップ（ｃ）が低電力状態になる、請求項１に記載のコンピュータ・プログラム。
6. 前記ワークロードの決定が所定のしきい値より上のワークロードを決定したときに、前記設定するステップ（ｃ）がパワーオン状態になる、請求項１に記載のコンピュータ・プログラム。
7. 複数サーバのクラスタのうちの各サーバのワークロードを決定する前記ステップが、アプリケーション・サービスを提供する第１の層の複数スケーラブル冗長サーバのうちの各サーバのワークロードを決定するステップを有し、前記トポロジの決定が、アクティブな第１層サーバの前記総数のうちの第１のカウントと、前記アプリケーション・サービスの前記第１のコンポーネントと前記第１のコンポーネントが実行される前記第１層サーバとの通信とを含み、
   前記コンピュータ・プログラム手段が、コンピュータ上で実行されたときに、
   （ｅ）前記ワークロードの決定に基づいて、前記アプリケーション・サービスと前記第１層サーバの自由プールとの間で第１層サーバを移行するステップ
   を実行するようにさらに適合され、
   前記設定するステップ（ｃ）が、
   （ｆ）前記トポロジの決定に基づいて、前記ワークロードの決定に基づく第１の所定の電力管理ポリシーにより、前記第１層サーバの自由プールの前記サーバのそれぞれに加えられた前記電力を制御するステップ
   を有する、請求項１に記載のコンピュータ・プログラム。
8. （ｇ）前記アプリケーション・サービスを提供する第２の層の複数スケーラブル冗長サーバのうちの各サーバのワークロードを決定するステップであって、前記第２の層の複数スケーラブル冗長サーバからの応答が前記第１の層の複数スケーラブル冗長サーバからの応答に依存するステップと、
   （ｈ）前記アプリケーション・サービスと第２層サーバの自由プールとの間で第２層サーバを移行するステップであって、
   前記トポロジの決定がアクティブな第２層サーバの総数のうちの第２のカウントをさらに含むステップと、
   （ｉ）第２の所定の電力管理ポリシーにより、前記トポロジの決定に基づいて、前記第２層サーバの自由プールの前記サーバのそれぞれに加えられた前記電力を制御するステップであって、
   前記第２の電力管理ポリシーが、前記第１の電力管理ポリシーおよび前記第１の電力管理ポリシーとは無関係のポリシーからなるグループから選択されたポリシーであるステップと、
   をさらに有する、請求項７に記載のコンピュータ・プログラム。
9. 前記ワークロードの決定が所定のしきい値より下のワークロードを決定したときに、前記移行するステップが前記アプリケーション・サービスから前記第１層サーバの自由プールに行われる、請求項７に記載のコンピュータ・プログラム。
10. 前記移行するステップがさらに、前記移行する第１層サーバのサーバ・リソースが完全に使用される程度に基づいて行われる、請求項９に記載のコンピュータ・プログラム。
11. 前記ワークロードの決定が所定のしきい値より上のワークロードを決定したときに、前記移行するステップが前記第１層サーバの自由プールから前記アプリケーション・サービスに行われる、請求項７に記載のコンピュータ・プログラム。
12. 前記第１層サーバの自由プールの前記サーバに適用される前記第１の所定の電力管理ポリシーが第１の数のサーバをパワーオン非アクティブ状態に維持し、残りのサーバが低電力状態に設定される、請求項７に記載のコンピュータ・プログラム。
13. （ａ）アプリケーション・サービスを提供する複数サーバのクラスタのうちの各サーバのワークロードを決定するステップと、
    （ｂ）前記アプリケーション・サービスのトポロジを決定するステップであって、前記トポロジの決定が、前記アプリケーション・サービスの第１のコンポーネントと前記第１のコンポーネントが実行される前記サーバとの通信を含むステップと、
    （ｃ）前記ワークロードの決定および前記トポロジの決定に基づいて、前記複数サーバのクラスタのうちの少なくとも１つのサーバの電力状態を設定するステップと、
    を有する方法。
14. アプリケーション・サービスを提供する複数サーバのクラスタのうちの各サーバのワークロードを検出するワークロード・モニターと、
    前記アプリケーション・サービスの第１のコンポーネントと前記第１のコンポーネントが実行される前記サーバとの通信を含み、前記アプリケーション・サービスのトポロジを決定するトポロジ・センサと、
    前記ワークロード・モニターによって決定された前記ワークロードおよび前記トポロジ・センサによって決定された前記トポロジに基づいて、前記複数サーバのクラスタのうちの少なくとも１つのサーバの電力状態を設定する電力コントローラと、
    を有する装置。

Images