Smart Metering of Cloud Services

(1)

Smart Metering of Cloud Services

Akshay Narayan

Gaurav Ranjan

Kumar D

Pavithrra V

Vasudha S V

[email protected]

International Institute of Information Technology Bangalore http://www.iiitb.ac.in/

Technical Report IIITB-OS-2011-5A

April 2011

(2)

Smart Metering, prevalent in the power grids is a billing model where, the consumers are charged variable rates for the power consumed based on the load conditions of the grid. A similar model is developed for the Cloud Services in this project.

The idea of Smart Metering of Cloud Services is to prevent wastage of com-pute power in low load conditions and improve the overall utilization of the cloud infrastructure. This objective is achieved by developing a varying tariff model based on the load prevailing on the cloud infrastructure.

In this project, a mapping between the load condition for a particular time period and the pricing is achieved. Time period of utilization of the cloud service is divided into time slots. The pricing for every time slot is published and consumers can query for the same. It is the consumer’s discretion to continue using the service or suspend the usage for the time period.

In the current implementation, a prediction of the load condition of the cloud infrastructure is obtained based on the previous load history. Statistical model, arima is used for this prediction. A prediction accuracy of up to 96% is achieved.

Monitoring of the cloud infrastructure is performed using Hyperic, an open source monitoring framework. Hyperic SIGAR framework is used to monitor the per-consumer usage of compute resources. In the current setup, the implementation can scale up to three cloud instances.

The pricing information obtained as a function of load condition is used for billing the consumers. The bill amount is a function of pricing for a time slot and the corresponding utilization of compute resource. The calculated bill is produced to the consumer.

Project URL: https://sourceforge.net/projects/smartmetering/

c

2011 Akshay Narayan, Gaurav Ranjan, Kumar D, Pavithrra V & Vasudha SV This material is available under the Creative Commons Attribution-NonCommercial-ShareAlike License. See http://creativecommons.org/licenses/by-nc-sa/3.0/ for details.

(3)

CONTENTS

List of Figures

1 Smart Metering - Architecture . . . 10

2 Smart Metering - Administrator Use case . . . 12

3 Smart Metering - Consumer Use case . . . 13

4 Smart Metering - Work flow . . . 14

5 Smart Metering - Cloud Setup . . . 16

6 Smart Metering - Database Schema . . . 19

7 ARIMA - Order Vs Prediction . . . 27

8 ARIMA - Prediction Vs Actual . . . 27

(5)

1. INTRODUCTION

1 Introduction

Cloud computing [1] provides for three categories of services namely, Infrastruc-ture as a service, Platform as a service and Software as a service. The set of cloud services such as computation, storage and network are packaged as a computing re-source and provided as metered utility service. Cloud services are sold on demand, both duration and quantum and are fully managed by the service providers. Multi tenancy [2] and on demand acquisition model make it very important to have a robust metering and billing mechanism.

Smart meters [3] in the power domain are hardware devices which perform real-time registration of electricity usage. They allow obtaining the usage information both locally and remotely. These smart meters offer a two way communication between the consumer installation and the power grid which facilitates regulating the power consumption via the meter installation.

Current implementation of metering mechanism [4] in cloud environment is based on a service level agreement which govern the provisioned capacity. It is a fixed-cost, post-paid service model. The limitation of this model is that, the consumers are billed based on a predefined tariff for the utilization.

This project caters to the need of a metering application in the cloud service context. The Smart Metering application is a software that provides for dynamic pricing of the cloud service based on the load condition of the cloud infrastructure. Resource usage per cloud instance is recorded and the consumer is billed accord-ing to two factors, his utilization and the load on the cloud duraccord-ing the period of utilization. The Smart Metering application facilitates improving the overall uti-lization of the cloud infrastructure, by implementing a varying tariff model based on the load prevailing on the infrastructure.

Rest of this section introduces the problem statement, similar systems and gap analysis. Section 2 details the system design including the pricing and billing model implemented in the application. Architecture and use cases are also presented in section 2. Section 3 details the implementation of various elements described in the design. This section includes the pseudocode for the modules developed. Performance metrics and results are presented in Section 4. Section 5 presents some conclusions and scope for further development.

