PerficientCloudSim: a tool to simulate large-scale computation in heterogeneous clouds

Abstract

The major reason for using a simulator, instead of a real test-bed, is to enable repeatable evaluation of large-scale cloud systems. CloudSim, the most widely used simulator, enables users to implement resource provisioning, and management policies. However, CloudSim does not provide support for: (i) interactive online services; (ii) platform heterogeneities; (iii) virtual machine migration modelling; and (iv) other essential models to abstract a real datacenter. This paper describes modifications needed in the classical CloudSim to support realistic experimentations that closely match experimental outcomes in a real system. We extend, and partially re-factor CloudSim to “PerficientCloudSim” in order to provide support for large-scale computation over heterogeneous resources. In the classical CloudSim, we add several classes for workload performance variations due to: (a) CPU heterogeneities; (b) resource contention; and (c) service migration. Through plausible assumptions, our empirical evaluation, using real workload traces from Google and Microsoft Azure clusters, demonstrates that “PerficientCloudSim” can reasonably simulate large-scale heterogeneous datacenters in respect of resource allocation and migration policies, resource contention, and platform heterogeneities. We discuss statistical methods to measure the accuracy of the simulated outcomes.

Appendix 1: CloudSim

CloudSim [1] is a tool-kit to model and simulate IaaS clouds. CloudSim is an extension of the GridSim [7] simulator that uses SimJava²³ library as a framework for event handling and passing messages between entities. Due to several limitations of SimJava, CloudSim is designed using a new discrete event management framework as demonstrated in [1]. CloudSim is widely used to simulate resource provisioning techniques. It has the ability to perform simulations of IaaS clouds where heterogeneous workload is assigned and executed with different experimental conditions. It enables users to express datacenter characteristics, including the number and specification of hosts, storage, network topology and design of datacenter usage. It enables the design of VM placement policies, allocation of host cores (PEs) to VMs and division of CPU time between users’ workloads. Switching on/off hosts, VM consolidation with migration, and integration of energy models (SPECpower²⁴ benchmarks) are the notable techniques to model energy and performance efficient datacenters in CloudSim [8].

Fig. 12

CloudSim basic architecture [1]

Within CloudSim, the application layer is managed by a broker which requests VMs creation. A broker can concurrently own one or more VMs, that are kept running on hosts until their explicit de-allocation by the broker, i.e. tasks are finished or some local requests are waiting (high priority) according to the SLA lease. VMs and host capacities are defined in millions of instructions per second (MIPS). For example, a CPU of 2.0 GHz is defined 2000 millions instructions per second, which means that it can execute 2000 instructions per second. Tasks (cloudlets) are allocated to VMs and defined in terms of the number of CPU instructions necessary for their completion (MIPS). Note that, if MIPS is used as a single measure, it means that workloads are basically homogeneous. Therefore, we assume larger or smaller MIPS as proxy for various workloads, represented by their CPU architecture-specific runtimes, since there is no other way to simulate the distinction between various workloads (e.g. a disk-bound and a CPU bound task). This provides a motivation for the discussion of CPU architectures and workloads at this point, which seems relevant. From CPU heterogeneity point of view, smaller or larger MIPS would certainly translate to variations in runtimes even for similar workloads. From application heterogeneity point of view, applications’ (workloads) runtimes (therefore, smaller or larger MIPS) are mapped statistically to runtimes of several benchmark workloads, such as Bzip2, Povray [9]. Closer similarities in runtimes (i.e. smaller or larger MIPS) are assumed as different types of applications. Figure 12 shows the multi-layered design of the CloudSim simulator framework and its various architectural components [1].

