Quick Start Administrator Guide

Overview

Please see the Quick Start User Guide for a general overview.
一般的な概要については、クイックスタートユーザーガイドを参照してください。

Also see Platforms for a list of supported computer platforms.
サポートされているコンピュータープラットフォームのリストについては、プラットフォームも参照してください。

This document also includes a section specifically describing how to perform upgrades.
このドキュメントには、アップグレードの実行方法を具体的に説明するセクションも含まれています。

Super Quick Start

Make sure the clocks, users and groups (UIDs and GIDs) are synchronized across the cluster.
クロック、ユーザー、およびグループ（UIDとGID）がクラスター全体で同期されていることを確認してください。
Install MUNGE for authentication.
認証用にMUNGEをインストールします。
Make sure that all nodes in your cluster have the same munge.key.
クラスタ内のすべてのノードが同じmunge.keyを持っていることを確認してください。
Make sure the MUNGE daemon, munged is started before you start the Slurm daemons.
Slurmデーモンを開始する前に、MUNGEデーモン（munged）が開始されていることを確認してください。
bunzip2 the distributed tar-ball and untar the files:
tar --bzip -x -f slurm*tar.bz2
bunzip2分散されたtar-ballとファイルのuntar：tar --bzip -x -f slurm * tar.bz2
cd to the directory containing the Slurm source and type ./configure with appropriate options, typically --prefix= and --sysconfdir=
Slurmソースを含むディレクトリにcdし、適切なオプション（通常は--prefix =および--sysconfdir =）を指定して./configureと入力します。
Type make to compile Slurm.
makeと入力して、Slurmをコンパイルします。
Type make install to install the programs, documentation, libraries, header files, etc.
make installと入力して、プログラム、ドキュメント、ライブラリ、ヘッダーファイルなどをインストールします。
Build a configuration file using your favorite web browser and doc/html/configurator.html.
お気に入りのWebブラウザーとdoc / html /configurator.htmlを使用して構成ファイルを作成します。

NOTE: The SlurmUser must exist prior to starting Slurm and must exist on all nodes of the cluster.
注：SlurmUserは、Slurmを開始する前に存在している必要があり、クラスターのすべてのノードに存在している必要があります。

NOTE: The parent directories for Slurm's log files, process ID files, state save directories, etc. are not created by Slurm.
注：Slurmのログファイル、プロセスIDファイル、状態保存ディレクトリなどの親ディレクトリは、Slurmによって作成されません。
They must be created and made writable by SlurmUser as needed prior to starting Slurm daemons.
これらは、Slurmデーモンを開始する前に、必要に応じてSlurmUserが作成し、書き込み可能にする必要があります。

NOTE: If any parent directories are created during the installation process (for the executable files, libraries, etc.), those directories will have access rights equal to read/write/execute for everyone minus the umask value (e.g. umask=0022 generates directories with permissions of "drwxr-r-x" and mask=0000 generates directories with permissions of "drwxrwrwx" which is a security problem).
注：インストールプロセス中に（実行可能ファイル、ライブラリなどの）親ディレクトリが作成された場合、それらのディレクトリには、すべてのユーザーの読み取り/書き込み/実行からumask値を引いた値に等しいアクセス権があります（たとえば、umask = 0022はディレクトリを生成します）。「drwxr-rx」のアクセス許可とmask = 0000を使用すると、セキュリティの問題である「drwxrwrwx」のアクセス許可を持つディレクトリが生成されます。
Type ldconfig -n <library_location> so that the Slurm libraries can be found by applications that intend to use Slurm APIs directly.
ldconfig -n ＜library_location＞と入力して、SlurmAPIを直接使用する予定のアプリケーションがSlurmライブラリーを見つけられるようにします。
Install the configuration file in <sysconfdir>/slurm.conf.
＜sysconfdir＞ /slurm.confに構成ファイルをインストールします。

NOTE: You will need to install this configuration file on all nodes of the cluster.
注：この構成ファイルは、クラスターのすべてのノードにインストールする必要があります。
systemd (optional): enable the appropriate services on each system:
systemd（オプション）：各システムで適切なサービスを有効にします。
- Controller: systemctl enable slurmctld
- Database: systemctl enable slurmdbd
- Compute Nodes: systemctl enable slurmd
Start the slurmctld and slurmd daemons.
slurmctldデーモンとslurmdデーモンを起動します。

NOTE: Items 3 through 8 can be replaced with
注：アイテム3から8は、次のように置き換えることができます。

rpmbuild -ta slurm*.tar.bz2
rpm --install <the rpm files>

FreeBSD administrators should see the FreeBSD section below.
FreeBSD管理者は、以下のFreeBSDセクションを参照してください。

Building and Installing Slurm

Instructions to build and install Slurm manually are shown below.
Slurmを手動でビルドおよびインストールする手順を以下に示します。
See the README and INSTALL files in the source distribution for more details.
詳細については、ソースディストリビューションのREADMEファイルとINSTALLファイルを参照してください。

Unpack the distributed tarball:
tar -xaf slurm*tar.bz2
配布されたtarballを解凍します：tar -xaf slurm * tar.bz2
cd to the directory containing the Slurm source and type ./configure with appropriate options (see below).
Slurmソースを含むディレクトリにcdし、適切なオプションを指定して./configureと入力します（以下を参照）。
Type make install to compile and install the programs, documentation, libraries, header files, etc.
make installと入力して、プログラム、ドキュメント、ライブラリ、ヘッダーファイルなどをコンパイルしてインストールします。
Type ldconfig -n <library_location> so that the Slurm libraries can be found by applications that intend to use Slurm APIs directly.
ldconfig -n ＜library_location＞と入力して、SlurmAPIを直接使用する予定のアプリケーションがSlurmライブラリーを見つけられるようにします。
The library location will be a subdirectory of PREFIX (described below) and depend upon the system type and configuration, typically lib or lib64.
ライブラリの場所はPREFIXのサブディレクトリ（以下で説明）であり、システムのタイプと構成（通常はlibまたはlib64）によって異なります。
For example, if PREFIX is "/usr" and the subdirectory is "lib64" then you would find that a file named "/usr/lib64/libslurm.so" was installed and the command ldconfig -n /usr/lib64 should be executed.
たとえば、PREFIXが「/ usr」でサブディレクトリが「lib64」の場合、「/ usr / lib64 / libslurm.so」という名前のファイルがインストールされており、コマンドldconfig -n / usr / lib64を実行する必要があります。。

A full list of configure options will be returned by the command configure --help.
configureオプションの完全なリストは、コマンドconfigure--helpによって返されます。
The most commonly used arguments to the configure command include:
configureコマンドで最も一般的に使用される引数は次のとおりです。

--enable-debug
Enable additional debugging logic within Slurm.
Slurm内で追加のデバッグロジックを有効にします。

--prefix=PREFIX
Install architecture-independent files in PREFIX; default value is /usr/local.
PREFIXにアーキテクチャに依存しないファイルをインストールします。デフォルト値は/ usr / localです。

--sysconfdir=DIR
Specify location of Slurm configuration file.
Slurm構成ファイルの場所を指定します。
The default value is PREFIX/etc
デフォルト値はPREFIX / etcです

