Accounting and Resource Limits

Contents

Overview
Infrastructure
Slurm JobComp Configuration
Slurm Accounting Configuration Before Build
Slurm Accounting Configuration After Build
SlurmDBD Configuration
MySQL Configuration
Tools
Database Configuration
Cluster Options
Account Options
User Options
Limit Enforcement
Modifying Entities
Removing Entities

Overview

Slurm can be configured to collect accounting information for every job and job step executed. Accounting records can be written to a simple text file or a database. Information is available about both currently executing jobs and jobs which have already terminated. The sacct command can report resource usage for running or terminated jobs including individual tasks, which can be useful to detect load imbalance between the tasks. The sstat command can be used to status only currently running jobs. It also can give you valuable information about imbalance between tasks. The sreport can be used to generate reports based upon all jobs executed in a particular time interval.
Slurmは、実行されるすべてのジョブおよびジョブステップのアカウンティング情報を収集するように構成できます。会計記録は、単純なテキストファイルまたはデータベースに書き込むことができます。現在実行中のジョブとすでに終了したジョブの両方に関する情報が利用可能です。sacctコマンドは、個々のタスクを含む実行中または終了したジョブのリソース使用状況を報告できます。これは、タスク間の負荷の不均衡を検出するのに役立ちます。sstatコマンドを使用して、現在実行中のジョブのステータスのみを確認できます。また、タスク間の不均衡に関する貴重な情報も提供します。sreportを使用して、特定の時間間隔で実行されたすべてのジョブに基づいてレポートを生成できます。

There are three distinct plugin types associated with resource accounting. The Slurm configuration parameters (in slurm.conf) associated with these plugins include:
リソースアカウンティングに関連付けられている3つの異なるプラグインタイプがあります。これらのプラグインに関連する（slurm.conf内の）Slurm構成パラメーターには、次のものがあります。

  • AccountingStorageType controls how detailed job and job step information is recorded. You can store this information in a text file or into SlurmDBD.
    AccountingStorageTypeは、ジョブとジョブステップの詳細情報の記録方法を制御します。この情報は、テキストファイルまたはSlurmDBDに保存できます。
  • JobAcctGatherType is operating system dependent and controls what mechanism is used to collect accounting information. Supported values are jobacct_gather/linux (recommended), jobacct_gather/cgroup and jobacct_gather/none (no information collected).
    JobAcctGatherTypeはオペレーティングシステムに依存し、アカウンティング情報を収集するために使用されるメカニズムを制御します。サポートされる値は、jobacct_gather / linux（推奨）、jobacct_gather / cgroup、およびjobacct_gather / none（情報収集なし）です。
  • JobCompType controls how job completion information is recorded. This can be used to record basic job information such as job name, user name, allocated nodes, start time, completion time, exit status, etc. If the preservation of only basic job information is required, this plugin should satisfy your needs with minimal overhead. You can store this information in a text file, or MySQL or MariaDB database.
    JobCompTypeは、ジョブ完了情報の記録方法を制御します。これは、ジョブ名、ユーザー名、割り当てられたノード、開始時間、完了時間、終了ステータスなどの基本的なジョブ情報を記録するために使用できます。基本的なジョブ情報のみの保持が必要な場合、このプラグインは最小限でニーズを満たす必要がありますオーバーヘッド。この情報は、テキストファイル、またはMySQLまたはMariaDBデータベースに保存できます。

The use of sacct to view information about jobs is dependent upon AccountingStorageType being configured to collect and store that information. The use of sreport is dependent upon some database being used to store that information.
sacctを使用してジョブに関する情報を表示する方法は、その情報を収集して保存するように構成されているAccountingStorageTypeに依存しています。sreportの使用は、その情報を格納するために使用されているデータベースに依存しています。

The use of sacct or sstat to view information about resource usage within jobs is dependent upon both JobAcctGatherType and AccountingStorageType being configured to collect and store that information.
ジョブ内のリソース使用状況に関する情報を表示するためのsacctまたはsstatの使用は、その情報を収集して保存するように構成されているJobAcctGatherTypeとAccountingStorageTypeの両方に依存しています。

Storing the accounting information into text files is very simple. Just configure the appropriate plugin (e.g. AccountingStorageType=accounting_storage/filetxt and/or JobCompType=jobcomp/filetxt) and then specify the pathname of the file (e.g. AccountingStorageLoc=/var/log/slurm/accounting and/or JobCompLoc=/var/log/slurm/job_completions). Use the logrotate or similar tool to prevent the log files from getting too large. Send a SIGUSR2 signal to the slurmctld daemon after moving the files, but before compressing them so that new log files will be created.
アカウンティング情報をテキストファイルに保存するのは非常に簡単です。適切なプラグイン（例：AccountingStorageType = accounting_storage / filetxtおよび/またはJobCompType = jobcomp / filetxt）を構成し、ファイルのパス名（例：AccountingStorageLoc = / var / log / slurm / accountingおよび/またはJobCompLoc = / var / log）を指定するだけです。 / slurm / job_completions）。logrotateまたは類似のツールを使用して、ログファイルが大きくなりすぎないようにします。新しいログファイルが作成されるようにファイルを圧縮した後、ファイルを移動した後、slurmctldデーモンにSIGUSR2シグナルを送信します。

Storing the data directly into a database from Slurm may seem attractive, but it requires the availability of user name and password data not only for the Slurm control daemon (slurmctld), but also for user commands which need to access the data (sacct, sreport, and sacctmgr). Making potentially sensitive information available to all users makes database security more difficult to provide. Sending the data through an intermediate daemon can provide better security and performance (through caching data). SlurmDBD (Slurm Database Daemon) provides such services. SlurmDBD is written in C, multi-threaded, secure and fast. The configuration required to use SlurmDBD will be described below. Storing information directly into a database would be similar.
Slurmからデータベースに直接データを保存することは魅力的なように見えるかもしれませんが、Slurm制御デーモン（slurmctld）だけでなく、データにアクセスする必要があるユーザーコマンド（sacct、sreport）のユーザー名とパスワードデータの可用性も必要です、およびsacctmgr）。機密性の高い情報をすべてのユーザーが利用できるようにすると、データベースのセキュリティを提供することがより困難になります。中間デーモンを介してデータを送信すると、（データをキャッシュすることによって）より良いセキュリティとパフォーマンスを提供できます。SlurmDBD（Slurm Database Daemon）はそのようなサービスを提供します。SlurmDBDはCで書かれており、マルチスレッドで安全かつ高速です。SlurmDBDを使用するために必要な設定を以下に説明します。情報をデータベースに直接格納する場合も同様です。

