TeachCloud: A Cloud Computing Educational Toolkit

Transcription

1 TeachCloud: A Cloud Computing Educational Toolkit Y. Jararweh* and Z. Alshara Department of Computer Science, Jordan University of Science and Technology, Jordan yijararweh@just.edu.jo * Corresponding author zakarea.alshara@gmail.com M. Jarrah and M. Kharbutli Department of Computer Engineering, Jordan University of Science and Technology, Jordan mjarrah@just.edu.jo kharbutli@just.edu.jo M. N. Alsaleh Department of Software and Information Systems University of North Carolina at Charlotte Charlotte, NC, USA malsaleh@uncc.edu Abstract: Cloud computing is an evolving and fast-spreading computing paradigm that has gained great interest from both industry and academia. Consequently, universities are actively integrating Cloud computing into their IT curricula. One major challenge facing Cloud computing instructors is the lack of a teaching tool to experiment with. We introduce TeachCloud, a modeling and simulation environment for cloud computing. Students can use TeachCloud to experiment with different cloud components such as: processing elements, data centers, networking, Service Level Agreement (SLA) constraints, web-based applications, Service Oriented Architecture (SOA), virtualization, management and automation, and Business Process Management (BPM). TeachCloud is an extension of CloudSim, a research-oriented simulator used for the development and validation in cloud computing. Keywords: Teaching Cloud computing; CloudSim; Network topologies; SLA management; Rain Workload generator; BPM. Reference to this paper should be made as follows: Jararweh, Y., Alshara, Z., Jarrah, M., Kharbutli, M. and Alsaleh, M. N. (2012) TeachCloud: A Cloud Computing Educational Toolkit, The 1st International IBM Cloud Academy Conference, April, North Carolina, USA, 2012 Copyright c 2012

2 2 1 Introduction Cloud computing is a new computing paradigm that is continuously evolving and spreading. Many experts believe it will become the dominant IT service delivery model by the end of the decade. As a result, universities worldwide are introducing cloud computing technologies in their curricula by updating existing courses or developing new ones. Cloud computing builds on a wide range of different computing technologies such as high-performance computing, distributed systems, virtualization, storage, networking, security, management and automation, Service-Oriented Architecture (SOA), Business Process Management (BPM), Service-Level Agreement (SLA) and Quality of Service (QoS)..etc. This complexity presents a major obstacle for the students to grasp and thoroughly understand cloud computing. The diversity of cloud computing related areas requires the students to put great efforts to understand each one of these areas alone in addition to integrating them in a single platform. This creates many challenges in teaching this rising technology for two main reasons: First, in order for a student to be able to grasp all aspects of cloud computing, the student must have adequate and sufficient background in the many areas listed above. Unfortunately, this is not always the case. For example, we found that while Computer Engineering students had sufficient background in the areas of high-performance computing, distributed systems, virtualization, storage, and networking, Computer Science students were lagging in these areas. On the other hand, Computer Science students had sufficient background in SOA, BPM, and management, areas Computer Engineering students were lagging in. Second, and more importantly, the fact that there are no teaching tools to cover the different aspects of cloud computing as a whole makes teaching more theoretical-oriented, and therefore, less effective. Although there exists teaching tools for most of the cloud components alone, no full-system tool exists yet. Table 1 Challenges in Teaching Cloud Computing as Identified by Students Challenge or Difficulty Lack of hands-on experience 93% Lack of a comprehensive textbook 63% Lack of help material on the Internet 57% Insufficient background 17% Vast amounts of different topics 17% Percentage Agreed At Jordan University of Science and Technology, we were one of the first universities in the Middle East to introduce cloud computing concepts in our courses for both graduate and undergraduate students. Our first attempt to teach a cloud computing course was last spring (spring semester 2011) as an elective course for senior students. During the course, we identified several key challenges in teaching cloud computing that we list in Table 1. At the end of the course, we