(6)

1.1 Problem Statement

The project is aimed at developing a technical model and an implementation of smart metering of cloud services. The project caters to the need of a dynamic pay-per-use model in the cloud environment based on real time pricing of the cloud service. The aim of this dynamic pay-per-use pricing model is regulation and improvement in overall utilization of the cloud infrastructure.

With respect to the consumer, the computing resource needs may be time variant. The prevalent billing model [5] does not provide for a robust dynamic pay-per-use mechanism. There is a need to develop a smart metering mechanism which enables the consumer to be billed per usage based on dynamic tariff plans.

This also enables the service provider to effectively manage the computing re-sources by having smart tariff plans based on the load condition on the infras-tructure. We propose to solve the aforementioned problem to achieve a dynamic metering and billing mechanism for cloud services in this project.

The result of the project is aimed to be analogous to the smart metering in power

grids [3] [6].

1.2 Similar Systems & Gap Analysis

Smart metering and smart tariff is implemented in power grids in various countries across the globe [7]. These systems are related to physical entities like electricity, natural gas and potable water. These implementations are mainly concerned with the implementational hardware and communication system between the power meters and the central control hub.

Commercial cloud service providers like Amazon provide for spot instances [8] which function based on bidding for the cloud instance. It works based on the bid amount which is the maximum price the consumer is willing to pay for the instance per hour.

Gap Analysis

The Virtual platform architecture for resource metering in data-centers [9] that is mostly implemented in private clouds provide for a pay-as-you-go billing

(7)

mech-1. INTRODUCTION

anism. However, this implementation does not provide for dynamic metering. The billing mechanism is based on a predefined static pricing information. Also the literature indicates usage of Virtual Platform Architecture, which may not be completely applicable to a cloud infrastructure that is deployed by cloud service providers.

The other existing systems for dynamic charge-back like Amazon Spot Instance [8] provides for a restrictive usage of cloud resources. Resource provisioning is based on the bid amount for the unused capacity. Once the cloud pricing amount increases beyond the bid amount, the cloud instance is terminated.

The smart metering implementation proposed in this project aims at providing a dynamic billing mechanism for cloud service providers. The service provider specifies a pricing based on the current load on the cloud using the smart metering module. It is then the consumer’s discretion to continue using the cloud instance by paying the specified amount or to terminate the cloud instance.

(8)

2 System Design

2.1 Definitions

1. Pricing rules:

Service provider specified pricing information corresponding to the load on the system.

2. Load Range:

The difference between maximum and minimum load values between which a price value holds.

3. Threshold load:

The load values on the cloud, which specify the load condition.

4. Instance:

A virtual machine deployed on the Eucalyptus cloud infrastructure.

5. Current price:

The cost of utilizing the cloud service in a specified load condition. This is obtained from the pricing rules specified by the service provider and the current load estimated.

2.2 Billing Model and Pricing

Pricing and billing are two important aspects addressed in the Smart Metering implementation. This section describes the mechanism of pricing and billing.

Pricing

Pricing for a cloud service can be applied based on multiple considerations. Current service providers like Amazon [10] and Rackspace [11] price the cloud instance mostly based on the configuration and duration of use. Another prevalent practice is to charge the consumers of fixed price for a lease period like the Amazon reserved

(9)

2. SYSTEM DESIGN

Smart Metering proposes pricing based on the operational cost of running the service. In this pricing model base cost of running the service is specified by the service provider, C_base.

Pricing rules which define the pricing overhead for running the service under vari-ous load conditions are specified by the service provider, Cloadi, where t is the time

instance of operation.

Current price, P_tfor the instance at a given load condition is given by equation 1.

Pt= Cbase∗ Cloadt (1)

Where,

Pt→ operational price at time t

Cbase→ base operational cost

Cloadt → cost of running the service under load loadt at time t.

Billing

Dynamic billing on cloud is a function of the instantaneous load on the cloud and the pricing information obtained as per the configuration specified by the service provider. Billing calculations involve determining the overall load on the cloud over a recent history and obtaining a weighted sum of the load on the entities and the corresponding pricing information as described above.