Note that SlurmDBD relies upon existing Slurm plugins for authentication and Slurm sql for database use, but the other Slurm commands and daemons are not required on the host where SlurmDBD is installed. Install the slurm and slurm-slurmdbd RPMs on the server where SlurmDBD is to run.
SlurmDBDは認証のために既存のSlurmプラグインとデータベースの使用のためにSlurm sqlに依存していますが、他のSlurmコマンドとデーモンはSlurmDBDがインストールされているホストでは必要ありません。SlurmDBDを実行するサーバーにslurmおよびslurm-slurmdbd RPMをインストールします。

Note if you switch from using the MySQL plugin to use the SlurmDBD plugin you must make sure the cluster has been added to the database. The MySQL plugin doesn't require this, but also will not hurt things if you have it there when using the MySQL plugin. You can verify with
MySQLプラグインの使用からSlurmDBDプラグインの使用に切り替える場合は、クラスターがデータベースに追加されていることを確認する必要があります。MySQLプラグインはこれを必要としませんが、MySQLプラグインを使用している場合、MySQLプラグインがあれば問題はありません。あなたはで確認することができます
 

sacctmgr list cluster
If the cluster isn't there add it (where my cluster's name was snowflake):
クラスターがない場合は追加します（私のクラスターの名前はスノーフレークでした）。
 
sacctmgr add cluster snowflake
Failure to do so will result in the slurmctld failing to talk to the slurmdbd after the switch. If you plan to upgrade to a new version of Slurm don't switch plugins at the same time or you may get unexpected results. Do one then the other.
そうしないと、slurmctldが切り替え後にslurmdbdと通信できなくなります。Slurmの新しいバージョンへのアップグレードを計画している場合は、同時にプラグインを切り替えないでください。予期しない結果が生じる可能性があります。次に、一方を実行します。

If SlurmDBD is configured for use but not responding then slurmctld will utilize an internal cache until SlurmDBD is returned to service. The cached data is written by slurmctld to local storage upon shutdown and recovered at startup. If SlurmDBD is not available when slurmctld starts, a cache of valid bank accounts, user limits, etc. based upon their state when the daemons were last communicating will be used. Note that SlurmDBD must be responding when slurmctld is first started since no cache of this critical data will be available. Job and step accounting records generated by slurmctld will be written to a cache as needed and transferred to SlurmDBD when returned to service. Note that if SlurmDBD is down long enough for the number of queued records to exceed the maximum queue size then messages will begin to be dropped.
SlurmDBDが使用するように構成されているが応答しない場合、slurmctldはSlurmDBDがサービスに戻るまで内部キャッシュを利用します。キャッシュされたデータは、シャットダウン時にslurmctldによってローカルストレージに書き込まれ、起動時に回復されます。slurmctldの起動時にSlurmDBDが使用できない場合、デーモンが最後に通信していたときの状態に基づいて、有効な銀行口座、ユーザー制限などのキャッシュが使用されます。この重要なデータのキャッシュが利用できないため、slurmctldが最初に起動されたとき、SlurmDBDが応答している必要があります。slurmctldによって生成されたジョブおよびステップのアカウンティングレコードは、必要に応じてキャッシュに書き込まれ、サービスに戻るときにSlurmDBDに転送されます。キューに入れられたレコードの数が最大キューサイズを超えるのに十分な長さでSlurmDBDがダウンしている場合、メッセージのドロップが開始されることに注意してください。

Infrastructure

With the SlurmDBD, we are able to collect data from multiple clusters in a single location. This does impose some constraints on the user naming and IDs. Accounting is maintained by user name (not user ID), but a given user name should refer to the same person across all of the computers. Authentication relies upon user ID numbers, so those must be uniform across all computers communicating with each SlurmDBD, at least for users requiring authentication. In particular, the configured SlurmUser must have the same name and ID across all clusters. If you plan to have administrators of user accounts, limits, etc. they must also have consistent names and IDs across all clusters. If you plan to restrict access to accounting records (e.g. only permit a user to view records of his jobs), then all users should have consistent names and IDs.
SlurmDBDを使用すると、単一の場所で複数のクラスターからデータを収集できます。これは、ユーザーの名前とIDにいくつかの制約を課します。アカウンティングはユーザー名（ユーザーIDではなく）によって維持されますが、特定のユーザー名はすべてのコンピューターで同じ人を参照する必要があります。認証はユーザーID番号に依存しているため、少なくとも認証を必要とするユーザーに対しては、各SlurmDBDと通信するすべてのコンピューター間で統一されている必要があります。特に、構成されたSlurmUserは、すべてのクラスターで同じ名前とIDを持つ必要があります。ユーザーアカウントや制限などの管理者を計画している場合は、すべてのクラスターで一貫した名前とIDも必要です。アカウンティングレコードへのアクセスを制限する（たとえば、ユーザーに自分のジョブのレコードを表示することのみを許可する）場合は、すべてのユーザーが一貫した名前とIDを持っている必要があります。

NOTE: Only lowercase usernames are supported.
注：小文字のユーザー名のみがサポートされています。

The best way to ensure security of the data is by authenticating communications to the SlurmDBD and we recommend MUNGE for that purpose. If you have one cluster managed by Slurm and execute the SlurmDBD on that one cluster, the normal MUNGE configuration will suffice. Otherwise MUNGE should then be installed on all nodes of all Slurm managed clusters, plus the machine where SlurmDBD executes. You then have a choice of either having a single MUNGE key for all of these computers or maintaining a unique key for each of the clusters plus a second key for communications between the clusters for better security. MUNGE enhancements are planned to support two keys within a single configuration file, but presently two different daemons must be started with different configurations to support two different keys (create two key files and start the daemons with the --key-file option to locate the proper key plus the --socket option to specify distinct local domain sockets for each). The pathname of local domain socket will be needed in the Slurm and SlurmDBD configuration files (slurm.conf and slurmdbd.conf respectively, more details are provided below).
データのセキュリティを確保する最良の方法は、SlurmDBDへの通信を認証することです。そのためにMUNGEをお勧めします。Slurmによって管理されている1つのクラスターがあり、その1つのクラスターでSlurmDBDを実行する場合、通常のMUNGE構成で十分です。それ以外の場合は、MUNGEをすべてのSlurm管理クラスターのすべてのノードと、SlurmDBDが実行されるマシンにインストールする必要があります。次に、これらすべてのコンピューターに単一のMUNGEキーを使用するか、各クラスターに一意のキーとクラスター間の通信用に2つ目のキーを維持してセキュリティを向上させるかを選択できます。MUNGEの機能拡張では、単一の構成ファイル内で2つのキーをサポートする予定です。ただし、2つの異なるキーをサポートするには、現在2つの異なるデーモンを異なる構成で起動する必要があります（2つのキーファイルを作成し、--key-fileオプションでデーモンを起動して適切なキーを見つけ、さらに--socketオプションで個別のローカルドメインソケットを指定します。それぞれ）。ローカルドメインソケットのパス名は、SlurmおよびSlurmDBD構成ファイルで必要です（それぞれ、slurm.confおよびslurmdbd.conf。詳細は以下に記載されています）。

