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

  1. Make sure the clocks, users and groups (UIDs and GIDs) are synchronized across the cluster.
    クロック、ユーザー、およびグループ（UIDおよびGID）がクラスター全体で同期されていることを確認します。
  2. Install MUNGE for authentication. Make sure that all nodes in your cluster have the same munge.key. Make sure the MUNGE daemon, munged is started before you start the Slurm daemons.
    認証のためにMUNGEをインストールします。クラスタ内のすべてのノードが同じmunge.keyを持っていることを確認してください。Slurmデーモンを開始する前に、MUNGEデーモンが変更されていることを確認してください。
  3. 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
  4. cd to the directory containing the Slurm source and type ./configure with appropriate options, typically --prefix= and --sysconfdir=
    Slurmソースを含むディレクトリにcdし、適切なオプション、通常は--prefix =および--sysconfdir =を使用して./configureと入力します。
  5. Type make to compile Slurm.
    makeと入力してSlurmをコンパイルします。
  6. Type make install to install the programs, documentation, libraries, header files, etc.
    make installと入力して、プログラム、ドキュメント、ライブラリ、ヘッダーファイルなどをインストールします。
  7. Build a configuration file using your favorite web browser and doc/html/configurator.html.
    NOTE: The SlurmUser must exist prior to starting Slurm and must exist on all nodes of the cluster.
    NOTE: The parent directories for Slurm's log files, process ID files, state save directories, etc. are not created by Slurm. They must be created and made writable by SlurmUser as needed prior to starting Slurm daemons.
    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).
    お好みのWebブラウザーとdoc / html / configurator.htmlを使用して構成ファイルを作成します。注：SlurmUserはSlurmを開始する前に存在し、クラスターのすべてのノードに存在している必要があります。注：Slurmのログファイルの親ディレクトリ、プロセスIDファイル、状態保存ディレクトリなどはSlurmによって作成されません。Slurmデーモンを開始する前に、必要に応じてSlurmUserによって作成および書き込み可能にする必要があります。注：インストールプロセス中に親ディレクトリが作成された場合（実行可能ファイル、ライブラリなど）、これらのディレクトリには読み取りと同等のアクセス権があります。 / write / executeは、umask値を引いた全員に対して実行します（たとえば、umask = 0022は「drwxr-rx」の権限を持つディレクトリを生成し、mask = 0000はセキュリティ上の問題である「drwxrwrwx」の権限を持つディレクトリを生成します）。
  8. Type ldconfig -n <library_location> so that the Slurm libraries can be found by applications that intend to use Slurm APIs directly.
    ldconfig -nと入力します これにより、Slurm APIを直接使用するアプリケーションでSlurmライブラリを見つけることができます。
  9. Install the configuration file in <sysconfdir>/slurm.conf.
    NOTE: You will need to install this configuration file on all nodes of the cluster.
    構成ファイルを /slurm.conf.NOTE：この構成ファイルをクラスターのすべてのノードにインストールする必要があります。
  10. systemd (optional): enable the appropriate services on each system:
    systemd（オプション）：各システムで適切なサービスを有効にします。
    • Controller: systemctl enable slurmctld
    • Database: systemctl enable slurmdbd
    • Compute Nodes: systemctl enable slurmd
  11. Start the slurmctld and slurmd daemons.
    slurmctldデーモンとslurmdデーモンを起動します。

NOTE: Items 3 through 8 can be replaced with
注：3から8のアイテムは、

  1. rpmbuild -ta slurm*.tar.bz2
  2. 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. See the README and INSTALL files in the source distribution for more details.
Slurmを手動でビルドおよびインストールする手順を以下に示します。詳細については、ソースディストリビューションのREADMEおよびINSTALLファイルを参照してください。

  1. Unpack the distributed tarball:
    tar -xaf slurm*tar.bz2
    配布されたtarballを解凍します。tar-xaf slurm * tar.bz2
  2. cd to the directory containing the Slurm source and type ./configure with appropriate options (see below).
    Slurmソースを含むディレクトリにcdし、適切なオプションを指定して./configureと入力します（以下を参照）。
  3. Type make install to compile and install the programs, documentation, libraries, header files, etc.
    make installと入力して、プログラム、ドキュメント、ライブラリ、ヘッダーファイルなどをコンパイルしてインストールします。
  4. Type ldconfig -n <library_location> so that the Slurm libraries can be found by applications that intend to use Slurm APIs directly. The library location will be a subdirectory of PREFIX (described below) and depend upon the system type and configuration, typically lib or 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.
    ldconfig -nと入力します これにより、Slurm APIを直接使用するアプリケーションでSlurmライブラリを見つけることができます。ライブラリーの場所はPREFIX（以下で説明）のサブディレクトリーであり、システムのタイプと構成（通常はlibまたはlib64）によって異なります。たとえば、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. The most commonly used arguments to the configure command include:
構成オプションの完全なリストは、コマンドconfigure --helpによって返されます。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. The default value is PREFIX/etc
Slurm構成ファイルの場所を指定します。デフォルト値はPREFIX / etcです。

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

  • 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.
    hdf5開発ライブラリが存在する場合、acct_gather_profile / hdf5ジョブプロファイリングプラグインがビルドされます。
  • HTML Man Pages HTML versions of the man pages will be generated if the man2html command is present.
    man2htmlコマンドが存在する場合、manページのHTMLバージョンが生成されます。
  • IPMI Engergy Consumption The acct_gather_energy/ipmi accouting plugin will be built if the freeimpi development library is present.
    acct_gather_energy / ipmi会計プラグインは、freeimpi開発ライブラリが存在する場合にビルドされます。
  • 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 / ofed InfiniBandアカウンティングプラグインがビルドされます。
  • Lua Support The lua API will be available in various plugins if the lua development library is present.
    lua開発ライブラリが存在する場合、lua APIはさまざまなプラグインで利用できます。
  • MUNGE The auth/munge plugin will be built if the MUNGE authentication development library is installed. MUNGE is used as the default authentication mechanism.
    MUNGE認証開発ライブラリがインストールされている場合、auth / mungeプラグインがビルドされます。MUNGEがデフォルトの認証メカニズムとして使用されます。
  • MySQL MySQL support for accounting will be built if the mysql development library is present.
    MySQLアカウンティングの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.
    scontrolおよびsacctmgrのインタラクティブモードでのreadlineサポートは、readline開発ライブラリが存在する場合に利用できます。
  • RRD External Sensor Data Collection The ext_sensors/rrd plugin will be built if the rrdtool development library is present.
    ext_sensors / rrdプラグインは、rrdtool開発ライブラリが存在する場合にビルドされます。
  • 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. 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:
ホームディレクトリの.rpmmacrosファイルで構築されたRPMのいくつかの側面を制御できます。特別なマクロ定義が必要になるのは、通常とは異なる場所にファイルがインストールされている場合のみです。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". It orchestrates Slurm activities, including queuing of jobs, monitoring node states, and allocating resources to jobs. 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). 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.
slurmctldは「コントローラー」と呼ばれることもあります。ジョブのキューイング、ノードの状態の監視、ジョブへのリソースの割り当てなど、Slurmアクティビティを調整します。プライマリコントローラーに障害が発生した場合に制御を自動的に引き継ぐオプションのバックアップコントローラーがあります（以下の高可用性セクションを参照）。プライマリコントローラは、サービスに復元されるたびに制御を再開します。状態が変化すると、コントローラーはその状態をディスクに保存します（以下の構成セクションの「StateSaveLocation」を参照）。この状態は、起動時にコントローラーによって回復できます。状態の変更が保存されるので、コントローラーが（バックアップコントローラーとの間で）移動したり再起動したりしたときに、ジョブやその他の状態情報を保持できます。

We recommend that you create a Unix user slurm for use by slurmctld. This user name will also be specified using the SlurmUser in the slurm.conf configuration file. 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で使用するUnixユーザーslurmを作成することをお勧めします。このユーザー名は、slurm.conf構成ファイルのSlurmUserを使用して指定することもできます。このユーザーは、クラスターのすべてのノードに存在する必要があります。slurmctldが使用するファイルとディレクトリは、ユーザーSlurmUserが読み取りまたは書き込み可能である必要があることに注意してください（Slurm構成ファイルは読み取り可能である必要があります。ログファイルディレクトリと状態保存ディレクトリは書き込み可能である必要があります）。

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

