C H A P T E R 5 |
Advance Reservation |
Advance Reservation (AR) is a feature of some queuing software systems, but this feature is not present in Sun Grid Engine release 6.1. (If you are using a later release of Sun Grid Engine, check whether that version includes an Advance Reservation feature.) AR schedules compute and visualization resources when the computer resources and the people to use the resources are both available. Reservations must not be scheduled to conflict with each other (by oversubscribing available resources), nor with other Sun Grid Engine uses of the same resources.
This chapter details information the system administrator needs to know about AR. The Sun Shared Visualization 1.1 Software Client Administration Guide, 820-3257, contains information for the end user.
Topics in this section include:
A user can reserve specified resources at a given time, for a given duration. Once confirmed, the resources are available to that user’s Sun Grid Engine jobs during that given reservation period. Jobs intended to run during the reservation period can be submitted to Sun Grid Engine (as with Sun Grid Engine’s qsub command) right after the reservation is confirmed, or anytime before the end of the reserved period.
Implementing Advance Reservations outside of Sun Grid Engine requires creating a dynamic Sun Grid Engine queue to represent each confirmed reservation. Resources are allocated to the reservation’s queue by temporarily removing the resources from the execution host’s generic queue (such as all.q or interactive). Resources are removed in advance of the reservation, so that non-AR jobs that use the resources are finished prior to when the reservation is scheduled to start.
The Advance Reservation package has two kinds of programs:
The AR server assures that reservations consume only enabled resources. This server assures that confirmed reservations’ resources are available to the users. For each confirmed reservation, the server dynamically creates a Sun Grid Engine queue that becomes active (that is, the queue’s jobs can run) at the reservation time. The server runs as the Sun Grid Engine administrator (sgeadmin) on a Sun Grid Engine administration host.
The AR client is used by any Sun Grid Engine user to create, list, and delete reservations. The client communicates with the AR server. The AR client exists in two forms. The Reserve client is a simple command-line program. The Reserve GUI is a graphical user interface that eases use.
Additional components involved in AR, shown in the architectural diagram (FIGURE 5-1), are:
This database is currently a Berkeley database, which is used only in primitive ways to make reservations persistent.
This application is the software that actually allocates resources to jobs, including jobs submitted against the reservation’s queue.
FIGURE 5-1 shows the implementation architecture.
FIGURE 5-1 Advance Reservation Architecture
The Advance Reservation package installs an ar subdirectory under the Sun Grid Engine SGE_ROOT. The default SGE_ROOT is /gridware/sge. If your SGE_ROOT differs from the default, you must set the SGE_ROOT environment variable, typically by sourcing the Sun Grid Engine /gridware/sge/default/common/settings.csh or /gridware/sge/default/common/settings.sh file.
Under $SGE_ROOT/ar you find these components:
If during installation or configuration you choose a different location for SGE_ROOT than the default of /gridware/sge, and if the Solaris software package SUNWsgeec is not installed on the Advance Reservation server host, the Advance Reservation facility needs your SGE_ROOT value. You must edit several files to include the nondefault location so that the Sun Grid Engine and Advance Reservation feature function properly.
1. Install the Sun Grid Engine software and optionally configure for Advance Reservation.
2. As superuser, use an editor to edit the following files:
3. Within the files, locate each occurrence of the string:
4. Replace each occurrence with:
where your-sge-root-path is your specific Sun Grid Engine root path.
If a reservation relies on certain resources being available at its start time T, no job can start (on the same host as the reservation) shortly before T using those resources and still be using them at time T. However, a job could start shortly before T using additional resources not required by the reservation.
defaults.prop contains a Java property called AdvanceReservation.MaximumNonreservedJobDuration. The value of this property is a duration. The default value is 2\:0\:0, which means 2 hours, 0 minutes, and 0 seconds.
This property determines the amount of time preceding any existing reservation during which the AR server will not allow another job to start running if that job would call for the reserved resources. That duration prior to the job start, the reserved resources will be set aside for the reservation by removing them from the generic queue given by the Java property AdvanceReservation.GenericQueueName (the default value is all.q). These reserved resources will be released by the reservation at the end of the reservation. The released resources are returned to the generic queue, unless they are already known to be needed soon afterwards by a subsequent reservation.
To guarantee the reservation, you must preclude jobs started prior to the resource reservation (that is more than AdvanceReservation.MaximumNonreservedJobDuration before the reservation start time T is still running at time T). To achieve this, the grid administrator should assure that jobs specify a maximum runtime (wall clock time) limit no greater than the duration of the AdvanceReservation.MaximumNonreservedJobDuration property.
The maximum runtime limit is specified using the h_rt resource (whose values are also in the hours:minutes:seconds format). You specify the maximum h_rt resource limit in the cluster-wide sge_request file. (You also can place a .sge_request file in the current working directory or in $HOME.) For the default cell, this file is $SGE_ROOT/default/common/sge_request.
The specification of a maximum h_rt equal to 2 hours would look like:
Note that an effective specification does not start with the # that appears in the comments already in the file.
The first time the Advance Reservation server runs, the server creates initial versions of the configuration files described in TABLE 5-1. The initial configuration enables Advance Reservation on all execution hosts in the grid of the server host. Initially, the limits file knows only of graphics resources that were assigned using Sun Grid Engine to a specific queue (for example, all.q@mygraphicsserver). The file does not know of those resources allocated to an execution host. To correct this situation, perform the procedure for your respective operating system.
To Perform Initial Configuration for Solaris 10 and Later Operating Systems |
1. As superuser, configure the Advance Reservation server with the Sun Grid Engine administrative user.
Replace sgeadmin with your Sun Grid Engine administrator username, if different.
2. Start the Advance Reservation service by typing:
The service is started and configured to start whenever the host reboots.
The files described in TABLE 5-1 are created.
3. Edit the $SGE_ROOT/ar/config/limits file to reflect any resources that are assigned to an execution host, rather than to a queue.
4. Restart the Advance Reservation service by typing:
The output of the AR server is saved in a log file named:
/var/svc/log/network-n1ge_ar:default.log
To Perform Initial Configuration for Solaris 9 and Earlier and Linux Operating Systems |
1. As superuser, open the /etc/init.d/sgear script in an editor.
2. Set the AR_USER variable to your Sun Grid Engine administrator username.
Replace sgeadmin with your Sun Grid Engine administrator username, if different.
4. Start the Advance Reservation service by typing:
The files described in TABLE 5-1 are created.
5. Edit the $SGE_ROOT/ar/config/limits file to reflect any resources that are assigned to an execution host, rather than to a queue.
Restart the Advance Reservation service by typing:
The output of the AR server is saved in a log file named:
/var/tmp/ARS.$$ ($$ is the process ID for the script).
To start the AR server or client, the bin/runar script is used. Normally, the server startup is performed by the RC script /etc/init.d/sgear.
The AR server must run on a Sun Grid Engine administrative host. The server runs as the Sun Grid Engine administrator (sgeadmin), and must have access to the Sun Grid Engine executables.
If you have configured your $SGE_ROOT variable to something other than the default, you can also type:
For more simplicity, you can alias the complete path to the runar script to a single command. For example:
Use of the Advance Reservation client is described in the Sun Shared Visualization 1.1 Software Client Administration Guide, 820-3257.
The following table lists the states a reservation normally passes through, in sequence:
Both the client and server contain both assertions and Assume code. The Assume code prints stack traces if the code encounters an error, but then continues to execute (rather than aborting).
The client displays the following message to indicate the client doesn’t find the server running (on the port specified):
Copyright © 2008, Sun Microsystems, Inc. All Rights Reserved.