If required libraries or header files are in non-standard locations, set CFLAGS and LDFLAGS environment variables accordingly.
必要なライブラリまたはヘッダーファイルが非標準の場所にある場合は、それに応じてCFLAGSおよびLDFLAGS環境変数を設定します。
Optional Slurm plugins will be built automatically when the configure script detects that the required build requirements are present.
オプションのSlurmプラグインは、configureスクリプトが必要なビルド要件が存在することを検出すると、自動的にビルドされます。
Build dependencies for various plugins and commands are denoted below:
さまざまなプラグインとコマンドのビルド依存関係を以下に示します。

cgroup Task Affinity The task/cgroup plugin will be built with task affinity support if the hwloc development library is present.
hwloc開発ライブラリが存在する場合、task / cgroupプラグインはタスクアフィニティサポートを使用して構築されます。
HDF5 Job Profiling The acct_gather_profile/hdf5 job profiling plugin will be built if the hdf5 development library is present.
acct_gather_profile / hdf5ジョブプロファイリングプラグインは、hdf5開発ライブラリが存在する場合にビルドされます。
HTML Man Pages HTML versions of the man pages will be generated if the man2html command is present.
man2htmlコマンドが存在する場合、マニュアルページのHTMLバージョンが生成されます。
IPMI Engergy Consumption The acct_gather_energy/ipmi accouting plugin will be built if the freeimpi development library is present.
freeimpi開発ライブラリが存在する場合、acct_gather_energy / ipmiアカウンティングプラグインがビルドされます。
InfiniBand Accounting The acct_gather_interconnect/ofed InfiniBand accounting plugin will be built if the libibmad and libibumad development libraries are present.
libibmadおよびlibibumad開発ライブラリが存在する場合、acct_gather_interconnect / ofedInfiniBandアカウンティングプラグインがビルドされます。
Lua Support The lua API will be available in various plugins if the lua development library is present.
lua開発ライブラリが存在する場合、luaAPIはさまざまなプラグインで使用できます。
MUNGE The auth/munge plugin will be built if the MUNGE authentication development library is installed.
MUNGE認証開発ライブラリがインストールされている場合、auth / mungeプラグインがビルドされます。
MUNGE is used as the default authentication mechanism.
MUNGEは、デフォルトの認証メカニズムとして使用されます。
MySQL MySQL support for accounting will be built if the mysql development library is present.
mysql開発ライブラリが存在する場合、アカウンティングのMySQLサポートが構築されます。
PAM Support PAM support will be added if the PAM development library is installed.
PAM開発ライブラリがインストールされている場合、PAMサポートが追加されます。
NUMA Affinity NUMA support in the task/affinity plugin will be available if the numa development library is installed.
タスク/アフィニティプラグインでのNUMAサポートは、numa開発ライブラリがインストールされている場合に利用できます。
Readline Support Readline support in scontrol and sacctmgr's interactive modes will be available if the readline development library is present.
readline開発ライブラリが存在する場合、scontrolおよびsacctmgrの対話モードでのReadlineサポートが利用可能になります。
RRD External Sensor Data Collection The ext_sensors/rrd plugin will be built if the rrdtool development library is present.
rrdtool開発ライブラリが存在する場合、ext_sensors / rrdプラグインがビルドされます。
sview The sview command will be built only if gtk+-2.0 is installed.
sviewコマンドは、gtk + -2.0がインストールされている場合にのみビルドされます。

Please see the Download page for references to required software to build these plugins.
これらのプラグインをビルドするために必要なソフトウェアへの参照については、ダウンロードページを参照してください。

To build RPMs directly, copy the distributed tarball into a directory and execute (substituting the appropriate Slurm version number):
rpmbuild -ta slurm-20.02.1.tar.bz2
RPMを直接ビルドするには、配布されたtarballをディレクトリにコピーし、実行します（適切なSlurmバージョン番号に置き換えます）：rpmbuild -ta slurm-20.02.1.tar.bz2

The rpm files will be installed under the $(HOME)/rpmbuild directory of the user building them.
rpmファイルは、それらをビルドするユーザーの＄（HOME）/ rpmbuildディレクトリにインストールされます。

You can control some aspects of the RPM built with a .rpmmacros file in your home directory.
ホームディレクトリの.rpmmacrosファイルで構築されたRPMのいくつかの側面を制御できます。
Special macro definitions will likely only be required if files are installed in unconventional locations.
特別なマクロ定義は、ファイルが型にはまらない場所にインストールされている場合にのみ必要になる可能性があります。
Some macro definitions that may be used in building Slurm include:
Slurmの構築に使用できるマクロ定義には次のものがあります。

_enable_debug: Specify if debugging logic within Slurm is to be enabled
Slurm内のデバッグロジックを有効にするかどうかを指定します
_prefix: Pathname of directory to contain the Slurm files
Slurmファイルを含むディレクトリのパス名
_sysconfdir (or _slurm_sysconfdir): Pathname of directory containing the slurm.conf configuration file
slurm.conf構成ファイルを含むディレクトリーのパス名
with_munge: Specifies the MUNGE (authentication library) installation location
MUNGE（認証ライブラリ）のインストール場所を指定します
with_ssl: Specifies SSL library installation location
SSLライブラリのインストール場所を指定します

An example .rpmmacros file:
.rpmmacrosファイルの例：

# .rpmmacros
# Override some RPM macros from /usr/lib/rpm/macros
# Set Slurm-specific macros for unconventional file locations
#
%_enable_debug     "--with-debug"
%_prefix           /opt/slurm
%_sysconfdir       %{_prefix}/etc/slurm
%_defaultdocdir    %{_prefix}/doc
%with_munge        "--with-munge=/opt/munge"

RPMs Installed

The RPMs needed on the head node, compute nodes, and slurmdbd node can vary by configuration, but here is a suggested starting point:
ヘッドノード、計算ノード、およびslurmdbdノードで必要なRPMは構成によって異なる場合がありますが、推奨される開始点は次のとおりです。

Head Node (where the slurmctld daemon runs),
Compute and Login Nodes
ヘッドノード（slurmctldデーモンが実行される場所）、コンピューティングノードおよびログインノード

slurm
slurm-perlapi
slurm-slurmctld (only on the head node)
slurm-slurmd (only on the compute nodes)

SlurmDBD Node

slurm
slurm-slurmdbd

Daemons

slurmctld is sometimes called the "controller".
slurmctldは「コントローラー」と呼ばれることもあります。
It orchestrates Slurm activities, including queuing of jobs, monitoring node states, and allocating resources to jobs.
ジョブのキューイング、ノード状態の監視、ジョブへのリソースの割り当てなど、Slurmアクティビティを調整します。
There is an optional backup controller that automatically assumes control in the event the primary controller fails (see the High Availability section below).
プライマリコントローラーに障害が発生した場合に自動的に制御を引き継ぐオプションのバックアップコントローラーがあります（以下の「高可用性」セクションを参照）。
The primary controller resumes control whenever it is restored to service.
プライマリコントローラは、サービスに復元されるたびに制御を再開します。
The controller saves its state to disk whenever there is a change in state (see "StateSaveLocation" in Configuration section below).
コントローラは、状態が変化するたびにその状態をディスクに保存します（以下の「構成」セクションの「StateSaveLocation」を参照）。
This state can be recovered by the controller at startup time.
この状態は、起動時にコントローラーによって回復できます。
State changes are saved so that jobs and other state information can be preserved when the controller moves (to or from a backup controller) or is restarted.
状態の変更は保存されるため、コントローラーが（バックアップコントローラーとの間で）移動したり、再起動したりしたときに、ジョブやその他の状態情報を保持できます。