3 conducted a students survey and asked the students to identify which challenges they thought were most important. The vast majority of the students (93%) agreed that the biggest challenge was lack of hands-on experience. Although a real cloud system can be used by the students to run experiments, the criticality and frangibility of the system poses many limitations and risks. A better solution is the use of a full cloud-system simulator tool with which students can play around and experiment risk-free. Other, but less important challenges, include lack of a single comprehensive textbook that covers all aspects of cloud computing, lack of help material on the Internet, insufficient students background, and the sheer amount of topics covered during a single semester. Consequently, we moved forward to find an experimental environment to be used in teaching cloud computing. One available option was the CloudSim simulator from the University of Melbourne, Australia (Calheiros et al. (2011)). CloudSim is a very promising tool for teaching cloud computing. However, CloudSim shows several limitations and shortcomings: First, it lacks a Graphical User Interface (GUI) which is important to students as it makes it easier for them to use the tool. Second, it is built on top of a grid computing environment which puts limitations on the infrastructures it can simulate. Third, it only includes a basic and simplified network model and a limited workload generator. Fourth, it lacks BPM and SLA components. As a result of these limitations in CloudSim, we started to develop TeachCloud as a cloud computing educational toolkit for use in cloud computing courses. TeachCloud uses CloudSim as the basic design platform and introduces many new enhancements on top of it. These enhancements and extensions include: Developing a GUI for the toolkit. Adding the Rain cloud workload generator to the CloudSim simulator. Adding new modules related to SLA and BPM. Adding new cloud network models (VL2, BCube, Portland, and DCell) to represent the actual topologies that exist in real cloud environments. Introducing a monitoring outlet for most of the cloud system components. Adding an action module that enables students to reconfigure the cloud system and study the impact of such changes on the total system performance. One use case scenario for TeachCloud could be as follows: First, the student can build a cloud system by building a data center with a given number of servers and VMs in addition to a specific network topology. Next, the student can set an SLA and BPM plan for his cloud system. After that, the student will apply a workload with certain intensity and collect information for the system resources utilization. Then, the students can start changing the workload intensity up and down and study how this will impact the system s resources. Moreover, the student can scale cloud system resources up and down and study the impact on the SLA violation and system s resources utilization. TeachCloud is still in its early stages and requires a sheer amount of work in addition to active participation from different partners from both the industry and academia. TeachCloud will be open source software available to all researchers and students working in Cloud Computing related projects and courses. Also, we are planning to create an international development community for TeachCloud to leverage the capabilities, features, performance and credibility of it. 3