Whether you use any authentication module or not you will need to have a way for the SlurmDBD to get UID's for users and/or admins. If using MUNGE, it is ideal for your users to have the same id on all your clusters. If this is the case you should have a combination of every cluster's /etc/passwd file on the database server to allow the DBD to resolve names for authentication. If using MUNGE and a user's name is not in the passwd file the action will fail. If not using MUNGE, you should add anyone you want to be an administrator or operator to the passwd file. If they plan on running sacctmgr or any of the accounting tools they should have the same UID, or they will not authenticate correctly. An LDAP server could also serve as a way to gather this information.
認証モジュールを使用するかどうかにかかわらず、SlurmDBDがユーザーや管理者のUIDを取得する方法が必要になります。MUNGEを使用する場合、ユーザーがすべてのクラスターで同じIDを持つことが理想的です。これが当てはまる場合は、DBDが認証のために名前を解決できるように、データベースサーバー上のすべてのクラスターの/ etc / passwdファイルの組み合わせが必要です。MUNGEを使用していて、ユーザーの名前がpasswdファイルにない場合、アクションは失敗します。MUNGEを使用しない場合は、管理者またはオペレーターになりたいユーザーをpasswdファイルに追加する必要があります。sacctmgrまたはアカウンティングツールのいずれかを実行する予定の場合は、同じUIDを使用する必要があります。そうしないと、正しく認証されません。LDAPサーバーは、この情報を収集する手段としても機能します。

Slurm JobComp Configuration

Presently job completion is not supported with the SlurmDBD, but can be written directly to a database, script or flat file. If you are running with the accounting storage plugin, use of the job completion plugin is probably redundant. If you would like to configure this, some of the more important parameters include:
現在、ジョブ完了はSlurmDBDではサポートされていませんが、データベース、スクリプト、またはフラットファイルに直接書き込むことができます。アカウンティングストレージプラグインで実行している場合、ジョブ完了プラグインの使用はおそらく冗長です。これを設定する場合、より重要なパラメータのいくつかは次のとおりです。

  • JobCompHost: Only needed if using a database. The name or address of the host where the database server executes.
    JobCompHost：データベースを使用する場合にのみ必要です。データベースサーバーが実行されるホストの名前またはアドレス。
  • JobCompLoc: Only needed if using a flat file. Location of file to write the job completion data to.
    JobCompLoc：フラットファイルを使用する場合にのみ必要です。ジョブ完了データを書き込むファイルの場所。
  • JobCompPass: Only needed if using a database. Password for the user connecting to the database. Since the password can not be securely maintained, storing the information directly in a database is not recommended.
    JobCompPass：データベースを使用する場合にのみ必要です。データベースに接続するユーザーのパスワード。パスワードを安全に維持できないため、データベースに情報を直接保存することはお勧めしません。
  • JobCompPort: Only needed if using a database. The network port that the database accepts communication on.
    JobCompPort：データベースを使用する場合にのみ必要です。データベースが通信を受け入れるネットワークポート。
  • JobCompType: Type of jobcomp plugin set to "jobcomp/mysql" or "jobcomp/filetxt".
    JobCompType：「jobcomp / mysql」または「jobcomp / filetxt」に設定されたjobcompプラグインのタイプ。
  • JobCompUser: Only needed if using a database. User name to connect to the database with.
    JobCompUser：データベースを使用する場合にのみ必要です。データベースへの接続に使用するユーザー名。
  • JobCompParams: Pass arbitrary text string to job completion plugin.
    JobCompParams：任意のテキスト文字列をジョブ完了プラグインに渡します。

Slurm Accounting Configuration Before Build


ビルド前のSlurmアカウンティング構成

While the SlurmDBD will work with a flat text file for recording job completions and similar data, this configuration will not allow for "associations" between a user and account. A database allows such a configuration.
SlurmDBDは、ジョブの完了や同様のデータを記録するためにフラットテキストファイルで動作しますが、この構成では、ユーザーとアカウント間の「関連付け」は許可されません。データベースはそのような構成を可能にします。

MySQL or MariaDB is the preferred database. To enable this database support one only needs to have the development package for the database they wish to use on the system. Slurm uses the InnoDB storage engine in MySQL to make rollback possible. This must be available on your MySQL installation or rollback will not work.
MySQLまたはMariaDBが推奨されるデータベースです。このデータベースのサポートを有効にするには、システムで使用するデータベースの開発パッケージが必要です。SlurmはMySQLのInnoDBストレージエンジンを使用してロールバックを可能にします。これは、MySQLインストールで使用可能でなければなりません。そうでないと、ロールバックは機能しません。

The slurm configure script uses mysql_config to find out the information it needs about installed libraries and headers. You can specify where your mysql_config script is with the --with-mysql_conf=/path/to/mysql_config option when configuring your slurm build. On a successful configure, output is something like this:
slurm configureスクリプトはmysql_configを使用して、インストールされているライブラリとヘッダーに関して必要な情報を見つけます。slurmビルドを設定するときに、mysql_configスクリプトの場所を--with-mysql_conf = / path / to / mysql_configオプションで指定できます。構成が成功すると、出力は次のようになります。

checking for mysql_config... /usr/bin/mysql_config
MySQL test program built properly.

NOTE: Before running the slurmdbd for the first time, review the current setting for MySQL's innodb_buffer_pool_size. Consider setting this value large enough to handle the size of the database. This helps when converting large tables over to the new database schema and when purging old records. Setting innodb_lock_wait_timeout and innodb_log_file_size to larger values than the default is also recommended.
注：slurmdbdを初めて実行する前に、MySQLのinnodb_buffer_pool_sizeの現在の設定を確認してください。この値を、データベースのサイズを処理するのに十分な大きさに設定することを検討してください。これは、大きなテーブルを新しいデータベーススキーマに変換するときや、古いレコードを削除するときに役立ちます。innodb_lock_wait_timeoutおよびinnodb_log_file_sizeをデフォルトよりも大きい値に設定することもお勧めします。