We recommend that you create a Unix user slurm for use by slurmctld.
slurmctldで使用するUnixユーザーslurmを作成することをお勧めします。
This user name will also be specified using the SlurmUser in the slurm.conf configuration file.
このユーザー名は、slurm.conf構成ファイルのSlurmUserを使用して指定することもできます。
This user must exist on all nodes of the cluster.
このユーザーは、クラスターのすべてのノードに存在する必要があります。
Note that files and directories used by slurmctld will need to be readable or writable by the user SlurmUser (the Slurm configuration files must be readable; the log file directory and state save directory must be writable).
slurmctldが使用するファイルとディレクトリは、ユーザーSlurmUserが読み取りまたは書き込み可能である必要があることに注意してください（Slurm構成ファイルは読み取り可能である必要があり、ログファイルディレクトリと状態保存ディレクトリは書き込み可能である必要があります）。

The slurmd daemon executes on every compute node.
slurmdデーモンはすべての計算ノードで実行されます。
It resembles a remote shell daemon to export control to Slurm.
これは、制御をSlurmにエクスポートするためのリモートシェルデーモンに似ています。
Because slurmd initiates and manages user jobs, it must execute as the user root.
slurmdはユーザージョブを開始および管理するため、ユーザーrootとして実行する必要があります。

If you want to archive job accounting records to a database, the slurmdbd (Slurm DataBase Daemon) should be used.
ジョブアカウンティングレコードをデータベースにアーカイブする場合は、slurmdbd（Slurm DataBase Daemon）を使用する必要があります。
We recommend that you defer adding accounting support until after basic Slurm functionality is established on your system.
システムで基本的なSlurm機能が確立されるまで、アカウンティングサポートの追加を延期することをお勧めします。
An Accounting web page contains more information.
会計Webページには、より多くの情報が含まれています。

slurmctld and/or slurmd should be initiated at node startup time per the Slurm configuration.
slurmctldおよび/またはslurmdは、Slurm構成に従ってノードの起動時に開始する必要があります。

High Availability

Multiple SlurmctldHost entries can be configured, with any entry beyond the first being treated as a backup host.
複数のSlurmctldHostエントリを構成でき、最初のエントリ以外のエントリはバックアップホストとして扱われます。
Any backup hosts configured should be on a different node than the node hosting the primary slurmctld.
構成されたバックアップホストは、プライマリslurmctldをホストしているノードとは異なるノード上にある必要があります。
However, all hosts should mount a common file system containing the state information (see "StateSaveLocation" in the Configuration section below).
ただし、すべてのホストは、状態情報を含む共通のファイルシステムをマウントする必要があります（以下の「構成」セクションの「StateSaveLocation」を参照）。

If more than one host is specified, when the primary fails the second listed SlurmctldHost will take over for it.
複数のホストが指定されている場合、プライマリに障害が発生すると、2番目にリストされているSlurmctldHostがそれを引き継ぎます。
When the primary returns to service, it notifies the backup.
プライマリがサービスに戻ると、バックアップに通知します。
The backup then saves the state and returns to backup mode.
その後、バックアップは状態を保存し、バックアップモードに戻ります。
The primary reads the saved state and resumes normal operation.
プライマリは保存された状態を読み取り、通常の操作を再開します。
Likewise, if both of the first two listed hosts fail the third SlurmctldHost will take over until the primary returns to service.
同様に、リストされている最初の2つのホストの両方に障害が発生した場合、プライマリがサービスに戻るまで3番目のSlurmctldHostが引き継ぎます。
Other than a brief period of non-responsiveness, the transition back and forth should go undetected.
短時間の無応答を除いて、前後の遷移は検出されないはずです。

Prior to 18.08, Slurm used the "BackupAddr" and "BackupController" parameters for High Availability.
18.08より前は、Slurmは高可用性のために「BackupAddr」および「BackupController」パラメーターを使用していました。
These parameters have been deprecated and are replaced by "SlurmctldHost".
これらのパラメーターは非推奨になり、「SlurmctldHost」に置き換えられました。
Also see " SlurmctldPrimaryOnProg" and " SlurmctldPrimaryOffProg" to adjust the actions taken when machines transition between being the primary controller.
また、「SlurmctldPrimaryOnProg」および「SlurmctldPrimaryOffProg」を参照して、マシンがプライマリコントローラーから移行するときに実行されるアクションを調整します。

Any time the slurmctld daemon or hardware fails before state information reaches disk can result in lost state.
状態情報がディスクに到達する前にslurmctldデーモンまたはハードウェアに障害が発生すると、状態が失われる可能性があります。
Slurmctld writes state frequently (every five seconds by default), but with large numbers of jobs, the formatting and writing of records can take seconds and recent changes might not be written to disk.
Slurmctldは状態を頻繁に書き込みます（デフォルトでは5秒ごと）が、ジョブの数が多いと、レコードのフォーマットと書き込みに数秒かかる場合があり、最近の変更がディスクに書き込まれない場合があります。
Another example is if the state information is written to file, but that information is cached in memory rather than written to disk when the node fails.
もう1つの例は、状態情報がファイルに書き込まれているが、ノードに障害が発生したときにその情報がディスクに書き込まれるのではなく、メモリにキャッシュされる場合です。
The interval between state saves being written to disk can be configured at build time by defining SAVE_MAX_WAIT to a different value than five.
ディスクに書き込まれる状態保存の間隔は、SAVE_MAX_WAITを5とは異なる値に定義することにより、ビルド時に構成できます。

Infrastructure

User and Group Identification

There must be a uniform user and group name space (including UIDs and GIDs) across the cluster.
クラスター全体で、統一されたユーザー名空間とグループ名前空間（UIDとGIDを含む）が必要です。
It is not necessary to permit user logins to the control hosts (SlurmctldHost), but the users and groups must be resolvable on those hosts.
制御ホスト（SlurmctldHost）へのユーザーログインを許可する必要はありませんが、ユーザーとグループはそれらのホストで解決可能である必要があります。

Authentication of Slurm communications

All communications between Slurm components are authenticated.
Slurmコンポーネント間のすべての通信が認証されます。
The authentication infrastructure is provided by a dynamically loaded plugin chosen at runtime via the AuthType keyword in the Slurm configuration file.
認証インフラストラクチャは、Slurm構成ファイルのAuthTypeキーワードを介して実行時に選択された動的にロードされたプラグインによって提供されます。
The only currently supported authentication types is munge, which requires the installation of the MUNGE package.
現在サポートされている認証タイプはmungeのみであり、MUNGEパッケージのインストールが必要です。
When using MUNGE, all nodes in the cluster must be configured with the same munge.key file.
MUNGEを使用する場合、クラスター内のすべてのノードを同じmunge.keyファイルで構成する必要があります。
The MUNGE daemon, munged, must also be started before Slurm daemons.
MungedされたMUNGEデーモンも、Slurmデーモンの前に開始する必要があります。
Note that MUNGE does require clocks to be synchronized throughout the cluster, usually done by NTP.
MUNGEでは、通常はNTPによって行われる、クラスター全体でクロックを同期する必要があることに注意してください。

MPI support

Slurm supports many different MPI implementations.
Slurmは、さまざまなMPI実装をサポートしています。
For more information, see MPI.
詳細については、MPIを参照してください。

Scheduler support