The basic requirements to run CloudSim include: (i) Sun’s Java version 8 or newer; and (ii) Apache ant²⁵ or Maven²⁶ to compile CloudSim. Both Ant and Maven “simplify Java project management by providing various tools and plug-ins for project building, testing and packaging, dependency management, etc.” CloudSim is not compatible with older versions of Java and may not be compatible with non-Sun Java version, such as GCJ or J++. A numerical library such as Flanagan’s²⁷ or Apache Math²⁸ is needed to run several built in examples inside the CloudSim. CloudSim can be installed on any desktop machine that supports Java 8 or newer version. However, machines with large memories are preferable, particularly, when dealing with large-scale datacenter simulations. Each CloudSim entity is an object, created at the start of the simulation, and this may cause heap memory issues when the Java garbage collector is not able to find un-referenced objects for deletion.

CloudSim has been widely used to: (i) measure the effects of energy-aware VM allocation and migration algorithms on datacenter OpEx (operational expenditures); and (ii) evaluate scheduling mechanisms to allocate tasks to VMs [62]. Because CloudSim is an event driven simulation toolkit, its components maintain a message queue and generate messages, which they pass to other entities. A CloudSim simulation can instantiate several datacenters, each of which comprises several hosts (heterogeneous), which in turn host/accommodate multiple VMs executing one or more tasks. A datacenter is then characterised by its policy of placing requested VMs onto hosts (with the default strategy being to select the host with the least CPU cores in use) [8]. Moreover, each datacenter can be configured to charge users with different prices for storage, VM usage and data transfer (i.e. pricing models).

Each host has its own policy, which defines how its compute resources are to be divided among accommodated VMs, i.e. whether VMs operate on shared (time shared) or distinctly separated (space shared) resources and whether over subscription of resources is allowed or not. In a similar fashion, each VM also comes with a scheduling policy which specifies how its compute resources are to be divided among tasks. On top of this architecture, an application-specific datacenter broker supervises the whole simulation. The broker is responsible to: (a) make requests for allocation and deallocation of VMs inside the datacenter, and (b) assign tasks to VMs for execution. Figure 13 shows the UML class diagram of CloudSim and its various components.

Fig. 13

CloudSim class design diagram [1] [an explanation of these classes is given in Sect. 1]

As a completely customisable tool, CloudSim allows extension of policies in all its components, which makes it a suitable research tool that can handle the complexities arising from simulated platforms [1]. Several extensions to CloudSim have been presented in the literature. For example: (i) NetworkCloudSim [63], which introduces sophisticated network modelling and inter-task communication; (ii) EMUSIM [64], which uses emulation to identify the performance requirements and runtime workload characteristics and feeds this information to CloudSim for more accurate simulation; and (iii) CloudMIG [65], which “facilitates the migration of software systems to the cloud by contrasting different cloud deployment options based on the simulation of a code model in CloudSim.” The internal processing of CloudSim in the form of a sequence diagram is shown in Fig. 14. The two methods updateVMProcessing() and updateCloudletsProcessing() are the core processes of the simulation internal processing. At datacenter level, at each simulation step, the former method updates VMs processing inside the hosts. Similarly, at host level, the former method invokes the latter one to update tasks execution which are currently running inside VMs. A comprehensive discussion of the simulation internal processing is available in [1].

Fig. 14

CloudSim sequence diagram [40] (the CloudSim core classes are described in Sect. 2)

Despite its popularity and number of citations, CloudSim is not validated and verified yet, although there are several models inside CloudSim which have been validated in the real world. For example, the linear power model and migration performance model are validated as accurate ($\sim$ 10% degradation) [66]. However, the linear power model assumes that energy consumption exclusively depends on CPU utilisation by ignoring other components such as memory and network. Moreover, CloudSim does not take into account several important parameters in its VM migration model such as over commitment and memory dirtying rate [67]. Similarly, there is no model to capture the overhead involved in the virtualisation and migration technologies.²⁹ Das et al. [40] have extended CloudSim with these models and have validated it through comparing with real-world experiments with an approximate error of $\pm 2\%$.

CloudSim simulator is designed with using two different kinds of classes: (i) the main classes which interact with each other to simulate a cloud (Sect. 1); and (ii) the core classes which make simulations possible (Sect. 2). We briefly describe these classes, here as we believe it would help readers in understanding CloudSim and our extensions; a detailed discussion of these classes can be found in [1].

