Advanced Resource Reservation Guide

Slurm has the ability to reserve resources for jobs being executed by select users and/or select bank accounts.
Slurmには、選択したユーザーや選択した銀行口座によって実行されるジョブ用にリソースを予約する機能があります。
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.
ノードまたはコアを含む予約は1つのパーティションに関連付けられており、複数のパーティションにまたがるリソースにまたがることはできません。
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のギャングスケジューラプラグインと互換性がないことに注意してください。

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.
コアまたはノードが予約されている場合、その予約を使用するジョブはそれらのリソースのみを使用でき（この動作はFLEXフラグを使用して変更できます）、他のジョブはそれらのリソースを使用できません。
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.
これにより、作成されたすべての事前予約にライセンスを明示的に配置する必要がなくなります。

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

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.
予約の一般的な操作モードの1つは、システムのダウンタイムのために特定の時間にコンピューター全体を予約することです。
The example below shows the creation of a full-system reservation at 16:00 hours on 6 February and lasting for 120 minutes.
以下の例は、2月6日の16:00にフルシステム予約を作成し、120分間継続することを示しています。
The "maint" flag is used to identify the reservation for accounting purposes as system maintenance.
「maint」フラグは、システム保守としてアカウンティング目的の予約を識別するために使用されます。
The "ignore_jobs" flag is used to indicate that we can ignore currently running jobs when creating this reservation.
「ignore_jobs」フラグは、この予約を作成するときに現在実行中のジョブを無視できることを示すために使用されます。
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.
予約時間が近づくと、予約時間までに完了できるジョブのみが開始されます。

$ 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.
システムリソースを使用するために実際のライセンスは必要ない場合がありますが、Slurmライセンスを使用して、リソースが利用できないときにリソースが必要なジョブが開始されないようにすることができます。
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".
以下の例では、「lustre」という名前の1000ライセンスの予約を作成します。
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.
このクラスターに合計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.
次の例は、デフォルトのSlurmパーティションで正午から毎日60分の期間で10個のノードを予約することです。
The reservation will be available only to users "alan" and "brenda".
予約は「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.
次の例は、今日の正午から60分間で100GBのバーストバッファスペースを予約することです。
The reservation will be available only to users "alan" and "brenda".
予約は「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).
これは、作成されたブロックのトポロジーに関する制限的なルール（ハードウェアの制約やSlurmの構成による）のため、BlueGeneシステムにとって特に重要です。
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システム上に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.
予約作成リクエストでは、ノードを選択するパーティション、または選択したすべてのノードに含める必要のある1つの機能を特定することもできます。

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.
この名前は、最初のユーザー名またはアカウント名と数字のサフィックスに基づいてSlurmによって自動的に生成されます。
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.
予約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.
予約は、必要に応じてユーザーrootによって変更できます。
For example their duration could be altered or the users granted access changed as shown below:
たとえば、以下に示すように、期間を変更したり、アクセスを許可したユーザーを変更したりできます。

$ 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.
利用可能な2つの特定の操作モードで、重複する予約のサポートは非常に限られています。
For ease of system maintenance, you can create a reservation with the "maint" flag that overlaps existing reservations.
システムのメンテナンスを容易にするために、既存の予約と重複する「maint」フラグを使用して予約を作成できます。
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.
たとえば、ユーザーalanとbrendaは、毎日正午から午後1時まで一部のノードを予約している場合があります。
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.
午後12時30分に開始するすべてのノードの保守予約がある場合、予約で開始できるジョブは、保守予約が開始される午後12時30分までに完了する必要があります。

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.
2番目の例外は、メンテナンス用に予約されたノードとしてアカウンティングシステムに記録されないことを除いて、メンテナンス予約と同じように動作します。
It requires the use of the "overlap" flag when creating the second reservation.
2番目の予約を作成するときは、「重なり」フラグを使用する必要があります。
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.
60分間に10ノードの予約があるalanとbrendaの前の例を使用すると、期間の最初の30分間に、その4ノードをbrenda用に予約したい場合があります。
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.
この場合、1つの重複する予約（合計2つの予約）の作成は、3つの個別の予約を作成するよりも簡単な場合があります。これは、予約を使用するには予約名のジョブ指定が必要なためです。

A six node reservation for both alan and brenda that lasts the full 60 minutes
アランとブレンダの両方の6ノード予約で60分続きます
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.
予約の作成時に「maint」または「overlap」フラグを使用すると、3番目の予約内の予約内に予約を作成できます。
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」フラグを持つ予約では、「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.
Slurmを使用して、開始時刻が将来一定の期間のままである事前予約を作成できます。
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.
そのノードは、新しいジョブがそこで開始されないようにするために、DRAINING状態になる可能性があります。
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.
メンテナンスを実行する準備ができたら、ノードを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).
TIME_FLOATのフラグ値と、現在の時刻を基準にした開始時刻を使用して予約を作成します（キーワード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.
以下の例では、ノードtux8は、60分の制限時間を超えてジョブを開始できません。
The duration of this reservation is 100 (minutes).
この予約の期間は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.
Slurmは、ジョブに割り当てられたノードが新しいアイドルノードに自動的に置き換えられる事前予約を作成できます。
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).
このオプションは、フルノードではなく複数のノードにまたがる個々のコアの予約ではサポートされていません（たとえば、ノード「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.
これは、「purge_comp」フラグを使用して実行されます。
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.
予約が作成されたら、開始時刻から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.
Slurmは、予約プロローグとエピローグの両方をサポートしています。
They may be configured using the ResvProlog and ResvEpilog configuration parameters in the slurm.conf file.
これらは、slurm.confファイルのResvPrologおよびResvEpilog構成パラメーターを使用して構成できます。
These scripts can be used to cancel jobs, modify partition configuration, etc.
これらのスクリプトは、ジョブのキャンセル、パーティション構成の変更などに使用できます。

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