4 4 The rest of the paper is organized as follows: Section 2 introduces the CloudSim simulator and the TeachCloud toolkit interface. Section 3 discusses the Cloud workload generator and the Rain generator that TeachCloud supports. We discuss the SLA constraints and BPM in Section 4. Then in Section 5, we describe the network topologies that were integrated in the TeachCloud toolkit. And finally, Section 6 provides a conclusion and future work. 2 CloudSim as an experimental tool CloudSim is a Cloud computing modeling and simulation tool that was developed in the University of Melbourne, Australia. It aims to provide Cloud computing researchers with a comprehensive experimental tool to conduct new research approaches. It supports the modeling and simulation of large scale Cloud computing environments, including power management, performance, data centers, computing nodes, resource provisioning, and virtual machine provisioning (Kim et al. (2009)). CloudSim is a layered design framework written in Java and initially was built on top of SimJava and GridSim (Buyya et al. (2009)). SimJava is a discrete event simulator and has been widely used. GridSim is a grid computing simulator that uses SimJava library. However, SimJava has several scalability limitations that led the developers of CloudSim to implement a new discrete event management framework which is the CloudSim core simulation engine ((Calheiros et al. (2011)). The following is a brief description on different Cloud computing features and components and how CloudSim models them: Data centers: represent the core infrastructures in a Cloud which are the hardware and software. In defining the data centers, the modeler needs to identify the number of hosts in each data center. Cloud federation: models multiple geographically distributed clouds (Private and/or Public) that are inter connected through network topology. Cloud tasks: represented by Cloudlets which is the Cloud-based application services. In this class, a computational metrics are used to model the complexity of applications. Brokering: through the use of DatacenterBroker class, the researcher establishes the contract between the Cloud users and the service providers. Storage in the grid: through the use of SANStorage, the researcher models the storage services in the Cloud. Virtual machine (VM): where the class VirtualMachine models an instance of a VM. Coordination: a CloudCoordinator class is used to model the communication between different Cloud coordinators and Cloud brokers. Also it monitors the internal state of each data center that is connected to the CloudCoordinator. Bandwidth provisioning: bandwidth provisioning services are modeled using the BWProvisioner class.

5 Memory provisioning: the policies of allocating memory to VMs are modeled using the MemoryProvisioner class. Virtual machine provisioning: virtual machines are allocated to the hosts using the VMProvisioner class. VM allocation policies: The class VMMAllocationPolicy models the policies for in allocating processing power to VMs which can be space-shared or timeshared. Power consumption: PowerModel class is used for the purpose of modeling data centers power consumption. Hosts: The class Host models a physical resource such as a computer or a server. A data center can have multiple hosts. To the best of our knowledge, CloudSim was never used as a teaching tool. This is mainly related to the difficulties in using it by students. Nevertheless, the capabilities of CloudSim are very promising for Cloud computing teaching. In this work, an extension is provided in order to make it convenient for teaching. Hence, a Graphical User Interface a long with new features were added. The GUI allows students to easily create the main components in a Cloud. For example, as shown in figure 1, a student can create data centers and define their parameters such as the number of hosts on each data center. Figures 2, 3, and 4 show the creation of Cloudlets, virtual machines and brokers respectively. The new features that were added as part of the TeachCloud are described in section 3, 4 and 5. 5 Figure 1 Creating data centers in TeachCloud After students setup the different components in the Cloud environment that they would like to experiment with and simulate, TeachCloud toolkit produces the simulation results for analysis as shown in figure 5.

6 6 Figure 2 Creating Cloudlets in TeachCloud Figure 3 Creating virtual machines in TeachCloud Figure 4 Creating Cloud brokers in TeachCloud 3 Workload generation and the Rain workload generator Cloud Computing systems promise to handle and fulfill different customers workload requirements. Due to the diversity of CC applications and services, ranging from data intensive (i.e. big-data) applications, financial applications, web service and Web 2.0 applications. The Cloud computing workloads are very dynamic and show different patterns during applications life span. Cloud computing workloads differ in their size, time, space and QoS requirements. Hence, Cloud computing systems are required to adjust their operational environment on the fly to cope with the workload dynamism. Workloads characterization is very crucial to the components of CC system in order to achieve proper resources provisioning, cost estimation, and SLA considerations. On the other hand, CC application developers and hosting companies need to predict changes in the workload patterns to be able to adjust promptly when variations in the patterns occur. Also, a detection of any possible system bottlenecks is needed before actually porting the application to the real system. Cloud applications updates after deployment may also cause a real problem in the actual Cloud system. These updates may change the workload patterns, intensity, operations mix, spikes

7 7 Figure 5 Sample of the simulation results in TeachCloud frequency and durations. These changes will affect the Cloud system resources allocation and QoS measurements. As a result, having a mechanism to test our Cloud application before the actual deployment or updates is very beneficial. Based on the aforementioned facts, an accurate and comprehensive workload modeling for CC environment is considered as an essential step in any CC simulation tool. Current workload modeling of systems like grid computing does not fit or match the workload founds in real CC systems. CloudSim provides a basic Cloud workload modeling structure that fails to capture many of the characteristics of CC workloads. Hence, CloudSim users need to extend available modules to generate the required patterns. CloudSim model the workload as an extension to the Cloudlet entity. By introducing the Utilization Model which is an abstract class that needs to be extended by users to implement the workload patterns related to the application (Calheiros et al. (2011)). The Utilization Model has methods and variables in order to specify resources requirements of applications during the deployment phase. The CloudSim requires the method getutilization() to be overwritten by CloudSim users. The input to getutilization() method is a discrete time parameter, while the output is a percentage of computational resources thats is required by the Cloudlet (Calheiros et al. (2011)). CloudSim workload modeling required CloudSim user generate the required workload patterns by overwriting the getutilization() methods. The main drawback of this approach is related to the lack of guarantee that the user will accurately represents the application workload patterns, and so, any related measurements based on this workload will be misleading to the user. Also this approach will incur an extra overhead on the user (i.e. the students in our case) and it suffers from the lack of flexibility and scalability. TeachCloud presents advanced workload capabilities by introducing the Rain workload generator framework from the University of California at Berkeley (Beitch et al. (2010)).

8 8 Rain framework presents accurate and comprehensive CC workload characteristics. Rain is an open source workload generator that is available to the Cloud computing community. This motivates us to utilize the advanced capabilities of Rain to achieve a meaningful load generator that is able to handle different CC applications. TeachCloud replaces the basic workload generator framework available in CloudSim by integrating Rain workload generator as shown in figure 6. The integration process is simple as both CloudSim and Rain were written in Java. The Three main workload characteristics that Rain provides are: 1) Variations in workload intensity (e.g. small, medium, and large amounts). 2) The variations in the operations mix performed by the system components (e.g. data intensive vs. computing intensive and tasks dependencies). 3) Variations in the data access patterns and frequency, also known as data hot spots. Predicting data hot spot enables efficient access to them that reduce access time and overhead. It is obvious that the aforementioned workload variations are closely related to each other and need a careful handling by any successful workload generator. Figure 6 Rain Generator in TeachCloud Tool 3.1 Rain workload generator architecture Rain is a unique statistics-based workload generator that overcomes many of the available workload generators limitations. It provides the user with ability to easily reuse, configure, and schedule a Cloud application workloads. The Cloud application variations in Rain are achieved efficiently by using empirical probability distributions. Rain architecture handles the variations in the load intensity and the mix of operations by using load scheduling mechanism. On the other hand, changes in the mix of operations and the realization of access pattern and data hot spots are done using application-specific request generators (Beitch et al. (2010)). Also, Rain architecture diverges from current workload generators in the way of handling workload requests. While current generator couple request generation with its execution, Rain decouple request generation from request execution which add flexibility to requests management. Another