Slurm can be configured with rather simple or quite sophisticated scheduling algorithms depending upon your needs and willingness to manage the configuration (much of which requires a database).
Slurmは、ニーズと構成を管理する意欲に応じて、かなり単純または非常に高度なスケジューリングアルゴリズムで構成できます（その多くはデータベースを必要とします）。
The first configuration parameter of interest is PriorityType with two options available: basic (first-in-first-out) and multifactor.
対象となる最初の構成パラメーターはPriorityTypeであり、基本（先入れ先出し）と多因子の2つのオプションを使用できます。
The multifactor plugin will assign a priority to jobs based upon a multitude of configuration parameters (age, size, fair-share allocation, etc.) and its details are beyond the scope of this document.
多要素プラグインは、多数の構成パラメーター（年齢、サイズ、フェアシェアの割り当てなど）に基づいてジョブに優先順位を割り当てます。その詳細は、このドキュメントの範囲を超えています。
See the Multifactor Job Priority Plugin document for details.
詳細については、Multifactor Job PriorityPluginのドキュメントを参照してください。

The SchedType configuration parameter controls how queued jobs are scheduled and several options are available.
SchedType構成パラメーターは、キューに入れられたジョブのスケジュール方法を制御し、いくつかのオプションを使用できます。

builtin will initiate jobs strictly in their priority order, typically (first-in-first-out)
ビルトインは、厳密に優先順位に従ってジョブを開始します。通常は（先入れ先出し）
backfill will initiate a lower-priority job if doing so does not delay the expected initiation time of higher priority jobs; essentially using smaller jobs to fill holes in the resource allocation plan.
バックフィルは、優先度の高いジョブの予想開始時間を遅らせない場合、優先度の低いジョブを開始します。基本的に、リソース割り当て計画の穴を埋めるために小さなジョブを使用します。
Effective backfill scheduling does require users to specify job time limits.
効果的な埋め戻しスケジューリングでは、ユーザーがジョブの時間制限を指定する必要があります。
gang time-slices jobs in the same partition/queue and can be used to preempt jobs from lower-priority queues in order to execute jobs in higher priority queues.
同じパーティション/キュー内のジョブをギャングタイムスライスし、優先度の高いキューでジョブを実行するために、優先度の低いキューからジョブをプリエンプトするために使用できます。

For more information about scheduling options see Gang Scheduling, Preemption, Resource Reservation Guide, Resource Limits and Sharing Consumable Resources.
スケジューリングオプションの詳細については、ギャングスケジューリング、プリエンプション、リソース予約ガイド、リソース制限、および消耗品リソースの共有を参照してください。

Resource selection

The resource selection mechanism used by Slurm is controlled by the SelectType configuration parameter.
Slurmが使用するリソース選択メカニズムは、SelectType構成パラメーターによって制御されます。
If you want to execute multiple jobs per node, but track and manage allocation of the processors, memory and other resources, the cons_res (consumable resources) plugin is recommended.
ノードごとに複数のジョブを実行したいが、プロセッサ、メモリ、その他のリソースの割り当てを追跡および管理する場合は、cons_res（消耗品リソース）プラグインをお勧めします。
For more information, please see Consumable Resources in Slurm.
詳細については、Slurmの消耗品リソースを参照してください。

Logging

Slurm uses syslog to record events if the SlurmctldLogFile and SlurmdLogFile locations are not set.
SlurmctldLogFileとSlurmdLogFileの場所が設定されていない場合、Slurmはsyslogを使用してイベントを記録します。

Accounting

Slurm supports accounting records being written to a simple text file, directly to a database (MySQL or MariaDB), or to a daemon securely managing accounting data for multiple clusters.
Slurmは、単純なテキストファイル、データベース（MySQLまたはMariaDB）、または複数のクラスターのアカウンティングデータを安全に管理するデーモンに書き込まれるアカウンティングレコードをサポートします。
For more information see Accounting.
詳細については、アカウンティングを参照してください。

Compute node access

Slurm does not by itself limit access to allocated compute nodes, but it does provide mechanisms to accomplish this.
Slurm自体は、割り当てられた計算ノードへのアクセスを制限しませんが、これを実現するメカニズムを提供します。
There is a Pluggable Authentication Module (PAM) for restricting access to compute nodes available for download.
ダウンロード可能な計算ノードへのアクセスを制限するためのPluggableAuthentication Module（PAM）があります。
When installed, the Slurm PAM module will prevent users from logging into any node that has not be assigned to that user.
Slurm PAMモジュールをインストールすると、ユーザーはそのユーザーに割り当てられていないノードにログインできなくなります。
On job termination, any processes initiated by the user outside of Slurm's control may be killed using an Epilog script configured in slurm.conf.
ジョブの終了時に、Slurmの制御外でユーザーによって開始されたプロセスは、slurm.confで構成されたEpilogスクリプトを使用して強制終了される場合があります。

Configuration

The Slurm configuration file includes a wide variety of parameters.
Slurm構成ファイルには、さまざまなパラメーターが含まれています。
This configuration file must be available on each node of the cluster and must have consistent contents.
この構成ファイルは、クラスターの各ノードで使用可能であり、内容が一貫している必要があります。
A full description of the parameters is included in the slurm.conf man page.
パラメータの完全な説明は、slurm.confのマニュアルページに含まれています。
Rather than duplicate that information, a minimal sample configuration file is shown below.
その情報を複製するのではなく、最小限のサンプル構成ファイルを以下に示します。
Your slurm.conf file should define at least the configuration parameters defined in this sample and likely additional ones.
slurm.confファイルは、少なくともこのサンプルで定義されている構成パラメーターと、場合によっては追加のパラメーターを定義する必要があります。
Any text following a "#" is considered a comment.
「＃」に続くテキストはコメントと見なされます。
The keywords in the file are not case sensitive, although the argument typically is (e.g., "SlurmUser=slurm" might be specified as "slurmuser=slurm").
ファイル内のキーワードでは大文字と小文字は区別されませんが、引数は通常は大文字と小文字が区別されます（たとえば、「SlurmUser = slurm」は「slurmuser = slurm」として指定される場合があります）。
The control machine, like all other machine specifications, can include both the host name and the name used for communications.
制御マシンは、他のすべてのマシン仕様と同様に、ホスト名と通信に使用される名前の両方を含めることができます。
In this case, the host's name is "mcri" and the name "emcri" is used for communications.
この場合、ホストの名前は「mcri」であり、名前「emcri」は通信に使用されます。
In this case "emcri" is the private management network interface for the host "mcri".
この場合、「emcri」はホスト「mcri」のプライベート管理ネットワークインターフェイスです。
Port numbers to be used for communications are specified as well as various timer values.
通信に使用するポート番号と各種タイマー値を指定します。

The SlurmUser must be created as needed prior to starting Slurm and must exist on all nodes in your cluster.
SlurmUserは、Slurmを開始する前に必要に応じて作成する必要があり、クラスター内のすべてのノードに存在する必要があります。
The parent directories for Slurm's log files, process ID files, state save directories, etc. are not created by Slurm.
Slurmのログファイル、プロセスIDファイル、状態保存ディレクトリなどの親ディレクトリは、Slurmによって作成されません。
They must be created and made writable by SlurmUser as needed prior to starting Slurm daemons.
これらは、Slurmデーモンを開始する前に、必要に応じてSlurmUserが作成し、書き込み可能にする必要があります。