If you want to archive job accounting records to a database, the slurmdbd (Slurm DataBase Daemon) should be used. We recommend that you defer adding accounting support until after basic Slurm functionality is established on your system. An Accounting web page contains more information.
ジョブアカウンティングレコードをデータベースにアーカイブする場合は、slurmdbd（Slurm DataBase Daemon）を使用する必要があります。システムで基本的なSlurm機能が確立されるまで、アカウンティングサポートの追加を延期することをお勧めします。アカウンティング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. Any backup hosts configured should be on a different node than the node hosting the primary slurmctld. However, all hosts should mount a common file system containing the state information (see "StateSaveLocation" in the Configuration section below).
複数のSlurmctldHostエントリを構成できます。最初のエントリを超えるエントリはすべてバックアップホストとして扱われます。構成されたバックアップホストは、プライマリslurmctldをホストしているノードとは異なるノード上にある必要があります。ただし、すべてのホストは、状態情報を含む共通のファイルシステムをマウントする必要があります（以下の構成セクションの「StateSaveLocation」を参照）。

If more than one host is specified, when the primary fails the second listed SlurmctldHost will take over for it. 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. Other than a brief period of non- responsiveness, the transition back and forth should go undetected.
複数のホストが指定されている場合、プライマリに障害が発生すると、2番目にリストされたSlurmctldHostがそれを引き継ぎます。プライマリがサービスに戻ると、バックアップに通知します。その後、バックアップは状態を保存し、バックアップモードに戻ります。プライマリは保存された状態を読み取り、通常の操作を再開します。同様に、リストされた最初の2つのホストの両方が失敗した場合、3番目のSlurmctldHostは、プライマリがサービスに戻るまで引き継ぎます。無反応の短い期間を除いて、前後の遷移は検出されないはずです。

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

Any time the slurmctld daemon or hardware fails before state information reaches disk can result in lost state. 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. 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. 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.
状態情報がディスクに到達する前にslurmctldデーモンまたはハードウェアに障害が発生すると、いつでも状態が失われる可能性があります。Slurmctldは状態を頻繁に（デフォルトでは5秒ごと）書き込みますが、ジョブの数が多いと、レコードのフォーマットと書き込みに数秒かかることがあり、最近の変更がディスクに書き込まれない場合があります。もう1つの例は、状態情報がファイルに書き込まれるが、ノードに障害が発生したときにその情報がディスクに書き込まれるのではなく、メモリにキャッシュされる場合です。ディスクに書き込まれる状態保存の間隔は、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. It is not necessary to permit user logins to the control hosts (SlurmctldHost), but the users and groups must be resolvable on those hosts.
クラスター全体で、ユーザーとグループの名前空間（UIDとGIDを含む）が統一されている必要があります。制御ホスト（SlurmctldHost）へのユーザーログインを許可する必要はありませんが、ユーザーとグループはそれらのホストで解決可能である必要があります。

Authentication of Slurm communications

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

MPI support

Slurm supports many different MPI implementations. For more information, see MPI.
Slurmは、さまざまな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). The first configuration parameter of interest is PriorityType with two options available: basic (first-in-first-out) and multifactor. 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.
Slurmは、ニーズと構成を管理する意欲（その多くはデータベースを必要とします）に応じて、かなり単純または非常に高度なスケジューリングアルゴリズムで構成できます。対象となる最初の構成パラメーターは、基本（先入れ先出し）と多要素の2つのオプションが利用可能なPriorityTypeです。多要素プラグインは、多数の構成パラメーター（年齢、サイズ、フェアシェア割り当てなど）に基づいてジョブに優先順位を割り当てます。その詳細は、このドキュメントの範囲を超えています。詳細については、Multifactor Job Priority Pluginドキュメントを参照してください。

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. 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. For more information, please see Consumable Resources in Slurm.
Slurmが使用するリソース選択メカニズムは、SelectType構成パラメーターによって制御されます。ノードごとに複数のジョブを実行するが、プロセッサ、メモリ、その他のリソースの割り当てを追跡および管理する場合は、cons_res（消費可能リソース）プラグインをお勧めします。詳細については、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. For more information see Accounting.
Slurmは、シンプルなテキストファイル、データベース（MySQLまたはMariaDB）、または複数のクラスターのアカウンティングデータを安全に管理するデーモンに直接書き込まれるアカウンティングレコードをサポートします。詳細については、会計を参照してください。

