Guide to CloudsimExample1.

java
simulation workflow
 published: july 20, 2019 / updated: november 25, 2019  anupinder singh  cloudsim
Any Example provided in the ‘org.cloudbus.cloudsim.example’ Package under the
example folder of the CloudSim project follows some standard steps to implement
the specified configuration to start a simulation. To understand the working of the
CloudSim simulation framework, knowledge about these steps is a must. This article
will help you to get an understanding of CloudsimExample1.java simulation workflow.

Before you start, It is essential that the cloudsim should already installed/setup on
your local computer machine. In case you are yet to install it, you may follow the
process of Cloudsim setup using Eclipse IDE

The main() method is the pointer from where the execution of this example starts

public static void main(String[] args)

There are eleven steps that are followed in each example with some variation in
them, specified as follows:

 Set the Number of users for the current simulation. This user count is directly
proportional to a number of brokers in the current simulation.

int num_user = 1; // number of cloud users

Calendar calendar = Calendar.getInstance();
boolean trace_flag = false;

 Initialize the simulation, provided with the current time, number of users and
trace flag.

CloudSim.init(num_user, calendar, trace_flag);

 Create a Datacenter.

Datacenter datacenter0 = createDatacenter("Datacenter_0");

where the createDatacenter() method itself initializes the various datacenter
characteristics along with the host list. This is the most important entity without this
there is no way the simulation of hosting the virtual machine is applicable.

private static Datacenter createDatacenter(String name)

{
List<Host> hostList = new ArrayList<Host>();
List<Pe> peList = new ArrayList<Pe>();
int mips = 1000;
peList.add(new Pe(0, new PeProvisionerSimple(mips)));
int hostId = 0;
int ram = 2048; // host memory (MB)
long storage = 1000000; // host storage
int bw = 10000;
hostList.add(
 new Host(
hostId,
new RamProvisionerSimple(ram),
new BwProvisionerSimple(bw),
storage,
peList,
new VmSchedulerTimeShared(peList)
)
);
String arch = "x86";
String os = "Linux";
String vmm = "Xen";
double time_zone = 10.0;
double cost = 3.0;
double costPerMem = 0.05;
double costPerStorage = 0.001;
double costPerBw = 0.0;
LinkedList<Storage> storageList = new LinkedList<Storage>();
DatacenterCharacteristics characteristics = new
DatacenterCharacteristics(arch, os, vmm, hostList,
time_zone, cost, costPerMem,
costPerStorage, costPerBw);
Datacenter datacenter = null;
try {
datacenter = new Datacenter(name, characteristics, new
VmAllocationPolicySimple(hostList),
storageList, 0);
} catch (Exception e) {
e.printStackTrace();
}
return datacenter;
}

 Create a Datacenter broker.

DatacenterBroker broker = createBroker();

int brokerId = broker.getId();
Where the createBroker() method initializes the entity object from DatacenterBroker
class

private static DatacenterBroker createBroker()

{
DatacenterBroker broker = null;
try {
broker = new DatacenterBroker("Broker");
} catch (Exception e) {
e.printStackTrace();
return null;
}
return broker;
}

 Create a Virtual Machine(s).

vmlist = new ArrayList<Vm>();

int vmid = 0;
int mips = 1000;
long size = 10000;
int ram = 512;
long bw = 1000;
int pesNumber = 1;
String vmm = "Xen";

Vm vm = new Vm(vmid, brokerId, mips, pesNumber, ram, bw, size, vmm, new
CloudletSchedulerTimeShared());

vmlist.add(vm);

 Submit Virtual Machine to Datacenter broker.

broker.submitVmList(vmlist);

 Create Cloudlet(s) by specifying their characteristics.

cloudletList = new ArrayList<Cloudlet>();

int id = 0;
long length = 400000;
long fileSize = 300;
long outputSize = 300;
UtilizationModel utilizationModel = new UtilizationModelFull();

