Agents for Cloud Resource Allocation: an Amazon EC2 Case Study

Transcription

1 Agents for Cloud Resource Allocation: an Amazon EC2 Case Study J. Octavio Gutierrez-Garcia and Kwang Mong Sim, Gwangju Institute of Science and Technology, Gwangju , Republic of Korea and Abstract. Infrastructure-as-a-service consumers are presented with numerous Cloud providers with a wide variety of resources. However, consumers are faced with providers that may offer (even similar) resources at different hourly cost rates, and also that no single provider may have matching resource capabilities to fulfill a highly heterogeneous set of requirements. This work proposes an agent-based approach endowed with the well-known contract net protocol for allocating heterogeneous resources from multiple Cloud providers while selecting the most economical resources. The contributions of this paper are: (i) devising an agent-based architecture for resource allocation in multi- Cloud environments, and (ii) implementing the agent-based Cloud resource allocation mechanism in commercial Clouds using Amazon EC2 as a case study. The Amazon EC2 case study shows that agents can autonomously select and allocate heterogeneous resources from multiple Cloud providers while dynamically sampling resources allocation cost for selecting the most economical resources. Keywords: agent-based Cloud computing; Cloud computing; multi-agent systems; resource allocation. 1 Introduction Infrastructure-as-a-service consumers are offered a wide diversity of Cloud resources from multiple, distributed Cloud providers (e.g., Amazon EC2 [3], GoGrid [9], and RackSpace [11]) supplied at different hourly cost rates. Moreover, similar Cloud resources may be priced differently by each Cloud provider. Furthermore, Cloud consumers may request heterogeneous sets of Cloud resources that may not be available in a single Cloud provider. Thus, autonomously carrying out resource allocation from multiple and self-interested Cloud providers while sampling hourly cost rates associated to Cloud resources is necessary to provide efficient (i.e., with low allocation costs) resource allocation services to consumers in a dynamic manner. This stresses the need for the agent paradigm. Agents are autonomous problem solvers that can act and collaborate flexibly and self-interestedly among each other. In this paper, agents represent Cloud participants (consumers, providers, and brokers), which use the contract net protocol (CNP) [13] to establish service contracts

2 with Cloud providers while sampling hourly cost rates. The CNP is used as the foundation for an agent-based Cloud resource allocation mechanism to autonomously allocate Cloud resources in multi-cloud environments. Finally, an agent-based system prototype was devised and implemented in which a case study using Amazon EC2 as Cloud provider was carried out. The significance and novelty of this paper is that, to the best of the authors knowledge, it is the earliest work in applying, developing, and deploying an agentbased approach to allocate Cloud resources from multiple and commercial Cloud providers (e.g., Amazon EC2) in an autonomous manner. The contributions of this work are as follows. (i) Devising an agent-based Cloud architecture for resource allocation in multi-cloud environments (Section 2), and (ii) implementing and deploying the agent-based resource allocation mechanism in commercial Clouds using Amazon EC2 as a case study (Section 3). In addition, Section 4 includes a related work comparison, and Section 5 presents conclusion and future work. 2 An Agent-Based Cloud Resource Allocation Architecture The components of the agent-based architecture that supports resource allocation in multi-cloud environments (Fig. 1) are as follows: Fig. 1. Agent-based Cloud resource allocation architecture.

3 1) A Cloud resource ontology (Fig. 2) is a formal specification of Cloud resources. Cloud resources are defined by their functional and non-functional capabilities as well as their location (URI address). Non-functional capabilities are (i) storage capacity, (ii) memory, (iii) architecture type, and (iv) processing capacity. Functional capabilities are (i) pre-installed operative system, and () pre-installed applications, e.g., database servers. Fig. 2. Cloud resource ontology. 2) A Cloud directory is a listing of Cloud participants either brokers or service providers and their capabilities. The capability of brokers is stated as providing resource allocation services to Cloud consumers. The capabilities of service providers are defined by the Cloud resource types they offer. The Cloud directory is handled by a system agent (see Section 3 for details) to which (i) service provider agents and broker agents register their services, and (ii) consumer agents and broker agents contact to request for broker and service provider agents addresses, respectively. 3) Consumer agents (CAs) act on behalf of Cloud consumers and are in charge of submitting resource allocation requests composed of a set of Cloud requirements. To do this, CAs adopt the initiator (manager) role of the CNP consisting of (i) sending a call-for-proposals (resource allocation request) to q broker agents (contractors). Then, from the p (p q) broker agents proposals, CAs select the best (e.g., cheapest) proposal and send an accept message to the broker agent with the winning bid, and reject messages to the remaining broker agents. 4) Broker agents (BAs) provide Cloud resource allocation services to CAs. To do this, BAs adopt the participant (contractor) role of the CNP consisting of (i) receiving resource allocation requests (call-for-proposals) from CAs, and (ii) replying with proposals based on the current hourly cost rates associated to the Cloud resources. If a BA is selected, the BA allocates the Cloud resources from service providers listed in the Cloud directory with matching resource capabilities. To do this, BAs adopt the initiator role of the CNP with service provider agents as participants. BAs call-forproposals are composed of single Cloud requirements. In doing so, CAs allocation requests consisting of multiple Cloud requirements are handled by BAs as independent and parallel resource allocations from the best (cheapest) service providers for each Cloud requirement. 5) Service provider agents (SPAs) offer and supply Cloud resources to BAs by adopting the participant role of the CNP with BAs as initiators. SPAs proposals consist of allocation costs based on the Cloud resource types. In addition, SPAs handle Cloud resource provisioning by requesting (de)allocations of Cloud resources to resource agents.

