forked from jbarber/maui-admin-guide
-
Notifications
You must be signed in to change notification settings - Fork 0
/
7.1.5managingreservations.html
723 lines (478 loc) · 49.8 KB
/
7.1.5managingreservations.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy for Linux (vers 25 March 2009), see www.w3.org">
<title></title>
</head>
<body>
<div class="sright">
<div class="sub-content-head">
Maui Scheduler
</div>
<div id="sub-content-rpt" class="sub-content-rpt">
<div class="tab-container docs" id="tab-container">
<div class="topNav">
<div class="docsSearch"></div>
<div class="navIcons topIcons">
<a href="index.html"><img src="home.png" title="Home" alt="Home" border="0"></a> <a href="7.1advancereservations.html"><img src="upArrow.png" title="Up" alt="Up" border="0"></a> <a href="7.1.4reservationpolicies.html"><img src="prevArrow.png" title="Previous" alt="Previous" border="0"></a> <a href="7.1.6userreservations.html"><img src="nextArrow.png" title="Next" alt="Next" border="0"></a>
</div>
<h1>7.1.5 Configuring and Managing Reservations</h1><!--<blockquote>-->
All reservations, whether they be administrative or standing, possess many similar traits.
<p><img src="logo1.gif" height="24"> The <a href="http://docs.adaptivecomputing.com/mcm/index.html">Moab Cluster Manager</a><sup>TM</sup> provides a graphical interface to <a href="http://docs.adaptivecomputing.com/mcm/reservationMgmt.html">view and control reservations</a>.</p>
<h2>7.1.5.1 Reservation Attributes</h2>All reservations possess a timeframe of activity, an access control list, and a list of resources to be reserved. Additionally, reservations may also possess a number of extension attributes including epilog/prolog specification, reservation ownership and accountability attributes, and special flags which modify the behavior of the reservation. <!--<blockquote>-->
<h3>7.1.5.1.1 Start/End Time</h3>All reservations possess a start and an end time which define the reservation's <i>active</i> time. During this active time, the resources within the reservation may only be used as specified by the reservation ACL. This active time may be specified as either a start/end pair or a start/duration pair. Reservations exist and are visible from the time they are created until the active time ends at which point they are automatically removed.
<h3>7.1.5.1.2 Access Control List (ACL)</h3>For a reservation to be useful, it must be able to limit who or what can access the resources it has reserved. This is handled by way of an access control list, or ACL.
<h3>7.1.5.1.3 Resources</h3>When specifying which resources to reserve, the administrator has a number of options. These options allow control over how many resources are reserved and where they are reserved at. The following reservation attributes allow the administrator to define resources
<h2>Task Description</h2>
<p>A key concept of reservations is the idea of a task. The scheduler uses the task concept extensively for its job and reservation management. A task is simply an atomic collection of resources, such as processors, memory, or local disk, which must be found on the same node. For example, if a task requires 4 processors and 2 GB of memory, the scheduler must find all processors AND memory on the same node; it cannot allocate 3 processors and 1 GB on one node and 1 processor and 1 GB of memory on another node to satisfy this task. Tasks constrain how the scheduler must collect resources for use in a standing reservation, however, they do not constrain the way in which the scheduler makes these cumulative resources available to jobs. A job can use the resources covered by an accessible reservation in whatever way it needs. If reservation X allocated 6 tasks with 2 processors and 512 MB of memory each, it could support job Y which requires 10 tasks of 1 processor and 128 MB of memory or job Z which requires 2 tasks of 4 processors and 1 GB of memory each. The task constraints used to acquire a reservation's resources are completely transparent to a job requesting use of these resources.</p>
<h2>Taskcount</h2>
<p>Using the task description, the taskcount attribute defines how many tasks must be allocated to satisfy the reservation request. To create a reservation, a taskcount and/or a hostlist must be specified.</p>
<h2>Hostlist</h2>
<p>A hostlist constrains the set of resource which are available to a reservation. If no taskcount is specified, the reservation will attempt to reserve one task on each of the listed resources. If a taskcount is specified which requests fewer resources than listed in the hostlist, the scheduler will reserve only the number of tasks from the hostlist specified by the taskcount attribute. If a taskcount is specified which requests more resources than listed in the hostlist, the scheduler will reserve the hostlist nodes first and then seek additional resources outside of this list.</p>
<h3>7.1.5.1.4 Flags</h3>Reservation flags allow specification of special reservation attributes or behaviors. The following flags are supported:<br>
<table border="1" width="100%" nosave="">
<tbody>
<tr>
<td><b>Flag Name</b></td>
<td><b>Description</b></td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td><b>BESTEFFORT</b></td>
<td>N/A</td>
</tr>
<tr>
<td><b>BYNAME</b></td>
<td>reservation will only allow access to jobs which meet reservation ACL's <i>and</i> explicitly request the resources of this reservation using the job <b>ADVRES</b> flag</td>
</tr>
<tr>
<td><b>OWNERPREEMPT</b></td>
<td>job's by the reservation owner are allowed to preempt non-owner jobs using reservation resources</td>
</tr>
<tr>
<td><b>PREEMPTEE</b></td>
<td>N/A</td>
</tr>
<tr>
<td valign="top"><b>SPACEFLEX</b><br></td>
<td valign="top">reservation is allowed to move from host to host over time in an attempt to optimize resource utilization*<br></td>
</tr>
</tbody>
</table><br>
<table class="note">
<tbody>
<tr>
<td class="noteIMG"><img src="note.png" title="Note" alt="Note"></td>
<td class="noteDetail">Reservations must now explicitly request the ability to 'float' for optimization purposes by using the <b>SPACEFLEX</b> flag. Previous versions enabled the 'float' behavior by default if a hostlist was not specified.</td>
</tr>
</tbody>
</table><!--</blockquote>-->
<h2>7.1.5.2 Configuring Standing Reservations</h2>
<p>Standing reservations allow resources to be dedicated for particular uses. This dedication can be configured to be permanent or periodic, recurring at a regular time of day and/or time of week. There is extensive applicability of standing reservations for everything from daily dedicated job runs to improved use of resources on weekends. All standing reservation attributes are specified via the <a href="a.fparameters.html#SRCFG">SRCFG</a> parameter using the attributes listed in the table below.</p>
<table border="2">
<tr>
<td><b>Attribute</b></td>
<td><b>Format</b></td>
<td><b>Default</b></td>
<td><b>Description</b></td>
<td><b>Example</b></td>
</tr>
<tr>
<td><a name="ACCESS" id="ACCESS"></a><b>ACCESS</b></td>
<td><b>DEDICATED</b> or <b>SHARED</b></td>
<td><b>DEDICATED</b></td>
<td>If set to <b>SHARED</b>, allows a standing reservation to utilize resources already allocated to other non-job reservations. Otherwise, these other reservations will block resource access.</td>
<td>
<tt>SRCFG[test] ACCESS=SHARED</tt>
<p>(Standing reservation <tt>test</tt> may access resources allocated to existing standing and administrative reservations)</p>
</td>
</tr>
<tr>
<td><a name="ACCOUNTLIST" id="ACCOUNTLIST"></a><b>ACCOUNTLIST</b></td>
<td>list of valid, comma delimited account names</td>
<td>[NONE]</td>
<td>specifies that jobs with the associated accounts may use the resources contained within this reservation</td>
<td>
<tt>SRCFG[test] ACCOUNTLIST=ops,staff</tt>
<p>(jobs using the account <tt>ops</tt> or <tt>staff</tt> are granted access to the resources in standing reservation <tt>test</tt>)</p>
</td>
</tr>
<tr>
<td><a name="CHARGEACCOUNT" id="CHARGEACCOUNT"></a><b>CHARGEACCOUNT</b></td>
<td>any valid accountname</td>
<td>[NONE]</td>
<td>specifies the account to which maui will charge all idle cycles within the reservation (via the allocation manager)</td>
<td>
<tt>SRCFG[test] CHARGEACCOUNT=jupiter</tt>
<p>(The scheduler will charge all idle cycles within reservations supporting standing reservation <tt>test</tt> to account <tt>jupiter</tt>)</p>
</td>
</tr>
<tr>
<td><a name="CLASSLIST" id="CLASSLIST"></a><b>CLASSLIST</b></td>
<td>list of valid, comma delimited class names</td>
<td>[NONE]</td>
<td>specifies that jobs requiring any of these classes may use the resources contained within this reservation</td>
<td>
<tt>SRCFG[test] CLASSLIST=interactive</tt>
<p>(The scheduler will allow all jobs requiring any of the classes listed access to the resources reserved by standing reservation <tt>test</tt>)</p>
</td>
</tr>
<tr>
<td><a name="DAYS" id="DAYS"></a><b>DAYS</b></td>
<td>one or more of the following (comma delimited)<br>
<b>Mon,</b> <b>Tue,</b> <b>Wed</b>, <b>Thu,</b> <b>Fri,</b> <b>Sat,</b> <b>Sun</b>,<br>
or <b>[ALL]</b></td>
<td><b>[ALL]</b></td>
<td>specifies which days of the week the standing reservation will be active</td>
<td>
<tt>SRCFG[test] DAYS=Mon,Tue,Wed,Thu,Fri</tt>
<p>(standing reservation <tt>test</tt> will be active on Monday thru Friday)</p>
</td>
</tr>
<tr>
<td><a name="DEPTH" id="DEPTH"></a><b>DEPTH</b></td>
<td><INTEGER></td>
<td>2</td>
<td>specifies the number of standing reservations which will be created (one per period) See <b>PERIOD</b>)</td>
<td>
<tt>SRCFG[test] PERIOD=DAY DEPTH=7</tt>
<p>(specifies that reservations will be created for standing reservation <tt>test</tt> for today, and the next 6 days)</p>
</td>
</tr>
<tr>
<td><a name="ENDTIME" id="ENDTIME"></a><b>ENDTIME</b></td>
<td>[[[DD:]HH:]MM:]SS</td>
<td>24:00:00</td>
<td>specifies the time of day the standing reservation period ends (end of day or end of week depending on <b>PERIOD</b>) <b>NOTE:</b> In Maui 3.2 and earlier, <i>week</i> based reservations required specification of the <b>WSTARTTIME</b> and <b>WENDTIME</b> attributes to indicate reservation start and end offsets.</td>
<td>
<pre>
SRCFG[test] STARTTIME=8:00:00
SRCFG[test] ENDTIME=17:00:00
SRCFG[test] PERIOD=DAY
</pre>
<p>(standing reservation <tt>test</tt> is active from 8:00 AM until 5:00 PM)</p>
</td>
</tr>
<tr>
<td><a name="FLAGS" id="FLAGS"></a><b>FLAGS</b></td>
<td>comma delimited list of zero or more of the following flags:<br>
<b>SINGLEUSE</b>, <b>BYNAME</b>, <b>OWNERPREEMPT</b>, <b>PREEMPTEE</b>, <b>TIMEFLEX</b>, or <b>FORCE</b></td>
<td>[NONE]</td>
<td>specifies special reservation attributes. See <a href="7.1.5managingreservations.html">7.1.5.1.4 Managing Reservations - Flags</a> for details.</td>
<td>
<tt>SRCFG[test] FLAGS=BYNAME</tt>
<p>(Jobs may only access the resources within this reservation if they explicitly request the reservation <i>by name</i>)</p>
</td>
</tr>
<tr>
<td><a name="GROUPLIST" id="GROUPLIST"></a><b>GROUPLIST</b></td>
<td>one or more comma delimited group names</td>
<td>[ALL]</td>
<td>specifies the groups which will be allowed access to this standing reservation</td>
<td>
<tt>SRCFG[test] GROUPLIST=staff,ops,special</tt><br>
<tt>SRCFG[test] CLASSLIST=interactive</tt>
<p>(The scheduler will allow jobs with the listed group ID's or which request the job class <tt>interactive</tt> to use the resources covered by the standing reservation.)</p>
</td>
</tr>
<tr>
<td><a name="HOSTLIST" id="HOSTLIST"></a><b>HOSTLIST</b></td>
<td>one or more comma delimited host names or host expressions</td>
<td>[ALL]</td>
<td>specifies the set of host from which the scheduler can search for resources to satisfy the reservation. If <b>TASKCOUNT</b> is also specified, only <b>TASKCOUNT</b> tasks will be reserved. Otherwise, all hosts listed will be reserved.</td>
<td>
<pre>
SRCFG[test] HOSTLIST=node001,node002,node003
SRCFG[test] RESOURCES=PROCS:2;MEM:512
SRCFG[test] TASKCOUNT=2
</pre>
<p>(The scheduler will reserve a total of 2 tasks - with 2 processors and 512 MB each, using resources located on node001, node002, and/or node003)</p>
</td>
</tr>
<tr>
<td><a name="JOBATTRLIST" id="JOBATTRLIST"></a><b>JOBATTRLIST</b></td>
<td>comma delimited list of one or more of the following job attributes<br>
<b>PREEMPTEE</b></td>
<td>[NONE]</td>
<td>specifies job attributes which will grant a job access to the reservation</td>
<td>
<tt>SRCFG[test] JOBATTRLIST=PREEMPTEE</tt>
<p>(Preemptible jobs can access the resources reserved within this reservation)</p>
</td>
</tr>
<tr>
<td><a name="NODEFEATURES" id="NODEFEATURES"></a><b>NODEFEATURES</b></td>
<td>comma delimited list of node features</td>
<td>[NONE]</td>
<td>specifies the required node features for nodes which will be part of the standing reservation</td>
<td>
<tt>SRCFG[test] NODEFEATURES=wide,fddi</tt>
<p>(all nodes allocated to the standing reservation must have both the <tt>wide</tt> and <tt>fddi</tt> node attributes)</p>
</td>
</tr>
<tr>
<td><a name="OWNER" id="OWNER"></a><b>OWNER</b></td>
<td><CREDTYPE>:<CREDID> where <CREDTYPE> is one of <b>USER</b>, <b>GROUP</b>, <b>ACCOUNT</b>, <b>QOS</b>, or <b>CLASS</b> and <CREDTYPE> is a valid credential id of that type.</td>
<td>[NONE]</td>
<td>specifies the owner of the reservation</td>
<td>
<tt>SRCFG[test] OWNER=USER:tom</tt>
<p>(user <tt>tom</tt> <i>owns</i> the reservation and may be granted special privileges associated with that ownership.)</p>
</td>
</tr>
<tr>
<td><a name="PARTITION" id="PARTITION"></a><b>PARTITION</b></td>
<td>a valid partition name</td>
<td>[ALL]</td>
<td>specifies the partition in which the standing reservation should be created</td>
<td>
<tt>SRCFG[test] PARTITION=OLD</tt>
<p>(The standing reservation will only select resources from partition <tt>OLD</tt>)</p>
</td>
</tr>
<tr>
<td><a name="PERIOD" id="PERIOD"></a><b>PERIOD</b></td>
<td>one of <b>DAY</b>, <b>WEEK</b>, or <b>INFINITY</b></td>
<td><b>DAY</b></td>
<td>specifies the <tt>period</tt> of the standing reservation</td>
<td>
<tt>SRCFG[test] PERIOD=WEEK</tt>
<p>(each standing reservation covers a one week period)</p>
</td>
</tr>
<tr>
<td><a name="PRIORITY" id="PRIORITY"></a><b>PRIORITY</b></td>
<td><INTEGER></td>
<td><b>0</b></td>
<td>specifies the <tt>priority</tt> of the standing reservation</td>
<td></td>
</tr>
<tr>
<td><a name="QOSLIST" id="QOSLIST"></a><b>QOSLIST</b></td>
<td>zero or more valid, comma delimited QOS names</td>
<td>[NONE]</td>
<td>specifies that jobs with the listed QOS names can access the reserved resources</td>
<td>
<tt>SRCFG[test] QOSLIST=hi,low,special</tt>
<p>(The scheduler will allow jobs using the listed QOS's access to the reserved resources)</p>
</td>
</tr>
<tr>
<td><a name="RESOURCES" id="RESOURCES"></a><b>RESOURCES</b></td>
<td>semicolon delimited <ATTR>=<VALUE> pairs where <ATTR> may be one of <b>PROCS</b>, <b>MEM</b>, <b>SWAP</b>, or <b>DISK</b></td>
<td>PROCS=-1 (All processors available on node)</td>
<td>
specifies what resources constitute a single standing reservation task. (each task must be able to obtain all of its resources as an atomic unit on a single node) Supported resources currently include the following:
<p>PROCS (number of processors)<br>
MEM (real memory in MB)<br>
DISK (local disk in MB)<br>
SWAP (virtual memory in MB)</p>
</td>
<td>
<tt>SRCFG[test] RESOURCES=PROCS:1;MEM:512</tt>
<p>(each standing reservation task will reserve one processor and 512 MB of real memory)</p>
</td>
</tr>
<tr>
<td><a name="STARTTIME" id="STARTTIME"></a><b>STARTTIME</b></td>
<td>[[[DD:]HH:]MM:]SS</td>
<td>00:00:00:00 (midnight)</td>
<td>specifies the time of day/week the standing reservation becomes active. Whether this indicated a time of day or time of week depends on the setting of <b>SRPERIOD</b> <b>NOTE:</b> In Maui 3.2 and earlier, <i>week</i> based reservations required specification of the <b>WSTARTTIME</b> and <b>WENDTIME</b> attributes to indicate reservation start and end offsets.</td>
<td>
<tt>SRCFG[test] STARTTIME=08:00:00</tt><br>
<tt>SRCFG[test] ENDTIME=17:00:00</tt> <tt>SRCFG[test] PERIOD=DAY</tt>
<p>(The standing reservation will be active from 8:00 AM until 5:00 PM each day)</p>
</td>
</tr>
<tr>
<td><a name="TASKCOUNT" id="TASKCOUNT"></a><b>TASKCOUNT</b></td>
<td><INTEGER></td>
<td>0 (unlimited tasks)</td>
<td>specifies how may tasks should be reserved for the reservation</td>
<td>
<tt>SRCFG[test] RESOURCES=PROCS:1;MEM:256</tt><br>
<tt>SRCFG[test] TASKCOUNT=16</tt>
<p>(standing reservation <tt>test</tt> will reserve 16 tasks worth of resources, in this case, 16 procs and 4 GB of real memory)</p>
</td>
</tr>
<tr>
<td><a name="TIMELIMIT" id="TIMELIMIT"></a><b>TIMELIMIT</b></td>
<td>[[[DD:]HH:]MM:]SS</td>
<td>-1 (no time based access)</td>
<td>specifies the maximum allowed overlap between a the standing reservation and a job requesting resource access</td>
<td>
<tt>SRCFG[test] TIMELIMIT=1:00:00</tt>
<p>(The scheduler will allow jobs to access up to one hour of resources in the standing reservation)</p>
</td>
</tr>
<tr>
<td><a name="TIMELOGIC" id="TIMELOGIC"></a><b>TIMELOGIC</b><br></td>
<td><b>AND</b> or <b>OR</b></td>
<td><b>OR</b></td>
<td>specifies how TIMELIMIT access status will be combined with other standing reservation access methods to determine job access. If TIMELOGIC is set to OR, a job is granted access to the reserved resources if it meets the TIMELIMIT criteria or any other access criteria (i.e., USERLIST) If TIMELOGIC is set to AND, a job is granted access to the reserved resources only if it meets the TIMELIMIT criteria and at least one other access criteria (NOTE: <b>TIMELOGIC</b> is not supported in Maui 3.2.6 and later. Instead, the <i>required</i> ACL marker, '<b>*</b>', should be used. Equivalent functionality can be enabled by setting something like the following <tt>SRCFG[special] TIMELIMIT=1:00:00*</tt></td>
<td><tt>SRCFG[special] TIMELIMIT=1:00:00</tt><br>
<tt>SRCFG[special] TIMELOGIC=AND</tt><br>
<tt>SRCFG[special] QOSLIST=high low special-</tt><br>
<tt>SRCFG[special] ACCCOUNTLIST=!projectX,!Y</tt><br></td>
</tr>
<tr>
<td><a name="TPN" id="TPN"><b>TPN</b> (Tasks Per Node)</a></td>
<td><INTEGER></td>
<td>0 (no TPN constraint)</td>
<td>specifies the minimum number of tasks per node which must be available on eligible nodes.</td>
<td>
<tt>SRCFG[2] TPN=4</tt><br>
<tt>SRCFG[2] RESOURCES=PROCS:2;MEM:256</tt>
<p>(Maui must locate at least 4 tasks on each node that is to be part of the reservation. That is, each node included in standing reservation '2' must have at least 8 processors and 1 GB of memory available)</p>
</td>
</tr>
<tr>
<td><a name="TRIGGER" id="TRIGGER"><b>TRIGGER</b></a></td>
<td><ETYPE>[+<OFFSET>][@<THRESHOLD>];<ATYPE>[@<ADATA>]<br>
where<br>
<b>ETYPE</b> is one of <b>create</b>, <b>start</b>, <b>end</b>, or <b>minload</b><br>
<b>OFFSET</b> is a relative time specified in [[HH:]MM:]SS format<br>
<b>THRESHOLD</b> is a floating point value<br>
<b>ATYPE</b> is one of <b>cancel</b>, <b>exec</b>, or <b>submit</b><br>
<b>ADATA</b> is a context sensitive string indicating an executable, submit script, or other action data</td>
<td>N/A</td>
<td>specifies event triggers to be launched by the scheduler under the scheduler's id. These triggers can be used to conditionally cancel reservations or launch various actions at specified event offsets. NOTE: This feature is only available in Moab 4.0 and higher.</td>
<td>
<tt>SRCFG[fast] TRIGGER=start+5:00:00:exec@/usr/local/domail.pl</tt><br>
<p>(Maui will launch the <tt>domail.pl</tt> script 5 hours after any <tt>fast</tt> reservation is started.</p>
</td>
</tr>
<tr>
<td><a name="USERLIST" id="USERLIST"></a><b>USERLIST</b></td>
<td>comma delimited list of users</td>
<td>[NONE]</td>
<td>specifies which users have access to the resources reserved by this reservation</td>
<td>
<tt>SRCFG[test] USERLIST=bob,joe,mary</tt>
<p>(users <tt>bob</tt>, <tt>joe</tt> and <tt>mary</tt> can all access the resources reserved within this reservation)</p>
</td>
</tr>
</table><!--<blockquote>-->
<h3>7.1.5.2.1 Standing Reservation Overview</h3>A standing reservation is similar to a normal administrative reservation in that it also places an access control list on a specified set of resources. Resources are specified on a <i>per-task</i> basis and currently include processors, local disk, real memory, and swap. The access control list supported for standing reservations includes users, groups, accounts, job classes, and QOS levels. Standing reservations can be configured to be permanent or periodic on a daily or weekly basis and can accept a daily or weekly start and end time. Regardless of whether a standing reservation is permanent or recurs on a daily or weekly basis, they are enforced using a series of reservations, extending a number of <i>periods</i> into the future as controlled by the <strong>DEPTH</strong> attribute of the <a href="a.fparameters.html#SRCFG">SRCFG</a> parameter.
<p>The examples below demonstrate possibles configuration specified with the <strong>SRCFG</strong> parameter.</p>
<h2>Example 1 Basic Business Hour Standing Reservation</h2>
<pre>
-----
# maui.cfg
SRCFG[interactive] TASKCOUNT=6 RESOURCES=PROCS:1,MEM:512
SRCFG[interactive] PERIOD=DAY DAYS=MON,TUE,WED,THU,FRI
SRCFG[interactive] STARTTIME=9:00:00 ENDTIME=17:00:00
SRCFG[interactive] CLASSLIST=interactive
-----
</pre>
<p><img src="note.png" height="24" width="20">when using the <b>SRCFG</b> parameter, attribute lists must be delimited using the <i>comma</i>, <i>pipe</i>, or <i>colon</i> characters (i.e., ',', '|', or ':'), they cannot be space delimited. For example, to specify a multi-class ACL, specify '<tt>SRCFG[test] CLASSLIST=classA,classB</tt>'.</p>
<p><img src="note.png" height="24" width="20">only one <b>STARTTIME</b> and one <b>ENDTIME</b> value can be specified per reservation. If varied start and end times are desired throughout the week, complementary standing reservations should be created. For example, to establish a reservation from 8:00 PM until 6:00 AM the next day during business days, two reservations should be created, one from 8:00 PM until midnight, and the other from midnight until 6:00 AM. Jobs can run across reservation boundaries allowing these two reservations function a single reservation which spans the night.<br></p>
<p>The above example fully specifies a reservation including the quantity of resources requested using the <strong>TASKCOUNT</strong> and <strong>RESOURCES</strong> attributes. In all cases, resources are allocated to a reservation in units called <i>tasks</i> where a task is a collection of resources which must be allocated together on a single node. The <strong>TASKCOUNT</strong> attribute specifies the number of these tasks which should be reserved by the reservation. In conjunction with this attribute, the <strong>RESOURCES</strong> attribute defines the reservation task by indicating what resources must be included in each task. In this case, the scheduler must locate and reserve 1 processor and 512 MB of memory together on the same node for each task requested.</p>
<p>As mentioned previously, a standing reservation reserves resources over a given timeframe. The <strong>PERIOD</strong> attribute may be set to a value of <strong>DAY</strong>, <strong>WEEK</strong>, or <strong>INFINITE</strong> to indicate the period over which this reservation should recur. If not specified, a standing reservation recurs on a daily basis. If a standing reservation is configured to recur daily, the attribute <strong>DAYS</strong> may be specified to indicate which days of the week the reservation should exist. This attribute takes a comma-delimited list of days where each day is specified as the first three letters of the day in all capital letters, i.e. <strong>MON</strong> or <strong>FRI</strong>. The above example specifies that this reservation is periodic on a daily basis and should only exist on business days.</p>
<p>The time of day during which the requested tasks are to be reserved is specified using the <strong>STARTTIME</strong> and <strong>ENDTIME</strong> attributes. These attributes are specified in standard military time HH:MM:SS format and both <strong>STARTTIME</strong> and <strong>ENDTIME</strong> specification is optional defaulting to midnight at the beginning and end of the day respectively. In the above example, resources will be reserved from 9:00 AM until 5:00 PM on business days.</p>
<p>The final aspect of any reservation is the access control list indicating who or what can utilize the reserved resources. In the above example, <strong>CLASSLIST</strong> attribute is used to indicate that jobs requesting the class <tt>interactive</tt> should be allowed to use this reservation.</p>
<h3>7.1.5.2.2 Specifying Reservation Resources</h3>In most cases, only a small subset of standing reservation attributes must be specified in any given case. For example, by default, <b>RESOURCES</b> is set to <b><tt>PROCS=-1</tt></b> which indicates that each task should reserve all of the processors on the node on which it is located. This, in essence, creates a <i>one task equals one node</i> mapping. In many cases, particularly on uniprocessor systems, this default behavior may be easiest to work with. However, in SMP environments, the <b>RESOURCES</b> attribute provides a powerful means of specifying an exact, multi-dimensional resource set.
<p><img src="note.png" height="24" width="20">An examination of the parameters documentation will show that the default value of <b>PERIOD</b> is <b>DAYS</b>. Thus, specifying this parameter in the example above was unnecessary. It was used only to introduce this parameter and indicate that other options exist beyond daily standing reservations.</p>
<h2>Example 2: Host Constrained Standing Reservation</h2>Although example 1 did specify a quantity of resources to reserve, it did not specify where the needed tasks were to be located. If this information is not specified, The scheduler will attempt to locate the needed resources anywhere it can find them. The example 1 reservation will essentially <i>float</i> to hosts where the needed resources can be found.
<p>If a site wanted to constrain a reservation to a subset of available resources, this could be accomplished using the <strong>HOSTLIST</strong> attribute. The <strong>HOSTLIST</strong> attribute is specified as a comma-separated list of hostnames and constrains the scheduler to only select tasks from the specified list. This attribute can exactly specify hosts or specify them using host regular expressions. The example below demonstrates a possible use of the <strong>HOSTLIST</strong> attribute.</p>
<pre>
-----
# maui.cfg
SRCFG[interactive] DAYS=MON,TUE,WED,THU,FRI
SRCFG[interactive] PERIOD=DAY
SRCFG[interactive] STARTTIME=10:00:00 ENDTIME=15:00:00
SRCFG[interactive] RESOURCES=PROCS:2,MEM:256
SRCFG[interactive] HOSTLIST=node001,node002,node005,node020
SRCFG[interactive] TASKCOUNT=6
SRCFG[interactive] CLASSLIST=interactive
-----
</pre>
<p>The example is now a bit more complex. Note that the <strong>HOSTLIST</strong> attribute specifies a non-contiguous list of hosts. Any combination of hosts may be specified and hosts may be specified in any order. In this example, the <strong>TASKCOUNT</strong> attribute is also specified. These two attributes both apply constraints on the scheduler with <strong>HOSTLIST</strong> specifying where the tasks can be located and <strong>TASKCOUNT</strong> indicating how many total tasks may be allocated. In the example above, 6 tasks are requested but only 4 hosts are specified. To handle this, if adequate resources are available, the scheduler may attempt to allocate more than one task per host. For example, assume that each host is a quad-processor system with 1 GB of memory. In such a case, the scheduler could allocated up to two tasks per host and even satisfy the <strong>TASKCOUNT</strong> constraint without using all of the hosts in the hostlist.</p>
<p><img src="note.png" height="24" width="20">It is important to note that even if there is a one to one mapping between the value of <b>TASKCOUNT</b> and the number of hosts in <b>HOSTLIST</b> this does not necessarily mean that the scheduler will place one task on each host. If, for example, node001 and node002 were 8 processor SMP hosts with 1 GB of memory, the scheduler could locate up to 4 tasks on each of these hosts fully satisfying the reservation taskcount without even partially using the remaining hosts. (The scheduler will place tasks on hosts according to the policy specified with the <a href="a.fparameters.html#NODEALLOCATIONPOLICY">NODEALLOCATIONPOLICY</a> parameter.) If the hostlist provides more resources than what is required by the reservation as specified via <b>TASKCOUNT</b>, the scheduler will simply select the needed resources within the set of hosts listed.</p>
<h3>7.1.5.2.3 Enforcing Policies Via Multiple Reservations</h3>
<p>Single reservations enable multiple capabilities. Combinations of reservations can further extend a site's capabilities to impose specific policies.</p>
<h4>Example 3: Reservation Stacking</h4>
<p>If <b>HOSTLIST</b> is specified but <b>TASKCOUNT</b> is not, the scheduler will pack as many tasks as possible onto <i>all</i> of the listed hosts. For example, assume the site added a second standing reservation named <i>debug</i> to its configuration which reserved resources for use by certain members of its staff using the configuration below:</p>
<pre>
-----
# maui.cfg
SRCFG[interactive] DAYS=MON,TUE,WED,THU,FRI
SRCFG[interactive] PERIOD=DAY
SRCFG[interactive] STARTTIME=10:00:00 ENDTIME=15:00:00
SRCFG[interactive] RESOURCES=PROCS:2,MEM:256
SRCFG[interactive] HOSTLIST=node001,node002,node005,node020
SRCFG[interactive] TASKCOUNT=6
SRCFG[interactive] CLASSLIST=interactive
SRCFG[debug] HOSTLIST=node001,node002,node003,node004
SRCFG[debug] USERLIST=helpdesk
SRCFG[debug] GROUPLIST=operations,sysadmin
SRCFG[debug] PERIOD=INFINITY
-----
</pre>
<p>The new standing reservation is quite simple. Since <b>RESOURCES</b> is not specified, it will allocate all processors on each host that is allocated. Since <b>TASKCOUNT</b> is not specified, it will allocate every host listed in <b>HOSTLIST</b>. Since <b>PERIOD</b> is set to <b>INFINITY</b>, the reservation is always in force and there is no need to specify <b>STARTTIME</b>, <b>ENDTIME</b>, of <b>DAYS</b>.</p>
<p>While the reservation resource and timeframe specification is simple, the reservation access specification is actually a bit more complicated. Note that the standing reservation has two access parameters set using the attributes <strong>USERLIST</strong> and <strong>GROUPLIST</strong>. This configuration indicates that the reservation can be accessed if any one of the access lists specified is satisfied by the resource consumer (i.e., the job). In essence, reservation access is <i>logically OR'd</i> allowing access if the requestor meets any of the access constraints specified. In this example, jobs submitted by either user <tt>helpdesk</tt> or any member of the groups <tt>operations</tt> or <tt>sysadmin</tt> can use the reserved resources.</p>
<p>While access is granted to the logical <i>OR</i> of access lists specified within a standing reservation, access is only granted to the logical <i>AND</i> of access lists across different standing reservations. A comparison of the standing reservations <tt>interactive</tt> and <tt>debug</tt> in the example above will indicate that they both can allocate hosts <tt>node001</tt> and <tt>node002</tt>. If <tt>node001</tt> had both of these reservations in place simultaneously and a job attempted to access this host during business hours when standing reservation <tt>interactive</tt> was active. The job could only use the <i>doubly</i> reserved resources if it requested the run class <tt>interactive</tt> <i>AND</i> it met the constraints of reservation <tt>debug</tt> (i.e., was submitted by user <tt>helpdesk</tt> or by a member of the group <tt>operations</tt> or <tt>sysadmin</tt>).</p>
<p>Things may be further complicated by the presence of partially reserved resources. As a rule, the scheduler will not <i>stack</i> reservations unless it has to. If adequate resources exist, it can allocate reserved resources <i>side by side</i> in a single SMP host rather than on top of each other. In the case of a 16 processor SMP host with two 8 processor standing reservations. Eight of the processors on this host will be allocated to the first reservation, and eight to the next. Any configuration is possible. The 16 processor hosts can also have 4 processors reserved for user <i>John</i>, 10 processors reserved for group <i>Staff</i>, with the remaining 2 processors available for use by any job.</p>
<p>Stacking reservations is not usually required but some sites choose to do it to enforce elaborate policies. There is no problem with doing so so long as you can keep things straight. It really is not too difficult a concept, just takes a little getting used to. See the <a href="7.1.1resoverview.html">Reservation Overview</a> section for a more detailed description of reservation use and constraints.</p>
<p>As mentioned earlier, by default the scheduler enforces standing reservations by creating a number of reservations where the number created is controlled by the <strong>DEPTH</strong> attribute. When the scheduler starts up, and again each night at midnight, the scheduler updates its periodic, <i>non-floating</i> standing reservations. By default, <b>DEPTH</b> is set to 2, meaning when the scheduler starts up, it will create two 24 hour reservations covering a total of two days worth of time, (i.e. a reservation for today and one for tomorrow.) For <i>daily</i> reservations, at midnight, the reservations will <i>roll</i>, meaning today's reservation will expire and be removed, tomorrow's reservation will become today's and the scheduler will create a new reservation for the next day.</p>
<p>With this model, the scheduler continues creating new reservations in the future as time moves forward. Each day, the needed resources are always reserved. At first, all appears automatic but the standing reservation <b>DEPTH</b> attribute is in fact an important aspect of reservation <i>rolling</i> which helps address certain site specific environmental factors. This attribute remedies a situation which might occur when a job is submitted and cannot run immediately because the system is backlogged with jobs. In such a case, available resources may not exist for several days out and the scheduler must reserve these future resources for this job. With the default <b>DEPTH</b> setting of two, when midnight arrives, the scheduler attempts to <i>roll</i> its standing reservations but a problem arises in that the job has now allocated the resources needed for the standing reservation two days out. The scheduler cannot reserve the resources for the standing reservation because they are already claimed by the job. The standing reservation reserves what it can but because all needed resources are not available, the resulting reservation is now smaller than it should be or possibly even empty.</p>
<p>If a standing reservation is smaller than it should be, the scheduler will attempt to add resources each iteration until it is fully populated. However, in the case of this job, the job is not going to release its reserved resources until it completes and the standing reservation cannot claim them until this time. The <b>DEPTH</b> attribute allows a site to specify how <i>deep</i> into the future a standing reservation should reserve its resources allowing it to claim the resources first and prevent this problem. If <i>partial</i> standing reservation us detected on a system, it may be an indication that the reservations <b>DEPTH</b> attribute should be increased.</p>
<p>In example 3 above, the <b>PERIOD</b> attribute is set to <b>INFINITY</b>. With this setting, a single, permanent standing reservation is created and the issues of resource contention do not exist. While this eliminates the contention issue, infinite length standing reservations cannot be made periodic.</p>
<h4>Example 4: Multiple ACL Types</h4>
<p>In most cases, access lists within a reservation are logically OR'd together to determine reservation access. However, exceptions to this rule can be specified by using the <i>required</i> ACL marker, '<b>*</b>' (i.e., the asterisk). Any ACL marked with this symbol is required and a job is only allowed to utilized a reservation if it meets <i>all</i> required ACL's and <i>at least one</i> non-required ACL (if specified). A common use for this facility is in conjunction with the <b>TIMELIMIT</b> attribute. This attribute controls the length of time a job may use the resources within a standing reservation. This access mechanism can be AND'd or OR'd to the cumulative set of all other access lists as specified by the required ACL marker. (NOTE: The required ACL marker is only enabled in Maui 3.2.6 and higher). Consider the following example configuration:</p>
<pre>
-----
# maui.cfg
SRCFG[special] TASKCOUNT=32
SRCFG[special] PERIOD=WEEK
SRCFG[special] STARTTIME=1:08:00:00
SRCFG[special] ENDTIME=5:17:00:00
SRCFG[special] NODEFEATURES=largememory
SRCFG[special] TIMELIMIT=1:00:00*
SRCFG[special] QOSLIST=high low special-
SRCFG[special] ACCCOUNTLIST=!projectX,!projectY
-----
</pre>
<p>The above configuration requests 32 tasks which translate to 32 nodes. The <b>PERIOD</b> attribute makes this reservation periodic on a weekly basis while the attributes <b>STARTTIME</b> and <b>ENDTIME</b> specify the week offsets when this reservation is to start and end. (Note that the specification format has changed to DD:HH:MM:SS) In this case, the reservation starts on Monday at 8:00 AM and runs until Friday at 5:00 PM. The reservation is enforced as a series of weekly reservations which only cover the specified timeframe. The <b>NODEFEATURES</b> attribute indicates that each of the reserved nodes must have the node feature <tt>largememory</tt> configured.</p>
<p>As described above, <b>TIMELIMIT</b> indicates that jobs using this reservation can only use it for one hour. This means the job and the reservation can only overlap for one hour. Clearly jobs requiring an hour or less of wallclock time meet this constraint. However, a four hour job that starts on Monday at 5:00 AM or a 12 hour job which starts on Friday at 4:00 PM also satisfy this constraint. Also, note the <b>TIMELIMIT</b> required ACL marker, '<b>*</b>'. It is set indicating that jobs must not only meet the <b>TIMELIMIT</b> access constraint but must also meet one or more of the other access constraints. In this example, the job can use this reservation if it can utilize the access specified via <b>QOSLIST</b> or <b>ACCOUNTLIST</b>, i.e., it is assigned a QOS of <tt>high</tt>, <tt>low</tt>, or <tt>special</tt> , or the submitter of the job has an account which satisfies the <tt>!projectX</tt> and <tt>!projectY</tt> criteria (More on this below). <b>NOTE</b>: See the <a href="7.3qos.html">QOS Overview</a> for more info about QOS configuration and usage.</p>
<h3>7.1.5.2.4 Affinity</h3>
<p>Reservation ACL's allow or deny access to reserved resources but they may be configured to also impact a job's <i>affinity</i> for a particular reservation. By default, jobs <i>gravitate</i> towards reservations through a mechanism known known as <i>positive affinity</i>. This mechanism allows jobs to run on the most constrained resources leaving other, unreserved resources free for use by other jobs which may not be able to access the reserved resources. Normally this is a desired behavior. However, sometimes, it is desirable to reserve resources for use only as a <i>last resort</i>, i.e., use the reserved resources only when there are no other resources available. This last resort behavior is known as <i>negative affinity</i>. Note the '-' (hyphen or negative sign) following the '<tt>special</tt>' in the <b>QOSLIST</b> values above. This special mark indicates that QOS '<tt>special</tt>' should be granted access to this reservation but should be assigned negative affinity. Thus, the <b>QOSLIST</b> attribute specifies that QOS <tt>high</tt> and <tt>low</tt> should be granted access with positive affinity (use the reservation first where possible) and QOS <tt>special</tt> granted access with negative affinity (use the reservation only when no other resources are available).</p>
<p>Affinity status is granted on a <i>per access object</i> basis rather than a <i>per access list</i> basis and always defaults to positive affinity. In addition to negative affinity, neutral affinity can also be specified using the '<b>=</b>' character, i.e., '<tt>QOSLIST[0] normal= high debug= low-</tt>'.</p>
<p>In addition to affinity, ACL's may also be of different types. Note the <b>ACCOUNTLIST</b> values in the previous example. They are preceded with an exclamation point, or NOT symbol. This indicates that all jobs with accounts other than <tt>projectX</tt> and <tt>projectY</tt> meet the account ACL. Note that if a !<X> value (ie '!projectX') appears in an ACL line, that ACL is satisfied by any object not explicitly listed by a NOT entry. Also, if an object matches a NOT entry, the associated job is excluded from the reservation even if it meets other ACL requirements. For example, a QOS 3 job requesting account '<tt>projectX</tt> ' will be denied access to the reservation even though the job QOS matches the QOS ACL.<b>Note that the ability to specify 'NOT' ACLs is only enabled in Moab 4.0.0 and higher.</b></p>
<h3>7.1.5.2.5 Reservation Ownership</h3>
<p>Reservation ownership allows a site to control who <i>owns</i> the reserved resources during the reservation timeframe. Depending on needs, this ownership may be identical to, a subset of, or completely distinct from the reservation ACL. By default, reservation ownership implies resource accountability and resources not consumed by jobs will be accounted against the reservation owner. In addition, ownership can also be associated with special privileges within the reservation.</p>
<p>Ownership is specified using the <b>OWNER</b> attribute in the format <tt><CREDTYPE>:<CREDID></tt>, as in <tt>OWNER=USER:john</tt>. To enable <i>john's</i> jobs to preempt other jobs using resources within his reservation, the <b>SRCFG</b> attribute <b>FLAG</b> should be set to <b>OWNERPREEMPT</b>. In the example below, the <tt>jupiter</tt> project chooses to share resources with the <tt>saturn</tt> project but only when it does not currently need them.</p>
<h4>Example 5: Limited Shared Access</h4>
<pre>
-----
# maui.cfg
ACCTCFG[jupiter] PRIORITY=10000
SRCFG[jupiter] HOSTLIST=node0[1-9]
SRCFG[jupiter] PERIOD=INFINITY
SRCFG[jupiter] ACCOUNTLIST=jupiter,saturn-
SRCFG[jupiter] OWNER=ACCOUNT:jupiter
SRCFG[jupiter] FLAGS=OWNERPREEMPT
SRCFG[jupiter] PERIOD=INFINITY
-----
</pre>
<h3>7.1.5.2.5 Resource Allocation Behavior</h3>
<p>As mentioned above, standing reservations can operate in one of two modes, floating, or non-floating (essentially node-locked). A floating reservation is created when a <b>TASKCOUNT</b> is specified and <b>HOSTLIST</b> is either not specified or specified with more resources than are needed to fulfill the <b>TASKCOUNT</b> requirement. If a reservation is non-floating, the scheduler will allocate all resources specified by the <b>HOSTLIST</b> parameter regardless of node state, job load, or even the presence of other standing reservations. The scheduler interprets the request for a non-floating reservation as stating, 'I want a reservation on these exact nodes, no matter what!'</p>
<p>If a reservation is configured to be floating, the scheduler takes a more relaxed stand, searching through all possible nodes to find resources meeting standing reservation constraints. Only Idle, Running, or Busy node will be considered and further, only considered if no reservation conflict is detected. The reservation attribute <b>ACCESS</b> can be used to modify this behavior slightly and allow the reservation to allocate resources even if reservation conflicts exist.</p>
<p>Other standing reservation attributes not covered here include <b>PARTITION</b> and <b>CHARGEACCOUNT</b>. These parameters are described in some detail in the <a href="a.fparameters.html">parameters</a> documentation. <!--</blockquote>--></p>
<hr width="100%">
<br>
<h2>7.1.5.3 Configuring Administrative Reservations</h2>
<p>A default reservation, with no ACL, is termed a <i>SYSTEM</i> reservation. It blocks access to all jobs because it possesses an empty access control list. It is often useful when performing administrative tasks but cannot be used for enforcing resource usage policies.</p>
<p>Administrative reservations are created and modified using the <a href="commands/setres.html">setres</a> command. With this command, all aspects of reservation timeframe, resource selection, and access control can be dynamically updated.</p>
<div class="navIcons bottomIcons">
<a href="index.html"><img src="home.png" title="Home" alt="Home" border="0"></a> <a href="7.1advancereservations.html"><img src="upArrow.png" title="Up" alt="Up" border="0"></a> <a href="7.1.4reservationpolicies.html"><img src="prevArrow.png" title="Previous" alt="Previous" border="0"></a> <a href="7.1.6userreservations.html"><img src="nextArrow.png" title="Next" alt="Next" border="0"></a>
</div>
</div>
</div>
</div>
<div class="sub-content-btm"></div>
</div>
</body>
</html>