Heterogeneous Job Support
- Overview
- Submitting Jobs
- Burst Buffers
- Managing Jobs
- Launching Applications (Job Steps)
- Environment Variables
- Examples
- Limitations
- System Administrator Information
Overview
Slurm version 17.11 and later supports the ability to submit and manage
heterogeneous jobs, in which each component has virtually all job options
available including partition, account and QOS (Quality Of Service).
For example, part of a job might require four cores and 4 GB for each of 128
tasks while another part of the job would require 16 GB of memory and one CPU.
Slurmバージョン17.11以降では、異種ジョブを送信および管理する機能がサポートされています。各コンポーネントには、パーティション、アカウント、QOS（サービス品質）など、ほぼすべてのジョブオプションが用意されています。たとえば、ジョブの一部には128個のタスクごとに4つのコアと4 GBが必要であり、ジョブの別の部分には16 GBのメモリと1つのCPUが必要です。
Submitting Jobs
The salloc, sbatch and srun commands can all be used
to submit heterogeneous jobs.
Resource specifications for each component of the heterogeneous job should be
separated with ":" character.
For example:
salloc、sbatch、およびsrunコマンドはすべて、異種ジョブをサブミットするために使用できます。異機種混合ジョブの各コンポーネントのリソース仕様は、「：」文字で区切る必要があります。例えば：
$ sbatch --cpus-per-task=4 --mem-per-cpu=1 --ntasks=128 : \
--cpus-per-task=1 --mem-per-cpu=16 --ntasks=1 my.bash
Options specified for one component of a heterogeneous job (or job step) will
be used for subsequent components to the extent which is expected to be helpful.
Propagated options can be reset as desired for each component (e.g. a different
account name could be specified for each hetjob component.
For example, --immediate and --job-name are propagated, while
--ntasks and --mem-per-cpu are reset to default values for each
component.
A list of propagated options follows.
異機種混在ジョブ（またはジョブステップ）の1つのコンポーネントに指定されたオプションは、役立つと予想される範囲で、後続のコンポーネントに使用されます。伝播されたオプションは、コンポーネントごとに必要に応じてリセットできます（たとえば、hetjobコンポーネントごとに異なるアカウント名を指定できます。たとえば、-immediateと--job-nameは伝達されますが、-ntasksと--mem-per- cpuは各コンポーネントのデフォルト値にリセットされます。伝播されたオプションのリストは次のとおりです。
- --account
- --acctg-freq
- --begin
- --cluster-constraint
- --clusters
- --comment
- --deadline
- --delay-boot
- --dependency
- --distribution
- --epilog (option available only in srun)
- --error
- --export
- --export-file
- --exclude
- --get-user-env
- --gid
- --hold
- --ignore-pbs
- --immediate
- --input
- --job-name
- --kill-on-bad-exit (option available only in srun)
- --label (option available only in srun)
- --mcs-label
- --msg-timeout (option available only in srun)
- --no-allocate (option available only in srun)
- --no-requeue
- --nice
- --no-kill
- --open-mode (option available only in srun)
- --output
- --parsable
- --priority
- --profile
- --propagate
- --prolog (option available only in srun)
- --pty (option available only in srun)
- --qos
- --quiet
- --quit-on-interrupt (option available only in srun)
- --reboot
- --reservation
- --requeue
- --signal
- --slurmd-debug (option available only in srun)
- --task-epilog (option available only in srun)
- --task-prolog (option available only in srun)
- --time
- --test-only
- --time-min
- --uid
- --unbuffered (option available only in srun)
- --verbose
- --wait
- --wait-all-nodes
- --wckey
- --workdir
The task distribution specification applies separately within each job
component. Consider for example a heterogeneous job with each component being
allocated 4 CPUs on 2 nodes. In our example, job component zero is allocated
2 CPUs on node "nid00001" and 2 CPUs on node "nid00002". Job component one is
allocated 2 CPUs on node "nid00003" and 2 CPUs on node "nid00004". A task
distribution of "cyclic" will distribute the first 4 tasks in a cyclic fashion
on nodes "nid00001" and "nid00002", then distribute the next 4 tasks in a cyclic
fashion on nodes "nid00003" and "nid00004" as shown below.
タスク分散仕様は、各ジョブコンポーネント内で個別に適用されます。たとえば、2つのノードで4つのCPUが各コンポーネントに割り当てられている異種ジョブを考えてみます。この例では、ジョブコンポーネント0にノード「nid00001」の2つのCPUとノード「nid00002」の2つのCPUが割り当てられています。ジョブコンポーネント1には、ノード "nid00003"に2 CPU、ノード "nid00004"に2 CPUが割り当てられています。「サイクリック」のタスク分散は、最初の4つのタスクをノード「nid00001」と「nid00002」で循環的に分散し、次の4つのタスクをノード「nid00003」と「nid00004」で循環的に分散します。
| Node nid00001 | Node nid00002 | Node nid00003 | Node nid00004 |
| Rank 0 | Rank 1 | Rank 4 | Rank 5 |
| Rank 2 | Rank 3 | Rank 6 | Rank 7 |
Some options should be specified only in the first hetjob component.
For example, specifying a batch job output file in the second hetjob component's
options will result in the first hetjob component (where the batch script
executes) using the default output file name.
一部のオプションは、最初のhetjobコンポーネントでのみ指定する必要があります。たとえば、2番目のhetjobコンポーネントのオプションでバッチジョブ出力ファイルを指定すると、最初のhetjobコンポーネント（バッチスクリプトが実行される場所）はデフォルトの出力ファイル名を使用します。
Environment variables used to specify default options for the job submit
command will be applied to every component of the heterogeneous job
(e.g. SBATCH_ACCOUNT).
ジョブ送信コマンドのデフォルトオプションを指定するために使用される環境変数は、異機種混合ジョブのすべてのコンポーネント（SBATCH_ACCOUNTなど）に適用されます。
Batch job options can be included in the submitted script for multiple
heterogeneous job components. Each component should be separated by a line
containing the line "#SBATCH hetjob" as shown below.
バッチジョブオプションは、複数の異種ジョブコンポーネントの送信済みスクリプトに含めることができます。以下に示すように、各コンポーネントは「#SBATCH hetjob」という行を含む行で区切る必要があります。
$ cat new.bash #!/bin/bash #SBATCH --cpus-per-task=4 --mem-per-cpu=16g --ntasks=1 #SBATCH hetjob #SBATCH --cpus-per-task=2 --mem-per-cpu=1g --ntasks=8 srun run.app $ sbatch new.bash
Is equivalent to the following:
次と同等です。
$ cat my.bash
#!/bin/bash
srun run.app
$ sbatch --cpus-per-task=4 --mem-per-cpu=16g --ntasks=1 : \
--cpus-per-task=2 --mem-per-cpu=1g --ntasks=8 my.bash
The batch script will be executed in the first node in the first component
of the heterogeneous job. For the above example, that will be the job component
with 1 task, 4 CPUs and 64 GB of memory (16 GB for each of the 4 CPUs).
バッチスクリプトは、異種ジョブの最初のコンポーネントの最初のノードで実行されます。上記の例では、1つのタスク、4つのCPU、64 GBのメモリ（4つのCPUごとに16 GB）を持つジョブコンポーネントになります。
If a heterogeneous job is submitted to run in multiple clusters not
part of a federation (e.g. "sbatch --cluster=alpha,beta ...") then the entire
job will be sent to the cluster expected to be able to start all components
at the earliest time.
フェデレーションの一部ではない複数のクラスターで実行する異種ジョブが送信された場合（例：「sbatch --cluster = alpha、beta ...」）、ジョブ全体がクラスターに送信され、すべてのコンポーネントを開始できると予想されます早い時期に。
A resource limit test is performed when a heterogeneous job is submitted in
order to immediately reject jobs that will not be able to start with current
limits.
The individual components of the heterogeneous job are validated, like all
regular jobs.
The heterogeneous job as a whole is also tested, but in a more limited
fashion with respect to quality of service (QOS) limits.
Each component of a heterogeneous job counts as a "job" with respect to
resource limits.
現在の制限では開始できないジョブを即座に拒否するために、異種ジョブが送信されると、リソース制限テストが実行されます。すべての通常のジョブと同様に、異種ジョブの個々のコンポーネントが検証されます。異種ジョブ全体もテストされますが、サービス品質（QOS）の制限に関してはより限定的な方法で行われます。異種ジョブの各コンポーネントは、リソース制限に関して「ジョブ」としてカウントされます。
Burst Buffers
A burst buffer can either be persistent or linked to a specific job ID
(at least the Cray implementation).
Since a heterogeneous job consists of multiple job IDs, a job-specific burst
buffer will be associated with only one heterogeneous job component.
Only a persistent burst buffer can be accessed by all components of a
heterogeneous job.
A sample batch script demonstrating this for a Cray system is appended.
バーストバッファーは、永続的であるか、特定のジョブID（少なくともCrayの実装）にリンクされています。異種ジョブは複数のジョブIDで構成されるため、ジョブ固有のバーストバッファーは、1つの異種ジョブコンポーネントにのみ関連付けられます。異機種混合ジョブのすべてのコンポーネントがアクセスできるのは、永続的なバーストバッファのみです。Crayシステムでこれを示すサンプルバッチスクリプトが追加されています。
#!/bin/bash #SBATCH --nodes=1 --constraint=haswell #BB create_persistent name=alpha capacity=10 access=striped type=scratch #DW persistentdw name=alpha #SBATCH hetjob #SBATCH --nodes=16 --constraint=knl #DW persistentdw name=alpha ...
NOTE: Cray's DataWarp interface directly reads the job script, but
has no knowledge of "Slurm's "hetjob" directive, so Slurm internally rebuilds
the script for each job component so that only that job components burst buffer
directives are included in that script. The batch script first component of the
job will be modified in order to replace the "#DW" directives of other
job components with "#EXCLUDED DW" to prevent their interpretation by Cray
infrastructure. Since the batch script will only be executed by the first job
component, the subsequent job components will not include commands from the
original script. These scripts are build and managed by Slurm for internal
purposes (and visiable from various Slurm commands) from a user script as shown
above. An example is shown below:
注：CrayのDataWarpインターフェースはジョブスクリプトを直接読み取りますが、 "Slurmの" hetjob "ディレクティブの知識がないため、Slurmは各ジョブコンポーネントのスクリプトを内部的に再構築し、そのジョブコンポーネントのバーストバッファーディレクティブのみがそのスクリプトに含まれるようにします。バッチジョブのスクリプトの最初のコンポーネントは、他のジョブコンポーネントの「#DW」ディレクティブを「#EXCLUDED DW」に置き換えるために変更され、Crayインフラストラクチャによる解釈を防ぎます。バッチスクリプトは最初のジョブコンポーネントによってのみ実行されるため、 、後続のジョブコンポーネントには、元のスクリプトからのコマンドは含まれません。これらのスクリプトは、上記のようにユーザースクリプトから内部目的で（およびさまざまなSlurmコマンドから見えるように）Slurmによって構築および管理されます。例を以下に示します。
Rebuilt script for first job component #!/bin/bash #SBATCH --nodes=1 --constraint=haswell #BB create_persistent name=alpha capacity=10 access=striped type=scratch #DW persistentdw name=alpha #SBATCH hetjob #SBATCH --nodes=16 --constraint=knl #EXCLUDED DW persistentdw name=alpha ... Rebuilt script for second job component #!/bin/bash #SBATCH --nodes=16 --constraint=knl #DW persistentdw name=alpha exit 0
Managing Jobs
Information maintained in Slurm for a heterogeneous job includes:
異機種混合ジョブのためにSlurmで維持される情報には、以下が含まれます。
- job_id: Each component of a heterogeneous job will have its own
unique job_id.
job_id：異種ジョブの各コンポーネントには、独自の固有のjob_idがあります。 - het_job_id: This identification number applies to all components
of the heterogeneous job. All components of the same job will have the same
het_job_id value and it will be equal to the job_id of the
first component. We refer to this as the "heterogeneous job leader".
het_job_id：この識別番号は、異機種混合ジョブのすべてのコンポーネントに適用されます。同じジョブのすべてのコンポーネントは同じhet_job_id値を持ち、最初のコンポーネントのjob_idと等しくなります。これを「異種ジョブリーダー」と呼びます。 - het_job_id_set: Regular expression identifying all job_id
values associated with the job.
het_job_id_set：ジョブに関連付けられたすべてのjob_id値を識別する正規表現。 - het_job_offset: A unique sequence number applied to each component
of the heterogeneous job. The first component will have a het_job_offset
value of 0, the next a value of 1, etc.
het_job_offset：異機種混合ジョブの各コンポーネントに適用される一意のシーケンス番号。最初のコンポーネントのhet_job_offset値は0、次のコンポーネントの値は1などです。
| job_id | het_job_id | het_job_offset | het_job_id_set |
|---|---|---|---|
| 123 | 123 | 0 | 123-127 |
| 124 | 123 | 1 | 123-127 |
| 125 | 123 | 2 | 123-127 |
| 126 | 123 | 3 | 123-127 |
| 127 | 123 | 4 | 123-127 |
Table 1: Example job IDs
The squeue and sview commands report the
components of a heterogeneous job using the format
"<het_job_id>+<het_job_offset>".
For example "123+4" would represent heterogeneous job id 123 and its fifth
component (note: the first component has a het_job_offset value of 0).
squeueおよびsviewコマンドは、フォーマット「」を使用して、異種ジョブのコンポーネントを報告します+"。たとえば、「123 + 4」は、異種ジョブID 123とその5番目のコンポーネントを表します（注：最初のコンポーネントのhet_job_offset値は0です）。
A request for a specific job ID that identifies a ID of the first component
of a heterogeneous job (i.e. the "heterogeneous job leader") will return
information about all components of that job. For example:
異機種混在ジョブの最初のコンポーネント（つまり、「異機種混在ジョブリーダー」）のIDを識別する特定のジョブIDを要求すると、そのジョブのすべてのコンポーネントに関する情報が返されます。例えば：
$ squeue --job=93 JOBID PARTITION NAME USER ST TIME NODES NODELIST 93+0 debug bash adam R 18:18 1 nid00001 93+1 debug bash adam R 18:18 1 nid00011 93+2 debug bash adam R 18:18 1 nid00021
A request to cancel or otherwise signal a heterogeneous job leader will be applied to
all components of that heterogeneous job. A request to cancel a specific component of
the heterogeneous job using the "#+#" notation will apply only to that specific component.
For example:
異機種混合ジョブリーダーをキャンセルするか、別の方法で通知する要求は、その異機種混合ジョブのすべてのコンポーネントに適用されます。「＃+＃」表記を使用して異種ジョブの特定のコンポーネントをキャンセルする要求は、その特定のコンポーネントにのみ適用されます。例えば：
$ squeue --job=93 JOBID PARTITION NAME USER ST TIME NODES NODELIST 93+0 debug bash adam R 19:18 1 nid00001 93+1 debug bash adam R 19:18 1 nid00011 93+2 debug bash adam R 19:18 1 nid00021 $ scancel 93+1 $ squeue --job=93 JOBID PARTITION NAME USER ST TIME NODES NODELIST 93+0 debug bash adam R 19:38 1 nid00001 93+2 debug bash adam R 19:38 1 nid00021 $ scancel 93 $ squeue --job=93 JOBID PARTITION NAME USER ST TIME NODES NODELIST
While a heterogeneous job is in pending state, only the entire job can be
cancelled rather than its individual components.
A request to cancel an individual component of a heterogeneous job not in
pending state will return an error.
After the job has begun execution, the individual component can be cancelled.
異機種混合ジョブが保留状態の場合、キャンセルできるのは、個々のコンポーネントではなく、ジョブ全体のみです。保留状態ではない異種ジョブの個々のコンポーネントをキャンセルするリクエストは、エラーを返します。ジョブが実行を開始した後、個々のコンポーネントをキャンセルできます。
Email notification for job state changes (the --mail-type option)
is only supported for a heterogeneous job leader. Requests for email
notifications for other components of a heterogeneous job will be silently
ignored.
ジョブの状態変更に関する電子メール通知（--mail-typeオプション）は、異種ジョブリーダーでのみサポートされています。異機種混合ジョブの他のコンポーネントの電子メール通知の要求は、通知なく無視されます。
Requests to modify an individual component of a job using the scontrol
command must specify the job ID with the "#+#" notation.
A request to modify a job by specifying the het_job_id will modify all
components of a heterogeneous job.
For example:
scontrolコマンドを使用してジョブの個々のコンポーネントを変更するリクエストでは、「＃+＃」表記でジョブIDを指定する必要があります。het_job_idを指定してジョブを変更する要求は、異種ジョブのすべてのコンポーネントを変更します。例えば：
# Change the account of component 2 of heterogeneous job 123: $ scontrol update jobid=123+2 account=abc # Change the time limit of all components of heterogeneous job 123: $ scontrol update jobid=123 timelimit=60
Requests to perform the following operations a job can only be requested for
a heterogeneous job leader and will be applied to all components of that
heterogeneous job. Requests to operate on individual components of the
heterogeneous will return an error.
次の操作を実行する要求ジョブは、異種ジョブリーダーに対してのみ要求でき、その異種ジョブのすべてのコンポーネントに適用されます。異種混合の個々のコンポーネントを操作するリクエストはエラーを返します。
- requeue
- resume
- suspend
The sbcast command supports heterogeneous job allocations. By default,
sbcast will will copy files to all nodes in the job allocation. The -j/--jobid
option can be used to copy files to individual components as shown below.
sbcastコマンドは、異種ジョブの割り当てをサポートしています。デフォルトでは、sbcastはジョブ割り当てのすべてのノードにファイルをコピーします。以下に示すように、-j /-jobidオプションを使用して、ファイルを個々のコンポーネントにコピーできます。
$ sbcast --jobid=123 data /tmp/data $ sbcast --jobid=123.0 app0 /tmp/app0 $ sbcast --jobid=123.1 app1 /tmp/app1
The srun commands --bcast option will transfer files to the nodes associated
with the application to be launched as specified by the --het-group option.
srunコマンドの--bcastオプションは、-het-groupオプションで指定された、起動するアプリケーションに関連付けられたノードにファイルを転送します。
Slurm has a configuration option to control behavior of some commands with
respect to heterogeneous jobs.
By default a request to cancel, hold or release a job ID that is not the
het_job_id, but that of a job component will only operate that one component
of the heterogeneous job.
If SchedulerParameters configuration parameter includes the option
"whole_hetjob" then the operation would apply to all components of the job if
any job component is specified to be operated upon. In the below example, the
scancel command will either cancel all components of job 93 if
SchedulingParameters=whole_hetjob is configured, otherwise only job 93+1 will be
cancelled. If a specific heterogeneous job component is specified (e.g. "scancel
93+1"), then only that one component will be effected.
Slurmには、異種ジョブに関する一部のコマンドの動作を制御する構成オプションがあります。デフォルトでは、het_job_idではなく、ジョブコンポーネントのジョブIDであるジョブIDをキャンセル、保留、または解放する要求は、異種ジョブのその1つのコンポーネントのみを操作します。SchedulerParameters構成パラメーターにオプション「whole_hetjob」が含まれている場合、操作対象のジョブコンポーネントが指定されている場合、操作はジョブのすべてのコンポーネントに適用されます。以下の例では、SchedulingParameters = whole_hetjobが構成されている場合、scancelコマンドはジョブ93のすべてのコンポーネントをキャンセルします。それ以外の場合は、ジョブ93 + 1のみがキャンセルされます。特定の異種ジョブコンポーネントが指定されている場合（ "scancel 93 + 1"など）、その1つのコンポーネントのみが影響を受けます。
$ squeue --job=93 JOBID PARTITION NAME USER ST TIME NODES NODELIST 93+0 debug bash adam R 19:18 1 nid00001 93+1 debug bash adam R 19:18 1 nid00011 93+2 debug bash adam R 19:18 1 nid00021 $ scancel 94 (where job ID 94 is equivalent to 93+1) # Cancel 93+0, 93+1 and 93+2 if SchedulerParameters includes "whole_hetjob" # Cancel only 93+1 if SchedulerParameters does not include "whole_hetjob"
Accounting
Slurm's accounting database records the het_job_id and het_job_offset
fields.
The sacct command reports job's using the format
"<het_job_id>+<het_job_offset>" and can accept a job ID
specification for filtering using the same format.
If a het_job_id value is specified as a job filter, then information about
all components of that job will be reported as shown below by default.
The --whole-hetjob=[yes|no] option can be used to force to report
the information about all the components of that job or just about the specific
component requested, no matter if the job filter includes the het_job_id
(leader) or not.
Slurmのアカウンティングデータベースは、het_job_idおよびhet_job_offsetフィールドを記録します。sacctコマンドは、ジョブの形式を「+"および同じ形式を使用してフィルタリングするジョブIDの指定を受け入れることができます。het_job_id値がジョブフィルターとして指定されている場合、そのジョブのすべてのコンポーネントに関する情報は、デフォルトで以下のように報告されます。--whole-hetjob = [yes | no]オプションを使用すると、ジョブフィルターにhet_job_id（リーダー）が含まれているかどうかに関係なく、そのジョブのすべてのコンポーネントまたは要求された特定のコンポーネントに関する情報を強制的に報告できます。
$ sacct -j 67767 JobID JobName Partition Account AllocCPUS State ExitCode ------- ------- --------- ------- --------- --------- -------- 67767+0 foo debug test 2 COMPLETED 0:0 67767+1 foo debug test 4 COMPLETED 0:0 $ sacct -j 67767+1 JobID JobName Partition Account AllocCPUS State ExitCode ------- ------- --------- ------- --------- --------- -------- 67767+1 foo debug test 4 COMPLETED 0:0 $ sacct -j 67767 --whole-hetjob=no JobID JobName Partition Account AllocCPUS State ExitCode ------- ------- --------- ------- --------- --------- -------- 67767+0 foo debug test 4 COMPLETED 0:0 $ sacct -j 67767+1 --whole-hetjob=yes JobID JobName Partition Account AllocCPUS State ExitCode ------- ------- --------- ------- --------- --------- -------- 67767+0 foo debug test 2 COMPLETED 0:0 67767+1 foo debug test 4 COMPLETED 0:0
Launching Applications (Job Steps)
The srun command is used to launch applications.
By default, the application is launched only on the first component of a
heterogeneous job, but options are available to support different behaviors.
srunコマンドは、アプリケーションを起動するために使用されます。デフォルトでは、アプリケーションは異種ジョブの最初のコンポーネントでのみ起動されますが、さまざまな動作をサポートするオプションを利用できます。
srun's "--het-group" option defines which hetjob component(s) are to have
applications launched for them. The --het-group option takes an expression
defining which component(s) are to launch an application for an individual
execution of the srun command. The expression can contain one or more component
index values in a comma separated list. Ranges of index values can be specified
in a hyphen separated list. By default, an application is launched only on
component number zero. Some examples follow:
srunの「--het-group」オプションは、どのhetjobコンポーネントがアプリケーションを起動するかを定義します。--het-groupオプションは、srunコマンドを個別に実行するためにアプリケーションを起動するコンポーネントを定義する式を取ります。式には、コンマ区切りのリストで1つ以上のコンポーネントインデックス値を含めることができます。インデックス値の範囲は、ハイフンで区切られたリストで指定できます。デフォルトでは、アプリケーションはコンポーネント番号0でのみ起動されます。次にいくつかの例を示します。
- --het-group=2
- --het-group=0,4
- --het-group=1,3-5
IMPORTANT: The ability to execute a single application across more
than one job allocation does not work with all MPI implementations or Slurm MPI
plugins. Slurm's ability to execute such an application can be disabled on the
entire cluster by adding "disable_hetjob_steps" to Slurm's SchedulerParameters
configuration parameter.
重要：複数のジョブ割り当てにわたって単一のアプリケーションを実行する機能は、すべてのMPI実装またはSlurm MPIプラグインでは機能しません。SlurmのSchedulerParameters構成パラメーターに「disable_hetjob_steps」を追加することで、そのようなアプリケーションを実行するSlurmの機能をクラスター全体で無効にすることができます。
IMPORTANT: While the srun command can be used to launch heterogeneous
job steps, mpirun would require substantial modification to support
heterogeneous applications. We are aware of no such mpirun development efforts
at this time.
重要：srunコマンドを使用して異種ジョブステップを起動できますが、mpirunは異種アプリケーションをサポートするために大幅な変更が必要になります。現在のところ、そのようなmpirun開発の取り組みはありません。
By default, the applications launched by a single execution of the srun
command (even for different components of the heterogeneous job) are combined
into one MPI_COMM_WORLD with non-overlapping task IDs.
デフォルトでは、srunコマンドの1回の実行で起動されたアプリケーションは（異種ジョブの異なるコンポーネントの場合でも）、タスクIDが重複しない1つのMPI_COMM_WORLDに結合されます。
As with the salloc and sbatch commands, the ":" character is used to
separate multiple components of a heterogeneous job.
This convention means that the stand-alone ":" character can not be used as an
argument to an application launched by srun.
This includes the ability to execute different applications and arguments
for each job component.
If some heterogeneous job component lacks an application specification, the next
application specification provided will be used for earlier components lacking
one as shown below.
sallocおよびsbatchコマンドと同様に、「：」文字は異種ジョブの複数のコンポーネントを区切るために使用されます。この規則は、スタンドアロンの「：」文字をsrunによって起動されたアプリケーションの引数として使用できないことを意味します。これには、各ジョブコンポーネントのさまざまなアプリケーションと引数を実行する機能が含まれます。異種ジョブコンポーネントの一部にアプリケーション仕様がない場合は、次に示すように、提供されている次のアプリケーション仕様が、コンポーネントのない以前のコンポーネントに使用されます。
$ srun --label -n2 : -n1 hostname 0: nid00012 1: nid00012 2: nid00013
If multiple srun commands are executed concurrently, this may result in resource
contention (e.g. memory limits preventing some job steps components from being
allocated resources because of two srun commands executing at the same time).
If the srun --het-group option is used to create multiple job steps (for the
different components of a heterogeneous job), those job steps will be created
sequentially.
When multiple srun commmands execute at the same time, this may result in some
step allocations taking place, while others are delayed.
Only after all job step allocations have been granted will the application
being launched.
複数のsrunコマンドが同時に実行されると、リソースの競合が発生する可能性があります（たとえば、メモリの制限により、2つのsrunコマンドが同時に実行されるため、一部のジョブステップコンポーネントにリソースが割り当てられません）。srun --het-groupオプションを使用して複数のジョブステップを作成する場合（異種ジョブの異なるコンポーネント用）、それらのジョブステップは順番に作成されます。複数のsrunコマンドが同時に実行されると、一部のステップ割り当てが行われる一方で、他のコマンドが遅延する場合があります。すべてのジョブステップの割り当てが許可された後にのみ、アプリケーションが起動されます。
All components of a job step will have the same step ID value.
If job steps are launched on subsets of the job components there may be gaps in
the step ID values for individual job components.
ジョブステップのすべてのコンポーネントは、同じステップID値を持ちます。ジョブコンポーネントのサブセットでジョブステップが起動される場合、個々のジョブコンポーネントのステップID値にギャップがある可能性があります。
$ salloc -n1 : -n2 beta bash salloc: Pending job allocation 1721 salloc: Granted job allocation 1721 $ srun --het-group=0,1 true # Launches steps 1721.0 and 1722.0 $ srun --het-group=0 true # Launches step 1721.1, no 1722.1 $ srun --het-group=0,1 true # Launches steps 1721.2 and 1722.2
The maximum het-group specified in a job step allocation (either explicitly
specified or implied by the ":" separator) must not exceed the number of
components in the heterogeneous job allocation. For example
ジョブステップの割り当てで明示的に指定された最大のhet-group（明示的に指定されるか、 "："セパレーターによって暗黙に示される）は、異種ジョブの割り当てにおけるコンポーネントの数を超えてはなりません。例えば
$ salloc -n1 -C alpha : -n2 -C beta bash
salloc: Pending job allocation 1728
salloc: Granted job allocation 1728
$ srun --het-group=0,1 hostname
nid00001
nid00008
nid00008
$ srun hostname : date : id
error: Attempt to run a job step with het-group value of 2,
but the job allocation has maximum value of 1
Environment Variables
Slurm environment variables will be set independently for each component of
the job by appending "_HET_GROUP_" and a sequence number the usual name.
In addition, the "SLURM_JOB_ID" environment variable will contain the job ID
of the heterogeneous job leader and "SLURM_HET_SIZE" will contain the number of
components in the job. If using srun with a single specific het group (for
instance --het-group=1) "SLURM_JOB_ID" will contain the job ID of that specific
component, behaving like a regular (non-heterogeneous job). For example:
Slurm環境変数は、「_ HET_GROUP_」とシーケンス番号に通常の名前を追加することにより、ジョブのコンポーネントごとに個別に設定されます。さらに、「SLURM_JOB_ID」環境変数には異種ジョブリーダーのジョブIDが含まれ、「SLURM_HET_SIZE」にはジョブ内のコンポーネントの数が含まれます。単一の特定のhetグループ（たとえば、-het-group = 1）でsrunを使用する場合、「SLURM_JOB_ID」には、その特定のコンポーネントのジョブIDが含まれ、通常の（異種のジョブ）のように動作します。例えば：
$ salloc -N1 : -N2 bash salloc: Pending job allocation 11741 salloc: job 11741 queued and waiting for resources salloc: job 11741 has been allocated resources $ env | grep SLURM SLURM_JOB_ID=11741 SLURM_HET_SIZE=2 SLURM_JOB_ID_HET_GROUP_0=11741 SLURM_JOB_ID_HET_GROUP_1=11742 SLURM_JOB_NODES_HET_GROUP_0=1 SLURM_JOB_NODES_HET_GROUP_1=2 SLURM_JOB_NODELIST_HET_GROUP_0=nid00001 SLURM_JOB_NODELIST_HET_GROUP_1=nid[00011-00012] ... $ srun --het-group=1 printenv SLURM_JOB_ID 11742 $ srun --het-group=0 printenv SLURM_JOB_ID 11741
The various MPI implementations rely heavily upon Slurm environment variables
for proper operation.
A single MPI applications executing in a single MPI_COMM_WORLD require a
uniform set of environment variables that reflect a single job allocation.
The example below shows how Slurm sets environment variables for MPI.
さまざまなMPI実装は、適切な操作のためにSlurm環境変数に大きく依存しています。単一のMPI_COMM_WORLDで実行される単一のMPIアプリケーションには、単一のジョブ割り当てを反映する環境変数の統一されたセットが必要です。以下の例は、SlurmがMPIの環境変数を設定する方法を示しています。
$ salloc -N1 : -N2 bash salloc: Pending job allocation 11741 salloc: job 11751 queued and waiting for resources salloc: job 11751 has been allocated resources $ env | grep SLURM SLURM_JOB_ID=11751 SLURM_HET_SIZE=2 SLURM_JOB_ID_HET_GROUP_0=11751 SLURM_JOB_ID_HET_GROUP_1=11752 SLURM_JOB_NODELIST_HET_GROUP_0=nid00001 SLURM_JOB_NODELIST_HET_GROUP_1=nid[00011-00012] ... $ srun --het-group=0,1 env | grep SLURM SLURM_JOB_ID=11751 SLURM_JOB_NODELIST=nid[00001,00011-00012] ...
Examples
Create a heterogeneous resource allocation containing one node with 256GB
of memory and a feature of "haswell" plus 2176 cores on 32 nodes with a
feature of "knl". Then launch a program called "master" on the "haswell" node
and "slave" on the "knl" nodes. Each application will be in its own
MPI_COMM_WORLD.
256 GBのメモリと「haswell」の機能を備えた1つのノードと、「knl」の機能を備えた32のノード上の2176コアを含む異種リソース割り当てを作成します。次に、「haswell」ノードで「master」、「knl」ノードで「slave」というプログラムを起動します。各アプリケーションは、独自のMPI_COMM_WORLDにあります。
salloc -N1 --mem=256GB -C haswell : \
-n2176 -N32 --ntasks-per-core=1 -C knl bash
srun master &
srun --het-group=1 slave &
wait
This variation of the above example launches programs "master" and "slave"
in a single MPI_COMM_WORLD.
上記の例のこのバリエーションは、単一のMPI_COMM_WORLDでプログラム「マスター」と「スレーブ」を起動します。
salloc -N1 --mem=256GB -C haswell : \
-n2176 -N32 --ntasks-per-core=1 -C knl bash
srun master : slave &
The SLURM_PROCID and SLURM_TASKID environment variables will be set to
reflect a global task rank (both environment variables will have the same value).
Each spawned process will have a unique SLURM_PROCID.
SLURM_PROCIDおよびSLURM_TASKID環境変数は、グローバルタスクランクを反映するように設定されます（両方の環境変数は同じ値になります）。生成された各プロセスには、一意のSLURM_PROCIDがあります。
Similarly, the SLURM_NPROCS and SLURM_NTASKS environment variables will be set
to reflect a global task count (both environment variables will have the same
value).
SLURM_NTASKS will be set to the total count of tasks in all components.
Note that the task rank and count values are needed by MPI and typically
determined by examining Slurm environment variables.
同様に、SLURM_NPROCSおよびSLURM_NTASKS環境変数は、グローバルタスクカウントを反映するように設定されます（両方の環境変数は同じ値になります）。SLURM_NTASKSは、すべてのコンポーネントのタスクの総数に設定されます。タスクのランクとカウントの値はMPIで必要であり、通常はSlurm環境変数を調べることで決定されることに注意してください。
Limitations
The backfill scheduler has limitations in how it tracks usage of CPUs and
memory in the future.
This typically requires the backfill scheduler be able to allocate each
component of a heterogeneous job on a different node in order to begin its
resource allocation, even if multiple components of the job do actually get
allocated resources on the same node.
バックフィルスケジューラには、将来のCPUとメモリの使用状況を追跡する方法に制限があります。これは通常、ジョブの複数のコンポーネントが実際に同じノードに割り当てられたリソースを取得する場合でも、バックフィルスケジューラがリソースの割り当てを開始するために、異なるノードの異種ジョブの各コンポーネントを割り当てることができることを必要とします。
In a federation of clusters, a heterogeneous job will execute entirely on
the cluster from which the job is submitted. The heterogeneous job will not
be eligible to migrate between clusters or to have different components of
the job execute on different clusters in the federation.
クラスターのフェデレーションでは、異種ジョブは、ジョブの送信元のクラスターで完全に実行されます。異機種混合ジョブは、クラスター間でマイグレーションしたり、フェデレーション内の異なるクラスターでジョブの異なるコンポーネントを実行したりするのに適格ではありません。
Caution must be taken when submitting heterogeneous jobs that request
multiple overlapping partitions. When the partitions share the same resources
it's possible to starve your own job by having the first job component request
enough nodes that the scheduler isn't able to fill the subsequent request(s).
Consider an example where you have partition p1 that contains 10 nodes
and partition p2 that exists on 5 of the same nodes. If you submit a
heterogeneous job that requests 5 nodes in p1 and 5 nodes in p2,
the scheduler may try to allocate some of the nodes from the p2
partition for the first job component, preventing the scheduler from being
able to fulfill the second request, resulting in a job that is never able to
start.
複数の重複するパーティションを要求する異種ジョブを送信する場合は注意が必要です。パーティションが同じリソースを共有している場合、最初のジョブコンポーネントが十分なノードをリクエストすることで、スケジューラが後続のリクエストを満たせないため、独自のジョブを枯渇させる可能性があります。10個のノードを含むパーティションp1と、同じノードの5つに存在するパーティションp2がある例を考えてみます。p1の5つのノードとp2の5つのノードを要求する異種ジョブをサブミットすると、スケジューラはp2パーティションの一部のノードを最初のジョブコンポーネントに割り当てようとするため、2番目の要求を実行できなくなります。その結果、ジョブを開始できなくなります。
Job arrays of heterogeneous jobs are not supported.
異種ジョブのジョブ配列はサポートされていません。
The srun command's --no-allocate option is not supported
for heterogeneous jobs.
srunコマンドの--no-allocateオプションは、異種ジョブではサポートされていません。
Only one job step per heterogeneous job component can be launched by a
single srun command (e.g.
"srun --het-group=0 alpha : --het-group=0 beta" is not supported).
単一のsrunコマンドで起動できるのは、異種ジョブコンポーネントごとに1つのジョブステップのみです（たとえば、「srun --het-group = 0 alpha：--het-group = 0 beta」はサポートされていません）。
The sattach command can only be used to attach to a single component of
a heterogeneous job at a time.
sattachコマンドは、異機種混合ジョブの単一コンポーネントに一度に接続するためにのみ使用できます。
Heterogeneous jobs are only scheduled by the backfill scheduler plugin.
The more frequently executed scheduling logic only starts jobs on a first-in
first-out (FIFO) basis and lacks logic for concurrently scheduling all
components of a heterogeneous job.
異種ジョブは、バックフィルスケジューラプラグインによってのみスケジュールされます。より頻繁に実行されるスケジューリングロジックは、先入れ先出し（FIFO）ベースでジョブを開始するだけであり、異種ジョブのすべてのコンポーネントを同時にスケジュールするロジックがありません。
Heterogeneous jobs are not supported on Cray ALPS systems.
異種ジョブはCray ALPSシステムではサポートされていません。
Heterogeneous jobs are not supported on IBM PE systems.
異種ジョブは、IBM PEシステムではサポートされていません。
Slurm's PERL APIs currently do not support heterogeneous jobs.
SlurmのPERL APIは現在、異種ジョブをサポートしていません。
The srun --multi-prog option can not be used to span more than one
heterogeneous job component.
srun --multi-progオプションを使用して、複数の異種ジョブコンポーネントにまたがることはできません。
The srun --open-mode option is by default set to "append".
srun --open-modeオプションはデフォルトで "append"に設定されています。
Ancient versions of OpenMPI and their derivatives (i.e. Cray MPI) are
dependent upon communication ports being assigned to them by Slurm. Such MPI
jobs will experience step launch failure if any component of a
heterogeneous job step is unable to acquire the allocated ports.
Non-heterogeneous job steps will retry step launch using a new set of
communication ports (no change in Slurm behavior).
OpenMPIとその派生物（すなわちCray MPI）の古いバージョンは、Slurmによって割り当てられた通信ポートに依存しています。異種ジョブステップのいずれかのコンポーネントが割り当てられたポートを取得できない場合、そのようなMPIジョブはステップの起動に失敗します。非異種ジョブステップは、新しい通信ポートのセットを使用してステップの起動を再試行します（Slurmの動作に変更はありません）。
System Administrator Information
The job submit plugin is invoked independently for each component of a
heterogeneous job.
ジョブ送信プラグインは、異種ジョブのコンポーネントごとに個別に呼び出されます。
The spank_init_post_opt() function is invoked once for each component of a
heterogeneous job. This permits site defined options on a per job component
basis.
spank_init_post_opt（）関数は、異種ジョブのコンポーネントごとに1回呼び出されます。これにより、ジョブコンポーネントごとにサイト定義のオプションが許可されます。
Scheduling of heterogeneous jobs is performed only by the sched/backfill
plugin and all heterogeneous job components are either all scheduled at the same
time or deferred. The pending reason of heterogeneous jobs isn't set until
backfill evaluation.
In order to ensure the timely initiation of both heterogeneous and
non-heterogeneous jobs, the backfill scheduler alternates between two different
modes on each iteration.
In the first mode, if a heterogeneous job component can not be initiated
immediately, its expected start time is recorded and all subsequent components
of that job will be considered for starting no earlier than the latest
component's expected start time.
In the second mode, all heterogeneous job components will be considered for
starting no earlier than the latest component's expected start time.
After completion of the second mode, all heterogeneous job expected start time
data is cleared and the first mode will be used in the next backfill scheduler
iteration.
Regular (non-heterogeneous jobs) are scheduled independently on each iteration
of the backfill scheduler.
異種ジョブのスケジューリングはsched / backfillプラグインによってのみ実行され、すべての異種ジョブコンポーネントはすべて同時にスケジュールされるか、延期されます。異種ジョブの保留中の理由は、バックフィルの評価まで設定されません。異種ジョブと非異種ジョブの両方をタイムリーに開始できるようにするために、バックフィルスケジューラは各反復で2つの異なるモードを交互に実行します。最初のモードでは、異種ジョブコンポーネントをすぐに開始できない場合、その予想される開始時刻が記録され、そのジョブの後続のすべてのコンポーネントは、最新のコンポーネントの予想される開始時刻より前に開始するものと見なされます。2番目のモードでは、すべての異種ジョブコンポーネントは、最新のコンポーネントの予想される開始時間よりも早く開始されたと見なされます。2番目のモードの完了後、すべての異種ジョブの予想開始時間データがクリアされ、次のバックフィルスケジューラの反復で最初のモードが使用されます。通常の（異種のジョブ）は、バックフィルスケジューラの各反復で個別にスケジュールされます。
For example, consider a heterogeneous job with three components.
When considered as independent jobs, the components could be initiated at times
now (component 0), now plus 2 hour (component 1), and now plus 1 hours
(component 2).
When the backfill scheduler runs in the first mode:
たとえば、3つのコンポーネントを持つ異種ジョブを考えてみます。独立したジョブと見なすと、コンポーネントは、現在（コンポーネント0）、2時間プラス（コンポーネント1）、および1時間プラス（コンポーネント2）の時点で開始できます。バックフィルスケジューラが最初のモードで実行される場合：
- Component 0 will be noted to possible to start now, but not initiated due
to the additional components to be initiated
コンポーネント0は、すぐに開始できることが示されますが、追加のコンポーネントが開始されるため開始されません - Component 1 will be noted to be possible to start in 2 hours
コンポーネント1は2時間で起動できることがわかります - Component 2 will not be considered for scheduling until 2 hours in the
future, which leave some additional resources available for scheduling to other
jobs
コンポーネント2は、今後2時間まではスケジュールの対象とはなりません。これにより、他のジョブがスケジュールに使用できる追加のリソースが残ります。
When the backfill scheduler executes next, it will use the second mode and
(assuming no other state changes) all three job components will be considered
available for scheduling no earlier than 2 hours in the future, which may allow
other jobs to be allocated resources before heterogeneous job component 0
could be initiated.
バックフィルスケジューラが次に実行されると、2番目のモードが使用され、（他の状態の変化がないと仮定して）3つのジョブコンポーネントすべてが将来2時間以内のスケジューリングに使用可能であると見なされます。これにより、他のジョブにリソースを割り当てることができます。異種ジョブコンポーネント0を開始できます。
The heterogeneous job start time data will be cleared before the first
mode is used in the next iteration in order to consider system status changes
which might permit the heterogeneous to be initiated at an earlier time than
previously determined.
異機種混合ジョブの開始時刻データは、次の反復で最初のモードが使用される前に消去され、以前に決定されたよりも早い時刻に異機種混合を開始できるようにするシステムステータスの変更を考慮します。
A resource limit test is performed when a heterogeneous job is submitted in
order to immediately reject jobs that will not be able to start with current
limits.
The individual components of the heterogeneous job are validated, like all
regular jobs.
The heterogeneous job as a whole is also tested, but in a more limited
fashion with respect to quality of service (QOS) limits.
This is due to the complexity of each job component having up to three sets of
limits (association, job QOS and partition QOS).
Note that successful submission of any job (heterogeneous or otherwise) does
not ensure the job will be able to start without exceeding some limit.
For example a job's CPU limit test does not consider that CPUs might not be
allocated individually, but resource allocations might be performed by whole
core, socket or node.
Each component of a heterogeneous job counts as a "job" with respect to
resource limits.
現在の制限では開始できないジョブを即座に拒否するために、異種ジョブが送信されると、リソース制限テストが実行されます。すべての通常のジョブと同様に、異種ジョブの個々のコンポーネントが検証されます。異種ジョブ全体もテストされますが、サービス品質（QOS）の制限に関してはより限定的な方法で行われます。これは、最大3セットの制限（関連付け、ジョブのQOS、パーティションのQOS）を持つ各ジョブコンポーネントの複雑さによるものです。ジョブ（異機種混合またはそれ以外）の送信が成功しても、制限を超えずにジョブを開始できるとは限らないことに注意してください。たとえば、ジョブのCPU制限テストでは、CPUが個別に割り当てられていない可能性があることは考慮されていませんが、リソースの割り当てはコア、ソケット、またはノード全体で実行される場合があります。
For example, a user might have a limit of 2 concurrent running jobs and submit
a heterogeneous job with 3 components.
Such a situation will have an adverse effect upon scheduling other jobs,
especially other heterogeneous jobs.
たとえば、ユーザーは2つのジョブを同時に実行するという制限があり、3つのコンポーネントを持つ異種ジョブをサブミットできます。このような状況は、他のジョブ、特に他の異種ジョブのスケジュールに悪影響を及ぼします。
Last modified 30 March 2020