マイLab手帖

普段はサイエンス業界でSRE的な仕事をやっています。主に自宅環境でのハンズオンの備忘録。

Slurm Installその後3.リソース制限 QoS

Slurm HPC Configuration

はじめに

前回の続きで、Slurmのリソース制限の方法をやっていこうと思います。

目次
前回

前回はassociationを用いて以下のような制限をやってみました。

associationを用いた制限
・ userレベル
・ accountレベル
・ account同士の親子(Parent/Child)関係で制限適用

taqqu.hatenablog.com

今回

association以外の制限の方法として「QoS」という機能がSlurmにはあります。 今回はこちらをみていきます。

QoSとは？

Quality of Serviceの略。

Quality of Service - Wikipedia
「引用」『フリー百科事典　ウィキペディア日本語版』より。 2022年4月25日 (月) 02:22 UTC
URL：Quality of Service - Wikipedia

このあたりは門外漢なのですが、もともとはコンピュータ・ネットワークの世界から標準的なワードとして広まったんでしょうか？？限られたコンピューティング・リソースを差別/優先して（サービス品質）、効率・安定的に利用者に供給する仕組みのようです。

世の中のたくさんの人々がコンピューティング・リソースを消費しあう訳なので、このような考え方が必要な事はなんとなく理解できますね。

↓一例ですが、ネットワーク以外にもQoSは色んな所で登場するようです。

  • 仮想ストレージ　→　IOや転送レートなど性能レベル制御
  • Kuberneters　→　Podの利用リソース制御、QoS Class
SlurmにおけるQoS

公式 Slurm Workload Manager - Quality of Service (QOS)

さきほど述べたQoSと似た概念として捉えておおむね問題なさそうです。Slurmで扱う制限をQoSとして指定することでジョブの実行リソースを制限していく仕組みのようです。

また「制限」の話から文脈は逸れますが、Slurmのジョブスケジューリング「優先付け(priority)」においてもQoSは優先順決定要因の中の一つとして登場するようです。 （こちらについてはまた勉強したら）

QoSの設定について

QoSは、Slurmで制限できる項目を「セット」にして作成する事ができます。

作成したQoSは以下に対して指定する事が出来ます。

  • partition

  • job (sbatch / salloc / srun、を実行時に--qos=で指定)

  • association (user / account / root)

リソース制限指定の優先

Slurmのリソース制限の適用には、適用の優先順があらかじめ決まっていて、次の1から順番に優先されていきます。

Slurm Workload Manager - Resource Limits

  1. Partition QOS limit
  2. Job QOS limit
  3. User association
  4. Account association(s), ascending the hierarchy
  5. Root/Cluster association
  6. Partition limit
  7. None

前回の記事(https://taqqu.hatenablog.com/entry/2022/09/10/174507)では、この優先順でいうところの3(User association)と4(Account association(s))を既に設定したことになります。

※ちなみに「Jobの実行時にオプションで'OverPartQOS' フラグをつけてPartition QoSと優先順位を逆転させる」ような事も可能だとか。

QoS設定をやってみる

では、実際にQoSを設定していきたいと思います。

前回まではassociationに対して、sacctmgr modify account/user <name> set <limits>にように直接制限を付与する事をやりました。

前回の制限内容
[slurm@master ~]$ sacctmgr show associations format=account,user,GrpJobs,GrpSubmitJobs
   Account       User GrpJobs GrpSubmit 
---------- ---------- ------- --------- 
      root                              
      root       root                   
      root      slurm                   
 chemistry                  1         2 
 chemistry       john                   
chemistry+                              
chemistry+        tom
  • account -> "chemistry" にたいしてGrpJobs=1, GrpSubmit=2を設定
[slurm@master ~]$ sacctmgr show association format=account,Parentname
   Account ParentName 
---------- ---------- 
      root            
      root            
      root            
 chemistry       root 
 chemistry            
chemistry+  chemistry 
chemistry+

でした。

今回は、QoSを新規作成してみてから、これら（前回作成済）の制限とで、適用優先関係も簡単にみていければと思います。

今回の制限内容

具体的にはですが、前回作成したassociation(account)の制限より優先が高くなるか？をみたいので、以下の順番でみていきたいと思います。

QoSをまず作成してから、

  1. account/assosiation よりJob QoSが優先されるか?
  2. account/assosiation & Job QoSよりpartition QOSが優先されるか？
イメージ

イメージの黄色塗り部分がQoSです。順に作成して、挙動をみていきます。

QoS優先イメージ

QoS設定前の動作確認

QoS作成前の動作をみておきましょう。前回記事の最後のsubmitのおさらいになります。

john( account : chemisty)で実行

[john@node1 ~]$ sbatch test.sh 
Submitted batch job 131
[john@node1 ~]$ sbatch test.sh 
Submitted batch job 132
[john@node1 ~]$ sbatch test.sh 
sbatch: error: AssocGrpSubmitJobsLimit
sbatch: error: Batch job submission failed: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits)

