(Click to open topic with navigation)

22.0 Workload-Driven Cloud Services > About workload-driven cloud services

Conventions

22.0 About workload-driven cloud services

A cloud service is one or more job workflows held in a virtual container — each comprising a separate but related piece of the service — that create, set up, and maintain it. Individual jobs within the workflows implement Moab triggers to run scripts that perform certain tasks and to set and receive variables. Variables correctly sequence the jobs that set up the services and allow scripts further in the workflow to locate them. The following example illustrates the composition of a simple VM service without storage:

Click to enlarge

A VC contains the job workflow, its jobs, and their triggers and shared variables. That workflow consists of a number of generic system jobs and a single selectable job that the user submits when requesting the service or service component.

22.0-A Workflows

A cloud workflow contains a series of generic system jobs, or system jobs with a trigger, with dependencies and variables. The workflow also contains a selectable job, which must meet the following criteria:

  1. It is not a generic system job.
  2. It is the final job in the workflow.
  3. If the service is a VM, it is a VM-tracking job.

Each job, besides the first in the workflow, has a dependency on another job to ensure that they run in the correct order. Workflows must be linear; they cannot branch.

Image 22-1: Workflow example

Click to enlarge

As shown in the illustration above, the user requests the selectable job using the msub command. Moab creates it and the other jobs inside of a VC. They run in the order specified by the template dependencies, ending with the selectable job.

22.0-B Virtual Containers

Virtual Containers (VCs) are logical groupings of objects with a shared variable space. They can hold jobs, reservations, nodes, VMs, and other VCs, including services.

Click to enlarge

This image illustrates a VC containing all possible object types, a PM workflow, and a child VC containing a VM service. The child VC contains two virtual machines and one physical machine workflow.

22.0-C Variables

Variables are the method by which jobs in a workflow, or even jobs within separate subservices of a single service, send messages to one another. A variable could be the IP address of a new VM, an indication of script success or failure, or another piece of information that affects other jobs in the service. By default, trigger variables are only accessible to its parent object (in this case, the job to which the trigger is attached); however, If configured to do so, triggers will pass their variables up to the VC, granting all objects access to one another's variables.

Click to enlarge

The image above shows vc1, a container comprised of two jobs. Each job has a trigger that sets a variable and it passes it up to vc1. When vc1 receives the variables, they become available to all objects. Job2 can receive V1, and Job1 can receive V2.

Additionally, if vc1 is the child of another VC, it passes all those variables up to its parent. This means that, as long as they have one VC in common, an object buried deep inside of multiple VCs can access a variable set by an object deep inside another series of VCs.

When variables are to be passed further up than one VC, Moab applies a name space before sending them to the parent VC(s). This way, if variables originating from separate components of a single service have the same name, they will not overwrite each other. A variable's new name becomes the name of its immediate VC and its original name with a period between them (<vcName>.<varName>). For example, if V2 in the image above were passed up to vc1's parent VC, its name would become vc1.V2.

Click to enlarge

The VM service in vc9 pictured above is made up of two VMs services, each containing one VM and two storage mounts. The six child containers each have a job with a trigger that sets a variable. When the variables are passed up from the first VC to the second, they inherit the name of the first VC as part of their own name. If this did not occur, vc9 would have four MtAddr and two IPAddr variables overwriting one another. A job that requests a variable originating from a different VC from its own would most likely receive the wrong information. When configuring a trigger, you can request name spaces in the argument list so that the script only pulls in the desired variable(s).

22.0-D Setting up Workload-Driven Cloud in Moab

  1. Enable VMs and VM-tracking jobs in Moab. See Enabling Cloud Services.
  2. Configure the setup templates using generic system jobs, where the trigger called will interact with underlying systems or resource managers. See Creating a generic system job.
  3. Set up job templates in moab.cfg that define generic workflows for all create VM processes. You will likely create template workflows for other resources as well, such as storage or VLANs. Configure the workflows with job template dependencies for receiving a host name, provisioning an OS, setting up software, or other tasks. Set a single selectable job template to represent the main resource for each workflow. See Creating a cloud workflow and Requesting Name Space Variables.
  4. Create a virtual container to hold the workflow(s) that create the VM. See Creating a VC to Hold a Service.

Related Tasks:

Reference topics:

© 2014 Adaptive Computing