Policy-based automated provisioning.

A utility computing system is a system for creating and managing multiple instances of a utility service within a shared IT (information technology) infrastructure. (1) A service provider maintains an aggregation of computing resources that can be allocated to different services. Customers of the utility computing system request access to services of particular types, and instances of these services are provisioned to meet their needs.

In IBM's on demand architecture, each instance of a utility service is called an "utility computing service environment" (UCSE). In creating the UCSEs, requests are made to resource managers (RMs) that keep track of certain types of resources, their allocations, and availabilities. There typically are RMs for servers, storage, switches, routers, middleware, and so forth. The RMs provide resources to the UCSEs, which are appropriately configured to meet the functionality and performance requirements of the particular service being supported. This will be described in greater detail in the section "Background."

Policies are considerations designed to guide decisions on courses of action and can be used for numerous purposes within utility computing systems. The service provider responsible for the computing environment manages the policies, which determine how the environment is shared; for example, which customers have priority, how reservations are managed, how costs are allocated, and so forth. A service provider with various environment instances (aggregations of computing resources) manages policies such as how each instance should be configured and operated, how performance should be measured, what to do in case of component failures.

The RMs that administer pools of specific computing resources manage policies regarding how resources are reserved, whether overbooking is allowed, how resources are monitored, and so forth. Resource-specific policies depend upon the characteristics that are associated with particular resource types: for example, storage systems have different characteristics (space allocated, striping, access control) than networks (bandwidth allocation, packet loss rate). A policy framework provides a general, formalized way of controlling such customization and variability within a system through the use of policies.

As described in Reference 1, a utility computing infrastructure architecture has been defined, and instances of it are being developed in order to validate its usefulness and completeness. Policy-based technologies are also being defined, (2) and standards are evolving in certain areas. (3) These technologies, however, are still not very mature, and the structure of policies and the interrelationships among them are described differently in different systems. It is thus of interest to investigate how policies can be applied to utility computing systems, what types of policies are needed, and how they extend the capabilities of the overall environment.

In the next section, the utility computing infrastructure is presented and its principal architectural components described. In the section "Policy-based computing," the concept of policy-based management and a general framework for its application is introduced, and in the section "Policy enablement," we show how policy-based technologies can be applied to the utility computing infrastructure.

In the section "Utility computing policies," we describe the types of policies that might be used within such a system and how they may interrelate. In general, the policy architecture must capture the details of the various policy rules in a policy schema and establish how policies are created and enforced within the system. It must also indicate how policies are related to other system decision-guiding structures like service level agreements (SLAs) and rules. This is covered in the section "SLAS, policies, and rules," where it is also noted that certain resource policies may be derivable from higher level aggregate policies of business objectives, while others have to be directly specified.

In the section "A gaming service example," a detailed description of a gaming service is presented, along with specific policies that can be used in its operation. We discuss the principal sources of the policies for such a service and how they are deployed. Finally, in the section "Conclusions," we comment on the status of efforts in this area, conclusions that can be drawn, and projected future work that should be undertaken to advance the state of policy-based systems.

Background

A utility computing system creates and manages multiple instances of a utility service, each of which provides application functions to customers. Each UCSE offering defines a UCSE type that can be built and deployed on demand. Environments that are good candidates for instantiation as UCSEs are those that need a significant number of resources for a short period of time, those that have complex requirements so that users may not have the skills or time to deploy them, and those that have resource needs that vary over time and can thus take advantage of a shared resource pool. A utility computing system can rapidly deploy complex UCSEs that dynamically and autonomically adjust capacity, using the services that the utility computing system provides.

Customers subscribe to on demand services (ODSs) using the OGSA (Open Grid Services Architecture) business-provisioning service (OBPS). The OBPS contains facilities supporting subscription, authentication, metering, SLA management, pricing, and rating. In addition to the OBPS, the utility computing system contains an OGSA distributed resource manager (ODRM). The ODRM is responsible for instantiating and managing the UCSEs. Once a UCSE has been created in response to a request to the OBPS, the customer accesses the service directly. The principal architectural components that comprise the utility computing infrastructure are shown in Figure 1.

[FIGURE 1 OMITTED]

The ODRM contains a planner whose purpose is to build workflows that create, configure, and adjust the working set of resources for the UCSE. When a user subscription is processed, an ODS instance for the environment is generated. The workflows created by the planner are stored in the new instance service. To generate the workflow, the planner uses input from the parts catalog and its referenced resource managers and from resource services (RSs), an ODS template, and the policy database. The information collected from these sources is described in Table 1.

The planner first builds a parts topology tree, the leaves of which correspond to operations on RMs or RSs. The leaves of the tree encapsulate the operations that need to be performed to build the ODS environment. Workflows are generated by collecting all of the operations referenced in the topology tree's leaves. Each workflow must ensure that every variable is generated by a process that computes its value before it is passed to any other process as an input.

After the ODS instance is instantiated with its workflow set, the reservation workflow can be invoked. It is not until this workflow has been successfully run that the reservation can be accepted and committed to the system. At activation time, the "create" workflow moves resources from the free pool and configures them appropriately for the new ODS environment that they will support.

Policy-based computing

The Internet Engineering Task Force (IETF) has adopted a general policy-based administration framework that consists of the four basic elements shown in Figure 2: a policy management tool, a policy repository, a policy decision point, and a policy enforcement point.

[FIGURE 2 OMITTED]

Administrators define the policies that they wish to use in the operation of the system with the policy management tool. Once defined, these are stored in a policy repository. In order to ensure interoperability across products from different vendors, information stored in the repository must follow an information model specified by the IETF's Policy Framework Working Group. (4) The actual points within the system software at which policies are executed are known as policy enforcement points (PEPs).

Instead of communicating directly with the repository, policy enforcement points use intermediaries known as policy decision points (PDPs). The PDPs are responsible for interpreting the policies stored in the repository and communicating them to the associated policy targets in whatever format is appropriate. Associated PEPs and PDPs may be in a single device or in different physical devices. Different protocols may be used for various parts of the architecture, for example the COPs (Common Open Policy Service) protocol (5) or SNMP (Simple Network Management Protocol) (6) can be used for communication between PDPs and PEPs, and the policy repository can be a network directory server that is accessed using LDAP (Lightweight Directory Access Protocol). (7,8)

The Distributed Management Task Force (DMTF) is also involved in the creation of policy standards. A high-level policy schema is included as part of the overall common information model (CIM) schema. (9) This defines policies as "condition, action" rules that can be aggregated into policy sets that have policy roles.