Cloud computing allows computing resources to be used as common utilities, like water and electricity, that are measured by a meter that keeps track of the usage and reports back to the service provider and consumers. In addition, cloud computing keeps track of how many resources and utilities each subscriber is consuming so that service providers can charge them appropriately. Metering systems record resource utilization, such as CPU, memory, data storage usage, and many other related resources that cloud service subscribers consume.

Metering is the basis for throttling and billing, as well. Metering tracks, collates, and calculates the resource usage of every subscriber, which generates the accurate resource usage information by a given time unit and thus becomes the basis of the "pay-per-use" billing model. From another aspect, enterprise private clouds leverage a metering service to show the actual resource usage of every subscriber to ensure computing environment security and availability. For instance, by metering the usage of private cloud resources, subscribers are motivated to release resources to the pool when they have finished with them, thus increasing the overall availability of the private cloud resource pool.

Today, most cloud service providers, including Amazon Elastic Compute Cloud (Amazon EC2) and Microsoft® Windows® Azure™, have their own metering systems. Basically, the design and implementation of the metering component is centered around which data is targeted and available for metering, how utilization data can be collected, and which metering values can be drawn from the collected data.

IBM Tivoli® Usage and Accounting Manager (TUAM) implements metering data collection with data collectors that gather data from different data sources, such as IBM z/VM®, VMware usage collector, and so on. Data is collected and converted into Common Source Resource (CSR) format, and then transferred to the processing servers for further processing. The Tivoli Usage and Accounting Manager integrator and processing engine process the gathered data. The processing steps may differ, depending on the collector used. CSR-formatted data is summarized based on given identifiers, and this data is taken as the input for further processing steps to implement billing or other financial and organizational-level services.

IBM SmartCloud Entry overview

IBM SmartCloud™ Entry (SCEntry) is a robust cloud software offering that takes a virtualized environment from cloud ready to real cloud. It leverages underlying hardware and virtualization management systems like IBM Systems Director VMControl™ and VMware vCenter, providing easy-to-use functions to build up an entry-level private cloud with little effort. SmartCloud Entry enables users to work with virtual appliances and workloads, focusing on the end user perspective rather than the IT or systems administrator perspective. It supports basic cloud operations such as provisioning and de-provisioning, drafting and cloning deployment configurations, power management of virtual servers, and resizing existing servers. Furthermore, it provides features like metering, billing, and approval processing to help IT managers monitor and manage the cloud environment for improved efficiency and utilization of the data center.

Metering, as one of the key components, loosely coupled with other components in SmartCloud Entry, collects virtual server allocation and other usage information from underlying adapters, generates metering records, stores them in a database, and exports the data into file system at given intervals. The high-level architecture of SmartCloud Entry is provided in Figure 1.

Back to top

Architecture and components

The SmartCloud Entry metering service runs on the SmartCloud Entry base service, which provides the base services to all other internal components. The layered architecture and components of the SmartCloud Entry metering service are described in the following sections.

Metering service architecture

The overall metering service architecture is divided into three layers, as shown in Figure 2.

The Data Collection Layer consists of the Event Listener and the Data Refresher, which collect metering data from various computing resources. The Data Transformation Layer receives and processes the metering data that the Data Collection Layer gathers and transforms the raw metering data into an internal format, persisting it to the database. The Data Consumption Layer provides functions like metering data exporting and archiving and also provides RESTful application programming interface (API) interaction with end users.

From a data flow perspective, the metering data flows from bottom to top through these three layers. First, the Data Collection Layer gathers the metering data and transfers it to the Data Transformation Layer for processing and persistence, after which the data is consumed by Data Consumption Layer components. The Data Export Service transforms the metering data to the Usage Detail Record (UDR) format and stores it in files in the local file system. The Data Archive Service cleans up the data that has expired to prevent the database from becoming too large. The RESTful API component provides the interfaces to the SmartCloud Entry user interface and third-party software integration to initiate the data export and archive requests. SmartCloud Entry base services act as the bridge through this data flow and processing, wherein metering components invoke the SmartCloud Entry base service to complete all kinds of metering data processing.

Metering service components

The metering architecture contains many components located at different layers and working for different purposes. This section describes how these components work together and their configuration.

The Data Collection Layer

