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.
Slurmは、実行されたすべてのジョブおよびジョブステップのアカウンティング情報を収集するように構成できます。
 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.
sacctコマンドは、個々のタスクを含む実行中または終了したジョブのリソース使用量をレポートできます。これは、タスク間の負荷の不均衡を検出するのに役立ちます。
 The sstat command can be used to status only currently running jobs.
sstatコマンドを使用して、現在実行中のジョブのみをステータス設定できます。
 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.
sreportを使用して、特定の時間間隔で実行されたすべてのジョブに基づいてレポートを生成できます。

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

  • AccountingStorageType controls how detailed job and job step information is recorded.
    AccountingStorageTypeは、詳細なジョブおよびジョブステップ情報の記録方法を制御します。
     You can store this information in a text file or into SlurmDBD.
    この情報は、テキストファイルまたはSlurmDBDに保存できます。
  • JobAcctGatherType is operating system dependent and controls what mechanism is used to collect accounting information.
    JobAcctGatherTypeはオペレーティングシステムに依存し、アカウンティング情報の収集に使用されるメカニズムを制御します。
     Supported values are jobacct_gather/linux (recommended), jobacct_gather/cgroup and jobacct_gather/none (no information collected).
    サポートされている値は、jobacct_gather / linux（推奨）、jobacct_gather / cgroup、およびjobacct_gather / none（情報は収集されません）です。
  • JobCompType controls how job completion information is recorded.
    JobCompTypeは、ジョブ完了情報の記録方法を制御します。
     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.
    この情報は、テキストファイル、MySQLまたはMariaDBデータベースに保存できます。

The use of sacct to view information about jobs is dependent upon AccountingStorageType being configured to collect and store that information.
ジョブに関する情報を表示するためのsacctの使用は、その情報を収集および保存するように構成されているAccountingStorageTypeに依存します。
 The use of sreport is dependent upon some database being used to store that information.
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).
適切なプラグイン（例：AccountingStorageType = accounting_storage / filetxtおよび/またはJobCompType = jobcomp / filetxt）を構成してから、ファイルのパス名（例：AccountingStorageLoc = / var / log / slurm / accountingおよび/またはJobCompLoc = / var / log）を指定するだけです。 / slurm / job_completions）。
 Use the logrotate or similar tool to prevent the log files from getting too large.
logrotateまたは同様のツールを使用して、ログファイルが大きくなりすぎないようにします。
 Send a SIGUSR2 signal to the slurmctld daemon after moving the files, but before compressing them so that new log files will be created.
ファイルを移動した後、新しいログファイルが作成されるようにファイルを圧縮する前に、SIGUSR2シグナルをslurmctldデーモンに送信します。

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).
Slurmからデータベースにデータを直接保存することは魅力的に思えるかもしれませんが、Slurm制御デーモン（slurmctld）だけでなく、データにアクセスする必要のあるユーザーコマンド（sacct、sreport）のユーザー名とパスワードデータの可用性が必要です。 、および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（Slurm Database Daemon）はそのようなサービスを提供します。
 SlurmDBD is written in C, multi-threaded, secure and fast.
SlurmDBDは、Cで記述されており、マルチスレッドで、安全で高速です。
 The configuration required to use SlurmDBD will be described below.
SlurmDBDを使用するために必要な構成を以下に説明します。
 Storing information directly into a database would be similar.
情報をデータベースに直接保存することも同様です。

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.
SlurmDBDは、認証のために既存のSlurmプラグインに依存し、データベースで使用するためにSlurm sqlに依存しますが、SlurmDBDがインストールされているホストでは他のSlurmコマンドとデーモンは必要ありません。
 Install the slurm and slurm-slurmdbd RPMs on the server where SlurmDBD is to run.
SlurmDBDを実行するサーバーにslurmおよびslurm-slurmdbdRPMをインストールします。

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.
MySQLプラグインの使用からSlurmDBDプラグインの使用に切り替える場合は、クラスターがデータベースに追加されていることを確認する必要があることに注意してください。
 The MySQL plugin doesn't require this, but also will not hurt things if you have it there when using the MySQL plugin.
MySQLプラグインはこれを必要としませんが、MySQLプラグインを使用するときにそこにある場合でも問題はありません。
 You can verify with
あなたはで確認することができます
 

sacctmgr list cluster
If the cluster isn't there add it (where my cluster's name was snowflake):
クラスターがない場合は、クラスターを追加します（クラスターの名前はsnowflakeでした）。
 
sacctmgr add cluster snowflake
Failure to do so will result in the slurmctld failing to talk to the slurmdbd after the switch.
そうしないと、切り替え後にslurmctldがslurmdbdと通信できなくなります。
 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.
