(57)【特許請求の範囲】
【請求項１】
（ａ）アプリケーション・サービスを提供する第１層の複数スケーラブル冗長サーバのクラスタのうちの各第１層サーバのワークロードを決定するステップと、
（ｂ）前記アプリケーション・サービスのトポロジを決定するステップであって、前記決定されたトポロジを表すトポロジ情報が、前記アプリケーション・サービスで現在アクティブな第１層サーバの総数を表す第１のカウントと、前記アプリケーション・サービスの第１のコンポーネントと前記第１のコンポーネントが実行される前記第１層サーバとの対応を含むステップと、
（ｃ）前記決定されたワークロードを表すワークロード情報に基づいて、前記アプリケーション・サービスと前記アプリケーション・サービスで現在アクティブでない第１層サーバの自由プールとの間で一の第１層サーバを移行するステップと、
（ｄ）前記ワークロード情報および前記トポロジ情報に基づいて、第１の所定の電力管理ポリシーにより、前記第１層サーバの自由プールの前記第１層サーバのそれぞれに加えられる電力を制御するステップとを有し、
前記第１の所定の電力管理ポリシーが、第１の数の第１層サーバをパワーオン非アクティブ状態に維持し、残りの第１層サーバを低電力状態に設定する方法。
【請求項２】
前記ワークロード情報が所定のしきい値より下のワークロードを表すときに、前記移行するステップ（ｃ）が、前記アプリケーション・サービスから前記第１層サーバの自由プールに行われる、請求項１に記載の方法。
【請求項３】
前記移行するステップ（ｃ）がさらに、前記移行する第１層サーバのサーバ・リソースが完全に使用される程度に基づいて行われる、請求項２に記載の方法。
【請求項４】
前記ワークロード情報が所定のしきい値より上のワークロードを表すときに、前記移行するステップ（ｃ）が、前記第１層サーバの自由プールから前記アプリケーション・サービスに行われる、請求項１に記載の方法。
【請求項５】
前記第１の所定の電力管理ポリシーが、前記第１のカウントに対する前記第１の数の比率の関数であり、最小数のパワーオン非アクティブ第１層サーバを設定するための規定を含む、請求項１に記載の方法。
【請求項６】
前記低電力状態が、スタンバイ状態、スリープ状態、ハイバネート状態およびオフ状態からなるグループから選択された状態である、請求項１に記載の方法。
【請求項７】
請求項１ないし請求項６の何れか１項に記載の方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラム。
【請求項８】
アプリケーション・サービスを提供する第１層の複数スケーラブル冗長サーバのうちの各第１層サーバのワークロードを検出するワークロード・モニターと、
前記アプリケーション・サービスのトポロジを決定するトポロジ・センサであって、前記決定されたトポロジを表すトポロジ情報が、前記アプリケーション・サービスで現在アクティブな第１層サーバの総数を表す第１のカウントと、前記アプリケーション・サービスの第１のコンポーネントと前記第１のコンポーネントが実行される前記第１層サーバとの対応を含むトポロジ・センサと、
前記ワークロード・モニターによって決定された前記ワークロードを表すワークロード情報に基づいて、前記アプリケーション・サービスと前記アプリケーション・サービスで現在アクティブでない第１層サーバの自由プールとの間で一の第１層サーバを移行する移動モジュールと、
前記ワークロード情報および前記トポロジ情報に基づいて、第１の所定の電力管理ポリシーにより、前記第１層サーバの自由プールの前記第１層サーバのそれぞれの電力状態を設定する電力コントローラとを有し、
前記第１の所定の電力管理ポリシーが、第１の数の第１層サーバをパワーオン非アクティブ状態に維持し、残りの第１層サーバを低電力状態に設定する装置。
【請求項９】
前記第１の所定の電力管理ポリシーが、前記第１のカウントに対する前記第１の数の比率の関数であり、最小数のパワーオン非アクティブ第１層サーバを設定するための規定を含む、請求項８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスタ化コンピューティング・システムおよびその他のクラスタ化情報処理システムに関する。
【背景技術】
【０００２】
負荷が大きいインターネット・アプリケーション・サービスの要求に応じるために、アプリケーション・サービスのプロバイダは、アプリケーション・サービスの応答時間を増加するために冗長性に頼っていた。冗長性とは、概して、１つまたは複数の機能的に同一のサーバをアプリケーション・サービスに追加することを指す。単一の物理サーバが論理的に複数のサーバとして動作する場合、その複数のサーバは一般に仮想サーバと呼ばれる。冗長サーバ環境でサーバを追加する場合、追加するサーバは物理サーバまたは仮想サーバにすることができる。
【０００３】
負荷が大きいインターネット・アプリケーション・サービスに配置されたネットワークは、概して、有限数のネットワーク・ノードを含む。各ノードには、１つのサーバまたは複数のサーバが存在する。その１つのサーバまたは複数のサーバは、仮想サーバまたは物理サーバあるいは両者の任意の組合せにすることができる。
【０００４】
サービス・プロバイダは、概して、様々な時点でアプリケーション・サービスを提供するために、複数のカスタマ間に割り振ることができる多数のノードを有する。提供されるワークロードは時間の経過につれて変動する可能性があるので、設備内のノードの数がサービスを提供するために必要なノードの数を上回る場合もあるであろう。過剰サーバが電力およびその他のリソースを消費するので、これはサービス・プロバイダに対して問題を提起するものである。非アクティブであって依然としてパワーオン状態であるサーバは、より多くの電力を消費するだけでなく、全パワーオン時間に相関する信頼性コンポーネントについて信頼性の低減にも陥りやすい。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
コスト節約を最大限にするためには、できるだけ多くのサーバをパワーオフすることが有益であると思われるであろう。しかし、サーバをパワーオフすると、サービス・プロバイダは、アプリケーション・サービスを提供するサーバのピーク負荷または障害発生時に十分素早くサーバを設定することができないというリスクに曝される。
【課題を解決するための手段】
【０００６】
本発明は、好ましくは、ピーク負荷またはサーバ障害発生時に十分素早くサーバを設定することができないというリスクを避けながら、同時に非アクティブ・サーバをパワーダウンしようとするインターネット・アプリケーション・サービスのプロバイダに解決策を提供するものである。一実施形態では、アプリケーション・サービスを提供する複数サーバのクラスタのうちの各サーバのワークロードが決定される。次に、アプリケーション・サービスのトポロジが決定される。このトポロジ情報は、アプリケーション・サービスのコンポーネントとそのコンポーネントが実行されるサーバとの対応（correspondence）を含む。次に、このワークロードおよびトポロジ情報に基づいて、１つまたは複数のサーバの電力状態が変更される。
【０００７】
この好ましい実施形態では、本発明の概念は、コンピュータ・プログラムの形で提供される。このプログラムは、カスタマのために、フレキシブル・ディスクまたはＣＤ−ＲＯＭなどのコンピュータ可読媒体で配布され、既存の（または提供された）コンピュータ・システムにインストールされる。
【０００８】
他の一実施形態では、本発明の概念は、装置の形で提供され、サーバ自体を含むことができる。
【０００９】
さらに他の一実施形態では、本発明の概念は、装置およびプログラムまたは方法の形でならびに任意の組合せで提供され、管理されるサーバを含むことができる。
【００１０】
次に、一例として、添付図面に関連して、本発明の好ましい諸実施形態について説明する。
【発明を実施するための最良の形態】
【００１１】
次に、より詳細に添付図面を参照すると、図１は、本発明の省電力化概念が使用される例示的なアプリケーション・サービスのトポロジを示している。図１のアプリケーション・サービスは、Ｗｅｂサーバ１００と、ネットワーク・ディスパッチャ１０１および１０２からなる。ネットワーク・ディスパッチャ１０１および１０２は、ＷｅｂサーバにＷｅｂ要求を配布するロード・バランシング・コンポーネントとして機能する。図１には単一のホット・スタンバイ・ネットワーク・ディスパッチャ１０２が示されているが、アプリケーション・サービスは、任意の数のネットワーク・ディスパッチャを有することができ、そのうちの任意のサブセットがホット・スタンバイ状態で機能する。ネットワーク・ディスパッチャの機能については、以下により詳細に説明する。また、ホット・スタンバイという用語についても、好ましい諸実施形態の説明が進むにつれて説明することにする。複数のＷｅｂサーバ１００は、Ｗｅｂページを供給する機能を実行するものであり、機能的に同一である。ネットワーク・ディスパッチャ１０１は、インターネットからＷｅｂページに関する要求を受信し、その要求をＷｅｂサーバ１００に転送する。Ｗｅｂサーバ１００は、個々の要求を処理し、インターネット上のクライアントに個々の応答を返送する。ホット・スタンバイ・ネットワーク・ディスパッチャ１０２は、ネットワーク・ディスパッチャ１０１側の障害の場合にネットワーク・ディスパッチャ１０１の役割を引き継ぐために使用する。図１のアプリケーション・サービスは、３つのサーバと２つのネットワーク・ディスパッチャとともに示されている。しかし、一般に、アプリケーション・サービスは、任意の数のＷｅｂサーバと、任意の数のネットワーク・ディスパッチャとを含むことができる。さらに、アプリケーション・サービスは、Ｗｅｂサーバ用の層１と、ネットワーク・ディスパッチャ用の層２という２つの層のサーバを有するものとして示されている。それにもかかわらず、アプリケーション・サービスは、任意の数の層の冗長サーバを含むことができる。各層は、アプリケーション・サービス内の１つの別個の機能を実行する。たとえば、Ｗｅｂサーバ１００に情報をフィードするＷｅｂまたはデータベース・アプリケーションを実行するサーバ用として、もう１つの層を追加することができる。実際に、スケーラブル冗長アーキテクチャから恩恵を受けることができるサーバ機能は、本発明の概念からも恩恵を受けることができる。たとえば、このような機能としては、プロキシ・キャッシュ、ＦＴＰ、ＤＮＳ、Ｇｏｐｈｅｒ、ＦｒｏｎｔＰａｇｅ（商標）、および認証機能を含む。データベース・アプリケーションは、ＩＢＭのＳＱＬ（商標）などのリレーショナル・データベースを含む、任意のデータベース・アプリケーションにすることができる。
【００１２】
負荷（ロード）という用語は、単位時間あたりネットワーク・ディスパッチャ１０１に到着する要求の数として定義することができる。好ましい実施形態によれば、アプリケーション・サービスにかかる負荷が小さい場合、アプリケーション・サービスから特定のサーバを除去することにより、アプリケーション・サービスに使用するサーバの数が削減される。その場合、アプリケーション・サービスから除去されたサーバのサブセットによって消費される電力の量を制御することにより、電力が削減される。さらに、アプリケーション・サービスがワークロードに応じるために十分なオンライン・パワーオン能力に加え、１つまたは複数の追加のサーバの形で特定の量のスペア・オンライン・パワーオン能力を有するように、任意の所与の層のサーバに関する冗長管理ポリシーが実現される。図１に示す例の場合、アプリケーション・サービスにかかる負荷が非常に小さい場合、たとえば、複数のＷｅｂサーバのうちの１つをパワーオフすることにより、アプリケーション・サービスに使用するＷｅｂサーバ１００の数を、たとえば、３から２に削減することができる。さらに、複数のＷｅｂサーバを完全にパワーオフするのではなく、スタンバイ、スリープ、ハイバネート（hibernate）、およびその他の省電力化状態およびモードなどの業界標準の半（semi）パワーオン状態または超低電力状態のうちの１つに電力状態を設定することにより、電力を節約することも可能である。スタンバイ状態は、以下に説明するホット・スタンバイ状態から独立した別個の状態であることに留意されたい。
【００１３】
図２は、アプリケーション・サービスで同一機能を実行する複数冗長サーバの層に含まれるサーバの設備および動作状態を示している。サーバは、そのサーバが経験するワークロードに応じて、アプリケーション・サービスのアクティブ状態２０１と自由プール２０２との間で移動する。アクティブ状態２０１は、サーバがアプリケーション・サービスに従事している完全パワーオン状態である。自由プール２０２内のサーバは、考慮中の特定のアプリケーション・サービスで非アクティブになっている。前述の通り、アプリケーション・サービスのワークロード要求に応じるために十分なオンライン・パワーオン能力に加え、１つまたは複数の追加のサーバの形で特定の量のスペア・オンライン・パワーオン能力を保証する冗長管理ポリシーが実現される。このようなスペア・オンライン・パワーオン・サーバは、ホット・スタンバイ・サーバと呼ばれる。この冗長管理ポリシーにより、自由プール２０２の特定の数のサーバがホット・スタンバイ状態２０３に保持される。このようなホット・スタンバイ・サーバは、アプリケーション・サービスでは非アクティブであるが、アプリケーション・サービスに対するワークロード要求が所定のしきい値を超える場合に素早くアクティブ状態２０１に設定することができる。電力を削減するために、ホット・スタンバイ状態で保持されない自由プール２０２のサーバは、低電力状態２０４に設定することができる。
【００１４】
好ましい実施形態では、アクティブ状態２０１と自由プール２０２との間ならびに自由プール内のホット・スタンバイ状態２０３と低電力状態２０４との間でサーバを移行するときに、アプリケーション・サービスのトポロジも考慮に入れる。トポロジの決定は多くの形を取ることができ、本明細書では様々な例が示されることになる。しかし、これらの例は、本発明の範囲を制限するものと解釈すべきではない。第１の例としてのトポロジの決定は、アプリケーション・サービスで現在アクティブのサーバの総数を決定するという形を取ることができる。もう１つの例のトポロジの決定は、それぞれのサーバの個々の正常性（health）を決定するという形を取ることができる。正常性を決定する際に、トポロジの決定は、残りのメモリの量あるいはメモリ、ＣＰＵ、入出力（Ｉ／Ｏ）、または任意のその他のシステム・リソースが枯渇している程度に焦点を合わせることができる。正常性を決定する際に、特定のオペレーティング・システムは時々リセット（リブート／再始動）する必要があることは周知のことであり、したがって、トポロジの決定は、任意の所与のサーバがリセットされてから経過した時間の総量に焦点を合わせることができる。また、いかなる種類のシステム・ボトルネックも考慮に入れることができる。
【００１５】
さらに他の例では、アプリケーション・サービスは仮想サーバ環境で動作する。仮想サーバ環境では、必ずしも仮想サーバと物理サーバとの間に１対１の対応が存在するわけではない。この環境では、トポロジの決定は、物理サーバが２つ以上の機能を実行しているかどうかまたは物理サーバが２つ以上の層の冗長サーバに関係しているかどうかを考慮することになる。たとえば、１つの物理サーバは、数百もの仮想Ａｐａｃｈｅサーバを実行している可能性がある。この例では、すべてのＡｐａｃｈｅサーバが同じ層内で動作しており、冗長なものである。さらに他の例では、物理サーバは、プロキシ・キャッシュ層またはネットワーク・ディスパッチャ層などの複数の層の仮想アプリケーションを実行することができる。この仮想サーバ環境では、あるサーバを低電力状態２０４に設定する前に、任意の所与の物理サーバ内のすべての仮想サーバのトポロジを考慮に入れ、物理サーバによって実行される仮想機能のすべてが自由プール２０２内にあり、ホット・スタンバイ状態２０３になっていると判定されない限り、物理サーバをパワーダウンしない。適切なワークロードの決定およびトポロジの決定が行われ、アプリケーション・サービスの要求に応じるために十分な数のホット・スタンバイ・サーバが自由プール内に存在すると判定されると、その場合のみ、物理サーバは低電力状態に設定されるかまたは完全にパワーオフされることになる。
【００１６】
次に、トポロジの決定およびワークロードの決定のより具体的な例を示す。この例では、各機能型あたりホット・スタンバイ状態２０３に保持すべきサーバの数は、以下のパラメータによって定義される。この場合、機能型は、複数冗長サーバの層によって実行される機能を指す。
ｍｉｎＨｏｔＩｎＦｒｅｅＰｏｏｌ−このパラメータは、自由プール内のこの機能型の最小数のホット・スタンバイ・サーバを設定するための規定を提供する。
ａｄｄＯｎｌｉｎｅＲａｔｉｏ−このパラメータは、アプリケーション・サービスに積極的に関与するこの機能型のサーバの数と、ホット・スタンバイ状態２０３に保持されるであろうこの機能型の追加サーバの数との所望の比率を表す。たとえば、１００個のサーバがアプリケーション・サービスに積極的に関与しており、ａｄｄＯｎｌｉｎｅＲａｔｉｏの値が２０である場合、この特定のアプリケーション・サービスは、自由プール２０２内に１００／２０＝５個のホット・スタンバイ・サーバを必要とすることになるであろう。自由プール２０２内の全サーバが１５であった場合、残りの１５−５＝１０個のサーバはパワーオフするか、あるいは低電力動作モードに設定することができる。
ｄｅｐｌｏｙｅｄＩｎＡｌｌＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｉｃｅｓ−このパラメータは、現在、サービス・プロバイダの環境に関与しているこの機能型のサーバの総数を示す。
ｈｏｔＳｅｒｖｅｒｓＩｎＦｒｅｅＰｏｏｌ−このパラメータは、自由プール２０２内にあるべきホット・スタンバイ・サーバの数を表す。
【００１７】
次に、ホット・スタンバイ状態２０３に保持すべき特定の機能型のサーバの数は、以下のように決定される。
【数１】
hotServersInFreePool =
minHotInFreePool + (deployedInApplicationServices/addOnlineRatio)
【００１８】
代替実施形態では、ｈｏｔＳｅｒｖｅｒｓＩｎＦｒｅｅＰｏｏｌは、以下のように計算することができる。
【数２】
hotServersinFreePool =
(minHotInFreePool > (deployedInApplicationServices/addOnlineRatio)?
minHotInFreePool :
minHotInFreePool + (deployedInApplicationServices/addOnlineRatio)
【００１９】
この例の電力管理システムは、自由プール２０２内の特定の型のホット・サーバの数をｈｏｔＳｅｒｖｅｒｓＩｎＦｒｅｅＰｏｏｌに等しくなるように維持しようと試みる。自由プール２０２内の残りのサーバは、低電力状態２０４にすることができる。
【００２０】
本発明の好ましい実施形態では、次に図１および図２の両方を参照すると、複数冗長サーバの各層ごとに個別に冗長および電力管理ポリシーが適用される。これらの層は、図１に層１および層２として示されており、破線で囲まれている。各機能型は固有のニーズを有する可能性があるので、このポリシーは個別に適用される。たとえば、ホット・スタンバイ状態２０３に保持すべきサーバの最小数は、機能型によって変動する可能性がある。Ｗｅｂサーバ１００の最小数は、ほぼ任意の数にすることができるが、ホット・スタンバイ・ネットワーク・ディスパッチャ１０２の最小数は、より特定のものにすることができる。ホット・スタンバイ・ネットワーク・ディスパッチャ１０２は、必ずしも常に使用されるわけではないが、現行ネットワーク・ディスパッチャ１０１の障害の場合にアクティブな役割を引き継ぐ必要があるので、パワーオフすることができない。電力および冗長管理ポリシーは、ネットワーク・ディスパッチャに関して、（１）少なくとも２つのネットワーク・ディスパッチャ・サーバが常にオンラインでなければならず、（２）追加のワークロードに応じるためにネットワーク・ディスパッチャをパワーオンすることができ、（３）少なくとも２つが常にオンラインである限り、ワークロードが減衰したときにネットワーク・ディスパッチャをパワーオフすることができるように、指定することができる。代替的に、１つのアプリケーション・サービスの様々な層に適用される電力および冗長管理ポリシーは、同じものにすることができる。
【００２１】
図３は、好ましい一実施形態の教示による電力および冗長管理ポリシーの流れ図である。ステップ３０１では、複数冗長サーバの層の各サーバのワークロードが決定される。任意の所与のサーバのワークロードは、全体としてアプリケーション・サービスにかかる負荷に直接関連し、さらにサーバ固有の属性（attribute）に依存する。サーバのワークロードの決定は、当技術分野では周知のものであり、したがって、これ以上詳細に説明しない。ワークロードが決定されると、処理はステップ３０２に移行する。ステップ３０２では、トポロジの決定に関する上記の考察通りにアプリケーション・サービスのトポロジが決定される。トポロジの決定は、アプリケーション・サービスのコンポーネントと、そのコンポーネントが実行されるサーバのアカウンティング（accounting）を含む。アプリケーション・サービスが仮想サーバを使用する場合、仮想サーバおよび対応する物理サーバに関して、さらにトポロジの決定が行われる。ステップ３０１および３０２によりワークロードおよびトポロジが決定されると、処理はステップ３０４に続き、そこで任意の特定のサーバの移行が必要であるかどうかが判定される。
【００２２】
アプリケーション・サービスにかかる負荷が所定の高負荷しきい値および低負荷しきい値を超えるかまたはそれらに適合しない場合、サーバの移行が必要になる。いずれのしきい値にも適合しない場合、処理はステップ３０１に続く。これに対して、一方のしきい値に適合する場合、処理はステップ３０５に続き、そこで以下の基準に従ってサーバが移動する。ステップ３０５では、ステップ３０１で決定された低負荷時に、アプリケーション・サービスのサーバがアプリケーション・サービスから自由プール２０２内に移動する。逆に、ステップ３０１で決定された高負荷時に、サーバが自由プール２０２からアプリケーション・サービス内に移動して戻る。
【００２３】
次に、処理はステップ３０７および３０８に続き、そこで上述の電力管理ポリシーが適用される。ステップ３０７では、ステップ３０５でサーバに対して行われる１回または複数回の移行により自由プール２０２のサーバに加えられた電力に関して判断が行われる。自由プール２０２のサーバに加えられた電力の現行レベルが十分なものであり、いかなる変更も不要であると判定された場合、処理はステップ３０１に続く。これに対して、より多くのサーバをホット・スタンバイ・モードにする必要があるかまたはより少ないサーバが必要であると判定された場合、処理はステップ３０８に続き、そこで１つまたは複数のサーバの電力操作レベルが設定される。ステップ３０８では、上記で論じた電力管理ポリシーが適用される。上述の通り、これらのポリシーでは、ステップ３０１および３０２で決定されたワークロードおよびトポロジを考慮に入れる。所定のしきい値に基づいてホット・スタンバイ状態２０３になっている自由プール２０２内のサーバの数を増加することができるとこれらの電力管理ポリシーが判定した場合、低電力状態２０４の自由プール・サーバをホット・スタンバイ状態２０３に設定することができる。他の所定のしきい値に基づいてホット・スタンバイ状態２０３になっている自由プール２０２内のサーバの数を減少することができるとこの電力管理ポリシーが判定した場合、ホット・スタンバイ状態２０３の自由プール・サーバを低電力状態２０４に設定することができる。これらの電力しきい値は、同じものまたは異なるものにすることができ、互いに依存するものまたは互いに独立したものにすることができる。１つまたは複数の電力レベルが設定されると、処理はステップ３０１に続き、そこで処理が繰り返される。
【００２４】
図４は、ハードウェア装置４００として実現された本発明の代替実施形態を示している。装置４００は、上述した通り、また以下に詳述する通り、サーバ４０９の電力をモニターし、感知し、移動し、制御する。サーバ４０９は、これまでに述べたサーバのいずれかまたは複数サーバの層のいずれかにすることができる。装置４００は、ワークロード・モニター４０１と、トポロジ・センサ４０２と、移動モジュール４０５と、電力コントローラ４０８からなり、本明細書で上述した電力および冗長管理ポリシーを実現する。ワークロード・モニター４０１は、それぞれのサーバ４０９のワークロードを決定し、図３に関してステップ３０１で述べた機能を類似的に実行する。トポロジ・センサ４０２は、それぞれのサーバ４０９のトポロジを決定し、図３に関してステップ３０２で述べた機能を同様に実行する。移動モジュール４０５は、図３に関して述べたステップ３０４および３０５に類似してサーバ４０９に作用する。電力コントローラ４０８は、それぞれのサーバ４０９の電力設定を制御し、図３に関してステップ３０７および３０８で述べた機能を類似的に実行する。さらに、装置４００は、サーバ４０９に結合されたときに本明細書で上述した機能を実行する単一ユニットとして実現することができる。代替的に、装置４００は、ユニット４０１、４０２、４０５、および４０８の分散シリーズとして実現することができる。装置４００は、ゲート・アレイ、マイクロプロセッサ、マイクロコンピュータ、カスタムＶＬＳＩモジュール、組込みネットワーク・プロセッサなど、当技術分野で知られている様々なハードウェア実現方法のいずれかで構築することができる。
【図面の簡単な説明】
【００２５】
【図１】本発明の好ましい一実施形態により省電力化概念が配置された例示的なアプリケーション・サービスのトポロジ図である。
【図２】アプリケーション・サービスと自由プールとの間のサーバの移動を含み、本発明の好ましい一実施形態による図１のアプリケーション・サービスのサーバの設備を示す図である。自由プールのサーバは、ホット・スタンバイ状態および低電力状態に保持されている。
【図３】本発明の好ましい一実施形態の教示による電力および冗長管理ポリシーの流れ図である。
【図４】装置の形で実現された本発明の代替実施形態のブロック図である。
【図１】
0004370255.tif 000002
【図２】
0004370255.tif 000003
【図３】
0004370255.tif 000004
【図４】
0004370255.tif 000005