→3回目の実行でerrorになります。GrpSubmitJobs=2が効いてsubmit(sbatch実行)が3回目でエラー

squeueで確認

[slurm@master ~]$ squeue 
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               132 partition     test     john PD       0:00      1 (AssocGrpJobsLimit)
               131 partition     test     john  R       0:08      1 node3

→2回目の実行(ID=132)はSubmitはされたものの、GrpJobs=1が効いて保留(ST=PD)になっている事がわかります。

はい、という事でこれからQoSを設定して挙動の変化をみていきます。

QoS設定

それではQoSを設定していきます。

slurm.confファイル

まずは/etc/slurm/slurm.confを確認すると（前回続きから）現状はlimitsになっています。

AccountingStorageEnforce=limits

ここで再度AccountingStorageEnforceについて確認しておきます。

設定例 内容
associations associaionsがデータベース(slurmdbd)に登録されていない場合、ユーザーはジョブ実行できない。associations登録がない＝ユーザーは無効なアカウント扱い。
qos すべてのジョブが有効な QoS (Quality of Service) を指定することが、デフォルトで明示的に要求される。QoS値はデータベース内の各associationsに対して定義されます。このオプションを設定すると'associations'オプションが自動的に設定。QoSで制限を実施したい場合は、'limits' オプションを使用する必要があります。
limits associationsに設定された制限が強制される。このオプションを設定すると、'associations' オプションも設定されます。
nojobs ジョブ情報をDB保存しない場合に設定
nosteps ジョブステップ情報をDB保存しない場合に設定

※全部ではありません。他にも,safe,wckeys...といった設定値があります


→limitsのままだとQoSは制限されてしまいますので、qosを追加しておきます。（slurm.confの再配布とslurmctld、slurmdの再起動も忘れずに）

#AccountingStorageEnforce=0
#AccountingStorageEnforce=associations
#AccountingStorageEnforce=limits
AccountingStorageEnforce=limits,qos
QoSの作成 (job)

次にQoSの作成です。これまでも出てきたsacctmgrコマンドを使います。

まずはJob QoSとして、以下の通り作成します。名前「job_qos」は適当です。

[slurm@master ~]$ sacctmgr add qos job_qos
 Adding QOS(s)
  job_qos
 Settings
  Description    = job_qos
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y

次に、イメージに書いたように、QoS「job_qos」に対してGrpJobs=2, GrpSubmitJobs=3を設定します。 （associationsの制限時からjob、submitそれぞれ上限数を+1）

[slurm@master ~]$  sacctmgr modify qos job_qos set GrpJobs=2 GrpSubmitJobs=3
 Modified qos...
  job_qos
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y

結果を確認してみます。

[slurm@master ~]$ sacctmgr show qos format=name,GrpJobs,GrpSubmitjobs
      Name GrpJobs GrpSubmit 
---------- ------- --------- 
    normal                   
   job_qos       2         3

設定できていそうですね。

動かしてみる

Job QoS

それではさきほど作成した制限(QoS)で「GrpJobs,GrpSubmitjobs」これまでの制限(associations)より優先されるか見ていきましょう。

submit数と実行数がそれぞれ１づつ増えていればOKという事になります。

Jobの実行時に（submit）でQoSを指定しますので、sbatchにオプション--qos=job_qosをつけて実行します。

[john@node1 ~]$ sbatch --qos=job_qos test.sh
sbatch: error: Batch job submission failed: Invalid qos specification

Invalid qos specificationとエラーになりました。

このままだとどうやらjohnがQos(job_qos)を利用できないようで、以下のように所属するaccount/associationの"chemistry"にQosをセットする必要がありました。

[slurm@master ~]$ sacctmgr modify account chemistry set qos=job_qos
 Modified account associations...
  C = sample-cluster A = chemistry of root
  C = sample-cluster A = chemistry_japan      U = tom      
  C = sample-cluster A = chemistry            U = john     
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y

※ 以下のようにjohn(user/association)にQoSを設定する方法でも大丈夫でした。

sacctmgr modify user john set qos=job_qos

どちらに設定するのかは管理ポリシーに依るところかも知れません。



では気を取り直して、再度実行(submit)します。

