This policy assigns a fixed priority to each job. The fixed priority ranges from 00 (lowest priority) to 19 (highest priority), so jobs with a higher priority will be dispatched first. The default priority values are assigned, by the Grid administrator, using the following criteria:

The user priority prevails over the group one. Also there is a special user (DEFAULT) to define the default priority value when no criteria apply.

The users can set the priority of their own jobs (gwsubmit -p) but without exceeding their limit set by the administrator in the scheduler configuration file.

Here is an example configuration for the fixed priority (see also Section 2.5, “Built-in Scheduler Configuration File”):

   # Weight for the Fixed priority policy
   FP_WEIGHT = 1
   
   # Fixed priority values for David's and Alice's jobs
   FP_USER[david]  = 2
   FP_USER[alice]  = 12
   
   # Fixed priority for every body in the staff group
   FP_GROUP[staff] = 5
   
   # Anyone else gets a default priority 3
   FP_USER[DEFAULT] = 3

The Grid administrator can also set the fixed priority of a job to 20. When a job gets a fixed priority of 20, it becomes an urgent job. Urgent jobs are dispatched as soon as possible, bypassing all the scheduling policies.

The fair-share policy allows you to establish a dispatching ratio among the users of a scheduling domain. For example, a fair-share policy could establish that jobs from David and Alice must be dispatched to the Grid in a 2:5 ratio. In this case, the scheduler tracks the jobs submitted to the Grid by these two users and dispatches the jobs so they target a 2:5 ratio of job submissions.

This policy resembles the well-known fair-share of traditional LRMS. However, note that what GridWay users share is the ability to submit a job to the Grid and not resource usage. Resource usage share cannot be imposed at a Grid level, as Grid resources are shared with other Grid users and with local users from the remote organization. In addition, the set of resources that can be potentially used by each user is not homogeneous, as each user may belong to a different VO.

GridWay tracks the jobs submitted to the Grid by the users over time. Grid administrators can specify a timeframe over which user submissions are evaluated. The amount of time considered by GridWay is defined by a number of time intervals (SH_WINDOW_DEPTH) and the duration of each one (SH_WINDOW_SIZE, in days). The effective number of submissions in a given window is exponentially damped, so present events become more relevant.

Here is an example configuration for the share policy (see also Section 2.5, “Built-in Scheduler Configuration File”):

   # Weight for the Fair-share policy
   SH_WEIGHT = 1
   
   # Shared values for David's and Alice's submissions
   SH_USER[david]  = 2
   SH_USER[alice]  = 5
   
   # Anyone else gets a default share value of 1
   SH_USER[DEFAULT] = 1
   
   # Consider submissions in the last 5 days
   SH_WINDOW_SIZE = 1
   SH_WINDOW_DEPTH= 5

The goal of this policy is to prevent low-priority jobs from starving. So jobs in the pending state long enough will be eventually submitted to the Grid. This policy can be found in most of the DRMS today. In GridWay, the priority of a job is increased linearly with the waiting time.

Here is an example configuration for this policy:

    # Weight for the Waiting-time policy
    WT_WEIGHT = 1

GridWay includes support for specifying deadlines at job submission. The scheduler will increase the priority of a job as its deadline approaches.

	Important
	Note that this policy does not guarantee that a job is completed before the deadline.

Grid administrators should provide a way to qualify the remaining time to reach the job deadline by defining when a job should get half of the maximum priority assigned by this policy (DL_HALF, in days).

Here is an example configuration for the deadline policy (see also Section 2.5, “Built-in Scheduler Configuration File”):

    # Weight of the Deadline Policy
    DL_WEIGHT = 1
    
    # Assign half of the priority two days before the deadline
    DL_HALF = 2

The list of all pending jobs is sorted by the dispatch priority, which is computed as a weighted sum of the contribution from the previous policies. In this way, the Grid administrator can implement different scheduling schemes by adjusting the policy weights.

The dispatch priority of a job is therefore computed with:

Figure 3. Dispatch priority of a job

where w_i is the weight for each policy (integer value) and p_i is the priority (normalized) contribution from each policy.

