260 likes | 411 Views
グリッド用シェル GXP の 長時間計算のための拡張. 関谷 岳史 田浦 健次朗 ( 東京大学 ). 背景. 複数拠点にまたがった計算資源を使える機会の増加 Grid5000 PLANETLAB InTrigger プラットフォーム ひとつの大きな計算資源として利用するためには様々な困難がある 拠点間のヘテロ性が主な理由. 困難その1 ハードウェア・ソフトウェアの不均一性. ハードウェアの不均一 計算・通信性能の違いによる扱いにくさ 負荷をバランスしにくい CPU のアーキテクチャの違いにより、バイナリファイルが使いまわせない ソフトウェアの不均一
E N D
グリッド用シェルGXPの長時間計算のための拡張グリッド用シェルGXPの長時間計算のための拡張 関谷 岳史 田浦 健次朗 (東京大学)
背景 • 複数拠点にまたがった計算資源を使える機会の増加 • Grid5000 • PLANETLAB • InTriggerプラットフォーム • ひとつの大きな計算資源として利用するためには様々な困難がある • 拠点間のヘテロ性が主な理由
困難その1ハードウェア・ソフトウェアの不均一性困難その1ハードウェア・ソフトウェアの不均一性 • ハードウェアの不均一 • 計算・通信性能の違いによる扱いにくさ • 負荷をバランスしにくい • CPUのアーキテクチャの違いにより、バイナリファイルが使いまわせない • ソフトウェアの不均一 • 利用したいソフトウェアがインストールされていない • インストールに管理者権限が必要なものもある
困難その2様々に指定された利用方法 • ssh/rsh、torque、SGE etc… • sshなどのインタラクティブな利用 • 1ノードづつ対話的に使うのには便利 • バッチキューを通しての利用 • 順番が来るまで待たないといけない • 拠点ごとに別々の管理だと、同時に複数拠点のノードをまとめて確保できるとは限らない
困難その3管理ドメイン・管理ポリシーの違い困難その3管理ドメイン・管理ポリシーの違い • ヘテロ性の解消を阻害 • 管理組織がことなることで、各拠点で環境をそろえにくい • ネットワークセグメントの違いによる通信の難しさ • セキュリティの確保のため、外部ネットワークとの間のファイアウォールの利用 • ネットワーク事情やIPアドレスの不足によるNATの利用
グリッド環境で使う場合の既存のミドルウェアの問題点グリッド環境で使う場合の既存のミドルウェアの問題点 • 同一管理ドメインでの利用を想定したもの • アカウント名の統一 • NFSなどで共有されたファイルシステム • 全対全通信(NAT・ファイアウォールなし) • 導入が大変なもの • 管理者権限でのインストール • 複雑な設定
GXP [Taura 2004] • グリッド用のツール • プロセスマネージャとしてMPD [Butler et al. 2000]と似た機能を提供 • プロセスの並列起動 • ローカル⇔リモート間のstdioのリダイレクト • マスターワーカーモデル計算とEPジョブの実行をサポート
GXPのアプローチ • なるべく少ない前提条件で動く • 最小のソフトウェア • 一般ユーザ権限 • 様々な資源利用方式に対応し、それらをまとめてインタラクティブに利用できるようにする • 環境のヘテロ性を隠して、単純なプログラミングモデルをユーザに提供
本研究の目的 • GXPを使った長時間計算のための拡張 • 計算実行中のノードの新規獲得・コマンドの投入 • 計算実行中のプロセスの脱退 大きなCPUパワーを得たい人がなるべく少ない 労力で、より簡単にグリッド環境を利用できるように
GXPの特徴(1) • 導入が簡単 • 最小限のソフトウェアで動く (python + ssh) • pythonスクリプトなので、コンパイルが不要・インストールはコピーするだけ • 1つのノードにのみインストールすればOK • 新しいノードを獲得する際に自分自身をコピーし、自動的にインストール • 設定がほとんどいらない
GXPの特徴(2) • 複数のリモートシェルに対応 • sshなどのインタラクティブシェル • torqueなどのバッチキュー • まとめて対話的に利用可能 sshログイン 対話的に コマンド投入 バッチキューによる ノード獲得
GXPの特徴(3) • 最小限の通信で動作 • sshやtorqueなどでユーザプロセスを立ち上げ可能であれば、ノードを獲得可能 • Tree状に多段ログイン • NAT/Firewallなどによる制限をうけづらい Global Network Private Network
構成 client コマンドの投入 stdioのリダイレクト gxpc gxpd sshd or torque etc.
ユーザから見たGXP • ヘテロな環境の資源をまとめて、直接対話的に利用可能なノード群に見せる Firewall ・・・ バッチシステム sshログイン
ノードの獲得 • useコマンド • あるホストから別のホストへのログイン手段を指示(ssh、torqueなど) • ログインに用いるユーザ名も指定可能 • exploreコマンド • useコマンドの指定に従って、実際に指定されたノードへ接続を試み、デーモンプロセスを立ち上げる % gxpc use ssh hongo000 suzuk000 % gxpc explore hongo[[000-010]]
コマンド投入 • eコマンド • 選択した各ノードでコマンド実行 • 各ノード⇔コンソール間でstdioをリダイレクト • unixパイプによるシェルと協調 % cat file | gxpc e ‘cat > local_file’ % gxpc e hostname | sort
マスター・ワーカーモデル • mwコマンド • ユーザの作成したマスターをローカル、ワーカーを各ノードに立ち上げる • ある決まったファイルディスクリプタを読み書きすることで、マスターワーカー間の通信が可能 % mw --master MASTER WORKER MASTER WORKER
while True: (task要求が来るまでFD3を読む) (task生成) (あて先とtaskをFD4へ書き込み) while True: (FD4へtask要求書き込み) (自分宛のメッセージが来るまでFD3を読む) (task消費) 簡単なマスターワーカーの例 マスター ワーカー 下位のネットワークを意識せずに、 ローカルのファイルディスクリプタへの書き込みで通信が可能
EmbarrassinglyParallel • epコマンド • mwコマンドにより実現 • tasks_fileに書かれたコマンドを順に各ノードへ割り振り(パラメータスイープジョブを実行可能) % gxpc ep tasks_file tasks_file cmd1 タスク要求 task1 cmd1 cmd2 task2 cmd2 task3 cmd3 cmd3 task4 cmd4 cmd4
GXPを用いた長時間大規模計算 • epコマンド・mwコマンドによる長時間大規模計算 • 自然言語処理・VGXP[鴨志田ら ‘06]など • 資源の大規模化・計算の長時間化 • 利用可能資源の動的な変化 • バッチキューの順番待ち • 連続利用時間の制限 • 故障の発生 • 計算実行中の資源の増減への対応が必要
GXPの拡張 • 長時間計算のための拡張 • 計算実行中のノードの新規獲得・コマンドの投入 • 動的explore • ノード追加eコマンド • epコマンド実行中のワーカーの脱退 • それぞれ対話的に行えるよう拡張 • 自律的な資源管理機構と組み合わせも可能 • 利用例: • バッチキューの順番を待ちつつ、獲得できた他のノードで計算を始めておく • 利用時間制限のある拠点からのみプロセスを脱退
通常のexploreコマンドと同様に対話的に資源の追加が可能通常のexploreコマンドと同様に対話的に資源の追加が可能 マスタープログラムをワーカの増加に対応するよう記述 ユーザから見た資源の追加 マスター ワーカー
計算資源の脱退 • epコマンドのみに対応 • 脱退の命令を受け取るとタスクをそれ以上要求しない • 実行中のタスクが終わり次第、脱退 • 命令を受け取ってから、脱退できるまでの時間はタスクの粒度による
デモ • POV-rayによるレイトレーシング • epコマンドによる並列化 • 全体画像を領域分割し、各プロセスで32*24の画像をレンダリング(パラメータスイープジョブ) • 総タスク数1024 ・1タスク5秒程度 • シナリオ • はじめistbsクラスタで実行開始 • sheepクラスタを計算に追加 • istbsクラスタへのタスクの割り振りを停止
まとめ • ヘテロなグリッド環境の資源をまとめて使うための手段としてのGXP • 導入が簡単 • eコマンドやepコマンドによる並列ジョブの実行 • 大規模長時間計算のためのGXPの拡張 • 計算実行中の資源の追加 • コマンドの追加投入
今後の課題 • よりよい耐故障機構の実装 • 現在は下位のネットワークのエラーによって故障を検知 • 対処はユーザが行う • ネットワークエラーの起きない故障の検知・対処 • 拡張を利用したよりハイレベルなジョブスケジューラの実装