Topology Guide

Slurm can be configured to support topology-aware resource allocation to optimize job performance. Slurm supports several modes of operation, one to optimize performance on systems with a three-dimensional torus interconnect and another for a hierarchical interconnect. The hierarchical mode of operation supports both fat-tree or dragonfly networks, using slightly different algorithms.
Slurmは、トポロジー対応のリソース割り当てをサポートしてジョブのパフォーマンスを最適化するように構成できます。Slurmはいくつかの動作モードをサポートしています。1つは3次元トーラス相互接続を備えたシステムのパフォーマンスを最適化するためのもので、もう1つは階層相互接続のためのものです。階層的な動作モードでは、わずかに異なるアルゴリズムを使用して、ファットツリーネットワークとトンボネットワークの両方がサポートされます。

Slurm's native mode of resource selection is to consider the nodes as a one-dimensional array. Jobs are allocated resources on a best-fit basis. For larger jobs, this minimizes the number of sets of consecutive nodes allocated to the job.
Slurmのリソース選択のネイティブモードは、ノードを1次元配列と見なすことです。ジョブには最適なリソースが割り当てられます。大きなジョブの場合、これにより、ジョブに割り当てられる連続ノードのセットの数が最小限になります。

Three-dimension Topology

Some larger computers rely upon a three-dimensional torus interconnect. The Cray XT and XE systems also have three-dimensional torus interconnects, but do not require that jobs execute in adjacent nodes. On those systems, Slurm only needs to allocate resources to a job which are nearby on the network. Slurm accomplishes this using a Hilbert curve to map the nodes from a three-dimensional space into a one-dimensional space. Slurm's native best-fit algorithm is thus able to achieve a high degree of locality for jobs.
一部の大規模なコンピューターは、3次元トーラス相互接続に依存しています。Cray XTおよびXEシステムにも3次元トーラス相互接続がありますが、隣接ノードでジョブを実行する必要はありません。これらのシステムでは、Slurmはネットワーク上の近くにあるジョブにリソースを割り当てるだけで済みます。Slurmは、ヒルベルト曲線を使用してノードを3次元空間から1次元空間にマッピングしてこれを実現します。したがって、Slurmのネイティブの最適アルゴリズムは、ジョブの高度な局所性を実現できます。

Hierarchical Networks

Slurm can also be configured to allocate resources to jobs on a hierarchical network to minimize network contention. The basic algorithm is to identify the lowest level switch in the hierarchy that can satisfy a job's request and then allocate resources on its underlying leaf switches using a best-fit algorithm. Use of this logic requires a configuration setting of TopologyPlugin=topology/tree.
Slurmは、ネットワークの競合を最小限に抑えるために、階層ネットワーク上のジョブにリソースを割り当てるように構成することもできます。基本的なアルゴリズムは、ジョブの要求を満たすことができる階層内の最低レベルのスイッチを識別し、最適なアルゴリズムを使用して、その基礎となるリーフスイッチにリソースを割り当てることです。このロジックを使用するには、TopologyPlugin = topology / treeの構成設定が必要です。

Note that slurm uses a best-fit algorithm on the currently available resources. This may result in an allocation with more that the optimum number of switches. The user can request a maximum number of switches for the job as well as a maximum time willing to wait for that number using the --switches option with the salloc, sbatch and srun commands. The parameters can also be changed for pending jobs using the scontrol and squeue commands.
slurmは、現在利用可能なリソースに最適なアルゴリズムを使用することに注意してください。これにより、最適な数を超えるスイッチが割り当てられる可能性があります。ユーザーは、sswitch、sbatch、srunコマンドの--switchesオプションを使用して、ジョブのスイッチの最大数とその数を待機する最大時間を要求できます。scontrolコマンドとsqueueコマンドを使用して、保留中のジョブのパラメータを変更することもできます。

