Mizuno Group Logo
MIZUNO GROUP
Back to Cloud

miyabi / wisteria スパコン利用マニュアル

東大のスーパーコンピュータ（HPC：High Performance Computingシステム）である miyabi と wisteria で処理や学習プログラムを動かすための利用マニュアルです。

  1. 初回接続と基本設定
  2. Python環境の構築
  3. プログラム（ジョブ）の実行
  4. Singularity環境（コンテナ）の利用

1. まずはスパコンにログインする

手元のクライアントPC等からSSH接続を設定します。SSH接続自体の基本概念については「Onpremiseマシン運用マニュアル」等を参照してください。

オンプレミス環境と同様に ssh-keygen コマンドで秘密鍵と公開鍵のペアを作成した後、公開鍵の中身（~/.ssh/xxx.pub）を各スパコンの利用支援ポータル（SSH公開鍵登録窓口）にアップロードします。

SSHの接続先設定 (~/.ssh/config)

登録完了後、ローカルPCの ~/.ssh/config に接続設定を記述します。

miyabi の設定例 (GPUノードの miyabi-g の場合)

miyabi は CPU+GPUノードの miyabi-g と、CPU専用ノードの miyabi-c でログインサーバーのアドレスが異なります。

Host miyabi-g
    HostName miyabi-g.jcahpc.jp
    User <your_username>
    Port 22
    IdentityFile ~/.ssh/<your_private_key>
    IdentitiesOnly yes

wisteria の設定例

wisteria は CPU+GPUノードの Aquarius と、CPU専用ノードの Odyssey がありますが、ログインの窓口は共通です。

Host wisteria
    HostName wisteria.cc.u-tokyo.ac.jp
    User <your_username>
    Port 22
    IdentityFile ~/.ssh/<your_private_key>
    IdentitiesOnly yes

記述したら、ターミナルで ssh miyabi-g または ssh wisteria を実行して接続テストを行います（VSCodeのRemote SSHを使用しても構いません）。

  • 注意: miyabi は初回接続時に、スマートフォンのワンタイムパスワード生成アプリ等を用いた2段階認証の設定が必要です。ログイン時の指示に従って設定を完了させてください。

2. ホームディレクトリの変更 (ディスク容量の確保)

ログイン直後のデフォルトのホームディレクトリ（~ / /home/<username>）は、ディスク容量の上限が 50GB しかなく、すぐに容量不足になります。 そのため、大容量の作業用共有ディレクトリである /work/<group_id>/<user_name> へホームディレクトリを変更します（miyabi はプロジェクトごとに 5TB、wisteria は各ユーザー 2TB の容量が確保されています）。

ログイン後、以下のコマンドを実行します。

$ chhome /work/<group_id>/$USER

これにより、ホームディレクトリ配下にあった各種設定ファイルや環境ディレクトリが /work 配下へと自動的に移動され、次回ログイン時から直接この領域へ入るようになります。移動後、パーミッション設定を正常化するため以下のコマンドを実行しておきます。

$ chgrp -R <group_id> /work/<group_id>/$USER
$ find /work/<group_id>/$USER -type d | xargs chmod g+s
  • wisteria における必須事項: wisteria では、計算処理を実行するノード（計算ノード）から /home ディレクトリに対して直接アクセスできない仕様となっています。そのため、プログラムファイルや Python の仮想環境はすべて /work ディレクトリの下に配置してください。

3. ※重要：ログインノードで重い処理を回さないこと

SSH接続した直後のサーバー（ログインノード）は、すべてのユーザーが共同で使用する窓口です。ここでは高負荷な処理を直接実行してはいけません。 プログラムの実行や、時間のかかる環境構築（コンパイル等）は、必ずジョブ（計算ノード）を確保して実行させてください。

4. データの転送方法 (rsync / scp)

小規模なスクリプトの転送であれば VSCode 上のドラッグ＆ドロップで十分ですが、大規模なデータやファイルを転送する場合はコマンドを使用します。

Onpremise から スパコンへデータ転送する (rsync)