A description of the nodes and their grouping into partitions is required.
ノードとそれらのパーティションへのグループ化の説明が必要です。
A simple node range expression may optionally be used to specify ranges of nodes to avoid building a configuration file with large numbers of entries.
オプションで、単純なノード範囲式を使用してノードの範囲を指定し、多数のエントリを含む構成ファイルを作成しないようにすることができます。
The node range expression can contain one pair of square brackets with a sequence of comma separated numbers and/or ranges of numbers separated by a "-" (e.g. "linux[0-64,128]", or "lx[15,18,32-33]").
ノード範囲式には、コンマで区切られた数値のシーケンスおよび/または「-」で区切られた数値の範囲を含む1組の角括弧を含めることができます（例：「linux [0-64,128]」または「lx [15,18,32」）。 -33] "）。
Up to two numeric ranges can be included in the expression (e.g. "rack[0-63]_blade[0-41]").
式には最大2つの数値範囲を含めることができます（例：「rack [0-63] _blade [0-41]」）。
If one or more numeric expressions are included, one of them must be at the end of the name (e.g. "unit[0-31]rack" is invalid), but arbitrary names can always be used in a comma separated list.
1つ以上の数式が含まれている場合、それらの1つは名前の末尾にある必要があります（たとえば、「unit [0-31] Rack」は無効です）が、コンマ区切りのリストでは常に任意の名前を使用できます。

Node names can have up to three name specifications: NodeName is the name used by all Slurm tools when referring to the node, NodeAddr is the name or IP address Slurm uses to communicate with the node, and NodeHostname is the name returned by the command /bin/hostname -s.
ノード名には最大3つの名前指定を指定できます。NodeNameはノードを参照するときにすべてのSlurmツールで使用される名前、NodeAddrはSlurmがノードと通信するために使用する名前またはIPアドレス、NodeHostnameはコマンド/によって返される名前です。 bin / hostname-s。
Only NodeName is required (the others default to the same name), although supporting all three parameters provides complete control over naming and addressing the nodes.
NodeNameのみが必要です（他はデフォルトで同じ名前になります）が、3つのパラメーターすべてをサポートすることで、ノードの命名とアドレス指定を完全に制御できます。
See the slurm.conf man page for details on all configuration parameters.
すべての構成パラメーターの詳細については、slurm.confのマニュアルページを参照してください。

Nodes can be in more than one partition and each partition can have different constraints (permitted users, time limits, job size limits, etc.).
ノードは複数のパーティションに配置でき、各パーティションには異なる制約（許可されたユーザー、時間制限、ジョブサイズ制限など）を設定できます。
Each partition can thus be considered a separate queue.
したがって、各パーティションは個別のキューと見なすことができます。
Partition and node specifications use node range expressions to identify nodes in a concise fashion.
パーティションとノードの仕様では、ノード範囲式を使用してノードを簡潔に識別します。
This configuration file defines a 1154-node cluster for Slurm, but it might be used for a much larger cluster by just changing a few node range expressions.
この構成ファイルは、Slurmの1154ノードクラスターを定義しますが、いくつかのノード範囲式を変更するだけで、はるかに大きなクラスターに使用できる場合があります。
Specify the minimum processor count (CPUs), real memory space (RealMemory, megabytes), and temporary disk space (TmpDisk, megabytes) that a node should have to be considered available for use.
ノードが使用可能であると見なす必要がある最小プロセッサー数（CPU）、実メモリー・スペース（RealMemory、メガバイト）、および一時ディスク・スペース（TmpDisk、メガバイト）を指定します。
Any node lacking these minimum configuration values will be considered DOWN and not scheduled.
これらの最小構成値がないノードは、DOWNと見なされ、スケジュールされません。
Note that a more extensive sample configuration file is provided in etc/slurm.conf.example.
より広範なサンプル構成ファイルがetc / slurm.conf.exampleに提供されていることに注意してください。
We also have a web-based configuration tool which can be used to build a simple configuration file, which can then be manually edited for more complex configurations.
また、単純な構成ファイルを作成するために使用できるWebベースの構成ツールもあります。このファイルは、手動で編集して、より複雑な構成にすることができます。

#
# Sample /etc/slurm.conf for mcr.llnl.gov
#
SlurmctldHost=mcri(12.34.56.78)
SlurmctldHost=mcrj(12.34.56.79)
#
AuthType=auth/munge
Epilog=/usr/local/slurm/etc/epilog
JobCompLoc=/var/tmp/jette/slurm.job.log
JobCompType=jobcomp/filetxt
JobCredentialPrivateKey=/usr/local/etc/slurm.key
JobCredentialPublicCertificate=/usr/local/etc/slurm.cert
PluginDir=/usr/local/slurm/lib/slurm
Prolog=/usr/local/slurm/etc/prolog
SchedulerType=sched/backfill
SelectType=select/linear
SlurmUser=slurm
SlurmctldPort=7002
SlurmctldTimeout=300
SlurmdPort=7003
SlurmdSpoolDir=/var/spool/slurmd.spool
SlurmdTimeout=300
StateSaveLocation=/var/spool/slurm.state
SwitchType=switch/none
TreeWidth=50
#
# Node Configurations
#
NodeName=DEFAULT CPUs=2 RealMemory=2000 TmpDisk=64000 State=UNKNOWN
NodeName=mcr[0-1151] NodeAddr=emcr[0-1151]
#
# Partition Configurations
#
PartitionName=DEFAULT State=UP
PartitionName=pdebug Nodes=mcr[0-191] MaxTime=30 MaxNodes=32 Default=YES
PartitionName=pbatch Nodes=mcr[192-1151]

Security

Besides authentication of Slurm communications based upon the value of the AuthType, digital signatures are used in job step credentials.
AuthTypeの値に基づくSlurm通信の認証に加えて、デジタル署名がジョブステップの資格情報で使用されます。
This signature is used by slurmctld to construct a job step credential, which is sent to srun and then forwarded to slurmd to initiate job steps.
この署名は、slurmctldがジョブステップ資格情報を作成するために使用します。この資格情報は、srunに送信されてから、slurmdに転送されてジョブステップを開始します。
This design offers improved performance by removing much of the job step initiation overhead from the slurmctld daemon.
この設計は、slurmctldデーモンからジョブステップ開始オーバーヘッドの多くを削除することにより、パフォーマンスを向上させます。
The digital signature mechanism is specified by the CredType configuration parameter and the default mechanism is MUNGE.
デジタル署名メカニズムはCredType構成パラメーターによって指定され、デフォルトのメカニズムはMUNGEです。

Authentication

Authentication of communications (identifying who generated a particular message) between Slurm components can use a different security mechanism that is configurable.
Slurmコンポーネント間の通信の認証（特定のメッセージを生成したユーザーの識別）では、構成可能な異なるセキュリティメカニズムを使用できます。
You must specify one "auth" plugin for this purpose using the AuthType configuration parameter.
この目的のために、AuthType構成パラメーターを使用して1つの「auth」プラグインを指定する必要があります。
Currently, only two authentication plugins are supported: auth/none and auth/munge.
現在、auth / noneとauth / mungeの2つの認証プラグインのみがサポートされています。
The auth/none plugin is built by default, but MUNGE should be installed in order to get properly authenticated communications.
auth / noneプラグインはデフォルトでビルドされますが、適切に認証された通信を取得するには、MUNGEをインストールする必要があります。
We recommend the use of MUNGE.
MUNGEの使用をお勧めします。
The configure script in the top-level directory of this distribution will determine which authentication plugins may be built.
このディストリビューションの最上位ディレクトリにあるconfigureスクリプトは、構築できる認証プラグインを決定します。
The configuration file specifies which of the available plugins will be utilized.
構成ファイルは、使用可能なプラグインのどれを使用するかを指定します。

