More Related Content Similar to TSUBAME3のインタラクティブ利用の利便性向上にむけた取り組み (20) 1. 野村 哲弘, 遠藤 敏夫 (東京工業大学), 三浦 信一 (理研/東工大)
朝倉 博紀, 越野 俊充, 草間 俊博 (日本ヒューレット・パッカード)
TSUBAME3のインタラクティブ利用の
利便性向上にむけた取り組み
Part of this work was supported by JSPS KAKENHI JP19H04121 and JST CREST JPMJCR1501, JPMJCR18F5, Japan, etc.
2. 大学スパコンの資源逼迫状況
• 東工大のスパコンTSUBAME3の利用者
• 学内ユーザ (教員・学生) – 「みんなのスパコン」
• 今回は主にこのユーザ層にフォーカスします
• 共同研究等に基づく他機関の研究者
• 学外利用プログラムによる学術利用・産業利用ユーザ
• HPCI/JHPCNでの利用・「京」移行期のユーザの受け皿・COVID19課題
• TSUBAMEの計算資源の逼迫
• ノード利用率96.6% (2020/1) に達する
• ジョブを投げてもなかなか走らない
• 特にインタラクティブ利用で致命的
FY2019利用率
(予稿の図4)
2020/7/31 SWoPP 2020 2
緑以外: 使用中
3. スパコンのインタラクティブ利用
• ジョブに利用者が介入 and/or 即時に実行したい
• デバッガの利用
• 計算結果のビジュアライズ
• Jupyter Labなどの統合開発環境の利用
• センサーデータのリアルタイム処理
• いつでも実行したいが、性能は多少低くても構わない
• ほとんどの時間は入力待ち、ノード占有するには勿体ない
• 従来のバッチジョブに求められる特性とは真逆
• ノードが空くまで待つのは構わないが、安定した性能が欲しい
• → 1つのノード内に多数のジョブが共存してもよい・共存すべき
• 目標その1: インタラクティブジョブに特化した、
資源逼迫時にもジョブが即時実行可能なサービスを作る
時刻
負荷
2020/7/31 SWoPP 2020 3
4. スパコン初学者にとっての壁
• スパコンの計算ノードで何かをするために必要な知識
• SSHおよび公開鍵認証 ← 教育コスト超高 Zoomでトラブルシューティングできますか?
• X転送・ポートフォワーディング (可視化・Jupyterなどを利用する場合)
• Linuxの基本的なコマンド
• ジョブスケジューラの概念・ジョブスクリプト
• アクセラレータ(GPU)や並列処理(MPI, OpenMP, OpenACC)
• ドメイン・実際に動かすアプリの知識
• 本質的には、オレンジ色の箇所の知識しか要らないはず
• いや、あるには越したことないのですが…
• 目標その2: 上記青色の知識がなくても、初心者がTSUBAMEの
計算ノードを利用できるようにする
2020/7/31 SWoPP 2020 4
6. TSUBAME3.0 ノード構成 (単一構成540ノード)
• 4GPU
• NVIDIA P100
• 2CPU
• Xeon E5-2680 v4
• 1 NVMe SSD
• Intel DC P3500 2TB
• 4 OmniPath HFI
• 1本あたり100Gbps
• 256GiB Memory
• 「京」などと比べてFatなノード
• 典型的なジョブのノード数が少ない
• 多くのジョブはノードを分割して
使っている
2020/7/31 SWoPP 2020 6
7. TSUBAME3での
(従来型ジョブ向け)リソース分割
• ジョブスケジューラ
Univa Grid Engine(UGE)上で
Linux cgroups (Control Groups)
を用いたノード論理分割
• ユーザには CPU 7コア+ 1GPU +
64GiB メモリといった
仮想ノードを見せる
• 複数のジョブが物理ノードを共
有
• 仮想ノードレベルでは1つの
ジョブが資源を占有
• 時間方向での資源要求の変化には
対応できない(無駄が出る)
2020/7/31 SWoPP 2020 7
CPU
CPU
GPU
GPU
GPU
GPU
OPA
HFI
OPA
HFI
OPA
HFI
OPA
HFI
14コア H
7コア Q
2コア
4コア
G
C4
F
8. 提案1: 学内向けインタラクティブ
ジョブ実行専用ノード・キューの導入
• ノードの利用が間欠的であるインタラクティブジョブは、1つの(物
理・仮想)ノードに複数詰め込んでも良い → 詰め込む
• ノード時間課金の従来型並列ジョブでは、外乱による性能劣化大なので不可
• TSUBAMEの540台の計算ノードから4台(<1%)をインタラクティブ
ジョブ専用に切り出し、別キューとして提供
• ¼ノード(7コア・1GPU・64GiB実メモリ)を最大7ジョブで共有
• 最大7ジョブはUGEの実装上の制限(物理コアとジョブがジョブ管理上対応している)
• 同時実行 4 x 4 x 7 = 112ジョブ, 実習系講義が1クラス分収まるレベル
• ジョブは待ち状態にならない (資源不足なら単純に失敗)
• 東工大学内ユーザ1ユーザあたり1ジョブのみ同時実行可能
• ジョブの最大実行時間は24h (忘れた頃に強制終了される)
• MPIなどのノード間並列は許可しない(OpenMPIなどのノード内並列は可)
• CPUメモリは1ジョブあたり60GBに制限、不足分はSSD(1.5TB)にスワップ
ファイルを作成して利用 (通常ジョブ用ノードはスワップファイル不使用)
• GPUメモリは制御ができないので「早い者勝ち」にせざるを得なかった
2020/7/31 SWoPP 2020 8
9. 提案1: 学内向けインタラクティブ
ジョブ実行専用ノード・キューの導入
• 使い方: qrsh -q interactive –l h_rt=08:00:00
• これだけで1GPUが見える計算ノードにログインした状態になるので、並列
コンパイル・デバッグ・可視化など自由に利用可能
• ログインノードにX転送付きでログインしていれば、Xアプリケーションも実
行可能
• 2019/11に東工大学内ユーザ向け試行開始
• 試行中は課金を行わず、学内向けインフラとしての提供
• 学外開放・課金するとして、何をベースに課金を行うか(実時間?、CPU時間?)、
通常ジョブとのバランス等要検討
• 2020/4～2020/5の2か月間で120名の利用
• 全アクティブユーザの15.8%
• 現状では、ノードが逼迫することはなく、比較的快適に利用できている状況
• 混雑していないので、ノードの「快適度」は現状測れていない
2020/7/31 SWoPP 2020 9
10. スパコンでのJupyter Labの利用
• Jupyter {Notebook|Lab}
• https://jupyter.org/
• Webブラウザ上でPythonプログラムを対話的に実行
• 近年ではJupyter Labとして、Notebook以外にも
ファイル操作・編集やコンソールアクセスも可能に
• 特にシステムの助けがない場合、以下のような起動手順となる
• Jupyterのインストール (pip install --user jupyterlab)
• 計算ノードの確保
• Jupyterの起動 (を、ジョブスクリプト内で行う)
• Jupyterが待ち受けする計算ノードまで、SSHポートフォワード設定
2020/7/31 SWoPP 2020 10
11. プロトタイプ (という意識は当時はなかった)
Jupyter起動コマンド jupyterrun
• 2019/6に(実験的サービスとしてこっそり)公開
• 使い方: jupyterrun (qrshと同じオプション, -q interactiveも可)
• 実行するとこんなメッセージが表示される
To enable port forwarding, execute this command in another terminal:
ssh -l username -L 8888:r0i1n2:12345 login.t3.gsic.titech.ac.jp
Then, you can connect to http://localhost:8888/
• 表示されてるsshコマンドを別ターミナルで叩く(ポートフォワーディング)
• http://localhost:8888/ を表示すると、計算ノードで動くJupyterが居る
• 計38行のスクリプトの裏でやってること
• jupyter lab --no-browser --ip=0.0.0.0 --port=(ランダムなポート番号)
• virtualenv等のPython仮想環境対応や、Jupyterのインストール状況確認、メッセージ表示
• やってること、(実装・起動の)手間の割には、楽に起動できるようになった
2020/7/31 SWoPP 2020 11
自動化は割と現実的にできそう、これを突き詰めるとどこまでできる?
13. ジョブの投入
• qsubコマンドのオプションをWeb UIで
指定する
• 先述のインタラクティブジョブ専用
キューも指定可能
• リソース不足(ノードが空いてない)時に
ジョブをキャンセルする動作がデフォル
ト
• UGEのqsubにおける -now y に相当
• ノードが空くまで待つこともできる
• Jupyter Lab以外も使えるようにUI等を設
計しているが、現在はJupyter以外提供し
ていない
2020/7/31 SWoPP 2020 13
15. ユーザ向けのJupyter環境の整備
• Jupyter Lab関係Pythonモジュールをインストール済みのPythonを
(通常のものとは別に)用意
• Jupyter Lab実行ディレクトリは${HOME}/t3workspace
• ユーザ設定ファイルを誤って操作しないよう${HOME}は避けた
• 通常のPythonモジュールのインストール
• Jupyter Lab上のコマンドライン(Notebookの%%bashも可)で、
pip install --user modulename で各自のホームディレクトリに導入可
• CUDA等外部ライブラリを参照するPythonモジュール(CuPy等)
• CUDAはTSUBAMEではデフォルトPATHにない(Environment module使用)
• CUDAバージョンは選択可能にしたい ↑いわゆるmoduleコマンド
• Jupyter Labで実行するPython環境(カーネル)の環境変数を定義するインタ
フェースが必要
2020/7/31 SWoPP 2020 15
16. t3jpttools Pythonモジュール
• create_kernel(カーネル名, Environment moduleのリスト)
• 実行するとJupyterのカーネル(環境)設定ファイルを作成
• Jupyterの機能でカーネルを切り替えることで、指定したEnvironment
moduleに対応する環境変数が設定されるので、CUDA等を利用可能に
• 以下、未実装な機能 (今後の課題)
• virtualenv, pyenv, Anaconda等のPython仮想環境への対応
• どこまで面倒を見るべきか… 現状はこの辺を使える人はjupyterrunも使える
• 任意のPythonバージョンの選択機構(部分的に対応済み)
• Jupyter動作に必要なPythonモジュール(ipykernel_launcher)の存在をど
うやって保証するかが問題
2020/7/31 SWoPP 2020 16
17. • 2020/4に本機能を公開
• 2020/4～6 のTSUBAME利用歴のあるユーザの内訳
• 利用者内のシェアとしては、14.5%
• 新規のユーザを6％発掘・獲得できた
• 機能の存在をどうやって宣伝していくかが鍵
• 現在は広報しつつ、担当講義の演習等で利用するなど
TSUBAMEログイン・利用歴あり: 921名
Webアプリケーション実行機能の
利用状況
2020/7/31 SWoPP 2020 17
SSHによる通常のログイン: 868名
Jupyter
134名
53名
新規発掘
18. 関連研究・実装等
• 中田ら (前回のHPC研究会 HPC174(1))
• ポートフォワーディングを自動化するスクリプト
• 東工大のjupyterrunをさらに発展・自動化させた形
• ユーザの手元に自動化用スクリプトを置くことが前提
• Jupyter Hubを外部のクラウド上に設置
• ユーザ管理が計算機と外部クラウドで二重に必要になる
• クラウド上にパスフレーズなしSSH鍵を設置する必要あり
• 計算機のアカウント1つを共有する設計 (TSUBAMEでは利用規約で禁止)
• Google Colab
• TPUやGPUが利用可能なクラウドJupyter Notebook環境
• Jupyterカーネル切り替えでTPUノードやGPUノードへの移動が可能
• ノードの確保はJupyterカーネル起動時(Pythonコードの初回実行時)の模様
• 一度Jupyterカーネルを起動すると、資源を占有して入力待ちに
2020/7/31 SWoPP 2020 18
