マイLab手帖

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

Slurm Installその後2.リソース制限 associations

はじめに

今回は、前回記事で作成したassociations設定に対してSlurmのリソースを掛ける設定をやってみます。

前回の流れ

おさらい

1. アカウント管理無効状態→johnユーザでsbatch実行 →実行OK
2. アカウント管理有効化→johnユーザでsbatch実行→不可(Deny)
3. associationsを作成
  cluster: 「sample-cluster」
  account: 「Chemistry
  user: 「 john」
4. johnユーザでsbatch実行 → 再び実行OK

前回記事はこちら taqqu.hatenablog.com


associationsの状態

sacctmgrコマンドでassociationsレコードを確認しておきます。

[slurm@master ~]$ sacctmgr show assoc format=cluster,account,user
   Cluster    Account       User 
---------- ---------- ---------- 
sample-cl+       root            
sample-cl+       root       root 
sample-cl+  chemistry            
sample-cl+  chemistry       john 

→defaultである「root」と検証ユーザである「john」のassociationsのレコードが存在しています。
それぞれ

  • accountレベル
  • userレベル

のレコードが生成された状態でした。


リソース制限 設定無しの状態

ユーザレベルでのassociationを使ったリソースを制限をやっていく前にまず、johnユーザでリソース制限設定の無い状態でsbatchの実行結果を確認しておきます。 環境は前回と同じです。

  • node1~4が計算ノード
  • partition1(node1, node2), partition2(node3, node4)に構成
  • 実行スクリプトとして適当に作成したtest.shをjohnが実行(test.shは中でtest-py-sort.pyを起動する)
  • test.shではparitition2(node3, node4)を使う

動かしてみる(1)

では、連続でジョブを5回ほど実行してみます。

[john@node1 ~]$ sbatch test.sh
Submitted batch job 62
[john@node1 ~]$ sbatch test.sh
Submitted batch job 63
[john@node1 ~]$ sbatch test.sh
Submitted batch job 64
[john@node1 ~]$ sbatch test.sh
Submitted batch job 65
[john@node1 ~]$ sbatch test.sh
Submitted batch job 66

squeueで確認

[slurm@master ~]$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
                66 partition     test     john PD       0:00      1 (Resources)
                62 partition     test     john  R       0:10      1 node3
                63 partition     test     john  R       0:10      1 node3
                64 partition     test     john  R       0:10      1 node4
                65 partition     test     john  R       0:10      1 node4

→partition2(node3&4)で1nodeにつき2ジョブづつ実行(ST=R)。また5番目(ID=66)のジョブはマシンリソースの影響でPD(保留)になっています。前回記事で前半に試した事と同じです。


userレベルassociationsのリソース制限

ではuserレベルassociationsのリソース制限設定をみていきます。 対象のassociationsは以下のレコードです。

* associatons(cluster-> account -> user)

   Cluster    Account       User 
---------- ---------- ---------- 
sample-cl+  chemistry       john 

上記に対してリソース制限を付与していきます。付与にはsacctmgrを用います。

制限項目

Slurmに組み込まれているassociationに付与可能な制限項目を確認した所、 どうやら項目は以下のように大別されています。

  • associationだけ固有に設定できる
  • associationまたはQoSのどちらにでも設定できる

QoSは今回もやりません

Ver22.05時点の項目は以下の通りでした。

associationだけ固有に設定できるポリシー

  • Fairshare=
  • MaxJobs=
  • MaxJobsAccrue=
  • MaxSubmitJobs=
  • QOS=

associationsにもQoSにも設定可能な制限

  • GrpTRESMins=
  • GrpTRESRunMins=
  • GrpTRES=
  • GrpJobs=
  • GrpJobsAccrue=
  • GrpSubmitJobs=
  • GrpWall=
  • MaxTRESMinsPerJob=
  • MaxTRESPerJob=
  • MaxTRESPerNode=
  • MaxWallDurationPerJob=
  • MinPrioThreshold= *

数が多いので各制限の内容については触れませんが、興味のある方はドキュメントを参照お願いします。
Slurm Workload Manager - Resource Limits

また、Grp~」始まりの制限設定は、ユーザレベルではなくアカウントレベルの制限で見ていきたいと思います。 ひとまずは、ぱっと見で内容が想像しやすい制限を扱っていきたいと思います。