Compute node access

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

Configuration

The Slurm configuration file includes a wide variety of parameters. 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. 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. 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"). 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. In this case "emcri" is the private management network interface for the host "mcri". Port numbers to be used for communications are specified as well as various timer values.
Slurm構成ファイルには、さまざまなパラメーターが含まれています。この構成ファイルは、クラスターの各ノードで使用可能でなければならず、一貫した内容でなければなりません。パラメータの詳細な説明は、slurm.confのmanページに含まれています。その情報を複製するのではなく、最小限のサンプル構成ファイルを以下に示します。slurm.confファイルでは、少なくともこのサンプルで定義されている構成パラメーターと、おそらく追加の構成パラメーターを定義する必要があります。「＃」に続くテキストはコメントと見なされます。ファイル内のキーワードでは大文字と小文字が区別されませんが、通常、引数は区別されます（たとえば、「SlurmUser = slurm」は「slurmuser = slurm」と指定される場合があります）。制御マシンには、他のすべてのマシン仕様と同様に、ホスト名と通信に使用される名前の両方を含めることができます。この場合、ホストの名前は「mcri」で、通信には「emcri」という名前が使用されます。この場合、「emcri」はホスト「mcri」のプライベート管理ネットワークインターフェイスです。通信に使用するポート番号や各種タイマー値を指定します。

The SlurmUser must be created as needed prior to starting Slurm and must exist on all nodes in your cluster. The parent directories for Slurm's log files, process ID files, state save directories, etc. are not created by Slurm. They must be created and made writable by SlurmUser as needed prior to starting Slurm daemons.
SlurmUserは、Slurmを開始する前に必要に応じて作成する必要があり、クラスター内のすべてのノードに存在する必要があります。Slurmのログファイル、プロセスIDファイル、状態保存ディレクトリなどの親ディレクトリは、Slurmによって作成されません。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]"). Up to two numeric ranges can be included in the expression (e.g. "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組の角括弧を含めることができます（例： "linux [0-64,128]"、または "lx [15,18,32 -33]」）。式には最大2つの数値範囲を含めることができます（例： "rack [0-63] _blade [0-41]"）。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. 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. See the slurm.conf man page for details on all configuration parameters.
ノード名には最大3つの名前を指定できます。NodeNameはノードを参照するときにすべてのSlurmツールで使用される名前、NodeAddrはSlurmがノードとの通信に使用する名前またはIPアドレス、NodeHostnameはコマンドによって返される名前/ bin / hostname -s。NodeNameのみが必要です（他のデフォルトは同じ名前です）が、3つのパラメーターすべてをサポートすることで、ノードの命名とアドレス指定を完全に制御できます。すべての構成パラメーターの詳細については、slurm.confのmanページを参照してください。

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. 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. Any node lacking these minimum configuration values will be considered DOWN and not scheduled. Note that a more extensive sample configuration file is provided in 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.
ノードは複数のパーティションに存在でき、各パーティションには異なる制約（許可されたユーザー、時間制限、ジョブサイズ制限など）を設定できます。したがって、各パーティションは個別のキューと見なすことができます。パーティションとノードの仕様では、ノード範囲式を使用してノードを簡潔に識別します。この構成ファイルは、Slurmの1154ノードのクラスターを定義しますが、いくつかのノード範囲式を変更するだけで、はるかに大きなクラスターに使用できます。ノードが使用可能であると見なされる必要がある必要がある最小プロセッサー数（CPU）、実メモリー・スペース（RealMemory、メガバイト）、および一時ディスク・スペース（TmpDisk、メガバイト）を指定します。これらの最小構成値がないノードは、DOWNと見なされ、スケジュールされません。より広範なサンプル構成ファイルがetc / slurm.conf.exampleに提供されていることに注意してください。

#
# 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. 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. This design offers improved performance by removing much of the job step initiation overhead from the slurmctld daemon. The digital signature mechanism is specified by the CredType configuration parameter and the default mechanism is MUNGE.
AuthTypeの値に基づくSlurm通信の認証に加えて、デジタル署名がジョブステップの資格情報で使用されます。このシグネチャは、slurmctldがジョブステップ資格情報を構築するために使用します。これは、srunに送信され、slurmdに転送されてジョブステップを開始します。この設計では、slurmctldデーモンからジョブステップ開始のオーバーヘッドの多くを取り除くことにより、パフォーマンスが向上しています。デジタル署名メカニズムはCredType構成パラメーターで指定され、デフォルトのメカニズムはMUNGEです。