Usually, GridWay is configured with several Information Managers (IM). Grid administrators can prioritize resources based upon the IM that discovered the resource. Grid administrators can also assign priorities to individual resources. For example, a fixed priority policy can specify that resources from the intranet (managed by an IM driver tagged intranet) should always be used before resources from other sites (managed by an IM driver tagged grid).

The priority of a resource ranges from 01 (lowest priority) to 99 (highest priority), so resources with a higher priority will be used first. Grid administrators can also prioritize individual resources based on business decisions.

When a resource gets the priority value 00, it becomes a banned resource, and will not be used for any job. So Grid administrators can virtually unplug resources from their scheduling domain.

Example configuration for the resource Fixed Priority Policy:

   # Weight for the Resource fixed priority policy
   RP_WEIGHT = 1
   
   # Fixed priority values for specific resources
   RP_HOST[my.cluster.com]    = 12
   RP_HOST[slow.machine.com]  = 02
   
   # Fixed priority for every resource in the intranet
   RP_IM[intranet] = 65
   
   # Fixed priority for every resource discovered by the grid IM
   RP_IM[grid] = 05
   
   # Anyone else gets a default priority 04 (i.e. other IM)
   RP_IM[DEFAULT] = 01

The goal of this policy is to prioritize those resources more suitable for the job, from its own point of view. For example, the rank policy for a job can state that resources with faster CPUs should be used first. This policy is configured through the RANK attribute in the job template, please refer to the GridWay user guide.

Example configuration for the Rank policy:

    # Weight of the Rank policy
    RA_WEIGHT = 1

This policy reflects the behavior of Grid resources based on job execution statistics. So, crucial performance variables, like the average queue wait time or network transfer times, are considered when scheduling a job. This policy is derived from the sum of two contributions: history and current.

These values are used to compute an estimated execution time of a job on a given resource for a given user:

Figure 4. Estimated execution time of a job on a resource

where T^c are the execution statistics of the last job (execution, transfer and queue wait-time), T^h are the execution statistics based on the history data; and w is the history ratio. Those resources with a lower estimated time are used first to execute a job.

The Usage policy can be configured with:

Example configuration for Usage policy:

   # Weight of the Usage policy
   UG_WEIGHT = 1
   
   # Number of days in the history window
   UG_HISTORY_WINDOW = 3
   
   # Accounting database to last execution ratio
   UG_HISTORY_RATIO = 0.25

When a resource fails, GridWay implements an exponential linear back-off strategy at resource level (and per each user); henceforth, resources with persistent failures are discarded (for a given user).

In particular, when a failure occurs a resource is banned for T seconds:

Figure 5. Banned time formula

where T_∞ is the maximum time that a resource can be banned, Delta t is the time since last failure, and C is a constant that determines how fast the T_∞ limit is reached.

The failure rate policy can be configured with the following parameters:

Example configuration for the Failure Rate policy:

    # Maximum time that a resource will not be used, in seconds
    FR_MAX_BANNED_TIME = 3600
    # Exponential constant
    FR_BANNED_C        = 650

The list of all candidate resources is sorted by the suitability priority, which is computed as a weighted sum of the contribution from the previous policies. The suitability priority resource is therefore computed with:

Figure 6. Suitability priority of a resource

where w_i is the weight for each policy (integer value) and p_i is the priority (normalized) contribution from each policy.

Also, the scheduler can migrate running jobs in the following situations:

See Section 1.2, “GridWay Daemon (GWD) Configuration” and the GridWay user guide, for information on configuring these policies.

By default, GridWay is configured to use the built-in policy engine described in the previous sections. If for any reason you need to recover this configuration, add the following line to $GW_LOCATION/etc/gwd.conf:

DM_SCHED  = builtin:gw_sched:

Do not forget to adjust the scheduler policies to your needs by editing the $GW_LOCATION/etc/sched.conf file.

To configure the round-robin/flood scheduler, first disable the built-in engine policy in the $GW_LOCATION/etc/sched.conf configuration file by adding the following line:

DISABLE = yes