See the following example: 

mysql> SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)

$cat my.cnf
...
[mysqld]
innodb_buffer_pool_size=1024M
innodb_log_file_size=64M
innodb_lock_wait_timeout=900
...

Also, in MySQL versions prior to 5.7 the default row format was set to COMPACT which could cause some issues during an upgrade when creating tables. In more recent versions it was changed to DYNAMIC. The row format of a table determines how its rows are physically stored in pages and directly affects the performane of queries and DML operations. In very specific situations using a format other than DYNAMIC can lead to rows not fitting into pages and MySQL can throw an error during the creation of the table because of that. Therefore it is recommended to read carefully about the row format before creating your database tables if you are not using DYNAMIC by default, and consider setting that if your database version supports it. If the following InnoDB error shows up during an upgrade, the table can then be altered (may take some time) to set the row format to DYNAMIC in order to allow the conversion to proceed:
また、5.7より前のMySQLバージョンでは、デフォルトの行形式がCOMPACTに設定されていたため、テーブルの作成時のアップグレード中に問題が発生する可能性がありました。最近のバージョンでは、動的に変更されました。テーブルの行形式は、その行がページに物理的に格納される方法を決定し、クエリとDML操作のパフォーマンスに直接影響します。非常に特殊な状況では、DYNAMIC以外のフォーマットを使用すると、行がページに収まらなくなり、MySQLがそのためにテーブルの作成中にエラーをスローする可能性があります。したがって、デフォルトでDYNAMICを使用していない場合は、データベーステーブルを作成する前に行フォーマットについて注意深く読み、データベースのバージョンでサポートされている場合はその設定を検討することをお勧めします。アップグレード中に次のInnoDBエラーが表示された場合、
 

[Warning] InnoDB: Cannot add field ... in table ... because after adding it, the row size is Y which is greater than maximum allowed size (X) for a record on index leaf page.
You can check your default row format value by showing the innodb_default_row_format variable, and how the tables are created by running:
innodb_default_row_format変数と、次のコマンドを実行してテーブルを作成する方法を示すことにより、デフォルトの行フォーマット値を確認できます。
 
mysql> SHOW TABLE STATUS IN table_name;

Slurm Accounting Configuration After Build


ビルド後のSlurmアカウンティング構成

For simplicity's sake, we are going to proceed under the assumption that you are running with the SlurmDBD. You can communicate with a storage plugin directly, but that offers minimal security.
簡単にするために、SlurmDBDを使用して実行しているという前提で進めます。ストレージプラグインと直接通信できますが、セキュリティは最小限です。

Several Slurm configuration parameters must be set to support archiving information in SlurmDBD. SlurmDBD has a separate configuration file which is documented in a separate section. Note that you can write accounting information to SlurmDBD while job completion records are written to a text file or not maintained at all. If you don't set the configuration parameters that begin with "AccountingStorage" then accounting information will not be referenced or recorded.
SlurmDBDのアーカイブ情報をサポートするには、いくつかのSlurm構成パラメーターを設定する必要があります。SlurmDBDには、別のセクションに記載されている別の構成ファイルがあります。ジョブ完了レコードがテキストファイルに書き込まれるか、まったく維持されないときに、SlurmDBDにアカウンティング情報を書き込むことができることに注意してください。「AccountingStorage」で始まる構成パラメーターを設定しない場合、アカウンティング情報は参照または記録されません。

  • AccountingStorageEnforce: This option contains a comma separated list of options you may want to enforce. The valid options are any comma separated combination of

      AccountingStorageEnforce：このオプションには、強制したいオプションのコンマ区切りのリストが含まれています。有効なオプションは、コンマ区切りの任意の組み合わせです。
    • associations - This will prevent users from running jobs if their association is not in the database. This option will prevent users from accessing invalid accounts.
      関連付け-これにより、ユーザーの関連付けがデータベースにない場合、ユーザーはジョブを実行できなくなります。このオプションは、ユーザーが無効なアカウントにアクセスするのを防ぎます。
    • limits - This will enforce limits set on associations and qos'. By setting this option, the 'associations' option is automatically set. If a qos is used the limits will be enforced, but 'qos' described below is still needed if you want to enforce access to the qos.
      制限-これにより、関連付けとQoSに設定された制限が適用されます。このオプションを設定すると、「関連付け」オプションが自動的に設定されます。QoSが使用されている場合、制限が適用されますが、QOSへのアクセスを適用する場合は、以下で説明する「QOS」が引き続き必要です。
    • nojobs - This will make it so no job information is stored in accounting. By setting this 'nosteps' is also set.
      nojobs-これにより、アカウンティングにジョブ情報は保存されません。これを設定することにより、「nosteps」も設定されます。
    • nosteps - This will make it so no step information is stored in accounting. Both nojobs and nosteps could be helpful in an environment where you want to use limits but don't really care about utilization.
      nosteps-これにより、ステップ情報はアカウンティングに保管されません。nojobsとnostepsはどちらも、制限を使用したいが実際には使用率を気にしない環境で役立ちます。
    • qos - This will require all jobs to specify (either overtly or by default) a valid qos (Quality of Service). QOS values are defined for each association in the database. By setting this option, the 'associations' option is automatically set. If you want QOS limits to be enforced you need to use the 'limits' option.
      qos-これにより、すべてのジョブが有効なqos（サービス品質）を（明白にまたはデフォルトで）指定する必要があります。QOS値は、データベース内の関連付けごとに定義されます。このオプションを設定すると、「関連付け」オプションが自動的に設定されます。QOS制限を強制したい場合は、 'limits'オプションを使用する必要があります。
    • safe - This will ensure a job will only be launched when using an association or qos that has a GrpTRESMins limit set if the job will be able to run to completion. Without this option set, jobs will be launched as long as their usage hasn't reached the TRES-minutes limit which can lead to jobs being launched but then killed when the limit is reached. By setting this option, both the 'associations' option and the 'limits' option are set automatically.
      安全-これにより、GrpTRESMins制限が設定された関連付けまたはQoSを使用している場合にのみ、ジョブを実行してジョブを完了させることができます。このオプションが設定されていない場合、使用量がTRES分の制限に達していない限りジョブが起動され、ジョブが起動される可能性がありますが、制限に達すると強制終了されます。このオプションを設定すると、「関連付け」オプションと「制限」オプションの両方が自動的に設定されます。
    • wckeys - This will prevent users from running jobs under a wckey that they don't have access to. By using this option, the 'associations' option is automatically set. The 'TrackWCKey' option is also set to true.
      wckeys-これにより、ユーザーはアクセス権のないwckeyでジョブを実行できなくなります。このオプションを使用すると、「関連付け」オプションが自動的に設定されます。'TrackWCKey'オプションもtrueに設定されています。
    (NOTE: The association is a combination of cluster, account, user names and optional partition name.)
    （注：関連付けは、クラスター、アカウント、ユーザー名、およびオプションのパーティション名の組み合わせです。）
    Without AccountingStorageEnforce being set (the default behavior) jobs will be executed based upon policies configured in Slurm on each cluster.
    AccountingStorageEnforceが設定されていない場合（デフォルトの動作）、各クラスターのSlurmで構成されたポリシーに基づいてジョブが実行されます。
  • AccountingStorageExternalHost: A comma separated list of external slurmdbds (<host/ip>[:port][,...]) to register with. If no port is given, the AccountingStoragePort will be used. This allows clusters registered with the external slurmdbd to communicate with each other using the --cluster/-M client command options. The cluster will add itself to the external slurmdbd if it doesn't exist. If a non-external cluster already exists on the external slurmdbd, the slurmctld will ignore registering to the external slurmdbd.
    AccountingStorageExternalHost：外部slurmdbdsのコンマ区切りリスト（[：port] [、...]）に登録します。ポートを指定しない場合、AccountingStoragePortが使用されます。これにより、外部のslurmdbdに登録されたクラスターは、-cluster / -Mクライアントコマンドオプションを使用して相互に通信できます。クラスターが存在しない場合、クラスターはそれを外部slurmdbdに追加します。非外部クラスターが外部slurmdbdにすでに存在する場合、slurmctldは外部slurmdbdへの登録を無視します。
  • AccountingStorageHost: The name or address of the host where SlurmDBD executes
    AccountingStorageHost：SlurmDBDが実行されるホストの名前またはアドレス
  • AccountingStoragePass: If using SlurmDBD with a second MUNGE daemon, store the pathname of the named socket used by MUNGE to provide enterprise-wide authentication (i.e. /var/run/munge/moab.socket.2). Otherwise the default MUNGE daemon will be used.
    AccountingStoragePass：2番目のMUNGEデーモンでSlurmDBDを使用する場合は、MUNGEが使用する名前付きソケットのパス名を格納して、企業全体の認証を提供します（/var/run/munge/moab.socket.2）。それ以外の場合は、デフォルトのMUNGEデーモンが使用されます。
  • AccountingStoragePort: The network port that SlurmDBD accepts communication on.
    AccountingStoragePort：SlurmDBDが通信を受け入れるネットワークポート。
  • AccountingStorageType: Set to "accounting_storage/slurmdbd".
    AccountingStorageType：「accounting_storage / slurmdbd」に設定します。
  • ClusterName: Set to a unique name for each Slurm-managed cluster so that accounting records from each can be identified.
    ClusterName：各Slurm管理のクラスターに一意の名前を設定して、それぞれからのアカウンティングレコードを識別できるようにします。
  • TrackWCKey: Boolean. If you want to track wckeys (Workload Characterization Key) of users. A Wckey is an orthogonal way to do accounting against possibly unrelated accounts. When a job is run, use the --wckey option to specify a value and accounting records will be collected by this wckey.
    TrackWCKey：ブール値。ユーザーのwckeys（Workload Characterization Key）を追跡する場合。Wckeyは、関係のない可能性のあるアカウントに対してアカウンティングを実行するための直交する方法です。ジョブを実行するときは、-wckeyオプションを使用して値を指定すると、このwckeyによってアカウンティングレコードが収集されます。