Authentication

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

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.
PAMモジュール（Pluggable Authentication Module）はSlurmで使用でき、その操作モードが必要な場合、ユーザーが割り当てられていないノードにアクセスできないようにすることができます。

Starting the Daemons

For testing purposes you may want to start by just running slurmctld and slurmd on one node. 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. The -v option will log events in more detail with more v's increasing the level of detail (e.g. -vvvvvv). You can use one window to execute "slurmctld -D -vvvvvv", a second window to execute "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. You can use a third window to execute commands such as "srun -N1 /bin/hostname" to confirm functionality.
テストの目的で、1つのノードでslurmctldとslurmdを実行するだけで開始できます。デフォルトでは、バックグラウンドで実行されます。デーモンごとに-Dオプションを使用してフォアグラウンドで実行すると、端末へのロギングが行われます。-vオプションを指定すると、イベントのログがより詳細になり、vの詳細度が高くなります（-vvvvvvなど）。1つのウィンドウを使用して「slurmctld -D -vvvvv」を実行し、2番目のウィンドウを使用して「slurmd -D -vvvvv」を実行できます。一方のデーモンが動作していて他方が起動しているときに、「接続が拒否されました」または「ノードXが応答しません」などのエラーが表示される場合がありますが、デーモンは任意の順序で起動でき、両方のデーモンが初期化を完了すると適切な通信が確立されます。3番目のウィンドウを使用して、「

Another important option for the daemons is "-c" to clear previous state information. Without the "-c" option, the daemons will restore any previously saved state information: node state, job state, etc. 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. 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. In practice, Slurm consistently restarts with preservation.
デーモンのもう1つの重要なオプションは、以前の状態情報をクリアする「-c」です。「-c」オプションを使用しない場合、デーモンは以前に保存された状態情報（ノード状態、ジョブ状態など）を復元します。「-c」オプションを使用すると、以前に実行されたすべてのジョブがパージされ、ノード状態が指定された値に復元されます構成ファイル内。これは、scontrolコマンドを使用して手動で構成されたノードは、構成ファイルで停止していると明記されていない限り、サービスに戻されることを意味します。実際には、Slurmは常に保持されて再起動します。

Administration Examples

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

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. A priority of zero prevents a job from being initiated (it is held in "pending" state).
ジョブ477の詳細な状態を出力し、その優先順位をゼロに変更します。優先度が0の場合、ジョブは開始されません（「保留」状態に保持されます）。

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

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. This should be done after changing the Slurm configuration file.
すべてのノードですべてのSlurmデーモンを再構成します。これは、Slurm構成ファイルを変更した後に行う必要があります。

adev0: scontrol reconfig

Print the current Slurm configuration. This also reports if the primary and secondary controllers (slurmctld daemons) are responding. To just see the state of the controllers, use the command ping.
現在のSlurm構成を印刷します。これは、プライマリおよびセカンダリコントローラ（slurmctldデーモン）が応答しているかどうかも報告します。コントローラーの状態を確認するには、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. The first two parts combine together to represent the major release, and match the year and month of that major release. 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). Thus version 20.02.x was initially released in February 2020. 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. A list of most recent major Slurm releases is shown below.
背景：Slurmのバージョン番号には、メジャーSlurmリリースとメンテナンスリリースレベルの両方を表す3つのピリオド区切りの番号が含まれています。最初の2つの部分を組み合わせてメジャーリリースを表し、そのメジャーリリースの年と月を一致させます。バージョンの3番目の数字は、特定のメンテナンスレベルを指定します：year.month.maintenance-release（たとえば、20.02.2はメジャーSlurmリリース20.02、メンテナンスバージョン2）。したがって、バージョン20.02.xは2020年2月に最初にリリースされました。RPC（リモートプロシージャコール）および状態ファイルの変更は、メジャーリリース番号が変更された場合にのみ行われます。最新の主要な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). Locally developed Slurm plugins may also require modification. 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). This means that upgrading at least once each year is recommended. 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.
SlurmのMPIライブラリは、メジャーリリース番号が変更された場合にも変更される可能性があり、アプリケーションの再リンクが必要になります（動作は、使用されるMPI実装とリリース間の特定のSlurm変更によって異なる場合があります）。ローカルで開発されたSlurmプラグインも変更が必要な場合があります。Slurmデーモンは、以前の2つのメジャーリリースのRPCと状態ファイルをサポートします（たとえば、バージョン20.02.xのSlurmDBDは、バージョン20.02.x、19.05.x、または18.08.xのslurmctldデーモンとコマンドをサポートします）。つまり、少なくとも毎年1回のアップグレードが推奨されます。それ以外の場合は、状態情報を保持するために中間アップグレードが必要になります。メンテナンスリリース番号の変更は通常、バグ修正のみを表していますが、マイナーな機能強化も含まれている場合があります。

