Advanced Resource Reservation Guide

Slurm has the ability to reserve resources for jobs being executed by select users and/or select bank accounts. A resource reservation identifies the resources in that reservation and a time period during which the reservation is available. The resources which can be reserved include cores, nodes, licenses and/or burst buffers. A reservation that contains nodes or cores is associated with one partition, and can't span resources over multiple partitions. The only exception from this is when the reservation is created with explicitly requested nodes. Note that resource reservations are not compatible with Slurm's gang scheduler plugin since the termination time of running jobs cannot be accurately predicted.
Slurmには、一部のユーザーや一部の銀行口座が実行するジョブ用にリソースを予約する機能があります。リソース予約は、その予約のリソースと、予約が利用可能な期間を識別します。予約できるリソースには、コア、ノード、ライセンス、バーストバッファーなどがあります。ノードまたはコアを含む予約は1つのパーティションに関連付けられており、リソースを複数のパーティションにまたがることはできません。これの唯一の例外は、明示的に要求されたノードで予約が作成された場合です。実行中のジョブの終了時間を正確に予測できないため、リソースの予約はSlurmのギャングスケジューラプラグインと互換性がないことに注意してください。

Note that reserved burst buffers and licenses are treated somewhat differently than reserved cores or nodes. When cores or nodes are reserved, then jobs using that reservation can use only those resources (this behavior can be change using FLEX flag) and no other jobs can use those resources. Reserved burst buffers and licenses can only be used by jobs associated with that reservation, but licenses not explicitly reserved are available to any job. This eliminates the need to explicitly put licenses into every advanced reservation created.
予約済みのバーストバッファーとライセンスは、予約済みのコアまたはノードとは少し異なる方法で処理されることに注意してください。コアまたはノードが予約されると、その予約を使用するジョブはそれらのリソースのみを使用でき（この動作はFLEXフラグを使用して変更できます）、他のジョブはそれらのリソースを使用できません。予約済みのバーストバッファーとライセンスは、その予約に関連付けられたジョブでのみ使用できますが、明示的に予約されていないライセンスはどのジョブでも使用できます。これにより、作成されたすべての事前予約に明示的にライセンスを配置する必要がなくなります。

Reservations can be created, updated, or destroyed only by user root or the configured SlurmUser using the scontrol command. The scontrol and sview commands can be used to view reservations. The man pages for the various commands contain details.
予約の作成、更新、破棄は、ユーザーrootまたは構成されたSlurmUserのみがscontrolコマンドを使用して行うことができます。scontrolおよびsviewコマンドを使用して、予約を表示できます。さまざまなコマンドのマニュアルページに詳細が記載されています。

Reservation Creation

One common mode of operation for a reservation would be to reserve an entire computer at a particular time for a system down time. The example below shows the creation of a full-system reservation at 16:00 hours on 6 February and lasting for 120 minutes. The "maint" flag is used to identify the reservation for accounting purposes as system maintenance. The "ignore_jobs" flag is used to indicate that we can ignore currently running jobs when creating this reservation. By default, only resources which are not expected to have a running job at the start time can be reserved (the time limit of all running jobs will have been reached). In this case we can manually cancel the running jobs as needed to perform system maintenance. As the reservation time approaches, only jobs that can complete by the reservation time will be initiated.
予約の一般的な操作モードの1つは、特定の時間にシステム全体のコンピューター全体を予約することです。以下の例は、2月6日の16:00に120分間続く完全なシステム予約の作成を示しています。「maint」フラグは、システム保守としての会計目的の予約を識別するために使用されます。「ignore_jobs」フラグは、この予約を作成するときに現在実行中のジョブを無視できることを示すために使用されます。デフォルトでは、開始時に実行中のジョブがあると予想されないリソースのみを予約できます（実行中のすべてのジョブの時間制限に達しています）。この場合、必要に応じて、実行中のジョブを手動でキャンセルして、システムメンテナンスを実行できます。予約時間が近づくと、予約時間までに完了できるジョブのみが開始されます。