新しいバージョンのSlurmにアップグレードする場合は、同時にプラグインを切り替えないでください。そうしないと、予期しない結果が生じる可能性があります。
 Do one then the other.
どちらか一方を実行し、次にもう一方を実行します。

If SlurmDBD is configured for use but not responding then slurmctld will utilize an internal cache until SlurmDBD is returned to service.
SlurmDBDが使用するように構成されているが応答しない場合、slurmctldは、SlurmDBDがサービスに戻るまで内部キャッシュを利用します。
 The cached data is written by slurmctld to local storage upon shutdown and recovered at startup.
キャッシュされたデータは、シャットダウン時にslurmctldによってローカルストレージに書き込まれ、起動時に回復されます。
 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.
slurmctldの開始時にSlurmDBDが使用できない場合、デーモンが最後に通信したときの状態に基づいた有効な銀行口座、ユーザー制限などのキャッシュが使用されます。
 Note that SlurmDBD must be responding when slurmctld is first started since no cache of this critical data will be available.
この重要なデータのキャッシュが利用できないため、slurmctldが最初に開始されたときにSlurmDBDが応答している必要があることに注意してください。
 Job and step accounting records generated by slurmctld will be written to a cache as needed and transferred to SlurmDBD when returned to service.
slurmctldによって生成されたジョブおよびステップのアカウンティングレコードは、必要に応じてキャッシュに書き込まれ、サービスに戻るときにSlurmDBDに転送されます。
 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がダウンしている場合、メッセージはドロップされ始めることに注意してください。

Infrastructure

With the SlurmDBD, we are able to collect data from multiple clusters in a single location.
SlurmDBDを使用すると、1つの場所で複数のクラスターからデータを収集できます。
 This does impose some constraints on the user naming and IDs.
これにより、ユーザーの名前付けとIDにいくつかの制約が課せられます。
 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.
アカウンティングは（ユーザーIDではなく）ユーザー名によって維持されますが、特定のユーザー名はすべてのコンピューターで同じ人物を参照する必要があります。
 Authentication relies upon user ID numbers, so those must be uniform across all computers communicating with each SlurmDBD, at least for users requiring authentication.
認証はユーザーID番号に依存するため、少なくとも認証を必要とするユーザーについては、各SlurmDBDと通信するすべてのコンピューターで統一されている必要があります。
 In particular, the configured SlurmUser must have the same name and ID across all clusters.
特に、構成されたSlurmUserは、すべてのクラスターで同じ名前とIDを持っている必要があります。
 If you plan to have administrators of user accounts, limits, etc. they must also have consistent names and IDs across all clusters.
ユーザーアカウントや制限などの管理者を配置する場合は、すべてのクラスターで一貫した名前とIDを使用する必要があります。
 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.
アカウンティングレコードへのアクセスを制限する場合（たとえば、ユーザーに自分のジョブのレコードの表示のみを許可する場合）、すべてのユーザーは一貫した名前と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.
データのセキュリティを確保する最善の方法は、SlurmDBDへの通信を認証することです。そのためには、MUNGEをお勧めします。
 If you have one cluster managed by Slurm and execute the SlurmDBD on that one cluster, the normal MUNGE configuration will suffice.
Slurmによって管理されているクラスターが1つあり、その1つのクラスターでSlurmDBDを実行する場合は、通常のMUNGE構成で十分です。
 Otherwise MUNGE should then be installed on all nodes of all Slurm managed clusters, plus the machine where SlurmDBD executes.
それ以外の場合は、MUNGEをすべてのSlurm管理対象クラスターのすべてのノードに加えて、SlurmDBDが実行されるマシンにインストールする必要があります。
 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キーを使用するか、クラスターごとに一意のキーを維持し、さらにセキュリティを強化するためにクラスター間の通信用に2番目のキーを使用するかを選択できます。
 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).
MUNGEの機能拡張は、単一の構成ファイル内で2つのキーをサポートするように計画されていますが、現在、2つの異なるキーをサポートするには、2つの異なるデーモンを異なる構成で開始する必要があります（2つのキーファイルを作成し、-key-fileオプションを使用してデーモンを開始して適切なキーと--socketオプションを使用して、それぞれに個別のローカルドメインソケットを指定します）。
 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).
ローカルドメインソケットのパス名は、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.
認証モジュールを使用するかどうかに関係なく、SlurmDBDがユーザーや管理者のUIDを取得する方法が必要になります。
 If using MUNGE, it is ideal for your users to have the same id on all your clusters.
MUNGEを使用する場合、ユーザーがすべてのクラスターで同じIDを持つことが理想的です。
 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.