Cloudlet cloudlet = new Cloudlet(id, length, pesNumber, fileSize,

outputSize, utilizationModel, utilizationModel,
utilizationModel);

cloudlet.setUserId(brokerId);
cloudlet.setVmId(vmid);

cloudletList.add(cloudlet);

 Submit Cloudlets to Datacenter broker.

broker.submitCloudletList(cloudletList);

 Send call to Start Simulation.

CloudSim.startSimulation();

 Once no more event to execute, send the call to Stop Simulation.

CloudSim.stopSimulation();

 Finally, print the final status of the Simulation.

List<Cloudlet> newList = broker.getCloudletReceivedList();

printCloudletList(newList);
Where printCloudletList() method formats the output to correctly display it on the
console.

private static void printCloudletList(List<Cloudlet> list)

{
int size = list.size();
Cloudlet cloudlet;
String indent = " ";
Log.printLine();
Log.printLine("========== OUTPUT ==========");
Log.printLine("Cloudlet ID" + indent + "STATUS" + indent
+ "Data center ID" + indent + "VM ID" +
indent + "Time" + indent
+ "Start Time" + indent + "Finish Time");

DecimalFormat dft = new DecimalFormat("###.##");

for (int i = 0; i < size; i++)
{
cloudlet = list.get(i);
Log.print(indent + cloudlet.getCloudletId() + indent +
indent);
if (cloudlet.getCloudletStatus() == Cloudlet.SUCCESS)
{
Log.print("SUCCESS");
Log.printLine(indent + indent +
cloudlet.getResourceId()
+ indent + indent + indent +
cloudlet.getVmId()
+ indent + indent +
dft.format(cloudlet.getActualCPUTime())
+ indent + indent +
dft.format(cloudlet.getExecStartTime())
+ indent + indent +
dft.format(cloudlet.getFinishTime()));
}
}
}
Once you Run the example the output for cloudsimExample1.java will be displayed
like:

CloudsimExample1.java console output

Also, the following video tutorial contains a detailed about cloudsimexample1.java
and helps you to understand CloudsimExample1.java simulation workflow

////////////////////////////////////////////////////
Beginners Guide to Cloudsim Project
Structure
https://www.cloudsimtutorials.online/beginners-guide-to-cloudsim-project-structure/

 published: july 10, 2019 / updated: november 25, 2019  anupinder singh  uncategorized

The Cloudsim Simulation Toolkit is an API that is written using the Java
programming language and its classes are structured in a very specific way. This
article will serve as a guide to the Cloudsim project structure and will help you
understand how the Cloudsim architecture is divided into different packages and
their important classes that facilitate the cloud simulation using Cloudsim.

Let us first explore and understand the structure of this simulation project. I assume
that you have already set up the cloudsim using Ecplise if not you may follow my
previous article on “Cloudsim Setup using Eclipse“.

Let proceed further and your eclipse project explorer should contain 6 folders and 7
files.
 Cloud
Sim Project Structure
The readme.txt file contains the necessary information about this project, like how to
install and run the cloudsim, what is the basic directory structure, if you are not using
any IDE then how to build the project source code.

Readme.txt file
Now, let us look at the directory structure in detail and understand the various
namespaces available in the “Source” folder

Cloudsim Source folder namespace/package view

There exist 12 namespaces; each namespace has a set of classes with specific
correlated functions as discussed below:

 Org.cloudbus.cloudsim: It contains the model classes of various basic

hardware components, their groups, and the allocation/utilization methods,
etc. Here, the model means that the classes contain the implementation of the
various attributes and behaviors of the real-life cloud computing hardware
component as a collection of Java methods. Once these classes initiate
during the simulation, they are going to simulate the behavior of the real-life
cloud-based system component.

 Org.cloudbus.cloudsim.core: This namespace contains the implementation