MaxJobs=
MaxSubmitJobs=


制限の設定

ではsacctmgr modifyでMaxJobs=1、MaxSubmitJobs=2 をjohnのassociationsに設定していきます。

sacctmgr modify user john set MaxJobs=1, MaxSubmitJobs=2

[slurm@master ~]$ sacctmgr modify user john set MaxJobs=1, MaxSubmitJobs=2
 Modified user associations...
  C = sample-cluster A = chemistry            U = john     
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y

→結果を確認してみます。

sacctmgr show associations name=john format=account,user,MaxJobs,MaxSubmitJobs

[slurm@master ~]$ sacctmgr show associations format=account,user,MaxJobs,MaxSubmitJobs
   Account       User MaxJobs MaxSubmit 
---------- ---------- ------- --------- 
      root                              
      root       root                   
 chemistry                              
 chemistry       john       1         2 

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


/etc/slurm/slurm.confの変更

上記に加えてもう1点、slurm.confの修正も必要となります。AccountingStorageEnforceパラメータが前回記事の続きで「associations」(以下)の設定になっています。

#AccountingStorageEnforce=0
AccountingStorageEnforce=associations

以下は前回記事の再掲ですが、設定例を確認するとassociationsのままでは制限は有効化されません。

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

※他にも,safe,wckeys...といった設定値が可能

制限を有効化するためにAccountingStorageEnforceパラメータをassociations→limitsに変更します。

#AccountingStorageEnforce=0
#AccountingStorageEnforce=associations
AccountingStorageEnforce=limits

以下も実施しておきます。

  • /etc/slurm/slurm.confをnode1~4に配布してslurmdを再起動

  • masterもslurmctldを再起動


動かしてみる(2)

それではjohnユーザで[動かしてみる(1)]と同様にsbatchを何度か実行して、制限が有効化されているか確認してみたいと思います。

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

→3回目の実行でerrorになります。MaxSubmitJobs=2が効いてsubmit(sbatch実行)が3回目からエラーになっている事がわかります。

squeueで確認

[vagrant@master ~]$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               103 partition     test     john PD       0:00      1 (AssocMaxJobsLimit)
               102 partition     test     john  R       0:08      1 node3

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

シンプルな例ですが、

  • userレベルassociationsでのリソース制限

ができました。次にアカウントレベルassociationsによる制限を見てみたいと思います。


accountレベルassociationsのリソース制限

制限項目

設定可能な制限項目は、ユーザレベルassociationsの章で書いた内容と同じです。 ただアカウントレベルでは、*Grp~**始まりの項目を設定みたいと思います。

  • GrpJobs=

  • GrpSubmitJobs=

*Grp~**始まりの項目は、前回記事にて触れた親子関係のassociationsにも適用できる制限のようですので、実際にやってみたいと思います。

↓公式からの引用

GrpJobs= The total number of jobs able to run at any given time from an association and its children QOS. If this limit is reached new jobs will be queued but only allowed to run after previous jobs complete from this group.

GrpSubmitJobs= The total number of jobs able to be submitted to the system at any given time from an association and its children or QOS. If this limit is reached new submission requests will be denied until previous jobs complete from this group.


associations(Child)の追加

それでは、既存(親: Parent)のaccount(Chemistry)に対して、子(Child)のaccount(Chemstry Japan)という形でassociationsを作成し、Tomというユーザも新規作成します。 以下のようなイメージです。


はじめにTomユーザを作成しておきます。(master & nodex4)

useradd -u 2001 tom

associationsの追加( account )

次にaccount associationsを作成します。 accountは"chemistry_japan"で、Parent=に"chemisty"を指定します。

sacctmgr add account chemistry_japan Cluster=sample-cluster Description="Chemisty dept. Japan-division" Organization=science.com Parent="chemistry"

[slurm@master ~]$ sacctmgr add account chemistry_japan Cluster=sample-cluster Description="Chemisty dept. Japan-division" Organization=science.com Parent="chemistry"
 Adding Account(s)
  chemistry_japan
 Settings
  Description     = chemisty dept. japan-division
  Organization    = science.com
 Associations
  A = chemistry_ C = sample-clu
 Settings
  Parent        = chemistry
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y