Overall load Lton the cloud infrastructure at time t is the summation of the load

on every node as given by:

Lt= n X i=1 li (2) Where,

Lt −→ total load on the cloud at time t

li −→ load index of the individual cloud component.

The load obtained in equation 2 is mapped to a corresponding pricing value at a given instance of time, t.

(10)

The billing amount is computed as a summation of the product of instantaneous pricing obtained in equation 1 and the utilization of the consumer, ut. Total bill

amount is obtained as in equation 3

Bill = n X t=1 Pt∗ ut (3) Where,

Pt→ operational price at time t

ut→ resource utilization of the consumer at time t.

2.3 Architecture

(11)

2. SYSTEM DESIGN

The main components of the Smart Metering application (indicated in Figure 1) are:

• Smart Meter module.

• Hyperic monitoring framework.

• Hyperic SIGAR framework.

• Backend database.

• Thin client UI.

The functioning of each of the component is described in this section.

Smart Meter uses the service of Hyperic [12] open source system monitoring tool to monitor the compute load on the cloud infrastructure. Eucalyptus [13] cloud, deployed on Ubuntu server (version 10.10) is used to host the cloud instances. Smart Meter uses a MySQL database backend to store the application data. Hy-peric SIGAR API [14] is used to monitor the individual cloud instances.

Hyperic is configured to monitor the load on the cloud every five minutes or every fifteen minutes as the configuration specifies. All other monitoring configurations are disabled currently. In its current form, the application does not compute the load on the network or storage to handle the metering and billing of cloud services. The application records the information about every deployed cloud instance. In the current form, the information about the deployed instances have to be manually fed by the administrator. This is later utilized for billing purpose.

The Smart Meter application utilizes the statistical model ARIMA [15] to obtain the time series prediction of load.

A mapping of the load to pricing is maintained in the application database, which is configurable by the service provider. Based on this mapping, the pricing for a time slot is published to the consumers. The consumer then decides to continue utilizing the cloud service or terminate the instance.

The mapped price is later used to generate billing information on a per consumer basis.

(12)

Figure 2: Smart Metering - Administrator Use case

2.4 Use Cases

Use case - Administrator

This use case is depicted in the Figure 2.

The administrator or the cloud service provider controls the pricing and the load thresholds that govern the working of the Smart Meter. Interfaces are provided to the cloud service provider to change the pricing rules and threshold values.

Pricing rules define the mapping between the load condition of the cloud and the

pricing for the load period.

The administrator is also able to monitor the number of users on the cloud at any given instance of time and the usage statistics of cloud as well as every deployed

(13)

2. SYSTEM DESIGN

Figure 3: Smart Metering - Consumer Use case

instance.

The threshold values define the transitions between each defined load intervals. Smart Meter application uses the services of Hyperic monitoring tool and Hyperic SIGAR API to monitor the cloud infrastructure.

Use case - Consumer

This use case is depicted in the Figure 3.

The consumer can view current pricing and obtain his usage statistics via the Smart Meter interface.

(14)

cloud instance.

2.5 Module Interaction

The interaction between various modules in the Smart Meter application is as indicated in Figure 4. The working of each of the modules is explained in the rest of this section.

Figure 4: Smart Metering - Work flow

Data Collection

Smart Metering application avails the service of Hyperic monitoring framework to monitor the load on the cloud infrastructure and Hyperic SIGAR framework to retrieve the individual instance resource utilization.

(15)

2. SYSTEM DESIGN

Data collection (VM Instances)

Process ID (PID) of the kvm process containing the cloud instance is identi-fied and SIGAR API is invoked to retrieve resource utilization data for the identified process. SIGAR API returns the percentage CPU Utilization for the process whose PID is passed as argument. This process is repeated for all cloud instances listed in the application database.

Data Collection (Cloud Infrastructure)

Hyperic getMetrics() API is used to obtain the load average of a node in the cloud infrastructure. This API returns load values as a list to the caller.

Load Prediction

Load prediction in the Smart Metering application is done based on time series analysis. The monitored load data forms a time series with predefined intervals. Arima, a statistical model is used to predict the load for next interval.

