Cloudlet in Cloudsim Simulation

Cloudlet in Cloudsim defined the workload, which is to be executed during the simulation run of the cloudsim simulation engine. Cloudlet in Cloudsim is a model class that exists inside the package ‘org.cloudbus.cloudsim‘. Cloudlet is one of the most important models which defined the specifications for a simulation engine corresponding to the real-life candidate application to be considered for moving to a Cloud-based system.

In contrast, we can also define this cloudlet as a single process or task being executed on the cloud-based system which is to be simulated through a Cloudsim simulation engine.

The cloudlet model class defines four different constructors for its initialization, its method signatures are as follows:

/*
First method signature with 8 parameters with simplest cloudlet execution with out maintaining its history or additional files
*/
public Cloudlet(
			final int cloudletId,
			final long cloudletLength,
			final int pesNumber,
			final long cloudletFileSize,
			final long cloudletOutputSize,
			final UtilizationModel utilizationModelCpu,
			final UtilizationModel utilizationModelRam,
			final UtilizationModel utilizationModelBw)

/*
Second method signature with 10 parameters with support for cloudlet execution history maintenance as well as additionl list of file requirements for execution.
*/
public Cloudlet(
			final int cloudletId,
			final long cloudletLength,
			final int pesNumber,
			final long cloudletFileSize,
			final long cloudletOutputSize,
			final UtilizationModel utilizationModelCpu,
			final UtilizationModel utilizationModelRam,
			final UtilizationModel utilizationModelBw,
			final boolean record,
			final List<String> fileList)

/*
Third method signature with 9 parameters with support for cloudlet execution additionl list of file requirements for execution.
*/
public Cloudlet(
			final int cloudletId,
			final long cloudletLength,
			final int pesNumber,
			final long cloudletFileSize,
			final long cloudletOutputSize,
			final UtilizationModel utilizationModelCpu,
			final UtilizationModel utilizationModelRam,
			final UtilizationModel utilizationModelBw,
			final List<String> fileList)

/*
Fourth method signature with 9 parameters with support for cloudlet execution history maintenance.
*/
public Cloudlet(
			final int cloudletId,
			final long cloudletLength,
			final int pesNumber,
			final long cloudletFileSize,
			final long cloudletOutputSize,
			final UtilizationModel utilizationModelCpu,
			final UtilizationModel utilizationModelRam,
			final UtilizationModel utilizationModelBw,
			final boolean record) 