associationsの追加( user )

続いて、TomのUser associationsを作成します。

sacctmgr add user tom Cluster=sample-cluster Account=chemistry_japan DefaultAccount=chemistry_japan

[slurm@master ~]$ sacctmgr add user tom Cluster=sample-cluster Account=chemistry_japan DefaultAccount=chemistry_japan
 Associations =
  U = tom       A = chemistry_ C = sample-clu
 Non Default Settings
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y

→これでchild accountとuserの設定はできました。


制限の設定

まず、さきほどJohnのassociationsに付与したMaxJobs,MaxSubmitJobsは一旦削除しておきます。 -1を指定することで、以前の制限を削除する事ができます。

sacctmgr modify user john set MaxJobs=-1 MaxSubmitJobs=-1

[slurm@master ~]$ sacctmgr modify user john  set MaxJobs=-1 MaxSubmitJobs=-1
 Modified user associations...
  C = sample-cluster A = chemistry            U = john     
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y

→前回付与した制限が削除できました。

次にparent account側(chemistry)に制限GrpJobs, GrpSubmitJobsを追加してみたいと思います。

sacctmgr modify account chemistry set GrpJobs=1, GrpSubmitJobs=2

[slurm@master ~]$ sacctmgr modify account chemistry set GrpJobs=1, GrpSubmitJobs=2
 Modified account associations...
  C = sample-cluster A = chemistry of root
Would you like to commit changes? (You have 30 seconds to decide)
(N/y): y

→これで設定完了です。

では設定の最後に、現状確認してみます。

[slurm@master ~]$ sacctmgr show associations format=account,user,GrpJobs,GrpSubmitJobs
   Account       User GrpJobs GrpSubmit 
---------- ---------- ------- --------- 
      root                              
      root       root                   
 chemistry                  1         2 
 chemistry       john                   
chemistry+                              
chemistry+        tom                   
                       

→parent account(chemistry)に「GrpJobs=1, GrpSubmitJobs=2」が、child account(chemisty_japan)には何も設定されていない事がわかります。これで設定は完了です。

動かしてみる(3)

account (parent: chemistry)

まずは動かしてみる(2)と同じ方法で、johnユーザで「GrpJobs、GrpSubmitJobs」が効いているか確認してみます。

[john@node1 ~]$ sbatch test.sh 
Submitted batch job 106
[john@node1 ~]$ sbatch test.sh 
Submitted batch job 107
[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回目からエラーになっている事がわかります。 MaxSubmitJobsと同じ挙動ですが、accountレベルの制限でもきちんと制限が掛かっています。

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

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


account (child: chemistry_japan)

それでは、子account (chemistry_japan)のTomユーザでsbatchを実行してみます。 (Node1から実行。sbatchのスクリプト内容はjohnと全く同じ)

[tom@node1 ~]$ sbatch test.sh 
Submitted batch job 108
[tom@node1 ~]$ sbatch test.sh 
Submitted batch job 109
[tom@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)
[tom@node1 ~]$ 

→johnと同様、3回目でGrpSubmitJobs"2"の制限によりerrorになりました。

[vagrant@master ~]$ squeue
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
               109 partition     test      tom PD       0:00      1 (AssocGrpJobsLimit)
               108 partition     test      tom  R       0:07      1 node3

→squeueの方もjohnと同様です。1回目の実行がRUNし(ID=108)、2回目の実行(ID=109)はGrpJobs=1が効いて保留(ST=PD)。

という事で、

  • accountレベルassociationsでのリソース制限
  • parentとなるaccountのリソース制限がchild accountにも適用される

を確認する事ができました。今回は以上です。

補足

GrpJobs/GrpSubmitJobsですが、userレベルのassociations(john)にも設定はできました。そしてjohnユーザで制限が掛かることも動作確認できましたが、childアカウント所属userであるtomでは制限が掛かりませんでした。 ちゃんとaccountレベルで制限付与しておかなければ、親子設定したchild accountの所属userへは制限が適用されないようです。

最後に

今回は、userレベルとaccountレベルのassociationsに対して、リソース制限機能を付与できる事を試してみました。

Slurmのリソース制限の階層の話には今回も触れる事ができませんでしたが、(できれば)次回はQoS設定をテーマにこちらにも触れられたらと思います。