9 limitation of current generators is related to the fact that the thread that generates the request, it s also responsible about its execution; this is known as threadaffinity problem. Thread-affinity problem impact the performance of the generator as one thread cannot generate new request until it complete the current one. Rain solved this problem by changing the logic of thread and request relation. Any request generated by a certain thread, can be executed by any other thread. This solution provides flexibility, scalability and improves the generator performance. Rain architecture consists of the following components (Beitch et al. (2010)): 1)The Scenario component: It is responsible for the experiments configuration parameters (e.g. maximum number of users, experiment duration, etc.). 2)The Generator components: It uses the configuration from the Scenario component to create requests and operations that will be used by other component. 3)The Scoreboard component: used to presents experiments results and summery. 4)The Threading component: contains the available threads for executing the tasks produced by request generator component. 5)The Benchmark component: it s responsible about running the entire experiments and its interact with other components: by loading the Scenario, that need to be handled by the threading components, initializes the Scoreboard, and present the results at the end of the experiment. 3.2 Rain workload generation Scenario component A new workload will be initialized by using the Scenario, each entity i.e. user will be assigned to a certain generator and assigned to a thread. The thread will request a new operation from the generator. When the thread finishes executing the operations assigned by the generator, it will generate a summary (e.g. status, execution results, etc) and write its details on the scoreboard. All this steps will be controlled by the benchmark component. TeachCloud users will use the workload generator in many ways. First, students can experiment with different workload patterns and mix of operations while using a fixed system configuration (e.g. VMs, network, etc.). This will help in understanding of how workload impact CC system components utilization and its impact on the SLA. Second, students can conduct experiments with different resources provisioning algorithm and assess how these algorithm react with workload variation. Third, students will be able to study the impacts of different workload patterns in the CC system components (VMs, network topology, etc.). Forth, students can apply an intensive workload scenario to detect any bottlenecks in the system. 9 4 Service Level Agreements and Business Process Management Injecting the business flavor in Cloud Computing course is a very hard and complex task. This is mainly due to the fact that most of the computer science and information technology students had no previous experience with business concepts and principles. Service Level Agreements and Business Process Management considered among the basic pillars of CC today (Faniyi and Bahsoon (2011)). Based on our experience, the students showed a lot of concerns about the SLA and BPM issue and how they are related to CC. In TeachCloud we made efforts

10 10 to introduce SLA to the students in simple and sufficient way. Starting from the basic definition of SLA as a contract between service provider and service user, which define in measurable terms the service quality that the user will expect to get. TeachCloud provide a set of these measurable terms that the user can change and study the impact on other system components. These measurable terms include but not limited to: number of users who can use the system simultaneously (e.g active user), time duration of service availability (e.g. 99.9%), service cost, possibility of service outage and how to handle them(if any), business continuity in case of a disaster, network performance, security measurements, service metering tools available for the user, user compensation in case of SLA violation(inconsistency between SLA terms and the actual service quality delivered to the user), and customer support by the service provider. To make thing more realistic we connect the SLA terms with the application sensitivity to the availability of the service, as some of the application cannot handle availability less than (%100). TeachCloud will enable the students to study the effect of the SLA terms on the Cloud system, service cost with different SLA configurations and different QoS requirements. Further, TeachCloud will integrate the Web Service Level Agreement (WSLA) framework that proposed to handle SLA monitoring and enforcement (Patel et al. (2009)). Figure 7 shows the SLA in TeachCloud. Figure 7 SLA parameters in TeachCloud On the other hand, and as a part of next phase of TeachCloud development, BPM modeling will be introduced. This will enable the students to understand business related issues related to the Cloud and how Cloud computing supports customer s business success. Further, the students will be able to perform feasibility study for running applications on the Cloud system based on the Capital Expenditure (CapEx) and Operating Expenditure (OpEx) versus hosting applications on private computing system.

11 5 Network topologies for TeachCloud 11 Data centers in Cloud computing infrastructure normally contain thousands of physical servers connected through switches, routers or other network devices. Hence, the proper design of data centers network plays a critical role in the Cloud environment since it directly affects the performance and the throughput of Cloud applications. VMFlow(Mann et al. (2011)) for example is a framework for placement and migration of VMs to reduce cost. It shows that the network topology along with network traffic demands should be taken into consideration in order to meet the objective of network power reduction. As shown in figure 8 conventional data centers are organized in a hierarchy of three layers: core, aggregation and servers layer. The core layer consists of the core routers that connect the aggregation switches to the Internet. In the servers layer, the servers are organized in racks and connected to access switches (normally called Topof-Rack switches) which are in turn connected to the aggregation switches. The aggregation layer may provide some functions such as domain service, location service, server load balancing, and more(zhang et al. (2010)). This simple design suffers from some limitations as stated in(greenberg et al. (2009)). First, as going up in the hierarchy it is becoming very hard technically and financially to sustain high bandwidth which results in preventing idle servers from being assigned to overloaded services and affects the data center performance. Second, the protocols that are normally used in the core and aggregation layers limits the utilization of the links to less than 50% of the maximum utilization. Third, the performance and communication depends on distance and the addressing scheme on the hierarchy which causes the services to scale up to nearby servers for rapid response and performance. That requires some unused capacity to be reserved for a single service for future scale up and not shared with others. Figure 8 Conventional data centers hierarchy

12 12 The diversity of the applications that can be deployed on Cloud environments makes it difficult to use real Cloud infrastructures such as Amazon EC2(Amazon EC2 (2012)), Google App Engine(AmazonEC2 (2012)) or Microsoft Azure(Chappell (2008)) for performance,throughput and cost evaluation because each application may have different configuration and deployment requirements. It is extremely hard to reconfigure such real infrastructures during the applications development and over the multiple test runs. Moreover some of the parameters are not even configurable by the developer. This motivates the use of Cloud simulation tools that provides a controllable environment for developers to test and tune their application services before deploying them on real clouds. CloudSim(Calheiros et al. (2011)) is a new generalized and extensible simulation framework that allows seamless modeling, simulation, and experimentation of Cloud computing infrastructures and application services. CloudSim was proposed to overcome the limitations of existing distributed grid and network simulators since none of them offers the environment that can be directly used for modeling Cloud computing environments. CloudSim supports modeling large scale Cloud computing environments and data centers along with many novel features such as simulating network connections between the different entities in the system. However, the inter-connections between the Cloud entities in CloudSim (data centers, hosts, SaaS providers, and end-users) are modeled based on conceptual networking abstraction. There are no entities simulating the network devices such as routers and switches. But since latency messages that depends on the network topology connecting simulated Cloud entities directly affects the overall service satisfaction experience, CloudSim models network latency using a matrix that specifies the delay (normally in milliseconds depending on the simulation unit) that a message can experience in the path between any pair of simulated entities in the network. The network topology information is stored in BRITE format and loaded every time CloudSim is initialized and it is used to build the latency matrix. When a message is sent from one simulated entity to another, it will be processed by a NetworkTopology object that uses the information loaded before to add the appropriate delay before doing further processing by the event management engine as shown in figure 9. Although this approach is much easier to implement, manage and simulate than modeling complex networking components, it does not always reflect realistic practical delays especially in the dynamic networks in which it may be hard to predict or estimate the delays between the different Cloud entities. This way of modeling the network topology does not provide control over the configuration of network components such as routing protocols and the internal organization of data centers which can dramatically affects the overall performance and throughput. Due to these limitations and more, we have integrated new network topologies which are: DCell, VL2, Portland and BCube in the TeachCloud tool as shown in figure10. The following is a description about these four topologies. DCell(Guo et al. (2008)) is a network architecture for data center meant to be a scalable and fault-tolerant solution. There is no single point of failure in DCell and it employs a distributed fault-tolerant routing protocol operating over the physical structure. Each server in DCell architecture connects to different cells via multiple links. high-level cells are built recursively from many low-level ones, in a way that the low-level cells form a fully-connected graph using mini-switches instead of high-

13 13 Figure 9 CloudSim Network Communication Figure 10 TeachCloud Network Topologies end switches to scale up. A cell in this architecture contains multiple servers, each of them has many links, one connects it to the mini switch within the cell while the others connect it to an outer servers in another cell. VL2(Greenberg et al. (2009)) is an other data center network architecture that has been recently proposed. The intention behind VL2 architecture is to provide the environment in which each service is running as if all the servers are assigned to it and those servers are all connected through a single Ethernet switch i.e. the traffic of one service should not be affected by the traffic of any other service. This should be transparently handled by the system without interrupting the service. The switches in VL2 architecture are arranged into a Clos topology that provides extensive path diversity between servers. Moreover the routing tables are calculated by OSPF protocol enabling the use of multiple paths. Assigning the IP addresses to servers in VL2 is not based on topological locations (i.e. It is independent from the switch to which a server is connected to) and the packets

14 14 are not directly forwarded to the destination based on the IP address. Instead the sender first invokes a directory system to get the actual location of the destination within the destination and then it tunnels the packet to that location. Portland(Mysore et al. (2009)) is a scalable, fault-tolerant layer 2 routing and forwarding protocol for data center environments. It leverages the observation that data center networks are often managed as a single logical network with a known topology and growth model while the support of tens of thousands of servers and other computing elements in data centers requires modularity, advance planning, and minimal human interaction. In this protocol the topology of data centers network is maintained by a centralized manager called fabric manager which is running as a process in a dedicated machine. It also performs efficient forwarding and routing by assigning a hierarchical Pseudo MAC address to each end host and encoding the host location within the topology in this address. The use of such addressing scheme reduces the size of forwarding tables in the switches. Portland edge switches perform the PMAC to MAC translation to keep the end hosts unmodified. The edge switches intercepts the ARP requests and forward them to the fabric manager which keeps an IP to PMAC mapping and returns an ARP reply through the edge switches with the PMAC address instead of the actual MAC address. BCube(Guo et al. (2009)) is an other high performance and robust network architecture for data centers. As similar to DCell, each server in BCube architecture has a number of ports connected to other servers and the multiple layers of cheap switches in the topology. This creates multiple parallel paths between any pair of servers to increase the communication bandwidth which is a key trend in BCube design. The existing routing protocols such as OSPF will not be able to fully utilize the maximum bandwidth between server under this architecture, BCube runs a source routing protocol called BSR. In BSR the sender determines the path in which a packet flow should use and encodes it in the packet header. According to the authors of(guo et al. (2009)), by using this approach the source can control the routing path without coordinations of the intermediate servers. Moreover, the intermediate servers do not involve in routing and just forward packets based on the packet header which simplifies their functionalities. BCube and DCell architectures represents examples for server-centric topologies in which the servers are connected directly to each other and the complexity of routing tables is moved to the servers. 6 Conclusion and future work The recent development in Cloud computing technology and services has urged the academia society to teach their students the concepts behind CC. In order to successfully comprehend the complexity in Cloud computing systems, an experimental effort is needed. In this paper, we have introduced the development of TeachCloud toolkit. The toolkit allows students to have hands-on experience with the different Cloud computing features. While providing a friendly user interface, the tool makes it easy for students to modify the Cloud computing parameters and components, and rerun the simulation to analyze results. Such experiments will help students to gain deeper insights of the different factors that affect Cloud

