2.4 Provisioning Resources and Managing Dynamic Security

Moab enables intelligent, coordinated dynamic provisioning and customization of both compute nodes and support infrastructure. Moab flexibility allows multiple provisioning models to be maintained across various resource groups and even over time.

2.4.1 Customizing a Compute Node

2.4.1.1 Rebuilding a Node From Scratch

Moab can support both disk-less and disk-full node configurations and can dynamically coordinate underlying tools to set up the operating system on a per-request basis.

2.4.1.2 Enabling Virtual Nodes

Moab can support both XEN and VMWare based virtual node management to allow customers to use node resources within a fully customized virtual space.

2.4.1.3 Application Based Access

If application level access is required, Moab can automatically customize and launch the appropriate application to allow usage only by

2.4.2 Customizing Storage, Network, and other Non-Compute Resources

Just as Moab can customize compute nodes, Moab can also configure resources that are off node. This can include setting up storage and network resources as well as customizing and launching support services.

2.4.3 Managing Dynamic Security

Moab can automatically set up user accounts, manage host-based security, and create dynamic VLANs and VPNs to enable per request network security.

2.4.4 Using Triggers and Trigger Variables

Triggers can automate many of the tasks that normally require a system administrator's time and attention. Triggers allow a site administrator to customize event policies or actions to take based on certain conditions within the Moab scheduler and the environment it is managing. In a hosting environment, triggers can be implemented to automate many of the tasks required in initializing sections of the cluster for specific customers. For example, a site may require sections of the cluster to be wiped clean, initialized with a private VPN, and finally formatted with a particular operating system. Each one of these actions can be automated by a trigger. When a co-allocation reservation is created, it can be given attributes of an RSVPROFILE as described earlier. This profile and its triggers can contain the actions and information necessary to initialize a section of the cluster for customers.

This first trigger executes the script /tmp/host/triggers/Net.sh with the names of the different reservations hosts as parameters. When it succeeds, it sets the variables $Var1, $Var2, and $Var3, which could be the IP address, gateway, and DHCP server. Should its execution last longer than one hour, it will be killed and the trigger will be put into a FAILED state.

RSVPROFILE[test1] TRIGGER=Sets=$Var1.$Var2.$Var3.!Net,EType=start,AType=exec,Action=/tmp/host/triggers/Net.sh,Timeout=1:00:00

This next trigger launches /tmp/host/triggers/FS.sh only when the first trigger has completed successfully. It uses the variables set by the first trigger and sets $Var4 and $Var5 once it has completed successfully. Should the trigger fail to terminate after 20 minutes it will also be put into a FAILED state and its variables will not reset.

RSVPROFILE[test1] TRIGGER=Requires=$Var1.$Var2.$Var3,Sets=$Var4.$Var5,EType=start,AType=exec,Action=/tmp/host/triggers/FS.sh+$Var1:$Var2:$Var3,Timeout=20:00

Trigger 3 uses all the variables from previous triggers as parameters for its script /tmp/host/triggers/OS.sh. If this trigger succeeds, it simply sets OSinit to TRUE. If it fails, it sets the variable NOOSinit to TRUE.

RSVPROFILE[test1] TRIGGER=Requires=$Var1.$Var2.$Var3.$Var4.$Var5,Sets=!NOOSinit.OSinit,Etype=start,AType=exec,Action=/tmp/host/triggers/OS.sh+$Var1:$Var2:$Var3:$Var4:$Var5

This trigger will only launch if trigger 3 has failed. This trigger will cancel the entire reservation should trigger 3 not run to completion. In essence, this trigger verifies that all previous triggers have completed successfully and if not, it will release the reservation and make its resources available for future queries.

RSVPROFILE[test1] TRIGGER=Requires=NOOSinit,AType=cancel,EType=start

The final trigger launches /tmp/host/triggers/success.sh once all previous triggers have completed successfully. This script could simply send out an email to administrators or customers notifying them that their requested resources are now available for consumption.

RSVPROFILE[test1] TRIGGER=EType=start,Requires=OSinit,AType=exec,Action=/tmp/host/triggers/success.sh

Variables can also be set at the moment a reservation is committed using the mrsvctl -c -V command. The previous example could be extended to include the following capability:

> mrsvctl -c -R 1 -V '$Var1=12.34.56.78'

$Var1 would then be set once the reservation is created and would be available as a parameter for each trigger.