[john@node1 ~]$ sbatch --qos=job_qos test.sh
Submitted batch job 254
[john@node1 ~]$ sbatch --qos=job_qos test.sh
Submitted batch job 255
[john@node1 ~]$ sbatch --qos=job_qos test.sh
Submitted batch job 256
[john@node1 ~]$ sbatch --qos=job_qos test.sh
sbatch: error: QOSGrpSubmitJobsLimit
sbatch: error: Batch job submission failed: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits)

→4回目の実行でerrorになります。GrpSubmitJobs=3が効いてsubmit(sbatch実行)が4回目でエラーです。QoS設定前より上限が+1され、出力の"QOSGrpSubmitJobsLimit"のメッセージからも今回設定したQoSが優先されている事がわかります。

squeueで確認

[slurm@master ~]$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               256 partition     test     john PD       0:00      1 (QOSGrpJobsLimit)
               254 partition     test     john  R       0:10      1 node3
               255 partition     test     john  R       0:10      1 node3

→こちらも2回目の実行までRUNしました（ID=255）。QoS設定前より上限が+1されたGrpJobs=2が効いて3回目の実行(ID=256)は保留になっている事がわかります。

Job QoSがaccount/associationでの制限より優先された事がわかりました。

補足ですが、一応ユーザtomでも実行しておきます。

[tom@node1 ~]$ sbatch --qos=job_qos test.sh 
Submitted batch job 260
[tom@node1 ~]$ sbatch --qos=job_qos test.sh 
Submitted batch job 261
[tom@node1 ~]$ sbatch --qos=job_qos test.sh 
Submitted batch job 262
[tom@node1 ~]$ sbatch --qos=job_qos test.sh 
sbatch: error: QOSGrpSubmitJobsLimit
sbatch: error: Batch job submission failed: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits)

→GrpSubmitJobs=3が効いていますね。Child accountでも同様にQoSが適用されているようです。squeueは割愛します。


では次にこのJob QoSよりpartition QOSが優先されるか？を見ていきます。

QoS設定

ではPartition QoSを設定していきます。 GrpSubmitJobs=0だけを設定して、Partitionでジョブが実行できないようにするイメージです。

QoSの作成(partition)

先程と同じやりかたで、sacctmgrコマンドでQoSを作成していきます。「part_qos」

[slurm@master ~]$ sacctmgr add qos part_qos
 Adding QOS(s)
  part_qos
 Settings
  Description    = part_qos
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y

さらに、イメージに書いたようにQoS「part_qos」に対してGrpSubmitJobs=0を設定します。（submitできなくする）

[slurm@master ~]$ sacctmgr modify qos part_qos set GrpSubmitJobs=0
 Modified qos...
  part_qos
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y

結果を確認してみます。

[slurm@master ~]$ sacctmgr show qos format=name,GrpJobs,GrpSubmitjobs
      Name GrpJobs GrpSubmit 
---------- ------- --------- 
    normal                   
   job_qos       2         3 
  part_qos                 0
PartitionへのQoS設定

partitionにQoSを設定したい場合は、/etc/slurm/slurm.confに直接記載する事ができます。

今回のjobはpartition2を使うようにしているので、slurm.confのpartition2の定義にQos=part_qosを追加します。（slurm.confの再配布とslurmctld、slurmdの再起動も忘れずに）

PartitionName=partition2 Nodes=node[3-4] Default=YES MaxTime=INFINITE State=UP Qos=part_qos

動かしてみる

Partition QoS

では、Jobを実行します。

[john@node1 ~]$ sbatch test.sh
sbatch: error: QOSGrpSubmitJobsLimit
sbatch: error: Batch job submission failed: Job violates accounting/QOS policy (job submit limit, user's size and/or time limits)

→先ほどまでは3回までsubmitできましたが、1回目から実行エラーがでます。GrpSubmitJobs=0がちゃんと効いていますね。

squeueで確認

[slurm@master ~]$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)

→submitできないので当然の結果ですね。

そしてPartition QoSの場合は、user/account/associationに対してQoSをセットする必要も無かったようです。

という事で、Partition QoSはとてもシンプルにやってしまいましたが、Job QoSよりpartition QOSが優先される事が確認できました。


最後に

今回は、

  • QoSを用いたSlurmの制限
  • (前回作成した)account/associationと今回作成したQoS(job)との優先
  • QoS(job)とQoS(partition)の優先

をやってみました。

Slurmの制限は、今回使用した「GrpJobs」「GrpSubmitJobs」のような制限項目の単位でpriority制御されるようです。

詳細 - Slurm Workload Manager - Resource Limits

ですので、

  • QoSのみ
  • Associationのみ
  • QoSとAssociationの両方

制限したい項目が↑のどれに当てはまるかも確認した上で、階層的な制御方法をデザインしていく必要があるのかも知れません（Slurmクラスタを自組織で柔軟に運用したい場合）。

今回は以上です。