Billing

The Smart Meter module maintains a mapping of the load to price. The load predicted above is mapped to a corresponding price value. This is used along with the utilization recorded for the instance and the bill is generated as the product of the two values mentioned.

Backend Database

MySQL is used as the back end database to maintain the application data. The database schema is explained in section 3

(16)

3 Implementation Details

3.1 Cloud Setup

Figure 5: Smart Metering - Cloud Setup

Eucalyptus was deployed on Ubuntu Server Version 10.10 for the project. The cloud controller, cluster controller and walrus storage engine setup was deployed on a Net-book running Intel Atom 1.6GHz processor with 1GB RAM. The node controller was installed on a more powerful Intel Core i7 based Dell laptop with 4GB RAM. The client machine was also installed on the same machine as the node controller.

The cloud deployment is analogous to Figure 5.

The instructions in the ”Eucalyptus Beginners guide” [16] were followed to deploy the cloud setup.

3.2 Monitoring

The monitoring tool for cloud infrastructure was chosen such that the basic criteria mentioned below are satisfied.

• Scalability: The monitoring tool must be scalable to at least one thousand nodes.

(17)

3. IMPLEMENTATION DETAILS

• It should have zero or minimum impact on the monitored machines’ resource utilization.

• The tool should automatically start monitoring the devices added dynami-cally in the infrastructure.

• It should consume minimal network bandwidth during data collation as net-work bandwidth in the cloud comes with a cost overhead.

• The same tool must be able to monitor various system resources like compute power, bandwidth and storage.

• Programmatic access to monitoring data should be provided by the tool, in the form of API.

Hyperic [12] was was chosen among the evaluated tools, which include:

• Nagios

• Hyperic

• Zabbix

Hyperic HQ

Some of the main features of Hyperic HQ include auto discovery of system re-sources, services running on machines, monitoring resources and applications, per-sisting monitored values in database, administration of software resources, alerts and notification etc.

Hyperic API’s are used to fetch the metric data programmatically from the database created by Hyperic. Hyperic scalability benchmarks can be found in the ”Hyperic HQ and MySQL Backend Performance Study” [17]

The Hyperic SIGAR API is exclusively used to monitor the deployed Virtual ma-chines. This is necessary to obtain the usage information on per instance basis. This information is used to generate the bill.

(18)

3.3 Load Prediction

Based on historical data collected through monitoring framework, the future load is predicted in the Smart Meter application. Predicting load plays an important part in the Smart Meter to publish an indicative pricing of the cloud service for the next time slot.

In this project ARIMA is used to predict the load based on the cloud based on the metric data collected from the Hyperic monitoring tool.

ARIMA

The Auto Regressive model assumes that the current value of a process xt, can be

described by a finite linear aggregate of the previous values of the process along with the current value of a white noise signal a_t. Generally, AR models (denoted as AR(p)) are described using the following equation

xt= ϕ1xt−1+ ϕ2xt−2+ L + ϕpxt−p+ at (4)

Where,

at→ the unpredictable white noise sequence with zero mean and variance of σa2

ϕ1, ϕ2, ϕp and L → coefficients of AR model with p as the number of coefficients.

If the p coefficients of AR models were estimated from the past data, the one-step-ahead prediction of this AR model can be estimated using these p coefficients along with the p historical data, xt−1, xt−2, L, xt−p

Mathematically this is described as follows:

ˆ

xt= ϕ1xt−1+ ϕ2xt−1+ L + ϕpx + t − p (5)

Where, ˆ

xt→ one-step-ahead prediction value of time t

The parameter p of AR models is the number of historical data points it uses. Run time cost increases if a higher order is used in the AR model to predict the load. If order chosen is too less, it results in an erroneous prediction.

We assume to have a dedicated machine for smart metering and hence use a higher order value for p. In [18], Dinda defined the space of order p to be explored is from

(19)

1 to 32. And his recommendation is to use AR models of relatively high order (16 or better) for load prediction. Hence AR (16) model which is equivalent to

ARIM A(16, 0, 0) is used to predict the CPU load for Smart Metering application.