At some point in the future Slurm code may be provided to gather network topology information directly. Now the network topology information must be included in a topology.conf configuration file as shown in the examples below.
将来のある時点で、ネットワークトポロジー情報を直接収集するためにSlurmコードが提供される可能性があります。次の例に示すように、ネットワークトポロジ情報をtopology.conf構成ファイルに含める必要があります。
The first example describes a three level switch in which each switch has two children. Note that the SwitchName values are arbitrary and only used to bookkeeping purposes, but a name must be specified on each line.
最初の例では、各スイッチに2つの子がある3レベルのスイッチについて説明します。SwitchNameの値は任意であり、簿記目的でのみ使用されますが、名前は各行に指定する必要があります。
The leaf switch descriptions contain a SwitchName field plus a Nodes field to identify the nodes connected to the switch.
リーフスイッチの説明には、SwitchNameフィールドと、スイッチに接続されているノードを識別するNodesフィールドが含まれています。
Higher-level switch descriptions contain a SwitchName field plus a Switches field to identify the child switches. Slurm's hostlist expression parser is used, so the node and switch names need not be consecutive (e.g. "Nodes=tux[0-3,12,18-20]" and "Switches=s[0-2,4-8,12]" will parse fine).
上位レベルのスイッチの説明には、SwitchNameフィールドと、子スイッチを識別するためのSwitchフィールドが含まれています。Slurmのホストリスト式パーサーが使用されるため、ノード名とスイッチ名を連続させる必要はありません（例： "Nodes = tux [0-3,12,18-20]"と "Switches = s [0-2,4-8,12 ] "は正常に解析されます）。

An optional LinkSpeed option can be used to indicate the relative performance of the link. The units used are arbitrary and this information is currently not used. It may be used in the future to optimize resource allocations.
オプションのLinkSpeedオプションを使用して、リンクの相対的なパフォーマンスを示すことができます。使用される単位は任意であり、この情報は現在使用されていません。将来、リソース割り当てを最適化するために使用される可能性があります。

The first example shows what a topology would look like for an eight node cluster in which all switches have only two children as shown in the diagram (not a very realistic configuration, but useful for an example).
最初の例は、図に示すように、すべてのスイッチに2つの子しかない8ノードクラスタのトポロジを示しています（非常に現実的な構成ではありませんが、例としては役立ちます）。

# topology.conf
# Switch Configuration
SwitchName=s0 Nodes=tux[0-1]
SwitchName=s1 Nodes=tux[2-3]
SwitchName=s2 Nodes=tux[4-5]
SwitchName=s3 Nodes=tux[6-7]
SwitchName=s4 Switches=s[0-1]
SwitchName=s5 Switches=s[2-3]
SwitchName=s6 Switches=s[4-5]

The next example is for a network with two levels and each switch has four connections.
次の例は、2つのレベルを持つネットワークで、各スイッチには4つの接続があります。

# topology.conf
# Switch Configuration
SwitchName=s0 Nodes=tux[0-3]   LinkSpeed=900
SwitchName=s1 Nodes=tux[4-7]   LinkSpeed=900
SwitchName=s2 Nodes=tux[8-11]  LinkSpeed=900
SwitchName=s3 Nodes=tux[12-15] LinkSpeed=1800
SwitchName=s4 Switches=s[0-3]  LinkSpeed=1800
SwitchName=s5 Switches=s[0-3]  LinkSpeed=1800
SwitchName=s6 Switches=s[0-3]  LinkSpeed=1800
SwitchName=s7 Switches=s[0-3]  LinkSpeed=1800

As a practical matter, listing every switch connection definitely results in a slower scheduling algorithm for Slurm to optimize job placement. The application performance may achieve little benefit from such optimization. Listing the leaf switches with their nodes plus one top level switch should result in good performance for both applications and Slurm. The previous example might be configured as follows:
実際問題として、すべてのスイッチ接続をリストすると、ジョブ配置を最適化するためのSlurmのスケジューリングアルゴリズムが明らかに遅くなります。アプリケーションのパフォーマンスは、そのような最適化からほとんど利益を得ることができません。リーフスイッチとそのノードおよび1つの最上位スイッチをリストすると、アプリケーションとSlurmの両方で良好なパフォーマンスが得られます。前の例は、次のように構成できます。

# topology.conf
# Switch Configuration
SwitchName=s0 Nodes=tux[0-3]
SwitchName=s1 Nodes=tux[4-7]
SwitchName=s2 Nodes=tux[8-11]
SwitchName=s3 Nodes=tux[12-15]
SwitchName=s4 Switches=s[0-3]

Note that compute nodes on switches that lack a common parent switch can be used, but no job will span leaf switches without a common parent (unless the TopologyParam=TopoOptional option is used). For example, it is legal to remove the line "SwitchName=s4 Switches=s[0-3]" from the above topology.conf file. In that case, no job will span more than four compute nodes on any single leaf switch. This configuration can be useful if one wants to schedule multiple physical clusters as a single logical cluster under the control of a single slurmctld daemon.
共通の親スイッチがないスイッチ上の計算ノードを使用できますが、（TopologyParam = TopoOptionalオプションが使用されていない限り）ジョブは共通の親がないとリーフスイッチにまたがることはありません。たとえば、上記のtopology.confファイルから「SwitchName = s4 Switches = s [0-3]」という行を削除することは正当です。その場合、単一のリーフスイッチで4つを超える計算ノードにまたがるジョブはありません。この構成は、単一のslurmctldデーモンの制御下で複数の物理クラスターを単一の論理クラスターとしてスケジュールする場合に役立ちます。