SlurmDBD Configuration

SlurmDBD requires its own configuration file called "slurmdbd.conf". This file should be only on the computer where SlurmDBD executes and should only be readable by the user which executes SlurmDBD (e.g. "slurm"). This file should be protected from unauthorized access since it contains a database login name and password. See "man slurmdbd.conf" for a more complete description of the configuration parameters. Some of the more important parameters include:
SlurmDBDには、「slurmdbd.conf」と呼ばれる独自の構成ファイルが必要です。このファイルは、SlurmDBDが実行されるコンピューター上にのみ存在し、SlurmDBDを実行するユーザー（たとえば、「slurm」）からのみ読み取り可能である必要があります。このファイルにはデータベースのログイン名とパスワードが含まれているため、不正なアクセスから保護する必要があります。構成パラメーターの詳細については、「man slurmdbd.conf」を参照してください。より重要なパラメータのいくつかは次のとおりです。

  • AuthInfo: If using SlurmDBD with a second MUNGE daemon, store the pathname of the named socket used by MUNGE to provide enterprise-wide. Otherwise the default MUNGE daemon will be used.
    AuthInfo：SlurmDBDを2番目のMUNGEデーモンと共に使用する場合、MUNGEが使用する名前付きソケットのパス名を格納して、企業全体に提供します。それ以外の場合は、デフォルトのMUNGEデーモンが使用されます。
  • AuthType: Define the authentication method for communications between Slurm components. A value of "auth/munge" is recommended.
    AuthType：Slurmコンポーネント間の通信の認証方法を定義します。「auth / munge」の値をお勧めします。
  • DbdHost: The name of the machine where the Slurm Database Daemon is executed. This should be a node name without the full domain name (e.g. "lx0001"). This defaults to localhost but should be supplied to avoid a warning message.
    DbdHost：Slurm Database Daemonが実行されるマシンの名前。これは完全なドメイン名のないノード名でなければなりません（例えば "lx0001"）。デフォルトはlocalhostですが、警告メッセージを回避するために指定する必要があります。
  • DbdPort: The port number that the Slurm Database Daemon (slurmdbd) listens to for work. The default value is SLURMDBD_PORT as established at system build time. If none is explicitly specified, it will be set to 6819. This value must be equal to the AccountingStoragePort parameter in the slurm.conf file.
    DbdPort：Slurmデータベースデーモン（slurmdbd）が作業のためにリッスンするポート番号。デフォルト値は、システムのビルド時に確立されるSLURMDBD_PORTです。明示的に指定されていない場合は、6819に設定されます。この値は、slurm.confファイルのAccountingStoragePortパラメータと等しい必要があります。
  • LogFile: Fully qualified pathname of a file into which the Slurm Database Daemon's logs are written. The default value is none (performs logging via syslog).
    LogFile：Slurm Database Daemonのログが書き込まれるファイルの完全修飾パス名。デフォルト値はnoneです（syslogを介してロギングを実行します）。
  • PluginDir: Identifies the places in which to look for Slurm plugins. This is a colon-separated list of directories, like the PATH environment variable. The default value is the prefix given at configure time + "/lib/slurm".
    PluginDir：Slurmプラグインを探す場所を識別します。これは、PATH環境変数のように、コロンで区切られたディレクトリのリストです。デフォルト値は、構成時に指定されたプレフィックス+ "/ lib / slurm"です。
  • SlurmUser: The name of the user that the slurmdbd daemon executes as. This user must exist on the machine executing the Slurm Database Daemon and have the same UID as the hosts on which slurmctld execute. For security purposes, a user other than "root" is recommended. The default value is "root". This name should also be the same SlurmUser on all clusters reporting to the SlurmDBD. NOTE: If this user is different from the one set for slurmctld and is not root, it must be added to accounting with AdminLevel=Admin and slurmctld must be restarted.
    SlurmUser：slurmdbdデーモンが実行するユーザーの名前。このユーザーは、Slurm Database Daemonを実行するマシンに存在し、slurmctldが実行されるホストと同じUIDを持っている必要があります。セキュリティ上の理由から、「root」以外のユーザーをお勧めします。デフォルト値は「root」です。この名前は、SlurmDBDにレポートするすべてのクラスターで同じSlurmUserにする必要もあります。注：このユーザーがslurmctldに設定されているユーザーとは異なり、rootでない場合は、AdminLevel = Adminでアカウンティングに追加し、slurmctldを再起動する必要があります。
  • StorageHost: Define the name of the host the database is running where we are going to store the data. Ideally this should be the host on which SlurmDBD executes, but could be a different machine.
    StorageHost：データを保存するデータベースが実行されているホストの名前を定義します。理想的には、これはSlurmDBDが実行されるホストである必要がありますが、別のマシンである可能性もあります。
  • StorageLoc: Specifies the name of the database where accounting records are written. For databases the default database is slurm_acct_db. Note the name can not have a '/' in it or the default will be used.
    StorageLoc：アカウンティングレコードが書き込まれるデータベースの名前を指定します。データベースの場合、デフォルトのデータベースはslurm_acct_dbです。名前に「/」を含めることはできません。そうすると、デフォルトが使用されます。
  • StoragePass: Define the password used to gain access to the database to store the job accounting data.
    StoragePass：データベースにアクセスしてジョブアカウンティングデータを保存するために使用するパスワードを定義します。
  • StoragePort: Define the port on which the database is listening.
    StoragePort：データベースがリスニングするポートを定義します。
  • StorageType: Define the accounting storage mechanism. The only acceptable value at present is "accounting_storage/mysql". The value "accounting_storage/mysql" indicates that accounting records should be written to a MySQL or MariaDB database specified by the StorageLoc parameter. This value must be specified.
    StorageType：アカウンティングストレージメカニズムを定義します。現在唯一の許容値は「accounting_storage / mysql」です。値「accounting_storage / mysql」は、アカウンティングレコードをStorageLocパラメータで指定されたMySQLまたはMariaDBデータベースに書き込む必要があることを示します。この値を指定する必要があります。
  • StorageUser: Define the name of the user we are going to connect to the database with to store the job accounting data.
    StorageUser：ジョブアカウンティングデータを保存するためにデータベースに接続するユーザーの名前を定義します。