$ scontrol create reservation starttime=2009-02-06T16:00:00 \
   duration=120 user=root flags=maint,ignore_jobs nodes=ALL
Reservation created: root_3

$ scontrol show reservation
ReservationName=root_3 StartTime=2009-02-06T16:00:00
   EndTime=2009-02-06T18:00:00 Duration=120
   Nodes=ALL NodeCnt=20
   Features=(null) PartitionName=(null)
   Flags=MAINT,SPEC_NODES,IGNORE_JOBS Licenses=(null)
   BurstBuffers=(null)
   Users=root Accounts=(null)

A variation of this would be to configure license to represent system resources, such as a global file system. The system resource may not require an actual license for use, but Slurm licenses can be used to prevent jobs needed the resource from being started when that resource is unavailable. One could create a reservation for all of those licenses in order to perform maintenance on that resource. In the example below, we create a reservation for 1000 licenses with the name of "lustre". If there are a total of 1000 lustre licenses configured in this cluster, this reservation will prevent any job specifying the need for needed a lustre license from being scheduled on this cluster during this reservation.
これのバリエーションは、グローバルファイルシステムなどのシステムリソースを表すようにライセンスを設定することです。システムリソースは実際の使用ライセンスを必要としない場合がありますが、Slurmライセンスを使用すると、リソースが使用できないときにリソースを必要とするジョブが開始されないようにすることができます。そのリソースのメンテナンスを実行するために、それらすべてのライセンスの予約を作成できます。以下の例では、「lustre」という名前の1000ライセンスの予約を作成します。このクラスターで合計1000の光沢ライセンスが構成されている場合、この予約により、必要な光沢ライセンスの必要性を指定するジョブが、この予約中にこのクラスターでスケジュールされなくなります。

$ scontrol create reservation starttime=2009-04-06T16:00:00 \
   duration=120 user=root flags=license_only \
   licenses=lustre:1000
Reservation created: root_4

$ scontrol show reservation
ReservationName=root_4 StartTime=2009-04-06T16:00:00
   EndTime=2009-04-06T18:00:00 Duration=120
   Nodes= NodeCnt=0
   Features=(null) PartitionName=(null)
   Flags=LICENSE_ONLY Licenses=lustre*1000
   BurstBuffers=(null)
   Users=root Accounts=(null)

Another mode of operation would be to reserve specific nodes for an indefinite period in order to study problems on those nodes. This could also be accomplished using a Slurm partition specifically for this purpose, but that would fail to capture the maintenance nature of their use.
別の操作モードは、特定のノードの問題を調査するために、特定のノードを無期限に予約することです。これは、特にこの目的のためにSlurmパーティションを使用して実現することもできますが、その使用の保守性を捉えることはできません。

$ scontrol create reservation user=root starttime=now \
   duration=infinite flags=maint nodes=sun000
Reservation created: root_5

$ scontrol show res
ReservationName=root_5 StartTime=2009-02-04T16:22:57
   EndTime=2009-02-04T16:21:57 Duration=4294967295
   Nodes=sun000 NodeCnt=1
   Features=(null) PartitionName=(null)
   Flags=MAINT,SPEC_NODES Licenses=(null)
   BurstBuffers=(null)
   Users=root Accounts=(null)

Our next example is to reserve ten nodes in the default Slurm partition starting at noon and with a duration of 60 minutes occurring daily. The reservation will be available only to users "alan" and "brenda".
次の例では、正午に開始し、毎日60分の期間で、デフォルトのSlurmパーティションに10個のノードを予約します。予約は、「alan」と「brenda」のユーザーのみが利用できます。

$ scontrol create reservation user=alan,brenda \
   starttime=noon duration=60 flags=daily nodecnt=10
Reservation created: alan_6

