スーパーコンピュータシステムの基本的な利用方法
本ページでは、本スーパーコンピュータシステムの基本的な使用方法についてご説明します。
スーパーコンピュータシステムはハードウェア構成で記述したハードウェアで構成されます。このハードウェアについて多数ユーザが効率的に共用できるようジョブ管理システムUGE(Univa Grid Engine)を利用してシステム利用環境を構築しています。 環境は以下の構成要素で構成されます。
ゲートウェイノード
インターネットから本システムに接続する為のノードです。システム利用の為にシステム外からまずこのノードにログインします。
ログインノード
ユーザがプログラム開発や、ジョブ管理システムにジョブの投入を行う為のノードです。ゲートウェイノードからqloginコマンドでログインします。 システム内に複数台存在し、ユーザはログイン時に負荷状況の低いログインノードに割り振られてログインします。
計算ノード
ジョブ管理システムの管理下にあってユーザから投入されたジョブを実行する為のノードです。計算機の種別によりThin計算ノード、Medium計算ノード、 Fat計算ノードがあります。
キュー
UGE上の概念で、計算ノードを論理的にグループ化するものです。キューを指定してジョブの実行をUGEに対して指示すると、指定した条件に合致するように 自動的に計算ノード上で計算が実行されます。キューには後述のように複数種類があります。具体的な利用方法については後述します。
これらの構成要素の関連を示したシステム利用の概略図を示します。
ではシステムの基本的な利用方法について順を追ってご説明します。
システムへのログイン
まずゲートウェイノードにssh経由でゲートウェイノード(gw.ddbj.nig.ac.jp)にログインして頂きます。お手元の端末で利用可能なsshクライアントソフトを各自ご用意頂き接続をお願いします。認証方法はパスワード認証です。
・Phase3システムゲートウェイ ⇒ gw.ddbj.nig.ac.jp
ゲートウェイノードは システム外部からの入口であり、このノード上では計算の実行およびプログラムの編集処理を実行することは禁止されており 、環境設定もされていません。その点ご注意ください。 ゲートウェイノードにログインできたら、そのままログインノードへ以下の手順に従ってログインをして下さい。
ログインノードへのログイン
UGEのコマンドである、qloginを使用します。 以下のようにします。
[username@gw1 ~]$ qlogin Your job 80308 ("QLOGIN") has been submitted waiting for interactive job to be scheduled ... Your interactive job 80308 has been successfully scheduled. Establishing /home/geadmin/UGER/utilbin/lx-amd64/qlogin_wrapper session to host at028 ... Last login: Tue Feb 26 13:55:12 2019 from gw1
qloginを利用すると、qloginが複数のログインノードの負荷情報を確認し負荷が低いログインノードを自動的に選択しますので、そのまま選択されたノードにログインします。 (上の例では、このログインセッション自体がインタラクティブジョブ(JobID 80308)として認識され、計算ノードat028が選択されてログイン処理が行われています。) この時にログインしたログインノード上でqstatコマンド(後述)を実行すると、
[username@at028 ~]$ qstat job-ID prior name user state submit/start at queue jclass slots ja-task-ID ------------------------------------------------------------------------------------------------------------------------------------------------ 80308 0.50000 QLOGIN username r 02/27/2019 16:03:29 login.q@at028 1
というように今qloginでログインしたログインセッションがUGE管理下のジョブとして確認できます。 ログインノード上では各種開発環境、スクリプティング言語環境が用意されています。開発作業を行う場合は、そのままログインノード上で作業を行ってください。ここでログインノード上では、大規模な計算処理を実行しないでください。必ずUGEに計算ジョブを投入することで計算ノード上で実行するようにしてください。
GPGPU開発環境を利用したプログラム開発を行う為にGPGPUを搭載したログインノードを用意しています。当該ノードにログイン したい場合は、ゲートウェイノード上でqloginを行う場合に
qlogin -l gpu
と、-l オプションでgpuを指定してください。これでGPGPUを搭載したログインノードにログインができます。
次に計算ノードへのジョブの投入方法についてご説明します。
計算ジョブの投入
現在のバージョンのUGEでは、PATH等の環境変数はジョブ実行時の環境に引き継がれません。必要な環境変数は、ジョブスクリプト内で設定していただけますようお願いします。
計算ノードに計算ジョブを投入するには、qsubコマンドを利用します。qsubコマンドでジョブを投入する為には、投入するジョブスクリプトを作成する 必要が有ります。簡単な例ですが以下のように記述します。
#!/bin/sh #$ -S /bin/sh export PATH=${PATH}:/path/to/execfiles export LD_LIBRARY_PATH=/path/to/libfiles:${LD_LIBRARY_PATH} pwd hostname date sleep 20 date echo “to stderr” 1>&2
この時、行の先頭に、"#$"が指定されている行が、UGEへのオプション指示行になります。オプション指示行をシェルスクリプトにする、またはqsubコマンド 実行時のオプションとして指定することでUGEに動作を指示します。主なオプションとしては以下のものがあります。
指示行の記述 | コマンドラインオプション指示 | 指示の意味 |
---|---|---|
#$ -S インタプリタパス | -S インタプリタパス | コマンドインタプリタをパス指定する。シェル以外のスクリプト言語も指定可能。このオプションは指定必要 |
#$ -cwd | #$ -cwd | ジョブ実行のカレントワーキングディレクトリを指定する。これによりジョブの標準出力、エラー出力もcwd上に出力される。 指定しない場合はホームディレクトリがカレントワーキングディレクトリとなりジョブ実行される。 |
#$ -N ジョブ名 | -N ジョブ名 | ジョブの名前を指定する。この指定が無ければスクリプト名がジョブ名になる。 |
#$ -o ファイルパス | -o ファイルパス | ジョブの標準出力の出力先を指定する。 |
#$ -e ファイルパス | -e ファイルパス | ジョブの標準エラー出力の出力先を指定する。 |
qsubには上記の他にも指定可能なオプションが多数ありますので、詳細についてはシステムにログイン後"man qsub"として、qsubコマンドの オンラインマニュアルを参照して確認してください。
ジョブ投入時のキューの選択について
ソフトウェア構成でもご説明している通り、本システムでは以下のキューを設定しています(2019年3月現在)。
キューの選択は、qsubコマンドの-lオプションで可能です。
各キューを指定して投入したい場合は下表の「キュー指定のオプション」を指定してqsubを実行してください。何も指定しなければ、
epyc.qに投入されます。
ただし、epyc.qのリソースに空きがなかった場合、Thinノードで構成された他のキュー(intel.q、gpu.q)に空きがあれば、そちらのキューに
割り当てられます。
Phase3システム 2019年3月導入
キュー名 |
ジョブスロット数
(キュー全体)
|
ジョブスロット数
(ノード当たり)
|
メモリ
(キュー全体)
|
メモリ
(ノード当たり)
| 実行時間の上限 | 用途 | キュー指定のオプション |
---|---|---|---|---|---|---|---|
epyc.q | 4,224 | 64 | 33.792TB | 512GB | 62日 | 実行時間2ヶ月間で他にリソース要求が無い時 | 指定なし または -l epyc |
intel.q | 1,472 | 32 | 17.664TB | 384GB | 62日 | Intel Xeonを使用 | -l intel |
gpu.q | 384 | 8 | 2.688TB | 192GB | 62日 | GPUを使用 | -l gpu -l cuda=n (nは1-4の整数) 詳細はこちらをご覧ください。 |
medium.q | 800 | 80 | 30TB | 3TB | 62日 | Medium計算ノードを使用 | -l medium |
login.q | 258 | 64 | 3.072TB | 512GB | 無期限 | ゲートウェイノードからqloginする際に利用 AMD CPU搭載ノードのみ |
|
login_gpu.q | 48 | 24 | 768GB | 384GB | 無期限 | GPU、Intel CPUを使用する際にqloginして利用 | -l gpu |
short.q | 744 | 16 | 2.688TB | 192GB | 3日 | 短時間ジョブ向け | -l short |
例えば、Thin計算ノードのintel.qにtest.shというジョブを投入したければ、以下のようにコマンドを投入します。
qsub -l intel test.sh
また、例えば、Medium計算ノードにtest.shというジョブを投入したければ、以下のようにコマンドを投入します。
qsub -l medium test.sh
但し、構成として、GPGPUを搭載しているノードは、SSDも搭載しており、SSDを搭載しているノードはHDDも搭載しているので、SSDを利用する為の キューのスロットが一杯になっていれば、ジョブはGPUのキューに流れるように設定されています。また、HDDのキューが一杯であれば、その時に投入した ジョブは、SSDのキューに投入されるように設定されています。その点ご注意ください。
ジョブの実行上限時間の指定について
ジョブ投入時は、qsubコマンドの -l d_rt オプションおよび、-l s_rt オプションでジョブの実行上限時間を指定してください。
-l d_rt オプションおよび、-l s_rt オプションには同じ値を指定してください。
なお、-l d_rt オプションおよび -l s_rt オプションに指定できる上限値はキューの実行時間の上限までです。
ジョブの標準実行上限時間は3日であるため、-l d_rt オプションおよび -l s_rt オプションを指定しなかった場合、ジョブは3日で終了します。
コマンド実行例
ジョブの投入時にジョブの実行上限時間に192時間(8日×24時間)を指定して実行する。( -l d_rt オプション、 -l s_rt オプションを指定して実行する。)
qsub -l d_rt=192:00:00 -l s_rt=192:00:00 test.sh
ジョブの投入状況の確認
qsubで投入したジョブがジョブとして投入されたかを確認します。投入したジョブの状態確認にはqstatコマンドを利用します。例えばジョブが 投入されていたとすれば以下のように表示されます。
[username@at027 ~]$ qstat job-ID prior name user state submit/start at queue jclass slots ja-task-ID ------------------------------------------------------------------------------------------------------------------------------------------------ 80312 0.50000 QLOGIN username r 02/27/2019 17:42:00 login.q@at027 1 80313 0.25000 jobname username r 02/27/2019 17:44:30 epyc.q@at040 1 80314 0.25000 jobname username r 02/27/2019 17:44:35 epyc.q@at040 1 80315 0.25000 jobname username r 02/27/2019 17:44:40 epyc.q@at040 1
この時、"state"欄の文字の意味は以下のようになります。
文字 | 意味 |
---|---|
r | ジョブ実行中 |
qw | ジョブはキューで待機中 |
t | ジョブは実行ホストへ転送処理中 |
E | ジョブにエラーが発生 |
d | ジョブは削除処理中 |
また、キューの利用状況を確認したい場合は、"qstat -f"と入力します。以下のような出力が出力されます。
[username@at027 ~]$ qstat -f queuename qtype resv/used/tot. np_load arch states --------------------------------------------------------------------------------- medium.q@m01 BP 0/0/80 0.00 lx-amd64 --------------------------------------------------------------------------------- medium.q@m02 BP 0/0/80 0.00 lx-amd64 --------------------------------------------------------------------------------- medium.q@m03 BP 0/0/80 0.00 lx-amd64 --------------------------------------------------------------------------------- medium.q@m04 BP 0/0/80 0.00 lx-amd64 (中略) --------------------------------------------------------------------------------- epyc.q@at033 BP 0/0/64 0.00 lx-amd64 --------------------------------------------------------------------------------- epyc.q@at034 BP 0/0/64 0.00 lx-amd64 --------------------------------------------------------------------------------- epyc.q@at035 BP 0/0/64 0.00 lx-amd64 (中略) --------------------------------------------------------------------------------- intel.q@it003 BP 0/0/32 0.00 lx-amd64 --------------------------------------------------------------------------------- intel.q@it004 BP 0/0/32 0.00 lx-amd64 --------------------------------------------------------------------------------- intel.q@it005 BP 0/0/32 0.00 lx-amd64 --------------------------------------------------------------------------------- intel.q@it006 BP 0/0/32 0.00 lx-amd64 --------------------------------------------------------------------------------- (以下略)
これにより、どのノード(キュー)にジョブが投入されているかを判別することができます。
また、 各キューのジョブの投入状況、キューの負荷状況等、全体を把握するのには、"qstat -g c"として確認することが 出来ます。
[username@at027 ~]$ qstat -g c CLUSTER QUEUE CQLOAD USED RES AVAIL TOTAL aoACDS cdsuE -------------------------------------------------------------------------------- epyc.q 0.00 0 0 4160 4224 0 64 gpu.q 0.00 0 0 64 112 0 48 intel.q 0.00 0 0 1472 1472 0 0 login.q 0.00 1 0 383 384 0 0 login_gpu.q 0.00 0 0 48 48 0 0 medium.q 0.00 0 0 800 800 0 0 short.q 0.00 0 0 128 224 0 96
また、"qstat -j ジョブID"とすることで、ジョブの詳細情報を取得することができます。
[username@at027 ~]$ qstat -j 199666 ============================================================== job_number: 199666 jclass: NONE submission_time: 02/27/2019 17:42:00.867 owner: username uid: 9876 group: ddbj gid: 9876 supplementary group: ddbj sge_o_home: /home/username sge_o_log_name: username sge_o_path: /cm/local/apps/gcc/7.2.0/bin:/home/geadmin/UGER/bin/lx-amd64:/cm/local/apps/environment-modules/4.0.0//bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/ibutils/bin:/sbin:/usr/sbin:/cm/local/apps/environment-modules/4.0.0/bin:/home/username/.local/bin:/home/username/bin sge_o_shell: /bin/bash sge_o_workdir: /lustre8/home/username sge_o_host: gw1 account: sge stderr_path_list: NONE:NONE:/dev/null hard resource_list: d_rt=259200,mem_req=8G,s_rt=259200,s_stack=10240K,s_vmem=8G soft resource_list: epyc=TRUE,gpu=TRUE,intel=TRUE,login=TRUE mail_list: username@gw1 notify: FALSE job_name: QLOGIN stdout_path_list: NONE:NONE:/dev/null priority: 0 jobshare: 0 restart: n env_list: TERM=xterm department: defaultdepartment binding: NONE mbind: NONE submit_cmd: qlogin category_id: 4 request_dispatch_info: FALSE start_time 1: 02/27/2019 17:42:00.884 job_state 1: r exec_host_list 1: at027:1 granted_req. 1: mem_req=8.000G usage 1: wallclock=01:00:01, cpu=00:00:00, mem=0.00000 GBs, io=0.00000 GB, iow=0.000 s, ioops=0, vmem=N/A, maxvmem=N/A scheduling info: -
また、実行状況を確認していて、ジョブの状況が異常でジョブの終了を待たずにただちに削除したい場合はqdelコマンドを使用します。 "qdel ジョブID"とします。自分が投入しているジョブをすべて削除したい場合は、"qdel -u ユーザ名"とすることで実行可能です。
結果の確認
ジョブの結果は、ファイル名がジョブ名.oジョブIDのファイルににジョブの標準出力、ファイル名がジョブ名.eジョブIDのファイルにジョブの標準エラー出力 が出力されています。ファイルをご確認ください。また実行したジョブがどのぐらいのリソースを利用したか等の詳細情報については、qacctコマンドで確認することができます。
[username@at027 ~]$ qacct -j 199666 ============================================================== qname intel.q hostname it003 group lect owner username project NONE department defaultdepartment jobname jobscript.sh jobnumber XXXXX taskid undefined pe_taskid NONE account sge priority 0 cwd NONE submit_host at027 submit_cmd qsub -l intel jobscript.sh qsub_time 02/27/2019 18:49:09.854 start_time 02/27/2019 18:49:15.069 end_time 02/27/2019 18:49:35.128 granted_pe NONE slots 1 failed 0 deleted_by NONE exit_status 0 ru_wallclock 20.059 ru_utime 0.016 ru_stime 0.034 ru_maxrss 10220 ru_ixrss 0 ru_ismrss 0 ru_idrss 0 ru_isrss 0 ru_minflt 9181 ru_majflt 2 ru_nswap 0 ru_inblock 344 ru_oublock 32 ru_msgsnd 0 ru_msgrcv 0 ru_nsignals 0 ru_nvcsw 108 ru_nivcsw 18 wallclock 20.108 cpu 0.051 mem 0.001 io 0.000 iow 0.000 ioops 1277 maxvmem 228.078M maxrss 0.000 maxpss 0.000 arid undefined jc_name NONE bound_cores NONE
高速領域(Lustre領域)の使用方法
Lustre構成
本スーパーコンピュータシステムではユーザホームディレクトリをLustre File Systemで構成されたファイルシステム上に構築しています。Lustreファイルシステムは、主に大規模なスーパーコンピュータシステムで利用される並列ファイルシステムです。
本システムでは、Phase2(2018年3月)にMDS(後述)2台、OSS(後述)4台、OST(後述)41セットで構成したlustre6を、Phase3(2019年3月)でMDS(後述)2台、OSS(後述)4台、OST(後述)54セットで構成したlustre7、lustre8の2ファイルシステム導入しました。
ファイルシステム | 導入時期 | 容量 | mds | oss | ost |
---|---|---|---|---|---|
lustre6 | 2018/3/1 | 3.8PB | 2 | 4VM on SFA14KXE | 41 x RAID6(8D+2P) |
lustre7 | 2019/3/1 | 5.0PB | 2 | 4VM on SFA14KXE | 54 x RAID6(8D+2P) |
lustre8 | 2019/3/1 | 5.0PB | 2 | 4VM on SFA14KXE | 54 x RAID6(8D+2P) |
Lustreの構成要素
Lustre File Systemは、概略で示すとObject Storage Server(OSS)と呼ばれるIOサーバと、Object Storage Target(OST)と呼ばれるディスク装置と、ファイルのメタデータ を管理するMetaData Server(MDS)と呼ばれるサーバを構成要素として成り立ちます。各コンポーネントの説明を下表に記述します。
コンポーネント | 用語説明 |
---|---|
Object Storage Server(OSS) | OST(後述)を管理し、ネットワークからのOSTに対するIO要求を制御します。 |
Object Storage Target(OST) | ブロックストレージデバイスで、ファイルデータを格納する装置です。一つのOSTは一つの仮想ディスクと考えられ、複数の物理ディスク から構成されます。ユーザデータは一つ以上のオブジェクトとして、一つ以上のOSTに格納されます。1ファイルあたりのオブジェクト数は設定変更が可能で、これをチューニング することでストレージのパフォーマンスの調整を行うことができます。 |
Meta Data Server(MDS) | 1つのLustreファイルシステムに1台(本構成ではHA構成の2台)のサーバで構成され、ファイルシステム内でファイルが割り当てられているオブジェクトの位置情報、ファイル属性情報を管理し、 ファイルIO要求を適切なOSSに誘導します。一旦ファイルIOが開始されれば、MDSは、そのファイルIOに関与せず、クライアントとOSS間で直接データ 転送が行われます。この為Lustre File Systemは高いIO性能を持つことが可能となっています。 |
Meta Data Target(MDT) | Lustreファイルシステム内のファイルのメタデータ(ファイル名、ディレクトリ、ACL等)を格納するストレージデバイスです。MDSに接続されます。 |
ファイルストライピングについて
Lustreの特長は、1つのファイルを複数のセグメントに分割し、これを複数のOST上に分散して格納できることです。この機能をファイルストライピング(file striping)と呼びます。 ファイルストライピングのメリットは、一つのファイルが複数のOST上に分割して格納される為、それに対してクライアントから並列にread/writeを実行可能で、大容量のファイルについては 高速にread/writeができることです。 しかしファイルストライピングにはデメリットもあります。ファイルは複数のOST上に分散される為、分散したデータのハンドリングのオーバーヘッドが増大することです。 この為、一般にストライプサイズ、ストライプカウントを変更して有効と考えられるのは、
対象となるファイルサイズが数GBであるとき。
等です。Lustreはメタデータは、MDSで一元管理される為、メタデータ操作(ls -lや大量の小サイズファイルの作成等)を伴うファイル操作は、MDSに負荷が 集中し、ローカルファイルシステム上の同等操作に比較して高速ではありません。その点に注意し、同一ディレクトリ上に数万の 小サイズのファイルを置くなどの操作は避けて頂きたくお願い致します(そのような場合は複数のディレクトリに分けて格納したほうが良い。)。
ホームディレクトリの使用状況の確認
ユーザの現在のホームディレクトリの使用状況は、"lfs quota"コマンドで確認することができます。
[username@at031 ~]$ lfs quota -u username ./ Disk quotas for usr username (uid 9876): Filesystem kbytes quota limit grace files quota limit grace ./ 359743396 0 0 - 5250 0 0 -
項目 | 意味・説明 |
kbyte | 使用中のファイル容量(KB) |
quota | ファイル容量/数の制限値(ソフトリミット) |
limit | ファイル容量/数の絶対制限値(ハードリミット) |
grace | 制限値越えの許容期間 |
files | 使用中のファイル数 |
ファイルストライプの設定方法
以下の手順で実施してください。まず、現状のストライプカウントを確認します。システムデフォルトは1になっています。 "lfs getstrip 対象ファイル(ディレクトリ)"で確認することができます。
[username@at031 ~]$ ls -ld tmp drwxr-xr-x 2 username lect 4096 Feb 22 00:51 tmp [username@at031 ~]$ lfs getstripe tmp tmp stripe_count: 1 stripe_size: 1048576 stripe_offset: -1
ストライプの設定は、"lfs setstripe"コマンドで設定することができます。
オプション名 | 説明 |
-c | ストライプ数、ストライプ幅を設定します。 |
-o | オフセットを指定します。 |
-s | ストライピングサイズを指定します |
ログインノード上でのXクライアントの利用方法
ログインノード上でX-Window Clientを利用する場合は、Windows 上の場合は、対応したX-Window サーバエミュレータをユーザ側でご用意下さい。
Macの場合は、 Xcode Toolsのなかに、X11 SDKがありますので、これをインストールしてX11を利用可能にしてください。