A Service-Oriented Architecture for Billing Resources in IaaS Cloud Platforms Nayane Ponte, Fernando Trinta, Ricardo Viana, Rossana Andrade, Vinícius Garcia, Rodrigo Assad {nayaneviana, fernandotrinta, ricardoviana, rossana}@great.ufc.br,
[email protected],
[email protected] ABSTRACT Cloud Computing is a recent paradigm where different IT resources, such as applications or hardware, are quickly provisioned to customers through a pay per use model. Many research studies have already been conducted concerning billing services for cloud computing, but they lack on flexibility to establish how resources are defined and monitored. In fact, current solutions seem also very dependent on specific cloud infrastructures. This paper proposes an architecture for billing cloud services decoupled from specific providers, named as aCCountS. This service is complemented by a Domain Specific Language that allows the specification of flexible pricing policies. Such policies aims at supporting cloud billing requirements collected from our literature survey, allowing pricing schemes that meet different customer profiles. Based on this architecture, a prototype has been implemented and tested to validate our proposal in two different cloud infrastructures. Experiments confirmed that (i) the architecture hasn’t dependencies of specific IaaS provider and (ii) the charging procedures are done correctly.
as hardware, development platforms, and/or services), that can be dynamically reconfigured to adjust to a variable load (scale), allowing also for an optimum resource utilization”. Despite any specific delivery model (Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS)), cloud resources are typically exploited by a pay-per-use model in which guarantees are offered by the infrastructure provider, using customized Service Level Agreements (SLAs) [1][2]. According to Lucredio and Silva[3], solutions for monitoring, billing and management tasks will be a key point for the success of any cloud infrastructure[2] in the near future. In order to address this topic, this paper presents a ServiceOriented Architecture, which follows a reference model [4], aiming at supporting billing procedures for infrastructure cloud platforms, called aCCountS (a Cloud aCcounting Service). In this service, a cloud administrator defines charging schemes (or pricing policies) for its IaaS resources in a fast and simplified way using a Domain Specific Language (DSL), called aCCountS-DSL.
Categories and Subject Descriptors
2.
D.2.2 [Software Engineering]: Design Tools and Techniques—Modules and interfaces
Silva et al [5] conducted a mapping study on cloud accounting. In their mapping, a taxonomy [4] for accounting process on the Internet is presented. This taxonomy introduced a common vocabulary regarding Internet accounting, which helps to develop accounting models. Fig. 1 presents this integrated vision of the proposed accounting process. Ruiz-Agundez et al also claim that most cloud billing solutions are very dependent to specific cloud platforms. This undesired scenario leads to maintenance and extensibility problems. The process proposed by the authors was implemented in a commercial solution called JBilling, which prevents access for further details about its validation. From the grid computing area, [6] and [7] propose new strategies for accounting and billing who take into account not only common factors such Virtual Machine’s uptime or their virtualized hardware, but also the total amount of consumed resources, such as the CPU/memory average usage. Our proposal uses these aforementioned studies as requirements to the Accounts design. The process proposed by [4] is adapted, since the roaming step is useless for our scenario. Our solution also is designed to be independent of any specific cloud provider.
General Terms Design
Keywords Cloud Computing, Pricing, Infrastructure as a Service
1.
INTRODUCTION
Cloud computing represents a new model for delivery and consumption of IT resources based on the Internet. According to Vaquero et al [1], this model refers to “a large pool of easily usable and accessible virtualized resources (such Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected]. SAC 2015 April 13 - 17, 2015, Salamanca, Spain Copyright 2015 ACM 978-1-4503-3196-8/15/04...$15.00. http://dx.doi.org/10.1145/2695664.2719244
3. 1719
RELATED WORK
ACCOUNTS - A CLOUD ACCOUNTING SERVICE
Figure 3: aCCountS Architecture The aCCountS-Service provides two interfaces for agents. iParameters (Fig. 3-b) allows that agents discover what resources should be gathered from each virtual machine, and iResources to collect monitored data read from the agents. Monitoring activities can be divided into four steps: (i) identify resources that should be monitored, (ii) perform metering, (iii) mediation tasks of these resources, and finally, (iv) send the information to the aCCountS-Service for further processing.
Figure 1: Accounting Resources Flow[4]
An overview of Accounts proposal is depicted in Fig. 2. Accounts structure is composed by two major elements: (i) a monitoring agent named Accounts-Agent, and (ii) a billing service designed as a SaaS, named Accounts-Service. The former gathers raw data from Virtual Machines and sends them to the billing service. The latter component receives and stores information from remote agents, in order to apply a further processing and compute resources’s costs based on specific pricing schemes. Accounts-DSL is used to write billing policies for VMs, according to their consumed resources.
3.2
Figure 2: aCCountS Overview There are two steps that must be followed in order to run aCCountS. The first step is the service configuration, that demands the cloud administrator to define which resources will be used to compose the charging schemes. In Fig. 2, these are the Monitored Resources’ Parameters. The cloud administrator uses these profiles to set prices for its resources. The second step is the service execution phase. When an aCCountS-agent starts up, it retrieves from the aCCountSService which resources should be monitored, and how they are acquired. aCCountS-agent as an uninterrupted process that collects data about the VM resources previously defined in configuration phase, and send them to a centralized repository.
3.1
Accounts Architecture
The aCCountS Architecture is depicted in Fig. 3 as an UML component diagram. In this figure, elements labeled with the Entity stereotype represent distinct kinds of data, where others components assume the role of managers of these resources. The communication between these two components uses messages based on JSON format to promote interoperability.
Accounts-DSL
A billing policy is a set of rules that defines how resources from virtual machines are specified. Accounts-DSL is a textual domain specific language for creating billing policies for the Accounts architecture. The DSL aims at allowing any cloud provider to define its own rules for billing schemes using simple strategies and concepts already used in cloud infrastructures. It was designed based on requirements from related work described in Section II, from both academia and industry, especially Amazon EC2. These requirements used by the Accounts are Payment Model, Accounting Procedure, Hardware profile, Utilities facilities, and Social Wellfare. A policy is defined by a set of elements as follows: policy identifies the name of a specific policy. It is divided in two sections: var, who is used to define auxiliary variables to store values that will be used in the policy rules, and rules, defines how the billing policy is computed. A policy is defined by means of assignment statements, arithmetic operations, conditional clauses, and inheritance mechanism. Its definition finishes with the reserved-word return, followed by a value representing the billing policy final cost. Listing 1 a policy named OnAveUsePosPlus to describe a policy scheme according Accounts-DSL structure. Listing 1: Post paid avg. use on demand policy created with aCCountS-DSL 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
1720
Policy OnAveUsePosPlus { var { dataCenterRate , memory , cpu , energyDiscount ; } rules { energyDiscount = 0; memory = instance . memory * $memory ; cpu = instance . cpu * $cpu ; if ( instance . economyEnergy >= 0.5 ) { energyDiscount = 0.03; } cost = memory + cpu + instance . software + instance . service ; discount = instance . sla + energyDiscount ; cost = cost - cost * discount ; } return cost ; }
4.
EXPERIMENTAL EVALUATION
value as its final result.
As aCCountS-Service and aCCountS-DSL were specified, a prototype was implemented to validate our architecture. The aCCountS prototype allowed us to perform some tests in our architecture. First, we deployed Accounts-Agents in two different cloud providers: Amazon EC2 and Microsoft Azzure. This first test aims at verifying if all components were functionally correct, and no communications problems were faced. The second test was designed to check if the pricing schemes was also computed correctly. Some sample data were sent to the Accounts-Service, and results were compared to the expected values of specific pricing schemes defined previously. Next two subsections present the results.
4.1
Table 2: Results obtained the three test cases Test Cases 1 Test Cases 2 Test Cases 3 Policy Exp. Retr. Exp. Retr. Exp. Retr. OnAvUsPoPls 0.3007 0.3007 0.3050 0.3050 0.3680 0.3680 RsAvUsPoPls 0.2894 0.2894 0.2871 0.2871 0.3616 0.3616 OnSmUsPoPls 0.2861 0.2861 0.2827 0.2827 0.3590 0.3590 OnAvTmPoPls 0.2522 0.2522 0.2522 0.2522 0.3300 0.3300 OnAvUsPrPls 0.3298 0.3298 0.3496 0.3496 0.3860 0.3860 OnAvUsPo 0.3100 0.3100 0.3280 0.3280 0.3680 0.3680 RsSmUsPoPls 0.2812 0.2812 0.2744 0.2744 0.3565 0.3565 RsAvTmPoPls 0.2031 0.2031 0.2031 0.2031 0.2794 0.2794 RsAvUsPrPls 0.3059 0.3059 0.3123 0.3123 0.3718 0.3718 RsAvUsPo 0.2984 0.2984 0.3086 0.3086 0.3616 0.3616
Evaluation of aCCountS Flow
Our experiment used three Amazon EC2 virtual machines, three Microsoft Azzure instances and last server running Accounts-Service. These used three pairs combination (policy/profile) to define its policy scheme and both clouds used same settings. The Policies used in each cloud were set as follows: smallUseOnPos policy (on demand allocation, postpaid model, in a small profile machine), smallTimeOnPos policy (on demand allocation, postpaid model in a small profile machine), smallUseRes1Pos policy (reserved to one year allocation, postpaid model in a small profile machine). These six virtual machines had been running for almost nine days and their metering records were sent each hour to an aCCountS-Service instance running on a specific machine. More than 900 metering records were collected from the agents. Table I shows six samples saved from our tests, and the value generated after applying their specific billing rules for these samples. Table 1: Results of experiments performed Amazon EC2 and Windows Azure Policy (Cloud) Reg. of Measurement smallUseOnPos “cpu”: 0.01545, “memory”: (Amazon) 0.80414, “storage”: 2.7e-05 smallUseRes1Pos “cpu”: 0.075, “memory”: (Amazon) 0.8302, “storage”: 4.1e-05 smallTimeOnPos “useTime”: 1.0 (Amazon) smallUseOnPos “cpu”: 0.06428, “mem(Azure) ory”: 0.79215, “storage”: 0.05129 smallUseRes1Pos “cpu”: 0.068518, “mem(Azure) ory”: 0.544349, “storage”: 0.0512838 smallTimeOnPos “useTime”: 1.0 (Azure)
4.2
5.
CONCLUSIONS AND FUTURE WORK
In this paper we presented the aCCountS architecture, a billing platform for infrastructure clouds. The components of aCCountS were presented, the aCCountS-Service and the aCCountS-DSL. The former is a software framework. The latter denotes a Domain Specific Language used by cloud administrators to define pricing rules for cloud resources. In order to validate our proposal, a prototype of the aCCountS architecture was implemented. Experiments conducted on this prototype allowed us to comprove that the architecture was able to charge IaaS resources correctly in two different clouds, Amazon EC2 and Microsoft Azzure. At the same time, different billing schemes were specified using aCCountS-DSL, and the language correctness was tested by using sample values to produce expected results. As future works, we intend to address also security, availability and scalability issues, in order to improve the quality of our solution. We can also think of the implementation or use of an independent agent virtual machine (such as Ganglia), which is robust, hypervisor based, and fault tolerant.
in the Charge $ 0.00492 $ 0.00448 $ 0.06000 $ 0.00545
6.
REFERENCES
[1] L. M. Vaquero et al., “A Break in the clouds: towards a Cloud definition,” Rev. Commun. SIGCOMM Comput., vol. 39, no. 1, pp. 50–55, December 2008. [2] M. Armbrust et al., “Above the clouds: A Berkeley view of Cloud Computing,” EECS Department, University of California, Berkeley, Tech. Rep., Fevereiro 2009. [3] D. Lucredio et al., “Software engineering for the cloud: A research roadmap,” in XXVI Brazilian Symposium on Soft. Eng. (SBES 2012), Natal-RN, Sept. 2012. [4] Ruiz-Agundez et al., “A Flexible Accounting Model for Cloud Computing,” in Annual SRII Global Conference (SRII 2011), San Jose, USA, March 2011, pp. 277–284. [5] F. A. P. d. Silva et al., “Accounting Models in Cloud and Grid computing: A Systematic Mapping Study,” ser. GCA 12, Las Vegas, USA, July 2012. [6] A. Caracas et al., “A pricing information service for grid computing,” ser. MGC ’07. New York, NY, USA: ACM, November 2007. [7] A. Narayan et al., “Smart metering of cloud services,” in IEEE International Systems Conference (SysCon 2012), Ottawa, Ontario, Canada, March 2012, pp. 1–7.
$ 0.00366 $ 0.06000
Evaluation of aCCountS-DSL
The second experiment focused on the DSL where ten pricing schemes were created by combining different requirements promoted by Accounts-DSL. Each pricing scheme was tested using three sets of fixed values, and these sets were associated with three test cases. Thus, the final value computed for every pricing scheme was known beforehand. Table 2 presents results of applying the test cases in each pre-defined pricing scheme with Accounts-DSL. We found that in all test cases, the service generated the expected
1721
