 |
2.1.2 Utility Computing Hosting Center Initial Configuration
2.1.2.1 Configuration Overview
The initial steps associated with configuring a typical hosting center include the following:
2.1.2.2 Enable Resource Monitoring
Moab supports the ability to monitor and manage virtually any type of compute resource or service. The Utility Computing Monitoring section covers needed configuration steps in detail.
2.1.2.3 Enable Resource Provisioning
Resource provisioning entails customizing and configuring available resources to meet specific customer needs. In the case of compute hosts, this step may include installing a new operating system or new application software. For networks, it may include creating a request specific VLAN and configuring guaranteed bandwidth. For data servers, it may include creating virtual data sandboxes with disk quota and security policies in place.
Regardless of the specific needs, enabling resource provisioning consists of providing a mechanism whereby Moab can dynamically modify or provision these resources to meet the needs of a new virtual cluster. The process of enabling each resource includes providing an interface whereby Moab can request the specific change and detect potential failures in fulfilling the request. The provisioning interface can be wrapped as needed and can use resource command line interfaces, APIs, expect scripts, or whatever method is needed to perform and monitor the change.
Once these interfaces are in place, they will be called by triggers from within Moab with timings and dependencies orchestrated to maximize resource efficiency and minimize customer response time.
Example
RMCFG[compute] TYPE=NATIVE CLUSTERQUERYURL=resquery.pl RSVPROFILE[X] TRIGGER=provisionme.pl ...
2.1.2.4 Identify Complete Virtual Cluster Packages
A virtual cluster can consist of many components, including but not limited to a virtual LAN, file space, software licenses, compute resources, and host based authentication. These requirements can be site specific and even query specific. Moab allows administrators to define pre-packaged virtual clusters using the VCPROFILE parameter within the moab.cfg file. An example of how to define a virtual cluster profile follows:
.... VCPROFILE[packageA] QUERYDATA='nodefeature=head,minnodes=1,offset=-2:00,rsvprofile=head,label=head' VCPROFILE[packageA] QUERYDATA='gres=vlan:1,rsvprofile=vlan,label=vlan' VCPROFILE[packageA] DESCRIPTION='co-allocation of the head node and ip address' VCPROFILE[packageA] OPRSVPROFILE=compute VCPROFILE[packageA] REQSTARTPAD=1:00:00 VCPROFILE[packageA] REQENDPAD=1:00:00 .....
When this package is selected it will automatically reserve one head node two minutes before everything else and associate it with the RSVPROFILE head. It will also reserve one VLAN and associate that reservation with the RSVPROFILE VLAN. The DESCRIPTION is simply a string describing what this package does. The OPRSVPROFILE will associate the user-requested resources with the RSVPROFILE compute. Finally, no matter what duration is asked for by the user, this package will pad the final reservation with one hour up front and one hour at the end. (This can be used for provisioning and cleanup, respectively.)
If needed, the QUERYDATA can be overridden by using the label parameter. To override the head QUERYDATA specify the following (in an mshow command):
-w label=head,[override request]
This will override every parameter in the QUERYDATA with label=head with whatever the user specifies.
Many VCPROFILE lines can be included and defined in the moab.cfg file enabling sites to pre-configure virtual cluster packages for users.
2.1.2.4.1 Generating a Complete Resource Request
Creating a fully operational virtual cluster often requires pulling together numerous resources. As mentioned previously, these resources may include such things as compute hosts, file space, software licenses, a network VLAN, and an externally available IP address. In most cases, there are a number of resources pulled into a virtual cluster that are mandatory and should not be configurable by the user. As there is significant value in minimizing the complexity presented to a customer when requesting a virtual cluster, Moab provides a virtual cluster package object that allows customers to specify only a small subset of configurable resources and allows Moab to handle the aggregation of all other resources behind the scenes. For example, using virtual cluster packages, a user could request four Opteron nodes and Moab would automatically integrate the required network, data, and software license resources into the request.
2.1.2.4.2 Querying Resource Availability
Before creating a virtual cluster, a query must be run to determine when and where resources will be available to allocate to the cluster. Once resource monitoring interfaces are defined as shown in step 18.1.2.2.1, the raw information needed to support this query will be automatically collected from all potential cluster resources. With this information, Moab determines what resources can be co-allocated and provisioned as needed to pull together a complete virtual cluster. In response to the query, Moab reports a number of timeframes during which it can guarantee resource availability needed to satisfy all virtual cluster requirements as well as meet all service level agreements and quality of service policies (described later).
Normally, this query and the associated response processing are handled via the user interface (described later). However, this query can also be manually performed for testing and diagnostic purposes using the mshow command. This command allows a requester to specify specific resources and time requirements and get a response indicating how many matching resources are available and when.
2.1.2.4.3 Committing the Resource Request
Once it is known which resources are available and when (using the Transaction ID), these resources can be committed using the mschedctl -c vpc command. When committing these resources, various other aspects of the virtual cluster can be specified, including the following:
- owner - the user/group/account that owns this virtual cluster
- variables - any pre-populated variables that may be of use in executing triggers
- messages - messages to attach to this virtual cluster
- user - the user ID under which an optional system job can run (for statistics and reporting)
|
|