この場合、データベースサーバー上にすべてのクラスターの/ etc / passwdファイルを組み合わせて、DBDが認証のために名前を解決できるようにする必要があります。
 If using MUNGE and a user's name is not in the passwd file the action will fail.
MUNGEを使用していて、ユーザーの名前がpasswdファイルにない場合、アクションは失敗します。
 If not using MUNGE, you should add anyone you want to be an administrator or operator to the passwd file.
MUNGEを使用しない場合は、管理者またはオペレーターになりたい人をpasswdファイルに追加する必要があります。
 If they plan on running sacctmgr or any of the accounting tools they should have the same UID, or they will not authenticate correctly.
sacctmgrまたはいずれかのアカウンティングツールの実行を計画している場合は、同じUIDを使用する必要があります。そうしないと、正しく認証されません。
 An LDAP server could also serve as a way to gather this information.
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.
現在、ジョブの完了はSlurmDBDではサポートされていませんが、データベース、スクリプト、またはフラットファイルに直接書き込むことができます。
 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:
これを構成する場合、より重要なパラメーターには次のものがあります。

  • JobCompHost: Only needed if using a database.
    JobCompHost：データベースを使用する場合にのみ必要です。
     The name or address of the host where the database server executes.
    データベースサーバーが実行されるホストの名前またはアドレス。
  • JobCompLoc: Only needed if using a flat file.
    JobCompLoc：フラットファイルを使用する場合にのみ必要です。
     Location of file to write the job completion data to.
    ジョブ完了データを書き込むファイルの場所。
  • JobCompPass: Only needed if using a database.
    JobCompPass：データベースを使用する場合にのみ必要です。
     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.
    パスワードは安全に管理できないため、データベースに直接情報を保存することはお勧めしません。
  • JobCompPort: Only needed if using a database.
    JobCompPort：データベースを使用する場合にのみ必要です。
     The network port that the database accepts communication on.
    データベースが通信を受け入れるネットワークポート。
  • 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.
    JobCompUser：データベースを使用する場合にのみ必要です。
     User name to connect to the database with.
    データベースに接続するためのユーザー名。
  • 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.
SlurmDBDは、ジョブの完了や同様のデータを記録するためにフラットテキストファイルで機能しますが、この構成では、ユーザーとアカウント間の「関連付け」は許可されません。
 A database allows such a configuration.
データベースはそのような構成を可能にします。

MySQL or MariaDB is the preferred database.
MySQLまたはMariaDBが推奨されるデータベースです。
 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.
Slurmは、MySQLのInnoDBストレージエンジンを使用してロールバックを可能にします。
 This must be available on your MySQL installation or rollback will not work.
これは、MySQLインストールで使用可能である必要があります。使用できない場合、ロールバックは機能しません。

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

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.
注：slurmdbdを初めて実行する前に、MySQLの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.
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.
また、5.7より前のMySQLバージョンでは、デフォルトの行形式がCOMPACTに設定されていたため、アップグレード中にテーブルを作成するときに問題が発生する可能性がありました。
 In more recent versions it was changed to DYNAMIC.
最近のバージョンでは、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.
テーブルの行形式は、その行がページに物理的に格納される方法を決定し、クエリとDML操作のパフォーマンスに直接影響します。
 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.
非常に特殊な状況では、DYNAMIC以外の形式を使用すると、行がページに収まらない可能性があり、そのため、MySQLはテーブルの作成中にエラーをスローする可能性があります。
 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.
したがって、デフォルトでDYNAMICを使用していない場合は、データベーステーブルを作成する前に行形式について注意深く読み、データベースバージョンでサポートされている場合はそれを設定することを検討することをお勧めします。
 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:
アップグレード中に次のInnoDBエラーが表示された場合は、変換を続行できるように、テーブルを変更して（時間がかかる場合があります）、行形式をDYNAMICに設定できます。
 