The Data Collection Layer collects resource usage data like CPU, memory, storage, and virtual server status. Two different mechanisms exist for collecting metering data. The Event Listener uses the Metering Listen mechanism to listen to the SmartCloud Entry base events, which the SmartCloud Entry base service generates. The Data Refresher uses the Metering Refresh mechanism to retrieve the metering data at regular intervals. Basically, Metering Listen is the fundamental mechanism for ensuring complete metering data collection. Meanwhile, Metering Refresh works as a complementary mechanism to avoid information lost in some special cases. Periodically, Data Refresher refreshes metering data through the SmartCloud Entry base service and compares it with the corresponding existing records. As soon as the collected metering data is changed (compared to the existing data), it updates the metering record accordingly, as shown in Figure 3.

For a large-scale cloud environment, each refresh cycle can be time-consuming. Therefore, we don't recommend running this data refresh frequently. SmartCloud Entry provides a configuration property to set the interval in the metering.properties file:

com.ibm.cfs.metering.interval=180

The Data Processing and Persistence Layer

This layer resides in the middle of the Data Collection Layer and Data Consumption Layer. Its components accept raw metering data from the Data Collection Layer, then transform the data to an internal format and persist it to the database. In addition, the Data Processing and Persistence Layer provides internal APIs to a higher layer to query the metering data.

In a production cloud environment, the metering data persisted to the database grows quickly. To avoid bad metering data operation performance, we introduce a cache between the database and other components to cache the latest metering data. Whenever the system needs to compare the existing metering data with the newly collected data to decide whether a new metering record is needed, it gets the latest existing data from the cache rather than having to query existing records from the database. To protect this memory cache from losing data by accident, we persist it as a file to the file system. Whenever SmartCloud Entry recovers from an unexpected termination, metering components recover the cache from this file. Another important file records the latest shutdown time for recovering. SmartCloud Entry updates this file each minute, so if the system shuts down unexpectedly, it is still able to recover the shutdown time, with a deviation of less than 1 minute.

The Data Consumption Layer

The Data consumption Layer consists of the Data Export Service, the Data Archive Service, and the RESTful API. The Data Export Service exports the metering data in UDR format from the database into UDR files.

Each UDR consists of three parts: a Header, an Identifier, and a Resource. The Header is used to record the general properties of this record, such as the start time and end time. The Identifier records the properties that can identify the metering resource that this record describes, such as the workload ID, indicating which workload the target virtual server belongs to. The Resource records how many resources this virtual machine (VM) is using. An example UDR data is shown in Table 1.

This UDR stores all the VM status and other properties between 10:12:34 and 10:22:34. Whenever the status or properties change, SmartCloud Entry creates a new UDR to reflect that change. So, the next record start time should be 10:22:34; with the help of UDR, IT administrators can determine the virtual server status and properties at any specific time. Not only does SmartCloud Entry use the metering data in UDR format, but the data can also be consumed by the Tivoli Usage and Accounting Manager billing system seamlessly.

The Data Export Service exports the metering data to UDR files in a configurable interval, which we set in the metering.properties file like so:

com.ibm.cfs.metering.data.interval=1

The exported UDR files are organized by date within each folder for the UDR files for 1 month. To ensure the data integrity of the UDR files, the Data Export Service creates a digest file for each UDR file that contains an MD5 code generated based on the UDR file content (see Figure 4).

The Data Archive Service is responsible for archiving and cleaning out-of-date metering data from the database to avoid the database becoming enormous. It determines whether the metering data is expired depending on the start time and end time in each metering record and takes archive actions accordingly. Users can configure how long the metering data has been expired in the database by using the following property:

com.ibm.cfs.metering.data.expired.days=370

Be aware that the interval of the metering data export should be less than the time span the metering data has been expired in the database. Even if the archived component deletes the expired metering data from the database, the metering data can still be found in the exported UDR files, so it helps to make sure that no metering data will be lost in the system.

The RESTful API provides access for administrators and users to initiate a data export or data query request, which is forward to the corresponding metering service for processing (see Figure 5).

Different data processing flows generally do not have a sequential relationship, because they can proceed asynchronously or concurrently:

• 1, 2, and 5. The SmartCloud Entry base service notifies the Event Listener if resource consumption or virtual server state changes occur in the cloud. The Event Listener gets these events and transfers the metering data to the metering data processing component, which invokes the persistence component for data persistence.
• 3, 4, and 5. The Data Refresher is called at a given interval to refresh metering data in case metering data changes occur. The SmartCloud Entry base service receives the requests from the Data Refresher to obtain and return the resource usage information of the cloud. The metering data processing component persists this metering data through the metering data persistence service invocation.
• 6. The Data Archive Service starts the archive job at a given interval to clean the historical metering data from the database.
• 7 and 8. The Data Export Service starts the export job at a given interval to export the metering data from the database into the UDR files.
• 9, 10, and 5. Users or third-party applications call the RESTful API to query the metering data. Metering data processing is invoked to query the data from the metering data persistence service, and then return the related metering data to the API consumer in response.

