(57)【特許請求の範囲】
【請求項１】
コンピューティングデバイスにより実行されたときに、前記コンピューティングデバイスに、
アクティブ状態及び少なくとも２つの異なる非アクティブ状態により構成される複数のサーバを含むサーバプールにおける今後の作業負荷を予測し、該予測された作業負荷に対してサーバ管理ポリシーを構築するステップであって、
比較的長期間のモデル、現在の傾向又は外部の知識の分析に基づいて、前記サーバプールへの今後のリクエスト数を予測するステップと、
今後のリクエストに対する応答時間を、今後のリクエスト数及び前記サーバプールにおけるアクティブサーバ数の関数としてモデル化するステップであって、前記サーバプールが今後のリクエストを処理して応答するための時間の分布を使用して、前記応答時間をモデル化するステップと、
所定のレベルの応答時間を維持するために、前記アクティブ状態及び前記少なくとも２つの異なる非アクティブ状態において動作すべきサーバの数を計算するステップと
を含む、今後の作業負荷を予測してサーバ管理ポリシーを構築するステップと、
前記サーバ管理ポリシーに基づいて、前記アクティブ状態及び前記少なくとも２つの異なる非アクティブ状態の各々にあるサーバの数を調整するステップであって、
前記サーバプール内の個々のサーバを順序付けるステップと、
前記アクティブ状態と前記少なくとも２つの異なる非アクティブ状態とを含むエネルギ状態を順序付けるステップと、
前記アクティブ状態及び前記少なくとも２つの異なる非アクティブ状態の各々について前記計算されたサーバの数を充足するように、前記個々のサーバに対する順序付けと前記エネルギ状態に対する順序付けとに基づいて、前記サーバプール内の個々のサーバを、前記アクティブ状態と前記少なくとも２つの非アクティブ状態のそれぞれの間で遷移させるステップと
を含む、調整するステップと
を実行させる、コンピュータプログラム。
【請求項２】
前記サーバ管理ポリシーは、前記サーバプール内の個々のサーバが動作している容量を示す性能カウンタと、単位時間当たりのリクエスト率、リクエスト規模及びリクエスト応答時間のうちの少なくとも１つを含むリクエスト情報と、個々のサーバの性能情報を示すエネルギ利用情報とのうちの少なくとも１つに基づいて構築され、
前記今後のリクエスト数を予測するステップは、前記今後のリクエスト数に加えて、今後のリクエスト規模及び今後のリクエスト内容を予測することを含む、請求項１に記載のコンピュータプログラム。
【請求項３】
前記計算するステップは、前記サーバプール内の個々のサーバのサーバ寿命に対する状態遷移の悪影響を考慮するステップである、請求項１に記載のコンピュータプログラム。
【請求項４】
非アクティブ状態は、オフ状態、スリープ状態及びハイバネート状態のいずれかであり、
前記計算するステップは、非アクティブ状態からアクティブ状態への遷移レイテンシ期間と個々の非アクティブ状態に関連する電力節約との両方を考慮する、請求項１に記載のコンピュータプログラム。
【請求項５】
前記状態を遷移させるステップは、信号を前記サーバプール内の個々のサーバに送信し、前記アクティブ状態と前記少なくとも２つの異なる非アクティブ状態との間で状態遷移を起こさせる、請求項１に記載のコンピュータプログラム。
【請求項６】
コンピューティングデバイスが、アクティブ状態及び少なくとも２つの異なる非アクティブ状態で構成される複数のサーバを含むサーバプールにおける今後の作業負荷を予測し、該予測された作業負荷に対してサーバ管理ポリシーを構築するステップであって、
コンピューティングデバイスが、比較的長期間のモデル、現在の傾向又は外部の知識の分析に基づいて、前記サーバプールへの今後のリクエスト数を予測するステップと、
コンピューティングデバイスが、今後のリクエストに対する応答時間を、今後のリクエスト数及び前記サーバプールにおけるアクティブサーバ数の関数としてモデル化するステップであって、前記サーバプールが今後のリクエストを処理して応答するための時間の分布を使用して前記応答時間をモデル化する、ステップと、
コンピューティングデバイスが、所定のレベルの応答時間を維持するために、前記アクティブ状態及び前記少なくとも２つの非アクティブ状態において動作すべきサーバの数を計算するステップと、
を含む、今後の作業負荷を予測してサーバ管理ポリシーを構築するステップと、
コンピューティングデバイスが、前記サーバ管理ポリシーに基づいて、前記アクティブ状態及び前記少なくとも２つの異なる非アクティブ状態の各々にあるサーバの数を調整するステップであって、
前記サーバプール内の個々のサーバを順序付けるステップと、
前記アクティブ状態と前記少なくとも２つの異なる非アクティブ状態とを含むエネルギ状態を順序付けるステップと、
前記アクティブ状態及び前記少なくとも２つの異なる非アクティブ状態の各々について前記計算されたサーバの数を充足するように、前記個々のサーバに対する順序付けと前記エネルギ状態に対する順序付けとに基づいて、前記サーバプール内の個々のサーバを、前記アクティブ状態と前記少なくとも２つの非アクティブ状態のそれぞれの間で遷移させるステップと
を含む、調整する
を含む、方法。
【請求項７】
前記サーバ管理ポリシーは、前記サーバプール内の個々のサーバが動作している容量を示す性能カウンタと、単位時間当たりのリクエスト率、リクエスト規模及びリクエスト応答時間のうちの少なくとも１つを含むリクエスト情報と、個々のサーバの性能情報を示すエネルギ利用情報とのうちの少なくとも１つに基づいて構築され、
前記今後のリクエスト数を予測するステップは、前記今後のリクエスト数に加えて、前記サーバプール中の個々のサーバへの今後のリクエスト規模及び今後のリクエスト内容を予測することを含む、請求項６に記載の方法。
【請求項８】
前記計算するステップは、個々のサーバのサーバ寿命に対する状態遷移の悪影響を考慮するステップである、請求項６に記載の方法。
【請求項９】
非アクティブ状態は、オフ状態、スリープ状態及びハイバネート状態のいずれかであり、
前記計算するステップは、個々の非アクティブ状態とアクティブ状態との間の遷移レイテンシ期間及び個々の非アクティブ状態に関連する電力節約の両方を考慮する、請求項６に記載の方法。
【請求項１０】
前記状態を遷移させるステップは、信号を前記サーバプール内の個々のサーバに送信し、前記アクティブ状態と前記少なくとも２つの異なる非アクティブ状態との間で状態遷移を起こさせる、請求項６に記載の方法。
【請求項１１】
アクティブ状態及び少なくとも２つの異なる非アクティブ状態で構成される複数のサーバを含むサーバプールにおける今後の作業負荷を予測し、該予測された作業負荷に対してサーバ管理ポリシーを構築することであって、
比較的長期間のモデル、現在の傾向又は外部の知識の分析に基づいて、前記サーバプールへの今後のリクエスト数を予測し、
今後のリクエストに対する応答時間を、今後のリクエスト数及び前記サーバプールにおけるアクティブサーバ数の関数としてモデル化することであって、前記サーバプールが今後のリクエストを処理して応答するための時間の分布を使用して前記応答時間をモデル化し、
所定のレベルの応答時間を維持するために、前記アクティブ状態及び前記少なくとも２つの非アクティブ状態において動作すべきサーバの数を計算する
ことにより、今後の作業負荷を予測してサーバ管理ポリシーを構築するように構成され、
前記サーバ管理ポリシーに基づいて、前記アクティブ状態及び前記少なくとも２つの異なる非アクティブ状態の各々にあるサーバの数を調整することであって、
前記サーバプール内の個々のサーバを順序付け、
前記アクティブ状態と前記少なくとも２つの異なる非アクティブ状態とを含むエネルギ状態を順序付け、
前記アクティブ状態及び前記少なくとも２つの異なる非アクティブ状態の各々について前記計算されたサーバの数を充足するように、前記個々のサーバに対する順序付けと前記エネルギ状態に対する順序付けとに基づいて、前記サーバプール内の個々の前記サーバを、前記アクティブ状態および前記少なくとも２つの非アクティブ状態のそれぞれの間で遷移させる
ことにより、サーバの数を調整するように構成された適応制御ユニットを備え、
コンピューティングデバイスが前記適応制御ユニットを実行するように構成される、コンピュータシステム。
【請求項１２】
前記サーバ管理ポリシーは、前記サーバプール内の個々のサーバが動作している容量を示す性能カウンタと、単位時間当たりのリクエスト率、リクエスト規模及びリクエスト応答時間のうちの少なくとも１つを含むリクエスト情報と、個々のサーバの性能情報を示すエネルギ利用情報とのうちの少なくとも１つに基づいて構築され、
前記適応制御ユニットは、前記今後のリクエスト数に加えて、今後のリクエスト規模及び今後のリクエスト内容を予測するように構成される、請求項１１に記載のシステム。
【請求項１３】
前記適応制御ユニットは、前記サーバプール内の前記個々のサーバのサーバ寿命に対して状態遷移の悪影響を考慮することによりサーバの数を計算するよう構成される、請求項１１に記載のシステム。
【請求項１４】
非アクティブ状態は、オフ状態、スリープ状態及びハイバネート状態のいずれかであり、
前記適応制御ユニットは、個々の非アクティブ状態からアクティブ状態への遷移レイテンシ期間及び個々の非アクティブ状態のそれぞれに関連する電力節約の両方を考慮することによりサーバの数を計算するよう構成される、請求項１１に記載のシステム。
【請求項１５】
前記適応制御ユニットは、信号を前記サーバプール内の個々のサーバに送信し、前記アクティブ状態と前記少なくとも２つの異なる非アクティブ状態との間で状態遷移を起こさせることにより前記個々のサーバに状態遷移を起こさせるように構成される、請求項１１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、エネルギーを意識したサーバ管理に関する。
【背景技術】
【０００２】
データセンターは、莫大な数のコンピュータ（即ち、サーバ）を含むことが多い。このようなサーバの多くは、一時的に利用されていないまたは使用すらされていないが、データセンターに到達するリクエストの急増に対処するために保持されている。例えば、クリスマスに殺到するオンラインのショッピングサイトや夕方に密集する通勤者の交通情報サイトを考えればわかる。現在データセンターで使用されているサーバは、アイドル時でさえも大量のエネルギーを消費している（あるサーバでは、アイドル状態が全エネルギー利用の７０パーセントを占める）。このようなサーバの電源を切ることでエネルギーを節約できるかもしれないが、顧客が急増してパワーオンになっているサーバが足りない場合、ウェブサービスの応答時間にも悪影響を与えるかもしれない。本概念は、データセンターのエネルギー利用を考慮しながら、リクエストサービスの応答時間を満たすやり方でデータセンターを管理することができる。
【発明の概要】
【０００３】
説明されている実施は、エネルギーを意識したサーバ管理に関する。より詳細には、本願は、リクエスト／応答サービスに対するエネルギーを意識したプロビジョニングおよび負荷ディスパッチングのためのツールに関する。
【０００４】
一実施は、事前定義されるレベルでサーバファームの応答時間を保持しながら、個々のサーバがアクティブ状態と非アクティブ状態との間を遷移することによってサーバファーム内のエネルギー利用を管理するように構成される適応制御ユニットを伴う。例えば、事前定義されるレベルは、サービスレベルに関する合意（ＳＬＡ）によって定義し得る。
【０００５】
別の実施において、ツールは、コンピュータセットの今後の作業負荷を予測する。個々のコンピュータは、オン／アクティブ、スリープおよびオフといった、少なくとも２つのエネルギー状態を有する。このツールは、今後予測される作業負荷に対するエネルギーを意識したサーバ管理ポリシーを構築して、そのエネルギーを意識したサーバ管理ポリシーに基づいて個々のコンピュータのエネルギー状態を調整する。
【０００６】
用語「ツール（複数可）」は、例えば、デバイス（複数可）、システム（複数可）、コンピュータ可読命令（例えば、実行可能命令を有する１または複数のコンピュータ可読媒体）、コンポーネント（複数可）、モジュール（複数可）、および／または上記文脈および文書を通じて可能な方法を指すこともある。さまざまな事例において、ツールをハードウェア、ソフトウェア、ファームウェア、またはその組み合わせとして実施できる。上記の例は、即時に参照を提供して読者を支援することを意図し、本明細書で説明される概念の範囲を定義することを意図しない。
【０００７】
添付図面は、本願において表される概念の実施を示す。例示される実施を、以下の説明を添付図とともに参照することによってより容易に理解することができる。さまざまな図面における同様の参照数字は、同様の要素を示すのに適した場所に使用される。さらに、各参照数字の左端の数字は、その参照数字が最初に導入される図面と関連する考察を表す。
【図面の簡単な説明】
【０００８】
【図１】本概念のある実施に従ってエネルギーを意識したサーバ管理の概念を実装するための方法例を示す図である。
【図２】本概念のある実施に従ってエネルギーを意識したサーバ管理を達成するためのシステムの例を示す図である。
【図３】本概念のある実施に従ってエネルギーを意識したサーバ管理を達成するためのコンポーネントの例を示す図である。
【図４】本概念のある実施に従ってエネルギーを意識したサーバ管理方法と関連付けられるフローチャートである。
【図５】本概念のある実施に従ってエネルギーを意識したサーバ管理方法と関連付けられるフローチャートである。
【発明を実施するための形態】
【０００９】
＜要約＞
本特許出願は、エネルギーを意識したサーバ管理に関する。簡単に言えば、本特許は、エネルギー消費量を削減しながら予想される性能レベルでサーバファームなどのコンピュータセットを動作するための概念を説明する。
【００１０】
本概念は、サーバファーム内でユーザリクエストまたは「リクエスト」に応答する多重状態（Ｍｕｌｔｉ−ｓｔａｔｅ）サーバを用いることができる。総合的に考えると、そのようなリクエストを、サーバファームの「作業負荷」と見なすことができる。多重状態サーバは、リクエストを処理することができるアクティブ状態（複数可）と、リクエストを処理しない非アクティブ状態を有することができる。ある多重状態コンピュータは、複数の非アクティブ状態を有することができる。例えば、スリープ、ハイバネートおよび／またはオフは、非アクティブ状態の例にすることができる。非アクティブ状態のサーバは、アクティブ状態のサーバよりも少ないエネルギーを実質的に使用することができる。しかしながら、例えば、非アクティブ状態のサーバからアクティブ状態のサーバへの遷移に伴って数秒から数分のレイテンシ期間が起こり得る。このレイテンシ期間は、リクエストを処理するのに付加的なサーバが利用できる（即ち、アクティブになる）前に不要な処理遅延（複数可）が生じる可能性がある。
【００１１】
それによって、エネルギーを意識したサーバ管理は、タイミング良くリクエストに応答しながら、レイテンシおよび性能基準といったいくつかのパラメータを考慮またはバランスをとってエネルギー利用を削減することができる。
【００１２】
図１は、方法１００の形式で本概念のいくつかの導入例を提示する。この場合、１０２において、サーバコンピュータなどのコンピュータセットの今後の作業負荷が予測または推定される。この予測は、２、３秒から２、３分といった比較的短い期間に関連することができる。この特定の例において、個々のコンピュータは、２または３以上のエネルギー状態を有することができる。例えば、そのコンピュータは、アクティブ状態（即ち、オン）と、１または複数の非アクティブ状態（即ち、とりわけ、オフ、スリープおよびハイバネート）を有することができる。
【００１３】
作業負荷予測方法の詳細な例は、後述の見出し「作業負荷予測の例」で説明される。簡単に言えば、ある事例において、作業負荷予測は、作業負荷予測処理で考慮されるパラメータとして、とりわけ、比較的長期間のモデリングと、比較的短期間の履歴（ｈｉｓｔｏｒｙ）と、現在の傾向（ｔｒｅｎｄｓ）と、および／または外部情報（ｅｘｔｅｒｎａｌｋｎｏｗｌｅｄｇｅ）（例えば、経営見通し、スケジュールイベント）とを利用することができる。
【００１４】
長期間のモデリングは、一日の時間帯、数週間のうちの数日、時節、選挙などの複数年サイクルに関連する作業負荷傾向を見ることができる。例えば、労働者が出社する平日の毎朝８時から９時までの間で一致した作業負荷要求（ｗｏｒｋｌｏａｄ  ｄｅｍａｎｄ）や、労働者が一日を始める際にさまざまな個人的および／または仕事関連のリクエストがあるかもしれない。
【００１５】
短期間の履歴は、最後の数秒または数分間のユーザリクエストレベルに関連することができる。例えば、人気のテレビ番組についてのウェブサイトの記述が、次の数分間でそのウェブサイトをヒットさせることもある。最後の数秒または数分における上昇傾向の表示は、次の数秒または数分に対する今後のリクエストを予測するのに役立つことができる。
【００１６】
現在の傾向は、作業負荷予測処理時に受信されるユーザリクエストに関連することができる。例えば、現在の傾向は、最近の利用可能時間にわたるリクエストグラフの形から得ることができる。そのグラフは、時系列配分において一定かもしれないし、変化するかもしれない（例えば、直線、急増）。
【００１７】
外部情報は、現在または過去のリクエストから獲得されていない情報と見なすことができる。その代わり、外部情報は、例えば、過去のデータで表すことができないこれからやって来るイベント（ｕｐｃｏｍｉｎｇ  ｅｖｅｎｔ）に関連することができる。例えば、外部情報は、オリンピックがやって来て、オリンピック開催中にユーザがそのイベントからのビデオをダウンロードしようとする時に非常に高いリクエスト数を経験し得ることを伝達することができる。
【００１８】
リクエスト数について代替的または付加的には、外部情報は、リクエストの規模（ｓｉｚｅ）に関連することができる。例えば、上記の例を継続すると、外部情報は、オリンピック期間中にリクエスト数が増加し得ること、およびそのリクエストが、データ量の多いビデオのダウンロードに関連する傾向にあるので各リクエストの規模が通常よりも大きくなり得ることを示すことができる。
【００１９】
上記の説明は、作業負荷予測の例を提供するが、これに限らない。他の例では、リクエスト規模を予測することができる。予測されるリクエスト規模を、次に、作業負荷予測において利用することができる。要するに、今後の作業負荷を予測するのに潜在的に多くのやり方がある。予測される今後の作業負荷を、次に、とりわけ、後述のシステム／方法において利用することができる。
【００２０】
１０４において、予測される作業負荷に対するエネルギーを意識したサーバ管理ポリシーを決定することができる。簡単に言えば、エネルギーを意識したサーバ管理ポリシーは、容量プロビジョニング（ｃａｐａｃｉｔｙ  ｐｒｏｖｉｓｉｏｎｉｎｇ）含むことができる。ある実施において、容量プロビジョニングを、作業負荷が変更する時にオンラインによる実時間のやり方で行うことができるという点で、先を見越したもの（即ち、先を見越した容量プロビジョニング）と見なすことができる。先を見越した容量プロビジョニングはまた、サーバの異なる電力状態間の遷移にかかる時間を先を見越してマスクすることができるという点で、先を見越したものと見なすことができる。このことは、イベントが起きた「後に」決定およびなんらかの応答動作が行われる反応型意思決定（ｒｅａｃｔｉｖｅ  ｄｅｃｉｓｉｏｎ  ｍａｋｉｎｇ）と対比されことがある。
【００２１】
別の言い方をすれば、現在の状態のコンピュータセットは、所与の作業負荷に対処する容量を有する。現在の状態のコンピュータの容量が予測される作業負荷に対処する容量とは異なる場合、容量プロビジョニングを用いて、そのコンピュータの一部の状態を調整して今後の容量を予測される作業負荷に合わせることができる。  
エネルギーを意識したサーバ管理ポリシーは、１または複数のコンピュータの状態を変更すること（即ち、アクティブ状態から非アクティブ状態へ遷移すること、逆もまた同様）を含むことができる。エネルギーを意識したサーバ管理ポリシーは、コンピュータセットのエネルギー利用と、ユーザリクエストへの応答に対するタイムリーな予想と、予測／推定の信頼（ｃｏｎｆｉｄｅｎｃｅ）と、および／または状態遷移と関連付けられる個々のコンピュータの予想されるサービス寿命（ｓｅｒｖｉｃｅ  ｌｉｆｅ）に対する影響とを含む、複数の要因のバランスをとることができるが、これにかぎらない。このような要因は、以下の見出し「容量プロビジョニングの例」でより詳細に説明される。
【００２２】
１０６において、エネルギーを意識したサーバ管理ポリシーに基づいて、個々のコンピュータのエネルギー状態を調整することができる。例えば、あるコンピュータを、アクティブ状態から非アクティブ状態に遷移させてエネルギーを保存することができる。エネルギーを意識したサーバ管理ポリシーはまた、アクティブ状態のコンピュータ間でリクエストを割り当てる方法を指定することができる。
【００２３】
エネルギーを意識したサーバ管理ポリシーの別の態様は、特定のコンピュータがどの状態をとり入れるべきかを指定することができる。このことは、コンピュータの信頼性を向上させるために行われるかもしれない。例えば、あるタイプのコンピュータは、アクティブ状態と非アクティブ状態との間の遷移を何度も繰り返す場合、長期によるネガティブな結果を経験することもある。従って、エネルギーを意識したサーバ管理ポリシーは、個々のサーバが、一日などの所与の期間内に所与の回数を超えて遷移してはいけないことを示すことができる。そのシステムは、「マシンＡ」が何回循環（ｃｙｃｌｅ）しているかを記録して、マシンＡがあまりに頻繁に循環している場合、異なるマシンを選択して遷移させることができる。エネルギーを意識したサーバ管理ポリシーのさまざまな態様は、図２に関連して、および以下の見出し「状態遷移の例」でより詳細に論じられるであろう。
【００２４】
＜システム構成の例＞
図２は、一例ではあるが、上述したエネルギーを意識したサーバ管理を実施することができるシステム２００を示す。この場合、システム２００は、負荷ディスパッチャ２０２と、適応制御ユニット２０４と、４つのサーバ２０６（１）、２０６（２）、２０６（３）および２０６（ｎ）のセットとを含む。負荷ディスパッチャ２０２と、適応制御ユニット２０４と、サーバ２０６（１）、２０６（２）、２０６（３）および２０６（ｎ）を、さまざまな実施において相互に並置（ｃｏｌｌｏｃａｔｅ）および／または分散できる。
【００２５】
２１０において一般的に示したユーザは、リクエスト２１２（１）−２１２（ｎ）を行うことができ、そのリクエストは、負荷ディスパッチャ２０２によって受信される。エネルギーを意識したサーバ管理ポリシー２１６およびアクティブマシンリスト２１８に従って、負荷ディスパッチャは、２１４（１）−２１４（ｎ）に示すように、個々のリクエスト２１２（１）−２１２（ｎ）を個々のサーバ２０６（１）−２０６（ｎ）に送信する。適応制御ユニット２０４によって、それらのエネルギーを意識したサーバ管理ポリシー２１６およびアクティブマシンリスト２１８が作成されて、負荷ディスパッチャ２０２に送信される。
【００２６】
アクティブマシンリスト２１８は、適応制御ユニット２０４によってサーバ２０６（１）−２０６（ｎ）に伝達されるエネルギー管理制御決定２２０を反映する。エネルギー管理制御決定を、個々のサーバ２０６（１）−２０６（ｎ）の状態を制御することによってエネルギーを意識したサーバ管理ポリシーをそのサーバレベルで実装する制御と見なすことができる。適応制御ユニット２０４は、さまざまな入力パラメータに基づいて、エネルギーを意識したサーバ管理ポリシー２１６およびアクティブマシンリスト２１８を作成する。この事例において、その入力パラメータは、性能カウンタ２２２と、リクエスト情報２２４と、エネルギー利用２２６と、および／または入力リクエスト作業負荷（具体的に図示せず）とを含むが、これに限らない。
【００２７】
性能カウンタ２２２を、サーバ２０６（１）−２０６（ｎ）から適応制御ユニット２０４に送信することができる。性能カウンタは、個々のサーバおよび／またはサーバの共同（ｃｏｌｌｅｃｔｉｖｅ）セットが動作している容量を示すことができる。
【００２８】
応答時間などのリクエスト情報２２４を、負荷ディスパッチャ２０２から獲得することができる。リクエスト情報を、とりわけ、リクエスト率（即ち、単位時間当たりのリクエスト）、リクエスト規模、および／またはリクエスト応答時間といったいくつかのやり方で明示することができる。
【００２９】
エネルギー利用２２６を、さまざまなソースから獲得することができるが、１つの簡単なソースでは、サーバ２０６（１）−２０６（ｎ）への電力供給に対するエネルギー消費量メータ（図示せず）がある。具体的に図示しないが、他の実施は、個々のサーバに対するエネルギー利用を、単独またはサーバとの組み合わせ、全体のエネルギー利用として提供できる。適応制御ユニットは、ソースに関する情報を受信することもできるが、具体的に図示しない。例えば、適応制御ユニットは、サービスレベルに関する合意（ＳＬＡ）で定義された性能情報を獲得することができる。この性能情報を、エネルギーを意識したサーバ管理ポリシー２１６の構築に利用することができる。さらに、適応制御ユニットは、エネルギーを意識したサーバ管理ポリシー２１６の特定部分のみを負荷ディスパッチャ２０２に送信できる。例えば、エネルギーを意識したサーバ管理ポリシーは、負荷ディスパッチャに送信されてリクエストがサーバにディスパッチされる方法を定義するディスパッチ論理を含むことができる。
【００３０】
ある事例において、負荷ディスパッチャ２０２は、負荷バランサとして機能して、リクエスト２１２（１）−２１２（ｎ）をアクティブサーバ２０６（１）−２０６（ｎ）に均一に分散することができる。他の事例において、アクティブサーバとの関連で、負荷ディスパッチャは、リクエストを比較的高頻度でアクティブサーバのサブセットに戦略的に分散して、それらのサーバを特定の容量に、例えば、全容量の７０パーセントに維持できる。サーバのサブセットが特定の容量を超えてしまうであろうリクエストはどれも、アクティブサーバの第２のサブセットに送信することができる。このような構成は、予備の役割で第２のサブセットを動作しながら、アクティブサーバの大多数が指定されたまたは望ましい容量で動作するのを維持することができるので、エネルギー効率を向上させることができる。一つの観点で見ると、アクティブサーバのこの第２のサブセットを、作業負荷の予想外の急上昇（ｓｐｉｋｅ）に対するヘッジ（ｈｅｄｇｅ）と見なすことができる。
【００３１】
さらに、適応制御ユニット２０４から獲得される情報（即ち、エネルギーを意識したサーバ管理ポリシー２１６および／またはアクティブマシンリスト２１８）に基づいて、負荷ディスパッチャ２０２は、非アクティブ状態に遷移する任意のサーバを避けて負荷を再分散することができる。
【００３２】
要約すれば、ある実装において、負荷ディスパッチャ２０２は、リクエストをアクティブサーバのみに分散することができ、そして非アクティブ状態に遷移されるサーバを避けてリクエストを再分散することができる。
【００３３】
システム２００の例示された構成において、適応制御ユニット２０４は、今後のワークフロー（即ち、今後のリクエスト）を予測することができる。適応制御ユニットは、エネルギーを意識したサーバ管理ポリシーを構築して、エネルギー効率の良いやり方で今後の作業負荷に対処することができる。適応制御ユニットは、エネルギーを意識したサーバ管理ポリシーを構築する際に複数のパラメータを考慮することができる。これらのパラメータは、リクエスト情報２２４と、エネルギー利用２２６と、および／または性能カウンタ２２２とを含むことができるが、これに限らない。
【００３４】
要約すれば、適応制御ユニット２０４は、エネルギー管理制御決定２２０経由のエネルギーを意識したサーバ管理ポリシーに従って、サーバ２０６（１）−２０６（ｎ）の状態を制御することができる。例示された構成において、適応制御ユニットは、受信入力に基づいて作成される出力経由でシステム機能を制御することができるという点で、比較的簡単な閉ループ制御のシナリオで機能することができる。
【００３５】
適応制御ユニットは、２，３例を挙げると、サーバの中央処理ユニット（ＣＰＵ）利用、リクエスト応答時間、エネルギー消費量といったシステム性能に関連する入力データを受信することによって働く。予測される今後の作業負荷を踏まえて入力データを考慮して、予測される今後の負荷に対処する方法を決定することができる。例えば、それぞれのエネルギー状態（即ち、アクティブ、非アクティブ（スリープ、ハイバネート、オフなど））にあるサーバ数を調整して、予測される作業負荷の容量のバランスをとることができるので、エネルギーを節約することができる。別の言い方をすれば、適応制御ユニットは、エネルギー効率の良いやり方で予測される作業負荷に対処するために、サーバ２０６（１）−２０６（ｎ）におけるエネルギー状態をプロビジョンすることができる。
【００３６】
ある場合には、サーバ２０６（１）−２０６（ｎ）は、サーバと関係ない使用のために設計されたプロセッサを用いることができる。例えば、現在の概念は、ネットブックおよび他のモバイルアプリケーションに使用するために設計されたプロセッサが、サーバのシナリオに有利に適用するのを可能にする。例えば、インテル社ブランドのＡｔｏｍプロセッサを、現在の構成の一部に利用することができる。Ａｔｏｍプロセッサは、アクティブ状態で比較的エネルギー効率が良く、非アクティブなスリープ状態ではアクティブ状態に対しておよそ９０パーセントのエネルギーを節約する。
【００３７】
非アクティブ状態は、一般的に、アクティブ状態に遷移するのに異なるレイテンシ時間を提示する。例えば、全くの（ｔｒｕｅ）「オフ」状態では、アクティブ状態に対して９９パーセント以上の電力節約を提示できる。しかしながら、実質的な電力節約は、その代償として比較的長い遷移レイテンシを伴う。例えば、オフの非アクティブ状態からアクティブ状態への遷移レイテンシが数分になることもある。それに対し、「スリープ」の非アクティブ状態が、例えば、９０パーセントのエネルギー節約を提示するかもしれないが、遷移レイテンシは、例えば、１０−２０秒になり得る。このような長い遷移の潜在的な不都合な点は、作業負荷予測が今後の作業負荷を実際に過小評価する（ｕｎｄｅｒｅｓｔｉｍａｔｅ）場合、オフになっているサーバは、比較的長い時間支援できなくなることである。
【００３８】
「ハイバネート」の非アクティブ状態は、エネルギー節約およびスリープの非アクティブ状態とオフの非アクティブ状態との間の遷移レイテンシを提示できる。例えば、ハイバネートは、アクティブ状態と比較して９５パーセントのエネルギー節約および３０秒のレイテンシ遷移を提示できる。ある特性化において、ハイバネートは、スリープの深いレベル（ｄｅｅｐ  ｌｅｖｅｌ）として特性化されることに留意されたい。上述したインテル社のＡｔｏｍプロセッサに関して、アクティブ状態のエネルギー消費量は、２８−３４ワットであるが、スリープ状態では、そのプロセッサは、３−４ワットを消費し、ハイバネートでは１−２ワットを消費し、その両方で、アイドル状態のプロセッサのエネルギー消費の少なくとも１０倍の削減を提示する。上述した非アクティブ状態の例は、考察するために提供される。現在の概念は、特定のサーバコンピュータに提示できる非アクティブ状態の特定のセットにとらわれないことを理解されたい。別の言い方をすれば、エネルギー節約機能性を、パワーダウンおよび／またはパワーオフにすることができるシステム、デバイス、および／またはコンポーネントのいずれにも適用することができる。
【００３９】
複数の非アクティブ状態を有するコンピュータは、ノート型コンピュータなどのある製品種目に利用できる傾向にある。複数の非アクティブ状態を提示する製品種目は、サーバファームなどの連動した（ｃｏｏｒｄｉｎａｔｅｄ）アプリケーションよりはむしろ、個人使用などの独立アプリケーション用に設計される傾向にある。連動したアプリケーションにおけるこのような特徴の欠如の一つの理由は、高性能かつエネルギー効率の良いやり方でさまざまなコンピュータを制御することによる複雑さ／困難さである。
【００４０】
性能とエネルギー効率のバランスをとる複雑さは、単一使用のシナリオでも証明される。例えば、ノート型コンピュータは、タイムアウトする場合（即ち、事前定義された期間にユーザ入力がまったく受信されない場合）、非アクティブ状態まで簡単にパワーダウンする。このタイムアウトの解決策は、今後の使用を満たすやり方で、エネルギーに配慮したまたはユーザにとって高性能なやり方で、今後の使用を予測してコンピュータを動作しようとするものではまったくない。従って、ユーザが非アクティブ状態に遷移されたコンピュータに返信する時、そのユーザは、ある入力を提供して、そのコンピュータがアクティブ状態に遷移して戻る間ずっと待たなければならない。
【００４１】
エネルギーを意識したサーバ管理ポリシー２１６は、多重状態のコンピュータの潜在的なエネルギー効率が、サーバファームなどの共同設定で実現するのを可能にする。簡単に言えば、エネルギーを意識したサーバ管理は、個々のサーバ２０６（１）−２０６（ｎ）が非アクティブ状態とアクティブ状態との間を遷移する時を決定して、現在および予測される今後の作業負荷にサービスすることができる。
【００４２】
図３は、エネルギーを意識したサーバ管理を達成するための適応制御ユニット２０４の論理モジュールの例を示す。この場合、論理モジュールは、作業負荷予測モジュール３０４と、戦略またはポリシーモジュール３０６と、および状態調整モジュール３０８として明示される。
【００４３】
作業負荷予測モジュール３０４は、現在の作業負荷を決定して、今後の作業負荷を予測することができる。一つの観点で見ると、作業負荷は、リクエストの規模を乗じた単位時間当たりのリクエスト数と見なすことができる。比較的多数のリクエストを伴うシナリオの動作において、かなり高い精度で平均的なリクエスト規模を計算することができる。そのような場合、その作業負荷を、その平均的なリクエスト規模を乗じた単位時間当たりのリクエスト数で簡単に計算することができる。作業負荷予測モジュールは、さまざまな技術を利用して今後の作業負荷を予測することができるが、その一部は上記で導入され、またその一部は以下でより詳細に論じられる。簡単に言えば、図２のシステムにおいて、作業負荷予測モジュール３０４は、リクエスト情報２２４を、今後の作業負荷を予測する入力データとして利用することができる。他の事例において、作業負荷予測モジュールは、外部情報を受信して利用することができる。ある実装において、作業負荷予測モジュールは、今後の作業負荷を推定するまたは予測する際に使用する長期間の履歴傾向を収集し、モデル化し、そして格納することができる。
【００４４】
ポリシーモジュール３０６は、作業負荷予測モジュール３０４によって供給される作業負荷予測を満たすためのエネルギーを意識したサーバ管理ポリシーを構築することができる。例えば、ポリシーモジュールは、現在の容量を、いくつかのアクティブサーバおよび個々のサーバによって対処することができる単位時間当たりのリクエスト数で計算することができる。ポリシーモジュールは、予測される作業負荷の適切な容量を計算することができる。要約すれば、エネルギーを意識したサーバ管理ポリシーは、予測される作業負荷に対処する容量プロビジョニングを含むことができる。
【００４５】
ポリシーモジュール３０６は、サーバを現在の構成から、予測される作業負荷の適切な容量に再構成するためのエネルギーを意識したサーバ管理ポリシーを構築することができる。例えば、それぞれのアクティブサーバが毎秒１０個のリクエストに対処することができるのに、１０個のサーバからなるサーバファームを伴うとする仮説シナリオを考えてみる。現在の作業負荷は、毎秒６７個のリクエストがあり、７個のアクティブサーバが対処している（残り３個のサーバは非アクティブである）。作業負荷予測は、今後の時間ｔ＋Δｔにおいて、その作業負荷が毎秒３８個のリクエストになるであろうことを示す。その場合、ポリシーモジュールは、アクティブサーバの数を削減するエネルギーを意識したサーバ管理ポリシーを構築することができる。
【００４６】
ポリシーモジュール３０６は、エネルギーを意識したサーバ管理ポリシーを構築する時に、費用対効果分析の複数の要因を含むことができる。例えば、ポリシーモジュールは、サーバの寿命を最大限にするために、個々のサーバがアクティブ化および非アクティブ化される回数を考慮できる。サーバの寿命は、アクティブなエネルギー状態と非アクティブなエネルギー状態との間の遷移回数に反比例する傾向にある。別の要因は、システム２００の性能レベルを定義するＳＬＡになり得る。考慮され得る別の要因は、作業負荷予測の信頼レベル（ｃｏｎｆｉｄｅｎｃｅ  ｌｅｖｅｌ）である。例えば、信頼レベルが高い事例において、ポリシーモジュールは、予測される作業負荷には４個のアクティブサーバで十分であり、さらに非アクティブになる３個のサーバを含めて合計６個が非アクティブサーバになると結論付けることもある。信頼レベルが低い場合、ポリシーモジュールは、５個のアクティブサーバを保持するエネルギーを意識したサーバ管理ポリシーを構築することもある。
【００４７】
ある実施において、ポリシーモジュール３０６は、エネルギーを意識したサーバ管理ポリシーを構築する際に、ＣＰＵ、メモリ、ディスク、ネットワークなどの異なるパラメータまたは測定基準を含むことができる性能学習モデル（ｐｅｒｆｏｒｍａｎｃｅ  ｌｅａｒｎｉｎｇ  ｍｏｄｅｌ）を用いることができる。さらに、説明を簡単にするために、上記の考察はすべてのサーバを同等に扱っている。しかしながら、ポリシーモジュールは、サーバ間の相違または不均一（ｈｅｔｅｒｏｇｅｎｅｉｔｙ）を認識するおよび／または取り組む、エネルギーを意識したサーバ管理ポリシー２１６を構築することができる。そのような相違は、サーバ内部および／または外部で生じるかもしれない。例えば、エネルギーを意識したサーバ管理ポリシーは、個々のサーバが異なる容量、異なる電力フットプリント（ｐｏｗｅｒ  ｆｏｏｔｐｒｉｎｔ）、およびエネルギー状態間の異なる遷移回数を有することを反映することができる。同様に、サーバは、熱だまり、修理および保守タスクといった外部要因によって影響されることもある。
【００４８】
エネルギーを意識したサーバ管理ポリシーはまた、個々のサーバが遷移される非アクティブ状態を指定することができる。例えば、スリープの非アクティブ状態がアクティブ状態に戻る素早い遷移を提示するので、エネルギーを意識したサーバ管理ポリシーは、一部のサーバをスリープ状態に保持させる間に他のサーバを非アクティブ状態に遷移させることを指定でき、それによって大幅なエネルギー節約を提示できる。
【００４９】
エネルギーを意識したサーバ管理ポリシーは、サーバ遷移を決定する付加的な要因を使用することができる。例えば、ソフトウェアのアップグレードといった修理／保守タスクのために、アクティブなサーバをオフに遷移することができ、その間非アクティブ状態の別のサーバをアクティブに遷移して、そのシステム容量が影響を受けないようにできる。
【００５０】
状態プロビジョニングモジュール３０８は、ポリシーモジュール３０６によって供給されるエネルギーを意識したサーバ管理ポリシーと一致する個々のサーバに対して状態変更させることができる。さらに、状態調整モジュールは、負荷ディスパッチャ２０２（図２）に対してアクティブなサーバを伝達して、負荷ディスパッチャが非アクティブサーバにリクエストを送信するのを避けることができる。
【００５１】
＜作業負荷予測の例＞
一実施において、重み付け線形回帰（ｗｅｉｇｈｔｅｄ  ｌｉｎｅａｒ  ｒｅｇｒｅｓｓｉｏｎ）を利用して作業負荷予測を達成することができる。この場合、重み付け線形回帰を、１または複数の独立変数の数学関数を使用して観察が表される回帰分析の形式と見なすことができる。例えば、その観察を、１秒当たりのリクエストなどの独立変数とすることができる。独立変数の例を、時間などの入力とすることができる。重み付け線形回帰の場合、その関数を、回帰係数の線形結合として表すことができる。重み付け線形回帰の目的は、観察とその関数によって予測される値と間の重み付けされた二乗和を削減（および潜在的に最小化する）のを可能にすることである。その重み付けを使用して、異なる重要な値を異なる観察に割り当てる。要するに、この特定の作業負荷予測方法は、回帰分析を、履歴傾向、長期モデル、外部情報などと結合させて今後の作業負荷を予測する。
【００５２】
＜容量プロビジョニングの例＞
ある特定の例において、性能学習モデルにおけるマシン学習を利用して、容量プロビジョニングを達成することができる。その事例の一つに、容量プロビジョニングは、応答時間の条件付き分布（ｃｏｎｄｉｔｉｏｎａｌ  ｄｉｓｔｒｉｂｔｉｏｎ）の分位点が入力作業負荷の関数（１秒当たりのリクエスト）およびアクティブサーバの数として表される、分位点回帰のマシン学習方法を用いる。
【００５３】
この分位点回帰の方法は、応答時間が、サーバ利用率が低い時にはほとんど直線的に増え、入力作業負荷がサーバの処理容量に近づくにつれて素早く（例えば、潜在的に、飛躍的に）増加するという事実を考慮する。言い換えれば、容量プロビジョニング方法は、オフラインのやり方で、入力作業負荷パラメータおよびアクティブサーバの数が変わることによってシステムの応答時間を学習することができる。次に、所与のＳＬＡ要件および予測される作業負荷の推定に対し、容量プロビジョニング方法は、指定されたＳＬＡ内の作業負荷を満たすのに必要なサーバ数を計算する。
【００５４】
＜状態遷移の例＞
図４は、エネルギーを意識したサーバ管理に従って、状態遷移を達成するための方法４００のフローチャートを提示する。ブロック４０２において、方法４００が開始される。ブロック４０４において、その方法は、サーバ（即ち、サーバファームのサーバまたは別のグループのサーバ）を順序付ける。ブロック４０４は、１または複数のパラメータに従ってサーバを順序付けることができる。例えば、サーバを、エネルギー状態（即ち、アクティブまたは非アクティブ）に従って順序付けすることができる。さらに、非アクティブサーバを、相対的エネルギー節約を反映するランク付けされたグループで順序付けることができる。例えば、アクティブサーバを、スリープ状態の非アクティブサーバ、次に、ハイバネート状態の非アクティブサーバ、そして最後にオフ状態の非アクティブサーバと続けてリスト化することができる。
【００５５】
ブロック４０６は、エネルギー状態を順序付ける。ある事例では、非アクティブ状態とアクティブ状態との間の遷移レイテンシに基づいて、エネルギー状態を順序付けることができる。代替的または付加的には、エネルギー利用またはフットプリントに基づいて、エネルギー状態を順序付けまたはランク付けることができる。従って例えば、エネルギー状態を、最もエネルギーが消費される状態（即ち、アクティブ）から最も少なくエネルギーが消費される状態（即ち、オフ）にリスト化することができる。
【００５６】
ブロック４０８は、今後の時間（ｔf）における予測されるサーバ要求（即ち、作業負荷）と時間ｔfにおいて利用可能な容量との差（ｄｉｆｆｅｒｅｎｃｅ）またはΔを計算する。作業負荷を予測するための技術は、上述している。要約すれば、ブロック４０８は、今後のある時間において利用可能なサーバ容量がちょうど良いか、かなりあるか（ｔｏｏ  ｈｉｇｈ）またはわずかしかない（ｔｏｏ  ｌｏｗ）かどうかを識別する働きをする。
【００５７】
ブロック４０８において、差はゼロに等しい（即ち、予測される作業負荷が今後の容量に等しい）場合、方法はブロック４１０に進む。ブロック４１０は、容量調整がまったく必要ないので、現在の時間においてサーバを制御する処理を停止する。３０秒などのある増分時間が経過した後、その方法は、次に、開始４０２に戻って、その方法が繰り返される。
【００５８】
ブロック４０８において、差がある（即ち、差がゼロでない）場合、その方法はブロック４１２に進む。
【００５９】
ブロック４１２は、（ブロック４０４において導入された全サーバからの）サーバセットが、現在の時間ｔと今後の時間ｔfの暫時期間に状態が遷移することを認識する。別の言い方をすれば、ブロック４１２は、状態間を遷移するおよび／またはすでにそれを行うようにスケジュールされているサーバを識別する。事例において、ブロック４０８の差が正の値（即ち、Δ＞０）であれば、方法はブロック４１４に進み、反対に、その差が負の値（即ち、Δ＜０）であれば、方法はブロック４１６に進む。
【００６０】
ブロック４１４において、方法は、アクティブ状態に遷移する非アクティブサーバを識別することによって時間ｔfに対するサーバ容量を増加する。個々のサーバの状態は、上記のブロック４０４においてリスト化される。識別に考慮される非アクティブサーバは、４１２において認識されるセットに属さない。別の言い方をすれば、その識別されるサーバは、暫定期間に遷移されないまたは遷移するようにスケジュールされていない非アクティブサーバである。
【００６１】
さまざまな他のパラメータを利用して、識別されるサーバを選択できる。例えば、遷移レイテンシを考慮できる。例えば、今後の時間ｔfが３０秒先である場合、方法は、遷移レイテンシを、遷移するサーバを考慮する時間（ｃｏｎｓｉｄｅｒａｔｉｏｎ）と見なすことができる。例えば、スリープからアクティブへの遷移レイテンシが２０秒で、オフからアクティブへの遷移レイテンシが１分である場合、その方法は、スリープ状態からのサーバを選択して、その遷移が今後の時間ｔf（即ち、３０秒）において完了できるようにし得る。
【００６２】
方法はまた、個々のサーバが所与の期間に遷移される回数を考慮することができる。例えば、スリープ状態のサーバの１つがすでに閾値回数（ａ  ｔｈｒｅｓｈｏｌｄ  ｎｕｍｂｅｒ  ｏｆ  ｔｉｍｅｓ）で遷移している場合、その方法は、その閾値より少ない別のスリープ状態のサーバを遷移させるのに選択できる。他のパラメータも、費用対効果分析における識別処理に利用することができる。例えば、費用は、とりわけ、頻繁な状態遷移に起因して増加する応答時間や低下するサーバ寿命のリスクを含み得る。効果は、とりわけ、減少されるエネルギー利用になり得る。
【００６３】
ブロック４１６は、今後の時間ｔfにおけるサーバ容量が予測される作業負荷よりも大きいシナリオに取り組む。ブロック４１６は、非アクティブ状態に遷移する個々のアクティブサーバをランク付けすることによって、時間ｔfのサーバ容量を削減する。考慮されるサーバは、すでに遷移しているかもしれない、ブロック４１２におけるセット｛ｔｓ｝に識別されるサーバを含まない。費用対効果分析を利用して考慮することができる１または複数のパラメータに基づいて、アクティブサーバを選択することができる。パラメータの例は、ブロック４１４に関連して上述している。簡単に言えば、所与のサーバがすでに閾値回数で遷移している場合、そのサーバを再度遷移することに対して費用対効果分析を重み付けすることができる。その代わりに、別のサーバを遷移するのに選択することもできる。
【００６４】
考慮することができる別のパラメータは、不十分な容量に対するヘッジングに関する。例えば、サーバを遷移するのに一方向で２０秒かかり、その処理がひとたび開始されれば停止することができないと仮定する。従って、アクティブサーバ（サーバ１と呼ぶ）を一度再アクティブ化して遷移を開始するのに４０秒かかる（即ち、アクティブから非アクティブに２０秒かかり、非アクティブからアクティブにさらに２０秒かかる）。考察するために、ｔfが今後にわたる３０秒に等しいと仮定する。別の非アクティブサーバ（サーバ２と呼ぶ）が、アクティブ状態に遷移されるのに利用可能である場合、サーバ１の遷移と関連付けられるリスクは、最初の１０秒間では比較的低い。なぜならば、時間ｔfが今後の少なくとも２０秒である限り、サーバ２を時間内にアクティブ化することができるからである。従って例えば、サーバ１を非アクティブ化する決定が行われて、８秒後に時間ｔfに関連する過小評価が検出される場合、サーバ２を時間内にアクティブ化して付加的な容量要件を補うことができる（即ち、８秒に２０秒をたした遷移は、２８秒でまたはその容量が不十分になり得る前の２秒でサーバ２をアクティブ状態にする）。従って、サーバ２の可用性は、サーバ１の非アクティブ化に対する費用対効果分析を左右することがある。
【００６５】
別の同様のパラメータは、任意の過小評価を補うサーバ１自体の能力に関連する。例えば、上記の例を継続すると、サーバ１が、一方向の遷移に２０秒かかり、アクティブからアクティブの遷移に４０秒かかると仮定する。今後の時間ｔfが３０秒先である第１のシナリオを考慮する。このような場合、過小評価が検出される場合、サーバ１は、今後の時間ｔfにおける付加的な要求を補うのに利用できないであろう。そのシナリオにおいて、このパラメータは、サーバ１に遷移しないことに対して重み付けすることができる。今後の時間ｔfが６０秒先である別のシナリオを考慮する。このような場合、過小評価すべき時間ｔf（即ち、４０秒後に）が検出される前にサーバ１を非アクティブ化して再アクティブ化することができる。このシナリオにおいて、このパラメータは、サーバ１を非アクティブ化することに対して重み付けすることができる。この費用対効果分析は、エネルギーを保存しながら、予想されるサービスレベルを提供する多くのパラメータを考慮することができることを当業者は認識されたい。
【００６６】
ブロック４１０と同様に、３０秒などのある増分時間が経過した後に、その方法は、次に、開始４０２に戻って、その方法を繰り返すことができる。
【００６７】
アルゴリズム１は、費用対効果分析を用いてエネルギーを意識したサーバ管理ポリシーの一部を作成する特定の状態遷移方法を示す。
【００６８】
＜アルゴリズム１＞
ステップ０．非アクティブ状態のサーバの前にアクティブ状態のサーバが順序付けられるシーケンスに従ってサーバを順序付けること――Ｓシーケンス（ＳＳｅｑｕｅｎｃｅ）と呼ぶ。
エネルギー状態を、そのエネルギー状態からアクティブ状態への遷移レイテンシが増加する順に順序付けること――Ｅシーケンス（ＥＳｅｑｕｅｎｃｅ）と呼ぶ。
エネルギーフットプリントが増加する順に順序付けること――Ｐシーケンス（ＰＳｅｑｕｅｎｃｅ）と呼ぶ。
【００６９】
ステップ１．予測されるサーバ要求（例えば、Ｐサーバ（Ｐ  ｓｅｒｖｅｒｓ））と事前決定された今後の時間ステップにおいて利用可能なサーバ（例えば、Ｆサーバ（Ｆ  ｓｅｒｖｅｒｓ））数との間の差を計算する。
（事前決定された今後の時間ステップにおいて利用可能なサーバ数は、現在アクティブなサーバ数と、現在遷移中のサーバ数と、事前決定された時間テップの前に遷移されるサーバ数とによって決まる。）
【００７０】
ステップ２．もし差がゼロならば、停止する（呼差（ｃａｌｌ  ｄｅｆｅｒｅｎｃｅ）＝Ｄ＝Ｐ−Ｆ）
【００７１】
ステップ３．Ｓシーケンスから第１のＴサーバ（Ｔ  ｓｅｒｖｅｒｓ）を取り、次に、（もしすでにアクティブではないまたはアクティブに遷移するならば）それらをＴ＝ＭＩＮＩＭＵＭ（Ｐ，Ｆ）であるアクティブ状態に遷移する。Ｔサーバ内の各ｉに対してＮｏＣｈａｎｇｅＵｎｔｉｌＴｉｍｅ［ｉ］：＝事前定義された今後の時間ステップ（ｐｒｅ−ｄｅｔｅｒｍｉｎｅｄ  ｆｕｔｕｒｅ  ｔｉｍｅ−ｓｔｅｐ）とする。
【００７２】
ステップ４．Ｉｆ  Ｄが正（即ち、さらに容量を加える）
ｔｈｅｎ
ＥシーケンスのＩＮＣＲＥＡＳＩＮＧ順序のＳシーケンスから次の（ステップ３に対して）Ｄサーバを取る
Ｆｏｒ  そのような各サーバ（例えば、S）に対して
ＮｏＣｈａｎｇｅＵｎｔｉｌＴｉｍｅ［ｓ］：＝事前定義された今後の時間ステップ（ｐｒｅ−ｄｅｔｅｒｍｉｎｅｄ  ｆｕｔｕｒｅ  ｔｉｍｅ−ｓｔｅｐ）とする
Ｉｆ（ｆｕｔｕｒｅ  ｔｉｍｅ−ｓｔｅｐ−ｃｕｒｒｅｎｔ  ｔｉｍｅ＞ｔｒａｎｓｉｔｉｏｎ−ｆｒｏｍ−ｔｈａｔ−ｅｎｅｒｇｙ−ｓｔａｔｅ−ｔｏ−ａｃｔｉｖｅ）
（即ち、しばらく残っている時間）
そのサーバの遷移をＦＵＴＵＲＥ時間においてアクティブ状態にスケジュールする（ｆｕｔｕｒｅ  ｔｉｍｅｓｔｅｐ−ｃｕｒｒｅｎｔ  ｔｉｍｅ）
ｅｌｓｅ
そのサーバの遷移を今アクティブ状態にスケジュールする
ｅｎｄ  ｉｆ
ｅｎｄ  ｆｏｒ
ｅｌｓｅ
Ｉｆ  Ｄが負（即ち、低容量）
ｔｈｅｎ
Ｓシーケンスからアクティブ状態の次の（ステップ３に対して）Ｄサーバを取るおよびそのような各サーバに対して（例えば、ｊ）ＮｏＴｒａｎｓｉｔｉｏｎＵｎｔｉｌＴｉｍｅ［ｊ］＜＝ｃｕｒｒｅｎｔ  ｔｉｍｅ
ステップ４．Ａ．Ｆｏｒ  Ｐシーケンス内の各エネルギー状態に対して
Ｉｆ（ｆｕｔｕｒｅ  ｔｉｍｅ−ｓｔｅｐ−ｃｕｒｒｅｎｔ  ｔｉｍｅ＞＝ｔｒａｎｓｉｔｉｏｎ−ｆｒｏｍ−ｔｈａｔ−ｅｎｅｒｇｙ−ｓｔａｔｅ−ｔｏ−ａｃｔｉｖｅ＋ｔｒａｎｓｉｔｉｏｎ−ｆｒｏｍ−ａｃｔｉｖｅ−ｔｏ−ｔｈａｔ−ｅｎｅｒｇｙ−ｓｔａｔｅ））
Ｄをそのエネルギーの今の状態；停止に進むようにスケジュールする
ｅｌｓｅ  ｉｆ（ｆｕｔｕｒｅ  ｔｉｍｅ−ｓｔｅｐ−ｃｕｒｒｅｎｔ  ｔｉｍｅ＞＝ｔｒａｎｓｉｔｉｏｎ−ｆｒｏｍ−ｔｈａｔ−ｅｎｅｒｇｙ−ｓｔａｔｅ−ｔｏ−ａｃｔｉｖｅ）
ＡＮＤ（そのエネルギー状態のサーバがＤ数ある）
ｔｈｅｎ
Ｄをそのエネルギーの今の状態；停止に進むようにスケジュールする
ｅｌｓｅ
（Ｄ−そのエネルギー状態のサーバの数）をそのエネルギーの今の状態に進むようにスケジュールする
Ｄ＝Ｄ−そのエネルギー状態のサーバの数
ステップ４．Ａに進む（およびその順序で次のエネルギー状態を考慮する）
ｅｎｄ  ｉｆ
ｅｎｄ  ｆｏｒ
ｅｎｄ  ｉｆ
ｅｎｄ  ｉｆ
【００７３】
要約すれば、容量プロビジョニング方法は、負荷要求を満たしながら、サーバを異なるエネルギー状態に遷移してこの遷移のレイテンシをマスクするようにし、そしてエネルギー利用を削減するために遷移を遅延させる、先を見越した手法をとる。
【００７４】
次に、その実施は、サーバ当たりの遷移回数の履歴、熱だまり、修理／保守動作、不具合などの付加的な要因を考慮に入れながら遷移を適用する。例えば、ノードを経由して遷移数のバランスをとるために、あるアクティブサーバを低いエネルギー状態にし、逆もまた同様にすることができる。
【００７５】
＜例示的方法＞
図５は、本概念の少なくとも一部の実施と一致する方法または技術５００のフローチャートを示す。方法５００が説明される順序は、限定して受け取られることを意図せず、その方法または代替的な方法を実装する任意の順序において、説明されるブロックの数を任意に組み合わせることができる。さらに、コンピューティングデバイスがその方法を実装することができるように、その方法を、適した任意のハードウェア、ソフトウェア、ファームウェア、またはその組み合わせに実装することができる。ある事例では、その方法を、命令セットとしてコンピュータ可読ストレージ媒体上に格納して、コンピューティングデバイスによる実行によって、そのコンピューティングデバイスにその方法を行わせるようにする。
【００７６】
ブロック５０２において、方法は、アクティブ状態および少なくとも２つの異なる非アクティブ状態で構成される個々のサーバを含むサーバプールに対する今後のリクエスト数を予測する。
【００７７】
ブロック５０４において、方法は、今後のリクエストに対する応答時間を、今後のリクエスト数およびアクティブサーバ数の関数としてモデル化する。
【００７８】
ブロック５０６において、方法は、アクティブ状態で動作するサーバ数および応答時間を満たす各サーバの非アクティブ状態を計算する。
【００７９】
ブロック５０８において、方法は、計算される数を満たすように、個々のサーバを状態間で遷移させる。
【００８０】
上述した方法は、サーバによるエネルギー利用を削減しながら、ユーザの期待を満たす（即ち、ＳＬＡの条件を満たすなど）ことができる。
【００８１】
＜結論＞
エネルギーを意識したサーバ管理に関する技術、方法、デバイス、システムなどは、構造的特徴および／または方法論的動作に特有の言語で説明されているが、当然のことながら、添付の特許請求の範囲において定義される発明の対象は、説明された特定の特徴または動作に必ずしも限定されない。むしろ、説明された特定の特徴および動作は、特許請求される方法、デバイス、システムなどを実装する例示的な形式として開示される。
【図１】
0005666482.tif 000002
【図２】
0005666482.tif 000003
【図３】
0005666482.tif 000004
【図４】
0005666482.tif 000005
【図５】
0005666482.tif 000006