Then add the following line to $GW_LOCATION/etc/gwd.conf:

DM_SCHED = flood:gw_flood_scheduler:-h 10 -u 30 -c 5 -s 15

where:

Now it is possible to specify a different gatekeeper port than the standard one (8443) in the Web Service driver. The line to configure EM MADs in gwd.conf has changed so you can add parameters to it. The parameter to change the port is the -p followed by the port number. For example:

 EM_MAD = osg_ws:gw_em_mad_ws:-p 9443:rsl2

This line tells the EM MAD to use port 9443 to connect to the GT4 Gatekeeper.

The GridFTP driver does not require any command line arguments. So to configure the driver, add the following line to $GW_LOCATION/etc/gwd.conf:

TM_MAD = gridftp:gw_tm_mad_ftp:

The name of the driver will be later used to specify the transfer mechanisms with Grid resource.

The Dummy driver should be used with those resources (clusters) which do not have a shared home. In this case, transfer and execution are performed as follows:

The following servers can be configured to access files on the client machine:

The Dummy driver behavior is specified with the following command line arguments:

Sample configuration to use a GridFTP server:

TM_MAD = dummy:gw_tm_mad_dummy:-u gsiftp\://hostname

	Important
	You MUST escape the colon character in gsiftp URL. Also, hostname should be the host running the GridWay instance.

Sample configuration to use GASS servers:

TM_MAD = dummy:gw_tm_mad_dummy:-g

In this mode, hosts are statically discovered by reading a host list file (note: each time it is read). Also the attributes of each host are read from files. Hint: Use this mode for testing purposes and not in a production environment. To configure a Information Driver in SS mode use the host list option, for example:

IM_MAD = static:gw_im_mad_static:-l examples/im/host.static:gridftp:ws

The host list file contains one host per line, with format:

FQDN    attribute_file

where:

For example (you can find this file, host.list, in $GW_LOCATION/examples/im/)

   hydrus.dacya.ucm.es examples/im/hydrus.attr
   draco.dacya.ucm.es examples/im/draco.attr

The attribute_file includes a single line with the host information and other lines with the information of each queue (one line per queue). Use the examples below as templates for your hosts.

Example of attribute file for a PBS cluster (you can find this file in $GW_LOCATION/examples/im/):

  HOSTNAME="hydrus.dacya.ucm.es" ARCH="i686" OS_NAME="Linux" OS_VERSION="2.6.4"
  CPU_MODEL="Intel(R) Pentium(R) 4 CPU 2" CPU_MHZ=2539 CPU_FREE=098 CPU_SMP=1
  NODECOUNT=4 SIZE_MEM_MB=503 FREE_MEM_MB=188 SIZE_DISK_MB=55570
  FREE_DISK_MB=39193 FORK_NAME="jobmanager-fork" LRMS_NAME="jobmanager-pbs"
  LRMS_TYPE="pbs" QUEUE_NAME[0]="q4small" QUEUE_NODECOUNT[0]=1
  QUEUE_FREENODECOUNT[0]=4 QUEUE_MAXTIME[0]=0 QUEUE_MAXCPUTIME[0]=20
  QUEUE_MAXCOUNT[0]=4 QUEUE_MAXRUNNINGJOBS[0]=0 QUEUE_MAXJOBSINQUEUE[0]=1
  QUEUE_STATUS[0]="enabled" QUEUE_DISPATCHTYPE[0]="batch"
  QUEUE_NAME[1]="q4medium" QUEUE_NODECOUNT[1]=4 QUEUE_FREENODECOUNT[1]=4
  QUEUE_MAXTIME[1]=0 QUEUE_MAXCPUTIME[1]=120 QUEUE_MAXCOUNT[1]=4
  QUEUE_MAXRUNNINGJOBS[1]=0 QUEUE_MAXJOBSINQUEUE[1]=1
  QUEUE_STATUS[1]="enabled" QUEUE_DISPATCHTYPE[1]="batch"

