Generic Resource (GRES) Design Guide
Overview
Generic Resources (GRES) are resources associated with a specific node
that can be allocated to jobs and steps. The most obvious example of
GRES use would be GPUs. GRES are identified by a specific name and use an
optional plugin to provide device-specific support. This document is meant
to provide details about Slurm's implementation of GRES support including the
relevant data structures. For an overview of GRES configuration and use, see
Generic Resource (GRES) Scheduling. For details about
the APIs provided by GRES plugins, see
Slurm Generic Resource (GRES) Plugin API.
汎用リソース（GRES）は、ジョブとステップに割り当てることができる特定のノードに関連付けられたリソースです。GRESの最も明白な使用例はGPUです。GRESは特定の名前で識別され、オプションのプラグインを使用してデバイス固有のサポートを提供します。このドキュメントは、関連するデータ構造を含む、SlurmのGRESサポートの実装に関する詳細を提供することを目的としています。GRESの構成と使用の概要については、汎用リソース（GRES）のスケジューリングを参照してください。GRESプラグインによって提供されるAPIの詳細については、Slurm Generic Resource（GRES）プラグインAPIを参照してください。
Data Structures
GRES are associated with Slurm nodes, jobs and job steps. You will find
a string variable named gres in those data structures which
is used to store the GRES configured on a node or required by a job or step
(e.g. "gpu:2,nic:1"). This string is also visible to various Slurm commands
viewing information about those data structures (e.g. "scontrol show job").
There is a second variable associated with each of those data structures on
the slurmctld daemon
named gres_list that is intended for program use only. Each element
in the list gres_list provides information about a specific GRES type
(e.g. one data structure for "gpu" and a second structure with information
about "nic"). The structures on gres_list contain an ID number
(which is faster to compare than a string) plus a pointer to another structure.
This second structure differs somewhat for nodes, jobs, and steps (see
gres_node_state_t, gres_job_state_t, and gres_step_state_t in
src/common/gres.h for details), but contains various counters and bitmaps.
Since these data structures differ for various entity types, the functions
used to work with them are also different. If no GRES are associated with a
node, job or step, then both gres and gres_list will be NULL.
GRESはSlurmノード、ジョブ、およびジョブステップに関連付けられています。ノードで構成された、またはジョブやステップで必要なGRESを格納するために使用されるデータ構造内に、gresという名前の文字列変数があります（例： "gpu：2、nic：1"）。この文字列は、これらのデータ構造に関する情報を表示するさまざまなSlurmコマンド（たとえば、「scontrol show job」）にも表示されます。slurmctldデーモンには、プログラムの使用のみを目的としたgres_listという名前の各データ構造に関連付けられた2番目の変数があります。リストgres_listの各要素は、特定のGRESタイプに関する情報を提供します（たとえば、「gpu」の1つのデータ構造と「nic」に関する情報を持つ2番目の構造）。gres_listの構造体には、ID番号（文字列よりも比較が速い）と別の構造体へのポインターが含まれています。この2番目の構造は、ノード、ジョブ、およびステップで多少異なります（詳細については、src / common / gres.hのgres_node_state_t、gres_job_state_t、およびgres_step_state_tを参照）、さまざまなカウンターとビットマップが含まれています。これらのデータ構造はさまざまなエンティティタイプによって異なるため、それらを操作するために使用される関数も異なります。ノード、ジョブ、またはステップに関連付けられているGRESがない場合、gresとgres_listの両方がNULLになります。
------------------------
| Job Information |
|----------------------|
| gres = "gpu:2,nic:1" |
| gres_list |
------------------------
|
+---------------------------------
| |
------------------ ------------------
| List Struct | | List Struct |
|----------------| |----------------|
| id = 123 (gpu) | | id = 124 (nic) |
| gres_data | | gres_data |
------------------ ------------------
| |
| ....
|
|
------------------------------------------------
| gres_job_state_t |
|----------------------------------------------|
| gres_count = 2 |
| node_count = 3 |
| gres_bitmap(by node) = 0,1; |
| 2,3; |
| 0,2 |
| gres_count_allocated_to_steps(by node) = 1; |
| 1; |
| 1 |
| gres_bitmap_allocated_to_steps(by node) = 0; |
| 2; |
| 0 |
------------------------------------------------
Mode of Operation
After the slurmd daemon reads the configuration files, it calls the function
node_config_load() for each configured plugin. This can be used to
validate the configuration, for example validate that the appropriate devices
actually exist. If no GRES plugin exists for that resource type, the information
in the configuration file is assumed correct. Each node's GRES information is
reported by slurmd to the slurmctld daemon at node registration time.
slurmdデーモンが構成ファイルを読み取った後、構成されたプラグインごとに関数node_config_load（）を呼び出します。これは、構成を検証するために使用できます。たとえば、適切なデバイスが実際に存在することを検証できます。そのリソースタイプにGRESプラグインが存在しない場合、構成ファイルの情報は正しいと見なされます。各ノードのGRES情報は、ノード登録時にslurmdによってslurmctldデーモンに報告されます。
The slurmctld daemon maintains GRES information in the data structures
described above for each node, including the number of configured and allocated
resources. If those resources are identified with a specific device file
rather than just a count, bitmaps are used record which specific resources have
been allocated to jobs.
slurmctldデーモンは、構成および割り当てられたリソースの数を含む、各ノードについて上記のデータ構造でGRES情報を維持します。これらのリソースがカウントだけでなく特定のデバイスファイルで識別される場合、ビットマップは、ジョブに割り当てられている特定のリソースを記録するために使用されます。
The slurmctld daemon's GRES information about jobs includes several arrays
equal in length to the number of allocated nodes. The index into each of the
arrays is the sequence number of the node in that's job's allocation (e.g.
the first element is node zero of the job allocation). The job step's
GRES information is similar to that of a job including the design where the
index into arrays is based upon the job's allocation. This means when a job
step is allocated or terminates, the required bitmap operations are very
easy to perform without computing different index values for job and step
data structures.
slurmctldデーモンのジョブに関するGRES情報には、割り当てられたノードの数と同じ長さの配列がいくつか含まれています。各配列へのインデックスは、そのジョブの割り当てにおけるノードのシーケンス番号です（たとえば、最初の要素はジョブ割り当てのノード0です）。ジョブステップのGRES情報は、配列へのインデックスがジョブの割り当てに基づいている設計を含むジョブのGRES情報に似ています。つまり、ジョブステップが割り当てられるか終了すると、ジョブとステップのデータ構造に異なるインデックス値を計算しなくても、必要なビットマップ操作を簡単に実行できます。
The most complex operation on the GRES data structures happens when a job
changes size (has nodes added or removed). In that case, the array indexed by
node index must be rebuilt, with records shifting as appropriate. Note that
the current software is not compatible with having different GRES counts by
node (a job can not have 2 GPUs on one node and 1 GPU on a second node),
although that might be addressed at a later time.
GRESデータ構造に対する最も複雑な操作は、ジョブのサイズが変更された（ノードが追加または削除された）ときに発生します。その場合、ノードインデックスでインデックス付けされた配列を再構築して、レコードを適切にシフトする必要があります。現在のソフトウェアはノードごとに異なるGRESカウントを持つことと互換性がないことに注意してください（ジョブは1つのノードに2つのGPUを持ち、2番目のノードに1つのGPUを持つことはできません）。
When a job or step is initiated, its credential includes allocated GRES information.
This can be used by the slurmd daemon to associate those resources with that
job. Our plan is to use the Linux cgroups logic to bind a job and/or its
tasks with specific GRES devices, however that logic does not currently exist.
What does exist today is a pair of plugin APIs, job_set_env() and
step_set_env() which can be used to set environment variables for the
program directing it to GRES which have been allocated for its use (the CUDA
libraries base their GPU selection upon environment variables, so this logic
should work for CUDA today if users do not attempt to manipulate the
environment variables reserved for CUDA use).
ジョブまたはステップが開始されると、その資格情報には割り当てられたGRES情報が含まれます。これは、slurmdデーモンがこれらのリソースをそのジョブに関連付けるために使用できます。私たちの計画は、Linux cgroupsロジックを使用して、ジョブおよび/またはそのタスクを特定のGRESデバイスにバインドすることですが、そのロジックは現在存在しません。現在存在しているのは、プラグインAPIのペアであるjob_set_env（）とstep_set_env（）であり、それらを使用するために割り当てられているGRESに指示するプログラムの環境変数を設定できます（CUDAライブラリは、環境に基づいてGPU選択を行います変数なので、ユーザーがCUDAで使用するために予約されている環境変数を操作しようとしない場合、このロジックは今日CUDAで機能するはずです。
If you want to see how GRES logic is allocating resources, configure
DebugFlags=GRES to log GRES state changes. Note the resulting output can
be quite verbose, especially for larger clusters.
GRESロジックがリソースを割り当てる方法を確認する場合は、GRESの状態変化をログに記録するようにDebugFlags = GRESを構成します。特に大きなクラスターの場合、結果の出力は非常に冗長になる可能性があることに注意してください。
Last modified 18 May 2011