Pluggable Authentication Module (PAM) support

A PAM module (Pluggable Authentication Module) is available for Slurm that can prevent a user from accessing a node which he has not been allocated, if that mode of operation is desired.
SlurmではPAMモジュール（Pluggable Authentication Module）を使用できます。これにより、ユーザーが割り当てられていないノードにアクセスできないようにすることができます（その操作モードが必要な場合）。

Starting the Daemons

For testing purposes you may want to start by just running slurmctld and slurmd on one node.
テストの目的で、1つのノードでslurmctldとslurmdを実行することから始めたい場合があります。
By default, they execute in the background.
デフォルトでは、バックグラウンドで実行されます。
Use the -D option for each daemon to execute them in the foreground and logging will be done to your terminal.
各デーモンの-Dオプションを使用してフォアグラウンドでデーモンを実行すると、端末にログが記録されます。
The -v option will log events in more detail with more v's increasing the level of detail (e.g. -vvvvvv).
-vオプションを使用すると、イベントがより詳細にログに記録され、vが増えると詳細レベルが上がります（例：-vvvvvv）。
You can use one window to execute "slurmctld -D -vvvvvv", a second window to execute "slurmd -D -vvvvv".
1つのウィンドウを使用して「slurmctld-D-vvvvvv」を実行し、2番目のウィンドウを使用して「slurmd-D-vvvvv」を実行できます。
You may see errors such as "Connection refused" or "Node X not responding" while one daemon is operative and the other is being started, but the daemons can be started in any order and proper communications will be established once both daemons complete initialization.
一方のデーモンが動作していて、もう一方のデーモンが起動しているときに、「接続が拒否されました」や「ノードXが応答していません」などのエラーが表示される場合がありますが、デーモンは任意の順序で起動でき、両方のデーモンが初期化を完了すると適切な通信が確立されます。
You can use a third window to execute commands such as "srun -N1 /bin/hostname" to confirm functionality.
3番目のウィンドウを使用して、「srun -N1 / bin / hostname」などのコマンドを実行し、機能を確認できます。

Another important option for the daemons is "-c" to clear previous state information.
デーモンのもう1つの重要なオプションは、以前の状態情報をクリアするための「-c」です。
Without the "-c" option, the daemons will restore any previously saved state information: node state, job state, etc.
「-c」オプションがないと、デーモンは以前に保存された状態情報（ノード状態、ジョブ状態など）を復元します。
With the "-c" option all previously running jobs will be purged and node state will be restored to the values specified in the configuration file.
「-c」オプションを使用すると、以前に実行されていたすべてのジョブがパージされ、ノードの状態が構成ファイルで指定された値に復元されます。
This means that a node configured down manually using the scontrol command will be returned to service unless noted as being down in the configuration file.
これは、scontrolコマンドを使用して手動でダウン構成されたノードは、構成ファイルでダウンしていると記載されていない限り、サービスに戻されることを意味します。
In practice, Slurm consistently restarts with preservation.
実際には、Slurmは一貫して保存を再開します。

Administration Examples

scontrol can be used to print all system information and modify most of it.
scontrolを使用して、すべてのシステム情報を印刷し、そのほとんどを変更できます。
Only a few examples are shown below.
以下にいくつかの例を示します。
Please see the scontrol man page for full details.
詳細については、scontrolのmanページを参照してください。
The commands and options are all case insensitive.
コマンドとオプションはすべて大文字と小文字を区別しません。

Print detailed state of all jobs in the system.
システム内のすべてのジョブの詳細な状態を出力します。

adev0: scontrol
scontrol: show job
JobId=475 UserId=bob(6885) Name=sleep JobState=COMPLETED
   Priority=4294901286 Partition=batch BatchFlag=0
   AllocNode:Sid=adevi:21432 TimeLimit=UNLIMITED
   StartTime=03/19-12:53:41 EndTime=03/19-12:53:59
   NodeList=adev8 NodeListIndecies=-1
   NumCPUs=0 MinNodes=0 OverSubscribe=0 Contiguous=0
   MinCPUs=0 MinMemory=0 Features=(null) MinTmpDisk=0
   ReqNodeList=(null) ReqNodeListIndecies=-1

JobId=476 UserId=bob(6885) Name=sleep JobState=RUNNING
   Priority=4294901285 Partition=batch BatchFlag=0
   AllocNode:Sid=adevi:21432 TimeLimit=UNLIMITED
   StartTime=03/19-12:54:01 EndTime=NONE
   NodeList=adev8 NodeListIndecies=8,8,-1
   NumCPUs=0 MinNodes=0 OverSubscribe=0 Contiguous=0
   MinCPUs=0 MinMemory=0 Features=(null) MinTmpDisk=0
   ReqNodeList=(null) ReqNodeListIndecies=-1

Print the detailed state of job 477 and change its priority to zero.
ジョブ477の詳細な状態を印刷し、その優先度をゼロに変更します。
A priority of zero prevents a job from being initiated (it is held in "pending" state).
優先度がゼロの場合、ジョブは開始されません（「保留中」の状態で保持されます）。

adev0: scontrol
scontrol: show job 477
JobId=477 UserId=bob(6885) Name=sleep JobState=PENDING
   Priority=4294901286 Partition=batch BatchFlag=0
   more data removed....
scontrol: update JobId=477 Priority=0

Print the state of node adev13 and drain it.
ノードadev13の状態を出力し、それを排出します。
To drain a node, specify a new state of DRAIN, DRAINED, or DRAINING.
ノードをドレインするには、DRAIN、DRAINED、またはDRAININGの新しい状態を指定します。
Slurm will automatically set it to the appropriate value of either DRAINING or DRAINED depending on whether the node is allocated or not.
Slurmは、ノードが割り当てられているかどうかに応じて、DRAININGまたはDRAINEDの適切な値に自動的に設定します。
Return it to service later.
後でサービスに戻します。

adev0: scontrol
scontrol: show node adev13
NodeName=adev13 State=ALLOCATED CPUs=2 RealMemory=3448 TmpDisk=32000
   Weight=16 Partition=debug Features=(null)
scontrol: update NodeName=adev13 State=DRAIN
scontrol: show node adev13
NodeName=adev13 State=DRAINING CPUs=2 RealMemory=3448 TmpDisk=32000
   Weight=16 Partition=debug Features=(null)
scontrol: quit
Later
adev0: scontrol
scontrol: show node adev13
NodeName=adev13 State=DRAINED CPUs=2 RealMemory=3448 TmpDisk=32000
   Weight=16 Partition=debug Features=(null)
scontrol: update NodeName=adev13 State=IDLE

Reconfigure all Slurm daemons on all nodes.
すべてのノードですべてのSlurmデーモンを再構成します。
This should be done after changing the Slurm configuration file.
これは、Slurm構成ファイルを変更した後に実行する必要があります。

adev0: scontrol reconfig

Print the current Slurm configuration.
現在のSlurm構成を出力します。
This also reports if the primary and secondary controllers (slurmctld daemons) are responding.
これは、プライマリおよびセカンダリコントローラ（slurmctldデーモン）が応答しているかどうかも報告します。
To just see the state of the controllers, use the command ping.
コントローラの状態を確認するには、コマンドpingを使用します。