Example of attribute file for a Fork Desktop (you can find this file in $GW_LOCATION/examples/im/):

  HOSTNAME="draco.dacya.ucm.es" ARCH="i686" OS_NAME="Linux" OS_VERSION="2.6-xen"
  CPU_MODEL="Intel(R) Pentium(R) 4 CPU 3" CPU_MHZ=3201 CPU_FREE=185 CPU_SMP=2
  NODECOUNT=2 SIZE_MEM_MB=431 FREE_MEM_MB=180 SIZE_DISK_MB=74312
  FREE_DISK_MB=40461 FORK_NAME="jobmanager-fork" LRMS_NAME="jobmanager-fork"
  LRMS_TYPE="fork" QUEUE_NAME[0]="default" QUEUE_NODECOUNT[0]=1
  QUEUE_FREENODECOUNT[0]=1 QUEUE_MAXTIME[0]=0 QUEUE_MAXCPUTIME[0]=0
  QUEUE_MAXCOUNT[0]=0 QUEUE_MAXRUNNINGJOBS[0]=0 QUEUE_MAXJOBSINQUEUE[0]=0
  QUEUE_STATUS[0]="0" QUEUE_DISPATCHTYPE[0]="Immediate"

To use the WS version of these files just change jobmanager-fork with Fork and jobmanager-pbs with PBS.

Hosts are discovered by reading a host list file. However, the information of each host is gathered by querying its information service (GRIS in MDS2 or the DefaultIndexService in MDS4). Hint: Use this mode if the resources in your Grid does not vary too much, i.e. resource are not added or removed very often. To configure an Information Driver in SD mode, use the host list option, for example:

IM_MAD = glue:gw_im_mad_mds2_glue:-l examples/im/host.list:gridftp:prews

In this case the host list file contains one host per line, with the format:

    FQDN
    ...
    FQDN

where:

For example (you can find this file in $GW_LOCATION/examples/im/)

    hydrus.dacya.ucm.es
    ursa.dacya.ucm.es
    draco.dacya.ucm.es

	Note
	The information services of each host (GRIS or/and DefaultIndexServices) must be properly configured to use this mode.

	Important
	You can configure your IMs to work in a dynamic monitoring mode but get some static information from an attributes file (as described in the SS mode). This configuration is useful when you want to add some host attributes missing from the IndexService (like software availability, special hardware devices...). You can see a useful use of this mode in section Troubleshooting.

In this mode, hosts are discovered and monitored by directly accessing the Grid Information Service. Hint: Use this mode if the resources in your Grid does vary too much, i.e. resource are added or removed very often. To configure a Information Driver in SD mode, use the server option, for example:

IM_MAD = mds4:gw_im_mad_mds4:-s hydrus.dacya.ucm.es:gridftp:ws

	Note
	A hierarchical information service (GIIS or/and DefaultIndexService) must be properly configured to use this mode.

If you are using an MDS2 information service you may need to specify the Virtual Organization name in the DN of the LDIF entries (Mds-vo-name) with the base option described above.

	Note
	You can simultaneously use as many Information Drivers as you need (up to 10). So GridWay allows you to simultaneously use MDS2 and MDS4 Services. You can also use resources from different Grids at the same time.

	Note
	You can mix SS, SD and DD modes in the same Information Driver.

There is a way to specify a different machine to be used as gsiftp endpoint than the one that has the gatekeeper installed. This is useful when the CE machine does not have gsiftp server configured but there is another machine that works as a Storage Element. Right now, this information could be set statically but the rest of the information can be updated dynamically. To use this feature you have to create a file for each host you want to configure with extra information and another file with pairs of host and file name (as described above for the SS mode). The filename can be a full path or a relative path to GW_LOCATION. Then in the IM MAD you must specify the list file with -l, like this (in gwd.conf):

   IM_MAD = mds4:gw_im_mad_mds4:-l etc/gridway/host.list:gridftp:ws

The file list should look like this:

   wsgram-host1.domain.com etc/gridway/wsgram-host1.attr
   wsgram-host2.domain.com etc/gridway/wsgram-host2.attr

And the attributes file for each node should look like this:

   SE_HOSTNAME="gridftp-host1.domain.com"