3.4 Database Schema

The database schema used for the Smart Meter application is as shown below in Figure 6.

Figure 6: Smart Metering - Database Schema

The purpose of the tables is as listed below:

• customer info:

Stores informations about every customer.

• pricing info:

(20)

• time slots:

Contains time interval in which the readings will be taken and pricing will be calculated.

• customer usage:

Stores the usage of all the customers at every time slots of the day. This table is populated using data from SIGAR APIs .

• cloud load:

Stores the actual and predicted state of load on cloud at every time slot.

• usage price:

The calculated usage price per time slot is stored in this table.

• monthly bill:

Contains the total usage and total monthly bill for every customer.

3.5 Pseudocode Listing

This section lists the pseudocode for various modules implemented in the Smart Metering application.

Data Collection

Data Collection VM Instances

The method getVMStats() invokes the SIGAR API getProcCpu(). PID of the KVM process containing the cloud instance in question is passed as the argument to collect resource utilization data. The percentage CPU utilization returned by getProcCpu() is captured in vmCpuUsage.

The above process is repeated for all cloud instances listed in the application database (listOfVM). The procedure is listed in Algorithm 1.

Data Collection Cloud Load

The method getLoad() invokes Hyperic getMetrics() API. The unique identifier of the node controller is passed as a parameter to getMetrics(). The number of data points to be returned is configurable. getMetrics()

(21)

API returns a list containing the load average values collected at every one, five or fifteen minutes.

The process is repeated for all registered node controllers. The procedure is listed in Algorithm 2.

Algorithm 1: Data Collection VM Instances Data: vmCpuUsage

Data: list listOfVM Data: pid begin getInstanceUtilization while true do foreach listOfVM[ 1 ... n ] do vmCpuUsage ← getVMStats(pid) store(vmCpuUsage, timestamp) end end end begin getVmStats Data: pid Result: vmCpuUsage vmCpuUsage ← sigar.getProcCpu(pid) return vmCpuUsage end Load Prediction

Data Fitting & Prediction

The load data obtained earlier using getCloudLoad() which is a time se-ries has to be fit into the arima model. The predictLoad() method uses ARIMA.fit() method to achieve this objective. Prediction of the next load instance is done by the ARIMA.predict() method. These methods are avail-able as a part of R programming language. Smart Metering application uses the rJava interface to interact with R.

(22)

Algorithm 2: Data Collection Cloud Load Data: list loadDataPoints

Data: list nodeControllers begin getCloudLoad while true do foreach nodeControllers[ i = 1 ... n ] do loadDataPoints ← getLoad(nodeControllers[i]) return loadDataPoints end end end begin getLoad Data: nodeController Result: loadDataPoints loadDataPoints ← hyperic.getMetrics(nodeController) end

information is published to the consumers. The map() method performs a table look up for the predicted load to obtain a corresponding pricing information. The predictedPrice is returned to the calling function.

These procedures are listed in Algorithm 3.

Billing

The actual resource utilization of instance obtained using the getInstanceUtilization() method defined earlier and the predictedPrice obtained using predictPrice()

method are stored is the SmartMetering database along with the timeStamp. These two values are used to generate the bill amount for a particular cloud in-stance.

Retrieve CPU Utilization

The getCpuUsageAtTimeStamp() method executes an SQL query to retrieve the stored CPU utilization of every cloud instance. timeStamp is passed as a parameter to this method.

(23)

Algorithm 3: Load Prediction Data: list loadValues

Data: double predictedLoad Data: double processUtilization Result: predictedPrice begin predictPrice while true do loadValues ← getCloudLoad() predictedLoad ← predictLoad(loadValues) predictedPrice ← map(predictedLoad)

This predicted price is published to the consumers. store(predictedPrice , timestamp) end end begin predictLoad Data: loadValues Data: predictedLoad Data: arimaRef arimaRef ← ARIMA.fit(loadValues) predictedLoad ← ARIMA.predict(arimaRef) return predictedLoad end begin map Data: predictedLoad

Data: constant LOAD TO PRICE TABLE Result: predictedPrice