adev0: scontrol show config
Configuration data as of 2019-03-29T12:20:45
...
SlurmctldAddr           = eadevi
SlurmctldDebug          = info
SlurmctldHost[0]        = adevi
SlurmctldHost[1]        = adevj
SlurmctldLogFile        = /var/log/slurmctld.log
...

Slurmctld(primary) at adevi is UP
Slurmctld(backup) at adevj is UP

Shutdown all Slurm daemons on all nodes.
すべてのノードですべてのSlurmデーモンをシャットダウンします。

adev0: scontrol shutdown

Upgrades

Background: The Slurm version number contains three period-separated numbers that represent both the major Slurm release and maintenance release level.
背景：Slurmのバージョン番号には、主要なSlurmリリースとメンテナンスリリースレベルの両方を表す3つの期間区切りの番号が含まれています。
The first two parts combine together to represent the major release, and match the year and month of that major release.
最初の2つの部分は、メジャーリリースを表すために組み合わされ、そのメジャーリリースの年と月に一致します。
The third number in the version designates a specific maintenance level: year.month.maintenance-release (e.g. 20.02.2 is major Slurm release 20.02, and maintenance version 2).
バージョンの3番目の番号は、特定のメンテナンスレベルを指定します：year.month.maintenance-release（たとえば、20.02.2はメジャーSlurmリリース20.02であり、メンテナンスバージョン2です）。
Thus version 20.02.x was initially released in February 2020.
したがって、バージョン20.02.xは、2020年2月に最初にリリースされました。
Changes in the RPCs (remote procedure calls) and state files will only be made if the major release number changes, which typically happens about every nine months.
RPC（リモートプロシージャコール）と状態ファイルの変更は、メジャーリリース番号が変更された場合にのみ行われます。これは通常、約9か月ごとに発生します。
A list of most recent major Slurm releases is shown below.
最新のメジャーSlurmリリースのリストを以下に示します。

18.08.x (Released August 2018)
19.05.x (Released May 2019)
20.02.x (Released February 2020)

Slurm's MPI libraries may also change if the major release number change, requiring applications be re-linked (behavior may vary depending upon the MPI implementation used and the specific Slurm changes between releases).
メジャーリリース番号が変更されると、SlurmのMPIライブラリも変更される可能性があり、アプリケーションを再リンクする必要があります（動作は、使用されるMPI実装およびリリース間での特定のSlurmの変更によって異なる場合があります）。
Locally developed Slurm plugins may also require modification.
ローカルで開発されたSlurmプラグインも変更が必要な場合があります。
Slurm daemons will support RPCs and state files from the two previous major releases (e.g. a version 20.02.x SlurmDBD will support slurmctld daemons and commands with a version of 20.02.x, 19.05.x, or 18.08.x).
Slurmデーモンは、以前の2つのメジャーリリースのRPCと状態ファイルをサポートします（たとえば、バージョン20.02.x SlurmDBDは、バージョン20.02.x、19.05.x、または18.08.xのslurmctldデーモンとコマンドをサポートします）。
This means that upgrading at least once each year is recommended.
つまり、少なくとも年に1回はアップグレードすることをお勧めします。
Otherwise, intermediate upgrades will be required to preserve state information.
それ以外の場合は、状態情報を保持するために中間アップグレードが必要になります。
Changes in the mainenance release number generally represent only bug fixes, but may also include minor enhancements.
メンテナンスリリース番号の変更は、通常、バグ修正のみを表していますが、マイナーな機能強化が含まれている場合もあります。

If the SlurmDBD daemon is used, it must be at the same or higher major release number as the Slurmctld daemons.
SlurmDBDデーモンを使用する場合は、Slurmctldデーモンと同じかそれ以上のメジャーリリース番号である必要があります。
In other words, when changing the version to a higher release number (e.g from 19.05.x to 20.02.x) always upgrade the SlurmDBD daemon first.
つまり、バージョンをより高いリリース番号（19.05.xから20.02.xなど）に変更する場合は、必ず最初にSlurmDBDデーモンをアップグレードしてください。
Database table changes may be required for the upgrade, for example adding new fields to existing tables.
アップグレードには、既存のテーブルに新しいフィールドを追加するなど、データベーステーブルの変更が必要になる場合があります。
If the database contains a large number of entries, the SlurmDBD daemon may require tens of minutes to update the database and be unresponsive during this time interval.
データベースに多数のエントリが含まれている場合、SlurmDBDデーモンはデータベースを更新するのに数十分かかり、この時間間隔中に応答しなくなる可能性があります。

Before upgrading SlurmDBD it is strongly recommended to make a backup of the database.
SlurmDBDをアップグレードする前に、データベースのバックアップを作成することを強くお勧めします。
When using mysqldump, the default behavior is to lock the tables, which can cause issues if SlurmDBD is still trying to send updates to the database.
mysqldumpを使用する場合、デフォルトの動作はテーブルをロックすることです。これにより、SlurmDBDがデータベースに更新を送信しようとしている場合に問題が発生する可能性があります。
To avoid locking the tables we recommend you use the --single-transaction flag with mysqldump.
テーブルのロックを回避するには、mysqldumpで--single-transactionフラグを使用することをお勧めします。
This will dump a consistent state of the database without blocking any applications.
これにより、アプリケーションをブロックすることなく、データベースの一貫した状態がダンプされます。
Note that in order for this flag to have the desired effect you must be using the InnoDB storage engine (specified by default when Slurm automatically creates any table).
このフラグが目的の効果を発揮するには、InnoDBストレージエンジンを使用している必要があることに注意してください（Slurmがテーブルを自動的に作成するときにデフォルトで指定されます）。
The --single-transaction flag permits a live logical backup (and is thus useful for periodic backups while in production).
--single-transactionフラグは、ライブ論理バックアップを許可します（したがって、本番環境での定期的なバックアップに役立ちます）。
When upgrading Slurm, it is recommended to first stop the SlurmDBD daemon and then dump the database using mysqldump before proceeding with the upgrade, as stated in the upgrade guide a few paragraphs below.
Slurmをアップグレードするときは、以下のアップグレードガイドに記載されているように、アップグレードを続行する前に、まずSlurmDBDデーモンを停止し、次にmysqldumpを使用してデータベースをダンプすることをお勧めします。
Note that requests intended for SlurmDBD from Slurmctld will be queued while SlurmDBD is down, but the queue size is limited and you should monitor the DBD Agent Queue size with the sdiag command.
SlurmctldからのSlurmDBDを対象とした要求は、SlurmDBDがダウンしている間はキューに入れられますが、キューのサイズには制限があるため、sdiagコマンドを使用してDBDエージェントのキューのサイズを監視する必要があります。

The slurmctld daemon must also be upgraded before or at the same time as the slurmd daemons on the compute nodes.
slurmctldデーモンは、計算ノード上のslurmdデーモンの前または同時にアップグレードする必要もあります。
Generally, upgrading Slurm on all of the login and compute nodes is recommended, although rolling upgrades are also possible (i.e. upgrading the head node(s) first then upgrading the compute and login nodes later at various times).
一般に、すべてのログインノードと計算ノードでSlurmをアップグレードすることをお勧めしますが、ローリングアップグレードも可能です（つまり、最初にヘッドノードをアップグレードしてから、後でさまざまな時点で計算ノードとログインノードをアップグレードします）。
Also see the note above about reverse compatibility.
下位互換性については、上記の注も参照してください。