of the simulation engine where the cloudsim.java class is the main class and
is responsible for the start and stop of the simulation process. Similarly, the
simentity.java class is for maintaining the state of the simulated cloud
components. Simevent.java, futurequeue.java, and defferedqueue.java are
responsible for maintaining the inter-entity(cloud component) related event
call during the simulation process.

 Org.cloudbus.cloudsim.core.predicates: contains the classes related to the

selection of events from the defferedqueue.java to be processed during the
simulation event processing.

 Org.cloudbus.cloudsim.distribution: It contains the implementation of the

various distribution function but is not used anywhere in the cloudsim. These
classes might be for future purposes.

 Org.cloudbus.cloudsim.lists: It contains the implementation of lists to be

used globally during the simulation process. These are the specialized set of
classes, where sorting and comparison operation implemented. There exist
the list class for the host, processing element, cloudlet, virtual machine, and
resources.

 Org.cloudbus.cloudsim.network: it contains the implementation for the

network related simulations purpose, and if you are working on a research
 work based on network optimization techniques then this is the best set of
classes to extend for simulation.

 Org.cloudbus.cloudsim.network.datacenter:  This namespace contains the

extended implementation of the basic cloud hardware components which can
support the simulation of federated cloud functions distributed across the
regions.

 Org.cloudbus.cloudsim.power: This package contains the extended

implementation of cloud components, which can simulate the green or power-
aware computing scenarios. This namespace implements the VM migration
related classes where extensive algorithm codes for virtual machine selection
and allocation related to migrations are available.

 Org.cloudbus.cloudsim.power.lists: This namespace contains only the

implementation of powervmlist.java, which is an extended version of the
VmList.java class of org.cloudbus.cloudsim.list namespace.

 Org.cloudbus.cloudsim.power.models: It contains the set of classes that

specifies the power configurations of servers as model classes. These
classes imitate the actual working of the various server machine brands
available in the market and help in determining the power consumption by
such machines during the simulation process.

 Org.cloudbus.cloudsim.provisioners: This namespace contains the

behavior implementation regarding how the specified cloud component
provisioned to requesting virtual resources.

 Org.cloudbus.cloudsim.util:  this namespace contains the implementation of

essential calculation functions and a general utility set.
Now let’s look at the “examples” folder. It contains 7 namespaces, and each
namespace contains a particular type of scenario implementations.

Examples.txt gives you an overview of various basic example scenarios that are

available in this folder. The file contains the instructions for the compile and
execution of example classes.

Workload.planetlab: It contains a real dataset containing a set of CPU utilization

traces from PlanetLab VMs collected during the 10 random days in March & April of
2011. The PlanetLab dataset is used as a benchmark dataset for the validation of
various research scenarios.

Now let’s move to the other folders:

 JRE system library: It is automatically created during the first build process
of the CloudSim by the eclipse.

 Reference Libraries: It contains the various dependency jars again

automatically added by the eclipse during the first build process.

 Docs: Contains the minimalist documentation of the cloudsim class API and

is automatically generated from the inline comments.

 Jars: This folder is supplied with the source zip file and contains the pre-
compiled build of the cloudsim 3.0.3. It can be used for creating custom
project scenarios whenever required. We will work on this in further blog
posts.

 Build.xml is an ANT based XML file used during the console based builds.
 Changelog.txt contains the history of the changes done to cloudsim during
various version releases.
 License.xml contans GNU-GPL notification.
 Pom.xml is a maven configuration file used during the setup of cloudsim
using eclipse.
 Releasenotes.txt contains the note from the cloudsim development team.
 ////////////////////////////////////////////////////////////////////////////////

CloudSim Simulation Toolkit: An

Introduction
 published: may 31, 2019 / updated: november 25, 2019  anupinder singh  cloudsim, introduction

Cloud computing is a pay as you use model, which delivers infrastructure (IaaS),
platform (PaaS) and software (SaaS) as services to users as per their requirements.
Cloud computing exposes data centers capabilities as network virtual services,
which may include the set of required hardware, application with support of the
database as well as the user interface. This allows the users to deploy and access
applications across the internet which is based on demand and QoS requirements.

