Large Cluster Administration Guide

This document contains Slurm administrator information specifically for clusters containing 1,024 nodes or more.
このドキュメントには、1,024ノード以上を含むクラスター専用のSlurm管理者情報が含まれています。
Large systems currently managed by Slurm include Tianhe-2 (at the National University of Defense Technology in China with 16,000 compute nodes and 3.1 million cores) and Sequoia (IBM Bluegene/Q at Lawrence Livermore National Laboratory with 98,304 compute nodes and 1.6 million cores).
現在Slurmが管理している大規模システムには、Tianhe-2（16,000の計算ノードと310万のコアを備えた中国の国防科技大学）とSequoia（98,304の計算ノードと160万のコアを備えたローレンスリバモア国立研究所のIBM Bluegene / Q）が含まれます。 。
Slurm operation on systems orders of magnitude larger has been validated using emulation.
桁違いに大きいシステムでのSlurm動作は、エミュレーションを使用して検証されています。
Getting optimal performance at that scale does require some tuning and this document should help get you off to a good start.
その規模で最適なパフォーマンスを得るには、ある程度の調整が必要です。このドキュメントは、良いスタートを切るのに役立つはずです。
A working knowledge of Slurm should be considered a prerequisite for this material.
Slurmの実用的な知識は、この資料の前提条件と見なす必要があります。

Performance

Times below are for execution of an MPI program printing "Hello world" and exiting and includes the time for processing output.
以下の時間は、「Hello world」を印刷して終了するMPIプログラムの実行時間であり、出力の処理時間も含まれます。
Your performance may vary due to differences in hardware, software, and configuration.
ハードウェア、ソフトウェア、および構成の違いにより、パフォーマンスが異なる場合があります。

• 1,966,080 tasks on 122,880 compute nodes of a BlueGene/Q: 322 seconds
  BlueGene / Qの122,880個の計算ノードでの1,966,080個のタスク：322秒
  
• 30,000 tasks on 15,000 compute nodes of a Linux cluster: 30 seconds
  Linuxクラスターの15,000の計算ノードで30,000のタスク：30秒
  

System Configuration

Three system configuration parameters must be set to support a large number of open files and TCP connections with large bursts of messages.
多数の開いているファイルと大量のメッセージバーストを伴うTCP接続をサポートするには、3つのシステム構成パラメーターを設定する必要があります。
Changes can be made using the /etc/rc.d/rc.local or /etc/sysctl.conf script to preserve changes after reboot.
/etc/rc.d/rc.localまたは/etc/sysctl.confスクリプトを使用して変更を加え、再起動後の変更を保持できます。
In either case, you can write values directly into these files (e.g. "echo 32832 > /proc/sys/fs/file-max").
いずれの場合も、これらのファイルに直接値を書き込むことができます（例：「echo32832＞ / proc / sys / fs / file-max」）。

• /proc/sys/fs/file-max: The maximum number of concurrently open files.
  / proc / sys / fs / file-max：同時に開くファイルの最大数。
  We recommend a limit of at least 32,832.
  少なくとも32,832の制限をお勧めします。
  
• /proc/sys/net/ipv4/tcp_max_syn_backlog: Maximum number of remembered connection requests, which still have not received an acknowledgment from the connecting client.
  / proc / sys / net / ipv4 / tcp_max_syn_backlog：接続しているクライアントからの確認応答をまだ受信していない、記憶されている接続要求の最大数。
  The default value is 1024 for systems with more than 128Mb of memory, and 128 for low memory machines.
  デフォルト値は、128Mbを超えるメモリを備えたシステムの場合は1024、メモリの少ないマシンの場合は128です。
  If server suffers of overload, try to increase this number.
  サーバーが過負荷になっている場合は、この数を増やしてみてください。
  
