The utility metering service of the Universal Management Infrastructure.

Utility computing brings the benefits of reduced IT !information technology) complexity, variable pricing, and reduced operating costs to enterprises. (1,2) Utility services can be infrastructure- of application-level services that are sold on a "pay-as-you-go" basis. To emphasize the on demand characteristic of these services, we refer to them in this paper as "on demand services" (ODSs). This is intended to be a generic term for the technical community and is not to be understood as the name of a product offering or marketing initiative. We describe the architecture of ODSs and the process of their development and present our vision for metering services for ODSs that use the Universal Management Infrastructure (UMI).

ODS architecture. On demand services (ODSs) form a layered hierarchy. Infrastructure ODSs, used by all the higher layers, are at the base. Above these are the application-level ODSs. (3) Both of these layers can be further divided into common and specialized ODSs. For example, a metering or monitoring ODS can be thought of as a common infrastructure-level ODS, whereas a firewall service can be thought of as a higher-level specialized infrastructure service. Likewise, a billing service is an example of a common service at the application level, whereas a supply chain management application is a specialized application-level ODS.

All ODSs use UMI for certain basic services. UMI is both a platform for flexible service delivery and a management discipline to automate the data center. (1) UMI watches the general health of ODSs running on it and provides a stable running environment for them. Our vision for the future of UMI is that after an ODS is loaded, configured, and running in the UMI environment (which consists of a hierarchy of ODSs plus the UMI base), the ODS should not have to ask UMI for any resources or for any specific help. Instead, UMI will monitor the ODS, notice what it needs, and provide the additional resources or corrective actions, as specified by some predefined service management policy. To accommodate the phased implementation of this vision and to allow for dynamic and flexible control by the ODSs as well, UMI is expected to provide some well-architected service programming interfaces (SPIs). ODSs can use these to request UMI services, to alter configurations, or to get information in and out of UMI.

In order for higher-level ODSs to take advantage of lower-level ODSs, there must also be interfaces and protocols for ODSs to talk to one another. It is expected that these interfaces and protocols will be based on Web-service standards (XML [eXtensible Markup Language], WSDL [Web Services Definition Language], SOAP [Simple Object Access Protocol], and UDDI [Universal Description, Discovery, and Integration]). It is expected that a higher-level ODS will serve its customers by occasionally calling lower-level services for the lower-level resources and services that it needs to satisfy its customers. For example, a Web e-mail ODS may need 5 GB of additional disk space to accommodate a request to create 1000 new e-mail accounts, and the ODS would request this from an infrastructure ODS that allocates disk storage. The Web e-mail ODS may want to meter c-mail accounts for their usage, whereas the disk storage ODS may want to meter storage usage (and potentially charge its respective customers based on usage). Both services could take advantage of UMI metering independently, and possibly for completely different purposes (e.g., one service might meter for billing purposes, whereas the other might meter for optimizing performance).

Although much of the discussion of metering applies equally to both infrastructure ODSs and application-level ODSs, in the following sections we will focus on application-level ODSs only, unless otherwise indicated.

The ODS development model and process. The development of an ODS on top of UMI must adhere to certain guidelines and standards, which will be published by the UMI development team. These guidelines and standards lead to a development process that systematically specifies what changes an application has to undergo in order to become a well-behaving ODS in the UMI environment. (IBM's Application Enablement Program [AEe] (4) team helps software vendors adhere to this process for faster and easier deployment.) We will not go into the details of all of these changes, but we will discuss what the ODS needs to be aware of with respect to metering in the section "Metering architecture." Table 1 presents some concepts and definitions that will be used in the presentation of the metering architecture and functions.

The importance of metering. Metering is an essential function in the world of on demand computing. Without a flexible and generalized metering function, the on demand vision cannot be realized. An on demand business, by definition, must be focused, resilient, and robust in response to changing conditions. Metering is essential in implementing systems that support variable cost, resiliency, and responsiveness. Autonomic behavior, which is a fundamental technical characteristic of on demand systems, depends upon implementing a closed-loop control system, at the heart of which is metering.

Metering data is critical because loss of this data can mean a loss of revenue. Some specific examples of the use of metering in on demand systems and solutions include usage-based billing, "charge back" to user departments of a consolidated service, capacity planning, and studying end-user usage patterns for improving customer service or inventing new services.

UMI. UMI is an infrastructure that supports utility computing systems. Some of the underlying concepts of UMI are similar to those underlying a phone company infrastructure, which supports services like local and long distance calls, Internet service, and DSL (digital subscriber line) service. The infrastructure has enough capacity to cope with variation in demand and provides stability for the services. The vision of UMI is to build an environment that provides stability for the ODSs by coping with fluctuating resource needs. (5) It is also meant to promote autonomic behavior of the ODSs so that when they deviate from expected behavior of performance, they can be corrected and brought back to normalcy. This correction is effected by constant monitoring of ODSs and application of prespecified policies when conditions deviate. This kind of autonomic behavior is referred to as policy-based management in UMI. (6)

There are roughly a dozen components which are expected in the initial release of UML The main ones are metering, monitoring, auto-provisioning, SLA (service level agreement) management, portal, billing, ordering, reporting, and helpdesk/change management. The capabilities of UMI are described on IBM'S Internet Web site and elsewhere in this issue. (3,6)

Metering is a key component of UMI and interacts with the UMI components that manage billing, reporting, and monitoring. The metering function of UMI is designed to handle usage metering of both system-level resources and application-level re sources as the application services (i.e., ODSs) are exercised by their end users.

In the remainder of this paper, we discuss the role and implementation of metering services generally and their importance in the provision of ODSs. We review the metering service architecture and describe the metering service function of UMI (and its benefits) in the context of utility computing services.

It should be noted that the descriptions of UMI, metering architecture, and its implementation that are presented here should be viewed as intended directions and not as commitments to be delivered in IBM products. The actual functions and features delivered in UMI releases may vary considerably from what has been described or referenced in this paper.

Metering

Requirements for a metering service pertain to the metering agent and the metering engine. Flexibility is a pervasive requirement. Of course, there are also general requirements like scalability, reliability, and availability that apply to the metering service as a whole. Table 2 summarizes these requirements.

In addition, it is useful to distinguish between metering and monitoring (7) functions. Table 3 presents the main distinctions between these two functions, emphasizing that metering, in contrast to monitoring, typically involves observing usage of a resource without interpreting the usage, tying those observations to a user or account, or retaining them for purposes of auditing.

Finally, one may observe that there are similarities among metering, monitoring, and SLA (service level agreement) management components. They all depend on raw measurements (or observations)--in fact, the "sensors" that provide these raw measurements could be the same for all three. The computations, transformations, and threshold logic applied to these measurements differ in each component, but they all have the same basic design pattern. The pattern has three parts: (1) collect the raw measurements, (2) process them in flexible ways (a processing engine), and (3) consume the processed results in order to effect changes in the larger system. This design pattern is shown in Figure 1. In the following sections we will expand on this basic design pattern as it applies to metering.

[FIGURE 1 OMITTED]

Metering architecture

In this section, we describe the entities of which the metering architecture is comprised and the interface protocols that the architecture supports.