As Cloud computing is a new concept and is still in a very early stage of its
evolution, so researchers and system developers are working on improving
the technology to deliver better on processing, quality & cost parameters. But
most of the research is focused on improving the performance of provisioning
policies and to test such research on real cloud environment like Amazon EC2,
Microsoft Azure, Google App Engine for different applications models under variable
conditions is extremely challenging as:

1. Clouds exhibit varying demands, supply patterns, system sizes, and resources
(hardware, software, and network).
2. Users have heterogeneous, dynamic, and competing QoS requirements.
3. Applications have varying performance, workload, and dynamic application scaling
requirements.

Benchmarking the application performance on the real public cloud

infrastructure like google cloud, Microsoft Azure, etc., are not suitable due to
their multi-tenant nature as well as variable workload fulfillment.

Also, there are very few admin level configurations that a user/researcher could be
able to change. Hence, this makes the reproduction of results that can be relied
upon, an extremely difficult undertaking.

Further, even if we do, it is a tedious and time-consuming effort to re-configure

benchmarking parameters across a massive-scale Cloud computing infrastructure
over multiple test runs. Therefore, it is impossible on real-world public Cloud
systems to undertake benchmarking experimentations as repeatable,
dependable, and scalable environments.

Thus the need to use simulation tool(s) arises, which may become a viable

alternative to evaluate/benchmark the test workloads in a controlled and fully
configurable environment that can repeatable over multiple iterations and
reproduce the results for analysis.

This simulation-based approach can provide various benefits across the researcher’s
community as it allows them to:
 1. Test services in a repeatable and controllable environment.
2. Tuning the system bottlenecks (performance issues) before deploying on real clouds.
3. Simulating the required infrastructure(small or large scale) to evaluate different sets
of workload as well as resource performance, which facilitates for developing, testing
and deployment of adaptive application provisioning techniques.

This article provides a beginners guide to cloudsim simulation toolkit and helps then
to get an insight into the role of its various components.

Why use Cloudsim?

Several simulators can be used to simulate the working of new services, among
them CloudSim Simulation Toolkit is the more generalized and effective
simulator for testing Cloud computing-related hypothesis. CloudSim is an
extensible simulation framework developed by a team of researchers(under the
guidance of Dr. Raj Kumar Buyya) at Cloud Computing and Distributed Systems
(CLOUDS) Laboratory, University of Melbourne. This toolkit allows seamless
modeling, simulation, and Experimentation related to cloud-based infrastructures and
application services and its various released versions are published on Cloudsim’s
GitHub project page.

This simulation toolkit allows the researchers as well as cloud developers to

test the performance of the potential cloud application for performance testing
in a controlled and easy to setup environment. And Also allows finetuning the
overall service performance even before it is deployed in the production
environment.

Features of CloudSim Simulation Toolkit

1. Support for modeling and simulation of large-scale Cloud computing environments,

including data centers, on a single physical computing node(could be a desktop,
laptop, or server machine).
2. A self-contained platform for modeling Clouds, service brokers, provisioning, and
allocation policies.
3. Facilitates the simulation of network connections across the simulated system
elements.
4. Facility for simulation of federated Cloud environment that inter-networks resources
from both private and public domains, a feature critical for research studies related to
Cloudbursts and automatic application scaling.
5. Availability of a virtualization engine that facilitates the creation and management of
multiple, independent, and co-hosted virtualized services on a data center node.
6. Flexibility to switch between space-shared and time-shared allocation of processing
cores to virtualized services.

All these features would help in accelerating the development, testing and
deployment of potential resource/application provisioning policies/algorithms for
Cloud Computing based systems.

