(57)【特許請求の範囲】
【請求項１】
コンピュータシステムにおいて複数のノードによりアプリケーションを実行する方法であって、前記アプリケーションは少なくとも１つの反復フェーズを有し、前記ノードは複数の電力状態を有し、当該方法は、
ａ）デフォルトの電力状態にあるノードとともに前記アプリケーションの実行を開始するステップと、
ｂ）ノードの待機時間を監視し、実行が反復フェーズに到達したことを確認し、ノードの平均的な待機時間を判定するステップと、
ｃ）ノード群のうちの部分集合について、電力状態を変更するステップと、
ｄ）待機時間を監視し続け、前記デフォルトの電力状態で決定された待機時間と比較し、前記反復フェーズが入出力バウンドであるか否かを確認するステップと、
ｅ）前記反復フェーズが入出力バウンドである場合に、エネルギ消費を減らすように全てのノードの電力状態を変更し、実行を継続するステップと、
を有する方法。
【請求項２】
複数の電力状態の各々について、ｃ）及びｄ）のステップが反復され、各々の反復はノード群のうちの可能な異なる部分集合を利用する、請求項１に記載の方法。
【請求項３】
前記複数の電力状態は、ノードについての最高の電力状態及び最低の電力状態を少なくとも含む、請求項２に記載の方法。
【請求項４】
前記複数の電力状態は、ノードについての複数の可能な電力状態の各々である、請求項２に記載の方法。  
【請求項５】
前記部分集合のサイズは、異なる数のノードの電力状態を変えた場合におけるノードの平均的な待機時間に対する影響を観測することにより決定される、請求項１〜４のうちの何れか１項に記載の方法。
【請求項６】
前記待機時間は、前記アプリケーションのグローバル境界までの待機時間である、請求項１〜５のうちの何れか１項に記載の方法。
【請求項７】
ｅ）のステップが、ノードの電力状態を、待機時間に対して検出可能な変化をもたらさない電力状態に変えることを含む、請求項１〜６のうち何れか１項に記載の方法。
【請求項８】
ｅ）のステップが、変更後の電力状態を利用して前記アプリケーションを最後まで実行し続けることを含む、請求項１〜７のうち何れか１項に記載の方法。
【請求項９】
前記アプリケーションの実行についての少なくとも１つの別の反復フェーズについて、ｂ）ないしｅ）のステップを反復することを更に含む、請求項１〜７のうち何れか１項に記載の方法。
【請求項１０】
少なくとも１つの反復フェーズを有するアプリケーションを実行するためにコンピュータシステムのノードを管理するリソースマネジャであって、前記ノードは複数の電力状態を有し、前記リソースマネジャは、
前記アプリケーションの個々の部分にノードを割り当てるスケジューリングモジュールと、
前記複数のノード各々の電力状態を設定するように形成される電力設定モジュールと、
ノードの待機時間を監視し、平均的な待機時間を計算する待機時間監視モジュールと、
前記平均的な待機時間に基づいて、前記アプリケーションがＩＯバウンドであるか否かを判定するアプリケーションタイプ判定モジュールとを有し、
前記電力設定モジュールは、デフォルトの電力状態のノードとともに前記アプリケーションの動作を開始するように形成され、
前記待機時間監視モジュールは、動作が反復フェーズに到達したことを確認するためにノードの待機時間を監視し、前記ノードの平均的な待機時間を計算するように形成され、
前記電力設定モジュールは、動作が反復フェーズに到達したことに応じて、ノード群のうちの部分集合についての電力状態を変更し、
前記待機時間監視モジュールは、待機時間を監視し続け、変更された電力状態における平均的な待機時間を計算するように形成され、
前記アプリケーションタイプ判定モジュールは、前記変更された電力状態における平均的な待機時間と前記デフォルトの電力状態において判定された平均的な待機時間とを比較することにより、前記アプリケーションがＩＯバウンドであるか否かを判定するように形成され、
前記電力設定モジュールは、前記アプリケーションがＩＯバウンドであることに応じて、エネルギ消費を減らすように前記ノード群の全ての電力状態を変更する、リソースマネジャ。
【請求項１１】
前記アプリケーションは通信ライブラリによる支援とともに動作し、前記待機時間監視モジュールは、前記通信ライブラリから通知を受けることにより、ノードの待機時間を監視する、請求項１０に記載のリソースマネジャ。
【請求項１２】
相互に接続される複数のノードと、
請求項１０又は１１に記載のリソースマネジャと、
を有するハイパフォーマンスコンピュータシステム。
【請求項１３】
コンピュータのプロセッサにより実行されることにより、請求項１０又は１１に記載のリソースマネジャをもたらすソフトウェア。
【発明の詳細な説明】
【技術分野】
【０００１】
本願はハイパフォーマンスコンピュータ(high-performance  computer：HPC)システムのようなコンピュータシステムにおけるエネルギを意識したリソース管理等に関連する。
【背景技術】
【０００２】
実施形態はコンピュータシステムにおけるエネルギの消費に対処し、例えば、大規模コンピュータクラスタ(特に、ハイパフォーマンスコンピュータシステム(HPC)システム)上で動作するプログラムにより消費されるエネルギ量の問題に対処する。HPCクラスタは、多数の準独立なコンピュータ群(ノード群)から形成され、そのノード群は互いに結合されて1つの大規模なモノリシックアプリケーションを実行するために使用されてよい。アプリケーション(又はジョブ)は複数のコンピュータタスクに分割され；そして、それらのタスクがリソースマネジャによりノードに割り当てられる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願公開第20120216205号明細書
【特許文献２】米国特許出願公開第20090100437号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
リソースマネジャはHPCシステムの効率的な動作に対する責任を負い、ノードを含むリソース(及び他の何らかのリソース)が要求に対してサービスを提供することを保証する。一般に、優先サービス要求又はオーバーライドサービス要求(over-ride  service  requirement)は可能な限り高速にアプリケーションを完了させるが、ノードはハイエンドコンピュータでありかつ多くのエネルギを消費するので、重要度が上昇しつつある二次的な要求は、可能な限り少ないエネルギを使うことになる。コンピュータノードはエネルギを削減するために使用可能な様々な手段を有するが、通常、それらは演算パフォーマンスを犠牲にすることになる。
【０００５】
サーバのコアを形成するマイクロプロセッサの能力を向上させることは、エネルギ消費を増やすことになる。しかしながら、最近のマイクロコンピュータの設計(又は構造)は、最高のパフォーマンスが要求されない場合に、電力消費を削減する機能も備える。これは、電圧や周波数のスケーリング、又は、マイクロプロセッサの不使用部分をオフにすること等のような様々な技術により実現される。この機能は、オペレーティングシステムにより、リソースマネジャがクラスタの電力消費を削減できるようにリソースマネジャに利用可能になるが、この機能の利用は、クラスタ上で動作するアプリケーションのパフォーマンスを維持する要請に対してバランスをとる必要がある。
【０００６】
アプリケーションの全体的なパフォーマンスは、数々の要因又はファクタに依存する。演算パフォーマンスは多くのHPCアプリケーションで重要であり、これらは「計算バウンド(compute-bound)」又は「CPUバウンド」と呼ばれる。ある種のアプリケーションでは、メモリに対するデータの読み書き、或いは、ノード間のデータ通信のような他の要因が支配的であり：これらは「IO(入出力)バウンド」と呼ばれる。計算バウンドのアプリケーションのパフォーマンスは、ノードをエネルギ節約状態に置くと不利な影響を受けるが、IOバウンドのアプリケーションは、パフォーマンスに対する最小限の影響でそれらのノードをエネルギ節約状態にすることが可能である。リソースマネジャは、制御下のアプリケーションが計算バウンドであるか或いはIOバウンドであるかについての事前の情報を有しないので、パフォーマンスが劣化しないことを保証しながら、何らかのアプリケーションをエネルギ節約モードに置くことはできない。アプリケーションは各自の実行の際に様々な段階(又はフェーズ)を経るかもしれないが、これらのフェーズは様々な特徴を有する可能性があり、或るフェーズは計算バウンドであるがそれ以降はIOバウンドであるかもしれない。
【０００７】
多くのリソースマネジャは、ジョブをエネルギ節約モードに設定する機能を、HPCクラスのユーザに提示する。しかしながら、ユーザはエネルギを節約するように動機付けられていないかもしれないので(例えば、使用される他のリソースに加えて使用されるエネルギについて課金されているような場合でない限り)、この機能は常には十分に活用されない。また、ユーザは各自のアプリケーションの実行パフォーマンスを減らしたくないかもしれない(すなわち、彼らはソリューションに対する時間を最小化したいかもしれない)。従って、リソースマネジャにとって、パフォーマンスが影響を受けないことを保証できる場合においてエネルギ節約モードを自動的に適用することが好ましい。
【０００８】
そのような「エネルギを意識した(energy-aware)」リソースマネジャに関する技術は、US20120216205及びUS20090100437により示されている。これらは、コンピュータモデル及び以前にサブミットされたジョブのパフォーマンス特徴についてのデータベースを備えるリソースマネジャを説明しており、コンピュータモデルは、所与のパフォーマンス特徴に関し、或るジョブにおいて或るクラスタをエネルギ節約モードに置いた影響についてのコンピュータモデルである。リソースマネジャが以前にサブミットされたジョブと同じジョブを特定できる場合、記録されている特徴を利用して、パフォーマンスに影響を与えない最適なエネルギコンフィギュレーションを計算する。
【０００９】
これらの文献が対処してない問題は、サブミットし直されるジョブは以前のサブミットと同じパフォーマンス特徴を有する、ということを保証しないことである。リソースマネジャは、エネルギ効率に関してアプリケーションの最適な設定が何であるかを外部から知ることはできない。たとえ、同じアプリケーションが以前にサブミットされていたとしても、リソースマネジャにとって不可視の「変化」であってエネルギ使用状態に影響を及ぼす「変化」が生じているかもしれない。これらの「変化」は、コードに対する修正、異なるソリューションアルゴリズムの選択、コンピュータノードに対する負荷のマッピングの仕方の相違、問題のサイズ(又は対象のサイズ)の相違、又は、イネーブルされるオプションの相違等を含む。これらの変化は、全て、アプリケーションのエネルギ利用状態や、コンフィギュレーションと計算パフォーマンスとの間の相互作用等に影響を及ぼす可能性があるので、アプリケーションに関する過去の経験は、現在の初期ファイルとともに現在のアプリケーションを実行することに対する信頼できる案内役にはならない。
【００１０】
従って、以前にサブミットしたジョブを当てにせずにエネルギを意識した動作を提供することが望まれる。
【課題を解決するための手段】
【００１１】
一実施形態による方法は、
コンピュータシステムにおいて複数のノードによりアプリケーションを実行する方法であって、前記アプリケーションは少なくとも１つの反復フェーズを有し、前記ノードは複数の電力状態を有し、当該方法は、
ａ）デフォルトの電力状態にあるノードとともに前記アプリケーションの実行を開始するステップと、
ｂ）ノードの待機時間を監視し、実行が反復フェーズに到達したことを確認し、ノードの平均的な待機時間を判定するステップと、
ｃ）ノード群のうちの部分集合について、電力状態を変更するステップと、
ｄ）待機時間を監視し続け、前記デフォルトの電力状態で決定された待機時間と比較し、前記反復フェーズが入出力バウンドであるか否かを確認するステップと、
ｅ）前記反復フェーズが入出力バウンドである場合に、エネルギ消費を減らすように全てのノードの電力状態を変更し、実行を継続するステップと、
を有する方法である。
【図面の簡単な説明】
【００１２】
【図１】複数のノード間で分配されるアプリケーションの実行タイムラインを示す図。
【図２】同種ノードに関するアプリケーションの実行タイムラインを示す図。
【図３】異種ノードに関するアプリケーションの実行タイムラインを示す図。
【図４】図3における何れかのノードに変化を与えた場合の影響を示す図。
【図５】全てのノードを低速化することによる実行タイムラインへの影響を示す図。
【図６】アプリケーションに不均一性を導入する影響についてのシミュレーションによるグラフを示す図。
【図７】一実施形態によるハイパフォーマンスコンピュータシステムについてのブロック図。
【図８】リソースマネジャの機能モジュールについてのブロック図。
【図９】一実施形態による方法で実行されるステップのフローチャートを示す図。
【図１０】一実施形態による修正された方法で実行されるステップのフローチャートを示す図。
【発明を実施するための形態】
【００１３】
＜実施形態の概要＞
一実施形態による方法は、コンピュータシステムにおいて複数のノードによりアプリケーションを実行する方法であって、前記アプリケーションは少なくとも１つの反復フェーズを有し、前記ノードは複数の電力状態を有し、当該方法は、
ａ）デフォルトの電力状態にあるノードとともに前記アプリケーションの実行を開始するステップと、
ｂ）ノードの待機時間を監視し、実行が反復フェーズに到達したことを確認し、ノードの平均的な待機時間を判定するステップと、
ｃ）ノード群のうちの部分集合について、電力状態を変更するステップと、
ｄ）待機時間を監視し続け、前記デフォルトの電力状態で決定された待機時間と比較し、前記反復フェーズが入出力バウンドであるか否かを確認するステップと、
ｅ）前記反復フェーズが入出力バウンドである場合に、エネルギ消費を減らすように全てのノードの電力状態を変更し、実行を継続するステップと、
を有する方法である。
【００１４】
そのような方法は本願で説明されるようなリソースマネジャを利用することにより適切に実行される。そのようなリソースマネジャは、例えば実行中にノードによりアクセスされる通信ライブラリから通知を受けることにより、各々のノードにおけるアプリケーションの進捗を監視することが可能である。
【００１５】
ａ）のステップは不均一な実行状態で動作を開始することに関連してもよい。しかしながらシステムによっては本来的に不均一であってもよい。
【００１６】
複数の電力状態の各々について、ｃ）及びｄ）のステップが反復され、各々の反復はノード群のうちの可能な異なる部分集合を利用してもよい。
【００１７】
この場合において、前記複数の電力状態は、ノードについての最高の電力状態及び最低の電力状態を少なくとも含んでもよいし；より一般的には、前記複数の電力状態は、ノードについての複数の可能な電力状態の各々を含んでもよく、例えば、クロック周波数や電源電圧などの様々な値を各ノードについて設定することにより決定されてもよい。
【００１８】
上記の任意の方法において、好ましくは、前記部分集合のサイズは、異なる数のノードの電力状態を変えた場合におけるノードの平均的な待機時間に対する影響を観測することにより決定されてもよい。
【００１９】
好ましくは、前記待機時間は、前記アプリケーションのグローバル境界までの待機時間であってもよい。そのような「グローバル待機」は、例えば、アプリケーションの実行中に参照される通信ライブラリにより検出されることが可能である。
【００２０】
上記の任意の方法において、好ましくは、ｅ）のステップは、ノードの電力状態を、待機時間に対して検出可能な変化をもたらさない電力状態に変えることを含んでもよい。
【００２１】
一実施形態において、ｅ）のステップは、変更後の電力状態を利用して前記アプリケーションを最後まで実行し続けることを含んでもよい。代替的に、前記アプリケーションの実行についての少なくとも１つの別の反復フェーズについて、ｂ）ないしｅ）のステップが反復されてもよい。
【００２２】
別の実施形態によれば、少なくとも１つの反復フェーズを有するアプリケーションを実行するためにコンピュータシステムのノードを管理するリソースマネジャが提供され、前記ノードは複数の電力状態を有し、前記リソースマネジャは、
前記アプリケーションの個々の部分にノードを割り当てるスケジューリングモジュールと、
前記複数のノード各々の電力状態を設定するように形成される電力設定モジュールと、
ノードの待機時間を監視し、平均的な待機時間を計算する待機時間監視モジュールと、
前記平均的な待機時間に基づいて、前記アプリケーションがＩＯバウンドであるか否かを判定するアプリケーションタイプ判定モジュールとを有し、
前記電力設定モジュールは、デフォルトの電力状態のノードとともに前記アプリケーションの動作を開始するように形成され、
前記待機時間監視モジュールは、動作が反復フェーズに到達したことを確認するためにノードの待機時間を監視し、前記ノードの平均的な待機時間を計算するように形成され、
前記電力設定モジュールは、動作が反復フェーズに到達したことに応じて、ノード群のうちの部分集合についての電力状態を変更し、
前記待機時間監視モジュールは、待機時間を監視し続け、変更された電力状態における平均的な待機時間を計算するように形成され、
前記アプリケーションタイプ判定モジュールは、前記変更された電力状態における平均的な待機時間と前記デフォルト状態の電力状態において判定された平均的な待機時間とを比較することにより、前記アプリケーションがＩＯバウンドであるか否かを判定するように形成され、
前記電力設定モジュールは、前記アプリケーションがＩＯバウンドであることに応じて、エネルギ消費を減らすように前記ノード群の全ての電力状態を変更する、リソースマネジャである。
【００２３】
好ましくは、前記アプリケーションは通信ライブラリによる支援とともに動作し、前記待機時間監視モジュールは、前記通信ライブラリから通知を受けることにより、ノードの待機時間を監視してもよい。
【００２４】
更に別の実施形態は、クラスタを形成するように相互接続により共に結合されるノード又はサーバと、上記のリソースマネジャと、を有するハイパフォーマンスコンピュータシステムを提供する。
【００２５】
更に別の実施形態は上記のリソースマネジャを提供するためのソフトウェアに関連する。そのようなソフトウェアは、1つ以上の非一時的なコンピュータ読み取り可能な記録媒体に保存されてもよい。そのようなソフトウェアは実施形態による方法を装置の処理部に実行させる。
【００２６】
最近のハイパフォーマンスコンピュータ(HPC)システムのような大規模コンピュータシステムは、大量のエネルギを消費する。コスト及び社会的責任などの理由からエネルギを削減する強い要請がある。HPCクラスタのコンポーネントのノードは各自のエネルギ消費を減らす機能(又は能力)を有するが、全部ではないある種のアプリケーションのパフォーマンスの低下を犠牲にする。HPCクラスタリソースマネジャは、エネルギ節約モードで実行されてもパフォーマンスを落とさないアプリケーションを特定できるならば、パフォーマンスを維持しつつエネルギを節約することが可能である。
【００２７】
実施形態は、特定のアプリケーションのハードウェアについての最も効果的なコンフィギュレーションを発見できるようにし、そのコンフィギュレーションは、アプリケーションが動作する場合に、最低の電力消費とともに、変わらないパフォーマンスを達成する。
【００２８】
実施形態は、パフォーマンスに影響せずに、エネルギ節約モードでHPCクラスタにおけるコンピュータジョブの実行を可能にすることを目指す。これを行うには、クラスタにサブミットされるジョブの特徴の特定を要する。HPCジョブの特徴は、サブミッション毎に非常に様々であり、更に、1つのジョブの実行中に変化することもしばしばある。従って、サブミットされたジョブの過去の情報を利用することは当てにならず；全てのジョブの特徴は、サブミッション毎に個別的に及び理想的には実行中に確認される必要がある。
【００２９】
実施形態で採用される原理は、実行するアプリケーションにテスト(又は検査)を適用することにより、そのような情報を取得することである。検査は、非侵襲的であり(non-invasive)、実行結果を変えず、アプリケーションのランタイムに僅かな影響しか与えないべきである。これらは敏感に迅速かつ信頼性高く実行されるべきである。これらの特徴に関するテストは、実行中にパフォーマンスの特徴が徐々に進行するにつれてエネルギの利用の仕方が精密に調整可能になるように、実行中に反復的に適用可能である。
【００３０】
この目的のため、本願による実施形態は、アプリケーションの実行の際に、アプリケーションに割り当てられるノードのうちの一部分(全部ではない)についての実行速度に不均一性を意図的に導入する。文脈上適切であるならば「不均一性(heterogeneity)」は「異質性」、「異成分」等と言及されてもよい。例えば、データを送ることや、計算を全体的に同期させること等のように、HPCアプリケーションがノード間で制御を必要とする場合、これらの不均一性は、これらの制御ポイントで費やされる待ち時間を変化させる。この場合における「制御(coordination)」は文脈上適切であるならば「調整」、「協調」、「連携」、「統合」等と言及されてもよい。計算主体のアプリケーション(computation  intensive  application)はこれらの「変化」による影響を最も強く受け、IOバウンドアプリケーションはそれほど影響を受けない。このため、実施形態はアプリケーションのこれら2つのタイプを区別し、最良のエネルギコンフィギュレーションを設定できるようにする。
【００３１】
アプリケーションがCPUバウンドであるか或いはIOバウンドであるかを確認することで、アプリケーションに割り当てられるノードに対して最適な電力状態が適用可能になる。これはアプリケーションの実行の際に任意のポイントで適用可能であり、様々なエネルギの使い方及びパフォーマンス特徴とともにアプリケーションがフェーズを経由する場合に、最適な効率を維持するようにハードウェアコンフィギュレーションを調整できるようにする。
【００３２】
本明細書において、「ノード」、「サーバ」、「プロセッサ」、「マイクロプロセッサ」及び「CPU」のような用語は文脈上別意でない限り可換に使用されてよく、「プログラム」、「アプリケーション」及び「ジョブ」についても同様である。「ラン(run)」及び「実行」という用語は本願においては等価的である。同様に、「(HPC)システム」、「クラスタ」及び「サーバ群」のような用語も等価的である。
【００３３】
＜図面＞
詳細な説明では、一例に過ぎない添付図面が参照される。
【００３４】
図1は複数のノード間で分配されるアプリケーションの実行タイムラインを示す。
【００３５】
図2は同種ノード(homogeneous  nodes)に関するアプリケーションの実行タイムラインを示す。
【００３６】
図3は異種ノード(heterogeneous  nodes)に関するアプリケーションの実行タイムラインを示す。
【００３７】
図4は図3における何れかのノードに変化を与えた場合の影響を示す。
【００３８】
図5は全てのノードを低速化することによる実行タイムラインへの影響を示す。
【００３９】
図6はアプリケーションに不均一性を導入する影響についてのシミュレーションを示すグラフである。
【００４０】
図7は一実施形態によるハイパフォーマンスコンピュータシステムについてのブロック図である。
【００４１】
図8はリソースマネジャの機能モジュールについてのブロック図である。
【００４２】
図9は一実施形態による方法で実行されるステップのフローチャートである。
【００４３】
図10は一実施形態による修正された方法で実行されるステップのフローチャートである。
【００４４】
＜実施形態の詳細な概要＞
上述したように、実施形態は、タスクがリソースマネジャにより割り振られる大規模コンピュータシステム(特に、ハイパフォーマンスコンピュータ(HPC)システム)において動作するプログラムにより消費されるエネルギ量を減らす問題に対処する。
【００４５】
リソースマネジャの役割は、適切なサービス品質の測定値が達成されるようにノード間でタスクを割り振ることであり、例えば、あるグループのタスクが最短の時間で完了するように、或いは、特定のタスクが所定の時間までに終了するようにタスクを割り振る。リソースマネジャは、HPCシステムにおけるリソースの利用可能性についての知識を当てにする経験則(heuristics)及び洗練されたアルゴリズムを利用する。リソースは、プロセッサの時間、サーバーメモリ、ネットワーク帯域幅、或いは、ソフトウェアライセンスの利用可能性などを含むことが可能である。リソースマネジャはクラスタが可能な限り効率的に使用されることを保証し、効率の測定値の1つ(特に、大規模なHPCクラスタについての効率の測定値の一例)は、それらが使用するエネルギの量である。
【００４６】
リソースマネジャがアプリケーションの実行についての特徴を信頼性高く検出できる場合、電力消費状態を能動的に管理することにより、より多くのエネルギの節約を達成することが可能になる。この原理については図1ないし図6の図面を参照しながら詳細に説明される。
【００４７】
HPCシステムの上位概念的なアーキテクチャは、通信ネットワークにより結合される準独立的なノード(quasi-independent  nodes)の集まりである。この場合における「集まり(collection)」は「集団」、「グループ」、「群」等と言及されてもよい。HPCシステムで動作するアプリケーションは、ノードに分配(又は分散)され、各々の部分のアプリケーションは他の部分から可能な限り分離されるが、ノード間で何らかの通信が常に必要である。通信は、ノードが他のノードからメッセージの到着を待機するように、ノードが各自の実行を連携させる必要があるように導く。制御(又は誘導)の程度はアプリケーション及びアルゴリズムのタイプとともに異なるが、通常、アプリケーションの実行中に、ノードが他のノードによる計算の完了を待機する場面が何度も存在する。数々のこれらの待機を制御するには、グローバル通信(すなわち、そのアプリケーションに割り当てられた全てのノードにわたる通信)を必要とし、あるノードによる実行に関する如何なる遅延も、最も遅いノードが追いつくまで、アプリケーションの全体を待機させることになる。
【００４８】
図1は、4つのノードで動作する1つのプログラムの実行フェーズを、水平に帯状に伸びる長さ部分により表現される時間とともに示す。プログラムは、「実行」、「待機」、「実行」及び「待機」という4つのフェーズを有する。「待機」の依存性(又は従属性)はノード間の矢印により示される。ノードはA-Bのペア及びC-Dのペアの中でしか通信しないので、第1の待機フェーズは、ローカル協調範囲(local  coordination  barrier)をモデル化する。第2の待機フェーズはグローバル協調範囲(global  coordination  barrier)をモデル化し；完了前に全てのノードが他の全てのノードを待機する。これは図1において「グローバル待機(Global  Wait)」のようなラベルで示され、(一般的には)全てのノードがここで待機しなければならないことを示す。
【００４９】
図2は、図1のプログラムに関し、各ノードが同じ実行時間で均一的(homogeneous)である場合の実行タイムラインを示す(例えば、同じ演算能力を有し、同等な部分のアプリケーションがそれらについて指定される)。全てのノードは待機フェーズで同じ時間に到達するので、待機に費やされる時間はなく、次のフェーズの実行を直ちに開始することができる。
【００５０】
図3は異種ノードに関する実行タイムラインを示し、異なるノードに関する実行時間は異なる。あるノードは他のノードより早く実行するので、待機する期間が存在するが(図3で影が付された部分)、クリティカルパス(critical  path)となる最も遅いノード(B)では待機時間がない。ノードAは第1の実行フェーズの後にパートナーのノードBのみを待機する。同様に、ノードCもノードDを待機する。第2の実行フェーズの後に、グローバル待機は、ノードBの処理が完了するまで全てのノードを待機させる。
【００５１】
図4は、同じプログラムに関し、ノードCの実行速度を変更した場合のタイムラインを示し、例えば、ノードCはCPUバウンドプログラムのクロック周波数を減らすことによる影響を受ける。ノードCについてのこの低速化は、ノードCによる電力消費を減らす(以下、ノードCの「変分」、「変動」、「変化」又は「ゆらぎ」(perturbation)のように言及され、ノードCと他のノードとの間の「不均一性」をもたらす)。その一方で実行フェーズは長くかかるようになり、ノードC及びDにおける待機フェーズの分布を変える(ノードA及びBについて変化はなく、ノードBは依然として最も遅いノードのままである)。グローバル待機フェーズで費やされる時間も変わる。しかしながら、1つのノードを低速化させたとしても、全体的な実行時間は変わらない。
【００５２】
図4に関する変化とは異なり、図5は、全てのノードを同じ量だけ低速化させた影響を示す。費やされた総時間は変化しているが、各ノードの各フェーズで費やされる時間の分布は、割合の観点からは、同じである。明らかに、図4の状況の方が好ましい；実行時間を影響させずに少ないエネルギ消費量となるからである。
【００５３】
待機しているノードは、リソースを使っておらず(又はアイドル状態にし)、全体的な演算パフォーマンスを低下させるので、通常、可能な限り減らされる。しかしながら、それでも様々な理由から待機ノードが登場する。これらの理由のうちのいくつかは、アプリケーションの実行の間中考慮され、これらの固有の理由は、ノードに配分される負荷の不均一性(imbalance)や、異種ノード又は障害ノードによるパフォーマンスの相違などを含む。他のプロセッサからの干渉のような一時的な理由(例えば、ジッタ(jitter))も存在し、これらはパフォーマンスに対して短時間の影響を及ぼす。これは、ノードが協調範囲において他のノードを或る期間にわたって待機することを常に体験することを意味する。
【００５４】
図4の例のように、個別的なノードを変動させることにより、ノード間に不均一性をもたらすことが可能である。HPCシステムは独立したコンピュータの形式のノードにより形成されるので、直接的な方法は、ノードの設定を個別的に変更することであり、例えば、コンピュータのクロック速度が落とされる。図6に示されるように、ノード実行時間に不均一性を導入することは、アプリケーションの実行時間に大きな影響をもたらすことが可能である。
【００５５】
図6において、x軸は、計算速度(実行スピード)が変更されるノードの割合を表す。0.1という割合は10％のノードに対応し、0.2は20％に対応し、等々である。従って、グラフの左端は、全てのノードが同じ実行時間を有する完全に均一(homogeneity)である場合を示す。同様に、グラフの右端も均一であることを示す(100％のノードが同様に変更される)。(右端の)その場合において、y軸に示されるようにノードについての小さいけれども有限の平均グローバル待機時間が存在する。
【００５６】
このシミュレーションでは、ある割合のノードが、5％のランダムバックグランドジッタ(random  background  jitter)により他のノードよりも10％遅く動作するように変化させられる(すなわち、適用される変動量に不確実性がある)。図6から分かるように、全てのノードが同じレートで動作する場合(図6のx軸の両端付近)、グローバル協調範囲(global  barrier)における平均待機時間は、小さいけれども類似している。僅かな量の不均一性が存在する場合(数個のノードが大多数のノードよりも遅く動作する場合)、平均グローバル待機時間は著しく増加する。最も大きな影響は、わずか数％のノードしか変化してない場合に生じることが観測される。これは、特定のHPCシステムには依存しない一般的な結果である。
【００５７】
考察されるノードの実行速度を減少させる限り、ノードに適用される変動の性質は重要ではないことに、留意すべきである。変動に関する可能性のある仕組みは、ノードのクロック周波数の低下、ノードの動作電圧の低下、ノードの演算機能の部分的なシャットダウン、他のアプリケーションとのノードのリソースの共有(通常、アプリケーションは、ノードに排他的にアクセスするように仮定されることが可能である)等を含む。好ましくは、変動はノードのI/Oパフォーマンスに影響しないべきである。
【００５８】
上記の影響に関し、本願の実施形態は以下の考察事項に基づく：
（ｉ）  アプリケーションは多数のノードに分散され、ノードは個別的に(少なくとも電力設定に関して)制御可能である。
【００５９】
（ｉｉ）  ノードはアプリケーションのうちの各自の部分を独立に実行するが、ささいでない(又は重要な)全てのアプリケーションはノード間の通信を必要とし、従って、相互の協調ポイント(協調範囲又は協調境界(a  barrier))に達するパートナーのノードに進捗が依存するポイントを有する。
【００６０】
（ｉｉｉ）  アプリケーションは典型的には複数の初期化及び反復フェーズにより形成され、各々の初期化フェーズの後に反復フェーズが続く。初期化フェーズは比較的短く；おそらくは、実行時間全体のうちの5％未満である。
【００６１】
（ｉｖ）  計算の進行速度は、例えば、ノードにおける負荷の不均一性、ノードで実行する他のコードによる干渉、及び、ノードの能力(性能又は機能)の相違などに起因して、ノード毎に異なる可能性がある。これは或るノードが他のノードを協調境界まで待機する結果となる。
【００６２】
（ｖ）  グローバル境界で待機するのに費やす平均時間は、少数のノードの実行速度の不均一性により、大きく影響を受ける。
【００６３】
（ｖｉ）  アプリケーションがCPUバウンドである場合、ノードのハードウェアにおけるエネルギ節約機能は、計算の進行速度に影響を及ぼす。この影響は、IOバウンドのコードの場合には顕著に小さい。
【００６４】
これらの事項は次のことを意味する：僅かな数のノードのエネルギ節約機能の設定を変更し、グローバル境界まで平均待ち時間を監視することにより、CPUバウンドのアプリケーションとIOバウンドのアプリケーションとを区別することが可能である。変化させていないシステム(均一システム)から顕著に変化するならば、そのアプリケーションはCPUバウンドであり、それほど変化しないならば、そのアプリケーションはIOバウンドである。
【００６５】
いったんこの区別がなされると、IOバウンドアプリケーションは、動作するノードを、削減される電力消費モードに置いてもらうことが可能になり、パフォーマンスを低下させずにエネルギを節約できる。現在のジョブのうちの残りの実行に関し、すなわち(おそらくは、ランタイム全体の80％に関し)、アプリケーションは、全てのノードに最適な設定を適用しながら実行されることが可能である。これは、従来技術のように以前にサブミットされたジョブの履歴を参照する必要なしに、顕著にエネルギを節約できるようにする。
【００６６】
これらの考察とともに、提案されるプロセスは次のように概説することができる：
（ａ）ジョブの初期実行の際に、リソースマネジャはジョブに対するリソースを通常通りに計画して割り当てる。リソースの割当計画はスケジューリング等と言及されてもよい。
【００６７】
（ｂ）ジョブは、安定的な実行ポイントに達するまで、デフォルトのエネルギコンフィギュレーションを用いて実行され、すなわち、初期段階を完了して反復部分(iteration  part)に入る。「エネルギコンフィギュレーション」は「エネルギ設定」、「エネルギ状態」等と言及されてもよい。アプリケーションは監視され、グローバル境界までの平均待ち時間が確認される(平均化は、アプリケーションに割り当てられたノード群について実行され、おそらくは境界に到達する複数のインスタンスについて実行される)。
【００６８】
（ｃ）リソースマネジャは、アプリケーションに対して割り当てられたノードのうちのいくつかについてのエネルギコンフィギュレーションを新たな値に修正し、例えば、パフォーマンスと引き替えに節電化を図るような新たな値に修正する。エネルギコンフィギュレーションの修正(又は変更)は、上述したように、ノードのクロック速度、動作電圧、アクティブにされる演算機能、或いは、アプリケーションに対する排他性を減らすことのうちの何れか1つ以上により達成することができる。以下、このエネルギコンフィギュレーションは「電力状態」のように言及されてもよい。
【００６９】
（ｄ）リソースマネジャはジョブの実行特性に関するこれらの変更の影響を観察し；特に、ステップ(b)で使用されるグローバル境界までの待ち時間に関する相違を監視する。
【００７０】
（ｅ）短期間の監視の後に、リソースマネジャは、データを分析し、その分析からアプリケーションのタイプを判定する(例えば、CPUバウンドであるか或いはIOバウンドであるかを判別する)。この短い期間は、例えば、予想される実行時間の全体に対する数パーセント等のような値として定量化することが可能である。(どの程度長い間リソースがジョブに割り当てられなければならないかをリソースマネジャが分かるように)予想される全体的な実行時間は、通常、ユーザにより提供される。或いは、初期化フェーズで費やされる時間のうちの適切な割合の期間(例えば、2分の1或いは4分の1)を待機することも可能である。
【００７１】
（ｆ）アプリケーションの特徴が分かると、リソースマネジャは、ジョブに対する最良のコンフィギュレーションを設定し、それを残りのジョブの実行に使用する。すなわち、アプリケーションはIOバウンドであることが判明すると、リソースマネジャは、アプリケーションを実行する全てのノードに対して、省エネルギコンフィギュレーション(reduced  energy  configuration)を適用する。これに対して、アプリケーションはCPUバウンドであることが確認されると、リソースマネジャは全てのノードをデフォルトコンフィギュレーションに復元する(デフォルトコンフィギュレーションは、通常、各々のノードについて最高電力の設定となっている)。
【００７２】
従って、実施形態は、ノードの各々について個別的に最適な電力状態を検出しようとするのではなく、実行時間について全く又はほとんど影響することなくエネルギ消費を減らすグローバル設定を見出すことを目的とする。「グローバル設定(global  setting)」は「全体的な設定」、「包括的な設定」等と言及されてもよい。
【００７３】
図7は一実施形態によるHPCシステムを示す図であり、HPCシステムは後述するようにアプリケーション101を実行するためのコンポーネント100、102、103を有する。「コンポーネント」は文脈上適切であるならば「要素」、「部品」、「手段」、「モジュール」等と言及されてもよい。リソースマネジャはHPCシステムを制御し、アプリケーションをノードに割り当て、ハードウェアに対して或る設定(例えば、上述したように、クロック速度や動作電圧等についての設定)を適用する。電力設定を適用することは、各々ノードについてのローカルオペレーティングシステム(図示せず)との協同により実行されてもよい。
【００７４】
説明の便宜上、1つのアプリケーション101が複数のノード102で動作するように割り振られることが仮定される。アプリケーションは、ノード間でデータを通信する必要があり、それを実行するために通信ライブラリ103を利用する。通信ライブラリは、MPIのような標準化されたインタフェースを実現し、全てのHPCシステムのサポートソフトウェアについての標準的なコンポーネントとして提供される。これらは、最適なパフォーマンスをもたらすために、アプリケーションノードと通信ハードウェアとの間のインタフェースとなる。
【００７５】
これらのコンポーネント間のやり取りのうちのいくつかは、各自の間に引かれるライン(線)によって強調されている。リソースマネジャは、アプリケーションの実行のためにノードを割り当てる(104、105)。実行するアプリケーションは、データを通信し及び境界までの待機を調整するために、通信ライブラリのルーチンを呼び出す(106)。リソースマネジャは、エネルギの利用の仕方及びパフォーマンスを制限(又は制御)するためにノードに或る設定を適用する(107)。上述したように、待機時間を監視するために、リソースマネジャは、ノードが実行フェーズの状態にあるのか或いは待機フェーズの状態にあるのかを知る必要がある。このため、通信ライブラリを介してアプリケーションからリソースマネジャへの通信情報に、新たな関係(108)が導入される。この関係については後述する。
【００７６】
図8には、リソースマネジャ100の機能モジュールが図式的に示されている。アプリケーション実行のうちの一部分(ジョブ)を各ノードに割り当てるスケジューラ100aに加えて、個々のノードに対して、各自のエネルギコンフィギュレーションを変更するためのコマンドを発行することが可能な電力設定モジュール100bが存在する。図8に示されるように、モジュール100a及び100bはそれらにコマンドを提供するノード102に接続される。待機時間モニタ100cは、図7の108に示されるような待機時間の報告を受けるために通信ライブラリ103に接続され、平均的な待機時間を計算する。ライブラリの特定の機能(又は関数)を呼び出すことにより境界待機(barrier  waits)が生じるので、これは、ノードが待機している状態(期間)を検出する通常の方法である。アプリケーションタイプディテクタ又はアプリケーションタイプ判定モジュール100dは、上述したように「変化」とともに又は「変化」なしにノードの平均的な待機時間を比較することに基づいて、アプリケーションが(少なくとも現在のフェーズにおいて)IOバウンドであるか否かを判断する。
【００７７】
図9は、一群のノードにジョブを割り当て、特徴の判別を経て、実行する残りの部分に最良のコンフィギュレーションを設定することによる実行フローを示す。
【００７８】
200において、コンピュータにおける一群のノード(ノード群)にジョブが割り当てられ、これらのノードはデフォルトコンフィギュレーションに設定される。ここで、「デフォルトコンフィギュレーション」は、実施形態による状態のようなエネルギ節約の仕組みが存在しない場合に使用されるコンフィギュレーション又は状態を意味する。同等なノードが、アプリケーションの類似する部分を実行する場合、それは図2の均一的な動作に対応する。しかしながら、理解されるように、HPCシステムは不均一ノードを含み、及び/又は、個々のノードに割り当てられるアプリケーション部分は、それに関わる演算負担量に応じて異なるかもしれない。
【００７９】
リソースマネジャは、グローバル境界までの各ノードの待ち時間に関するレポートを(通信ライブラリ103を介して)ジョブから受信する(201)。
【００８０】
ある時点において(202において「イエス(Yes)」である場合)、これらの待機時間は安定的になり、すなわち、シミュレーション期間とともに反復的な待機のパターンが生じる。これは、ジョブが、実行についての主要な部分(言い換えれば、反復フェーズ)に到達したことを示す。
【００８１】
そして、リソースマネジャは、ジョブに割り当てられたノード群のうちの一部分(部分集合)のノードの実行速度又は実行レート(rate)に不均一性を導入する(203)。ここで、「部分集合(subset)」は、ジョブが割り当てたれた群よりも少ない数のノードを意味する。文脈上適切であるならば「群」は「集合」、「集団」、「集まり」、「グループ」等と言及されてよい。部分集合内のノードの数は図6に示されるライン(線)に従ってされ、例えば、鋭い応答をもたらすノード比率により決定されてもよい。例えば、図6に示される例では、それは1ないし2％のノードであってもよい。不均一性はランダムに導入される(言い換えれば、部分集合は、ノード全体の集合のうち、ランダムに選択される部分集合である)。
【００８２】
リソースマネジャは待機時間を監視し(204)、(201による)均一的な実行の場合に確認される平均時間と新たな平均時間とを比較する。この比較は、CPUバウンド及びIOバウンドの間の実行の区別を可能にする(205)。本願で説明されるように、検査するための多数の可能な電力消費状態が存在し；それぞれ1つずつ順に検査することが可能である(206)。全ての可能なコンフィギュレーションが検査されると、最適な設定(電力状態)が全てのノードに適用され(207)、ジョブの実行は完了する。個々のノードに不均一性を導入することにより決定される設定が、アプリケーションを実行するノード群の全体に等しく適用される。
【００８３】
通常、ノードについての多数の様々な電力消費状態が存在し、各々の電力消費状態は、電力消費を減らす一方でパフォーマンスの低下をもたらす。S1,S2,S3,...,SNというN個の電力状態が存在する場合に、各自の電力消費量Pは、
P1＞P2＞P3＞...＞PN
のように整えられ、実行速度Rは、
R1＞R2＞R3＞...＞RN
のように整えられるように仮定することが一般に可能である。
【００８４】
全てのノードは当初において(200において)S1という最高の電力設定状態(及び最高のパフォーマンス状態)に設定されている。203における不均一性の最初の導入は、ノードのうちのいくつか(上記の「部分集合」)についての電力状態をSNに設定する。これらのノードを(何らかの中間的な電力状態ではなく)SNに直接的に設定することは、IOバウンドアプリケーションを最も迅速に顕在化させる方法である。
【００８５】
205においてIOバウンドアプリケーションが検出されると(待機時間がさほど変化しない場合)、ステップ206の分岐は207に進み、SNが全てのノードに適用され、実行が完了する(208)。しかしながら、CPUバウンドアプリケーションである可能性がある場合(待機時間が変化する場合)、203において、状態SNにおけるノードは(例えば)SN-1に設定され、ランダムに選択される異なる部分集合のノードを利用して、再び実行されるステップ203ないし206のループを監視して識別する。ちなみに、このステップにおいて、検査される次の歩幅(ステップ)がS1から何らの変化も示さない最低値とそれまでに検査された最高値との間の中間であるように、バイナリサーチ(binary  search)を用いて電力状態を設定することも可能である。
【００８６】
ループを監視して識別する処理は、待機時間に変化のないことが検出されるまで続く。全ての状態S1,S2,S3,...,SNが、検出される如何なるIOバウンドもなしに検出される場合、均一な状態は、全てのノードがS1であり(エネルギを一切節約せず、デフォルトコンフィギュレーションから変わりがない状態に対応する)、そうでない場合、グローバル待ち時間に対して検出可能な変化をもたらさないSの値である。
【００８７】
上記のプロセスにおいて、S1の値の全てを検査するのではなく、一群の状態のうちの一部分のみを利用することが可能であり、例えば、S1及びSNを利用することが可能である。この方法は、いくつかのジョブがより高い電力消費で実行されることを招くが、最終的な均一な状態を速やかに選択できる。
【００８８】
図6は、1％ないし5％の範囲内のような非常に僅かな割合のノードのみが、変化させられた実行速度を有するべきことを示し、従って、上記の考察される部分集合のサイズは小さくあるべきである。変化させるノードの割合は、特定の如何なるHPCシステムにも依存せず従って一般的な値を選択することが可能である。好ましくは、部分集合のサイズは、非常に小さい応答からIOバウンドアプリケーションを区別するように、(モニター及び識別のループの反復における)各々の検査で同じであるべきである。しかしながら、IOバウンドアプリケーションである可能性がある場合、部分集合のサイズが十分に大きくなるようことを保証するために、部分集合のサイズを増やすことを促してもよい。
【００８９】
アプリケーションの実行の早期段階において実施形態による方法を適用し、決定された設定を、実行の残りの部分に適用するように上記では説明したが、アプリケーションを実行する際の任意のポイントで本方法を再び適用することが可能であり、アプリケーションが様々なエネルギ状態及びパフォーマンスで各フェーズを通過する場合に、最適な効率を維持するようにハードウェア設定を調整することが可能である。
【００９０】
すなわち、HPCアプリケーションは、その計算のいくつかの異なるフェーズをしばしば通り、各々のフェーズは異なるメモリ及びCPU利用状態を有し、アプリケーションがこれらのフェーズを通る場合に、最適な電力利用状態は変化するかもしれない。
【００９１】
図10は一実施形態による方法の変形例を示し、実行を監視し及びプログラムフェーズの変更に合わせて電力消費状態を調整するように、図8のフローがどのように拡張されることが可能であるかを示す。ステップ300ないし306はそれぞれ図9のステップ200ないし206に対応する。最適なコンフィギュレーションが見出され、ジョブのノードがそれに合わせて不均一化され(307)、実行フローはステップ308に進むが、リソースマネジャは、フェーズの変化に対して待機時間を監視する(309、310)。変化が検出されると、検査ループは再び303に入り、新たなコンフィギュレーションが決定される。
【００９２】
本願の開示範囲内において様々な変形例が可能である。
【００９３】
上記の説明では、ノードのパフォーマンスを落とすために幾つかのノードのエネルギコンフィギュレーションをリソースマネジャが修正することが仮定されている。しかしながら、これは唯一の可能な形態ではない。クリティカルパスにおけるノードで多くのエネルギを費やすように、(ノードのハードウェアにより許容されるならば)個々のノードのパフォーマンスを一時的に増進させることが可能である(クリティカルパスにおけるノードは、多くの演算負担を有し、他のノードはそれを待機する必要が生じる)。これは、アプリケーションを実行するのに費やされる全体的な時間を減らすことにより、消費される全エネルギを減らすことになる。図9及び図10の方法において、これは、可能な最高の状態S1よりも下位の電力状態でノードをスタートさせる必要がある。
【００９４】
リソースマネジャ100は、図7において、ノード102とは別個の単独の機能ユニットとして示されているが、リソースマネジャは、複数の機能ユニットの間に分散されること及び/又は1つ以上のノード上で実現されることが可能である。
【００９５】
上記の説明では、N個の電力消費状態が仮定されているが；実施形態は各々のノードについての僅か2つの可能な電力状態とともに適用されてもよい。
【００９６】
本願で説明される方法ステップは、説明された順序と異なる順序で実行されてもよく、それでも適切な結果をもたらすことが可能である。
【００９７】
リソースマネジャは、ソフトウェア、ハードウェア、ミドルウェアにおいて実現されてもよいし、或いは、特定用途向け集積回路(ASIC)又は他の任意の形態で実現されてもよい。
【００９８】
＜産業上の利用可能性＞
実施形態は、特定のアプリケーションに対するハードウェアについての最も効果的なコンフィギュレーションを発見することを可能にし、そのコンフィギュレーションはアプリケーションが動作する間に最低の電力消費による不変のパフォーマンスを達成し、これにより、必ずしも実行時間を延期することなく、ハイパフォーマンスコンピュータにおけるエネルギ消費を減らすことができる。
【符号の説明】
【００９９】
１００  リソースマネジャ
１０１  アプリケーション
１０２  ノード
１０３  通信ライブラリ
【図１】
0006477260.tif 000002
【図２】
0006477260.tif 000003
【図３】
0006477260.tif 000004
【図４】
0006477260.tif 000005
【図５】
0006477260.tif 000006
【図６】
0006477260.tif 000007
【図７】
0006477260.tif 000008
【図８】
0006477260.tif 000009
【図９】
0006477260.tif 000010
【図１０】
0006477260.tif 000011