for predictedLoad in keys of (LOAD TO PRICE TABLE) do predictedPrice ← LOAD TO PRICE TABLE[predictedLoad] end

return predictedPrice end

(24)

Retrieve Price Information The getPriceAtTimeStamp() method

exe-cutes an SQL query to retrieve the predicted price at given timeStamp.

These procedures are listed in Algorithm 4.

Algorithm 4: Generate Billing Data: vmCpuUsage Data: predictedPrice Data: timetamp Data: listOfVM begin generateBill foreach listOfVM[ i = 1 ... n ] do vmCpuUsage ← getCpuUsageAtTimeStamp(timestamp) predictedPrice ← getPriceAtTimeStamp(timestamp) billAmount ← vmCpuUsage * predictedPrice

store(listOfVM[i], billAmount) end end begin getCpuUsageAtTimeStamp Data: timestamp Result: vmCpuUsage

vmCpuUsage ← get vmCpuUsage at timeStamp=timestamp return vmCpuUsage

end

begin getPriceAtTimeStamp Data: timestamp

Result: predictedPrice

predictedPrice ← get predictedPrice at timeStamp=timestamp return predictedPrice

(25)

4. OBSERVATIONS AND RESULTS

4 Observations and Results

Results

Load to price mapping

A configurable load to price mapping was achieved in this project. The basic operational cost specified by the service provider and the pricing rules form the basis of this mapping. A sample mapping is listed in Table 4.

Load Start Load End Base Price Price Multiplier

0 1 100 0.2

1 2 100 0.5

2 3 100 1

3 4 100 2.5

4 20 100 7.5

Table 1: Load to Price Mapping

Dynamic tariff

A tariff plan based on the above mapping was developed. Varying tariff based on the load condition of the cloud infrastructure was achieved. Table 4 depicts a sample dynamic tariff generated by the application.

Load Condition Load Average Price (in Rs.)

Low 1.76977 50 Low 1.19032 50 Medium 2.04024 100 Medium 2.53133 100 High 3.56575 250 High 3.48933 250 Extreme 9.44684 750 Extreme 8.19211 750 Extreme 4.69272 750

Table 2: Load to Price Mapping

(26)

generating an itemized bill per consumer and per instance basis. A sample of the itemized billing for one consumer in the database is listed in Table 4

Instance ID Usage Price ( in Rs)

i-3A1806E8 5.75 1148

i-40CF0798 15.65 3357.5

i-666A0B5F 1.1 882.5

Table 3: Itemized Usage

Performance Metrics

This section of the document lists the performance metrics evaluated as a part of the project.

ARIMA Order for Prediction

Smart Metering application uses previous 200 data points to predict the load of the next time interval. For this input size, it was experimentally determined that an order of P = 8 or P = 9 in ARIM A(P, D, Q) results in a prediction close to the actual load condition. The plot of Order Vs Prediction is shown in Figure 7

Prediction

Using ARIMA model a prediction accuracy of up to 96% was achieved. However, the error factor is high when there is a steep jump or a steep drop in the load average. This behavior can be observed in the plot shown in 8

Time to Query

It was observed that the time to query the data from Hyperic gradually increased as the load on the machine increased. However, the time to query was always within acceptable limits. Peak time to query being around 120ms when the corresponding load average was recorded as 7.5. A plot of this data is show in Figure 9

(27)

4. OBSERVATIONS AND RESULTS

Figure 7: ARIMA - Order Vs Prediction

(28)

Figure 9: Hyperic Performance - Query Vs Load

5 Conclusion

An effective mapping between price and load was obtained in the current imple-mentation of Smart Metering. Using this mapping a dynamic pricing of the cloud services based on the load condition of the cloud infrastructure was achieved. Based on this dynamic pricing information, a varying tariff model for the cloud services was developed in the project.

An effective billing mechanism was developed for the cloud services which is anal-ogous to the Smart Metering in power grids.

Future Work

A mechanism to handle time based billing can be incorporated to the current implementation of Smart Metering.

The order for ARIMA used in this project was defined by [18], however, in [19] Liu et. al. suggest optimal order for ARIMA by considering four different criteria. We can incorporate this improvement in the Smart Meter application.