CloudSim Architecture
The above diagram demonstrates the layered architecture of CloudSim Simulation
Toolkit. The CloudSim Core simulation engine provides support for modeling and
simulation of virtualized Cloud-based data center environments including queuing
and processing of events, creation of cloud system entities (like data center, host,
virtual machines, brokers, services, etc.) communication between components and
management of the simulation clock.

The CloudSim layer provides dedicated management interfaces for Virtual

Machines, memory, storage, and bandwidth. Also, it manages the other fundamental
issues, such as provisioning of hosts to Virtual Machines, managing application
execution, and monitoring dynamic system state(e.g. Network topology, sensors,
storage characteristics, etc), etc.

The User Code layer is a custom layer where the user writes their own code to
redefine the characteristics of the stimulating environment as per their new research
findings.

Design and Implementation of CloudSim

In this section, we provide finer details related to the fundamental classes of
CloudSim Simulation Toolkit(Version 3.0.3), which are also the building blocks of the
simulator. The overall class design diagram for CloudSim is as(to better understand
read- “Guide to CloudsimExample1.java simulation workflow“):

The description of all the major classes mentioned in the class diagram above is
described below:

1. Cloudlet: This class model(define specific attributes such as length of instruction,

input/output filesize, no of processor required, etc) the Cloud-based application
services (program based tasks) such as content delivery, social networking, etc.
CloudSim implements the complexity of an application in terms of its computational
requirements. As a developer, we know that every individual executable
application/service workload has a pre-defined instruction length and requires certain
network data flow (both pre and post fetches) overhead that it needs to undertake
during its life cycle. this class allows modeling all the above-said requirements
2. CloudletScheduler: This is responsible for the implementation of different policies
that determine the share of processing power among Cloudlets in a VM. There are
two types of provisioning policies offered: space-shared (using
CloudetSchedulerSpaceShared class) and time-shared (using
CloudletSchedulerTimeShared class).
3. Datacenter: This class model the core infrastructure-level services (i.e. hardware)
that are offered by Cloud providers (Amazon, Azure, and App Engine). It
encapsulates a set of hosts(resembling server machine model) instances that
can either be homogeneous or heterogeneous concerning their hardware
configurations (memory, cores, capacity, and storage). Also, every Datacenter
component takes care of generalized application provisioning that enforces a set of
policies for the allocation of bandwidth, memory, and storage devices to hosts and its
related VMs.
4. DatacenterBroker or Cloud Broker: This class model a broker, which is responsible
for mediating negotiations between SaaS and Cloud providers and such negotiations
are driven by QoS requirements. The broker class acts on behalf of applications. Its
 prime role is to query the CIS to discover suitable resources/services and undertakes