Almost every new major release of Slurm (e.g. 19.05.x to 20.02.x) involves changes to the state files with new data structures, new options, etc.
Slurmのほぼすべての新しいメジャーリリース（19.05.xから20.02.xなど）には、新しいデータ構造、新しいオプションなどを使用した状態ファイルの変更が含まれます。
Slurm permits upgrades to a new major release from the past two major releases, which happen every nine months (e.g. 18.08.x or 19.05.x to 20.02.x) without loss of jobs or other state information.
Slurmは、過去2つのメジャーリリースから新しいメジャーリリースへのアップグレードを許可します。これは、ジョブやその他の状態情報を失うことなく、9か月ごとに行われます（例：18.08.xまたは19.05.xから20.02.x）。
State information from older versions will not be recognized and will be discarded, resulting in loss of all running and pending jobs.
古いバージョンの状態情報は認識されず、破棄されるため、実行中および保留中のすべてのジョブが失われます。
State files are not recognized when downgrading (e.g. from 19.05.x to 18.08.x) and will be discarded, resulting in loss of all running and pending jobs. For this reason, creating backup copies of state files (as described below) can be of value.
状態ファイルは、ダウングレード（19.05.xから18.08.xなど）時に認識されず、破棄されるため、実行中および保留中のすべてのジョブが失われます。このため、（以下で説明するように）状態ファイルのバックアップコピーを作成することは価値があります。
Therefore when upgrading Slurm (more precisely, the slurmctld daemon), saving the StateSaveLocation (as defined in slurm.conf) directory contents with all state information is recommended.
したがって、Slurm（より正確にはslurmctldデーモン）をアップグレードするときは、StateSaveLocation（slurm.confで定義されている）ディレクトリの内容をすべての状態情報とともに保存することをお勧めします。
If you need to downgrade, restoring that directory's contents will let you recover the jobs.
ダウングレードする必要がある場合は、そのディレクトリの内容を復元すると、ジョブを回復できます。
Jobs submitted under the new version will not be in those state files, but it can let you recover most jobs.
新しいバージョンで送信されたジョブはこれらの状態ファイルには含まれませんが、ほとんどのジョブを回復できます。
An exception to this is that jobs may be lost when installing new pre-release versions (e.g. 20.02.0-pre1 to 20.02.0-pre2).
これの例外は、新しいプレリリースバージョン（例：20.02.0-pre1から20.02.0-pre2）をインストールするときにジョブが失われる可能性があることです。
Developers will try to note these cases in the NEWS file.
開発者は、これらのケースをNEWSファイルに記録しようとします。
Contents of major releases are also described in the RELEASE_NOTES file.
メジャーリリースの内容は、RELEASE_NOTESファイルにも記載されています。

The libslurm.so version is increased every major release.
libslurm.soバージョンは、メジャーリリースごとに増加しています。
So things like MPI libraries with Slurm integration should be recompiled.
したがって、Slurm統合を備えたMPIライブラリのようなものは再コンパイルする必要があります。
Sometimes it works to just symlink the old .so name(s) to the new one, but this has no guarantee of working.
古い.so名を新しい名前にシンボリックリンクするだけで機能する場合もありますが、これが機能する保証はありません。

Be mindful of your configured SlurmdTimeout and SlurmctldTimeout values.
構成済みのSlurmdTimeout値とSlurmctldTimeout値に注意してください。
If the Slurm daemon's are down for longer than the specified timeout during an upgrade, nodes may be marked DOWN and their jobs killed.
アップグレード中にSlurmデーモンが指定されたタイムアウトより長くダウンしている場合、ノードはDOWNとマークされ、ジョブが強制終了される可能性があります。
You can either increase the timeout values during an upgrade or ensure that the slurmd daemons on compute nodes are not down for longer than SlurmdTimeout.
アップグレード中にタイムアウト値を増やすか、計算ノードのslurmdデーモンがSlurmdTimeoutより長くダウンしないようにすることができます。
The recommended upgrade order is as follows:
推奨されるアップグレード順序は次のとおりです。

Shutdown the slurmdbd daemon
slurmdbdデーモンをシャットダウンします
Dump the Slurm database using mysqldump (in case of any possible failure) and increase innodb_buffer_size in my.cnf to 128M
mysqldumpを使用してSlurmデータベースをダンプし（障害が発生する可能性がある場合）、my.cnfのinnodb_buffer_sizeを128Mに増やします。
Upgrade the slurmdbd daemon
slurmdbdデーモンをアップグレードします
Restart the slurmdbd daemon
slurmdbdデーモンを再起動します
Increase configured SlurmdTimeout and SlurmctldTimeout values and execute "scontrol reconfig" for them to take effect
構成済みのSlurmdTimeout値とSlurmctldTimeout値を増やし、「scontrolreconfig」を実行してそれらを有効にします
Shutdown the slurmctld daemon(s)
slurmctldデーモンをシャットダウンします
Shutdown the slurmd daemons on the compute nodes
計算ノードのslurmdデーモンをシャットダウンします
Copy the contents of the configured StateSaveLocation directory (in case of any possible failure)
構成されたStateSaveLocationディレクトリの内容をコピーします（障害が発生した場合）
Upgrade the slurmctld and slurmd daemons
slurmctldデーモンとslurmdデーモンをアップグレードします
Restart the slurmd daemons on the compute nodes
計算ノードでslurmdデーモンを再起動します
Restart the slurmctld daemon(s)
slurmctldデーモンを再起動します
Validate proper operation
適切な操作を検証する
Restore configured SlurmdTimeout and SlurmctldTimeout values and execute "scontrol reconfig" for them to take effect
構成済みのSlurmdTimeout値とSlurmctldTimeout値を復元し、「scontrolreconfig」を実行してそれらを有効にします
Destroy backup copies of database and/or state files
データベースや状態ファイルのバックアップコピーを破棄します

Note: It is possible to update the slurmd daemons on a node-by-node basis after the slurmctld daemon(s) are upgraded, but do make sure their down time is below the SlurmdTimeout value.
注：slurmctldデーモンがアップグレードされた後、ノードごとにslurmdデーモンを更新することは可能ですが、それらのダウンタイムがSlurmdTimeout値を下回っていることを確認してください。

If you have built your own version of Slurm plugins, they will likely need modification to support a new version of Slurm.
独自のバージョンのSlurmプラグインを作成した場合は、新しいバージョンのSlurmをサポートするために変更が必要になる可能性があります。
It is common for plugins to add new functions and function arguments during major updates.
プラグインは、メジャーアップデート中に新しい関数と関数引数を追加するのが一般的です。
See the RELEASE_NOTES file for details.
詳細については、RELEASE_NOTESファイルを参照してください。

FreeBSD

FreeBSD administrators can install the latest stable Slurm as a binary package using:
FreeBSD管理者は、以下を使用して最新の安定したSlurmをバイナリパッケージとしてインストールできます。

pkg install slurm-wlm

Or, it can be built and installed from source using:
または、以下を使用してソースからビルドおよびインストールできます。

cd /usr/ports/sysutils/slurm-wlm && make install

The binary package installs a minimal Slurm configuration suitable for typical compute nodes.
バイナリパッケージは、一般的な計算ノードに適した最小限のSlurm構成をインストールします。
Installing from source allows the user to enable options such as mysql and gui tools via a configuration menu.
ソースからインストールすると、ユーザーは構成メニューからmysqlやguiツールなどのオプションを有効にできます。

Last modified 30 January 2020