Cloudlet in Cloudsim defines following are the attributes that are being by the cloudsim simulation engine:

  • userId: defines the broker id to through which this cloudlet will be executed and the result of execution will be returned & displayed on the console through the same broker.
  • cloudletLength: defines the length of the cloudlet in terms of the expected number of instructions required to be executed in the lifetime of the workload under execution.
  • cloudletFileSize: As the cloudlet is supposed to be executed over the cloud that means the input data transfer over the network should be happening during the execution. This attribute defines the total size of the input data in bytes.
  • cloudletOutputSize: Similar to cloudletFileSize the output data size is also defined in bytes.
  • numberOfPes: Defines the number of processors required to execute this cloudlet, if parallel processing is required to be performed.
  • cloudletId: used as a unique identification number for cloudlets, required for referencing throughout the simulation flow.
  • status: defines the current state of the cloudlet. A cloudlet could be in any one of the state as follows: CREATED, READY, QUEUED, INEXEC, SUCCESS, FAILED, CANCELED, PAUSED, RESUMED, FAILED_RESOURCE_UNAVAILABLE. These states are defined explicitly in cloudlet model class and are assigned a numerical value.
  • num: defined the time at various stages of cloudlet execution
  • execStartTime: Defines the latest execution time and is updated every time the status of cloudlet shuffle among CANCEL, PAUSED and RESUMED
  • finishTime: Stores the time, when the execution of the cloudlet is finished and status is not a success.
  • reservationId: defines the ID of the resource reserved for which this cloudlet.
  • record: defines in boolean(True/False) if the history of the cloudlet execution across different resources is maintained or not.
  • newline: Defined newline characteristics and used during the string concatenations while logging the history of cloudlet execution.
  • history: maintains the history of the cloudlet execution across simulation flow.
  • resList: Maintains the log of the resources where the cloudlet is being executed.
  • index: defines the ID of the resource on which the cloudlet is being currently assigned and helps in getting the status
  • classType: Defines the resource scheduling information(never used in cloudsim 3.0.3)
  • netToS: Defines the type of service for the network transactions. This is a field for IPv6 for ensuring the quality of service.
  • vmId: stores the Id of the virtual machine to which this cloudlet is to be allocated for allocation. This is done in the case where you are planning to move a real-life application to a cloud-based system with a specific Virtual machine configuration. Such mapping of cloudlet helps in determining the behavior of the application in various scenarios as simulated over the cloudsim simulation engine.
  • costPerBw: defines the cost associated with the usage of the network for cloudlet network usage. this is overridden if the cost on bandwidth is defined by the datacenter instance which is always done.
  • accumulatedBwCost: Stores the overall cost of bandwidth consumed by the cloudlet while processing during the simulation. This can be used to check what is the cost involved in network bandwidth for a particular candidate application which is under consideration to be moved to the cloud-based system.
  • utilizationModelCpu/utilizationModelRam/utilizationModelBw: these attributes defines the type of model to be used for executing the defined cloudlet. It may individually defined for each attribute from following: UtilizationModelFull, UtilizationModelNull, UtilizationModelStochastic and UtilizationModelPlanetLabInMemory(used in power-aware workloads only).
  • requiredFiles: defines the path for the list of files to be required by the cloudlet during execution. These are the input files and are directly associated with the network bandwidth cost.

Following are the states that each cloudlet can sustain during the simulation flow:

  • CREATED: Defined when the cloudlet is created and added to the CloudletList(used by the datacenter broker during the simulation flow)
  • READY: Defined when the cloudlet is assigned with a resource for execution
  • QUEUED: Defined when the cloudlet is moved to the cloud resource on which it will wait for its execution
  • INEXEC: Defined when the cloudlet is put into execution on the assigned cloud resource;
  • SUCCESS: Defined when the cloudlet execution is successfully completed and is ready to be sent back to the broker with its final status
  • FAILED: Defined in case the cloudlet is failed to be executed to the planned cloud node e.g. when the VM for which the cloudlet is to be assigned is failed to start due to any reason the cloudlet execution will be failed.
  • CANCELED: Defined, when the execution of the cloudlet is canceled due to any situation and can be further denoted in the failed state is required
  • PAUSED: Defined, when the cloudlet execution is put on hold. This could be due to some high priority cloudlet arrival or due to VM migration etc.
  • RESUMED: Defined to resume the cloudlet execution after it is being paused.
  • FAILED_RESOURCE_UNAVAILABLE: Defined when the cloudlet execution failed due to the failure of the resource on which it was supposed to be executed.

The cloudlets would shuffle between these states any number of times depending upon the simulation scenario under consideration.

One of the most important behaviors of the Cloudlet model class is that it may be moved from one resource to another resource due to any implicit/explicit reasons, therefore, the track is to be maintained for its movement during the simulation flow. To support this a nested class named ‘Resource’ is defined which contains the following attributes:

  • submissionTime: defines when the cloudlet was submitted to the provided cloud resource instance.
  • wallClockTime: defines the total time that a cloudlet spent of the currently provided cloud resource.
  • actualCPUTime: defines the actual time spent under the execution and may or may not differ from wallClockTime.
  • costPerSec: defines the cost spent on execution of cloudlet on currently provided cloud resources based on usage per second.
  • finishedSoFar: defines the currently completed execution under the currently provided cloud resource.
  • resourceId: stores the unique ID of the cloud resource which is currently provided to the cloudlet for the execution.
  • resourceName: defines the name of the current cloud resource.