• /proc/sys/net/core/somaxconn: Limit of socket listen() backlog, known in userspace as SOMAXCONN.
  / proc / sys / net / core / somaxconn：ソケットlisten（）バックログの制限。ユーザースペースではSOMAXCONNとして知られています。
  Defaults to 128.
  デフォルトは128です。
  The value should be raised substantially to support bursts of request.
  リクエストのバーストをサポートするには、値を大幅に上げる必要があります。
  For example, to support a burst of 1024 requests, set somaxconn to 1024.
  たとえば、1024リクエストのバーストをサポートするには、somaxconnを1024に設定します。
  

The transmit queue length (txqueuelen) may also need to be modified using the ifconfig command.
送信キューの長さ（txqueuelen）も、ifconfigコマンドを使用して変更する必要がある場合があります。
A value of 4096 has been found to work well for one site with a very large cluster (e.g. "ifconfig txqueuelen 4096").
4096の値は、クラスターが非常に大きい1つのサイト（「ifconfigtxqueuelen4096」など）で適切に機能することがわかっています。

Thread/Process Limit

There is a newly introduced limit in SLES 12 SP2 (used on Cray systems with CLE 6.0UP04, to be released mid-2017).
SLES 12 SP2には新たに導入された制限があります（CLE 6.0UP04を搭載したCrayシステムで使用され、2017年半ばにリリースされます）。
The version of systemd shipped with SLES 12 SP2 contains support for the PIDs cgroup controller.
SLES 12 SP2に同梱されているsystemdのバージョンには、PIDのcgroupコントローラーのサポートが含まれています。
Under the new systemd version, each init script or systemd service is limited to 512 threads/processes by default.
新しいsystemdバージョンでは、各initスクリプトまたはsystemdサービスはデフォルトで512スレッド/プロセスに制限されています。
This could cause issues for the slurmctld and slurmd daemons on large clusters or systems with a high job throughput rate.
これにより、大規模なクラスターまたはジョブスループット率の高いシステムでslurmctldデーモンとslurmdデーモンに問題が発生する可能性があります。
To increase the limit beyond the default:
デフォルトを超えて制限を増やすには：

• If using a systemd service file: Add TasksMax=N to the [Service] section.
  systemdサービスファイルを使用する場合：[Service]セクションにTasksMax = Nを追加します。
  N can be a specific number, or special value infinity.
  Nは、特定の数値、または特別な値の無限大にすることができます。
  
• If using an init script: Create the file
  /etc/systemd/system/<init script name>.service.d/override.conf
  with these contents:
  initスクリプトを使用する場合：次の内容でファイル/ etc / systemd / system / ＜initスクリプト名＞ .service.d /override.confを作成します。
  

    [Service]
    TasksMax=N
  

Note: Earlier versions of systemd that don't support the PIDs cgroup controller simply ignore the TasksMax setting.
注：PID cgroupコントローラーをサポートしない以前のバージョンのsystemdは、TasksMax設定を単に無視します。

User Limits

The ulimit values in effect for the slurmctld daemon should be set quite high for memory size, open file count and stack size.
slurmctldデーモンに有効なulimit値は、メモリサイズ、オープンファイル数、およびスタックサイズに対して非常に高く設定する必要があります。

Node Selection Plugin (SelectType)

While allocating individual processors within a node is great for smaller clusters, the overhead of keeping track of the individual processors and memory within each node adds significant overhead.
ノード内に個々のプロセッサを割り当てることは小さなクラスターには最適ですが、各ノード内の個々のプロセッサとメモリを追跡するオーバーヘッドはかなりのオーバーヘッドを追加します。
For best scalability, allocate whole nodes using select/linear and avoid select/cons_res.
最高のスケーラビリティを得るには、select / linearを使用してノード全体を割り当て、select / cons_resを回避します。

Job Accounting Gather Plugin (JobAcctGatherType)