MySQL Configuration

While Slurm will create the database tables automatically you will need to make sure the StorageUser is given permissions in the MySQL or MariaDB database to do so. As the mysql user grant privileges to that user using a command such as:
Slurmはデータベーステーブルを自動的に作成しますが、それを行うには、MySQLまたはMariaDBデータベースでStorageUserに権限が付与されていることを確認する必要があります。mysqlユーザーが次のようなコマンドを使用して、そのユーザーに特権を付与します。

GRANT ALL ON StorageLoc.* TO 'StorageUser'@'StorageHost';
(The ticks are needed)
StorageLoc。*をGRANT ALL TO TO StorageUser '@' StorageHost ';（ティックが必要です）

(You need to be root to do this. Also in the info for password usage there is a line that starts with '->'. This a continuation prompt since the previous mysql statement did not end with a ';'. It assumes that you wish to input more info.)
（これを行うにはrootである必要があります。パスワードの使用に関する情報にも「->」で始まる行があります。前のmysqlステートメントが「;」で終わっていなかったため、これは継続プロンプトです。これは、詳細を入力してください。）

If you want Slurm to create the database itself, and any future databases, you can change your grant line to be *.* instead of StorageLoc.*
Slurmでデータベース自体と将来のデータベースを作成する場合は、許可行をStorageLoc。*ではなく*。*に変更できます。

Live example:

mysql@snowflake:~$ mysql
Welcome to the MySQL monitor.Commands end with ; or \g.
Your MySQL connection id is 538
Server version: 5.0.51a-3ubuntu5.1 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> create user 'slurm'@'localhost' identified by 'password';
Query OK, 0 rows affected (0.00 sec)

mysql> grant all on slurm_acct_db.* TO 'slurm'@'localhost';
Query OK, 0 rows affected (0.00 sec)

You may also need to do the same with the system name in order for mysql to work correctly:
mysqlが正しく機能するためには、システム名でも同じことが必要になる場合があります。

mysql> grant all on slurm_acct_db.* TO 'slurm'@'system0';
Query OK, 0 rows affected (0.00 sec)
where 'system0' is the localhost or database storage host.

or with a password...

mysql> grant all on slurm_acct_db.* TO 'slurm'@'localhost'
    -> identified by 'some_pass' with grant option;
Query OK, 0 rows affected (0.00 sec)

The same is true in the case, you made to do the same with the system name:

mysql> grant all on slurm_acct_db.* TO 'slurm'@'system0'
    -> identified by 'some_pass' with grant option;
where 'system0' is the localhost or database storage host.

Verify you have InnoDB support

mysql> SHOW ENGINES;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| ...                |         |                                                                |              |      |            |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| ...                |         |                                                                |              |      |            |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+

Then create the database:

mysql> create database slurm_acct_db;