[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.
簡単にするために、SlurmDBDを使用していることを前提に進めます。
 You can communicate with a storage plugin directly, but that offers minimal security.
ストレージプラグインと直接通信できますが、セキュリティは最小限に抑えられます。

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

  • AccountingStorageEnforce: This option contains a comma separated list of options you may want to enforce.
    AccountingStorageEnforce：このオプションには、強制する可能性のあるオプションのコンマ区切りのリストが含まれています。
     The valid options are any comma separated combination of

      有効なオプションは、コンマで区切られた任意の組み合わせです。
    • 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'.
      制限-これにより、アソシエーションと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」が引き続き必要です。
    • nojobs - This will make it so no job information is stored in accounting.
      nojobs-これにより、ジョブ情報がアカウンティングに保存されなくなります。
       By setting this 'nosteps' is also set.
      これを設定することにより、「nosteps」も設定されます。
    • nosteps - This will make it so no step information is stored in accounting.
      nosteps-これにより、ステップ情報がアカウンティングに保存されなくなります。
       Both nojobs and nosteps could be helpful in an environment where you want to use limits but don't really care about utilization.
      nojobsとnostepsはどちらも、制限を使用したいが実際には使用率を気にしない環境で役立つ可能性があります。
    • qos - This will require all jobs to specify (either overtly or by default) a valid qos (Quality of Service).
      qos-これにより、すべてのジョブで有効なqos（サービス品質）を（明示的またはデフォルトで）指定する必要があります。
       QOS values are defined for each association in the database.
      QOS値は、データベース内の関連付けごとに定義されます。
       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制限を適用する場合は、「制限」オプションを使用する必要があります。
    • 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.
      安全-これにより、ジョブを完了まで実行できる場合に、GrpTRESMins制限が設定されているアソシエーションまたはQoSを使用している場合にのみジョブが起動されるようになります。
       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.
      このオプションが設定されていない場合、ジョブは、使用量がTRES分の制限に達していない限り起動されます。これにより、ジョブが起動されますが、制限に達すると強制終了されます。
       By setting this option, both the 'associations' option and the 'limits' option are set automatically.
      このオプションを設定すると、「関連付け」オプションと「制限」オプションの両方が自動的に設定されます。
    • wckeys - This will prevent users from running jobs under a wckey that they don't have access to.
      wckeys-これにより、ユーザーはアクセスできないwckeyでジョブを実行できなくなります。
       By using this option, the 'associations' option is automatically set.
      このオプションを使用すると、「関連付け」オプションが自動的に設定されます。
       The 'TrackWCKey' option is also set to true.
      '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.
    AccountingStorageExternalHost：登録する外部slurmdbds（＜host / ip＞ [：port] [、...]）のコンマ区切りのリスト。
     If no port is given, the AccountingStoragePort will be used.
    ポートが指定されていない場合、AccountingStoragePortが使用されます。
     This allows clusters registered with the external slurmdbd to communicate with each other using the --cluster/-M client command options.
    これにより、外部slurmdbdに登録されているクラスターは、-cluster / -Mclientコマンドオプションを使用して相互に通信できます。
     The cluster will add itself to the external slurmdbd if it doesn't exist.
    クラスターが存在しない場合、クラスターはそれ自体を外部slurmdbdに追加します。
     If a non-external cluster already exists on the external slurmdbd, the slurmctld will ignore registering to the external 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).
    AccountingStoragePass：2番目のMUNGEデーモンでSlurmDBDを使用する場合、企業全体の認証を提供するためにMUNGEが使用する名前付きソケットのパス名を格納します（つまり、/ var / run / munge / moab.socket.2）。
     Otherwise the default MUNGE daemon will be used.
    それ以外の場合は、デフォルトの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.
    TrackWCKey：ブール値。
     If you want to track wckeys (Workload Characterization Key) of users.
    ユーザーのwckey（ワークロード特性キー）を追跡する場合。
     A Wckey is an orthogonal way to do accounting against possibly unrelated accounts.
    Wckeyは、おそらく無関係なアカウントに対してアカウンティングを行うための直交する方法です。
     When a job is run, use the --wckey option to specify a value and accounting records will be collected by this wckey.
    ジョブの実行時に、-wckeyオプションを使用して値を指定すると、アカウンティングレコードがこのwckeyによって収集されます。

SlurmDBD Configuration

SlurmDBD requires its own configuration file called "slurmdbd.conf".
SlurmDBDには、「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").
このファイルは、SlurmDBDが実行されるコンピューター上にのみ存在し、SlurmDBDを実行するユーザー（「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.
構成パラメーターの詳細については、「manslurmdbd.conf」を参照してください。
 Some of the more important parameters include:
より重要なパラメータには、次のものがあります。

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

GRANT ALL ON StorageLoc.* TO 'StorageUser'@'StorageHost';
(The ticks are needed)
StorageLoc。*のすべてを 'StorageUser' @ 'StorageHost'に付与します。（ダニが必要です）

(You need to be root to do this.
（これを行うには、rootである必要があります。
 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 ';'.
前のmysqlステートメントが「;」で終わっていなかったため、これは継続プロンプトです。
 It assumes that you wish to input more info.)
より多くの情報を入力したいことを前提としています。）

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
InnoDBをサポートしていることを確認します

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.
これにより、ユーザーの「slurm」アクセスが許可され、ローカルホストまたはストレージホストシステムで必要な処理を実行できます。
 This must be done before the SlurmDBD will work properly.