For systems with a dragonfly network, configure Slurm with TopologyPlugin=topology/tree plus TopologyParam=dragonfly. If a single job can not be entirely placed within a single network leaf switch, the job will be spread across as many leaf switches as possible in order to optimize the job's network bandwidth.
トンボネットワークを備えたシステムの場合、TopologyPlugin = topology / treeおよびTopologyParam = dragonflyを使用してSlurmを構成します。単一のジョブを単一のネットワークリーフスイッチ内に完全に配置できない場合、ジョブのネットワーク帯域幅を最適化するために、ジョブはできるだけ多くのリーフスイッチに分散されます。

NOTE:Slurm first identifies the network switches which provide the best fit for pending jobs and then selects the nodes with the lowest "weight" within those switches. If optimizing resource selection by node weight is more important than optimizing network topology then do NOT use the topology/tree plugin.
注：Slurmは、保留中のジョブに最適なネットワークスイッチを最初に識別し、それらのスイッチ内で最も「重み」が低いノードを選択します。ノードの重みによるリソース選択の最適化がネットワークトポロジの最適化よりも重要である場合は、トポロジ/ツリープラグインを使用しないでください。

NOTE:The topology.conf file for an Infiniband switch can be automatically generated using the slurmibtopology tool found here:
注：Infinibandスイッチのtopology.confファイルは、次の場所にあるslurmibtopologyツールを使用して自動的に生成できます。

https://ftp.fysik.dtu.dk/Slurm/slurmibtopology.sh.

NOTE:The topology.conf file for an Omni-Path (OPA) switch can be automatically generated using the opa2slurm tool found here:
注：Omni-Path（OPA）スイッチのtopology.confファイルは、ここにあるopa2slurmツールを使用して自動的に生成できます。

https://gitlab.com/jtfrey/opa2slurm.

User Options

For use with the topology/tree plugin, user can also specify the maximum number of leaf switches to be used for their job with the maximum time the job should wait for this optimized configuration. The syntax for this option is "--switches=count[@time]".
トポロジ/ツリープラグインで使用する場合、ユーザーは、ジョブに使用されるリーフスイッチの最大数と、ジョブがこの最適化された構成を待機する最大時間を指定することもできます。このオプションの構文は、「-switches = count [@time]」です。
The system administrator can limit the maximum time that any job can wait for this optimized configuration using the SchedulerParameters configuration parameter with the max_switch_wait option.
システム管理者は、max_switch_waitオプションを指定したSchedulerParameters構成パラメーターを使用して、ジョブがこの最適化された構成を待機できる最大時間を制限できます。

Environment Variables

If the topology/tree plugin is used, two environment variables will be set to describe that job's network topology. Note that these environment variables will contain different data for the tasks launched on each node. Use of these environment variables is at the discretion of the user.
トポロジ/ツリープラグインが使用されている場合、そのジョブのネットワークトポロジを説明するために2つの環境変数が設定されます。これらの環境変数には、各ノードで起動されたタスクの異なるデータが含まれることに注意してください。これらの環境変数の使用は、ユーザーの裁量に任されています。

SLURM_TOPOLOGY_ADDR: The value will be set to the names network switches which may be involved in the job's communications from the system's top level switch down to the leaf switch and ending with node name. A period is used to separate each hardware component name.
SLURM_TOPOLOGY_ADDR：この値は、ネットワークスイッチの名前に設定されます。ネットワークスイッチは、システムのトップレベルスイッチからリーフスイッチまでのジョブの通信に関与し、ノード名で終了する可能性があります。ピリオドは、各ハードウェアコンポーネント名を区切るために使用されます。

SLURM_TOPOLOGY_ADDR_PATTERN: This is set only if the system has the topology/tree plugin configured. The value will be set component types listed in SLURM_TOPOLOGY_ADDR. Each component will be identified as either "switch" or "node". A period is used to separate each hardware component type.
SLURM_TOPOLOGY_ADDR_PATTERN：これは、システムにトポロジー/ツリープラグインが構成されている場合にのみ設定されます。値は、SLURM_TOPOLOGY_ADDRにリストされているコンポーネントタイプに設定されます。各コンポーネントは、「スイッチ」または「ノード」として識別されます。ピリオドは、各ハードウェアコンポーネントタイプを区切るために使用されます。

Last modified 14 June 2018