データシステムの整合性を崩さないよう、ファイルの所有者情報などを意図せず引き継がないオプション（-rt 等）を使用します。

# Onpremiseのシェルで実行
$ rsync -rthz --no-i-r --info=progress2 <source_directory_or_file> <username>@<HPC_HostName>:<destination_path>
  • -rt: 所有者情報以外のファイル基本情報のみを引き継ぎます（所有者情報をスパコン側に無理やり引き継ぐと、ファイルのクォータ制限で容量上限に引っかかる可能性があります）。
  • -h: サイズを読みやすい単位で出力。
  • -z: データを圧縮して転送。
  • 注意: ディレクトリパスの末尾にスラッシュ（/）を付けると中身がそのまま転送先に展開され、付けない場合はディレクトリごと転送先に配置されます。

Windows等ローカルPCからスパコンへの転送 (scp)

$ scp -rC <source_path> <username>@<HPC_HostName>:<destination_path>

5. ジョブ実行の設定方法

スパコンでは、計算キュー（リソースグループ）の指定やリソースの確保を、ジョブスクリプト（.sh）の先頭に特定のコメント行として記述します。

miyabi-g でのジョブスクリプト指定例 (#PBS)

#!/bin/bash
#PBS -q debug-mig              # 使用するキュー (debug-mig, regular-g 等)
#PBS -l select=1               # 使用するノード数 (基本は1)
#PBS -W group_list=<group_id>  # 使用するグループID
#PBS -o make_env.out           # 標準出力ログファイル
#PBS -e make_env.err           # 標準エラーログファイル

wisteria Aquarius でのジョブスクリプト指定例 (#PJM)

#!/bin/bash
#PJM -L rscgrp=share-debug     # リソースグループ (share, share-debug 等)
#PJM -L gpu=1                  # 使用するGPU数
#PJM -g <group_id>             # グループID
#PJM -o make_env.out
#PJM -e make_env.err

6. 必要モジュールのロードと CPU アーキテクチャ

スパコンでは、各ジョブや構築時に必要なライブラリ・ツール群を module load コマンドで読み込みます。

代表的なモジュールのロード例

  • miyabi-g 用 
    module purge
module load gcc/11.4.1 cmake/3.31.1 ompi/4.1.6 cuda/12.4 cudnn/9.5.1.17 nccl/2.23.4
  • wisteria 用 
    module load gcc/8.3.1 cmake/3.28.4 ompi/4.1.1 cuda/12.2 cudnn/8.9.4 nccl/2.18.5

アーキテクチャの違いに関する注意

ログインノードと各計算ノードで CPU のアーキテクチャが異なる場合があります（例: aarch64 と x86_64）。 異なるアーキテクチャ間でビルドされた Python やライブラリ、仮想環境は共有できません。 異なるノード向けに環境を作る場合は、ディレクトリ名や環境設定を明確に分ける（別の .bashrc を用意するなど）ように管理してください。

7. おまけ：Singularity環境の利用

スパコン環境では管理者権限を必要としないコンテナプラットフォーム Singularity（または Apptainer）を利用して、独自の環境を定義・実行できます。

  • Dockerfile に対応するのが .def（定義ファイル）
  • Dockerイメージ に対応するのが .sif（コンテナイメージファイル）

ビルドと実行の流れ

  1. Singularity モジュールをロードします。
    • miyabi: module load singularity/4.2.1
    • wisteria: module load singularity/3.7.3
  2. 定義ファイルから .sif イメージをビルドします（計算ノード上で実行します）。 
    $ singularity build --fakeroot my_env.sif my_env.def
  3. コンテナ内でコマンドを実行します。 
    $ singularity exec --nv --fakeroot my_env.sif python scripts/train.py

[!NOTE] コンテナ起動時のディレクトリのバインド
スパコンのシステムごとに、ホストのホームディレクトリやカレントディレクトリがコンテナ内のどこに自動バインドされるか挙動が異なります。安全のため、パスの記述は ~/ などのホームディレクトリ基点にするか、絶対パスを使用してください。

Tags

#linux #ssh #slurm #singularity