Evaluate Moab Workload Manager® for Grids

Evaluate Moab Workload Manager_^® for Grids

This installation and configuration guide contains the most basic configuration and parameter settings needed to establish a grid environment with Moab. For more detailed information, please see our Grid Documentation.

Prerequisites

Step 1: Download

Step 2: Installation

Step 3: Configuring a Grid Environment

Step 4: Initial Testing

Step 5: Moab Cluster Manager and Access Portal

Step 6: Additional Configuration

Prerequisites

Moab Workload Manager for Grids is only installed on the head node of each cluster attached to the grid.

You will need a resource manager previously installed that can run workload. Moab will sit on top of the resource manager and aggregate cluster information while driving the resource manager. You can download TORQUE Resource Manager freely from here.

Step 1: Download

Step 1A: Register to receive an instantaneous free username and password if you don't already have one. Forgot your username and/or password?

Step 1B: Download the appropriate Moab build.

Linux-i386 - Version 5.1.0 (For use with version 2.1 or higher of TORQUE)

Linux-x86_64 - Version 5.1.0 (For use with version 2.1 of higher of TORQUE)

Step 2: Install

(Detailed installation instructions)

Step 2A: Extract the contents of the tar file.

Step 2B: Run ./configure in the newly created directory.

Step 3C: Run make install.

Step 4D: Type moab to run Moab.

Step 3: Configure a Grid Environment

Step 3A: Choose the Grid model that best suits your needs. Moab can control a grid environment using two main models:

Model 1: Traditional Centralized Source-Destination

This model allows users to submit jobs to a centralized source Moab server. The source Moab server will obtain full resource information from all clusters and make intelligent scheduling decisions across all clusters. As needed, jobs and data are migrated to the remote clusters. If communication between the source and destination clusters is lost, then the destination cluster can still run jobs locally. The model is recommended for intra-organization grid environments when cluster autonomy is not as necessary. Learn More

Model 2: True Peer-to-Peer (Bi-directional flow)

This model allows users to submit jobs from one Moab server (server 1) and have them scheduled on another Moab server (server 2). Jobs can also be submitted from server 2 and scheduled on server 1. The Moab servers will obtain full resource information from all clusters and make intelligent scheduling decisions across all clusters. As needed, jobs and data are migrated to the remote clusters.

This model allows for clusters to retain their autonomy while still allowing jobs to run on any cluster. No central location for job submission is needed and end users will not need to submit jobs from different nodes depending upon resource needs. A job is submitted from any location and is either migrated to nodes on the best utilized cluster or the nodes determined in the job submission. This model is recommended for grids in an inter-organization grid environment. Learn More

Model 1: Traditional Centralized Source-Destination:

I. Configure one cluster as the source cluster

moab.cfg (source server)

T1. Add an RMCFG parameter pointing to each destination cluster - in this case C2 and C3.

T2. Set TYPE=MOAB to tell the source Moab server that those clusters are destination Moab servers.

RMCFG[C2] TYPE=MOAB   SERVER=head.C2.xyz.com:40559

RMCFG[C3] TYPE=MOAB   SERVER=head.C3.xyz.com:40558

NOTE: The name you give RMCFG in brackets, must be the same as the name given to the cooresponding SCHEDCFG.

II. Trusting the Destination: moab-private.cfg

The source Moab server needs to know which destination servers to trust. With the proper security key, the source Moab server will allow destination servers access to the grid.

Source Server

T3. Create a file named moab-private.cfg in the same directory as moab.cfg. Only should the user running Moab have read/write privileges to this file.

T4. Add the CLIENTCFG[RM:] parameter and point RM to the specific destination server as seen in the example below.

T5. Create a different KEY for each destination server.

CLIENTCFG[RM:C2] KEY=fastclu3t3r

CLIENTCFG[RM:C3] KEY=14436aaa

Destination Server

T6. Create a file named moab-private.cfg in the same directory as moab.cfg. Only should the user running Moab have read/write privileges to this file.

T7. Add the CLIENTCFG[RM:] parameter and point RM to the source Moab server as seen in the example below.

T8. The KEY will need to be the same key configured for the specific destination server in the source server's moab-private.cfg file.

T9. Add AUTH=admin1 to tell the source Moab server to allow the destination cluster complete Moab administrator rights.

moab-private.cfg (C2)

CLIENTCFG[RM:C1] KEY=fastclu3t3r AUTH=admin1

moab-private.cfg (C3)

CLIENTCFG[RM:C1] KEY=14436aaa AUTH=admin1

Model 2: Creating a True Peer-to-Peer (Bi-directional Flow)

I. Configure the Peer servers

moab.cfg (server 1)

P1. Add the RMCFG parameter and point it to server2.

P2. Set TYPE=MOAB to tell the Moab server that the destination is a Moab server as well.

RMCFG[server2] TYPE=MOAB SERVER=server2.omc.com:42005

NOTE: The name you give RMCFG in brackets, must be the same as the name given to the cooresponding SCHEDCFG.

moab.cfg (server 2)

P3. Add the RMCFG parameter and point it to server1.

P4. Set TYPE=MOAB to tell the Moab server that the destination is a Moab server as well.

RMCFG[server1] TYPE=MOAB SERVER=server1.omc.com:42006

NOTE: The name you give RMCFG in brackets, must be the same as the name given to the cooresponding SCHEDCFG.

II. Trusting the Servers - moab-private.cfg

P5. Create a file named moab-private.cfg on each cluster server and in the same directory as moab.cfg. Only should the user running Moab have read/write privileges to this file.

P6. Add the CLIENTCFG[RM:] for each peer server and point RM to the specific Moab peer server

P7. Create a KEY for each Moab server.

P8. Add AUTH=admin1 to tell the Moab server to allow the other server complete Moab administrator rights.

moab-private.cfg (server 1)

CLIENTCFG[RM:server2] KEY=443db-writ4 AUTH=admin1

moab-private.cfg (server 2)

CLIENTCFG[RM:server1] KEY=443db-writ4 AUTH=admin1

Step 4: Initial Testing

Step 4A: Type showq to see all the workload running on your system. You will see number of nodes and processors on the grid.

Step 4B: Type mdiag -n to see a list of all the nodes on the grid.

Step 4C: Type mdiag -R to see the state of the Moab servers.

Step 4D: Submit a job using msub -l nodes=[node on other cluster] script.

>msub -l nodes=node82 sleep.sh

Step 5: View the functionality of Moab Cluster Manager and Moab Access Portal for Grids

Currently, only Moab Workload Manager for Grids is available for evaluation from the Web site, however the other components of Moab Grid Suite are available upon request. Sites may also use corresponding products from Moab Cluster Suite to see an example of the product functionality.

Step 5A: Follow the instructions for downloading, installing and using Moab Cluster Manager. You can run an instance of Moab Cluster Manager for each cluster in the grid.

Step 5B: Follow the instructions for downloading, installing and using Moab Access Portal. It will provide you with the look, feel and usability of Moab Access Portal for Grids but without complete grid capabilities. You can also view the Online Demo. To evaluate Moab Access Portal for Grids, please contact Cluster Resources.