1.1 Main classes

The class diagram of the CloudSim main classes is shown in Fig. 13 [1].

BwProvisioner (abstract class) models the provisioning policy of network bandwidth to VMs.

CloudCoordinator periodically monitors the internal state of datacenter (resources) and undertakes dynamic load-shredding decisions.

Cloudlet models the cloud-based application services (each Cloudlet refers to a user’s job/task).

CloudletScheduler (abstract class) can be extended by the implementation of different policies to determine the share of processing power (CPU) among Cloudlets that are running inside a VM. Two types of provisioning policies are offered in CloudSim: (i) space-shared; and (ii) time-shared [1].

CloudletSchedulerTimeShared represents a provisioning policy which allows resources of a single VM to be shared among various cloudlets or tasks—allocate VMs resources to cloudlets or tasks.

CloudletSchedulerSpaceShared represents a provisioning policy which does not allow resources of a single VM to be shared among various cloudlets or tasks—allocate whole VM to a single and exactly one cloudlet or task.

Datacenter models the core infrastructure-level services (hardware) that are offered by cloud providers (such as Google).

DatacenterBroker discovers suitable cloud service providers by querying the CIS and undertakes online negotiations for allocation of resources that can meet the application requirements.

DatacenterCharacteristics contains configuration information of datacenter resources.

Host models a physical resource—host/server and its characteristics.

NetworkTopology contains the information for inducing network behaviour (latencies) in the simulation.

RamProvisioner represents the provisioning policy for memory (RAM) allocation to VMs.

SanStorage models a Storage Area Network (SAN) that is commonly ambient in datacenters for storing data (such as Amazon S3).

Vm models a VM and its characteristics, which is managed and hosted by Host class.

VmAllocationPolicy represents a provisioning policy to place VMs on hosts.

VmScheduler models the policies (space-shared, time-shared) to allocate processor cores (PEs) to VMs.

VmSchedulerTimeShared represents a provisioning policy which allows resources of a single host to be shared among various VMs—allocate processor cores (PEs) to VMs.

VmSchedulerSpaceShared represents a provisioning policy which does not allow resources of a single host to be shared among various VMs—allocate whole processor core (PE) to a single and exactly one VM.

1.2 Core classes

The class diagram of the CloudSim core classes is shown in Fig. 15 [1].

Fig. 15

Class diagram of CloudSim core classes [1]

CloudSim responsible to manage event queues and control execution of the simulation events. Every event generated by the CloudSim entity at runtime is stored in a queue (future events). The events are sorted based on their creation time. Each event that is scheduled at the simulation step is removed from the queue (future events) and is added to another queue (deferred events).

CloudInformationService provides resource registration, indexing, and discovering capabilities [1].

CloudSimShutdown waits for the termination of all end-user and broker entities, and then signals the end of simulation to CIS.

CloudSimTags consists of various static events/commands which indicate the action taken by CloudSim entities when they receive or send events.

DeferredQueue implements the deferred event queue.

FutureQueue implements the future event queue.

SimEntity (abstract class) represents a simulation entity that is able to send messages to other entities. Furthermore, CIS is responsible to process received messages, fire and handle events. All entities must override the three core methods in this class: (i) startEntity()—entity initialisation; (ii) processEvent()—processing of events; and (iii) ShutdownEntity()—entity destruction.

SimEvent represents a simulation event that is passed between two or more entities.

The above classes when linked with each other can model a simple, but complete datacenter. Besides these classes, other classes might exist in CloudSim simulator and its various variants, such as FederatedDataCenter, containerDataCenter, VmScheduler, and CloudletScheduler. All these classes are inherited either from the above core classes or main classes in some or other way. Therefore, we do not include them in this paper. A detailed discussion, functionalities/capabilities and explanation of these inherited classes can be found in [1, 22]. Further materials, documentations, online courses, publications and several variants of the CloudSim simulator are available at the portal of CLOUDS Laboratory.³⁰