The constraint specification of the policies is comprised of a set of logical clauses and operators that compare property names and values. The grid server defines most of these properties, but they can also be arbitrarily extended by the user/developer.
All properties appear in the job context, which is an environment where constraints are evaluated. Compound clauses can be created by logical concatenation of earlier clauses. A rich set of constraints can thus be written in the policies to describe the needs of a particular job. However, this is only part of the picture.
Constraints can also be set by an administrator via deployed policies, and additional constraints can be specified by jobs to further restrict a particular job instance. The figure below shows the complete process employed by the Orchestrator Server to constrain and schedule jobs.
When a user issues a work request, the user facts (user.* facts) and job facts (job.* facts) are added to the job context. The server also makes all available resource facts (resource.* facts) visible by reference. This set of properties creates an environment in which constraints can be executed. The scheduler applies a logic ANDing of job constraints (specified in the policies), grid policy constraints (set on the server), optionally additional user defined constraints specified on job submission, and optional constraints specified by the resources.
This procedure results in a list of matching resources. The Orchestrator solution returns three lists:
Preemptable resources (nodes running lower priority jobs that could be suspended)
Resources that could be “stolen” (nodes running lower-priority jobs that could be killed)
These lists are then passed to the resource allocation logic where, given the possible resources, the ordered list of desired resources is returned together with information on the minimum acceptable allocation. The scheduler uses this information to appropriate resources for all jobs within the same priority group. Because the scheduler is continually re-evaluating the allocation of resources, the job policies forms part of the schedulers real-time algorithm, thus providing an extremely versatile and powerful scheduling mechanism.
Figure 8-2 Job Scheduling Priority
Although job scheduling might appear complex, it is very easy to use for an end user. For example, a job developer might write just a few lines of policy code to describe a job to require a node with a x86 machine, greater than 512 MB of memory, and a resource allocation strategy of minimizing execution time. Below is an example.
<constraint type=”resource”> <and> <eq fact="cpu.architecture" value="x86" /> <gt fact="memory.physical.total" value="512" /> </and> </constraint>