4 6) Resource agents (RAs) (de)allocate and monitor Cloud resources by using specific vendor APIs (usually web services), e.g., Amazon AWS APIs [1]. RAs are described by the Cloud resource type they can allocate. RAs functions are: (i) receiving allocation requests from SPAs, (ii) creating private/public keys to access Cloud resources, (iii) extracting and decrypting passwords to access Cloud resources, (iv) extracting public IP addresses from recently allocated Cloud resources, and (v) forwarding Cloud resources access information to SPAs. Fig. 3. Cloud resource allocation interaction protocol. An agent-based Cloud resource allocation scenario (Fig. 3) is as follows. A CA retrieves BAs addresses from the Cloud directory, and then the CA sends a call-forproposals (consisting of a set of p Cloud consumer requirements) to a set of BAs. The BAs reply with proposals containing the overall allocation cost. Afterwards, the CA sends an accept-proposal message to the selected BA and reject-proposal messages to the remaining BAs. Subsequently, the selected BA adopts p CNP executions with SPAs (listed in the Cloud directory) as participants in a parallel manner, i.e., the selected BA adopts a CNP execution for each Cloud resource requested by the CA. The SPAs (selected by the BA) send allocation requests to appropriate RAs (i.e., RAs matching the Cloud consumer requirements). Finally, the RAs extract the public IP

5 addresses and passwords from the recently allocated Cloud resources, and forward the results to their SPAs that forward the information to the BA, which hand over the information to the CA. 3 Agent-Based Cloud Resource Allocation in Amazon EC2 A case study using Amazon EC2 was carried out for which an agent-based system prototype was implemented using (i) the java agent development framework (JADE) [6], (ii) Bouncy Castle Crypto APIs [7] (for encrypting and decrypting Cloud resources passwords), and (iii) Amazon SDK for Java [5]. 3.1 Amazon EC2 Cloud Ontology The Cloud resource ontology (Fig. 2) was provided with Cloud resource definitions based on (i) Amazon instance types and (ii) Amazon machine images (AMIs), for a total of 58 different Cloud resource definitions that resulted from the valid combinations (i.e., not all the AMIs can be run on a given instance type) between instance types and AMIs (Table 1). Table 1. Amazon instance types and Amazon machine images. Amazon instance types (i) t1.micro, (ii) m1.small, (iii) m1.large, (iv) m1.xlarge, (v) m2.xlarge, (vi) m2.2xlarge, (vii) m2.4xlarge, (viii) c1.medium, (ix) c1.xlarge, (x) cc1.4xlarge, and (xi) cg1.4xlarge. Amazon machine images (i) Basic 32-bit Amazon Linux, (ii) Basic 64-bit Amazon Linux, (iii) Red Hat Enterprise Linux bit, (iv) Red Hat Enterprise Linux bit, (v) SUSE Linux Enterprise Server bit, (vi) SUSE Linux Enterprise Server bit, (vii) Microsoft Windows Server 2008 Base, (viii) Microsoft Windows Server 2008 R2 Base, (ix) Microsoft Windows Server 2008 R2 with SQL Server Express and IIS, (x) Microsoft Windows Server 2008 R2 with SQL Server Standard, (xi) Cluster Instances Amazon Linux, and (xii) Cluster Instances HVM SUSE Linux Enterprise Cloud Participants and Distributed Cloud Environment The agents involved in the case study were 1 RA, 5 BAs, 5 SPAs, and 2500 RAs. Each agent, either CAs, BAs, or SPAs was deployed on a different JADE agent container (see Fig. 1 and Fig. 4), i.e., an instance of a JADE runtime environment. In addition, since RAs do not interact among themselves, all the RAs were deployed on a single container (Container-1 in Fig. 4). In doing so, SPAs had to contact RAs located at a remote location, and an unnecessary large number of containers was avoided in the system prototype. The Cloud resource type of the RAs was randomly selected from the available 58 Cloud resource types (Table 1). Moreover, all the RAs