Back to top

SmartCloud Entry metering integration

The SmartCloud Entry metering system provides data-access interfaces for third-party application integration, wherein metering data is integrated through UDR files or JavaScript Object Notation (JSON) messages. The reporting system can use the UDR files to create a metering data report; the billing system can use the files to generate charge bills on resource usage. Third-party applications can retrieve UDR files through SmartCloud Entry in two ways: either by file transfer or through the RESTful API. In the first method, the metering data is configured for export to the target directory, where the third-party application can access and download the exported UDR files. This manner is suitable for third-party applications that have access to the file system on the SmartCloud Entry server.

The alternative way of retrieving the UDR files is to use REST APIs:

• GET /udrfiles. Retrieve all the metering data files in all the folders.
• GET /udrfiles/{directoryName}. Retrieve all the UDR files stored in a given directory.
• GET /udrfiles/{directoryName}/{fileName}. Retrieve the specific UDR file.

Leveraging the RESTful API is a good choice for third-party applications that have no access to the SmartCloud Entry server file system. We use another set of REST APIs to retrieve the metering data in JSON format:

• GET /udrs. Retrieve all the metering data in JSON format.
• GET /udrs/{id}. Retrieve the specific metering data in JSON format.

JSON format is widely accepted in modern applications; therefore, it is more convenient to parse the JSON objects than plain files. Furthermore, we can provide request parameters to support the query with complex conditions.

The typical scenario that follows demonstrates this easy integration with third-party applications. This scenario is related to how to retrieve the metering data of a specific VM for 1 specific month. We provide three solutions:

• Direct file access:
  1. Access the directory that stores the UDR files for the specific month.
  2. Read the UDR files in the folder that have a .csv file extension.
  3. Parse every UDR file line by line.

     Each line represents one individual metering record. Identify the UDR records representing resource usage for the concerned virtual server, and parse those records.

• Using the REST API to access UDR files:
  1. Download the files through the REST API GET /udrfiles/{directoryName}/{fileName} command, where {directoryName} is same as that in the previous solution and {fileName} contains the .csv suffix.
  2. Parse the UDR files in the same way as step 3 in previous solution.
• Using the REST API to obtain metering data in JSON format:
  1. Invoke the REST API GET /udrs?globalObjectId={globalObjectId}&startTime={startTime}&endTime={endTime}, where {globalObjectId} contains the ID of the concerned VM and {startTime} and {endTime} indicate the time interval of the metering records.
  2. Parse the JSON objects retrieved from step 1 to get the metering data.

Back to top

Conclusion

Metering plays an indispensable role in cloud computing systems. It enables us to collect cloud computing resources, calculate metrics, and build up the basis for the upper-layer billing services. IBM SmartCloud Entry implements a metering system with a layered architecture. Two complementary metering data-collection mechanisms are designed to ensure accurate, real-time resource usage statistics. Metering data is processed using a common data format to be consumed by and integrated with third-party applications. IBM SmartCloud Entry also provides mechanisms such as export and archival to facilitate cleanup and maintenance of the huge volume of historical metering data. A set of metering RESTful APIs is provided to support the third-party service for integrating the IBM SmartCloud Entry metering service.

Resources

Learn

• Access IBM SmartCloud Entry Documentation to find more information on configuration and deployment of IBM SmartCloud Entry.
  
  
• Explore the IBM SmartCloud Entry wiki to find updates and support.
  
  
• Refer to the Deployment Guide Series: IBM Tivoli Usage and Accounting Manager V7.1.
  
  
• In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
  
  
• Follow developerWorks on Twitter.
  
  
• Watch developerWorks demos ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
  
  

Get products and technologies

• Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
  
  

Discuss

• Check the IBM SmartCloud Entry product introduction to obtain product introduction and updates.
  
  
• Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• IBM SmartCloud Entry overview
• Architecture and components
• SmartCloud Entry metering integration
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

Learn more, join the cloud community

---

• Community: Cloud computing conversations led by IBM community members
• Buy: Try IBM software on IBM SmartCloud Enterprise

Dig deeper into Cloud computing on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers