広域分散環境に適応した柔軟な資源管理システムの提案 2006.2.17 電子情報工学科４年近山・田浦研究室 40391 斎藤大 1 背景  広域分散環境     高性能な計算機・高速なネットワークの普及大規模並列計算多数のパラメータでの計算効率の良い資源管理の必要性  様々なスケジューラが提案 2 背景  よく用いられるシステム：“Batch scheduling system” →マスタースケジューラがジョブへのリソース割り当てを行う  問題点  柔軟性に欠ける資源の利用方針（排他的なリソース利用）  サポートするプログラミング環境の少なさ  ジョブの実行形式の制限（自由なプロセス起動の禁止）  スケーラビリティ・single point of failure  広域環境における無駄なトラフィック Job Job Job Job 3 柔軟性に欠ける資源の利用方針  多くの場合各ノードは１プロセスが占有   プロセスの競合を発生させないため不都合なケース   インタラクティブな（間欠的にCPUを利用する）プロセス Cycle steeling process（例：SETI＠home）    たくさんCPUを使いたいが故に控えめなプロセスシステム管理（特定ノードにのみ関心がある）動く「場所」が性能にとって重要なプロセス 4 サポートするプログラミング環境の少なさ    ジョブの実行形式の制限がある多くのbatch schedulerはリクエストに対し（ユーザに代わって）プロセスを起動するプログラミング環境（MPI, PVM, RMI…）毎にプロセス起動方式（ssh, rsh, fork, exec…）が異なる →プログラミング環境とbatch schedulerがお互いに対応する必要がある Job Job Job 5 スケーラビリティ・耐故障  スケーラビリティの問題   システム規模の拡大でマスターへの負荷増加 Single point of failure →マスターの故障でシステムダウン  ハードの故障  キューの設定ミス(人為的なミス） Job 6 広域環境における通信   全てのリクエストを１ノードに集約局所性の無視   距離に関わらず実行の度にマスターとの通信 NATやfirewallの問題  多くは直接接続が不可能なケースを考慮していない 7 目的  従来のbatch scheduling system  単一のクラスタでの利用を想定    広域な環境へはad hocな対応しかしていない実行形式に制限がある目標するシステム   はじめから広域な環境を想定実行ジョブの制限をしない広域分散環境に適応した柔軟な資源管理システムの提案 8 発表の流れ      背景と目的関連研究提案手法実験と評価まとめ 9 関連研究  Batch queueing system及びそのスケジューラ [Raman 98]   Gang Scheduling, Co-Scheduling [Andrea 98, Sobalvarro 97]    １ノード１ジョブを前提全ノードで同期した時分割共有並列計算の効率化両者を組み合わせたシステム   Distributed Queue Tree [Hori 99] 時分割＋空間分割 10 提案するシステムの概要    P2P的にグラフを張り、近隣から探索を行う  スケーラビリティ、局所性の保存  NAT、firewall越え各ノードに「全てのプロセス」を監視するデーモンを置く  自由なプロセス起動を許容するプロセスの属性「希望占有率」を提案  希望占有率が低いもの同士を１ノード上で共存 Node Search Scheduler Daemon 11 広域環境でのグラフ構築  ネットワークアドレスを元にクラスタリング     IPアドレスが類似→同一クラスタ内（近接・接続）ローカルIPしか持たない→NAT・ゲートノードの存在「自クラスタ内のノード＋ゲートノード」で接続特別な事前設定無しで動作 12 ノード探索   直接接続しているノード間で定期的に Load average情報交換グラフに従ってn個の空きノード（ワーカ）探索 Load average<規定値？  CPU使用率<規定値？（並列にps実行）この二つを満たすと実行可能なワーカとみなす全て探索しても足りない場合上を満たさない（混雑）ノードについて  ノード上のプロセス状況スケジューラ  「ジョブを投入する余裕があるか」を見る  13 ノード探索の流れ k=3 A 8node ps ps B ps D ps C B1 ps C1 B3 ps B2 C2 ps ps ps 14 ローカルスケジューラ  各ノード上で自律的に動作    ノード上の全ての実行プロセスを管理ユーザが各プロセスに ‘希望占有率’を設定 nice値を調整、CPUを振り分ける  OS内部でのプロセス優先度＝20 – nice nicei  20  20 CPUi max(CPU ) 15 ローカルスケジューラ   占有したいのか、邪魔していいのかノード探索システムへ    どの占有率のプロセスがどれだけ走っているか、を返す例）低占有率のプロセスのみだったら実行可能なワーカとみなす 16 ユーザから見た動作     引数に実行したいプログラムを与えると n個のワーカで実行引数無しだと、ワーカのホスト名リストを文字列で返す →応用（MPIなど） Parameter Sweepに対応全ノード探索して十分なワーカが見つからない時、初めてキューに追加 17 実験：負荷分散   情報理工 istbsクラスタ 190ノード管理 10,20,30,…190台のワーカ取得、hostname 1-64で低占有率×１、70-75で高占有率×３ 3.5  空きノード優先低プロセスのみなら実行可能とみなす 2.5 2 1.5 低占有率 1 0.5 高占有率 0 0 10 20 30 40 50 60 70 80 9 10 0 0 11 0 12 0 13 0 14 0 15 0 16 0 17 0 18 0  load average 3 20 18 16 14 12 10 8 6 4 2 0 実行回数  ノードID 18 実験：スケジューラによる選択      20ノード管理（×２CPU） 10ノードでは高占有率プロセス（fib(35))を２つ、 10ノードでは低占有率プロセスを２つ走らせる。 CPU使用率200％、Load average≒2.0 更に10個のプロセス投入低占有率プロセスが稼動しているノードのみが選ばれた 19 実験：マスターへの高負荷    120ノード管理本システムと同等の動作をするマスターワーカー型システムとの比較複数のユーザが同時に１０台のワーカ取得しそれぞれのワーカ上でhostname 2.5 同時アクセスが発生しても性能変わらず実行時間(s)  MasterWorker 本システム 2 1.5 1 0.5 0 0 5 10 同時ユーザ数 15 20 20 まとめ  資源管理システムの提案     基本は空いているノード探索混雑時、占有率に従ったノード選択アクセスの集中が発生しない（スケーラブル）今後の課題    システム全体の高速化同時起動の問題空きが見つからないときのキューの設計 21