logo资料库

介绍cloudsim的论文.pdf

第1页 / 共11页
第2页 / 共11页
第3页 / 共11页
第4页 / 共11页
第5页 / 共11页
第6页 / 共11页
第7页 / 共11页
第8页 / 共11页
资料共11页,剩余部分请下载后查看
ou
ou
ou
Modeling and Simulation of Scalable Cloud Computing Environments and the CloudSim Toolkit: Challenges and Opportunities Rajkumar Buyya1, Rajiv Ranjan2 and Rodrigo N. Calheiros1,3 1 Grid Computing and Distributed Systems (GRIDS) Laboratory Department of Computer Science and Software Engineering The University of Melbourne, Australia 2 Department of Computer Science and Engineering The University of New South Wales, Sydney, Australia 3Pontifical Catholic University of Rio Grande do Sul Porto Alegre, Brazil Email: {raj, rodrigoc}@csse.unimelb.edu.au, rajiv@unsw.edu.au Abstract have different applications Cloud computing aims to power the next generation data centers and enables application service providers to lease data center capabilities for deploying applications depending on user QoS (Quality of Service) requirements. Cloud composition, configuration, and deployment requirements. Quantifying the performance of resource allocation policies and application scheduling algorithms at finer details in Cloud computing environments for different application and service models under varying load, energy performance (power consumption, heat dissipation), and system size is a challenging problem to tackle. To simplify this process, in this paper we propose CloudSim: an extensible simulation toolkit that enables modelling and simulation of Cloud computing environments. The CloudSim toolkit supports modelling and creation of one or more virtual machines (VMs) on a simulated node of a Data Center, jobs, and their mapping to suitable VMs. It also allows simulation of multiple Data Centers to enable a study on federation and associated policies for migration of VMs for reliability and automatic scaling of applications. 1. Introduction Cloud computing delivers infrastructure, platform, and software as services, which are made available as subscription-based services in a pay-as-you-go model to consumers. These services in industry are respectively referred to as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). The importance of these services is highlighted in a recent report from Berkeley as: “Cloud computing, the long-held dream of computing as a utility, has the potential to transform a large part of the IT industry, making software even more attractive as a service” [11]. Clouds [10] aim to power the next generation data centers by exposing them as a network of virtual services 1 (hardware, database, user-interface, application logic) so that users are able to access and deploy applications from anywhere in the world on demand at competitive costs depending on users QoS (Quality of Service) requirements [1]. Developers with innovative ideas for new Internet services are no longer required to make large capital outlays in the hardware and software infrastructures to deploy their services or human expense to operate it [11]. It offers significant benefit to IT companies by freeing them from the low level task of setting up basic hardware and software infrastructures and thus enabling more focus on innovation and creation of business values. real time Some of the traditional and emerging Cloud-based include social networking, web hosting, applications content delivery, and instrumented data processing. Each of these application types has different composition, configuration, and deployment requirements. Quantifying the performance of scheduling and allocation policies in a real Cloud environment for different application and service models under different conditions is extremely challenging because: (i) Clouds exhibit varying demand, supply patterns, and system size; and (ii) users have heterogenous and competing QoS requirements. The use of real infrastructures such as Amazon EC2, limits the experiments to the scale of the infrastructure, and makes the reproduction of results an extremely difficult undertaking. The main reason for this being the conditions prevailing in the Internet-based environments are beyond the control of developers of resource allocation and application scheduling algorithms. An alternative is the utilization of simulation tools that open the possibility of evaluating the hypothesis prior to software development in an environment where one can reproduce the case of Cloud computing, where access to the infrastructure incurs payments in real currency, simulation-based approaches offer significant benefits to Cloud customers by allowing tests. Specifically in
them to: (i) test their services in repeatable and controllable environment free of cost; and (ii) tune the performance bottlenecks before deploying on real Clouds. At the provider side, simulation environments allow evaluation of different kinds of resource leasing scenarios under varying load and pricing distributions. Such studies could aid providers in optimizing the resource access cost with focus on improving profits. In the absence of such simulation platforms, Cloud customers and providers have to rely either on theoretical and imprecise evaluations, or on try- and-error approaches that lead to inefficient service performance and revenue generation. Considering that none of the current distributed system simulators [4][7][9] offer the environment that can be directly used by the Cloud computing community, we propose CloudSim: a new, generalized, and extensible simulation framework that enables seamless modeling, simulation, and experimentation of emerging Cloud computing infrastructures and application services. By using CloudSim, researchers and industry-based developers can focus on specific system design issues that they want to investigate, without getting concerned about the low level details related to Cloud-based infrastructures and services. CloudSim offers the following novel features: (i) support for modeling and simulation of large scale Cloud computing infrastructure, including data centers on a single physical computing node; and (ii) a self-contained platform for modeling data centers, service brokers, scheduling, and allocations policies. Among the unique features of CloudSim, there are: (i) availability of virtualization engine, which aids in creation and management of multiple, independent, and co-hosted virtualized services on a data center node; and (ii) flexibility to switch between space- shared and time-shared allocation of processing cores to virtualized features of CloudSim would speed up the development of new resource allocation policies and scheduling algorithms for Cloud computing. services. These compelling that need 2. Key Concepts and Terminologies This section presents background information on various architectural elements that form the basis for Cloud computing. It also presents requirements of various applications across multiple geographically distributed data centers owned by one or more service providers. As development of resource allocation and application scaling techniques and their performance evaluation under various operational scenarios in a real Cloud environment is difficult and hard to repeat; we propose the use of simulation as an alternate approach for achieving the same. scale to 2.1 Cloud computing Cloud computing can be defined as “a type of parallel and distributed system consisting of a collection of inter- connected and virtualized computers that are dynamically provisioned and presented as one or more unified computing resources based on service-level agreements 2 through negotiation between established the service provider and consumers” [1]. Some examples of emerging Cloud computing infrastructures are Microsoft Azure [2], Amazon EC2, Google App Engine, and Aneka [3]. Emerging Cloud applications such as social networking, gaming portals, business applications, content delivery, and scientific workflows operate at the highest layer of the architecture. Actual usage patterns of many real-world applications vary with in unpredictable ways. These applications have different Quality of Service (QoS) requirements depending on time criticality and users’ interaction patterns (online/offline). time, most of time the 2.2 Layered Design Figure 1 shows the layered design of service-oriented Cloud computing architecture. Physical Cloud resources along with core middleware capabilities form the basis for delivering IaaS. The user-level middleware aims at providing PaaS capabilities. The top layer focuses on application services (SaaS) by making use of services provided by the lower layer services. PaaS/SaaS services are often developed and provided by 3rd party service providers, who are different from IaaS providers [13]. User-Level Middleware: This layer includes the software frameworks such as Web 2.0 Interfaces (Ajax, IBM Workplace) that help developers in creating rich, cost- effecting user-interfaces for browser-based applications. The layer also provides the programming environments and composition tools that ease the creation, deployment, and execution of applications in Clouds. User level Social computing, Enterprise, ISV, Scientific, CDNs, ... Cloud applications User-Level Middleware Cloud programming: environments and tools Web 2.0 Interfaces, Mashups, Concurrent and Distributed Programming, Workflows, Libraries, Scripting QoS Negotiation, Admission Control, Pricing, SLA Management, Monitoring, Execution Management, Metering, Accounting, Billing Apps Hosting Platforms Core Middleware Virtual Machine (VM), VM Management and Deployment Cloud resources System level A d a p t t i v e M a n a g e m e n A u t o n o m i c / C l o u d E c o n o m y Figure 1. Layered Cloud Computing Architecture. Core Middleware: This layer implements the platform level services that provide runtime environment enabling Cloud computing capabilities to application services built using User-Level Middlewares. Core services at this layer includes Dynamic SLA Management, Accounting, Billing, Execution monitoring and management, and Pricing. The well-known examples of services operating at this layer are Amazon EC2, Google App Engine, and Aneka [3]. System Level: The computing power in Cloud computing environments is supplied by a collection of data centers,
the data centers. which are typically installed with hundreds to thousands of servers [9]. At the System Level layer there exist massive physical resources (storage servers and application servers) that power These servers are transparently managed by the higher level virtualization [8] services and toolkits that allow sharing of their capacity among virtual instances of servers. These VMs are isolated from each other, which aid in achieving fault tolerant behavior and isolated security context. 2.3 Federation (Inter-Networking) of Clouds Current Cloud Computing providers have several data centers at different geographical locations over the Internet in order to optimally serve costumers needs around the world. However, existing systems does not support mechanisms and policies for dynamically coordinating load-shredding among different data centers in order to determine optimal location for hosting application services to achieve reasonable service satisfaction levels. Further, the Cloud service providers are unable to predict geographic distribution of users consuming their services, hence the load coordination must happen automatically, and distribution of services must change in response to changes in the load behaviour. Figure 2 depicts such a service-oriented Cloud computing architecture consisting of service consumer’s brokering and provider’s coordinator services that support utility-driven internetworking of clouds [12]: application scheduling, resource allocation, and workload migration. Figure 2. Clouds and their federated network mediated by a Cloud exchange. The Cloud coordinator component is instantiated by each data center that: (i) exports the Cloud services, both infrastructure and platform-level, to the federation; (ii) keeps track of load on the data center and undertakes negotiation with other Cloud providers for dynamic scaling of services across multiple data centers for handling the peak in demands; and (iii) monitors the application execution and oversees that agreed SLAs are delivered. The Cloud brokers acting on behalf of service consumers (users) identify suitable Cloud service providers through the Cloud Exchange and negotiate with Cloud 3 Coordinators for allocation of resources that meets the QoS needs of hosted applications. The Cloud Exchange (CEx) acts as a market maker for bringing together service providers and consumers. It aggregates the infrastructure demands from the Cloud brokers and evaluates them against the available supply currently published by the Cloud Coordinators. The applications from that would benefit the aforementioned federated Cloud computing system include social networks such as Facebook and MySpace, Content Delivery Networks (CDNs). Social networking sites serve dynamic contents to millions of users, whose access and interaction patterns are difficult to predict. In general, social networking websites are built using multi-tiered web applications such as WebSphere and persistency layers such as the MySQL relational database. Usually, each component will run in a different virtual machine, which can be hosted in data centers owned by different Cloud computing providers. Additionally, each plug-in developer has the freedom to choose which Cloud computing provider offers the services that are more suitable to run his/her plug-in. As a consequence, a typical social networking web application is formed by hundreds of different services, which may be hosted by dozens of Cloud-oriented data centers around the world. Whenever there is a variation in temporal and spatial locality of workload, each application component must dynamically scale to offer good quality of experience to users. 2.4 A Case for Simulation and Related Work is an event-driven simulation In the past decade, Grids [5] have evolved as the infrastructure for delivering high-performance services for compute and data-intensive scientific applications. To support research and development of new Grid components, policies, and middleware; several Grid simulators, such as GridSim [9], SimGrid [7], and GangSim [4] have been proposed. SimGrid is a generic framework for simulation of distributed applications on Grid platforms. Similarly, GangSim is a Grid simulation toolkit that provides support for modeling of Grid-based virtual organisations and resources. On the other hand, GridSim for heterogeneous Grid resources. It supports modeling of grid entities, users, machines, and network, including network traffic. Although the aforementioned toolkits are capable of modeling and simulating the Grid application behaviors (execution, scheduling, allocation, and monitoring) in a distributed environment consisting of multiple Grid organisations, none of these are able to support the infrastructure and application-level requirements arising from Cloud computing paradigm. In particular, there is very little or no support in existing Grid simulation toolkits for modeling of on-demand virtualization enabled resource and application management. Further, Clouds promise to deliver services on subscription-basis in a pay-as-you-go model to Cloud customers. Hence, Cloud infrastructure toolkit
VMs in the Cloud. A Cloud host can be concurrently shared among a number of VMs that execute applications based on user-defined QoS specifications. The top-most layer in the simulation stack is the User Code that exposes configuration related functionalities for hosts (number of machines, their specification and so on), applications (number of tasks and their requirements), VMs, number of users and their application types, and broker scheduling policies. A Cloud application developer can generate: (i) a mix of user request distributions, application configurations; and (ii) Cloud availability scenarios at this layer and perform robust tests based on the custom configurations already supported within the CloudSim. As Cloud computing is a rapidly evolving research area, there is a severe lack of defined standards, tools and methods that can efficiently tackle the infrastructure and application level complexities. Hence in the near future there would be a number of research efforts both in academia and industry towards defining core algorithms, policies, application benchmarking based on execution contexts. By extending the basic functionalities already exposed by CloudSim, researchers would be able to perform and configurations, hence allowing the development of best practices in all the critical aspects related to Cloud Computing. tests based on scenarios specific modeling and simulation toolkits must provide support for economic entities such as Cloud brokers and Cloud exchange for enabling real-time trading of services between customers and providers. Among the currently available simulators discussed in this paper, only GridSim offers support for economic-driven resource management and application scheduling simulation. Another aspect related to Clouds that should be considered is that research and development in Cloud computing systems, applications and services are in their infancy. There are a number of important issues that need detailed investigation along the Cloud software stack. Topics of interest to Cloud developers include economic strategies for provisioning of virtualized resources to incoming user's requests, scheduling of applications, resources and federation of clouds. To support and accelerate the research related to Cloud computing systems, applications and services; it is important that the necessary software tools are designed and developed to aid researchers. negotiations, inter-cloud discovery, 3. CloudSim Architecture the required for and software implementation of layered framework Figure 3 shows the CloudSim architectural components. At the lowest layer is the SimJava discrete event simulation engine [6] that implements the core functionalities higher-level simulation frameworks such as queuing and processing of events, creation of system components (services, host, data center, broker, virtual machines), communication between components, and management of the simulation clock. Next follows the libraries implementing the GridSim toolkit [9] that support: (i) high level software components infrastructures, including for modeling multiple Grid networks and associated (ii) fundamental Grid components such as the resources, data sets, workload traces, and information services. traffic profiles; and the core The CloudSim is implemented at the next level by programmatically extending functionalities exposed by the GridSim layer. CloudSim provides novel support for modeling and simulation of virtualized Cloud- based data center environments such as dedicated management interfaces for VMs, memory, storage, and bandwidth. CloudSim layer manages the instantiation and execution of core entities (VMs, hosts, data centers, application) during the simulation period. This layer is capable of concurrently instantiating and transparently managing a large scale Cloud infrastructure consisting of thousands of system components. The fundamental issues such as provisioning of hosts to VMs based on user requests, managing application execution, and dynamic monitoring are handled by this layer. A Cloud provider, who wants to study the efficacy of different policies in allocating its hosts, would need to implement his strategies at this layer by programmatically extending the core VM provisioning functionality. There is a clear distinction at this layer on how a host is allocated to different competing 4 Figure 3. Layered CloudSim architecture. One of the design decisions that we had to make as the CloudSim was being developed was whether to extensively reuse existing simulation libraries and frameworks or not. We decided to take advantage of already implemented and
its implementation of networking, proven libraries such as GridSim and SimJava to handle low-level requirements of the system. For example, by using SimJava, we avoided reimplementation of event handling and message passing among components. This saved us time and cost of software engineering and testing. Similarly, the use of the GridSim framework allowed us to reuse information services, files, users, and resources. Since,SimJava and GridSim have been extensively utilized in conducting cutting edge research in Grid resource management by several researchers. Therefore, bugs that may compromise the validity of the simulation have been already detected and fixed. By reusing these long validated frameworks, we were able to focus on critical aspects of the system that are relevant to Cloud computing. At the same time taking advantage of the reliability of components that are not directly related to Clouds. 3.1. Modeling the Cloud The core hardware infrastructure services related to the Clouds are modeled in the simulator by a Datacenter component for handling service requests. These requests are application elements sandboxed within VMs, which need to be allocated a share of processing power on Datacenter’s host components. By VM processing, we mean a set of operations related to VM life cycle: provisioning of a host to a VM, VM creation, VM destruction, and VM migration. A Datacenter is composed by a set of hosts, which are responsible for managing VMs during their life cycles. Host is a component that represents a physical computing node in a Cloud: it is assigned a pre-configured processing capability (expressed in million of instructions per second – MIPS), memory, storage, and a scheduling policy for allocating processing cores to virtual machines. The Host component implements interfaces that support modeling and simulation of both single-core and multi-core nodes. (FCFS) Allocation of application-specific VMs to Hosts in a Cloud-based data center is the responsibility of the Virtual Machine Provisioner component. This component exposes a number of custom methods for researchers, which aids in implementation of new VM provisioning policies based on optimization goals (user centric, system centric). The default policy implemented by the VM Provisioner is a straightforward policy that allocates a VM to the Host in First-Come-First-Serve system parameters such as the required number of processing cores, memory and storage as requested by the Cloud user form the basis for such mappings. Other complicated policies can be written by the researchers based on the infrastructure and application demands. For each Host component, the allocation of processing cores to VMs is done based on a host allocation. The policy takes into account how many processing cores will be delegated to each VM, and how much of the processing core's capacity will effectively be attributed for a given VM. So, it is possible to assign specific CPU cores to specific VMs (a space-shared policy) or to dynamically basis. The 5 distribute the capacity of a core among VMs (time-shared policy), and to assign cores to VMs on demand, or to specify other policies. Each Host component instantiates a VM scheduler component that implements the space-shared or time- shared policies for allocating cores to VMs. Cloud system developers and researchers can extend the VM scheduler component for experimenting with more custom allocation policies. Next, the finer level details related to the time- shared and space-shared policies are described. 3.2. Modeling the VM allocation One of the key aspects that make a Cloud computing infrastructure different from a Grid computing is the massive deployment of virtualization technologies and tools. Hence, as compared to Grids, we have in Clouds an extra layer (the virtualization) that acts as an execution and hosting environment for Cloud-based application services. Hence, traditional application mapping models that assign individual application elements to computing nodes do not accurately represent the computational abstraction which is commonly associated with the Clouds. For example, consider a physical data center host that has single processing core, and there is a requirement of concurrently instantiating two VMs on that core. Even though in practice there is isolation between behaviors (application execution context) of both VMs, the amount of resources available to each VM is constrained by the total processing power of the host. This critical factor must be considered during the allocation process, to avoid creation of a VM that demands more processing power than the one available in the host, as multiple task units in each virtual machine shares time slices of the same processing core. To allow simulation of different policies under varying levels of performance isolation, CloudSim supports VM scheduling at two levels: First, at the host level and second, at the VM level. At the host level, it is possible to specify how much of the overall processing power of each core in a host will be assigned to each VM. At the VM level, the VMs assign specific amount of the available processing power to the individual task units that are hosted within its execution engine. At each level, CloudSim implements the time-shared and space-shared resource allocation policies. To clearly illustrate the difference between these policies and their effect on the application performance, in Figure 4 we show a simple scheduling scenario. In this figure, a host with two CPU cores receives request for hosting two VMs, and each one requiring two cores and running four tasks units: t1, t2, t3 and t4 to be run in VM1, while t5, t6, t7, and t8 to be run in VM2. Figure 4(a) presents a space-shared policy for both VMs and task units: as each VM requires two cores, only one VM can run at a given instance of time. Therefore, VM2 can only be assigned the core once VM1 finishes the execution of task units. The same happens for tasks hosted within the VM: as each task unit demands only one core,
two of them run simultaneously, and the other two are queued until the completion of the earlier task units. Finally, in Figure 4(d) a time-shared allocation is applied for both VMs and task units. Hence, the processing power is concurrently shared by the VMs and the shares of each VM are concurrently divided among the task units assigned to each VM. In this case, there are no queues either for virtual machines or for task units. these Further, 3.3. Modeling the Cloud Market Support for services that act as a market maker enabling capability sharing across Cloud service providers and customer through its match making services is critical to Cloud computing. services need mechanisms to determine service costs and pricing policies. Modeling of costs and pricing policies is an important aspect to be considered when designing a Cloud simulator. To allow the modeling of the Cloud market, four market-related properties are associated to a data center: cost per processing, cost per unit of memory, cost per unit of storage, and cost per unit of used bandwidth. Cost per memory and storage incur during virtual machine creation. Cost per bandwidth incurs during data transfer. Besides costs for use of memory, storage, and bandwidth, the other cost is associated to use of processing resources. Inherited from the GridSim model, this cost is associated with the execution of user task units. Hence, if VMs were created but no task units were executed on them, only the costs of memory and storage will incur. This behavior may, of course, be changed by users. 4. Design and Implementation of CloudSim The Class design diagram for the simulator is depicted in Figure 5. In this section, we provide finer details related to the fundamental classes of CloudSim, which are building blocks of the simulator. Figure 4. Effects of different scheduling policies on task execution: (a) Space-shared for VMs and tasks, (b) Space-shared for VMs and time-shared for tasks, (c) Time-shared for VMs, space-shared for tasks, and (d) Time-shared for VMs and tasks. In Figure 4(b), a space-shared policy is used for allocating VMs, but a time-shared policy is used for allocating individual task units within VM. Hence, during a VM lifetime, all the tasks assigned to it dynamically context switch until their completion. This allocation policy enables the task units to be scheduled at an earlier time, but significantly affecting the completion time of task units that are ahead the queue. In Figure 4(c), a time-shared scheduling is used for VMs, and a space-shared one is used for task units. In this case, each VM receives a time slice of each processing core, and then slices are distributed to task units on space-shared basis. As the core is shared, the amount of processing power available to the VM is comparatively lesser than the aforementioned scenarios. As task unit assignment is space-shared, hence only one task can be allocated to each core, while others are queued in for future consideration. 6 in a Cloud computing environment. DataCenter. This class models the core infrastructure level services (hardware, software) offered by resource providers It encapsulates a set of compute hosts that can be either homogeneous or heterogeneous as regards to their resource configurations (memory, cores, capacity, and storage). Furthermore, every DataCenter component instantiates a generalized that implements a set of policies for allocating bandwidth, memory, and storage devices. resource provisioning component DatacenterBroker. This class models a broker, which is responsible for mediating between users and service providers depending on users’ QoS requirements and deploys service tasks across Clouds. The broker acting on behalf of users identifies suitable Cloud service providers through (CIS) and negotiates with them for an allocation of resources that meet QoS needs of users. The researchers and system developers must extend for conducting experiments with their custom developed application placement policies. Information Service the Cloud this class SANStorage. This class models a storage area network that is commonly available to Cloud-based data centers for
Figure 5: CloudSim class design diagram. storing large chunks of data. SANStorage implements a simple interface that can be used to simulate storage and retrieval of any amount of data, at any time subject to the availability of network bandwidth. Accessing files in a SAN at run time incurs additional delays for task unit execution, due to time elapsed for transferring the required data files through the data center internal network. VirtualMachine. This class models an instance of a VM, whose management during its life cycle is the responsibility of the Host component. As discussed earlier, a host can simultaneously instantiate multiple VMs and allocate cores based on predefined processor sharing policies (space-shared, time-shared). Every VM component has access to a component that stores the characteristics related to a VM, such as memory, processor, storage, and the VM’s internal scheduling policy, which is extended from the abstract component called VMScheduling. class models Cloudlet. This the Cloud-based application services (content delivery, social networking, business workflow), which are commonly deployed in the data centers. CloudSim represents the complexity of an application in terms of its computational requirements. Every application component has a pre-assigned instruction length (inherited from GridSim’s Gridlet component) and amount of data transfer (both pre and post fetches) that needs to be undertaken for successfully hosting the application. to a data center. This class CloudCoordinator. This abstract class provides federation capacity is responsible for not only communicating with other peer CloudCoordinator and Cloud Brokers (DataCenterBroker), but also for monitoring the internal state of a data center that plays integral role in load- balancing/application scaling decision making. The monitoring occurs periodically in terms of simulation time. The specific event that triggers the load migration is services 7 implemented by CloudSim users through Sensor component. Each sensor may model one specific triggering procedure to undertake dynamic load-shredding. the CloudCoordinator that may cause BWProvisioner. This is an abstract class that models the provisioning policy of bandwidth to VMs that are deployed on a Host component. The function of this component is to undertake the allocation of network bandwidths to set of competing VMs deployed across the data center. Cloud system developers and researchers can extend this class with their own policies (priority, QoS) to reflect the needs of their applications. MemoryProvisioner. This is an abstract class that represents the provisioning policy for allocating memory to VMs. This component models policies for allocating physical memory spaces to the competing VMs. The execution and deployment of VM on a host is feasible only if the MemoryProvisioner component determines that the host has the amount of free memory, which is requested for the new VM deployment. VMProvisioner. This abstract class represents the provisioning policy that a VM Monitor utilizes for allocating VMs to Hosts. The chief functionality of the VMProvisioner is to select available host in a data center, the memory, storage, and availability which meets requirement for a VM deployment. The default SimpleVMProvisioner implementation provided with the CloudSim package allocates VMs to the first available Host that meets the aforementioned requirements. Hosts are considered for mapping in a sequential order. However, more complicated policies can be easily implemented within this component for achieving optimized allocations, for example, selection of hosts based on their ability to meet QoS requirements such as response time, budget.
VMMAllocationPolicy. This is an abstract class implemented by a Host component that models the policies (space-shared, allocating processing power to VMs. The functionalities of this class can easily be overridden to accommodate application specific processor sharing policies. time-shared) required for 4.1. Entities and threading As the CloudSim programmatically builds upon the SimJava discrete event simulation engine, it preserves the SimJava’s threading model for creation of simulation entities. A programming component is referred to as an entity if it directly extends the core Sim_Entity component of SimJava, which implements the Runnable interface. Every entity is capable of sending and receiving messages through the SimJava’s shared event queue. The message propagation (sending and receiving) occurs through input and output ports that SimJava associates with each entity in the simulation system. Since threads incur a lot of memory and processor context switching overhead, having a large number of threads/entities in a simulation environment can be performance bottleneck due to limited scalability. To counter this behavior, CloudSim minimizes the number of entities in the system by implementing only the core components (Users and Datacenters) as the inherited members of SimJava entities. This design decision is significant as it helps CloudSim in modeling a really large scale simulation environment on a computing machine (desktops, laptops) with moderate processing capacity. Other key CloudSim components such as VMs, provisioning policies, hosts are instantiated as standalone objects, which are lightweight and do not compete for processing power. Hence, regardless of the number of hosts in a simulated data center, runtime environment (Java virtual machine) needs to manage only two threads (Datacenter and Broker). As the processing of task units is handled by respective VMs, therefore their (task) progress must be updated and monitored after every simulation step. To handle this, an internal event is generated regarding the expected completion time of a task unit to inform the Datacenter entity about the future completion events. Thus, at each simulation step, each Datacenter invokes a method called updateVMsProcessing() for every host in the system, to update processing of tasks running within the VMs. The argument of this method is the current simulation time and the return type is the next expected completion time of a task running in one of the VMs on a particular host. The least time among all the finish times returned by the hosts is noted for the next internal event. At the host level, invocation of updateVMsProcessing() triggers an updateGridletsProcessing() method, which directs every VM to update its tasks unit status (finish, suspended, executing) with the Datacenter entity. This method logic as described previously for updateVMsProcessing() but at the VM level. Once this method is called, VMs return the next expected the similar implements the 8 completion time of the task units currently managed by them. The least completion time among all the computed values is send to the Datacenter entity. As a result, completion times are kept in a queue that is queried by Datacenter after each event processing step. If there are completed tasks waiting in the queue, then they are removed from it and sent back to the user. 4.2. Communication among Entities Figure 6 depicts the flow of communication among core CloudSim entities. In the beginning of the simulation, each Datacenter entity registers itself with the CIS (Cloud Information Service) Registry. CIS provides database level match-making services for mapping user requests to suitable Cloud providers. Brokers acting on behalf of users consult the CIS service about the list of Clouds who offer infrastructure application requirements. In case the match occurs the broker deploys the application with the Cloud that was suggested by the CIS. services matching user’s Figure 6. Simulation data flow. The communication flow described so far relates to the basic flow in a simulated experiment. Some variations in this flow are possible depending on policies. For example, messages from Brokers to Datacenters may require a confirmation, from the part of the Datacenter, about the execution of the action, or the maximum number of VMs a user can create may be negotiated before VM creation. 5. Experiments and Evaluation In this section, we present experiments and evaluation that we undertook in order to quantify the efficiency of CloudSim in modeling and simulating Cloud computing environments. The experiments were conducted on a Celeron machine having configuration: 1.86GHz with 1MB of L2 cache and 1 GB of RAM running a standard Ubuntu Linux version 8.04 and JDK 1.6. To evaluate the overhead in building a simulated Cloud computing environment that consists of a single data center, a broker and a user, we performed series of experiments. The number of hosts in the data center in each
分享到:
收藏