(29)

5. CONCLUSION

In the current implementation, we use ARIMA as the only statistical prediction model. However, the robustness of the prediction can be improved by using a weighted average of various predictors like in the Potluck Problem [20].

The Smart Meter application in the current form depends on Hyperic system mon-itoring tool for load monmon-itoring and R package for load prediction. The application can be made stand alone, by incorporating a monitoring module and a prediction engine written specifically for the Smart Meter.

The current implementation of the Smart Meter is compatible with Eucalyptus cloud infrastructure. The system can be extended to work with other cloud service providers like Nimbus, Amazon etc.

(30)

References

[1] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, “A view of cloud computing,” Commun. ACM, vol. 53, pp. 50–58, April 2010.

[2] C.-P. Bezemer, A. Zaidman, B. Platzbeecker, T. Hurkmans, and A. ’t Hart, “Enabling multi-tenancy: An industrial experience report,” in Software

Main-tenance (ICSM), 2010 IEEE International Conference on, Sept 2010, pp. 1

–8.

[3] R. van Gerwen, S. Jaarsma, and R. Wilhite, “Smart metering,” July 2006. [Online]. Available: http://www.leonardo-energy.org/webfm send/435

[4] J. W. Ross, M. R. Vitale, and C. M. Beath, “The untapped potential of it chargeback,” MIS Quarterly, vol. 23, no. 2, pp. 215–237, June 1999.

[5] Understanding cloud pricing. [Online]. Avail-able: http://searchcloudcomputing.techtarget.com/tutorial/ Understanding-cloud-computing-pricing

[6] P.Vijayapriya, G. Bapna, and Dr.D.P.Kothari, “Smart tariff for smart meters in smart grid,” International Journal of Engineering and Technology, vol. 2, no. 5, 2010.

[7] H.-P. Siderius and A. Dijkstra, “Smart metering for households: Cost and benefits for the Netherlands,” EEDAL, 2006.

[8] Amazon spot instance. [Online]. Available: http://aws.amazon.com/ec2/ spot-instances/

[9] R. Iyer, R. Illikkal, L. Zhao, D. Newell, and J. Moses, “Virtual platform architectures for resource metering in datacenters,” SIGMETRICS Perform.

Eval. Rev., vol. 37, pp. 89–90, October 2009.

[10] Amazon pricing. [Online]. Available: http://aws.amazon.com/ec2/pricing/

[11] Rackspace pricing. [Online]. Available: http://www.rackspace.com/cloud/ cloud hosting products/servers/pricing/

(31)

REFERENCES

[12] Hyperic open source monitoring. [Online]. Available: http://www.hyperic. com/products/open-source-systems-monitoring

[13] Open eucalyptus. [Online]. Available: http://open.eucalyptus.com/

[14] Hyperic sigar api. [Online]. Available: http://www.hyperic.com/products/ sigar

[15] G. E. P. Box, G. M. Jenkins, and G. C. Reinsel, “Time series analysis: Fore-casting and control,” 2008.

[16] “Eucalyptus beginners guide,” 2010. [Online]. Available: http://open. eucalyptus.com/forum/eucalyptus-beginners-guide-uec-edition

[17] “Hyperic HQ and MySQL Backend Performance Study,” 2008. [Online]. Avail-able: http://download.hyperic.com/pdf/Hyperic-WP-MySQL-Benchmark. pdf

[18] P. A. Dinda and D. R. O’Hallaron, “An evaluation of linear models for host load prediction,” High-Performance Distributed Computing,

Interna-tional Symposium on, vol. 0, p. 10, 1999.

[19] J. Huo, L. Liu, L. Liu, Y. Yang, and L. Li, “Selection of the order of autore-gressive models for host load prediction in grid,” Software Engineering,

Ar-tificial Intelligence, Networking, and Parallel/Distributed Computing, ACIS International Conference on, vol. 2, pp. 516–521, 2007.

[20] P. K. Enumula and S. Rao, “The potluck problem,” Economics Letters, vol. 107, no. 1, pp. 10 – 12, 2010.

Smart Metering of Cloud Services