The instance of this ‘Resource’ model class is defined and utilized through the setResourceParameter() method of cloudlet class. Which is further utilized in the processCloudletSubmit() method(line no 715) of DataCenter class available under the same package i.e. ‘org.cloudbus.cloudsim’. This class plays a very important role in simulated distributed network applications.

Learn More

You may subscribe to an online self-paced course named Learn Basics of Cloudsim, The content for this course which will be updated weekly till August 2021. Click here to get the applicable discount coupon codes.

Power-Aware Simulation Scenario in Cloudsim

Support of Power-aware Simulation scenario in cloudsim is one of the major breakthroughs and it has been widely utilized by the research community to publish their optimized results related to their proposed algorithms referring to VM migrations, SLA’s, resource allocation, reducing power consumption, etc. The general questions that are being worked upon are:

How to optimize resource allocation?

How to perform VM migrations?

How to reduce host power consumption?

How to reduce SLA violations?

As a stimulating environment, the cloudsim provides various API which allows you to work around generating a simulating model for answering the questions mentioned above. To effectively utilize the power-aware feature of cloudsim, you should be aware of the API packages that are available at your dispose of and for what purpose you would be able to use it. Following are the three core packages within cloudsim that facilitate the simulation of power-aware scenarios:

  • org.cloudbus.cloudsim.power.models
  • org.cloudbus.cloudsim.power.lists
  • org.cloudbus.cloudsim.power

Let us go through each of these packages one by one, but in case you have bumped in this article directly from search and no clue about the basic structure of cloudsim then you should first read CloudSim Simulation Toolkit: An Introduction and Beginners Guide to Cloudsim Project Structure 

org.cloudbus.cloudsim.power.models

Now the first thing to understand is that we are trying to simulate the real servers to calculate their power consumption.

Generic Power Model Class Hierarchy for power-aware simulation scenario
Generic Power Model Class Hierarchy

There are four generic power models were implemented as class names: PowerModelLinear.java, PowerModelCubic.java, PowerModelSquare.java, and PowerModelSqrt.java. Inherently, all these power models implement the PowerModel.java interface.

Also, the package org.cloudbus.cloudsim.power.models allow you to utilize the existing power model like “PowerModelSpecPowerIbmX3550XeonX5675.java” which models the server machine IBM X3550 with 2 XeonX5675 processors(6 cores each) along with the memory capacity of 16GB. Overall there are six server-based power models were implemented by the cloudsim developer’s team.

Server Power Model Class Hierarchy for power-aware simulation scenario
Server Power Model Class Hierarchy

Following is the code of model mentioned above:

package org.cloudbus.cloudsim.power.models;

public class PowerModelSpecPowerIbmX3550XeonX5675 extends PowerModelSpecPower {

      private final double[] power = { 58.4, 98, 109, 118, 128, 140, 
                                       153, 170, 189, 205, 222 };

      @Override
      protected double getPowerData(int index) {
             return power[index];
      }
}

The SPEC Benchmark is the base for generating these server-based power models. And, On a similar note, you may extend your own server specification power models in cloudsim just by extending the PowerModelSpecPower.java class, which also inherits the PowerModel.java. This is an abstract class containing two methods named getPower() and abstract method getPowerData(). As you can see in the above code the abstract method getPowerData() is been implemented in the simplest way and returns a predefined power against the specified utilization factor.

Now the point is how these models are being utilized while simulation. for this, you should be exploring the “org.cloudbus.cloudsim.examples.power” package and within this check “Constant.java” class. In this, a PowerModel array is declared at line number 60 as follows:

public final static PowerModel[] HOST_POWER = {
		new PowerModelSpecPowerHpProLiantMl110G4Xeon3040(),
		new PowerModelSpecPowerHpProLiantMl110G5Xeon3075()
	};

