Network Configuration Guide

Contents

Overview
Communication for slurmctld
Communication for slurmdbd
Communication for slurmd
Communication for client commands
Communication for multiple controllers
Communication with multiple clusters
Communication in a federation

Overview

There are a lot of components in a Slurm cluster that need to be able to communicate with each other.
Slurmクラスターには、相互に通信できる必要のあるコンポーネントがたくさんあります。
Some sites have security requirements that prevent them from opening all communications between the machines and will need to be able to selectively open just the ports that are necessary.
一部のサイトには、マシン間のすべての通信を開くことができないセキュリティ要件があり、必要なポートのみを選択的に開くことができる必要があります。
This document will go over what is needed for different components to be able to talk to each other.
このドキュメントでは、さまざまなコンポーネントが相互に通信できるようにするために必要なものについて説明します。

Below is a diagram of a fairly typical cluster, with slurmctld and slurmdbd on separate machines.
以下は、slurmctldとslurmdbdが別々のマシンにあるかなり典型的なクラスターの図です。
In smaller clusters, MySQL can run on the same machine as the slurmdbd, but in most cases it is preferable to have it run on a dedicated machine.
小規模なクラスターでは、MySQLはslurmdbdと同じマシンで実行できますが、ほとんどの場合、専用のマシンで実行することをお勧めします。
slurmd runs on the compute nodes and the client commands can be installed and run from machines of your choosing.
slurmdは計算ノードで実行され、クライアントコマンドは選択したマシンからインストールして実行できます。


Typical configuration

Communication for slurmctld

The default port used by slurmctld to listen for incoming requests is 6817.
slurmctldが着信要求をリッスンするために使用するデフォルトのポートは6817です。
This port can be changed with the SlurmctldPort slurm.conf parameter.
このポートは、SlurmctldPortslurm.confパラメーターを使用して変更できます。
Slurmctld listens for incoming requests on that port and responds back on the same connection opened by the requestor.
Slurmctldは、そのポートで着信要求をリッスンし、リクエスターによって開かれた同じ接続で応答します。

The machine running slurmctld needs to be able to establish outbound connections as well.
slurmctldを実行しているマシンは、アウトバウンド接続も確立できる必要があります。
It needs to communicate with slurmdbd on port 6819 by default (see the slurmdbd section for information on how to change this).
デフォルトでは、ポート6819でslurmdbdと通信する必要があります(これを変更する方法については、slurmdbdセクションを参照してください)。
It also needs to communicate with slurmd on the compute nodes on port 6818 by default (see the slurmd section for information on how to change this).
また、デフォルトでポート6818の計算ノードのslurmdと通信する必要があります(これを変更する方法については、slurmdのセクションを参照してください)。

By default, the slurmctld will listen for IPv4 traffic.
デフォルトでは、slurmctldはIPv4トラフィックをリッスンします。
IPv6 communication can be enabled by adding EnableIPv6 to the CommunicationParameters in your slurm.conf.
IPv6通信を有効にするには、slurm.confのCommunicationParametersにEnableIPv6を追加します。
With IPv6 enabled, you can disable IPv4 by adding DisableIPv4 to the CommunicationParameters.
IPv6を有効にした状態で、CommunicationParametersにDisableIPv4を追加することにより、IPv4を無効にできます。
These settings must match in both slurmdbd.conf and slurm.conf (see the slurmdbd section).
これらの設定は、slurmdbd.confとslurm.confの両方で一致する必要があります(slurmdbdセクションを参照)。

Communication for slurmdbd

The default port used by slurmdbd to listen for incoming requests is 6819.
slurmdbdが着信要求をリッスンするために使用するデフォルトのポートは6819です。
This port can be changed with the DbdPort slurmdbd.conf parameter.
このポートは、DbdPortslurmdbd.confパラメーターを使用して変更できます。
Slurmdbd listens for incoming requests on that port and responds back on the same connection opened by the requestor.
Slurmdbdは、そのポートで着信要求をリッスンし、リクエスターによって開かれた同じ接続で応答します。

The machine running slurmdbd needs to be able to reach the MySQL or MariaDB server on port 3306 by default (the port is configurable on the database side).
slurmdbdを実行しているマシンは、デフォルトでポート3306でMySQLまたはMariaDBサーバーに到達できる必要があります(ポートはデータベース側で構成可能です)。
This port can be changed with the StoragePort slurmdbd.conf parameter.
このポートは、StoragePortslurmdbd.confパラメーターを使用して変更できます。
It also needs to be able to initiate a connection to slurmctld on port 6819 by default (see the slurmctld section for information on how to change this).
また、デフォルトでポート6819でslurmctldへの接続を開始できる必要があります(これを変更する方法については、slurmctldセクションを参照してください)。