If the SlurmDBD daemon is used, it must be at the same or higher major release number as the Slurmctld daemons. 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. 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デーモンを使用する場合は、Slurmctldデーモンと同じかそれ以上のメジャーリリース番号にする必要があります。言い換えると、バージョンをより高いリリース番号（19.05.xから20.02.xなど）に変更するときは、常に最初にSlurmDBDデーモンをアップグレードしてください。既存のテーブルに新しいフィールドを追加するなど、データベーステーブルの変更がアップグレードに必要になる場合があります。データベースに多数のエントリーが含まれている場合、SlurmDBDデーモンはデータベースを更新するために数十分かかる場合があり、この時間間隔中に応答しなくなります。

Before upgrading SlurmDBD it is strongly recommended to make a backup of the database. 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. To avoid locking the tables we recommend you use the --single-transaction flag with mysqldump. 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). The --single-transaction flag permits a live logical backup (and is thus useful for periodic backups while in production). 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. 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.
SlurmDBDをアップグレードする前に、データベースのバックアップを作成することを強くお勧めします。mysqldumpを使用する場合、デフォルトの動作はテーブルをロックすることであり、SlurmDBDが更新をデータベースに送信しようとすると問題が発生する可能性があります。テーブルのロックを回避するには、mysqldumpで--single-transactionフラグを使用することをお勧めします。これにより、アプリケーションをブロックすることなく、データベースの一貫した状態がダンプされます。このフラグが望ましい効果を持つためには、InnoDBストレージエンジンを使用している必要があることに注意してください（Slurmがテーブルを自動的に作成するときにデフォルトで指定されています）。--single-transactionフラグは、ライブの論理バックアップを許可します（したがって、運用中の定期的なバックアップに役立ちます）。Slurmをアップグレードすると、以下のいくつかの段落のアップグレードガイドに記載されているように、アップグレードを続行する前に、最初にSlurmDBDデーモンを停止し、次にmysqldumpを使用してデータベースをダンプすることをお勧めします。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. 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). Also see the note above about reverse compatibility.
slurmctldデーモンも、計算ノードのslurmdデーモンの前または同時にアップグレードする必要があります。通常、すべてのログインノードと計算ノードでSlurmをアップグレードすることをお勧めしますが、ローリングアップグレードも可能です（つまり、最初にヘッドノードをアップグレードしてから、後でさまざまなタイミングで計算ノードとログインノードをアップグレードします）。逆の互換性については、上記の注も参照してください。

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 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. 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. 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. 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). Developers will try to note these cases in the NEWS file. Contents of major releases are also described in the RELEASE_NOTES file.
Slurmのほとんどすべての新しいメジャーリリース（19.05.xから20.02.xなど）には、新しいデータ構造、新しいオプションなどを含む状態ファイルへの変更が含まれます。Slurmでは、過去2回のメジャーリリースからの新しいメジャーリリースへのアップグレードが可能です。 9か月ごと（たとえば、18.08.xまたは19.05.xから20.02.x）に、ジョブやその他の州の情報を失うことはありません。古いバージョンの状態情報は認識されずに破棄され、実行中および保留中のすべてのジョブが失われます。状態ファイルはダウングレード時に認識されず（たとえば、19.05.xから18.08.xへ）、破棄され、実行中および保留中のすべてのジョブが失われます。このため、状態ファイルのバックアップコピー（後述）を作成することは重要です。したがって、Slurm（より正確には、slurmctldデーモン）をアップグレードする場合、StateSaveLocation（slurmで定義）を保存します。conf）すべての状態情報を含むディレクトリの内容をお勧めします。ダウングレードする必要がある場合は、そのディレクトリの内容を復元すると、ジョブを回復できます。新しいバージョンで送信されたジョブはこれらの状態ファイルには含まれませんが、ほとんどのジョブを回復できます。これの例外は、新しいプレリリースバージョン（20.02.0-pre1から20.02.0-pre2など）をインストールするときにジョブが失われる可能性があることです。開発者は、NEWSファイルでこれらのケースに注意を払います。メジャーリリースの内容はRELEASE_NOTESファイルにも記述されています。これの例外は、新しいプレリリースバージョン（20.02.0-pre1から20.02.0-pre2など）をインストールするときにジョブが失われる可能性があることです。開発者は、NEWSファイルでこれらのケースに注意を払います。メジャーリリースの内容はRELEASE_NOTESファイルにも記述されています。これの例外は、新しいプレリリースバージョン（20.02.0-pre1から20.02.0-pre2など）をインストールするときにジョブが失われる可能性があることです。開発者は、NEWSファイルでこれらのケースに注意を払います。メジャーリリースの内容はRELEASE_NOTESファイルにも記述されています。

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