Job accounting relies upon the slurmstepd daemon on each compute node periodically sampling data.
ジョブアカウンティングは、各計算ノードのslurmstepdデーモンが定期的にデータをサンプリングすることに依存しています。
This data collection will take compute cycles away from the application inducing what is known as system noise.
このデータ収集により、アプリケーションから計算サイクルが奪われ、システムノイズと呼ばれるものが発生します。
For large parallel applications, this system noise can detract from application scalability.
大規模な並列アプリケーションの場合、このシステムノイズはアプリケーションのスケーラビリティを損なう可能性があります。
For optimal application performance, disabling job accounting is best (jobacct_gather/none).
アプリケーションのパフォーマンスを最適化するには、ジョブアカウンティングを無効にするのが最適です（jobacct_gather / none）。
Consider use of job completion records (JobCompType) for accounting purposes as this entails far less overhead.
オーバーヘッドがはるかに少ないため、アカウンティング目的でジョブ完了レコード（JobCompType）を使用することを検討してください。
If job accounting is required, configure the sampling interval to a relatively large size (e.g. JobAcctGatherFrequency=300).
ジョブアカウンティングが必要な場合は、サンプリング間隔を比較的大きなサイズに構成します（例：JobAcctGatherFrequency = 300）。
Some experimentation may be required to deal with collisions on data transmission.
データ送信時の衝突に対処するには、いくつかの実験が必要になる場合があります。

Node Configuration

While Slurm can track the amount of memory and disk space actually found on each compute node and use it for scheduling purposes, this entails extra overhead.
Slurmは、各計算ノードで実際に検出されたメモリとディスクスペースの量を追跡し、それをスケジューリングの目的で使用できますが、これには余分なオーバーヘッドが伴います。
Optimize performance by specifying the expected configuration using the available parameters (RealMemory, CPUs, and TmpDisk).
使用可能なパラメーター（RealMemory、CPU、およびTmpDisk）を使用して予想される構成を指定することにより、パフォーマンスを最適化します。
If the node is found to contain less resources than configured, it will be marked DOWN and not used.
ノードに含まれるリソースが構成よりも少ないことが判明した場合、ノードはDOWNとマークされ、使用されません。
While Slurm can easily handle a heterogeneous cluster, configuring the nodes using the minimal number of lines in slurm.conf will both make for easier administration and better performance.
Slurmは異種クラスターを簡単に処理できますが、slurm.confの最小行数を使用してノードを構成すると、管理が容易になり、パフォーマンスが向上します。

Timers

The EioTimeout configuration parameter controls how long the srun command will wait for the slurmstepd to close the TCP/IP connection used to relay data between the user application and srun when the user application terminates.
EioTimeout構成パラメーターは、ユーザーアプリケーションの終了時にsrunコマンドがslurmstepdがユーザーアプリケーションとsrunの間でデータを中継するために使用されるTCP / IP接続を閉じるのを待機する時間を制御します。
The default value is 60 seconds.
デフォルト値は60秒です。
Larger systems and/or slower networks may need a higher value.
大規模なシステムや低速のネットワークでは、より高い値が必要になる場合があります。

If a high throughput of jobs is anticipated (i.e. large numbers of jobs with brief execution times) then configure MinJobAge to the smallest interval practical for your environment.
ジョブの高スループットが予想される場合（つまり、実行時間が短い多数のジョブ）、MinJobAgeをご使用の環境で実用的な最小間隔に構成します。
MinJobAge specifies the minimum number of seconds that a terminated job will be retained by Slurm's control daemon before purging.
MinJobAgeは、終了したジョブがパージされる前にSlurmの制御デーモンによって保持される最小秒数を指定します。
After this time, information about terminated jobs will only be available through accounting records.
この時間以降、終了したジョブに関する情報は、アカウンティングレコードを通じてのみ利用可能になります。

The configuration parameter SlurmdTimeout determines the interval at which slurmctld routinely communicates with slurmd.
構成パラメーターSlurmdTimeoutは、slurmctldがslurmdと定期的に通信する間隔を決定します。
Communications occur at half the SlurmdTimeout value.
通信はSlurmdTimeout値の半分で発生します。
The purpose of this is to determine when a compute node fails and thus should not be allocated work.
これの目的は、計算ノードに障害が発生したため、作業を割り当てるべきではない時期を判断することです。
Longer intervals decrease system noise on compute nodes (we do synchronize these requests across the cluster, but there will be some impact upon applications).
間隔を長くすると、計算ノードのシステムノイズが減少します（これらの要求はクラスター全体で同期されますが、アプリケーションにいくらかの影響があります）。
For really large clusters, SlurmdTimeout values of 120 seconds or more are reasonable.
非常に大きなクラスターの場合、120秒以上のSlurmdTimeout値が妥当です。

