(57)【要約】      （修正有）【課題】高性能コンピュータシステムのような分散型コンピュータシステムにおけるエネルギ認識型リソース管理に関する。【解決手段】リソースマネジャ２００は、複数のコンピュータ１０１を管理する。各コンピュータは、高電力構成及び１又は複数の低電力構成を含む複数の電力構成のうちの１つで動作可能である。リソースマネジャ２００は、各コンピュータの中にあるリソースマネジャプロキシ２０１とメッセージを交換する。リソースマネジャプロキシからのアプリケーションの実行状態変化の通知に応答して、リソースマネジャは、リソースマネジャプロキシのコンピュータ又はアプリケーションを実行中のコンピュータの集合に適用可能な電力構成を決定する。リソースマネジャ２００は、リソースマネジャプロキシ２０１に決定した電力構成を通知する。次に、リソースマネジャプロキシ２０１は、変更を実施するか否かを決定する。【選択図】図３
2016012347.tif 000002
【特許請求の範囲】
【請求項１】
分散型コンピュータシステムでアプリケーションを実行する方法であって、前記分散型コンピュータシステムは、リソースマネジャと、前記アプリケーションが割り当てられ各々複数の電力構成のうちの１つで動作可能な複数のコンピュータとを有し、前記方法は、
前記分散型コンピュータシステムの各コンピュータの中にリソースマネジャプロキシを設けるステップと、
各リソースマネジャプロキシが、前記リソースマネジャに、前記リソースマネジャプロキシが設けられた前記コンピュータの中の前記アプリケーションの実行状態の変化を通知するステップと、
前記リソースマネジャが、前記通知するステップに応答して、少なくとも１つの前記コンピュータのための電力構成を決定するステップと、
前記リソースマネジャが、前記電力構成を、前記少なくとも１つのコンピュータの前記リソースマネジャプロキシに知らせるステップと、
前記リソースマネジャプロキシが、前記知らせるステップに基づき、前記コンピュータの電力構成の変化を生じさせるステップと、
を有する方法。
【請求項２】
前記通知するステップは、前記リソースマネジャプロキシが、前記コンピュータに割り当てられた前記アプリケーションのコードの中の注釈から生成され前記実行状態を示すメッセージを識別するステップを更に有する、請求項１に記載の方法。
【請求項３】
前記リソースマネジャプロキシが、前記コンピュータの既存の電力構成を考慮することにより、前記コンピュータの前記電力構成を変更すべきか否かを決定するステップ、を更に有する請求項１又は２に記載の方法。
【請求項４】
前記リソースマネジャプロキシが、前記コンピュータの電力構成の変化を前記リソースマネジャに確認するステップ、を更に有する請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
前記電力構成は、少なくとも１つの高電力及び少なくとも１つの低電力構成を有し、前記決定するステップは、前記リソースマネジャが複数の前記コンピュータが待機状態に入ったことを識別し、該コンピュータのために前記低電力構成を決定するステップ、を更に有する、請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記待機状態は、前記アプリケーションが割り当てられた全ての前記コンピュータに影響を与えるグローバル待機である、請求項５に記載の方法。
【請求項７】
前記リソースマネジャが、前記コンピュータのうちのどれが前記待機状態に入ったかを監視するステップと、
前記リソースマネジャが、コンピュータを前記待機状態を出るために備えるべき遷移時間を決定するステップと、
前記リソースマネジャが、前記遷移時間の前に、通知元のリソースマネジャプロキシに前記低電力構成を知らせるステップと、前記遷移時間の後に、前記待機状態に入った各コンピュータの前記リソースマネジャプロキシに、前記高電力構成を知らせるステップと、
を更に有する請求項５又は６に記載の方法。
【請求項８】
前記決定するステップ及び知らせるステップにおいて、前記リソースマネジャは、先ず、少なくとも１つのコンピュータのための電力構成の前の推奨を決定し及び知らせ、次に、前記推奨を更新し及び前記リソースマネジャプロキシに前記更新した電力構成を知らせる、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
前記リソースマネジャにより決定された前記電力構成は、全ての前記コンピュータに適用され、前記通知するステップは、全ての前記リソースマネジャプロキシに前記電力構成をブロードキャストするステップを有する、請求項１乃至４のいずれか一項に記載の方法。
【請求項１０】
前記リソースマネジャは、前記通知するステップの前に、電力構成を全ての前記リソースマネジャプロキシに先制（pre−emptively）ブロードキャストするステップ、を更に有する請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
前記リソースマネジャは、前記アプリケーションが割り当てられた前記コンピュータと別個の少なくとも１つのコンピュータにより提供される、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
前記リソースマネジャは、それぞれ前記アプリケーションが割り当てられた前記コンピュータの個々の部分集合に責任のある及び通信フレームワークにより接続される複数のリソースマネジャを有する分散型形式である、請求項１乃至１１のいずれか一項に記載の方法。
【請求項１３】
アプリケーションを実行するために分散型コンピュータシステムの中の複数のコンピュータを管理するリソースマネジャであって、前記コンピュータの各々は、複数の電力構成のうちの１つで動作可能であり、前記リソースマネジャは、
前記分散型コンピュータシステムの各コンピュータの中のリソースマネジャプロキシとメッセージを交換する通信モジュールと、
リソースマネジャプロキシからの、前記アプリケーションの実行状態の変化の通知に応答して、少なくとも１つの前記コンピュータの状態を決定する状態モニタと、
前記状態モニタにより決定された前記状態に応答して、少なくとも１つの前記コンピュータのための電力状態を決定する電力構成部と、
を有し、
前記通信モジュールは、前記決定された電力構成を、前記少なくとも１つのコンピュータの前記リソースマネジャプロキシに知らせるよう配置される、リソースマネジャ。
【請求項１４】
コンピュータ可読コードであって、分散型コンピュータシステムのコンピュータにより実行されるとリソースマネジャプロキシを提供し、前記リソースマネジャプロキシは、
前記コンピュータに割り当てられたプログラムコードに含まれる、前記プログラムコードの実行状態の変化の指示を読み出すコードリーダと、
前記指示を前記分散型コンピュータシステムのリソースマネジャに転送し、前記リソースマネジャから、前記コンピュータのための電力構成推奨を受信する通信モジュールと、
前記リソースマネジャからの前記推奨に基づき、前記コンピュータの電力構成の変化を生じさせる電力管理部と、
を有する、コンピュータ可読コード。
【請求項１５】
高性能コンピューティングシステムであって、
それぞれ請求項１４に記載のリソースマネジャプロキシと請求項１３に記載のリソースマネジャとを備えられた複数の相互接続されたコンピュータ、を有する高性能コンピューティングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示のアプリケーションは、高性能コンピュータシステム（high  performance  computing：ＨＰＣシステム）のような分散型コンピュータシステムにおけるエネルギ認識型リソース管理に関する。
【背景技術】
【０００２】
本開示は、コンピュータシステムにおけるエネルギ消費、例えば、大規模コンピュータクラスタ、特に高性能コンピューティング（ＨＰＣ）システムで実行するプログラムにより消費されるエネルギ量を解決する。ＨＰＣクラスタは、互いに結合され１つの大規模な単一アプリケーションを実行するために用いられ得る多数の半独立コンピュータ（ノード）を有する。アプリケーション（又は他のジョブ）は、多数の通信タスクに分けられる。ソースマネジャは、これらのタスクをコンピュータに割り当て、消費されるエネルギを低減するためにコンピュータハードウェアの電力構成を管理できる。
【０００３】
リソースマネジャは、ＨＰＣシステムの効率的な実行を担い、ノード及び任意の他のリソースを含むリソースがサービスを要求者に供給できることを保証する。最も重要なサービス要件は、通常、可能な限り速くアプリケーショを完了することである。しかし、ノードはハイエンドコンピュータであり多くのエネルギを使用し得るので、重要性の増大している第２の要件は、可能な限り少ないエネルギを使用することである。コンピュータノードは、エネルギ消費を低減するために使用できる多様なメカニズムを有する。しかし、これらは、通常、計算性能のコストを犠牲にする。したがって、各ノードは、通常、それら個々の性能及びエネルギ使用と異なる複数の可能な動作モード又は「電力構成」を有する。
【０００４】
高性能コンピューティング（ＨＰＣ）で実行されるプログラムは、ウェブスケールコンピューティングのようなＨＰＣを他の形式の大規模コンピューティングと区別する多数の特徴を有する。これらのうちの１つは、ＨＰＣプログラムが、多数の別個のコンピュータに渡り分散される１つの計算として考えられることである（これと対照的に、ウェブスケールプログラムは、基本的に、別個のコンピュータで同時に実行される多数の独立した計算である）。計算はプログラムフェーズ又はステージを通じて進行するので、それが使用するリソースに対する要求は変化する。言い換えると、ハードウェアに対する要求は、アプリケーションの現在の「状態」に応じて変化する。この状態により、アプリケーションの完了のステージだけでなく、その時に要求されるオペレーションの種類も意味される。標準的に、プログラムの実行は、初期化及び反復フェーズを通じて進行し、同じ実行において同じコードセクションを何回も繰り返し、リソース要求は各繰り返しにおいて同様の又は同一である。
【０００５】
ウェブスケールコンピューティングでは、計算は、基本的に独立に実行し、リソース要求の変化も独立に生じ、コンピュータの全体のセットに渡るリソース使用パターンをもたらす平均的効果は平等に静的である。他方で、ＨＰＣプログラムは、プログラムが全ての占有（occupied）コンピュータに渡り同時に同じ状態に変化するので、調整されたリソース使用変化パターンを示す。
【０００６】
これらの異なるリソース使用変化パターンは、リソースマネジャの最適設計に影響を与える。ウェブスケールプログラムでは、リソース管理決定は、コンピュータにローカルに行うことができる。しかしながら、ＨＰＣ型のプログラムでは、リソース管理は、ローカルレベル管理に加えて、グローバルレベルで生じなければならない。
【０００７】
コンピュータのコアを形成するマイクロプロセッサの能力の増大は、エネルギ使用の増大をもたらす。しかしながら、最近のマイクロプロセッサ設計は、最高性能が要求されないとき、電力消費を低減する能力も有する。これは、電圧及び周波数スケーリング又はマイクロプロセッサの未使用セクションの電源を切るような種々の技術により達成される。エネルギ低減決定は、コンピュータで現在動作しているコードの観察された状態に応じて、各コンピュータ内でローカルに実施される。異なるコンピュータは、異なるエネルギ及び性能構成（電力構成）であっても良い。
【０００８】
したがって、性能及びエネルギ管理は、ＨＰＣシステムで２つのレベルで、つまり、複数のコンピュータに及ぶプログラムに渡って、及び各コンピュータにローカルに生じる。これらの管理決定は、異なる時間尺度で動作する。ローカル管理は、短時間の変化に応答して速い。グローバル管理時間尺度は、それらが個々のコンピュータからの情報を中央リソースマネジャプログラムに通信するのに要する時間により、管理決定を行うために集めた情報を処理するのに要する時間により、及びコンピュータに該決定を配信するのに要する時間により決定されるので、もっと長い。
【０００９】
変化する電力構成は、時間を要し、コンピュータに渡る電力構成変化の粗悪な調整は、ＨＰＣプログラムの性能に悪影響を与え得る。したがって、ローカル電力管理は、オフにされ、又は非常に控えめに動作されて、許容可能な性能を保証するがエネルギ節約の多くの機会を失う場合が多い。他方で、中央型管理は、全てのエネルギ節約機会を活かすために十分に素早く分配されない。
【００１０】
ＨＰＣアプリケーションをノードに渡り分配するとき、ノード間の一部の通信は常に必要であるが、アプリケーションの各部分は、他の部分から可能な限り多く分離される。通信は、ノードが他のノードからのメッセージの到着を待つとき、ノードにそれらの実行を調整させる。調整の程度は、アプリケーション及びアルゴリズム種類に伴い変化するが、通常、ノードが他のノードの計算の完了を待つことは、アプリケーションの実行中に何回も存在する。調整のためのこれらの待機の回数は、グローバル通信（つまり、アプリケーションに割り当てられた全てのノードに渡る）を必要とする。したがって、あるノードによる実行までの遅延は、最も遅いノードに追いつくためにアプリケーション全体を待機させる。これは、グローバル調整バリア又は単に「グローバルバリア」と呼ばれる。
【００１１】
これを説明するために、図１は、４個のノードＡ〜Ｄで実行する単純なプログラムの実行フェーズを示し、水平バーに沿った長さにより時間を表す。プログラムは４個のフェーズ、つまり、実行、待機、実行及び待機を有する。待機依存関係は、ノード間の矢印として示される。第１の待機フェーズは、ノードがペア、つまりＡとＢ、及びＣとＤでのみ通信するので、ローカル調整バリアをモデル化する。第２の待機は、グローバルバリアをモデル化する。各ノードは、完了前に全ての他のノードを待つ。これは、図中で「グローバル待機」と付され、全てのノードが（通常）ここで待機しなければならないことを示す。待機フェーズにあるノードは、待機フェーズの開始により表される特定のタイミングにおいて、バリアに「入った」と記載されても良い。
【００１２】
コンピュータに渡り負荷及び実行時間に不平衡が存在するので、個々のコンピュータは、異なる時間にバリアに到達する。その結果、幾つかのコンピュータは他のコンピュータが追いつくのをグローバルバリアで待機する。大気中のコンピュータは計算していないので、それらは、全てのコンピュータがグローバルバリアに来るまで、低エネルギ電力構成に置かれ、性能に影響を与えない。しかしながら、構成変化を達成するために要する時間はプログラムの性能を遅くするので、グローバルバリアに遅く到着することは、高電力／高速性能電力構成のままでなければならない。この決定は、各コンピュータが自身が到着キューのどこにいるのか分からないので、ローカルに行うことができない。したがって、決定は、中央で、しかし可能な限り多くのエネルギを節約するために可能な限り速く行われなければならない。
【００１３】
中央管理領域（リソースマネジャ）における時間尺度は、ローカル時間尺度よりも遙かに長い。これは、効果的な決定を行うために十分なメッセージを受信するために要する時間、及びメッセージを処理するための時間、より具体的には、コンピュータ数に対応する最適化アルゴリズムを実行するのに要する時間、及びデータ構造の部分にアクセスするための時間、に起因する。クラスタ内のコンピュータ数は１０００００〜１００００００に及ぶので、任意の中央管理のために要する時間は長すぎるだろう。
【００１４】
解決すべき問題は、多数の参加しているコンピュータが計算中のエネルギ節約の短命な機会を生かすために十分速く中央決定を行い分配することである。
【００１５】
多くのリソースマネジャは、ジョブのエネルギ節約モードをＨＰＣクラスタの使用に設定する能力を公開する。この能力は、（例えば、他の使用リソースに加えて使用されるエネルギについて変更されることにより）ユーザがエネルギを節約しようという動機づけを有しないので、うまく使用されていない。また、ユーザは、彼らのアプリケーションの実効性能を低下させなくない（つまり、彼らはソリューションのための時間を最小限に抑えたい）。したがって、リソースマネジャは、性能が影響されないことが保証できるエネルギ節約モードを自動的に適用する必要がある。
【００１６】
同様に、ロ―カルオペレーティングシステムは、それらの基本ハードウェアの電力構成を直接設定する能力を有する。ハードウェアに存在するこの能力は、ＨＰＣクラスタに存在する殆どのオペレーティングシステムで公開される。この能力の使用は、通常限られている。つまり、この能力は、レートを実行するためにローカルに決定される変化は、コンピュータに渡り累積され実行中に大きな全体遅延を生じ、分散型アプリケーションの計算レートに予測できない効果を与えるので、通常オフにされる。
【００１７】
「エネルギ認識型」リソースマネジャの従来技術は、米国特許出願ＵＳ２０１２０２１６２０５及びＵＳ２００９０１００４３７により開示されている。これらは、前に提出されたジョブの性能特性のデータベースを有するリソースマネジャ、及び所与の性能特性を有するジョブでクラスタをエネルギ節約モードに置くことの影響の計算モデルを記載する。リソースマネジャは、前に提出されたジョブと同じジョブを識別できる場合、性能に影響を与えない最適エネルギ構成を計算するために、記録された特性を用いる。
【００１８】
従来技術において解決されない問題は、エネルギ効率の最適構成がアプリケーションの実行中に、多くの場合に高頻度で変化することである。アプリケーションの期間中に単一構成を設定することは、常に、幾らかの性能を失い、最高エネルギ効率を達成できない。
【００１９】
リソースマネジャの階層構造を通じて管理の責任を分配することが提案されている（例えば、CN１０３２６８２６１及びArgo,  http://www.mcs.anl.gov/project/argo−exascale−operating−system）。計算及びデータ収集負荷を多数の小さなコンポーネント間に分配することは、個々の計算負荷を低減し、したがって反応性を増大する。しかしながら、サブマネジャの各々はコンピュータの限られた部分集合からデータを受信するだけなので、システム全体の最適動作を保証できない。
【発明の概要】
【発明が解決しようとする課題】
【００２０】
したがって、上述の問題を回避する分散型コンピュータシステムのエネルギ認識型管理を提供することが望ましい。
【課題を解決するための手段】
【００２１】
本開示の一態様の一実施形態によると、分散型コンピュータシステムでアプリケーションを実行する方法であって、前記分散型コンピュータシステムは、リソースマネジャと、前記アプリケーションが割り当てられ各々が複数の電力構成のうちの１つで動作可能な複数のコンピュータとを有し、前記方法は、前記分散型コンピュータシステムの各コンピュータの中にリソースマネジャプロキシを設けるステップと、各リソースマネジャプロキシが、前記リソースマネジャに、前記リソースマネジャプロキシが設けられた前記コンピュータの中の前記アプリケーションの実行状態の変化を通知するステップと、前記リソースマネジャが、前記通知するステップに応答して、少なくとも１つの前記コンピュータのための電力構成を決定するステップと、前記リソースマネジャが、前記電力構成を、前記少なくとも１つのコンピュータの前記リソースマネジャプロキシに知らせるステップと、前記リソースマネジャプロキシが、前記知らせるステップに基づき、前記コンピュータの電力構成の変化を生じさせるステップと、を有する方法が提供される。
【００２２】
このようなリソースマネジャは従来知られているが、リソースマネジャプロキシは、本開示において新規に提供される。リソースマネジャプロキシは、各コンピュータの中にあり、リソースマネジャの一種のローカルエージェントである。リソースマネジャプロキシは、電力構成を直接実施する必要はないが、例えば、変更を有効にするために、コンピュータ自体のＯＳと通信しても良い。
【００２３】
リソースマネジャプロキシは、実行状態の変化を検出するために、それ自体のコンピュータにより実行中のコードをモニタする。望ましくは、前記通知するステップは、前記リソースマネジャプロキシが、前記コンピュータに割り当てられた前記アプリケーションのコードの中の注釈から生成され前記実行状態（又はその変化）を示すメッセージを識別するステップを更に有する。
【００２４】
リソースマネジャは、例えば、コンピュータのための使用すべき新しい電力構成の推奨を行うことにより、リソースマネジャプロキシに電力構成を知らせる。これに応答して、リソースマネジャプロキシは、コンピュータの既存電力構成を考慮することにより、コンピュータの電力構成を変更するか否かを決定しても良い。したがって、例えば、知らせるステップで推奨された電力構成が現在の構成と同じ場合、変更は必要ない。
【００２５】
リソースマネジャプロキシは、リソースマネジャにメッセージを送信することにより、コンピュータの電力構成の変化を確認しても良い。代替で、リソースマネジャプロキシは、推奨された電力構成が何らかの理由により実施されない場合、リソースマネジャに知らせても良い。
【００２６】
望ましくは、前記電力構成は、少なくとも１つの高電力及び少なくとも１つの低電力構成を有し、前記決定するステップは、前記リソースマネジャが複数の前記コンピュータが待機状態に入ったことを識別し、該コンピュータのために前記低電力構成を決定するステップ、を更に有する。
【００２７】
ここで、待機状態は、アプリケーションが割り当てられた全てのコンピュータに影響を与える（グローバルバリアによる）「グローバル待機」であっても良い。代替で、待機状態は、一部のコンピュータに影響を与えるが他には与えない「ローカル待機」であっても良い。
【００２８】
いずれの場合にも、方法は、前記リソースマネジャが、前記コンピュータのうちのどれが前記待機状態に入ったかを監視するステップと、前記リソースマネジャが、コンピュータを前記待機状態を出るために備えるべき遷移時間を決定するステップと、前記リソースマネジャが、前記遷移時間の前に、通知元のリソースマネジャプロキシに前記低電力構成を知らせるステップと、前記遷移時間の後に、前記待機状態に入った各コンピュータの前記リソースマネジャプロキシに、前記高電力構成を推奨するステップと、を更に有する。
【００２９】
前記「遷移時間」は、何個のコンピュータが既に待機状態に入っているか（言い換えると、バリアに到達したか）、及び／又はバリアに到達した最初のコンピュータが待機を開始してから経過した時間に依存しても良い。
【００３０】
いずれの場合にも、前記方法は、前記決定するステップ及び知らせるステップにおいて、前記リソースマネジャが、先ず、少なくとも１つのコンピュータのための電力構成の前の推奨を決定し及び知らせ、次に、前記推奨を更新し及び前記リソースマネジャプロキシに前記更新した電力構成を知らせるステップを有する。
【００３１】
幾つかの例において、リソースマネジャにより決定された電力構成は、全てのコンピュータに適用し、この場合に、上述の通知するステップは、電力構成を全ての前記リソースマネジャプロキシにブロードキャストするステップを有する。
【００３２】
さらに、リソースマネジャは、通知するステップの前に、電力構成を全ての前記リソースマネジャプロキシに先制（pre−emptively）ブロードキャストしても良い。言い換えると、リソースマネジャは、電力構成の推奨を提供する前に、リソースマネジャプロキシから報告を受信するのを待つ必要がない。
【００３３】
望ましくは、リソースマネジャは、アプリケーションが割り当てられたコンピュータとは別個の少なくとも１つのコンピュータにより提供される。
【００３４】
前記リソースマネジャは、それぞれ前記アプリケーションが割り当てられた前記コンピュータの個々の部分集合に責任のある及び通信フレームワークにより接続される複数のリソースマネジャを有する分散型形式で提供されても良い。
【００３５】
本開示の第２の態様によると、アプリケーションを実行するために分散型コンピュータシステムの中の複数のコンピュータを管理するリソースマネジャであって、前記コンピュータの各々は、複数の電力構成のうちの１つで動作可能であり、前記リソースマネジャは、前記分散型コンピュータシステムの各コンピュータの中のリソースマネジャプロキシとメッセージを交換する通信モジュールと、リソースマネジャプロキシからの、前記アプリケーションの実行状態の変化の通知に応答して、少なくとも１つの前記コンピュータの状態を決定する状態モニタと、前記状態モニタにより決定された前記状態に応答して、少なくとも１つの前記コンピュータのための電力状態を決定する電力構成部と、を有し、前記通信モジュールは、前記決定された電力構成を、前記少なくとも１つのコンピュータの前記リソースマネジャプロキシに知らせるよう配置される、リソースマネジャが提供される。
【００３６】
本開示の第２の態様によると、高性能コンピュータシステムであって、それぞれ上述のリソースマネジャプロキシと上述のリソースマネジャとを備えられた複数のコンピュータを有する高性能コンピュータシステムを提供する。
【００３７】
本開示の更なる態様によると、コンピュータ可読コードを有するソフトウェアであって、分散型コンピュータシステムのコンピュータにより実行されるとリソースマネジャプロキシを提供し、前記リソースマネジャプロキシは、前記コンピュータに割り当てられたプログラムコードに含まれる、前記プログラムコードの実行状態の変化の指示を読み出すコードリーダと、前記指示を前記分散型コンピュータシステムのリソースマネジャに転送し、前記リソースマネジャから、前記コンピュータのための電力構成推奨を受信する通信モジュールと、前記リソースマネジャからの前記推奨に基づき、前記コンピュータの電力構成の変化を生じさせる電力管理部と、を有する、ソフトウェアが提供される。
【００３８】
強調されるべきことに、「コンピュータ」はリソースマネジャプロキシとして動作するだけでなく、アプリケーションの部分、つまり上述の「コンピュータに割り当てられたプログラムコード」も実行する。
【００３９】
更なる態様は、上述のリソースマネジャを提供するソフトウェアに関連する。
【００４０】
このようなソフトウェアは、１又は複数の非推移的コンピュータ可読記録媒体に格納されても良い。
【００４１】
したがって、本開示の実施形態は、エネルギ認識型ＨＰＣリソースマネジャのための新規なアーキテクチャを提供する。設計は、計算ノードの負荷を最小化し、一方で、エネルギを節約するために利用できる短命の状態の利用を可能にするために十分速い応答を保証する。リソースマネジャは、望ましくは、それ自体が計算ノードの１つではないコンピュータにより提供される。代替の実装は、通信リソースマネジャピアのグループとして、バックグラウンド及びバックチャネル通信を通じた補正に応答するために負荷を分散する。
【００４２】
実施形態は、複数のコンピュータを占有するアプリケーションの全体的状態を考慮してＨＰＣクラスタ内の個々のコンピュータの電力構成のきめ細かい応答型制御を可能にすることにより、特に排他的ではなく高性能コンピューティングシステムで使用中のエネルギ量を低減できる。このようなきめ細かい制御は、グローバルプログラム状態の知識と高速なローカル状態変化との間の未解決の緊張（tension）により現在のシステムにおいて利用できない。その結果、多くのエネルギ節約機会が失われている。
【００４３】
本願明細書では、「電力構成」は、分散型コンピュータシステムの中のコンピュータの１又は複数の設定を表し、特定の性能レベル及び特性のエネルギ使用レベルの両方を意味する。プログラムの「状態」は、所与のコンピュータに関して、検討中の該コンピュータにより現在実行中のアプリケーションコードの一部、及びコードの該一部により指示される（「計算する」、「待機する」、又は「データを移動する」のような）動作の種類を表す。用語「ノード」、「サーバ」及び「コンピュータ」は、文脈上特に断らない限り、同義的に用いられる。同様に、用語「システム」及び「クラスタ」は等価である。用語「アプリケーション」、「プログラム」及び「ジョブ」は、文脈上特に断りのない限り、同義的に用いられる。
【図面の簡単な説明】
【００４４】
単に例として、添付の図面を参照する。
【図１】複数のノード間に分配されたアプリケーションの実行時系列を示す。
【図２】本開示の実施形態が適用されるコンピュータシステム（ＨＰＣクラスタ）を示す。
【図３】図２のシステムの１つのコンピュータ内の機能ブロックを示す。
【図４】図２のシステムのリソースマネジャプロキシの機能モジュールを示す。
【図５】図２のシステムのリソースマネジャプロキシの機能モジュールを示す。
【図６】本開示を実施する１つの方法における、リソースマネジャの処理フローを示す。
【図７】図６の処理フローの変更バージョンを示す。
【図８】リソースマネジャプロキシ内の処理フローを示す。
【図９】リソースマネジャが分配される別の実施形態を示す。
【発明を実施するための形態】
【００４５】
本発明の実施形態を、図２〜９を参照して以下に記載する。
【００４６】
図２は、本開示の一実施形態における分散型コンピュータシステム１００を示す。リソースマネジャ２００は、ＨＰＣクラスタ１００内の多数のコンピュータ１０１の電力構成を制御する。コンピュータ１０１は、ＨＰＣプログラムの計算ノード（又は「コンピュータノード」）を有する。図２は８個のコンピュータを示すが、ハイエンドＨＰＣクラスタは、何千乃至何十万ものコンピュータからのリソースを用いるＨＰＣプログラムを実行する。各コンピュータは、最高電力、高性能構成、及び１又は複数のエネルギ節約、低性能モードを含む複数の電力構成のうちの任意の１つで動作可能であるとする。
【００４７】
各コンピュータは、本開示に関連する３個のプログラムを実行する。これらのプログラムは互いに独立である。プログラムは、リソースマネジャプロキシ２０１、ローカルオペレーティングシステム１０３、及びＨＰＣアプリケーションのローカル部分１０４である。
【００４８】
本実施形態では、リソースマネジャ２００は、ＨＰＣクラスタの一部であるが管理しているアプリケーションの任意の部分を実行しない別のコンピュータで実行される。したがって、リソースマネジャ自体はコンピュータリソースを使用するコンピュータプログラムであるが、別個のリソースがこの目的のために提供され、ＨＰＣプログラムの実行と干渉すること及びＨＰＣアプリケーション全体の性能を低速にすることを回避する。
【００４９】
リソースマネジャプロキシ２０１は、各ローカルコンピュータ１０１にあるリソースマネジャ２００を表す非常に軽量な（言い換えると、自身のホストコンピュータのリソース使用量の非常に低い）プログラムである。つまり、リソースマネジャプロキシは、中央リソースマネジャを支援するローカルマネジャである。アプリケーションの実行において役割を果たすコンピュータ１０１毎に、１つのリソースマネジャプロキシが存在する。その軽量さは、ＨＰＣアプリケーションのローカル部分との干渉が小さいことを意味する。リソースマネジャプロキシ２０１は、本開示において新規であり、軽量に保つことを可能にする方法が提案される。
【００５０】
ローカルオペレーティングシステムは、コンピュータハードウェアの電力構成を管理するためのインタフェースである。
【００５１】
ローカルＨＰＣプログラム１０４は、コンピュータ上で実行するＨＰＣアプリケーションの部分である。留意すべきことに、ローカルＨＰＣプログラムの制御フローは、全ての他のローカルＨＰＣプログラムのフローと独立に実行する。ＨＰＣアプリケーションの調整は、ローカルＨＰＣプログラム間でメッセージを渡すことにより達成される。
【００５２】
本開示は、メッセージの受け渡しの追加パターンを提案する。図２で、これらのメッセージは、リソースマネジャと例えば１０５で示されるような各コンピュータとの間で渡される。
【００５３】
図３は、図２の単一のコンピュータをより詳細に示す。同じ構造が、ＨＰＣアプリケーションの部分を実行している全てのコンピュータに適用される。リソースマネジャ２００との全ての通信は、リソースマネジャプロキシ２０１を通る。この通信は、２０２で示されるように双方向である。リソースマネジャプロキシは、ローカルＨＰＣプログラムの状態（以下を参照）に対する変化に関するリソースマネジャ情報を送信し、（ローカルＨＰＣプログラムの状態及びＨＰＣアプリケーション全体の状態が与えられた場合に）ハードウェアの最適電力構成についてのリソースマネジャからの提案を受信する。リソースマネジャプロキシは、電力構成を設定するために、ローカルオペレーティングシステム２０３と相互作用する。ローカルＨＰＣプログラムとリソースマネジャプロキシとの間の通信は、一方向であり、２０４により示されるようにローカルＨＰＣプログラムは送信するのみであり、例えば、状態変化を示す短いメッセージを有する。
【００５４】
本開示を用いるＨＰＣプログラムは、報告の目的でＨＰＣプログラムに追加される関数呼び出しを用いて、自身の状態を自身のローカルリソースマネジャプロキシに報告できることが必要である。これらの呼び出しは、エネルギ節約のために利用できる特性を有するコードセクションに入ること及びそれから出ることを示すべきである。
【００５５】
このようなコードセクションの例は、以下を含む。
＊可能な最大速度で実行すべき、数値計算セクション。
＊例えば、完了すべき通信又は到達されるべきバリアを待つ、低減電力消費で動作可能な、待機セクション。
＊低減電力消費で動作可能な、ローカルデータ移動セクション（例えば、ディスクにデータを転送する）。
【００５６】
明らかなことに、上述のセクションの種類の各々は、異なるプログラム「状態」に対応する。コードの数値計算セクションを現在実行しているコンピュータに対するリソース要求は、例えば待機セクションにいるものより遙かに大きい。したがって、これらの異なる状態は、コンピュータの電力構成を設定する目的で区別され得る。
【００５７】
これらのセクションは、共有メモリマルチプロセッシングプログラミングのための所謂ＯｐｅｎＭＰのパターンに従う、ＨＰＣアプリケーションコードの中の適切なマーク付けを要求する。この目的は、実行、通信、待機、等のような異なるプログラム状態に対応する異なるコード部分を識別するために、プログラムコードに注釈を付けることである。プログラミング技術の現在の状況では、マーク付けは、自動技術も可能であるかも知れないが、通常、人間のプログラマにより実行される必要がある。このような注釈を付けられたコードの例は、次の通りである。ここで、「#pragma  amee」で始まる文は、リソースマネジャ向けのメッセージを意図している。
【数１】
2016012347.tif 000003
【００５８】
ここで、リソースマネジャプロキシ向けの注釈（通知）は、コンパイルのときに、注釈を分析しそれらを呼び出しに変換する伝統的な技術を用いて、通信呼び出しと同様の方法で変換される。したがって、リソースマネジャプロキシは、関連するコンピュータにおいてプログラム実行が先に例示した文のうちの１つに到達する度に通知を受信しても良い。
【００５９】
留意すべきことに、図２及び３のアーキテクチャでは、通信はコンピュータにローカルである。これは、ＨＰＣアプリケーション内のメッセージングのために用いられるクラスタ全域の通信ではなく、ローカルオペレーティングシステム（例えば、メッセージキュー又は共有メモリセグメントのような標準的なUnix（登録商標）  Interprocess  Communication（ＩＰＣ）技術）により提供される軽量且つ高速通信方法を利用できることを意味する。
【００６０】
図４は、リソースマネジャプロキシの機能モジュールを示し、コンピュータ内のアプリケーションの実行状態の変化を示す上述の文を受信するコードリーダ２０７と、分散型コンピュータシステムのリソースマネジャ２００に実行状態の変化を通知し及びリソースマネジャから電力構成推奨を受信する通信モジュール２０５と、リソースマネジャからの推奨に基づきコンピュータ１０１の電力構成の変化を開始する電力マネジャ２０９と、を有する。
【００６１】
リソースマネジャプロキシ２０１は、ローカルＨＰＣプログラムと同じコンピュータで実行し、ローカルＨＰＣプログラムとリソースを競合すべきではないので、軽量プログラムである。コードリーダ２０７は、現在実行中のコードセクションの変化、したがって実行状態を示す上述の注釈をプログラムコードに埋め込まれたメッセージとして検出する。コードリーダは、このような注釈、例えば上述の「#pragma  amee」注釈の結果として生成されたメッセージに反応するようプログラムされても良く、該メッセージをデコード又は理解する必要がない。通信モジュール２０５は、これらのメッセージをＨＰＣプログラムからリソースマネジャへと中継する。通信モジュールからのメッセージは、情報コンテンツ又は「ペイロード」に加えて、発信元コンピュータの識別表示を含む。ペイロード自体は、注釈から生成された上述のメッセージを単に再生しても良く、或いは該メッセージを特定の処理済み形式で提供しても良い。通信モジュール２０５は、リソースマネジャから、電力構成変化の要求又は推奨も受信する。次に、電力マネジャ２０９は、ローカルオペレーティングシステム２０３へ命令を送信することにより（適切な場合には）電力変化を実施する。ローカルオペレーティングシステム２０３は、コンピュータの電力管理を最終的に担うと考えられる。この場合（例えば、リソースマネジャ２００と通信モジュール２０５との間の相互作用）、通信はＨＰＣクラスタ内のコンピュータに跨る。しかしながら、ＨＰＣクラスタは、効率的な通信ネットワーク及びそれらにアクセスするための標準化ＡＰＩを有する。したがって、リソースマネジャ通信に対するリソースマネジャプロキシはこれらを使用できる。一例は、メッセージ通過インタフェースＡＰＩである。
【００６２】
リソースマネジャプロキシ２０１は、専らメッセージの受信及び送信並びに電力構成変化の実施に関する少ない知能しか必要ないが、特定の簡単な処理を実行しても良い。例えば、以下に記載されるようにリソースマネジャが素早く応答しようとする場合でさえ、ローカルプログラム状態はリソースマネジャ要求が受信される前に変化し得る。リソースマネジャプロキシは、現在のローカルＨＰＣプログラム状態が要求された電力構成と矛盾する場合、要求された電力構成を無視することを選択しても良い。
【００６３】
図５は、本開示に関連する、リソースマネジャ２００の機能モジュールを示す（プログラムコードを各コンピュータに最初に割り当てるスケジューラのような他の機能モジュールが存在することを排除するものではないが、これは本開示の範囲外である）。
【００６４】
リソースマネジャ２００では、通信モジュール２１０は、個々のリソースマネジャプロキシを介して、アプリケーションに割り当てられた全てのコンピュータからメッセージを受信する。本開示の説明を目的として、リソースマネジャ２００とコンピュータ１０１との間の通信のみが、リソースマネジャプロキシ２０１を介する。しかしながら、リソースマネジャは、通常、コンピュータ１０１に加えてＨＰＣシステムの他の態様を管理するので、リソースマネジャが他のソースからも入力を受信することが可能である。例えば、リソースマネジャは、ライブラリ関数の開始及び終了に関する情報を受信しても良い。
【００６５】
状態モニタ２１２は、ＨＰＣプログラムの全体状態を評価するため及びエネルギ節約の機会を検出するために、これらのメッセージを監視する。状態モニタは、ＨＰＣクラスタに関与する全てのコンピュータを認識し、発信元コンピュータの識別子に基づき、入来メッセージを区別できる。状態モニタ２１２により監視される全体状態に基づき、電力構成部２１４は、コンピュータのうちの１又は複数をエネルギ節約モードに切り替えることによりエネルギ節約の機会を利用し、それに応じて、リソースマネジャプロキシに指示するために通信モジュール２１０にメッセージを送信する。（ブロードキャストメッセージ−以下を参照−とは対照的に）特定のコンピュータ向けのメッセージは、宛先コンピュータの識別表示を含み、メッセージがメッセージ通過インフラストラクチャを介してルーティングできるようにする。通信モジュールは、リソースマネジャプロキシから、推奨電力構成が採用されたことの（又は代替で無視されたことの−上記を参照）確認のような返信メッセージを受信しても良い。
【００６６】
発見的アクションのデータベースを実行中コードの種類について検索すること、及び可能性の高いプログラム展開を推定するために前の反復からのデータを使用すること、及び（パターンマッチング、一般的アルゴリズム、等により）最適方針を計算することを含む種々の処理技術がこれらの機会を検出するために使用できる。しかしながら、メッセージの数及び電力構成を導出するために必要な結果として生じる処理は、報告するコンピュータのために最適な新しい電力構成を計算するのに長時間を要し得ることを意味する。したがって、電力構成部２１４は、情報の不完全な処理に基づき暫定的推奨、つまり誤っている又は準最適な電力構成、を行うことが望ましい。通信モジュール２１０により通信されるこの推奨と並列に、電力構成部２１４は、最適電力構成を計算し、将来の特定の時点で自身の推奨を更新しても良い。
【００６７】
エネルギ節約機会を識別する方法を検討する前に、ＨＰＣアプリケーションが通常以下の特性を有することが分かる。
【００６８】
（ｉ）アプリケーションは、（少なくとも電力設定に関して）個々に制御可能な多数のノードに渡り分散される。
【００６９】
（ｉｉ）ノードは、アプリケーションの自身の個々の部分を独立に実行するが、全ての重要アプリケーションはノード間の通信を必要とし、したがって進行が相互調整点（バリア）に達しているパートナーノードに依存するポイントを有する。
【００７０】
（ｉｉｉ）アプリケーションは、通常、多数の初期化及び反復フェーズを有し、各初期化フェーズの後に反復フェーズが続く。初期化フェーズは、全実行時間と比較して相対的に短くても良い。
【００７１】
（ｉｖ）計算を通して進行のレートは、例えばノードの負荷不平衡、該ノードで実行中の他のコードからの干渉、及び異なるノード能力により、ノード毎に変化し得る。これは、バリアで他のノードを待機する幾つかのノードを生じる。
【００７２】
したがって、ノードがグローバルバリアで待機している場合、１つのエネルギ節約機会が生じる。標準的なＨＰＣアプリケーションは、先に言及した反復フェーズの繰り返しによって、複数の同様のグローバルバリアを有すると期待できる。このバリアに最も早く到達するコンピュータは、低電力構成に移るよう指示されるが、殆ど全てのコンピュータがバリアに到達する特定の時点において、最適方針は、遅く到達したものを高電力構成のままにし、他のものを高電力構成に移し始めることである。リソースマネジャは、ＨＰＣプログラムの同じ実行中のバリアの多くのインスタンスを監視することによりこの転換を行うために、最適遷移時間（任意のコンピュータがバリアに最初に入ってから経過した時間）を学習する。これは多くの処理を必要とし、したがって古い情報を使用する可能性がある。
【００７３】
図６は、リソースマネジャにおける上述の場合のロジックのフローを示す。リソースマネジャは、各コンピュータの状態、つまり到達した実行ステージ、の記録を保持する。リソースマネジャは、ステップ３００でメッセージを待ち、メッセージがリソースマネジャプロキシから受信されると、３０１で処理が開始する。リソースマネジャは、コンピュータからメッセージが受信された該コンピュータを、グローバルバリアに到達したＮ番目のコンピュータとして識別し、該コンピュータの記録された状態を更新する。ステップ３０２で、リソースマネジャは、先に言及した転換を実行すべき遷移時間に到達したことを決定する。このような決定は、番号Ｎ（つまり、何個のコンピュータがバリアに到達しているかの数）、バリアでの経過時間、又は望ましくはこれらの両者に基づくことができる。リソースマネジャは、直ちに、このバリアの到達の状態を調べ、推奨電力構成と共にＮ番目のコンピュータへの応答を設定する（ステップ３０２、３０３、３０４）。
【００７４】
次に、処理は、ステップ３０５で２つの同時スレッドに分かれる。第１のスレッドは、新しいメッセージを待つ高優先度であり、ステップ３００に戻るフローを有する。第２のスレッドは、低優先度の、メッセージの更なる（バックグラウンド）処理を有し、先ず、必要な場合には前の報告コンピュータの電力構成を変更しても良い（ステップ３０６）。前の報告コンピュータ１乃至Ｎ−１の電力構成の変化は、これらのコンピュータの現在の電力状態がステップ３０７で決定された現在の推奨と異なる場合、必要である。第２のスレッドは、ステップ３０７で、このバリアに対するリソースマネジャの応答を更新及び最適化する処理を更に有する。この結果、ステップ３０５で低電力構成の推奨から高電力構成の推奨までの遷移時間の新しい値を設定する（ステップ３０８）。この遷移時間の新しい値は、プログラム実行中の同じ（又は対応する）バリアの将来のインスタンスに適用される。
【００７５】
本開示の技術的関心の中心は、エネルギを節約するために最適構成がローカルコンピュータで動作できるように十分速く、グローバルな状況を考慮に入れた該最適構成を該ローカルコンピュータに分配することである。上述の議論は、ポイントツーポイントの「二重」通信を検討した。しかしながら、推奨構成の変化が行われると、該変化は、計算に参加している全てのコンピュータに適用される場合が多い。これは、前の構成をリセットすることが最適であることを意味する（例えば、ステップ３０６）。これはまた、プロキシからリソースマネジャへの通信ステップの前に構成変化をローカルに適用させるために、この現在の推奨構成を全てのコンピュータへ送信することが最適であることも意味する。したがって電力構成の変化に対する応答を高速化する。
【００７６】
図７は、この変形プロトコルを示し、推奨構成の先制（pre−emptive）及び後制（post−emptive）ブロードキャストを含む。ここで、「ブロードキャスト」は、先に議論したような１つのリソースマネジャプロキシだけでなく、全てのリソースマネジャプロキシへ送信されるメッセージを表す。ブロードキャストメッセージは、ターゲットポイントツーポイントメッセージと同じ方法で、リソースマネジャプロキシにより受信され得る。しかしながら、リソースマネジャプロキシは、このようなブロードキャストを受信するために、リソースマネジャへの報告に対する応答を待つときだけでなく、常に準備している必要がある。
【００７７】
最初のステップ４００で、リソースマネジャは、コンピュータからの入来メッセージを待つ。ステップ４０１で、メッセージは、Ｎ番目のコンピュータから到着し、従属状態（subject  state）に達する。メッセージは、このＮ番目のコンピュータの最適構成を決定するために高優先度で処理される（ステップ４０２、４０３、４０４）。処理は、Ｎ番目のコンピュータの最適構成を設定して更に入来メッセージを待つ高優先度スレッドに分かれる。従属状態（実行のステージ）の推奨構成に変化があった場合、低優先度スレッドは、この変化を全ての参加コンピュータに（ステップ４０６を参照、つまり、既に従属状態であることを報告したコンピュータ、及び未だ報告していないコンピュータに）ブロードキャストする。リソースマネジャは、次に、ステップ４０７及び４０８の処理を実行し、グローバルアプリケーション状態のビューを更新する。留意すべきことに、ステップ４０５及び４０６は、必ずしも常に生じるものではなく、Ｎ番目のコンピュータが既に（ブロードキャストメッセージを通じて）推奨電力構成を知っている場合、ステップ４０５のみが必要であり、ステップ４０６は、推奨電力構成が変化する場合にのみ必要である。
【００７８】
図８は、リソースマネジャプロキシ２０１内の制御フローを示す。先ず、ステップ５００で、プロキシは、自身のローカルプログラム（ＨＰＣアプリケーションの一部）から又はリソースマネジャからのメッセージを待つ。ステップ５０１で、ローカルプログラムからのメッセージは、プログラム状態のローカルな変化を示す。ステップ５０２で、プロキシは、ブロードキャストステップ４０６の一部として、この状態のための推奨を既に受信していても良い。既に受信している場合、ステップ５０３で、プロキシは、ローカルハードウェアに該構成を適用する。推奨が適用されると、ステップ５０４は、メッセージをリソースマネジャに中継する。リソースマネジャ応答推奨は、プロキシにより保持される推奨から変化しても良い。この場合、ステップ５０５で、新しい構成はローカルハードウェアに適用され、応答推奨も新しい推奨である場合にはここで適用される。リソースマネジャプロキシは、次に、待機状態に戻る（ステップ５００）。
【００７９】
ステップ５０６で、リソースマネジャからのメッセージは、可能なプログラム状態のうちの任意のものに適用しても良い。プロキシは、推奨を記録し、現在のプログラム状態に適用する場合（ステップ５０７でＹｅｓ）、ステップ５０５で該推奨をハードウェアに適用し、その他の場合、待機状態に戻る。
【００８０】
リソースマネジャとリソースマネジャプロキシとの間で渡されるメッセージは、状態変化が生じるコード中のポイントを一意に識別する必要がある。既に言及したように、ＨＰＣコードは、通常、反復的な繰り返すコードセクションであり、多くの場合異なるデータを有する。これは、メッセージがコードを通じてどのパスが適用するかを識別する必要もあることを意味する。したがって、いずれの方法で渡された又はブロードキャストされたメッセージのペイロードは、少なくとも２つの値、つまりコード部分識別子及びパス識別子を有する。コード部分は、先に言及した２つの注釈の間のプログラムのセクションとして定められても良い。或いは、等価に、注釈自体がコード部分のラベルを形成できる。
【００８１】
本開示の更なる実施形態は、単一のリソースマネジャをリソースマネジャのグループで置き替える。各リソースマネジャは、アプリケーションに割り当てられたコンピュータの部分集合に責任を持つ。リソースマネジャ間の関係は公平であり、全てのリソースマネジャはピアであり、階層構造は存在しない。リソースマネジャとそれらのプロキシとの間のプロトコル及び相互作用は、上述のままであるが、構成要素であるリソースマネジャがアプリケーションのグローバルビューを交渉するとき、構成要素であるリソースマネジャ間の追加通信が存在する。
【００８２】
リソースマネジャは、アプリケーション内にグローバル演算が存在するときに取るべき最適な動作のビューを得るために、情報を共有する必要がある。例えば、グローバル待機を最適化する際に、全てのリソースマネジャは、アプリケーションが待機状態中に過ごす合計時間、つまり最初のコンピュータが待機状態に入ってから最後に待機状態を終了するまでの間の時間長、を認識するべきである。ＨＰＣアプリケーションは規則的パターンを有し反復的なので、前の反復に基づく決定は公平に正確である。これは、分散型リソースマネジャが自身のクライアントコンピュータを前の反復からのデータから決定された最適化により制御することを意味する。バックグラウンドで、それらは、自身の最適化を更新でき、特定の状態変化の次の反復に備える。これは、リソースマネジャ間のバックグラウンド相互作用により行うことができる。
【００８３】
図９はこの実施形態を示す。コンピュータ１０１は、図２のコンピュータと同じであり、同じ内部配置を有する。コンピュータ１０１は、同じ方法で、つまり自身のリソースマネジャプロキシを介して、リソースマネジャと通信する。ここで、リソースマネジャの１つより多いインスタンス２００ａ、２００ｂ、．．．、２００ｅが存在し、単に既存の通信ハードウェアの上部のソフトウェア構成であっても良くリソースマネジャとリソースマネジャプロキシとの間の通信に類似するリソースマネジャ内通信フレームワーク２２０がある。
【００８４】
分散型リソースマネジャは、コンピュータの正確なグローバルカウントを特定の状態に維持することが困難なので、インスタンスを計数する先に用いた技術は適さない。代わりに、リソースマネジャは、目標状態で過ごす時間に基づき、決定する必要がある。所与のリソースマネジャに割り当てられた最初のコンピュータが新しい状態に入るとき（グローバルバリアのインスタンスに到達する又はそこから去る）、該リソースマネジャは、その事実を全ての他のリソースマネジャにブロードキャストする。これは、グローバル開始時間を生成するために使用できる。メッセージトラフィックは、その他の場合、規則的間隔で活動の連結報告を送信することにより低減される。
【００８５】
この分散型ピアツーピアリソースマネジャアーキテクチャの利点は、負荷の分散に起因する。各リソースマネジャは、負荷全体の割合を扱い、計算及びメッセージ処理負荷を低くし、したがって、リソースマネジャはより反応が良くなる。追加で、通信ネットワークの負荷は、全てのコンピュータへの及びプロセッサへの全てのコンピュータからのメッセージの集中がないので、低減される。
【００８６】
リソースマネジャに割り当てられるコンピュータの割合は、多くの方法で決定できる。１つの方法は、コンピュータをリソースマネジャに均等に分散して、各リソースマネジャが同数のコンピュータを扱うようにすることである。また、メッセージング負荷に従ってリソースマネジャにコンピュータを分散して、平均して各リソースマネジャが等しい数のメッセージを処理するようにすることも可能である。
【００８７】
以上を纏めると、本開示の実施形態は、実行中にエネルギ節約の非常に短期間の機会を利用するために、アプリケーションを積極的に管理する技術を提供する。分散型コンピュータシステムでは、リソースマネジャ２００は、アプリケーションを実行するために複数のコンピュータ１０１を管理するために設けられる。各コンピュータは、高電力構成及び１又は複数の低電力構成を含む複数の電力構成のうちの１つで動作可能である。リソースマネジャ２００は、分散型コンピュータシステムの各コンピュータ内にあるリソ―スマネジャプロキシ２０１とメッセージを交換する。アプリケーションは、エネルギ使用に影響を与えるコードセクションに入ること及び出ることをリソースマネジャプロキシに報告するために、注釈を付けられる（並列処理を公開するような他の目的のコード注釈は、標準的技法であるが、エネルギ効率への適用は新規である）。リソースマネジャプロキシは、これらの報告をリソースマネジャに渡す。
【００８８】
リソースマネジャプロキシからのアプリケーションの実行状態変化の通知に応答して、リソースマネジャは、リソースマネジャプロキシのコンピュータ又はアプリケーションを実行中のコンピュータの集合（場合によっては全てのコンピュータを含む）に適用可能な電力構成を決定する。リソースマネジャ２００は、リソースマネジャプロキシ２０１に決定した電力構成を通知する。次に、リソースマネジャプロキシ２０１は、変更を実施するか否かを決定する。これは、複数のコンピュータを占有するアプリケーションの全体的状態を考慮してＨＰＣクラスタ内の個々のコンピュータの電力構成のきめ細かい応答型制御を可能にすることにより、特に排他的ではなく高性能コンピューティングシステムで使用中のエネルギ量を低減する。
【００８９】
リソースマネジャによりコンピュータへ送信される構成は、古くなってしまう可能性がある（迅速な応答及び後に誤りを訂正することに重点を置く）。リソースマネジャは、リソースマネジャプロキシからのメッセージに応答して推奨を送信するのに加えて、構成を先制（pre−emptively）ブロードキャストできる。リソースマネジャは、分散型形式であっても良い。
【００９０】
本発明の範囲内で種々の変更が可能である。
【００９１】
全てのコンピュータがグローバルバリアに入るグローバル待機の例について詳細に記載したが、本開示は、分散型コンピュータシステム内のコンピュータの部分集合のみを巻き込むローカルバリアにも適用できる。本開示は、グローバル又はローカルバリアを出る、コードの通信（ＩＯ）セクションに入る又は出る、コードの計算セクションに入る又は出るような、リソース要求に影響を与えるプログラムの実行中の他の状態変化にも適用できる。
【００９２】
別の例は、アプリケーションを実行中のノードに渡る実行速度を規則化することである。リソースマネジャは、プロキシからの報告を用いて、（計算フェーズの終了の報告のタイミングから、又はローカル大気中に他のモードを待つのに過ごした自身の平均時間から）どのノードが他のノードより速く実行するかを決定できる。
【００９３】
代替で、低速ノードと高速ノードとの比に依存して、低速ノードは、より高い電力／実行レートモードに置かれ、全体の計算が高速化し、システム全体が少ないエネルギを使用するようにできる。
【００９４】
全てのノードが全ての他のノードにデータを送信する大規模通信ステップ又は全てのノードがディスクにデータを書き込むフェーズのような、グローバル待機と同じ方法で利用できるプログラム状態の他のバルク変化が存在する。
【００９５】
以上では、コンピュータの複数の電力構成を参照した。多くのこのような構成が存在し得るが、最小では、２個のみ、つまり計算のための通常電力構成及び低電力構成が必要である。
【００９６】
以上では、リソースマネジャプロキシのみが、リソースマネジャからの指示の下で、コンピュータの電力構成を変更できた。しかしながら、リソースマネジャプロキシと連携して、例えば高電力モードに切り替えるためにローカルな独立性を許容し、一方で低電力モードへの切り替えるためのリソースマネジャによる決定を強制する方針により、コンピュータのローカルな電力管理システムを動作することが可能である。
【００９７】
本願明細書で言及した方法のステップは、定められた順序と異なる順序で実行されて、依然として好適な結果を生成しても良い。
【００９８】
リソースマネジャは、ソフトウェア、ハードウェア、ミドルウェア、ＡＳＩＣ（application  specific  integrated  circuit）又は任意の他の形式で実施されても良い。リソースマネジャプロキシは、通常、ソフトウェアで実施される。
本開示は、特定のアプリケーションのための最も効率的なハードウェア構成の発見及び実施を可能にし、アプリケ―ションの実行中に低電力消費による不変の性能を達成し、それにより、実行時間を長引かせる必要を有しないで、高性能コンピューティングにおいてエネルギ消費を低減する。
【符号の説明】
【００９９】
１０１  コンピュータ
２００  リソースマネジャ
２０１  リソースマネジャプロキシ
２０４  プログラム
２０４  ローカルオペレーティングシステム
【図１】
2016012347.tif 000004
【図２】
2016012347.tif 000005
【図３】
2016012347.tif 000006
【図４】
2016012347.tif 000007
【図５】
2016012347.tif 000008
【図６】
2016012347.tif 000009
【図７】
2016012347.tif 000010
【図８】
2016012347.tif 000011
【図９】
2016012347.tif 000012
【手続補正書】
【提出日】平成27年7月13日(2015.7.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
高性能コンピュータシステムで単一モノリシックアプリケーションを実行する方法であって、前記コンピュータシステムは、リソースマネジャと、前記アプリケーションを実行するために一緒に結合され各々複数の電力構成のうちの１つで動作可能な複数のコンピュータとを有し、前記方法は、
前記アプリケーションの個々の部分を前記コンピュータの各々に割り当てるステップであって、各部分は、数値計算状態、データ転送状態、及び他のコンピュータとの調整のための待機状態を含む異なるアプリケーション状態に対応するコードセクションを有する、ステップと、
前記高性能コンピュータシステムの各コンピュータの中にリソースマネジャプロキシを設けるステップと、
前記リソースマネジャプロキシが、前記リソースマネジャに、前記コンピュータの中のアプリケーション状態の変化を通知するステップと、
前記リソースマネジャが、前記通知するステップに応答して前記アプリケーションの全体状態を評価し、前記全体状態に基づき前記高性能コンピュータシステムの個々のコンピュータのための電力構成を決定するステップと、
前記リソースマネジャが、前記の決定した電力構成を、前記コンピュータの前記リソースマネジャプロキシに知らせるステップと、
前記リソースマネジャプロキシが、前記知らせるステップに基づき、前記コンピュータの電力構成の変化を生じさせるステップと、
を有する方法。
【請求項２】
前記通知するステップは、前記リソースマネジャプロキシが、前記コンピュータに割り当てられた前記アプリケーションの前記部分の前記コードセクションの中の注釈から生成され前記アプリケーション状態を示すメッセージを識別するステップを更に有する、請求項１に記載の方法。
【請求項３】
前記リソースマネジャプロキシが、前記コンピュータの既存の電力構成を考慮することにより、前記コンピュータの前記電力構成を変更すべきか否かを決定するステップ、を更に有する請求項１又は２に記載の方法。
【請求項４】
前記リソースマネジャプロキシが、前記コンピュータの電力構成の変化を前記リソースマネジャに確認するステップ、を更に有する請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
前記電力構成は、少なくとも１つの高電力及び少なくとも１つの低電力構成を有し、前記決定するステップは、前記リソースマネジャが複数の前記コンピュータの中の前記アプリケーション状態が待機状態に入ったことを識別し、該コンピュータのために前記低電力構成を決定するステップ、を更に有する、請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記待機状態は、前記アプリケーションの前記部分が割り当てられた全ての前記コンピュータに影響を与えるグローバル待機である、請求項５に記載の方法。
【請求項７】
前記リソースマネジャが、前記コンピュータのうちのどれの中で前記アプリケーション状態が前記待機状態に入ったかを監視するステップと、
前記リソースマネジャが、前記監視するステップに基づき、コンピュータを低電力から高電力構成に転換すべき遷移時間を決定するステップと、
前記リソースマネジャが、前記遷移時間の前に、通知元のリソースマネジャプロキシに前記低電力構成を知らせるステップと、前記遷移時間の後に、前記アプリケーション状態が前記待機状態に入った各コンピュータの前記リソースマネジャプロキシに、前記高電力構成を知らせるステップと、
を更に有する請求項５又は６に記載の方法。
【請求項８】
前記決定するステップ及び知らせるステップにおいて、前記リソースマネジャは、先ず、少なくとも１つのコンピュータのための電力構成の前の推奨を決定し及び知らせ、次に、前記推奨を更新し及び前記リソースマネジャプロキシに前記更新した電力構成を知らせる、請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
前記リソースマネジャにより決定された前記電力構成は、全ての前記コンピュータに適用され、前記通知するステップは、全ての前記リソースマネジャプロキシに前記電力構成をブロードキャストするステップを有する、請求項１乃至４のいずれか一項に記載の方法。
【請求項１０】
前記リソースマネジャは、前記通知するステップの前に、電力構成を全ての前記リソースマネジャプロキシに先制（pre−emptively）ブロードキャストするステップ、を更に有する請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
前記リソースマネジャは、前記アプリケーションの部分が割り当てられた前記コンピュータと別個の少なくとも１つのコンピュータにより提供される、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
前記リソースマネジャは、それぞれ前記アプリケーションの部分が割り当てられた前記コンピュータの個々の部分集合に責任のある及び通信フレームワークにより接続される複数のリソースマネジャを有する分散型形式である、請求項１乃至１１のいずれか一項に記載の方法。
【請求項１３】
アプリケーションを実行するために高性能コンピュータシステムの中の複数のコンピュータを管理するリソースマネジャであって、前記コンピュータは単一のモノリシックアプリケーションを実行するために一緒に結合され、前記コンピュータの各々は、数値計算状態、データ転送状態、及び他のコンピュータとの調整のための待機状態を含む異なるアプリケーション状態に対応するコードセクションを有する前記アプリケーションの個々の部分を前記コンピュータの各々に割り当てられ、前記コンピュータの各々は、複数の電力構成のうちの１つで動作可能であり、前記リソースマネジャは、
前記高性能コンピュータシステムの各コンピュータの中のリソースマネジャプロキシとメッセージを交換する通信モジュールと、
リソースマネジャプロキシからの通知に応答して、前記コンピュータの中のアプリケーション状態の変化を決定し、前記アプリケーションの全体状態を評価する状態モニタと、
前記状態モニタによる前記評価に応答して、前記高性能コンピュータシステムの個々コンピュータのための電力状態を決定する電力構成部と、
を有し、
前記通信モジュールは、前記決定された電力構成を、前記コンピュータの前記リソースマネジャプロキシに知らせるよう配置される、リソースマネジャ。
【請求項１４】
コンピュータプログラムであって、高性能コンピュータシステムにより実行されると請求項１乃至１２のいずれか一項に記載の方法を実行するコンピュータ可読コードを有する、コンピュータプログラム。
【請求項１５】
高性能コンピューティングシステムであって、
請求項１３に記載のリソースマネジャと、
単一のモノリシックアプリケーションを実行するために一緒に結合された複数のコンピュータであって、前記コンピュータの各々は、数値計算状態、データ転送状態、及び待機状態を含む異なるアプリケーション状態に対応するコードセクションを有する前記アプリケーションの個々の部分を割り当てられ、前記コンピュータの各々は、複数の電力構成のうちの１つで動作可能である、複数のコンピュータと、
を有し、
前記コンピュータの各々は、リソースマネジャを備えられ、前記リソースマネジャは、
前記コンピュータに割り当てられた前記コードセクションに含まれる、アプリケーション状態の変化の指示を読み出すコードリーダと、
前記指示を前記リソースマネジャへ転送し、前記リソースマネジャから、前記コンピュータのための電力構成推奨を受信する通信モジュールと、
前記リソースマネジャからの前記推奨に基づき前記コンピュータの電力構成の変化を生じさせる電力管理部と、
を有する、高性能コンピューティングシステム。