6 were randomly assigned to the SPAs to simulate a scenario with highly heterogeneous Cloud providers. Fig. 4. JADE sniffer agent showing an agent-based Cloud resource allocation scenario. All the agent containers must be and were registered in a main JADE container that manages and supports the agent-based platform by (i) handling asynchronous message passing communication through Java RMI and IIOP, (ii) starting and killing agents, and (iii) providing services such as: a directory facilitator agent (Cloud directory), a sniffer agent, a remote management agent, etc., see [6] for details of JADE.

7 Fig. 5. AWS management console Key pairs option. Fig. 6. AWS management console My instances option. As shown in Fig. 4, agent-based platform CloudMAS had: (i) 1 Main-Container including a remote monitoring agent (RMA@CloudMAS), an agent management system (ams@cloudmas), a directory facilitator (df@cloudmas), i.e., a Cloud directory, and a sniffer agent (for illustrative purposes); and (ii) 12 basic containers (from Container-1 to Container-12). Container-1 included all the RAs. The SPAs and BAs were included in agent containers ranging from Container-2 to Container-11, one agent for each container. Finally, the CA was included in Container-12. Since all the agent containers were deployed on the same host, each container was provided with a different network port to simulate a fully distributed environment. 3.3 Cloud Resource Allocation Scenario The CA was provided with a Cloud resource allocation request composed of 6 Cloud resources: 4 m1.small instances with an AMI ami-8c1fece5 (Basic 32-bit Amazon Linux AMI Beta) and 2 m1.large instances with an AMI ami-8e1fece7 (Basic 64-bit Amazon Linux AMI Beta).

8 Fig. 7. Console output for agent-based resource allocations using Amazon SDK. The CA submitted the allocation request to the 5 BAs by using the CNP. The selected BA executed 6 CNP (one for each Cloud resource to be allocated) with the 5 SPAs in a parallel manner. Finally, the selected SPAs requested the Cloud resource allocations to their RAs. Fig. 4 shows an extract of the messages exchanged among all the agents to carry out the Cloud resource allocation request, which was fulfilled by agent BA4 (a BA selected by consumer CA1). The messages received by agent BA4 (Fig. 4) came from the SPAs bidding for allocating a Cloud resource and/or providing data to access the recently allocated Cloud resources, e.g., the messages exchanged between agents SPA1 and BA4, see Fig. 4. In addition, as soon as allocation data (public IP address and password to access a given Cloud resource) was received, broker BA4 forwarded the data to consumer CA1, as shown in the bottom of Fig. 4. The interleaving of messages received by agent BA4 from all the SPAs (see Fig. 4) is the result of the parallel execution of CNPs for allocating Cloud resources. 3.4 Technical Aspects to Handle Cloud Resource Allocation in Amazon EC2 The RAs were provided with (i) Amazon EC2 API tools to handle Cloud resource allocations, and (ii) Amazon AWS security credentials to access Amazon EC2. It should be noted that although the RAs shared the same security credentials (i.e., all the RAs accessed Amazon EC2 using the same Amazon AWS account), sharing the credentials had no advantageous effects on the agent-based Cloud resource allocation approach.