This will grant user 'slurm' access to do what it needs to do on the local host or the storage host system. This must be done before the SlurmDBD will work properly. After you grant permission to the user 'slurm' in mysql then you can start SlurmDBD and the other Slurm daemons. You start SlurmDBD by typing its pathname '/usr/sbin/slurmdbd' or '/etc/init.d/slurmdbd start'. You can verify that SlurmDBD is running by typing 'ps aux | grep slurmdbd'.
これにより、ローカルホストまたはストレージホストシステムで実行する必要があることを実行するための「スラム」アクセスがユーザーに許可されます。これは、SlurmDBDが正しく機能する前に実行する必要があります。mysqlでユーザー「slurm」に権限を付与した後、SlurmDBDと他のSlurmデーモンを起動できます。パス名「/ usr / sbin / slurmdbd」または「/etc/init.d/slurmdbd start」を入力して、SlurmDBDを起動します。「ps aux |」と入力すると、SlurmDBDが実行されていることを確認できます。grep slurmdbd '。

If the SlurmDBD is not running you can use the -v option when you start SlurmDBD to get more detailed information. Starting the SlurmDBD in daemon mode with the '-D' option can also help in debugging so you don't have to go to the log to find the problem.
SlurmDBDが実行されていない場合は、SlurmDBDの起動時に-vオプションを使用して、より詳細な情報を取得できます。「-D」オプションを使用してSlurmDBDをデーモンモードで開始すると、デバッグに役立つため、問題を見つけるためにログに移動する必要がありません。

Tools

There are a few tools available to work with accounting data, sacct, sacctmgr, and sreport. These tools all get or set data through the SlurmDBD daemon.
アカウンティングデータ、sacct、sacctmgr、およびsreportを操作するために使用できるいくつかのツールがあります。これらのツールはすべて、SlurmDBDデーモンを通じてデータを取得または設定します。

  • sacct is used to generate accounting report for both running and completed jobs.
    sacctは、実行中のジョブと完了したジョブの両方のアカウンティングレポートを生成するために使用されます。
  • sacctmgr is used to manage associations in the database: add or remove clusters, add or remove users, etc.
    sacctmgrは、データベースの関連付けを管理するために使用されます：クラスターの追加または削除、ユーザーの追加または削除など。
  • sreport is used to generate various reports on usage collected over a given time period.
    sreportは、特定の期間に収集された使用状況に関するさまざまなレポートを生成するために使用されます。

See the man pages for each command for more information.
詳細については、各コマンドのマニュアルページを参照してください。

Database Configuration

Accounting records are maintained based upon what we refer to as an Association, which consists of four elements: cluster, account, user names and an optional partition name. Use the sacctmgr command to create and manage these records.
アカウンティングレコードは、関連付けと呼ばれるものに基づいて維持されます。関連付けは、クラスター、アカウント、ユーザー名、およびオプションのパーティション名の4つの要素で構成されます。これらのレコードを作成および管理するには、sacctmgrコマンドを使用します。

NOTE: There is an order to set up accounting associations. You must define clusters before you add accounts and you must add accounts before you can add users.
注：アカウンティングアソシエーションを設定するための順序があります。アカウントを追加する前にクラスターを定義し、ユーザーを追加する前にアカウントを追加する必要があります。