then the same has been called on logic to choose a random power model in “Helper.java” through createHostList() method at line number 108, while adding a new host to hostlist as follows:

public static List<PowerHost> createHostList(int hostsNumber) {

List<PowerHost> hostList = new ArrayList<PowerHost>();
for (int i = 0; i < hostsNumber; i++) 
{
        //logic to choose the random power model
	int hostType = i % Constants.HOST_TYPES;

	List<Pe> peList = new ArrayList<Pe>();
	for (int j = 0; j < Constants.HOST_PES[hostType]; j++) 
        {
	       peList.add(new Pe(j, new 
               PeProvisionerSimple(Constants.HOST_MIPS[hostType])));
	}
	hostList.add(
           new PowerHostUtilizationHistory(i,
	     new RamProvisionerSimple(Constants.HOST_RAM[hostType]),
	     new BwProvisionerSimple(Constants.HOST_BW),
             Constants.HOST_STORAGE,
             peList,
             new VmSchedulerTimeSharedOverSubscription(peList),

             //Exact place where the power model is specified
             Constants.HOST_POWER[hostType])
         );
}
return hostList;
}

So in case you have worked upon your own custom power model, you should be working around these sets of codes to make it work with your simulation scenario.

org.cloudbus.cloudsim.power.lists

This package contains only one class definition i.e. PowerVmList.java which inherently extends the vmList. As mentioned in cloudsim documentation this class contains the specific operations related to virtual machines and there is only one method defined to perform sorting of VM on the basis of its CPU utilization.

This class is been instantiated from createVmList() method of Helper.java during a power-aware simulation run.

This package can be utilized to addon more lists or adding more relevant operations related to the virtual machines that might be required during the migration process.

org.cloudbus.cloudsim.power

This package contains the core set of power-aware extended models of DataCenter, DataCenter Broker, Host, Vm(virtual machine). Along with this, a new set of classes related to Vm Allocation policy as well as Vm Selection policy were included here. These sets of classes facilitate the power-aware simulation scenario in cloudsim that are related to optimized Vm allocation or migrations.

The PowerDatacenter extends the basic Datacenter class and implements the additional methods that support the virtual machine migration process along with the cloudlet processing.

Class Hierarchy of PowerDatacenter for power-aware simulation scenario
Class Hierarchy of PowerDatacenter

Similarly, the PowerDatacenterBroker extends the basic DatacenterBroker. This new extended class overrides only the processVmCreate() method which is responsible for identifying whether or not the VM create is processed.

Class Hierarchy of PowerDatacenterBroker
Class Hierarchy of PowerDatacenterBroker

The PowerHost extends the HostDynamicWorkload which further extends the classic Host class. It does a really great addition to the overall power-aware simulation and contains the implementation of methods related to power calculation on the basis of the simulated server power model. Apart from this PowerHost class is further extended by PowerHostUtilizationHistory which implements various methods to track and process the host CPU utilization history. This history is further utilized by the allocation and selection policies during VM migration.

Class hierarchy of PowerHost for power-aware simulation scenario
Class Hierarchy of PowerHost

The PowerVm class extends the classic Vm class and one of the major method overrides is of updateVmProcessing() this updates the processing cloudlet by Vm during the simulation run. Apart from this, it contains the implementation for maintaining the utilization history, utilization mean, median, and standard deviation, etc.

Class hierarchy of PowerVm for power-aware simulation scenario
Class Hierarchy of PowerVm

The power-aware package contains the implementation of VM Allocation and Selection policies as classes. This set of classes contains the logic to perform the optimized VM migrations among running hosts on the fly during any simulation scenario. During the realtime VM migration first the hosts are identified(Overutilized/Underutilized) from which the VM to be selected for migration and are kept is a migration list. This is based on the Vm selection policy, few policies are predefined in cloudsim and the class hierarchy for VM selection policies are as follows:

Class hierarchy of Vm Selection Policies  for power-aware simulation scenario
Class Hierarchy of Vm Selection Policies

In case you want to implement your own selection algorithm for VM migration, you are required to extend the PowerVmSelectionPolicy class and should study all the classes mentioned above for better understanding.

Now as the list of identified VMs is ready the next step if to find the suitable host to migrate the selected VM. This is done by the appropriate VM Allocation Policies, just like selection policies there are few VM allocation policies are predefined in cloudsim and the class hierarchy for VM allocation policies are as follows:

Class hierarchy of Vm Allocation Policies for power-aware simulation scenario
Class Hierarchy of Vm Allocation Policies

In case you want to implement your own allocation algorithm for VM migration, you are required to extend the PowerVmAllocationPolicyMigrationAbstract class and should study all the classes mentioned above for better understanding.

The basic utilization of this package is done through the example of a power-aware simulation scenario available in org.cloudbus.cloudsim.examples.power.planetlab as well as org.cloudbus.cloudsim.examples.power.random. These examples have implemented a variety of combinations of VM allocation and selection policies. This helps in recognizing various scenarios in which the overall system optimization related to the VM migration process can be analyzed.

org.cloudbus.cloudsim.examples.power.planetlab VS org.cloudbus.cloudsim.examples.power.random

The basic difference between the org.cloudbus.cloudsim.examples.power.planetlab and org.cloudbus.cloudsim.examples.power.random package is that the org.cloudbus.cloudsim.examples.power.planetlab utilizes a PlanetLab’s VM utilization benchmark data for recognization of the power-aware simulation scenario behavior whereas org.cloudbus.cloudsim.examples.power.random generates its own workload.

Learn More

You may subscribe to an online self-paced course named Learn Basics of Cloudsim, The content for this course which will be updated weekly till August 2021. Click here to get the applicable discount coupon codes.

Beginners Guide to Cloudsim Project Structure

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.

Eclipse Project Explorer representing Cloudsim project structure
CloudSim 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.

Cloudsim Readme.txt file content
Readme.txt file

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

Source Folder namespace/packages
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.
List of org.cloudbus.cloudsim classes
  • 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.
Class list of org.cloudbus.cloudsim.core
  • 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.
Class List of Org.cloudbus.cloudsim.core.predicates
  • 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.
Class list of Org.cloudbus.cloudsim.distribution
  • 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.
Class list of Org.cloudbus.cloudsim.lists
  • 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.
Class list of Org.cloudbus.cloudsim.Network
  • 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.
Class list of Org.cloudbus.cloudsim.Network.datacenter
  • 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.
Class list of Org.cloudbus.cloudsim.power
  • 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.
Class list of Org.cloudbus.cloudsim.power.lists
  • 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.
Class list of Org.cloudbus.cloudsim.power.models
  • Org.cloudbus.cloudsim.provisioners: This namespace contains the behavior implementation regarding how the specified cloud component provisioned to requesting virtual resources.
Class list of Org.cloudbus.cloudsim.provisioners
  • Org.cloudbus.cloudsim.util: this namespace contains the implementation of essential calculation functions and a general utility set.
Class list of Org.cloudbus.cloudsim.utils

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

Class list of Org.cloudbus.cloudsim.examples and relevant namespaces

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.
cloudsim project JRE automated compiled dependencies.
  • Reference Libraries: It contains the various dependency jars again automatically added by the eclipse during the first build process.
cloudsim reference libraries
  • Docs: Contains the minimalist documentation of the cloudsim class API and is automatically generated from the inline comments.
cloudsim documentation
  • 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.
cloudsim bundled jar provided with source code.
  • 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.

You may also follow the detailed step by step demo to “Cloudsim Tutorial: Introduction to Package Intro (Part 2)

Learn More

You may subscribe to an online self-paced course named Learn Basics of Cloudsim, The content for this course which will be updated weekly till August 2021. Click here to get the applicable discount coupon codes.