これは、SlurmDBDが正しく機能する前に実行する必要があります。
 After you grant permission to the user 'slurm' in mysql then you can start SlurmDBD and the other Slurm daemons.
mysqlでユーザー「slurm」に権限を付与した後、SlurmDBDおよびその他のSlurmデーモンを起動できます。
 You start SlurmDBD by typing its pathname '/usr/sbin/slurmdbd' or '/etc/init.d/slurmdbd start'.
SlurmDBDを開始するには、パス名「/ usr / sbin / slurmdbd」または「/etc/init.d/slurmdbdstart」を入力します。
 You can verify that SlurmDBD is running by typing 'ps aux | grep 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.
SlurmDBDが実行されていない場合は、SlurmDBDの起動時に-vオプションを使用して、より詳細な情報を取得できます。
 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をデーモンモードで「-D」オプションを指定して起動すると、デバッグにも役立つため、問題を見つけるためにログに移動する必要はありません。

Tools

There are a few tools available to work with accounting data, sacct, sacctmgr, and sreport.
アカウンティングデータ、sacct、sacctmgr、およびsreportを操作するために使用できるツールがいくつかあります。
 These tools all get or set data through the SlurmDBD daemon.
これらのツールはすべて、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.
アカウンティングレコードは、クラスター、アカウント、ユーザー名、およびオプションのパーティション名の4つの要素で構成されるアソシエーションと呼ばれるものに基づいて維持されます。
 Use the sacctmgr command to create and manage these records.
これらのレコードを作成および管理するには、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.
たとえば、「snowflake」という名前のクラスターをデータベースに追加するには、この行を実行します（注：20.02以降、slurmctldは、クラスターが存在しない場合、開始時にデータベースに追加します。
 Associations still need to be created after addition):
追加後も関連付けを作成する必要があります）：

sacctmgr add cluster snowflake

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

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.
アカウントの追加行でparent = ''オプションを指定するだけで、階層が構築されます。
 For the example above execute
上記の例では、

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.
AccountingStorageEnforce = associationsがクラスターsnowflakeのslurm.confで構成されている場合、ユーザーdaはアカウントテストおよび将来追加される他のアカウントで実行できます。
 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.
ジョブ送信コマンドでアカウントテストを指定しない場合、アカウントテストがデフォルトになります。

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 = ＜PartitionName＞オプションを含めて、同じアカウントとユーザーを持つ他のアソシエーションに固有のアソシエーションを作成できます。

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

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.
    AdminLevel =このフィールドは、ユーザーがこのユーザーにアカウンティング特権を追加できるようにするために使用されます。
     Valid options are
    有効なオプションは次のとおりです
    • 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.
      また、提供されたslurmctldのすべてを、slurmユーザーまたはrootであるかのように変更できます。
  • 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.
    DefaultAccount =ユーザーのデフォルトアカウント。ジョブの送信時にアカウントが指定されていない場合に使用されます。
     (Required on creation)
    （作成時に必要）
  • DefaultWCKey= Default wckey for the user, used when no wckey is specified when a job is submitted.
    DefaultWCKey =ユーザーのデフォルトのwckey。ジョブの送信時にwckeyが指定されていない場合に使用されます。
     (Only used when tracking wckeys.)
    （wckeyを追跡する場合にのみ使用されます。）
  • Name= User 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.
制限の適用を有効にするには、少なくともslurm.confにAccountingStorageEnforce = limitsが含まれている必要があります。
 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.
AccountingStorageEnforceの他のオプションとそれぞれの説明は、リソース制限ドキュメントに記載されています。

Modifying Entities

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

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".
デフォルトのアカウントが「test」のすべてのユーザーをアカウント「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.
エンティティが追加、変更、または削除されると、変更は適切な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".
アカウント「physics」からユーザー「brian」を削除します。
 If user "brian" has access to other accounts, those user records will remain.
ユーザー「brian」が他のアカウントにアクセスできる場合、それらのユーザーレコードは残ります。

Note: In most cases, removed entities are preserved in the slurm database, but flagged as deleted.
注：ほとんどの場合、削除されたエンティティはslurmデータベースに保持されますが、削除済みのフラグが付けられます。
 If an entity has existed for less than 1 day, the entity will be removed completely.
エンティティの存在期間が1日未満の場合、エンティティは完全に削除されます。
 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.
ただし、ユーザーの関連付けまたはアカウントを削除すると、slurmctldはそのユーザー/アカウントの使用状況データを追跡できなくなります。

Last modified 12 May 2020