15 computing metrics such as: performance, power, SLA, BPM. Also, different Cloud network topologies (VL2, DCell, BCube, or Portland) that connects the physical resources can be simulated and compared. We aim as a future work, to formulate practical exercises using TeachCloud where instructors can use them as guidelines in the teaching process. TeachCloud will be an open source available for academia along with the practical exercises. 15 References Zhang, Qi and Cheng, Lu and Boutaba, Raouf (2010) Cloud computing: state-of-theart and research challenges, Journal of Internet Services and Applications, Vol. 1, pp Greenberg, A., Hamilton, J. R., Jain, N., Kandula, S., Kim, C., Lahiri, P., Maltz, D. A., Patel, P. and Sengupta, S. (2009) VL2: a scalable and flexible data center network, SIGCOMM Comput. Commun. Rev., Vol. 39, pp Guo, C., Wu, H., Tan, K., Shi, L., Zhang, Y. and Lu, S. (2008) Dcell: a scalable and fault-tolerant network structure for data centers, Proceedings of the ACM SIGCOMM 2008 conference on Data communication, Seattle, WA, USA, pp Buyya, R., Ranjan, R. and Calheiros, R.N. (2009) Modeling and simulation of scalable Cloud computing environments and the CloudSim toolkit: Challenges and opportunities, Proceedings of the international conference on high performance computing and cimulation (HPCS), 2009, Leipzig, Germany, pp Guo, C., Lu, G., Li, D., Wu, H., Zhang, X., Shi, Y., Tian, C., Zhang, Y. and Lu, S. (2009) BCube: a high performance, server-centric network architecture for modular data centers, Proceedings of the ACM SIGCOMM 2009 conference on Data communication, Barcelona, Spain, pp Faniyi, F. and Bahsoon, R. (2011) Engineering Proprioception in SLA Management for Cloud Architectures, Proceedings of the 9th Working IEEE/IFIP Conference on Software Architecture (WICSA), 2011, Boulder, CO, USA, pp Kim, K. H., Beloglazov, A. and Buyya, R. (2009) Power-aware Provisioning of Cloud Resources for Real-time Services. Proceedings of the 7th international workshop on middleware for Grids, Clouds and e-science. Urbana Champaign, Illinois, USA, Patel, P., Ranabahu, A. and Sheth, A. (2011) Service Level Agreement in Cloud Computing, In Cloud Workshops at OOPSLA09, 2009 Calheiros, R. N., Ranjan, R., Beloglazov, A., De Rose, C. A. F. and Buyya, R. (2011) CloudSim: a toolkit for modeling and simulation of Cloud computing environments and evaluation of resource provisioning algorithms, Software: Practice and Experience, Vol. 41, pp AmazoneEC2 (2012) Amazon Elastic Compute Cloud (Amazon EC2), GoogleApp (2012) Google App Engine, Mysore, R. N., Pamboris, A., Farrington, N., Huang, N., Miri, P., Radhakrishnan, S., Subramanya, V. and Vahdat, A. (2009) PortLand: a scalable fault-tolerant layer 2 data center network fabric, SIGCOMM Comput. Commun. Rev., Vol. 39, pp Chappell, D. (2008) Introducing the Azure Services Platform, White Paper, sponsored by Microsoft Corporation.

16 16 Beitch, A., Liu, B., Yung, T., Griffith, R., Fox, A. and Patterson, D. A. (2010) Rain: A Workload Generation Toolkit for Cloud Computing Applications, Technical Report UCB/EECS Mann, V., Kumar, A., Dutta, P. and Kalyanaraman, S. (2011) VMFlow: Leveraging VM Mobility to Reduce Network Power Costs in Data Centers, Lecture Notes in Computer Science (NETWORKING 2011), Vol. 6640, pp