| Moab Workload Manager® for Grids |
17.3 Centralized Grid Management
17.3.1 Configuring a Peer Client (Destination)
In a peer-to-peer relationship, a destination server is responsible for reporting resource status information, accepting and executing jobs from source servers, and reporting the status of the source server jobs. In a simple master-slave configuration, there is a single source and multiple destinations. In other configurations, servers may be both a source and a destination server, staging jobs to some peers and accepting jobs from others. Regardless, the configuration for a destination server is basically the same and involves a required authentication CLIENTCFG line and an optional configuration RMCFG line, as in the following example:
In the previous example, notice the CLIENTCFG parameter, which has an index pointing to the master peer with a prefix of RM indicating that this client must be mapped to a resource manager. Also in the example, the RMCFG parameter is included; this parameter is optional and the peer relationship will be created without it. However, if destination side configuration of the interface is desired, this line can be added to set desired policies (in this case, the RM flag grid is being set).
NOTE: If a destination side RMCFG configuration line is specified, the client flag must be set.
A final aspect of the example configuration to note is the MODE=SLAVE attribute of the SCHEDCFG parameter. In SLAVE mode, the Moab server will behave like a normal scheduler with the exception that it will not independently start or otherwise manage jobs. In SLAVE mode, the Moab server acts like a resource manager and will only start and manage jobs under the direction of an external server. In the example, the external server is master.
The SLAVE mode is not the only mode possible for peer-to-peer environments. In some cases, sites may want to allow users to directly submit jobs to the destination cluster and have the destination cluster locally schedule and manage these jobs. In this case, the mode NORMAL can be used and the source (master) will schedule and submit global jobs across multiple clusters while the destination clusters will schedule locally submitted jobs.
It is important to note that a destination server need not receive all of its jobs from a source peer. In fact, one of the most common scenarios would be for a destination peer to fully manage a local resource manager (such as PBS or LSF) including the scheduling of all locally submitted jobs. Since jobs submitted directly to the low-level resource manager are not eligible for job migration, they must all execute locally. Consequently, many destination peers are responsible for scheduling both local jobs and jobs received from source peers.