9 When the RAs received the SPAs requests to allocate Cloud resources, the RAs created new RSA key pairs to access Amazon EC2 (Fig. 5). The key pairs were automatically named based on the identifiers of the RAs that allocated the Cloud resources, e.g., newkeyra2462 (see the left side of Fig. 5). Right afterwards, the RAs proceeded to allocate the Cloud resources (Fig. 6) corresponding to the CA s initial allocation request (consisting of 6 Cloud resources, see Section 3.3). The console output of the agent-based system (Fig. 7) corresponding to the CA s allocation request shows: (i) JADE initialization messages displaying agent containers addresses and names, (ii) self-generated output messages derived from the creation of key pairs by using Amazon SDK, and (iii) self-generated output messages derived from the Amazon instance allocations by using Amazon SDK. In general, the self-generated output messages contained the following information: timestamp, key pair name, AWS access key, type of instance allocated, etc., see Fig. 7 for details. Since Amazon instances take some time to be fully functional (i.e., to start) and the delay time may vary due to the size of AMIs, number of instances to be allocated, among other factors [2], the RAs were continuously checking (every 200 s) whether Amazon instances were up and running by retrieving the console output of the recently allocated instances as indication of the start of the instances. Once the RAs detected an output in the instances console, the RAs proceeded to extract the public IP addresses and passwords (only possible when the instances are up and running), which were forwarded to their corresponding SPAs. 4 Related Work Resource allocation mechanisms have been widely investigated (see [12]). However, little attention has been directed to (i) Cloud resource allocation in multi-cloud environments, and (ii) to actual implementations of autonomous Cloud resource allocation mechanisms. Whereas current Cloud management systems (see [8], [10], and [14]) may allocate Cloud resources from different Clouds to execute consumers applications, no explicit consideration of autonomous Cloud resource selection based on fees associated to Cloud resources has been made. In contrast, this present work uses both the agent paradigm and the CNP to (i) sample Cloud resources hourly cost rates, and (ii) allocate Cloud resources in multi-cloud environments in an autonomous and dynamic manner. In addition, the proposed agent-based Cloud resource allocation mechanism is fully distributed, in contrast to centralized allocation mechanisms (see [4]) that require a central control entity (allocator) that commonly becomes a system bottleneck. 5 Conclusion and Future Work The contributions of this paper are as follows. (i) Devising the earliest (to the best of the authors knowledge) agent-based Cloud architecture for resource allocation in multi-cloud environments, and (ii) implementing and deploying the agent-based

10 resource allocation mechanism in commercial Clouds using Amazon EC2 as a case study. In this work, autonomous agents equipped with the CNP to (i) dynamically sample hourly cost rates and (ii) support cost-based Cloud resource allocation among selfinterested Cloud participants were used to deal with Cloud resource allocation in multi-cloud environments. By using the agent paradigm, Cloud consumers can efficiently (i.e., with the lowest allocation costs) allocate heterogeneous sets of Cloud resources from multiple, distributed Cloud providers in a dynamic and autonomous manner as shown in the Amazon EC2 case study. Since this work provides the foundations for a general-purpose agent-based multi- Cloud platform by providing an infrastructure-as-a-service solution (allocated from multiple Cloud providers) to Cloud consumers, future research directions include: (i) adding agent capabilities to schedule and execute both workflows and bag-of-tasks applications in multi-cloud environments, and (ii) implementing access to more commercial Cloud providers, such as: GoGrid [9] and RackSpace [11]. Acknowledgments. This work was supported by the Korea Research Foundation Grant funded by the Korean Government (MEST) (KRF D00092) and the DASAN International Faculty Fund (project code: ). References 1. Amazon EC2 API Tools, 2. Amazon EC2 FAQs, 3. Amazon Elastic Compute Cloud (Amazon EC2), 4. Asmild, M., Paradi, J.C., Pastor, J.T.: Centralized Resource Allocation BCC Models, Omega 37(1), (2009) 5. AWS SDK for Java A Java Library for Amazon S3, Amazon EC2, and More, 6. Bellifemine, F., Poggi, A., Rimassa, G.: JADE - A FIPA-Compliant Agent Framework. In: 4th International Conference and Exhibition on the Practical Application of Intelligent Agents and Multi-Agents, pp (1999) 7. Bouncy Castle Crypto APIs, 8. Buyya, R., Pandey, S., Vecchiola, C.: Cloudbus Toolkit for Market-Oriented Cloud Computing. In: Jaatun, M.G., Zhao, G., Rong C. (eds.) CloudCom 2009, LNCS, vol. 5931, pp Springer-Verlag, Berlin, Heidelberg (2009) 9. GoGrid, Lee, K., Paton, N.W., Sakellariou, R., Deelman, E., Fernandes, A.A.A., Metha, G.: Adaptive Workflow Processing and Execution in Pegasus. Concurr. Comput.: Pract. Exper. 21(16), (2009) 11. RackSpace, Sim, K.M.: A Survey of Bargaining Models for Grid Resource Allocation. SIGecom Exch. 5(5), (2006) 13. Smith, R.G.: The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver. IEEE Trans. Comput. 29(12), (1980) 14. Yang, Y., Liu, K., Chen, J., Lignier, J., Jin, H.: Peer-to-peer Based Grid Workflow Runtime Environment of SwinDeW-G. In: 3rd IEEE International Conference on e-science and Grid Computing, pp IEEE Computer Society, Washington (2007)