$ scontrol show res
ReservationName=alan_6 StartTime=2009-02-05T12:00:00
   EndTime=2009-02-05T13:00:00 Duration=60
   Nodes=sun[000-003,007,010-013,017] NodeCnt=10
   Features=(null) PartitionName=pdebug
   Flags=DAILY Licenses=(null) BurstBuffers=(null)
   Users=alan,brenda Accounts=(null)

Our next example is to reserve 100GB of burst buffer space starting at noon today and with a duration of 60 minutes. The reservation will be available only to users "alan" and "brenda".
次の例では、今日の正午から60分の期間で100GBのバーストバッファースペースを予約します。予約は、「alan」と「brenda」のユーザーのみが利用できます。

$ scontrol create reservation user=alan,brenda \
   starttime=noon duration=60 flags=any_nodes burstbuffer=100GB
Reservation created: alan_7

$ scontrol show res
ReservationName=alan_7 StartTime=2009-02-05T12:00:00
   EndTime=2009-02-05T13:00:00 Duration=60
   Nodes= NodeCnt=0
   Features=(null) PartitionName=(null)
   Flags=ANY_NODES Licenses=(null) BurstBuffer=100GB
   Users=alan,brenda Accounts=(null)

Reservations can be optimized with respect to system topology if the reservation request includes information about the sizes of jobs to be created. This is especially important for BlueGene systems due to restrictive rules about the topology of created blocks (due to hardware constraints and/or Slurm's configuration). To take advantage of this optimization, specify the sizes of jobs of to be concurrently executed. The example below creates a reservation containing 4096 c-nodes on a BlueGene system so that two 2048 c-node jobs can execute simultaneously.
作成するジョブのサイズに関する情報が予約要求に含まれている場合、システムトポロジに関して予約を最適化できます。これはBlueGeneシステムにとって特に重要です（ハードウェアの制約やSlurmの構成により）作成されたブロックのトポロジに関する制限的なルールに起因します。この最適化を利用するには、同時に実行するジョブのサイズを指定します。以下の例では、BlueGeneシステム上に4096個のcノードを含む予約を作成して、2つの2048個のcノードジョブを同時に実行できるようにします。

$ scontrol create reservation user=alan,brenda \
   starttime=noon duration=60 nodecnt=2k,2k
Reservation created: alan_8

$ scontrol show res
ReservationName=alan_8 StartTime=2011-12-05T12:00:00
   EndTime=2011-12-05T13:00:00 Duration=60
   Nodes=bgp[000x011,210x311] NodeCnt=4096
   Features=(null) PartitionName=pdebug
   Flags= Licenses=(null) BurstBuffers=(null)
   Users=alan,brenda Accounts=(null)

Note that specific nodes to be associated with the reservation are identified immediately after creation of the reservation. This permits users to stage files to the nodes in preparation for use during the reservation. Note that the reservation creation request can also identify the partition from which to select the nodes or _one_ feature that every selected node must contain.
予約に関連付けられる特定のノードは、予約の作成直後に識別されることに注意してください。これにより、ユーザーは、予約時に使用する準備としてノードにファイルをステージングできます。予約作成リクエストでは、ノードの選択元のパーティション、または選択したすべてのノードに含まれている必要がある_one_機能も識別できることに注意してください。

On a smaller system, one might want to reserve cores rather than whole nodes. This capability permits the administrator to identify the core count to be reserved on each node as shown in the examples below.
NOTE: Core reservations are not available when the system is configured to use the select/linear plugin.
小規模なシステムでは、ノード全体ではなくコアを予約したい場合があります。この機能により、管理者は、以下の例に示すように、各ノードで予約するコア数を特定できます。注：システムがselect / linearプラグインを使用するように構成されている場合、コア予約は使用できません。

# Create a two core reservation for user alan
$ scontrol create reservation StartTime=now Duration=60 \
  NodeCnt=1 CoreCnt=2 User=alan

# Create a reservation for user brenda with two cores on
# node tux8 and 4 cores on node tux9
$ scontrol create reservation StartTime=now Duration=60 \
  Nodes=tux8,tux9 CoreCnt=2,4 User=brenda

Reservations can not only be created for the use of specific accounts and users, but specific accounts and/or users can be prevented from using them. In the following example, a reservation is created for account "foo", but user "alan" is prevented from using the reservation even when using the account "foo".
予約は、特定のアカウントやユーザーを使用するために作成できるだけでなく、特定のアカウントやユーザーがそれらを使用できないようにすることもできます。次の例では、アカウント「foo」の予約が作成されていますが、ユーザー「alan」は、アカウント「foo」を使用している場合でも、予約を使用できません。

$ scontrol create reservation account=foo \
   user=-alan partition=pdebug \
   starttime=noon duration=60 nodecnt=2k,2k
Reservation created: alan_9

$ scontrol show res
ReservationName=alan_9 StartTime=2011-12-05T13:00:00
   EndTime=2011-12-05T14:00:00 Duration=60
   Nodes=bgp[000x011,210x311] NodeCnt=4096
   Features=(null) PartitionName=pdebug
   Flags= Licenses=(null) BurstBuffers=(null)
   Users=-alan Accounts=foo

Reservation Use

The reservation create response includes the reservation's name. This name is automatically generated by Slurm based upon the first user or account name and a numeric suffix. In order to use the reservation, the job submit request must explicitly specify that reservation name. The job must be contained completely within the named reservation. The job will be canceled after the reservation reaches its EndTime. If letting the job continue execution after the reservation EndTime, a configuration option ResvOverRun in slurm.conf can be set to control how long the job can continue execution.
予約作成応答には、予約の名前が含まれています。この名前は、最初のユーザー名またはアカウント名と数値のサフィックスに基づいてSlurmによって自動的に生成されます。予約を使用するには、ジョブ送信リクエストでその予約名を明示的に指定する必要があります。ジョブは指定された予約内に完全に含まれている必要があります。予約がEndTimeに達すると、ジョブはキャンセルされます。予約のEndTimeの後にジョブの実行を継続させる場合は、slurm.confの構成オプションResvOverRunを設定して、ジョブが実行を継続できる時間を制御できます。

$ sbatch --reservation=alan_6 -N4 my.script
sbatch: Submitted batch job 65540

Note that use of a reservation does not alter a job's priority, but it does act as an enhancement to the job's priority. Any job with a reservation is considered for scheduling to resources before any other job in the same Slurm partition (queue) not associated with a reservation.
予約を使用してもジョブの優先度は変更されませんが、ジョブの優先度の拡張として機能することに注意してください。予約のあるジョブは、予約に関連付けられていない同じSlurmパーティション（キュー）内の他のジョブの前に、リソースへのスケジューリングと見なされます。

Reservation Modification

Reservations can be modified by user root as desired. For example their duration could be altered or the users granted access changed as shown below:
予約は、必要に応じてユーザーrootによって変更できます。たとえば、期間を変更したり、アクセスを許可したユーザーを次のように変更したりできます。

$ scontrol update ReservationName=root_3 \
   duration=150 users=admin
Reservation updated.

bash-3.00$ scontrol show ReservationName=root_3
ReservationName=root_3 StartTime=2009-02-06T16:00:00
   EndTime=2009-02-06T18:30:00 Duration=150
   Nodes=ALL NodeCnt=20 Features=(null)
   PartitionName=(null) Flags=MAINT,SPEC_NODES
   Licenses=(null) BurstBuffers=(null)
   Users=admin Accounts=(null)

Reservation Deletion

Reservations are automatically purged after their end time. They may also be manually deleted as shown below. Note that a reservation can not be deleted while there are jobs running in it.
予約は終了時間後に自動的に削除されます。以下に示すように、手動で削除することもできます。予約が実行されている間は予約を削除できないことに注意してください。

$ scontrol delete ReservationName=alan_6

NOTE: By default, when a reservation ends the reservation request will be removed from any pending jobs submitted to the reservation and will be put into a held state. Use the NO_HOLD_JOBS_AFTER_END reservation flag to let jobs run outside of the reservation after the reservation is gone.
注：デフォルトでは、予約が終了すると、予約に送信された保留中のジョブから予約リクエストが削除され、保留状態になります。NO_HOLD_JOBS_AFTER_END予約フラグを使用して、予約がなくなった後にジョブを予約外で実行できるようにします。

Overlapping Reservations

By default, reservations must not overlap. They must either include different nodes or operate at different times. If specific nodes are not specified when a reservation is created, Slurm will automatically select nodes to avoid overlap and ensure that the selected nodes are available when the reservation begins.
デフォルトでは、予約は重複してはなりません。それらは異なるノードを含むか、異なる時間に動作する必要があります。予約の作成時に特定のノードが指定されていない場合、Slurmは自動的にノードを選択して重複を回避し、選択されたノードが予約の開始時に確実に使用できるようにします。

There is very limited support for overlapping reservations with two specific modes of operation available. For ease of system maintenance, you can create a reservation with the "maint" flag that overlaps existing reservations. This permits an administrator to easily create a maintenance reservation for an entire cluster without needing to remove or reschedule pre-existing reservations. Users requesting access to one of these pre-existing reservations will be prevented from using resources that are also in this maintenance reservation. For example, users alan and brenda might have a reservation for some nodes daily from noon until 1PM. If there is a maintenance reservation for all nodes starting at 12:30PM, the only jobs they may start in their reservation would have to be completed by 12:30PM, when the maintenance reservation begins.
2つの特定の操作モードが利用可能な予約の重複に対するサポートは非常に限られています。システムメンテナンスを容易にするために、既存の予約と重複する「maint」フラグを使用して予約を作成できます。これにより、管理者は既存の予約を削除または再スケジュールする必要なく、クラスター全体の保守予約を簡単に作成できます。これらの既存の予約の1つへのアクセスを要求するユーザーは、このメンテナンス予約にあるリソースを使用できなくなります。たとえば、ユーザーalanとbrendaは、正午から午後1時まで毎日一部のノードを予約する場合があります。12:30 PMに開始するすべてのノードの保守予約がある場合、それらの予約で開始できる唯一のジョブは、保守予約が始まる12:30 PMまでに完了する必要があります。

The second exception operates in the same manner as a maintenance reservation except that is it not logged in the accounting system as nodes reserved for maintenance. It requires the use of the "overlap" flag when creating the second reservation. This might be used to ensure availability of resources for a specific user within a group having a reservation. Using the previous example of alan and brenda having a 10 node reservation for 60 minutes, we might want to reserve 4 nodes of that for for brenda during the first 30 minutes of the time period. In this case, the creation of one overlapping reservation (for a total of two reservations) may be simpler than creating three separate reservations, partly since the use of any reservation requires the job specification of the reservation name.
2番目の例外は、メンテナンス予約と同じように動作しますが、メンテナンス用に予約されたノードとしてアカウンティングシステムにログインしない点が異なります。2番目の予約を作成するときは、「overlap」フラグを使用する必要があります。これは、予約されているグループ内の特定のユーザーのリソースの可用性を確保するために使用される場合があります。前述のalanとbrendaが60分間10ノード予約を持っている例を使用すると、期間の最初の30分間に、その4ノードをbrenda用に予約することができます。この場合、1つの重複する予約（合計2つの予約）を作成する方が、3つの個別の予約を作成するよりも簡単です。

A six node reservation for both alan and brenda that lasts the full 60 minutes
60分間続くアランとブレンダの両方の6ノード予約
A four node reservation for brenda for the first 30 minutes
最初の30分間のブレンダの4ノード予約
A four node reservation for both alan and brenda that lasts for the final 30 minutes
最後の30分間続く、アランとブレンダ両方の4ノード予約

If the "maint" or "overlap" flag is used when creating reservations, one could create a reservation within a reservation within a third reservation. Note a reservation having a "maint" or "overlap" flag will not have resources removed from it by a subsequent reservation also having a "maint" or "overlap" flag, so nesting of reservations only works to a depth of two.
予約の作成時に「maint」または「overlap」フラグを使用すると、3番目の予約内の予約内に予約を作成できます。「maint」または「overlap」フラグを持つ予約は、「maint」または「overlap」フラグを持つ後続の予約によってリソースが削除されないため、予約のネストは深さ2までしか機能しないことに注意してください。

Reservations Floating Through Time

Slurm can be used to create an advanced reservation with a start time that remains a fixed period of time in the future. These reservation are not intended to run jobs, but to prevent long running jobs from being initiated on specific nodes. That node might be placed in a DRAINING state to prevent any new jobs from being started there. Alternately, an advanced reservation might be placed on the node to prevent jobs exceeding some specific time limit from being started. Attempts by users to make use of a reservation with a floating start time will be rejected. When ready to perform the maintenance, place the node in DRAINING state and delete the previously created advanced reservation.
Slurmを使用して、開始時刻が将来の一定期間のままになる事前予約を作成できます。これらの予約は、ジョブを実行するためのものではなく、特定のノードで長時間実行されるジョブが開始されるのを防ぐためのものです。そのノードがDRAINING状態になり、新しいジョブがそこで開始されないようにする場合があります。あるいは、特定の時間制限を超えるジョブが開始されないようにするために、事前予約がノードに配置される場合があります。開始時刻が変動する予約をユーザーが使用しようとすると、拒否されます。メンテナンスを実行する準備ができたら、ノードをDRAINING状態にして、以前に作成した事前予約を削除します。

Create the reservation by using the flag value of TIME_FLOAT and a start time that is relative to the current time (use the keyword now). The reservation duration should generally be a value which is large relative to typical job run times in order to not adversely impact backfill scheduling decisions. Alternately the reservation can have a specific end time, in which case the reservation's start time will increase through time until the reservation's end time is reached. When the current time passes the reservation end time then the reservation will be purged. In the example below, node tux8 is prevented from starting any jobs exceeding a 60 minute time limit. The duration of this reservation is 100 (minutes).
TIME_FLOATのフラグ値と現在の時刻に相対的な開始時刻を使用して予約を作成します（今すぐキーワードを使用）。バックフィルスケジューリングの決定に悪影響を及ぼさないように、予約期間は通常、一般的なジョブランタイムに比べて大きい値にする必要があります。または、予約に特定の終了時刻を設定することもできます。その場合、予約の開始時刻は、予約の終了時刻に達するまで増加します。現在の時刻が予約の終了時刻を過ぎると、予約は削除されます。以下の例では、ノードtux8は60分の時間制限を超えるジョブを開始できません。この予約の期間は100（分）です。

$ scontrol create reservation user=operator nodes=tux8 \
  starttime=now+60minutes duration=100 flags=time_float

Reservations that Replace Allocated Resources

Slurm can create an advanced reservation for which nodes which are allocated to jobs are automatically replaced with new idle nodes. The effect of this is to always maintain a constant size pool of resources. This is accomplished by using a "replace" flag as shown in the example below. This option is not supported for reservations of individual cores which span more than one node rather than full nodes (e.g. a 1 core reservation on node "tux1" will be moved if node "tux1" goes down, but a reservation containing 2 cores on node "tux1" and 3 cores on "tux2" will not be moved node "tux1" goes down).
Slurmは、ジョブに割り当てられているノードが自動的に新しいアイドルノードに置き換えられる事前予約を作成できます。これの効果は、リソースの一定サイズのプールを常に維持することです。これは、以下の例に示すように、「置換」フラグを使用することで実現されます。このオプションは、フルノードではなく複数のノードにまたがる個々のコアの予約ではサポートされていません（たとえば、ノード「tux1」がダウンした場合、ノード「tux1」の1コア予約は移動しますが、ノードの2コアを含む予約は移動します「tux1」と「tux2」の3つのコアは移動されません。ノード「tux1」はダウンします）。

$ scontrol create reservation starttime=now duration=60 \
  users=foo nodecnt=2 flags=replace
Reservation created: foo_82

$ scontrol show res
ReservationName=foo_82 StartTime=2014-11-20T16:21:11
   EndTime=2014-11-20T17:21:11 Duration=01:00:00
   Nodes=tux[0-1] NodeCnt=2 CoreCnt=12 Features=(null)
   PartitionName=debug Flags=REPLACE
   Users=jette Accounts=(null) Licenses=(null) State=ACTIVE

$ sbatch -n4 --reservation=foo_82 tmp
Submitted batch job 97

$ scontrol show res
ReservationName=foo_82 StartTime=2014-11-20T16:21:11
   EndTime=2014-11-20T17:21:11 Duration=01:00:00
   Nodes=tux[1-2] NodeCnt=2 CoreCnt=12 Features=(null)
   PartitionName=debug Flags=REPLACE
   Users=jette Accounts=(null) Licenses=(null) State=ACTIVE

$ sbatch -n4 --reservation=foo_82 tmp
Submitted batch job 98

$ scontrol show res
ReservationName=foo_82 StartTime=2014-11-20T16:21:11
   EndTime=2014-11-20T17:21:11 Duration=01:00:00
   Nodes=tux[2-3] NodeCnt=2 CoreCnt=12 Features=(null)
   PartitionName=debug Flags=REPLACE
   Users=jette Accounts=(null) Licenses=(null) State=ACTIVE

$ squeue
JOBID PARTITION  NAME  USER ST  TIME  NODES NODELIST(REASON)
   97     debug   tmp   foo  R  0:09      1 tux0
   98     debug   tmp   foo  R  0:07      1 tux1

Reservation Purging After Last Job

A reservation may be automatically purged after the last associated job completes. This is accomplished by using a "purge_comp" flag. Once the reservation has been created, it must be populated within 5 minutes of its start time or it will be purged before any jobs have been run.
最後に関連付けられたジョブが完了すると、予約が自動的に消去される場合があります。これは、「purge_comp」フラグを使用することによって実現されます。予約が作成されたら、開始時刻から5分以内に予約を入力する必要があります。そうしないと、ジョブが実行される前に削除されます。

Reservation Accounting

Jobs executed within a reservation are accounted for using the appropriate user and bank account. If resources within a reservation are not used, those resources will be accounted for as being used by all users or bank accounts associated with the reservation on an equal basis (e.g. if two users are eligible to use a reservation and neither does, each user will be reported to have used half of the reserved resources).
予約内で実行されたジョブは、適切なユーザーと銀行口座を使用して会計処理されます。予約内のリソースが使用されない場合、それらのリソースは、予約に関連付けられているすべてのユーザーまたは銀行口座によって平等に使用されていると見なされます（たとえば、2人のユーザーが予約を使用する資格があり、どちらも使用できない場合、各ユーザーは予約済みリソースの半分を使用したと報告されます）。

Prolog and Epilog

Slurm supports both a reservation prolog and epilog. They may be configured using the ResvProlog and ResvEpilog configuration parameters in the slurm.conf file. These scripts can be used to cancel jobs, modify partition configuration, etc.
Slurmは予約プロローグとエピローグの両方をサポートしています。これらは、slurm.confファイルのResvPrologおよびResvEpilog構成パラメーターを使用して構成できます。これらのスクリプトは、ジョブのキャンセル、パーティション構成の変更などに使用できます。

Future Work

Reservations made within a partition having gang scheduling assumes the highest level rather than the actual level of time-slicing when considering the initiation of jobs. This will prevent the initiation of some jobs which would complete execution before a reservation given fewer jobs to time-slice with.
ギャングスケジューリングを持つパーティション内で行われた予約は、ジョブの開始を検討する際に、タイムスライスの実際のレベルではなく最高レベルを想定します。これにより、予約する前に実行を完了し、タイムスライスするジョブが少なくなるジョブの開始が防止されます。

Last modified 23 September 2019