By default, the slurmdbd will listen for IPv4 traffic.
デフォルトでは、slurmdbdはIPv4トラフィックをリッスンします。
IPv6 communication can be enabled by adding EnableIPv6 to the CommunicationParameters in your slurmdbd.conf.
IPv6通信を有効にするには、slurmdbd.confのCommunicationParametersにEnableIPv6を追加します。
With IPv6 enabled, you can disable IPv4 by adding DisableIPv4 to the CommunicationParameters.
IPv6を有効にした状態で、CommunicationParametersにDisableIPv4を追加することにより、IPv4を無効にできます。
These settings must match in both slurmdbd.conf and slurm.conf (see the slurmctld section).
これらの設定は、slurmdbd.confとslurm.confの両方で一致する必要があります(slurmctldセクションを参照)。

Communication for slurmd

The default port used by slurmd to listen for incoming requests from slurmctld is 6818.
slurmdがslurmctldからの着信要求をリッスンするために使用するデフォルトのポートは6818です。
This port can be changed with the SlurmdPort slurm.conf parameter.
このポートは、SlurmdPortslurm.confパラメーターを使用して変更できます。

The machines running srun also use a range of ports to be able to communicate with slurmstepd.
srunを実行しているマシンは、slurmstepdと通信できるようにさまざまなポートも使用します。
By default these ports are chosen at random from the ephemeral port range, but you can use the SrunPortRange to specify a range of ports from which they can be chosen.
デフォルトでは、これらのポートはエフェメラルポート範囲からランダムに選択されますが、SrunPortRangeを使用して、選択できるポートの範囲を指定できます。
This is necessary for login nodes that are behind a firewall.
これは、ファイアウォールの背後にあるログインノードに必要です。

The machines running slurmd need to be able to establish connections with slurmctld on port 6817 by default (see the slurmctld section for information on how to change this).
slurmdを実行しているマシンは、デフォルトでポート6817でslurmctldとの接続を確立できる必要があります(これを変更する方法については、slurmctldセクションを参照してください)。

By default, the slurmd communicates over IPv4.
デフォルトでは、slurmdはIPv4を介して通信します。
Please see the slurmctld section for details on how to change this as the slurm.conf parameter affects slurmd daemons as well.
slurm.confパラメーターはslurmdデーモンにも影響するため、これを変更する方法の詳細については、slurmctldセクションを参照してください。

Communication for client commands

The majority of the client commands will communicate with slurmctld on port 6817 by default (see the slurmctld section for information on how to change this) to get the information they need.
クライアントコマンドの大部分は、デフォルトでポート6817のslurmctldと通信し(これを変更する方法については、slurmctldのセクションを参照)、必要な情報を取得します。
This includes the following commands:


これには、次のコマンドが含まれます。
salloc
sacctmgr
sbatch
sbcast
scancel
scontrol
sdiag
sinfo
sprio
squeue
sshare
sstat
strigger
sview

There are also commands that communicate directly with slurmdbd on port 6819 by default (see the slurmdbd section for information on how to change this).
デフォルトでは、ポート6819のslurmdbdと直接通信するコマンドもあります(これを変更する方法については、slurmdbdのセクションを参照してください)。
The following commands get information from slurmdbd:


次のコマンドは、slurmdbdから情報を取得します。
sacct
sacctmgr
sreport

When a user starts a job using srun there has to be a communication path from the machine where srun is called to the node(s) the job is allocated.
ユーザーがsrunを使用してジョブを開始するときは、srunが呼び出されたマシンからジョブが割り当てられているノードへの通信パスが必要です。
Communication follows the sequence outlined below:


通信は、以下に概説する順序に従います。
1a. srun sends job allocation request to slurmctld
1a。srunはジョブ割り当て要求をslurmctldに送信します
1b. slurmctld grants allocation and returns details
1b。slurmctldは割り当てを許可し、詳細を返します
2a. srun sends step create request to slurmctld
2a。srunはステップ作成要求をslurmctldに送信します
2b. slurmctld responds with step credential
2b。slurmctldはステップクレデンシャルで応答します
3. srun opens sockets for I/O
3.srunはI / O用のソケットを開きます
4. srun forwards credential with task info to slurmd
4. srunは、タスク情報を含むクレデンシャルをslurmdに転送します
5. slurmd forwards request as needed (per fanout)
5. slurmdは必要に応じてリクエストを転送します(ファンアウトごと)
6. slurmd forks/execs slurmstepd
6.slurmdフォーク/エグゼクティブslurmstepd
7. slurmstepd connects I/O and launches tasks
7.slurmstepdはI / Oを接続し、タスクを起動します
8. On task termination, slurmstepd notifies srun
8.タスクの終了時に、slurmstepdはsrunに通知します
9. srun notifies slurmctld of job termination
9.srunはslurmctldにジョブの終了を通知します
10. slurmctld verifies termination of all processes via slurmd and releases resources for next job
10. slurmctldは、slurmdを介してすべてのプロセスの終了を確認し、次のジョブのためにリソースを解放します

srun communication

Communication with multiple controllers