Be mindful of your configured SlurmdTimeout and SlurmctldTimeout values. 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. 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. The recommended upgrade order is as follows:
構成したSlurmdTimeoutおよびSlurmctldTimeout値に注意してください。Slurmデーモンがアップグレード中に指定されたタイムアウトよりも長い間ダウンしている場合、ノードがDOWNとマークされ、そのジョブが強制終了される場合があります。アップグレード中にタイムアウト値を増やすか、計算ノードのslurmdデーモンがSlurmdTimeoutより長くダウンしないようにすることができます。推奨されるアップグレードの順序は次のとおりです。

  1. Shutdown the slurmdbd daemon
    slurmdbdデーモンをシャットダウンします
  2. 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に増やします。
  3. Upgrade the slurmdbd daemon
    slurmdbdデーモンをアップグレードする
  4. Restart the slurmdbd daemon
    slurmdbdデーモンを再起動します
  5. Increase configured SlurmdTimeout and SlurmctldTimeout values and execute "scontrol reconfig" for them to take effect
    構成されたSlurmdTimeoutおよびSlurmctldTimeout値を増やし、それらを有効にするために「scontrol reconfig」を実行します
  6. Shutdown the slurmctld daemon(s)
    slurmctldデーモンをシャットダウンします
  7. Shutdown the slurmd daemons on the compute nodes
    計算ノードでslurmdデーモンをシャットダウンします
  8. Copy the contents of the configured StateSaveLocation directory (in case of any possible failure)
    構成されたStateSaveLocationディレクトリの内容をコピーします（エラーが発生した場合）
  9. Upgrade the slurmctld and slurmd daemons
    slurmctldおよびslurmdデーモンをアップグレードする
  10. Restart the slurmd daemons on the compute nodes
    計算ノードでslurmdデーモンを再起動します
  11. Restart the slurmctld daemon(s)
    slurmctldデーモンを再起動します
  12. Validate proper operation
    適切な操作を検証する
  13. Restore configured SlurmdTimeout and SlurmctldTimeout values and execute "scontrol reconfig" for them to take effect
    構成されたSlurmdTimeoutとSlurmctldTimeoutの値を復元し、「scontrol reconfig」を実行してそれらを有効にします。
  14. 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. It is common for plugins to add new functions and function arguments during major updates. See the RELEASE_NOTES file for details.
独自のバージョンのSlurmプラグインをビルドしている場合、新しいバージョンのSlurmをサポートするために変更が必要になる可能性があります。プラグインがメジャーアップデート中に新しい関数と関数引数を追加することはよくあります。詳細については、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. Installing from source allows the user to enable options such as mysql and gui tools via a configuration menu.
バイナリパッケージは、一般的な計算ノードに適した最小限のSlurm構成をインストールします。ソースからインストールすると、ユーザーは構成メニューからmysqlやguiツールなどのオプションを有効にできます。

Last modified 30 January 2020