If MPICH-2 is used, the srun command will manage the key-pairs used to bootstrap the application.
MPICH-2が使用されている場合、srunコマンドは、アプリケーションのブートストラップに使用されるキーペアを管理します。
Depending upon the processor speed and architecture, the communication of key-pair information may require extra time.
プロセッサの速度とアーキテクチャによっては、キーペア情報の通信に余分な時間がかかる場合があります。
This can be done by setting an environment variable PMI_TIME before executing srun to launch the tasks.
これは、タスクを起動するためにsrunを実行する前に環境変数PMI_TIMEを設定することで実行できます。
The default value of PMI_TIME is 500 and this is the number of microseconds alloted to transmit each key-pair.
PMI_TIMEのデフォルト値は500で、これは各キーペアを送信するために割り当てられたマイクロ秒数です。
We have executed up to 16,000 tasks with a value of PMI_TIME=4000.
PMI_TIME = 4000の値で最大16,000のタスクを実行しました。

The individual slurmd daemons on compute nodes will initiate messages to the slurmctld daemon only when they start up or when the epilog completes for a job.
計算ノード上の個々のslurmdデーモンは、起動時またはジョブのエピローグが完了したときにのみ、slurmctldデーモンへのメッセージを開始します。
When a job allocated a large number of nodes completes, it can cause a very large number of messages to be sent by the slurmd daemons on these nodes to the slurmctld daemon all at the same time.
多数のノードが割り当てられたジョブが完了すると、これらのノードのslurmdデーモンからslurmctldデーモンに同時に非常に多くのメッセージが送信される可能性があります。
In order to spread this message traffic out over time and avoid message loss, The EpilogMsgTime parameter may be used.
このメッセージトラフィックを時間の経過とともに分散させ、メッセージの損失を回避するために、EpilogMsgTimeパラメータを使用できます。
Note that even if messages are lost, they will be retransmitted, but this will result in a delay for reallocating resources to new jobs.
メッセージが失われた場合でも、メッセージは再送信されますが、これにより、リソースを新しいジョブに再割り当てするための遅延が発生することに注意してください。

Other

Slurm uses hierarchical communications between the slurmd daemons in order to increase parallelism and improve performance.
Slurmは、並列処理を増やしてパフォーマンスを向上させるために、slurmdデーモン間の階層通信を使用します。
The TreeWidth configuration parameter controls the fanout of messages.
TreeWidth構成パラメーターは、メッセージのファンアウトを制御します。
The default value is 50, meaning each slurmd daemon can communicate with up to 50 other slurmd daemons and over 2500 nodes can be contacted with two message hops.
デフォルト値は50です。これは、各slurmdデーモンが最大50の他のslurmdデーモンと通信でき、2500を超えるノードが2つのメッセージホップで接続できることを意味します。
The default value will work well for most clusters.
デフォルト値は、ほとんどのクラスターで適切に機能します。
Optimal system performance can typically be achieved if TreeWidth is set to the square root of the number of nodes in the cluster for systems having no more than 2500 nodes or the cube root for larger systems.
最適なシステムパフォーマンスは、通常、TreeWidthが2500ノード以下のシステムの場合はクラスター内のノード数の平方根に設定されているか、大規模なシステムの場合は立方根に設定されている場合に達成できます。

The srun command automatically increases its open file limit to the hard limit in order to process all of the standard input and output connections to the launched tasks.
srunコマンドは、起動されたタスクへのすべての標準入力および出力接続を処理するために、開いているファイルの制限をハード制限まで自動的に増やします。
It is recommended that you set the open file hard limit to 8192 across the cluster.
クラスタ全体でオープンファイルのハード制限を8192に設定することをお勧めします。

Last modified 9 October 2019