You can configure a secondary slurmctld and/or slurmdbd to serve as a fallback if the primary should go down.
プライマリがダウンした場合のフォールバックとして機能するように、セカンダリslurmctldやslurmdbdを構成できます。
The ports involved don't change, but there are additional communication paths that need to be taken into consideration.
関連するポートは変更されませんが、考慮する必要のある追加の通信パスがあります。
The client commands need to be able to reach both machines running slurmctld as well as both machines running slurmdbd.
クライアントコマンドは、slurmctldを実行している両方のマシンとslurmdbdを実行している両方のマシンに到達できる必要があります。
Both instances of slurmctld need to be able to reach both instances of slurmdbd and each slurmdbd needs to be able to reach the MySQL server.
slurmctldの両方のインスタンスがslurmdbdの両方のインスタンスに到達できる必要があり、各slurmdbdがMySQLサーバーに到達できる必要があります。


Fallback slurmctld and slurmdbd

Communication with multiple clusters

In environments where multiple slurmctld instances share the same slurmdbd you can configure each cluster to stand on their own and allow users to specify a cluster to submit their jobs to.
複数のslurmctldインスタンスが同じslurmdbdを共有する環境では、各クラスターが独立するように構成し、ユーザーがジョブを送信するクラスターを指定できるようにすることができます。
Ports used by the different daemons don't change, but all instances of slurmctld need to be able to communicate with the same instance of slurmdbd.
異なるデーモンが使用するポートは変更されませんが、slurmctldのすべてのインスタンスがslurmdbdの同じインスタンスと通信できる必要があります。
You can read more about multi cluster configurations in the Multi-Cluster Operation documentation.
マルチクラスター構成の詳細については、マルチクラスター操作のドキュメントを参照してください。


Multi-Cluster configuration

Communication in a federation

Slurm also provides the ability to schedule jobs in a peer-to-peer fashion between multiple clusters, allowing jobs to run on the cluster that has available resources first.
Slurmは、複数のクラスター間でピアツーピア方式でジョブをスケジュールする機能も提供し、使用可能なリソースが最初にあるクラスターでジョブを実行できるようにします。
The difference in communication needs between this and a multi-cluster configuration is that the two instances of slurmctld need to be able to communicate with each other.
これとマルチクラスター構成の通信ニーズの違いは、slurmctldの2つのインスタンスが相互に通信できる必要があることです。
There are more details about using a Federation in the documentation.
フェデレーションの使用に関する詳細は、ドキュメントにあります。


Federation configuration

Communication with IPv6

The slurmctld, slurmdbd, and slurmd daemons will, by default, communicate using IPv4, but they can be configured to use IPv6.
slurmctld、slurmdbd、およびslurmdデーモンは、デフォルトでIPv4を使用して通信しますが、IPv6を使用するように構成できます。
This is handled by setting CommunicationParameters=EnableIPv6 in your slurm.conf and slurmdbd.conf, then restarting all of the daemons.
これは、slurm.confおよびslurmdbd.confでCommunicationParameters = EnableIPv6を設定してから、すべてのデーモンを再起動することで処理されます。
The slurmd may operate over IPv4 OR IPv6 in this mode.
slurmdは、このモードでIPv4またはIPv6を介して動作する場合があります。
IPv4 can be disabled by setting CommunicationParameters=EnableIPv6,DisableIPv4.
CommunicationParameters = EnableIPv6、DisableIPv4を設定することにより、IPv4を無効にできます。
In is mode, everything must have a valid IPv6 address or the conection will fail.
isモードでは、すべてに有効なIPv6アドレスが必要です。そうでない場合、接続は失敗します。

The slurmctld expects a node to map to a single IP address (which will be the first address returned when looking up the IP of the node with getaddrinfo()).
slurmctldは、ノードが単一のIPアドレス(getaddrinfo()でノードのIPを検索するときに返される最初のアドレスになります)にマップすることを想定しています。
If you enable IPv6 on an existing cluster and the nodes have IPv6 addresses, you must restart the slurmd daemons for communication over IPv6 to be established.
既存のクラスターでIPv6を有効にし、ノードにIPv6アドレスがある場合、IPv6を介した通信を確立するには、slurmdデーモンを再起動する必要があります。

The presence of precedence ::ffff:0:0/96 100 in /etc/gai.conf will cause IPv4 addresses to be returned BEFORE an IPv6 address.
/etc/gai.confに優先順位:: ffff:0:0/96 100が存在すると、IPv6アドレスの前にIPv4アドレスが返されます。
This might cause a situation where you have enabled IPv6 for Slurm, but are still seeing nodes communicate with IPv4.
これにより、Slurmに対してIPv6を有効にしたにもかかわらず、ノードがIPv4と通信しているのを確認している状況が発生する可能性があります。
If there is confusion as to which address is being used you can call scontrol setdebugflags +NET to enable network related debug logging in your slurmctld.log.
使用されているアドレスがわからない場合は、scontrol setdebugflags + NETを呼び出して、slurmctld.logでネットワーク関連のデバッグログを有効にすることができます。

If IPv4 and IPv6 are enabled, the loopback interface may still resolve to 127.0.0.1.
IPv4とIPv6が有効になっている場合でも、ループバックインターフェイスは127.0.0.1に解決される可能性があります。
This is not necessarily an indication of a problem.
これは必ずしも問題を示しているわけではありません。

Last modified 25 November 2020