negotiations for the allocation of resources/services that can fulfill the application’s
QoS needs. This class must be extended for evaluating and testing custom brokering
policies.
5. DatacenterCharacteristics: This class contains configuration information of data
center resources like the available host list, the fine-grained cost for each resource
type, etc.
6. Host: This class model a physical resource such as a computer or storage server. It
encapsulates important information such as the amount of memory and storage, a list
and type of processing cores (if it is a multi-core machine), an allocation of policy for
provisioning the compute, memory and bandwidth to the VMs.
7. NetworkTopology: This class contains the information for inducing network behavior
(latencies) in the simulation. It stores the topology information, which is generated
using the BRITE topology generator.
8. RamProvisioner: This is an abstract class that represents the provisioning policy for
allocating primary memory (RAM) to Virtual Machines. The execution and
deployment of VM on a host are feasible only if the RamProvisioner component
approves that the host has the required amount of free memory. The
RamProvisionerSimple does not enforce any limitation on the amount of memory that
a VM may request. The RAM resource request will be rejected if it is beyond the
available capacity.
9. BwProvisioner: The main role of this component is to undertake the allocation of
network bandwidths to a set of competing VMs that are deployed across the data
center. Cloud system developers and researchers can extend this class with their
policies (priority, QoS) to reflect the needs of their applications.
10. Vm: This class model a Virtual Machine (VM), which is managed and hosted by a
Cloud host component. Every VM component has access to a component that stores
the following characteristics related to a VM (i.e.) accessible memory, processor,
storage size, and the VM’s internal provisioning policy that is extended from an
abstract class called the CloudletScheduler.
11. VmAllocationPolicy: This is an abstract class that represents a provisioning policy
to be utilized by VM Monitor for mapping VMs to hosts. The primary role is to select
the best fit host in a data center that meets the memory, storage, and availability
requirement for VM deployment mapping.
12. VmScheduler: This is an abstract class implemented by a Host component that
models the allocation policies (space-shared, time-shared) defining the rules for
processor cores allocations to VMs. To accommodate application-specific processor
sharing policies, the class functionality can be extended to define a new set of
provisioning rules.
13. CloudSim: This is the prime class, with the role of managing entity event queues and
controlling the sequential execution of simulation events. Every event that is
generated by the CloudSim entity at run-time is stored in the queue called future
events. These events are sorted by their time parameters and are enqueued into the
future queue. Next, the events that are scheduled at each step of the simulation are
removed from the future events queue and transferred to the deferred event queue.
Following this, an event processing method is invoked for each entity, which chooses
events from the deferred event queue and performs appropriate actions. Such an
organization allows flexible management of simulation and provides the following
powerful capabilities:
a. Deactivation (hold/pause) of entities.
b. Context switching of entities between different states (e.g. waiting to active).
Pause and resume the process of simulation.
c. Creation of new entities at run-time.
d. Aborting and restarting simulation at run-time.
 14. FutureQueue: This class implements the future event queue accessed by CloudSim
and acts as a ready queue to the simulation engine.
15. DeferredQueue: This class implements the deferred event queue used by CloudSim
and hold such events which are failed or paused. It acts as a wait queue of the
simulation engine, where preempted resource requests are kept.
16. CloudInformationService: A CIS is an entity that provides resource registration,
indexing, and discovering capabilities. CIS supports two basic primitives:
a. publish(), on the start of simulation it allows entities to register themselves
with CIS
b. search(), allows Brokers in discovering resources status and endpoint
addresses of other entities. This entity also acts as a notification service to
the other entities about the end of the simulation.
17. SimEntity: This is an abstract class, which represents a simulation entity (such as
DataCenter, DatacenterBroker, etc) ) that is able to send messages to other entities
and processes received messages as well as fire and handle events. SimEntity
class provides the ability to schedule new events and send messages to other
entities, where network delay is calculated according to the BRITE model.
Once created, entities automatically register with CIS. All entities must extend
this class and override its three core methods:
a. startEntity(), which define actions for entity initialization.
b. processEvent(), which defines actions processing of each called event(s)
with respect to the entity.
c. shutdownEntity(),which define actions for entity destruction.
18. CloudSimTags. This class contains various static event/command tags that indicate
the type of action that needs to be undertaken by CloudSim entities when they
receive or send events.
19. SimEvent: This entity represents a simulation event that is passed between two or
more entities. SimEvent stores the following information about an event:

a. type,
b. init time,
c. time at which the event should occur,
d. finish time,
e. time at which the event should be delivered to its destination entity,
f. IDs of the source and destination entities,
g. the tag of the event, and
h. Data that have to be passed to the destination entity.
2. CloudSimShutdown: This is an entity class that waits for the termination of all end-
user submitted cloudlets(tasks) and broker entities events, and once detected, then
signals the end of simulation to CIS.

Following is a very specific and important call hierarchy of classes which enables the
CloudSim Simulation Toolkit to simulate the cloud computing environment, as
demonstrated below:

This hierarchy during the simulation iteratively calls a sequence of events to be

performed with respect to the submitted Cloudlets, Datacenterborker policies and
other relevant entities. The iteration stops when there are no more events left in
FutureQueue/DeferredQueue instances.

////////////////////////////////////////////////////