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