For example, to add a cluster named "snowflake" to the database execute this line (NOTE: as of 20.02, slurmctld will add the cluster to the database upon start if it doesn't exist. Associations still need to be created after addition):
たとえば、「snowflake」という名前のクラスターをデータベースに追加するには、次の行を実行します（注：20.02以降、slurmctldは、存在しない場合、起動時にクラスターをデータベースに追加します。追加後に関連付けを作成する必要があります） ：

sacctmgr add cluster snowflake

Add accounts "none" and "test" to cluster "snowflake" with an execute line of this sort:
次のような実行行を使用して、クラスター「snowflake」にアカウント「none」と「test」を追加します。

sacctmgr add account none,test Cluster=snowflake \
  Description="none" Organization="none"

If you have more clusters you want to add these accounts, to you can either not specify a cluster, which will add the accounts to all clusters in the system, or comma separate the cluster names you want to add to in the cluster option. Note that multiple accounts can be added at the same time by comma separating the names. A description of the account and the organization to which it belongs must be specified. These terms can be used later to generate accounting reports. Accounts may be arranged in a hierarchical fashion. For example, accounts chemistry and physics may be children of the account science. The hierarchy may have an arbitrary depth. Just specify the parent='' option in the add account line to construct the hierarchy. For the example above execute
これらのアカウントを追加するクラスターがさらにある場合は、クラスターを指定しないでシステム内のすべてのクラスターにアカウントを追加するか、クラスターオプションで追加するクラスター名をコンマで区切ることができます。名前をコンマで区切ることにより、複数のアカウントを同時に追加できることに注意してください。アカウントとアカウントが属する組織の説明を指定する必要があります。これらの用語は、後でアカウンティングレポートを生成するために使用できます。アカウントは階層的に配置できます。たとえば、アカウントの化学と物理学はアカウントサイエンスの子供である可能性があります。階層は任意の深さを持つことができます。アカウントを追加する行でparent = ''オプションを指定して、階層を構築します。上記の例では、

sacctmgr add account science \
 Description="science accounts" Organization=science
sacctmgr add account chemistry,physics parent=science \
 Description="physical sciences" Organization=science

Add users to accounts using similar syntax. For example, to permit user da to execute jobs on all clusters with a default account of test execute:
同様の構文を使用してユーザーをアカウントに追加します。たとえば、ユーザーdaがtest executeのデフォルトアカウントを使用してすべてのクラスターでジョブを実行することを許可するには、次のようにします。

sacctmgr add user brian Account=physics
sacctmgr add user da DefaultAccount=test

If AccountingStorageEnforce=associations is configured in the slurm.conf of the cluster snowflake then user da would be allowed to run in account test and any other accounts added in the future. Any attempt to use other accounts will result in the job being aborted. Account test will be the default if he doesn't specify one in the job submission command.
クラスタースノーフレークのslurm.confでAccountingStorageEnforce = associationsが構成されている場合、ユーザーdaはアカウントテストでの実行を許可され、その他のアカウントは将来追加されます。他のアカウントを使用しようとすると、ジョブが中止されます。ジョブ送信コマンドでアカウントテストを指定しない場合、アカウントテストがデフォルトになります。

Associations can also be created that are tied to specific partitions. When using the "add user" command of sacctmgr you can include the Partition=<PartitionName> option to create an association that is unique to other associations with the same Account and User.
特定のパーティションに関連付けられた関連付けを作成することもできます。sacctmgrの「ユーザーの追加」コマンドを使用する場合、Partition =を含めることができます。 同じアカウントとユーザーを持つ他の関連付けに固有の関連付けを作成するオプション。

Cluster Options

When either adding or modifying a cluster, these are the options available with sacctmgr:
クラスターを追加または変更する場合、sacctmgrで使用できるオプションは次のとおりです。

  • Name= Cluster name

Account Options

When either adding or modifying an account, the following sacctmgr options are available:
アカウントを追加または変更する場合、次のsacctmgrオプションを使用できます。

  • Cluster= Only add this account to these clusters. The account is added to all defined clusters by default.
    Cluster =このアカウントのみをこれらのクラスターに追加します。アカウントは、デフォルトですべての定義済みクラスターに追加されます。
  • Description= Description of the account. (Default is account name)
    Description =アカウントの説明。（デフォルトはアカウント名です）
  • Name= Name of account. Note the name must be unique and can not represent different bank accounts at different points in the account hierarchy
    Name =アカウントの名前。名前は一意である必要があり、口座階層の異なるポイントで異なる銀行口座を表すことはできません。
  • Organization=Organization of the account. (Default is parent account unless parent account is root then organization is set to the account name.)
    Organization =アカウントの組織。（親アカウントがrootでない限り、デフォルトは親アカウントです。組織はアカウント名に設定されます。）
  • Parent= Make this account a child of this other account (already added).
    Parent =このアカウントをこの別のアカウントの子にします（すでに追加されています）。

User Options

When either adding or modifying a user, the following sacctmgr options are available:
ユーザーを追加または変更する場合、次のsacctmgrオプションを使用できます。

  • Account= Account(s) to add user to
    Account =ユーザーを追加するアカウント
  • AdminLevel= This field is used to allow a user to add accounting privileges to this user. Valid options are
    AdminLevel =このフィールドは、ユーザーがこのユーザーに会計特権を追加できるようにするために使用されます。有効なオプションは
    • None
      なし
    • Operator: can add, modify, and remove any database object (user, account, etc), and add other operators
      On a SlurmDBD served slurmctld these users can

      オペレーター：データベースオブジェクト（ユーザー、アカウントなど）を追加、変更、削除して、他のオペレーターを追加できます。SlurmDBDで提供されるslurmctldで、これらのユーザーは
      • View information that is blocked to regular uses by a PrivateData flag
        PrivateDataフラグによって通常の使用がブロックされている情報を表示する
      • Create/Alter/Delete Reservations
        予約の作成/変更/削除
    • Admin: These users have the same level of privileges as an operator in the database. They can also alter anything on a served slurmctld as if they were the slurm user or root.
      管理者：これらのユーザーは、データベース内のオペレーターと同じレベルの特権を持っています。また、それらがslurmユーザーまたはrootであるかのように、提供されたslurmctld上のすべてを変更することもできます。
  • Cluster= Only add to accounts on these clusters (default is all clusters)
    Cluster =これらのクラスターのアカウントにのみ追加します（デフォルトはすべてのクラスターです）
  • DefaultAccount= Default account for the user, used when no account is specified when a job is submitted. (Required on creation)
    DefaultAccount =ユーザーのデフォルトアカウント。ジョブの送信時にアカウントが指定されていない場合に使用されます。（作成時に必要）
  • DefaultWCKey= Default wckey for the user, used when no wckey is specified when a job is submitted. (Only used when tracking wckeys.)
    DefaultWCKey =ユーザーのデフォルトのwckey。ジョブの送信時にwckeyが指定されていない場合に使用されます。（wckeysを追跡する場合にのみ使用されます。）
  • Name= User name
    Name =ユーザー名
  • NewName= Use to rename a user in the accounting database
    NewName =アカウンティングデータベース内のユーザーの名前を変更するために使用します
  • Partition= Name of Slurm partition this association applies to
    Partition =この関連付けが適用されるSlurmパーティションの名前

Limit Enforcement

Various limits and limit enforcement are described in the Resource Limits web page.
さまざまな制限と制限の実施については、リソース制限のWebページで説明しています。

To enable any limit enforcement you must at least have AccountingStorageEnforce=limits in your slurm.conf. Otherwise, even if you have limits set, they will not be enforced. Other options for AccountingStorageEnforce and the explanation for each are found on the Resource Limits document.
制限の適用を有効にするには、slurm.confに少なくともAccountingStorageEnforce = limitsが必要です。それ以外の場合は、制限が設定されていても、適用されません。AccountingStorageEnforceの他のオプションとそれぞれの説明は、リソース制限のドキュメントに記載されています。

Modifying Entities

When modifying entities, you can specify many different options in SQL-like fashion, using key words like where and set. A typical execute line has the following form:
エンティティを変更する場合、whereやsetなどのキーワードを使用して、SQLに似た方法でさまざまなオプションを指定できます。一般的な実行行は次の形式です。
 

sacctmgr modify <entity> set <options> where <options>

For example:

sacctmgr modify user set default=none where default=test

will change all users with a default account of "test" to account "none". Once an entity has been added, modified or removed, the change is sent to the appropriate Slurm daemons and will be available for use instantly.
「test」のデフォルトアカウントを持つすべてのユーザーをアカウント「none」に変更します。エンティティが追加、変更、または削除されると、変更は適切なSlurmデーモンに送信され、すぐに使用できます。

Removing Entities

Removing entities using an execute line similar to the modify example above, but without the set options. For example, remove all users with a default account "test" using the following execute line:
上記の変更例と同様の実行行を使用してエンティティーを削除しますが、設定オプションはありません。たとえば、次の実行行を使用して、デフォルトのアカウント「test」を持つすべてのユーザーを削除します。

sacctmgr remove user where default=test

will remove all user records where the default account is "test".
デフォルトのアカウントが「test」であるすべてのユーザーレコードを削除します。

sacctmgr remove user brian where account=physics

will remove user "brian" from account "physics". If user "brian" has access to other accounts, those user records will remain.
ユーザー「brian」をアカウント「physics」から削除します。ユーザー「brian」が他のアカウントにアクセスできる場合、それらのユーザーレコードは残ります。

Note: In most cases, removed entities are preserved in the slurm database, but flagged as deleted. If an entity has existed for less than 1 day, the entity will be removed completely. This is meant to clean up after typographical errors. Removing user associations or accounts, however, will cause slurmctld to lose track of usage data for that user/account.
注：ほとんどの場合、削除されたエンティティはslurmデータベースに保持されますが、削除済みのフラグが付けられます。エンティティが存在してから1日未満の場合、エンティティは完全に削除されます。これは、タイプミスの後にクリーンアップするためのものです。ただし、ユーザーの関連付けまたはアカウントを削除すると、slurmctldはそのユーザー/アカウントの使用状況データを追跡できなくなります。

Last modified 12 May 2020