/[pdpsoft]/nl.nikhef.pdp.dynsched/trunk/lcg-info-dynamic-scheduler.txt
ViewVC logotype

Contents of /nl.nikhef.pdp.dynsched/trunk/lcg-info-dynamic-scheduler.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 2008 - (show annotations) (download)
Fri Oct 8 12:51:58 2010 UTC (11 years, 7 months ago) by templon
File MIME type: text/plain
File size: 7004 byte(s)
added header lines

1 $Id$
2 Source: $URL$
3
4 FOR THE IMPATIENT
5
6 Just installing the RPM should result in a working system.
7
8 You may want to look at the "vomap" section below if your
9 unix group names are not the same as your VO names.
10
11 OK THE REAL DOCS
12
13 This is an implementation of per-VO estimated response times and free
14 slots for the LCG 'generic information provider' framework.
15
16 HOW IT IS SUPPOSED TO WORK
17
18 There are two parts to the system.
19
20 One part (lcg-dynamic-info-scheduler program) contains the algorithm
21 that computes the response times. This part doesn't know the details
22 of the underlying batch system, so that the estimated times are as
23 independent as possible from the various LRMS.
24
25 The second part is the LRMS specific part. This gathers information
26 from the LRMS and writes it out in a LRMS-independent format. There
27 are two of these critters; one for the LRMS state, and one for the
28 scheduling policy.
29
30 A typical deployment will consist of the generic part, and two LRMS-
31 and/or site-specific plugins for this second part. These plugins need
32 to write their information in a specific format that is the same for
33 all LRMSes/schedulers. For the LRMS state information, see the file
34 lrmsinfo-generic.txt; for the free slot information, see the file
35 vomaxjobs-generic.txt.
36
37 WORKING EXAMPLES
38
39 See the doc directory, where a working set of files is included.
40 YAIM sets these up for your site by default, if you use YAIM.
41
42 DEPLOYMENT
43
44 The RPM building takes care of making sure that the scripts can find
45 the support modules (e.g. lrms.py, EstTT.py). If you decide to move
46 these modules somewhere else (relocate the RPM) then you will need to
47 adjust the paths in the script.
48
49 Aside from that the dynamic-scheduler plugin needs a configuration
50 file, which is described below. Finally, one needs to drop the ERT plugin
51 (lcg-info-dynamic-scheduler-wrapper) into the GIP plugin directory,
52 typically
53
54 /opt/lcg/var/gip/plugin
55
56 CONFIG FILE
57
58 The format of the config file is like a Windows INI file; for the
59 exact format, see the documentation for the ConfigParser module in the
60 Python standard library. Concisely it looks like this:
61
62 [Main]
63 static_ldif_file : value # required
64 vomap : # required
65 unixgroup1 : vo1
66 unixgroup2 : vo2
67 [ ... ]
68
69 [LRMS]
70 lrms_backend_cmd : value # required
71
72 [Scheduler]
73 vo_max_jobs_cmd : value # optional
74 cycle_time : value # optional
75
76 Here is an explanation of each of the options.
77
78 [Main] static_ldif_file
79
80 Set to the full pathname of the static LDIF file used by the GIP
81 system. It is used to find out which CEs are in the system, and which
82 VOs are supported by which CE. You can find this in a normal
83 deployment under
84
85 /opt/lcg/var/gip/ldif/static-file-CE.ldif
86
87 [Main] vomap
88
89 On many systems, control of access to the LRMS queues is done by unix
90 group names, associating a single unix group to a set of pool accounts
91 belonging to a particular VO. Sometimes the unix group names are not
92 the same as the VO names, "VO name" here being the thing that appears
93 in the GlueCEAccessControlBaseRule lines. The vomap is how
94 information coming from the LRMS backends is modified so that the ERT
95 and free-slot computations can be done using VO names found in the
96 static LDIF file, rather than having to make site-specific
97 customizations to either the LRMS backend plugins or to the ERT
98 scripts.
99
100 Specifically, if all relevant unix group names are identical to the
101 external VO names (as published in the CEAccessControlBaseRules),
102 then the vomap section is not needed. The only entries that are
103 needed here are those for which the external VO name is different
104 than the unix group name. Note that it is allowed to map several
105 unix group names onto a single "external" name, but each internal
106 group name must map to at most one external name.
107
108 The format looks like
109
110 vomap:
111 atlsgm : atlas
112 biome : biomed
113 LSF_lhcb : lhcb
114
115 The leading spaces are significant, they signify that each line is a
116 continuation of the 'vomap' parameter. The left hand of each line is
117 the unix group name, the right hand is the external VO name found in the
118 GlueCEAccessControlBaseRule field. If the unix group name and VO name
119 are the same, there is no need to include it in the vomap construct.
120 NOTE I have yet to test what happens if vomap is empty.
121
122 New in release 2.0 : the vomap can also map unix groups to VOMS FQANs,
123 like
124
125 aliceprd : /alice/Role=production
126
127 which maps the unix group 'aliceprd' to the listed VOMS FQAN. If
128 there is a VOView for this FQAN in the static_ldif_file, the relevant
129 info will be printed for jobs belonging to this unix group.
130
131 [LRMS] lrms_backend_cmd
132
133 Set this to a string that will run the command producing the queue
134 state information (first part of the lrms-specific part). This could
135 either be a real command like
136
137 /path/to/cmd/lrmsinfo-pbs -c /other/path/to/config_file_if_needed
138
139 or it could simply write the contents of some file to standard output
140 if you choose to generate the queue state information by a mechanism
141 other than the GIP subsystem:
142
143 cat /place/where/you/find/text_file_containing_the_generic_lrms_state.info
144
145 [Scheduler] vo_max_jobs_cmd
146
147 This is the same kind of critter as [LRMS] lrms_backend_cmd, except it
148 will provide for each unix group known to the LRMS, the maximum number
149 of job slots this group can take. Mapping from group to VO is handled
150 by the vomap parameter. If a VO has no cap on the number of jobs, it
151 can be left out. This entire command is optional, in which case the
152 free slots will only be limited by the number of free CPUs (or will be
153 set to zero when jobs for a VO are in a waiting state, in which case
154 there are obviously no free slots at the moment).
155
156 [Scheduler] cycle_time
157
158 There are various pieces of information that only make sense modulo
159 the scheduler cycle time. For example if the ERT prediction is
160 'zero', it is reset to half the scheduler cycle since the job will
161 almost never be run immediately, unless it happens to have been
162 submitted one second before the scheduling cycle starts. Set this
163 parameter to the length of your scheduling cycle. It is optional.
164 NOTE I have yet to test what happens if you leave this out.
165
166 LIMITATIONS
167
168 The program assumes that the structure of the static LDIF file is always
169 such that each block (corresponding to a given DN) is separated from the
170 next one by a blank line. If this is not the case, the parser will fail.
171
172 The program assumes that dn's it needs to parse are constructed
173 like
174
175 dn: GlueCEUniqueID=lxb...
176
177 where the line begins in the first column, and there is exactly one
178 space between the colon and the 'G' character.
179
180 For the purposes of VOView scheduling information, the plugin only
181 looks at the last AccessControlBaseRule in each VOView. The assumption
182 here is that the only reason that two ACBRs would be present in a single VOView
183 is if they mapped to the same underlying group in the batch system, in which
184 case it does not matter which one is used. The last one happens to be easier
185 for parsing purposes.

Properties

Name Value
svn:eol-style native
svn:keywords Id URL

grid.support@nikhef.nl
ViewVC Help
Powered by ViewVC 1.1.28